Re: reset low speed USB device using uhci_hcd

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
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel