NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/54761: nvme corruption on GENERIC without DIAGNOSTIC



The following reply was made to PR kern/54761; it has been noted by GNATS.

From: David Brownlee <abs%absd.org@localhost>
To: Masanobu SAITOH <msaitoh%execsw.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
	netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/54761: nvme corruption on GENERIC without DIAGNOSTIC
Date: Thu, 19 Dec 2019 01:05:55 +0000

 On Tue, 17 Dec 2019 at 07:09, Masanobu SAITOH <msaitoh%execsw.org@localhost> wrote:
 >
 > >         Obvkously a workaround is to include DIAGNOSTIC
 >
 > sys/dev/ic/nvme.c uses bus_space_barrier().
 > x86's bus_space_barrier() change will be pulled up by the
 > following ticket:
 >
 >         http://releng.netbsd.org/cgi-bin/req-9.cgi?show=566
 >
 >  Could you test with this change?
 
 I've switched from using cgd, and I've not seen corruption, but I have
 seen lockups (still trying to see if I can get into ddb) with the
 previous (problem) kernel .
 
 Testing with Tue Dec 17 16:14:25 UTC 2019 from releng, which includes
 bus_space.c,v 1.41.4.1, and I saw the same type of lockup (stupidly
 did not have ddb.fromconsole=1)
 
 This is with some xterms, firefox, and network over iwm0. I'll leave
 it running overnight to see if it locks up again and if so if I can
 get into ddb...
 
 Thanks
 
 David
 


Home | Main Index | Thread Index | Old Index