diff mbox

x86/ACPI: Fix regression caused by 16ee7b3dcc56

Message ID 1428417244-32416-1-git-send-email-jiang.liu@linux.intel.com (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Jiang Liu April 7, 2015, 2:34 p.m. UTC
Hi Jim,
	Could you please help to test this patch against v4.0-rc6?
Thanks!
Gerry

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 arch/x86/kernel/acpi/boot.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Comments

Jim April 7, 2015, 4:49 p.m. UTC | #1
On 04/07/2015 04:34 PM, Jiang Liu wrote:
> Hi Jim,
> 	Could you please help to test this patch against v4.0-rc6?
> Thanks!
> Gerry
> 
> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> ---
>  arch/x86/kernel/acpi/boot.c |   10 +++++++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 803b684676ff..f7f1fe7cd1b0 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -403,10 +403,14 @@ static int mp_config_acpi_gsi(struct device *dev, u32 gsi, int trigger,
>  static int mp_register_gsi(struct device *dev, u32 gsi, int trigger,
>  			   int polarity)
>  {
> -	int irq, node;
> +	int i, irq, node;
>  
> -	if (acpi_irq_model != ACPI_IRQ_MODEL_IOAPIC)
> -		return gsi;
> +	if (acpi_irq_model != ACPI_IRQ_MODEL_IOAPIC) {
> +		for (i = 0; i < nr_legacy_irqs(); i++)
> +			if (isa_irq_to_gsi[i] == gsi)
> +				return i;
> +		return -1;
> +	}
>  
>  	trigger = trigger == ACPI_EDGE_SENSITIVE ? 0 : 1;
>  	polarity = polarity == ACPI_ACTIVE_HIGH ? 0 : 1;
> 

Jiang,

It definitely seems to be an improvement, using Virtualbox guest with
your patch applied acpi-events work for all combinations (smp/nosmp
with/without I/O APIC assigned to the guest).

However, on the Dell laptop it still doesn't work.  To be sure I built a
3.16 kernel on this laptop and acpi_event power-button lid close/open
are working just fine.

Attached config + dmesg + cat /proc/interrupt for the working 3.16 case
and still not working 4.0-rc6+patch case.

Thanks,
Jim
Jiang Liu April 8, 2015, 5:26 a.m. UTC | #2
On 2015/4/8 0:49, Jim Bos wrote:
> On 04/07/2015 04:34 PM, Jiang Liu wrote:
>> Hi Jim,
>> 	Could you please help to test this patch against v4.0-rc6?
>> Thanks!
>> Gerry
>>
>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>> ---
>>  arch/x86/kernel/acpi/boot.c |   10 +++++++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
>> index 803b684676ff..f7f1fe7cd1b0 100644
>> --- a/arch/x86/kernel/acpi/boot.c
>> +++ b/arch/x86/kernel/acpi/boot.c
>> @@ -403,10 +403,14 @@ static int mp_config_acpi_gsi(struct device *dev, u32 gsi, int trigger,
>>  static int mp_register_gsi(struct device *dev, u32 gsi, int trigger,
>>  			   int polarity)
>>  {
>> -	int irq, node;
>> +	int i, irq, node;
>>  
>> -	if (acpi_irq_model != ACPI_IRQ_MODEL_IOAPIC)
>> -		return gsi;
>> +	if (acpi_irq_model != ACPI_IRQ_MODEL_IOAPIC) {
>> +		for (i = 0; i < nr_legacy_irqs(); i++)
>> +			if (isa_irq_to_gsi[i] == gsi)
>> +				return i;
>> +		return -1;
>> +	}
>>  
>>  	trigger = trigger == ACPI_EDGE_SENSITIVE ? 0 : 1;
>>  	polarity = polarity == ACPI_ACTIVE_HIGH ? 0 : 1;
>>
> 
> Jiang,
> 
> It definitely seems to be an improvement, using Virtualbox guest with
> your patch applied acpi-events work for all combinations (smp/nosmp
> with/without I/O APIC assigned to the guest).
> 
> However, on the Dell laptop it still doesn't work.  To be sure I built a
> 3.16 kernel on this laptop and acpi_event power-button lid close/open
> are working just fine.
> 
> Attached config + dmesg + cat /proc/interrupt for the working 3.16 case
> and still not working 4.0-rc6+patch case.
Hi Jim,
	According to the attached files, you are building a UP kernel
with IOAPIC enabled. This configuration works well on my HP laptop.
And according to file IRQs from 4.0-rc6, it shows:
 9:          1    XT-PIC  acpi
That means kernel has received one ACPI SCI interrupt, but no
following-on ACPI SCI interrupts, I can't figure out the root cause yet.

So could you please help to dump ACPI tables from your dell laptop by
using acpidump utility?
Thanks!
Gerry

> 
> Thanks,
> Jim
> 
> 
> 
> 
> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jim April 8, 2015, 3:51 p.m. UTC | #3
On 04/08/2015 07:26 AM, Jiang Liu wrote:
> On 2015/4/8 0:49, Jim Bos wrote:
>> On 04/07/2015 04:34 PM, Jiang Liu wrote:
>>> Hi Jim,
>>> 	Could you please help to test this patch against v4.0-rc6?
>>> Thanks!
>>> Gerry
>>>
>>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>>> ---
>>>  arch/x86/kernel/acpi/boot.c |   10 +++++++---
>>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
>>> index 803b684676ff..f7f1fe7cd1b0 100644
>>> --- a/arch/x86/kernel/acpi/boot.c
>>> +++ b/arch/x86/kernel/acpi/boot.c
>>> @@ -403,10 +403,14 @@ static int mp_config_acpi_gsi(struct device *dev, u32 gsi, int trigger,
>>>  static int mp_register_gsi(struct device *dev, u32 gsi, int trigger,
>>>  			   int polarity)
>>>  {
>>> -	int irq, node;
>>> +	int i, irq, node;
>>>  
>>> -	if (acpi_irq_model != ACPI_IRQ_MODEL_IOAPIC)
>>> -		return gsi;
>>> +	if (acpi_irq_model != ACPI_IRQ_MODEL_IOAPIC) {
>>> +		for (i = 0; i < nr_legacy_irqs(); i++)
>>> +			if (isa_irq_to_gsi[i] == gsi)
>>> +				return i;
>>> +		return -1;
>>> +	}
>>>  
>>>  	trigger = trigger == ACPI_EDGE_SENSITIVE ? 0 : 1;
>>>  	polarity = polarity == ACPI_ACTIVE_HIGH ? 0 : 1;
>>>
>>
>> Jiang,
>>
>> It definitely seems to be an improvement, using Virtualbox guest with
>> your patch applied acpi-events work for all combinations (smp/nosmp
>> with/without I/O APIC assigned to the guest).
>>
>> However, on the Dell laptop it still doesn't work.  To be sure I built a
>> 3.16 kernel on this laptop and acpi_event power-button lid close/open
>> are working just fine.
>>
>> Attached config + dmesg + cat /proc/interrupt for the working 3.16 case
>> and still not working 4.0-rc6+patch case.
> Hi Jim,
> 	According to the attached files, you are building a UP kernel
> with IOAPIC enabled. This configuration works well on my HP laptop.
> And according to file IRQs from 4.0-rc6, it shows:
>  9:          1    XT-PIC  acpi
> That means kernel has received one ACPI SCI interrupt, but no
> following-on ACPI SCI interrupts, I can't figure out the root cause yet.
> 
> So could you please help to dump ACPI tables from your dell laptop by
> using acpidump utility?
> Thanks!
> Gerry
> 
>>
>> Thanks,
>> Jim
>>

Gerry,

Attached acpidump (binary files and regular dump).
I just tested 4.0-rc6+your_patch on another single core system, AMD
geode board, and that works fine now!
So indeed it seems there is something special about the dell laptop as
that's the only system, I've available here, which still has an issue.
Jiang Liu April 9, 2015, 10:15 a.m. UTC | #4
On 2015/4/8 23:51, Jim Bos wrote:
> On 04/08/2015 07:26 AM, Jiang Liu wrote:
>> On 2015/4/8 0:49, Jim Bos wrote:
>>> On 04/07/2015 04:34 PM, Jiang Liu wrote:
>>>> Hi Jim,
>>>> 	Could you please help to test this patch against v4.0-rc6?
>>>> Thanks!
>>>> Gerry
>>>>
>>>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>>>> ---
>>>>  arch/x86/kernel/acpi/boot.c |   10 +++++++---
>>>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
>>>> index 803b684676ff..f7f1fe7cd1b0 100644
>>>> --- a/arch/x86/kernel/acpi/boot.c
>>>> +++ b/arch/x86/kernel/acpi/boot.c
>>>> @@ -403,10 +403,14 @@ static int mp_config_acpi_gsi(struct device *dev, u32 gsi, int trigger,
>>>>  static int mp_register_gsi(struct device *dev, u32 gsi, int trigger,
>>>>  			   int polarity)
>>>>  {
>>>> -	int irq, node;
>>>> +	int i, irq, node;
>>>>  
>>>> -	if (acpi_irq_model != ACPI_IRQ_MODEL_IOAPIC)
>>>> -		return gsi;
>>>> +	if (acpi_irq_model != ACPI_IRQ_MODEL_IOAPIC) {
>>>> +		for (i = 0; i < nr_legacy_irqs(); i++)
>>>> +			if (isa_irq_to_gsi[i] == gsi)
>>>> +				return i;
>>>> +		return -1;
>>>> +	}
>>>>  
>>>>  	trigger = trigger == ACPI_EDGE_SENSITIVE ? 0 : 1;
>>>>  	polarity = polarity == ACPI_ACTIVE_HIGH ? 0 : 1;
>>>>
>>>
>>> Jiang,
>>>
>>> It definitely seems to be an improvement, using Virtualbox guest with
>>> your patch applied acpi-events work for all combinations (smp/nosmp
>>> with/without I/O APIC assigned to the guest).
>>>
>>> However, on the Dell laptop it still doesn't work.  To be sure I built a
>>> 3.16 kernel on this laptop and acpi_event power-button lid close/open
>>> are working just fine.
>>>
>>> Attached config + dmesg + cat /proc/interrupt for the working 3.16 case
>>> and still not working 4.0-rc6+patch case.
>> Hi Jim,
>> 	According to the attached files, you are building a UP kernel
>> with IOAPIC enabled. This configuration works well on my HP laptop.
>> And according to file IRQs from 4.0-rc6, it shows:
>>  9:          1    XT-PIC  acpi
>> That means kernel has received one ACPI SCI interrupt, but no
>> following-on ACPI SCI interrupts, I can't figure out the root cause yet.
>>
>> So could you please help to dump ACPI tables from your dell laptop by
>> using acpidump utility?
>> Thanks!
>> Gerry
>>
>>>
>>> Thanks,
>>> Jim
>>>
> 
> Gerry,
> 
> Attached acpidump (binary files and regular dump).
> I just tested 4.0-rc6+your_patch on another single core system, AMD
> geode board, and that works fine now!
> So indeed it seems there is something special about the dell laptop as
> that's the only system, I've available here, which still has an issue.
Hi Jim,
	I'm really confused. I can't even explain why my previous
patch fixes the issue on AMD geode board now:(

For the Dell laptop, seems you have:
1) build a kernel with Local APIC and IOAPIC enabled
2) lapic is disabled by BIOS, so there's no ACPI MADT(APIC)
table at all.
That means the laptop is working with 8259 PICs only.
There's little change between 3.16 and 4.0 related to 8259.

For the AMD geode board, I still think original code is right.
I can't explain why the patch fix the issue.

So could you please help to:
1) Try to enable lapic on Dell laptop in BIOS
2) Dump acpi tables and dmesg on AMD board

If that still doesn't help, I will try to send you some
debug patches to gather more info.
Thanks!
Gerry
> _
> Jim
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jim April 9, 2015, 4:41 p.m. UTC | #5
On 04/09/2015 12:15 PM, Jiang Liu wrote:
> On 2015/4/8 23:51, Jim Bos wrote:
>> On 04/08/2015 07:26 AM, Jiang Liu wrote:
>>> On 2015/4/8 0:49, Jim Bos wrote:
>>>> On 04/07/2015 04:34 PM, Jiang Liu wrote:
>>>>> Hi Jim,
>>>>> 	Could you please help to test this patch against v4.0-rc6?
>>>>> Thanks!
>>>>> Gerry
>>>>>
>>>>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>>>>> ---
>>>>>  arch/x86/kernel/acpi/boot.c |   10 +++++++---
>>>>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
>>>>> index 803b684676ff..f7f1fe7cd1b0 100644
>>>>> --- a/arch/x86/kernel/acpi/boot.c
>>>>> +++ b/arch/x86/kernel/acpi/boot.c
>>>>> @@ -403,10 +403,14 @@ static int mp_config_acpi_gsi(struct device *dev, u32 gsi, int trigger,
>>>>>  static int mp_register_gsi(struct device *dev, u32 gsi, int trigger,
>>>>>  			   int polarity)
>>>>>  {
>>>>> -	int irq, node;
>>>>> +	int i, irq, node;
>>>>>  
>>>>> -	if (acpi_irq_model != ACPI_IRQ_MODEL_IOAPIC)
>>>>> -		return gsi;
>>>>> +	if (acpi_irq_model != ACPI_IRQ_MODEL_IOAPIC) {
>>>>> +		for (i = 0; i < nr_legacy_irqs(); i++)
>>>>> +			if (isa_irq_to_gsi[i] == gsi)
>>>>> +				return i;
>>>>> +		return -1;
>>>>> +	}
>>>>>  
>>>>>  	trigger = trigger == ACPI_EDGE_SENSITIVE ? 0 : 1;
>>>>>  	polarity = polarity == ACPI_ACTIVE_HIGH ? 0 : 1;
>>>>>
>>>>
>>>> Jiang,
>>>>
>>>> It definitely seems to be an improvement, using Virtualbox guest with
>>>> your patch applied acpi-events work for all combinations (smp/nosmp
>>>> with/without I/O APIC assigned to the guest).
>>>>
>>>> However, on the Dell laptop it still doesn't work.  To be sure I built a
>>>> 3.16 kernel on this laptop and acpi_event power-button lid close/open
>>>> are working just fine.
>>>>
>>>> Attached config + dmesg + cat /proc/interrupt for the working 3.16 case
>>>> and still not working 4.0-rc6+patch case.
>>> Hi Jim,
>>> 	According to the attached files, you are building a UP kernel
>>> with IOAPIC enabled. This configuration works well on my HP laptop.
>>> And according to file IRQs from 4.0-rc6, it shows:
>>>  9:          1    XT-PIC  acpi
>>> That means kernel has received one ACPI SCI interrupt, but no
>>> following-on ACPI SCI interrupts, I can't figure out the root cause yet.
>>>
>>> So could you please help to dump ACPI tables from your dell laptop by
>>> using acpidump utility?
>>> Thanks!
>>> Gerry
>>>
>>>>
>>>> Thanks,
>>>> Jim
>>>>
>>
>> Gerry,
>>
>> Attached acpidump (binary files and regular dump).
>> I just tested 4.0-rc6+your_patch on another single core system, AMD
>> geode board, and that works fine now!
>> So indeed it seems there is something special about the dell laptop as
>> that's the only system, I've available here, which still has an issue.
> Hi Jim,
> 	I'm really confused. I can't even explain why my previous
> patch fixes the issue on AMD geode board now:(
> 
> For the Dell laptop, seems you have:
> 1) build a kernel with Local APIC and IOAPIC enabled
> 2) lapic is disabled by BIOS, so there's no ACPI MADT(APIC)
> table at all.
> That means the laptop is working with 8259 PICs only.
> There's little change between 3.16 and 4.0 related to 8259.
> 
> For the AMD geode board, I still think original code is right.
> I can't explain why the patch fix the issue.
> 
> So could you please help to:
> 1) Try to enable lapic on Dell laptop in BIOS
> 2) Dump acpi tables and dmesg on AMD board
> 
> If that still doesn't help, I will try to send you some
> debug patches to gather more info.
> Thanks!
> Gerry
>> _
>> Jim
>>
> 

Gerry,

As you mentioned your patch shouldn't make a difference, run some more
tests, as it turns out:
- geode system  broken on 3.16+ up to and including 3.19, however, on
plain 4.0-rc6 it works!  Root cause appears to be there isn't an ACPI
interrupt assigned in non-working kernels.
- other system I got my hands on: Pentium(R) CPU G3220, broken on 3.19.0
when boot parameter 'nosmp' is specified, again no acpi entry in
/proc/interrupts,  working fine on 4.0-rc6

So obviously between 3.19 and 4.0-rc6 something got fixed here!

The Dell laptop remains the only problem then on 4.0-rc6, there IS an
acpi interrupt  (but firing once apparently).
There isn't an option in BIOS to enable LAPIC, however, when specifying
'lapic' as boot parameter I got interesting result, still not working
and /proc/interrups still shows XT-PIC.  Doing a diff between dmesg on
3.19 and 4.0-rc6 this pops out:

-Local APIC disabled by BIOS -- you can enable it with "lapic"
-APIC: disable apic facility
-APIC: switched to apic NOOP
+Local APIC disabled by BIOS -- reenabling.
+Found and enabled local APIC!

+Enabling APIC mode:  Flat.  Using 0 I/O APICs

Jim

--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jiang Liu April 10, 2015, 1:56 a.m. UTC | #6
On 2015/4/10 0:41, Jim Bos wrote:
> On 04/09/2015 12:15 PM, Jiang Liu wrote:
>> On 2015/4/8 23:51, Jim Bos wrote:
>>> On 04/08/2015 07:26 AM, Jiang Liu wrote:
>>>> On 2015/4/8 0:49, Jim Bos wrote:
>>>>> On 04/07/2015 04:34 PM, Jiang Liu wrote:
<snip>
>> Hi Jim,
>> 	I'm really confused. I can't even explain why my previous
>> patch fixes the issue on AMD geode board now:(
>>
>> For the Dell laptop, seems you have:
>> 1) build a kernel with Local APIC and IOAPIC enabled
>> 2) lapic is disabled by BIOS, so there's no ACPI MADT(APIC)
>> table at all.
>> That means the laptop is working with 8259 PICs only.
>> There's little change between 3.16 and 4.0 related to 8259.
>>
>> For the AMD geode board, I still think original code is right.
>> I can't explain why the patch fix the issue.
>>
>> So could you please help to:
>> 1) Try to enable lapic on Dell laptop in BIOS
>> 2) Dump acpi tables and dmesg on AMD board
>>
>> If that still doesn't help, I will try to send you some
>> debug patches to gather more info.
>> Thanks!
>> Gerry
>>> _
>>> Jim
>>>
>>
> 
> Gerry,
> 
> As you mentioned your patch shouldn't make a difference, run some more
> tests, as it turns out:
> - geode system  broken on 3.16+ up to and including 3.19, however, on
> plain 4.0-rc6 it works!  Root cause appears to be there isn't an ACPI
> interrupt assigned in non-working kernels.
> - other system I got my hands on: Pentium(R) CPU G3220, broken on 3.19.0
> when boot parameter 'nosmp' is specified, again no acpi entry in
> /proc/interrupts,  working fine on 4.0-rc6
> 
> So obviously between 3.19 and 4.0-rc6 something got fixed here!
Hi Jim,
Yes, the bugfix patch should be:
commit 1ea76fbadd66("x86/irq: Fix regression caused by commit b568b8601f05")

> The Dell laptop remains the only problem then on 4.0-rc6, there IS an
> acpi interrupt  (but firing once apparently).
> There isn't an option in BIOS to enable LAPIC, however, when specifying
> 'lapic' as boot parameter I got interesting result, still not working
> and /proc/interrups still shows XT-PIC.  Doing a diff between dmesg on
> 3.19 and 4.0-rc6 this pops out:
> 
> -Local APIC disabled by BIOS -- you can enable it with "lapic"
> -APIC: disable apic facility
> -APIC: switched to apic NOOP
> +Local APIC disabled by BIOS -- reenabling.
> +Found and enabled local APIC!
> 
> +Enabling APIC mode:  Flat.  Using 0 I/O APICs
What's the last know working kernel for Dell laptop?
Does it work as expected with v3.19 kernel?
Do you means this message is from plain v4.0-rc6 kernel?
Thanks!
Gerry

> 
> Jim
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jim April 10, 2015, 6:19 a.m. UTC | #7
On 04/10/2015 03:56 AM, Jiang Liu wrote:
> On 2015/4/10 0:41, Jim Bos wrote:
>> On 04/09/2015 12:15 PM, Jiang Liu wrote:
>>> On 2015/4/8 23:51, Jim Bos wrote:
>>>> On 04/08/2015 07:26 AM, Jiang Liu wrote:
>>>>> On 2015/4/8 0:49, Jim Bos wrote:
>>>>>> On 04/07/2015 04:34 PM, Jiang Liu wrote:
> <snip>
>>> Hi Jim,
>>> 	I'm really confused. I can't even explain why my previous
>>> patch fixes the issue on AMD geode board now:(
>>>
>>> For the Dell laptop, seems you have:
>>> 1) build a kernel with Local APIC and IOAPIC enabled
>>> 2) lapic is disabled by BIOS, so there's no ACPI MADT(APIC)
>>> table at all.
>>> That means the laptop is working with 8259 PICs only.
>>> There's little change between 3.16 and 4.0 related to 8259.
>>>
>>> For the AMD geode board, I still think original code is right.
>>> I can't explain why the patch fix the issue.
>>>
>>> So could you please help to:
>>> 1) Try to enable lapic on Dell laptop in BIOS
>>> 2) Dump acpi tables and dmesg on AMD board
>>>
>>> If that still doesn't help, I will try to send you some
>>> debug patches to gather more info.
>>> Thanks!
>>> Gerry
>>>> _
>>>> Jim
>>>>
>>>
>>
>> Gerry,
>>
>> As you mentioned your patch shouldn't make a difference, run some more
>> tests, as it turns out:
>> - geode system  broken on 3.16+ up to and including 3.19, however, on
>> plain 4.0-rc6 it works!  Root cause appears to be there isn't an ACPI
>> interrupt assigned in non-working kernels.
>> - other system I got my hands on: Pentium(R) CPU G3220, broken on 3.19.0
>> when boot parameter 'nosmp' is specified, again no acpi entry in
>> /proc/interrupts,  working fine on 4.0-rc6
>>
>> So obviously between 3.19 and 4.0-rc6 something got fixed here!
> Hi Jim,
> Yes, the bugfix patch should be:
> commit 1ea76fbadd66("x86/irq: Fix regression caused by commit b568b8601f05")
> 
>> The Dell laptop remains the only problem then on 4.0-rc6, there IS an
>> acpi interrupt  (but firing once apparently).
>> There isn't an option in BIOS to enable LAPIC, however, when specifying
>> 'lapic' as boot parameter I got interesting result, still not working
>> and /proc/interrups still shows XT-PIC.  Doing a diff between dmesg on
>> 3.19 and 4.0-rc6 this pops out:
>>
>> -Local APIC disabled by BIOS -- you can enable it with "lapic"
>> -APIC: disable apic facility
>> -APIC: switched to apic NOOP
>> +Local APIC disabled by BIOS -- reenabling.
>> +Found and enabled local APIC!
>>
>> +Enabling APIC mode:  Flat.  Using 0 I/O APICs
> What's the last know working kernel for Dell laptop?
> Does it work as expected with v3.19 kernel?
> Do you means this message is from plain v4.0-rc6 kernel?
> Thanks!
> Gerry
> 
>>
>> Jim
>>
> 
Last know working version on the Dell laptop is 3.16 and yes this message"

>> -Local APIC disabled by BIOS -- you can enable it with "lapic"
>> -APIC: disable apic facility
>> -APIC: switched to apic NOOP
>> +Local APIC disabled by BIOS -- reenabling.
>> +Found and enabled local APIC!

is from the v4.0-rc6 message. Full dmesg attached.

Jim.
Jim April 11, 2015, 3:08 p.m. UTC | #8
On 04/10/2015 03:56 AM, Jiang Liu wrote:
> On 2015/4/10 0:41, Jim Bos wrote:
>> On 04/09/2015 12:15 PM, Jiang Liu wrote:
>>> On 2015/4/8 23:51, Jim Bos wrote:
>>>> On 04/08/2015 07:26 AM, Jiang Liu wrote:
>>>>> On 2015/4/8 0:49, Jim Bos wrote:
>>>>>> On 04/07/2015 04:34 PM, Jiang Liu wrote:
> <snip>
>>> Hi Jim,
>>> 	I'm really confused. I can't even explain why my previous
>>> patch fixes the issue on AMD geode board now:(
>>>
>>> For the Dell laptop, seems you have:
>>> 1) build a kernel with Local APIC and IOAPIC enabled
>>> 2) lapic is disabled by BIOS, so there's no ACPI MADT(APIC)
>>> table at all.
>>> That means the laptop is working with 8259 PICs only.
>>> There's little change between 3.16 and 4.0 related to 8259.
>>>
>>> For the AMD geode board, I still think original code is right.
>>> I can't explain why the patch fix the issue.
>>>
>>> So could you please help to:
>>> 1) Try to enable lapic on Dell laptop in BIOS
>>> 2) Dump acpi tables and dmesg on AMD board
>>>
>>> If that still doesn't help, I will try to send you some
>>> debug patches to gather more info.
>>> Thanks!
>>> Gerry
>>>> _
>>>> Jim
>>>>
>>>
>>
>> Gerry,
>>
>> As you mentioned your patch shouldn't make a difference, run some more
>> tests, as it turns out:
>> - geode system  broken on 3.16+ up to and including 3.19, however, on
>> plain 4.0-rc6 it works!  Root cause appears to be there isn't an ACPI
>> interrupt assigned in non-working kernels.
>> - other system I got my hands on: Pentium(R) CPU G3220, broken on 3.19.0
>> when boot parameter 'nosmp' is specified, again no acpi entry in
>> /proc/interrupts,  working fine on 4.0-rc6
>>
>> So obviously between 3.19 and 4.0-rc6 something got fixed here!
> Hi Jim,
> Yes, the bugfix patch should be:
> commit 1ea76fbadd66("x86/irq: Fix regression caused by commit b568b8601f05")
> 
>> The Dell laptop remains the only problem then on 4.0-rc6, there IS an
>> acpi interrupt  (but firing once apparently).
>> There isn't an option in BIOS to enable LAPIC, however, when specifying
>> 'lapic' as boot parameter I got interesting result, still not working
>> and /proc/interrups still shows XT-PIC.  Doing a diff between dmesg on
>> 3.19 and 4.0-rc6 this pops out:
>>
>> -Local APIC disabled by BIOS -- you can enable it with "lapic"
>> -APIC: disable apic facility
>> -APIC: switched to apic NOOP
>> +Local APIC disabled by BIOS -- reenabling.
>> +Found and enabled local APIC!
>>
>> +Enabling APIC mode:  Flat.  Using 0 I/O APICs
> What's the last know working kernel for Dell laptop?
> Does it work as expected with v3.19 kernel?
> Do you means this message is from plain v4.0-rc6 kernel?
> Thanks!
> Gerry
> 
>>
>> Jim
>>
> 

Gerry, Rafael,

Ok, found it.
It was very 'interesting' bisect, because there were 2 overlapping
issues here.  On the Dell laptop some kernels there wasn't an ACPI
interrupt at all or it fired once and then seemed to get stuck.
Turns out that kernel version:
3.16: OK
3.17: Broken (no acpi interrupt)
3.18: actually fine
3.19: Broken

So started bisecting between 3.18 or 3.19, in the end found Rafael's
patch which broke it:

==
commit c50f13c672df758b59e026c15b9118f3ed46edc4
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date:   Mon Dec 1 23:50:16 2014 +0100

    ACPICA: Save current masks of enabled GPEs after enable register writes
==

Reverting that patch on top of 4.0-rc7 (with some offsets and one
trivial manual edit) and I finally got a working ACPI interrupt again!

Jim



--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jiang Liu April 11, 2015, 4:57 p.m. UTC | #9
On 2015/4/11 23:08, Jim Bos wrote:
> On 04/10/2015 03:56 AM, Jiang Liu wrote:
>> On 2015/4/10 0:41, Jim Bos wrote:
>>> On 04/09/2015 12:15 PM, Jiang Liu wrote:
>>>> On 2015/4/8 23:51, Jim Bos wrote:
>>>>> On 04/08/2015 07:26 AM, Jiang Liu wrote:
>>>>>> On 2015/4/8 0:49, Jim Bos wrote:
>>>>>>> On 04/07/2015 04:34 PM, Jiang Liu wrote:
>> <snip>
>>>> Hi Jim,
>>>> 	I'm really confused. I can't even explain why my previous
>>>> patch fixes the issue on AMD geode board now:(
>>>>
>>>> For the Dell laptop, seems you have:
>>>> 1) build a kernel with Local APIC and IOAPIC enabled
>>>> 2) lapic is disabled by BIOS, so there's no ACPI MADT(APIC)
>>>> table at all.
>>>> That means the laptop is working with 8259 PICs only.
>>>> There's little change between 3.16 and 4.0 related to 8259.
>>>>
>>>> For the AMD geode board, I still think original code is right.
>>>> I can't explain why the patch fix the issue.
>>>>
>>>> So could you please help to:
>>>> 1) Try to enable lapic on Dell laptop in BIOS
>>>> 2) Dump acpi tables and dmesg on AMD board
>>>>
>>>> If that still doesn't help, I will try to send you some
>>>> debug patches to gather more info.
>>>> Thanks!
>>>> Gerry
>>>>> _
>>>>> Jim
>>>>>
>>>>
>>>
>>> Gerry,
>>>
>>> As you mentioned your patch shouldn't make a difference, run some more
>>> tests, as it turns out:
>>> - geode system  broken on 3.16+ up to and including 3.19, however, on
>>> plain 4.0-rc6 it works!  Root cause appears to be there isn't an ACPI
>>> interrupt assigned in non-working kernels.
>>> - other system I got my hands on: Pentium(R) CPU G3220, broken on 3.19.0
>>> when boot parameter 'nosmp' is specified, again no acpi entry in
>>> /proc/interrupts,  working fine on 4.0-rc6
>>>
>>> So obviously between 3.19 and 4.0-rc6 something got fixed here!
>> Hi Jim,
>> Yes, the bugfix patch should be:
>> commit 1ea76fbadd66("x86/irq: Fix regression caused by commit b568b8601f05")
>>
>>> The Dell laptop remains the only problem then on 4.0-rc6, there IS an
>>> acpi interrupt  (but firing once apparently).
>>> There isn't an option in BIOS to enable LAPIC, however, when specifying
>>> 'lapic' as boot parameter I got interesting result, still not working
>>> and /proc/interrups still shows XT-PIC.  Doing a diff between dmesg on
>>> 3.19 and 4.0-rc6 this pops out:
>>>
>>> -Local APIC disabled by BIOS -- you can enable it with "lapic"
>>> -APIC: disable apic facility
>>> -APIC: switched to apic NOOP
>>> +Local APIC disabled by BIOS -- reenabling.
>>> +Found and enabled local APIC!
>>>
>>> +Enabling APIC mode:  Flat.  Using 0 I/O APICs
>> What's the last know working kernel for Dell laptop?
>> Does it work as expected with v3.19 kernel?
>> Do you means this message is from plain v4.0-rc6 kernel?
>> Thanks!
>> Gerry
>>
>>>
>>> Jim
>>>
>>
> 
> Gerry, Rafael,
> 
> Ok, found it.
> It was very 'interesting' bisect, because there were 2 overlapping
> issues here.  On the Dell laptop some kernels there wasn't an ACPI
> interrupt at all or it fired once and then seemed to get stuck.
> Turns out that kernel version:
> 3.16: OK
> 3.17: Broken (no acpi interrupt)
> 3.18: actually fine
> 3.19: Broken
> 
> So started bisecting between 3.18 or 3.19, in the end found Rafael's
> patch which broke it:
> 
> ==
> commit c50f13c672df758b59e026c15b9118f3ed46edc4
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date:   Mon Dec 1 23:50:16 2014 +0100
> 
>     ACPICA: Save current masks of enabled GPEs after enable register writes
> ==
> 
> Reverting that patch on top of 4.0-rc7 (with some offsets and one
> trivial manual edit) and I finally got a working ACPI interrupt again!
Hi Jim,
	Thanks for your great effort to bisect the regression.
And it gets reasonable now:)
Thanks!
Gerry

> 
> Jim
> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Rafael J. Wysocki April 12, 2015, 1:29 a.m. UTC | #10
On Saturday, April 11, 2015 05:08:38 PM Jim Bos wrote:
> On 04/10/2015 03:56 AM, Jiang Liu wrote:
> > On 2015/4/10 0:41, Jim Bos wrote:
> >> On 04/09/2015 12:15 PM, Jiang Liu wrote:
> >>> On 2015/4/8 23:51, Jim Bos wrote:
> >>>> On 04/08/2015 07:26 AM, Jiang Liu wrote:
> >>>>> On 2015/4/8 0:49, Jim Bos wrote:
> >>>>>> On 04/07/2015 04:34 PM, Jiang Liu wrote:
> > <snip>
> >>> Hi Jim,
> >>> 	I'm really confused. I can't even explain why my previous
> >>> patch fixes the issue on AMD geode board now:(
> >>>
> >>> For the Dell laptop, seems you have:
> >>> 1) build a kernel with Local APIC and IOAPIC enabled
> >>> 2) lapic is disabled by BIOS, so there's no ACPI MADT(APIC)
> >>> table at all.
> >>> That means the laptop is working with 8259 PICs only.
> >>> There's little change between 3.16 and 4.0 related to 8259.
> >>>
> >>> For the AMD geode board, I still think original code is right.
> >>> I can't explain why the patch fix the issue.
> >>>
> >>> So could you please help to:
> >>> 1) Try to enable lapic on Dell laptop in BIOS
> >>> 2) Dump acpi tables and dmesg on AMD board
> >>>
> >>> If that still doesn't help, I will try to send you some
> >>> debug patches to gather more info.
> >>> Thanks!
> >>> Gerry
> >>>> _
> >>>> Jim
> >>>>
> >>>
> >>
> >> Gerry,
> >>
> >> As you mentioned your patch shouldn't make a difference, run some more
> >> tests, as it turns out:
> >> - geode system  broken on 3.16+ up to and including 3.19, however, on
> >> plain 4.0-rc6 it works!  Root cause appears to be there isn't an ACPI
> >> interrupt assigned in non-working kernels.
> >> - other system I got my hands on: Pentium(R) CPU G3220, broken on 3.19.0
> >> when boot parameter 'nosmp' is specified, again no acpi entry in
> >> /proc/interrupts,  working fine on 4.0-rc6
> >>
> >> So obviously between 3.19 and 4.0-rc6 something got fixed here!
> > Hi Jim,
> > Yes, the bugfix patch should be:
> > commit 1ea76fbadd66("x86/irq: Fix regression caused by commit b568b8601f05")
> > 
> >> The Dell laptop remains the only problem then on 4.0-rc6, there IS an
> >> acpi interrupt  (but firing once apparently).
> >> There isn't an option in BIOS to enable LAPIC, however, when specifying
> >> 'lapic' as boot parameter I got interesting result, still not working
> >> and /proc/interrups still shows XT-PIC.  Doing a diff between dmesg on
> >> 3.19 and 4.0-rc6 this pops out:
> >>
> >> -Local APIC disabled by BIOS -- you can enable it with "lapic"
> >> -APIC: disable apic facility
> >> -APIC: switched to apic NOOP
> >> +Local APIC disabled by BIOS -- reenabling.
> >> +Found and enabled local APIC!
> >>
> >> +Enabling APIC mode:  Flat.  Using 0 I/O APICs
> > What's the last know working kernel for Dell laptop?
> > Does it work as expected with v3.19 kernel?
> > Do you means this message is from plain v4.0-rc6 kernel?
> > Thanks!
> > Gerry
> > 
> >>
> >> Jim
> >>
> > 
> 
> Gerry, Rafael,
> 
> Ok, found it.
> It was very 'interesting' bisect, because there were 2 overlapping
> issues here.  On the Dell laptop some kernels there wasn't an ACPI
> interrupt at all or it fired once and then seemed to get stuck.
> Turns out that kernel version:
> 3.16: OK
> 3.17: Broken (no acpi interrupt)
> 3.18: actually fine
> 3.19: Broken
> 
> So started bisecting between 3.18 or 3.19, in the end found Rafael's
> patch which broke it:
> 
> ==
> commit c50f13c672df758b59e026c15b9118f3ed46edc4
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date:   Mon Dec 1 23:50:16 2014 +0100
> 
>     ACPICA: Save current masks of enabled GPEs after enable register writes
> ==
> 
> Reverting that patch on top of 4.0-rc7 (with some offsets and one
> trivial manual edit) and I finally got a working ACPI interrupt again!

That's unexpected.

Is system suspend/resume involved in the reproduction of the problem in any way?

In any case, does it help if you replace "enable_mask" with "enable_for_run"
in line 127 of drivers/acpi/acpica/hwgpe.c (without reverting the whole commit)?
diff mbox

Patch

diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 803b684676ff..f7f1fe7cd1b0 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -403,10 +403,14 @@  static int mp_config_acpi_gsi(struct device *dev, u32 gsi, int trigger,
 static int mp_register_gsi(struct device *dev, u32 gsi, int trigger,
 			   int polarity)
 {
-	int irq, node;
+	int i, irq, node;
 
-	if (acpi_irq_model != ACPI_IRQ_MODEL_IOAPIC)
-		return gsi;
+	if (acpi_irq_model != ACPI_IRQ_MODEL_IOAPIC) {
+		for (i = 0; i < nr_legacy_irqs(); i++)
+			if (isa_irq_to_gsi[i] == gsi)
+				return i;
+		return -1;
+	}
 
 	trigger = trigger == ACPI_EDGE_SENSITIVE ? 0 : 1;
 	polarity = polarity == ACPI_ACTIVE_HIGH ? 0 : 1;