gnewsense-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnewsense-dev] Re: 2.6.32-libre-lemote vs NetworkManager (race conditio


From: Daniel Clark
Subject: [Gnewsense-dev] Re: 2.6.32-libre-lemote vs NetworkManager (race condition?)
Date: Mon, 14 Dec 2009 21:21:02 -0500
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

Wu Zhangjin wrote:
> On Mon, 2009-12-14 at 11:23 -0500, Daniel Clark wrote:
>> Alexandre Oliva wrote:
>>> I've been experiencing loss of wired networking with NetworkManager
>>> since I started using 2.6.32-libre-lemote, that don't seem to ever occur
>>> with 2.6.31.7-libre2-lemote.
>>>
>>> My setup uses a DHCP-configured wired network interface, with the WiFi
>>> module blacklisted.
>>>
>>> The network is always brought up early in the boot, and remains on for
>>> at least 45 seconds, but quite often NetworkManager decides that dhcp
>>> took too long (>45 seconds) to complete and reverts to a local IP
>>> address, 169.254.some.thing IIRC.  It doesn't seem to recover from that
>>> by itself; resetting the network connection after logging in as a
>>> desktop user works; unplugging the cable and plugging it back it, or
>>> restarting network-manager fix the problem, but sometimes only
>>> temporarily, for another 45 seconds.
>>>
>>> It appears to be some race condition involving dbus, dhcbdb and the
>>> dbus-send notification in /etc/dhcp3/dhclient-exit-hooks.d/dhcdbd, but
>>> it's hard to tell for sure.  If I strace the system dbus-daemon and/or
>>> dhcbdb and then restart network-manager, the connection goes dead after
>>> another 45 seconds.  If I don't strace anything, or if I strace -f
>>> dhcbdb, sometimes it survives, sometimes it dies in the same way.
>>>
>>> I have strace logs that worked and failed, and AFAICT the dbus-send
>>> notification issued by dhclient-exit-hooks.d/dhcdbd doesn't get to
>>> dhcdbd on traces in which the connection dies, whereas it does when it
>>> survives.  I'm guessing (from the little I know about dbus) that the
>>> race has to do with dhcdbd registering with dbus-daemon to receive
>>> messages from dhcdbd, but that's just a guess: I don't really know how
>>> dbus decides whom to relay messages to.
>>>
>>> Is anyone else experiencing this?  Anyone familiar with dbus and
>>> dhclient willing to offer a more informed guess as to where the problem
>>> might be?
>>>
>>> Thanks in advance,
>> Sorry I have no specific help to offer for this at this time, but I am
>> starting to think that the WPA not working under 2.6.31.6 is also a
>> timing problem - see https://savannah.nongnu.org/bugs/?28289 "gNewSense
>> GNU/Linux - Bugs: WPA doesn't work on yeeloong under 2.6.31.6-libre1 linux"
>>
>> Has anyone had WPA work under 2.6.31.6 or later on the yeeloong?
>>
>> Any workarounds you had to employ (other than dealing with the rfkill
>> stuff)?
>>
> 
> Hi, Just tested the WPA under 2.6.32 with a TP-Links router, works well.
> It's time to use 2.6.32?
> 
> Best Regards,
>       Wu Zhangjin

Good to know. I will try 2.6.32 as soon as possible. If you could put
your 2.6.32 source tree / binaries somewhere it would be good to have as
a reference "known good" sanity check. I can give you server space
somewhere if you don't have some easily available.

Thanks,
-- 
Daniel JB Clark   | Sys Admin, Free Software Foundation
pobox.com/~dclark | http://www.fsf.org/about/staff#danny





reply via email to

[Prev in Thread] Current Thread [Next in Thread]