[Re: panic: blockable sleep lock (sleep mutex) Giant @/usr/src/sys/vm/vm_fault.c:206
* John Baldwin <[EMAIL PROTECTED]> [2003-03-25 18.41 -0500]: Hi John, > http://www.FreeBSD.org/~jhb/patches/linux.patch Similar to Drew's > except that I patched alpha as well. Similarly untested. Apply > with patch -p6 while in /sys. Please let me know if it fixes the > problem. It fixes the problem. I loaded/unloaded the module a few times, and ran various linux-dependant apps. Thank you. (And thanks for the instructions you mailed me, Drew.) Best regards, -- Martin Karlsson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[Re: panic: blockable sleep lock (sleep mutex) Giant @/usr/src/sys/vm/vm_fault.c:206
Martin Karlsson writes: > * John Baldwin <[EMAIL PROTECTED]> [2003-03-25 18.41 -0500]: > > [...snip...] > > > http://www.FreeBSD.org/~jhb/patches/linux.patch Similar to Drew's > > except that I patched alpha as well. Similarly untested. Apply > > with patch -p6 while in /sys. Please let me know if it fixes the > > problem. > > Sure, I'll try it. And then? Rebuild your linux module. cd /sys/modules/linux make depend make If you've never loaded linux (and won't crash because of the bug), then load the new module: kldload ./linux.ko kldunload linux Else just install the module and reboot cp linux.ko /boot/kernel/ shutdown -r now > > BTW, I've backed up my /usr/src dir, so I can apply the two > patches "one by one". Or should I apply them together? (Actually, I don't > mind testing all three options, but I'd like to hear what you have to > say about this. Just apply John's patch. Its cleaner & suitable for committing if it works. Mine was a quick hack while waiting for my dinner to microwave itself.. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
* John Baldwin <[EMAIL PROTECTED]> [2003-03-25 18.41 -0500]: [...snip...] > http://www.FreeBSD.org/~jhb/patches/linux.patch Similar to Drew's > except that I patched alpha as well. Similarly untested. Apply > with patch -p6 while in /sys. Please let me know if it fixes the > problem. Sure, I'll try it. And then? '# cd /usr/src/sys/compat/linux && make && make install' followed by reboot and crash test? (Or rebuild/reinstall world?) BTW, I've backed up my /usr/src dir, so I can apply the two patches "one by one". Or should I apply them together? (Actually, I don't mind testing all three options, but I'd like to hear what you have to say about this. Best regards, -- Martin Karlsson <--- newbie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
* Andrew Gallatin <[EMAIL PROTECTED]> [2003-03-25 18.10 -0500]: [...snip text...] > Index: compat/linux/linux_mib.c > === [...snip patch] Hi! Sure, I'll try it. But, from where (i.e. which directory) should I apply it, and with which value N for patch -pN? And then what? '# cd /usr/src/sys && make && make install' followed by a reboot and do a crash test? (Or should I rebuild/reinstall world?) /me == newbie :) -- Martin Karlsson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
On 25-Mar-2003 John Baldwin wrote:
>
> On 25-Mar-2003 Andrew Gallatin wrote:
>>
>> Martin Karlsson writes:
>>
>> > #9 0xc02dca88 in calltrap () at {standard input}:96
>> > #10 0xc01e7b0b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:528
>> > #11 0xc020256e in witness_lock (lock=0xc03760c0, flags=8, file=0xc0332416
>> "/usr/src/sys/vm/vm_fault.c", line=206)
>> > at /usr/src/sys/kern/subr_witness.c:604
>> > #12 0xc01e0237 in _mtx_lock_flags (m=0xc03760c0, opts=0, file=0xc0332416
>> "/usr/src/sys/vm/vm_fault.c", line=206) at /usr/src/sys/kern/kern_mutex.c:336
>>
>>
>> It looks like the witness mutex debugging system crashed. This sort
>> of thing tends to happen when the witness data structures become
>> corrupt. A frequent cause of this is a module failing to destroy a
>> mutex.
>>
>> I think the recent addition of the
>>
>> MTX_SYSINIT(linux_osname, &osname_lock, "linux osname", MTX_DEF);
>>
>> could be causing the problem, as I do not see how its getting torn
>> down.
>
> Oh, good catch Drew. My bad it seems :( I'll work up a patch.
http://www.FreeBSD.org/~jhb/patches/linux.patch Similar to Drew's
except that I patched alpha as well. Similarly untested. Apply
with patch -p6 while in /sys. Please let me know if it fixes the
problem.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
John Baldwin writes: > > Oh, good catch Drew. My bad it seems :( I'll work up a patch. > I see this all the time when people add code to our driver, test it only on linux. So I'm quite used to the symptoms ;) Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
On 25-Mar-2003 Andrew Gallatin wrote:
>
> Martin Karlsson writes:
>
> > #9 0xc02dca88 in calltrap () at {standard input}:96
> > #10 0xc01e7b0b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:528
> > #11 0xc020256e in witness_lock (lock=0xc03760c0, flags=8, file=0xc0332416
> "/usr/src/sys/vm/vm_fault.c", line=206)
> > at /usr/src/sys/kern/subr_witness.c:604
> > #12 0xc01e0237 in _mtx_lock_flags (m=0xc03760c0, opts=0, file=0xc0332416
> "/usr/src/sys/vm/vm_fault.c", line=206) at /usr/src/sys/kern/kern_mutex.c:336
>
>
> It looks like the witness mutex debugging system crashed. This sort
> of thing tends to happen when the witness data structures become
> corrupt. A frequent cause of this is a module failing to destroy a
> mutex.
>
> I think the recent addition of the
>
> MTX_SYSINIT(linux_osname, &osname_lock, "linux osname", MTX_DEF);
>
> could be causing the problem, as I do not see how its getting torn
> down.
Oh, good catch Drew. My bad it seems :( I'll work up a patch.
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
Martin Karlsson writes:
> #9 0xc02dca88 in calltrap () at {standard input}:96
> #10 0xc01e7b0b in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:528
> #11 0xc020256e in witness_lock (lock=0xc03760c0, flags=8, file=0xc0332416
> "/usr/src/sys/vm/vm_fault.c", line=206)
> at /usr/src/sys/kern/subr_witness.c:604
> #12 0xc01e0237 in _mtx_lock_flags (m=0xc03760c0, opts=0, file=0xc0332416
> "/usr/src/sys/vm/vm_fault.c", line=206) at /usr/src/sys/kern/kern_mutex.c:336
It looks like the witness mutex debugging system crashed. This sort
of thing tends to happen when the witness data structures become
corrupt. A frequent cause of this is a module failing to destroy a
mutex.
I think the recent addition of the
MTX_SYSINIT(linux_osname, &osname_lock, "linux osname", MTX_DEF);
could be causing the problem, as I do not see how its getting torn
down.
Can you try the following patch (it may not even compile, I don't
have a current box handy):
(its obviously incomplete, just intended to see if it fixes the
problem you are seeing)
Drew
Index: compat/linux/linux_mib.c
===
RCS file: /home/ncvs/src/sys/compat/linux/linux_mib.c,v
retrieving revision 1.19
diff -u -r1.19 linux_mib.c
--- compat/linux/linux_mib.c13 Mar 2003 22:45:43 - 1.19
+++ compat/linux/linux_mib.c25 Mar 2003 23:05:08 -
@@ -50,7 +50,7 @@
SYSCTL_NODE(_compat, OID_AUTO, linux, CTLFLAG_RW, 0,
"Linux mode");
-static struct mtx osname_lock;
+struct mtx osname_lock;
MTX_SYSINIT(linux_osname, &osname_lock, "linux osname", MTX_DEF);
static charlinux_osname[LINUX_MAX_UTSNAME] = "Linux";
Index: i386/linux/linux_sysvec.c
===
RCS file: /home/ncvs/src/sys/i386/linux/linux_sysvec.c,v
retrieving revision 1.116
diff -u -r1.116 linux_sysvec.c
--- i386/linux/linux_sysvec.c 21 Mar 2003 19:49:34 - 1.116
+++ i386/linux/linux_sysvec.c 25 Mar 2003 23:07:36 -
@@ -885,6 +885,7 @@
&linux_glibc2brand,
NULL
};
+extern struct mtx osname_lock;
static int
linux_elf_modevent(module_t mod, int type, void *data)
@@ -925,6 +926,7 @@
linux_ioctl_unregister_handler(*lihp);
if (bootverbose)
printf("Linux ELF exec handler removed\n");
+ mtx_destroy(&osname_lock);
} else
printf("Could not deinstall ELF interpreter entry\n");
break;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
On Sun, Jan 05, 2003 at 08:54:01PM -0600, ryan beasley wrote:
> I'm including a GDB capture including traceback and some locking
> information. Anyone have any ideas? Is there any other data I should
> grab and submit?
I'm really sorry for following up to myself again, but the following
might be useful:
(gdb)
#8 0xc01bce28 in enroll (description=0xc02e3718 "vnode interlock",
lock_class=0xc0300fc0)
at /home/ryanb/FREDRIK_DP_INV/sys/kern/subr_witness.c:985
985 if (w->w_name == description || (w->w_refcount > 0 &&
Current language: auto; currently c
(gdb) p *w
$16 = {w_name = 0xc16fd8fe ,
w_class = 0xc0300fc0, w_list = {stqe_next = 0xc032fa50}, w_typelist = {
stqe_next = 0xc032fa50}, w_children = 0x0, w_file = 0x0, w_line = 0,
w_level = 0, w_refcount = 2, w_Giant_squawked = 0 '\0',
w_other_squawked = 0 '\0', w_same_squawked = 0 '\0'}
This is the instruction where the page fault occurred. As to how w_name
was clobbered, I have no idea.
--
ryan beasley<[EMAIL PROTECTED]>
GPG ID: 0x16EFBD48 http://www.goddamnbastard.org
msg49751/pgp0.pgp
Description: PGP signature
Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
On Sat, Jan 04, 2003 at 10:31:45AM -0600, ryan beasley wrote:
> Sources are HEAD from Dec 28th, 2002, 04:00 -0600.
> DDB session reprinted below. dmesg at the tail.
OK, I found a way to reproduce this one, but given that it only happens
with a 3rd party module, I'm not necessarily sure where the fault lies.
*boot in multiuser (vesa/miibus/if_dc loaded)*
load module
unload module
*panic*
I'm including a GDB capture including traceback and some locking
information. Anyone have any ideas? Is there any other data I should
grab and submit?
(gdb) bt
#0 Debugger (msg=0x12 ) at atomic.h:260
#1 0xc019a03b in panic (fmt=0x0)
at /home/ryanb/FREDRIK_DP_INV/sys/kern/kern_shutdown.c:503
#2 0xc01bbfff in witness_lock (lock=0xc0301160, flags=8,
file=0xc02ea34e "/usr/src/sys/vm/vm_fault.c", line=206)
at /home/ryanb/FREDRIK_DP_INV/sys/kern/subr_witness.c:508
#3 0xc0190441 in _mtx_lock_flags (m=0xc0300fc0, opts=0,
file=0xc0301160 "À\0170ÀJ¿-ÀJ¿-À", line=206)
at /usr/src/sys/kern/kern_mutex.c:328
#4 0xc0271789 in vm_fault (map=0xc082f000, vaddr=3245330432,
fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:206
#5 0xc02b6ac1 in trap_pfault (frame=0xca3e27b8, usermode=0, eva=3245332734)
at /usr/src/sys/i386/i386/trap.c:746
#6 0xc02b669d in trap (frame=
{tf_fs = 24, tf_es = -1070268400, tf_ds = -1070596080, tf_edi =
-1070713064, tf_esi = -1070592064, tf_ebp = -901896196, tf_isp = -901896220,
tf_ebx = -1070400984, tf_edx = -1070713064, tf_ecx = -1049634562, tf_eax =
-1049634562, tf_trapno = 12, tf_err = 0, tf_eip = -1071664406, tf_cs = 8,
tf_eflags = 66050, tf_esp = -1070400984, tf_ss = -901896160}) at
/usr/src/sys/i386/i386/trap.c:445
#7 0xc02a7158 in calltrap () at {standard input}:98
#8 0xc01bce28 in enroll (description=0xc02e3718 "vnode interlock",
lock_class=0xc0300fc0)
at /home/ryanb/FREDRIK_DP_INV/sys/kern/subr_witness.c:985
#9 0xc01bbcb5 in witness_init (lock=0xc032fa28)
---Type to continue, or q to quit---
at /home/ryanb/FREDRIK_DP_INV/sys/kern/subr_witness.c:388
#10 0xc0190eb1 in mtx_init (m=0xc02e3718, name=0xc02e3718 "vnode interlock",
type=0x0, opts=0) at /usr/src/sys/kern/kern_mutex.c:940
#11 0xc01ebe6f in getnewvnode (tag=0xc02e56e9 "ufs", mp=0x12, vops=0x12,
vpp=0x12) at /usr/src/sys/kern/vfs_subr.c:1000
#12 0xc025fc6b in ffs_vget (mp=0xc09fdc00, ino=481954, flags=2, vpp=0xca3e2984)
at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1254
#13 0xc026706b in ufs_lookup (ap=0xca3e2ab8)
at /usr/src/sys/ufs/ufs/ufs_lookup.c:601
#14 0xc026d5f8 in ufs_vnoperate (ap=0x0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2796
#15 0xc01e2bac in vfs_cache_lookup (ap=0x12) at vnode_if.h:82
#16 0xc026d5f8 in ufs_vnoperate (ap=0x0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2796
#17 0xc01e7172 in lookup (ndp=0xca3e2c24) at vnode_if.h:52
#18 0xc01e6b6e in namei (ndp=0xca3e2c24) at /usr/src/sys/kern/vfs_lookup.c:181
#19 0xc01f4152 in stat (td=0xc1266000, uap=0xca3e2d10)
at /usr/src/sys/kern/vfs_syscalls.c:1654
#20 0xc02b714e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135567080, tf_esi =
135655208, tf_ebp = -1077937688, tf_isp = -901894796, tf_ebx = 135567080, tf_edx
= 135564138, tf_ecx = 135655219, tf_eax = 188, tf_trapno = 12, tf_err = 2,
tf_eip = 134954771, tf_cs = 31, tf_eflags = 662, tf_esp = -1077937812, tf_ss =
47})
at /usr/src/sys/i386/i386/trap.c:1033
(gdb)
#2 0xc01bbfff in witness_lock (lock=0xc0301160, flags=8,
file=0xc02ea34e "/usr/src/sys/vm/vm_fault.c", line=206)
at /usr/src/sys/kern/subr_witness.c:508
translating /usr/src/sys/kern/subr_witness.c ->
/home/ryanb/FREDRIK_DP_INV/sys/kern/subr_witness.c
508 panic("blockable sleep lock (%s) %s @ %s:%d (td
%p)",
(gdb) p td
$1 = (struct thread *) 0xc1266000
(gdb) p *lock
$2 = {lo_class = 0xc0300fc0, lo_name = 0xc02dbf4a "Giant",
lo_type = 0xc02dbf4a "Giant", lo_flags = 0xb, lo_list = {
tqe_next = 0xc0301120, tqe_prev = 0xc03041f0}, lo_witness = 0xc0330f18}
(gdb) p *td->td_sleeplocks
$3 = {ll_next = 0x0, ll_children = {{li_lock = 0xc0301160,
li_file = 0xc02efb57 "/usr/src/sys/i386/i386/trap.c", li_line = 1025,
li_flags = 131072}, {li_lock = 0xc122a0d8,
li_file = 0xc02ec088 "/usr/src/sys/vm/uma_core.c", li_line = 1335,
li_flags = 131072}, {li_lock = 0xc122a024,
li_file = 0xc02ec088 "/usr/src/sys/vm/uma_core.c", li_line = 1352,
li_flags = 131072}}, ll_count = 1}
(gdb) p *td->td_sleeplocks.ll_children[0].li_lock
$4 = {lo_class = 0xc0300fc0, lo_name = 0xc02dbf4a "Giant",
lo_type = 0xc02dbf4a "Giant", lo_flags = 0xb, lo_list = {
tqe_next = 0xc0301120, tqe_prev = 0xc03041f0}, lo_witness = 0xc0330f18}
(gdb) p *td->td_sleeplocks.ll_children[1].li_lock
$5 = {lo_class = 0xc0300fc0, lo_name = 0xc122a000 "PCPU VNODE",
lo_type = 0xc02ec1e8 "UMA cpu", lo_flags = 0x43, lo_list = {
tqe_next = 0xc122a144, tqe_prev = 0xc122a034}, lo_witnes
