Michael Krufky wrote: > Manu Abraham wrote: > >>>>> Michael Krufky wrote: >>>>> >>>>> bt878(0): irq FDSR risc_pc=2c4bd008 >>>>> bt878(0): irq FDSR risc_pc=2c4bd008 >>>>> bt878(0): irq SCERR risc_pc=2c4bd000 >>>>> bt878(0): irq FDSR risc_pc=2c4bd008 >>>>> [...] >>>>> bt878(0): irq FDSR risc_pc=2c4bd008 >>>>> bt878(0): irq FDSR risc_pc=2c4bd008 >>>>> bt878(0): IRQ lockup, cleared int mask >>>> >>>> >>>> Looks like you had too many a IRQ's due to FDSR errors, why don't >>>> you try ignoring the FBUS errors >>>> >>>> ie, >>>> >>>> card->irq_error_ignore = BT878_AFBUS | BT878_AFDSR | BT878_APABORT >>>> | BT878_ARIPERR | BT878_APPERR; >>>> >>>> you could try the same thing or whichever combination, but the >>>> basic idea is to reduce too many interrupts, since lockup >>>> you might like to try to add resync also, >>>> >>>> ie, >>>> >>>> card->op_sync_orin = BT878_RISC_SYNC_MASK; >>>> >>>> >>>> either both of them or a combination of them and see whether it >>>> still occurs. >>>> in the relevant section in dvb-bt8xx, similar to others. That will >>>> help you atleast to reduce the number or IRQ's >>> >>> >>> Manu- >>> >>> I applied both of the changes above and it fixes the problem. ie: >>> >>> diff -u -p -r1.49 dvb-bt8xx.c >>> --- linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c 10 Sep 2005 07:26:02 >>> -0000 1.49 >>> +++ linux/drivers/media/dvb/bt8xx/dvb-bt8xx.c 11 Sep 2005 19:19:26 >>> -0000 >>> @@ -828,8 +828,8 @@ static int dvb_bt8xx_probe(struct device >>> case BTTV_DVICO_FUSIONHDTV_5_LITE: >>> #endif >>> card->gpio_mode = 0x0400c060; >>> - card->op_sync_orin = 0; >>> - card->irq_err_ignore = 0; >>> + card->op_sync_orin = BT878_RISC_SYNC_MASK; >>> + card->irq_err_ignore = BT878_AFBUS | BT878_AFDSR | >>> BT878_APABORT | BT878_ARIPERR | BT878_APPERR; >>> break; >>> >>> #ifdef BTTV_TWINHAN_VP3021 >>> >>> Should I leave it this way, or should I bother trying to remove some >>> of those ignore cases, figuring out what's necessary and only keep >>> the bare minimum? >>> >> Just trim it to the requirement. If someone has problems later on add >> more of them. In some cases you can possibly do some error correction >> depending upon how severe it is. Well it's a painstaking procedure to >> do that. Well, if you have the time give it a shot and see, trying to >> do error correction. >> >> It is okay as it is too .. >> >>> I suspect that it is safe to keep it as it shown in the patch >>> above... Please confirm. >> >> >> Yes, no problems .. I use all of them for the DST. Most of the Fusion >> 878 based cards, use similar stuff, except that the GPIO connections >> would be different and hence a difference in the GPIO config. Some >> cards would tweak the RISC program too, but that is not very >> critical, but helps in optimal settings. >> >>> I wonder why Doug didnt have this problem. Do you think it might be >>> a quirk with my motherboard, causing those irq's ? >> >> >> It depends on the bus on which your cards sits.. Remember the old >> bttv and Avermedia problems ? Well it is the same, revisited. >> Some other bttv cards also might need that setting, also. >> >> If he has the card on a bus which is *relatively* free of data >> transfer, this case will not show up, but when you have all hardware >> onto a single PCI bus, the errors are shown highlighted. In this case >> you need to ignore some errors ! > > > I don't know what he's got, but I only have 1 pci slot in this > machine, and that's where the FusionHDTV5 Lite is. > Eventhough you have only a single PCI slot doesn't mean that is the only PCI peripheral. The motherboard will have it's set of resources too. It's like driving through a road jammed with traffic. So as the traffic get's wilder, imagination follows ... ;-) Manu