USB changes.
Julian Elischer
julian at elischer.org
Thu Apr 28 12:55:32 PDT 2005
Joe Altman wrote:
>On Thu, Apr 28, 2005 at 11:23:14AM -0700, Julian Elischer wrote:
>
>
>>>+++
>>>
>>>Currently, I find my P4 hanging just after discovering the parallel
>>>port and mounting disk; in other words, just here:
>>>
>>>ppc0: parallel port not found.
>>>ad0: 28629MB <ST330620A> [58168/16/63] at ata0-master UDMA100
>>>
>>>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.
>>>
>>>
>>>
>>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);
>>
>>
>
>Hmmm...
>
>/usr/src/lib/libusbhid/
>
>Nope..
>
>
/usr/sr/sys/dev/usb/usb.c
>Aha...maybe this is it:
>
>/usr/src/usr.sbin/usbd/
>
>
nope
>ll /usr/src/usr.sbin/usbd/
>
>2734320 -rw-r--r-- 1 root wheel 169 Apr 25 2001 Makefile
>2738254 -rw-r--r-- 1 root wheel 4460 Jun 22 2003 usbd.8
>2736938 -rw-r--r-- 1 root wheel 30079 Nov 29 2003 usbd.c
>2737339 -rw-r--r-- 1 root wheel 5046 Aug 27 2004 usbd.conf.5
>
>Is that the one?
>
>Here is a part of 'tail -25' on the file, showing the bottom:
>
>/* check the event queue */
> if (handle_events && (FD_ISSET(fd, &r) || error == 0))
> {
> if (verbose >= 2)
> printf("%s: processing event queue
> %son %s\n",
> __progname,
> (error? "":"due to timeout "),
> USBDEV);
> process_event_queue(fd);
> }
> }
>}
>
>So no, this file doesn't end in what you ask; I can't see anywhere
>else it might live; is there some other usbd.c you need?
>
>
>
>>>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.
>>
>>
>
>Ah...okay; well, I was in the dark anyway, may as well whistle.
>
>
theoretically it may be that the usb code doesn't like being run at that
time..
I'll try duplicate your setup more closely.
is it a uhci or ohci controller?
I just realised I did most of my testing with ohci..
will hunt down a uhci machine to test with.
>
>
>>I'll see if I can duplicate yuor problem.. I tested with several USB 1.1
>>devices but a mounse was not amongst them.
>>
>>
>
>Okay; it may be a one off, relative to me only, as I've seen no other
>indications of issues. I am behind on my list reading, though.
>
>
>
>>I assume it works right if you remove the mouse before booting and reinsert
>>it after the kernel has booted?
>>
>>
>
>Yes; once I have a console, the mouse is detected:
>
>ums0: Logitech USB Receiver, rev 1.10/23.02, addr 2, iclass 3/1
>ums0: 7 buttons and Z dir.
>
>Then, it works in X just fine; I forgot to test it on the console.
>
>
shouldn't matter..
More information about the freebsd-stable
mailing list