Date: Mon, 3 Jan 2000 19:53:44 -0500 (EST) From: "Mark W. Krentel" <krentel@dreamscape.com> To: freebsd-emulation@FreeBSD.ORG Subject: running linux binaries from ext2fs partition Message-ID: <200001040053.TAA03343@dreamscape.com>
next in thread | raw e-mail | index | archive | help
Last month, I reported a problem when running linux binaries directly
from an ext2fs partition. I've done several more tests to narrow down
the problem, and I can now produce a kernel dump (see below).
Here's what it takes to produce the bug: (1) a Red Hat linux binary,
(2) one from linux's /bin (one that uses /lib instead of /usr/lib),
(3) run from an ext2fs partition, (4) in stable.
By contrast, I can run Red Hat binaries from /usr/bin or /usr/X11R6/bin.
I can run SuSE 6.3 binaries from /bin. (Does SuSE keep separate /lib
and /usr/lib like Red Hat?) And I can run Red Hat /bin binaries by
copying them to a UFS partition. But running Red Hat's /bin/ls from
its ext2fs partition produces an immediate panic. As for stable vs.
current, well, I don't run current, so I don't know.
It's not a new problem. I'm currently running 3.4-Release, the
linux_base-6.0 port with Red Hat 6.0 installed on a spare disk. But I
saw the same problem with Red Hat 5.2 and the linux_base-5.2 port.
And it's not something like bad sectors on the disk. I've installed
Red Hat on two disks, and it panics on both.
I've seen a few different panic messages:
vfs_busy: unexpected lock failure
ext2fs_statfs - magic number spoiled
lockmgr: pid 409, not exclusive lock holder 848 unlocking
So, perhaps the in-core version of the ext2fs partition is getting
corrupted which then causes the panic (I mount the ext2fs partition
read-only).
I'd really like to track this down, but I don't know enough about the
internals of linux emulation or ext2fs. But I can run experiments if
some developer suggests what to try.
Here's a sample kernel dump. This is in 3.4-Release with the
linux_base-6.0 port. The kernel is 3.4 GENERIC plus EXT2FS and
IPFIREWALL and minus a bunch of devices I don't have. I mounted
Red Hat's / on /mnt (read-only), then as user, I cd'd to /mnt/bin,
ran "./ls -l" and I got this panic:
% gdb -k
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd".
(kgdb) symbol /usr/src/sys/compile/RHTEST/kernel.debug
Reading symbols from /usr/src/sys/compile/RHTEST/kernel.debug...done.
(kgdb) exec-file /var/crash/kernel.3
(kgdb) core-file /var/crash/vmcore.3
IdlePTD 2506752
initial pcb at 200f18
panicstr: vfs_busy: unexpected lock failure
panic messages:
---
panic: lockmgr: pid 409, not exclusive lock holder 848 unlocking
syncing disks... panic: vfs_busy: unexpected lock failure
dumping to dev 401, offset 196608
dump 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41
40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:285
285 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=260) at ../../kern/kern_shutdown.c:285
#1 0xc0141f7c in at_shutdown (
function=0xc01dd20b <__set_sysctl__kern_sym_sysctl___kern_maxvnodes+19>,
arg=0xc45b9cac, queue=-1072265566) at ../../kern/kern_shutdown.c:446
#2 0xc01653e5 in vfs_busy (mp=0xc08d5400, flags=16, interlkp=0xc021809c,
p=0xc0217024) at ../../kern/vfs_subr.c:201
#3 0xc01686a2 in sync (p=0xc0217024, uap=0x0) at ../../kern/vfs_syscalls.c:541
#4 0xc0141b3d in boot (howto=256) at ../../kern/kern_shutdown.c:203
#5 0xc0141f7c in at_shutdown (
function=0xc01da868 <__set_sysuninit_set_sym_M_KTRACE_uninit_sys_uninit+208>,
arg=0x199, queue=-1071798190) at ../../kern/kern_shutdown.c:446
#6 0xc013dd2b in lockmgr (lkp=0xc08f9a00, flags=6, interlkp=0xc45c48b0,
p=0xc455c5a0) at ../../kern/kern_lock.c:373
#7 0xc0163d43 in vop_stdunlock (ap=0xc45b9dbc) at ../../kern/vfs_default.c:232
#8 0xc019a0bd in ufs_vnoperate (ap=0xc45b9dbc) at ../../ufs/ufs/ufs_vnops.c:2300
#9 0xc08aa7d6 in ?? ()
#10 0xc01c0043 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 3,
tf_esi = -1077946520, tf_ebp = -1077945612, tf_isp = -1000628252, tf_ebx = 3,
tf_edx = 849, tf_ecx = -1077946520, tf_eax = 141, tf_trapno = 12, tf_err = 2,
tf_eip = 672096315, tf_cs = 31, tf_eflags = 642, tf_esp = -1077946524,
tf_ss = 39}) at ../../i386/i386/trap.c:1100
#11 0xc01b64fc in Xint0x80_syscall ()
#12 0x280f5cc7 in ?? ()
#13 0x804a6d5 in ?? ()
#14 0x8049594 in ?? ()
#15 0x28081cb3 in ?? ()
(kgdb) up 6
#6 0xc013dd2b in lockmgr (lkp=0xc08f9a00, flags=6, interlkp=0xc45c48b0,
p=0xc455c5a0) at ../../kern/kern_lock.c:373
373 panic("lockmgr: pid %d, not %s %d unlocking",
(kgdb) info lo
lkp = (struct lock *) 0xc01da868
flags = 0
p = (struct proc *) 0x0
error = 0
pid = 409
extflags = 256
(kgdb) up
#7 0xc0163d43 in vop_stdunlock (ap=0xc45b9dbc) at ../../kern/vfs_default.c:232
232 return (lockmgr(l, ap->a_flags | LK_RELEASE, &ap->a_vp->v_interlock,
(kgdb) info lo
ap = (struct vop_unlock_args *) 0x0
l = (struct lock *) 0x0
(kgdb) up
#8 0xc019a0bd in ufs_vnoperate (ap=0xc45b9dbc) at ../../ufs/ufs/ufs_vnops.c:2300
2300 return (VOCALL(ufs_vnodeop_p, ap->a_desc->vdesc_offset, ap));
(kgdb) info lo
ap = (struct vop_generic_args *) 0x0
(kgdb) up
#9 0xc08aa7d6 in ?? ()
(kgdb) up
#10 0xc01c0043 in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 3,
tf_esi = -1077946520, tf_ebp = -1077945612, tf_isp = -1000628252, tf_ebx = 3,
tf_edx = 849, tf_ecx = -1077946520, tf_eax = 141, tf_trapno = 12, tf_err = 2,
tf_eip = 672096315, tf_cs = 31, tf_eflags = 642, tf_esp = -1077946524,
tf_ss = 39}) at ../../i386/i386/trap.c:1100
1100 error = (*callp->sy_call)(p, args);
(kgdb) info lo
params = 0x0
callp = (struct sysent *) 0xc45c4840
p = (struct proc *) 0xc455c5a0
sticks = 0
error = 3
args = {3, -1077946520, 849, -1077946520, 3, 134578740, 0, 0}
code = 141
(kgdb) up
#11 0xc01b64fc in Xint0x80_syscall ()
(kgdb)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-emulation" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001040053.TAA03343>