Anyone have access to a Solaris 11.4 system? What I'm after are the values of AV_HW1_IDX and AV_HW2_IDX, defined in /usr/include/sys/auxv.h (or possibly /usr/include/sys/auxv_SPARC.h)

if they're indices, probably 0 and 1.

hopefully alanc or someone can check

oh, peter isn't here anymore

that's a shame, I was wondering what could possibly be consuming that.

oh, I missed his earlier question

#define AV_HW1_IDX 0

#define AV_HW2_IDX 1

#define AV_HW3_IDX 2

yeah, they're indices used with getisax so they're 0, 1, etc.

oh, you beat me to it. thanks alan.

getisax annoyed me recently

yeah, I'd have thought the mapping of individual bits to each index in /usr/include/sys/auxv_SPARC.h would be the more interesting part

(right now, nothing on SPARC is in HW3 - we had to add that for Intel)

I'm going to hit HW3 on arm conceptually soon

and with HW3 already using 24 of 32 bits, may need HW4 in the future

intel already did.

alanc: see msg for '32 bits' I'm so annoyed by that choice.

I would have thought ptribble knew the trick to getting files out of pkg.oracle.com by looking up their hash in the pkg manifest

[illumos-gate] 15471 replace csh based which(1) with implementation in C from BSD -- Dominik Hassler <hadfl⊙oo>

Thanks hadfl

nice:)

andyf: I have no idea what my gerrit +1 did to say "This change is ready for review", but if I accidentally kicked it out of draft, I'm sorry.

Thanks, I forgot to undraft it

ok, well I'm sorry, but also you're welcome

we can trade

just looking at the 15471 change (post-push), we no longer need the .descrip file?

y'all sure do spend a lot of time reviewing stuff _after_ it integrates sometimes.

fenix help me with links to issue 15471 please

FEATURE 15471: replace csh based which(1) with implementation in C from BSD (Closed)

↳ illumos.org/issues/15471 | code.illumos.org/c/illumos-gate/+/2710

richlowe: :D

The THIRDPARTYLICENSE.descrip? I think they're necessary

andyf: yep, that's what i meant

The usr/src/pkg/Makefile processes them, so it's still needed

I think yuri is saying it went missing

The change updated THIRDPARTYLICENSE but the existing .descrip was fine

ah ok!

(sorry, just looking at the list of the files and didn't notice it's "M" and not "A" for thirdpartylicense)

np, I misunderstood what you were asking too

rmustacc: have you seen with ixgbe where when you create a vnic, the vnic gets multiple TX rings, but only a single RX ring (which obviously can have performance implications)

is that something known?

I don't know about this particular situation, but there are a limit on the number of groups that exist.

A mac client would be assigned a group with some number of rings.

s/client/device

I have an old (and still working!) Sun Fire X4500 that hangs while booting modern versions of SmartOS. I narrowed the issue down to the change from 20210729T002724Z, which boots & runs, to 20210812T031946Z which hangs during boot. The 20210812T031946Z release includes the Illumos update where the TSC calibration was moved earlier in the boot

process: illumos.org/issues/13354. I'm not sure if that's a red herring or not. When it hangs, I'm unable to get back to kmdb using F1-A / Shift-Pause or using an NMI. I've roughly narrowed it down to a call to do_bsys_doint during startup:

fffffffffbc8a140 do_bsys_doint()

fffffffffbc8a1a0 read_firstblock+0x46(80)

→ BUG 13354: illumos should calibrate the TSC earlier in the boot process. (Closed) | code.illumos.org/c/illumos-gate/+/1097

fffffffffbc8a1f0 startup_bios_disk+0x82()

fffffffffbc8a220 impl_setup_ddi+0x175()

fffffffffbc8a230 create_devinfo_tree+0xaf()

fffffffffbc8a240 setup_ddi+0x13()

fffffffffbc8a2c0 startup_modules+0xec()

fffffffffbc8a2d0 startup+0x5a()

fffffffffbc8a310 main+0x36()

fffffffffbc8a320 _locore_start+0x90()

Is this the appropriate place to ask for help with continuing to debug this issue, or would the Illumos developer list be more appropriate?

Both really, but perhaps at this time of day the mailing list.

Thanks!  I'll join & post to the mailing list.

there is the prom_debug you can enable

that + verbose boot should show all of the TSC calibration stuff

IIRC, it also will show the value, so you can see if it's sane or not

Yes, I have prom_debug set and it gets past startup_tsc() in startup.c.  It reports "TSC calibrated using PIT; freq is 2791 MHz" which sounds good.  It's got two Dual Core AMD Opteron(tm) Processor 290's running at 2.8 GHz.

It's very similar if not the same to the following post from last year:  illumos.topicbox.com/groups/omnios-discuss/T2d6ff4b7ea30bb00

if you can boot a DEBUG build, there's also the biosdebug tunable

from your stacktrace, it's calling read_firstblock()

I haven't tried that!

there's nothing obvious to link the two that i'm aware of.. the only thing as far as the PIT code is concerned is it does add an additional test to try to tell if the PIT is operational

yeah, that's where it's trying to read sectors from the first hard drive.  The system boots via the network using ipxe, and has four network ports and then an external usb drive as boot options.

since there are some systems now that don't have PITs, and there's (AFAIK) no way to actually tell other than 'try it, and assume busy-waiting by some amount should be long enough to see the counter value read from it change if it's working'

Can you send me pointers on getting or building a DEBUG build?  My thoughts where weird TSC issue, bios bug, or some bios configuration error.

danmcd might have one handy..

have you built smartos before?

No I haven't but I'm more than willing to give it a try.  I'm pretty sure I've seen the documentation online on building it.

github.com/TritonDataCenter/smartos-live#building-smartos -- not sure if there's any more recent docs

Here I thought I was the last person using thumpers. (I have 5 in production)

for a DEBUG build, you run ./configure -d

Ha!  I also have a Sun Fire X4540 running, bit I haven't tried upgrading it once I ran into my current issue.

Thanks, I'm going to try building a debug build either later tonight or tomorrow at work.

oh wait, I only have 3 of the 4540s in prod. The 4500s are halted, DBAN'd, and flagged for surplus.

The only other Sun relic I have running is a Sun Fire X4100 M2, but it's currently running linux.

I need to get that through my thick skull.

(I have enough spare parts I could put 3 more 4540s in prod but they're officially 'parts only' so $PI doesn't Get Any Ideas)

Actually, the X4540 is connected to a Sun Storage J4400 and using multipathing all running on SmartOs