oh right, this one ...
John Baldwin
jhb at freebsd.org
Fri Dec 14 22:08:31 UTC 2012
On Tuesday, December 11, 2012 1:48:08 pm Sean Bruno wrote:
> On Tue, 2012-12-11 at 10:13 -0800, Sean Bruno wrote:
> > Finally got around to returning the Dell R620 series BIOS update that
> > breaks badly on FreeBSD. I suspect that there is an ACPI update going
> > on here that I need to figure out for -current. I'm going to disable
> > the pci bus that fails to attach via device hints and get an acpidump in
> > a bit.
>
> acpidump --> http://people.freebsd.org/~sbruno/r620_acpi.txt
> pciconf -lvcb --> http://people.freebsd.org/~sbruno/r620_pciconf.txt
>
> Problematic pci bus attach is on pcib6
>
> pcib6: <ACPI PCI-PCI bridge> at device 28.0 on pci0
> pcib6: domain 0
> pcib6: secondary bus 6
> pcib6: subordinate bus 6
> pcib6: no prefetched decode
> device_attach: pcib6 attach returned 6
> pcib6: <ACPI PCI-PCI bridge> irq 19 at device 28.7 on pci0
> panic: Bad tailq NEXT(0xffffffff814f3318->tqh_last) != NULL
>
>
> A couple of comments here. It sure *looks* like the failure to attach
> doesn't clean up after itself, which then leads to a *reuse* of pcib6
> data elements for pcib7!
>
> 1. we fail to attach to pcib6
> 2. we don't clean up properly on a failure to attach
> 3. we try to reuse the data structure that failed for the next pcib
> device.
Yes, it is known to not clean up after itself. Fixing that isn't entirely
trivial. Disable pcib6 instead of trying to disable pci6.
--
John Baldwin
More information about the freebsd-acpi
mailing list