Date: Wed, 21 Mar 2018 23:41:59 -0600 From: Warner Losh <imp@bsdimp.com> To: Hyun Hwang <hyun@caffeinated.codes> Cc: "Hartmann, O." <ohartmann@walstatt.org>, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: CURRENT r331284: crashing with USB Message-ID: <CANCZdfptgUQ9586s-v0wopNO=_UnavkzBKW-zqzBrKf5aCucUA@mail.gmail.com> In-Reply-To: <CANCZdfoMv_ZwGrZK3n8arLLUEM0hv2OqA%2BSeT6oJiN2%2BKZ0qzA@mail.gmail.com> References: <20180321120710.4eb3b944@hermann> <1521686539.3047757.1311778784.3E60E604@webmail.messagingengine.com> <CANCZdfoMv_ZwGrZK3n8arLLUEM0hv2OqA%2BSeT6oJiN2%2BKZ0qzA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 21, 2018 at 11:17 PM, Warner Losh <imp@bsdimp.com> wrote: > > > On Wed, Mar 21, 2018 at 8:42 PM, Hyun Hwang <hyun@caffeinated.codes> > wrote: > >> On Wednesday, March 21, 2018, 12:07 PM (UTC+0100), "Hartmann, O." < >> ohartmann@walstatt.org> wrote: >> > Hello. >> > >> > Incident: CURRENT r331284 can be brought down reliably with an USB >> > flash drive plugged in and out without mounting or doing anything with >> > it. >> > >> > [...] >> > >> > Does anyone else observe this bug? >> > >> >> Can confirm: whenever I plug my Transcend USB microSD reader into my >> builder (amd64, r331284), the kernel does attach da0 then immediately >> panics and falls down to `db>` prompt. >> > > Do you have a traceback? > actually, can you test https://reviews.freebsd.org/D14792 for me please? The hardware I bought to provoke this wound up in my wife's bags for a trip she's still on and I won't be able to test until Friday (which is why I've been slow to fix this). I hesitate to commit another change I'm sure will fix it on the off chance I'll be wrong again... Occasionally, we'll send a TUR to the device. To make sure that the periph doesn't go away while that's going on, we acquire a reference to the device. When the command completes we release it. The problem is that there's a race that the new asserts I put in uncovered. If we've sent a TUR to the device, but it hasn't completed when damediapoll timeout fires, it will think that we can send a TUR since we cleared the TUR work flag. This bumps the count, and bang! we have two TURs in flight. The Transend USB reader, at least the one I got takes a long time for TUR to return, so this can trigger the race. The above fix simply says that if a TUR is in flight, don't schedule another one. We'll poll again later anyway, and we have the TUR in flight already, so we'll accomplish the goal of TUR even though we chose to omit one we might otherwise do. Warner > Warner > > >> > I can plugin the USB and then unplug it and after two or three times >> doing this, the box goes down. >> >> I did not even have to plug-unplug the reader three times; plug the >> reader in and bam! immediate panic. >> >> AFAIK, r331115 did not have this issue because I was able to update my >> RPi 2 with the very reader from the very builder. >> I managed to salvage kernel binary dump; in case the dump is needed, >> please let me know. >> -- >> Hyun Hwang >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfptgUQ9586s-v0wopNO=_UnavkzBKW-zqzBrKf5aCucUA>