In the meantime, I tried the kernel parameters notsc and clocksource=hpet or acpi_pm (because of the "Clocksource tsc unstable" lines that are appear in the surroundings of the problem.

I also disabled all offload parameters (rx, tx, sg, tso and gso) using ethtool very early in the boot process, unfortunately without success.

The interface still stops to work some seconds after booting. Sometimes I can do some pings after the boot process has finished, but after another few seconds later, it hangs:

64 bytes from apu.domanig.kloburg.at (10.0.0.1): icmp_seq=22 ttl=64 time=0.159 ms
64 bytes from apu.domanig.kloburg.at (10.0.0.1): icmp_seq=23 ttl=64 time=0.159 ms
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available

Interestingly after doing an "rmmod tg3; modprobe tg3", the interface works stable and I can transfer gigabytes of data without problems.

I am having exactly the same problem after upgrading from FC11 to FC13. I am also on a Dell Optiplex 740.

lspci -v | grep Eth
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express (rev 02)

I get some errors but after doing rmmod tg3; modprobe tg3' it works until the next reboot. Unfortunately doing rmmod on tg3 seems to take ~30 seconds. It seems to be waiting for something to time out. In the dmesg log below you can see the errors I got and then the successful eth0 config after doing rmmod/modprobe.

------------------
tg3: tg3_abort_hw timed out for eth0, TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
tg3: eth0: No firmware running.
tg3: eth0: Link is down.
tg3 0000:02:00.0: PME# enabled
pcieport 0000:00:03.0: wake-up capability enabled by ACPI
tg3 0000:02:00.0: PCI INT A disabled
tg3.c:v3.106 (January 12, 2010)
tg3 0000:02:00.0: enabling device (0000 -> 0002)
tg3 0000:02:00.0: PCI INT A -> Link[APC5] -> GSI 16 (level, low) -> IRQ 16
tg3 0000:02:00.0: setting latency timer to 64
pcieport 0000:00:03.0: wake-up capability disabled by ACPI
tg3 0000:02:00.0: PME# disabled
eth0: Tigon3 [partno(BCM95754) rev b002] (PCI Express) MAC address 00:18:8b:7a:e4:2f
eth0: attached PHY is 5787 (10/100/1000Base-T Ethernet) (WireSpeed[1])
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
eth0: dma_rwctrl[76180000] dma_mask[64-bit]
tg3 0000:02:00.0: irq 27 for MSI/MSI-X
ADDRCONF(NETDEV_UP): eth0: link is not ready
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is off for TX and off for RX.
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
eth0: no IPv6 routers present
------------------

Hi, 

I'm also having a problem with the tg3 module after upgrading from fedora 11 to 13. I'm also on a Dell Optiplex 740.


------------[ cut here ]------------
WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0xf5/0x197()
Hardware name: OptiPlex 740
NETDEV WATCHDOG: eth0 (tg3): transmit queue 0 timed out
Modules linked in: sit tunnel4 fuse sunrpc cpufreq_ondemand powernow_k8 freq_table ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 aes_x86_64 aes_generic xts gf128mul dm_crypt uinput snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd edac_core k8temp i2c_nforce2 soundcore edac_mce_amd snd_page_alloc tg3 kaweth serio_raw dcdbas microcode pata_acpi ata_generic sata_nv radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: bonding]
Pid: 0, comm: swapper Not tainted 2.6.34.7-61.fc13.x86_64 #1
Call Trace:
<IRQ>  [<ffffffff8104d14f>] warn_slowpath_common+0x7c/0x94
[<ffffffff8104d1be>] warn_slowpath_fmt+0x41/0x43
[<ffffffff813ba01f>] ? netif_tx_lock+0x44/0x6d
[<ffffffff813ba13d>] dev_watchdog+0xf5/0x197
[<ffffffff8106b24d>] ? sched_clock_local+0x1c/0x82
[<ffffffff8106b376>] ? sched_clock_cpu+0xc3/0xce
[<ffffffff810594d6>] run_timer_softirq+0x1bf/0x263
[<ffffffff8106e3f7>] ? ktime_get+0x65/0xbe
[<ffffffff81053285>] __do_softirq+0xe5/0x1a6
[<ffffffff810726d0>] ? tick_program_event+0x2a/0x2c
[<ffffffff8100ab5c>] call_softirq+0x1c/0x30
[<ffffffff8100c342>] do_softirq+0x46/0x83
[<ffffffff810530f6>] irq_exit+0x3b/0x7d
[<ffffffff814529f0>] smp_apic_timer_interrupt+0x8d/0x9b
[<ffffffff8100a613>] apic_timer_interrupt+0x13/0x20
<EOI>  [<ffffffff8102a615>] ? native_safe_halt+0xb/0xd
[<ffffffff81011659>] default_idle+0x36/0x53
[<ffffffff81011771>] c1e_idle+0xfb/0x102
[<ffffffff81008c22>] cpu_idle+0xaa/0xe4
[<ffffffff81445976>] start_secondary+0x253/0x294
---[ end trace 79692f0fb307c5eb ]---
tg3 0000:02:00.0: eth0: transmit timed out, resetting
tg3 0000:02:00.0: eth0: DEBUG: MAC_TX_STATUS[ffffffff] MAC_RX_STATUS[ffffffff]
tg3 0000:02:00.0: eth0: DEBUG: RDMAC_STATUS[ffffffff] WDMAC_STATUS[ffffffff]
tg3_stop_block timed out, ofs=2c00 enable_bit=2
tg3_stop_block timed out, ofs=2000 enable_bit=2
tg3_stop_block timed out, ofs=2400 enable_bit=2
tg3_stop_block timed out, ofs=2800 enable_bit=2
tg3_stop_block timed out, ofs=3000 enable_bit=2
tg3_stop_block timed out, ofs=1400 enable_bit=2
tg3_stop_block timed out, ofs=1800 enable_bit=2
tg3_stop_block timed out, ofs=c00 enable_bit=2
tg3_stop_block timed out, ofs=4800 enable_bit=2
tg3_stop_block timed out, ofs=1000 enable_bit=2
tg3_stop_block timed out, ofs=1c00 enable_bit=2
tg3 0000:02:00.0: eth0: tg3_abort_hw timed out, TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
tg3_stop_block timed out, ofs=3c00 enable_bit=2
tg3_stop_block timed out, ofs=4c00 enable_bit=2
tg3 0000:02:00.0: eth0: No firmware running
tg3 0000:02:00.0: eth0: tg3_abort_hw timed out, TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
tg3 0000:02:00.0: eth0: Link is down

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This is still and issue for me in FC13. Have not tried FC14 yet. I cannot modify the version field for this bug.

I can confirm this is still a problem with F13.

also happens on F14, 2.6.35.12-88.fc14.i686.PAE.

OTOH, I have somewhere around 50 identical machines (all the way down to the
hardware revision on the BCM5754 card):

02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express (rev 02)

and only see this issue popping up on two of them. I'd call it a broken hardware issue, if only rmmod/modprobe wouldn't get it working again... Weird...

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

continues happening on F14, x86_64, kernel 2.6.35.13-92.fc14.x86_64

Haven't had a chance to test in F15 yet, but can we please keep this open for now ?

Thanks,
--G

I think i am experiencing exactly the same issue on F13 and F15 :
https://bugzilla.redhat.com/show_bug.cgi?id=552288

F13 : Sometimes system will freeze on boot / Sometimes system crash after 3 weeks. (Broadcom BCM5721 & BCM5722 NIC)

F15 : System will freeze on boot when reaching NIC modules loading in most case.

How to get this fixed ?

Sorry my fault, not the same issue, only tg3 related.

continues happening on F15, x86, kernel 2.6.38.8-35.fc15.i686.PAE (hp 6730b). Sometimes works great, but sametimes after wake-up dmesg shows:

tg3 0000:85:00.0: irq 51 for MSI/MSI-X
tg3 0000:85:00.0: eth0: No firmware running

I haven't seen this happen with F16 (kernels 3.2.* and 3.3.*), in quite a while.

The same (still) in F17 on kernel 3.3.7

tg3: 0000:85:88.8 tg3_abort_hw timed out, TX_MODE_ENABLE will not clear MAC_TX_MODE=ffffffff
tg3 0000:85:00.0: eth0: No firmware running

I must do rmmod and modprobe and work fine. It happens after turn on WIFI, and then susspend and wake-up notbook or after using GSM modem with physically disconnected lan.

This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping