site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi, 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++) { -Dave Footnotes: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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 @@ 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. 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. This email sent to site_archiver@lists.apple.com