[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4A35431A.50507@lammerts.org>
Date: Sun, 14 Jun 2009 14:36:10 -0400
From: Eric Lammerts <eric@...merts.org>
To: Hugh Dickins <hugh.dickins@...cali.co.uk>
Cc: kernel list <linux-kernel@...r.kernel.org>, gregkh@...e.de,
netdev@...r.kernel.org
Subject: Re: 2.6.30: tun losing ip
On 06/14/2009 05:28 AM, Hugh Dickins wrote:
> On Sun, 14 Jun 2009, Eric Lammerts wrote:
>> There is something strange going on with tun devices:
<snip>
>> First you see the ip, then you don't...
>>
>> I traced it back to this commit:
>>
>> $ git-bisect bad
>> 05f54c13cd0c33694eec39a265475c5d6cf223cf is first bad commit
>> commit 05f54c13cd0c33694eec39a265475c5d6cf223cf
>> Author: Hugh Dickins <hugh@...itas.com>
>> Date: Thu Apr 16 21:55:29 2009 +0100
>>
>> Revert "kobject: don't block for each kobject_uevent".
>>
>> If I take 2.6.30 and revert that commit, the problem goes away.
>
> I'm mortified! But it's rather odd, that's just a straight reversion
> of an earlier, clearly buggy commit: I guess you have some other issue,
> which reverting to a wait here now uncovers.
>
> One likely workaround: I suspect your .config says something like
> CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug, but you've no /sbin/hotplug?
> Please try changing that to CONFIG_UEVENT_HELPER_PATH="", and see if
> the problem comes up with that resulting kernel.
Actually I do have an /sbin/hotplug, with I now noticed has some old
script stuff behind it that starts a udhcpc... aarrrgh. I removed it and
the problem's gone.
Apologies for wasting your time.
Eric
--
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/
Powered by blists - more mailing lists