On Jan 3, 2011, at 4:06 PM, Colin Watson <cjwat...@debian.org> wrote:
> On Mon, Jan 03, 2011 at 12:13:01AM +0000, Colin Watson wrote: >> On Sun, Jan 02, 2011 at 10:41:50PM +0000, Steve McIntyre wrote: >>> 2.iso: >>> >>> goes all the way through to bus ff and returns to a grub prompt >> >> This is interesting and suggests a measure of coincidence. What that >> patch did was skip remaining functions on a device that doesn't >> implement function 0, taking that as an indication that it doesn't >> exist. This was based on: >> >> http://en.wikipedia.org/wiki/PCI_configuration_space#Bus_enumeration >> >> Vladimir, are you OK with this change to trunk? >> >> 2011-01-02 Colin Watson <cjwat...@ubuntu.com> >> >> * grub-core/bus/pci.c (grub_pci_iterate): Skip remaining functions >> on devices that do not implement function 0. > > I've applied this patch to trunk following an ack from Vladimir on IRC. > I'll prepare an updated package for unstable shortly. > >> Nevertheless, I'm not confident that this will fix the problem on all >> machines, so I would like to sort out the bridge handling as well. > > This may be more complicated than I thought. Seth Goldberg pointed out > that my approach fails to deal with peer host bridges correctly (i.e. > cases where there are multiple trees, not just a single one rooted at > bus 0). Linux deals with this by asking the PCI BIOS for the last bus > number, but at this point things get complicated as you have to do > things in different ways for different firmware. > The proper way to do this on modern systems is to traverse the system's [DSDT/SSDT] ACPI tables looking for Device objects with the host bridge HID/CID and evaluate the BBN object (which can be a method), if it exists (which it must if there are multiple host bridges). Since grub2 does not have a full ACPI interpreter (pulling in Intel's acpica would work ;), though the license may force it to be a grub-extra), going that route with anything less would never cover all systems' BBNs, so PCI BIOS would be simplest. Things get a bit more complicated when a system has multiple PCI segments (i.e.: using the MCFG table, MMIO addresses that may be >4G, etc.), but that can be tackled later. --S > I am inclined to try the first piece alone and see how this works out, > and if we can fix the affected systems by just probing function 0 on > every device on every bus then let it stand at that, even if it feels > less elegant. Inventing new piles of infrastructure to handle a case > I'm unsure about in a subsystem I don't know well isn't my idea of a > good time. > > -- > Colin Watson [cjwat...@debian.org] > > _______________________________________________ > Grub-devel mailing list > grub-de...@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
