Date: Wed, 17 Dec 2014 14:17:57 +0100
Message-ID: <s5h61dabeka.wl-tiwai@suse.de>
From: Takashi Iwai <tiwai@suse.de>
To: Jeremiah Mahler <jmmahler@gmail.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>, Stephen Rothwell <sfr@canb.auug.org.au>,
        linux-kernel@vger.kernel.org, linux-next@vger.kernel.org,
        linux-fsdevel@vger.kernel.org
Subject: Re: [BUG, linux-next] spawn PID 1 without CLONE_FS, wireless inop
In-Reply-To: <20141216200351.GA1126@newt.localdomain>
References: <20141216115537.GA1259@hudson.localdomain>
	<20141216125615.GZ22149@ZenIV.linux.org.uk>
	<20141216132821.GA22149@ZenIV.linux.org.uk>
	<20141216140952.GA1224@hudson.localdomain>
	<20141216142542.GC22149@ZenIV.linux.org.uk>
	<20141216144610.GA1219@hudson.localdomain>
	<20141216150518.GD22149@ZenIV.linux.org.uk>
	<20141216152626.GA1228@hudson.localdomain>
	<20141216162716.GE22149@ZenIV.linux.org.uk>
	<20141216200351.GA1126@newt.localdomain>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka)
 FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.4
 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org

At Tue, 16 Dec 2014 12:03:51 -0800,
Jeremiah Mahler wrote:
> 
> Al Viro,
> 
> On Tue, Dec 16, 2014 at 04:27:16PM +0000, Al Viro wrote:
> > On Tue, Dec 16, 2014 at 07:26:26AM -0800, Jeremiah Mahler wrote:
> > 
> > > > No such errors happen on the normal boot, presumably?
> > > > 
> > > > > [    2.392117] EXT4-fs (sda5): mounting ext2 file system using the ext4 subsystem
> > > > > [    2.393920] EXT4-fs (sda5): mounted filesystem without journal. Opts: (null)
> > > > 
> > > > Wait a minute. So that happens _before_ /dev/sda5 mount?  Could you post dmesg
> > > > from the normal boot (e.g. just prior to the buggy commit)?
> > > > 
> > > > I really don't get it - there's nothing for init_fs.root to point to other
> > > > than initramfs by that point, CLONE_FS or no CLONE_FS.  We simply don't
> > > > have anything else mounted yet.  Do you get another failing bunch of
> > > > request_firmware later?  And what does dmesg look like on the working
> > > > kernel - either you have that firmware on initramfs image (in which case
> > > > it ought to have been picked by both kernels), or you do not, in which case
> > > > neither kernel would've managed to load it until after mounting the real
> > > > root...
> > > 
> > > I compiled this kernel with the commit just before the bug was introduced
> > > (93fe74b2e2b5d266d630f0c3f8287efcbe6ecd10).  Wireless comes up without
> > > any issue.  Here is the dmesg output.
> > 
> > OK, so the root is on sda6, it's been mounted before those attempts to
> > load firmware and init has been chrooted into it, while init_fs got left
> > behind.  And that "chrooted into" has happened without pivot_root(2) (or
> > it would've been caught by chroot_fs_refs() in sys_pivot_root()) and
> > not from the "no /init on initramfs" codepath (you do have it there).
> > 
> > OK, it's probably unsalvagable, then.  Pity, since it means that PID 1 and
> > kernel threads _must_ share ->fs, for the sake of usable ->fs->root, which
> > is asking for trouble.  And it means that we still need a sane solution for
> > nfsd folks...
> > 
> > Anyway, dropped that stuff from for-next (and for-linus, obviously), with
> > apologies all around.
> 
> On a totally different machine, an Acer C720, the sound quit working.
> I bisected that one and it pointed to this same commit.  However this
> one doesn't involve loading firmware or any of that stuff.  Attached
> are the good/bad dmesg logs.

Did you mean HD-audio stuff?  The bad case shows the error

[    2.122849] hda-i915: get_power symbol get fail
[    2.122856] snd_hda_intel 0000:00:03.0: Error request power-well from i915

This is the place calling request_symbol(), where i915 module should
have been loaded dynamically but it failed, likely because of the same
reason as the firmware loading failure.


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