Date: Sun, 29 Sep 2002 16:16:44 -0700 From: Bill Fenner <fenner@research.att.com> To: stable@freebsd.org Subject: 4.7-RC: panic: resource_list_alloc: resource entry is busy in sound code on resume from sleep Message-ID: <200209292316.QAA03694@windsor.research.att.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200209292316.QAA03694>