yup, "we have a plan to cut a billion bolts in the 5-year range! let's exceed it and cut 1.1 billion bolts!" "and we have a plan to cut a billion nuts in the 5-year range! let's exceed it and cut 1.5 billion nuts!" ... 5 years later ... "So what do we do with several extra trains of nuts?"

as for python questions... ended up abandoning hope for certbot as I found acme.sh instead and it just worked

I am a fan of dehydrated

getssl for me :)

well, the first second option google came up with :)

TBH, dehydrated was also there in the page

not sure about getssl

are there any particular differences? I just need to pre-face a Jenkisn server with an apache (or nginx) doing https, and updating the cert regularly

heh.. so i'd really like to update the tpm driver to support tpm 2.0 devices (since those are a lot more useful than 1.2 devices)...

though i have a somewhat silly question...

my home server has a tpm 2.0 module attached to the LPC bus

how in the world do you enumerate/attach to that?

I _think_ there's like an ISA PNP id, and an ACPI table (which in this case just says 'it uses memory mapped io' but doesn't indicate a physical address like say an HPET

IIUC, there is a fixed physical address -- but i'm thinking there should be some sort of way for the system to know if there's one there

vs. blindly poking at stuff

(i didn't see anything obvious in the writing drivers book.. though maybe didn't look in the right spot)

jbk: I expect it's going to be something you find out through ACPI, or through the CPU programmer's references

My incredibly limited understanding suggests that just because something is LPC-attached, doesn't mean it is necessarily ISA

Perhaps the TPM specification covers how you're supposed to find them, even

my question is more around the driver binding (I think)

like for 2.0 devices, there should (if i read it correctly) an ACPI table, which for mine says 'memory mapped'.. which ok.. there's a defined hw address range

but doesn't something still need to say 'hey i found this, and this is the driver to load and attach'

Presumably the acpirootnex?

I recall there being some stuff in uts/intel/io/acpica/acpi_enum.c which interacts with /boot/solaris/devicedb/master

aha.. i think that was the missing piece

the _HID is MSFT0101 -- so i think a line just needs to be there to tell it to load the driver

andyf gist.github.com/sjorge/5e4c82c348d2b9c284442cebacc7ef59

Does this look familier to you?

I got it twice last night on the CN that is running the latest bhyve sync

I can provide dump if needed

hm. freebsd guests under bhyve seeing vtnet watchdog timeouts -- does that ring a bell for anyone?

andyf: pkg.blackdot.be/cores/vmdump_vmm_sol_dev.gz

nbjoerg on illumos?

sjorge: no, does not ring any bells. I'll take a look at the core

Smithx10: your pool scattered all over the datacenter? :D So you got it back up?

@Agnar_: until the signalfd thing is fixed, I suggest you add -DWAIT_USE_POLL to config_env->{CPPFLAGS} in your build_farm.conf

andyf let me know when i can remove the dump

got it, thanks

sjorge: well, smartos, but I think bhyve is common base?

nbjoerg yeah thats all illumos :p

I've had this happen from time to time, where all viona's buffers are on loan

it basically gets stuck and trips the watchdog/deadman timer thingy

Usually when that happens and you bounce the vm... it never leaves shutting_down state

Might be something different though

illumos.org/issues/13463 is the loan buffer issue

→ BUG 13463: bhyve locks up when viona ring buffers on loan to a local zone are not returned by sockfs (New)

It causes all sorts of weird effect with nics

sjorge: in my case it is only one or two interfaces affected

hm. so what I don't understand from the ticket is we can't allocate more ring buffer elements and swap them behind bhyve on TX?

sensille: lol yes

nbjoerg yeah, but that does lock up the nic and depending on how quick it happens it could just hang the VM or have the guest os in the vm panic or hang.

Could still be a different issue, but I have certainly seen freebsd barf on watchdog when it was happening ot one or more nics

hm, still seeing acpi stuff in wsdiff output, i thought 10447 was supposed to take care of that? or not entirely?

ypankov: it only takes care of it if you don't change VERSION between builds IIRC

If, like me, you use something like the commit hash in VERSION, they show up every time

andyf: it seems to be a lot of the following: pastebin.com/LuDFcb9w, does not seem to be VERSION related? or is it?

did your VERSION change length?

I usually see things like this - illumos.topicbox.com/groups/advocat…5-ratz-some-ast-tools-not-necessary

pastebin.com/Ksf8TLNm -- this? i just checked out previous commit

yes, so because the length of VERSION changed, I expect it's caused code offsets to change too

ok, great, thanks!

It's not ideal. These days, if I remember, I manually set VERSION to the same as the last build when I want to wsdiff.

nice hint!

I'd like to see VERSION removed entirely from those acpi files, but I'm not sure everyone agrees.

sjorge: any way to bump the initial size?

sjorge: virtio allows up to 64k if I read this correctly?

wonder if there's any real reason to keep gcc 4.4.4 shadow as requirement?

andyf: this one is done i think? illumos.org/issues/10011

→ BUG 10011: stop building and shipping lint libraries (In Progress)

ypankov: yes, it needs closing and I couldn't work out how

I assume it needs someone with more permissions than I have

got it, was just looking through lint-related issues to not file duplicate

I think the gcc 4 shadow is still there so we don't break SPARC unnecessarily.. it looks like we might get a gcc10 shadow soon, which will be nice too

sparc only builds using gcc 4.4.4?

I think so, yes.

sparc might build with other compilers, but only the gcc4 bits will actually work

unless you add the additional sprc-specific patches our gcc4 has

ok, that explains

ypankov: I have a fix for the slow pkg/server thing..

so it's real issue?

Yes. The way that the python cheroot module is using /dev/poll seems problematic

here's the fix I'm going with for now, pending further investigation

when processing HTTP/1.1 connections, it puts the connection back on the select queue after processing a request, but it never comes up readable again even though there is a request waiting. This introduces 30s timeouts and slows everything down

There might be something wrong with Python's /dev/poll usage, I haven't looked yet

I can give you a hotfix, or just edit /usr/lib/python3.7/vendor-packages/cheroot/connections.py

(or python3.9 for the bloody branch)

yep, let me try editing that and testing

do we have any restrictions on setting bootfs anymore?

src.illumos.org/source/xref/illumos…ootfs/bootfs_006_pos.ksh?r=c09fb523 -- this still fails and it seems like it should be trivial to fix -- i think it just hasn't been updated to match what's allowed these days

it looks like only stripe and stripe+spare are not supported (according to tests)?

that comment is now badly placed

i'm pretty sure the test is failing on: src.illumos.org/source/xref/illumos…s/bootfs_006_pos.ksh?r=c09fb523#125

which suggests it's allowing bootfs to be set

that's why i just wanted to try to confirm what's actually supposed to work

to make sure the test reflects reality

(or if our validation code is wrong)

ypankov: What are you looking at :P

after leftwing did fix the kernel, we should be able to use striped setups too (in most cases)

err

I don't think my change will do anything for multi-vdev pools

should test:)

i've been booting locally from this pool for quite some time: gist.github.com/jasonbking/64ea324213d7020be2afef7a975cf6e1

(even before piadm)

though.. i don't recall how recently i've tried booting off an alternate device

i installed the bootloader on all 4 disks

was it created with 2 vdevs?

2 mirrors, that is

no, it was created like that IIRC

ok, because if the second vdev is added later, then most of the files are still on the first:)

a program is linked with libumem, is it possible to change the backend from sbrk to mmap from the program?

from a sheel I can set UMEM_OPTIONS, but from the program... is it possible?

*shell

There is a private way to do it from the program, but there is no stability promised for it.

I see, thanks

See the use of _umem_options_init() or _umem_debug_init() in things like startd and configd.

In particular, all of the umem item have their own stability settings.

So, the backend is evolving. This means that it may still change and we can't promise you won't be broken in the future.

But it is likely the umem means of specifying that won't change.

nice, at this moment a problem is solved, thank you very much!

anyway to find out what my zpool id is?

zpool import, zdb

nbjoerg: not sure, but someone over in #smartos might know

tsoome: easiest was zpool get guuid <pool>

right:D

hahaha, i had a brain fart on that 1

[illumos-gate] 13487 want mapfile-based assertions about symbol properties -- Richard Lowe <richlowe⊙rn>

and now chaos ensues, I imagine

that kind of chaos is good