Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 22 5月, 2009 1 次提交
  3. 21 5月, 2009 4 次提交
  5. 20 5月, 2009 9 次提交
  7. 19 5月, 2009 13 次提交
  9. 18 5月, 2009 13 次提交
    • R
      Neterion: *FIFO1_DMA_ERR set twice, should 2nd be *FIFO2_DMA_ERR? · d77dd8d2
      由 roel kluin 提交于 
      FIFO1_DMA_ERR is set twice, the second should be FIFO2_DMA_ERR.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Acked-by: NRam Vepa <ram.vepa@neterion.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d77dd8d2
    • G
      mv643xx_eth: fix PPC DMA breakage · eb0519b5
      由 Gabriel Paubert 提交于 
      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: NGabriel Paubert <paubert@iram.es>
Acked-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eb0519b5
    • S
      bonding: fix link down handling in 802.3ad mode · 4cd6fe1c
      由 Stephen Hemminger 提交于 
      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: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4cd6fe1c
    • R
      NET: Meth: Fix unsafe mix of irq and non-irq spinlocks. · a8f492c6
      由 Ralf Baechle 提交于 
      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: NRalf Baechle <ralf@linux-mips.org>
Tested-by: NAndrew Randrianasulu <randrik_a@yahoo.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8f492c6
    • P
      ixgbe: Don't reset the hardware when switching between LFC and PFC · 62551d3e
      由 Peter P Waskiewicz Jr 提交于 
      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: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      62551d3e
    • P
      ixgbe: When in DCB mode with PFC enabled, show LFC is disabled · 8756924c
      由 Peter P Waskiewicz Jr 提交于 
      Ethtool should report that link flow control is disabled when in priority
flow control mode.
Signed-off-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8756924c
    • P
      ixgbe: Allow link flow control in DCB mode for 82599 adapters · 264857b8
      由 Peter P Waskiewicz Jr 提交于 
      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: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      264857b8
    • P
      ixgbe: Set Priority Flow Control low water threshhold for DCB · 70b77628
      由 Peter P Waskiewicz Jr 提交于 
      This sets the low water threshhold for priority flow control for 82598
and 82599 controllers in DCB mode.
Signed-off-by: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      70b77628
    • Y
      ixgbe: Enable jumbo frame for FCoE feature in 82599 · 63f39bd1
      由 Yi Zou 提交于 
      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: NYi Zou <yi.zou@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      63f39bd1
    • Y
      ixgbe: Enable FCoE redirection table feature in 82599 · 29ebf6f8
      由 Yi Zou 提交于 
      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: NYi Zou <yi.zou@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      29ebf6f8
    • Y
      ixgbe: Add RING_F_FCOE for FCoE feature in 82599 · 0331a832
      由 Yi Zou 提交于 
      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: NYi Zou <yi.zou@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0331a832
    • W
      ixgbe: Add SAN MAC address to the RAR, return the address to DCB · aca6bee7
      由 Waskiewicz Jr, Peter P 提交于 
      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: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      aca6bee7
    • P
      ixgbe: Add FCoE Storage MAC Address support · 0365e6e4
      由 PJ Waskiewicz 提交于 
      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: NPeter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0365e6e4