Kay Sievers | 1 May 2007 15:09

[ANNOUNCE] udev 110 release

Here comes a new udev version. Thanks to all who have contributed to
this release.

The tarball can be found here:
  ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/

The development repository can be found here:
  http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary

The ChangeLog can be found here:
  http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog

udev 110
========
Bugfixes.

Removal of useless extras/eventrecorder.sh.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
George Beshers | 2 May 2007 01:42
Picon
Favicon

udevd on very large systems: again


After some testing the following patch seems safe for dealing with computers
with more than 500 processors.  It occurred to me that it might be 
easier and
just as useful to note when udev is running on a large computer (e.g., >= 8p
and >= 16Gb of memory) and simply not worry about throttling at that point.

The patch should apply cleanly against udev-110.

Comments welcome.

George

diff -Naur udev-110.Orig/udevd.c udev-110.new/udevd.c
--- udev-110.Orig/udevd.c	2007-05-01 08:33:39.000000000 -0400
+++ udev-110.new/udevd.c	2007-05-01 12:49:38.000000000 -0400
 <at>  <at>  -347,31 +347,21  <at>  <at> 

 static int cpu_count(void)
 {
-	int f;
-	char buf[65536];
+	FILE* f;
+	char buf[1024];
 	int len;
 	const char *pos;
 	int count = 0;

(Continue reading)

Razza | 2 May 2007 10:47

RE: udev problem DVB-S/T Cards

Razza wrote on 28 April 2007 11:49:
> All,
> I have been playing with udev as I need to pin specific identical DVB
> cards
> to specific nodes, mixing DVB-S and DVB-T is bad!
> I have found how to identify cards etc. but getting the rule right is
> confusing me. I am running Fedora Core 5 and have the following
> standard
> rule in "/etc/udev/rules.d/50-udev.rules" -
> 
> SUBSYSTEM=="dvb", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
> dvb/adapter%%i/%%s $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0660"
> 
> The closest I got to getting things working was by substituting
> "dvb/adapter%%i/" with "dvb/adapter5/", thus forcing the adapter to
> /dev/dvb/adapter5, rule below -
> 
> BUS=="pci", ID=="0000:01:06.0", SYSFS{device}=="0x7146",
> SYSFS{vendor}=="0x1131", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf
> dvb/adapter5/%%s $${K%%%%.*} $${K#*.}'", NAME="%c", MODE="0660"
> 
> Unfortunately that changed the tree/node structure from the norm -
>  /dev/dvb/
>  `-- adapter5
>      |-- ca0
>      |-- demux0
>      |-- dvr0
>      |-- frontend0
>      `-- net0
> 
(Continue reading)

Matthias Schwarzott | 2 May 2007 11:19
Picon
Favicon

eth1394 has problems with persistent-net with kernel 2.6.21

Hi!

As eth1394 had some "small" change in Kernel 2.6.21, it now has no 
parent-device, and thus no DRIVERS=="?*". So the generated rule for 
persistent-net does no longer apply, and we get the known sympthoms of 
devices called "eth?_rename" and 30sec timeout at boot.

The relevant change to that driver:

--- linux-2.6.20/drivers/ieee1394/eth1394.c      2007-02-21 18:17:20.000000000 
+0100
+++ linux-2.6.21/drivers/ieee1394/eth1394.c      2007-04-27  <at>  <at>  -585,7 +584,10 
 <at>  <at> 
         }

        SET_MODULE_OWNER(dev);
+#if 0
+       /* FIXME - Is this the correct parent device anyway? */
        SET_NETDEV_DEV(dev, &host->device);
+#endif

        priv = netdev_priv(dev);

Matthias
--

-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
(Continue reading)

Marco d'Itri | 2 May 2007 11:23
Picon
Favicon

Re: eth1394 has problems with persistent-net with kernel 2.6.21

On May 02, Matthias Schwarzott <zzam <at> gentoo.org> wrote:

> As eth1394 had some "small" change in Kernel 2.6.21, it now has no 
> parent-device, and thus no DRIVERS=="?*". So the generated rule for 
> persistent-net does no longer apply, and we get the known sympthoms of 
> devices called "eth?_rename" and 30sec timeout at boot.
Let's just say that this sucks.

--

-- 
ciao,
Marco

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Matthias Schwarzott | 2 May 2007 11:25
Picon
Favicon

Re: eth1394 has problems with persistent-net with kernel 2.6.21

On Mittwoch, 2. Mai 2007, Marco d'Itri wrote:
> On May 02, Matthias Schwarzott <zzam <at> gentoo.org> wrote:
> > As eth1394 had some "small" change in Kernel 2.6.21, it now has no
> > parent-device, and thus no DRIVERS=="?*". So the generated rule for
> > persistent-net does no longer apply, and we get the known sympthoms of
> > devices called "eth?_rename" and 30sec timeout at boot.
>
> Let's just say that this sucks.
Full ack, eth1394 should not be autoloaded! Perhaps we add it to the modules 
blacklist for next gentoo udev ebuild. But well, this is no solution for 
people using it really. Should we in this case remove the DRIVERS=="?*" ?

Matthias

--

-- 
Matthias Schwarzott (zzam)

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Bryan Kadzban | 2 May 2007 13:08

Re: udev problem DVB-S/T Cards

Razza wrote:
> I am specifically interested in what 'K' is at various points in this
> rule -
> 
> 
> BUS=="pci", ID=="0000:01:06.0", SYSFS{device}=="0x7146", 
> SYSFS{vendor}=="0x1131", PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb};
> printf dvb/adapter5/%%s $${K%%%%.*} $${K#*.}'", NAME="%c",
> MODE="0660"

Well, it starts out at %k (the kernel NAME, which should be available
via udevinfo).  After that, you should be able to set K=<that name> in a
normal shell, and then start running subsequent commands from the shell,
while echoing $K from time to time.

(However, note that udev requires double dollar signs and double percent
signs, so if you paste the various echos and printfs into a shell,
you'll have to un-escape those characters.  I.e., %%s should be run
through the shell as %s, and %%%% should be turned into %%.)

And actually, K only changes once (when it's set to ${K#dvb} just before
the printf.  The rest of that rule is just formatting the output.

(Oh, and you hopefully already know this from the documentation, but
NAME="%c" sets NAME to the output of the PROGRAM.)

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
(Continue reading)

Grahame Jordan | 2 May 2007 13:29
Picon

ifupdown problems

Hi,

I am using Kubuntu 7.4 but the same happens on Debian etch.

When I plug in my usb cable for my gumstix thing the usb interface comes 
up but it does not even attempt to get the dhcp from the gumstix.
The problem seems to be that the interface is up before it gets to ifup 
and therefore ifup thinks the interface is already up but it's not.

eg:
ifup usb0
ifup: interface usb0 already configured

In my old sarge interfaces file I had this:
mapping hotplug
script grep
map usb0
iface usb0 inet dhcp

But this does not work on Kubuntu 7.4 for "hotplug", because in 
85-ifupdown.rules we have:

ACTION=="add",     RUN+="/sbin/start-stop-daemon --start --background 
--pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto 
$env{INTERFACE}"

Which will only ifup the auto sections of interfaces. So I changed it to 
--allow hotplug --force.

ACTION=="add",      RUN+="/sbin/start-stop-daemon --start --background 
(Continue reading)

Marco d'Itri | 2 May 2007 13:35
Picon
Favicon

Re: eth1394 has problems with persistent-net with kernel 2.6.21

On May 02, Matthias Schwarzott <zzam <at> gentoo.org> wrote:

> Full ack, eth1394 should not be autoloaded! Perhaps we add it to the modules 
> blacklist for next gentoo udev ebuild.
I do not consider this to be a valid solution.

> But well, this is no solution for 
> people using it really. Should we in this case remove the DRIVERS=="?*" ?
No, because this will breaks many more cases (at least VLANs and some
wireless drivers IIRC).

--

-- 
ciao,
Marco

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
Olivier Blin | 2 May 2007 13:50

Re: eth1394 has problems with persistent-net with kernel 2.6.21

Matthias Schwarzott <zzam <at> gentoo.org> writes:

> On Mittwoch, 2. Mai 2007, Marco d'Itri wrote:
>> On May 02, Matthias Schwarzott <zzam <at> gentoo.org> wrote:
>> > As eth1394 had some "small" change in Kernel 2.6.21, it now has no
>> > parent-device, and thus no DRIVERS=="?*". So the generated rule for
>> > persistent-net does no longer apply, and we get the known sympthoms of
>> > devices called "eth?_rename" and 30sec timeout at boot.
>>
>> Let's just say that this sucks.
> Full ack, eth1394 should not be autoloaded! Perhaps we add it to the modules 
> blacklist for next gentoo udev ebuild.

There should be not need for that, since eth1394 won't be autoloaded
anymore at controller initialization in future kernel releases (and
it's already this way in -mm kernel):
http://lkml.org/lkml/2007/4/29/361

--

-- 
Olivier Blin - Mandriva

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Gmane