From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LZChd-0008Pf-32 for mharc-grub-devel@gnu.org; Mon, 16 Feb 2009 18:16:41 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LZCha-0008P6-Td for grub-devel@gnu.org; Mon, 16 Feb 2009 18:16:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LZChZ-0008Ou-Gw for grub-devel@gnu.org; Mon, 16 Feb 2009 18:16:37 -0500 Received: from [199.232.76.173] (port=33346 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZChZ-0008Or-BZ for grub-devel@gnu.org; Mon, 16 Feb 2009 18:16:37 -0500 Received: from fg-out-1718.google.com ([72.14.220.158]:3937) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LZChY-0007c3-VP for grub-devel@gnu.org; Mon, 16 Feb 2009 18:16:37 -0500 Received: by fg-out-1718.google.com with SMTP id l27so342853fgb.30 for ; Mon, 16 Feb 2009 15:16:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=XoniwdU+f1I/HRTrdNXR1rfmHcgYstS+qzwO4+9/ltU=; b=j0qQ4gCmQ3pj+/quuFA7Nk+UDlGxM86yt8CBQJUxFwIGs4/MsaQpyLIWMKSRwA/C9Y Z0wVoRpege+anZjBXVe8f6txe4XCIqNaxRuP88gbPX+4mdvorR9SuG4GTlpPlkmb8wZ7 uGqVqrMgw70hkmpeaTU5LcV+AFnCOmHiMnrf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=gPRb/8A0CY5cDHh3EjbGk49MIwBC2mAB3eAZYX0Su9SY/kqMS9Gwhqtk8NBC2ABi1W MbHQzP2pzVK4MYfS1RePltsEAuE3T7iTodUJIjI6MXGVbbDV6a5cOed8+TR9iJBN9XF0 4lL5JaP/hSmCPfIM4cmFjFfw8CRt2tvIAkchs= Received: by 10.86.29.8 with SMTP id c8mr1758847fgc.67.1234826195583; Mon, 16 Feb 2009 15:16:35 -0800 (PST) Received: from ?192.168.1.2? (18-253.0-85.cust.bluewin.ch [85.0.253.18]) by mx.google.com with ESMTPS id 4sm8255154fge.54.2009.02.16.15.16.34 (version=SSLv3 cipher=RC4-MD5); Mon, 16 Feb 2009 15:16:34 -0800 (PST) Message-ID: <4999F3D2.2080306@gmail.com> Date: Tue, 17 Feb 2009 00:16:34 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: The development of GRUB 2 References: <4999EE71.100@gmail.com> In-Reply-To: <4999EE71.100@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: grub_machine_fini on efi systems X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 23:16:39 -0000 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