From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31535 invoked from network); 21 Jul 2021 16:49:58 -0000 Received: from 1ess.inri.net (216.126.196.35) by inbox.vuxu.org with ESMTPUTF8; 21 Jul 2021 16:49:58 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 1ess; Wed Jul 21 12:43:14 -0400 2021 Message-ID: Date: Wed, 21 Jul 2021 18:43:04 +0200 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: virtualized dependency service-oriented framework Subject: Re: [9front] nvme driver crashy on a shitty OEM drive Reply-To: 9front@9front.org Precedence: bulk that linux thread hints on some physical layer issues... they'r trying to reset the whole pci bus to force it to recover and tuning some timing delay loops... we do not have a pci error handler except generic machine check handler, so we might just freeze up instead of seeing the errors linux prints. it is really odd, especially as it starts to not hang when you boot with usb disk inserted. it might well be a timing dependency right there. for one, i'd suggest to take the ahci out of the equation by setting *noahci=1 in 9boot > prompt before booting the kernel. then maybe take a look at the linux quirk routine in detail. (i have not dont yet). -- cinap