Kernel panic during boot in usb_add_task

[Bill Hacker]

Michael Neumann wrote:
Michael Neumann wrote:
Michael Neumann schrieb:
Bill Hacker schrieb:
Michael Neumann wrote:
For starters, what does NetBSD report as the hardware and can you 
capture *any* scan, dmesg, or other report from FreeBSD 7-BETA3 or 
DFLY?
I could track it down where the panic occurs:

http://opengrok.creo.hu/dragonfly/xref/src/sys/bus/usb/usb.c#374

More specifically:

  http://opengrok.creo.hu/dragonfly/xref/src/sys/sys/queue.h#428

  *(head)->tqh_last = (elm);

This expands to:

  *(&taskq->tasks)->tgh_last = task;

There a NULL pointer is dereferenced somehow.

usb_add_task is called from uhci_timeout:

  http://opengrok.creo.hu/dragonfly/xref/src/sys/bus/usb/uhci.c#1428

It seems to get only called when a timeout occurs. That's maybe that I 
am the only one having those problems :)

I couldn't track it down further. My pure guess would be that it would 
not panic if "uhci_abort_xfer(&uxfer->xfer, USBD_TIMEOUT);" is called 
instead (sc->sc_dying == 1), but I can't build a kernel right now, so I 
can't change the code and build an ISO image.

Any further ideas?

Regards,

  Michael
Looks to be decent detective work to me!

But I quit coding in 'C' the same year the 386-16 was launched,

;-)

. ..so we'll now need to wait for a developer to weigh-in.

Meanwhile - it is not *supposed to* matter - but on any OS that you are able to 
boot with the devices all optioned ON, can you confirm use of shared interrupts 
or NOT?

Ex:

Tyan Tomcat - some sharing:

triligon# ps -xa | grep '\[irq'
   22  ??  WL     0:00.00 [irq9: acpi0]
   23  ??  WL     0:07.04 [irq16: bge0 uhci3]
   24  ??  WL     0:00.02 [irq17: bge1]
   25  ??  WL     0:00.00 [irq23: uhci0 ehci0]
   29  ??  WL     0:23.97 [irq19: uhci1+]
   31  ??  WL     0:00.00 [irq18: uhci2+]
   35  ??  WL     0:00.00 [irq14: ata0]
   36  ??  WL     0:00.00 [irq15: ata1]
   37  ??  WL     0:00.00 [irq1: atkbd0]
   38  ??  WL     0:00.00 [irq12: psm0]
   40  ??  WL     0:00.00 [irq7: ppc0]
 3401  p0  S+     0:00.00 grep \\[irq
HP-Compaq Proliant - nothing shared:

datareplica# ps -xa | grep '\[irq'
   19  ??  WL     0:00.00 [irq9: acpi0]
   20  ??  WL     0:07.15 [irq76: ciss0]
   22  ??  WL     0:01.68 [irq72: em0]
   23  ??  WL     3:58.75 [irq73: em1]
   24  ??  WL     0:11.54 [irq24: mpt0]
   26  ??  WL     0:00.00 [irq25: mpt1]
   28  ??  WL     0:04.47 [irq16: uhci0]
   31  ??  WL     0:00.00 [irq19: uhci1]
   33  ??  WL     0:00.00 [irq23: ehci0]
   35  ??  WL     2:15.89 [irq17: bge0]
   36  ??  WL     0:00.00 [irq14: ata0]
   37  ??  WL     0:00.00 [irq15: ata1]
   40  ??  WL     0:00.00 [irq1: atkbd0]
   41  ??  WL     0:00.00 [irq12: psm0]
   42  ??  WL     0:00.00 [irq7: ppc0]
Asus P5K (with 'fast' PCI-e empty).
Poop hits the fan bigtime PCI-wise (one PCI-attached NIC, max) if that slot is used.
   25  ??  WL     0:00.00 [irq9: acpi0]
   26  ??  WL     0:00.00 [irq16: de0 uhci0+]
   30  ??  WL     0:00.00 [irq21: uhci1]
   32  ??  WL     0:00.00 [irq18: rl1 uhci2++]
   35  ??  WL     0:00.12 [irq17: rl0 atapci1]
   36  ??  WL     0:00.00 [irq23: uhci3 ehci1]
   38  ??  WL     0:00.00 [irq19: uhci4]
   42  ??  WL     2:06.03 [irq22: atapci2+]
   43  ??  WL     0:00.07 [irq1: atkbd0]
   44  ??  WL     0:00.00 [irq14: ata0]
   45  ??  WL     0:00.00 [irq15: ata1]
Mind - this may not have anything to do with the issue.

But fast peripherals - even just init'ing- can be quite greedy, and it is a 
cheaply made observation.

Bill