Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
大约 1 年 前同步成功

通知 155
Star 36
Fork 7
cloud-kernel
cloud-kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 12 7月, 2007 1 次提交
  3. 10 5月, 2007 1 次提交
    • A
      tg3: use flush_work_keventd() · 2b3cb2e7
      由 Andrew Morton 提交于 
      Convert tg3 over to flush_work_keventd().  Remove nasty now-unneeded deadlock
avoidance logic.

(akpm: bypassed maintainers, sorry.  There are other patches which depend on
this)

Cc: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: David Howells <dhowells@redhat.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Michael Chan <mchan@broadcom.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2b3cb2e7
  5. 07 5月, 2007 1 次提交
  7. 06 5月, 2007 4 次提交
  9. 26 3月, 2007 2 次提交
    • M
      [TG3]: Exit irq handler during chip reset. · d18edcb2
      由 Michael Chan 提交于 
      On most tg3 chips, the memory enable bit in the PCI command register
gets cleared during chip reset and must be restored before accessing
PCI registers using memory cycles.  The chip does not generate
interrupt during chip reset, but the irq handler can still be called
because of irq sharing or irqpoll.  Reading a register in the irq
handler can cause a master abort in this scenario and may result in a
crash on some architectures.

Use the TG3_FLAG_CHIP_RESETTING flag to tell the irq handler to exit
without touching any registers.  The checking of the flag is in the
"slow" path of the irq handler and will not affect normal performance.
The msi handler is not shared and therefore does not require checking
the flag.

Thanks to Bernhard Walle <bwalle@suse.de> for reporting the problem.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d18edcb2
    • M
      [TG3]: Eliminate the unused TG3_FLAG_SPLIT_MODE flag. · 1c46ae05
      由 Michael Chan 提交于 
      This flag to support multiple PCIX split completions was never used
because of hardware bugs.  This will make room for a new flag.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1c46ae05
  11. 27 2月, 2007 1 次提交
    • M
      [TG3]: TSO workaround fixes. · 7f62ad5d
      由 Michael Chan 提交于 
      1.  Add race condition check after netif_stop_queue().  tg3_tx() runs
    without netif_tx_lock and can race with tg3_start_xmit_dma_bug() ->
    tg3_tso_bug().

2.  Firmware TSO in 5703/5704/5705 also have the same TSO limitation,
    i.e. they cannot handle TSO headers bigger than 80 bytes.  Rename
    TG3_FL2_HW_TSO_1_BUG to TG3_FL2_TSO_BUG and set this flag on
    these chips as well.

3.  Update version to 3.74.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7f62ad5d
  13. 14 2月, 2007 1 次提交
  15. 09 1月, 2007 1 次提交
  17. 18 12月, 2006 1 次提交
  19. 07 12月, 2006 1 次提交
  21. 29 9月, 2006 6 次提交
  23. 08 8月, 2006 1 次提交
    • M
      [TG3]: Fix tx race condition · 1b2a7205
      由 Michael Chan 提交于 
      Fix a subtle race condition between tg3_start_xmit() and tg3_tx()
discovered by Herbert Xu <herbert@gondor.apana.org.au>:

CPU0					CPU1
tg3_start_xmit()
	if (tx_ring_full) {
		tx_lock
					tg3_tx()
						if (!netif_queue_stopped)
		netif_stop_queue()
		if (!tx_ring_full)
						update_tx_ring 
			netif_wake_queue()
		tx_unlock
	}

Even though tx_ring is updated before the if statement in tg3_tx() in
program order, it can be re-ordered by the CPU as shown above.  This
scenario can cause the tx queue to be stopped forever if tg3_tx() has
just freed up the entire tx_ring.  The possibility of this happening
should be very rare though.

The following changes are made:

1. Add memory barrier to fix the above race condition.

2. Eliminate the private tx_lock altogether and rely solely on
netif_tx_lock.  This eliminates one spinlock in tg3_start_xmit()
when the ring is full.

3. Because of 2, use netif_tx_lock in tg3_tx() before calling
netif_wake_queue().

4. Change TX_BUFFS_AVAIL to an inline function with a memory barrier.
Herbert and David suggested using the memory barrier instead of
volatile.

5. Check for the full wake queue condition before getting
netif_tx_lock in tg3_tx().  This reduces the number of unnecessary
spinlocks when the tx ring is full in a steady-state condition.

6. Update version to 3.65.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b2a7205
  25. 01 7月, 2006 3 次提交
  27. 18 6月, 2006 2 次提交
    • M
      [TG3]: Convert to non-LLTX · 00b70504
      由 Michael Chan 提交于 
      Herbert Xu pointed out that it is unsafe to call netif_tx_disable()
from LLTX drivers because it uses dev->xmit_lock to synchronize
whereas LLTX drivers use private locks.

Convert tg3 to non-LLTX to fix this issue. tg3 is a lockless driver
where hard_start_xmit and tx completion handling can run concurrently
under normal conditions. A tx_lock is only needed to prevent
netif_stop_queue and netif_wake_queue race condtions when the queue
is full.

So whether we use LLTX or non-LLTX, it makes practically no
difference.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      00b70504
    • M
      [TG3]: Add recovery logic when MMIOs are re-ordered · df3e6548
      由 Michael Chan 提交于 
      Add recovery logic when we suspect that the system is re-ordering
MMIOs. Re-ordered MMIOs to the send mailbox can cause bogus tx
completions and hit BUG_ON() in the tx completion path.

tg3 already has logic to handle re-ordered MMIOs by flushing the MMIOs
that must be strictly ordered (such as the send mailbox).  Determining
when to enable the flush is currently a manual process of adding known
chipsets to a list.

The new code replaces the BUG_ON() in the tx completion path with the
call to tg3_tx_recover(). It will set the TG3_FLAG_MBOX_WRITE_REORDER
flag and reset the chip later in the workqueue to recover and start
flushing MMIOs to the mailbox.

A message to report the problem will be printed. We will then decide
whether or not to add the host bridge to the list of chipsets that do
re-ordering.

We may add some additional code later to print the host bridge's ID so
that the user can report it more easily.

The assumption that re-ordering can only happen on x86 systems is also
removed.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      df3e6548
  29. 10 6月, 2006 1 次提交
    • D
      [TG3]: Handle Sun onboard tg3 chips more correctly. · f49639e6
      由 David S. Miller 提交于 
      Get rid of all the SUN_570X logic and instead:

1) Make sure MEMARB_ENABLE is set when we probe the SRAM
   for config information.  If that is off we will get
   timeouts.

2) Always try to sync with the firmware, if there is no
   firmware running do not treat it as an error and instead
   just report it the first time we notice this condition.

3) If there is no valid SRAM signature, assume the device
   is onboard by setting TG3_FLAG_EEPROM_WRITE_PROT.

Update driver version and release date.

With help from Michael Chan and Fabio Massimo Di Nitto.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f49639e6
  31. 30 4月, 2006 1 次提交
  33. 10 4月, 2006 2 次提交
    • M
      [TG3]: Speed up SRAM access (2nd version) · bbadf503
      由 Michael Chan 提交于 
      Speed up SRAM read and write functions if possible by using MMIO
instead of config. cycles. With this change, the post reset signature
done at the end of D3 power change must now be moved before the D3
power change.

IBM reported a problem on powerpc blades during ethtool self test that
was caused by the memory test taking excessively long. Config.  cycles
are very slow on powerpc and the memory test can take more than 10
seconds to complete using config. cycles.

David Miller informed me that an earlier version of the patch caused
problems on sparc64 systems with built-in tg3 chips. This version
fixes the problem by excluding all SUN built-in tg3 chips from doing
MMIO SRAM access.

TG3_FLAG_EEPROM_WRITE_PROT is also set unconditionally when
TG3_FLG2_SUN_570X is set. This should be sane as all SUN chips are
built-in and do not require Vaux switching.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bbadf503
    • M
      [TG3]: Kill some less useful flags · d2d746f8
      由 Michael Chan 提交于 
      Kill the TG3_FLAG_NO_{TX|RX}_PSEUDO_CSUM flags because they are not
very useful. This will free up some bits for new flags.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d2d746f8
  35. 23 3月, 2006 2 次提交
  37. 21 3月, 2006 5 次提交
  39. 20 3月, 2006 1 次提交
    • M
      [TG3]: 40-bit DMA workaround part 2 · 4a29cc2e
      由 Michael Chan 提交于 
      The 40-bit DMA workaround recently implemented for 5714, 5715, and
5780 needs to be expanded because there may be other tg3 devices
behind the EPB Express to PCIX bridge in the 5780 class device.

For example, some 4-port card or mother board designs have 5704 behind
the 5714.

All devices behind the EPB require the 40-bit DMA workaround.

Thanks to Chris Elmquist again for reporting the problem and testing
the patch.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a29cc2e
  41. 03 2月, 2006 1 次提交
    • M
      [TG3]: Flush tg3_reset_task() · 7faa006f
      由 Michael Chan 提交于 
      Make sure tg3_reset_task() is flushed in the close and suspend paths
as noted by Jeff Garzik.

In the close path, calling flush_scheduled_work() may cause deadlock
if linkwatch_event() is on the workqueue. linkwatch_event() will try
to get the rtnl_lock() which is already held by tg3_close(). So
instead, we set a flag in tg3_reset_task() and tg3_close() polls
the flag until it is cleared.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7faa006f
  43. 17 1月, 2006 1 次提交
    • M
      [TG3]: Refine nvram locking · ec41c7df
      由 Michael Chan 提交于 
      Add nvram lock count so that calls to tg3_nvram_lock()/unlock() can
be nested. Add error checking to all callers of tg3_nvram_lock()
where appropriate. To prevent nvram lock failures after halting the
firmware, it is also necessary to release firmware's nvram lock in
tg3_halt_cpu().

Update version to 3.48.

Based on David Miller's initial patch.
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ec41c7df