[alsa-devel] No recording on hda-intel (AD1981HD)
Hi. I have a problem with recording on HP nx6325 laptop with hda-intel (AD1981HD codec). The problem is described in [1], and [2], but nobody can help there, so I write here (maybe more developers reads mailing-list ;)).
Problem is that arecord, audacity or skype stops recording after 5-10 min. Unloading and loading modules helps, but only for another 5-10 min. What info do you need to debug the problem ?
PS. HG version differs only three patches (not related to the bug) from 1.0.16rc2, so I didn't try HG.
References:
[1] https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2449 [2] https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3542 [3] http://www.analog.com/en/prod/0,2877,AD1981HD,00.html (codec data sheet)
Here is output from lspci:
################# BEGIN ################################## 00:14.2 Audio device: ATI Technologies Inc SB450 HDA Audio (rev 01) Subsystem: Unknown device 30b0:103c Flags: bus master, slow devsel, latency 64, IRQ 16 Memory at 88000000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- ################ END #####################################
Here is output from cat /proc/asound/card0/codec#0:
################# BEGIN ##################################
Codec: Analog Devices AD1981 Address: 0 Vendor Id: 0x11d41981 Subsystem Id: 0x103c30b0 Revision Id: 0x100200 No Modem Function Group found Default PCM: rates [0x7f]: 8000 11025 16000 22050 32000 44100 48000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Default Amp-Out caps: ofs=0x3d, nsteps=0x3f, stepsize=0x05, mute=1 GPIO: io=4, o=0, i=0, unsolicited=1, wake=0 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=1 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=1 IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0 IO[3]: enable=0, dir=0, wake=0, sticky=0, data=1 Node 0x02 [Audio Output] wcaps 0x30311: Stereo Digital Converter: stream=0, channel=0 Digital: Digital category: 0x0 PCM: rates [0x60]: 44100 48000 bits [0x2]: 16 formats [0x5]: PCM AC3 Delay: 3 samples Connection: 2 0x01* 0x04 Node 0x03 [Audio Output] wcaps 0x441: Stereo Converter: stream=5, channel=0 Power: setting=D0, actual=D0 Processing caps: benign=1, ncoeff=70 Node 0x04 [Audio Input] wcaps 0x100511: Stereo Converter: stream=0, channel=0 SDI-Select: 0 PCM: rates [0x7f]: 8000 11025 16000 22050 32000 44100 48000 bits [0x6]: 16 20 formats [0x1]: PCM Power: setting=D0, actual=D0 Connection: 1 0x15 Node 0x05 [Pin Complex] wcaps 0x400187: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] [0x00 0x00] Amp-Out caps: ofs=0x3d, nsteps=0x3f, stepsize=0x05, mute=1 Amp-Out vals: [0x38 0x38] Pincap 0x081173f: IN OUT HP EAPD Detect Trigger ImpSense Vref caps: HIZ 50 GRD 80 EAPD 0x2: EAPD Pin Default 0x92174110: [Fixed] Speaker at Int Front Conn = Analog, Color = Green DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT VREF_HIZ Unsolicited: tag=00, enabled=0 Connection: 2 0x03 0x0e* Node 0x06 [Pin Complex] wcaps 0x400185: Stereo Amp-Out Amp-Out caps: ofs=0x3d, nsteps=0x3f, stepsize=0x05, mute=1 Amp-Out vals: [0x38 0x38] Pincap 0x081f: OUT HP Detect Trigger ImpSense Pin Default 0x0421201f: [Jack] HP Out at Ext Right Conn = 1/8, Color = Grey DefAssociation = 0x1, Sequence = 0xf Pin-ctls: 0xc0: OUT HP Unsolicited: tag=37, enabled=1 Connection: 2 0x03 0x0e* Node 0x07 [Pin Complex] wcaps 0x400104: Mono Amp-Out Amp-Out caps: ofs=0x3d, nsteps=0x3f, stepsize=0x05, mute=1 Amp-Out vals: [0x80] Pincap 0x0810: OUT Pin Default 0x410710f0: [N/A] Line Out at Ext Rear Conn = Analog, Color = Black DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x40: OUT Connection: 1 0x0f Node 0x08 [Pin Complex] wcaps 0x400083: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: Pincap 0x081727: IN Detect Trigger ImpSense Vref caps: HIZ 50 GRD 80 Pin Default 0x04a12020: [Jack] Mic at Ext Right Conn = 1/8, Color = Grey DefAssociation = 0x2, Sequence = 0x0 Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=38, enabled=1 Node 0x09 [Pin Complex] wcaps 0x400187: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] [0x00 0x00] Amp-Out caps: ofs=0x3d, nsteps=0x3f, stepsize=0x05, mute=1 Amp-Out vals: [0xbf 0xbf] Pincap 0x081737: IN OUT Detect Trigger ImpSense Vref caps: HIZ 50 GRD 80 Pin Default 0x0181302e: [Jack] Line In at Ext Rear Conn = 1/8, Color = Blue DefAssociation = 0x2, Sequence = 0xe Pin-ctls: 0x20: IN VREF_HIZ Unsolicited: tag=00, enabled=0 Connection: 2 0x03* 0x0e Node 0x0a [Pin Complex] wcaps 0x400301: Stereo Digital Pincap 0x0810: OUT Pin Default 0x4145f0f0: [N/A] SPDIF Out at Ext Rear Conn = Optical, Color = Other DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x40: OUT Connection: 1 0x02 Node 0x0b [Audio Selector] wcaps 0x300101: Stereo Connection: 6 0x03 0x0c 0x09 0x0e* 0x05 0x18 Node 0x0c [Audio Mixer] wcaps 0x200101: Stereo Connection: 2 0x1e 0x1f Node 0x0d [Audio Selector] wcaps 0x30010c: Mono Amp-Out Amp-Out caps: ofs=0x0f, nsteps=0x0f, stepsize=0x0b, mute=1 Amp-Out vals: [0x80] Connection: 2 0x10* 0x16 Node 0x0e [Audio Mixer] wcaps 0x200101: Stereo Connection: 8 0x0d 0x11 0x12 0x13 0x1a 0x1b 0x1c 0x1d Node 0x0f [Audio Mixer] wcaps 0x200100: Mono Connection: 1 0x0b Node 0x10 [Beep Generator Widget] wcaps 0x700000: Mono Node 0x11 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x1f 0x1f] Connection: 1 0x03 Node 0x12 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x80 0x80] Connection: 1 0x08 Node 0x13 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x80 0x80] Connection: 1 0x09 Node 0x14 [Power Widget] wcaps 0x500500: Mono Power: setting=D0, actual=D0 Connection: 13 0x0d* 0x0e 0x0f 0x10 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1d Node 0x15 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x0f, stepsize=0x05, mute=1 Amp-Out vals: [0x00 0x00] Connection: 8 0x0c* 0x09 0x0e 0x0f 0x19 0x05 0x18 0x17 Node 0x16 [Pin Complex] wcaps 0x400000: Mono Pincap 0x0820: IN Pin Default 0x995711f0: [Fixed] Digital Out at Int ATAPI Conn = Analog, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Node 0x17 [Pin Complex] wcaps 0x400081: Stereo Pincap 0x0827: IN Detect Trigger ImpSense Pin Default 0x5993e0f0: [N/A] Aux at Int ATAPI Conn = ATAPI, Color = White DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x20: IN Unsolicited: tag=00, enabled=0 Node 0x18 [Pin Complex] wcaps 0x400187: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] [0x00 0x00] Amp-Out caps: ofs=0x3d, nsteps=0x3f, stepsize=0x05, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x081737: IN OUT Detect Trigger ImpSense Vref caps: HIZ 50 GRD 80 Pin Default 0x91a79121: [Fixed] Mic at Int Rear Conn = Analog, Color = Pink DefAssociation = 0x2, Sequence = 0x1 Misc = NO_PRESENCE Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=00, enabled=0 Connection: 2 0x03* 0x0e Node 0x19 [Pin Complex] wcaps 0x400001: Stereo Pincap 0x0820: IN Pin Default 0x593310f0: [N/A] CD at Int ATAPI Conn = ATAPI, Color = Black DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x20: IN Node 0x1a [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x80 0x80] Connection: 1 0x05 Node 0x1b [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x80 0x80] Connection: 1 0x17 Node 0x1c [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x80 0x80] Connection: 1 0x18 Node 0x1d [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x80 0x80] Connection: 1 0x19 Node 0x1e [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Connection: 1 0x08 Node 0x1f [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Connection: 1 0x18
################ END #####################################
# uname -a Linux ensima-hp 2.6.24 #18 SMP PREEMPT Sun Feb 3 01:19:45 CET 2008 i686 AMD Turion(tm) 64 X2 Mobile Technology TL-56 AuthenticAMD GNU/Linux
# cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.16rc2 (Thu Jan 31 16:40:16 2008 UTC)
alsa-headers-1.0.16_rc2 alsa-lib-1.0.16_rc2 alsa-utils-1.0.16_rc1
From Andrew Morton:
"Recording the bug in the alsa bugtracker is good, and Takashi is actively working on the bug, and he is the best guy to do that.
So I don't think anything else really needs to be done here - please work with him on solving this?"
######################################
Hi, Takashi, so can You help ? Below is my letter to LKML (in case You haven't read it yet).
Problem description:
I have a problem with recording on HP nx6325 notebook (hda-intel with AD1981HD codec). Playback works fine, but after 5-10 min. of recording microphone stops working (playback works all the time). Unloading and loading sound modules fixes problem, but only for another 5-10 minutes. This problem exists from more than a year (at least from 2.6.17.13 kernel). In [1] we came to conclusion that this problem is ralated to IRQ sharing [2] (HDA Intel is on the same IRQ as sata_sil).
How to reproduce the problem:
1) on one console run arecord and see the output (You should see some garbage) 2) on another console run cat /etc/* 3) at once arecord on the first console gives no output
So, doing lot of hdd I/O occurs problem with mic.
What had been done:
1) I tried to boot Fedora 8 livecd and unload sata_sil, so that hda_intel was the only device using IRQ. After that microphone was working all the time (I left recording for all night, and in the morning I had almost 2h voip chat using Twinkle). So when sata_sil is unloaded, and hda-intel is not sharing the IRQ, the mic. is working all the time. Look at [3] to see /proc/interrupts output when laptop is booted from livecd, and mic works.
2) I tried to load hda-intel with enable_msi=1 (my RS480 chip is on blacklist, but I've removed it). Module loads and playback works ok, but problem with mic still exists. Difference here is that when recording stops to work the playback also stops to work (without MSI only mic stops to work). Look at [4] to see /proc/interrupts output when module is loaded with enable_msi=1.
Question:
What information I need to provide to help resolving the problem ? Where to start, because I've run out of ideas :) ?
References: [1] https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2449
######################################
[2] cat /proc/interrupts (IRQ sharing) CPU0 CPU1 0: 71953009 0 local-APIC-edge-fasteoi timer 1: 36662 1 IO-APIC-edge i8042 8: 1 1 IO-APIC-edge rtc 12: 147 1 IO-APIC-edge i8042 14: 49 2 IO-APIC-edge ide0 16: 681511809 679908107 IO-APIC-fasteoi sata_sil, HDA Intel 18: 29 1 IO-APIC-fasteoi 19: 430379 1 IO-APIC-fasteoi ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3 20: 0 1 IO-APIC-fasteoi sdhci:slot0, yenta 21: 1231834 9 IO-APIC-fasteoi acpi 23: 2273726 1 IO-APIC-fasteoi eth0 NMI: 0 0 Non-maskable interrupts LOC: 0 71952388 Local timer interrupts RES: 44883365 19180072 Rescheduling interrupts CAL: 57631 790 function call interrupts TLB: 7262 11762 TLB shootdowns TRM: 0 0 Thermal event interrupts SPU: 0 0 Spurious interrupts ERR: 37465 MIS: 0
[ceho@ensima-hp ~]$ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.15 (Tue Nov 20 19:16:42 2007 UTC).
[ceho@ensima-hp ~]$ uname -a Linux ensima-hp 2.6.24 #7 SMP PREEMPT Mon Feb 4 20:34:21 CET 2008 i686 AMD Turion(tm) 64 X2 Mobile Technology TL-56 AuthenticAMD GNU/Linux
######################################
[3] [fedora@localhost ~]$ cat /proc/interrupts CPU0 CPU1 0: 3014988 0 local-APIC-edge-fasteoi timer 1: 0 1881 IO-APIC-edge i8042 8: 0 1 IO-APIC-edge rtc 12: 0 151 IO-APIC-edge i8042 14: 2 17391 IO-APIC-edge libata 15: 0 0 IO-APIC-edge libata 16: 1 49 IO-APIC-fasteoi yenta, firewire_ohci, tifm_7xx1, sdhci:slot0 17: 0 23001 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2, ehci_hcd:usb3 18: 0 260787 IO-APIC-fasteoi HDA Intel 20: 0 297695 IO-APIC-fasteoi eth1 21: 3 2304 IO-APIC-fasteoi acpi NMI: 0 0 LOC: 0 3014807 ERR: 15 MIS: 0
[fedora@localhost ~]$ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.15 (Tue Oct 23 06:09:18 2007 UTC).
[fedora@localhost ~]$ uname -a Linux localhost.localdomain 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 athlon i386 GNU/Linux
######################################
[4] cat /proc/interrupts CPU0 CPU1 0: 51997092 0 local-APIC-edge-fasteoi timer 1: 50850 2 IO-APIC-edge i8042 8: 1 1 IO-APIC-edge rtc 12: 792 2 IO-APIC-edge i8042 14: 9331 2 IO-APIC-edge ide0 16: 0 1 IO-APIC-fasteoi yenta, sdhci:slot0 17: 3449488 190200 IO-APIC-fasteoi eth0 18: 492896 6 IO-APIC-fasteoi sata_sil 20: 457421 1 IO-APIC-fasteoi ehci_hcd:usb1, ohci_hcd:usb2, ohci_hcd:usb3 21: 181549 9 IO-APIC-fasteoi acpi 220: 50035 1136607 PCI-MSI-edge HDA Intel NMI: 0 0 Non-maskable interrupts LOC: 0 51994900 Local timer interrupts RES: 3435250 2342689 Rescheduling interrupts CAL: 9842 2528 function call interrupts TLB: 11148 18295 TLB shootdowns TRM: 0 0 Thermal event interrupts SPU: 0 0 Spurious interrupts ERR: 113 MIS: 0
######################################
At Wed, 6 Feb 2008 12:09:35 +0100, Grzegorz Chwesewicz wrote:
From Andrew Morton:
"Recording the bug in the alsa bugtracker is good, and Takashi is actively working on the bug, and he is the best guy to do that.
So I don't think anything else really needs to be done here - please work with him on solving this?"
######################################
Hi, Takashi, so can You help ? Below is my letter to LKML (in case You haven't read it yet).
Don't worry, I've been reading it, but had too little time to track down.
Problem description:
I have a problem with recording on HP nx6325 notebook (hda-intel with AD1981HD codec). Playback works fine, but after 5-10 min. of recording microphone stops working (playback works all the time). Unloading and loading sound modules fixes problem, but only for another 5-10 minutes. This problem exists from more than a year (at least from 2.6.17.13 kernel). In [1] we came to conclusion that this problem is ralated to IRQ sharing [2] (HDA Intel is on the same IRQ as sata_sil).
How to reproduce the problem:
- on one console run arecord and see the output (You should see some garbage)
- on another console run cat /etc/*
- at once arecord on the first console gives no output
So, doing lot of hdd I/O occurs problem with mic.
What had been done:
- I tried to boot Fedora 8 livecd and unload sata_sil, so that hda_intel was
the only device using IRQ. After that microphone was working all the time (I left recording for all night, and in the morning I had almost 2h voip chat using Twinkle). So when sata_sil is unloaded, and hda-intel is not sharing the IRQ, the mic. is working all the time. Look at [3] to see /proc/interrupts output when laptop is booted from livecd, and mic works.
- I tried to load hda-intel with enable_msi=1 (my RS480 chip is on blacklist,
but I've removed it). Module loads and playback works ok, but problem with mic still exists. Difference here is that when recording stops to work the playback also stops to work (without MSI only mic stops to work). Look at [4] to see /proc/interrupts output when module is loaded with enable_msi=1.
Question:
What information I need to provide to help resolving the problem ? Where to start, because I've run out of ideas :) ?
This is a pretty nasty bug. Appreantly this seems specific to ATI chipset, and I'm not sure whether it's AD1981HD specific, too. (Due to the fact that it's related with IRQ, I guess rather not specific to the codec chip.)
It's nice that you already tried MSI as I suggsted. Could you check whether the irq handler still gets called? For example, try the patch below and see whether the message appears.
thanks,
Takashi
diff -r 17f90f301932 pci/hda/hda_intel.c --- a/pci/hda/hda_intel.c Thu Feb 07 12:06:32 2008 +0100 +++ b/pci/hda/hda_intel.c Thu Feb 07 12:54:48 2008 +0100 @@ -922,6 +922,10 @@ static irqreturn_t azx_interrupt(int irq status = azx_readl(chip, INTSTS); if (status == 0) { spin_unlock(&chip->reg_lock); + if (chip->msi) { + printk(KERN_DEBUG "XXX hda-intel: status=0\n"); + return IRQ_HANDLED; + } return IRQ_NONE; }
At Thu, 07 Feb 2008 13:09:24 +0100, I wrote:
At Wed, 6 Feb 2008 12:09:35 +0100, Grzegorz Chwesewicz wrote:
From Andrew Morton:
"Recording the bug in the alsa bugtracker is good, and Takashi is actively working on the bug, and he is the best guy to do that.
So I don't think anything else really needs to be done here - please work with him on solving this?"
######################################
Hi, Takashi, so can You help ? Below is my letter to LKML (in case You haven't read it yet).
Don't worry, I've been reading it, but had too little time to track down.
Problem description:
I have a problem with recording on HP nx6325 notebook (hda-intel with AD1981HD codec). Playback works fine, but after 5-10 min. of recording microphone stops working (playback works all the time). Unloading and loading sound modules fixes problem, but only for another 5-10 minutes. This problem exists from more than a year (at least from 2.6.17.13 kernel). In [1] we came to conclusion that this problem is ralated to IRQ sharing [2] (HDA Intel is on the same IRQ as sata_sil).
How to reproduce the problem:
- on one console run arecord and see the output (You should see some garbage)
- on another console run cat /etc/*
- at once arecord on the first console gives no output
So, doing lot of hdd I/O occurs problem with mic.
What had been done:
- I tried to boot Fedora 8 livecd and unload sata_sil, so that hda_intel was
the only device using IRQ. After that microphone was working all the time (I left recording for all night, and in the morning I had almost 2h voip chat using Twinkle). So when sata_sil is unloaded, and hda-intel is not sharing the IRQ, the mic. is working all the time. Look at [3] to see /proc/interrupts output when laptop is booted from livecd, and mic works.
- I tried to load hda-intel with enable_msi=1 (my RS480 chip is on blacklist,
but I've removed it). Module loads and playback works ok, but problem with mic still exists. Difference here is that when recording stops to work the playback also stops to work (without MSI only mic stops to work). Look at [4] to see /proc/interrupts output when module is loaded with enable_msi=1.
Question:
What information I need to provide to help resolving the problem ? Where to start, because I've run out of ideas :) ?
This is a pretty nasty bug. Appreantly this seems specific to ATI chipset, and I'm not sure whether it's AD1981HD specific, too. (Due to the fact that it's related with IRQ, I guess rather not specific to the codec chip.)
It's nice that you already tried MSI as I suggsted. Could you check whether the irq handler still gets called? For example, try the patch below and see whether the message appears.
BTW, do you have problems found in below? https://bugzilla.novell.com/show_bug.cgi?id=297703
According to the reporter, nc6400 with AD1981 has a problem with headphone jack auto-muting and with the non-linear master volume.
I supplied two test patches there.
Takashi
At Fri, 08 Feb 2008 13:24:52 +0100, I wrote:
BTW, do you have problems found in below? https://bugzilla.novell.com/show_bug.cgi?id=297703
According to the reporter, nc6400 with AD1981 has a problem with headphone jack auto-muting and with the non-linear master volume.
I supplied two test patches there.
For convenience, I attach patches here.
Takashi
Friday 08 of February 2008 16:57:37 Takashi Iwai napisał(a):
At Fri, 08 Feb 2008 13:24:52 +0100,
I wrote:
BTW, do you have problems found in below? https://bugzilla.novell.com/show_bug.cgi?id=297703
According to the reporter, nc6400 with AD1981 has a problem with headphone jack auto-muting and with the non-linear master volume.
I supplied two test patches there.
For convenience, I attach patches here.
Hi, I had no time to test your first patch (this one which check if irq handler is called), I've only tested it for a while (working on MSI turned on, sometimes hard locks my laptop).
I also have similiar problems with automute, and non-linear master volume control.
Without automute patch, automute works from time to time. With your patch applied to latest git it works all the time, until the recording breaks. When it happens I have sound only in headphones, but not in internal speaker. Pluging and unpluging HP doesn't help, only reloading hda-intel fixes problem. Assuming, your automute patch is ok, but it helps me only until mic breaks.
Without ad1981-hp-master-amp-fix muting (muting=disabling it, not making it's value equal 0) "Master" and "PCM" control works ok. Decrementing Master and PCM controls to 0 is possible, but after that I can hear very quiet output from internal speakers. With your patch (ad1981-hp-master-amp-fix) applied to latest git I can't decrement Master control to 0 (I can do that with PCM, but behavior is same as described upper). I can only decrement it to value 3, and when I press down key (in alsamixer) to step to lower level of loudness, it's switching to value 103. When Master has 103 value I can hear very quiet output from internal speakers and HP (if plugged).
I hope you understand my english ;)
PS. I will test your irq_handler_check patch today, and I will send results soon.
At Fri, 8 Feb 2008 19:51:39 +0100, Grzegorz Chwesewicz wrote:
Friday 08 of February 2008 16:57:37 Takashi Iwai napisał(a):
At Fri, 08 Feb 2008 13:24:52 +0100,
I wrote:
BTW, do you have problems found in below? https://bugzilla.novell.com/show_bug.cgi?id=297703
According to the reporter, nc6400 with AD1981 has a problem with headphone jack auto-muting and with the non-linear master volume.
I supplied two test patches there.
For convenience, I attach patches here.
Hi, I had no time to test your first patch (this one which check if irq handler is called), I've only tested it for a while (working on MSI turned on, sometimes hard locks my laptop).
I also have similiar problems with automute, and non-linear master volume control.
Without automute patch, automute works from time to time. With your patch applied to latest git it works all the time, until the recording breaks. When it happens I have sound only in headphones, but not in internal speaker. Pluging and unpluging HP doesn't help, only reloading hda-intel fixes problem. Assuming, your automute patch is ok, but it helps me only until mic breaks.
OK, this patch is now on HG tree.
Without ad1981-hp-master-amp-fix muting (muting=disabling it, not making it's value equal 0) "Master" and "PCM" control works ok. Decrementing Master and PCM controls to 0 is possible, but after that I can hear very quiet output from internal speakers. With your patch (ad1981-hp-master-amp-fix) applied to latest git I can't decrement Master control to 0 (I can do that with PCM, but behavior is same as described upper). I can only decrement it to value 3, and when I press down key (in alsamixer) to step to lower level of loudness, it's switching to value 103. When Master has 103 value I can hear very quiet output from internal speakers and HP (if plugged).
The patch will change only the behavior of Master control. PCM should be as same as before.
What "value" are you referring in the above context? Is it a raw mixer value, percent or dB, or the codec amp value?
Maybe we need to make clear how the master volume control behaves. According to the original bug reporter, the master volume behaves like below:
- from 0% to 49% sounds are still audible, and the volume doesn't change at all - from 50% to 100% sounds get louder normally
How about yours?
Takashi
I have read the whole thread and I have the same exact problem of recording with a realtek ALC861 codec on a ATI chipset board. My harddisk controller is also using sata_sil module. I have this problem for a long time too. Would the same patch solve the problem for me as well?
2008/2/12, Takashi Iwai tiwai@suse.de:
At Fri, 8 Feb 2008 19:51:39 +0100, Grzegorz Chwesewicz wrote:
Friday 08 of February 2008 16:57:37 Takashi Iwai napisał(a):
At Fri, 08 Feb 2008 13:24:52 +0100,
I wrote:
BTW, do you have problems found in below? https://bugzilla.novell.com/show_bug.cgi?id=297703
According to the reporter, nc6400 with AD1981 has a problem with headphone jack auto-muting and with the non-linear master volume.
I supplied two test patches there.
For convenience, I attach patches here.
Hi, I had no time to test your first patch (this one which check if irq handler is called), I've only tested it for a while (working on MSI turned on, sometimes hard locks my laptop).
I also have similiar problems with automute, and non-linear master volume control.
Without automute patch, automute works from time to time. With your patch applied to latest git it works all the time, until the recording breaks. When it happens I have sound only in headphones, but not in internal speaker. Pluging and unpluging HP doesn't help, only reloading hda-intel fixes problem. Assuming, your automute patch is ok, but it helps me only until mic breaks.
OK, this patch is now on HG tree.
Without ad1981-hp-master-amp-fix muting (muting=disabling it, not making it's value equal 0) "Master" and "PCM" control works ok. Decrementing Master and PCM controls to 0 is possible, but after that I can hear very quiet output from internal speakers. With your patch (ad1981-hp-master-amp-fix) applied to latest git I can't decrement Master control to 0 (I can do that with PCM, but behavior is same as described upper). I can only decrement it to value 3, and when I press down key (in alsamixer) to step to lower level of loudness, it's switching to value 103. When Master has 103 value I can hear very quiet output from internal speakers and HP (if plugged).
The patch will change only the behavior of Master control. PCM should be as same as before.
What "value" are you referring in the above context? Is it a raw mixer value, percent or dB, or the codec amp value?
Maybe we need to make clear how the master volume control behaves. According to the original bug reporter, the master volume behaves like below:
- from 0% to 49% sounds are still audible, and the volume doesn't change at all
- from 50% to 100% sounds get louder normally
How about yours?
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Tue, 12 Feb 2008 16:00:51 +0200, Ustun ERGENOGLU wrote:
I have read the whole thread and I have the same exact problem of recording with a realtek ALC861 codec on a ATI chipset board. My harddisk controller is also using sata_sil module. I have this problem for a long time too. Would the same patch solve the problem for me as well?
Well, the patch does have effect only when you enable MSI. And, MSI is disabled on many ATI chipsets as default unless you patch the kernel. I suggest it just to check whether any unknown IRQs are issued or the hardware is just screwed up.
It looks like this is a generic problem of ATI SB chipset. Which model is it? SB450, SB460 or SB600?
Takashi
2008/2/12, Takashi Iwai tiwai@suse.de:
At Fri, 8 Feb 2008 19:51:39 +0100, Grzegorz Chwesewicz wrote:
Friday 08 of February 2008 16:57:37 Takashi Iwai napisał(a):
At Fri, 08 Feb 2008 13:24:52 +0100,
I wrote:
BTW, do you have problems found in below? https://bugzilla.novell.com/show_bug.cgi?id=297703
According to the reporter, nc6400 with AD1981 has a problem with headphone jack auto-muting and with the non-linear master volume.
I supplied two test patches there.
For convenience, I attach patches here.
Hi, I had no time to test your first patch (this one which check if irq handler is called), I've only tested it for a while (working on MSI turned on, sometimes hard locks my laptop).
I also have similiar problems with automute, and non-linear master volume control.
Without automute patch, automute works from time to time. With your patch applied to latest git it works all the time, until the recording breaks. When it happens I have sound only in headphones, but not in internal speaker. Pluging and unpluging HP doesn't help, only reloading hda-intel fixes problem. Assuming, your automute patch is ok, but it helps me only until mic breaks.
OK, this patch is now on HG tree.
Without ad1981-hp-master-amp-fix muting (muting=disabling it, not making it's value equal 0) "Master" and "PCM" control works ok. Decrementing Master and PCM controls to 0 is possible, but after that I can hear very quiet output from internal speakers. With your patch (ad1981-hp-master-amp-fix) applied to latest git I can't decrement Master control to 0 (I can do that with PCM, but behavior is same as described upper). I can only decrement it to value 3, and when I press down key (in alsamixer) to step to lower level of loudness, it's switching to value 103. When Master has 103 value I can hear very quiet output from internal speakers and HP (if plugged).
The patch will change only the behavior of Master control. PCM should be as same as before.
What "value" are you referring in the above context? Is it a raw mixer value, percent or dB, or the codec amp value?
Maybe we need to make clear how the master volume control behaves. According to the original bug reporter, the master volume behaves like below:
- from 0% to 49% sounds are still audible, and the volume doesn't change at all
- from 50% to 100% sounds get louder normally
How about yours?
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
It looks like this is a generic problem of ATI SB chipset. Which model is it? SB450, SB460 or SB600?
it is SB450
Takashi
2008/2/12, Takashi Iwai tiwai@suse.de:
At Fri, 8 Feb 2008 19:51:39 +0100, Grzegorz Chwesewicz wrote:
Friday 08 of February 2008 16:57:37 Takashi Iwai napisał(a):
At Fri, 08 Feb 2008 13:24:52 +0100,
I wrote:
BTW, do you have problems found in below? https://bugzilla.novell.com/show_bug.cgi?id=297703
According to the reporter, nc6400 with AD1981 has a problem with headphone jack auto-muting and with the non-linear master volume.
I supplied two test patches there.
For convenience, I attach patches here.
Hi, I had no time to test your first patch (this one which check if irq handler is called), I've only tested it for a while (working on MSI turned on, sometimes hard locks my laptop).
I also have similiar problems with automute, and non-linear master volume control.
Without automute patch, automute works from time to time. With your patch applied to latest git it works all the time, until the recording breaks. When it happens I have sound only in headphones, but not in internal speaker. Pluging and unpluging HP doesn't help, only reloading hda-intel fixes problem. Assuming, your automute patch is ok, but it helps me only until mic breaks.
OK, this patch is now on HG tree.
Without ad1981-hp-master-amp-fix muting (muting=disabling it, not making it's value equal 0) "Master" and "PCM" control works ok. Decrementing Master and PCM controls to 0 is possible, but after that I can hear very quiet output from internal speakers. With your patch (ad1981-hp-master-amp-fix) applied to latest git I can't decrement Master control to 0 (I can do that with PCM, but behavior is same as described upper). I can only decrement it to value 3, and when I press down key (in alsamixer) to step to lower level of loudness, it's switching to value 103. When Master has 103 value I can hear very quiet output from internal speakers and HP (if plugged).
The patch will change only the behavior of Master control. PCM should be as same as before.
What "value" are you referring in the above context? Is it a raw mixer value, percent or dB, or the codec amp value?
Maybe we need to make clear how the master volume control behaves. According to the original bug reporter, the master volume behaves like below:
- from 0% to 49% sounds are still audible, and the volume doesn't change at all
- from 50% to 100% sounds get louder normally
How about yours?
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
Tuesday 12 of February 2008 15:04:59 Takashi Iwai napisał(a):
At Tue, 12 Feb 2008 16:00:51 +0200,
Ustun ERGENOGLU wrote:
I have read the whole thread and I have the same exact problem of recording with a realtek ALC861 codec on a ATI chipset board. My harddisk controller is also using sata_sil module. I have this problem for a long time too. Would the same patch solve the problem for me as well?
Well, the patch does have effect only when you enable MSI. And, MSI is disabled on many ATI chipsets as default unless you patch the kernel. I suggest it just to check whether any unknown IRQs are issued or the hardware is just screwed up.
It looks like this is a generic problem of ATI SB chipset. Which model is it? SB450, SB460 or SB600?
Below are results of my tests with patch from Takashi (and MSI enabled).
Using arecord everytime ends in freezing machine. My laptop freezes exactly when recording stops working. My test procedure looks like this:
1) on one console run arecord and see the output (You should see some garbage) 2) on another console run cat /etc/* 3) wait for freeze ;)
Here is section from /var/log/messages (text in <> can be seen only on console, syslog doesn't catch to save it to disk, and machine freezes):
1232171 Feb 12 18:38:15 ensima-hp [ 63.888029] ALSA sound/pci/hda/hda_intel.c:1258: azx_pcm_prepare: bufsize=0x10000, fragsize=0x2000, format=0x21 1232172 Feb 12 18:38:15 ensima-hp [ 63.888081] ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x4, stream=0x1, channel=0, format=0x21 1232173 Feb 12 18:38:22 ensima-hp [ 70.913893] ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x4, stream=0x0, channel=0, format=0x0 1232174 Feb 12 18:38:27 ensima-hp [ 75.885448] ALSA sound/pci/hda/hda_intel.c:1258: azx_pcm_prepare: bufsize=0x10000, fragsize=0x2000, format=0x21 1232175 Feb 12 18:38:27 ensima-hp [ 75.885490] ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x4, stream=0x1, channel=0, format=0x21 ####### Recording stops to work and machine freezes ####### <XXX hda-intel: status=0> <XXX hda-intel: status=0> <XXX hda-intel: status=0> <XXX hda-intel: status=0>
Takashi, below is listing of few softlockups that I've encountered while testing your patch (MSI one).
78921 Feb 7 17:37:01 ensima-hp [ 290.184844] BUG: soft lockup - CPU#0 stuck for 11s! [kirqd:879] 78922 Feb 7 17:37:01 ensima-hp [ 290.184848] 78923 Feb 7 17:37:01 ensima-hp [ 290.184851] Pid: 879, comm: kirqd Not tainted (2.6.24 #3) 78924 Feb 7 17:37:01 ensima-hp [ 290.184854] EIP: 0060:[<c0155ed3>] EFLAGS: 00000246 CPU: 0 78925 Feb 7 17:37:01 ensima-hp [ 290.184859] EIP is at handle_IRQ_event+0x13/0x60 78926 Feb 7 17:37:01 ensima-hp [ 290.184862] EAX: 000000dc EBX: f72177a0 ECX: f7d9c000 EDX: f72177a0 78927 Feb 7 17:37:01 ensima-hp [ 290.184865] ESI: f72177a0 EDI: 000000dc EBP: 000000dc ESP: f7d9df0c 78928 Feb 7 17:37:01 ensima-hp [ 290.184868] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 78929 Feb 7 17:37:01 ensima-hp [ 290.184871] CR0: 8005003b CR2: 0807b064 CR3: 36e30000 CR4: 000006d0 78930 Feb 7 17:37:01 ensima-hp [ 290.184875] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 78931 Feb 7 17:37:02 ensima-hp [ 290.184878] DR6: ffff0ff0 DR7: 00000400 78932 Feb 7 17:37:02 ensima-hp [ 290.184895] [<c01573dd>] handle_edge_irq+0xad/0x130 78933 Feb 7 17:37:02 ensima-hp [ 290.184903] [<c010827b>] do_IRQ+0x3b/0x70 78934 Feb 7 17:37:02 ensima-hp [ 290.184915] [<c0105ea3>] common_interrupt+0x23/0x28 78935 Feb 7 17:37:02 ensima-hp [ 290.184929] [<c011b6f3>] balanced_irq+0x3f3/0x5b0 78936 Feb 7 17:37:02 ensima-hp [ 290.184949] [<c011b300>] balanced_irq+0x0/0x5b0 78937 Feb 7 17:37:02 ensima-hp [ 290.184969] [<c013e502>] kthread+0x42/0x70 78938 Feb 7 17:37:02 ensima-hp [ 290.184973] [<c013e4c0>] kthread+0x0/0x70 78939 Feb 7 17:37:02 ensima-hp [ 290.184977] [<c01060cf>] kernel_thread_helper+0x7/0x18 78940 Feb 7 17:37:02 ensima-hp [ 290.184987] ======================= 78941 Feb 7 17:37:13 ensima-hp [ 301.989526] BUG: soft lockup - CPU#0 stuck for 11s! [kirqd:879] 78942 Feb 7 17:37:13 ensima-hp [ 301.989529] 78943 Feb 7 17:37:13 ensima-hp [ 301.989531] Pid: 879, comm: kirqd Not tainted (2.6.24 #3) 78944 Feb 7 17:37:13 ensima-hp [ 301.989533] EIP: 0060:[<c0155ed3>] EFLAGS: 00000246 CPU: 0 78945 Feb 7 17:37:13 ensima-hp [ 301.989536] EIP is at handle_IRQ_event+0x13/0x60 78946 Feb 7 17:37:13 ensima-hp [ 301.989539] EAX: 000000dc EBX: f72177a0 ECX: f7d9c000 EDX: f72177a0 78947 Feb 7 17:37:13 ensima-hp [ 301.989541] ESI: f72177a0 EDI: 000000dc EBP: 000000dc ESP: f7d9df0c 78948 Feb 7 17:37:13 ensima-hp [ 301.989544] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 78949 Feb 7 17:37:13 ensima-hp [ 301.989547] CR0: 8005003b CR2: 0807b064 CR3: 36e30000 CR4: 000006d0 78950 Feb 7 17:37:13 ensima-hp [ 301.989550] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 78951 Feb 7 17:37:14 ensima-hp [ 301.989552] DR6: ffff0ff0 DR7: 00000400 78952 Feb 7 17:37:14 ensima-hp [ 301.989560] [<c01573dd>] handle_edge_irq+0xad/0x130 78953 Feb 7 17:37:14 ensima-hp [ 301.989581] [<c010827b>] do_IRQ+0x3b/0x70 78954 Feb 7 17:37:14 ensima-hp [ 301.989592] [<c0105ea3>] common_interrupt+0x23/0x28 78955 Feb 7 17:37:14 ensima-hp [ 301.989606] [<c011b6f3>] balanced_irq+0x3f3/0x5b0 78956 Feb 7 17:37:14 ensima-hp [ 301.989639] [<c011b300>] balanced_irq+0x0/0x5b0 78957 Feb 7 17:37:14 ensima-hp [ 301.989644] [<c013e502>] kthread+0x42/0x70 78958 Feb 7 17:37:14 ensima-hp [ 301.989646] [<c013e4c0>] kthread+0x0/0x70 78959 Feb 7 17:37:14 ensima-hp [ 301.989651] [<c01060cf>] kernel_thread_helper+0x7/0x18 78960 Feb 7 17:37:14 ensima-hp [ 301.989659] ======================= 78961 Feb 7 17:37:25 ensima-hp [ 313.794211] BUG: soft lockup - CPU#0 stuck for 11s! [kirqd:879] 78962 Feb 7 17:37:25 ensima-hp [ 313.794214] 78963 Feb 7 17:37:25 ensima-hp [ 313.794216] Pid: 879, comm: kirqd Not tainted (2.6.24 #3) 78964 Feb 7 17:37:25 ensima-hp [ 313.794218] EIP: 0060:[<c03a6117>] EFLAGS: 00000282 CPU: 0 78965 Feb 7 17:37:25 ensima-hp [ 313.794222] EIP is at _read_unlock_irqrestore+0x7/0x30 78966 Feb 7 17:37:25 ensima-hp [ 313.794226] EAX: 00000282 EBX: f6ee4800 ECX: f7d9c000 EDX: 00000282 78967 Feb 7 17:37:25 ensima-hp [ 313.794229] ESI: f71d1380 EDI: 000004c8 EBP: f6ee4800 ESP: f7d9deac 78968 Feb 7 17:37:25 ensima-hp [ 313.794231] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 78969 Feb 7 17:37:25 ensima-hp [ 313.794237] CR0: 8005003b CR2: 0807b064 CR3: 36e30000 CR4: 000006d0 78970 Feb 7 17:37:25 ensima-hp [ 313.794257] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 78971 Feb 7 17:37:25 ensima-hp [ 313.794272] DR6: ffff0ff0 DR7: 00000400 78972 Feb 7 17:37:26 ensima-hp [ 313.794275] [<f955ffed>] snd_pcm_period_elapsed+0x7d/0x2f0 [snd_pcm] 78973 Feb 7 17:37:26 ensima-hp [ 313.794298] [<c027c993>] pci_bus_write_config_word+0x63/0x80 78974 Feb 7 17:37:26 ensima-hp [ 313.794323] [<f956efd9>] azx_interrupt+0x79/0x100 [snd_hda_intel] 78975 Feb 7 17:37:26 ensima-hp [ 313.794344] [<c0155ef0>] handle_IRQ_event+0x30/0x60 78976 Feb 7 17:37:26 ensima-hp [ 313.794351] [<c01573dd>] handle_edge_irq+0xad/0x130 78977 Feb 7 17:37:26 ensima-hp [ 313.794357] [<c010827b>] do_IRQ+0x3b/0x70 78978 Feb 7 17:37:26 ensima-hp [ 313.794366] [<c0105ea3>] common_interrupt+0x23/0x28 78979 Feb 7 17:37:26 ensima-hp [ 313.794377] [<c011b6f3>] balanced_irq+0x3f3/0x5b0 78980 Feb 7 17:37:26 ensima-hp [ 313.794393] [<c011b300>] balanced_irq+0x0/0x5b0 78981 Feb 7 17:37:26 ensima-hp [ 313.794398] [<c013e502>] kthread+0x42/0x70 78982 Feb 7 17:37:26 ensima-hp [ 313.794401] [<c013e4c0>] kthread+0x0/0x70 78983 Feb 7 17:37:26 ensima-hp [ 313.794405] [<c01060cf>] kernel_thread_helper+0x7/0x18 78984 Feb 7 17:37:27 ensima-hp [ 313.794414] ======================= 78985 Feb 7 17:37:37 ensima-hp [ 325.598892] BUG: soft lockup - CPU#0 stuck for 11s! [kirqd:879] 78986 Feb 7 17:37:37 ensima-hp [ 325.598895] 78987 Feb 7 17:37:37 ensima-hp [ 325.598897] Pid: 879, comm: kirqd Not tainted (2.6.24 #3) 78988 Feb 7 17:37:37 ensima-hp [ 325.598899] EIP: 0060:[<c03a6117>] EFLAGS: 00000282 CPU: 0 78989 Feb 7 17:37:37 ensima-hp [ 325.598902] EIP is at _read_unlock_irqrestore+0x7/0x30 78990 Feb 7 17:37:37 ensima-hp [ 325.598907] EAX: 00000282 EBX: f6ee4800 ECX: f7d9c000 EDX: 00000282 78991 Feb 7 17:37:37 ensima-hp [ 325.598910] ESI: f71d1380 EDI: 000004c8 EBP: f6ee4800 ESP: f7d9deac 78992 Feb 7 17:37:37 ensima-hp [ 325.598913] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 78993 Feb 7 17:37:37 ensima-hp [ 325.598924] CR0: 8005003b CR2: 0807b064 CR3: 36e30000 CR4: 000006d0 78994 Feb 7 17:37:37 ensima-hp [ 325.598928] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 78995 Feb 7 17:37:37 ensima-hp [ 325.598942] DR6: ffff0ff0 DR7: 00000400 78996 Feb 7 17:37:37 ensima-hp [ 325.598946] [<f955ffed>] snd_pcm_period_elapsed+0x7d/0x2f0 [snd_pcm] 78997 Feb 7 17:37:37 ensima-hp [ 325.598964] [<c027c993>] pci_bus_write_config_word+0x63/0x80 78998 Feb 7 17:37:37 ensima-hp [ 325.598983] [<f956efd9>] azx_interrupt+0x79/0x100 [snd_hda_intel] 78999 Feb 7 17:37:38 ensima-hp [ 325.599003] [<c0155ef0>] handle_IRQ_event+0x30/0x60 79000 Feb 7 17:37:38 ensima-hp [ 325.599010] [<c01573dd>] handle_edge_irq+0xad/0x130 79001 Feb 7 17:37:38 ensima-hp [ 325.599016] [<c010827b>] do_IRQ+0x3b/0x70 79002 Feb 7 17:37:38 ensima-hp [ 325.599025] [<c0105ea3>] common_interrupt+0x23/0x28 79003 Feb 7 17:37:38 ensima-hp [ 325.599036] [<c011b6f3>] balanced_irq+0x3f3/0x5b0 79004 Feb 7 17:37:38 ensima-hp [ 325.599052] [<c011b300>] balanced_irq+0x0/0x5b0 79005 Feb 7 17:37:38 ensima-hp [ 325.599057] [<c013e502>] kthread+0x42/0x70 79006 Feb 7 17:37:38 ensima-hp [ 325.599060] [<c013e4c0>] kthread+0x0/0x70 79007 Feb 7 17:37:38 ensima-hp [ 325.599064] [<c01060cf>] kernel_thread_helper+0x7/0x18 79008 Feb 7 17:37:38 ensima-hp [ 325.599073] =======================
At Tue, 12 Feb 2008 18:59:44 +0100, Grzegorz Chwesewicz wrote:
Tuesday 12 of February 2008 15:04:59 Takashi Iwai napisał(a):
At Tue, 12 Feb 2008 16:00:51 +0200,
Ustun ERGENOGLU wrote:
I have read the whole thread and I have the same exact problem of recording with a realtek ALC861 codec on a ATI chipset board. My harddisk controller is also using sata_sil module. I have this problem for a long time too. Would the same patch solve the problem for me as well?
Well, the patch does have effect only when you enable MSI. And, MSI is disabled on many ATI chipsets as default unless you patch the kernel. I suggest it just to check whether any unknown IRQs are issued or the hardware is just screwed up.
It looks like this is a generic problem of ATI SB chipset. Which model is it? SB450, SB460 or SB600?
Below are results of my tests with patch from Takashi (and MSI enabled).
Using arecord everytime ends in freezing machine. My laptop freezes exactly when recording stops working. My test procedure looks like this:
- on one console run arecord and see the output (You should see some garbage)
- on another console run cat /etc/*
- wait for freeze ;)
Here is section from /var/log/messages (text in <> can be seen only on console, syslog doesn't catch to save it to disk, and machine freezes):
1232171 Feb 12 18:38:15 ensima-hp [ 63.888029] ALSA sound/pci/hda/hda_intel.c:1258: azx_pcm_prepare: bufsize=0x10000, fragsize=0x2000, format=0x21 1232172 Feb 12 18:38:15 ensima-hp [ 63.888081] ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x4, stream=0x1, channel=0, format=0x21 1232173 Feb 12 18:38:22 ensima-hp [ 70.913893] ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x4, stream=0x0, channel=0, format=0x0 1232174 Feb 12 18:38:27 ensima-hp [ 75.885448] ALSA sound/pci/hda/hda_intel.c:1258: azx_pcm_prepare: bufsize=0x10000, fragsize=0x2000, format=0x21 1232175 Feb 12 18:38:27 ensima-hp [ 75.885490] ALSA sound/pci/hda/hda_codec.c:682: hda_codec_setup_stream: NID=0x4, stream=0x1, channel=0, format=0x21 ####### Recording stops to work and machine freezes #######
<XXX hda-intel: status=0> <XXX hda-intel: status=0> <XXX hda-intel: status=0> <XXX hda-intel: status=0>
OK, so actually uknown IRQs are triggered. This must be really a problem of ATI SB chipset.
Takashi
The patch will change only the behavior of Master control. PCM should be as same as before.
That's correct, PCM behaves always the same way (with or without patch).
What "value" are you referring in the above context? Is it a raw mixer value, percent or dB, or the codec amp value?
I mean value which is under Master control bar in alsamixer program.
Maybe we need to make clear how the master volume control behaves. According to the original bug reporter, the master volume behaves like below:
- from 0% to 49% sounds are still audible, and the volume doesn't change at
all
- from 50% to 100% sounds get louder normally
How about yours?
I have exactly the same behavior of volume control as you described, but after applying ad1981-hp-master-amp-fix master behaves as described in previous letter and below (as reminder).
"I can only decrement it (master) to value (I've described what do I mean saying "value" in the begining of the letter) 3, and when I press down key (in alsamixer) to step to lower level of loudness, it's switching to value 103. When Master has 103 value I can hear very quiet output from internal speakers and HP (if plugged)."
participants (3)
-
Grzegorz Chwesewicz -
Takashi Iwai -
Ustun ERGENOGLU