Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1450607 > unrolled thread
| Started by | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| First post | 2016-07-26 16:00 +0200 |
| Last post | 2016-07-26 16:30 +0200 |
| Articles | 4 — 2 participants |
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.
Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression) Thomas Gleixner <tglx@linutronix.de> - 2016-07-26 16:00 +0200
Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression) Foster Snowhill <forst@forstwoof.ru> - 2016-07-26 16:10 +0200
Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression) Thomas Gleixner <tglx@linutronix.de> - 2016-07-26 16:10 +0200
Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression) Foster Snowhill <forst@forstwoof.ru> - 2016-07-26 16:30 +0200
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2016-07-26 16:00 +0200 |
| Subject | Re: PROBLEM: Intel I210AT NIC resets while using PCI passthrough on ESXi (regression) |
| Message-ID | <rZb3Q-2Cx-13@gated-at.bofh.it> |
On Mon, 25 Jul 2016, Foster Snowhill wrote: > On 25.07.16 13:56, Thomas Gleixner wrote: > > On Sat, 23 Jul 2016, Foster Snowhill wrote: > >> [1.] One line summary of the problem: > >> > >> Intel I210AT NIC resets while using PCI passthrough on ESXi (regression) > > > > That has been reported before and so far this has been believed to be a vmware > > issue. Native hardware and KVM do not expose that. See: > > > > http://marc.info/?l=linux-kernel&m=145280623530135&w=2 > > http://marc.info/?l=linux-kernel&m=145879968005421&w=2 > > This is indeed the same symptoms I encountered in my case. More than that, I have an LSI 2008 adapter which is also being passed through in the same manner as the NIC, absolutely the same problem there too. Before doing the bisect I considered it a separate issue and planned to work on it later. > > > 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 test something else with that patch? After starting the NIC, can you please shutdown the interface, so the interrupt gets shutdown as well. (It should vanish from /proc/interrupts). Does that work correctly? Thanks, tglx
[toc] | [next] | [standalone]
| From | Foster Snowhill <forst@forstwoof.ru> |
|---|---|
| Date | 2016-07-26 16:10 +0200 |
| Message-ID | <rZbdv-2V0-15@gated-at.bofh.it> |
| In reply to | #1450607 |
On 26.07.16 16:49, Thomas Gleixner wrote:
> On Mon, 25 Jul 2016, Foster Snowhill wrote:
>> On 25.07.16 13:56, Thomas Gleixner wrote:
>>> 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 test something else with that patch?
>
> After starting the NIC, can you please shutdown the interface, so the
> interrupt gets shutdown as well. (It should vanish from /proc/interrupts).
root@ubuntutest ~ # cat /proc/interrupts
CPU0
0: 22 IO-APIC 2-edge timer
1: 9 IO-APIC 1-edge i8042
4: 3641 IO-APIC 4-edge serial
8: 1 IO-APIC 8-edge rtc0
9: 0 IO-APIC 9-fasteoi acpi
12: 15 IO-APIC 12-edge i8042
14: 0 IO-APIC 14-edge ata_piix
15: 0 IO-APIC 15-edge ata_piix
16: 1 IO-APIC 16-fasteoi vmwgfx
24: 0 PCI-MSI 344064-edge PCIe PME, pciehp
25: 0 PCI-MSI 346112-edge PCIe PME, pciehp
26: 0 PCI-MSI 348160-edge PCIe PME, pciehp
27: 0 PCI-MSI 350208-edge PCIe PME, pciehp
28: 0 PCI-MSI 352256-edge PCIe PME, pciehp
29: 0 PCI-MSI 354304-edge PCIe PME, pciehp
30: 0 PCI-MSI 356352-edge PCIe PME, pciehp
31: 0 PCI-MSI 358400-edge PCIe PME, pciehp
32: 0 PCI-MSI 360448-edge PCIe PME, pciehp
33: 0 PCI-MSI 362496-edge PCIe PME, pciehp
34: 0 PCI-MSI 364544-edge PCIe PME, pciehp
35: 0 PCI-MSI 366592-edge PCIe PME, pciehp
36: 0 PCI-MSI 368640-edge PCIe PME, pciehp
37: 0 PCI-MSI 370688-edge PCIe PME, pciehp
38: 0 PCI-MSI 372736-edge PCIe PME, pciehp
39: 0 PCI-MSI 374784-edge PCIe PME, pciehp
40: 0 PCI-MSI 376832-edge PCIe PME, pciehp
41: 0 PCI-MSI 378880-edge PCIe PME, pciehp
42: 0 PCI-MSI 380928-edge PCIe PME, pciehp
43: 0 PCI-MSI 382976-edge PCIe PME, pciehp
44: 0 PCI-MSI 385024-edge PCIe PME, pciehp
45: 0 PCI-MSI 387072-edge PCIe PME, pciehp
46: 0 PCI-MSI 389120-edge PCIe PME, pciehp
47: 0 PCI-MSI 391168-edge PCIe PME, pciehp
48: 0 PCI-MSI 393216-edge PCIe PME, pciehp
49: 0 PCI-MSI 395264-edge PCIe PME, pciehp
50: 0 PCI-MSI 397312-edge PCIe PME, pciehp
51: 0 PCI-MSI 399360-edge PCIe PME, pciehp
52: 0 PCI-MSI 401408-edge PCIe PME, pciehp
53: 0 PCI-MSI 403456-edge PCIe PME, pciehp
54: 0 PCI-MSI 405504-edge PCIe PME, pciehp
55: 0 PCI-MSI 407552-edge PCIe PME, pciehp
56: 4319 PCI-MSI 1572864-edge vmw_pvscsi
57: 32 PCI-MSI 129024-edge vmw_vmci
58: 0 PCI-MSI 129025-edge vmw_vmci
59: 134 PCI-MSI 1064960-edge ahci[0000:02:01.0]
60: 1 PCI-MSI 9961472-edge ens224
61: 64 PCI-MSI 9961473-edge ens224-rx-0
62: 43 PCI-MSI 9961474-edge ens224-tx-0
NMI: 0 Non-maskable interrupts
LOC: 5384 Local timer interrupts
SPU: 0 Spurious interrupts
PMI: 0 Performance monitoring interrupts
IWI: 1 IRQ work interrupts
RTR: 0 APIC ICR read retries
RES: 0 Rescheduling interrupts
CAL: 0 Function call interrupts
TLB: 0 TLB shootdowns
TRM: 0 Thermal event interrupts
THR: 0 Threshold APIC interrupts
DFR: 0 Deferred Error APIC interrupts
MCE: 0 Machine check exceptions
MCP: 1 Machine check polls
ERR: 0
MIS: 0
PIN: 0 Posted-interrupt notification event
PIW: 0 Posted-interrupt wakeup event
root@ubuntutest ~ # ifdown ens224
RTNETLINK answers: No such process
RTNETLINK answers: Cannot assign requested address
root@ubuntutest ~ # cat /proc/interrupts
CPU0
0: 22 IO-APIC 2-edge timer
1: 9 IO-APIC 1-edge i8042
4: 4459 IO-APIC 4-edge serial
8: 1 IO-APIC 8-edge rtc0
9: 0 IO-APIC 9-fasteoi acpi
12: 15 IO-APIC 12-edge i8042
14: 0 IO-APIC 14-edge ata_piix
15: 0 IO-APIC 15-edge ata_piix
16: 1 IO-APIC 16-fasteoi vmwgfx
24: 0 PCI-MSI 344064-edge PCIe PME, pciehp
25: 0 PCI-MSI 346112-edge PCIe PME, pciehp
26: 0 PCI-MSI 348160-edge PCIe PME, pciehp
27: 0 PCI-MSI 350208-edge PCIe PME, pciehp
28: 0 PCI-MSI 352256-edge PCIe PME, pciehp
29: 0 PCI-MSI 354304-edge PCIe PME, pciehp
30: 0 PCI-MSI 356352-edge PCIe PME, pciehp
31: 0 PCI-MSI 358400-edge PCIe PME, pciehp
32: 0 PCI-MSI 360448-edge PCIe PME, pciehp
33: 0 PCI-MSI 362496-edge PCIe PME, pciehp
34: 0 PCI-MSI 364544-edge PCIe PME, pciehp
35: 0 PCI-MSI 366592-edge PCIe PME, pciehp
36: 0 PCI-MSI 368640-edge PCIe PME, pciehp
37: 0 PCI-MSI 370688-edge PCIe PME, pciehp
38: 0 PCI-MSI 372736-edge PCIe PME, pciehp
39: 0 PCI-MSI 374784-edge PCIe PME, pciehp
40: 0 PCI-MSI 376832-edge PCIe PME, pciehp
41: 0 PCI-MSI 378880-edge PCIe PME, pciehp
42: 0 PCI-MSI 380928-edge PCIe PME, pciehp
43: 0 PCI-MSI 382976-edge PCIe PME, pciehp
44: 0 PCI-MSI 385024-edge PCIe PME, pciehp
45: 0 PCI-MSI 387072-edge PCIe PME, pciehp
46: 0 PCI-MSI 389120-edge PCIe PME, pciehp
47: 0 PCI-MSI 391168-edge PCIe PME, pciehp
48: 0 PCI-MSI 393216-edge PCIe PME, pciehp
49: 0 PCI-MSI 395264-edge PCIe PME, pciehp
50: 0 PCI-MSI 397312-edge PCIe PME, pciehp
51: 0 PCI-MSI 399360-edge PCIe PME, pciehp
52: 0 PCI-MSI 401408-edge PCIe PME, pciehp
53: 0 PCI-MSI 403456-edge PCIe PME, pciehp
54: 0 PCI-MSI 405504-edge PCIe PME, pciehp
55: 0 PCI-MSI 407552-edge PCIe PME, pciehp
56: 4338 PCI-MSI 1572864-edge vmw_pvscsi
57: 39 PCI-MSI 129024-edge vmw_vmci
58: 0 PCI-MSI 129025-edge vmw_vmci
59: 156 PCI-MSI 1064960-edge ahci[0000:02:01.0]
60: 1 PCI-MSI 9961472-edge
61: 72 PCI-MSI 9961473-edge
62: 49 PCI-MSI 9961474-edge
NMI: 0 Non-maskable interrupts
LOC: 7417 Local timer interrupts
SPU: 0 Spurious interrupts
PMI: 0 Performance monitoring interrupts
IWI: 1 IRQ work interrupts
RTR: 0 APIC ICR read retries
RES: 0 Rescheduling interrupts
CAL: 0 Function call interrupts
TLB: 0 TLB shootdowns
TRM: 0 Thermal event interrupts
THR: 0 Threshold APIC interrupts
DFR: 0 Deferred Error APIC interrupts
MCE: 0 Machine check exceptions
MCP: 1 Machine check polls
ERR: 0
MIS: 0
PIN: 0 Posted-interrupt notification event
PIW: 0 Posted-interrupt wakeup event
[toc] | [prev] | [next] | [standalone]
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Date | 2016-07-26 16:10 +0200 |
| Message-ID | <rZbdv-2V0-17@gated-at.bofh.it> |
| In reply to | #1450613 |
On Tue, 26 Jul 2016, Foster Snowhill wrote: > On 26.07.16 16:49, Thomas Gleixner wrote: > > On Mon, 25 Jul 2016, Foster Snowhill wrote: > >> On 25.07.16 13:56, Thomas Gleixner wrote: > >>> 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 test something else with that patch? > > > > After starting the NIC, can you please shutdown the interface, so the > > interrupt gets shutdown as well. (It should vanish from /proc/interrupts). Does reenabling work or does that result in a stall again? Thanks, tglx
[toc] | [prev] | [next] | [standalone]
| From | Foster Snowhill <forst@forstwoof.ru> |
|---|---|
| Date | 2016-07-26 16:30 +0200 |
| Message-ID | <rZbwS-32n-31@gated-at.bofh.it> |
| In reply to | #1450614 |
On 26.07.16 17:06, Thomas Gleixner wrote: > On Tue, 26 Jul 2016, Foster Snowhill wrote: >> On 26.07.16 16:49, Thomas Gleixner wrote: >>> On Mon, 25 Jul 2016, Foster Snowhill wrote: >>>> On 25.07.16 13:56, Thomas Gleixner wrote: >>>>> 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 test something else with that patch? >>> >>> After starting the NIC, can you please shutdown the interface, so the >>> interrupt gets shutdown as well. (It should vanish from /proc/interrupts). > > Does reenabling work or does that result in a stall again? Works. root@ubuntutest ~ # ifup ens224 Waiting for DAD... Done root@ubuntutest ~ # ping -s 1000 -n ya.ru PING YA.ru (213.180.204.3) 1000(1028) bytes of data. 1008 bytes from 213.180.204.3: icmp_seq=1 ttl=57 time=2.97 ms 1008 bytes from 213.180.204.3: icmp_seq=2 ttl=57 time=2.85 ms 1008 bytes from 213.180.204.3: icmp_seq=3 ttl=57 time=2.87 ms 1008 bytes from 213.180.204.3: icmp_seq=4 ttl=57 time=2.92 ms ^C --- YA.ru ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 2.851/2.904/2.976/0.072 ms root@ubuntutest ~ # grep ens224 /proc/interrupts 60: 3 PCI-MSI 9961472-edge ens224 61: 1686 PCI-MSI 9961473-edge ens224-rx-0 62: 890 PCI-MSI 9961474-edge ens224-tx-0
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web