gbowne1 has quit [Remote host closed the connection]
gbowne1 has joined #osdev
innegatives has joined #osdev
vdamewood has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 240 seconds]
Turn_Left has joined #osdev
Turn_Left has quit [Read error: Connection reset by peer]
Left_Turn has quit [Ping timeout: 272 seconds]
sbalmos has quit [Quit: WeeChat 3.0]
[itchyjunk] has quit [Ping timeout: 248 seconds]
torresjrjr has quit [Ping timeout: 258 seconds]
[itchyjunk] has joined #osdev
torresjrjr has joined #osdev
elastic_dog has quit [Ping timeout: 260 seconds]
Mondenkind has quit [Quit: !]
elastic_dog has joined #osdev
moon-child has joined #osdev
Bonstra has quit [Quit: Pouf c'est tout !]
alice has quit [Ping timeout: 240 seconds]
andreas303 has quit [Ping timeout: 272 seconds]
andreas303 has joined #osdev
Bonstra has joined #osdev
alice has joined #osdev
[itchyjunk] has quit [Read error: Connection reset by peer]
elastic_dog has quit [Ping timeout: 272 seconds]
<kof213>
> You don't know how to write a program until you've already written it > this is all pretty iterative > reading theory on $subject is just a way to shortcut a bunch
<kof213>
this is all conway's law :D but i would distinguish "well-tested theory more directly based on iterating" versus "unknown theory, that should work, but not necessarily fully tested yet"
<kof213>
or: there are theories and Theories
elastic_dog has joined #osdev
gbowne1 has quit [Remote host closed the connection]
gbowne1 has joined #osdev
<kof213>
this is just to say, conway's law still in effect, as always, when you decide which "theories" you trust or not
greaser|q has joined #osdev
<kof213>
i mean, same argument: you don't know which theory to trust until you've already written it
<kof213>
i don't see a guaranteed shortcut there, the hopium is there though :D
<kof213>
> i feel like all of these posts were written in the far past where everyone was slightly-very nuts well, they always leave out "whatever ye bind" aka conway's law lol
Arthuria has joined #osdev
freakazoid332 has joined #osdev
admiral_frost has quit [Quit: It's time]
Arthuria has quit [Remote host closed the connection]
Osmten has joined #osdev
Burgundy has joined #osdev
Gooberpatrol_66 has quit [Ping timeout: 260 seconds]
Gooberpatrol66 has joined #osdev
Burgundy has quit [Ping timeout: 255 seconds]
doppler has quit [Ping timeout: 260 seconds]
bl4ckb0ne has quit [Remote host closed the connection]
bl4ckb0ne has joined #osdev
doppler has joined #osdev
Vercas has quit [Remote host closed the connection]
gildasio has quit [Remote host closed the connection]
gxt_ has quit [Remote host closed the connection]
gxt_ has joined #osdev
Vercas has joined #osdev
gildasio has joined #osdev
antranigv has quit [Ping timeout: 255 seconds]
antranigv has joined #osdev
[itchyjunk] has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
dza has quit [Remote host closed the connection]
gbowne1 has quit [Quit: Leaving]
dza has joined #osdev
netbsduser has joined #osdev
GeDaMo has joined #osdev
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
gog has joined #osdev
zxrom has quit [Quit: Leaving]
nyah has joined #osdev
Osmten has quit [Quit: Client closed]
goliath has joined #osdev
Osmten has joined #osdev
danilogondolfo has joined #osdev
admiral_frost has joined #osdev
Yoofie0 has joined #osdev
Yoofie has quit [Ping timeout: 255 seconds]
Yoofie0 is now known as Yoofie
Osmten46 has joined #osdev
Osmten has quit [Ping timeout: 245 seconds]
muffin has joined #osdev
muffin has quit [Quit: WeeChat 4.0.5]
Burgundy has joined #osdev
muffin has joined #osdev
sbalmos has joined #osdev
admiral_frost has quit [Quit: It's time]
Osmten46 has quit [Quit: Client closed]
zxrom has joined #osdev
heat has joined #osdev
Arthuria has joined #osdev
dzwdz has quit [Ping timeout: 248 seconds]
dzwdz has joined #osdev
Arthuria has quit [Ping timeout: 260 seconds]
admiral_frost has joined #osdev
stolen has joined #osdev
heat has quit [Remote host closed the connection]
heat has joined #osdev
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
<bslsk05>
www.theregister.com: VA hospital's IT snafu blamed on cat's keyboard surfing • The Register
Burgundy has quit [Ping timeout: 240 seconds]
<mcrod>
i
<mcrod>
hate
<mcrod>
shell
<mcrod>
scripting!
<zid>
hrmph, my good knife broke
<zid>
It wasn't being hand washed cus honestly it was a cheap shit knife, so it got a bit of water between the tang and the handle and apparently rusted through then snapped
<zid>
but I now don't have a knife worth using
eddof13 has joined #osdev
Left_Turn has joined #osdev
sbalmos has quit [Ping timeout: 272 seconds]
heat has quit [Remote host closed the connection]
heat has joined #osdev
<gog>
oof
<heat>
oof
<mcrod>
oof
<Ermine>
hi oofs
Burgundy has joined #osdev
<gog>
hi Ermine may i pet you
<Ermine>
Sorry, no
<mcrod>
gog you may pet me instead
* gog
pet mcrod
* mcrod
prr
<heat>
Ermine, im proud of you
<heat>
resist the petting
<gog>
heat may i pet you
<heat>
yes
* gog
pet heat
* heat
bark
<heat>
hooman bark
<gog>
good boy
Turn_Left has joined #osdev
<Ermine>
heat: :)
Left_Turn has quit [Ping timeout: 246 seconds]
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eddof13 has joined #osdev
admiral_frost has quit [Quit: It's time]
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sbalmos has joined #osdev
eddof13 has joined #osdev
xenos1984 has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
muffin has left #osdev [WeeChat 4.0.5]
FreeFull has joined #osdev
gog has quit [Quit: Konversation terminated!]
xenos1984 has quit [Ping timeout: 258 seconds]
netbsduser has quit [Remote host closed the connection]
netbsduser has joined #osdev
gog has joined #osdev
xenos1984 has joined #osdev
stolen has quit [Quit: Connection closed for inactivity]
gog has quit [Quit: byee]
gog has joined #osdev
<targetdisk>
alright the next thing on my docket is to figure out how to ask ACPI whether or not the system is running off of battery or not (from within UEFI boot services)
<targetdisk>
yay :)
rorx has quit [Ping timeout: 240 seconds]
rustyy has quit [Quit: leaving]
zid has quit [Read error: Connection reset by peer]
<heat>
as far as I remember, no EFI protocol can query that
<heat>
and EFI has no ACPI interpreter protocol either
<heat>
so unless you want to bundle ACPICA with your bootloader, it's not really doable
<targetdisk>
looks like I can interrogate the ACPI tables while in boot services
<Bitweasil>
... why does it matter during boot, exactly?
<Bitweasil>
Throttles to go, get that boot done, and then let the booted OS handle CPU throttling.
<Bitweasil>
ACPI sucks. :(
<targetdisk>
I'm writing an EFI application that resembles Apple's old target disk mode
<heat>
yeah "interrogating the ACPI tables" is very non trivial
<heat>
like hundreds of lines of code non-trivial
<targetdisk>
I just need to see if the battery is present
<Bitweasil>
Ok. So why does battery/AC adapter state matter?
<heat>
sorry, hundreds of thousands*
<targetdisk>
if the battery is present, I need to ask what percent
<Bitweasil>
Seriously, ACPI looks simple and gets gnarly.
<Bitweasil>
Ok. What happens if you query and it's not present?
<targetdisk>
I won't display a battery indicator on my application ;)
<Bitweasil>
TBH, if "parsing ACPI sanely" is a prerequisite for a battery indicator, I'd just ship without the battery indicator.
<heat>
yeah
<Bitweasil>
It's *seriously* non-trivial to parse and understand, and if you take shortcuts, it *will* break in some future EFI update.
<heat>
OH
<heat>
EFI_BATTERY_CHARGING_PROTOCOL!
<heat>
i wonder if this is relatively available
<targetdisk>
I wonder when this was introduced
<heat>
it's not even standard
admiral_frost has joined #osdev
<heat>
just microsoft-specific it seems
<targetdisk>
I wonder if Intel Macs have it
<heat>
no
<targetdisk>
Maybe I can fallback to ACPI code if bundling/linking it isn't too high of an overhead
<heat>
that sounds very unlikely
leon has quit [Ping timeout: 255 seconds]
zid has joined #osdev
<targetdisk>
I think that checking for the protocol and falling back to ACPI would be nice. I'm curious what happens though on non-complete community implementations of UEFI on systems that didn't ship with UEFI from the factory
rustyy has joined #osdev
<targetdisk>
I'm pretty sure they ported a subset of UEFI for Asahi Linux to work on the M-series macs as well
<targetdisk>
curious how it behaves
<targetdisk>
I wonder if I can test it on my M1 Air without disabling macOS security features
<Bitweasil>
Do you need ACPI for *anything* other than battery status?
<targetdisk>
nope just battery
dude12312414 has joined #osdev
<Bitweasil>
Finish the rest of the project first, and then dive into the ACPI stuff if you must.
<heat>
i'd skip battery if i were you
<Bitweasil>
That's a huge pile of work for, IMO, a very minor feature.
<heat>
yeah
<heat>
and the protocol isn't even likely to be there
<Bitweasil>
I'm with heat. Skip it, suggest people be plugged in. If they don't, well, that's kind of on them.
<Bitweasil>
If you can detect easily that it's on battery, "WARNING: Battery use not recommended! Please plug your machine in!" or something. But if you have to embed an ACPI parser to get that information, thar be dragons.
<heat>
also executing AML and ending up triggering some sort of weird SMM bug because you didn't exit boot services yet would be VERY FUNNY
<heat>
and somehow realistic
<targetdisk>
ugh well the rest of the app involves making a proxy device with two device ports that enables a host system to access block storage devices on another system as if they were USB mass storage
<targetdisk>
the complexity of the ACPI or battery stuff is likely laughably minor when compared with the rest of what I need to do
<heat>
>the complexity of ACPI
<heat>
do not underestimate the complexity of ACPI
<Bitweasil>
Do the USB ports even *work* in that mode as a device?
<targetdisk>
I wanted to see if I can get an RP2040 to drive two USB high-speed PHYs with PIO
<Bitweasil>
Oh, you'll have an interposer device.
<targetdisk>
yes I need to make one
<Bitweasil>
So it's "host to host" through the interposer. Yeah, that should be fine.
<Bitweasil>
How much do you care about speed? I'd personally use one of the Arduino chips with a built in USB PHY.
<targetdisk>
I mean I know it'll work when I'm done, but it's going to be a lot to get there
<Bitweasil>
The... Pro Micro, I think, has USB? One of the smaller ones is based around a chip with USB.
<targetdisk>
Bitweasil: I would like to have it be 2.0 speeds
<Bitweasil>
And I know they work as device mode.
<Bitweasil>
Should be fine.
<targetdisk>
all the good micros with high-speed PHYs built in were out of stock last I checked
<targetdisk>
also the RP2040 and two external PHYs is probably a lot cheaper
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<targetdisk>
there's no way that USB PHYs or RP2040 chips are going out of stock any time soon
<Bitweasil>
It's got an Atmega 32U4, which is USB 2.0
<targetdisk>
No I want to sell the interposer device too
<targetdisk>
I want it to be cheap
<Bitweasil>
Hrm. Also, looks like that only supports the 12Mbit data rates.
<Bitweasil>
If you don't mind board design, can't argue with the 2040 idea.
<Bitweasil>
However, I'll also suggest that you have several projects worth fo work here, and should probably start with something "known working" for USB support while you work out the software, then get the hardware design done separately. Or start with the hardware and just run userspace sort of USB drivers to debug it, then get the endpoints working.
leon has joined #osdev
<targetdisk>
so far no one has tried getting the 2040 to do high-speed USB before. There are projects for the 2040 that enable USB PIO at "full-speed" already. I think if I improve that and drive the 2040 with a crystal at some multiple of the PHY's clock speed I should be able to make it work
<bslsk05>
sekigon-gonnoc/Pico-PIO-USB - USB host/device implementation using PIO of raspberry pi pico (RP2040). (101 forks/987 stargazers/MIT)
<targetdisk>
then I'll make something like it that works at higher speeds later on that apes their API
<targetdisk>
*then I'll make something like it
<targetdisk>
jeez
<Bitweasil>
Seems sane enough, just a big project. And I'm genuinely not kidding, I think ACPI is easily almost as much work as the rest of it.
<Bitweasil>
It's a nasty little spec.
<targetdisk>
I think that if people can drive HDMI with the RP2040 and still have room to draw graphics, I can probably make a USB 2.0 high-speed device work with the 2040
<targetdisk>
I found a high-speed 480Mb/s FPGA soft core on opencores
<targetdisk>
I think that if I cross-reference that with the spec and the other PIO implementation I should be able to figure it out
<Bitweasil>
USB is nasty. ACPI is nasty. EFI is... well, compared to those, actually not half bad, really. Pick one or two first. ;)
<heat>
efi is nasty
<heat>
there you go
rorx has joined #osdev
<targetdisk>
UEFI is easy once you setup your build environment tbh
<heat>
haha
<targetdisk>
It feels just like programming arduino but faster
<heat>
dunning-kruger effect baybeeee
<targetdisk>
I love gatekeeping thanks <3
<targetdisk>
I want to learn this even if it turns out being hard
<heat>
i'm not gatekeeping
<heat>
just telling you EFI is hard and tricky
<targetdisk>
oh well I haven't seen the scary bits yet
<heat>
even if it does not seem as such at first (oh, just calling functions through function pointer tables? that seems EZ)
<targetdisk>
hardest part was getting shit to compile when I was getting started so far
<ChavGPT>
"OOH GATEKEEPING" should be autoban for a week
<targetdisk>
chav I will sick the libera people on you stfu
<heat>
the best part about extensively using EFI is figuring out how the firmware people fucked it up in all the possible corner cases
<targetdisk>
oh that's gonna be fun
<heat>
millions of lines of code that have never been run with UBSAN or ASAN or MSAN or anything that can verify correctness
<targetdisk>
Oh I'm sure
<heat>
the PE loader has glaring security issues, it's brilliant
<targetdisk>
because only a select few people have access to the intel in circuit debugging tools
<heat>
you don't need that shit
<targetdisk>
sure
<targetdisk>
you're right
<heat>
it's not a lack of possibility, it's a lack of care
<targetdisk>
you can mock things and unit test them off-platform after all
<heat>
huge chunks of the code run with DRAM enabled
<heat>
those could all use some ASAN
<targetdisk>
ah I see what you mean. so like I can see the entire address space through my code maybe?
<heat>
wdym?
JerryXiao has joined #osdev
<targetdisk>
oh you're talking about compile-time/static analysis stuff
<targetdisk>
sorry I was confused
<heat>
no
<heat>
ASAN is runtime
<Bitweasil>
... yeah, you're in the EFI space, you're sort of the only thing running on the hardware. But you *could,* if you cared, run almost all those modules in a more normal mocked mode so you could run memory correctness tools on them - or in an emulator that has that support. They didn't.
<targetdisk>
oh right. but you put it in at compile-time
<targetdisk>
I forgot
<Bitweasil>
There are ways to have made the EFI code "less bad." They generally don't seem to have been done.
<targetdisk>
right I see what you mean
<heat>
you can definitely run ASAN on bare metal there
<heat>
it has been done before, there's a random intel branch somewhere with a PoC for OVMF
<targetdisk>
nice!
<Bitweasil>
Anyway, you've bit off a lot. My personal suggestion is to skip the ACPI parts until everything else is working, because it's "yet another gnarly, nasty part" on top of a few others that don't sound any easier. I fully believe what you're doing is doable, it's just not particularly easy.
<Bitweasil>
And I've, in the past, gone rather out of my way to avoid needing to put ACPI parsers in code.
<Bitweasil>
Fortunately, the board let me move the various south bridge peripherals into PCI mode, so I could just query the PCI bus and get the BARs out of that.
<Bitweasil>
Which was *far* easier than parsing ACPI.
<targetdisk>
but probably less universally compatible :(
<Bitweasil>
Didn't care.
<targetdisk>
but interesting idea
<Bitweasil>
I was writing for one particular board at the time.
<heat>
yeah ACPI at the end of the day either queries PCI directly or does a magic sequence into a magic CPU mode that... queries some hardware registers directly
<heat>
it's not rocket science, but ACPI is very convoluted
<targetdisk>
sure
<heat>
in this case i bet it just speaks SMBUS with the battery controller
<heat>
probably doesn't need SMM at all
<Ermine>
ASAN for OVMF ?
<Bitweasil>
Hopefully. I still occasionally have x86/SMM dreams... :(
<Bitweasil>
They're as unpleasant as that sounds.
<heat>
haha
<heat>
they're axing most of it though
<Ermine>
ah, proof-of-concept
<heat>
through the EFI PRM stuff
<Bitweasil>
You know you've been staring at disassembly too long when you start dreaming in x86 assembly. Usually takes me about a week of heads down work before I start in on those dreams...
<Ermine>
:(
<Bitweasil>
Oh? I've been over in ARM space, haven't been paying attention. What's the PRM stuff? End of SMM would make me happy, it's a hot mess over there.
<Bitweasil>
> A processor executing in the 0-3 ring privilege levels will not be
<Bitweasil>
able to read from or write to SMRAM space.
<Bitweasil>
"Should not..." :p
<Bitweasil>
Far too often it's been left open or trivial to unlock.
<heat>
hah
<Bitweasil>
So they're abandoning the STM concept entirely? Good...
<Bitweasil>
(the SMM hypervisor - let's move the problems one level lower!)
<targetdisk>
that sounds fun ;)
<Bitweasil>
Hm. Also, I disagree that all cores are *required* to enter SMM. They all *do* because current handlers require it, but it's not a hardware requirement that I'm aware of.
<Bitweasil>
Spent 3 years working on introspection from that space.
truepassion has joined #osdev
<targetdisk>
as in introspection of system state?
<targetdisk>
what does introspection mean in this context
<truepassion>
hi, does anyone know if it is possible to access memory mapped registers from linux kernel ebpf program
<Bitweasil>
heat, thanks, I'm glad to see SMM going away, at least in theory. Would improve a lot...
<Bitweasil>
targetdisk, "peering into" a running OS or hypervisor to evaluate the state of it.
<Bitweasil>
Looking in from the outside.
<heat>
Bitweasil, np
<heat>
tbf i think they always serialize all CPUs into SMM because of TOCTOU bugs
<targetdisk>
nice Bitweasil! that's pretty sick
<heat>
truepassion, i don't know but i seriously doubt it
<Bitweasil>
The concept was, among other things, being able to do things like measure (hash) the kernel, hypervisor, etc, code spaces, to see if they'd been changed/modified. It's impossible to "protect Ring 0 from Ring 0" - so the concept was to see what we could do from outside.
<heat>
and it's probably the wrong idea anyway
<Bitweasil>
The STM (SMM hypervisor) is the most privileged place on the system, and you get nice VMX interactions with the OS - you exit from the executive hypervisor down to the STM, enter from the STM to either the SMM handlers or the executive hypervisor. So we could do some neat stuff with that, performance counters (they can fire an SMI#), etc.
<Bitweasil>
truepassion, I'd expect ebpf to be rather locked down in what it can do.
<heat>
haha great joke
<Bitweasil>
heat, yeah, because SMM handlers are a hot mess of hand written assembly. :p
<Bitweasil>
Hm?
<heat>
eBPF has greatly expanded in crap it can do
<Bitweasil>
Aw. :(
<Bitweasil>
Well, yet another datapoint for Qubes.
<heat>
there were suggestions for eBPF scheduling a few months back
<Bitweasil>
As we were talking about yesterday, I think in here, I just don't trust the kernel.
<Bitweasil>
Honestly, I think I just hate computers anymore. :)
<targetdisk>
yeah Linux is *big*
<heat>
Bitweasil, aren't SMM handlers mostly C? just the entry/exit stub is asm
<heat>
in the EFI era at least
<Bitweasil>
[handwave]
<Bitweasil>
I don't know what a lot of OEMs have done.
<Bitweasil>
I'd like to think so, but I believe that there's also old binary blobs and stuff in there from the old hand written assembly era. At least, that was one of the concerns the STM tried to solve: OEMs saying, "We don't know how to rewrite this securely."
<Bitweasil>
And that was convincing enough for Intel to dance and add the dual monitor mode.
<Bitweasil>
It all goes back to the HAP stuff (High Assurance Platform).
<heat>
they wouldn't know how to write it securely anyway ;)
<Bitweasil>
Which was a dumb idea to start with, but there was money behind it.
<Bitweasil>
Yeah, and the expectation was that those same OEMs could write a secure STM. <Narrator>But they couldn't.</>
<truepassion>
heat: Bitweasil: thanks. not sure if people use ebpf to handle network packets and may be send them back via the neetwork card. if so, would it require MMIO access?
<heat>
your best chance would be to hope there are eBPF network calls to let you do that
<Bitweasil>
I would say that I didn't think eBPF could actually interact with the network card, only with the packet data, but... anymore, I've apparently no idea what it can or can't do.
<Bitweasil>
DMA isn't fast enough for modern NICs, so there's DCA (direct into L3 cache) support on some newer Intel chips.
<targetdisk>
and if hope runs out, maybe write something that uses DPDK in userspace if you need high performance
<bslsk05>
www.intel.com: Beyond Direct Memory Access: How to Reduce the Data Center Tax
<kof213>
linked from wikipedia: "Modern PCs are horrible. ACPI is a complete design disaster in every way. But we're kind of stuck with it. If any Intel people are listening to this and you had anything to do with ACPI, shoot yourself now, before you reproduce." -- linus i do not know enough about ACPI, just it was buggy back then
<Bitweasil>
Well, anyway. It's DCA, if you want to look it up.
<Bitweasil>
There's also L3 cache partitioning in the newer Xeons.
<Bitweasil>
Yeah, Linus is pretty much spot on there.
<Bitweasil>
However bad you think ACPI could be, it's worse. :)
<Bitweasil>
mmm... let me see if I can find it. There was a proof of concept ACPI exploit that would root a Linux box if you plugged and unplugged the power adapter in the right pattern...
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<Bitweasil>
That's my current box. It's amazing. I've been trying to get ARM boards to desktop status for years, and this "just works," and even runs Qubes out of the box with no dramatic issues.
<heat>
oh an x86 SBC? that's cute
<heat>
>A configurable Unlimited Performance mode allowing the CPU to run in sustained turbo boost mode.
<heat>
UNLIMITED PERFORMANCE
<heat>
LITERALLY NEVER ENDS
<heat>
+INF%
<Ermine>
UNLIMITED POWER
pounce has quit [Remote host closed the connection]
pounce has joined #osdev
<Bitweasil>
Yeah, it's still not fast. But at least it's not throttled to a particular power point. You can pull the... oh, PL2, PL3, whatever the long term limit down if you need.
<Bitweasil>
I think it'll still throttle thermally.
<Bitweasil>
But with a fan on it, it'll ride the turbo limit.
<Bitweasil>
Huh, not sure if Xen is using turbo mode or not.
<Bitweasil>
Anyway, I just don't care about system performance anymore. :)
<heat>
ChavGPT in shambles
<Bitweasil>
I'll run clanky stuff with Qubes and wait for it to finish.
<Bitweasil>
Hm?
<heat>
he's our local performance nut
<kof213>
chav is the budget doug16k j/k
<heat>
hmm no doug16k wasn't really performance-focused IIRC
<heat>
more like CPU/microarch focused
<Ermine>
Btw where's ChavGPT
<heat>
here
<Ermine>
Didn't hear him for a while
<mcrod>
what happened to mrvn
<heat>
Ermine, literally spoke some 30 mins ago
<Ermine>
ok
<Ermine>
my bad
<heat>
SHAME ON YOU
<mcrod>
i am heavily debating on something terrible
<heat>
you mean samething
<heat>
hehe
<Ermine>
Please, have a mercy on me!
<mcrod>
by the way
<moon-child>
I don't like ChavGPT
<moon-child>
I miss mjg59
<mcrod>
SAMEthing was fully capable of broadcasting the emergency alert test that went out yesterday
<heat>
yeah i miss mjg59 too
<CompanionCube>
64-bit mjg when?
<heat>
there's no need for more than 59 bits
<heat>
it's a very nice, round number
<mcrod>
i wonder if I should buy an EPYC
* mcrod
think
<Ermine>
I'd vote for another 10 bits
<mcrod>
how fast does LLVM compile on the top tier $11,000 EPYC
<moon-child>
how come doug16k gets 16384 bits then
<Bitweasil>
Depends on how parallel the build is, I'd think.
<moon-child>
is this like rsa and ed25519 having different key sizes (4096 bits vs 25519 bits)?
<bslsk05>
www.anandtech.com: Compiling Performance / LLVM - AMD EPYC Milan Review Part 2: Testing 8 to 64 Cores in a Production Platform
<mcrod>
dunno how much this is to be believed
* kof213
read that as llvm compiling something...and went to make a joke, but it seems you did say llvm compile
<mcrod>
well don't worry kof213
<kof213>
s/ /-/ that is just one long verb
<mcrod>
i wish i had $11k to just drop on an EPYC
gbowne1 has joined #osdev
gbowne1 has quit [Remote host closed the connection]
gbowne1 has joined #osdev
gbowne1 has quit [Remote host closed the connection]
gbowne1 has joined #osdev
pounce has quit [Remote host closed the connection]
pounce has joined #osdev
pounce has quit [Remote host closed the connection]
pounce has joined #osdev
pounce has quit [Remote host closed the connection]
pounce has joined #osdev
* ChavGPT
burps
<heat>
ChavGPT, where did you hide mjg59
<ChavGPT>
somewhere in initrd
ChavGPT is now known as niceperson
<niceperson>
aight
<niceperson>
hello there
<niceperson>
i'm feeling like benching onyx
<niceperson>
can you ship me an image with will-it-scale
<niceperson>
there is no way i'm building your stuff
<zid>
oops, forgot to -4 one of my irc connections
<zid>
guess we're Local host: goggles.dot.gog.dot.goggendorf.at (2001:470:1f09:1cfb::606) now
<moon-child>
ipv6? traitor!
<moon-child>
'[zid] actually using host 81.101.221.143'
<zid>
'one of my'
<Ermine>
oh, I've got some unfinished stuff here
<zid>
is it cake
<Ermine>
please wait one eternity and I'll build it for you
<Ermine>
but actually niceperson, be nice person and use those shiny new instructions
kof213 has left #osdev [#osdev]
<niceperson>
heat: may i please have a bootable onyx image
<heat>
niceperson, k give me a bit
danilogondolfo has quit [Remote host closed the connection]
<heat>
actually that's kind of annoying since my tree isn't clean
<heat>
the effort i make for nice people...
<heat>
ugh actually just build it yourself if you're so nice
<heat>
ermine wrote some great build instructions
gorgonical has joined #osdev
<niceperson>
you could appreciate i'm willing to run it on a modern uarch
<heat>
you running it on sapphire rapids?
<niceperson>
i do intend to, yes
<heat>
WONTFIX my software isn't designed to run on those many cores
<niceperson>
i intend to run on 16
<niceperson>
definitely not on bare metal
<heat>
WONTFIX my software isn't designed to run on those many cores
<niceperson>
i can scale it down to 8
<niceperson>
but below that may as well use openbsd instead
<heat>
mid-level laptops from 2018 only!
* Ermine
is still on 4 cores
<niceperson>
my laptop is on 4 *threads*
<niceperson>
i'm compensating by developing on bigger machines
<heat>
but srsly i don't think you're going to find much interesting stuff. what scales now will probably scale on whatever uarch with however many cores as long as it's not a stupid number (cough cough sapphire rapids)
<gorgonical>
my laptop is a i5-3320m with 4 cores lol
<Ermine>
i don't have hyperthreading, so I have 4 cores too
<heat>
what doesn't scale now obviously won't scale
<heat>
oh, second disclaimer: I DONT HANDLE NUMA
<Ermine>
I found a book where NUMA was mentioned as better than UMA
<heat>
i mean...
<heat>
maybe? if software is set up right
<niceperson>
i would not run you on numa
<heat>
which is really tricky to do
<niceperson>
i'm in the mood for some OS drag racing
<heat>
ok
<heat>
as long as you don't need disk
<niceperson>
i'm going to do some gentle will-it-scale testen
<gorgonical>
disks are for chumps who don't just memorize everything they've ever typed
<heat>
niceperson, i'm even ENABLING LTO
<heat>
actually no
<heat>
then the flamegraph will come out like shit
<heat>
we don't want that do w
<heat>
e
<Ermine>
So, is there no way to have onyx on disk?
<heat>
there is, but it's not super stable
<heat>
i've been in the middle of fixing it
<heat>
the problem is that page cache dirtying/flushing is a bit borked
<moon-child>
niceperson: when you have a shitton of sockets, can you have sockets closer and others farther away?
<Ermine>
ic
<niceperson>
moon-child: if you re asking if all interconnects are of equal speed, the answer is no
<niceperson>
wold you mind not mentioning snmalloc
<heat>
gl hf
<niceperson>
did you bundle will it scale
<heat>
will boot to a tmpfs, just run tests normally, they're all installed to /usr/bin and in PATH
<heat>
yep
<moon-child>
I mean generally. A wants to message C, also wants to message B. Also A and B are close and B and C are close, but A and C are far. A should send both of its messages to B and let B forward the message to C fo rit
<niceperson>
that is something you are going to have to measure
<niceperson>
note that latency is not constant here either
<heat>
also /usr/bin/flamegraph captures some 10s of input and shits out to stdout a thing you can pass to stackcollapse.pl
<moon-child>
what would make it vary?
<moon-child>
Conjestion?
<niceperson>
networking?
<heat>
ROUTING
<niceperson>
do i need to serial porti nto it to extract anything
<heat>
niceperson, probably easier if you get a serial on it yeah
<niceperson>
i think it failed to boot
<niceperson>
screen is blank, got nothing after grub
<niceperson>
and claim it is loading initrd
<heat>
oh uh
<heat>
how much memory
<niceperson>
4G
<heat>
what happens if you give it like 2G
<niceperson>
booted with 1
<niceperson>
will try more later
<niceperson>
maybe
<heat>
ok thanks
admiral_frost has quit [Quit: It's time]
<heat>
do you have EFI on? or just a regular BIOS vm?
<niceperson>
also something crashes due to uncaught exception when /dev/eth0 is missing
<heat>
yeah ignorable
<niceperson>
i did not check
<niceperson>
just clicked away in virt-manager
<niceperson>
:X
<heat>
open the qemu monitor and do info roms
<niceperson>
get some tab comlpetion
<heat>
there's a bash port i didn't include
<heat>
sorry
heat has quit [Remote host closed the connection]
heat has joined #osdev
<niceperson>
getppid is only 12 mln
<niceperson>
that's literally lower than linux
<niceperson>
vfsmix is at 66k, when linux is doing 100k
<niceperson>
(tmpfs-backed)
<heat>
MY OS IS SLOWER THAN LINUX??
<niceperson>
it crashed
<Ermine>
mind trying minix?
<heat>
oh shit
<heat>
crashed on what?
<Ermine>
I wonder how bad numbers are there
<niceperson>
Ermine: maybe later
<niceperson>
heat: you really need to patch it to print panics over serial port
<heat>
something is going oopsie with the e1000 driver, i think
<heat>
just use virtio-net
netbsduser has joined #osdev
<klange>
that does seem to result in netctld initializing without an error about eth0 being missing, but I still have network
<klange>
also your "ip" command responds to "ip help" by telling me to run "ip help"
<heat>
hah ip(1) isn't finished
<heat>
you don't have network?
<klange>
well ping does not seem to work, at least
nyah has quit [Quit: leaving]
<klange>
pinging a domain times out on getaddrinfo, pinging an IP that should work fine results in 'Socket not connected'
<heat>
weird
<heat>
what are you passing for virtio-net?
<klange>
`-nic user,model=virtio-net-pci`
<heat>
hmm i think i broke networking
<heat>
fuck
<heat>
in my defense it's really hard to test everything on every commit
<klange>
f
<mcrod>
i reject your defense
<klange>
you need a test suite [says the person who hasn't had a test suite in years]
<mcrod>
and sentence you to rm -rf
<moon-child>
CONTINUOUS
<moon-child>
INTEGRATION
<klange>
[though having a gui with lots of crap that runs on startup, like several things that want working networks, means I do test nearly everything just by booting]
<heat>
klange, i have a test suite but it's not really comprehensive and qemu TCG regularly times out in github actions
<heat>
it's annoying
<klange>
You need your own runner so you can KVM :)