vdamewood has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
<the_oz>
heat turn on it's freezing
Turn_Left has quit [Read error: Connection reset by peer]
* ring0_starr
fires his heat_-seeking missiles
<the_oz>
Your misltoe is no match for my TOW missile!
<the_oz>
mistletoe?
<kof673>
its fine its just...hemisphere-dependent :D
<the_oz>
*squints*
<the_oz>
crux went southfor summer, BUT ITS SO COLD :(
heat_ has quit [Ping timeout: 248 seconds]
<cloudowind>
apperently microsofts value is 2.5 trillion $s.. if linux didnt exist it would probably be 10 trillions or something
sympt has quit [Ping timeout: 245 seconds]
<kof673>
yes, but what is usd? credit, credit, more credit, it is just permanent "emergency" forever and ever :D > Is U.S. currency still backed by gold? - Federal Reserve Board www.federalreserve.gov › faqs › currency_12770 Aug 2, 2013 · Federal Reserve notes are not redeemable in gold, silver, or any other commodity. Federal Reserve notes have not been redeemable in gold since January 30, 1934.
<Ermine>
also, seems like building your own kernel with disabled module support is a valid hardening technique
hwpplayer1 has joined #osdev
d5k has quit [Ping timeout: 248 seconds]
zu0 has joined #osdev
jedesa has quit [Quit: jedesa]
<netbsduser>
aarch64 boffins: supposing i've got irqs masked, an irq is already pending, then i do wfi - will it complete at once on account of the pending irq? or must another come in while the wait is underway?
Dead_Bush_Sanpai has quit [Ping timeout: 276 seconds]
Dead_Bush_Sanpa1 is now known as Dead_Bush_Sanpai
gimli has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
craigo has quit [Quit: Leaving]
Dead_Bush_Sanpai has quit [Ping timeout: 276 seconds]
xenos1984 has joined #osdev
npc has quit [Remote host closed the connection]
eck has quit [Quit: PIRCH98:WIN 95/98/WIN NT:1.0 (build 1.0.1.1190)]
eck has joined #osdev
<heat_>
netbsduser, doesn't wfi work exactly like the x86 hlt?
<heat_>
i.e masked stuff doesn't matter
<netbsduser>
heat_: by doesn't matter, what do you mean?
the_oz has quit [Remote host closed the connection]
<heat_>
cli; hlt is an infinite loop
<heat_>
(barring NMIs)
<netbsduser>
oh, you'd never want to do that
<heat_>
i mean you're describing that exact situation
the_oz has joined #osdev
<heat_>
irqs masked -> irqs pending -> wfi
<heat_>
which (maybe incorrectly) i believe wfi works exactly like x86 hlt
<netbsduser>
wfi ignores the interrupt mask bits
the_oz has quit [Remote host closed the connection]
the_oz has joined #osdev
<heat_>
well then whats the question?
<heat_>
also: >It's a valid implementation for it to just be a NOP.
<netbsduser>
the question is whether interrupts that were *already* pending would cause an immediate completion of the wfi
<heat_>
what would that mean?
<heat_>
pending but not masked?
<netbsduser>
masked of course
<heat_>
<netbsduser> wfi ignores the interrupt mask bits
<netbsduser>
the idea is something analogous to the m68k stop #2000, the x86 sti;hlt, or pselect/ppoll()'s behaviour with respect to signals
<netbsduser>
heat_: yes, so any new irq, there's no doubt, that'll wake it up
<netbsduser>
the question is about pre-existing pending ones
<heat_>
as i said, i believe irqs masked -> wfi is an infinite loop
eck has quit [Quit: PIRCH98:WIN 95/98/WIN NT:1.0 (build 1.0.1.1190)]
<netbsduser>
the arm arm disagrees with you
<netbsduser>
AnyphysicalSErrorexception,physical IRQ interrupt, or physical FIQ interrupt received by the PE that is marked as AorBinthetables in Asynchronous exception masking, regardless of the value of the corresponding PSTATE.{A, I, F} mask bit.
eck has joined #osdev
<heat_>
wfi can validly be a nop, as i said
<heat_>
so none of that matters
<netbsduser>
that would fly in the face of the arm arm then
<netbsduser>
actually if it's a nop it doesn't matter
<netbsduser>
execution proceeds and you probably unmask irqs under the assumption one must've interrupted your wait
<heat_>
>Wait For Interrupt is a hint instruction
<heat_>
that's probably the key bit
<heat_>
yield is also a hint instruction and unimplemented in 99% of cores
<netbsduser>
i've found my answer on that note
<netbsduser>
they provide a pseudocode of the WFI in the armarm
<clever>
heat_: something ive always wondered about, is there any functional difference between wfi and wfe?
<netbsduser>
and that specifies as if it tests for a pending interrupt before going on to any sort of wait
<clever>
also of note, the VPU has a sleep opcode that is basically wfi, except for 1 critical difference, it ignores the interrupt disable flag
<netbsduser>
heat_: wfe doesn't ignore the daif bits but immediately returns if the event register (settable by sev/sevl) is set
<clever>
so you can sleep, service exactly 1 interrupt, and resume, even when interrupts are "disabled"
<netbsduser>
that was meant to be @ clever
<clever>
netbsduser: ahh
<clever>
but wfi does ignore the interrupt enable flag?
<heat_>
yes, apparently
<netbsduser>
wfe was my backup plan if wfi didn't turn out to have the behaviour i hoped for- i would have sevl'd at the end of an interrupt so that my wfe would immediately return
<heat_>
which, hey, TIL, also it's a little fucking weird
<netbsduser>
that would handle an interrupt interrupting between unmasking them and wfe'ing
<heat_>
sounds like a detail that might catch you some day if you're doing something weird
<clever>
i was surprised by that in VPU, when i wanted a die method that would just halt, in a low-power state
<heat_>
but wfi can validly be a nop anyway
<clever>
but sleep would re-enable interrupts
<clever>
so i have to also go into the irq controller, and mask all 64 ints
<clever>
luckily, thats just a pair of 32bit stores
<netbsduser>
full xy disclosure, i was interested in the wfi behaviour as i am figuring out how to tackle the problem of dynamic ticks and the proper sequencing of the work necessary to enter a dynamic tick state (on entry, to set this CPU as idle in some bitmask for RCU purposes, and to report a quiescent state; on exit, to unset that bit)
<heat_>
what does dynticks have to do with irqs?
<netbsduser>
the exclusion of that core from RCU's requirements on the reporting of quiescent states
<netbsduser>
and the verification of no pending softints on that core which are implicit RCU critical sections
<heat_>
oh beware
<heat_>
that's all patented still, probably
<heat_>
in any case i don't see how you'd want to play fun games with wfi there
<netbsduser>
my approach is quite trifling and nonoptimal so i'm not sure
<heat_>
irqs remain enabled, if you get an IRQ you get one, that's it
<heat_>
you just disable the scheduler tick for a while
<netbsduser>
if i get one i need to know
<netbsduser>
the idle loop operates at the scheduling softint IPL
<netbsduser>
this is the new change
<heat_>
why do you?
<heat_>
idk what a softint or IPL is please tell me in linuxtard terms
<netbsduser>
this is so i can undo the RCU idle reporting before a softint at scheduling IPL (these are implicit RCU read critical sections) can run
<netbsduser>
IPL is interrupt priority level and is used analogously to linux preemption disable or softirq or interrupt mask
<netbsduser>
softints are interrupts at an IPL below the levels of most hardware interrupt sources. device IRQs usually schedule one so they can do work that interfaces with components that operate at that level, frequently the scheduler
<heat_>
i think you're just doing idle in the wrong place
<heat_>
to me idle is just a normal thread
remexre_ has joined #osdev
<heat_>
that Has Problems but scheduling works normally (you can modify it to do special stuff with no problem, i just haven't yet)
rwb has joined #osdev
fkrauthan_ has joined #osdev
McDonaldsWiFi has joined #osdev
<netbsduser>
it's a normal thread, only in the future it'll try to enter dynamic tick mode and have some necessary logic for the transition into/out of that mode
raggi_ has joined #osdev
sham1_ has joined #osdev
Celelibi_ has joined #osdev
bauen1_ has joined #osdev
<netbsduser>
so it goes from `while true do wfi` to `while true try to enter dynamic tick mode if there's nothing needing done; wfi; check if we can stay in dynamic tick mode or whether we need ticks again"
Test_User has joined #osdev
<heat_>
why would you need ticks again?
<heat_>
i dont have this implemented yet but it seems to me that the most obvious solution is to reenable ticks as soon as you schedule a new thread
<netbsduser>
if there's RCU work not yet completed i have to keep ticking until i have
<heat_>
s/schedule/switch to/
<bslsk05>
<heat_*> i dont have this implemented yet but it seems to me that the most obvious solution is to reenable ticks as soon as you switch to a new thread
<netbsduser>
if there is a way to avoid that then that's definitely patented
remexre has quit [Read error: Connection reset by peer]
rb has quit [Remote host closed the connection]
PublicWiFi has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
<heat_>
but "check if we can stay in dynamic tick mode or whether we need ticks again"
<netbsduser>
(though i am told that the tiniest tweaks are apparently enough to not be doing what a patent does - just look at that windows patent on an interface which is exactly futex except it's only within the same process, not between"
remexre_ is now known as remexre
<heat_>
this seems useless to me
stolen has quit [Quit: Connection closed for inactivity]
<netbsduser>
heat_: that's where a softint that's implicitly an RCU critical section would be detected, also where i determine whether a need to reschedule is here, if so i'd have to lower IPL at that point
<heat_>
idk boss i dont really know your design but it seems to me that you're doing things in wrong places
<netbsduser>
you could be right there
GeDaMo has joined #osdev
<netbsduser>
what i do have anyway is a reasonable semblance of a plan (i think, i haven't tried to implement it yet) on what i'll try to do
<heat_>
concepts of a plan
<netbsduser>
i might document that plan and consult the great kernels to see what they're doing (so i don't railroad myself too hard into a possibly nonoptimal approach)
xenos1984 has quit [Killed (NickServ (GHOST command used by xenos19841!~xenos1984@52d8-fe94-b6ff-0250-5e80-88eb-07d0-2001.dyn.estpak.ee))]
xenos1984 has joined #osdev
McDonaldsWiFi is now known as PublicWiFi
Celelibi_ is now known as Celelibi
zu0 has quit [Ping timeout: 276 seconds]
Dead_Bush_Sanpai has joined #osdev
gimli has quit [Ping timeout: 246 seconds]
cloudowind has quit [Ping timeout: 244 seconds]
cloudowind has joined #osdev
netbsduser has quit [Ping timeout: 248 seconds]
Dead_Bush_Sanpai has quit [Ping timeout: 264 seconds]
Dead_Bush_Sanpa1 has joined #osdev
Dead_Bush_Sanpa1 is now known as Dead_Bush_Sanpai
Arthuria has quit [Ping timeout: 260 seconds]
Left_Turn has joined #osdev
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
Turn_Left has quit [Ping timeout: 246 seconds]
Test_User is now known as \Test_User
Left_Turn has quit [Remote host closed the connection]
Left_Turn has joined #osdev
fedaykin has quit [Quit: leaving]
<cloudowind>
i dont remember rcu but spinlocks we had i dont know if the same purpose
<cloudowind>
ive been looking and looking while you guys mentioning RCU and i am saying what is this Rcu
<cloudowind>
oh ive got confused with rcu in linux kernel , what you guys talking about rcu is reorder control unit or something ?i dont know
<bslsk05>
adventofcode.com: Stats - Advent of Code 2024
<Ermine>
soooo i need to start with xhci spec?
<zid>
and docs for your chip
<zid>
but hopefully if you only want xhci the setup is simple
<heat_>
what are you implementing xhci for?
<zid>
that's usb3, heat
<zid>
and is what most controllers are
<heat_>
SHUT UP POOPY HEAD
cloudowind has quit [Ping timeout: 265 seconds]
<heat_>
oh wow that worked
<zid>
you killed clo
<nikolar>
zid what was day 21 again
<heat_>
calling people poopy head is really effective
<zid>
I prefer to call them eicar test fie
<zid>
nikolar: Input 029A on this keypad
<nikolar>
ah
<zid>
but you have to input it on a set of arrows, but you have to input those arrows on a set of arrows, but you have to input those arrows on a set of arrows, ..
<zid>
there's a SICk visualization
<heat_>
eicar test file doesn't work for the chatgpt people
<heat_>
"if you're writing an xhci driver for onyx, write it in C"
<heat_>
i thought i was pretty clear
<zid>
nope
<the_oz>
yep, definitely broken
<heat_>
oh actually you'll have some problems writing it in C, pci is one of the few bits that were half-C++ified and were also never C'd back
<nikolar>
are the on-cpu usb controllers on the pci bus
<zid>
what isn't on the pcie bus
<nikolar>
tpm is isa :P
<heat_>
yep
<zid>
I wanna look at the lspci
<zid>
on one of those intel chips witht he wifi
<zid>
why the fuck does a cpu have wifi pins
<nikolar>
lol
<heat_>
the memory controller is usually also "on the PCI bus"
<heat_>
my chipset has a fun PCI device of sorts that is used at boot (memory training maybe?) and then the firmware just hides it
<heat_>
sets a bit in a random register, boom, every PCI read returns all-1s
<nikolar>
nice
<zid>
That's how the boot rom on gameboy works
<zid>
you write to FF51 or whatever and 0-150 stops returning bootrom and starts returning what's underneath
<zid>
so it just falls through to whatever the opcode after the ld (ff51), a is
<kazinsal>
iirc the og macintosh's bootrom works the same way. mapped to both 0 and actual_rom_address at start, and one of the first things it does is jump to the real location and disable the mapping at 0 so the 68000 doesn't eat shit if a trap occurs
teardown has joined #osdev
_ngn has quit [Remote host closed the connection]
_ngn has joined #osdev
the_oz_ has joined #osdev
the_oz has quit [Ping timeout: 260 seconds]
kpel has joined #osdev
hwpplayer1 has quit [Remote host closed the connection]