Re: DViCO FusionHDTV7 Dual Express I2C write failed
So what would a mainstream dual (or more) tuner card be? I've found these Fusions to be flaky. Had one die and another went flaky when I enabled the sleep mode. Can't really afford any more now, but am always watching. A company called Ceton seems to havea quad, but it's a cable card tuner costing $450. On 1/19/2011 9:13 AM, Devin Heitmueller wrote: On Wed, Jan 19, 2011 at 10:59 AM, VDR Useruser@gmail.com wrote: Can someone please look into this and possibly provide a fix for the bug? I'm surprised it hasn't happened yet after all this time but maybe it's been forgotten the bug existed. You shouldn't be too surprised. In many cases device support for more obscure products comes not from the maintainer of the actual driver but rather from some random user who hacked in an additional board profile (in many cases, not doing it correctly but good enough so it works for them). In cases like that, the changes get committed, the original submitter disappears, and then when things break there is nobody with the appropriate knowledge and the hardware to debug the problem. Devin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DViCO FusionHDTV7 Dual Express I2C write failed
I just tried to update from kernel 2.6.34 and in doing so had to switch to git for v4l. I noticed the chip in this this post and saved it to look at latter. now I'm glad I did. I ran into the same problem. Driver seems to load ok, but when I try to start vdr I get thet same messages in syslog. Jan 16 21:50:48 LLLx64-32 vdr: [6170] saved setup to /usr/local/dvb/VDR/config/setup.conf Jan 16 21:50:49 LLLx64-32 kernel: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... Jan 16 21:50:49 LLLx64-32 kernel: xc5000: firmware read 12401 bytes. Jan 16 21:50:49 LLLx64-32 kernel: xc5000: firmware uploading... Jan 16 21:50:49 LLLx64-32 vdr: [6176] section handler thread ended (pid=6170, tid=6176) Jan 16 21:50:49 LLLx64-32 kernel: xc5000: I2C write failed (len=3) Jan 16 21:50:49 LLLx64-32 kernel: xc5000: firmware upload complete... Jan 16 21:50:50 LLLx64-32 vdr: [6175] tuner on frontend 0/0 thread ended (pid=6170, tid=6175) Jan 16 21:50:50 LLLx64-32 kernel: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... Jan 16 21:50:50 LLLx64-32 kernel: xc5000: firmware read 12401 bytes. Jan 16 21:50:50 LLLx64-32 kernel: xc5000: firmware uploading... Jan 16 21:50:50 LLLx64-32 vdr: [6174] CI adapter on device 0 thread ended (pid=6170, tid=6174) ... On 12/7/2010 12:07 PM, Mark Zimmerman wrote: Greetings: I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but which fails to initialize with the latest 2.6.36 kernel. The firmware fails to load due to an i2c failure. A search of the archives indicates that this is not the first time this issue has occurred. What can I do to help get this problem fixed? Here is the dmesg from 2.6.35, for the two tuners: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... xc5000: firmware read 12401 bytes. xc5000: firmware uploading... xc5000: firmware upload complete... xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... xc5000: firmware read 12401 bytes. xc5000: firmware uploading... xc5000: firmware upload complete.. and here is what happens with 2.6.36: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... xc5000: firmware read 12401 bytes. xc5000: firmware uploading... xc5000: I2C write failed (len=3) xc5000: firmware upload complete... xc5000: Unable to initialise tuner xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... xc5000: firmware read 12401 bytes. xc5000: firmware uploading... xc5000: I2C write failed (len=3) xc5000: firmware upload complete... -- Mark -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
too few arguments to function 'i2c_new_probed_device'
http://linux.derkeiler.com/Mailing-Lists/Kernel/2010-09/msg12477.html hg v4l today (01/16/2011). Doesn't do it when using linux-2.6.34 x64, but when trying to compile under linux-2.6.37 on a 32bit: /usr/local/dvb/drivers/v4l-20110116/v4l-dvb/v4l/bttv-i2c.c: In function 'init_bttv_i2c_ir': /usr/local/dvb/drivers/v4l-20110116/v4l-dvb/v4l/bttv-i2c.c:437: error: too few arguments to function 'i2c_new_probed_device' make[3]: *** [/usr/local/dvb/drivers/v4l-20110116/v4l-dvb/v4l/bttv-i2c.o] Error 1 make[2]: *** [_module_/usr/local/dvb/drivers/v4l-20110116/v4l-dvb/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-2.6.37' make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/local/dvb/drivers/v4l-20110116/v4l-dvb/v4l' make: *** [all] Error 2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx5000 default auto sleep mode
I am seeing a problem again. driver I'm using is v4l-20100625. Don't know if the tuner card is dieing again or what. I had the sleep mode turned on and have been using the fusion dual along with a 1800. THe 1800 shows as the 3rd device. Friday I had recordings setup on 2 channels at the same time and one started recording the wrong channel with a lot of pixiling. When I used femon to try switching through tuners one tuner disapeared and then the other tuner switched to the channel the other was incorectly trying to record. Ended up restarting vdr and the drivers. Today I found that epg data was missing for several channels. When I used femon to switch tuners, the second tuner was no signal. I have turned the power save back off and restarted. Hopefully all 3 tuners will work tonight. This would be the second fusion HDTV7 to go bad and it is in a different computer running x63 instead of x32. So ether there is a bug in the drivers or theses are really crappy tuners. On 5/10/2010 6:45 PM, Timothy D. Lenz wrote: On 4/14/2010 9:39 PM, Devin Heitmueller wrote: On Wed, Apr 14, 2010 at 11:44 PM, Andy Wallsawa...@md.metrocast.net wrote: On Wed, 2010-04-14 at 13:40 -0400, Devin Heitmueller wrote: On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenztl...@vorgon.com wrote: Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7 Dual express. Didn't know linux supported an auto sleep mode on the tuner chips and that it defaulted to on. Seems like it would be better to default to off. Regarding the general assertion that the power management should be disabled by default, I disagree. The power savings is considerable, the time to bring the tuner out of sleep is negligible, and it's generally good policy. Andy, do you have any actual details regarding the nature of the problem? Not really. DViCo Fusion dual digital tv card. One side of the card would yield black video screen when starting a digital capture sometime after (?) the VDR ATSC EPG plugin tried to suck off data. I'm not sure there was a causal relationship. I hypothesized that one side of the dual-tuner was going stupid or one of the two channels used in the cx23885 was getting confused. I was looking at how to narrow the problem down to cx23885 chip or xc5000 tuner, or s5h14xx demod when I noted the power managment module option for the xc5000. I suggested Tim try it. It was dumb luck that my guess actually made his symptoms go away. That's all I know. We did have a similar issue with the PCTV 800i. Basically, the GPIO definition was improperly defined for the xc5000 reset callback. As a result, it was strobing the reset on both the xc5000 *and* the s5h1411, which would then cause the s5h1411's hardware state to not match the driver state. After multiple round trips with the hardware engineer at PCTV, I finally concluded that there actually wasn't a way to strobe the reset without screwing up the demodulator, which prompted me to disable the xc5000 reset callback (see cx88-cards:2944). My guess is that the reset GPIO definition for that board is wrong (a problem exposed by this change), or that it's resetting the s5h1411 as well. Devin I replaced the single tuner with the other FusionHD7 Dual Express I had so there was two of the same cards. Within a few hours Both tuners where down on the original card and even restarting drivers wouldn't bring it back. So I moved the new card to it's slot and put the single back in in case the old card was defective. I removed the no power off switch and went out for awhile. When I came back vdr had crashed which often happens when it tried to tune and there is no signal as in when a tuner goes down. For some reason vdr/xine/xorg/vdpau combo is very unstable when signal is poor or missing. I wish we could dump xine as it seems to be the cause. I never had a problem with vdr crashing when it rained knocking out signal when the nexus card was providing video. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
FusionHDTV7 Dual express vs WinTV-HVR-2250?
I am looking to get another card to replace a fusionhdtv7 that died. After spending more then a year trying to get a problem pined down, it turns out the card was deffective. I tried contacting the company, There seems to be no mention of warranty period on the box, in the manual or on the web site. It may be there, But I didn't find it. The company hasn't responded. Hauppauge cards have proven to be good and well supported by linux and now I see the 2250 has driver support and may even get support for the analog side. People in the AVS forum seem to think the tuner used in the fusion are among the best, better then the LG 6th gen. What I'd like to know is how these two cards stand up to each other, both for their tuners and overall. It will be used in a computer along side a HVR-1800, and a nexus-s, though I would like to replace the nexus with a dual s/s2 at some point or add one since new cards are PCIe and the nexus is PCI. I have a limited number of free PCIe slots, so I am only looking at multi tuner cards. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: laggy remote on x64
I have now noticed that IR drivers are being loaded when I modprobe cx23885 to load the drivers for the HVR-1800 which doesn't even have a remote. The 32bit computer doesn't have this card, it has a Nexus and a FusionHDTV7 express. The drivers that are being loaded seem to be enough to get a responce from the nexus remote, but it's doing exactly the same thing as when I also modprobe ir_kbd_i2c which was always used in the past to load remote drivers for the nexus and is what I have been using to load drivers for the Fusion card. Is there some kind of conflict now? I've had the 1800 in the x64 system with the nexus for a long time but stopped using/updating it to get the 32bit system running. There seems to be a problem with the new IR drivers. On 6/29/2010 4:54 PM, Timothy D. Lenz wrote: I have 2 systems nearly identical except one runs 64bit and the other runs 32bit. I'm now trying to use the remote port on the nexus-s card. The 32 bit seems to be working ok, but the 64bit acts like it's bussy doing somthing else. It randomly won't respond to the remote. It doesn't buffer the keys or anything. Wait a moment and maybe it works fine for a few presses. When it doesn't respond is highly random. Kernel-2.6.34, debian squeeze updated a few days ago, v4l is hg from 06/25/2010 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
laggy remote on x64
I have 2 systems nearly identical except one runs 64bit and the other runs 32bit. I'm now trying to use the remote port on the nexus-s card. The 32 bit seems to be working ok, but the 64bit acts like it's bussy doing somthing else. It randomly won't respond to the remote. It doesn't buffer the keys or anything. Wait a moment and maybe it works fine for a few presses. When it doesn't respond is highly random. Kernel-2.6.34, debian squeeze updated a few days ago, v4l is hg from 06/25/2010 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ERROR: cKbdRemote: Invalid argument
Got remote back with new hg drivers. On 6/24/2010 8:04 PM, Timothy D. Lenz wrote: Not sure what caused this, but the remote was working and I did an apt-get update/upgrade and then it wasn't. Now the syslog is getting this repeating. Don't seem to have to use the remote for another entry to be added to the log. Jun 24 19:36:33 x64VDR vdr: [4903] ERROR: cKbdRemote: Invalid argument Using Debian Squeeze. remote is on a nexus-s and using ir_kbd_i2c -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ERROR: cKbdRemote: Invalid argument
Not sure what caused this, but the remote was working and I did an apt-get update/upgrade and then it wasn't. Now the syslog is getting this repeating. Don't seem to have to use the remote for another entry to be added to the log. Jun 24 19:36:33 x64VDR vdr: [4903] ERROR: cKbdRemote: Invalid argument Using Debian Squeeze. remote is on a nexus-s and using ir_kbd_i2c -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx5000 default auto sleep mode
Update, that card has now died. We bought 2 of those cards at the same time and the other has been working for a about 3 weeks with sleep mode disabled. I tried it with sleep mode enabled and ether vdr or xine crashed with in a few hours. But the version of xine I am still running on that computer is touchy about corrupt video streams and will crash when video starts pixeling or drops out totally for extended time. When I get a chance to update xine, I'll try turning auto sleep mode back on. I have sent a message to Dvico, but I don't expect much since I've now had the card for more then a year. I should have just tried the other card way back then, but I thought sure it was a software/driver problem since making changes did at times effect how long it worked. On 4/14/2010 9:39 PM, Devin Heitmueller wrote: On Wed, Apr 14, 2010 at 11:44 PM, Andy Wallsawa...@md.metrocast.net wrote: On Wed, 2010-04-14 at 13:40 -0400, Devin Heitmueller wrote: On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenztl...@vorgon.com wrote: Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7 Dual express. Didn't know linux supported an auto sleep mode on the tuner chips and that it defaulted to on. Seems like it would be better to default to off. Regarding the general assertion that the power management should be disabled by default, I disagree. The power savings is considerable, the time to bring the tuner out of sleep is negligible, and it's generally good policy. Andy, do you have any actual details regarding the nature of the problem? Not really. DViCo Fusion dual digital tv card. One side of the card would yield black video screen when starting a digital capture sometime after (?) the VDR ATSC EPG plugin tried to suck off data. I'm not sure there was a causal relationship. I hypothesized that one side of the dual-tuner was going stupid or one of the two channels used in the cx23885 was getting confused. I was looking at how to narrow the problem down to cx23885 chip or xc5000 tuner, or s5h14xx demod when I noted the power managment module option for the xc5000. I suggested Tim try it. It was dumb luck that my guess actually made his symptoms go away. That's all I know. We did have a similar issue with the PCTV 800i. Basically, the GPIO definition was improperly defined for the xc5000 reset callback. As a result, it was strobing the reset on both the xc5000 *and* the s5h1411, which would then cause the s5h1411's hardware state to not match the driver state. After multiple round trips with the hardware engineer at PCTV, I finally concluded that there actually wasn't a way to strobe the reset without screwing up the demodulator, which prompted me to disable the xc5000 reset callback (see cx88-cards:2944). My guess is that the reset GPIO definition for that board is wrong (a problem exposed by this change), or that it's resetting the s5h1411 as well. Devin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel oops with new IR modules
Looks like the patches fixed it. At least no oops this time. Now to install xine/vdpau and see if it all works On 6/14/2010 5:39 AM, Andy Walls wrote: On Sun, 2010-06-13 at 19:55 -0700, Timothy D. Lenz wrote: I tried to build new drivers from v4l hg for 06/08/10 and when I tried to load drivers I got a kernel oops. Kernel is 2.6.34 64bit for amd cpu http://pastebin.com/7KwJtFJg See: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/20198 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/19904 The Oops appears to be in the same place as the Oops I analyzed in the second link. However, your compiler, like mine, decides to code the comparison against RC_DRIVER_SCANCODE (which is 0) first: 4f: 83 3a 00 cmpl $0x0,(%rdx)-- Oopsing insn Right about here: http://linuxtv.org/hg/v4l-dvb/file/23492745405c/linux/drivers/media/IR/ir-sysfs.c#l226 As mentioned in the first link, please try the patch found here: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=84b14f181a36eea6591779156ef356f8d198bbfd Regards, Andy Jun 13 14:35:40 x64VDR kernel: IR JVC protocol handler initialized Jun 13 14:35:40 x64VDR kernel: IR Sony protocol handler initialized Jun 13 14:35:40 x64VDR kernel: cx23885_dev_checkrevision() Hardware revision = 0xb0 Jun 13 14:35:40 x64VDR kernel: cx23885[0]/0: found at :02:00.0, rev: 2, irq: 16, latency: 0, mmio: 0xfdc0 Jun 13 14:35:40 x64VDR kernel: cx23885 :02:00.0: setting latency timer to 64 Jun 13 14:35:40 x64VDR kernel: IRQ 16/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs Jun 13 14:35:40 x64VDR kernel: Registered IR keymap rc-fusionhdtv-mce Jun 13 14:35:40 x64VDR kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Jun 13 14:35:40 x64VDR kernel: IP: [a0229e30] ir_register_class+0x4f/0x15f [ir_core] Jun 13 14:35:40 x64VDR kernel: PGD 7ebdb067 PUD 7ebd3067 PMD 0 Jun 13 14:35:40 x64VDR kernel: Oops: [#1] PREEMPT SMP Jun 13 14:35:40 x64VDR kernel: last sysfs file: /sys/module/ir_core/initstate Jun 13 14:35:40 x64VDR kernel: CPU 1 Jun 13 14:35:40 x64VDR kernel: Modules linked in: rc_fusionhdtv_mce ir_kbd_i2c(+) ir_sony_decoder ir_jvc_decoder ir_rc6_decoder cx23885 ir_rc5_decoder cx2341x v4l2_common videobuf_dvb ir_common ir_nec_decoder ir_core btcx_risc tveeprom lnbp21 stv0299 dvb_ttpci dvb_core saa7146_vv videodev v4l1_compat v4l2_compat_ioctl32 saa7146 videobuf_dma_sg videobuf_core ttpci_eeprom powernow_k8 hwmon_vid max6650 snd_intel8x0 snd_ac97_codec ac97_bus smbfs af_packet snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_pcm snd_seq snd_timer snd_seq_device snd sg psmouse amd64_edac_mod k8temp fan soundcore snd_page_alloc asus_atk0110 i2c_nforce2 thermal processor button Jun 13 14:35:40 x64VDR kernel: Jun 13 14:35:40 x64VDR kernel: Pid: 1933, comm: modprobe Not tainted 2.6.34.20100610.1 #1 M2N-E/System Product Name Jun 13 14:35:40 x64VDR kernel: RIP: 0010:[a0229e30] [a0229e30] ir_register_class+0x4f/0x15f [ir_core] Jun 13 14:35:40 x64VDR kernel: RSP: 0018:88007e0abd18 EFLAGS: 00010246 Jun 13 14:35:40 x64VDR kernel: RAX: RBX: 88007ee5ec00 RCX: a022ae00 Jun 13 14:35:40 x64VDR kernel: RDX: RSI: a022a9d4 RDI: 88007ee5ec00 Jun 13 14:35:40 x64VDR kernel: RBP: R08: 004f R09: Jun 13 14:35:40 x64VDR kernel: R10: R11: 88007ee28808 R12: a029d060 Jun 13 14:35:40 x64VDR kernel: R13: 88007ee28000 R14: 0282 R15: a0296aec Jun 13 14:35:40 x64VDR kernel: FS: 7fdc8355d6f0() GS:88000170() knlGS: Jun 13 14:35:40 x64VDR kernel: CS: 0010 DS: ES: CR0: 8005003b Jun 13 14:35:40 x64VDR kernel: CR2: CR3: 7ebd1000 CR4: 06e0 Jun 13 14:35:40 x64VDR kernel: DR0: DR1: DR2: Jun 13 14:35:40 x64VDR kernel: DR3: DR6: 0ff0 DR7: 0400 Jun 13 14:35:40 x64VDR kernel: Process modprobe (pid: 1933, threadinfo 88007e0aa000, task 88007e22a280) Jun 13 14:35:40 x64VDR kernel: Stack: Jun 13 14:35:40 x64VDR kernel: 88007ee28000 88007ee5ec00 88007ee28000 a029d060 Jun 13 14:35:40 x64VDR kernel:0 002d a022960a 0001 Jun 13 14:35:40 x64VDR kernel:0 88007ee5ee20 88007ee5edf8 88007e0aa000 88007d815600 Jun 13 14:35:40 x64VDR kernel: Call Trace: Jun 13 14:35:40 x64VDR kernel: [a022960a] ? __ir_input_register+0x243/0x2e7 [ir_core] Jun 13 14:35:40 x64VDR kernel: [a02963aa] ? ir_probe+0x37f/0x448 [ir_kbd_i2c] Jun 13 14:35:40 x64VDR kernel: [a029602b] ? ir_probe+0x0/0x448 [ir_kbd_i2c] Jun 13 14:35:40 x64VDR kernel: [81222ce2] ? i2c_device_probe+0xb0/0xe6 Jun 13 14:35:40 x64VDR kernel: [811be322
Kernel oops with new IR modules
I tried to build new drivers from v4l hg for 06/08/10 and when I tried to load drivers I got a kernel oops. Kernel is 2.6.34 64bit for amd cpu http://pastebin.com/7KwJtFJg Jun 13 14:35:40 x64VDR kernel: IR JVC protocol handler initialized Jun 13 14:35:40 x64VDR kernel: IR Sony protocol handler initialized Jun 13 14:35:40 x64VDR kernel: cx23885_dev_checkrevision() Hardware revision = 0xb0 Jun 13 14:35:40 x64VDR kernel: cx23885[0]/0: found at :02:00.0, rev: 2, irq: 16, latency: 0, mmio: 0xfdc0 Jun 13 14:35:40 x64VDR kernel: cx23885 :02:00.0: setting latency timer to 64 Jun 13 14:35:40 x64VDR kernel: IRQ 16/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs Jun 13 14:35:40 x64VDR kernel: Registered IR keymap rc-fusionhdtv-mce Jun 13 14:35:40 x64VDR kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Jun 13 14:35:40 x64VDR kernel: IP: [a0229e30] ir_register_class+0x4f/0x15f [ir_core] Jun 13 14:35:40 x64VDR kernel: PGD 7ebdb067 PUD 7ebd3067 PMD 0 Jun 13 14:35:40 x64VDR kernel: Oops: [#1] PREEMPT SMP Jun 13 14:35:40 x64VDR kernel: last sysfs file: /sys/module/ir_core/initstate Jun 13 14:35:40 x64VDR kernel: CPU 1 Jun 13 14:35:40 x64VDR kernel: Modules linked in: rc_fusionhdtv_mce ir_kbd_i2c(+) ir_sony_decoder ir_jvc_decoder ir_rc6_decoder cx23885 ir_rc5_decoder cx2341x v4l2_common videobuf_dvb ir_common ir_nec_decoder ir_core btcx_risc tveeprom lnbp21 stv0299 dvb_ttpci dvb_core saa7146_vv videodev v4l1_compat v4l2_compat_ioctl32 saa7146 videobuf_dma_sg videobuf_core ttpci_eeprom powernow_k8 hwmon_vid max6650 snd_intel8x0 snd_ac97_codec ac97_bus smbfs af_packet snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_pcm snd_seq snd_timer snd_seq_device snd sg psmouse amd64_edac_mod k8temp fan soundcore snd_page_alloc asus_atk0110 i2c_nforce2 thermal processor button Jun 13 14:35:40 x64VDR kernel: Jun 13 14:35:40 x64VDR kernel: Pid: 1933, comm: modprobe Not tainted 2.6.34.20100610.1 #1 M2N-E/System Product Name Jun 13 14:35:40 x64VDR kernel: RIP: 0010:[a0229e30] [a0229e30] ir_register_class+0x4f/0x15f [ir_core] Jun 13 14:35:40 x64VDR kernel: RSP: 0018:88007e0abd18 EFLAGS: 00010246 Jun 13 14:35:40 x64VDR kernel: RAX: RBX: 88007ee5ec00 RCX: a022ae00 Jun 13 14:35:40 x64VDR kernel: RDX: RSI: a022a9d4 RDI: 88007ee5ec00 Jun 13 14:35:40 x64VDR kernel: RBP: R08: 004f R09: Jun 13 14:35:40 x64VDR kernel: R10: R11: 88007ee28808 R12: a029d060 Jun 13 14:35:40 x64VDR kernel: R13: 88007ee28000 R14: 0282 R15: a0296aec Jun 13 14:35:40 x64VDR kernel: FS: 7fdc8355d6f0() GS:88000170() knlGS: Jun 13 14:35:40 x64VDR kernel: CS: 0010 DS: ES: CR0: 8005003b Jun 13 14:35:40 x64VDR kernel: CR2: CR3: 7ebd1000 CR4: 06e0 Jun 13 14:35:40 x64VDR kernel: DR0: DR1: DR2: Jun 13 14:35:40 x64VDR kernel: DR3: DR6: 0ff0 DR7: 0400 Jun 13 14:35:40 x64VDR kernel: Process modprobe (pid: 1933, threadinfo 88007e0aa000, task 88007e22a280) Jun 13 14:35:40 x64VDR kernel: Stack: Jun 13 14:35:40 x64VDR kernel: 88007ee28000 88007ee5ec00 88007ee28000 a029d060 Jun 13 14:35:40 x64VDR kernel: 0 002d a022960a 0001 Jun 13 14:35:40 x64VDR kernel: 0 88007ee5ee20 88007ee5edf8 88007e0aa000 88007d815600 Jun 13 14:35:40 x64VDR kernel: Call Trace: Jun 13 14:35:40 x64VDR kernel: [a022960a] ? __ir_input_register+0x243/0x2e7 [ir_core] Jun 13 14:35:40 x64VDR kernel: [a02963aa] ? ir_probe+0x37f/0x448 [ir_kbd_i2c] Jun 13 14:35:40 x64VDR kernel: [a029602b] ? ir_probe+0x0/0x448 [ir_kbd_i2c] Jun 13 14:35:40 x64VDR kernel: [81222ce2] ? i2c_device_probe+0xb0/0xe6 Jun 13 14:35:40 x64VDR kernel: [811be322] ? driver_sysfs_add+0x42/0x69 Jun 13 14:35:40 x64VDR kernel: [811be452] ? driver_probe_device+0x9c/0x123 Jun 13 14:35:40 x64VDR kernel: [811be528] ? __driver_attach+0x4f/0x6f Jun 13 14:35:40 x64VDR kernel: [811be4d9] ? __driver_attach+0x0/0x6f Jun 13 14:35:40 x64VDR kernel: [811bdd13] ? bus_for_each_dev+0x44/0x78 Jun 13 14:35:40 x64VDR kernel: [811bd6f8] ? bus_add_driver+0xaf/0x1f7 Jun 13 14:35:40 x64VDR kernel: [811be7cd] ? driver_register+0x90/0xf8 Jun 13 14:35:40 x64VDR kernel: [a029a000] ? ir_init+0x0/0x19 [ir_kbd_i2c] Jun 13 14:35:40 x64VDR kernel: [812238f9] ? i2c_register_driver+0x40/0x91 Jun 13 14:35:40 x64VDR kernel: [a029a000] ? ir_init+0x0/0x19 [ir_kbd_i2c] Jun 13 14:35:40 x64VDR kernel: [810001e0] ? do_one_initcall+0x4f/0x13e Jun 13 14:35:40 x64VDR kernel: [81052330] ?
Re: DViCo Dual Fusion Express (cx23885) remote control issue
On 4/22/2010 5:29 PM, Daniel O'Connor wrote: On Fri, 23 Apr 2010, Timothy D. Lenz wrote: On 4/22/2010 6:11 AM, Daniel O'Connor wrote: On Thu, 15 Apr 2010, Daniel O'Connor wrote: I haven't delved much further yet (planning to printf my way through the probe routines) as I am a Linux kernel noob (plenty of FreeBSD experience though!). I found that it is intermittent with no pattern I can determine. When it doesn't work the probe routine is not called, but I am not sure how i2c_register_driver decides to call the probe routine. Does anyone have an idea what the cause could be? Or at least somewhere to start looking :) A patch was posted that was suposed to be merged that fixed the ir problem, at least for me. Though my problem was not intermittent. The patch worked for me. Now if I could just get both tuners to keep working Hmm do you have a subject line or message ID I can search for? I haven't found any problems with tuners not working although I don't often fire them both up at once. [PATCH] FusionHDTV: Use quick reads for I2C IR device probing -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DViCo Dual Fusion Express (cx23885) remote control issue
On 4/22/2010 6:11 AM, Daniel O'Connor wrote: On Thu, 15 Apr 2010, Daniel O'Connor wrote: I haven't delved much further yet (planning to printf my way through the probe routines) as I am a Linux kernel noob (plenty of FreeBSD experience though!). I found that it is intermittent with no pattern I can determine. When it doesn't work the probe routine is not called, but I am not sure how i2c_register_driver decides to call the probe routine. Does anyone have an idea what the cause could be? Or at least somewhere to start looking :) Thanks. A patch was posted that was suposed to be merged that fixed the ir problem, at least for me. Though my problem was not intermittent. The patch worked for me. Now if I could just get both tuners to keep working -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx5000 default auto sleep mode
On 4/14/2010 9:39 PM, Devin Heitmueller wrote: On Wed, Apr 14, 2010 at 11:44 PM, Andy Wallsawa...@md.metrocast.net wrote: On Wed, 2010-04-14 at 13:40 -0400, Devin Heitmueller wrote: On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenztl...@vorgon.com wrote: Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7 Dual express. Didn't know linux supported an auto sleep mode on the tuner chips and that it defaulted to on. Seems like it would be better to default to off. Regarding the general assertion that the power management should be disabled by default, I disagree. The power savings is considerable, the time to bring the tuner out of sleep is negligible, and it's generally good policy. Andy, do you have any actual details regarding the nature of the problem? Not really. DViCo Fusion dual digital tv card. One side of the card would yield black video screen when starting a digital capture sometime after (?) the VDR ATSC EPG plugin tried to suck off data. I'm not sure there was a causal relationship. I hypothesized that one side of the dual-tuner was going stupid or one of the two channels used in the cx23885 was getting confused. I was looking at how to narrow the problem down to cx23885 chip or xc5000 tuner, or s5h14xx demod when I noted the power managment module option for the xc5000. I suggested Tim try it. It was dumb luck that my guess actually made his symptoms go away. That's all I know. We did have a similar issue with the PCTV 800i. Basically, the GPIO definition was improperly defined for the xc5000 reset callback. As a result, it was strobing the reset on both the xc5000 *and* the s5h1411, which would then cause the s5h1411's hardware state to not match the driver state. After multiple round trips with the hardware engineer at PCTV, I finally concluded that there actually wasn't a way to strobe the reset without screwing up the demodulator, which prompted me to disable the xc5000 reset callback (see cx88-cards:2944). My guess is that the reset GPIO definition for that board is wrong (a problem exposed by this change), or that it's resetting the s5h1411 as well. Devin Are any of the logs usefull? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx5000 default auto sleep mode
On 4/14/2010 10:40 AM, Devin Heitmueller wrote: On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenztl...@vorgon.com wrote: Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7 Dual express. Didn't know linux supported an auto sleep mode on the tuner chips and that it defaulted to on. Seems like it would be better to default to off. If someone wants an auto power down/sleep mode and their software supports it, then let the program activate it. Seems people are more likely to want the tuners to stay on then keep shutting down. Spent over a year trying to figure out why vdr would loose control of 1 of the dual tuners when the atscepg pluging was used thinking it was a problem with the plugin. The xc5000 power management changes I made were actually pretty thoroughly tested with that card (between myself and Michael Krufky, we tested it with just about every card that uses the tuner). In fact, we uncovered several power management bugs in other drivers as a result of that effort. It was a grueling effort that I spent almost three months working on. Generally I agree with the premise that functionality like this should only be enabled for boards it was tested with. However, in this case it actually was pretty extensively tested with all the cards in question (including this one), and thus it was deemed safe to enable by default. We've had cases in the past where developers exercised poor judgement and blindly turned on power management to make it work with one card, disregarding the possible breakage that could occur with other cards that use the same driver -- this was *not* one of those cases. If there is a bug, it should be pretty straightforward to fix provided it can be reproduced. Regarding the general assertion that the power management should be disabled by default, I disagree. The power savings is considerable, the time to bring the tuner out of sleep is negligible, and it's generally good policy. Andy, do you have any actual details regarding the nature of the problem? Devin This morning a tuner was down. So the long runs it made, maybe where a fluke. I still have options xc5000 no_poweroff=1 debug=1. I posted new logs, to http://24.255.17.209:2400/vdr/logs/. The files with .new ext are the new ones with lognig when the tuner went down. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx5000 default auto sleep mode
On 4/14/2010 10:40 AM, Devin Heitmueller wrote: On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenztl...@vorgon.com wrote: Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7 Dual express. Didn't know linux supported an auto sleep mode on the tuner chips and that it defaulted to on. Seems like it would be better to default to off. If someone wants an auto power down/sleep mode and their software supports it, then let the program activate it. Seems people are more likely to want the tuners to stay on then keep shutting down. Spent over a year trying to figure out why vdr would loose control of 1 of the dual tuners when the atscepg pluging was used thinking it was a problem with the plugin. The xc5000 power management changes I made were actually pretty thoroughly tested with that card (between myself and Michael Krufky, we tested it with just about every card that uses the tuner). In fact, we uncovered several power management bugs in other drivers as a result of that effort. It was a grueling effort that I spent almost three months working on. Generally I agree with the premise that functionality like this should only be enabled for boards it was tested with. However, in this case it actually was pretty extensively tested with all the cards in question (including this one), and thus it was deemed safe to enable by default. We've had cases in the past where developers exercised poor judgement and blindly turned on power management to make it work with one card, disregarding the possible breakage that could occur with other cards that use the same driver -- this was *not* one of those cases. If there is a bug, it should be pretty straightforward to fix provided it can be reproduced. Regarding the general assertion that the power management should be disabled by default, I disagree. The power savings is considerable, the time to bring the tuner out of sleep is negligible, and it's generally good policy. Andy, do you have any actual details regarding the nature of the problem? Devin Went down a second time today, so copied the logs over again. If what is needed to fix this isn't in those, will have to look else where. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx5000 default auto sleep mode
On 4/14/2010 10:40 AM, Devin Heitmueller wrote: On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenztl...@vorgon.com wrote: Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7 Dual express. Didn't know linux supported an auto sleep mode on the tuner chips and that it defaulted to on. Seems like it would be better to default to off. If someone wants an auto power down/sleep mode and their software supports it, then let the program activate it. Seems people are more likely to want the tuners to stay on then keep shutting down. Spent over a year trying to figure out why vdr would loose control of 1 of the dual tuners when the atscepg pluging was used thinking it was a problem with the plugin. The xc5000 power management changes I made were actually pretty thoroughly tested with that card (between myself and Michael Krufky, we tested it with just about every card that uses the tuner). In fact, we uncovered several power management bugs in other drivers as a result of that effort. It was a grueling effort that I spent almost three months working on. Generally I agree with the premise that functionality like this should only be enabled for boards it was tested with. However, in this case it actually was pretty extensively tested with all the cards in question (including this one), and thus it was deemed safe to enable by default. We've had cases in the past where developers exercised poor judgement and blindly turned on power management to make it work with one card, disregarding the possible breakage that could occur with other cards that use the same driver -- this was *not* one of those cases. If there is a bug, it should be pretty straightforward to fix provided it can be reproduced. Regarding the general assertion that the power management should be disabled by default, I disagree. The power savings is considerable, the time to bring the tuner out of sleep is negligible, and it's generally good policy. Andy, do you have any actual details regarding the nature of the problem? Devin I turned debug back on yesterday and it's been running since. No tuners have gone down yet, but here are some logs: http://24.255.17.209:2400/vdr/logs/ When/if a tuner goes down again I'll put fresh logs up -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx5000 default auto sleep mode
On 4/14/2010 8:44 PM, Andy Walls wrote: On Wed, 2010-04-14 at 13:40 -0400, Devin Heitmueller wrote: On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenztl...@vorgon.com wrote: Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7 Dual express. Didn't know linux supported an auto sleep mode on the tuner chips and that it defaulted to on. Seems like it would be better to default to off. Regarding the general assertion that the power management should be disabled by default, I disagree. The power savings is considerable, the time to bring the tuner out of sleep is negligible, and it's generally good policy. Andy, do you have any actual details regarding the nature of the problem? Not really. DViCo Fusion dual digital tv card. One side of the card would yield black video screen when starting a digital capture sometime after (?) the VDR ATSC EPG plugin tried to suck off data. I'm not sure there was a causal relationship. I hypothesized that one side of the dual-tuner was going stupid or one of the two channels used in the cx23885 was getting confused. I was looking at how to narrow the problem down to cx23885 chip or xc5000 tuner, or s5h14xx demod when I noted the power managment module option for the xc5000. I suggested Tim try it. It was dumb luck that my guess actually made his symptoms go away. That's all I know. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Guess it only reduced the problem. Today I looked at the guide and abc had no data. Checked with femon and the second tuner on the dual would not tune. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cx5000 default auto sleep mode
Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7 Dual express. Didn't know linux supported an auto sleep mode on the tuner chips and that it defaulted to on. Seems like it would be better to default to off. If someone wants an auto power down/sleep mode and their software supports it, then let the program activate it. Seems people are more likely to want the tuners to stay on then keep shutting down. Spent over a year trying to figure out why vdr would loose control of 1 of the dual tuners when the atscepg pluging was used thinking it was a problem with the plugin. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible bug with FusionHDTV7 Dual Express
Ran fin without problems for several days. Changed setting to -D 0 -D 1 -D 2 So it would use all 3 tuners (default) and left it on the 3rd tuner. Next morning first tuner was down. Today I'm trying it with -D 0 -D 2 So it uses the first tuner of the dual and the 3rd tuner (second card). Leaving it set with vdr on the 3rd tuner. On 4/5/2010 1:21 PM, Timothy D. Lenz wrote: For some time I have been having problems with VDR seemingly loosing control over one of the two tuners. It seems to be related to the atscepg plugin. It happened quicker after VDR had timer recorded a show. Removing the plugin seemed to stop it but also get no epg data. basicly, which ever tuner vdr was displaying from, the other tuner would seem to stop working. You get no signal. But only vdr needed to be restarted to get the tuner back. One tuner always seemed to go down within 24hrs when using the plugin. It seems to be related to when the plugin used a free tuner to scan epg. I put a second card in, an HVR-1800 which became the 3rd dvb device according to vdr. Same thing kept happening. Always the first or second tuner since no mater which vdr was using, it would always be one of those that was left free. I started vdr with -D 1 -D 2 to force vdr to only use 1 tuner of the dual and the second card. I also use femon to make sure vdr is using dvb1 after changing channels so that the plugin uses the second card for scanning. It has been running for a couple of days and done recordings without loosing a tuner. Since forcing it to use only one tuner of the dual seems to have stopped the problem, it is starting to look like a driver problem with the fusion card. Today I used femon to put vdr on dvb2 so that the plugin uses the fusion to scan epg. In a couple days if the problem still doesn't show, I may swap slot positions of the two cards so vdr use the 1800 without forcing by blocking a tuner. The plugin Author has also been looking into this, but he only recently got a second tuner card working. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Possible bug with FusionHDTV7 Dual Express
For some time I have been having problems with VDR seemingly loosing control over one of the two tuners. It seems to be related to the atscepg plugin. It happened quicker after VDR had timer recorded a show. Removing the plugin seemed to stop it but also get no epg data. basicly, which ever tuner vdr was displaying from, the other tuner would seem to stop working. You get no signal. But only vdr needed to be restarted to get the tuner back. One tuner always seemed to go down within 24hrs when using the plugin. It seems to be related to when the plugin used a free tuner to scan epg. I put a second card in, an HVR-1800 which became the 3rd dvb device according to vdr. Same thing kept happening. Always the first or second tuner since no mater which vdr was using, it would always be one of those that was left free. I started vdr with -D 1 -D 2 to force vdr to only use 1 tuner of the dual and the second card. I also use femon to make sure vdr is using dvb1 after changing channels so that the plugin uses the second card for scanning. It has been running for a couple of days and done recordings without loosing a tuner. Since forcing it to use only one tuner of the dual seems to have stopped the problem, it is starting to look like a driver problem with the fusion card. Today I used femon to put vdr on dvb2 so that the plugin uses the fusion to scan epg. In a couple days if the problem still doesn't show, I may swap slot positions of the two cards so vdr use the 1800 without forcing by blocking a tuner. The plugin Author has also been looking into this, but he only recently got a second tuner card working. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lost remote after kernel/v4l update cx23885 chipset
On 1/24/2010 1:07 PM, Timothy D. Lenz wrote: After updating from kernel 2.6.26.8 to 2.6.32.2 and from v4l of 05/19/2009 to 01/18/2010 I lost remote function with Dvico FusionHDTV7 Dual Express. The driver is loading, but not creating an IR device. Went over it with awalls on IRC. The log is at: http://pastebin.com/m4b02ff0c I noticed that in the kern.log there where 2 different ways ir-kbd-i2c showed up. ir-kbd-i2c no longer shows up when loading drivers. Jan 17 14:59:32 LLLx64-32 kernel: input: i2c IR (FusionHDTV) as /devices/virtual/input/input5 Jan 17 14:59:32 LLLx64-32 kernel: ir-kbd-i2c: i2c IR (FusionHDTV) detected at i2c-2/2-006b/ir0 [cx23885[0]] -- Jan 18 17:23:27 LLLx64-32 kernel: input: i2c IR (FusionHDTV) as /devices/virtual/input/input5 Jan 18 17:23:27 LLLx64-32 kernel: Creating IR device irrcv0 Jan 18 17:23:27 LLLx64-32 kernel: ir-kbd-i2c: i2c IR (FusionHDTV) detected at i2c-1/1-006b/ir0 [cx23885[0]] Jan 18 18:28:50 LLLx64-32 kernel: input: i2c IR (FusionHDTV) as /devices/virtual/input/input5 Jan 18 18:28:50 LLLx64-32 kernel: ir-kbd-i2c: i2c IR (FusionHDTV) detected at i2c-2/2-006b/ir0 [cx23885[0]] -- A driver load that worked: Jan 17 11:22:35 LLLx64-32 kernel: Linux video capture interface: v2.00 Jan 17 11:22:35 LLLx64-32 kernel: cx23885 driver version 0.0.2 loaded Jan 17 11:22:35 LLLx64-32 kernel: ACPI: PCI Interrupt :02:00.0[A] - Link [APC7] - GSI 16 (level, low) - IRQ 16 Jan 17 11:22:35 LLLx64-32 kernel: CORE cx23885[0]: subsystem: 18ac:d618, board: DViCO FusionHDTV7 Dual Express [card=10,autodetected] Jan 17 11:22:35 LLLx64-32 kernel: cx23885_dvb_register() allocating 1 frontend(s) Jan 17 11:22:35 LLLx64-32 kernel: cx23885[0]: cx23885 based dvb card Jan 17 11:22:35 LLLx64-32 kernel: xc5000 2-0064: creating new instance Jan 17 11:22:35 LLLx64-32 kernel: xc5000: Successfully identified at address 0x64 Jan 17 11:22:35 LLLx64-32 kernel: xc5000: Firmware has not been loaded previously Jan 17 11:22:35 LLLx64-32 kernel: DVB: registering new adapter (cx23885[0]) Jan 17 11:22:35 LLLx64-32 kernel: DVB: registering adapter 0 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend)... Jan 17 11:22:35 LLLx64-32 kernel: cx23885_dvb_register() allocating 1 frontend(s) Jan 17 11:22:35 LLLx64-32 kernel: cx23885[0]: cx23885 based dvb card Jan 17 11:22:35 LLLx64-32 kernel: xc5000 3-0064: creating new instance Jan 17 11:22:35 LLLx64-32 kernel: xc5000: Successfully identified at address 0x64 Jan 17 11:22:35 LLLx64-32 kernel: xc5000: Firmware has not been loaded previously Jan 17 11:22:35 LLLx64-32 kernel: DVB: registering new adapter (cx23885[0]) Jan 17 11:22:35 LLLx64-32 kernel: DVB: registering adapter 1 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend)... Jan 17 11:22:35 LLLx64-32 kernel: cx23885_dev_checkrevision() Hardware revision = 0xb0 Jan 17 11:22:35 LLLx64-32 kernel: cx23885[0]/0: found at :02:00.0, rev: 2, irq: 16, latency: 0, mmio: 0xfdc0 Jan 17 11:22:35 LLLx64-32 kernel: PCI: Setting latency timer of device :02:00.0 to 64 Jan 17 11:22:35 LLLx64-32 kernel: input: i2c IR (FusionHDTV) as /devices/virtual/input/input8 Jan 17 11:22:35 LLLx64-32 kernel: ir-kbd-i2c: i2c IR (FusionHDTV) detected at i2c-2/2-006b/ir0 [cx23885[0]] Jan 17 11:22:36 LLLx64-32 kernel: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... Jan 17 11:22:36 LLLx64-32 kernel: firmware: requesting dvb-fe-xc5000-1.6.114.fw Jan 17 11:22:36 LLLx64-32 kernel: xc5000: firmware read 12401 bytes. Jan 17 11:22:36 LLLx64-32 kernel: xc5000: firmware uploading... Jan 17 11:22:37 LLLx64-32 kernel: xc5000: firmware upload complete... Jan 17 11:22:37 LLLx64-32 kernel: xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... Jan 17 11:22:37 LLLx64-32 kernel: firmware: requesting dvb-fe-xc5000-1.6.114.fw Jan 17 11:22:37 LLLx64-32 kernel: xc5000: firmware read 12401 bytes. Jan 17 11:22:37 LLLx64-32 kernel: xc5000: firmware uploading... Jan 17 11:22:39 LLLx64-32 kernel: xc5000: firmware upload complete... -- And what it does now: Jan 23 17:10:47 LLLx64-32 kernel: Linux video capture interface: v2.00 Jan 23 17:10:47 LLLx64-32 kernel: cx23885 driver version 0.0.2 loaded Jan 23 17:10:47 LLLx64-32 kernel: cx23885 :02:00.0: PCI INT A - Link[APC7] - GSI 16 (level, low) - IRQ 16 Jan 23 17:10:47 LLLx64-32 kernel: CORE cx23885[0]: subsystem: 18ac:d618, board: DViCO FusionHDTV7 Dual Express [card=10,autodetected] Jan 23 17:10:47 LLLx64-32 kernel: cx23885_dvb_register() allocating 1 frontend(s) Jan 23 17:10:47 LLLx64-32 kernel: cx23885[0]: cx23885 based dvb card Jan 23 17:10:47 LLLx64-32 kernel: xc5000 1-0064: creating new instance Jan 23 17:10:47 LLLx64-32 kernel: xc5000: Successfully identified at address 0x64 Jan 23 17:10:47 LLLx64-32 kernel: xc5000: Firmware has not been loaded previously Jan 23 17:10:47 LLLx64-32 kernel: DVB: registering new adapter (cx23885[0]) Jan 23 17:10:47 LLLx64-32 kernel: DVB: registering adapter 0 frontend 0 (Samsung S5H1411 QAM/8VSB Frontend
Re: XC5000 improvements: call for testers!
- Original Message - From: Devin Heitmueller dheitmuel...@kernellabs.com To: Britney Fransen britney.fran...@gmail.com Cc: Devin Heitmueller devin.heitmuel...@gmail.com; Linux Media Mailing List linux-media@vger.kernel.org Sent: Tuesday, May 12, 2009 1:56 PM Subject: Re: XC5000 improvements: call for testers! On Tue, May 12, 2009 at 4:50 PM, Britney Fransen britney.fran...@gmail.com wrote: I finally had some time to do some more testing with the beta2 tree and I think most of the issues I had were user error. Not exactly sure what I did wrong before but I am not seeing the reception issues or any regressions on the digital side anymore. I think why I thought I was seeing QAM64 was because I was using the wrong tuner. With the beta2 tree my 950q is now adapter1, before it was always adapter2. That could be part of what I thought was the reception regression as well. Thanks, Britney Hello Britney, Thank you for taking the time to isolate/debug the situation. The changes should have no effect on the order of adapter1/adapter2. Could have just been a coincidence or the order in which you plugged in the devices compared to what they usually are at boot time. Glad to see that there are no longer any issues. Once I get one outstanding Pinnacle 800i fix in, I will issue a PULL request and this will go into the mainline. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com So when this goes main, next time we update from v4l we need the new firmware right? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DViCO FusionHDTV7 Dual Express remote driver
Which module needs to be loaded to get the remote for the FusionHDTV7 dual express working? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic
Not sure what you ment by if you got the panic to stop by commenting out the
call to the problem function? You want me to comment
something out in the driver and recompile v4l? With debug=7 it still panics and
much of the call trace scrolled off and again,
nothing went to serial port so no way to log it that I know of unless there is
something else I can do to get the kernel to semd
it's panic to ttyS0.
As for lspci -nnv:
02:00.0 Multimedia video controller [0400]: Conexant Device [14f1:8852] (rev 02)
Subsystem: DViCO Corporation Device [18ac:d618]
Flags: bus master, fast devsel, latency 0, IRQ 255
Memory at fdc0 (64-bit, non-prefetchable) [size=2M]
Capabilities: [40] Express Endpoint, MSI 00
Capabilities: [80] Power Management version 2
Capabilities: [90] Vital Product Data ?
Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-
Capabilities: [100] Advanced Error Reporting ?
Capabilities: [200] Virtual Channel ?
Kernel modules: cx23885
- Original Message -
From: Andy Walls awa...@radix.net
To: linux-media@vger.kernel.org
Cc: linux-...@linuxtv.org
Sent: Friday, March 20, 2009 6:10 PM
Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic
On Fri, 2009-03-20 at 11:22 -0700, Timothy D. Lenz wrote:
Not sure where I was suposed to reply to. When replying I find the replys
are coming from diffrent lists and out look is picking
that up. At the bottom it says v4l related stuff should go to
linux-media@vger.kernel.org, but the thread started in
linux-...@linuxtv.org. So I'm re-replying in linux-...@linuxtv.org.
After searching the internet for ways to redirect the error to serial or
other system and not getting to work, I typed out by
hand
what is on the screen minus the cpu dump which is mostly scrolled off
anyway and thus gone. In trying to get the dump out ttyS0
I
found I was getting different dumps to screen.
When I use:
kernel /boot/vmlinuz-2.6.26.8.20090311.1 root=/dev/hda1 ro quiet
console=ttyS0,115200n8 console=tty0
I get:
Call Trace:
[f8aa406f] netup_ci_slot_status+0x2e/0x34 [cx23885]
[f8aa07ff] cx23885_irq+0x327/0x3d8 [cx23885]
[c013d10c] handle_IRQ_event+0x1a/0x3f
[c013df36] handle_fasteoi_irq+0x76/0xab
[c0105236] do_IRQ+0x4f/0x65
[c010366f] common_interrupt+0x23/0x28
===
Code: 00 74 04 0f 0b eb fe 89 d8 e8 ed a3 ff ff ba 01 00 00 00 5b 89 d0 5e
c3 51
89 d1 8b 15 20 ba 3e c0 e8 52 ff ff ff 5a c3 53 89 c3 f0 0f ba 2a 00 19
c0 31
c9 85 c0 75 54 8d 42 04 39 42 04 74 04
EIP: [c012a8c6] queue_work+0x3/0x68 SS:ESR 0068:f7733f40
Kernel panic - not syncing: Fatal exception in interrupt
When I use the default setting:
kernel /boot/vmlinuz-2.6.26.8.20090311.1 root=/dev/hda1 ro quiet
I get:
Call Trace:
[f8aa406f] netup_ci_slot_status+0x2e/0x34 [cx23885]
[f8aa07ff] cx23885_irq+0x327/0x3d8 [cx23885]
[c013d10c] handle_IRQ_event+0x1a/0x3f
[c013df36] handle_fasteoi_irq+0x76/0xab
[c0105236] do_IRQ+0x4f/0x65
[c010366f] common_interrupt+0x23/0x28
[c0308096] _spin_unlock_irq+0x5/0x19
[c011e3ba] do_syslog+0x12f/0x2f1
[c010369c] reschedule_interrupt+0x28/0x30
[c012cd38] autoremove_wake_function+0x0/0x2d
[c018f27a] kmsg_read+0x0/0x36
[c01888cf] proc_reg_read+0x60/0x73
[c018886f] proc_reg_read+0x0/0x73
[c015d9cf] vfs_read+0x81/0xf4
[c015dada] sys_read+0x3c/0x63
[c0102c7d] sysenter_past_esp+0x6a/0x91
===
Code: 00 74 04 0f 0b eb fe 89 d8 e8 ed a3 ff ff ba 01 00 00 00 5b 89 d0 5e
c3 51
89 d1 8b 15 20 ba 3e c0 e8 52 ff ff ff 5a c3 53 89 c3 f0 0f ba 2a 00 19
c0 31
c9 85 c0 75 54 8d 42 04 39 42 04 74 04
EIP: [c012a8c6] queue_work+0x3/0x68 SS:ESR 0068:f7693e7c
Kernel panic - not syncing: Fatal exception in interrupt
Here is the kernel source code that corresponds to where the panic
occurs in linux/kernel/workqueue.c:
#define work_data_bits(work) ((unsigned long *)((work)-data))
#define WORK_STRUCT_PENDING 0
int queue_work(struct workqueue_struct *wq, struct work_struct *work)
{
int ret;
ret = queue_work_on(get_cpu(), wq, work);
put_cpu();
return ret;
}
int
queue_work_on(int cpu, struct workqueue_struct *wq, struct work_struct *work)
{
int ret = 0;
if (!test_and_set_bit(WORK_STRUCT_PENDING, work_data_bits(work))) {
BUG_ON(!list_empty(work-entry));
__queue_work(wq_per_cpu(wq, cpu), work);
ret = 1;
}
return ret;
}
Here is the disassembled code bytes from the oops:
ffd9: 74 04je 0xffdf
ffdb: 0f 0bud2a
ffdd: eb fejmp0xffdd
ffdf: 89 d8mov%ebx,%eax
ffe1: e8 ed a3 ff ff call 0xa3d3
ffe6: ba 01 00 00 00 mov$0x1,%edx
ffeb: 5b pop
Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic
No, changing baud rate to 9600 has no effect. It is simply not sending the log to the serial port. - Original Message - From: Andy Walls awa...@radix.net To: linux-media@vger.kernel.org Cc: linux-...@linuxtv.org Sent: Wednesday, March 18, 2009 7:48 PM Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic On Wed, 2009-03-18 at 19:16 -0700, Timothy D. Lenz wrote: I've added console=ttyS0,115200 console=tty0 to the kernel command line options and with out the console=tty0 part the dump no longer shows on the monitor, so redirect seems to work but loging the serial port on a second computer gets nothing. I tested the connection with echo and that worked but the kernel dump won't go out the port. The last 2 lines of the screen are: EIP: [c012a8c6] queue_work+0x3/0x68 SS:ESP 0068:f778dd24 Kernel panic - not syncing: Fatal exception in interrupt Hmm. The only thing in the cx23885 driver that tries to schedule work, and thus the only thing that could possibly pass in a bad argument, is the netup_ci_slot_status() function. It gets called when an IRQ comes in indicating a GPIO[01] event, and the driver thinks the card is a NetUp Dual DVB-S2 CI card. That's consistent with the fatal exception in interrupt, but without the backtrace, one can't be completely sure this call to queue work was initiated by the cx23885 driver and a problem with cx23885 data structures. (But it is the most likely scenario, IMO) I just can't see how netup_ci_slot_status() get's called for your card. Any way to get the dump to go out the serial port? Does 9600 baud help? (Just a guess.) Regards, Andy - Original Message - From: Andy Walls awa...@radix.net To: Timothy D. Lenz tl...@vorgon.com Cc: linux-media@vger.kernel.org Sent: Monday, March 16, 2009 6:07 PM Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic On Mon, 2009-03-16 at 17:46 -0700, Timothy D. Lenz wrote: When it panics, there is no log, just a bunch of stuff that that scrolls fast on the main monitor then cold lock. No way to scroll back. Not even Shift+PageUp ? I looked at the logs and the ones that are text had nothing about it. Digital camera or pencil and paper will be least complex way to capture the ooops data. Please don't leave out the Code bytes at the bottom and do your best to make sure those are absolutely correct. Regards, Andy - Original Message - From: Steven Toth st...@linuxtv.org To: linux-media@vger.kernel.org Cc: linux-...@linuxtv.org Sent: Monday, March 16, 2009 6:59 AM Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic Timothy D. Lenz wrote: Using kernel 2.6.26.8 and v4l from a few days ago. When I modprobe cx23885 to load the drivers, I get kernel panic We'll need the oops. - Steve ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic
After searching the internet for ways to redirect the error to serial or other system and not getting to work, I typed out by hand what is on the screen minus the cpu dump which is mostly scrolled off anyway and thus gone. In trying to get the dump out ttyS0 I found I was getting different dumps to screen. When I use: kernel /boot/vmlinuz-2.6.26.8.20090311.1 root=/dev/hda1 ro quiet console=ttyS0,115200n8 console=tty0 I get: Call Trace: [f8aa406f] netup_ci_slot_status+0x2e/0x34 [cx23885] [f8aa07ff] cx23885_irq+0x327/0x3d8 [cx23885] [c013d10c] handle_IRQ_event+0x1a/0x3f [c013df36] handle_fasteoi_irq+0x76/0xab [c0105236] do_IRQ+0x4f/0x65 [c010366f] common_interrupt+0x23/0x28 === Code: 00 74 04 0f 0b eb fe 89 d8 e8 ed a3 ff ff ba 01 00 00 00 5b 89 d0 5e c3 51 89 d1 8b 15 20 ba 3e c0 e8 52 ff ff ff 5a c3 53 89 c3 f0 0f ba 2a 00 19 c0 31 c9 85 c0 75 54 8d 42 04 39 42 04 74 04 EIP: [c012a8c6] queue_work+0x3/0x68 SS:ESR 0068:f7733f40 Kernel panic - not syncing: Fatal exception in interrupt When I use the default setting: kernel /boot/vmlinuz-2.6.26.8.20090311.1 root=/dev/hda1 ro quiet I get: Call Trace: [f8aa406f] netup_ci_slot_status+0x2e/0x34 [cx23885] [f8aa07ff] cx23885_irq+0x327/0x3d8 [cx23885] [c013d10c] handle_IRQ_event+0x1a/0x3f [c013df36] handle_fasteoi_irq+0x76/0xab [c0105236] do_IRQ+0x4f/0x65 [c010366f] common_interrupt+0x23/0x28 [c0308096] _spin_unlock_irq+0x5/0x19 [c011e3ba] do_syslog+0x12f/0x2f1 [c010369c] reschedule_interrupt+0x28/0x30 [c012cd38] autoremove_wake_function+0x0/0x2d [c018f27a] kmsg_read+0x0/0x36 [c01888cf] proc_reg_read+0x60/0x73 [c018886f] proc_reg_read+0x0/0x73 [c015d9cf] vfs_read+0x81/0xf4 [c015dada] sys_read+0x3c/0x63 [c0102c7d] sysenter_past_esp+0x6a/0x91 === Code: 00 74 04 0f 0b eb fe 89 d8 e8 ed a3 ff ff ba 01 00 00 00 5b 89 d0 5e c3 51 89 d1 8b 15 20 ba 3e c0 e8 52 ff ff ff 5a c3 53 89 c3 f0 0f ba 2a 00 19 c0 31 c9 85 c0 75 54 8d 42 04 39 42 04 74 04 EIP: [c012a8c6] queue_work+0x3/0x68 SS:ESR 0068:f7693e7c Kernel panic - not syncing: Fatal exception in interrupt It may be a bit different each time because I think I've seen longer Call Trace dumps - Original Message - From: Andy Walls awa...@radix.net To: linux-media@vger.kernel.org Cc: linux-...@linuxtv.org Sent: Wednesday, March 18, 2009 7:48 PM Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic On Wed, 2009-03-18 at 19:16 -0700, Timothy D. Lenz wrote: I've added console=ttyS0,115200 console=tty0 to the kernel command line options and with out the console=tty0 part the dump no longer shows on the monitor, so redirect seems to work but loging the serial port on a second computer gets nothing. I tested the connection with echo and that worked but the kernel dump won't go out the port. The last 2 lines of the screen are: EIP: [c012a8c6] queue_work+0x3/0x68 SS:ESP 0068:f778dd24 Kernel panic - not syncing: Fatal exception in interrupt Hmm. The only thing in the cx23885 driver that tries to schedule work, and thus the only thing that could possibly pass in a bad argument, is the netup_ci_slot_status() function. It gets called when an IRQ comes in indicating a GPIO[01] event, and the driver thinks the card is a NetUp Dual DVB-S2 CI card. That's consistent with the fatal exception in interrupt, but without the backtrace, one can't be completely sure this call to queue work was initiated by the cx23885 driver and a problem with cx23885 data structures. (But it is the most likely scenario, IMO) I just can't see how netup_ci_slot_status() get's called for your card. Any way to get the dump to go out the serial port? Does 9600 baud help? (Just a guess.) Regards, Andy - Original Message - From: Andy Walls awa...@radix.net To: Timothy D. Lenz tl...@vorgon.com Cc: linux-media@vger.kernel.org Sent: Monday, March 16, 2009 6:07 PM Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic On Mon, 2009-03-16 at 17:46 -0700, Timothy D. Lenz wrote: When it panics, there is no log, just a bunch of stuff that that scrolls fast on the main monitor then cold lock. No way to scroll back. Not even Shift+PageUp ? I looked at the logs and the ones that are text had nothing about it. Digital camera or pencil and paper will be least complex way to capture the ooops data. Please don't leave out the Code bytes at the bottom and do your best to make sure those are absolutely correct. Regards, Andy - Original Message - From: Steven Toth st...@linuxtv.org To: linux-media@vger.kernel.org Cc: linux-...@linuxtv.org Sent: Monday, March 16, 2009 6:59 AM Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic Timothy D. Lenz wrote: Using kernel 2.6.26.8 and v4l from a few days ago. When I modprobe cx23885 to load the drivers, I get kernel panic
Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic
When it panics, there is no log, just a bunch of stuff that that scrolls fast on the main monitor then cold lock. No way to scroll back. I looked at the logs and the ones that are text had nothing about it. - Original Message - From: Steven Toth st...@linuxtv.org To: linux-media@vger.kernel.org Cc: linux-...@linuxtv.org Sent: Monday, March 16, 2009 6:59 AM Subject: Re: [linux-dvb] FusionHDTV7 and v4l causes kernel panic Timothy D. Lenz wrote: Using kernel 2.6.26.8 and v4l from a few days ago. When I modprobe cx23885 to load the drivers, I get kernel panic We'll need the oops. - Steve ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
