Continuing problem analysis Linux systems

Today I noticed several new problems and am adding them to my diagnostics queue. One is device drivers that do not act sensibly either in Windows or Linux. I have a model problem where the fan on the video card runs constantly. From this I will build the tools that allow me to see what is taking place and how these things are controlled now. It is vastly more complex and radically different than the first VGA interfaces. Multiple CPUs , memory mapping, port mapping, analog and digital as well as new types of integration.

Another issue is cross talk in the USB stack. I have a capture device that can make the mouse scroll. I am certain this is not an intended action. There must be some data cross contamination between USB devices and I can see I am going to have to make my own kernel. As well as kernel modules.

Something is radically wrong and somebody has to understand it, in order to maintain it.

What adds more complexity is the ever changing landscape of the Internet. There is new functionality everywhere and sometimes it isn't documented well, or even possible. How do you notify a user that a new tool is available on an interface and how can a person deal with this. I can't just erase my behavior like a disk sector and every new change leads to a new case action on every choice.

Here is a link to some helpful USB information on the USB stack and HIDs. I am guessing that the video device in question is generating HID commands on its USB and they are being moved to the mouse or pointer interface.

I suppose it all starts with lsbusb to get an idea of what is taking place. Here is another link to USB stuff for the kernel.

I suspect some deep conflict issues that are connectivity, but act in such a complex way that they are not considered. Here is another command.

cat /proc/bus/input/devices

Lack of information plagues the process and control of driver software developed for devices can complicate issues when hidden functionality causes actions which cannot be predicted. I would say that it is complicated enough to have thousands of CPUs running somewhat independently, without concealing interfaces and signals. I have to wonder how many people really understand all of this, anymore than theoretical physics. To me the structure of the universe seems mundane and very simple compared to diagnosing a USB stack problem on a system with 4 CPU cores, and an interface to devices that conceal their functionality and use.

So here are a few things that I see as I move across this particular problem. This case may have nothing to do with a deadlock condition that I am hoping to find, but it serves to gain understanding of the inter-relationship of the software on a Linux system.

$ lsusb
Bus 001 Device 005: ID 2304:0208 Pinnacle Systems, Inc. [hex] Studio PCTV USB2
$ cat /proc/bus/input/devices
I: Bus=0018 Vendor=0000 Product=0000 Version=0000
N: Name="i2c IR (i2c IR (EM28XX Pinnacle"
P: Phys=i2c-4/4-0047/ir0
S: Sysfs=/devices/virtual/input/input5
U: Uniq=
H: Handlers=kbd event5 
B: EV=100003
B: KEY=c0014 902040 0 0 0 4 8000 1a8 80000803 9e1680 0 40 12800ffc

$ ls -lA /dev/input/event5
crw-r----- 1 root root 13, 69 2011-04-07 08:23 /dev/input/event5

In this particular case the Pinnacle device will lock up on some odd transient IR signal and continuously send the "up arrow" keyboard code. This is an example of unexpected interaction and undocumented effect. What I am wondering now is how the kernel decides that this event is linked to that signal from the USB device and whether it is a sensible interpretation. Obviously not if it makes my list selection impossible. This could also interact at a higher level in the emulation of "key repeat". So in this case the mouse has nothing to do with the problem, when a menu is selected, the up arrow key keeps being generated and it looks exactly like the mouse scroll wheel is stuck rotating up. Now all I have to do is figure out who is making this mistake, is it Pinnacle, USB, kernel, convenience functions in Gnome, or perhaps it is a feature and not a bug :)

It took me 30 minutes to find this particular bug, but I learned a lot and glossed over much more. These same issues of complex interoperability exhibit themselves in every computer interface. It is not just Linux or MAC or Windows, it is everywhere and complex electronics systems often produce unexpected utility or more often, strange failures.

0 comments:

Contributors

Automated Intelligence

Automated Intelligence
Auftrag der unendlichen LOL katzen