Bug 8922 - 2.6.14 regression - Shutdown hangs after acpi_power_off called only if sounds outputed before.
Summary: 2.6.14 regression - Shutdown hangs after acpi_power_off called only if sounds...
Status: CLOSED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Takashi Iwai
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-22 08:13 UTC by Wei-li Tang
Modified: 2008-02-07 00:32 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.22.4
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
logs start from boot to shutdown (41.74 KB, application/x-gzip)
2007-08-22 08:15 UTC, Wei-li Tang
Details
kernel configuration (78.67 KB, text/plain)
2007-08-22 08:16 UTC, Wei-li Tang
Details
dsdt.dsl (149.42 KB, text/plain)
2007-08-22 08:18 UTC, Wei-li Tang
Details
acpidump output (47 bytes, text/plain)
2007-08-25 00:24 UTC, Wei-li Tang
Details
dmesg of 2.6.13.5 (99.44 KB, application/x-gzip)
2007-08-25 00:29 UTC, Wei-li Tang
Details
dmesg of 2.6.14 (54.33 KB, application/x-gzip)
2007-08-25 00:31 UTC, Wei-li Tang
Details

Description Wei-li Tang 2007-08-22 08:13:25 UTC
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.)
Comment 1 Wei-li Tang 2007-08-22 08:15:21 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.
Comment 2 Wei-li Tang 2007-08-22 08:16:08 UTC
Created attachment 12487 [details]
kernel configuration
Comment 3 Wei-li Tang 2007-08-22 08:18:22 UTC
Created attachment 12488 [details]
dsdt.dsl

My dsdt.dsl.
Comment 4 Len Brown 2007-08-24 00:56:24 UTC
please attach the complete output from acpidump

please try reproducing the problem with "pnpacpi=off"
Comment 5 Len Brown 2007-08-24 00:58:43 UTC
> 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?
Comment 6 Wei-li Tang 2007-08-25 00:24:21 UTC
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.
Comment 7 Wei-li Tang 2007-08-25 00:29:56 UTC
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.
Comment 8 Wei-li Tang 2007-08-25 00:31:47 UTC
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
Comment 9 Len Brown 2007-08-25 00:52:17 UTC
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?
Comment 10 Wei-li Tang 2007-08-26 00:26:37 UTC
(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.
Comment 11 Natalie Protasevich 2007-11-08 05:34:23 UTC
Has this problem been fixed, or it is still there?
Thanks.
Comment 12 Natalie Protasevich 2008-02-07 00:32:20 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.