Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: [5.0] USB device ignored on boot

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.

/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

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


Home | Main Index | Thread Index | Old Index