+++ This bug was initially created as a clone of Bug #285721 +++

Description of problem:
On hibernate, the following messages are displayed on the console:

tg3 0000:08:04.1: tg3_abort_hw timed out, TX_MODE_ENABLED will not clear MAC_TX_MODE=ffffffff

system will not wake from lan from hibernate

on resume:

tg3 0000:08:04.0: PME# disabled
tg3 0000:08:04.0: eth0: Link is down
tg3 0000:08:04.1: PME# disabled
tg3 0000:08:04.1: eth1: Link is down

and network in non-functional until module is removed and re-added.

Adding tg3 to SUSPEND_MODULES allows the network to work on resume, but also prevents wake on lan.

08:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5715 Gigabit Ethernet (rev a3)
08:04.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5715 Gigabit Ethernet (rev a3)

Version-Release number of selected component (if applicable):
2.6.32-131.2.1.el6.x86_64


From Bug 285721:

When suspending my computer with pm-hibernate --quirk-vbe-post I get this error
message on console (and in dmesg):

tg3: tg3_abort_hw timed out for eth0, TX_MODE_ENABLE will not clear
MAC_TX_MODE=ffffffff

After resume, I have to modprobe -v -r not only my wifi driver (iwl3945) but tg3
as well in order to make wifi to work.

How reproducible:
100%

Steps to Reproduce:
1.suspend/resume cycle
2.
3.
  
Actual results:
error message on console/dmesg and no wireless after resume, have to rmmod both
wifi and Ethernet driver

Expected results:
just works

Additional info:
having
SUSPEND_MODULES="kvm_intel kvm" in /etc/pm/config.d/unload_modules 
(with having iwl3945 there as well didn't help; will try now with both iwl3945
and tg3)

--- Additional comment from mcepl on 2007-09-11 06:06:26 EDT ---

Created attachment 192361 [details]
output of dmesg command

--- Additional comment from pknirsch on 2007-09-11 08:39:09 EDT ---

Hm thats sounds more like the tg3 driver has a problem when you hibernate using
this quirk.

Have you tried hibernating without the quirk? Or doesn't the machine hibernate
properly when you leave it out.

But in general, it's a kernel module spitting out an error message, so i rather
think this is a kernel problem, therefore i'm reassigning it to kernel.

Thanks,

Read ya, Phil

--- Additional comment from mcepl on 2007-09-25 09:47:39 EDT ---

yes, I tried to hibernate with any possible quirks or without them at all and it
makes this message all the time.

--- Additional comment from snecklifter on 2007-10-03 09:19:02 EDT ---

Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

From the 2.6.23-rc3 Changelog:

commit 3e0c95fd648c0d3175b9ff2232597d0b02eb7d46
Author: Michael Chan <mchan>
Date:   Fri Aug 3 20:56:54 2007 -0700

    [TG3]: Fix suspend/resume problem.
    
    Joachim Deguara <joachim.deguara> reported that tg3 devices
    would not resume properly if the device was shutdown before the system
    was suspended.  In such scenario where the netif_running state is 0,
    tg3_suspend() would not save the PCI state and so the memory enable bit
    and bus master enable bit would be lost.
    
    We fix this by always saving and restoring the PCI state in
    tg3_suspend() and tg3_resume() regardless of netif_running() state.
    
    Signed-off-by: Michael Chan <mchan>
    Signed-off-by: David S. Miller <davem>

Matej, can you test with a kernel based off this?

Also, could you clear up whether you are suspend/resuming or hibernate/waking?
You mention suspend/resume but then indicate you are running pm-hibernate. Do
you still see this issue with pm-suspend?

Cheers
Chris

--- Additional comment from mcepl on 2007-10-04 19:47:07 EDT ---

Tried kernel-2.6.23-0.217.rc9.git1.fc8 and the results are no good:

a) iwl3945 driver didn't work with NetworkManager-0.6.5-7.fc7 (it did with
kernel-2.6.22.9-91.fc7), so ifup had to be used.
b) tg3 warning message went away, but after suspend no wireless card whatsoever
(I have the computer at home, so I have no chance to test wired ethernet
function actually), and there were some backtraces in dmesg (see attached).

--- Additional comment from mcepl on 2007-10-04 19:47:32 EDT ---

Created attachment 216801 [details]
output of dmesg

--- Additional comment from mcepl on 2007-10-04 19:49:14 EDT ---

Created attachment 216811 [details]
/var/log/messages

--- Additional comment from snecklifter on 2007-10-05 06:58:04 EDT ---

Matej,

As the original issue with tg3 appears resolved in 2.6.23, I'm changing the
subject to reflect that. It might even be worth filing a new bug for the
wireless but to be honest there is so much work going into NetworkManager and
intel wifi at the moment it will likely get lost in the noise.

I'd suggest your best option would be to test with NetworkManager (again from
development if you can) and see if this helps. In the meantime I'll re-assign to
the wireless team. For brevity here is the backtrace which is related to your
touchpad rather than network driver issues:

=============================================
[ INFO: possible recursive locking detected ]
2.6.23-0.217.rc9.git1.fc8 #1
---------------------------------------------
kseriod/253 is trying to acquire lock:
 (&ps2dev->cmd_mutex){--..}, at: [<c0631cb3>] mutex_lock+0x21/0x24

but task is already holding lock:
 (&ps2dev->cmd_mutex){--..}, at: [<c0631cb3>] mutex_lock+0x21/0x24

other info that might help us debug this:
4 locks held by kseriod/253:
 #0:  (serio_mutex){--..}, at: [<c0631cb3>] mutex_lock+0x21/0x24
 #1:  (&serio->drv_mutex){--..}, at: [<c0631cb3>] mutex_lock+0x21/0x24
 #2:  (psmouse_mutex){--..}, at: [<c0631cb3>] mutex_lock+0x21/0x24
 #3:  (&ps2dev->cmd_mutex){--..}, at: [<c0631cb3>] mutex_lock+0x21/0x24

stack backtrace:
 [<c0406463>] show_trace_log_lvl+0x1a/0x2f
 [<c0406e4d>] show_trace+0x12/0x14
 [<c0406e65>] dump_stack+0x16/0x18
 [<c0449c56>] __lock_acquire+0x189/0xc67
 [<c044abae>] lock_acquire+0x7b/0x9e
 [<c0631ac0>] __mutex_lock_slowpath+0x10a/0x2dc
 [<c0631cb3>] mutex_lock+0x21/0x24
 [<c059bc3f>] ps2_command+0x92/0x30e
 [<c05a23c6>] psmouse_sliced_command+0x1c/0x5a
 [<c05a46eb>] synaptics_pt_write+0x21/0x46
 [<c059ba14>] ps2_sendbyte+0x39/0xcb
 [<c059bcbe>] ps2_command+0x111/0x30e
 [<c05a2001>] psmouse_probe+0x1d/0x6c
 [<c05a314d>] psmouse_connect+0xf8/0x20c
 [<c05993e0>] serio_connect_driver+0x1e/0x2e
 [<c0599406>] serio_driver_probe+0x16/0x18
 [<c05767bd>] driver_probe_device+0xf2/0x173
 [<c0576846>] __device_attach+0x8/0xa
 [<c0575b92>] bus_for_each_drv+0x3c/0x67
 [<c05768dc>] device_attach+0x75/0x8a
 [<c059941c>] serio_find_driver+0x14/0x3c
 [<c0599f59>] serio_thread+0x166/0x2b9
 [<c043e7f7>] kthread+0x3b/0x64
 [<c0405ee3>] kernel_thread_helper+0x7/0x10
 =======================

The logs then indicates the device coming back up and dhclient restarting a few
times before sleeping. NetworkManager fares no better later on it would seem.

--- Additional comment from linville on 2007-10-05 09:02:44 EDT ---

FWIW, it is really bad form to simply hijack a bug for another problem, rename 
it, and expect it to be treated as an extension of the same bug.  It isn't 
clear to me that this is the same issue at all, and having synaptics 
backtraces and tg3 stuff in what now claims to be an iwl3945 bug just creates 
confusion...

--- Additional comment from mcepl on 2007-10-05 09:24:27 EDT ---

Sure, being a bugmaster, I thought that kernel folks have different mores ;-).
No, seriously, should I file a new bug?

--- Additional comment from linville on 2007-10-05 09:35:18 EDT ---

Matej, you weren't the one I was hoping to educate. :-)  Yes, please open a 
new bug.  Restoring the name and assignee of this one (and closing it, if 
appropriate) seems like a good idea too.

--- Additional comment from mcepl on 2007-10-05 15:56:07 EDT ---

OK, so let's close this bug as CLOSED/RAWHIDE, and I will upgrade on Monday my
computer to F8test3 update that to the latest Rawhide, and I will all bugs which
will be eventually found out and you will fix them. Is it a deal? :-)

--- Additional comment from snecklifter on 2007-10-05 16:40:03 EDT ---

(In reply to comment #13)
> FWIW, it is really bad form to simply hijack a bug for another problem, rename 
> it, and expect it to be treated as an extension of the same bug.  It isn't 
> clear to me that this is the same issue at all, and having synaptics 
> backtraces and tg3 stuff in what now claims to be an iwl3945 bug just creates 
> confusion...

I'm no hi-jacker, you must have me confused with someone else. I don't *expect*
it to be treated as an extension, just that the underlying issue may be the same
however the initial tg3 errors were resolved so I felt a change of subject was
appropriate. Its your call to ask the reporter to file a new bug or continue on
this one. Please don't accuse me of hi-jacking - as indicated I am attempting to
triage kernel bugs.

(In reply to comment #16)
> OK, so let's close this bug as CLOSED/RAWHIDE, and I will upgrade on Monday my
> computer to F8test3 update that to the latest Rawhide, and I will all bugs which
> will be eventually found out and you will fix them. Is it a deal? :-)

Deal.

Cheers
Chris

--- Additional comment from mcepl on 2007-10-10 16:11:13 EDT ---

Sorry guys, if I can have my original summary back (I believe many people search
by the error they get in logs), and unfortunately I have to reopen this.

I have upgraded to full Rawhide, so I have now here kernel
2.6.23-0.224.rc9.git6.fc8 and 
NetworkManager-0.7.0-0.3.svn2914.fc8.

Unfortunately, the error message is back.

--- Additional comment from mcepl on 2007-10-10 16:25:57 EDT ---

Created attachment 223371 [details]
/var/log/messages

These are the /var/log/messages contain both suspend/resume cycle and reboot.

After suspend/resume cycle, there is no network (neither wireless nor wired). I
will file a different bug about this.

--- Additional comment from mcepl on 2008-01-14 01:27:05 EST ---

I cannot find in any log any error messages for now. So, lets CLOSE this for
now, and I will reopen it if every needed again.