Hi,
On 11/28/2016 11:18 PM, Heyi Guo wrote:
Hi Leif,
Welcome back :)
Please help to review the RP1612 v4 version patchsets, thanks.
在 11/29/2016 12:31 AM, Leif Lindholm 写道:
(Hi Heyi, I am now back from my holiday.)
On Sat, Nov 19, 2016 at 03:41:57PM +0800, Heyi Guo wrote:
Hi Leif,
We have the test result about the BootMode, see detail below, please check and let me know your comment.
Thanks and Regards, Heyi.
在 11/16/2016 8:53 AM, Heyi Guo 写道:
sorry, I missed the comments previous version, i will try it.
在 11/16/2016 4:49 AM, Leif Lindholm 写道:
On Mon, Nov 14, 2016 at 07:29:50PM +0800, Heyi Guo wrote:
Memory test may take long time when there is a lot of memory in system, so we disable memory test in BDS to accelerate boot speed.
I am still not a fan of this. Do you have any feedback with regards to the comments I made on the previous version?:
It would be very much preferable if you could make use of the provided facilities and set your BootMode to BOOT_WITH_DEFAULT_SETTINGS or BOOT_WITH_FULL_CONFIGURATION, which would cut the memory test time to 1/16.
Have a look at GenericMemoryTestEntryPoint() and let me know what you think.
We have checked the code and found that the BootMode is already BOOT_WITH_FULL_CONFIGURATION at the previous version, butit is could not define the test level, actually, the test level is passed by the PlatformBdsPolicyBehavior at PlatformIntelBdsLib, and the level is 'QUICK' now, if we switch it to 'SPARSE' the test time will cut to 1/4, but the D05 have 16 DIMM slots(D03 8 slots) and totally support 16GB*16(256GB) memory, the test time is still too long, so could we set the level to 'IGNOR'?
For reference, what periods of time are we talking about here?
As far as I can see, this protocol is required only because D0* are still using IntelBds? And looking at that code, it will happily skip over doing the memory test (returning EFI_SUCCESS) if the protocol cannot be found.
So if we are genuinely looking to remove the feature of verifying that the RAM is basically functional - why are we not just dropping the GenericMemoryTestDxe instead of replacing it with NullMemoryTestDxe?
Regards,
Leif
It's cost about 2 minutes on 256G memory platform, yes, this protocol is required because we still using IntelBds, and we also think that using NullMemoryTestDxe is better.
It seems to me, that these are the kinds of decisions best left up to the end user. IMHO, doing some basic hardware sanity checking at power on is part of what makes a machine "enterprise". Giving users more concerned with boot speed the option to disable (and particularly interactively skip) the check is a much better choice than trying to make the decision for all the users.
Consider the case of scheduled downtime to install RAM. In that case, spending an additional few minutes to sanity check the RAM is a much better option than discovering half an hour after boot there is something wrong when a particular page starts taking uncorrectable errors on first use.
BTW: This isn't all or nothing either, there are a lot of choices about how aggressive the POST should be, based on whether the machine detects a hardware change, is being cold powered on, warm rebooted, etc.
Thanks,