Bug 23132

Created attachment 37402 [details]
2.6.37-rc2 log

Attached the 2.6.37-rc2 log file  with dc9887dc reverted and pnp.debug enabled.

Created attachment 39742 [details]
debug patch to skip PCI assignments

Here's something to experiment with.

Reverting dc9887dc should only affect these PCI bridge window assignments:

  pci 0000:00:1c.0: BAR 8: assigned [mem 0xffc00000-0xffdfffff]
  pci 0000:00:1c.0: BAR 9: assigned [mem 0xfef00000-0xff0fffff 64bit pref]
  pci 0000:00:1c.1: BAR 9: assigned [mem 0xff100000-0xff2fffff 64bit pref]
  pci 0000:00:1c.2: BAR 9: assigned [mem 0xff300000-0xff4fffff 64bit pref]
  pci 0000:00:1c.0: BAR 7: assigned [io  0x7000-0x7fff]
  pci 0000:00:1c.1: BAR 7: assigned [io  0x8000-0x8fff]

These are done in that order from these host bridge windows:

  pci_root PNP0A03:00: host bridge window [mem 0xffc00000-0xffdfffff]
  pci_root PNP0A03:00: host bridge window [mem 0xfee10000-0xff9fffff]
  pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]

You can see that we're starting with the highest host bridge windows,
and filling each window from bottom to top (there's some unused space
below the 00:1c.0 BAR 9 to align it).

Commit dc9887dc will change that so we fill each window from top to
bottom.  This should not affect 00:1c.0 BAR 8 because it completely
fills the host bridge window, but will affect the others.

I don't think we actually *need* any of these windows we're assigning;
both devices behind the bridges (0c:00.0 behind 00:1c.1 and 09:00.0
behind 00:1c.2) already have all the resources they need.

My theory is that there's an unreported device somewhere in the
[mem 0xff500000-0xff9fffff] range, and when we assign a bridge
window there, it causes a conflict.  Windows *should* see a similar
problem, but maybe it takes a lazy approach and assigns bridge
windows only when necessary, which would hide the problem.

If you apply this debug patch and boot with this parameter:

  pci=skip=00:1c.0:9;00:1c.1:9;00:1c.2:9

we won't assign those windows either, and it might boot.  If
that doesn't work, try skipping the I/O port windows as well.

Here's a better approach that's already in the kernel and doesn't
require a patch.  If you boot with "reserve=0xff9fffff,0x500000",
we'll still assign all the windows, but we should avoid the
[mem 0xff500000-0xff9fffff] range.

If that boots, it's a good clue that there's an unreported device
there.  I'm not sure where to go from there.  We could do a series
of experiments like I did here:

  https://bugzilla.kernel.org/show_bug.cgi?id=23332#c20

to determine exactly where the problem is, then add a quirk for
the Inspiron 1545.

The problem with that approach is that if Linux assigns bridge windows
more aggressively than Windows does, we'll likely trip over the
same problem on other machines, and I really don't want to have
to deal with them one-by-one.

This situation (a bridge with nothing behind it, where BIOS leaves
the windows disabled, and Linux assigns them) seems fairly common,
so I should be able to find a machine with Windows so I can find out
what it does.

Created attachment 40482 [details]
avoid e820 regions

We plan to apply this patch to 2.6.37-rc6.  I believe it will fix
this issue, because one of the things the patch does is revert
commit dc9887dc, but confirmation would be great.

Fixed by http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=46bdfe6a50b88942f5323f837a3afd93a1c86e60 .