Henrik Sjoberg wrote: >>Henrik Sjoberg wrote: >> >> >> >>>I have started working on HLCI support for mythtv (for now without any >>>coordination with the mythtv project). When I last worked on it (a couple >>>of weeks ago) I managed to decode at least some encypted channels. >>> >>>I started looking into it again last week. However, I'm seeing problem >>>with the latest cvs (or any cvs since the merge) that I often don't get a >>>lock when tuning channels. when I revert to cvs from for example nov 11 >>>everthing works fine again. >>> >>> >>> >>> >>The only thing that is of considerable change is the addition of a >>MONOSHOT read of flags .. >> >>mode_flags & FE_TUNE_MODE_ONESHOT >> >>Can you check whether this condition becomes valid for you ? If it becomes >>valid, it will not read back the status from the frontend in this case and >>no lock. >>This condition should not ideally become valid, unless specified >>explicitly. >> >> >> >> > >The condition is not valid. >I have produced two logs using latest cvs, one where the fault occurs and >one where it does not. Both when I am tuning to the same channel. When >doing a diff between them, the first diff starts when I am to read the >reply from the lock command. > >(When using cvs from nov 11, the log file looks as the one that is ok.) > >Here is the diff between the two: > >[root@evermeet ~]# diff -pub /tmp/ok.log /tmp/error.log >--- /tmp/ok.log 2005-12-06 22:44:03.000000000 +0100 >+++ /tmp/error.log 2005-12-06 22:43:57.000000000 +0100 >@@ -8,9 +8,9 @@ evermeet kernel: dst_gpio_outb: mask=[00 > evermeet kernel: writing [ 09 00 0a 48 d0 07 00 08 00 c6 ] > evermeet kernel: dst_gpio_outb: mask=[ffffffff], enbb=[0000], outhigh=[0000] > evermeet kernel: read_dst: reply is 0xff >-evermeet kernel: dst_wait_dst_ready: dst wait ready after 74 >+evermeet kernel: dst_wait_dst_ready: dst wait ready after 1 > evermeet kernel: read_dst: reply is 0x9 >-evermeet kernel: 0x0 0xa 0x48 0xd0 0x32 0x80 0x47 0x0 0xdc >+evermeet kernel: 0x0 0xa 0x48 0xd0 0x7 0x0 0x8 0x0 0xc6 > evermeet kernel: dst_comm_init: Initializing DST. > evermeet kernel: dst_gpio_outb: mask=[ffffffff], enbb=[0001], outhigh=[0000] > evermeet kernel: rdc_reset_state: Resetting state machine >@@ -20,8 +20,8 @@ evermeet kernel: writing [ 00 05 00 00 0 > evermeet kernel: dst_gpio_outb: mask=[ffffffff], enbb=[0000], outhigh=[0000] > evermeet kernel: read_dst: reply is 0xff > evermeet kernel: dst_wait_dst_ready: dst wait ready after 1 >-evermeet kernel: read_dst: reply is 0xa >-evermeet kernel: 0x48 0xd0 0x46 0x80 0x47 0x0 0xd1 >+evermeet kernel: read_dst: reply is 0x0 >+evermeet kernel: 0x0 0x0 0xc 0x80 0x47 0x0 0x2d > evermeet kernel: dst_comm_init: Initializing DST. > evermeet kernel: dst_gpio_outb: mask=[ffffffff], enbb=[0001], outhigh=[0000] > evermeet kernel: rdc_reset_state: Resetting state machine >@@ -31,6 +31,5 @@ evermeet kernel: writing [ 00 05 00 00 0 > evermeet kernel: dst_gpio_outb: mask=[ffffffff], enbb=[0000], outhigh=[0000] > evermeet kernel: read_dst: reply is 0xff > evermeet kernel: dst_wait_dst_ready: dst wait ready after 1 >-evermeet kernel: read_dst: reply is 0xa >-evermeet kernel: 0x48 0xd0 0x4b 0x80 0x49 0x0 0xca >- >+evermeet kernel: read_dst: reply is 0x0 >+evermeet kernel: 0x0 0x0 0x4b 0x80 0x4b 0x0 0xea > >If anyone has any idea what the problem could be, please let me know. > > I will check this. No clue ATM. will post as soon as i find something. Manu
