1. 08 May, 2012 2 commits
  2. 02 May, 2012 3 commits
  3. 01 May, 2012 2 commits
  4. 30 Apr, 2012 4 commits
  5. 26 Apr, 2012 3 commits
  6. 25 Apr, 2012 2 commits
  7. 24 Apr, 2012 2 commits
    • Jeff Kirsher's avatar
      e1000e: Fix default interrupt throttle rate not set in NIC HW · 727c356f
      Jeff Kirsher authored
      
      
      Based on the original patch from  Ying Cai <ycai@google.com>
      This change ensures that the itr/itr_setting adjustment logic is used,
      even for the default/compiled-in value.
      
      Context:
        When we changed the default InterruptThrottleRate value from default
        (3 = dynamic mode) to 8000 for example, only adapter->itr_setting
        (which controls interrupt coalescing mode) was set to 8000, but
        adapter->itr (which controls the value set in NIC register) was not
        updated accordingly. So from ethtool, it seemed the interrupt
        throttling is enabled at 8000 intr/s, but the NIC actually was
        running in dynamic mode which has lower CPU efficiency especially
        when throughput is not high.
      
      CC: Ying Cai <ycai@google.com>
      CC: David Decotigny <david.decotigny@google.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.kirsher@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      727c356f
    • Prasanna S Panchamukhi's avatar
      e1000e: MSI interrupt test failed, using legacy interrupt · 569a3aff
      Prasanna S Panchamukhi authored
      
      
      Following logs where seen on Systems with multiple NICs,
      while using MSI interrupts as shown below:
      
      Feb 16 15:09:32 (none) user.notice kernel: 0000:00:0d.0: lan0_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:32 (none) user.notice kernel: 0000:40:0d.0: wan0_1: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:32 (none) user.notice kernel: 0000:40:0d.0: lan0_1: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:32 (none) user.warn kernel: 0000:40:0e.0: wan4_0: MSI interrupt
      test failed, using legacy interrupt.
      Feb 16 15:09:32 (none) user.notice kernel: 0000:00:0e.0: wan1_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0e.0: lan1_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0f.0: wan2_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:00:0f.0: lan2_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:40:0a.0: wan3_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:33 (none) user.notice kernel: 0000:40:0a.0: lan3_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0e.0: lan4_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0f.0: wan5_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      Feb 16 15:09:34 (none) user.notice kernel: 0000:40:0f.0: lan5_0: NIC Link is Up
      1000 Mbps Full Duplex, Flow Control: RX/TX
      
      This patch fixes this problem by increasing the msleep from 50 to 100.
      Signed-off-by: default avatarPrasanna S Panchamukhi <ppanchamukhi@riverbed.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      569a3aff
  8. 23 Apr, 2012 2 commits
    • Anatolij Gustschin's avatar
      net/davinci_emac: fix failing PHY connect attempts · 1ab8be4a
      Anatolij Gustschin authored
      
      
      PHY connect attempts fail if no PHY id is specified in the emac platform
      data and another mdio bus has been registered before 'davinci_mdio' bus. In
      this case when configuring the interface, there will be an attempt to
      connect to already attached PHY on the previously registered mdio bus:
      
      net eth1: PHY already attached
      net eth1: could not connect to phy smsc911x-0:01
      IP-Config: Failed to open eth1
      IP-Config: Device `eth1' not found
      
      Fix this by modifying match_first_device() to match first PHY device
      on 'davinci_mdio' bus.
      Signed-off-by: default avatarAnatolij Gustschin <agust@denx.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ab8be4a
    • Thadeu Lima de Souza Cascardo's avatar
      ehea: only register irq after setting up ports · c2f1244b
      Thadeu Lima de Souza Cascardo authored
      
      
      If we receive an interrupt too early before we set up ports in the probe
      function, there won't be any port ready to handle it.
      
      Only registering the irq after the ports are setup fixes the problem,
      and works fine without losing any interrupts.
      
      This causes crashes in some situations:
      
      [c000000f7ff7fd60] d000000008e223f0 .ehea_neq_tasklet+0x78/0x148 [ehea]
      [c000000f7ff7fe00] c0000000000b6cac .tasklet_hi_action+0xdc/0x210
      [c000000f7ff7fea0] c0000000000b7cc8 .__do_softirq+0x178/0x300
      [c000000f7ff7ff90] c000000000022694 .call_do_softirq+0x14/0x24
      [c000000f68ee7900] c000000000010e04 .do_softirq+0xec/0x110
      [c000000f68ee79a0] c0000000000b789c .irq_exit+0xac/0xe0
      [c000000f68ee7a20] c0000000000110bc .do_IRQ+0x114/0x2a8
      [c000000f68ee7ae0] c00000000000553c hardware_interrupt_entry+0x18/0x1c
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c2f1244b
  9. 21 Apr, 2012 3 commits
    • Lee Jones's avatar
      drivers/net: Do not free an IRQ if its request failed · 163faf31
      Lee Jones authored
      
      
      Refrain from attempting to free an interrupt line if the request
      fails and hence, there is no IRQ to free.
      
      CC: netdev@vger.kernel.org
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      163faf31
    • Matt Renzelmann's avatar
      ks8851: Fix request_irq/free_irq mismatch · e8195b24
      Matt Renzelmann authored
      
      
      The dev_id parameter passed to free_irq needs to match the one passed
      to the corresponding request_irq.
      Signed-off-by: default avatarMatt Renzelmann <mjr@cs.wisc.edu>
      Acked-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e8195b24
    • Stephen Boyd's avatar
      ks8851: Fix mutex deadlock in ks8851_net_stop() · c5a99937
      Stephen Boyd authored
      
      
      There is a potential deadlock scenario when the ks8851 driver
      is removed. The interrupt handler schedules a workqueue which
      acquires a mutex that ks8851_net_stop() also acquires before
      flushing the workqueue. Previously lockdep wouldn't be able
      to find this problem but now that it has the support we can
      trigger this lockdep warning by rmmoding the driver after
      an ifconfig up.
      
      Fix the possible deadlock by disabling the interrupts in
      the chip and then release the lock across the workqueue
      flushing. The mutex is only there to proect the registers
      anyway so this should be ok.
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      3.0.21-00021-g8b33780-dirty #2911
      -------------------------------------------------------
      rmmod/125 is trying to acquire lock:
       ((&ks->irq_work)){+.+...}, at: [<c019e0b8>] flush_work+0x0/0xac
      
      but task is already holding lock:
       (&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&ks->lock){+.+...}:
             [<c01b89c8>] __lock_acquire+0x940/0x9f8
             [<c01b9058>] lock_acquire+0x10c/0x130
             [<c083dbec>] mutex_lock_nested+0x68/0x3dc
             [<bf00bd48>] ks8851_irq_work+0x24/0x46c [ks8851]
             [<c019c580>] process_one_work+0x2d8/0x518
             [<c019cb98>] worker_thread+0x220/0x3a0
             [<c01a2ad4>] kthread+0x88/0x94
             [<c0107008>] kernel_thread_exit+0x0/0x8
      
      -> #0 ((&ks->irq_work)){+.+...}:
             [<c01b7984>] validate_chain+0x914/0x1018
             [<c01b89c8>] __lock_acquire+0x940/0x9f8
             [<c01b9058>] lock_acquire+0x10c/0x130
             [<c019e104>] flush_work+0x4c/0xac
             [<bf00b858>] ks8851_net_stop+0x6c/0x138 [ks8851]
             [<c06b209c>] __dev_close_many+0x98/0xcc
             [<c06b2174>] dev_close_many+0x68/0xd0
             [<c06b22ec>] rollback_registered_many+0xcc/0x2b8
             [<c06b2554>] rollback_registered+0x28/0x34
             [<c06b25b8>] unregister_netdevice_queue+0x58/0x7c
             [<c06b25f4>] unregister_netdev+0x18/0x20
             [<bf00c1f4>] ks8851_remove+0x64/0xb4 [ks8851]
             [<c049ddf0>] spi_drv_remove+0x18/0x1c
             [<c0468e98>] __device_release_driver+0x7c/0xbc
             [<c0468f64>] driver_detach+0x8c/0xb4
             [<c0467f00>] bus_remove_driver+0xb8/0xe8
             [<c01c1d20>] sys_delete_module+0x1e8/0x27c
             [<c0105ec0>] ret_fast_syscall+0x0/0x3c
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&ks->lock);
                                     lock((&ks->irq_work));
                                     lock(&ks->lock);
        lock((&ks->irq_work));
      
       *** DEADLOCK ***
      
      4 locks held by rmmod/125:
       #0:  (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f44>] driver_detach+0x6c/0xb4
       #1:  (&__lockdep_no_validate__){+.+.+.}, at: [<c0468f50>] driver_detach+0x78/0xb4
       #2:  (rtnl_mutex){+.+.+.}, at: [<c06b25e8>] unregister_netdev+0xc/0x20
       #3:  (&ks->lock){+.+...}, at: [<bf00b850>] ks8851_net_stop+0x64/0x138 [ks8851]
      
      Cc: Ben Dooks <ben-linux@fluff.org>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5a99937
  10. 19 Apr, 2012 2 commits
  11. 17 Apr, 2012 3 commits
  12. 14 Apr, 2012 3 commits
  13. 13 Apr, 2012 5 commits
  14. 05 Apr, 2012 1 commit
    • Stephen Boyd's avatar
      simple_open: automatically convert to simple_open() · 234e3405
      Stephen Boyd authored
      
      
      Many users of debugfs copy the implementation of default_open() when
      they want to support a custom read/write function op.  This leads to a
      proliferation of the default_open() implementation across the entire
      tree.
      
      Now that the common implementation has been consolidated into libfs we
      can replace all the users of this function with simple_open().
      
      This replacement was done with the following semantic patch:
      
      <smpl>
      @ open @
      identifier open_f != simple_open;
      identifier i, f;
      @@
      -int open_f(struct inode *i, struct file *f)
      -{
      (
      -if (i->i_private)
      -f->private_data = i->i_private;
      |
      -f->private_data = i->i_private;
      )
      -return 0;
      -}
      
      @ has_open depends on open @
      identifier fops;
      identifier open.open_f;
      @@
      struct file_operations fops = {
      ...
      -.open = open_f,
      +.open = simple_open,
      ...
      };
      </smpl>
      
      [akpm@linux-foundation.org: checkpatch fixes]
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Julia Lawall <Julia.Lawall@lip6.fr>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      234e3405
  15. 04 Apr, 2012 3 commits
    • Thadeu Lima de Souza Cascardo's avatar
      mlx4: allocate just enough pages instead of always 4 pages · 117980c4
      Thadeu Lima de Souza Cascardo authored
      
      
      The driver uses a 2-order allocation, which is too much on architectures
      like ppc64, which has a 64KiB page. This particular allocation is used
      for large packet fragments that may have a size of 512, 1024, 4096 or
      fill the whole allocation. So, a minimum size of 16384 is good enough
      and will be the same size that is used in architectures of 4KiB sized
      pages.
      
      This will avoid allocation failures that we see when the system is under
      stress, but still has plenty of memory, like the one below.
      
      This will also allow us to set the interface MTU to higher values like
      9000, which was not possible on ppc64 without this patch.
      
      Node 1 DMA: 737*64kB 37*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 51904kB
      83137 total pagecache pages
      0 pages in swap cache
      Swap cache stats: add 0, delete 0, find 0/0
      Free swap  = 10420096kB
      Total swap = 10420096kB
      107776 pages RAM
      1184 pages reserved
      147343 pages shared
      28152 pages non-shared
      netstat: page allocation failure. order:2, mode:0x4020
      Call Trace:
      [c0000001a4fa3770] [c000000000012f04] .show_stack+0x74/0x1c0 (unreliable)
      [c0000001a4fa3820] [c00000000016af38] .__alloc_pages_nodemask+0x618/0x930
      [c0000001a4fa39a0] [c0000000001a71a0] .alloc_pages_current+0xb0/0x170
      [c0000001a4fa3a40] [d00000000dcc3e00] .mlx4_en_alloc_frag+0x200/0x240 [mlx4_en]
      [c0000001a4fa3b10] [d00000000dcc3f8c] .mlx4_en_complete_rx_desc+0x14c/0x250 [mlx4_en]
      [c0000001a4fa3be0] [d00000000dcc4eec] .mlx4_en_process_rx_cq+0x62c/0x850 [mlx4_en]
      [c0000001a4fa3d20] [d00000000dcc5150] .mlx4_en_poll_rx_cq+0x40/0x90 [mlx4_en]
      [c0000001a4fa3dc0] [c0000000004e2bb8] .net_rx_action+0x178/0x450
      [c0000001a4fa3eb0] [c00000000009c9b8] .__do_softirq+0x118/0x290
      [c0000001a4fa3f90] [c000000000031df8] .call_do_softirq+0x14/0x24
      [c000000184c3b520] [c00000000000e700] .do_softirq+0xf0/0x110
      [c000000184c3b5c0] [c00000000009c6d4] .irq_exit+0xb4/0xc0
      [c000000184c3b640] [c00000000000e964] .do_IRQ+0x144/0x230
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Signed-off-by: default avatarKleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
      Tested-by: default avatarKleber Sacilotto de Souza <klebers@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      117980c4
    • Marc Kleine-Budde's avatar
      stmmac: re-add IFF_UNICAST_FLT for dwmac1000 · 03f2eecd
      Marc Kleine-Budde authored
      In commit (bfab27a1
      
       stmmac: add the experimental PCI support) the
      IFF_UNICAST_FLT flag has been removed from the stmmac_mac_device_setup()
      function. This patch re-adds the flag.
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Acked-by: default avatarGiuseppe Cavallaro <peppe.cavallaro@st.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      03f2eecd
    • Yaniv Rosner's avatar
      bnx2x: Clear MDC/MDIO warning message · ca7b91bb
      Yaniv Rosner authored
      
      
      This patch clears a warning message of "MDC/MDIO access timeout" which may
      appear when interface is loaded due to missing clock setting before resetting
      the LED, and starting periodic function too early.
      Signed-off-by: default avatarYaniv Rosner <yanivr@broadcom.com>
      Signed-off-by: default avatarEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ca7b91bb