linux-toradex.git/drivers/net, branch v2.6.27.12

e1000e: fix IPMI traffic

2009-01-18T18:35:40+00:00

commit eb7c3adb1ca92450870dbb0d347fc986cd5e2af4 upstream.

Some users reported that they have machines with BMCs enabled that cannot
receive IPMI traffic after e1000e is loaded.
http://marc.info/?l=e1000-devel&m=121909039127414&w=2
http://marc.info/?l=e1000-devel&m=121365543823387&w=2

This fixes the issue if they load with the new parameter = 0 by disabling
crc stripping, but leaves the performance feature on for most users.
Based on work done by Hong Zhang.

Signed-off-by: Jeff Kirsher 
Signed-off-by: Jesse Brandeburg 
Signed-off-by: David S. Miller 
Cc: Bryon Roche 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: use GFP_KERNEL to allocate Rx SKB memory

2009-01-18T18:35:27+00:00

commit f1bc4ac61f2c08515afd80c6dc3962aa6d0b138b upstream.

Previously we allocate Rx SKB with GFP_ATOMIC flag. This is because we need
to hold a spinlock to protect the two rx_used and rx_free lists operation
in the rxq.

	spin_lock();
	...
	element = rxq->rx_used.next;
	element->skb = alloc_skb(..., GFP_ATOMIC);
	list_del(element);
	list_add_tail(&element->list, &rxq->rx_free);
	...
	spin_unlock();

After spliting the rx_used delete and rx_free insert into two operations,
we don't require the skb allocation in an atomic context any more (the
function itself is scheduled in a workqueue).

	spin_lock();
	...
	element = rxq->rx_used.next;
	list_del(element);
	...
	spin_unlock();
	...
	element->skb = alloc_skb(..., GFP_KERNEL);
	...
	spin_lock()
	...
	list_add_tail(&element->list, &rxq->rx_free);
	...
	spin_unlock();

This patch should fix the "iwlagn: Can not allocate SKB buffers" warning
we see recently.

Signed-off-by: Zhu Yi 
Acked-by: Tomas Winkler 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

drivers/net: starfire: Fix napi ->poll() weight handling

2009-01-14T17:44:07+00:00

commit 9a3de25544dadab1971847f28f33b1cd0d1770a6 upstream.

starfire napi ->poll() handler can return work == weight after calling
netif_rx_complete() (if there is no more work). It is illegal and this
patch fixes it.

Reported-by: Alexander Huemer 
Tested-by: Alexander Huemer 
Signed-off-by: Jarek Poplawski 
Signed-off-by: David S. Miller 
Cc: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

iwlagn: downgrade BUG_ON in interrupt

2009-01-14T17:44:03+00:00

commit 55d6a3cd0cc85ed90c39cf32e16f622bd003117b upstream.

This BUG_ON really shouldn't trigger, but if it does, as on my machine,
it leaves you wondering what happened because you won't see it. Let's
instead leak a bit of state and memory and at least make it possible to
report it to the kerneloops project to track it.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Cc: François Valenduc 
Signed-off-by: Greg Kroah-Hartman

iwlagn: fix RX skb alignment

2008-12-18T17:13:38+00:00

commit 4018517a1a69a85c3d61b20fa02f187b80773137 upstream.

So I dug deeper into the DMA problems I had with iwlagn and a kind soul
helped me in that he said something about pci-e alignment and mentioned
the iwl_rx_allocate function to check for crossing 4KB boundaries. Since
there's 8KB A-MPDU support, crossing 4k boundaries didn't seem like
something the device would fail with, but when I looked into the
function for a minute anyway I stumbled over this little gem:

	BUG_ON(rxb->dma_addr & (~DMA_BIT_MASK(36) & 0xff));

Clearly, that is a totally bogus check, one would hope the compiler
removes it entirely. (Think about it)

After fixing it, I obviously ran into it, nothing guarantees the
alignment the way you want it,  because of the way skbs and their
headroom are allocated. I won't explain that here nor double-check that
I'm right, that goes beyond what most of the CC'ed people care about.

So then I came up with the patch below, and so far my system has
survived minutes with 64K pages, when it would previously fail in
seconds. And I haven't seen a single instance of the TX bug either. But
when you see the patch it'll be pretty obvious to you why.

This should fix the following reported kernel bugs:

http://bugzilla.kernel.org/show_bug.cgi?id=11596
http://bugzilla.kernel.org/show_bug.cgi?id=11393
http://bugzilla.kernel.org/show_bug.cgi?id=11983

I haven't checked if there are any elsewhere, but I suppose RHBZ will
have a few instances too...

I'd like to ask anyone who is CC'ed (those are people I know ran into
the bug) to try this patch.

I am convinced that this patch is correct in spirit, but I haven't
understood why, for example, there are so many unmap calls. I'm not
entirely convinced that this is the only bug leading to the TX reply
errors.

Signed-off-by: Johannes Berg 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

iwlwifi: clean key table in iwl_clear_stations_table function

2008-12-18T17:13:37+00:00

commit 40a9a8299116297429298e8fcee08235134883f7 upstream.

This patch cleans uCode key table bit map iwl_clear_stations_table
since all stations are cleared also the key table must be.

Since the keys are not removed properly on suspend by mac80211
this may result in exhausting key table on resume leading
to memory corruption during removal

This patch also fixes a memory corruption problem reported in
http://marc.info/?l=linux-wireless&m=122641417231586&w=2 and tracked in
http://bugzilla.kernel.org/show_bug.cgi?id=12040.

When the key is removed a second time the offset is set to 255 - this
index is not valid for the ucode_key_table and corrupts the eeprom pointer
(which is 255 bits from ucode_key_table).

Signed-off-by: Tomas Winkler 
Signed-off-by: Zhu Yi 
Reported-by: Carlos R. Mafra 
Reported-by: Lukas Hejtmanek 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

e1000e: fix double release of mutex

2008-12-18T17:13:36+00:00

commit 30bb0e0dce78427f3e5cb728d6b5ea73acbefffa upstream.

During a reset, releasing the swflag after it failed to be acquired would
cause a double unlock of the mutex.  Instead, test whether acquisition of
the swflag was successful and if not, do not release the swflag.  The reset
must still be done to bring the device to a quiescent state.

This resolves [BUG 12200] BUG: bad unlock balance detected! e1000e
http://bugzilla.kernel.org/show_bug.cgi?id=12200

Signed-off-by: Jeff Kirsher 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bonding: fix miimon failure counter

2008-12-18T17:13:35+00:00

commit fba4acda35f3119328bcba28aacefae14245d2bb upstream.

During the rework of the mii monitor for:

  commit f0c76d61779b153dbfb955db3f144c62d02173c2
  Author: Jay Vosburgh 
  Date:   Wed Jul 2 18:21:58 2008 -0700

    bonding: refactor mii monitor

I left out the increment of the link failure counter.  This
patch corrects that omission.

Signed-off-by: Jay Vosburgh 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

cxgb3 - remove duplicate tests in lro

2008-12-13T23:29:30+00:00

commit 004f23b9d3874efc81d2d1cf18fd0fe48dc2f26f upstream.

The generic lro code checks TCP flags/options.
Remove duplicate tests done in the driver.

Signed-off-by: Divy Le Ray 
Signed-off-by: Jeff Garzik 
Cc: Hannes Reinecke 
Signed-off-by: Greg Kroah-Hartman

cxgb3 - fix race in EEH

2008-12-13T23:29:30+00:00

commit 0ca41c0413a4d9ca58767d53d23accea9aa1cdef upstream.

A SGE queue set timer might access registers while in EEH recovery,
triggering an EEH error loop. Stop all timers early in EEH process.

Signed-off-by: Divy Le Ray 
Signed-off-by: David S. Miller 
Cc: Karsten Keil 
Signed-off-by: Greg Kroah-Hartman