Re: pcm remaining problem (possible ACPI too)
Hi, Since rescent -CURRENT is stable enough, I have the chance to find out remaining pcm problem. My MP box no more has double fatal fault and turns into random sleep. The random sleep happens after pcm having its own problem. uname -av is FreeBSD cartier.home 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Wed Dec 4 23:07:36 CST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERI i386 Kernel config is simply a modified GENERIC, with options SMP, APIC_IO, and ident GENERI. Below is what I've got in my dmesg. Complete dmesg is at http://fatpipi.cirx.org/~clive/cartier_dmesg.txt lock order reversal 1st 0xc6992900 pipe mutex (pipe mutex) @ /usr/src/sys/kern/sys_pipe.c:465 2nd 0xc0524600 sigio lock (sigio lock) @ /usr/src/sys/kern/kern_sig.c:2225 acquiring duplicate lock of same type: pcm channel 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 wakeup from sleeping state (slept 00:02:06) ata0: resetting devices .. done I think the real problem is in pcm on MP system as you said, IRQ 9 maybe shared with pcm0 and acpi. Could you show me this? # acpidump | grep SCI_INT Also, I'd like to see which acpi event was occured on ramdom sleep. Backtrace is helpful to track this down. Press Ctrl+Alt+Esc into DDB, enter db b acpi_SetSleepState to set break point, then send me the output of db t when the ramdom sleep is occurred. BTW, you can set ignoring some of acpi events like this: # sysctl hw.acpi.power_button_state=NONE # sysctl hw.acpi.sleep_button_state=NONE # sysctl hw.acpi.lid_switch_state=NONE acpi0: RCCRCCNILE on motherboard # I worry about this... :P Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pcm remaining problem (possible ACPI too)
Hi, Since rescent -CURRENT is stable enough, I have the chance to find out remaining pcm problem. My MP box no more has double fatal fault and turns into random sleep. The random sleep happens after pcm having its own problem. uname -av is FreeBSD cartier.home 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Wed Dec 4 23:07:36 CST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERI i386 Kernel config is simply a modified GENERIC, with options SMP, APIC_IO, and ident GENERI. Below is what I've got in my dmesg. Complete dmesg is at http://fatpipi.cirx.org/~clive/cartier_dmesg.txt lock order reversal 1st 0xc6992900 pipe mutex (pipe mutex) @ /usr/src/sys/kern/sys_pipe.c:465 2nd 0xc0524600 sigio lock (sigio lock) @ /usr/src/sys/kern/kern_sig.c:2225 acquiring duplicate lock of same type: pcm channel 1st pcm0:record:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 2nd pcm0:play:0 @ /usr/src/sys/dev/sound/pcm/sound.c:191 wakeup from sleeping state (slept 00:02:06) ata0: resetting devices .. done ata1: resetting devices .. done psmintr: delay too long; resetting byte count wakeup from sleeping state (slept 00:00:40) ata0: resetting devices .. done ata1: resetting devices .. done wakeup from sleeping state (slept 00:03:49) ata0: resetting devices .. done ata1: resetting devices .. done wakeup from sleeping state (slept 00:03:05) ata0: resetting devices .. done ata1: resetting devices .. done To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pcm remaining problem (possible ACPI too)
On Sat, Dec 07, 2002 at 01:00:44AM +0800, Clive Lin wrote: Hi, Since rescent -CURRENT is stable enough, I have the chance to find out remaining pcm problem. My MP box no more has double fatal fault and turns into random sleep. The random sleep happens after pcm having its own problem. [deleted] I updated my -CURRENT, with uname -av below: FreeBSD cartier.home 5.0-RC FreeBSD 5.0-RC #0: Sat Dec 7 02:40:46 CST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERI i386 This does not help anything. But, if I disable ACPI in BIOS, everything is fine. No more sleep. The dmesg output without ACPI is at: http://fatpipi.cirx.org/~clive/cartier_dmesg_no_ACPI.txt Clive To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
