changeset 14351:2eda2bcc8d6f

changeset 14351:2eda2bcc8d6f

[e9hack]

Hi,

changeset 14351:2eda2bcc8d6f is incomplete. If the init function is split in two function,
the deinit function shall consider this. The changes shall be apply also to av7110_init_v4l().

diff -r 58ae12f18e80 linux/drivers/media/common/saa7146_fops.c
--- a/linux/drivers/media/common/saa7146_fops.c Tue Mar 02 23:52:36 2010 -0300
+++ b/linux/drivers/media/common/saa7146_fops.c Wed Mar 03 12:15:23 2010 +0100
@@ -481,8 +481,10 @@ int saa7146_vv_release(struct saa7146_de
        DEB_EE(("dev:%p\n",dev));

        v4l2_device_unregister(&dev->v4l2_dev);
-       pci_free_consistent(dev->pci, SAA7146_CLIPPING_MEM, vv->d_clipping.cpu_addr,
vv->d_clipping.dma_handle);
-       kfree(vv);
+       if (vv) {
+               pci_free_consistent(dev->pci, SAA7146_CLIPPING_MEM,
vv->d_clipping.cpu_addr, vv->d_clipping.dma_handle);
+               kfree(vv);
+       }
        dev->vv_data = NULL;
        dev->vv_callback = NULL;

diff -r 58ae12f18e80 linux/drivers/media/dvb/ttpci/av7110_v4l.c
--- a/linux/drivers/media/dvb/ttpci/av7110_v4l.c        Tue Mar 02 23:52:36 2010 -0300
+++ b/linux/drivers/media/dvb/ttpci/av7110_v4l.c        Wed Mar 03 12:15:23 2010 +0100
@@ -790,12 +790,20 @@ int av7110_init_v4l(struct av7110 *av711
                vv_data = &av7110_vv_data_c;
        else
                vv_data = &av7110_vv_data_st;
+       ret = saa7146_vv_devinit(dev);
+
+       if (ret < 0) {
+               ERR(("cannot init device. skipping.\n"));
+               return ret;
+       }
+
        ret = saa7146_vv_init(dev, vv_data);
-
-       if (ret) {
+       if (ret < 0) {
                ERR(("cannot init capture device. skipping.\n"));
+               saa7146_vv_release(dev);
                return ret;
        }
+
        vv_data->ops.vidioc_enum_input = vidioc_enum_input;
        vv_data->ops.vidioc_g_input = vidioc_g_input;
        vv_data->ops.vidioc_s_input = vidioc_s_input;

Regards,
Hartmut

Re: changeset 14351:2eda2bcc8d6f

[Hans Verkuil]

Hi Hartmut,

After reviewing your patch I realized that more needed to be done to get this
to work properly. The core problem is that the probe function does not have a
counterpart that can do a cleanup.

So if the probe fails, then v4l2_device_unregister will never be called, which
is a particular problem on mxb.

I've made a new patch that basically reverts my original patch and instead
modifies the mxb driver. I realized that mxb doesn't need to do a separate
probe. Instead attach can just call probe and return an error if it fails.

This way I can avoid the devinit and the cleanup is also much more straightforward.

If there are no further comments, then I'll post a pull request in a few days.

Tested with the mxb board. It would be nice if you can verify this with the
av7110.

Regards,

	Hans

diff --git a/drivers/media/common/saa7146_fops.c b/drivers/media/common/saa7146_fops.c
index fd8e1f4..7364b96 100644
--- a/drivers/media/common/saa7146_fops.c
+++ b/drivers/media/common/saa7146_fops.c
@@ -423,15 +423,14 @@ static void vv_callback(struct saa7146_dev *dev, unsigned long status)
 	}
 }
 
-int saa7146_vv_devinit(struct saa7146_dev *dev)
-{
-	return v4l2_device_register(&dev->pci->dev, &dev->v4l2_dev);
-}
-EXPORT_SYMBOL_GPL(saa7146_vv_devinit);
-
 int saa7146_vv_init(struct saa7146_dev* dev, struct saa7146_ext_vv *ext_vv)
 {
 	struct saa7146_vv *vv;
+	int err;
+
+	err = v4l2_device_register(&dev->pci->dev, &dev->v4l2_dev);
+	if (err)
+		return err;
 
 	vv = kzalloc(sizeof(struct saa7146_vv), GFP_KERNEL);
 	if (vv == NULL) {
diff --git a/drivers/media/video/hexium_gemini.c b/drivers/media/video/hexium_gemini.c
index e620a3a..ad2c232 100644
--- a/drivers/media/video/hexium_gemini.c
+++ b/drivers/media/video/hexium_gemini.c
@@ -356,9 +356,6 @@ static int hexium_attach(struct saa7146_dev *dev, struct saa7146_pci_extension_d
 
 	DEB_EE((".\n"));
 
-	ret = saa7146_vv_devinit(dev);
-	if (ret)
-		return ret;
 	hexium = kzalloc(sizeof(struct hexium), GFP_KERNEL);
 	if (NULL == hexium) {
 		printk("hexium_gemini: not enough kernel memory in hexium_attach().\n");
diff --git a/drivers/media/video/hexium_orion.c b/drivers/media/video/hexium_orion.c
index fe596a1..938a1f8 100644
--- a/drivers/media/video/hexium_orion.c
+++ b/drivers/media/video/hexium_orion.c
@@ -216,10 +216,6 @@ static int hexium_probe(struct saa7146_dev *dev)
 		return -EFAULT;
 	}
 
-	err = saa7146_vv_devinit(dev);
-	if (err)
-		return err;
-
 	hexium = kzalloc(sizeof(struct hexium), GFP_KERNEL);
 	if (NULL == hexium) {
 		printk("hexium_orion: hexium_probe: not enough kernel memory.\n");
diff --git a/drivers/media/video/mxb.c b/drivers/media/video/mxb.c
index 9f01f14..ef0c817 100644
--- a/drivers/media/video/mxb.c
+++ b/drivers/media/video/mxb.c
@@ -169,11 +169,7 @@ static struct saa7146_extension extension;
 static int mxb_probe(struct saa7146_dev *dev)
 {
 	struct mxb *mxb = NULL;
-	int err;
 
-	err = saa7146_vv_devinit(dev);
-	if (err)
-		return err;
 	mxb = kzalloc(sizeof(struct mxb), GFP_KERNEL);
 	if (mxb == NULL) {
 		DEB_D(("not enough kernel memory.\n"));
@@ -699,14 +695,17 @@ static struct saa7146_ext_vv vv_data;
 /* this function only gets called when the probing was successful */
 static int mxb_attach(struct saa7146_dev *dev, struct saa7146_pci_extension_data *info)
 {
-	struct mxb *mxb = (struct mxb *)dev->ext_priv;
+	struct mxb *mxb;
 
 	DEB_EE(("dev:%p\n", dev));
 
-	/* checking for i2c-devices can be omitted here, because we
-	   already did this in "mxb_vl42_probe" */
-
 	saa7146_vv_init(dev, &vv_data);
+	if (mxb_probe(dev)) {
+		saa7146_vv_release(dev);
+		return -1;
+	}
+	mxb = (struct mxb *)dev->ext_priv;
+
 	vv_data.ops.vidioc_queryctrl = vidioc_queryctrl;
 	vv_data.ops.vidioc_g_ctrl = vidioc_g_ctrl;
 	vv_data.ops.vidioc_s_ctrl = vidioc_s_ctrl;
@@ -726,6 +725,7 @@ static int mxb_attach(struct saa7146_dev *dev, struct saa7146_pci_extension_data
 	vv_data.ops.vidioc_default = vidioc_default;
 	if (saa7146_register_device(&mxb->video_dev, dev, "mxb", VFL_TYPE_GRABBER)) {
 		ERR(("cannot register capture v4l2 device. skipping.\n"));
+		saa7146_vv_release(dev);
 		return -1;
 	}
 
@@ -846,7 +846,6 @@ static struct saa7146_extension extension = {
 	.pci_tbl	= &pci_tbl[0],
 	.module		= THIS_MODULE,
 
-	.probe		= mxb_probe,
 	.attach		= mxb_attach,
 	.detach		= mxb_detach,
 
diff --git a/include/media/saa7146_vv.h b/include/media/saa7146_vv.h
index b9da1f5..4aeff96 100644
--- a/include/media/saa7146_vv.h
+++ b/include/media/saa7146_vv.h
@@ -188,7 +188,6 @@ void saa7146_buffer_timeout(unsigned long data);
 void saa7146_dma_free(struct saa7146_dev* dev,struct videobuf_queue *q,
 						struct saa7146_buf *buf);
 
-int saa7146_vv_devinit(struct saa7146_dev *dev);
 int saa7146_vv_init(struct saa7146_dev* dev, struct saa7146_ext_vv *ext_vv);
 int saa7146_vv_release(struct saa7146_dev* dev);
 


On Wednesday 03 March 2010 12:39:27 e9hack wrote:
> Hi,
> 
> changeset 14351:2eda2bcc8d6f is incomplete. If the init function is split in two function,
> the deinit function shall consider this. The changes shall be apply also to av7110_init_v4l().
> 
> diff -r 58ae12f18e80 linux/drivers/media/common/saa7146_fops.c
> --- a/linux/drivers/media/common/saa7146_fops.c Tue Mar 02 23:52:36 2010 -0300
> +++ b/linux/drivers/media/common/saa7146_fops.c Wed Mar 03 12:15:23 2010 +0100
> @@ -481,8 +481,10 @@ int saa7146_vv_release(struct saa7146_de
>         DEB_EE(("dev:%p\n",dev));
> 
>         v4l2_device_unregister(&dev->v4l2_dev);
> -       pci_free_consistent(dev->pci, SAA7146_CLIPPING_MEM, vv->d_clipping.cpu_addr,
> vv->d_clipping.dma_handle);
> -       kfree(vv);
> +       if (vv) {
> +               pci_free_consistent(dev->pci, SAA7146_CLIPPING_MEM,
> vv->d_clipping.cpu_addr, vv->d_clipping.dma_handle);
> +               kfree(vv);
> +       }
>         dev->vv_data = NULL;
>         dev->vv_callback = NULL;
> 
> diff -r 58ae12f18e80 linux/drivers/media/dvb/ttpci/av7110_v4l.c
> --- a/linux/drivers/media/dvb/ttpci/av7110_v4l.c        Tue Mar 02 23:52:36 2010 -0300
> +++ b/linux/drivers/media/dvb/ttpci/av7110_v4l.c        Wed Mar 03 12:15:23 2010 +0100
> @@ -790,12 +790,20 @@ int av7110_init_v4l(struct av7110 *av711
>                 vv_data = &av7110_vv_data_c;
>         else
>                 vv_data = &av7110_vv_data_st;
> +       ret = saa7146_vv_devinit(dev);
> +
> +       if (ret < 0) {
> +               ERR(("cannot init device. skipping.\n"));
> +               return ret;
> +       }
> +
>         ret = saa7146_vv_init(dev, vv_data);
> -
> -       if (ret) {
> +       if (ret < 0) {
>                 ERR(("cannot init capture device. skipping.\n"));
> +               saa7146_vv_release(dev);
>                 return ret;
>         }
> +
>         vv_data->ops.vidioc_enum_input = vidioc_enum_input;
>         vv_data->ops.vidioc_g_input = vidioc_g_input;
>         vv_data->ops.vidioc_s_input = vidioc_s_input;
> 
> Regards,
> Hartmut
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: changeset 14351:2eda2bcc8d6f

[e9hack]

Am 13.3.2010 17:27, schrieb Hans Verkuil:
> If there are no further comments, then I'll post a pull request in a few days.
> 
> Tested with the mxb board. It would be nice if you can verify this with the
> av7110.

Hi hans,

it works with my TT-C2300 perfectly. The main problem of your changes was: It wasn't
possible to unload the module for the TT-C2300.

Regards,
Hartmut

av7110 and budget_av are broken! (was: Re: changeset 14351:2eda2bcc8d6f)

[Oliver Endriss]

e9hack wrote:
> Am 13.3.2010 17:27, schrieb Hans Verkuil:
> > If there are no further comments, then I'll post a pull request in a few days.
> > 
> > Tested with the mxb board. It would be nice if you can verify this with the
> > av7110.
> 
> Hi hans,
> 
> it works with my TT-C2300 perfectly. The main problem of your changes was: It wasn't
> possible to unload the module for the TT-C2300.

Guys, when will you finally apply this fix?

As Hartmut pointed out, changeset 14351:2eda2bcc8d6f broke the av7110
driver (and also budget-av).

It is time to fix it. This bug must not go into the kernel!

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: av7110 and budget_av are broken! (was: Re: changeset 14351:2eda2bcc8d6f)

[Hans Verkuil]

On Saturday 20 March 2010 15:07:08 Oliver Endriss wrote:
> e9hack wrote:
> > Am 13.3.2010 17:27, schrieb Hans Verkuil:
> > > If there are no further comments, then I'll post a pull request in a few days.
> > > 
> > > Tested with the mxb board. It would be nice if you can verify this with the
> > > av7110.
> > 
> > Hi hans,
> > 
> > it works with my TT-C2300 perfectly. The main problem of your changes was: It wasn't
> > possible to unload the module for the TT-C2300.
> 
> Guys, when will you finally apply this fix?

Thanks for reminding me, I frankly forgot about this.

Hartmut, is the problem with unloading the module something that my patch
caused? Or was that there as well before changeset 14351:2eda2bcc8d6f?
Are there any kernel messages indicating why it won't unload?

Regards,

	Hans

> As Hartmut pointed out, changeset 14351:2eda2bcc8d6f broke the av7110
> driver (and also budget-av).
> 
> It is time to fix it. This bug must not go into the kernel!
> 
> CU
> Oliver
> 
> 

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: av7110 and budget_av are broken! (was: Re: changeset 14351:2eda2bcc8d6f)

[Oliver Endriss]

Hans Verkuil wrote:
> On Saturday 20 March 2010 15:07:08 Oliver Endriss wrote:
> > e9hack wrote:
> > > Am 13.3.2010 17:27, schrieb Hans Verkuil:
> > > > If there are no further comments, then I'll post a pull request in a few days.
> > > > 
> > > > Tested with the mxb board. It would be nice if you can verify this with the
> > > > av7110.
> > > 
> > > Hi hans,
> > > 
> > > it works with my TT-C2300 perfectly. The main problem of your changes was: It wasn't
> > > possible to unload the module for the TT-C2300.
> > 
> > Guys, when will you finally apply this fix?
> 
> Thanks for reminding me, I frankly forgot about this.
> 
> Hartmut, is the problem with unloading the module something that my patch
> caused? Or was that there as well before changeset 14351:2eda2bcc8d6f?
> Are there any kernel messages indicating why it won't unload?

The patch caused the problem.

You moved v4l2_device_register() from saa7146_vv_init() to
saa7146_vv_devinit(), but you did not modify av7110_v4l.c and
budget-av.c accordingly.

$ grep saa7146_vv_init v4l/*c
v4l/av7110_v4l.c:       ret = saa7146_vv_init(dev, vv_data);
v4l/budget-av.c:                if (0 != saa7146_vv_init(dev, &vv_data)) {
v4l/hexium_gemini.c:    saa7146_vv_init(dev, &vv_data);
v4l/hexium_orion.c:     saa7146_vv_init(dev, &vv_data);
v4l/mxb.c:      saa7146_vv_init(dev, &vv_data);
v4l/saa7146_fops.c:int saa7146_vv_init(struct saa7146_dev* dev, struct saa7146_ext_vv *ext_vv)
v4l/saa7146_fops.c:EXPORT_SYMBOL_GPL(saa7146_vv_init);
v4l/saa7146_fops.c:static int __init saa7146_vv_init_module(void)
v4l/saa7146_fops.c:module_init(saa7146_vv_init_module);

$ grep saa7146_vv_devinit v4l/*c
v4l/hexium_gemini.c:    ret = saa7146_vv_devinit(dev);
v4l/hexium_orion.c:     err = saa7146_vv_devinit(dev);
v4l/mxb.c:      err = saa7146_vv_devinit(dev);
v4l/saa7146_fops.c:int saa7146_vv_devinit(struct saa7146_dev *dev)
v4l/saa7146_fops.c:EXPORT_SYMBOL_GPL(saa7146_vv_devinit);

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: av7110 and budget_av are broken!

[e9hack]

Am 20.3.2010 15:20, schrieb Hans Verkuil:
> Hartmut, is the problem with unloading the module something that my patch
> caused? Or was that there as well before changeset 14351:2eda2bcc8d6f?
> Are there any kernel messages indicating why it won't unload?

Changset 14351:2eda2bcc8d6f causes a kernel oops during unload of the module for my dvb
cards. The call trace points to dvb_ttpci. I assumed, that the FF card is affected only.
It may be possible, that budget-av does crash also, if it is unload as second.

Regards,
Hartmut

Mar  3 11:42:33 vdr kernel: [ 3291.915576] saa7146: unregister extension 'budget_av'.
Mar  3 11:42:33 vdr kernel: [ 3291.916426] budget_av 0000:04:07.0: PCI INT A disabled
Mar  3 11:42:33 vdr kernel: [ 3291.918565] saa7146: unregister extension 'dvb'.
Mar  3 11:42:33 vdr kernel: [ 3291.918750] BUG: unable to handle kernel NULL pointer
dereference at (null)
Mar  3 11:42:33 vdr kernel: [ 3291.918966] IP: [<ffffffffa0286aac>]
v4l2_device_unregister+0x1c/0x60 [videodev]
Mar  3 11:42:33 vdr kernel: [ 3291.919013] PGD 3db10067 PUD 37a3d067 PMD 0
Mar  3 11:42:33 vdr kernel: [ 3291.919013] Oops: 0000 [#1] PREEMPT SMP
Mar  3 11:42:33 vdr kernel: [ 3291.919013] last sysfs file:
/sys/devices/platform/w83627ehf.2576/cpu0_vid
Mar  3 11:42:33 vdr kernel: [ 3291.919013] CPU 0
Mar  3 11:42:33 vdr kernel: [ 3291.919013] Pid: 15305, comm: rmmod Not tainted
2.6.33-64-suse-11.0 #4 MS-7207PV/MS-7207PV
Mar  3 11:42:33 vdr kernel: [ 3291.919013] RIP: 0010:[<ffffffffa0286aac>]
[<ffffffffa0286aac>] v4l2_device_unregister+0x1c/0x60 [videodev]
Mar  3 11:42:33 vdr kernel: [ 3291.919013] RSP: 0018:ffff88003da55cc8  EFLAGS: 00010203
Mar  3 11:42:33 vdr kernel: [ 3291.919013] RAX: 0000000000000000 RBX: 0000000000000000
RCX: ffff88003d64d3e0
Mar  3 11:42:34 vdr kernel: [ 3291.919013] RDX: 0000000000000001 RSI: 0000000000000000
RDI: 0000000000000000
Mar  3 11:42:34 vdr kernel: [ 3291.919013] RBP: ffff880037fd7018 R08: 0000000080808081
R09: 0000000000000000
Mar  3 11:42:34 vdr kernel: [ 3291.919013] R10: 0000000000000000 R11: ffffffffa02812a0
R12: ffff880037fd7020
Mar  3 11:42:34 vdr kernel: [ 3291.919013] R13: 0000000000000000 R14: 0000000000000001
R15: ffff88003fb98888
Mar  3 11:42:34 vdr kernel: [ 3291.919013] FS:  00007f2def23b6f0(0000)
GS:ffff880001800000(0000) knlGS:0000000000000000
Mar  3 11:42:34 vdr kernel: [ 3291.919013] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Mar  3 11:42:34 vdr kernel: [ 3291.919013] CR2: 0000000000000000 CR3: 0000000037abd000
CR4: 00000000000006f0
Mar  3 11:42:34 vdr kernel: [ 3291.919013] DR0: 0000000000000000 DR1: 0000000000000000
DR2: 0000000000000000
Mar  3 11:42:34 vdr kernel: [ 3291.919013] DR3: 0000000000000000 DR6: 00000000ffff0ff0
DR7: 0000000000000400
Mar  3 11:42:34 vdr kernel: [ 3291.919013] Process rmmod (pid: 15305, threadinfo
ffff88003da54000, task ffff880009830080)
Mar  3 11:42:34 vdr kernel: [ 3291.919013] Stack:
Mar  3 11:42:34 vdr kernel: [ 3291.919013]  ffff88003edc0108 ffff880037fd7000
ffff88003db47000 ffffffffa0396ca5
Mar  3 11:42:34 vdr kernel: [ 3291.919013] <0> ffffffffa03df158 ffff88003edc0108
ffff880037fd7118 ffff880037fd7000
Mar  3 11:42:34 vdr kernel: [ 3291.919013] <0> ffffffffa03df158 0000000000000001
ffff88003fb98888 ffffffffa03cb2c5
Mar  3 11:42:34 vdr kernel: [ 3291.919013] Call Trace:
Mar  3 11:42:34 vdr kernel: [ 3291.919013]  [<ffffffffa0396ca5>] ?
saa7146_vv_release+0x45/0x140 [saa7146_vv]
Mar  3 11:42:34 vdr kernel: [ 3291.919013]  [<ffffffffa03cb2c5>] ?
av7110_exit_v4l+0x45/0x60 [dvb_ttpci]
Mar  3 11:42:34 vdr kernel: [ 3291.919013]  [<ffffffffa03d9748>] ?
av7110_detach+0x138/0x2a0 [dvb_ttpci]
Mar  3 11:42:34 vdr kernel: [ 3291.919013]  [<ffffffffa02dd322>] ?
saa7146_remove_one+0xb2/0x230 [saa7146]
Mar  3 11:42:34 vdr kernel: [ 3291.919013]  [<ffffffff811dd37f>] ? pci_device_remove+0x2f/0x60
Mar  3 11:42:34 vdr kernel: [ 3291.919013]  [<ffffffff81270c88>] ?
__device_release_driver+0x78/0xf0
Mar  3 11:42:34 vdr kernel: [ 3291.919013]  [<ffffffff81270db0>] ? driver_detach+0xb0/0xc0
Mar  3 11:42:34 vdr kernel: [ 3291.919013]  [<ffffffff8126fca4>] ? bus_remove_driver+0x84/0xe0
Mar  3 11:42:34 vdr kernel: [ 3291.919013]  [<ffffffff811dd69f>] ?
pci_unregister_driver+0x3f/0xc0
Mar  3 11:42:34 vdr kernel: [ 3291.919013]  [<ffffffffa02dd1a7>] ?
saa7146_unregister_extension+0x27/0x60 [saa7146]
Mar  3 11:42:34 vdr kernel: [ 3291.919013]  [<ffffffff81084db6>] ?
sys_delete_module+0x1f6/0x2d0
Mar  3 11:42:34 vdr kernel: [ 3291.919013]  [<ffffffff81344255>] ?
_raw_spin_unlock_irqrestore+0x15/0x40
Mar  3 11:42:34 vdr kernel: [ 3291.919013]  [<ffffffff81002e6b>] ?
system_call_fastpath+0x16/0x1b
Mar  3 11:42:34 vdr kernel: [ 3291.919013] Code: fe e0 48 c7 03 00 00 00 00 5b c3 0f 1f 40
00 41 54 48 85 ff 55 48 89 fd 53 74 4a e8 cf ff ff ff 48 8b 5d 08 4c 8d 65 08 4c 39 e3 <
Mar  3 11:42:34 vdr kernel: [ 3291.919013] RIP  [<ffffffffa0286aac>]
v4l2_device_unregister+0x1c/0x60 [videodev]
Mar  3 11:42:34 vdr kernel: [ 3291.919013]  RSP <ffff88003da55cc8>
Mar  3 11:42:34 vdr kernel: [ 3291.919013] CR2: 0000000000000000
Mar  3 11:42:34 vdr kernel: [ 3291.934087] ---[ end trace 685f9ceb9b064f25 ]---
Mar  3 11:42:52 vdr logger: rcvdr: stop
Mar  3 11:43:34 vdr shutdown[5610]: shutting down for system reboot

Re: av7110 and budget_av are broken!

[Hans Verkuil]

On Saturday 20 March 2010 17:03:01 e9hack wrote:
> Am 20.3.2010 15:20, schrieb Hans Verkuil:
> > Hartmut, is the problem with unloading the module something that my patch
> > caused? Or was that there as well before changeset 14351:2eda2bcc8d6f?
> > Are there any kernel messages indicating why it won't unload?
> 
> Changset 14351:2eda2bcc8d6f causes a kernel oops during unload of the module for my dvb
> cards.

OK, I know that. But does the patch I mailed you last time fix this problem
without causing new ones? If so, then I'll post that patch to the list.

Regards,

	Hans

> The call trace points to dvb_ttpci. I assumed, that the FF card is affected only.
> It may be possible, that budget-av does crash also, if it is unload as second.

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG

Re: av7110 and budget_av are broken!

[e9hack]

Am 20.3.2010 22:37, schrieb Hans Verkuil:
> On Saturday 20 March 2010 17:03:01 e9hack wrote:
> OK, I know that. But does the patch I mailed you last time fix this problem
> without causing new ones? If so, then I'll post that patch to the list.

With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my
VDR does start, currently I've no chance to determine which module is load first, but it
works. If I unload all modules and load it again, I've no problem. In this case, the
modules for the budget card is load first and the modules for the FF loads as second one.

Regards,
Hartmut

Re: av7110 and budget_av are broken!

[e9hack]

Am 22.3.2010 20:34, schrieb e9hack:
> Am 20.3.2010 22:37, schrieb Hans Verkuil:
>> On Saturday 20 March 2010 17:03:01 e9hack wrote:
>> OK, I know that. But does the patch I mailed you last time fix this problem
>> without causing new ones? If so, then I'll post that patch to the list.
> 
> With your last patch, I've no problems. I'm using a a TT-C2300 and a Budget card. If my
> VDR does start, currently I've no chance to determine which module is load first, but it
> works. If I unload all modules and load it again, I've no problem. In this case, the
> modules for the budget card is load first and the modules for the FF loads as second one.

Ping!!!!!!

Re: av7110 and budget_av are broken!

[Hans Verkuil]

> Am 22.3.2010 20:34, schrieb e9hack:
>> Am 20.3.2010 22:37, schrieb Hans Verkuil:
>>> On Saturday 20 March 2010 17:03:01 e9hack wrote:
>>> OK, I know that. But does the patch I mailed you last time fix this
>>> problem
>>> without causing new ones? If so, then I'll post that patch to the list.
>>
>> With your last patch, I've no problems. I'm using a a TT-C2300 and a
>> Budget card. If my
>> VDR does start, currently I've no chance to determine which module is
>> load first, but it
>> works. If I unload all modules and load it again, I've no problem. In
>> this case, the
>> modules for the budget card is load first and the modules for the FF
>> loads as second one.
>
> Ping!!!!!!

It's merged in Mauro's fixes tree, but I don't think those pending patches
have been pushed upstream yet. Mauro, can you verify this? They should be
pushed to 2.6.34!

Regards,

        Hans 'still stuck in San Francisco' Verkuil

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

Re: av7110 and budget_av are broken!

[Oliver Endriss]

On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote:
> > Am 22.3.2010 20:34, schrieb e9hack:
> >> Am 20.3.2010 22:37, schrieb Hans Verkuil:
> >>> On Saturday 20 March 2010 17:03:01 e9hack wrote:
> >>> OK, I know that. But does the patch I mailed you last time fix this
> >>> problem
> >>> without causing new ones? If so, then I'll post that patch to the list.
> >>
> >> With your last patch, I've no problems. I'm using a a TT-C2300 and a
> >> Budget card. If my
> >> VDR does start, currently I've no chance to determine which module is
> >> load first, but it
> >> works. If I unload all modules and load it again, I've no problem. In
> >> this case, the
> >> modules for the budget card is load first and the modules for the FF
> >> loads as second one.
> >
> > Ping!!!!!!
>
> It's merged in Mauro's fixes tree, but I don't think those pending patches
> have been pushed upstream yet. Mauro, can you verify this? They should be
> pushed to 2.6.34!

What about the HG driver?
The v4l-dvb HG repository is broken for 7 weeks...

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: av7110 and budget_av are broken!

[VDR User]

On Wed, Apr 21, 2010 at 2:44 AM, Oliver Endriss <o.endriss@gmx.de> wrote:
>> It's merged in Mauro's fixes tree, but I don't think those pending patches
>> have been pushed upstream yet. Mauro, can you verify this? They should be
>> pushed to 2.6.34!
>
> What about the HG driver?
> The v4l-dvb HG repository is broken for 7 weeks...

It doesn't make any sense why someone would break a driver and then
leave it that way for such a long period of time.  Yes, please fix the
HG repository.  I don't actually know anyone who bothers with the git
tree for obvious reasons, but a whole mess of users continue, of
course, to use the mercurial tree...

Re: av7110 and budget_av are broken!

[Mauro Carvalho Chehab]

VDR User wrote:
> On Wed, Apr 21, 2010 at 2:44 AM, Oliver Endriss <o.endriss@gmx.de> wrote:
>>> It's merged in Mauro's fixes tree, but I don't think those pending patches
>>> have been pushed upstream yet. Mauro, can you verify this? They should be
>>> pushed to 2.6.34!
>> What about the HG driver?
>> The v4l-dvb HG repository is broken for 7 weeks...
> 
> It doesn't make any sense why someone would break a driver and then
> leave it that way for such a long period of time.  Yes, please fix the
> HG repository. 

You need to ask Douglas about -hg issues. He is the actual maintainer of that tree.
It is probably a good idea to merge also from fixes.git tree, but this may make
his sync process more complicated, so, it is up to him to decide how to do it.

I still thinking on having a better way to have those fixes patches merged earlier
on -git, but I'll need to have some time to do some scripting and test some things.

> I don't actually know anyone who bothers with the git
> tree for obvious reasons

About half of the developers are submitting git requests, so it seems that
there are people using it.

-- 

Cheers,
Mauro

Re: av7110 and budget_av are broken!

[VDR User]

On Mon, Apr 26, 2010 at 6:35 AM, Mauro Carvalho Chehab
<mchehab@infradead.org> wrote:
> You need to ask Douglas about -hg issues. He is the actual maintainer of that tree.
> It is probably a good idea to merge also from fixes.git tree, but this may make
> his sync process more complicated, so, it is up to him to decide how to do it.
>
> I still thinking on having a better way to have those fixes patches merged earlier
> on -git, but I'll need to have some time to do some scripting and test some things.

I think any progress to keep these trees in better sync is a good idea.

>> I don't actually know anyone who bothers with the git
>> tree for obvious reasons
>
> About half of the developers are submitting git requests, so it seems that
> there are people using it.

I'd expect that a portion of developers prefer git, but I was
referring to end-users -- the guys who do the majority of testing imo.
 I don't know any end-users with any intention of using the git tree.
Actually, there are quite a few who stopped updating their hg tree and
prefer to use older known working drivers because of the sync
problems/broken drivers not being fixed.  From a developer standpoint
it may be decent but to an end-user it's just turned into a big mess.
Oh well, who needs all those testers anyways? ;)

Cheers

Re: av7110 and budget_av are broken!

[Oliver Endriss]

On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote:
> On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote:
> > > Am 22.3.2010 20:34, schrieb e9hack:
> > >> Am 20.3.2010 22:37, schrieb Hans Verkuil:
> > >>> On Saturday 20 March 2010 17:03:01 e9hack wrote:
> > >>> OK, I know that. But does the patch I mailed you last time fix this
> > >>> problem
> > >>> without causing new ones? If so, then I'll post that patch to the list.
> > >>
> > >> With your last patch, I've no problems. I'm using a a TT-C2300 and a
> > >> Budget card. If my
> > >> VDR does start, currently I've no chance to determine which module is
> > >> load first, but it
> > >> works. If I unload all modules and load it again, I've no problem. In
> > >> this case, the
> > >> modules for the budget card is load first and the modules for the FF
> > >> loads as second one.
> > >
> > > Ping!!!!!!
> >
> > It's merged in Mauro's fixes tree, but I don't think those pending patches
> > have been pushed upstream yet. Mauro, can you verify this? They should be
> > pushed to 2.6.34!
> 
> What about the HG driver?
> The v4l-dvb HG repository is broken for 7 weeks...

Hi guys,

we have May 16th, and the HG driver is broken for 10 weeks now!

History:
- The changeset which caused the mess was applied on March 2nd:
  http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f

- A fix is waiting at fixes.git since March 24th:
  http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73

Are there any plans to bring v4ldvb HG to an usable state?

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: av7110 and budget_av are broken!

[Douglas Schilling Landgraf]

Hello Oliver,

On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss <o.endriss@gmx.de> wrote:
> On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote:
>> On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote:
>> > > Am 22.3.2010 20:34, schrieb e9hack:
>> > >> Am 20.3.2010 22:37, schrieb Hans Verkuil:
>> > >>> On Saturday 20 March 2010 17:03:01 e9hack wrote:
>> > >>> OK, I know that. But does the patch I mailed you last time fix this
>> > >>> problem
>> > >>> without causing new ones? If so, then I'll post that patch to the list.
>> > >>
>> > >> With your last patch, I've no problems. I'm using a a TT-C2300 and a
>> > >> Budget card. If my
>> > >> VDR does start, currently I've no chance to determine which module is
>> > >> load first, but it
>> > >> works. If I unload all modules and load it again, I've no problem. In
>> > >> this case, the
>> > >> modules for the budget card is load first and the modules for the FF
>> > >> loads as second one.
>> > >
>> > > Ping!!!!!!
>> >
>> > It's merged in Mauro's fixes tree, but I don't think those pending patches
>> > have been pushed upstream yet. Mauro, can you verify this? They should be
>> > pushed to 2.6.34!
>>
>> What about the HG driver?
>> The v4l-dvb HG repository is broken for 7 weeks...
>
> Hi guys,
>
> we have May 16th, and the HG driver is broken for 10 weeks now!
>
> History:
> - The changeset which caused the mess was applied on March 2nd:
>  http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f
>
> - A fix is waiting at fixes.git since March 24th:
>  http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73
>
> Are there any plans to bring v4ldvb HG to an usable state?

Yes, Now I will collect patches from devel and fixes tree. At least
until we achieve a better approach on it.
Sorry the delay.

Sounds good? Any other suggestion?

Let me work on it.

Cheers
Douglas

Re: av7110 and budget_av are broken!

[hermann pitton]

Am Samstag, den 15.05.2010, 22:33 -0300 schrieb Douglas Schilling
Landgraf:
> Hello Oliver,
> 
> On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss <o.endriss@gmx.de> wrote:
> > On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote:
> >> On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote:
> >> > > Am 22.3.2010 20:34, schrieb e9hack:
> >> > >> Am 20.3.2010 22:37, schrieb Hans Verkuil:
> >> > >>> On Saturday 20 March 2010 17:03:01 e9hack wrote:
> >> > >>> OK, I know that. But does the patch I mailed you last time fix this
> >> > >>> problem
> >> > >>> without causing new ones? If so, then I'll post that patch to the list.
> >> > >>
> >> > >> With your last patch, I've no problems. I'm using a a TT-C2300 and a
> >> > >> Budget card. If my
> >> > >> VDR does start, currently I've no chance to determine which module is
> >> > >> load first, but it
> >> > >> works. If I unload all modules and load it again, I've no problem. In
> >> > >> this case, the
> >> > >> modules for the budget card is load first and the modules for the FF
> >> > >> loads as second one.
> >> > >
> >> > > Ping!!!!!!
> >> >
> >> > It's merged in Mauro's fixes tree, but I don't think those pending patches
> >> > have been pushed upstream yet. Mauro, can you verify this? They should be
> >> > pushed to 2.6.34!
> >>
> >> What about the HG driver?
> >> The v4l-dvb HG repository is broken for 7 weeks...
> >
> > Hi guys,
> >
> > we have May 16th, and the HG driver is broken for 10 weeks now!
> >
> > History:
> > - The changeset which caused the mess was applied on March 2nd:
> >  http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f
> >
> > - A fix is waiting at fixes.git since March 24th:
> >  http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73
> >
> > Are there any plans to bring v4ldvb HG to an usable state?
> 
> Yes, Now I will collect patches from devel and fixes tree. At least
> until we achieve a better approach on it.
> Sorry the delay.
> 
> Sounds good? Any other suggestion?
> 
> Let me work on it.
> 
> Cheers
> Douglas


Hi, Douglas and Oliver,

just as a small comment.

I have not been on latest rc1 and such rcs close to a release for some
time.

But I was for a long time and v4l-dvb can't be a substitute for such.

Despite of getting more users for testing, on _that_ front does not
happen such much currently, keeping v4l-dvb is mostly a service for
developers this time.

So, contributing on the backports and helping Douglas with such is
really welcome.

Cheers,
Hermann

Re: av7110 and budget_av are broken!

[Oliver Endriss]

On Sunday 16 May 2010 03:53:48 hermann pitton wrote:
> 
> Am Samstag, den 15.05.2010, 22:33 -0300 schrieb Douglas Schilling
> Landgraf:
> > Hello Oliver,
> > 
> > On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss <o.endriss@gmx.de> wrote:
> > > On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote:
> > >> On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote:
> > >> > > Am 22.3.2010 20:34, schrieb e9hack:
> > >> > >> Am 20.3.2010 22:37, schrieb Hans Verkuil:
> > >> > >>> On Saturday 20 March 2010 17:03:01 e9hack wrote:
> > >> > >>> OK, I know that. But does the patch I mailed you last time fix this
> > >> > >>> problem
> > >> > >>> without causing new ones? If so, then I'll post that patch to the list.
> > >> > >>
> > >> > >> With your last patch, I've no problems. I'm using a a TT-C2300 and a
> > >> > >> Budget card. If my
> > >> > >> VDR does start, currently I've no chance to determine which module is
> > >> > >> load first, but it
> > >> > >> works. If I unload all modules and load it again, I've no problem. In
> > >> > >> this case, the
> > >> > >> modules for the budget card is load first and the modules for the FF
> > >> > >> loads as second one.
> > >> > >
> > >> > > Ping!!!!!!
> > >> >
> > >> > It's merged in Mauro's fixes tree, but I don't think those pending patches
> > >> > have been pushed upstream yet. Mauro, can you verify this? They should be
> > >> > pushed to 2.6.34!
> > >>
> > >> What about the HG driver?
> > >> The v4l-dvb HG repository is broken for 7 weeks...
> > >
> > > Hi guys,
> > >
> > > we have May 16th, and the HG driver is broken for 10 weeks now!
> > >
> > > History:
> > > - The changeset which caused the mess was applied on March 2nd:
> > >  http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f
> > >
> > > - A fix is waiting at fixes.git since March 24th:
> > >  http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73
> > >
> > > Are there any plans to bring v4ldvb HG to an usable state?
> > 
> > Yes, Now I will collect patches from devel and fixes tree. At least
> > until we achieve a better approach on it.
> > Sorry the delay.
> > 
> > Sounds good? Any other suggestion?
> > 
> > Let me work on it.
> > 
> > Cheers
> > Douglas
> 
> 
> Hi, Douglas and Oliver,
> 
> just as a small comment.
> 
> I have not been on latest rc1 and such rcs close to a release for some
> time.
>
> But I was for a long time and v4l-dvb can't be a substitute for such.

Sorry, I do not want to cope with experimental kernels and their bugs on
my systems. I need a stable and reliable platform, so that I can
concentrate on 'my' bugs.

Usually I update the kernel every 3..4 releases (which causes enough
trouble due to changed features, interfaces etc).

> Despite of getting more users for testing, on _that_ front does not
> happen such much currently, keeping v4l-dvb is mostly a service for
> developers this time.
> 
> So, contributing on the backports and helping Douglas with such is
> really welcome.

I confess that I do not know much about the tree handling procedures of
the kernel. Imho it sounds crazy to have separate 'fixes' and
'development' trees.

A developer's tree (no matter whether HG or GIT) must also include the
fixes, otherwise it is unusable. You cannot wait until applied fixes
flow back from the kernel.

Btw, the v4ldvb HG repositories contain tons of disabled code (marked
'#if 0'), which was stripped for submission to the kernel.
Even if we would switch to GIT completely, we need a separate GIT
repository which would hold the original code.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: av7110 and budget_av are broken!

[Mauro Carvalho Chehab]

Oliver Endriss wrote:
> On Sunday 16 May 2010 03:53:48 hermann pitton wrote:
>> Am Samstag, den 15.05.2010, 22:33 -0300 schrieb Douglas Schilling
>> Landgraf:
>>> Hello Oliver,
>>>
>>> On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss <o.endriss@gmx.de> wrote:
>>>> On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote:
>>>>> On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote:
>>>>>>> Am 22.3.2010 20:34, schrieb e9hack:
>>>>>>>> Am 20.3.2010 22:37, schrieb Hans Verkuil:
>>>>>>>>> On Saturday 20 March 2010 17:03:01 e9hack wrote:
>>>>>>>>> OK, I know that. But does the patch I mailed you last time fix this
>>>>>>>>> problem
>>>>>>>>> without causing new ones? If so, then I'll post that patch to the list.
>>>>>>>> With your last patch, I've no problems. I'm using a a TT-C2300 and a
>>>>>>>> Budget card. If my
>>>>>>>> VDR does start, currently I've no chance to determine which module is
>>>>>>>> load first, but it
>>>>>>>> works. If I unload all modules and load it again, I've no problem. In
>>>>>>>> this case, the
>>>>>>>> modules for the budget card is load first and the modules for the FF
>>>>>>>> loads as second one.
>>>>>>> Ping!!!!!!
>>>>>> It's merged in Mauro's fixes tree, but I don't think those pending patches
>>>>>> have been pushed upstream yet. Mauro, can you verify this? They should be
>>>>>> pushed to 2.6.34!
>>>>> What about the HG driver?
>>>>> The v4l-dvb HG repository is broken for 7 weeks...
>>>> Hi guys,
>>>>
>>>> we have May 16th, and the HG driver is broken for 10 weeks now!
>>>>
>>>> History:
>>>> - The changeset which caused the mess was applied on March 2nd:
>>>>  http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f
>>>>
>>>> - A fix is waiting at fixes.git since March 24th:
>>>>  http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73
>>>>
>>>> Are there any plans to bring v4ldvb HG to an usable state?
>>> Yes, Now I will collect patches from devel and fixes tree. At least
>>> until we achieve a better approach on it.
>>> Sorry the delay.
>>>
>>> Sounds good? Any other suggestion?
>>>
>>> Let me work on it.
>>>
>>> Cheers
>>> Douglas
>>
>> Hi, Douglas and Oliver,
>>
>> just as a small comment.
>>
>> I have not been on latest rc1 and such rcs close to a release for some
>> time.
>>
>> But I was for a long time and v4l-dvb can't be a substitute for such.
> 
> Sorry, I do not want to cope with experimental kernels and their bugs on
> my systems. I need a stable and reliable platform, so that I can
> concentrate on 'my' bugs.
> 
> Usually I update the kernel every 3..4 releases (which causes enough
> trouble due to changed features, interfaces etc).

I used to do it, but, in fact updating every release and following stable
worked better for me, since there are less changes at the features, making
easier to compile a new kernel that won't break anything.

Anyway, it is up to you to use whatever works better for you.

> 
>> Despite of getting more users for testing, on _that_ front does not
>> happen such much currently, keeping v4l-dvb is mostly a service for
>> developers this time.
>>
>> So, contributing on the backports and helping Douglas with such is
>> really welcome.
> 
> I confess that I do not know much about the tree handling procedures of
> the kernel. Imho it sounds crazy to have separate 'fixes' and
> 'development' trees.

I'll change the procedures for 2.6.35. I'll basically opt for having
topic branches (for example, having a "ngene" branch), where all ngene patches
will be applied, updating "master" only after having those patches in kernel.
I'll likely create a stable branch, with the latest kernel, plus all patches
(like v2.6.34-v4l-dvb), to help people that want to develop using git.

The big problem when handling patches upstream is caused by rebasing a patch,
and the higher number of patches in a tree, the higher is the probability that
a rebase will needed to avoid breaking compilation on a bisect.

To give you an example, one big series of patches moved slab.h into each 
driver that uses malloc. If a new driver or c file that needs this include
on our series were added, to avoid breaking bisect, we need to go to the patch
that introduced this code, and add the include there. All patches after this
one needs to be rebased, when submitting upstream.

So, let's say that the original patch has 05a43 has, and the new patch has
a0342 (fictional numbers).

So, in the development branches, this patch is known as 05a43, where, on
upstream, this patch will be known as a0342.

If I rebase the development tree, all developers using git would need to rebase
their trees. If I don't rebase, after merging from upstream, this patch will
appear 2 times at the master branch history: as 05a43 and as a0342. To be worse,
on the next time I need to send patches upstream, this patch will appear again
on my pile of patches to be submitted, and I'll need to manually drop it.
Due to 2.6.33 merge, this problem is already present on our master branch. So,
I'll need to drop a big pile of patches on my next upstream pull request.
At each new kernel release, things would become worse.

With topic branches, things will hopefully become easier, as people can base their
trees on a topic branch. Also, we may have some topic branches based on a stable
release, and others based on upstream, but it will require me to maintain separate
development branches with all merging patches per kernel release.

> 
> A developer's tree (no matter whether HG or GIT) must also include the
> fixes, otherwise it is unusable. You cannot wait until applied fixes
> flow back from the kernel.
> 
> Btw, the v4ldvb HG repositories contain tons of disabled code (marked
> '#if 0'), which was stripped for submission to the kernel.
> Even if we would switch to GIT completely, we need a separate GIT
> repository which would hold the original code.

This is due to a policy we had at -hg time: not pollute upstream with
dead code garbage. Maybe we may have a topic branch with all those dead code, 
but I think that, before adding those code on kernel, we need to review what 
will be added there: there are _lots_ of such #if 0 code that is there for 
years and were never touched (in a matter of fact, this is the typical
case). It seems valuable to do a cleanup first, at -hg, removing the ones that
are there for ages and that nobody is interested on working it, and just
drop at -hg. It will still be there forever, at -hg history, but the source
files will be cleaner without those useless code.

In the specific case of ngene, where stoth and devin are working to enable most
of those dead code, I'll seek for an approach that will add those #if 0 code
before applying the patches that will fix that code, in order to have a better
history at -git, when they submit their next pull request.


-- 

Cheers,
Mauro

Re: av7110 and budget_av are broken!

[Oliver Endriss]

On Sunday 16 May 2010 14:57:18 Mauro Carvalho Chehab wrote:
> Oliver Endriss wrote:
> > On Sunday 16 May 2010 03:53:48 hermann pitton wrote:
> >> Hi, Douglas and Oliver,
> >>
> >> just as a small comment.
> >>
> >> I have not been on latest rc1 and such rcs close to a release for some
> >> time.
> >>
> >> But I was for a long time and v4l-dvb can't be a substitute for such.
> > 
> > Sorry, I do not want to cope with experimental kernels and their bugs on
> > my systems. I need a stable and reliable platform, so that I can
> > concentrate on 'my' bugs.
> > 
> > Usually I update the kernel every 3..4 releases (which causes enough
> > trouble due to changed features, interfaces etc).
> 
> I used to do it, but, in fact updating every release and following stable
> worked better for me, since there are less changes at the features, making
> easier to compile a new kernel that won't break anything.
> 
> Anyway, it is up to you to use whatever works better for you.

Well, the problem is bug hunting: If you have changes both in the kernel
and in the driver, it is harder to identify the problem...

> >> Despite of getting more users for testing, on _that_ front does not
> >> happen such much currently, keeping v4l-dvb is mostly a service for
> >> developers this time.
> >>
> >> So, contributing on the backports and helping Douglas with such is
> >> really welcome.
> > 
> > I confess that I do not know much about the tree handling procedures of
> > the kernel. Imho it sounds crazy to have separate 'fixes' and
> > 'development' trees.
> 
> I'll change the procedures for 2.6.35. I'll basically opt for having
> topic branches (for example, having a "ngene" branch), where all ngene patches
> will be applied, updating "master" only after having those patches in kernel.

How do you handle patches for shared components (frontend drivers,
dvb-core etc)? With topic branches, you have to apply those to every
topic branch which depends on them.

> I'll likely create a stable branch, with the latest kernel, plus all patches
> (like v2.6.34-v4l-dvb), to help people that want to develop using git.
> 
> The big problem when handling patches upstream is caused by rebasing a patch,
> and the higher number of patches in a tree, the higher is the probability that
> a rebase will needed to avoid breaking compilation on a bisect.
> 
> To give you an example, one big series of patches moved slab.h into each 
> driver that uses malloc. If a new driver or c file that needs this include
> on our series were added, to avoid breaking bisect, we need to go to the patch
> that introduced this code, and add the include there. All patches after this
> one needs to be rebased, when submitting upstream.

I would rather break bisect than doing that. In this example one could
simply disable the new driver in menuconfig to avoid the problem.

> So, let's say that the original patch has 05a43 has, and the new patch has
> a0342 (fictional numbers).
> 
> So, in the development branches, this patch is known as 05a43, where, on
> upstream, this patch will be known as a0342.
> 
> If I rebase the development tree, all developers using git would need to rebase
> their trees. If I don't rebase, after merging from upstream, this patch will
> appear 2 times at the master branch history: as 05a43 and as a0342. To be worse,
> on the next time I need to send patches upstream, this patch will appear again
> on my pile of patches to be submitted, and I'll need to manually drop it.
> Due to 2.6.33 merge, this problem is already present on our master branch. So,
> I'll need to drop a big pile of patches on my next upstream pull request.
> At each new kernel release, things would become worse.

Hm. Imho tree handling is getting way too complicated. ;-(

> With topic branches, things will hopefully become easier, as people can base their
> trees on a topic branch. Also, we may have some topic branches based on a stable
> release, and others based on upstream, but it will require me to maintain separate
> development branches with all merging patches per kernel release.

See above. I doubt that it will make things really easier.

> > A developer's tree (no matter whether HG or GIT) must also include the
> > fixes, otherwise it is unusable. You cannot wait until applied fixes
> > flow back from the kernel.
> > 
> > Btw, the v4ldvb HG repositories contain tons of disabled code (marked
> > '#if 0'), which was stripped for submission to the kernel.
> > Even if we would switch to GIT completely, we need a separate GIT
> > repository which would hold the original code.
> 
> This is due to a policy we had at -hg time: not pollute upstream with
> dead code garbage. Maybe we may have a topic branch with all those dead code, 
> but I think that, before adding those code on kernel, we need to review what 
> will be added there: there are _lots_ of such #if 0 code that is there for 
> years and were never touched (in a matter of fact, this is the typical
> case). It seems valuable to do a cleanup first, at -hg, removing the ones that
> are there for ages and that nobody is interested on working it, and just
> drop at -hg. It will still be there forever, at -hg history, but the source
> files will be cleaner without those useless code.

I agree that dead code should be identified and removed, but debug stuff
must be preserved. After 2 years nobody remembers that this stuff did
ever exist. So the history will not be checked...

Furthermore, if HG will be dropped some time in the future, history and
corresponding code might be lost.

> In the specific case of ngene, where stoth and devin are working to enable most
> of those dead code, I'll seek for an approach that will add those #if 0 code
> before applying the patches that will fix that code, in order to have a better
> history at -git, when they submit their next pull request.

ngene is a very new driver. New features and cards are still being added.
So it is handy to have the '#if 0's in the development tree.
When the driver has settled, the code should be cleaned-up.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: av7110 and budget_av are broken!

[Mauro Carvalho Chehab]

Oliver Endriss wrote:
> On Sunday 16 May 2010 14:57:18 Mauro Carvalho Chehab wrote:
>> Oliver Endriss wrote:
>>> On Sunday 16 May 2010 03:53:48 hermann pitton wrote:
>>>> Hi, Douglas and Oliver,
>>>>
>>>> just as a small comment.
>>>>
>>>> I have not been on latest rc1 and such rcs close to a release for some
>>>> time.
>>>>
>>>> But I was for a long time and v4l-dvb can't be a substitute for such.
>>> Sorry, I do not want to cope with experimental kernels and their bugs on
>>> my systems. I need a stable and reliable platform, so that I can
>>> concentrate on 'my' bugs.
>>>
>>> Usually I update the kernel every 3..4 releases (which causes enough
>>> trouble due to changed features, interfaces etc).
>> I used to do it, but, in fact updating every release and following stable
>> worked better for me, since there are less changes at the features, making
>> easier to compile a new kernel that won't break anything.
>>
>> Anyway, it is up to you to use whatever works better for you.
> 
> Well, the problem is bug hunting: If you have changes both in the kernel
> and in the driver, it is harder to identify the problem...

True, but if you're using an older kernel version, you can miss some bugs that
appeared because of some changes that happened upstream.
> 
>>>> Despite of getting more users for testing, on _that_ front does not
>>>> happen such much currently, keeping v4l-dvb is mostly a service for
>>>> developers this time.
>>>>
>>>> So, contributing on the backports and helping Douglas with such is
>>>> really welcome.
>>> I confess that I do not know much about the tree handling procedures of
>>> the kernel. Imho it sounds crazy to have separate 'fixes' and
>>> 'development' trees.
>> I'll change the procedures for 2.6.35. I'll basically opt for having
>> topic branches (for example, having a "ngene" branch), where all ngene patches
>> will be applied, updating "master" only after having those patches in kernel.
> 
> How do you handle patches for shared components (frontend drivers,
> dvb-core etc)? With topic branches, you have to apply those to every
> topic branch which depends on them.

Yes. x86 is using topic branches and it is working there. So, I'm expecting that
the same kind of procedure could work for us.

>> I'll likely create a stable branch, with the latest kernel, plus all patches
>> (like v2.6.34-v4l-dvb), to help people that want to develop using git.
>>
>> The big problem when handling patches upstream is caused by rebasing a patch,
>> and the higher number of patches in a tree, the higher is the probability that
>> a rebase will needed to avoid breaking compilation on a bisect.
>>
>> To give you an example, one big series of patches moved slab.h into each 
>> driver that uses malloc. If a new driver or c file that needs this include
>> on our series were added, to avoid breaking bisect, we need to go to the patch
>> that introduced this code, and add the include there. All patches after this
>> one needs to be rebased, when submitting upstream.
> 
> I would rather break bisect than doing that. In this example one could
> simply disable the new driver in menuconfig to avoid the problem.

If it is a new driver, we can do that, but even moving a patch at the patch series
or changing an unrelated patch will change the md5sum for the entire series.

Disabling bisect hurts not only us, when seeking for a bug, but any other developer/user
that is seeking for what patch broke for him. From one kernel version to the next one,
dozens of thousands of patches are applied. With bisect, a broken patch can be identified
with about 10 compilations, while, without bisect, you'll need to seek the entire patch 
series.

So, it is not an option to break bisect.
 
>> So, let's say that the original patch has 05a43 has, and the new patch has
>> a0342 (fictional numbers).
>>
>> So, in the development branches, this patch is known as 05a43, where, on
>> upstream, this patch will be known as a0342.
>>
>> If I rebase the development tree, all developers using git would need to rebase
>> their trees. If I don't rebase, after merging from upstream, this patch will
>> appear 2 times at the master branch history: as 05a43 and as a0342. To be worse,
>> on the next time I need to send patches upstream, this patch will appear again
>> on my pile of patches to be submitted, and I'll need to manually drop it.
>> Due to 2.6.33 merge, this problem is already present on our master branch. So,
>> I'll need to drop a big pile of patches on my next upstream pull request.
>> At each new kernel release, things would become worse.
> 
> Hm. Imho tree handling is getting way too complicated. ;-(

It were always complex, but as we're having much more conflicts with SoC patches, and
a much higher number of patches, the old process, where I was fixing the conflicts myself 
only when sending stuff upstream, weren't working anymore, as the number of troubles
were exponentially increasing with a linear grouth of the number of patches.

Anyway, I'm open to suggestions to improve the process.

>> With topic branches, things will hopefully become easier, as people can base their
>> trees on a topic branch. Also, we may have some topic branches based on a stable
>> release, and others based on upstream, but it will require me to maintain separate
>> development branches with all merging patches per kernel release.
> 
> See above. I doubt that it will make things really easier.
> 
>>> A developer's tree (no matter whether HG or GIT) must also include the
>>> fixes, otherwise it is unusable. You cannot wait until applied fixes
>>> flow back from the kernel.
>>>
>>> Btw, the v4ldvb HG repositories contain tons of disabled code (marked
>>> '#if 0'), which was stripped for submission to the kernel.
>>> Even if we would switch to GIT completely, we need a separate GIT
>>> repository which would hold the original code.
>> This is due to a policy we had at -hg time: not pollute upstream with
>> dead code garbage. Maybe we may have a topic branch with all those dead code, 
>> but I think that, before adding those code on kernel, we need to review what 
>> will be added there: there are _lots_ of such #if 0 code that is there for 
>> years and were never touched (in a matter of fact, this is the typical
>> case). It seems valuable to do a cleanup first, at -hg, removing the ones that
>> are there for ages and that nobody is interested on working it, and just
>> drop at -hg. It will still be there forever, at -hg history, but the source
>> files will be cleaner without those useless code.
> 
> I agree that dead code should be identified and removed, but debug stuff
> must be preserved. After 2 years nobody remembers that this stuff did
> ever exist. So the history will not be checked...
> 
> Furthermore, if HG will be dropped some time in the future, history and
> corresponding code might be lost.

Makes sense.

>> In the specific case of ngene, where stoth and devin are working to enable most
>> of those dead code, I'll seek for an approach that will add those #if 0 code
>> before applying the patches that will fix that code, in order to have a better
>> history at -git, when they submit their next pull request.
> 
> ngene is a very new driver. New features and cards are still being added.
> So it is handy to have the '#if 0's in the development tree.
> When the driver has settled, the code should be cleaned-up.

Agreed.

-- 

Cheers,
Mauro

Re: av7110 and budget_av are broken!

[hermann pitton]

Hi,

Am Sonntag, den 16.05.2010, 06:21 +0200 schrieb Oliver Endriss:
> On Sunday 16 May 2010 03:53:48 hermann pitton wrote:
> > 
> > Am Samstag, den 15.05.2010, 22:33 -0300 schrieb Douglas Schilling
> > Landgraf:
> > > Hello Oliver,
> > > 
> > > On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss <o.endriss@gmx.de> wrote:
> > > > On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote:
> > > >> On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote:
> > > >> > > Am 22.3.2010 20:34, schrieb e9hack:
> > > >> > >> Am 20.3.2010 22:37, schrieb Hans Verkuil:
> > > >> > >>> On Saturday 20 March 2010 17:03:01 e9hack wrote:
> > > >> > >>> OK, I know that. But does the patch I mailed you last time fix this
> > > >> > >>> problem
> > > >> > >>> without causing new ones? If so, then I'll post that patch to the list.
> > > >> > >>
> > > >> > >> With your last patch, I've no problems. I'm using a a TT-C2300 and a
> > > >> > >> Budget card. If my
> > > >> > >> VDR does start, currently I've no chance to determine which module is
> > > >> > >> load first, but it
> > > >> > >> works. If I unload all modules and load it again, I've no problem. In
> > > >> > >> this case, the
> > > >> > >> modules for the budget card is load first and the modules for the FF
> > > >> > >> loads as second one.
> > > >> > >
> > > >> > > Ping!!!!!!
> > > >> >
> > > >> > It's merged in Mauro's fixes tree, but I don't think those pending patches
> > > >> > have been pushed upstream yet. Mauro, can you verify this? They should be
> > > >> > pushed to 2.6.34!
> > > >>
> > > >> What about the HG driver?
> > > >> The v4l-dvb HG repository is broken for 7 weeks...
> > > >
> > > > Hi guys,
> > > >
> > > > we have May 16th, and the HG driver is broken for 10 weeks now!
> > > >
> > > > History:
> > > > - The changeset which caused the mess was applied on March 2nd:
> > > >  http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f
> > > >
> > > > - A fix is waiting at fixes.git since March 24th:
> > > >  http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73
> > > >
> > > > Are there any plans to bring v4ldvb HG to an usable state?
> > > 
> > > Yes, Now I will collect patches from devel and fixes tree. At least
> > > until we achieve a better approach on it.
> > > Sorry the delay.
> > > 
> > > Sounds good? Any other suggestion?
> > > 
> > > Let me work on it.
> > > 
> > > Cheers
> > > Douglas
> > 
> > 
> > Hi, Douglas and Oliver,
> > 
> > just as a small comment.
> > 
> > I have not been on latest rc1 and such rcs close to a release for some
> > time.
> >
> > But I was for a long time and v4l-dvb can't be a substitute for such.
> 
> Sorry, I do not want to cope with experimental kernels and their bugs on
> my systems. I need a stable and reliable platform, so that I can
> concentrate on 'my' bugs.
> 
> Usually I update the kernel every 3..4 releases (which causes enough
> trouble due to changed features, interfaces etc).

that is what everyone does prefer and that I call subsystem developer
service.

In fact, everyone has to be on .rc stuff starting with .rc1 ;)

Failing on being there, than blaming the one doing the backports for
being in delay, likely without any related hardware in his possession,
that can't work.

Cheers,
Hermann

Re: av7110 and budget_av are broken!

[Douglas Schilling Landgraf]

On Sat, May 15, 2010 at 8:06 PM, Oliver Endriss <o.endriss@gmx.de> wrote:
> On Wednesday 21 April 2010 11:44:16 Oliver Endriss wrote:
>> On Wednesday 21 April 2010 08:37:39 Hans Verkuil wrote:
>> > > Am 22.3.2010 20:34, schrieb e9hack:
>> > >> Am 20.3.2010 22:37, schrieb Hans Verkuil:
>> > >>> On Saturday 20 March 2010 17:03:01 e9hack wrote:
>> > >>> OK, I know that. But does the patch I mailed you last time fix this
>> > >>> problem
>> > >>> without causing new ones? If so, then I'll post that patch to the list.
>> > >>
>> > >> With your last patch, I've no problems. I'm using a a TT-C2300 and a
>> > >> Budget card. If my
>> > >> VDR does start, currently I've no chance to determine which module is
>> > >> load first, but it
>> > >> works. If I unload all modules and load it again, I've no problem. In
>> > >> this case, the
>> > >> modules for the budget card is load first and the modules for the FF
>> > >> loads as second one.
>> > >
>> > > Ping!!!!!!
>> >
>> > It's merged in Mauro's fixes tree, but I don't think those pending patches
>> > have been pushed upstream yet. Mauro, can you verify this? They should be
>> > pushed to 2.6.34!
>>
>> What about the HG driver?
>> The v4l-dvb HG repository is broken for 7 weeks...
>
> Hi guys,
>
> we have May 16th, and the HG driver is broken for 10 weeks now!
>
> History:
> - The changeset which caused the mess was applied on March 2nd:
>  http://linuxtv.org/hg/v4l-dvb/rev/2eda2bcc8d6f
>
> - A fix is waiting at fixes.git since March 24th:
>  http://git.linuxtv.org/fixes.git?a=commitdiff_plain;h=40358c8b5380604ac2507be2fac0c9bbd3e02b73
>
> Are there any plans to bring v4ldvb HG to an usable state?
>

Please hg pull -u, now should include the change that you are looking for.

Cheers
Douglas

Re: av7110 and budget_av are broken!

[Oliver Endriss]

Hi Douglas,

On Sunday 16 May 2010 07:09:21 Douglas Schilling Landgraf wrote:
> Please hg pull -u, now should include the change that you are looking for.

Thanks, now the driver works again. :-)

Regards,
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------