Does anyone have a workload where SCTP is being used?

I'm looking for a simple packet capture of some valid SCTP packets for a test case

oh ffs

chmod does a chdir then a chdir .. with -R instead of just iterating the directories

(which makes it rather useless when someone accidentially removes all permissions to a directory)

as the chdir .. fails and it bails

i think i'll be filing a bug for that :)

jbk: should open ('.') and then fchdir back.

the problem is someone's completely screwed up all of the permissions on this directory tree, and chmod -R (it's ACLs that are the issue) is failing because the chdir back is failing

and instead of ignoring it and moving on, it stops

and there's millions of files

it looks like it's not using fchdir:

(also, it can't handle deep directory heirarchies, which seems like another bug/enhancement)

if I'm taking driver knowledge from BSD, and the knowledge is spread across the BSDs, do I take the entire license block from each?

especially asking core people

I remember the BSD/MIT/ICS situation being weird, but not how, because I've always just done what I'm told

but now people ask _me_ to tell them, unfortunately.

richlowe: I think, generally, if you _copy_ something that isn't just facts, you probably need to include the licences from the one you copied

If you're just reading a header full of, like, "bit 5 in this register turns on the encabulator"

I feel like that is a fact that you can then retain and just use yourself

To be clearer, if you copy blah.h from FreeBSD, include the blah.h licence bits

But if you read blah.h in FreeBSD and discover that BLAH_POWER_ON is 0x001, you probably don't need the licence stuff if you then add BLAH_FL_PWR_ON to our own header

that's all my view on things, but I'm meaning: If someone feels they need the copyright, do they need the full license text?

because of the wordage in there

I think I can ask without disclosing details...

If I see this from `savecore -f vmdump...`:

1:47 99% donesavecore: stream tag 3548 not in range 1..1

savecore: bad summary magic 20081420

Do I have any way to recover anything? Whenever I saw this in the past I gave up, but I'm curious if there's some trick I'm missing?

it'd probably require hacking up savecore (i.e. I don't think there's any flags or mdb magic that can be done)

if it's at the end, you might be able to try skipping over it

(slightly related, because of network reliability issues we often end up having to split the vmdump file into smaller chunks for customers to upload to us.. i've been thinking about adding support to savecore where it could read those chunks directly when expanding instead of having to first concatenate the files

i don't know if that's something that would be of use to the greater community or not...

Are you compressing it before upload?

yes

but the files are still quite large

I have a feeling a lot of the specifics are ultimately going to be situation specific because it's not clear to me you'd want to do this say pre-compresion.

and in some cases, they have to bounce around multiple internal systems at a customer before they can get out, etc. so being able to break it up (we just have then use split -b) helps

it'd be after savecore has saved it to the system, but to transfer it off the system for analysis

i.e. the vmdump.XX file

just that with an 80+gb dump, cat file1 ... > vmdump.0 can take an appreciable amount of time on its own (to then just run savecore to expand it)

Sure, I just mean thinking out loud what you probably want is vmdump.XX -> compress -> split.

they're usually already compressed when written though I thought? would trying to compress again make a noticable impact?

Pretty sure andyf has noticed a pretty good win with some of the things he does on the vmdump.

if so, I'd check savecore -vf first and then compress archived vmcore and unix files. compressed segments versus whole file compession.

[illumos-gate] 17278 nvme shutdown and reset be aware of "gone" devices -- Dan Cross <cross⊙oc>

Ungg think I've found the bug

paulf ?

Ouch...

I see...

That's been there FOR... EV... ER.

SHould be `*typep = ap->type;` and local var `type` removed, right?

Yes I think so

hm, where is this 'read from uninitialized memory' warning....

I think the optimization just puts a zero in there

  10344c:       c7 06 00 00 00 00       movl   $0x0,(%rsi)

Yeah, that's definitely a bug and that's the right fix. Do you want to fix that paulf or would you rather someone else did so?

It would be a lot easier for me if someone else did it

Sure, no problem.

../port/threads/pthr_mutex.c:370:16: error: 'type' may be used uninitialized [-Werror=maybe-uninitialized]

I'll put in a temporary workaround on my sude

side

hrmmm: Loading modules: [ libc.so.1 libumem.so.1 libtopo.so.1mdb: ld.so.1: mdb: fatal: relocation error: file /usr/lib/mdb/proc/amd64/libzpool.so: symbol mdb_gethrtime: referenced symbol not found

that's odd...

yep.

paulf: clearly not a heavily used function!

no and I don't know why I've just noticed the issue

Valgrind uses it internally to check that the mutex type that it stores is consistent with the value that pthread_mutexattr_gettype obtains

In a typical application I'd think the attributes of a pthread_*attr_t would be written once, and only read behind the scenes by the implementation.

Does anyone know if there's a ticket filed for this?

I think paulf just found it - the only hit for pthread_mutextattr_gettype in our bug database is your illumos.org/issues/16200

→ BUG 16200: posix NORMAL lock is required to deadlock (Closed) | code.illumos.org/c/illumos-gate/+/3255

yeah, Solaris still has the code there that was in OpenSolaris but which illumos removed last year: illumos/illumos-gate 50718d3

→ GitHub commit 50718d3: 16200 posix NORMAL lock is required to deadlock (committed)

Thanks sommerfeld.