LinuxQuestions.org - udev-182 in -current

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - udev-182 in -current (https://www.linuxquestions.org/questions/slackware-14/udev-182-in-current-4175418157/)

udev-182 in -current

Is this working for anyone? Mine is stuck in a reboot-loop not able to find /dev/sda4 (my root partition) Had to roll back to udev-165

btw, if you find cdrecord is not working on the new udevs, you need to restore this line to /lib/udev/rules.d/80-drivers.rules

SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_device", TEST!="[module/sg]", RUN+="/sbin/modprobe -bv sg"

yes, it worked on my desktop, workstation, and laptop :)

mine worked fine with huge-smp, fixing some firmware loading problems as well.

Quote:

Originally Posted by Neil65 (Post 4735507)

Is this working for anyone? Mine is stuck in a reboot-loop not able to find /dev/sda4 (my root partition) Had to roll back to udev-165

Same problem here, have to roll back to udev-165.

I noticed there was a udev segmentation fault.
After that e2fsck not able to find /dev/sda5 (my root partition), it just reboot.

BTW, I'm running 3.5.0 kernel(without module support).

udev-175 worked fine.

udev-176 and later no longer creates the /dev entries (relying on devtmpfs), so make sure CONFIG_DEVTMPFS is enabled in your kernel.

After upgrading to latest set of changes, my Slackware64 installation is hanging upon trying to start desktop environment - for example, I can see KDE loading, but keyboard and mouse are not responding. It's really vanilla installation, with NVIDIA binary driver added only (that I reinstalled after this upgrade, but this didn't help), on ThinkPad W520 laptop. So far, the only suspicious thing I've found is that t the end of boot, after gpm loaded, following message is printed:
O0o.oops(): [server_tools.c(76)]: Could not open (null)

Quote:

Originally Posted by volkerdi (Post 4735604)

udev-176 and later no longer creates the /dev entries (relying on devtmpfs), so make sure CONFIG_DEVTMPFS is enabled in your kernel.

Yeah! After enable it, udev-182 worked fine!
Thank you very much!

(I disabled this option cause I want to compile a "minimal" kernel).

Quote:

Originally Posted by cgorac (Post 4735614)

After upgrading to latest set of changes, my Slackware64 installation is hanging upon trying to start desktop environment...

After downgrading to udev-175, I am able now to start KDE properly (in particular, keyboard and mouse are responding).

On the other side, I've checked dmesg, and I can see:
[ 5.792041] udev[1178]: starting version 165
[ 7.014032] udevd[1383]: starting version 175
there - don't know is this supposed to be this way, or I should do something to disable starting version 165?

cgorac, you need to rebuild your initrd. :)

Quote:

Originally Posted by TommyC7 (Post 4735631)

cgorac, you need to rebuild your initrd. :)

Thanks, that fixed it indeed. Out of curiosity - how users were supposed to know this?

Quote:

Originally Posted by cgorac (Post 4735648)

Thanks, that fixed it indeed. Out of curiosity - how users were supposed to know this?

On one hand, that's a legitimate question. On the other hand, this is not a new release of Slackware - we're talking about the development branch that's intended for users who either know how the system fits together or want to *learn* how it fits together. If you're not in one of those groups, then you should wait for the release, after which rebuilding the initrd will be an obvious step due to the kernel upgrade.

Now, which of those two hands has the most appropriate answer? I'm not sure; I think they're both appropriate. :-)

Quote:

Originally Posted by cgorac (Post 4735648)

Thanks, that fixed it indeed.

Just to clarify it here: I was intending to say that udev-182 upgrade worked fine, once I ran mkinitrd after doing the upgrade.

@rworkman: I don't know... I consider myself knowledgeable user, for >10 years I'm using Slackware only; but for example, even that I'm using generic kernels from long ago, I still don't know exactly after which upgrades mkinitrd should be run (except, of course, after kernel upgrade), nor where/how to found this info.

Understood. Even though I didn't elaborate on it as much, I really did mean it when I said that it was a legitimate question. I'm still trying to figure out how to best document an answer (and where to document it).

Got an excessive delay on startup with udev-182:

Code:

[  10.697038] Console: switching to colour frame buffer device 128x48

[  10.701558] fb0: radeondrmfb frame buffer device

[  10.701600] drm: registered panic notifier

[  10.701705] [drm] Initialized radeon 2.12.0 20080528 for 0000:01:00.0 on minor 0

[  11.101238] cfg80211: World regulatory domain updated:

[  11.101297] cfg80211:    (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)

[  11.101367] cfg80211:    (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

[  11.101437] cfg80211:    (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)

[  11.101506] cfg80211:    (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)

[  11.101576] cfg80211:    (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

[  11.101646] cfg80211:    (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

[  11.480030] intel8x0_measure_ac97_clock: measured 50476 usecs (2433 samples)

[  11.480099] intel8x0: clocking to 48000

[  15.956865] IBM TrackPoint firmware: 0x0e, buttons: 3/3

[  16.187311] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/serio2/input/input7

[  40.828124] cfg80211: failed to add phy80211 symlink to netdev!

[  40.828878] ipw2200: Detected geography ZZH (13 802.11bg channels, 4 802.11a channels)

[  40.904203] Adding 8388604k swap on /dev/sda3.  Priority:-1 extents:1 across:8388604k

Switching back to udev-175 solved the problem.

Thanks, CONFIG_DEVTMPFS fixed it for me. I was also testing 3.4.x and 3.5.x, and had not known about that kernel parameter. Like the last poster, I've also seen some episodes of slowness. Reboot again and its fine. Testing too much stuff at once so I can't attribute it to the kernel or udev. I'm leaning towards udev though. Doesn't fill me with confidence for systemd.

With the older udev before the slack ware birthday update, my BCM4331 wireless network card failed to load the firmware saying no firmware available although I had recompiled the kernel with BCMA enabled. After the upgrade to udev 182, BCM4331 is happy now.

I better check this on my HP Mini Netbook. My BCM4312 has been very disagreeable as of late.

I too got an excessive delay on startup when using udev 182, anybody has the same problem?

Trying to run /sbin/udevadm --debug trigger when the system is already up and running is very fast. I don't know what's wrong with the startup delay though.

Searching the web for "udev 30 seconds" redirected me to ArchWiki. I tried the solution from there (to add the problematic module, ipw2200 in my case, to the initrd) and everything is ok now.

Hi guanx,

I too suspect this is related with my network adapter, I'm having this problem on my HP Pavilion dv6 notebook but not on my desktop.

Here's the output from lspci:

Code:

00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)

00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)

00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)

00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)

00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)

00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)

00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b5)

00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 3 (rev b5)

00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b5)

00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)

00:1f.0 ISA bridge: Intel Corporation HM65 Express Chipset Family LPC Controller (rev 05)

00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 05)

00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)

01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Whistler XT [AMD Radeon HD 6700M Series] (rev ff)

07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)

0d:00.0 Network controller: Ralink corp. RT5390 [802.11 b/g/n 1T1R G-band PCI Express Single Chip]

13:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5116 PCI Express Card Reader (rev 01)

19:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)

I've tried blacklisting my wireless and ethernet module using an entry in /etc/modprobe.d/blacklist.conf and add them to my initrd but I still got excessive delay when udev is starting. Checking for udev process after the system is running found it runs two instance, is this normal?

Code:

[dwi@pavilion:rc.d]$ ps aux | grep udev

root      1330  0.0  0.0  28432  1896 ?        Ss  10:33  0:00 /sbin/udevd --daemon

root      6327  0.0  0.0  28428  1360 ?        S    10:59  0:00 /sbin/udevd --daemon

Thanks for your reply

Quote:

Originally Posted by ack_iix (Post 4774643)

Hi guanx,

I too suspect this is related with my network adapter, I'm having this problem on my HP Pavilion dv6 notebook but not on my desktop.

...

Is the delay really caused by your WLAN? Can you post the beginning of your dmesg (e.g. dmesg from the first 40 seconds)?

BTW, This is output from my system:

Code:

$ ps aux | grep udev

root      1039  0.0  0.0  4952  1040 ?        Ss  Sep06  0:00 /sbin/udevd --daemon

root      3938  0.0  0.0  4948  1040 ?        S    15:21  0:00 /sbin/udevd --daemon

root      3940  0.0  0.0  4948  1032 ?        S    15:21  0:00 /sbin/udevd --daemon

guanx    4666  0.0  0.0  2764  880 pts/2    S+  16:00  0:00 grep udev

Hi guanx,

Yesterday I my effort to debug what's causing the delay, I took a crazy step and edit my /etc/rc.d/rc.udev file and I did the following changes:

Code:

change /sbin/udevd --daemon

Code:

/sbin/udevd --debug --daemon &> /var/log/udev.log &

Code:

/sbin/udevadm trigger --type=subsystems --action=add

Code:

/sbin/udevadm --debug trigger --type=subsystems --action=add &> /var/log/udev_subsystems.log &

Code:

/sbin/udevadm trigger --type=devices

Code:

/sbin/udevadm --debug trigger --type=devices --action=add &> /var/log/udev_devices.log &

After these changes by boot suddenly becomes blazing fast again, looking at the log file generated I don't see any error. Is there any possible ill effect of modifying this rc.udev file?

Thanks for your reply