lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 11 Feb 2011 20:58:49 +0800
From:	Wang Lei <f3d27b@...il.com>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	linux-kernel@...r.kernel.org, Jaroslav Kysela <perex@...ex.cz>
Subject: Re: [SOUND] SBx00 sound card using snd_hda_codec_analog auto mutes

Takashi Iwai <tiwai@...e.de> writes:

> At Fri, 11 Feb 2011 20:23:21 +0800,
> Wang Lei wrote:
>> 
>> Thanks for your reply!
>> 
>> Takashi Iwai <tiwai@...e.de> writes:
>> 
>> > At Thu, 10 Feb 2011 20:49:51 +0800,
>> > Wang Lei wrote:
>> >> 
>> >> On my laptop, the sound card auto mutes some seconds after i enable it.
>> >> And play a audio file can't make sound. This is not a powersave feature,
>> >> because i haven't enable it. I guess it's a driver problem. It occurs
>> >> since 2.6.36.X. Please help.
>> >
>> > Then a possible cause would be the badly working interrupts.
>> > Or, I remember vaguely some reports mentioning conflicts with radeon
>> > driver.
>> >
>> > Anyway, try to reproduce without the graphic interface first.
>> >
>> 
>> I have reproduced it without the graphic interface.
>> 
>> > Also, try to pass enable_msi=0 or 1.  AMD controllers tend to unstable
>> > regarding MSI.
>> >
>> 
>> And pass enable_msi=0 or 1 to snd_hda_intel, or even add boot parameter
>> pci=nomsi (i actually don't know whether this is reasonable), the
>> problem occurs.
>> 
>> I have forgot to mention this, when passing apci=off to the boot kernel,
>> there is no this problem.
>
> Then check whether the interrupt is properly generated during PCM
> playback by watching /proc/interrupts.  If not, it's likely an ACPI or
> BIOS problem.
>

I hope i did the right thing. I `cat /proc/interrupts > 1', then use
alsamixer increase the PCM channel, then `cat /proc/interrupts >2'.

This is the diff output:
--------------------
[~]$ diff -u 1 2
--- 1	2011-02-11 20:54:29.205759305 +0800
+++ 2	2011-02-11 20:54:35.912611712 +0800
@@ -1,21 +1,21 @@
            CPU0       CPU1       
-  0:      11355    9074412   IO-APIC-edge      timer
-  1:         28       7111   IO-APIC-edge      i8042
+  0:      11355    9081104   IO-APIC-edge      timer
+  1:         28       7141   IO-APIC-edge      i8042
   7:          1          0   IO-APIC-edge    
   8:          0          0   IO-APIC-edge      rtc0
   9:          1         49   IO-APIC-fasteoi   acpi
  12:       4193    1186548   IO-APIC-edge      i8042
  14:          1         52   IO-APIC-edge      pata_atiixp
  15:          0          0   IO-APIC-edge      pata_atiixp
- 16:        760     271833   IO-APIC-fasteoi   ahci, hda_intel
+ 16:        760     271846   IO-APIC-fasteoi   ahci, hda_intel
  17:        344      84956   IO-APIC-fasteoi   ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6
  23:          1          7   IO-APIC-fasteoi   ehci_hcd:usb1, ohci_hcd:usb2
 NMI:          0          0   Non-maskable interrupts
-LOC:    9074392      11170   Local timer interrupts
+LOC:    9081084      11170   Local timer interrupts
 SPU:          0          0   Spurious interrupts
 PMI:          0          0   Performance monitoring interrupts
 IWI:          0          0   IRQ work interrupts
-RES:     833684     997760   Rescheduling interrupts
+RES:     834075     998023   Rescheduling interrupts
 CAL:         16          6   Function call interrupts
 TLB:      21213      18762   TLB shootdowns
 THR:          0          0   Threshold APIC interrupts
[~]$
--------------------

>
> Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ