richlowe: 15961. strip -x is what I'm using on all files

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.

What is calling strip on the .rlib prior to the linking step?

> 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.

I'm guessing that GNU strip doesn't do this, and perhaps ours should not either in the presence of '-x'

Either that, or we need to add a sentence against the -x option in strip(1) to clarify.

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

I already skip *.a so adding *.rlib wasn't a big deal

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

[illumos-gate] 15959 race condition in devfs_readdir causes panic -- Andy Fiddaman <illumos⊙fn>

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 ?

Honestly, my first instinct is to ask what's wrong with your machine where a non-parallel illumos build is causing thermal failure?

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?

This feels like a HW problem.

hide the box from the sunlight, sometimes it helps :)

denk hahha, I tried compiling at night when is freezing here, did not work :)

danmcd yes, I need better thermal paste maybe but illumos is the only build that failed on this machine due thermal shutdown

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

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

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).

you can try to configure the syslog to send messages to another server, it could help to detect a problem

[illumos-gate] 15958 swap: clean up build -- Toomas Soome <tsoome⊙mc>

hrm...

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?

or what would be something to look at?

(the poll is failing approx 10,000x/sec)

jesus loo

lol

that is a lot

yeah

basically there's always a 9k packet available

At least at face value it feels like there is something missing in how we decide to poll there

but mac is asking for < 9k

well about 50% of the time mac as asking for <9k

Yeah I would figure out how it comes up with that number

this is a somewhat heavy workload

it is across multiple rings and 2 nics (in an aggr), so the per-ring rate should be lower

(and it's almost all NFS traffic, so not going out to userland)

does ::typedef -r override any existing CTF definitions?

jbk: In general ::typedef has its own CTF container that all such type definitions go into.

The ::typedef -r just iterates over all types in a file and adds them to said container as well.

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.

tsoome: (since you've messed with it the most recently :P) does smatch allow for adding custom checks?

as like extensions

so we could add custom things w/o having to basically do it as a fork (and worry about merging, etc)

I havent seen any support for that

I havent really been searching for that either

but we do have added illumos specific tests already

check_cmn_err.c for example

ahh ok

i should look at those

(I'm curious if it'd caught my really silly mistake i just found :P)

which was bzero(ptr, sizeof (ptr)) instead of bzero(ptr, sizeof (*ptr))

not a first error of this kind:)

jbk: seems a pretty reasonable thing to add

I think we have actually upstreamed some patches in the past as well

That one seems pretty generic

tsoome: no, but i did smack my forehead when i figured out that was causing the problem

(thankfully nothing in use yet)

on an unrelated note, has anyone done any real investigations on what i guess you'd call the patterns of mblk_ts we generate?

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

(tiny being 30-60 bytes, large being 5k+)

which from most of the NIC drivers i've looked at, ends up being a rather pathological case

though i don't know how often that was happening

A bunch of what we give the NIC depends on what the application is doing.

And then how retransmits and windows are happening.

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?

show the key

as hex

I think you have to @%x or something?

from the dtrace book, i thought maybe 'printa("%a %@u", @a)'

but that doesn't seem to do it

unless i'm misunderstanding it

i read it as %@<fmt> is for the value of the aggr

also tried printa("%a", @a)

try: pfexec dtrace -qn 'BEGIN { @a[0x99] = count(); @a[0xaa] = count(); exit(0); } END { printa("%04x %@u\n", @a); }'

Critically your aggregation _key_ is the one that's hex, right, so you don't want to use the @ flag with _that_ one

the @ flag is for the aggregated result value; e.g., the count() etc

there we go..