In the first one, Linus talks about a USB controller whose SMM code
chokes on the BAR being disabled. That explanation seems odd to me. If
it chokes on the BAR disabled, how doesn't it choke on the BAR being
moved to a different location, which is unavoidable during probing?
Also, I think we do USB handoff from the BIOS much earlier than we used
to, which likely prevents these issues.
In the second one, he mentions that "So the secondary rule to "don't
turnoff MEM or IO accesses" is "never allocate real PCI BAR resources at
the top of memory". Well, unfortunately, the second one isn't possible
to meet given that we have boards with the MMCONFIG up there, so
disabling the decode is the only thing we can do. That whole discussion
was also based on the fact that it wasn't necessary to solve problems.
This is no longer a theoretical problem. We now have real problems that
we need this in order to solve.
It's not impossible at all. In fact I'm quite sure (Jesse can confirm)
that in the case of the board he was using, it was an add-in graphics
card where he saw this problem.
The fact is that in the case of MMCONFIG overlap with PCI BARs, which
one takes priority is completely undefined. In the case of this Intel
chipset, clearly the PCI Express device connected to the northbridge had
higher decode priority than the MMCONFIG aperture.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
-
