jbk: that works ok, so if you have ideas for what to poke at... :)

also, (I might have missed it), are you trying to use a relatively recent (anything this year) version of smartos?

yep latest, also tried with a release from 2020 but no difference. We got it installed with disable-ahci so at least we have network but are wondering if there's a trick to enable the module afterwards again?

ok.. so the sata deadlock fix should be there

if I/O keeps timing out, i wonder if something goofy with interrupts is going on...

wiedi: are you familiar with creating boot modules? (e.g. booting w/ custom /etc/system)?

(could also be done w/ kmdb)

i'm wondering if setting sd_io_time to 10, sa_ua_retry_count=3, might be enough to let the system boot w/ the driver loaded (so more direct debugging could occur)

@jperkin seems it does not compile (anymore), well go-carbon that is the go-carbonapi does

Don't know enough go to know if it's easy ti fix

sjorge: am I missing context? fwiw @foo doesn't notify me

Aha then yes you probably are

I though we had go-carbon and go-carbonapi in pkgsrc but couldn't find it

Since it go, I did a simple go get and noticed it doesn't compile, so it probably was never there or it broke at some point

yeh I don't see it and there's no CHANGES entry for it

jbk: re boot modules - not really. But with milestone=none we got it far enough to have a shell and run mdb and other things. Loading the driver after booting with disable-ahci=true would still be convenient as that also gives us networking etc.

For interrupts it looked like this frupic.frubar.net/shots/43476.png - and frupic.frubar.net/shots/43470.png which only shows one of the three controller doing something

do we have some utility function to parse numeric value with units (k,m,g)?

ZFS has zfs_nicestrtonum

(libcmdutil has nicenum which goes the other way, and I believe ZFS has a variant of that as well)

tsoome: I was going to rewrite one the other way with some flags recently because I hit the terror of mkfile and it not supporting T.

tsoome: What do you want it for? That might be the motivation to get me to get back to that.

→ BUG 15711: snoop capture into rotating output files (In Progress)

rmustacc: Thanks for pointing me at ulwp_t the other day.

Oh yeah? That helping with something?

I think I have a way to replace calls to uselocale(NULL) in libc with a single instruction on i386/amd64.

at the cost of making setlocale() slightly slower.

so curthread->ul_locale would always point at "the current locale", with a separate byte marking whether or not it was a global or thread-local locale.

Basically just always return the locale_t from the ulwp_t and iterate over all the threads while calling setlocale() to update the pointer if it was pointing to the global one?

bingo

Do you even need the byte?

move the complexity to the place where it doesn't happen often.

that's an open question.

it's needed if you want to preserve existing behavior (which is that setlocale changes the locale in threads that haven't set one themselves)

In my head I feel I can get away without it,

and there's a free byte in ulwp_t

But I'm not sure how clever I'm being in my head.

(I also don't trust my head that much)

I think you need a bit *somewhere*. you could stuff it in the low order bit of the pointer but then the reader has to mask it off.

I didn't see a generic internal flags field in ulwp_t either but I might have missed something.

Ah, yeah. I'm a bit off in that if I setlocale() and uselocale(newlocale()) the same thing the latter shouldn't change on a subsequent setlocale().

Actually, will they be the same locale_t?

Even though they refer to the same data, won't it be a distinct locale_t returned by newlocale()?

you might be able to get away with "if (ulwp->ul_locale == oldlocale) ulwp->ul_locale = newlocale;"

The data is cached, but not the locale_t.

i haven't looked too far under the covers yet.

I don't think it's worth the clarity cost to save the byte, but I think it's just that with oldlocale being the old global locale.

I guess the ulwp_t doesn't have a flags member. Probably worth just sticking this as a bit on one of them.

It also makes the post mortum experience smoother.

I'll be happy to take a look when you have something. I guess the biggest thing will be to hold all the ulwp's to update.

looks like ulwp_t has a bunch of char-containing-boolean fields.

the code necessary to walk the threadlist is mercifully small.

And it's fork safe?

I think so - will have to take a closer look. Might leak locales in the child.

I copied the lock/loop structure from the thread fork hooks so it should play nice with that.

Hmm. I guess we'll maybe want to test what happens with racing setlocale / fork.

pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html says "The setlocale() function need not be thread-safe." so application expectations are hopefully low...

a thing to check on top of the standards is whether anyone else's is safe

because we're firmly in a world now where it doesn't matter if the standard says we can, if nobody else does.

Linux is firmly in the "setlocale() is not thread-safe" camp.

or perhaps more correctly, glibc is.

stack exchange best practice appears to be "don't call setlocale() with a non-NULL locale after you've created a thread"

OK, I'm likely worrying too much about this stuff.

there are inherent and likely unfixable data races when the global locale is set.

Yeah, I know some of it is unavoidable. But I think if I'm not calling into things that use the locale, one would be forgiven for believing otherwise.

I think we can avoid nasal-daemon-level undefined behavior

I'm considering setlocale() vs thread creation races, to avoid a thread getting stuck with an old global locale.

I think as long as you capture it at the time that _thrp_create() does its lmutex_lock of the link lock, you should be good.

the thread will be suspended and unable to do anything at that point in time.

actually, yes, that's right. (I didn't see that threads start suspended by default and have to be released).

gotta run for a bit.

[illumos-gate] 15701 vr: the comparison will always evaluate as 'false' -- Toomas Soome <tsoome⊙mc>

jperkin ack, I couldn't find the older python one either so I wonder how I was running that at one point. Maybe I somehow compiled it myself.

[illumos-gate] 15689 nvme: race between detach and removal callback -- Robert Mustacchi <rm⊙fo>