Re: panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/s
On Tue, Jan 07, 2003 at 11:41:33AM -0500, John Baldwin wrote: > Your 3rd party registered a lock somehow? Does it do mtx_init() and not > do mtx_destroy() when being unloaded? Gah! You hit this one right on the head. I thought I had equivalent mtx_destroy calls for every mtx_init, but there's a section of code that bzero()s a structure containing a mutex before initializing that mutex, so that caused this common mutex to be initialized twice without triggering a panic in witness_init(). The subsequent destroy only removed the one instance. I've fixed said code and now I can load/unload to my little heart's content. :). Thanks for replying. -- ryan beasley<[EMAIL PROTECTED]> GPG ID: 0x16EFBD48 msg49860/pgp0.pgp Description: PGP signature
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
$
Re: current/stable remote gdb interoperability
On Sat, Jan 04, 2003 at 06:32:43AM +1100, Bruce Evans wrote:
> Another possible problem is using the same serial line for gdb as for
> the console and mixing speeds. If the userland speed differs from the
> low level speed, then the i/o routines switch back and forth between
> the speeds for every character and this tends to lose some. The
> userland speed is locked to the low level speed initially but userland
> unlock it. Losing a character or two is almost unnoticable in ddb but
> is fatal in gdb. I normally set all speeds to 115200 so I only see this
> problem when I look for it.
Unless I'm misunderstanding, the serial port isn't doing any such double
duty. I've explicity toggled between sio flags 0x10 and 0x80 in
device.hints depending on what I'm trying to figure out. (In reality,
it's more often trying to get useful information for others that can
figure stuff out. :).)
For what it's worth, I've taken Nate's suggestion and backed down to
9600bps, and this problem hasn't occurred yet, so I'm assuming this is
the "fix". (The 4.7 machine has an ASUS P2B-D board, and the -CURRENT
box is a recent Dell Dimension, so I don't *think* I'm using garbage
serial hardware.) Though slow, I guess I can't complain if it works.
:).
--
ryan beasley<[EMAIL PROTECTED]>
GPG ID: 0x16EFBD48 http://www.goddamnbastard.org
msg49699/pgp0.pgp
Description: PGP signature
LOR - inp / tcp
000 1 448 0004102 norm[SLPQwait c14701c8][SLP] login 447 c1470390 ca65a0000 1 447 0004102 norm[SLPQwait c1470390][SLP] login 446 c1470558 ca65b0000 1 446 0004102 norm[SLPQwait c1470558][SLP] login 445 c1470720 ca65c0000 1 445 0004102 norm[SLPQwait c1470720][SLP] login 436 c124ac78 ca3d70000 1 436 000 norm[SLPQ nanslp c032e794][SLP] cron 399 c124aab0 ca3d6000 25 1 399 2000100 norm[SLPQ pause ca3d6000][SLP] sendmail 393 c1265000 ca3d80000 1 393 100 norm[CVQ select c03043b4][SLP] sshd 220 c1265ab0 ca3de0000 1 220 000 norm[CVQ select c03043b4][SLP] syslogd 170 c1265c78 ca3df0000 0 0 204 norm[IWAIT] irq9: dc0 115 c12651c8 ca3d90000 1 115 200 norm[SLPQ pause ca3d9000][SLP] adjkerntz 31 c12671c8 ca4170000 0 0 204 norm[SLPQ nfsidl c030d8cc][SLP] nfsiod 3 30 c11a4558 c63850000 0 0 204 norm[SLPQ nfsidl c030d8c8][SLP] nfsiod 2 29 c11a4720 c63bc0000 0 0 204 norm[SLPQ nfsidl c030d8c4][SLP] nfsiod 1 28 c11a48e8 c63bd0000 0 0 204 norm[SLPQ nfsidl c030d8c0][SLP] nfsiod 0 27 c11a4ab0 c63be0000 0 0 204 norm[SLPQ vlruwt c11a4ab0][SLP] vnlru 9 c11a4c78 c63bf0000 0 0 204 norm[SLPQ syncer c030226c][SLP] syncer 8 c124a000 ca3d0 0 0 204 norm[SLPQ psleep c03535f4][SLP] bufdaemon 7 c124a1c8 ca3d10000 0 0 20c norm[SLPQ pgzero c0355054][SLP] pagezero 6 c124a390 ca3d20000 0 0 204 norm[SLPQ psleep c035506c][SLP] vmdaemon 5 c124a558 ca3d30000 0 0 204 norm[SLPQ psleep c03127d8][SLP] pagedaemon 26 c124a720 ca3d40000 0 0 204 new [IWAIT] irq8: rtc 25 c124a8e8 ca3d50000 0 0 204 new [IWAIT] irq0: clk 24 c09f11c8 c5f7a0000 0 0 204 new [IWAIT] irq4: sio0 23 c09f1390 c5f7b0000 0 0 204 norm[IWAIT] swi0: tty:sio 22 c09f1558 c5f7c0000 0 0 204 norm[IWAIT] irq6: fdc0 21 c09f1720 c5f7d0000 0 0 204 new [IWAIT] irq12: psm0 20 c09f18e8 c5f7e0000 0 0 204 norm[IWAIT] irq1: atkbd0 19 c09f1ab0 c5f7f0000 0 0 204 norm[IWAIT] irq15: ata1 18 c09f1c78 c5f80 0 0 204 norm[IWAIT] irq14: ata0 17 c11a4000 c63820000 0 0 204 new [IWAIT] irq13: 16 c11a41c8 c63830000 0 0 204 new [IWAIT] swi5: task queue 15 c11a4390 c63840000 0 0 204 norm[SLPQ sleep c031c0a0][SLP] random 4 c09ea000 c5f050000 0 0 204 norm[SLPQ g_down c02fb770][SLP] g_down 3 c09ea1c8 c5f720000 0 0 204 norm[SLPQg_up c02fb76c][SLP] g_up 2 c09ea390 c5f730000 0 0 204 norm[SLPQ g_events c02fb764][SLP] g_event 14 c09ea558 c5f740000 0 0 204 new [IWAIT] swi4: vm 13 c09ea720 c5f750000 0 0 20c norm[RUNQ] swi6: tty:sio clock 12 c09ea8e8 c5f760000 0 0 204 norm[CPU 0] swi1: net 11 c09eaab0 c5f770000 0 0 20c norm[Can run] idle 1 c09eac78 c5f780000 0 1 0004200 norm[SLPQwait c09eac78][SLP] init 10 c09f1000 c5f790000 0 0 204 norm[CVQ ktrace c032b2b4][SLP] ktrace 0 c02fc9c0 c04030000 0 0 200 norm[SLPQ sched c02fc9c0][SLP] swapper db> -- ryan beasley<[EMAIL PROTECTED]> GPG ID: 0x16EFBD48 http://www.goddamnbastard.org msg49695/pgp0.pgp Description: PGP signature
panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206
0 Uptime: 15m40s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:360 Uptime: 15m40s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:360 Uptime: 15m40s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:360 Uptime: 15m40s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:360 Uptime: 15m40s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:360 Uptime: 15m40s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:360 Uptime: 15m40s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:360 Uptime: 15m40s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:360 Uptime: 15m40s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:360 Uptime: 15m40s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:360 Uptime: 15m40s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:360 Uptime: 15m40s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:360 Uptime: 15m40s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:360 Uptime: 15m40s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:360 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #7: Fri Jan 3 09:25:52 CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FREDRIK_DP_INV Preloaded elf kernel "/boot/kernel/kernel" at 0xc03e3000. Preloaded elf module "/boot/kernel/vesa.ko" at 0xc03e30b4. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2392297804 Hz CPU: Pentium 4 (2392.30-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff real memory = 67108864 (64 MB) avail memory = 61079552 (58 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc03e0c22 (122) VESA: NVidia npx0: on motherboard npx0: INT 16 interface Using $PIR table, 8 entries at 0xc00f44e0 pcib0: at pcibus 0 on motherboard pci0: on pcib0 agp0: mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.7 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 pci2: at device 1.0 (no driver attached) pci2: at device 1.1 (no driver attached) pci2: at device 2.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 31.3 (no driver attached) orm0: at iomem 0xc-0xcefff on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x90 on isa0 sio0: type 16550A, console sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (irq) Timecounters tick every 10.000 msec ad0: 38172MB [77557/16/63] at ata0-master UDMA100 ad1: 38166MB [77545/16/63] at ata0-slave UDMA33 acd0: CD-RW <_NEC CD-RW NR-9100A> at ata1-master PIO4 -- ryan beasley<[EMAIL PROTECTED]> GPG ID: 0x16EFBD48 http://www.goddamnbastard.org msg49650/pgp0.pgp Description: PGP signature
Re: current/stable remote gdb interoperability
On Fri, Jan 03, 2003 at 10:19:03AM -0500, Alexander Kabaev wrote:
> I've seen similar erratic behaviour myself when using gdb without -k
> command switch. Can it be your problem too?
Are you saying that you don't see this problem when using the -k flag?
I don't have the -k option at my disposal. I could be wrong, but I
think that the -k extension to GDB is found only in changes made to
whatever's included under src/contrib/gdb, not in the patches for the
ports. (RELENG_4 is still including GDB 4.18, and that can't read the
debugging info in the new 5.0 kernel. That's why I installed a new
version manually. :).)
> Also, you might want to look for sample .gdbinit files for useful gbd
> macros other people are using. These files are in the tree somewhere.
Will do.
Thanks for the reply.
--
ryan beasley<[EMAIL PROTECTED]>
GPG ID: 0x16EFBD48 http://www.goddamnbastard.org
msg49587/pgp0.pgp
Description: PGP signature
current/stable remote gdb interoperability
I'm running -CURRENT from around Dec 28th, 2002, 04:00 -0600, on a testing machine. While debugging a 3rd party module, I occasionally find myself in situations where I can't obtain a core dump. (e.g., a panic related to a lock assertion occurs just before the dump routine begins.) To get around this, I decided I'd use my other RELENG_4_7 box as a remote GDB master. The serial port on the -CURRENT machine is compiled at 38400. FYI, jesper == 4.7R-p2 debugging box, and fredrik == 5.0 panic box. This instance of gdb was compiled from source w/ the patches found in the devel/gdb52 port. (I don't have room for the ports tree locally.) The problem I'm running into is primarily erratic behavior. The trace trap shown below occurs frequently, and while it's only a minor annoyance, my main concern is gdb randomly freezing when attempting to get a backtrace. (Sometimes it'll run to completion, others will hang between frames.) Is this a case of user error? (I've never had a problem w/ serial rates >9600 bps between similarly configured RELENG_4 boxes.) Is cross- release debugging taboo? What do the experts recommend I do? TIA! Session output is included below: ryanb@jesper ~/FREDRIK_DP_INV> gdb52 --baud 38400 GNU gdb 5.2 (FreeBSD) Copyright 2002 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-freebsd4.7". (gdb) target remote /dev/cuaa0 Remote debugging using /dev/cuaa0 0xc02a5aba in ?? () (gdb) add-symbol-file kernel.debug add symbol table from file "kernel.debug" at (y or n) y Reading symbols from kernel.debug...done. (gdb) dir sys Source directories searched: /home/ryanb/FREDRIK_DP_INV/sys:$cdir:$cwd (gdb) dir ipfilter Source directories searched: /home/ryanb/FREDRIK_DP_INV/ipfilter:/home/ryanb/FREDRIK_DP_INV/sys:$cdir:$cwd (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. Debugger (msg=0x19 ) at atomic.h:260 260 atomic.h: No such file or directory. in atomic.h (gdb) bt #0 Debugger (msg=0x19 ) at atomic.h:260 #1 0xc01bc5c7 in witness_lock (lock=0xc1264734, flags=8, file=0xc02d9e6d "/usr/src/sys/kern/kern_descrip.c", line=2108) at /usr/src/sys/kern/subr_witness.c:720 #2 0xc0190441 in _mtx_lock_flags (m=0x0, opts=0, file=0xc1264734 " \0170ÀU\230-ÀU\230-À", line=-1070255508) at /usr/src/sys/kern/kern_mutex.c:328 #3 0xc017eba3 in sysctl_kern_file (oidp=0xc02fdfe0, arg1=0x0, arg2=0, req=0xc5f47c0c) at /usr/src/sys/kern/kern_descrip.c:2108 #4 0xc01a279b in sysctl_root (oidp=0x0, arg1=0xc5f47ca8, arg2=2, req=0xc5f47c0c) at /usr/src/sys/kern/kern_sysctl.c:1150 (Session just dies here.) ryanb@jesper ~> ps auxww | grep gdb ryanb 50317 0.0 5.4 22272 21160 p4 S+7:35AM 0:01.87 gdb52 --baud 38400 Its current wait channel is (surprise!) ttyin. -- ryan beasley<[EMAIL PROTECTED]> GPG ID: 0x16EFBD48 http://www.goddamnbastard.org msg49585/pgp0.pgp Description: PGP signature
witness: could sleep with "dc0" locked
Not sure if this is already known, and I'm not knowledgeable enough to
tell if this is a harmless warning or an indicator of trouble down the
road. (I'm assuming the prior as witness normally has a reason to
complain, right? :).)
Sources from HEAD around 04:15 -0600 today. I noticed the same thing
with RELENG_5_0 sources from about a week ago.
ifconfig is automatically loading the dc(4) and mii(4) modules at boot.
The only other module loaded prior is vesa.ko as specified in
/boot/loader.conf.
Doing initial network setup: hostname.
dc0: port 0xd400-0xd4ff mem 0xfeaffc00-0xfeaffcff irq 9
at device 2.0 on pci2
dc0: Ethernet address: 00:08:a1:2a:2d:29
/usr/src/sys/vm/uma_core.c:1330: could sleep with "dc0" locked from
/usr/src/sys/pci/if_dc.c:691
Debugger("witness_sleep")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db> sh locks
exclusive sleep mutex dc0 (network driver) r = 0 (0xc13987bc) locked @
/usr/src/sys/pci/if_dc.c:691
exclusive sleep mutex Giant r = 0 (0xc03010c0) locked @ /usr/src/sys/vm/vm_object.c:435
db> trace
Debugger(c02cdca4,c02ebfea,532,c02df7e0,c11dc380) at Debugger+0x54
witness_sleep(1,0,c02ebfea,532,c5f47a5c) at witness_sleep+0x123
uma_zalloc_arg(c09d,0,4,c5f47a74,c09d) at uma_zalloc_arg+0x54
malloc(120,c0308de0,4,c136385c,0) at malloc+0x79
if_attach(c1398000,c09e8d00,c1398000,c1398000,c11d8080) at if_attach+0x23c
ether_ifattach(c1398000,c5f47b5c,c1362a10,c1362a80,) at ether_ifattach+0x22
dc_attach(c09e8d00,c139a098,c02f7a74,c018e9b6,c0303664) at dc_attach+0xf4f
device_probe_and_attach(c09e8d00,c11d8080,c02f7a6c,c11910c0,c11d8080) at
device_probe_and_attach+0xb0
bus_generic_driver_added(c11d8080,c1364ce8,c02f7ac4,c1364ce8,c1364d98) at
bus_generic_driver_added+0x6e
devclass_add_driver(c09d7e80,c1364ce8,c02dcd8e,c09d7e80,c12880c0) at
devclass_add_driver+0xe7
driver_module_handler(c12880c0,0,c1364d98,c5f47c54,c02da9b3) at
driver_module_handler+0x85
module_register_init(c1364db0,c02da9b3,c5f47c54,c5f47c58,0) at
module_register_init+0x81
linker_file_sysinit(c1264b00,c117dac0,c5f47c80,c117dac0,1) at linker_file_sysinit+0xa0
linker_load_file(c117dac0,c5f47ca4,0,c5f47cb4,0) at linker_load_file+0x10b
linker_load_module(0,c11d9800,0,0,c5f47cd0) at linker_load_module+0xd7
kldload(c09ec2a0,c5f47d10,c02efab9,407,1) at kldload+0x114
syscall(2f,2f,2f,bfbffdc8,0) at syscall+0x28e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (304, FreeBSD ELF32, kldload), eip = 0x804f913, esp = 0xbfbffc7c, eb
p = 0xbfbffcf8 ---
--
ryan beasley<[EMAIL PROTECTED]>
GPG ID: 0x16EFBD48 http://www.goddamnbastard.org
msg49482/pgp0.pgp
Description: PGP signature
panic: lockmgr: draining against myself
7698 -8 0 00 g_up DL??0:00.01 (g_up) 0 4 0 327698 -8 0 00 g_down DL??0:00.03 (g_down) 0 5 0 327698 -84 0 00 actask DL??0:00.00 (acpi_task0) 0 6 0 327698 -84 0 00 actask DL??0:00.00 (acpi_task1) 0 7 0 327698 -84 0 00 actask DL??0:00.00 (acpi_task2) 0 8 0 327698 -16 0 00 psleep DL??0:00.00 (pagedaemon) 0 9 0 327698 20 0 00 psleep DL??0:00.00 (vmdaemon) 010 0 327698 -16 0 00 ktrace DL??0:00.00 (ktrace) 011 0 327698 -16 0 00 - RL??1:26.81 (idle) 012 0 327698 -48 0 00 - WL??0:00.08 (swi6: tty:sio clock) 013 0 327698 -32 0 00 - RL??0:00.00 (swi4: vm) 014 0 327698 -44 0 00 - WL??0:00.00 (swi1: net) 015 0 327698 76 0 00 sleep DL??0:00.00 (random) 016 0 327698 -28 0 00 - WL??0:00.00 (swi5: acpitaskq) 017 0 327698 -28 0 00 - RL??0:00.00 (swi5: task queue) 018 0 327698 -21 0 00 - RL??0:00.00 (irq13:) 019 0 327698 -68 0 00 - WL??0:00.00 (irq9: dc0 acpi0) 020 0 327698 -64 0 00 - WL??0:00.02 (irq14: ata0) 021 0 327698 -64 0 00 - WL??0:00.00 (irq15: ata1) 022 0 327698 -48 0 00 - RL??0:00.00 (swi0: tty:sio) 023 0 327698 -60 0 00 - RL??0:00.00 (irq4: sio0) 024 0 327698 -64 0 00 - WL??0:00.00 (irq6: fdc0) 025 0 327698 -60 0 00 - WL??0:00.02 (irq1: atkbd0) 026 0 327698 -60 0 00 - RL??0:00.00 (irq12: psm0) 027 0 327698 -84 0 00 - RL??0:00.00 (irq0: clk) 028 0 327698 -84 0 00 - RL??0:00.00 (irq8: rtc) 029 0 327698 171 0 00 pgzero DL??0:00.08 (pagezero) 030 0 327698 -16 0 00 psleep DL??0:00.00 (bufdaemon) 031 0 327698 -4 0 00 vlruwt DL??0:00.00 (vnlru) 032 0 327698 20 0 00 syncer DL??0:00.00 (syncer) 033 0 327698 8 0 00 nfsidl DL??0:00.00 (nfsiod 0) 034 0 327698 8 0 00 nfsidl DL??0:00.00 (nfsiod 1) 035 0 327698 8 0 00 nfsidl DL??0:00.00 (nfsiod 2) 036 0 327698 8 0 00 nfsidl DL??0:00.00 (nfsiod 3) 0 119 1 327698 20 0 2200 pause Ds??0:00.00 (adjkerntz) 0 184 1 327698 96 0 11600 select Ds??0:00.00 (dhclient) -- ryan beasley<[EMAIL PROTECTED]> GPG ID: 0x16EFBD48 http://www.goddamnbastard.org msg49382/pgp0.pgp Description: PGP signature
Re: CNet Pro200WL (Davicom DM9102A): fine under 4.6.2-p2, no worky under -CURRENT
On Sat, Oct 12, 2002 at 04:12:02AM -0500, ryan beasley wrote: > was loaded / probed the card? (FWIW, I'm not seeing any significant > changes to dc_setfilt_21143() between revs 1.9.2.33 and 1.81...) Er, I meant dc_attach. Rilly. Trust me. ;) ( I think I initially guessed there from the 'set our mac address' comment without taking *any* of the surrounding code into context. ) I skimmed over a portion of the DM9102A data sheet, saw the SROM layout, and modified this driver to grab the MAC from that space. It's worked fine ever since. (I sent a pr this morning with said patch, and while my mail logs show the message as having been received as msgID B63E843E3B, it hasn't shown up anywhere.) Thoughts? -- ryan beasley<[EMAIL PROTECTED]> GPG ID: 0x16EFBD48 http://www.goddamnbastard.org # made against if_dcreg.h 1.27 and if_dc.c 1.81 --- sys/pci/if_dcreg.h.orig Tue Oct 15 07:44:12 2002 +++ sys/pci/if_dcreg.h Tue Oct 15 07:42:37 2002 @@ -856,6 +856,11 @@ #define DC_REVISION_DM9102A0x30 /* + * DM9102A MAC address SROM offset. + */ +#defineDC_DM9102_NODEADDR 0x14 + +/* * ADMtek vendor ID. */ #define DC_VENDORID_ADMTEK 0x1317 --- sys/pci/if_dc.c.origTue Oct 15 07:44:08 2002 +++ sys/pci/if_dc.c Tue Oct 15 07:42:29 2002 @@ -1995,6 +1995,9 @@ command &= 0x00FF; command |= 0x8000; pci_write_config(dev, DC_PCI_CFLT, command, 4); + /* See above. ;) */ + dc_eeprom_width(sc); + dc_read_srom(sc, sc->dc_romwidth); break; case DC_DEVICEID_AL981: sc->dc_type = DC_TYPE_AL981; @@ -2142,6 +2145,9 @@ dc_read_eeprom(sc, (caddr_t)&eaddr, 0, 3, 1); break; case DC_TYPE_DM9102: + bcopy(&sc->dc_srom[DC_DM9102_NODEADDR], (caddr_t)&eaddr, + ETHER_ADDR_LEN); + break; case DC_TYPE_21143: case DC_TYPE_ASIX: dc_read_eeprom(sc, (caddr_t)&eaddr, DC_EE_NODEADDR, 3, 0); msg44737/pgp0.pgp Description: PGP signature
Re: CNet Pro200WL (Davicom DM9102A): fine under 4.6.2-p2, no worky under -CURRENT
On Fri, Oct 11, 2002 at 08:44:37PM -0500, ryan beasley wrote: > > I'm attaching dmesg and pciconf output to this message. Please let me > know what (if any) further information is required. > Hm... just noticed a strange MAC reported in ifconfig output under -CURRENT. dc0: flags=8802 mtu 1500 ether 15:01:15:01:15:01 I rebooted to 4.6.2-p2, copied down the probed MAC, then returned to -CURRENT and applied said MAC. Suddenly the card is working. Soo... anyone have any idea why the correct MAC wasn't pulled when the driver was loaded / probed the card? (FWIW, I'm not seeing any significant changes to dc_setfilt_21143() between revs 1.9.2.33 and 1.81...) Any help is appreciated. -- ryan beasley<[EMAIL PROTECTED]> GPG ID: 0x16EFBD48 http://www.goddamnbastard.org msg45243/pgp0.pgp Description: PGP signature
CNet Pro200WL (Davicom DM9102A): fine under 4.6.2-p2, no worky under -CURRENT
Herro -CURRENT! I have a Dell Dimension 4500 that included a CNet Pro200WL adapter. I have 4.6.2-p2 installed on one partition and -CURRENT from earlier today on another. 4.6.2-p2 has no problem with this card, and while it's detected under -CURRENT, I can't seem to, well, make it work. I've attempted to force media types and suboptions to no avail (as opposed to autoselect). tcpdump in promiscuous mode shows only ARP requests when this machine tries to reach another on the subnet. Other machines never see any segments generated by this one, and 'netstat -i' shows no input / output errors. For what it's worth, the following message is broadcast to my console when trying to configure the interface: dc0: failed to force tx and rx to idle state I'm attaching dmesg and pciconf output to this message. Please let me know what (if any) further information is required. TIA! -- ryan beasley<[EMAIL PROTECTED]> GPG ID: 0x16EFBD48 http://www.goddamnbastard.org # /var/run/dmesg.boot Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #3: Fri Oct 11 19:54:38 CDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FREDRIK_DP Preloaded elf kernel "/boot/kernel/kernel" at 0xc03cd000. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 2392297388 Hz CPU: Pentium 4 (2392.30-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff real memory = 536084480 (523520K bytes) avail memory = 516149248 (504052K bytes) Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface Using $PIR table, 8 entries at 0xc00f44e0 pcib0: at pcibus 0 on motherboard pci0: on pcib0 agp0: mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.7 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 pci2: at device 1.0 (no driver attached) pci2: at device 1.1 (no driver attached) dc0: port 0xd400-0xd4ff mem 0xfeaffc00-0xfeaffcff irq 9 at device 2.0 on pci2 dc0: Ethernet address: 15:01:15:01:15:01 miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 31.3 (no driver attached) orm0: at iomem 0xc-0xcefff on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 psm0: irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (irq) Timecounters tick every 10.000 msec Initializing GEOMetry subsystem ad0: 38172MB [77557/16/63] at ata0-master UDMA100 ad1: 38166MB [77545/16/63] at ata0-slave UDMA33 acd0: CD-RW <_NEC CD-RW NR-9100A> at ata1-master PIO4 Mounting root from ufs:/dev/ad1s2a # pciconf -l agp0@pci0:0:0: class=0x06 card=0x1a308086 chip=0x1a308086 rev=0x11 hdr=0x00 pcib1@pci0:1:0: class=0x060400 card=0x chip=0x1a318086 rev=0x11 hdr=0x01 none0@pci0:29:0:class=0x0c0300 card=0x01321028 chip=0x24c28086 rev=0x01 hdr=0x00 none1@pci0:29:1:class=0x0c0300 card=0x01321028 chip=0x24c48086 rev=0x01 hdr=0x00 none2@pci0:29:2:class=0x0c0300 card=0x01321028 chip=0x24c78086 rev=0x01 hdr=0x00 none3@pci0:29:7:class=0x0c0320 card=0x01321028 chip=0x24cd8086 rev=0x01 hdr=0x00 pcib2@pci0:30:0:class=0x060400 card=0x chip=0x244e8086 rev=0x81 hdr=0x01 isab0@pci0:31:0:class=0x060100 card=0x chip=0x24c08086 rev=0x01 hdr=0x00 atapci0@pci0:31:1: class=0x01018a card=0x01321028 chip=0x24cb8086 rev=0x01 hdr=0x00 none4@pci0:31:3:class=0x0c0500 card=0x01321028 chip=0x24c38086 rev=0x01 hdr=0x00 none5@pci1:0:0: class=0x03 c
