01:43:54 andyf: /opt/ooce/bin/gdb spews a lot of the following on every startup: https://pastebin.com/EiXsZnib, how do i fix it? :) 01:55:59 First you must understand gdb 01:56:42 Which is usually what keeps me from making any progress with it :P 01:57:07 oh, i thought you were making some sort of zen like statement :P 02:05:42 jclulow: well, it's *before* starting to understand it :D 03:37:46 yuripv: most likely an install was copied without preserving relative timestamps between the .scm and the .go files. 03:38:14 .go appears to be the bytecode-compiled version of the .scm file 03:43:02 it's pkg://extra.omnios/ooce/developer/gdb⊙120:20230714T085149Z 03:46:33 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.. 08:00:19 sommerfeld - the packager certainly knew about those - https://github.com/omniosorg/omnios-extra/blob/master/build/gdb/local.mog#L22-L26 08:01:48 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. 08:34:15 I've published a new 'guile' package for r151047, which looks good to me, can you please test yuripv ? 08:34:16 file path=opt/ooce/guile/share/guile/2.0/ice-9/eval.scm timestamp=20230927T080707Z 08:34:16 file path=opt/ooce/lib/amd64/guile/2.0/ccache/ice-9/eval.go timestamp=20230927T080737Z 09:54:13 andyf: looks good now, thanks! 09:54:26 and it starts very fast now 10:07:51 https://www.illumos.org/issues/15926 nice, we have headers from distant future 10:07:52 → BUG 15926: uchar.h has a wrong conditional macro (New) 11:57:42 I wonder if this has ever blown up: https://src.illumos.org/source/xref/illumos-gate/usr/src/uts/i86pc/vm/htable.c?r=86ef0a63&mo=9694&fi=394#400 12:09:34 and i wonder why it's not VERIFY(), dereferencing possible null pointer below is imo worse 12:10:51 I kind of figured, KM_NOSLEEP would need pointer check anyhow:D 12:24:59 yuripv: worse in what way. it's pretty obvious what happened. 12:25:30 tsoome: if we really can't allocate there we're not going to get much further :) 12:25:46 obviously:) 12:31:19 jlevon: well, why ASSERT() it at all then 12:31:30 yuripv: I agree 12:36:00 well, ASSERT/VERIFY should denote that we are aware of potential issue, but in that case it should be VERIFY IMO 12:36:33 and then it would be good if we wont get notified by smatch:) 12:44:26 this is other kind of fun we have in few places: https://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/vm/vm_pagelist.c?r=3df2e8b2#4342 13:10:06 is that some new gcc version yelling at you? 15:28:46 yuripv no, new smatch 16:21:14 andyf: thanks for following up! 16:37:46 I've noticed that grep -R is extremely slow on illumos, at least for me in two different machines 16:37:53 Or it directly hangs 16:38:07 Do you know why that may be the case? I.e 16:39:03 /src/illumos-gate/usr/src/uts > time grep -R kbtrans_putcode 16:39:35 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 16:40:07 ~/src/illumos-gate/usr/src/uts > grep -R kbtrans_putcode 16:40:20 And it finished almost instantly, while the illumos grep is still going 16:40:59 In fact I don't recall any grep -R having finished executing, i end up ctrl-cing them after a while 16:43:39 as you did create the clone, the tree is most likely still in the cache. 16:44:03 of course, our grep may still need some love;) 16:45:09 pilonsi: The issue is that you need to specify a file. 16:45:18 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) 16:45:21 That is grep -R foo and no path doesn't do anything. 16:45:32 No, this is much simpler. 16:45:37 or, you can try 'git grep ...' 16:45:39 I bet if you run pstack on it you'll see it's waiting for input. 16:46:12 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. 16:46:14 and yes, no files means it is reading stdin:) 16:46:29 So you need to do 'grep -R kbtrans_putcode *' 16:46:58 So I'd use this as a learning exercise for a moment. 16:47:05 In another shell run pstack $(pgrep grep) 16:47:43 The first line of the stack trace is 'fee7ba37 read (0, 8323cc8, 2000)' 16:47:49 In this case we're reading from fd 0, which is stdin. 16:48:01 So it's not doing quite what you expected. 16:48:09 pilonsi: Does that make sense? 16:49:35 I did start to check for performance related updates in OpenZFS because my 3+1 raidz is sometimes slow (but not always;) 16:52:20 rmustacc: thanks for the detailed explanation! Indeed it does make more sense that you need to specify a file first 16:52:45 pstack does show feeec095 read (0, 8068630, 2000) 16:53:01 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 16:53:09 0 is stdin :) 16:53:40 (or you can check with pfiles command) 16:54:31 pfiles shows the fds open by a process right? 16:54:41 yes 16:57:05 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 16:57:15 Thanks! 17:14:52 ripgrep is pretty fast and nice to use if you do recursive grep often, it's even in the omnios repositories 17:29:23 patrikr: I'll check it out, i do use recursive grep a lot 18:18:58 Is there any issue with the ipkg.sfbay domain? I was building the BE with the changes with > pfexec onu -t 15839-test 18:19:19 But it fails complaining that it cannot resolve the hostname for ipkg.sfbay 18:20:07 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 18:21:05 When updating catalogs: Unable to contact valid package repository: http://ipkg.sfbay/on-nightly/ 18:21:21 Framework error: code: E_COULDNT_RESOLVE_HOST (6) reason: Could not resolve host: ipkg.sfbay 18:22:30 What pointed you to that domain? 18:22:44 If you're using onu you need to give it a path to the build image. 18:22:47 *built 18:23:08 that or a flux capacitor :) 18:23:40 I'm following the instructions in https://www.illumos.org/books/dev/workflow.html#testing 18:24:07 Sorry, looks like that's missing a flag that points t your local worskapce. 18:24:12 And after building and setting up bldenv 18:24:15 Aaah! 18:24:35 You'll need to use a -d to point to the built packages directory. 18:24:44 I see, thank you! 18:24:46 (but we should probably change that default) 18:25:06 That's from the sun days right? 18:25:18 Mind noting a bug about that issue on https://github.com/illumos/dev-guide/ about the wrong example? 18:25:49 Sure! 18:39:50 pilonsi: yes. that was "ipkg.sfbay.sun.com" (an internal machine at Sun) 18:47:36 damn 18:49:55 :( 18:50:22 rmustacc: https://github.com/illumos/dev-guide/issues/51 19:26:41 We should adjust onu to be clever if it's in a workspace, maybe 19:26:56 though I'm not sure if "in" means "bldenv" or "$PWD" in this case. 19:27:40 You remind me... we need to just make `ws` a wrapper-or-alias around `bldenv`. 19:30:55 really we need to delete it and ask the old folks to adjust 19:31:05 not that I haven't failed at that twice already 19:31:12 (hi sommerfeld!) 19:31:54 it's easier now the default env file is location-agnostic, though. 19:33:50 but there was some reason either sommerfeld or carlsonj convinced me that wasn't enough. 19:34:06 but also that was many years ago, so who knows if anyone remembers why, or even if I remember right. 19:35:13 [illumos-gate] 15885 fmtopo produces inconsistent output for unsigned arrays -- Andy Fiddaman 19:51:11 richlowe: I've largely stopped using it in favor of bldenv 20:03:50 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? 20:04:12 Nope, no it doesn't. 20:04:16 I wanna be able to: 20:04:20 - git clone 20:04:33 - ws my-copy-of-gate 20:04:50 - Get dropped in and started. 20:05:29 It's great for single-module development. 20:05:46 I suppose just copying an env file + bldenv is sufficient. 20:05:57 I won't whine (publically) if ws goes bye-bye. 20:06:36 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 20:12:58 eh. This is a bit funny too: https://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/io/e1000g/e1000g_main.c?r=42b53e0f&mo=136923&fi=5196#5214 20:14:39 apparently its there from 2007. 20:14:53 o/~ it's a little bit funny, this spelling inside... 20:17:54 Whoa! 20:20:02 oops. 20:22:49 this alone is good cause to make sure we do not have -Wno-unused-label :D 20:23:32 Bad accent day, 'dis is de alt' 20:25:55 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 20:27:43 Lemme try... because if THAT works, one could replace "ws" with a tiny shell script. 20:28:22 I think jeffpc finally got that done years ago 20:31:48 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 20:32:44 Stock ws on my OmniOS build environment fails in similar ways to the bldenv of $TOOLS/env/illumos.sh (namely wrong path for gcc10). 20:33:08 So hey, might be worth it to write ws-the-wrapper. 20:34:09 I think Marcel fixed it so the Perl stuff defaults now 20:34:35 the pkgvers stuff I set to . in a way that seems to (now) beat everyone again 20:34:44 that could easily go upstream in some variant 20:35:00 `PKGVERS_BRANCH=999999.$(date +%Y.%-m.%-e.%-H); export PKGVERS_BRANCH` 20:35:53 machines are fast enough now that really needs %-M on the end too 21:00:54 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? 22:00:21 danmcd, I'm curious what reason there could be to not do it? 22:02:28 It's a superstition at this point, but ISTR some BIOSes default to 32-bit. 22:03:01 e.g. one of Kebecloud's CNs was 32-bit PCI, and I think it's a default (Haswell-E era machine). 22:03:02 and i'm guessing no way to tell other than 'it breaks' 22:03:39 so... you enable it in the OS but the host says nyet and crashes? 22:03:46 but it's fixable with a BIOS setting? 22:04:44 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. 22:04:56 danmcd: I don't know of any, but I suspect you'd find out quickly if there were one :) 22:04:56 (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 :() 22:05:01 It makes sense to flip the "you have to do something to make this work" onto the older hardware. 22:05:52 * nomad once again offers the old SPARCstation LX he found in his garage to anyone who really wants to play with the old stuff. 22:07:24 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?) 23:59:15 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:) 23:59:46 mmm delaut