Re: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c
Alan Stern wrote: Got it. It's not good enough; the initial error occurred before the start of your extract. Here's yet another version of the patch; this one will stop printing the debug messages when an error is first detected so maybe it won't overrun your log buffer. Alan Stern Alan, Thanks again. I was able to get the full dmesg output this time. I ran capture-example three times and each time removing the webcam before capture-example finished. On the third time I got the poisoned hash message and I captured the output to a file. Attached is the dmesg output. Sean dmesg2.log.tar.gz Description: Unix tar archive
Re: [linux-dvb] SheevaBox as a media Server and a Fit-PC as a streaming client?
Le Fri, 01 Jan 2010 15:26:54 +0100, DUBOST Brice dub...@crans.ens-cachan.fr a écrit : Markus Rechberger a écrit : Hi, On Wed, Dec 16, 2009 at 4:12 PM, Lothar Behrens lothar.behr...@lollisoft.de wrote: Hi, I am new here and start with a setup question. The media or NAS server I think about: http://plugcomputer.org/ It has a high speed USB 2.0 port and a gigabit Lan. http://support.sundtek.com/index.php/topic,179.0.html (english) http://support.sundtek.com/index.php/topic,178.0.html (german) This might be interesting for you. Markus hello MuMuDVB is reported to work fine on a sheevaplug I use my sheevaplug without any problem with a CinergyT2, and I know someone who runs with an empia-based hybrid tuner (Terratec Cinergy hybrid XS) The main bottleneck of the sheevaplug and all ARMv5TE compliant processors is the lack of FPU, if you have to do transcoding stuff (mpeg4-mpeg2 for example) before streaming. To my mind the 'TE' extension should be used for such transcoding but this is off topic. Otherwise, it is perfect to host a streaming server like vlc or MuMuDVB, to stream untouched video frames coming from DVB tuners. Cheers, Thierry -- 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: Fwd: Compro S300 - ZL10313
On Sat, 2010-01-02 at 09:39 +0200, Theunis Potgieter wrote: 2010/1/1 JD Louw jd.l...@mweb.co.za: On Tue, 2009-12-29 at 23:23 +0200, Theunis Potgieter wrote: Hi mailing list, I have a problem with my Compro S300 pci card under Linux 2.6.32. I cannot tune with this card and STR/SNRA is very bad compared to my Technisat SkyStar 2 pci card, connected to the same dish. I have this card and are willing to run tests, tested drivers etc to make this work. I currently load the module saa7134 with options: card=169 I enabled some debug parameters on the saa7134, not sure what else I should enable. Please find my dmesg log attached. lsmod shows : # lsmod Module Size Used by zl10039 6268 2 mt312 12048 2 saa7134_dvb41549 11 saa7134 195664 1 saa7134_dvb nfsd 416819 11 videobuf_dvb8187 1 saa7134_dvb dvb_core 148140 1 videobuf_dvb ir_common 40625 1 saa7134 v4l2_common21544 1 saa7134 videodev 58341 2 saa7134,v4l2_common v4l1_compat24473 1 videodev videobuf_dma_sg17830 2 saa7134_dvb,saa7134 videobuf_core 26534 3 saa7134,videobuf_dvb,videobuf_dma_sg tveeprom 12550 1 saa7134 thermal20547 0 processor 54638 1 # uname -a Linux vbox 2.6.32-gentoo #4 Sat Dec 19 00:54:19 SAST 2009 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux Thanks, Theunis Hi, It's probably the GPIO settings that are wrong for your SAA7133 based card revision. See http://osdir.com/ml/linux-media/2009-06/msg01256.html for an explanation. For quick confirmation check if you have 12V - 20V DC going to your LNB. The relevant lines of code is in ~/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c: case SAA7134_BOARD_VIDEOMATE_S350: dev-has_remote = SAA7134_REMOTE_GPIO; saa_andorl(SAA7134_GPIO_GPMODE0 2, 0x8000, 0x8000); saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0x8000, 0x8000); break; Hi thanks for the hint. I changed it to the following: case SAA7134_BOARD_VIDEOMATE_S350: dev-has_remote = SAA7134_REMOTE_GPIO; saa_andorl(SAA7134_GPIO_GPMODE0 2, 0xc000, 0xc000); saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0xc000, 0xc000); break; I now get the same SNR as on my skystar2 card, signal is still indicating 17% where as the skystar2 would show 68%. At least I'm getting a LOCK on channels :) Thanks! Looking at your log, at least the demodulator and tuner is responding correctly. You can see this by looking at the i2c traffic addressed to 0x1c (demodulator) and 0xc0 (tuner). Attached is a dmesg trace from my working SAA7130 based card. Regards JD Hi, Just to clarify, can you now watch channels? At the moment the signal strength measurement is a bit whacked, so don't worry too much about it. I also get the 75%/17% figures you mentioned when tuning to strong signals. The figure is simply reported wrongly: even weaker signals should tune fine. If you want you can have a look in ~/v4l-dvb/linux/drivers/media/dvb/frontends/mt312.c at mt312_read_signal_strength(). Also, if you have a multimeter handy, can you confirm that the 0xc000 GPIO fix enables LNB voltage? I'd like to issue a patch for this. I've already tested this on my older card with no ill effect. Regards JD -- 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: Fwd: Compro S300 - ZL10313
2010/1/2 JD Louw jd.l...@mweb.co.za: On Sat, 2010-01-02 at 09:39 +0200, Theunis Potgieter wrote: 2010/1/1 JD Louw jd.l...@mweb.co.za: On Tue, 2009-12-29 at 23:23 +0200, Theunis Potgieter wrote: Hi mailing list, I have a problem with my Compro S300 pci card under Linux 2.6.32. I cannot tune with this card and STR/SNRA is very bad compared to my Technisat SkyStar 2 pci card, connected to the same dish. I have this card and are willing to run tests, tested drivers etc to make this work. I currently load the module saa7134 with options: card=169 I enabled some debug parameters on the saa7134, not sure what else I should enable. Please find my dmesg log attached. lsmod shows : # lsmod Module Size Used by zl10039 6268 2 mt312 12048 2 saa7134_dvb 41549 11 saa7134 195664 1 saa7134_dvb nfsd 416819 11 videobuf_dvb 8187 1 saa7134_dvb dvb_core 148140 1 videobuf_dvb ir_common 40625 1 saa7134 v4l2_common 21544 1 saa7134 videodev 58341 2 saa7134,v4l2_common v4l1_compat 24473 1 videodev videobuf_dma_sg 17830 2 saa7134_dvb,saa7134 videobuf_core 26534 3 saa7134,videobuf_dvb,videobuf_dma_sg tveeprom 12550 1 saa7134 thermal 20547 0 processor 54638 1 # uname -a Linux vbox 2.6.32-gentoo #4 Sat Dec 19 00:54:19 SAST 2009 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux Thanks, Theunis Hi, It's probably the GPIO settings that are wrong for your SAA7133 based card revision. See http://osdir.com/ml/linux-media/2009-06/msg01256.html for an explanation. For quick confirmation check if you have 12V - 20V DC going to your LNB. The relevant lines of code is in ~/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c: case SAA7134_BOARD_VIDEOMATE_S350: dev-has_remote = SAA7134_REMOTE_GPIO; saa_andorl(SAA7134_GPIO_GPMODE0 2, 0x8000, 0x8000); saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0x8000, 0x8000); break; Hi thanks for the hint. I changed it to the following: case SAA7134_BOARD_VIDEOMATE_S350: dev-has_remote = SAA7134_REMOTE_GPIO; saa_andorl(SAA7134_GPIO_GPMODE0 2, 0xc000, 0xc000); saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0xc000, 0xc000); break; I now get the same SNR as on my skystar2 card, signal is still indicating 17% where as the skystar2 would show 68%. At least I'm getting a LOCK on channels :) Thanks! Looking at your log, at least the demodulator and tuner is responding correctly. You can see this by looking at the i2c traffic addressed to 0x1c (demodulator) and 0xc0 (tuner). Attached is a dmesg trace from my working SAA7130 based card. Regards JD Hi, Just to clarify, can you now watch channels? Hi Jan, yes I can watch channels on Vivid bouquet, some of which are FTA channels. Here is some channels I can get a lock and a picture on vdr: GodCh;GodCh:11674:vC56M2O0S0:S68.5E:26652:0:0:0:0:110:73:3:0 ASTV;ASTV:11674:vC56M2O0S0:S68.5E:26652:0:0:0:0:111:73:3:0 At the moment the signal strength measurement is a bit whacked, so don't worry too much about it. I also get the 75%/17% figures you mentioned when tuning to strong signals. The figure is simply reported wrongly: even weaker signals should tune fine. If you want you can have a look in ~/v4l-dvb/linux/drivers/media/dvb/frontends/mt312.c at mt312_read_signal_strength(). Also, if you have a multimeter handy, can you confirm that the 0xc000 GPIO fix enables LNB voltage? I'd like to issue a patch for this. I've already tested this on my older card with no ill effect. I will try and do this as soon as possible. Was there any worth while information in the ZL10313 documentation that could assist in setting the correct parameters for my Compro S300? Regards JD Thanks for the assistance :) Theunis -- 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
DTV2000 H Plus issues
I have 2 TV Cards. The DTV2000 H Plus and a Technisat. The Technisat works very well. I am trying to get the DVT working for other video input devices such as VCR to make copies of old Videos and an inteface for my N95 video out. I do not seem to be able to get it to find a tuner. Seems to be problem finding the card. Any suggestions wold be greatly appreciated. Here is part of an mplayer -verbose output Selected driver: v4l2 name: Video 4 Linux 2 input author: Martin Olschewski olschew...@zpr.uni-koeln.de comment: first try, more to come ;-) Selected device: UNKNOWN/GENERIC Capabilites: video capture VBI capture device read/write streaming supported norms: 0 = NTSC-M; 1 = NTSC-M-JP; 2 = NTSC-443; 3 = PAL-BG; 4 = PAL-I; 5 = PAL-DK; 6 = PAL-M; 7 = PAL-N; 8 = PAL-Nc; 9 = PAL-60; 10 = SECAM-B; 11 = SECAM-G; 12 = SECAM-H; 13 = SECAM-DK; 14 = SECAM-L; inputs: 0 = Composite1; 1 = Composite2; 2 = Composite3; 3 = Composite4; I am running Kubuntu Karmic 2.6.31-16-generic on AMD64 quadcore. I have latest mercurial of v4l installed. Here is the Lspci info and dmesg etc 5:05.0 Network controller [0280]: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card [13d0:2103] (rev 02) Subsystem: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card [13d0:2103] Flags: bus master, slow devsel, latency 64, IRQ 20 Memory at fbff (32-bit, non-prefetchable) [size=64K] I/O ports at ec00 [size=32] Kernel driver in use: b2c2_flexcop_pci Kernel modules: b2c2-flexcop-pci 05:06.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05) Subsystem: LeadTek Research Inc. Device [107d:6f42] Flags: bus master, medium devsel, latency 64, IRQ 21 Memory at f800 (32-bit, non-prefetchable) [size=16M] Capabilities: access denied Kernel driver in use: cx8800 Kernel modules: cx8800 05:06.1 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] [14f1:8801] (rev 05) Subsystem: LeadTek Research Inc. Device [107d:6f42] Flags: bus master, medium devsel, latency 64, IRQ 21 Memory at f900 (32-bit, non-prefetchable) [size=16M] Capabilities: access denied Kernel driver in use: cx88_audio Kernel modules: cx88-alsa 05:06.2 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] [14f1:8802] (rev 05) Subsystem: LeadTek Research Inc. Device [107d:6f42] Flags: bus master, medium devsel, latency 64, IRQ 10 Memory at fa00 (32-bit, non-prefetchable) [size=16M] Capabilities: access denied Kernel modules: cx8802 dmesg in part here: [snip] [ 20.387650] b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully [ 20.390596] EDAC MC: Ver: 2.1.0 Dec 8 2009 [ 20.392347] flexcop-pci: will use the HW PID filter. [ 20.392351] flexcop-pci: card revision 2 [ 20.392359] alloc irq_desc for 20 on node 0 [ 20.392361] alloc kstat_irqs on node 0 [ 20.392366] b2c2_flexcop_pci :05:05.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [ 20.403400] EDAC amd64_edac: Ver: 3.2.0 Dec 8 2009 [ 20.404070] EDAC amd64: This node reports that Memory ECC is currently disabled. [ 20.404073] EDAC amd64: bit 0x40 in register F3x44 of the MISC_CONTROL device (:00:18.3) should be enabled [ 20.404076] EDAC amd64: WARNING: ECC is NOT currently enabled by the BIOS. Module will NOT be loaded. [ 20.404077] Either Enable ECC in the BIOS, or use the 'ecc_enable_override' parameter. [ 20.404078] Might be a BIOS bug, if BIOS says ECC is enabled [ 20.404078] Use of the override can cause unknown side effects. [ 20.404541] amd64_edac: probe of :00:18.2 failed with error -22 [ 20.425278] HDA Intel :00:14.2: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 20.430203] DVB: registering new adapter (FlexCop Digital TV device) [ 20.431702] b2c2-flexcop: MAC address = 00:d0:d7:16:5d:8f [ 20.432308] CX24123: cx24123_i2c_readreg: reg=0x0 (error=-121) [ 20.432311] CX24123: wrong demod revision: 87 [ 20.547542] Linux video capture interface: v2.00 [ 20.555291] HDA Intel :01:00.1: PCI INT B - GSI 19 (level, low) - IRQ 19 [ 20.555310] HDA Intel :01:00.1: setting latency timer to 64 [ 20.608776] EXT3 FS on sda1, internal journal [ 20.857754] cx88/0: cx2388x v4l2 driver version 0.0.7 loaded [ 20.859425] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded [ 20.859959] b2c2-flexcop: found 'Zarlink MT352 DVB-T' . [ 20.859963] DVB: registering adapter 0 frontend 0 (Zarlink MT352 DVB-T)... [ 20.860017] b2c2-flexcop: initialization of 'Air2PC/AirStar 2 DVB-T' at the 'PCI' bus controlled by a
DTV2000 H Plus issues
PS: I have tried modprobe and insmode card=51 and card=82 and card=0 with no luck. -- 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
A4tech PK-333 MB Bad colors
Hi i have such webcam http://www.a4tech.com/ennew/product.asp?cid=77scid=89id=401 i got image but with weird colors? This cam has some night vision feature. Can i help somehow to enhance driver? -- 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: DTV2000 H Plus issues
On 01/02/2010 05:10 PM, Raena Lea-Shannon wrote: I have 2 TV Cards. The DTV2000 H Plus and a Technisat. The Technisat works very well. I am trying to get the DVT working for other video input devices such as VCR to make copies of old Videos and an inteface for my N95 video out. I do not seem to be able to get it to find a tuner. Seems to be problem finding the card. Any suggestions wold be greatly appreciated. This card uses an Xceive XC4000 tuner, which is not supported yet. However, a driver for the tuner chip is being developed at kernellabs.com, so the card may become supported in the future. -- 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
Technisat SkyStar HD S2 USB
Dear all, i want to use the Technisat SkyStar HD S2 USB for building a PVR. Does anyone know, if this Box is supported in the near future? (USB VID 0x14f7, PID 0x0002) Actually i couldn`t find a valid driver. -- 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Jan 2 19:00:02 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13879:b6b82258cf5e gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.33-rc2-armv5: ERRORS linux-2.6.32-armv5-davinci: OK linux-2.6.33-rc2-armv5-davinci: ERRORS linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.33-rc2-armv5-ixp: ERRORS linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.33-rc2-armv5-omap2: ERRORS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: WARNINGS linux-2.6.32-i686: WARNINGS linux-2.6.33-rc2-i686: ERRORS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.33-rc2-m32r: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.33-rc2-mips: ERRORS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: WARNINGS linux-2.6.33-rc2-powerpc64: ERRORS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: WARNINGS linux-2.6.32-x86_64: WARNINGS linux-2.6.33-rc2-x86_64: ERRORS spec: OK sparse (linux-2.6.32): ERRORS sparse (linux-2.6.33-rc2): ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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
Re: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c
On Sat, 2 Jan 2010, Sean wrote: Alan, Thanks again. I was able to get the full dmesg output this time. I ran capture-example three times and each time removing the webcam before capture-example finished. On the third time I got the poisoned hash message and I captured the output to a file. Attached is the dmesg output. Okay. Take a look at the following output: $ egrep -n '[2e]e(80|9c)' dmesg2.log 680:pci :00:0c.0: reg 14 io port: [0xee80-0xee83] 727:kobject: 'ieee80211' (c79d5e1c): kobject_add_internal: parent: 'class', set: 'class' 728:kobject: 'ieee80211' (c79d5e1c): kobject_uevent_env 729:kobject: 'ieee80211' (c79d5e1c): fill_kobj_path: path = '/class/ieee80211' 4994:ohci_hcd :00:0b.0: td alloc for 2 ep85: c6662e80 5027:ohci_hcd :00:0b.0: hash c6662e80 to 58 - (null) 5185:ohci_hcd :00:0b.0: td alloc for 2 ep85: c676ee80 5218:ohci_hcd :00:0b.0: hash c676ee80 to 58 - c6662e80 5276:ohci_hcd :00:0b.0: td free c6662e80 5277:ohci_hcd :00:0b.0: (58 1) c676ee9c - (null) 5296:ohci_hcd :00:0b.0: td alloc for 2 ep85: c6662e80 5329:ohci_hcd :00:0b.0: hash c6662e80 to 58 - c676ee80 5538:ohci_hcd :00:0b.0: td free c676ee80 5539:ohci_hcd :00:0b.0: (58 1) c6662e9c - (null) 5558:ohci_hcd :00:0b.0: td alloc for 2 ep85: c676ee80 5591:ohci_hcd :00:0b.0: hash c676ee80 to 58 - c6662e80 5644:ohci_hcd :00:0b.0: td free c6662e80 5645:ohci_hcd :00:0b.0: (58 1) c676ee9c - (null) 5720:ohci_hcd :00:0b.0: td alloc for 2 ep85: c6662e80 5753:ohci_hcd :00:0b.0: hash c6662e80 to 58 - c676ee80 5900:ohci_hcd :00:0b.0: td free c676ee80 5901:ohci_hcd :00:0b.0: (58 1) c6662e9c - (null) 5978:ohci_hcd :00:0b.0: td alloc for 2 ep85: c676ee80 6011:ohci_hcd :00:0b.0: hash c676ee80 to 58 - c6662e80 6072:ohci_hcd :00:0b.0: td free c6662e80 6073:ohci_hcd :00:0b.0: (58 1) c676ee9c - (null) 6088:ohci_hcd :00:0b.0: td alloc for 2 ep85: c6662e80 6121:ohci_hcd :00:0b.0: hash c6662e80 to 58 - c676ee80 6324:ohci_hcd :00:0b.0: td free c676ee80 6325:ohci_hcd :00:0b.0: (58 1) c6662e9c - (null) 6343:ohci_hcd :00:0b.0: td alloc for 2 ep85: c676ee80 6376:ohci_hcd :00:0b.0: hash c676ee80 to 58 - c6662e80 6416:ohci_hcd :00:0b.0: td free c6662e80 6417:ohci_hcd :00:0b.0: (58 1) c676ee9c - c676ee80 6492:ohci_hcd :00:0b.0: td alloc for 2 ep85: c6662e80 6525:ohci_hcd :00:0b.0: hash c6662e80 to 58 - c676ee80 6686:ohci_hcd :00:0b.0: td free c676ee80 6687:ohci_hcd :00:0b.0: (58 1) c6662e9c - c676ee80 Ignore the first few lines as being irrelevant. Starting with line 5185 you can see that this shows two TDs being allocated, hashed, freed, and unlinked over and over again, at addresses c6662e80 and c676ee80. When each one is hashed into the list, its td_hash member is made to point to the other. When each is removed from the hash list, the other's td_hash member is set to NULL. It's all very regular and repetitious until line 6417. At that line, the td_hash member of c676ee80 (which is at offset 1c from the start of the structure, hence at c676ee9c) is made to point to its own structure! Thus later at line 6687, when c676ee80 is freed, the td_hash member of c6662e80 is set to point at the freed structure. This is what leads to poisoned pointer values later on. So what went wrong at line 6417? There's no way to know exactly. My guess is that the write at line 6325, where c6662e9c was supposed to be set to NULL, never got recorded properly in the computer's memory. This would mean that c6662e9c still contained the c676ee80 value assigned at line 6121, and hence the incorrect value was copied at line 6417. In other words, I'm guessing that you're suffering from hardware memory errors. A possible way to test this is to modify the patch. In td_free() where it adds the line: + ohci_dbg(hc, (%d %d) %p - %p\n, hash, n, prev, *prev); instead add this code: + barrier(); + ohci_dbg(hc, (%d %d) %p - %p [%p]\n, hash, n, + prev, *prev, td-td_hash); If we find that the value of *prev differs from the value of td-td_hash then we'll know for certain. (Or maybe the presence of the barrier() will cause the object code to change in a way that prevents the error from occurring.) Alan Stern -- 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
CI USB
Hi All, Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. Cheers, - jonas -- 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: CI USB
Hi Jonas Does anyone know if there's any progress on USB CI adapter support? Last posts I can find are from 2008 (Terratec Cinergy CI USB Hauppauge WinTV-CI). That attempt seems to have stranded with Luc Brosens (who gave it a shot back then) asking for help. The chip manufacturer introduced a usb stick as well; http://www.smardtv.com/index.php?page=products_listingrubrique=pctvsection=usbcam but besides the scary Vista logo on that page, it looks like they target broadcast companies only and not end users. You are right. Seems DVB CI stick is not targeted to end consumers. Anyway, it looks interesting, even it requires additional DVB tuner somewhere in the pc what means duplicated traffic (to the CI stick for descrambling and back for mpeg a/v decoding). It would be nice to see such stuff working in linux, but because of market targeting i don' t expect that. BTW, Hauppauge's WinTV-CI looked much more promissing. At least when I started reading whole thread about it here: http://www.mail-archive.com/linux-...@linuxtv.org/msg28113.html Unfortunatelly, last Steve's note about not getting anything (even any answer) has disappointed me fully. And because google is quiet about any progress on it I pressume no any docu nor driver was released later on. /Honza -- 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: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c
Alan Stern wrote: In other words, I'm guessing that you're suffering from hardware memory errors. A possible way to test this is to modify the patch. In td_free() where it adds the line: + ohci_dbg(hc, (%d %d) %p - %p\n, hash, n, prev, *prev); instead add this code: + barrier(); + ohci_dbg(hc, (%d %d) %p - %p [%p]\n, hash, n, + prev, *prev, td-td_hash); If we find that the value of *prev differs from the value of td-td_hash then we'll know for certain. (Or maybe the presence of the barrier() will cause the object code to change in a way that prevents the error from occurring.) Alan Stern Hmm, I applied the changes and I did not see a place where *prev differs from td-td_hash. I have run memtest86+ on this box and it has passed 16 times, so I do not suspect a hardware memory error. What do you think? Attached is the latest dmesg output. Sean dmesg3.log.tar.gz Description: Unix tar archive
