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:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Oct 07 12:10:00 +0000 2020
>Last-Modified:  Wed Oct 07 21:55:01 +0000 2020
>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:

>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

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