From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54327) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c2kLl-0005TK-0w for qemu-devel@nongnu.org; Fri, 04 Nov 2016 15:40:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c2kLg-0005cO-WA for qemu-devel@nongnu.org; Fri, 04 Nov 2016 15:40:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52790) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c2kLg-0005as-OE for qemu-devel@nongnu.org; Fri, 04 Nov 2016 15:40:24 -0400 References: <0f042e9b-f6a3-27c1-4ca0-94e13f8102d8@gmx.net> <20161104110813.GF9817@stefanha-x1.localdomain> From: Laszlo Ersek Message-ID: Date: Fri, 4 Nov 2016 20:40:20 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] alpha platform is missing files after initrd load List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , Stefan Hajnoczi , Dennis Luehring Cc: qemu-devel , "Richard W.M. Jones" On 11/04/16 17:37, Richard Henderson wrote: > On 11/04/2016 05:08 AM, Stefan Hajnoczi wrote: >> On Thu, Oct 20, 2016 at 12:45:37PM +0200, Dennis Luehring wrote: >>> qemu: 2.7.x (git head) >>> platform: Alpha (Clipper) >> >> Two options: >> >> 1. Not many people use Alpha. You may need to debug this yourself by >> learning about the Linux alpha boot protocol (where the initramfs is >> loaded and how big that region of memory may be). Then you can >> verify the memory contents after QEMU has loaded the >> kernel/initramfs using monitor commands to read memory. You may need >> to look at QEMU's kernel/initramfs loading code to see what it's >> doing. >> >> 2. If it worked in a previous QEMU version, please use git-bisect(1) to >> find out which commit broke it. >> >> Good luck! > > We debugged this via private mail. > > For the 4.7 kernel, we had enough ram to unpack the (large) initrd; with > the 4.8 kernel, we ran out. The 4.8 kernel did in fact print an > (obscure) error message to that effect, which had not been noticed. Was it Unpacking initramfs... Initramfs unpacking failed: junk in compressed archive ? If so, then the same has been encountered with the aarch64 target: https://github.com/libguestfs/libguestfs/commit/c24f242521e8 > I > consider it a bug that the kernel does not treat this like any other > failure to mount /root, via panic. I agree. And, apparently, it used to be handled with a panic() call, but then that was deemed "policy", and downgraded to a KERN_EMERG message: commit 73310a169aebe257efdd35a763cce1c7658f40c9 Author: H. Peter Anvin Date: Wed Jan 14 11:28:35 2009 -0800 init: make initrd/initramfs decompression failure a KERN_EMERG event Impact: More consistent behaviour, avoid policy in the kernel Upgrade/downgrade initrd/initramfs decompression failure from inconsistently a panic or a KERN_ALERT message to a KERN_EMERG event. It is, however, possible do design a system which can recover from this (using the kernel builtin code and/or the internal initramfs), which means this is policy, not a technical necessity. A good way to handle this would be to have a panic-level=X option, to force a panic on a printk above a certain level. That is a separate patch, however. Signed-off-by: H. Peter Anvin I guess it is "possible to design a system which can recover from this", except noone seems to have bothered, since 2009. (Ditto for the proposed "panic-level=X" alternative.) I've now briefly considered posting a trivial kernel patch for this, but having learned about the above commit, I don't think so... Thanks Laszlo > Increasing ram from 1GB to 2GB allowed the 4.8 kernel to succeed in > unpacking and booting off of the initrd.