netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* RE: Mystery packet killing tg3
@ 2005-05-04  6:27 Michael Chan
  2005-05-04 22:51 ` Stephen Hemminger
  0 siblings, 1 reply; 35+ messages in thread
From: Michael Chan @ 2005-05-04  6:27 UTC (permalink / raw)
  To: Stephen Hemminger, David S. Miller; +Cc: jgarzik, netdev

Stephen Hemminger wrote:

> Initially, it reproduced everytime link came up, we 
> reconfigured the VLAN to
> have a mirror port into a laptop to try and capture what was 
> happening, but when
> we did that the bootup problem went away. It was in the tg3_reset_hw
> during initial dev_open.
> 

During initial dev_open, the TG3_FLAG_INIT_COMPLETE flag is not set so
tg3_reset_hw() should not call tg3_abort_hw() where the stop_block calls are
made. So there should be no stop_block errors.

I think stop_block errors can only happen during dev_close, suspend, netdev
watchdog, or ethtool "set" calls.

^ permalink raw reply	[flat|nested] 35+ messages in thread
* RE: Mystery packet killing tg3
@ 2005-05-04  6:09 Michael Chan
  0 siblings, 0 replies; 35+ messages in thread
From: Michael Chan @ 2005-05-04  6:09 UTC (permalink / raw)
  To: David S. Miller; +Cc: shemminger, jgarzik, netdev

David S. Miller wrote:

> I can't think of what else could be wedging the tg3.  
> Michael, any ideas?  There are some 5703 specific programming 
> to consider:
> 
The 5703 related settings in tg3 seem ok to me too.

If Stephen says the stop_block error happens during normal ifdown and traffic
was otherwise working fine before ifdown, then I think it may not even be a
problem at all.

Stopping the various state machines can be tricky and I'm not at all
surprised that some state machines can fail to stop in some cases. They are
all interconnected and even if you follow the stopping sequence in the
programmer's reference manual, you may still end up with a situation where
one state machine is waiting for another that has been stopped already. This
is not a problem as tg3_stop_block() calls are always followed by a global
chip reset that will clean up the whole chip. The purpose of tg3_stop_block()
is to quiesce the chip and complete all DMA transactions before abruptly
resetting the chip. If the DMA blocks would not stop, then it would be a
bigger problem.

Other tg3_stop_block() errors that I've seen, such as the ones reported by
John Linville, were preceded by netdev watchdog timeouts. These netdev
watchdog timeouts were real problems that needed to be solved.

^ permalink raw reply	[flat|nested] 35+ messages in thread
* Mystery packet killing tg3
@ 2005-05-02 23:24 Stephen Hemminger
  2005-05-03  3:02 ` David S. Miller
  0 siblings, 1 reply; 35+ messages in thread
From: Stephen Hemminger @ 2005-05-02 23:24 UTC (permalink / raw)
  To: David S. Miller, Jeff Garzik; +Cc: netdev

While I was on vacation, OSDL did some networking changes that seems to aggravate some
existing bug in the tg3 driver. Could be some VLAN related garbage, not sure.

System is 2 CPU AMD64 and the tg3 is on the motherboard.

I am seeing messages like:
 eth0: Tigon3 [partno(BCM95703A30) rev 1002 PHY(5703)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:0d:60:53:08:18
 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] Split[0] WireSpeed[1] TSOcap[0] 
 tg3: tg3_stop_block timed out, ofs=4000 enable_bit=2

Any clues?

^ permalink raw reply	[flat|nested] 35+ messages in thread

end of thread, other threads:[~2005-05-05 21:42 UTC | newest]

Thread overview: 35+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-05-04  6:27 Mystery packet killing tg3 Michael Chan
2005-05-04 22:51 ` Stephen Hemminger
2005-05-04 22:30   ` Michael Chan
     [not found]     ` <20050505113356.0f1b4c00.davem@davemloft.net>
2005-05-05 19:56       ` Michael Chan
2005-05-05 21:42         ` David S. Miller
  -- strict thread matches above, loose matches on Subject: below --
2005-05-04  6:09 Michael Chan
2005-05-02 23:24 Stephen Hemminger
2005-05-03  3:02 ` David S. Miller
2005-05-03 21:05   ` Stephen Hemminger
2005-05-03 21:13     ` David S. Miller
2005-05-03 20:41       ` Michael Chan
2005-05-03 22:03         ` David S. Miller
2005-05-03 21:28           ` Michael Chan
2005-05-03 22:53             ` David S. Miller
2005-05-03 22:45           ` Stephen Hemminger
2005-05-03 22:39             ` David S. Miller
2005-05-03 22:59               ` Stephen Hemminger
2005-05-03 21:29       ` Stephen Hemminger
2005-05-04 18:30   ` Andi Kleen
2005-05-04 18:44     ` Peter Buckingham
2005-05-05 11:43       ` Andi Kleen
2005-05-05 16:20         ` Stephen Hemminger
2005-05-05 18:01           ` Andi Kleen
2005-05-05 17:09         ` Peter Buckingham
2005-05-05 17:32           ` Rick Jones
2005-05-05 17:38             ` Peter Buckingham
2005-05-05 17:45             ` John Heffner
2005-05-05 18:06           ` Andi Kleen
2005-05-05 18:21             ` Peter Buckingham
2005-05-05 18:31               ` Andi Kleen
2005-05-05 18:40                 ` Peter Buckingham
2005-05-05 18:56                   ` Andi Kleen
2005-05-05 19:02                     ` Peter Buckingham
2005-05-05 19:24                       ` Andi Kleen
2005-05-04 19:41     ` Stephen Hemminger

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).