- 19 May, 2009 2 commits
-
-
David S. Miller authored
Conflicts: drivers/scsi/fcoe/fcoe.c
-
Eric Dumazet authored
gen_estimator can overflow bps (bytes per second) with Gb links, while it was designed with a u32 API, with a theorical limit of 34360Mbit (2^32 bytes) Using 64 bit intermediate avbps/brate counters can allow us to reach this theorical limit. Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
Jarek Poplawski <jarkao2@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 18 May, 2009 38 commits
-
-
Wolfgang Grandegger authored
The patch adds support for the PCI cards: PCIcan and PCIcanx (1, 2 or 4 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:
-
Wolfgang Grandegger authored
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 authored
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:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
Oliver Hartkopp <oliver.hartkopp@volkswagen.de> Signed-off-by:
-
Wolfgang Grandegger authored
This patch adds the generic Socket-CAN driver for the Philips SJA1000 full CAN controller. Signed-off-by:
-
Wolfgang Grandegger authored
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 authored
Signed-off-by:
-
Wolfgang Grandegger authored
This patch documents the CAN netowrk device drivers interface, removes obsolete documentation and adds some useful links to CAN resources. Signed-off-by:
-
Ajit Khaparde authored
Signed-off-by:
Ajit Khaparde <ajitk@serverengines.com> Signed-off-by:
-
Anant Gole authored
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/sprue24aSigned-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:
-
Rami Rosen authored
There is no need for net/icmp.h header in net/ipv4/fib_frontend.c. This patch removes the #include net/icmp.h from it. Signed-off-by:
Rami Rosen <ramirose@gmail.com> Signed-off-by:
-
Rami Rosen authored
Signed-off-by:
-
Eric Dumazet authored
We can update netdev_queue tx_bytes/tx_packets/tx_dropped counters instead of dev->stats ones, to reduce number of cache lines dirtied in xmit path. This fixes a performance problem on SMP when many different cpus take vlan tx path. Signed-off-by:
-
Eric Dumazet authored
offsetof(struct net_device, features)=0x44 offsetof(struct net_device, stats.tx_packets)=0x54 offsetof(struct net_device, stats.tx_bytes)=0x5c offsetof(struct net_device, stats.tx_dropped)=0x6c Network drivers that touch dev->stats.tx_packets/stats.tx_bytes in their tx path can slow down SMP operations, since they dirty a cache line that should stay shared (dev->features is needed in rx and tx paths) We could move away stats field in net_device but it wont help that much. (Two cache lines dirtied in tx path, we can do one only) Better solution is to add tx_packets/tx_bytes/tx_dropped in struct netdev_queue because this structure is already touched in tx path and counters updates will then be free (no increase in size) Signed-off-by:
-
Eric Dumazet authored
It is illegal to dereference a skb after a successful ndo_start_xmit() call. We must store skb length in a local variable instead. Bug was introduced in 2.6.27 by commit 0abf77e5 (net_sched: Add accessor function for packet length for qdiscs) Signed-off-by:
-
Peter P Waskiewicz Jr authored
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:
-
Peter P Waskiewicz Jr authored
This patch adds the generic XAUI device support for 82599 controllers. Signed-off-by:
-
Alexander Duyck authored
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:
-
Ilpo Järvinen authored
Commit 518a09ef (tcp: Fix recvmsg MSG_PEEK influence of blocking behavior) lets the loop run longer than the race check did previously expect, so we need to be more careful with this check and consider the work we have been doing. I tried my best to deal with urg hole madness too which happens here: if (!sock_flag(sk, SOCK_URGINLINE)) { ++*seq; ... by using additional offset by one but I certainly have very little interest in testing that part. Signed-off-by:
Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Tested-by:
Frans Pop <elendil@planet.nl> Tested-by:
Ian Zimmermann <itz@buug.org> Signed-off-by:
-
-
Wang Tinggong authored
Signed-off-by:
Wang Tinggong <wangtinggong@gmail.com> Signed-off-by:
-
roel kluin authored
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:
-
Gabriel Paubert authored
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:
-
Stephen Hemminger authored
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:
-
-
Stephen Hemminger authored
If bridge is configured with no STP and forwarding delay of 0 (which is typical for virtualization) then when link starts it will flood all packets for the first 20 seconds. This bug was introduced by a combination of earlier changes: * forwarding database uses hold time of zero to indicate user wants to always flood packets * optimzation of the case of forwarding delay of 0 avoids the initial timer tick The fix is to just skip all the topology change detection code if kernel STP is not being used. Signed-off-by: -
Stephen Hemminger authored
Currently the bridge catches all STP packets; even if STP is turned off. This prevents other systems (which do have STP turned on) from being able to detect loops in the network. With this patch, if STP is off, then any packet sent to the STP multicast group address is forwarded to all ports. Based on earlier patch by Joakim Tjernlund with changes to go through forwarding (not local chain), and optimization that only last octet needs to be checked. Signed-off-by:
-
Ralf Baechle authored
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:
-
Peter P Waskiewicz Jr authored
When running in DCB mode, switching between link flow control and priority flow control shouldn't need to reset the hardware. This removes that reset. This also extends the set_all() dcbnl callback to return a value indicating that the HW config changed, however a reset was not required. Signed-off-by:
-
Peter P Waskiewicz Jr authored
Ethtool should report that link flow control is disabled when in priority flow control mode. Signed-off-by:
-
Peter P Waskiewicz Jr authored
82599 supports using either link flow control or priority flow control when in DCB mode. The dcbnl interface already supports sending down configurations through rtnetlink that can enable LFC when DCB is enabled, so the driver should take advantage of this. 82598 does not support using LFC when DCB is enabled, so explicitly disable it when we're in DCB mode. This means we always run in PFC mode when DCB is enabled. Signed-off-by:
-
Peter P Waskiewicz Jr authored
This sets the low water threshhold for priority flow control for 82598 and 82599 controllers in DCB mode. Signed-off-by:
-
Yi Zou authored
Enable jumbo frame when FCoE feature is enabled in 82599. Use 3K as the receive queue buffer size for receive queues used by FCoE to address for max Fiber Channel frame size as 2148 bytes (with max 2112 bytes of payload). Signed-off-by:
Yi Zou <yi.zou@intel.com> Signed-off-by:
-
Yi Zou authored
Enable using FCoE redirection table feature in 82599. The FCoE redirection table has maximum of eight entries, corresponding to maximum of eight receive queues to be used for distributing incoming FCoE packets. This patch sets up the FCoE redirection table when multiple receive queues are available for FCoE. Signed-off-by:
-
Yi Zou authored
Add ring feature for FCoE to make use of the FCoE redirection table in 82599. The FCoE redirection table is a receive side scaling feature for Fiber Channel over Ethernet feature in 82599, enabling distributing FCoE packets to different receive queues based on the exchange id. Signed-off-by:
-
Vasu Dev authored
If we can find a type NETDEV_HW_ADDR_T_SAN mac address from the corresponding netdev for a fcoe interface then sets up added the fc->ctlr.spma flag and stores spma mode address in ctl_src_addr. In case the spma flag is set then:- 1. Adds spma mode MAC address in ctl_src_addr as secondary MAC address, the FLOGI for FIP and pre-FIP will go out using this address. 2. Cleans up stored spma MAC address in ctl_src_addr in fcoe_netdev_cleanup. 3. Sets up spma bit in fip_flags for FIP solicitations along with exiting FPMA bit setting. 4. Initialize the FLOGI FIP MAC descriptor to stored spma MAC address in ctl_src_addr. This is used as proposed FCoE MAC address from initiator along with both SPMA and FPMA bit set in FIP solicitation, in response the switch may grant any FPMA or SPMA mode MAC address to initiator. Removes FIP descriptor type checking against ELS type ELS_FLOGI in fcoe_ctlr_encaps to update a FIP MAC descriptor, instead now checks against FIP_DT_FLOGI. I've tested this with available FPMA-only FCoE switch but since data_src_addr is updated using same old code for both FPMA and SPMA modes with FIP or pre-FIP links, so added SPMA mode will work with SPMA-only switch also provided that switch grants a valid MAC address. Signed-off-by:Vasu Dev <vasu.dev@intel.com> Signed-off-by:
-
Vasu Dev authored
Currently fcoe_netdev_config adds netdev pkt handler for fcoe pkts, fcoe_if_create adds netdev pkt handler for fip packets, a secondary MAC address is added by fcoe_netdev_config and then later cleanup for these netdev related config/adds is done only during fcoe_if_destroy and no cleanup done on error during fcoe interface creation after above netdev config calling in fcoe_if_create. So this patch adds single func for above mentioned cleanup the fcoe_netdev_cleanup and then calls this func on either fcoe interface destroy or exiting from fcoe_if_create due to an error after fcoe/fip related above netdev config is done. Moved netdev pkt handler addition code blocks for fip pkts close to similar code block for foce pkt in fcoe_netdev_config, so that added fcoe_netdev_cleanup could be called on error from fcoe_netdev_config to undo these both additions for fcoe/fip pkt handlers. This move required reference to fcoe_fip_recv in fcoe_netdev_config, so moved fip related functions fcoe_fip_recv, fcoe_fip_send and fcoe_update_src_mac above fcoe_netdev_config. This consolidation will enable spma mode support in next patch to easily add or delete spma mode mac address beside fixing current no cleanup issue during error. Signed-off-by:
-
Waskiewicz Jr, Peter P authored
After acquiring the SAN MAC address from the EEPROM, we need to program it into one of the RARs. Also, DCB will use this MAC address to run DCBX commands, so it doesn't have to play musical MAC addresses when things like bonding enter the picture. So we need to return the MAC address through the netlink interface to userspace. This also moves the init_rx_addrs() call out of start_hw() and into reset_hw(). We shouldn't try to read any of the RAR information before initializing our internal accounting of the RAR table, which was what was happening. Signed-off-by:
-
PJ Waskiewicz authored
This patch implements the Storage Address entrypoint from the net device. It will read the SAN MAC addresses from the EEPROM of the 82599 hardware, and make them available to the FCoE stack through the net device. Also, add/del the SAN MAC address to the netdev dev_addr_list via the kernel api dev_addr_add()/dev_addr_del() when there is a valid SAN MAC supported by the HW. Signed-off-by:
-
