Most recent kernel where this bug did not occur: Distribution: Debian Testing Hardware Environment: Acer TravelMate 242 Software Environment: Kaffeine, Mplayer Problem Description: Unable to change to channel located in MUX2 when playing channel from MUX1 Steps to reproduce: plug in card, let it play with kaffeine etc...
Hi Obi, just tested with 2.6.20-mh1 and today's SVN version v4l-dvb-f21b24ec4e8f and I have to reopen this bug. pccard: CardBus card inserted into slot 0 PCI: Enabling device 0000:02:00.0 (0000 -> 0002) ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKF] -> GSI 10 (level, low) -> IRQ 10 PCI: Setting latency timer of device 0000:02:00.0 to 64 DVB: registering new adapter (pluto2). pluto2 0000:02:00.0: board revision 2.15 pluto2 0000:02:00.0: S/N 13320420103842 pluto2 0000:02:00.0: MAC 00:d0:16:01:5c:0c DVB: registering frontend 0 (Philips TDA10046H DVB-T)... tda1004x: setting up plls for 53MHz sampling clock tda1004x: timeout waiting for DSP ready tda1004x: found firmware revision 0 -- invalid tda1004x: trying to boot from eeprom tda1004x: timeout waiting for DSP ready tda1004x: found firmware revision 0 -- invalid tda1004x: waiting for firmware upload... tda1004x: found firmware revision 29 -- ok tda1004x: setting up plls for 53MHz sampling clock tda1004x: found firmware revision 29 -- ok spurious 8259A interrupt: IRQ7. pluto2 0000:02:00.0: overflow irq (1) pluto2 0000:02:00.0: overflow irq (1) pluto2 0000:02:00.0: overflow irq (1) pluto2 0000:02:00.0: overflow irq (1) pluto2 0000:02:00.0: overflow irq (1) pluto2 0000:02:00.0: overflow irq (1) pluto2 0000:02:00.0: overflow irq (1) pluto2 0000:02:00.0: overflow irq (1) pluto2 0000:02:00.0: overflow irq (1) pluto2 0000:02:00.0: overflow irq (1) tda1004x: setting up plls for 53MHz sampling clock tda1004x: found firmware revision 29 -- ok pluto2 0000:02:00.0: overflow irq (1) pluto2 0000:02:00.0: overflow irq (1) pluto2 0000:02:00.0: overflow irq (1) Now behavior is little bit different. I still see unable tune dvb, but when I press channel button again, firmware loads again and MUX is tuned. This is now everytime, but 3x from 10 tries. Can you verify? Please ignore overflow irq, there exist different bug opened for this issue. Michal
There were multiple DVB fixes picked upt from Mauro's tree around 2.6.22-rc5. Can you please try it and see if problem was addressed? Thanks.
Tested with dvb-Mercurial-b03a5545f8e1 and problem is still present :(
Still present in latest vanilla 2.6.23.11