* [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7
@ 2015-08-09 8:15 Jiang Liu
2015-08-09 10:14 ` Alexander Holler
` (4 more replies)
0 siblings, 5 replies; 16+ messages in thread
From: Jiang Liu @ 2015-08-09 8:15 UTC (permalink / raw)
To: Thomas Gleixner, Alexander Holler, Mark Rustad, Alex Deucher,
Ingo Molnar, H. Peter Anvin, x86, Jiang Liu
Cc: Tony Luck, linux-kernel
Alex Deucher, Mark Rustad and Alexander Holler reported a regression
with the latest v4.2-rc4 kernel, which breaks some SATA controllers.
With multi-MSI capable SATA controllers, only the first port works,
all other ports times out when executing SATA commands. This regression
bisects to 52f518a3a7c2 ("x86/MSI: Use hierarchical irqdomains to manage
MSI interrupts"), but it's not the root cause, it just triggers a bug
caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage
CPU interrupt vectors").
With this patch applied, the affected SATA controllers work as expected.
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Reported-by: Alex Deucher <alexdeucher@gmail.com>
Reported-by: Mark Rustad <mrustad@gmail.com>
Reported-by: Alexander Holler <holler@ahsoftware.de>
---
Hi Alex, Mark and Alexandler,
Sorry for the long delay to root cause this regression, it's
really annoying. Could you please help test this patch against the
latest v4.2-rcx?
Thanks!
Gerry
---
arch/x86/kernel/apic/vector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index f813261d9740..2683f36e4e0a 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -322,7 +322,7 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, unsigned int virq,
irq_data->chip = &lapic_controller;
irq_data->chip_data = data;
irq_data->hwirq = virq + i;
- err = assign_irq_vector_policy(virq, irq_data->node, data,
+ err = assign_irq_vector_policy(virq + i, irq_data->node, data,
info);
if (err)
goto error;
--
1.7.10.4
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 2015-08-09 8:15 [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 Jiang Liu @ 2015-08-09 10:14 ` Alexander Holler 2015-08-09 14:11 ` Jiang Liu 2015-08-10 15:00 ` Alex Deucher ` (3 subsequent siblings) 4 siblings, 1 reply; 16+ messages in thread From: Alexander Holler @ 2015-08-09 10:14 UTC (permalink / raw) To: Jiang Liu, Thomas Gleixner, Mark Rustad, Alex Deucher, Ingo Molnar, H. Peter Anvin, x86 Cc: Tony Luck, linux-kernel Am 09.08.2015 um 10:15 schrieb Jiang Liu: > Alex Deucher, Mark Rustad and Alexander Holler reported a regression > with the latest v4.2-rc4 kernel, which breaks some SATA controllers. > With multi-MSI capable SATA controllers, only the first port works, > all other ports times out when executing SATA commands. This regression > bisects to 52f518a3a7c2 ("x86/MSI: Use hierarchical irqdomains to manage > MSI interrupts"), but it's not the root cause, it just triggers a bug > caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage > CPU interrupt vectors"). > > With this patch applied, the affected SATA controllers work as expected. > > Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> > Reported-by: Alex Deucher <alexdeucher@gmail.com> > Reported-by: Mark Rustad <mrustad@gmail.com> > Reported-by: Alexander Holler <holler@ahsoftware.de> > --- > Hi Alex, Mark and Alexandler, > Sorry for the long delay to root cause this regression, it's > really annoying. Could you please help test this patch against the > latest v4.2-rcx? Works. Thanks. Tested-by: Alexander Holler <holler@ahsoftware.de> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 2015-08-09 10:14 ` Alexander Holler @ 2015-08-09 14:11 ` Jiang Liu 0 siblings, 0 replies; 16+ messages in thread From: Jiang Liu @ 2015-08-09 14:11 UTC (permalink / raw) To: Alexander Holler, Thomas Gleixner, Mark Rustad, Alex Deucher, Ingo Molnar, H. Peter Anvin, x86 Cc: Tony Luck, linux-kernel On 2015/8/9 18:14, Alexander Holler wrote: > Am 09.08.2015 um 10:15 schrieb Jiang Liu: >> Alex Deucher, Mark Rustad and Alexander Holler reported a regression >> with the latest v4.2-rc4 kernel, which breaks some SATA controllers. >> With multi-MSI capable SATA controllers, only the first port works, >> all other ports times out when executing SATA commands. This regression >> bisects to 52f518a3a7c2 ("x86/MSI: Use hierarchical irqdomains to manage >> MSI interrupts"), but it's not the root cause, it just triggers a bug >> caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage >> CPU interrupt vectors"). >> >> With this patch applied, the affected SATA controllers work as expected. >> >> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> >> Reported-by: Alex Deucher <alexdeucher@gmail.com> >> Reported-by: Mark Rustad <mrustad@gmail.com> >> Reported-by: Alexander Holler <holler@ahsoftware.de> >> --- >> Hi Alex, Mark and Alexandler, >> Sorry for the long delay to root cause this regression, it's >> really annoying. Could you please help test this patch against the >> latest v4.2-rcx? > > Works. Thanks. > > Tested-by: Alexander Holler <holler@ahsoftware.de> Thanks, Alexander! ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 2015-08-09 8:15 [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 Jiang Liu 2015-08-09 10:14 ` Alexander Holler @ 2015-08-10 15:00 ` Alex Deucher 2015-08-11 1:06 ` Jiang Liu 2015-08-10 16:47 ` Rustad, Mark D ` (2 subsequent siblings) 4 siblings, 1 reply; 16+ messages in thread From: Alex Deucher @ 2015-08-10 15:00 UTC (permalink / raw) To: Jiang Liu Cc: Thomas Gleixner, Alexander Holler, Mark Rustad, Ingo Molnar, H. Peter Anvin, x86, Tony Luck, LKML On Sun, Aug 9, 2015 at 4:15 AM, Jiang Liu <jiang.liu@linux.intel.com> wrote: > Alex Deucher, Mark Rustad and Alexander Holler reported a regression > with the latest v4.2-rc4 kernel, which breaks some SATA controllers. > With multi-MSI capable SATA controllers, only the first port works, > all other ports times out when executing SATA commands. This regression > bisects to 52f518a3a7c2 ("x86/MSI: Use hierarchical irqdomains to manage > MSI interrupts"), but it's not the root cause, it just triggers a bug > caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage > CPU interrupt vectors"). > > With this patch applied, the affected SATA controllers work as expected. Yes, this fixes the SATA regression: Tested-by: Alex Deucher <alexander.deucher@amd.com> I'm not sure if it's related to this patch or not (I haven't bisected it independently yet), but MSIs don't seem to work on GPUs. See the line for amdgpu. This is just after loading the driver. $ cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 138 0 0 0 IR-IO-APIC 2-edge timer 1: 2 2 1 4 IR-IO-APIC 1-edge i8042 7: 1 0 0 0 IR-IO-APIC 7-edge 8: 0 0 1 0 IR-IO-APIC 8-edge rtc0 9: 0 0 0 0 IR-IO-APIC 9-fasteoi acpi 14: 0 0 0 0 IR-IO-APIC 14-edge pata_atiixp 15: 0 0 0 0 IR-IO-APIC 15-edge pata_atiixp 16: 302 303 301 314 IR-IO-APIC 16-fasteoi snd_hda_intel 17: 0 0 0 0 IR-IO-APIC 17-fasteoi ehci_hcd:usb7, ehci_hcd:usb8 18: 0 0 0 0 IR-IO-APIC 18-fasteoi ohci_hcd:usb9, ohci_hcd:usb10, ohci_hcd:usb11 24: 0 0 0 1 PCI-MSI 4096-edge AMD-Vi 26: 0 0 0 0 IR-PCI-MSI 34816-edge PCIe PME 27: 0 0 0 0 IR-PCI-MSI 344064-edge PCIe PME 28: 0 0 0 0 IR-PCI-MSI 348160-edge PCIe PME 29: 0 0 0 0 IR-PCI-MSI 350208-edge PCIe PME 30: 247 255 1381 4617 IR-PCI-MSI 278528-edge ahci0 31: 162 163 164 181 IR-PCI-MSI 278529-edge ahci1 34: 2 1 2 17 IR-PCI-MSI 262144-edge xhci_hcd 35: 0 0 0 0 IR-PCI-MSI 262145-edge xhci_hcd 36: 0 0 0 0 IR-PCI-MSI 262146-edge xhci_hcd 37: 0 0 0 0 IR-PCI-MSI 262147-edge xhci_hcd 38: 0 0 0 0 IR-PCI-MSI 262148-edge xhci_hcd 39: 0 0 0 0 IR-PCI-MSI 264192-edge xhci_hcd 40: 0 0 0 0 IR-PCI-MSI 264193-edge xhci_hcd 41: 0 0 0 0 IR-PCI-MSI 264194-edge xhci_hcd 42: 0 0 0 0 IR-PCI-MSI 264195-edge xhci_hcd 43: 0 0 0 0 IR-PCI-MSI 264196-edge xhci_hcd 44: 0 0 0 0 IR-PCI-MSI 2097152-edge xhci_hcd 45: 0 0 0 0 IR-PCI-MSI 2097153-edge xhci_hcd 46: 0 0 0 0 IR-PCI-MSI 2097154-edge xhci_hcd 47: 0 0 0 0 IR-PCI-MSI 2097155-edge xhci_hcd 48: 0 0 0 0 IR-PCI-MSI 2097156-edge xhci_hcd 50: 40 41 41 40 IR-PCI-MSI 526336-edge snd_hda_intel 51: 14 15 21 1105 IR-PCI-MSI 2621440-edge em1 52: 16579895 16579562 16580988 16583443 IR-PCI-MSI 524288-edge amdgpu NMI: 4 3 4 3 Non-maskable interrupts LOC: 15020 10425 8933 8584 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 4 3 4 3 Performance monitoring interrupts IWI: 1 1 1 1 IRQ work interrupts RTR: 0 0 0 0 APIC ICR read retries RES: 7203 5501 10621 5077 Rescheduling interrupts CAL: 498 559 614 591 Function call interrupts TLB: 58 149 104 95 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts DFR: 0 0 0 0 Deferred Error APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 1 1 1 1 Machine check polls HYP: 0 0 0 0 Hypervisor callback interrupts ERR: 1 MIS: 0 PIN: 0 0 0 0 Posted-interrupt notification event PIW: 0 0 0 0 Posted-interrupt wakeup event This worked fine on 4.1. Any ideas? Thanks, Alex > > Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> > Reported-by: Alex Deucher <alexdeucher@gmail.com> > Reported-by: Mark Rustad <mrustad@gmail.com> > Reported-by: Alexander Holler <holler@ahsoftware.de> > --- > Hi Alex, Mark and Alexandler, > Sorry for the long delay to root cause this regression, it's > really annoying. Could you please help test this patch against the > latest v4.2-rcx? > Thanks! > Gerry > --- > arch/x86/kernel/apic/vector.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c > index f813261d9740..2683f36e4e0a 100644 > --- a/arch/x86/kernel/apic/vector.c > +++ b/arch/x86/kernel/apic/vector.c > @@ -322,7 +322,7 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, unsigned int virq, > irq_data->chip = &lapic_controller; > irq_data->chip_data = data; > irq_data->hwirq = virq + i; > - err = assign_irq_vector_policy(virq, irq_data->node, data, > + err = assign_irq_vector_policy(virq + i, irq_data->node, data, > info); > if (err) > goto error; > -- > 1.7.10.4 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 2015-08-10 15:00 ` Alex Deucher @ 2015-08-11 1:06 ` Jiang Liu 2015-08-13 19:46 ` Alex Deucher 0 siblings, 1 reply; 16+ messages in thread From: Jiang Liu @ 2015-08-11 1:06 UTC (permalink / raw) To: Alex Deucher Cc: Thomas Gleixner, Alexander Holler, Mark Rustad, Ingo Molnar, H. Peter Anvin, x86, Tony Luck, LKML On 2015/8/10 23:00, Alex Deucher wrote: > On Sun, Aug 9, 2015 at 4:15 AM, Jiang Liu <jiang.liu@linux.intel.com> wrote: >> Alex Deucher, Mark Rustad and Alexander Holler reported a regression >> with the latest v4.2-rc4 kernel, which breaks some SATA controllers. >> With multi-MSI capable SATA controllers, only the first port works, >> all other ports times out when executing SATA commands. This regression >> bisects to 52f518a3a7c2 ("x86/MSI: Use hierarchical irqdomains to manage >> MSI interrupts"), but it's not the root cause, it just triggers a bug >> caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage >> CPU interrupt vectors"). >> >> With this patch applied, the affected SATA controllers work as expected. > > Yes, this fixes the SATA regression: > Tested-by: Alex Deucher <alexander.deucher@amd.com> > > I'm not sure if it's related to this patch or not (I haven't bisected > it independently yet), but MSIs don't seem to work on GPUs. See the > line for amdgpu. This is just after loading the driver. Hi Alex, This patch only affects multiple-MSI, and it seems that your gpu only uses one MSI interrupt, so it may not be related to this patch. And this seems like a sort of interrupt storm. > 52: 16579895 16579562 16580988 16583443 IR-PCI-MSI > 524288-edge amdgpu Does it make any change by disable interrupt remapping? Does it make any change by disable MSI? Thanks! Gerry > > $ cat /proc/interrupts > CPU0 CPU1 CPU2 CPU3 > 0: 138 0 0 0 IR-IO-APIC > 2-edge timer > 1: 2 2 1 4 IR-IO-APIC > 1-edge i8042 > 7: 1 0 0 0 IR-IO-APIC 7-edge > 8: 0 0 1 0 IR-IO-APIC > 8-edge rtc0 > 9: 0 0 0 0 IR-IO-APIC > 9-fasteoi acpi > 14: 0 0 0 0 IR-IO-APIC > 14-edge pata_atiixp > 15: 0 0 0 0 IR-IO-APIC > 15-edge pata_atiixp > 16: 302 303 301 314 IR-IO-APIC > 16-fasteoi snd_hda_intel > 17: 0 0 0 0 IR-IO-APIC > 17-fasteoi ehci_hcd:usb7, ehci_hcd:usb8 > 18: 0 0 0 0 IR-IO-APIC > 18-fasteoi ohci_hcd:usb9, ohci_hcd:usb10, ohci_hcd:usb11 > 24: 0 0 0 1 PCI-MSI 4096-edge > AMD-Vi > 26: 0 0 0 0 IR-PCI-MSI > 34816-edge PCIe PME > 27: 0 0 0 0 IR-PCI-MSI > 344064-edge PCIe PME > 28: 0 0 0 0 IR-PCI-MSI > 348160-edge PCIe PME > 29: 0 0 0 0 IR-PCI-MSI > 350208-edge PCIe PME > 30: 247 255 1381 4617 IR-PCI-MSI > 278528-edge ahci0 > 31: 162 163 164 181 IR-PCI-MSI > 278529-edge ahci1 > 34: 2 1 2 17 IR-PCI-MSI > 262144-edge xhci_hcd > 35: 0 0 0 0 IR-PCI-MSI > 262145-edge xhci_hcd > 36: 0 0 0 0 IR-PCI-MSI > 262146-edge xhci_hcd > 37: 0 0 0 0 IR-PCI-MSI > 262147-edge xhci_hcd > 38: 0 0 0 0 IR-PCI-MSI > 262148-edge xhci_hcd > 39: 0 0 0 0 IR-PCI-MSI > 264192-edge xhci_hcd > 40: 0 0 0 0 IR-PCI-MSI > 264193-edge xhci_hcd > 41: 0 0 0 0 IR-PCI-MSI > 264194-edge xhci_hcd > 42: 0 0 0 0 IR-PCI-MSI > 264195-edge xhci_hcd > 43: 0 0 0 0 IR-PCI-MSI > 264196-edge xhci_hcd > 44: 0 0 0 0 IR-PCI-MSI > 2097152-edge xhci_hcd > 45: 0 0 0 0 IR-PCI-MSI > 2097153-edge xhci_hcd > 46: 0 0 0 0 IR-PCI-MSI > 2097154-edge xhci_hcd > 47: 0 0 0 0 IR-PCI-MSI > 2097155-edge xhci_hcd > 48: 0 0 0 0 IR-PCI-MSI > 2097156-edge xhci_hcd > 50: 40 41 41 40 IR-PCI-MSI > 526336-edge snd_hda_intel > 51: 14 15 21 1105 IR-PCI-MSI > 2621440-edge em1 > 52: 16579895 16579562 16580988 16583443 IR-PCI-MSI > 524288-edge amdgpu > NMI: 4 3 4 3 Non-maskable interrupts > LOC: 15020 10425 8933 8584 Local timer interrupts > SPU: 0 0 0 0 Spurious interrupts > PMI: 4 3 4 3 Performance > monitoring interrupts > IWI: 1 1 1 1 IRQ work interrupts > RTR: 0 0 0 0 APIC ICR read retries > RES: 7203 5501 10621 5077 Rescheduling interrupts > CAL: 498 559 614 591 Function call interrupts > TLB: 58 149 104 95 TLB shootdowns > TRM: 0 0 0 0 Thermal event interrupts > THR: 0 0 0 0 Threshold APIC interrupts > DFR: 0 0 0 0 Deferred Error > APIC interrupts > MCE: 0 0 0 0 Machine check exceptions > MCP: 1 1 1 1 Machine check polls > HYP: 0 0 0 0 Hypervisor > callback interrupts > ERR: 1 > MIS: 0 > PIN: 0 0 0 0 Posted-interrupt > notification event > PIW: 0 0 0 0 Posted-interrupt > wakeup event > > This worked fine on 4.1. Any ideas? > > Thanks, > > Alex > > >> >> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> >> Reported-by: Alex Deucher <alexdeucher@gmail.com> >> Reported-by: Mark Rustad <mrustad@gmail.com> >> Reported-by: Alexander Holler <holler@ahsoftware.de> >> --- >> Hi Alex, Mark and Alexandler, >> Sorry for the long delay to root cause this regression, it's >> really annoying. Could you please help test this patch against the >> latest v4.2-rcx? >> Thanks! >> Gerry >> --- >> arch/x86/kernel/apic/vector.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c >> index f813261d9740..2683f36e4e0a 100644 >> --- a/arch/x86/kernel/apic/vector.c >> +++ b/arch/x86/kernel/apic/vector.c >> @@ -322,7 +322,7 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, unsigned int virq, >> irq_data->chip = &lapic_controller; >> irq_data->chip_data = data; >> irq_data->hwirq = virq + i; >> - err = assign_irq_vector_policy(virq, irq_data->node, data, >> + err = assign_irq_vector_policy(virq + i, irq_data->node, data, >> info); >> if (err) >> goto error; >> -- >> 1.7.10.4 >> > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 2015-08-11 1:06 ` Jiang Liu @ 2015-08-13 19:46 ` Alex Deucher 2015-08-13 20:15 ` Alex Deucher 0 siblings, 1 reply; 16+ messages in thread From: Alex Deucher @ 2015-08-13 19:46 UTC (permalink / raw) To: Jiang Liu Cc: Thomas Gleixner, Alexander Holler, Mark Rustad, Ingo Molnar, H. Peter Anvin, x86, Tony Luck, LKML On Mon, Aug 10, 2015 at 9:06 PM, Jiang Liu <jiang.liu@linux.intel.com> wrote: > On 2015/8/10 23:00, Alex Deucher wrote: >> On Sun, Aug 9, 2015 at 4:15 AM, Jiang Liu <jiang.liu@linux.intel.com> wrote: >>> Alex Deucher, Mark Rustad and Alexander Holler reported a regression >>> with the latest v4.2-rc4 kernel, which breaks some SATA controllers. >>> With multi-MSI capable SATA controllers, only the first port works, >>> all other ports times out when executing SATA commands. This regression >>> bisects to 52f518a3a7c2 ("x86/MSI: Use hierarchical irqdomains to manage >>> MSI interrupts"), but it's not the root cause, it just triggers a bug >>> caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage >>> CPU interrupt vectors"). >>> >>> With this patch applied, the affected SATA controllers work as expected. >> >> Yes, this fixes the SATA regression: >> Tested-by: Alex Deucher <alexander.deucher@amd.com> >> >> I'm not sure if it's related to this patch or not (I haven't bisected >> it independently yet), but MSIs don't seem to work on GPUs. See the >> line for amdgpu. This is just after loading the driver. > Hi Alex, > This patch only affects multiple-MSI, and it seems that your > gpu only uses one MSI interrupt, so it may not be related to this patch. > And this seems like a sort of interrupt storm. >> 52: 16579895 16579562 16580988 16583443 IR-PCI-MSI >> 524288-edge amdgpu > > Does it make any change by disable interrupt remapping? Nope. Still going crazy: 46: 4769660 4769130 4775899 4784657 PCI-MSI 524288-edge amdgpu > Does it make any change by disable MSI? If I set pci=nomsi, the sata controllers time out. If I disable MSIs just for the gpu, I don't get any interrupts: 25: 0 0 0 0 IR-IO-APIC 0-fasteoi amdgpu Alex > Thanks! > Gerry > >> >> $ cat /proc/interrupts >> CPU0 CPU1 CPU2 CPU3 >> 0: 138 0 0 0 IR-IO-APIC >> 2-edge timer >> 1: 2 2 1 4 IR-IO-APIC >> 1-edge i8042 >> 7: 1 0 0 0 IR-IO-APIC 7-edge >> 8: 0 0 1 0 IR-IO-APIC >> 8-edge rtc0 >> 9: 0 0 0 0 IR-IO-APIC >> 9-fasteoi acpi >> 14: 0 0 0 0 IR-IO-APIC >> 14-edge pata_atiixp >> 15: 0 0 0 0 IR-IO-APIC >> 15-edge pata_atiixp >> 16: 302 303 301 314 IR-IO-APIC >> 16-fasteoi snd_hda_intel >> 17: 0 0 0 0 IR-IO-APIC >> 17-fasteoi ehci_hcd:usb7, ehci_hcd:usb8 >> 18: 0 0 0 0 IR-IO-APIC >> 18-fasteoi ohci_hcd:usb9, ohci_hcd:usb10, ohci_hcd:usb11 >> 24: 0 0 0 1 PCI-MSI 4096-edge >> AMD-Vi >> 26: 0 0 0 0 IR-PCI-MSI >> 34816-edge PCIe PME >> 27: 0 0 0 0 IR-PCI-MSI >> 344064-edge PCIe PME >> 28: 0 0 0 0 IR-PCI-MSI >> 348160-edge PCIe PME >> 29: 0 0 0 0 IR-PCI-MSI >> 350208-edge PCIe PME >> 30: 247 255 1381 4617 IR-PCI-MSI >> 278528-edge ahci0 >> 31: 162 163 164 181 IR-PCI-MSI >> 278529-edge ahci1 >> 34: 2 1 2 17 IR-PCI-MSI >> 262144-edge xhci_hcd >> 35: 0 0 0 0 IR-PCI-MSI >> 262145-edge xhci_hcd >> 36: 0 0 0 0 IR-PCI-MSI >> 262146-edge xhci_hcd >> 37: 0 0 0 0 IR-PCI-MSI >> 262147-edge xhci_hcd >> 38: 0 0 0 0 IR-PCI-MSI >> 262148-edge xhci_hcd >> 39: 0 0 0 0 IR-PCI-MSI >> 264192-edge xhci_hcd >> 40: 0 0 0 0 IR-PCI-MSI >> 264193-edge xhci_hcd >> 41: 0 0 0 0 IR-PCI-MSI >> 264194-edge xhci_hcd >> 42: 0 0 0 0 IR-PCI-MSI >> 264195-edge xhci_hcd >> 43: 0 0 0 0 IR-PCI-MSI >> 264196-edge xhci_hcd >> 44: 0 0 0 0 IR-PCI-MSI >> 2097152-edge xhci_hcd >> 45: 0 0 0 0 IR-PCI-MSI >> 2097153-edge xhci_hcd >> 46: 0 0 0 0 IR-PCI-MSI >> 2097154-edge xhci_hcd >> 47: 0 0 0 0 IR-PCI-MSI >> 2097155-edge xhci_hcd >> 48: 0 0 0 0 IR-PCI-MSI >> 2097156-edge xhci_hcd >> 50: 40 41 41 40 IR-PCI-MSI >> 526336-edge snd_hda_intel >> 51: 14 15 21 1105 IR-PCI-MSI >> 2621440-edge em1 >> 52: 16579895 16579562 16580988 16583443 IR-PCI-MSI >> 524288-edge amdgpu >> NMI: 4 3 4 3 Non-maskable interrupts >> LOC: 15020 10425 8933 8584 Local timer interrupts >> SPU: 0 0 0 0 Spurious interrupts >> PMI: 4 3 4 3 Performance >> monitoring interrupts >> IWI: 1 1 1 1 IRQ work interrupts >> RTR: 0 0 0 0 APIC ICR read retries >> RES: 7203 5501 10621 5077 Rescheduling interrupts >> CAL: 498 559 614 591 Function call interrupts >> TLB: 58 149 104 95 TLB shootdowns >> TRM: 0 0 0 0 Thermal event interrupts >> THR: 0 0 0 0 Threshold APIC interrupts >> DFR: 0 0 0 0 Deferred Error >> APIC interrupts >> MCE: 0 0 0 0 Machine check exceptions >> MCP: 1 1 1 1 Machine check polls >> HYP: 0 0 0 0 Hypervisor >> callback interrupts >> ERR: 1 >> MIS: 0 >> PIN: 0 0 0 0 Posted-interrupt >> notification event >> PIW: 0 0 0 0 Posted-interrupt >> wakeup event >> >> This worked fine on 4.1. Any ideas? >> >> Thanks, >> >> Alex >> >> >>> >>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> >>> Reported-by: Alex Deucher <alexdeucher@gmail.com> >>> Reported-by: Mark Rustad <mrustad@gmail.com> >>> Reported-by: Alexander Holler <holler@ahsoftware.de> >>> --- >>> Hi Alex, Mark and Alexandler, >>> Sorry for the long delay to root cause this regression, it's >>> really annoying. Could you please help test this patch against the >>> latest v4.2-rcx? >>> Thanks! >>> Gerry >>> --- >>> arch/x86/kernel/apic/vector.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c >>> index f813261d9740..2683f36e4e0a 100644 >>> --- a/arch/x86/kernel/apic/vector.c >>> +++ b/arch/x86/kernel/apic/vector.c >>> @@ -322,7 +322,7 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, unsigned int virq, >>> irq_data->chip = &lapic_controller; >>> irq_data->chip_data = data; >>> irq_data->hwirq = virq + i; >>> - err = assign_irq_vector_policy(virq, irq_data->node, data, >>> + err = assign_irq_vector_policy(virq + i, irq_data->node, data, >>> info); >>> if (err) >>> goto error; >>> -- >>> 1.7.10.4 >>> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ >> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 2015-08-13 19:46 ` Alex Deucher @ 2015-08-13 20:15 ` Alex Deucher 2015-08-13 22:13 ` Alex Deucher 0 siblings, 1 reply; 16+ messages in thread From: Alex Deucher @ 2015-08-13 20:15 UTC (permalink / raw) To: Jiang Liu Cc: Thomas Gleixner, Alexander Holler, Mark Rustad, Ingo Molnar, H. Peter Anvin, x86, Tony Luck, LKML On Thu, Aug 13, 2015 at 3:46 PM, Alex Deucher <alexdeucher@gmail.com> wrote: > On Mon, Aug 10, 2015 at 9:06 PM, Jiang Liu <jiang.liu@linux.intel.com> wrote: >> On 2015/8/10 23:00, Alex Deucher wrote: >>> On Sun, Aug 9, 2015 at 4:15 AM, Jiang Liu <jiang.liu@linux.intel.com> wrote: >>>> Alex Deucher, Mark Rustad and Alexander Holler reported a regression >>>> with the latest v4.2-rc4 kernel, which breaks some SATA controllers. >>>> With multi-MSI capable SATA controllers, only the first port works, >>>> all other ports times out when executing SATA commands. This regression >>>> bisects to 52f518a3a7c2 ("x86/MSI: Use hierarchical irqdomains to manage >>>> MSI interrupts"), but it's not the root cause, it just triggers a bug >>>> caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage >>>> CPU interrupt vectors"). >>>> >>>> With this patch applied, the affected SATA controllers work as expected. >>> >>> Yes, this fixes the SATA regression: >>> Tested-by: Alex Deucher <alexander.deucher@amd.com> >>> >>> I'm not sure if it's related to this patch or not (I haven't bisected >>> it independently yet), but MSIs don't seem to work on GPUs. See the >>> line for amdgpu. This is just after loading the driver. >> Hi Alex, >> This patch only affects multiple-MSI, and it seems that your >> gpu only uses one MSI interrupt, so it may not be related to this patch. >> And this seems like a sort of interrupt storm. >>> 52: 16579895 16579562 16580988 16583443 IR-PCI-MSI >>> 524288-edge amdgpu >> >> Does it make any change by disable interrupt remapping? > > Nope. Still going crazy: > 46: 4769660 4769130 4775899 4784657 PCI-MSI > 524288-edge amdgpu > > >> Does it make any change by disable MSI? > > If I set pci=nomsi, the sata controllers time out. If I disable MSIs > just for the gpu, I don't get any interrupts: > 25: 0 0 0 0 IR-IO-APIC > 0-fasteoi amdgpu > Strangely, it only seems to affect certain boards. E.g., this card works fine: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire XT [Radeon HD 7790/8770 / R9 260 OEM] (prog-if 00 [VGA controller]) Subsystem: Diamond Multimedia Systems Device 2329 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort+ <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 52 Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at d0000000 (64-bit, prefetchable) [size=8M] Region 4: I/O ports at e000 [size=256] Region 5: Memory at ff600000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at ff640000 [disabled] [size=128K] Capabilities: [48] Vendor Specific Information: Len=08 <?> Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+, EqualizationPhase1+ EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest- Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee00000 Data: 0000 Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [150 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [270 v1] #19 Capabilities: [2b0 v1] Address Translation Service (ATS) ATSCap: Invalidate Queue Depth: 00 ATSCtl: Enable+, Smallest Translation Unit: 00 Capabilities: [2c0 v1] #13 Capabilities: [2d0 v1] #1b Kernel driver in use: amdgpu This one does not: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 6939 (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd Device 229d Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort+ <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 52 Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at d0000000 (64-bit, prefetchable) [size=2M] Region 4: I/O ports at e000 [size=256] Region 5: Memory at ff600000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at ff640000 [disabled] [size=128K] Capabilities: [48] Vendor Specific Information: Len=08 <?> Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+, EqualizationPhase1+ EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest- Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee00000 Data: 0000 Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [150 v2] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [200 v1] #15 Capabilities: [270 v1] #19 Capabilities: [2b0 v1] Address Translation Service (ATS) ATSCap: Invalidate Queue Depth: 00 ATSCtl: Enable+, Smallest Translation Unit: 00 Capabilities: [2c0 v1] #13 Capabilities: [2d0 v1] #1b Capabilities: [328 v1] Alternative Routing-ID Interpretation (ARI) ARICap: MFVC- ACS-, Next Function: 1 ARICtl: MFVC- ACS-, Function Group: 0 Kernel driver in use: amdgpu Any ideas? I'll see if I can find the time to bisect this. Alex > Alex > >> Thanks! >> Gerry >> >>> >>> $ cat /proc/interrupts >>> CPU0 CPU1 CPU2 CPU3 >>> 0: 138 0 0 0 IR-IO-APIC >>> 2-edge timer >>> 1: 2 2 1 4 IR-IO-APIC >>> 1-edge i8042 >>> 7: 1 0 0 0 IR-IO-APIC 7-edge >>> 8: 0 0 1 0 IR-IO-APIC >>> 8-edge rtc0 >>> 9: 0 0 0 0 IR-IO-APIC >>> 9-fasteoi acpi >>> 14: 0 0 0 0 IR-IO-APIC >>> 14-edge pata_atiixp >>> 15: 0 0 0 0 IR-IO-APIC >>> 15-edge pata_atiixp >>> 16: 302 303 301 314 IR-IO-APIC >>> 16-fasteoi snd_hda_intel >>> 17: 0 0 0 0 IR-IO-APIC >>> 17-fasteoi ehci_hcd:usb7, ehci_hcd:usb8 >>> 18: 0 0 0 0 IR-IO-APIC >>> 18-fasteoi ohci_hcd:usb9, ohci_hcd:usb10, ohci_hcd:usb11 >>> 24: 0 0 0 1 PCI-MSI 4096-edge >>> AMD-Vi >>> 26: 0 0 0 0 IR-PCI-MSI >>> 34816-edge PCIe PME >>> 27: 0 0 0 0 IR-PCI-MSI >>> 344064-edge PCIe PME >>> 28: 0 0 0 0 IR-PCI-MSI >>> 348160-edge PCIe PME >>> 29: 0 0 0 0 IR-PCI-MSI >>> 350208-edge PCIe PME >>> 30: 247 255 1381 4617 IR-PCI-MSI >>> 278528-edge ahci0 >>> 31: 162 163 164 181 IR-PCI-MSI >>> 278529-edge ahci1 >>> 34: 2 1 2 17 IR-PCI-MSI >>> 262144-edge xhci_hcd >>> 35: 0 0 0 0 IR-PCI-MSI >>> 262145-edge xhci_hcd >>> 36: 0 0 0 0 IR-PCI-MSI >>> 262146-edge xhci_hcd >>> 37: 0 0 0 0 IR-PCI-MSI >>> 262147-edge xhci_hcd >>> 38: 0 0 0 0 IR-PCI-MSI >>> 262148-edge xhci_hcd >>> 39: 0 0 0 0 IR-PCI-MSI >>> 264192-edge xhci_hcd >>> 40: 0 0 0 0 IR-PCI-MSI >>> 264193-edge xhci_hcd >>> 41: 0 0 0 0 IR-PCI-MSI >>> 264194-edge xhci_hcd >>> 42: 0 0 0 0 IR-PCI-MSI >>> 264195-edge xhci_hcd >>> 43: 0 0 0 0 IR-PCI-MSI >>> 264196-edge xhci_hcd >>> 44: 0 0 0 0 IR-PCI-MSI >>> 2097152-edge xhci_hcd >>> 45: 0 0 0 0 IR-PCI-MSI >>> 2097153-edge xhci_hcd >>> 46: 0 0 0 0 IR-PCI-MSI >>> 2097154-edge xhci_hcd >>> 47: 0 0 0 0 IR-PCI-MSI >>> 2097155-edge xhci_hcd >>> 48: 0 0 0 0 IR-PCI-MSI >>> 2097156-edge xhci_hcd >>> 50: 40 41 41 40 IR-PCI-MSI >>> 526336-edge snd_hda_intel >>> 51: 14 15 21 1105 IR-PCI-MSI >>> 2621440-edge em1 >>> 52: 16579895 16579562 16580988 16583443 IR-PCI-MSI >>> 524288-edge amdgpu >>> NMI: 4 3 4 3 Non-maskable interrupts >>> LOC: 15020 10425 8933 8584 Local timer interrupts >>> SPU: 0 0 0 0 Spurious interrupts >>> PMI: 4 3 4 3 Performance >>> monitoring interrupts >>> IWI: 1 1 1 1 IRQ work interrupts >>> RTR: 0 0 0 0 APIC ICR read retries >>> RES: 7203 5501 10621 5077 Rescheduling interrupts >>> CAL: 498 559 614 591 Function call interrupts >>> TLB: 58 149 104 95 TLB shootdowns >>> TRM: 0 0 0 0 Thermal event interrupts >>> THR: 0 0 0 0 Threshold APIC interrupts >>> DFR: 0 0 0 0 Deferred Error >>> APIC interrupts >>> MCE: 0 0 0 0 Machine check exceptions >>> MCP: 1 1 1 1 Machine check polls >>> HYP: 0 0 0 0 Hypervisor >>> callback interrupts >>> ERR: 1 >>> MIS: 0 >>> PIN: 0 0 0 0 Posted-interrupt >>> notification event >>> PIW: 0 0 0 0 Posted-interrupt >>> wakeup event >>> >>> This worked fine on 4.1. Any ideas? >>> >>> Thanks, >>> >>> Alex >>> >>> >>>> >>>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> >>>> Reported-by: Alex Deucher <alexdeucher@gmail.com> >>>> Reported-by: Mark Rustad <mrustad@gmail.com> >>>> Reported-by: Alexander Holler <holler@ahsoftware.de> >>>> --- >>>> Hi Alex, Mark and Alexandler, >>>> Sorry for the long delay to root cause this regression, it's >>>> really annoying. Could you please help test this patch against the >>>> latest v4.2-rcx? >>>> Thanks! >>>> Gerry >>>> --- >>>> arch/x86/kernel/apic/vector.c | 2 +- >>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>> >>>> diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c >>>> index f813261d9740..2683f36e4e0a 100644 >>>> --- a/arch/x86/kernel/apic/vector.c >>>> +++ b/arch/x86/kernel/apic/vector.c >>>> @@ -322,7 +322,7 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, unsigned int virq, >>>> irq_data->chip = &lapic_controller; >>>> irq_data->chip_data = data; >>>> irq_data->hwirq = virq + i; >>>> - err = assign_irq_vector_policy(virq, irq_data->node, data, >>>> + err = assign_irq_vector_policy(virq + i, irq_data->node, data, >>>> info); >>>> if (err) >>>> goto error; >>>> -- >>>> 1.7.10.4 >>>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >>> the body of a message to majordomo@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> Please read the FAQ at http://www.tux.org/lkml/ >>> ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 2015-08-13 20:15 ` Alex Deucher @ 2015-08-13 22:13 ` Alex Deucher 2015-08-25 4:03 ` Alex Deucher 0 siblings, 1 reply; 16+ messages in thread From: Alex Deucher @ 2015-08-13 22:13 UTC (permalink / raw) To: Jiang Liu Cc: Thomas Gleixner, Alexander Holler, Mark Rustad, Ingo Molnar, H. Peter Anvin, x86, Tony Luck, LKML On Thu, Aug 13, 2015 at 4:15 PM, Alex Deucher <alexdeucher@gmail.com> wrote: > On Thu, Aug 13, 2015 at 3:46 PM, Alex Deucher <alexdeucher@gmail.com> wrote: >> On Mon, Aug 10, 2015 at 9:06 PM, Jiang Liu <jiang.liu@linux.intel.com> wrote: >>> On 2015/8/10 23:00, Alex Deucher wrote: >>>> On Sun, Aug 9, 2015 at 4:15 AM, Jiang Liu <jiang.liu@linux.intel.com> wrote: >>>>> Alex Deucher, Mark Rustad and Alexander Holler reported a regression >>>>> with the latest v4.2-rc4 kernel, which breaks some SATA controllers. >>>>> With multi-MSI capable SATA controllers, only the first port works, >>>>> all other ports times out when executing SATA commands. This regression >>>>> bisects to 52f518a3a7c2 ("x86/MSI: Use hierarchical irqdomains to manage >>>>> MSI interrupts"), but it's not the root cause, it just triggers a bug >>>>> caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage >>>>> CPU interrupt vectors"). >>>>> >>>>> With this patch applied, the affected SATA controllers work as expected. >>>> >>>> Yes, this fixes the SATA regression: >>>> Tested-by: Alex Deucher <alexander.deucher@amd.com> >>>> >>>> I'm not sure if it's related to this patch or not (I haven't bisected >>>> it independently yet), but MSIs don't seem to work on GPUs. See the >>>> line for amdgpu. This is just after loading the driver. >>> Hi Alex, >>> This patch only affects multiple-MSI, and it seems that your >>> gpu only uses one MSI interrupt, so it may not be related to this patch. >>> And this seems like a sort of interrupt storm. >>>> 52: 16579895 16579562 16580988 16583443 IR-PCI-MSI >>>> 524288-edge amdgpu >>> >>> Does it make any change by disable interrupt remapping? >> >> Nope. Still going crazy: >> 46: 4769660 4769130 4775899 4784657 PCI-MSI >> 524288-edge amdgpu >> >> >>> Does it make any change by disable MSI? >> >> If I set pci=nomsi, the sata controllers time out. If I disable MSIs >> just for the gpu, I don't get any interrupts: >> 25: 0 0 0 0 IR-IO-APIC >> 0-fasteoi amdgpu >> > > Strangely, it only seems to affect certain boards. E.g., this card works fine: > 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. > [AMD/ATI] Bonaire XT [Radeon HD 7790/8770 / R9 260 OEM] (prog-if 00 > [VGA controller]) > Subsystem: Diamond Multimedia Systems Device 2329 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > <TAbort+ <MAbort- >SERR- <PERR- INTx- > Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 52 > Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M] > Region 2: Memory at d0000000 (64-bit, prefetchable) [size=8M] > Region 4: I/O ports at e000 [size=256] > Region 5: Memory at ff600000 (32-bit, non-prefetchable) [size=256K] > Expansion ROM at ff640000 [disabled] [size=128K] > Capabilities: [48] Vendor Specific Information: Len=08 <?> > Capabilities: [50] Power Management version 3 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA > PME(D0-,D1+,D2+,D3hot+,D3cold-) > Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00 > DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s > <4us, L1 unlimited > ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- > DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- > RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ > MaxPayload 256 bytes, MaxReadReq 512 bytes > DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- > LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit > Latency L0s <64ns, L1 <1us > ClockPM- Surprise- LLActRep- BwNot- > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > LnkSta: Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ > DLActive- BWMgmt- ABWMgmt- > DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, > OBFF Not Supported > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, > OBFF Disabled > LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- > Transmit Margin: Normal Operating Range, > EnterModifiedCompliance- ComplianceSOS- > Compliance De-emphasis: -6dB > LnkSta2: Current De-emphasis Level: -6dB, > EqualizationComplete+, EqualizationPhase1+ > EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest- > Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Address: 00000000fee00000 Data: 0000 > Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 > Len=010 <?> > Capabilities: [150 v2] Advanced Error Reporting > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- > UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- > RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ > CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ > AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- > Capabilities: [270 v1] #19 > Capabilities: [2b0 v1] Address Translation Service (ATS) > ATSCap: Invalidate Queue Depth: 00 > ATSCtl: Enable+, Smallest Translation Unit: 00 > Capabilities: [2c0 v1] #13 > Capabilities: [2d0 v1] #1b > Kernel driver in use: amdgpu > > This one does not: > 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. > [AMD/ATI] Device 6939 (prog-if 00 [VGA controller]) > Subsystem: Gigabyte Technology Co., Ltd Device 229d > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > <TAbort+ <MAbort- >SERR- <PERR- INTx- > Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 52 > Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M] > Region 2: Memory at d0000000 (64-bit, prefetchable) [size=2M] > Region 4: I/O ports at e000 [size=256] > Region 5: Memory at ff600000 (32-bit, non-prefetchable) [size=256K] > Expansion ROM at ff640000 [disabled] [size=128K] > Capabilities: [48] Vendor Specific Information: Len=08 <?> > Capabilities: [50] Power Management version 3 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA > PME(D0-,D1+,D2+,D3hot+,D3cold+) > Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00 > DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s > <4us, L1 unlimited > ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- > DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- > RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ > MaxPayload 256 bytes, MaxReadReq 512 bytes > DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- > LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit > Latency L0s <64ns, L1 <1us > ClockPM- Surprise- LLActRep- BwNot- > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > LnkSta: Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ > DLActive- BWMgmt- ABWMgmt- > DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, > OBFF Not Supported > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, > OBFF Disabled > LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- > Transmit Margin: Normal Operating Range, > EnterModifiedCompliance- ComplianceSOS- > Compliance De-emphasis: -6dB > LnkSta2: Current De-emphasis Level: -6dB, > EqualizationComplete+, EqualizationPhase1+ > EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest- > Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Address: 00000000fee00000 Data: 0000 > Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 > Len=010 <?> > Capabilities: [150 v2] Advanced Error Reporting > UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- > UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- > RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- > UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- > RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- > CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ > CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ > AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- > Capabilities: [200 v1] #15 > Capabilities: [270 v1] #19 > Capabilities: [2b0 v1] Address Translation Service (ATS) > ATSCap: Invalidate Queue Depth: 00 > ATSCtl: Enable+, Smallest Translation Unit: 00 > Capabilities: [2c0 v1] #13 > Capabilities: [2d0 v1] #1b > Capabilities: [328 v1] Alternative Routing-ID Interpretation (ARI) > ARICap: MFVC- ACS-, Next Function: 1 > ARICtl: MFVC- ACS-, Function Group: 0 > Kernel driver in use: amdgpu > > Any ideas? I'll see if I can find the time to bisect this. I attempted to bisect this, however the regression happened prior to my driver being merged upstream: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=099bfbfc7fbbe22356c02f0caf709ac32e1126ea So I can't easily bisect it further without backporting the driver to each commit before that. This may take a while... Alex ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 2015-08-13 22:13 ` Alex Deucher @ 2015-08-25 4:03 ` Alex Deucher 2015-08-25 4:46 ` Jiang Liu 0 siblings, 1 reply; 16+ messages in thread From: Alex Deucher @ 2015-08-25 4:03 UTC (permalink / raw) To: Jiang Liu Cc: Thomas Gleixner, Alexander Holler, Mark Rustad, Ingo Molnar, H. Peter Anvin, x86, Tony Luck, LKML On Thu, Aug 13, 2015 at 6:13 PM, Alex Deucher <alexdeucher@gmail.com> wrote: > On Thu, Aug 13, 2015 at 4:15 PM, Alex Deucher <alexdeucher@gmail.com> wrote: >> On Thu, Aug 13, 2015 at 3:46 PM, Alex Deucher <alexdeucher@gmail.com> wrote: >>> On Mon, Aug 10, 2015 at 9:06 PM, Jiang Liu <jiang.liu@linux.intel.com> wrote: >>>> On 2015/8/10 23:00, Alex Deucher wrote: >>>>> On Sun, Aug 9, 2015 at 4:15 AM, Jiang Liu <jiang.liu@linux.intel.com> wrote: >>>>>> Alex Deucher, Mark Rustad and Alexander Holler reported a regression >>>>>> with the latest v4.2-rc4 kernel, which breaks some SATA controllers. >>>>>> With multi-MSI capable SATA controllers, only the first port works, >>>>>> all other ports times out when executing SATA commands. This regression >>>>>> bisects to 52f518a3a7c2 ("x86/MSI: Use hierarchical irqdomains to manage >>>>>> MSI interrupts"), but it's not the root cause, it just triggers a bug >>>>>> caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage >>>>>> CPU interrupt vectors"). >>>>>> >>>>>> With this patch applied, the affected SATA controllers work as expected. >>>>> >>>>> Yes, this fixes the SATA regression: >>>>> Tested-by: Alex Deucher <alexander.deucher@amd.com> >>>>> >>>>> I'm not sure if it's related to this patch or not (I haven't bisected >>>>> it independently yet), but MSIs don't seem to work on GPUs. See the >>>>> line for amdgpu. This is just after loading the driver. >>>> Hi Alex, >>>> This patch only affects multiple-MSI, and it seems that your >>>> gpu only uses one MSI interrupt, so it may not be related to this patch. >>>> And this seems like a sort of interrupt storm. >>>>> 52: 16579895 16579562 16580988 16583443 IR-PCI-MSI >>>>> 524288-edge amdgpu >>>> >>>> Does it make any change by disable interrupt remapping? >>> >>> Nope. Still going crazy: >>> 46: 4769660 4769130 4775899 4784657 PCI-MSI >>> 524288-edge amdgpu >>> >>> >>>> Does it make any change by disable MSI? >>> >>> If I set pci=nomsi, the sata controllers time out. If I disable MSIs >>> just for the gpu, I don't get any interrupts: >>> 25: 0 0 0 0 IR-IO-APIC >>> 0-fasteoi amdgpu >>> >> >> Strangely, it only seems to affect certain boards. E.g., this card works fine: >> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. >> [AMD/ATI] Bonaire XT [Radeon HD 7790/8770 / R9 260 OEM] (prog-if 00 >> [VGA controller]) >> Subsystem: Diamond Multimedia Systems Device 2329 >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >> ParErr- Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >> <TAbort+ <MAbort- >SERR- <PERR- INTx- >> Latency: 0, Cache Line Size: 64 bytes >> Interrupt: pin A routed to IRQ 52 >> Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M] >> Region 2: Memory at d0000000 (64-bit, prefetchable) [size=8M] >> Region 4: I/O ports at e000 [size=256] >> Region 5: Memory at ff600000 (32-bit, non-prefetchable) [size=256K] >> Expansion ROM at ff640000 [disabled] [size=128K] >> Capabilities: [48] Vendor Specific Information: Len=08 <?> >> Capabilities: [50] Power Management version 3 >> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA >> PME(D0-,D1+,D2+,D3hot+,D3cold-) >> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- >> Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00 >> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s >> <4us, L1 unlimited >> ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- >> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ >> MaxPayload 256 bytes, MaxReadReq 512 bytes >> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- >> LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit >> Latency L0s <64ns, L1 <1us >> ClockPM- Surprise- LLActRep- BwNot- >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ >> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >> LnkSta: Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ >> DLActive- BWMgmt- ABWMgmt- >> DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, >> OBFF Not Supported >> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, >> OBFF Disabled >> LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- >> Transmit Margin: Normal Operating Range, >> EnterModifiedCompliance- ComplianceSOS- >> Compliance De-emphasis: -6dB >> LnkSta2: Current De-emphasis Level: -6dB, >> EqualizationComplete+, EqualizationPhase1+ >> EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest- >> Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ >> Address: 00000000fee00000 Data: 0000 >> Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 >> Len=010 <?> >> Capabilities: [150 v2] Advanced Error Reporting >> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- >> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- >> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- >> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- >> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ >> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ >> AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- >> Capabilities: [270 v1] #19 >> Capabilities: [2b0 v1] Address Translation Service (ATS) >> ATSCap: Invalidate Queue Depth: 00 >> ATSCtl: Enable+, Smallest Translation Unit: 00 >> Capabilities: [2c0 v1] #13 >> Capabilities: [2d0 v1] #1b >> Kernel driver in use: amdgpu >> >> This one does not: >> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. >> [AMD/ATI] Device 6939 (prog-if 00 [VGA controller]) >> Subsystem: Gigabyte Technology Co., Ltd Device 229d >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >> ParErr- Stepping- SERR- FastB2B- DisINTx+ >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- >> <TAbort+ <MAbort- >SERR- <PERR- INTx- >> Latency: 0, Cache Line Size: 64 bytes >> Interrupt: pin A routed to IRQ 52 >> Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M] >> Region 2: Memory at d0000000 (64-bit, prefetchable) [size=2M] >> Region 4: I/O ports at e000 [size=256] >> Region 5: Memory at ff600000 (32-bit, non-prefetchable) [size=256K] >> Expansion ROM at ff640000 [disabled] [size=128K] >> Capabilities: [48] Vendor Specific Information: Len=08 <?> >> Capabilities: [50] Power Management version 3 >> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA >> PME(D0-,D1+,D2+,D3hot+,D3cold+) >> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- >> Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00 >> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s >> <4us, L1 unlimited >> ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- >> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- >> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ >> MaxPayload 256 bytes, MaxReadReq 512 bytes >> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- >> LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit >> Latency L0s <64ns, L1 <1us >> ClockPM- Surprise- LLActRep- BwNot- >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ >> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >> LnkSta: Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ >> DLActive- BWMgmt- ABWMgmt- >> DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, >> OBFF Not Supported >> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, >> OBFF Disabled >> LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis- >> Transmit Margin: Normal Operating Range, >> EnterModifiedCompliance- ComplianceSOS- >> Compliance De-emphasis: -6dB >> LnkSta2: Current De-emphasis Level: -6dB, >> EqualizationComplete+, EqualizationPhase1+ >> EqualizationPhase2+, EqualizationPhase3+, LinkEqualizationRequest- >> Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ >> Address: 00000000fee00000 Data: 0000 >> Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 >> Len=010 <?> >> Capabilities: [150 v2] Advanced Error Reporting >> UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- >> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >> UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- >> RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- >> UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- >> RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- >> CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ >> CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ >> AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- >> Capabilities: [200 v1] #15 >> Capabilities: [270 v1] #19 >> Capabilities: [2b0 v1] Address Translation Service (ATS) >> ATSCap: Invalidate Queue Depth: 00 >> ATSCtl: Enable+, Smallest Translation Unit: 00 >> Capabilities: [2c0 v1] #13 >> Capabilities: [2d0 v1] #1b >> Capabilities: [328 v1] Alternative Routing-ID Interpretation (ARI) >> ARICap: MFVC- ACS-, Next Function: 1 >> ARICtl: MFVC- ACS-, Function Group: 0 >> Kernel driver in use: amdgpu >> >> Any ideas? I'll see if I can find the time to bisect this. > > I attempted to bisect this, however the regression happened prior to > my driver being merged upstream: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=099bfbfc7fbbe22356c02f0caf709ac32e1126ea > So I can't easily bisect it further without backporting the driver to > each commit before that. This may take a while... Just a heads up, this ended up being an alignment issue in the driver and was not a regression. Alex > > Alex ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 2015-08-25 4:03 ` Alex Deucher @ 2015-08-25 4:46 ` Jiang Liu 0 siblings, 0 replies; 16+ messages in thread From: Jiang Liu @ 2015-08-25 4:46 UTC (permalink / raw) To: Alex Deucher Cc: Thomas Gleixner, Alexander Holler, Mark Rustad, Ingo Molnar, H. Peter Anvin, x86, Tony Luck, LKML On 2015/8/25 12:03, Alex Deucher wrote: > On Thu, Aug 13, 2015 at 6:13 PM, Alex Deucher <alexdeucher@gmail.com> wrote: >>> Any ideas? I'll see if I can find the time to bisect this. >> >> I attempted to bisect this, however the regression happened prior to >> my driver being merged upstream: >> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=099bfbfc7fbbe22356c02f0caf709ac32e1126ea >> So I can't easily bisect it further without backporting the driver to >> each commit before that. This may take a while... > > Just a heads up, this ended up being an alignment issue in the driver > and was not a regression. Thanks for confirmation:) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 2015-08-09 8:15 [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 Jiang Liu 2015-08-09 10:14 ` Alexander Holler 2015-08-10 15:00 ` Alex Deucher @ 2015-08-10 16:47 ` Rustad, Mark D 2015-08-17 21:02 ` Alex Deucher 2015-08-17 21:11 ` Thomas Gleixner 4 siblings, 0 replies; 16+ messages in thread From: Rustad, Mark D @ 2015-08-10 16:47 UTC (permalink / raw) To: Jiang Liu Cc: Thomas Gleixner, Alexander Holler, Alex Deucher, Ingo Molnar, H. Peter Anvin, x86@kernel.org, Luck, Tony, linux-kernel@vger.kernel.org [-- Attachment #1: Type: text/plain, Size: 1216 bytes --] Gerry, > On Aug 9, 2015, at 1:15 AM, Jiang Liu <jiang.liu@linux.intel.com> wrote: > > Alex Deucher, Mark Rustad and Alexander Holler reported a regression > with the latest v4.2-rc4 kernel, which breaks some SATA controllers. > With multi-MSI capable SATA controllers, only the first port works, > all other ports times out when executing SATA commands. This regression > bisects to 52f518a3a7c2 ("x86/MSI: Use hierarchical irqdomains to manage > MSI interrupts"), but it's not the root cause, it just triggers a bug > caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage > CPU interrupt vectors"). > > With this patch applied, the affected SATA controllers work as expected. I see the same thing here as well. > Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> > Reported-by: Alex Deucher <alexdeucher@gmail.com> > Reported-by: Mark Rustad <mrustad@gmail.com> > Reported-by: Alexander Holler <holler@ahsoftware.de> > --- > Hi Alex, Mark and Alexandler, > Sorry for the long delay to root cause this regression, it's > really annoying. Could you please help test this patch against the > latest v4.2-rcx? It works for me. Thanks. -- Mark Rustad, Networking Division, Intel Corporation [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 841 bytes --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 2015-08-09 8:15 [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 Jiang Liu ` (2 preceding siblings ...) 2015-08-10 16:47 ` Rustad, Mark D @ 2015-08-17 21:02 ` Alex Deucher 2015-08-18 12:53 ` Thomas Gleixner 2015-08-17 21:11 ` Thomas Gleixner 4 siblings, 1 reply; 16+ messages in thread From: Alex Deucher @ 2015-08-17 21:02 UTC (permalink / raw) To: Jiang Liu Cc: Thomas Gleixner, Alexander Holler, Mark Rustad, Ingo Molnar, H. Peter Anvin, x86, Tony Luck, LKML On Sun, Aug 9, 2015 at 4:15 AM, Jiang Liu <jiang.liu@linux.intel.com> wrote: > Alex Deucher, Mark Rustad and Alexander Holler reported a regression > with the latest v4.2-rc4 kernel, which breaks some SATA controllers. > With multi-MSI capable SATA controllers, only the first port works, > all other ports times out when executing SATA commands. This regression > bisects to 52f518a3a7c2 ("x86/MSI: Use hierarchical irqdomains to manage > MSI interrupts"), but it's not the root cause, it just triggers a bug > caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage > CPU interrupt vectors"). > > With this patch applied, the affected SATA controllers work as expected. I don't see this upstream yet. Any chance this will make 4.2? Alex > > Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> > Reported-by: Alex Deucher <alexdeucher@gmail.com> > Reported-by: Mark Rustad <mrustad@gmail.com> > Reported-by: Alexander Holler <holler@ahsoftware.de> > --- > Hi Alex, Mark and Alexandler, > Sorry for the long delay to root cause this regression, it's > really annoying. Could you please help test this patch against the > latest v4.2-rcx? > Thanks! > Gerry > --- > arch/x86/kernel/apic/vector.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c > index f813261d9740..2683f36e4e0a 100644 > --- a/arch/x86/kernel/apic/vector.c > +++ b/arch/x86/kernel/apic/vector.c > @@ -322,7 +322,7 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, unsigned int virq, > irq_data->chip = &lapic_controller; > irq_data->chip_data = data; > irq_data->hwirq = virq + i; > - err = assign_irq_vector_policy(virq, irq_data->node, data, > + err = assign_irq_vector_policy(virq + i, irq_data->node, data, > info); > if (err) > goto error; > -- > 1.7.10.4 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 2015-08-17 21:02 ` Alex Deucher @ 2015-08-18 12:53 ` Thomas Gleixner 0 siblings, 0 replies; 16+ messages in thread From: Thomas Gleixner @ 2015-08-18 12:53 UTC (permalink / raw) To: Alex Deucher Cc: Jiang Liu, Alexander Holler, Mark Rustad, Ingo Molnar, H. Peter Anvin, x86, Tony Luck, LKML On Mon, 17 Aug 2015, Alex Deucher wrote: > On Sun, Aug 9, 2015 at 4:15 AM, Jiang Liu <jiang.liu@linux.intel.com> wrote: > > Alex Deucher, Mark Rustad and Alexander Holler reported a regression > > with the latest v4.2-rc4 kernel, which breaks some SATA controllers. > > With multi-MSI capable SATA controllers, only the first port works, > > all other ports times out when executing SATA commands. This regression > > bisects to 52f518a3a7c2 ("x86/MSI: Use hierarchical irqdomains to manage > > MSI interrupts"), but it's not the root cause, it just triggers a bug > > caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage > > CPU interrupt vectors"). > > > > With this patch applied, the affected SATA controllers work as expected. > > I don't see this upstream yet. Any chance this will make 4.2? Yes, it's going to be there. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 2015-08-09 8:15 [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 Jiang Liu ` (3 preceding siblings ...) 2015-08-17 21:02 ` Alex Deucher @ 2015-08-17 21:11 ` Thomas Gleixner 2015-08-18 15:20 ` [Bugfix] x86, irq: Fix an error in building CPU vector to IRQ number mapping for MSI Jiang Liu 4 siblings, 1 reply; 16+ messages in thread From: Thomas Gleixner @ 2015-08-17 21:11 UTC (permalink / raw) To: Jiang Liu Cc: Alexander Holler, Mark Rustad, Alex Deucher, Ingo Molnar, H. Peter Anvin, x86, Tony Luck, linux-kernel On Sun, 9 Aug 2015, Jiang Liu wrote: > Alex Deucher, Mark Rustad and Alexander Holler reported a regression > with the latest v4.2-rc4 kernel, which breaks some SATA controllers. > With multi-MSI capable SATA controllers, only the first port works, > all other ports times out when executing SATA commands. This regression > bisects to 52f518a3a7c2 ("x86/MSI: Use hierarchical irqdomains to manage > MSI interrupts"), but it's not the root cause, it just triggers a bug > caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage > CPU interrupt vectors"). > > With this patch applied, the affected SATA controllers work as expected. This changelog including the subject line is horrible. 1) The subject line should describe the change in a short and precise form x86/irq: Fix a regression caused by commit b5dc8e6c21e7 fits the short category, but completely fails to be precise. It's not interesting for the subject line which commit caused the problem and whether it's a regression or not. We want a to see a proper description of the change itself. 2) The changelog should describe the bug itself. ... but it's not the root cause, it just triggers a bug caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors"). does not tell what the actual bug in the code is. 3) The changelog should describe the solution. With this patch applied, the affected SATA controllers work as expected. is describing the desired effect of the change, but not the change itself. Thanks, tglx ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bugfix] x86, irq: Fix an error in building CPU vector to IRQ number mapping for MSI 2015-08-17 21:11 ` Thomas Gleixner @ 2015-08-18 15:20 ` Jiang Liu 2015-08-18 16:21 ` [tip:x86/urgent] x86/irq: Build correct vector mapping for multiple MSI interrupts tip-bot for Jiang Liu 0 siblings, 1 reply; 16+ messages in thread From: Jiang Liu @ 2015-08-18 15:20 UTC (permalink / raw) To: Thomas Gleixner, Alexander Holler, Mark Rustad, Alex Deucher, Ingo Molnar, H. Peter Anvin, x86, Jiang Liu Cc: Tony Luck, linux-kernel Alex Deucher, Mark Rustad and Alexander Holler reported a regression with the latest v4.2-rc4 kernel, which breaks some SATA controllers. With multi-MSI capable SATA controllers, only the first port works, all other ports times out when executing SATA commands. The regression is caused by b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors"), which builds wrong CPU vector to IRQ number mappings for second and subsequent IRQs of multiple MSIs and causes that all MSI IRQs are handled as the first MSI IRQ. So fix the regression by building correct CPU vector to IRQ number mappings for multiple MSIs. Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Reported-and-tested-by: Alex Deucher <alexdeucher@gmail.com> Reported-and-tested-by: Mark Rustad <mrustad@gmail.com> Reported-and-tested-by: Alexander Holler <holler@ahsoftware.de> --- arch/x86/kernel/apic/vector.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c index f813261d9740..2683f36e4e0a 100644 --- a/arch/x86/kernel/apic/vector.c +++ b/arch/x86/kernel/apic/vector.c @@ -322,7 +322,7 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, unsigned int virq, irq_data->chip = &lapic_controller; irq_data->chip_data = data; irq_data->hwirq = virq + i; - err = assign_irq_vector_policy(virq, irq_data->node, data, + err = assign_irq_vector_policy(virq + i, irq_data->node, data, info); if (err) goto error; -- 1.7.10.4 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [tip:x86/urgent] x86/irq: Build correct vector mapping for multiple MSI interrupts 2015-08-18 15:20 ` [Bugfix] x86, irq: Fix an error in building CPU vector to IRQ number mapping for MSI Jiang Liu @ 2015-08-18 16:21 ` tip-bot for Jiang Liu 0 siblings, 0 replies; 16+ messages in thread From: tip-bot for Jiang Liu @ 2015-08-18 16:21 UTC (permalink / raw) To: linux-tip-commits Cc: mingo, hpa, alexdeucher, tglx, tony.luck, holler, mrustad, linux-kernel, jiang.liu Commit-ID: 527f0a91e91cd55ec79fce80451b0ad5d5e6a21a Gitweb: http://git.kernel.org/tip/527f0a91e91cd55ec79fce80451b0ad5d5e6a21a Author: Jiang Liu <jiang.liu@linux.intel.com> AuthorDate: Tue, 18 Aug 2015 23:20:20 +0800 Committer: Thomas Gleixner <tglx@linutronix.de> CommitDate: Tue, 18 Aug 2015 18:18:55 +0200 x86/irq: Build correct vector mapping for multiple MSI interrupts Alex Deucher, Mark Rustad and Alexander Holler reported a regression with the latest v4.2-rc4 kernel, which breaks some SATA controllers. With multi-MSI capable SATA controllers, only the first port works, all other ports time out when executing SATA commands. This happens because the first argument to assign_irq_vector_policy() is always the base linux irq number of the multi MSI interrupt block, so all subsequent vector assignments operate on the base linux irq number, so all MSI irqs are handled as the first irq number. Therefor the other MSI irqs of a device are never set up correctly and never fire. Add the loop iterator to the base irq number so all vectors are assigned correctly. Fixes: b5dc8e6c21e7 "x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors" Reported-and-tested-by: Alex Deucher <alexdeucher@gmail.com> Reported-and-tested-by: Mark Rustad <mrustad@gmail.com> Reported-and-tested-by: Alexander Holler <holler@ahsoftware.de> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Cc: Tony Luck <tony.luck@intel.com> Link: http://lkml.kernel.org/r/1439911228-9880-1-git-send-email-jiang.liu@linux.intel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> --- arch/x86/kernel/apic/vector.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c index f813261..2683f36 100644 --- a/arch/x86/kernel/apic/vector.c +++ b/arch/x86/kernel/apic/vector.c @@ -322,7 +322,7 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, unsigned int virq, irq_data->chip = &lapic_controller; irq_data->chip_data = data; irq_data->hwirq = virq + i; - err = assign_irq_vector_policy(virq, irq_data->node, data, + err = assign_irq_vector_policy(virq + i, irq_data->node, data, info); if (err) goto error; ^ permalink raw reply related [flat|nested] 16+ messages in thread
end of thread, other threads:[~2015-08-25 4:46 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-08-09 8:15 [Bugfix] x86, irq: Fix a regression caused by commit b5dc8e6c21e7 Jiang Liu 2015-08-09 10:14 ` Alexander Holler 2015-08-09 14:11 ` Jiang Liu 2015-08-10 15:00 ` Alex Deucher 2015-08-11 1:06 ` Jiang Liu 2015-08-13 19:46 ` Alex Deucher 2015-08-13 20:15 ` Alex Deucher 2015-08-13 22:13 ` Alex Deucher 2015-08-25 4:03 ` Alex Deucher 2015-08-25 4:46 ` Jiang Liu 2015-08-10 16:47 ` Rustad, Mark D 2015-08-17 21:02 ` Alex Deucher 2015-08-18 12:53 ` Thomas Gleixner 2015-08-17 21:11 ` Thomas Gleixner 2015-08-18 15:20 ` [Bugfix] x86, irq: Fix an error in building CPU vector to IRQ number mapping for MSI Jiang Liu 2015-08-18 16:21 ` [tip:x86/urgent] x86/irq: Build correct vector mapping for multiple MSI interrupts tip-bot for Jiang Liu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox