Below is what the bt878 data book says about the PCI bug compatibilitymodes of the bt878 chip.The triton1 insmod option sets the EN_TBFX bit in the control register.The vsfx insmod option does the same for EN_VSFX bit.  If you havestability problems you can try if one of these options makes your boxwork solid.drivers/pci/quirks.c knows about these issues, this way these bits areenabled automagically for known-buggy chipsets (look at the kernelmessages, bttv tells you).HTH,  Gerd---------------------------- cut here --------------------------Normal PCI Mode---------------The PCI REQ signal is the logical-or of the incoming function requests.The inter-nal GNT[0:1] signals are gated asynchronously with GNT anddemultiplexed by the audio request signal. Thus the arbiter defaults tothe video function at power-up and parks there during no requests forbus access. This is desirable since the video will request the bus moreoften. However, the audio will have highest bus access priority. Thusthe audio will have first access to the bus even when issuing a requestafter the video request but before the PCI external arbiter has grantedaccess to the Bt879. Neither function can preempt the other once on thebus. The duration to empty the entire video PCI FIFO onto the PCI bus isvery short compared to the bus access latency the audio PCI FIFO cantolerate.430FX Compatibility Mode------------------------When using the 430FX PCI, the following rules will ensurecompatibility:  (1) Deassert REQ at the same time as asserting FRAME.  (2) Do not reassert REQ to request another bus transaction until after     finish-ing the previous transaction.Since the individual bus masters do not have direct control of REQ, asimple logical-or of video and audio requests would violate the rules.Thus, both the arbiter and the initiator contain 430FX compatibilitymode logic. To enable 430FX mode, set the EN_TBFX bit as indicated inDevice Control Register on page 104.When EN_TBFX is enabled, the arbiter ensures that the two compatibilityrules are satisfied. Before GNT is asserted by the PCI arbiter, thisinternal arbiter may still logical-or the two requests. However, oncethe GNT is issued, this arbiter must lock in its decision and now routeonly the granted request to the REQ pin. The arbiter decision lockhappens regardless of the state of FRAME because it does not know whenFRAME will be asserted (typically - each initiator will assert FRAME onthe cycle following GNT). When FRAME is asserted, it is the initiator sresponsibility to remove its request at the same time. It is thearbiters responsibility to allow this request to flow through to REQ andnot allow the other request to hold REQ asserted. The decision lock maybe removed at the end of the transaction: for example, when the bus isidle (FRAME and IRDY). The arbiter decision may then continueasynchronously until GNT is again asserted.Interfacing with Non-PCI 2.1 Compliant Core Logic-------------------------------------------------A small percentage of core logic devices may start a bus transactionduring the same cycle that GNT is de-asserted. This is non PCI 2.1compliant. To ensure compatibility when using PCs with these PCIcontrollers, the EN_VSFX bit must be enabled (refer to Device ControlRegister on page 104). When in this mode, the arbiter does not pass GNTto the internal functions unless REQ is asserted. This prevents a bustransaction from starting the same cycle as GNT is de-asserted. Thisalso has the side effect of not being able to take advantage of busparking, thus lowering arbitration performance. The Bt879 drivers mustquery for these non-compliant devices, and set the EN_VSFX bit only ifrequired.