Thomas Klausner <tk%giga.or.at@localhost> writes: > I just tried again, on a kernel with EHCI_DEBUG and UCOM_DEBUG. > The device seems to want 115200 baud, so I used > > cu -s 115200 -l /dev/dtyU0 > > which showed some patterns when it worked, perhaps some self tests. > > I booted into single-user mode and after enabling ehci and ucom debug, > I tried a couple of times to start cu, exit it (with "<ENTER>~."), and > power off/on the device again. After about the 5th try, the NetBSD > machine hung. There were no kernel messages when I unplugged or > replugged USB devices, and even the PS/2 keyboard that is attached > didn't work any longer. I didn't really know what to do with such a > stuck system, so I rebooted. > > Any ideas what I should try next time? Turn on more USB debugging, perhaps USBVERBOSE (?) or USBDEBUG (?) or perhaps something in the specific driver. UCOM_DEBUG will probably (I have not read the code) only show things at the ucom layer, and if the problem is lower down in the USB stack, perhaps nothing will appear. >> Did you try on a netbsd-7 system? > > No, I'm only running -current on that machine, and the netbsd-7 > machines I have are remote. If you can boot a kernel and try it without a disk, that might be good to do. But I am really unclear on if that will change anything.
Attachment:
signature.asc
Description: PGP signature