<bslsk05>
'Buying a PC With Dell: My Journey Into Hell' by Super Eyepatch Wolf (00:35:03)
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
SpikeHeron has quit [Quit: WeeChat 3.5]
<gog`>
imagine spending $2000 on a laptop
<gog`>
i only spent half that
<gog`>
shoulda got lenovo breh
SpikeHeron has joined #osdev
<geist>
yah get a mac if you're gonna spend that much
<heat>
this is a work laptop
<heat>
I didn't actually get to choose
<geist>
ah yeah the last dell laptop i had was a work laptop. was a piece of crap
<clever>
a lot of my dads work laptops where dells as well, and i got handed the used ones
<clever>
i think 2 died in his hands, and ive had the rest physically falling apart
<geist>
keyboard was garbage, trackpad was garbage. was vaguely useable with externa keyboard and mouse
<geist>
in which case it was just a portable intel machine
<clever>
one of them, i used so much, i physically wore a hole in the track pad
<clever>
the rest all had hinge problems
<heat>
I got a broken key, the CPU throttles constantly in linux unless you get thermald and a really new kernel, the thermal ACPI code wasn't included for some fucking reason (so it can't turboboost under load), S3 wasn't included because who needs suspend
<heat>
there are literally references to thermal objects that don't exist
<heat>
I'm pissed and this wasn't even my money
<heat>
it's like they try to be incompetent
JiTtLe is now known as JTL
scoobydoob has joined #osdev
<clever>
heat: if you want some real incompetence, my dads work sent him the new work laptop, after he was fired!
<clever>
they claimed the order was canceled, and the laptop still arrived
<geist>
they were trying to get rid of it
<heat>
hey that's great
<clever>
geist: its brand new
<heat>
if it was a dell, they were definitely trying to get rid of it
<kazinsal>
my current work laptop is a dell and it is definitely not great
<kazinsal>
keyboard is *horrendous*
<clever>
the previous one was HP
<clever>
not sure about the new one
<heat>
kazinsal, same here
<heat>
the shell also gets really fucking hot
<heat>
the constant 400MHz throttle was there to protect me I guess :v
scoobydoo has quit [Ping timeout: 260 seconds]
scoobydoob is now known as scoobydoo
wand has quit [Remote host closed the connection]
<clever>
heat: one dell laptop i had, would thermal throttle only if the lid was closed, but cleaning dust out of the heatsink fixed it
<clever>
another older dell, never thermal throttled, but one day the cpu fan jammed, and it went into thermal shutdown
<clever>
but i just gave the fan a nudge, and it was as good as new
<clever>
that thermal shutdown was also weird
<clever>
it seemed to go into a major thermal throttle at first
<clever>
the system got very laggy, yet cpu/ram usage graphs said it was fine
<bslsk05>
'Mentorship Session: Writing Linux Kernel Modules in Rust' by The Linux Foundation (01:30:37)
<doug16k>
clever, it won't always show up as the clock reducing on intel. I have seen my brother's machines sit at 100C in prime95. stayed 5GHz flat as a ruler
<heat>
from what I read, they disabled S3 because windows sometimes BSOD'd when resuming
<heat>
it's the definition of 🚢 it
<doug16k>
MSI "gameboost" = try to blow up CPU
<doug16k>
presumably injecting nops or something to keep it exactly at 100
<heat>
of course msi would call that gameboost
<clever>
doug16k: yeah, when the rpi thermal throttles, it just ignores the freq the arm asks for, and uses something lower
<heat>
it's like a gaming motherboard
<clever>
and you have to go thru some special hoops to see the real freq
<clever>
doug16k: though the dell that had thermal shutdown, it turned off within something like 5 seconds, i barely had time to investigate what was happening
matt__ has joined #osdev
matt__ is now known as freakazoid333
<doug16k>
best auto-OC I have seen yet though. could accidentally put your machine on 5GHz allcore and it would pass prime
<doug16k>
not sure whether you would get VRM scent after a while
<doug16k>
good luck killing MSI VRM though. they are ridiculous
<clever>
doug16k: something i still dont fully understand, is how the pmic and firmware co-operate during clock changes, i would assume its just raising the voltage before the freq, but then you have things like DVS
<doug16k>
all you need is to stop clock when the droop is past a threshold
<doug16k>
so it might skip some clocks if it needs a lot more current suddenly
<clever>
makes sense, but i'm not sure it has hardware that can do it
heat has quit [Ping timeout: 272 seconds]
<clever>
the bcm2711C0T revision, also has a different thing to massively help with thermals
<clever>
if all of the inputs to a hw block are idle, the clock to that block stops
frkzoid has joined #osdev
freakazoid333 has quit [Ping timeout: 244 seconds]
<doug16k>
typical VRM is 100kHz, so it gets to use a new pulsewidth every (1/(100kHz*phasecount)) sec, so if 6 phase, then every 1.6us
<doug16k>
1.6us is an eternity
nick64 has quit [Quit: Connection closed for inactivity]
<doug16k>
you are supposed to have enough capacitance to cover the transients
zaquest has quit [Remote host closed the connection]
<doug16k>
there's a fixed dI/dt (rising slope of current) determined by the supply voltage and inductance, so you only get to increase current a fixed amount per cycle
xhe has quit [Ping timeout: 255 seconds]
zaquest has joined #osdev
xhe has joined #osdev
noeontheend has joined #osdev
<doug16k>
if you go with huge inductors then you can use low switching frequency, and low losses, and the current is hard to move up and down. if you go with tiny inductors, you have to use high switching frequency and take higher losses, and the current can be moved up and down quickly
gog` has quit [Ping timeout: 276 seconds]
tsraoien has quit [Ping timeout: 255 seconds]
<doug16k>
so you figure out a ramp up time you can tolerate, and allowing more time allows cheaper vrm and less losses
_xor has quit [Read error: Connection reset by peer]
<doug16k>
super efficient one is expensive because the larger inductor's price is much more
<doug16k>
need super low ESR caps too for super efficient one
Gooberpatrol66 has quit [Quit: Leaving]
<doug16k>
if you cheap out hard on the inductor you can get amazing caps that will actually hold those tiny pulses, if you get giant inductor, garbage caps are fine
<clever>
makes sense
gog has joined #osdev
<mrvn>
gold caps, all the way *duck*
<doug16k>
if you take an existing MB and turn up the switching frequency, it increases losses directly, but makes it have faster reaction time against droop
qubasa has quit [Ping timeout: 276 seconds]
<doug16k>
100KHz would be a default, then you could select maybe 150 then 200
<mrvn>
I select 131072Hz
<doug16k>
it also reduces the resolution of the PWM
Gooberpatrol66 has joined #osdev
noeontheend has quit [Ping timeout: 244 seconds]
<doug16k>
mrvn, yours has a nice round number like that?
<doug16k>
it could be any number though, sure
<mrvn>
sadly no. stupid hardware store sells me crystals with 1MHz or 16MHz.
<mrvn>
stupid decimal people.
<doug16k>
the 32.768kHz crystal people are alright
<mrvn>
I should order me some of those. My toy CPU runs with a 16MHz crystal (needed for the UART) driving a counter ladder to get a nice slow clock.
<doug16k>
the stability of them is pretty impressive. something like -200ppm to 0 from -50C to +100C
<doug16k>
25C is middle, where it is typically +/- 0
<bslsk05>
github.com: bootstrap/Makefile at master · zid/bootstrap · GitHub
<dzwdz>
wow, that's small
<zid`>
I mean, what else does it really need to do?
<dzwdz>
mine also builds the init binary, the initrd, and runs tests
<zid`>
tis a skeleblob too don't forget
<zid`>
Mine just builds boot.bin, kernel.bin, and uses those two files + stage2_eltorito to make a bootable grub cd-rom
<zid`>
boot.bin is a 32bit ELF that's a 64bit elf loader
gog` has joined #osdev
<zid`>
hegoog
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<gog`>
moew
<gog`>
i had big plans today
<gog`>
chose slep instead
<zid`>
That's a reasonable big plan
<gog`>
agreed
eroux has joined #osdev
<heat>
using gcc instead of ld to link is good practice
<heat>
you're the weird one using ld
<zid`>
gcc is good if you're using system defaults
<zid`>
ld is better if you're building weird things like kernel images
<gog`>
who does that anyway
<zid`>
good point
pretty_dumm_guy has joined #osdev
frkzoid has quit [Ping timeout: 272 seconds]
gog` has quit [Ping timeout: 260 seconds]
<heat>
using gcc is always useful
<heat>
for instance, some options you'd pass gcc aren't really linker options, the gcc spec has a bunch of defaults you may want to use, LTO is a PITA to set up without gcc
<zid`>
hmm?
<zid`>
To me that's like saying "C compilation is hard without gcc"
<zid`>
as long as you build with -flto and then link with it too it justworks because that's how gcc does it, plugin lto is a pain though yea
<zid`>
-fwhole-program *is* nice though
gog has quit [Ping timeout: 276 seconds]
xhe has quit [Ping timeout: 272 seconds]
<zid`>
but I don't think ld cares about that? I think that just goes around making things static internally
smpl has joined #osdev
xhe has joined #osdev
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 244 seconds]
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 268 seconds]
<bslsk05>
github.com: bootstrap/long.asm at master · zid/bootstrap · GitHub
<dzwdz>
but now if i have to set up the gdt before i can load C code (unless i bothered to separately compile the GDT stuff... with a separate 32 bit compiler i guess), why bother setting it up again later?
bauen1 has joined #osdev
<zid`>
You need one per cpu, for starters?
gildasio has quit [Remote host closed the connection]
<dzwdz>
hm
<dzwdz>
i didn't set up smp yet so i didn't know that
<zid`>
unless you wanna re-use the same exception stack
<zid`>
for every cpu
<zid`>
sounds like a bad plan to me
gildasio has joined #osdev
<zid`>
64bit only really uses tss to load a ring0 stack from for interrupts
gxt has quit [Remote host closed the connection]
gog` has joined #osdev
gog` is now known as gog
gxt has joined #osdev
<dzwdz>
does long mode remain activated after i disable paging?
<dzwdz>
the docs say that the cpu behaves as 32-bit until i enable paging, but they don't seem to mention disabling it again
<gog>
long mode requires paging
<gog>
and it's generally a bad idea to try to exit long mode once it's started
<gog>
if you try to disable paging while EFER.LME is active you'll get a #GP
<zid`>
There's a nice flowchart in the manual
<zid`>
a lot of the arrows are #GP
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
<dzwdz>
and i'm not supposed to map the kernel in userland because of meltdown, right? so i'd need to reload cr3 on every syscall?
<zid`>
found it, figure 4.1
<zid`>
~page 108 depending on manual version
<dzwdz>
which manual, intel or amd?
<zid`>
intel
<zid`>
clear pae is #gp, clear LME is #gp, clear PG does actually work
<gog>
oh it does?
<gog>
interesting
<zid`>
It puts you into a dotted box so I think nothing actually changes
<zid`>
but you can then disable LME and/or PAE
<zid`>
to get into a real cpu mode
<gog>
well, in any case, no you don't reload cr3 on system calls, you use the user/supervisor bit in the page table to protect kernel pages
<zid`>
meltdown he said, gog
<zid`>
and for meltdown, yea you do, or use PCI or whatever it's called, I think that's safe
<dzwdz>
zid`: which chapter is that in? page 108 is the manual i have open is about floating point exceptions
<zid`>
volume 3, the one about osdev
<zid`>
figure 4-1
<gog>
you _can_ use page table isolation and only map the system call code which in turn will load kernel page tables
<zid`>
approximately 108 pages into it
<dzwdz>
so in i686 i was doing something kinda similar
<dzwdz>
where instead of reloading cr3 i was just disabling paging
<dzwdz>
i assumed that'd be faster
<zid`>
I'd be surprised if enabling paging again didn't flush the TLB
<zid`>
but who knows
<dzwdz>
i haven't benchmarked it
<dzwdz>
it was easier than setting up proper paging anyways
<gog>
oh also the IDT and ISRs
<gog>
gotta have those
<gog>
and the GDT probably
<dzwdz>
yup, i needed to map the GDT too iirc
<zid`>
yea almost everything is a linear addresss
<zid`>
the only physical address anything cares about is cr3 really
<zid`>
(swap the object and subject in that sentence pls)
<dzwdz>
so that flowchart tells me that i can disable paging in long mode and it won't crash
<dzwdz>
actually nvm
<zid`>
Although, there's a note above
<zid`>
that says doing it will #GP if you're in long mode at the time
<zid`>
so I'm not sure who to believe anymore!
<zid`>
says you need to go into compat mode before it works
<gog>
so LMA has to be 0
<zid`>
no, L bit
<gog>
o
<gog>
oh yehj
<zid`>
unsetting LM is a gp for sure
<zid`>
and the way to unset L is to.. jump to a selector without L set, which makes sense
xhe has quit [Read error: Connection reset by peer]
<gog>
yes
<zid`>
which is basically WHY all this shit #GPs anyway
xhe has joined #osdev
<zid`>
suddenly the state makes no fucking sense
<gog>
the most general of faults
<gog>
why does it happen? many reasons
<zid`>
it's just more succinct than "shit's fucked yo"
<dzwdz>
i still don't really see why disabling paging the normal way would GP
<gog>
my architecture will have a #SF exception
<gog>
"shit's fucked"
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
<dzwdz>
the 64bit gcc toolchain won't output 32bit code, right? so if i wanted to write the code that'd set up paging for long mode in C, i'd need two toolchains?
X-Scale` has joined #osdev
jafarlihi has joined #osdev
<zid`>
-m32
X-Scale has quit [Ping timeout: 272 seconds]
<zid`>
it's even in the makefile I linked
X-Scale` is now known as X-Scale
<jafarlihi>
Is `pfifo_fast_dequeue` good place to hook if I want to check sent packets against Wireshark to be sure nothing is hidden?
<dzwdz>
oooooh
<zid`>
and for binutils it varies by tool, hoorah
<gog>
binutils is a mess
<dzwdz>
so is gcc
<zid`>
but for ld it's -m elf_i386
<zid`>
binutils is a MESS
<zid`>
It's mainly that some options are shared, but some are implemented by the specific emulation
<dzwdz>
is -m32 the only way, or can i set some attribute on a function to mark it to be compiled to 32bit code?
<zid`>
-m32
<zid`>
it's per TU only
hbag has joined #osdev
<gog>
hbag:
<gog>
sup
<hbag>
just rejoining since i realized i havent rejoined since my connection last died
<gog>
:D
nyah has joined #osdev
jafarlihi has quit [Quit: WeeChat 3.5]
<doug16k>
dzwdz, x86_64 will generate i386 code, and the codegen is more how x86_64 cpus like it, too
<doug16k>
it likes using whole registers more, for example
[itchyjunk] has joined #osdev
gog has quit [Ping timeout: 240 seconds]
<doug16k>
a real 32 bit cpu will have no trouble with it though. more like the generated doesn't make x86_64 merge partial registers so much
blockhead has quit []
nvmd has joined #osdev
ripmalware has quit [Quit: Leaving]
matt__ has joined #osdev
matt__ is now known as freakazoid333
nvmd has quit [Quit: WeeChat 3.6]
nvmd has joined #osdev
TorusField has joined #osdev
k0valski1889 has joined #osdev
<klys>
anyone around toying with gcc 12 ?
<zid`>
toying how?
<zid`>
using it as a compiler? for ages
gildasio has quit [Remote host closed the connection]
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
<klys>
looks like 12.1 was released on 06may2022.
gildasio has joined #osdev
freakazoid333 has quit [Ping timeout: 240 seconds]
gog has joined #osdev
Bonstra has quit [Ping timeout: 240 seconds]
gog has quit [Ping timeout: 240 seconds]
nyah has quit [Quit: leaving]
nyah has joined #osdev
Bonstra has joined #osdev
meisaka has quit [Ping timeout: 255 seconds]
meisaka has joined #osdev
ebrasca has joined #osdev
<ebrasca>
What is the BAR for 82540EM ?
<zid`>
question makes no sense
<zid`>
devices have BARs
zaquest has quit [Ping timeout: 240 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
<bslsk05>
www.ebay.com: AMD EPYC Milan 7453 28-Core 2.75GHz SP3 225W Server Processor CPU 100-000000319 | eBay
<mjg_>
heh, you reminded me to check on laptop prices
<mjg_>
i had my eyes on a zen laptop, but given retbleed maybe i'll try something less fucked by it
<sbalmos>
an Etch-A-Sketch?
xhe has joined #osdev
noeontheend has joined #osdev
<geist>
klys: ah yeah it was you that was dumping an insane amount of money into some home server thing?
<geist>
Like 100gbit network, etc?
<geist>
mjg_: meh. I wouldn’t worry about whatever the latest nonsense is. Also zen 3 doesn’t seem to be effected by it
<geist>
But if it’s not retbleed it’ll just be the other one. You can’t win except to run really legacy stuff
<geist>
At the end of the day you gain/lose some percentage of points on some benchmark. But it’s still a laptop. It doesn’t suddenly become trash if it gets n% slower in some syscall
<geist>
This is one of those cases where you’re just better off if you dont know how the sausage is made. Lots of times kernel folks like us i think put too much value in these little details, whereas in the grand scheme of things if it shows cat pictures it does its job
<mjg_>
i thought the migitation disables some of speculative execution altogether
<mjg_>
not just kernel-side
<mjg_>
general point being my good ol' haswell laptop kind of works, but it is slow
<mjg_>
would be quite a bummer to buy a new one only to find it shitting the bed on single-threaded stuff
<mjg_>
with perspective of it getting even slower down the road
<klys>
geist, I'm slow at making money too, I still haven't bought the ram yet. just the motherboard and cpu.
<geist>
That seems like a really bad idea
<geist>
Always buy computer hardware when you need it
<geist>
Since the price will usually go down over time
<klys>
the better zen 3 7003 options are still above 2k which cuts me out
<klys>
that ebay listing is probably just a fluke
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
vinleod has joined #osdev
<mrvn>
It would be nice if application doing sensitive stuff could enable those mitigations as needed.
vinleod is now known as vdamewood
<mrvn>
"I'm going to do some online payment, disable all speculatiuve execution now"
<moon-child>
have an isolated core
<moon-child>
numactl -Ck firefox, where k is the in-order core that doesn't get to run anything you don't specifically ask to run on it
<moon-child>
(sans the 'in-order' part, you can do this today)
<mrvn>
you also need the cores that share caches
<moon-child>
(which is significant given that runtime toggling of mitigations may be impractical for kernels)
chartreuse has joined #osdev
<moon-child>
mrvn: sure, yes
<mrvn>
And when you aren't online shopping you can let other stuff run on the cores too.
<moon-child>
well, hmm. The point is to observe branch timing. But l2/l3 hit should be slower than a branch mispredict. Do these vulnerabilities only apply to stuff in l1? Haven't looked too closely
<moon-child>
easy solution is just get an old laptop or crappy pc and use that :P
<mrvn>
I should look into making a cgroup for firefox and hack something together to limit the cgroup to 0.1% cpu time whenever the window is minimized.
<moon-child>
(easy--and much more robust)
noeontheend has quit [Ping timeout: 255 seconds]
heat has joined #osdev
Matt|home has quit [Quit: Leaving]
noeontheend has joined #osdev
wootehfoot has joined #osdev
Matt|home has joined #osdev
dude12312414 has joined #osdev
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
noeontheend has quit [Ping timeout: 240 seconds]
<mrvn>
Do any of the performance counters update when doing speculative execution that then isn't taken?
nyah has quit [Ping timeout: 268 seconds]
wootehfoot has quit [Ping timeout: 240 seconds]
wootehfoot has joined #osdev
<immibis>
mrvn: Interesting question, my gut says yes. Because that DOES affect performance!
<immibis>
hmm
<immibis>
the obvious follow-up is: can any of them be used to leak memory contents?
<zid`>
moon-child: can there *be* anything interesting in l1?
<mrvn>
immibis: I don't mean the branch itself. That obviously increments the branch miss counter. I mean the rest of the instructions that need to be undone.
<zid`>
it's non-shared and there isn't really space for anything interesting to be there that isn't the exploit code itself :P
<zid`>
or the remnants of the context switch
<immibis>
I think the performance counters would be kinda useless if they didn't. Depends on the specific counter, obviously.
<mrvn>
zid`: the bit of memory the exploit code tries to read
<immibis>
The one for instructions issued SHOULD be incremented when the processor speculatively issues an instruction.
<immibis>
The one for instructions retired SHOULDN'T be incremented because incorrectly speculated instructions do not retire.
<immibis>
and so on.
<mrvn>
immibis: then that instantly leaks information
<immibis>
geist: We live in an environment where there is a non-negligible chance of money being worthless next week
<immibis>
although if that happens, probably computer parts will also be relatively worthless so you may still be able to buy some
<mrvn>
immibis: because that has happened so many times recently?
<zid`>
My plan is to trade sex for them
<mrvn>
I would rather say the problem is you don't have money, you have bits.
<zid`>
wait nvm that's also my current plan
<mrvn>
zid`: Give me all your food or I will fuck you?
<zid`>
moon-child: hi
<mats1>
yes daddy
<zid`>
you can't call me daddy without subscribing to my onlyfan
<mrvn>
Didn't know you could inline initialize member variables with values of previous members that aren't even inline initialized.
<immibis>
makes sense but also wtf
<immibis>
remind me to use that at work
<mrvn>
If you think about how initialization works with constructors it makes sense. It's just `graph(std::size_t v) : V(v), row(std::vector(V)), matrix(V, row) { }
the_lanetly_052_ has joined #osdev
<mrvn>
If you don't initialize V you get a warning but no error.
the_lanetly_052 has quit [Ping timeout: 268 seconds]
mimmy has quit [Ping timeout: 244 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
mimmy has joined #osdev
psykose has quit [Remote host closed the connection]