Most recent kernel where this bug did not occur: 2.6.13.5 Distribution: Debian etch Hardware Environment: CPU: P4 3.0GHz MB: Gigabyte GA-8I915P Pro (Rev 1.x) North: i915P, South: ICH6. VGA: Leadtek WinFast PX6600 TD PCI-E (NVIDIA GeForce 6600) NIC: Broadcom 5751 SND: C-Media 9880 CODEC (UAJ) (driver: snd_hda_intel) Software Environment: Xorg 7.1.0, GNOME 2.14.3.6 Problem Description: Shutdown hangs after acpi_power_off called only if sounds outputed before. No matter whether X/GNOME runs or not, if no sounds output from my speaker until shutdown, things will be fine. The problem is similar to bug 6431 but I have no sky2 drive installed. Steps to reproduce: 1. cat something.wav > /dev/dsp 2. shutdown -h now 3. acpi_power_off called (power isn't off.)
Created attachment 12486 [details] logs start from boot to shutdown logs start from boot to shutdown, with kernel param acpi.debug_level=0xFFFFFFFF & acpi.debug_layer=0xFFFFFFFF.
Created attachment 12487 [details] kernel configuration
Created attachment 12488 [details] dsdt.dsl My dsdt.dsl.
please attach the complete output from acpidump please try reproducing the problem with "pnpacpi=off"
> did not occur: 2.6.13.5 Can you attach the dmesg from this successful configuration? > 2.6.22.4 Can you isolate in which release this first broke?
Created attachment 12524 [details] acpidump output (In reply to comment #4) > please attach the complete output from acpidump > > please try reproducing the problem with "pnpacpi=off" > yes I can reproduce it with "pnpacpi=off" and the problem is still there.
Created attachment 12525 [details] dmesg of 2.6.13.5 Since the debug messages are too verbose that I can't completely capture it at boot time, I enabled debug parameters after login.
Created attachment 12526 [details] dmesg of 2.6.14 (In reply to comment #5) > > 2.6.22.4 > > Can you isolate in which release this first broke? v2.6.14
Hangs like this are typically because we've done something, maybe something unrelated, that confuses the BIOS. Is it possible to git-bisect which change between 2.6.13 and 2.6.14 caused this to break?
(In reply to comment #9) > Hangs like this are typically because we've done something, > maybe something unrelated, that confuses the BIOS. > > Is it possible to git-bisect which change between > 2.6.13 and 2.6.14 caused this to break? > 0be3b5d3fb94c36c517655d18a936681d7108667 is first bad commit commit 0be3b5d3fb94c36c517655d18a936681d7108667 Author: Takashi Iwai <tiwai@suse.de> Date: Mon Sep 5 17:11:40 2005 +0200 [ALSA] hda-intel - Check validity of DMA position HDA Intel driver Check the validity of the current DMA position when position_fix=0 (auto) is set. If the DMA position overcomes the threshold, the driver changes the fix behavior automatically to use POSBUF. Signed-off-by: Takashi Iwai <tiwai@suse.de> :040000 040000 4c9f3762f5863d9b11ac009a162f8793083f9de7 a650ce2de5036b5880b6c25df730c8c22a330906 M sound Thanks.
Has this problem been fixed, or it is still there? Thanks.
It looks like several commits from Takashi has been done to fix this problem, and I believe the bug was fixed. Please reopen if problem persists.