00:21:21 <gitomat> [illumos-gate] 16758 pci_enable_errors clobbers pcie_fabric_scan extended tagging -- Robert Mustacchi <rm⊙fo>
01:04:27 <gitomat> [illumos-gate] 16546 The find command should be able to find SIDs -- Bill Sommerfeld <sommerfeld⊙ho>
06:40:36 <tsoome_> jbk how is your 15907 going?:) I have been using it since published and have not seen any problems:)
13:46:07 <gitomat> [illumos-gate] 16766 SO_SNDTIMEO/SO_RCVTIMEO options broken for UNIX sockets -- Andy Fiddaman <illumos⊙fn>
13:46:07 <gitomat> [illumos-gate] 8891 One unmountable dataset on rpool breaks a lot of things -- Andrew Stormont <andyjstormont⊙gc>
14:03:37 <jbk> tsoome_: there were some issues w/ jumbo frames (which then revealed some bits that are not obvious -- no docs, etc), and we sometimes run into this situation where it works really well, then really poorly that we haven't been able to nail down
14:06:06 <jbk> it doesn't look like it's running out of any resources (i.e. pre-mapped DMA buffers), but not sure if maybe if something's a bit slow if it's maybe triggering adverse behavior upstack
14:06:16 <jbk> or at least, i haven't been able to eliminate that yet
14:07:03 <jbk> i suspect we're maybe just pushing more stuff to ESX than it can handle
14:07:13 <jbk> but haven't found a good way to confirm that...
14:08:10 <tsoome_> ah, ok I havent tested jumbos
14:09:09 <tsoome_> I was just walking my branches and found your update is still there:D
15:10:32 <jbk> speaking of that..
15:10:52 <jbk> i know someone (I can't recall who offhand) posted an update for ACPI a fairly long while ago
15:11:11 <jbk> i've been running that almost since it came out w/o issue
15:11:16 <jbk> maybe a few weeks to a month after
15:11:30 <jbk> i don't know if anyone else has been using it
15:11:51 <jbk> but might be nice to get it in if we feel it's had enough soak time
15:13:14 <jbk> (though at the same time, i suspect the most interesting things to look at would be to test it with newer systems with the thought that they would be more likely to want/need/utilize things in newer versions of the spec)
17:01:54 <tsoome_> well, atm my smartos on bhyve is spamming messages like: WARNING: cpupm_init: processor 18: unable to get ACPI handle
17:36:31 <jbk> oh, i haven't tried that change in a VM.. this is on my home server
17:36:35 <jbk> that runs smartos
17:37:00 <jbk> (I have a branch where I've applied that change + my in-progress TPM driver)
18:36:45 <tsoome_> ou, how far is your tpm driver btw?
18:39:02 <richlowe> tpm2, or virtual tpm, or?
18:42:07 <richlowe> also while I'm here.  I've exhausted my usual suspects:  Does someone have a sparc made after, say, 2009 that they're willing to send me `prtconf -pv` from? 
18:42:19 <richlowe> it might help if a matching `prtconf -d` is in there
18:42:26 <richlowe> (I sure wish `prtconf -pvd` worked somehow)
18:47:36 <tsoome_> richlowe asked friend of mine;)
18:48:33 <tsoome_> they have number of T8-2's in use...
18:52:38 <richlowe> thanks!
21:40:37 <gitomat> [illumos-gate] 16745 asy: rework asy(4D) register access and fix chip identification -- Hans Rosenfeld <rosenfeld⊙gho>
21:42:03 <gitomat> [illumos-gate] 16747 asy: support 16950 and compatible UARTs -- Hans Rosenfeld <rosenfeld⊙gho>
21:43:07 <gitomat> [illumos-gate] 16746 asy: improve PCI(e) device support -- Hans Rosenfeld <rosenfeld⊙gho>
21:44:33 <gitomat> [illumos-gate] 16752 asy: infinite loop in asyopen() -- Hans Rosenfeld <rosenfeld⊙gho>
22:21:38 <josephholsten> ugh, it's clearly been too long since I tried building illumos-gate. I'm following https://illumos.org/docs/developers/build/, I've got the omnios bits defined in illumos.sh, but I'm not getting a great error message out of nightly except `Warning: Target `install` not remade because of errors`. I've checked I've got 8GiB memory on the vm, anything obvious I should check before I start bisecting the build scripts with printfs?
22:24:07 <Woodstock> well, you can backtrack from the "not remade of errors" to the actual error in nightly.log
22:24:21 <iximeow> fwiw, when i'd gotten that i found some success searching for `***` (or `\*\*\*` depending how you're searching)
22:24:49 <iximeow> the last instance of that warning was very downstream from the first instance, which was much closer to the actual issue
22:25:16 <sommerfeld> yeah, search for the first *** and look immediately above it for error messages.
22:26:21 <Woodstock> sommerfeld: fyi, i updated https://code.illumos.org/c/illumos-gate/+/3662 with the 912600 baud bits, in case you want to resume reviewing :)
22:26:21 <fenix> → CODE REVIEW 3662: 16748 asy: support higher baud rates (NEW) | https://www.illumos.org/issues/16748
22:26:44 <josephholsten> grumble, well of course I found something obvious after asking.
22:26:49 <rmustacc> https://illumos.org/books/dev/workflow.html#diagnosing-build-failures
22:26:52 <rmustacc> Has some info.
22:26:58 <richlowe> 'Error code' is the key grep
22:27:43 <richlowe> adding `-w` to your `make` command line makes it a thousand times easier to work out where you are (and for your editor to, as well)
22:27:48 <josephholsten> rmustacc: ooh, I hope I'll break something interesting enough to need that this weekend
22:27:53 <rmustacc> Woodstock: what cables are you using that you're having trouble with?
22:28:21 <richlowe> one day I will get annoyed enough to make -w the default and add a tool to summarize your build errors
22:28:23 <rmustacc> FWIW, we have the AMD uarts running at 3 Mbaud to a USB receiver.
22:28:49 <josephholsten> ri
22:28:53 <sommerfeld> also see the flag day list at https://illumos.org/docs/developers/flagdays/ ; the March 2024 one may be related
22:29:48 <Woodstock> rmustacc: plain old null modem cables, around 1.5m or 2m long (that would be around 5 to 7 feet, if I'm not mistaken?)
22:30:13 <Woodstock> no shielding, no twisted pairs or anything, db9 on each end
22:30:17 <rmustacc> Hmm, okay. We end up using them to a USB receiver.
22:30:37 <rmustacc> But we also have hardware flow control on there.
22:30:56 <rmustacc> I'll have to double check our variant driver, but I believe we have to tweak clock settings elsewhere beyond just the UART driver to get it high enough.
22:31:47 <Woodstock> the flow control wasn't the issue, it was corrupted characters that I got. given that the corruption didn't look like typical line noise and also not like a baud rate mismatch I'd attribute them to crosstalk and reflections on the signal. I didn't bother to hook up my old scope to verify this, though :)
22:32:31 <josephholsten> richlowe: do I need to tweak nightly for that? I'm thinking build tooling might have some nice starting contributions, was thinking about https://github.com/richlowe/arm64-gate/issues/11 vs the illumos-gate build scripts to play with this weekend
22:32:32 <rmustacc> Assuming you know the device in question can do that, then it makes sense.
22:32:42 <Woodstock> with the standard 1.8432mhz clock you won't get much higher than 1843200 baud anyway :)
22:33:58 <rmustacc> Yeah. There's a separate 3 MHz clock in the AMD FCH. So our table looks like https://github.com/oxidecomputer/illumos-gate/blob/stlouis/usr/src/uts/oxide/io/dwu.c#L257-L291.
22:34:10 <sommerfeld> josephholsten: set MAKEFLAGS in your environment file.   I have `export MAKEFLAGS=wek` in mine.
22:42:49 <Woodstock> rmustacc: these serial lines you're using are not by chance using RS-422 signalling?
22:44:42 <rmustacc> No, we're not using RS-422. We had to bypass the level shifter on the board.
22:44:51 <rmustacc> Practically speaking, that could also be your problem.
22:45:35 <rmustacc> AMD implements a bog-standard designware uart for example, but most folks put some level translator on the board to get to RS-232 signalling.
22:46:10 <rmustacc> I guess I had forgotten that we bypassed the RS-232 level shifter on stock systems there and just don't put it on the board at all.
22:46:41 <Woodstock> so what kind of signalling do you get if you bypass the level shifter? just plain ol' ttl?
22:47:03 <rmustacc> Let me double check the EDS.
22:48:14 <rmustacc> SP3 and probably AM4 were all 1.8V single-ended signals.
22:48:55 <Woodstock> interesting
22:49:39 <rmustacc> But every traditionally puts an RS-232 level shifter on there to get you to the +/-12V and a lot of those tapped out at < 1 Mbaud.
22:49:50 <Woodstock> that makes sense
22:51:37 <Woodstock> one of the systems I acquired recently has a usb-c port for serial console, so there's a ftdi232 chip in there connected to the integrated uart. is that similar to what you're doing?
22:53:21 <rmustacc> We use things like the FT2232H or when we're limited to 1 Mbaud the UT232R.
22:53:41 <Woodstock> i see, that makes sense
22:54:17 <Woodstock> so the serial cabling is of no issue there
22:56:56 <rmustacc> Yeah, I would guess that cabling may not be of issue for you.
22:58:08 <rmustacc> I would check if there's an explicit level shifter on the device you're using.