another hack I just discovered is that if the scsibus<n> has come up ok, then
you can sometimes force the usb device recognition which has stalled with a

scsictl /dev/scsibus0 scan all all # for some <n>, 0 in this instance

this worked for me yesterday, with a USB cd device detected as cd0 after that.

if its only been seen as a umass0 instance, this trick doesn't work. I mailed in
the past about how it would be really neat (tm) if there was a way to tell the
kernel from userspace to allocate the device slots it needs, and then attach
them, because these USB devices really do just wake up again if you frob them
the right way. I think that may be hard at this time in NetBSD though.

oddly, attach/detach cycles AFTER a reboot connected USB is there are usually
ok. I just don't get it. maybe lower level probe logic during kernel init phase
isn't the same as usertime probe in USB.

the bulk-only/BBB appears to be a bit more buggy at the moment than it has been,
I don't know whats changed but a couple of my devices don't recognize well any
more. :-(

And an SD cardreader I used the other day was truly abysmal. unwriteable, and
read phase was crawling. No idea why. But Kudos to Lennart for all his work
keeping this very odd device space alive.

-George

 On Mon, 15 Dec 2003 22:24:20 -0500 Brian Rose <lists@brianrose.net>
wrote:

> Steven M. Bellovin wrote:
> 
> > 
> > There's a bug that often prevents USB drives from being usable unless 
> > the drive (or perhaps some USB drive) is plugged in at boot time.  Try 
> > that, and then see if you can remove/reinsert the plug and get the sd0 
> > message.
> > 
> 
> That did it. Thanks!
> 
> --
> Brian
> 


-- 
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3858 3150  |  Australia
  Fax: +61 7 3858 3199  |  http://www.apnic.net