Re: Kernel > 2.6.30: PCI issue causes Kernel freeze at booting

[Bjorn Helgaas <bhelgaas@google.com>]

On Fri, May 27, 2011 at 12:48 AM, Hornung, Michael <mhornung@init-ka.de> wrote:
> Hi Bjorn,
>
>>>> Hi Michael,
>>>>
>>>> Any update on this problem?  Did it make any difference to put the
>>>> UART in the ACPI namespace?
>>>
>>> thank you very much for your support. Unfortunately I'm not able to get it to work. I changed
>>> the BIOS and added PNP0500 device nodes for all 21 UARTS (all located in the FPGA, all connected
>>> via LPC, all located at addresses between 0x1900 and 0x19a7h and all using IRQ3), but the kernel does not care about
>>> that nodes. CONFIG_SERIAL_8250_PNP is set to "y" (see attached config.txt) but the kernel output does not show
>>> up any differences (2.6.38.6.log).
>>
>> Hmm, let's see...  It's been a while since I really worked in this area.
>>
>> I think there are two problems here:
>>
>> 1) Something must be wrong with your PNP0500 devices because we only
>> found seven PNP/ACPI devices, the same as we found in the original
>> boot.Your most recent boot didn't have "debug" on the command line;
>> that should show us the PNP devices we did find.  Can you post the
>> DSDT?  Maybe it will have a clue about why we didn't find 28 (the
>> original 7 + the new 21 UARTs) devices.
>
> The BIOS sources were a little bit confusing at that point, but finally
> I am able to add PNP device nodes.
>
>> 2) Even if the PNP0500 devices were all there, Linux has a
>> long-standing problem that we don't actually *do* anything with PNP
>> resources until a driver claims the device.  This PCI assignment is
>> happening before the serial driver would claim the devices, so I'm
>> afraid it won't help with the problem you're seeing.  Ugh.  I've been
>> wanting to fix this for years, but haven't had a chance to dig into
>> it.
>
>> It does seem unnecessary to assign I/O resources to the 00:1c.1 bridge
>> at all, since there's no device below the bridge that needs I/O
>> resources.  But changing that is a bigger project, too.
>
>> There *is* an exception to the "Linux ignores PNP resources" rule,
>> though -- maybe we could take advantage of that.  We do reserve
>> "motherboard" resources (PNP0C01 and PNP0C02 devices), and there's
>> even a comment in drivers/pnp/system.c about doing it early, before
>> PCI assigns resources.  So if you change your new PNP0500 devices to
>> PNP0C02 (and fix whatever is preventing PNPACPI from finding them),
>> that might fix the PCI bridge assignment.  Then you'd have to keep the
>> serial.h hack, since the serial driver wouldn't be able to claim the
>> UARTs.
>
> Thank you so much, that actually did the trick. I got it done to add a
> PNP0C02 device with a memory region from 0x1900 to 0x1947 and that is
> sufficient to get the kernel booting.
>
>> Ugh.  I'm really sorry you're tripping over this ugliness in Linux.
>
> Don't mind, 21 UARTs, all starting at address 0x1900 is a little bit "special".
>
>> The way this is *supposed* to work is that first, ACPI tells us where
>> all the fixed hardware is.  The UARTs and PCI host bridges are
>> examples of this fixed hardware.  Then we're supposed to enumerate
>> things below the host bridges and assign unused space when necessary.
>> But Linux has always discovered PCI stuff first, mostly ignoring ACPI,
>> so keep tripping over problems like this.

I opened this bug report to make sure we don't lose this.  I don't
know when or if this will be addressed, but your system is valuable as
a real live test case that shows what we're doing wrong.

https://bugzilla.kernel.org/show_bug.cgi?id=36462

Bjorn