ACPI broke going from 8 to 9

[John Baldwin]

On 12/31/11 9:14 PM, Garrett Cooper wrote:
> On Sat, Dec 31, 2011 at 3:31 PM, Jeremy Chadwick
> <freebsd at jdc.parodius.com>  wrote:
>> On Sat, Dec 31, 2011 at 04:17:16PM -0700, Dan Allen wrote:
>>> On 31 Dec 2011, at 12:34 PM, Garrett Cooper wrote:
>>>
>>>> Not yet. Add 'nooptions NEW_PCIB' to your KERNCONF, recompile, and
>>>> try booting the new kernel. See if this works.
>>>
>>> It worked!  No hang, power button works.  Nice.  I hope this experimental option stays in.
>>>
>>> Thank you everyone for your help.  Happy New Years!
>>
>> This option isn't documented **anywhere** in the entire src tree.  It's
>> purely #ifdef all over.
>>
>> The code in question was committed 7 months ago.  It was MFC'd to
>> RELENG_8 6 months ago.  Here's the HEAD commit message:
>>
>> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pci/pci.c#rev1.420
>>
>> The RELENG_8 MFC is revision 1.386.2.15.
>>
>> The committer is jhb@, with mav@ being the individual who tested it, so
>> I imagine either of these folks will have some excellent insights as to
>> what's causing Dan's problem.  I'm CC'ing them both directly on this
>> thread.
>>
>> In the meantime: Dan, when you say in your original mail, "I just
>> upgraded my Dell OptiPlex GX270 from RELENG_8 to RELENG_9", can you
>> please provide uname -a output from the system when it was running
>> RELENG_8?  I'm looking specifically for the exact time when the kernel
>> was built, because there may have been fixes (that broke things for you)
>> between the above commit and present-day RELENG_8 (I have not examined
>> all commits).
>
>      It's going to be the feature that's going to cause headaches
> post-9.0-RELEASE based on my observations of several mailing list
> posts and the fact that 9.0 isn't actually RELEASEd yet (people have
> run into issues with acpi, atkbdc, mfi, and usb so far, but that's
> probably not everything).
>      If it could be made into a runtime tunable, that would be awesome,
> but that would require changes to driver structures and methods. With
> a little pointer aliasing and tunable guard sprinkling it wouldn't be
> hard to solve -- but it's still work.

Eh, almost all the problems are not with the PCI-PCI bridge bits, but
with the later changes to the ACPI Host-PCI bridge driver, and that is
changeable via a tunable.  (debug.acpi.disabled="hostres")  All of the
problems in this case are due to the BIOS providing incomplete or
flat-out erroneous information in the ACPI tables about which resource
ranges each Host-PCI bridge decodes.

Also, there is supposed to be language in the 9.0 errata mentioning
this tunable.  I had suggested to re@ that we disable it for 9.0 by
default, but instead they decided to document it instead since I made
the suggestion fairly late in the process (even though at this point
that was more like a month ago).

Finally, I made a commit this week to HEAD that probably "fixes" most
of the issues with BIOSes lying about their Host-PCI bridges (the
problem is the BIOS says two different things in two different places
when it programs a BAR or other resource that it then claims the parent
bridge doesn't handle).

The commit specifically fixed a Dell Optiplex GX620, so I imagine it
will fix a GX270 just as well (revision 228961).

The ACPI bits are not a simple matter of "only use it for ACPI 2.0" to
reference an earlier e-mail in this thread.  The boxes in question
almost certainly have ACPI 3.0 or later BIOSes at this point (remember
ACPI 1.0 came out in the 1999/2000 timeframe).

The PCI-PCI bridge changes are also not specific to only newer versions
of PCI, they go back to the rev 1.1 of the PCI-PCI bridge specification
and are fixing deficiencies in our handling of the I/O resource
windows in bridges.  Together the changes in NEW_PCIB are the last
remaining bits to make it possible to use "PNP OS" set to yes for PCI
devices.  Granted, at this point most BIOSes no longer have that option
and just always set it to no, but it is important infrastructure to have
in place for hotplug PCI (and cardbus (9 should no longer need the
hw.cbb.start_memory tunable hacks on various laptops due to NEW_PCIB),
etc.).

-- 
John Baldwin