cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon Jan 19 04:00:14 CET 2015 git branch: test git hash: 99f3cd52aee21091ce62442285a68873e3be833f gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17.8-i686: OK linux-3.18-i686: OK linux-3.19-rc4-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.23-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16-x86_64: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18-x86_64: ERRORS linux-3.19-rc4-x86_64: ERRORS apps: OK spec-git: OK sparse: ERRORS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API 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: [PATCH] [media] soc_camera: avoid potential null-dereference
On Wed, 7 Jan 2015, Guennadi Liakhovetski wrote:
> Hi Andy,
>
> Thanks for the patch. Will queue for the next pull request.
Actually no, I won't. I don't think there's currently a but there. the
pointer isn't dereferenced before being checked. Only an address of a
field in a struct, it's pointing to is calculated. So, if it's NULL just a
small offset will be calculated, but no dereferencing will take place.
Thanks
Guennadi
> Regards
> Guennadi
>
> On Wed, 7 Jan 2015, Andy Shevchenko wrote:
>
> > We have to check the pointer before dereferencing it.
> >
> > Signed-off-by: Andy Shevchenko
> > ---
> > drivers/media/platform/soc_camera/soc_camera.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/platform/soc_camera/soc_camera.c
> > b/drivers/media/platform/soc_camera/soc_camera.c
> > index b3db51c..8c665c4 100644
> > --- a/drivers/media/platform/soc_camera/soc_camera.c
> > +++ b/drivers/media/platform/soc_camera/soc_camera.c
> > @@ -2166,7 +2166,7 @@ static int soc_camera_video_start(struct
> > soc_camera_device *icd)
> > static int soc_camera_pdrv_probe(struct platform_device *pdev)
> > {
> > struct soc_camera_desc *sdesc = pdev->dev.platform_data;
> > - struct soc_camera_subdev_desc *ssdd = &sdesc->subdev_desc;
> > + struct soc_camera_subdev_desc *ssdd;
> > struct soc_camera_device *icd;
> > int ret;
> >
> > @@ -2177,6 +2177,8 @@ static int soc_camera_pdrv_probe(struct
> > platform_device *pdev)
> > if (!icd)
> > return -ENOMEM;
> >
> > + ssdd = &sdesc->subdev_desc;
> > +
> > /*
> > * In the asynchronous case ssdd->num_regulators == 0 yet, so, the below
> > * regulator allocation is a dummy. They are actually requested by the
> > --
> > 1.8.3.101.g727a46b
> >
>
--
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: [PATCHv3] media: i2c/adp1653: devicetree support for adp1653
On Sun 2015-01-04 10:43:52, Pavel Machek wrote: > > We are moving to device tree support on OMAP3, but that currently > breaks ADP1653 driver. This adds device tree support, plus required > documentation. > > Signed-off-by: Pavel Machek Sakari? You are listed as adp1653 maintainer. Did you apply the patch? Is it going to be in 3.20? Thanks, Pavel > --- > > Please apply, > Pavel > > diff --git a/Documentation/devicetree/bindings/media/i2c/adp1653.txt > b/Documentation/devicetree/bindings/media/i2c/adp1653.txt > new file mode 100644 > index 000..0fc28a9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/i2c/adp1653.txt > @@ -0,0 +1,37 @@ > +* Analog Devices ADP1653 flash LED driver -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [RFC PATCH 5/5] media: rcar_vin: move buffer management to .stop_streaming handler
On Thu, 18 Dec 2014, Ben Hutchings wrote:
> From: William Towle
>
> Move the buffer state test in the .buf_cleanup handler into
> .stop_streaming so that a) the vb2_queue API is not subverted, and
> b) tracking of active-state buffers via priv->queue_buf[] is handled
> as early as is possible
Huh... Sorry, patches 1, 2, 3, and 5 of this series look like a strange
way to get from the present state to the destination. They all have to be
merged IMHO.
Further, looking at vb2, I don't think active buffers should ever stay
active until .buf_cleanup() is called. I think rcar_vin's
.stop_streaming() should stop the hardware, wait until it's stopped, then
walk all queued buffers and return errors for them, while removing them
from the list at the same time. Then I don't think a .buf_cleanup() method
is needed there at all.
Thanks
Guennadi
>
> Signed-off-by: William Towle
> ---
> drivers/media/platform/soc_camera/rcar_vin.c | 36
> ++
> 1 file changed, 14 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
> b/drivers/media/platform/soc_camera/rcar_vin.c
> index 20dbedf..bf60074 100644
> --- a/drivers/media/platform/soc_camera/rcar_vin.c
> +++ b/drivers/media/platform/soc_camera/rcar_vin.c
> @@ -486,28 +486,8 @@ static void rcar_vin_videobuf_release(struct vb2_buffer
> *vb)
> struct soc_camera_device *icd = soc_camera_from_vb2q(vb->vb2_queue);
> struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
> struct rcar_vin_priv *priv = ici->priv;
> - unsigned int i;
> - int buf_in_use = 0;
> - spin_lock_irq(&priv->lock);
> -
> - /* Is the buffer in use by the VIN hardware? */
> - for (i = 0; i < MAX_BUFFER_NUM; i++) {
> - if (priv->queue_buf[i] == vb) {
> - buf_in_use = 1;
> - break;
> - }
> - }
>
> - if (buf_in_use) {
> - rcar_vin_wait_stop_streaming(priv);
> -
> - /*
> - * Capturing has now stopped. The buffer we have been asked
> - * to release could be any of the current buffers in use, so
> - * release all buffers that are in use by HW
> - */
> - priv->queue_buf[i] = NULL;
> - }
> + spin_lock_irq(&priv->lock);
>
> list_del_init(to_buf_list(vb));
>
> @@ -533,8 +513,20 @@ static void rcar_vin_stop_streaming(struct vb2_queue *vq)
> rcar_vin_wait_stop_streaming(priv);
>
> for (i = 0; i < vq->num_buffers; ++i)
> - if (vq->bufs[i]->state == VB2_BUF_STATE_ACTIVE)
> + if (vq->bufs[i]->state == VB2_BUF_STATE_ACTIVE) {
> + int j;
> +
> + /* Is this a buffer we have told the
> + * hardware about? Update the associated
> + * list, if so
> + */
> + for (j = 0; j < MAX_BUFFER_NUM; j++) {
> + if (priv->queue_buf[j] == vq->bufs[i]) {
> + priv->queue_buf[j] = NULL;
> + }
> + }
> vb2_buffer_done(vq->bufs[i], VB2_BUF_STATE_ERROR);
> + }
>
> list_for_each_safe(buf_head, tmp, &priv->capture)
> list_del_init(buf_head);
> --
> 1.7.10.4
>
>
>
--
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: [RFC PATCH 3/5] media: rcar_vin: Fix race condition terminating stream
On Thu, 18 Dec 2014, Sergei Shtylyov wrote: > Hello. > > On 12/18/2014 05:49 PM, Ben Hutchings wrote: > > > From: Ian Molton > > > This patch fixes a race condition whereby a frame being captured may > > generate an > > interrupt between requesting capture to halt and freeing buffers. > >No need for the leading space. > > > This condition is exposed by the earlier patch that explicitly calls > > vb2_buffer_done() during stop streaming. > >Hm, perhaps for the sake of bisection, these 2 patches need to be merged? +1. Please, don't introduce a bug in one patch to fix it in a later one. Thanks Guennadi > > > The solution is to wait for capture to finish prior to finalising these > > buffers. > > > Signed-off-by: Ian Molton > > Signed-off-by: William Towle > > --- > > drivers/media/platform/soc_camera/rcar_vin.c | 43 > > +- > > 1 file changed, 28 insertions(+), 15 deletions(-) > > > diff --git a/drivers/media/platform/soc_camera/rcar_vin.c > > b/drivers/media/platform/soc_camera/rcar_vin.c > > index 7069176..b234e57 100644 > > --- a/drivers/media/platform/soc_camera/rcar_vin.c > > +++ b/drivers/media/platform/soc_camera/rcar_vin.c > [...] > > @@ -465,7 +488,6 @@ static void rcar_vin_videobuf_release(struct vb2_buffer > > *vb) > > struct rcar_vin_priv *priv = ici->priv; > > unsigned int i; > > int buf_in_use = 0; > > - > >Unrelated white space change. Moreover, there should be an empty line after > declarations. > > > spin_lock_irq(&priv->lock); > > > > /* Is the buffer in use by the VIN hardware? */ > [...] > > @@ -520,12 +530,15 @@ static void rcar_vin_stop_streaming(struct vb2_queue > > *vq) > > > > spin_lock_irq(&priv->lock); > > > > + rcar_vin_wait_stop_streaming(priv); > > + > > for (i = 0; i < vq->num_buffers; ++i) > > if (vq->bufs[i]->state == VB2_BUF_STATE_ACTIVE) > > vb2_buffer_done(vq->bufs[i], VB2_BUF_STATE_ERROR); > > > > list_for_each_safe(buf_head, tmp, &priv->capture) > > list_del_init(buf_head); > > + > >Also seems like unrelated whitespace cleanup. > > > spin_unlock_irq(&priv->lock); > > } > > WBR, Sergei > -- 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 2/4] media: rcar_vin: Ensure all in-flight buffers are returned to error state before stopping.
Hi Ian,
Apparently, I wasn't quite right in my reply to patch 1 from this series.
It seems to be related to this one and to Hans' comment below. Taking it
into account, it seems you shouldn't remove cancelled active buffers from
the list without calling vb2_buffer_done(&buf->vb, VB2_BUF_STATE_ERROR)
for them. So, I think you should modify your patch 1 to either leave those
buffers on the list and report them "done" here, or call "done" for them
when removing from the list. I think I'd rather go with the latter option
to not keep failed buffers on the list and rely, that the vb2 core will
stop streaming soon. Hans, do you agree?
Thanks
Guennadi
On Mon, 4 Aug 2014, Hans Verkuil wrote:
> On 07/08/2014 11:41 AM, Ian Molton wrote:
> > Videobuf2 complains about buffers that are still marked ACTIVE (in use by
> > the driver) following a call to stop_streaming().
> >
> > This patch returns all active buffers to state ERROR prior to stopping.
> >
> > Note: this introduces a (non fatal) race condition as the stream is not
> > guaranteed to be stopped at this point.
> >
> > Signed-off-by: Ian Molton
> > Signed-off-by: William Towle
> > ---
> > drivers/media/platform/soc_camera/rcar_vin.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
> > b/drivers/media/platform/soc_camera/rcar_vin.c
> > index 7154500..06ce705 100644
> > --- a/drivers/media/platform/soc_camera/rcar_vin.c
> > +++ b/drivers/media/platform/soc_camera/rcar_vin.c
> > @@ -513,8 +513,14 @@ static void rcar_vin_stop_streaming(struct vb2_queue
> > *vq)
> > struct soc_camera_host *ici = to_soc_camera_host(icd->parent);
> > struct rcar_vin_priv *priv = ici->priv;
> > struct list_head *buf_head, *tmp;
> > + int i;
> >
> > spin_lock_irq(&priv->lock);
> > +
> > + for (i = 0; i < vq->num_buffers; ++i)
> > + if (vq->bufs[i]->state == VB2_BUF_STATE_ACTIVE)
> > + vb2_buffer_done(vq->bufs[i], VB2_BUF_STATE_ERROR);
> > +
> > list_for_each_safe(buf_head, tmp, &priv->capture)
> > list_del_init(buf_head);
>
> I'm assuming all buffers that are queued to the driver via buf_queue() are
> linked into priv->capture. So you would typically call vb2_buffer_done
> when you are walking that list:
>
> list_for_each_safe(buf_head, tmp, &priv->capture) {
> // usually you go from buf_head to the real buffer struct
> // containing a vb2_buffer struct
> vb2_buffer_done(&buf->vb, VB2_BUF_STATE_ERROR);
> list_del_init(buf_head);
> }
>
> Please use this rather than looking into internal vb2_queue datastructures.
>
> Regards,
>
> Hans
>
> > spin_unlock_irq(&priv->lock);
> >
>
--
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: [RFC PATCH 1/5] media: rcar_vin: Dont aggressively retire buffers
Hi Ben,
Sorry for a long delay. The patch looks good to me, although I'll extend
it a bit by also removing the comment above the deleted loop - it's no
longer relevant.
Thanks
Guennadi
On Thu, 18 Dec 2014, Ben Hutchings wrote:
> From: Ian Molton
>
> rcar_vin_videobuf_release() is called once per buffer from the buf_cleanup
> hook.
>
> There is no need to look up the queue and free all buffers at this point.
>
> Signed-off-by: Ian Molton
> Signed-off-by: William Towle
> ---
> drivers/media/platform/soc_camera/rcar_vin.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
> b/drivers/media/platform/soc_camera/rcar_vin.c
> index 8d8438b..773de53 100644
> --- a/drivers/media/platform/soc_camera/rcar_vin.c
> +++ b/drivers/media/platform/soc_camera/rcar_vin.c
> @@ -496,17 +496,11 @@ static void rcar_vin_videobuf_release(struct vb2_buffer
> *vb)
>* to release could be any of the current buffers in use, so
>* release all buffers that are in use by HW
>*/
> - for (i = 0; i < MAX_BUFFER_NUM; i++) {
> - if (priv->queue_buf[i]) {
> - vb2_buffer_done(priv->queue_buf[i],
> - VB2_BUF_STATE_ERROR);
> - priv->queue_buf[i] = NULL;
> - }
> - }
> - } else {
> - list_del_init(to_buf_list(vb));
> + priv->queue_buf[i] = NULL;
> }
>
> + list_del_init(to_buf_list(vb));
> +
> spin_unlock_irq(&priv->lock);
> }
>
> --
> 1.7.10.4
>
>
>
>
--
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
Darlehen
man einen Kredit? kontaktieren Amegy Banküber unten. Name: === Benötigte Stückzahl: === Dauer: == Land: == Mobile Phone: == info-amegyl...@qq.com www.amegy.ibnk-us.com Herr Edward Mancon Niederlassungsleiter (USA) --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- 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: Latest media_build break Geniatech T230
Hello Roy, There's already a fix for this problem, it just has not made it's way yet to media_tree. https://www.mail-archive.com/linux-media@vger.kernel.org/msg83778.html I see Hans submitted a pull request just a couple of days ago which includes this patch, so probably the media_build will be ok in the nearby future as well when it comes to this device. Cheers, -olli On 18 January 2015 at 05:11, Roy Keano wrote: > identification of the device with which you are having difficulty: > Geniatech T230 > > the device's subsystem ID, taken from the output of lspci -vnn (for > PCI/PCIe devices) or lsusb -v (for USB based devices): > ID 0572:c688 > > the environment your running it under (e.g. Fedora 10, with kernel > 2.6.27.5, 64-bit), and with what other hardware (e.g. ASUS Core 2 Duo > motherboard): > Debian 7.7 > 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u2 x86_64 GNU/Linux > > a note of whether you're using the built in kernel drivers supplied by > your distro or if you have installed the v4l-dvb driver set, or those > from one of the LinuxTV developers' repos > installed the v4l-dvb driver set using media_build > > /var/log/message log: > cite the television standard applicable for your device (e.g. ATSC > tuner card, PAL capture card) > > ..dvb_usb_cxusb: probe of 1-2:1.0 failed with error -22 > ...usbcore: registered new interface driver dvb_usb_cxusb > > Exact sequence of actions that causes your problem. If it is possible, > try to provide a simple reproducible test case, as this makes it much > easier to track down the actual problem.: > > Install using the simple procedure of media_build without any > indication of error, latest copy of drivers was installed > > Copied the 2 firmwares relevant to the tuner from openelec > > Reboot the system > > Plug in dvb-t stick > > /dev/dvb file was MISSING > > ** > I googled around and found this post by Crni Gruja: > https://tvheadend.org/boards/5/topics/10864?page=8 > > I downloaded and used his media_build script. (The link to poster's > media_build can be found at the above link) > > The /var/log/message showed: > > Jan 18 11:03:34 jebat kernel: [34051.900148] usb 7-1: new high-speed > USB device number 9 using ehci_hcd > Jan 18 11:03:34 jebat kernel: [34052.032992] usb 7-1: New USB device > found, idVendor=0572, idProduct=c688 > Jan 18 11:03:34 jebat kernel: [34052.033001] usb 7-1: New USB device > strings: Mfr=1, Product=2, SerialNumber=3 > Jan 18 11:03:34 jebat kernel: [34052.033008] usb 7-1: Product: USB Stick > Jan 18 11:03:34 jebat kernel: [34052.033013] usb 7-1: Manufacturer: Max > Jan 18 11:03:34 jebat kernel: [34052.033018] usb 7-1: SerialNumber: 080116 > Jan 18 11:03:34 jebat kernel: [34052.033712] dvb-usb: found a 'Mygica > T230 DVB-T/T2/C' in warm state. > Jan 18 11:03:34 jebat kernel: [34052.268209] dvb-usb: will pass the > complete MPEG2 transport stream to the software demuxer. > Jan 18 11:03:34 jebat kernel: [34052.268402] DVB: registering new > adapter (Mygica T230 DVB-T/T2/C) > Jan 18 11:03:34 jebat kernel: [34052.273649] input: IR-receiver inside > an USB DVB receiver as > /devices/pci:00/:00:1d.7/usb7/7-1/input/input11 > Jan 18 11:03:34 jebat kernel: [34052.273806] dvb-usb: schedule remote > query interval to 100 msecs. > Jan 18 11:03:34 jebat kernel: [34052.273989] dvb-usb: Mygica T230 > DVB-T/T2/C successfully initialized and connected. > Jan 18 11:03:34 jebat mtp-probe: checking bus 7, device 9: > "/sys/devices/pci:00/:00:1d.7/usb7/7-1" > Jan 18 11:03:34 jebat mtp-probe: bus: 7, device: 9 was not an MTP device > > ls -l /dev/dvd: > drwxr-xr-x 2 root root 100 Jan 18 11:03 adapter0 > > > Best Regards > -- > 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
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: [] 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:[] [] > > 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] [] buffer_prepare+0x19/0x20 [cx23885] > > [47772.129916] [] __buf_prepare+0x27e/0x390 > > [videobuf2_core] > > [47772.130838] [] vb2_internal_qbuf+0x6b/0x210 > > [videobuf2_core] > > [47772.131722] [] vb2_thread+0x136/0x4d0 > > [videobuf2_core] > > [47772.132642] [] ? vb2_internal_qbuf+0x210/0x210 > > [videobuf2_core] > > [47772.133527] [] kthread+0xd8/0xf0 > > [47772.134400] [] ? kthread_create_on_node > > +0x190/0x190 > > [47772.135268] [] ret_from_fork+0x7c/0xb0 > > [47772.136134] [] ? 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
Re: [PATCH] cx23885/vb2 regression: please test this patch
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. 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: [] 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:[] [] > 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] [] buffer_prepare+0x19/0x20 [cx23885] > [47772.129916] [] __buf_prepare+0x27e/0x390 > [videobuf2_core] > [47772.130838] [] vb2_internal_qbuf+0x6b/0x210 > [videobuf2_core] > [47772.131722] [] vb2_thread+0x136/0x4d0 > [videobuf2_core] > [47772.132642] [] ? vb2_internal_qbuf+0x210/0x210 > [videobuf2_core] > [47772.133527] [] kthread+0xd8/0xf0 > [47772.134400] [] ? kthread_create_on_node > +0x190/0x190 > [47772.135268] [] ret_from_fork+0x7c/0xb0 > [47772.136134] [] ? 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 [] cx23885_buf_prepare+0x6c/0xd0 > [cx23885] > [47772.139841] RSP > [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_
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: [] 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:[] [] 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] [] buffer_prepare+0x19/0x20 [cx23885] [47772.129916] [] __buf_prepare+0x27e/0x390 [videobuf2_core] [47772.130838] [] vb2_internal_qbuf+0x6b/0x210 [videobuf2_core] [47772.131722] [] vb2_thread+0x136/0x4d0 [videobuf2_core] [47772.132642] [] ? vb2_internal_qbuf+0x210/0x210 [videobuf2_core] [47772.133527] [] kthread+0xd8/0xf0 [47772.134400] [] ? kthread_create_on_node +0x190/0x190 [47772.135268] [] ret_from_fork+0x7c/0xb0 [47772.136134] [] ? 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 [] cx23885_buf_prepare+0x6c/0xd0 [cx23885] [47772.139841] RSP [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 [47481.024019] DEBUG: vb2_thread [47708.823051] DEBUG: vb2_thread_stop entered [47708.823184] DEBUG: vb2_thread_stop quit [47709.166499] DEBUG: vb2_thread Regards, Jurgen -- To unsubscribe from this list: send the line "unsubscrib
