NetBSD Problem Report #53096

From www@NetBSD.org  Tue Mar 13 18:12:22 2018
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 0E02C7A180
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 13 Mar 2018 18:12:22 +0000 (UTC)
Message-Id: <20180313181218.438A57A22E@mollari.NetBSD.org>
Date: Tue, 13 Mar 2018 18:12:18 +0000 (UTC)
From: rcbixler@nyx.net
Reply-To: rcbixler@nyx.net
To: gnats-bugs@NetBSD.org
Subject: netbsd-8 crash on heavy disk I/O
X-Send-Pr-Version: www-1.0

>Number:         53096
>Category:       kern
>Synopsis:       netbsd-8 crash on heavy disk I/O
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    hannken
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 13 18:15:00 +0000 2018
>Closed-Date:    Sat May 12 20:23:22 +0000 2018
>Last-Modified:  Sat May 12 20:23:22 +0000 2018
>Originator:     Roy Bixler
>Release:        netbsd-8
>Organization:
>Environment:
NetBSD rbixler.britannica.net 8.0_BETA NetBSD 8.0_BETA (GENERIC) #2: Wed Mar  7 15:05:15 CST 2018  rcb@rbixler.britannica.net:/usr/src/obj/sys/arch/amd64/compile/GENERIC amd64
>Description:
System often crashes under heavy disk I/O.  Examples are a "find" command on "/usr" or a "cvs up" of the NetBSD-8 source tree.  Usually, I only see the system reboot, but last time it happened, I got a crash dump.  Here is the backtrace from it:

crash> bt
_KERNEL_OPT_NARCNET() at 0
ostype() at ostype+0xba183
vpanic() at vpanic+0x149
vstate_assert_get() at vstate_assert_get
lru_requeue() at lru_requeue
vrelel() at vrelel+0x1e2
sys_chdir() at sys_chdir+0x4a
syscall() at syscall+0x1d8
--- syscall (number 12) ---
7d5e45481e4a:

Drive where it occurs is wd0.  Here is "dmesg" output:

Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 8.0_BETA (GENERIC) #2: Wed Mar  7 15:05:15 CST 2018
        rcb@rbixler.britannica.net:/usr/src/obj/sys/arch/amd64/compile/GENERIC
total memory = 8104 MB
avail memory = 7847 MB
timecounter: Timecounters tick every 10.000 msec
Kernelized RAIDframe activated
running cgd selftest aes-xts-256 aes-xts-512 done
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
Generic PC
mainbus0 (root)
ACPI: RSDP 0x00000000000F0470 000024 (v02 DELL  )
ACPI: XSDT 0x00000000BADD2070 00005C (v01 DELL   WN09     01072009 AMI  00010013)
ACPI: FACP 0x00000000BADD8A58 0000F4 (v04 DELL   WN09     01072009 AMI  00010013)
ACPI: DSDT 0x00000000BADD2158 0068FD (v02 DELL   WN09     00000000 INTL 20051117)
ACPI: FACS 0x00000000BAE14F80 000040
ACPI: APIC 0x00000000BADD8B50 000072 (v03 DELL   WN09     01072009 AMI  00010013)
ACPI: SSDT 0x00000000BADD8BC8 000102 (v01 AMICPU PROC     00000001 MSFT 03000001)
ACPI: MCFG 0x00000000BADD8CD0 00003C (v01 DELL   WN09     01072009 MSFT 00000097)
ACPI: SLIC 0x00000000BADD8D10 000176 (v01 DELL   WN09     01072009 AMI  00010013)
ACPI: HPET 0x00000000BADD8E88 000038 (v01 DELL   WN09     01072009 AMI. 00000004)
ACPI: OSFR 0x00000000BADD8EC0 000082 (v01 DELL   M08      07DC0512 ASL  00000061)
ACPI: Executed 1 blocks of module-level executable AML code
ACPI: 2 ACPI AML tables successfully acquired and loaded
ioapic0 at mainbus0 apid 0: pa 0xfec00000, version 0x20, 24 pins
cpu0 at mainbus0 apid 0
cpu0: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, id 0x206a7
cpu0: package 0, core 0, smt 0
cpu1 at mainbus0 apid 2
cpu1: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, id 0x206a7
cpu1: package 0, core 1, smt 0
cpu2 at mainbus0 apid 4
cpu2: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, id 0x206a7
cpu2: package 0, core 2, smt 0
cpu3 at mainbus0 apid 6
cpu3: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, id 0x206a7
cpu3: package 0, core 3, smt 0
acpi0 at mainbus0: Intel ACPICA 20170303
acpi0: X/RSDT: OemId <DELL  , WN09   ,01072009>, AslId <AMI ,00010013>
acpi0: MCFG: segment 0, bus 0-255, address 0x00000000e0000000
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0xFFFFFE823DC84410 00038C (v01 AMI    IST      00000001 MSFT 03000001)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0xFFFFFE810E78A680 000084 (v01 AMI    CST      00000001 MSFT 03000001)
acpi0: SCI interrupting at int 9
timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000
hpet0 at acpi0: high precision event timer (mem 0xfed00000-0xfed00400)
timecounter: Timecounter "hpet0" frequency 14318180 Hz quality 2000
MCH (PNP0C01) at acpi0 not configured
SIO1 (PNP0C02) at acpi0 not configured
attimer1 at acpi0 (TMR, PNP0100): io 0x40-0x43 irq 0
pcppi1 at acpi0 (SPKR, PNP0800): io 0x61
spkr0 at pcppi1: PC Speaker
midi0 at pcppi1: PC speaker
sysbeep0 at pcppi1
RMSC (PNP0C02) at acpi0 not configured
PCH (PNP0C01) at acpi0 not configured
CWDT (INT3F0D) at acpi0 not configured
acpibut0 at acpi0 (PWRB, PNP0C0C-170): ACPI Power Button
RMEM (PNP0C01) at acpi0 not configured
OMSC (PNP0C02) at acpi0 not configured
ACPI: Enabled 3 GPEs in block 00 to 3F
attimer1: attached to pcppi1
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0: vendor 8086 product 0100 (rev. 0x09)
i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 0102 (rev. 0x09)
drm: Memory usable by graphics device = 2048M
drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
drm: Driver supports precise vblank timestamp query.
i915drmkms0: interrupting at ioapic0 pin 16 (i915)
drm: Wrong MCH_SSKPD value: 0x16040307
drm: This can cause pipe underruns and display issues.
drm: Please upgrade your BIOS to fix this.
intelfb0 at i915drmkms0
i915drmkms0: info: registered panic notifier
intelfb0: framebuffer at 0xffff80008e7b7000, size 1920x1080, depth 32, stride 7680
wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation)
wsmux1: connecting to wsdisplay0
vendor 8086 product 1c3a (miscellaneous communications, revision 0x04) at pci0 dev 22 function 0 not configured
ehci0 at pci0 dev 26 function 0: vendor 8086 product 1c2d (rev. 0x05)
ehci0: interrupting at ioapic0 pin 17
ehci0: BIOS has given up ownership
ehci0: EHCI version 1.0
usb0 at ehci0: USB revision 2.0
hdaudio0 at pci0 dev 27 function 0: HD Audio Controller
hdaudio0: interrupting at msi0 vec 0
hdafg0 at hdaudio0: vendor 14f1 product 50a1
hdafg0: DAC00 2ch: Speaker [Jack]
hdafg0: ADC01 2ch: Mic In [Jack]
hdafg0: ADC02 2ch: Line In [Jack], Mic In [Jack]
hdafg0: DAC03 2ch: HP Out [Jack]
hdafg0: 2ch/2ch 44100Hz 48000Hz 96000Hz PCM16 PCM20 PCM24 AC3
audio0 at hdafg0: full duplex, playback, capture, mmap, independent
hdafg0: Virtual format configured - Format SLINEAR, precision 16, channels 2, frequency 48000
hdafg0: Latency: 128 milliseconds
spkr1 at audio0: PC Speaker (synthesized)
hdafg1 at hdaudio0: vendor 8086 product 2805
hdafg1: DP00 8ch: Digital Out [Jack]
hdafg1: 8ch/0ch 48000Hz PCM16*
ppb0 at pci0 dev 28 function 0: vendor 8086 product 1c10 (rev. 0xb5)
ppb0: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x1 @ 5.0GT/s
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
ppb1 at pci0 dev 28 function 4: vendor 8086 product 1c18 (rev. 0xb5)
ppb1: PCI Express capability version 2 <Root Port of PCI-E Root Complex> x1 @ 5.0GT/s
ppb1: link is x1 @ 2.5GT/s
pci2 at ppb1 bus 2
pci2: i/o space, memory space enabled, rd/line, wr/inv ok
re0 at pci2 dev 0 function 0: RealTek 8168/8111 PCIe Gigabit Ethernet (rev. 0x06)
re0: interrupting at msi1 vec 0
re0: Ethernet address d4:be:d9:e7:46:c4
re0: using 256 tx descriptors
rgephy0 at re0 phy 7: RTL8169S/8110S/8211 1000BASE-T media interface, rev. 5
rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
ehci1 at pci0 dev 29 function 0: vendor 8086 product 1c26 (rev. 0x05)
ehci1: interrupting at ioapic0 pin 23
ehci1: BIOS has given up ownership
ehci1: EHCI version 1.0
usb1 at ehci1: USB revision 2.0
ichlpcib0 at pci0 dev 31 function 0: vendor 8086 product 1c5c (rev. 0x05)
timecounter: Timecounter "ichlpcib0" frequency 3579545 Hz quality 1000
ichlpcib0: 24-bit timer
tco0 at ichlpcib0: TCO (watchdog) timer configured.
tco0: Min/Max interval 1/367 seconds
piixide0 at pci0 dev 31 function 2: Intel 6 Series Serial ATA Controller (rev. 0x05)
piixide0: bus-master DMA support present
piixide0: primary channel configured to compatibility mode
piixide0: primary channel interrupting at ioapic0 pin 14
atabus0 at piixide0 channel 0
piixide0: secondary channel configured to compatibility mode
piixide0: secondary channel interrupting at ioapic0 pin 15
atabus1 at piixide0 channel 1
ichsmb0 at pci0 dev 31 function 3: vendor 8086 product 1c22 (rev. 0x05)
ichsmb0: interrupting at ioapic0 pin 18
iic0 at ichsmb0: I2C bus
piixide1 at pci0 dev 31 function 5: Intel 6 Series Serial ATA Controller (rev. 0x05)
piixide1: bus-master DMA support present
piixide1: primary channel wired to native-PCI mode
piixide1: using ioapic0 pin 19 for native-PCI interrupt
atabus2 at piixide1 channel 0
piixide1: secondary channel wired to native-PCI mode
atabus3 at piixide1 channel 1
isa0 at ichlpcib0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
pckbc0 at isa0 port 0x60-0x64
acpicpu0 at cpu0: ACPI CPU
acpicpu0: C1: FFH, lat   1 us, pow  1000 mW
acpicpu0: C3: FFH, lat 104 us, pow   350 mW, bus master check
acpicpu0: P0: FFH, lat  10 us, pow 95000 mW, 3101 MHz, turbo boost
acpicpu0: P1: FFH, lat  10 us, pow 95000 mW, 3100 MHz
acpicpu0: P2: FFH, lat  10 us, pow 87000 mW, 2900 MHz
acpicpu0: P3: FFH, lat  10 us, pow 79000 mW, 2700 MHz
acpicpu0: P4: FFH, lat  10 us, pow 71000 mW, 2500 MHz
acpicpu0: P5: FFH, lat  10 us, pow 64000 mW, 2300 MHz
acpicpu0: P6: FFH, lat  10 us, pow 57000 mW, 2100 MHz
acpicpu0: P7: FFH, lat  10 us, pow 51000 mW, 1900 MHz
acpicpu0: P8: FFH, lat  10 us, pow 44000 mW, 1700 MHz
acpicpu0: P9: FFH, lat  10 us, pow 41000 mW, 1600 MHz
acpicpu0: T0: FFH, lat   1 us, pow  1000 mW, 100 %
acpicpu0: T1: FFH, lat   1 us, pow   875 mW,  88 %
acpicpu0: T2: FFH, lat   1 us, pow   750 mW,  75 %
acpicpu0: T3: FFH, lat   1 us, pow   625 mW,  63 %
acpicpu0: T4: FFH, lat   1 us, pow   500 mW,  50 %
acpicpu0: T5: FFH, lat   1 us, pow   375 mW,  38 %
acpicpu0: T6: FFH, lat   1 us, pow   250 mW,  25 %
acpicpu0: T7: FFH, lat   1 us, pow   125 mW,  13 %
coretemp0 at cpu0: thermal sensor, 1 C resolution, Tjmax=99
acpicpu1 at cpu1: ACPI CPU
coretemp1 at cpu1: thermal sensor, 1 C resolution, Tjmax=99
acpicpu2 at cpu2: ACPI CPU
coretemp2 at cpu2: thermal sensor, 1 C resolution, Tjmax=99
acpicpu3 at cpu3: ACPI CPU
coretemp3 at cpu3: thermal sensor, 1 C resolution, Tjmax=99
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
timecounter: Timecounter "TSC" frequency 3093103400 Hz quality 3000
IPsec: Initialized Security Association Processing.
uhub0 at usb0: vendor 8086 (0x8086) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub1 at usb1: vendor 8086 (0x8086) EHCI root hub (0000), class 9/0, rev 2.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
drm: Enabling RC6 states: RC6 on, RC6p off, RC6pp off
uhub2 at uhub0 port 1: vendor 8087 (0x8087) product 0024 (0x24), class 9/0, rev 2.00/0.00, addr 2
uhub2: single transaction translator
uhub3 at uhub1 port 1: vendor 8087 (0x8087) product 0024 (0x24), class 9/0, rev 2.00/0.00, addr 2
uhub3: single transaction translator
uhub2: 4 ports with 4 removable, self powered
uhub3: 6 ports with 6 removable, self powered
wd0 at atabus0 drive 0
wd0: <ADATA SU800>
wd0: drive supports 2-sector PIO transfers, LBA48 addressing
wd0: 119 GB, 248085 cyl, 16 head, 63 sec, 512 bytes/sect x 250069680 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd0(piixide0:0:0): using PIO mode 4, Ultra-DMA mode 6 (Ultra/133) (using DMA)
umass0 at uhub3 port 1 configuration 1 interface 0
umass0: Generic (0x58f) Mass Storage Device (0x6362), rev 2.00/1.00, addr 3
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 4 luns per target
sd0 at scsibus0 target 0 lun 0: <Generic-, SD/MMC, 1.00> disk removable
sd0: drive offline
uhidev0 at uhub2 port 3 configuration 1 interface 0
uhidev0: Microsoft (0x45e) Microsoft Basic Optical Mouse v2.0 (0xcb), rev 1.10/1.04, addr 3, iclass 3/1
sd1 at scsibus0 target 0 lun 1: <Generic-, Compact Flash, 1.01> disk removable
sd1: drive offline
ums0 at uhidev0: 3 buttons and Z dir
wsmouse0 at ums0 mux 0
sd2 at scsibus0 target 0 lun 2: <Generic-, SM/xD Picture, 1.02> disk removable
sd2: drive offline
sd3 at scsibus0 target 0 lun 3: <Generic-, MS/MS-Pro, 1.03> disk removable
sd3: drive offline
uhidev1 at uhub2 port 4 configuration 1 interface 0
uhidev1: Microsoft (0x45e) Wired Keyboard 600 (0x750), rev 1.10/1.10, addr 4, iclass 3/1
ukbd0 at uhidev1: 8 Variable keys, 6 Array codes
wskbd0 at ukbd0: console keyboard, using wsdisplay0
uhidev2 at uhub2 port 4 configuration 1 interface 1
uhidev2: Microsoft (0x45e) Wired Keyboard 600 (0x750), rev 1.10/1.10, addr 4, iclass 3/0
uhidev2: 3 report ids
uhid0 at uhidev2 reportid 1: input=7, output=0, feature=0
uhid1 at uhidev2 reportid 3: input=1, output=0, feature=0
atapibus0 at atabus1: 2 targets
cd0 at atapibus0 drive 0: <TSSTcorp DVD+/-RW SH-216BB, R8U46GGC502G0R, D100> cdrom removable
cd0: 32-bit data port
cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100)
cd0(piixide0:1:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using DMA)
pad0: outputs: 44100Hz, 16-bit, stereo
audio1 at pad0: half duplex, playback, capture, mmap
pad0: Virtual format configured - Format SLINEAR, precision 16, channels 2, frequency 44100
pad0: Latency: 139 milliseconds
spkr2 at audio1: PC Speaker (synthesized)
boot device: wd0
root on wd0a dumps on wd0b
root file system type: ffs
kern.module.path=/stand/amd64/8.0/modules
wsdisplay0: screen 1 added (default, vt100 emulation)
wsdisplay0: screen 2 added (default, vt100 emulation)
wsdisplay0: screen 3 added (default, vt100 emulation)
wsdisplay0: screen 4 added (default, vt100 emulation)
cpu 0: ucode 0x1a->0x29
cpu 1: ucode 0x1a->0x29
cpu 2: ucode 0x1a->0x29
cpu 3: ucode 0x1a->0x29


>How-To-Repeat:
Run a "find" command on "/usr" or do a "cvs up" on a large source tree like netbsd-8.
>Fix:
n/a

>Release-Note:

>Audit-Trail:

From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/53096: netbsd-8 crash on heavy disk I/O
Date: Sun, 18 Mar 2018 17:45:41 +0100

 The backtrace is a bit misleading, it really is:

 sys_chdir() -> vrele() -> vrelel() -> vstate_assert_change() -> vnpanic()

 This matches the panic from dmesg:

 ...
 cpu 0: ucode 0x1a->0x29
 cpu 1: ucode 0x1a->0x29
 cpu 2: ucode 0x1a->0x29
 cpu 3: ucode 0x1a->0x29
 vnode 0xfffffe82137bde70 flags 0x30<MPSAFE,LOCKSWORK>
   tag VT_UFS(1) type VDIR(2) mount 0xfffffe823dbb2008 typedata 0x0
   usecount 1 writecount 0 holdcount 1
   size 200 writesize 200 numoutput 0
   data 0xfffffe8213cce900 lock 0xfffffe82137bdfa0
   state BLOCKED key(0xfffffe823dbb2008 8) b1 c8 3a 00 00 00 00 00
   lrulisthd 0xffffffff814c6400
   tag VT_UFS, ino 3852465, on dev 0, 0 flags 0x0, nlink 3
   mode 040755, owner 1001, group 0, size 512
 panic: BLOCKED to LOADED with usecount 2 at vrelel:783

 Here vrelel() is:

 767  VSTATE_CHANGE(vp, VS_LOADED, VS_BLOCKED);
 768  mutex_exit(vp->v_interlock);
 ...
 778  recycle = false;
 779  VOP_INACTIVE(vp, &recycle);
 780  if (!recycle)
 781          VOP_UNLOCK(vp);
 782  mutex_enter(vp->v_interlock);
 783  VSTATE_CHANGE(vp, VS_BLOCKED, VS_LOADED);

 and VSTATE_CHANGE() expands to vstate_assert_change(), which is:

 315  KASSERTMSG(mutex_owned(vp->v_interlock), "at %s:%d", func, line);

 328  if ((from == VS_BLOCKED || to == VS_BLOCKED) && vp->v_usecount != 1)
 329          vnpanic(vp, "%s to %s with usecount %d at %s:%d",

 So the usecount of a blocked vnode with interlock held changed from 1,
 it is "2" on the call to vnpanic() and "1" when vnpanic prints
 the vnode.

 As vcache_vget() and vcache_tryvget() either error out or wait if the current
 state is BLOCKED it could be a vref() without a prior reference.

 Please try the attached patch to see if one of these assertions fire.

 diff -r 13173af16202 -r 0a76936d2ed0 sys/kern/vfs_vnode.c
 --- sys/kern/vfs_vnode.c
 +++ sys/kern/vfs_vnode.c
 @@ -670,11 +670,22 @@ static inline bool
  vtryrele(vnode_t *vp)
  {
  	u_int use, next;
 +	vnode_impl_t *vip = VNODE_TO_VIMPL(vp);

  	for (use = vp->v_usecount;; use = next) {
  		if (use == 1) {
  			return false;
  		}
 +
 +		membar_enter();
 +		if (vip->vi_state == VS_BLOCKED) {
 +			mutex_enter(vp->v_interlock);
 +			if (vip->vi_state == VS_BLOCKED) {
 +				vnpanic(vp, "vtryrele on BLOCKED vnode");
 +			}
 +			mutex_exit(vp->v_interlock);
 +		}
 +
  		KASSERT(use > 1);
  		next = atomic_cas_uint(&vp->v_usecount, use, use - 1);
  		if (__predict_true(next == use)) {
 @@ -865,6 +876,16 @@ vrele_async(vnode_t *vp)
  void
  vref(vnode_t *vp)
  {
 +	vnode_impl_t *vip = VNODE_TO_VIMPL(vp);
 +
 +	membar_enter();
 +	if (vip->vi_state == VS_BLOCKED) {
 +		mutex_enter(vp->v_interlock);
 +		if (vip->vi_state == VS_BLOCKED) {
 +			vnpanic(vp, "vref on BLOCKED vnode");
 +		}
 +		mutex_exit(vp->v_interlock);
 +	}

  	KASSERT(vp->v_usecount != 0);


From: Roy Bixler <rcbixler@nyx.net>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/53096: netbsd-8 crash on heavy disk I/O
Date: Mon, 19 Mar 2018 06:08:21 -0600

 On Sun, Mar 18, 2018 at 04:50:01PM +0000, J. Hannken-Illjes wrote:
 > The following reply was made to PR kern/53096; it has been noted by GNATS.
 > 
 > From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: kern/53096: netbsd-8 crash on heavy disk I/O
 > Date: Sun, 18 Mar 2018 17:45:41 +0100
 > 
 >  The backtrace is a bit misleading, it really is:
 >  
 >  sys_chdir() -> vrele() -> vrelel() -> vstate_assert_change() -> vnpanic()
 >  
 >  This matches the panic from dmesg:
 >  
 >  ...
 >  cpu 0: ucode 0x1a->0x29
 >  cpu 1: ucode 0x1a->0x29
 >  cpu 2: ucode 0x1a->0x29
 >  cpu 3: ucode 0x1a->0x29
 >  vnode 0xfffffe82137bde70 flags 0x30<MPSAFE,LOCKSWORK>
 >    tag VT_UFS(1) type VDIR(2) mount 0xfffffe823dbb2008 typedata 0x0
 >    usecount 1 writecount 0 holdcount 1
 >    size 200 writesize 200 numoutput 0
 >    data 0xfffffe8213cce900 lock 0xfffffe82137bdfa0
 >    state BLOCKED key(0xfffffe823dbb2008 8) b1 c8 3a 00 00 00 00 00
 >    lrulisthd 0xffffffff814c6400
 >    tag VT_UFS, ino 3852465, on dev 0, 0 flags 0x0, nlink 3
 >    mode 040755, owner 1001, group 0, size 512
 >  panic: BLOCKED to LOADED with usecount 2 at vrelel:783
 >  
 >  Here vrelel() is:
 >  
 >  767  VSTATE_CHANGE(vp, VS_LOADED, VS_BLOCKED);
 >  768  mutex_exit(vp->v_interlock);
 >  ...
 >  778  recycle = false;
 >  779  VOP_INACTIVE(vp, &recycle);
 >  780  if (!recycle)
 >  781          VOP_UNLOCK(vp);
 >  782  mutex_enter(vp->v_interlock);
 >  783  VSTATE_CHANGE(vp, VS_BLOCKED, VS_LOADED);
 >  
 >  and VSTATE_CHANGE() expands to vstate_assert_change(), which is:
 >  
 >  315  KASSERTMSG(mutex_owned(vp->v_interlock), "at %s:%d", func, line);
 >  
 >  328  if ((from == VS_BLOCKED || to == VS_BLOCKED) && vp->v_usecount != 1)
 >  329          vnpanic(vp, "%s to %s with usecount %d at %s:%d",
 >  
 >  So the usecount of a blocked vnode with interlock held changed from 1,
 >  it is "2" on the call to vnpanic() and "1" when vnpanic prints
 >  the vnode.
 >  
 >  As vcache_vget() and vcache_tryvget() either error out or wait if the current
 >  state is BLOCKED it could be a vref() without a prior reference.
 >  
 >  Please try the attached patch to see if one of these assertions fire.
 >  
 >  diff -r 13173af16202 -r 0a76936d2ed0 sys/kern/vfs_vnode.c
 >  --- sys/kern/vfs_vnode.c
 >  +++ sys/kern/vfs_vnode.c
 >  @@ -670,11 +670,22 @@ static inline bool
 >   vtryrele(vnode_t *vp)
 >   {
 >   	u_int use, next;
 >  +	vnode_impl_t *vip = VNODE_TO_VIMPL(vp);
 >   
 >   	for (use = vp->v_usecount;; use = next) {
 >   		if (use == 1) {
 >   			return false;
 >   		}
 >  +
 >  +		membar_enter();
 >  +		if (vip->vi_state == VS_BLOCKED) {
 >  +			mutex_enter(vp->v_interlock);
 >  +			if (vip->vi_state == VS_BLOCKED) {
 >  +				vnpanic(vp, "vtryrele on BLOCKED vnode");
 >  +			}
 >  +			mutex_exit(vp->v_interlock);
 >  +		}
 >  +
 >   		KASSERT(use > 1);
 >   		next = atomic_cas_uint(&vp->v_usecount, use, use - 1);
 >   		if (__predict_true(next == use)) {
 >  @@ -865,6 +876,16 @@ vrele_async(vnode_t *vp)
 >   void
 >   vref(vnode_t *vp)
 >   {
 >  +	vnode_impl_t *vip = VNODE_TO_VIMPL(vp);
 >  +
 >  +	membar_enter();
 >  +	if (vip->vi_state == VS_BLOCKED) {
 >  +		mutex_enter(vp->v_interlock);
 >  +		if (vip->vi_state == VS_BLOCKED) {
 >  +			vnpanic(vp, "vref on BLOCKED vnode");
 >  +		}
 >  +		mutex_exit(vp->v_interlock);
 >  +	}
 >   
 >   	KASSERT(vp->v_usecount != 0);
 >   

 Should I apply the patch to current netbsd-8 or the version on which I
 could reproduce the crashes?  I ask because I've updated a couple of
 times since my report and I haven't seen the crashes since the
 updates.

 -- 
 Roy Bixler <rcbixler@nyx.net>
 "The fundamental principle of science, the definition almost, is this: the
 sole test of the validity of any idea is experiment."
 -- Richard P. Feynman

From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/53096: netbsd-8 crash on heavy disk I/O
Date: Mon, 19 Mar 2018 13:57:31 +0100

 > On 19. Mar 2018, at 13:15, Roy Bixler <rcbixler@nyx.net> wrote:
 <snip>
 > 
 > Should I apply the patch to current netbsd-8 or the version on which I
 > could reproduce the crashes?  I ask because I've updated a couple of
 > times since my report and I haven't seen the crashes since the
 > updates.

 The version that crashes please.

 Which version (release/time stamp) did crash and which version did not?

 --
 J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)

From: Roy Bixler <rcbixler@nyx.net>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/53096: netbsd-8 crash on heavy disk I/O
Date: Mon, 19 Mar 2018 07:39:05 -0600

 On Mon, Mar 19, 2018 at 01:00:01PM +0000, J. Hannken-Illjes wrote:
 > The following reply was made to PR kern/53096; it has been noted by GNATS.
 > 
 > From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: kern/53096: netbsd-8 crash on heavy disk I/O
 > Date: Mon, 19 Mar 2018 13:57:31 +0100
 > 
 >  > On 19. Mar 2018, at 13:15, Roy Bixler <rcbixler@nyx.net> wrote:
 >  <snip>
 >  > 
 >  > Should I apply the patch to current netbsd-8 or the version on which I
 >  > could reproduce the crashes?  I ask because I've updated a couple of
 >  > times since my report and I haven't seen the crashes since the
 >  > updates.
 >  
 >  The version that crashes please.

 Ok, then I'll apply the change to source pulled from about 7 Mar. 2018
 15:05Z.

 >  Which version (release/time stamp) did crash and which version did not?

 The timestamp above is the only one which a) crashed and b) I have a
 crash dump for it.  I did an update on 16 Feb. and that seemed OK.
 I updated a couple of times last week and haven't seen the problem
 with either of the builds.  I haven't had this machine very long, but
 I seem to remember having issues when I first set it up around the
 beginning of February.

 -- 
 Roy Bixler <rcbixler@nyx.net>
 "The fundamental principle of science, the definition almost, is this: the
 sole test of the validity of any idea is experiment."
 -- Richard P. Feynman

State-Changed-From-To: open->closed
State-Changed-By: jdolecek@NetBSD.org
State-Changed-When: Tue, 20 Mar 2018 02:11:01 +0000
State-Changed-Why:
According to submitter this doesn't happen with netbsd-8 kernel
from Feb 16 2018 onwards. Thanks for report.


State-Changed-From-To: closed->open
State-Changed-By: jdolecek@NetBSD.org
State-Changed-When: Tue, 20 Mar 2018 17:34:34 +0000
State-Changed-Why:
hannken wants to investigate it more.


From: Roy Bixler <rcbixler@nyx.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/53096 (netbsd-8 crash on heavy disk I/O)
Date: Mon, 2 Apr 2018 09:47:56 -0600

 On Tue, Mar 20, 2018 at 05:34:34PM +0000, jdolecek@NetBSD.org wrote:
 > Synopsis: netbsd-8 crash on heavy disk I/O
 > 
 > State-Changed-From-To: closed->open
 > State-Changed-By: jdolecek@NetBSD.org
 > State-Changed-When: Tue, 20 Mar 2018 17:34:34 +0000
 > State-Changed-Why:
 > hannken wants to investigate it more.

 Good call, as this seems to be a difficult-to-reproduce issue.  I
 reverted to going to regular builds and I just had the same problem
 today while trying to do a "cvs up" on pkgsrc to go from -2017Q4 to
 2018Q1.  The kernel version is:

 NetBSD rbixler.britannica.net 8.0_BETA NetBSD 8.0_BETA (GENERIC.201803222040Z) amd64

 The backtrace from the crash dump was very similar.  I will try to
 reproduce the problem with a gdb-enabled kernel as recommended by
 hannken.

 -- 
 Roy Bixler <rcbixler@nyx.net>
 "The fundamental principle of science, the definition almost, is this: the
 sole test of the validity of any idea is experiment."
 -- Richard P. Feynman

From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/53096 (netbsd-8 crash on heavy disk I/O)
Date: Fri, 6 Apr 2018 12:15:22 +0200

 From a recent crash it looks like a race condition from procfs_dir().

 One proc is running stat or readlink on /proc/XXX/cwd while proc XXX
 changes its working directory.  As procfs_dir() takes the cwdi_cdir
 without locking the cwdi it may be vrele'd before getcwd_common()
 adds a reference resulting in the panics observed for this PR.

 Please apply this patch, it should fix the race.

 diff -r eeeea698d964 -r 18ca5463ad55 sys/miscfs/procfs/procfs_vnops.c
 --- sys/miscfs/procfs/procfs_vnops.c
 +++ sys/miscfs/procfs/procfs_vnops.c
 @@ -545,11 +545,10 @@ procfs_symlink(void *v)
  }

  /*
 - * Works out the path to (and vnode of) the target process's current
 + * Works out the path to the target process's current
   * working directory or chroot.  If the caller is in a chroot and
   * can't "reach" the target's cwd or root (or some other error
 - * occurs), a "/" is returned for the path and a NULL pointer is
 - * returned for the vnode.
 + * occurs), a "/" is returned for the path.
   */
  static void
  procfs_dir(pfstype t, struct lwp *caller, struct proc *target, char **bpp,
 @@ -559,12 +558,12 @@ procfs_dir(pfstype t, struct lwp *caller
  	struct vnode *vp, *rvp;
  	char *bp;

 -	cwdi = caller->l_proc->p_cwdi;
 -	rw_enter(&cwdi->cwdi_lock, RW_READER);
 -
 -	rvp = cwdi->cwdi_rdir;
 -	bp = bpp ? *bpp : NULL;
 -
 +	/*
 +	 * Lock target cwdi and take a reference to the vnode
 +	 * we are interested in to prevent it from disappearing
 +	 * before getcwd_common() below.
 +	 */
 +	rw_enter(&target->p_cwdi->cwdi_lock, RW_READER);
  	switch (t) {
  	case PFScwd:
  		vp = target->p_cwdi->cwdi_cdir;
 @@ -573,9 +572,17 @@ procfs_dir(pfstype t, struct lwp *caller
  		vp = target->p_cwdi->cwdi_rdir;
  		break;
  	default:
 -		rw_exit(&cwdi->cwdi_lock);
 +		rw_exit(&target->p_cwdi->cwdi_lock);
  		return;
  	}
 +	vref(vp);
 +	rw_exit(&target->p_cwdi->cwdi_lock);
 +
 +	cwdi = caller->l_proc->p_cwdi;
 +	rw_enter(&cwdi->cwdi_lock, RW_READER);
 +
 +	rvp = cwdi->cwdi_rdir;
 +	bp = bpp ? *bpp : NULL;

  	/*
  	 * XXX: this horrible kludge avoids locking panics when
 @@ -586,6 +593,7 @@ procfs_dir(pfstype t, struct lwp *caller
  			*--bp = '/';
  			*bpp = bp;
  		}
 +		vrele(vp);
  		rw_exit(&cwdi->cwdi_lock);
  		return;
  	}
 @@ -594,7 +602,6 @@ procfs_dir(pfstype t, struct lwp *caller
  		rvp = rootvnode;
  	if (vp == NULL || getcwd_common(vp, rvp, bp ? &bp : NULL, path,
  	    len / 2, 0, caller) != 0) {
 -		vp = NULL;
  		if (bpp) {
  			bp = *bpp;
  			*--bp = '/';
 @@ -604,6 +611,8 @@ procfs_dir(pfstype t, struct lwp *caller
  	if (bpp)
  		*bpp = bp;

 +	if (vp != NULL)
 +		vrele(vp);
  	rw_exit(&cwdi->cwdi_lock);
  }


From: Roy Bixler <rcbixler@nyx.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/53096 (netbsd-8 crash on heavy disk I/O)
Date: Fri, 6 Apr 2018 08:25:20 -0600

 On Fri, Apr 06, 2018 at 10:20:01AM +0000, J. Hannken-Illjes wrote:
 > The following reply was made to PR kern/53096; it has been noted by GNATS.
 > 
 > From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: kern/53096 (netbsd-8 crash on heavy disk I/O)
 > Date: Fri, 6 Apr 2018 12:15:22 +0200
 > 
 >  From a recent crash it looks like a race condition from procfs_dir().
 >  
 >  One proc is running stat or readlink on /proc/XXX/cwd while proc XXX
 >  changes its working directory.  As procfs_dir() takes the cwdi_cdir
 >  without locking the cwdi it may be vrele'd before getcwd_common()
 >  adds a reference resulting in the panics observed for this PR.
 >  
 >  Please apply this patch, it should fix the race.

 I applied the patch to netbsd-8 source pulled from yesterday evening
 and I'm running the GDB-enabled kernel now.  So far, I haven't seen
 any crashes from "rm -r" on a big source tree or from "cvs"
 checkouts, but time will tell.

 >  diff -r eeeea698d964 -r 18ca5463ad55 sys/miscfs/procfs/procfs_vnops.c
 >  --- sys/miscfs/procfs/procfs_vnops.c
 >  +++ sys/miscfs/procfs/procfs_vnops.c
 >  @@ -545,11 +545,10 @@ procfs_symlink(void *v)
 >   }
 >   
 >   /*
 >  - * Works out the path to (and vnode of) the target process's current
 >  + * Works out the path to the target process's current
 >    * working directory or chroot.  If the caller is in a chroot and
 >    * can't "reach" the target's cwd or root (or some other error
 >  - * occurs), a "/" is returned for the path and a NULL pointer is
 >  - * returned for the vnode.
 >  + * occurs), a "/" is returned for the path.
 >    */
 >   static void
 >   procfs_dir(pfstype t, struct lwp *caller, struct proc *target, char **bpp,
 >  @@ -559,12 +558,12 @@ procfs_dir(pfstype t, struct lwp *caller
 >   	struct vnode *vp, *rvp;
 >   	char *bp;
 >   
 >  -	cwdi = caller->l_proc->p_cwdi;
 >  -	rw_enter(&cwdi->cwdi_lock, RW_READER);
 >  -
 >  -	rvp = cwdi->cwdi_rdir;
 >  -	bp = bpp ? *bpp : NULL;
 >  -
 >  +	/*
 >  +	 * Lock target cwdi and take a reference to the vnode
 >  +	 * we are interested in to prevent it from disappearing
 >  +	 * before getcwd_common() below.
 >  +	 */
 >  +	rw_enter(&target->p_cwdi->cwdi_lock, RW_READER);
 >   	switch (t) {
 >   	case PFScwd:
 >   		vp = target->p_cwdi->cwdi_cdir;
 >  @@ -573,9 +572,17 @@ procfs_dir(pfstype t, struct lwp *caller
 >   		vp = target->p_cwdi->cwdi_rdir;
 >   		break;
 >   	default:
 >  -		rw_exit(&cwdi->cwdi_lock);
 >  +		rw_exit(&target->p_cwdi->cwdi_lock);
 >   		return;
 >   	}
 >  +	vref(vp);
 >  +	rw_exit(&target->p_cwdi->cwdi_lock);
 >  +
 >  +	cwdi = caller->l_proc->p_cwdi;
 >  +	rw_enter(&cwdi->cwdi_lock, RW_READER);
 >  +
 >  +	rvp = cwdi->cwdi_rdir;
 >  +	bp = bpp ? *bpp : NULL;
 >   
 >   	/*
 >   	 * XXX: this horrible kludge avoids locking panics when
 >  @@ -586,6 +593,7 @@ procfs_dir(pfstype t, struct lwp *caller
 >   			*--bp = '/';
 >   			*bpp = bp;
 >   		}
 >  +		vrele(vp);
 >   		rw_exit(&cwdi->cwdi_lock);
 >   		return;
 >   	}
 >  @@ -594,7 +602,6 @@ procfs_dir(pfstype t, struct lwp *caller
 >   		rvp = rootvnode;
 >   	if (vp == NULL || getcwd_common(vp, rvp, bp ? &bp : NULL, path,
 >   	    len / 2, 0, caller) != 0) {
 >  -		vp = NULL;
 >   		if (bpp) {
 >   			bp = *bpp;
 >   			*--bp = '/';
 >  @@ -604,6 +611,8 @@ procfs_dir(pfstype t, struct lwp *caller
 >   	if (bpp)
 >   		*bpp = bp;
 >   
 >  +	if (vp != NULL)
 >  +		vrele(vp);
 >   	rw_exit(&cwdi->cwdi_lock);
 >   }
 >   
 >  

 -- 
 Roy Bixler <rcbixler@nyx.net>
 "The fundamental principle of science, the definition almost, is this: the
 sole test of the validity of any idea is experiment."
 -- Richard P. Feynman

From: "Juergen Hannken-Illjes" <hannken@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53096 CVS commit: src/sys/miscfs/procfs
Date: Sat, 7 Apr 2018 13:42:42 +0000

 Module Name:	src
 Committed By:	hannken
 Date:		Sat Apr  7 13:42:42 UTC 2018

 Modified Files:
 	src/sys/miscfs/procfs: procfs_vnops.c

 Log Message:
 Lock the target cwdi and take an additional reference to the
 vnode we are interested in to prevent it from disappearing
 before getcwd_common().

 Should fix PR kern/53096 (netbsd-8 crash on heavy disk I/O)


 To generate a diff of this commit:
 cvs rdiff -u -r1.202 -r1.203 src/sys/miscfs/procfs/procfs_vnops.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Soren Jacobsen" <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/53096 CVS commit: [netbsd-8] src/sys/miscfs/procfs
Date: Sun, 8 Apr 2018 06:10:24 +0000

 Module Name:	src
 Committed By:	snj
 Date:		Sun Apr  8 06:10:24 UTC 2018

 Modified Files:
 	src/sys/miscfs/procfs [netbsd-8]: procfs_vnops.c

 Log Message:
 Pull up following revision(s) (requested by hannken in ticket #702):
 	sys/miscfs/procfs/procfs_vnops.c: 1.203
 Lock the target cwdi and take an additional reference to the
 vnode we are interested in to prevent it from disappearing
 before getcwd_common().
 Should fix PR kern/53096 (netbsd-8 crash on heavy disk I/O)


 To generate a diff of this commit:
 cvs rdiff -u -r1.197 -r1.197.2.1 src/sys/miscfs/procfs/procfs_vnops.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Responsible-Changed-From-To: kern-bug-people->hannken
Responsible-Changed-By: hannken@NetBSD.org
Responsible-Changed-When: Fri, 20 Apr 2018 10:35:47 +0000
Responsible-Changed-Why:
Take -- committed a fix.


State-Changed-From-To: open->feedback
State-Changed-By: hannken@NetBSD.org
State-Changed-When: Fri, 20 Apr 2018 10:35:47 +0000
State-Changed-Why:
A fix was committed and pulled up to NetBSD-8.
Is the problem gone with procfs_vnops Rev. 1.203 or Rev. 1.197.2.1?


From: Roy Bixler <rcbixler@nyx.net>
To: gnats-bugs@NetBSD.org
Cc: hannken@NetBSD.org, kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org,
        gnats-admin@netbsd.org
Subject: Re: kern/53096 (netbsd-8 crash on heavy disk I/O)
Date: Fri, 20 Apr 2018 07:40:58 -0600

 On Fri, Apr 20, 2018 at 10:35:48AM +0000, hannken@NetBSD.org wrote:
 > Synopsis: netbsd-8 crash on heavy disk I/O
 > 
 > Responsible-Changed-From-To: kern-bug-people->hannken
 > Responsible-Changed-By: hannken@NetBSD.org
 > Responsible-Changed-When: Fri, 20 Apr 2018 10:35:47 +0000
 > Responsible-Changed-Why:
 > Take -- committed a fix.
 > 
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: hannken@NetBSD.org
 > State-Changed-When: Fri, 20 Apr 2018 10:35:47 +0000
 > State-Changed-Why:
 > A fix was committed and pulled up to NetBSD-8.
 > Is the problem gone with procfs_vnops Rev. 1.203 or Rev. 1.197.2.1?

 I assume that r. 1.203 is included with NetBSD 8_RC1 and r. 1.197.2.1
 is the original fix.  I've been running with the original fix and I
 haven't seen the problem recur.  I've just upgraded to RC1 and initial
 testing is also positive.

 -- 
 Roy Bixler <rcbixler@nyx.net>
 "The fundamental principle of science, the definition almost, is this: the
 sole test of the validity of any idea is experiment."
 -- Richard P. Feynman

From: Robert Elz <kre@munnari.OZ.AU>
To: Roy Bixler <rcbixler@nyx.net>
Cc: gnats-bugs@NetBSD.org, hannken@NetBSD.org, kern-bug-people@netbsd.org,
        netbsd-bugs@netbsd.org, gnats-admin@netbsd.org
Subject: Re: kern/53096 (netbsd-8 crash on heavy disk I/O)
Date: Fri, 20 Apr 2018 21:50:28 +0700

     Date:        Fri, 20 Apr 2018 07:40:58 -0600
     From:        Roy Bixler <rcbixler@nyx.net>
     Message-ID:  <20180420134058.GA15009@nyx.net>

   | I assume that r. 1.203 is included with NetBSD 8_RC1 and r. 1.197.2.1
   | is the original fix.

 More likely the other way around.

 kre

From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/53096 (netbsd-8 crash on heavy disk I/O)
Date: Sat, 12 May 2018 18:31:04 +0200

 Did you get another crash since April 20. or is it ok to close this PR?

 --
 J. Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)

From: Roy Bixler <rcbixler@nyx.net>
To: gnats-bugs@NetBSD.org
Cc: hannken@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/53096 (netbsd-8 crash on heavy disk I/O)
Date: Sat, 12 May 2018 11:03:45 -0600

 On Sat, May 12, 2018 at 04:35:01PM +0000, J. Hannken-Illjes wrote:
 > The following reply was made to PR kern/53096; it has been noted by GNATS.
 > 
 > From: "J. Hannken-Illjes" <hannken@eis.cs.tu-bs.de>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: kern/53096 (netbsd-8 crash on heavy disk I/O)
 > Date: Sat, 12 May 2018 18:31:04 +0200
 > 
 >  Did you get another crash since April 20. or is it ok to close this PR?

 No, I haven't and, yes, it seems safe to close this.

 -- 
 Roy Bixler <rcbixler@nyx.net>
 "The fundamental principle of science, the definition almost, is this: the
 sole test of the validity of any idea is experiment."
 -- Richard P. Feynman

State-Changed-From-To: feedback->closed
State-Changed-By: hannken@NetBSD.org
State-Changed-When: Sat, 12 May 2018 20:23:22 +0000
State-Changed-Why:
Submitter confirms it is fixed.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.