| Age | Commit message (Collapse) | Author |
|---|
|
Michael Tokarev reported receiving a large packet could crash
a machine with RTL8169 NIC.
( original thread at http://lkml.org/lkml/2009/6/8/192 )
Problem is this driver tells that NIC frames up to 16383 bytes
can be received but provides skb to rx ring allocated with
smaller sizes (1536 bytes in case standard 1500 bytes MTU is used)
When a frame larger than what was allocated by driver is received,
dma transfert can occurs past the end of buffer and corrupt
kernel memory.
Fix is to tell to NIC what is the maximum size a frame can be.
This bug is very old, (before git introduction, linux-2.6.10), and
should be backported to stable versions.
Reported-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Patch to fix bad length checking in e1000. E1000 by default does two
things:
1) Spans rx descriptors for packets that don't fit into 1 skb on recieve
2) Strips the crc from a frame by subtracting 4 bytes from the length prior to
doing an skb_put
Since the e1000 driver isn't written to support receiving packets that span
multiple rx buffers, it checks the End of Packet bit of every frame, and
discards it if its not set. This places us in a situation where, if we have a
spanning packet, the first part is discarded, but the second part is not (since
it is the end of packet, and it passes the EOP bit test). If the second part of
the frame is small (4 bytes or less), we subtract 4 from it to remove its crc,
underflow the length, and wind up in skb_over_panic, when we try to skb_put a
huge number of bytes into the skb. This amounts to a remote DOS attack through
careful selection of frame size in relation to interface MTU. The fix for this
is already in the e1000e driver, as well as the e1000 sourceforge driver, but no
one ever pushed it to e1000. This is lifted straight from e1000e, and prevents
small frames from causing the underflow described above
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Tested-by: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add a phy_power_down parameter to forcedeth: set to 1 to power down the
phy and disable the link when an interface goes down; set to 0 to always
leave the phy powered up.
The phy power state persists across reboots; Windows, some BIOSes, and
older versions of Linux don't bother to power up the phy again, forcing
users to remove all power to get the interface working (see
http://bugzilla.kernel.org/show_bug.cgi?id=13072). Leaving the phy
powered on is the safest default behavior. Users accustomed to seeing
the link state reflect the interface state and/or wanting to minimize
power consumption can set phy_power_down=1 if compatibility with other
OSes is not an issue.
Signed-off-by: Ed Swierk <eswierk@aristanetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Several EISA device IDs for 3c509 family network cards are missing from
the driver, making the cards unusable in their EISA mode. Here's a fix to
add them based on the EISA configuration files distributed by 3Com and our
eisa.ids database.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Gary Lin reports that a new device id needs to be added to the atl1e in
order to get some new Asus hardware to work properly.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When the transmit queue gets full we enable interrupts for TX completions
There was a race that we handled the TX queue both from the interrupt context
and from the transmit function. Using "spin_trylock_irq()" ensures this
doesn't happen.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
|
|
http://bugzilla.kernel.org/show_bug.cgi?id=13383
Reported-by: Przemyslaw Kulczycki <azrael@autocom.pl>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
http://bugzilla.kernel.org/show_bug.cgi?id=13312
at76_dwork_hw_scan holds a mutex while calling ieee80211_scan_completed,
which then calls at76_config which needs the same mutex. This reworks
the ordering to not hold the lock while calling ieee80211_scan_completed.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Fix the build for CONFIG_NET_POLL_CONTROLLER that I broke with
217cbfa856dc1cbc2890781626c4032d9e3ec59f ("mac8390: fix regression
caused during net_device_ops conversion").
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Do not call t3_link_fault() under spinlock, as it calls msleep().
Besides, only the access to pi->link_fault needs to be serialized.
Also initialize local variables before checking the link status,
link state fields might otherwise end up containing garbage.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Commit 5e68b772e6efd189d6aca76f6872fb75d51ace60
cxgb3: map entire Rx page, feed map+offset to Rx ring.
introduced a regression on platforms defining DECLARE_PCI_UNMAP_ADDR()
and related macros as no-ops.
Rx descriptors are fed with the a page buffer bus address + page chunk offset.
The page buffer bus address is set and retrieved through
pci_unamp_addr_set(), pci_unmap_addr().
These functions being meaningless on x86 (if CONFIG_DMA_API_DEBUG is not set).
The HW ends up with a bogus bus address.
This patch saves the page buffer bus address for all plaftorms.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The previous commit "convert to net_device_ops" broke the Blackfin MAC
driver as it declared the new structure before the function it used:
CC drivers/net/bfin_mac.o
drivers/net/bfin_mac.c:984: error: ‘bfin_mac_close’ undeclared here (not in a function)
make[1]: *** [drivers/net/bfin_mac.o] Error 1
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Both atl1.c and atl2.c include atlx.h, which defines some modinfo
stuff. But atl2.c seems like it doesn't want the modinfo data
from atlx.h, as it defines its own.
Running modinfo on atl2.ko, we get conflicting information:
$ /sbin/modinfo drivers/net/atlx/atl2.ko | egrep "version|description|author"
version: 2.2.3
description: Atheros Fast Ethernet Network Driver
author: Atheros Corporation <xiong.huang@atheros.com>, Chris Snook <csnook@redhat.com>
version: 2.1.3
author: Xiong Huang <xiong.huang@atheros.com>, Chris Snook <csnook@redhat.com>, Jay Cliburn <jcliburn@gmail.com>
Move the modinfo data out of atlx.h and into atl1.c to eliminate
the confusion:
$ /sbin/modinfo drivers/net/atlx/atl1.ko | egrep "version|description|author"
version: 2.1.3
author: Xiong Huang <xiong.huang@atheros.com>, Chris Snook <csnook@redhat.com>, Jay Cliburn <jcliburn@gmail.com>
description: Atheros L1 Gigabit Ethernet Driver
$ /sbin/modinfo drivers/net/atlx/atl2.ko | egrep "version|description|author"
version: 2.2.3
description: Atheros Fast Ethernet Network Driver
author: Atheros Corporation <xiong.huang@atheros.com>, Chris Snook <csnook@redhat.com>
Reported-by: Scott Scriven <scott.scriven@hp.com>
Signed-off-by: Alex Chiang <achiang@hp.com>
Acked-by: Jay Cliburn <jcliburn@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Gianfar interrupt handler uses IEVENT_ERR_MASK to check and handle errors.
Babbling RX error (IEVENT_BABR) should be included in IEVENT_ERROR_MASK.
Otherwise if BABR is raised, it never gets handled nor cleared, and an
interrupt storm results. This has been observed to happen on sending a
burst of ethernet frames to a gianfar based board.
Signed-off-by: Xiaotian Feng <xiaotian.feng@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax
|
|
The 8169 chip only generates MSI interrupts when all enabled event
sources are quiescent and one or more sources transition to active. If
not all of the active events are acknowledged, or a new event becomes
active while the existing ones are cleared in the handler, we will not
see a new interrupt.
The current interrupt handler masks off the Rx and Tx events once the
NAPI handler has been scheduled, which opens a race window in which we
can get another Rx or Tx event and never ACK'ing it, stopping all
activity until the link is reset (ifconfig down/up). Fix this by always
ACK'ing all event sources, and loop in the handler until we have all
sources quiescent.
Signed-off-by: David Dillow <dave@thedillows.org>
Tested-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Changeset ca17584bf2ad1b1e37a5c0e4386728cc5fc9dabc ("mac8390: update
to net_device_ops") broke mac8390 by adding 8390.o to the link. That
meant that lib8390.c was included twice, once in mac8390.c and once in
8390.c, subject to different macros. This patch reverts that by
avoiding the wrappers in 8390.c. They seem to be of no value since
COMPAT_NET_DEV_OPS is going away soon.
Tested with a Kinetics EtherPort card.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Since commit 0fd56bb5be6455d0d42241e65aed057244665e5e ("gianfar:
Add support for skb recycling"), gianfar puts skbuffs that are in
the rx ring back onto the recycle list as-is in case there was a
receive error, but this breaks the following invariant: that all
skbuffs on the recycle list have skb->data = skb->head + NET_SKB_PAD.
The RXBUF_ALIGNMENT realignment done in gfar_new_skb() will be done
twice on skbuffs recycled in this way, causing there not to be enough
room in the skb anymore to receive a full packet, eventually leading
to an skb_over_panic from gfar_clean_rx_ring() -> skb_put().
Resetting the skb->data pointer to skb->head + NET_SKB_PAD before
putting the skb back onto the recycle list restores the mentioned
invariant, and should fix this issue.
Reported-by: Michael Guntsche <mike@it-loops.com>
Tested-by: Michael Guntsche <mike@it-loops.com>
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
When the i2400m is connected to a network, the host interface (USB)
cannot be suspended. For that to happen, the device has to have
negotiated with the basestation to put the link on IDLE state.
If the host tries to put the device in standby while it is connected
but not idle, the device resets, as the driver should not do that.
To avoid triggering that, when the USB susbsytem requires the driver
to autosuspend the device, the driver checks if the device is not yet
idle. If it is not, the request is rejected (will be retried again
later on after the autosuspend timeout). At some point the device will
enter idle and the request will succeed (unless of course, there is
network traffic, but at that point, there is no idle neither in the
link or the host interface).
Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
|
|
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Do not go beyond ARRAY_SIZE of intf->crypto_stats
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
enable iwl driver to support 5000 ucode having version 2 of API
Signed-off-by: Jay Sternberg <jay.e.sternberg@linux.intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
"airo: airo_get_encode{,ext} potential buffer overflow" was actually a
no-op, due to an unrecognized type overflow in an assignment. Oddly,
gcc only seems to tell me about it when using -Wextra...grrr...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
When the EEPROM contains weird values for the power levels we have to
fix the interpolation process.
Signed-off-by: Fabio Rossi <rossi.f@inwind.it>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Calling cancel_delayed_work() from inside
spin_lock_irqsave, introduces a potential deadlock.
As explained by Johannes Berg <johannes@sipsolutions.net>
A - lock
T - timer
phase CPU 1 CPU 2
---------------------------------------------
some place that calls
cancel_timer_sync()
(which is the | code)
lock-irq(A)
| "lock-irq"(T)
| "unlock"(T)
| wait(T)
unlock(A)
timer softirq
"lock"(T)
run(T)
"unlock"(T)
irq handler
lock(A)
unlock(A)
Now all that again, interleaved, leading to deadlock:
lock-irq(A)
"lock"(T)
run(T)
IRQ during or maybe
before run(T) --> lock(A)
"lock-irq"(T)
wait(T)
We fix this by moving the call to cancel_delayed_work() into workqueue.
There are cases where the work may not actually be queued or running
at the time we are trying to cancel it, but cancel_delayed_work() is
able to deal with this.
Also cleanup iwl_set_mode related to this call. This function
(iwl_set_mode) is only called when bringing interface up and there will
thus not be any scanning done. No need to try to cancel scanning.
Fixes http://bugzilla.kernel.org/show_bug.cgi?id=13224, which was also
reported at http://marc.info/?l=linux-wireless&m=124081921903223&w=2 .
Tested-by: Miles Lane <miles.lane@gmail.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Acked-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Commit e8f055f0c3b ("ath5k: Update reset code") subtly changed the
code that computes floating point values for the PHY3_TIMING register
such that the exponent is off by a decimal point, which can cause
problems with OFDM channel operation.
get_bitmask_order() actually returns the highest bit set plus one,
whereas the previous code wanted the highest bit set. Instead, use
ilog2 which is what this code is really calculating. Also check
coef_scaled to handle the (invalid) case where we need log2(0).
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
AR5K_PHY_PLL_40MHZ_5413 should not be ORed with AR5K_PHY_MODE_RAD_RF5112
for 5 GHz channels.
The incorrect PLL value breaks scanning in the countries where 5 GHz
channels are allowed.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Acked-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
FIFO1_DMA_ERR is set twice, the second should be FIFO2_DMA_ERR.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Ram Vepa <ram.vepa@neterion.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
After 2.6.29, PPC no more admits passing NULL to the dev parameter of
the DMA API. The result is a BUG followed by solid lock-up when the
mv643xx_eth driver brings an interface up. The following patch makes
the driver work on my Pegasos again; it is mostly a search and replace
of NULL by mp->dev->dev.parent in dma allocation/freeing/mapping/unmapping
functions.
Signed-off-by: Gabriel Paubert <paubert@iram.es>
Acked-by: Lennert Buytenhek <buytenh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
One of the purposes of bonding is to allow for redundant links, and failover
correctly if the cable is pulled. If all the members of a bonded device have
no carrier present, the bonded device itself needs to report no carrier present
to user space so management tools (like routing daemons) can respond.
Bonding in 802.3ad mode does not work correctly for this because it incorrectly
chooses a link that is down as a possible aggregator.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax
|
|
Mixing of normal and irq spinlocks results in the following lockdep messages
on bootup on IP32:
[...]
Sending DHCP requests .
======================================================
[ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
2.6.30-rc5-00164-g41baeef #30
------------------------------------------------------
swapper/1 [HC0[0]:SC0[1]:HE0:SE0] is trying to acquire:
(&priv->meth_lock){+.+...}, at: [<ffffffff8026388c>] meth_tx+0x48/0x43c
and this task is already holding:
(_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c
which would create a new lock dependency:
(_xmit_ETHER#2){+.-...} -> (&priv->meth_lock){+.+...}
but this new dependency connects a SOFTIRQ-irq-safe lock:
(_xmit_ETHER#2){+.-...}
... which became SOFTIRQ-irq-safe at:
[<ffffffff80061458>] __lock_acquire+0x784/0x1a14
[<ffffffff800627e0>] lock_acquire+0xf8/0x150
[<ffffffff800128d0>] _spin_lock+0x30/0x44
[<ffffffff802d2b88>] dev_watchdog+0x70/0x398
[<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
[<ffffffff8003da5c>] __do_softirq+0xec/0x208
[<ffffffff8003dbd8>] do_softirq+0x60/0xe4
[<ffffffff8003dda0>] irq_exit+0x54/0x9c
[<ffffffff80004420>] ret_from_irq+0x0/0x4
[<ffffffff80004720>] r4k_wait+0x20/0x40
[<ffffffff80015418>] cpu_idle+0x30/0x60
[<ffffffff804cd934>] start_kernel+0x3ec/0x404
to a SOFTIRQ-irq-unsafe lock:
(&priv->meth_lock){+.+...}
... which became SOFTIRQ-irq-unsafe at:
... [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14
[<ffffffff800627e0>] lock_acquire+0xf8/0x150
[<ffffffff800128d0>] _spin_lock+0x30/0x44
[<ffffffff80263f20>] meth_reset+0x118/0x2d8
[<ffffffff8026424c>] meth_open+0x28/0x140
[<ffffffff802c1ae8>] dev_open+0xe0/0x18c
[<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
[<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
[<ffffffff80012e68>] do_one_initcall+0x58/0x170
[<ffffffff804cd190>] kernel_init+0x98/0x104
[<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
other info that might help us debug this:
2 locks held by swapper/1:
#0: (rcu_read_lock){.+.+..}, at: [<ffffffff802c0954>] dev_queue_xmit+0x1e0/0x4b0
#1: (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c
the SOFTIRQ-irq-safe lock's dependencies:
-> (_xmit_ETHER#2){+.-...} ops: 0 {
HARDIRQ-ON-W at:
[<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14
[<ffffffff800627e0>] lock_acquire+0xf8/0x150
[<ffffffff800128d0>] _spin_lock+0x30/0x44
[<ffffffff802d2b88>] dev_watchdog+0x70/0x398
[<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
[<ffffffff8003da5c>] __do_softirq+0xec/0x208
[<ffffffff8003dbd8>] do_softirq+0x60/0xe4
[<ffffffff8003dda0>] irq_exit+0x54/0x9c
[<ffffffff80004420>] ret_from_irq+0x0/0x4
[<ffffffff80004720>] r4k_wait+0x20/0x40
[<ffffffff80015418>] cpu_idle+0x30/0x60
[<ffffffff804cd934>] start_kernel+0x3ec/0x404
IN-SOFTIRQ-W at:
[<ffffffff80061458>] __lock_acquire+0x784/0x1a14
[<ffffffff800627e0>] lock_acquire+0xf8/0x150
[<ffffffff800128d0>] _spin_lock+0x30/0x44
[<ffffffff802d2b88>] dev_watchdog+0x70/0x398
[<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
[<ffffffff8003da5c>] __do_softirq+0xec/0x208
[<ffffffff8003dbd8>] do_softirq+0x60/0xe4
[<ffffffff8003dda0>] irq_exit+0x54/0x9c
[<ffffffff80004420>] ret_from_irq+0x0/0x4
[<ffffffff80004720>] r4k_wait+0x20/0x40
[<ffffffff80015418>] cpu_idle+0x30/0x60
[<ffffffff804cd934>] start_kernel+0x3ec/0x404
INITIAL USE at:
[<ffffffff80061570>] __lock_acquire+0x89c/0x1a14
[<ffffffff800627e0>] lock_acquire+0xf8/0x150
[<ffffffff800128d0>] _spin_lock+0x30/0x44
[<ffffffff802d2b88>] dev_watchdog+0x70/0x398
[<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
[<ffffffff8003da5c>] __do_softirq+0xec/0x208
[<ffffffff8003dbd8>] do_softirq+0x60/0xe4
[<ffffffff8003dda0>] irq_exit+0x54/0x9c
[<ffffffff80004420>] ret_from_irq+0x0/0x4
[<ffffffff80004720>] r4k_wait+0x20/0x40
[<ffffffff80015418>] cpu_idle+0x30/0x60
[<ffffffff804cd934>] start_kernel+0x3ec/0x404
}
... key at: [<ffffffff80cf93f0>] netdev_xmit_lock_key+0x8/0x1c8
the SOFTIRQ-irq-unsafe lock's dependencies:
-> (&priv->meth_lock){+.+...} ops: 0 {
HARDIRQ-ON-W at:
[<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14
[<ffffffff800627e0>] lock_acquire+0xf8/0x150
[<ffffffff800128d0>] _spin_lock+0x30/0x44
[<ffffffff80263f20>] meth_reset+0x118/0x2d8
[<ffffffff8026424c>] meth_open+0x28/0x140
[<ffffffff802c1ae8>] dev_open+0xe0/0x18c
[<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
[<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
[<ffffffff80012e68>] do_one_initcall+0x58/0x170
[<ffffffff804cd190>] kernel_init+0x98/0x104
[<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
SOFTIRQ-ON-W at:
[<ffffffff800614f8>] __lock_acquire+0x824/0x1a14
[<ffffffff800627e0>] lock_acquire+0xf8/0x150
[<ffffffff800128d0>] _spin_lock+0x30/0x44
[<ffffffff80263f20>] meth_reset+0x118/0x2d8
[<ffffffff8026424c>] meth_open+0x28/0x140
[<ffffffff802c1ae8>] dev_open+0xe0/0x18c
[<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
[<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
[<ffffffff80012e68>] do_one_initcall+0x58/0x170
[<ffffffff804cd190>] kernel_init+0x98/0x104
[<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
INITIAL USE at:
[<ffffffff80061570>] __lock_acquire+0x89c/0x1a14
[<ffffffff800627e0>] lock_acquire+0xf8/0x150
[<ffffffff800128d0>] _spin_lock+0x30/0x44
[<ffffffff80263f20>] meth_reset+0x118/0x2d8
[<ffffffff8026424c>] meth_open+0x28/0x140
[<ffffffff802c1ae8>] dev_open+0xe0/0x18c
[<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
[<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
[<ffffffff80012e68>] do_one_initcall+0x58/0x170
[<ffffffff804cd190>] kernel_init+0x98/0x104
[<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
}
... key at: [<ffffffff80cf6ce8>] __key.32424+0x0/0x8
stack backtrace:
Call Trace:
[<ffffffff8000ed0c>] dump_stack+0x8/0x34
[<ffffffff80060b74>] check_usage+0x470/0x4a0
[<ffffffff80060c34>] check_irq_usage+0x90/0x130
[<ffffffff80061f78>] __lock_acquire+0x12a4/0x1a14
[<ffffffff800627e0>] lock_acquire+0xf8/0x150
[<ffffffff80012a0c>] _spin_lock_irqsave+0x60/0x84
[<ffffffff8026388c>] meth_tx+0x48/0x43c
[<ffffffff802d3a38>] __qdisc_run+0x150/0x30c
[<ffffffff802c0aa8>] dev_queue_xmit+0x334/0x4b0
[<ffffffff804e7e6c>] ip_auto_config+0x8d0/0xf28
[<ffffffff80012e68>] do_one_initcall+0x58/0x170
[<ffffffff804cd190>] kernel_init+0x98/0x104
[<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
..... timed out!
IP-Config: Retrying forever (NFS root)...
Sending DHCP requests ., OK
[...]
Fixed by converting all locks to irq locks.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Tested-by: Andrew Randrianasulu <randrik_a@yahoo.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Napi structures are being created each time we open a port, but when
the port is closed the napi structure is only disabled but not removed.
This bug caused hang while removing the driver.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6:
piix: The Sony TZ90 needs the cable type hardcoding
icside: register second channel of version 6 PCB
ide-tape: remove back-to-back REQUEST_SENSE detection
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6:
ACPI: Idle C-states disabled by max_cstate should not disable the TSC
ACPI: idle: fix init-time TSC check regression
ACPI processor: reset the throttling state once it's invalid
ACPI processor: introduce module parameter processor.ignore_tpc
ACPI, i915: build fix
ACPI: suspend: restore BM_RLD on resume
ACPI: resume: re-enable SCI-enable workaround
thermal: fix off-by-1 error in trip point trigger condition
eeepc-laptop: unregister_rfkill_notifier on failure
asus-laptop: fix input keycode
eeepc-laptop: support for super hybrid engine (SHE)
eeepc-laptop: Work around rfkill firmware bug
eeepc-laptop: report brightness control events via the input layer
eeepc-laptop: fix wlan rfkill state change during init
ACPI: suspend: don't let device _PS3 failure prevent suspend
ACPI: power: update error message
ACPI: video: DMI workaround another broken Acer BIOS enabling display brightness
ACPICA: use acpi.* modparam namespace
ACPI video: dmi check for broken _BQC on Acer Aspire 5720
|
|
The Sony TZ90 needs the cable type hardcoding. See bug #12734
Signed-off-by: Alan Cox <alan@linux.intel.com>
Reported-by: Jonathan E. Snow <jesnow@uh.edu>
[bart: port it from ata_piix to piix and give reporter the proper credit]
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
|
|
The second IDE channel of version 6 PCB is not being registered anymore since
the commit 48c3c1072651922ed153bcf0a33ea82cf20df390 (ide: add struct ide_host
(take 3)).
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
|
|
Impact: fix an oops which always triggers
ide_tape_issue_pc() assumed drive->pc isn't NULL on invocation when
checking for back-to-back request sense issues but drive->pc can be
NULL and even when it's not NULL, it's not safe to dereference it once
the previous command is complete because pc could have been freed or
was on stack. Kill back-to-back REQUEST_SENSE detection.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
|
|
'bugzilla-13121', 'bugzilla-13165', 'bugzilla-13243', 'bugzilla-13259', 'resume-sci-en-regression', 'thermal-regression', 'tsc-regression' and 'asus-2.6.30' into release
|
|
Processor idle power states C2 and C3 stop the TSC on many machines.
Linux recognizes this situation and marks the TSC as unstable:
Marking TSC unstable due to TSC halts in idle
But if those same machines are booted with "processor.max_cstate=1",
then there is no need to validate C2 and C3, and no need to
disable the TSC, which can be reliably used as a clocksource.
Signed-off-by: Len Brown <len.brown@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
|
|
A previous 2.6.30 patch, a71e4917dc0ebbcb5a0ecb7ca3486643c1c9a6e2,
(ACPI: idle: mark_tsc_unstable() at init-time, not run-time)
erroneously disabled the TSC on systems that did not actually
have valid deep C-states.
Move the check after the deep-C-states are validated,
via new helper, tsc_check_state(), hich replaces tsc_halts_in_c().
Signed-off-by: Len Brown <len.brown@intel.com>
Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Frans Pop <elendil@planet.nl>
|
|
If the BIOS hands us an invalid throttling state,
write a valid state.
http://bugzilla.kernel.org/show_bug.cgi?id=13259
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: James Ettle <theholyettlz@googlemail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
Introduce module parameter processor.ignore_tpc.
Some laptops are shipped with buggy _TPC,
this module parameter is used to to disable the buggy support.
http://bugzilla.kernel.org/show_bug.cgi?id=13259
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: James Ettle <theholyettlz@googlemail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
drivers/built-in.o: In function `intel_opregion_init':
(.text+0x9d540): undefined reference to `acpi_video_register'
http://bugzilla.kernel.org/show_bug.cgi?id=13165
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
In 2.6.29,
31878dd86b7df9a147f5e6cc6e07092b4308782b
"ACPI: remove BM_RLD access from idle entry path"
moved BM_RLD initialization to init-time from run time.
But we discovered that some BIOS do not restore BM_RLD
after suspend, causing device errors on C3 and C4
after resume. So now the kernel restores BM_RLD.
http://bugzilla.kernel.org/show_bug.cgi?id=13032
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
The BIOS bug workaround mistakenly got disabled
when we followed the ACPI specification more closely
by ignoring OS updates to that bit.
(The BIOS is supposed to update SCI_EN, not the OS)
http://bugzilla.kernel.org/show_bug.cgi?id=13289
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
PCI MSI: Fix MSI-X with NIU cards
PCI: Fix pci-e port driver slot_reset bad default return value
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel
* 'drm-intel-next' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel:
drm/i915: Add new GET_PIPE_FROM_CRTC_ID ioctl.
drm/i915: Set HDMI hot plug interrupt enable for only the output in question.
drm/i915: Include 965GME pci ID in IS_I965GM(dev) to match UMS.
drm/i915: Use the GM45 VGA hotplug workaround on G45 as well.
drm/i915: ignore LVDS on intel graphics systems that lie about having it
drm/i915: sanity check IER at wait_request time
drm/i915: workaround IGD i2c bus issue in kernel side (v2)
drm/i915: Don't allow binding objects into the last page of the aperture.
drm/i915: save/restore fence registers across suspend/resume
drm/i915: x86 always has writeq. Add I915_READ64 for symmetry.
|
