Bug 785346 - NetworkManager is continuously tearing down and setting up wired connection
Summary: NetworkManager is continuously tearing down and setting up wired connection
Keywords:
Status: CLOSED DUPLICATE of bug 796837
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-28 10:05 UTC by Nicolas Mailhot
Modified: 2012-03-21 08:26 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-21 08:26:42 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dmesg (77.43 KB, text/plain)
2012-01-28 10:06 UTC, Nicolas Mailhot
no flags Details
system logs (868.90 KB, text/plain)
2012-01-28 10:13 UTC, Nicolas Mailhot
no flags Details

Description Nicolas Mailhot 2012-01-28 10:05:33 UTC
Description of problem:

NetworkManager is continuously tearing down and setting up wired connection

The Desktop is bombarded by gnome-shell notifications apps find and lose network
Evo and firefox regularly decide to go offline

Version-Release number of selected component (if applicable):

kernel-3.3.0-0.rc1.git4.1.fc17.x86_64
NetworkManager-0.9.2-4.fc17.x86_64
systemd-39-1.fc17.x86_64

Comment 1 Nicolas Mailhot 2012-01-28 10:06:59 UTC
Created attachment 558024 [details]
dmesg

Comment 2 Nicolas Mailhot 2012-01-28 10:13:19 UTC
Created attachment 558031 [details]
system logs

Comment 3 Jirka Klimes 2012-02-07 16:20:33 UTC
Does setting Method to "Ignore" in IPv6 Settings tab in nm-connection-editor helps?

BTW, there's a kernel problem (seen in dmesg):
  66.250006] [ INFO: possible recursive locking detected ]
[   66.250006] 3.3.0-0.rc1.git4.1.fc17.x86_64 #1 Not tainted
[   66.250006] ---------------------------------------------
[   66.250006] udevd/489 is trying to acquire lock:
[   66.250006]  (&hdl->lock){+.+...}, at: [<ffffffffa02dc7e7>] find_ref_lock+0x27/0x60 [videodev]
[   66.250006] 
...

Comment 4 Nicolas Mailhot 2012-02-08 18:03:07 UTC
(In reply to comment #3)
> Does setting Method to "Ignore" in IPv6 Settings tab in nm-connection-editor
> helps?

Thanks for the suggestion, I will try this
Though networkmanager has been configured like this for ages here, so if it is the cause something regressed in the nm stack

> BTW, there's a kernel problem (seen in dmesg):
>   66.250006] [ INFO: possible recursive locking detected ]
> [   66.250006] 3.3.0-0.rc1.git4.1.fc17.x86_64 #1 Not tainted
> [   66.250006] ---------------------------------------------
> [   66.250006] udevd/489 is trying to acquire lock:
> [   66.250006]  (&hdl->lock){+.+...}, at: [<ffffffffa02dc7e7>]
> find_ref_lock+0x27/0x60 [videodev]
> [   66.250006] 
> ...

the videodev people say this is a false alert, and can't find the time to annotate the kernel properly so it don't complain here

Comment 5 Nicolas Mailhot 2012-02-11 14:06:09 UTC
Maybe that's linked to bug #785772 ?

Comment 6 Nicolas Mailhot 2012-02-11 15:09:11 UTC
(In reply to comment #3)
> Does setting Method to "Ignore" in IPv6 Settings tab in nm-connection-editor
> helps?

This seems to help

I'll continue testing a few days, but disabling ipv6 is not nice

Comment 7 Pavel Šimerda (pavlix) 2012-03-20 20:30:39 UTC
Please look at bug 753482. It describes a similar problem with wireless networks but it turns out the problem is packet loss and fragile Router Advertisement data. Please report if your connection problems are related to that bug.

Comment 8 Jirka Klimes 2012-03-21 08:26:42 UTC

*** This bug has been marked as a duplicate of bug 796837 ***


Note You need to log in before you can comment on or make changes to this bug.