https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176417
Warner Losh <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #6 from Warner Losh <[email protected]> --- OK. So looking at the stack trace, we get a panic because we're trying to add 'pass16' as a device when there's already a pass16 device. This appears to be because the CAM probe device thinks it needs to enumerate it, but the reporter said it was being removed. The actual traceback, in case we lose the dropbox is: da12: xxx MB (xxx 512 byte sectors: <made up geom>) ugen3.2: <Western Digital> at usbus3 (disconnected) umass0: at ushub3 port 1, addr 1 (disconnected) (da12:umass-sim0:0:0:0): lost device - 1 outstanding (da12:umass-sim0:0:0:0): outstanding 0 (da12:panic: make_dev_credv: bad si_name (error = 17, si_name=pass16) umass-sim0:0: cpuid=1 0:KDB: stack backtrace: 0): removing device entry kdb_backtrace panic make_dev_crdev+0x1dc make_dev_0x6f passregister+0x1fe cam_periph_alloc+0x569 passasysnc ... so we have the intermixed output, strongly suggesting one thread removing while the other thread is adding. there's been a fair amount of locking tightening that would prevent the refcount from falling to 0, I think, but I can't be sure. This is purely a CAM problem. I wonder if the original poster can recreate this issue still, or if we can provoke it somehow. But, this CAM problem is because of a random failure during discovery where the drive also goes away and we start the teardown, so from that perspective it's also a USB issue maybe. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "[email protected]"
