| Age | Commit message (Collapse) | Author |
|---|
|
Drop test for FW_STATE_RESET in p54spi_work as fw_state
is never assigned this value.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Process beacon change even if the BSSID doesn't
change at the same time. Also fix what I think
is a small locking error in b43legacy, there's
a spin_unlock_irqrestore that looks out of place.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Under high load first data word, read after available data size
is sometimes lost in p54spi_rx. It seems to depend on frequency
of interrupts and latency of data read request relatively to
'data available' interrupt. The worst consequence of this bug
is loss of packet transmission acknowledgement, which in turn
causes overflow of tx queues and permanent link loss.
Read data size and first data word in one SPI transaction.
No packets from LMAC should have length less than 1 word,
so this shouldn't interfere with the next read transaction.
Also call p54spi_sleep if p54spi_wake succeeded.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Put chip into sleep state, once it's been awaken.
Also, propagate error code to the caller.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Return whether wakeup operation succeeded.
Make use of this return value.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
interrupt status read
When SPI write of odd length is requested, p54spi_write splits it
into two parts: one for all data, except the last byte, and one
for last byte and padding byte. Unfortunately, the length of
first part is not amended. It works because all meaningful bytes
have proper value and the last byte of odd length SPI write
transaction is ignored.
p54spi_work has dummy HOST_INTERRUPTS register read at the end.
Drop it, as its result is not used and it has no side effects.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Host is not allowed to modify DMA_WRITE_CTRL register
if bit HOST_ALLOWED in it is not set. Wait for HOST_ALLOWED first.
Also get rid of timeout in p54spi_wait_bit as it's been playing
a role of workaround for such an incorrect register access.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Eliminate direct accesses to the driver_data field.
cf 82ab13b26f15f49be45f15ccc96bfa0b81dfd015
The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
struct device *dev;
expression E;
type T;
@@
- dev->driver_data = (T)E
+ dev_set_drvdata(dev, E)
@@
struct device *dev;
type T;
@@
- (T)dev->driver_data
+ dev_get_drvdata(dev)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch is one of the incremental steps for unifying iwl_station_entry
for all HWs, i.e. removing of iwl3945_station_entry
This patch drops iwl3945_tid_data and use iwl_tid_data instead.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch replaces struct iwl3945_hw_key by struct iwl_hw_key.
It's not used directly with any host command therefore removal is trivial
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This removes unnecessary MMIO accesses in the interrupt hotpath. The
patch by Michael Buesch for b43 has been ported to b43legacy.
Signed-off-by: Stefano Brivio <stefano.brivio@polimi.it>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This patch configures the beacon timers with beacon interval
and beacon period passed through vif.bss_conf. Also cache the
currecnt beacon configuration which will be used to configure
the beacon timers when the driver triggers it after reset.
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The previous implementation was moving back to NETWORK SLEEP state
immediately after receiving a Beacon frame. This means that we are
unlikely to receive all the buffered broadcast/multicast frames that
would be sent after DTIM Beacon frames. Fix this by parsing the Beacon
frame and remaining awake, if needed, to receive the buffered
broadcast/multicast frames. The last buffered frame will trigger the
move back into NETWORK SLEEP state.
If the last broadcast/multicast frame is not received properly (or if
the AP fails to send it), the next Beacon frame will work as a backup
trigger for returning into NETWORK SLEEP.
A new debug type, PS (debug=0x800 module parameter), is added to make
it easier to debug potential power save issues in the
future. Currently, this is only used for the Beacon frame and buffered
broadcast/multicast receiving.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This makes use of the local fc variable in bit more places and uses a
common helper macro. The part of RX process that delivers skb's to
mac80211 is moved to a separate function in preparation for future
changes that will need to do this from two places. The modifications
here should not result in any functional changes.
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The broadcast bit is in the first, not the last octet..
Signed-off-by: Jouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
According to my tests, all that ZD_CS_MULTICAST does is to
disable retrying/waiting for an ACK. Reflect this by renaming
the bit to ZD_CS_NO_ACK and setting it based on
IEEE80211_TX_CTL_NO_ACK, instead of is_multicast_ether_addr.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This is more consistent with our nl80211 naming convention
for HT40-/+.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
We are not correctly listening to the regulatory max bandwidth
settings. To actually make use of it we need to redesign things
a bit. This patch does the work for that. We do this to so we
can obey to regulatory rules accordingly for use of HT40.
We end up dealing with HT40 by having two passes for each channel.
The first check will see if a 20 MHz channel fits into the channel's
center freq on a given frequency range. We check for a 20 MHz
banwidth channel as that is the maximum an individual channel
will use, at least for now. The first pass will go ahead and
check if the regulatory rule for that given center of frequency
allows 40 MHz bandwidths and we use this to determine whether
or not the channel supports HT40 or not. So to support HT40 you'll
need at a regulatory rule that allows you to use 40 MHz channels
but you're channel must also be enabled and support 20 MHz by itself.
The second pass is done after we do the regulatory checks over
an device's supported channel list. On each channel we'll check
if the control channel and the extension both:
o exist
o are enabled
o regulatory allows 40 MHz bandwidth on its frequency range
This work allows allows us to idependently check for HT40- and
HT40+.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
GRO/LRO can be controlled through ethtool so this is unnecessary.
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Update myri10ge driver version to 1.5.0-1.415.
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Allow myri10ge LRO to be enabled/disabled via ethtool
(and by the stack for packet forwarding).
Signed-off-by: Brice Goglin <brice@myri.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This is purely a cleanup patch. This collapses some of the code required
when we configure our Tx and Rx feature sets, and makes the code more
readable and maintainable.
Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
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>
|
|
The SFF specification for Direct Attach cable detection has now been
ratified. Previously, DA cable detect was looking at the Twinaxial bit in
byte 9 of the SFP+ EEPROM. The spec now defines active and passive DA
cables in byte 8 of the SFP+ EEPROM. This patch changes the cable
detection for both 82598 and 82599 SFP+ adapters to conform to the new
spec.
Signed-off-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>
|
|
The SFP+ NIC (device id 0x10fb) needs a semaphore to serialize
PHY access, so our PHY init code must honor that same semaphore.
Signed-off-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>
|
|
Due to mostly historic reasons, including a lack of reliability
of the link handling (especially with the older 8169), the
current r8169 driver emulates forced mode setting by limiting
the advertised modes.
With this change the driver allows real 10/100 forced mode
settings on the 8169 and 8101/8102.
Original idea by Vincent Steenhoute. The RTL_GIGA_MAC_VER_03
tweak was extracted from Realtek's r8169 v6.010.00 driver.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Tested-by: Jean Delvare <jdelvare@suse.de>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Jarek pointed pppoe can call back dev_queue_xmit(), and might need
skb->dst, so its safer to unset IFF_XMIT_DST_RELEASE on ppp devices.
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
One point of contention in high network loads is the dst_release() performed
when a transmited skb is freed. This is because NIC tx completion calls
dev_kree_skb() long after original call to dev_queue_xmit(skb).
CPU cache is cold and the atomic op in dst_release() stalls. On SMP, this is
quite visible if one CPU is 100% handling softirqs for a network device,
since dst_clone() is done by other cpus, involving cache line ping pongs.
It seems right place to release dst is in dev_hard_start_xmit(), for most
devices but ones that are virtual, and some exceptions.
David Miller suggested to define a new device flag, set in alloc_netdev_mq()
(so that most devices set it at init time), and carefuly unset in devices
which dont want a NULL skb->dst in their ndo_start_xmit().
List of devices that must clear this flag is :
- loopback device, because it calls netif_rx() and quoting Patrick :
"ip_route_input() doesn't accept loopback addresses, so loopback packets
already need to have a dst_entry attached."
- appletalk/ipddp.c : needs skb->dst in its xmit function
- And all devices that call again dev_queue_xmit() from their xmit function
(as some classifiers need skb->dst) : bonding, vlan, macvlan, eql, ifb, hdlc_fr
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Sysfs files for a network device can not unconditionally take the
rtnl_lock as the bonding sysfs files do. If someone accesses those
sysfs files while the network device is being unregistered with the
rtnl_lock held we will deadlock.
So use trylock and restart_syscall to avoid this problem.
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Network device sysfs files that grab the rtnl_lock unconditionally
will deadlock if accessed when the network device is being
unregistered. So use trylock and syscall_restart to avoid this
deadlock.
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The pdev->irq was not saved in netxen_adapter, causing request_irq()
with invalid irq number.
This was broken in commit be339aee634d5cb98a8df8d6febe04002ec497f3
("netxen: fix irq tear down and msix leak.").
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
Conflicts:
drivers/scsi/fcoe/fcoe.c
|
|
channel) from Kvaser (http://www.kvaser.com).
Signed-off-by: Per Dalen <per.dalen@cnw.se>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The patch adds support for the one or two channel CPC-PCI and CPC-PCIe
cards from EMS Dr. Thomas Wuensche (http://www.ems-wuensche.de).
Signed-off-by: Sebastian Haas <haas@ems-wuensche.com>
Signed-off-by: Markus Plessing <plessing@ems-wuensche.com>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This driver adds support for the SJA1000 chips connected to the
"platform bus", which can be found on various embedded systems.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This patch adds the generic Socket-CAN driver for the Philips SJA1000
full CAN controller.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The CAN network device driver interface provides a generic interface to
setup, configure and monitor CAN network devices. It exports a set of
common data structures and functions, which all real CAN network device
drivers should use. Please have a look to the SJA1000 or MSCAN driver
to understand how to use them. The name of the module is can-dev.ko.
Furthermore, it adds a Netlink interface allowing to configure the CAN
device using the program "ip" from the iproute2 utility suite.
For further information please check "Documentation/networking/can.txt"
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add support for TI DaVinci EMAC driver.
TI DaVinci Ethernet Media Access Controller module is based upon
TI CPPI 3.0 DMA engine and supports 10/100 Mbps on all and Gigabit modes on
some TI devices. It supports MII/RMII and has up to 8Kbytes of internal
descriptor memory. This driver has been working on several TI devices including
DM644x, DM646x and DA830 platforms. The specs of this device are available at:
http://www.ti.com/litv/pdf/sprue24a
Signed-off-by: Anant Gole <anantgole@ti.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Chaithrika U S <chaithrika@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Marching along, let's bump the version number to indicate things actually
have happened to the driver.
Signed-off-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>
|
|
This patch adds the generic XAUI device support for 82599 controllers.
Signed-off-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>
|
|
The performance of hardware RSC is greatly reduced if the total for max rsc
descriptors multiplied by the buffer size is greater than 65535. To
prevent this we need to adjust the max rsc descriptors appropriately.
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>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
|
|
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>
|
