| onebuck |
08-04-2012 09:29 AM |
"Well, udev in this devel cycle has certainly been interesting! "
Hi,
I have been catching up on some of things that are floating on my TODO. Over looked this changelog entry;
Code:
Sun Jul 22 22:38:36 UTC 2012
Howdy! Lots of shiny stuff here, including the long awaited Xfce 4.10!
Thanks to Robby Workman for the initial set of build scripts, and lots
of testing (plus some very helpful notes about things such as the proper
build order). I'm calling this a beta (finally!), and it's really very
close to what we expect to release. Test away.
BTW, Mercury leaves retrograde on August 8th, position 01:26 Leo. ;-)
...
...
a/udev-182-x86_64-1.txz: Upgraded.
Well, udev in this devel cycle has certainly been interesting! A fair
number of odd bug reports have been coming in, and we hadn't really been
able to get a handle on the source of the issues. Quite some time ago
we started testing udev-182, and noticed that it caused some issues with
the persistent net and cd rules. There'd sometimes be two entries per
device, so a machine with a single Ethernet card might come up showing the
card as eth1, with two rules in 70-persistent-net.rules (eth0 and eth1).
We tested a lot of udev versions trying to determine where the problem
started, and it seemed to begin with version 176, the first one that
used libkmod rather than calling out to module-init-tools to load modules.
Asking upstream about it, they suggested that we just turn the generation
of persistent rules off. They'd already turned it off by default. "Make
'em make rules!" seemed to be the answer, and since I remember well why
the autogeneration of net and CD rules came about, I wasn't really happy
with that answer. After deploying the "safe" upgrade to 175, we got a
couple of reports of this same issue happening (though none of us could
reproduce the issue with 175). Robby ended up making some patches to
the rule writing scripts for udev-182 that were able to stop the doubling
up of rules, but the devices themselves would still be misnumbered on the
first boot without rules, and would then be correct after a reboot.
Last week I sat down determined to figure out where the race condition
was. After endless reboots with various tests, I got the idea to put my
network modules on the initrd and have it shell out so that I could take
a look at them. What I found was that the rules were generated correctly
on the initrd. Well, that was a surprise, but I must have had some kind
of hunch to even try a test like that. On another hunch, I ran
"pstree -c -p | grep udevd" on the running system. Heh. There it was.
We had been running two copies of udevd, and they were fighting it out.
At some point along the line, udevd was changed. It used to be that if
you tried to start a second copy it wouldn't start, and would exit with
status 1, and our rc.udev script relied on this behavior. Fixing the
problem was considerably easier than finding it... rworkman and I made
some changes in rc.udev to check if udevd was already running instead
of expecting it to check for itself. Another change was required to
cause it to write out rules if they didn't exist already, and then to
read them back in (otherwise optical symlinks were still missing on first
boot without rules). There's still one issue that was also present with
udev-175, which is that a hotplugged optical drive won't get symlinks
unless it has been in at boot and had rules generated for it then.
Otherwise, things are looking considerably better. Firmware is loading
correctly, rules are autogenerated properly again, and several devices
that were missing in /dev have returned.
So, there's the story. Maybe more than you really wanted to know. ;-)
Thanks to rworkman for his help on this. Please report any new problems.
And if anyone knows how to get symlinks working for a hotplugged optical
drive like they did in udev-165, a fix would be most appreciated.
I have just updated my -currrent 'ISO' and will be installing on a new Dell Laptop. Anyone notice these problems with 'udev'? I believe PV does have this problem corrected but would like to confirm from other Slackware -current users. I am wanting to do some testing with a newer Laptop. My laptop collection is getting large at this point in time. Just cannot bear to rid my babies from the collective. :) |
