HVR-900H dvb-t regression(s)

PATCH Fabio M. Di Nitto 2 participants 6 messages Nov 28, 2011 – Nov 29, 2011 Media (V4L/DVB)

Share & tools

Fabio M. Di Nitto

author

2011-11-28 14:41 UTC #0 lore raw

Hi all,

short summary is that dvb-t on $subject doesn´t work with head of the tree (for_3.3 branch) and scan or mplayer stop working.

Here is the breakdown of what I found with all logs. Please let me know if you need any extra info. Can easily test patches and gather more logs if necessary.

Also please note that I am no media guru of any kind. I had to work on some assumptions from time to time.

Based on git bisect:

The last known good commit is e872bb9a7ddfc025ed727cc922b0aa32a7582004

The first known bad commit is f010dca2e52d8dcc0445d695192df19241afacdb

commit f010dca2e52d8dcc0445d695192df19241afacdb

Author: Stefan Ringel <[email protected]>
Date:   Mon May 9 16:53:58 2011 -0300

[media] tm6000: move from tm6000_set_reg to tm6000_set_reg_mask

move from tm6000_set_reg to tm6000_set_reg_mask

Signed-off-by Stefan Ringel <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

While this commit appears rather innocent, it changes the way some registries are set.

the original code did:

read_reg...
change value
write_reg.. (unconditionally)

the new code path:

read_reg...
calculate new value
check if it is same
if not, write_reg...

So I did the simplest test as possible by removing the conditional in tm6000_set_reg_mask and dvb-t started working again.

something along those lines:

(quoted diff) +0 -0

b/drivers/media/video/tm6000/tm6000-core.c
index 9783616..818f542 100644

drivers/media/video/tm6000/tm6000-core.c +0 -0

@@ -132,8 +132,8 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8

req, u16 value,

        new_index = (buf[0] & ~mask) | (index & mask);

- if (new_index == index)
- return 0;
+// if (new_index == index)
+// return 0;

return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR,
req, value, new_index, NULL, 0);

but moving this change to the HEAD of for_v3.3 doesn´t solve the problem, possibly hinting to multiple regressions in the driver but at this point I am slightly lost because i can´t figure out what else is wrong. Some semi-random git bisect didn´t bring me anywhere useful at this point.

In an poor attempt to be a good boy, I collected all the data here:
http://fabbione.fedorapeople.org/dvblogs.tar.xz
(NOTE: 76MB file, 101MB unpacked)

The file contains 5 dirs:

last-known-good-e872bb9a7ddfc025ed727cc922b0aa32a7582004 first-known-bad-f010dca2e52d8dcc0445d695192df19241afacdb test1-change-set-reg-mask-f010dca2e52d8dcc0445d695192df19241afacdb+ head-known-bad-7e5219d18e93dd23e834a53b1ea73ead19cfeeb1 test2-change-set-reg-mask-7e5219d18e93dd23e834a53b1ea73ead19cfeeb1+

and each directory has:

dmesg
scan_results
tcpdump (tcpdump -i usbmod1 -w tcpdump)
usbmon0u (cat /sys.... > usbmod0u)

captures are started before modprobe tm6000-dvb and stop after a "scan -a 0 dk"

The testX are marked "+" as they contain the workaround mentioned above (test1 also adds a build workaround fixed a few commits later in the tree to unexport a symbol).

Thanks
Fabio

Mauro Carvalho Chehab

2011-11-28 21:07 UTC #1 lore raw

Quoted 68 lines · Fabio M. Di Nitto

Hi all,
short summary is that dvb-t on $subject doesn´t work with head of the tree (for_3.3 branch) and scan or mplayer stop working.
Here is the breakdown of what I found with all logs. Please let me know if you need any extra info. Can easily test patches and gather more logs if necessary.
Also please note that I am no media guru of any kind. I had to work on some assumptions from time to time.
Based on git bisect:
The last known good commit is e872bb9a7ddfc025ed727cc922b0aa32a7582004
The first known bad commit is f010dca2e52d8dcc0445d695192df19241afacdb
commit f010dca2e52d8dcc0445d695192df19241afacdb
Author: Stefan Ringel<[email protected]>
Date:   Mon May 9 16:53:58 2011 -0300
[media] tm6000: move from tm6000_set_reg to tm6000_set_reg_mask
move from tm6000_set_reg to tm6000_set_reg_mask
Signed-off-by Stefan Ringel<[email protected]>
Signed-off-by Mauro Carvalho Chehab<[email protected]>
While this commit appears rather innocent, it changes the way some registries are set.
the original code did:
read_reg...
change value
write_reg.. (unconditionally)
the new code path:
read_reg...
calculate new value
check if it is same
if not, write_reg...
So I did the simplest test as possible by removing the conditional in tm6000_set_reg_mask and dvb-t started working again.
something along those lines:
drivers/media/video/tm6000/tm6000-core.c +2 -2
index 9783616..818f542 100644
@@ -132,8 +132,8 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8
 req, u16 value,
 
         new_index = (buf[0]&  ~mask) | (index&  mask);
 
-       if (new_index == index)
-               return 0;
+//     if (new_index == index)
+//             return 0;
 
         return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR,
                                       req, value, new_index, NULL, 0);

Quoted 5 lines

but moving this change to the HEAD of for_v3.3 doesn´t solve the problem, possibly hinting to multiple regressions in the driver but at this point I am slightly lost because i can´t figure out what else is wrong. Some semi-random git bisect didn´t bring me anywhere useful at this point.

Hmm... It occurred to me that HVR-900H has a bug at device initialization. Sometimes, after a device connect it can't read anything from eeprom. As result, it will print:

[ 7867.776612] tm6000: Found Generic tm6010 board
[ 7867.841177] tm6000 #1: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7867.958753] tm6000 #1: i2c eeprom 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7868.075698] tm6000 #1: i2c eeprom 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7868.193607] tm6000 #1: i2c eeprom 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7868.310546] tm6000 #1: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7868.427507] tm6000 #1: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7868.544442] tm6000 #1: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7868.662375] tm6000 #1: i2c eeprom 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7868.779319] tm6000 #1: i2c eeprom 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7868.896238] tm6000 #1: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7869.013195] tm6000 #1: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7869.130135] tm6000 #1: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7869.247069] tm6000 #1: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7869.363981] tm6000 #1: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7869.480948] tm6000 #1: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7869.597884] tm6000 #1: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[ 7869.707769] Device has eeprom but is currently unknown

and the device will be miss-detected.

You can fix it by forcing the driver to use "card=9" via modprobe option.

Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the audio issue with HVR-900H on analog mode.

Quoted 29 lines

In an poor attempt to be a good boy, I collected all the data here:
http://fabbione.fedorapeople.org/dvblogs.tar.xz
(NOTE: 76MB file, 101MB unpacked)
The file contains 5 dirs:
last-known-good-e872bb9a7ddfc025ed727cc922b0aa32a7582004 first-known-bad-f010dca2e52d8dcc0445d695192df19241afacdb test1-change-set-reg-mask-f010dca2e52d8dcc0445d695192df19241afacdb+ head-known-bad-7e5219d18e93dd23e834a53b1ea73ead19cfeeb1 test2-change-set-reg-mask-7e5219d18e93dd23e834a53b1ea73ead19cfeeb1+
and each directory has:
dmesg
scan_results
tcpdump (tcpdump -i usbmod1 -w tcpdump)
usbmon0u (cat /sys....> usbmod0u)
captures are started before modprobe tm6000-dvb and stop after a "scan -a 0 dk"
The testX are marked "+" as they contain the workaround mentioned above (test1 also adds a build workaround fixed a few commits later in the tree to unexport a symbol).
Thanks
Fabio

Fabio M. Di Nitto

author

2011-11-29 04:53 UTC #2 lore raw

Quoted 83 lines · Mauro Carvalho Chehab

Quoted 68 lines · Fabio M. Di Nitto
Hi all,
short summary is that dvb-t on $subject doesn´t work with head of the tree (for_3.3 branch) and scan or mplayer stop working.
Here is the breakdown of what I found with all logs. Please let me know if you need any extra info. Can easily test patches and gather more logs if necessary.
Also please note that I am no media guru of any kind. I had to work on some assumptions from time to time.
Based on git bisect:
The last known good commit is e872bb9a7ddfc025ed727cc922b0aa32a7582004
The first known bad commit is f010dca2e52d8dcc0445d695192df19241afacdb
commit f010dca2e52d8dcc0445d695192df19241afacdb
Author: Stefan Ringel<[email protected]>
Date:   Mon May 9 16:53:58 2011 -0300
[media] tm6000: move from tm6000_set_reg to tm6000_set_reg_mask
move from tm6000_set_reg to tm6000_set_reg_mask
Signed-off-by Stefan Ringel<[email protected]>
Signed-off-by Mauro Carvalho Chehab<[email protected]>
While this commit appears rather innocent, it changes the way some registries are set.
the original code did:
read_reg...
change value
write_reg.. (unconditionally)
the new code path:
read_reg...
calculate new value
check if it is same
if not, write_reg...
So I did the simplest test as possible by removing the conditional in tm6000_set_reg_mask and dvb-t started working again.
something along those lines:
drivers/media/video/tm6000/tm6000-core.c +2 -2
index 9783616..818f542 100644
@@ -132,8 +132,8 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8
 req, u16 value,
 
         new_index = (buf[0]&  ~mask) | (index&  mask);
 
-       if (new_index == index)
-               return 0;
+//     if (new_index == index)
+//             return 0;
 
         return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR,
                                       req, value, new_index, NULL, 0);
Quoted 5 lines
but moving this change to the HEAD of for_v3.3 doesn´t solve the problem, possibly hinting to multiple regressions in the driver but at this point I am slightly lost because i can´t figure out what else is wrong. Some semi-random git bisect didn´t bring me anywhere useful at this point.
Hmm... It occurred to me that HVR-900H has a bug at device initialization. Sometimes, after a device connect it can't read anything from eeprom. As result,
it will print:
[ 7867.776612] tm6000: Found Generic tm6010 board
[ 7867.841177] tm6000 #1: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 ................

[SNIP]

Quoted 3 lines

[ 7869.707769] Device has eeprom but is currently unknown
and the device will be miss-detected.

I don't think this was ever the case, but I can easily check the dmesg output that I collected.

Quoted 5 lines

You can fix it by forcing the driver to use "card=9" via modprobe option.
Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the audio issue with HVR-900H on analog mode.

Ok, I'll try to grab them. It appears that mail relay from linux-media to my inbox is not reliable.

As for the analog, I should be able to test it today.

Fabio

Mauro Carvalho Chehab

2011-11-29 11:36 UTC #3 lore raw

Quoted 84 lines · Fabio M. Di Nitto

Quoted 80 lines · Mauro Carvalho Chehab
Quoted 68 lines · Fabio M. Di Nitto
Hi all,
short summary is that dvb-t on $subject doesn´t work with head of the tree (for_3.3 branch) and scan or mplayer stop working.
Here is the breakdown of what I found with all logs. Please let me know if you need any extra info. Can easily test patches and gather more logs if necessary.
Also please note that I am no media guru of any kind. I had to work on some assumptions from time to time.
Based on git bisect:
The last known good commit is e872bb9a7ddfc025ed727cc922b0aa32a7582004
The first known bad commit is f010dca2e52d8dcc0445d695192df19241afacdb
commit f010dca2e52d8dcc0445d695192df19241afacdb
Author: Stefan Ringel<[email protected]>
Date:   Mon May 9 16:53:58 2011 -0300
[media] tm6000: move from tm6000_set_reg to tm6000_set_reg_mask
move from tm6000_set_reg to tm6000_set_reg_mask
Signed-off-by Stefan Ringel<[email protected]>
Signed-off-by Mauro Carvalho Chehab<[email protected]>
While this commit appears rather innocent, it changes the way some registries are set.
the original code did:
read_reg...
change value
write_reg.. (unconditionally)
the new code path:
read_reg...
calculate new value
check if it is same
if not, write_reg...
So I did the simplest test as possible by removing the conditional in tm6000_set_reg_mask and dvb-t started working again.
something along those lines:
drivers/media/video/tm6000/tm6000-core.c +2 -2
index 9783616..818f542 100644
@@ -132,8 +132,8 @@ int tm6000_set_reg_mask(struct tm6000_core *dev, u8
 req, u16 value,
 
          new_index = (buf[0]&   ~mask) | (index&   mask);
 
-       if (new_index == index)
-               return 0;
+//     if (new_index == index)
+//             return 0;
 
          return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR,
                                        req, value, new_index, NULL, 0);
Quoted 5 lines
but moving this change to the HEAD of for_v3.3 doesn´t solve the problem, possibly hinting to multiple regressions in the driver but at this point I am slightly lost because i can´t figure out what else is wrong. Some semi-random git bisect didn´t bring me anywhere useful at this point.
Hmm... It occurred to me that HVR-900H has a bug at device initialization. Sometimes, after a device connect it can't read anything from eeprom. As result,
it will print:
Quoted 3 lines
[ 7867.776612] tm6000: Found Generic tm6010 board
[ 7867.841177] tm6000 #1: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 ................

Quoted 7 lines

[SNIP]
Quoted 3 lines
[ 7869.707769] Device has eeprom but is currently unknown
and the device will be miss-detected.
I don't think this was ever the case, but I can easily check the dmesg output that I collected.

This may affect your bisect tests.

Quoted 7 lines

Quoted 4 lines
You can fix it by forcing the driver to use "card=9" via modprobe option.
Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the audio issue with HVR-900H on analog mode.
Ok, I'll try to grab them. It appears that mail relay from linux-media to my inbox is not reliable.

I've applied them yesterday.

Quoted 1 line

As for the analog, I should be able to test it today.

On the tests I've made yesterday after applying Stefan and my patches, analog is working fine. Audio got corrected by the patches for MSC (the audio standard used on NTSC and PAL-M). I tested here with both NTSC and PAL-M standards, and it worked as expected.

There are some fixes applied yesterday that are related to DTV. One of them fixes the alloc function call used for the DVB streaming buffer inside the USB stack:

- ret = usb_submit_urb(dvb->bulk_urb, GFP_KERNEL);
+ ret = usb_submit_urb(dvb->bulk_urb, GFP_ATOMIC);

The usage of GFP_KERNEL there may fail, causing failures at the DVB stream.

I'm now seeing if I can make the IR work on HVR-900H.

Regards,
Mauro

Fabio M. Di Nitto

author

2011-11-29 11:51 UTC #4 lore raw

Quoted 6 lines · Mauro Carvalho Chehab

Quoted 4 lines · Fabio M. Di Nitto
Quoted 3 lines
[ 7867.776612] tm6000: Found Generic tm6010 board
[ 7867.841177] tm6000 #1: i2c eeprom 00: 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 ................
[SNIP]

Quoted 8 lines

Quoted 6 lines
Quoted 3 lines
[ 7869.707769] Device has eeprom but is currently unknown
and the device will be miss-detected.
I don't think this was ever the case, but I can easily check the dmesg output that I collected.
This may affect your bisect tests.

The eeprom was never 00 all the way.

Quoted 11 lines

Quoted 9 lines
Quoted 6 lines
You can fix it by forcing the driver to use "card=9" via modprobe option.
Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the audio issue with HVR-900H on analog mode.
Ok, I'll try to grab them. It appears that mail relay from linux-media to my inbox is not reliable.
I've applied them yesterday.

tested them already, I sent the results in another email.

Quoted 12 lines

Quoted 2 lines
As for the analog, I should be able to test it today.
On the tests I've made yesterday after applying Stefan and my patches, analog is working fine. Audio got corrected by the patches for MSC (the audio standard used on NTSC and PAL-M). I tested here with both NTSC and PAL-M standards, and it worked as expected.
There are some fixes applied yesterday that are related to DTV. One of them fixes the alloc function call used for the DVB streaming buffer inside the USB stack:

Quoted 6 lines

- ret = usb_submit_urb(dvb->bulk_urb, GFP_KERNEL);
+ ret = usb_submit_urb(dvb->bulk_urb, GFP_ATOMIC);
The usage of GFP_KERNEL there may fail, causing failures at the DVB stream.
I'm now seeing if I can make the IR work on HVR-900H.

No luck with analog here, but I need to do more investigation as the source might be broken all together.

Fabio

Fabio M. Di Nitto

author

2011-11-29 11:49 UTC #5 lore raw

In reply to Mauro Carvalho Chehab

Quoted 2 lines · Mauro Carvalho Chehab

Btw, Stefan sent some fixes to the ML. I'll test if the patch solves the audio issue with HVR-900H on analog mode.

I just finished testing those ones and they seem to fix my specific issue.

There is still one thing that puzzles me, but maybe it´s just my misunderstanding on how dvb-t protocol works.

Quoted 13 lines

root@cerberus:~# scan -a 0 /home/fabbione/dk
scanning /home/fabbione/dk
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder 586000000 0 2 9 3 1 3 0
Quoted 1 line
Quoted 1 line
Quoted 1 line
tune to: 586000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE
0x0000 0x0065: pmt_pid 0x0065 DR -- DR1 (running) 0x0000 0x00d9: pmt_pid 0x0835 TV 2 -- TV 2 (Lorry) (running) 0x0000 0x01a1: pmt_pid 0x0191 DIGI-TV -- Hovedstaden (running) 0x0000 0x0066: pmt_pid 0x00c9 DR -- DR2 (running) 0x0000 0x006f: pmt_pid 0x0068 DR -- DR Synstolkning (running) 0x0000 0x0051: pmt_pid 0x0051 DIGI-TV -- OAD MUX1 (running) Network Name 'Mux1 kbhv-glx'
Quoted 1 line
Quoted 1 line
Quoted 1 line
tune to: 730000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE

Quoted 11 lines

WARNING: filter timeout pid 0x0011
WARNING: filter timeout pid 0x0000
WARNING: filter timeout pid 0x0010
dumping lists (6 services)
OAD MUX1:586000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:0:0:81 DR1:586000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:111:121:101 DR2:586000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:211:221:102 DR Synstolkning:586000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:111:122:111 TV 2 (Lorry):586000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:2111:2121:217 Hovedstaden:586000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE:411:421:417 Done.

In my dk file I only specify:

Quoted 6 lines

root@cerberus:~# cat /home/fabbione/dk
# Denmark, whole country
# Created from http://www.digi-tv.dk/Indhold_og_tilbud/frekvenser.asp
# and http://www.digi-tv.dk/Sendenettets_opbygning/
# T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
T 586000000 8MHz 2/3 NONE QAM64 8k 1/4 NONE

because for simple testing I don´t need to scan the whole spectrum.

Now, in some versions of the driver, it automatically picks up 730MHz (I know it´s a good frequency in the area as I get it at my home and shares the same channels as 586).

What I noticed is that sometimes it tunes and time outs, sometime it tunes and scan correctly, but with the latest driver from HEAD, it failed completely to tune with the usual error.
Not sure if this info might be relevant.

As for analog I am not able to even get scantv to find the channel broadcasted from the VCR. I´ll need to investigate if it´s a problem with the VCR/tuner/driver etc. (there is no analog broadcast in dk).

So far this is what I get:

Quoted 8 lines

scantv -n PAL-DK -f europe-west -c /dev/video0 -C /dev/null [global]
freqtab = europe-west
[defaults]
input = Television
norm = PAL-DK

Quoted 8 lines

ioctl: VIDIOC_S_CTRL(id=9963778;value=0): Inappropriate ioctl for device
ioctl: VIDIOC_S_CTRL(id=9963776;value=0): Inappropriate ioctl for device
ioctl: VIDIOC_S_CTRL(id=9963779;value=0): Inappropriate ioctl for device
ioctl: VIDIOC_S_CTRL(id=9963777;value=130): Inappropriate ioctl for device scanning channel list europe-west...
E2 ( 48.25 MHz): ioctl: VIDIOC_S_CTRL(id=9963785;value=1): Inappropriate ioctl for device
ioctl: VIDIOC_S_CTRL(id=9963785;value=0): Inappropriate ioctl for device no station

(repeat the above for every single channel and no channels found)

The result is pretty much the same with or without tm6000-dvb loaded.

Fabio