My laptop (a Samsung X20) contains a Phoenix BIOS and would benefit from 
patch 1e22436eba84edfec9c25e5a25d09062c4f91ca9 (x86: reserve low 64K on 
AMI and Phoenix BIOS boxen).

However, according to /sys/class/dmi/id/bios_vendor, the BIOS identifies
its vendor as "Phoenix Technologies LTD" (sans the comma).

This patch adds the approptiate identifier to the bad_bios_dmi_table in
arch/x86/kernel/setup.c.

The patch compiles cleanly and has been tested successfully on my machine.

Signed-off-by: Philipp Kohlbecher <xt28@gmx.de>

---

Please CC me, I am not on the list.

  arch/x86/kernel/setup.c |    7 +++++++
  1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 0fa6790..b88fdbe 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -767,6 +767,13 @@ static struct dmi_system_id __initdata
bad_bios_dmi_table[] = {
              DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies, LTD"),
          },
      },
+    {
+        .callback = dmi_low_memory_corruption,
+        .ident = "Phoenix BIOS",
+        .matches = {
+            DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies LTD"),
+        },
+    },
  #endif
      {}
  };

--

[ message continues ]

Given that AMI and Phoenix combined is something like 80% of the BIOS
market, if not more, it might simply be easier to make it unconditional,
 or make it a whitelist instead.

	-hpa
--

[ message continues ]

Note that we should do a simpler patch: just change the string to 
"Phoenix Technologies" and that will provide a proper match. (DMI 
matches work on substrings too)

Also, note that you can also force this behavior (and the checking) 
via CONFIG_X86_CHECK_BIOS_CORRUPTION=y - that will enable the 

The (slim) hope would be for them to address the memory corruptions 
that have been reported. It can affect older Linux versions, etc. So 
we want to print the fact to the syslog, based on the DMI strings from 
the reports.

	Ingo
--

[ message continues ]

Phoenix BIOSes variously identify their vendor as "Phoenix Technologies, 
LTD" or "Phoenix Technologies LTD" (without the comma.)

This patch makes the identification string in the bad_bios_dmi_table 
more general (following a suggestion by Ingo Molnar), so that both 
versions are handled.

Again, the patched file compiles cleanly and the patch has been tested 
successfully on my machine.

Signed-off-by: Philipp Kohlbecher <xt28@gmx.de>

---

  arch/x86/kernel/setup.c |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 0fa6790..9d5674f 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -764,7 +764,7 @@ static struct dmi_system_id __initdata 
bad_bios_dmi_table[] = {
  		.callback = dmi_low_memory_corruption,
  		.ident = "Phoenix BIOS",
  		.matches = {
-			DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies, LTD"),
+			DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies"),
  		},
  	},
  #endif


Done. (I wasn't sure whether you were saying that *I* should write this 
simpler patch or that you would. Anyway, here it is.)
--

[ message continues ]

applied to tip/x86/urgent, thanks Philipp!


yeah, developers/users writing patches is always the preferred 
solution! It's the vector that spreads Linux development to new areas 
and new people.

	Ingo
--

[ message continues ]

On Sat, 15 Nov 2008 17:55:20 -0800

Far more useful would be to make people aware of the problem. If the BIOS
is scribbling in the low 64K of RAM not just BIOS areas, and doing so
outside of ACPI marked areas they need to fix the BIOS ASAP. If they leave
their BIOSes randomly scribbling in operating system memory areas then as
with previous (hardware related) cases of vendors knowingly shipping
corrupting equipment they'll be building up a huge class action legal
liability.

As such making sure the vendor knows in a way they cannot deny is a very
useful activity.

Alan
--

[ message continues ]

CONFIG_X86_CHECK_BIOS_CORRUPTION=y will do that, it prints:

  Corrupted low memory at 0x1000 (4096 phys) = 0x1234
  Memory corruption detected in low memory
  < stack trace >

if enough distros turn it on (at least in their debug kernels) it 
creates the right kind of user pressure.

This debug feature to catch BIOS-generated low-memory corruption is 
already upstream.

	Ingo
--

[ message continues ]

Whitelist is bad:

even if bios vendor is a good boy and tests their bios with linux,
they will not notice that they corrupt low 64K (not whitelisted), and
will not fix their bios.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--

[ message continues ]