ACPI errors on amd64 (sempron)

[John Baldwin]

On Thursday 27 October 2005 08:56 pm, Nate Lawson wrote:
> Jung-uk Kim wrote:
> > On Thursday 27 October 2005 08:08 pm, Nate Lawson wrote:
> >>Jung-uk Kim wrote:
> >>>It's already fixed in (soon to be imported) ACPICA-20051021 code.
> >>
> >>There's no way we can get acpi-ca tested in -current and MFC'd
> >>before 6.0.  Instead, we should MFC just the logic Intel changed in
> >>the header file to 6.0.
> >
> > IMHO, I think there's not enough time to do any fix at this point.  I
> > think we should fix it *after* 6.0-RELEASE because it only fixes half
> > of his problem.
>
> I disagree.  It's very clear what the alignment requirements are on
> amd64 and that acpi-ca is being too strict, harming an actual
> implementation.

I think it only shuts up a warning, does it actually change the behavior?

> > In fact, I have seen somebody else had similar problem:
> >
> > http://bsdforum.or.kr/viewtopic.php?p=5414#5414
> >
> > It's Korean BSD User Forum but you may be able to read this:
> >
> > pci_link26: BIOS IRQ 10 for -2145771032.1.INTA is invalid
> > pci_link21: BIOS IRQ 11 for -2145771032.2.INTA is invalid
> > pci_link27: BIOS IRQ 3 for -2145771032.2.INTB is invalid
> > pci_link23: BIOS IRQ 10 for -2145771032.10.INTA is invalid
> > pci_link24: BIOS IRQ 11 for -2145771032.4.INTA is invalid
> > pci_link29: BIOS IRQ 11 for -2145771032.7.INTA is invalid
> > pci_link30: BIOS IRQ 10 for -2145771032.8.INTA is invalid
>
> Yes, I agree that this alone doesn't fix it.  This looks to me like the
> pci_link code is pointing the interrupt source at the wrong part of the
> resource descriptor.  Perhaps it is not incrementing the pointer
> correctly for 64-bit arches.

From the actual code:

	/* Validate the BIOS IRQ. */
	if (!link_valid_irq(link, bios_irq)) {
		device_printf(dev, "BIOS IRQ %u for %d.%d.INT%c is invalid\n",
		    bios_irq, pcib_get_bus(pcib), slot, pin + 'A');

Thus, the weird value is being retuned by pcib_get_bus(), it's not coming out 
of ACPI at all.  ACPI dosen't provide bus numbers, just the slot and pin, we 
have to extract the bus number from the ACPI device that has a _PRT object.  
what's really odd is that he is even getting valid-looking IRQs, since we use 
pcib_get_bus() as the bus number for configuration transactions.  It's 
probably getting truncated down to the low byte at some point and thus 
reading the wrong bus, hence getting invalid IRQs I guess.  The real question 
here is why pcib_get_bus() is broken on this bridge.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org