NetBSD Problem Report #54023
From hauke@spg.tu-darmstadt.de Wed Feb 27 15:43:24 2019
Return-Path: <hauke@spg.tu-darmstadt.de>
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 F08F27A1EF
for <gnats-bugs@gnats.NetBSD.org>; Wed, 27 Feb 2019 15:43:23 +0000 (UTC)
Message-Id: <201902271543.x1RFhFIg026850@Aibel.nt.e-technik.tu-darmstadt.de>
Date: Wed, 27 Feb 2019 16:43:15 +0100 (CET)
From: Hauke Fath <hf@spg.tu-darmstadt.de>
Reply-To: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: Hauke Fath <hf@spg.tu-darmstadt.de>
Subject: assertion panic during shutdown
X-Send-Pr-Version: 3.95
>Number: 54023
>Category: kern
>Synopsis: assertion panic during shutdown
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Feb 27 15:45:00 +0000 2019
>Last-Modified: Wed Mar 13 14:30:01 +0000 2019
>Originator: Hauke Fath
>Release: NetBSD 8.99.34
>Organization:
Technische Universitaet Darmstadt
>Environment:
System: NetBSD Aibel.nt.e-technik.tu-darmstadt.de 8.99.34 NetBSD 8.99.34 (PINE64-$Revision$) #0: Tue Feb 26 14:51:31 CET 2019 hf@Hochstuhl:/var/obj/netbsd-builds/developer/evbarm/sys/arch/evbarm/compile/PINE64 evbarm
Architecture: aarch64
Machine: evbarm
>Description:
This pinebook panics during shutdown/reboot with an assertion
failure:
kernel disgnostic assertion "xfer-ux_status != USBD_CANCELLED" failed: file "[...]/sys/dev/usb/ehci.c", line 3264
Full stack trace at
<https://www2.nt.tu-darmstadt.de/~hf/netbsd/pinebook/usb_ehci_c-assertion.jpg>
It then locks up hard trying to dump core, and has to be
powered off.
>
How-To-Repeat:
Reboot pinebook.
<code/input/activities to reproduce the problem (multiple lines)>
>Fix:
No idea.
>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/54023: assertion panic during shutdown
Date: Wed, 27 Feb 2019 16:46:52 +0100
What usb devices do you have connected?
Martin
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org
Cc:
Subject: Re: kern/54023: assertion panic during shutdown
Date: Wed, 27 Feb 2019 17:21:34 +0100
On 2/27/19 4:50 PM, Martin Husemann wrote:
> What usb devices do you have connected?
An axe(4) and an urtwn(4) - but I have seen the panic (and, more often,
just a hard lock) also without any external USB devices attached.
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: re: kern/54023: assertion panic during shutdown
Date: Thu, 28 Feb 2019 06:35:45 +1100
not particular thoughts on the assert itself (which is fairly
new -- only added last year), however...
> It then locks up hard trying to dump core, and has to be
> powered off.
this part is probably related to the fact USB crashed and the
dump device is behind USB. it may be that USB dumps don't
work at all... i will see about testing this situation.
.mrg.
ps. actually, there is a known issue in usb abort still that
we haven't finished patching, so it may be related to that,
though the race is very hard now, compared to the old ways
these bugs could be triggered.
From: Hauke Fath <hauke.fath@gmail.com>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@NetBSD.org
Subject: re: kern/54023: assertion panic during shutdown
Date: Wed, 27 Feb 2019 20:47:23 +0100
On Wed, 27 Feb 2019 19:40:01 +0000 (UTC), matthew green wrote:
> > It then locks up hard trying to dump core, and has to be
> > powered off.
>
> this part is probably related to the fact USB crashed and the
> dump device is behind USB. it may be that USB dumps don't
> work at all... i will see about testing this situation.
The boot (and dump) device is
[ 2.094399] ld2 at sdmmc2:
<0x15:0x0100:AJTD4R:0x00:0x5340fa43:0x000>
[ 2.116224] ld2: 14910 MB, 7573 cyl, 64 head, 63 sec, 512
bytes/sect x 30535680 sectors
[ 2.116224] ld2: 8-bit width, HS200, 64 MB cache, 200.000 MHz
which hangs off simplebus. No USB involved, AFAICS.
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: re: kern/54023: assertion panic during shutdown
Date: Sat, 02 Mar 2019 08:01:54 +1100
the 5 finger copy of the crash bt:
vpanic
kern_assert
ehci_abort_pipe
usbd_ar_pipe
usbd_abort_pipe
uhidev_stop
uhidclose
cdev_close
spec_close
VOP_CLOSE
vn_close
closef
fd_free
exit1
sigexit
postsig
lwp_userret
syscall
el0_trap
From: matthew green <mrg@eterna.com.au>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: re: kern/54023: assertion panic during shutdown
Date: Sat, 02 Mar 2019 08:27:34 +1100
can you turn on USB_DEBUG and UHID_DEBUG, make sure that usb_debug
is set in sysctl, make sure ddb will be entered (ddb.onpanic=1),
and since the keyboard probably won't work (it is either the kbd
or mouse that is triggering this fault), also set ddb.commandonenter
to something like "show kernhist usbhist", then we may even get a
useful usb log of what it was doing before the crash. it may
scroll a lot -- but the really useful stuff is likely in the last
part, so hopefully a picture not video will suffice.
thanks.
.mrg.
ps: it occurs to me another test case that isn't reboot would be
to (remotely) use drvctl -d to detach the ukbd/ums devices and
see if either or both trigger this problem directly there, or if
something else is the trigger..
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
matthew green <mrg@eterna.com.au>
Subject: Re: kern/54023: assertion panic during shutdown
Date: Wed, 6 Mar 2019 17:31:56 +0100
On 3/1/19 10:30 PM, matthew green wrote:
> can you turn on USB_DEBUG and UHID_DEBUG, make sure that usb_debug
> is set in sysctl, make sure ddb will be entered (ddb.onpanic=1),
This is the log from msgbuf after 'reboot 0x04':
[ 266.812560] panic: kernel diagnostic assertion "xfer->ux_status !=
USBD_CANCELLED" failed: file
"/public/netbsd-developer/sys/dev/usb/ehci.c", line 3264
[ 266.832561] cpu3: Begin traceback...
[ 266.832561] trace fp ffffffc044d87820
[ 266.842567] fp ffffffc044d87840 vpanic() at ffffffc000439570
netbsd:vpanic+0x198
[ 266.852563] fp ffffffc044d878a0 kern_assert() at ffffffc000569ae4
netbsd:kern_assert+0x5c
[ 266.862565] fp ffffffc044d87930 ehci_abort_xfer() at
ffffffc000178ac4 netbsd:ehci_abort_xfer+0x2c4
[ 266.872565] fp ffffffc044d87990 usbd_ar_pipe() at ffffffc0000c1000
netbsd:usbd_ar_pipe+0x1c8
[ 266.882566] fp ffffffc044d879e0 usbd_abort_pipe() at
ffffffc0000c1390 netbsd:usbd_abort_pipe+0x28
[ 266.892566] fp ffffffc044d87a00 uhidev_stop() at ffffffc0000de8e8
netbsd:uhidev_stop+0x30
[ 266.902568] fp ffffffc044d87a20 uhidclose() at ffffffc0000df374
netbsd:uhidclose+0x64
[ 266.912568] fp ffffffc044d87a50 cdev_close() at ffffffc000425d88
netbsd:cdev_close+0xb8
[ 266.922570] fp ffffffc044d87a90 spec_close() at ffffffc0004ae8c0
netbsd:spec_close+0x1a0
[ 266.932570] fp ffffffc044d87ae0 VOP_CLOSE() at ffffffc0004a1fb4
netbsd:VOP_CLOSE+0x3c
[ 266.942571] fp ffffffc044d87b20 vn_close() at ffffffc00049a5ac
netbsd:vn_close+0x34
[ 266.952571] fp ffffffc044d87b50 closef() at ffffffc0003d7dd8
netbsd:closef+0x50
[ 266.962573] fp ffffffc044d87b90 fd_free() at ffffffc0003db2e4
netbsd:fd_free+0x1ac
[ 266.972573] fp ffffffc044d87c00 exit1() at ffffffc0003e2c48
netbsd:exit1+0xe8
[ 266.982574] fp ffffffc044d87cc0 sigexit() at ffffffc000407da8
netbsd:sigexit+0x1d8
[ 266.992575] fp ffffffc044d87d10 postsig() at ffffffc00040815c
netbsd:postsig+0x26c
[ 267.002576] fp ffffffc044d87db0 lwp_userret() at ffffffc0003ecc20
netbsd:lwp_userret+0x1a0
[ 267.012577] fp ffffffc044d87e00 userret() at ffffffc00007063c
netbsd:userret+0x6c
[ 267.022578] fp ffffffc044d87e20 syscall() at ffffffc0000703cc
netbsd:syscall+0x104
[ 267.042580] tf ffffffc044d87ed0 el0_trap() at ffffffc00006ea10
netbsd:el0_trap
[ 267.042580] ---- trapframe 0xffffffc044d87ed0 (304 bytes) ----
[ 267.052581] pc=0000f707d44a3e90, spsr=0000000080000000
[ 267.052581] esr=0000000056000003, far=ffffffc0440d9000
[ 267.062581] x0=0000000000000003, x1=0000ffffffe93ba8
[ 267.072582] x2=0000000000000001, x3=0000f707d4586c98
[ 267.072582] x4=0000ffffffe928b9, x5=0000000000000000
[ 267.082583] x6=0000ffffffe9318c, x7=0000000000000000
[ 267.082583] x8=0000ffffffe928b9, x9=0000000000000011
[ 267.092584] x10=0000000000000004, x11=0000000000000001
[ 267.092584] x12=000003ffffffa4c0, x13=000003ffffffa4c4
[ 267.102585] x14=0000f707d433c254, x15=0000ffffffe93110
[ 267.112585] x16=0000000200112b38, x17=0000f707d44a3e90
[ 267.112585] x18=0000000000004040, x19=0000ffffffe94faf
[ 267.122587] x20=0000ffffffe94fe8, x21=0000000000000008
[ 267.122587] x22=0000000200112000, x23=0000f707d433c140
[ 267.132587] x24=0000ffffffe93ba8, x25=0000ffffffe955a5
[ 267.132587] x26=0000ffffffe955b3, x27=0000000000000000
[ 267.142588] x28=0000000000000001, fp=x29=0000000000000000
[ 267.142588] lr=x30=00000002001020fc, sp=0000ffffffe93af0
[ 267.152589] ------------------------------------------------
[ 267.162590] cpu3: End traceback...
rebooting...
> and since the keyboard probably won't work (it is either the kbd
> or mouse that is triggering this fault),
The kbd actually worked, but ...
> also set ddb.commandonenter
> to something like "show kernhist usbhist", then we may even get a
> useful usb log of what it was doing before the crash. it may
> scroll a lot -- but the really useful stuff is likely in the last
> part, so hopefully a picture not video will suffice.
'show kernhist' told me putput would exceed 50000 characters, and 'show
usbhist" said it didn't exist.
I will rebuild with larger DDB_HISTORY_SIZE and retry.
> ps: it occurs to me another test case that isn't reboot would be
> to (remotely) use drvctl -d to detach the ukbd/ums devices and
> see if either or both trigger this problem directly there, or if
> something else is the trigger..
I tried that, it paniced anyway.
Cheerio,
hauke
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org
Subject: Re: kern/54023: assertion panic during shutdown
Date: Wed, 6 Mar 2019 17:53:24 +0100
On 3/6/19 5:35 PM, Hauke Fath wrote:
> 'show kernhist' told me putput would exceed 50000 characters, and 'show
> usbhist" said it didn't exist.
>
> I will rebuild with larger DDB_HISTORY_SIZE and retry.
There was no output at all from 'show kernhist' this time, nor any error
message. And I had to enter it manually, since
options DDB_COMMANDONENTER="show kernhist usbhist"
was not executed on entry.
Cheerio,
hauke
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org
Cc:
Subject: Re: kern/54023: assertion panic during shutdown
Date: Wed, 6 Mar 2019 18:18:14 +0100
On 3/6/19 5:55 PM, Hauke Fath wrote:
> There was no output at all from 'show kernhist' this time, nor any error
> message.
Scratch that, I overlooked setting the usb sysctl variable. ddb is still
scrolling...
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org
Subject: Re: kern/54023: assertion panic during shutdown
Date: Thu, 7 Mar 2019 10:02:07 +0100
On 3/1/19 10:30 PM, matthew green wrote:
> set ddb.commandonenter
> to something like "show kernhist usbhist", then we may even get a
> useful usb log of what it was doing before the crash. it may
> scroll a lot -- but the really useful stuff is likely in the last
> part [...]
Interesting...
This morning, the pinebook had rebooted. The message buffer starts with
= 0xffff0000bf79f8a0, flags = 0x4, pipe = 0xffff0000bf67ac10, running = 1
1551890685.395526 usb_insert_transfer#5404@2: called!
1551890685.395527 usb_insert_transfer#5404@2: xfer = 0xffff0000bf79f8a0
pipe = 0xffff0000bf67ac10 running = 1 timeout = 0
1551890685.395528 usb_insert_transfer#5404@2: <- done xfer
0xffff0000bf79f8a0, err 1
1551890685.395529 usbd_transfer#5404@2: <- done transfer
0xffff0000bf79f8a0, err = 1
1551890685.395529 usbd_transfer#5404@2: <- done xfer 0xffff0000bf79f8a0,
not sync (err 1)
1551890685.395530 usbd_start_next#5868@2: called!
1551890685.395531 usbd_start_next#5868@2: pipe = 0xffff0000bf67ac10,
xfer = 0xffff0000bf79f8a0
db{2}>
bdeletematchsearchwbreakdmesgnextsetwatchbtdwatchpshowwhatiscexamineprintsiftingwritecallexitpsstepxcallouthelpquitsynccontinuekillreboottracedmachinesuntildb{2}>
db{2}> [ 62
.0496787] Bad character in number
db{2}> [ 62.0496787] Bad character
[ 62.049679] ?
db{2}> [ 62.0496787] Bad character in number
db{2}> [ 62.0496787] Bad character in number
db{2}> [ 62.0496787] Bad character
followed by more random input (I had set 'options DDB_TEE_MSGBUF=1') and
several panics like
fp ffffffc044d8f840 cpu_Debugger() at ffffffc00006eacc netbsd:cpu_Debugger
fp ffffffc044d8f8a0 kern_assert() at ffffffc000569bc4
netbsd:kern_assert+0x5c
fp ffffffc044d8f930 ehci_abort_xfer() at ffffffc000178ac4
netbsd:ehci_abort_xfer+0x2c4
fp ffffffc044d8f990 usbd_ar_pipe() at ffffffc0000c1000
netbsd:usbd_ar_pipe+0x1c8
fp ffffffc044d8f9e0 usbd_abort_pipe() at ffffffc0000c1390
netbsd:usbd_abort_pipe+0x28
fp ffffffc044d8fa00 uhidev_stop() at ffffffc0000de8e8
netbsd:uhidev_stop+0x30
fp ffffffc044d8fa20 uhidclose() at ffffffc0000df374 netbsd:uhidclose+0x64
fp ffffffc044d8fa50 cdev_close() at ffffffc000425e58 netbsd:cdev_close+0xb8
fp ffffffc044d8fa90 spec_close() at ffffffc0004ae990 netbsd:spec_close+0x1a0
fp ffffffc044d8fae0 VOP_CLOSE() at ffffffc0004a2084 netbsd:VOP_CLOSE+0x3c
fp ffffffc044d8fb20 vn_close() at ffffffc00049a67c netbsd:vn_close+0x34
fp ffffffc044d8fb50 closef() at ffffffc0003d7ea8 netbsd:closef+0x50
fp ffffffc044d8fb90 fd_free() at ffffffc0003db3b4 netbsd:fd_free+0x1ac
fp ffffffc044d8fc00 exit1() at ffffffc0003e2d18 netbsd:exit1+0xe8
fp ffffffc044d8fcc0 sigexit() at ffffffc000407e78 netbsd:sigexit+0x1d8
fp ffffffc044d8fd10 postsig() at ffffffc00040822c netbsd:postsig+0x26c
fp ffffffc044d8fdb0 lwp_userret() at ffffffc0003eccf0
netbsd:lwp_userret+0x1a0
fp ffffffc044d8fe00 userret() at ffffffc00007063c netbsd:userret+0x6c
fp ffffffc044d8fe20 syscall() at ffffffc0000703cc netbsd:syscall+0x104
tf ffffffc044d8fed0 el0_trap() at ffffffc00006ea10 netbsd:el0_trap
till the machine eventually rebooted:
[ 62.049679] dump to dev 92,17 not possible
[ 62.049679] rebooting...
Is there any way to limit the output of ddb's 'show kernhhist'? The man
page entry is kind of obscure...
Cheerio,
hauke
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@netbsd.org
Subject: Re: kern/54023: assertion panic during shutdown
Date: Thu, 7 Mar 2019 10:28:54 +0100
On 3/1/19 10:30 PM, matthew green wrote:
> can you turn on USB_DEBUG and UHID_DEBUG, make sure that usb_debug
> is set in sysctl, make sure ddb will be entered (ddb.onpanic=1),
> and since the keyboard probably won't work (it is either the kbd
> or mouse that is triggering this fault), also set ddb.commandonenter
> to something like "show kernhist usbhist", then we may even get a
> useful usb log of what it was doing before the crash. it may
> scroll a lot -- but the really useful stuff is likely in the last
> part,
I tried a 'show kernhist ,100' - not clear what the meaning of "address"
is here:
[ 501.173862] panic: kernel diagnostic assertion "xfer->ux_status !=
USBD_CANCELLED" failed: file
"/public/netbsd-developer/sys/dev/usb/ehci.c", line 3264
[ 501.193860] cpu1: Begin traceback...
[ 501.193860] trace fp ffffffc044d57820
[ 501.203861] fp ffffffc044d57840 vpanic() at ffffffc000439640
netbsd:vpanic+0x198
[ 501.203861] fp ffffffc044d578a0 kern_assert() at ffffffc000569bc4
netbsd:kern_assert+0x5c
[ 501.223864] fp ffffffc044d57930 ehci_abort_xfer() at
ffffffc000178ac4 netbsd:ehci_abort_xfer+0x2c4
[ 501.233862] fp ffffffc044d57990 usbd_ar_pipe() at ffffffc0000c1000
netbsd:usbd_ar_pipe+0x1c8
[ 501.243863] fp ffffffc044d579e0 usbd_abort_pipe() at
ffffffc0000c1390 netbsd:usbd_abort_pipe+0x28
[ 501.253864] fp ffffffc044d57a00 uhidev_stop() at ffffffc0000de8e8
netbsd:uhidev_stop+0x30
[ 501.263864] fp ffffffc044d57a20 uhidclose() at ffffffc0000df374
netbsd:uhidclose+0x64
[ 501.273865] fp ffffffc044d57a50 cdev_close() at ffffffc000425e58
netbsd:cdev_close+0xb8
[ 501.283868] fp ffffffc044d57a90 spec_close() at ffffffc0004ae990
netbsd:spec_close+0x1a0
[ 501.293868] fp ffffffc044d57ae0 VOP_CLOSE() at ffffffc0004a2084
netbsd:VOP_CLOSE+0x3c
[ 501.303868] fp ffffffc044d57b20 vn_close() at ffffffc00049a67c
netbsd:vn_close+0x34
[ 501.313869] fp ffffffc044d57b50 closef() at ffffffc0003d7ea8
netbsd:closef+0x50
[ 501.323870] fp ffffffc044d57b90 fd_free() at ffffffc0003db3b4
netbsd:fd_free+0x1ac
[ 501.333870] fp ffffffc044d57c00 exit1() at ffffffc0003e2d18
netbsd:exit1+0xe8
[ 501.343872] fp ffffffc044d57cc0 sigexit() at ffffffc000407e78
netbsd:sigexit+0x1d8
[ 501.353872] fp ffffffc044d57d10 postsig() at ffffffc00040822c
netbsd:postsig+0x26c
[ 501.363873] fp ffffffc044d57db0 lwp_userret() at ffffffc0003eccf0
netbsd:lwp_userret+0x1a0
[ 501.373874] fp ffffffc044d57e00 userret() at ffffffc00007063c
netbsd:userret+0x6c
[ 501.383875] fp ffffffc044d57e20 syscall() at ffffffc0000703cc
netbsd:syscall+0x104
[ 501.403877] tf ffffffc044d57ed0 el0_trap() at ffffffc00006ea10
netbsd:el0_trap
[ 501.403877] ---- trapframe 0xffffffc044d57ed0 (304 bytes) ----
[ 501.413877] pc=0000fc069c623e90, spsr=0000000080000000
[ 501.413877] esr=0000000056000003, far=ffffffc0440dd000
[ 501.423878] x0=0000000000000003, x1=0000ffffff999318
[ 501.433879] x2=0000000000000001, x3=0000fc069c706c98
[ 501.433879] x4=0000ffffff998029, x5=0000000000000000
[ 501.443880] x6=0000ffffff9988fc, x7=0000000000000000
[ 501.443880] x8=0000ffffff998029, x9=0000000000000011
[ 501.453881] x10=0000000000000004, x11=0000000000000001
[ 501.453881] x12=000003fffffe661e, x13=000003fffffe6622
[ 501.463882] x14=0000fc069c43c254, x15=0000ffffff998880
[ 501.473883] x16=0000000200112b38, x17=0000fc069c623e90
[ 501.473883] x18=0000000000004040, x19=0000ffffff99a71f
[ 501.483883] x20=0000ffffff99a758, x21=0000000000000008
[ 501.483883] x22=0000000200112000, x23=0000fc069c43c140
[ 501.493884] x24=0000ffffff999318, x25=0000ffffff99ad15
[ 501.493884] x26=0000ffffff99ad23, x27=0000000000000000
[ 501.503885] x28=0000000000000001, fp=x29=0000000000000000
[ 501.503885] lr=x30=00000002001020fc, sp=0000ffffff999260
[ 501.513886] ------------------------------------------------
[ 501.523887] cpu1: End traceback...
Stopped in pid 549.1 (usbhidaction) at netbsd:cpu_Debugger+0x4:
[ 501.5238873] ret
[ 501.523887] ?
db{1}> [ 501.5238873] kernhist 'usbhist': at 0xffffffc000a31820 total
50000 next free 36181
db{1}> 1551944051.721767 usb_insert_transfer#14265@1: xfer =
0xffff0000bf79a5c0 pipe = 0xffff0000bee80e58 running = 0 timeout = 10000
1551944051.721768 usb_insert_transfer#14265@1: <- done xfer
0xffff0000bf79a5c0, err 0
1551944051.721785 usbd_transfer#14265@1: <- done transfer
0xffff0000bf79a5c0, err = 1
1551944051.721786 usbd_transfer#14265@1: <- done xfer
0xffff0000bf79a5c0, not sync (err 1)
1551944051.721929 usb_schedsoftintr#14066@3: called!
1551944051.721951 usb_rem_task#14271@3: called!
1551944051.721956 usb_transfer_complete#14271@3: called!
1551944051.721956 usb_transfer_complete#14271@3: pipe =
0xffff0000bee80e58 xfer = 0xffff0000bf79a5c0 status = 0 actlen = 282
1551944051.721957 usb_transfer_complete#14271@3: xfer
0xffff0000bf79a5c0: repeat 0 new head = 0
1551944051.721958 usb_transfer_complete#14271@3: xfer 0xffff0000bf79a5c0
doing done 0xffffffc000172158
1551944051.721959 usb_transfer_complete#14271@3: xfer 0xffff0000bf79a5c0
doing callback 0xffffffc000104230 status 0
1551944051.721965 usbd_start_next#14271@3: called!
1551944051.721966 usbd_start_next#14271@3: pipe = 0xffff0000bee80e58,
xfer = 0
1551944051.737180 usb_schedsoftintr#14067@2: called!
1551944051.737198 usb_transfer_complete#16762@1: xfer 0xffff0000bf79ab80
doing done 0xffffffc0001721e8
1551950377.204744 usb_transfer_complete#16762@1: xfer 0xffff0000bf79ab80
doing callback 0xffffffc0000dddb8 status 0
1551950377.204760 usbd_start_next#16761@1: called!
1551950377.204761 usbd_start_next#16761@1: pipe = 0xffff0000bf90c0c8,
xfer = 0xffff0000bf79ab80
db{1}>
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org
Cc:
Subject: Re: kern/54023: assertion panic during shutdown
Date: Wed, 13 Mar 2019 15:21:46 +0100
Okay...
Removing the equivalent of
<https://wiki.netbsd.org/ports/evbarm/allwinner/#index2h2> from the
machine's rc.local makes the panic go away.
I guess something here needs to clean up after itself, and doesn't?
Cheerio,
hauke
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.43 2018/01/16 07:36:43 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home