> 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. > I have run tuning scripts over night with different cvs versions and I'm fairly sure that the problem is around the area you mentioned before. Some thing that happend here: cvs diff -D 20051118 -D 20051119 However, it is a strange fault. Sometimes when I run with a newer cvs everything works fine for a while, but at some point, the problems start and then never goes away. I have yet to find a connection to when it happens. I will continue to look into it this weekend. Henrik
