On Thu, 2010-06-17 at 07:31 -0600, Myles Watson wrote:
Yes, here it is attached. It is copied and modified from AMD Tilapia mainboard, because that seemed to be a close relative.
Thanks.
Meanwhile, I added call to it8712f_kill_watchdog() , like Rudolf Marek suggested. That changed the behavior so that the machine no longer reboots in the middle of iterating through PCI busses and devices, but instead it seems to go on iterating infinitely, or presumably until malloc runs out of memory.
OK
Perhaps I should start out with a very minimalist devicetree and then add parts as needed?
Yes. Instead of commenting out devices from the Tilapia board, I think you should turn them off. The exception to that is: #device pci 18.0 on end #device pci 18.0 on end
You can look at lspci -xxx from the factory BIOS and look at the register settings to determine which link is being used, or you can just try moving those lines around.
Now this command gives only hex dumps. I have some idea what the PCI part (first 64 bytes) means, but I have no clue how to interpret the dump to find out the Hypertransport topology. Is there some web reference for this? The lspci listing is attached.
Placing those duplicate "device pci 18.0 on end" entries either before or after the main entry seems to have no effect.
After some experiments with different devicetrees, I did not get very much further. PCI scan is still stuck in infinite loop.
If I switch device 0.0 off, the device enumeration dies, because RS780 device is not found, which is quite logical.
If I switch off the super IO device, I no longer get debug output after that device is switched off, again quite easy to understand.
Otherwise, switching devices on or off does not seem to change the end result: The PCI scan gets into an infinte loop (or recursion). Please see the attached boot log. It was generated using the attached devicetree.cb file.
I added some extra debug print statements to src/devices/pci_device.c, function pci_scan_bus:
/* For all children that implement scan_bus() (i.e. bridges) * scan the bus behind that child. */ printk(BIOS_DEBUG, "PCI: pci_scan_bus entering children of devfn %x.%x - devfn %x.%x\n", PCI_SLOT(min_devfn), PCI_FUNC(min_devfn), PCI_SLOT(max_devfn), PCI_FUNC(max_devfn) ); for (child = bus->children; child; child = child->sibling) { printk(BIOS_DEBUG, " %s\n", dev_path(child) ); } printk(BIOS_DEBUG, "PCI: pci_scan_bus child list end.\n");
for (child = bus->children; child; child = child->sibling) { max = scan_bus(child, max); }
The first for-loop and printk statemements around it were added to see if there is a recursion path through pci_scan_bus.
The resulting log shows that this piece of code is only executed once, so the answer was no.
If I have understood correctly, this part of the boot process scans through the PCI busses and devices by querying the hardware. Can it get into a loop like this, if the hardware gives funny answers?
By my logic, this could be caused by at least three things: - bad devicetree.cb - hardware gives funny answers to PCI scan - bug in the PCI scan logic
Presumably, the first step would be to distinguish among these.
Where would be an appropriate place to insert printk's to find out what is going on?
Best regards, Juhana Helovuo