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-next>] [day] [month] [year] [list]
Date:	Thu, 17 May 2007 14:27:14 +0200
From:	Claas Langbehn <claas@...tdir.de>
To:	LKML <linux-kernel@...r.kernel.org>
Subject: This kernel requires the following features not present on the CPU...
 (on a VIA C7 CPU)

Hello,

I have got a VIA EPIA EX15000G Mini-ITX mainboard with a C7 VIA Esther 
processor (1500MHz).
There are two options in the BIOS that affect CPU feature flags:

C7 CMPXCHG8 - enable/disable (Disable to install windows NT 4.0) and
C7 No Execute (NX) - enable/disable

I enabled both and compiled a new 2.6.22-rc1-mm1 kernel. So far so good.

The problem is that the system is very unstable and crashes regularly 
(1-3 times a day).
After a crash the bios resets the two processor flags back to disabled. 
But like this
the kernel complains and does not continiue booting:

 > This kernel requires the following features not present on the CPU:
 > 0:8

Each time this happens, I have to go to the BIOS and manually enable 
these flags again.
That is pretty annoying! :(
I attached a cpuinfo.txt. When the two flags are disabled, cx8 and nx 
are not listed there.


Now my question is:

Would it be possible to override the BIOS settings of cx8 and nx and 
activate it with linux anyway?
The CPU supports it and I don't see any reason to disable it.


I already wrote several emails to VIA months ago saying that this is 
probably a bug in their BIOS, but they
are neitherreleasing a new BIOS nor reacting in any way. Their so called 
support website viaarena.com
is not helping neither. Since VIA is not helping at all, the only 
soulution I see would be to override the
BIOS'es decision.

Concerning the crashes I already changed the memory module, but with no 
success. I'm not sure
wether this is a hardware or software bug.


Many regards,
claas

View attachment "cpuinfo.txt" of type "text/plain" (481 bytes)

View attachment "dmesg.txt" of type "text/plain" (1679 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ