[HN Gopher] Memtest86 v6.00 with UEFI support released
___________________________________________________________________
Memtest86 v6.00 with UEFI support released
Author : conductor
Score : 98 points
Date : 2022-10-24 16:11 UTC (6 hours ago)
(HTM) web link (www.memtest.org)
(TXT) w3m dump (www.memtest.org)
| imwillofficial wrote:
| A thankless champion of quality tools.
|
| Memtest, I love you.
| systems_glitch wrote:
| Donate. That's how we support the open source projects we
| depend on!
| imwillofficial wrote:
| Will do! I've been using memtest since like 2006.
| rasz wrote:
| Which one? passmark or plus one?
| pt_PT_guy wrote:
| Isn't there a confusion between memtest86 from passmark and
| memtest86+?
|
| and memtest86 from passmark has a lot of nice features that
| aren't available MemTest86+, includin UEFI support, writing logs
| to disk, fully 64bit code, additional RAM tests, benchmarking,
| row hammer testing and more?
|
| and passmark shows that: https://www.memtest86.com/compare.html
| anderskaseorg wrote:
| Yeah, title should be Memtest86+ 6.0.0, not Memtest86 6.0.0.
| The original (PassMark) Memtest86 has been proprietary since
| 2013.
| conductor wrote:
| I guess HN has stripped out the "+" sign from the title.
| mjevans wrote:
| Could a mod or someone with privileges please change the
| title to:
|
| Memtest86plus ???
| systems_glitch wrote:
| Glad to see this finally out of beta! I've been using the various
| UEFI beta releases for a while, many new systems won't legacy
| boot the old memtest86+ correctly.
|
| Every machine in the shop, every server deployed, every customer
| repair (industrial control) gets memtest86+ after assembly and
| before going any further.
| nope96 wrote:
| This was 10+ years ago, but I had an issue with my motherboard
| not liking my RAM when in dual channel mode that memtest/memtest+
| could not find, but Windows Memory Diagnostic (advanced tests)
| did find. So it's worth running both if you are ever stumped.
| frou_dh wrote:
| I've returned faulty RAM after confirming a suspicion using
| MemTest86 (the PassMark one), several times over the years.
|
| In that situation, it's so nice to actually have some evidence to
| point to (a photo of the test results screen).
| linsomniac wrote:
| Memtest is awesome, I've used it for decades and run it on
| every new machine I get. It's great at detecting memory, bus,
| and CPU problems.
|
| We had a Dell R640 rackmount that arrived and part of our burn-
| in testing is running memtest, which said one of the modules
| had a problem. I contacted Dell support and they had me run the
| Dell built in memory test, which IIRC took something less than
| an hour. Memtest was taking around a day to generate this
| error. Dell support didn't want to replace it because their
| built in test wasn't showing anything.
|
| This was maybe the 5th or 6th same model server we had gotten
| and all of them were clean, so I really didn't want to put this
| into production. Could have been a memory problem, could have
| been CPU or motherboard issue...
|
| Went back and forth a few times, and finally contacted our
| sales person asking them what our return window was for the
| server. They reached out to support, who contacted us and said
| "Fine, we'll send you a replacement, but only this one time!"
| Usually I've gotten really good support from Dell Pro Support,
| but this time I was pretty disappointed.
| sigjuice wrote:
| Is there potential for UEFI-based aarch64 systems? Or is the code
| too specific to x86?
| MisterTea wrote:
| Already done. https://en.wikipedia.org/wiki/Windows_RT#History
|
| Windows is (was?) so deeply intertwined with x86 that MS
| bastardized their early ARM platform with ACPI and UEFI so they
| didn't have to write a new kernel HAL. Perhaps this has changed
| since Win RT.
|
| The RPi can also run tianocore, an open source reference uefi.
| xxpor wrote:
| UEFI/APCI is still a huge UX improvement over a device tree
| based solution.
| ajross wrote:
| UEFI is just a (somewhat/very clumsy) C API, there's nothing
| particularly x86-specific about it. Obviously some aspects like
| access to particular devices is going to be platform-dependent,
| but there's no reason it couldn't be used wherever.
|
| The question is why would you want to? Almost nothing in the
| UEFI world beyond core system boot is actually used in
| practice, and even there all the hard/interesting bits (device
| selection and bootstrapping, initial security and signature
| checks) have to happen before UEFI entry anyway. So it's all
| duplicated code. Your BIOS has a bunch of boot hooks that have
| to run before UEFI starts, then UEFI has to have all of its own
| drivers for storage and filesystems, just to load an OS kernel
| that has another driver suite.
|
| It's all just a mess. Frankly if you want an implementation of
| a clean but featureful boot environment for PCs that extends
| across architectures, look to Chromebooks.
| mjg59 wrote:
| > The question is why would you want to?
|
| To make it as easy as possible for people to transition from
| x86 to arm - having a compatible firmware interface means you
| don't need to entirely rewrite your deployment tooling when
| you start deploying arm servers.
|
| > Your BIOS has a bunch of boot hooks that have to run before
| UEFI starts
|
| What? There is no BIOS on a UEFI system.
|
| > UEFI has to have all of its own drivers for storage and
| filesystems, just to load an OS kernel that has another
| driver suite.
|
| Well, yes, you need to have the ability to access the
| hardware that the OS is on in order to get to the OS. The
| only way you avoid that is to put the kernel in flash and
| jump to it directly, but then you're incompatible with
| existing general-purpose operating systems.
| ajross wrote:
| > What? There is no BIOS on a UEFI system.
|
| This is... true, but only as an issue of semantics. There
| are _absolutely_ duplicated framebuffer and storage drivers
| in the firmware of modern PCs (and probably TPM & CSME
| too, though that's not my world) ( _Edit: also USB and PS
| /2 input device handling_). Those BIOS (yes, "BIOS" --
| that's what the people who write it call it) splash screens
| aren't using UEFI, nor is the initial boot device selection
| in most cases I'm aware of.
|
| UEFI seems clean (well, cleanER) only when viewed from
| downstream.
| yjftsjthsd-h wrote:
| > but there's no reason it couldn't be used wherever.
|
| And in fact has been; aarch64 UEFI exists (ex.
| https://www.cnx-software.com/2020/02/18/raspberry-
| pi-4-uefia... )
|
| > The question is why would you want to? Almost nothing in
| the UEFI world beyond core system boot is actually used in
| practice, and even there all the hard/interesting bits
| (device selection and bootstrapping, initial security and
| signature checks) have to happen before UEFI entry anyway. So
| it's all duplicated code. Your BIOS has a bunch of boot hooks
| that have to run before UEFI starts, then UEFI has to have
| all of its own drivers for storage and filesystems, just to
| load an OS kernel that has another driver suite.
|
| Because it's a universal interface for arbitrary OSs to boot
| without having to special-case every single new board as it
| comes out. You can take a single standard install media and
| use it to install on any UEFI ARM board, because they all
| boot and hand off hardware discovery to the kernel in the
| same way.
| ajross wrote:
| You're doing the thing where you confuse the need for a
| feature with the need for a particular implementation of
| that feature. Again, UEFI is really awful. Look at
| ChromeOS.
| yjftsjthsd-h wrote:
| > You're doing the thing where you confuse the need for a
| feature with the need for a particular implementation of
| that feature. Again, UEFI is really awful.
|
| To be clear, I would have preferred that the universal
| booting solution was Open Firmware. But I'm pragmatic;
| UEFI is already widely used, so I'd rather have _any_
| universal standard rather than a fragmented ecosystem of
| non-standard options. I don 't care that it's ugly, I
| care that it works and that it can get the market buy-in.
|
| > Look at ChromeOS.
|
| ChromeOS is a single OS from a single vendor, albeit
| running on multiple architectures. I don't know enough to
| know how beautiful it can be internally, but in practice
| a boot firmware that can't boot arbitrary BSD and Linux
| OSs is useless to me, and the ChromeOS firmware is, to my
| knowledge, only supported on Chromebook hardware and by
| ChromeOS and a tiny number of Linux distros that target
| Chromebook hardware. Ecosystem effects matter.
| mjg59 wrote:
| Assuming you mean "potential for memtest86+ on UEFI-based
| aarch64 systems" - memtest86+ takes over the entire system,
| rather than relying on firmware services. In that respect it's
| more like a kernel rather than an app, and so involves a lot of
| architecture-specific setup code - the UEFI port here is more
| about being able to jump into the memtest86+ "kernel" from the
| UEFI firmware than making it a generic UEFI application. It
| also needs guarantees around memory access that aren't provided
| by C, so there's assembly code to do that. And finally, a lot
| of the hardware interaction seems to assume a PC-type platform.
| I don't think there's anything impossible to port to aarch64
| here, but it looks like a fair amount of work.
| sigjuice wrote:
| Thanks! Yes, I meant "potential for memtest86+ ..."
| mastax wrote:
| I wonder what this changelog entry means:
|
| > Add support for SDRAM
|
| Surely it had support for SDRAM before, since DDR, DDR2, ... are
| all SDRAM.
|
| Edit: I figured it out. The JEDEC SPD spec calls SPD type 4
| "SDRAM", referring to Single Data Rate SDRAM.
| xxpor wrote:
| >I figured it out. The JEDEC SPD spec calls SPD type 4 "SDRAM",
| referring to Single Data Rate SDRAM
|
| I have seen some dumb naming choices in my time but that might
| just take the cake.
| Fatnino wrote:
| The USB _waves hands_ everything is a masterclass in how not
| to name things.
| mastax wrote:
| Well DDR SDRAM hadn't been invented yet, and since everyone
| calls DDR SDRAM "DDR" it's not particularly confusing in
| context.
___________________________________________________________________
(page generated 2022-10-24 23:02 UTC)