* Re: "index_mm_open: No such file or directory" on a kernel without modules
From: Lucas De Marchi @ 2012-02-11 21:36 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <jh370d$8to$1@dough.gmane.org>
Hey!
On Sat, Feb 11, 2012 at 9:31 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Fri, Feb 10, 2012 at 14:44, RogutÄ—s Sparnuotos
> <rogutes@googlemail.com> wrote:
>> G'day,
>>
>> On a kernel without modules (/lib/modules empty), udev prints
>> "index_mm_open: No such file or directory"
>> at startup. Why?
Because:
1. You are not using the last release (v5) that added a more meaningful message
2. Because you are running without a modules.dep{,.bin} on your system.
Kay, do you think we should decrease the prio of this message to DBG?
Lucas De Marchi
^ permalink raw reply
* udev-171-r5 1 of 2 tests failed
From: Toralf Förster @ 2012-02-12 12:00 UTC (permalink / raw)
To: linux-hotplug
That packages emerged fine at a stable Gentoo Linux system.
However if I chroot into a stable Gentoo Linux user mode linux image and
emerge it there I get :
PASS: test/udev-test.pl
File "./test/rule-syntax-check.py", line 58
print 'Invalid line %s:%i: %s' % (path, lineno, line)
^
SyntaxError: invalid syntax
FAIL: test/rules-test.sh
=======================
1 of 2 tests failed
Please report to linux-hotplug@vger.kernel.org
=======================
--
MfG/Sincerely
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ permalink raw reply
* Re: udev-171-r5 1 of 2 tests failed
From: Kay Sievers @ 2012-02-12 15:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201202121300.37930.toralf.foerster@gmx.de>
MjAxMi8yLzEyIFRvcmFsZiBGw7Zyc3RlciA8dG9yYWxmLmZvZXJzdGVyQGdteC5kZT46Cj4gVGhh
dCBwYWNrYWdlcyBlbWVyZ2VkIGZpbmUgYXQgYSBzdGFibGUgR2VudG9vIExpbnV4IHN5c3RlbS4K
Pgo+IEhvd2V2ZXIgaWYgSSBjaHJvb3QgaW50byBhIHN0YWJsZSBHZW50b28gTGludXggdXNlciBt
b2RlIGxpbnV4IGltYWdlIGFuZAo+IGVtZXJnZSBpdCB0aGVyZSBJIGdldCA6Cj4KPiBQQVNTOiB0
ZXN0L3VkZXYtdGVzdC5wbAo+IMKgRmlsZSAiLi90ZXN0L3J1bGUtc3ludGF4LWNoZWNrLnB5Iiwg
bGluZSA1OAo+IMKgIMKgcHJpbnQgJ0ludmFsaWQgbGluZSAlczolaTogJXMnICUgKHBhdGgsIGxp
bmVubywgbGluZSkKPiDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDC
oCDCoCBeCj4gU3ludGF4RXJyb3I6IGludmFsaWQgc3ludGF4Cj4gRkFJTDogdGVzdC9ydWxlcy10
ZXN0LnNoCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQo+
IDEgb2YgMiB0ZXN0cyBmYWlsZWQKPiBQbGVhc2UgcmVwb3J0IHRvIGxpbnV4LWhvdHBsdWdAdmdl
ci5rZXJuZWwub3JnCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PQoKWW91IG5lZWQgYW4gb2xkZXIgcHl0aG9uIG9yIGEgbmV3ZXIgdWRldiAgdG8gcnVuIHRo
aXMgdGVzdC4KClRoYW5rcywKS2F5Cg=
^ permalink raw reply
* Re: "index_mm_open: No such file or directory" on a kernel without modules
From: Kay Sievers @ 2012-02-12 16:22 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <jh370d$8to$1@dough.gmane.org>
On Sat, Feb 11, 2012 at 22:36, Lucas De Marchi
<lucas.demarchi@profusion.mobi> wrote:
> On Sat, Feb 11, 2012 at 9:31 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On Fri, Feb 10, 2012 at 14:44, RogutÄ—s Sparnuotos
>> <rogutes@googlemail.com> wrote:
>>> G'day,
>>>
>>> On a kernel without modules (/lib/modules empty), udev prints
>>> "index_mm_open: No such file or directory"
>>> at startup. Why?
>
> Because:
>
> 1. You are not using the last release (v5) that added a more meaningful message
> 2. Because you are running without a modules.dep{,.bin} on your system.
>
> Kay, do you think we should decrease the prio of this message to DBG?
Yeah, I think so. No modules config files to work off, means nothing
to do, and no complains, I guess.
Kay
^ permalink raw reply
* Re: [PATCH] make: link udevd with -lrt
From: Kay Sievers @ 2012-02-12 21:10 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1328127721-18825-1-git-send-email-ncopa@alpinelinux.org>
On Wed, Feb 1, 2012 at 21:22, Natanael Copa <ncopa@alpinelinux.org> wrote:
> sd-daemon.c uses mq_getattr() and should link with -lrt as the
> man mq_getattr(3) states.
Something seems wrong on your system. The:
AC_SEARCH_LIBS([clock_gettime], [rt], ...
in configure.ac should take care of that, and puts this in Makefile:
LIBS = -lrt
...
$(AM_V_CCLD)$(src_udevd_LINK) $(src_udevd_OBJECTS) $(src_udevd_LDADD) $(LIBS)
Kay
^ permalink raw reply
* Re: [PATCH] make: support for tar without -J option
From: Kay Sievers @ 2012-02-12 21:36 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1328127096-13293-1-git-send-email-ncopa@alpinelinux.org>
On Wed, Feb 1, 2012 at 21:11, Natanael Copa <ncopa@alpinelinux.org> wrote:
> Not all tar implementation has support for -J yet. For example
> busybox tar.
This should now only be needed to run the tests, not to build udev.
Kay
^ permalink raw reply
* Re: [PATCH] make: support for tar without -J option
From: Natanael Copa @ 2012-02-13 16:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1328127096-13293-1-git-send-email-ncopa@alpinelinux.org>
On Sun, 12 Feb 2012 22:36:47 +0100
Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Feb 1, 2012 at 21:11, Natanael Copa <ncopa@alpinelinux.org>
> wrote:
> > Not all tar implementation has support for -J yet. For example
> > busybox tar.
>
> This should now only be needed to run the tests, not to build udev.
perfect.
Thanks!
-nc
^ permalink raw reply
* Re: [PATCH] make: link udevd with -lrt
From: Natanael Copa @ 2012-02-14 8:45 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1328127721-18825-1-git-send-email-ncopa@alpinelinux.org>
On Sun, 12 Feb 2012 22:10:34 +0100
Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Feb 1, 2012 at 21:22, Natanael Copa <ncopa@alpinelinux.org>
> wrote:
> > sd-daemon.c uses mq_getattr() and should link with -lrt as the
> > man mq_getattr(3) states.
>
> Something seems wrong on your system. The:
> AC_SEARCH_LIBS([clock_gettime], [rt], ...
> in configure.ac should take care of that, and puts this in Makefile:
> LIBS = -lrt
> ...
> $(AM_V_CCLD)$(src_udevd_LINK) $(src_udevd_OBJECTS)
> $(src_udevd_LDADD) $(LIBS)
>
> Kay
configure:12437: checking for library containing clock_gettime
configure:12468: ccache gcc -o conftest -march=i486 -Os -fomit-frame-pointer -pipe -march=i486 -Os -fomit-frame-pointer -pipe -Wl,--as-needed conftest.c >&5
configure:12468: $? = 0
configure:12485: result: none required
$ nm -D /lib/libc.so.0.9.32 | grep clock_gettime
0000000000010b08 T clock_gettime
$ nm -D /lib/librt.so.0.9.32 | grep clock_gettime
00000000000023c0 T clock_gettime
So what is "wrong" on my system is that uClibc provides 2 different
versions of clock_gettime. One is with the threading additions and one
is without. This makes it possible to use clock_gettime() without
linking in the entire libpthread unless you actually use those
additions.
The configure script will test if -lrt is needed by checking
clock_gettime() and bumps into this "feature" and thinks it does not
need to add the -lrt flag. However, it also uses mq_getattr() which
does require -lrt.
We should probably check for mq_getattr() instead of clock_gettime().
Thanks!
-nc
^ permalink raw reply
* [PATCH] make: test for mq_getattr rather than clock_gettime
From: Natanael Copa @ 2012-02-14 9:20 UTC (permalink / raw)
To: linux-hotplug
Some systems (like uClibc) has 2 versions of clock_gettime and will
use a lighter version when linked without -lrt. Therefore we test for
mq_getattr instead of clock_gettime.
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
---
configure.ac | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index a88a34c..382e9c0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -21,7 +21,7 @@ AC_PREFIX_DEFAULT([/usr])
AC_PATH_PROG([XSLTPROC], [xsltproc])
AM_CONDITIONAL(HAVE_XSLTPROC, test x"$XSLTPROC" != x)
-AC_SEARCH_LIBS([clock_gettime], [rt], [], [AC_MSG_ERROR([POSIX RT library not found])])
+AC_SEARCH_LIBS([mq_getattr], [rt], [], [AC_MSG_ERROR([POSIX RT library not found])])
PKG_CHECK_MODULES(BLKID, blkid >= 2.20)
--
1.7.9
^ permalink raw reply related
* Can't create a mathcing udev-rule....
From: Daniel Spannbauer @ 2012-02-14 10:04 UTC (permalink / raw)
To: linux-hotplug
Hello,
I try to create a udev-rule for the USB-Devices produced by our company.
Espacially one device drives me crazy.
This is a board connects via USB, the kernel creates a tty
(/dev/ttyUSB?). Other USB-Devices can be connected to this "baseboard".
To create a unique Devicenode to that Baseboard I have to create a
UDEV-Rule. For the other devices connected to that baseboard a rule
already exists.
Here is the ruleset for our devices:
=======================# rule for io-interfaces
SUBSYSTEMS= "usb", KERNEL="ttyUSB[0-9]*", ATTR{idVendor}="1dfb",
RUN+="/usr/uti/udevscript usbmodul %k $env{ID_SERIAL_SHORT}"
# additional rule for io-interfaces to read with control485
SUBSYSTEMS="tty", KERNEL="ttyUSB[0-9]*", ACTION="add",
RUN+="/usr/uti/udevscript-485 usbmodul %k $env{ID_SERIAL_SHORT}"
SUBSYSTEMS="tty", KERNEL="ttyUSB[0-9]*", ACTION="remove",
RUN+="/usr/uti/marco-udevscript-485 usbmodul_remove %k"
# USBSTICK
SUBSYSTEMS= "usb", KERNEL="sd[a-z]1", RUN+="/usr/uti/marco-udevscript
usbstick %k"
SUBSYSTEMS= "usb", KERNEL="sd[a-z]", RUN+="/usr/uti/marco-udevscript
usbstick_device %k"
# PCAN
SUBSYSTEMS= "usb", ATTR{idVendor}="0c72", ATTR{idProduct}="000c",
RUN+="/usr/uti/udevscript pcan"
# 2a-Board
SUBSYSTEMS="usb", KERNEL="ttyUSB[0-9]*", ATTRS{idVendor}="1dfb",
ATTRS{idProduct}="0007", SYMLINK+="/dev/2a/%k"
========================
Here is a "/sbin/udevadm info --query=all --attribute-walk
--name=/dev/ttyUSB0" for that device (it is reachable over /dev/ttyUSB0):
http://pastebin.com/B8YrQSxm
I disconnect and connect that device....but nothing is created under
/dev/2a.
Any hints about this ruleset?
Regards
Daniel
--
Daniel Spannbauer Software Entwicklung
marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11
Rechbergstr. 4 - 6, D 87727 Babenhausen Mobil +49 171 4033220
http://www.marco.de/ Email ds@marco.de
Geschäftsführer Martin Reuter HRB 171775 Amtsgericht München
^ permalink raw reply
* busy mounts with udev 176 and later
From: Thierry Reding @ 2012-02-14 11:01 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 2642 bytes --]
Hi,
I'm running a custom distribution that uses an initial ramdisk to get the
system up and running. The system uses udev and systemd and keeps the initial
ramdisk around to make use of systemd's shutdown hook to properly unmount
filesystems on shutdown.
I have to admit that the setup is probably not very common: the device has an
onboard flash with a SATA interface, and one of the partitions contains a
squashfs image that is the actual root filesystem. So in order to properly get
this up and running, the partition is mounted at /media/disk and then
/media/disk/rootfs.img can be mounted as the new root filesystem. To further
complicate things, /media/disk is then moved into the new root filesystem to
keep it available after the system is booted. So there really is a mount
dependency and the root filesystem cannot be unmounted because /media/disk is
still mounted, yet /media/disk cannot be unmounted because it contains
rootfs.img which is mounted as root filesystem.
That's where the shutdown hook comes into play: systemd jumps back to the
initial ramdisk (which is kept around for exactly this purpose) and a script
is run to unmount the filesystems in the proper order. So I first move
/oldroot/media/disk to /media/disk, which allows /oldroot to be unmounted.
Finally I can unmount /media/disk because rootfs.img is no longer mounted.
This all used to work properly until recently when I upgraded udev from 173
to 181. Suddently unmounting /media/disk fails with "device or resource
busy". So I tried to find out where exactly this was introduced and found out
that things work well with 175 but not 176 and later. However I didn't manage
to bisect this further because none of the intermittent commits would yield a
working udev so that either keyboard didn't work and I couldn't shut it down
(networking didn't work either in that case) or the SATA interface wasn't
properly initialized.
Somewhere inbetween I also tried debugging from the kernel side by looking at
debug output from the umount syscall. Apparently the reason is that the usage
count of the /media/disk mountpoint is 3 at the time the shutdown script
tries to unmount it and consequently the umount is rejected.
So I went back to look at the logs to take an educated guess about what
changes might be causing this behaviour. The only potential candidates that
seemed to jump out were the new blkid and kmod builtins. I attempted to rip
out the actual implementation (in effect making them dummy builtins) but that
didn't fix the problem either.
Now I'm pretty much running out of ideas about where to look. Does anybody
else have any ideas?
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Can't create a mathcing udev-rule....
From: Jim Paris @ 2012-02-14 15:57 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F3A31A8.1020300@marco.de>
Daniel Spannbauer wrote:
> # 2a-Board
> SUBSYSTEMS="usb", KERNEL="ttyUSB[0-9]*", ATTRS{idVendor}="1dfb",
Need two equals here ------^
-jim
^ permalink raw reply
* will these methods work with firmware loading?
From: Larry Finger @ 2012-02-19 18:40 UTC (permalink / raw)
To: LKML, driverdevel, wireless, linux-hotplug
I sent a previous messages to most of these lists, but got no answer, thus a
second try.
When a driver loads firmware synchronously in the module_init() path using
request_firmware(), then there is trouble with timeouts when booting.
I know that changing the request_firmware() call to request_firmware_nowait()
solves the problem; however, that gives some trouble for driver b43legacy as it
loads 3 or 4 firmware files depending on the hardware version. When I launch the
3 or 4 nowait requests, I get an error because the system is trying to start
several tasks with the same name.
Would it be OK to load the first file with the nowait version, and issue a
request_firmware() for the others from the callback routine? I think that would
not cause any problems, but I would like to get confirmation from an expert.
Similarly, if I were to create a work queue, init and schedule it from
module_init(), and then use synchronous loads to get the firmware from the work
queue callback, would that get around the boot problem? I know it works as I
have trial patches; however, my version of udev is not one affected. This method
is very easy to implement, but again I would like confirmation from an expert.
Thanks,
Larry
^ permalink raw reply
* Re: will these methods work with firmware loading?
From: Johannes Berg @ 2012-02-20 9:46 UTC (permalink / raw)
To: Larry Finger; +Cc: LKML, driverdevel, wireless, linux-hotplug
In-Reply-To: <4F414230.5040506@lwfinger.net>
Hi Larry,
> I know that changing the request_firmware() call to request_firmware_nowait()
> solves the problem; however, that gives some trouble for driver b43legacy as it
> loads 3 or 4 firmware files depending on the hardware version. When I launch the
> 3 or 4 nowait requests, I get an error because the system is trying to start
> several tasks with the same name.
>
> Would it be OK to load the first file with the nowait version, and issue a
> request_firmware() for the others from the callback routine? I think that would
> not cause any problems, but I would like to get confirmation from an expert.
That should work -- I just looked at the firmware code and it spawns a
new thread for every "nowait" request (and it calls the callback in that
thread's context), so it won't block against itself.
> Similarly, if I were to create a work queue, init and schedule it from
> module_init(), and then use synchronous loads to get the firmware from the work
> queue callback, would that get around the boot problem? I know it works as I
> have trial patches; however, my version of udev is not one affected. This method
> is very easy to implement, but again I would like confirmation from an expert.
We discussed that before, and technically it should work, I'm just a bit
worried about udev treating asynchronous and synchronous requests
differently and that causing issues, but somebody who knows udev better
will have to comment on that.
johannes
^ permalink raw reply
* Re: will these methods work with firmware loading?
From: Arend van Spriel @ 2012-02-20 10:01 UTC (permalink / raw)
To: Larry Finger
Cc: LKML, driverdevel, wireless, linux-hotplug@vger.kernel.org,
Kay Sievers
In-Reply-To: <4F414230.5040506@lwfinger.net>
On 02/19/2012 07:40 PM, Larry Finger wrote:
> I sent a previous messages to most of these lists, but got no answer, thus a
> second try.
>
> When a driver loads firmware synchronously in the module_init() path using
> request_firmware(), then there is trouble with timeouts when booting.
>
> I know that changing the request_firmware() call to request_firmware_nowait()
> solves the problem; however, that gives some trouble for driver b43legacy as it
> loads 3 or 4 firmware files depending on the hardware version. When I launch the
> 3 or 4 nowait requests, I get an error because the system is trying to start
> several tasks with the same name.
Yep, the nowait api just kicks off a kernel thread for the firmware request.
> Would it be OK to load the first file with the nowait version, and issue a
> request_firmware() for the others from the callback routine? I think that would
> not cause any problems, but I would like to get confirmation from an expert.
No expert, but that is what I did although the chaining of firmware
requests does not feel great. Especially for handling error flows.
Johannes Berg and Kay Sievers mentioned need to unbind/rebind the driver
upon failed firmware load, but I don't like the idea of building a
timer-controlled retry mechanism.
> Similarly, if I were to create a work queue, init and schedule it from
> module_init(), and then use synchronous loads to get the firmware from the work
> queue callback, would that get around the boot problem? I know it works as I
> have trial patches; however, my version of udev is not one affected. This method
> is very easy to implement, but again I would like confirmation from an expert.
What boot problem are you referring to? The blocking modprobe? For that
problem I would say yes. Also here the problem of handling error flows
exist. If the driver is kicked of during boot with a initramfs missing
the firmware, should we retry until the real root is mounted?
Gr. AvS
^ permalink raw reply
* Re: will these methods work with firmware loading?
From: Kay Sievers @ 2012-02-20 10:19 UTC (permalink / raw)
To: Arend van Spriel
Cc: Larry Finger, LKML, driverdevel, wireless,
linux-hotplug@vger.kernel.org
In-Reply-To: <4F421A0E.8030805@broadcom.com>
On Mon, Feb 20, 2012 at 11:01, Arend van Spriel <arend@broadcom.com> wrote:
> On 02/19/2012 07:40 PM, Larry Finger wrote:
>> Similarly, if I were to create a work queue, init and schedule it from
>> module_init(), and then use synchronous loads to get the firmware from the
>> work
>> queue callback, would that get around the boot problem? I know it works as
>> I
>> have trial patches; however, my version of udev is not one affected. This
>> method
>> is very easy to implement, but again I would like confirmation from an
>> expert.
It sounds like it should work, because the modprobe event returns, not
waiting for the firmware request. Chaining one firmware request after
the other sounds not like a problem, as long as they are chained with
the return from the earlier request and not from inside the earlier
request, which would have duplicated device name issues in the kernel
too.
> What boot problem are you referring to?
The pci event calls modprobe, the module init for the pci driver
creates a child event of the pci device, this child event is queued in
udev to be started after the pci event has finished. The pci event
does not finish in time because the firmware request blocks itself.
The current udev logic limits the timeout to 30 sec, while the
firmware request is 60 sec, so it usually works with a logged error,
and a 30 second delay.
> The blocking modprobe?
Yes, blocking in the module init path, will deadlock udev. Linking
code into the kernel must not depend on device init or firmware
loading.
> For that
> problem I would say yes. Also here the problem of handling error flows
> exist. If the driver is kicked of during boot with a initramfs missing the
> firmware, should we retry until the real root is mounted?
I don't think so. Drivers are not supposed to know about bootup or
initramfs issues. If they want, they can disable the timeout, and wait
for userspace to handle the request any time later, but they should
not try to be smart here.
Currently, firmware requests are cancelled if the firmware isn't
found, but that's a userspace issue, and nothing the kernel should try
to work around.
Kay
^ permalink raw reply
* Re: will these methods work with firmware loading?
From: Arend van Spriel @ 2012-02-20 10:32 UTC (permalink / raw)
To: Kay Sievers
Cc: Larry Finger, LKML, driverdevel, wireless,
linux-hotplug@vger.kernel.org
In-Reply-To: <CAPXgP10qa_g6R=pOWd8JuXpw0wPdJ4rP7B_4YHDU91mhC0N6Vg@mail.gmail.com>
On 02/20/2012 11:19 AM, Kay Sievers wrote:
>> For that
>> > problem I would say yes. Also here the problem of handling error flows
>> > exist. If the driver is kicked of during boot with a initramfs missing the
>> > firmware, should we retry until the real root is mounted?
> I don't think so. Drivers are not supposed to know about bootup or
> initramfs issues. If they want, they can disable the timeout, and wait
> for userspace to handle the request any time later, but they should
> not try to be smart here.
>
> Currently, firmware requests are cancelled if the firmware isn't
> found, but that's a userspace issue, and nothing the kernel should try
> to work around.
I can not agree more. I prefer to keep my driver happily unaware. I will
just take the firmware loading away from the module init path and stop
worrying about userspace issues ;-)
Gr. AvS
^ permalink raw reply
* Re: will these methods work with firmware loading?
From: Larry Finger @ 2012-02-20 20:12 UTC (permalink / raw)
To: Kay Sievers
Cc: Arend van Spriel, LKML, driverdevel, wireless,
linux-hotplug@vger.kernel.org
In-Reply-To: <CAPXgP10qa_g6R=pOWd8JuXpw0wPdJ4rP7B_4YHDU91mhC0N6Vg@mail.gmail.com>
On 02/20/2012 04:19 AM, Kay Sievers wrote:
> On Mon, Feb 20, 2012 at 11:01, Arend van Spriel<arend@broadcom.com> wrote:
>> On 02/19/2012 07:40 PM, Larry Finger wrote:
>
>>> Similarly, if I were to create a work queue, init and schedule it from
>>> module_init(), and then use synchronous loads to get the firmware from the
>>> work
>>> queue callback, would that get around the boot problem? I know it works as
>>> I
>>> have trial patches; however, my version of udev is not one affected. This
>>> method
>>> is very easy to implement, but again I would like confirmation from an
>>> expert.
>
> It sounds like it should work, because the modprobe event returns, not
> waiting for the firmware request. Chaining one firmware request after
> the other sounds not like a problem, as long as they are chained with
> the return from the earlier request and not from inside the earlier
> request, which would have duplicated device name issues in the kernel
> too.
>
>> What boot problem are you referring to?
>
> The pci event calls modprobe, the module init for the pci driver
> creates a child event of the pci device, this child event is queued in
> udev to be started after the pci event has finished. The pci event
> does not finish in time because the firmware request blocks itself.
>
> The current udev logic limits the timeout to 30 sec, while the
> firmware request is 60 sec, so it usually works with a logged error,
> and a 30 second delay.
>
>> The blocking modprobe?
>
> Yes, blocking in the module init path, will deadlock udev. Linking
> code into the kernel must not depend on device init or firmware
> loading.
>
>> For that
>> problem I would say yes. Also here the problem of handling error flows
>> exist. If the driver is kicked of during boot with a initramfs missing the
>> firmware, should we retry until the real root is mounted?
>
> I don't think so. Drivers are not supposed to know about bootup or
> initramfs issues. If they want, they can disable the timeout, and wait
> for userspace to handle the request any time later, but they should
> not try to be smart here.
>
> Currently, firmware requests are cancelled if the firmware isn't
> found, but that's a userspace issue, and nothing the kernel should try
> to work around.
Kay,
Thanks for your very helpful comments. I think I will keep my second method,
i.e. start a work queue entry from the probe routine, and then use synchronous
firmware loads from that queue's callback routine. In most cases, the firmware
loading is already done from a separate routine, thus the flow is not that
different from the current code.
Larry
^ permalink raw reply
* [libudev] udev_monitor_filter_remove not clearing tag filters?
From: Sebastian Wiesner @ 2012-02-23 18:31 UTC (permalink / raw)
To: linux-hotplug
Hi,
I'm maintaining pyudev [1], a pure Python binding for libudev. When
wrapping "udev_monitor_filter_remove()", I stumbled upon a discrepancy
between the documentation of this function and its sources. The
documentation [2] states, that
it removes all filters from the monitor. However, in the source code,
only the list of subsystem filters (as installed by
udev_monitor_filter_add_match_subsystem_devtype()") is cleared. The
list of tag filters is not touched.
So what's the correct behaviour? What should I write in the
documentation of the python bindings?
Greetings,
Sebastian Wiesner
[1] http://pyudev.readthedocs.org
[2] http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/libudev-udev-monitor.html#udev-monitor-filter-remove
^ permalink raw reply
* Re: udev and existing /dev (devtmpfs)
From: Piotr Karbowski @ 2012-03-02 0:46 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F15CB13.1000703@gmail.com>
On 01/23/2012 06:00 PM, Kay Sievers wrote:
> On Mon, Jan 23, 2012 at 17:41, Gabor Z. Papp<gzp@papp.hu> wrote:
>
> It was always 'add' which was suggested. It was the default action,
> but it was changed to 'change' because 'add' must not be used anywhere
> else than once after bootup.
>
> Triggering 'change' has some valid use cases, not many though, and
> most of them are workarounds for broken things.
>
> Settle is only needed to block until broken subsystems catch up with
> reality during bootup, and with reality how hotplug systems work
> today. It is not pulled-in for systems which do not run broken or
> legacy tools.
> o
>
> Yes, that changed May 2010 with udev 154.
I just upgraded to udev-181 and the issue still is there. I believe the
/dev/mapper/ nodes are created by kernel's devtmpfs but the /dev/dm-*
are created by cryptsetup and lvm running in initramfs where is no udev
running. Even if I umount devtmpfs on initramfs level and let udev mount
it again, the changes will be still there. (I do mount --move to
/newroot/dev). Maybe the 'actiond' should care about already-created
nodes as well?
-- Piotr.
^ permalink raw reply
* Re: udev and existing /dev (devtmpfs)
From: Kay Sievers @ 2012-03-02 2:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4F15CB13.1000703@gmail.com>
On Fri, Mar 2, 2012 at 01:46, Piotr Karbowski <piotr.karbowski@gmail.com> wrote:
> On 01/23/2012 06:00 PM, Kay Sievers wrote:
>>
>> On Mon, Jan 23, 2012 at 17:41, Gabor Z. Papp<gzp@papp.hu> Â wrote:
>>
>> It was always 'add' which was suggested. It was the default action,
>> but it was changed to 'change' because 'add' must not be used anywhere
>> else than once after bootup.
>>
>> Triggering 'change' has some valid use cases, not many though, and
>> most of them are workarounds for broken things.
>>
>> Settle is only needed to block until broken subsystems catch up with
>> reality during bootup, and with reality how hotplug systems work
>> today. It is not pulled-in for systems which do not run broken or
>> legacy tools.
>> o
>>
>> Yes, that changed May 2010 with udev 154.
>
>
> I just upgraded to udev-181 and the issue still is there. I believe the
> /dev/mapper/ nodes are created by kernel's devtmpfs but the /dev/dm-* are
> created by cryptsetup and lvm running in initramfs where is no udev running.
> Even if I umount devtmpfs on initramfs level and let udev mount it again,
> the changes will be still there. (I do mount --move to /newroot/dev). Maybe
> the 'actiond' should care about already-created nodes as well?
/dev/mapper/* is never created by the kernel.
/dev/dm-* is always created by the kernel.
You can mount and unmount devtmpfs as many times as you want, it will
always have the same content. If some tool, or you, change the
content, it will stay at the state it was changed to, regardless how
and when you mount it.
Kay
^ permalink raw reply
* [ANNOUNCE] kmod 6
From: Lucas De Marchi @ 2012-03-03 4:39 UTC (permalink / raw)
To: linux-modules, LKML, linux-hotplug
Hey!! kmod 6 is out:
ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-6.tar.xz
ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-6.tar.sign
The first noticeable change is that we are now hosting kmod on
kernel.org. The new repository can be found here:
http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=summary
This version is very shorter than previous and this only indicates we
are reaching a maintenance phase. Everyone is advised to upgrade from
previous versions (including distros packaging kmod 5 and wanting to
freeze in that version). There were some important bugs fixed. Check
NEWS file for more information:
http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=blob;f=NEWS;hA81097b8334e6145e556fc12ee42922d5751fb3;hb=HEAD
Shortlog is below. Thanks for everyone that helped with this release.
Lucas De Marchi
Dan McGee (1):
testsuite: libtestsuite depends on individual components
Dave Reisner (5):
testsuite: add .path member to test struct
libkmod/module: add kmod_module_apply_filter method
modinfo: use new apply_filter method to avoid builtins
find builtins by property, not initstate
modprobe: show builtin label on --show-depends
Lucas De Marchi (30):
libkmod-module: probe: Fix ignore-loaded flag not being applied
testsuite: macronify main function
testsuite: macronify test definitions
testsuite: update README file
testsuite: add tests to modprobe --show-depends
build-sys: add rule to pack rootfs
Check if libc has __xstat
Mark functions with attribute noreturn
test: remove test-state
libkmod-module: probe: fix infinite loop with softdeps
libkmod-index: don't print an error if index doesn't exist
TODO: add tasks and bug fixes
testsuite: add test for builtins with modprobe
kmod-module: lookup: search modules.builtin file too
testsuite: fix color of unexpected failure
Downgrade log level when modules.dep{,.bin} don't exist
Add missing newlines
libkmod-module: probe: check if module exists for install cmds
TODO: update and organize items
libkmod-module: don't treat "coming" as in-kernel
Move repository to kernel.org
libkmod-module: fill builtin's name
libkmod-index: free node when we have only partial match
man: detail modprobe.blacklist in kcmdline
Downgrade log message: refcnt file may not exist
libkmod-index: do not pre-populate mmap
Fix wrong printf format string
Add kmod_module_apply_filter() to doc-sections file
Use upper case after Deprecated in doc
kmod 6
Wouter van Kesteren (1):
Fix path.c's function pointer defenitions.
^ permalink raw reply
* Re: [ANNOUNCE] kmod 6
From: Lucas De Marchi @ 2012-03-03 4:56 UTC (permalink / raw)
To: Lucas De Marchi; +Cc: linux-modules, LKML, linux-hotplug
In-Reply-To: <CAMOw1v5TpPiQG4BLdtDzDTgqdf+9Y49cLvgpD+x0-3nY3Xg12A@mail.gmail.com>
On Sat, Mar 3, 2012 at 01:39, Lucas De Marchi
<lucas.demarchi@profusion.mobi> wrote:
> Hey!! kmod 6 is out:
>
> ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-6.tar.xz
> ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-6.tar.sign
>
> The first noticeable change is that we are now hosting kmod on
> kernel.org. The new repository can be found here:
>
> http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=summary
>
> This version is very shorter than previous and this only indicates we
> are reaching a maintenance phase. Everyone is advised to upgrade from
> previous versions (including distros packaging kmod 5 and wanting to
> freeze in that version). There were some important bugs fixed. Check
> NEWS file for more information:
> http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=blob;f=NEWS;hA81097b8334e6145e556fc12ee42922d5751fb3;hb=HEAD
This link is wrong, it should be the following one:
http://git.kernel.org/?p=utils/kernel/kmod/kmod.git;a=blob;f=NEWS;h€9cfaf90526e0579b08ad3661ca4593e726a6ba;hb&906fe73eb8ca40761c0378ccdc1f2ed9a15a08
Lucas De Marchi
^ permalink raw reply
* A rule gets applied only after running `udevadm test`
From: Rogutės Sparnuotos @ 2012-03-04 21:00 UTC (permalink / raw)
To: linux-hotplug
I have 2 custom rules to rename network interfaces:
SUBSYSTEM="net", ACTION="add", ATTR{address}="00:1f:d0:5a:7d:48",
NAME="eth_int"
SUBSYSTEM="net", ACTION="add", ATTR{address}="00:50:22:e9:7d:09",
NAME="eth1"
But they aren't triggered on boot (although another rule from the same
file is applied). Now if I run
$ udevadm test --actiond \
/sys/devices/pci0000:00/0000:00:1c.4/0000:04:00.0/net/eth1
$ udevadm test --actiond \
/sys/devices/pci0000:00/0000:00:1e.0/0000:05:01.0/net/eth0
the interfaces get renamed. What could I do to make these rules work on
boot? Could this be an udev bug caused by a module-less kernel?
^ permalink raw reply
* Re: A rule gets applied only after running `udevadm test`
From: Kay Sievers @ 2012-03-04 23:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <jj0l5p$kl$1@dough.gmane.org>
On Sun, Mar 4, 2012 at 22:00, RogutÄ—s Sparnuotos <rogutes@googlemail.com> wrote:
> I have 2 custom rules to rename network interfaces:
>
> SUBSYSTEM="net", ACTION="add", ATTR{address}="00:1f:d0:5a:7d:48",
> NAME="eth_int"
> SUBSYSTEM="net", ACTION="add", ATTR{address}="00:50:22:e9:7d:09",
> NAME="eth1"
>
> But they aren't triggered on boot (although another rule from the same
> file is applied). Now if I run
>
> $ udevadm test --actiond \
> /sys/devices/pci0000:00/0000:00:1c.4/0000:04:00.0/net/eth1
>
> $ udevadm test --actiond \
> /sys/devices/pci0000:00/0000:00:1e.0/0000:05:01.0/net/eth0
>
> the interfaces get renamed. What could I do to make these rules work on
> boot? Could this be an udev bug caused by a module-less kernel?
Does:
udevadm trigger --actiond
make it work the same way as running 'udevadm test'? Then it's more
likely an issue with your init system/bootup logic and not with udev.
Kay
^ 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