Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1426083 > unrolled thread

kernel-4.7 bug in Intel sound and/or ACPI

Back to article view | Back to linux.kernel

Contents

  kernel-4.7 bug in Intel sound and/or ACPI Wim Osterholt <wim@djo.tudelft.nl> - 2016-06-20 02:40 +0200
    Re: kernel-4.7 bug in Intel sound and/or ACPI "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-06-20 03:00 +0200
      Re: kernel-4.7 bug in Intel sound and/or ACPI Bjorn Helgaas <helgaas@kernel.org> - 2016-06-20 23:30 +0200
        Re: kernel-4.7 bug in Intel sound and/or ACPI Sinan Kaya <okaya@codeaurora.org> - 2016-06-21 00:30 +0200
          Re: kernel-4.7 bug in Intel sound and/or ACPI Wim Osterholt <wim@djo.tudelft.nl> - 2016-06-21 14:50 +0200
            Re: kernel-4.7 bug in Intel sound and/or ACPI Sinan Kaya <okaya@codeaurora.org> - 2016-06-21 15:50 +0200
              Re: kernel-4.7 bug in Intel sound and/or ACPI Wim Osterholt <wim@djo.tudelft.nl> - 2016-06-22 00:30 +0200
                Re: kernel-4.7 bug in Intel sound and/or ACPI okaya@codeaurora.org - 2016-06-23 06:00 +0200
                  Re: kernel-4.7 bug in Intel sound and/or ACPI Wim Osterholt <wim@djo.tudelft.nl> - 2016-06-23 16:20 +0200
                    Re: kernel-4.7 bug in Intel sound and/or ACPI Sinan Kaya <okaya@codeaurora.org> - 2016-06-23 17:00 +0200
                      Re: kernel-4.7 bug in Intel sound and/or ACPI Sinan Kaya <okaya@codeaurora.org> - 2016-06-23 17:50 +0200
                        Re: kernel-4.7 bug in Intel sound and/or ACPI Bjorn Helgaas <helgaas@kernel.org> - 2016-06-23 18:30 +0200
                          Re: kernel-4.7 bug in Intel sound and/or ACPI Alex Williamson <alex.williamson@redhat.com> - 2016-06-23 19:10 +0200
                        Re: kernel-4.7 bug in Intel sound and/or ACPI Wim Osterholt <wim@djo.tudelft.nl> - 2016-06-24 01:30 +0200
                          Re: kernel-4.7 bug in Intel sound and/or ACPI Sinan Kaya <okaya@codeaurora.org> - 2016-06-24 08:10 +0200
                            Re: kernel-4.7 bug in Intel sound and/or ACPI Wim Osterholt <wim@djo.tudelft.nl> - 2016-06-25 03:40 +0200
                              Re: kernel-4.7 bug in Intel sound and/or ACPI okaya@codeaurora.org - 2016-06-25 11:00 +0200
                                Re: kernel-4.7 bug in Intel sound and/or ACPI Wim Osterholt <wim@djo.tudelft.nl> - 2016-06-27 08:30 +0200
                                  Re: kernel-4.7 bug in Intel sound and/or ACPI okaya@codeaurora.org - 2016-06-27 10:30 +0200
                                    Re: kernel-4.7 bug in Intel sound and/or ACPI Wim Osterholt <wim@djo.tudelft.nl> - 2016-06-27 15:10 +0200
                                      Re: kernel-4.7 bug in Intel sound and/or ACPI okaya@codeaurora.org - 2016-06-27 23:10 +0200
                                        Re: kernel-4.7 bug in Intel sound and/or ACPI Sinan Kaya <okaya@codeaurora.org> - 2016-06-29 10:40 +0200
                                          Re: kernel-4.7 bug in Intel sound and/or ACPI Wim Osterholt <wim@djo.tudelft.nl> - 2016-06-30 04:40 +0200
                                            Re: kernel-4.7 bug in Intel sound and/or ACPI okaya@codeaurora.org - 2016-06-30 11:50 +0200

Page 1 of 2  [1] 2  Next page →

#1426083 — kernel-4.7 bug in Intel sound and/or ACPI

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

[toc] | [next] | [standalone]

#1426094

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

[toc] | [prev] | [next] | [standalone]

#1427069

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

[toc] | [prev] | [next] | [standalone]

#1427098

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

[toc] | [prev] | [next] | [standalone]

#1427713

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

[toc] | [prev] | [next] | [standalone]

#1427772

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

[toc] | [prev] | [next] | [standalone]

#1428235

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

[toc] | [prev] | [next] | [standalone]

#1429428

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

[toc] | [prev] | [next] | [standalone]

#1429883

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

[toc] | [prev] | [next] | [standalone]

#1429913

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

[toc] | [prev] | [next] | [standalone]

#1429938

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1429963

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

[toc] | [prev] | [next] | [standalone]

#1429994

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

[toc] | [prev] | [next] | [standalone]

#1430241

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

[toc] | [prev] | [next] | [standalone]

#1430380

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#1431043

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

[toc] | [prev] | [next] | [standalone]

#1431101

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

[toc] | [prev] | [next] | [standalone]

#1431744

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

[toc] | [prev] | [next] | [standalone]

#1431810

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

[toc] | [prev] | [next] | [standalone]

#1432031

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web