From owner-freebsd-stable Sun Sep 29 16:17:15 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6791A37B401 for ; Sun, 29 Sep 2002 16:17:12 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75E4343E4A for ; Sun, 29 Sep 2002 16:17:11 -0700 (PDT) (envelope-from fenner@research.att.com) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 82CFF1E10C for ; Sun, 29 Sep 2002 19:16:45 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id TAA25408 for ; Sun, 29 Sep 2002 19:16:44 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id QAA03694; Sun, 29 Sep 2002 16:16:45 -0700 (PDT) Message-Id: <200209292316.QAA03694@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: stable@freebsd.org Subject: 4.7-RC: panic: resource_list_alloc: resource entry is busy in sound code on resume from sleep Date: Sun, 29 Sep 2002 16:16:44 -0700 Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have an IBM Thinkpad T21. Sound has never worked properly in 4.6-RELEASE or 4.6-STABLE after resuming from sleep; however, now the kernel panics on resuming from sleep. The panic is: panic: resource_list_alloc: resource entry is busy Then after this panic, I get a fatal trap 12. gdb lies some in the trace (it shows poweroff_wait() instead of panic(), dunno what else is wrong) and the variables are wrong (too far up in the stack?) so I haven't been able to debug. It only happens when in X, so I can't debug with ddb. It's on my TODO list to hook up a serial console and use remote gdb, but I haven't gotten around to that yet. The trace is appended; the kernel and (afaict, useless) core are available if anyone wants. Bill panic: resource_list_alloc: resource entry is busy syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc030ec50 stack pointer = 0x10:0xc0429570 frame pointer = 0x10:0xc0429578 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = bio trap number = 12 panic: page fault Uptime: 1m12s dumping to dev #ad/0x30001, offset 786560 dump ata0: resetting devices .. done 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 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 --- 0xc030ec50 looks like acquire_lock(). (Yup, look at frame #6). The original panic occurred in frame #14. Remember that gdb is smoking something and reports panic() as poweroff_wait(). #0 dumpsys () at ../../kern/kern_shutdown.c:487 #1 0xc020b747 in boot (howto=260) at ../../kern/kern_shutdown.c:316 #2 0xc020bb6c in poweroff_wait (junk=0xc042034c, howto=-1069416849) at ../../kern/kern_shutdown.c:595 #3 0xc03a1c7e in trap_fatal (frame=0xc0429530, eva=48) at ../../i386/i386/trap.c:974 #4 0xc03a1951 in trap_pfault (frame=0xc0429530, usermode=0, eva=48) at ../../i386/i386/trap.c:867 #5 0xc03a150f in trap (frame={tf_fs = -1071448048, tf_es = 4194320, tf_ds = -1069416432, tf_edi = 0, tf_esi = -1056310272, tf_ebp = -1069378184, tf_isp = -1069378212, tf_ebx = -1069161060, tf_edx = 6867008, tf_ecx = -918483648, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1070535600, tf_cs = 8, tf_eflags = 66050, tf_esp = -1056310272, tf_ss = -1056310272}) at ../../i386/i386/trap.c:466 #6 0xc030ec50 in acquire_lock (lk=0xc045e59c) at ../../ufs/ffs/ffs_softdep.c:266 #7 0xc0312d50 in softdep_update_inodeblock (ip=0xc109fc00, bp=0xc37c3298, waitfor=0) at ../../ufs/ffs/ffs_softdep.c:3813 #8 0xc030dd85 in ffs_update (vp=0xc9410d40, waitfor=0) at ../../ufs/ffs/ffs_inode.c:106 #9 0xc031777d in ffs_fsync (ap=0xc0429624) at ../../ufs/ffs/ffs_vnops.c:273 #10 0xc031605b in ffs_sync (mp=0xc100e000, waitfor=2, cred=0xc0b31600, p=0xc04c44c0) at vnode_if.h:558 #11 0xc023b537 in sync (p=0xc04c44c0, uap=0x0) at ../../kern/vfs_syscalls.c:576 #12 0xc020b4e2 in boot (howto=256) at ../../kern/kern_shutdown.c:235 #13 0xc020bb6c in poweroff_wait (junk=0xc03efc20, howto=-1057332984) at ../../kern/kern_shutdown.c:595 #14 0xc02141ac in resource_list_alloc (rl=0xc0fa6104, bus=0xc0fa6780, child=0xc0fa6080, type=3, rid=0xc0fa9684, start=0, end=4294967295, count=1, flags=2) at ../../kern/subr_bus.c:1800 #15 0xc030706f in pci_alloc_resource (dev=0xc0fa6780, child=0xc0fa6080, type=3, rid=0xc0fa9684, start=0, end=4294967295, count=1, flags=2) at ../../pci/pci.c:1661 #16 0xc0135ca3 in BUS_ALLOC_RESOURCE (dev=0xc0fa6780, child=0xc0fa6080, type=3, rid=0xc0fa9684, start=0, end=4294967295, count=1, flags=2) at bus_if.c:114 #17 0xc02145fb in bus_alloc_resource (dev=0xc0fa6080, type=3, rid=0xc0fa9684, start=0, end=4294967295, count=1, flags=2) at ../../kern/subr_bus.c:2085 #18 0xc035339d in csa_attach (dev=0xc0fa6080) at ../../dev/sound/pci/csa.c:262 #19 0xc03535f3 in csa_resume (dev=0xc0fa6080) at ../../dev/sound/pci/csa.c:367 #20 0xc0135ad2 in DEVICE_RESUME (dev=0xc0fa6080) at device_if.c:105 #21 0xc02143da in bus_generic_resume (dev=0xc0fa6780) at ../../kern/subr_bus.c:1936 #22 0xc0135ad2 in DEVICE_RESUME (dev=0xc0fa6780) at device_if.c:105 #23 0xc02143da in bus_generic_resume (dev=0xc0fa6900) at ../../kern/subr_bus.c:1936 #24 0xc0135ad2 in DEVICE_RESUME (dev=0xc0fa6900) at device_if.c:105 #25 0xc02143da in bus_generic_resume (dev=0xc0fa6a80) at ../../kern/subr_bus.c:1936 #26 0xc0135ad2 in DEVICE_RESUME (dev=0xc0fa6a80) at device_if.c:105 #27 0xc02143da in bus_generic_resume (dev=0xc0b31580) at ../../kern/subr_bus.c:1936 #28 0xc0135ad2 in DEVICE_RESUME (dev=0xc0b31580) at device_if.c:105 #29 0xc03906d7 in apm_resume () at ../../i386/apm/apm.c:605 #30 0xc0390d90 in apm_processevent () at ../../i386/apm/apm.c:989 #31 0xc0390562 in apm_do_suspend () at ../../i386/apm/apm.c:490 #32 0xc0390919 in apm_timeout (dummy=0x0) at ../../i386/apm/apm.c:747 #33 0xc0211655 in softclock () at ../../kern/kern_timeout.c:131 #34 0xc0394403 in doreti_swi () To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message