linux-stable.git/drivers/net, branch linux-2.6.37.y

ixgbe: work around for DDP last buffer size

2011-03-23T19:50:42+00:00

commit c600636bd560b04973174caa5e349a72bce51637 upstream.

A HW limitation was recently discovered where the last buffer in a DDP offload
cannot be a full buffer size in length. Fix the issue with a work around by
adding another buffer with size = 1.

Signed-off-by: Amir Hanania 
Tested-by: Ross Brattain 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

ixgbe: limit VF access to network traffic

2011-03-23T19:50:41+00:00

commit 96cc637235892a102fb829218adac048bd730ab7 upstream.

This change fixes VM pool allocation issues based on MAC address filtering,
as well as limits the scope of VF access to promiscuous mode.

Signed-off-by: Alexander Duyck 
Acked-by: Greg Rose 
Signed-off-by: Jeff Kirsher 
Signed-off-by: Greg Kroah-Hartman

ath9k: remove support for the FIF_PROMISC_IN_BSS filter flag

2011-03-23T19:50:12+00:00

commit 2e286947f1294239527c11f9f466ddce6466455b upstream.

The hardware rx filter flag triggered by FIF_PROMISC_IN_BSS is overly broad
and covers even frames with PHY errors. When this flag is enabled, this message
shows up frequently during scanning or hardware resets:

ath: Could not stop RX, we could be confusing the DMA engine when we start RX up

Since promiscuous mode is usually not particularly useful, yet enabled by
default by bridging (either used normally in 4-addr mode, or with hacks
for various virtualization software), we should sacrifice it for better
reliability during normal operation.

This patch leaves it enabled if there are active monitor mode interfaces, since
it's very useful for debugging.

Signed-off-by: Felix Fietkau 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k_hw: Fix incorrect macversion and macrev checks

2011-03-23T19:50:11+00:00

commit ac45c12dfb3f727a5a7a3332ed9c11b4a5ab287e upstream.

There are few places where we are checking for macversion and revsions
before RTC is powered ON. However we are reading the macversion and
revisions only after RTC is powered ON and so both macversion and
revisions are actully zero and this leads to incorrect srev checks

Incorrect srev checks can cause registers to be configured wrongly and can
cause unexpected behavior. Fixing this seems to address the ASPM issue that
we have observed. The laptop becomes very slow and hangs mostly with ASPM L1
enabled without this fix.

fix this by reading the macversion and revisisons even before we start
using them. There is no reason why should we delay reading this info
until RTC is powered on as this is just a register information.

Signed-off-by: Senthil Balasubramanian 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

ath9k_hw: read and backup AR_WA register value even before chip reset on.

2011-03-23T19:50:10+00:00

commit 0a8d7cb0c8182df7a28ad719780071178c386f0f upstream.

We need to read and backup AR_WA register value permanently and reading
this after the chip is awakened results in this register being zeroed out.

This seems to fix the ASPM with L1 enabled issue that we have observed.
The laptop becomes very slow and hangs mostly with ASPM L1 enabled without
this fix.

Signed-off-by: Senthil Balasubramanian 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

rt2x00: fix hang when unplugging USB device in use

2011-03-23T19:49:57+00:00

commit d7bb5f845f437662296adbfeaab8fbfce1c32289 upstream.

When an rt2x00 USB device is unplugged while in use, it reliably
hangs the whole system.  After some time the watchdog prints:

BUG: soft lockup - CPU#0 stuck for 64s! [kworker/u:0:5]
...
[] (usb_submit_urb+0x0/0x2ac) from [] (rt2x00usb_kick_rx_entry+0xb4/0xe8 [rt2x00usb])
[] (rt2x00usb_kick_rx_entry+0x0/0xe8 [rt2x00usb]) from [] (rt2x00usb_clear_entry+x28/0x2c [rt2x00usb])
[] (rt2x00usb_clear_entry+0x0/0x2c [rt2x00usb]) from [] (rt2x00lib_rxdone+0x2e0/0x2f8 [rt2x00lib])
[] (rt2x00lib_rxdone+0x0/0x2f8 [rt2x00lib]) from [] (rt2x00usb_work_rxdone+0x54/0x74 [rt2x00usb])
[] (rt2x00usb_work_rxdone+0x0/0x74 [rt2x00usb]) from [] (process_one_work+0x20c/0x35c)

Clear the DEVICE_STATE_PRESENT flag when usb_submit_urb()
returns -ENODEV to fix this.

Signed-off-by: Johannes Stezenbach 
Signed-off-by: Ivo van Doorn 
Signed-off-by: John W. Linville 
Cc: Stanislaw Gruszka 
Signed-off-by: Greg Kroah-Hartman

rt2x00: Fix crash on USB unplug

2011-03-23T19:49:57+00:00

commit 070192dd2975c0e97bbdeac7623b755235c6db7d upstream.

By not scheduling the TX/RX completion worker threads
when Radio is disabled, or hardware has been unplugged,
the queues cannot be completely cleaned.

This causes crashes when the hardware has been unplugged while
the radio is still enabled.

Signed-off-by: Ivo van Doorn 
Acked-by: Gertjan van Wingerde 
Signed-off-by: John W. Linville 
Cc: Stanislaw Gruszka 
Signed-off-by: Greg Kroah-Hartman

drivers/net: Call netif_carrier_off at the end of the probe

2011-03-14T21:17:39+00:00

commit 0d672e9f8ac320c6d1ea9103db6df7f99ea20361 upstream.

Without calling of netif_carrier_off at the end of the probe the operstate
is unknown when the device is initially opened. By default the carrier is
on so when the device is opened and netif_carrier_on is called the link
watch event is not fired and operstate remains zero (unknown).

This patch fixes this behavior in forcedeth and r8169.

Signed-off-by: Ivan Vecera 
Acked-by: Francois Romieu 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

r8169: prevent RxFIFO induced loops in the irq handler.

2011-03-14T21:17:39+00:00

commit f60ac8e7ab7cbb413a0131d5665b053f9f386526 upstream.

While the RxFIFO interruption is masked for most 8168, nothing prevents
it to appear in the irq status word. This is no excuse to crash.

Signed-off-by: Francois Romieu 
Cc: Ivan Vecera 
Cc: Hayes 
Signed-off-by: Greg Kroah-Hartman

r8169: RxFIFO overflow oddities with 8168 chipsets.

2011-03-14T21:17:38+00:00

commit 1519e57fe81c14bb8fa4855579f19264d1ef63b4 upstream.

Some experiment-based action to prevent my 8168 chipsets locking-up hard
in the irq handler under load (pktgen ~1Mpps). Apparently a reset is not
always mandatory (is it at all ?).

- RTL_GIGA_MAC_VER_12
- RTL_GIGA_MAC_VER_25
  Missed ~55% packets. Note:
  - this is an old SiS 965L motherboard
  - the 8168 chipset emits (lots of) control frames towards the sender

- RTL_GIGA_MAC_VER_26
  The chipset does not go into a frenzy of mac control pause when it
  crashes yet but it can still be crashed. It needs more work.

Signed-off-by: Francois Romieu 
Cc: Ivan Vecera 
Cc: Hayes 
Signed-off-by: Greg Kroah-Hartman