Hamish Moffatt wrote:
>
> > >>>bt878(0): irq FDSR risc_pc=2c4bd008
>
> > I applied both of the changes above and it fixes the problem. ie:
>
> It prevents the lockup, but do you get data stream corruption when the
> (now masked) interrupts occur? The buffers in the BT878 overflowed
> causing the interrupt, and ignoring the interrupt won't prevent the
> buffers from overflowing.
Sure, you'll miss some packets. But they are already lost even if you
get a message in the log. Better a stream with some lost packets
than a full log and a complete stall.
> IMHO the BT878 buffer is too small, as it's not designed for this
> application.
I'm not that sure that it's the small audio dma fifo. It's half as
big as the video fifo but video dma has much more than double the
bandwidth and I've never seen the error with video dma. And both
are sitting in the same PCI slot.
My wild guess: maybe it's the MAX_LAT setting[1]. For the video dma
it's set to 10ms but for the audio channel its 64ms! I googled
around for some MAX_LAT info but I found not much. The only refer-
ences were pretty old and it seems that at that time no PCI-bridge
was honouring MAX_LAT. But what about modern chipsets? If they
really think that they could wait up to 64ms before giving the bus
to the bt878 audio dma channel then that explains everything.
Anybody got a manual for an ATIIXP?
Ciao, ET.
[1] I'm not talking about the latency register. I'm talking about
the read-only MIN_GNT/MAX_LAT registers.
