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 188.8.131.52 kernel used in Puppy 4.3.1 is configured with memtest enabled (as is the 184.108.40.206 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.
Comments:Posted on 27 Dec 2009, 21:53 by bigpup
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.
Posted on 27 Dec 2009, 22:46 by 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!
Posted on 28 Dec 2009, 22:04 by 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.
Posted on 29 Dec 2009, 2:50 by 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 220.127.116.11 (root@puppypc) (gcc version 4.2.2) #1 SMP Sun Apr 5 17:18:58 GMT-8 2009
KERNEL supported cpus:
NSC Geode by NSC
Posted on 29 Dec 2009, 7:59 by BarryK
That's it, it's getting lost.
Puppy records dmesg in the initramfs, at /tmp/bootkernel.log, but that starts off as:
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
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.
Posted on 30 Dec 2009, 23:40 by bigpup
kernel memory blocking
Check this out:
Posted on 31 Dec 2009, 8:30 by BarryK
memtest: I give up
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+.
Posted on 31 Dec 2009, 15:14 by 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)