Alan Stern wrote: >> I'll try it again though (with >> irqbalance turned on for consistency's sake) and report back tomorrow >> (probably, it can take a while for the problem to show up). >> > I asked because the log doesn't mention anything to do with the mouse. It > could simply be that the repeated retries for the dying card reader are > using up too much CPU time, not leaving enough for the mouse handler to > run with sufficiently low latency. > Good point. I had an accident with the dmesg output (it's been a long day) but it was interesting when the mouse went strange.
Both cores were pretty well idle, not much going on at all. I checked /proc/interrupts and to my considerable surprise there were no interrupts being delivered for uhci_hcd at all. That is, in this line: 66: 69272 68272 IO-APIC-level uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4 the interrupt counts were going up at all. I'm surprised that the mouse runs at all. I didn't see anything in the dmesg output before I lost it that indicated that there was a problem here, but next time I'll be a little more careful with it. jch ------------------------------------------------------------------------- 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-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
