Hans Petter Selasky wrote: > Hi Bill ! *trimming the 'history' - its in archives... >> tail -f /var/log/messages >> >> - you will be looking for the message announceing ums & usb load >> >> >> ls /dev/u* before unplugging, Again after re-plugging >> >> - you are looking for /dev/um0 and at least one /dev/usb(n) changing. > > Why should one of the /dev/usbX change ? As an 'opinion' - it should NOT. As an *observation* it/they DID. Specifically, loaded, then unloaded - reloaded on unplug-replug, accompanied by 'message' traffic so reporting. That could be: - mechanical environment: i.e. unreliable USB contacts, 'cold' MB or mouse PCB solder joint, cracked trace on MB or mouse PCB, et al... - electrical environment: flakey power supply, defective mouse PCB, bad cables, more current-drain than the USB port can handle. - firmware environment: firmware on mouse that shuts it OFF or awaits a wake-up initialization, USB port power-saving.. The fact that it works OK after unplug/replug says IF any of the above are involved, it is a transitory, perhaps related to boot-up power drain. - software environment: there are a great many bytes involved, BIOS and OS. That my dmesg.boot showed what was correct, and the one just posted did not, say the BIOS may be involved. The rarity of other similar reports HERE on the list suggest that whatever it is, it is probably not FreeBSD code. Hence my suggestion to see if the symptoms persisted with other mice and/or responded to BIOS setting changes. Coders cannot fix the 'external' world, and should not be asked to do so. >> AFAIK, um0 and usb(n) will load by default. > > What is "um0" ? You mean "ums0" ? > Yes, sorry. >> ..which you might just try, as that 'mad mouse' I experienced was a > > Can you explain what you mean by "mad mouse" ? > Cursor visible, but blinking, position jumping around at a high rate of refresh, responding marginally or not at all to movement of the mouse itself. Was once upon a time a common problem. Long ago fixed in the general case. > By the way there is a "man ums" command that might be interesting. > It was helpful along the way, yes. What was needed OTOH was a 'man CLUEBAT' applied to whomever coded the BIOS! Or a man 'FAULT ISOLATE' before jumping on coders at all.... ;-) BillReceived on Sun Oct 14 2007 - 13:04:12 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:19 UTC