10ec:8168 wired internet regression in 2.6.35-25-generic r8169

From your BootDmesg.txt file it seems to be working:

[ 35.273764] r8169 0000:02:00.0: eth0: link up
[ 35.273773] r8169 0000:02:00.0: eth0: link up

Well it might partially work, ie device become active, but I can't connect to the internet with it, and I can when I boot into the previous kernel.
When I look at the Network History in the System Monitor it seems to send and receive a couple of k but thats about all.
Do you want to me to grab a packet capture for the good and bad kernels, I have a feeling the bad one doesn't make it through getting a DHCP lease.
Is there anything else I could/should be investigating ?

Looking at WifiSyslog.txt I also found the following (the 1st column is the line number):

 3127 Feb 1 22:08:51 ICE-BOX dhclient: Internet Systems Consortium DHCP Client V3.1.3
 3128 Feb 1 22:08:51 ICE-BOX dhclient: Copyright 2004-2009 Internet Systems Consortium.
 3129 Feb 1 22:08:51 ICE-BOX dhclient: All rights reserved.
 3130 Feb 1 22:08:51 ICE-BOX dhclient: For info, please visit https://www.isc.org/software/dhcp/
 3131 Feb 1 22:08:51 ICE-BOX dhclient:
 3132 Feb 1 22:08:51 ICE-BOX dhclient: Listening on LPF/br0/00:1f:d0:a1:04:04
 3133 Feb 1 22:08:51 ICE-BOX dhclient: Sending on LPF/br0/00:1f:d0:a1:04:04
 3134 Feb 1 22:08:51 ICE-BOX dhclient: Sending on Socket/fallback
 3135 Feb 1 22:08:51 ICE-BOX dhclient: DHCPDISCOVER on br0 to 255.255.255.255 port 67 interval 3
 3136 Feb 1 22:08:52 ICE-BOX dhclient: DHCPOFFER of 192.168.2.3 from 192.168.2.1
 3137 Feb 1 22:08:52 ICE-BOX dhclient: DHCPREQUEST of 192.168.2.3 on br0 to 255.255.255.255 port 67
 3138 Feb 1 22:08:52 ICE-BOX dhclient: DHCPACK of 192.168.2.3 from 192.168.2.1
 3139 Feb 1 22:08:53 ICE-BOX kernel: [ 18.457517] eth0: no IPv6 routers present
 3140 Feb 1 22:08:53 ICE-BOX kernel: [ 18.640006] br0: no IPv6 routers present
 3141 Feb 1 22:08:53 ICE-BOX dhclient: bound to 192.168.2.3 -- renewal in 850925114 seconds.

Perhaps following the debugging procedures at https://wiki.ubuntu.com/DebuggingNetworkManager would help - but I'm not positive. A packet trace would of course be the most informative.

 /dev/br0 is my phone which is DHCP'ing there I think.
I had my phone plugged in acting as a wireless modem so I could connect to the Internet and submit this bug report.
I guess I should not of plugged it in until the bug reporting software had finished gathering the logs.
I'll have a look with wireshark to see if anything gets sent from eth0 when I reload the r8169 module and restart NetworkManager. (Without the phone)
Yell out if you want me to take a second batch of logs, without my phone polluting them this time.

OK I used wireshark to capture some logs from the pseudo device that monitors all network activity.
The logs are of an ifup after an ifdown, and a modprobe r8169, start network-manager after a stop network-manager, modprobe -r r8169, for both the working and the non-working cases.

Thanks for getting the packet traces.

I also tried out the Natty Natwhal alpha 2 as a boot CD and wired networking seemed to work fine.
So from my side I'm not too worried, I can just use the previous kernel for a couple of months then upgrade to Natty.

Darren, thank you for reporting this and helping make Ubuntu better. Maverick reached EOL on April 10, 2012.
Please see this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We were wondering if this is still an issue in a supported release? If so, can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command in a supported release from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. As well, please comment on which kernel version specifically you tested.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream', and comment as to why specifically you were unable to test it.

Please let us know your results. Thanks in advance.

Helpful Bug Reporting Links:
https://help.ubuntu.com/community/ReportingBugs#Bug_Reporting_Etiquette
https://help.ubuntu.com/community/ReportingBugs#A3._Make_sure_the_bug_hasn.27t_already_been_reported
https://help.ubuntu.com/community/ReportingBugs#Adding_Apport_Debug_Information_to_an_Existing_Launchpad_Bug
https://help.ubuntu.com/community/ReportingBugs#Adding_Additional_Attachments_to_an_Existing_Launchpad_Bug

This was fixed when I upgraded to Natty Natwhal.
At the time I investegated a little more and found I could resolve the problem by reverting a networking configuration change that I had added to work around a previous bug.
It was strange (and annoying at the time) that the non-standard configuration broke with the update, but it was probably not a kernel bug.