Michael Neumann wrote:
quoted text
> 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