06:33:13 richlowe: 15961. strip -x is what I'm using on all files 06:53:56 jperkin - that's expected behaviour, isn't it? At least according to strip(1), stripping an archive file stops you being able to use it for linking. 06:54:52 What is calling strip on the .rlib prior to the linking step? 06:55:58 > If strip is executed on a common archive file....in addition to processing the members, strip removes the archive symbol table. The archive symbol table must be restored by executing the ar(1) command with the -s option before the archive can be linked by the ld(1) command. 06:59:18 I'm guessing that GNU strip doesn't do this, and perhaps ours should not either in the presence of '-x' 07:05:03 Either that, or we need to add a sentence against the -x option in strip(1) to clarify. 07:52:08 andyf: yeh I agree the docs suggest it shouldn't work, I think rich/josh wanted it raised though as GNU strip doesn't break them and it's worth discussing whether we should keep them when using -x 07:52:36 I already skip *.a so adding *.rlib wasn't a big deal 07:53:46 in this case stripping is handled by the pkgsrc infrastructure, we automatically ctfconvert and strip any suitable files in the stage install area prior to packaging it up 12:12:30 [illumos-gate] 15959 race condition in devfs_readdir causes panic -- Andy Fiddaman 14:27:14 is there a way to slowdown illumos builds?, it seems my computer is getting a thermal shutdown when building illumos-gate, I already set MAX_JOBS=1 are there other options ? 14:33:46 Honestly, my first instinct is to ask what's wrong with your machine where a non-parallel illumos build is causing thermal failure? 14:34:23 Beyond that, maybe using prctl(1) can help you reduce its CPU usage, assuming CPU is what's causing your overheading. Is it an HDD that's causing the heat? 14:34:49 This feels like a HW problem. 14:35:31 hide the box from the sunlight, sometimes it helps :) 14:38:33 denk hahha, I tried compiling at night when is freezing here, did not work :) 14:39:24 danmcd yes, I need better thermal paste maybe but illumos is the only build that failed on this machine due thermal shutdown 14:41:18 danmcd yes, should be a hw problem maybe but the only activity that produces this is building gate. I'll try today again maybe underclock the cpu 14:43:07 danmcd, the disk is a good clue as I haven't used this disk to compile anything else, just illumos is using it. Could be a disk issue but I did not see anything in fmadm 14:45:04 I've had awful problems with spinning-rust overheating on my not-so-great-for-HDD case. Next time I run `zpool scrub` I'll see if the most recently RMAed drive is the problem (or not). 14:51:53 you can try to configure the syslog to send messages to another server, it could help to detect a problem 16:39:14 [illumos-gate] 15958 swap: clean up build -- Toomas Soome 17:06:05 hrm... 17:22:53 so in this workload.. mac is pretty frequently resorting to polling (rx), and about 50% of the time polling is failing because the next available packet is larger than the poll amount, would that suggest maybe needing to tune something upstack? 17:25:23 or what would be something to look at? 17:26:39 (the poll is failing approx 10,000x/sec) 17:33:37 jesus loo 17:33:39 lol 17:33:41 that is a lot 17:34:07 yeah 17:34:14 basically there's always a 9k packet available 17:34:17 At least at face value it feels like there is something missing in how we decide to poll there 17:34:19 but mac is asking for < 9k 17:34:39 well about 50% of the time mac as asking for <9k 17:34:53 Yeah I would figure out how it comes up with that number 17:35:01 this is a somewhat heavy workload 17:36:33 it is across multiple rings and 2 nics (in an aggr), so the per-ring rate should be lower 17:37:37 (and it's almost all NFS traffic, so not going out to userland) 19:11:33 does ::typedef -r override any existing CTF definitions? 19:51:38 jbk: In general ::typedef has its own CTF container that all such type definitions go into. 19:52:16 The ::typedef -r just iterates over all types in a file and adds them to said container as well. 19:53:20 Then in the various mdb_ctf actions, it'll fall back to that CTF container when looking things up. So for example, when we're doing a general name to type, we'll try to find a ctf type in the target's default, then try to find it in all objects, and then come back to the synthetic container to try to look up a type name. 21:28:01 tsoome: (since you've messed with it the most recently :P) does smatch allow for adding custom checks? 21:28:07 as like extensions 21:28:42 so we could add custom things w/o having to basically do it as a fork (and worry about merging, etc) 21:34:06 I havent seen any support for that 21:34:22 I havent really been searching for that either 21:34:51 but we do have added illumos specific tests already 21:35:49 check_cmn_err.c for example 21:57:27 ahh ok 21:57:33 i should look at those 21:57:51 (I'm curious if it'd caught my really silly mistake i just found :P) 22:00:59 which was bzero(ptr, sizeof (ptr)) instead of bzero(ptr, sizeof (*ptr)) 22:01:30 not a first error of this kind:) 22:28:08 jbk: seems a pretty reasonable thing to add 22:28:33 I think we have actually upstreamed some patches in the past as well 22:28:41 That one seems pretty generic 22:32:21 tsoome: no, but i did smack my forehead when i figured out that was causing the problem 22:32:39 (thankfully nothing in use yet) 22:45:41 on an unrelated note, has anyone done any real investigations on what i guess you'd call the patterns of mblk_ts we generate? 22:46:51 like i saw a system where we gave the NIC a 10-segment mblk_t for LRO where the segments were tiny, large, tiny, large 22:47:02 (tiny being 30-60 bytes, large being 5k+) 22:47:23 which from most of the NIC drivers i've looked at, ends up being a rather pathological case 22:47:39 though i don't know how often that was happening 23:11:25 A bunch of what we give the NIC depends on what the application is doing. 23:11:36 And then how retransmits and windows are happening. 23:32:15 related to this a bit.. if I'm using an kernel address as a key in an addr in dtrace, how do i get printa to show it as a hex value instead of int64_t? 23:32:33 show the key 23:32:35 as hex 23:32:55 I think you have to @%x or something? 23:33:13 from the dtrace book, i thought maybe 'printa("%a %@u", @a)' 23:33:19 but that doesn't seem to do it 23:33:43 unless i'm misunderstanding it 23:34:11 i read it as %@ is for the value of the aggr 23:35:53 also tried printa("%a", @a) 23:37:47 try: pfexec dtrace -qn 'BEGIN { @a[0x99] = count(); @a[0xaa] = count(); exit(0); } END { printa("%04x %@u\n", @a); }' 23:39:02 Critically your aggregation _key_ is the one that's hex, right, so you don't want to use the @ flag with _that_ one 23:39:10 the @ flag is for the aggregated result value; e.g., the count() etc 23:49:37 there we go..