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: <20070602092232.GP7217@one.firstfloor.org>
Date:	Sat, 2 Jun 2007 11:22:32 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Venki Pallipadi <venkatesh.pallipadi@...el.com>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Andi Kleen <andi@...stfloor.org>,
	Justin Piszcz <jpiszcz@...idpixels.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Intel's response Linux/MTRR/8GB Memory Support / Why doesn't the kernel realize the BIOS has problems and re-map appropriately?

> I feel, having a silent/transparent workaround is not a good idea. With that

If enough RAM is chopped off users will notice. They tend to complain
when they miss RAM.  I don't like panic very much because for many
users it will be a show stopper (even when they are not blessed
with "quiet" boots like some distributions do) 

The message in dmesg could be also emphasized a bit with a little
ASCII art (but no <blink> tag in there) 

The problem I'm more worried about is if the system will be really
stable --- could it be that the memory controller is still
misconfigured and cause other stability issues? (we've had such
cases in the past). Also I'm not sure we can handle the case of 
the MTRR wrong not at the end of memory but at the hole sanely.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ