Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.periphs.mainboard.abit (
More info?)
Chip wrote:
> Will Dormann wrote:
>> Chip wrote:
>>> The Real Slim Shady wrote:
>>>> Nonsense.
>>>> You too don't know what you're talking about. No dos, no windows,
>>>> no os/2, no VMS, no UNICOS. Nothing but an excellent memtest.
>>>> Running another tester that needs an os is a waste of time. But
>>>> it's too long to explain you why.
>>>
>>> So, memtest just runs "on its own" does it?
>>
>> Yes.
>>
>>> Didn't you stop to think how does memtest actually display anything
>>> on screen? Or take input from your keyboard? Do you think the
>>> memtest authors decided to write all their own device drivers, just
>>> for the hell of it? Well I can tell you, they didn't.
>>
>> You seem pretty sure of yourself, Chip. But you're quite wrong.
>> memtest86 does not run on DOS. Just because you see text on the
>> screen, that in no way means that it's DOS.
>>
>> Some of the memtest86 code is based on the Linux 1.2.1 kernel, but it
>> indeed does not run "on top" of any OS. Saying that memtest86
>> isn't that great because it misses areas of memory used by Windows
>> because it is DOS-based is completely ridiculous.
>
> OK I got it wrong-ish. I had thought that Memtest86 ran on a DOS
> derivative. Having browsed their website, I realize it runs on a
> Linux derivative. However DOS/Linux, who cares. It still doesn't
> run "on its own". It needs disk drivers
Nope, uses the BIOS floppy calls (doesn't need to do floppy access once in
protected mode).
> display drivers
Nope, uses the BIOS video calls to set up the screen while in real mode, and
uses the old fashoned 0xB800 segment to display stuff in protected mode.
> keyboard drivers
~20 lines of code can hardly be called a keyboard driver ... it just polls
the two main keyboard I/O ports to see if a key has been pressed.
> and the like and they have to sit in memory somewhere. Just
> because they take a Linux boot sector reader and modify it, it
> doesn't mean the code isn't there!
It depends what you classify as an OS. The only code taken from Linux is the
boot sector, the memory size-detection code (some of it, anyhow), and the
code to kick it into protected mode. Everything else is the memtest86
program itself. I personally wouldn't call a boot sector and protected-mode
entry code an OS since it's not used after the boot-up sequence, but your
standards may differ.
> And as to my point about memtest not testing all of your memory, and
> that you can have a clean bill of health in memtest, but still get
> Windows crashes. Well, the memtest people say this:
>
> "By default the test attempts to get the memory size from the BIOS
> using the 'e820' method. With 'e820' the BIOS provides a table of
> memory segments and identifies what they will be used for. By default
> Memtest86 will test all of the ram marked as available and also the
> area reserved for the ACPI tables. This is safe since the test does
> not use the ACPI tables and the 'e820' specifications state that this
> memory may be reused after the tables have been copied. **Although
> this is a safe default some memory will not be tested.**"
The types of memory that can be specified through e820 are:
01: memory, available to OS
02: reserved, not available (e.g. system ROM, memory-mapped device)
03: ACPI Reclaim Memory (usable by OS after reading ACPI tables)
04: ACPI NVS Memory (OS is required to save this memory between NVS
sessions)
other (00 and 05-FF): not defined yet -- treat as Reserved
Memtest86 tests regions marked 01 and 03. If Windows is using regions marked
02 and 04, I would be EXTREMELY worried. As long as memtest86 is reporting
the same amount of memory available as Windows, then it'll be testing
exactly the same parts that Windows uses (Windows NT kernels since 3.1 use
E820 as the primary method of memory-size detection).
> So yes, OK its not "DOS" based. But it does have device drivers
Nope (read the source code
).
> and
> it makes assumptions about what memory to test
Sorta ... it assumes that trying to write to ROMs ain't gonna work, which is
fair enough IMO (every OS I know makes this assumption as well).
> and what not to test.
> These points I made, and these are correct.
One incorrect, one correct on a technicality that's not applicable to the
situation at hand
In my experience, if Memtest86 passes but Windows still has stability
issues, then the problem is either the power supply/voltage regulators, the
CPU, or the northbridge. The middle case can (on AMD CPUs) be identified by
reducing the multiplier. This is the most probably case. The middle case can
be identified by putting in higher-spec RAM, cooling the northbridge better,
or increasing the northbridge voltage. Unless you're really pushing the
chipset, this is unlikely to be a problem though. The remaining case is
quite interesting. When you're runing memtest86, the power usage is very
stable. It's doing the exact same thing over and over again, and nothing is
changing (except when it changes tests). This means that the voltage
regulators (both in the PUS and on the board) have a very easy job as long
as they can supply sufficient power. With a fluctuating load, you tend to
get a fluctuating "regulated" voltage in the opposite direction to what you
want: when you have a load spike, the voltage dips down briefly until the
regulator compensates for it. So your chip will (for a brief moment) be
running at the higher load with a lower voltage = not good for stability.
Under Windows, you have a very variable load. You have timers firing off all
the time, interrupts getting serviced (memtest86 runs with most interrupts
turned off), disk activity, etc etc. As well as that, Windows tends to push
the rests of the system (CPU, video card, disk drives) a lot harder than
memtest86 (which only really pushes the memory). So the regulators have to
supply more power to a more fluctuating load. Consequently, the voltage
regulators have a difficult job keeping the lines stable and you can end up
with voltage dips happening at annoying times. So although the every part of
the system may be stable under a continuous load with the rest of the system
idle, when you put everything together and throw the power requirements all
over the place, it becomes unstable if anything is being pushed near to its
limit.
So, what's the solution? As usual, increase the voltage
Depending on
what's failing, you'll need to increade the RAM, CPU, or chipset voltage, or
try a better PSU if that's the thing having problems. It's a bit annoying
having to run things at a higher voltage than what they need, but until
someone comes up with a much better voltage regulator, these problems are
here to stay.
--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more
Add michael@ to emboss.co.nz - My inbox is always open
Facebook
Twitter
Instagram