Interrupt routing broken on TiBook IV with 2.6.21.x ?

Interrupt routing broken on TiBook IV with 2.6.21.x ?

[Christian Böhme]

Hi all,

With the availability of the stable 2.6.21.x kernels I recently started to
move over from OSS to ALSA for audio I/O.  Along with that move came the
surprise that not the simplest audio output works anymore (actually, this
was the case with the stable 2.6.20.x kernels and OSS already which I
therefore opted to avoid).

The problem I ran into is that no matter which application (speaker-test,
aplay, xmms, gxine) using either the native ALSA API or via the OSS
compatibility layer, none of these is able to sustain audio output for
more than 7 seconds.  In fact, most attempts max out at statistically one
second (with many even shorter than that).  After the signal at the output
jack died, the application appears to be blocking forever (it does not spin)
with no signs of ending its output.

I initially presented this problem on alsa-user@lists.sourceforge.net where
someone suggested that it might actually be caused by (broken) interrupt
routing for the built-in audio device.  This assumption may be supported
by the observation that once the sound previously produced by the application
(speaker-test in the simplest case) stopped being sent through the output
jack, no increase in the interrupt counter occurs.

An example output of /proc/interrupts on my machine looks like this (why
eth0 does not show up in this listing is beyond me):

            CPU0
  19:      39005   MPIC 1    Level     ide0
  20:         34   MPIC 1    Level     ide1
  25:     151785   MPIC 1    Level     VIA-PMU
  26:        131   MPIC 1    Level     keywest i2c
  27:          1   MPIC 1    Level     ohci_hcd:usb1
  28:          1   MPIC 1    Level     ohci_hcd:usb2
  30:        197   MPIC 1    Edge      PMac Output
  31:          1   MPIC 1    Edge      PMac Input
  40:          2   MPIC 1    Level     ohci1394
  42:          0   MPIC 1    Level     keywest i2c
  47:       7682   MPIC 1    Level     GPIO1 ADB
  48:      39571   MPIC 1    Level     radeon@pci:0000:00:10.0
  57:          0   MPIC 1    Level     eth1
  58:          1   MPIC 1    Level     yenta
  61:          1   MPIC 1    Edge      Sound Headphone Detection
BAD:          0


Has anyone any idea what causes the audio output to die prematurely ?


Cheers,
Christian

Re: Interrupt routing broken on TiBook IV with 2.6.21.x ?

[Benjamin Herrenschmidt]

> Has anyone any idea what causes the audio output to die prematurely ?

Nope... it can't be a routing problem since interrupt -is- routed (you
are getting it !) unless I missed some subtle breakage in the
device-tree.

Which exact tipb model is this ? (cat /proc/device-tree/model)

Cheers,
Ben.

Re: Interrupt routing broken on TiBook IV with 2.6.21.x ?

[Christian Böhme]

Benjamin Herrenschmidt wrote:

> Nope... it can't be a routing problem since interrupt -is- routed (you
> are getting it !)

Actually, these were the exact words from the ALSA developer.  For some
reason, however, the interrupt count does not increase after some (variable)
time.  It looks as if the ALSA code waits for but not receiving them.  After
a restart, an audio signal does leave the jack and the interrupt count
increases but only for about a second (sometimes more, often less).  No idea 
whether interrupts must be routed/are routable on this very machine I have at 
all ...

> Which exact tipb model is this ? (cat /proc/device-tree/model)

PowerBook3,5 of the 2002-11 release variety.

I stuck to OSS up to the 2.6.19.x kernels where everything (surprisingly)
``just worked''.  Then came the 2.6.20.x series and <root>/sound/oss/\
dmasound/dmasound_awacs.c started spitting out loads of ``tx-irq: xfer died -
patching it up...'' messages with stuttering audio output but nothing
different in their respective implementations from 2.6.19.x to 2.6.20.x.

Is there anything particular I can dive into myself to expedite finding the
cause of the problem without learning the full details of the PPC implemen-
tation ?


Cheers,
Christian

Re: Interrupt routing broken on TiBook IV with 2.6.21.x ?

[Benjamin Herrenschmidt]

On Mon, 2007-05-21 at 22:08 +0200, Christian Böhme wrote:
> Benjamin Herrenschmidt wrote:
> 
> > Nope... it can't be a routing problem since interrupt -is- routed (you
> > are getting it !)
> 
> Actually, these were the exact words from the ALSA developer.  For some
> reason, however, the interrupt count does not increase after some (variable)
> time.  It looks as if the ALSA code waits for but not receiving them.  After
> a restart, an audio signal does leave the jack and the interrupt count
> increases but only for about a second (sometimes more, often less).  No idea 
> whether interrupts must be routed/are routable on this very machine I have at 
> all ...

Or it could be the DMA channel going dead though I fail to see why it
would just start doing that now.

> > Which exact tipb model is this ? (cat /proc/device-tree/model)
> 
> PowerBook3,5 of the 2002-11 release variety.

Ok, I think I have access to one of these, I'll try to reproduce myself.

> I stuck to OSS up to the 2.6.19.x kernels where everything (surprisingly)
> ``just worked''.  Then came the 2.6.20.x series and <root>/sound/oss/\
> dmasound/dmasound_awacs.c started spitting out loads of ``tx-irq: xfer died -
> patching it up...'' messages with stuttering audio output but nothing
> different in their respective implementations from 2.6.19.x to 2.6.20.x.
> 
> Is there anything particular I can dive into myself to expedite finding the
> cause of the problem without learning the full details of the PPC implemen-
> tation ?

Not sure where to start :-) I'll first see if I can reproduce.

Cheers,
Ben.

Re: Interrupt routing broken on TiBook IV with 2.6.21.x ?

[Christian Böhme]

Benjamin Herrenschmidt wrote:

> Or it could be the DMA channel going dead though I fail to see why it
> would just start doing that now.

...

> Not sure where to start :-) I'll first see if I can reproduce.

It's not that I am not interested nor completely new to this, it's just that
I am currently a little short on time for things like these.  The last time
I checked, the Linux people have just started to make use of DMA maps, a
concept that other OS/architecture combos employed for years already.  Is
that what is used in the TiBooks to allocate DMA channels ?


Cheers,
Christian

Re: Interrupt routing broken on TiBook IV with 2.6.21.x ?

[Benjamin Herrenschmidt]

On Tue, 2007-05-22 at 00:47 +0200, Christian Böhme wrote:
> It's not that I am not interested nor completely new to this, it's just that
> I am currently a little short on time for things like these.  The last time
> I checked, the Linux people have just started to make use of DMA maps, a
> concept that other OS/architecture combos employed for years already.  Is
> that what is used in the TiBooks to allocate DMA channels ?

I'm not sure what you are talking about here. DMA mapping has existed in
linux for years.

Ben.

Re: Interrupt routing broken on TiBook IV with 2.6.21.x ?

[Christian Böhme]

Benjamin Herrenschmidt wrote:

> I'm not sure what you are talking about here. DMA mapping has existed in
> linux for years.

I do admit that it's been a while since that last look ;)  The topic came up
when discussing PCI and bus systems in general with micro/real-time kernel
people whom I assumed to be experts in this since they had Linux kernels
running on top of their scheduling scheme.  As it turned out, using an
abstraction such as a DMA map was a totally new concept to them.  They
even questioned the usefulness of such an approach.


Cheers,
Christian