linux-kernel - Re: 2.6.34 on Samsung P460: reset after "Waiting for /dev to be fully populated"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 May 2010 10:50:42 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Harald Dunkel <harald.dunkel@...igo.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg KH <greg@...ah.com>
Subject: Re: 2.6.34 on Samsung P460: reset after "Waiting for /dev to be fully 
	populated"

On Wed, May 26, 2010 at 03:46, Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Tue, 25 May 2010 11:12:30 +0200 Harald Dunkel <harald.dunkel@...igo.de> wrote:
>> Problem: At boot time I see a final message
>>
>>       Waiting for /dev to be fully populated
>>
>> then my laptop (Samsung P460) does a reset. The next
>> boot doesn't work, so I have to power-cycle the laptop.
>>
>> If I boot with "acpi=off", then 2.6.34 gets stuck instead.
>> The last 2 lines are
>>
>>       TCP reno registered
>>       Net: Registered protocol family 1
>>
>> Any helpful comment would be highly appreciated.
>
> ow, hard.
>
> I assume that the "Waiting for /dev to be fully populated" comes from
> udev?  Greg, do you know what might trigger that?
>
> Harald, I think the best (only?) way to fix this is for you to do a
> bisection search.  http://landley.net/writing/git-quick.html has some
> instructions.
>
> It's a bit of a pain to do, sorry.

A behavior like this is usually a kernel module that gets loaded which
hangs the box. The message comes from distro specific stuff, and not
from udev itself, so we can't know what exactly it is doing.

Did you wait for 3 minutes at least to let the boot processes run into
their timeouts?

Are you using an initramfs? If not, does init=/bin/sh work?

For current -git kernels it could be the FIONREAD bug, which breaks
all sorts of services using inotify. They all hang in a loop, it's not
only udevd:
  http://lkml.org/lkml/2010/5/23/100

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/