acpi resources problem potentially because of new pcib code

[John Baldwin]

On Monday, May 23, 2011 4:12:47 am Andriy Gapon wrote:
> 
> John,
> 
> it seems that possibly your recent changes for PCI bridges could have broken
> something for my old 440BX/PIIX4/PIII type test machine.
> Looks like now some I/O resources get assigned to a PCI bridge instead of 
ACPI.

Actually, this is due to some older changes in 9 to make ACPI reserve all 
assigned resources via resource_list_reserve().

> Some highlights follow:
> ...
> acpi_timer0: couldn't allocate resource (port 0x4008)
> ...
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff,0x4000-0x4041,0x5000-0x500f 
on acpi0
> ...
> device_attach: acpi_throttle0 attach returned 6
> 
> More data here:
> http://people.freebsd.org/~avg/ms6163/
> 
> I see that _CRS of the Host-PCI bridge indeed claims that 0x4000 range, so I
> realize that this is a BIOS bug, but I think that perhaps we could have some
> quirk there to leave this range to ACPI.

Well, it would be hard to know how to quirk this generically.  acpi timer 
devices do not use a fixed address range.

One thing I have run into is that we make our lives more difficulty by 
violating the ACPI namespace in our new-bus tree.  Specifically, I think we 
should have an ACPI-aware ISA driver and that any ACPI-enumerated devices that 
are below the PCI-ISA bridge should be devices on that ISA bus, not on acpi0 
directly.  The resource producer ranges set up in Host-PCI bridge devices all 
assume that ACPI-enumerated ISA devices are behind the Host-PCI bridge rather 
than at the same level.  People did not like this the last time I suggested 
it, but we may need to do it regardless.  I might look at doing that in 10.

For your BIOS I'd be tempted to just blacklist it.

I suppose we could add a quirk to ignore all 'consumed' devices on Host-PCI 
bridges that are not for the '0xcf8-0xcff' range as an alternative perhaps.

-- 
John Baldwin