IOPCIConfigurator BAR sizing bug?
IOPCIConfigurator BAR sizing bug?
- Subject: IOPCIConfigurator BAR sizing bug?
- From: David Elliott <email@hidden>
- Date: Mon, 29 Jun 2009 03:48:02 -0400
Hi,
I've come across a very strange bug in IOPCIConfigurator. On a
particular motherboard (an Intel DG35EC) I am finding that the sizing
of particular BARs is causing the machine to crash.
After reading the relevant portion of the PCI spec (Revision 2.2,
section 6.2.5.1 at top of page 204) it seems that according to the
spec the "decode (I/O or memory) of a register is disabled via the
command register before sizing a Base Address register."
Looking at the IOPCIConfigurator code I could not see where or if it
was doing this so I patched it as follows:
diff -ur IOPCIFamily-106/IOPCIConfigurator.cpp IOPCIFamily-106-dfe/
IOPCIConfigurator.cpp
--- IOPCIFamily-106/IOPCIConfigurator.cpp 2008-07-16
14:41:58.000000000 -0400
+++ IOPCIFamily-106-dfe/IOPCIConfigurator.cpp 2009-06-29
02:59:01.000000000 -0400
@@ -87,6 +87,9 @@
fFlags = kIOPCIConfiguratorEnable;
+ // DFE: Set the debug flags permanently for now.
+ fFlags |= kIOPCIConfiguratorIOLog | kIOPCIConfiguratorKPrintf;
+
if (kPCIHotPlug == fPCIBridgeList[0]->supportsHotPlug)
{
fFlags |= 0
@@ -1982,9 +1985,16 @@
{
uint32_t idx;
+ // DFE: Disable and restore access while sizing the BARs
+ uint16_t cmdr;
+ cmdr = pciDisableAccess(device);
+ DLOG(" cmdr 0x%x\n", cmdr);
+
// Probe BAR 0 through 5 and ROM
pciSafeProbeBaseAddressRegister(device, kIOPCIRangeExpansionROM);
+ pciRestoreAccess(device, cmdr);
+
DLOG(" state %d\n", device->deviceState);
for (idx = kIOPCIRangeBAR0; idx <= kIOPCIRangeExpansionROM; idx++)
{
With that patch the machine boots just fine. Without that patch the
machine bombs in IOPCIConfigurator::pciProbeBaseAddressRegister when
sizing barNum=2 of [0:2:0] (which seems to be the onboard VGA
device[1]). If I attempted to skip sizing that bar using GDB to skip
around the code it would proceed to crash again on another BAR of
[0:2:1].
The symptom of the crash varies. Sometimes the machine just
completely hangs. Other times it gets a page fault trying to execute
code at 0x8. In the latter case most of the time the backtrace ends
at that point. Some of the time the backtrace will continue down from
that point but it's missing a few entries that should be there (unless
of course the functions are inlined or don't have a stack frame for
one reason or another in which case that would explain that).
What I'm not understanding here is that after having a look at the
Linux PCI source (2.6.30 git on the kernel.org website) I noticed that
it also does not disable memory access while sizing the BARs. Yet
this machine has always booted Linux just fine, but not Darwin.
Am I on the right track here or am I missing something? The patch
fixes the problem, but is it the right fix?
Oh, and if you're wondering how I'm running GDB against this: I'm
doing it over the serial port using the SerialKDPProxy. Clearly
FireWire and Ethernet debugging aren't available this early in the game.
-Dave
Footnotes:
1. I have not yet attempted to install a PCI-Express graphics card
into the system. Since this is the very first device that is probed I
haven't gotten a chance to see if the problem happens on later devices
or if it's just limited to this onboard VGA device.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden