tsoome_: So my serial console doesn't work right anymore. It seems to be stuck at 9600 baud even though the file says 115200. Also, if I switch to 9600 baud to engage with it, it's doing that thing where it drops a lot of key presses... I'm pretty sure this never used to happen on this machine. gist.github.com/jclulow/68a87cd9d4c7267a6f58c1efb107fcdd

When it gets up into the OS, because I have the console ttydef forced to 115200 it starts working then

jclulow hm. it is confusing. there is ttya-spcr-mode present, so thats the setting from firmware, and if it is there, we should have ttya-mode with the same value (it is actual setting for port), and the presence of ttya-spcr-mode should block the change of ttya-mode. one can unset ttya-spcr-mode to make it possible to change ttya-mode - there is no nounset hook set with *-spcr-mode. so the question is, why we get ttya-mode set to 9600...

why does ttya-spcr-mode block setting ttya-mode :/

because you have set it in firmware and firmware console redirection may depend on its value.

I haven't set it in the firmware

There aren't any settings in the firmware haha

well, ok, it is reported value

I think we probably need to take people at face value when they set the property that has worked for probably 25+ years

ou, the system does not have serial redirection but it is still reporting SPCR?

I'm not sure what it has, to be honest, it's a minimal core boot

thats the problem, people do not set property values, we do provide 9600 in our config files, while todays systems default to 115200

I think it's a PC Engines apu1d4

its booting with BIOS mode?

It looks like BIOS yes

so it does get acpi spcr.

To be clear, if I didn't put something in /boot/conf.d/* that explicitly sets ttya-mode it would be fine to do whatever the firmware says

but I did :P

so it was working with default 115200?

(default in sense what firmware was having)

I haven't been on the console in probably a year, since before updating to OmniOS r151046 LTS. When I wrote the file in 2020 it was working at 115200 yes

Which was probably OmniOS r151034 I think

there is other bug, however, we use 'N' in biosacpi.c, but comconsole is expecting 'n', so need to fix that.

I did wonder if that was case insensitive

I also think, there should be better way to ignore spcr, probably like ignore-spcr=true or something

jclulow could you check please if code.illumos.org/c/illumos-gate/+/3327 will improve things...

→ CODE REVIEW 3327: 16330 loader: SPCR needs better handling (NEW) | illumos.org/issues/16330

Hello everyone, I hope you're all well, I had a question about using BHyve, should I prefer Omnios or OpenIndiana?

They should both work fine, the underlying bhyve code comes from illumos which they both share. As far as I know, they both have bhyve-branded zones too which means you can run it in a zone and get to its console with zlogin etc.

OmniOS does have a `zadm` utility which makes things a bit easier, and the way the zones are implemented is a bit different, but that's all.

andyf thank you

[illumos-gate] 16297 pmadvise: 'restrict'-qualified parameter aliases with argument 4 -- Toomas Soome <tsoome⊙mc>

tsoome_: do you have plans to integrate code.illumos.org/c/illumos-gate/+/3299 soon?

→ CODE REVIEW 3299: 16290 libuutil: assfail() is not needed (NEW) | illumos.org/issues/16290

sort of, I think I need to get the nightly done soon

is it affecting something?

it will simplify my code.illumos.org/c/illumos-gate/+/3237 (which among other things fixes the return type for assfail() to be consistently void)

→ CODE REVIEW 3237: 16192 Retire libc's thr_debug.h in favor of <sys/debug.h> (NEW) | illumos.org/issues/16192

I see, I'll set the nightly up now

Thanks!

[illumos-gate] 16322 sockfs: unused variable -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16313 loader: we can only env_discard() existing variable -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16320 remnants of patch builds should be removed -- Richard Lowe <richlowe⊙rn>

[illumos-gate] 16200 posix NORMAL lock is required to deadlock -- Robert Mustacchi <rm⊙fo>