11:34:55 andyf: dilos is steel active, but have no updates on site :) but has updated apt repo :) 13:11:41 vab: I have a T5120 that's a perfect candidate for OI testing. I thought SPARC support being killed in upstream illumos meant OI was also killing it, though 13:56:05 KungFuJesus: THanks to the effort of ptribble and klaus SParc is being kept alive in a fork. If you send me your mail, I'll gladly put you in contact with Klaus 14:09:00 awesome, my T4 is also EOL with Solaris upstream 14:11:15 I also have a sunfire v240 with a GPU that might make a viable X11 based testbed 14:12:35 I _think_ it's just the crappiest available common ATI rage card, so it's probably relegated to very unaccelerated fb only drivers, but...hey, it's something 17:32:57 Solaris still supports T4, it was T1-T3 that were EOL'ed 17:51:23 KungFuJesus: most of the sparc stuff is being done by Peter Tribble 17:51:34 you might want to look at tribblix/talk to ptribble when he's on IRC about it 17:54:53 alanc: Hmm, for some reason I remember the upgrade path past 11.3 being impossible 17:55:32 that's when T1, T2, & T3 were dropped 17:55:38 KungFuJesus Klaus has a V240 where he does a lot of dev work. Even gcc 11 is working. :-) 17:56:28 hmm, I swear pkg upgrade was failing for me for some reason 17:56:54 vab: does that mean he fixed the system call issues? I imagine Peter would be interested in that 17:57:40 in any case it would be nice to have an illumos distribution on those guys given that the support cycle is probably on the tail end, anyway 17:58:20 I might finally write some VIS3 accelerated routines for zlib-ng, hah 18:00:15 The V240 might also make for a good testbed for big endian fixes in mesa, too. That way I can decipher if it's just a nouveau issue or a core mesa problem 18:04:12 of course llvmpipe gets me a lot of that too, but it doesn't always exercise the same paths 18:07:23 pkg upgrade could fail for reasons other than CPU support 18:09:30 wait, like what? 18:09:39 I mean, obviously it could, but I thought if you were on the beaten path that should just always work 18:09:40 for y'all 18:11:46 like installing third party packages that depend on stuff we obsoleted, or playing around with version-lock facets or freezes 18:13:01 oh, ah. 18:13:04 or if you're not using the support repo, the 11.3 -> 11.4 upgrade will fail because the upgrade requires things that are only in 11.3 support repo be installed first 18:13:05 I thought you meant in the general scheme of things. 18:13:17 though that last line seems like just something you shouldn't have done 18:13:48 but I guess that depends on whether you convinced customers to bother doing upgrades, yet. 18:13:52 it's only been 15 years 18:14:07 many people argued for the "bunny hop" bits to be placed in the /release repo too but they were unsuccessful 18:14:45 (it's a new version of pkg that understands some new attributes used in the 11.4 packages, and some ON changes I forget) 18:16:19 it's definitely something I can't imagine shawn doing willingly 18:16:28 richlowe Sorry, been out of the loop for a while... what system call issues are there? 18:16:52 Currently the problem is that the T5440 I gave him will happily run with three CPU and memory boards. 18:17:10 Once he puts the last in, it fails. 18:17:20 https://www.illumos.org/issues/2757 18:17:21 → BUG 2757: 32bit sparc direct system calls should not rely on compiler mannerisms (In Progress) 18:18:15 module /platform/SUNW,T5440/kernel/sparcv9/unix: text at [0x1000000, 18:18:15 0x10e14e5] data at 0x1800000 18:18:15 module /platform/SUNW,T5440/kernel/sparcv9/genunix: text at [0x10e1500, 18:18:15 0x13051bf] data at 0x1936ac0 18:18:15 module /platform/SUNW,T5440/kernel/misc/sparcv9/platmod: text at 18:18:17 [0x13051c0, 0x13051cf] data at 0x199ed60 18:18:20 module /platform/SUNW,T5440/kernel/cpu/sparcv9/sun4v: text at 18:18:22 [0x13051e0, 0x1307c4f] data at 0x199f300 18:18:25 OpenIndiana Hipster 2023.04 Version illumos-69019bc162 64-bit 18:18:27 Ethernet address = 0:14:4f:a0:81:1a 18:18:30 ERROR: Last Trap: Fast Data Access MMU Miss 18:18:43 I'll ask him. He's not usually in irc/libera. 19:54:34 [illumos-gate] 15254 %ymm registers not restored after signal handler -- Robert Mustacchi 19:54:59 rmustacc: congrats, and thank you. 20:02:44 Thanks. Next we'll have to do the stack improvements, but this should help at least folks and reduce a bunch of gnarly corruption. 20:11:09 Woo! 20:53:49 I feel like there's a way to wait for an SMF service, manually, and I have forgotten what it is. 20:53:59 does that ring any bells for anyone? 20:54:09 the equivalent of pwait(1), but for a service FMRI to come online 20:55:00 like svcprop -w or whatever it is? 20:55:13 There's a syncronous start... 20:55:19 jlevon: that seems to be for properties only 20:55:34 nahamu: I am just wanting to wait for the system to calm down after booting, for eg, by waiting for multi-user-server to come online 20:55:37 richlowe: yeah but you watch for the state like svcadm -s does no? 20:55:39 remember ssh, console-login, etc, start before that. 20:55:43 jlevon: clever! 21:00:37 You may be able to just drop a svcadm enable -s as well? 23:07:29 hello, installed the latest OpenIndiana and stuck without internet. dhcpagent spams "select_best: no valid OFFER/BOOTP reply". meanwhile I check logs on my router and it sends offer response to pc, also I checked 67 and 68 ports on pc using snoop, and I can see, that some information(including interface hostname that I assigned) comes back to the 23:07:30 OpenIndiana pc. somehow it can't get IP address. Trying to fix this few hours in a row, any help is appreciated 23:14:48 any other warnings? https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/cmd-inet/sbin/dhcpagent/request.c#L455 is the code used to "score" an offer. 23:15:01 look at the options found in the OFFER 23:15:36 it will reject offers missing a lease time or a server id. 23:16:53 the message you quoted comes from select_best() in the same file; I suspect it's hitting the "compute_points_v4 returns -1" path. 23:24:18 so, I checked and server definitely provides with server id, and regarding lease time, it sends address-time (equals 600). when you mentioned time, I have wrong location/time set on pc, maybe it has something to do with offer expiration. let me try to fix time 23:25:36 ps: sever has lease time in settings, so I assume it sends it as well 23:53:02 best to actually look at what options appear on the wire in the OFFER message. a 600s lease is on the very short side. snoop -v will decode options.