02:01:20 <GrayJack> Hey good people! How are you doing?
02:03:09 <GrayJack> I have a question. Looks like `geteuid` and `getegid` are no syscalls, but they are listed in the man pages, where I can find the implementation of those functions?
02:06:34 <rmustacc> It's in libc and is a syscall: https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libc/common/sys/getegid.S
02:12:52 <GrayJack> Oh! I put a filter on my search thats kiped asm files!
02:13:41 <GrayJack> So it is just `getegid` is just get `getgid` under the hood
02:27:43 <GrayJack> I'm unable to see the difference between `SYSTRAP_RVAL1` and `SYSTRAP_RVAL2`. Both are expanding to the same thing
02:35:25 <sommerfeld> GrayJack: the difference is in RET vs RET2
02:39:04 <iximeow> sommerfeld: you wouldn't happen to know what the difference is between SYSTRAP_RVAL1/SYSTRAP_RVAL2, would you? i see they're defined the same on sparc/i386/amd64, so maybe it's just implying that we'd expect to see a RET2 consuming the second return value from the syscall?
02:39:18 <sommerfeld> GrayJack: as you have no doubt figured out, the actual trap returns both getuid() and geteuid() values (in different registers).  there may well have been an architecture where something needed to be different between SYSTRAP_RVAL1 and SYSTRAP_RVAL2 but none of the current architectures require anything to differ.
02:39:31 <iximeow> ah, well. thanks for reading my mind :)
02:40:34 <sommerfeld> aha, found a place where they're different: 32-bit x86
02:41:53 <sommerfeld> on processors with SYSENTER, it's faster but it can only return one value
02:42:10 <sommerfeld> so the SYSTRAP_RVAL2 path is slower in that case.
02:42:33 <sommerfeld> see usr/src/lib/libc/i386/inc/SYS.h
02:44:56 <iximeow> i think it's that sysenter requires a particular value in edx, so for sysenter to be used in SYSTRAP_RVAL2 it would require a different ABI. quite awkward
02:45:17 <iximeow> err, "sysenter"->"sysexit"
02:50:39 <jbk> i know this has been answered before, but since we only run on 64-bit cpus now, are there any cpus where we run that don't support it?
02:52:52 <GrayJack> Thanks sommerfeld! This is very different from the BSDs and Linux, I think it's kind of neat
03:15:25 <rmustacc> I hsould caveat that some of the design there may change depending on how we approach some of the poxis getresxid changes.
03:27:05 <GrayJack> Looks like RET2 always use `rdx` (on x86_64) for the rval2
03:28:20 <GrayJack> Do I have adapat calls for syscalls with 3 or more arguments or it is ok to use `rdx` as a inout register
03:29:58 <GrayJack> As this register is used for the third argument acording to the x86_64 syscall ABI
03:38:09 <iximeow> i don't know the illumos syscall ABI but note this is a return value not argument for the call
03:38:43 <iximeow> in that way it's more similar to the SysV ABI's return values in rax-maybe-with-rdx-as-extra for large structs
03:39:54 <iximeow> oh right, the linux amd64 ABI also specifically mentions rdx as the second return register (though it's the third argument register)
03:47:01 <GrayJack> Oh, I didn't know!
03:48:44 <GrayJack> TIL. I should have read the Sys V ABI more carefully last time
03:49:21 <iximeow> it is, unfortunately imo, an underutilized ABI detail :)
03:50:46 <GrayJack> In my defence, back then, I was still undiagnosticated for my ADHD. so my attention span was not even close to good when I wanted to finish something fast LOL
04:02:20 <GrayJack> I wonder how is that on aarch64 (one of my main machines are aarch64, and I never though on that for another exploration project I did)
15:28:40 <jbk> hrm.. this is maybe interesting... pulling a hotplug nvme device on this dell box is causing a pcie fatal error and panic...
17:08:59 <jbk> rmustacc: i know you and jordan did a lot of work in that area, is there any known issues (or maybe bits not upstreamed yet) to be aware of before I dive too deeply into this?
18:46:55 <rmustacc> I don't think we have anything that's not upstream off hand. I'll check.
18:47:24 <rmustacc> In general, there are a lot of different ways you can set up the fatal status registers and I think there's opportunity to make PCIe fatal errors less OS-wide fatal.
18:47:48 <rmustacc> It'll depend a lot on the specifics, whether it's poison, just a transaction that'll never complete, etc. and eventually getting things all the way up the stack.
18:48:17 <rmustacc> Part of the changes that folks have done here is to try to offer up downstream port containment to make this not as bad, but that requires a bunch of other infra and more driver reset logic.
19:13:20 <jbk> i'll need to see if maybe I can get a non-NVMe disk attached to this box (for a dump, doesn't work well when the dump device is on the disk that's removed :P)
19:14:58 <rmustacc> If you end up in kmdb walking the ereport pending queue and using ::ereport -v will get you 90% of the way.
19:15:03 <rmustacc> The dump itself won't be too powerful.
19:18:03 <jclulow> FYI: I'm going to take Redmine down for a few minutes at 1930Z (~13 minutes from now) to move the database around for upgrades
19:25:31 <jbk> this is what you see on the console https://pastebin.com/BCqM3qPP
19:25:38 <richlowe> jclulow: <good luck, we're all counting on you.gif>
19:25:52 <jclulow> lol richlowe thank you
19:26:03 <jbk> ok.. i'll see what I can get from kmdb
19:26:16 <jbk> richlowe: surely you mean .jpg
19:26:17 <jbk> :P
19:26:55 <jclulow> jpegs don't MOVE jbk come on
19:27:28 <jbk> well i needed something to setup the obvious reply
19:30:54 <jclulow> I'm too tired for jokes that depend entirely on US accents haha
19:32:02 <jbk> it's arguably the most memorable line from the movie
19:49:16 <jclulow> Alright, Redmine should be working again for now
19:49:48 <jbk> ... and retrying it didn't cause a panic this time...
19:50:04 <jbk> ahh the heisenbugs...
19:56:29 <rmustacc> jbk: It's probably going to depend on what outstanding transactions are running to the device and the exact timing unfortunately.
19:56:40 <rmustacc> Not all PCIe transactions are equal.
20:06:42 <richlowe> it is a great shame that the only way to learn this is in detail to have the expensive specs, or to buy the less-expensive book that is basically a clean-room of the specs.
20:07:47 <richlowe> I will never not be unhappy that the pci-sig still exists
20:08:44 <rmustacc> It's definitely annoying. If we can do more to help the docs in illumos, let me know what I can do and I'll try my best.
20:11:27 <wiedi> what's the less-expensive book called?
20:15:06 <jbk> i should bug my friend's dad if he has anything...
20:15:43 <jbk> he did write a book on PCI (not PCI-e -- this was late 90s) hot plug and IIRC still I think works at HPe on PCI stuff...
20:19:29 <richlowe> "PCI Express System Architecture" I think -- I don't have a copy
20:19:51 <richlowe> not that I'm _saying_ it turns out to be easier to steal an older copy of the relevant standard, but you could certainly check
20:20:24 <wiedi> thx :D
20:24:14 <jbk> hmm.. ok.. there are some entries in the fma error log (and fma did retire the disk).. i'll see if I can figure out where those are getting generated
20:27:34 <jbk> hrm... now cfgadm shows the condition as faulted, but can't seem to clear it..
20:27:41 <jbk> (after re-inserting the disk)
20:48:54 <jbk> somewhat related, should fmd enumerate any status leds (fault, power, etc)? I didn't see anything in teh pcibus module to do it, but might be looking in the wrong spot
20:50:22 <jbk> err status leds for hotplug pci devices
20:50:31 <jbk> (e.g. nvme)
20:59:43 <richlowe> I believe it does, but not how you might expect.
20:59:53 <richlowe> rmustacc and jclulow at least know the details
21:00:50 <richlowe> because I've complained about the various possible LED configurations v. hotplug configurations, and then asked why oxide does something else again
21:05:28 <rmustacc> I don't believe fmd is going to enumerate any leds for those on i86pc by default.
21:05:37 <rmustacc> It will depend on what mechanism your hardware platform is even using.
21:06:03 <rmustacc> While we cleaned up and made it much easier to use the standard PCIe slot registers for this, whether or not they are present or even wired up correctly depends on the hardware platform.
21:06:20 <jbk> this is dell, so i'm not going to hold my breath :)
21:09:17 <richlowe> that probably covers the "not how you might expect", thanks rmustacc.
21:11:12 <rmustacc> So for example on AMD SP3 systems basically the enterprise ssd hotplug method doesn't plumb LEDs into the standard slot registers.
21:11:24 <rmustacc> We found most off the shelf systems sometimes used that.
21:12:17 <rmustacc> So we mostly use the standard mechanism; however, where we're different is that we don't have a different attention and power LED.
21:12:28 <rmustacc> We just use a single LED where as a standard PCIe slot has the two.
21:12:59 <rmustacc> If the Dell platform is Intel based, I'm less sure what'd happen. But I'd expect the LEDs were probably controlled through the DRAC, though you could experiment with the hotplug command and service to see if it is there.
21:18:11 <rmustacc> Sorry, I wish it was better, but it's still kind of a mess out here.
21:18:56 <jbk> I know a lot more than I did this morning, so it was helpful
21:19:09 <rmustacc> Unfortunately while PCIe has also introduced a bit around enclosure management, LEDs are out of scope.
21:19:23 <jbk> I (foolishly) hoped that maybe it was a quick fix, but sounds like we might need to spend a bit of time to make things work on this system
21:19:34 <rmustacc> The simplest way to see if the indicators are controlled through the spec is to use pcieadm on the root ports and look at the slot capabilities register.
21:19:45 <rmustacc> Which Dell platform if you can share?
21:23:49 <jbk> it's something recent (though I'm always bad about keeping track of model names).. let me see if I can find it...
21:25:35 <rmustacc> smbios will tell you it.
21:25:40 <richlowe> rmustacc: out of pure academic interest.  Can the cap register be relied on to mean that it actually does something?
21:25:59 <rmustacc> Uh... in theory?
21:26:04 <richlowe> rmustacc: I have a lot of "To Be Filled In By O.E.M" systems, does fma support those? :)
21:26:26 <rmustacc> I generally have not found folks lying about the PCIe slot status register.
21:26:59 <rmustacc> I have once or twice found surprises around power control.
21:27:16 <rmustacc> But on AMD I think very few folks give you power control so generally when it's there it works.
21:27:35 <jbk> poweredge r660
21:29:30 <rmustacc> Ah, Intel based so I have even less of an idea of what they have on that platform.
21:52:43 <twobitsahead> Hello, I am attempting to sign up at https://www.illumos.org/account/register
21:53:03 <richlowe> jclulow: ^^^
21:53:08 <twobitsahead> I completed the form and did not receive a confirmation email. Resent the confirmation email and still did not receive it
21:53:43 <twobitsahead> Disregard^
21:54:19 <jclulow> all good?
21:54:34 <twobitsahead> As luck would have it, they arrived now. There was a six minute delay, so I had assumed that the form had failed in some way
21:54:41 <twobitsahead> Yes
21:54:43 <twobitsahead> Thanks
21:55:23 <jclulow> You're welcome!
21:57:51 <twobitsahead> I am Guest34 from yesterday who mentioned the Perl path issue while building illumos-gate
21:58:23 <jclulow> Welcome back!
21:58:30 <twobitsahead> Thank you!
21:58:42 <jclulow> We've updated the docs on the site since then, I think, so hopefully the perl stuff is fixed there
21:58:44 <twobitsahead> I noticed that the illumos help page had been updated and
21:58:48 <jclulow> Yeah
21:58:52 <twobitsahead> Yes
21:58:59 <twobitsahead> I just compiled it again
21:59:07 <twobitsahead> Or rather, just compiled it
21:59:56 <twobitsahead> The mail_msg shows a cropped version of the error message from yesterday, still referencing the */amd64/perl and */i386/perl paths
22:00:25 <twobitsahead> Although it seems that the build passed, at least seemingly in line with the documentation I am reading through
22:00:54 <jclulow> Can you gist/pastebin the mail_msg
22:02:27 <twobitsahead> I was disconnected
22:03:04 <twobitsahead> testing
22:03:25 <twobitsahead> Oh, the leading slashes aren't playing nice with Libera, it seems
22:03:57 <twobitsahead> I was writing out that ./log/latest/proto_list_i386 and ./packages are now present, unlike the failed build from yesterday
22:04:15 <jclulow> That's a good start!  Can you gist/pastebin the mail_msg
22:04:26 <twobitsahead> gist/pastebin
22:04:30 <twobitsahead> What is this?
22:04:36 <twobitsahead> If you don't mind
22:05:07 <sommerfeld> website which lets you upload a short (or long) snippit of text and give it a URL that you can paste into IRC
22:05:18 <sommerfeld> there are many such out there
22:06:23 <twobitsahead> Yes, I can post it
22:06:27 <twobitsahead> Just a moment
22:13:03 <twobitsahead> I did the build within a zone and am not sure how to access the mail_msg file from Gist. I'll need a little while to figure this out
22:14:56 <jbk> twobitsahead: are you fairly comfortable with git? I'd need to find the info, but gists themselves are stored as git repos, so you could just clone + copy + commit + push to github
22:53:20 <sommerfeld> twobitsahead: also leading slashes don't play well with any IRC system as all IRC commands start with /
23:12:35 <jclulow> alanc: What does iovec look like for you, now?  i.e., https://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/sys/uio.h?r=b4203d75#62-76
23:48:33 <alanc> mostly the same, except we changed #if	defined(_XPG4_2) to #if !defined(__USE_LEGACY_PROTOTYPES__)
23:48:59 <alanc> and changed IOV_MAX to 1024
23:50:03 <jclulow> Makes sense
23:50:05 <jclulow> thansk
23:50:07 <alanc> yeah, hg annotate says other than the ifdef lines, the rest of the lines haven't been changed since OpenSolaris Launch (blame stevel)
23:50:07 <jclulow> *thanks