On Fri, 2012-05-04 at 11:05 +0200, David Henningsson wrote:
When an IRQ for some reason gets lost, we wait up to a second using udelay, which is CPU intensive. This patch improves the situation by waiting about 30 ms in the CPU intensive mode, then stepping down to using msleep(2) instead. In essence, we trade some granularity in exchange for less CPU consumption when the waiting time is a bit longer.
As a result, PulseAudio should no longer be killed by the kernel for taking up to much RT-prio CPU time. At least not for *this* reason.
Signed-off-by: David Henningsson david.henningsson@canonical.com
sound/pci/hda/hda_intel.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
Hi Arun,
Can you check if this patch resolves your problem with PulseAudio getting killed by the kernel? If so, we should apply it to the kernel, perhaps even to stable.
// David
Thanks, this fixes the problem for me. Don't know what the official procedure for these things is, but fwiw:
Signed-off-by: Arun Raghavan arun.raghavan@collabora.co.uk
diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 7b6a823..0e7c3f1 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -783,11 +783,13 @@ static unsigned int azx_rirb_get_response(struct hda_bus *bus, { struct azx *chip = bus->private_data; unsigned long timeout;
unsigned long loopcounter; int do_poll = 0;
again: timeout = jiffies + msecs_to_jiffies(1000);
- for (;;) {
- for (loopcounter = 0;; loopcounter++) { if (chip->polling_mode || do_poll) { spin_lock_irq(&chip->reg_lock); azx_update_rirb(chip);
@@ -803,7 +805,7 @@ static unsigned int azx_rirb_get_response(struct hda_bus *bus, } if (time_after(jiffies, timeout)) break;
if (bus->needs_damn_long_delay)
if (bus->needs_damn_long_delay || loopcounter > 3000) msleep(2); /* temporary workaround */