On Wed, 14 Mar 2007, Gordon Messmer wrote:

> Alan Stern wrote:
> > On Tue, 13 Mar 2007, Gordon Messmer wrote:
> > 
> >> 2.6.20 behaves the same.  If I built a preemptible kernel, (with preempt 
> >> the BKL) and the timer frequency is 1000 HZ, then the mouse has issues. 
> >> If I build a kernel with a lower frequency, or with voluntary 
> >> preemption at any timer frequency, I don't see the problem.
> > 
> > This seems so unlikely, I have trouble believing it's not a hardware
> > problem.   Have you tried using a different mouse?  Or using your mouse on
> > a different computer?
> 
> Maybe it is a hardware problem.  I know that I'm not the only person 
> affected, though none of the other people who are got anywhere with the 
> issue.

You should try writing to them.  Let them know what you've found and see
if your solution can fix their problems.

> 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.

> I could just walk away from the problem, but since the kernel 
> configuration determines whether or not the problem occurs, it looks to 
> me like a bug, and that's the kind of thing I have a hard time leaving 
> behind.

Not at all.  The kernel configuration determines how the hardware will be 
used, but the usage should be carried out in a valid manner no matter what 
the config.  If it isn't, that's a bug.  But if the usage is valid and the 
device still fails to work, it's a hardware problem.

> I guess that, from my point of view, if it's a hardware bug, it'd be 
> nice to be able to tell users who come across the issue what they should 
> be looking for.
> 
> > 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.
> 
> > Do you think the errors are correlated with, say, disk activity?
> 
> I'll try watching iostat and usbmon output at the same time and see if 
> anything looks suspicious.

My thought was that some other sort of electrical activity on the 
motherboard might interfere with the USB signals.  Disk activity was just 
a guess; it could be anything.

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

Reply via email to