On Wed, 14 Mar 2007, Gordon Messmer wrote: > Alan Stern wrote: > > On Wed, 14 Mar 2007, Gordon Messmer wrote: > > > >> I have tried other mice with this PC. I have an old MS optical > >> Intellimouse (the second worst mouse I've ever used), and a newer > >> revision of the problematic Logitech BD-58, a BT-58. Both other mice > >> work without issue. I've also tried the BD-58 in several other PCs, > >> running the same kernels. Only this mouse, in this PC, with this > >> specific kernel configuration manifests the problem. > > > > That sounds like a hardware problem to me. > > OK. It still bothers me that only a preemptible kernel would be able to > see this hardware problem. I don't know why that should be.
Me neither. For one thing, almost none of the code in uhci-hcd is preemptible. For another, these errors are detected not by software but by the hardware in the USB controller -- which should not be affected at all by preemption. I also don't understand why going to HZ=250 should eliminate the errors. If they are caused by some strange software interaction with the timer interrupt handler then they should be 4 times less frequent than with HZ=1000 -- but still present. > >>> What about if you turn on preemption but not preempt-BKL (shooting in the > >>> dark)? > >> I don't know, but I'll give it a shot. > > No, it still has problems if I disable the preempt-BKL option. Not surprising. The BKL isn't used very much. > I've tried killing off all of the active processes but sshd. The only > thing that stops the errors is killing gpm and Xorg. I guess it's not > surprising that if no processes have /dev/input/mice open, then there's > nothing printed by usbmon? Right. If the mouse's device file isn't held open then the driver doesn't try to talk to it. > I did notice that when gpm opens the device, this appears in usbmon: > > f7c9b840 3783825882 C Ii:003:01 -2 0 > f7c9b840 3806163653 S Ii:003:01 -115 4 < Those two lines differ in time by 23 seconds. Presumably only the last line appeared at the time gpm was started up. > And when it closes the device: > > f7c9b840 3808386058 C Ii:003:01 -2 0 > > Those are normal, presumably? Yes. The second line in the first group shows an input request being submitted, and the only line in the second group shows it being killed. > I'll probably try logging in locally just to see, but even when there's > no disk activity, and gpm is nearly the last userspace process running, > the I/O errors continue at more or less the same interval. Also try booting into single-user mode and starting gpm. (Forget about X; it does so many different things that it's just too confusing.) Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
