[alsa-devel] snd-hda-intel: no data when recording from mic, "IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj" logged in kern.log

Aleksander Adamowski alsa at olo.org.pl
Wed Mar 17 12:01:15 CET 2010


Hello again Takashi,

Got no answer from you back in October and I still experience the sound
capture problem, no daily release of alsa-driver would observably solve the
problem to date. Capture stops working; sometimes arecord is silent but
produces no output, sometimes it outputs a flood of "overrun!!! (at least
27.876 ms long)".

The problem persists until system is rebooted.

The kernel log error messages no longer occur at the moment time when
capture stops working (previosly they did), but when rebooting I usually get
a short burst of either "Too big adjustment 32" or "azx_get_response
timeout" errors:


kern.log:Mar 15 13:39:06 stacja kernel: [22003.694323] ALSA
hda_intel.c:1220: Too big adjustment 32
kern.log:Mar 15 13:39:06 stacja kernel: [22003.714642] ALSA
hda_intel.c:1220: Too big adjustment 32
......
kern.log:Mar 15 13:42:41 stacja kernel: [22218.254581] ALSA
hda_intel.c:1220: Too big adjustment 32
kern.log:Mar 15 13:42:41 stacja kernel: [22218.275689] ALSA
hda_intel.c:1220: Too big adjustment 32
kern.log:Mar 15 13:59:01 stacja kernel: [   22.431420] HDA Intel
0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16
kern.log:Mar 15 13:59:01 stacja kernel: [   22.577821] ALSA
hda_codec.c:3441: hda_codec: model 'auto' is selected
kern.log:Mar 15 13:59:01 stacja kernel: [   22.577828] ALSA
hda_codec.c:4356: autoconfig: line_outs=1 (0x14/0x0/0x0/0x0/0x0)
kern.log:Mar 15 13:59:01 stacja kernel: [   22.577832] ALSA
hda_codec.c:4360:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
kern.log:Mar 15 13:59:01 stacja kernel: [   22.577835] ALSA
hda_codec.c:4364:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
kern.log:Mar 15 13:59:01 stacja kernel: [   22.577838] ALSA
hda_codec.c:4365:    mono: mono_out=0x0
kern.log:Mar 15 13:59:01 stacja kernel: [   22.577840] ALSA
hda_codec.c:4368:    dig-out=0x1e/0x0
kern.log:Mar 15 13:59:01 stacja kernel: [   22.577842] ALSA
hda_codec.c:4376:    inputs: mic=0x18, fmic=0x19, line=0x1a, fline=0x0,
cd=0x0, aux=0x0
kern.log:Mar 15 13:59:01 stacja kernel: [   22.579420] input: HDA Digital
PCBeep as /devices/pci0000:00/0000:00:14.2/input/input6
kern.log:Mar 15 13:59:01 stacja kernel: [   22.583527] HDA Intel
0000:01:05.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
kern.log:Mar 15 13:59:01 stacja kernel: [   22.583591] HDA Intel
0000:01:05.2: irq 27 for MSI/MSI-X

Unfortunately, the "azx_get_response timeout" logs occured before 2010-03-07
and were eaten by my logrotate script.


I've uploaded the alsa-info.sh data to the ALSA project hardware database:
http://www.alsa-project.org/db/?f=cf97d7cd4a29c306ddc6ca86a64842cb7cb9f634

My current module parameters are:
options snd-hda-intel model=auto probe_mask=1

I've also tried several other combinations, none of which really helped.
Here's my annotated modprobe config file, annotations explain which options
caused what effects. Unannotated entries simply didn't change much WRT to
the problem, apart from shuffling available mixer controls:


#options snd-hda-intel model=3stack-6ch
#options snd-hda-intel model=6stack-dig
# Advised at http://forum.ubuntu.pl/showthread.php?t=67236 :
#options snd-hda-intel model=acer-aspire
#options snd-hda-intel model=5stack
#options snd-hda-intel model=auto

# See http://www.kernel.org/pub/linux/kernel/people/tiwai/docs/HD-Audio.html,
"Codec-Probing Problem":
#options snd-hda-intel model=auto probe_mask=1
# doesn't help, "hda_intel: azx_get_response timeout, switching to
single_cmd mode" still happens. Upgrading kernel to 2.6.29.
# upgrading didn't help but the message disappeared.

# See
http://kerneltrap.org/mailarchive/git-commits-head/2008/7/14/2478124/thread
#options snd-hda-intel bdl_pos_adj=32 probe_mask=1 model=auto

# This conf still has capture problems (e.g. 2010-03-13):
options snd-hda-intel model=auto probe_mask=1

# This conf prevents audio from working at all:
#options snd-hda-intel model=auto probe_mask=8

# Needs testing:
#options snd-hda-intel model=auto probe_mask=1 position_fix=1

# Needs testing:
# http://www.linuxhardware.org/forums/viewtopic.php?t=9 :
#options snd-hda-intel model=3stack-6ch position_fix=1 bdl_pos_adj=0



<http://www.alsa-project.org/db/?f=cf97d7cd4a29c306ddc6ca86a64842cb7cb9f634>The
most important question for me now is whether the additional logging
statements from my patch will assist in debugging this problem?


On Sat, Oct 17, 2009 at 18:09, Aleksander Adamowski <alsa at olo.org.pl> wrote:

> BTW, Takashi, if that would be of any help, I could add some #ifdef's
> to the driver's code that would log additional information, if you
> could tell me what to log. It seems that the current log messages
> aren't detailed enough to diagnose the problem.
>
> For starters, I've added this:
>
> diff -ruN alsa-driver-20091017.orig/alsa-kernel/pci/hda/hda_intel.c
> alsa-driver-20091017/alsa-kernel/pci/hda/hda_intel.c
> --- alsa-driver-20091017.orig/alsa-kernel/pci/hda/hda_intel.c
> 2009-10-15 00:05:03.000000000 +0200
> +++ alsa-driver-20091017/alsa-kernel/pci/hda/hda_intel.c
> 2009-10-17 19:07:19.283328740 +0200
> @@ -1182,8 +1182,8 @@
>                                pos_align;
>                pos_adj = frames_to_bytes(runtime, pos_adj);
>                if (pos_adj >= period_bytes) {
> -                       snd_printk(KERN_WARNING SFX "Too big adjustment
> %d\n",
> -                                  bdl_pos_adj[chip->dev_index]);
> +                       snd_printk(KERN_WARNING SFX "Too big
> adjustment %d, pos_adj: %d, period_bytes: %d\n",
> +                                  bdl_pos_adj[chip->dev_index],
> pos_adj, period_bytes);
>                        pos_adj = 0;
>                } else {
>                        ofs = setup_bdle(substream, azx_dev,
>
>
> On Sat, Oct 17, 2009 at 2:57 PM, Aleksander Adamowski <alsa at olo.org.pl>
> wrote:
> > Concerning that problem, after a reboot the problem has reoccured two
> > days later:
> >
> > Oct 17 14:16:09 hostname kernel: [192087.249165] ALSA
> > hda_intel.c:1187: Too big adjustment 32
> > Oct 17 14:22:08 hostname kernel: [192447.072018] ALSA
> > hda_intel.c:1187: Too big adjustment 32
> > Oct 17 14:22:38 hostname kernel: [192477.062967] ALSA
> > hda_intel.c:1187: Too big adjustment 32
> > Oct 17 14:23:06 hostname kernel: [192504.918440] ALSA
> > hda_intel.c:1187: Too big adjustment 32
> > Oct 17 14:23:37 hostname kernel: [192535.594196] ALSA
> > hda_intel.c:1187: Too big adjustment 32
> >
> > Uploaded new alsa-info.sh data from the machine:
> >
> http://www.alsa-project.org/db/?f=e7e696254df6f61fa5e4755e9d1d06403dacf144
> >
> > Upgrading from alsa-driver-20091005 to alsa-driver-20091017 and will
> > let you know how it worked.
> >
> > On Wed, Oct 14, 2009 at 9:04 AM, Aleksander Adamowski <alsa at olo.org.pl>
> wrote:
> >
> >> After running for almost ten days with alsa-driver-20091005, I didn't
> >> observe that problem.
> >>
> >> However, a new one (well, one with slightly different symptoms) has
> surfaced.
> >>
> >> The difference is only in the log files.
> >> During a Skype conversation, the other side has stopped hearing us;
> >> after trying to record some sound with arecord, I got an empty stream
> >> (a 44 byte WAV file with only a header) - just like previously.
> >>
> >> However, this time there were no messages in the kernel logs
> >> whatsoever - no "azx_get_response timeout", no "Suggest a bigger
> >> bdl_pos_adj".
> >> Arecord also didn't flood the console with overrun errors - it was
> >> completely silent apart from the fact that it did not record anything.
> >>
> >> The only hda-related entries I saw in the kernel log were a couple
> >> hours earlier at 20:44 - while the failure has occured between 23:00
> >> and 00:00.
> >>
> >> At 20:44 the following has been logged:
> >>
> >> Oct 13 20:44:25 hostname kernel: [117828.065069] ALSA
> >> hda_intel.c:1187: Too big adjustment 32
> >> Oct 13 20:44:25 hostname kernel: [117828.073562] ALSA
> >> hda_intel.c:1187: Too big adjustment 32
> >> Oct 13 20:44:25 hostname kernel: [117828.083367] ALSA
> >> hda_intel.c:1187: Too big adjustment 32
> >> Oct 13 20:44:25 hostname kernel: [117828.578958] ALSA
> >> hda_intel.c:1187: Too big adjustment 32
> >> Oct 13 20:44:25 hostname kernel: [117828.584872] ALSA
> >> hda_intel.c:1187: Too big adjustment 32
> >> Oct 13 20:44:25 hostname kernel: [117828.592909] ALSA
> >> hda_intel.c:1187: Too big adjustment 32
> >> Oct 13 20:44:25 hostname kernel: [117828.651513] ALSA
> >> hda_intel.c:1187: Too big adjustment 32
> >> Oct 13 20:44:25 hostname kernel: [117828.657009] ALSA
> >> hda_intel.c:1187: Too big adjustment 32
> >> Oct 13 20:44:25 hostname kernel: [117828.665794] ALSA
> >> hda_intel.c:1187: Too big adjustment 32
> >>
> >> The machine is currently still in the failed state - I cannot record
> >> anything until I reboot.
> >>
> >>
> >> --
> >> Best Regards,
> >>  Aleksander Adamowski
> >>  http://olo.org.pl
> >>
> >
> >
> >
> > --
> > Best Regards,
> >  Aleksander Adamowski
> >  http://olo.org.pl
> >
>
>
>
> --
> Best Regards,
>  Aleksander Adamowski
>  http://olo.org.pl
>



-- 
Best Regards,
 Aleksander Adamowski
 http://olo.org.pl


More information about the Alsa-devel mailing list