[linux-dvb] dvb_udb_digitv : Unable to handle kernel paging request...

Andy Clark list.linux-dvb at dairylogic.co.uk
Mon Oct 24 11:28:20 CEST 2005


Andy Clark wrote:

>Patrick Boettcher wrote:
>  
>
>>>>>I'm experiencing a problem with a newly-bought Nebula uDigiTV USB2 box.
>>>>>
>>>>>          
>>>>>
>>>>>Oct 19 23:48:52 vim kernel: >>> 02 7f 01 00 00 00 00
>>>>>Oct 19 23:48:52 vim kernel: <<< 02 7f 01 8a 00 00 00
>>>>>Oct 19 23:48:52 vim kernel: >>> 02 73 01 00 00 00 00
>>>>>Oct 19 23:48:52 vim kernel: <<< 02 73 01 8a 00 00 00
>>>>>          
>>>>>
>>>
>>>Here we have it: When trying to identify the mt352 (0x7f) it gets 0x8a
>>>(whereas 0x13 is expected). Same for nxt6000: 0x0b expected, 0x8a
>>>delivered.
>>>
>>>So either you have a new very new device with an unkown demod inside,
>>>or your box is broken  :) . Does it work in windows?
>>>
>>>      
>>>
>> 
>>
>>    
>>
>
>I've not yet tested it in Windows, but I will do so this evening. The
>box is actually a uDigiTV, rather than a master, and it occurs to me
>that this might be the cause of the problem. However, from what I read
>about the two types of decoder, it was my understanding that the main
>difference was that the master device comes with an IR interface and
>with Windows software for recording, whereas the slave doesn't.
>
>  
>
I have now tested the box in Windows, and it works.

It's a uDigiTV slave unit
(<http://www.nebula-electronics.com/information/info.asp?Code=0007>)
which means that it needs a uDigiTV master USB box or a PCI version for
the Windows software to function correctly. I have a DigiTV PCI card, so
I was able to get the USB slave device to work in Windows.

In addition, I've also confirmed that the box will work in Linux,
provided that I first boot to Windows. After doing so, I can switch back
to Linux, and I receive the following messages :-

Oct 22 19:50:18 vim kernel: check for cold 547 201
Oct 22 19:50:18 vim kernel: dvb-usb: found a 'Nebula Electronics uDigiTV
DVB-T USB2.0)' in warm state.
Oct 22 19:50:18 vim kernel: dvb-usb: will pass the complete MPEG2
transport stream to the software demuxer.
Oct 22 19:50:18 vim kernel: DVB: registering new adapter (Nebula
Electronics uDigiTV DVB-T USB2.0)).
Oct 22 19:50:19 vim kernel: >>> 02 7f 01 00 00 00 00
Oct 22 19:50:19 vim kernel: <<< 02 7f 01 13 00 00 00
Oct 22 19:50:19 vim kernel: DVB: registering frontend 0 (Zarlink MT352
DVB-T)...
Oct 22 19:50:19 vim kernel: dvb-usb: Nebula Electronics uDigiTV DVB-T
USB2.0) successfully initialized and connected.
Oct 22 19:50:19 vim kernel: >>> 08 00 04 01 00 00 00
Oct 22 19:50:19 vim kernel: >>> 07 00 04 00 00 00 00
Oct 22 19:50:19 vim kernel: usbcore: registered new driver dvb_usb_digitv

After doing so, I can obtain a lock with tzap, and MythTV is able to
access and record correctly.

If I then power-cycle the USB box, I'm back to the original behaviour.
The firmware loads in Linux, and the box responds :-

Oct 19 23:48:52 vim kernel: >>> 02 7f 01 00 00 00 00
Oct 19 23:48:52 vim kernel: <<< 02 7f 01 8a 00 00 00
Oct 19 23:48:52 vim kernel: >>> 02 73 01 00 00 00 00
Oct 19 23:48:52 vim kernel: <<< 02 73 01 8a 00 00 00


Considering the above, my first guess would be that the uDigiTV slave
device uses firmware different to that provided by dvb-linux, and that
Windows is providing the correct firmware. Can anyone advise how I can
identify and extract the firmware supplied to the box when running Windows?

As it stands, I'm using the box on my PVR. However, my dual-boot
workstation is in a different room to the PVR, so getting the DVB
decoder working involves a long power extention cable and a powered USB
hub. :)

I'm happy to perform further testing to improve native Linux support for
the decoder. Let me know.

Many thanks,

Andy Clark.



More information about the linux-dvb mailing list