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
--
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.
On Sun, Jan 20, 2002 at 10:41:19AM -0500, christophe barb? wrote:
> 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.
> v4l-conf had some trouble, trying to continue anyway
That too, because of the earlier warning about overlay.
> 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.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <[email protected]>
On Sun, Jan 20, 2002 at 05:22:58PM +0100, Guus Sliepen wrote:
> On Sun, Jan 20, 2002 at 10:41:19AM -0500, christophe barb? wrote:
>
> > 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.
>
> > v4l-conf had some trouble, trying to continue anyway
>
> That too, because of the earlier warning about overlay.
>
> > 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.
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
>
> --
> Met vriendelijke groet / with kind regards,
> Guus Sliepen <[email protected]>
--
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
On Sun, Jan 20, 2002 at 12:08:37PM -0500, christophe barb? wrote:
>
> 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
On Sun, Jan 20, 2002 at 02:54:23PM -0800, Greg KH wrote:
> On Sun, Jan 20, 2002 at 12:08:37PM -0500, christophe barb? wrote:
> >
> > 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
>
> thanks,
>
> greg k-h
--
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.)