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