Date: Wed, 08 Nov 2023 22:26:03 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 274974] nvme: resetting controller after mounting a partition Message-ID: <bug-274974-227-7KQcMX5WvY@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-274974-227@https.bugs.freebsd.org/bugzilla/> References: <bug-274974-227@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=3D274974 Warner Losh <imp@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |imp@FreeBSD.org --- Comment #1 from Warner Losh <imp@FreeBSD.org> --- So, the unknown statis is my fault: Forgot to add something to a table. Ign= ore that. But second, this error message happens when we post a transaction to the ca= rd, and then we don't get an interrupt and we timeout. When we timeout, we go l= ook at the status registers for the card and find that the card is gone (reads = as 0xffffffff) (that's the possible hotplug part). With the card reading that, there's no hope: it's game over. So the question is presumably it wasn't like that when we booted the system= . It had to have read these registers, and a lot of others to boot, to find the card, then later we've had to do I/Os to the card when CAM starts up to get= the card to attach (though these are trivial, they'd freak out if they read back all ff's). So what happened between probe time and now to get it into this state? Did a bridge go away, get renumbered, move its memory windows? Was something else mapped in conflict so the fight over the decoding results in ff's? Why didn't the interrupt happen so we got into the timeout path? --=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-274974-227-7KQcMX5WvY>