On Mon, Dec 03, 2018 at 01:44:38PM +0100, Mark Kettenis wrote:
> > Date: Mon, 3 Dec 2018 12:51:32 +0100
> > From: Nils Frohberg <ni...@tako.de>
> >
> > Hi,
> >
> > is it safe to call usbd_delay_ms() from under splusb()? In axen(4),
> > axen_rxeof() is called from usb_transfer_complete() which runs at
> > splusb() (called via usbd_transfer()).
>
> It is perfectly fine to call usbd_delay_ms() from within code
> protected by splusb().  It is not ok to call this code from interrupt
> context though.
>

Thanks for the reply. Maybe I didn't dig deep enough yet.

> > The following patch prevents a panic on my system.
>
> What panic?  And what is the ddb backtrace you see?

Unfortunately the box locks up and I have to cycle its power to
resume. The following is OCRed/hand copied.

axen0: axen_rxeof: hdr_offset (13518) > total_len (12288)
splassert: assertwaitok: want 0 have 5
Starting stack trace...
assertwaitok() at assertwaitok+0x40
mi_switch() at mi_switch+0x4c
sleep_finish(7f46a7a3c4f58676,ffff800031797fb0) at sleep_finish+0x7f
sleep_finish_all(35d5abeefe2b03b6,ffff800031797fb0) at sleep_finish_all+0x1f
tsleep(966025df8a2b3822,34ce,ffff800000a8c000,ffffff0079fed000) at tsleep+0xcd
axen_rxeof(a32d84d5ed79e3d7,ffffff027e480878,ffff800000e33000) at 
axen_rxeof+0x368
usb_transfer_complete(7f61ed570abf387f) at usb_transfer_complete+0x1ff
xhci_event_dequeue(1) at xhci_event_dequeue+0xfd
xhci_softintr(27dca8a8be38a839) at xhci_softintr+0x30
softintr_dispatch(e606342f3f0cdd) at softintr_dispatch+0xfc
Xsoftnet(4,ffffffff8193c2b0,4,18041969,0,d) at Xsoftnet+0x1f
Xspllower(1aae5abe56c575fd,ffffffff81d35ab8,ffffffff814cb23f,ffffffff81d35aa8,ffffffff81d35aa0,826bd2fe661a86e9)
 at XSpllower+0x19
softintr_dispatch(e606342f3f002d) at softintr_dispatch+0xed
Xsoftclock(1aae5abe56b35319,ffffffff8109cff0,ffffffff814cb23f,0,ffff8000fffff9c8,826bd2fe661a86e9)
 at XSoftclock+0x1f
sched_idle(0) at sched_idle+0x1b9
end trace frame: 0x0, count: 242
End of stack trace.
panic: kernel diagnostic assertion ”p->p_wchan == NULL" failed: file 
"/usr/src/sys/kern/kern_sched.c", line 338
Stopped at      db_enter+0x12:  popq    %r11
    TID    PID    UID     PRFLAGS     PFLAGS  CPU  COMMAND
db_enter() at db_enter+0x12
panic() at panic+0x120
assert(ffffffff816da0d4,ffff800031797ea0,ffffffff8109cff0,ffff8000fffff9c8) at 
__assert+0x24
sched_chooseproc() at sched_chooseproc+0x241
mi_switch() at mi_switch+0x1b4
sleep_finish(7f46a7a3c4f58676,ffff800031797fb0) at sleep_finish+0x7f
sleep_finish_all(35d5abeefe2b03b6,ffff800031797fb0) at sleep_finish_all+0x1f
tsleep(966025df8a2b3822,34ce,ffff800000a80000,ffffff0079fed000) at tsleep+0xcd
axen_rxeof(a32d84d5ed79e3d7,ffffff027e480878,ffff800000e33000) at axen_rxeof+0x 
368
usb_transfer_complete(7f61ed570abf387f) at usb_transfer_complete+0x1ff
xhci_event_dequeue(1) at xhci_event_dequeue+0xfd
xhci_softintr(27dca8a8be38a839) at xhci_softintr+0x30
softintr_dispatch(e606342f3f00dd) at softintr_dispatch+0xfc
Xsoftnet(4,ffffffff8193c2b0,4,18041969,0,d) at Xsoftnet+0x1f
end trace frame: 0xffff800031798280, count: 0
https://www.openbsd.org/ddb.htm1 describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{0}>

>
> > Index: sys/dev/usb/if_axen.c
> > ===================================================================
> > RCS file: /cvs/src/sys/dev/usb/if_axen.c,v
> > retrieving revision 1.25
> > diff -u -r1.25 if_axen.c
> > --- sys/dev/usb/if_axen.c   12 Jun 2018 06:59:27 -0000      1.25
> > +++ sys/dev/usb/if_axen.c   30 Nov 2018 14:47:49 -0000
> > @@ -937,7 +937,6 @@
> >     /* sanity check */
> >     if (hdr_offset > total_len) {
> >             ifp->if_ierrors++;
> > -           usbd_delay_ms(sc->axen_udev, 100);
> >             goto done;
> >     }
> >
> >
> >
>

Reply via email to