Re: DVBSky T980C CI issues (kernel 4.0.x)
Hi Olli, On Fri, 2016-03-04 at 10:28 +0200, Olli Salonen wrote: > Hi Jurgen, > > Ah, that's interesting. My T980C (and based on printout from Torbjörn > his as well) have Si2168-A20 chips. > > Some things I'd like to understand: > - is there a difference if the CI slot is populated or not? Not sure, will test > - is there any difference between the different firmwares? I'll check the second newer one. > - does it work with the DVBSky provided driver? Will test this as well (dvbv5-scan) > - when you say it doesn't work, is the issue that the demodulator > does > not lock on the DVB-T2 muxes? I am using DVB-C, I do not have issues with tuning. Only dvbv5-scan does not work. > > Two different firmwares for A30 chip: > https://github.com/OpenELEC/dvb-firmware/blob/18b12de1f57b3c70a681983 > 638989f94590b19f1/firmware/dvb-demod-si2168-a30-01.fw?raw=true > https://github.com/OpenELEC/dvb-firmware/raw/dc7cf270e328de144e75a30d > 970b6e147e8bcb6e/firmware/dvb-demod-si2168-a30-01.fw > > I think the second one is newer, but don't have the means to verify > right now... I am currently using the first one. What about the si2158? [ 121.771582] si2157 10-0060: found a 'Silicon Labs Si2158-A20' [ 121.794158] si2157 10-0060: downloading firmware from file 'dvb- tuner-si2158-a20-01.fw' [ 122.594826] si2157 10-0060: firmware version: 2.1.6 Bye, Jurgen > > Cheers, > -olli > > On 4 March 2016 at 10:15, Jurgen Kramer <gtmkra...@xs4all.nl> wrote: > > > > Hi Olli, > > > > On Thu, 2016-03-03 at 13:02 +0200, Olli Salonen wrote: > > > > > > Hi Jurgen, Torbjörn, > > > > > > I've noticed that there is currently a small confusion about the > > > firmware versions for the Si2168-A20 demodulator. This is used in > > > the > > > older versions of DVBSky T680C (TechnoTrend CT2-4650 CI) and > > > DVBSky > > > T980C (TechnoTrend CT2-4500 CI). > > > > > > The version 2.0.5 does not support PLP handling and seems to work > > > very > > > badly with the Linux driver - at least for me. Version 2.0.35 on > > > the > > > other hand seems to find all DVB-T/T2 channels for me just fine > > > with > > > both dvbv5-scan and w_scan (devices used for this test: > > > TechnoTrend > > > CT2-4650 CI and TechnoTrend CT2-4500 CI new version). > > > > > > Versions used: > > > dvbv5-scan version 1.7.0 > > > w_scan version 20150111 (compiled for DVB API 5.10) > > > > > > So if you are running these Si2168-A20 based devices, make sure > > > you've > > > got the firmware 2.0.35 that can be downloaded for example here: > > > http://palosaari.fi/linux/v4l-dvb/firmware/Si2168/Si2168-A20/32e0 > > > 6713 > > > b33915f674bfb2c209beaea5/ > > It seems my TC980Cs have Si2168-A30's on board > > > > [ 118.526665] si2168 8-0064: found a 'Silicon Labs Si2168-A30' > > [ 118.640642] si2168 8-0064: downloading firmware from file 'dvb- > > demod-si2168-a30-01.fw' > > [ 121.762983] si2168 8-0064: firmware version: 3.0.16 > > > > dvbv5_scan does not work me. > > sha1sum for this firmware is: > > 59a0b90703d65229fb2589b52834ca68d1e96ad9 dvb-demod-si2168-a30- > > 01.fw > > > > Jurgen > > -- 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: DVBSky T980C CI issues (kernel 4.0.x)
Hi Olli, On Thu, 2016-03-03 at 13:02 +0200, Olli Salonen wrote: > Hi Jurgen, Torbjörn, > > I've noticed that there is currently a small confusion about the > firmware versions for the Si2168-A20 demodulator. This is used in the > older versions of DVBSky T680C (TechnoTrend CT2-4650 CI) and DVBSky > T980C (TechnoTrend CT2-4500 CI). > > The version 2.0.5 does not support PLP handling and seems to work > very > badly with the Linux driver - at least for me. Version 2.0.35 on the > other hand seems to find all DVB-T/T2 channels for me just fine with > both dvbv5-scan and w_scan (devices used for this test: TechnoTrend > CT2-4650 CI and TechnoTrend CT2-4500 CI new version). > > Versions used: > dvbv5-scan version 1.7.0 > w_scan version 20150111 (compiled for DVB API 5.10) > > So if you are running these Si2168-A20 based devices, make sure > you've > got the firmware 2.0.35 that can be downloaded for example here: > http://palosaari.fi/linux/v4l-dvb/firmware/Si2168/Si2168-A20/32e06713 > b33915f674bfb2c209beaea5/ It seems my TC980Cs have Si2168-A30's on board [ 118.526665] si2168 8-0064: found a 'Silicon Labs Si2168-A30' [ 118.640642] si2168 8-0064: downloading firmware from file 'dvb- demod-si2168-a30-01.fw' [ 121.762983] si2168 8-0064: firmware version: 3.0.16 dvbv5_scan does not work me. sha1sum for this firmware is: 59a0b90703d65229fb2589b52834ca68d1e96ad9 dvb-demod-si2168-a30-01.fw Jurgen -- 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: DVBSky T980C CI issues (kernel 4.0.x)
On Fri, 2015-09-11 at 22:01 +0200, Torbjorn Jansson wrote:
> On 2015-08-23 19:50, Jurgen Kramer wrote:
> >
> > On Sun, 2015-07-12 at 12:38 +0200, Jurgen Kramer wrote:
> >> I have been running a couple of DVBSky T980C's with CIs with success
> >> using an older kernel (3.17.8) with media-build and some added patches
> >> from the mailing list.
> >>
> >> I thought lets try a current 4.0 kernel to see if I no longer need to be
> >> running a custom kernel. Everything works just fine except the CAM
> >> module. I am seeing these:
> >>
> >> [ 456.574969] dvb_ca adapter 0: Invalid PC card inserted :(
> >> [ 456.626943] dvb_ca adapter 1: Invalid PC card inserted :(
> >> [ 456.666932] dvb_ca adapter 2: Invalid PC card inserted :(
> >>
> >> The normal 'CAM detected and initialised' messages to do show up with
> >> 4.0.8
> >>
> >> I am not sure what changed in the recent kernels, what is needed to
> >> debug this?
> >>
> >> Jurgen
> > Retest. I've isolated one T980C on another PC with kernel 4.1.5, still the
> > same 'Invalid PC card inserted :(' message.
> > Even after installed today's media_build from git no improvement.
> >
> > Any hints where to start looking would be appreciated!
> >
> > cimax2.c|h do not seem to have changed. There are changes to
> > dvb_ca_en50221.c
> >
> > Jurgen
> >
>
> did you get it to work?
No, it needs a thorough debug session. So far no one seems able to
help...
> i got a dvbsky T980C too for dvb-t2 reception and so far the only
> drivers that have worked at all is the ones from dvbsky directly.
>
> i was very happy when i noticed that recent kernels have support for it
> built in but unfortunately only the modules and firmware loads but then
> nothing actually works.
> i use mythtv and it complains a lot about the signal, running femon also
> produces lots of errors.
>
> so i had to switch back to kernel 4.0.4 with mediabuild from dvbsky.
>
> if there were any other dvb-t2 card with ci support that had better
> drivers i would change right away.
>
> one problem i have with the mediabuilt from dvbsky is that at boot the
> cam never works and i have to first tune a channel, then remove and
> reinstert the cam to get it to work.
> without that nothing works.
>
> and finally a problem i ran into when i tried mediabuilt from linuxtv.org.
> fedora uses kernel modules with .ko.xz extension so when you install the
> mediabuilt modulels you get one modulename.ko and one modulename.ko.xz
>
> before a make install from mediabuild overwrote the needed modules.
> any advice on how to handle this now?
>
>
--
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: DVBSky T980C CI issues (kernel 4.0.x)
On Sun, 2015-07-12 at 12:38 +0200, Jurgen Kramer wrote:
I have been running a couple of DVBSky T980C's with CIs with success
using an older kernel (3.17.8) with media-build and some added patches
from the mailing list.
I thought lets try a current 4.0 kernel to see if I no longer need to be
running a custom kernel. Everything works just fine except the CAM
module. I am seeing these:
[ 456.574969] dvb_ca adapter 0: Invalid PC card inserted :(
[ 456.626943] dvb_ca adapter 1: Invalid PC card inserted :(
[ 456.666932] dvb_ca adapter 2: Invalid PC card inserted :(
The normal 'CAM detected and initialised' messages to do show up with
4.0.8
I am not sure what changed in the recent kernels, what is needed to
debug this?
Jurgen
Retest. I've isolated one T980C on another PC with kernel 4.1.5, still the same
'Invalid PC card inserted :(' message.
Even after installed today's media_build from git no improvement.
Any hints where to start looking would be appreciated!
cimax2.c|h do not seem to have changed. There are changes to
dvb_ca_en50221.c
Jurgen
Relevant kernel messages:
[ 14.899827] cx25840 9-0044: loaded v4l-cx23885-avcore-01.fw firmware
(16382 bytes)
[ 14.915384] cx23885_dvb_register() allocating 1 frontend(s)
[ 14.915386] cx23885[0]: cx23885 based dvb card
[ 15.326745] i2c i2c-8: Added multiplexed i2c bus 10
[ 15.326747] si2168 8-0064: Silicon Labs Si2168 successfully attached
[ 15.390538] si2157 10-0060: Silicon Labs Si2147/2148/2157/2158
successfully attached
[ 15.390542] DVB: registering new adapter (cx23885[0])
[ 15.390544] cx23885 :02:00.0: DVB: registering adapter 0 frontend
0 (Silicon Labs Si2168)...
[ 15.758330] sp2 8-0040: CIMaX SP2 successfully attached
[ 15.785785] DVBSky T980C MAC address: 00:17:42:54:09:88
[ 15.785789] cx23885_dev_checkrevision() Hardware revision = 0xa5
[ 15.785792] cx23885[0]/0: found at :02:00.0, rev: 4, irq: 16,
latency: 0, mmio: 0xf7c0
[ 15.785883] CORE cx23885[1]: subsystem: 4254:980c, board: DVBSky
T980C [card=46,autodetected]
[ 15.996981] EXT4-fs (sda2): mounted filesystem with ordered data
mode. Opts: (null)
[ 16.015395] cx25840 13-0044: cx23885 A/V decoder found @ 0x88
(cx23885[1])
[ 16.642705] cx25840 13-0044: loaded v4l-cx23885-avcore-01.fw firmware
(16382 bytes)
[ 16.658240] cx23885_dvb_register() allocating 1 frontend(s)
[ 16.658242] cx23885[1]: cx23885 based dvb card
[ 16.659004] i2c i2c-12: Added multiplexed i2c bus 14
[ 16.659006] si2168 12-0064: Silicon Labs Si2168 successfully attached
[ 16.660689] si2157 14-0060: Silicon Labs Si2147/2148/2157/2158
successfully attached
[ 16.660692] DVB: registering new adapter (cx23885[1])
[ 16.660693] cx23885 :03:00.0: DVB: registering adapter 1 frontend
0 (Silicon Labs Si2168)...
[ 16.667337] sp2 12-0040: CIMaX SP2 successfully attached
[ 16.694845] DVBSky T980C MAC address: 00:17:42:54:09:88
[ 16.694848] cx23885_dev_checkrevision() Hardware revision = 0xa5
[ 16.694852] cx23885[1]/0: found at :03:00.0, rev: 4, irq: 17,
latency: 0, mmio: 0xf7a0
[ 16.694986] CORE cx23885[2]: subsystem: 4254:980c, board: DVBSky
T980C [card=46,autodetected]
[ 16.924320] cx25840 17-0044: cx23885 A/V decoder found @ 0x88
(cx23885[2])
[ 17.551377] cx25840 17-0044: loaded v4l-cx23885-avcore-01.fw firmware
(16382 bytes)
[ 17.566994] cx23885_dvb_register() allocating 1 frontend(s)
[ 17.566996] cx23885[2]: cx23885 based dvb card
[ 17.567898] i2c i2c-16: Added multiplexed i2c bus 18
[ 17.567900] si2168 16-0064: Silicon Labs Si2168 successfully attached
[ 17.569710] si2157 18-0060: Silicon Labs Si2147/2148/2157/2158
successfully attached
[ 17.569714] DVB: registering new adapter (cx23885[2])
[ 17.569715] cx23885 :05:00.0: DVB: registering adapter 2 frontend
0 (Silicon Labs Si2168)...
[ 17.576684] sp2 16-0040: CIMaX SP2 successfully attached
[ 17.604168] DVBSky T980C MAC address: 00:17:42:54:09:88
[ 17.604171] cx23885_dev_checkrevision() Hardware revision = 0xa5
[ 17.604174] cx23885[2]/0: found at :05:00.0, rev: 4, irq: 19,
latency: 0, mmio: 0xf780
[ 220.616002] si2168 8-0064: found a 'Silicon Labs Si2168-A30'
[ 220.635026] si2168 8-0064: downloading firmware from file
'dvb-demod-si2168-a30-01.fw'
[ 223.744845] si2168 8-0064: firmware version: 3.0.16
[ 223.753441] si2157 10-0060: found a 'Silicon Labs Si2158-A20'
[ 223.777443] si2157 10-0060: downloading firmware from file
'dvb-tuner-si2158-a20-01.fw'
[ 224.59] si2157 10-0060: firmware version: 2.1.6
[ 224.683600] si2168 12-0064: found a 'Silicon Labs Si2168-A30'
[ 224.683633] si2168 12-0064: downloading firmware from file
'dvb-demod-si2168-a30-01.fw'
[ 227.797635] si2168 12-0064: firmware version: 3.0.16
[ 227.806235] si2157 14-0060: found a 'Silicon Labs Si2158-A20'
[ 227.806249] si2157 14-0060: downloading firmware from file
'dvb-tuner-si2158-a20-01.fw
DVBSky T980C CI issues (kernel 4.0.x)
I have been running a couple of DVBSky T980C's with CIs with success using an older kernel (3.17.8) with media-build and some added patches from the mailing list. I thought lets try a current 4.0 kernel to see if I no longer need to be running a custom kernel. Everything works just fine except the CAM module. I am seeing these: [ 456.574969] dvb_ca adapter 0: Invalid PC card inserted :( [ 456.626943] dvb_ca adapter 1: Invalid PC card inserted :( [ 456.666932] dvb_ca adapter 2: Invalid PC card inserted :( The normal 'CAM detected and initialised' messages to do show up with 4.0.8 I am not sure what changed in the recent kernels, what is needed to debug this? Jurgen Relevant kernel messages: [ 14.899827] cx25840 9-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) [ 14.915384] cx23885_dvb_register() allocating 1 frontend(s) [ 14.915386] cx23885[0]: cx23885 based dvb card [ 15.326745] i2c i2c-8: Added multiplexed i2c bus 10 [ 15.326747] si2168 8-0064: Silicon Labs Si2168 successfully attached [ 15.390538] si2157 10-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached [ 15.390542] DVB: registering new adapter (cx23885[0]) [ 15.390544] cx23885 :02:00.0: DVB: registering adapter 0 frontend 0 (Silicon Labs Si2168)... [ 15.758330] sp2 8-0040: CIMaX SP2 successfully attached [ 15.785785] DVBSky T980C MAC address: 00:17:42:54:09:88 [ 15.785789] cx23885_dev_checkrevision() Hardware revision = 0xa5 [ 15.785792] cx23885[0]/0: found at :02:00.0, rev: 4, irq: 16, latency: 0, mmio: 0xf7c0 [ 15.785883] CORE cx23885[1]: subsystem: 4254:980c, board: DVBSky T980C [card=46,autodetected] [ 15.996981] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: (null) [ 16.015395] cx25840 13-0044: cx23885 A/V decoder found @ 0x88 (cx23885[1]) [ 16.642705] cx25840 13-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) [ 16.658240] cx23885_dvb_register() allocating 1 frontend(s) [ 16.658242] cx23885[1]: cx23885 based dvb card [ 16.659004] i2c i2c-12: Added multiplexed i2c bus 14 [ 16.659006] si2168 12-0064: Silicon Labs Si2168 successfully attached [ 16.660689] si2157 14-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached [ 16.660692] DVB: registering new adapter (cx23885[1]) [ 16.660693] cx23885 :03:00.0: DVB: registering adapter 1 frontend 0 (Silicon Labs Si2168)... [ 16.667337] sp2 12-0040: CIMaX SP2 successfully attached [ 16.694845] DVBSky T980C MAC address: 00:17:42:54:09:88 [ 16.694848] cx23885_dev_checkrevision() Hardware revision = 0xa5 [ 16.694852] cx23885[1]/0: found at :03:00.0, rev: 4, irq: 17, latency: 0, mmio: 0xf7a0 [ 16.694986] CORE cx23885[2]: subsystem: 4254:980c, board: DVBSky T980C [card=46,autodetected] [ 16.924320] cx25840 17-0044: cx23885 A/V decoder found @ 0x88 (cx23885[2]) [ 17.551377] cx25840 17-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) [ 17.566994] cx23885_dvb_register() allocating 1 frontend(s) [ 17.566996] cx23885[2]: cx23885 based dvb card [ 17.567898] i2c i2c-16: Added multiplexed i2c bus 18 [ 17.567900] si2168 16-0064: Silicon Labs Si2168 successfully attached [ 17.569710] si2157 18-0060: Silicon Labs Si2147/2148/2157/2158 successfully attached [ 17.569714] DVB: registering new adapter (cx23885[2]) [ 17.569715] cx23885 :05:00.0: DVB: registering adapter 2 frontend 0 (Silicon Labs Si2168)... [ 17.576684] sp2 16-0040: CIMaX SP2 successfully attached [ 17.604168] DVBSky T980C MAC address: 00:17:42:54:09:88 [ 17.604171] cx23885_dev_checkrevision() Hardware revision = 0xa5 [ 17.604174] cx23885[2]/0: found at :05:00.0, rev: 4, irq: 19, latency: 0, mmio: 0xf780 [ 220.616002] si2168 8-0064: found a 'Silicon Labs Si2168-A30' [ 220.635026] si2168 8-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 223.744845] si2168 8-0064: firmware version: 3.0.16 [ 223.753441] si2157 10-0060: found a 'Silicon Labs Si2158-A20' [ 223.777443] si2157 10-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' [ 224.59] si2157 10-0060: firmware version: 2.1.6 [ 224.683600] si2168 12-0064: found a 'Silicon Labs Si2168-A30' [ 224.683633] si2168 12-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 227.797635] si2168 12-0064: firmware version: 3.0.16 [ 227.806235] si2157 14-0060: found a 'Silicon Labs Si2158-A20' [ 227.806249] si2157 14-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' [ 228.606280] si2157 14-0060: firmware version: 2.1.6 [ 228.644496] si2168 16-0064: found a 'Silicon Labs Si2168-A30' [ 228.644521] si2168 16-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 231.763081] si2168 16-0064: firmware version: 3.0.16 [ 231.771685] si2157 18-0060: found a 'Silicon Labs Si2158-A20' [ 231.771711] si2157 18-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' [ 232.571684] si2157 18-0060: firmware version: 2.1.6 [
Re: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
Hi Hans, On Fri, 2015-02-13 at 10:24 +0100, Hans Verkuil wrote: Jurgen, Raimond, On 02/13/2015 10:12 AM, Hans Verkuil wrote: Hi Jurgen, On 02/04/2015 06:21 PM, Jurgen Kramer wrote: On Wed, 2015-02-04 at 17:19 +0100, Hans Verkuil wrote: On 02/04/2015 05:06 PM, Jurgen Kramer wrote: Hi Hans, On Mon, 2015-02-02 at 10:36 +0100, Hans Verkuil wrote: Raimonds and Jurgen, Can you both test with the following patch applied to the driver: Unfortunately the mpeg error is not (completely) gone: OK, I suspected that might be the case. Is the UNBALANCED warning gone with my vb2 patch? When you see this risc error, does anything break (broken up video) or crash, or does it just keep on streaming? Can you comment on this question? The UNBALANCED warnings have not reappeared (so far). And they are still gone? If that's the case, then I'll merge the patch fixing this for 3.20. With respect to the risc error: the only reason I can think of is that it is a race condition when the risc program is updated. I'll see if I can spend some time on this today or on Monday. Can you give me an indication how often you see this risc error message? Can you both apply this patch and let me know what it says the next time you get a risc error message? I just realized that important information was never logged, so with luck this might help me pinpoint the problem. So far I got one mpeg error: [81639.485605] cx23885[2]: mpeg risc op code error 10001 0 [81639.485610] cx23885[2]: TS1 B - dma channel status dump [81639.485612] cx23885[2]: cmds: init risc lo : 0x053aa000 [81639.485615] cx23885[2]: cmds: init risc hi : 0x [81639.485617] cx23885[2]: cmds: cdt base : 0x00010580 [81639.485620] cx23885[2]: cmds: cdt size : 0x000a [81639.485622] cx23885[2]: cmds: iq base: 0x00010400 [81639.485625] cx23885[2]: cmds: iq size: 0x0010 [81639.485628] cx23885[2]: cmds: risc pc lo : 0x048e5048 [81639.485630] cx23885[2]: cmds: risc pc hi : 0x [81639.485633] cx23885[2]: cmds: iq wr ptr : 0x4105 [81639.485636] cx23885[2]: cmds: iq rd ptr : 0x4109 [81639.485638] cx23885[2]: cmds: cdt current: 0x000105a8 [81639.485640] cx23885[2]: cmds: pci target lo : 0xadc44000 [81639.485642] cx23885[2]: cmds: pci target hi : 0x [81639.485645] cx23885[2]: cmds: line / byte: 0x0020 [81639.485648] cx23885[2]: risc0: 0x1c0002f0 [ write sol eol count=752 ] [81639.485651] cx23885[2]: risc1: 0xadc44000 [ readc sol eol irq1 23 22 18 14 count=0 ] [81639.485655] cx23885[2]: risc2: 0x [ INVALID count=0 ] [81639.485658] cx23885[2]: risc3: 0x1c0002f0 [ write sol eol count=752 ] [81639.485661] cx23885[2]: (0x00010400) iq 0: 0xadc448d0 [ readc sol eol irq1 23 22 18 14 count=2256 ] [81639.485665] cx23885[2]: (0x00010404) iq 1: 0x [ INVALID count=0 ] [81639.485667] cx23885[2]: (0x00010408) iq 2: 0x1c0002f0 [ write sol eol count=752 ] [81639.485670] cx23885[2]: iq 3: 0xadc44bc0 [ arg #1 ] [81639.485672] cx23885[2]: iq 4: 0x [ arg #2 ] [81639.485674] cx23885[2]: (0x00010414) iq 5: 0x7100 [ jump irq1 count=0 ] [81639.485677] cx23885[2]: iq 6: 0x1c0002f0 [ arg #1 ] [81639.485679] cx23885[2]: iq 7: 0xadc44000 [ arg #2 ] [81639.485682] cx23885[2]: (0x00010420) iq 8: 0x [ INVALID count=0 ] [81639.485684] cx23885[2]: (0x00010424) iq 9: 0x1c0002f0 [ write sol eol count=752 ] [81639.485687] cx23885[2]: iq a: 0xadc442f0 [ arg #1 ] [81639.485689] cx23885[2]: iq b: 0x [ arg #2 ] [81639.485691] cx23885[2]: (0x00010430) iq c: 0x1c0002f0 [ write sol eol count=752 ] [81639.485694] cx23885[2]: iq d: 0xadc445e0 [ arg #1 ] [81639.485696] cx23885[2]: iq e: 0x [ arg #2 ] [81639.485698] cx23885[2]: (0x0001043c) iq f: 0x1c0002f0 [ write sol eol count=752 ] [81639.485701] cx23885[2]: iq 10: 0x3efdbb2f [ arg #1 ] [81639.485704] cx23885[2]: iq 11: 0xbb1ae8fd [ arg #2 ] [81639.485704] cx23885[2]: fifo: 0x5000 - 0x6000 [81639.485705] cx23885[2]: ctrl: 0x00010400 - 0x10460 [81639.485707] cx23885[2]: ptr1_reg: 0x5700 [81639.485709] cx23885[2]: ptr2_reg: 0x000105a8 [81639.485711] cx23885[2]: cnt1_reg: 0x0012 [81639.485714] cx23885[2]: cnt2_reg: 0x0005 Best regards, Jurgen -- 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: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
Hi, On Fri, 2015-02-13 at 10:12 +0100, Hans Verkuil wrote: Hi Jurgen, On 02/04/2015 06:21 PM, Jurgen Kramer wrote: On Wed, 2015-02-04 at 17:19 +0100, Hans Verkuil wrote: On 02/04/2015 05:06 PM, Jurgen Kramer wrote: Hi Hans, On Mon, 2015-02-02 at 10:36 +0100, Hans Verkuil wrote: Raimonds and Jurgen, Can you both test with the following patch applied to the driver: Unfortunately the mpeg error is not (completely) gone: OK, I suspected that might be the case. Is the UNBALANCED warning gone with my vb2 patch? When you see this risc error, does anything break (broken up video) or crash, or does it just keep on streaming? Can you comment on this question? I still get the risc errors at regular intervals. I am not sure what the real impact is. I do get the occasional failed recording (dreaded 0 byte recoderings). The UNBALANCED warnings have not reappeared (so far). And they are still gone? If that's the case, then I'll merge the patch fixing this for 3.20. No, these are gone. With respect to the risc error: the only reason I can think of is that it is a race condition when the risc program is updated. I'll see if I can spend some time on this today or on Monday. Can you give me an indication how often you see this risc error message? dmesg |grep risc op code error [ 1267.999719] cx23885[1]: mpeg risc op code error [17830.312766] cx23885[2]: mpeg risc op code error [37820.312372] cx23885[2]: mpeg risc op code error [48973.897721] cx23885[2]: mpeg risc op code error [126673.151447] cx23885[0]: mpeg risc op code error [208262.607584] cx23885[2]: mpeg risc op code error [212564.803499] cx23885[2]: mpeg risc op code error [288834.700570] cx23885[1]: mpeg risc op code error [298753.789105] cx23885[2]: mpeg risc op code error [341900.746719] cx23885[2]: mpeg risc op code error [346513.849946] cx23885[1]: mpeg risc op code error [359267.169552] cx23885[2]: mpeg risc op code error [370728.293458] cx23885[1]: mpeg risc op code error [423626.314834] cx23885[1]: mpeg risc op code error uptime: 17:14:03 up 4 days, 22:22, 2 users, load average: 0.19, 0.39, 0.34 Best regards, Jurgen -- 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: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
Hi Hans, On Fri, 2015-02-13 at 10:24 +0100, Hans Verkuil wrote: Jurgen, Raimond, On 02/13/2015 10:12 AM, Hans Verkuil wrote: Hi Jurgen, On 02/04/2015 06:21 PM, Jurgen Kramer wrote: On Wed, 2015-02-04 at 17:19 +0100, Hans Verkuil wrote: On 02/04/2015 05:06 PM, Jurgen Kramer wrote: Hi Hans, On Mon, 2015-02-02 at 10:36 +0100, Hans Verkuil wrote: Raimonds and Jurgen, Can you both test with the following patch applied to the driver: Unfortunately the mpeg error is not (completely) gone: OK, I suspected that might be the case. Is the UNBALANCED warning gone with my vb2 patch? When you see this risc error, does anything break (broken up video) or crash, or does it just keep on streaming? Can you comment on this question? The UNBALANCED warnings have not reappeared (so far). And they are still gone? If that's the case, then I'll merge the patch fixing this for 3.20. With respect to the risc error: the only reason I can think of is that it is a race condition when the risc program is updated. I'll see if I can spend some time on this today or on Monday. Can you give me an indication how often you see this risc error message? Can you both apply this patch and let me know what it says the next time you get a risc error message? I just realized that important information was never logged, so with luck this might help me pinpoint the problem. I'll apply it tonight and will keep you posted. Jurgen -- 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: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
Hi, On Fri, 2015-02-13 at 17:42 +0100, Hans Verkuil wrote: On 02/13/2015 05:14 PM, Jurgen Kramer wrote: Hi, On Fri, 2015-02-13 at 10:12 +0100, Hans Verkuil wrote: Hi Jurgen, On 02/04/2015 06:21 PM, Jurgen Kramer wrote: On Wed, 2015-02-04 at 17:19 +0100, Hans Verkuil wrote: On 02/04/2015 05:06 PM, Jurgen Kramer wrote: Hi Hans, On Mon, 2015-02-02 at 10:36 +0100, Hans Verkuil wrote: Raimonds and Jurgen, Can you both test with the following patch applied to the driver: Unfortunately the mpeg error is not (completely) gone: OK, I suspected that might be the case. Is the UNBALANCED warning gone with my vb2 patch? When you see this risc error, does anything break (broken up video) or crash, or does it just keep on streaming? Can you comment on this question? I still get the risc errors at regular intervals. I am not sure what the real impact is. I do get the occasional failed recording (dreaded 0 byte recoderings). Did you get those failed recordings in the past (i.e. before the 'convert to vb2' commit) as well? Or are these new since that commit? I only got the T980C's last December. I also had the occasional failed recording with my old PCI cards. The UNBALANCED warnings have not reappeared (so far). And they are still gone? If that's the case, then I'll merge the patch fixing this for 3.20. No, these are gone. Ah, good news. With respect to the risc error: the only reason I can think of is that it is a race condition when the risc program is updated. I'll see if I can spend some time on this today or on Monday. Can you give me an indication how often you see this risc error message? dmesg |grep risc op code error [ 1267.999719] cx23885[1]: mpeg risc op code error [17830.312766] cx23885[2]: mpeg risc op code error [37820.312372] cx23885[2]: mpeg risc op code error [48973.897721] cx23885[2]: mpeg risc op code error [126673.151447] cx23885[0]: mpeg risc op code error [208262.607584] cx23885[2]: mpeg risc op code error [212564.803499] cx23885[2]: mpeg risc op code error [288834.700570] cx23885[1]: mpeg risc op code error [298753.789105] cx23885[2]: mpeg risc op code error [341900.746719] cx23885[2]: mpeg risc op code error [346513.849946] cx23885[1]: mpeg risc op code error [359267.169552] cx23885[2]: mpeg risc op code error [370728.293458] cx23885[1]: mpeg risc op code error [423626.314834] cx23885[1]: mpeg risc op code error uptime: 17:14:03 up 4 days, 22:22, 2 users, load average: 0.19, 0.39, 0.34 I understand that you record continuously? Or only at specific times? No not continuously, occasionally when there is something interesting :-), but quite regularly (series etc). Sorry for all these questions, but they help me locate the problem. No problem :-) Regards, Jurgen -- 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: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
On Wed, 2015-02-04 at 17:19 +0100, Hans Verkuil wrote: On 02/04/2015 05:06 PM, Jurgen Kramer wrote: Hi Hans, On Mon, 2015-02-02 at 10:36 +0100, Hans Verkuil wrote: Raimonds and Jurgen, Can you both test with the following patch applied to the driver: Unfortunately the mpeg error is not (completely) gone: OK, I suspected that might be the case. Is the UNBALANCED warning gone with my vb2 patch? When you see this risc error, does anything break (broken up video) or crash, or does it just keep on streaming? The UNBALANCED warnings have not reappeared (so far). Regards, Jurgen -- 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: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
Hi Hans, On Mon, 2015-02-02 at 10:36 +0100, Hans Verkuil wrote: On 02/01/2015 02:06 PM, Raimonds Cicans wrote: On 29.01.2015 14:12, Hans Verkuil wrote: On 01/29/15 12:51, Raimonds Cicans wrote: On 29.01.2015 09:33, Hans Verkuil wrote: On 01/11/2015 10:33 AM, Raimonds Cicans wrote: I contacted you because I am hit by regression caused by your commit: 453afdd [media] cx23885: convert to vb2 My system: AMD Athlon(tm) II X2 240e Processor on Asus M5A97 LE R2.0 motherboard TBS6981 card (Dual DVB-S/S2 PCIe receiver, cx23885 in kernel driver) After upgrade from kernel 3.13.10 (do not have commit) to 3.17.7 (have commit) I started receiving following IOMMU related messages: 1) AMD-Vi: Event logged [IO_PAGE_FAULT device=0a:00.0 domain=0x001d address=0x0637c000 flags=0x] where device=0a:00.0 is TBS6981 card As far as I can tell this has nothing to do with the cx23885 driver but is a bug in the amd iommu/BIOS. See e.g.: https://bbs.archlinux.org/viewtopic.php?pid=1309055 I managed to reproduce the Intel equivalent if I enable CONFIG_IOMMU_SUPPORT. Most likely due to broken BIOS/ACPI/whatever information that's read by the kernel. I would recommend disabling this kernel option. Maybe... But on other hand this did not happen on old kernel with old driver. And when I did bisection on old kernel + media tree I started to receive this message only on new driver. Was CONFIG_IOMMU_SUPPORT enabled in the old kernel? zgrep CONFIG_IOMMU_SUPPORT /proc/config.gz CONFIG_IOMMU_SUPPORT=y Raimonds Cicans Raimonds and Jurgen, Can you both test with the following patch applied to the driver: Unfortunately the mpeg error is not (completely) gone: [ 172.946876] dvb_ca adapter 0: DVB CAM detected and initialised successfully [ 276.938186] dvb_ca adapter 1: DVB CAM detected and initialised successfully [ 405.007902] dvb_ca adapter 2: DVB CAM detected and initialised successfully [ 8031.928944] traps: polkitd[1017] general protection ip:7f8754445022 sp:7fff3ef612d0 error:0 in libmozjs-17.0.so[7f8754306000+3b3000] [18977.465763] perf interrupt took too long (2510 2500), lowering kernel.perf_event_max_sample_rate to 5 [60407.000404] cx23885[1]: mpeg risc op code error [60407.000409] cx23885[1]: TS1 B - dma channel status dump [60407.000411] cx23885[1]: cmds: init risc lo : 0xb8869000 [60407.000414] cx23885[1]: cmds: init risc hi : 0x [60407.000417] cx23885[1]: cmds: cdt base : 0x00010580 [60407.000420] cx23885[1]: cmds: cdt size : 0x000a [60407.000422] cx23885[1]: cmds: iq base: 0x00010400 [60407.000425] cx23885[1]: cmds: iq size: 0x0010 [60407.000427] cx23885[1]: cmds: risc pc lo : 0xc9601048 [60407.000430] cx23885[1]: cmds: risc pc hi : 0x [60407.000433] cx23885[1]: cmds: iq wr ptr : 0x4105 [60407.000435] cx23885[1]: cmds: iq rd ptr : 0x4109 [60407.000438] cx23885[1]: cmds: cdt current: 0x000105a8 [60407.000441] cx23885[1]: cmds: pci target lo : 0xb8988000 [60407.000443] cx23885[1]: cmds: pci target hi : 0x [60407.000445] cx23885[1]: cmds: line / byte: 0x0020 [60407.000448] cx23885[1]: risc0: 0x1c0002f0 [ write sol eol count=752 ] [60407.000452] cx23885[1]: risc1: 0xb8988000 [ writerm sol 23 20 19 resync count=0 ] [60407.000455] cx23885[1]: risc2: 0x [ INVALID count=0 ] [60407.000457] cx23885[1]: risc3: 0x1c0002f0 [ write sol eol count=752 ] [60407.000460] cx23885[1]: (0x00010400) iq 0: 0xb89888d0 [ writerm sol 23 20 19 resync count=2256 ] [60407.000464] cx23885[1]: iq 1: 0x [ arg #1 ] [60407.000466] cx23885[1]: iq 2: 0x1c0002f0 [ arg #2 ] [60407.000468] cx23885[1]: (0x0001040c) iq 3: 0xb8988bc0 [ writerm sol 23 20 19 resync count=3008 ] [60407.000472] cx23885[1]: iq 4: 0x [ arg #1 ] [60407.000474] cx23885[1]: iq 5: 0x7100 [ arg #2 ] [60407.000476] cx23885[1]: (0x00010418) iq 6: 0x1c0002f0 [ write sol eol count=752 ] [60407.000479] cx23885[1]: iq 7: 0xb8988000 [ arg #1 ] [60407.000481] cx23885[1]: iq 8: 0x [ arg #2 ] [60407.000483] cx23885[1]: (0x00010424) iq 9: 0x1c0002f0 [ write sol eol count=752 ] [60407.000486] cx23885[1]: iq a: 0xb89882f0 [ arg #1 ] [60407.000488] cx23885[1]: iq b: 0x [ arg #2 ] [60407.000490] cx23885[1]: (0x00010430) iq c: 0x1c0002f0 [ write sol eol count=752 ] [60407.000493] cx23885[1]: iq d: 0xb89885e0 [ arg #1 ] [60407.000495] cx23885[1]: iq e: 0x [ arg #2 ] [60407.000497] cx23885[1]: (0x0001043c) iq f: 0x1c0002f0 [ write sol eol count=752 ] [60407.000500] cx23885[1]: iq 10: 0x6a76032d [ arg #1 ] [60407.000502] cx23885[1]: iq 11: 0x3a68baa3 [ arg #2 ] [60407.000503] cx23885[1]: fifo: 0x5000 - 0x6000 [60407.000504] cx23885[1]: ctrl: 0x00010400 - 0x10460 [60407.000506] cx23885[1]: ptr1_reg: 0x5860 [60407.000508] cx23885[1]: ptr2_reg: 0x000105a8
Re: [REGRESSION] media: cx23885 broken by commit 453afdd [media] cx23885: convert to vb2
On Mon, 2015-02-02 at 10:36 +0100, Hans Verkuil wrote:
On 02/01/2015 02:06 PM, Raimonds Cicans wrote:
On 29.01.2015 14:12, Hans Verkuil wrote:
On 01/29/15 12:51, Raimonds Cicans wrote:
On 29.01.2015 09:33, Hans Verkuil wrote:
On 01/11/2015 10:33 AM, Raimonds Cicans wrote:
I contacted you because I am hit by regression caused by your commit:
453afdd [media] cx23885: convert to vb2
My system:
AMD Athlon(tm) II X2 240e Processor on Asus M5A97 LE R2.0 motherboard
TBS6981 card (Dual DVB-S/S2 PCIe receiver, cx23885 in kernel driver)
After upgrade from kernel 3.13.10 (do not have commit) to 3.17.7
(have commit) I started receiving following IOMMU related messages:
1)
AMD-Vi: Event logged [IO_PAGE_FAULT device=0a:00.0 domain=0x001d
address=0x0637c000 flags=0x]
where device=0a:00.0 is TBS6981 card
As far as I can tell this has nothing to do with the cx23885 driver but
is
a bug in the amd iommu/BIOS. See e.g.:
https://bbs.archlinux.org/viewtopic.php?pid=1309055
I managed to reproduce the Intel equivalent if I enable
CONFIG_IOMMU_SUPPORT.
Most likely due to broken BIOS/ACPI/whatever information that's read by
the
kernel. I would recommend disabling this kernel option.
Maybe...
But on other hand this did not happen on old kernel with old driver.
And when I did bisection on old kernel + media tree I started to
receive this message only on new driver.
Was CONFIG_IOMMU_SUPPORT enabled in the old kernel?
zgrep CONFIG_IOMMU_SUPPORT /proc/config.gz
CONFIG_IOMMU_SUPPORT=y
Raimonds Cicans
Hi Hans,
Raimonds and Jurgen,
Can you both test with the following patch applied to the driver:
diff --git a/drivers/media/pci/cx23885/cx23885-core.c
b/drivers/media/pci/cx23885/cx23885-core.c
index 1ad4994..72df5ae 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -1497,6 +1497,7 @@ void cx23885_buf_queue(struct cx23885_tsport *port,
struct cx23885_buffer *buf)
buf-risc.jmp[0] = cpu_to_le32(RISC_JUMP | RISC_CNT_INC);
buf-risc.jmp[1] = cpu_to_le32(buf-risc.dma + 12);
buf-risc.jmp[2] = cpu_to_le32(0); /* bits 63-32 */
+ wmb();
spin_lock_irqsave(dev-slock, flags);
if (list_empty(cx88q-active)) {
@@ -1505,10 +1506,12 @@ void cx23885_buf_queue(struct cx23885_tsport *port,
struct cx23885_buffer *buf)
buf, buf-vb.v4l2_buf.index, __func__);
} else {
buf-risc.cpu[0] |= cpu_to_le32(RISC_IRQ1);
+ wmb();
prev = list_entry(cx88q-active.prev, struct cx23885_buffer,
queue);
list_add_tail(buf-queue, cx88q-active);
prev-risc.jmp[1] = cpu_to_le32(buf-risc.dma);
+ wmb();
dprintk(1, [%p/%d] %s - append to active\n,
buf, buf-vb.v4l2_buf.index, __func__);
}
I wonder if there is some PCI write reordering going on that is causing some
of the weird
behavior that you see.
I'll test this patch on top of the other patches. So far the only
messages left are the mpeg errors.
Regards,
Jurgen
--
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: [PATCH] Si2168: increase timeout to fix firmware loading
On Thu, 2015-01-22 at 12:04 +0200, Antti Palosaari wrote:
I will make pull request for that as that is still on patchwork :(
Thanks, I was about to send in a resend.
Jurgen
Antti
On 12/14/2014 01:29 PM, Antti Palosaari wrote:
On 12/08/2014 07:52 PM, Antti Palosaari wrote:
On 12/08/2014 10:30 AM, Jurgen Kramer wrote:
Increase si2168 cmd execute timeout to prevent firmware load failures.
Tests
shows it takes up to 52ms to load the 'dvb-demod-si2168-a30-01.fw'
firmware.
Increase timeout to a safe value of 70ms.
Signed-off-by: Jurgen Kramer gtmkra...@xs4all.nl
Reviewed-by: Antti Palosaari cr...@iki.fi
Cc: sta...@vger.kernel.org # v3.17+
Cc: sta...@vger.kernel.org # v3.16+
Changed from stable 3.17+ to 3.16+ as I found that PCTV 292e timeouts
too when tuning DVB-T2, not always, but from time to time...
Antti
That must go stable 3.17.
Antti
---
drivers/media/dvb-frontends/si2168.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index ce9ab44..d2f1a3e 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -39,7 +39,7 @@ static int si2168_cmd_execute(struct si2168 *s,
struct si2168_cmd *cmd)
if (cmd-rlen) {
/* wait cmd execution terminate */
-#define TIMEOUT 50
+#define TIMEOUT 70
timeout = jiffies + msecs_to_jiffies(TIMEOUT);
while (!time_after(jiffies, timeout)) {
ret = i2c_master_recv(s-client, cmd-args, cmd-rlen);
--
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: [PATCH] cx23885/vb2 regression: please test this patch
I have been running the original code (because of issues with the patch) for a while with some added printks. This morning I found this NULL pointer derefence: [47772.121968] DEBUG: vb2_thread_stop entered [47772.122014] BUG: unable to handle kernel NULL pointer dereference at (null) [47772.122042] vb2: counters for queue 880407ee9828: UNBALANCED! [47772.122043] vb2: setup: 1 start_streaming: 1 stop_streaming: 1 [47772.122043] vb2: wait_prepare: 249333 wait_finish: 249334 [47772.122083] IP: [a057b65c] cx23885_buf_prepare+0x6c/0xd0 [cx23885] [47772.122102] PGD 0 [47772.122107] Oops: [#1] SMP [47772.122116] Modules linked in: cfg80211 rfkill nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) si2157(OE) si2168(OE) i2c_mux cx25840(OE) cx23885(OE) altera_ci(OE) tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) videobuf2_core(OE) videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq snd_seq_device snd_pcm snd_timer snd soundcore tveeprom(OE) cx2341x(OE) dvb_core(OE) rc_core(OE) v4l2_common(OE) videodev(OE) raid456 async_raid6_recov async_memcpy [47772.122321] async_pq async_xor xor async_tx raid6_pq media(OE) mxm_wmi intel_rapl x86_pkg_temp_thermal coretemp kvm_intel kvm serio_raw shpchp mei_me mei i2c_i801 crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel microcode dw_dmac wmi dw_dmac_core tpm_tis tpm i2c_hid i2c_designware_platform i2c_designware_core acpi_pad nfsd auth_rpcgss nfs_acl lockd sunrpc e1000e i915 ptp pps_core i2c_algo_bit drm_kms_helper drm sdhci_acpi sdhci mmc_core video [47772.122472] CPU: 0 PID: 6151 Comm: vb2-cx23885[2] Tainted: G OE 3.17.8-200.fc20.x86_64 #1 [47772.122492] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z97 Extreme4, BIOS P1.50 12/17/2014 [47772.122523] task: 8803dcfc9d70 ti: 8803652a8000 task.ti: 8803652a8000 [47772.122549] RIP: 0010:[a057b65c] [a057b65c] cx23885_buf_prepare+0x6c/0xd0 [cx23885] [47772.122573] RSP: 0018:8803652abdc8 EFLAGS: 00010246 [47772.122585] RAX: 5e00 RBX: 880036a6d600 RCX: 02f0 [47772.122609] RDX: 5e00 RSI: 88040608a3b8 RDI: 8804091f3000 [47772.122624] RBP: 8803652abdf0 R08: 0020 R09: [47772.122649] R10: 880407ee9828 R11: 880407ee9828 R12: 88040608a000 [47772.122663] R13: 5e00 R14: 880036a6c000 R15: [47772.122677] FS: () GS:88041fa0() knlGS: [47772.122693] CS: 0010 DS: ES: CR0: 80050033 [47772.122705] CR2: CR3: 01c14000 CR4: 001407f0 [47772.122720] DR0: DR1: DR2: [47772.123643] DR3: DR6: fffe0ff0 DR7: 0400 [47772.124605] Stack: [47772.125468] 88040608a000 88040608c458 88040608a000 [47772.126350] 880407ee9828 8803652abe00 a057cd69 8803652abe30 [47772.127230] a04f183e 5e00 880407ee9828 88040608c458 [47772.128129] Call Trace: [47772.129002] [a057cd69] buffer_prepare+0x19/0x20 [cx23885] [47772.129916] [a04f183e] __buf_prepare+0x27e/0x390 [videobuf2_core] [47772.130838] [a04f301b] vb2_internal_qbuf+0x6b/0x210 [videobuf2_core] [47772.131722] [a04f32f6] vb2_thread+0x136/0x4d0 [videobuf2_core] [47772.132642] [a04f31c0] ? vb2_internal_qbuf+0x210/0x210 [videobuf2_core] [47772.133527] [810b04b8] kthread+0xd8/0xf0 [47772.134400] [810b03e0] ? kthread_create_on_node +0x190/0x190 [47772.135268] [8173057c] ret_from_fork+0x7c/0xb0 [47772.136134] [810b03e0] ? kthread_create_on_node +0x190/0x190 [47772.137058] Code: 24 60 02 00 00 85 c0 75 3e 45 85 ed 75 4d 90 8b 8b f0 00 00 00 49 8b be 20 01 00 00 49 8d b4 24 b8 03 00 00 44 8b 83 f4 00 00 00 49 8b 17 45 31 c9 e8 c9 f0 ff ff 31 c0 5b 41 5c 41 5d 41 5e 41 [47772.138917] RIP [a057b65c] cx23885_buf_prepare+0x6c/0xd0 [cx23885] [47772.139841] RSP 8803652abdc8 [47772.140776] CR2: [47772.146080] ---[ end trace 2c986045fea9fe0a ]--- [47772.146236] DEBUG: vb2_thread_stop quit This happened only once normally it just prints: [47179.170117] DEBUG: vb2_thread [47400.670021] DEBUG: vb2_thread_stop entered [47400.670105] DEBUG: vb2_thread_stop quit [47401.012711] DEBUG: vb2_thread [47456.200792] DEBUG: vb2_thread_stop entered [47456.200908] DEBUG: vb2_thread_stop quit [47456.544154] DEBUG: vb2_thread [47480.938606] DEBUG: vb2_thread_stop entered [47480.938711] DEBUG: vb2_thread_stop quit
Re: [PATCH] cx23885/vb2 regression: please test this patch
On Sun, 2015-01-18 at 11:40 +0100, Hans Verkuil wrote: On 01/18/2015 09:54 AM, Jurgen Kramer wrote: I have been running the original code (because of issues with the patch) for a while with some added printks. This morning I found this NULL pointer derefence: That's what my patch fixes, so that's no surprise that you get this. I don't understand why you have issues with the patch, very weird. I just retested with your patch using mplayer instead of mythtv. It played for a few seconds then it froze and the mplayer process is not killable. Can you sent my your version of patched videobuf2-core.c? I had to hand patch (patch did not apply cleanly). Maybe I botched something. Regards, Jurgen Regards, Hans [47772.121968] DEBUG: vb2_thread_stop entered [47772.122014] BUG: unable to handle kernel NULL pointer dereference at (null) [47772.122042] vb2: counters for queue 880407ee9828: UNBALANCED! [47772.122043] vb2: setup: 1 start_streaming: 1 stop_streaming: 1 [47772.122043] vb2: wait_prepare: 249333 wait_finish: 249334 [47772.122083] IP: [a057b65c] cx23885_buf_prepare+0x6c/0xd0 [cx23885] [47772.122102] PGD 0 [47772.122107] Oops: [#1] SMP [47772.122116] Modules linked in: cfg80211 rfkill nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) si2157(OE) si2168(OE) i2c_mux cx25840(OE) cx23885(OE) altera_ci(OE) tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) videobuf2_core(OE) videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq snd_seq_device snd_pcm snd_timer snd soundcore tveeprom(OE) cx2341x(OE) dvb_core(OE) rc_core(OE) v4l2_common(OE) videodev(OE) raid456 async_raid6_recov async_memcpy [47772.122321] async_pq async_xor xor async_tx raid6_pq media(OE) mxm_wmi intel_rapl x86_pkg_temp_thermal coretemp kvm_intel kvm serio_raw shpchp mei_me mei i2c_i801 crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel microcode dw_dmac wmi dw_dmac_core tpm_tis tpm i2c_hid i2c_designware_platform i2c_designware_core acpi_pad nfsd auth_rpcgss nfs_acl lockd sunrpc e1000e i915 ptp pps_core i2c_algo_bit drm_kms_helper drm sdhci_acpi sdhci mmc_core video [47772.122472] CPU: 0 PID: 6151 Comm: vb2-cx23885[2] Tainted: G OE 3.17.8-200.fc20.x86_64 #1 [47772.122492] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z97 Extreme4, BIOS P1.50 12/17/2014 [47772.122523] task: 8803dcfc9d70 ti: 8803652a8000 task.ti: 8803652a8000 [47772.122549] RIP: 0010:[a057b65c] [a057b65c] cx23885_buf_prepare+0x6c/0xd0 [cx23885] [47772.122573] RSP: 0018:8803652abdc8 EFLAGS: 00010246 [47772.122585] RAX: 5e00 RBX: 880036a6d600 RCX: 02f0 [47772.122609] RDX: 5e00 RSI: 88040608a3b8 RDI: 8804091f3000 [47772.122624] RBP: 8803652abdf0 R08: 0020 R09: [47772.122649] R10: 880407ee9828 R11: 880407ee9828 R12: 88040608a000 [47772.122663] R13: 5e00 R14: 880036a6c000 R15: [47772.122677] FS: () GS:88041fa0() knlGS: [47772.122693] CS: 0010 DS: ES: CR0: 80050033 [47772.122705] CR2: CR3: 01c14000 CR4: 001407f0 [47772.122720] DR0: DR1: DR2: [47772.123643] DR3: DR6: fffe0ff0 DR7: 0400 [47772.124605] Stack: [47772.125468] 88040608a000 88040608c458 88040608a000 [47772.126350] 880407ee9828 8803652abe00 a057cd69 8803652abe30 [47772.127230] a04f183e 5e00 880407ee9828 88040608c458 [47772.128129] Call Trace: [47772.129002] [a057cd69] buffer_prepare+0x19/0x20 [cx23885] [47772.129916] [a04f183e] __buf_prepare+0x27e/0x390 [videobuf2_core] [47772.130838] [a04f301b] vb2_internal_qbuf+0x6b/0x210 [videobuf2_core] [47772.131722] [a04f32f6] vb2_thread+0x136/0x4d0 [videobuf2_core] [47772.132642] [a04f31c0] ? vb2_internal_qbuf+0x210/0x210 [videobuf2_core] [47772.133527] [810b04b8] kthread+0xd8/0xf0 [47772.134400] [810b03e0] ? kthread_create_on_node +0x190/0x190 [47772.135268] [8173057c] ret_from_fork+0x7c/0xb0 [47772.136134] [810b03e0] ? kthread_create_on_node +0x190/0x190 [47772.137058] Code: 24 60 02 00 00 85 c0 75 3e 45 85 ed 75 4d 90 8b 8b f0 00 00 00 49 8b be 20 01 00 00 49 8d b4 24 b8 03 00 00 44 8b 83 f4
Re: [PATCH] cx23885/vb2 regression: please test this patch
On Fri, 2015-01-16 at 15:58 +0100, Hans Verkuil wrote: On 01/15/2015 05:32 PM, Jurgen Kramer wrote: Hi Hans, On Tue, 2015-01-13 at 17:59 +0100, Jurgen Kramer wrote: Hi Hans, On Tue, 2015-01-13 at 15:01 +0100, Hans Verkuil wrote: Hi Raimonds, Jurgen, Can you both test this patch? It should (I hope) solve the problems you both had with the cx23885 driver. This patch fixes a race condition in the vb2_thread that occurs when the thread is stopped. The crucial fix is calling kthread_stop much earlier in vb2_thread_stop(). But I also made the vb2_thread more robust. Thanks. Will test your patch and report back. I have tested the patch, unfortunately results are not positive. With the patch MythTV has issues with the tuners. Live TV no longer works and eventually mythbackend hangs. Reverting the patch brings everything back to a working state. Which kernel version are you using? Do you use media_build to install the drivers or do you use a git repository? Do you see any kernel messages? I am on 3.17.7 (F20 x86-64) with current media_build (git://linuxtv.org/media_build.git) There were no kernel messages indicating failure, same goes for mythbackend. Do you get problems with e.g. mplayer or vlc or another GUI tool as well? I have only tested it with MythTV. I'll give a w_scan and mplayer a try to see if that combo gives working TV output. Regards, Jurgen -- 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: [PATCH] cx23885/vb2 regression: please test this patch
Hi Hans, On Tue, 2015-01-13 at 17:59 +0100, Jurgen Kramer wrote: Hi Hans, On Tue, 2015-01-13 at 15:01 +0100, Hans Verkuil wrote: Hi Raimonds, Jurgen, Can you both test this patch? It should (I hope) solve the problems you both had with the cx23885 driver. This patch fixes a race condition in the vb2_thread that occurs when the thread is stopped. The crucial fix is calling kthread_stop much earlier in vb2_thread_stop(). But I also made the vb2_thread more robust. Thanks. Will test your patch and report back. I have tested the patch, unfortunately results are not positive. With the patch MythTV has issues with the tuners. Live TV no longer works and eventually mythbackend hangs. Reverting the patch brings everything back to a working state. Regards, Jurgen -- 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
Re: [PATCH] cx23885/vb2 regression: please test this patch
Hi Hans, On Tue, 2015-01-13 at 15:01 +0100, Hans Verkuil wrote: Hi Raimonds, Jurgen, Can you both test this patch? It should (I hope) solve the problems you both had with the cx23885 driver. This patch fixes a race condition in the vb2_thread that occurs when the thread is stopped. The crucial fix is calling kthread_stop much earlier in vb2_thread_stop(). But I also made the vb2_thread more robust. Thanks. Will test your patch and report back. Regards, Jurgen -- 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: videobuf2_core oops, recent media_build. dvbsky t980c's
Hi Hans, On Mon, 2015-01-12 at 16:29 +0100, Hans Verkuil wrote: On 12/29/2014 03:38 PM, Jurgen Kramer wrote: On Sat, 2014-12-27 at 10:35 +0100, Jurgen Kramer wrote: I am seeing kernel oopses using recent media_builds on kernel 3.17: [ 506.969697] BUG: unable to handle kernel NULL pointer dereference at 0058 [ 506.969720] IP: [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.969739] PGD 0 [ 506.969746] Oops: 0002 [#1] SMP [ 506.969754] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast cfg80211 rfkill ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) si2157(OE) si2168(OE) i2c_mux nouveau cx25840(OE) cx23885(OE) altera_ci(OE) tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) videobuf2_core(OE) videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq snd_seq_device snd_pcm snd_timer snd video i2c_algo_bit ttm drm_kms_helper soundcore iTCO_wdt ppdev gpio_ich iTCO_vendor_support tveeprom(OE) cx2341x(OE) [ 506.969871] coretemp dvb_core(OE) v4l2_common(OE) videodev(OE) media(OE) kvm crc32c_intel raid456 async_raid6_recov async_memcpy async_pq async_xor drm xor async_tx raid6_pq microcode serio_raw shpchp i7core_edac edac_core i2c_i801 lpc_ich mfd_core parport_pc parport ite_cir(OE) rc_core(OE) tpm_infineon tpm_tis tpm acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd sunrpc mxm_wmi asix usbnet r8169 mii wmi [ 506.969970] CPU: 0 PID: 3160 Comm: vb2-cx23885[0] Tainted: G OE 3.17.4-200.fc20.x86_64 #1 [ 506.969982] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./P55 Extreme, BIOS P2.70 08/20/2010 [ 506.969993] task: 8800bc18e220 ti: 88020d36c000 task.ti: 88020d36c000 [ 506.970002] RIP: 0010:[a03a233a] [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.970021] RSP: 0018:88020d36fe68 EFLAGS: 00010246 [ 506.970663] RAX: RBX: RCX: 000b [ 506.971305] RDX: 0058 RSI: 8800bc18e220 RDI: 0058 [ 506.971952] RBP: 88020d36fec0 R08: 88020d36c000 R09: 158f [ 506.972611] R10: 30de R11: 0010 R12: 0058 [ 506.973275] R13: 8800b81814a0 R14: R15: 880225c61028 [ 506.973947] FS: () GS:880233c0() knlGS: [ 506.974634] CS: 0010 DS: ES: CR0: 8005003b [ 506.975321] CR2: 0058 CR3: 01c14000 CR4: 07f0 [ 506.976021] Stack: [ 506.976723] 8800bc18e220 0070 00ff81c1b460 [ 506.977442] 8802 880225c61028 88020d1d8480 880225c61028 [ 506.978165] a03a21c0 88020d36ff48 [ 506.979055] Call Trace: [ 506.979795] [a03a21c0] ? vb2_internal_qbuf+0x210/0x210 [videobuf2_core] [ 506.980545] [810b0498] kthread+0xd8/0xf0 [ 506.981293] [810b03c0] ? kthread_create_on_node +0x190/0x190 [ 506.982045] [8172e33c] ret_from_fork+0x7c/0xb0 [ 506.982806] [810b03c0] ? kthread_create_on_node +0x190/0x190 [ 506.983568] Code: 89 e7 ba 58 00 00 00 0f 85 94 01 00 00 40 f6 c7 02 0f 85 72 01 00 00 40 f6 c7 04 0f 85 50 01 00 00 89 d1 31 c0 c1 e9 03 f6 c2 04 f3 48 ab 74 0a c7 07 00 00 00 00 48 83 c7 04 f6 c2 02 74 0a 31 [ 506.984464] RIP [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.985306] RSP 88020d36fe68 [ 506.986147] CR2: 0058 [ 506.990986] ---[ end trace 1973fbcab83c3353 ]--- First I thought is was related to CAM initialization but after removing the CAMS and doing a fresh cold start I am still seeing the oopses. After the oops everything is still functioning. I am using 3x DVBSKY T980C. How can I debug this further? The problem persist while my system went through a motherboard/mem/cpu upgrade. The oops occurs when one of the DVB-C cards get its first use (in my case mythtv): [ 102.050294] si2157 18-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' [ 181.460968] BUG: unable to handle kernel NULL pointer dereference at 0058 [ 181.460991] IP: [a04d833a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 181.461019] PGD 0 [ 181.461024] Oops: 0002 [#1] SMP [ 181.461032] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter cfg80211 rfkill ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6
Re: videobuf2_core oops, recent media_build. dvbsky t980c's
On Sat, 2014-12-27 at 10:35 +0100, Jurgen Kramer wrote: I am seeing kernel oopses using recent media_builds on kernel 3.17: [ 506.969697] BUG: unable to handle kernel NULL pointer dereference at 0058 [ 506.969720] IP: [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.969739] PGD 0 [ 506.969746] Oops: 0002 [#1] SMP [ 506.969754] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast cfg80211 rfkill ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) si2157(OE) si2168(OE) i2c_mux nouveau cx25840(OE) cx23885(OE) altera_ci(OE) tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) videobuf2_core(OE) videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq snd_seq_device snd_pcm snd_timer snd video i2c_algo_bit ttm drm_kms_helper soundcore iTCO_wdt ppdev gpio_ich iTCO_vendor_support tveeprom(OE) cx2341x(OE) [ 506.969871] coretemp dvb_core(OE) v4l2_common(OE) videodev(OE) media(OE) kvm crc32c_intel raid456 async_raid6_recov async_memcpy async_pq async_xor drm xor async_tx raid6_pq microcode serio_raw shpchp i7core_edac edac_core i2c_i801 lpc_ich mfd_core parport_pc parport ite_cir(OE) rc_core(OE) tpm_infineon tpm_tis tpm acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd sunrpc mxm_wmi asix usbnet r8169 mii wmi [ 506.969970] CPU: 0 PID: 3160 Comm: vb2-cx23885[0] Tainted: G OE 3.17.4-200.fc20.x86_64 #1 [ 506.969982] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./P55 Extreme, BIOS P2.70 08/20/2010 [ 506.969993] task: 8800bc18e220 ti: 88020d36c000 task.ti: 88020d36c000 [ 506.970002] RIP: 0010:[a03a233a] [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.970021] RSP: 0018:88020d36fe68 EFLAGS: 00010246 [ 506.970663] RAX: RBX: RCX: 000b [ 506.971305] RDX: 0058 RSI: 8800bc18e220 RDI: 0058 [ 506.971952] RBP: 88020d36fec0 R08: 88020d36c000 R09: 158f [ 506.972611] R10: 30de R11: 0010 R12: 0058 [ 506.973275] R13: 8800b81814a0 R14: R15: 880225c61028 [ 506.973947] FS: () GS:880233c0() knlGS: [ 506.974634] CS: 0010 DS: ES: CR0: 8005003b [ 506.975321] CR2: 0058 CR3: 01c14000 CR4: 07f0 [ 506.976021] Stack: [ 506.976723] 8800bc18e220 0070 00ff81c1b460 [ 506.977442] 8802 880225c61028 88020d1d8480 880225c61028 [ 506.978165] a03a21c0 88020d36ff48 [ 506.979055] Call Trace: [ 506.979795] [a03a21c0] ? vb2_internal_qbuf+0x210/0x210 [videobuf2_core] [ 506.980545] [810b0498] kthread+0xd8/0xf0 [ 506.981293] [810b03c0] ? kthread_create_on_node +0x190/0x190 [ 506.982045] [8172e33c] ret_from_fork+0x7c/0xb0 [ 506.982806] [810b03c0] ? kthread_create_on_node +0x190/0x190 [ 506.983568] Code: 89 e7 ba 58 00 00 00 0f 85 94 01 00 00 40 f6 c7 02 0f 85 72 01 00 00 40 f6 c7 04 0f 85 50 01 00 00 89 d1 31 c0 c1 e9 03 f6 c2 04 f3 48 ab 74 0a c7 07 00 00 00 00 48 83 c7 04 f6 c2 02 74 0a 31 [ 506.984464] RIP [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.985306] RSP 88020d36fe68 [ 506.986147] CR2: 0058 [ 506.990986] ---[ end trace 1973fbcab83c3353 ]--- First I thought is was related to CAM initialization but after removing the CAMS and doing a fresh cold start I am still seeing the oopses. After the oops everything is still functioning. I am using 3x DVBSKY T980C. How can I debug this further? The problem persist while my system went through a motherboard/mem/cpu upgrade. The oops occurs when one of the DVB-C cards get its first use (in my case mythtv): [ 102.050294] si2157 18-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' [ 181.460968] BUG: unable to handle kernel NULL pointer dereference at 0058 [ 181.460991] IP: [a04d833a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 181.461019] PGD 0 [ 181.461024] Oops: 0002 [#1] SMP [ 181.461032] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter cfg80211 rfkill ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE
videobuf2_core oops, recent media_build
I am seeing kernel oopses using recent media_builds on kernel 3.17: [ 506.969697] BUG: unable to handle kernel NULL pointer dereference at 0058 [ 506.969720] IP: [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.969739] PGD 0 [ 506.969746] Oops: 0002 [#1] SMP [ 506.969754] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast cfg80211 rfkill ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw sp2(OE) si2157(OE) si2168(OE) i2c_mux nouveau cx25840(OE) cx23885(OE) altera_ci(OE) tda18271(OE) altera_stapl(OE) videobuf2_dvb(OE) videobuf2_core(OE) videobuf2_dma_sg(OE) videobuf2_memops(OE) snd_seq snd_seq_device snd_pcm snd_timer snd video i2c_algo_bit ttm drm_kms_helper soundcore iTCO_wdt ppdev gpio_ich iTCO_vendor_support tveeprom(OE) cx2341x(OE) [ 506.969871] coretemp dvb_core(OE) v4l2_common(OE) videodev(OE) media(OE) kvm crc32c_intel raid456 async_raid6_recov async_memcpy async_pq async_xor drm xor async_tx raid6_pq microcode serio_raw shpchp i7core_edac edac_core i2c_i801 lpc_ich mfd_core parport_pc parport ite_cir(OE) rc_core(OE) tpm_infineon tpm_tis tpm acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd sunrpc mxm_wmi asix usbnet r8169 mii wmi [ 506.969970] CPU: 0 PID: 3160 Comm: vb2-cx23885[0] Tainted: G OE 3.17.4-200.fc20.x86_64 #1 [ 506.969982] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./P55 Extreme, BIOS P2.70 08/20/2010 [ 506.969993] task: 8800bc18e220 ti: 88020d36c000 task.ti: 88020d36c000 [ 506.970002] RIP: 0010:[a03a233a] [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.970021] RSP: 0018:88020d36fe68 EFLAGS: 00010246 [ 506.970663] RAX: RBX: RCX: 000b [ 506.971305] RDX: 0058 RSI: 8800bc18e220 RDI: 0058 [ 506.971952] RBP: 88020d36fec0 R08: 88020d36c000 R09: 158f [ 506.972611] R10: 30de R11: 0010 R12: 0058 [ 506.973275] R13: 8800b81814a0 R14: R15: 880225c61028 [ 506.973947] FS: () GS:880233c0() knlGS: [ 506.974634] CS: 0010 DS: ES: CR0: 8005003b [ 506.975321] CR2: 0058 CR3: 01c14000 CR4: 07f0 [ 506.976021] Stack: [ 506.976723] 8800bc18e220 0070 00ff81c1b460 [ 506.977442] 8802 880225c61028 88020d1d8480 880225c61028 [ 506.978165] a03a21c0 88020d36ff48 [ 506.979055] Call Trace: [ 506.979795] [a03a21c0] ? vb2_internal_qbuf+0x210/0x210 [videobuf2_core] [ 506.980545] [810b0498] kthread+0xd8/0xf0 [ 506.981293] [810b03c0] ? kthread_create_on_node +0x190/0x190 [ 506.982045] [8172e33c] ret_from_fork+0x7c/0xb0 [ 506.982806] [810b03c0] ? kthread_create_on_node +0x190/0x190 [ 506.983568] Code: 89 e7 ba 58 00 00 00 0f 85 94 01 00 00 40 f6 c7 02 0f 85 72 01 00 00 40 f6 c7 04 0f 85 50 01 00 00 89 d1 31 c0 c1 e9 03 f6 c2 04 f3 48 ab 74 0a c7 07 00 00 00 00 48 83 c7 04 f6 c2 02 74 0a 31 [ 506.984464] RIP [a03a233a] vb2_thread+0x17a/0x480 [videobuf2_core] [ 506.985306] RSP 88020d36fe68 [ 506.986147] CR2: 0058 [ 506.990986] ---[ end trace 1973fbcab83c3353 ]--- First I thought is was related to CAM initialization but after removing the CAMS and doing a fresh cold start I am still seeing the oopses. After the oops everything is still functioning. I am using 3x DVBSKY T980C. How can I debug this further? Thanks, Jurgen -- 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: DVBSky T980C: Si2168 fw load failed
On Mon, 2014-12-08 at 09:50 +0200, Antti Palosaari wrote: On 12/08/2014 09:39 AM, Jurgen Kramer wrote: On Sun, 2014-12-07 at 16:50 +0200, Antti Palosaari wrote: On 12/07/2014 10:15 AM, Jurgen Kramer wrote: On Sat, 2014-12-06 at 20:29 +0200, Antti Palosaari wrote: On 12/06/2014 06:48 PM, Jurgen Kramer wrote: On my new DVBSky T980C the tuner firmware failes to load: [ 51.326525] si2168 2-0064: found a 'Silicon Labs Si2168' in cold state [ 51.356233] si2168 2-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 51.408166] si2168 2-0064: firmware download failed=-110 [ 51.415457] si2157 4-0060: found a 'Silicon Labs Si2146/2147/2148/2157/2158' in cold state [ 51.521714] si2157 4-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' [ 52.330605] si2168 2-0064: found a 'Silicon Labs Si2168' in cold state [ 52.330784] si2168 2-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 52.382145] si2168 2-0064: firmware download failed=-110 110 seems to mean connection timeout. Any pointers how to debug this further? This is with the latest media_build from linuxtv.org on 3.17.4. Looks like si2168 firmware failed to download, but si2157 succeeded. Could you add some more time for driver timeout? Current timeout is selected by trial and error, lets say it takes always max 43ms for my device I coded it 50ms. drivers/media/dvb-frontends/si2168.c /* wait cmd execution terminate */ #define TIMEOUT 50 change it to #define TIMEOUT 500 Thanks, with the larger timeout the fw load works: [ 56.960982] si2168 4-0064: found a 'Silicon Labs Si2168' in cold state [ 56.972650] si2168 4-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 60.103509] si2168 4-0064: found a 'Silicon Labs Si2168' in warm state [ 60.110739] si2157 6-0060: found a 'Silicon Labs Si2146/2147/2148/2157/2158' in cold state [ 60.123720] si2157 6-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' Have to find out some suitable value. For that I need know how long it took maximum in your case. There is already dubug printing to print execution time of each command, but it is behind dynamic debug. Maybe the most easiest way is change that debug line to info: drivers/media/dvb-frontends/si2168.c - dev_dbg(s-client-dev, cmd execution took %d ms\n, + dev_info(s-client-dev, cmd execution took %d ms\n, and then compile and install and issue command: This gives the following results: [ 50.152281] si2168 4-0064: cmd execution took 0 ms [ 50.154007] si2168 4-0064: cmd execution took 1 ms [ 50.154010] si2168 4-0064: found a 'Silicon Labs Si2168' in cold state [ 50.181157] si2168 4-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 50.233374] si2168 4-0064: cmd execution took 52 ms [ 53.300879] si2168 4-0064: cmd execution took 0 ms [ 53.300880] si2168 4-0064: found a 'Silicon Labs Si2168' in warm state [ 53.308282] si2157 6-0060: found a 'Silicon Labs Si2146/2147/2148/2157/2158' in cold state [ 53.321085] si2157 6-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' [ 54.152370] si2168 4-0064: cmd execution took 1 ms So the initial timeout of 50ms is just missed. New value 60ms? or 75 to be really safe. 70ms sounds nice for my me. Wanna make a patch? Or if it sounds too hard I could make it. No problem creating a patch (against git://linuxtv.org/media_tree.git ?). Regards, Jurgen -- 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
[PATCH] Si2168: increase timeout to fix firmware loading
Increase si2168 cmd execute timeout to prevent firmware load failures. Tests
shows it takes up to 52ms to load the 'dvb-demod-si2168-a30-01.fw' firmware.
Increase timeout to a safe value of 70ms.
Signed-off-by: Jurgen Kramer gtmkra...@xs4all.nl
---
drivers/media/dvb-frontends/si2168.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index ce9ab44..d2f1a3e 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -39,7 +39,7 @@ static int si2168_cmd_execute(struct si2168 *s, struct
si2168_cmd *cmd)
if (cmd-rlen) {
/* wait cmd execution terminate */
- #define TIMEOUT 50
+ #define TIMEOUT 70
timeout = jiffies + msecs_to_jiffies(TIMEOUT);
while (!time_after(jiffies, timeout)) {
ret = i2c_master_recv(s-client, cmd-args, cmd-rlen);
--
1.9.3
--
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: DVBSky T980C: Si2168 fw load failed
On Sat, 2014-12-06 at 20:29 +0200, Antti Palosaari wrote: On 12/06/2014 06:48 PM, Jurgen Kramer wrote: On my new DVBSky T980C the tuner firmware failes to load: [ 51.326525] si2168 2-0064: found a 'Silicon Labs Si2168' in cold state [ 51.356233] si2168 2-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 51.408166] si2168 2-0064: firmware download failed=-110 [ 51.415457] si2157 4-0060: found a 'Silicon Labs Si2146/2147/2148/2157/2158' in cold state [ 51.521714] si2157 4-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' [ 52.330605] si2168 2-0064: found a 'Silicon Labs Si2168' in cold state [ 52.330784] si2168 2-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 52.382145] si2168 2-0064: firmware download failed=-110 110 seems to mean connection timeout. Any pointers how to debug this further? This is with the latest media_build from linuxtv.org on 3.17.4. Looks like si2168 firmware failed to download, but si2157 succeeded. Could you add some more time for driver timeout? Current timeout is selected by trial and error, lets say it takes always max 43ms for my device I coded it 50ms. drivers/media/dvb-frontends/si2168.c /* wait cmd execution terminate */ #define TIMEOUT 50 change it to #define TIMEOUT 500 Thanks, with the larger timeout the fw load works: [ 56.960982] si2168 4-0064: found a 'Silicon Labs Si2168' in cold state [ 56.972650] si2168 4-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 60.103509] si2168 4-0064: found a 'Silicon Labs Si2168' in warm state [ 60.110739] si2157 6-0060: found a 'Silicon Labs Si2146/2147/2148/2157/2158' in cold state [ 60.123720] si2157 6-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' BTW Is there a way to switch between T/T2 and DVB-C mode? Regards, Jurgen -- 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: DVBSky T980C: Si2168 fw load failed
On Sun, 2014-12-07 at 16:50 +0200, Antti Palosaari wrote: On 12/07/2014 10:15 AM, Jurgen Kramer wrote: On Sat, 2014-12-06 at 20:29 +0200, Antti Palosaari wrote: On 12/06/2014 06:48 PM, Jurgen Kramer wrote: On my new DVBSky T980C the tuner firmware failes to load: [ 51.326525] si2168 2-0064: found a 'Silicon Labs Si2168' in cold state [ 51.356233] si2168 2-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 51.408166] si2168 2-0064: firmware download failed=-110 [ 51.415457] si2157 4-0060: found a 'Silicon Labs Si2146/2147/2148/2157/2158' in cold state [ 51.521714] si2157 4-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' [ 52.330605] si2168 2-0064: found a 'Silicon Labs Si2168' in cold state [ 52.330784] si2168 2-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 52.382145] si2168 2-0064: firmware download failed=-110 110 seems to mean connection timeout. Any pointers how to debug this further? This is with the latest media_build from linuxtv.org on 3.17.4. Looks like si2168 firmware failed to download, but si2157 succeeded. Could you add some more time for driver timeout? Current timeout is selected by trial and error, lets say it takes always max 43ms for my device I coded it 50ms. drivers/media/dvb-frontends/si2168.c /* wait cmd execution terminate */ #define TIMEOUT 50 change it to #define TIMEOUT 500 Thanks, with the larger timeout the fw load works: [ 56.960982] si2168 4-0064: found a 'Silicon Labs Si2168' in cold state [ 56.972650] si2168 4-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 60.103509] si2168 4-0064: found a 'Silicon Labs Si2168' in warm state [ 60.110739] si2157 6-0060: found a 'Silicon Labs Si2146/2147/2148/2157/2158' in cold state [ 60.123720] si2157 6-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' Have to find out some suitable value. For that I need know how long it took maximum in your case. There is already dubug printing to print execution time of each command, but it is behind dynamic debug. Maybe the most easiest way is change that debug line to info: drivers/media/dvb-frontends/si2168.c - dev_dbg(s-client-dev, cmd execution took %d ms\n, + dev_info(s-client-dev, cmd execution took %d ms\n, and then compile and install and issue command: This gives the following results: [ 50.152281] si2168 4-0064: cmd execution took 0 ms [ 50.154007] si2168 4-0064: cmd execution took 1 ms [ 50.154010] si2168 4-0064: found a 'Silicon Labs Si2168' in cold state [ 50.181157] si2168 4-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 50.233374] si2168 4-0064: cmd execution took 52 ms [ 53.300879] si2168 4-0064: cmd execution took 0 ms [ 53.300880] si2168 4-0064: found a 'Silicon Labs Si2168' in warm state [ 53.308282] si2157 6-0060: found a 'Silicon Labs Si2146/2147/2148/2157/2158' in cold state [ 53.321085] si2157 6-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' [ 54.152370] si2168 4-0064: cmd execution took 1 ms So the initial timeout of 50ms is just missed. New value 60ms? or 75 to be really safe. $ dvb-fe-tool --set-delsys=DVBT2 Thanks, dvb-fe-tool -a 2 -d dvbc/annex_a worked. Regards, Jurgen -- 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
DVBSky T980C: Si2168 fw load failed
On my new DVBSky T980C the tuner firmware failes to load: [ 51.326525] si2168 2-0064: found a 'Silicon Labs Si2168' in cold state [ 51.356233] si2168 2-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 51.408166] si2168 2-0064: firmware download failed=-110 [ 51.415457] si2157 4-0060: found a 'Silicon Labs Si2146/2147/2148/2157/2158' in cold state [ 51.521714] si2157 4-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' [ 52.330605] si2168 2-0064: found a 'Silicon Labs Si2168' in cold state [ 52.330784] si2168 2-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 52.382145] si2168 2-0064: firmware download failed=-110 110 seems to mean connection timeout. Any pointers how to debug this further? This is with the latest media_build from linuxtv.org on 3.17.4. Jurgen -- 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
