13:13:16 Does anyone have a workload where SCTP is being used? 13:13:57 I'm looking for a simple packet capture of some valid SCTP packets for a test case 16:25:58 oh ffs 16:26:21 chmod does a chdir then a chdir .. with -R instead of just iterating the directories 16:26:59 (which makes it rather useless when someone accidentially removes all permissions to a directory) 16:27:07 as the chdir .. fails and it bails 16:27:28 i think i'll be filing a bug for that :) 16:34:15 jbk: should open ('.') and then fchdir back. 16:38:37 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 16:38:44 and instead of ignoring it and moving on, it stops 16:42:30 and there's millions of files 17:35:38 it looks like it's not using fchdir: 17:35:40 https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/chmod/chmod.c#L342 17:35:48 https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/chmod/chmod.c#L433 17:36:32 (also, it can't handle deep directory heirarchies, which seems like another bug/enhancement) 19:10:38 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? 19:10:53 especially asking core people 19:11:14 I remember the BSD/MIT/ICS situation being weird, but not how, because I've always just done what I'm told 19:11:21 but now people ask _me_ to tell them, unfortunately. 19:32:29 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 19:34:52 If you're just reading a header full of, like, "bit 5 in this register turns on the encabulator" 19:35:13 I feel like that is a fact that you can then retain and just use yourself 19:39:26 To be clearer, if you copy blah.h from FreeBSD, include the blah.h licence bits 19:40:21 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 19:44:48 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? 19:45:00 because of the wordage in there 19:54:06 I think I can ask without disclosing details... 19:54:18 If I see this from `savecore -f vmdump...`: 19:54:21 1:47 99% donesavecore: stream tag 3548 not in range 1..1 19:54:22 savecore: bad summary magic 20081420 19:54:48 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? 20:01:56 it'd probably require hacking up savecore (i.e. I don't think there's any flags or mdb magic that can be done) 20:02:17 if it's at the end, you might be able to try skipping over it 20:03:28 (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 20:03:43 i don't know if that's something that would be of use to the greater community or not... 20:04:04 Are you compressing it before upload? 20:05:02 yes 20:05:27 but the files are still quite large 20:06:07 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. 20:06:09 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 20:06:57 it'd be after savecore has saved it to the system, but to transfer it off the system for analysis 20:07:04 i.e. the vmdump.XX file 20:08:02 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) 20:08:04 Sure, I just mean thinking out loud what you probably want is vmdump.XX -> compress -> split. 20:08:38 they're usually already compressed when written though I thought? would trying to compress again make a noticable impact? 20:09:07 Pretty sure andyf has noticed a pretty good win with some of the things he does on the vmdump. 20:11:16 if so, I'd check savecore -vf first and then compress archived vmcore and unix files. compressed segments versus whole file compession. 20:14:26 [illumos-gate] 17278 nvme shutdown and reset be aware of "gone" devices -- Dan Cross 20:14:58 Ungg think I've found the bug 20:15:43 https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libc/port/threads/pthr_mutex.c#L370 20:16:51 paulf ? 20:17:00 Ouch... 20:17:29 I see... 20:17:38 That's been there FOR... EV... ER. 20:18:29 SHould be `*typep = ap->type;` and local var `type` removed, right? 20:18:42 Yes I think so 20:19:47 hm, where is this 'read from uninitialized memory' warning.... 20:20:50 I think the optimization just puts a zero in there 20:22:15   10344c:       c7 06 00 00 00 00       movl   $0x0,(%rsi) 20:23:30 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? 20:24:51 It would be a lot easier for me if someone else did it 20:25:21 Sure, no problem. 20:25:29 ../port/threads/pthr_mutex.c:370:16: error: 'type' may be used uninitialized [-Werror=maybe-uninitialized] 20:29:37 I'll put in a temporary workaround on my sude 20:29:39 side 20:42:11 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 20:58:11 that's odd... 21:03:05 yep. 21:06:16 paulf: clearly not a heavily used function! 21:07:53 no and I don't know why I've just noticed the issue 21:09:07 Valgrind uses it internally to check that the mutex type that it stores is consistent with the value that pthread_mutexattr_gettype obtains 21:11:35 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. 21:26:23 Does anyone know if there's a ticket filed for this? 21:35:22 I think paulf just found it - the only hit for pthread_mutextattr_gettype in our bug database is your https://www.illumos.org/issues/16200 21:35:23 → BUG 16200: posix NORMAL lock is required to deadlock (Closed) | https://code.illumos.org/c/illumos-gate/+/3255 21:44:44 yeah, Solaris still has the code there that was in OpenSolaris but which illumos removed last year: https://github.com/illumos/illumos-gate/commit/50718d3ece2504ebcfdc3f385132f664b567cdd0 21:44:44 → GitHub commit 50718d3: 16200 posix NORMAL lock is required to deadlock (committed) 22:27:22 Thanks sommerfeld.