Re: Kernel panic with usbverbose (?)

[BERTRAND Joël <joel.bertrand%systella.fr@localhost>]

Manuel Bouyer a écrit :
> On Sat, Oct 10, 2020 at 02:30:43PM +0200, BERTRAND Joël wrote:
>> Michael van Elst a écrit :
>>> joel.bertrand%systella.fr@localhost (=?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

	I suspect a bug between re(4) with jumbo frames and iSCSI. My adapter
is a PCI (not PCIe) card with a 8169S Realtek chip.

	When MTU are set to 1500 on both sides of the link, there is no problem
and iSCSI initiator over re0 seems to run as expected (Bacula has
archived more than 60 GB without panic). If I set MTU to 7418 (of
course, on both sides), even with default iSCSI segment length, I obtain
re0 watchdog timeout and iSCSI connection errors. Thus, if dk driver
cannot handle this kind of error, I understand that kernel panics.

	Regards,

	JKB