From owner-freebsd-emulation Mon Jan 3 16:53:55 2000 Delivered-To: freebsd-emulation@freebsd.org Received: from io.dreamscape.com (io.dreamscape.com [206.64.128.6]) by hub.freebsd.org (Postfix) with ESMTP id E40341520A for ; Mon, 3 Jan 2000 16:53:46 -0800 (PST) (envelope-from krentel@dreamscape.com) Received: from dreamscape.com ([209.217.204.97]) by io.dreamscape.com (8.9.3/8.8.4) with ESMTP id TAA11223 for ; Mon, 3 Jan 2000 19:53:33 -0500 (EST) X-Dreamscape-Track-A: [209.217.204.97] X-Dreamscape-Track-B: Mon, 3 Jan 2000 19:53:33 -0500 (EST) Received: (from krentel@localhost) by dreamscape.com (8.9.3/8.9.3) id TAA03343 for freebsd-emulation@FreeBSD.ORG; Mon, 3 Jan 2000 19:53:44 -0500 (EST) (envelope-from krentel) Date: Mon, 3 Jan 2000 19:53:44 -0500 (EST) From: "Mark W. Krentel" Message-Id: <200001040053.TAA03343@dreamscape.com> To: freebsd-emulation@FreeBSD.ORG Subject: running linux binaries from ext2fs partition Sender: owner-freebsd-emulation@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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