* Re: udev regression from 167 to 168 on notion ink adam
From: Marco d'Itri @ 2011-05-05 10:18 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <809580245.144501.1304521074555.JavaMail.fmail@mwmweb069>
On May 05, Kay Sievers <kay.sievers@vrfy.org> wrote:
> Sure, but what should we do? We are in a poll() loop, that will never
> block if we don't get the stuff out of the file descriptor that wakes
> us up. We could exit? We can certainly try to print something that is
> easier to read than a strace.
Just aborting looks fine to me, at least it will be obvious that
something is wrong.
> But on the other hand we require a certain kernel version and it's
> symbols to work. There should never be a ENOSYS unless something is
> broken somewhere else.
This is why I think crashing is OK.
--
ciao,
Marco
^ permalink raw reply
* Re: udev regression from 167 to 168 on notion ink adam
From: Kay Sievers @ 2011-05-05 10:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <809580245.144501.1304521074555.JavaMail.fmail@mwmweb069>
On Thu, May 5, 2011 at 11:56, Marco d'Itri <md@linux.it> wrote:
> On May 05, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> Ah, no counted wrong, missed that there are 5 arguments. The 4th
>> argument, the 0x80000 is the SOCK_CLOEXEC. So it looks like your
>> kernel does not support accept4. Is that really a 2.6.32 kernel?
> Probably it is a libc bug, hppa had the same problem:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?buga7967
>
> Johannes, can you confirm that the newer libc package works so I can add
> the appropriate conflicts when it will be in unstable?
>
> Still, udev should just explode if a syscall fails with ENOSYS.
Sure, but what should we do? We are in a poll() loop, that will never
block if we don't get the stuff out of the file descriptor that wakes
us up. We could exit? We can certainly try to print something that is
easier to read than a strace.
But on the other hand we require a certain kernel version and it's
symbols to work. There should never be a ENOSYS unless something is
broken somewhere else.
Kay
^ permalink raw reply
* Re: udev regression from 167 to 168 on notion ink adam
From: Marco d'Itri @ 2011-05-05 9:56 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <809580245.144501.1304521074555.JavaMail.fmail@mwmweb069>
On May 05, Kay Sievers <kay.sievers@vrfy.org> wrote:
> Ah, no counted wrong, missed that there are 5 arguments. The 4th
> argument, the 0x80000 is the SOCK_CLOEXEC. So it looks like your
> kernel does not support accept4. Is that really a 2.6.32 kernel?
Probably it is a libc bug, hppa had the same problem:
http://bugs.debian.org/cgi-bin/bugreport.cgi?buga7967
Johannes, can you confirm that the newer libc package works so I can add
the appropriate conflicts when it will be in unstable?
Still, udev should just explode if a syscall fails with ENOSYS.
--
ciao,
Marco
^ permalink raw reply
* Re: udev regression from 167 to 168 on notion ink adam
From: Kay Sievers @ 2011-05-05 9:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <809580245.144501.1304521074555.JavaMail.fmail@mwmweb069>
On Thu, May 5, 2011 at 11:33, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, May 5, 2011 at 10:33, Johannes Schauer <j.schauer@email.de> wrote:
>> basically it's these two messages repeating infinitely:
>>
>> [pid 2353] epoll_wait(0xb, 0xbeb4d3b8, 0x8, 0xbb8) = 1
>> [pid 2353] SYS_366(0x4, 0, 0, 0x80000, 0) = -1 ENOSYS (Function not implemented)
>
> That's a syscall number and accept4(). It should be there since kernel
> 2.6.28 and glibc 2.10.
>
> With proper kernel support, and a more recent strace it would look like:
> accept4(3, 0, NULL, SOCK_CLOEXEC) = 11
>
> Not sure how that can happen on your side. The last parameter, the
> CLOEXEC flag is definitely not 0.
Ah, no counted wrong, missed that there are 5 arguments. The 4th
argument, the 0x80000 is the SOCK_CLOEXEC. So it looks like your
kernel does not support accept4. Is that really a 2.6.32 kernel?
Kay
^ permalink raw reply
* Re: udev regression from 167 to 168 on notion ink adam
From: Kay Sievers @ 2011-05-05 9:33 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <809580245.144501.1304521074555.JavaMail.fmail@mwmweb069>
On Thu, May 5, 2011 at 10:33, Johannes Schauer <j.schauer@email.de> wrote:
> basically it's these two messages repeating infinitely:
>
> [pid 2353] epoll_wait(0xb, 0xbeb4d3b8, 0x8, 0xbb8) = 1
> [pid 2353] SYS_366(0x4, 0, 0, 0x80000, 0) = -1 ENOSYS (Function not implemented)
That's a syscall number and accept4(). It should be there since kernel
2.6.28 and glibc 2.10.
With proper kernel support, and a more recent strace it would look like:
accept4(3, 0, NULL, SOCK_CLOEXEC) = 11
Not sure how that can happen on your side. The last parameter, the
CLOEXEC flag is definitely not 0.
> Note, that the ENOSYS errors didnt show up when i just attached strace to the
> udev process.
> What is this SYS_366 message telling me? Why is it called and why is it missing?
> My kernel has CONFIG_EPOLL=y and as you can see in the strace epoll_create1
> and epoll_ctl work just fine.
>
> It kinda looks like an error on my side but shouldn't udev nevertheless check for
> whatever it is and quit instead of running wild like that?
Yeah, we could try to catch these errors, but it seems there is
something that needs to be fixed in your kernel or glibc. Udev
requires at minimum kernel 2.6.32, and that *should* work there.
Kay
^ permalink raw reply
* Re: udev regression from 167 to 168 on notion ink adam
From: Johannes Schauer @ 2011-05-05 8:33 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <809580245.144501.1304521074555.JavaMail.fmail@mwmweb069>
Hi,
>On Wed, May 4, 2011 at 16:57, Johannes Schauer <j.schauer@email.de> wrote:
>> I'm running debian unstable on the notion ink adam tablet.
>> It was all working fine until debian upgraded udev to 168.
>> From then on the following three things happen with new rootfs
>> builds:
>>
>> 1.) upon each boot udev would take 180 seconds to finish and
>> allow the boot process to continue after the "waiting for /dev to
>> be fully populated" message.
>> 2.) when the system is booted doing "ps -e | grep udevd | wc -l"
>> yields that I have 24 udevd processes running.
>> 3.) when i start "top" I see that there is a udevd process running
>> constantly consuming 100% cpu power.
I bisected the commits from 167 to 168 and I found that this commit is the culprit
introducing the error I see:
commit ff2c503df091e6e4e9ab48cdb6df6ec8b7b525d0
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Tue, 12 Apr 2011 23:17:09 +0000
You can find a strace of the whole udev execution here:
http://mister-muffin.de/p/vPMW
basically it's these two messages repeating infinitely:
[pid 2353] epoll_wait(0xb, 0xbeb4d3b8, 0x8, 0xbb8) = 1
[pid 2353] SYS_366(0x4, 0, 0, 0x80000, 0) = -1 ENOSYS (Function not implemented)
Note, that the ENOSYS errors didnt show up when i just attached strace to the
udev process.
What is this SYS_366 message telling me? Why is it called and why is it missing?
My kernel has CONFIG_EPOLL=y and as you can see in the strace epoll_create1
and epoll_ctl work just fine.
It kinda looks like an error on my side but shouldnt udev nevertheless check for
whatever it is and quit instead of running wild like that?
thanks for helping!
cheers, josch
^ permalink raw reply
* RE: [PATCH] Set PCIE maxpayload for card during hotplug insertion
From: Jordan_Hargrave @ 2011-05-04 18:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1301005267-31006-1-git-send-email-jordan_hargrave@dell.com>
I have tested and verified that the patch works.
Tested-by: jordan_hargrave@dell.com
--jordan hargrave
Dell Enterprise Linux Engineering
> -----Original Message-----
> From: Hargrave, Jordan
> Sent: Tuesday, March 29, 2011 4:43 PM
> To: Iyer, Shyam; Hargrave, Jordan
> Subject: [PATCH] Set PCIE maxpayload for card during hotplug insertion
>
> Signed-off-by: Jordan Hargrave <Jordan_Hargrave@dell.com>
> ---
> drivers/pci/hotplug/pcihp_slot.c | 44
> ++++++++++++++++++++++++++++++++++++++
> 1 files changed, 44 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/hotplug/pcihp_slot.c
> b/drivers/pci/hotplug/pcihp_slot.c
> index 80b461c..3b628c5 100644
> --- a/drivers/pci/hotplug/pcihp_slot.c
> +++ b/drivers/pci/hotplug/pcihp_slot.c
> @@ -158,6 +158,46 @@ static void program_hpp_type2(struct pci_dev *dev,
> struct hpp_type2 *hpp)
> */
> }
>
> +/* Program PCIE MaxPayload setting on device: ensure parent maxpayload
> <= device */
> +static int pci_set_payload(struct pci_dev *dev)
> +{
> + int pos, ppos;
> + u16 pctl, psz;
> + u16 dctl, dsz, dcap, dmax;
> + struct pci_dev *parent;
> +
> + parent = dev->bus->self;
> + pos = pci_pcie_cap(dev);
> + if (!pos)
> + return 0;
> +
> + /* Read Device MaxPayload capability and setting */
> + pci_read_config_word(dev, pos + PCI_EXP_DEVCTL, &dctl);
> + pci_read_config_word(dev, pos + PCI_EXP_DEVCAP, &dcap);
> + dsz = (dctl & PCI_EXP_DEVCTL_PAYLOAD) >> 5;
> + dmax = (dcap & PCI_EXP_DEVCAP_PAYLOAD);
> +
> + /* Read Parent MaxPayload setting */
> + ppos = pci_pcie_cap(parent);
> + if (!ppos)
> + return 0;
> + pci_read_config_word(parent, ppos + PCI_EXP_DEVCTL, &pctl);
> + psz = (pctl & PCI_EXP_DEVCTL_PAYLOAD) >> 5;
> +
> + /* If parent payload > device max payload -> error
> + * If parent payload > device payload -> set speed
> + * If parent payload <= device payload -> do nothing
> + */
> + if (psz > dmax)
> + return -1;
> + if (psz > dsz) {
> + dev_info(&dev->dev, "Setting MaxPayload to %d\n", 128 <<
> psz);
> + dctl = (dctl & ~PCI_EXP_DEVCTL_PAYLOAD) + (psz << 5);
> + pci_write_config_word(dev, pos + PCI_EXP_DEVCTL, dctl);
> + }
> + return 0;
> +}
> +
> void pci_configure_slot(struct pci_dev *dev)
> {
> struct pci_dev *cdev;
> @@ -169,6 +209,10 @@ void pci_configure_slot(struct pci_dev *dev)
> (dev->class >> 8) = PCI_CLASS_BRIDGE_PCI)))
> return;
>
> + ret = pci_set_payload(dev);
> + if (ret)
> + dev_warn(&dev->dev, "could not set device max payload\n");
> +
> memset(&hpp, 0, sizeof(hpp));
> ret = pci_get_hp_params(dev, &hpp);
> if (ret)
> --
> 1.7.4.1
^ permalink raw reply
* Re: udev regression from 167 to 168 on notion ink adam
From: Johannes Schauer @ 2011-05-04 18:39 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <809580245.144501.1304521074555.JavaMail.fmail@mwmweb069>
Hi,
On Wed, May 4, 2011 at 18:36, Kay Sievers <kay.sievers@vrfy.org> wrote:
>On Wed, May 4, 2011 at 16:57, Johannes Schauer <j.schauer@email.de> wrote:
>> 1.) upon each boot udev would take 180 seconds to finish and
>> allow the boot process to continue after the "waiting for /dev to
>> be fully populated" message.
>> 2.) when the system is booted doing "ps -e | grep udevd | wc -l"
>> yields that I have 24 udevd processes running.
>> 3.) when i start "top" I see that there is a udevd process running
>> constantly consuming 100% cpu power.
>
>Any chance to attach: strace -p <pid> to that process?
ah that was a good idea - did that. and indeed I got loads of "epoll_wait"
messages spamming my terminal. but that doesnt tell me anything yet,
right?
>And what kernel version is that?
2.6.32
does it matter?
i was also about to try bisecting udev from 167 to 168 but have to postpone
that to later as the current debian sid perl 5.12 transition doesnt allow me
to install the required build dependencies for udev in debian yet. but once that
issue is resolved and I didnt find any other solution to the problem i will
definitely bisect it to get to the source of the error.
cheers, josch
^ permalink raw reply
* Re: udev regression from 167 to 168 on notion ink adam
From: Kay Sievers @ 2011-05-04 16:36 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <809580245.144501.1304521074555.JavaMail.fmail@mwmweb069>
On Wed, May 4, 2011 at 16:57, Johannes Schauer <j.schauer@email.de> wrote:
> I'm running debian unstable on the notion ink adam tablet.
> It was all working fine until debian upgraded udev to 168.
> From then on the following three things happen with new rootfs
> builds:
>
> 1.) upon each boot udev would take 180 seconds to finish and
> allow the boot process to continue after the "waiting for /dev to
> be fully populated" message.
> 2.) when the system is booted doing "ps -e | grep udevd | wc -l"
> yields that I have 24 udevd processes running.
> 3.) when i start "top" I see that there is a udevd process running
> constantly consuming 100% cpu power.
Any chance to attach: strace -p <pid> to that process?
And what kernel version is that?
Maybe some poll() loop goes crazy or something like that.
Kay
^ permalink raw reply
* Re: udev regression from 167 to 168 on notion ink adam
From: Gabor Z. Papp @ 2011-05-04 16:31 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <809580245.144501.1304521074555.JavaMail.fmail@mwmweb069>
* "Johannes Schauer" <j.schauer@email.de>:
| I had still an older rootfs of mine lying around with udev 167 which
| was working fine. After I upgraded it to 168 it showed the exact
| same behaviour as explained above.
Same happend to me with 2.6.27.x on x86, but I was lazy do debug it, since I
don't use it daily.
^ permalink raw reply
* Re: udev regression from 167 to 168 on notion ink adam
From: Kay Sievers @ 2011-05-04 16:03 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <809580245.144501.1304521074555.JavaMail.fmail@mwmweb069>
On Wed, May 4, 2011 at 17:20, Marco d'Itri <md@linux.it> wrote:
> On May 04, Johannes Schauer <j.schauer@email.de> wrote:
>
>> now my question is: how do I debug this? how do I find out
> The best way to debug this kind of problems is to boot with
> init=/bin/bash, start a shell on tty2 or a serial port with openvt or
> getty and then exec /sbin/init.
> Then you can find out from the second shell what the udevd processes are
> waiting for.
>
> OTOH, I remember that udevadm settle was supposed to print the uevents
> still queued when the timeout expires, did it stop doing this?
It should still do this.
Kay
^ permalink raw reply
* Re: udev regression from 167 to 168 on notion ink adam
From: Marco d'Itri @ 2011-05-04 15:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <809580245.144501.1304521074555.JavaMail.fmail@mwmweb069>
On May 04, Johannes Schauer <j.schauer@email.de> wrote:
> now my question is: how do I debug this? how do I find out
The best way to debug this kind of problems is to boot with
init=/bin/bash, start a shell on tty2 or a serial port with openvt or
getty and then exec /sbin/init.
Then you can find out from the second shell what the udevd processes are
waiting for.
OTOH, I remember that udevadm settle was supposed to print the uevents
still queued when the timeout expires, did it stop doing this?
--
ciao,
Marco
^ permalink raw reply
* udev regression from 167 to 168 on notion ink adam
From: Johannes Schauer @ 2011-05-04 14:57 UTC (permalink / raw)
To: linux-hotplug
hi,
I'm running debian unstable on the notion ink adam tablet.
It was all working fine until debian upgraded udev to 168.
From then on the following three things happen with new rootfs
builds:
1.) upon each boot udev would take 180 seconds to finish and
allow the boot process to continue after the "waiting for /dev to
be fully populated" message.
2.) when the system is booted doing "ps -e | grep udevd | wc -l"
yields that I have 24 udevd processes running.
3.) when i start "top" I see that there is a udevd process running
constantly consuming 100% cpu power.
I had still an older rootfs of mine lying around with udev 167 which
was working fine. After I upgraded it to 168 it showed the exact
same behaviour as explained above.
now my question is: how do I debug this? how do I find out
what is wrong? It is probably already helping that I know that 167
worked and 168 is not?
cheers, josch
^ permalink raw reply
* Re: [PATCHES] Misc. trivial fixes
From: Robby Workman @ 2011-05-03 4:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Andreas Oberritter, linux-media, Patrick Volkerding,
Hans De Goede, linux-hotplug
In-Reply-To: <4DBF79B4.5040000@redhat.com>
On Tue, 3 May 2011, Mauro Carvalho Chehab wrote:
> Em 02-05-2011 23:48, Robby Workman escreveu:
>> On Mon, 2 May 2011, Mauro Carvalho Chehab wrote:
>>
>>> Not sure what happened, but I lost the original email, so let me quote
>>> it from patchwork ID#699151.
>>>
>>>> Subject: [PATCHES] Misc. trivial fixes
>>>> Date: Tue, 12 Apr 2011 02:10:36 -0000
>>>> From: Robby Workman <rworkman@slackware.com>
>>>> X-Patchwork-Id: 699151
>>>> Message-Id: <alpine.LNX.2.00.1104111908050.32072@connie.slackware.com>
>>>> To: linux-media@vger.kernel.org
>>>>
>>>> Patch #1 installs udev rules files to /lib/udev/rules.d/ instead
>>>> of /etc/udev/rules.d/ - see commit message for more info.
>>>>
>>>> Patch #2 allows override of manpage installation directory by
>>>> packagers - see commit message for more info
>>>
>>> Please send each patch in-lined, one patch per email.
>>
>>
>> Okay, noted. Should I resend, or is this for future reference?
>
> If you don't mind, please re-send it. Please c/c me, as we're having some
> troubles with patchwork nowadays.
Sure, will do in just a bit.
>>> Not all distros use /lib for it. In fact, RHEL5/RHEL6/Fedora 15 and Fedora rawhide
>>> all use /etc/udev/rules.d.
>>
>> If so, it's only older distros that I wouldn't expect to be packaging newer
>> versions of v4l-utils (e.g. RHEL won't as I understand it), and for Fedora,
>> if "rawhide" is devel tree, then I'm pretty sure you're mistaken.
>
> We've packaged v4l-utils for RHEL, via epel[1]. I volunteered to maintain it for RHEL6,
> as I use it on my machine and I would be doing it anyway for me, so better to maintain
> it for the others also ;)
>
> [1] https://admin.fedoraproject.org/pkgdb/acls/name/v4l-utils
>
> I don't intend to maintain it for RHEL5, but I was told that lots of mythtv users run
> CentOS (based on RHEL5). So, I won't doubt if someone from CentOS (or other rpm repos
> for .el5, like atrpms) would add v4l-utils there.
Okay, fair enough.
> Do you know, by any chance, what's the minimal udev version where /lib/udev exists?
>
> If it is too old, then I agree that pointing the default to /lib/udev is the better.
Here's a casual look into udev's git log:
commit 05b9640022d25a75923cc7809409914491a5f9da
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Fri Jul 18 16:26:55 2008 +0200
release 125
...
commit 282988c4f8a85c28468e6442e86efe51dc71cc93
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Fri Jul 18 15:56:03 2008 +0200
move default rules from /etc/udev/rules.d/ to /lib/udev/rules.d/
...
So that's almost three years ago...
-RW
^ permalink raw reply
* Re: [PATCHES] Misc. trivial fixes
From: Mauro Carvalho Chehab @ 2011-05-03 3:42 UTC (permalink / raw)
To: Robby Workman
Cc: Andreas Oberritter, linux-media, Patrick Volkerding,
Hans De Goede, linux-hotplug
In-Reply-To: <alpine.LNX.2.00.1105021926220.25339@connie.slackware.com>
Em 02-05-2011 23:48, Robby Workman escreveu:
> On Mon, 2 May 2011, Mauro Carvalho Chehab wrote:
>
>> Not sure what happened, but I lost the original email, so let me quote
>> it from patchwork ID#699151.
>>
>>
>>> Subject: [PATCHES] Misc. trivial fixes
>>> Date: Tue, 12 Apr 2011 02:10:36 -0000
>>> From: Robby Workman <rworkman@slackware.com>
>>> X-Patchwork-Id: 699151
>>> Message-Id: <alpine.LNX.2.00.1104111908050.32072@connie.slackware.com>
>>> To: linux-media@vger.kernel.org
>>>
>>> Patch #1 installs udev rules files to /lib/udev/rules.d/ instead
>>> of /etc/udev/rules.d/ - see commit message for more info.
>>>
>>> Patch #2 allows override of manpage installation directory by
>>> packagers - see commit message for more info
>>
>> Please send each patch in-lined, one patch per email.
>
>
> Okay, noted. Should I resend, or is this for future reference?
If you don't mind, please re-send it. Please c/c me, as we're having some
troubles with patchwork nowadays.
>> Not all distros use /lib for it. In fact, RHEL5/RHEL6/Fedora 15 and Fedora rawhide
>> all use /etc/udev/rules.d.
>
> If so, it's only older distros that I wouldn't expect to be packaging newer
> versions of v4l-utils (e.g. RHEL won't as I understand it), and for Fedora,
> if "rawhide" is devel tree, then I'm pretty sure you're mistaken.
We've packaged v4l-utils for RHEL, via epel[1]. I volunteered to maintain it for RHEL6,
as I use it on my machine and I would be doing it anyway for me, so better to maintain
it for the others also ;)
[1] https://admin.fedoraproject.org/pkgdb/acls/name/v4l-utils
I don't intend to maintain it for RHEL5, but I was told that lots of mythtv users run
CentOS (based on RHEL5). So, I won't doubt if someone from CentOS (or other rpm repos
for .el5, like atrpms) would add v4l-utils there.
>> In a matter of fact, looking at RHEL6 (udev-147-2.35.el6.x86_64), it has both. I suspect
>> that /lib/udev/rules.d is meant to have the default scripts that are part of the
>> official packages, and /etc/udev/rules.d to be user-defined ones. So, at least on RHEL6,
>> it makes sense that a user-compiled tarball would install stuff into /etc/*, and
>> that a RHEL6 package would change it to install at /lib/*.
>
>
> Every distro (recent) will have both /lib/udev/rules.d/ and /etc/udev/rules.d/ ;
> more on that later...
>
>
>> So, it is better to have some Makefile var with some default, that
>> allows overriding it when doing a make install, for example:
>>
>> UDEVDIR=/etc/udev/rules.d
>
>
> Well, if you *insist* on doing this, sure, but better to do this:
> UDEVDIR=/lib/udev as the default, and then use $(UDEVDIR)/rules.d/ (and let packagers
> redefine UDEVDIR if desired - though I don't think that will be as
> common as you believe).
Do you know, by any chance, what's the minimal udev version where /lib/udev exists?
If it is too old, then I agree that pointing the default to /lib/udev is the better.
>> The default is a matter of personal taste. I would keep the current way as default,
>> as it avoids breaking for those that are using it on the current way. One alternative
>> would be to add some logic there to change the default to /lib/* if /etc/* doesn't
>> exist.
>
>
> But /etc/udev/rules.d/ should exist regardless, and it's not at all a
> matter of personal taste, as I understand it. /lib/udev/rules.d/ is
> the location for packaged and general default rules files to be placed,
> and /etc/udev/rules.d/ is where autogenerated rules (such as those that
> create persistent symlinks for optical and network devices) are placed,
> as well as admin- and system-specific override rules (e.g. a file named
> 10-blah.rules in /etc/udev/rules.d/ would completely override a file of
> the same name in /lib/udev/rules.d/).
Ok.
>
> The point I'm trying to make is this: you lose nothing in the way of user customization by defaulting to /lib/udev/rules.d/ - you simply force it to happen the way that upstream udev intends. The only thing
> you lose is support for older udev releases, and I'm not sure that's
> a big concern :-)
>
> (CC'd udev mail list so that someone can LART me if I'm wrong) ;-)
Thanks!
>
> -RW
Mauro.
^ permalink raw reply
* Re: [PATCHES] Misc. trivial fixes
From: Robby Workman @ 2011-05-03 2:48 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Andreas Oberritter, linux-media, Patrick Volkerding,
Hans De Goede, linux-hotplug
In-Reply-To: <4DBF126D.6060807@redhat.com>
On Mon, 2 May 2011, Mauro Carvalho Chehab wrote:
> Not sure what happened, but I lost the original email, so let me quote
> it from patchwork ID#699151.
>
>
>> Subject: [PATCHES] Misc. trivial fixes
>> Date: Tue, 12 Apr 2011 02:10:36 -0000
>> From: Robby Workman <rworkman@slackware.com>
>> X-Patchwork-Id: 699151
>> Message-Id: <alpine.LNX.2.00.1104111908050.32072@connie.slackware.com>
>> To: linux-media@vger.kernel.org
>>
>> Patch #1 installs udev rules files to /lib/udev/rules.d/ instead
>> of /etc/udev/rules.d/ - see commit message for more info.
>>
>> Patch #2 allows override of manpage installation directory by
>> packagers - see commit message for more info
>
> Please send each patch in-lined, one patch per email.
Okay, noted. Should I resend, or is this for future reference?
>> This creates MANDIR in Make.rules and keeps the preexisting
>> default of /usr/share/man, but allows packagers to easily
>> override via e.g. "make MANDIR=/usr/man"
>> ... snipped lots ...
>> +MANDIR = /usr/share/man
>
>
> It would be better to define it as:
> MANDIR = $(PREFIX)/share/man
>
> As suggested by Andreas.
Yes, I sent a fixed patch later - perhaps a resend is better
regardless now? :-)
>> ... snipped lots ...
>> - install -m 755 -d $(DESTDIR)/etc/udev/rules.d
>> - install -m 644 -p 70-infrared.rules $(DESTDIR)/etc/udev/rules.d
>> + install -m 755 -d $(DESTDIR)/lib/udev/rules.d
>
>
> Not all distros use /lib for it. In fact, RHEL5/RHEL6/Fedora 15 and Fedora rawhide
> all use /etc/udev/rules.d.
If so, it's only older distros that I wouldn't expect to be packaging newer
versions of v4l-utils (e.g. RHEL won't as I understand it), and for Fedora,
if "rawhide" is devel tree, then I'm pretty sure you're mistaken.
> In a matter of fact, looking at RHEL6 (udev-147-2.35.el6.x86_64), it has both. I suspect
> that /lib/udev/rules.d is meant to have the default scripts that are part of the
> official packages, and /etc/udev/rules.d to be user-defined ones. So, at least on RHEL6,
> it makes sense that a user-compiled tarball would install stuff into /etc/*, and
> that a RHEL6 package would change it to install at /lib/*.
Every distro (recent) will have both /lib/udev/rules.d/ and /etc/udev/rules.d/ ;
more on that later...
> So, it is better to have some Makefile var with some default, that
> allows overriding it when doing a make install, for example:
>
> UDEVDIR=/etc/udev/rules.d
Well, if you *insist* on doing this, sure, but better to do this:
UDEVDIR=/lib/udev
as the default, and then use $(UDEVDIR)/rules.d/ (and let packagers
redefine UDEVDIR if desired - though I don't think that will be as
common as you believe).
> The default is a matter of personal taste. I would keep the current way as default,
> as it avoids breaking for those that are using it on the current way. One alternative
> would be to add some logic there to change the default to /lib/* if /etc/* doesn't
> exist.
But /etc/udev/rules.d/ should exist regardless, and it's not at all a
matter of personal taste, as I understand it. /lib/udev/rules.d/ is
the location for packaged and general default rules files to be placed,
and /etc/udev/rules.d/ is where autogenerated rules (such as those that
create persistent symlinks for optical and network devices) are placed,
as well as admin- and system-specific override rules (e.g. a file named
10-blah.rules in /etc/udev/rules.d/ would completely override a file of
the same name in /lib/udev/rules.d/).
The point I'm trying to make is this: you lose nothing in the way of
user customization by defaulting to /lib/udev/rules.d/ - you simply
force it to happen the way that upstream udev intends. The only thing
you lose is support for older udev releases, and I'm not sure that's
a big concern :-)
(CC'd udev mail list so that someone can LART me if I'm wrong) ;-)
-RW
^ permalink raw reply
* Re: why does udev-167 break /lib64/udev/firmware ?
From: Matthias Schwarzott @ 2011-04-24 19:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201104141753.22335.jason.vas.dias@gmail.com>
On Donnerstag, 14. April 2011, Kay Sievers wrote:
>
> There is something seriously broken on your system:
>
> First, there is no /lib64/udev/ directory for udev ever. Gentoo should
> finally stop doing that nonsense. /lib64 is for shared libs only, the
> application private directory is /lib/udev/ regardless of the
> architecture.
The ebuild did install to /lib64/udev, correct. But there was always the
assumption that /lib linked to /lib64 in these cases, so that /lib/udev always
is valid.
But it seems I was wrong, so that will get changed back to plain "/lib/udev" I
think.
Matthias
^ permalink raw reply
* Add atm device description rules
From: Pantelis Koukousoulas @ 2011-04-23 17:38 UTC (permalink / raw)
To: linux-hotplug
USB ATM devices could use the same treatment that USB ethernet
devices enjoy, so that the atm device inherits the info from its parent
USB device. Would this be useful to include in mainline udev?
cat > 75-atm-description.rules << EOF
# do not edit this file, it will be overwritten on update
ACTION="remove", GOTO="atm_end"
SUBSYSTEM!="atm", GOTO="atm_end"
SUBSYSTEMS="usb", ENV{ID_MODEL}="", IMPORT{program}="usb_id --export %p"
SUBSYSTEMS="usb", ENV{ID_MODEL_FROM_DATABASE}="", IMPORT{program}="usb-db %p"
SUBSYSTEMS="usb", ATTRS{idVendor}!="", ATTRS{idProduct}!="",
ENV{ID_VENDOR_ID}="$attr{idVendor}",
ENV{ID_MODEL_ID}="$attr{idProduct}"
SUBSYSTEMS="usb", GOTO="atm_end"
SUBSYSTEMS="pci", ENV{ID_MODEL_FROM_DATABASE}="", IMPORT{program}="pci-db %p"
SUBSYSTEMS="pci", ENV{ID_BUS}="pci",
ENV{ID_VENDOR_ID}="$attr{vendor}", ENV{ID_MODEL_ID}="$attr{device}"
LABEL="atm_end"
EOF
Thanks,
Pantelis
^ permalink raw reply
* Re: embedded udev-81 doesn't remove node when fd open
From: Greg KH @ 2011-04-22 23:17 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTinNZG9W3JrEMzWnQNrgCveDTswjdw@mail.gmail.com>
On Fri, Apr 22, 2011 at 04:03:00PM -0700, John Ervin wrote:
> > Note, we did "help" this out in future kernel versions by sending a
> > HANGUP signal to userspace when the device went away, and you would get
> > that fix for free by updating to a newer kernel.
>
> Greg,
>
> Happen to recall the earliest this was implemented, ie kernel with
> appropriate udev/rev?
Again, it's not a udev issue, it was a kernel change.
And no, sorry, I don't, again, it was years ago, which was a few hundred
thousand changes ago, sorry.
git is your friend, it should be trivial to dig it up if you really want
it. Go make the people forcing you to stick with obsolete software do
it for you :)
good luck,
greg k-h
^ permalink raw reply
* Re: embedded udev-81 doesn't remove node when fd open
From: John Ervin @ 2011-04-22 23:03 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTinNZG9W3JrEMzWnQNrgCveDTswjdw@mail.gmail.com>
> Note, we did "help" this out in future kernel versions by sending a
> HANGUP signal to userspace when the device went away, and you would get
> that fix for free by updating to a newer kernel.
Greg,
Happen to recall the earliest this was implemented, ie kernel with
appropriate udev/rev?
John Ervin
^ permalink raw reply
* Re: embedded udev-81 doesn't remove node when fd open
From: Greg KH @ 2011-04-22 22:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BANLkTinNZG9W3JrEMzWnQNrgCveDTswjdw@mail.gmail.com>
On Fri, Apr 22, 2011 at 03:34:52PM -0700, John Ervin wrote:
> Hello,
>
> Using udev-81 in an embedded system with 2.6.21 kernel (later versions
> of udev don't compile b/c of glibc version with cross compilation
> tools).
Wow, you do realize just how old both of those releases are, right? If
you are stuck on those releases, then I suggest you get support from the
vendors or people who are forcing those versions on you, there's not
much we can do about it here, right?
> I need to keep the file descriptor of the device (a usb serial
> device) open to receive asynchronous data.
>
> But, if the device is removed while the fd is open, udev doesn't
> remove the node. Any way to configure things so that udev removes the
> node, even while the fd is held open by user space program(s)?
That's because the device node is not gone, the kernel still sees it
being open, so it has not released it.
udev isn't involved here at all, so there's nothing it can do, it is
never notified of anything because nothing has changed in the kernel
yet.
Note, we did "help" this out in future kernel versions by sending a
HANGUP signal to userspace when the device went away, and you would get
that fix for free by updating to a newer kernel.
best of luck,
greg k-h
^ permalink raw reply
* Re: embedded udev-81 doesn't remove node when fd open
From: John Ervin @ 2011-04-22 22:34 UTC (permalink / raw)
To: linux-hotplug
Hello,
Using udev-81 in an embedded system with 2.6.21 kernel (later versions
of udev don't compile b/c of glibc version with cross compilation
tools). I need to keep the file descriptor of the device (a usb serial
device) open to receive asynchronous data.
But, if the device is removed while the fd is open, udev doesn't
remove the node. Any way to configure things so that udev removes the
node, even while the fd is held open by user space program(s)?
John Ervin
^ permalink raw reply
* [PATCH] udevd: clarify worker exit status
From: harald @ 2011-04-21 8:09 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1303373212-29508-1-git-send-email-harald@redhat.com>
From: Harald Hoyer <harald@redhat.com>
---
udev/udevd.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/udev/udevd.c b/udev/udevd.c
index b8513e1..0e73f81 100644
--- a/udev/udevd.c
+++ b/udev/udevd.c
@@ -812,7 +812,16 @@ static void handle_signal(struct udev *udev, int signo)
info(udev, "worker [%u] exit\n", pid);
if (!WIFEXITED(status) || WEXITSTATUS(status) != 0) {
- err(udev, "worker [%u] unexpectedly returned with status 0x%04x\n", pid, status);
+ if (WEXITSTATUS(status))
+ err(udev, "worker [%u] unexpectedly returned with status %d\n", pid, WEXITSTATUS(status));
+ else if (WIFSIGNALED(status))
+ err(udev, "worker [%u] killed by signal %d (%s)\n", pid,
+ WTERMSIG(status), strsignal(WTERMSIG(status)));
+ else if (WIFSTOPPED(status))
+ err(udev, "worker [%u] unexpectedly stopped\n", pid);
+ else if (WIFCONTINUED(status))
+ err(udev, "worker [%u] continued\n", pid);
+
if (worker->event != NULL) {
err(udev, "worker [%u] failed while handling '%s'\n", pid, worker->event->devpath);
worker->event->exitcode = -32;
--
1.7.3.4
^ permalink raw reply related
* [PATCH] udevd: clarify worker exit status
From: harald @ 2011-04-21 8:06 UTC (permalink / raw)
To: linux-hotplug
From: Harald Hoyer <harald@redhat.com>
---
udev/udevd.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/udev/udevd.c b/udev/udevd.c
index b8513e1..b0474b1 100644
--- a/udev/udevd.c
+++ b/udev/udevd.c
@@ -812,7 +812,15 @@ static void handle_signal(struct udev *udev, int signo)
info(udev, "worker [%u] exit\n", pid);
if (!WIFEXITED(status) || WEXITSTATUS(status) != 0) {
- err(udev, "worker [%u] unexpectedly returned with status 0x%04x\n", pid, status);
+ if (WEXITSTATUS(status))
+ err(udev, "worker [%u] unexpectedly returned with status %d\n", pid, WEXITSTATUS(status));
+ else if (WIFSIGNALED(status))
+ err(udev, "worker [%u] killed by signal %d\n", pid, WTERMSIG(status));
+ else if (WIFSTOPPED(status))
+ err(udev, "worker [%u] unexpectedly stopped\n", pid);
+ else if (WIFCONTINUED(status))
+ err(udev, "worker [%u] continued\n", pid);
+
if (worker->event != NULL) {
err(udev, "worker [%u] failed while handling '%s'\n", pid, worker->event->devpath);
worker->event->exitcode = -32;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] udevd: help to debug timouts of RUN+=""
From: Harald Hoyer @ 2011-04-18 8:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1303113946-3692-1-git-send-email-harald@redhat.com>
Am 18.04.2011 10:05, schrieb harald@redhat.com:
> From: Harald Hoyer <harald@redhat.com>
>
> Store pointer of command to RUN in the event, to aid debugging of timed
> out events.
forget it... will send correct patch later.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox