05:09:53 <tomman> latest crash stacktrace: https://paste.debian.net/1283224/
05:09:55 <tomman> looks.... weird
05:10:34 <tomman> I'm definitely doing a memtest ASAP, but I doubt it's RAM (otherwise why Linux or any other app is bursting in flames? I know RAM failures can be tricky, but ugh....)
06:36:08 <njsg> tomman: was it you who had trouble with sessionstore and search engines?
14:42:39 <tomman> another crash
14:42:44 <tomman> surprise: i have bad RAM!
14:43:08 <tomman> memtest found a lone faulty cell so far
14:43:49 <tomman> near the end of the memory space
14:43:53 <tomman> yay
14:44:19 <tomman> I got lucky that only SeaMonkey was hitting this booby trap, and not the rest of the OS!
16:04:44 <njsg> near the end?
16:05:01 <njsg> hm, so maybe it's worth a try trying to cap linux's usable memory?
16:05:08 <njsg> IIRC there was a parameter for that
16:07:42 <njsg> mem= perhaps, but the documentation has notes about possible troubles with PCI memory addresses on X86, I wonder if "X86" there means a sort of ""x86 group"" including AMD64 or if it is specifically IA-32.
16:10:00 <njsg> ah, documented at the beginning. includes AMD64.
16:22:28 <tomman> ugh, and now I've rendered my machine unbootable because of GRUB_BADRAM
16:22:39 <tomman> there is a very old bug lingering on it if you use 64-bit offsets
16:25:29 <tomman> "So don't use GRUB badram on 64bit systems, unless you know what you're doing."
16:25:31 <tomman> https://unix.stackexchange.com/questions/746164/grub-hangs-itself-with-64bit-memtest86-badram-pattern
16:25:34 <tomman> too late!
17:11:11 <njsg> tomman: unless I'm looking wrong, there's no bug about "badmem" on savannah
17:19:15 <tomman> njsg: I guess noone cares
17:19:46 <tomman> I defined GRUB_BADMEM on mine with the values pointed out by memtest86, ran update-grub, rebooted, and GRUB itself would hang at a black screen
17:20:03 <tomman> found many reports of GRUB_BADMEM not working at all on 64-bit machines
17:20:32 <tomman> Anyway, it seems memmap= works, after figuring out how to translate the badmem= entries
17:20:37 <njsg> if you have this information handy, can you say here the grub version, anything specific about how grub got built, oh and the machine architecture too - amd64, I presume?
17:21:06 <njsg> tomman: doesn't help in any way, but kind of related to badmem vs. memmap https://github.com/memtest86plus/memtest86plus/issues/288
17:23:35 <tomman> it's whatever GRUB2 version ships with Debian Bullseye
17:23:36 <tomman> grub-pc:amd64/bullseye 2.06-3~deb11u5 uptodate
17:41:07 <njsg> how's it booted, UEFI or PC BIOS?
18:13:00 <tomman> njsg: good ol' legacy boot
18:14:36 <tomman> Well, I think I've blackholed the bad memory zone
18:14:49 <tomman> just to be safe I made a 1MB memory hole around that space
18:15:05 <tomman> let's see how well it stands... until I get the chance to buy moar RAM
21:18:48 <tomman> > user: [mem 0x00000000a00f2000-0x00000000a01f1fff] reserved
21:18:50 <tomman> a whole megabyte of RAM that Shall Not Be Touched Ever Again™
21:19:56 <tomman> the magical enchant turned out to be "memmap=1M$0x00000000a00f2000" through the kernel boot args
21:20:35 <tomman> (the actual size of bad RAM spots there was much smaller, but eh, I'll survive without that chunk large enough to run another instance of MS-DOS :D )
21:22:30 <njsg> WIN.COM might need more memory, though :-P
21:26:28 <tomman> dunno, I think Windows 1.0 might run in 1MB RAM
22:15:53 <frg_Away> 640K ought to be enough for anybody.
23:57:29 <tomman> https://news.ycombinator.com/item?id=36370725 oh god, Google is deploying Infiniscroll™
23:58:21 <tomman> fortunately they're A/B'ing it, and I haven't won that lottery yet