07:47:36 jbk: that works ok, so if you have ideas for what to poke at... :) 14:03:35 also, (I might have missed it), are you trying to use a relatively recent (anything this year) version of smartos? 14:06:06 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? 14:09:30 ok.. so the sata deadlock fix should be there 14:53:01 if I/O keeps timing out, i wonder if something goofy with interrupts is going on... 15:48:50 wiedi: are you familiar with creating boot modules? (e.g. booting w/ custom /etc/system)? 15:49:01 (could also be done w/ kmdb) 15:51:00 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) 16:08:08 @jperkin seems it does not compile (anymore), well go-carbon that is the go-carbonapi does 16:08:21 Don't know enough go to know if it's easy ti fix 16:11:14 sjorge: am I missing context? fwiw @foo doesn't notify me 18:02:20 Aha then yes you probably are 18:02:36 I though we had go-carbon and go-carbonapi in pkgsrc but couldn't find it 18:03:03 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 18:10:24 yeh I don't see it and there's no CHANGES entry for it 18:15:44 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. 18:16:24 For interrupts it looked like this https://frupic.frubar.net/shots/43476.png - and https://frupic.frubar.net/shots/43470.png which only shows one of the three controller doing something 19:28:49 do we have some utility function to parse numeric value with units (k,m,g)? 19:39:33 ZFS has zfs_nicestrtonum 19:40:10 (libcmdutil has nicenum which goes the other way, and I believe ZFS has a variant of that as well) 19:46:52 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. 19:49:28 tsoome: What do you want it for? That might be the motivation to get me to get back to that. 19:49:48 https://www.illumos.org/issues/15711 19:49:49 → BUG 15711: snoop capture into rotating output files (In Progress) 19:54:55 rmustacc: Thanks for pointing me at ulwp_t the other day. 19:55:11 Oh yeah? That helping with something? 19:56:01 I think I have a way to replace calls to uselocale(NULL) in libc with a single instruction on i386/amd64. 19:56:35 at the cost of making setlocale() slightly slower. 19:59:03 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. 19:59:04 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? 19:59:10 bingo 19:59:28 Do you even need the byte? 19:59:34 move the complexity to the place where it doesn't happen often. 20:00:00 that's an open question. 20:00:34 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) 20:00:54 In my head I feel I can get away without it, 20:00:56 and there's a free byte in ulwp_t 20:01:01 But I'm not sure how clever I'm being in my head. 20:01:33 (I also don't trust my head that much) 20:01:40 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. 20:02:35 I didn't see a generic internal flags field in ulwp_t either but I might have missed something. 20:02:46 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(). 20:03:30 Actually, will they be the same locale_t? 20:03:51 Even though they refer to the same data, won't it be a distinct locale_t returned by newlocale()? 20:04:10 you might be able to get away with "if (ulwp->ul_locale == oldlocale) ulwp->ul_locale = newlocale;" 20:04:16 The data is cached, but not the locale_t. 20:05:00 i haven't looked too far under the covers yet. 20:05:01 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. 20:05:45 I guess the ulwp_t doesn't have a flags member. Probably worth just sticking this as a bit on one of them. 20:05:53 It also makes the post mortum experience smoother. 20:07:20 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. 20:07:55 looks like ulwp_t has a bunch of char-containing-boolean fields. 20:08:57 the code necessary to walk the threadlist is mercifully small. 20:09:05 And it's fork safe? 20:11:12 I think so - will have to take a closer look. Might leak locales in the child. 20:11:16 https://gist.github.com/Bill-Sommerfeld/f9ad1554ac5537c69d1574bb1da5023c 20:12:19 I copied the lock/loop structure from the thread fork hooks so it should play nice with that. 20:13:41 Hmm. I guess we'll maybe want to test what happens with racing setlocale / fork. 20:17:54 https://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html says "The setlocale() function need not be thread-safe." so application expectations are hopefully low... 20:33:20 a thing to check on top of the standards is whether anyone else's is safe 20:34:04 because we're firmly in a world now where it doesn't matter if the standard says we can, if nobody else does. 20:34:43 Linux is firmly in the "setlocale() is not thread-safe" camp. 20:34:58 or perhaps more correctly, glibc is. 20:35:19 https://www.gnu.org/software/libc/manual/html_node/Setting-the-Locale.html#index-setlocale 20:43:29 stack exchange best practice appears to be "don't call setlocale() with a non-NULL locale after you've created a thread" 20:51:44 OK, I'm likely worrying too much about this stuff. 20:54:56 there are inherent and likely unfixable data races when the global locale is set. 20:55:46 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. 20:57:08 I think we can avoid nasal-daemon-level undefined behavior 21:02:06 I'm considering setlocale() vs thread creation races, to avoid a thread getting stuck with an old global locale. 21:05:11 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. 21:05:38 the thread will be suspended and unable to do anything at that point in time. 21:09:17 actually, yes, that's right. (I didn't see that threads start suspended by default and have to be released). 21:09:46 gotta run for a bit. 21:16:20 [illumos-gate] 15701 vr: the comparison will always evaluate as 'false' -- Toomas Soome 21:23:37 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. 22:54:06 [illumos-gate] 15689 nvme: race between detach and removal callback -- Robert Mustacchi