Archived from groups: alt.comp.hardware.overclocking.amd,alt.comp.periphs.mainboard.abit (More info?)
Thanks Michael for a very thorough explanation of how memtest86 works.
"Michael Brown" <see@signature.below> wrote in message
news:JwDkc.352$8J.20415@news.xtra.co.nz...
> 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
>
>
Thanks Michael for a very thorough explanation of how memtest86 works.
"Michael Brown" <see@signature.below> wrote in message
news:JwDkc.352$8J.20415@news.xtra.co.nz...
> 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