Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 09 Jan 2019 19:22:44 +0000
From:      bugzilla-noreply@freebsd.org
To:        usb@FreeBSD.org
Subject:   [Bug 176417] [xhci][cam][umass] kernelpanic while removing plugged in disk
Message-ID:  <bug-176417-19105-hLvFxx0cQi@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-176417-19105@https.bugs.freebsd.org/bugzilla/>
References:  <bug-176417-19105@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D176417

Warner Losh <imp@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |imp@FreeBSD.org

--- Comment #6 from Warner Losh <imp@FreeBSD.org> ---
OK. So looking at the stack trace, we get a panic because we're trying to a=
dd
'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 =3D 17, si_name=3Dpass16)
umass-sim0:0: cpuid=3D1
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 w=
hile
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.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-176417-19105-hLvFxx0cQi>