Bug#594967: Bug #594967: [poulsbo] grub-pc Hangs After "Welcome to GRUB!"

[Seth Goldberg]

On Jan 3, 2011, at 4:06 PM, Colin Watson <cjwatson at 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  <cjwatson at 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                                       [cjwatson at debian.org]
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel at gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel