Date: Mon, 1 Oct 2012 08:47:53 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org, sbruno@freebsd.org Cc: Andriy Gapon <avg@freebsd.org> Subject: Re: stable/9 panic Bad tailq NEXT(0xffffffff80e52660->tqh_last) != NULL Message-ID: <201210010847.53984.jhb@freebsd.org> In-Reply-To: <1348779229.10543.11.camel@powernoodle.corp.yahoo.com> References: <1342197082.2664.4.camel@powernoodle.corp.yahoo.com> <1348768344.10543.7.camel@powernoodle.corp.yahoo.com> <1348779229.10543.11.camel@powernoodle.corp.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201210010847.53984.jhb>