FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 05-17-2011, 04:51 PM
Gaetan Bisson
 
Default udev-168-2

[2011-05-17 18:23:10 +0200] Tom Gundersen:
> There was a regression in udev-168 where "udevadm settle" would
> sometimes return too early. This lead to some (apparently rare)
> systems being unable to boot, especially people booting from usb
> drives or not having devtmpfs support in their kernels were affected.
>
> udev-168-2 contains the fix packported from upstream git.

Signoff x86_64.

--
Gaetan
 
Old 05-17-2011, 05:26 PM
Thomas Bächler
 
Default udev-168-2

Am 17.05.2011 18:23, schrieb Tom Gundersen:
> Hi guys,
>
> There was a regression in udev-168 where "udevadm settle" would
> sometimes return too early. This lead to some (apparently rare)
> systems being unable to boot, especially people booting from usb
> drives or not having devtmpfs support in their kernels were affected.
>
> udev-168-2 contains the fix packported from upstream git.
>
> Please test and signoff both arches, I hope to push to [core]
> relatively quickly.

And I was wondering why my aic7xxx controller initialized so fast -
turns out nothing was waiting for it to initialize (in this case, I wish
I could restore that behaviour, because it takes ages).

Anyway, signoff x86_64.
 
Old 05-17-2011, 05:31 PM
Thomas Bächler
 
Default udev-168-2

Am 17.05.2011 19:26, schrieb Thomas Bächler:
> Am 17.05.2011 18:23, schrieb Tom Gundersen:
>> Hi guys,
>>
>> There was a regression in udev-168 where "udevadm settle" would
>> sometimes return too early. This lead to some (apparently rare)
>> systems being unable to boot, especially people booting from usb
>> drives or not having devtmpfs support in their kernels were affected.
>>
>> udev-168-2 contains the fix packported from upstream git.
>>
>> Please test and signoff both arches, I hope to push to [core]
>> relatively quickly.
>
> And I was wondering why my aic7xxx controller initialized so fast -
> turns out nothing was waiting for it to initialize (in this case, I wish
> I could restore that behaviour, because it takes ages).
>
> Anyway, signoff x86_64.

And i686, too.
 
Old 05-17-2011, 05:33 PM
Tom Gundersen
 
Default udev-168-2

On Tue, May 17, 2011 at 7:26 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> Am 17.05.2011 18:23, schrieb Tom Gundersen:
>> There was a regression in udev-168 where "udevadm settle" would
>> sometimes return too early. This lead to some (apparently rare)
>> systems being unable to boot, especially people booting from usb
>> drives or not having devtmpfs support in their kernels were affected.
>>
>> udev-168-2 contains the fix packported from upstream git.
>>
>> Please test and signoff both arches, I hope to push to [core]
>> relatively quickly.
>
> And I was wondering why my aic7xxx controller initialized so fast -
> turns out nothing was waiting for it to initialize (in this case, I wish
> I could restore that behaviour, because it takes ages).

UDEV_TIMEOUT=0 restores the bug ;-)

(though I think it is a very bad idea to use this feature, it might
mean you won't have your block devices when you need them...)
 
Old 05-17-2011, 05:35 PM
Tom Gundersen
 
Default udev-168-2

On Tue, May 17, 2011 at 7:31 PM, Thomas Bächler <thomas@archlinux.org> wrote:
> Am 17.05.2011 19:26, schrieb Thomas Bächler:
>> Am 17.05.2011 18:23, schrieb Tom Gundersen:
>>> Hi guys,
>>>
>>> There was a regression in udev-168 where "udevadm settle" would
>>> sometimes return too early. This lead to some (apparently rare)
>>> systems being unable to boot, especially people booting from usb
>>> drives or not having devtmpfs support in their kernels were affected.
>>>
>>> udev-168-2 contains the fix packported from upstream git.
>>>
>>> Please test and signoff both arches, I hope to push to [core]
>>> relatively quickly.
>>
>> And I was wondering why my aic7xxx controller initialized so fast -
>> turns out nothing was waiting for it to initialize (in this case, I wish
>> I could restore that behaviour, because it takes ages).
>>
>> Anyway, signoff x86_64.
>
> And i686, too.
>

Great. Then it can be pushed to core (I have tested on two x86_64
machines and one i686).

Thomas? Ionut?

Cheers,

Tom
 

Thread Tools




All times are GMT. The time now is 02:21 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org