[illumos-gate] 15599 smb_opipe_transceive uses a lot of stack -- Gordon Ross <gordon.ross⊙tc>

alanc: do you still have anything approaching a desktop on x86?

I can't remember what's disappeared

yes

do you know which vuid modules are useless now?

it feels like vuidm*

I'm typing this on a GNOME 41 desktop running on a Solaris x86 box

are probably all serias

serials

but I have a deep and abiding suspicion of shit that may lurk in laptops and whatever.

so maybe they have users, but also maybe vuidps2 is useless too

yeah, we still ship vuid2ps2, vuid3ps2, vuidm3p, vuidm4p, & vuidm5p, but I suspect that's because no one has put in the time to figure out which are still relevant in an x64-only world

ah, not just me then :)

at one point, laptops used PS/2 for the builtin keyboard & trackpad/pointer device, even if they had no external PS/2 ports, but that may have gone away with legacy BIOS support?

the serial bus mice modules seem even more likely to be irrelevant in this millenium, but hard to tell without doing a "drop them and see who screams" test

[illumos-gate] 15714 stmf: the comparison will always evaluate as 'true' -- Toomas Soome <tsoome⊙mc>

alanc: I think I removed most of the support for our serial mice already, but not all of it

unfortunately, vuidmice(4D) is from the past

it strongly implies they're all useless, but also uses the wrong device names in general to do it.

what IS_P2ALIGNED() (that is described as checking address alignment) checks exactly when used on non-addresses? e.g. ASSERT(IS_P2ALIGNED(len, pgsz)), where len is size_t

#define IS_P2ALIGNED(v, a) ((((uintptr_t)(v)) & ((uintptr_t)(a) - 1)) == 0)

the same thing that it does to the numeric value of a pointer

IS_P2ALIGNED(sizeof(foo), 1024) -> is sizeof(foo) a multiple of 1024

only works if the 2nd arg is a power of two.

got it, thanks (making sure i understood it correctly)

(2^N) - 1 represented in binary is N-1 consecutive 1 bits, so, assuming a is a power of 2, (v & (a-1)) will be zero only if the (n-1) low order bits of v are all zero.

yep, thanks, i somehow misunderstood what P2 means exactly here and was confused by comment above

now it is all obvious :)

yes, this is all about avoiding integer division.

asking as i saw this: Assertion failed: IS_P2ALIGNED(udpEntrySize, sizeof (mib2_udpEntry_t *)), file netstat.c, line 2257, function mib_get_constants

when netstat is built without -DNDEBUG

and it seems to be a regression, does not do this on somewhat older codebase (now to find what exactly broke it)

hard to believe we're about to hit 18 years of blaming stevel for all the bugs in code like this that still bears his name: github.com/illumos/illumos-gate/blo…aster/usr/src/stand/lib/sa/malloc.c

It is neat how malloc() tracks the size of allocations by overallocating to store the size right before the allocation. I recall catching a free() last year that returned a pointer offset into the allocation to free(). I can see now that was a real bug, rather than just a hypothetical one.

That is unless there is some other malloc() in the codebase that does things differently.

yuripv, sommerfeld: we have had issues with typo promotion in those macros

uh, type promotion

what a day

ryao: there's like a million different mallocs that do things

as alanc can tell you :)

yuripv: so if you're debugging it seeming to give surprising results, consider the widths of your types.

hayashi fixed it with typeof() magic I think looks good, but was hoping rmustacc or someone standards smart would confirm for me.

I fixed the one that was most problematic with a cast and a sweary comment.

While we are reminiscing, I saw an old Sun promotional video last night that referred to Sun's data centers as ranches. Did that terminology persist until the Oracle acquisition?

we had a "compute ranch" well after the acquistion - there's still some remnants of it in "CR" abbreviations in various things

richlowe: now i'm just trying to find why it worked previously and doesn't now

(have that netstat code reused and it suddenly started hitting that assertion on new illumos codebase)

It's what became the SP2.

a bunch of RS-6000s being managed by shell scripts and rsync, complete with batch system.

yuripv: look at types and signedness, I don't think the macro change relevantly

That would have been 1991-92ish.

but also I'm very paranoid about that, because debugging it was hellish

It is a shame that Oracle outbid IBM for Sun. Things would have been better under IBM ownership.

until I realized the wrong value was precisely the bitwise-opposite of the correct one, and it had gone negative

One more thing about the past, why did Sun Grid fail while AWS succeeded?

i was one told (by an ex-IBMer) the difference between a desktop, server, and SP2 node was the orientation of the case :)

another instance of Sun doing almost the right thing a decade too soon, and then neglecting it

see also thin clients, and various other stuff.

thin clients a decade too late _and_ a decade too soon

you can argue about when "then network is the computer" became both true, and also a good thing.

jbk, sounds about right.

oh, also blade systems

but I don't know if Sun did that early, or just neglectfully

also, SP2 nodes are in coffins, to differentiate them from servers and workstations.

yes i remember those

sprint had (at the time) a fairly large SP2 cluster for their CDR archive.. which was two doors down from my cubicle

had to power that up after a contractor mistook the covered EPO switch for the light switch

well a group of us

I feel like phone companies and those interacting with them have kept a lot of weird shit alive, over the years.

for better or worse

the same contractor was then caught standing on top of one of the disk cabinets for it

jbk: I once heard about some guys in a datacenter throwing empty boxes in a space right next to where they had the big red button. One day, a box hit the button.

(also those put out enough heat to warp the floor tiles in front of it)

jbk, we had that happen at IBM Research's server room.

The mainframes took hours/days to come back online.

We waltez in, hit the power buttons on the RS-6000s and waltzed back out.

we got pretty good at swapping out disks on that though

They ... were not happy with us.

because they were from a bad batch

so we had 2-3 fail per day, every day, for like 18 months

I remember Solaris 10 being somewhat slow to boot. I guess that was fast compared to a main frame.

you mean IPL :)

yay, someone else who knows about IPL!

solaris 10 was very fast to boot if you have no hardware

the zones people did a lot of work there

and the SMF people

if you _do_ have hardware, you're at its mercy

heh.. the guy that ran the datacenters always called the storage DASD :)

we also had an S/390 that you would get _very_ harshly chastized by directors and VPs if you called it a mainframe

This might explain why Sun Grid failed... these restrictions basically meant you needed Sun hardware locally to use it: en.wikipedia.org/wiki/Sun_Cloud#Suitable_applications

jbk: Why is it not a main frame?

because the 'not a mainframe' was running unix system services

I was comparing SGE to condor for $job[0] when they changed the rules for SGE so we couldn't use it.

S/390 is a mainframe, don't care what OS it's running.

Most of AWS' customers never had Sun hardware. In fact, many of them likely have Wintel machines...

Sheehs, that's the whole point of the VM layer they invented in the 70s.

yes, but teh CIO at the time had declared they woudl only use 'open systems' (i.e. no mainframes).... probably because of the cost

so no one was allowed to call it that :)

ah, got it.

No making mainframes into open systems?

so we just called it the 'not a mainframe'

the code for the s/390 opensolaris is still around

though obviously as out of date as that implies

I had no idea OpenSolaris ran on the s/390.

that's news to me as well.

the 'not a mainframe' ran the code that was basically a giant, single RPC hub between every single IT system

I thought it was a SPARC/x86 exclusive. Is the m68k code still around too?

Closest I ever got to a "mainframe running Solaris" was the E10K (am I remembering that right) that I managed to dodge responsibility for.

S/390 never integrated to the mainstream codebase, was always a seperate porting project

eventually it was migrated to an HP superdome (I.e. their 'oh shit' clone of an E10k :P)

I think there's a few m68k #ifdef's that never got fully deleted, but the bulk of that code, like the 32-bit SPARC code, was never released

Sine Nomine Associates ported it to S/390

That is an odd name. :P

Illumos runs on ARM, RISC-V and Alpha too now

Although I'm not sure everything has been integrated yet

Awesome. I did not realize it had gained support for other architectures... wait, how did porting to Alpha work considering that the barriers in the code were never designed for Alpha's memory model.

I didn't think anything but x64 was in the illumos gate today (well, and the SPARC remnants in the process of being deleted)

be cool to see something on RISC-V. I've been wanting to play with that.

Is SPARC support being removed?

nothing except x86 today

When did that happen?

arm is making pretty ok progress

riscv needs someone to do what we've been doing for arm, but for riscv

It's been a few months to years i think, ryao

RISC-V hardware is less than ideal and QEMU's RISC-V emulation is buggy. :/

github.com/illumos/ipd/blob/master/ipd/0019/README.md - "Sunset SPARC"

→ IPD 19: Sunset SPARC (published)

I can hope. I just don't think my skin tone being blue would be attractive.

You can, if you want, fork the project and port back to SPARC. I know I would like to - and never will

/nick notadev

Some information on the qemu bug: seL4/seL4 d11179e

easier to just use the out-of-tree SPARC support being maintained by Tribblix & OI than to re-do the port yourself

jbk: unix mainframe hours xd

wait what

Tribblix runs on SPARC, just from the last commit that built out of the box.

I ought to add a few more recent commits, but there's little current work that's at all relevant for SPARC.

Klaus and Peter are both (together?) (separately?) working on SPARC-ing

Hopefully they pick up the cross stuff we did for arm, etc.

fenix: IPD40

IPD 40: Cross compilation for illumos (draft)

↳ github.com/illumos/ipd/tree/master/ipd/0040/README.md

so someone still has a fire alight for it, it's just not on mainline anymore

neat

I'm treating it as frozen for the moment; Klaus is more interested in keeping current.

yeah, nobody is against it coming back even, if it comes back in a way that's maintainable

that's why the cross-build stuff etc is important.

IPD 19 mentions that removing SPARC support would enable the use of Rust. That is a bit odd to me, since illumos SPARC support is listed here: doc.rust-lang.org/rustc/platform-support.html

Why was the compiler stuck at GCC 4.4.4 for SPARC?

→ BUG 2757: 32bit sparc direct system calls should not rely on compiler mannerisms (In Progress)

Is the SPARC support for newer machines current?

I think only OpenBSD has support for the newer machines apart from Solaris 11

there is no sparc for newer machines

I think someone or other booted it as naked sun4v, but anything beyond that isn't there

nobody has them, the people who do have them haven't had time.

We don't have support for hardware released after the gate was closed. So T4 works (and works well) but nothing newer.

the naming of the gate as the gate is oddly poetic in this case

the naming of the gate as the gate is deeply historic

i am well aware

if the old TeamWare white paper is still around, it describes what the ON group stopped doing anymore because it sucked

I am not aware.

it the mid 90s

I was intrigued to find that we shipped the ddi_dma_set_sbus64.9f manual on x86

I mean, SBus? On x86?

And it's not just the man page, the function is even implemented.

was there maybe some prototype x86 system w/ sbus that made it to market?

And the emlxs driver uses it, which is probably something that can be cleaned up.

I presume emlxs just didn't bother to hide that code behind #ifdef sparc

I don't know when the per-group gates went away and everyone just started integrating to the central gate for the release - before my time (except for specific project gates for large team projects)

alanc: that's the change over bonwick is referring to in the Quality Death Spiral document

re: "no more gate merges"

ah, right

best EPO accident I remember witnessing was at MIT in the mid-80's. electrician reportedly dropped a ladder on the EPO button. and then they discovered that something had been miswired in the EPO system and they couldn't turn power back on right away-- they spent a good long time with the front cover of the breaker panel off before the machine room had power again...

at least the electrician was quick to respond to the service call.

I slightly mis-remembered the one at research. He wasn't looking for the light switch but the 'push here to unlock the door' button.

the one that was *very clearly* labeled.

No, they had to call in better electricians to fix it.

"Isn

"Isn't it ironic, don't you think?"

and yes, the usr/src/stand/lib/sa/malloc.c I pointed to earlier is a very simplified malloc for standalone code (i.e. not userspace or full kernel), so does things differently than the 8 other malloc implementations in the gate (well, in our gate, I've not counted in illumos')

and it has at least one bug the others don't

two if you count the claim to follow malloc(3c) since passing a size of 0 to realloc() doesn't just free the existing buffer, but that's not something sane code should be doing

Who is working on the RISC-V port?

I want to suggest trying to get it running on a FPGA RISC-V softcore like this guy did with Linux: github.com/litex-hub/linux-on-litex-vexriscv

I have my fingers crossed that open source hardware will let us get fully open source computers in the future. This just needs display hardware and then it could be fabricated for free through Google to produce a fully open source machine: github.com/enjoy-digital/litex developers.google.com/silicon

I guess there is a bit more that would be needed, like PCB designs and some other components, but it is just a thought that has been on my mind as of late.

If this piques anyone's interest, there are some higher end open source RISC-V core designs here that could probably be added to LiteX to get something more performant than the current selection of cores: github.com/T-head-Semi

And an open source display port implementation: github.com/hamsternz/DisplayPort_Verilog