Hello,
I discovered the issue with Memtest86+ stuck on my Thinkpad x230 on the very first tests. Always on the same point, 52%. Every release since 4.8 works this way, coreboot 4.7 works fine. Is this a known bug?
Hi Max,
check out this "workaround" [1]: It seems that Memtest86+ is buggy when directly integrated as a part of the coreboot configuration but works fine when you use the Memtest86+ floppy in conjunction with SeaBIOS.
Unfortunately I do not know any reason why it is that way or if there is a plan to fix it just that the above mentioned workaround exists and works (on my T430 that is).
Kind regards
lhochstetter
[1] https://mail.coreboot.org/pipermail/coreboot/2018-November/087713.html
On 22.04.20 23:11, Max Zim wrote:
Hello,
I discovered the issue with Memtest86+ stuck on my Thinkpad x230 on the very first tests. Always on the same point, 52%. Every release since 4.8 works this way, coreboot 4.7 works fine. Is this a known bug? _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Dear Max,
Am 22.04.20 um 23:11 schrieb Max Zim:
I discovered the issue with Memtest86+ stuck on my Thinkpad x230 on the very first tests. Always on the same point, 52%. Every release since 4.8 works this way, coreboot 4.7 works fine. Is this a known bug?
Thank you for your report. I cannot remember hearing/reading about that. Your report is lacking some details, so it’s unclear if it’s a regression in Memtest86+ or coreboot. It’d be great if you could answer the questions below.
1. How do you build the Memtest86+ payload? 2. What version do you choose? I believe there is *Stable* and *Master*? 3. How do you start the Memtest86+ payload? I assume you have it as secondary payload, and select it from some primary payload (`fallback/payload` in CBFS)? Which one do you use? 4. Payloads are actually interchangeable between coreboot versions. If you add the Memtest86+ payload, which works with coreboot 4.7 to coreboot master, does it still work?
Something like:
$ build/cbfstool path/to/coreboot-v4.7.rom extract -n img/memtest -f memtest-v4.7
And then for the master:
$ build/cbfstool path/to/coreboot-master.rom add-payload -n img/mtest-v4.7 -f memtest-v4.7 -c lzma
That way, we can figure out if it’s a regression in coreboot or Memtest86+.
Kind regards,
Paul
On 23/04/2020 09:24, Paul Menzel wrote:
1. How do you build the Memtest86+ payload? 2. What version do you choose? I believe there is *Stable* and *Master*?
I just checked the box in the nconfig menu, so it should be Stable as defined in the coreboot's automated build flow.
3. How do you start the Memtest86+ payload?
I'm pressing ESC and choose Memtest86+ from the payloads menu. I also checked the Debian's Memtest86+. It stuck on both "good" and "bad" coreboot.
If you add the Memtest86+ payload, which works with coreboot 4.7 to coreboot master, does it still work?
Yes. Workaround previously suggested by Lars Hochstetter also works. I also rebuilt coreboot with Memtest86+ from master, it also works fine while Debian's Memtest86+ still stuck.
Dear Max,
Am 23.04.20 um 11:28 schrieb Max Zim:
On 23/04/2020 09:24, Paul Menzel wrote:
1. How do you build the Memtest86+ payload? 2. What version do you choose? I believe there is *Stable* and *Master*?
I just checked the box in the nconfig menu, so it should be Stable as defined in the coreboot's automated build flow.
Understood. No idea, if the stable tag changed between 4.7 and today.
3. How do you start the Memtest86+ payload?
I'm pressing ESC and choose Memtest86+ from the payloads menu. I also checked the Debian's Memtest86+. It stuck on both "good" and "bad" coreboot.
Ok, so you are using SeaBIOS as primary payload.
If you add the Memtest86+ payload, which works with coreboot 4.7 to coreboot master, does it still work?
Yes. Workaround previously suggested by Lars Hochstetter also works. I also rebuilt coreboot with Memtest86+ from master, it also works fine while Debian's Memtest86+ still stuck.
Sorry, you lost me. Please give more details, so there is no room for ambiguity – especially when two programs and different versions are involved.
So, coreboot master with Memtest86+ Stable does *not* work. coreboot master with Memtest86+ Master *does* work?
Kind regards,
Paul
Dear Max,
Am 23.04.20 um 12:34 schrieb Max Zim:
On 23/04/2020 12:07, Paul Menzel wrote:
So, coreboot master with Memtest86+ Stable does *not* work. coreboot master with Memtest86+ Master *does* work?
Correct.
The Memtest86+ stable tag was changed to v002 in coreboot 4.10 in commit af15d040 (payloads/external/Memtest86Plus: update to version 002 stable) [1].
It’d be great, if you could bisect the commit, fixing this in Memtest86+’ master branch. There are less than 20 commits, so it should be really fast.
$ git log --oneline --reverse v002..origin/master 746c840 spd: refactor code for AMD SBx00 and FCH aeb2c32 pci.c: Remove unneeded 'else' a5c8cea dmi.c: Fix whitespace for conditional statements 80c4e48 controller: Remove dead assignment e3cfbc0 spd.c: Remove dead assignment d2519c0 Revert "spd.c: Remove dead assignment" 2182c5b Work around freeze if built with GCC8+ due to pointer overflow optimizations in test.c 09c630f Update Standard manufacturer’s ID code 07c9685 controller.c: Fix logical ‘or’ of equal expressions a78401b spd.c: Remove dead assignment fb07598 Memtest86+: Support for configuring console from LB_SERIAL entry 1e49025 Memtest86+: Replace serial accessor macros with inline functions 73ad6b3 Memtest86+: Refactor serial port code to reduce global variables c6f27cc Memtest86+: Support MMIO serial ports 0b75625 (origin/master, origin/HEAD) Memtest86+: Fix typos
Afterward, we tag Memtest86+ v003, and use that as the new stable release.
Kind regards,
Paul
PS: By the way, Memtest86+ 5.31b was released [2].
[1]: https://review.coreboot.org/c/coreboot/+/32613 [2]: https://www.memtest.org/
On 23/04/2020 12:45, Paul Menzel wrote:
It’d be great, if you could bisect the commit
2182c5b is the first "good" commit.
On Thu, Apr 23, 2020 at 6:46 AM Paul Menzel pmenzel@molgen.mpg.de wrote:
PS: By the way, Memtest86+ 5.31b was released [2].
That's huge! Thanks for picking up development.
On Thu, Apr 23, 2020 at 5:42 PM R S rene.shuster@bcsemail.org wrote:
On Thu, Apr 23, 2020 at 6:46 AM Paul Menzel pmenzel@molgen.mpg.de wrote:
PS: By the way, Memtest86+ 5.31b was released [2].
That's huge! Thanks for picking up development.
-- LAN Engineer * NOC and IT Infrastructure Maintenance BCS Technology Department * Network Group ComicSans Awareness Campaign _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Would like to add 2 notes: 1) Recently I've discovered that you could build a coreboot's "5.01 002" memtest86+ fork as a floppy instead of payload (and then manually add a floppy to a coreboot BIOS build) 2) A good way to double check is to also use a Passmark's memtest86 4.37 floppy. If you're getting the same results, means that maybe a RAM is faulty; if the different results - maybea false positive.
Thank you for telling about a new memtest86+, nice to see it active again. I'd inform the developer about coreboot's fork and some other forks, so that he could merge them into a one great memtest.
Hello,
Hello Max,
I discovered the issue with Memtest86+ stuck on my Thinkpad x230 on the very first tests. Always on the same point, 52%. Every release since 4.8 works this way, coreboot 4.7 works fine. Is this a known bug?
Please try to apply the patch I did some time ago [1]. It is exactly the same issue I was having, except it hang at a different point IIRC.
The cause of this is that when Memtest86+ is run as a payload, it expects that the memory map provided in coreboot tables is correct. It isn't, as SeaBIOS modified it and didn't update the coreboot tables. However, it keeps track of used memory in E820 properly, so other Memtest86+ binaries (e.g. emulated floppy or file on a disk) work.
[1] https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/thread/Y4BLTED...
Krystian Hebel Firmware Engineer https://3mdeb.com | @3mdeb_com
On 23/04/2020 13:06, Krystian Hebel wrote:
Please try to apply the patch I did some time ago [1].
Unfortunately it does not work for me. I applied patch manually, switched back to the Stable Memtest86+ and ran `make clean && make`; memory test hanged at the same point. Checked twice.
-
Krystian Hebel -
Lars Hochstetter -
Max Zim -
Mike Banon -
Paul Menzel -
R S