Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Al Stone]

On 10/14/2015 03:25 PM, Rafael J. Wysocki wrote:
> On Wednesday, October 14, 2015 02:20:51 PM Al Stone wrote:
>> This is a multi-part message in MIME format.
>> --020400080004050109020606
>> Content-Type: text/plain; charset=utf-8
>> Content-Transfer-Encoding: 7bit
>>
>> On 10/12/2015 10:06 PM, Pat Erley wrote:
>>> On 10/12/2015 01:52 PM, Al Stone wrote:
 On 10/11/2015 09:58 PM, Pat Erley wrote:
> On 10/11/2015 08:49 PM, Hanjun Guo wrote:
>> On 10/12/2015 11:08 AM, Pat Erley wrote:
>>> On 10/05/2015 10:12 AM, Al Stone wrote:
 On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
> On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
>> On 09/30/2015 03:00 AM, Hanjun Guo wrote:
>>> On 2015/9/30 7:45, Al Stone wrote:
 NB: this patch set is for use against the linux-pm bleeding edge
 branch.

>>
>> [snip...]
>>
>>>
>>> For this patch set,
>>>
>>> Reviewed-by: Hanjun Guo 
>>>
>>> Thanks
>>> Hanjun
>>
>> Thanks, Hanjun!
>
> Series applied, thanks!
>
> Rafael
>

 Thanks, Rafael!

>>>
>>> Just decided to test out linux-next (to see the new nouveau cleanups).
>>> This change set prevents my Lenovo W510 from booting properly.
>>>
>>> Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
>>> eventually replace the macro"
>>>
>>> Gets the system booting again.  I'm attaching my dmesg from the failed
>>> boot, who wants the acpidump?
>>
>> [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
>> [0.00] ACPI: Error parsing LAPIC address override entry
>> [0.00] ACPI: Invalid BIOS MADT, disabling ACPI
>>
>> Seems the MADT revision is not right, could you dump the ACPI MADT
>> (APIC) table and send it out? I will take a look :)
>>
>> Thanks
>> Hanjun
>
> Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.

 Pat,

 Would you mind sending a copy of the FADT, also, please?  The first of the
 ACPI messages is a check of version correspondence between the FADT and 
 MADT,
 while the second message is from looking at just an MADT subtable.  Thanks
 for sending the MADT out -- that helps me quite a lot in thinking this 
 through.

 BTW, whoever is providing the BIOS (Lenovo, I assume) may want to have a 
 look
 at these, also:

 [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in
 FADT/Pm1aControlBlock: 16/32 (20150818/tbfadt-623)
 [0.00] ACPI BIOS Warning (bug): Invalid length for
 FADT/Pm1aControlBlock: 32, using default 16 (20150818/tbfadt-704)

 Not inherently dangerous, but definitely sloppy and mind-numbingly easy to
 avoid, IIRC.

>>>
>>> Here ya go.
>>
>> Okay.  There's just a lot of weird stuff out there in ACPI-land.  I've
>> attached four minor fixes for the special cases that have been reported
>> (well, the last one is actually a fix for a typo in the spec, but just
>> the same...).
>>
>> These should apply on top of linux-next; would you mind trying them out
>> to make sure I didn't break anything else on your laptop?  If they behave
>> as I hope they will, I think I'll have covered all the places where the
>> checking of MADT subtables needs to be be relaxed a bit.  These work for
>> me on arm64, but if they work for you and a couple of other testers, then
>> I'll send them to Rafael properly.
> 
> Well, you might as well submit them properly right away, so I could pick
> them up and put them into my linux-next branch, which then might make it
> easier for some people to test them.
> 
> Thanks,
> Rafael
> 

Fair enough.  I was just being overly cautious about possible further breakage.

Done.  Patch series sent to the list.

-- 
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Rafael J. Wysocki]

On Wednesday, October 14, 2015 02:20:51 PM Al Stone wrote:
> This is a multi-part message in MIME format.
> --020400080004050109020606
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 7bit
> 
> On 10/12/2015 10:06 PM, Pat Erley wrote:
> > On 10/12/2015 01:52 PM, Al Stone wrote:
> >> On 10/11/2015 09:58 PM, Pat Erley wrote:
> >>> On 10/11/2015 08:49 PM, Hanjun Guo wrote:
>  On 10/12/2015 11:08 AM, Pat Erley wrote:
> > On 10/05/2015 10:12 AM, Al Stone wrote:
> >> On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
> >>> On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
>  On 09/30/2015 03:00 AM, Hanjun Guo wrote:
> > On 2015/9/30 7:45, Al Stone wrote:
> >> NB: this patch set is for use against the linux-pm bleeding edge
> >> branch.
> >>
> 
>  [snip...]
> 
> >
> > For this patch set,
> >
> > Reviewed-by: Hanjun Guo 
> >
> > Thanks
> > Hanjun
> 
>  Thanks, Hanjun!
> >>>
> >>> Series applied, thanks!
> >>>
> >>> Rafael
> >>>
> >>
> >> Thanks, Rafael!
> >>
> >
> > Just decided to test out linux-next (to see the new nouveau cleanups).
> > This change set prevents my Lenovo W510 from booting properly.
> >
> > Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
> > eventually replace the macro"
> >
> > Gets the system booting again.  I'm attaching my dmesg from the failed
> > boot, who wants the acpidump?
> 
>  [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
>  [0.00] ACPI: Error parsing LAPIC address override entry
>  [0.00] ACPI: Invalid BIOS MADT, disabling ACPI
> 
>  Seems the MADT revision is not right, could you dump the ACPI MADT
>  (APIC) table and send it out? I will take a look :)
> 
>  Thanks
>  Hanjun
> >>>
> >>> Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.
> >>
> >> Pat,
> >>
> >> Would you mind sending a copy of the FADT, also, please?  The first of the
> >> ACPI messages is a check of version correspondence between the FADT and 
> >> MADT,
> >> while the second message is from looking at just an MADT subtable.  Thanks
> >> for sending the MADT out -- that helps me quite a lot in thinking this 
> >> through.
> >>
> >> BTW, whoever is providing the BIOS (Lenovo, I assume) may want to have a 
> >> look
> >> at these, also:
> >>
> >> [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in
> >> FADT/Pm1aControlBlock: 16/32 (20150818/tbfadt-623)
> >> [0.00] ACPI BIOS Warning (bug): Invalid length for
> >> FADT/Pm1aControlBlock: 32, using default 16 (20150818/tbfadt-704)
> >>
> >> Not inherently dangerous, but definitely sloppy and mind-numbingly easy to
> >> avoid, IIRC.
> >>
> > 
> > Here ya go.
> 
> Okay.  There's just a lot of weird stuff out there in ACPI-land.  I've
> attached four minor fixes for the special cases that have been reported
> (well, the last one is actually a fix for a typo in the spec, but just
> the same...).
> 
> These should apply on top of linux-next; would you mind trying them out
> to make sure I didn't break anything else on your laptop?  If they behave
> as I hope they will, I think I'll have covered all the places where the
> checking of MADT subtables needs to be be relaxed a bit.  These work for
> me on arm64, but if they work for you and a couple of other testers, then
> I'll send them to Rafael properly.

Well, you might as well submit them properly right away, so I could pick
them up and put them into my linux-next branch, which then might make it
easier for some people to test them.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Al Stone]

On 10/12/2015 10:06 PM, Pat Erley wrote:
> On 10/12/2015 01:52 PM, Al Stone wrote:
>> On 10/11/2015 09:58 PM, Pat Erley wrote:
>>> On 10/11/2015 08:49 PM, Hanjun Guo wrote:
 On 10/12/2015 11:08 AM, Pat Erley wrote:
> On 10/05/2015 10:12 AM, Al Stone wrote:
>> On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
>>> On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
 On 09/30/2015 03:00 AM, Hanjun Guo wrote:
> On 2015/9/30 7:45, Al Stone wrote:
>> NB: this patch set is for use against the linux-pm bleeding edge
>> branch.
>>

 [snip...]

>
> For this patch set,
>
> Reviewed-by: Hanjun Guo 
>
> Thanks
> Hanjun

 Thanks, Hanjun!
>>>
>>> Series applied, thanks!
>>>
>>> Rafael
>>>
>>
>> Thanks, Rafael!
>>
>
> Just decided to test out linux-next (to see the new nouveau cleanups).
> This change set prevents my Lenovo W510 from booting properly.
>
> Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
> eventually replace the macro"
>
> Gets the system booting again.  I'm attaching my dmesg from the failed
> boot, who wants the acpidump?

 [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
 [0.00] ACPI: Error parsing LAPIC address override entry
 [0.00] ACPI: Invalid BIOS MADT, disabling ACPI

 Seems the MADT revision is not right, could you dump the ACPI MADT
 (APIC) table and send it out? I will take a look :)

 Thanks
 Hanjun
>>>
>>> Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.
>>
>> Pat,
>>
>> Would you mind sending a copy of the FADT, also, please?  The first of the
>> ACPI messages is a check of version correspondence between the FADT and MADT,
>> while the second message is from looking at just an MADT subtable.  Thanks
>> for sending the MADT out -- that helps me quite a lot in thinking this 
>> through.
>>
>> BTW, whoever is providing the BIOS (Lenovo, I assume) may want to have a look
>> at these, also:
>>
>> [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in
>> FADT/Pm1aControlBlock: 16/32 (20150818/tbfadt-623)
>> [0.00] ACPI BIOS Warning (bug): Invalid length for
>> FADT/Pm1aControlBlock: 32, using default 16 (20150818/tbfadt-704)
>>
>> Not inherently dangerous, but definitely sloppy and mind-numbingly easy to
>> avoid, IIRC.
>>
> 
> Here ya go.

Okay.  There's just a lot of weird stuff out there in ACPI-land.  I've
attached four minor fixes for the special cases that have been reported
(well, the last one is actually a fix for a typo in the spec, but just
the same...).

These should apply on top of linux-next; would you mind trying them out
to make sure I didn't break anything else on your laptop?  If they behave
as I hope they will, I think I'll have covered all the places where the
checking of MADT subtables needs to be be relaxed a bit.  These work for
me on arm64, but if they work for you and a couple of other testers, then
I'll send them to Rafael properly.

Many thanks!

-- 
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
>From 52a2011c4998674d80c4456e6fd8ba11beaee65c Mon Sep 17 00:00:00 2001
From: Al Stone 
Date: Tue, 13 Oct 2015 15:29:15 -0600
Subject: [PATCH 1/4] ACPI: workaround x86 firmware using reserved MADT
 subtable IDs

According to the ACPI specification, version 6.0, table 5-46,  MADT
subtable IDs in the range of 0x10-0x7f are reserved for possible
future use by the specification.  The function bad_madt_entry() tries
to enforce the spec, but it turns out there are x86 machines that use
0x7f even though they should not.

So, continue to enforce this rule for arm64, since we're starting out
fresh, but relax it for systems already out there so we don't keep them
from booting.

Signed-off-by: Al Stone 
---
 drivers/acpi/tables.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index a2ed38a..e5cfd72 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -413,9 +413,17 @@ static int __init bad_madt_entry(struct acpi_table_header *table,
 	}
 
 	if (entry->type >= ms->num_types) {
-		pr_err("undefined MADT subtable type for FADT %d.%d: %d (length %d)\n",
-		   major, minor, entry->type, entry->length);
-		return 1;
+		if (IS_ENABLED(CONFIG_ARM64)) {
+			/* Enforce this stricture on arm64... */
+			pr_err("undefined MADT subtable type for FADT %d.%d: %d (length %d)\n",
+			   major, minor, entry->type, entry->length);
+			return 1;
+		} else {
+			/* ... but relax it on legacy systems so they boot */
+			pr_warn("undefined MADT subtable type for FADT %d.%d: %d (length %d)\n",
+			 major, minor, entry->type, entry->length);
+			return 0;
+		}

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Al Stone]

On 10/12/2015 10:06 PM, Pat Erley wrote:
> On 10/12/2015 01:52 PM, Al Stone wrote:
>> On 10/11/2015 09:58 PM, Pat Erley wrote:
>>> On 10/11/2015 08:49 PM, Hanjun Guo wrote:
 On 10/12/2015 11:08 AM, Pat Erley wrote:
> On 10/05/2015 10:12 AM, Al Stone wrote:
>> On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
>>> On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
 On 09/30/2015 03:00 AM, Hanjun Guo wrote:
> On 2015/9/30 7:45, Al Stone wrote:
>> NB: this patch set is for use against the linux-pm bleeding edge
>> branch.
>>

 [snip...]

>
> For this patch set,
>
> Reviewed-by: Hanjun Guo 
>
> Thanks
> Hanjun

 Thanks, Hanjun!
>>>
>>> Series applied, thanks!
>>>
>>> Rafael
>>>
>>
>> Thanks, Rafael!
>>
>
> Just decided to test out linux-next (to see the new nouveau cleanups).
> This change set prevents my Lenovo W510 from booting properly.
>
> Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
> eventually replace the macro"
>
> Gets the system booting again.  I'm attaching my dmesg from the failed
> boot, who wants the acpidump?

 [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
 [0.00] ACPI: Error parsing LAPIC address override entry
 [0.00] ACPI: Invalid BIOS MADT, disabling ACPI

 Seems the MADT revision is not right, could you dump the ACPI MADT
 (APIC) table and send it out? I will take a look :)

 Thanks
 Hanjun
>>>
>>> Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.
>>
>> Pat,
>>
>> Would you mind sending a copy of the FADT, also, please?  The first of the
>> ACPI messages is a check of version correspondence between the FADT and MADT,
>> while the second message is from looking at just an MADT subtable.  Thanks
>> for sending the MADT out -- that helps me quite a lot in thinking this 
>> through.
>>
>> BTW, whoever is providing the BIOS (Lenovo, I assume) may want to have a look
>> at these, also:
>>
>> [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in
>> FADT/Pm1aControlBlock: 16/32 (20150818/tbfadt-623)
>> [0.00] ACPI BIOS Warning (bug): Invalid length for
>> FADT/Pm1aControlBlock: 32, using default 16 (20150818/tbfadt-704)
>>
>> Not inherently dangerous, but definitely sloppy and mind-numbingly easy to
>> avoid, IIRC.
>>
> 
> Here ya go.

Okay.  There's just a lot of weird stuff out there in ACPI-land.  I've
attached four minor fixes for the special cases that have been reported
(well, the last one is actually a fix for a typo in the spec, but just
the same...).

These should apply on top of linux-next; would you mind trying them out
to make sure I didn't break anything else on your laptop?  If they behave
as I hope they will, I think I'll have covered all the places where the
checking of MADT subtables needs to be be relaxed a bit.  These work for
me on arm64, but if they work for you and a couple of other testers, then
I'll send them to Rafael properly.

Many thanks!

-- 
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
>From 52a2011c4998674d80c4456e6fd8ba11beaee65c Mon Sep 17 00:00:00 2001
From: Al Stone 
Date: Tue, 13 Oct 2015 15:29:15 -0600
Subject: [PATCH 1/4] ACPI: workaround x86 firmware using reserved MADT
 subtable IDs

According to the ACPI specification, version 6.0, table 5-46,  MADT
subtable IDs in the range of 0x10-0x7f are reserved for possible
future use by the specification.  The function bad_madt_entry() tries
to enforce the spec, but it turns out there are x86 machines that use
0x7f even though they should not.

So, continue to enforce this rule for arm64, since we're starting out
fresh, but relax it for systems already out there so we don't keep them
from booting.

Signed-off-by: Al Stone 
---
 drivers/acpi/tables.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index a2ed38a..e5cfd72 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -413,9 +413,17 @@ static int __init bad_madt_entry(struct acpi_table_header *table,
 	}
 
 	if (entry->type >= ms->num_types) {
-		pr_err("undefined MADT subtable type for FADT %d.%d: %d (length %d)\n",
-		   major, minor, entry->type, entry->length);
-		return 1;
+		if (IS_ENABLED(CONFIG_ARM64)) {
+			/* Enforce this stricture on arm64... */
+			pr_err("undefined MADT subtable type for FADT %d.%d: %d (length %d)\n",
+			   major, minor, entry->type, entry->length);
+			return 1;
+		} else {
+			/* ... but relax it on legacy systems so they boot */
+			pr_warn("undefined MADT subtable type for FADT %d.%d: %d (length %d)\n",
+			 

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Al Stone]

On 10/14/2015 03:25 PM, Rafael J. Wysocki wrote:
> On Wednesday, October 14, 2015 02:20:51 PM Al Stone wrote:
>> This is a multi-part message in MIME format.
>> --020400080004050109020606
>> Content-Type: text/plain; charset=utf-8
>> Content-Transfer-Encoding: 7bit
>>
>> On 10/12/2015 10:06 PM, Pat Erley wrote:
>>> On 10/12/2015 01:52 PM, Al Stone wrote:
 On 10/11/2015 09:58 PM, Pat Erley wrote:
> On 10/11/2015 08:49 PM, Hanjun Guo wrote:
>> On 10/12/2015 11:08 AM, Pat Erley wrote:
>>> On 10/05/2015 10:12 AM, Al Stone wrote:
 On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
> On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
>> On 09/30/2015 03:00 AM, Hanjun Guo wrote:
>>> On 2015/9/30 7:45, Al Stone wrote:
 NB: this patch set is for use against the linux-pm bleeding edge
 branch.

>>
>> [snip...]
>>
>>>
>>> For this patch set,
>>>
>>> Reviewed-by: Hanjun Guo 
>>>
>>> Thanks
>>> Hanjun
>>
>> Thanks, Hanjun!
>
> Series applied, thanks!
>
> Rafael
>

 Thanks, Rafael!

>>>
>>> Just decided to test out linux-next (to see the new nouveau cleanups).
>>> This change set prevents my Lenovo W510 from booting properly.
>>>
>>> Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
>>> eventually replace the macro"
>>>
>>> Gets the system booting again.  I'm attaching my dmesg from the failed
>>> boot, who wants the acpidump?
>>
>> [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
>> [0.00] ACPI: Error parsing LAPIC address override entry
>> [0.00] ACPI: Invalid BIOS MADT, disabling ACPI
>>
>> Seems the MADT revision is not right, could you dump the ACPI MADT
>> (APIC) table and send it out? I will take a look :)
>>
>> Thanks
>> Hanjun
>
> Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.

 Pat,

 Would you mind sending a copy of the FADT, also, please?  The first of the
 ACPI messages is a check of version correspondence between the FADT and 
 MADT,
 while the second message is from looking at just an MADT subtable.  Thanks
 for sending the MADT out -- that helps me quite a lot in thinking this 
 through.

 BTW, whoever is providing the BIOS (Lenovo, I assume) may want to have a 
 look
 at these, also:

 [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in
 FADT/Pm1aControlBlock: 16/32 (20150818/tbfadt-623)
 [0.00] ACPI BIOS Warning (bug): Invalid length for
 FADT/Pm1aControlBlock: 32, using default 16 (20150818/tbfadt-704)

 Not inherently dangerous, but definitely sloppy and mind-numbingly easy to
 avoid, IIRC.

>>>
>>> Here ya go.
>>
>> Okay.  There's just a lot of weird stuff out there in ACPI-land.  I've
>> attached four minor fixes for the special cases that have been reported
>> (well, the last one is actually a fix for a typo in the spec, but just
>> the same...).
>>
>> These should apply on top of linux-next; would you mind trying them out
>> to make sure I didn't break anything else on your laptop?  If they behave
>> as I hope they will, I think I'll have covered all the places where the
>> checking of MADT subtables needs to be be relaxed a bit.  These work for
>> me on arm64, but if they work for you and a couple of other testers, then
>> I'll send them to Rafael properly.
> 
> Well, you might as well submit them properly right away, so I could pick
> them up and put them into my linux-next branch, which then might make it
> easier for some people to test them.
> 
> Thanks,
> Rafael
> 

Fair enough.  I was just being overly cautious about possible further breakage.

Done.  Patch series sent to the list.

-- 
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Rafael J. Wysocki]

On Wednesday, October 14, 2015 02:20:51 PM Al Stone wrote:
> This is a multi-part message in MIME format.
> --020400080004050109020606
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: 7bit
> 
> On 10/12/2015 10:06 PM, Pat Erley wrote:
> > On 10/12/2015 01:52 PM, Al Stone wrote:
> >> On 10/11/2015 09:58 PM, Pat Erley wrote:
> >>> On 10/11/2015 08:49 PM, Hanjun Guo wrote:
>  On 10/12/2015 11:08 AM, Pat Erley wrote:
> > On 10/05/2015 10:12 AM, Al Stone wrote:
> >> On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
> >>> On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
>  On 09/30/2015 03:00 AM, Hanjun Guo wrote:
> > On 2015/9/30 7:45, Al Stone wrote:
> >> NB: this patch set is for use against the linux-pm bleeding edge
> >> branch.
> >>
> 
>  [snip...]
> 
> >
> > For this patch set,
> >
> > Reviewed-by: Hanjun Guo 
> >
> > Thanks
> > Hanjun
> 
>  Thanks, Hanjun!
> >>>
> >>> Series applied, thanks!
> >>>
> >>> Rafael
> >>>
> >>
> >> Thanks, Rafael!
> >>
> >
> > Just decided to test out linux-next (to see the new nouveau cleanups).
> > This change set prevents my Lenovo W510 from booting properly.
> >
> > Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
> > eventually replace the macro"
> >
> > Gets the system booting again.  I'm attaching my dmesg from the failed
> > boot, who wants the acpidump?
> 
>  [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
>  [0.00] ACPI: Error parsing LAPIC address override entry
>  [0.00] ACPI: Invalid BIOS MADT, disabling ACPI
> 
>  Seems the MADT revision is not right, could you dump the ACPI MADT
>  (APIC) table and send it out? I will take a look :)
> 
>  Thanks
>  Hanjun
> >>>
> >>> Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.
> >>
> >> Pat,
> >>
> >> Would you mind sending a copy of the FADT, also, please?  The first of the
> >> ACPI messages is a check of version correspondence between the FADT and 
> >> MADT,
> >> while the second message is from looking at just an MADT subtable.  Thanks
> >> for sending the MADT out -- that helps me quite a lot in thinking this 
> >> through.
> >>
> >> BTW, whoever is providing the BIOS (Lenovo, I assume) may want to have a 
> >> look
> >> at these, also:
> >>
> >> [0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in
> >> FADT/Pm1aControlBlock: 16/32 (20150818/tbfadt-623)
> >> [0.00] ACPI BIOS Warning (bug): Invalid length for
> >> FADT/Pm1aControlBlock: 32, using default 16 (20150818/tbfadt-704)
> >>
> >> Not inherently dangerous, but definitely sloppy and mind-numbingly easy to
> >> avoid, IIRC.
> >>
> > 
> > Here ya go.
> 
> Okay.  There's just a lot of weird stuff out there in ACPI-land.  I've
> attached four minor fixes for the special cases that have been reported
> (well, the last one is actually a fix for a typo in the spec, but just
> the same...).
> 
> These should apply on top of linux-next; would you mind trying them out
> to make sure I didn't break anything else on your laptop?  If they behave
> as I hope they will, I think I'll have covered all the places where the
> checking of MADT subtables needs to be be relaxed a bit.  These work for
> me on arm64, but if they work for you and a couple of other testers, then
> I'll send them to Rafael properly.

Well, you might as well submit them properly right away, so I could pick
them up and put them into my linux-next branch, which then might make it
easier for some people to test them.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Sudeep Holla]

On 12/10/15 20:25, Rafael J. Wysocki wrote:

On Monday, October 12, 2015 10:44:52 AM Sudeep Holla wrote:


[...]



Instead of just removing the check completely on x86, IMO restrict
it to some newer/later version of ACPI so you can still force
vendors to fix their ACPI tables at-least in future.


No, we can't force vendors to fix their ACPI tables.  This is
completely unrealistic.



No, I was referring to the future platforms *only*


We simly need to deal with the bugs in the ACPI tables in the
kernel.



Yes sadly true for existing systems, but if we now place a check for
ACPIv6.0 and above, we might avoid seeing such broken tables sometime in
future once the kernel with this check in place is used for validation.


It would be good to get such sanity check in the tools used to
build those tables, but yes since such static tables can be built
in many ways, its difficult to deal it in all those tools.


As I said to Al, we need those checks in firmware test suites.
Having them in the kernel is OK too, but they should cause warnings
to be printed to the kernel log instead of causing the kernel to
panic.



Agreed

--
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Sudeep Holla]

On 12/10/15 20:25, Rafael J. Wysocki wrote:

On Monday, October 12, 2015 10:44:52 AM Sudeep Holla wrote:


[...]



Instead of just removing the check completely on x86, IMO restrict
it to some newer/later version of ACPI so you can still force
vendors to fix their ACPI tables at-least in future.


No, we can't force vendors to fix their ACPI tables.  This is
completely unrealistic.



No, I was referring to the future platforms *only*


We simly need to deal with the bugs in the ACPI tables in the
kernel.



Yes sadly true for existing systems, but if we now place a check for
ACPIv6.0 and above, we might avoid seeing such broken tables sometime in
future once the kernel with this check in place is used for validation.


It would be good to get such sanity check in the tools used to
build those tables, but yes since such static tables can be built
in many ways, its difficult to deal it in all those tools.


As I said to Al, we need those checks in firmware test suites.
Having them in the kernel is OK too, but they should cause warnings
to be printed to the kernel log instead of causing the kernel to
panic.



Agreed

--
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Pat Erley]

On 10/12/2015 01:52 PM, Al Stone wrote:

On 10/11/2015 09:58 PM, Pat Erley wrote:

On 10/11/2015 08:49 PM, Hanjun Guo wrote:

On 10/12/2015 11:08 AM, Pat Erley wrote:

On 10/05/2015 10:12 AM, Al Stone wrote:

On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:

On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:

On 09/30/2015 03:00 AM, Hanjun Guo wrote:

On 2015/9/30 7:45, Al Stone wrote:

NB: this patch set is for use against the linux-pm bleeding edge
branch.



[snip...]



For this patch set,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun


Thanks, Hanjun!


Series applied, thanks!

Rafael



Thanks, Rafael!



Just decided to test out linux-next (to see the new nouveau cleanups).
This change set prevents my Lenovo W510 from booting properly.

Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
eventually replace the macro"

Gets the system booting again.  I'm attaching my dmesg from the failed
boot, who wants the acpidump?


[0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI

Seems the MADT revision is not right, could you dump the ACPI MADT
(APIC) table and send it out? I will take a look :)

Thanks
Hanjun


Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.


Pat,

Would you mind sending a copy of the FADT, also, please?  The first of the
ACPI messages is a check of version correspondence between the FADT and MADT,
while the second message is from looking at just an MADT subtable.  Thanks
for sending the MADT out -- that helps me quite a lot in thinking this through.

BTW, whoever is providing the BIOS (Lenovo, I assume) may want to have a look
at these, also:

[0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in
FADT/Pm1aControlBlock: 16/32 (20150818/tbfadt-623)
[0.00] ACPI BIOS Warning (bug): Invalid length for
FADT/Pm1aControlBlock: 32, using default 16 (20150818/tbfadt-704)

Not inherently dangerous, but definitely sloppy and mind-numbingly easy to
avoid, IIRC.



Here ya go.
/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20150717-64
 * Copyright (c) 2000 - 2015 Intel Corporation
 * 
 * Disassembly of facp.dat, Mon Oct 12 21:06:03 2015
 *
 * ACPI Data Table [FACP]
 *
 * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
 */

[000h    4]Signature : "FACP"[Fixed ACPI Description Table (FADT)]
[004h 0004   4] Table Length : 00F4
[008h 0008   1] Revision : 04
[009h 0009   1] Checksum : 59
[00Ah 0010   6]   Oem ID : "LENOVO"
[010h 0016   8] Oem Table ID : "TP-6N   "
[018h 0024   4] Oem Revision : 1450
[01Ch 0028   4]  Asl Compiler ID : "LNVO"
[020h 0032   4]Asl Compiler Revision : 0001

[024h 0036   4] FACS Address : BBEE7000
[028h 0040   4] DSDT Address : BBFF1C9B
[02Ch 0044   1]Model : 00
[02Dh 0045   1]   PM Profile : 02 [Mobile]
[02Eh 0046   2]SCI Interrupt : 0009
[030h 0048   4] SMI Command Port : 00B2
[034h 0052   1]ACPI Enable Value : F0
[035h 0053   1]   ACPI Disable Value : F1
[036h 0054   1]   S4BIOS Command : 00
[037h 0055   1]  P-State Control : 80
[038h 0056   4] PM1A Event Block Address : 1000
[03Ch 0060   4] PM1B Event Block Address : 
[040h 0064   4]   PM1A Control Block Address : 1004
[044h 0068   4]   PM1B Control Block Address : 
[048h 0072   4]PM2 Control Block Address : 1050
[04Ch 0076   4]   PM Timer Block Address : 1008
[050h 0080   4]   GPE0 Block Address : 1020
[054h 0084   4]   GPE1 Block Address : 
[058h 0088   1]   PM1 Event Block Length : 04
[059h 0089   1] PM1 Control Block Length : 02
[05Ah 0090   1] PM2 Control Block Length : 01
[05Bh 0091   1]PM Timer Block Length : 04
[05Ch 0092   1]GPE0 Block Length : 10
[05Dh 0093   1]GPE1 Block Length : 00
[05Eh 0094   1] GPE1 Base Offset : 00
[05Fh 0095   1] _CST Support : 85
[060h 0096   2]   C2 Latency : 0001
[062h 0098   2]   C3 Latency : 0039
[064h 0100   2]   CPU Cache Size : 
[066h 0102   2]   Cache Flush Stride : 
[068h 0104   1]Duty Cycle Offset : 01
[069h 0105   1] Duty Cycle Width : 03
[06Ah 0106   1]  RTC Day Alarm Index : 0D
[06Bh 0107   1]RTC Month Alarm Index : 00
[06Ch 0108   1]RTC Century Index : 32
[06Dh 0109   2]   Boot Flags (decoded below) : 0012
   Legacy Devices Supported (V2) : 0
8042 Present on ports 60/64 (V2) : 1
VGA Not Present (V4) : 0
  

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Hanjun Guo]

On 10/13/2015 03:21 AM, Rafael J. Wysocki wrote:

On Monday, October 12, 2015 03:04:30 PM Hanjun Guo wrote:

On 10/12/2015 11:58 AM, Pat Erley wrote:

On 10/11/2015 08:49 PM, Hanjun Guo wrote:

On 10/12/2015 11:08 AM, Pat Erley wrote:

On 10/05/2015 10:12 AM, Al Stone wrote:

On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:

On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:

On 09/30/2015 03:00 AM, Hanjun Guo wrote:

On 2015/9/30 7:45, Al Stone wrote:

NB: this patch set is for use against the linux-pm bleeding edge
branch.



[snip...]



For this patch set,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun


Thanks, Hanjun!


Series applied, thanks!

Rafael



Thanks, Rafael!



Just decided to test out linux-next (to see the new nouveau cleanups).
This change set prevents my Lenovo W510 from booting properly.

Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
eventually replace the macro"

Gets the system booting again.  I'm attaching my dmesg from the failed
boot, who wants the acpidump?


[0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI

Seems the MADT revision is not right, could you dump the ACPI MADT
(APIC) table and send it out? I will take a look :)

Thanks
Hanjun


Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.


Thanks! I think I had the right guess, the MADT revision is not right
for ACPI 4.0:

[000h    4]Signature : "APIC"[Multiple APIC
Description Table (MADT)]
[004h 0004   4] Table Length : 00BC
[008h 0008   1] *Revision : 01*

I encountered such problem before because the table was just copied from
previous version, and without the update for table revision.

I think we may need to ignore the table revision for x86, but restrict
it for ARM64, I'd like Al and Rafael's suggestion before I send out a
patch.


As I said before to Al, we definitely can't break systems that worked before
the commit in question.


Sure :)

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Al Stone]

On 10/11/2015 09:58 PM, Pat Erley wrote:
> On 10/11/2015 08:49 PM, Hanjun Guo wrote:
>> On 10/12/2015 11:08 AM, Pat Erley wrote:
>>> On 10/05/2015 10:12 AM, Al Stone wrote:
 On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
> On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
>> On 09/30/2015 03:00 AM, Hanjun Guo wrote:
>>> On 2015/9/30 7:45, Al Stone wrote:
 NB: this patch set is for use against the linux-pm bleeding edge
 branch.

>>
>> [snip...]
>>
>>>
>>> For this patch set,
>>>
>>> Reviewed-by: Hanjun Guo 
>>>
>>> Thanks
>>> Hanjun
>>
>> Thanks, Hanjun!
>
> Series applied, thanks!
>
> Rafael
>

 Thanks, Rafael!

>>>
>>> Just decided to test out linux-next (to see the new nouveau cleanups).
>>> This change set prevents my Lenovo W510 from booting properly.
>>>
>>> Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
>>> eventually replace the macro"
>>>
>>> Gets the system booting again.  I'm attaching my dmesg from the failed
>>> boot, who wants the acpidump?
>>
>> [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
>> [0.00] ACPI: Error parsing LAPIC address override entry
>> [0.00] ACPI: Invalid BIOS MADT, disabling ACPI
>>
>> Seems the MADT revision is not right, could you dump the ACPI MADT
>> (APIC) table and send it out? I will take a look :)
>>
>> Thanks
>> Hanjun
> 
> Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.

Pat,

Would you mind sending a copy of the FADT, also, please?  The first of the
ACPI messages is a check of version correspondence between the FADT and MADT,
while the second message is from looking at just an MADT subtable.  Thanks
for sending the MADT out -- that helps me quite a lot in thinking this through.

BTW, whoever is providing the BIOS (Lenovo, I assume) may want to have a look
at these, also:

[0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in
FADT/Pm1aControlBlock: 16/32 (20150818/tbfadt-623)
[0.00] ACPI BIOS Warning (bug): Invalid length for
FADT/Pm1aControlBlock: 32, using default 16 (20150818/tbfadt-704)

Not inherently dangerous, but definitely sloppy and mind-numbingly easy to
avoid, IIRC.

-- 
ciao,
al
---
Al Stone
Software Engineer
Linaro Enterprise Group
al.st...@linaro.org
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Al Stone]

On 10/12/2015 01:25 PM, Rafael J. Wysocki wrote:
> On Monday, October 12, 2015 10:44:52 AM Sudeep Holla wrote:
>>
>> On 12/10/15 08:04, Hanjun Guo wrote:
>>> On 10/12/2015 11:58 AM, Pat Erley wrote:
 On 10/11/2015 08:49 PM, Hanjun Guo wrote:
> On 10/12/2015 11:08 AM, Pat Erley wrote:
>> On 10/05/2015 10:12 AM, Al Stone wrote:
>>> On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
 On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
> On 09/30/2015 03:00 AM, Hanjun Guo wrote:
>> On 2015/9/30 7:45, Al Stone wrote:
>>> NB: this patch set is for use against the linux-pm bleeding edge
>>> branch.
>>>
>
> [snip...]
>
>>
>> For this patch set,
>>
>> Reviewed-by: Hanjun Guo 
>>
>> Thanks
>> Hanjun
>
> Thanks, Hanjun!

 Series applied, thanks!

 Rafael

>>>
>>> Thanks, Rafael!
>>>
>>
>> Just decided to test out linux-next (to see the new nouveau cleanups).
>> This change set prevents my Lenovo W510 from booting properly.
>>
>> Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
>> eventually replace the macro"
>>
>> Gets the system booting again.  I'm attaching my dmesg from the failed
>> boot, who wants the acpidump?

Thanks for sending this!

> [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
> [0.00] ACPI: Error parsing LAPIC address override entry
> [0.00] ACPI: Invalid BIOS MADT, disabling ACPI
>
> Seems the MADT revision is not right, could you dump the ACPI MADT
> (APIC) table and send it out? I will take a look :)
>
> Thanks
> Hanjun

 Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.
>>>
>>> Thanks! I think I had the right guess, the MADT revision is not right
>>> for ACPI 4.0:
>>>
>>> [000h    4]Signature : "APIC"[Multiple APIC
>>> Description Table (MADT)]
>>> [004h 0004   4] Table Length : 00BC
>>> [008h 0008   1] *Revision : 01*
>>>
>>> I encountered such problem before because the table was just copied from
>>> previous version, and without the update for table revision.
>>>
>>> I think we may need to ignore the table revision for x86, but restrict
>>> it for ARM64, I'd like Al and Rafael's suggestion before I send out a
>>> patch.
>>>
>>
>> Instead of just removing the check completely on x86, IMO restrict it to
>> some newer/later version of ACPI so you can still force vendors to fix
>> their ACPI tables at-least in future.
> 
> No, we can't force vendors to fix their ACPI tables.  This is completely
> unrealistic.
> 
> We simly need to deal with the bugs in the ACPI tables in the kernel.

Unfortunately true.  I've had a couple of reports to look at and think
through apart from this; it's really quite fascinating how much stuff
a slightly stricter table check is turning up.  A little surprising,
too, but fascinating.  A fix is in progress, still needs some testing...

>> It would be good to get such sanity check in the tools used to build
>> those tables, but yes since such static tables can be built in many
>> ways, its difficult to deal it in all those tools.
> 
> As I said to Al, we need those checks in firmware test suites.  Having
> them in the kernel is OK too, but they should cause warnings to be printed
> to the kernel log instead of causing the kernel to panic.
> 
> Thanks,
> Rafael
> 

Yup.  Agreed.  For x86, we can't induce kernel panics.  Since arm64 is new to
the game, we'll be stricter since we can afford to be for now.

-- 
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Rafael J. Wysocki]

On Monday, October 12, 2015 03:04:30 PM Hanjun Guo wrote:
> On 10/12/2015 11:58 AM, Pat Erley wrote:
> > On 10/11/2015 08:49 PM, Hanjun Guo wrote:
> >> On 10/12/2015 11:08 AM, Pat Erley wrote:
> >>> On 10/05/2015 10:12 AM, Al Stone wrote:
>  On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
> > On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
> >> On 09/30/2015 03:00 AM, Hanjun Guo wrote:
> >>> On 2015/9/30 7:45, Al Stone wrote:
>  NB: this patch set is for use against the linux-pm bleeding edge
>  branch.
> 
> >>
> >> [snip...]
> >>
> >>>
> >>> For this patch set,
> >>>
> >>> Reviewed-by: Hanjun Guo 
> >>>
> >>> Thanks
> >>> Hanjun
> >>
> >> Thanks, Hanjun!
> >
> > Series applied, thanks!
> >
> > Rafael
> >
> 
>  Thanks, Rafael!
> 
> >>>
> >>> Just decided to test out linux-next (to see the new nouveau cleanups).
> >>> This change set prevents my Lenovo W510 from booting properly.
> >>>
> >>> Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
> >>> eventually replace the macro"
> >>>
> >>> Gets the system booting again.  I'm attaching my dmesg from the failed
> >>> boot, who wants the acpidump?
> >>
> >> [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
> >> [0.00] ACPI: Error parsing LAPIC address override entry
> >> [0.00] ACPI: Invalid BIOS MADT, disabling ACPI
> >>
> >> Seems the MADT revision is not right, could you dump the ACPI MADT
> >> (APIC) table and send it out? I will take a look :)
> >>
> >> Thanks
> >> Hanjun
> >
> > Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.
> 
> Thanks! I think I had the right guess, the MADT revision is not right
> for ACPI 4.0:
> 
> [000h    4]Signature : "APIC"[Multiple APIC 
> Description Table (MADT)]
> [004h 0004   4] Table Length : 00BC
> [008h 0008   1] *Revision : 01*
> 
> I encountered such problem before because the table was just copied from
> previous version, and without the update for table revision.
> 
> I think we may need to ignore the table revision for x86, but restrict
> it for ARM64, I'd like Al and Rafael's suggestion before I send out a
> patch.

As I said before to Al, we definitely can't break systems that worked before
the commit in question.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Rafael J. Wysocki]

On Monday, October 12, 2015 10:44:52 AM Sudeep Holla wrote:
> 
> On 12/10/15 08:04, Hanjun Guo wrote:
> > On 10/12/2015 11:58 AM, Pat Erley wrote:
> >> On 10/11/2015 08:49 PM, Hanjun Guo wrote:
> >>> On 10/12/2015 11:08 AM, Pat Erley wrote:
>  On 10/05/2015 10:12 AM, Al Stone wrote:
> > On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
> >> On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
> >>> On 09/30/2015 03:00 AM, Hanjun Guo wrote:
>  On 2015/9/30 7:45, Al Stone wrote:
> > NB: this patch set is for use against the linux-pm bleeding edge
> > branch.
> >
> >>>
> >>> [snip...]
> >>>
> 
>  For this patch set,
> 
>  Reviewed-by: Hanjun Guo 
> 
>  Thanks
>  Hanjun
> >>>
> >>> Thanks, Hanjun!
> >>
> >> Series applied, thanks!
> >>
> >> Rafael
> >>
> >
> > Thanks, Rafael!
> >
> 
>  Just decided to test out linux-next (to see the new nouveau cleanups).
>  This change set prevents my Lenovo W510 from booting properly.
> 
>  Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
>  eventually replace the macro"
> 
>  Gets the system booting again.  I'm attaching my dmesg from the failed
>  boot, who wants the acpidump?
> >>>
> >>> [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
> >>> [0.00] ACPI: Error parsing LAPIC address override entry
> >>> [0.00] ACPI: Invalid BIOS MADT, disabling ACPI
> >>>
> >>> Seems the MADT revision is not right, could you dump the ACPI MADT
> >>> (APIC) table and send it out? I will take a look :)
> >>>
> >>> Thanks
> >>> Hanjun
> >>
> >> Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.
> >
> > Thanks! I think I had the right guess, the MADT revision is not right
> > for ACPI 4.0:
> >
> > [000h    4]Signature : "APIC"[Multiple APIC
> > Description Table (MADT)]
> > [004h 0004   4] Table Length : 00BC
> > [008h 0008   1] *Revision : 01*
> >
> > I encountered such problem before because the table was just copied from
> > previous version, and without the update for table revision.
> >
> > I think we may need to ignore the table revision for x86, but restrict
> > it for ARM64, I'd like Al and Rafael's suggestion before I send out a
> > patch.
> >
> 
> Instead of just removing the check completely on x86, IMO restrict it to
> some newer/later version of ACPI so you can still force vendors to fix
> their ACPI tables at-least in future.

No, we can't force vendors to fix their ACPI tables.  This is completely
unrealistic.

We simly need to deal with the bugs in the ACPI tables in the kernel.

> It would be good to get such sanity check in the tools used to build
> those tables, but yes since such static tables can be built in many
> ways, its difficult to deal it in all those tools.

As I said to Al, we need those checks in firmware test suites.  Having
them in the kernel is OK too, but they should cause warnings to be printed
to the kernel log instead of causing the kernel to panic.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Hanjun Guo]

On 10/12/2015 05:44 PM, Sudeep Holla wrote:



On 12/10/15 08:04, Hanjun Guo wrote:

On 10/12/2015 11:58 AM, Pat Erley wrote:

On 10/11/2015 08:49 PM, Hanjun Guo wrote:

On 10/12/2015 11:08 AM, Pat Erley wrote:

On 10/05/2015 10:12 AM, Al Stone wrote:

On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:

On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:

On 09/30/2015 03:00 AM, Hanjun Guo wrote:

On 2015/9/30 7:45, Al Stone wrote:

NB: this patch set is for use against the linux-pm bleeding edge
branch.



[snip...]



For this patch set,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun


Thanks, Hanjun!


Series applied, thanks!

Rafael



Thanks, Rafael!



Just decided to test out linux-next (to see the new nouveau cleanups).
This change set prevents my Lenovo W510 from booting properly.

Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
eventually replace the macro"

Gets the system booting again.  I'm attaching my dmesg from the failed
boot, who wants the acpidump?


[0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI

Seems the MADT revision is not right, could you dump the ACPI MADT
(APIC) table and send it out? I will take a look :)

Thanks
Hanjun


Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.


Thanks! I think I had the right guess, the MADT revision is not right
for ACPI 4.0:

[000h    4]Signature : "APIC"[Multiple APIC
Description Table (MADT)]
[004h 0004   4] Table Length : 00BC
[008h 0008   1] *Revision : 01*

I encountered such problem before because the table was just copied from
previous version, and without the update for table revision.

I think we may need to ignore the table revision for x86, but restrict
it for ARM64, I'd like Al and Rafael's suggestion before I send out a
patch.



Instead of just removing the check completely on x86, IMO restrict it to
some newer/later version of ACPI so you can still force vendors to fix
their ACPI tables at-least in future.


I agree.



It would be good to get such sanity check in the tools used to build
those tables, but yes since such static tables can be built in many
ways, its difficult to deal it in all those tools.


At least we can check that in the FWTS. :)

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Sudeep Holla]

On 12/10/15 08:04, Hanjun Guo wrote:

On 10/12/2015 11:58 AM, Pat Erley wrote:

On 10/11/2015 08:49 PM, Hanjun Guo wrote:

On 10/12/2015 11:08 AM, Pat Erley wrote:

On 10/05/2015 10:12 AM, Al Stone wrote:

On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:

On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:

On 09/30/2015 03:00 AM, Hanjun Guo wrote:

On 2015/9/30 7:45, Al Stone wrote:

NB: this patch set is for use against the linux-pm bleeding edge
branch.



[snip...]



For this patch set,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun


Thanks, Hanjun!


Series applied, thanks!

Rafael



Thanks, Rafael!



Just decided to test out linux-next (to see the new nouveau cleanups).
This change set prevents my Lenovo W510 from booting properly.

Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
eventually replace the macro"

Gets the system booting again.  I'm attaching my dmesg from the failed
boot, who wants the acpidump?


[0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI

Seems the MADT revision is not right, could you dump the ACPI MADT
(APIC) table and send it out? I will take a look :)

Thanks
Hanjun


Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.


Thanks! I think I had the right guess, the MADT revision is not right
for ACPI 4.0:

[000h    4]Signature : "APIC"[Multiple APIC
Description Table (MADT)]
[004h 0004   4] Table Length : 00BC
[008h 0008   1] *Revision : 01*

I encountered such problem before because the table was just copied from
previous version, and without the update for table revision.

I think we may need to ignore the table revision for x86, but restrict
it for ARM64, I'd like Al and Rafael's suggestion before I send out a
patch.



Instead of just removing the check completely on x86, IMO restrict it to
some newer/later version of ACPI so you can still force vendors to fix
their ACPI tables at-least in future.

It would be good to get such sanity check in the tools used to build
those tables, but yes since such static tables can be built in many
ways, its difficult to deal it in all those tools.

--
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Hanjun Guo]

On 10/12/2015 11:58 AM, Pat Erley wrote:

On 10/11/2015 08:49 PM, Hanjun Guo wrote:

On 10/12/2015 11:08 AM, Pat Erley wrote:

On 10/05/2015 10:12 AM, Al Stone wrote:

On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:

On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:

On 09/30/2015 03:00 AM, Hanjun Guo wrote:

On 2015/9/30 7:45, Al Stone wrote:

NB: this patch set is for use against the linux-pm bleeding edge
branch.



[snip...]



For this patch set,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun


Thanks, Hanjun!


Series applied, thanks!

Rafael



Thanks, Rafael!



Just decided to test out linux-next (to see the new nouveau cleanups).
This change set prevents my Lenovo W510 from booting properly.

Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
eventually replace the macro"

Gets the system booting again.  I'm attaching my dmesg from the failed
boot, who wants the acpidump?


[0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI

Seems the MADT revision is not right, could you dump the ACPI MADT
(APIC) table and send it out? I will take a look :)

Thanks
Hanjun


Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.


Thanks! I think I had the right guess, the MADT revision is not right
for ACPI 4.0:

[000h    4]Signature : "APIC"[Multiple APIC 
Description Table (MADT)]

[004h 0004   4] Table Length : 00BC
[008h 0008   1] *Revision : 01*

I encountered such problem before because the table was just copied from
previous version, and without the update for table revision.

I think we may need to ignore the table revision for x86, but restrict
it for ARM64, I'd like Al and Rafael's suggestion before I send out a
patch.

Thanks
Hanjun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Hanjun Guo]

On 10/12/2015 11:58 AM, Pat Erley wrote:

On 10/11/2015 08:49 PM, Hanjun Guo wrote:

On 10/12/2015 11:08 AM, Pat Erley wrote:

On 10/05/2015 10:12 AM, Al Stone wrote:

On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:

On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:

On 09/30/2015 03:00 AM, Hanjun Guo wrote:

On 2015/9/30 7:45, Al Stone wrote:

NB: this patch set is for use against the linux-pm bleeding edge
branch.



[snip...]



For this patch set,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun


Thanks, Hanjun!


Series applied, thanks!

Rafael



Thanks, Rafael!



Just decided to test out linux-next (to see the new nouveau cleanups).
This change set prevents my Lenovo W510 from booting properly.

Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
eventually replace the macro"

Gets the system booting again.  I'm attaching my dmesg from the failed
boot, who wants the acpidump?


[0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI

Seems the MADT revision is not right, could you dump the ACPI MADT
(APIC) table and send it out? I will take a look :)

Thanks
Hanjun


Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.


Thanks! I think I had the right guess, the MADT revision is not right
for ACPI 4.0:

[000h    4]Signature : "APIC"[Multiple APIC 
Description Table (MADT)]

[004h 0004   4] Table Length : 00BC
[008h 0008   1] *Revision : 01*

I encountered such problem before because the table was just copied from
previous version, and without the update for table revision.

I think we may need to ignore the table revision for x86, but restrict
it for ARM64, I'd like Al and Rafael's suggestion before I send out a
patch.

Thanks
Hanjun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Sudeep Holla]

On 12/10/15 08:04, Hanjun Guo wrote:

On 10/12/2015 11:58 AM, Pat Erley wrote:

On 10/11/2015 08:49 PM, Hanjun Guo wrote:

On 10/12/2015 11:08 AM, Pat Erley wrote:

On 10/05/2015 10:12 AM, Al Stone wrote:

On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:

On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:

On 09/30/2015 03:00 AM, Hanjun Guo wrote:

On 2015/9/30 7:45, Al Stone wrote:

NB: this patch set is for use against the linux-pm bleeding edge
branch.



[snip...]



For this patch set,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun


Thanks, Hanjun!


Series applied, thanks!

Rafael



Thanks, Rafael!



Just decided to test out linux-next (to see the new nouveau cleanups).
This change set prevents my Lenovo W510 from booting properly.

Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
eventually replace the macro"

Gets the system booting again.  I'm attaching my dmesg from the failed
boot, who wants the acpidump?


[0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI

Seems the MADT revision is not right, could you dump the ACPI MADT
(APIC) table and send it out? I will take a look :)

Thanks
Hanjun


Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.


Thanks! I think I had the right guess, the MADT revision is not right
for ACPI 4.0:

[000h    4]Signature : "APIC"[Multiple APIC
Description Table (MADT)]
[004h 0004   4] Table Length : 00BC
[008h 0008   1] *Revision : 01*

I encountered such problem before because the table was just copied from
previous version, and without the update for table revision.

I think we may need to ignore the table revision for x86, but restrict
it for ARM64, I'd like Al and Rafael's suggestion before I send out a
patch.



Instead of just removing the check completely on x86, IMO restrict it to
some newer/later version of ACPI so you can still force vendors to fix
their ACPI tables at-least in future.

It would be good to get such sanity check in the tools used to build
those tables, but yes since such static tables can be built in many
ways, its difficult to deal it in all those tools.

--
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Hanjun Guo]

On 10/12/2015 05:44 PM, Sudeep Holla wrote:



On 12/10/15 08:04, Hanjun Guo wrote:

On 10/12/2015 11:58 AM, Pat Erley wrote:

On 10/11/2015 08:49 PM, Hanjun Guo wrote:

On 10/12/2015 11:08 AM, Pat Erley wrote:

On 10/05/2015 10:12 AM, Al Stone wrote:

On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:

On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:

On 09/30/2015 03:00 AM, Hanjun Guo wrote:

On 2015/9/30 7:45, Al Stone wrote:

NB: this patch set is for use against the linux-pm bleeding edge
branch.



[snip...]



For this patch set,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun


Thanks, Hanjun!


Series applied, thanks!

Rafael



Thanks, Rafael!



Just decided to test out linux-next (to see the new nouveau cleanups).
This change set prevents my Lenovo W510 from booting properly.

Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
eventually replace the macro"

Gets the system booting again.  I'm attaching my dmesg from the failed
boot, who wants the acpidump?


[0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI

Seems the MADT revision is not right, could you dump the ACPI MADT
(APIC) table and send it out? I will take a look :)

Thanks
Hanjun


Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.


Thanks! I think I had the right guess, the MADT revision is not right
for ACPI 4.0:

[000h    4]Signature : "APIC"[Multiple APIC
Description Table (MADT)]
[004h 0004   4] Table Length : 00BC
[008h 0008   1] *Revision : 01*

I encountered such problem before because the table was just copied from
previous version, and without the update for table revision.

I think we may need to ignore the table revision for x86, but restrict
it for ARM64, I'd like Al and Rafael's suggestion before I send out a
patch.



Instead of just removing the check completely on x86, IMO restrict it to
some newer/later version of ACPI so you can still force vendors to fix
their ACPI tables at-least in future.


I agree.



It would be good to get such sanity check in the tools used to build
those tables, but yes since such static tables can be built in many
ways, its difficult to deal it in all those tools.


At least we can check that in the FWTS. :)

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Rafael J. Wysocki]

On Monday, October 12, 2015 10:44:52 AM Sudeep Holla wrote:
> 
> On 12/10/15 08:04, Hanjun Guo wrote:
> > On 10/12/2015 11:58 AM, Pat Erley wrote:
> >> On 10/11/2015 08:49 PM, Hanjun Guo wrote:
> >>> On 10/12/2015 11:08 AM, Pat Erley wrote:
>  On 10/05/2015 10:12 AM, Al Stone wrote:
> > On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
> >> On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
> >>> On 09/30/2015 03:00 AM, Hanjun Guo wrote:
>  On 2015/9/30 7:45, Al Stone wrote:
> > NB: this patch set is for use against the linux-pm bleeding edge
> > branch.
> >
> >>>
> >>> [snip...]
> >>>
> 
>  For this patch set,
> 
>  Reviewed-by: Hanjun Guo 
> 
>  Thanks
>  Hanjun
> >>>
> >>> Thanks, Hanjun!
> >>
> >> Series applied, thanks!
> >>
> >> Rafael
> >>
> >
> > Thanks, Rafael!
> >
> 
>  Just decided to test out linux-next (to see the new nouveau cleanups).
>  This change set prevents my Lenovo W510 from booting properly.
> 
>  Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
>  eventually replace the macro"
> 
>  Gets the system booting again.  I'm attaching my dmesg from the failed
>  boot, who wants the acpidump?
> >>>
> >>> [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
> >>> [0.00] ACPI: Error parsing LAPIC address override entry
> >>> [0.00] ACPI: Invalid BIOS MADT, disabling ACPI
> >>>
> >>> Seems the MADT revision is not right, could you dump the ACPI MADT
> >>> (APIC) table and send it out? I will take a look :)
> >>>
> >>> Thanks
> >>> Hanjun
> >>
> >> Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.
> >
> > Thanks! I think I had the right guess, the MADT revision is not right
> > for ACPI 4.0:
> >
> > [000h    4]Signature : "APIC"[Multiple APIC
> > Description Table (MADT)]
> > [004h 0004   4] Table Length : 00BC
> > [008h 0008   1] *Revision : 01*
> >
> > I encountered such problem before because the table was just copied from
> > previous version, and without the update for table revision.
> >
> > I think we may need to ignore the table revision for x86, but restrict
> > it for ARM64, I'd like Al and Rafael's suggestion before I send out a
> > patch.
> >
> 
> Instead of just removing the check completely on x86, IMO restrict it to
> some newer/later version of ACPI so you can still force vendors to fix
> their ACPI tables at-least in future.

No, we can't force vendors to fix their ACPI tables.  This is completely
unrealistic.

We simly need to deal with the bugs in the ACPI tables in the kernel.

> It would be good to get such sanity check in the tools used to build
> those tables, but yes since such static tables can be built in many
> ways, its difficult to deal it in all those tools.

As I said to Al, we need those checks in firmware test suites.  Having
them in the kernel is OK too, but they should cause warnings to be printed
to the kernel log instead of causing the kernel to panic.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Al Stone]

On 10/12/2015 01:25 PM, Rafael J. Wysocki wrote:
> On Monday, October 12, 2015 10:44:52 AM Sudeep Holla wrote:
>>
>> On 12/10/15 08:04, Hanjun Guo wrote:
>>> On 10/12/2015 11:58 AM, Pat Erley wrote:
 On 10/11/2015 08:49 PM, Hanjun Guo wrote:
> On 10/12/2015 11:08 AM, Pat Erley wrote:
>> On 10/05/2015 10:12 AM, Al Stone wrote:
>>> On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
 On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
> On 09/30/2015 03:00 AM, Hanjun Guo wrote:
>> On 2015/9/30 7:45, Al Stone wrote:
>>> NB: this patch set is for use against the linux-pm bleeding edge
>>> branch.
>>>
>
> [snip...]
>
>>
>> For this patch set,
>>
>> Reviewed-by: Hanjun Guo 
>>
>> Thanks
>> Hanjun
>
> Thanks, Hanjun!

 Series applied, thanks!

 Rafael

>>>
>>> Thanks, Rafael!
>>>
>>
>> Just decided to test out linux-next (to see the new nouveau cleanups).
>> This change set prevents my Lenovo W510 from booting properly.
>>
>> Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
>> eventually replace the macro"
>>
>> Gets the system booting again.  I'm attaching my dmesg from the failed
>> boot, who wants the acpidump?

Thanks for sending this!

> [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
> [0.00] ACPI: Error parsing LAPIC address override entry
> [0.00] ACPI: Invalid BIOS MADT, disabling ACPI
>
> Seems the MADT revision is not right, could you dump the ACPI MADT
> (APIC) table and send it out? I will take a look :)
>
> Thanks
> Hanjun

 Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.
>>>
>>> Thanks! I think I had the right guess, the MADT revision is not right
>>> for ACPI 4.0:
>>>
>>> [000h    4]Signature : "APIC"[Multiple APIC
>>> Description Table (MADT)]
>>> [004h 0004   4] Table Length : 00BC
>>> [008h 0008   1] *Revision : 01*
>>>
>>> I encountered such problem before because the table was just copied from
>>> previous version, and without the update for table revision.
>>>
>>> I think we may need to ignore the table revision for x86, but restrict
>>> it for ARM64, I'd like Al and Rafael's suggestion before I send out a
>>> patch.
>>>
>>
>> Instead of just removing the check completely on x86, IMO restrict it to
>> some newer/later version of ACPI so you can still force vendors to fix
>> their ACPI tables at-least in future.
> 
> No, we can't force vendors to fix their ACPI tables.  This is completely
> unrealistic.
> 
> We simly need to deal with the bugs in the ACPI tables in the kernel.

Unfortunately true.  I've had a couple of reports to look at and think
through apart from this; it's really quite fascinating how much stuff
a slightly stricter table check is turning up.  A little surprising,
too, but fascinating.  A fix is in progress, still needs some testing...

>> It would be good to get such sanity check in the tools used to build
>> those tables, but yes since such static tables can be built in many
>> ways, its difficult to deal it in all those tools.
> 
> As I said to Al, we need those checks in firmware test suites.  Having
> them in the kernel is OK too, but they should cause warnings to be printed
> to the kernel log instead of causing the kernel to panic.
> 
> Thanks,
> Rafael
> 

Yup.  Agreed.  For x86, we can't induce kernel panics.  Since arm64 is new to
the game, we'll be stricter since we can afford to be for now.

-- 
ciao,
al
---
Al Stone
Software Engineer
Red Hat, Inc.
a...@redhat.com
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Rafael J. Wysocki]

On Monday, October 12, 2015 03:04:30 PM Hanjun Guo wrote:
> On 10/12/2015 11:58 AM, Pat Erley wrote:
> > On 10/11/2015 08:49 PM, Hanjun Guo wrote:
> >> On 10/12/2015 11:08 AM, Pat Erley wrote:
> >>> On 10/05/2015 10:12 AM, Al Stone wrote:
>  On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
> > On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
> >> On 09/30/2015 03:00 AM, Hanjun Guo wrote:
> >>> On 2015/9/30 7:45, Al Stone wrote:
>  NB: this patch set is for use against the linux-pm bleeding edge
>  branch.
> 
> >>
> >> [snip...]
> >>
> >>>
> >>> For this patch set,
> >>>
> >>> Reviewed-by: Hanjun Guo 
> >>>
> >>> Thanks
> >>> Hanjun
> >>
> >> Thanks, Hanjun!
> >
> > Series applied, thanks!
> >
> > Rafael
> >
> 
>  Thanks, Rafael!
> 
> >>>
> >>> Just decided to test out linux-next (to see the new nouveau cleanups).
> >>> This change set prevents my Lenovo W510 from booting properly.
> >>>
> >>> Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
> >>> eventually replace the macro"
> >>>
> >>> Gets the system booting again.  I'm attaching my dmesg from the failed
> >>> boot, who wants the acpidump?
> >>
> >> [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
> >> [0.00] ACPI: Error parsing LAPIC address override entry
> >> [0.00] ACPI: Invalid BIOS MADT, disabling ACPI
> >>
> >> Seems the MADT revision is not right, could you dump the ACPI MADT
> >> (APIC) table and send it out? I will take a look :)
> >>
> >> Thanks
> >> Hanjun
> >
> > Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.
> 
> Thanks! I think I had the right guess, the MADT revision is not right
> for ACPI 4.0:
> 
> [000h    4]Signature : "APIC"[Multiple APIC 
> Description Table (MADT)]
> [004h 0004   4] Table Length : 00BC
> [008h 0008   1] *Revision : 01*
> 
> I encountered such problem before because the table was just copied from
> previous version, and without the update for table revision.
> 
> I think we may need to ignore the table revision for x86, but restrict
> it for ARM64, I'd like Al and Rafael's suggestion before I send out a
> patch.

As I said before to Al, we definitely can't break systems that worked before
the commit in question.

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Al Stone]

On 10/11/2015 09:58 PM, Pat Erley wrote:
> On 10/11/2015 08:49 PM, Hanjun Guo wrote:
>> On 10/12/2015 11:08 AM, Pat Erley wrote:
>>> On 10/05/2015 10:12 AM, Al Stone wrote:
 On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
> On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:
>> On 09/30/2015 03:00 AM, Hanjun Guo wrote:
>>> On 2015/9/30 7:45, Al Stone wrote:
 NB: this patch set is for use against the linux-pm bleeding edge
 branch.

>>
>> [snip...]
>>
>>>
>>> For this patch set,
>>>
>>> Reviewed-by: Hanjun Guo 
>>>
>>> Thanks
>>> Hanjun
>>
>> Thanks, Hanjun!
>
> Series applied, thanks!
>
> Rafael
>

 Thanks, Rafael!

>>>
>>> Just decided to test out linux-next (to see the new nouveau cleanups).
>>> This change set prevents my Lenovo W510 from booting properly.
>>>
>>> Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
>>> eventually replace the macro"
>>>
>>> Gets the system booting again.  I'm attaching my dmesg from the failed
>>> boot, who wants the acpidump?
>>
>> [0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
>> [0.00] ACPI: Error parsing LAPIC address override entry
>> [0.00] ACPI: Invalid BIOS MADT, disabling ACPI
>>
>> Seems the MADT revision is not right, could you dump the ACPI MADT
>> (APIC) table and send it out? I will take a look :)
>>
>> Thanks
>> Hanjun
> 
> Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.

Pat,

Would you mind sending a copy of the FADT, also, please?  The first of the
ACPI messages is a check of version correspondence between the FADT and MADT,
while the second message is from looking at just an MADT subtable.  Thanks
for sending the MADT out -- that helps me quite a lot in thinking this through.

BTW, whoever is providing the BIOS (Lenovo, I assume) may want to have a look
at these, also:

[0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in
FADT/Pm1aControlBlock: 16/32 (20150818/tbfadt-623)
[0.00] ACPI BIOS Warning (bug): Invalid length for
FADT/Pm1aControlBlock: 32, using default 16 (20150818/tbfadt-704)

Not inherently dangerous, but definitely sloppy and mind-numbingly easy to
avoid, IIRC.

-- 
ciao,
al
---
Al Stone
Software Engineer
Linaro Enterprise Group
al.st...@linaro.org
---
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Hanjun Guo]

On 10/13/2015 03:21 AM, Rafael J. Wysocki wrote:

On Monday, October 12, 2015 03:04:30 PM Hanjun Guo wrote:

On 10/12/2015 11:58 AM, Pat Erley wrote:

On 10/11/2015 08:49 PM, Hanjun Guo wrote:

On 10/12/2015 11:08 AM, Pat Erley wrote:

On 10/05/2015 10:12 AM, Al Stone wrote:

On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:

On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:

On 09/30/2015 03:00 AM, Hanjun Guo wrote:

On 2015/9/30 7:45, Al Stone wrote:

NB: this patch set is for use against the linux-pm bleeding edge
branch.



[snip...]



For this patch set,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun


Thanks, Hanjun!


Series applied, thanks!

Rafael



Thanks, Rafael!



Just decided to test out linux-next (to see the new nouveau cleanups).
This change set prevents my Lenovo W510 from booting properly.

Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
eventually replace the macro"

Gets the system booting again.  I'm attaching my dmesg from the failed
boot, who wants the acpidump?


[0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI

Seems the MADT revision is not right, could you dump the ACPI MADT
(APIC) table and send it out? I will take a look :)

Thanks
Hanjun


Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.


Thanks! I think I had the right guess, the MADT revision is not right
for ACPI 4.0:

[000h    4]Signature : "APIC"[Multiple APIC
Description Table (MADT)]
[004h 0004   4] Table Length : 00BC
[008h 0008   1] *Revision : 01*

I encountered such problem before because the table was just copied from
previous version, and without the update for table revision.

I think we may need to ignore the table revision for x86, but restrict
it for ARM64, I'd like Al and Rafael's suggestion before I send out a
patch.


As I said before to Al, we definitely can't break systems that worked before
the commit in question.


Sure :)

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Pat Erley]

On 10/12/2015 01:52 PM, Al Stone wrote:

On 10/11/2015 09:58 PM, Pat Erley wrote:

On 10/11/2015 08:49 PM, Hanjun Guo wrote:

On 10/12/2015 11:08 AM, Pat Erley wrote:

On 10/05/2015 10:12 AM, Al Stone wrote:

On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:

On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:

On 09/30/2015 03:00 AM, Hanjun Guo wrote:

On 2015/9/30 7:45, Al Stone wrote:

NB: this patch set is for use against the linux-pm bleeding edge
branch.



[snip...]



For this patch set,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun


Thanks, Hanjun!


Series applied, thanks!

Rafael



Thanks, Rafael!



Just decided to test out linux-next (to see the new nouveau cleanups).
This change set prevents my Lenovo W510 from booting properly.

Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
eventually replace the macro"

Gets the system booting again.  I'm attaching my dmesg from the failed
boot, who wants the acpidump?


[0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI

Seems the MADT revision is not right, could you dump the ACPI MADT
(APIC) table and send it out? I will take a look :)

Thanks
Hanjun


Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.


Pat,

Would you mind sending a copy of the FADT, also, please?  The first of the
ACPI messages is a check of version correspondence between the FADT and MADT,
while the second message is from looking at just an MADT subtable.  Thanks
for sending the MADT out -- that helps me quite a lot in thinking this through.

BTW, whoever is providing the BIOS (Lenovo, I assume) may want to have a look
at these, also:

[0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in
FADT/Pm1aControlBlock: 16/32 (20150818/tbfadt-623)
[0.00] ACPI BIOS Warning (bug): Invalid length for
FADT/Pm1aControlBlock: 32, using default 16 (20150818/tbfadt-704)

Not inherently dangerous, but definitely sloppy and mind-numbingly easy to
avoid, IIRC.



Here ya go.
/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20150717-64
 * Copyright (c) 2000 - 2015 Intel Corporation
 * 
 * Disassembly of facp.dat, Mon Oct 12 21:06:03 2015
 *
 * ACPI Data Table [FACP]
 *
 * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
 */

[000h    4]Signature : "FACP"[Fixed ACPI Description Table (FADT)]
[004h 0004   4] Table Length : 00F4
[008h 0008   1] Revision : 04
[009h 0009   1] Checksum : 59
[00Ah 0010   6]   Oem ID : "LENOVO"
[010h 0016   8] Oem Table ID : "TP-6N   "
[018h 0024   4] Oem Revision : 1450
[01Ch 0028   4]  Asl Compiler ID : "LNVO"
[020h 0032   4]Asl Compiler Revision : 0001

[024h 0036   4] FACS Address : BBEE7000
[028h 0040   4] DSDT Address : BBFF1C9B
[02Ch 0044   1]Model : 00
[02Dh 0045   1]   PM Profile : 02 [Mobile]
[02Eh 0046   2]SCI Interrupt : 0009
[030h 0048   4] SMI Command Port : 00B2
[034h 0052   1]ACPI Enable Value : F0
[035h 0053   1]   ACPI Disable Value : F1
[036h 0054   1]   S4BIOS Command : 00
[037h 0055   1]  P-State Control : 80
[038h 0056   4] PM1A Event Block Address : 1000
[03Ch 0060   4] PM1B Event Block Address : 
[040h 0064   4]   PM1A Control Block Address : 1004
[044h 0068   4]   PM1B Control Block Address : 
[048h 0072   4]PM2 Control Block Address : 1050
[04Ch 0076   4]   PM Timer Block Address : 1008
[050h 0080   4]   GPE0 Block Address : 1020
[054h 0084   4]   GPE1 Block Address : 
[058h 0088   1]   PM1 Event Block Length : 04
[059h 0089   1] PM1 Control Block Length : 02
[05Ah 0090   1] PM2 Control Block Length : 01
[05Bh 0091   1]PM Timer Block Length : 04
[05Ch 0092   1]GPE0 Block Length : 10
[05Dh 0093   1]GPE1 Block Length : 00
[05Eh 0094   1] GPE1 Base Offset : 00
[05Fh 0095   1] _CST Support : 85
[060h 0096   2]   C2 Latency : 0001
[062h 0098   2]   C3 Latency : 0039
[064h 0100   2]   CPU Cache Size : 
[066h 0102   2]   Cache Flush Stride : 
[068h 0104   1]Duty Cycle Offset : 01
[069h 0105   1] Duty Cycle Width : 03
[06Ah 0106   1]  RTC Day Alarm Index : 0D
[06Bh 0107   1]RTC Month Alarm Index : 00
[06Ch 0108   1]RTC Century Index : 32
[06Dh 0109   2]   Boot Flags (decoded below) : 0012
   Legacy Devices Supported (V2) : 0
8042 Present on ports 60/64 (V2) : 1
VGA Not Present (V4) : 

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Pat Erley]

On 10/11/2015 08:49 PM, Hanjun Guo wrote:

On 10/12/2015 11:08 AM, Pat Erley wrote:

On 10/05/2015 10:12 AM, Al Stone wrote:

On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:

On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:

On 09/30/2015 03:00 AM, Hanjun Guo wrote:

On 2015/9/30 7:45, Al Stone wrote:

NB: this patch set is for use against the linux-pm bleeding edge
branch.



[snip...]



For this patch set,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun


Thanks, Hanjun!


Series applied, thanks!

Rafael



Thanks, Rafael!



Just decided to test out linux-next (to see the new nouveau cleanups).
This change set prevents my Lenovo W510 from booting properly.

Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
eventually replace the macro"

Gets the system booting again.  I'm attaching my dmesg from the failed
boot, who wants the acpidump?


[0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI

Seems the MADT revision is not right, could you dump the ACPI MADT
(APIC) table and send it out? I will take a look :)

Thanks
Hanjun


Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.


apic.dat
Description: Netscape Proxy Auto Config
/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20150717-64
 * Copyright (c) 2000 - 2015 Intel Corporation
 * 
 * Disassembly of apic.dat, Sun Oct 11 20:55:40 2015
 *
 * ACPI Data Table [APIC]
 *
 * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
 */

[000h    4]Signature : "APIC"[Multiple APIC Description Table (MADT)]
[004h 0004   4] Table Length : 00BC
[008h 0008   1] Revision : 01
[009h 0009   1] Checksum : FA
[00Ah 0010   6]   Oem ID : "LENOVO"
[010h 0016   8] Oem Table ID : "TP-6N   "
[018h 0024   4] Oem Revision : 1450
[01Ch 0028   4]  Asl Compiler ID : "LNVO"
[020h 0032   4]Asl Compiler Revision : 0001

[024h 0036   4]   Local Apic Address : FEE0
[028h 0040   4]Flags (decoded below) : 0001
 PC-AT Compatibility : 1

[02Ch 0044   1]Subtable Type : 00 [Processor Local APIC]
[02Dh 0045   1]   Length : 08
[02Eh 0046   1] Processor ID : 00
[02Fh 0047   1]Local Apic ID : 00
[030h 0048   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[034h 0052   1]Subtable Type : 00 [Processor Local APIC]
[035h 0053   1]   Length : 08
[036h 0054   1] Processor ID : 01
[037h 0055   1]Local Apic ID : 01
[038h 0056   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[03Ch 0060   1]Subtable Type : 00 [Processor Local APIC]
[03Dh 0061   1]   Length : 08
[03Eh 0062   1] Processor ID : 02
[03Fh 0063   1]Local Apic ID : 02
[040h 0064   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[044h 0068   1]Subtable Type : 00 [Processor Local APIC]
[045h 0069   1]   Length : 08
[046h 0070   1] Processor ID : 03
[047h 0071   1]Local Apic ID : 03
[048h 0072   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[04Ch 0076   1]Subtable Type : 00 [Processor Local APIC]
[04Dh 0077   1]   Length : 08
[04Eh 0078   1] Processor ID : 04
[04Fh 0079   1]Local Apic ID : 04
[050h 0080   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[054h 0084   1]Subtable Type : 00 [Processor Local APIC]
[055h 0085   1]   Length : 08
[056h 0086   1] Processor ID : 05
[057h 0087   1]Local Apic ID : 05
[058h 0088   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[05Ch 0092   1]Subtable Type : 00 [Processor Local APIC]
[05Dh 0093   1]   Length : 08
[05Eh 0094   1] Processor ID : 06
[05Fh 0095   1]Local Apic ID : 06
[060h 0096   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[064h 0100   1]Subtable Type : 00 [Processor Local APIC]
[065h 0101   1]   Length : 08
[066h 0102   1] Processor ID : 07
[067h 0103   1]Local Apic ID : 07
[068h 0104   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[06Ch 0108   1]Subtable Type : 

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Hanjun Guo]

On 10/12/2015 11:08 AM, Pat Erley wrote:

On 10/05/2015 10:12 AM, Al Stone wrote:

On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:

On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:

On 09/30/2015 03:00 AM, Hanjun Guo wrote:

On 2015/9/30 7:45, Al Stone wrote:

NB: this patch set is for use against the linux-pm bleeding edge
branch.



[snip...]



For this patch set,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun


Thanks, Hanjun!


Series applied, thanks!

Rafael



Thanks, Rafael!



Just decided to test out linux-next (to see the new nouveau cleanups).
This change set prevents my Lenovo W510 from booting properly.

Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
eventually replace the macro"

Gets the system booting again.  I'm attaching my dmesg from the failed
boot, who wants the acpidump?


[0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI

Seems the MADT revision is not right, could you dump the ACPI MADT
(APIC) table and send it out? I will take a look :)

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Pat Erley]

On 10/11/2015 08:49 PM, Hanjun Guo wrote:

On 10/12/2015 11:08 AM, Pat Erley wrote:

On 10/05/2015 10:12 AM, Al Stone wrote:

On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:

On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:

On 09/30/2015 03:00 AM, Hanjun Guo wrote:

On 2015/9/30 7:45, Al Stone wrote:

NB: this patch set is for use against the linux-pm bleeding edge
branch.



[snip...]



For this patch set,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun


Thanks, Hanjun!


Series applied, thanks!

Rafael



Thanks, Rafael!



Just decided to test out linux-next (to see the new nouveau cleanups).
This change set prevents my Lenovo W510 from booting properly.

Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
eventually replace the macro"

Gets the system booting again.  I'm attaching my dmesg from the failed
boot, who wants the acpidump?


[0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI

Seems the MADT revision is not right, could you dump the ACPI MADT
(APIC) table and send it out? I will take a look :)

Thanks
Hanjun


Here ya go, enjoy.  Feel free to CC me on any patches that might fix it.


apic.dat
Description: Netscape Proxy Auto Config
/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20150717-64
 * Copyright (c) 2000 - 2015 Intel Corporation
 * 
 * Disassembly of apic.dat, Sun Oct 11 20:55:40 2015
 *
 * ACPI Data Table [APIC]
 *
 * Format: [HexOffset DecimalOffset ByteLength]  FieldName : FieldValue
 */

[000h    4]Signature : "APIC"[Multiple APIC Description Table (MADT)]
[004h 0004   4] Table Length : 00BC
[008h 0008   1] Revision : 01
[009h 0009   1] Checksum : FA
[00Ah 0010   6]   Oem ID : "LENOVO"
[010h 0016   8] Oem Table ID : "TP-6N   "
[018h 0024   4] Oem Revision : 1450
[01Ch 0028   4]  Asl Compiler ID : "LNVO"
[020h 0032   4]Asl Compiler Revision : 0001

[024h 0036   4]   Local Apic Address : FEE0
[028h 0040   4]Flags (decoded below) : 0001
 PC-AT Compatibility : 1

[02Ch 0044   1]Subtable Type : 00 [Processor Local APIC]
[02Dh 0045   1]   Length : 08
[02Eh 0046   1] Processor ID : 00
[02Fh 0047   1]Local Apic ID : 00
[030h 0048   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[034h 0052   1]Subtable Type : 00 [Processor Local APIC]
[035h 0053   1]   Length : 08
[036h 0054   1] Processor ID : 01
[037h 0055   1]Local Apic ID : 01
[038h 0056   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[03Ch 0060   1]Subtable Type : 00 [Processor Local APIC]
[03Dh 0061   1]   Length : 08
[03Eh 0062   1] Processor ID : 02
[03Fh 0063   1]Local Apic ID : 02
[040h 0064   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[044h 0068   1]Subtable Type : 00 [Processor Local APIC]
[045h 0069   1]   Length : 08
[046h 0070   1] Processor ID : 03
[047h 0071   1]Local Apic ID : 03
[048h 0072   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[04Ch 0076   1]Subtable Type : 00 [Processor Local APIC]
[04Dh 0077   1]   Length : 08
[04Eh 0078   1] Processor ID : 04
[04Fh 0079   1]Local Apic ID : 04
[050h 0080   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[054h 0084   1]Subtable Type : 00 [Processor Local APIC]
[055h 0085   1]   Length : 08
[056h 0086   1] Processor ID : 05
[057h 0087   1]Local Apic ID : 05
[058h 0088   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[05Ch 0092   1]Subtable Type : 00 [Processor Local APIC]
[05Dh 0093   1]   Length : 08
[05Eh 0094   1] Processor ID : 06
[05Fh 0095   1]Local Apic ID : 06
[060h 0096   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[064h 0100   1]Subtable Type : 00 [Processor Local APIC]
[065h 0101   1]   Length : 08
[066h 0102   1] Processor ID : 07
[067h 0103   1]Local Apic ID : 07
[068h 0104   4]Flags (decoded below) : 0001
   Processor Enabled : 1

[06Ch 0108   1]   

Re: [Linaro-acpi] [PATCH v5 0/5] Provide better MADT subtable sanity checks

[Hanjun Guo]

On 10/12/2015 11:08 AM, Pat Erley wrote:

On 10/05/2015 10:12 AM, Al Stone wrote:

On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:

On Wednesday, September 30, 2015 10:10:16 AM Al Stone wrote:

On 09/30/2015 03:00 AM, Hanjun Guo wrote:

On 2015/9/30 7:45, Al Stone wrote:

NB: this patch set is for use against the linux-pm bleeding edge
branch.



[snip...]



For this patch set,

Reviewed-by: Hanjun Guo 

Thanks
Hanjun


Thanks, Hanjun!


Series applied, thanks!

Rafael



Thanks, Rafael!



Just decided to test out linux-next (to see the new nouveau cleanups).
This change set prevents my Lenovo W510 from booting properly.

Reverting: 7494b0 "ACPI: add in a bad_madt_entry() function to
eventually replace the macro"

Gets the system booting again.  I'm attaching my dmesg from the failed
boot, who wants the acpidump?


[0.00] ACPI: undefined version for either FADT 4.0 or MADT 1
[0.00] ACPI: Error parsing LAPIC address override entry
[0.00] ACPI: Invalid BIOS MADT, disabling ACPI

Seems the MADT revision is not right, could you dump the ACPI MADT
(APIC) table and send it out? I will take a look :)

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/