An error occurred fetching the project authors.
  1. 27 Feb, 2018 4 commits
  2. 22 Feb, 2018 3 commits
  3. 21 Feb, 2018 6 commits
  4. 20 Feb, 2018 2 commits
  5. 14 Feb, 2018 5 commits
  6. 09 Feb, 2018 2 commits
  7. 08 Feb, 2018 3 commits
  8. 06 Feb, 2018 1 commit
  9. 01 Feb, 2018 1 commit
  10. 29 Jan, 2018 1 commit
    • Thomas Falcon's avatar
      ibmvnic: Wait for device response when changing MAC · f813614f
      Thomas Falcon authored
      Wait for a response from the VNIC server before exiting after setting
      the MAC address. The resolves an issue with bonding a VNIC client in
      ALB or TLB modes. The bonding driver was changing the MAC address more
      rapidly than the device could respond, causing the following errors.
      
      "bond0: the hw address of slave eth2 is in use by the bond;
      couldn't find a slave with a free hw address to give it
      (this should not have happened)"
      
      If the function waits until the change is finalized, these errors are
      avoided.
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f813614f
  11. 22 Jan, 2018 3 commits
  12. 19 Jan, 2018 2 commits
  13. 16 Jan, 2018 1 commit
    • Thomas Falcon's avatar
      ibmvnic: Fix pending MAC address changes · 3d166130
      Thomas Falcon authored
      Due to architecture limitations, the IBM VNIC client driver is unable
      to perform MAC address changes unless the device has "logged in" to
      its backing device. Currently, pending MAC changes are handled before
      login, resulting in an error and failure to change the MAC address.
      Moving that chunk to the end of the ibmvnic_login function, when we are
      sure that it was successful, fixes that.
      
      The MAC address can be changed when the device is up or down, so
      only check if the device is in a "PROBED" state before setting the
      MAC address.
      
      Fixes: c26eba03 ("ibmvnic: Update reset infrastructure to support tunable parameters")
      Signed-off-by: default avatarThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Reviewed-by: default avatarJohn Allen <jallen@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3d166130
  14. 11 Jan, 2018 1 commit
    • Nathan Fontenot's avatar
      ibmvnic: Don't handle RX interrupts when not up. · 09fb35ea
      Nathan Fontenot authored
      Initiating a kdump via the command line can cause a pending interrupt
      to be handled by the ibmvnic driver when initializing the sub-CRQ
      irqs during driver initialization.
      
      NIP [d000000000ca34f0] ibmvnic_interrupt_rx+0x40/0xd0 [ibmvnic]
      LR [c000000008132ef0] __handle_irq_event_percpu+0xa0/0x2f0
      Call Trace:
      [c000000047fcfde0] [c000000008132ef0] __handle_irq_event_percpu+0xa0/0x2f0
      [c000000047fcfea0] [c00000000813317c] handle_irq_event_percpu+0x3c/0x90
      [c000000047fcfee0] [c00000000813323c] handle_irq_event+0x6c/0xd0
      [c000000047fcff10] [c0000000081385e0] handle_fasteoi_irq+0xf0/0x250
      [c000000047fcff40] [c0000000081320a0] generic_handle_irq+0x50/0x80
      [c000000047fcff60] [c000000008014984] __do_irq+0x84/0x1d0
      [c000000047fcff90] [c000000008027564] call_do_irq+0x14/0x24
      [c00000003c92af00] [c000000008014b70] do_IRQ+0xa0/0x120
      [c00000003c92af50] [c000000008002594] hardware_interrupt_common+0x114/0x180
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      09fb35ea
  15. 09 Jan, 2018 1 commit
  16. 19 Dec, 2017 2 commits
  17. 18 Nov, 2017 1 commit
  18. 14 Nov, 2017 1 commit