All of lore.kernel.org
 help / color / mirror / Atom feed
* 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	[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	[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.