https://bugzilla.kernel.org/show_bug.cgi?id=22132
Bjorn Helgaas <bjorn.helg...@hp.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Regression|No |Yes
--- Comment #3 from Bjorn Helgaas <bjorn.helg...@hp.com> 2010-11-11 23:33:53
---
Sergey, thank you very much for the report and detailed logs. Some
significant changes in this area appeared in 2.6.37-rc1, and I'm pretty
sure that will work on your system (please test it if you can).
However, I think there's still a problem we need to fix.
Here's what I think is happening. The BIOS didn't assign space for
the 00:1d.7 USB BAR, so Linux did it. Without _CRS, we guess that the
[mem 0x80000000-0xdfffffff] region is available for PCI devices, based
on these E820 entries:
BIOS-e820: 000000007f6f0000 - 0000000080000000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
Allocating PCI resources starting at 80000000 (gap: 80000000:60000000)
If we look at /proc/iomem, looking for space from low addresses to high,
[mem 0x942c4000-0x942c43ff] is the first available place to put the 00:1d.7
USB device, which works fine:
7f6f0000-7fffffff : reserved
80000000-8fffffff : 0000:00:02.0
90000000-90ffffff : PCI Bus 0000:01
91000000-91ffffff : PCI Bus 0000:02
92000000-930fffff : PCI Bus 0000:02
93100000-941fffff : PCI Bus 0000:01
94200000-9427ffff : 0000:00:02.0
94280000-942bffff : 0000:00:02.0
942c0000-942c3fff : 0000:00:1b.0
942c4000-942c43ff : 0000:00:1d.7 (** assigned by Linux **)
e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff]
When Linux pays attention to the host bridge _CRS, as it does by default
starting in 2.6.34, we no longer just guess at what's available. Instead,
we use the _CRS information:
pci_root PNP0A08:00: host bridge window [mem 0x7f800000-0x7fffffff]
pci_root PNP0A08:00: host bridge window [mem 0x80000000-0xfebfffff]
Note that the entire first window ([mem 0x7f800000-0x7fffffff]) is
"reserved" according to the E820 table. I think it's a video framebuffer:
uvesafb: framebuffer at 0x7f800000, mapped to 0xf8100000, using 7872k ...
I suppose this region is connected with the 00:02.0 video device (though it
doesn't appear in any BARs), so it makes some sense that the _CRS tells us
it's routed to PCI bus 00.
Now, here's the rub: we do try to pay attention to the fact that E820
tells us the area is reserved, but we don't do it correctly. Here's what
it looks like in /proc/iomem:
7f6f0000-7fffffff : reserved
7f800000-7fffffff : PCI Bus 0000:00
80000000-febfffff : PCI Bus 0000:00
When we allocate space for the 00:1d.7 USB device, we look for available
space *below* the PCI Bus 0000:00 resources. We never look *up* at the
parents of those resources, so the 7f6f0000-7fffffff reserved area doesn't
affect the allocation at all. The result is that we assign some of that
framebuffer space to the USB device, which doesn't work because accesses
go to the framebuffer instead of to the USB device:
pci 0000:00:1d.7: BAR 0: assigned [mem 0x7f800000-0x7f8003ff]
I think 2.6.37-rc1 will work on your machine because we'll allocate from
the top down instead of from the bottom up, so we'll probably get a
region like [mem 0xfebffc00-0xfebfffff].
But of course, we still haven't fixed the underlying problem of ignoring
the E820 reservations.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
