Re: [linux-dvb] Hauppauge Nova T-500 / Nova-TD Stick (DiBcom tuners/demods) - the plot thickens...

2008-03-06 Thread Philip Pemberton 
Henrik Beckman wrote:
> My TD stick never worked as it should in my Nforce 4, killed my USB 
> controllers.
> Worked ok on my VIA controller.

I've just tested it on an ASUS Eee PC (Intel chipset) and it seems to be fine, 
one tuner active and playing video, the other scanning for channels.

What I did find interesting was that it really doesn't like strong signals. I 
rigged it up on our test bench at work (we have a UK terrestrial feed that's 
trimmed to the same signal power around the building, +/- a few dB). I clocked 
the signal at 70.1dBuV with a Promax DVB analyser, and the Nova-TD refused to 
lock on -- the tuner locked, but no data flowed ("filter timeout pid..." from 
scandvb).

In fact, it only passed data along after I put 21dB worth of attenuators 
(three 3dBs and a pair of 6dBs) in line, bringing the signal strength down to 
48dBuV. The maximum signal strength that allowed any signal was 60.8dBuV...

Naturally, it's behaving itself with my aerial (pointed at Emley Moor) and 
doing a far better job than the Freecom USB stick I bought it to replace.

This is with Fedora 8, kernel 2.6.23.15-137.fc8. I've got a 2.6.23 kernel 
building on the Ubuntu box, and I'm digging through the Fedora patches in the 
2.6.23.15 kernel source RPM (and the kernel config) to see if there are any 
significant differences that might explain the issues with the T500 / TD.

> Not sure that stick is proved 100% stable.

Seems stable here...

Thanks,
-- 
Phil. |  (\_/)  This is Bunny. Copy and paste Bunny
[EMAIL PROTECTED]   | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] Hauppauge Nova T-500 / Nova-TD Stick (DiBcom tuners/demods) - the plot thickens...

2008-03-05 Thread Philip Pemberton 
Philip Pemberton wrote:
> [ 3097.541301] ep 0 write error (status = -19, len: 4)
> [ 3097.541302] dvb-usb: error while stopping stream.

Forgot to mention -- after this mess, both tuners on the Nova-TD were dead.

I restarted mythbackend and they woke up again, then as soon as I tuned to a 
channel both of them fell over again (USB disconnect).

I think the EMI thing might have been a one-off -- the second disconnect was a 
standard one, not a "hub has disabled the port".

-- 
Phil. |  (\_/)  This is Bunny. Copy and paste Bunny
[EMAIL PROTECTED]   | (='.'=) into your signature to help him gain
http://www.philpem.me.uk/ | (")_(") world domination.

___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] Hauppauge Nova T-500 / Nova-TD Stick (DiBcom tuners/demods) - the plot thickens...

2008-03-05 Thread Philip Pemberton 
Hi guys,
   I've just bought a Nova-TD stick to replace the Nova-T-500 (which really 
doesn't seem to want to play nice) and as soon as I enabled EIT scanning in 
MythTV, I got this in dmesg:

[ 2780.827260] >>> 02 81 01 f5
[ 2780.828753] <<< ff ff
[ 2780.828761] >>> 02 81 01 fa
[ 2780.830250] <<< 00 00
[ 2780.830550] modifying (1) streaming state for 0
[ 2780.830555] data for streaming: 10 11
[ 2780.830557] >>> 0f 10 11 00
[ 2780.831372] modifying (0) streaming state for 0
[ 2780.831377] data for streaming: 0 10
[ 2780.831378] >>> 0f 00 10 00
[ 2780.836076] modifying (1) streaming state for 0
[ 2780.836086] data for streaming: 10 11
[ 2780.836087] >>> 0f 10 11 00
[ 2780.842428] hub 6-0:1.0: port 1 disabled by hub (EMI?), re-enabling...
[ 2780.842436] usb 6-1: USB disconnect, address 2
[ 2780.842721] >>> 03 80 04 01 c0 00
[ 2780.842728] ep 0 write error (status = -19, len: 6)
[ 2780.842730] MT2266 I2C write failed
[ 2780.842732] >>> 03 80 04 01 c0 00
[ 2780.842735] ep 0 write error (status = -19, len: 6)
[ 2780.842737] MT2266 I2C write failed
[ 2780.842739] >>> 02 81 00 eb
[ 2780.842743] ep 0 read error (status = -19)
[ 2780.842744] <<< e0 93
[ 2780.842746] I2C read failed on address 40
[ 2780.842748] >>> 03 80 00 eb 00 32
[ 2780.842752] ep 0 write error (status = -19, len: 6)
[ 2780.842753] >>> 03 80 00 ec 07 00
[ 2780.842757] ep 0 write error (status = -19, len: 6)
[ 2780.842758] >>> 03 80 05 06 00 00
[ 2780.842762] ep 0 write error (status = -19, len: 6)
[ 2780.842764] >>> 02 81 05 00
[ 2780.842766] ep 0 read error (status = -19)
[ 2780.842768] <<< ac 1f
[ 2780.842770] I2C read failed on address 40
[ 2780.842771] >>> 03 80 03 06 ff ff
[ 2780.842775] ep 0 write error (status = -19, len: 6)
[ 2780.842776] >>> 03 80 03 07 ff ff
[ 2780.842780] ep 0 write error (status = -19, len: 6)
[ 2780.842781] >>> 03 80 03 08 00 07
[ 2780.842785] ep 0 write error (status = -19, len: 6)
[ 2780.842786] >>> 03 80 03 83 00 03
[ 2780.842790] ep 0 write error (status = -19, len: 6)
[ 2780.842791] >>> 03 80 05 00 8a 1f
[ 2780.842795] ep 0 write error (status = -19, len: 6)
[ 3097.541289] modifying (0) streaming state for 0
[ 3097.541294] data for streaming: 0 10
[ 3097.541295] >>> 0f 00 10 00
[ 3097.541301] ep 0 write error (status = -19, len: 4)
[ 3097.541302] dvb-usb: error while stopping stream.
[ 3383.815796] wifi0: rx FIFO overrun; resetting

First point: this is a DiB7000 based device, not a DiB3000 (which is what the 
Nova T-500 has on board -- that and a DiB0700 USB bridge).

Now what caught my eye was the

Now what I find interesting is the "disabled by hub (EMI?)" message -- the 
Nova-TD Stick is connected straight to the motherboard USB header via the 
short (6in) cable that came with the TD.

A quick Google search suggests this might be down to heavy data transfer on 
the USB bus -- the controller can't handle the mass of data (buffer 
overflow?), so it shuts down the port. The Kernel notices that the controller 
has killed the port and restarts it. Most of what I've found seems to point to 
issues with older kernels (2.6.20 RCs mainly) and/or SMP...

This suggests putting a hub in the way might help: 
http://forum.sparkfun.com/viewtopic.php?=&p=25520

And this suggests issues surfacing under high I/O / Ethernet activity: 
http://www.mail-archive.com/[EMAIL PROTECTED]/msg18069.html
Of course, the response was "no it's not a kernel bug, it's a bug with your 
device" (which is fair enough because 8/10 times it's NOT the kernel's fault, 
but in the other 2 times... :-/ )

The same thing was reported here with a DDR (Dance Dance Revolution?) pad... 
http://www.linuxquestions.org/questions/linux-hardware-18/usb-device-ddr-pad-keeps-disconnecting-596445/

The last one is interesting because if MythTV is grabbing the EIT, it'll be 
spooling the EIT data to RAM, then decoding it and saving it to the database. 
The database writes involve a good bit of disc access, and the data's going to 
be spooling in at ~20Mbit/sec from the DVB receiver. I wonder if the 
combination of lots of USB I/O, disc I/O, etc. is upsetting the kernel, or the 
USB controller (again - maybe the USB controller's buffer isn't getting 
flushed in time and is overflowing?)

Though that said, 2x20Mbit=40Mbit, which is still well below USB2 High Speed's 
claimed 480Mbit transfer limit. The data is going to be packed into USB data 
frames/packets though, and I suspect the chip will be sending it in 188-byte 
blobs (i.e. full transport stream packets).

I'm going to put my USB thumb-hub in the way (in unpowered mode) and see what 
happens. Given that I've never seen that bug in my syslog before today, and 
that the Fedora 7 / 8 stock kernels seem to be happy with it, I'd like to say 
"kernel bug", but equally I don't want to place the blame on something that is 
rarely the cause of a problem.

I'm also tempted to unplug the wireless card... that last "rx FIFO overrun" is 
making me somewhat suspicious.

-- 
Phil. |  (\_/)  This is B