grub_machine_fini on efi systems
Hello. I found a serious problem which may be the cause of linux not booting on some efi systems. grub_machine_fini is called before grub_linux_boot. grub_machine_fini returns all memory allocated by grub2 to efi. This includes all memory used to load modules. So actually efi can rightfully destroy linux module before it has slightest chance to do its job. I asked step21 to declare linux boot as returnable to stop grub_machine_fini. However it's nothing more then a workaround. I hope that someone will find a way to fix this nicely because for the moment I see none. (perhaps tomorrow I'll find sth) Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub_machine_fini on efi systems
Remark 1: when loading OS grub has to call grub_efi_exit_boot_services which unloads efi nearly completely. On the other hand it shouldn't be called when returning with exit command. Perhaps we should split grub_machine_fini in two: one for preparing for OS and other for exiting. But then when one chainloads then grub_efi_exit_boot_services shouldn't be called. So I propose that loader function should cope with environment preparation. For cases when some preparation is needed independently of the type of loaded os (like setting 'map' hook) the best solution IMO would be preboot hooks. Remark 2: it should be clearly stated somewhere what the boot function may and may not use (e.g. boot function isn't allowed to read from disk, boot function may use grub_printf but not and so on) so that boot function conflicts neither with grub_machine_fini nor with preboot hooks Remark 3: in case of an error the non-returning boot function may return. I see 3 possible solution: a) forbid such an action. Use grub_fatal if really necessary b) loader should call a special function at point of noreturn c) delete the separation between returnable and not returnable booters. grub_machine_prepare_for_os and preboot_hooks in my proposition patch would then be extended with second function which is called upon the return to undo the action of the hook itself Regards Vladimir 'phcoder' Serbinenko phcoder wrote: Hello. I found a serious problem which may be the cause of linux not booting on some efi systems. grub_machine_fini is called before grub_linux_boot. grub_machine_fini returns all memory allocated by grub2 to efi. This includes all memory used to load modules. So actually efi can rightfully destroy linux module before it has slightest chance to do its job. I asked step21 to declare linux boot as returnable to stop grub_machine_fini. However it's nothing more then a workaround. I hope that someone will find a way to fix this nicely because for the moment I see none. (perhaps tomorrow I'll find sth) Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub_machine_fini on efi systems
There is also a problem with Apple 64 bit grub.efi booting ubuntu 2.6.27 linux in which the kernel is booted and starting but all video is lost after the boot command. I don't know if there may be a connection. A temporary fix is to change Video frame buufer settings in /loader/i386/efi/linux.c: grub_find_video_card and grub_linux_setup_video Then proceeds to the next bug (libata hangup during initrd ). On Tue, Feb 17, 2009 at 9:53 AM, phcoder phco...@gmail.com wrote: Hello. I found a serious problem which may be the cause of linux not booting on some efi systems. grub_machine_fini is called before grub_linux_boot. grub_machine_fini returns all memory allocated by grub2 to efi. This includes all memory used to load modules. So actually efi can rightfully destroy linux module before it has slightest chance to do its job. I asked step21 to declare linux boot as returnable to stop grub_machine_fini. However it's nothing more then a workaround. I hope that someone will find a way to fix this nicely because for the moment I see none. (perhaps tomorrow I'll find sth) Regards Vladimir 'phcoder' Serbinenko ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub_machine_fini on efi systems
On Tue, Feb 17, 2009 at 10:56 AM, Peter Cros pxwp...@gmail.com wrote: There is also a problem with Apple 64 bit grub.efi booting ubuntu 2.6.27 linux in which the kernel is booted and starting but all video is lost after the boot command. I don't know if there may be a connection. A temporary fix is to change Video frame buufer settings in /loader/i386/efi/linux.c: grub_find_video_card and grub_linux_setup_video Then proceeds to the next bug (libata hangup during initrd ). Hi, What's your frame buffer address, does grub_find_video_card detect it wrong ? -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: grub_machine_fini on efi systems
1. Initially - With 2GB RAM Imac8,1 has 256MB VRAM Radeon HD2600 1920x1200 MBP4,1 has 512MB VRAM Nvidia 8600 1920x1200 Imac8,1 grub boot linux shows Video frame buffer at 9052 and blank screen. MBP4,1 gives 9000 and scrambled video. 2. By overriding video_base to set it at 2GB grub_linux_setup_video () video_base = 0; grub_pci_iterate (grub_find_video_card); /* override */ video_base = 0x8000; Result - MBP gets readable text screens from kernel boot and init. Imac gets scrambled video (better than nothing) 3. further fiddling with grub_linux_setup_video() params-lfb_line_len = 8192; changed fromm 8192 to = width*4 gets clear script for Imac, but MBP wants 8192. 4. The results with 4GB RAM will differ I expect, and later effects unknown as the linux initialization is not completing (other issues with libata). On Tue, Feb 17, 2009 at 2:02 PM, Bean bean12...@gmail.com wrote: On Tue, Feb 17, 2009 at 10:56 AM, Peter Cros pxwp...@gmail.com wrote: There is also a problem with Apple 64 bit grub.efi booting ubuntu 2.6.27 linux in which the kernel is booted and starting but all video is lost after the boot command. I don't know if there may be a connection. A temporary fix is to change Video frame buufer settings in /loader/i386/efi/linux.c: grub_find_video_card and grub_linux_setup_video Then proceeds to the next bug (libata hangup during initrd ). Hi, What's your frame buffer address, does grub_find_video_card detect it wrong ? -- Bean ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Cros ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
