usb-ohci, ov511, video4linux
I've two problems with the 2.4 series that seems to be related. The common point is the usb-ohci module.
Since 2.4.0, sometimes X loose the usb mouse. X show nothing special in its log and the kernel nothing (I have compiled the usb debug code). This seems to appear when the CPU is mostly used for another application (most of the time the CPU is 100% used when I loose the mouse). If I switch to the console (Ctrl-Alt-F1) and switch back to X, the usb mouse is back. My first thought was that it was a X bug. But the other problem I have seems to indicate this is a kernel problem.
I bought a usb webcam (D-Link DCS100) which uses the ov511 chipset familly. I use the last driver (not the one shipped with the kernel) but I think this is not an issue.
Now It works for a few seconds (minutes) and the application using it freeze. If I kill the app and retsart it, I works for a few seconds (it looks like X and the mouse).
Here also it seems to appear when another app use most of the CPU.
The Xawtv outputs are interesting :
# xawtv This is xawtv-3.68, running on Linux/i586 (2.4.17) /dev/video0 [v4l]: no overlay support v4l-conf had some trouble, trying to continue anyway v4l: timeout (got SIGALRM), hardware/driver problems? ioctl: VIDIOCSYNC(0): Appel système interrompu v4l: timeout (got SIGALRM), hardware/driver problems? ioctl: VIDIOCSYNC(1): Appel système interrompu
What do you think about it ?
I've enabled 'Allow IRQ during APM bios calls'. It seems slighly better for the mouse but not significantly enough to be sure.
I've tried to boot without apm (apm=off) but problems are still there.
Should I try a preemt or low-latency kernel ?
Christophe
Signature · 4 lines
Christophe Barbé <[email protected]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Dogs believe they are human. Cats believe they are God.
Quoted 5 lines · christophe barbé
The Xawtv outputs are interesting :
# xawtv This is xawtv-3.68, running on Linux/i586 (2.4.17) /dev/video0 [v4l]: no overlay support
That's normal.
Quoted 1 line
v4l-conf had some trouble, trying to continue anyway
That too, because of the earlier warning about overlay.
Quoted 4 lines
v4l: timeout (got SIGALRM), hardware/driver problems?
ioctl: VIDIOCSYNC(0): Appel système interrompu
v4l: timeout (got SIGALRM), hardware/driver problems?
ioctl: VIDIOCSYNC(1): Appel système interrompu
xawtv has a very short timeout when it tries to grab frames. It really was made for TV cards, not webcams. You can either change xawtv's libng/grab-v4l.c and edit the line containing #define SYNC_TIMEOUT, or use a program like gqcam that is written especially for slow USB webcams.
The problems with the other USB devices might be caused by the fact that USB webcams will use all the available bandwidth.
Signature · 2 lines
Met vriendelijke groet / with kind regards, Guus Sliepen <[email protected]>
Quoted 19 lines · Guus Sliepen
Quoted 5 lines · christophe barbé
The Xawtv outputs are interesting :
# xawtv This is xawtv-3.68, running on Linux/i586 (2.4.17) /dev/video0 [v4l]: no overlay supportThat's normal.
Quoted 1 line
v4l-conf had some trouble, trying to continue anyway
That too, because of the earlier warning about overlay.
Quoted 4 lines
v4l: timeout (got SIGALRM), hardware/driver problems?
ioctl: VIDIOCSYNC(0): Appel système interrompu
v4l: timeout (got SIGALRM), hardware/driver problems?
ioctl: VIDIOCSYNC(1): Appel système interrompu
Quoted 8 lines
xawtv has a very short timeout when it tries to grab frames. It really was made for TV cards, not webcams. You can either change xawtv's
libng/grab-v4l.cand edit the line containing #defineSYNC_TIMEOUT, or use a program like gqcam that is written especially for slow USB webcams.The problems with the other USB devices might be caused by the fact that USB webcams will use all the available bandwidth.
I have the same problem with gqcam, camstream and gnomemeeting. With xawtv and the debug option, the problem disapears. Perhaps the timeout is increased in this case. I will check the code.
The problem with the usb mouse is there with or without webcam.
Christophe
Quoted 4 lines
Signature · 3 lines
-- Met vriendelijke groet / with kind regards, Guus Sliepen <[email protected]>
Signature · 5 lines
Christophe Barbé <[email protected]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E Dogs come when they're called; cats take a message and get back to you later. --Mary Bly
Quoted 2 lines · christophe barbé
The problem with the usb mouse is there with or without webcam.
Is there any kernel log messages when the mouse "goes away"? It could be a flaky hub that is dropping the connection to your device, or a flaky mouse. I've seen both of these before.
thanks,
greg k-h
Quoted 7 lines · Greg KH
Quoted 2 lines · christophe barbé
The problem with the usb mouse is there with or without webcam.
Is there any kernel log messages when the mouse "goes away"? It could be a flaky hub that is dropping the connection to your device, or a flaky mouse. I've seen both of these before.
I see the mouse problem without hub.
So it could be a flaky mouse.
Is the fact that 'switching to the console and switching back to X restore X' compatible with your idea ?
What sounds strange is that this appears only when CPU is mainly used by others apps.
My idea is a timeout in X (without output : strange) due to a latency.
An important point here is that the mouse works fine with the 2.2 kernel (I should have used 2.2.17 to 2.2.19).
Christophe
Quoted 4 lines
thanks,
greg k-h
Signature · 5 lines
Christophe Barbé <[email protected]> GnuPG FingerPrint: E0F6 FADF 2A5C F072 6AF8 F67A 8F45 2F1E D72C B41E A qui sait comprendre, peu de mots suffisent. (Intelligenti pauca.)