NetBSD Problem Report #55699

From bertrand@legendre.systella.fr  Wed Oct  7 12:07:47 2020
Return-Path: <bertrand@legendre.systella.fr>
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 6791A1A923A
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  7 Oct 2020 12:07:47 +0000 (UTC)
Message-Id: <20201007120744.2DDFC2C6740@legendre.systella.fr>
Date: Wed,  7 Oct 2020 14:07:44 +0200 (CEST)
From: joel.bertrand@systella.fr
Reply-To: joel.bertrand@systella.fr
To: gnats-bugs@NetBSD.org
Subject: Panic certainly in iSCSI initiator
X-Send-Pr-Version: 3.95

>Number:         55699
>Category:       kern
>Synopsis:       Panic certainly in iSCSI initiator
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pgoyette
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Oct 07 12:10:00 +0000 2020
>Closed-Date:    Tue Jul 20 12:57:11 +0000 2021
>Last-Modified:  Tue Jul 20 12:57:11 +0000 2021
>Originator:     joel.bertrand@systella.fr
>Release:        NetBSD 9.0_STABLE
>Organization:
>Environment:


System: NetBSD legendre.systella.fr 9.0_STABLE NetBSD 9.0_STABLE (CUSTOM) #13: Tue Oct 6 14:45:51 CEST 2020 root@legendre.systella.fr:/usr/src/netbsd-9/obj/sys/arch/amd64/compile/CUSTOM amd64
Architecture: x86_64
Machine: amd64
>Description:

	Hello,

	I have installed bacula on a NetBSD-9 server (dir, fd and sd). Bacula saves
data on a NAS (QNAP) directly connected through a specific ethernet adapter.

	Topology :
- wm0 : WAN
- agr0 (wm1+wm2) LAN
- re0 : to NAS (RTL8169 PCI Gigabit Ethernet Controller [10ec:8169] (rev 10))
- bridge0 (tap0+tap1) : remote access

	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
[  3409.143358] usbd_fill_deviceinfo() at netbsd:usbd_fill_deviceinfo+0x68
[  3409.143358] usbioctl() at netbsd:usbioctl+0xdc
[  3409.143358] cdev_ioctl() at netbsd:cdev_ioctl+0xc4
[  3409.153361] VOP_IOCTL() at netbsd:VOP_IOCTL+0x54
[  3409.153361] vn_ioctl() at netbsd:vn_ioctl+0xa5
[  3409.153361] sys_ioctl() at netbsd:sys_ioctl+0x5ab
[  3409.163364] syscall() at netbsd:syscall+0x157
[  3409.163364] --- syscall (number 54) ---
[  3409.163364] 735f5396824a:
[  3409.163364] cpu5: End traceback...

[  3409.163364] dumping to dev 18,1 (offset=251919, size=4162814):

	Of course, I don't have any information in /var/crash. But I have
netbsd.gdb if required.

>How-To-Repeat:

	Connect an iSCSI target with iscsictl and generate huge traffic on iSCSI
device.

>Fix:

>Release-Note:

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

 joel.bertrand@systella.fr 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
                                 "A potential Snark may lurk in every tree."

From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, 
    joel.bertrand@systella.fr
Subject: Re: kern/55699: Panic certainly in iSCSI initiator
Date: Wed, 7 Oct 2020 07:04:38 -0700 (PDT)

 On Wed, 7 Oct 2020, Michael van Elst wrote:

 <snip>

 > 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.

 It might be helpful to set

  	sysctl -w kern.module.verbose=1

 to confirm this possibility.


 +--------------------+--------------------------+-----------------------+
 | Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:     |
 | (Retired)          | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com     |
 | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org   |
 +--------------------+--------------------------+-----------------------+

From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
        netbsd-bugs@netbsd.org
Cc: 
Subject: Re: kern/55699: Panic certainly in iSCSI initiator
Date: Wed, 7 Oct 2020 16:31:11 +0200

 Michael van Elst a écrit :
 > The following reply was made to PR kern/55699; it has been noted by GNATS.
 > 
 > From: mlelstv@serpens.de (Michael van Elst)
 > To: gnats-bugs@netbsd.org
 > Cc: 
 > Subject: Re: kern/55699: Panic certainly in iSCSI initiator
 > Date: Wed, 7 Oct 2020 13:55:15 -0000 (UTC)
 > 
 >  joel.bertrand@systella.fr 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.

 	I have seen that this panic was related to usb. Unfortunately, this
 server only uses keyboard and mouse :

 legendre# usbdevs
 addr 0: xHCI root hub, NetBSD
 addr 0: xHCI root hub, NetBSD
  addr 1: Microsoft 3-Button Mouse with IntelliEye(TM), Microsoft
  addr 2: USB Keyboard, Logitech
 addr 1: EHCI root hub, NetBSD
  addr 2: Rate Matching Hub, Intel
 addr 1: EHCI root hub, NetBSD
  addr 2: Rate Matching Hub, Intel
 legendre#

 >  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.

 	I've never seen this kind of devices in bacula.

 >  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.

 	JKB

From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
        netbsd-bugs@netbsd.org
Cc: 
Subject: Re: kern/55699: Panic certainly in iSCSI initiator
Date: Wed, 7 Oct 2020 16:50:40 +0200

 Paul Goyette a écrit :
 > The following reply was made to PR kern/55699; it has been noted by GNATS.
 > 
 > From: Paul Goyette <paul@whooppee.com>
 > To: gnats-bugs@netbsd.org
 > Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, 
 >     joel.bertrand@systella.fr
 > Subject: Re: kern/55699: Panic certainly in iSCSI initiator
 > Date: Wed, 7 Oct 2020 07:04:38 -0700 (PDT)
 > 
 >  On Wed, 7 Oct 2020, Michael van Elst wrote:
 >  
 >  <snip>
 >  
 >  > 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.
 >  
 >  It might be helpful to set
 >  
 >   	sysctl -w kern.module.verbose=1
 >  
 >  to confirm this possibility.
 >  

 I don't know if I can confirm this possibility.

 I have removed usbverbose from kernel: modunload usbverbose.
 No error. Just after, I have set kern.module.verbose=1

 When I start bacula job (and stop to avoid panic...), I obtain on console :



 [ 10736.911324] DEBUG: module: Loading plist from
 /stand/amd64/9.0/modules/usbverbose/usbverbose.plist
 [ 10736.911324] DEBUG: module: plist load returned error 2 for
 `/stand/amd64/9.0/modules/usbverbose/usbverbose.kmod'
 [ 10736.921726] DEBUG: module: module `usbverbose' loaded successfully
 [ 10746.925138] DEBUG: module: unload requested for 'usbverbose' (FALSE)
 [ 10746.925138] DEBUG: module: unloaded module `usbverbose'
 [ 10746.965153] DEBUG: module: Loading module from
 /stand/amd64/9.0/modules/usbverbose/usbverbose.kmod
 [ 10746.965153] DEBUG: module: Loading plist from
 /stand/amd64/9.0/modules/usbverbose/usbverbose.plist
 [ 10746.965153] DEBUG: module: plist load returned error 2 for
 `/stand/amd64/9.0/modules/usbverbose/usbverbose.kmod'
 [ 10746.975404] DEBUG: module: module `usbverbose' loaded successfully
 [ 10753.947813] DEBUG: module: unload requested for 'usbverbose' (TRUE)
 [ 10753.947813] DEBUG: module: unloaded module `usbverbose'
 [ 10756.998976] DEBUG: module: Loading module from
 /stand/amd64/9.0/modules/usbverbose/usbverbose.kmod
 [ 10756.998976] DEBUG: module: Loading plist from
 /stand/amd64/9.0/modules/usbverbose/usbverbose.plist
 [ 10756.998976] DEBUG: module: plist load returned error 2 for
 `/stand/amd64/9.0/modules/usbverbose/usbverbose.kmod'
 [ 10757.019631] DEBUG: module: module `usbverbose' loaded successfully
 [ 10767.012792] DEBUG: module: unload requested for 'usbverbose' (FALSE)
 [ 10767.012792] DEBUG: module: unloaded module `usbverbose'
 [ 10767.042803] DEBUG: module: Loading module from
 /stand/amd64/9.0/modules/usbverbose/usbverbose.kmod
 [ 10767.042803] DEBUG: module: Loading plist from
 /stand/amd64/9.0/modules/usbverbose/usbverbose.plist
 [ 10767.042803] DEBUG: module: plist load returned error 2 for
 `/stand/amd64/9.0/modules/usbverbose/usbverbose.kmod'
 [ 10767.052828] DEBUG: module: module `usbverbose' loaded successfully
 [ 10777.056620] DEBUG: module: unload requested for 'usbverbose' (FALSE)
 [ 10777.056620] DEBUG: module: unloaded module `usbverbose'
 [ 10777.076627] DEBUG: module: Loading module from
 /stand/amd64/9.0/modules/usbverbose/usbverbose.kmod
 [ 10777.076627] DEBUG: module: Loading plist from
 /stand/amd64/9.0/modules/usbverbose/usbverbose.plist
 [ 10777.076627] DEBUG: module: plist load returned error 2 for
 `/stand/amd64/9.0/modules/usbverbose/usbverbose.kmod'
 [ 10777.096792] DEBUG: module: module `usbverbose' loaded successfully
 [ 10787.090445] DEBUG: module: unload requested for 'usbverbose' (FALSE)
 [ 10787.090445] DEBUG: module: unloaded module `usbverbose'
 [ 10787.120456] DEBUG: module: Loading module from
 /stand/amd64/9.0/modules/usbverbose/usbverbose.kmod

 	Regards,

 	JKB

From: Paul Goyette <paul@whooppee.com>
To: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org, 
    netbsd-bugs@netbsd.org
Subject: Re: kern/55699: Panic certainly in iSCSI initiator
Date: Wed, 7 Oct 2020 08:07:05 -0700 (PDT)

   This message is in MIME format.  The first part should be readable text,
   while the remaining parts are likely unreadable without MIME-aware tools.

 --0-192185534-1602083225=:15496
 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
 Content-Transfer-Encoding: QUOTED-PRINTABLE

 That confirms that the module is being auto-loaded and -unloaded

 So now we just have to identify where it is being used-after-unload.



 On Wed, 7 Oct 2020, BERTRAND Jo=C3=ABl wrote:

 > Paul Goyette a =C3=A9crit=C2=A0:
 >> The following reply was made to PR kern/55699; it has been noted by GNAT=
 S.
 >>
 >> From: Paul Goyette <paul@whooppee.com>
 >> To: gnats-bugs@netbsd.org
 >> Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netb=
 sd.org,
 >>     joel.bertrand@systella.fr
 >> Subject: Re: kern/55699: Panic certainly in iSCSI initiator
 >> Date: Wed, 7 Oct 2020 07:04:38 -0700 (PDT)
 >>
 >>  On Wed, 7 Oct 2020, Michael van Elst wrote:
 >>
 >>  <snip>
 >>
 >> > 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.
 >>
 >>  It might be helpful to set
 >>
 >>   =09sysctl -w kern.module.verbose=3D1
 >>
 >>  to confirm this possibility.
 >>
 >
 > I don't know if I can confirm this possibility.
 >
 > I have removed usbverbose from kernel: modunload usbverbose.
 > No error. Just after, I have set kern.module.verbose=3D1
 >
 > When I start bacula job (and stop to avoid panic...), I obtain on console=
  :
 >
 >
 >
 > [ 10736.911324] DEBUG: module: Loading plist from
 > /stand/amd64/9.0/modules/usbverbose/usbverbose.plist
 > [ 10736.911324] DEBUG: module: plist load returned error 2 for
 > `/stand/amd64/9.0/modules/usbverbose/usbverbose.kmod'
 > [ 10736.921726] DEBUG: module: module `usbverbose' loaded successfully
 > [ 10746.925138] DEBUG: module: unload requested for 'usbverbose' (FALSE)
 > [ 10746.925138] DEBUG: module: unloaded module `usbverbose'
 > [ 10746.965153] DEBUG: module: Loading module from
 > /stand/amd64/9.0/modules/usbverbose/usbverbose.kmod
 > [ 10746.965153] DEBUG: module: Loading plist from
 > /stand/amd64/9.0/modules/usbverbose/usbverbose.plist
 > [ 10746.965153] DEBUG: module: plist load returned error 2 for
 > `/stand/amd64/9.0/modules/usbverbose/usbverbose.kmod'
 > [ 10746.975404] DEBUG: module: module `usbverbose' loaded successfully
 > [ 10753.947813] DEBUG: module: unload requested for 'usbverbose' (TRUE)
 > [ 10753.947813] DEBUG: module: unloaded module `usbverbose'
 > [ 10756.998976] DEBUG: module: Loading module from
 > /stand/amd64/9.0/modules/usbverbose/usbverbose.kmod
 > [ 10756.998976] DEBUG: module: Loading plist from
 > /stand/amd64/9.0/modules/usbverbose/usbverbose.plist
 > [ 10756.998976] DEBUG: module: plist load returned error 2 for
 > `/stand/amd64/9.0/modules/usbverbose/usbverbose.kmod'
 > [ 10757.019631] DEBUG: module: module `usbverbose' loaded successfully
 > [ 10767.012792] DEBUG: module: unload requested for 'usbverbose' (FALSE)
 > [ 10767.012792] DEBUG: module: unloaded module `usbverbose'
 > [ 10767.042803] DEBUG: module: Loading module from
 > /stand/amd64/9.0/modules/usbverbose/usbverbose.kmod
 > [ 10767.042803] DEBUG: module: Loading plist from
 > /stand/amd64/9.0/modules/usbverbose/usbverbose.plist
 > [ 10767.042803] DEBUG: module: plist load returned error 2 for
 > `/stand/amd64/9.0/modules/usbverbose/usbverbose.kmod'
 > [ 10767.052828] DEBUG: module: module `usbverbose' loaded successfully
 > [ 10777.056620] DEBUG: module: unload requested for 'usbverbose' (FALSE)
 > [ 10777.056620] DEBUG: module: unloaded module `usbverbose'
 > [ 10777.076627] DEBUG: module: Loading module from
 > /stand/amd64/9.0/modules/usbverbose/usbverbose.kmod
 > [ 10777.076627] DEBUG: module: Loading plist from
 > /stand/amd64/9.0/modules/usbverbose/usbverbose.plist
 > [ 10777.076627] DEBUG: module: plist load returned error 2 for
 > `/stand/amd64/9.0/modules/usbverbose/usbverbose.kmod'
 > [ 10777.096792] DEBUG: module: module `usbverbose' loaded successfully
 > [ 10787.090445] DEBUG: module: unload requested for 'usbverbose' (FALSE)
 > [ 10787.090445] DEBUG: module: unloaded module `usbverbose'
 > [ 10787.120456] DEBUG: module: Loading module from
 > /stand/amd64/9.0/modules/usbverbose/usbverbose.kmod
 >
 > =09Regards,
 >
 > =09JKB
 >
 > !DSPAM:5f7dd61c75301160512031!
 >
 >

 +--------------------+--------------------------+-----------------------+
 | Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:     |
 | (Retired)          | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com     |
 | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org   |
 +--------------------+--------------------------+-----------------------+
 --0-192185534-1602083225=:15496--

From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: Paul Goyette <paul@whooppee.com>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
        netbsd-bugs@netbsd.org
Subject: Re: kern/55699: Panic certainly in iSCSI initiator
Date: Wed, 7 Oct 2020 17:14:33 +0200

 Paul Goyette a écrit :
 > That confirms that the module is being auto-loaded and -unloaded
 > 
 > So now we just have to identify where it is being used-after-unload.

 	Yes, I understand, but I don't see how this trouble can be related to
 bacula. I have checked in sources and I haven't find any line of code
 related to ab usb device.

From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: Paul Goyette <paul@whooppee.com>
Cc: kern-bug-people@netbsd.org,
        "gnats-bugs@netbsd.org"
 <gnats-bugs@NetBSD.org>,
        gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/55699: Panic certainly in iSCSI initiator
Date: Wed, 7 Oct 2020 18:20:31 +0200

 Paul Goyette a écrit :
 > On Wed, 7 Oct 2020, BERTRAND Joël wrote:
 > 
 >> Paul Goyette a écrit :
 >>> That confirms that the module is being auto-loaded and -unloaded
 >>>
 >>> So now we just have to identify where it is being used-after-unload.
 >>
 >>     Yes, I understand, but I don't see how this trouble can be related to
 >> bacula. I have checked in sources and I haven't find any line of code
 >> related to ab usb device.
 > 
 > Something in bacula is invoking usbdevs, either directly or via the
 > same ioctl.  Perhaps it is in some library dependency?  I don't know,
 > I don't use bacula.  But that's what triggers your crash.

 In bacula's sources (src/findlib/fstype.c), I see that is called (line 127).

 statvfs is a libc function :

 int
 statvfs(const char *file, struct statvfs *st)
 {
     return statvfs1(file, st, ST_WAIT);
 }

 but I don't find sources of statvfs1 (seems to be statvfs1.S) to check
 if this function call usbdevs.

 	JKB

From: Robert Elz <kre@munnari.OZ.AU>
To: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
Cc: Paul Goyette <paul@whooppee.com>, kern-bug-people@netbsd.org,
        "gnats-bugs@netbsd.org" <gnats-bugs@NetBSD.org>,
        gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/55699: Panic certainly in iSCSI initiator
Date: Thu, 08 Oct 2020 02:39:51 +0700

     Date:        Wed, 7 Oct 2020 18:20:31 +0200
     From:        =3D?UTF-8?Q?BERTRAND_Jo=3Dc3=3Dabl?=3D <joel.bertrand=40=
 systella.fr>
     Message-ID:  <4a9619fb-bed4-0ea0-c370-51f8060bec5e=40systella.fr>

   =7C but I don't find sources of statvfs1 (seems to be statvfs1.S) to ch=
 eck
   =7C if this function call usbdevs.

 statvfs() is a system call, it will reference usb devices if the filesyst=
 em
 it is seeking information on is on a usb backed device.

 For your installation, do you have any filesystem mounted on usb, or
 anything in fstab which could mount on usb?   If so, bacula is probably
 trying to check it (even if you didn't expect that to happen).

 kre

From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
        netbsd-bugs@netbsd.org
Cc: 
Subject: Re: kern/55699: Panic certainly in iSCSI initiator
Date: Wed, 7 Oct 2020 23:54:05 +0200

 Robert Elz a écrit :
 > The following reply was made to PR kern/55699; it has been noted by GNATS.
 > 
 > From: Robert Elz <kre@munnari.OZ.AU>
 > To: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
 > Cc: Paul Goyette <paul@whooppee.com>, kern-bug-people@netbsd.org,
 >         "gnats-bugs@netbsd.org" <gnats-bugs@NetBSD.org>,
 >         gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
 > Subject: Re: kern/55699: Panic certainly in iSCSI initiator
 > Date: Thu, 08 Oct 2020 02:39:51 +0700
 > 
 >      Date:        Wed, 7 Oct 2020 18:20:31 +0200
 >      From:        =3D?UTF-8?Q?BERTRAND_Jo=3Dc3=3Dabl?=3D <joel.bertrand=40=
 >  systella.fr>
 >      Message-ID:  <4a9619fb-bed4-0ea0-c370-51f8060bec5e=40systella.fr>
 >  
 >    =7C but I don't find sources of statvfs1 (seems to be statvfs1.S) to ch=
 >  eck
 >    =7C if this function call usbdevs.
 >  
 >  statvfs() is a system call, it will reference usb devices if the filesyst=
 >  em
 >  it is seeking information on is on a usb backed device.
 >
 >  For your installation, do you have any filesystem mounted on usb, or
 >  anything in fstab which could mount on usb?   If so, bacula is probably
 >  trying to check it (even if you didn't expect that to happen).

 	I don't have. My fstab is :

 legendre# cat /etc/fstab
 /dev/raid0a             /               ffs     rw,log          1 1
 /dev/raid0b             none            swap    sw,dp           0 0
 /dev/raid0e             /usr            ffs     rw,log          1 2
 /dev/raid0f             /var            ffs     rw,log          1 2
 /dev/raid0g             /usr/src        ffs     rw,log          1 2
 /dev/raid0h             /srv            ffs     rw,log          1 2
 /dev/dk0                /home           ffs     rw,log          1 3
 kernfs                  /kern           kernfs  rw
 ptyfs                   /dev/pts        ptyfs   rw
 procfs                  /proc           procfs  rw
 /dev/cd0a               /cdrom          cd9660  ro,noauto
 tmpfs                   /var/shm        tmpfs   rw,-m1777,-sram%25

 legendre# df
 Filesystem    1K-blocks       Used      Avail  %Cap Mounted on
 /dev/raid0a    32529068    1112068    29790548   3% /
 /dev/raid0e    65058298   25405420    36399964  41% /usr
 /dev/raid0f    32529068   11474358    19428258  37% /var
 /dev/raid0g   264277976   36181292   214882788  14% /usr/src
 /dev/raid0h   548684628  238862272   282388128  45% /srv
 /dev/dk0     3876580176 2579149400  1103601768  70% /home
 kernfs                1          1           0 100% /kern
 ptyfs                 1          1           0 100% /dev/pts
 procfs                4          4           0 100% /proc
 tmpfs           4162812         28     4162784   0% /var/shm
 /dev/dk1    11335898764    1042376 10768061452   0% /opt
 legendre#

 dk1 is an iSCSI target. dk0 is a raid5 volume.

 legendre# raidctl -s raid0
 Components:
            /dev/wd2a: optimal
            /dev/wd3a: optimal
 ...
 legendre# raidctl -s raid1
 Components:
            /dev/wd4e: optimal
            /dev/wd5e: optimal
            /dev/wd6e: optimal

 	I haven't found any direct usage of USB in bacula.

 	JKB

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/55699: Panic certainly in iSCSI initiator
Date: Wed, 9 Jun 2021 05:48:47 +0000

 not sent to gnats (send PR responses to gnats-bugs@)

    ------

 From: BERTRAND Jo?l <joel.bertrand@systella.fr>
 To: Paul Goyette <paul@whooppee.com>
 Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
 Subject: Re: kern/55699: Panic certainly in iSCSI initiator
 Date: Thu, 8 Oct 2020 17:24:29 +0200

 Paul Goyette a ?crit?:
 > On Wed, 7 Oct 2020, BERTRAND Jo?l wrote:
 > 
 >> Paul Goyette a ?crit?:
 >>> That confirms that the module is being auto-loaded and -unloaded
 >>>
 >>> So now we just have to identify where it is being used-after-unload.
 >>
 >> ????Yes, I understand, but I don't see how this trouble can be related to
 >> bacula. I have checked in sources and I haven't find any line of code
 >> related to ab usb device.
 > 
 > Something in bacula is invoking usbdevs, either directly or via the
 > same ioctl.? Perhaps it is in some library dependency?? I don't know,
 > I don't use bacula.? But that's what triggers your crash.

 	Hi Paul,

 	A second workstation has paniced today with the same traceback (and
 _without_ any USB special device, only a keyboard, no mouse). This
 workstation doesn't run bacula. Thus, this bug is surely triggered by
 bacula but can occur without this application.

 	If I remember, I have seen on my server the same panic (similar
 traceback) last month, before I have installed bacula.

 	Something should be wrong around vfs.

 	Best regards,

 	JKB

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/55699: Panic certainly in iSCSI initiator
Date: Wed, 9 Jun 2021 05:55:00 +0000

 Also see 56232: it is possible that bacula was trying to back up your
 /dev and tripped on one of the things mentioned there.

 -- 
 David A. Holland
 dholland@netbsd.org

From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc: joel.bertrand@systella.fr
Subject: Re: kern/55699: Panic certainly in iSCSI initiator
Date: Wed, 9 Jun 2021 05:53:47 -0700 (PDT)

   This message is in MIME format.  The first part should be readable text,
   while the remaining parts are likely unreadable without MIME-aware tools.

 --0-702270949-1623243227=:3538
 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

 I'm currently working some code to prevent the usbverbose module
 from being unloaded while in use.  Unfortunately I don't have any
 system which exhibits the problem.

 Perhaps you could try the attached patch?  (I'm also waiting for
 some other folks to test the patch.)


 +--------------------+--------------------------+---------------------+
 | Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:   |
 | (Retired)          | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com   |
 | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
 +--------------------+--------------------------+---------------------+
 --0-702270949-1623243227=:3538
 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=DEV_VERBOSE.diffs
 Content-Transfer-Encoding: BASE64
 Content-ID: <Pine.NEB.4.64.2106090553470.3538@speedy.whooppee.com>
 Content-Description: 
 Content-Disposition: attachment; filename=DEV_VERBOSE.diffs

 SW5kZXg6IGRldl92ZXJib3NlLmgNCj09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N
 ClJDUyBmaWxlOiAvY3Zzcm9vdC9zcmMvc3lzL2Rldi9kZXZfdmVyYm9zZS5o
 LHYNCnJldHJpZXZpbmcgcmV2aXNpb24gMS41DQpkaWZmIC11IC1wIC1yMS41
 IGRldl92ZXJib3NlLmgNCi0tLSBkZXZfdmVyYm9zZS5oCTEgSnVuIDIwMjEg
 MjI6NTg6MDMgLTAwMDAJMS41DQorKysgZGV2X3ZlcmJvc2UuaAk0IEp1biAy
 MDIxIDAwOjM1OjE3IC0wMDAwDQpAQCAtMjUsNiArMjUsMTAgQEANCiAjaWZu
 ZGVmIF9ERVZfREVWX1ZFUkJPU0VfSF8NCiAjZGVmaW5lCV9ERVZfREVWX1ZF
 UkJPU0VfSF8NCiANCisjaWZkZWYgX0tFUk5FTA0KKyNpbmNsdWRlIDxzeXMv
 bW9kdWxlX2hvb2suaD4NCisjZW5kaWYNCisNCiBjb25zdCBjaGFyICpkZXZf
 ZmluZHZlbmRvcihjaGFyICosIHNpemVfdCwgY29uc3QgY2hhciAqLCBzaXpl
 X3QsIA0KIAljb25zdCB1aW50MTZfdCAqLCBzaXplX3QsIHVpbnQxNl90KTsN
 CiBjb25zdCBjaGFyICpkZXZfZmluZHByb2R1Y3QoY2hhciAqLCBzaXplX3Qs
 IGNvbnN0IGNoYXIgKiwgc2l6ZV90LCANCkBAIC01MCwzMyArNTQsMzQgQEAg
 dGFnICMjIF9maW5kcHJvZHVjdF9yZWFsKGNoYXIgKmJ1Ziwgc2l6ZQ0KIA0K
 ICNpZmRlZiBfS0VSTkVMDQogDQorI2RlZmluZSBERVZfVkVSQk9TRV9LRVJO
 RUxfREVDTEFSRSh0YWcpCQkJCQlcDQorTU9EVUxFX0hPT0sodGFnICMjIF9m
 aW5kdmVuZG9yX2hvb2ssIGNvbnN0IGNoYXIgKiwJCQlcDQorCShjaGFyICos
 IHNpemVfdCwgdWludDE2X3QpKTsJCQkJCVwNCitNT0RVTEVfSE9PSyh0YWcg
 IyMgX2ZpbmRwcm9kdWN0X2hvb2ssIGNvbnN0IGNoYXIgKiwJCQlcDQorCShj
 aGFyICosIHNpemVfdCwgdWludDE2X3QsIHVpbnQxNl90KSk7CQkJCVwNCitl
 eHRlcm4gaW50IHRhZyAjIyB2ZXJib3NlX2xvYWRlZDsNCisNCiAjZGVmaW5l
 IERFVl9WRVJCT1NFX01PRFVMRV9ERUZJTkUodGFnLCBkZXBzKQkJCQlcDQog
 REVWX1ZFUkJPU0VfQ09NTU9OX0RFRklORSh0YWcpCQkJCQkJXA0KLWV4dGVy
 biBpbnQgdGFnICMjIHZlcmJvc2VfbG9hZGVkOwkJCQkJXA0KK0RFVl9WRVJC
 T1NFX0tFUk5FTF9ERUNMQVJFKHRhZykJCQkJCQlcDQogCQkJCQkJCQkJXA0K
 IHN0YXRpYyBpbnQJCQkJCQkJCVwNCiB0YWcgIyMgdmVyYm9zZV9tb2RjbWQo
 bW9kY21kX3QgY21kLCB2b2lkICphcmcpCQkJCVwNCiB7CQkJCQkJCQkJXA0K
 LQlzdGF0aWMgY29uc3QgY2hhciAqKCpzYXZlZF9maW5kdmVuZG9yKShjaGFy
 ICosIHNpemVfdCwJCVwNCi0JICAgIHVpbnQxNl90KTsJCQkJCQkJXA0KLQlz
 dGF0aWMgY29uc3QgY2hhciAqKCpzYXZlZF9maW5kcHJvZHVjdCkoY2hhciAq
 LCBzaXplX3QsCQlcDQotCSAgICB1aW50MTZfdCwgdWludDE2X3QpOwkJCQkJ
 XA0KIAkJCQkJCQkJCVwNCiAJc3dpdGNoIChjbWQpIHsJCQkJCQkJXA0KIAlj
 YXNlIE1PRFVMRV9DTURfSU5JVDoJCQkJCQlcDQotCQlzYXZlZF9maW5kdmVu
 ZG9yID0gdGFnICMjIF9maW5kdmVuZG9yOwkJCVwNCi0JCXNhdmVkX2ZpbmRw
 cm9kdWN0ID0gdGFnICMjIF9maW5kcHJvZHVjdDsJCVwNCi0JCXRhZyAjIyBf
 ZmluZHZlbmRvciA9IHRhZyAjIyBfZmluZHZlbmRvcl9yZWFsOwkJXA0KLQkJ
 dGFnICMjIF9maW5kcHJvZHVjdCA9IHRhZyAjIyBfZmluZHByb2R1Y3RfcmVh
 bDsJCVwNCisJCU1PRFVMRV9IT09LX1NFVCh0YWcgIyMgX2ZpbmR2ZW5kb3Jf
 aG9vaywJCVwNCisJCQl0YWcgIyMgX2ZpbmR2ZW5kb3JfcmVhbCk7CQkJXA0K
 KwkJTU9EVUxFX0hPT0tfU0VUKHRhZyAjIyBfZmluZHByb2R1Y3RfaG9vaywJ
 CVwNCisJCQl0YWcgIyMgX2ZpbmRwcm9kdWN0X3JlYWwpOwkJCVwNCiAJCXRh
 ZyAjIyB2ZXJib3NlX2xvYWRlZCA9IDE7CQkJCVwNCiAJCXJldHVybiAwOwkJ
 CQkJCVwNCiAJY2FzZSBNT0RVTEVfQ01EX0ZJTkk6CQkJCQkJXA0KLQkJdGFn
 ICMjIF9maW5kdmVuZG9yID0gc2F2ZWRfZmluZHZlbmRvcjsJCQlcDQotCQl0
 YWcgIyMgX2ZpbmRwcm9kdWN0ID0gc2F2ZWRfZmluZHByb2R1Y3Q7CQlcDQog
 CQl0YWcgIyMgdmVyYm9zZV9sb2FkZWQgPSAwOwkJCQlcDQorCQlNT0RVTEVf
 SE9PS19VTlNFVCh0YWcgIyMgX2ZpbmRwcm9kdWN0X2hvb2spOwkJXA0KKwkJ
 TU9EVUxFX0hPT0tfVU5TRVQodGFnICMjIF9maW5kdmVuZG9yX2hvb2spOwkJ
 XA0KIAkJcmV0dXJuIDA7CQkJCQkJXA0KLQljYXNlIE1PRFVMRV9DTURfQVVU
 T1VOTE9BRDoJCQkJCVwNCi0JCXJldHVybiBFQlVTWTsJCQkJCQlcDQogCWRl
 ZmF1bHQ6CQkJCQkJCVwNCiAJCXJldHVybiBFTk9UVFk7CQkJCQkJXA0KIAl9
 CQkJCQkJCQlcDQpAQCAtODYsMTEgKzkxLDE1IEBAIE1PRFVMRShNT0RVTEVf
 Q0xBU1NfRFJJVkVSLCB0YWcgIyMgdmVyYm8NCiAjZW5kaWYgLyogS0VSTkVM
 ICovDQogDQogI2RlZmluZSBERVZfVkVSQk9TRV9ERUNMQVJFKHRhZykJCQkJ
 CVwNCi1leHRlcm4gY29uc3QgY2hhciAqICgqdGFnICMjIF9maW5kdmVuZG9y
 KShjaGFyICosIHNpemVfdCwgdWludDE2X3QpOwlcDQotZXh0ZXJuIGNvbnN0
 IGNoYXIgKiAoKnRhZyAjIyBfZmluZHByb2R1Y3QpKGNoYXIgKiwgc2l6ZV90
 LCB1aW50MTZfdCwgdWludDE2X3QpDQorZXh0ZXJuIGNvbnN0IGNoYXIgKiB0
 YWcgIyMgX2ZpbmR2ZW5kb3IoY2hhciAqLCBzaXplX3QsIHVpbnQxNl90KTsJ
 XA0KK2V4dGVybiBjb25zdCBjaGFyICogdGFnICMjIF9maW5kcHJvZHVjdChj
 aGFyICosIHNpemVfdCwgdWludDE2X3QsIHVpbnQxNl90KQ0KIA0KICNpZiBk
 ZWZpbmVkKF9LRVJORUwpDQorDQogI2RlZmluZSBERVZfVkVSQk9TRV9ERUZJ
 TkUodGFnKQkJCQkJCVwNCitERVZfVkVSQk9TRV9LRVJORUxfREVDTEFSRSh0
 YWcpCQkJCQkJXA0KK3N0cnVjdCB0YWcgIyMgX2ZpbmR2ZW5kb3JfaG9va190
 IHRhZyAjIyBfZmluZHZlbmRvcl9ob29rOwkJXA0KK3N0cnVjdCB0YWcgIyMg
 X2ZpbmRwcm9kdWN0X2hvb2tfdCB0YWcgIyMgX2ZpbmRwcm9kdWN0X2hvb2s7
 CQlcDQogaW50IHRhZyAjIyB2ZXJib3NlX2xvYWRlZCA9IDA7CQkJCQkJXA0K
 IAkJCQkJCQkJCVwNCiBzdGF0aWMgdm9pZAkJCQkJCQkJXA0KQEAgLTEwMSw0
 NiArMTEwLDQ4IEBAIHRhZyAjIyBfbG9hZF92ZXJib3NlKHZvaWQpCQkJCQkJ
 XA0KIAkJbW9kdWxlX2F1dG9sb2FkKCMgdGFnICJ2ZXJib3NlIiwgTU9EVUxF
 X0NMQVNTX0RSSVZFUik7CVwNCiB9CQkJCQkJCQkJXA0KIAkJCQkJCQkJCVwN
 Ci1zdGF0aWMgY29uc3QgY2hhciAqCQkJCQkJCVwNCi10YWcgIyMgX2ZpbmR2
 ZW5kb3Jfc3R1YihjaGFyICpidWYsIHNpemVfdCBsZW4sIHVpbnQxNl90IHZl
 bmRvcikJCVwNCitjb25zdCBjaGFyICoJCQkJCQkJCVwNCit0YWcgIyMgX2Zp
 bmR2ZW5kb3IoY2hhciAqYnVmLCBzaXplX3QgbGVuLCB1aW50MTZfdCB2ZW5k
 b3IpCQlcDQogewkJCQkJCQkJCVwNCisJY29uc3QgY2hhciAqcmV0dmFsID0g
 TlVMTDsJCQkJCVwNCiAJCQkJCQkJCQlcDQogCXRhZyAjIyBfbG9hZF92ZXJi
 b3NlKCk7CQkJCQkJXA0KLQlpZiAodGFnICMjIHZlcmJvc2VfbG9hZGVkKQkJ
 CQkJXA0KLQkJcmV0dXJuIHRhZyAjIyBfZmluZHZlbmRvcihidWYsIGxlbiwg
 dmVuZG9yKTsJCVwNCi0JZWxzZSB7CQkJCQkJCQlcDQotCQlzbnByaW50Zihi
 dWYsIGxlbiwgInZlbmRvciAlNC40eCIsIHZlbmRvcik7CQlcDQotCQlyZXR1
 cm4gTlVMTDsJCQkJCQlcDQotCX0JCQkJCQkJCVwNCisJTU9EVUxFX0hPT0tf
 Q0FMTCh0YWcgIyMgX2ZpbmR2ZW5kb3JfaG9vaywgKGJ1ZiwgbGVuLCB2ZW5k
 b3IpLAlcDQorCQl7c25wcmludGYoYnVmLCBsZW4sICJ2ZW5kb3IgJTQuNHgi
 LCB2ZW5kb3IpOyBOVUxMOyB9LAlcDQorCQlyZXR2YWwpOwkJCQkJCVwNCisJ
 cmV0dXJuIHJldHZhbDsJCQkJCQkJXA0KIH0JCQkJCQkJCQlcDQogCQkJCQkJ
 CQkJXA0KLXN0YXRpYyBjb25zdCBjaGFyICoJCQkJCQkJXA0KLXRhZyAjIyBf
 ZmluZHByb2R1Y3Rfc3R1YihjaGFyICpidWYsIHNpemVfdCBsZW4sIHVpbnQx
 Nl90IHZlbmRvciwJXA0KK2NvbnN0IGNoYXIgKgkJCQkJCQkJXA0KK3RhZyAj
 IyBfZmluZHByb2R1Y3QoY2hhciAqYnVmLCBzaXplX3QgbGVuLCB1aW50MTZf
 dCB2ZW5kb3IsCQlcDQogICAgIHVpbnQxNl90IHByb2R1Y3QpCQkJCQkJCVwN
 CiB7CQkJCQkJCQkJXA0KKwljb25zdCBjaGFyICpyZXR2YWwgPSBOVUxMOwkJ
 CQkJXA0KIAkJCQkJCQkJCVwNCiAJdGFnICMjIF9sb2FkX3ZlcmJvc2UoKTsJ
 CQkJCQlcDQotCWlmICh0YWcgIyMgdmVyYm9zZV9sb2FkZWQpCQkJCQlcDQot
 CQlyZXR1cm4gdGFnICMjIF9maW5kcHJvZHVjdChidWYsIGxlbiwgdmVuZG9y
 LCBwcm9kdWN0KTsJXA0KLQllbHNlIHsJCQkJCQkJCVwNCi0JCXNucHJpbnRm
 KGJ1ZiwgbGVuLCAicHJvZHVjdCAlNC40eCIsIHByb2R1Y3QpOwkJXA0KLQkJ
 cmV0dXJuIE5VTEw7CQkJCQkJXA0KLQl9CQkJCQkJCQlcDQorCU1PRFVMRV9I
 T09LX0NBTEwodGFnICMjIF9maW5kcHJvZHVjdF9ob29rLAkJCVwNCisJCShi
 dWYsIGxlbiwgdmVuZG9yLCBwcm9kdWN0KSwJCQkJXA0KKwkJe3NucHJpbnRm
 KGJ1ZiwgbGVuLCAicHJvZHVjdCAlNC40eCIsIHByb2R1Y3QpOyBOVUxMOyB9
 LAlcDQorCQlyZXR2YWwpOwkJCQkJCVwNCisJcmV0dXJuIHJldHZhbDsJCQkJ
 CQkJXA0KIH0JCQkJCQkJCQlcDQotCQkJCQkJCQkJXA0KLWNvbnN0IGNoYXIg
 KigqdGFnICMjIF9maW5kdmVuZG9yKShjaGFyICosIHNpemVfdCwgdWludDE2
 X3QpID0gCQlcDQotICAgIHRhZyAjIyBfZmluZHZlbmRvcl9zdHViOwkJCQkJ
 CVwNCi1jb25zdCBjaGFyICooKnRhZyAjIyBfZmluZHByb2R1Y3QpKGNoYXIg
 Kiwgc2l6ZV90LCB1aW50MTZfdCwgdWludDE2X3QpID1cDQotICAgIHRhZyAj
 IyBfZmluZHByb2R1Y3Rfc3R1YgkJCQkJCVwNCiANCi0jZWxzZQ0KKyNlbHNl
 CS8qIF9LRVJORUwgKi8NCiANCiAjZGVmaW5lIERFVl9WRVJCT1NFX0RFRklO
 RSh0YWcpCQkJCQkJXA0KIERFVl9WRVJCT1NFX0NPTU1PTl9ERUZJTkUodGFn
 KQkJCQkJCVwNCi1jb25zdCBjaGFyICooKnRhZyAjIyBfZmluZHZlbmRvciko
 Y2hhciAqLCBzaXplX3QsIHVpbnQxNl90KSA9IAkJXA0KLSAgICB0YWcgIyMg
 X2ZpbmR2ZW5kb3JfcmVhbDsJCQkJCQlcDQotY29uc3QgY2hhciAqKCp0YWcg
 IyMgX2ZpbmRwcm9kdWN0KShjaGFyICosIHNpemVfdCwgdWludDE2X3QsIHVp
 bnQxNl90KSA9XA0KLSAgICB0YWcgIyMgX2ZpbmRwcm9kdWN0X3JlYWwJCQkJ
 CQlcDQorY29uc3QgY2hhciAqdGFnICMjIF9maW5kdmVuZG9yKGNoYXIgKmJ1
 Ziwgc2l6ZV90IGxlbiwgdWludDE2X3QgdmVuZG9yKQlcDQorewkJCQkJCQkJ
 CVwNCisJCQkJCQkJCQlcDQorCXJldHVybiB0YWcgIyMgX2ZpbmR2ZW5kb3Jf
 cmVhbChidWYsIGxlbiwgdmVuZG9yKTsJCVwNCit9CQkJCQkJCQkJXA0KKwkJ
 CQkJCQkJCVwNCitjb25zdCBjaGFyICp0YWcgIyMgX2ZpbmRwcm9kdWN0KGNo
 YXIgKmJ1Ziwgc2l6ZV90IGxlbiwgdWludDE2X3QgdmVuZG9yLAlcDQorCQl1
 aW50MTZfdCBwcm9kdWN0KQkJCQkJXA0KK3sJCQkJCQkJCQlcDQorCQkJCQkJ
 CQkJXA0KKwlyZXR1cm4gdGFnICMjIF9maW5kcHJvZHVjdF9yZWFsKGJ1Ziwg
 bGVuLCB2ZW5kb3IsIHByb2R1Y3QpOwlcDQorfQ0KIA0KICNlbmRpZiAvKiBf
 S0VSTkVMICovDQogDQo=

 --0-702270949-1623243227=:3538--

Responsible-Changed-From-To: kern-bug-people->pgoyette
Responsible-Changed-By: pgoyette@NetBSD.org
Responsible-Changed-When: Thu, 10 Jun 2021 21:18:40 +0000
Responsible-Changed-Why:
I'm working on it


State-Changed-From-To: open->feedback
State-Changed-By: pgoyette@NetBSD.org
State-Changed-When: Thu, 10 Jun 2021 21:18:40 +0000
State-Changed-Why:
A likely fix was committed, requesting submitter to confirm.


From: Paul Goyette <paul@whooppee.com>
To: gnats-bugs@netbsd.org
Cc: joel.bertrand@systella.fr
Subject: Re: kern/55699: Panic certainly in iSCSI initiator
Date: Thu, 10 Jun 2021 14:17:22 -0700 (PDT)

 > I'm currently working some code to prevent the usbverbose module
 > from being unloaded while in use.  Unfortunately I don't have any
 > system which exhibits the problem.
 >
 > Perhaps you could try the attached patch?  (I'm also waiting for
 > some other folks to test the patch.)

 The patch was committed yesterday, so please retry the operation
 with an up-to-date build from HEAD.


 +--------------------+--------------------------+---------------------+
 | Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:   |
 | (Retired)          | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com   |
 | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org |
 +--------------------+--------------------------+---------------------+

State-Changed-From-To: feedback->closed
State-Changed-By: pgoyette@NetBSD.org
State-Changed-When: Tue, 20 Jul 2021 12:57:11 +0000
State-Changed-Why:
Fix committed, feedback timeout.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.