* [dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1 @ 2013-11-22 12:29 Dmitry Vyal 2013-11-22 12:48 ` Thomas Monjalon 0 siblings, 1 reply; 11+ messages in thread From: Dmitry Vyal @ 2013-11-22 12:29 UTC (permalink / raw) To: dev Hi, I'm experiencing weird problems with running dpdk examples on my server running ubuntu-12.04. Application either manages to use ethernet ports or doesn't. For example, this is results of two identical sequental runs of l2fwd: ****************************************************************************** dev@tiny-one:~/dpdk-1.5.0r1/examples/l2fwd$ s -E ./build/l2fwd -c 0x3 -n 2 EAL: Detected lcore 0 as core 0 on socket 0 EAL: Detected lcore 1 as core 1 on socket 0 EAL: Detected lcore 2 as core 2 on socket 0 EAL: Detected lcore 3 as core 3 on socket 0 EAL: Detected lcore 4 as core 0 on socket 0 EAL: Detected lcore 5 as core 1 on socket 0 EAL: Detected lcore 6 as core 2 on socket 0 EAL: Detected lcore 7 as core 3 on socket 0 EAL: Skip lcore 8 (not detected) <LINES DELETED> EAL: Setting up memory... EAL: Ask a virtual area of 0x4194304 bytes EAL: Virtual area found at 0x7f6b82400000 (size = 0x400000) EAL: Ask a virtual area of 0x2097152 bytes EAL: Virtual area found at 0x7f6b82000000 (size = 0x200000) EAL: Ask a virtual area of 0x2097152 bytes EAL: Virtual area found at 0x7f6b81c00000 (size = 0x200000) EAL: Ask a virtual area of 0x1056964608 bytes EAL: Virtual area found at 0x7f6b42a00000 (size = 0x3f000000) EAL: Ask a virtual area of 0x2097152 bytes EAL: Virtual area found at 0x7f6b42600000 (size = 0x200000) EAL: Ask a virtual area of 0x2097152 bytes EAL: Virtual area found at 0x7f6b42200000 (size = 0x200000) EAL: Ask a virtual area of 0x2097152 bytes EAL: Virtual area found at 0x7f6b41e00000 (size = 0x200000) EAL: Ask a virtual area of 0x2097152 bytes EAL: Virtual area found at 0x7f6b41a00000 (size = 0x200000) EAL: Requesting 512 pages of size 2MB from socket 0 EAL: TSC frequency is ~1600000 KHz EAL: Master core 0 is ready (tid=836da800) EAL: Core 1 is ready (tid=40ff8700) EAL: PCI device 0000:02:00.0 on NUMA socket -1 EAL: probe driver: 8086:10fb rte_ixgbe_pmd EAL: PCI memory mapped at 0x7f6b83687000 EAL: PCI memory mapped at 0x7f6b83683000 EAL: PCI device 0000:02:00.1 on NUMA socket -1 EAL: probe driver: 8086:10fb rte_ixgbe_pmd EAL: PCI memory mapped at 0x7f6b83663000 EAL: PCI memory mapped at 0x7f6b8365f000 EAL: PCI device 0000:03:00.0 on NUMA socket -1 EAL: probe driver: 8086:10d3 rte_em_pmd EAL: 0000:03:00.0 not managed by UIO driver, skipping EAL: PCI device 0000:04:00.0 on NUMA socket -1 EAL: probe driver: 8086:10d3 rte_em_pmd EAL: 0000:04:00.0 not managed by UIO driver, skipping EAL: PCI device 0000:05:00.0 on NUMA socket -1 EAL: probe driver: 8086:10d3 rte_em_pmd EAL: 0000:05:00.0 not managed by UIO driver, skipping EAL: PCI device 0000:06:00.0 on NUMA socket -1 EAL: probe driver: 8086:10d3 rte_em_pmd EAL: 0000:06:00.0 not managed by UIO driver, skipping EAL: PCI device 0000:07:00.0 on NUMA socket -1 EAL: probe driver: 8086:10d3 rte_em_pmd EAL: 0000:07:00.0 not managed by UIO driver, skipping EAL: PCI device 0000:08:00.0 on NUMA socket -1 EAL: probe driver: 8086:10d3 rte_em_pmd EAL: 0000:08:00.0 not managed by UIO driver, skipping EAL: PCI device 0000:09:00.0 on NUMA socket -1 EAL: probe driver: 8086:10d3 rte_em_pmd EAL: 0000:09:00.0 not managed by UIO driver, skipping EAL: Error - exiting with code: 1 Cause: No Ethernet ports - bye ************************************************************************************ dev@econat-tiny-one:~/dpdk-1.5.0r1/examples/l2fwd$ s -E ./build/l2fwd -c 0x3 -n 2 EAL: Detected lcore 0 as core 0 on socket 0 EAL: Detected lcore 1 as core 1 on socket 0 EAL: Detected lcore 2 as core 2 on socket 0 EAL: Detected lcore 3 as core 3 on socket 0 EAL: Detected lcore 4 as core 0 on socket 0 EAL: Detected lcore 5 as core 1 on socket 0 EAL: Detected lcore 6 as core 2 on socket 0 EAL: Detected lcore 7 as core 3 on socket 0 EAL: Skip lcore 8 (not detected) <LINES DELETED> EAL: Setting up memory... EAL: Ask a virtual area of 0x4194304 bytes EAL: Virtual area found at 0x7f538a600000 (size = 0x400000) EAL: Ask a virtual area of 0x2097152 bytes EAL: Virtual area found at 0x7f538a200000 (size = 0x200000) EAL: Ask a virtual area of 0x2097152 bytes EAL: Virtual area found at 0x7f5389e00000 (size = 0x200000) EAL: Ask a virtual area of 0x1056964608 bytes EAL: Virtual area found at 0x7f534ac00000 (size = 0x3f000000) EAL: Ask a virtual area of 0x2097152 bytes EAL: Virtual area found at 0x7f534a800000 (size = 0x200000) EAL: Ask a virtual area of 0x2097152 bytes EAL: Virtual area found at 0x7f534a400000 (size = 0x200000) EAL: Ask a virtual area of 0x2097152 bytes EAL: Virtual area found at 0x7f534a000000 (size = 0x200000) EAL: Ask a virtual area of 0x2097152 bytes EAL: Virtual area found at 0x7f5349c00000 (size = 0x200000) EAL: Requesting 512 pages of size 2MB from socket 0 EAL: TSC frequency is ~3301000 KHz EAL: Master core 0 is ready (tid=8b98d800) EAL: Core 1 is ready (tid=491f8700) EAL: PCI device 0000:02:00.0 on NUMA socket -1 EAL: probe driver: 8086:10fb rte_ixgbe_pmd EAL: PCI memory mapped at 0x7f538b93a000 EAL: PCI memory mapped at 0x7f538b936000 EAL: PCI device 0000:02:00.1 on NUMA socket -1 EAL: probe driver: 8086:10fb rte_ixgbe_pmd EAL: PCI memory mapped at 0x7f538b916000 EAL: PCI memory mapped at 0x7f538b912000 EAL: PCI device 0000:03:00.0 on NUMA socket -1 EAL: probe driver: 8086:10d3 rte_em_pmd EAL: 0000:03:00.0 not managed by UIO driver, skipping EAL: PCI device 0000:04:00.0 on NUMA socket -1 EAL: probe driver: 8086:10d3 rte_em_pmd EAL: 0000:04:00.0 not managed by UIO driver, skipping EAL: PCI device 0000:05:00.0 on NUMA socket -1 EAL: probe driver: 8086:10d3 rte_em_pmd EAL: 0000:05:00.0 not managed by UIO driver, skipping EAL: PCI device 0000:06:00.0 on NUMA socket -1 EAL: probe driver: 8086:10d3 rte_em_pmd EAL: 0000:06:00.0 not managed by UIO driver, skipping EAL: PCI device 0000:07:00.0 on NUMA socket -1 EAL: probe driver: 8086:10d3 rte_em_pmd EAL: 0000:07:00.0 not managed by UIO driver, skipping EAL: PCI device 0000:08:00.0 on NUMA socket -1 EAL: probe driver: 8086:10d3 rte_em_pmd EAL: 0000:08:00.0 not managed by UIO driver, skipping EAL: PCI device 0000:09:00.0 on NUMA socket -1 EAL: probe driver: 8086:10d3 rte_em_pmd EAL: 0000:09:00.0 not managed by UIO driver, skipping Skipping disabled port 0 Skipping disabled port 1 EAL: Error - exiting with code: 1 Cause: All available ports are disabled. Please set portmask. ****************************************************************** You see, final messages differ. Almost all the time I get "Cause: No Ethernet ports - bye" but sometimes (with probability of 1/10 or so) NIC is initialized successfully. Some info about the system: dev@tiny-one:~/dpdk-1.5.0r1/examples/l2fwd$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 58 model name : Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz stepping : 9 microcode : 0x10 cpu MHz : 1600.000 cache size : 8192 KB physical id : 0 siblings : 8 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms bogomips : 6584.75 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: dev@tiny-one:~/dpdk-1.5.0r1/examples/l2fwd$ lspci 00:00.0 Host bridge: Intel Corporation Ivy Bridge DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Ivy Bridge PCI Express Root Port (rev 09) 00:01.1 PCI bridge: Intel Corporation Ivy Bridge PCI Express Root Port (rev 09) 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05) 00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5) 00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b5) 00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 3 (rev b5) 00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b5) 00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b5) 00:1c.5 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 6 (rev b5) 00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b5) 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a5) 00:1f.0 ISA bridge: Intel Corporation C206 Chipset Family LPC Controller (rev 05) 00:1f.2 IDE interface: Intel Corporation 6 Series/C200 Series Chipset Family 4 port SATA IDE Controller (rev 05) 00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05) 00:1f.5 IDE interface: Intel Corporation 6 Series/C200 Series Chipset Family 2 port SATA IDE Controller (rev 05) 02:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) 02:00.1 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) 03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 08:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 09:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection dev@tiny-one:~/dpdk-1.5.0r1/examples/l2fwd$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 12.04.2 LTS Release: 12.04 Codename: precise Any ideas how to investigate this? Regards, Dmitry ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1 2013-11-22 12:29 [dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1 Dmitry Vyal @ 2013-11-22 12:48 ` Thomas Monjalon 2013-11-27 14:06 ` Dmitry Vyal 0 siblings, 1 reply; 11+ messages in thread From: Thomas Monjalon @ 2013-11-22 12:48 UTC (permalink / raw) To: Dmitry Vyal; +Cc: dev Hello, 22/11/2013 13:29, Dmitry Vyal : > EAL: PCI device 0000:02:00.0 on NUMA socket -1 > EAL: probe driver: 8086:10fb rte_ixgbe_pmd > EAL: PCI memory mapped at 0x7f6b83687000 > EAL: PCI memory mapped at 0x7f6b83683000 > EAL: PCI device 0000:02:00.1 on NUMA socket -1 > EAL: probe driver: 8086:10fb rte_ixgbe_pmd > EAL: PCI memory mapped at 0x7f6b83663000 > EAL: PCI memory mapped at 0x7f6b8365f000 [...] > EAL: Error - exiting with code: 1 > Cause: No Ethernet ports - bye > > Any ideas how to investigate this? Could you try this patch in order to see the root cause of your issue ? --- a/lib/librte_pmd_ixgbe/ixgbe_logs.h +++ b/lib/librte_pmd_ixgbe/ixgbe_logs.h @@ -34,41 +34,44 @@ #ifndef _IXGBE_LOGS_H_ #define _IXGBE_LOGS_H_ +#define PMD_LOG(level, fmt, args...) \ + RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ##args) + #ifdef RTE_LIBRTE_IXGBE_DEBUG_INIT -#define PMD_INIT_LOG(level, fmt, args...) \ - RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) +#define PMD_INIT_LOG(level, fmt, args...) PMD_LOG(level, fmt, ##args) #define PMD_INIT_FUNC_TRACE() PMD_INIT_LOG(DEBUG, " >>") #else -#define PMD_INIT_LOG(level, fmt, args...) do { } while(0) +#define PMD_INIT_LOG(level, fmt, args...) \ + (void)(RTE_LOG_##level <= RTE_LOG_ERR ? PMD_LOG(level, fmt, ##args) : 0) #define PMD_INIT_FUNC_TRACE() do { } while(0) #endif #ifdef RTE_LIBRTE_IXGBE_DEBUG_RX -#define PMD_RX_LOG(level, fmt, args...) \ - RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) +#define PMD_RX_LOG(level, fmt, args...) PMD_LOG(level, fmt, ##args) #else -#define PMD_RX_LOG(level, fmt, args...) do { } while(0) +#define PMD_RX_LOG(level, fmt, args...) \ + (void)(RTE_LOG_##level <= RTE_LOG_ERR ? PMD_LOG(level, fmt, ##args) : 0) #endif #ifdef RTE_LIBRTE_IXGBE_DEBUG_TX -#define PMD_TX_LOG(level, fmt, args...) \ - RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) +#define PMD_TX_LOG(level, fmt, args...) PMD_LOG(level, fmt, ##args) #else -#define PMD_TX_LOG(level, fmt, args...) do { } while(0) +#define PMD_TX_LOG(level, fmt, args...) \ + (void)(RTE_LOG_##level <= RTE_LOG_ERR ? PMD_LOG(level, fmt, ##args) : 0) #endif #ifdef RTE_LIBRTE_IXGBE_DEBUG_TX_FREE -#define PMD_TX_FREE_LOG(level, fmt, args...) \ - RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) +#define PMD_TX_FREE_LOG(level, fmt, args...) PMD_LOG(level, fmt, ##args) #else -#define PMD_TX_FREE_LOG(level, fmt, args...) do { } while(0) +#define PMD_TX_FREE_LOG(level, fmt, args...) \ + (void)(RTE_LOG_##level <= RTE_LOG_ERR ? PMD_LOG(level, fmt, ##args) : 0) #endif #ifdef RTE_LIBRTE_IXGBE_DEBUG_DRIVER -#define PMD_DRV_LOG(level, fmt, args...) \ - RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) +#define PMD_DRV_LOG(level, fmt, args...) PMD_LOG(level, fmt, ##args) #else -#define PMD_DRV_LOG(level, fmt, args...) do { } while(0) +#define PMD_DRV_LOG(level, fmt, args...) \ + (void)(RTE_LOG_##level <= RTE_LOG_ERR ? PMD_LOG(level, fmt, ##args) : 0) #endif #endif /* _IXGBE_LOGS_H_ */ -- Thomas ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1 2013-11-22 12:48 ` Thomas Monjalon @ 2013-11-27 14:06 ` Dmitry Vyal 2013-11-27 14:10 ` jigsaw 2013-11-27 14:42 ` Thomas Monjalon 0 siblings, 2 replies; 11+ messages in thread From: Dmitry Vyal @ 2013-11-27 14:06 UTC (permalink / raw) To: Thomas Monjalon; +Cc: dev Looks like I finally found the reason. After applying this patch I can no longer reproduce the error. diff --git a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c index db07789..5f825fa 100644 --- a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c +++ b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c @@ -2347,7 +2347,7 @@ s32 ixgbe_reset_pipeline_82599(struct ixgbe_hw *hw) /* Write AUTOC register with toggled LMS[2] bit and Restart_AN */ IXGBE_WRITE_REG(hw, IXGBE_AUTOC, autoc_reg ^ IXGBE_AUTOC_LMS_1G_AN); /* Wait for AN to leave state 0 */ - for (i = 0; i < 10; i++) { + for (i = 0; i < 100; i++) { msec_delay(4); anlp1_reg = IXGBE_READ_REG(hw, IXGBE_ANLP1); if (anlp1_reg & IXGBE_ANLP1_AN_STATE_MASK) On 11/22/2013 04:48 PM, Thomas Monjalon wrote: > Hello, > > 22/11/2013 13:29, Dmitry Vyal : >> EAL: PCI device 0000:02:00.0 on NUMA socket -1 >> EAL: probe driver: 8086:10fb rte_ixgbe_pmd >> EAL: PCI memory mapped at 0x7f6b83687000 >> EAL: PCI memory mapped at 0x7f6b83683000 >> EAL: PCI device 0000:02:00.1 on NUMA socket -1 >> EAL: probe driver: 8086:10fb rte_ixgbe_pmd >> EAL: PCI memory mapped at 0x7f6b83663000 >> EAL: PCI memory mapped at 0x7f6b8365f000 > [...] >> EAL: Error - exiting with code: 1 >> Cause: No Ethernet ports - bye >> >> Any ideas how to investigate this? > Could you try this patch in order to see the root cause of your issue ? > > --- a/lib/librte_pmd_ixgbe/ixgbe_logs.h > +++ b/lib/librte_pmd_ixgbe/ixgbe_logs.h > @@ -34,41 +34,44 @@ > #ifndef _IXGBE_LOGS_H_ > #define _IXGBE_LOGS_H_ > > +#define PMD_LOG(level, fmt, args...) \ > + RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ##args) > + > #ifdef RTE_LIBRTE_IXGBE_DEBUG_INIT > -#define PMD_INIT_LOG(level, fmt, args...) \ > - RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) > +#define PMD_INIT_LOG(level, fmt, args...) PMD_LOG(level, fmt, ##args) > #define PMD_INIT_FUNC_TRACE() PMD_INIT_LOG(DEBUG, " >>") > #else > -#define PMD_INIT_LOG(level, fmt, args...) do { } while(0) > +#define PMD_INIT_LOG(level, fmt, args...) \ > + (void)(RTE_LOG_##level <= RTE_LOG_ERR ? PMD_LOG(level, fmt, ##args) : 0) > #define PMD_INIT_FUNC_TRACE() do { } while(0) > #endif > > #ifdef RTE_LIBRTE_IXGBE_DEBUG_RX > -#define PMD_RX_LOG(level, fmt, args...) \ > - RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) > +#define PMD_RX_LOG(level, fmt, args...) PMD_LOG(level, fmt, ##args) > #else > -#define PMD_RX_LOG(level, fmt, args...) do { } while(0) > +#define PMD_RX_LOG(level, fmt, args...) \ > + (void)(RTE_LOG_##level <= RTE_LOG_ERR ? PMD_LOG(level, fmt, ##args) : 0) > #endif > > #ifdef RTE_LIBRTE_IXGBE_DEBUG_TX > -#define PMD_TX_LOG(level, fmt, args...) \ > - RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) > +#define PMD_TX_LOG(level, fmt, args...) PMD_LOG(level, fmt, ##args) > #else > -#define PMD_TX_LOG(level, fmt, args...) do { } while(0) > +#define PMD_TX_LOG(level, fmt, args...) \ > + (void)(RTE_LOG_##level <= RTE_LOG_ERR ? PMD_LOG(level, fmt, ##args) : 0) > #endif > > #ifdef RTE_LIBRTE_IXGBE_DEBUG_TX_FREE > -#define PMD_TX_FREE_LOG(level, fmt, args...) \ > - RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) > +#define PMD_TX_FREE_LOG(level, fmt, args...) PMD_LOG(level, fmt, ##args) > #else > -#define PMD_TX_FREE_LOG(level, fmt, args...) do { } while(0) > +#define PMD_TX_FREE_LOG(level, fmt, args...) \ > + (void)(RTE_LOG_##level <= RTE_LOG_ERR ? PMD_LOG(level, fmt, ##args) : 0) > #endif > > #ifdef RTE_LIBRTE_IXGBE_DEBUG_DRIVER > -#define PMD_DRV_LOG(level, fmt, args...) \ > - RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) > +#define PMD_DRV_LOG(level, fmt, args...) PMD_LOG(level, fmt, ##args) > #else > -#define PMD_DRV_LOG(level, fmt, args...) do { } while(0) > +#define PMD_DRV_LOG(level, fmt, args...) \ > + (void)(RTE_LOG_##level <= RTE_LOG_ERR ? PMD_LOG(level, fmt, ##args) : 0) > #endif > > #endif /* _IXGBE_LOGS_H_ */ > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1 2013-11-27 14:06 ` Dmitry Vyal @ 2013-11-27 14:10 ` jigsaw 2013-11-27 14:42 ` Thomas Monjalon 1 sibling, 0 replies; 11+ messages in thread From: jigsaw @ 2013-11-27 14:10 UTC (permalink / raw) To: Dmitry Vyal; +Cc: dev I had exactly same problem and fixed it with same patch since release 1.4. But somehow it stopped to appear even without the patch. I have no idea what I have done since both the kernel and the driver have been updated during these days. On Wed, Nov 27, 2013 at 4:06 PM, Dmitry Vyal <dmitryvyal@gmail.com> wrote: > Looks like I finally found the reason. After applying this patch I can no > longer reproduce the error. > > diff --git a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c > b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c > index db07789..5f825fa 100644 > --- a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c > +++ b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c > @@ -2347,7 +2347,7 @@ s32 ixgbe_reset_pipeline_82599(struct ixgbe_hw *hw) > /* Write AUTOC register with toggled LMS[2] bit and Restart_AN */ > IXGBE_WRITE_REG(hw, IXGBE_AUTOC, autoc_reg ^ IXGBE_AUTOC_LMS_1G_AN); > /* Wait for AN to leave state 0 */ > - for (i = 0; i < 10; i++) { > + for (i = 0; i < 100; i++) { > msec_delay(4); > anlp1_reg = IXGBE_READ_REG(hw, IXGBE_ANLP1); > if (anlp1_reg & IXGBE_ANLP1_AN_STATE_MASK) > > On 11/22/2013 04:48 PM, Thomas Monjalon wrote: >> >> Hello, >> >> 22/11/2013 13:29, Dmitry Vyal : >>> >>> EAL: PCI device 0000:02:00.0 on NUMA socket -1 >>> EAL: probe driver: 8086:10fb rte_ixgbe_pmd >>> EAL: PCI memory mapped at 0x7f6b83687000 >>> EAL: PCI memory mapped at 0x7f6b83683000 >>> EAL: PCI device 0000:02:00.1 on NUMA socket -1 >>> EAL: probe driver: 8086:10fb rte_ixgbe_pmd >>> EAL: PCI memory mapped at 0x7f6b83663000 >>> EAL: PCI memory mapped at 0x7f6b8365f000 >> >> [...] >>> >>> EAL: Error - exiting with code: 1 >>> Cause: No Ethernet ports - bye >>> >>> Any ideas how to investigate this? >> >> Could you try this patch in order to see the root cause of your issue ? >> >> --- a/lib/librte_pmd_ixgbe/ixgbe_logs.h >> +++ b/lib/librte_pmd_ixgbe/ixgbe_logs.h >> @@ -34,41 +34,44 @@ >> #ifndef _IXGBE_LOGS_H_ >> #define _IXGBE_LOGS_H_ >> +#define PMD_LOG(level, fmt, args...) \ >> + RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ##args) >> + >> #ifdef RTE_LIBRTE_IXGBE_DEBUG_INIT >> -#define PMD_INIT_LOG(level, fmt, args...) \ >> - RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) >> +#define PMD_INIT_LOG(level, fmt, args...) PMD_LOG(level, fmt, ##args) >> #define PMD_INIT_FUNC_TRACE() PMD_INIT_LOG(DEBUG, " >>") >> #else >> -#define PMD_INIT_LOG(level, fmt, args...) do { } while(0) >> +#define PMD_INIT_LOG(level, fmt, args...) \ >> + (void)(RTE_LOG_##level <= RTE_LOG_ERR ? PMD_LOG(level, fmt, >> ##args) : 0) >> #define PMD_INIT_FUNC_TRACE() do { } while(0) >> #endif >> #ifdef RTE_LIBRTE_IXGBE_DEBUG_RX >> -#define PMD_RX_LOG(level, fmt, args...) \ >> - RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) >> +#define PMD_RX_LOG(level, fmt, args...) PMD_LOG(level, fmt, ##args) >> #else >> -#define PMD_RX_LOG(level, fmt, args...) do { } while(0) >> +#define PMD_RX_LOG(level, fmt, args...) \ >> + (void)(RTE_LOG_##level <= RTE_LOG_ERR ? PMD_LOG(level, fmt, >> ##args) : 0) >> #endif >> #ifdef RTE_LIBRTE_IXGBE_DEBUG_TX >> -#define PMD_TX_LOG(level, fmt, args...) \ >> - RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) >> +#define PMD_TX_LOG(level, fmt, args...) PMD_LOG(level, fmt, ##args) >> #else >> -#define PMD_TX_LOG(level, fmt, args...) do { } while(0) >> +#define PMD_TX_LOG(level, fmt, args...) \ >> + (void)(RTE_LOG_##level <= RTE_LOG_ERR ? PMD_LOG(level, fmt, >> ##args) : 0) >> #endif >> #ifdef RTE_LIBRTE_IXGBE_DEBUG_TX_FREE >> -#define PMD_TX_FREE_LOG(level, fmt, args...) \ >> - RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) >> +#define PMD_TX_FREE_LOG(level, fmt, args...) PMD_LOG(level, fmt, ##args) >> #else >> -#define PMD_TX_FREE_LOG(level, fmt, args...) do { } while(0) >> +#define PMD_TX_FREE_LOG(level, fmt, args...) \ >> + (void)(RTE_LOG_##level <= RTE_LOG_ERR ? PMD_LOG(level, fmt, >> ##args) : 0) >> #endif >> #ifdef RTE_LIBRTE_IXGBE_DEBUG_DRIVER >> -#define PMD_DRV_LOG(level, fmt, args...) \ >> - RTE_LOG(level, PMD, "%s(): " fmt "\n", __func__, ## args) >> +#define PMD_DRV_LOG(level, fmt, args...) PMD_LOG(level, fmt, ##args) >> #else >> -#define PMD_DRV_LOG(level, fmt, args...) do { } while(0) >> +#define PMD_DRV_LOG(level, fmt, args...) \ >> + (void)(RTE_LOG_##level <= RTE_LOG_ERR ? PMD_LOG(level, fmt, >> ##args) : 0) >> #endif >> #endif /* _IXGBE_LOGS_H_ */ >> > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1 2013-11-27 14:06 ` Dmitry Vyal 2013-11-27 14:10 ` jigsaw @ 2013-11-27 14:42 ` Thomas Monjalon 2013-11-28 11:01 ` Richardson, Bruce 1 sibling, 1 reply; 11+ messages in thread From: Thomas Monjalon @ 2013-11-27 14:42 UTC (permalink / raw) To: Dmitry Vyal; +Cc: dev 27/11/2013 15:06, Dmitry Vyal : > Looks like I finally found the reason. After applying this patch I can > no longer reproduce the error. > > --- a/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c > +++ b/lib/librte_pmd_ixgbe/ixgbe/ixgbe_82599.c > /* Wait for AN to leave state 0 */ > - for (i = 0; i < 10; i++) { > + for (i = 0; i < 100; i++) { > msec_delay(4); > anlp1_reg = IXGBE_READ_REG(hw, IXGBE_ANLP1); > if (anlp1_reg & IXGBE_ANLP1_AN_STATE_MASK) It's probably due to a frequency scaling. The timer based is initialized when DPDK initialize and the CPU can change its frequency, breaking next timers. The fix is to control the CPU frequency. Please try this, without your patch: for g in /sys/devices/system/cpu/*/cpufreq/scaling_governor; do echo performance >$g; done The right fix for applications (examples and testpmd included) could be to call rte_power_init(). Patches are welcomed. Thank you for your analysis -- Thomas ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1 2013-11-27 14:42 ` Thomas Monjalon @ 2013-11-28 11:01 ` Richardson, Bruce 2013-11-29 10:53 ` Dmitry Vyal 0 siblings, 1 reply; 11+ messages in thread From: Richardson, Bruce @ 2013-11-28 11:01 UTC (permalink / raw) To: Thomas Monjalon, Dmitry Vyal; +Cc: dev > > It's probably due to a frequency scaling. > The timer based is initialized when DPDK initialize and the CPU can change > its frequency, breaking next timers. > > The fix is to control the CPU frequency. > Please try this, without your patch: > for g in /sys/devices/system/cpu/*/cpufreq/scaling_governor; do > echo performance >$g; done The right fix for applications (examples and > testpmd included) could be to call rte_power_init(). Patches are welcomed. > [BR] Frequency changes should not affect timers for modern Intel CPUs. Please see the " Intel(r) 64 and IA-32 Architectures Software Developer's Manual" Volume 3 (http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf) , Section 17.13 for more details on this. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1 2013-11-28 11:01 ` Richardson, Bruce @ 2013-11-29 10:53 ` Dmitry Vyal 2013-11-29 12:25 ` Thomas Monjalon 0 siblings, 1 reply; 11+ messages in thread From: Dmitry Vyal @ 2013-11-29 10:53 UTC (permalink / raw) To: Richardson, Bruce, Thomas Monjalon; +Cc: dev Hmm, that's strange. I don't know how to interpret my observations then. I have access to two platforms, one is based on Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz and another on Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz. Both running ubuntu-12.04 server. I see repeating errors on NIC initialisation phase. The error frequency greatly reduces if I patch loop limit as I described earlier or if I call rte_power_init and rte_power_freq_max as Thomas suggested. But the only way to get rid of them completely is to set performance governor. On 11/28/2013 03:01 PM, Richardson, Bruce wrote: >> It's probably due to a frequency scaling. >> The timer based is initialized when DPDK initialize and the CPU can change >> its frequency, breaking next timers. >> >> The fix is to control the CPU frequency. >> Please try this, without your patch: >> for g in /sys/devices/system/cpu/*/cpufreq/scaling_governor; do >> echo performance >$g; done The right fix for applications (examples and >> testpmd included) could be to call rte_power_init(). Patches are welcomed. >> > [BR] Frequency changes should not affect timers for modern Intel CPUs. Please see the " Intel(r) 64 and IA-32 Architectures Software Developer's Manual" Volume 3 (http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf) , Section 17.13 for more details on this. > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1 2013-11-29 10:53 ` Dmitry Vyal @ 2013-11-29 12:25 ` Thomas Monjalon 2013-11-29 12:39 ` Thomas Monjalon 2013-11-29 18:20 ` Thomas Monjalon 0 siblings, 2 replies; 11+ messages in thread From: Thomas Monjalon @ 2013-11-29 12:25 UTC (permalink / raw) To: Dmitry Vyal; +Cc: dev 29/11/2013 14:53, Dmitry Vyal : > On 11/28/2013 03:01 PM, Richardson, Bruce wrote: > >> It's probably due to a frequency scaling. > >> The timer based is initialized when DPDK initialize and the CPU can > >> change > >> its frequency, breaking next timers. > >> > >> The fix is to control the CPU frequency. > >> > >> Please try this, without your patch: > >> for g in /sys/devices/system/cpu/*/cpufreq/scaling_governor; do > >> > >> echo performance >$g; done The right fix for applications (examples and > >> testpmd included) could be to call rte_power_init(). Patches are > >> welcomed. > > > > [BR] Frequency changes should not affect timers for modern Intel CPUs. > > Please see the " Intel(r) 64 and IA-32 Architectures Software Developer's > > Manual" Volume 3 > > (http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-i > > a-32-architectures-software-developer-system-programming-manual-325384.pdf > > ) , Section 17.13 for more details on this. > > Hmm, that's strange. I don't know how to interpret my observations then. > I have access to two platforms, one is based on Intel(R) Xeon(R) CPU > E3-1230 V2 @ 3.30GHz and another on Intel(R) Xeon(R) CPU E3-1270 v3 @ > 3.50GHz. Both running ubuntu-12.04 server. I see repeating errors on NIC > initialisation phase. The error frequency greatly reduces if I patch > loop limit as I described earlier or if I call rte_power_init and > rte_power_freq_max as Thomas suggested. > > But the only way to get rid of them completely is to set performance > governor. Please check that your hardware do not support invariant TSC. It would explain why you need to fix frequency. I attach a simple code to test CPU feature "Invariant TSC". -- Thomas From elevran@gmail.com Fri Nov 29 13:30:07 2013 Return-Path: <elevran@gmail.com> Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by dpdk.org (Postfix) with ESMTP id 05CBA5957 for <dev@dpdk.org>; Fri, 29 Nov 2013 13:30:06 +0100 (CET) Received: by mail-we0-f179.google.com with SMTP id q59so9138233wes.24 for <dev@dpdk.org>; Fri, 29 Nov 2013 04:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=YgCCovryZzq6ddtzTpobh+UluwKbC5L79otuZIxexDo=; b=QwbRWGBva7n9G7iJie7XwNIyS5w1aUpCfsW6K3cJbMErnf4fqQyFDVh+hrnIy1+PQs yz3m19LaUk9PTzSV+IAUsdMgRP+vVNjqHlnQJaVf1SnMSgCeuZ6IbNpQZXhWjnOgpYtr CgjIrbwSoeq6HKXH3vsbi/m+QJXTQuQVy3jLIN+TQGB8YcEcycgk3XQeV9LforTelJkZ +Xzvjner6ld+Endb+ZflPcZjiSYXMtjqc7ZnVAdm39tJcQoOF4Yq/dHInLThgFmwE+GJ g7xGqxZ/NR3yijoiIlgeZd2xvTIUJ817CiOtoNkWg0NRqCDOIOOe4OKNa7L/lzLRkx8l 8tfA== X-Received: by 10.180.90.141 with SMTP id bw13mr6711636wib.40.1385728267606; Fri, 29 Nov 2013 04:31:07 -0800 (PST) Received: from elevranwin7 (85.64.123.135.dynamic.barak-online.net. [85.64.123.135]) by mx.google.com with ESMTPSA id a19sm91468131wib.1.2013.11.29.04.31.04 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Nov 2013 04:31:06 -0800 (PST) From: "Etai Lev-Ran" <elevran@gmail.com> To: "'Surya Nimmagadda'" <nscsekhar@juniper.net> References: <20d8915bacb140d5a7a02e45f0093c3f@CO1PR05MB284.namprd05.prod.outlook.com> <52987205.4050507@bisdn.de> In-Reply-To: <52987205.4050507@bisdn.de> Date: Fri, 29 Nov 2013 14:31:12 +0200 Message-ID: <019601ceecfe$e5304fc0$af90ef40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Ac7s8RhXRr3criIyS9m8QQASzSCIUAADIISg Content-language: en-us Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Unable to build dpdk : #error "SSSE3 instruction set not enabled" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Fri, 29 Nov 2013 12:30:07 -0000 Hi Surya, SSE3 instructions are not enabled by default. To enable, you can either tell gcc your CPU architecture (-march=<arch>) as suggested by Marc, or enable just the specific SSE version that's supported by your CPU (e.g., make TOOLCHAIN_CFLAGS="-msse4") See http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html for a list of CPU architectures and instruction flags. Regards, Etai -----Original Message----- From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Marc Sune Sent: Friday, November 29, 2013 12:53 PM To: dev@dpdk.org Subject: Re: [dpdk-dev] Unable to build dpdk : #error "SSSE3 instruction set not enabled" Changing the CPU type emulation to some model that supports SSSE3 solved it (e.g. core2duo) should do the trick. I faced the same problem sometime ago. best marc On 29/11/13 11:39, Surya Nimmagadda wrote: > Hi, > > I am a beginner with dpdk and trying to follow the instructions in > http://www.dpdk.org/doc/quick-start > > I am seeing the following error when doing make with 1.5.0r2 or > 1.5.1r1 > > == Build lib/librte_meter > == Build lib/librte_sched > CC rte_sched.o > In file included from /home/surya/dpdk/dpdk-1.5.1r1/lib/librte_sched/rte_bitmap.h:77:0, > from /home/surya/dpdk/dpdk-1.5.1r1/lib/librte_sched/rte_sched.c:47: > /usr/lib/gcc/x86_64-linux-gnu/4.6/include/tmmintrin.h:31:3: error: #error "SSSE3 instruction set not enabled" > make[3]: *** [rte_sched.o] Error 1 > make[2]: *** [librte_sched] Error 2 > make[1]: *** [lib] Error 2 > make: *** [all] Error 2 > > I am running this on a Ubuntu VM (12.04) with gcc version 4.6.3 > > It built fine on another vm where I have Ubuntun 13.10 with gcc > version 4.8.1 > > Should I upgrade to 4.8.1 here as well (it has become a long process with lot of road blocks) or is there any simple fix? > > The DPDK doc says I just need gcc versions 4.5.x or later. > > Thanks, > Surya > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1 2013-11-29 12:25 ` Thomas Monjalon @ 2013-11-29 12:39 ` Thomas Monjalon 2013-12-06 12:43 ` Dmitry Vyal 2013-11-29 18:20 ` Thomas Monjalon 1 sibling, 1 reply; 11+ messages in thread From: Thomas Monjalon @ 2013-11-29 12:39 UTC (permalink / raw) To: Dmitry Vyal; +Cc: dev 29/11/2013 13:25, Thomas Monjalon : > 29/11/2013 14:53, Dmitry Vyal : > > On 11/28/2013 03:01 PM, Richardson, Bruce wrote: > > > [BR] Frequency changes should not affect timers for modern Intel CPUs. > > > Please see the " Intel(r) 64 and IA-32 Architectures Software > > > Developer's > > > Manual" Volume 3 > > > (http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-> > > i > > > a-32-architectures-software-developer-system-programming-manual-325384.p > > > df > > > ) , Section 17.13 for more details on this. > > > > Hmm, that's strange. I don't know how to interpret my observations then. > > I have access to two platforms, one is based on Intel(R) Xeon(R) CPU > > E3-1230 V2 @ 3.30GHz and another on Intel(R) Xeon(R) CPU E3-1270 v3 @ > > 3.50GHz. Both running ubuntu-12.04 server. I see repeating errors on NIC > > initialisation phase. The error frequency greatly reduces if I patch > > loop limit as I described earlier or if I call rte_power_init and > > rte_power_freq_max as Thomas suggested. > > > > But the only way to get rid of them completely is to set performance > > governor. > > Please check that your hardware do not support invariant TSC. > It would explain why you need to fix frequency. > > I attach a simple code to test CPU feature "Invariant TSC". It seems that the file is stripped on the mailing-list. Code inlined: #include <stdlib.h> #include <stdio.h> #include <unistd.h> #include <stdint.h> int main() { uint32_t a = 0x80000000; uint32_t b, d; __asm__("cpuid;" :"=a"(b) :"0"(a)); if (b >= 0x80000007) { a = 0x80000007; __asm__("cpuid;" :"=a"(b), "=d"(d) :"0"(a)); if (d & (1<<8)) { printf("Invariant TSC is supported\n"); } else{ printf("Invariant TSC is NOT supported\n"); } } else { printf("No support for Advanced Power Management Information in CPUID\n"); } return 0; } ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1 2013-11-29 12:39 ` Thomas Monjalon @ 2013-12-06 12:43 ` Dmitry Vyal 0 siblings, 0 replies; 11+ messages in thread From: Dmitry Vyal @ 2013-12-06 12:43 UTC (permalink / raw) To: Thomas Monjalon; +Cc: dev On 11/29/2013 04:39 PM, Thomas Monjalon wrote: > 29/11/2013 13:25, Thomas Monjalon : > > Please check that your hardware do not support invariant TSC. > It would explain why you need to fix frequency. > > I attach a simple code to test CPU feature "Invariant TSC". I compiled and ran the code on all the platforms I had troubles on. Invariant TSC is supported everywhere. > It seems that the file is stripped on the mailing-list. > Code inlined: > > #include <stdlib.h> > #include <stdio.h> > #include <unistd.h> > #include <stdint.h> > > > int main() > { > uint32_t a = 0x80000000; > uint32_t b, d; > > __asm__("cpuid;" > :"=a"(b) > :"0"(a)); > > if (b >= 0x80000007) { > > a = 0x80000007; > __asm__("cpuid;" > :"=a"(b), "=d"(d) > :"0"(a)); > > if (d & (1<<8)) { > printf("Invariant TSC is supported\n"); > } else{ > printf("Invariant TSC is NOT supported\n"); > } > } else { > printf("No support for Advanced Power Management Information in > CPUID\n"); > } > return 0; > } > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1 2013-11-29 12:25 ` Thomas Monjalon 2013-11-29 12:39 ` Thomas Monjalon @ 2013-11-29 18:20 ` Thomas Monjalon 1 sibling, 0 replies; 11+ messages in thread From: Thomas Monjalon @ 2013-11-29 18:20 UTC (permalink / raw) To: Dmitry Vyal; +Cc: dev Thomas29/11/2013 13:25, Monjalon : > 29/11/2013 14:53, Dmitry Vyal : > > On 11/28/2013 03:01 PM, Richardson, Bruce wrote: > > > [BR] Frequency changes should not affect timers for modern Intel CPUs. > > > > The error frequency greatly reduces if I patch > > loop limit as I described earlier or if I call rte_power_init and > > rte_power_freq_max as Thomas suggested. > > > > But the only way to get rid of them completely is to set performance > > governor. > > Please check that your hardware do not support invariant TSC. > It would explain why you need to fix frequency. > > I attach a simple code to test CPU feature "Invariant TSC". Note that this feature is called constant_tsc in /proc/cpuinfo: grep --color -m1 constant_tsc /proc/cpuinfo It is checked by check_tsc_flags() at DPDK initialization and should print a warning if missing: http://dpdk.org/browse/dpdk/commit/?id=e7c8996e13b9abb706ea0de53271346f4f86ca03 -- Thomas ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-12-06 12:42 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-11-22 12:29 [dpdk-dev] Sporadic errors while initializing NICs in example applications, dpdk-1.5.0r1 Dmitry Vyal 2013-11-22 12:48 ` Thomas Monjalon 2013-11-27 14:06 ` Dmitry Vyal 2013-11-27 14:10 ` jigsaw 2013-11-27 14:42 ` Thomas Monjalon 2013-11-28 11:01 ` Richardson, Bruce 2013-11-29 10:53 ` Dmitry Vyal 2013-11-29 12:25 ` Thomas Monjalon 2013-11-29 12:39 ` Thomas Monjalon 2013-12-06 12:43 ` Dmitry Vyal 2013-11-29 18:20 ` Thomas Monjalon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).