Date: Thu, 29 Sep 2016 11:20:28 -0700 From: Alexander Motin <mav@FreeBSD.org> To: Hans Petter Selasky <hps@selasky.org>, Jan Henrik Sylvester <me@janh.de> Cc: John Baldwin <jhb@freebsd.org>, FreeBSD-USB Mailing List <freebsd-usb@freebsd.org>, Warner Losh <imp@bsdimp.com> Subject: Re: Status of PCIe Hotplug? Message-ID: <d0255dab-4389-db60-92e4-1d05f46a243d@FreeBSD.org> In-Reply-To: <623f33ff-faaf-02e0-0c6e-725b9e0319e1@selasky.org> References: <D7E110DB-EF6D-41DD-8D69-A021422916FA@sarenet.es> <3c6ab189-aad0-2593-1d3c-f221de294174@janh.de> <b192f906-7e2e-339c-675c-5d6a01e6b7cd@selasky.org> <1635480.htdnZkDgDb@ralph.baldwin.cx> <de8a9add-0e55-6813-ff3b-ae9b335bf33a@selasky.org> <6742d46b-304c-79c9-7233-61cd86ef6542@selasky.org> <ab5b65f4-ff9a-36bb-caf1-17131dcc7aab@janh.de> <623f33ff-faaf-02e0-0c6e-725b9e0319e1@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29.09.2016 02:40, Hans Petter Selasky wrote: > On 09/29/16 11:24, Jan Henrik Sylvester wrote: >> On 09/29/2016 10:17, Hans Petter Selasky wrote: >>> Hi, >>> >>> I created this differential review: >>> >>> https://reviews.freebsd.org/D8070 >>> >>> Jan Henrik: Can you download this patch and try it instead of the one I >>> sent? >>> >>> --HPS >> >> Pulling the naked USB 3.0 ExpressCard without detaching it does not lead >> to a panic anymore. >> >> Anyhow, the scenario that happened frequently on 10.3 for me without a >> panic was pulling the USB 3.0 ExpressCard together with an usb stick. >> That still leads to a panic on 11.0 + D8070: >> >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff80ab48ca >> stack pointer = 0x28:0xfffffe022476ba20 >> frame pointer = 0x28:0xfffffe022476baa0 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 4 (doneq0) >> trap number = 12 >> panic: page fault >> cpuid = 1 >> KDB: stack backtrace: >> #0 0xffffffff80b24107 at kdb_backtrace+0x67 >> #1 0xffffffff80ad93e2 at vpanic+0x182 >> #2 0xffffffff80ad9253 at panic+0x43 >> #3 0xffffffff80fa0d31 at trap_fatal+0x351 >> #4 0xffffffff80fa0f23 at trap_pfault+0x1e3 >> #5 0xffffffff80fa04cc at trap+0x26c >> #6 0xffffffff80f841d1 at calltrap+0x8 >> #7 0xffffffff8030a879 at xpt_release_simq+0x79 >> #8 0xffffffff8030a649 at xpt_async_process+0x409 >> #9 0xffffffff8030b187 at xpt_done_process+0x807 >> #10 0xffffffff8030d916 at xpt_done_td+0x146 >> #11 0xffffffff80a90055 at fork_exit+0x85 >> #12 0xffffffff80f8467e at fork_trampoline+0xe >> > > Hi, > > This panic seems to be an issue within the CAM subsystem. Apparently the > CAM sim detach is not waiting for the release to complete, so functions > inside umass.ko are referred after umass.ko is unloaded. > > imp+mav: Any comments? cam_sim_free() that should be called as part of SIM destruction process waits for all of SIM references to be dropped, that also recursively implies all other references. It worked file last time I tested it, but it was quite a long time ago. I can not say what went wrong here, but I guess that either USB somehow did not wait for cam_sim_free(), or something somewhere did not do reference counting properly, allowing destruction of some still referenced item. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d0255dab-4389-db60-92e4-1d05f46a243d>