David S introduced memtest86+ which can diagnose faulty RAM which may cause random crashes, the storage of faulty data, incorrect checksums and a range of inconsistent errors.
memtest86+ carries out a series of tests which can take a long time to execute; if errors are found, you can isolate, remove or swap memory but note that two memory chips from the same batch are likely to exhibit the same problem. If memtest86+ hangs, there may be a motherboard problem. If there are no errors, the problem may have gone away simply because the chips have been waggled in their sockets or because memtest86+ doesn’t pick up all errors.
You can set two kernel parameters:
memtest=n runs n passes of memtest86+ and puts faulty memory regions out of use but it doesn’t catch all errors.
memmap="size$location" puts the size of RAM after the location in hex out of bounds. Unfortunately, there is no easy way of recording errors generated by memtest86+ though there is an option to identify regions of bad RAM.
You can edit lilo.conf or GRUB and add the expression
memmap="size\$location" to the boot parameters.
David C reported back on the visit to FabLab. They are interested in whether we would want to use their space
for personal use, in which case people need to turn up with files
to run a Raspberry Pi/Arduino club
as the basis for a Keighley LUG
to demonstrate on a voluntary or paid-for basis software like GIMP, Inkscape or freeCAD
to share designs
to create documentation.
David S and Brian then reported on BCB; the next programme is on 7 March; so it needs to be ready by 28 February. There are opportunities for people to contribute via a Google hangout or an Audacity recording.
David C then updated people on the website.