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

[Bjorn Helgaas <bhelgaas@google.com>]

[added linux-pci]

On Tue, May 17, 2011 at 1:01 AM, Hornung, Michael <mhornung@init-ka.de> wrote:
> the system from which I'm talking about is a Menlow XL (Intel Atom Z510PT and SCH US15WPT) platform with 512 megabyte RAM.
> There is one PCIe-switch (PI7C9X20404SL) attached to each of both PCIe-ports of the US15WPT (see attached 2.6.30-lspci.txt for details).

I think you forgot to attach the lspci.

> With both switches enabled, all Kernel versions (vanilla) above 2.6.30 refuse to boot. With only one switch active
> (the other one with no supply voltage ), all Kernel versions boot properly. It does not matter which switch is removed, it
> is sufficient just to remove one of the two.
>
> There is an UART (FPGA IP Core) in that system located at address 1900h using interrupt 3. In order to get Kernel messages at boot time,
> I changed file arch/x86/include/asm/serial.h as follows:
>
> -        { 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS },      /* ttyS0 */     \
> +        { 0, BASE_BAUD, 0x1900, 3, STD_COM_FLAGS },     /* ttyS0 */    \
>
> that is the only change I made to the kernel sources.

Is this UART connected via PCI?  I don't think so, because I don't see
any I/O BARs that include 0x1900.  However, I don't see any ACPI
devices that mention that address either (none of the "pnp 00:xx"
devices include that range).

Since there's no PCI-enumerable device that uses 0x1900, and ACPI
doesn't mention it, we think it's available, and I notice the 2.6.38.6
kernel does assign the [io  0x1000-0x1fff] range to the 00:1c.1 bridge
I/O window.  Now we probably have two devices claiming accesses to
0x1900 (the bridge and the UART).  I don't know whether this is
causing the problem, but it can't be good.

I think the best way to fix this would be to change your BIOS to
include a PNP0501 ACPI device with the appropriate _CRS to tell us
what resources it uses (then you could drop your serial.h change,
too).

If changing the BIOS is impossible, you could at least find out if
this is the problem by adding a quirk in drivers/pnp/quirks.c to
reserve the 0x1900 region by adding an I/O resource to the PNP0c02
device.

Bjorn