Created attachment 347034 [details] output of strace -s 512 -f -o /root/udev.log /bin/bash -x /sbin/start_udev Last night before I left work I ran: sudo pm-suspend and suspended my laptop. This is the first time I've done that in a long time. Normally I just power off. This morning on the bus ride to work I opened the computer and resumed. It surprisingly worked fine. I'm only mentioning the above, because suspend and resume is not something I do. In the middle of the bus ride I tried to reboot the machine. It went down okay, but during boot up it would stall at "Starting udev: " From there I booted with init=/bin/sh udevtrace udevinfo on my kernel command line and run: setsid /bin/bash -i < /dev/tty1 mount -oremount,rw / mount devpts /dev/pts -t devpts screen strace -s 512 -f -o /root/udev.log /bin/bash -x /sbin/start_udev and looked at the log in one screen window while watching the udev output in another. I got a little confused reading the strace logs. If I ran ps -ef |grep udev, udevd was not running, but according the strace logs it looks like it never exited or crashed. Anyway the last line in the udev debug spew was: run /sys/devices/pci0000:00/0000:00:1d.2/usb7/7-1/7-1.2/7-1.2:1.0 (895) '/usr/sbin/pcscd --hotplug' So I tried mv /usr/sbin/pcscd{,.bak} and rebooting the macine. After that the machine came up. I don't know if that's a red herring though, because it continues to boot now even though I've moved the pcscd binary back. Another interesting fact, since this morning's events my system clock seems to be hosed. Whenever I boot the machine the time is off by several hours. The minutes are fine, though. It doesn't appear to be some utc-edt confusion because the delta is bigger than the the difference between utc and edt. There may be some bizarre hardware failure going on here. I'm just filing the bug report so the strace is saved. Feel free to close it out WORKSFORME or whatever.
pcscd would have been killed after 3 minutes and even after 30 seconds your system should have continued, so I guess this was a kernel/hardware hiccup. Haven't heard about such a bug elsewhere... and you can't reproduce it.. sorry.