/class/net/wifi0 times out after three minutes

Don't Ctrl-C at this point, instead wait about three minutes. Then the boot sequence should carry on by itself; attach /var/log/udev from this boot.

If after 5 minutes, it still hasn't carried on, then please let me know as this would indicate a kernel problem.

Am Montag, 13. März 2006 12:18 schrieb Scott James Remnant:

> Comment:
> Don't Ctrl-C at this point, instead wait about three minutes. Then the
> boot sequence should carry on by itself; attach /var/log/udev from this
> boot.

As you said, If I wait about 3 minutes, everything is booting up fine.

I attached you the gzipped udev logfile. The boot was with some usb and other
devices plugged in but the problem still exists if being unplugged from
everything.

Best wishes.
 Martin
--
Glaubwürdigkeit ist ein soziales Konstrukt, das wesentlich aus
Anerkennung erwächst. (Andreas Peeck in de.admin.news.groups)

There are some other devices plugged in into my laptop but even without them, it is hanging for approx. 3 min.

This appears to be being caused by class/net/wifi0. It's the only UEVENT for which there is no UDEV, which means that udev did not process, or did not finish processing this event. The UEVENT is also before the 30s wait.

That's consistent with udev timing out after three minutes because the rules for this device failed to complete.

I've subscribed Martin Pitt to this bug because I suspect this is a linux-wlan-ng device (by the name) so would like to see what rules he added for those.

Could you attach a copy of "ls /etc/udev/rules.d" for me.

It's a cisco aironet 350 mini pci device, works with the airo driver.
lspci says: 0000:02:02.0 Network controller: AIRONET Wireless Communications Cisco Aironet Wireless 802.11b.

martin@arrakis:~$ ls /etc/udev/rules.d/
00-init.rules 45-libsane.rules 85-ifupdown.rules
025_logitechmouse.rules 60-symlinks.rules 85-pcmcia.rules
10-custom.rules 65-persistent-disk.rules 90-hal.rules
20-names.rules 80-programs.rules 90-modprobe.rules
25-iftab.rules 85-alsa.rules 99-udevmonitor.rules
40-permissions.rules 85-hal.rules
45-libgphoto2.rules 85-hdparm.rules

Custom rule is:

martin@arrakis:~$ cat /etc/udev/rules.d/10-custom.rules
BUS=="usb", KERNEL=="ttyUSB[13579]", SYMLINK="tungsten", MODE=="666"

Interesting

With the system is up and running, could you:
$ sudo -s
# killall udevd
# UDEV_LOG=info udevd --daemon
# udevplug /class/net/wifi0

in theory that should also take three minutes, then attach /var/log/syslog

Also could you attach /etc/network/interfaces and /etc/iftab

OK, this produced no delay, probably because syslog is telling:

/var/log/syslog:

Mar 16 14:55:10 localhost sudo: PAM unable to dlopen(/lib/security/pam_foreground.so)
Mar 16 14:55:10 localhost sudo: PAM [dlerror: /lib/security/pam_foreground.so: cannot open shared object file: No such file or directory]
Mar 16 14:55:10 localhost sudo: PAM adding faulty module: /lib/security/pam_foreground.so
Mar 16 14:55:31 localhost udevd[6917]: main: will daemonize
Mar 16 14:55:31 localhost udevd[6918]: main: initialize max_childs to 64
Mar 16 14:55:31 localhost udevd[6918]: main: initialize max_childs_running to 16
Mar 16 14:55:49 localhost udevplug[6919]: visit_entry: error stat '/sys/class/net/wifi0': No such file or directory

/etc/network/interfaces (removed comments):

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

/etc/iftab (removed comments):

eth0 mac 00:09:6b:bf:00:21
eth1 mac 00:02:8a:9e:c9:33

OK, it isn't /class/net/wifi0, it's /class/net/wifi0_ifrename

syslog is also more promising then...

Mar 17 00:26:21 localhost udevd[7797]: main: will daemonize
Mar 17 00:26:21 localhost udevd[7798]: main: initialize max_childs to 64
Mar 17 00:26:21 localhost udevd[7798]: main: initialize max_childs_running to 16
Mar 17 00:26:50 localhost udevd[7798]: udev_event_run: seq 2480 forked, pid [7800], 'add' 'net', 0 seconds old
Mar 17 00:26:50 localhost udevd-event[7800]: wait_for_sysfs: file appeared after 0 loops
Mar 17 00:26:50 localhost udevd-event[7800]: run_program: 'iftab_helper wifi0_ifrename 00:02:8a:9e:c9:33 801'
Mar 17 00:26:50 localhost udevd-event[7800]: run_program: '/lib/udev/iftab_helper' (stdout) 'eth1'
Mar 17 00:26:50 localhost udevd-event[7800]: run_program: '/lib/udev/iftab_helper' returned with status 0
Mar 17 00:26:50 localhost udevd-event[7800]: udev_rules_get_name: rule applied, 'wifi0_ifrename' becomes 'eth1'
Mar 17 00:26:50 localhost udevd-event[7800]: rename_net_if: changing net interface name from 'wifi0_ifrename' to 'eth1'
Mar 17 00:29:50 localhost udevd[7798]: udev_done: seq 2480, pid [7800] exit with 1, 180 seconds old

/etc/iftab and /etc/network interfaces are still the same.

The renaming process seems to work "in time" for me but udev is taking a long break.

there's a wifi_ifrename_ in sys after

$ sudo -s
# killall udevd
# UDEV_LOG=info udevd --daemon
# udevplug /class/net/wifi0

The difference when I udevplug this one is that it's not taking the 3 minute break and it has some additional lines:

Mar 17 00:31:47 localhost udevd-event[7847]: rename_net_if: changing net interface name from 'wifi0_ifrename_' to 'eth1'
Mar 17 00:31:47 localhost udevd-event[7847]: rename_net_if: error changing net interface name: File exists
Mar 17 00:31:47 localhost udevd-event[7847]: pass_env_to_socket: passed 154 bytes to socket '/org/freedesktop/hal/udev_event',
Mar 17 00:31:47 localhost udevd-event[7847]: run_program: '/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto wifi0_ifrename_'
Mar 17 00:31:47 localhost udevd-event[7847]: run_program: '/sbin/start-stop-daemon' returned with status 0
Mar 17 00:31:47 localhost udevd-event[7847]: pass_env_to_socket: passed -1 bytes to socket '/org/kernel/udev/monitor',
Mar 17 00:31:47 localhost udevd-event[7847]: udev_event_run: seq 2481 finished

Adding "arp 1" at the end of /etc/iftab fixes this hang. See also Bug #31182

Ah, of course it will!

Martin, could you try adding that to your /etc/iftab -- if that works, could you let me know when you installed this system.

Thanks

OK, this fixed it. At least the last bootup went fine after adding the arp 1.

I installed the system somwhere around end of october - beginning of december last year from a kubuntu 5.10 cd and upgraded to dapper after the installation.

Thanks for help, I'll drop a line if I still have problems with the above.

Thanks Martin. I'll close this bug because your machine was installed before we fixed netcfg to prevent this.