Re: [BUG, linux-next] spawn PID 1 without CLONE_FS, wireless inop

[Takashi Iwai <tiwai@suse.de>]

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