lkml.org 
[lkml]   [2014]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BUG, linux-next] spawn PID 1 without CLONE_FS, wireless inop
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


\
 
 \ /
  Last update: 2014-12-17 15:01    [W:0.152 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site