Re: [linux-dvb] Re: [Patch] USBVision - Fix NT1005 Bridge detection
I agree too... I tested out both patches Mauro and trents patches. I did not
get any ops, and tested the patches for about three hours.I did not have
the device removed, so I would assume it the dummy device definition that's
causing the problem.
I vote that we should get rid of the dummy device. It's always caused a great
deal of headaches. We should probably set it up like the saa7134 devices.
- Original Message
From: Thierry MERLE [EMAIL PROTECTED]
To: Mauro Carvalho Chehab [EMAIL PROTECTED]
Cc: Dwaine Garden [EMAIL PROTECTED]; Linux and Kernel Video [EMAIL
PROTECTED]; Linux DVB linux-dvb@linuxtv.org
Sent: Saturday, April 14, 2007 1:26:19 PM
Subject: [linux-dvb] Re: [Patch] USBVision - Fix NT1005 Bridge detection
Mauro Carvalho Chehab a écrit :
Hi Dwaine and Thierry,
The patch seems to be ok. However, it is not nice to do this:
+ if ((!strcmp(usbvision_device_data[model].ModelString, Dazzle
Fusion Model DVC-90 Rev 1 (SECAM)))
Since, if for some reason, people decide to change the comment at
usbvision-cards, it will break the above code. Instead, it is better to
create a code for each board and for its value.
I've did such change on:
http://linuxtv.org/hg/~mchehab/usbvision
It also honors CodingStyle max line size.
I've also removed some duplicated stuff (ID Vendor/Product) and changed
some flags to use bitmap. As result, It saved about 1K of kernelspace
area.
I also noticed that the same name string were used for more than one
board. So, I've added a number for the duplicated names to avoid having
the same name for two different boards. It would be better, however, to
replace the duplicated definitions to a proper one, or to merge the
entries, if they are just referring to the same board.
May you test it and comment?
Acked-by: Thierry MERLE [EMAIL PROTECTED]
I agree totally with this simplification.
I am currently debugging the Trent's patch that makes a kernel oops and
I don't know why.
The usbvision_probe is called event if the device is not plugged, and
the kernel oops occurs on this piece of code:
model = devid-driver_info;
printk(KERN_INFO %s: %s found\n, __FUNCTION__,
usbvision_device_data[model].ModelString);
Memory alignment problem ? Why this probe is called even if there is no
device plugged-in ?
By putting something like:
model = devid-driver_info;
if(model0 || model HPG_WINTV) {
printk(KERN_INFO model out of bounds %d\n,model);
return -ENODEV;
} else printk(KERN_INFO model is %d\n,model);
The problem disappeared...
Regards,
Thierry
Apr 14 18:17:10 localhost kernel: BUG: unable to handle kernel paging
request at virtual address 0917ab30
Apr 14 18:17:10 localhost kernel: printing eip:
Apr 14 18:17:10 localhost kernel: c01d837b
Apr 14 18:17:10 localhost kernel: *pde =
Apr 14 18:17:10 localhost kernel: Oops: [#1]
Apr 14 18:17:10 localhost kernel: Modules linked in: usbvision videodev
tuner v4l2_common snd_pcm_oss snd_mixer_oss cpufreq_conservative
cinergyT2 dvb_core
mga drm ns558 analog joydev nvidia(P) snd_hda_intel snd_hda_codec
snd_pcm snd_timer snd snd_page_alloc
Apr 14 18:17:10 localhost kernel: CPU:0
Apr 14 18:17:10 localhost kernel: EIP:0060:[c01d837b]Tainted:
P VLI
Apr 14 18:17:10 localhost kernel: EFLAGS: 00210097 (2.6.21-rc6 #7)
Apr 14 18:17:10 localhost kernel: EIP is at vsnprintf+0x2d1/0x4d3
Apr 14 18:17:10 localhost kernel: eax: 0917ab30 ebx: c03f01b4 ecx:
0917ab30 edx: fffe
Apr 14 18:17:10 localhost kernel: esi: c75ebe7c edi: 000a ebp:
esp: c75ebd98
Apr 14 18:17:10 localhost kernel: ds: 007b es: 007b fs: 00d8 gs:
0033 ss: 0068
Apr 14 18:17:10 localhost kernel: Process modprobe (pid: 4759,
ti=c75ea000 task=e24e6520 task.ti=c75ea000)
Apr 14 18:17:10 localhost kernel: Stack: e7dde000 ead775e0 584da500
ead775e0 c03ef3e0 ead775e0
Apr 14 18:17:10 localhost kernel: c03f05a0 0400
c03f01a0 ed0edf6f 0400 eb9c6400 c03f01a0
Apr 14 18:17:10 localhost kernel:ea412fa0 c01d858f c75ebe74
e49c9b70 c0117ec8 c75ebe74 ebc3fc18 0001
Apr 14 18:17:10 localhost kernel: Call Trace:
Apr 14 18:17:10 localhost kernel: [c01d858f] vscnprintf+0x12/0x1d
Apr 14 18:17:10 localhost kernel: [c0117ec8] vprintk+0x4d/0x1f3
Apr 14 18:17:10 localhost kernel: [c0177830] __sysfs_new_dirent+0x12/0x40
Apr 14 18:17:10 localhost kernel: [c017791a]
__sysfs_make_dirent+0x11/0x6c
Apr 14 18:17:10 localhost kernel: [c0117e78] printk+0x16/0x19
Apr 14 18:17:10 localhost kernel: [ed0eaa40]
usbvision_probe+0x9a/0x3f6 [usbvision]
Apr 14 18:17:10 localhost kernel: [c02665e2]
usb_probe_interface+0x66/0x88
Apr 14 18:17:10 localhost kernel: [c022fc9c] really_probe+0x9c/0x12e
Apr 14 18:17:10 localhost kernel: [c0266893] usb_match_id+0x34/0x42
Apr 14 18:17:10 localhost kernel: [c022fde0]
driver_probe_device+0xa3/0xaf
Apr 14 18:17:10 localhost kernel:
[linux-dvb] Re: [Patch] USBVision - Fix NT1005 Bridge detection
I think usbvision_probe is called because of the dummy device code. We should
probably rethink the dummy device.
- Original Message
From: Thierry MERLE [EMAIL PROTECTED]
To: Mauro Carvalho Chehab [EMAIL PROTECTED]
Cc: Dwaine Garden [EMAIL PROTECTED]; Linux and Kernel Video [EMAIL
PROTECTED]; Linux DVB linux-dvb@linuxtv.org
Sent: Saturday, April 14, 2007 3:08:01 PM
Subject: Re: [Patch] USBVision - Fix NT1005 Bridge detection
Hi Mauro,
Mauro Carvalho Chehab a écrit :
Hi Thierry,
I am currently debugging the Trent's patch that makes a kernel oops and
I don't know why.
The usbvision_probe is called event if the device is not plugged, and
the kernel oops occurs on this piece of code:
model = devid-driver_info;
printk(KERN_INFO %s: %s found\n, __FUNCTION__,
usbvision_device_data[model].ModelString);
Memory alignment problem ? Why this probe is called even if there is no
device plugged-in ?
Very weird. It shouldn't be called when no device is plugged...
By putting something like:
model = devid-driver_info;
if(model0 || model HPG_WINTV) {
printk(KERN_INFO model out of bounds %d\n,model);
return -ENODEV;
} else printk(KERN_INFO model is %d\n,model);
The problem disappeared...
A similar code is also present on em28xx. Anyway, it is better to have
this kind of protection. I've added a patch, based on yours, fixing the
bug. As you'd agreed, I've pushed the patches to master tree.
It is better, however, to check why it is calling the code, without a
valid USB ID, since it may mean a future trouble...
Btw, I think we can also apply this one also:
diff -r 6b6805e3c76d linux/drivers/media/video/usbvision/usbvision-video.c
--- a/linux/drivers/media/video/usbvision/usbvision-video.cSat Apr 14
15:17:08 2007 -0300
+++ b/linux/drivers/media/video/usbvision/usbvision-video.cSat Apr 14
15:19:06 2007 -0300
@@ -1985,8 +1985,6 @@ static int __devinit usbvision_probe(str
return -ENODEV;
}
-usb_get_dev(dev);
-
if ((usbvision = usbvision_alloc(dev)) == NULL) {
err(%s: couldn't allocate USBVision struct, __FUNCTION__);
return -ENOMEM;
usb_get_dev() is already called previously on usbvision_probe.
Latest v4l-dvb tree tested OK.
You are right for usb_get_dev, only one call is necessary to increment
the reference count.
Thierry
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Afatech af9005 unstable reception [added: mt2060 gain control?]
En/na P. van Gaans ha escrit: What, top-posting? Wikipedia is helpful.. I didn't know, I prefer top-posting, saves scrollingtime. In fact I was wondering why you were bottom-posting. I'm used to forums, not to mailinglists. On forums you decide yourself if you want to see everything top or bottomposted.. Seriously I didn't know it was a crime! See sig. This is a mailing list, not a forum So I understand I have to change the 0 into a 1 and change state-strong to temp? Not remove the # for if? If that's all correct I guess it didn't really help. If you're following the mailing list, see Thomas Pinz's reply to my message. Maybe you just get what you pay for then.. On other receivers I get signals from 60 kilometers away, on the afatach vitually nothing (closest transmitter is 27 kilometer). Are you supposed to tape the antenna to the transmitter? I live ~6km to the transmitting tower, and I cannot get at least one mux (the rest are mostly fine though). But, in my case, it's the same under windows. But wait.. *looks at laptop*, suddenly the afatech stick reads the channels from Wavre, Belgium. That's over 80 kilometers away and a pretty weak transmitter. The much stronger signal from Schoten (35 kilometers or so) is blissfully ignored. The image contains some blocks but it's better than the radio I had earlier. Strange stuff.. Indeed Bye -- Luca A: Because it destroys the flow of the conversation Q: Why is it bad? A: No, it's bad. Q: Should I top post in replies to mailing lists? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] timeout problems with nova-s+
Hi list,
I have very unstable video and sound with my nova-s plus, and wonder, if
anyone has the same problem or can help me out?
I use vdr for recording and tested with xine dvb to see if it is vdr related:
both show the same symptoms.
Vdr's femon plugin shows excellent reception values and a dreambox and
a pace reciever show now problems when connected to the same cable.
The recordings and live view are not always bad. Sometimes it works just fine,
but I couldn't find a pattern yet.
this is a (very small) excerpt of what I get from the logs:
Apr 16 09:19:23 job4 vdr: [11513] frontend 0 regained lock on channel 20, tp
211739
Apr 16 09:19:28 job4 vdr: [11513] frontend 0 lost lock on channel 20, tp 211739
Apr 16 09:19:28 job4 vdr: [11513] frontend 0 regained lock on channel 20, tp
211739
Apr 16 09:19:29 job4 vdr: [11513] frontend 0 lost lock on channel 20, tp 211739
Apr 16 09:19:29 job4 vdr: [11513] frontend 0 regained lock on channel 20, tp
211739
Apr 16 09:19:32 job4 vdr: [11513] frontend 0 lost lock on channel 20, tp 211739
Apr 16 09:19:32 job4 vdr: [11513] frontend 0 regained lock on channel 20, tp
211739
Apr 16 09:19:51 job4 vdr: [11513] frontend 0 lost lock on channel 19, tp 211778
Apr 16 09:19:51 job4 vdr: [11513] frontend 0 regained lock on channel 19, tp
211778
Apr 16 09:21:19 job4 kernel: cx88[0]/2-mpeg: cx8802_timeout
Apr 16 09:21:19 job4 vdr: [11513] frontend 0 lost lock on channel 21, tp 211973
Apr 16 09:21:20 job4 kernel: cx88[0]/2-mpeg: cx8802_timeout
Apr 16 09:21:20 job4 vdr: [11513] frontend 0 regained lock on channel 21, tp
211973
Apr 16 09:21:21 job4 kernel: cx88[0]/2-mpeg: cx8802_timeout
Apr 16 09:21:23 job4 kernel: cx88[0]/2-mpeg: cx8802_timeout
Apr 16 09:21:37 job4 kernel: cx88[0]/2-mpeg: cx8802_timeout
Apr 16 09:21:37 job4 vdr: [11513] frontend 0 lost lock on channel 21, tp 211973
Apr 16 09:21:37 job4 vdr: [11513] frontend 0 regained lock on channel 21, tp
211973
This is what boot.msg has to say about the card:
# awk '/cx/ { print NR: $0 }' /var/log/boot.msg
399: 6cx2388x alsa driver version 0.0.6 loaded
400: 6cx2388x cx88-mpeg Driver Manager version 0.0.6 loaded
401: 6cx2388x v4l2 driver version 0.0.6 loaded
427: 6CORE cx88[0]: subsystem: 0070:9202, board: Hauppauge Nova-S-Plus DVB-S
[card=37,autodetected]
434: 6i2c-algo-bit.o: cx88[0] passed test.
442: 6cx88[0]: hauppauge eeprom: model=92001
443: 6input: cx88 IR (Hauppauge Nova-S-Plus as /class/input/input3
444: 6cx88[0]/1: CX88x/0: ALSA support for cx2388x boards
445: 4cx88[0]/2: cx2388x 8802 Driver Manager
448: 6cx88[0]/2: found at :03:00.2, rev: 5, irq: 169, latency: 64, mmio:
0xf900
466: 6cx88[0]/0: found at :03:00.0, rev: 5, irq: 169, latency: 20, mmio:
0xfb00
467: 6cx88[0]/0: registered device video0 [v4l2]
468: 6cx88[0]/0: registered device vbi0
485: 6cx2388x dvb driver version 0.0.6 loaded
486: 6cx8802_register_driver() -registering driver type=dvb access=shared
487: 6CORE cx88[0]: subsystem: 0070:9202, board: Hauppauge Nova-S-Plus DVB-S
[card=37]
488: 4cx88[0]/2: cx2388x based dvb card
490: 4DVB: registering new adapter (cx88[0]).
The lspci output:
00:00.0 Host bridge: Intel Corporation 82P965/G965 Memory Controller Hub (rev
02)
00:01.0 PCI bridge: Intel Corporation 82P965/G965 PCI Express Root Port (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #4 (rev
02)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #5 (rev
02)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #2
(rev 02)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1
(rev 02)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #1 (rev
02)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #2 (rev
02)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI #3 (rev
02)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI #1
(rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2)
00:1f.0 ISA bridge: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface
Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801H (ICH8 Family) 4 port SATA IDE
Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02)
00:1f.5 IDE interface: Intel Corporation 82801H (ICH8 Family) 2 port SATA IDE
Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7600 GS]
(rev a1)
02:00.0 IDE interface: JMicron Technologies, Inc. JMB361 AHCI/IDE (rev 02)
02:00.1 IDE interface: JMicron Technologies, Inc. JMB361 AHCI/IDE (rev 02)
03:00.0 Multimedia video controller: Conexant CX23880/1/2/3 PCI Video and Audio
Decoder (rev 05)
03:00.1 Multimedia controller: Conexant CX23880/1/2/3 PCI Video and Audio
Decoder [Audio Port] (rev 05)
03:00.2 Multimedia controller: Conexant CX23880/1/2/3 PCI
Re: [linux-dvb] timeout problems with nova-s+
Am Montag, 16. April 2007 09:59 schrieb Joachim Banzhaf: Hi list, Just seen that the tip version I gave is not correct. I used the drivers I got April, 1st (no joke) This might also be useful? # lsmod Module Size Used by appletalk 74864 2 ax25 99708 2 ipx65224 2 p8023 19072 1 ipx af_packet 57356 0 joydev 28160 0 st 57892 0 ide_cd 59680 0 ide_core 175104 1 ide_cd bluetooth 90244 0 xt_pkttype 18816 12 ipt_TCPMSS 21248 1 ipt_LOG23808 27 nfsd 286824 9 exportfs 22912 1 nfsd vmnet 76592 21 lockd 96496 2 nfsd nfs_acl20608 1 nfsd vmmon 166252 0 sunrpc193224 9 nfsd,lockd,nfs_acl tun29440 1 snd_pcm_oss71936 0 snd_mixer_oss 35840 1 snd_pcm_oss snd_seq83360 0 snd_seq_device 26516 1 snd_seq cpufreq_conservative25608 0 cpufreq_ondemand 24592 2 cpufreq_userspace 24064 0 cpufreq_powersave 18688 0 acpi_cpufreq 26884 1 freq_table 22912 1 acpi_cpufreq hisax 445376 0 crc_ccitt 19072 1 hisax isdn 160736 1 hisax slhc 24064 1 isdn button 24736 0 battery28168 0 ac 22792 0 ip6t_REJECT22528 3 ip6t_LOG 24192 1 xt_limit 20224 28 xt_tcpudp 20352 62 ipt_REJECT 22528 3 xt_state 19200 36 iptable_mangle 19840 0 iptable_nat25092 0 ip_nat 38060 1 iptable_nat iptable_filter 20096 1 ip6table_mangle19456 0 ip_conntrack 78628 3 xt_state,iptable_nat,ip_nat nfnetlink 24648 2 ip_nat,ip_conntrack ip_tables 39400 3 iptable_mangle,iptable_nat,iptable_filter ip6table_filter19840 1 ip6_tables 33352 3 ip6t_LOG,ip6table_mangle,ip6table_filter x_tables 37384 12 xt_pkttype,ipt_TCPMSS,ipt_LOG,ip6t_REJECT,ip6t_LOG,xt_limit,xt_tcpudp,ipt_REJECT,xt_state,iptable_nat,ip_tables,ip6_tables ipv6 358752 37 ip6t_REJECT apparmor 74520 0 aamatch_pcre 31232 1 apparmor nls_utf8 19072 1 ntfs 209672 1 nls_iso8859_1 22144 2 nls_cp437 23808 2 vfat 30976 2 fat73392 1 vfat ext2 88208 1 mbcache27016 1 ext2 loop 34064 0 dm_mod 82128 28 isl642119200 1 cx2412330088 1 cx88_dvb 34052 0 cx88_vp3054_i2c22272 1 cx88_dvb dvb_pll33412 1 cx88_dvb video_buf_dvb 23940 1 cx88_dvb dvb_core 107696 1 video_buf_dvb usblp 32179 1 cx8800 57084 0 cx8802 37508 1 cx88_dvb cx88_alsa 32520 2 cx88xx 89892 4 cx88_dvb,cx8800,cx8802,cx88_alsa ir_common 54276 1 cx88xx i2c_algo_bit 26248 2 cx88_vp3054_i2c,cx88xx compat_ioctl32 25600 1 cx8800 tveeprom 34832 1 cx88xx nvidia 7770136 32 videodev 45696 2 cx8800,cx88xx v4l2_common36992 4 cx8800,cx88xx,compat_ioctl32,videodev r8169 50824 0 i2c_i801 25364 0 ehci_hcd 51080 0 v4l1_compat28804 1 videodev video_buf 44804 6 cx88_dvb,video_buf_dvb,cx8800,cx8802,cx88_alsa,cx88xx tulip 71712 0 btcx_risc 22024 4 cx8800,cx8802,cx88_alsa,cx88xx intel_agp 44224 1 i2c_core 41472 10 isl6421,cx24123,cx88_dvb,cx88_vp3054_i2c,dvb_pll,cx88xx,i2c_algo_bit,tveeprom,nvidia,i2c_i801 uhci_hcd 42520 0 snd_hda_intel 37660 2 snd_hda_codec 220416 1 snd_hda_intel snd_pcm 115592 4 snd_pcm_oss,cx88_alsa,snd_hda_intel,snd_hda_codec snd_timer 44680 2 snd_seq,snd_pcm snd89768 17 snd_pcm_oss,snd_mixer_oss,snd_seq,snd_seq_device,cx88_alsa,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer soundcore 28320 1 snd snd_page_alloc 27920 2 snd_hda_intel,snd_pcm usbcore 163624 4 usblp,ehci_hcd,uhci_hcd parport_pc 58984 1 lp 30664 0 parport59916 2 parport_pc,lp reiserfs 260992 15 sr_mod 34724 0 cdrom 54056 2 ide_cd,sr_mod edd27912 0 fan22408 1 pata_jmicron 24576 0 sg 55080 0 ata_piix 34564 21
Re: [linux-dvb] Freecom DVB 25451-Rev.3 Why have it 2 frontends?
I have the same issues with the same card. Benjie Gillam. [EMAIL PROTECTED] wrote: hello, after plugin the freecom 25451 rev3 i can see this dmesg-output: [ 136.488000] usb 5-3: new high speed USB device using ehci_hcd and address 4 [ 136.628000] usb 5-3: configuration #1 chosen from 1 choice [ 136.76] dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in cold state, will try to load a firmware [ 136.772000] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-fc03.fw' [ 136.86] usbcore: registered new interface driver dvb_usb_dtt200u [ 138.26] usb 5-3: USB disconnect, address 4 [ 138.26] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. [ 139.508000] usb 5-3: new high speed USB device using ehci_hcd and address 5 [ 139.64] usb 5-3: configuration #1 chosen from 1 choice [ 139.64] dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in warm state. [ 139.64] dvb-usb: will use the device's hardware PID filter (table count: 15). [ 139.644000] DVB: registering new adapter (WideView WT-220U PenType Receiver (Typhoon/Freecom)). [ 139.644000] DVB: registering frontend 0 (WideView USB DVB-T)... [ 139.644000] input: IR-receiver inside an USB DVB receiver as /class/input/input9 [ 139.644000] dvb-usb: schedule remote query interval to 300 msecs. [ 139.644000] dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully initialized and connected. [ 139.644000] dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in warm state. [ 139.644000] dvb-usb: will use the device's hardware PID filter (table count: 15). [ 139.644000] DVB: registering new adapter (WideView WT-220U PenType Receiver (Typhoon/Freecom)). [ 139.644000] DVB: registering frontend 1 (WideView USB DVB-T)... [ 139.644000] input: IR-receiver inside an USB DVB receiver as /class/input/input10 [ 139.644000] dvb-usb: schedule remote query interval to 300 msecs. [ 139.644000] dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully initialized and connected. [ 139.816000] usbcore: registered new interface driver hiddev [ 139.816000] usbcore: registered new interface driver usbhid [ 139.816000] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 139.832000] usbcore: registered new interface driver xpad [ 139.832000] drivers/usb/input/xpad.c: driver for Xbox controllers v0.1.6 [ 141.244000] eth1: no IPv6 routers present [ 141.944000] dvb-usb: recv bulk message failed: -110 in kaffeine there are also 2 devices shown, but i think i only should have one of it? Can somebody explain this to me please. Also in kaffeine, when starting tv the first time, tv-screen freezes after 2 seconds and i have to switch to another channel, i think it is some problem with the firmware, because i also have a yakumo and everthing is fine. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Hybrid tuner proposal (V4L/DVB)
On Mon, Apr 16, 2007, Manu Abraham wrote: Johannes Stezenbach wrote: I believe many people (users) would like em28xx to be merged asap, so I'm trying to find a way how it could be done. IMHO, code that which is bad should be fixed and then only be accepted into the project. I don't see any reason for any person/project to be given any special status and things should work just as normally. It is completely wrong to artificially create a huge importance/need and doing things -- Incorrect way of doing things. It's not artificial. The em28xx merge has been delayed for more than a year with little visible progress. That's a disaster. And it doesn't really matter whose fault it is. If you have technical reasons why Markus' code shouln't be merged (like breaks support for the X card, or even breaks all non-em28xx cards or crashes under SMP etc.), then you should let us know about it. Note that your hybrid tuner proposal is not dismissed by merging Markus' code, however time is important here, and I don't think it's OK to delay the merge another couple of weeks/months until your proposal is fully implemented, tested and merged. Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Hybrid tuner proposal (V4L/DVB)
Johannes Stezenbach wrote: On Mon, Apr 16, 2007, Manu Abraham wrote: Johannes Stezenbach wrote: I believe many people (users) would like em28xx to be merged asap, so I'm trying to find a way how it could be done. IMHO, code that which is bad should be fixed and then only be accepted into the project. I don't see any reason for any person/project to be given any special status and things should work just as normally. It is completely wrong to artificially create a huge importance/need and doing things -- Incorrect way of doing things. It's not artificial. The em28xx merge has been delayed for more than a year with little visible progress. That's a disaster. We have had discussions that have been outstanding since 2005. Don't you feel the same on those ? Do you know how many people were/are still anxiously looking forward, Sorry not just people -- OSS projects (applications and so on), Commercial projects and so on. And it doesn't really matter whose fault it is. If you have technical reasons why Markus' code shouln't be merged (like breaks support for the X card, or even breaks all non-em28xx cards or crashes under SMP etc.), then you should let us know about it. Note that your hybrid tuner proposal is not dismissed by merging Markus' code, however time is important here, and I don't think it's OK to delay the merge another couple of weeks/months until your proposal is fully implemented, tested and merged. As i said, completely upto you. Don't have anything more to say. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Kaffeine universal DVB-T scan file
Dear Christoph, all, Christoph Pfister wrote: Hi, 2007/4/14, P. van Gaans [EMAIL PROTECTED]: Say you live in The Netherlands. Frequencies change here all the time, and QAM settings and stuff also change all the time. Say you're living on the border, like me. I receive channels from The Netherlands and Belgium at the same time, but there's no scan file for that. There will also always be locations missing in the list. And what if you simply have no clue about where you live? Nobody thinks of them! Then again, nobody knows where they are ;-) So here is the solution: a file that'll make Kaffeine scan all UHF channels with AUTO for the QAM and other stuff, will be sufficient in most countries although scanning takes a bit longer. I hope it makes it into some next version of Kaffeine :). Pim snip There are enough cases where such a file doesn't work (think of offsets, 7 mhz transponders etc). Responsible for such complete scannings are the apps (kaffeine has auto scan which does pretty much the same as your file does and it tries offsets iirc). Christoph I think dvb-t scan files should be organized in 3 levels: 1. specific location 2. specific country 3. most general case For 1. the scan will be fast, because only frequencies known to be active will be scanned - and most params will be known. For 2., we should refer to the frequency allocation plan of a given country, so that all possible frequencies (and bandwidths) are listed - with other params left to autodetection. 3. should be the union of all known center frequencies used somewhere, listed more than once if other params may change (e.g. bandwidth 6 or 7 or 8 MHz). The scan will probably be very slow, but the goal is to maximize the chance to get all available muxes. When the scan file for your specific location (1.) is not present or does not work, you can try 2., and if 2. is not enough you could try 3. Cheers, Mauro. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Hybrid tuner proposal (V4L/DVB)
On 4/16/07, Manu Abraham [EMAIL PROTECTED] wrote: Johannes Stezenbach wrote: On Mon, Apr 16, 2007, Manu Abraham wrote: Johannes Stezenbach wrote: I believe many people (users) would like em28xx to be merged asap, so I'm trying to find a way how it could be done. IMHO, code that which is bad should be fixed and then only be accepted into the project. I don't see any reason for any person/project to be given any special status and things should work just as normally. It is completely wrong to artificially create a huge importance/need and doing things -- Incorrect way of doing things. It's not artificial. The em28xx merge has been delayed for more than a year with little visible progress. That's a disaster. We have had discussions that have been outstanding since 2005. Don't you feel the same on those ? Do you know how many people were/are still anxiously looking forward, Sorry not just people -- OSS projects (applications and so on), Commercial projects and so on. Manu please stay on a constructive level now. What I don't like about your current approach is that you have to duplicate the wrapper in every new hybrid tuner module (eg you have one generic core tuning function and you have to build wrappers around to fit the i2c and dvb part). Please point me to your code and where my current approach will break the multiproto work you did last year. Regarding the difficulty, I don't see anything within the whole project which isn't doable everything's about time and patience of reading specs to get something done here. And it doesn't really matter whose fault it is. If you have technical reasons why Markus' code shouln't be merged (like breaks support for the X card, or even breaks all non-em28xx cards or crashes under SMP etc.), then you should let us know about it. Note that your hybrid tuner proposal is not dismissed by merging Markus' code, however time is important here, and I don't think it's OK to delay the merge another couple of weeks/months until your proposal is fully implemented, tested and merged. As i said, completely upto you. Don't have anything more to say. now stop pushing anyone and discuss the work we did so far, this is not only up to Johannes he didn't write your neither my code. Markus ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Hybrid tuner proposal (V4L/DVB)
Markus Rechberger wrote: On 4/16/07, Manu Abraham [EMAIL PROTECTED] wrote: Johannes Stezenbach wrote: On Mon, Apr 16, 2007, Manu Abraham wrote: Johannes Stezenbach wrote: I believe many people (users) would like em28xx to be merged asap, so I'm trying to find a way how it could be done. IMHO, code that which is bad should be fixed and then only be accepted into the project. I don't see any reason for any person/project to be given any special status and things should work just as normally. It is completely wrong to artificially create a huge importance/need and doing things -- Incorrect way of doing things. It's not artificial. The em28xx merge has been delayed for more than a year with little visible progress. That's a disaster. We have had discussions that have been outstanding since 2005. Don't you feel the same on those ? Do you know how many people were/are still anxiously looking forward, Sorry not just people -- OSS projects (applications and so on), Commercial projects and so on. Manu please stay on a constructive level now. *enough* Stop it. Someone talking constructive. Huh ! What I don't like about your current approach is that you have to duplicate the wrapper in every new hybrid tuner module (eg you have one generic core tuning function and you have to build wrappers around to fit the i2c and dvb part). Johannes, you probably understand now. Please point me to your code and where my current approach will break the multiproto work you did last year. You can read that discussion for understanding how. Not multiproto, but your broken approach _will_ break. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Hybrid tuner proposal (V4L/DVB)
On Mon, Apr 16, 2007, Manu Abraham wrote: Johannes, you probably understand now. Well, you want to be DVB maintainer, so please try to think like one. How can you serve the project better? [ ] By putting all personal issues aside and merge em28xx anyway, even if it means getting your hands dirty and having to fix up possible problems and any ugliness caused by it? [ ] By further delaying it until Markus might one day*) wake up enligthened and would magically fix up all issues to your whole content himself? Choose wisely. It's OK that you defend your code and your proposal, but if you look at the big picture the the choice should be clear, right? Johannes *) In Germany we call this day Sankt Nimmerleinstag ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Opera S1- DVB-USB
Thanks for your answer
if fixed the things you wrote, and now it look a bit nicer.
the values used here for many command here are unknown to me, because i
have no doc for this part of dvb box.
so i this first enough to put it in and have some more testern for this
device ?
[EMAIL PROTECTED] schrieb:
Hi Marco,
I've some comments bellow about your patch.
Cheers,
Mauro
Em Dom, 2007-04-15 às 19:55 +0200, Marco Gittler escreveu:
+config DVB_USB_OPERA1
+tristate Opera1 DVB-S USB2.0 receiver
+depends on DVB_USB
+select DVB_STV0299
+ #if !DVB_FE_CUSTOMISE
Why the above is commented? If DVB_FE_CUSTOMISE is not yet supported,
just remove it, but the better is to allow supporting it.
+static const u8* xilinx_init=\x90\x6e\xc5\xfa\x32\xd0\x73\x23\x1e;
Instead of writing as a string, better to write as a char array:
static const u8* xilinx_init= {0x90, 0x6e, 0xc5, ...
Better yet if you can better document the values at the array, by
replacing it by aliases, like:
static const u8* xilinx_init= { R90_INIT_DEV, R60_SELECT_MODE, ...
(of course if you know what the init is doing)
+ memset(r,0,10);
Avoid using magic numbers. Instead, do:
memset (r,0,sizeof(*r));
+ //if (mutex_lock_interruptible(mymutex)){
+ //return -EAGAIN;
+ //}
Instead, use #if 0 for commenting codes like the above
Also, to follow kernel Documentation/CodingStyle, you should do:
if (foo) {
instead of
if (foo){
The same trouble (and other CodingStyle things, like column max size)
happens also on other parts of the code. Maybe the better is to run
indent with the following options:
indent -kr -i8 -ts8 -sob -l80 -ss -ncs files
This will apply several common CodingStyle used on kernel. You should
review the code, since sometimes it mess some stuff and remove spaces
used for alignment on some undesirable places.
So, the above should be something like this:
#if 0
if (mutex_lock_interruptible(mymutex)) {
return -EAGAIN;
}
#endif
+ ret=usb_control_msg(dev, pipe,request, request_type| USB_TYPE_VENDOR,value,
0x0 /*index*/, u8buf,len, 2000);
The /*index*/ comment here is useless and can be removed.
+ }else
+ *state = REMOTE_NO_KEY_PRESSED;
+ return 0;
Hmm... return 0 is wrongly indented here.
+ if(ret==0)
+ {
Another CodingStyle. Should be, instead
if ( ret==0 ) {
+ // clear fpga ?
Generally, we avoid using c++ style comments, using instead:
/* clear fpga */
+ .entries = {
+ { 1064000, 500, 0xe5, 0xc6 },
+ { 1169000, 500, 0xe5, 0xe6 },
+ {1299000, 500, 0xe5, 0x24 },
Hmm... this went missaligned at the email. Probably, you've mixed tabs
with spaces. Better to use or one or the other at the table.
Cheers,
Mauro
diff -r b5be3479f070 linux/drivers/media/dvb/dvb-usb/Kconfig
--- a/linux/drivers/media/dvb/dvb-usb/Kconfig Sat Apr 14 16:19:13 2007 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/Kconfig Mon Apr 16 12:06:05 2007 +0200
@@ -110,6 +110,7 @@ config DVB_USB_CXUSB
Medion MD95700 hybrid USB2.0 device.
DViCO FusionHDTV (Bluebird) USB2.0 devices
+
config DVB_USB_M920X
tristate Uli m920x DVB-T USB2.0 support
@@ -211,3 +212,10 @@ config DVB_USB_DTT200U
The receivers are also known as DTT200U (Yakumo) and UB300 (Yuan).
The WT-220U and its clones are pen-sized.
+
+config DVB_USB_OPERA1
+tristate Opera1 DVB-S USB2.0 receiver
+depends on DVB_USB
+select DVB_STV0299 if !DVB_FE_CUSTOMISE
+help
+ Say Y here to support the Opera DVB-S USB2.0 receiver.
diff -r b5be3479f070 linux/drivers/media/dvb/dvb-usb/Makefile
--- a/linux/drivers/media/dvb/dvb-usb/Makefile Sat Apr 14 16:19:13 2007 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/Makefile Sun Apr 15 12:08:27 2007 +0200
@@ -51,4 +51,8 @@ dvb-usb-dib0700-objs = dib0700_core.o di
dvb-usb-dib0700-objs = dib0700_core.o dib0700_devices.o
obj-$(CONFIG_DVB_USB_DIB0700) += dvb-usb-dib0700.o
+dvb-usb-opera-objs = opera1.o
+obj-$(CONFIG_DVB_USB_OPERA1) += dvb-usb-opera.o
+
+
EXTRA_CFLAGS = -Idrivers/media/dvb/dvb-core/ -Idrivers/media/dvb/frontends/
diff -r b5be3479f070 linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Sat Apr 14 16:19:13
2007 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h Sun Apr 15 11:57:27
2007 +0200
@@ -38,6 +38,7 @@
#define USB_VID_ULTIMA_ELECTRONIC 0x05d8
#define USB_VID_UNIWILL0x1584
#define USB_VID_WIDEVIEW 0x14aa
+#define USB_VID_OPERA1 0x695C
/* Product IDs */
#define USB_PID_ADSTECH_USB2_COLD 0xa333
@@ -142,6 +143,8 @@
#define USB_PID_GENPIX_8PSK_WARM 0x0201
#define USB_PID_SIGMATEK_DVB_110 0x6610
#define
[linux-dvb] Re: [v4l-dvb-maintainer] DVB Maintainer
Johannes Stezenbach wrote: On Mon, Apr 16, 2007, Manu Abraham wrote: Johannes Stezenbach wrote: Why do you waste your time looking backward? Not only is this not useful, in this case it's also _harmful_. When someone flames you in all aspects again and again, you would just watch it go by ? Usually yes I don't think that is entirely true .. but since usually Instead of trying to keep the flamewar alive, the right thing to do (as this is written under the DVB Maintainer subject), is put the personal issues aside and find a way to integrate the em28xx driver. Would have appreciated your stand, if you had the same stand on other threads as well. (IIRC your stand on the DVB-S2/multiproto threads were completely opposite. You wanted to hold things back) That is not true. Your first proposal was crap, yet you asked Mauro the merge it and even got ACKs from others. So I pointed out that I thought it needs more work. Ok, if my first proposal was crap, it is crap still. After the driver was completed _most_ of the stuff had to be done according to the old proposal, because the delivery system does indeed need them (not just useless params) You were asleep throughout the discussion. For Marcel's request you said it was okay too. After that you had a dream or something like that and even apologized for your last minute barging in, also that you didn't understand about DVB-S2. It wasn't anyone else's fault that you NACK'd it after asking Mauro to pull, but yours alone. You could have done it earlier too.. or just kept quiet. Was a waste of time for so many people involved. I also think the whole approach of we need to merge this API change *now* so we can develop DVB-S2 drivers was flawed. IMHO first you have to produce a working driver to prove the API is working, *then* it can be merged. I don't think that's true for a new delivery system. Even after the driver was developed, it was still flawed, Huh ? And if there was a please review or Mauro, please merge mail regarding multiproto recently, I must have missed it. Sorry. You said you didn't have the time after everything was done, inspite of many mails sent to you. If someone NACK's something for a reason and when those things are fixed, the same person could at least show a bit of courtesy by stating the same problems are/were fixed. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] initial tuning failed
hello, maybe somebody can help. after system-crash, I updated reinstalled my system, but now, i cannot get dvb working. after dvbscan i get the following warning: WARNING: frontend type (OFDM) is not compatible with requested tuning type (QAM) and the the error: ERROR: initial tuning failed dumping lists (0 services) Done. i have the 2.6.18.8 linux-kernel the dmesg looks so: usb 1-1: new full speed USB device using ohci_hcd and address 18 usb 1-1: configuration #1 chosen from 1 choice dvb-usb: found a 'Artec T1 USB1.1 TVBOX with AN2235 (faulty USB IDs)' in cold state, will try to load a firmware dvb-usb: downloading firmware from file 'dvb-usb-dibusb-an2235-01.fw' usb 1-1: USB disconnect, address 18 dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. ohci_hcd :00:0b.0: wakeup usb 1-1: new full speed USB device using ohci_hcd and address 19 usb 1-1: configuration #1 chosen from 1 choice dvb-usb: found a 'DiBcom USB1.1 DVB-T reference design (MOD3000)' in warm state. dvb-usb: will use the device's hardware PID filter (table count: 16). DVB: registering new adapter (DiBcom USB1.1 DVB-T reference design (MOD3000)). DVB: registering frontend 0 (DiBcom 3000M-B DVB-T)... dibusb: This device has the Thomson Cable onboard. Which is default. input: IR-receiver inside an USB DVB receiver as /class/input/input9 dvb-usb: schedule remote query interval to 150 msecs. dvb-usb: DiBcom USB1.1 DVB-T reference design (MOD3000) successfully initialized and connected. before all worked without problems. does anymody know, why it is not compatible? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Will this USB DVB-T stick work under Linux?
Hello, I have a slightly unusual USB DVB-T stick and I am trying to work out if it is supported by Linux. I purchased it from Oatley Electronics here in Australia. A picture and description can be viewed here: http://secure.oatleyelectronics.com//product_info.php?cPath=24products_id=348osCsid=3a2a89b61e884d851844e1d820c768e2 The device is enclosed in a metal casing with a typical 75ohm TV connector at one end, and the USB connector at the other. There are two holes in the case, allowing one red and one green LED to be visible when the device is operating (under Windows XP). I have prized off the metal casing to get a view of circuit board. It hosts, amongst other components, the following chips: - Zarlink MT352CG (Demodulator) - Infineon TUA6045 (Tuner) - Cypress CY7C68013A (Usb Microcontroller High-speed Usb Peripheral Controller) - ATMEL546 24C02N (EEPROM?) I have taken a closeup image of each side of the circuit board. These can be viewed at the following URLs (~750kb each): http://www.lucsmall.com/share/dvbusb-top.jpg http://www.lucsmall.com/share/dvbusb-underside.jpg I am keen to get this stick functioning under Linux since it seems to work quite well under Windows XP. It seems to be quite sensitive, and where I live (which admittedly isn't too far from the transmitter site) the unit works quite happily with a 1 metre length of hookup wire for an aerial. From what I can gather, the device appears to be made by CE. The Windows driver and software seem to suggest that. However when I plug the device in when running Linux it seems to be identified as a Hanftek UMT-010 DVB-T USB2.0. When I try to run scan, however, it fails to tune. Any advice as to whether, and if so how, this device could be made to run under Linux would be greatly appreciated. I have included some information below that I hope might be useful in answering my query. Best wishes, Luc Windows Software: - - DVTPlayer.Exe - CEDTVLDR.sys - CEDTVLDR.inf - USBDTV.sys - DTVM5P2.sys File Player.ini that comes with Windows Software: -- [Player] Tunertype=14 TunerI2CAddress=192 CaptureTo=1 ScalePercent=100,100,100 [Driver] DriverLoader=CEDTVLDR.sys DriverCapture=DTVM5P2.sys dmesg output after device plugged in: - [17188486.864000] usb 4-1.2: new high speed USB device using ehci_hcd and address 9 [17188486.956000] usb 4-1.2: configuration #1 chosen from 1 choice [17188487.168000] dvb-usb: found a 'Hanftek UMT-010 DVB-T USB2.0' in cold state, will try to load a firmware [17188487.192000] dvb-usb: downloading firmware from file 'dvb-usb-umt-010-02.fw' [17188487.224000] usbcore: registered new driver dvb_usb_umt_010 [17188487.432000] usb 4-1.2: USB disconnect, address 9 [17188487.432000] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. [17188489.168000] usb 4-1.2: new high speed USB device using ehci_hcd and address 10 [17188489.26] usb 4-1.2: configuration #1 chosen from 1 choice [17188489.26] dvb-usb: found a 'Hanftek UMT-010 DVB-T USB2.0' in warm state. [17188489.26] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [17188489.276000] DVB: registering new adapter (Hanftek UMT-010 DVB-T USB2.0). [17188489.276000] DVB: registering frontend 0 (Zarlink MT352 DVB-T)... [17188489.292000] dvb-usb: Hanftek UMT-010 DVB-T USB2.0 successfully initialized and connected. Output of /proc/bus/usb/devices for device: --- T: Bus=04 Lev=02 Prnt=02 Port=01 Cnt=02 Dev#= 10 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=15f4 ProdID=0015 Rev= 0.01 S: Manufacturer=UMT-010 V00.01 S: Product=HANF FIRMWARE C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 4 Cls=ff(vend.) Sub=00 Prot=00 Driver=dvb_usb_umt_010 E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms Output of lsusb -v for device: -- Bus 004 Device 010: ID 15f4:0015 HanfTek Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x15f4 HanfTek idProduct 0x0015 bcdDevice0.01 iManufacturer 1 UMT-010 V00.01 iProduct2 HANF FIRMWARE iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9
Re: [linux-dvb] Re: [v4l-dvb-maintainer] DVB Maintainer
Original-Nachricht Datum: Mon, 16 Apr 2007 15:35:59 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Johannes Stezenbach [EMAIL PROTECTED] CC: [EMAIL PROTECTED], linux-dvb linux-dvb@linuxtv.org Betreff: [linux-dvb] Re: [v4l-dvb-maintainer] DVB Maintainer Johannes Stezenbach wrote: On Mon, Apr 16, 2007, Manu Abraham wrote: Johannes Stezenbach wrote: Why do you waste your time looking backward? Not only is this not useful, in this case it's also _harmful_. When someone flames you in all aspects again and again, you would just watch it go by ? Usually yes I don't think that is entirely true .. but since usually Instead of trying to keep the flamewar alive, the right thing to do (as this is written under the DVB Maintainer subject), is put the personal issues aside and find a way to integrate the em28xx driver. Would have appreciated your stand, if you had the same stand on other threads as well. (IIRC your stand on the DVB-S2/multiproto threads were completely opposite. You wanted to hold things back) That is not true. Your first proposal was crap, yet you asked Mauro the merge it and even got ACKs from others. So I pointed out that I thought it needs more work. Ok, if my first proposal was crap, it is crap still. After the driver was completed _most_ of the stuff had to be done according to the old proposal, because the delivery system does indeed need them (not just useless params) You were asleep throughout the discussion. For Marcel's request you said it was okay too. After that you had a dream or something like that and even apologized for your last minute barging in, also that you didn't understand about DVB-S2. It wasn't anyone else's fault that you NACK'd it after asking Mauro to pull, but yours alone. You could have done it earlier too.. or just kept quiet. Was a waste of time for so many people involved. I also think the whole approach of we need to merge this API change *now* so we can develop DVB-S2 drivers was flawed. IMHO first you have to produce a working driver to prove the API is working, *then* it can be merged. I don't think that's true for a new delivery system. Even after the driver was developed, it was still flawed, Huh ? And if there was a please review or Mauro, please merge mail regarding multiproto recently, I must have missed it. Sorry. You said you didn't have the time after everything was done, inspite of many mails sent to you. If someone NACK's something for a reason and when those things are fixed, the same person could at least show a bit of courtesy by stating the same problems are/were fixed. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Hi, I do not want to extend this issue at all, BUT: I have still got 2 patches lying around that were sent in some 10 or 15 times, but continuously ignored, although they are OK by at least 98 %. They update some broken docu and they help me to save RAM. Two statements: 1. To make it utmost hard for you: Show that you can work WITH Manu, not against him. (Johannes Stezenbach). 2. Literally: There are developpers that have a certain kind of driver knowledge but are lacking the human skills. Those are the WORST. (Linus Torvalds). I am still hopeful for things getting better, that's why I won't add the name of the person I have in mind concerning citation number 2. But I do not state anything wrong saying that I never had any problems on the communication layer when linuxtv.org was but in german hands (Michael Hunold and others). Regards Uwe P. S.: My two patches need a bit of work - I know! But investing at least 5 minutes of time for that is far more progressive, constructive, and helpful for the whole community than any kind of flamewar out of whatever reason has ever been! Stubbornness and primadonna behaviour, or at least ignoring or sitting out things do not help anyone, bring nothing forward, waste the atmosphere that could be a lot more better if there was some reflection about those communication schemes settled down in at least one person. -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Hybrid tuner proposal (V4L/DVB)
Johannes Stezenbach wrote: On Mon, Apr 16, 2007, Manu Abraham wrote: Johannes, you probably understand now. Well, you want to be DVB maintainer, so please try to think like one. How can you serve the project better? [ ] By putting all personal issues aside and merge em28xx anyway, even if it means getting your hands dirty and having to fix up possible problems and any ugliness caused by it? The merging probably sounds okay. (As i said in a previous post, it is upto you. I don't have the said device to comment on it) For later fixups, for API updates there needs to be co-operation from the author, rather than flames that's all. [ ] By further delaying it until Markus might one day*) wake up enligthened and would magically fix up all issues to your whole content himself? Choose wisely. It's OK that you defend your code and your proposal, but if you look at the big picture the the choice should be clear, right? Johannes *) In Germany we call this day Sankt Nimmerleinstag Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [v4l-dvb-maintainer] DVB Maintainer
On Mon, Apr 16, 2007, Manu Abraham wrote: Johannes Stezenbach wrote: On Mon, Apr 16, 2007, Manu Abraham wrote: Would have appreciated your stand, if you had the same stand on other threads as well. (IIRC your stand on the DVB-S2/multiproto threads were completely opposite. You wanted to hold things back) That is not true. Your first proposal was crap, yet you asked Mauro the merge it and even got ACKs from others. So I pointed out that I thought it needs more work. Ok, if my first proposal was crap, it is crap still. After the driver was completed _most_ of the stuff had to be done according to the old proposal, because the delivery system does indeed need them (not just useless params) You were asleep throughout the discussion. For Marcel's request you said it was okay too. After that you had a dream or something like that and even apologized for your last minute barging in, also that you didn't understand about DVB-S2. It wasn't anyone else's fault that you NACK'd it after asking Mauro to pull, but yours alone. You could have done it earlier too.. or just kept quiet. Was a waste of time for so many people involved. I rejected the DVB-S2 proposal when I first read about it -- which was when you asked Mauro to merge it. The discussions about the DVB-S2 API that followed were dragged out over a period of serveral weeks, if not months. And at the end of the discussions your proposal looked totally different than your first one. And the agreement was that you and others implement a driver and show the API works in practice, then it can be merged. I'm sure you will tell us when you think it's ready. The list archives can tell the full story. Since you are so good at finding stuff in archives I'm confident you can find the key postings if you only want to. And if there was a please review or Mauro, please merge mail regarding multiproto recently, I must have missed it. Sorry. You said you didn't have the time after everything was done, inspite of many mails sent to you. If someone NACK's something for a reason and when those things are fixed, the same person could at least show a bit of courtesy by stating the same problems are/were fixed. I told you many times that I'm not interested in DVB anymore, thus I won't spend my time reviewing code or discussing architecture, especially if it's sent to me in private. I'm really so out of it that the details escape me anyway. The reason why I speak up here occationally is that I do care about Linux' as a whole. I try to help out if I think things start to go wrong in DVB land. Too bad you see this as a personal attack or a Markus vs. Manu thing. :-( The merging of em28xx has in fact absolutely nothing to do with DVB-S2. So we merge em28xx now and DVB-S2 later. What's the problem? Johannes ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: [v4l-dvb-maintainer] DVB Maintainer
Johannes Stezenbach wrote: On Mon, Apr 16, 2007, Manu Abraham wrote: Johannes Stezenbach wrote: On Mon, Apr 16, 2007, Manu Abraham wrote: Would have appreciated your stand, if you had the same stand on other threads as well. (IIRC your stand on the DVB-S2/multiproto threads were completely opposite. You wanted to hold things back) That is not true. Your first proposal was crap, yet you asked Mauro the merge it and even got ACKs from others. So I pointed out that I thought it needs more work. Ok, if my first proposal was crap, it is crap still. After the driver was completed _most_ of the stuff had to be done according to the old proposal, because the delivery system does indeed need them (not just useless params) You were asleep throughout the discussion. For Marcel's request you said it was okay too. After that you had a dream or something like that and even apologized for your last minute barging in, also that you didn't understand about DVB-S2. It wasn't anyone else's fault that you NACK'd it after asking Mauro to pull, but yours alone. You could have done it earlier too.. or just kept quiet. Was a waste of time for so many people involved. I rejected the DVB-S2 proposal when I first read about it -- which was when you asked Mauro to merge it. The discussions about the DVB-S2 API that followed were dragged out over a period of serveral weeks, if not months. And at the end of the discussions your proposal looked totally different than your first one. And the agreement was that you and others implement a driver and show the API works in practice, then it can be merged. I'm sure you will tell us when you think it's ready. The list archives can tell the full story. Since you are so good at finding stuff in archives I'm confident you can find the key postings if you only want to. And if there was a please review or Mauro, please merge mail regarding multiproto recently, I must have missed it. Sorry. You said you didn't have the time after everything was done, inspite of many mails sent to you. If someone NACK's something for a reason and when those things are fixed, the same person could at least show a bit of courtesy by stating the same problems are/were fixed. I told you many times that I'm not interested in DVB anymore, thus I won't spend my time reviewing code or discussing architecture, especially if it's sent to me in private. I'm really so out of it that the details escape me anyway. The reason why I speak up here occationally is that I do care about Linux' as a whole. I try to help out if I think things start to go wrong in DVB land. Too bad you see this as a personal attack or a Markus vs. Manu thing. :-( Too bad that you saw it that way. I wasn't looking at it that way. I did throw in the towel completely at one point completely. Because of many short sighted decisions many things are broken and hence commented on the same. If you don't see the value in it, just throw everything into the trash, who cares As simple as that. Manu ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Tuning broken in development branch, 2.6.20 for lowest freq channel with TT DVB-C 1500
Hello Hardware: Technotrend DVB-C 1500, CI, Conax CAM, Asus P5B Am I the only one left alone without working system with current development v4l tree? Somewhere between 2.6.18.1 and 2.6.20 (and current mercurial, also) something changed, and tuning to Discovery channel no longer works at least for me. With 2.6.18.1 plain vanilla kernel, Discovery channel on 138 Mhz works fine: mythtv:/home/mythtv/.czap# czap -a 1 -c disco.conf Discovery using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' reading channels from file 'disco.conf' 1 Discovery:13800:INVERSION_AUTO:690:FEC_NONE:QAM_128:900:901:406 1 Discovery: f 13800, s 690, i 2, fec 0, qam 4, v 0x384, a 0x385 status 1f | signal 0324 | snr 1224 | ber | unc | FE_HAS_LOCK status 1f | signal 0325 | snr 0fbd | ber | unc | FE_HAS_LOCK status 1f | signal 0325 | snr 104c | ber | unc | FE_HAS_LOCK status 1f | signal 0325 | snr 1107 | ber | unc | FE_HAS_LOCK status 1f | signal 0325 | snr 1154 | ber | unc | FE_HAS_LOCK status 1f | signal 0325 | snr 10da | ber | unc | FE_HAS_LOCK but if I try with 2.6.20 or v4l mercurial: mythtv:/home/mythtv/.czap# czap -a 1 -c disco.conf Discovery using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' reading channels from file 'disco.conf' 1 Discovery:13800:INVERSION_AUTO:690:FEC_NONE:QAM_128:900:901:406 1 Discovery: f 13800, s 690, i 2, fec 0, qam 4, v 0x384, a 0x385 status 00 | signal 0329 | snr 2368 | ber | unc | status 00 | signal 0329 | snr 06fc | ber | unc | status 00 | signal 032a | snr 07eb | ber | unc | status 00 | signal 032a | snr 07e4 | ber | unc | status 00 | signal 0328 | snr 0678 | ber | unc | .. no lock, no picture .. All the other multiplexes work ok with both setups, except for one HD channel with QAM256, which has some artifacts, but that's a different issue... It seems that on the problematic set, SNR is large on first seconds and drops fast after that. Possibly a timing issue?? Anyone have ideas how to debug this? --Kari ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Opera S1- DVB-USB
On Mon, 16 Apr 2007, Marco Gittler wrote:
Thanks for your answer
if fixed the things you wrote, and now it look a bit nicer.
the values used here for many command here are unknown to me, because i have
no doc for this part of dvb box.
It would be nice if you can add some comments for things that you've
already guessed, pointing that it is just a guess.
so i this first enough to put it in and have some more testern for this
device ?
For me, it seems ok now. I'll apply it later at master tree, to allow more
people to test it. This will bring us about 3 weeks for testing and decide
if this is ready for 2.6.22 or not.
This will also give opportunity to other guys to send their comments,
patches and sugestions to improve your driver.
Cheers,
Mauro.
[EMAIL PROTECTED] schrieb:
Hi Marco,
I've some comments bellow about your patch.
Cheers,
Mauro
Em Dom, 2007-04-15 às 19:55 +0200, Marco Gittler escreveu:
+config DVB_USB_OPERA1
+tristate Opera1 DVB-S USB2.0 receiver
+depends on DVB_USB
+select DVB_STV0299 + #if !DVB_FE_CUSTOMISE
Why the above is commented? If DVB_FE_CUSTOMISE is not yet supported,
just remove it, but the better is to allow supporting it.
+static const u8* xilinx_init=\x90\x6e\xc5\xfa\x32\xd0\x73\x23\x1e;
Instead of writing as a string, better to write as a char array:
static const u8* xilinx_init= {0x90, 0x6e, 0xc5, ...
Better yet if you can better document the values at the array, by
replacing it by aliases, like:
static const u8* xilinx_init= { R90_INIT_DEV, R60_SELECT_MODE, ...
(of course if you know what the init is doing)
+ memset(r,0,10);
Avoid using magic numbers. Instead, do:
memset (r,0,sizeof(*r));
+ //if (mutex_lock_interruptible(mymutex)){
+ //return -EAGAIN;
+ //}
Instead, use #if 0 for commenting codes like the above
Also, to follow kernel Documentation/CodingStyle, you should do:
if (foo) {
instead of if (foo){
The same trouble (and other CodingStyle things, like column max size)
happens also on other parts of the code. Maybe the better is to run
indent with the following options:
indent -kr -i8 -ts8 -sob -l80 -ss -ncs files
This will apply several common CodingStyle used on kernel. You should
review the code, since sometimes it mess some stuff and remove spaces
used for alignment on some undesirable places.
So, the above should be something like this:
#if 0
if (mutex_lock_interruptible(mymutex)) {
return -EAGAIN;
}
#endif
+ ret=usb_control_msg(dev, pipe,request, request_type|
USB_TYPE_VENDOR,value, 0x0 /*index*/, u8buf,len, 2000);
The /*index*/ comment here is useless and can be removed.
+ }else
+ *state = REMOTE_NO_KEY_PRESSED;
+ return 0;
Hmm... return 0 is wrongly indented here.
+ if(ret==0)
+ {
Another CodingStyle. Should be, instead
if ( ret==0 ) {
+ // clear fpga ?
Generally, we avoid using c++ style comments, using instead:
/* clear fpga */
+ .entries = {
+ { 1064000, 500, 0xe5, 0xc6 },
+ { 1169000, 500, 0xe5, 0xe6 },
+ {1299000, 500, 0xe5, 0x24 },
Hmm... this went missaligned at the email. Probably, you've mixed tabs
with spaces. Better to use or one or the other at the table.
Cheers,
Mauro
--
Cheers,
Mauro Carvalho Chehab
http://linuxtv.org
[EMAIL PROTECTED]___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Mantis driver - Where to download?
Hello, Where is it possible to download the mantis drivers? -- Regards, Andrej Jouravlev ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis driver - Where to download?
Andrej Jouravlev wrote: Hello, Where is it possible to download the mantis drivers? -- Regards, Andrej Jouravlev ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb http://jusst.de/manu/mantis-v4l-dvb.tar.bz2 ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [PATCH] Fix the tid within the generated output files from the scan utility
Hi,
the scan utility has a little bug. If a sdt is found, the informations for a
channel is created. If no nit was found up
to this point, the informations of a transponder does only contains the
information from the initial scan file. The
entry of the the transport stream id (tid) isn't initialized yet. The tid is
always 0 for such channels. For my local
setup (DVB-C with the German provider 'Kabel BW'), this occurs always for the
first transponder. The attached patch will
fix this problem (only) for the generated channel files. The fix stores a
pointer of the transponder within the channel
info instead of the tid from the transponder. At the time where the output file
is generated, a valid nit parsing may
update all transponders. In this case, the tid is valid. A better solution may
be: start the sdt parsing only, if a
valid nit was found.
Signed off by: Hartmut Birr [EMAIL PROTECTED]
- Hartmut
diff -r aeddd2c75f4a util/scan/scan.c
--- a/util/scan/scan.c Mon Apr 16 18:02:52 2007 +0200
+++ b/util/scan/scan.c Sat Nov 18 14:15:35 2006 +0200
@@ -102,9 +102,28 @@ enum running_mode {
#define AUDIO_CHAN_MAX (32)
#define CA_SYSTEM_ID_MAX (16)
+struct transponder {
+ struct list_head list;
+ struct list_head services;
+ int network_id;
+ int original_network_id;
+ int transport_stream_id;
+ enum fe_type type;
+ struct dvb_frontend_parameters param;
+ enum polarisation polarisation; /* only for DVB-S */
+ int orbital_pos; /* only for DVB-S */
+ unsigned int we_flag : 1; /* West/East Flag - only for DVB-S */
+ unsigned int scan_done : 1;
+ unsigned int last_tuning_failed : 1;
+ unsigned int other_frequency_flag : 1; /* DVB-T */
+ unsigned int wrong_frequency : 1; /* DVB-T with other_frequency_flag */
+ int n_other_f;
+ uint32_t *other_f; /* DVB-T freqeuency-list descriptor */
+};
+
struct service {
struct list_head list;
- int transport_stream_id;
+ struct transponder* transponder;
int service_id;
char *provider_name;
char *service_name;
@@ -126,26 +145,6 @@ struct service {
int channel_num;
};
-struct transponder {
- struct list_head list;
- struct list_head services;
- int network_id;
- int original_network_id;
- int transport_stream_id;
- enum fe_type type;
- struct dvb_frontend_parameters param;
- enum polarisation polarisation; /* only for DVB-S */
- int orbital_pos; /* only for DVB-S */
- unsigned int we_flag : 1; /* West/East Flag - only for DVB-S */
- unsigned int scan_done : 1;
- unsigned int last_tuning_failed : 1;
- unsigned int other_frequency_flag : 1; /* DVB-T */
- unsigned int wrong_frequency : 1; /* DVB-T with other_frequency_flag */
- int n_other_f;
- uint32_t *other_f; /* DVB-T freqeuency-list descriptor */
-};
-
-
struct section_buf {
struct list_head list;
const char *dmx_devname;
@@ -265,7 +264,7 @@ static struct service *alloc_service(str
struct service *s = calloc(1, sizeof(*s));
INIT_LIST_HEAD(s-list);
s-service_id = service_id;
- s-transport_stream_id = tp-transport_stream_id;
+ s-transponder = tp;
list_add_tail(s-list, tp-services);
return s;
}
@@ -588,7 +587,7 @@ static void parse_service_descriptor (co
}
info(0x%04x 0x%04x: pmt_pid 0x%04x %s -- %s (%s%s)\n,
- s-transport_stream_id,
+ s-transponder-transport_stream_id,
s-service_id,
s-pmt_pid,
s-provider_name, s-service_name,
@@ -818,7 +817,7 @@ static void parse_pmt (const unsigned ch
tmp += sprintf(tmp, , 0x%04x (%.4s), s-audio_pid[i], s-audio_lang[i]);
debug(0x%04x 0x%04x: %s -- %s, pmt_pid 0x%04x, vpid 0x%04x, apid %s\n,
- s-transport_stream_id,
+ s-transponder-transport_stream_id,
s-service_id,
s-provider_name, s-service_name,
s-pmt_pid, s-video_pid, msg_buf);
@@ -2008,7 +2007,7 @@ static void dump_lists (void)
s-ac3_pid,
s-service_id,
t-original_network_id,
- s-transport_stream_id,
+ s-transponder-transport_stream_id,
t-orbital_pos,
t-we_flag,
vdr_dump_provider,
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Afatech af9005 unstable reception [added: mt2060 gain control?]
Luca Olivetti wrote: En/na P. van Gaans ha escrit: (I don't post this message to the list) In your short replies I read I'm probably annoying you. Not at all! I'm sorry if it appears that way (I *am* annoyed by top posting though ;-) My replies aren't any longer because I don't have much more to say: I live very near to the transmitter and I have poor reception of one mux and the rest are so-so (both when I tried it under windows to sniff the data and under linux). Other users say it works fine for them, while other have the same reception problems. The commented out code was to try the opposite problem (too strong a signal) and according to Thomas Pinz it shouldn't really change anything, so don't bother trying it, it won't solve your problem as it didn't solve mine. I'm sorry. I'm no developer, I don't understand the technical stuff so I ask stupid questions. I'll go look for another solution, I guess the Afatech just isn't sensitive enough for my signal. Thanks for your help. This is probably a stupid question, but, you're using a roof-top antenna, and not the joke provided with the stick, right? Bye (I post this to the list again because it might be of some use to other users) I was annoyed by the joke that comes with the stick, well, in fact I was more annoyed by the fact the cable to convert the stick-connector to coax was missing. I cut the cable with the joke and screwed a coax connector onto it. My antenna isn't really on the roof, but it is just under it, indoors. It is impossible to locate the antenna at any higher point indoors. It is approx. 10 meters above the ground and on any other receiver I can see four different transmitters on it all around me. But I guess the signal isn't strong enough for the Afatech, quite possible since all my other receivers are quite sensitive. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Afatech af9005 unstable reception [added: mt2060 gain control?]
En/na Thomas Pinz - DC2RPT ha escrit: Hi Luca, On Monday 16 April 2007 08:57, Luca Olivetti wrote: I live ~6km to the transmitting tower, and I cannot get at least one mux (the rest are mostly fine though). But, in my case, it's the same under windows. On which channels are muxes (also the belgian one) ? An which of them don't you get ? Look at the es-Collserola file. I don't get c26 and c33, but I think that's normal, since those are local tv directed at Barcelona and I'm at the opposite side (though I could get a glimpse once of c26). c61 is the best of all, the others are so-so and the problematic one is c64. Maybe you can also find out the transmission power of the muxes. Here for example they are not equal. According to some forums neither are here, and it seems they screwed many times with that mux. However I still think I should receive it fine. Probably they'll increase the power, or I'll have to raise the antenna (I have a building blocking direct line of sight to the tower) Bye -- Luca ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] patch, which supports some new DVB-C budget cards
Janne Grunau wrote: On Thursday 12 April 2007 00:01:43 e9hack wrote: I've split the patch like the description above. Thanks. Patched v4l-dvb hg still works for my Cinergy DVB-C (with tda10021) and KNC One V1.0. Hi, how is the status for integrating this patch into the v4l-dvb repository? - Hartmut ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Patches adding QT1010 support for EM2880 (and also for a broken DIBCOM)
Hi David, thanks for your patch! can you add a small line describing your patches (which can be used for committing the code) Patch1: description1 Signed-off-by: yourname youremail Patch2: description2 Signed-off-by: yourname youremail then we're complete with the formal part as well. I'd say the dibcom patch can be applied directly to the master repository, the qt1010 patch will get applied to the v4l-dvb-experimental tree on mcentral.de thanks, Markus On 4/17/07, David Edwards [EMAIL PROTECTED] wrote: Dear Markus As requested, please find attached patches that get an EM2880 device working with a QT1010, and a DIBCOM device that has a duff Vendor and Product ID when cold. The patches are against hg clone http://mcentral.de/hg/~mrec/v4l-dvb-experimental taken this evening at 20:08 GMT. My kernel is 2.6.20-15-generic for Ubuntu 7.04, upgraded this morning. The kernel messages from the two devices are below, the DIBCOM first. The sound and picture for the QT1010 device (which is actually a KWorld 380U, which apparently has the same USB Vendor and Product ID as the 355U), by comparison with the DIBCOM, are terrible, but recognisable, using the same aerial for both. I don't know if it is any better under Windows. Best regards David Edwards Apr 16 22:39:46 e2acer kernel: [ 145.196000] usb 3-2: new full speed USB device using uhci_hcd and address 2 Apr 16 22:39:46 e2acer kernel: [ 145.344000] usb 3-2: configuration #1 chosen from 1 choice Apr 16 22:39:46 e2acer kernel: [ 145.696000] dvb-usb: found a 'KWorld V-Stream XPERT DTV - DVB-T USB1.1 Duff' in cold state, will try to load a firmware Apr 16 22:39:46 e2acer kernel: [ 145.732000] dvb-usb: downloading firmware from file 'dvb-usb-dibusb-5.0.0.11.fw' Apr 16 22:39:47 e2acer kernel: [ 146.232000] usbcore: registered new interface driver dvb_usb_dibusb_mb Apr 16 22:39:47 e2acer kernel: [ 146.468000] usb 3-2: USB disconnect, address 2 Apr 16 22:39:47 e2acer kernel: [ 146.468000] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. Apr 16 22:39:49 e2acer kernel: [ 148.192000] usb 3-2: new full speed USB device using uhci_hcd and address 3 Apr 16 22:39:49 e2acer kernel: [ 148.352000] usb 3-2: configuration #1 chosen from 1 choice Apr 16 22:39:49 e2acer kernel: [ 148.356000] dvb-usb: found a 'DiBcom USB1.1 DVB-T reference design (MOD3000)' in warm state. Apr 16 22:39:49 e2acer kernel: [ 148.376000] dvb-usb: will use the device's hardware PID filter (table count: 16). Apr 16 22:39:49 e2acer kernel: [ 148.376000] DVB: registering new adapter (DiBcom USB1.1 DVB-T reference design (MOD3000)). Apr 16 22:39:49 e2acer kernel: [ 148.38] DVB: registering frontend 0 (DiBcom 3000M-B DVB-T)... Apr 16 22:39:49 e2acer kernel: [ 148.384000] dibusb: This device has the Thomson Cable onboard. Which is default. Apr 16 22:39:49 e2acer kernel: [ 148.384000] input: IR-receiver inside an USB DVB receiver as /class/input/input9 Apr 16 22:39:49 e2acer kernel: [ 148.384000] dvb-usb: schedule remote query interval to 150 msecs. Apr 16 22:39:49 e2acer kernel: [ 148.404000] dvb-usb: DiBcom USB1.1 DVB-T reference design (MOD3000) successfully initialized and connected. Apr 16 22:40:38 e2acer kernel: [ 197.044000] dvb-usb: bulk message failed: -71 (1/1) Apr 16 22:40:38 e2acer kernel: [ 197.092000] usb 3-2: USB disconnect, address 3 Apr 16 22:40:38 e2acer kernel: [ 197.092000] dvb-usb: DiBcom USB1.1 DVB-T reference design (MOD3000) successfully deinitialized and disconnected. Apr 16 22:41:09 e2acer kernel: [ 228.60] usb 4-6: new high speed USB device using ehci_hcd and address 4 Apr 16 22:41:09 e2acer kernel: [ 228.732000] usb 4-6: configuration #1 chosen from 1 choice Apr 16 22:41:10 e2acer kernel: [ 228.948000] Linux video capture interface: v2.00 Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx v4l2 driver version 0.0.1 loaded Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx new video device (eb1a:e357): interface 0, class 255 Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx: device is attached to a USB 2.0 bus Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx: you're using the experimental/unstable tree from mcentral.de Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx: there's also a stable tree available but which is limited to Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx: linux =2.6.19.2 Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx: it's fine to use this driver but keep in mind that it will move Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx: to http://mcentral.de/hg/~mrec/v4l-dvb-kernel as soon as it's Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx: proved to be stable Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx #0: Alternate settings: 8 Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx #0: Alternate setting 0, max size= 0 Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx #0: Alternate setting 1, max size= 0 Apr 16 22:41:10 e2acer kernel: [
[linux-dvb] Re: Patches adding QT1010 support for EM2880 (and also for a broken DIBCOM)
Since this patch was smaller than expected, it was easy to review it.. changes to tuner-types.c and tuner.h weren't necessary since these files are only valid for analogue tuners. Can you submit a channelscan for your area? (using dvbscan/scan) I'm surprised that it seems to work for you. Markus On 4/17/07, Markus Rechberger [EMAIL PROTECTED] wrote: Hi David, thanks for your patch! can you add a small line describing your patches (which can be used for committing the code) Patch1: description1 Signed-off-by: yourname youremail Patch2: description2 Signed-off-by: yourname youremail then we're complete with the formal part as well. I'd say the dibcom patch can be applied directly to the master repository, the qt1010 patch will get applied to the v4l-dvb-experimental tree on mcentral.de thanks, Markus On 4/17/07, David Edwards [EMAIL PROTECTED] wrote: Dear Markus As requested, please find attached patches that get an EM2880 device working with a QT1010, and a DIBCOM device that has a duff Vendor and Product ID when cold. The patches are against hg clone http://mcentral.de/hg/~mrec/v4l-dvb-experimental taken this evening at 20:08 GMT. My kernel is 2.6.20-15-generic for Ubuntu 7.04, upgraded this morning. The kernel messages from the two devices are below, the DIBCOM first. The sound and picture for the QT1010 device (which is actually a KWorld 380U, which apparently has the same USB Vendor and Product ID as the 355U), by comparison with the DIBCOM, are terrible, but recognisable, using the same aerial for both. I don't know if it is any better under Windows. Best regards David Edwards Apr 16 22:39:46 e2acer kernel: [ 145.196000] usb 3-2: new full speed USB device using uhci_hcd and address 2 Apr 16 22:39:46 e2acer kernel: [ 145.344000] usb 3-2: configuration #1 chosen from 1 choice Apr 16 22:39:46 e2acer kernel: [ 145.696000] dvb-usb: found a 'KWorld V-Stream XPERT DTV - DVB-T USB1.1 Duff' in cold state, will try to load a firmware Apr 16 22:39:46 e2acer kernel: [ 145.732000] dvb-usb: downloading firmware from file 'dvb-usb-dibusb-5.0.0.11.fw' Apr 16 22:39:47 e2acer kernel: [ 146.232000] usbcore: registered new interface driver dvb_usb_dibusb_mb Apr 16 22:39:47 e2acer kernel: [ 146.468000] usb 3-2: USB disconnect, address 2 Apr 16 22:39:47 e2acer kernel: [ 146.468000] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. Apr 16 22:39:49 e2acer kernel: [ 148.192000] usb 3-2: new full speed USB device using uhci_hcd and address 3 Apr 16 22:39:49 e2acer kernel: [ 148.352000] usb 3-2: configuration #1 chosen from 1 choice Apr 16 22:39:49 e2acer kernel: [ 148.356000] dvb-usb: found a 'DiBcom USB1.1 DVB-T reference design (MOD3000)' in warm state. Apr 16 22:39:49 e2acer kernel: [ 148.376000] dvb-usb: will use the device's hardware PID filter (table count: 16). Apr 16 22:39:49 e2acer kernel: [ 148.376000] DVB: registering new adapter (DiBcom USB1.1 DVB-T reference design (MOD3000)). Apr 16 22:39:49 e2acer kernel: [ 148.38] DVB: registering frontend 0 (DiBcom 3000M-B DVB-T)... Apr 16 22:39:49 e2acer kernel: [ 148.384000] dibusb: This device has the Thomson Cable onboard. Which is default. Apr 16 22:39:49 e2acer kernel: [ 148.384000] input: IR-receiver inside an USB DVB receiver as /class/input/input9 Apr 16 22:39:49 e2acer kernel: [ 148.384000] dvb-usb: schedule remote query interval to 150 msecs. Apr 16 22:39:49 e2acer kernel: [ 148.404000] dvb-usb: DiBcom USB1.1 DVB-T reference design (MOD3000) successfully initialized and connected. Apr 16 22:40:38 e2acer kernel: [ 197.044000] dvb-usb: bulk message failed: -71 (1/1) Apr 16 22:40:38 e2acer kernel: [ 197.092000] usb 3-2: USB disconnect, address 3 Apr 16 22:40:38 e2acer kernel: [ 197.092000] dvb-usb: DiBcom USB1.1 DVB-T reference design (MOD3000) successfully deinitialized and disconnected. Apr 16 22:41:09 e2acer kernel: [ 228.60] usb 4-6: new high speed USB device using ehci_hcd and address 4 Apr 16 22:41:09 e2acer kernel: [ 228.732000] usb 4-6: configuration #1 chosen from 1 choice Apr 16 22:41:10 e2acer kernel: [ 228.948000] Linux video capture interface: v2.00 Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx v4l2 driver version 0.0.1 loaded Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx new video device (eb1a:e357): interface 0, class 255 Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx: device is attached to a USB 2.0 bus Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx: you're using the experimental/unstable tree from mcentral.de Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx: there's also a stable tree available but which is limited to Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx: linux =2.6.19.2 Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx: it's fine to use this driver but keep in mind that it will move Apr 16 22:41:10 e2acer kernel: [ 229.028000] em28xx: to
Re: [linux-dvb] Will this USB DVB-T stick work under Linux?
Hi Nick, Thanks for your quick response. Did you try running kaffeine? Nick. I've just tried Kaffeine, however it was not able to tune any TV stations. I tried using AUTO and au-Canberra and both did not work. Here's the output echoed to the console when scanning using au-Canberra: Using DVB device 0:0 Zarlink MT352 DVB-T tuning DVB-T to 20550 Hz inv:2 bw:1 fecH:3 fecL:3 mod:3 tm:1 gi:1 hier:0 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Using DVB device 0:0 Zarlink MT352 DVB-T tuning DVB-T to 22650 Hz inv:2 bw:1 fecH:2 fecL:9 mod:3 tm:1 gi:2 hier:0 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Using DVB device 0:0 Zarlink MT352 DVB-T tuning DVB-T to 21950 Hz inv:2 bw:1 fecH:3 fecL:9 mod:3 tm:1 gi:1 hier:0 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Using DVB device 0:0 Zarlink MT352 DVB-T tuning DVB-T to 17750 Hz inv:2 bw:1 fecH:3 fecL:1 mod:3 tm:1 gi:1 hier:0 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Using DVB device 0:0 Zarlink MT352 DVB-T tuning DVB-T to 54350 Hz inv:2 bw:1 fecH:2 fecL:9 mod:3 tm:1 gi:2 hier:0 ... Not able to lock to the signal on the given frequency Frontend closed dvbsi: Cant tune DVB Transponders: 5 dvbsi: The end :) Channels found: 0 Cheers, Luc ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Will this USB DVB-T stick work under Linux?
On Mon, 16 Apr 2007 22:17:37 +1000 Luc Small [EMAIL PROTECTED] wrote: Hello, I have a slightly unusual USB DVB-T stick and I am trying to work out if it is supported by Linux. I purchased it from Oatley Electronics here in Australia. A picture and description can be viewed here: http://secure.oatleyelectronics.com//product_info.php?cPath=24products_id=348osCsid=3a2a89b61e884d851844e1d820c768e2 The device is enclosed in a metal casing with a typical 75ohm TV connector at one end, and the USB connector at the other. There are two holes in the case, allowing one red and one green LED to be visible when the device is operating (under Windows XP). I have prized off the metal casing to get a view of circuit board. It hosts, amongst other components, the following chips: - Zarlink MT352CG (Demodulator) - Infineon TUA6045 (Tuner) I do not think this tuner is supported yet. Infineon offers datasheets though... -- Aapo Tahkola ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Opera S1- DVB-USB
On Mon, 16 Apr 2007, Mauro Carvalho Chehab wrote:
On Mon, 16 Apr 2007, Marco Gittler wrote:
so i this first enough to put it in and have some more testern for this
device ?
For me, it seems ok now. I'll apply it later at master tree, to allow more
people to test it. This will bring us about 3 weeks for testing and decide
if this is ready for 2.6.22 or not.
This will also give opportunity to other guys to send their comments,
patches and sugestions to improve your driver.
diff -r b5be3479f070 linux/drivers/media/dvb/dvb-usb/Kconfig
--- a/linux/drivers/media/dvb/dvb-usb/Kconfig Sat Apr 14 16:19:13 2007 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/Kconfig Mon Apr 16 12:06:05 2007 +0200
@@ -110,6 +110,7 @@ config DVB_USB_CXUSB
Medion MD95700 hybrid USB2.0 device.
DViCO FusionHDTV (Bluebird) USB2.0 devices
+
Random blank line inserted.
diff -r b5be3479f070 linux/drivers/media/dvb/dvb-usb/opera1.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/dvb-usb/opera1.c Mon Apr 16 13:16:17 2007 +0200
[...]
+#include opera1.h
+#include linux/module.h
+#include linux/init.h
+#include linux/firmware.h
+#include dvb-usb.h
+#include dvb-pll.h
+#include stv0299.h
Includes should be first linux/*.h includes (with not ), then
include compat.h, then sub-system includes (e.g., dvb-usb.h), then your
includes. The linux/* then compat.h order is important, the rest not as
much.
+ int ret = 0, t = 0;
+ u8 r[10];
+ u8 u8buf[len];
[...]
+ memset(r, 0, sizeof(*r));
You don't need to initialize ret or t. It would easier to initialize r (I
don't think you need to anyway, but if you do) with u8 r[10] = {0}; Instead
of adding an extra call to memset(). Also the memset is wrong, it should
be memset(r, 0, sizeof(r)); as sizeof(*r) is 1, not 10.
Linux coding style is for one blank line after variables are declared and
before statements start.
The variable sized u8buf[len] array is a C99 feature. Are we allowed to
use this in the kernel? I'm not sure if this is allowed or not.
+ t = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
+ OPERA_TUNER_REQ, USB_DIR_IN | USB_TYPE_VENDOR,
+ 0x01, 0x0, r, 10, 2000);
You never use t anywhere. You should probably check if usb_con...() failed
and return an error or print something.
static int opera1_usb_i2c_msgxfer(struct dvb_usb_device *dev, u16 addr,
[...]
+ request = (addr 0xff00) 8;
+ if (!request)
+ request = 0xb1;
+ value = (addr 0xff);
+ if (flag OPERA_READ_MSG) {
+ value |= 0x01;
+static int opera1_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[],
[...]
+ if ((tmp = opera1_usb_i2c_msgxfer(d,
+ msg[i].addr,
The Linux I2C subsystem uses 7-bit addresses, while your code is using
8-bit addresses. You should either change opera1_usb_i2c_msgxfer() so it
uses 7-bit addreses, or change opera1_i2c_xfer() so it passes
msg[i].addr1 to opera1_usb_i2c_msgxfer(). This problem keeps comming
up again and again, you can check the list archives to find more
explainations.
opera1_i2c_xfer() would be better if you had this at the first line of
code:
if (!d)
return -ENODEV;
And the got rid of the extra if(d){ ... } part. Note that if d is NULL,
you will crash on the line that does mutex_lock_interruptible(d-i2c_mutex),
which is run _before_ you check if d is null. So the current if(d){ } is
pointless, you will crash before you get there.
+static struct stv0299_config opera1_stv0299_config = {
+ .demod_address = 0xd0,
[...]
+static int opera1_tuner_attach(struct dvb_usb_adapter *adap)
+{
+ adap-pll_addr = 0xc0;
The addresses are wrong, it should be 0x68 and 0x60. It works because your
i2c code is also wrong, and the mistakes cancel each other out.
+static int opera1_streaming_ctrl(struct dvb_usb_adapter *adap, int onoff)
+{
+ u8 buf_start[2] = { 0xff, 0x03 };
+ u8 buf_stop[2] = { 0xff, 0x00 };
Declare constant arrays like this as static const.
+static int opera1_rc_query(struct dvb_usb_device *dev, u32 * event, int *state)
[...]
+ memset(rcbuffer, 0, 32);
This memset isn't necessary, you're just going to over-write it with the i2c
command.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] patch, which supports some new DVB-C budget cards
e9hack wrote: Janne Grunau wrote: On Thursday 12 April 2007 00:01:43 e9hack wrote: I've split the patch like the description above. Thanks. Patched v4l-dvb hg still works for my Cinergy DVB-C (with tda10021) and KNC One V1.0. Hi, how is the status for integrating this patch into the v4l-dvb repository? If nobody objects, I'll commit the patchset to HG next weekend. Oliver -- VDR Remote Plugin 0.3.9 available at http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Will this USB DVB-T stick work under Linux?
Hi Aapo, Thanks for your email. I do not think this tuner [TUA6045] is supported yet. Infineon offers datasheets though... Assuming for a moment that I were to write a driver for the TUA6045: 1. Is it at all likely that an existing driver could be adapted to work with this device? i.e. are other tuners by Infineon supported under Linux and, if so, how significantly do the tuners typically differ in terms of how drivers interact with them? It would, after all, be much easier to start with something (i.e. an existing driver) than to start from scratch. 2. If I did succeed in writing such a driver, would I still face an issue with firmware? i.e. the stick seems to be loaded (under Windows XP) with CE firmware rather than the Hanftek firmware that Linux loads onto it. Is there any way to get hold of this (CE) firmware or to extract it from the Windows drivers? Best wishes, Luc On 4/17/07, Aapo Tahkola [EMAIL PROTECTED] wrote: On Mon, 16 Apr 2007 22:17:37 +1000 Luc Small [EMAIL PROTECTED] wrote: Hello, I have a slightly unusual USB DVB-T stick and I am trying to work out if it is supported by Linux. I purchased it from Oatley Electronics here in Australia. A picture and description can be viewed here: http://secure.oatleyelectronics.com//product_info.php?cPath=24products_id=348osCsid=3a2a89b61e884d851844e1d820c768e2 The device is enclosed in a metal casing with a typical 75ohm TV connector at one end, and the USB connector at the other. There are two holes in the case, allowing one red and one green LED to be visible when the device is operating (under Windows XP). I have prized off the metal casing to get a view of circuit board. It hosts, amongst other components, the following chips: - Zarlink MT352CG (Demodulator) - Infineon TUA6045 (Tuner) I do not think this tuner is supported yet. Infineon offers datasheets though... -- Aapo Tahkola ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Will this USB DVB-T stick work under Linux?
2. If I did succeed in writing such a driver, would I still face an issue with firmware? i.e. the stick seems to be loaded (under Windows XP) with CE firmware rather than the Hanftek firmware that Linux loads onto it. Is there any way to get hold of this (CE) firmware or to extract it from the Windows drivers? It uses soft-loading of the FX2 chip it seems - scan your C:\windows\system32\drivers (or ..\system32 to be safe) for a file named *.spt (might be called samenameasdriver.spt or something similar). That's the firmware in cypress soft-load format. -tc ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [Patch] USBVision - Fix NT1005 Bridge detection
Em Dom, 2007-04-15 às 23:35 -0700, Dwaine Garden escreveu:
I agree too... I tested out both patches Mauro and trents patches.
I did not get any ops, and tested the patches for about three hours.
I did not have the device removed, so I would assume it the dummy
device definition that's causing the problem.
I vote that we should get rid of the dummy device. It's always
caused a great deal of headaches. We should probably set it up like
the saa7134 devices.
I vote also to remove the dummy. Proper parameters will do the job.
- Original Message
From: Thierry MERLE [EMAIL PROTECTED]
To: Mauro Carvalho Chehab [EMAIL PROTECTED]
Cc: Dwaine Garden [EMAIL PROTECTED]; Linux and Kernel Video
[EMAIL PROTECTED]; Linux DVB linux-dvb@linuxtv.org
Sent: Saturday, April 14, 2007 1:26:19 PM
Subject: [linux-dvb] Re: [Patch] USBVision - Fix NT1005 Bridge
detection
Mauro Carvalho Chehab a écrit :
Hi Dwaine and Thierry,
The patch seems to be ok. However, it is not nice to do this:
+ if ((!strcmp(usbvision_device_data[model].ModelString,
Dazzle
Fusion Model DVC-90 Rev 1 (SECAM)))
Since, if for some reason, people decide to change the comment at
usbvision-cards, it will break the above code. Instead, it is better
to
create a code for each board and for its value.
I've did such change on:
http://linuxtv.org/hg/~mchehab/usbvision
It also honors CodingStyle max line size.
I've also removed some duplicated stuff (ID Vendor/Product) and
changed
some flags to use bitmap. As result, It saved about 1K of
kernelspace
area.
I also noticed that the same name string were used for more than one
board. So, I've added a number for the duplicated names to avoid
having
the same name for two different boards. It would be better, however,
to
replace the duplicated definitions to a proper one, or to merge the
entries, if they are just referring to the same board.
May you test it and comment?
Acked-by: Thierry MERLE [EMAIL PROTECTED]
I agree totally with this simplification.
I am currently debugging the Trent's patch that makes a kernel oops
and
I don't know why.
The usbvision_probe is called event if the device is not plugged, and
the kernel oops occurs on this piece of code:
model = devid-driver_info;
printk(KERN_INFO %s: %s found\n, __FUNCTION__,
usbvision_device_data[model].ModelString);
Memory alignment problem ? Why this probe is called even if there is
no
device plugged-in ?
By putting something like:
model = devid-driver_info;
if(model0 || model HPG_WINTV) {
printk(KERN_INFO model out of bounds %d\n,model);
return -ENODEV;
} else printk(KERN_INFO model is %d\n,model);
The problem disappeared...
Regards,
Thierry
Apr 14 18:17:10 localhost kernel: BUG: unable to handle kernel paging
request at virtual address 0917ab30
Apr 14 18:17:10 localhost kernel: printing eip:
Apr 14 18:17:10 localhost kernel: c01d837b
Apr 14 18:17:10 localhost kernel: *pde =
Apr 14 18:17:10 localhost kernel: Oops: [#1]
Apr 14 18:17:10 localhost kernel: Modules linked in: usbvision
videodev
tuner v4l2_common snd_pcm_oss snd_mixer_oss cpufreq_conservative
cinergyT2 dvb_core
mga drm ns558 analog joydev nvidia(P) snd_hda_intel snd_hda_codec
snd_pcm snd_timer snd snd_page_alloc
Apr 14 18:17:10 localhost kernel: CPU:0
Apr 14 18:17:10 localhost kernel:
EIP:0060:[c01d837b]Tainted:
P VLI
Apr 14 18:17:10 localhost kernel: EFLAGS: 00210097 (2.6.21-rc6 #7)
Apr 14 18:17:10 localhost kernel: EIP is at vsnprintf+0x2d1/0x4d3
Apr 14 18:17:10 localhost kernel: eax: 0917ab30 ebx: c03f01b4
ecx:
0917ab30 edx: fffe
Apr 14 18:17:10 localhost kernel: esi: c75ebe7c edi: 000a
ebp:
esp: c75ebd98
Apr 14 18:17:10 localhost kernel: ds: 007b es: 007b fs: 00d8 gs:
0033 ss: 0068
Apr 14 18:17:10 localhost kernel: Process modprobe (pid: 4759,
ti=c75ea000 task=e24e6520 task.ti=c75ea000)
Apr 14 18:17:10 localhost kernel: Stack: e7dde000 ead775e0 584da500
ead775e0 c03ef3e0 ead775e0
Apr 14 18:17:10 localhost kernel: c03f05a0 0400
c03f01a0 ed0edf6f 0400 eb9c6400 c03f01a0
Apr 14 18:17:10 localhost kernel:ea412fa0 c01d858f c75ebe74
e49c9b70 c0117ec8 c75ebe74 ebc3fc18 0001
Apr 14 18:17:10 localhost kernel: Call Trace:
Apr 14 18:17:10 localhost kernel: [c01d858f] vscnprintf+0x12/0x1d
Apr 14 18:17:10 localhost kernel: [c0117ec8] vprintk+0x4d/0x1f3
Apr 14 18:17:10 localhost kernel: [c0177830] __sysfs_new_dirent
+0x12/0x40
Apr 14 18:17:10 localhost kernel: [c017791a]
__sysfs_make_dirent+0x11/0x6c
Apr 14 18:17:10 localhost kernel: [c0117e78] printk+0x16/0x19
Apr 14 18:17:10 localhost kernel: [ed0eaa40]
usbvision_probe+0x9a/0x3f6 [usbvision]
Apr 14 18:17:10 localhost kernel: [c02665e2]
usb_probe_interface+0x66/0x88
Apr
