I've got Ubuntu 8.04 with AC97 sound, this seems to be happening to me.
If I run the above script as root after resume from standby it reports
HDA TCSEL register needs correcting
But pcitweak doesn't seem to be available with hardy; neither is the
above script installed
--
snd-hda-intel: distor
** Also affects: linux-source-2.6.22 (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux-source-2.6.22 (Ubuntu)
Status: New => Fix Released
** Changed in: linux-source-2.6.20 (Ubuntu)
Status: Fix Committed => Won't Fix
--
snd-hda-intel: distorted sound after
Thanks TJ, that's much better :)
--
snd-hda-intel: distorted sound after resume, until the module is reloaded
https://bugs.launchpad.net/bugs/100114
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubunt
Nice work-around Willem!
I've enhanced your script to make it more modular. Users can install
this script and not have to check and set the PCI device ID as the
script will figure it out.
#!/bin/bash
# this file is /etc/acpi/resume.d/66-snd-hda-intel.sh
# workaround for HDA resume bug on 2.6.20 (
There is also a workaround that doesn't require patching the kernel, maybe this
is of help to someone experiencing the problem right now.
Create a file /etc/acpi/resume.d/66-snd-hda-intel.sh that contains:
#!/bin/sh
# workaround resume bug on 2.6.20 (fixed in .22)
# see https://bugs.launchpad.ne
I'd agree with you on the CPU start order.
To pinpoint the offending code, I instrumented some resume code with printk's
and an msleep(10) after them (HZ=1000), so the TCSEL timer can jump in and
report (it reports only when it detects a difference with the previous value).
Result from this kern
Changed status to "Fix Committed" now cause is known and patch is
available.
** Changed in: linux-source-2.6.20 (Ubuntu)
Status: Confirmed => Fix Committed
--
snd-hda-intel: distorted sound after resume, until the module is reloaded
https://bugs.launchpad.net/bugs/100114
You received this
I've tested the latest Gutsy kernel from git (2.6.22-8.18) and found it
doesn't suffer from this bug. In that, the 2nd CPU is started before the
PCI devices are resumed. After resume the HDA device PCI config shows
the TCSEL register is 0x00.
Therefore I'm attaching a patch against Feisty's 2.6.20
Is it significant that upon resume the 2nd CPU is resumed *after* PCI
config has been written back to the device and it has been reinitialised
by its driver? When cold-starting the CPU has been started before the
PCI device is configured.
See the attached log-file that compares the relevant sectio
What we should have made clear in the two comments above is that we
found by monitoring the PCI config space when the ALSA drivers weren't
loaded that the TCSEL value was still being changed to 0x07 from 0x0.
That was when we decided to implement a timer to find out when the value
was changing.
--
Here's another log that pinpoints to enabling CPU1 beyond doubt:
[9.868250] ALSA sound/pci/hda/hda_intel.c:796: hda-intel: timer: TCSEL=0
[9.908187] ALSA sound/pci/hda/hda_intel.c:796: hda-intel: timer: TCSEL=0
[9.924171] usb 5-8: new high speed USB device using ehci_hcd and address
OK, it seems we have identified the reason for this problem.
Willem and I worked together on tracing the value of TCSEL after resume.
The code that finally pinpointed the issue was a kernel timer started in
azx_resume() and stopped in azx_pcm_open() with a jiffie interval of 10,
which appears to e
kprobe results: nothing to see. The module (for source see attachment) just
monitors calls to pci_bus_write_config_*() so pci configuration writes that
bypass this function are not detected.
Hypothesis: a(nother) module or the kernel corrupts the pci configuration of
this device. Can a pci confi
azx_reset() is only called from azx_init_chip(), to which I added printk's; so
I don't think the hda driver does another initialisation. I'm currently writing
a kprobe on pci_bus_write_config_* to see if something else is writing. If
that's not the case, it may even be the hardware; that's possi
Sorry - I pasted the wrong line from 'config'!
I see what you mean about TCSEL being reset to 07 when a sound is
played, and when I do 'hexedt config' and change 0x44 to 0, the sound is
corrected - nice one.
So the question is, is there another chip reset operation between
azx_resume() and playba
Hmm I didn't clearly indicate the base of numbers, but I meant 68d=44h. And the
value of TCSEL is correctly put back at resume, but somehow it changes between
initialisation and start of playback; see attachment for tracing of TCSEL at
various places in hda_intel.c. It is interesting how its val
I'm afraid I'm seeing no difference here. I had previously checked TCSEL
because of the comment in the head of azx_init_chip(), and I had also
made sure that azx_resume() was called, and in-turn was calling
azx_init_chip().
I also put a check of the value of TCSEL in azx_init_chip() to see what
va
I hope I'm not spamming this bug with information; as the cause is somewhat
unclear, all these things may or may not be important in the end. There's two
kinds of config data: pci and memory mapped. PCI can be checked using sysfs,
About memory mapped registers. Find attached a dump of these befo
Ok, I tracked DPLBASE and posbuf before and after suspend/resume and they look
pretty similar. In both cases, the lowest bit of DPLBASE is set, so it should
report back the position. Before:
posbuf 0x340, lpibpos 0x294, posbuf=0x1b881020 DPLBASE=0x1b881001
posbuf 0xfe0, lpibpos 0xf40, posbuf=
A short overview of where posbuf is used in hda_intel.c:
In azx_init_chip():
azx_writel(chip, DPLBASE, (u32)chip->posbuf.addr);
azx_writel(chip, DPUBASE, upper_32bit(chip->posbuf.addr));
In azx_setup_controller():
// enable the position buffer
if (! (azx_readl(chip, DPLBASE) & ICH6_DPLB
Yes, I agree. I found some time yesterday to build the alsa-core and
snd-hda modules myself and have been watching the updating of the
hw_ptr_interrupt. I've attached the log. Also, the line
pos -= pos % runtime->min_align;
is, if you read it carefully, not intended to update pos but simply to
en
I don't think the line
pos -= pos % runtime->min_align;
updates the position buffer each time. You can see in posbuf-trace-01.txt that
runtime->min_align=1, so pos remains the same. I can find no place where posbuf
is updated, so I think the hardware does that. Before suspend, hardware and
s
Thanks for that report, it was just what I needed. I was already
tracking the various code responsible for updating posbuf and your trace
has confirmed some of what I was expecting. There are several reasons
why posbuf/pos won't be updated so we should try eliminating
possibilities.
In snd_pcm_upd
Wow, you've replied quite a lot already, here the answers to questions
you posed.
posbuf was reported in azx_pcm_pointer(), just after the line
pos = le32_to_cpu(*azx_dev->posbuf);
( http://lxr.linux.no/source/sound/pci/hda/hda_intel.c#L1215 )
I had another printk at read_lpib, but that one wasn
Reading this extract from the HDA PRM in conjunction with
azx_setup_controller() (note my ***...*** highlights) might suggest a
problem with "...the hardware may still have pre-fetched descriptors
that will not be flushed when the stream is restarted...":
4.6.6
After the RUN bit has been set, the
azx_setup_controller() is called azx_pcm_prepare():
snd_printdd("azx_pcm_prepare: bufsize=0x%x, fragsize=0x%x,
format=0x%x\n",
azx_dev->bufsize, azx_dev->fragsize, azx_dev->format_val);
azx_setup_periods(azx_dev);
azx_setup_controller(chip, azx_dev);
N
hda_intel.c:1392:
azx_init_stream() {
...
azx_dev->posbuf = (u32 __iomem *)(chip->posbuf.area + i * 8);
--
snd-hda-intel: distorted sound after resume, until the module is reloaded
https://bugs.launchpad.net/bugs/100114
You received this bug notification because you are a member of Ubuntu
B
Funny how you can arrive at the same point from different directions. I
noticed in your tracing that int_cnt had far more interrupts (for the
same file) just after resume than when the module had been freshly
loaded (389 vs 11) and had traced through to the posbuf from struct
azx_dev:
hda_intel.c:
Allright, I can see the DMA pointer not being updated. az_interrupt() calls
snd_pcm_period_elapsed(), where the position pointer is read using
snd_pcm_update_hw_ptr_pos(), which gets the current position from the driver:
azx_pcm_pointer() in our case. Printing pos shows that it its value remains
Oh cool! Someone else that knows how to hack :)
I've been reading the Intel HDA Programmers Reference Manual
(http://www.intel.com/design/chipsets/hdaudio.htm) and from what I've
learned so far the problem appears to be with the handling of the output
buffers. Here's the description of what should
Great to see some work on this! I'm not too familiar with DMA, but I'll
try to help a bit. I started to trace the DMA transfer process by
verifying that the interrupts are correctly setup after resume. It seems
this is working: azx_interrupt() is called a number of times
proportional to the length
I decided to track the interrupt/DMA enabling/disabling. I'll put my
notes here in case others want to investigate.
I analysed the sequence of operations in hda_intel.c::azx_suspend(),
azx_resume() and the device initialisation functions.
I noticed that azx_suspend() calls snd_hda_suspend() then
Re: unloading the module. It was in-use even after I stopped GDM and was
working from a console.
I've been debugging this issue and have made a little progress, albeit
not the kind we want.
The difference in the outputs reported here and in bug #55071 pre- and
post-suspend of codex#0 is not of co
What about the volume control? I removed the volume control applet from
my panel at the top of the screen; this is no problem since there are
special keys for the volume anyway. Running an audio application, or
even Firefox with a flash object may also prevent the module from
unloading; this is som
I'm hearing the same problem on a Sony Vaio VGN-FE41Z.
I read where you say "Unloading/reloading the snd-hda-intel module makes
the soundcard work again correctly". I've been unable to do that because
the module is always in-use although I don't know by what:
$ sudo modprobe -r snd-hda-intel
FATA
** Changed in: linux-source-2.6.20 (Ubuntu)
Assignee: (unassigned) => Ubuntu Kernel Team
Status: Unconfirmed => Confirmed
--
snd-hda-intel: distorted sound after resume, until the module is reloaded
https://bugs.launchpad.net/bugs/100114
You received this bug notification because you
ALSA bug https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2187 may
be related
--
snd-hda-intel: distorted sound after resume, until the module is reloaded
https://bugs.launchpad.net/bugs/100114
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug cont
37 matches
Mail list logo
