headers
Petr Vandrovec | 2 Feb 2008 12:21
Picon
Picon

udevd induced deadlock in loading kernel modules?

Mailer on sf.net says that email address in udev's README is obsolete. 
Oops...
						Petr

-------- Original Message --------
Subject: udevd induced deadlock in loading kernel modules?
Date: Sat, 2 Feb 2008 12:07:19 +0100
From: Petr Vandrovec <petr <at> vandrovec.name>
To: linux-kernel <at> vger.kernel.org
CC: linux-hotplug-devel <at> lists.sourceforge.net

Hello,
   today my system hung during boot, while loading ftdi_sio & loop - I 
have two ftdi serial ports,
and apparently this tricked udevd to start two concurrent modprobes for 
them - so I ended up with
strance "ftdi_sio: gave up waiting for init of module usbserial." for 
each symbol it tried to
import, until I kill-9 process 3137 (see below).  After that loop got 
loaded, and second ftdi's
load finished as well.

Unfortunately I do not have stacktraces of hung modprobe processes. 
Maybe next time, but it
does not look very reproducible.

Kernel is current git (2.6.24, 
ed50d6cbc394cd0966469d3e249353c9dd1d38b9), udev is Debian's 0.114-2,
and module-init-tools are Debian's 3.3-pre11-4.  Kernel is 64bit amd64 
with almost all debugging
(Continue reading)

Permalink | Reply | 3 comments |
headers
Greg KH | 2 Feb 2008 19:55
Gravatar

Re: udevd induced deadlock in loading kernel modules?

On Sat, Feb 02, 2008 at 03:21:16AM -0800, Petr Vandrovec wrote:
> Mailer on sf.net says that email address in udev's README is obsolete. 
> Oops...
> 						Petr
>
> -------- Original Message --------
> Subject: udevd induced deadlock in loading kernel modules?
> Date: Sat, 2 Feb 2008 12:07:19 +0100
> From: Petr Vandrovec <petr <at> vandrovec.name>
> To: linux-kernel <at> vger.kernel.org
> CC: linux-hotplug-devel <at> lists.sourceforge.net
>
> Hello,
>   today my system hung during boot, while loading ftdi_sio & loop - I have 
> two ftdi serial ports,
> and apparently this tricked udevd to start two concurrent modprobes for 
> them - so I ended up with
> strance "ftdi_sio: gave up waiting for init of module usbserial." for each 
> symbol it tried to
> import, until I kill-9 process 3137 (see below).  After that loop got 
> loaded, and second ftdi's
> load finished as well.
>
> Unfortunately I do not have stacktraces of hung modprobe processes. Maybe 
> next time, but it
> does not look very reproducible.
>
> Kernel is current git (2.6.24, ed50d6cbc394cd0966469d3e249353c9dd1d38b9), 
> udev is Debian's 0.114-2,
> and module-init-tools are Debian's 3.3-pre11-4.  Kernel is 64bit amd64 with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott James Remnant | 4 Feb 2008 11:47
Favicon

Re: udev rules - please try again later?

On Wed, 2008-01-30 at 15:17 -0600, Matt Domsch wrote:

> biosdevname has a shortcoming, in that it doesn't know the names of
> all the network devices in a system until after all the network
> drivers have been loaded.  So if a system has NICs of different types,
> such that the tg3, e1000, e100, and 3c59x drivers all need to be
> loaded, biosdevname doesn't necessarily give the "right" answer until
> they all are loaded.
> 
The obvious problem is what if one of those network cards is PCMCIA?
The requisite module will not be loaded until the card is actually
inserted, how do you know that the user hasn't dropped it in their
coffee long ago and doesn't use it anymore?

Scott
--

-- 
Scott James Remnant
scott <at> ubuntu.com
Permalink | Reply | 0 comments |
headers
Matthias Schwarzott | 5 Feb 2008 12:57
Picon
Favicon

[PATCH] No longer depend on GNU install

Hi there!

This patch by Roy Marples changes the make install target to work with non-GNU 
install binaries.

It was submitted here: http://bugs.gentoo.org/show_bug.cgi?id=208815
Original comment:
The -D option is a GNUism for install, and udev itself works fine without GNU
install. Patch to follow for users who have /bin/sh linked to busybox.

Regards
Matthias

--

-- 
Matthias Schwarzott (zzam)
Attachment (udev-install-non-gnu.diff): text/x-diff, 11 KiB
Permalink | Reply | 1 comment |
headers
Greg KH | 4 Feb 2008 23:35
Gravatar

Re: udev rules - please try again later?

On Wed, Jan 30, 2008 at 03:17:26PM -0600, Matt Domsch wrote:
> Background: I wrote biosdevname, a tool that, given an ethernet device
> name like 'eth0', returns the name that BIOS thinks it should have,
> e.g. 'eth1'.  This type of thing is needed for systems where the udev
> natural order of device naming (eth0, eth1, ...) doesn't line up with
> the names printed on the outside of the box (Gb1, Gb2, ...)
> 
> biosdevname has a shortcoming, in that it doesn't know the names of
> all the network devices in a system until after all the network
> drivers have been loaded.  So if a system has NICs of different types,
> such that the tg3, e1000, e100, and 3c59x drivers all need to be
> loaded, biosdevname doesn't necessarily give the "right" answer until
> they all are loaded.  It can look at PCI device types (e.g. Ethernet)
> to know when it thinks they are all loaded.  Take for example, the
> PowerEdge 4600.  It has 2 NICs on the motherboard, one driven by the
> e100 driver, and one by the tg3 driver.  Both are reported to be
> Embedded (e.g. in PCI Slot 0 in the PCI IRQ Routing Table), but the
> chassis labels will say that the e100 port should be considered "eth0"
> while the tg3 port should be considered "eth1".
> 
> If the tg3 driver is loaded, the e100 driver isn't loaded, and
> biosdevname is invoked, it would answer the question "what should the
> name of the thing called eth0 be" incorrectly and respond with "eth0"
> when the right answer would be "eth1".  It would get it correct when
> asked again after loading the e100 driver.
> 
> What I think I need is a response to udev meaning "I don't know,
> please ask me again after all the drivers are loaded".  I have no idea
> if this is feasible, or desirable.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marek Szuba | 5 Feb 2008 20:50
Picon
Favicon

Udev rules for devices created by all_partitions

Hello,

I have run into a certain problem while trying to make udev create 
persistent symlinks to partitions on a card in my reader, namely:

  - if I don't use the option all_partitions, rules like
 	KERNEL=="sd*[0-9]", SYMLINK+="card%n"
work fine but as the reader doesn't notify the system of media changes,
I need to manually force re-reading the partition table - as root,
which defeats the whole point of using the above rule,

  - if I do use the option all_partitions on KERNEL=="sd?" I get all
the partition devices as I should but the above rule never triggers,
thus leaving me without persistent symlinks. This can be a problem if I
e.g. have another hard drive or a USB mass storage device plugged in at
boot time, as this shifts the card reader to another set of device
nodes, rendering older fstab entries useless.

Would you have any suggestions on how to approach the matter? I use 
udev-115, by the way.

Yours sincerely,
--

-- 
MS
-
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Miklos Vajna | 7 Feb 2008 14:01
Picon
Gravatar

Re: udevd induced deadlock in loading kernel modules?

On Sat, Feb 02, 2008 at 03:21:16AM -0800, Petr Vandrovec <vandrove <at> vc.cvut.cz> wrote:
> Mailer on sf.net says that email address in udev's README is obsolete. 
> Oops...
> 						Petr

Kay updated the address on Dec 27, 2007. maybe you are reading some
old README :)

- VMiklos
Permalink | Reply | 0 comments |
headers
Stefan Richter | 7 Feb 2008 18:05
Picon

Re: no INQUIRY from userspace please

(adding Cc linux-hotplug)

James Bottomley wrote:
> On Thu, 2008-02-07 at 11:08 +0100, Stefan Richter wrote:
>> Mike Anderson wrote:
>> > A number of user apps like lvm scanning that execute media access commands
>> > already have filter capability to filter devices that one does not want to
>> > scan. Another class of device scanners just use inquiries which are not
>> > effected by the passive state (though some could probably use udevinfo and
>> > reduce the amount of repeated SCSI inquiries execute on the system.
>> 
>> To expand on this:
>> 
>> At least on desktop systems and SOHO server systems, userspace should
>> _never_ issue INQUIRY.  There are too many broken firmwares out there
>> which assume that there will never be more than one INQUIRY sent.  They
>> start to return garbled data or crash if they get a second INQUIRY.
> 
> It's all very well to say this, but I think if you look at what udev
> does, you'll find that it uses scsi_id to send a VPD inquiry to the
> device so it can populate /dev/disk/by-id, so the point is already
> conceded (and I think looking at a recent camera crash that seems to
> have been precipitated by this, it's already causing us problems).
> 
> This is all a tradeoff.  If you want userspace *never* to issue raw SCSI
> commands like INQUIRY, we're going to have to provide the needed
> information from the kernel via sysfs ... including VPD strings.  This
> is something we've always shovelled off into userspace before.

Well, it's definitely awkward to have to deal with less than perfect
(Continue reading)

Permalink | Reply | 8 comments |
headers
Stefan Richter | 7 Feb 2008 18:13
Picon

Re: no INQUIRY from userspace please

> James Bottomley wrote:
>> It's all very well to say this, but I think if you look at what udev
>> does, you'll find that it uses scsi_id to send a VPD inquiry to the
>> device so it can populate /dev/disk/by-id, so the point is already
>> conceded

PS:  Alas we don't have a practicable way to know how many of the
  - doesn't work with Linux but works to some degree with Windows,
  - doesn't work with a 2.6 based Linux distro but did work with a
    2.4 based distro
kinds of devices are those with this INQUIRY bug or similar bugs.

While non-udev distros slowly went out of fashion on the desktop, there
was a certain frequency of reports of the latter kind of FireWire
devices, but this was before I became aware of that kind of firmware
bug, therefore I don't have any data whether it played a role for these
cases.
--

-- 
Stefan Richter
-=====-==--- --=- --===
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 5 comments |
headers
dlb | 9 Feb 2008 15:13
Picon
Favicon

lookup_group: specified group 'xxx' unknown

Hello,
i'm trying to build a minimal system with udev to manage /dev and when
my rc script launch the udevd process i got errors about unknown group
but i do have a correct /etc/group file with expected groups in it.

I saw in the code of udev_utils.c that udev generate this error when the
getgrnam() function has failed but i don't understand why this one failed.
I'm using busybox 1.9.0 and udev 118 on a X86_64 hardware and i got this
error using either the busybox builtin fonctions or the GNU LibC
fonctions (with /lib/libnss_* libs and a /etc/nsswitch.conf file).
I compiled busybox and udev with GCC 4.2.2 and GNU LibC 2.7-4 (working
on a Debian Sid)
I searched in the udev ML archives but found nothing, I hope this is the
right place to ask.
--

-- 
http://lbdan.free.fr/
-
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |

Gmane