[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug#594967: Bug #594967: [poulsbo] grub-pc Hangs After "Welcome to G
Re: Bug#594967: Bug #594967: [poulsbo] grub-pc Hangs After "Welcome to GRUB!"
Mon, 3 Jan 2011 16:26:25 -0800
On Jan 3, 2011, at 4:06 PM, Colin Watson <address@hidden> 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:
>>> 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:
>> Vladimir, are you OK with this change to trunk?
>> 2011-01-02 Colin Watson <address@hidden>
>> * 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.
> 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 address@hidden
> Grub-devel mailing list