Re: 2.6.26-rc9-git9 doesn't boot on Macintel

[Justin Mattock]

On Wed, Jul 16, 2008 at 3:58 AM, Jack Howarth <howarth@xxxxxxxxxxxxxxxxx> wrote:
> Justin,
>     At the moment I am not really certain what the problem is.
> I have heard that Macintel machines (because of EFI) can't boot
> without resorting to MMCONFIG. If that is true, the problem I
> am seeing would appear to start with the fact that the boot
> proceeds with "Not using MMCONFIG". I plan on trying to add
> some printk statements in arch/x86/pci/mmconfig-shared.c to
> puzzle out why this is failing. The code in question is...
>
>
>                if (!early)
>                        printk(KERN_ERR "PCI: BIOS Bug: MCFG area at %Lx is not"
>                               " reserved in ACPI motherboard resources\n",
>                               cfg->address);
>                /* Don't try to do this check unless configuration
>                   type 1 is available. how about type 2 ?*/
>                if (raw_pci_ops && e820_all_mapped(cfg->address,
>                                                  cfg->address + size - 1,
>                                                  E820_RESERVED)) {
>                        printk(KERN_NOTICE
>                               "PCI: MCFG area at %Lx reserved in E820\n",
>                               cfg->address);
>                        valid = 1;
>                }
>
>                if (!valid)
>                        goto reject;
>        }
>
>        return;
>
> reject:
>        printk(KERN_ERR "PCI: Not using MMCONFIG.\n");
>        pci_mmcfg_arch_free();
>        kfree(pci_mmcfg_config);
>        pci_mmcfg_config = NULL;
>        pci_mmcfg_config_num = 0;
> }
>
> I've verified that test for raw_pci_ops is passing but it appears
> that the e820_all_mapped() test is failing (at least on
> my machine).
>                        Jack
>
> On Wed, Jul 16, 2008 at 03:05:23AM +0000, Justin Mattock wrote:
>> On Wed, Jul 16, 2008 at 1:24 AM, Jack Howarth <howarth@xxxxxxxxxxxxxxxxx> wrote:
>> > Justin,
>> >    You also download the x86_64 iso instead from...
>> >
>> > http://mirrors.kernel.org/fedora/development/x86_64/os/images/
>> >
>> > Both should give you the same kernel boot freeze that I am
>> > seeing (assuming that the kernel boots up with the message
>> > "Not using MMCONFIG". At this point I am just trying to find
>> > out if anyone else can reproduce this issue on a MacBook Pro
>> > (second generation). Otherwise I am going to be out of luck
>> > when distros switch to 2.6.26.
>> >                          Jack
>> > ps I am currently guessing that thet actual freeze is
>> > occuring in the code that is executed right after...
>> >
>> > pci 0000:00:1f.0: quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO
>> > pci 0000:00:1f.0: quirk: region 0500-053f claimed by ICH6 GPIO
>> >
>> > but before...
>> >
>> > PCI: Transparent bridge - 0000:00:1e.0
>> >
>> > ...which never appears here under 2.6.26.
>> >
>> >
>> >
>> >
>> > On Wed, Jul 16, 2008 at 12:26:05AM +0000, Justin Mattock wrote:
>> >> >
>> >>
>> >> Ah I see, so this is from a fresh .iso image
>> >> I can give you're suggestion a try(need to locate a blank cd)
>> >> keep in mind the .iso might not have x86 support i.g.
>> >> I use nubuntu(why: it's small) one of the problems I was facing was
>> >> the alpha release, which did not support x86(when using that .iso image
>> >> it would start booting and then spit out a bunch of messages vertically,
>> >> but a few month's later they released there .iso with support thus
>> >> giving me the opportunity to use it.
>> >> This might be what you are dealing with.
>> >> regards;
>> >>
>> >> --
>> >> Justin P. Mattock
>> >
>>
>> I have not yet tried the .iso's yet.
>> (busy with other things at the moment),
>> from what you're telling me it seems they must have left out
>> something in the .config. "Shit" this means you can't even load the .iso itself
>> for the initial install. Maybe you should let them know about this(I
>> don't use fedora that much)
>> If need be, try a stable version of the O.S(fedora). so you can load
>> 2.6.26, and then if time permits
>> you, update to that of the development version.(that is until you get
>> an answer from the
>> maintainers of this .iso with the issue).
>> regards;
>>
>> --
>> Justin P. Mattock
>

Hello;
One of my weaknesses right now is pulling code out of my ass
(maybe in a few years from now), but from what you are showing me
This is what is causing the NULL(if that's right to say)

 if (!valid)
                       goto reject;

So the question is, is how to have a valid
"something" to prevent going to NULL
maybe a boot param i.g. acpi_osi=Darwin,
or another option to make a "good" !valid
So you don't:   goto reject;

Or take the whole reject mechanism out
just so you can boot up, and then asses the situation from there.
regards;


-- 
Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/