2011/2/6 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com> > On 02/06/2011 05:57 AM, Nate Weibley wrote: > > On Fri, Feb 4, 2011 at 12:01 PM, <grub-devel-requ...@gnu.org > > <mailto:grub-devel-requ...@gnu.org>> wrote: > > > > Date: Fri, 04 Feb 2011 19:19:34 +0300 > > From: Vladimir '?-coder/phcoder' Serbinenko <phco...@gmail.com > > <mailto:phco...@gmail.com>> > > Subject: Re: AMI Aptio EFI booting problems on ASUS G73SW-A1 > > To: grub-devel@gnu.org <mailto:grub-devel@gnu.org> > > Message-ID: <4d4c2716.7080...@gmail.com > > <mailto:4d4c2716.7080...@gmail.com>> > > Content-Type: text/plain; charset="utf-8" > > > > On 02/04/2011 04:54 PM, Nate Weibley wrote: > > > Hey GRUB devs, > > > > > > I've been having some trouble getting GRUB2 to load Arch x86_64 > > on my > > > ASUS G73SW-A1. Specifically, if I do not specify noefi on the > kernel > > > command line in my grub.cfg everything stalls at initrd. > > I don't think that it gets so far as initrd and actually panics > early. > > > I'm building GRUB2 from the bzr repo, so to my knowledge it > > should be > > > up-to-date. > > > > > "noefi" isn't handled at all by GRUB itself. It's just a parameter > > that > > it transfers to linux. So if it makes a difference. It's either: > > a) (most likely) Linux doesn't handle your EFI either because of > > EFI or > > Linux bugs > > b) GRUB passes incorrect EFI pointers. Considering that this > operation > > is trivial, I think this is unlikely. > > GRUB can't do anything for (a). Well it could but not anything in > > a sane > > way. I suggest trying different Linuxes (kernels) E.g. Ubuntu, > Debian, > > Red Hat, git. > > > > > I substituted noefi for add_efi_memmap and added set debug=all > > before > > > initrd is used. > > > > > add_efi_memmap should do any difference at all. It just makes > > Linux redo > > some of GRUB's job. > > > The system stalled again, but I did get /some /debugging output. A > > > link to the output is below; apologies for having to take a picture > > > with my cell phone as the laptop does not have a usable serial port > > > for capture. > > > http://imgur.com/40lLO > > > I should point out that adding set debug=all appears to stall the > > > system at the same point even if noefi is still set for the > > kernel... > > > so perhaps this stall is not indicative of the initrd failure. I > > read > > > through the thread suggesting that there was a bug present with > > system > > > over 8GB, but it was my impression that the bug was patched. > > Are you sure? It may be indicative of a failure when printing debug > > output. Previously there was such bug when GRUB tried to use already > > finalised EFI services to print debug output but AFAICT it's > > already fixed. > > > If I can provide any additional info or take any additional > > debugging > > > steps, please let me know. > > > > > > -- > > > --Nate Weibley > > > > > > > > > _______________________________________________ > > > Grub-devel mailing list > > > Grub-devel@gnu.org <mailto:Grub-devel@gnu.org> > > > http://lists.gnu.org/mailman/listinfo/grub-devel > > > > > > > > > -- > > Regards > > Vladimir 'φ-coder/phcoder' Serbinenko > > > > Vladimir, > > Per your suggestion I tried other linux distros with various kernels. > > So far none of the EFI enabled distros are working. They do work if > > booted via BIOS though, of course. Windows 7 64bit /does / boot > > appropriately via EFI, so it's hard to say where the fault is. If > > Windows is booting though, it seems more likely something is going > > wrong in the Linux kernel EFI handling, or perhaps as you say GRUB is > > passing incorrect pointers. Either way, they all exhibit the exact > > same behavior... the kernel is loaded, and at the point init should be > > called, the system stalls with no debug or error message. > On EFI Linux has no early printk other than to a serial. So you receive > no messages unless you're connected to serial. It makes diagnosis much > more difficult. > -- > Regards > Vladimir 'φ-coder/phcoder' Serbinenko > > > I'll say! I was hoping there would be a way to pass messages back through grub like some sort of virtual serial port or to virtualize this but allow interaction with my actual system EFI. Barring that, I can't even fathom how I'd approach the next step of debugging. AFAIK this chipset doesn't even *support *legacy serial, so I couldn't even open my laptop and tap into some traces/pads to get RS-232 out. I guess the best I can do is wait and see if future kernels adhere more closely to the pure EFI spec and hope that's what is allowing windows to boot.
-- --Nate Weibley
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
