andyf: /opt/ooce/bin/gdb spews a lot of the following on every startup: pastebin.com/EiXsZnib, how do i fix it? :)

First you must understand gdb

Which is usually what keeps me from making any progress with it :P

oh, i thought you were making some sort of zen like statement :P

jclulow: well, it's *before* starting to understand it :D

yuripv: most likely an install was copied without preserving relative timestamps between the .scm and the .go files.

.go appears to be the bytecode-compiled version of the .scm file

it's pkg://extra.omnios/ooce/developer/gdb⊙120:20230714T085149Z

whoever packaged it should read about the "timestamp" attribute in pkg(7); what it advises about adding them to .py files should also apply to .scm files..

sommerfeld - the packager certainly knew about those - github.com/omniosorg/omnios-extra/b…/master/build/gdb/local.mog#L22-L26

It looks like this is also done in the guile package, but it's possible that it wasn't rebuilt and published at the time. I'll push an updated package to the r151047/bloody repo for you to test.

I've published a new 'guile' package for r151047, which looks good to me, can you please test yuripv ?

file path=opt/ooce/guile/share/guile/2.0/ice-9/eval.scm timestamp=20230927T080707Z

file path=opt/ooce/lib/amd64/guile/2.0/ccache/ice-9/eval.go timestamp=20230927T080737Z

andyf: looks good now, thanks!

and it starts very fast now

illumos.org/issues/15926 nice, we have headers from distant future

→ BUG 15926: uchar.h has a wrong conditional macro (New)

I wonder if this has ever blown up: src.illumos.org/source/xref/illumos…ble.c?r=86ef0a63&mo=9694&fi=394#400

and i wonder why it's not VERIFY(), dereferencing possible null pointer below is imo worse

I kind of figured, KM_NOSLEEP would need pointer check anyhow:D

yuripv: worse in what way. it's pretty obvious what happened.

tsoome: if we really can't allocate there we're not going to get much further :)

obviously:)

jlevon: well, why ASSERT() it at all then

yuripv: I agree

well, ASSERT/VERIFY should denote that we are aware of potential issue, but in that case it should be VERIFY IMO

and then it would be good if we wont get notified by smatch:)

this is other kind of fun we have in few places: src.illumos.org/source/xref/illumos…on/vm/vm_pagelist.c?r=3df2e8b2#4342

is that some new gcc version yelling at you?

yuripv no, new smatch

andyf: thanks for following up!

I've noticed that grep -R is extremely slow on illumos, at least for me in two different machines

Or it directly hangs

Do you know why that may be the case? I.e

/src/illumos-gate/usr/src/uts > time grep -R kbtrans_putcode

While that was doing its thing I waited a few minutes and then cloned the gate again to my mac, and when it finised i did the same

~/src/illumos-gate/usr/src/uts > grep -R kbtrans_putcode

And it finished almost instantly, while the illumos grep is still going

In fact I don't recall any grep -R having finished executing, i end up ctrl-cing them after a while

as you did create the clone, the tree is most likely still in the cache.

of course, our grep may still need some love;)

pilonsi: The issue is that you need to specify a file.

or, fs code for that matter, because we are missing some updates the OpenZFS have done (I have some of those in my backlog, waiting for free time slot)

That is grep -R foo and no path doesn't do anything.

No, this is much simpler.

or, you can try 'git grep ...'

I bet if you run pstack on it you'll see it's waiting for input.

That is, GNU grep (not sure about the various BSDs) will assume if you give it no arguments it should go recurse the current directory.

and yes, no files means it is reading stdin:)

So you need to do 'grep -R kbtrans_putcode *'

So I'd use this as a learning exercise for a moment.

In another shell run pstack $(pgrep grep)

The first line of the stack trace is 'fee7ba37 read (0, 8323cc8, 2000)'

In this case we're reading from fd 0, which is stdin.

So it's not doing quite what you expected.

pilonsi: Does that make sense?

I did start to check for performance related updates in OpenZFS because my 3+1 raidz is sometimes slow (but not always;)

rmustacc: thanks for the detailed explanation! Indeed it does make more sense that you need to specify a file first

pstack does show feeec095 read (0, 8068630, 2000)

i got used to gnu/fbsd grep not requiring argument if -r is specified, so i sit there waiting for illumos grep to finish :D

0 is stdin :)

(or you can check with pfiles command)

pfiles shows the fds open by a process right?

yes

Indeed if i do grep -R kbtrans_putcode . it works almost instant and if i switch terminals quick enough I can see with pfiles and pthread that it's opening other fds

Thanks!

ripgrep is pretty fast and nice to use if you do recursive grep often, it's even in the omnios repositories

patrikr: I'll check it out, i do use recursive grep a lot

Is there any issue with the ipkg.sfbay domain? I was building the BE with the changes with > pfexec onu -t 15839-test

But it fails complaining that it cannot resolve the hostname for ipkg.sfbay

If I do a dig for it I just get an authority section with the domain for a root server, and looking through dns testing websites in case it was my dns, still fails

When updating catalogs: Unable to contact valid package repository: ipkg.sfbay/on-nightly

Framework error: code: E_COULDNT_RESOLVE_HOST (6) reason: Could not resolve host: ipkg.sfbay

What pointed you to that domain?

If you're using onu you need to give it a path to the build image.

*built

that or a flux capacitor :)

I'm following the instructions in illumos.org/books/dev/workflow.html#testing

Sorry, looks like that's missing a flag that points t your local worskapce.

And after building and setting up bldenv

Aaah!

You'll need to use a -d to point to the built packages directory.

I see, thank you!

(but we should probably change that default)

That's from the sun days right?

Mind noting a bug about that issue on github.com/illumos/dev-guide about the wrong example?

Sure!

pilonsi: yes. that was "ipkg.sfbay.sun.com" (an internal machine at Sun)

damn

:(

rmustacc: illumos/dev-guide #51

We should adjust onu to be clever if it's in a workspace, maybe

though I'm not sure if "in" means "bldenv" or "$PWD" in this case.

You remind me... we need to just make `ws` a wrapper-or-alias around `bldenv`.

really we need to delete it and ask the old folks to adjust

not that I haven't failed at that twice already

(hi sommerfeld!)

it's easier now the default env file is location-agnostic, though.

but there was some reason either sommerfeld or carlsonj convinced me that wasn't enough.

but also that was many years ago, so who knows if anyone remembers why, or even if I remember right.

[illumos-gate] 15885 fmtopo produces inconsistent output for unsigned arrays -- Andy Fiddaman <illumos⊙fn>

richlowe: I've largely stopped using it in favor of bldenv

My ONLY reason for using "ws" is that a repo w/o a .env file should be able to be used for building something. OTOH doesn't bldenv w/o an env file DTRT now?

Nope, no it doesn't.

I wanna be able to:

- git clone

- ws my-copy-of-gate

- Get dropped in and started.

It's great for single-module development.

I suppose just copying an env file + bldenv is sufficient.

I won't whine (publically) if ws goes bye-bye.

I have a "local.env" I drop into the root that drops a half-dozen environment variables on top of usr/src/tools/env/illumos.sh

eh. This is a bit funny too: src.illumos.org/source/xref/illumos…c?r=42b53e0f&mo=136923&fi=5196#5214

apparently its there from 2007.

o/~ it's a little bit funny, this spelling inside...

Whoa!

oops.

this alone is good cause to make sure we do not have -Wno-unused-label :D

Bad accent day, 'dis is de alt'

danmcd: the template 'illumos' env file should default everything properly, so you can 'bldenv illumos' or 'bldenv usr/src/tools/env/illumos' and get running

Lemme try... because if THAT works, one could replace "ws" with a tiny shell script.

I think jeffpc finally got that done years ago

it's almost there. my local.env sets PKGVERS_BRANCH and a bunch of PERL_* variables - all needed to build packages I can install on top of openindiana

Stock ws on my OmniOS build environment fails in similar ways to the bldenv of $TOOLS/env/illumos.sh (namely wrong path for gcc10).

So hey, might be worth it to write ws-the-wrapper.

I think Marcel fixed it so the Perl stuff defaults now

the pkgvers stuff I set to <bignum>.<datestamp> in a way that seems to (now) beat everyone again

that could easily go upstream in some variant

`PKGVERS_BRANCH=999999.$(date +%Y.%-m.%-e.%-H); export PKGVERS_BRANCH`

machines are fast enough now that really needs %-M on the end too

I have a possibly really dumb question: Is there ANY reason in 2023 for (even older) machines to NOT enable full-64-bit PCIe addressing?

danmcd, I'm curious what reason there could be to not do it?

It's a superstition at this point, but ISTR some BIOSes default to 32-bit.

e.g. one of Kebecloud's CNs was 32-bit PCI, and I think it's a default (Haswell-E era machine).

and i'm guessing no way to tell other than 'it breaks'

so... you enable it in the OS but the host says nyet and crashes?

but it's fixable with a BIOS setting?

If 64bit is a major speed improvement and I have to do something (manually) to enable it in all my modern hosts then ... yeah, I'd prefer it be default at this point.

danmcd: I don't know of any, but I suspect you'd find out quickly if there were one :)

(speaking of breaks, it appears intel's server platforms took a cue from a certain hades-adjent vendor and blocks correctable memory events to the OS :()

It makes sense to flip the "you have to do something to make this work" onto the older hardware.

there is an intel 'RAS' pci device though... i thought I saw something that it might handle some of this (maybe just needs a driver to allow the OS to see the DIMM correctable errors?)

tsoome: apparently when we were doing the work to remove -Wno-unused-label from our builds, we found 4 different misspellings of default to fix (defaul: deault: defult: delaut:)

mmm delaut