Re: [linux-dvb] [PATCH] Userspace tuner
On 9/13/07, Manu Abraham [EMAIL PROTECTED] wrote: Markus Rechberger wrote: On 9/13/07, Manu Abraham [EMAIL PROTECTED] wrote: It's only a step in development, I do not intend to keep the kernel stub in the end, but I do intend to keep and use the userspace drivers with i2c-dev in the long run, this requires a v4l/dvb library at the front of everything. Well, this was what adq and myself did with libdvbapi and mti, (much before UIO was announced at LK.) It is not tied to I2C either. I2C is the main communication path for it, although there are callback mechanisms available which add the possibility for different configuration paths. Sorry, i must say that what you said is wrong. The example implementation in libdvbapi/mti is I2C only with a STV0299 on the TTPCI, if that was what you meant. But if you need examples for every possible interface, then probably you are out of luck. I didn't comment the libdvbapi/mti driver. I'm quite confident that non I2C protocols can be handled by a callback function. In the end it's either a usb control command or pci mmio writes in the current usual cases and such calls could be handled behind a callback function which is implemented in the driver. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
On 9/13/07, Steven Toth [EMAIL PROTECTED] wrote: Also there is to consider a non technical aspect, whether vendors will misuse this interface for binary only, undermining the efforts put in for OSS drivers. What holds companies for using the current available code putting it into an rpm or deb package and releasing such code now? The Avermedia example I pointed out to is a good example already. As from my side I won't release binary drivers. Although on the other side: * are drivers from vendors which work through several kernel versions that bad? * Why did someone duallicense videodev2 with BSD/GPL? I would appreciate if someone else on the list could also comment the reason that drivers should all be included in the linuxkernel just because forcing the companies to release binary drivers because of that. My opinion about that is if a company wants to go opensource they will do so, if not they will either not release a driver or release nothing. I know for certain that adding a userland API tuner/demod interface to the kernel, allowing non-caring opportunistic silicon or board vendors to developer closed source proprietary drivers, will have a negative effect on the community and we'd set back linuxtv 3-5 years. I know for certain that it would happen. Trust me. I've told you this countless times and you're not hearing me. Hauppauge have some leverage with Conexant and NXP to release public datasheets. If they just have to release a demod.so (or similar) loadable, they'll defer to the board vendors and we'll see the certain board vendors 'locking other board vendors' out of their drivers. We'll see embedded firmware, not shared between drivers. Except, it won't stop at demod.so. It will extend into unfixable bugs for VendorB's board, because VendorA doesn't want to release a new demod.so, and VendorB has no linux resources. What happens next? For financial reasons - demod.so will begin to include checks to see if specific PCI or USB devices are present in the system, and will fail to work properly (if at all) when they're not being used with the preferred products. Steven, what stops vendors of using the current existing code to achieve that goal. They could provide binary drivers with the existing API. What stops companies to intercept the ioctl calls and overriding some I2C commands? Since you know about windows drivers (at least I think that you know about it) you might know about the limitations of the v4l/dvb API in general the reason just put as much code as possible into the kernel just for forcing companies to release code under GPL doesn't seem to be valid. How about proprietary video formats, would you also place the decoding algorithms in kernel just to force companies to release their code for it? What do you think about the existing usbfs implementation, which allows to implement usb drivers completly in userspace? What do you think about IOMMU? please answer those questions. thanks, Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] [PATCH] Userspace tuner
Let's add the LKML to this. On 9/13/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: > On 9/12/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > Markus, > > > > Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu: > > > Following patch adds the possibility to implement tuner drivers in > > > userspace. > > > > As you asked me about userspace driver, at Linux Conf Europe, let me > > give you my feedback about it. > > > > On Linux, userspace-to-kernelspace APIs are meant to be forever. This > > means that, once a newer API is created, this should remain supported > > for all future versions. So, such APIs should be carefully analyzed and > > accepted by the community, before going to mainstream. > > > > The V4L and DVB API is stable at the moment because it's at a stage > which is sufficient for older devices but not sufficient for newer > devices anymore. > To support newer device it needs a change. > > > I don't see any technical reason why tuner drivers should be moved to > > userspace. Looking at xc3028 device, the driver is very simple and > > doesn't require any special treatment that it isn't possible to be done > > at kernel. There are already some implementations on kernelspace that > > works fine. > > > > As from my side to support the xceive driver properly it needs a > rewrite and a proper API description. Since it's not possible to > discuss any API changes I will work around at least for those devices > which I can support for. > > > On the other hand, a TV driver without a tuner is a broken driver. With > > parts of the driver being at userspace, this means to add undesired > > complexity at the drivers architecture, while not bringing any benefit. > > > > If you look at V4L history, the first drivers started at userspace, > > being migrated to kernelspace, where we have the proper scenario for > > managing those devices. > > > > Another aspect that should be analyzed is what is desired by the > > community: > > don't get me wrong but the existing community is rather small and > kicking off people who are interested in changing things. > I recently had a talk with someone and I've been told that I'm kicking > off people. > Guess why I kick off people? -> because they do not contribute in a > productive way which also means submitting patches. Optical useless > changes don't make any difference at the functionality in the end. And > my requirements are ignored constantly here. > > > kernelspace tuners or userspace tuners. Keeping support for > > both at long term doesn't seem reasonable. The Linux community should > > decide what is the better way. Currently, only you are pushing for > > userspace tuners, mainly due to non-technical reasons. > > read the project site and you will see the reasons. > http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages > Another advantage is that I have cygwin based code here which I can > easily reuse with all that work I'm not going to reinvent the wheel > even for newer devices which I work on. > > > Almost all the > > other developers are comfortable with kernelspace tuners. So, creating > > an userspace interface just to make you happy is not the way we should > > go. > > > > I'm afraid of giving the people which are against what I submitted the > responsibility over the project. Initially there was an RFC which > didn't get commented either (well there was one useless comment, I > tried to discuss it on IRC before with the same guy) after I > implemented exactly what I proposed there I got the first non > technical comments - also keep in mind that working on something costs > alot of time and talking about something unknown is rather cheap. > > > A final aspect is that having an userspace driver for tuner will mean > > that the kernel driver will depend on an userspace counterpart in order > > to work. This will allow a vendor with bad intentions to release a > > partially broken userspace driver, with limited capabilities, and a > > closed source driver for full support. This model is likely to occur, if > > you take a look at the past. For example: ATI and Nvidia closed source > > drivers, several soft modem drivers, some network drivers, ... > > > > Please go forward and discuss the UIO driver with Greg Kroah Hartmann > and the fuse driver with the other people. If companies want to > release binary drivers they can easily use the existing code put it > into an RPM or DEB package and Ubuntu will pick it up. > > > With all those issues, I'm against to add an userspace interface for >
Re: [linux-dvb] [PATCH] Userspace tuner
Let's add the LKML to this. On 9/13/07, Markus Rechberger [EMAIL PROTECTED] wrote: On 9/12/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: Markus, Em Ter, 2007-08-14 às 16:31 +0200, Markus Rechberger escreveu: Following patch adds the possibility to implement tuner drivers in userspace. As you asked me about userspace driver, at Linux Conf Europe, let me give you my feedback about it. On Linux, userspace-to-kernelspace APIs are meant to be forever. This means that, once a newer API is created, this should remain supported for all future versions. So, such APIs should be carefully analyzed and accepted by the community, before going to mainstream. The V4L and DVB API is stable at the moment because it's at a stage which is sufficient for older devices but not sufficient for newer devices anymore. To support newer device it needs a change. I don't see any technical reason why tuner drivers should be moved to userspace. Looking at xc3028 device, the driver is very simple and doesn't require any special treatment that it isn't possible to be done at kernel. There are already some implementations on kernelspace that works fine. As from my side to support the xceive driver properly it needs a rewrite and a proper API description. Since it's not possible to discuss any API changes I will work around at least for those devices which I can support for. On the other hand, a TV driver without a tuner is a broken driver. With parts of the driver being at userspace, this means to add undesired complexity at the drivers architecture, while not bringing any benefit. If you look at V4L history, the first drivers started at userspace, being migrated to kernelspace, where we have the proper scenario for managing those devices. Another aspect that should be analyzed is what is desired by the community: don't get me wrong but the existing community is rather small and kicking off people who are interested in changing things. I recently had a talk with someone and I've been told that I'm kicking off people. Guess why I kick off people? - because they do not contribute in a productive way which also means submitting patches. Optical useless changes don't make any difference at the functionality in the end. And my requirements are ignored constantly here. kernelspace tuners or userspace tuners. Keeping support for both at long term doesn't seem reasonable. The Linux community should decide what is the better way. Currently, only you are pushing for userspace tuners, mainly due to non-technical reasons. read the project site and you will see the reasons. http://mcentral.de/wiki/index.php/Userspace_tuner#Advantages Another advantage is that I have cygwin based code here which I can easily reuse with all that work I'm not going to reinvent the wheel even for newer devices which I work on. Almost all the other developers are comfortable with kernelspace tuners. So, creating an userspace interface just to make you happy is not the way we should go. I'm afraid of giving the people which are against what I submitted the responsibility over the project. Initially there was an RFC which didn't get commented either (well there was one useless comment, I tried to discuss it on IRC before with the same guy) after I implemented exactly what I proposed there I got the first non technical comments - also keep in mind that working on something costs alot of time and talking about something unknown is rather cheap. A final aspect is that having an userspace driver for tuner will mean that the kernel driver will depend on an userspace counterpart in order to work. This will allow a vendor with bad intentions to release a partially broken userspace driver, with limited capabilities, and a closed source driver for full support. This model is likely to occur, if you take a look at the past. For example: ATI and Nvidia closed source drivers, several soft modem drivers, some network drivers, ... Please go forward and discuss the UIO driver with Greg Kroah Hartmann and the fuse driver with the other people. If companies want to release binary drivers they can easily use the existing code put it into an RPM or DEB package and Ubuntu will pick it up. With all those issues, I'm against to add an userspace interface for tuners. I'm against how the project works out at the moment and how it worked out in history. Exactly this way will kick off companies to be interested in future like Avermedia. A driver can easily be written within a few weeks and I've been struggling with it for 2 years(!!!) now just for nothing finally telling me that some guys want to steal my code and move it to kernelspace although it would raise more complications with upcoming and current devices which have even more requirements. I spent more time in rewriting and discussing everything than to get any of those
Re: [PATCH] Fix a memory leak in em28xx_usb_probe()
Hi Jesper,
On 8/9/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> EHLO,
>
> If, in em28xx_usb_probe() the memory allocation
> dev->alt_max_pkt_size = kmalloc(32*
> dev->num_alt,GFP_KERNEL);
> fails, then we'll bail out and return -ENOMEM.
> The problem is that in that case we don't free the storage allocated
> to 'dev', thus causing a memory leak.
>
> This patch fixes the leak by freeing 'dev' before we return -ENOMEM.
> This fixes Coverity bug #647.
>
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
Acked-by: Markus Rechberger <[EMAIL PROTECTED]>
thanks,
Markus
> ---
>
> drivers/media/video/em28xx/em28xx-video.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/video/em28xx/em28xx-video.c
> b/drivers/media/video/em28xx/em28xx-video.c
> index 2c7b158..40307f3 100644
> --- a/drivers/media/video/em28xx/em28xx-video.c
> +++ b/drivers/media/video/em28xx/em28xx-video.c
> @@ -1772,6 +1772,7 @@ static int em28xx_usb_probe(struct usb_interface
> *interface,
> if (dev->alt_max_pkt_size == NULL) {
> em28xx_errdev("out of memory!\n");
> em28xx_devused&=~(1< + kfree(dev);
> return -ENOMEM;
> }
>
>
>
>
>
--
Markus Rechberger
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix a memory leak in em28xx_usb_probe()
Hi Jesper,
On 8/9/07, Jesper Juhl [EMAIL PROTECTED] wrote:
EHLO,
If, in em28xx_usb_probe() the memory allocation
dev-alt_max_pkt_size = kmalloc(32*
dev-num_alt,GFP_KERNEL);
fails, then we'll bail out and return -ENOMEM.
The problem is that in that case we don't free the storage allocated
to 'dev', thus causing a memory leak.
This patch fixes the leak by freeing 'dev' before we return -ENOMEM.
This fixes Coverity bug #647.
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
Acked-by: Markus Rechberger [EMAIL PROTECTED]
thanks,
Markus
---
drivers/media/video/em28xx/em28xx-video.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-video.c
b/drivers/media/video/em28xx/em28xx-video.c
index 2c7b158..40307f3 100644
--- a/drivers/media/video/em28xx/em28xx-video.c
+++ b/drivers/media/video/em28xx/em28xx-video.c
@@ -1772,6 +1772,7 @@ static int em28xx_usb_probe(struct usb_interface
*interface,
if (dev-alt_max_pkt_size == NULL) {
em28xx_errdev(out of memory!\n);
em28xx_devused=~(1nr);
+ kfree(dev);
return -ENOMEM;
}
--
Markus Rechberger
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Firmware class name collision
Hi Marcel,
Marcel Holtmann wrote:
Hi Markus,
following patch fixes the i2c name collision with i2c-dev.
http://mcentral.de/wiki/index.php/Bugtracker#i2c_core_problem
This issue has been experienced with em28xx and saa7133 based devices.
I discussed that problem with Jean Delvare a while ago and he proposed
to add a prefix to the class name.
http://mcentral.de/~mrec/patches/firmware_class_name_collision.diff
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
index b24efd4..bfc54a1 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -297,8 +297,7 @@ firmware_class_timeout(u_long data)
static inline void fw_setup_device_id(struct device *f_dev, struct
device *dev)
{
- /* XXX warning we should watch out for name collisions */
- strlcpy(f_dev->bus_id, dev->bus_id, BUS_ID_SIZE);
+ snprintf(f_dev->bus_id, BUS_ID_SIZE, "fw-%s", dev->bus_id);
}
I would prefer if we use "firmware-%s" since the "fw" might collide with
the new Firewire stack. Please change that and I agree.
firmware-%s sounds more informative and cannot be mistaken with firewire
yes.
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
http://mcentral.de/~mrec/patches/firmware_class_name_collision_2.diff
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index b24efd4..bfc54a1 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -297,8 +297,7 @@ firmware_class_timeout(u_long data)
static inline void fw_setup_device_id(struct device *f_dev, struct
device *dev)
{
- /* XXX warning we should watch out for name collisions */
- strlcpy(f_dev->bus_id, dev->bus_id, BUS_ID_SIZE);
+ snprintf(f_dev->bus_id, BUS_ID_SIZE, "firmware-%s", dev->bus_id);
}
static int fw_register_device(struct device **dev_p, const char *fw_name,
Acked-by: Marcel Holtmann <[EMAIL PROTECTED]>
Regards
Marcel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Firmware class name collision
Hi,
following patch fixes the i2c name collision with i2c-dev.
http://mcentral.de/wiki/index.php/Bugtracker#i2c_core_problem
This issue has been experienced with em28xx and saa7133 based devices.
I discussed that problem with Jean Delvare a while ago and he proposed
to add a prefix to the class name.
http://mcentral.de/~mrec/patches/firmware_class_name_collision.diff
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
index b24efd4..bfc54a1 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -297,8 +297,7 @@ firmware_class_timeout(u_long data)
static inline void fw_setup_device_id(struct device *f_dev, struct
device *dev)
{
- /* XXX warning we should watch out for name collisions */
- strlcpy(f_dev->bus_id, dev->bus_id, BUS_ID_SIZE);
+ snprintf(f_dev->bus_id, BUS_ID_SIZE, "fw-%s", dev->bus_id);
}
static int fw_register_device(struct device **dev_p, const char *fw_name,
Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Firmware class name collision
Hi,
following patch fixes the i2c name collision with i2c-dev.
http://mcentral.de/wiki/index.php/Bugtracker#i2c_core_problem
This issue has been experienced with em28xx and saa7133 based devices.
I discussed that problem with Jean Delvare a while ago and he proposed
to add a prefix to the class name.
http://mcentral.de/~mrec/patches/firmware_class_name_collision.diff
Signed-off-by: Markus Rechberger [EMAIL PROTECTED]
index b24efd4..bfc54a1 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -297,8 +297,7 @@ firmware_class_timeout(u_long data)
static inline void fw_setup_device_id(struct device *f_dev, struct
device *dev)
{
- /* XXX warning we should watch out for name collisions */
- strlcpy(f_dev-bus_id, dev-bus_id, BUS_ID_SIZE);
+ snprintf(f_dev-bus_id, BUS_ID_SIZE, fw-%s, dev-bus_id);
}
static int fw_register_device(struct device **dev_p, const char *fw_name,
Markus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Firmware class name collision
Hi Marcel,
Marcel Holtmann wrote:
Hi Markus,
following patch fixes the i2c name collision with i2c-dev.
http://mcentral.de/wiki/index.php/Bugtracker#i2c_core_problem
This issue has been experienced with em28xx and saa7133 based devices.
I discussed that problem with Jean Delvare a while ago and he proposed
to add a prefix to the class name.
http://mcentral.de/~mrec/patches/firmware_class_name_collision.diff
Signed-off-by: Markus Rechberger [EMAIL PROTECTED]
index b24efd4..bfc54a1 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -297,8 +297,7 @@ firmware_class_timeout(u_long data)
static inline void fw_setup_device_id(struct device *f_dev, struct
device *dev)
{
- /* XXX warning we should watch out for name collisions */
- strlcpy(f_dev-bus_id, dev-bus_id, BUS_ID_SIZE);
+ snprintf(f_dev-bus_id, BUS_ID_SIZE, fw-%s, dev-bus_id);
}
I would prefer if we use firmware-%s since the fw might collide with
the new Firewire stack. Please change that and I agree.
firmware-%s sounds more informative and cannot be mistaken with firewire
yes.
Signed-off-by: Markus Rechberger [EMAIL PROTECTED]
http://mcentral.de/~mrec/patches/firmware_class_name_collision_2.diff
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index b24efd4..bfc54a1 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -297,8 +297,7 @@ firmware_class_timeout(u_long data)
static inline void fw_setup_device_id(struct device *f_dev, struct
device *dev)
{
- /* XXX warning we should watch out for name collisions */
- strlcpy(f_dev-bus_id, dev-bus_id, BUS_ID_SIZE);
+ snprintf(f_dev-bus_id, BUS_ID_SIZE, firmware-%s, dev-bus_id);
}
static int fw_register_device(struct device **dev_p, const char *fw_name,
Acked-by: Marcel Holtmann [EMAIL PROTECTED]
Regards
Marcel
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [2.6 patch] dvb_frontend_ioctl(): fix check-after-use
On 8/11/07, Trent Piepho <[EMAIL PROTECTED]> wrote: > On Fri, 10 Aug 2007, Markus Rechberger wrote: > > On 8/1/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > > > On 7/31/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > The Coverity checker spotted that we have already oops'ed if "fe" was > > > NULL. > > > > > > > > --- linux-2.6.23-rc1-mm1/drivers/media/dvb/dvb-core/dvb_frontend.c.old > > > > +++ linux-2.6.23-rc1-mm1/drivers/media/dvb/dvb-core/dvb_frontend.c > > > > @@ -706,11 +706,11 @@ static int dvb_frontend_ioctl(struct ino > > > > - if (!fe || fepriv->exit) > > > > + if (fepriv->exit) > > > > return -ENODEV; > > > > This issue has been known for a while including some other problems at > > that part. > > > > > http://article.gmane.org/gmane.linux.drivers.dvb/35351/match=patch+dvb_net+hotplugging+support > > > > this includes a link where this and more got discussed in May. > > For dvb_net_close, I like the patch I already posted better. To fix the > check-after-use, it's not "use" part that's the problem, it's the "check" > part > that isn't necessary. > > I traced the dvb-net code, > http://article.gmane.org/gmane.linux.kernel/543689, > and I'm sure that dvbdev can't be NULL. > > My patch also deletes a few pieces of duplicated code by calling > dvb_generic_release(). > > The only problem is that practically no one uses dvb-net, so it's very hard > to > test these patches. > I didn't see this patch, it would be fine if it would get applied. > In all the dvb code, were is the locking for device open and release? I > don't > see it. What is preventing two threads from trying to open and/or close the > same dvb device at the same time? > Haven't looked at that yet, since I moreover work to get the em28xx driver included now. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [2.6 patch] dvb_frontend_ioctl(): fix check-after-use
On 8/11/07, Trent Piepho [EMAIL PROTECTED] wrote: On Fri, 10 Aug 2007, Markus Rechberger wrote: On 8/1/07, Manu Abraham [EMAIL PROTECTED] wrote: On 7/31/07, Adrian Bunk [EMAIL PROTECTED] wrote: The Coverity checker spotted that we have already oops'ed if fe was NULL. --- linux-2.6.23-rc1-mm1/drivers/media/dvb/dvb-core/dvb_frontend.c.old +++ linux-2.6.23-rc1-mm1/drivers/media/dvb/dvb-core/dvb_frontend.c @@ -706,11 +706,11 @@ static int dvb_frontend_ioctl(struct ino - if (!fe || fepriv-exit) + if (fepriv-exit) return -ENODEV; This issue has been known for a while including some other problems at that part. http://article.gmane.org/gmane.linux.drivers.dvb/35351/match=patch+dvb_net+hotplugging+support this includes a link where this and more got discussed in May. For dvb_net_close, I like the patch I already posted better. To fix the check-after-use, it's not use part that's the problem, it's the check part that isn't necessary. I traced the dvb-net code, http://article.gmane.org/gmane.linux.kernel/543689, and I'm sure that dvbdev can't be NULL. My patch also deletes a few pieces of duplicated code by calling dvb_generic_release(). The only problem is that practically no one uses dvb-net, so it's very hard to test these patches. I didn't see this patch, it would be fine if it would get applied. In all the dvb code, were is the locking for device open and release? I don't see it. What is preventing two threads from trying to open and/or close the same dvb device at the same time? Haven't looked at that yet, since I moreover work to get the em28xx driver included now. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [2.6 patch] dvb_frontend_ioctl(): fix check-after-use
On 8/1/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> On 7/31/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > The Coverity checker spotted that we have already oops'ed if "fe" was
> NULL.
> >
> > Since "fe" being NULL seems impossible at this point this patch removes
> > the NULL check.
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> >
> > ---
> > --- linux-2.6.23-rc1-mm1/drivers/media/dvb/dvb-core/dvb_frontend.c.old
> 2007-07-29 21:41:56.0 +0200
> > +++ linux-2.6.23-rc1-mm1/drivers/media/dvb/dvb-core/dvb_frontend.c
> 2007-07-29 21:42:16.0 +0200
> > @@ -706,11 +706,11 @@ static int dvb_frontend_ioctl(struct ino
> > struct dvb_frontend_private *fepriv = fe->frontend_priv;
> > int err = -EOPNOTSUPP;
> >
> > dprintk ("%s\n", __FUNCTION__);
> >
> > - if (!fe || fepriv->exit)
> > + if (fepriv->exit)
> > return -ENODEV;
> >
> > if ((file->f_flags & O_ACCMODE) == O_RDONLY &&
> > (_IOC_DIR(cmd) != _IOC_READ || cmd == FE_GET_EVENT ||
> > cmd == FE_DISEQC_RECV_SLAVE_REPLY))
> >
> > -
>
> Acked-by: Manu Abraham <[EMAIL PROTECTED]>
>
This issue has been known for a while including some other problems at
that part.
http://article.gmane.org/gmane.linux.drivers.dvb/35351/match=patch+dvb_net+hotplugging+support
this includes a link where this and more got discussed in May.
Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [2.6 patch] dvb_frontend_ioctl(): fix check-after-use
On 8/1/07, Manu Abraham [EMAIL PROTECTED] wrote: On 7/31/07, Adrian Bunk [EMAIL PROTECTED] wrote: The Coverity checker spotted that we have already oops'ed if fe was NULL. Since fe being NULL seems impossible at this point this patch removes the NULL check. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- --- linux-2.6.23-rc1-mm1/drivers/media/dvb/dvb-core/dvb_frontend.c.old 2007-07-29 21:41:56.0 +0200 +++ linux-2.6.23-rc1-mm1/drivers/media/dvb/dvb-core/dvb_frontend.c 2007-07-29 21:42:16.0 +0200 @@ -706,11 +706,11 @@ static int dvb_frontend_ioctl(struct ino struct dvb_frontend_private *fepriv = fe-frontend_priv; int err = -EOPNOTSUPP; dprintk (%s\n, __FUNCTION__); - if (!fe || fepriv-exit) + if (fepriv-exit) return -ENODEV; if ((file-f_flags O_ACCMODE) == O_RDONLY (_IOC_DIR(cmd) != _IOC_READ || cmd == FE_GET_EVENT || cmd == FE_DISEQC_RECV_SLAVE_REPLY)) - Acked-by: Manu Abraham [EMAIL PROTECTED] This issue has been known for a while including some other problems at that part. http://article.gmane.org/gmane.linux.drivers.dvb/35351/match=patch+dvb_net+hotplugging+support this includes a link where this and more got discussed in May. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] SAA7160/2
Creating a wiki site for Empia based devices and setting up a Mailinglist worked out well. That way you also get the email addresses of people who are very likely interested in such device. Markus On 8/1/07, Manu Abraham <[EMAIL PROTECTED]> wrote: > Hi All, > > After a bit of talks with NXP, they stated that if shown enough of a > user base (future business forecast) for the SAA7160 / SAA7162 PCIe > chipset, they would take into consideration, an investment into > support, such that the chips can be better supported. > > ie, i need to provide them information that there is some significant > numbers in the user base. > Additionally, vendors such as Azurewave are ready to help us as well, > in whatever way they can. > > Any ideas, how we can show user support in terms of a future business > case ? Comments appreciated. > > Thanks, > Manu > > ___ > linux-dvb mailing list > [EMAIL PROTECTED] > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > -- Markus Rechberger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] SAA7160/2
Creating a wiki site for Empia based devices and setting up a Mailinglist worked out well. That way you also get the email addresses of people who are very likely interested in such device. Markus On 8/1/07, Manu Abraham [EMAIL PROTECTED] wrote: Hi All, After a bit of talks with NXP, they stated that if shown enough of a user base (future business forecast) for the SAA7160 / SAA7162 PCIe chipset, they would take into consideration, an investment into support, such that the chips can be better supported. ie, i need to provide them information that there is some significant numbers in the user base. Additionally, vendors such as Azurewave are ready to help us as well, in whatever way they can. Any ideas, how we can show user support in terms of a future business case ? Comments appreciated. Thanks, Manu ___ linux-dvb mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- Markus Rechberger - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6 spurious hangs
On 6/29/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > Still we can't do this under cinergyt2->sem, because cinergyt2_query() > takes it too. This all looks very wrong to me, I hope maintaners can > explain. AFAIK, the driver authors are not working anymore with CinergyT2. The last patch we have on development tree from Holger is dated as Dec, 3 2004. Since them, only internal kernel API changes and a few sparse fixes from other contributors were applied. Also, none of the current DVB maintainers seem to have any hardware for testing. I received a Mail a while ago that this driver is open to the community, it duplicates some code because the developers wanted to use this driver for testing another DVB API which never took off. Best would be to remove the duplicated code in that driver and make it look like all other DVB drivers. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc6 spurious hangs
On 6/29/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: Still we can't do this under cinergyt2-sem, because cinergyt2_query() takes it too. This all looks very wrong to me, I hope maintaners can explain. AFAIK, the driver authors are not working anymore with CinergyT2. The last patch we have on development tree from Holger is dated as Dec, 3 2004. Since them, only internal kernel API changes and a few sparse fixes from other contributors were applied. Also, none of the current DVB maintainers seem to have any hardware for testing. I received a Mail a while ago that this driver is open to the community, it duplicates some code because the developers wanted to use this driver for testing another DVB API which never took off. Best would be to remove the duplicated code in that driver and make it look like all other DVB drivers. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to improve the quality of the kernel?
On 6/17/07, Natalie Protasevich <[EMAIL PROTECTED]> wrote:
On 6/17/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 17, 2007 at 06:26:55PM +0200, Stefan Richter wrote:
> > Adrian Bunk wrote:
> > >>> And we should be aware that reverting is only a workaround for the
real
> > >>> problem which lies in our bug handling.
> > >> ...
> > >
> > > And this is something I want to emphasize again.
> > >
> > > How can we make any progress with the real problem and not only the
> > > symptoms?
> > ...
> >
> > Perhaps make lists of
> >
> > - bug reports which never lead to any debug activity
> > (no responsible person/team was found, or a seemingly person/team
> > did not start to debug the report)
> >
> > - known regressions on release,
> >
> > - regressions that became known after release,
> >
> > - subsystems with notable backlogs of old bugs,
> >
> > - other categories?
> >
> > Select typical cases from each categories, analyze what went wrong in
> > these cases, and try to identify practicable countermeasures.
>
> No maintainer or no maintainer who is debugging bug reports is the
> major problem in all parts of your list.
>
> > Another approach: Figure out areas where quality is exemplary and try
> > to draw conclusions for areas where quality is lacking.
>
> ieee1394 has a maintainer who is looking after all bug reports he gets.
>
> Conclusion: We need such maintainers for all parts of the kernel.
>
I noticed some areas are well maintained because there is an awesome
maintainer, or good and well coordinated team - and this is mostly in
the "fun" areas ;) But there are "boring" areas that are about to be
deprecated or no new development expected etc. It will be hard to get
a dedicated person to take care of such. How about having people on
rotation, or jury duty so to speak - for a period of time (completely
voluntary!) Nice stats on the report about contributions in non-native
areas for a developer would be great accomplishment and also good
chance to look into other things! Besides, this way "old parts" will
get attention to be be revised and re-implemented sooner. And we can
post "Temp maintainer needed" list...
I'd vote for that, I've seen alot very bad code already within some
subsystems and critical problems which just have been ignored by some
maintainers.
It mostly helps if some volunteers read through existing code and
state out their considerations about implementations which they don't
like.
I just grep'ed some examples I noticed (note I do not want to jump
onto someone's toe here, just give some examples):
(sn9c102_ov7660.c)
...
err += sn9c102_i2c_write(cam, 0x12, 0x80);
err += sn9c102_i2c_write(cam, 0x11, 0x09);
err += sn9c102_i2c_write(cam, 0x00, 0x0A);
err += sn9c102_i2c_write(cam, 0x01, 0x80);
err += sn9c102_i2c_write(cam, 0x02, 0x80);
err += sn9c102_i2c_write(cam, 0x03, 0x00);
... (around 150 lines directly after each other doing such writes and
adding error values to a variable, I don't understand why someone
should add the errors but continue with sending 150 more updates, how
about one write failed but others succeeded for any reason)
(tvp5150.c)
static int tvp5150_read(struct i2c_client *c, unsigned char addr)
{
unsigned char buffer[1];
int rc;
buffer[0] = addr;
if (1 != (rc = i2c_master_send(c, buffer, 1)))
tvp5150_dbg(0, "i2c i/o error: rc == %d (should be 1)\n", rc);
msleep(10);
if (1 != (rc = i2c_master_recv(c, buffer, 1)))
tvp5150_dbg(0, "i2c i/o error: rc == %d (should be 1)\n", rc);
tvp5150_dbg(2, "tvp5150: read 0x%02x = 0x%02x\n", addr, buffer[0]);
return (buffer[0]);
}
(i2c issues within some driver)
/* This code detects calls by card attach_inform */
if (NULL == t->i2c.dev.driver) {
tuner_dbg ("tuner 0x%02x: called during i2c_client
register by adapter's attach_inform\n", c->addr);
return;
}
... that code doesn't even work anymore since the i2c.dev.driver is
always initialized.
just reading through it and cleaning up some code isn't so difficult
and can be done by many people - if they're allowed/wanted to do so.
Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How to improve the quality of the kernel?
On 6/17/07, Natalie Protasevich [EMAIL PROTECTED] wrote:
On 6/17/07, Adrian Bunk [EMAIL PROTECTED] wrote:
On Sun, Jun 17, 2007 at 06:26:55PM +0200, Stefan Richter wrote:
Adrian Bunk wrote:
And we should be aware that reverting is only a workaround for the
real
problem which lies in our bug handling.
...
And this is something I want to emphasize again.
How can we make any progress with the real problem and not only the
symptoms?
...
Perhaps make lists of
- bug reports which never lead to any debug activity
(no responsible person/team was found, or a seemingly person/team
did not start to debug the report)
- known regressions on release,
- regressions that became known after release,
- subsystems with notable backlogs of old bugs,
- other categories?
Select typical cases from each categories, analyze what went wrong in
these cases, and try to identify practicable countermeasures.
No maintainer or no maintainer who is debugging bug reports is the
major problem in all parts of your list.
Another approach: Figure out areas where quality is exemplary and try
to draw conclusions for areas where quality is lacking.
ieee1394 has a maintainer who is looking after all bug reports he gets.
Conclusion: We need such maintainers for all parts of the kernel.
I noticed some areas are well maintained because there is an awesome
maintainer, or good and well coordinated team - and this is mostly in
the fun areas ;) But there are boring areas that are about to be
deprecated or no new development expected etc. It will be hard to get
a dedicated person to take care of such. How about having people on
rotation, or jury duty so to speak - for a period of time (completely
voluntary!) Nice stats on the report about contributions in non-native
areas for a developer would be great accomplishment and also good
chance to look into other things! Besides, this way old parts will
get attention to be be revised and re-implemented sooner. And we can
post Temp maintainer needed list...
I'd vote for that, I've seen alot very bad code already within some
subsystems and critical problems which just have been ignored by some
maintainers.
It mostly helps if some volunteers read through existing code and
state out their considerations about implementations which they don't
like.
I just grep'ed some examples I noticed (note I do not want to jump
onto someone's toe here, just give some examples):
(sn9c102_ov7660.c)
...
err += sn9c102_i2c_write(cam, 0x12, 0x80);
err += sn9c102_i2c_write(cam, 0x11, 0x09);
err += sn9c102_i2c_write(cam, 0x00, 0x0A);
err += sn9c102_i2c_write(cam, 0x01, 0x80);
err += sn9c102_i2c_write(cam, 0x02, 0x80);
err += sn9c102_i2c_write(cam, 0x03, 0x00);
... (around 150 lines directly after each other doing such writes and
adding error values to a variable, I don't understand why someone
should add the errors but continue with sending 150 more updates, how
about one write failed but others succeeded for any reason)
(tvp5150.c)
static int tvp5150_read(struct i2c_client *c, unsigned char addr)
{
unsigned char buffer[1];
int rc;
buffer[0] = addr;
if (1 != (rc = i2c_master_send(c, buffer, 1)))
tvp5150_dbg(0, i2c i/o error: rc == %d (should be 1)\n, rc);
msleep(10);
if (1 != (rc = i2c_master_recv(c, buffer, 1)))
tvp5150_dbg(0, i2c i/o error: rc == %d (should be 1)\n, rc);
tvp5150_dbg(2, tvp5150: read 0x%02x = 0x%02x\n, addr, buffer[0]);
return (buffer[0]);
}
(i2c issues within some driver)
/* This code detects calls by card attach_inform */
if (NULL == t-i2c.dev.driver) {
tuner_dbg (tuner 0x%02x: called during i2c_client
register by adapter's attach_inform\n, c-addr);
return;
}
... that code doesn't even work anymore since the i2c.dev.driver is
always initialized.
just reading through it and cleaning up some code isn't so difficult
and can be done by many people - if they're allowed/wanted to do so.
Markus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: pci probe
On 5/30/07, Greg KH <[EMAIL PROTECTED]> wrote: On Wed, May 16, 2007 at 04:29:38PM +0400, Manu Abraham wrote: > Greg KH wrote: > > On Tue, May 15, 2007 at 05:15:28PM +0400, Manu Abraham wrote: > >> Manu Abraham wrote: > >>> Hi, > >>> > >>> I do have a device that's a multifunction device. Eventhough a MFD, it > >>> just has one Interrupt which is shared by by a Configuration space for > >>> each function. ie, INTA is shared between them functions. > >>> > >>> In such a case, i am wondering, (since pci_probe returns a pointer to > >>> one PCI function alone and i need to use both the functions in one > >>> module alone rather than using a module for each function and that the > >>> functions are quite similar for them to be used in different modules, > >>> such that a separate probe/ISR etc is used) whether using pci_get_device > >>> would be a better alternative to do manual searching for the functions > >>> in such a case. > >>> > >> Just figured out that pci_get_subsys() does work in a better. Looking at > >> kernel sources all i find is just one single user of pci_get_subsys() > >> > >> building the code around pci_get_subsys(), does this have any negative > >> impact ? > > > > Yes: > > - your device will not show up properly in sysfs (no > > device/driver binding ability from userspace, no good > > information so that udev can properly name the device, etc.) > > This one sounds bad. > > > - your driver will not work on any pci-hotplug type system (that > > includes expresscard and pccard and lots of high-end servers. > > This doesn't matter Are you sure? PCI Hotplug is showing up in more places that people realize... In case of video4linux and dvb, there are cx88 and saa7134 based pcmcia devices available which show up as PCI devices, both of these drivers enable the interrupts as soon as they're connected and there's no need to access the device nodes for that. Another point is that they're not hotplug aware, the driver end up in an endless loop or crashes linux if someone unplugs the device (even if it's not in use). > > - your driver will not be notified if the system is being > > suspended or resumed or wanting to drop into a low power > > state. > > - another driver can bind to your device without you ever > > knowing it. > > These also sound bad. > > > So in short, use pci_probe and just handle the fact that you need to be > > called for two PCI devices and bind to both of them. It shouldn't be > > that hard... > > Thanks for the explanation. > > Do you mean to have two PCIID tables ? But then that does mean 2 modules > don't you ? (i thought probe would be called once per module) Or you > mean to say use PCI_ANY_ID in the table to match multiple devices and > then allow probe to return a list of devices ? No, you can specify multiple devices in the same device id table, and your driver will get called for all of the matching devices. You just need to "bind" them together in your driver to be able to handle everything properly. It shouldn't be that tough. Uwe posted an example how to tie multiple functions of a device together, there are quite a few ways how to solve that problem. http://linuxtv.org/pipermail/linux-dvb/2007-June/018481.html Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pci probe
On 5/30/07, Greg KH [EMAIL PROTECTED] wrote: On Wed, May 16, 2007 at 04:29:38PM +0400, Manu Abraham wrote: Greg KH wrote: On Tue, May 15, 2007 at 05:15:28PM +0400, Manu Abraham wrote: Manu Abraham wrote: Hi, I do have a device that's a multifunction device. Eventhough a MFD, it just has one Interrupt which is shared by by a Configuration space for each function. ie, INTA is shared between them functions. In such a case, i am wondering, (since pci_probe returns a pointer to one PCI function alone and i need to use both the functions in one module alone rather than using a module for each function and that the functions are quite similar for them to be used in different modules, such that a separate probe/ISR etc is used) whether using pci_get_device would be a better alternative to do manual searching for the functions in such a case. Just figured out that pci_get_subsys() does work in a better. Looking at kernel sources all i find is just one single user of pci_get_subsys() building the code around pci_get_subsys(), does this have any negative impact ? Yes: - your device will not show up properly in sysfs (no device/driver binding ability from userspace, no good information so that udev can properly name the device, etc.) This one sounds bad. - your driver will not work on any pci-hotplug type system (that includes expresscard and pccard and lots of high-end servers. This doesn't matter Are you sure? PCI Hotplug is showing up in more places that people realize... In case of video4linux and dvb, there are cx88 and saa7134 based pcmcia devices available which show up as PCI devices, both of these drivers enable the interrupts as soon as they're connected and there's no need to access the device nodes for that. Another point is that they're not hotplug aware, the driver end up in an endless loop or crashes linux if someone unplugs the device (even if it's not in use). - your driver will not be notified if the system is being suspended or resumed or wanting to drop into a low power state. - another driver can bind to your device without you ever knowing it. These also sound bad. So in short, use pci_probe and just handle the fact that you need to be called for two PCI devices and bind to both of them. It shouldn't be that hard... Thanks for the explanation. Do you mean to have two PCIID tables ? But then that does mean 2 modules don't you ? (i thought probe would be called once per module) Or you mean to say use PCI_ANY_ID in the table to match multiple devices and then allow probe to return a list of devices ? No, you can specify multiple devices in the same device id table, and your driver will get called for all of the matching devices. You just need to bind them together in your driver to be able to handle everything properly. It shouldn't be that tough. Uwe posted an example how to tie multiple functions of a device together, there are quite a few ways how to solve that problem. http://linuxtv.org/pipermail/linux-dvb/2007-June/018481.html Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] remove orphaned Email
Manuel Estrada Sainz passed away on May 9th 2004, his email account got
deactivated. He was in charge of the firmware_class code, and still got
CC'ed in recent discussions about it.
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
diff --git a/Documentation/firmware_class/README b/Documentation/firmware_class/README
index e9cc8bb..d19eb19 100644
--- a/Documentation/firmware_class/README
+++ b/Documentation/firmware_class/README
@@ -1,7 +1,7 @@
request_firmware() hotplug interface:
- Copyright (C) 2003 Manuel Estrada Sainz <[EMAIL PROTECTED]>
+ Copyright (C) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident)
Why:
---
diff --git a/Documentation/firmware_class/firmware_sample_driver.c b/Documentation/firmware_class/firmware_sample_driver.c
index 87feccd..3d4a877 100644
--- a/Documentation/firmware_class/firmware_sample_driver.c
+++ b/Documentation/firmware_class/firmware_sample_driver.c
@@ -1,7 +1,7 @@
/*
* firmware_sample_driver.c -
*
- * Copyright (c) 2003 Manuel Estrada Sainz <[EMAIL PROTECTED]>
+ * Copyright (c) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident)
*
* Sample code on how to use request_firmware() from drivers.
*
diff --git a/Documentation/firmware_class/firmware_sample_firmware_class.c b/Documentation/firmware_class/firmware_sample_firmware_class.c
index 9e1b0e4..678b050 100644
--- a/Documentation/firmware_class/firmware_sample_firmware_class.c
+++ b/Documentation/firmware_class/firmware_sample_firmware_class.c
@@ -1,7 +1,7 @@
/*
* firmware_sample_firmware_class.c -
*
- * Copyright (c) 2003 Manuel Estrada Sainz <[EMAIL PROTECTED]>
+ * Copyright (c) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident)
*
* NOTE: This is just a probe of concept, if you think that your driver would
* be well served by this mechanism please contact me first.
@@ -19,7 +19,7 @@
#include
-MODULE_AUTHOR("Manuel Estrada Sainz <[EMAIL PROTECTED]>");
+MODULE_AUTHOR("Manuel Estrada Sainz");
MODULE_DESCRIPTION("Hackish sample for using firmware class directly");
MODULE_LICENSE("GPL");
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 97ab5bd..672c221 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1,7 +1,7 @@
/*
* firmware_class.c - Multi purpose firmware loading support
*
- * Copyright (c) 2003 Manuel Estrada Sainz <[EMAIL PROTECTED]>
+ * Copyright (c) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident)
*
* Please see Documentation/firmware_class/ for more information.
*
@@ -23,7 +23,7 @@
#define to_dev(obj) container_of(obj, struct device, kobj)
-MODULE_AUTHOR("Manuel Estrada Sainz <[EMAIL PROTECTED]>");
+MODULE_AUTHOR("Manuel Estrada Sainz");
MODULE_DESCRIPTION("Multi purpose firmware loading support");
MODULE_LICENSE("GPL");
[patch] remove orphaned Email
Manuel Estrada Sainz passed away on May 9th 2004, his email account got deactivated. He was in charge of the firmware_class code, and still got CC'ed in recent discussions about it. Signed-off-by: Markus Rechberger [EMAIL PROTECTED] diff --git a/Documentation/firmware_class/README b/Documentation/firmware_class/README index e9cc8bb..d19eb19 100644 --- a/Documentation/firmware_class/README +++ b/Documentation/firmware_class/README @@ -1,7 +1,7 @@ request_firmware() hotplug interface: - Copyright (C) 2003 Manuel Estrada Sainz [EMAIL PROTECTED] + Copyright (C) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident) Why: --- diff --git a/Documentation/firmware_class/firmware_sample_driver.c b/Documentation/firmware_class/firmware_sample_driver.c index 87feccd..3d4a877 100644 --- a/Documentation/firmware_class/firmware_sample_driver.c +++ b/Documentation/firmware_class/firmware_sample_driver.c @@ -1,7 +1,7 @@ /* * firmware_sample_driver.c - * - * Copyright (c) 2003 Manuel Estrada Sainz [EMAIL PROTECTED] + * Copyright (c) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident) * * Sample code on how to use request_firmware() from drivers. * diff --git a/Documentation/firmware_class/firmware_sample_firmware_class.c b/Documentation/firmware_class/firmware_sample_firmware_class.c index 9e1b0e4..678b050 100644 --- a/Documentation/firmware_class/firmware_sample_firmware_class.c +++ b/Documentation/firmware_class/firmware_sample_firmware_class.c @@ -1,7 +1,7 @@ /* * firmware_sample_firmware_class.c - * - * Copyright (c) 2003 Manuel Estrada Sainz [EMAIL PROTECTED] + * Copyright (c) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident) * * NOTE: This is just a probe of concept, if you think that your driver would * be well served by this mechanism please contact me first. @@ -19,7 +19,7 @@ #include linux/firmware.h -MODULE_AUTHOR(Manuel Estrada Sainz [EMAIL PROTECTED]); +MODULE_AUTHOR(Manuel Estrada Sainz); MODULE_DESCRIPTION(Hackish sample for using firmware class directly); MODULE_LICENSE(GPL); diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 97ab5bd..672c221 100644 --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -1,7 +1,7 @@ /* * firmware_class.c - Multi purpose firmware loading support * - * Copyright (c) 2003 Manuel Estrada Sainz [EMAIL PROTECTED] + * Copyright (c) 2003 Manuel Estrada Sainz (passed away on May 9th 2004 at a car accident) * * Please see Documentation/firmware_class/ for more information. * @@ -23,7 +23,7 @@ #define to_dev(obj) container_of(obj, struct device, kobj) -MODULE_AUTHOR(Manuel Estrada Sainz [EMAIL PROTECTED]); +MODULE_AUTHOR(Manuel Estrada Sainz); MODULE_DESCRIPTION(Multi purpose firmware loading support); MODULE_LICENSE(GPL);
Re: [linux-dvb] dst customization patchset
On 6/1/07, Bill Eldridge <[EMAIL PROTECTED]> wrote: Sounds good, Markus - do you have a list of known bugs that need to be handled? Yes, I put together a few things that came into mind: http://mcentral.de/wiki/index.php/Bugtracker Is this something that can go up on the Wiki, or are there enough that a bug tracking system is required? Wiki/ML should be fine, people use to avoid the bugzilla on kernel.org although I'd be fine with it (at least for the em28xx project) but people prefer to add bugreports to the wiki or send mails. While timelines won't be enforceable for people doing things in their spare time, it's still useful to put up time goals and priority lists on projects, both new development and bug fixes, to keep momentum going and gauge progress, including seeing that something that should have been fixed isn't getting handled. Can people accept Markus as a reasonable, informed arbiter of what will go into the main tree even if there are disagreements? It also sounds like new programmers here need more startup instructions/assistance/advice and ground rules than on many open source projects. I would appreciate to get more people involved with that project, VDR/mythTV/mplayer/ffmpeg etc. projects use the outcoming work. While the v4l and dvb project is doing really hard at the moment and improvements are handled in a snail speed (if ever handled) this should really change. cheers, Markus Regards, Bill Markus Rechberger wrote: > > Some developers are also sick of contributing since the whole > community is flawed at the moment. I propose a few ways to go > > * stopping that signed off by madness that every driver developer has > to sign off changes which happened at the core which will definitelly > never happen because people _do not like each other_. > > * change the maintainership and push it over to me, even if it sounds > selfish at the moment _every_ code which provides additional features > and where noone expects further improvements within the next few weeks > (without throwing away alot of work or generating useless extra work > by telling someone to rewrite the core of his work); everyone still > can try to write better code - but then he _has to do it completly_ > and get in peace with the projects by supporting them to get further. > > The problem I have with this project is that many more things are > upcoming at the moment (including bug fixing) but there are certain > developers which first weren't experienced enough, afterwards started > to think about the issues which were tried to discuss at the beginning > already and who don't have an overview about the requirements, neither > do they want to discuss the requirements. > I can name numerous of bugs of this project which can be solved but > which just get ignored. Some known bugs dont even get explained to > people who are interested in fixing them, so this is what I consider > that it's a major problem. > > I'm looking for a serious discussion about it, if anyone wants to know > about the history I can point out to many logfiles/older emails which > deeply explain the whole video4linux/dvb issues - the project should > turn back to a real community. > > Markus > -- Markus Rechberger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] dst customization patchset
On 6/1/07, Bill Eldridge [EMAIL PROTECTED] wrote: Sounds good, Markus - do you have a list of known bugs that need to be handled? Yes, I put together a few things that came into mind: http://mcentral.de/wiki/index.php/Bugtracker Is this something that can go up on the Wiki, or are there enough that a bug tracking system is required? Wiki/ML should be fine, people use to avoid the bugzilla on kernel.org although I'd be fine with it (at least for the em28xx project) but people prefer to add bugreports to the wiki or send mails. While timelines won't be enforceable for people doing things in their spare time, it's still useful to put up time goals and priority lists on projects, both new development and bug fixes, to keep momentum going and gauge progress, including seeing that something that should have been fixed isn't getting handled. Can people accept Markus as a reasonable, informed arbiter of what will go into the main tree even if there are disagreements? It also sounds like new programmers here need more startup instructions/assistance/advice and ground rules than on many open source projects. I would appreciate to get more people involved with that project, VDR/mythTV/mplayer/ffmpeg etc. projects use the outcoming work. While the v4l and dvb project is doing really hard at the moment and improvements are handled in a snail speed (if ever handled) this should really change. cheers, Markus Regards, Bill Markus Rechberger wrote: Some developers are also sick of contributing since the whole community is flawed at the moment. I propose a few ways to go * stopping that signed off by madness that every driver developer has to sign off changes which happened at the core which will definitelly never happen because people _do not like each other_. * change the maintainership and push it over to me, even if it sounds selfish at the moment _every_ code which provides additional features and where noone expects further improvements within the next few weeks (without throwing away alot of work or generating useless extra work by telling someone to rewrite the core of his work); everyone still can try to write better code - but then he _has to do it completly_ and get in peace with the projects by supporting them to get further. The problem I have with this project is that many more things are upcoming at the moment (including bug fixing) but there are certain developers which first weren't experienced enough, afterwards started to think about the issues which were tried to discuss at the beginning already and who don't have an overview about the requirements, neither do they want to discuss the requirements. I can name numerous of bugs of this project which can be solved but which just get ignored. Some known bugs dont even get explained to people who are interested in fixing them, so this is what I consider that it's a major problem. I'm looking for a serious discussion about it, if anyone wants to know about the history I can point out to many logfiles/older emails which deeply explain the whole video4linux/dvb issues - the project should turn back to a real community. Markus -- Markus Rechberger - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] dst customization patchset
On 5/31/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: Am Donnerstag, 31. Mai 2007 07:01 schrieb Bill Eldridge: > timecop wrote: > >> Guys, it's GPL code. Fork the project and stop your bitching. > >> If you do a better job, people will use and contribute to your version. > >> If you do a worse job, people will use and contribute to Manu's. > >> Some will use and contribute to both. Life's good, eh? > > > > This is exactly why Linux is shit. > > You have 100s of "forked projects" because some guy named Uwe thought > > he could do better than some guy named Manu and now you have two > > projects to contribute to, both suck in various ways, of course some > > idiot is going to be "backporting" from one to another, introducing > > weird bugs, etc etc etc. > > > > Make a fucking decision and stick with it. Stop wasting everyone's > > time. It's no secret that current Linux-DVB/V4L/whatever system is a > > pile of steaming feces. Every one of you admitted to it on this list > > at some point in the past. So get to it, make a fucking decision, > > "fire" (loool) retards who are slowing the project down, and get shit > > moving. I vote for Uwe as Linux-DVB maintainer. > > Regards, > > tc > > I nominate Timecop to be maintainer/top cop to figure out which version > sucks in which area > and do his best to get the best approach used. Sometimes a good strong > and outspoken > manager is more important than technical prowess (and I have no idea as > to your technical > abilities, just saying it looks like a management issue). I am not a fan of "strong men" or "strong managers" of whatever kind. We in Germany have very bad experiences concerning this kind of human desire / call regarding our history. Instead there should be one responsible code reviewer for v4l stuff, and at least one responsible code reviewer for DVB stuff. This is a minimum adequate demand to make things work. Inactivity on future projects in connection with Nacks of activities to optimize the stock kernel are no fair play or helpful behaviour at all, but they are just counterproductive. Who likes small kings? Well, I do not! > > For Uwe, it's not that I don't "want" to understand anything - I just > showed up 2 days ago and > simply want a workable driver for my machine, and instead had to switch > cards to something > else. Usually I assume if the code was forked the fork would be > somewhere else and you wouldn't > be complaining to this list, but I understand there are different ways. > (Samba did it this way for > quite some time). Forking may be OK for different Linux distros. But v4l-DVB is not a distro, it should be a common project instead. What you find is some 20 developers with a multiplicity of repositories. You do not even know who is maintainer and who is not. What you also find is the blocking gesture of that person who once threw his hat into the ring wanting to become maintainer. As the whole situation is one big mess you do not even know whether becoming a maintainer or not is product of a democtratic vote. Above that there is no team structure at all, but instead there is a big chaos, mess. And if some code, may it be humble or mature, is not even pulled into the mm-tree (its basic role has always been testing, nothing else) I would call that a catastrophe. Uwe writes alot insulting crap (which is a fact), even if the DVB subsystem has no maintainer the code should be managed appropriately and stopping the development is no way to do it. At the moment we have __tonns of critical bugs__ in the drivers and the video4linux and dvb framework; both frameworks are incomplete and don't provide the necessary flexibility to support an infrastructure for devices which could already be supported at the moment. We have several (technical) good people which which work on the framework on different parts but who don't cooperate at all and who cannot work together at all. We have alot code which is managed in separated repositories where different developers spent several years of development (including reverse engineering, hacking and so on) it's a shame that the whole project is stuck where it is. New developers who fundamentally want to change something are not welcome at all, even if they have valuable ideas. Some developers are also sick of contributing since the whole community is flawed at the moment. I propose a few ways to go * stopping that signed off by madness that every driver developer has to sign off changes which happened at the core which will definitelly never happen because people _do not like each other_. * change the maintainership and push it over to me, even if it sounds selfish at the moment _every_ code which provides additional features and where noone expects further improvements within the next few weeks (without throwing away alot of work or generating useless extra work by telling someone to rewrite the core of his work); everyone still can try to write better code - but then he _has to do it
Re: [linux-dvb] dst customization patchset
On 5/31/07, Uwe Bugla [EMAIL PROTECTED] wrote: Am Donnerstag, 31. Mai 2007 07:01 schrieb Bill Eldridge: timecop wrote: Guys, it's GPL code. Fork the project and stop your bitching. If you do a better job, people will use and contribute to your version. If you do a worse job, people will use and contribute to Manu's. Some will use and contribute to both. Life's good, eh? This is exactly why Linux is shit. You have 100s of forked projects because some guy named Uwe thought he could do better than some guy named Manu and now you have two projects to contribute to, both suck in various ways, of course some idiot is going to be backporting from one to another, introducing weird bugs, etc etc etc. Make a fucking decision and stick with it. Stop wasting everyone's time. It's no secret that current Linux-DVB/V4L/whatever system is a pile of steaming feces. Every one of you admitted to it on this list at some point in the past. So get to it, make a fucking decision, fire (loool) retards who are slowing the project down, and get shit moving. I vote for Uwe as Linux-DVB maintainer. Regards, tc I nominate Timecop to be maintainer/top cop to figure out which version sucks in which area and do his best to get the best approach used. Sometimes a good strong and outspoken manager is more important than technical prowess (and I have no idea as to your technical abilities, just saying it looks like a management issue). I am not a fan of strong men or strong managers of whatever kind. We in Germany have very bad experiences concerning this kind of human desire / call regarding our history. Instead there should be one responsible code reviewer for v4l stuff, and at least one responsible code reviewer for DVB stuff. This is a minimum adequate demand to make things work. Inactivity on future projects in connection with Nacks of activities to optimize the stock kernel are no fair play or helpful behaviour at all, but they are just counterproductive. Who likes small kings? Well, I do not! For Uwe, it's not that I don't want to understand anything - I just showed up 2 days ago and simply want a workable driver for my machine, and instead had to switch cards to something else. Usually I assume if the code was forked the fork would be somewhere else and you wouldn't be complaining to this list, but I understand there are different ways. (Samba did it this way for quite some time). Forking may be OK for different Linux distros. But v4l-DVB is not a distro, it should be a common project instead. What you find is some 20 developers with a multiplicity of repositories. You do not even know who is maintainer and who is not. What you also find is the blocking gesture of that person who once threw his hat into the ring wanting to become maintainer. As the whole situation is one big mess you do not even know whether becoming a maintainer or not is product of a democtratic vote. Above that there is no team structure at all, but instead there is a big chaos, mess. And if some code, may it be humble or mature, is not even pulled into the mm-tree (its basic role has always been testing, nothing else) I would call that a catastrophe. Uwe writes alot insulting crap (which is a fact), even if the DVB subsystem has no maintainer the code should be managed appropriately and stopping the development is no way to do it. At the moment we have __tonns of critical bugs__ in the drivers and the video4linux and dvb framework; both frameworks are incomplete and don't provide the necessary flexibility to support an infrastructure for devices which could already be supported at the moment. We have several (technical) good people which which work on the framework on different parts but who don't cooperate at all and who cannot work together at all. We have alot code which is managed in separated repositories where different developers spent several years of development (including reverse engineering, hacking and so on) it's a shame that the whole project is stuck where it is. New developers who fundamentally want to change something are not welcome at all, even if they have valuable ideas. Some developers are also sick of contributing since the whole community is flawed at the moment. I propose a few ways to go * stopping that signed off by madness that every driver developer has to sign off changes which happened at the core which will definitelly never happen because people _do not like each other_. * change the maintainership and push it over to me, even if it sounds selfish at the moment _every_ code which provides additional features and where noone expects further improvements within the next few weeks (without throwing away alot of work or generating useless extra work by telling someone to rewrite the core of his work); everyone still can try to write better code - but then he _has to do it completly_ and get in peace with the projects by supporting them to get further. The
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On 5/28/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: Em Seg, 2007-05-28 às 17:14 +0200, Markus Rechberger escreveu: > > > +/* > > > + * Bayer conversion > > > + */ > > > > We don't do format conversions in kernel. Instead, you should return a > > proper Bayer Fourcc format (like V4L2_PIX_FMT_SBGGR8). > > > > It's ok in his case since most userspace applications do not support > this format, it helps noone if there's a driver out there which isn't > supported by most userspace applications and I don't expect that all > applications will add a conversion for that format soon. > This would moreover raise the question about a userspace library, > though there are many more important issues which are outstanding and > which got smashed down. As Luca pointed, if we add conversion for one driver, we should add for the rest. Instead, it would be better if Jiri sends the decoding and the rescaling stuff as a patch to v4l2-apps/lib, starting the API decoding library. Once we have a library, we can ask the userspace developers to use it for the formats not recognized by their userspace apps. I think it would be better to evaluate existing solutions (eg. libpw). Instead starting another one (which would lack any design since I haven't seen any thread that was picking together requirements), improving that existing one might also be helpful for applications like ekiga. As for libpw it also supports colourspace conversion and software scaling, the used algorithms seem to need some improvement, but alot work has already been done there. Of course other libraries should also be taken into account, maybe someone knows something better which is more complete. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On 5/28/07, Luca Risolia <[EMAIL PROTECTED]> wrote: On Monday 28 May 2007 17:14:51 Markus Rechberger wrote: > On 5/28/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > We don't do format conversions in kernel. Instead, you should return a > > proper Bayer Fourcc format (like V4L2_PIX_FMT_SBGGR8). > > It's ok in his case since most userspace applications do not support > this format, it helps noone if there's a driver out there which isn't > supported by most userspace applications and I don't expect that all > applications will add a conversion for that format soon. > This would moreover raise the question about a userspace library, > though there are many more important issues which are outstanding and > which got smashed down. Markus, I do think the userspace library is THE real problem with the whole V4L subsystem. It's annoying to keep repeating why these convertions should be done outside the kernel, be them in a library or not. I deliberatly never implemented the above convertion in the drivers that I have been maintaing for years, since I had the idea that this approach whould have pushed the developers to write the _best_ algorithm by themselves. I still think it's the correct approach, but now I give up. Mauro, if you are planning to accept this BayerToSomething color convertion, be also prepared to accept the same convertion for other drivers in the kernel. Rules are made for everyone. Initially asking for help doesn't lead anywhere either because most people aren't skilled enough or have personal issues with helping out at linuxtv. I'm fine with the conversion, a valid point is scaling, this is something userspace can handle already. And as I mentioned there are more important issues out there which should be handled first, but they're greatly getting ignored again (just as usual, and this also takes regressions and current implementation bugs in account). Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On 5/24/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
On 5/24/07, Markus Rechberger <[EMAIL PROTECTED]> wrote:
> Hi Jiri,
>
> On 5/24/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
> > Well, no objections on v4l list, try to merge it. Any further comments
will
> > be
> > appreciated.
> >
> > --
> >
> > stk11xx, add a new webcam driver
> >
> > Cc: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
> > Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
> >
[...]
> > +/*
> > + * Bayer conversion
> > + */
> > +
> > +#define STK11XX_AVG2(x,y) (u8)(((int)x + (int)y) / 2)
> > +#define STK11XX_AVG4(a,b,c,d) (u8)(((int)a + (int)b + (int)c + (int)d)
/ 4)
> > +
> > +static void stk11xx_bayer_to_rgb(u8 *rgb, const u8 *bayer,
> > + const int width, const int height)
>
> hmm.. this is probably to support xawtv/tvtime?
> It would be better to do that in userspace, but the argument which
> seems to be against it is that userspace applications often don't
> support bayer.
Exactly. This would make the webcam driver unusable. Another one,
which awaits RGB is camstream, which also I use. After moving all
major used userspace apps to something like pwlib, this may be wiped
out.
> > +{
> > + unsigned int x, y, nwidth, nheight;
> > +
> > + nheight = height / factor;
> > + nwidth = width / factor;
> > +
> > + for (y = 0; y < nheight; y++) {
> > + for (x = 0; x < nwidth; x++) {
> > + /* R */
> > + out[y * nwidth * 3 + x * 3 + 0] =
> > + in[y * factor * width * 3 + x * factor * 3 +
0];
> > + /* G */
> > + out[y * nwidth * 3 + x * 3 + 1] =
> > + in[y * factor * width * 3 + x * factor * 3 +
1];
> > + /* B */
> > + out[y * nwidth * 3 + x * 3 + 2] =
> > + in[y * factor * width * 3 + x * factor * 3 +
2];
> > + }
> > + }
> > +}
> > +
> > +static void stk11xx_correct_brightness(u8 *rgb, unsigned int width,
> > + unsigned int height, int brightness)
> > +{
>
> same here, why do you want to have that in kernelspace?
not sure who from userspace can do this nowadays. Will check.
> > +/*
> > + * The configuration of device is composed of 12 steps.
> > + * This function is called by the initialization process.
> > + *
> > + * We don't know the meaning of these steps! We only replay the USB
log.
> > + */
> > +static int stk1135_configure_device(struct stk11xx *dev, int step)
> > +{
> > + int value;
> > +
> > + /* 0,1,2,3,4,5,6,7,8,9,
> > + 10, 11, 12, 13 */
> > +
> > + const u8 values_001B[] = {
> > + 0x0E, 0x03, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E,
0x07,
> > + 0x07, 0x07, 0x07, 0x07
> > + };
> > + const u8 values_001C[] = {
> > + 0x06, 0x02, 0x46, 0x46, 0x46, 0x46, 0x46, 0x46, 0x06,
0x06,
> > + 0x06, 0x06, 0x06, 0x07
> > + };
> > + const u8 values_0202[] = {
> > + 0x1E, 0x0A, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E,
0x1E,
> > + 0x1E, 0x1E, 0x1E, 0x1E
> > + };
> > + const u8 values_0110[] = {
> > + 0x07, 0x00, 0x00, 0x00, 0x00, 0x3E, 0x3E, 0x00, 0x04,
0x00,
> > + 0x00, 0x00, 0x00, 0x00
> > + };
> > + const u8 values_0112[] = {
> > + 0x07, 0x00, 0x00, 0x00, 0x00, 0x09, 0x09, 0x00, 0x04,
0x00,
> > + 0x00, 0x00, 0x00, 0x00
> > + };
> > + const u8 values_0114[] = {
> > + 0x87, 0x80, 0x80, 0x80, 0x80, 0xBE, 0xBE, 0x80, 0x84,
0x80,
> > + 0x80, 0x80, 0x80, 0x80
> > + };
> > + const u8 values_0116[] = {
> > + 0xE7, 0xE0, 0xE0, 0xE0, 0xE0, 0xE9, 0xE9, 0xE0, 0xE4,
0xE0,
> > + 0xE0, 0xE0, 0xE0, 0xE0
> > + };
> > + const u8 values_0100[] = {
> > + 0x20, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x23,
0x20,
> > + 0x20, 0x20, 0x20, 0x20
> > + };
> > +
> > + dev_dbg(>udev->dev, "stk1135_configure_device: %d\n", step);
> > +
> > + stk11xx_write_registry(dev, 0x, 0x0024);
> > + stk11xx_write_registry(dev, 0x0002, 0x0068);
> > + stk11xx_write_registry(dev, 0x0003, 0x0080);
> &g
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
id *fh, v4l2_std_id
> *a)
> +{
> + *a = V4L2_STD_UNKNOWN;
> + return 0;
> +}
> +
> +static int stk11xx_s_std(struct file *file, void *fh, v4l2_std_id *a)
> +{
> + return *a == V4L2_STD_UNKNOWN ? 0 : -EINVAL;
> +}
This raises an interesting discussion about video standards. I would,
instead, use V4L2_STD_ALL, since webcams are capable of properly
handling on 525 raw lines/60Hz based standards (those derived from
640x480 res) as well as 625 raw lines/50Hz based standards (those
derived from ITU-T CIF resolutions).
As reference, STD_ALL is defined as:
#define V4L2_STD_ALL(V4L2_STD_525_60|\
V4L2_STD_625_50)
---
Also, I noticed that several hexadecimal values are using uppercases.
The better is to convert all of them to lowercase, to keep the same
codingstyle as the other drivers.
--
Cheers,
Mauro
--
video4linux-list mailing list
Unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/video4linux-list
--
Markus Rechberger
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
values are using uppercases. The better is to convert all of them to lowercase, to keep the same codingstyle as the other drivers. -- Cheers, Mauro -- video4linux-list mailing list Unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/video4linux-list -- Markus Rechberger - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On 5/24/07, Jiri Slaby [EMAIL PROTECTED] wrote:
On 5/24/07, Markus Rechberger [EMAIL PROTECTED] wrote:
Hi Jiri,
On 5/24/07, Jiri Slaby [EMAIL PROTECTED] wrote:
Well, no objections on v4l list, try to merge it. Any further comments
will
be
appreciated.
--
stk11xx, add a new webcam driver
Cc: Mauro Carvalho Chehab [EMAIL PROTECTED]
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
[...]
+/*
+ * Bayer conversion
+ */
+
+#define STK11XX_AVG2(x,y) (u8)(((int)x + (int)y) / 2)
+#define STK11XX_AVG4(a,b,c,d) (u8)(((int)a + (int)b + (int)c + (int)d)
/ 4)
+
+static void stk11xx_bayer_to_rgb(u8 *rgb, const u8 *bayer,
+ const int width, const int height)
hmm.. this is probably to support xawtv/tvtime?
It would be better to do that in userspace, but the argument which
seems to be against it is that userspace applications often don't
support bayer.
Exactly. This would make the webcam driver unusable. Another one,
which awaits RGB is camstream, which also I use. After moving all
major used userspace apps to something like pwlib, this may be wiped
out.
+{
+ unsigned int x, y, nwidth, nheight;
+
+ nheight = height / factor;
+ nwidth = width / factor;
+
+ for (y = 0; y nheight; y++) {
+ for (x = 0; x nwidth; x++) {
+ /* R */
+ out[y * nwidth * 3 + x * 3 + 0] =
+ in[y * factor * width * 3 + x * factor * 3 +
0];
+ /* G */
+ out[y * nwidth * 3 + x * 3 + 1] =
+ in[y * factor * width * 3 + x * factor * 3 +
1];
+ /* B */
+ out[y * nwidth * 3 + x * 3 + 2] =
+ in[y * factor * width * 3 + x * factor * 3 +
2];
+ }
+ }
+}
+
+static void stk11xx_correct_brightness(u8 *rgb, unsigned int width,
+ unsigned int height, int brightness)
+{
same here, why do you want to have that in kernelspace?
not sure who from userspace can do this nowadays. Will check.
+/*
+ * The configuration of device is composed of 12 steps.
+ * This function is called by the initialization process.
+ *
+ * We don't know the meaning of these steps! We only replay the USB
log.
+ */
+static int stk1135_configure_device(struct stk11xx *dev, int step)
+{
+ int value;
+
+ /* 0,1,2,3,4,5,6,7,8,9,
+ 10, 11, 12, 13 */
+
+ const u8 values_001B[] = {
+ 0x0E, 0x03, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E, 0x0E,
0x07,
+ 0x07, 0x07, 0x07, 0x07
+ };
+ const u8 values_001C[] = {
+ 0x06, 0x02, 0x46, 0x46, 0x46, 0x46, 0x46, 0x46, 0x06,
0x06,
+ 0x06, 0x06, 0x06, 0x07
+ };
+ const u8 values_0202[] = {
+ 0x1E, 0x0A, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E, 0x1E,
0x1E,
+ 0x1E, 0x1E, 0x1E, 0x1E
+ };
+ const u8 values_0110[] = {
+ 0x07, 0x00, 0x00, 0x00, 0x00, 0x3E, 0x3E, 0x00, 0x04,
0x00,
+ 0x00, 0x00, 0x00, 0x00
+ };
+ const u8 values_0112[] = {
+ 0x07, 0x00, 0x00, 0x00, 0x00, 0x09, 0x09, 0x00, 0x04,
0x00,
+ 0x00, 0x00, 0x00, 0x00
+ };
+ const u8 values_0114[] = {
+ 0x87, 0x80, 0x80, 0x80, 0x80, 0xBE, 0xBE, 0x80, 0x84,
0x80,
+ 0x80, 0x80, 0x80, 0x80
+ };
+ const u8 values_0116[] = {
+ 0xE7, 0xE0, 0xE0, 0xE0, 0xE0, 0xE9, 0xE9, 0xE0, 0xE4,
0xE0,
+ 0xE0, 0xE0, 0xE0, 0xE0
+ };
+ const u8 values_0100[] = {
+ 0x20, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x23,
0x20,
+ 0x20, 0x20, 0x20, 0x20
+ };
+
+ dev_dbg(dev-udev-dev, stk1135_configure_device: %d\n, step);
+
+ stk11xx_write_registry(dev, 0x, 0x0024);
+ stk11xx_write_registry(dev, 0x0002, 0x0068);
+ stk11xx_write_registry(dev, 0x0003, 0x0080);
+ stk11xx_write_registry(dev, 0x0005, 0x);
+
+ stk11xx_write_registry(dev, 0x0007, 0x0003);
+ stk11xx_write_registry(dev, 0x000d, 0x);
+ stk11xx_write_registry(dev, 0x000f, 0x0002);
+ stk11xx_write_registry(dev, 0x0300, 0x0012);
+ stk11xx_write_registry(dev, 0x0350, 0x0041);
+
+ stk11xx_write_registry(dev, 0x0351, 0x);
+ stk11xx_write_registry(dev, 0x0352, 0x);
+ stk11xx_write_registry(dev, 0x0353, 0x);
+ stk11xx_write_registry(dev, 0x0018, 0x0010);
+ stk11xx_write_registry(dev, 0x0019, 0x);
+
+ stk11xx_write_registry(dev, 0x001b, values_001B[step]);
+ stk11xx_write_registry(dev, 0x001c, values_001C[step]);
+ stk11xx_write_registry(dev, 0x0300, 0x0080);
+ stk11xx_write_registry(dev, 0x001a, 0x0004);
+ stk11xx_write_registry(dev, 0x0202
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On 5/28/07, Luca Risolia [EMAIL PROTECTED] wrote: On Monday 28 May 2007 17:14:51 Markus Rechberger wrote: On 5/28/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: We don't do format conversions in kernel. Instead, you should return a proper Bayer Fourcc format (like V4L2_PIX_FMT_SBGGR8). It's ok in his case since most userspace applications do not support this format, it helps noone if there's a driver out there which isn't supported by most userspace applications and I don't expect that all applications will add a conversion for that format soon. This would moreover raise the question about a userspace library, though there are many more important issues which are outstanding and which got smashed down. Markus, I do think the userspace library is THE real problem with the whole V4L subsystem. It's annoying to keep repeating why these convertions should be done outside the kernel, be them in a library or not. I deliberatly never implemented the above convertion in the drivers that I have been maintaing for years, since I had the idea that this approach whould have pushed the developers to write the _best_ algorithm by themselves. I still think it's the correct approach, but now I give up. Mauro, if you are planning to accept this BayerToSomething color convertion, be also prepared to accept the same convertion for other drivers in the kernel. Rules are made for everyone. Initially asking for help doesn't lead anywhere either because most people aren't skilled enough or have personal issues with helping out at linuxtv. I'm fine with the conversion, a valid point is scaling, this is something userspace can handle already. And as I mentioned there are more important issues out there which should be handled first, but they're greatly getting ignored again (just as usual, and this also takes regressions and current implementation bugs in account). Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On 5/28/07, Mauro Carvalho Chehab [EMAIL PROTECTED] wrote: Em Seg, 2007-05-28 às 17:14 +0200, Markus Rechberger escreveu: +/* + * Bayer conversion + */ We don't do format conversions in kernel. Instead, you should return a proper Bayer Fourcc format (like V4L2_PIX_FMT_SBGGR8). It's ok in his case since most userspace applications do not support this format, it helps noone if there's a driver out there which isn't supported by most userspace applications and I don't expect that all applications will add a conversion for that format soon. This would moreover raise the question about a userspace library, though there are many more important issues which are outstanding and which got smashed down. As Luca pointed, if we add conversion for one driver, we should add for the rest. Instead, it would be better if Jiri sends the decoding and the rescaling stuff as a patch to v4l2-apps/lib, starting the API decoding library. Once we have a library, we can ask the userspace developers to use it for the formats not recognized by their userspace apps. I think it would be better to evaluate existing solutions (eg. libpw). Instead starting another one (which would lack any design since I haven't seen any thread that was picking together requirements), improving that existing one might also be helpful for applications like ekiga. As for libpw it also supports colourspace conversion and software scaling, the used algorithms seem to need some improvement, but alot work has already been done there. Of course other libraries should also be taken into account, maybe someone knows something better which is more complete. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] em28xx and ivtv should depend on PCI
On 5/16/07, Al Viro <[EMAIL PROTECTED]> wrote: On Wed, May 16, 2007 at 03:25:23AM +0400, Manu Abraham wrote: > Al Viro wrote: > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> > > --- > > drivers/media/video/em28xx/Kconfig |2 +- > > drivers/media/video/ivtv/Kconfig |2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/media/video/em28xx/Kconfig b/drivers/media/video/em28xx/Kconfig > > index 3823b62..2c450bd 100644 > > --- a/drivers/media/video/em28xx/Kconfig > > +++ b/drivers/media/video/em28xx/Kconfig > > @@ -1,6 +1,6 @@ > > config VIDEO_EM28XX > > tristate "Empia EM2800/2820/2840 USB video capture support" > > - depends on VIDEO_V4L1 && I2C > > + depends on VIDEO_V4L1 && I2C && PCI > > Err .. why would a USB device need to be depend on PCI ? Because video-buf.c does. And VIDEO_EM28XX selects it. the em28xx does not rely on video-buf, this seems to be a dependency derived from another dependency. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] em28xx and ivtv should depend on PCI
On 5/16/07, Al Viro [EMAIL PROTECTED] wrote: On Wed, May 16, 2007 at 03:25:23AM +0400, Manu Abraham wrote: Al Viro wrote: Signed-off-by: Al Viro [EMAIL PROTECTED] --- drivers/media/video/em28xx/Kconfig |2 +- drivers/media/video/ivtv/Kconfig |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/em28xx/Kconfig b/drivers/media/video/em28xx/Kconfig index 3823b62..2c450bd 100644 --- a/drivers/media/video/em28xx/Kconfig +++ b/drivers/media/video/em28xx/Kconfig @@ -1,6 +1,6 @@ config VIDEO_EM28XX tristate Empia EM2800/2820/2840 USB video capture support - depends on VIDEO_V4L1 I2C + depends on VIDEO_V4L1 I2C PCI Err .. why would a USB device need to be depend on PCI ? Because video-buf.c does. And VIDEO_EM28XX selects it. the em28xx does not rely on video-buf, this seems to be a dependency derived from another dependency. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/4/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Markus Rechberger wrote: > I mean the mail from Helge Hafting (thread [linux-dvb] Critical > points about kernel 2.6.21 and pseudo-authorities) at the very first > beginning. > I am replying to this mail, just because someone's spreading lies all around. On the mentioned thread, what i wrote (and that was the only mail from my side): There is a saying: "He who lives by the sword, dies by the sword." And what issues are outstanding of these discussions? I went over it and it just shows up that there have been communication problems in 2005. We now have open issues with several device drivers and that's what we should focus at. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Markus Rechberger wrote: > On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: >> Mauro Carvalho Chehab wrote: >> > Enough. Let's stop arguing non technical issues. >> > >> > If either one of you have any technical argue against the Trent's >> > patches, please point where the fix is wrong. Otherwise, if you wish, >> > you may send an acked-by agreeing with the fix. >> > >> >> Why don't you stop this childish behaviour ? >> >> After explaining to you the reasons in the previous mail: >> being the author and maintainer of dst/dst_ca and maintainer of >> dvb-bt8xx, i NACK this change >> >> (1) You aren't DVB maintainer > > I've seen that too often already, now we could point to a mail someone > sent to Uwe regarding maintainership. FYI, I have never written to Uwe regarding any sort of maintainership. You seem to be quite up with an overdose of drugs I mean the mail from Helge Hafting (thread [linux-dvb] Critical points about kernel 2.6.21 and pseudo-authorities) at the very first beginning. From 2005/09/13 - 2007/05/03 (till date) there have been 15 mails from my side to Uwe, none of which has a topic whatsoever you say. Only the first mail was a private mail and that is CC'd to Johannes as well. Firstly you seem to play politics by getting Uwe to flame me, then when it backfired, you are trying to play tricks with the rest of the community as well, by spreading nonsense statements. I sent several comments to Uwe to stop flaming, Trent was in the CC sometimes I never wrote that he should flame on anyone. I can simply forward you all mails I sent to Uwe there's not one bad mail. My point is moreover to get that issue sorted out by either accepting his "proposal" or stating out why not to add it (and there must be a reason behind it, and no mail which is 2 years old, or explaining what the device is, again it got explained what's required from you) seems like your response is based on that misunderstood sentence, sorry for not beeing clear enough. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Mauro Carvalho Chehab wrote: > Enough. Let's stop arguing non technical issues. > > If either one of you have any technical argue against the Trent's > patches, please point where the fix is wrong. Otherwise, if you wish, > you may send an acked-by agreeing with the fix. > Why don't you stop this childish behaviour ? After explaining to you the reasons in the previous mail: being the author and maintainer of dst/dst_ca and maintainer of dvb-bt8xx, i NACK this change (1) You aren't DVB maintainer I've seen that too often already, now we could point to a mail someone sent to Uwe regarding maintainership. You wouldn't be better at the moment, Mauro at least aknowlidges the work of others. I don't know what problems you have with Mauro I heard that there have been some mails between you and some other developers as well and the whole situation is just terrible. If you want to change the whole situation, think about what you can do for improving the whole situation even if it means that you have to work with people you don't like. (2) one shouldn't make such judgement calls on somebody else's driver unless it falls within your own maintainership I wrote what I'd like to see from you, it would be a start if you could work on that first. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, VDR User <[EMAIL PROTECTED]> wrote: STOP FIGHTING ALL THE DAMN TIME! From an outsiders perspective there is a lot of unnecessary & childish behavior going on at the expense of good ideas and coding. It seems as though the Markus/Mauro team will go against anything Manu says simply because Manu is the one saying it. From what I've seen he is very knowledgeable and a good coder. From his technical knowledge he's as ok as many other developers are who have been involved for several years now. He tries to become the DVB Maintainer, from my side I wrote he first has to prove it for at least a half year that he supports the project and helps out people. Till now I haven't seen any response to the technical questions I had. And telling that the politicians here are so bad to everyone who'd like to help finding a solution for it is definitelly the wrong way either, so other people will not even be able to get an insight into the whole story. Manu is an asset and all the personal bickering and immature attitudes being displayed do not benefit any projects in any way. If you can't get past your personal problems then step down until you can learn to be unbiased and start treating these projects with some sanity/common sense. When you drive good people away, guess who loses? EVERYONE. Grow up and quit letting your personal feelings interfere in places it should not be in the first place!! Since all these issues have been there for more than one year now it either would be better that he leaves the project OR starts to seriously discuss the issues and how it would be best to solve them (and in a way where everyone agrees here) He just nacks the changes proposed by Uwe which got implemented by Trent and now Mauro wants to get it done somehow, either in a way explaining what he wants to do with it in future or changing these few lines NOW. I couldn't care less what will happen with his driver, the whole story gets blown up just because one party here doesn't understand that the other one doesn't know what he wants to do (and if he seriously will do something) I apologize for going off-topic but this is relevant to dvb dev as a whole. Things have degraded to a ridiculous state and it's time to knock it off. Enough is enough. The dvb projects should NOT have to suffer simply because people have lost the decency to act civil towards one another! Lastly, the opinions I'm sharing in this post are held by many others, although they hesitate to do the same publicly for certain reasons. I fully agree with that. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Markus Rechberger wrote: > Manu, > > to me it looks like your attitude is not acceptable here, I sent > several mails already which you just use to ignore. You very well know the reason why i am ignoring your mails. You just tend to flame people for nothing. I tend to ignore the flamers. You should stop to rely on the history, since such a flame needs at least 2 parties and back then you were also involved. There's nothing else to say about that. > If you don't change that attitude immediatelly I'd really wish to get > you banned of this community until you're open for discussions. > > http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html > > there's a bugreport and you fully ignore it, and you blame it on the > "politicians" here, telling me that there are mails out there > somewhere shows that you're not interested in getting forward. > That bug report very well proves my point. Well it would be nice if you could answer the question in that mail then, I don't see any reason why you shouldn't answer it. It's just a guess, but it seems like that you had a problem with other developers at that part and it seems like it didn't get to an end (probably because both parties didn't agree with each other) Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Uwe Bugla wrote: > Hi Manu, > > But it would be an acceptable compromise FOR NOW, wouldn't it? The reason is i do not wish to make changes to it, till i can fix it. It is indeed hard to fix things that support a lot of devices, with different issues. There are enough of issues in there. You can look at all those frontend not found issues on the DVB ML. The people who make all these noise, do nothing but just play politics. Just do a search on the linux-dvb ML at gmane.org. You can easily find them. Manu, to me it looks like your attitude is not acceptable here, I sent several mails already which you just use to ignore. If you don't change that attitude immediatelly I'd really wish to get you banned of this community until you're open for discussions. http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html there's a bugreport and you fully ignore it, and you blame it on the "politicians" here, telling me that there are mails out there somewhere shows that you're not interested in getting forward. I'm waiting for your response here. Markus > Waiting for your link meanwhile to download that hopeful project... http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 -- Markus Rechberger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pcmcia/pccard deadlock fix
Andrew Morton wrote:
On Tue, 20 Feb 2007 16:08:11 +0100
20 Feb was a long time ago, sorry. I was hoping to feed the pcmcia patches
through Dominik but I think he's busy with exams or such. So I get to
pretend to be pcmcia maintainer.
"Markus Rechberger" <[EMAIL PROTECTED]> wrote:
following patch prevents a mutex/semaphore deadlock within the pcmcia
framework when ejecting devices multiple times using pccardctl eject.
For some more details see:
http://lkml.org/lkml/2007/2/19/58
Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]>
--
Markus Rechberger
Operating System Research Center
AMD Saxony LLC & Co. KG
[pcmcia-pccard-deadlock-fix.diff text/plain (757B)]
index ac00424..c02bf0d 100644
--- a/drivers/pcmcia/cs.c
+++ b/drivers/pcmcia/cs.c
@@ -856,7 +856,8 @@ int pcmcia_eject_card(struct pcmcia_socket *skt)
cs_dbg(skt, 1, "user eject request\n");
- mutex_lock(>skt_mutex);
+ if (!mutex_trylock(>skt_mutex))
+ return -EAGAIN;
do {
if (!(skt->state & SOCKET_PRESENT)) {
ret = -ENODEV;
index 18e111e..b9d3440 100644
--- a/drivers/pcmcia/ds.c
+++ b/drivers/pcmcia/ds.c
@@ -1100,7 +1100,9 @@ static ssize_t pcmcia_store_allow_func_id_match(struct
device *dev,
if (!count)
return -EINVAL;
- mutex_lock(_dev->socket->skt_mutex);
+ if (!mutex_trylock(_dev->socket->skt_mutex))
+ return -EAGAIN;
+
p_dev->allow_func_id_match = 1;
mutex_unlock(_dev->socket->skt_mutex);
This is a pretty sad-looking solution. Does it not mean that sometimes
user-initiated actions will mysteriously fail?
The userspace application should return the appropriate error then. It
can really happen any time when someone tries to eject the pcmcia device
(any time as within 1 minute - never in a normal scenario)
Are you able to provide a more detailed description of why/how the deadlock
actually occurs so that perhaps a more robust fix can be implemented?
There's a description about it in following Email:
http://lkml.org/lkml/2007/2/19/58
Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pcmcia/pccard deadlock fix
Andrew Morton wrote:
On Tue, 20 Feb 2007 16:08:11 +0100
20 Feb was a long time ago, sorry. I was hoping to feed the pcmcia patches
through Dominik but I think he's busy with exams or such. So I get to
pretend to be pcmcia maintainer.
Markus Rechberger [EMAIL PROTECTED] wrote:
following patch prevents a mutex/semaphore deadlock within the pcmcia
framework when ejecting devices multiple times using pccardctl eject.
For some more details see:
http://lkml.org/lkml/2007/2/19/58
Signed-off-by: Markus Rechberger [EMAIL PROTECTED]
--
Markus Rechberger
Operating System Research Center
AMD Saxony LLC Co. KG
[pcmcia-pccard-deadlock-fix.diff text/plain (757B)]
index ac00424..c02bf0d 100644
--- a/drivers/pcmcia/cs.c
+++ b/drivers/pcmcia/cs.c
@@ -856,7 +856,8 @@ int pcmcia_eject_card(struct pcmcia_socket *skt)
cs_dbg(skt, 1, user eject request\n);
- mutex_lock(skt-skt_mutex);
+ if (!mutex_trylock(skt-skt_mutex))
+ return -EAGAIN;
do {
if (!(skt-state SOCKET_PRESENT)) {
ret = -ENODEV;
index 18e111e..b9d3440 100644
--- a/drivers/pcmcia/ds.c
+++ b/drivers/pcmcia/ds.c
@@ -1100,7 +1100,9 @@ static ssize_t pcmcia_store_allow_func_id_match(struct
device *dev,
if (!count)
return -EINVAL;
- mutex_lock(p_dev-socket-skt_mutex);
+ if (!mutex_trylock(p_dev-socket-skt_mutex))
+ return -EAGAIN;
+
p_dev-allow_func_id_match = 1;
mutex_unlock(p_dev-socket-skt_mutex);
This is a pretty sad-looking solution. Does it not mean that sometimes
user-initiated actions will mysteriously fail?
The userspace application should return the appropriate error then. It
can really happen any time when someone tries to eject the pcmcia device
(any time as within 1 minute - never in a normal scenario)
Are you able to provide a more detailed description of why/how the deadlock
actually occurs so that perhaps a more robust fix can be implemented?
There's a description about it in following Email:
http://lkml.org/lkml/2007/2/19/58
Markus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham [EMAIL PROTECTED] wrote: Uwe Bugla wrote: Hi Manu, But it would be an acceptable compromise FOR NOW, wouldn't it? The reason is i do not wish to make changes to it, till i can fix it. It is indeed hard to fix things that support a lot of devices, with different issues. There are enough of issues in there. You can look at all those frontend not found issues on the DVB ML. The people who make all these noise, do nothing but just play politics. Just do a search on the linux-dvb ML at gmane.org. You can easily find them. Manu, to me it looks like your attitude is not acceptable here, I sent several mails already which you just use to ignore. If you don't change that attitude immediatelly I'd really wish to get you banned of this community until you're open for discussions. http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html there's a bugreport and you fully ignore it, and you blame it on the politicians here, telling me that there are mails out there somewhere shows that you're not interested in getting forward. I'm waiting for your response here. Markus Waiting for your link meanwhile to download that hopeful project... http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/cx878_41?ca=43abfe89c2c9;type=bz2 -- Markus Rechberger - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham [EMAIL PROTECTED] wrote: Markus Rechberger wrote: Manu, to me it looks like your attitude is not acceptable here, I sent several mails already which you just use to ignore. You very well know the reason why i am ignoring your mails. You just tend to flame people for nothing. I tend to ignore the flamers. You should stop to rely on the history, since such a flame needs at least 2 parties and back then you were also involved. There's nothing else to say about that. If you don't change that attitude immediatelly I'd really wish to get you banned of this community until you're open for discussions. http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg22943.html there's a bugreport and you fully ignore it, and you blame it on the politicians here, telling me that there are mails out there somewhere shows that you're not interested in getting forward. That bug report very well proves my point. Well it would be nice if you could answer the question in that mail then, I don't see any reason why you shouldn't answer it. It's just a guess, but it seems like that you had a problem with other developers at that part and it seems like it didn't get to an end (probably because both parties didn't agree with each other) Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, VDR User [EMAIL PROTECTED] wrote: STOP FIGHTING ALL THE DAMN TIME! From an outsiders perspective there is a lot of unnecessary childish behavior going on at the expense of good ideas and coding. It seems as though the Markus/Mauro team will go against anything Manu says simply because Manu is the one saying it. From what I've seen he is very knowledgeable and a good coder. From his technical knowledge he's as ok as many other developers are who have been involved for several years now. He tries to become the DVB Maintainer, from my side I wrote he first has to prove it for at least a half year that he supports the project and helps out people. Till now I haven't seen any response to the technical questions I had. And telling that the politicians here are so bad to everyone who'd like to help finding a solution for it is definitelly the wrong way either, so other people will not even be able to get an insight into the whole story. Manu is an asset and all the personal bickering and immature attitudes being displayed do not benefit any projects in any way. If you can't get past your personal problems then step down until you can learn to be unbiased and start treating these projects with some sanity/common sense. When you drive good people away, guess who loses? EVERYONE. Grow up and quit letting your personal feelings interfere in places it should not be in the first place!! Since all these issues have been there for more than one year now it either would be better that he leaves the project OR starts to seriously discuss the issues and how it would be best to solve them (and in a way where everyone agrees here) He just nacks the changes proposed by Uwe which got implemented by Trent and now Mauro wants to get it done somehow, either in a way explaining what he wants to do with it in future or changing these few lines NOW. I couldn't care less what will happen with his driver, the whole story gets blown up just because one party here doesn't understand that the other one doesn't know what he wants to do (and if he seriously will do something) I apologize for going off-topic but this is relevant to dvb dev as a whole. Things have degraded to a ridiculous state and it's time to knock it off. Enough is enough. The dvb projects should NOT have to suffer simply because people have lost the decency to act civil towards one another! Lastly, the opinions I'm sharing in this post are held by many others, although they hesitate to do the same publicly for certain reasons. I fully agree with that. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham [EMAIL PROTECTED] wrote: Mauro Carvalho Chehab wrote: Enough. Let's stop arguing non technical issues. If either one of you have any technical argue against the Trent's patches, please point where the fix is wrong. Otherwise, if you wish, you may send an acked-by agreeing with the fix. Why don't you stop this childish behaviour ? After explaining to you the reasons in the previous mail: being the author and maintainer of dst/dst_ca and maintainer of dvb-bt8xx, i NACK this change (1) You aren't DVB maintainer I've seen that too often already, now we could point to a mail someone sent to Uwe regarding maintainership. You wouldn't be better at the moment, Mauro at least aknowlidges the work of others. I don't know what problems you have with Mauro I heard that there have been some mails between you and some other developers as well and the whole situation is just terrible. If you want to change the whole situation, think about what you can do for improving the whole situation even if it means that you have to work with people you don't like. (2) one shouldn't make such judgement calls on somebody else's driver unless it falls within your own maintainership I wrote what I'd like to see from you, it would be a start if you could work on that first. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/3/07, Manu Abraham [EMAIL PROTECTED] wrote: Markus Rechberger wrote: On 5/3/07, Manu Abraham [EMAIL PROTECTED] wrote: Mauro Carvalho Chehab wrote: Enough. Let's stop arguing non technical issues. If either one of you have any technical argue against the Trent's patches, please point where the fix is wrong. Otherwise, if you wish, you may send an acked-by agreeing with the fix. Why don't you stop this childish behaviour ? After explaining to you the reasons in the previous mail: being the author and maintainer of dst/dst_ca and maintainer of dvb-bt8xx, i NACK this change (1) You aren't DVB maintainer I've seen that too often already, now we could point to a mail someone sent to Uwe regarding maintainership. FYI, I have never written to Uwe regarding any sort of maintainership. You seem to be quite up with an overdose of drugs I mean the mail from Helge Hafting (thread [linux-dvb] Critical points about kernel 2.6.21 and pseudo-authorities) at the very first beginning. From 2005/09/13 - 2007/05/03 (till date) there have been 15 mails from my side to Uwe, none of which has a topic whatsoever you say. Only the first mail was a private mail and that is CC'd to Johannes as well. Firstly you seem to play politics by getting Uwe to flame me, then when it backfired, you are trying to play tricks with the rest of the community as well, by spreading nonsense statements. I sent several comments to Uwe to stop flaming, Trent was in the CC sometimes I never wrote that he should flame on anyone. I can simply forward you all mails I sent to Uwe there's not one bad mail. My point is moreover to get that issue sorted out by either accepting his proposal or stating out why not to add it (and there must be a reason behind it, and no mail which is 2 years old, or explaining what the device is, again it got explained what's required from you) seems like your response is based on that misunderstood sentence, sorry for not beeing clear enough. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/4/07, Manu Abraham [EMAIL PROTECTED] wrote: Markus Rechberger wrote: I mean the mail from Helge Hafting (thread [linux-dvb] Critical points about kernel 2.6.21 and pseudo-authorities) at the very first beginning. I am replying to this mail, just because someone's spreading lies all around. On the mentioned thread, what i wrote (and that was the only mail from my side): There is a saying: He who lives by the sword, dies by the sword. And what issues are outstanding of these discussions? I went over it and it just shows up that there have been communication problems in 2005. We now have open issues with several device drivers and that's what we should focus at. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/2/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Uwe Bugla wrote: > Original-Nachricht > Datum: Wed, 02 May 2007 17:30:32 +0400 > Von: Manu Abraham <[EMAIL PROTECTED]> > An: Trent Piepho <[EMAIL PROTECTED]> > CC: Simon Arlott <[EMAIL PROTECTED]>, Linux Kernel Mailing list , [EMAIL PROTECTED], Jan Engelhardt <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], Linux DVB <[EMAIL PROTECTED]> > Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Criticalpoints about ...) > >> Trent Piepho wrote: >>> On Tue, 1 May 2007, Simon Arlott wrote: >>>> On 30/04/07 22:17, Markus Rechberger wrote: >>>>> From my side I do not see any problem with that patch, if someone else >>>>> has a problem with it please state out the reason. >>>> I have no problem with the patch since it has nothing to do with my DVB >>>> card but you're only encouraging Uwe to be abusive since it seems to >>>> help get him what he wants: >>> I've been aware of the problem with dst not fully using the dvb >> customization >>> systems(*) for a long time. It came up when dvb_attach() et al were >> first >>> being integrated, well before any rejected patches or strongly worded >> emails >>> or whatever from certain people that I'm aware of. >>> >> Well, your understanding of the device is quite limited and hence your >> comments and patches. >> >> The DST as it refers to is an embedded system a x86 Compatible RISC core >> [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own >> IO and 2 DMA channels. What we have is a PQFP device >> >> This is the case in most cases. On some cheaper cards the embedded >> system is replaced by an 8 bit host microcontroller, to cut down costs >> where all the features are not required for a specific model >> >> Additionally this embedded system has a fast shovelling engine for the >> MPEG2 TS routing in between the >> This embedded system is connected to an actual >> (1) DVB frontend [2] >> (2) DVB CA interface [3] >> (3) Analog tuner >> (4) Audio interfaces >> >> These features are not the characteristics of a DVB Frontend. Here there >> is a DVB frontend like the normal ones which is hidden behind another >> pseudo bridge (So you don't have *any* access to the frontend at large) >> >> It is not necessary that *all* the dst cards (there are around ~15 >> different variants of the same) do have the very same feature set. >> >> It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In >> fact it is a combo driver supporting the entire devices using a common >> command set >> >> In such a case it has more characteristics of the PCI bridge and in fact >> heavily tied to it and has it's own advantages. >> >>> I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and >> since >>> I already know about the issues here, I felt I should post a patch for >> them >>> any other reasonable developers who might spend time on this. >>> >> I would think that it would be *extremely* rude for a person to send in >> patches for a device that which you don't understand at all, when it is >> for limiting the capability of the said device > > Hi Manu, > now if this is your evalution about it all, then let me tell you that I feel deeply sorry about it. > > Fact is: > Noone ever intended to send in patches limiting the capability of the said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others never did... > > Instead of this we all have very different knowledge and understanding levels, with you obviously being the one with the most elaborate and sophisticated level. > > So please why, instead of marking other people as "rude" whose solutions you do not appreciate at all, don't you just pick up the pratical proposals of other persons, even if you do not like them for some reasons, and at least try to raise them up to a far more better level? > Thus you definitely could avoid a lots of flaming, misunderstanding, and other counterproductive things to happen... > And this would conform to practising the synergetic principle, wouldn't it? > > Just one hint to help you: I remember a mail from Johannes in which he told me that you started up this whole development thing from a zero level some two or three years ago. And Johannes not forgot to state that in the beginning you were nothing but nerving... (now add a smiley behind this, please, I'd deeply appreciate you to do). > > Above that: > 1. Ta
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/2/07, Manu Abraham [EMAIL PROTECTED] wrote: Uwe Bugla wrote: Original-Nachricht Datum: Wed, 02 May 2007 17:30:32 +0400 Von: Manu Abraham [EMAIL PROTECTED] An: Trent Piepho [EMAIL PROTECTED] CC: Simon Arlott [EMAIL PROTECTED], Linux Kernel Mailing list linux-kernel@vger.kernel.org, [EMAIL PROTECTED], Jan Engelhardt [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Linux DVB [EMAIL PROTECTED] Betreff: Re: [linux-dvb] DST/BT878 module customization (.. was: Criticalpoints about ...) Trent Piepho wrote: On Tue, 1 May 2007, Simon Arlott wrote: On 30/04/07 22:17, Markus Rechberger wrote: From my side I do not see any problem with that patch, if someone else has a problem with it please state out the reason. I have no problem with the patch since it has nothing to do with my DVB card but you're only encouraging Uwe to be abusive since it seems to help get him what he wants: I've been aware of the problem with dst not fully using the dvb customization systems(*) for a long time. It came up when dvb_attach() et al were first being integrated, well before any rejected patches or strongly worded emails or whatever from certain people that I'm aware of. Well, your understanding of the device is quite limited and hence your comments and patches. The DST as it refers to is an embedded system a x86 Compatible RISC core [1] running at 20Mhz with 4MB Flash and 1MB RAM. The device has it's own IO and 2 DMA channels. What we have is a PQFP device This is the case in most cases. On some cheaper cards the embedded system is replaced by an 8 bit host microcontroller, to cut down costs where all the features are not required for a specific model Additionally this embedded system has a fast shovelling engine for the MPEG2 TS routing in between the This embedded system is connected to an actual (1) DVB frontend [2] (2) DVB CA interface [3] (3) Analog tuner (4) Audio interfaces These features are not the characteristics of a DVB Frontend. Here there is a DVB frontend like the normal ones which is hidden behind another pseudo bridge (So you don't have *any* access to the frontend at large) It is not necessary that *all* the dst cards (there are around ~15 different variants of the same) do have the very same feature set. It does support DVB-S/DSS/DVB-C/DVB-T/ATSC depending on the cards. In fact it is a combo driver supporting the entire devices using a common command set In such a case it has more characteristics of the PCI bridge and in fact heavily tied to it and has it's own advantages. I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and since I already know about the issues here, I felt I should post a patch for them any other reasonable developers who might spend time on this. I would think that it would be *extremely* rude for a person to send in patches for a device that which you don't understand at all, when it is for limiting the capability of the said device Hi Manu, now if this is your evalution about it all, then let me tell you that I feel deeply sorry about it. Fact is: Noone ever intended to send in patches limiting the capability of the said device (DST): I never did, Trent never did, Markus, Mauro, Andrew and others never did... Instead of this we all have very different knowledge and understanding levels, with you obviously being the one with the most elaborate and sophisticated level. So please why, instead of marking other people as rude whose solutions you do not appreciate at all, don't you just pick up the pratical proposals of other persons, even if you do not like them for some reasons, and at least try to raise them up to a far more better level? Thus you definitely could avoid a lots of flaming, misunderstanding, and other counterproductive things to happen... And this would conform to practising the synergetic principle, wouldn't it? Just one hint to help you: I remember a mail from Johannes in which he told me that you started up this whole development thing from a zero level some two or three years ago. And Johannes not forgot to state that in the beginning you were nothing but nerving... (now add a smiley behind this, please, I'd deeply appreciate you to do). Above that: 1. Taking part in testing the mm-tree and eliminating horrible bugs in it I never experienced but positive and warm compromise solutions in the end. Experiencing this is highly enlarging one's own personality. 2. If you start up at zero (like you did once too - see above and ask Johannes if you do not remember at all) it is no good start at all if your humble effort is being thrown off after the first or second reject. That's highly discouraging, and if it happens very often the bad experience remains in one's own subjective perception filter. i did really start very small during those early stages. Johannes did help me a lot in many areas, he gave me a lot of valuable information
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/1/07, Simon Arlott <[EMAIL PROTECTED]> wrote: On 30/04/07 22:17, Markus Rechberger wrote: > Trent Piepho wrote another patch for it, it just completes Uwe's patch > in the end. > From my side I do not see any problem with that patch, if someone else > has a problem with it please state out the reason. I have no problem with the patch since it has nothing to do with my DVB card but you're only encouraging Uwe to be abusive since it seems to help get him what he wants: On 01/05/07 00:05, Uwe Bugla wrote: > Piepho, you are a devil, and your links do not work at all! > Uwe On 01/05/07 00:40, Uwe Bugla wrote: > Go to hell, Manuel Abraham, and do not return at all to absolutely no thinkable condition at all, and never come back to this place once more again > Just goto hell, you goddamn deeply asocial miserable sonofabitch!! > > Uwe > On 4/30/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: >> it's enough, I told him that I'll look at it and try to get some other >> people involved if it really breaks something it should get stated >> out; and I'll refuse any further help if he starts to write any more >> abusive mail. It's not working. Patches should still be applied on the basis of what they do and how, not why they were made, of course. this patch was written by Trent, and it seems like he already had that idea earlier too. I really don't care if that patch goes in or not in the end, there's just no need to flame around for it. The only reason I see is that it's not needed to link it statically against the bt878 module and there isn't even much work to do. Uwe's Makefile patch worked as expected, but it wasn't clean/complete enough that was a reason to not include it. Now with Trent's patch I don't see that as a valid argument against it anymore. And the email from Manu claiming that it generates alot work (which is btw. 2 years old) doesn't seem to be valid either. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On 5/1/07, Simon Arlott [EMAIL PROTECTED] wrote: On 30/04/07 22:17, Markus Rechberger wrote: Trent Piepho wrote another patch for it, it just completes Uwe's patch in the end. From my side I do not see any problem with that patch, if someone else has a problem with it please state out the reason. I have no problem with the patch since it has nothing to do with my DVB card but you're only encouraging Uwe to be abusive since it seems to help get him what he wants: On 01/05/07 00:05, Uwe Bugla wrote: Piepho, you are a devil, and your links do not work at all! Uwe On 01/05/07 00:40, Uwe Bugla wrote: Go to hell, Manuel Abraham, and do not return at all to absolutely no thinkable condition at all, and never come back to this place once more again Just goto hell, you goddamn deeply asocial miserable sonofabitch!! Uwe On 4/30/07, Markus Rechberger [EMAIL PROTECTED] wrote: it's enough, I told him that I'll look at it and try to get some other people involved if it really breaks something it should get stated out; and I'll refuse any further help if he starts to write any more abusive mail. It's not working. Patches should still be applied on the basis of what they do and how, not why they were made, of course. this patch was written by Trent, and it seems like he already had that idea earlier too. I really don't care if that patch goes in or not in the end, there's just no need to flame around for it. The only reason I see is that it's not needed to link it statically against the bt878 module and there isn't even much work to do. Uwe's Makefile patch worked as expected, but it wasn't clean/complete enough that was a reason to not include it. Now with Trent's patch I don't see that as a valid argument against it anymore. And the email from Manu claiming that it generates alot work (which is btw. 2 years old) doesn't seem to be valid either. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
where I can get that complete list of cards corresponding to that standard, and I'll instantly sit down and write a patch to improve documentation. But before I even think about doing that I appreciate you to do your homework: a. readd my name (I didn't delete it, so I won't do the same job again, not for sync reasons, and not for reasons of lack of time, and not for any other reason. b. fix orthographic errors in dvb-bt8xx.txt (for the same reason mentioned in point a.) c. reconstruct my 2.6.13-structure of dvb-bt8xx.txt as far as possible d. reflect very well, whether debug parameters should not better be situated in different documentation texts (logically structured, understandable) Regards Uwe Bugla P. S.: akpm never complains about lack of time, and he is doing a very fair and good job, and, at least for him, the amount of 54 patches is simply peanuts. I love cooperation with guys like him! In other words: I respect the demand that cvs-tree and current kernel must be in sync somehow, but if the output is rubbish for several reasons and, moreover, neglects my work, there is simply no reason for any kind of respect. Because I ain't no idiot, just to say it in very simple words. So please in future avoid to blame my person for things that you personally don't get worked (synchronization or whatever kind). And would you please answer me one question: How can I be shure that my patchwork at least enters the institution akpm, if there is someone like you in between complaining for lack of time and synchronization faults? I prefer flat hierarchies (the real hidden success principle of Linux) and cooperation with akpm works very fine. So, as a matter of principle, I don't see any reason why I should prepare and send in my work three, four, five times, just because at the other end someone doesn't get his stuff synchronized or lacks time. I ain't no idiot! Ya Basta! And even if I would give in now for strategic reasons and do the same fuckin' work again, how many Stezenbach clones or whoever would come up afterwards and continue to fuck up my work in the same or just in a different way you personally did? Who do you think you are and who do you think I am? So please do your homework, and do it correct in the future, or leave that job simply to another person. OK? Any further questions, Mr. Johannes Stezenbach? -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner ___ linux-dvb mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- Markus Rechberger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 5/1/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Trent Piepho wrote: > The issue with dst is just a minor missing feature to fully support the dvb > helper module customization system. So nobody needs to worry about this > anymore, the last two patches in this repository will fix it correctly. With regards to the dst, i have explained earlier to you that 1) the dst is not a frontend 2) i do not wish to use the frontend attach methods with regards to dst/dst_ca To mention, we had these discussions much long back how to go about it and don't think that every time a new developer get's an account with linuxtv.org, this has to be a matter that has to discussed to death http://article.gmane.org/gmane.linux.drivers.dvb/16156/match=patch+dvb+bt8xx+cleanup (eventhough of not much concern) If you now see most of the code in dvb-bt8xx especially the DMA stuff was refactored from the dst driver. But that said, the dst *is* different, so WTH ? Please show me where this change makes your work more difficult, Trent's change is small and I don't see the problem where it seriously affects your work. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
DST/BT878 module customization (.. was: Critical points about ...)
Hi, Trent Piepho wrote another patch for it, it just completes Uwe's patch in the end. http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb as far as I see from that patch it cleans up a memory leak which would happen when the system tries to load the dst module if it's not available and it also prints a message that points the user should enable it in the kernel if needed. It also bundles the dst and dst_ca objects to one selectable option. So the idea remains the same. From my side I do not see any problem with that patch, if someone else has a problem with it please state out the reason. Markus On 4/30/07, Markus Rechberger <[EMAIL PROTECTED]> wrote: On 4/30/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > > On Apr 30 2007 19:25, Uwe Bugla wrote: > > >THIS PATCH IS DONE TO AVOID RAM WASTE FOR CASES IN WHICH IT IS PROVEN THAT > DST > >AND DST_CA ARE NOT NEEDED AT ALL > >[...] > > > How much on the Theo-meter are we yet? > it's enough, I told him that I'll look at it and try to get some other people involved if it really breaks something it should get stated out; and I'll refuse any further help if he starts to write any more abusive mail. So to his proposal: the whole noise is about following Makefile patch: -obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o +obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o +obj-$(CONFIG_DVB_DST) += dst.o +obj-$(CONFIG_DVB_DST_CA) += dst_ca.o that symbol_request is unable to return a valid pointer if DST an DST_CA aren't selected should be ok because this would only happen if someone didn't compile them in (an appropriate error message should be added for that) I'm trying to look closer at this issue with some other developers, if it's really that easy to split off the dst module from the bt* objects without breaking anything, to me the direction this patch goes seems to be ok, some people stated out that there are problems so I'll try to get more information about that. Markus -- Markus Rechberger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote: On Apr 30 2007 19:25, Uwe Bugla wrote: >THIS PATCH IS DONE TO AVOID RAM WASTE FOR CASES IN WHICH IT IS PROVEN THAT DST >AND DST_CA ARE NOT NEEDED AT ALL >[...] How much on the Theo-meter are we yet? it's enough, I told him that I'll look at it and try to get some other people involved if it really breaks something it should get stated out; and I'll refuse any further help if he starts to write any more abusive mail. So to his proposal: the whole noise is about following Makefile patch: -obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o +obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o +obj-$(CONFIG_DVB_DST) += dst.o +obj-$(CONFIG_DVB_DST_CA) += dst_ca.o that symbol_request is unable to return a valid pointer if DST an DST_CA aren't selected should be ok because this would only happen if someone didn't compile them in (an appropriate error message should be added for that) I'm trying to look closer at this issue with some other developers, if it's really that easy to split off the dst module from the bt* objects without breaking anything, to me the direction this patch goes seems to be ok, some people stated out that there are problems so I'll try to get more information about that. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
all these discussions are about Makefile and documentation changes as far as I see. I don't see the point why there's a need for such a big discussion here just about these changes. Uwe please resend your patch files and lets get this story done, if your work breaks something we can point you out to what is wrong. We have what's in the repository now and it won't change unless we put some time in it again. Uwe, if you have a problem with anyone here keep it for yourself just submit the latest patches and I'll have a look asap at it. There's no need to be unfriendly here. Markus On 4/30/07, Helge Hafting <[EMAIL PROTECTED]> wrote: Uwe Bugla wrote: > Original-Nachricht > Datum: Mon, 30 Apr 2007 13:21:29 +0200 > Von: Helge Hafting <[EMAIL PROTECTED]> > An: Uwe Bugla <[EMAIL PROTECTED]> > CC: linux-kernel@vger.kernel.org > Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities > > >> Uwe Bugla wrote: >> >>> In this ten Emails you will yourself see the intellectual and technical >>> >> proof in how far Mr. Chehab is acting with nothing else but: >> >>> a. Lies >>> b. Unproven thesis >>> c. Stigmatizations >>> >>> and so on. >>> >>> THIS MAN HAS NO IDEA, BUT HE HAS THE POWER! >>> >>> >> Please note that there are ways to replace a bad maintainer. >> We still try to keep it polite. >> >> But note that you can't have someone "fired", no matter how bad they >> do their job. A bad maintainer is usually better than none - the bad >> maintainer might improve. Or at least get some simple stuff done. >> >> You therefore replace a bad maintainer by taking over the position. >> Contact whoever is above the maintainer (Linus or some other >> higher-level maintainer). You explain the problem, and you must also >> show that you have the time and knowledge to do a better job. >> > > Hi Helge, > A. I do neither have enough skills to take up a maintainers role > Then your only hope is to find someone else that is interested. > B. Linus and Andrew are high-leveled informed about the whole structural problem, but they close their eyes, they simply do not want to see the necessity of a replacement. > That is at least my impression. > The aren't doing any less than you do. They don't provide a better maintainer, but neither do you. Linus and Andrew don't have that much more resources than you have. They have programming skills and lots of trust in the community. >> You can, for example, maintain the same subsystem in parallel. After a >> while, >> all interested parties sees that your tree works better and that >> communicating with you is easier. >> If you aren't prepared to do this - then you have to live with the current >> maintainer. There is no staff ready to replace maintainers after >> complaints, a volunteer doing a better job is always necessary. >> > > Neither nor: I do not livbe with persons like Chehab and others, no matter what the consequence is. To be truthful I would strategically prefare a vacuum at the price that the work isn't even done for months. > ONLY IF there is a personnel vacuum the necessity for others to volunteer will arise. > A sufficiently bad maintainer will also do it. If lots of submitters send their patches to andrew in order to get past a dysfunctional maintainer, then the subsystem effectively is unmaintained. > So if you want a real change you gotta first kick the reactionary dumb bastards off from their seats without any return ticket - without that there won't be any changes at all! > Well then - create a patch to the MAINTAINERS file that removes this maintainer leaving the position open. Perhaps you can get that accepted despite the existing maintainer - *if* you can get most other developers for that subsystem to add signed-off lines. It will then be clear that the community agrees with you. However, if the bulk of them thinks the current maintainer is fine, then it stays that way. Satisfying everybody is unfortunately not always possible. You can always try submitting your own patches above this maintainer. > But the practice now is the typical "Sit out and do not react at all" behaviour as far as Chehab himself is concerned - Germans remember that reactionary gesture from the time when Hellmut Kohl was chancellor for 16 horrible years. > > So there will be no "soft" or "polite" solution at all, but only a harsh and rude one: > "Kick out the Jams!" Dropping lazy or incompetent maintainers do happen occationally. But don't let frustration lead to angry emails - all you get that way is lost credibility, that will only make it ha
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 13:48:34 +0200 Von: "Markus Rechberger" <[EMAIL PROTECTED]> An: "Uwe Bugla" <[EMAIL PROTECTED]> CC: "hermann pitton" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities > On 4/30/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: > > > > Original-Nachricht > > Datum: Mon, 30 Apr 2007 02:58:33 +0200 > > Von: hermann pitton <[EMAIL PROTECTED]> > > An: Uwe Bugla <[EMAIL PROTECTED]> > > CC: Linus Torvalds <[EMAIL PROTECTED]>, [EMAIL PROTECTED], > > [EMAIL PROTECTED], [EMAIL PROTECTED], > > linux-kernel@vger.kernel.org > > Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 > > and pseudo-authorities > > > > > Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: > > > > Original-Nachricht > > > > Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) > > > > Von: Linus Torvalds <[EMAIL PROTECTED]> > > > > An: Uwe Bugla <[EMAIL PROTECTED]> > > > > CC: [EMAIL PROTECTED], [EMAIL PROTECTED], > [EMAIL PROTECTED], > > > linux-kernel@vger.kernel.org, [EMAIL PROTECTED] > > > > Betreff: Re: Critical points about kernel 2.6.21 and > pseudo-authorities > > > > > > > > > > > > > > > > > > > On Sun, 29 Apr 2007, Uwe Bugla wrote: > > > > > > > > > > > > I have been trying diff and other tools in various variants > (except > > > > > > git-bisect that I cannot handle because I do not understand the > > > practice > > > > > > of it). > > > > > > > > > > git bisect is _really_ simple if you already have a git tree > anyway. > > > And > > > > > even if you don't, getting one isn't really hard either. Just do > > > > > > > > > >git clone > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > > > linux-2.6 > > > > > > > > > > and you have a tree (it will take a little while - it's going to > > > dowload > > > > > about 170MB or so of stuff, so the initial clone is going to be a > bit > > > > > painful unless you have a fast internet connection). > > > > > > > > > > Once you have the git tree, assuming that 2.6.21-rc7 worked for > you, > > > it's > > > > > really as easy as just saying > > > > > > > > > >git bisect start > > > > >git bisect good v2.6.21-rc7 > > > > >git bisect bad v2.6.21 > > > > > > > > > > and git will think for a short while (most of the time is going to > be > > > > > checking out the new tree) and give you a tree to test. > > > > > > > > > > Just build, boot, and test that tree. > > > > > > > > > > If it was fine, do > > > > > > > > > >git bisect good > > > > > > > > > > and git will pick a new tree to test. And if it wasn't, instead > just > > > do > > > > > "git bisect bad", and git will pick _another_ version to test. Do > this > > > a > > > > > few times, and git will tell you which commit introduced them. > > > > > > > > > > There were just 125 commits in between 2.6.21-rc7 and the final > one, > > > so it > > > > > should be quite quick - bisection basically does a binary search, > so > > > doing > > > > > seven reboots should have you with the result. > > > > > > > > > > The fact that it already works in 2.6.21-git2 obviously means that > _I_ > > > end > > > > > up being less interested, but the -stable tree people would love > to > > > hear > > > > > what broke! > > > > > > > > Hi again Linus, > > > > my deep thanks for your excellent explication of git-bisect. > > > > But I unfortunately owe a 100Kbit flatrate, and so downloading some > 170 > > > MB git tree will need the time amount of one entire night (11.5 kb /s > if I > > > am lucky - no more). > > > > Just to t
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 02:58:33 +0200 Von: hermann pitton <[EMAIL PROTECTED]> An: Uwe Bugla <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities > Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: > > Original-Nachricht > > Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) > > Von: Linus Torvalds <[EMAIL PROTECTED]> > > An: Uwe Bugla <[EMAIL PROTECTED]> > > CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], > linux-kernel@vger.kernel.org, [EMAIL PROTECTED] > > Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities > > > > > > > > > > > On Sun, 29 Apr 2007, Uwe Bugla wrote: > > > > > > > > I have been trying diff and other tools in various variants (except > > > > git-bisect that I cannot handle because I do not understand the > practice > > > > of it). > > > > > > git bisect is _really_ simple if you already have a git tree anyway. > And > > > even if you don't, getting one isn't really hard either. Just do > > > > > > git clone > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > linux-2.6 > > > > > > and you have a tree (it will take a little while - it's going to > dowload > > > about 170MB or so of stuff, so the initial clone is going to be a bit > > > painful unless you have a fast internet connection). > > > > > > Once you have the git tree, assuming that 2.6.21-rc7 worked for you, > it's > > > really as easy as just saying > > > > > > git bisect start > > > git bisect good v2.6.21-rc7 > > > git bisect bad v2.6.21 > > > > > > and git will think for a short while (most of the time is going to be > > > checking out the new tree) and give you a tree to test. > > > > > > Just build, boot, and test that tree. > > > > > > If it was fine, do > > > > > > git bisect good > > > > > > and git will pick a new tree to test. And if it wasn't, instead just > do > > > "git bisect bad", and git will pick _another_ version to test. Do this > a > > > few times, and git will tell you which commit introduced them. > > > > > > There were just 125 commits in between 2.6.21-rc7 and the final one, > so it > > > should be quite quick - bisection basically does a binary search, so > doing > > > seven reboots should have you with the result. > > > > > > The fact that it already works in 2.6.21-git2 obviously means that _I_ > end > > > up being less interested, but the -stable tree people would love to > hear > > > what broke! > > > > Hi again Linus, > > my deep thanks for your excellent explication of git-bisect. > > But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 > MB git tree will need the time amount of one entire night (11.5 kb /s if I > am lucky - no more). > > Just to take up a different approach: > > > > The difference between 2.6.21-rc7 and 2.6.21 official does not play any > role at all. > > > > On the other hand I found out that: > > 2.6.21-rc7 made my AMD K7 router work fine > > 2.6.21 official hung my AMD K7 router up > > 2.6.21-git1 hung my AMD K7 router up > > 2.6.21-git2 made my AMD K7 router work. > > > > In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves > the problem. > > Or am I saying something wrong as far as logical terms are concerned? > > > > > > > > > I like small and effective kernels instead of blown up RAM waste. > > > > This is no Windoze, man, this is Linux! > > > > > > Yes. But if you cannot be polite and *RESPECTFUL*, you won't get > anywhere > > > at all. > > > > > > This is Linux, not Windows. But that also means that those developers > that > > > you denigrate aren't getting paid by you, and if you don't show them > > > respect, they'll totally ignore you. > > > > > > Linus > > > > Now this is the old problem about it all: the hypocricy factor, the > utmost small, if not to say pre-pubertarian character plus some other obviously > counter-productive character traits in those so-called "maintainers" who > behave like kids, but not like grown-ups at all! > > Not only you, but also Andrew perfectly and willingly step into the > hypocritic trap and do not even feel that they are trapped! > > > > For the majority of all cases of the so-called "maintainer personnel" at > linuxtv.org the statement of some missing "politeness" or some missing > "respect" is nothing but an utmost dumb, kiddish, human mediocre and utmost > stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness, > wrong solidarity, kiddishness and technical incompetence. > > > > They are building up pseudo-authorities to hide their lack of > competence, no matter if their lack of competence funds on technical or human lacks. > > And at least the Brazilian Mauro Carvalho Chehab does go even so far to > soap in Andrew
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Uwe Bugla [EMAIL PROTECTED] wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 02:58:33 +0200 Von: hermann pitton [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED] Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). git bisect is _really_ simple if you already have a git tree anyway. And even if you don't, getting one isn't really hard either. Just do git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 and you have a tree (it will take a little while - it's going to dowload about 170MB or so of stuff, so the initial clone is going to be a bit painful unless you have a fast internet connection). Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's really as easy as just saying git bisect start git bisect good v2.6.21-rc7 git bisect bad v2.6.21 and git will think for a short while (most of the time is going to be checking out the new tree) and give you a tree to test. Just build, boot, and test that tree. If it was fine, do git bisect good and git will pick a new tree to test. And if it wasn't, instead just do git bisect bad, and git will pick _another_ version to test. Do this a few times, and git will tell you which commit introduced them. There were just 125 commits in between 2.6.21-rc7 and the final one, so it should be quite quick - bisection basically does a binary search, so doing seven reboots should have you with the result. The fact that it already works in 2.6.21-git2 obviously means that _I_ end up being less interested, but the -stable tree people would love to hear what broke! Hi again Linus, my deep thanks for your excellent explication of git-bisect. But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more). Just to take up a different approach: The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all. On the other hand I found out that: 2.6.21-rc7 made my AMD K7 router work fine 2.6.21 official hung my AMD K7 router up 2.6.21-git1 hung my AMD K7 router up 2.6.21-git2 made my AMD K7 router work. In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem. Or am I saying something wrong as far as logical terms are concerned? I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere at all. This is Linux, not Windows. But that also means that those developers that you denigrate aren't getting paid by you, and if you don't show them respect, they'll totally ignore you. Linus Now this is the old problem about it all: the hypocricy factor, the utmost small, if not to say pre-pubertarian character plus some other obviously counter-productive character traits in those so-called maintainers who behave like kids, but not like grown-ups at all! Not only you, but also Andrew perfectly and willingly step into the hypocritic trap and do not even feel that they are trapped! For the majority of all cases of the so-called maintainer personnel at linuxtv.org the statement of some missing politeness or some missing respect is nothing but an utmost dumb, kiddish, human mediocre and utmost stupid and utmost hypocritic excuse for bare naked incompatibility, dumbness, wrong solidarity, kiddishness and technical incompetence. They are building up pseudo-authorities to hide their lack of competence, no matter if their lack of competence funds on technical or human lacks. And at least the Brazilian Mauro Carvalho Chehab does go even so far to soap in Andrew Morton's face with this enourmous threat of incompetence, kiddishness, incompatibility, hypocricy, lies, stigmatisations, stubbornness, lack of experience, pre-pubertarian behaviour, fascistoid opinion dictatorship as part of a deep immature anti-democratic and reactionary personality
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Uwe Bugla [EMAIL PROTECTED] wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 13:48:34 +0200 Von: Markus Rechberger [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: hermann pitton [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities On 4/30/07, Uwe Bugla [EMAIL PROTECTED] wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 02:58:33 +0200 Von: hermann pitton [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Am Montag, den 30.04.2007, 01:00 +0200 schrieb Uwe Bugla: Original-Nachricht Datum: Sun, 29 Apr 2007 14:19:22 -0700 (PDT) Von: Linus Torvalds [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], linux-kernel@vger.kernel.org, [EMAIL PROTECTED] Betreff: Re: Critical points about kernel 2.6.21 and pseudo-authorities On Sun, 29 Apr 2007, Uwe Bugla wrote: I have been trying diff and other tools in various variants (except git-bisect that I cannot handle because I do not understand the practice of it). git bisect is _really_ simple if you already have a git tree anyway. And even if you don't, getting one isn't really hard either. Just do git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6 and you have a tree (it will take a little while - it's going to dowload about 170MB or so of stuff, so the initial clone is going to be a bit painful unless you have a fast internet connection). Once you have the git tree, assuming that 2.6.21-rc7 worked for you, it's really as easy as just saying git bisect start git bisect good v2.6.21-rc7 git bisect bad v2.6.21 and git will think for a short while (most of the time is going to be checking out the new tree) and give you a tree to test. Just build, boot, and test that tree. If it was fine, do git bisect good and git will pick a new tree to test. And if it wasn't, instead just do git bisect bad, and git will pick _another_ version to test. Do this a few times, and git will tell you which commit introduced them. There were just 125 commits in between 2.6.21-rc7 and the final one, so it should be quite quick - bisection basically does a binary search, so doing seven reboots should have you with the result. The fact that it already works in 2.6.21-git2 obviously means that _I_ end up being less interested, but the -stable tree people would love to hear what broke! Hi again Linus, my deep thanks for your excellent explication of git-bisect. But I unfortunately owe a 100Kbit flatrate, and so downloading some 170 MB git tree will need the time amount of one entire night (11.5 kb /s if I am lucky - no more). Just to take up a different approach: The difference between 2.6.21-rc7 and 2.6.21 official does not play any role at all. On the other hand I found out that: 2.6.21-rc7 made my AMD K7 router work fine 2.6.21 official hung my AMD K7 router up 2.6.21-git1 hung my AMD K7 router up 2.6.21-git2 made my AMD K7 router work. In so far the diff between 2.6.21-git1 and 2.6.21-git2 obviously solves the problem. Or am I saying something wrong as far as logical terms are concerned? I like small and effective kernels instead of blown up RAM waste. This is no Windoze, man, this is Linux! Yes. But if you cannot be polite and *RESPECTFUL*, you won't get anywhere at all. This is Linux, not Windows. But that also means that those developers that you denigrate aren't getting paid by you, and if you don't show them respect, they'll totally ignore you. Linus Now this is the old problem about it all: the hypocricy factor, the utmost small, if not to say pre-pubertarian character plus some other obviously counter-productive character traits in those so-called maintainers who behave like kids, but not like grown-ups at all! Not only you, but also Andrew perfectly and willingly step into the hypocritic trap and do not even feel that they are trapped! For the majority of all cases of the so-called maintainer personnel at linuxtv.org the statement of some missing politeness or some missing respect
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
all these discussions are about Makefile and documentation changes as far as I see. I don't see the point why there's a need for such a big discussion here just about these changes. Uwe please resend your patch files and lets get this story done, if your work breaks something we can point you out to what is wrong. We have what's in the repository now and it won't change unless we put some time in it again. Uwe, if you have a problem with anyone here keep it for yourself just submit the latest patches and I'll have a look asap at it. There's no need to be unfriendly here. Markus On 4/30/07, Helge Hafting [EMAIL PROTECTED] wrote: Uwe Bugla wrote: Original-Nachricht Datum: Mon, 30 Apr 2007 13:21:29 +0200 Von: Helge Hafting [EMAIL PROTECTED] An: Uwe Bugla [EMAIL PROTECTED] CC: linux-kernel@vger.kernel.org Betreff: Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities Uwe Bugla wrote: In this ten Emails you will yourself see the intellectual and technical proof in how far Mr. Chehab is acting with nothing else but: a. Lies b. Unproven thesis c. Stigmatizations and so on. THIS MAN HAS NO IDEA, BUT HE HAS THE POWER! Please note that there are ways to replace a bad maintainer. We still try to keep it polite. But note that you can't have someone fired, no matter how bad they do their job. A bad maintainer is usually better than none - the bad maintainer might improve. Or at least get some simple stuff done. You therefore replace a bad maintainer by taking over the position. Contact whoever is above the maintainer (Linus or some other higher-level maintainer). You explain the problem, and you must also show that you have the time and knowledge to do a better job. Hi Helge, A. I do neither have enough skills to take up a maintainers role Then your only hope is to find someone else that is interested. B. Linus and Andrew are high-leveled informed about the whole structural problem, but they close their eyes, they simply do not want to see the necessity of a replacement. That is at least my impression. The aren't doing any less than you do. They don't provide a better maintainer, but neither do you. Linus and Andrew don't have that much more resources than you have. They have programming skills and lots of trust in the community. You can, for example, maintain the same subsystem in parallel. After a while, all interested parties sees that your tree works better and that communicating with you is easier. If you aren't prepared to do this - then you have to live with the current maintainer. There is no staff ready to replace maintainers after complaints, a volunteer doing a better job is always necessary. Neither nor: I do not livbe with persons like Chehab and others, no matter what the consequence is. To be truthful I would strategically prefare a vacuum at the price that the work isn't even done for months. ONLY IF there is a personnel vacuum the necessity for others to volunteer will arise. A sufficiently bad maintainer will also do it. If lots of submitters send their patches to andrew in order to get past a dysfunctional maintainer, then the subsystem effectively is unmaintained. So if you want a real change you gotta first kick the reactionary dumb bastards off from their seats without any return ticket - without that there won't be any changes at all! Well then - create a patch to the MAINTAINERS file that removes this maintainer leaving the position open. Perhaps you can get that accepted despite the existing maintainer - *if* you can get most other developers for that subsystem to add signed-off lines. It will then be clear that the community agrees with you. However, if the bulk of them thinks the current maintainer is fine, then it stays that way. Satisfying everybody is unfortunately not always possible. You can always try submitting your own patches above this maintainer. But the practice now is the typical Sit out and do not react at all behaviour as far as Chehab himself is concerned - Germans remember that reactionary gesture from the time when Hellmut Kohl was chancellor for 16 horrible years. So there will be no soft or polite solution at all, but only a harsh and rude one: Kick out the Jams! Dropping lazy or incompetent maintainers do happen occationally. But don't let frustration lead to angry emails - all you get that way is lost credibility, that will only make it harder to convince people. Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Markus Rechberger - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 4/30/07, Jan Engelhardt [EMAIL PROTECTED] wrote: On Apr 30 2007 19:25, Uwe Bugla wrote: THIS PATCH IS DONE TO AVOID RAM WASTE FOR CASES IN WHICH IT IS PROVEN THAT DST AND DST_CA ARE NOT NEEDED AT ALL [...] How much on the Theo-meter are we yet? it's enough, I told him that I'll look at it and try to get some other people involved if it really breaks something it should get stated out; and I'll refuse any further help if he starts to write any more abusive mail. So to his proposal: the whole noise is about following Makefile patch: -obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o +obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o +obj-$(CONFIG_DVB_DST) += dst.o +obj-$(CONFIG_DVB_DST_CA) += dst_ca.o that symbol_request is unable to return a valid pointer if DST an DST_CA aren't selected should be ok because this would only happen if someone didn't compile them in (an appropriate error message should be added for that) I'm trying to look closer at this issue with some other developers, if it's really that easy to split off the dst module from the bt* objects without breaking anything, to me the direction this patch goes seems to be ok, some people stated out that there are problems so I'll try to get more information about that. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
DST/BT878 module customization (.. was: Critical points about ...)
Hi, Trent Piepho wrote another patch for it, it just completes Uwe's patch in the end. http://linuxtv.org/hg/~tap/dst-new?cmd=changeset;node=bbdd2b53cd5c;style=gitweb as far as I see from that patch it cleans up a memory leak which would happen when the system tries to load the dst module if it's not available and it also prints a message that points the user should enable it in the kernel if needed. It also bundles the dst and dst_ca objects to one selectable option. So the idea remains the same. From my side I do not see any problem with that patch, if someone else has a problem with it please state out the reason. Markus On 4/30/07, Markus Rechberger [EMAIL PROTECTED] wrote: On 4/30/07, Jan Engelhardt [EMAIL PROTECTED] wrote: On Apr 30 2007 19:25, Uwe Bugla wrote: THIS PATCH IS DONE TO AVOID RAM WASTE FOR CASES IN WHICH IT IS PROVEN THAT DST AND DST_CA ARE NOT NEEDED AT ALL [...] How much on the Theo-meter are we yet? it's enough, I told him that I'll look at it and try to get some other people involved if it really breaks something it should get stated out; and I'll refuse any further help if he starts to write any more abusive mail. So to his proposal: the whole noise is about following Makefile patch: -obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o dst.o dst_ca.o +obj-$(CONFIG_DVB_BT8XX) += bt878.o dvb-bt8xx.o +obj-$(CONFIG_DVB_DST) += dst.o +obj-$(CONFIG_DVB_DST_CA) += dst_ca.o that symbol_request is unable to return a valid pointer if DST an DST_CA aren't selected should be ok because this would only happen if someone didn't compile them in (an appropriate error message should be added for that) I'm trying to look closer at this issue with some other developers, if it's really that easy to split off the dst module from the bt* objects without breaking anything, to me the direction this patch goes seems to be ok, some people stated out that there are problems so I'll try to get more information about that. Markus -- Markus Rechberger - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On 5/1/07, Manu Abraham [EMAIL PROTECTED] wrote: Trent Piepho wrote: The issue with dst is just a minor missing feature to fully support the dvb helper module customization system. So nobody needs to worry about this anymore, the last two patches in this repository will fix it correctly. With regards to the dst, i have explained earlier to you that 1) the dst is not a frontend 2) i do not wish to use the frontend attach methods with regards to dst/dst_ca To mention, we had these discussions much long back how to go about it and don't think that every time a new developer get's an account with linuxtv.org, this has to be a matter that has to discussed to death http://article.gmane.org/gmane.linux.drivers.dvb/16156/match=patch+dvb+bt8xx+cleanup (eventhough of not much concern) If you now see most of the code in dvb-bt8xx especially the DMA stuff was refactored from the dst driver. But that said, the dst *is* different, so WTH ? Please show me where this change makes your work more difficult, Trent's change is small and I don't see the problem where it seriously affects your work. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
homework: a. readd my name (I didn't delete it, so I won't do the same job again, not for sync reasons, and not for reasons of lack of time, and not for any other reason. b. fix orthographic errors in dvb-bt8xx.txt (for the same reason mentioned in point a.) c. reconstruct my 2.6.13-structure of dvb-bt8xx.txt as far as possible d. reflect very well, whether debug parameters should not better be situated in different documentation texts (logically structured, understandable) Regards Uwe Bugla P. S.: akpm never complains about lack of time, and he is doing a very fair and good job, and, at least for him, the amount of 54 patches is simply peanuts. I love cooperation with guys like him! In other words: I respect the demand that cvs-tree and current kernel must be in sync somehow, but if the output is rubbish for several reasons and, moreover, neglects my work, there is simply no reason for any kind of respect. Because I ain't no idiot, just to say it in very simple words. So please in future avoid to blame my person for things that you personally don't get worked (synchronization or whatever kind). And would you please answer me one question: How can I be shure that my patchwork at least enters the institution akpm, if there is someone like you in between complaining for lack of time and synchronization faults? I prefer flat hierarchies (the real hidden success principle of Linux) and cooperation with akpm works very fine. So, as a matter of principle, I don't see any reason why I should prepare and send in my work three, four, five times, just because at the other end someone doesn't get his stuff synchronized or lacks time. I ain't no idiot! Ya Basta! And even if I would give in now for strategic reasons and do the same fuckin' work again, how many Stezenbach clones or whoever would come up afterwards and continue to fuck up my work in the same or just in a different way you personally did? Who do you think you are and who do you think I am? So please do your homework, and do it correct in the future, or leave that job simply to another person. OK? Any further questions, Mr. Johannes Stezenbach? -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen für GMX Partner: http://www.gmx.net/de/go/partner ___ linux-dvb mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- Markus Rechberger - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
On 4/29/07, Bob Tracy <[EMAIL PROTECTED]> wrote: Linus Torvalds wrote: > On Sun, 29 Apr 2007, Markus Rechberger wrote: > > How else should bugs get handled, sending them to the lkml? > > Actually, looking at Adrian's regression lists, yes. lkml worked better > than bugzilla did. By at _least_ a factor of two. Since 1992, lkml (with "Cc:" to the appropriate subsystem mailing list if applicable) and the presumed responsible parties are the only channels I've used to report the bugs I encounter. since there are subsystems out there which are managed separatly this doesn't work out. I wasn't happy when I noticed that patches got applied to the sourcecode I contributed without notifying me while I still worked on that code separatly It was moreover the fault of the subsystem maintainer to not notify me back then but a centralized bugreporting (as bugzilla) tool would at least have notified me, or I would have been able to see the suggested changes there. But I agree with that if you're only 1 level far away from the linux kernel. Other methods come and go, but old habits die hard, particularly when they have a knack for producing the desired result. Historically, requiring a developer to fire up a GUI to read a bug report decreases the chance that bug report will be noticed. The development community can do whatever flips its collective switch as far as tracking bugs, but the bugs have to be reported and noticed before tracking becomes a meaningful activity. One more thought and I'll get off your screens... We've steadfastly resisted making lkml and friends subscriber-only mailing lists precisely because we don't want to miss a potential bug report because a would-be submitter isn't subscribed. If people aren't looking for bug reports here, what's the point? it's just easy to miss something here, if an ext3 bug comes in and all people who're involved in the ext3 filesytem are on vacation I'm sure they won't read all the mails which came in during a week, now take a part of the kernel which is smaller than the ext3 filesystem (eg. usb gadgets, smaller drivers) Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
On 4/29/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: On Sun, 29 Apr 2007, Markus Rechberger wrote: > > I totally disagree here, bugzilla is a very good tool. If someone is > too lazy to look at it it's his problem. You must be doing things very differently from a lot of other people if you think that's the case. Well I'm behind the stuff I'm doing because I'm interested in it. And if some bugs are introduced by my work or derived by my work I'd like to get them cleaned up in the end. If I see that someone reports bugs which doesn't really address my work at all I just forward them to the subsystem/maintainer who's "in charge" (if someone can say it that way for an open source project) > Kernel Janitors can pick out some bugs which aren't addressed by > anyone or got left behind. IF that happened, it would actually be great. That's what I'm arguing for. And it was basically what Adrian was doing! I'm very sure that happens maybe it's just not visible to everyone because there are so many open issues. (I just take myself as an example here, I didn't do too much with other bugs but at least some of my work closed 5 other bugs this year beside the bugreports I'm getting directly) > How else should bugs get handled, sending them to the lkml? Actually, looking at Adrian's regression lists, yes. lkml worked better than bugzilla did. By at _least_ a factor of two. Yes Adrian did a very good job with collecting every bugreport and sending the mails to all corresponding subsystems. > I'm 100% sure some bugreports will also get lost then, but on the lkml > they'll very likely remain lost whereas in the bugzilla they'll remain > as open. What's the difference between bugzilla and lkml.org? Both have search buttons. Both archive the old stuff. Both can be pointed to. Both have search buttons yes, but the lkml doesn't leave an unread mail open ontop of the lkml as bugzilla does if you look for open bugs in a subsystem. > what are your suggestions to improve a bugreporting tool, I'm very > sure that many people, especially people who want to get into existing > projects here, would love to contribute. I don't know what the perfect setup is, but I do know that bugzilla is very close to be totally useless for the top-level maintainers. Try to think like a person who doesn't maintain *one* specific file in the kernel, but who can actually make a good judgement about a lot of things, or at least funnel a problem report to the right person? And now, imagine that that person is also fairly busy (exactly *because* he's not looking at a single file, he may be maintaining a huge subsystem that has multiple submaintainers etc). And ask yourself whether bugzilla really helps. bugzilla keeps the bugs open at least, at the lkml I use to skip days sometimes. Many people who consider themself as maintainer of a subsystem are assigned to a subsection on bugzilla, if it really doesn't work out we have to change the corresponding maintainer. If that maintainer doesn't know where to go with that bugreport he can easily send it to the lkml and some people will recognize the sender/email and pay extra attention to it (that's just how I think about it) > I'd say this is a personal opinion, some people will get along with it > and some of them will not... I think bugzilla really only works for very "directed" issues. If you already know exactly which driver is affected (which is often wrong anyway: some of the bugs that were due timer breakage got blamed as disk hangs!) it's almost totally useless. And yes, maybe that's why you have a much higher opinion of bugzilla than I do. To _me_ bugzilla is a total mess. There's absolutely _zero_ useful information there. And I'm pretty certain that is true of a *lot* of other people too. But if you have a small project, or you maintain a very specific (and clearly delineated) part of a big project, bugzilla probably looks a lot more palatable. well are there any bugs that cannot be forwarded/directed to a corresponding maintainer? Maybe I don't see something here, can you point me out to a bugreport which cannot be handled at all? As a reference I'll take following bugreport: http://thread.gmane.org/gmane.linux.kernel/521185 the bug doesn't even mention what device is affected, asking for further detailed information (dmesg) shows up what's left at least.. (in the meanwhile the bug even got solved) Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
On 4/29/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: On Sat, 28 Apr 2007, Adrian Bunk wrote: > > We are already quite good at ignoring bug reports that come through > linux-kernel, and it's an _advantage_ of the kernel Bugzilla to see more > than 1600 open bugs because this tells how bad we are at handling bugs. No, it just shows that bugzilla doesn't matter for most of the kernel. Don't say that "bugzilla tells how bad we are at handling bugs". It tells how bad *bugzilla* is for handling bugs, nothing more. I totally disagree here, bugzilla is a very good tool. If someone is too lazy to look at it it's his problem. Kernel Janitors can pick out some bugs which aren't addressed by anyone or got left behind. I also found some bugs there which could have been solved by anyone here, the matter is just that many people aren't interested in mainly bug fixing and many also work on different other topics here. How else should bugs get handled, sending them to the lkml? I'm 100% sure some bugreports will also get lost then, but on the lkml they'll very likely remain lost whereas in the bugzilla they'll remain as open. Trying to play politics by pointing to bugzilla is pointless. Bugzilla is used for a few subsystems (ACPI seems to use it actively, for example), but I doubt most developers use it. as for the em28xx I actively use it, but I also set up a mailinglist etc. and there are many supporters already... Would be be good to have a better bug-tracking setup? Yes. But I think it takes man-power, and it would take something *fundamentally* better than bugzilla. what are your suggestions to improve a bugreporting tool, I'm very sure that many people, especially people who want to get into existing projects here, would love to contribute. Maybe the new "http://kernelnewbies.org/known_regressions; thing will evolve to something worth tracking. Right now, bugzilla isn't it (although it can be a useful tracking place for individual bugs, *once* you've found and gotten the right developer involved - but that's a huge step that bugzilla generally does *not* do for us). I'd say this is a personal opinion, some people will get along with it and some of them will not... Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
On 4/27/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Fri, Apr 27, 2007 at 12:31:43PM -0400, Theodore Tso wrote: > On Fri, Apr 27, 2007 at 04:58:05PM +0200, Adrian Bunk wrote: > > "no regressions" is definitely not feasible. > > > > 14 known regressions, some of them not yet debugged at all, are > > different from your "some small regression". > > Yes, but when were some of these regressions reported? Past a certain > point, I think it's reasonable to look at the regression, decide how > many people would be affected by it, and why it hadn't been noticed > earlier, and in some cases, decide that it's better to get this > debugged and fixed in the stable and development trees in parallel. 8 of them have been reported in March or earlier. [1] Patches for 2 of these 8 were available at the time of the release. [2] While the question whether to merge one of them into 2.6.21 was controversial, the other one was not controversial. I can imagine that the dvb oops bugfix got held back to avoid some noise with dvb developers who claimed that they didn't get notified about how that patch got into the v4l-dvb repository (it didn't get reviewed by these people for weeks because it simply got ignored and some of them were aware of that) On the other side if I read bugreports like the following one: http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg23028.html (My Nova-T 500 crashes quite regularly. My machine has been running for about a week and in that time has had 5 oopses.) It doesn't solve the Nova-T disconnects, but it at least solves that the machine doesn't go down when this happens till the driver gets fixed. I think it would have been nice to get that patch into it Markus For one of the bugs, it became obvious when someone looked at it after the release of 2.6.21 that between the bug report on March 31th and the release of 2.6.21 on April 21th, noone started debugging this bug. [3] [4] > > And look e.g. at the many (and non-trivial) changes between -rc7 and > > -final, resulting in more than one report from people who were running > > -rc7 without problems - and 2.6.21 doesn't work for them. > > I agree that's unfortunate. > > > It's not a choice between "regressions don't matter" and "no regressions", > > it's about the place in the area between these two extremes. I have my > > opinions on what I want to expect from a stable Linux kernel, and other > > people have different opinins. > > Everyone is going to disagree to some extent; and their own comfort > zone. So a certain amount compromise is always going to be necessary. > Of course, it's up to you decide whether this has gone beyond the zone > where you aren't comfortable working with other people's development > style. > > Regards, > >- Ted cu Adrian [1] http://lkml.org/lkml/2007/4/26/2 [2] http://lkml.org/lkml/2007/4/25/496 [3] http://lkml.org/lkml/2007/4/26/496 [4] and although it turned out this specific regression was already fixed in 2.6.21, I hope you get my point -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Markus Rechberger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB updates
On 4/28/07, Trent Piepho <[EMAIL PROTECTED]> wrote:
On Sat, 28 Apr 2007, Markus Rechberger wrote:
> On 4/27/07, Trent Piepho <[EMAIL PROTECTED]> wrote:
> > On Mon, 16 Apr 2007, Markus Rechberger wrote:
> > > > >> enough testing to be sent to mainline.
> >
> > I wish these patches had more comments about how they worked, because
it's
> > not clear to me exactly what they are doing or why they do it.
> >
> > Fix 3/3 for bug 7819: fixed hotplugging for dvbnet
> >
> > I'm just going to talk about this one patch, since it appears to be the
> > simplest.
> >
> > This patch removes the 'wait_queue' memory of dvb_demux. Why does a
patch
> > to dvbnet have anything to do with the demux device? Should this change
> > have been part of the previous patch, the one what fixes demux and dvr?
> >
>
> The waitqueue got added in a previous patch just ignore it..
Do the patches need to be applied all together? If I apply just the first
two, do I get something that's broken?
yes very likely only because of this wait_queue..
> > The patch replace the (file_operations)->release pointer with the new
> > function dvb_net_close() in place of dvb_generic_release(). The first
> > part of dvb_net_close() is just a cut from dvb_generic_release(),
> > so maybe it would be better to just call dvb_generic_release() instead?
> >
>
> no because it needs the dvb_net structure which cannot be used in the
> dvb_generic_release function.
I mean, have dvb_net_close() call dvb_generic_release() and then do the
extra stuff.
dvb_generic_release is really generic and has no information about the
dvb net structure if it's used for eg. the frontend
for example the dvb_frontend release function:
static int dvb_frontend_release(struct inode *inode, struct file *file)
{
struct dvb_device *dvbdev = file->private_data;
struct dvb_frontend *fe = dvbdev->priv;
struct dvb_frontend_private *fepriv = fe->frontend_priv;
it would be possible to use dvb_release_generic if there wouldn't be
any reference to dvb_frontend and dvb_frontend_private.
In case of dvb-net it's a dvb_net specific release function by adding
the dvb_net structure.
If you look at dvb_generic_release it only uses dvb_device which is
really generic and used by all the dvb modules (frontend/dmx/..)
> > There is also a bug:
> >
> > +static int dvb_net_close(struct inode *inode, struct file *file)
> > +{
> > + struct dvb_device *dvbdev = file->private_data;
> > + struct dvb_net *dvbnet = dvbdev->priv;
> > +
> > + if (!dvbdev)
> > + return -ENODEV;
> >
> > The check for !dvbdev is too late, dvbdev was already dereferenced on
the
> > previous line to get dvbnet, so if dvbdev is NULL you will have already
> > crashed.
> >
>
> I think this check isn't needed at all actually, why should someone
> release dvbdev before already?
>
> > Is the check for !dvbdev unnecessary paranoia? Or can dvbdev actually
be
> > NULL is some cases?
> >
> > So, w.r.t. dvbnet, my understanding is that somehow dvb_net_release() is
> > called while the net device is still in use. Is that correct?
> > dvb_net_release() will end up deleting some stuff that needs to be
around
> > while there is still a user of the device?
> >
> > Would it be possible to keep dvb_net_release() from getting called in
the
> > first place until there are no users of the device?
What about this? I don't have any hot pluggable hardware, so how does
dvb_net_release() get called when the device disconnects?
I don't understand, it's inode based if you open the file it will also
release the file if you close it.
If it's not hotpluggable it will not use the wait_queue because the
usecount would be 0 already when unloading the module.
> > When looking at this code, keep in mind that users starts at 1 and goes
> > down as the device is used.
> >
> > void dvb_net_release (struct dvb_net *dvbnet)
> > {
> > int i;
> >
> > dvbnet->exit = 1;
> > if (dvbnet->dvbdev->users < 1) /* line A */
> > wait_event(dvbnet->dvbdev->wait_queue, /* line B */
> > dvbnet->dvbdev->users==1);
> > /* line C */
> > dvb_unregister_device(dvbnet->dvbdev);
> > [...]
> > }
> >
> > Isn't there a race condition here? What if there are no users of the
> > device at the time line A runs, but the device is opened before line C
> > runs? After the wait_even() on line B returns there are no users, but
what
> > if new users opens
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB updates
On 4/28/07, Trent Piepho [EMAIL PROTECTED] wrote:
On Sat, 28 Apr 2007, Markus Rechberger wrote:
On 4/27/07, Trent Piepho [EMAIL PROTECTED] wrote:
On Mon, 16 Apr 2007, Markus Rechberger wrote:
enough testing to be sent to mainline.
I wish these patches had more comments about how they worked, because
it's
not clear to me exactly what they are doing or why they do it.
Fix 3/3 for bug 7819: fixed hotplugging for dvbnet
I'm just going to talk about this one patch, since it appears to be the
simplest.
This patch removes the 'wait_queue' memory of dvb_demux. Why does a
patch
to dvbnet have anything to do with the demux device? Should this change
have been part of the previous patch, the one what fixes demux and dvr?
The waitqueue got added in a previous patch just ignore it..
Do the patches need to be applied all together? If I apply just the first
two, do I get something that's broken?
yes very likely only because of this wait_queue..
The patch replace the (file_operations)-release pointer with the new
function dvb_net_close() in place of dvb_generic_release(). The first
part of dvb_net_close() is just a cutpaste from dvb_generic_release(),
so maybe it would be better to just call dvb_generic_release() instead?
no because it needs the dvb_net structure which cannot be used in the
dvb_generic_release function.
I mean, have dvb_net_close() call dvb_generic_release() and then do the
extra stuff.
dvb_generic_release is really generic and has no information about the
dvb net structure if it's used for eg. the frontend
for example the dvb_frontend release function:
static int dvb_frontend_release(struct inode *inode, struct file *file)
{
struct dvb_device *dvbdev = file-private_data;
struct dvb_frontend *fe = dvbdev-priv;
struct dvb_frontend_private *fepriv = fe-frontend_priv;
it would be possible to use dvb_release_generic if there wouldn't be
any reference to dvb_frontend and dvb_frontend_private.
In case of dvb-net it's a dvb_net specific release function by adding
the dvb_net structure.
If you look at dvb_generic_release it only uses dvb_device which is
really generic and used by all the dvb modules (frontend/dmx/..)
There is also a bug:
+static int dvb_net_close(struct inode *inode, struct file *file)
+{
+ struct dvb_device *dvbdev = file-private_data;
+ struct dvb_net *dvbnet = dvbdev-priv;
+
+ if (!dvbdev)
+ return -ENODEV;
The check for !dvbdev is too late, dvbdev was already dereferenced on
the
previous line to get dvbnet, so if dvbdev is NULL you will have already
crashed.
I think this check isn't needed at all actually, why should someone
release dvbdev before already?
Is the check for !dvbdev unnecessary paranoia? Or can dvbdev actually
be
NULL is some cases?
So, w.r.t. dvbnet, my understanding is that somehow dvb_net_release() is
called while the net device is still in use. Is that correct?
dvb_net_release() will end up deleting some stuff that needs to be
around
while there is still a user of the device?
Would it be possible to keep dvb_net_release() from getting called in
the
first place until there are no users of the device?
What about this? I don't have any hot pluggable hardware, so how does
dvb_net_release() get called when the device disconnects?
I don't understand, it's inode based if you open the file it will also
release the file if you close it.
If it's not hotpluggable it will not use the wait_queue because the
usecount would be 0 already when unloading the module.
When looking at this code, keep in mind that users starts at 1 and goes
down as the device is used.
void dvb_net_release (struct dvb_net *dvbnet)
{
int i;
dvbnet-exit = 1;
if (dvbnet-dvbdev-users 1) /* line A */
wait_event(dvbnet-dvbdev-wait_queue, /* line B */
dvbnet-dvbdev-users==1);
/* line C */
dvb_unregister_device(dvbnet-dvbdev);
[...]
}
Isn't there a race condition here? What if there are no users of the
device at the time line A runs, but the device is opened before line C
runs? After the wait_even() on line B returns there are no users, but
what
if new users opens the device after the after line B?
yes this is a valid argument, practically it will never occure though.
Since I also wrote that I didn't have a dvb signal at the time of
writing this I don't even know if the dvb-net implementation is ok at
all.
I don't even know if that part of the framework works and if someone
really uses it.
Is seems like you need something to prevent new users from opening the
device, i.e. make it so that dvbnet-exit=1 prevents the device from
getting opened, but if that's the intention, I don't see where it's
happening.
In dvb_net_close():
+ if(dvbdev-users == 1 dvbnet-exit==1
Re: Linux 2.6.21
On 4/27/07, Adrian Bunk [EMAIL PROTECTED] wrote: On Fri, Apr 27, 2007 at 12:31:43PM -0400, Theodore Tso wrote: On Fri, Apr 27, 2007 at 04:58:05PM +0200, Adrian Bunk wrote: no regressions is definitely not feasible. 14 known regressions, some of them not yet debugged at all, are different from your some small regression. Yes, but when were some of these regressions reported? Past a certain point, I think it's reasonable to look at the regression, decide how many people would be affected by it, and why it hadn't been noticed earlier, and in some cases, decide that it's better to get this debugged and fixed in the stable and development trees in parallel. 8 of them have been reported in March or earlier. [1] Patches for 2 of these 8 were available at the time of the release. [2] While the question whether to merge one of them into 2.6.21 was controversial, the other one was not controversial. I can imagine that the dvb oops bugfix got held back to avoid some noise with dvb developers who claimed that they didn't get notified about how that patch got into the v4l-dvb repository (it didn't get reviewed by these people for weeks because it simply got ignored and some of them were aware of that) On the other side if I read bugreports like the following one: http://www.mail-archive.com/linux-dvb%40linuxtv.org/msg23028.html (My Nova-T 500 crashes quite regularly. My machine has been running for about a week and in that time has had 5 oopses.) It doesn't solve the Nova-T disconnects, but it at least solves that the machine doesn't go down when this happens till the driver gets fixed. I think it would have been nice to get that patch into it Markus For one of the bugs, it became obvious when someone looked at it after the release of 2.6.21 that between the bug report on March 31th and the release of 2.6.21 on April 21th, noone started debugging this bug. [3] [4] And look e.g. at the many (and non-trivial) changes between -rc7 and -final, resulting in more than one report from people who were running -rc7 without problems - and 2.6.21 doesn't work for them. I agree that's unfortunate. It's not a choice between regressions don't matter and no regressions, it's about the place in the area between these two extremes. I have my opinions on what I want to expect from a stable Linux kernel, and other people have different opinins. Everyone is going to disagree to some extent; and their own comfort zone. So a certain amount compromise is always going to be necessary. Of course, it's up to you decide whether this has gone beyond the zone where you aren't comfortable working with other people's development style. Regards, - Ted cu Adrian [1] http://lkml.org/lkml/2007/4/26/2 [2] http://lkml.org/lkml/2007/4/25/496 [3] http://lkml.org/lkml/2007/4/26/496 [4] and although it turned out this specific regression was already fixed in 2.6.21, I hope you get my point -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Markus Rechberger - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
On 4/29/07, Linus Torvalds [EMAIL PROTECTED] wrote: On Sat, 28 Apr 2007, Adrian Bunk wrote: We are already quite good at ignoring bug reports that come through linux-kernel, and it's an _advantage_ of the kernel Bugzilla to see more than 1600 open bugs because this tells how bad we are at handling bugs. No, it just shows that bugzilla doesn't matter for most of the kernel. Don't say that bugzilla tells how bad we are at handling bugs. It tells how bad *bugzilla* is for handling bugs, nothing more. I totally disagree here, bugzilla is a very good tool. If someone is too lazy to look at it it's his problem. Kernel Janitors can pick out some bugs which aren't addressed by anyone or got left behind. I also found some bugs there which could have been solved by anyone here, the matter is just that many people aren't interested in mainly bug fixing and many also work on different other topics here. How else should bugs get handled, sending them to the lkml? I'm 100% sure some bugreports will also get lost then, but on the lkml they'll very likely remain lost whereas in the bugzilla they'll remain as open. Trying to play politics by pointing to bugzilla is pointless. Bugzilla is used for a few subsystems (ACPI seems to use it actively, for example), but I doubt most developers use it. as for the em28xx I actively use it, but I also set up a mailinglist etc. and there are many supporters already... Would be be good to have a better bug-tracking setup? Yes. But I think it takes man-power, and it would take something *fundamentally* better than bugzilla. what are your suggestions to improve a bugreporting tool, I'm very sure that many people, especially people who want to get into existing projects here, would love to contribute. Maybe the new http://kernelnewbies.org/known_regressions; thing will evolve to something worth tracking. Right now, bugzilla isn't it (although it can be a useful tracking place for individual bugs, *once* you've found and gotten the right developer involved - but that's a huge step that bugzilla generally does *not* do for us). I'd say this is a personal opinion, some people will get along with it and some of them will not... Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
On 4/29/07, Linus Torvalds [EMAIL PROTECTED] wrote: On Sun, 29 Apr 2007, Markus Rechberger wrote: I totally disagree here, bugzilla is a very good tool. If someone is too lazy to look at it it's his problem. You must be doing things very differently from a lot of other people if you think that's the case. Well I'm behind the stuff I'm doing because I'm interested in it. And if some bugs are introduced by my work or derived by my work I'd like to get them cleaned up in the end. If I see that someone reports bugs which doesn't really address my work at all I just forward them to the subsystem/maintainer who's in charge (if someone can say it that way for an open source project) Kernel Janitors can pick out some bugs which aren't addressed by anyone or got left behind. IF that happened, it would actually be great. That's what I'm arguing for. And it was basically what Adrian was doing! I'm very sure that happens maybe it's just not visible to everyone because there are so many open issues. (I just take myself as an example here, I didn't do too much with other bugs but at least some of my work closed 5 other bugs this year beside the bugreports I'm getting directly) How else should bugs get handled, sending them to the lkml? Actually, looking at Adrian's regression lists, yes. lkml worked better than bugzilla did. By at _least_ a factor of two. Yes Adrian did a very good job with collecting every bugreport and sending the mails to all corresponding subsystems. I'm 100% sure some bugreports will also get lost then, but on the lkml they'll very likely remain lost whereas in the bugzilla they'll remain as open. What's the difference between bugzilla and lkml.org? Both have search buttons. Both archive the old stuff. Both can be pointed to. Both have search buttons yes, but the lkml doesn't leave an unread mail open ontop of the lkml as bugzilla does if you look for open bugs in a subsystem. what are your suggestions to improve a bugreporting tool, I'm very sure that many people, especially people who want to get into existing projects here, would love to contribute. I don't know what the perfect setup is, but I do know that bugzilla is very close to be totally useless for the top-level maintainers. Try to think like a person who doesn't maintain *one* specific file in the kernel, but who can actually make a good judgement about a lot of things, or at least funnel a problem report to the right person? And now, imagine that that person is also fairly busy (exactly *because* he's not looking at a single file, he may be maintaining a huge subsystem that has multiple submaintainers etc). And ask yourself whether bugzilla really helps. bugzilla keeps the bugs open at least, at the lkml I use to skip days sometimes. Many people who consider themself as maintainer of a subsystem are assigned to a subsection on bugzilla, if it really doesn't work out we have to change the corresponding maintainer. If that maintainer doesn't know where to go with that bugreport he can easily send it to the lkml and some people will recognize the sender/email and pay extra attention to it (that's just how I think about it) I'd say this is a personal opinion, some people will get along with it and some of them will not... I think bugzilla really only works for very directed issues. If you already know exactly which driver is affected (which is often wrong anyway: some of the bugs that were due timer breakage got blamed as disk hangs!) it's almost totally useless. And yes, maybe that's why you have a much higher opinion of bugzilla than I do. To _me_ bugzilla is a total mess. There's absolutely _zero_ useful information there. And I'm pretty certain that is true of a *lot* of other people too. But if you have a small project, or you maintain a very specific (and clearly delineated) part of a big project, bugzilla probably looks a lot more palatable. well are there any bugs that cannot be forwarded/directed to a corresponding maintainer? Maybe I don't see something here, can you point me out to a bugreport which cannot be handled at all? As a reference I'll take following bugreport: http://thread.gmane.org/gmane.linux.kernel/521185 the bug doesn't even mention what device is affected, asking for further detailed information (dmesg) shows up what's left at least.. (in the meanwhile the bug even got solved) Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21
On 4/29/07, Bob Tracy [EMAIL PROTECTED] wrote: Linus Torvalds wrote: On Sun, 29 Apr 2007, Markus Rechberger wrote: How else should bugs get handled, sending them to the lkml? Actually, looking at Adrian's regression lists, yes. lkml worked better than bugzilla did. By at _least_ a factor of two. Since 1992, lkml (with Cc: to the appropriate subsystem mailing list if applicable) and the presumed responsible parties are the only channels I've used to report the bugs I encounter. since there are subsystems out there which are managed separatly this doesn't work out. I wasn't happy when I noticed that patches got applied to the sourcecode I contributed without notifying me while I still worked on that code separatly It was moreover the fault of the subsystem maintainer to not notify me back then but a centralized bugreporting (as bugzilla) tool would at least have notified me, or I would have been able to see the suggested changes there. But I agree with that if you're only 1 level far away from the linux kernel. Other methods come and go, but old habits die hard, particularly when they have a knack for producing the desired result. Historically, requiring a developer to fire up a GUI to read a bug report decreases the chance that bug report will be noticed. The development community can do whatever flips its collective switch as far as tracking bugs, but the bugs have to be reported and noticed before tracking becomes a meaningful activity. One more thought and I'll get off your screens... We've steadfastly resisted making lkml and friends subscriber-only mailing lists precisely because we don't want to miss a potential bug report because a would-be submitter isn't subscribed. If people aren't looking for bug reports here, what's the point? it's just easy to miss something here, if an ext3 bug comes in and all people who're involved in the ext3 filesytem are on vacation I'm sure they won't read all the mails which came in during a week, now take a part of the kernel which is smaller than the ext3 filesystem (eg. usb gadgets, smaller drivers) Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: More than 2Gb problem (dvb related) ?
Does this only happen with DVB and not with analogue TV (I know there are some cx88 hybrid devices out there, I recently got one but couldn't tested it yet ..)? Markus On 4/28/07, Robert Hancock <[EMAIL PROTECTED]> wrote: Gregoire Favre wrote: > Hello, > > I have a computer (mother Asus Commando) with 4x1Gb Ram. > > If I start without the BIOS remap memory, my BIOS and linux just see 2Gb > of ram, and DVB apps works just great. > > When I enable the remapping of the memory, my BIOS and linux just see > the whole 4Gb but then, I can tune to any transponder without problem, > but I am unable to get a TS... > > I have tested it with vdr/kaffeine/mplayer. > > szap/kaffeine/vdr get the lock just well. > > I had already asked about this on just linux-dvb ml, but maybe I am the > first one to try DVB with a system with more than 2 Gb as I didn't > receive any further info as someone get it working or not with such > amount of ram. > > Anyone got an idea on what could be done to solve this issue ? > > PLEASE CC to me all message in lkml as I am not subscribed to this ml :) Sounds like the cx88 driver is not using the DMA API properly to set up proper mappings, this will blow up if it tries to access memory above the 4GB mark if the device cannot do >32bit DMA.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Markus Rechberger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB updates
On 4/27/07, Trent Piepho <[EMAIL PROTECTED]> wrote:
On Mon, 16 Apr 2007, Markus Rechberger wrote:
> On 4/16/07, Michael Krufky <[EMAIL PROTECTED]> wrote:
> > Adrian Bunk wrote:
> > > On Sun, Apr 15, 2007 at 08:33:38PM -0400, Michael Krufky wrote:
> > >> Mauro,
> > >>
> > >> I've been out of town for the past few days... I just got home and
saw
> > this:
> > >>
> > >>
> > >> Mauro Carvalho Chehab wrote:
> > >>>- Fix 1/3 for bug 7819: fixed frontend hotplug issue
> > >>>- Fix 2/3 for bug 7819: demux and dvr
> > >>>- Fix 3/3 for bug 7819: fixed hotplugging for dvbnet
> > >> I don't think that this is 2.6.21 material. These patches have not
yet
> > >> received
> > >> enough testing to be sent to mainline.
I wish these patches had more comments about how they worked, because it's
not clear to me exactly what they are doing or why they do it.
Fix 3/3 for bug 7819: fixed hotplugging for dvbnet
I'm just going to talk about this one patch, since it appears to be the
simplest.
This patch removes the 'wait_queue' memory of dvb_demux. Why does a patch
to dvbnet have anything to do with the demux device? Should this change
have been part of the previous patch, the one what fixes demux and dvr?
The waitqueue got added in a previous patch just ignore it..
The patch replace the (file_operations)->release pointer with the new
function dvb_net_close() in place of dvb_generic_release(). The first
part of dvb_net_close() is just a cut from dvb_generic_release(),
so maybe it would be better to just call dvb_generic_release() instead?
no because it needs the dvb_net structure which cannot be used in the
dvb_generic_release function.
There is also a bug:
+static int dvb_net_close(struct inode *inode, struct file *file)
+{
+ struct dvb_device *dvbdev = file->private_data;
+ struct dvb_net *dvbnet = dvbdev->priv;
+
+ if (!dvbdev)
+ return -ENODEV;
The check for !dvbdev is too late, dvbdev was already dereferenced on the
previous line to get dvbnet, so if dvbdev is NULL you will have already
crashed.
I think this check isn't needed at all actually, why should someone
release dvbdev before already?
Is the check for !dvbdev unnecessary paranoia? Or can dvbdev actually be
NULL is some cases?
So, w.r.t. dvbnet, my understanding is that somehow dvb_net_release() is
called while the net device is still in use. Is that correct?
dvb_net_release() will end up deleting some stuff that needs to be around
while there is still a user of the device?
Would it be possible to keep dvb_net_release() from getting called in the
first place until there are no users of the device?
When looking at this code, keep in mind that users starts at 1 and goes
down as the device is used.
void dvb_net_release (struct dvb_net *dvbnet)
{
int i;
dvbnet->exit = 1;
if (dvbnet->dvbdev->users < 1) /* line A */
wait_event(dvbnet->dvbdev->wait_queue, /* line B */
dvbnet->dvbdev->users==1);
/* line C */
dvb_unregister_device(dvbnet->dvbdev);
[...]
}
Isn't there a race condition here? What if there are no users of the
device at the time line A runs, but the device is opened before line C
runs? After the wait_even() on line B returns there are no users, but what
if new users opens the device after the after line B?
yes this is a valid argument, practically it will never occure though.
Since I also wrote that I didn't have a dvb signal at the time of
writing this I don't even know if the dvb-net implementation is ok at
all.
I don't even know if that part of the framework works and if someone
really uses it.
Is seems like you need something to prevent new users from opening the
device, i.e. make it so that dvbnet->exit=1 prevents the device from
getting opened, but if that's the intention, I don't see where it's
happening.
In dvb_net_close():
+ if(dvbdev->users == 1 && dvbnet->exit==1) {
+ fops_put(file->f_op);
+ file->f_op = NULL;
+ wake_up(>wait_queue);
+ }
What is the purpose of the fops_put() call and setting file->f_op to NULL?
fops_put lowers the usecount on the inode, after wake_up the f_op
structure is invalid because it's just allocated memory which gets
freed by the dvb release function.
thanks for reviewing,
Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: More than 2Gb problem (dvb related) ?
just for the completeness, what does dmesg show up? You forgot to mention what device you have too... Markus On 4/27/07, Gregoire Favre <[EMAIL PROTECTED]> wrote: Hello, I have a computer (mother Asus Commando) with 4x1Gb Ram. If I start without the BIOS remap memory, my BIOS and linux just see 2Gb of ram, and DVB apps works just great. When I enable the remapping of the memory, my BIOS and linux just see the whole 4Gb but then, I can tune to any transponder without problem, but I am unable to get a TS... I have tested it with vdr/kaffeine/mplayer. szap/kaffeine/vdr get the lock just well. I had already asked about this on just linux-dvb ml, but maybe I am the first one to try DVB with a system with more than 2 Gb as I didn't receive any further info as someone get it working or not with such amount of ram. Anyone got an idea on what could be done to solve this issue ? PLEASE CC to me all message in lkml as I am not subscribed to this ml :) -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Markus Rechberger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: More than 2Gb problem (dvb related) ?
just for the completeness, what does dmesg show up? You forgot to mention what device you have too... Markus On 4/27/07, Gregoire Favre [EMAIL PROTECTED] wrote: Hello, I have a computer (mother Asus Commando) with 4x1Gb Ram. If I start without the BIOS remap memory, my BIOS and linux just see 2Gb of ram, and DVB apps works just great. When I enable the remapping of the memory, my BIOS and linux just see the whole 4Gb but then, I can tune to any transponder without problem, but I am unable to get a TS... I have tested it with vdr/kaffeine/mplayer. szap/kaffeine/vdr get the lock just well. I had already asked about this on just linux-dvb ml, but maybe I am the first one to try DVB with a system with more than 2 Gb as I didn't receive any further info as someone get it working or not with such amount of ram. Anyone got an idea on what could be done to solve this issue ? PLEASE CC to me all message in lkml as I am not subscribed to this ml :) -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Markus Rechberger - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB updates
On 4/27/07, Trent Piepho [EMAIL PROTECTED] wrote:
On Mon, 16 Apr 2007, Markus Rechberger wrote:
On 4/16/07, Michael Krufky [EMAIL PROTECTED] wrote:
Adrian Bunk wrote:
On Sun, Apr 15, 2007 at 08:33:38PM -0400, Michael Krufky wrote:
Mauro,
I've been out of town for the past few days... I just got home and
saw
this:
Mauro Carvalho Chehab wrote:
- Fix 1/3 for bug 7819: fixed frontend hotplug issue
- Fix 2/3 for bug 7819: demux and dvr
- Fix 3/3 for bug 7819: fixed hotplugging for dvbnet
I don't think that this is 2.6.21 material. These patches have not
yet
received
enough testing to be sent to mainline.
I wish these patches had more comments about how they worked, because it's
not clear to me exactly what they are doing or why they do it.
Fix 3/3 for bug 7819: fixed hotplugging for dvbnet
I'm just going to talk about this one patch, since it appears to be the
simplest.
This patch removes the 'wait_queue' memory of dvb_demux. Why does a patch
to dvbnet have anything to do with the demux device? Should this change
have been part of the previous patch, the one what fixes demux and dvr?
The waitqueue got added in a previous patch just ignore it..
The patch replace the (file_operations)-release pointer with the new
function dvb_net_close() in place of dvb_generic_release(). The first
part of dvb_net_close() is just a cutpaste from dvb_generic_release(),
so maybe it would be better to just call dvb_generic_release() instead?
no because it needs the dvb_net structure which cannot be used in the
dvb_generic_release function.
There is also a bug:
+static int dvb_net_close(struct inode *inode, struct file *file)
+{
+ struct dvb_device *dvbdev = file-private_data;
+ struct dvb_net *dvbnet = dvbdev-priv;
+
+ if (!dvbdev)
+ return -ENODEV;
The check for !dvbdev is too late, dvbdev was already dereferenced on the
previous line to get dvbnet, so if dvbdev is NULL you will have already
crashed.
I think this check isn't needed at all actually, why should someone
release dvbdev before already?
Is the check for !dvbdev unnecessary paranoia? Or can dvbdev actually be
NULL is some cases?
So, w.r.t. dvbnet, my understanding is that somehow dvb_net_release() is
called while the net device is still in use. Is that correct?
dvb_net_release() will end up deleting some stuff that needs to be around
while there is still a user of the device?
Would it be possible to keep dvb_net_release() from getting called in the
first place until there are no users of the device?
When looking at this code, keep in mind that users starts at 1 and goes
down as the device is used.
void dvb_net_release (struct dvb_net *dvbnet)
{
int i;
dvbnet-exit = 1;
if (dvbnet-dvbdev-users 1) /* line A */
wait_event(dvbnet-dvbdev-wait_queue, /* line B */
dvbnet-dvbdev-users==1);
/* line C */
dvb_unregister_device(dvbnet-dvbdev);
[...]
}
Isn't there a race condition here? What if there are no users of the
device at the time line A runs, but the device is opened before line C
runs? After the wait_even() on line B returns there are no users, but what
if new users opens the device after the after line B?
yes this is a valid argument, practically it will never occure though.
Since I also wrote that I didn't have a dvb signal at the time of
writing this I don't even know if the dvb-net implementation is ok at
all.
I don't even know if that part of the framework works and if someone
really uses it.
Is seems like you need something to prevent new users from opening the
device, i.e. make it so that dvbnet-exit=1 prevents the device from
getting opened, but if that's the intention, I don't see where it's
happening.
In dvb_net_close():
+ if(dvbdev-users == 1 dvbnet-exit==1) {
+ fops_put(file-f_op);
+ file-f_op = NULL;
+ wake_up(dvbdev-wait_queue);
+ }
What is the purpose of the fops_put() call and setting file-f_op to NULL?
fops_put lowers the usecount on the inode, after wake_up the f_op
structure is invalid because it's just allocated memory which gets
freed by the dvb release function.
thanks for reviewing,
Markus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: More than 2Gb problem (dvb related) ?
Does this only happen with DVB and not with analogue TV (I know there are some cx88 hybrid devices out there, I recently got one but couldn't tested it yet ..)? Markus On 4/28/07, Robert Hancock [EMAIL PROTECTED] wrote: Gregoire Favre wrote: Hello, I have a computer (mother Asus Commando) with 4x1Gb Ram. If I start without the BIOS remap memory, my BIOS and linux just see 2Gb of ram, and DVB apps works just great. When I enable the remapping of the memory, my BIOS and linux just see the whole 4Gb but then, I can tune to any transponder without problem, but I am unable to get a TS... I have tested it with vdr/kaffeine/mplayer. szap/kaffeine/vdr get the lock just well. I had already asked about this on just linux-dvb ml, but maybe I am the first one to try DVB with a system with more than 2 Gb as I didn't receive any further info as someone get it working or not with such amount of ram. Anyone got an idea on what could be done to solve this issue ? PLEASE CC to me all message in lkml as I am not subscribed to this ml :) Sounds like the cx88 driver is not using the DMA API properly to set up proper mappings, this will blow up if it tries to access memory above the 4GB mark if the device cannot do 32bit DMA.. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Markus Rechberger - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel IOMMU][patch 6/8] Doc updates for Intel Virtualization Technology for Directed I/O.
- linux-2.6.21-rc5.orig/Documentation/kernel-parameters.txt 2007-04-17 04:59:42.0 -0700 +++ linux-2.6.21-rc5/Documentation/kernel-parameters.txt2007-04-17 05:41:56.0 -0700 @@ -710,6 +710,26 @@ inttest=[IA64] + intel_iommu=[DMAR] Intel IOMMU driver (DMAR) option + off + Disable intel iommu driver. + forcerw + Some drivers might incorrectly map DMA buffers as + write-only even when the device, requires read/write + mapping. This option works around the issue in IOMMU + driver by making all write-only map as read/write. + Default is off. + igfx_off [Default Off] + By default, gfx is mapped as normal device. If a gfx + device has a dedicated DMAR unit, the DMAR unit is + bypassed with this option. In this case, gfx device + will use physical address for DMA. + gfx_workaround [Default Off] + gfx devices tend to use physical address for DMA and + avoid using DMA api's. Setting this option permits + the IOMMU driver to set a unity map for all OS + visible memory. Hence the driver can continue to use + physical addresses for DMA. io7=[HW] IO7 for Marvel based alpha systems See comment before marvel_specify_io7 in arch/alpha/kernel/core_marvel.c. -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Markus Rechberger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel IOMMU][patch 6/8] Doc updates for Intel Virtualization Technology for Directed I/O.
/Documentation/kernel-parameters.txt 2007-04-17 04:59:42.0 -0700 +++ linux-2.6.21-rc5/Documentation/kernel-parameters.txt2007-04-17 05:41:56.0 -0700 @@ -710,6 +710,26 @@ inttest=[IA64] + intel_iommu=[DMAR] Intel IOMMU driver (DMAR) option + off + Disable intel iommu driver. + forcerw + Some drivers might incorrectly map DMA buffers as + write-only even when the device, requires read/write + mapping. This option works around the issue in IOMMU + driver by making all write-only map as read/write. + Default is off. + igfx_off [Default Off] + By default, gfx is mapped as normal device. If a gfx + device has a dedicated DMAR unit, the DMAR unit is + bypassed with this option. In this case, gfx device + will use physical address for DMA. + gfx_workaround [Default Off] + gfx devices tend to use physical address for DMA and + avoid using DMA api's. Setting this option permits + the IOMMU driver to set a unity map for all OS + visible memory. Hence the driver can continue to use + physical addresses for DMA. io7=[HW] IO7 for Marvel based alpha systems See comment before marvel_specify_io7 in arch/alpha/kernel/core_marvel.c. -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Markus Rechberger - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops on 2.6.21 with dvb-usb-dib0700?
Hi, this will be fixed in upcoming kernel releases, there's already a patch for that in the video4linux/dvb repository on linuxtv.org. So if you update your v4l-dvb drivers that problem shouldn't occure anymore. http://linuxtv.org/repo/ -Markus On 4/19/07, Chris Murton <[EMAIL PROTECTED]> wrote: > Hi, > > Get an occasional Oops which can occur either when the device is in use, > or idle.. and it only usually happens after several hours of uptime with > the module and device loaded. The 'oops' seems to directly correlate > with the device appearing to disconnect and reconnect via USB (but > nothing physical has changed). > > In this example, the box was booted at 21:50 and the Oops occurred at > 03:13 when the device was idle: > > Apr 19 03:13:01 basil kernel: usb 2-1: USB disconnect, address 2 > Apr 19 03:13:01 basil kernel: ehci_hcd :04:08.2: qh 81003dbc61e0 > (#82) state 4(has tds) > Apr 19 03:13:01 basil kernel: mt2060 I2C write failed > Apr 19 03:13:01 basil kernel: mt2060 I2C write failed > Apr 19 03:13:01 basil kernel: dvb-usb: Hauppauge Nova-T 500 Dual DVB-T > successfully deinitialized and disconnected. > Apr 19 03:13:02 basil kernel: usb 2-1: new high speed USB device using > ehci_hcd and address 3 > Apr 19 03:13:02 basil kernel: usb 2-1: configuration #1 chosen from 1 choice > Apr 19 03:13:02 basil kernel: dvb-usb: found a 'Hauppauge Nova-T 500 > Dual DVB-T' in warm state. > Apr 19 03:13:02 basil kernel: **WARNING** I2C adapter driver [Hauppauge > Nova-T 500 Dual DVB-T] forgot to specify physical device; fi > x it! > Apr 19 03:13:02 basil kernel: dvb-usb: will pass the complete MPEG2 > transport stream to the software demuxer. > Apr 19 03:13:02 basil kernel: DVB: registering new adapter (Hauppauge > Nova-T 500 Dual DVB-T). > Apr 19 03:13:02 basil kernel: **WARNING** I2C adapter driver [DiBX000 > tuner I2C bus] forgot to specify physical device; fix it! > Apr 19 03:13:02 basil kernel: DVB: registering frontend 0 (DiBcom > 3000MC/P)... > Apr 19 03:13:02 basil kernel: MT2060: successfully identified (IF1 = 1220) > Apr 19 03:13:02 basil kernel: dvb-usb: will pass the complete MPEG2 > transport stream to the software demuxer. > Apr 19 03:13:02 basil kernel: DVB: registering new adapter (Hauppauge > Nova-T 500 Dual DVB-T). > Apr 19 03:13:02 basil kernel: **WARNING** I2C adapter driver [DiBX000 > tuner I2C bus] forgot to specify physical device; fix it! > Apr 19 03:13:02 basil kernel: DVB: registering frontend 1 (DiBcom > 3000MC/P)... > Apr 19 03:13:02 basil kernel: MT2060: successfully identified (IF1 = 1220) > Apr 19 03:13:03 basil kernel: dvb-usb: Hauppauge Nova-T 500 Dual DVB-T > successfully initialized and connected. > Apr 19 03:17:30 basil kernel: Unable to handle kernel NULL pointer > dereference at RIP: > Apr 19 03:17:30 basil kernel: [] > __mutex_lock_interruptible_slowpath+0x22/0x99 > Apr 19 03:17:30 basil kernel: PGD 13042067 PUD 13043067 PMD 0 > Apr 19 03:17:30 basil kernel: Oops: 0002 [1] > Apr 19 03:17:30 basil kernel: CPU 0 > Apr 19 03:17:30 basil kernel: Modules linked in: nvidia(P) snd_mpu401 > snd_mpu401_uart snd_seq_midi snd_seq_midi_event snd_hda_intel > snd_hda_codec snd_seq snd_pcm_oss snd_mixer_oss dvb_usb_dib0700 dib7000m > dib7000p dvb_usb snd_rawmidi dvb_core snd_pcm snd_timer snd > _seq_device lirc_imon lirc_mceusb2 lirc_dev dvb_pll dib3000mc > dibx000_common mt2060 snd_page_alloc > Apr 19 03:17:30 basil kernel: Pid: 7860, comm: mythbackend Tainted: > P 2.6.20 #1 > Apr 19 03:17:30 basil kernel: RIP: 0010:[] > [] __mutex_lock_interruptible_slowpath+0x22/0x99 > Apr 19 03:17:30 basil kernel: RSP: 0018:81002e929ea8 EFLAGS: 00010292 > Apr 19 03:17:30 basil kernel: RAX: c200101ad0a0 RBX: > c200101ad098 RCX: > Apr 19 03:17:30 basil kernel: RDX: 81002e929fd8 RSI: > 8100331ee980 RDI: c200101ad098 > Apr 19 03:17:30 basil kernel: RBP: 810034403200 R08: > R09: 1eb4 > Apr 19 03:17:30 basil kernel: R10: R11: > 0206 R12: c200101ad098 > Apr 19 03:17:30 basil kernel: R13: 81003cff7418 R14: > 81003da1a8c0 R15: 81003c997b70 > Apr 19 03:17:30 basil kernel: FS: 4a816960(0063) > GS:80615000() knlGS:f7db58c0 > Apr 19 03:17:30 basil kernel: CS: 0010 DS: ES: CR0: > 8005003b > Apr 19 03:17:30 basil kernel: CR2: CR3: > 13041000 CR4: 06e0 > Apr 19 03:17:30 basil kernel: Process mythbackend (pid: 7860, threadinfo > 81002e928000, task 810034403200) > Apr 19 03:17:30 basil kernel: Stack: c200101ad0a0 > 0008 > Apr 19 03:17:30 basil kernel: 81003c542fa0 c200101ad000 > 81003c542fa0 88043d22 > Apr 19 03:17:30 basil kernel: 0008 8100331ee980 > 81003cff7418 802618ec > Apr 19 03:17:30 basil kernel: Call Trace: > Apr 19 03:17:30 basil kernel: [] >
Re: Oops on 2.6.21 with dvb-usb-dib0700?
Hi, this will be fixed in upcoming kernel releases, there's already a patch for that in the video4linux/dvb repository on linuxtv.org. So if you update your v4l-dvb drivers that problem shouldn't occure anymore. http://linuxtv.org/repo/ -Markus On 4/19/07, Chris Murton [EMAIL PROTECTED] wrote: Hi, Get an occasional Oops which can occur either when the device is in use, or idle.. and it only usually happens after several hours of uptime with the module and device loaded. The 'oops' seems to directly correlate with the device appearing to disconnect and reconnect via USB (but nothing physical has changed). In this example, the box was booted at 21:50 and the Oops occurred at 03:13 when the device was idle: Apr 19 03:13:01 basil kernel: usb 2-1: USB disconnect, address 2 Apr 19 03:13:01 basil kernel: ehci_hcd :04:08.2: qh 81003dbc61e0 (#82) state 4(has tds) Apr 19 03:13:01 basil kernel: mt2060 I2C write failed Apr 19 03:13:01 basil kernel: mt2060 I2C write failed Apr 19 03:13:01 basil kernel: dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully deinitialized and disconnected. Apr 19 03:13:02 basil kernel: usb 2-1: new high speed USB device using ehci_hcd and address 3 Apr 19 03:13:02 basil kernel: usb 2-1: configuration #1 chosen from 1 choice Apr 19 03:13:02 basil kernel: dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state. Apr 19 03:13:02 basil kernel: **WARNING** I2C adapter driver [Hauppauge Nova-T 500 Dual DVB-T] forgot to specify physical device; fi x it! Apr 19 03:13:02 basil kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Apr 19 03:13:02 basil kernel: DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T). Apr 19 03:13:02 basil kernel: **WARNING** I2C adapter driver [DiBX000 tuner I2C bus] forgot to specify physical device; fix it! Apr 19 03:13:02 basil kernel: DVB: registering frontend 0 (DiBcom 3000MC/P)... Apr 19 03:13:02 basil kernel: MT2060: successfully identified (IF1 = 1220) Apr 19 03:13:02 basil kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Apr 19 03:13:02 basil kernel: DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T). Apr 19 03:13:02 basil kernel: **WARNING** I2C adapter driver [DiBX000 tuner I2C bus] forgot to specify physical device; fix it! Apr 19 03:13:02 basil kernel: DVB: registering frontend 1 (DiBcom 3000MC/P)... Apr 19 03:13:02 basil kernel: MT2060: successfully identified (IF1 = 1220) Apr 19 03:13:03 basil kernel: dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized and connected. Apr 19 03:17:30 basil kernel: Unable to handle kernel NULL pointer dereference at RIP: Apr 19 03:17:30 basil kernel: [804a4af2] __mutex_lock_interruptible_slowpath+0x22/0x99 Apr 19 03:17:30 basil kernel: PGD 13042067 PUD 13043067 PMD 0 Apr 19 03:17:30 basil kernel: Oops: 0002 [1] Apr 19 03:17:30 basil kernel: CPU 0 Apr 19 03:17:30 basil kernel: Modules linked in: nvidia(P) snd_mpu401 snd_mpu401_uart snd_seq_midi snd_seq_midi_event snd_hda_intel snd_hda_codec snd_seq snd_pcm_oss snd_mixer_oss dvb_usb_dib0700 dib7000m dib7000p dvb_usb snd_rawmidi dvb_core snd_pcm snd_timer snd _seq_device lirc_imon lirc_mceusb2 lirc_dev dvb_pll dib3000mc dibx000_common mt2060 snd_page_alloc Apr 19 03:17:30 basil kernel: Pid: 7860, comm: mythbackend Tainted: P 2.6.20 #1 Apr 19 03:17:30 basil kernel: RIP: 0010:[804a4af2] [804a4af2] __mutex_lock_interruptible_slowpath+0x22/0x99 Apr 19 03:17:30 basil kernel: RSP: 0018:81002e929ea8 EFLAGS: 00010292 Apr 19 03:17:30 basil kernel: RAX: c200101ad0a0 RBX: c200101ad098 RCX: Apr 19 03:17:30 basil kernel: RDX: 81002e929fd8 RSI: 8100331ee980 RDI: c200101ad098 Apr 19 03:17:30 basil kernel: RBP: 810034403200 R08: R09: 1eb4 Apr 19 03:17:30 basil kernel: R10: R11: 0206 R12: c200101ad098 Apr 19 03:17:30 basil kernel: R13: 81003cff7418 R14: 81003da1a8c0 R15: 81003c997b70 Apr 19 03:17:30 basil kernel: FS: 4a816960(0063) GS:80615000() knlGS:f7db58c0 Apr 19 03:17:30 basil kernel: CS: 0010 DS: ES: CR0: 8005003b Apr 19 03:17:30 basil kernel: CR2: CR3: 13041000 CR4: 06e0 Apr 19 03:17:30 basil kernel: Process mythbackend (pid: 7860, threadinfo 81002e928000, task 810034403200) Apr 19 03:17:30 basil kernel: Stack: c200101ad0a0 0008 Apr 19 03:17:30 basil kernel: 81003c542fa0 c200101ad000 81003c542fa0 88043d22 Apr 19 03:17:30 basil kernel: 0008 8100331ee980 81003cff7418 802618ec Apr 19 03:17:30 basil kernel: Call Trace: Apr 19 03:17:30 basil kernel: [88043d22] :dvb_core:dvb_demux_release+0x37/0xba
Re: [linux-dvb] Re: [video4linux-cvs] [hg:v4l-dvb] Add support for Opera S1- DVB-USB
On 4/20/07, Manu Abraham <[EMAIL PROTECTED]> wrote: hermann pitton wrote: > Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham: >> Mauro Carvalho Chehab wrote: >>> Em Qui, 2007-04-19 às 16:41 -0400, Michael Krufky escreveu: Marco Gittler wrote: > this patch has applied the hints from mkrufky (dvb_attach, > firmware-naming) > and also one working rewrite of the i2c addresses stuff to fit the > kernel i2c reqs. > > Signed-off-by: Marco Gittler<[EMAIL PROTECTED]> > diff -r c8b73ec18b42 linux/drivers/media/dvb/dvb-usb/opera1.c > --- a/linux/drivers/media/dvb/dvb-usb/opera1.c Thu Apr 19 12:04:50 2007 -0300 > +++ b/linux/drivers/media/dvb/dvb-usb/opera1.c Thu Apr 19 20:38:01 2007 +0200 > @@ -25,6 +25,13 @@ > #define REG_20_SYMBOLRATE_BYTE1 0x20 > #define REG_21_SYMBOLRATE_BYTE2 0x21 > > +#define ADDR_C0_TUNER (0xc0>>1) > +#define ADDR_D0_PLL (0xd0>>1) > I don't like these two #define's. These i2c addresses need only be specified once, in the config structs / frontendfoo_attach calls for the tuner / demod. Better to just put them in as constants like all of the other dvb drivers. >>> I prefer the way it is. We should really avoid having magic numbers >>> inside the code. The alias here helps to know that 0x60 is tuner addres >>> and 0x68 the pll. >> >> Following a project's coding styles and conventions is "respecting" a >> project >> >> Manu >> > > Hi, > > the other natural place for this should be the LKML to get more _good_ > arguments, instead of hanging soon in some "respect" stuff again. DVB drivers generally have device addresses such as tuner_addresses and demod_adresses defined in a config struct least to prevent them from being global, wherever the header is included, since the very same device can have multiple addresses and so on, which are non-probable since being behind a repeater which is switched by a demod (private) and hence. Those are some of the reasons to follow a certain coding style/conventions. They are _not_ for fun. cat *priv.h says something else too... there are also many global register defines in DVB drivers, they just don't include the register value in the define name. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] Re: [video4linux-cvs] [hg:v4l-dvb] Add support for Opera S1- DVB-USB
On 4/20/07, Manu Abraham [EMAIL PROTECTED] wrote: hermann pitton wrote: Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham: Mauro Carvalho Chehab wrote: Em Qui, 2007-04-19 às 16:41 -0400, Michael Krufky escreveu: Marco Gittler wrote: this patch has applied the hints from mkrufky (dvb_attach, firmware-naming) and also one working rewrite of the i2c addresses stuff to fit the kernel i2c reqs. Signed-off-by: Marco Gittler[EMAIL PROTECTED] diff -r c8b73ec18b42 linux/drivers/media/dvb/dvb-usb/opera1.c --- a/linux/drivers/media/dvb/dvb-usb/opera1.c Thu Apr 19 12:04:50 2007 -0300 +++ b/linux/drivers/media/dvb/dvb-usb/opera1.c Thu Apr 19 20:38:01 2007 +0200 @@ -25,6 +25,13 @@ #define REG_20_SYMBOLRATE_BYTE1 0x20 #define REG_21_SYMBOLRATE_BYTE2 0x21 +#define ADDR_C0_TUNER (0xc01) +#define ADDR_D0_PLL (0xd01) I don't like these two #define's. These i2c addresses need only be specified once, in the config structs / frontendfoo_attach calls for the tuner / demod. Better to just put them in as constants like all of the other dvb drivers. I prefer the way it is. We should really avoid having magic numbers inside the code. The alias here helps to know that 0x60 is tuner addres and 0x68 the pll. Following a project's coding styles and conventions is respecting a project Manu Hi, the other natural place for this should be the LKML to get more _good_ arguments, instead of hanging soon in some respect stuff again. DVB drivers generally have device addresses such as tuner_addresses and demod_adresses defined in a config struct least to prevent them from being global, wherever the header is included, since the very same device can have multiple addresses and so on, which are non-probable since being behind a repeater which is switched by a demod (private) and hence. Those are some of the reasons to follow a certain coding style/conventions. They are _not_ for fun. cat *priv.h says something else too... there are also many global register defines in DVB drivers, they just don't include the register value in the define name. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB updates
On 4/16/07, Michael Krufky <[EMAIL PROTECTED]> wrote: Adrian Bunk wrote: > On Sun, Apr 15, 2007 at 08:33:38PM -0400, Michael Krufky wrote: >> Mauro, >> >> I've been out of town for the past few days... I just got home and saw this: >> >> >> Mauro Carvalho Chehab wrote: >>>- Fix 1/3 for bug 7819: fixed frontend hotplug issue >>>- Fix 2/3 for bug 7819: demux and dvr >>>- Fix 3/3 for bug 7819: fixed hotplugging for dvbnet >> I don't think that this is 2.6.21 material. These patches have not yet >> received >> enough testing to be sent to mainline. >> >> I have tested them, and they seem to work for my cxusb device, but we have >> yet to hear test results from users of usb dvb devices that do not use the >> dvb-usb framework. (ttusb, flexcop-usb, cinergyT2, for example) >> >> The bug that these patches fix has been around throughout the entire kernel >> history of the dvb subsystem. The bug is not a regression -- it has >> always been >> there. In my opinion, it is too late in 2.6.21 development to apply >> this change. >> Because these fixes are not obvious, I think we should let them get some >> more testing, and have them queued for 2.6.22 . > > Unless I misunderstand anything, this should fix [1]. > > And this is a bug that was reported to be present in 2.6.21-rc but not > in 2.6.20 (and it's therefore a regression, no matter whether the > underlying problem was older and only exposed by some other change). Not true. The DVB subsystem has NEVER been hot-unpluggable. I confirm that the patches SEEM to be correct, but this has not yet been verified. None of the authors of dvb-core gave their ACK on these changesets. The DVB hotplug issue has been around since the very beginning. I assure you, that I consider this fix to be very important, and I really would love to see it hit mainline. However, given the situation, it is not appropriate to push these in during -rc7 I have doubts on CIJOML's testing method -- there is no way he could have unplugged the device while in use, while running 2.6.20.y and not receive an OOPS. CIJOML, please see the bottom of this email for Sure, this will prevent an OOPS on some, and hopefully all devices... but what if it causes a regression for those untested? Why do we have a merge window, if new changesets are going to be rushed into late -rc kernels without proper testing, and without the ack of a dvb subsystem maintainer? Are we prepared to go for another -rc and 3 or 4 weeks of testing to confirm that this fix doesn't cause new regressions? I don't think so. The problem I see with the cinergyT2 is that this driver reimplements the frontend code and doesn't even use the dvb-core template, so a proper fix would also be to reimplement that fix in the cinergyT2 device. I don't think Daniel Mack or Holger Waechtler manage this driver anymore because they didn't comment the last few fixes that were applied to that driver (though I put them into CC here) As far as I remember someone wrote that they didn't want to use the dvb_frontend code back then for any reason. So the only driver I'd take into account would be the flexcop driver. Currently tested drivers are: dvb-usb based devices, and em28xx/em2880 based devices Markus Markus Rechberger wrote: > The patch has been around on the dvb mailinglist ([PATCH][RFC] DVB > Hotplug Fix, 5. April 2007), The patch was merged into the development repository at the same time the pull request was issued to Linus. This has NOT been tested on a wide scale. It should go to -mm for a while before being merged to mainline. Mauro Carvalho Chehab wrote: > I also explicitly warned at DVB ML that I were about to send this patch, > together with other fixes, asking the community for more tests. After > that, I received two positive answers on my mailbox from people that > tested and noticed that this really fixed the issue. One of those positive answers was me - I explained that it worked for me, but we need others to test. You waited ONE DAY after sending this "warning" to the dvb mailing list? ( http://linuxtv.org/pipermail/linux-dvb/2007-April/017204.html ) I saw that email after seeing the pull request to Linus. We dont have users testing the repositories after each commit -- you _really_ need to give some more time to allow for such testing. CIJOML wrote: > Hi, > > I have tested these patches with: > > Freecom DVB-T dongle > Pluto2 pcmcia card > Leadtek WinFast DTV dongle 1st generation > Leadtek WinFast DTV dongle 2nd generation > > These are 4 different devices with 4 different hw and modules. > All works. Please apply. Well, that helps... But it would still be nice to hear test results on a CinergyT2 or flexcop-usb. Which driver supports those Winfast don
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB updates
On 4/16/07, Manu Abraham <[EMAIL PROTECTED]> wrote: Michael Krufky wrote: > Mauro, > > I've been out of town for the past few days... I just got home and saw this: > > > Mauro Carvalho Chehab wrote: >>- Fix 1/3 for bug 7819: fixed frontend hotplug issue >>- Fix 2/3 for bug 7819: demux and dvr >>- Fix 3/3 for bug 7819: fixed hotplugging for dvbnet > I don't think that this is 2.6.21 material. These patches have not yet > received > enough testing to be sent to mainline. > > I have tested them, and they seem to work for my cxusb device, but we have > yet to hear test results from users of usb dvb devices that do not use the > dvb-usb framework. (ttusb, flexcop-usb, cinergyT2, for example) > > The bug that these patches fix has been around throughout the entire kernel > history of the dvb subsystem. The bug is not a regression -- it has > always been > there. In my opinion, it is too late in 2.6.21 development to apply > this change. > Because these fixes are not obvious, I think we should let them get some > more testing, and have them queued for 2.6.22 . I am not arguing about the veracity of the patches, but how things are handled. Agreed to all the mentioned above. There is one more aspect. The mentioned patches, do not have any ACK/SOB from any DVB developer/maintainer for the same. Huge regressions are created this way. One more time the regression creator is caught. The patch has been around on the dvb mailinglist ([PATCH][RFC] DVB Hotplug Fix, 5. April 2007), Michael looked at it when I told him about it again separatly (12. April 2007) Between that there was enough time to respond on it or review it. Mauro told me at the beginning if noone responds he'll go forward somehow because it fixes hotplugging, and after 2 weeks I wouldn't expect anyone commenting that thread anymore. It would be better to look and respond to that patch first before responding about that you don't like how it's handled, Mauro also wrote in his announcement that people should look at the recent mercurial tree and he'll revert it if something doesn't work by accident before submitting it to his git tree... still noone complained about the hotplugging patch in there. Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB updates
On 4/16/07, Manu Abraham [EMAIL PROTECTED] wrote: Michael Krufky wrote: Mauro, I've been out of town for the past few days... I just got home and saw this: Mauro Carvalho Chehab wrote: - Fix 1/3 for bug 7819: fixed frontend hotplug issue - Fix 2/3 for bug 7819: demux and dvr - Fix 3/3 for bug 7819: fixed hotplugging for dvbnet I don't think that this is 2.6.21 material. These patches have not yet received enough testing to be sent to mainline. I have tested them, and they seem to work for my cxusb device, but we have yet to hear test results from users of usb dvb devices that do not use the dvb-usb framework. (ttusb, flexcop-usb, cinergyT2, for example) The bug that these patches fix has been around throughout the entire kernel history of the dvb subsystem. The bug is not a regression -- it has always been there. In my opinion, it is too late in 2.6.21 development to apply this change. Because these fixes are not obvious, I think we should let them get some more testing, and have them queued for 2.6.22 . I am not arguing about the veracity of the patches, but how things are handled. Agreed to all the mentioned above. There is one more aspect. The mentioned patches, do not have any ACK/SOB from any DVB developer/maintainer for the same. Huge regressions are created this way. One more time the regression creator is caught. The patch has been around on the dvb mailinglist ([PATCH][RFC] DVB Hotplug Fix, 5. April 2007), Michael looked at it when I told him about it again separatly (12. April 2007) Between that there was enough time to respond on it or review it. Mauro told me at the beginning if noone responds he'll go forward somehow because it fixes hotplugging, and after 2 weeks I wouldn't expect anyone commenting that thread anymore. It would be better to look and respond to that patch first before responding about that you don't like how it's handled, Mauro also wrote in his announcement that people should look at the recent mercurial tree and he'll revert it if something doesn't work by accident before submitting it to his git tree... still noone complained about the hotplugging patch in there. Markus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4l-dvb-maintainer] [GIT PATCHES] V4L/DVB updates
On 4/16/07, Michael Krufky [EMAIL PROTECTED] wrote: Adrian Bunk wrote: On Sun, Apr 15, 2007 at 08:33:38PM -0400, Michael Krufky wrote: Mauro, I've been out of town for the past few days... I just got home and saw this: Mauro Carvalho Chehab wrote: - Fix 1/3 for bug 7819: fixed frontend hotplug issue - Fix 2/3 for bug 7819: demux and dvr - Fix 3/3 for bug 7819: fixed hotplugging for dvbnet I don't think that this is 2.6.21 material. These patches have not yet received enough testing to be sent to mainline. I have tested them, and they seem to work for my cxusb device, but we have yet to hear test results from users of usb dvb devices that do not use the dvb-usb framework. (ttusb, flexcop-usb, cinergyT2, for example) The bug that these patches fix has been around throughout the entire kernel history of the dvb subsystem. The bug is not a regression -- it has always been there. In my opinion, it is too late in 2.6.21 development to apply this change. Because these fixes are not obvious, I think we should let them get some more testing, and have them queued for 2.6.22 . Unless I misunderstand anything, this should fix [1]. And this is a bug that was reported to be present in 2.6.21-rc but not in 2.6.20 (and it's therefore a regression, no matter whether the underlying problem was older and only exposed by some other change). Not true. The DVB subsystem has NEVER been hot-unpluggable. I confirm that the patches SEEM to be correct, but this has not yet been verified. None of the authors of dvb-core gave their ACK on these changesets. The DVB hotplug issue has been around since the very beginning. I assure you, that I consider this fix to be very important, and I really would love to see it hit mainline. However, given the situation, it is not appropriate to push these in during -rc7 I have doubts on CIJOML's testing method -- there is no way he could have unplugged the device while in use, while running 2.6.20.y and not receive an OOPS. CIJOML, please see the bottom of this email for Sure, this will prevent an OOPS on some, and hopefully all devices... but what if it causes a regression for those untested? Why do we have a merge window, if new changesets are going to be rushed into late -rc kernels without proper testing, and without the ack of a dvb subsystem maintainer? Are we prepared to go for another -rc and 3 or 4 weeks of testing to confirm that this fix doesn't cause new regressions? I don't think so. The problem I see with the cinergyT2 is that this driver reimplements the frontend code and doesn't even use the dvb-core template, so a proper fix would also be to reimplement that fix in the cinergyT2 device. I don't think Daniel Mack or Holger Waechtler manage this driver anymore because they didn't comment the last few fixes that were applied to that driver (though I put them into CC here) As far as I remember someone wrote that they didn't want to use the dvb_frontend code back then for any reason. So the only driver I'd take into account would be the flexcop driver. Currently tested drivers are: dvb-usb based devices, and em28xx/em2880 based devices Markus Markus Rechberger wrote: The patch has been around on the dvb mailinglist ([PATCH][RFC] DVB Hotplug Fix, 5. April 2007), The patch was merged into the development repository at the same time the pull request was issued to Linus. This has NOT been tested on a wide scale. It should go to -mm for a while before being merged to mainline. Mauro Carvalho Chehab wrote: I also explicitly warned at DVB ML that I were about to send this patch, together with other fixes, asking the community for more tests. After that, I received two positive answers on my mailbox from people that tested and noticed that this really fixed the issue. One of those positive answers was me - I explained that it worked for me, but we need others to test. You waited ONE DAY after sending this warning to the dvb mailing list? ( http://linuxtv.org/pipermail/linux-dvb/2007-April/017204.html ) I saw that email after seeing the pull request to Linus. We dont have users testing the repositories after each commit -- you _really_ need to give some more time to allow for such testing. CIJOML wrote: Hi, I have tested these patches with: Freecom DVB-T dongle Pluto2 pcmcia card Leadtek WinFast DTV dongle 1st generation Leadtek WinFast DTV dongle 2nd generation These are 4 different devices with 4 different hw and modules. All works. Please apply. Well, that helps... But it would still be nice to hear test results on a CinergyT2 or flexcop-usb. Which driver supports those Winfast dongles? We already know for sure that the patches work correctly for any driver based on the dvb-usb framework. If you had the device open, and then disconnect it from the usb bus, no matter what kernel version you're running, you should hit the OOPS. I confirm that these patches prevent that OOPS from occurring
Re: How should an exit routine wait for release() callbacks?
Cornelia Huck wrote: On Fri, 13 Apr 2007 13:42:04 +0200, "Markus Rechberger" <[EMAIL PROTECTED]> wrote: seems like you have the same problem as the dvb framework has/had. http://mcentral.de/hg/~mrec/v4l-dvb-stable The last 3 changesets do the trick to not oops, it will delay the deinitialization of the device till the last user closed the device node. Probably dumb question (since I'm not at all familiar with the dvb code): Isn't that a different race you're solving there? I don't see any driver core objects involved (except class devices created by class_device_create, which obviously don't have the release function problem). This looks more like a race of "we want an object to go away, but a user still has a file open" (which would be similar to the kobject<->sysfs lifetime rules issues, where work is currently ongoing). most dvb usb drivers call the device node unregistration when a device gets unplugged (when At this time the filehandle can still be open, the patch on that site sets a flag that disallows any further access to the device node (in the DVB framework there are 4 of such nodes) This can happen any time, so while someone is reading or accessing the device some structures might have gone away already and this could cause an oops. The problem of the DVB framework is file operation related, the last user calls fops_put on the existing structure and sets the pointer to NULL before it wakes up the other function which frees the file operation structure. In Alan's case isn't there any users flag available that shows that the structure is still beeing accessed? If that would be the case he could set a flag when he enters my_exit which would disable access to all other functions by returning an error value at the beginning of the other functions, the only way out would be to call my_release for existing users and wake up my_exit when the last reference to that structure is gone. Some more information about the whole driver/scenario would be helpful. Markus -- | AMD Saxony Limited Liability Company & Co. KG Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany System| Register Court Dresden: HRA 4896 Research | General Partner authorized to represent: Center| AMD Saxony LLC (Wilmington, Delaware, US) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How should an exit routine wait for release() callbacks?
Alan,
seems like you have the same problem as the dvb framework has/had.
http://mcentral.de/hg/~mrec/v4l-dvb-stable
The last 3 changesets do the trick to not oops, it will delay the
deinitialization of the device till the last user closed the device node.
Markus
Cornelia Huck wrote:
On Thu, 12 Apr 2007 17:23:18 -0400 (EDT),
Alan Stern <[EMAIL PROTECTED]> wrote:
Here's a not-so-theoretical question.
I've got a module which registers a struct device. (It represents a
virtual device, not a real one, but that doesn't matter.) Obviously the
module's exit routine has to wait until the release() routine for that
device has been invoked -- if it returned too early then the release()
call would oops.
How should it wait?
Device lifetime vs. module lifetime - that's a fun one...
The most straightforward approach is to use a struct completion, like
this:
static struct {
struct device dev;
...
} my_dev;
static DECLARE_COMPLETION(my_completion);
static void my_release(struct device *dev)
{
complete(_completion);
}
static void __exit my_exit(void)
{
device_unregister(_dev.dev);
wait_for_completion(_completion);
}
The problem is that there is no guarantee a context switch won't take
place after my_release() has called complete() and before my_release()
returns. If that happens and my_exit() finishes running, then the module
will be unloaded and the next context switch back to finish off
my_release() will oops.
Other approaches have similar defects. So how can this problem be solved?
What I see that a device driver may do now is the following:
- disallow module unloading (duh)
- move the release function outside the module
To make the completion approach work, the complete() would need to be
after the release function. This would imply an upper layer, but this
upper layer would need to access the completion structure in the
module...
One could think about a owner field (for getting/putting the module
reference) for the object (with a final module_put() after the release
function has been called). The problem there would be that it would
preclude unloading of the module if there isn't a "self destruct" knob
for the object.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
| AMD Saxony Limited Liability Company & Co. KG
Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
System | Register Court Dresden: HRA 4896
Research | General Partner authorized to represent:
Center | AMD Saxony LLC (Wilmington, Delaware, US)
| General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How should an exit routine wait for release() callbacks?
Alan,
seems like you have the same problem as the dvb framework has/had.
http://mcentral.de/hg/~mrec/v4l-dvb-stable
The last 3 changesets do the trick to not oops, it will delay the
deinitialization of the device till the last user closed the device node.
Markus
Cornelia Huck wrote:
On Thu, 12 Apr 2007 17:23:18 -0400 (EDT),
Alan Stern [EMAIL PROTECTED] wrote:
Here's a not-so-theoretical question.
I've got a module which registers a struct device. (It represents a
virtual device, not a real one, but that doesn't matter.) Obviously the
module's exit routine has to wait until the release() routine for that
device has been invoked -- if it returned too early then the release()
call would oops.
How should it wait?
Device lifetime vs. module lifetime - that's a fun one...
The most straightforward approach is to use a struct completion, like
this:
static struct {
struct device dev;
...
} my_dev;
static DECLARE_COMPLETION(my_completion);
static void my_release(struct device *dev)
{
complete(my_completion);
}
static void __exit my_exit(void)
{
device_unregister(my_dev.dev);
wait_for_completion(my_completion);
}
The problem is that there is no guarantee a context switch won't take
place after my_release() has called complete() and before my_release()
returns. If that happens and my_exit() finishes running, then the module
will be unloaded and the next context switch back to finish off
my_release() will oops.
Other approaches have similar defects. So how can this problem be solved?
What I see that a device driver may do now is the following:
- disallow module unloading (duh)
- move the release function outside the module
To make the completion approach work, the complete() would need to be
after the release function. This would imply an upper layer, but this
upper layer would need to access the completion structure in the
module...
One could think about a owner field (for getting/putting the module
reference) for the object (with a final module_put() after the release
function has been called). The problem there would be that it would
preclude unloading of the module if there isn't a self destruct knob
for the object.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
| AMD Saxony Limited Liability Company Co. KG
Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
System | Register Court Dresden: HRA 4896
Research | General Partner authorized to represent:
Center | AMD Saxony LLC (Wilmington, Delaware, US)
| General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: How should an exit routine wait for release() callbacks?
Cornelia Huck wrote: On Fri, 13 Apr 2007 13:42:04 +0200, Markus Rechberger [EMAIL PROTECTED] wrote: seems like you have the same problem as the dvb framework has/had. http://mcentral.de/hg/~mrec/v4l-dvb-stable The last 3 changesets do the trick to not oops, it will delay the deinitialization of the device till the last user closed the device node. Probably dumb question (since I'm not at all familiar with the dvb code): Isn't that a different race you're solving there? I don't see any driver core objects involved (except class devices created by class_device_create, which obviously don't have the release function problem). This looks more like a race of we want an object to go away, but a user still has a file open (which would be similar to the kobject-sysfs lifetime rules issues, where work is currently ongoing). most dvb usb drivers call the device node unregistration when a device gets unplugged (when At this time the filehandle can still be open, the patch on that site sets a flag that disallows any further access to the device node (in the DVB framework there are 4 of such nodes) This can happen any time, so while someone is reading or accessing the device some structures might have gone away already and this could cause an oops. The problem of the DVB framework is file operation related, the last user calls fops_put on the existing structure and sets the pointer to NULL before it wakes up the other function which frees the file operation structure. In Alan's case isn't there any users flag available that shows that the structure is still beeing accessed? If that would be the case he could set a flag when he enters my_exit which would disable access to all other functions by returning an error value at the beginning of the other functions, the only way out would be to call my_release for existing users and wake up my_exit when the last reference to that structure is gone. Some more information about the whole driver/scenario would be helpful. Markus -- | AMD Saxony Limited Liability Company Co. KG Operating | Wilschdorfer Landstr. 101, 01109 Dresden, Germany System| Register Court Dresden: HRA 4896 Research | General Partner authorized to represent: Center| AMD Saxony LLC (Wilmington, Delaware, US) | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
