Re: Kernel panic during boot in usb_add_task

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

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