List: linux-video Subject: [video4linux] Long standing bttv bug From: alan () lxorguk ! ukuu ! org ! uk (Alan Cox) Date: 1998-08-29 1:54:24 I've been hunting this one for a while. There is a long standing bttv problem with some cirrus cards and acceleration and another about mode switches. In both cases the bttv stops capturing video but is otherwise ok. I finally pinned it down Both are PCI stopping the DMA engine. IRQ_SCERR is asserted. The driver recovery code fails to work at this point. Until the module is reloaded capture will not continue. All other functions work fine. Alan ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] Long standing bttv bug From: alexb () jetsuite ! com (Bakaev, Alex) Date: 1998-08-29 1:30:24 If I remember correctly, Cirrus guys ( and S3 too ) had to implement some swich in their display driver under Windows so we could turn it on and off when 848 was capturing ( has to do with how they handle PCI bus ). I'll see if that info can be released somehow. Alex Alan Cox wrote: > > I've been hunting this one for a while. There is a long standing bttv > problem with some cirrus cards and acceleration and another about > mode switches. In both cases the bttv stops capturing video but is > otherwise ok. > > I finally pinned it down > > Both are PCI stopping the DMA engine. IRQ_SCERR is asserted. The driver > recovery code fails to work at this point. Until the module is reloaded > capture will not continue. All other functions work fine. > > Alan > > ------------ > To unsubscribe from this list send mail to majordomo@phunk.org with the > line "unsubscribe video4linux" without the quotes in the body of the > message. ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] Long standing bttv bug From: alan () lxorguk ! ukuu ! org ! uk (Alan Cox) Date: 1998-08-29 2:31:42 > If I remember correctly, Cirrus guys ( and S3 too ) had to implement > some swich in their display driver under Windows so we could turn it on > and off when 848 was capturing ( has to do with how they handle PCI bus > ). I'll see if that info can be released somehow. S3 seems to be fine, as do the later Cirrus. The problem that needs fixing isnt so much the SCERR as the fact the bttv driver isnt recovering from it. Losing a frame now and then to a bitblt is fine. Having to reload the driver is less cool. For the Cirrus you can tell the Xserver not to use acceleration, and sent the memory fifos down to leave more bandwidth (tho at 1024x768 on the 5430 you lose anyway looking at the docs) Alan ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: [video4linux] BTTV bugs part 2 From: Alan Cox <alan () cymru ! net> Date: 1998-08-30 17:33:26 I finally had time to play with a bttv setup on a non Linux box and did a bit more testing. We've got another extremely obvious bug at least on the PAL Hauppauge. Under Lose95 the video is tracking subtle frequency shifts, under Linux they cause the device to lose sync and often video capture until you detune and retune it. The easy way to demo this is to warm up a bttv card while watching TV . Once you do it under both OS's its very obvious the Linux driver has bad problems with something in the tuning. Alan ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] BTTV bugs part 2 From: "Michael H. Warfield" <mhw () wittsend ! com> Date: 1998-08-30 18:42:43 Alan Cox enscribed thusly: > I finally had time to play with a bttv setup on a non Linux box and did > a bit more testing. We've got another extremely obvious bug at least on > the PAL Hauppauge. > Under Lose95 the video is tracking subtle frequency shifts, under Linux > they cause the device to lose sync and often video capture until you detune > and retune it. > The easy way to demo this is to warm up a bttv card while watching TV . > Once you do it under both OS's its very obvious the Linux driver has bad > problems with something in the tuning. Warming up? Hmmm... Is this implying that the Hauppauge is performing some sort of AFC which the bttv driver is failing to enable or is the Lose95 driver tracking some sort of PLL error and trimming the frequency setting periodically? The difference could be significant. When you say "subtle frequency shifts", I assume that you are referring to subtle frequency shifts in the tuner which is probably originating in thermal drift in the tuner PLL reference oscillator. That would cause the frequency to drift even though the PLL divisors remained the same. An AFC might apply a corrective bias to the PLL or the frequency reference directly. Manual correction would be to note the PLL error and adjust the divisors to comphensate. Side note: I'm not using the Hauppage board, but I find the problem interesting. My setup is an STB board on an NTSC cable system. That has been pretty stable to date... > Alan Mike -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.
List: linux-video Subject: Re: [video4linux] BTTV bugs part 2 From: Alan Cox <alan () cymru ! net> Date: 1998-08-30 20:00:19 > Warming up? Hmmm... Is this implying that the Hauppauge is > performing some sort of AFC which the bttv driver is failing to enable or > is the Lose95 driver tracking some sort of PLL error and trimming the > frequency setting periodically? The difference could be significant. Not sure. > When you say "subtle frequency shifts", I assume that you are > referring to subtle frequency shifts in the tuner which is probably > originating in thermal drift in the tuner PLL reference oscillator. > That would cause the frequency to drift even though the PLL divisors > remained the same. An AFC might apply a corrective bias to the PLL or > the frequency reference directly. Manual correction would be to note the > PLL error and adjust the divisors to comphensate. The actual behaviour I see in these circumstances is that the picture latches when you hit the channel but then slips off channel, or at least the video sync is lost. Retuning down and back up recovers it - its like the AFC is only being applied while the tune in occurs not afterwards On Lose95 the picture is held reliably ------------ To unsubscribe from this list send mail to majordomo@phunk.org with the line "unsubscribe video4linux" without the quotes in the body of the message.