Bugzilla – Bug 159136
Broadcom NIC (tg3): losing carrier detect on suspend cycle
Last modified: 2007-03-12 12:48:18 UTC
While testing suspend-to-ram on GNOME and KDE on the FSC Stylistic ST502x I registered that after resume there is no network connection. No hostname, no IP, no NIS/automount ... suspend-to-disk is not effected. Not complete sure what the cause of this bug is, but IMO the networkmanager is a good starting point. If I use traditional ifup network all work perfect. @thoenig: could you check this bug and if necessary reassign to the correct person (rlove?).
I've seen something similar with my Dell D600 having no network connection after resume. As Powersave sends the sleep/wake signals it might turn out not to be a NM problem. I'll take care.
By thw way, I've seen this with STD rather than STR which unfortunately does not work on my system any longer. Hi, Seife ;-)
Could not reproduce a second time. Danny, please attach /var/log/NetworkManager.
There is a possible fix for this in the latest NM builds. So if you have only reproduced in the past, please retry with current build from STABLE!
Created attachment 73732 [details] log from /var/log/NetworkManager after suspend2ram
(In reply to comment #4) > There is a possible fix for this in the latest NM builds. So if you have only > reproduced in the past, please retry with current build from STABLE! I tried this with 0.6.1-5 and the problem is still present.
Danny's system (Broadcom NIC, tg3) is loosing the link beat. Please follow Seife's instructions from IRC and -- if applicable -- assign to the kernel guys.
Whoops, I didn't mean to change the priority. Reverting.
Yes this look like a kernel bug in the tg3 module after s2ram. This happens also with init=/bin/bash as I could see on the machine. Reassign to kernel. Btw. I think this is a blocker bug, but I set this to critical. @aj could you check the severity?
this is not a blocker.
Comment on attachment 73732 [details] log from /var/log/NetworkManager after suspend2ram text/plain is text/plain is text/plain is text/plain and NOT application/octet-stream :-)
Please set the NIC's debug level to 65535 shortly before suspending (using ethtool -s eth0 msglvl 65535), then suspend, resume and attach dmesg output to this bug. Thanks! Karsten, would you take this one, please?
Karsten, please look at today's thread on netdev with subject "tg3 breakage this morning" - it seems one of the power mgmt related patches that went into tg3 recently was bad. Maybe it would help to back out one or more of these: > [TG3]: Bump driver version and reldate. > [TG3]: Skip phy power down on some devices > [TG3]: Fix SRAM access during tg3_init_one() > [TG3]: Don't mark tg3_test_registers() as returning ... > [TG3]: make drivers/net/tg3.c:tg3_request_irq() static > [TG3]: netif_carrier_off runs too early; could still .. Specifically one poster mentioned that the "Skip phy power down" patch was negatively affecting his machine.
(In reply to comment #13) > (From update of attachment 73732 [details] [edit]) > text/plain is text/plain is text/plain is text/plain and NOT > application/octet-stream :-) File a bug against bugzilla automatic detection if this is a problem for you
*** Bug 160507 has been marked as a duplicate of this bug. ***
Which kernel on which arch do you use (e.g. kernel-default on i386) ?
OK some other basic informations about the hardware are missing, at least lspci -vn for the networkcontroller. regarding comment #15: These patches are not in our kernel yet, they were for 2.6.17. But maybe (depend on the exact HW) [TG3]: Fix SRAM access during tg3_init_one() maybe a candidate to fix this issue.
Created attachment 75017 [details] output of lspci -vn
please answer also comment 18.
Also reporting this issue is beta customer Luke Watson (SR 10254046167).
Danny? Anyway, I've got another system with tg3 suffering from this bug. Comment #18: kernel-default-2.6.16-7 Comment #19: 06:06.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5788 Gigabit Ethernet (rev 03) 06:06.0 Class 0200: 14e4:169c (rev 03) Subsystem: 1025:0067 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 177 Memory at b0100000 (32-bit, non-prefetchable) [size=64K] Capabilities: [48] Power Management version 2 Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable-
Created attachment 75529 [details] dmesg of STR cycle with msglvl 0xffff
Adjusting summary.
There hasn't been any progress on this bug for a couple of weeks -> what's the status?
Beta Customer Dan Elder also having trouble. Adding his comments. Please advise if this does not appear to be a duplicate of this bug. Dan can collect logs or any other info needed: With rc1 when I resumed from a suspend on an x86_64 laptop using ndiswrapper for a Broadcom card, NetworkManager correctly identified which network to automatically join and listed other available networks in nm-applet but would not automatically join the correct network (GOAWAY). nm-applet showed that it was in stage 1 of joining (the 3 bar progress bar had no bars filled in) and said that it was waiting for the wireless key for the network. There wasn't any dialog box present asking for the key though and it already had they key from previous connections. After waiting several minutes I cliked on nm-applet and manually chose the network to join from the list of available networks and it successfully joined up without any other intervention.
(In reply to comment #27) > Beta Customer Dan Elder also having trouble. Adding his comments. Please > advise if this does not appear to be a duplicate of this bug. Dan can collect > logs or any other info needed: > > With rc1 when I resumed from a suspend on an x86_64 laptop using ndiswrapper > for a Broadcom card, NetworkManager correctly identified which network to This is a different bug, since tg3 is for wired networks. Please file a bug for the NM/ndiswrapper/suspend problem, it might be a problem in the interaction of powersaved / module unloading / NM.
this is also reported on the suspend-devel list and other mailing lists. This will also hurt us in SLED10. Will we do anything about it?
argh! my bad, nobody can read it if it is SLED :-(
I also have a system affected from this bug. Shuttle XPC SD11G5 with Broadcom BCM5789 Gigabit Ethernet controller. Suspend-to-Disk and Standby works, but with suspend-to-ram, there is no network connection after resume. Write me, if you need some logfiles
*** Bug 178280 has been marked as a duplicate of this bug. ***
Is there anyone on this bug that can reproduce the problem that has the ability to test kernel patches out to see if we can fix the issue or not?
at least Danny has a D600 that shows this problem. He will probably not be back in the office before Monday.
To #33: Feel free to contact me. My testmachine stays for another week.
suspend to ram isn't "critical"
Will have a look at this.
I have build 2 test kernel, please try these,they are available (after sync) from: ftp://ftp.suse.com/pub/people/kkeil/testing/code10/[i586|x86_64] kernel-[default|smp]-2.6.16.18-3.<arch>.rpm with a resume patch kernel-[default|smp]-2.6.16.18-tg3_3.58.<arch>.rpm version 3.58 from 2.6.17
As I have the same problem here on an Acer TravelMate C300 I tested the two kernel from above, and they don't change anything, at least here with my problem. After the suspend you aren't able to activate the network card. Even rmmod/modprobe of the tg3 driver doesn't help. This problem occurs here with the final version of SL 10.1 not Beta 8 as stated in the header. This was working fine on my machine with SL 10.0, and it only affects STR not STD as said by Danny in the description.
*** Bug 183225 has been marked as a duplicate of this bug. ***
In my case, I don't have a network connection after a suspend-to-disk. Should this be a new bug or is it in the scope of this one? My network card is on an nForce (1st generation).
Patrick, please open a new bug for that issue. Please add me to CC of the new bug as I would have some questions for investigating your problem.
Timo, I opened bug 184660.
*** Bug 195102 has been marked as a duplicate of this bug. ***
Seems to be fixed with 10.2 RC1 on my system here. Maybe Danny can verify on his DELL...
*** Bug 222820 has been marked as a duplicate of this bug. ***
Can you please retest with a current SP1 beta kernel, it contains the lastest driver from broadcom which has some changes in this area.
I don't have access the the laptop where the broadcom nic was installed anymore so I can't really help you with the test on this bug, sorry.
Tested with actual SP1 kernel from next-sle10-sp-i386 and it work now for SP1.
So it's fixed for future releases according last comment.