* kernel-4.7 bug in Intel sound and/or ACPI @ 2016-06-20 0:35 Wim Osterholt 2016-06-20 1:02 ` Rafael J. Wysocki 0 siblings, 1 reply; 24+ messages in thread From: Wim Osterholt @ 2016-06-20 0:35 UTC (permalink / raw) To: linux-kernel; +Cc: Wim Osterholt, linux-acpi, perex L.S. up to vanilla kernel-4.6.2 sound was working fine. Switching to kernel-4.7.0-rc3 made sound disappear. No /dev/mixer etc. There appears to be a bug in the Intel sound driver and/or ACPI driver. Dmesg shows interesting lines like: [ 11.498592] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7 [ 11.498605] PCI: setting IRQ 7 as level-triggered [ 11.543903] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP] [ 12.757735] genirq: Flags mismatch irq 7. 00000080 (snd_intel8x0m) vs. 00000000 (parport0) [ 12.757751] snd_intel8x0m 0000:00:1f.6: unable to grab IRQ 7 [ 12.757875] snd_intel8x0m: probe of 0000:00:1f.6 failed with error -16 [ 12.900171] genirq: Flags mismatch irq 7. 00000080 (snd_intel8x0) vs. 00000000 (parport0) [ 12.900189] snd_intel8x0 0000:00:1f.5: unable to grab IRQ 7 [ 12.900389] snd_intel8x0: probe of 0000:00:1f.5 failed with error -16 [ 12.922554] genirq: Flags mismatch irq 7. 00000080 (ipw2200) vs. 00000000 (parport0) [ 12.922559] ipw2200: Error allocating IRQ 7 If I boot kernel-4.7.0-rc3 with acpi=off then sound is back! If you need the full dmesg outputs then please get them here: http://webserver.djo.tudelft.nl/dmesg460+ACPI http://webserver.djo.tudelft.nl/dmesg473+ACPI http://webserver.djo.tudelft.nl/dmesg473noACPI (with excuses for the silly hostname which is out of our control) Regards, Wim. ----- wim@djo.tudelft.nl ----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-20 0:35 kernel-4.7 bug in Intel sound and/or ACPI Wim Osterholt @ 2016-06-20 1:02 ` Rafael J. Wysocki 2016-06-20 21:25 ` Bjorn Helgaas 0 siblings, 1 reply; 24+ messages in thread From: Rafael J. Wysocki @ 2016-06-20 1:02 UTC (permalink / raw) To: wim; +Cc: linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai You should CC the linux-pci too (done now) On Monday, June 20, 2016 02:35:30 AM Wim Osterholt wrote: > L.S. > up to vanilla kernel-4.6.2 sound was working fine. > Switching to kernel-4.7.0-rc3 made sound disappear. No /dev/mixer etc. > There appears to be a bug in the Intel sound driver and/or ACPI driver. > Dmesg shows interesting lines like: > [ 11.498592] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7 > [ 11.498605] PCI: setting IRQ 7 as level-triggered > [ 11.543903] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP] > [ 12.757735] genirq: Flags mismatch irq 7. 00000080 (snd_intel8x0m) vs. 00000000 (parport0) > [ 12.757751] snd_intel8x0m 0000:00:1f.6: unable to grab IRQ 7 > [ 12.757875] snd_intel8x0m: probe of 0000:00:1f.6 failed with error -16 > [ 12.900171] genirq: Flags mismatch irq 7. 00000080 (snd_intel8x0) vs. 00000000 (parport0) > [ 12.900189] snd_intel8x0 0000:00:1f.5: unable to grab IRQ 7 > [ 12.900389] snd_intel8x0: probe of 0000:00:1f.5 failed with error -16 > [ 12.922554] genirq: Flags mismatch irq 7. 00000080 (ipw2200) vs. 00000000 (parport0) > [ 12.922559] ipw2200: Error allocating IRQ 7 > > If I boot kernel-4.7.0-rc3 with acpi=off then sound is back! > > If you need the full dmesg outputs then please get them here: > http://webserver.djo.tudelft.nl/dmesg460+ACPI > http://webserver.djo.tudelft.nl/dmesg473+ACPI > http://webserver.djo.tudelft.nl/dmesg473noACPI > (with excuses for the silly hostname which is out of our control) > > Regards, Wim. > > > ----- wim@djo.tudelft.nl ----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-20 1:02 ` Rafael J. Wysocki @ 2016-06-20 21:25 ` Bjorn Helgaas 2016-06-20 22:25 ` Sinan Kaya 0 siblings, 1 reply; 24+ messages in thread From: Bjorn Helgaas @ 2016-06-20 21:25 UTC (permalink / raw) To: Rafael J. Wysocki Cc: wim, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, Sinan Kaya [+cc Sinan] On Mon, Jun 20, 2016 at 03:02:57AM +0200, Rafael J. Wysocki wrote: > You should CC the linux-pci too (done now) > > On Monday, June 20, 2016 02:35:30 AM Wim Osterholt wrote: > > L.S. > > up to vanilla kernel-4.6.2 sound was working fine. > > Switching to kernel-4.7.0-rc3 made sound disappear. No /dev/mixer etc. > > There appears to be a bug in the Intel sound driver and/or ACPI driver. > > Dmesg shows interesting lines like: > > [ 11.498592] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7 > > [ 11.498605] PCI: setting IRQ 7 as level-triggered > > [ 11.543903] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP] > > [ 12.757735] genirq: Flags mismatch irq 7. 00000080 (snd_intel8x0m) vs. 00000000 (parport0) > > [ 12.757751] snd_intel8x0m 0000:00:1f.6: unable to grab IRQ 7 > > [ 12.757875] snd_intel8x0m: probe of 0000:00:1f.6 failed with error -16 > > [ 12.900171] genirq: Flags mismatch irq 7. 00000080 (snd_intel8x0) vs. 00000000 (parport0) > > [ 12.900189] snd_intel8x0 0000:00:1f.5: unable to grab IRQ 7 > > [ 12.900389] snd_intel8x0: probe of 0000:00:1f.5 failed with error -16 > > [ 12.922554] genirq: Flags mismatch irq 7. 00000080 (ipw2200) vs. 00000000 (parport0) > > [ 12.922559] ipw2200: Error allocating IRQ 7 > > > > If I boot kernel-4.7.0-rc3 with acpi=off then sound is back! > > > > If you need the full dmesg outputs then please get them here: > > http://webserver.djo.tudelft.nl/dmesg460+ACPI > > http://webserver.djo.tudelft.nl/dmesg473+ACPI > > http://webserver.djo.tudelft.nl/dmesg473noACPI > > (with excuses for the silly hostname which is out of our control) I think snd_intel8x0 (00:1f.5) is connected to LNKB, and in v4.6 LNKB was set to IRQ 5, while in v4.7 LNKB is connected to IRQ7. It looks like IRQ7 is already in use by parport, which doesn't want to share it. This might be related to Sinan's changes to pci_link.c, which were merged for 4.7: 9e5ed6d1fb87 ACPI,PCI,IRQ: remove SCI penalize function 1fcb6a813c4f ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init() 5c5087a55390 ACPI,PCI,IRQ: reduce static IRQ array size to 16 103544d86976 ACPI,PCI,IRQ: reduce resource requirements I don't think we intended to change any behavior with those patches, but maybe we did. Could you confirm/deny that those patches are related? If they're not, bisection might be the quickest way to find the problem. Bjorn ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-20 21:25 ` Bjorn Helgaas @ 2016-06-20 22:25 ` Sinan Kaya 2016-06-21 12:47 ` Wim Osterholt 0 siblings, 1 reply; 24+ messages in thread From: Sinan Kaya @ 2016-06-20 22:25 UTC (permalink / raw) To: Bjorn Helgaas, Rafael J. Wysocki Cc: wim, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai On 6/20/2016 5:25 PM, Bjorn Helgaas wrote: > [+cc Sinan] > > On Mon, Jun 20, 2016 at 03:02:57AM +0200, Rafael J. Wysocki wrote: >> You should CC the linux-pci too (done now) >> >> On Monday, June 20, 2016 02:35:30 AM Wim Osterholt wrote: >>> L.S. >>> up to vanilla kernel-4.6.2 sound was working fine. >>> Switching to kernel-4.7.0-rc3 made sound disappear. No /dev/mixer etc. >>> There appears to be a bug in the Intel sound driver and/or ACPI driver. >>> Dmesg shows interesting lines like: >>> [ 11.498592] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 7 >>> [ 11.498605] PCI: setting IRQ 7 as level-triggered >>> [ 11.543903] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP] >>> [ 12.757735] genirq: Flags mismatch irq 7. 00000080 (snd_intel8x0m) vs. 00000000 (parport0) >>> [ 12.757751] snd_intel8x0m 0000:00:1f.6: unable to grab IRQ 7 >>> [ 12.757875] snd_intel8x0m: probe of 0000:00:1f.6 failed with error -16 >>> [ 12.900171] genirq: Flags mismatch irq 7. 00000080 (snd_intel8x0) vs. 00000000 (parport0) >>> [ 12.900189] snd_intel8x0 0000:00:1f.5: unable to grab IRQ 7 >>> [ 12.900389] snd_intel8x0: probe of 0000:00:1f.5 failed with error -16 >>> [ 12.922554] genirq: Flags mismatch irq 7. 00000080 (ipw2200) vs. 00000000 (parport0) >>> [ 12.922559] ipw2200: Error allocating IRQ 7 >>> >>> If I boot kernel-4.7.0-rc3 with acpi=off then sound is back! >>> >>> If you need the full dmesg outputs then please get them here: >>> http://webserver.djo.tudelft.nl/dmesg460+ACPI >>> http://webserver.djo.tudelft.nl/dmesg473+ACPI >>> http://webserver.djo.tudelft.nl/dmesg473noACPI >>> (with excuses for the silly hostname which is out of our control) > > I think snd_intel8x0 (00:1f.5) is connected to LNKB, and in v4.6 LNKB > was set to IRQ 5, while in v4.7 LNKB is connected to IRQ7. It looks > like IRQ7 is already in use by parport, which doesn't want to share > it. > > This might be related to Sinan's changes to pci_link.c, which > were merged for 4.7: > > 9e5ed6d1fb87 ACPI,PCI,IRQ: remove SCI penalize function > 1fcb6a813c4f ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init() > 5c5087a55390 ACPI,PCI,IRQ: reduce static IRQ array size to 16 > 103544d86976 ACPI,PCI,IRQ: reduce resource requirements > > I don't think we intended to change any behavior with those patches, > but maybe we did. Could you confirm/deny that those patches are > related? If they're not, bisection might be the quickest way to > find the problem. > I agree. The intention was not to change the existing behavior. I am trying to decode what this means. [ 0.305642] ACPI: PCI Interrupt Link [LNKA] (IRQs 9 10 *11) [ 0.306365] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 7) *11 [ 0.307078] ACPI: PCI Interrupt Link [LNKC] (IRQs 9 10 *11) [ 0.307791] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 7 9 10 *11) It looks like the syntax is ((possible irqs) *active irq) It looks like both 5 and 7 are possible for LNKB and 11 is the active IRQ. Since 5 and 7 are listed as possible, I don't understand what makes 7 not a good IRQ. Anyhow, I did some code inspection. I am seeing some problems around the acpi_irq_get_penalty function. The acpi_irq_get_penalty function is both a get and set function for PCI IRQs. However, it looks like we are accounting the penalty twice when using ISA IRQs. Can you try the following and see if it makes any difference? --- a/drivers/acpi/pci_link.c +++ b/drivers/acpi/pci_link.c @@ -500,7 +500,7 @@ static int acpi_irq_get_penalty(int irq) int penalty = 0; if (irq < ACPI_MAX_ISA_IRQS) - penalty += acpi_isa_irq_penalty[irq]; + return acpi_isa_irq_penalty[irq]; /* * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict @@ -586,6 +586,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link) acpi_device_bid(link->device)); return -ENODEV; } else { + if (irq < ACPI_MAX_ISA_IRQS) + acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) + + PIRQ_PENALTY_PCI_USING; + > Bjorn > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-20 22:25 ` Sinan Kaya @ 2016-06-21 12:47 ` Wim Osterholt 2016-06-21 13:40 ` Sinan Kaya 0 siblings, 1 reply; 24+ messages in thread From: Wim Osterholt @ 2016-06-21 12:47 UTC (permalink / raw) To: Sinan Kaya Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, Wim Osterholt > Can you try the following and see if it makes any difference? > > > --- a/drivers/acpi/pci_link.c > +++ b/drivers/acpi/pci_link.c > @@ -500,7 +500,7 @@ static int acpi_irq_get_penalty(int irq) > int penalty = 0; > > if (irq < ACPI_MAX_ISA_IRQS) > - penalty += acpi_isa_irq_penalty[irq]; > + return acpi_isa_irq_penalty[irq]; > > /* > * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict > @@ -586,6 +586,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link) > acpi_device_bid(link->device)); > return -ENODEV; > } else { > + if (irq < ACPI_MAX_ISA_IRQS) > + acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) + > + PIRQ_PENALTY_PCI_USING; > + > > > > > Bjorn I tried this on kernel 4.7.0-rc4, but that didn't help. It still tried to grab irq7. Regards, Wim. ----- wim@djo.tudelft.nl ----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-21 12:47 ` Wim Osterholt @ 2016-06-21 13:40 ` Sinan Kaya 2016-06-21 22:13 ` Wim Osterholt 0 siblings, 1 reply; 24+ messages in thread From: Sinan Kaya @ 2016-06-21 13:40 UTC (permalink / raw) To: wim Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai On 6/21/2016 8:47 AM, Wim Osterholt wrote: >> Can you try the following and see if it makes any difference? >> >> >> --- a/drivers/acpi/pci_link.c >> +++ b/drivers/acpi/pci_link.c >> @@ -500,7 +500,7 @@ static int acpi_irq_get_penalty(int irq) >> int penalty = 0; >> >> if (irq < ACPI_MAX_ISA_IRQS) >> - penalty += acpi_isa_irq_penalty[irq]; >> + return acpi_isa_irq_penalty[irq]; >> >> /* >> * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict >> @@ -586,6 +586,10 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link) >> acpi_device_bid(link->device)); >> return -ENODEV; >> } else { >> + if (irq < ACPI_MAX_ISA_IRQS) >> + acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) + >> + PIRQ_PENALTY_PCI_USING; >> + >> >> >> >>> Bjorn > > > I tried this on kernel 4.7.0-rc4, but that didn't help. It still tried to > grab irq7. > > Thanks, It was a guess with no proof. Let's undo the change above and start adding some print statements to collect data from your system. Can you add this to the end of acpi_irq_get_penalty function and then send the output? pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq, penalty); > Regards, Wim. > > > ----- wim@djo.tudelft.nl ----- > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-21 13:40 ` Sinan Kaya @ 2016-06-21 22:13 ` Wim Osterholt 2016-06-23 3:54 ` okaya 0 siblings, 1 reply; 24+ messages in thread From: Wim Osterholt @ 2016-06-21 22:13 UTC (permalink / raw) To: Sinan Kaya Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, Wim Osterholt On Tue, Jun 21, 2016 at 09:40:10AM -0400, Sinan Kaya wrote: > > Thanks, It was a guess with no proof. > > Let's undo the change above and start adding some print statements to collect > data from your system. > > Can you add this to the end of acpi_irq_get_penalty function and then send > the output? > > pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq, > penalty); > This produced some 60 lines extra. Too much to include here. The entire dmesg file is here: http://webserver.djo.tudelft.nl/dmesg474+printpenalty Regards, Wim. ----- wim@djo.tudelft.nl ----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-21 22:13 ` Wim Osterholt @ 2016-06-23 3:54 ` okaya 2016-06-23 14:12 ` Wim Osterholt 0 siblings, 1 reply; 24+ messages in thread From: okaya @ 2016-06-23 3:54 UTC (permalink / raw) To: wim Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner On 2016-06-21 18:13, Wim Osterholt wrote: > On Tue, Jun 21, 2016 at 09:40:10AM -0400, Sinan Kaya wrote: >> >> Thanks, It was a guess with no proof. >> >> Let's undo the change above and start adding some print statements to >> collect >> data from your system. >> >> Can you add this to the end of acpi_irq_get_penalty function and then >> send >> the output? >> >> pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq, >> penalty); >> > > This produced some 60 lines extra. Too much to include here. > The entire dmesg file is here: > http://webserver.djo.tudelft.nl/dmesg474+printpenalty Thanks, let's go back to 4.6 and add a very similar printf to every single place where the array is modified and also right before the enabled message. I am trying to find a system with similar characteristics for debug > > > Regards, Wim. > > > ----- wim@djo.tudelft.nl ----- > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-23 3:54 ` okaya @ 2016-06-23 14:12 ` Wim Osterholt 2016-06-23 14:55 ` Sinan Kaya 0 siblings, 1 reply; 24+ messages in thread From: Wim Osterholt @ 2016-06-23 14:12 UTC (permalink / raw) To: okaya Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner, Wim Osterholt On Wed, Jun 22, 2016 at 11:54:39PM -0400, okaya@codeaurora.org wrote: > On 2016-06-21 18:13, Wim Osterholt wrote: > >> > >> pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq, > >> penalty); > >> > > > > This produced some 60 lines extra.... > > Thanks, let's go back to 4.6 and add a very similar printf to every > single place where the array is modified and also right before the > enabled message. > I don't get this right. Assuming that you're still talking about the same file, I find a few instances of 'enabled', most of them in if-statements and one where it might be set, so it looks. However, that's already in a printk statement. I don't know about arrays and even less where these are set. Even worse, I don't know what to put in a 'similar' line if you don't mean 'exactly the same'. So please state file and line numbers and the line to be inserted. Groeten, Wim. ----- wim@djo.tudelft.nl ----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-23 14:12 ` Wim Osterholt @ 2016-06-23 14:55 ` Sinan Kaya 2016-06-23 15:45 ` Sinan Kaya 0 siblings, 1 reply; 24+ messages in thread From: Sinan Kaya @ 2016-06-23 14:55 UTC (permalink / raw) To: wim Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner On 6/23/2016 10:12 AM, Wim Osterholt wrote: > On Wed, Jun 22, 2016 at 11:54:39PM -0400, okaya@codeaurora.org wrote: >> On 2016-06-21 18:13, Wim Osterholt wrote: >>>> >>>> pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq, >>>> penalty); >>>> >>> >>> This produced some 60 lines extra.... >> >> Thanks, let's go back to 4.6 and add a very similar printf to every >> single place where the array is modified and also right before the >> enabled message. >> > > I don't get this right. > Assuming that you're still talking about the same file, I find a few > instances of 'enabled', most of them in if-statements and one where it might > be set, so it looks. However, that's already in a printk statement. > I don't know about arrays and even less where these are set. Even worse, I > don't know what to put in a 'similar' line if you don't mean 'exactly the > same'. > So please state file and line numbers and the line to be inserted. > Sure, let me get a patch for you. I was hoping to do it yesterday. I ran out of time. I typed the message from my phone. > > > Groeten, Wim. > > > ----- wim@djo.tudelft.nl ----- > -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-23 14:55 ` Sinan Kaya @ 2016-06-23 15:45 ` Sinan Kaya 2016-06-23 16:21 ` Bjorn Helgaas 2016-06-23 23:25 ` Wim Osterholt 0 siblings, 2 replies; 24+ messages in thread From: Sinan Kaya @ 2016-06-23 15:45 UTC (permalink / raw) To: wim Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner [-- Attachment #1: Type: text/plain, Size: 1367 bytes --] On 6/23/2016 10:55 AM, Sinan Kaya wrote: > On 6/23/2016 10:12 AM, Wim Osterholt wrote: >> On Wed, Jun 22, 2016 at 11:54:39PM -0400, okaya@codeaurora.org wrote: >>> On 2016-06-21 18:13, Wim Osterholt wrote: >>>>> >>>>> pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq, >>>>> penalty); >>>>> >>>> >>>> This produced some 60 lines extra.... >>> >>> Thanks, let's go back to 4.6 and add a very similar printf to every >>> single place where the array is modified and also right before the >>> enabled message. >>> >> >> I don't get this right. >> Assuming that you're still talking about the same file, I find a few >> instances of 'enabled', most of them in if-statements and one where it might >> be set, so it looks. However, that's already in a printk statement. >> I don't know about arrays and even less where these are set. Even worse, I >> don't know what to put in a 'similar' line if you don't mean 'exactly the >> same'. >> So please state file and line numbers and the line to be inserted. >> > > Sure, let me get a patch for you. I was hoping to do it yesterday. > I ran out of time. I typed the message from my phone. > Here it is -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project [-- Attachment #2: irq_link.patch --] [-- Type: text/plain, Size: 3183 bytes --] diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c index ededa90..228b61f 100644 --- a/drivers/acpi/pci_link.c +++ b/drivers/acpi/pci_link.c @@ -487,15 +487,18 @@ int __init acpi_irq_penalty_init(void) link->irq.possible_count; for (i = 0; i < link->irq.possible_count; i++) { - if (link->irq.possible[i] < ACPI_MAX_ISA_IRQ) + if (link->irq.possible[i] < ACPI_MAX_ISA_IRQ) { acpi_irq_penalty[link->irq. possible[i]] += penalty; + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, link->irq.possible[i], acpi_irq_penalty[link->irq.possible[i]]); + } } } else if (link->irq.active) { acpi_irq_penalty[link->irq.active] += PIRQ_PENALTY_PCI_POSSIBLE; + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, link->irq.active, acpi_irq_penalty[link->irq.active]); } } @@ -548,8 +551,11 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link) */ for (i = (link->irq.possible_count - 1); i >= 0; i--) { if (acpi_irq_penalty[irq] > - acpi_irq_penalty[link->irq.possible[i]]) + acpi_irq_penalty[link->irq.possible[i]]) { + pr_info("%s:%d acpi_irq_penalty[irq=%d](0x%x) vs. acpi_irq_penalty[%d](0x%x)\n", + __func__, __LINE__, irq, acpi_irq_penalty[irq], link->irq.possible[i], acpi_irq_penalty[link->irq.possible[i]]); irq = link->irq.possible[i]; + } } } if (acpi_irq_penalty[irq] >= PIRQ_PENALTY_ISA_ALWAYS) { @@ -569,6 +575,7 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link) return -ENODEV; } else { acpi_irq_penalty[link->irq.active] += PIRQ_PENALTY_PCI_USING; + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, link->irq.active, acpi_irq_penalty[link->irq.active]); printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n", acpi_device_name(link->device), acpi_device_bid(link->device), link->irq.active); @@ -804,6 +811,8 @@ static int __init acpi_irq_penalty_update(char *str, int used) else acpi_irq_penalty[irq] = PIRQ_PENALTY_PCI_AVAILABLE; + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, irq, acpi_irq_penalty[irq]); + if (retval != 2) /* no next number */ break; } @@ -824,11 +833,16 @@ void acpi_penalize_isa_irq(int irq, int active) acpi_irq_penalty[irq] += PIRQ_PENALTY_ISA_USED; else acpi_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING; + + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, irq, acpi_irq_penalty[irq]); } } bool acpi_isa_irq_available(int irq) { + if (irq >= 0 && (irq < ARRAY_SIZE(acpi_irq_penalty))) + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, irq, acpi_irq_penalty[irq]); + return irq >= 0 && (irq >= ARRAY_SIZE(acpi_irq_penalty) || acpi_irq_penalty[irq] < PIRQ_PENALTY_ISA_ALWAYS); } @@ -846,6 +860,8 @@ void acpi_penalize_sci_irq(int irq, int trigger, int polarity) acpi_irq_penalty[irq] += PIRQ_PENALTY_ISA_ALWAYS; else acpi_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING; + + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, irq, acpi_irq_penalty[irq]); } } ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-23 15:45 ` Sinan Kaya @ 2016-06-23 16:21 ` Bjorn Helgaas 2016-06-23 17:05 ` Alex Williamson 2016-06-23 23:25 ` Wim Osterholt 1 sibling, 1 reply; 24+ messages in thread From: Bjorn Helgaas @ 2016-06-23 16:21 UTC (permalink / raw) To: Sinan Kaya Cc: wim, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner, Alex Williamson [+cc Alex, FYI] This thread is about a regression that we'll want to fix before v4.7 releases. It looks like it's related to these changes which were merged via the ACPI tree: 9e5ed6d1fb87 ACPI,PCI,IRQ: remove SCI penalize function 1fcb6a813c4f ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init() 5c5087a55390 ACPI,PCI,IRQ: reduce static IRQ array size to 16 103544d86976 ACPI,PCI,IRQ: reduce resource requirements If that turns out to be the case, it probably makes sense to merge the fix via the ACPI tree as well. But in the unlikely event the fix turns out to be in PCI, Alex will probably have to merge it because I'll be on vacation. So I'm adding Alex to the CC: list in case that happens. On Thu, Jun 23, 2016 at 11:45:47AM -0400, Sinan Kaya wrote: > On 6/23/2016 10:55 AM, Sinan Kaya wrote: > > On 6/23/2016 10:12 AM, Wim Osterholt wrote: > >> On Wed, Jun 22, 2016 at 11:54:39PM -0400, okaya@codeaurora.org wrote: > >>> On 2016-06-21 18:13, Wim Osterholt wrote: > >>>>> > >>>>> pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq, > >>>>> penalty); > >>>>> > >>>> > >>>> This produced some 60 lines extra.... > >>> > >>> Thanks, let's go back to 4.6 and add a very similar printf to every > >>> single place where the array is modified and also right before the > >>> enabled message. > >>> > >> > >> I don't get this right. > >> Assuming that you're still talking about the same file, I find a few > >> instances of 'enabled', most of them in if-statements and one where it might > >> be set, so it looks. However, that's already in a printk statement. > >> I don't know about arrays and even less where these are set. Even worse, I > >> don't know what to put in a 'similar' line if you don't mean 'exactly the > >> same'. > >> So please state file and line numbers and the line to be inserted. > >> > > > > Sure, let me get a patch for you. I was hoping to do it yesterday. > > I ran out of time. I typed the message from my phone. > > > > Here it is > > > > -- > Sinan Kaya > Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c > index ededa90..228b61f 100644 > --- a/drivers/acpi/pci_link.c > +++ b/drivers/acpi/pci_link.c > @@ -487,15 +487,18 @@ int __init acpi_irq_penalty_init(void) > link->irq.possible_count; > > for (i = 0; i < link->irq.possible_count; i++) { > - if (link->irq.possible[i] < ACPI_MAX_ISA_IRQ) > + if (link->irq.possible[i] < ACPI_MAX_ISA_IRQ) { > acpi_irq_penalty[link->irq. > possible[i]] += > penalty; > + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, link->irq.possible[i], acpi_irq_penalty[link->irq.possible[i]]); > + } > } > > } else if (link->irq.active) { > acpi_irq_penalty[link->irq.active] += > PIRQ_PENALTY_PCI_POSSIBLE; > + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, link->irq.active, acpi_irq_penalty[link->irq.active]); > } > } > > @@ -548,8 +551,11 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link) > */ > for (i = (link->irq.possible_count - 1); i >= 0; i--) { > if (acpi_irq_penalty[irq] > > - acpi_irq_penalty[link->irq.possible[i]]) > + acpi_irq_penalty[link->irq.possible[i]]) { > + pr_info("%s:%d acpi_irq_penalty[irq=%d](0x%x) vs. acpi_irq_penalty[%d](0x%x)\n", > + __func__, __LINE__, irq, acpi_irq_penalty[irq], link->irq.possible[i], acpi_irq_penalty[link->irq.possible[i]]); > irq = link->irq.possible[i]; > + } > } > } > if (acpi_irq_penalty[irq] >= PIRQ_PENALTY_ISA_ALWAYS) { > @@ -569,6 +575,7 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link) > return -ENODEV; > } else { > acpi_irq_penalty[link->irq.active] += PIRQ_PENALTY_PCI_USING; > + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, link->irq.active, acpi_irq_penalty[link->irq.active]); > printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n", > acpi_device_name(link->device), > acpi_device_bid(link->device), link->irq.active); > @@ -804,6 +811,8 @@ static int __init acpi_irq_penalty_update(char *str, int used) > else > acpi_irq_penalty[irq] = PIRQ_PENALTY_PCI_AVAILABLE; > > + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, irq, acpi_irq_penalty[irq]); > + > if (retval != 2) /* no next number */ > break; > } > @@ -824,11 +833,16 @@ void acpi_penalize_isa_irq(int irq, int active) > acpi_irq_penalty[irq] += PIRQ_PENALTY_ISA_USED; > else > acpi_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING; > + > + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, irq, acpi_irq_penalty[irq]); > } > } > > bool acpi_isa_irq_available(int irq) > { > + if (irq >= 0 && (irq < ARRAY_SIZE(acpi_irq_penalty))) > + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, irq, acpi_irq_penalty[irq]); > + > return irq >= 0 && (irq >= ARRAY_SIZE(acpi_irq_penalty) || > acpi_irq_penalty[irq] < PIRQ_PENALTY_ISA_ALWAYS); > } > @@ -846,6 +860,8 @@ void acpi_penalize_sci_irq(int irq, int trigger, int polarity) > acpi_irq_penalty[irq] += PIRQ_PENALTY_ISA_ALWAYS; > else > acpi_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING; > + > + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, irq, acpi_irq_penalty[irq]); > } > } > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-23 16:21 ` Bjorn Helgaas @ 2016-06-23 17:05 ` Alex Williamson 0 siblings, 0 replies; 24+ messages in thread From: Alex Williamson @ 2016-06-23 17:05 UTC (permalink / raw) To: Bjorn Helgaas Cc: Sinan Kaya, wim, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner On Thu, 23 Jun 2016 11:21:58 -0500 Bjorn Helgaas <helgaas@kernel.org> wrote: > [+cc Alex, FYI] > > This thread is about a regression that we'll want to fix before v4.7 > releases. It looks like it's related to these changes which were > merged via the ACPI tree: > > 9e5ed6d1fb87 ACPI,PCI,IRQ: remove SCI penalize function > 1fcb6a813c4f ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init() > 5c5087a55390 ACPI,PCI,IRQ: reduce static IRQ array size to 16 > 103544d86976 ACPI,PCI,IRQ: reduce resource requirements > > If that turns out to be the case, it probably makes sense to merge the fix > via the ACPI tree as well. But in the unlikely event the fix turns out to > be in PCI, Alex will probably have to merge it because I'll be on vacation. > So I'm adding Alex to the CC: list in case that happens. Thanks, I'm watching it now. I'll also encourage anyone posting other fixes that they feel are relevant to v4.7 while Bjorn is away to please proactively poke me. Bjorn is pretty strict about only accepting regression fixes after the merge window and I intend to do the same. Thanks, Alex > On Thu, Jun 23, 2016 at 11:45:47AM -0400, Sinan Kaya wrote: > > On 6/23/2016 10:55 AM, Sinan Kaya wrote: > > > On 6/23/2016 10:12 AM, Wim Osterholt wrote: > > >> On Wed, Jun 22, 2016 at 11:54:39PM -0400, okaya@codeaurora.org wrote: > > >>> On 2016-06-21 18:13, Wim Osterholt wrote: > > >>>>> > > >>>>> pr_info("%s:%d irq = %d penalty = %d\n", __func__, __LINE__, irq, > > >>>>> penalty); > > >>>>> > > >>>> > > >>>> This produced some 60 lines extra.... > > >>> > > >>> Thanks, let's go back to 4.6 and add a very similar printf to every > > >>> single place where the array is modified and also right before the > > >>> enabled message. > > >>> > > >> > > >> I don't get this right. > > >> Assuming that you're still talking about the same file, I find a few > > >> instances of 'enabled', most of them in if-statements and one where it might > > >> be set, so it looks. However, that's already in a printk statement. > > >> I don't know about arrays and even less where these are set. Even worse, I > > >> don't know what to put in a 'similar' line if you don't mean 'exactly the > > >> same'. > > >> So please state file and line numbers and the line to be inserted. > > >> > > > > > > Sure, let me get a patch for you. I was hoping to do it yesterday. > > > I ran out of time. I typed the message from my phone. > > > > > > > Here it is > > > > > > > > -- > > Sinan Kaya > > Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. > > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project > > > diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c > > index ededa90..228b61f 100644 > > --- a/drivers/acpi/pci_link.c > > +++ b/drivers/acpi/pci_link.c > > @@ -487,15 +487,18 @@ int __init acpi_irq_penalty_init(void) > > link->irq.possible_count; > > > > for (i = 0; i < link->irq.possible_count; i++) { > > - if (link->irq.possible[i] < ACPI_MAX_ISA_IRQ) > > + if (link->irq.possible[i] < ACPI_MAX_ISA_IRQ) { > > acpi_irq_penalty[link->irq. > > possible[i]] += > > penalty; > > + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, link->irq.possible[i], acpi_irq_penalty[link->irq.possible[i]]); > > + } > > } > > > > } else if (link->irq.active) { > > acpi_irq_penalty[link->irq.active] += > > PIRQ_PENALTY_PCI_POSSIBLE; > > + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, link->irq.active, acpi_irq_penalty[link->irq.active]); > > } > > } > > > > @@ -548,8 +551,11 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link) > > */ > > for (i = (link->irq.possible_count - 1); i >= 0; i--) { > > if (acpi_irq_penalty[irq] > > > - acpi_irq_penalty[link->irq.possible[i]]) > > + acpi_irq_penalty[link->irq.possible[i]]) { > > + pr_info("%s:%d acpi_irq_penalty[irq=%d](0x%x) vs. acpi_irq_penalty[%d](0x%x)\n", > > + __func__, __LINE__, irq, acpi_irq_penalty[irq], link->irq.possible[i], acpi_irq_penalty[link->irq.possible[i]]); > > irq = link->irq.possible[i]; > > + } > > } > > } > > if (acpi_irq_penalty[irq] >= PIRQ_PENALTY_ISA_ALWAYS) { > > @@ -569,6 +575,7 @@ static int acpi_pci_link_allocate(struct acpi_pci_link *link) > > return -ENODEV; > > } else { > > acpi_irq_penalty[link->irq.active] += PIRQ_PENALTY_PCI_USING; > > + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, link->irq.active, acpi_irq_penalty[link->irq.active]); > > printk(KERN_WARNING PREFIX "%s [%s] enabled at IRQ %d\n", > > acpi_device_name(link->device), > > acpi_device_bid(link->device), link->irq.active); > > @@ -804,6 +811,8 @@ static int __init acpi_irq_penalty_update(char *str, int used) > > else > > acpi_irq_penalty[irq] = PIRQ_PENALTY_PCI_AVAILABLE; > > > > + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, irq, acpi_irq_penalty[irq]); > > + > > if (retval != 2) /* no next number */ > > break; > > } > > @@ -824,11 +833,16 @@ void acpi_penalize_isa_irq(int irq, int active) > > acpi_irq_penalty[irq] += PIRQ_PENALTY_ISA_USED; > > else > > acpi_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING; > > + > > + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, irq, acpi_irq_penalty[irq]); > > } > > } > > > > bool acpi_isa_irq_available(int irq) > > { > > + if (irq >= 0 && (irq < ARRAY_SIZE(acpi_irq_penalty))) > > + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, irq, acpi_irq_penalty[irq]); > > + > > return irq >= 0 && (irq >= ARRAY_SIZE(acpi_irq_penalty) || > > acpi_irq_penalty[irq] < PIRQ_PENALTY_ISA_ALWAYS); > > } > > @@ -846,6 +860,8 @@ void acpi_penalize_sci_irq(int irq, int trigger, int polarity) > > acpi_irq_penalty[irq] += PIRQ_PENALTY_ISA_ALWAYS; > > else > > acpi_irq_penalty[irq] += PIRQ_PENALTY_PCI_USING; > > + > > + pr_info("%s:%d acpi_irq_penalty[%d] = 0x%x\n", __func__, __LINE__, irq, acpi_irq_penalty[irq]); > > } > > } > > > ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-23 15:45 ` Sinan Kaya 2016-06-23 16:21 ` Bjorn Helgaas @ 2016-06-23 23:25 ` Wim Osterholt 2016-06-24 6:09 ` Sinan Kaya 1 sibling, 1 reply; 24+ messages in thread From: Wim Osterholt @ 2016-06-23 23:25 UTC (permalink / raw) To: Sinan Kaya Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner, Wim Osterholt On Thu, Jun 23, 2016 at 11:45:47AM -0400, Sinan Kaya wrote: > > > > Sure, let me get a patch for you. > > Here it is http://webserver.djo.tudelft.nl/dmesg460+printpatch2 > I am trying to find a system with similar characteristics for debug All from the same laptop, Dell Inspiron 4100. The same problem arises at a Dell Inspiron 510m. I've not seen it on a workstation Dell XW4300. Groeten, Wim. ----- wim@djo.tudelft.nl ----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-23 23:25 ` Wim Osterholt @ 2016-06-24 6:09 ` Sinan Kaya 2016-06-25 1:39 ` Wim Osterholt 0 siblings, 1 reply; 24+ messages in thread From: Sinan Kaya @ 2016-06-24 6:09 UTC (permalink / raw) To: wim Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner, Alex Williamson [-- Attachment #1: Type: text/plain, Size: 1041 bytes --] On 6/23/2016 7:25 PM, Wim Osterholt wrote: > On Thu, Jun 23, 2016 at 11:45:47AM -0400, Sinan Kaya wrote: >>> >>> Sure, let me get a patch for you. >> >> Here it is > > http://webserver.djo.tudelft.nl/dmesg460+printpatch2 > Thanks, this was very helpful. I was able to fix the problem by using the values in your log. Can you give it a try? > >> I am trying to find a system with similar characteristics for debug > > All from the same laptop, Dell Inspiron 4100. > The same problem arises at a Dell Inspiron 510m. > I've not seen it on a workstation Dell XW4300. > > > > Groeten, Wim. > > > ----- wim@djo.tudelft.nl ----- > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project [-- Attachment #2: 0002-Revert-ACPI-PCI-IRQ-remove-redundant-code-in-acpi_ir.patch --] [-- Type: text/plain, Size: 2859 bytes --] >From 44dabd4b7413a4edee4b7399f95f6ce10c8bbd27 Mon Sep 17 00:00:00 2001 From: Sinan Kaya <okaya@codeaurora.org> Date: Fri, 24 Jun 2016 01:04:05 -0400 Subject: [PATCH 2/4] Revert "ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init()" Trying to make the ISA and PCI init functionality common turned out to be a bad idea. ISA path depends on external functionality. Restoring the previous behavior and limiting the refactoring to PCI interrupts only. This reverts commit 1fcb6a813c4f ("ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init()"). Signed-off-by: Sinan Kaya <okaya@codeaurora.org> --- arch/x86/pci/acpi.c | 1 + drivers/acpi/pci_link.c | 36 ++++++++++++++++++++++++++++++++++++ include/acpi/acpi_drivers.h | 1 + 3 files changed, 38 insertions(+) diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c index b2a4e2a..3cd6983 100644 --- a/arch/x86/pci/acpi.c +++ b/arch/x86/pci/acpi.c @@ -396,6 +396,7 @@ int __init pci_acpi_init(void) return -ENODEV; printk(KERN_INFO "PCI: Using ACPI for IRQ routing\n"); + acpi_irq_penalty_init(); pcibios_enable_irq = acpi_pci_irq_enable; pcibios_disable_irq = acpi_pci_irq_disable; x86_init.pci.init_irq = x86_init_noop; diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c index f2b69e3..714ba4d 100644 --- a/drivers/acpi/pci_link.c +++ b/drivers/acpi/pci_link.c @@ -517,6 +517,42 @@ static int acpi_irq_get_penalty(int irq) return penalty; } +int __init acpi_irq_penalty_init(void) +{ + struct acpi_pci_link *link; + int i; + + /* + * Update penalties to facilitate IRQ balancing. + */ + list_for_each_entry(link, &acpi_link_list, list) { + + /* + * reflect the possible and active irqs in the penalty table -- + * useful for breaking ties. + */ + if (link->irq.possible_count) { + int penalty = + PIRQ_PENALTY_PCI_POSSIBLE / + link->irq.possible_count; + + for (i = 0; i < link->irq.possible_count; i++) { + if (link->irq.possible[i] < ACPI_MAX_ISA_IRQS) + acpi_isa_irq_penalty[link->irq. + possible[i]] += + penalty; + } + + } else if (link->irq.active && + (link->irq.active < ACPI_MAX_ISA_IRQS)) { + acpi_isa_irq_penalty[link->irq.active] += + PIRQ_PENALTY_PCI_POSSIBLE; + } + } + + return 0; +} + static int acpi_irq_balance = -1; /* 0: static, 1: balance */ static int acpi_pci_link_allocate(struct acpi_pci_link *link) diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h index 797ae2e..29c6912 100644 --- a/include/acpi/acpi_drivers.h +++ b/include/acpi/acpi_drivers.h @@ -78,6 +78,7 @@ /* ACPI PCI Interrupt Link (pci_link.c) */ +int acpi_irq_penalty_init(void); int acpi_pci_link_allocate_irq(acpi_handle handle, int index, int *triggering, int *polarity, char **name); int acpi_pci_link_free_irq(acpi_handle handle); -- 1.8.2.1 [-- Attachment #3: 0003-ACPI-PCI-IRQ-separate-ISA-penalty-calculation.patch --] [-- Type: text/plain, Size: 1553 bytes --] >From 81acb01ea4950d5f87c9f1b43f396f798d512b89 Mon Sep 17 00:00:00 2001 From: Sinan Kaya <okaya@codeaurora.org> Date: Fri, 24 Jun 2016 01:31:04 -0400 Subject: [PATCH 3/4] ACPI,PCI,IRQ: separate ISA penalty calculation Since commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements") the penalty values are calculated on the fly rather than boot time. This works fine for PCI interrupts but not so well for the ISA interrupts. Whether an ISA interrupt is in use or not information is not available inside the pci_link.c file. This information gets sent externally via acpi_penalize_isa_irq function. If active is true, then the IRQ is in use by ISA. Otherwise, IRQ is in use by PCI. Since the current code relies on PCI Link object for determination of penalties, we are factoring in the PCI penalty twice after acpi_penalize_isa_irq function is called. This change is limiting the newly added functionality to just PCI interrupts so that old behavior is still maintained. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> --- drivers/acpi/pci_link.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c index 714ba4d..c2f22c9 100644 --- a/drivers/acpi/pci_link.c +++ b/drivers/acpi/pci_link.c @@ -497,7 +497,7 @@ static int acpi_irq_get_penalty(int irq) int penalty = 0; if (irq < ACPI_MAX_ISA_IRQS) - penalty += acpi_isa_irq_penalty[irq]; + return acpi_isa_irq_penalty[irq]; /* * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict -- 1.8.2.1 [-- Attachment #4: 0004-ACPI-PCI-IRQ-correct-operator-precedence.patch --] [-- Type: text/plain, Size: 977 bytes --] >From e45079330af06a0e697ed0c280d8e8c27100b5b7 Mon Sep 17 00:00:00 2001 From: Sinan Kaya <okaya@codeaurora.org> Date: Fri, 24 Jun 2016 01:31:44 -0400 Subject: [PATCH 4/4] ACPI,PCI,IRQ: correct operator precedence The omitted parenthesis prevents the addition operation when acpi_penalize_isa_irq function is called. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> --- drivers/acpi/pci_link.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c index c2f22c9..fcd1267 100644 --- a/drivers/acpi/pci_link.c +++ b/drivers/acpi/pci_link.c @@ -872,7 +872,7 @@ void acpi_penalize_isa_irq(int irq, int active) { if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty))) acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) + - active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING; + (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING); } bool acpi_isa_irq_available(int irq) -- 1.8.2.1 [-- Attachment #5: 0001-ACPI-PCI-IRQ-factor-in-PCI-possible.patch --] [-- Type: text/plain, Size: 1844 bytes --] >From c78fa07940f71dfd907e20304df5c8ce7e36dafa Mon Sep 17 00:00:00 2001 From: Sinan Kaya <okaya@codeaurora.org> Date: Fri, 24 Jun 2016 01:27:54 -0400 Subject: [PATCH 1/4] ACPI,PCI,IRQ: factor in PCI possible The change introduced in commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements") omitted the initially assigned POSSIBLE penalty when the IRQ is active. The original code would assign the POSSIBLE value divided by the number of possible IRQs during initialization. Later, if the IRQ is chosen as the active IRQ or if the IRQ is in use by ISA; additional penalties get added. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> --- drivers/acpi/pci_link.c | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c index 8fc7323..f2b69e3 100644 --- a/drivers/acpi/pci_link.c +++ b/drivers/acpi/pci_link.c @@ -470,6 +470,7 @@ static int acpi_irq_pci_sharing_penalty(int irq) { struct acpi_pci_link *link; int penalty = 0; + int i; list_for_each_entry(link, &acpi_link_list, list) { /* @@ -478,18 +479,14 @@ static int acpi_irq_pci_sharing_penalty(int irq) */ if (link->irq.active && link->irq.active == irq) penalty += PIRQ_PENALTY_PCI_USING; - else { - int i; - - /* - * If a link is inactive, penalize the IRQs it - * might use, but not as severely. - */ - for (i = 0; i < link->irq.possible_count; i++) - if (link->irq.possible[i] == irq) - penalty += PIRQ_PENALTY_PCI_POSSIBLE / - link->irq.possible_count; - } + + /* + * penalize the IRQs PCI might use, but not as severely. + */ + for (i = 0; i < link->irq.possible_count; i++) + if (link->irq.possible[i] == irq) + penalty += PIRQ_PENALTY_PCI_POSSIBLE / + link->irq.possible_count; } return penalty; -- 1.8.2.1 ^ permalink raw reply related [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-24 6:09 ` Sinan Kaya @ 2016-06-25 1:39 ` Wim Osterholt 2016-06-25 8:51 ` okaya 0 siblings, 1 reply; 24+ messages in thread From: Wim Osterholt @ 2016-06-25 1:39 UTC (permalink / raw) To: Sinan Kaya Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner, Alex Williamson, Wim Osterholt On Fri, Jun 24, 2016 at 02:09:15AM -0400, Sinan Kaya wrote: > > Can you give it a try? Whell, I tried to no avail. Wether it is on 4.6 or 4.7, with or without your previous patch, I keep getting rejected hunks. For example, here the line to be deleted is nowhere to be found: > diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c > index 714ba4d..c2f22c9 100644 > --- a/drivers/acpi/pci_link.c > +++ b/drivers/acpi/pci_link.c > @@ -497,7 +497,7 @@ static int acpi_irq_get_penalty(int irq) > int penalty = 0; > > if (irq < ACPI_MAX_ISA_IRQS) > - penalty += acpi_isa_irq_penalty[irq]; > + return acpi_isa_irq_penalty[irq]; > > /* > * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict Regards, Wim. ----- wim@djo.tudelft.nl ----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-25 1:39 ` Wim Osterholt @ 2016-06-25 8:51 ` okaya 2016-06-27 6:27 ` Wim Osterholt 0 siblings, 1 reply; 24+ messages in thread From: okaya @ 2016-06-25 8:51 UTC (permalink / raw) To: wim Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner, Alex Williamson On 2016-06-24 21:39, Wim Osterholt wrote: > On Fri, Jun 24, 2016 at 02:09:15AM -0400, Sinan Kaya wrote: >> >> Can you give it a try? > > Whell, I tried to no avail. > > Wether it is on 4.6 or 4.7, with or without your previous patch, > I keep getting rejected hunks. > For example, here the line to be deleted is nowhere to be found: > >> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c >> index 714ba4d..c2f22c9 100644 >> --- a/drivers/acpi/pci_link.c >> +++ b/drivers/acpi/pci_link.c >> @@ -497,7 +497,7 @@ static int acpi_irq_get_penalty(int irq) >> int penalty = 0; >> >> if (irq < ACPI_MAX_ISA_IRQS) >> - penalty += acpi_isa_irq_penalty[irq]; >> + return acpi_isa_irq_penalty[irq]; >> >> /* >> * Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict > > > Regards, Wim. > > > ----- wim@djo.tudelft.nl ----- Please apply the patches on top of clean 4.7-rc4 tree and apply them in order with git am 0001... git am 0002... ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-25 8:51 ` okaya @ 2016-06-27 6:27 ` Wim Osterholt 2016-06-27 8:22 ` okaya 0 siblings, 1 reply; 24+ messages in thread From: Wim Osterholt @ 2016-06-27 6:27 UTC (permalink / raw) To: okaya Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner, Alex Williamson, Wim Osterholt On Sat, Jun 25, 2016 at 04:51:03AM -0400, okaya@codeaurora.org wrote: > On 2016-06-24 21:39, Wim Osterholt wrote: > > Please apply the patches on top of clean 4.7-rc4 tree and apply them in > order with > > git am 0001... > git am 0002... It doesn't work that way. Beginners problems with git. Tried all kinds of things, including a new git clone to no avail. Took a long time to discover that in the above example these were the names of the 'attachments'. It didn't work. Error 'could not find out the kind of patch' or some such. Took much longer to find out that in that mail and in the saved attachments there were lines beginning with '>From' that were the culprit. Still not found out how to make patch work without errors. Anyway, by doing it with more manual intervention om a stock kernel-4.7-rc4 on my (very slow) Inspiron 4100 it seems to work like before. Hooray. However, an earlier try on my Inspiron 510m did not work. I'll do a clean retry later today, just to make sure. regards, Wim. ----- wim@djo.tudelft.nl ----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-27 6:27 ` Wim Osterholt @ 2016-06-27 8:22 ` okaya 2016-06-27 13:04 ` Wim Osterholt 0 siblings, 1 reply; 24+ messages in thread From: okaya @ 2016-06-27 8:22 UTC (permalink / raw) To: wim Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner, Alex Williamson On 2016-06-27 02:27, Wim Osterholt wrote: > On Sat, Jun 25, 2016 at 04:51:03AM -0400, okaya@codeaurora.org wrote: >> On 2016-06-24 21:39, Wim Osterholt wrote: >> >> Please apply the patches on top of clean 4.7-rc4 tree and apply them >> in >> order with >> >> git am 0001... >> git am 0002... > > It doesn't work that way. > Beginners problems with git. > Tried all kinds of things, including a new git clone to no avail. > Took a long time to discover that in the above example these were the > names > of the 'attachments'. > It didn't work. Error 'could not find out the kind of patch' or some > such. > Took much longer to find out that in that mail and in the saved > attachments > there were lines beginning with '>From' that were the culprit. > > Still not found out how to make patch work without errors. > Anyway, by doing it with more manual intervention om a stock > kernel-4.7-rc4 > on my (very slow) Inspiron 4100 it seems to work like before. Hooray. > However, an earlier try on my Inspiron 510m did not work. > I'll do a clean retry later today, just to make sure. Ok, let me know. I can post a clean patch series. I was trying to get you something to test before posting the official version. > > regards, Wim. > > > ----- wim@djo.tudelft.nl ----- > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-27 8:22 ` okaya @ 2016-06-27 13:04 ` Wim Osterholt 2016-06-27 21:05 ` okaya 0 siblings, 1 reply; 24+ messages in thread From: Wim Osterholt @ 2016-06-27 13:04 UTC (permalink / raw) To: okaya Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner, Alex Williamson, Wim Osterholt On Mon, Jun 27, 2016 at 04:22:18AM -0400, okaya@codeaurora.org wrote: > > However, an earlier try on my Inspiron 510m did not work. > > I'll do a clean retry later today, just to make sure. > > > Ok, let me know. I can post a clean patch series. I was trying to get > you something to test before posting the official version. The 510m just finished compiling and now it works fine too. Thanks. Regards, Wim. ----- wim@djo.tudelft.nl ----- ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-27 13:04 ` Wim Osterholt @ 2016-06-27 21:05 ` okaya 2016-06-29 8:34 ` Sinan Kaya 0 siblings, 1 reply; 24+ messages in thread From: okaya @ 2016-06-27 21:05 UTC (permalink / raw) To: wim Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner, Alex Williamson On 2016-06-27 16:04, Wim Osterholt wrote: > On Mon, Jun 27, 2016 at 04:22:18AM -0400, okaya@codeaurora.org wrote: >> > However, an earlier try on my Inspiron 510m did not work. >> > I'll do a clean retry later today, just to make sure. >> >> >> Ok, let me know. I can post a clean patch series. I was trying to get >> you something to test before posting the official version. > > The 510m just finished compiling and now it works fine too. > Thanks. > Nice, I will post the official version and let you know. > > > Regards, Wim. > > > ----- wim@djo.tudelft.nl ----- > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-27 21:05 ` okaya @ 2016-06-29 8:34 ` Sinan Kaya 2016-06-30 2:30 ` Wim Osterholt 0 siblings, 1 reply; 24+ messages in thread From: Sinan Kaya @ 2016-06-29 8:34 UTC (permalink / raw) To: wim Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner, Alex Williamson On 6/27/2016 5:05 PM, okaya@codeaurora.org wrote: > On 2016-06-27 16:04, Wim Osterholt wrote: >> On Mon, Jun 27, 2016 at 04:22:18AM -0400, okaya@codeaurora.org wrote: >>> > However, an earlier try on my Inspiron 510m did not work. >>> > I'll do a clean retry later today, just to make sure. >>> >>> >>> Ok, let me know. I can post a clean patch series. I was trying to get >>> you something to test before posting the official version. >> >> The 510m just finished compiling and now it works fine too. >> Thanks. >> > > Nice, I will post the official version and let you know. > I posted this [PATCH V2 0/4] ACPI,PCI,IRQ: correct ISA penalty calculation Can you test this and give me a tested-by? Alex, If you could also review this, it would be great. Sinan >> >> >> Regards, Wim. >> >> >> ----- wim@djo.tudelft.nl ----- >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-pci" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-29 8:34 ` Sinan Kaya @ 2016-06-30 2:30 ` Wim Osterholt 2016-06-30 9:43 ` okaya 0 siblings, 1 reply; 24+ messages in thread From: Wim Osterholt @ 2016-06-30 2:30 UTC (permalink / raw) To: Sinan Kaya Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner, Alex Williamson, Wim Osterholt On Wed, Jun 29, 2016 at 04:34:14AM -0400, Sinan Kaya wrote: > > > > I posted this [PATCH V2 0/4] ACPI,PCI,IRQ: correct ISA penalty calculation > > Can you test this and give me a tested-by? Kernel-4.7-rc5 plus this patch works like a charm on my Inspiron 4100. Dmesg output is quite similar to the one from kernel-4.6 . Tested-by: Wim Osterholt. <wim@djo.tudelft.nl> ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: kernel-4.7 bug in Intel sound and/or ACPI 2016-06-30 2:30 ` Wim Osterholt @ 2016-06-30 9:43 ` okaya 0 siblings, 0 replies; 24+ messages in thread From: okaya @ 2016-06-30 9:43 UTC (permalink / raw) To: wim Cc: Bjorn Helgaas, Rafael J. Wysocki, linux-kernel, linux-acpi, perex, linux-pci, Takashi Iwai, linux-pci-owner, Alex Williamson On 2016-06-30 05:30, Wim Osterholt wrote: > On Wed, Jun 29, 2016 at 04:34:14AM -0400, Sinan Kaya wrote: >> > >> >> I posted this [PATCH V2 0/4] ACPI,PCI,IRQ: correct ISA penalty >> calculation >> >> Can you test this and give me a tested-by? > > > Kernel-4.7-rc5 plus this patch works like a charm on my Inspiron 4100. > Dmesg output is quite similar to the one from kernel-4.6 . > > Tested-by: Wim Osterholt. <wim@djo.tudelft.nl> > Thank you. > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2016-06-30 9:43 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-06-20 0:35 kernel-4.7 bug in Intel sound and/or ACPI Wim Osterholt 2016-06-20 1:02 ` Rafael J. Wysocki 2016-06-20 21:25 ` Bjorn Helgaas 2016-06-20 22:25 ` Sinan Kaya 2016-06-21 12:47 ` Wim Osterholt 2016-06-21 13:40 ` Sinan Kaya 2016-06-21 22:13 ` Wim Osterholt 2016-06-23 3:54 ` okaya 2016-06-23 14:12 ` Wim Osterholt 2016-06-23 14:55 ` Sinan Kaya 2016-06-23 15:45 ` Sinan Kaya 2016-06-23 16:21 ` Bjorn Helgaas 2016-06-23 17:05 ` Alex Williamson 2016-06-23 23:25 ` Wim Osterholt 2016-06-24 6:09 ` Sinan Kaya 2016-06-25 1:39 ` Wim Osterholt 2016-06-25 8:51 ` okaya 2016-06-27 6:27 ` Wim Osterholt 2016-06-27 8:22 ` okaya 2016-06-27 13:04 ` Wim Osterholt 2016-06-27 21:05 ` okaya 2016-06-29 8:34 ` Sinan Kaya 2016-06-30 2:30 ` Wim Osterholt 2016-06-30 9:43 ` okaya
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.