Date: Thu, 28 Apr 2005 12:03:27 -0700 From: Julian Elischer <julian@elischer.org> To: Julian Elischer <julian@elischer.org> Cc: freebsd-stable@freebsd.org Subject: Re: USB changes. Message-ID: <4271337F.50401@elischer.org> In-Reply-To: <42712A12.70009@elischer.org> References: <20050428093053.A4DE816A4EB@hub.freebsd.org> <42712A12.70009@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > >> +++ >> >> Currently, I find my P4 hanging just after discovering the parallel >> port and mounting disk; in other words, just here: >> >> but ->only<- when my Logitech USB mouse is plugged in. Now, if I >> unplug it and hit reset (not Ctrl-Alt-Del; the keyboard is frozen) the >> system boots, and I can obtain X w/ a functional mouse. Yesterday, of >> course, prior to the USB change the system did not hang. > try plugging the mouse in again before X starts. >> > > I saw this problem in testing ad THOUGHT I had checked in the fix.. > > Can you confirm that usb.c ends with: > SYSINIT(usb_cold_explore, SI_SUB_INT_CONFIG_HOOKS, SI_ORDER_FIRST, > usb_cold_explore, NULL); > > >> I noticed that some code was changed in between my discovery of the >> hanging and my attempt to fix it: >> >> Apr 27 21:15 subr_bus.c >> >> but this change, and the subsequent world update, did not solve the >> issue of the hanging mouse. > > > the changes that you are refering to include some to defer probing of > the USB 1.1 busses untill after the USB2.0 busses have been configured. > They should probe for the devices at around the same time that the > scsi devices probe. > I'll see if I can duplicate yuor problem.. I tested with several USB 1.1 > devices but a mounse was not amongst them. I tried to duplicate this but failed.. my mose was found just fine.. can you boot with the -v option? i.e. "boot -v" fromt eh loader prompt. > > >> >> See, I know I've only myself to blame for missing the announcement >> and/or starting an upgrade in an interstice between stability and >> apparent instability. But still...test first, deploy later, perhaps? >> >> Kernel bits, had them for a couple of years now: >> >> device uhci >> device ohci >> device ehci >> device usb >> device ugen >> device ums >> device uscanner >> >> With my luck, it's probably not the mouse after all. > what about if you don't have the ums driver loaded? > > I assume it works right if you remove the mouse before booting and > reinsert it after the kernel has booted? >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4271337F.50401>