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

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

[Harald Dunkel]

Hi folks,

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.


Regards

Harri

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

[Andrew Morton]

On Tue, 25 May 2010 11:12:30 +0200 Harald Dunkel <harald.dunkel@aixigo.de> wrote:

> Hi folks,
> 
> 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.

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

[Kay Sievers]

On Wed, May 26, 2010 at 03:46, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Tue, 25 May 2010 11:12:30 +0200 Harald Dunkel <harald.dunkel@aixigo.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

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

[Harald Dunkel]

On 05/26/10 10:50, Kay Sievers wrote:
> 
> 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?
> 

I waited for 10 minutes, but there was no additional action.
Its stuck.

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

I am using an initrd. init=/bin/sh did not work; it complained
about a missing boot disk.

To get rid of some autodetected devices I also disabled USB
support in the BIOS, as far as possible. No luck.

> 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
> 

The most recent kernel I tried is 2.6.34. I built it and
installed it on USB. The same USB stick boots fine in other
PCs (e.g. a Dell XPS M1300).

Of course I will keep on trying.


Regards

Harri

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

[Kay Sievers]

On Wed, May 26, 2010 at 15:18, Harald Dunkel <harald.dunkel@aixigo.de> wrote:
> On 05/26/10 10:50, Kay Sievers wrote:
>>
>> 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?
>>
>
> I waited for 10 minutes, but there was no additional action.
> Its stuck.
>
>> Are you using an initramfs? If not, does init=/bin/sh work?
>>
>
> I am using an initrd. init=/bin/sh did not work; it complained
> about a missing boot disk.

Try rdinit=/bin/sh and you should/might get a shell from the initramfs image?

Kay

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

[Harald Dunkel]

Hi Kay,

Sorry for the delay.

It crashes when the "processor" acpi module is loaded.
If I blacklist this module, then the laptop boots fine.

The same problem exists for 2.6.35 and older kernels.

Of course I would be glad to help to track this down.


Regards

Harri

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

[Greg KH]

On Tue, Aug 03, 2010 at 09:02:54AM +0200, Harald Dunkel wrote:
> Hi Kay,
> 
> Sorry for the delay.
> 
> It crashes when the "processor" acpi module is loaded.

Sounds like an ACPI bug.  The ACPI developers use the
bugzilla.kernel.org site to track things like this.  Try filing a bug
there and they can take care of it.

thanks,

greg k-h

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

[Harald Dunkel]

On 08/03/10 17:14, Greg KH wrote:
> 
> Sounds like an ACPI bug.  The ACPI developers use the
> bugzilla.kernel.org site to track things like this.  Try filing a bug
> there and they can take care of it.
> 

Done: https://bugzilla.kernel.org/show_bug.cgi?id=16097


Many thanx

Harri