1. 26 4月, 2021 1 次提交
  2. 27 1月, 2021 1 次提交
  3. 27 10月, 2020 1 次提交
    • Z
      net: hns3: Clear the CMDQ registers before unmapping BAR region · e3364c5f
      Zenghui Yu 提交于
      When unbinding the hns3 driver with the HNS3 VF, I got the following
      kernel panic:
      
      [  265.709989] Unable to handle kernel paging request at virtual address ffff800054627000
      [  265.717928] Mem abort info:
      [  265.720740]   ESR = 0x96000047
      [  265.723810]   EC = 0x25: DABT (current EL), IL = 32 bits
      [  265.729126]   SET = 0, FnV = 0
      [  265.732195]   EA = 0, S1PTW = 0
      [  265.735351] Data abort info:
      [  265.738227]   ISV = 0, ISS = 0x00000047
      [  265.742071]   CM = 0, WnR = 1
      [  265.745055] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000009b54000
      [  265.751753] [ffff800054627000] pgd=0000202ffffff003, p4d=0000202ffffff003, pud=00002020020eb003, pmd=00000020a0dfc003, pte=0000000000000000
      [  265.764314] Internal error: Oops: 96000047 [#1] SMP
      [  265.830357] CPU: 61 PID: 20319 Comm: bash Not tainted 5.9.0+ #206
      [  265.836423] Hardware name: Huawei TaiShan 2280 V2/BC82AMDDA, BIOS 1.05 09/18/2019
      [  265.843873] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
      [  265.843890] pc : hclgevf_cmd_uninit+0xbc/0x300
      [  265.861988] lr : hclgevf_cmd_uninit+0xb0/0x300
      [  265.861992] sp : ffff80004c983b50
      [  265.881411] pmr_save: 000000e0
      [  265.884453] x29: ffff80004c983b50 x28: ffff20280bbce500
      [  265.889744] x27: 0000000000000000 x26: 0000000000000000
      [  265.895034] x25: ffff800011a1f000 x24: ffff800011a1fe90
      [  265.900325] x23: ffff0020ce9b00d8 x22: ffff0020ce9b0150
      [  265.905616] x21: ffff800010d70e90 x20: ffff800010d70e90
      [  265.910906] x19: ffff0020ce9b0080 x18: 0000000000000004
      [  265.916198] x17: 0000000000000000 x16: ffff800011ae32e8
      [  265.916201] x15: 0000000000000028 x14: 0000000000000002
      [  265.916204] x13: ffff800011ae32e8 x12: 0000000000012ad8
      [  265.946619] x11: ffff80004c983b50 x10: 0000000000000000
      [  265.951911] x9 : ffff8000115d0888 x8 : 0000000000000000
      [  265.951914] x7 : ffff800011890b20 x6 : c0000000ffff7fff
      [  265.951917] x5 : ffff80004c983930 x4 : 0000000000000001
      [  265.951919] x3 : ffffa027eec1b000 x2 : 2b78ccbbff369100
      [  265.964487] x1 : 0000000000000000 x0 : ffff800054627000
      [  265.964491] Call trace:
      [  265.964494]  hclgevf_cmd_uninit+0xbc/0x300
      [  265.964496]  hclgevf_uninit_ae_dev+0x9c/0xe8
      [  265.964501]  hnae3_unregister_ae_dev+0xb0/0x130
      [  265.964516]  hns3_remove+0x34/0x88 [hns3]
      [  266.009683]  pci_device_remove+0x48/0xf0
      [  266.009692]  device_release_driver_internal+0x114/0x1e8
      [  266.030058]  device_driver_detach+0x28/0x38
      [  266.034224]  unbind_store+0xd4/0x108
      [  266.037784]  drv_attr_store+0x40/0x58
      [  266.041435]  sysfs_kf_write+0x54/0x80
      [  266.045081]  kernfs_fop_write+0x12c/0x250
      [  266.049076]  vfs_write+0xc4/0x248
      [  266.052378]  ksys_write+0x74/0xf8
      [  266.055677]  __arm64_sys_write+0x24/0x30
      [  266.059584]  el0_svc_common.constprop.3+0x84/0x270
      [  266.064354]  do_el0_svc+0x34/0xa0
      [  266.067658]  el0_svc+0x38/0x40
      [  266.070700]  el0_sync_handler+0x8c/0xb0
      [  266.074519]  el0_sync+0x140/0x180
      
      It looks like the BAR memory region had already been unmapped before we
      start clearing CMDQ registers in it, which is pretty bad and the kernel
      happily kills itself because of a Current EL Data Abort (on arm64).
      
      Moving the CMDQ uninitialization a bit early fixes the issue for me.
      
      Fixes: 862d969a ("net: hns3: do VF's pci re-initialization while PF doing FLR")
      Signed-off-by: NZenghui Yu <yuzenghui@huawei.com>
      Link: https://lore.kernel.org/r/20201023051550.793-1-yuzenghui@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      e3364c5f
  4. 30 9月, 2020 1 次提交
  5. 28 9月, 2020 3 次提交
  6. 25 9月, 2020 2 次提交
  7. 22 9月, 2020 1 次提交
  8. 09 9月, 2020 2 次提交
  9. 07 8月, 2020 1 次提交
  10. 29 7月, 2020 2 次提交
  11. 07 7月, 2020 1 次提交
  12. 31 5月, 2020 1 次提交
  13. 29 5月, 2020 2 次提交
  14. 28 5月, 2020 1 次提交
  15. 26 4月, 2020 3 次提交
    • J
      net: hns3: optimize the filter table entries handling when resetting · 039ba863
      Jian Shen 提交于
      Currently, the PF driver removes all (including its VFs') MAC/VLAN
      flow director table entries when resetting, and restores them after
      reset completed.
      
      In fact, the hardware will clear all table entries only in IMP
      reset and global reset. So driver only needs to restore the table
      entries in these cases, and needs do nothing when PF reset, FLR
      or other function level reset.
      
      This patch optimizes it by removing unnecessary table entries clear
      and restoring handling in the reset flow, and doing the restoring
      after reset completed.
      Signed-off-by: NJian Shen <shenjian15@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      039ba863
    • J
      net: hns3: refactor the promisc mode setting · c631c696
      Jian Shen 提交于
      As the HNS3 driver doesn't update the MAC address directly in
      function hns3_set_rx_mode() now, it can't know whether the
      MAC table is full from __dev_uc_sync() and __dev_mc_sync(),
      so it's senseless to handle the overflow promisc here.
      
      This patch removes the handle of overflow promisc from function
      hns3_set_rx_mode(), and updates the promisc mode in the service
      task.
      Signed-off-by: NJian Shen <shenjian15@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c631c696
    • J
      net: hns3: refactor the MAC address configure · ee4bcd3b
      Jian Shen 提交于
      Currently, the HNS3 driver sync and unsync MAC address in function
      hns3_set_rx_mode(). For PF, it adds and deletes MAC address directly
      in the path of dev_set_rx_mode(). If failed, it won't retry until
      next calling of hns3_set_rx_mode(). On the other hand, if request
      add and remove a same address many times at a short interval, each
      request must be done one by one, can't be merged. For VF, it sends
      mailbox messages to PF to request adding or deleting MAC address in
      the path of function hns3_set_rx_mode(), no matter the address is
      configured success.
      
      This patch refines it by recording the MAC address in function
      hns3_set_rx_mode(), and updating MAC address in the service task.
      If failed, it will retry by the next calling of periodical service
      task. It also uses some state to mark the state of each MAC address
      in the MAC list, which can help merge configure request for a same
      address. With these changes, when global reset or IMP reset occurs,
      we can restore the MAC table with the MAC list.
      Signed-off-by: NJian Shen <shenjian15@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ee4bcd3b
  16. 31 3月, 2020 2 次提交
    • G
      net: hns3: fix RSS config lost after VF reset. · 944de484
      Guojia Liao 提交于
      Currently, VF's RSS configuration would be set to default
      after VF reset, the the user's one will loss.
      
      To fix it, this patch separates hclgevf_rss_init_hw() into
      two parts, one sets up the default RSS configuration and
      just be called when driver loading, one configures the hardware
      and be called by driver loading or reset.
      
      Fixes: d97b3072 ("net: hns3: Add RSS tuples support for VF")
      Signed-off-by: NGuojia Liao <liaoguojia@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      944de484
    • Y
      net: hns3: drop the WQ_MEM_RECLAIM flag when allocating WQ · 16deaef2
      Yunsheng Lin 提交于
      The WQ in hns3 driver is allocated with WQ_MEM_RECLAIM flag
      in order to guarantee forward progress, which may cause hns3'
      WQ_MEM_RECLAIM WQ flushing infiniband' !WQ_MEM_RECLAIM WQ
      warning:
      
      [11246.200168] hns3 0000:bd:00.1: Reset done, hclge driver initialization finished.
      [11246.209979] hns3 0000:bd:00.1 eth7: net open
      [11246.227608] ------------[ cut here ]------------
      [11246.237370] workqueue: WQ_MEM_RECLAIM hclge:hclge_service_task [hclge] is flushing !WQ_MEM_RECLAIM infiniband:0x0
      [11246.237391] WARNING: CPU: 50 PID: 2279 at ./kernel/workqueue.c:2605 check_flush_dependency+0xcc/0x140
      [11246.260412] Modules linked in: hclgevf hns_roce_hw_v2 rdma_test(O) hns3 xt_CHECKSUM iptable_mangle xt_conntrack ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter bpfilter vfio_iommu_type1 vfio_pci vfio_virqfd vfio ib_isert iscsi_target_mod ib_ipoib ib_umad rpcrdma ib_iser libiscsi scsi_transport_iscsi aes_ce_blk crypto_simd cryptd aes_ce_cipher sunrpc nls_iso8859_1 crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce joydev input_leds hid_generic usbkbd usbmouse sbsa_gwdt usbhid usb_storage hid ses hclge hisi_zip hisi_hpre hisi_sec2 hnae3 hisi_qm ahci hisi_trng_v2 evbug uacce rng_core gpio_dwapb autofs4 hisi_sas_v3_hw megaraid_sas hisi_sas_main libsas scsi_transport_sas [last unloaded: hns_roce_hw_v2]
      [11246.325742] CPU: 50 PID: 2279 Comm: kworker/50:0 Kdump: loaded Tainted: G           O      5.4.0-rc4+ #1
      [11246.335181] Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDD, BIOS 2280-V2 CS V3.B140.01 12/18/2019
      [11246.344802] Workqueue: hclge hclge_service_task [hclge]
      [11246.350007] pstate: 60c00009 (nZCv daif +PAN +UAO)
      [11246.354779] pc : check_flush_dependency+0xcc/0x140
      [11246.359549] lr : check_flush_dependency+0xcc/0x140
      [11246.364317] sp : ffff800268a73990
      [11246.367618] x29: ffff800268a73990 x28: 0000000000000001
      [11246.372907] x27: ffffcbe4f5868000 x26: ffffcbe4f5541000
      [11246.378196] x25: 00000000000000b8 x24: ffff002fdd0ff868
      [11246.383483] x23: ffff002fdd0ff800 x22: ffff2027401ba600
      [11246.388770] x21: 0000000000000000 x20: ffff002fdd0ff800
      [11246.394059] x19: ffff202719293b00 x18: ffffcbe4f5541948
      [11246.399347] x17: 000000006f8ad8dd x16: 0000000000000002
      [11246.404634] x15: ffff8002e8a734f7 x14: 6c66207369205d65
      [11246.409922] x13: 676c63685b206b73 x12: 61745f6563697672
      [11246.415208] x11: 65735f65676c6368 x10: 3a65676c6368204d
      [11246.420494] x9 : 49414c4345525f4d x8 : 6e6162696e69666e
      [11246.425782] x7 : 69204d49414c4345 x6 : ffffcbe4f5765145
      [11246.431068] x5 : 0000000000000000 x4 : 0000000000000000
      [11246.436355] x3 : 0000000000000030 x2 : 00000000ffffffff
      [11246.441642] x1 : 3349eb1ac5310100 x0 : 0000000000000000
      [11246.446928] Call trace:
      [11246.449363]  check_flush_dependency+0xcc/0x140
      [11246.453785]  flush_workqueue+0x110/0x410
      [11246.457691]  ib_cache_cleanup_one+0x54/0x468
      [11246.461943]  __ib_unregister_device+0x70/0xa8
      [11246.466279]  ib_unregister_device+0x2c/0x40
      [11246.470455]  hns_roce_exit+0x34/0x198 [hns_roce_hw_v2]
      [11246.475571]  __hns_roce_hw_v2_uninit_instance.isra.56+0x3c/0x58 [hns_roce_hw_v2]
      [11246.482934]  hns_roce_hw_v2_reset_notify+0xd8/0x210 [hns_roce_hw_v2]
      [11246.489261]  hclge_notify_roce_client+0x84/0xe0 [hclge]
      [11246.494464]  hclge_reset_rebuild+0x60/0x730 [hclge]
      [11246.499320]  hclge_reset_service_task+0x400/0x5a0 [hclge]
      [11246.504695]  hclge_service_task+0x54/0x698 [hclge]
      [11246.509464]  process_one_work+0x15c/0x458
      [11246.513454]  worker_thread+0x144/0x520
      [11246.517186]  kthread+0xfc/0x128
      [11246.520314]  ret_from_fork+0x10/0x18
      [11246.523873] ---[ end trace eb980723699c2585 ]---
      [11246.528710] hns3 0000:bd:00.2: Func clear success after reset.
      [11246.528747] hns3 0000:bd:00.0: Func clear success after reset.
      [11246.907710] hns3 0000:bd:00.1 eth7: link up
      
      According to [1] and [2]:
      
      There seems to be no specific guidance about how to handling the
      forward progress guarantee of network device's WQ yet, and other
      network device's WQ seem to be marked with WQ_MEM_RECLAIM without
      a clear reason.
      
      So this patch removes the WQ_MEM_RECLAIM flag when allocating WQ
      to aviod the above warning.
      
      1. https://www.spinics.net/lists/netdev/msg631646.html
      2. https://www.spinics.net/lists/netdev/msg632097.html
      
      Fixes: 0ea68902 ("net: hns3: allocate WQ with WQ_MEM_RECLAIM flag")
      Signed-off-by: NYunsheng Lin <linyunsheng@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      16deaef2
  17. 22 3月, 2020 1 次提交
  18. 13 3月, 2020 1 次提交
  19. 10 3月, 2020 1 次提交
  20. 21 1月, 2020 3 次提交
  21. 12 1月, 2020 2 次提交
    • H
      net: hns3: refactor the procedure of VF FLR · f28368bb
      Huazhong Tan 提交于
      Currently, the actual work of VF FLR is handled in the reset task,
      which is asynchronous. So in some case, if the preparing and
      rebuilding are not done, then the VF FLR will trigger some problems,
      for example, makes hardware go into chaos.
      
      So this patch separates the process of VF FLR from reset task, and
      adds a semaphore to serialize this reset and others.
      
      When FLR's preparing fails, if there has other higher level reset
      pending or failing times less than the HCLGE_FLR_RETRY_CNT, this
      preparing should be retried, otherwise it will get into a wrong state.
      
      BTW, while the hardware reports misc interrupt during pcie_flr(),
      the driver can not receive this interrupt anymore, so disable it
      when hclgevf_flr_prepare() return, and re-enable it when enter
      hclgevf_flr_done().
      
      Avoid declaring internal function hclgevf_enable_vector(), this patch
      also moves its definition forward, and removes unused enum
      hnae3_flr_state.
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f28368bb
    • H
      net: hns3: split hclgevf_reset() into preparing and rebuilding part · 1cc9bc6e
      Huazhong Tan 提交于
      hclgevf_reset() is a little bloated, and the process of VF FLR will
      be separated from the reset task later. So this patch splits
      hclgevf_reset() into hclgevf_reset_prepare() and hclge_reset_rebuild(),
      then FLR can also reuse these two functions. Also moves HNAE3_UP_CLIENT
      into hclgevf_reset_stack().
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1cc9bc6e
  22. 07 1月, 2020 1 次提交
  23. 17 12月, 2019 4 次提交
  24. 01 11月, 2019 2 次提交