During suspend to ram I have this message:
ACPI Warning (nspredef-0852): \_WAK: Return type mismatch - found
Integer, expected Package [20080926]
s2ram seems works OK
dmesg, acpidump:
http://unixy.pl/maciek/download/kernel/2.6.28-rc1_wak/
--
Maciej Rutecki
http://www.maciek.unixy.pl
On Saturday, 25 of October 2008, Maciej Rutecki wrote:
> During suspend to ram I have this message:
>
> ACPI Warning (nspredef-0852): \_WAK: Return type mismatch - found
> Integer, expected Package [20080926]
>
> s2ram seems works OK
>
> dmesg, acpidump:
> http://unixy.pl/maciek/download/kernel/2.6.28-rc1_wak/
IMO it's yet another incarnation of
http://bugzilla.kernel.org/show_bug.cgi?id=11822
Thanks,
Rafael
On Sat, 25 Oct 2008, Rafael J. Wysocki wrote:
> On Saturday, 25 of October 2008, Maciej Rutecki wrote:
> > During suspend to ram I have this message:
> >
> > ACPI Warning (nspredef-0852): \_WAK: Return type mismatch - found
> > Integer, expected Package [20080926]
> >
> > s2ram seems works OK
> >
> > dmesg, acpidump:
> > http://unixy.pl/maciek/download/kernel/2.6.28-rc1_wak/
>
> IMO it's yet another incarnation of
> http://bugzilla.kernel.org/show_bug.cgi?id=11822
If this is an outright violation of the ACPI spec, let me know (and if
possible, please tell me the spec page). This is the kind of thing I expect
it would be a no-brainer to get Lenovo to fix with a BIOS update.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Henrique de Moraes Holschuh wrote:
> On Sat, 25 Oct 2008, Rafael J. Wysocki wrote:
>> On Saturday, 25 of October 2008, Maciej Rutecki wrote:
>>> During suspend to ram I have this message:
>>>
>>> ACPI Warning (nspredef-0852): \_WAK: Return type mismatch - found
>>> Integer, expected Package [20080926]
>>>
>>> s2ram seems works OK
>>>
>>> dmesg, acpidump:
>>> http://unixy.pl/maciek/download/kernel/2.6.28-rc1_wak/
>> IMO it's yet another incarnation of
>> http://bugzilla.kernel.org/show_bug.cgi?id=11822
>
> If this is an outright violation of the ACPI spec, let me know (and if
> possible, please tell me the spec page). This is the kind of thing I expect
> it would be a no-brainer to get Lenovo to fix with a BIOS update.
I don't think this is the same issue, but in both cases it looks like
the BIOS AML code is wrong (just judging from the output, haven't looked
at the dump yet). _WAK is supposed to return a package of 2 DWORD
values, a bit field of conditions that occurred during sleep, and the
effective S-state the system actually entered (section 7.3.7 of the ACPI
3.0 spec). Presumably the BIOS is returning a single integer.
On Saturday, 25 of October 2008, Robert Hancock wrote:
> Henrique de Moraes Holschuh wrote:
> > On Sat, 25 Oct 2008, Rafael J. Wysocki wrote:
> >> On Saturday, 25 of October 2008, Maciej Rutecki wrote:
> >>> During suspend to ram I have this message:
> >>>
> >>> ACPI Warning (nspredef-0852): \_WAK: Return type mismatch - found
> >>> Integer, expected Package [20080926]
> >>>
> >>> s2ram seems works OK
> >>>
> >>> dmesg, acpidump:
> >>> http://unixy.pl/maciek/download/kernel/2.6.28-rc1_wak/
> >> IMO it's yet another incarnation of
> >> http://bugzilla.kernel.org/show_bug.cgi?id=11822
> >
> > If this is an outright violation of the ACPI spec, let me know (and if
> > possible, please tell me the spec page). This is the kind of thing I expect
> > it would be a no-brainer to get Lenovo to fix with a BIOS update.
>
> I don't think this is the same issue, but in both cases it looks like
> the BIOS AML code is wrong (just judging from the output, haven't looked
> at the dump yet). _WAK is supposed to return a package of 2 DWORD
> values, a bit field of conditions that occurred during sleep, and the
> effective S-state the system actually entered (section 7.3.7 of the ACPI
> 3.0 spec). Presumably the BIOS is returning a single integer.
The underlying issue is we've never reported such BIOS bugs before and now we
do that unconditionally. IMnshO, this should only be done if ACPI debugging is
enabled.
While I can see a value in doing that always, IMO such a change should only be
made after a big announcement.
Thanks,
Rafael
Suspend to ram, but another machine (previous PC, now laptop) and
another problem:
ACPI: EC: missing confirmations, switch off interrupt mode.
ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for
[EmbeddedControl] [20080926]
ACPI Error (psparse-0524): Method parse/execution failed [\_TZ_.C31E]
(Node f7019858), AE_TIME
ACPI Error (psparse-0524): Method parse/execution failed
[\_TZ_.TZ3_._TMP] (Node f7019ed0), AE_TIME
It doesn't happened immediately after s2ram but is correlation between
s2ram and this error.
Thermal zone seems OK (fan works)
Dmesg, acpidump:
http://unixy.pl/maciek/download/kernel/2.6.28-rc1_tz/
Regards
--
Maciej Rutecki
http://www.maciek.unixy.pl
2008/10/25 Maciej Rutecki <[email protected]>:
> Suspend to ram, but another machine (previous PC, now laptop) and
> another problem:
>
> ACPI: EC: missing confirmations, switch off interrupt mode.
> ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for
> [EmbeddedControl] [20080926]
> ACPI Error (psparse-0524): Method parse/execution failed [\_TZ_.C31E]
> (Node f7019858), AE_TIME
> ACPI Error (psparse-0524): Method parse/execution failed
> [\_TZ_.TZ3_._TMP] (Node f7019ed0), AE_TIME
>
> It doesn't happened immediately after s2ram but is correlation between
> s2ram and this error.
I was wrong; it happens not only after suspend to ram but sometimes
after normal boot.
--
Maciej Rutecki
http://www.maciek.unixy.pl
On Mon, 2008-10-27 at 13:19 -0700, Maciej Rutecki wrote:
> 2008/10/25 Maciej Rutecki <[email protected]>:
> > Suspend to ram, but another machine (previous PC, now laptop) and
> > another problem:
> >
> > ACPI: EC: missing confirmations, switch off interrupt mode.
> > ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for
> > [EmbeddedControl] [20080926]
> > ACPI Error (psparse-0524): Method parse/execution failed [\_TZ_.C31E]
> > (Node f7019858), AE_TIME
> > ACPI Error (psparse-0524): Method parse/execution failed
> > [\_TZ_.TZ3_._TMP] (Node f7019ed0), AE_TIME
> >
> > It doesn't happened immediately after s2ram but is correlation between
> > s2ram and this error.
Will you please confirm whether the following issue exists on the
previous kernel? For example: 2.6.27-rc6 or 2.6.27.2
> ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for
> [EmbeddedControl] [20080926]
> ACPI Error (psparse-0524): Method parse/execution failed [\_TZ_.C31E]
> (Node f7019858), AE_TIME
> ACPI Error (psparse-0524): Method parse/execution failed
> [\_TZ_.TZ3_._TMP] (Node f7019ed0), AE_TIME
If there is no such problem on the early kernel, maybe it is a
regression.
Thanks.
> I was wrong; it happens not only after suspend to ram but sometimes
> after normal boot.
>
>
On Mon, 2008-10-27 at 13:19 -0700, Maciej Rutecki wrote:
> 2008/10/25 Maciej Rutecki <[email protected]>:
> > Suspend to ram, but another machine (previous PC, now laptop) and
> > another problem:
> >
> > ACPI: EC: missing confirmations, switch off interrupt mode.
> > ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for
> > [EmbeddedControl] [20080926]
> > ACPI Error (psparse-0524): Method parse/execution failed [\_TZ_.C31E]
> > (Node f7019858), AE_TIME
> > ACPI Error (psparse-0524): Method parse/execution failed
> > [\_TZ_.TZ3_._TMP] (Node f7019ed0), AE_TIME
Will you please try the attached patch on the latest kernel(2.6.28-rc1)
and see whether the issue still exists?
After the test, please attach the output of dmesg.
Thanks.
> >
> > It doesn't happened immediately after s2ram but is correlation between
> > s2ram and this error.
>
> I was wrong; it happens not only after suspend to ram but sometimes
> after normal boot.
>
>
2008/10/28 Zhao Yakui <[email protected]>:
> Will you please try the attached patch on the latest kernel(2.6.28-rc1)
> and see whether the issue still exists?
>
> After the test, please attach the output of dmesg.
> Thanks.
It seems that patch solves problem. Dmesg:
http://unixy.pl/maciek/download/kernel/2.6.28-rc1_tz/dmesg_2.6.28-rc1_ec.txt
On 2.6.27-rcx and 2.6.27 this error never happen.
--
Maciej Rutecki
http://www.maciek.unixy.pl
Problem still exists on 2.6.28-rc3:
ACPI: EC: missing confirmations, switch off interrupt mode.
ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for
[EmbeddedControl] [20080926]
ACPI Error (psparse-0524): Method parse/execution failed [\_TZ_.C31E]
(Node f7019858), AE_TIME
ACPI Error (psparse-0524): Method parse/execution failed
[\_TZ_.TZ3_._TMP] (Node f7019ed0), AE_TIME
But I don't see any functional problems.
Regards
--
Maciej Rutecki
http://www.maciek.unixy.pl
Maciej Rutecki wrote:
> Problem still exists on 2.6.28-rc3:
> ACPI: EC: missing confirmations, switch off interrupt mode.
> ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for
> [EmbeddedControl] [20080926]
> ACPI Error (psparse-0524): Method parse/execution failed [\_TZ_.C31E]
> (Node f7019858), AE_TIME
> ACPI Error (psparse-0524): Method parse/execution failed
> [\_TZ_.TZ3_._TMP] (Node f7019ed0), AE_TIME
>
> But I don't see any functional problems.
>
> Regards
>
please see #11917
Alexey Starikovskiy wrote:
> Maciej Rutecki wrote:
>> Problem still exists on 2.6.28-rc3:
>> ACPI: EC: missing confirmations, switch off interrupt mode.
>> ACPI Exception (evregion-0419): AE_TIME, Returned by Handler for
>> [EmbeddedControl] [20080926]
>> ACPI Error (psparse-0524): Method parse/execution failed [\_TZ_.C31E]
>> (Node f7019858), AE_TIME
>> ACPI Error (psparse-0524): Method parse/execution failed
>> [\_TZ_.TZ3_._TMP] (Node f7019ed0), AE_TIME
>>
>> But I don't see any functional problems.
>>
>> Regards
>>
> please see #11917
Um, I think you mean #11896. I confess I don't understand why they are considered duplicates of each other, they have different error messages and patches.
Maciej: if you look at #11896, you will find patches from two different people. If you're interested... well, let's just say I suggest you try Alex's patch first :).
Alan
2008/11/3 Alexey Starikovskiy <[email protected]>:
>
> please see #11917
>
Patch from comment #3 doesn't help. I will try patches from #11896 very soon.
--
Maciej Rutecki
http://www.maciek.unixy.pl
2008/11/3 Maciej Rutecki <[email protected]>:
> Patch from comment #3 doesn't help. I will try patches from #11896 very soon.
>
Booth patches (from comment #1-4 and 6) work OK
Thanks for help
--
Maciej Rutecki
http://www.maciek.unixy.pl
2008/11/3 Maciej Rutecki <[email protected]>:
> 2008/11/3 Maciej Rutecki <[email protected]>:
>
>> Patch from comment #3 doesn't help. I will try patches from #11896 very soon.
>>
>
> Booth patches (from comment #1-4 and 6) work OK
I was wrong: patch from comment #6 doesn't work. I'm going to test
four patches from #11896 again to be sure.
--
Maciej Rutecki
http://www.maciek.unixy.pl
> The underlying issue is we've never reported such BIOS bugs before and now we
> do that unconditionally. IMnshO, this should only be done if ACPI debugging is
> enabled.
>
> While I can see a value in doing that always, IMO such a change should only be
> made after a big announcement.
I agree that we were aggressive in shipping this checking in 2.6.28-rc.
The checking has no functional effect, except to issue a console warning,
so I figured it had limited down-side.
It actually paid off almost immediately by pointing out why
a Linux bug was provoked on jejb's test box.
I had figured on making it CONFIG_ACPI_DEBUG for the
final release, but at this point we've seen only the
_BIF and _WAK warnings -- and they're both dealt with
via the patches queued for Linus.
So at this point, I'm inclined to keep this checking enabled in
2.6.28-final, independent of CONFIG_ACPI_DEBUG.
-Len