On 11/8/09, Devin Heitmueller <dheitmuel...@kernellabs.com> wrote:
> I think the next step at this point is for you to definitively find a
> use case that does not work with the latest v4l-dvb tip and Robert's
> patch, and include exactly what kernel you tested with and which board
> is having the problem (including the PCI or USB ID).
>
> At this point, your description seems a bit vague in terms of what is
> working and what is not. If you do the additional testing to narrow
> down specifically the failure case you are experiencing, I will see
> what I can do.
I'm trying to be as clear as I can.
We can forget about setups 1 and 2, they no longer have the messages
from the cxusb module that I originally reported, I can tune and run
signal level tests like [1].
I'm now looking at setup 3.
os: ubuntu karmic i386
kernel: 2.6.31-14-generic
v4l modules: hg identify returns "19c0469c02c3+ tip"
If I cold boot, I see no tuning issues at the kernel level. Details
of the test below.
The failure I was attempting to report is that
I am unable to tune with dvbscan or w_scan.
I think it is due to changes in the V4L API with respect to the versions
of these programs I have installed.
However I am able to tune with 'tzap'. I'm not entirely sure why tzap works,
but it does and it shows the v4l tip drivers are ok regarding the
issue originally
reported.
There are two further areas I am looking into.
1. If I *warm* boot the same setup, I see "dvb-usb: bulk message failed:"
in dmesg.
I am working on this still to try to get a clear report for you of when
and on which device it occurs. It will probably take me a week to get
back to you.
2. There may be differences in performance, in that:
2.6.31-14-generic+v4l+Rob shows worse Bit Error Rates than
2.6.31-14-generic+Rob
Again I have some work to do to clarify this.
It seems likely it is a separate issue from this thread.
> That said, I'm preparing a tree with Robert's patch since I am pretty
> confident at least his particular problem is now addressed.
I can see no obstacle to you going ahead with that. Thanks again.
Cheers
Vince
Test details:
I tune like this:
sudo strace -t -ff -F -o tzap.strace /usr/bin/tzap -a 0 -r -c
channels.conf "7 Digital(Seven Network)"
In dmesg I see the firmware being loaded but no other messages:
[ 1232.684884] usb 3-1: firmware: requesting xc3028-v27.fw
[ 1232.743698] xc2028 1-0061: Loading 80 firmware images from
xc3028-v27.fw, type: xc2028 firmware, ver 2.7
[ 1232.756391] xc2028 1-0061: Loading firmware for type=BASE F8MHZ
(3), id 0000000000000000.
[ 1237.332511] xc2028 1-0061: Loading firmware for type=D2633 DTV7
(90), id 0000000000000000.
[ 1237.416510] xc2028 1-0061: Loading SCODE for type=SCODE
HAS_IF_5260 (60000000), id 0000000000000000.
I can successfully tune each of the 4 tuners in this way. Each time I
run tzap on
a tuner I've not used before, dmesg shows the firmware loading ok.
[1] http://linuxtv.org/wiki/index.php/Testing_reception_quality
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
