Re: PCI devices causing machine lockups on SX164

[Andreas Johansson <ajo wopr campus luth se>]

On Fri, 31 Mar 2000, Ivan Kokshaysky wrote:

> On Fri, Mar 31, 2000 at 02:37:02AM +0200, Andreas Johansson wrote:
> > The Pyxis PCI chipset obviously doesn't comply to this, instead it lets
> > those devices make as long transfers as they like without any arbitration.
> > 
> Not correct. Cypress IDE DMA does affect the ISA bus, not PCI.
> For example, PCI audio cards work fine with Cypress IDE.

Would you care to explain just how the PCI Cypress device would only
affect the ISA bus?

Your example may very well hold true, but it does not prove your
theory. How much FIFO do you have in respective sound card, how
large transfers are done through the PCI->ISA bridge, etc. ?

> > If I do 64kB block DMA from the disk and
> > play audio at the same time, the audio output is garbled by FIFO underrun
> > in the audio card's DMA. It sounds a little as if the audio is played at
> > a too low and instable sample rate.
> 
> It's known problem with the Cypress chip. Try reducing BUSMASTER_TIMEOUT
> value in drivers/ide/cy82c693.c

Ok, you're right, the card doesn't do a full 64kB transfer, it only
transfers 0x50 32-bit words (I guess) per transfer. How many PCI cycles
this means, I don't know. Probably more.

Yes, I can fix my audio garbling by reducing the BUSMASTER_TIMEOUT to
0x14 and getting lousy IDE performance. 0x16 still gives me some audible
sound garbling.

This solution however is much worse than being able to set the PCI latency
of a device. The idea with the latency timer is that each busmastering
device may ATLEAST get X cycles for each PCI transfers and after this
other devices that wants to use the bus may interrupt the ongoing
transfer. If no device wants the bus, the first transfer may continue
until the master latency timeout occurs (i.e. 65280 PCI cycles with the
default PYXIS setting).

This means that in cases where only one device is using the bus, high
transfer rate is achieved. When some device needs frequent bus access, it
gets in to the penelty of transfer rate. I like this much better than
limiting all transfers!

> I don't know about bttv, but other hardware you listed should work fine
> with the latest kernels.

All devices work by them self, it's when I combine them I run into
problems.

> Ivan.

Thanks for pointing out the BUSMASTER_TIMEOUT define.

/Andreas