stable/9 panic Bad tailq NEXT(0xffffffff80e52660->tqh_last) !=
NULL
John Baldwin
jhb at freebsd.org
Mon Oct 1 12:58:21 UTC 2012
On Thursday, September 27, 2012 4:53:49 pm Sean Bruno wrote:
> On Thu, 2012-09-27 at 10:52 -0700, Sean Bruno wrote:
> > >
> > > > pcib7: <ACPI PCI-PCI bridge> irq 19 at device 28.7 on pci0
> > > > panic: Bad tailq NEXT(0xffffffff80e52660->tqh_last) != NULL
> > > > cpuid = 0
> > > > KDB: stack backtrace:
> > > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> > > > kdb_backtrace() at kdb_backtrace+0x37
> > > > panic() at panic+0x1d8
> > > > rman_init() at rman_init+0x17c
> > > > pcib_alloc_window() at pcib_alloc_window+0x9f
> > > > pcib_attach_common() at pcib_attach_common+0x457
> > > > acpi_pcib_pci_attach() at acpi_pcib_pci_attach+0x1c
> > > > device_attach() at device_attach+0x72
> > > > bus_generic_attach() at bus_generic_attach+0x1a
> > > > acpi_pci_attach() at acpi_pci_attach+0x164
> > > > device_attach() at device_attach+0x72
> > > > bus_generic_attach() at bus_generic_attach+0x1a
> > > > acpi_pcib_attach() at acpi_pcib_attach+0x1a7
> > > > acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0x1f6
> > > > device_attach() at device_attach+0x72
> > > > bus_generic_attach() at bus_generic_attach+0x1a
> > > > acpi_attach() at acpi_attach+0xbc1
> > > > device_attach() at device_attach+0x72
> > > > bus_generic_attach() at bus_generic_attach+0x1a
> > > > nexus_acpi_attach() at nexus_acpi_attach+0x69
> > > > device_attach() at device_attach+0x72
> > > > bus_generic_new_pass() at bus_generic_new_pass+0xd6
> > > > bus_set_pass() at bus_set_pass+0x7a
> > > > configure() at configure+0xa
> > > > mi_startup() at mi_startup+0x77
> > > > btext() at btext+0x2c
> > > > Uptime: 1s
> > > > Automatic reboot in 15 seconds - press a key on the console to abort
> > > > --> Press a key on the console to reboot,
> > > > --> or switch off the system now.
> > > >
> > >
> > > --
> > > Andriy Gapon
> > >
> >
> > resurrecting this thread from my sent items folder, not sure if
> > mailman will thread this correctly or not
> >
> > Anyway, after disabling the "broken" pci bridge via some hackery
> > that jhb and eadler had lying around, I was able to get the r620 up
> > on the "new" BIOS and get an acpidump before and after the firmware update.
> >
> > I can poke a the machines, but I don't quite see in this nonsense where
> > it breaks acpi_pcib_pci_attach(). Where should I start poking next?
> >
> >
> > http://people.freebsd.org/~sbruno/acpi_112_r620.txt
> >
> > http://people.freebsd.org/~sbruno/acpi_126_r620.txt
> >
> >
>
> For fun, I added the pciconf output to see if there's anything obviously
> wrong with pcib7. But, as usual, I have no idea how to interpret this.
>
> http://people.freebsd.org/~sbruno/r620_pciconf.txt
Can you add extra printfs to see where exactly attach is failing? I would
start with the attach routine in sys/dev/acpica/acpi_pcib_pci.c:
static int
acpi_pcib_pci_attach(device_t dev)
{
struct acpi_pcib_softc *sc;
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
pcib_attach_common(dev);
sc = device_get_softc(dev);
sc->ap_handle = acpi_get_handle(dev);
return (acpi_pcib_attach(dev, &sc->ap_prt, sc->ap_pcibsc.secbus));
}
Hmm, so that can only fail inside of acpi_pcib_attach() in
sys/dev/acpica/acpi_pcib.c. I would add printfs to annotate that.
--
John Baldwin
More information about the freebsd-stable
mailing list