Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1450545 > unrolled thread

Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on  ESXi (regression) Thomas Gleixner <tglx@linutronix.de> - 2016-07-26 13:50 +0200
    Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on  ESXi (regression) Foster Snowhill <forst@forstwoof.ru> - 2016-07-26 15:00 +0200
      Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on  ESXi (regression) Thomas Gleixner <tglx@linutronix.de> - 2016-07-26 15:10 +0200

#1450545 — Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression)

On Mon, 25 Jul 2016, Foster Snowhill wrote:
> On 25.07.16 13:56, Thomas Gleixner wrote:
i> > Could you please give the patch below a try? It might be related, but I'm
> > not sure whether it will cure that particular vmware oddity.
>
> Patch fixed the issue for me. Did 4-5 reboots just to be sure, all working
> properly, no adapter resets. Just for the sake of experiment built a clean
> 4.7 kernel without the patch, issue still present there as expected.

Can you please try whether the replacement patch below fixes your issue as
well?

Thanks,

	tglx

8<------------
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index a080f4496fe2..142341f8331b 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -645,6 +645,15 @@ static int msi_capability_init(struct pci_dev *dev, int nvec)
 		return ret;
 	}
 
+	/*
+	 * The mask can be ignored and PCI 2.3 does not specify mask bits for
+	 * each MSI interrupt. So in case of hierarchical irqdomains we need
+	 * to make sure that if masking is not available that the msi message
+	 * is written prior to setting the MSI enable bit in the device.
+	 */
+	if (pci_msi_ignore_mask || !entry->msi_attrib.maskbit)
+		irq_domain_activate_irq(irq_get_irq_data(entry->irq));
+
 	/* Set MSI enabled bits	 */
 	pci_intx_for_msi(dev, 0);
 	pci_msi_set_enable(dev, 1);

[toc] | [next] | [standalone]

#1450592

On 26.07.16 14:46, Thomas Gleixner wrote:
> Can you please try whether the replacement patch below fixes your issue as
> well?

This one doesn't fix the issue, getting resets again. Patch applied to HEAD (commit e65805251f2db69c9f67ed8062ab82526be5a374).

[    4.377316] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.3.0-k
[    4.377319] igb: Copyright (c) 2007-2014 Intel Corporation.
[    4.377387] igb 0000:13:00.0: enabling device (0000 -> 0002)
[    4.413040] igb 0000:13:00.0: added PHC on eth0
[    4.413041] igb 0000:13:00.0: Intel(R) Gigabit Ethernet Network Connection
[    4.413043] igb 0000:13:00.0: eth0: (PCIe:5.0Gb/s:unknown) xx:xx:xx:xx:xx:xx
[    4.413125] igb 0000:13:00.0: eth0: PBA No: 001300-000
[    4.413127] igb 0000:13:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s)
[    4.981302] igb 0000:13:00.0 ens224: renamed from eth0
[    5.394728] igb 0000:13:00.0: changing MTU from 1500 to 9000
[    7.904222] igb 0000:13:00.0 ens224: igb: ens224 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
[    7.904479] IPv6: ADDRCONF(NETDEV_CHANGE): ens224: link becomes ready
[   13.023592] ------------[ cut here ]------------
[   13.023621] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:272 dev_watchdog+0x22c/0x230
[   13.023624] NETDEV WATCHDOG: ens224 (igb): transmit queue 0 timed out
[   13.023625] Modules linked in: vmw_vsock_vmci_transport vsock joydev ppdev vmw_balloon intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel input_leds psmouse serio_raw igb ptp pps_core dca i2c_algo_bit nls_iso8859_1 ahci libahci fjes parport_pc parport vmw_vmci i2c_piix4 pata_acpi mac_hid sch_fq_codel ib_iser rdma_cm iw_cm ib_cm ib_core configfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi autofs4 raid10 raid456 libcrc32c async_raid6_recov async_memcpy async_pq async_xor xor async_tx raid6_pq raid1 raid0 multipath linear aesni_intel aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd vmw_pvscsi vmwgfx ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm shpchp
[   13.023650] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.7.0-msi2 #1
[   13.023652] Hardware name: VMware, Inc. VMware7,1/440BX Desktop Reference Platform, BIOS VMW71.00V.0.B64.1506250318 06/25/2015
[   13.023653]  0000000000000286 dd7086eb3068bd0c ffff8880fc603d70 ffffffff833f8cd3
[   13.023654]  ffff8880fc603dc0 0000000000000000 ffff8880fc603db0 ffffffff830820bb
[   13.023655]  00000110fc603da8 0000000000000000 0000000000000008 0000000000000000
[   13.023656] Call Trace:
[   13.023657]  <IRQ>  [<ffffffff833f8cd3>] dump_stack+0x63/0x90
[   13.023664]  [<ffffffff830820bb>] __warn+0xcb/0xf0
[   13.023665]  [<ffffffff8308213f>] warn_slowpath_fmt+0x5f/0x80
[   13.023667]  [<ffffffff8376b55c>] dev_watchdog+0x22c/0x230
[   13.023668]  [<ffffffff8376b330>] ? qdisc_rcu_free+0x40/0x40
[   13.023671]  [<ffffffff830f1595>] call_timer_fn+0x35/0x120
[   13.023672]  [<ffffffff830f1ef2>] run_timer_softirq+0x222/0x4d0
[   13.023674]  [<ffffffff830fa46c>] ? ktime_get+0x3c/0xb0
[   13.023676]  [<ffffffff83052dca>] ? lapic_next_deadline+0x2a/0x30
[   13.023678]  [<ffffffff83100e12>] ? clockevents_program_event+0x82/0x120
[   13.023681]  [<ffffffff83853b76>] __do_softirq+0xf6/0x280
[   13.023683]  [<ffffffff83087d63>] irq_exit+0xa3/0xb0
[   13.023684]  [<ffffffff83853992>] smp_apic_timer_interrupt+0x42/0x50
[   13.023686]  [<ffffffff83851c62>] apic_timer_interrupt+0x82/0x90
[   13.023686]  <EOI>  [<ffffffff83064486>] ? native_safe_halt+0x6/0x10
[   13.023691]  [<ffffffff83037fde>] default_idle+0x1e/0xd0
[   13.023692]  [<ffffffff8303875f>] arch_cpu_idle+0xf/0x20
[   13.023693]  [<ffffffff830c613a>] default_idle_call+0x2a/0x40
[   13.023694]  [<ffffffff830c643a>] cpu_startup_entry+0x2ea/0x350
[   13.023696]  [<ffffffff838437d7>] rest_init+0x77/0x80
[   13.023699]  [<ffffffff83f61fe9>] start_kernel+0x466/0x487
[   13.023700]  [<ffffffff83f61120>] ? early_idt_handler_array+0x120/0x120
[   13.023701]  [<ffffffff83f612da>] x86_64_start_reservations+0x29/0x2b
[   13.023702]  [<ffffffff83f6141f>] x86_64_start_kernel+0x143/0x166
[   13.023704] ---[ end trace 46f69508befb7107 ]---
[   13.023724] igb 0000:13:00.0 ens224: Reset adapter
[   17.824272] igb 0000:13:00.0 ens224: igb: ens224 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX

[toc] | [prev] | [next] | [standalone]

#1450595

On Tue, 26 Jul 2016, Foster Snowhill wrote:
> On 26.07.16 14:46, Thomas Gleixner wrote:
> > Can you please try whether the replacement patch below fixes your issue as
> > well?

> This one doesn't fix the issue, getting resets again. Patch applied to HEAD
> (commit e65805251f2db69c9f67ed8062ab82526be5a374).
>
> [    4.413127] igb 0000:13:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s)

Gah! That's MSI-X not MSI. So yes, the patch can't work then. Though it
confirms that it is an actual VMWARE emulation bug ...

Thanks,

	tglx

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web