I'm compiling a new kernel with those options as I type. Yes, this is
very much reproduceable. If you look at the dmesg you will also see
the previous reboot for the same reason but with a different device -
a WLAN stick that also includes some mass storage for the windows
driver and probably another for the mini-sd or whatever card fits in
The Pendrive I then used is a 64MB (yes, megabytes) so from that you
can probably guess how ancient that thing is so it should not have any
new and fancy options aka quirks ;).
What I haven't tried yet is simply loading the module while no device
I'll try that when I have the new kernel booted. It will take some
time though since this is a 500MHz Geode..
I think I also saw a few other bugreports related to this issue maybe
someone else already included a backtrace.
Thanks for looking into this,
Zitat von Hans Petter Selasky <hsela...@c2i.net>:
This sounds like a missing MODULE_DEPEND() issue or your pendrive is
an error code to some of the SCSI commands which is not handled properly.
Could you add these options to the kernel config file:
options KDB # Kernel debugger related code
options KDB_TRACE # Print a stack trace for a panic
Then get full backtrace.
Is this issue reproducable. I cannot reproduce over here using a 9-stable
GENERIC kernel without "device umass".
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"