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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
