On 06.09.2014 00:19, ron minnich wrote:
I don't think it's random at all. Vladimir can confirm, but if he is caching the RAM parameters, then this 'solution' will work for you until the next time you reflash coreboot, or change your dram type, at which point it will stop working.
Nehalem code discards cache if there is any mismatch between cache and modules. There are 2 techniques in use: 1) If SPD mismatches, cache is discarded, so plugging new module will discard cache. 2) Series of witnesses ensure that cache is only used if full algorithm would yield the same result. E.g. if the result is a middle of timing segment, then it saves the ends of segments and checks on next boot that ends are the same. So even reseating the modules is likely to cause cache to be discarded.
I think that his problem is either: 1) Badly seated modules 2) Only one permutation fails. 3) Code bug triggered by specific insertion of the said module Since I've spent countless hours will all kinds of modules inserted and reinserted on nehalem and the only bug I'm aware of is triggered by having over 8G (maximum for nehalem) worth of RAM which causes die() instead of proper ignore of extra RAM, without proof to contrary I'd guess 1 is the case.
On Fri, Sep 5, 2014 at 2:37 PM, Vladimir 'φ-coder/phcoder' Serbinenko phcoder@gmail.com wrote:
I think that his problem is either:
- Badly seated modules
I like this because it gets us off the hook. But it's hard for me to believe that every single reseat is a bad one.
Mono, now that it's all working, can you reflash coreboot (to make sure the MRC cache is dead, dead, dead), reboot, and see if it works. If so, the I believe Vladimir
ron
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
cache
Is that trying to make the code fast before making it correct?
//Peter
-
Peter Stuge -
ron minnich -
Vladimir 'φ-coder/phcoder' Serbinenko