[illumos-gate] 16758 pci_enable_errors clobbers pcie_fabric_scan extended tagging -- Robert Mustacchi <rm⊙fo>

[illumos-gate] 16546 The find command should be able to find SIDs -- Bill Sommerfeld <sommerfeld⊙ho>

jbk how is your 15907 going?:) I have been using it since published and have not seen any problems:)

[illumos-gate] 16766 SO_SNDTIMEO/SO_RCVTIMEO options broken for UNIX sockets -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 8891 One unmountable dataset on rpool breaks a lot of things -- Andrew Stormont <andyjstormont⊙gc>

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

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

or at least, i haven't been able to eliminate that yet

i suspect we're maybe just pushing more stuff to ESX than it can handle

but haven't found a good way to confirm that...

ah, ok I havent tested jumbos

I was just walking my branches and found your update is still there:D

speaking of that..

i know someone (I can't recall who offhand) posted an update for ACPI a fairly long while ago

i've been running that almost since it came out w/o issue

maybe a few weeks to a month after

i don't know if anyone else has been using it

but might be nice to get it in if we feel it's had enough soak time

(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)

well, atm my smartos on bhyve is spamming messages like: WARNING: cpupm_init: processor 18: unable to get ACPI handle

oh, i haven't tried that change in a VM.. this is on my home server

that runs smartos

(I have a branch where I've applied that change + my in-progress TPM driver)

ou, how far is your tpm driver btw?

tpm2, or virtual tpm, or?

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?

it might help if a matching `prtconf -d` is in there

(I sure wish `prtconf -pvd` worked somehow)

richlowe asked friend of mine;)

they have number of T8-2's in use...

thanks!

[illumos-gate] 16745 asy: rework asy(4D) register access and fix chip identification -- Hans Rosenfeld <rosenfeld⊙gho>

[illumos-gate] 16747 asy: support 16950 and compatible UARTs -- Hans Rosenfeld <rosenfeld⊙gho>

[illumos-gate] 16746 asy: improve PCI(e) device support -- Hans Rosenfeld <rosenfeld⊙gho>

[illumos-gate] 16752 asy: infinite loop in asyopen() -- Hans Rosenfeld <rosenfeld⊙gho>

ugh, it's clearly been too long since I tried building illumos-gate. I'm following 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?

well, you can backtrack from the "not remade of errors" to the actual error in nightly.log

fwiw, when i'd gotten that i found some success searching for `***` (or `\*\*\*` depending how you're searching)

the last instance of that warning was very downstream from the first instance, which was much closer to the actual issue

yeah, search for the first *** and look immediately above it for error messages.

sommerfeld: fyi, i updated code.illumos.org/c/illumos-gate/+/3662 with the 912600 baud bits, in case you want to resume reviewing :)

→ CODE REVIEW 3662: 16748 asy: support higher baud rates (NEW) | illumos.org/issues/16748

grumble, well of course I found something obvious after asking.

Has some info.

'Error code' is the key grep

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)

rmustacc: ooh, I hope I'll break something interesting enough to need that this weekend

Woodstock: what cables are you using that you're having trouble with?

one day I will get annoyed enough to make -w the default and add a tool to summarize your build errors

FWIW, we have the AMD uarts running at 3 Mbaud to a USB receiver.

ri

also see the flag day list at illumos.org/docs/developers/flagdays ; the March 2024 one may be related

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?)

no shielding, no twisted pairs or anything, db9 on each end

Hmm, okay. We end up using them to a USB receiver.

But we also have hardware flow control on there.

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.

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 :)

richlowe: do I need to tweak nightly for that? I'm thinking build tooling might have some nice starting contributions, was thinking about richlowe/arm64-gate #11 vs the illumos-gate build scripts to play with this weekend

Assuming you know the device in question can do that, then it makes sense.

with the standard 1.8432mhz clock you won't get much higher than 1843200 baud anyway :)

Yeah. There's a separate 3 MHz clock in the AMD FCH. So our table looks like github.com/oxidecomputer/illumos-ga…sr/src/uts/oxide/io/dwu.c#L257-L291.

josephholsten: set MAKEFLAGS in your environment file. I have `export MAKEFLAGS=wek` in mine.

rmustacc: these serial lines you're using are not by chance using RS-422 signalling?

No, we're not using RS-422. We had to bypass the level shifter on the board.

Practically speaking, that could also be your problem.

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.

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.

so what kind of signalling do you get if you bypass the level shifter? just plain ol' ttl?

Let me double check the EDS.

SP3 and probably AM4 were all 1.8V single-ended signals.

interesting

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.

that makes sense

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?

We use things like the FT2232H or when we're limited to 1 Mbaud the UT232R.

i see, that makes sense

so the serial cabling is of no issue there

Yeah, I would guess that cabling may not be of issue for you.

I would check if there's an explicit level shifter on the device you're using.