On Sat, Oct 10, 2020 at 02:30:43PM +0200, BERTRAND Joël wrote: > Michael van Elst a écrit : > > [email protected] (=?UTF-8?Q?BERTRAND_Jo=c3=abl?=) writes: > > > >> No. This PID is a kernel thread (ioflush). This morning, I have seen > >> several panics in ioflush. > > > > Kernel threads all run as PID=0. > > Of course. I don't know what was 160.1. But since this morning, I've > only seen panics in 0.175. Another one : > > [ 8900.078912] sd0d: error writing fsbn 11514444945 of > 11514444945-11514444961 (sd0 bn 11514444945; cn 5622287 tn 36 sn 17) > [ 8900.078912] sd0d: error writing fsbn 11514444962 of > 11514444962-11514445008 (sd0 bn 11514444962; cn 5622287 tn 37 sn 2) > [ 8900.078912] sd0d: error writing fsbn 11514445009 of > 11514445009-11514445072 (sd0 bn 11514445009; cn 5622287 tn 38 sn 17) > [ 8900.078912] sd0d: error writing fsbn 11514445073 of > 11514445073-11514445089 (sd0 bn 11514445073; cn 5622287 tn 40 sn 17) > [ 8900.078912] sd0d: error writing fsbn 11514445090 of > 11514445090-11514445104 (sd0 bn 11514445090; cn 5622287 tn 41 sn 2) > [ 8900.078912] sd0d: error writing fsbn 11514445105 of > 11514445105-11514445168 (sd0 bn 11514445105; cn 5622287 tn 41 sn 17) > [ 8900.078912] sd0d: error writing fsbn 11514445169 (sd0 bn > 11514445169; cn 5622287 tn 43 sn 17) > [ 8909.342671] uvm_fault(0xffffffff8151f760, 0xffffba0020ad0000, 1) -> e > [ 8909.342671] fatal page fault in supervisor mode > [ 8909.342671] trap type 6 code 0 rip 0xffffffff8026aee8 cs 0x8 rflags > 0x10286 cr2 0xffffba0020ad0070 ilevel 0 rsp 0xffffba013cc18b90 > [ 8909.342671] curlwp 0xffff9974adb6e900 pid 0.175 lowest kstack > 0xffffba013cc162c0 > [ 8909.342671] panic: trap > [ 8909.342671] cpu5: Begin traceback... > [ 8909.342671] vpanic() at netbsd:vpanic+0x160 > [ 8909.342671] snprintf() at netbsd:snprintf > [ 8909.342671] startlwp() at netbsd:startlwp > [ 8909.342671] alltraps() at netbsd:alltraps+0xbb > [ 8909.342671] dk_start() at netbsd:dk_start+0x102 > [ 8909.342671] spec_strategy() at netbsd:spec_strategy+0xa7 > [ 8909.342671] VOP_STRATEGY() at netbsd:VOP_STRATEGY+0x4c > [ 8909.352675] dkstart() at netbsd:dkstart+0x184 > [ 8909.352675] spec_strategy() at netbsd:spec_strategy+0xa7 > [ 8909.352675] VOP_STRATEGY() at netbsd:VOP_STRATEGY+0x4c > [ 8909.352675] wapbl_buffered_write_async() at > netbsd:wapbl_buffered_write_async+0x7d > [ 8909.352675] wapbl_buffered_write() at netbsd:wapbl_buffered_write+0xdf > [ 8909.352675] wapbl_circ_write() at netbsd:wapbl_circ_write+0x103 > [ 8909.352675] wapbl_flush() at netbsd:wapbl_flush+0x26f > [ 8909.352675] ffs_sync() at netbsd:ffs_sync+0x20a > [ 8909.362679] VFS_SYNC() at netbsd:VFS_SYNC+0x35 > [ 8909.362679] sched_sync() at netbsd:sched_sync+0x98 > [ 8909.362679] cpu5: End traceback...
So your disk is bad, with write errors, and it looks like there is a bug in dk in this case -- Manuel Bouyer <[email protected]> NetBSD: 26 ans d'experience feront toujours la difference --
