Timo Buhrmester <t...@math.uni-bonn.de> writes:
> Apparently out of nothing, one of our servers paniced.
>
>
> uname -a gives:
>
> | NetBSD trave.math.uni-bonn.de 8.2_STABLE NetBSD 8.2_STABLE
> | (MI-Server) #17: Fri Jul 16 14:01:03 CEST 2021
> | supp...@trave.math.uni-bonn.de:/var/work/obj-8/sys/arch/amd64/compile/miserv
> | amd64
My impression is that there have been a lot of USB fixes since 8.
> I've transcribed the panic message and backtrace:
>
> | ohci0: 1 scheduling overruns
> | ugen0: detached
> | ugen0: at uhub4 port 2 (addr 2) disconnected
> | ugen0 at uhub4 port 2
> | ugen0: Phoenixtec Power (0x6da) USB Cable (V2.00) (0x02), rev 1.00/0.06,
> addr 2
> | uvm_fault(0xfffffe82574c2458, 0x0, 1) -> e
> | fatal page fault in supervisor mode
> | trap type 6 code 0 rip 0xffffffff802f627e cs 0x8 rflags 0x10246 cr2 0x2
> ilevel 6 (NB: could be ilevel 0 as well) rsp 0xffff80013f482c10
> | curlwp 0xfffffe83002b2000 pid 8393.1 lowest kstack 0xffff80013f4802c0
> | kernel: page fault trap, code=0
> | Stopped in pid 8393.1 (nutdrv_qx_usb) at netbsd:ugen_get_cdesc+0xb1:
> | movzwl 2(%rax),%edx
> | db{2}> bt
> | ugen_get_cdesc() at netbsd:ugen_get_cdesc+0xb1
> | ugenioctl() at netbsd:ugenioctl+0x9a4
> | cdev_ioctl() at netbsd:cdev_ioctl+0xb4
> | VOP_IOCTL() at netbsd:VOP_IOCTL+0x54
> | vn_ioctl() at netbsd:vn_ioctl+0xa6
> | sys_ioctl() at netbsd:sys_ioctl+0x11a
> | syscall() at netbsd:syscall+0x1ec
> | --- syscall (number 54) ---
> | 7a73c9eff13a:
> | db{2}>
>
> Any idea what's going on?
It can always be hardware. (Even if one can argue bad hardware should never
lead to panic.) I'm not saying it is, or is likely, but keep that in
mind.
You didn't give timing. If this immediately followed the disconnnect,
it's perhaps a bug in ugen to do something after the device is gone. It
may be that this bug has always been there and that normally the UPS
doesn't disconnect, or you hit a bad race.
Try updating to 9 or 10 :-)
