1. 25 2月, 2016 1 次提交
  2. 16 2月, 2016 2 次提交
  3. 13 12月, 2015 1 次提交
    • J
      igb: don't unmap NULL hw_addr · 73bf8048
      Jarod Wilson 提交于
      I've got a startech thunderbolt dock someone loaned me, which among other
      things, has the following device in it:
      
      08:00.0 Ethernet controller: Intel Corporation I210 Gigabit Network Connection (rev 03)
      
      This hotplugs just fine (kernel 4.2.0 plus a patch or two here):
      
      [  863.020315] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.2.18-k
      [  863.020316] igb: Copyright (c) 2007-2014 Intel Corporation.
      [  863.028657] igb 0000:08:00.0: enabling device (0000 -> 0002)
      [  863.062089] igb 0000:08:00.0: added PHC on eth0
      [  863.062090] igb 0000:08:00.0: Intel(R) Gigabit Ethernet Network Connection
      [  863.062091] igb 0000:08:00.0: eth0: (PCIe:2.5Gb/s:Width x1) e8:ea:6a:00:1b:2a
      [  863.062194] igb 0000:08:00.0: eth0: PBA No: 000200-000
      [  863.062196] igb 0000:08:00.0: Using MSI-X interrupts. 4 rx queue(s), 4 tx queue(s)
      [  863.064889] igb 0000:08:00.0 enp8s0: renamed from eth0
      
      But disconnecting it is another story:
      
      [ 1002.807932] igb 0000:08:00.0: removed PHC on enp8s0
      [ 1002.807944] igb 0000:08:00.0 enp8s0: PCIe link lost, device now detached
      [ 1003.341141] ------------[ cut here ]------------
      [ 1003.341148] WARNING: CPU: 0 PID: 199 at lib/iomap.c:43 bad_io_access+0x38/0x40()
      [ 1003.341149] Bad IO access at port 0x0 ()
      [ 1003.342767] Modules linked in: snd_usb_audio snd_usbmidi_lib snd_rawmidi igb dca firewire_ohci firewire_core crc_itu_t rfcomm ctr ccm arc4 iwlmvm mac80211 fuse xt_CHECKSUM ipt_MASQUERADE
      nf_nat_masquerade_ipv4 tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat
      nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
      nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter bnep dm_mirror dm_region_hash dm_log dm_mod coretemp x86_pkg_temp_thermal intel_powerclamp kvm_intel snd_hda_codec_hdmi kvm
      crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drbg
      [ 1003.342793]  ansi_cprng aesni_intel hp_wmi aes_x86_64 iTCO_wdt lrw iTCO_vendor_support ppdev gf128mul sparse_keymap glue_helper ablk_helper cryptd snd_hda_codec_realtek snd_hda_codec_generic
      microcode snd_hda_intel uvcvideo iwlwifi snd_hda_codec videobuf2_vmalloc videobuf2_memops snd_hda_core videobuf2_core snd_hwdep btusb v4l2_common btrtl snd_seq btbcm btintel videodev cfg80211
      snd_seq_device rtsx_pci_ms bluetooth pcspkr input_leds i2c_i801 media parport_pc memstick rfkill sg lpc_ich snd_pcm 8250_fintek parport joydev snd_timer snd soundcore hp_accel ie31200_edac
      mei_me lis3lv02d edac_core input_polldev mei hp_wireless shpchp tpm_infineon sch_fq_codel nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables autofs4 xfs libcrc32c sd_mod sr_mod cdrom
      rtsx_pci_sdmmc mmc_core crc32c_intel serio_raw rtsx_pci
      [ 1003.342822]  nouveau ahci libahci mxm_wmi e1000e xhci_pci hwmon ptp drm_kms_helper pps_core xhci_hcd ttm wmi video ipv6
      [ 1003.342839] CPU: 0 PID: 199 Comm: kworker/0:2 Not tainted 4.2.0-2.el7_UNSUPPORTED.x86_64 #1
      [ 1003.342840] Hardware name: Hewlett-Packard HP ZBook 15 G2/2253, BIOS M70 Ver. 01.07 02/26/2015
      [ 1003.342843] Workqueue: pciehp-3 pciehp_power_thread
      [ 1003.342844]  ffffffff81a90655 ffff8804866d3b48 ffffffff8164763a 0000000000000000
      [ 1003.342846]  ffff8804866d3b98 ffff8804866d3b88 ffffffff8107134a ffff8804866d3b88
      [ 1003.342847]  ffff880486f46000 ffff88046c8a8000 ffff880486f46840 ffff88046c8a8098
      [ 1003.342848] Call Trace:
      [ 1003.342852]  [<ffffffff8164763a>] dump_stack+0x45/0x57
      [ 1003.342855]  [<ffffffff8107134a>] warn_slowpath_common+0x8a/0xc0
      [ 1003.342857]  [<ffffffff810713c6>] warn_slowpath_fmt+0x46/0x50
      [ 1003.342859]  [<ffffffff8133719e>] ? pci_disable_msix+0x3e/0x50
      [ 1003.342860]  [<ffffffff812f6328>] bad_io_access+0x38/0x40
      [ 1003.342861]  [<ffffffff812f6567>] pci_iounmap+0x27/0x40
      [ 1003.342865]  [<ffffffffa0b728d7>] igb_remove+0xc7/0x160 [igb]
      [ 1003.342867]  [<ffffffff8132189f>] pci_device_remove+0x3f/0xc0
      [ 1003.342869]  [<ffffffff81433426>] __device_release_driver+0x96/0x130
      [ 1003.342870]  [<ffffffff814334e3>] device_release_driver+0x23/0x30
      [ 1003.342871]  [<ffffffff8131b404>] pci_stop_bus_device+0x94/0xa0
      [ 1003.342872]  [<ffffffff8131b3ad>] pci_stop_bus_device+0x3d/0xa0
      [ 1003.342873]  [<ffffffff8131b3ad>] pci_stop_bus_device+0x3d/0xa0
      [ 1003.342874]  [<ffffffff8131b516>] pci_stop_and_remove_bus_device+0x16/0x30
      [ 1003.342876]  [<ffffffff81333f5b>] pciehp_unconfigure_device+0x9b/0x180
      [ 1003.342877]  [<ffffffff81333a73>] pciehp_disable_slot+0x43/0xb0
      [ 1003.342878]  [<ffffffff81333b6d>] pciehp_power_thread+0x8d/0xb0
      [ 1003.342885]  [<ffffffff810881b2>] process_one_work+0x152/0x3d0
      [ 1003.342886]  [<ffffffff8108854a>] worker_thread+0x11a/0x460
      [ 1003.342887]  [<ffffffff81088430>] ? process_one_work+0x3d0/0x3d0
      [ 1003.342890]  [<ffffffff8108ddd9>] kthread+0xc9/0xe0
      [ 1003.342891]  [<ffffffff8108dd10>] ? kthread_create_on_node+0x180/0x180
      [ 1003.342893]  [<ffffffff8164e29f>] ret_from_fork+0x3f/0x70
      [ 1003.342894]  [<ffffffff8108dd10>] ? kthread_create_on_node+0x180/0x180
      [ 1003.342895] ---[ end trace 65a77e06d5aa9358 ]---
      
      Upon looking at the igb driver, I see that igb_rd32() attempted to read from
      hw_addr and failed, so it set hw->hw_addr to NULL and spit out the message
      in the log output above, "PCIe link lost, device now detached".
      
      Well, now that hw_addr is NULL, the attempt to call pci_iounmap is obviously
      not going to go well. As suggested by Mark Rustad, do something similar to
      what ixgbe does, and save a copy of hw_addr as adapter->io_addr, so we can
      still call pci_iounmap on it on teardown. Additionally, for consistency,
      make the pci_iomap call assignment directly to io_addr, so map and unmap
      match.
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      73bf8048
  4. 05 10月, 2015 1 次提交
  5. 19 8月, 2015 1 次提交
    • S
      igb: Fix oops caused by missing queue pairing · 72ddef05
      Shota Suzuki 提交于
      When initializing igb driver (e.g. 82576, I350), IGB_FLAG_QUEUE_PAIRS is
      set if adapter->rss_queues exceeds half of max_rss_queues in
      igb_init_queue_configuration().
      On the other hand, IGB_FLAG_QUEUE_PAIRS is not set even if the number of
      queues exceeds half of max_combined in igb_set_channels() when changing
      the number of queues by "ethtool -L".
      In this case, if numvecs is larger than MAX_MSIX_ENTRIES (10), the size
      of adapter->msix_entries[], an overflow can occur in
      igb_set_interrupt_capability(), which in turn leads to an oops.
      
      Fix this problem as follows:
       - When changing the number of queues by "ethtool -L", set
         IGB_FLAG_QUEUE_PAIRS in the same way as initializing igb driver.
       - When increasing the size of q_vector, reallocate it appropriately.
         (With IGB_FLAG_QUEUE_PAIRS set, the size of q_vector gets larger.)
      
      Another possible way to fix this problem is to cap the queues at its
      initial number, which is the number of the initial online cpus. But this
      is not the optimal way because we cannot increase queues when another
      cpu becomes online.
      
      Note that before commit cd14ef54 ("igb: Change to use statically
      allocated array for MSIx entries"), this problem did not cause oops
      but just made the number of queues become 1 because of entering msi_only
      mode in igb_set_interrupt_capability().
      
      Fixes: 907b7835 ("igb: Add ethtool support to configure number of channels")
      CC: stable <stable@vger.kernel.org>
      Signed-off-by: NShota Suzuki <suzuki_shota_t3@lab.ntt.co.jp>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      72ddef05
  6. 23 1月, 2015 1 次提交
  7. 31 12月, 2014 1 次提交
  8. 02 10月, 2014 1 次提交
    • B
      igb: remove blocking phy read from inside spinlock · 7acf6318
      Bernhard Kaindl 提交于
      Remove a source of latency spikes (in my case up to 10ms) by not calling
      code that uses mdelay() for feeding a phy statistic (rx errors for idle
      symbols - not data -> idle_errors) while being called with a spinlock held.
      
      As idle_errors isn't read, this patch only removes unused code and data.
      
      Later, more complicated changes may be applied to address the spinlock and
      allow for some PHY diagnostics by harvesting this PHY stats register fully.
      
      This patch is designed to fix the issue and be safe for longterm/stable.
      
      For the Intel e1000e driver, the same change was applied in 2008 with
      commit 23033fad ("e1000e: remove phy read from inside spinlock").
      
      The mdelay is triggered by HW/SW semaphores, thus it depends on the HW.
      
      I've HW that triggers it even when idle. Others may trigger it only e.g.
      when Ethernet ports aquire or loose the link or on ifconfig up / down.
      We've noticed this first from delays in frame rx/tx due to the mdelay().
      
      Example command for checking if the issue is triggered: cyclictest -Smp1
      (Look for occasional "Max:" values > 4000 or use -b 4000 to stop if greater)
      
      It was observed with I350 ports connected to other I350 ports, but not
      if driver and EEPROM was modified to run the I350 in EEPROM-less mode.
      
      phy_stats.idle_errors and .receive_errors (isn't touched) occupy 64 not
      used bits in the adapter struct: Their allocation may be removed as well.
      
      Cc: Carolyn Wyborny <carolyn.wyborny@intel.com>
      Cc: Todd Fujinaka <todd.fujinaka@intel.com>
      Fixes: 12dcd86b ("igb: fix stats handling") (this added the spin_lock)
      Signed-off-by: NBernhard Kaindl <bk-linux@use.startmail.com>
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      7acf6318
  9. 25 4月, 2014 1 次提交
  10. 23 4月, 2014 1 次提交
  11. 11 4月, 2014 1 次提交
  12. 28 3月, 2014 1 次提交
  13. 21 3月, 2014 1 次提交
  14. 13 3月, 2014 1 次提交
  15. 27 2月, 2014 2 次提交
  16. 18 12月, 2013 1 次提交
  17. 10 12月, 2013 3 次提交
  18. 02 10月, 2013 1 次提交
  19. 25 9月, 2013 1 次提交
    • J
      intel: Remove extern from function prototypes · 5ccc921a
      Joe Perches 提交于
      There are a mix of function prototypes with and without extern
      in the kernel sources.  Standardize on not using extern for
      function prototypes.
      
      Function prototypes don't need to be written with extern.
      extern is assumed by the compiler.  Its use is as unnecessary as
      using auto to declare automatic/local variables in a block.
      Signed-off-by: NJoe Perches <joe@perches.com>
      5ccc921a
  20. 04 9月, 2013 1 次提交
  21. 22 8月, 2013 2 次提交
  22. 21 5月, 2013 2 次提交
  23. 19 4月, 2013 5 次提交
  24. 05 3月, 2013 1 次提交
  25. 15 2月, 2013 2 次提交
  26. 19 1月, 2013 1 次提交
  27. 18 1月, 2013 3 次提交