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

[Jeremiah Mahler <jmmahler@gmail.com>]

Takashi,

On Wed, Dec 17, 2014 at 02:17:57PM +0100, Takashi Iwai wrote:
> At Tue, 16 Dec 2014 12:03:51 -0800,
> Jeremiah Mahler wrote:
> > 
> > Al Viro,
[...]
> > > 
> > > 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.
> 

Ah, perhaps it does load firmware.  Then I am mistaken on that point.

> 
> Takashi

-- 
- Jeremiah Mahler