| Age | Commit message (Collapse) | Author |
|---|
|
commit d1cb0bdac180a4afdd3c001acb2618d2a62d9abe upstream.
* Set correct xpd curve indices for high/low gain curves during
rfbuffer setup on RF5112B with both calibration curves available.
* Don't return zero min power when we have the same pcdac value
twice because it breaks interpolation. Instead return the right
x barrier as we do when we have equal power levels for 2 different
pcdac values.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Acked-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Dan Williams <dcbw@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 33cb7d33a1c36e07839d08a4d1a33bf6a0f70bba upstream.
Before bringing up a sky2 interface up ethtool reports
"Link detected: yes". Do as ixgbe does and netif_carrier_off() on
probe().
Signed-off-by: Brandon Philips <bphilips@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 9a3f45116f5e08819136cd512fd7f6450ac22aa8 upstream.
b43 allocates a bouncebuffer, if the supplied TX skb is in an invalid
memory range for DMA.
However, this is broken in that it fails to copy over some metadata to the
new skb.
This patch fixes three problems:
* Failure to adjust the ieee80211_tx_info pointer to the new buffer.
This results in a kmemcheck warning.
* Failure to copy the skb cb, which contains ieee80211_tx_info, to the new skb.
This results in breakage of various TX-status postprocessing (Rate control).
* Failure to transfer the queue mapping.
This results in the wrong queue being stopped on saturation and can result in queue overflow.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Tested-by: Christian Casteyde <casteyde.christian@free.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit dcfcb256cc23c4436691b0fe677275306699d6a1 upstream.
Fix soft-lockup in hso.c which is triggered on SMP machine when
modem is removed while file descriptor(s) under /dev are still open:
old version called kref_put() too early which resulted in destroying
hso_serial and hso_device objects which were still used later on.
Signed-off-by: Antti Kaijanmäki <antti.kaijanmaki@nomovok.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
[ Upstream commit 345056af41feeda506a8993474b9cbb2c66bc9fb ]
Page buffers containing packets with an incorrect checksum or using a
protocol not handled by hardware checksum offload were previously not
passed to LRO. The conversion to GRO changed this, but did not set
the ip_summed value accordingly.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
[ Upstream commit d3da68310a2cf934c2ea8a99a519d8b1ccca4c56 ]
Modify bonding hash transmit policies to use the psource MAC address of
the packet instead of the MAC address configured for the bonding device.
The old sitation conflicts with the documentation.
Signed-off-by: Jasper Spaans <spaans@fox-it.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
[ Upstream commit 6c60e0c30c80fcd53e61701b7865a85283f8a341 ]
If ace_load_firmware() fails, ace_init() cleans up but still returns
0, leading to an oops as seen in <http://bugs.debian.org/521383>.
It should pass the error code up.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 18c6951091eca7645005a71b556106cc99a6f4b1 upstream.
As shown in http://thread.gmane.org/gmane.linux.kernel.wireless.general/36497,
mac80211 has a bug that allows a call to the TX routine after the queues have
been stopped. This situation will only occur under extreme stress. Although
b43 does not crash when this condition occurs, it does generate a WARN_ON and
also logs a queue overrun message. This patch recognizes b43 is not at fault
and logs a message only when the most verbose debugging mode is enabled. In
the unlikely event that the queue is not stopped when the DMA queue becomes
full, then a warning is issued.
During testing of this patch with one output stream running repeated tcpperf
writes and a second running a flood ping, this routine was entered with
the DMA ring stopped about once per hour. The condition where the DMA queue is
full but the ring has not been stopped has never been seen by me.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 827d42c9ac91ddd728e4f4a31fefb906ef2ceff7 upstream.
Lennert Buytenhek noticed that delBA handling in mac80211
was broken and has remotely triggerable problems, some of
which are due to some code shuffling I did that ended up
changing the order in which things were done -- this was
commit d75636ef9c1af224f1097941879d5a8db7cd04e5
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Tue Feb 10 21:25:53 2009 +0100
mac80211: RX aggregation: clean up stop session
and other parts were already present in the original
commit d92684e66091c0f0101819619b315b4bb8b5bcc5
Author: Ron Rindjunsky <ron.rindjunsky@intel.com>
Date: Mon Jan 28 14:07:22 2008 +0200
mac80211: A-MPDU Tx add delBA from recipient support
The first problem is that I moved a BUG_ON before various
checks -- thereby making it possible to hit. As the comment
indicates, the BUG_ON can be removed since the ampdu_action
callback must already exist when the state is != IDLE.
The second problem isn't easily exploitable but there's a
race condition due to unconditionally setting the state to
OPERATIONAL when a delBA frame is received, even when no
aggregation session was ever initiated. All the drivers
accept stopping the session even then, but that opens a
race window where crashes could happen before the driver
accepts it. Right now, a WARN_ON may happen with non-HT
drivers, while the race opens only for HT drivers.
For this case, there are two things necessary to fix it:
1) don't process spurious delBA frames, and be more careful
about the session state; don't drop the lock
2) HT drivers need to be prepared to handle a session stop
even before the session was really started -- this is
true for all drivers (that support aggregation) but
iwlwifi which can be fixed easily. The other HT drivers
(ath9k and ar9170) are behaving properly already.
Reported-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d01032e4fd33110f9f3a085a36cb819c1dfc5827 upstream
Turn on RTS/CTS for HT to prevent uCode TX fifo underrun
This is fix for
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2103
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Tested-by: Jiajia Zheng <jiajia.zheng@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 73871f7181a1406c67e93c8c83f5edb26057a2a6 upstream
When 802.11g was introduced, we had RTS/CTS and CTS-to-Self protection
mechanisms. In an HT Beacon, HT stations use the "Operating Mode" field
in the HT Information Element to determine whether or not to use
protection.
The Operating Mode field has 4 possible settings: 0-3:
Mode 0: If all stations in the BSS are 20/40 MHz HT capable, or if the
BSS is 20/40 MHz capable, or if all stations in the BSS are 20 MHz HT
stations in a 20 MHz BSS
Mode 1: used if there are non-HT stations or APs using the primary or
secondary channels
Mode 2: if only HT stations are associated in the BSS and at least one
20 MHz HT station is associated.
Mode 3: used if one or more non-HT stations are associated in the BSS.
When in operating modes 1 or 3, and the Use_Protection field is 1 in the
Beacon's ERP IE, all HT transmissions must be protected using RTS/CTS or
CTS-to-Self.
By default, CTS-to-self is the preferred protection mechanism for less
overhead and higher throughput; but using the full RTS/CTS will better
protect the inner exchange from interference, especially in
highly-congested environment.
For 6000 series WIFI NIC, RTS/CTS protection mechanism is the
recommended choice for HT traffic based on the HW design.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 37b12dd2b07b4d7dc222a5f7f88b25cec532b2aa upstream.
As reported by Rick Farina (sidhayn@gmail.com), removing the RTL8187
USB stick, or unloading the driver rtl8187 using rmmod will cause a
kernel oops. There are at least two forms of the failure, (1) BUG:
Scheduling while atomic, and (2) a fatal kernel page fault. This
problem is reported in Bugzilla #14539.
This problem does not occur for kernel 2.6.31, but does for 2.6.32-rc2,
thus it is technically a regression; however, bisection did not locate
any faulty patch. The fix was found by comparing the faulty code in
rtl8187 with p54usb. My interpretation is that the handling of work
queues in mac80211 changed enough to the LEDs to be unregistered
before tasks on the work queues are cancelled. Previously, these
actions could be done in either order.
(Herton Ronaldo Krzesinski <herton@mandriva.com.br> reports that the
code is the same in 2.6.31, so this may be a candidate for 2.6.31.x.
-- JWL)
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Rick Farina <sidhayn@gmail.com>
Tested-by: Rick Farina <sidhayn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit f82a924cc88a5541df1d4b9d38a0968cd077a051 upstream.
Replenishment of receive buffers is done in the tasklet handling
received frames as well as in a workqueue. When we are in the tasklet
we cannot sleep and thus attempt atomic skb allocations. It is generally
not a big problem if this fails since iwl_rx_allocate is always followed
by a call to iwl_rx_queue_restock which will queue the work to replenish
the buffers at a time when sleeping is allowed.
We thus add the __GFP_NOWARN to the skb allocation in iwl_rx_allocate to
reduce the noise if such an allocation fails while we still have enough
buffers. We do maintain the warning and the error message when we are low
on buffers to communicate to the user that there is a potential problem with
memory availability on system
This addresses issue reported upstream in thread "iwlagn: order 2 page
allocation failures" in
http://thread.gmane.org/gmane.linux.kernel.wireless.general/39187
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Acked-by: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit de0bd50845eb5935ce3d503c5d2f565d6cb9ece1 upstream.
RX handling maintains a few lists that keep track of the RX buffers.
Buffers move from one list to the other as they are used, replenished, and
again made available for usage. In one such instance, when a buffer is used
it enters the "rx_used" list. When buffers are replenished an skb is
attached to the buffer and it is moved to the "rx_free" list. The problem
here is that the buffer is first removed from the "rx_used" list _before_ the
skb is allocated. Thus, if the skb allocation fails this buffer remains
removed from the "rx_used" list and is thus lost for future usage.
Fix this by first allocating the skb before trying to attach it to a list.
We add an additional check to not do this unnecessarily.
Reported-by: Rick Farrington <rickdic@hotmail.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d9d5283228d0c752f199c901fff6e1405dc91bcb upstream.
In mii monitor mode, bond_check_dev_link() calls the the ioctl
handler of slave devices. It stores the ndo_do_ioctl function
pointer to a static (!) ioctl variable and later uses it to call the
handler with the IOCTL macro.
If another thread executes bond_check_dev_link() at the same time
(even with a different bond, which none of the locks prevent), a
race condition occurs. If the two racing slaves have different
drivers, this may result in one driver's ioctl handler being
called with a pointer to a net_device controlled with a different
driver, resulting in unpredictable breakage.
Unless I am overlooking something, the "static" must be a
copy'n'paste error (?).
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit d50bae33d1358b909ade05ae121d83d3a60ab63f upstream.
"b43: Fix PPC crash in rfkill polling on unload" fixed the bug reported
in Bugzilla No. 14181; however, it introduced a new bug. Whenever the
radio switch was turned off, it was necessary to unload and reload
the driver for it to recognize the switch again.
This patch fixes both the original bug in #14181 and the bug introduced by
the previous patch. It must be stated, however, that if there is a BCM4306/3
with an rfkill switch (not yet proven), then the driver will need an
unload/reload cycle to turn the device back on.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit e9024a059f2c17fb2bfab212ee9d31511d7b8e57 upstream.
On a 64-bit kernel, skb->tail is an offset, not a pointer. The libertas
usb driver passes it to usb_fill_bulk_urb() anyway, causing interesting
crashes. Fix that by using skb->data instead.
This highlights a problem with usb_fill_bulk_urb(). It doesn't notice
when dma_map_single() fails and return the error to its caller as it
should. In fact it _can't_ currently return the error, since it returns
void.
So this problem was showing up only at unmap time, after we'd already
suffered memory corruption by doing DMA to a bogus address.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 575c9ed7798218dc923f319c0d78f0c25ca506b9 upstream.
I've not touched the other stuff here but the word "locking" comes to mind.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 2facba769d7f9e563cf706de709074a2d20f1bba upstream.
The address stored in the next link address is a word address but when
reading the OTP blocks, a byte address is used. Also if the blocks are
full and the last link pointer is not zero, then none of the blocks are
valid so return an error.
The algorithm is simply valid blocks have a next address and that
address's contents is zero.
Using the wrong address for the next link address gets arbitrary data,
obviously. In cases seen, the first block is considered valid when it is not.
If the block has in fact been invalidated there may be old data or
there may be no data, bad data, or partial data, there is no way of
telling. Without this patch it is possible that a device with valid OTP data
is unable to work.
Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit a825e00c98a2ee37eb2a0ad93b352e79d2bc1593 upstream.
There appears to have been a mixup in the max supported jumbo frame size
between 82574 and 82583 which ended up disabling jumbo frames on the 82574
as a result. This patch swaps the two so that this issue is resolved.
This patch fixes http://bugzilla.kernel.org/show_bug.cgi?id=14261
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>
Cc: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
[ Upstream commit ffcfb8db540ff879c2a85bf7e404954281443414 ]
And also do a better job of returning proper NET_{RX,XMIT}_ values.
Based on a patch by Mark Smith.
This fixes CVE-2009-2903
Reported-by: Mark Smith <lk-netdev@lk-netdev.nosense.org>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
[ Upstream commit 74a61ebf653c6abe459f228eb40e9f24f7ef1fb7 ]
The SKY2_HW_RAM_BUFFER bit in hw->flags was checked in sky2_mac_init(),
before being set later in sky2_up().
Setting SKY2_HW_RAM_BUFFER in sky2_init() where other hw->flags are set
should avoid this problem recurring.
Signed-off-by: Mike McCormack <mikem@ring3k.org>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
[ Upstream commit ec4756238239f1a331d9fb95bad8b281dad56855 ]
Usbnet framework assumes USB hardware doesn't handle zero length
packets, but SMSC LAN95xx requires these to be sent for correct
operation.
This patch fixes an easily reproducible tx lockup when sending a frame
that results in exactly 512 bytes in a USB transmission (e.g. a UDP
frame with 458 data bytes, due to IP headers and our USB headers). It
adds an extra flag to usbnet for the hardware driver to indicate that
it can handle and requires the zero length packets.
This patch should not affect other usbnet users, please also consider
for -stable.
Signed-off-by: Steve Glendinning <steve.glendinning@smsc.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
[ Upstream commit 36989b90879c785f95b877bdcf65a2527dadd893 ]
After commit 2b980dbd77d229eb60588802162c9659726b11f4
("lsm: Add hooks to the TUN driver") tun_set_iff doesn't
return -EINVAL though neither IFF_TUN nor IFF_TAP is set.
Signed-off-by: Kusanagi Kouichi <slash@ma.neweb.ne.jp>
Reviewed-by: Paul Moore <paul.moore@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit b607bd900051efc3308c4edc65dd98b34b230021 upstream.
Which is why I have always preferred sizeof(struct foo) over
sizeof(var).
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
This is commit 5bddf54962bf68002816df710348ba197d6391bb in linux-2.6.
If NetworkManager is busy scanning when user
tries to unload the module, the driver can not be unloaded
because HW still scanning.
Make sure driver sends abort scan host command to uCode if it
is in the middle of scanning during driver unload.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 415e49936b4b29b34c2fb561eeab867d41fc43a6 upstream.
For devices using OTP memory, EEPROM image can start from
any one of the OTP blocks. If shadow RAM is disabled, we need to
traverse link list to find the last valid block, then start the EEPROM
image reading.
If OTP is not full, the valid block is the block _before_ the last block
on the link list; the last block on the link list is the empty block
ready for next OTP refresh/update.
If OTP is full, then the last block is the valid block to be used for
configure the device.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 02c06e4abc0680afd31bf481a803541556757fb6 upstream.
On 1000, there are two Switching Voltage Regulators (SVR). The first one
apply digital voltage level (1.32V) for PCIe block and core. We need to
use this regulator to solve a stability issue related to noisy DC2DC
line in the silicon.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit cce53aa347c1e023d967b1cb1aa393c725aedba5 upstream.
firmware file now contains build number so API needs to be updated.
Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit cc0f555d511a5fe9d4519334c8f674a1dbab9e3a upstream.
Adding new API version to account for change to ucode file format. New
header includes the build number of the ucode. This build number is the
SVN revision thus allowing for exact correlation to the code that
generated it.
The header adds the build number so that older ucode images can also be
enhanced to include the build in the future.
some cleanup in iwl_read_ucode needed to ensure old header not used and
reduce unnecessary references through pointer with the data is already
in heap variable.
Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 0d0cd72fa1e6bfd419c99478ec70b4877ed0ef86 upstream.
Paraphrasing Rafael J. Wysocki: "drivers should not release PCI IRQs
in suspend." Doing so causes a warning during suspend/resume on some
platforms.
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Reported-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit edd7fc7003f31da48d06e215a93ea966a22c2a03 upstream.
* Don't put chip to full sleep because there are problems during
wakeup. Instead hold MAC/Baseband on warm reset state via a new
function ath5k_hw_on_hold.
* Minor cleanups
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Tested-by: Ben Greear <greearb@candelatech.com>
Tested-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 481a8199142c050b72bff8a1956a49fd0a75bbe0 upstream.
When using nanosleep() in an userspace application we get a ratelimit warning
NOHZ: local_softirq_pending 08
for 10 times.
The echo of CAN frames is done from process context and softirq context only.
Therefore the usage of netif_rx() was wrong (for years).
This patch replaces netif_rx() with netif_rx_ni() which has to be used from
process/softirq context. It also adds a missing comment that can_send() must
no be used from hardirq context.
Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: Urs Thuermann <urs@isnogud.escape.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 051b982bcc620695de629d29c333c95b66e9b95e upstream.
kaweth_control() never frees the buffer that it allocates for the USB
control message. Test case:
while :; do ifconfig eth2 down ; ifconfig eth2 up ; done
This is a tiny buffer so it is a slow leak. If you want to speed up the
process, you can change the allocation size to e.g. 16384 bytes, and it
will consume several megabytes within a few minutes.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Acked-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit fe9f6342c86292aee1941447f22dc5470735e5a1 upstream.
This patch adds the usbid for TP-Link TL-WN821N v2.
Reported-by: Fabian Lenz <lenz_fabian@yahoo.de>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit f7f71173ea69d4dabf166533beffa9294090b7ef upstream.
This patch adds a new usbid for Zcomax XG-705A to the device table.
Reported-by: Jari Jaakola <jari.jaakola@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit fa0681d2129732027355d6b7083dd8932b9b799d upstream.
The current implementation allocates a single host page for EQ context
memory, which was OK when we only allocated a few EQs. However, since
we now allocate an EQ for each CPU core, this patch removes the
hard-coded limit (which we exceed with 4 KB pages and 128 byte EQ
context entries with 32 CPUs) and uses the same ICM table code as all
other context tables, which ends up simplifying the code quite a bit
while fixing the problem.
This problem was actually hit in practice on a dual-socket Nehalem box
with 16 real hardware threads and sufficiently odd ACPI tables that it
shows on boot
SMP: Allowing 32 CPUs, 16 hotplug CPUs
so num_possible_cpus() ends up 32, and mlx4 ends up creating 33 MSI-X
interrupts and 33 EQs. This mlx4 bug means that mlx4 can't even
initialize at all on this quite mainstream system.
Reported-by: Eli Cohen <eli@mellanox.co.il>
Tested-by: Christoph Lameter <cl@linux-foundation.org>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
commit 3355443ad7601991affa5992b0d53870335af765 upstream.
"Ath5k: unify resets"
introduced a regression into 2.6.28 where the PCU registers are never
initialized, due to ath5k_reset() always passing true for change_channel.
We subsequently program a lot of these registers but several may start
in an unknown state.
Reported-by: Forrest Zhang <forrest@hifulltech.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
|
|
Reported by Michael Guntsche <mike@it-loops.com>
--------------------
Commit
38bddf04bcfe661fbdab94888c3b72c32f6873b3 gianfar: gfar_remove needs to call unregister_netdev()
breaks the build of the gianfar driver because "dev" is undefined in
this function. To quickly test rc9 I changed this to priv->ndev but I do
not know if this is the correct one.
--------------------
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch solves the problem that the Oops(BUG_ON) occurs by rmmod.
# rmmod gianfar_driver
------------[ cut here ]------------
Kernel BUG at c01fec48 [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
MPC837x MDS
Modules linked in: gianfar_driver(-) usb_storage scsi_wait_scan
NIP: c01fec48 LR: c01febf4 CTR: c01feba8
REGS: dec5bd60 TRAP: 0700 Tainted: G W (2.6.31-rc2)
MSR: 00029032 <EE,ME,CE,IR,DR> CR: 22000424 XER: 20000000
TASK = dec4cac0[1135] 'rmmod' THREAD: dec5a000
GPR00: 00000002 dec5be10 dec4cac0 dfba1820 c035d444 c035d478 ffffffff 00000000
GPR08: 0000002b 00000001 dfba193c 00000001 22000424 10019b34 1ffcb000 00000000
GPR16: 10012008 00000000 bf82ebe0 100017ec bf82ebec bf82ebe8 bf82ebd0 00000880
GPR24: 00000000 bf82ebf0 c03532f0 c03532e4 c036b594 dfba183c dfba1800 dfba1820
NIP [c01fec48] free_netdev+0xa0/0xb8
LR [c01febf4] free_netdev+0x4c/0xb8
Call Trace:
[dec5be10] [c01febf4] free_netdev+0x4c/0xb8 (unreliable)
[dec5be30] [e105f290] gfar_remove+0x50/0x68 [gianfar_driver]
[dec5be40] [c01ec534] of_platform_device_remove+0x30/0x44
[dec5be50] [c0181760] __device_release_driver+0x68/0xc8
[dec5be60] [c0181868] driver_detach+0xa8/0xac
[dec5be80] [c0180814] bus_remove_driver+0x9c/0xd8
[dec5bea0] [c0181efc] driver_unregister+0x60/0x98
[dec5beb0] [c01ec650] of_unregister_driver+0x14/0x24
[dec5bec0] [e10631bc] gfar_exit+0x18/0x4bc [gianfar_driver]
[dec5bed0] [c0047584] sys_delete_module+0x16c/0x228
[dec5bf40] [c00116bc] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff3669c
LR = 0x10000f34
Instruction dump:
409e0024 a07e00c0 7c63f050 4be74429 80010024 bba10014 38210020 7c0803a6
4e800020 68000003 3160ffff 7d2b0110 <0f090000> 38000004 387e01f0 901e01d4
---[ end trace 8c595bcd37230a0f ]---
localhost kernel: ------------[ cut here ]------------
Signed-off-by: Toru UCHIYAMA uchiyama.toru@jp.fujitsu.com
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
|
|
Bartlomiej Zolnierkiewicz reported an atomic order-6 allocation failure
for ipw2200 firmware loading in kernel 2.6.30. High order allocation is
likely to fail and should always be avoided.
The patch fixes this problem by replacing the original order-6
pci_alloc_consistent() with an array of order-1 pages from a pci pool.
This utilized the ipw2200 DMA command blocks (up to 64 slots). The
maximum firmware size support remains the same (64*8K).
This patch fixes bug http://bugzilla.kernel.org/show_bug.cgi?id=14016
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
If we run out of memory, use keventd to fill the buffer. There's a
report of this happening: "Page allocation failures in guest",
Message-ID: <20090713115158.0a4892b0@mjolnir.ossman.eu>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch is based on commit d2f3ad4 (pxaficp-ir: remove incorrect
net_device_ops). Do the same for sa1100_ir.
Untested.
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch is based on commit d2f3ad4 (pxaficp-ir: remove incorrect
net_device_ops). Do the same for au1k_ir.
Untested.
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The NETPOLL requires that interrupts remain disabled in its callbacks.
Using *_irq_save()/irq_restore() to replace *_irq_disable()/irq_enable()
functions in NETPOLL's callbacks of smc91x, so that it doesn't enable
interrupts when already disabled, and kgdboe/netconsole would work
properly over smc91x.
Signed-off-by: Dongdong Deng <dongdong.deng@windriver.com>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch fixes broken pxaficp-ir. The problem was in incorrect
net_device_ops being specified which prevented the driver from
operating. The symptoms were:
- failing ifconfig for IrLAN, resulting in
SIOCSIFFLAGS: Cannot assign requested address
- irattach working for IrCOMM, but the port stayed disabled
Moreover this patch corrects missing sysfs device link.
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The NETPOLL API requires that interrupts remain disabled in
netpoll_send_skb(). The use of "A functions set" in the NETPOLL API
callbacks causes the interrupts to get enabled and can lead to kernel
instability.
The solution is to use "B functions set" to prevent the irqs from
getting enabled while in netpoll_send_skb().
A functions set:
local_irq_disable()/local_irq_enable()
spin_lock_irq()/spin_unlock_irq()
spin_trylock_irq()/spin_unlock_irq()
B functions set:
local_irq_save()/local_irq_restore()
spin_lock_irqsave()/spin_unlock_irqrestore()
spin_trylock_irqsave()/spin_unlock_irqrestore()
Signed-off-by: Dongdong Deng <dongdong.deng@windriver.com>
Acked-by: Matt Mackall <mpm@selenic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Andreas Mohr <andi@lisas.de>
Acked-by: Richard Röjfors <richard.rojfors.ext@mocean-labs.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
