10:50:42 A good place to check for historical runs is the weekly merge PRs, I'll take a look. 10:53:04 hadfl's build times have been 36:02 (2nd of June) 35:40 (29th) and 35:35 (8th of July) 17:30:03 my builds have been ~1:05 consistently in early june, but ~1:12 now 17:30:07 I just went back to the old BE, and the build time got better. 17:30:12 but I can't see any evidence of _why_ 17:30:53 Can you break it down by phase from mail_msg? 17:31:29 not in a way that helps 17:31:43 the "build time" time stamp only got 2 minutes longer 17:31:52 I'm not user the tools build would hold up to the rest. 17:31:56 s/user/sure/ 17:33:36 for my last two builds from before/after I went back to the june 9th BE: full time new BE: 1:11:23, old be: 1:03:16. "elapsed build time" new BE: 57:03.1 old BE: 54:24.2 17:35:01 normally I'd ignore it, but I'm both desparate to confirm it's not my fault in my project work, and worried because last time it felt off but I didn't check, was the gcc thing you fixed 17:35:28 We've definitely had build time regressions in the past, which is how I know to go and look at the ~weekly PRs 17:35:30 so I wanted to at least report, and see if anyone else could reproduce/had noticed/something. 17:35:52 It doesn't look like we've had any on those omnios upstreaming builds 17:41:02 thanks 18:15:03 andyf: does the non-hotload version of loading the microcode persist across reboots, or is this something where to remain safe you must stay on up-to-date versions of illumos (or Linux or whatever)? I just want to be certain before advising anyone else. 18:15:32 wrong channel. sigh 18:16:01 gonna move my question to #illumos for the sake of posterity. 18:43:19 There will be an OmniOS update in a day or two to get this loaded during boot, but it has to get through review and testing.