Re: kern/55699: Panic certainly in iSCSI initiator

[mlelstv%serpens.de@localhost (Michael van Elst)]

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

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/55699: Panic certainly in iSCSI initiator
Date: Wed, 7 Oct 2020 13:55:15 -0000 (UTC)

 joel.bertrand%systella.fr@localhost writes:
 
 >	Randomly, when bacula lauches a job, system panics with :
 >[  3409.124192] uvm_fault(0xffffffff8151f760, 0xffffffff819ca000, 4) -> e
 >[  3409.124192] fatal page fault in supervisor mode
 >[  3409.124192] trap type 6 code 0x10 rip 0xffffffff819ca061 cs 0x8 rflags
 >0x10293 cr2 0xffffffff819ca061 ilevel 0 rsp 0xffffae013d79abb0
 >[  3409.124192] curlwp 0xfffffa749e1ef060 pid 160.1 lowest kstack
 >0xffffae013d7982c0
 >[  3409.124192] panic: trap
 >[  3409.124192] cpu5: Begin traceback...
 >[  3409.133355] vpanic() at netbsd:vpanic+0x160
 >[  3409.133355] snprintf() at netbsd:snprintf
 >[  3409.133355] startlwp() at netbsd:startlwp
 >[  3409.133355] alltraps() at netbsd:alltraps+0xbb
 >[  3409.133355] usbd_devinfo_vp() at netbsd:usbd_devinfo_vp+0xa9
 
 That crash is unrelated to backup, network or iSCSI.
 
 Something is running usbdevs or calls an equivalent function and
 the USB driver crashes. Maybe bacula has support of USB devices
 and probes for them.
 
 The rip is the same as the fault adress (cr2), which means some
 code should be executed that is no longer in memory. My guess is
 that the usbverbose module is unloaded while in use (which would
 be a bug). A workaround would then be to load that module manually.
 
 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv%serpens.de@localhost
                                 "A potential Snark may lurk in every tree."