udevadm settle timeout of 120 seconds delays eth0 startup after boot

[rmrichesjr]

(New TinyCore user, first posting in this forum.)

For the first two minutes after booting, eth0 does not come up, apparently because "udevadm settle" waits 120 seconds to time out.  I see this with TinyCore 4.0.1, MicroCore 4.0.1, and a remastered ISO based on 4.0.2.  All cases were in a virtual machine under qemu/libvirt.  In some cases, the console message says scsi_wait_scan is in the queue.  In other cases, it says input devices (mouse and such) are in the queue.  Multiple udevd processes are running (which I would guess might be a bad thing), as few as 3 and as many as 48.  (120 / 48 = 2.5000, which looks a bit suspicious.)

Any suggestions?

Thanks,

Robert

(Googled for solutions but did not find anything applicable.  This issue is a little similar to another posting from someone else, but the symptoms are fairly different.)

[rmrichesjr]

I experimented with lots of udev rule changes to try to solve this problem.  However, nothing worked.  So far, the best solution I found was to modify the virtual machine's configuration to eliminate the QEMU Tablet that was being used as a mouse-type input device.  It appears that is sufficient and as far as I could tell necessary to solve the problem.

Thanks to all who read the first posting and tried to think of a way to solve it for me.

[nim108]

Thought this was worth a bump. I am running into the same issue PXE booting TC 4.0.2 and cannot figure out how to fix this for the life of me. The network interfaces do not work until udevadm settle times out (120 seconds). Any suggestions on how to fix this? Unlike rmrichesjr, I am not virtualizing this through something like qemu so that solution will not work for me.

I get basically the same error message: udevadm settle timeout of 120 seconds reached. the event queue contains /sys/module/scsi_wait_scan (836)

For the record, the PC this is being PXE booted on is quite old so I am running it with boot codes such as "noapic nolapic acpi=off clocksource=jiffies" to turn power save features off and bypass the clocksource tsc unstable message (if it matters at all).

Initially I was also getting the message "e100: eth0: e100_request_firmware: Failed to load firmware "e100/d102e_ucode.bin": -2" which resulted in the udevadm settle timeout to call out yenta_cardbus (837) instead, but after loading firmware.tcz extension, firmware error was gone but udevadm settle timeout still remained as mentioned above.

[curaga]

This is a kernel or udev bug, I think I said that in another thread.

The timeout can be shortened as a workaround, in dhcp.sh. Some 5 seconds could be an ok value to still let the network driver init.

[nim108]

This is a kernel or udev bug, I think I said that in another thread.

The timeout can be shortened as a workaround, in dhcp.sh. Some 5 seconds could be an ok value to still let the network driver init.

Do you mean adding a timeout? Because I don't see an existing one in dhcp.sh. All I see is the call /sbin/udevadm settle. Is the timeout specified elsewhere? Thanks, really want to get this issue resolved. 5 seconds would be fine for me but I'm just not sure where to add it.

[maro]

Well, according to an 'udevadm' (online) man-page the 'settle' command can take a '--timeout=seconds' option.

Therefore I'd guess that udevadm settle --timeout=5 might be what curaga meant.

[nim108]

^ Thank you sir, I will try that. I must have overlooked it in the man pages.

[curaga]

Please tell us how it works. If it's good, maybe we'll need to add it.

[nim108]

Please tell us how it works. If it's good, maybe we'll need to add it.

Will do, again, this is on a very old machine, so perhaps this is not a major bug with only a few users experiencing it. It seems to be a bug of udevadm though and not TCL, but I am not sure.

EDIT: Thought I'd add to this post, but adding a simple timeout is really not a fix to this situation, though it will suffice for now. So why is udev causing issues? I booted up another distro that uses a 2.6.37 kernel with the same bootcodes, and udev seems to be fine there.

[nim108]

No udevadm settle timeouts in TCL 3.8.4 either (is it even in there?), the 2.6.33 kernel seems to be much friendly on the older hardware I am running it on as well.

[curaga]

There is some driver waiting on something, and udev waits on it, this is my guess.

[andrewb]

Could this be the reason wifi is very slow to connect with TC4 compared to TC3.8.4?

I have an eeepc 900ax with RT2680 hardware.  After eventually finding the extension required to get this operating in TC4 (yet another undocumented 'feature' of the TC3 -> TC4 upgrade that has caused pain) I have noticed wifi is very slow to connect. It does not manage to make a connection by the time the desktop has started & I've started firefox, appbrowser, or anything requiring a net connection. TC3.8.4 always made the connection by the time any application was started.

[curaga]

Assuming you start the wifi in bootlocal, you can time it in both TC3 & 4 via starting syslog and adding logger statements before and after the wifi commands.

It's only second accuracy, but that should be enough for this problem.