Bug 8922
Summary: | 2.6.14 regression - Shutdown hangs after acpi_power_off called only if sounds outputed before. | ||
---|---|---|---|
Product: | Drivers | Reporter: | Wei-li Tang (s3321037) |
Component: | Sound(ALSA) | Assignee: | Takashi Iwai (tiwai) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | acpi-bugzilla, protasnb, tiwai |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.22.4 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: |
logs start from boot to shutdown
kernel configuration dsdt.dsl acpidump output dmesg of 2.6.13.5 dmesg of 2.6.14 |
Description
Wei-li Tang
2007-08-22 08:13:25 UTC
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. |