site  contact  subhomenews

Memtest in Linux

December 27, 2009 — BarryK
panzerpuppy wrote:

How about including Memtest (accessible from the boot menu) in the next build of Quirky?
I really miss this useful app. Great for memory diagnostics and checking the bandwidth/performance of the memory and CPU caches.

The 2.6.26 and later kernel has memtest builtin, that can be invoked at the boot prompt. See my earlier report:

The kernel used in Puppy 4.3.1 is configured with memtest enabled (as is the kernel in Quirky), but I was unable to get anything in 'dmesg' despite what Dougal investigated should be happening.

Obviously I was doing something wrong when I tried to activate it. Maybe there was something in 'dmesg' and I overlooked it?

I wish that I could get this issue resolved. Every now and again someone posts that they would like memtest to be in Puppy, I respond that it is already in the kernel, and there the matter stops, noone resolves it. Would someone take this onboard and solve this mystery? There is probably a very simple solution.


limited memtest
Username: bigpup
From: Memtest is a commonly used tool for checking your memory. In 2.6.26 Linux is including his own in-kernel memory tester. The goal is not to replace memtest, in fact this tester is much simpler and less capable than memtest, but it's handy to have a built-in memory tester on every kernel. It's enabled easily with the "memtest" boot parameter. From this statement, the memtest in the kernel, is not as good, as the real memtest86 that we would all like to have.

limited memtest
Username: bigpup
"From what I can find on the memtest, that is in the kernel,it is designed to do one thing. On boot up, It will check for bad memory and block that memory from being used. This is a good thing, but we would like to have memtest86 on the boot menu. Seems that memtest86 does much more testing and troubleshooting. Remember Quirky is all about doing things different. We like that, and we want to get quirky!

Username: prehistoric
"When I am chasing hardware problems on computers, I run memtest86+ as a standalone utility. This eliminates many variables which complicate matters when running tests under a Linux kernel. There are reasons for running a memory test under the OS, but these are not as compelling as fundamental diagnostics. I doubt most Puppy users are running servers that must stay on round-the-clock. If people want to run a test which finds hard errors and maps those pages out of memory, the test under the kernel will do. If they want information from diagnostics, it may disappoint them.

Username: Dougal
"Have you tried booting with memtest turned on and pfix=rdsh? I seem to recall that you use a low value (like 15) of CONFIG_LOG_BUF_SHIFT, which always caused the early messages (which I assume is where the memtest messages will be) to be gone by the time you finish booting and run dmesg... Here's how the dmesg output should start ("dmesg | head") if nothing is lost: BIOS EBDA/lowmem at: 0009fc00/0009fc00 Linux version (root@puppypc) (gcc version 4.2.2) #1 SMP Sun Apr 5 17:18:58 GMT-8 2009 KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD NSC Geode by NSC Cyrix CyrixInstead Centaur CentaurHauls Transmeta GenuineTMx86 Transmeta TransmetaCPU

dmesg lost
Username: BarryK
"Dougal, That's it, it's getting lost. Puppy records dmesg in the initramfs, at /tmp/bootkernel.log, but that starts off as: [code] resource 1 mem: [0x000000-0xffffffff] pci_bus 0000:02: resource 0 io: [0x2000-0x2fff] pci_bus 0000:02: resource 1 mem: [0x24000000-0x240fffff] pci_bus 0000:02: resource 2 mem: [0x0-0xfffff] pci_bus 0000:03: resource 0 mem: [0x0-0xfff] pci_bus 0000:03: resource 1 mem: [0x0-0xfffff] pci_bus 0000:03: resource 2 mem: [0x0-0xfffff] pci_bus 0000:04: resource 0 mem: [0x0-0xfff] pci_bus 0000:04: resource 1 mem: [0x0-0xfffff] pci_bus 0000:04: resource 2 mem: [0x0-0xfffff] pci_bus 0000:05: resource 0 mem: [0x0-0xfff] pci_bus 0000:05: resource 1 mem: [0x0-0xfffff] pci_bus 0000:05: resource 2 mem: [0x0-0xfffff] pci_bus 0000:0a: resource 0 io: [0x3000-0x3fff] pci_bus 0000:0a: resource 1 mem: [0xd0000000-0xd00fffff] pci_bus 0000:0a: resource 2 pref mem [0x20000000-0x23ffffff] pci_bus 0000:0a: resource 3 io: [0x00-0xffff] pci_bus 0000:0a: resource 4 mem: [0x000000-0xffffffff] pci_bus 0000:0b: resource 0 io: [0x3000-0x30ff] pci_bus 0000:0b: resource 1 io: [0x3400-0x34ff] pci_bus 0000:0b: resource 2 pref mem [0x20000000-0x23ffffff] pci_bus 0000:0b: resource 3 mem: [0x28000000-0x2bffffff] NET: Registered protocol family 2[/code] Thanks Dougal, you have identified the problem. So, probably easiest thing to do will be to record dmesg earlier, right at the start of execution of 'init' script.

kernel memory blocking
Username: bigpup
"Check this out:

memtest: I give up
Username: BarryK
"My latest Woof allows "pfix=rdsh0" which dumps to a console right at the beginning of the 'init' script. Then when I run 'dmesg' I do see that preliminary stuff that Dougal posted. However, although I booted with "memtest=4" I cannot see anything in the kernel log that looks anything like it is reporting on the memtest. Quite disappointing that. Looks like I might have to install memtest86+.

Username: superpup
""Looks like I might have to install memtest86+" That's great news! Now we'll have the 'real deal' = Memtest86+ :) (that means I can finally get rid of that Knoppix Live DVD and use Quirky instead)

Tags: puppy