kernel-4.7 bug in Intel sound and/or ACPI

kernel-4.7 bug in Intel sound and/or ACPI

[Wim Osterholt]

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 -----

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Rafael J. Wysocki]

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 -----

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Bjorn Helgaas]

[+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

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Sinan Kaya]

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

Re: kernel-4.7 bug in Intel sound and/or ACPI

[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 -----

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Sinan Kaya]

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

Re: kernel-4.7 bug in Intel sound and/or ACPI

[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 -----

Re: kernel-4.7 bug in Intel sound and/or ACPI

[okaya]

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

Re: kernel-4.7 bug in Intel sound and/or ACPI

[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 -----

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Sinan Kaya]

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

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Sinan Kaya]

[-- 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]);
 	}
 }
 

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Bjorn Helgaas]

[+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]);
>  	}
>  }
>  

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Alex Williamson]

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]);
> >  	}
> >  }
> >    
> 

Re: kernel-4.7 bug in Intel sound and/or ACPI

[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 -----

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Sinan Kaya]

[-- 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

Re: kernel-4.7 bug in Intel sound and/or ACPI

[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 -----

Re: kernel-4.7 bug in Intel sound and/or ACPI

[okaya]

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...

Re: kernel-4.7 bug in Intel sound and/or ACPI

[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 -----

Re: kernel-4.7 bug in Intel sound and/or ACPI

[okaya]

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

Re: kernel-4.7 bug in Intel sound and/or ACPI

[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 -----

Re: kernel-4.7 bug in Intel sound and/or ACPI

[okaya]

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

Re: kernel-4.7 bug in Intel sound and/or ACPI

[Sinan Kaya]

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

Re: kernel-4.7 bug in Intel sound and/or ACPI

[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>

Re: kernel-4.7 bug in Intel sound and/or ACPI

[okaya]

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