Bug#649033: linux-image-3.1.0-1-amd64: boot sometimes stuck with waiting for /dev to be fully populated.
On 2012-01-04 09:48:48 +0100, Vincent Lefevre wrote: It happened yeaterday, for the first time after I removed the 'quiet' option. There were a few lines about the wifi chipset, and the last message was: iwlagn :0c:00.0: Refused to change power state, currently in D3 This has occurred another time. Since this bug was too generic (other users posted different causes), I've opened a new one: bug #654822 -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120105223852.ga3...@xvii.vinc17.org
Bug#649033: linux-image-3.1.0-1-amd64: boot sometimes stuck with waiting for /dev to be fully populated.
Hi, On 2011-11-17 00:52:18 +, Ben Hutchings wrote: On Thu, Nov 17, 2011 at 01:29:08AM +0100, Vincent Lefevre wrote: The boot sometimes freezes with the message: waiting for /dev to be fully populated. There was a bug report against udev (bug #606192), which is closed, suggesting a kernel bug if the timeout doesn't occur, which is the case here (with linux-image-3.1.0-1-amd64 3.1.1-1). [...] Please start the kernel without 'quiet' (the GRUB 'rescue mode' entries will do this) so the kernel logs more to the console, and send us the resulting messages (a photograph with readable text is fine). It happened yeaterday, for the first time after I removed the 'quiet' option. There were a few lines about the wifi chipset, and the last message was: iwlagn :0c:00.0: Refused to change power state, currently in D3 -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120104084848.ga24...@xvii.vinc17.org
Bug#649033: linux-image-3.1.0-1-amd64: boot sometimes stuck with waiting for /dev to be fully populated.
I’m seeing this too on my ThinkPad X201i. The kernel I’m running is linux-image-3.1.0-1-686-pae version 3.1.1-1. It happens quite frequently, most often when first booting in the morning; forcing a shutdown and trying booting again usually results in a normal boot. If there’s some debug output I can can collect to help track this down, please let me know. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#649033: linux-image-3.1.0-1-amd64: boot sometimes stuck with waiting for /dev to be fully populated.
Hello, On Thu, Nov 17, 2011 at 01:29:08AM +0100, Vincent Lefevre wrote: Package: linux-2.6 Version: 3.1.1-1 Severity: important The boot sometimes freezes with the message: waiting for /dev to be fully populated. There was a bug report against udev (bug #606192), which is closed, suggesting a kernel bug if the timeout doesn't occur, which is the case here (with linux-image-3.1.0-1-amd64 3.1.1-1). http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606192#98 If the boot does not continue then it looks like that udev loaded a module which crashed your system (so this would be a kernel bug). I'm not the only one who has this problem: http://identi.ca/conversation/84449449 Occasionally I see this, too. Today I waited a bit longer and got more output after some time: udevd[422]: timeout: killing '/sbin/modprobe -b acpi:SMO1200:PNP0C31:' [444] (repeated many times) udevadm settle - timeout of 120 seconds reached, the event queue contains: ... blurred image ... LNXSYSTM:00/device:00/PNP0A08:00/device:0a/SMO1200:00 (852) udevd[422]: timeout: killing '/sbin/modprobe -b acpi:SMO1200:PNP0C31:' [444] (copied from a photo) than the booting process continued as usual. SMO1200 is my laptop's TPM chip. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2027093915.gc17...@pengutronix.de
Bug#649033: linux-image-3.1.0-1-amd64: boot sometimes stuck with waiting for /dev to be fully populated.
I've had a similar problem with 3.0.0, in my case the processor module hung the system on every boot. Although it wasn't a real solution, adding processor.nocst=1 as a boot parameter did the trick. However, it is true that in many cases the freeze is not a problem of udev but of a kernel module that udev loads during boot. Sometimes it helps to grab a list of loaded modules when/if the system boots properly with another kernel, then boot the problematic kernel in single mode (or using init=/bin/bash) and try loading one module at a time. That's how I found the culprit in my case. -- Mauro -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1322049260.81182.yahoomail...@web38005.mail.mud.yahoo.com
Bug#649033: linux-image-3.1.0-1-amd64: boot sometimes stuck with waiting for /dev to be fully populated.
On 2011-11-23 03:54:20 -0800, Mauro Meloni wrote: However, it is true that in many cases the freeze is not a problem of udev but of a kernel module that udev loads during boot. Sometimes it helps to grab a list of loaded modules when/if the system boots properly with another kernel, then boot the problematic kernel in single mode (or using init=/bin/bash) and try loading one module at a time. That's how I found the culprit in my case. This is possible when the freeze occurs at each boot. But in my case, it seems to occur completely randomly (I would have thought more often shortly after installing a new kernel, but I'm not sure), and not very often. I've removed the quiet option and rebooted a few times, but the machine didn't freeze. I'll try a few more times. But I wonder whether the freeze can occur without the quiet option (for instance, configuring udev as verbose always resulted in a freeze). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2023140331.gm3...@xvii.vinc17.org
Bug#649033: linux-image-3.1.0-1-amd64: boot sometimes stuck with waiting for /dev to be fully populated.
Package: linux-2.6 Version: 3.1.1-1 Severity: important The boot sometimes freezes with the message: waiting for /dev to be fully populated. There was a bug report against udev (bug #606192), which is closed, suggesting a kernel bug if the timeout doesn't occur, which is the case here (with linux-image-3.1.0-1-amd64 3.1.1-1). http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606192#98 If the boot does not continue then it looks like that udev loaded a module which crashed your system (so this would be a kernel bug). I'm not the only one who has this problem: http://identi.ca/conversation/84449449 Note that even though this problem doesn't occur very often, it can be very problematic if one wants to reboot the machine remotely, as there is no way to redo a reboot. -- Package-specific info: ** Version: Linux version 3.1.0-1-amd64 (Debian 3.1.1-1) (b...@decadent.org.uk) (gcc version 4.6.2 (Debian 4.6.2-4) ) #1 SMP Mon Nov 14 08:02:25 UTC 2011 ** Command line: root=/dev/mapper/xvii-root ro quiet ** Not tainted ** Kernel log: [ 11.653828] [drm] nouveau :01:00.0: 0: memory 100MHz core 169MHz shader 338MHz voltage 900mV fanspeed 100% timing 0 [ 11.653832] [drm] nouveau :01:00.0: 1: memory 250MHz core 275MHz shader 550MHz voltage 900mV fanspeed 100% timing 1 [ 11.653836] [drm] nouveau :01:00.0: 2: memory 400MHz core 500MHz shader 1000MHz voltage 1090mV fanspeed 100% timing 2 [ 11.653840] [drm] nouveau :01:00.0: 3: memory 400MHz core 580MHz shader 1450MHz voltage 1170mV fanspeed 100% timing 3 [ 11.653869] [drm] nouveau :01:00.0: Register 0x4030 not found in PLL limits table [ 11.653982] [drm] nouveau :01:00.0: c: memory 249MHz core 275MHz shader 550MHz voltage 900mV [ 11.656429] [TTM] Zone kernel: Available graphics memory: 2024866 kiB. [ 11.656432] [TTM] Initializing pool allocator. [ 11.656443] [drm] nouveau :01:00.0: Detected 256MiB VRAM [ 11.656449] mtrr: type mismatch for e000,1000 old: write-back new: write-combining [ 11.656474] [drm] nouveau :01:00.0: 512 MiB GART (aperture) [ 11.670404] [drm] nouveau :01:00.0: ACPI backlight interface available, not registering our own [ 11.671776] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 11.671778] [drm] No driver support for vblank timestamp query. [ 11.699932] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs' [ 11.707286] input: DualPoint Stick as /devices/platform/i8042/serio1/input/input9 [ 11.724092] input: AlpsPS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input10 [ 11.877392] [drm] nouveau :01:00.0: allocated 1440x900 fb: 0x31, bo 88011a388400 [ 11.877466] fbcon: nouveaufb (fb0) is primary device [ 11.952017] dell_wmi: Received unknown WMI event (0x11) [ 13.218625] Console: switching to colour frame buffer device 180x56 [ 13.221576] fb0: nouveaufb frame buffer device [ 13.221577] drm: registered panic notifier [ 13.221587] [drm] Initialized nouveau 0.0.16 20090420 for :01:00.0 on minor 0 [ 13.244484] dell_wmi: Received unknown WMI event (0x11) [ 13.383201] snd_hda_intel :00:1b.0: PCI INT A - GSI 21 (level, low) - IRQ 21 [ 13.383266] snd_hda_intel :00:1b.0: irq 47 for MSI/MSI-X [ 13.383297] snd_hda_intel :00:1b.0: setting latency timer to 64 [ 13.493888] input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input11 [ 13.509229] input: HDA Intel Mic at Sep Left Jack as /devices/pci:00/:00:1b.0/sound/card0/input12 [ 13.509324] input: HDA Intel Mic at Ext Right Jack as /devices/pci:00/:00:1b.0/sound/card0/input13 [ 13.509405] input: HDA Intel Line Out at Sep Left Jack as /devices/pci:00/:00:1b.0/sound/card0/input14 [ 13.509485] input: HDA Intel HP Out at Ext Right Jack as /devices/pci:00/:00:1b.0/sound/card0/input15 [ 13.860800] WARNING! power/level is deprecated; use power/control instead [ 13.998220] Linux media interface: v0.10 [ 14.002163] Linux video capture interface: v2.00 [ 14.014492] uvcvideo: Found UVC 1.00 device Laptop_Integrated_Webcam_0.3M (0c45:63f8) [ 14.028812] input: Laptop_Integrated_Webcam_0.3M as /devices/pci:00/:00:1a.7/usb1/1-6/1-6:1.0/input/input16 [ 14.028902] usbcore: registered new interface driver uvcvideo [ 14.028904] USB Video Class driver (1.1.1) [ 14.121270] usb 3-1.3: new full speed USB device number 5 using uhci_hcd [ 14.251270] usb 3-1.3: New USB device found, idVendor=413c, idProduct=8156 [ 14.251274] usb 3-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 14.251278] usb 3-1.3: Product: Dell Wireless 370 Bluetooth Mini-card [ 14.251281] usb 3-1.3: Manufacturer: Dell Computer Corp [ 14.352418] Bluetooth: Core ver 2.16 [ 14.352439] NET: Registered protocol family 31 [ 14.352441] Bluetooth: HCI device and connection manager initialized [ 14.352443] Bluetooth: HCI socket layer initialized [ 14.352445]
Bug#649033: linux-image-3.1.0-1-amd64: boot sometimes stuck with waiting for /dev to be fully populated.
On Thu, Nov 17, 2011 at 01:29:08AM +0100, Vincent Lefevre wrote: Package: linux-2.6 Version: 3.1.1-1 Severity: important The boot sometimes freezes with the message: waiting for /dev to be fully populated. There was a bug report against udev (bug #606192), which is closed, suggesting a kernel bug if the timeout doesn't occur, which is the case here (with linux-image-3.1.0-1-amd64 3.1.1-1). [...] Please start the kernel without 'quiet' (the GRUB 'rescue mode' entries will do this) so the kernel logs more to the console, and send us the resulting messages (a photograph with readable text is fine). Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2017005218.gg3...@decadent.org.uk