hrm.. this is annoying

if you boot into kmdb on aws, and try to reboot from it, the VM hangs

normal reboot (init 6) seems fine

jbk: Huh! As in, $q from kmdb or whatever?

What instance type is this?

Also, I guess: BIOS or EFI boot?

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.

probably you already know it

yeah $q from kmdb

it's a nitro instance (UEFI)

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)

i've never really dug into that aspect to know what difference (if any) there is

That definitely seems unusual

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

At least with the serial port you can probably emit some information about where you get up to

(by altering the code)

yeah.. might look into it after I'm done with this other stuff

Should I be worried if I see this on a zpool after running `zdb -C $POOL` ?

space map refcount mismatch: expected 841 != actual 838

[illumos-gate] 16416 64bit commands built in weird environments (like tests) avoid -msave-args -- Richard Lowe <richlowe⊙rn>

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?

the duration type is 'child' and I wonder if that's maybe the problem

it appears to be exiting with the correct error value

jclulow: could I bug you or someone to refresh the index on src.illumos.org at some point?

a fun rust project might be to do some sort of opengrok replacement...

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

when you could compile all of them tens of times (if not more) over with the same compute resources

in the same amount of time

[illumos-gate] 16323 pynfs/nfs4.1: SEQ7 st_sequence.testTooManyOps : FAILURE -- Vitaliy Gusev <gusev.vitaliy⊙gc>

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.

this is not to say that the indexing can't be faster than it is.

jbk: though that's 31 rounds; the full hash has 64.

still sounds like it's a decent advance

i thought things had kinda stalled a while back

unclear. I haven't been following progress that closely, but eprint.iacr.org/2015/350.pdf - published 9 years ago - talks about 31-round collisions.

may just be that they're finding 31-round collisions faster.