kernel-packages team mailing list archive

[Joseph Salisbury <joseph.salisbury@xxxxxxxxxxxxx>]

I also confirmed this bug is happening on our server for 12.04 with the
3.2.0-101 kernel.

** Description changed:

  Cavium engineers are testing  SR-IOV feature with  Cavium's new liquidIO
  card (based on OCTEON processor running as an intelligent NIC) on x86
  Dell servers and ran into the issue described below.
  
  They are *not* seeing this issue on  Intel 82599 NIC.
  
  So far, they have seen this on multiple Dell servers - T5810  & Dell
  T630 (x86 - Ubuntu certified).
  
- We are testing a Cavium OCTEON device in EP mode with SRIOV.  With a CentOS7 VM running on the Ubuntu 14.04.2 host (using VFIO) we see that a single PCI read or write transaction targeting the device’s BAR0 issued from the VM appears twice on the PCIe bus. The same accesses work fine when the VF is accessed directly from the Ubuntu 14.04.2 host. These BAR0 PCI accesses do not require a driver on the VM side. We can reproduce the problem using a simple user-space application to access the VF’s BAR0 registers.
-  
- We do not see this problem when the VM runs within a CentOS 7 host or under a Ubuntu 12.04 host. This appears specific to Ubuntu 14.04 release. Appreciate your help in any clues or pointers to this behavior.
+ We are testing a Cavium OCTEON device in EP mode with SRIOV.  With a
+ CentOS7 VM running on the Ubuntu 14.04.2 host (using VFIO) we see that a
+ single PCI read or write transaction targeting the device’s BAR0 issued
+ from the VM appears twice on the PCIe bus. The same accesses work fine
+ when the VF is accessed directly from the Ubuntu 14.04.2 host. These
+ BAR0 PCI accesses do not require a driver on the VM side. We can
+ reproduce the problem using a simple user-space application to access
+ the VF’s BAR0 registers.
+ 
+ We do not see this problem when the VM runs within a CentOS 7 host or
+ under a Ubuntu 12.04 host. This appears specific to Ubuntu 14.04
+ release. Appreciate your help in any clues or pointers to this behavior.
  
  This issue is also not happening with 16.04 beta.
+ 
+ 
+ Steps to reproduce the bug with pcimem:
+ 
+ Read:
+ ./pcimem /sys/bus/pci/devices/0000\:04\:00.0/resource0 0x10080 d
+ 
+ Write:
+ ./pcimem /sys/bus/pci/devices/0000\:04\:00.0/resource0 0x10080 d 2048
+ 
+ Read again:
+ ./pcimem /sys/bus/pci/devices/0000\:04\:00.0/resource0 0x10080 d
+ 
+ 
+ The value of SLIST_BAOFF_DBELL should be the same for the first read and the second read, after the write.  
+ 
+ If the bug is hit, the second read will report a value of double instead
+ of the same.

** Description changed:

  Cavium engineers are testing  SR-IOV feature with  Cavium's new liquidIO
  card (based on OCTEON processor running as an intelligent NIC) on x86
  Dell servers and ran into the issue described below.
  
  They are *not* seeing this issue on  Intel 82599 NIC.
  
  So far, they have seen this on multiple Dell servers - T5810  & Dell
  T630 (x86 - Ubuntu certified).
  
  We are testing a Cavium OCTEON device in EP mode with SRIOV.  With a
  CentOS7 VM running on the Ubuntu 14.04.2 host (using VFIO) we see that a
  single PCI read or write transaction targeting the device’s BAR0 issued
  from the VM appears twice on the PCIe bus. The same accesses work fine
  when the VF is accessed directly from the Ubuntu 14.04.2 host. These
  BAR0 PCI accesses do not require a driver on the VM side. We can
  reproduce the problem using a simple user-space application to access
  the VF’s BAR0 registers.
  
  We do not see this problem when the VM runs within a CentOS 7 host or
  under a Ubuntu 12.04 host. This appears specific to Ubuntu 14.04
  release. Appreciate your help in any clues or pointers to this behavior.
  
  This issue is also not happening with 16.04 beta.
  
- 
  Steps to reproduce the bug with pcimem:
  
  Read:
  ./pcimem /sys/bus/pci/devices/0000\:04\:00.0/resource0 0x10080 d
  
  Write:
  ./pcimem /sys/bus/pci/devices/0000\:04\:00.0/resource0 0x10080 d 2048
  
  Read again:
  ./pcimem /sys/bus/pci/devices/0000\:04\:00.0/resource0 0x10080 d
  
- 
- The value of SLIST_BAOFF_DBELL should be the same for the first read and the second read, after the write.  
+ The value of SLIST_BAOFF_DBELL should be the same for the first read and
+ the second read, after the write.
  
  If the bug is hit, the second read will report a value of double instead
  of the same.
+ 
+ The register should have read back the same value that was written. The
+ register acts like an adder in that every write adds to the previously
+ written value minus anything the device has consumed. We see that the
+ second read returns double the value written in the single write. We
+ captured a PCIe trace and found that each of the PCI operation accessing
+ this register is seen twice on the PCI bus. The 2 writes cause the
+ register value to double which has implications for normal operation.
+ The PCIe trace is attached and has markers to identify the relevant
+ transactions.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1563375

Title:
  A a single PCI read or write appears twice on the PCIe bus. This
  happens when using the SR-IOV feature with  Cavium's liquidIO card

Status in linux package in Ubuntu:
  In Progress

Bug description:
  Cavium engineers are testing  SR-IOV feature with  Cavium's new
  liquidIO card (based on OCTEON processor running as an intelligent
  NIC) on x86 Dell servers and ran into the issue described below.

  They are *not* seeing this issue on  Intel 82599 NIC.

  So far, they have seen this on multiple Dell servers - T5810  & Dell
  T630 (x86 - Ubuntu certified).

  We are testing a Cavium OCTEON device in EP mode with SRIOV.  With a
  CentOS7 VM running on the Ubuntu 14.04.2 host (using VFIO) we see that
  a single PCI read or write transaction targeting the device’s BAR0
  issued from the VM appears twice on the PCIe bus. The same accesses
  work fine when the VF is accessed directly from the Ubuntu 14.04.2
  host. These BAR0 PCI accesses do not require a driver on the VM side.
  We can reproduce the problem using a simple user-space application to
  access the VF’s BAR0 registers.

  We do not see this problem when the VM runs within a CentOS 7 host or
  under a Ubuntu 12.04 host. This appears specific to Ubuntu 14.04
  release. Appreciate your help in any clues or pointers to this
  behavior.

  This issue is also not happening with 16.04 beta.

  Steps to reproduce the bug with pcimem:

  Read:
  ./pcimem /sys/bus/pci/devices/0000\:04\:00.0/resource0 0x10080 d

  Write:
  ./pcimem /sys/bus/pci/devices/0000\:04\:00.0/resource0 0x10080 d 2048

  Read again:
  ./pcimem /sys/bus/pci/devices/0000\:04\:00.0/resource0 0x10080 d

  The value of SLIST_BAOFF_DBELL should be the same for the first read
  and the second read, after the write.

  If the bug is hit, the second read will report a value of double
  instead of the same.

  The register should have read back the same value that was written.
  The register acts like an adder in that every write adds to the
  previously written value minus anything the device has consumed. We
  see that the second read returns double the value written in the
  single write. We captured a PCIe trace and found that each of the PCI
  operation accessing this register is seen twice on the PCI bus. The 2
  writes cause the register value to double which has implications for
  normal operation. The PCIe trace is attached and has markers to
  identify the relevant transactions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1563375/+subscriptions