On Wed, Jan 23, 2019 at 12:09:46PM -0700, Keith Busch wrote: > On Wed, Jan 23, 2019 at 08:07:23PM +0100, Lukas Wunner wrote: > > On Wed, Jan 23, 2019 at 07:54:20PM +0100, Lukas Wunner wrote: > > > So I don't see a perfect solution. What device are we talking about > > > anyway? 400 ms is a *long* time. > > > > Also, how exactly does this issue manifest itself: Is it just an > > annoyance that the slot is brought up/down/up or does it not work > > at all? > > Yeah, there is an nvme driver bug that hits a dead lock if you bring > a very quick add-remove sequence. The nvme remove tries to delete IO > resources before the async probe side set them up, so the driver doesn't > actually see that they're invalid. I have a proposed fix, but waiting to > here if it is successful. > > bz: https://bugzilla.kernel.org/show_bug.cgi?id=202081 Hm, there's no full dmesg output attached, so it's not possible to tell what the topology looks like and what the vendor/device ID of 0000:b0:04.0 is. Also, there's only a card present / link up sequence visible in the abridged dmesg output which has a 4 usec delay, but no link up / card present sequence with a 400 msec delay? Thanks, Lukas
