Re: [5.0] USB device ignored on boot

[Andreas Wrede <andreas%wrede.ca@localhost>]

On 20-Jul-09, at 02:12 , Iain Hibbert wrote:

> On Sun, 19 Jul 2009, Andreas Wrede wrote:
>
> > I am running NetBSD/amd64 5.0_STABLE on a Gigabyte GA-MA78GM-US2H  
> > motherboard
> > with three uplcom(4) USB to serial adapters.  On boot, only two of  
> > these are
> > recognized, I have to manually un- and re-plug the third adapter in  
> > order to
> > get it attached. (See end of the dmesg output). Un- and re-plugging  
> > is not
> > even a work-around since the machine is running remotely -  
> > unattended.
>
> > I also noticed that the output from the attach of the second  
> > uplcom(4) adapter
> > gets intermixed with other boot messages:
> >
> > [...]
> > ucom0 at uplcom0
> > uplcom1 at uhub1 port 1boot device: wd0
> > root on wd0a dumps on wd0b
> >
> > uplcom1: Prolific Technology Inc. USB-Serial Controller, rev  
> > 1.10/3.00, addr 2
> > [...]
> >
> > Is there a locking issue here?
>
> not because of that at least, the usb attachment runs in a thread  
> and is
> event driven so it would be pretty normal for other things to be  
> going on
> at the same time..

I tried to build a kernel with USB_DEBUG but it won't build.

First:
/u2/netbsd-5.0/src/sys/dev/usb/ulpt.c: In function 'ulpt_do_read':
/u2/netbsd-5.0/src/sys/dev/usb/ulpt.c:763: warning: format '%d'  
expects type 'int', but argument 3 has type 'size_t'

fixing that gets me:

hid.o: In function `hid_get_data':
/u2/netbsd-5.0/src/sys/dev/usb/hid.c:438: undefined reference to  
`uhidevdebug'
/u2/netbsd-5.0/src/sys/dev/usb/hid.c:452: undefined reference to  
`uhidevdebug'
hid.o: In function `hid_clear_local':
/u2/netbsd-5.0/src/sys/dev/usb/hid.c:78: undefined reference to  
`uhidevdebug'
hid.o: In function `hid_get_item':
/u2/netbsd-5.0/src/sys/dev/usb/hid.c:129: undefined reference to  
`uhidevdebug'
/u2/netbsd-5.0/src/sys/dev/usb/hid.c:194: undefined reference to  
`uhidevdebug'
hid.o:/u2/netbsd-5.0/src/sys/dev/usb/hid.c:194: more undefined  
references to `uhidevdebug' follow

which is beyond my hacking level.


> the non attachment problem I don't know about, did it work with a  
> previous
> version?

This is a new machine, starting life with NetBSD 5.

> I don't know if drvctl(8) could be used to work around the problem
> remotely, can you force a bus rescan?


Unfortunately, no:

# drvctl -r uhub1
drvctl: DRVRESCANBUS: Invalid argument

--
    aew