04:58:00 hrm.. this is annoying 04:58:12 if you boot into kmdb on aws, and try to reboot from it, the VM hangs 04:58:25 normal reboot (init 6) seems fine 05:34:36 jbk: Huh! As in, $q from kmdb or whatever? 05:34:43 What instance type is this? 05:35:00 Also, I guess: BIOS or EFI boot? 10:52:30 I was doing this a lot recently in a UEFI-booted instance. I was probably doing just ^D to reboot after ending up in kmdb. 12:22:09 https://comsec.ethz.ch/research/dram/zenhammer/ 12:22:22 probably you already know it 14:07:08 yeah $q from kmdb 14:07:14 it's a nitro instance (UEFI) 14:08:00 later investigation (it was pretty late) suggests it didn't actually lock up, but took several (like 5+) minutes to reset, which still feels wrong (esp if a regular reboot is fine) 14:32:46 i've never really dug into that aspect to know what difference (if any) there is 15:19:14 That definitely seems unusual 15:21:36 yeah.. it feels like it's hitting some sort of timeout, though since any sort of HV diagnostic isn't available AFAIK, it's hard to know what's going on from that perspective 15:45:54 At least with the serial port you can probably emit some information about where you get up to 15:46:13 (by altering the code) 16:11:43 yeah.. might look into it after I'm done with this other stuff 17:47:51 Should I be worried if I see this on a zpool after running `zdb -C $POOL` ? 17:47:53 space map refcount mismatch: expected 841 != actual 838 18:44:17 [illumos-gate] 16416 64bit commands built in weird environments (like tests) avoid -msave-args -- Richard Lowe 19:40:08 hrm.. does a service need anything special in its manifest for it to exit with SMF_EXIT_NODAEMON and not have smf restart the service? 19:41:22 the duration type is 'child' and I wonder if that's maybe the problem 19:41:38 it appears to be exiting with the correct error value 20:02:12 jclulow: could I bug you or someone to refresh the index on src.illumos.org at some point? 20:57:35 a fun rust project might be to do some sort of opengrok replacement... 20:58:10 i have to think it's maybe doing a lot of unnecessary stuff or inefficient for it to take days to index illumos-gate, freebsd, and the linux kernel 20:58:33 when you could compile all of them tens of times (if not more) over with the same compute resources 20:58:43 in the same amount of time 21:20:06 [illumos-gate] 16323 pynfs/nfs4.1: SEQ7 st_sequence.testTooManyOps : FAILURE -- Vitaliy Gusev 21:45:29 jbk: on the other hand, parallelizing compilation of an OS source tree is straightforward; you can build "main" in 57 different subdirectories of usr/src/cmd in parallel without any interference. But when indexing, each "main" has to land in the same pile of references in the index. 21:45:42 this is not to say that the indexing can't be faster than it is. 22:54:45 https://twitter.com/jedisct1/status/1772647350554464448 22:59:26 jbk: though that's 31 rounds; the full hash has 64. 23:03:44 still sounds like it's a decent advance 23:03:51 i thought things had kinda stalled a while back 23:08:52 unclear. I haven't been following progress that closely, but https://eprint.iacr.org/2015/350.pdf - published 9 years ago - talks about 31-round collisions. 23:44:54 may just be that they're finding 31-round collisions faster.