linux-kernel - Re: Endless ACPI errors on Linus tree (5b664cb235)

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]

Message-Id: <48D0C316.76E4.0078.0@novell.com>
Date:	Wed, 17 Sep 2008 07:43:02 +0100
From:	"Jan Beulich" <jbeulich@...ell.com>
To:	"Andrew Paprocki" <andrew@...iboo.com>
Cc:	"Andi Kleen" <andi@...stfloor.org>,
	"Robert Gough" <robert.gough@...el.com>,
	"Robert Moore" <robert.moore@...el.com>,
	"Len Brown" <lenb@...nel.org>, "Takashi Iwai" <tiwai@...e.de>,
	"LKML" <linux-kernel@...r.kernel.org>
Subject: Re: Endless ACPI errors on Linus tree (5b664cb235)

>>> "Andrew Paprocki" <andrew@...iboo.com> 17.09.08 06:56 >>>
>On Wed, Jul 23, 2008 at 12:14 PM, Jan Beulich <jbeulich@...ell.com> wrote:
>>>>> "Moore, Robert" <robert.moore@...el.com> 23.07.08 17:43 >>>
>>>Couple of thoughts.
>>>
>>>I think we must use the V2 field if it is present and the address value
>>>is > 32 bits.
>>>
>>>What if the V2 address is < 32 bits but does not match the V1 address?
>>
>> The v2 address was used already before this patch, the patch just
>> (initially) tried to make things consistent to use the v2 bit width along
>> with the v2 address. That didn't work out. I certainly think there's room
>> for improvement, but perhaps (at least at present) of more academical
>> nature: If the v2 widths indicate a value wider than the v1 ones, then
>> we could still try to use the v2 field. The breakages reported so far
>> were only in the v2 widths being smaller than the v1 ones...
>
>Jan,
>
>I finally was able to test this patch with the hardware which
>exhibited the original problem. The system works as expected and it
>prints out the kernel warning, which is also expected:
>
>FADT: X_PM1a_EVT_BLK.bit_width (8) does not match PM1_EVT_LEN (4)
>
>Let me know if you'd like me to try anything else on this hardware. I
>dumped the BIOS tables and verified that the bit width field is
>incorrect, so there doesn't seem to be much else to do.

Thanks, Andrew. No, there's nothing else to try.

Len/Robert/Andi - could we get that patch then into the queue again?
Do I need to re-submit?

Jan

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