linux-kernel - Re: [Re: Linux 2.6.28-rc1] ACPI Warning (nspredef-0852)[...]

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 25 Oct 2008 20:04:00 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Robert Hancock <hancockr@...w.ca>
Cc:	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Maciej Rutecki <maciej.rutecki@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-acpi@...r.kernel.org, lenb@...nel.org,
	fabio.comolli@...il.com
Subject: Re: [Re: Linux 2.6.28-rc1] ACPI Warning (nspredef-0852)[...]

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