2.6.28.[45] boot failure: request_module: runaway loop modprobe binfmt-464c
Tilman Schmidt
mirrored SATA disks), which runs fine with kernel:
ts@xenon:~> uname -a
Linux xenon 2.6.28.3-testing #1 SMP PREEMPT Mon Feb 2 23:32:07 CET 2009 i686 i686 i386 GNU/Linux
fails to come up with an identically configured 2.6.28.4 or 2.6.28.5
kernel. The boot process hangs at about the time the root
file system is mounted, the last messages being (scribbled
down manually on a piece of paper, please make allowances):
/dev/RAID/root: recovering journal ... clean
fsck successful. Mounting root device r/w
Mounting root /dev/RAID/root
kjournald starting. Commit interval 5 seconds
EXT3 FS on dm-0, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c
request_module: runaway loop modprobe binfmt-464c
After a pause of about 15 seconds, there is another set of
messages:
CPA self-test:
4k 3070 large 219 gb 0 x 3289[c0000000-f77fd000] miss 0
4k 194558 large 32 gb 0 x 194590[c0000000-f77fd000] miss 0
4k 194558 large 32 gb 0 x 194590[c0000000-f77fd000] miss 0
ok.
Then, silence. The keyboard remains operative inasmuch as I can
use the SysRq functions to sync and reboot, but otherwise the
system does not go any further. Going back to kernel 2.6.28.3
the system comes up fine again.
The most conspicuous symtpom is of course the five consecutive
"runaway loop" messages I never saw before. But before that,
the order in which the PCI and USB devices are detected also
appears surprisingly changed for a stable release.
I am prepared to bisect this if somebody reminds me how to do
that for stable releases. The tree
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
doesn't seem to have them.
Thanks
Tilman
--
Tilman Schmidt E-Mail: til...@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
Kay Sievers
> My workhorse machine (Pentium D 940, Intel DG965QF board,
> mirrored SATA disks), which runs fine with kernel:
> ts@xenon:~> uname -a
> Linux xenon 2.6.28.3-testing #1 SMP PREEMPT Mon Feb 2 23:32:07 CET 2009 i686 i686 i386 GNU/Linux
> fails to come up with an identically configured 2.6.28.4 or 2.6.28.5
> kernel. The boot process hangs at about the time the root
> file system is mounted, the last messages being (scribbled
> down manually on a piece of paper, please make allowances):
>
> /dev/RAID/root: recovering journal ... clean
> fsck successful. Mounting root device r/w
> Mounting root /dev/RAID/root
> kjournald starting. Commit interval 5 seconds
> EXT3 FS on dm-0, internal journal
> EXT3-fs: mounted filesystem with ordered data mode.
> request_module: runaway loop modprobe binfmt-464c
> request_module: runaway loop modprobe binfmt-464c
> request_module: runaway loop modprobe binfmt-464c
> request_module: runaway loop modprobe binfmt-464c
> request_module: runaway loop modprobe binfmt-464c
Are you sure, that you don't have a 32/64 bit mismatch between the
kernel and userspace? Like you miss 32-bit emulation in a 64-bit
kernel, or your modprobe is 64-bit and you are trying to run it on a
32-bit kernel?
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Tilman Schmidt
> On Tue, Feb 17, 2009 at 10:09, Tilman Schmidt <til...@imap.cc> wrote:
>> My workhorse machine (Pentium D 940, Intel DG965QF board,
>> mirrored SATA disks), which runs fine with kernel:
>> ts@xenon:~> uname -a
>> Linux xenon 2.6.28.3-testing #1 SMP PREEMPT Mon Feb 2 23:32:07 CET 2009 i686 i686 i386 GNU/Linux
>> fails to come up with an identically configured 2.6.28.4 or 2.6.28.5
>
> Are you sure, that you don't have a 32/64 bit mismatch between the
> kernel and userspace? Like you miss 32-bit emulation in a 64-bit
> kernel, or your modprobe is 64-bit and you are trying to run it on a
> 32-bit kernel?
Pretty sure. Although running on a 64 bit capable processor, this
is a pure 32 bit installation:
ts@xenon:~> file /sbin/modprobe
/sbin/modprobe: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), stripped
ts@xenon:~> uname -a
Linux xenon 2.6.28.3-testing #1 SMP PREEMPT Mon Feb 2 23:32:07 CET 2009 i686 i686 i386 GNU/Linux
ts@xenon:~> diff kernel/linux-2.6.28.{3,5}-work/.config
3,4c3,4
< # Linux kernel version: 2.6.28.3
< # Mon Feb 2 22:41:42 2009
---
> # Linux kernel version: 2.6.28.5
> # Sat Feb 14 00:06:09 2009
ts@xenon:~> file /boot/vmlinuz-2.6.28.*
/boot/vmlinuz-2.6.28.3-testing: Linux/x86 Kernel, Setup Version 0x209, bzImage, Version 2.6.28.3, RO-rootFS, swap_dev 0x2, Normal VGA
/boot/vmlinuz-2.6.28.5-testing: Linux/x86 Kernel, Setup Version 0x209, bzImage, Version 2.6.28.5, RO-rootFS, swap_dev 0x2, Normal VGA
ts@xenon:~>
The first one of these two kernels runs fine, the second one hangs.
Thanks,
Tilman Schmidt
>> request_module: runaway loop modprobe binfmt-464c
>> request_module: runaway loop modprobe binfmt-464c
>> request_module: runaway loop modprobe binfmt-464c
>> request_module: runaway loop modprobe binfmt-464c
>> request_module: runaway loop modprobe binfmt-464c
>
> Are you sure, that you don't have a 32/64 bit mismatch between the
> kernel and userspace? Like you miss 32-bit emulation in a 64-bit
> kernel, or your modprobe is 64-bit and you are trying to run it on a
> 32-bit kernel?
Aaaugh, never mind my previous reply, you were right on spot!
"make install" had picked up the wrong root partition when it
created the GRUB menu entry for the new kernel, so it actually
tried to boot an experimental 64 bit installation on a different
disk with my newly built 32 bit kernels. That'll teach me not to
choose too similar partition names.
Now to find out how "make install" creates its GRUB menu entries
and why it suddenly started to go wrong ...
Thanks,