tsoome: seems I'm going to do my second contribution to the illumos kernel ;) I removed the emlxs check for oracle branded hbas - and the driver seems to work. I'll do some testing of course before ;) Carsten wrote me that Hans told him that our emlxs is originating from emulex - so it is probably the foundation of their old lpfc driver, and to not collide with the solaris' own emlxs they built in that #ifdef ...

nice, I suppose, it is kind of trial and error - if you do not have vendor docs to refer to, that is...

tsoome: it also helps to have some history background - the existence of lpfc and emlxs at the same time is a good pointer...

tsoome: but yes, it was worth a try. I'll test also with LPe11002-S I have in a different box

I always disliked the emulex lightpulse adapters for having the crappy lpfc driver and on x86 the bad bios integration. but then I learned about the existence of MegaRAID and I think the road to peace in the world is blocked by that RAID controller.

and the person who invented MegaCli. honestly, who thought "this is it! this is what we want our customers to experience!"?

yes.

Woodstock: oh, thanks indirectly to you too :)

for megaraid? :)

also, but for telling Carsten once about the origin of our emlxs ;)

ah yes

I have a X4-2 here with 7 SAS disks, and the stupid megaraid only sees 4 targets, while the ILOM tells me that 7 disks are inserted. I suspect a sas cable problem with the upper SAS expander backplane, but it's still weird.

which driver is driving that thing?

Woodstock: mr_sas - the reason I suspect a hardware issue is, I have a second X4-2 from the same batch that detects all 7 disks

I have X6-2 and trying to figure out if it is worth getting nvme for it -- thats 1 adapter + disks

tsoome: is that also driven by mr_sas?

tsoome: I use a bunch of cheap consumer NVMes in my X4270 M2, KINGSTON SNV2S250G and KINGSTON SA1000M8240G in PCIe M2 adapters

Woodstock yes

pci1000,9361, instance #0 (driver name: mr_sas)

tsoome: funny btw: I do the same in my T5220 which works, but it does NOT work in the T4-1 - likely the OBP/HyperVisor prevents the OS from seeing the device

fascinating

that's btw another thing I'd like to debug...ILOM...

my version does not let to use disks as JBOD - there is option to switch it in menu but setting it does not work. someone thought that it may be because of connected supercap, however.

tsoome: my megaraids also don't allow me to do JBOD, but I just set up RAID0 for each slot and that's fine

and then Mr. ZFS takes the job from there

same, the issue is, when the raid0 logical is getting errors, you have to do some work to fix it.

like when 3-years old is getting to pull from interesting handles:D

oooh, yeah. I see

my 19" Rack is standing in the workshop ;)

and my kids are 10 and 12 ;) they know that their minecraft server goes down if they start touching servers :)

yea, I still have to wait with that move.

I recently upgraded the home rack with an older eMC silkworm - now I have 4Gb FC at home. Which is handy as I want to use the two X4-2 servers as bhyve hosts for different training systems.

hello. does Illumos ftpd support Kerberos (GSS) authentication?

illumos itself does not provide ftpd, but distributions do

tsoome_: Solaris ftpd got removed?

yes: 5069 Removal of wu-ftpd

ah ok.

it was wuftpd, but yes

i haven't found any third party ftpd that does GSS, except some ancient-looking patch for ProFTPD :-( i was hoping i could port the solaris one to freebsd

ftp client does have gss component, but I have no idea how well it is actually working

well, it is git repo, so you can still extract the source (and yes, there are gss bits present)

oh, no hg anymore? ... yeah, i might do, although i'm dubious about taking old unmaintained code that doesn't get security coverage

the API itself should give some base to work with, you most likely do not want whole wuftpd from it

of course, you need to be careful about license details....

for everyone who ports a new software to illumos: en.cppreference.com/w/c/23 (WD of C23)

illumos libc is C23?

I don't think so, but it should conform it in some time

Agnar: isn't storcli now the preferred tool to deal with those cards?

neuroserve: storcli?

Agnar : as those RAID controllers moved from LSI to Broadcom, the configuration tools changed, as well

Agnar : I use storcli as it is a little more user friendly than MegaCLI - and is available as Solaris binary, too (which saves booting to other operating systems to configure the controller)

do you have a download link?

Agnar : broadcom.com/support/knowledgebase/…-8i---9260de-8i---9261-8i-downloads - but you might have to search for your controller first

thanks!

Agnar : thomas-krenn.com/de/wiki/StorCLI <- and Thomas Krenn Wiki is always useful, too

*nod* I have the megacli article from that wiki in my bookmarks

[illumos-gate] 16424 libavl should expose avl_update{,_lt,_gt} -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 16436 zfs reference tracking panic during zfs_receive_raw_incremental test -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 16203 zfs: switch refcount tracking from lists to AVL-trees -- Alexander Motin <mav⊙Fo>

[illumos-gate] 16458 genunix: memory leak in ip_helper_stream.c -- Toomas Soome <tsoome⊙mc>

Note, the C23 spec has not been formally published yet, so we have not begun any adoption efforts so we don't end up with implementing something from a draft that gets changed and then breaks folks.

That sounds paranoid, but this is happened before, more than once

s/is/has/

i'm guessing that's the reason behind the two different versions of getpw{nam,uid}_r and such

Among other things, yeah.

Happy for us to get it all ready to land and work on it, just why I haven't touched that or POSIX next stuff.

Or if others have already implemented interfaces so we're all in it together.

I think C23 is supposed to be past that point since it's in the final balloting stage, unlike the posix threads draft stuff that bit Sun in the 90's, but I admit I've been waiting for final publication as well

though of course some bits are already done because the standard adopted existing practice, like strdup() and memccpy()

gustedt.gitlabpages.inria.fr/c23-library seems like a nice preview of the libc work that will be needed

Do you have a sense of how the SUS rev is going similarly alanc?

It isn't clear to me as an Austin-outsider how much some of the stuff is firmed up or not yet.

I assume also some stuff that is already implemented like you mention that we're missing is safer.

I think they're also getting close to final draft, but not as close to finished as C23

If you do hear anything from them and it's not too much trouble, give me a shout.

I would like to coordinate a bit with you on some of the posix gedents stuff and related.

I've seen Austion Group mark stuff as "too late for issue 8, put it on the list for issue 9" for a bit now

If we put other file types into the info there like doors, it seems we're better trying to be similar than different.

right, makes sense

and actually , looking back at the minutes in the austin-group-l mails, they may have done their final draft/ballot as well now

but I think with both, due to standards body constraints, people not in the standards body can't see the final drafts until official publication

Yeah, I realize it's an over-constrained problem.

The thing I really would hope austin puts out though is a summary of what's actually changed.

I've seen summaries from them of the brand new API's added, but not of changes to existing ones

Yeah, likewise.

Robert Elz made some nice summaries I saw for NetBSD, like mail-index.netbsd.org/current-users/2020/03/23/msg038129.html and mail-index.netbsd.org/current-users/2023/01/17/msg043531.html but I don't have a complete set of those posts from him, and since he omitted things that NetBSD doesn't have to change for, that's probably not the best source of info for other OS'es

gist.github.com/Earnestly/29deee4f18346da6630ed1df760f1590 is another brief/incomplete summary of changes to commands in Issue 8, ignoring library changes entirely

I've not checked to see if the new ksh93 community is working on them or not - I believe bash is

(them == the POSIX shell changes)

oh if we had to change shells again that would be a thing

but I can't say the thought of modifying ksh93 in any respect appeals

sounds like discussions we've had debating the relative fun levels of changing /bin/sh to something else (for us in a micro release) vs. poking the ksh93 bear even more

The challenge is that there are real live ksh users, who use all those... features

I honestly don't remember whether we promised bin/sh had them, never mind whether we intended to

austingroupbugs.net/view.php?id=1462 seems like it'd be interesting for our 32-bit env

though maybe just having 64-bit apps w/ 64-bit time_t might qualify

we've talked about time some, but definitely with a view to following the crowd

64-bit apps is certainly a possibility, since it ends up being necessary for me anyway

I'm not sure if there's a desire in the world for explicitly 32bit time64 apps

I guess the relative difficulty in fixing a whole app, or just its time

alanc: Thanks for some of those links. Appreciated.

yeah, 64-bit time_t in a 32-bit app doesn't help if you can't recompile the app, and if you can recompile the app is it really that much harder to go full 64-bit ?

though I suppose if you don't actually use time_t in your app, then having ld.so.1 be able to handle 64-bit time_t when calling stat() to find your libraries lets you at least keep running after Jan 2038, but that could be a private API instead of a public one

I wish richlowe was right, but I got a bad feeling people are gonna want 32-bit apps with "large time".

See IPD 138

Wait...

off by several... fenix ipd 14

IPD 14: illumos and Y2038 (predraft)

↳ github.com/illumos/ipd/tree/master/ipd/0014/README.md

and because of the XPG8/POSIX.1-2024 change jbk posted, if you don't do something, then you have to explain you're only fully supporting the new standards in 64-bit software, not 32-bit