This patch fixes two potential races in the velocity driver:
* Move the ACK and error handler to the interrupt handler. This fixes a
potential race with shared interrupts when the other device interrupts
before the NAPI poll handler has finished. As the velocity driver hasn't
acked it's own interrupt, it will then steal the interrupt from the
other device.
* Use spin_lock_irqsave in velocity_poll. In the current code, the
interrupt handler will deadlock if e.g., the NAPI poll handler is
executing when an interrupt (for another device) comes in since it
tries to take the already held lock.
Also unlock the spinlock only after enabling the interrupt in
velocity_poll.
The error path is moved to the interrupt handler since this is where the
ISR is checked now.
Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
Signed-off-by: Anders Grafstrom <anders.grafstrom@netinsight.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
velocity_set_coalesce touches ISR and some other sensitive registers not
covered by the rtnl lock, so take the velocity spinlock.
Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add new RTL8187B device.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@kernel.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The wrong pointer was tested.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Currently, PAE frames are not assigned proper sequence numbers.
Since sending PAE frames as part of aggregates breaks
crupto with several APs, they are sent as normal MPDUs.
Fix the seqeuence number issue by updating the frame with the
internal sequence number.
Tested-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Test the value that was just allocated rather than the previously tested one.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@r@
expression *x;
expression e;
identifier l;
@@
if (x == NULL || ...) {
... when forall
return ...; }
... when != goto l;
when != x = e
when != &x
*x == NULL
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Verify the HW checksum state for frames handed to GRO processing.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
iwl_set_rxon_ht() only get called in iwl_post_associate(); which cause
possible incorrect ht configuration. Adding the call in iwl_mac_config() if
IEEE80211_CONF_CHANGE_CHANNEL flag is set to re-configure and send rxon
command.
Fixes
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2146
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
CC: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This change corrects an issue that will cause false hangs when using either
82575 or 82580 in legacy interrupt mode. The issue is caused when there is
a slow traffic flow and an "ethtool -r" is executed while using legacy or
MSI interrupts. MSI-X is not affected by this issue due to the fact that
we were already reconfiguring the vectors after reset.
If possible it would be best to push this for net-2.6 since it is resolving
a bug but if that is not possible then net-next-2.6 will be fine.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
a developer had complained of getting lots of warnings:
"eth16 selects TX queue 98, but real number of TX queues is 64"
http://www.mail-archive.com/e1000-devel@lists.sourceforge.net/msg02200.html
As there was no follow up on that bug, I am submitting this
patch assuming that the other return points will not return
invalid txq's, and also that this fixes the bug (not tested).
Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit e5a43549f7 (ixgbe: remove
skb_dma_map/unmap calls from driver) looks to have introduced a bug in
ixgbe_tx_map. If we get an error from a PCI DMA call, we loop backwards
through count until it becomes -1 and return that.
The caller of ixgbe_tx_map expects 0 on error, so return that instead.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
o context resources can be in used, while resource cleanup is in progress,
during fw recover.
o Null pointer execption can occur in send_cmd_desc, if fw recovery
module frees tx ring without rtnl lock.
o Same applies to ethtool register dump.
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For NX2031, first try to scrub interrupt before requesting firmware
reset. Return statement was missing after scrubbbing interrupt.
Signed-off-by: Vernon Mauery <vernux@us.ibm.com>
Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The book keeping structure for transmit always had the flags value
cleared so transmit DMA maps were never released correctly.
Based on patch by Jarek Poplawski, problem observed by Michael Breuer.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit c7ab5ef9bc entitled "b43: implement
short slot and basic rate handling" reduced the transmit throughput for
my BCM4311 device from 18 Mb/s to 0.7 Mb/s. The basic rate handling
portion is OK, the problem is in the short slot handling.
Prior to this change, the short slot enable/disable routines were never
called. Experimentation showed that the critical part was changing the
value at offset 0x0010 in the shared memory. This is supposed to contain
the 802.11 Slot Time in usec, but if it is changed from its initial value
of zero, performance is destroyed. On the other hand, changing the value
in the MMIO register corresponding to the Interframe Slot Time increased
performance from 18 to 22 Mb/s. A BCM4306/3 also shows dramatic
improvement of the transmit rate from 5.3 to 19.0 Mb/s.
Other changes in the patch include removal of the magic number for the
MMIO register, and allowing the slot time to be set for any PHY operating
in the 2.4 GHz band. Previously, the routine was executed only for G PHYs.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@kernel.org> [Any stable version back through 2.6.28]
Signed-off-by: John W. Linville <linville@tuxdriver.com>
cev-isr reg offset for each function is better calculated using (any) eq-id
alloted to that function instead of using pci-func number(which
does not work in some configurations...)
Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 37e8273cd3 ("usbnet: Set link down
initially for drivers that update link state") changed the initial link
state in cdc_ether and other drivers based on the understanding that the
devices they support generate link change interrupts. However, this is
optional in the CDC Ethernet protocol, and two users have reported in
<http://bugzilla.kernel.org/show_bug.cgi?id=14791> that the link state
for their devices remains down. Therefore, revert the change in
cdc_ether.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Tested-by: Avi Rozen <avi.rozen@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The convention for API functions in kernel is to return errno value;
bond_open would return -1 if alb setup failed. The only reason that
could happen is if kmalloc() failed.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Call ixgbe_copy_dcb_cfg() earlier in the ixgbe_dcbnl_set_all() so that
we can learn if this is going to fail as early as possible. Previously,
ixgbe_down or ixgbe_close were being called before this check and the
IXGBE_RESETTING bit was being set and cleared. Worse if this failed
the corresponding ixgbe_up/ndo_open would not called.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Set the correct bit BIT_PG_TX when tx PG settings are set.
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
Acked-by: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This change fixes an issue in igbvf with mapped_as_page being left set
after a page is unmapped which results in buffers which are mapped via map
single being unmapped as page.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hello David Miller,
I fix a bug in ks8851_mll driver, which has existed since 2.6.32-rc6.
>From : David J. Choi <david.choi@micrel.com>
Fix a bug that the data pointers in the interrupt handler are set wrong, which is related with the 5th parameter of request_irq().
Signed-off-by : David J. Choi <david.choi@micrel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Bug fix in be2net for newer generation of BladeEngine ASIC.
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
netdev_open() will return without cleaning up net device or hardware state
if firmware loading fails. This results in a BUG() on a second attempt to
bring the interface up, reported in
<http://bugzilla.kernel.org/show_bug.cgi?id=15091>, and probably has even
worse effects if the driver is removed afterwards.
Call netdev_close() to clean up on failure.
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=15091
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Reported-by: Michael Moffatt <michael@moffatt.org.nz>
Tested-by: Michael Moffatt <michael@moffatt.org.nz>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
I have seen RX stalls on a machine that experienced a suspected
OOM. After the stall, the RX buffer is empty on the guest side
and there are exactly 16 entries available on the host side. As
the number of entries is less than that required by a maximal
skb, the host cannot proceed.
The guest did not have a refill job scheduled.
My diagnosis is that an OOM had occured, with the delayed refill
job scheduled. The job was able to allocate at least one skb, but
not enough to overcome the minimum required by the host to proceed.
As the refill job would only reschedule itself if it failed completely
to allocate any skbs, this would lead to an RX stall.
The following patch removes this stall possibility by always
rescheduling the refill job until the ring is totally refilled.
Testing has shown that the RX stall no longer occurs whereas
previously it would occur within a day.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
The low-level MCDI code always uses 32-bit MMIO operations, and
callers must pad input and output buffers to multiples of 4 bytes.
The MCDI NVRAM functions are not doing this. Also, their buffers are
declared as variable-length arrays with no explicit maximum length.
Switch to a fixed buffer size based on the chunk size used by the
MTD driver (which is a multiple of 4).
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Due to a hardware bug in the SFC9000 family, the firmware must
transfer raw GMAC statistics to host memory before aggregating them
into the cooked (speed-independent) MAC statistics. Extend the stats
buffer to support this.
The length of the buffer is explicit in the MAC_STATS command, so this
change is backward-compatible on both sides.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently qlge tries to release regions even if they were not allocated.
This causes messages like the following in the kernel log
Trying to free nonexistent resource <00000000006af400-00000000006af4ff>
Trying to free nonexistent resource <00003c04ff9f4000-00003c04ff9f7fff>
Trying to free nonexistent resource <00003c04ffc00000-00003c04ffcfffff>
This patch fixes the goto logic in order to not release the resources
if they were not allocated.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Among other changes, this commit:
commit 06d0f0663e
Author: Sujith <Sujith.Manoharan@atheros.com>
Date: Thu Feb 12 10:06:45 2009 +0530
ath9k: Enable Fractional N mode
changed the hw attach code to fix up initialization values only for
dual band devices, however the commit message did not give a reason as
to why this would be useful or necessary.
According to tests by Jorge Boncompte, this breaks at least some
2GHz-only cards, so the code should be changed back to the
unconditional INI fixup.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Reported-by: Jorge Boncompte <jorge@dti2.net>
Cc: stable@kernel.org
Tested-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are a few station addresses that are
char *, instead of the normal u8 *; gcc
gives pointer signedness warnings for some
of those, so use u8 * consistently.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Obviously, this register had some other impact that is causing
the regression. Either it is masking some other access or needs
to be reset in some path.
Either, way it is best to just revert the change for 2.6.33
This reverts commit 166a0fd4c7.
Signed-off-by: David S. Miller <davem@davemloft.net>
Y2_HW_WOL_ON/Y2_HW_WOL_OFF should be set and cleared per chip,
not per port. On dual port cards, Y2_HW_WOL_ON should be
enabled if either sky2 port has WOL enabled.
Found while reviewing code for a WOL regression, though this is
probably not the cause of the regression.
Signed-off-by: Mike McCormack <mikem@ring3k.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Found this problem when testing IPv6 from a KVM guest to a remote
host via e1000e device on the host.
The following patch fixes the check for IPv6 GSO packet in Intel
ethernet drivers to use skb_is_gso_v6(). SKB_GSO_DODGY is also set
when packets are forwarded from a guest.
Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
After removing the skb_dma_map/unmap calls the exception handling in
igb_tx_map_adv is not correct. The issue is that the count value was not
being correctly handled so as a result we were not rewinding the ring as
back as we should have been.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When testing the "e1000: enhance frame fragment detection" (and e1000e)
patches we found some bugs with reducing the MTU size. The 1024 byte
descriptor used with the 1000 mtu test also (re) introduced the
(originally) reported bug, and causes us to need the e1000_clean_tx_irq
"enhance frame fragment detection" fix.
So what has occured here is that 2.6.32 is only vulnerable for mtu <
1500 due to the jumbo specific routines in both e1000 and e1000e.
So, 2.6.32 needs the 2kB buffer len fix for those smaller MTUs, but
is not vulnerable to the original issue reported. It has been pointed
out that this vulnerability needs to be patched in older kernels that
don't have the e1000 jumbo routine. Without the jumbo routines, we
need the "enhance frame fragment detection" fix the e1000, old
e1000e is only vulnerable for < 1500 mtu, and needs a similar
fix. We split the patches up to provide easy backport paths.
There is only a slight bit of extra code when this fix and the
original "enhance frame fragment detection" fixes are applied, so
please apply both, even though it is a bit of overkill.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
fmvj18x_cs, serial_cs:
add new id
Panasonic lan & modem card (model name:AL-VML101)
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
Only the first two fields of mcc wrb - embedded, payload_len
need to be cpu_to_le32() swapped while issuing a cmd to the hw.
The fields tag0, tag1 are opaque and returned back to cpu as is...
Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Please add support for Microsoft MN-120 PCMCIA network card. It's an
old card, I know, but adding support is very easy. You just need to
get tulip_core.c to recognise its vendor/device ID.
Patch for kernel 2.6.32.4 (and many previous) attached.
.....Ron Murray
Signed-off-by: Ron Murray <rjmx@rjmx.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pages are posted to the rxq in such a way that more than one frag
can share the page. The last frag that uses the page unmaps the
page. In the case when a page is not fully used (due to lack of space in rxq)
the last frag that uses the page is not being set as a "last_page_user";
instead, the next frag in the rxq is incorrectly being set.
The fix has also been tested on ppc64 with 64k pages...
Signed-off-by: Sathya Perla <sathyap@serverengines.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The Intel WiMax Wireless Link 6050 can show under more than one USB
ID. Add support for all, introducing a generic flag (i2400mu->i6050)
that denotes a 6x50 based device.
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Originally patched by Neil Horman <nhorman@tuxdriver.com>
e1000e could with a jumbo frame enabled interface, and packet split disabled,
receive a packet that would overflow a single rx buffer. While in practice
very hard to craft a packet that could abuse this, it is possible.
this is related to CVE-2009-4538
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Originally From: Neil Horman <nhorman@tuxdriver.com>
Modified by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Hey all-
A security discussion was recently given:
http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html
And a patch that I submitted awhile back was brought up. Apparently some of
their testing revealed that they were able to force a buffer fragment in e1000
in which the trailing fragment was greater than 4 bytes. As a result the
fragment check I introduced failed to detect the fragement and a partial
invalid frame was passed up into the network stack. I've written this patch
to correct it. I'm in the process of testing it now, but it makes good
logical sense to me. Effectively it maintains a per-adapter state variable
which detects a non-EOP frame, and discards it and subsequent non-EOP frames
leading up to _and_ _including_ the next positive-EOP frame (as it is by
definition the last fragment). This should prevent any and all partial frames
from entering the network stack from e1000.
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The variable count and i are unsigned so the (<|>=)0 tests do not work.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When cleaning up beacon buffers and slots, ath9k currently checks if
sc->ah->opmode is set to a beacon related mode before cleaning up
buffers.
An unfortunate ordering of interface up/down commands can lead to
sc->ah->opmode being set to monitor mode, while there are AP interfaces
present on the same wiphy.
Always cleaning up beacon buffers if present fixes this issue.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
