Turn_Left has quit [Read error: Connection reset by peer]
dude12312414 has joined #osdev
MiningMarsh has quit [Ping timeout: 250 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
<zid>
kazinsal: Hence avx10
<klys>
cpuinfo on my epyc3 box lists avx and avx2
SGautam has quit [Quit: Connection closed for inactivity]
xenos1984 has joined #osdev
wblue has quit [Quit: wblue]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
[itchyjunk] has quit [Ping timeout: 246 seconds]
smeso has quit [Quit: smeso]
smeso has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<geist>
computers! amirite?
Yoofie has quit [Ping timeout: 244 seconds]
Yoofie has joined #osdev
carbonfiber has quit [Quit: Connection closed for inactivity]
<kazinsal>
*nods sagely* computers.
<geist>
hows your vax been doing?
<kazinsal>
a capacitor in the power supply went pop, so I need to tear it down and recap it
<kazinsal>
was fiddling around in the monitor one day and suddenly the console went dead and there was the distinctive smell of dead capacitor in the air
<zid>
is new vax smoke expensive?
<kazinsal>
probably not, I'd expect there's probably only 10-15 caps on the power supply board
<kazinsal>
but if something is going bad on the motherboard, it's going to definitely be expensive smoke
slidercrank has joined #osdev
<zid>
ah, generic smoke
Vercas has quit [Quit: buh bye]
Vercas has joined #osdev
<geist>
yeah that psu in it looks like a beast
<geist>
might be pretty interesting to get it open
<geist>
i did some surface mount soldering the other day, pretty proud of
<zid>
I've seen beefy caps in weird voltages cost like $40/ea
<geist>
some 0603 resistor and caps
<zid>
so it's not unreasonable that it might cost a lot to fix
<bslsk05>
Note by Wayland.social: "Welcome to Wayland.social: the successor to X.com."
goliath has quit [Quit: SIGSEGV]
<Ermine>
Nice
<sham1>
It does make sense
slidercrank has quit [Ping timeout: 260 seconds]
<Ermine>
Someone has also to joke about X-COM
<sham1>
If I use X, will I be an x-man?
zxrom_ has joined #osdev
zxrom has quit [Ping timeout: 245 seconds]
goliath has joined #osdev
slidercrank has joined #osdev
benlyn has joined #osdev
benlyn has quit [Client Quit]
benlyn has joined #osdev
GeDaMo has joined #osdev
danilogondolfo has joined #osdev
[itchyjunk] has joined #osdev
andydude has quit [Ping timeout: 250 seconds]
<zid>
oh, random fuzxxl encounter in the wild
<zid>
he's got the top commenton a random old vid I rewatched
[itchyjunk] has quit [Read error: Connection reset by peer]
<moon-child>
remember the good old days
<moon-child>
when fuzxxl was just fuzxl
zxrom_ is now known as zxrom
<zid>
before he got double fat?
heat has joined #osdev
nyah has joined #osdev
vai has quit [Ping timeout: 245 seconds]
Burgundy has joined #osdev
<kazinsal>
staring trying to find out from the worst technical documentation how to implement the 4th edition Unix filesystem
<kazinsal>
grr
<GeDaMo>
Use the source, Luke?
<sham1>
The code is the documentation
<clever>
in my case, the code just says use 5682 for 19.2mhz, and no explanation of why, lol
<clever>
if i correctly use 5682, i get a SOF interval of 125uSec, 8khz, as the usb specs say
<clever>
if i try 5683, i get an SOF interval of ~122.6, 8156khz
<clever>
but i cant find a clear linear relationship between those numbers
<Affliction>
yay, PLLs?
<zid>
so it's not a divisor?
<zid>
it looks like one with those two numbers
<zid>
45.464
<clever>
5695 gives 99 uSec or 10101Hz
<clever>
5648 gives 390.8uSec or 2558Hz
<zid>
It might have control bits mixed in
<clever>
i tried using a bitmask to select the lower N bits, but still no obvious pattern, for every N
<zid>
like, it might be bit 3 is a /10, but bit 0-2 are an integer, or such
<clever>
and if i go too low (2000, or 5200), it goes completely off the rails
<zid>
You'd need to test a fuck load of values imo
<zid>
at least, flipping every bit
<clever>
yep, thats why i added code to raise/lower the divisor by 1, and report the avg SOF interval
<clever>
ive graphed 5648 thru 5695
<clever>
and it looks pretty linear so far
<zid>
but those all contain the 2048 bit
<clever>
yeah
<zid>
err 4096
<zid>
knowing the base clock would be a cheat too
<clever>
19.2mhz i believe
<zid>
solves one of the simultaneous equations in advance
<heat>
kazinsal, those filesystems are all horrendous
<heat>
they even adjust based on the fucking CPU
<heat>
although i looked at v7, but i dont imagine param.h is any less cursed in v4
<clever>
zid: hmmm, looking over the numbers again, as this mystery number goes up, the SOF freq also goes up, so its not a divisor, but a multiplier, refclk * mystery == sof_freq
<clever>
and behind the scenes, a PLL just implements that as sof_freq(vco)/mystery == refclk, via the PLL
<clever>
and that does come out to 159hz refclk, when masking with 63..., but that seems rather slow
<zid>
160 ish yea
<zid>
but it might be a selector bit and 4096 is something else, again
<zid>
so it's actually like 200 * n not 4200 * n
<zid>
which makes it a few khz instead of 160 ish
<clever>
5633 made a huge step, to 44.9 usec or 22,271 Hz
<zid>
Time to write a script to boot the pi on all 64ki values and record what happens
<geist>
kazinsal: hmm, is it approximately FFS? or some completely different design?
<clever>
no need to reboot, i can just change it on the fly
<geist>
i forgot when FFS got stamped out
<zid>
it might crash? :P
<geist>
and dunno if it's based on anything previous
<clever>
zid: if i change the mystery number by even +/- 2, i get a transfer error from the usb controller, it was polling an interrupt endpoint
<geist>
wikipedia says FFS is roughly based on unix v7 FS so okay
<clever>
but it keeps on sending SOF's out at the wrong rate, likely the wrong symbol rate too
<heat>
yeah FFS is BSD isn't it?
<geist>
4.2BSD it seems
<kazinsal>
what I'm doing is between v4 manual filesystem and 4BSD FFS
<bslsk05>
docs.google.com: pll control - Google Sheets
<kazinsal>
physical structure of a standard classic BSD filesystem but with a much more regressive physical implementation backing it
<clever>
zid: column F is the input i put into the hw, and then column E is the interval i measured
<heat>
kazinsal, early BSD's filesystem is literally v7's filesystem
<clever>
in rows 10/11, there is a very clear step, where it stops being linear, but thats at 0x1603 to 0x1604
Lian has joined #osdev
<Lian>
boo
<heat>
both of which really are garbage filesystems anyway
Yoofie4 has joined #osdev
<zid>
5 values in a row giving #DIV/0 is strange
Yoofie has quit [Ping timeout: 260 seconds]
Yoofie4 is now known as Yoofie
<zid>
You'd expect a power of 2 if any control bits were in there
<heat>
also they really liked using octal in early UNIX and fuck that
<clever>
zid: those are because i havent measured the SOF interval for those rows
<zid>
oh right
<clever>
but it does seem like the VCO has bottomed out
<clever>
rows 11-14 are all giving the same interval
<clever>
which is also visible in the graph near row 70
<clever>
at 0x1609, it starts to leave the floor
<clever>
zid: hmmm, nothing i do to the numbers, makes any sense out of them
<sham1>
heat: octal good
Yoofie has quit [Ping timeout: 264 seconds]
Yoofie has joined #osdev
<clever>
zid: at 512, its either not ticking, or too slow to even do 1 usb transfer, at 1024, its ticking fast enough that the interrupt endpoint failed due to the wrong bus rate
slidercrank has quit [Ping timeout: 264 seconds]
joe9 has quit [Quit: leaving]
vai has joined #osdev
Terlisimo has quit [Quit: Connection reset by beer]
slidercrank has joined #osdev
lanodan has quit [Quit: WeeChat 3.8]
lanodan has joined #osdev
<clever>
i think i just need some sleep, this is very clearly a linear relationship, but i just cant math at 7am, lol
Terlisimo has joined #osdev
eroux has quit [Ping timeout: 250 seconds]
gog has joined #osdev
eroux has joined #osdev
<gog>
hi
eroux has quit [Ping timeout: 244 seconds]
eroux_ has joined #osdev
eroux has joined #osdev
eroux_ has quit [Ping timeout: 264 seconds]
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<zid>
omg did you guys hear that elon musk is re-launching X.org
<zid>
Wayland sucks, X11 for ever
<zid>
(The logo is like, super similar, so I assume he's talking about Xorg)
<nortti>
X.com, the corporate fork of X.org
MiningMarsh has joined #osdev
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
<Lian>
The Xorg mastodon account also suffered a hostile takeover by the freedesktop trolls who now advertise Wayland and talk down to X users.
<Lian>
It's quite unsportsmanlike
<nortti>
lol
<gog>
i can't go back to X, i like not having screen tearing
<gog>
sorry
<gog>
freesync also does not work at all not even a little
<zid>
I'd like to not have tearing too, sadly W10 isn't enough
<zid>
It's a little better than W7
<zid>
but the dirty rectangles impl is still buggy with overlapping windows
<zid>
video players etc behind other windows can cause scrolling the top window to tear
<gog>
once again linux beats windows at a thing you think it wouldn't
<gog>
SO SAD
<zid>
I mean, the problem with linux is that it's a diaspora
<zid>
so it might be better, it might be worse
<zid>
depends on the day of the week
<gog>
my linux
<zid>
windows is fairly standardly 60% all of the time
<gog>
the linux specific to my configuration
<zid>
The things that are broke have been broken since win2k
<gog>
my unique special snowflake of an operating system
<zid>
Like, you can still move the taskbar while it's locked on w7, they never fixed that throughout its entire lifespan
<sham1>
So it's not actually locked
<sham1>
What kind of chicanery is that
<zid>
it's locked *most* of the time
<zid>
but there's some flag issue or race condition or something
<zid>
where very occasionally if you click to select something on the taskbar while moving the mouse a few pixels, like you might accidentally do
<zid>
the taskbar can get stuck to your mouse
<gog>
taskbar glomps mouse pointer
<zid>
plus that afforementioned tearing issue
<zid>
afformentioned?
<zid>
spellig us hurd
<gog>
who
<zid>
gnu/hurd
<gog>
no such thing
<gog>
you made that up
<zid>
gnu/gnu
<zid>
bison/hurd, flex/gaggle
<zid>
yacc/windows
<sham1>
hotel/trivago
<Lian>
brille/fielmann
<gog>
cool pronouns
<Lian>
i have the coolest pronouns
<Lian>
in the whole wide world
<gog>
cool/cool ?
<Lian>
nah
<Lian>
idk actually
<gog>
valid
<zid>
My pronouns are the entire contents of war and peace, and "him"
<Lian>
if the entire contents of war and peace feels that is right for him, of course i support him
<zid>
you can shorten the war and peace part to "he" though, it's short for 'pierre bezukhov'
<zid>
I'll know whether you meant it as 'war and peace but abbreviated' or 'he' when you say it aloud, so make sure you think really hard about war and peace while you say it
heat_ has quit [Read error: Connection reset by peer]
<zid>
For bonus points, shoot someone in a duel and join the freemasons
heat_ has joined #osdev
<gog>
i already did that
xenos1984 has quit [Read error: Connection reset by peer]
<sham1>
Instructions unclear, joined FreeDOS instead
<zid>
gog: That's because you're a friendly person
<zid>
sham1 over here always gets my pronouns wrong on purpose to spite me, hasn't once shot anybody in a duel
<mjg>
extra points for this loller being *inlined*
<mjg>
that's some 10% pure code
<mjg>
faster motherfucker
<Bitweasil>
Ew. I just tried the zenbleed demo on a few of my boxes that are vulnerable CPUs. That's terrifying to watch in action.
slidercrank has joined #osdev
<geist>
was thinking, i guess if you disable SMT it should be pretty clear right? or can you still read stale register data out of the register file from some previous context switch?
<heat>
they say disabling SMT makes no difference because all cores share the register pool thingy
<geist>
except they dont, the register file is shared between threads, the cores are still separate from each other
<Bitweasil>
Context switch can leak.
<Bitweasil>
A lot less than HTs, though.
<geist>
yeah must be context switch leaking
<Bitweasil>
And there's a chicken bit you can use to disable the stuff.
<geist>
right, we were looking at it at work yesterday. it's still undocumented precisely what it does, even in the non public PPR
aws has joined #osdev
goliath has quit [Quit: SIGSEGV]
<geist>
but that particular MSR (0xc0011029 iirc) has other chicken bits in it for other workarounds
<mjg>
for fuchsia you probably want to just enabled it for the time being
<geist>
yep
<mjg>
no point digging into the ordeal
<geist>
probably just all fam 17h. it seems to not be for fam 19h and above
<Bitweasil>
I enjoy the kernel drama over the name of it.
<heat>
where?
<geist>
i'll put in a change for it today
<heat>
i like drama
<Bitweasil>
"Can we rename it boring things?" "No. You didn't help in the slightest with the original work, when you knew what it was."
<bslsk05>
lore.kernel.org: Re: [PATCH] x86/CPU/AMD: Rename the spectral chicken - Peter Zijlstra
<Bitweasil>
That's the spicy response. I like it.
<geist>
the later change of course is post some particular microcode version you dont need to set the bit
<Bitweasil>
I just updated a box with a BIOS and microcode, and it's still leaking.
<Bitweasil>
Per the POC.
<heat>
i think the current microcode is already fixed?
<heat>
at least the one in linux-firmware
<geist>
i thought it wa sonly fixed on a particular EPYC
<Bitweasil>
I had to set the chicken bit to get it to stop showing things, though I'm not sure the leakage was actually *leakage* or if it was just flag values.
<geist>
saw some table just a whiel ago on some article
<Bitweasil>
A lot of SCSCSCSCSCSC stuff.
<mjg>
ye
<Bitweasil>
And " 0 0 0 0 0..."
<mjg>
i think they are not giong to fix it on zens until the end of the year
<geist>
the rest of the microcode fixes for ab unch of the desktop stuff are coming more like dec 2023
<mjg>
ye that
<geist>
yeah. they fast pushed it for EPYC romes i think
<heat>
why?
<geist>
becuase those really matter
<heat>
this is like, erm, super serious
SGautam has joined #osdev
<Bitweasil>
Oh, I didn't realize the fix wasn't for desktop chips.
<geist>
but also may be something like they have more microcode
<geist>
i remember some folks at work bitching that the main problem with earlier zens is they dont have enough microcode space, so they quickly ran out of space
<Bitweasil>
"Pouring out any memory copied to anyone who looks" is a problem.
<Bitweasil>
Huh.
<Bitweasil>
So, what if we just turn all the computers back into the sand they came from...
<heat>
geist, new zen gens are getting way larger microcode
<geist>
right, i dont remember if that started with zen 3 or whatnot
<heat>
they recently increased the microcode updating code in linux to have a 2-3x larger buffer
<geist>
also still curious why zen 3+ doesn't seem to be affected. did this particular piece get reimplemented differently?
<geist>
presumably they didn't fix it in the design explicitly, or they would hve already knowna botu it
<geist>
though i assume someone is furiously trying to reproduce this on other zens and intel hardware
<geist>
wouldn't be surprised if we dont see it show up elsewhere soon
<mjg>
personally i'm waiting for a slew of new vulns here
<heat>
i'd say google already tried?
<geist>
it's one of these in retrospect this is probably an easy bug to make
<mjg>
after cheap attempts someone is gonna fuzz
<heat>
it's not like they only fuzz ryzen chips
<mjg>
instead of mining bitcoin
<geist>
yeah these sort of things tend to trigger a new wave of folks
<Bitweasil>
Indeed.
<Bitweasil>
You crack open the new box of goodies.
<Bitweasil>
And it takes a while to rummage around and see what's in there.
<geist>
good ol proper risc: you want to zero the register? zero them yourself dumbass
<Bitweasil>
And this one is architecturally visible misbehavior.
<bslsk05>
marc.info: '[PATCH] Revert "page cache: fix page_cache_next/prev_miss off by one"' - MARC
<geist>
reminds me i need to start adding vector context switch to zircon
<geist>
kinda a chicken and egg, not much is using it in user space yet, since no real hardware exists with vector 1.0
<geist>
i think linux only really recently got it
<geist>
(on risc-v that is)
<heat>
according to #riscv it's not really a solved problem yet
<geist>
oh the linux csw?
<geist>
shit i can beat em to the punch!
<heat>
csw?
<geist>
context switch
<heat>
oh yeah they have support for it, but detection from userspace sucks
<geist>
yeah gotta do the whole instruction trapping thing
<geist>
if you want it lazy
<heat>
you can't go by the misa string, because that doesn't mean the kernel supports it
<geist>
oh that, yeah.
<Bitweasil>
Man. I wouldn't write a lazy context switcher without the plumbing to make it a real scrub of data on short notice.
<geist>
well, we haven't really solved that in zircon either, passing the misa string through
<heat>
and then you can't go by their new feature thing, because apparently it's opt-in/out with a prctl
<Bitweasil>
Everything seems to leak enough that a lazy switch is risky.
<geist>
for riscv even with a hyper superscalar design there's just not that much state to leak, so its probably safer for a while
<heat>
RIIIIIIIISCVVVVVVVVVVVVVVVVVVVVV
<geist>
you can get the ARM64 style 'read a supervisor MSR and get data from it'
<heat>
RUST RISCV RUST RISCV RUST RISCV
<geist>
and of course any of the classic meltdown style page table leaks i guess
FreeFull has joined #osdev
DoubleJ has joined #osdev
DoubleJ has quit [Client Quit]
DoubleJ has joined #osdev
slidercrank has quit [Quit: Why not ask me about Sevastopol's safety protocols?]
DoubleJ has quit [Client Quit]
DoubleJ has joined #osdev
DoubleJ has quit [Client Quit]
DoubleJ has joined #osdev
<geist>
you know i do wonder why no one has decided it's a good idea to add a unused-page-zeroer to linux/etc again now that it spends a lot of times running in a VM
<geist>
i guess maybe the idea is if you want to return pages to the VM the VM implements a balloon thing
<geist>
and it's more explicit
<heat>
what's an unused-page-zeroer?
<heat>
like the idle loop thing?
<geist>
zero out pages that are free
<geist>
so that the VMM can reclaim the pages as being zeroed
<heat>
yeah right i still think there are no wins there though? no idea if the measurements were done under a VM though
<geist>
used to be a thing that OSes generally did, but over time it became more efficient to zero-on-demand
<geist>
and of course most modern systems dont tend to have a lot of free memory at any one time
<heat>
triggering KSM is hella-expensive so I assume it won't be done that much
<heat>
actually, i dont know if linux replaces pages with the zero page outside of KSM
<gog>
nyaa mrrp meow prr
<gog>
ω̈
<heat>
gog
<heat>
gog
<heat>
gog
<gog>
hi
<heat>
hi
<gog>
imagine using memory
<heat>
i do nto use mem
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
bgs has quit [Remote host closed the connection]
<Ermine>
gog: may I pet you
awita has joined #osdev
<gog>
Ermine: yes
<gog>
using memory is cringe
* Ermine
pets gog
* gog
prr
Brnocrist has quit [Ping timeout: 245 seconds]
<geist>
yah i use KSM on my VM box
<geist>
actually works fairly well
CaCode has joined #osdev
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<heat>
"The new GPRs are XSAVE-enabled, which means that they can be automatically saved and restored by XSAVE/XRSTOR sequences during context switches. They do not change the size and layout of the XSAVE area as they take up the space left behind by the deprecated Intel® MPX registers."
<nortti>
I do love the idea of a new prefix for specifying a third operand
FreeFull has joined #osdev
andydude has quit [Quit: Leaving.]
<heat>
Intel® APX demonstrates the advantage of the variable-length instruction encodings of x86 – new features enhancing the entire instruction set can be defined with only incremental changes to the instruction-decode hardware. This flexibility has allowed Intel® architecture to adapt and flourish over four decades of rapid advances in computing – and it enables the innovations that will keep it thriving into the future.
<heat>
aka SUCK IT RISCV AND ARM
gareppa has quit [Quit: WeeChat 3.8]
meisaka has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
meisaka has joined #osdev
<moon-child>
those are already variable length though
<moon-child>
FUUUUUUUUUSION
<moon-child>
MOVPRFX
<moon-child>
anyway, this is basically x86 adding risc
<bslsk05>
forum.osdev.org: OSDev.org • View topic - Dawn
<moon-child>
you don't understand heat it's SIMPLE
<kazinsal>
the subleq people have some kind of disease
<moon-child>
you just don't appreciate SIMPLICITY
<kazinsal>
clearly. I own a vax
<nortti>
I do personally appreciate subleq the same way I appreciate brainfuck or underload (my favourite esolang ever probably), but I'd never try to build anything more involved on top of it
<heat>
The internet, global forum of the free speech - actually controlled by the ISP-s and governments. A wifi device is driven by 5 million of source code lines, and nobody actually fully understants, how they work, a TCP stack is 500.000 lines of code. There are no experts at this area any more - even professionals are just typing random things in
<heat>
consoles to get it working if something is broken, hoping that it will randomly cure itself, becouse they cant debug 30 and 40 million code lines that is responsible for sending a bit on the cable.
<heat>
amen brotha 💯💯
andydude has joined #osdev
<heat>
"since dawn runs in an emulator at the moment, and subleq have no multiplier units to render the gui more quicker, antialiasing at the moment canot be enabled."
<heat>
bhahaha haha this thread was peak osdev forums
<sham1>
Good grief, wsl just doesn't want to do its stuff
<sham1>
Mildly annoying
SGautam has quit [Quit: Connection closed for inactivity]
awita has quit [Remote host closed the connection]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
sebonirc has quit [Remote host closed the connection]
Brnocrist has joined #osdev
sebonirc has joined #osdev
andydude has quit [Quit: Leaving.]
danilogondolfo has quit [Remote host closed the connection]
xenos1984 has quit [Ping timeout: 258 seconds]
foudfou has quit [Ping timeout: 240 seconds]
xenos1984 has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]