channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=23&m=1&d=11
00:02:00 <heat> zid, my "main" loop is also a hlt
00:02:00 <heat> checkmate boros
00:02:00 <heat> boros? more like shitos
00:02:00 * mjg write bezos
00:02:00 <moon-child> halt is slow
00:02:00 <moon-child> it makes the cpu slow down
00:02:00 <mjg> rust makes cpu go brrr
00:03:00 <moon-child> for MAXIMUM PERFORMANCE, you should run the cpu at its MAXIMUM FREQUENCY all the time
00:03:00 <heat> mjg, seriously when do you write your own
00:03:00 <moon-child> I will put mjgos on all my servers
00:04:00 <heat> yeah it ought to be fast
00:06:00 <zid> given branch prediction exists
00:06:00 <zid> do you think jmp -2 takes 0 cycles
00:06:00 <mjg> i already had a system with printf and hookers
00:06:00 <zid> and thus has infintie performance
00:06:00 <mjg> jmp always incurs a delay
00:06:00 <zid> not if the uop streamer guy deletes it
00:07:00 <mjg> u sure that happens
00:07:00 <mjg> cause i know of a lol case which depends on jmps incuring a delay
00:07:00 <heat> https://gist.github.com/heatd/9326eab8a7887453b25ef7dd42e786a9
00:07:00 <bslsk05> gist.github.com: nopies.cpp · GitHub
00:07:00 <heat> tldr no
00:08:00 <zid> what have you got against pies
00:08:00 <heat> small jumps are still slightly slower than just nop'ing
00:09:00 <gog> noppies
00:10:00 <moon-child> mjg: o.o what code does that
00:11:00 <mjg> moon-child: SOLARIS MOTHERFUCKER
00:12:00 <mjg> they have it as a hack in case pause does not work
00:12:00 <moon-child> ahaha
00:12:00 <moon-child> also there are so many queues it's not clear what counts as 'delay'
00:12:00 <zid> I think to test if jmps have delays after uop stuff you'd need to put a big stall before the jmp
00:12:00 <zid> so that it had definitely finished decoding it first
00:13:00 <zid> if you're in a nop sled you're presumably just measuring decode bw
00:14:00 <zid> which x86 kinda sucks at
00:14:00 <moon-child> what are you referring to as a stall with jmps if not decode?
00:15:00 <zid> whether the jmp actually takes time to execute
00:15:00 <zid> obviously it takes time to fetch and decode
00:15:00 <moon-child> oh like if it actually goes to the backend?
00:15:00 <moon-child> agner says it does, but I don't understand why
00:15:00 <zid> I assumed it just did the qemu tcg linking thing
00:16:00 <zid> and splatted the instruction before's microops, and then the instruction after the jump's microops, consecutively
00:16:00 <moon-child> more interesting though would be to know if you have to wait before you can start decoding at the new location, and if so how long
00:16:00 <zid> into the uop cache
00:16:00 <moon-child> I would guess it depends on btb hotness
00:16:00 <gog> how does it even alter the ip
00:16:00 <gog> does it copy to a temporary register
00:17:00 <gog> add
00:17:00 <zid> who needs IP
00:17:00 <gog> no i'm asking how the fuck computers work
00:17:00 <zid> only 'push' actually cares about IP
00:17:00 <zid> err 'call'
00:17:00 <gog> i don't even know how to program
00:18:00 <gog> i crib everything from stackoverflow
00:18:00 <klange> it's all pixies
00:18:00 <zid> real hw is grabbing cache lines and walking through them forwards decoding them and reordering shit and other nonsense
00:18:00 <klange> you trick them into doing your bidding with the electrons
00:18:00 <zid> by the time anything actually runs, IP isn't really a concept
00:19:00 <moon-child> of course it is
00:23:00 <gog> i'm a fraud and a clown
00:23:00 <zid> I thought you were a vtuber
00:24:00 <heat> why not all 3
00:24:00 <mjg> i'm a social media influencer
00:25:00 <heat> old news
00:25:00 <moon-child> mjg: i thought you were a tiktoker
00:25:00 <heat> im looking for hot steamy sex, you can reach me at tech-kern@netbsd.org
00:26:00 <mjg> dude i twerk my solarium-improved ass and get views
00:26:00 <mjg> i watched a vice documentary on tik tok influencer houses, or whatever the name
00:26:00 <mjg> one girl says she stares into the camera and people watch that
00:26:00 <mjg> like lol
00:26:00 <mjg> i think this one https://www.youtube.com/watch?v=L_432I88eVQ
00:26:00 <bslsk05> 'These Kids Are Skipping College to Be TikTok Famous' by VICE News (00:22:56)
00:27:00 <mjg> try are round 4:30
00:30:00 <gog`> pog
00:31:00 <heat> goggles
00:31:00 <zid> (poggles)
00:31:00 <moon-child> pog`
01:48:00 <geist> COMPUTERS
01:52:00 <zid> Nah, food
02:01:00 <moon-child> definitely food
02:12:00 <kaichiuchi> sushi?
02:32:00 <heat> geist, computer
02:35:00 * geist nods, sagely
02:35:00 <geist> computer.
02:39:00 <heat> i really regret engaging with tianocore
02:39:00 <heat> it pisses me off to no end
02:48:00 <heat> https://jtsylve.blog/post/2022/11/27/APFS-Advent-Challenge-2022
02:48:00 <bslsk05> jtsylve.blog: 2022 APFS Advent Challenge – Joe T. Sylve, Ph.D. – Digital Forensic Researcher and Educator
02:54:00 <geist> oh interesting, looks like an interesting read
03:19:00 <zid> sizeof(uint32_t);
03:19:00 <zid> #define FOUR 4
03:19:00 <heat> I do sizeof(uint32_t)
03:19:00 <heat> deal with it
03:19:00 <zid> yea it's legit if you're using it as abstraction for 4
03:32:00 <geist> well, if you're on a 16bit machine then the sizeof(uint32_t) would be 2
03:33:00 <geist> ie, a TI Piccolo, which i dealt with in 2014 and still exists
03:33:00 <geist> and yeah i know you're not likely to hit it, but that kinda stuff *does* still exist. i had to fiddle with some of my code when i took some bits out of LK and ran it on a piccolo
03:34:00 <geist> notably things that assumed a char was 8 bit, and/or memcpy(..., N) copied N bytes
03:34:00 <klange> Those are for analog sampling? Not _technically_ audio equipment, but basically the same idea?
03:34:00 <geist> actually TI piccolo is used in a lot of motor controller stuff
03:35:00 <geist> but it's basically a wonky 16 bit arch, where the smallest unit of addressible meory is 16 bits
03:35:00 <geist> which is of course perfectly legal in C
03:37:00 <geist> well, actually 32bit arch, now that i looked at it, but it did't have a huge address space
03:50:00 <zid> geist: The code would break if CHAR_BIT was not 8
03:53:00 <geist> yup
03:55:00 <zid> That's why I said it's just an overly complicated way of writing 4
08:03:00 <ddevault> yeah it was the memory barriers
08:14:00 <zid> It's always the memory barriers
08:43:00 <x8dcc> I am adding an IDT now and although I have some ideas on how to do it (initialize it) I am not sure about some stuff
08:44:00 <x8dcc> first of all, I would need a full 256 entry idt, right? and I would need to initialize it as 0 (at least the present bit)
08:45:00 <x8dcc> and on top of that, fill the entries I want to use/handle
08:46:00 <x8dcc> I thought about declaring the idt bytes (for the 256 entries) in assembly, but I am not sure if it's the best idea because afaik it will be easier to fill it from a C function
08:54:00 <zid> you don't need all 256 entries
08:54:00 <zid> but you might as well leave the space for it regardless
08:54:00 <zid> so that you don't need to keep moving it around as it grows
08:54:00 <x8dcc> yeah I see
08:54:00 <x8dcc> I thought I did
08:55:00 <zid> the IDTR contains the size in bytes (less 1) of the IDT
08:55:00 <x8dcc> still, I am not sure where to declare it because I the IRS will be in C
08:55:00 <zid> IRS?
08:55:00 <zid> oh interrupt servic routines?
08:55:00 <x8dcc> so I don't know which way would be easier
08:55:00 <x8dcc> ISR*
08:55:00 <x8dcc> yeah yeah
08:55:00 <zid> easier for me is C, idk what you find easy
08:56:00 <x8dcc> I see, thanks
08:56:00 <x8dcc> and yeah, I know its the size - 1, noticed from the gdt :)
08:56:00 <zid> https://github.com/zid/boros/blob/master/interrupt.c I don't really dick much with interrupts so this is a teeny C version
08:56:00 <bslsk05> github.com: boros/interrupt.c at master · zid/boros · GitHub
08:56:00 <zid> 64bit so the shifts and stuff will be different, but you get the idea
08:57:00 <x8dcc> yeah, I will have a look now. Thanks!
09:22:00 <ddevault> ESR == 0x2000000
09:22:00 <ddevault> whelp
09:28:00 <ddevault> on... mov x8, x0?
09:30:00 <ddevault> nothing in ARMARM D17.2.37 seems to be relevant
09:32:00 <ddevault> this code worked yesterday :<
09:41:00 <x8dcc> zid: why do you exactly need to remap the IRQs? I saw that in other projects as well but I am not sure what that does
09:52:00 <ddevault> well, it wasn't the data or instruction caches
09:52:00 <ddevault> that's the only lead I could find
09:53:00 <ddevault> hm, maybe SPSR is wrong
09:57:00 <zid> x8dcc: 0+ is where cpu exceptions are
09:57:00 <zid> you won't be able to tell IRQ1 apart from #DIV
09:57:00 <zid> etc
09:57:00 <ddevault> sure would be nice if firefox would load the end of ARMARM so I could get to the register index
09:59:00 <ddevault> nope, looks fine, only thing set is the carry flag
09:59:00 <ddevault> what the hell
10:02:00 <gog> computer?
10:02:00 <zid> no
10:02:00 <zid> no computer
10:02:00 <gog> zid did you sleep
10:02:00 <zid> no
10:02:00 <gog> do you work
10:03:00 <zid> no
10:03:00 <gog> fair enough
10:03:00 <gog> you want money
10:03:00 <zid> yes pelase
10:03:00 <x8dcc> zid: I don't understand what you mean by "0+"
10:03:00 <zid> 2 sacks
10:03:00 <zid> x8dcc: rather than 32+
10:04:00 <zid> the numbers larger than 31
10:04:00 <x8dcc> I stil don't know what you are talking about, sorry
10:04:00 <zid> are you aware of the number line
10:05:00 <zid> or do you have a ruler handy idk
10:05:00 <zid> centimeters or inches, both are fine
10:05:00 <x8dcc> sure
10:05:00 <ddevault> this does not make any sense ;_;
10:05:00 <zid> Okay so imagine interrupt 0 is at 0cm, interrupt 1 is at 1cm, etc etc
10:06:00 <zid> divide by zero exception is interrupt 0, interrupt 1 is debug exception, etc
10:06:00 <x8dcc> yeah
10:06:00 <zid> It's best to sliiide those IRQs over, so that they don't overlap
10:06:00 <zid> to say, 32cm onwards
10:06:00 <x8dcc> why? overlap with what?
10:06:00 <zid> >divide by zero exception is interrupt 0, interrupt 1 is debug exception, etc
10:06:00 <ddevault> exceptions
10:06:00 <ddevault> the CPU generates interrupts on its own when invalid scenarios arise, such as divide by zero
10:07:00 <ddevault> by default they overlap with IRQs, which are nominal cases
10:07:00 <ddevault> you don't want to mix nominal and exceptional, so you remap the IRQs
10:07:00 <x8dcc> oh, I didn't know that
10:07:00 <zid> so you just weren't aware of cpu exceptions? huh
10:07:00 <x8dcc> I didn't knew they overlapped
10:07:00 <zid> Well I explained it, twice
10:07:00 <zid> that you should make it so they shouldn't
10:07:00 <ddevault> your metaphor was awful zid
10:07:00 <zid> by moving the IRQs to 32
10:07:00 <zid> it wasn't a metaphor?
10:07:00 <ddevault> number line/ruler metaphor
10:08:00 <zid> It wasn't a metaphor
10:08:00 <x8dcc> I understand it now anyway
10:08:00 <ddevault> I am fairly certain that the interrupt handlers are not literally 1cm apart
10:08:00 <ddevault> if only because my CPU is narrower than 32cm
10:08:00 <zid> a nm ruler is too hard to see so I scaled it up
10:08:00 <ddevault> ah, naturally
10:10:00 * FireFly ponders the distance to system memory in this analogy
10:10:00 <x8dcc> well I have to go now, but I will mess with this a bit and probably ask more stuff when I get back ^^'
10:10:00 <FireFly> take care!
10:10:00 <x8dcc> thank you both anyway :D
10:12:00 <ddevault> tfw thought I was done with bullshit problems
10:12:00 <ddevault> reminds me of when my x86_64 raised a machine check
10:12:00 <ddevault> always nice when you ask the manual what went wrong and the official answer is "I dunno lol"
10:14:00 <zid> how the fuck did you get an ME
10:15:00 <ddevault> writing to invalid physical memory addresses, at the time
10:15:00 <zid> oh that works
10:15:00 <zid> maybe? idk
10:23:00 <ddevault> bah
10:23:00 <ddevault> whatever
10:23:00 <ddevault> I can't narrow it down
10:23:00 <ddevault> not consistent enough
10:24:00 <ddevault> I want to say it's cache related but I'm not sure
10:25:00 * ddevault pulls up the cache chapter
10:29:00 <ddevault> no, perhaps it's not cache related
10:29:00 <ddevault> disabling the caches entirely in SCTLR_EL1 does not fix the bug
10:35:00 <ddevault> I wonder if my rpi is just overheated, given that it spins the CPU when my test code finishes
10:35:00 * ddevault puts it in the fridge
10:36:00 <ddevault> can you tell I'm grasping at straws here
10:36:00 <zid> I'm going to go out on a limb
10:36:00 <zid> and suggest that maybe your code is inolved
10:37:00 <epony> remember when I told you about waste heat being a major problem in SoCs
10:37:00 <ddevault> well
10:37:00 <epony> glue a radiator to it, it would help the convection cooling
10:37:00 <epony> (thermal paste or similar)
10:37:00 <ddevault> each build consistently causes an unknown fault at the same location, mov x0, x8, in the userspace syscall entry points
10:38:00 <ddevault> but different builds fail at different times depending on magic, if I add more logging it fails in a different syscall
10:38:00 <zid> what does qemu do? :P
10:38:00 <ddevault> qemu works fine -_-
10:38:00 <zid> what does linux do on the pi?
10:38:00 <ddevault> I don't even know where to start looking to answer that question
10:39:00 <zid> run linux on it?
10:39:00 <ddevault> well I mean linux runs fine
10:39:00 <epony> sounds like a halt and catch fire
10:39:00 <epony> could be a HW bug?
10:39:00 <zid> yea you did it, naughty boy
10:39:00 <ddevault> I don't know
10:39:00 <zid> maybe some timer or irq or somthing happens cus it's a real device
10:39:00 <epony> aks others to validate / reproduce
10:39:00 <ddevault> the manual suggests a number of possible causes related to this exception
10:39:00 <ddevault> none of them seem likely
10:40:00 <ddevault> the closest one mentions writing to SP_EL0 when SPsel = 0, but SPsel = 1
10:40:00 <ddevault> yeah, if anyone has a raspberry pi I can share a test case
10:40:00 <ddevault> raspberry pi 4, to be specific
10:44:00 <ddevault> fridge strat did not work :(
10:45:00 <ddevault> j`ey: would appreciate being able to pick your brain on this issue, as the resident ARM wizard
10:48:00 <j`ey> just skimmed scrollback.. not sure I have anything to suggest
10:48:00 <ddevault> oh well :/
10:49:00 <epony> ask on the qemu mailing list too
10:49:00 <ddevault> it's not a qemu problem
10:50:00 <epony> then the rpi lists
10:51:00 <ddevault> yeah that may be better
10:51:00 <j`ey> ddevault: have you looked at the unknown reason.. reasons?
10:51:00 <epony> or run some functional testing / benchmarking tooling on it
10:52:00 <ddevault> j`ey: you mean the part of the manual which enumerates possible causes?
10:52:00 <epony> (or a memtest)
10:52:00 <j`ey> yeah ddevault
10:52:00 <ddevault> yeah, I have
10:52:00 <ddevault> none of them seem likely, but I'll read it again
10:52:00 <epony> eMMC can cause problems..
10:53:00 <epony> could be the memory going unstable etc
10:53:00 <ddevault> fwiw I'm not accessing the eMMC
10:53:00 <ddevault> once the bootloader is done it's not touched again
10:53:00 <ddevault> and I would expect "general instability" to not manifest this consistently
10:54:00 <epony> if you're not randomising the layout in memory..
10:54:00 <epony> things end up in the same places
10:54:00 <ddevault> well, true
10:54:00 <ddevault> I could see what happens if I move my stuff around a bit
10:54:00 <epony> so a memory unreliable chip could be causing it
10:54:00 <epony> yep
11:27:00 <ddevault> putting init somewhere else in physical memory does not correct the issue
11:35:00 <epony> so it's a CPU bug hypthesis
11:36:00 <epony> hypertenzis
11:40:00 <ddevault> >This message has been submitted successfully, but it will need to be approved by a moderator before it is publicly viewable. You will be notified when your post has been approved.
11:40:00 <ddevault> -_-
11:40:00 <klange> one sec
11:40:00 <ddevault> rpi forums, not osdev
11:40:00 <klange> oh :(
11:41:00 <klange> you got my hopes up there for a moment
11:41:00 <klange> thought I could actually be useful for once
11:43:00 <klange> i had a lot of "fun" with my rpi400 bringup
11:43:00 <klange> good times
11:44:00 <ddevault> here's the full write-up I (tried to) post on the rpi forums: https://l.sr.ht/a2DF.png
11:44:00 <epony> the next generation of the raspberry pi is going to be called rping
11:52:00 <ddevault> every time I have a stupid idea to rule out I really hope it can't be ruled out
11:52:00 <ddevault> it can always be ruled out
11:54:00 <kaichiuchi> hi
11:59:00 <ddevault> difficult to resist the temptation to burn this device in a pyre and start a farm
12:05:00 <ddevault> oh my god it was the caches
12:05:00 <ddevault> I was invalidating them incorrectly, AGAIN
12:06:00 <ddevault> god the ARM manual sucks
12:08:00 <ddevault> https://git.sr.ht/~sircmpwn/helios/commit/aa5388d2582fb917647d9e5b4f96291cee590267
12:08:00 <bslsk05> git.sr.ht: ~sircmpwn/helios: +aarch64: fix icache/dcache invalidation - sourcehut git
12:11:00 <gog> hi
12:21:00 <ddevault> remaining TODOs: thread local storage, scheduling, fault delivery, and porting & verifying the kernel test suite
12:22:00 <ddevault> then I can start working on the actual slide deck code
12:22:00 <ddevault> whether or not I'll get to use this to give a talk at FOSDEM... odds not great
14:05:00 <epony> so, the mystery soul snatcher has been converted to colon sublimator https://www.youtube.com/watch?v=ArjUUDhntzE
14:05:00 <bslsk05> '"APPLE PRODUCT LAUNCH" — A Bad Lip Reading' by Bad Lip Reading (00:04:16)
14:28:00 <x8dcc> I am back. I managed to add the IDT, but I feel like I messed something up. I just added ~21 ISRs to the IDT for printing the exceptions and panicking
14:28:00 <x8dcc> what's a good way of checking if it's loaded correctly?
14:29:00 <x8dcc> I didn't remap the IRQs yet, by the way
14:46:00 <epony> "there is still some time left for yak shaving with the hairy parts of the kernel splicer for continuation resumption in the on chip system debugger console" --Chewie "Altdawg" Chewbacca
15:00:00 <gog> i'm not wroking
15:00:00 <gog> x8dcc: you will need to re-map the IRQs or mask all of them
15:01:00 <gog> because if say, the timer IRQ fires, it's gonna show up as aaaa double fault i think
15:02:00 <x8dcc> so if they are in the same position they fire both? I see
15:02:00 <gog> yes
15:02:00 <gog> by default the PC bios remaps the first pic to an offset of 8
15:03:00 <gog> so IRQ 0, the timer irq, will vector to 8
15:03:00 <gog> but it's not actually a double fault
15:03:00 <x8dcc> I see
15:03:00 <gog> it's just that your cpu was vectored to it wrongly
15:04:00 <x8dcc> well I tried manually interrupting from assembly to see if the idt was loaded correctly, but it reboots
15:04:00 <gog> that's a triple fault
15:04:00 <x8dcc> its what I thought, but I was not sure why that happened
15:04:00 <gog> faults on looking up ISR, faults on looking up double fault ISR, triple fault is reset
15:05:00 <gog> or rather
15:05:00 <gog> #GP due to missing isr, fault due to missing GP isr, then triple
15:06:00 <gog> or malformatted isr etc
15:06:00 <x8dcc> okay so for example what I did now was add the idt struct, and create the 256-entry idt. then fill ~21 entries with the right type flags, and offets for the isr, and the isr's should just panic with the current exception
15:07:00 <x8dcc> because it compiles, I commited and pushed to a different branch, I can send the link if you want, but I am sure I am missing something (besides the IRQ remapping)
15:11:00 <gog> show me the link pls
15:11:00 <gog> the irq remapping won't affect what you've done with the ISR
15:12:00 <x8dcc> https://github.com/fs-os/fs-os/tree/idt
15:12:00 <bslsk05> github.com: GitHub - fs-os/fs-os at idt
15:12:00 <x8dcc> I want to organize the files and functions a bit, but the idt is filled from src/kernel/idt.c
15:13:00 <x8dcc> and the idt_load function is from src/kernel/misc.asm
15:20:00 <gog> hm nothing jumps out at me
15:20:00 <gog> can you make it hang after load_idt and see what the IDTR says in monitor?
15:20:00 <x8dcc> well that shocked me haha
15:21:00 <x8dcc> hmmm let me try
15:21:00 <gog> i got my IDT code settled some time ago and try not to fuck with it anymore so i may have missed something
15:22:00 <x8dcc> well all those exceptions are added to the idt using flags 0x8E
15:22:00 <x8dcc> thats something that I don't really get, where should I use interrupt gates and trap gates
15:23:00 <gog> don't worry about that right now
15:23:00 <gog> the difference is that interrupt gates will automatically clear EFLAGS.IF
15:23:00 <x8dcc> okay, I just looked at many idts and they were very different
15:23:00 <x8dcc> yeah, one disables interrrupts and then enables them when returning, right?
15:24:00 <gog> https://github.com/adachristine/sophia/blob/main/kc/core/cpu/descriptor.h https://github.com/adachristine/sophia/blob/main/kc/core/cpu/cpu.c#L78
15:24:00 <bslsk05> github.com: sophia/descriptor.h at main · adachristine/sophia · GitHub
15:24:00 <bslsk05> github.com: sophia/cpu.c at main · adachristine/sophia · GitHub
15:24:00 <gog> yeah interrupt gates
15:24:00 <gog> this is for 64 bit but it's basically the same
15:24:00 <x8dcc> yeah
15:25:00 <x8dcc> so what do you exactly wanted to se with the IDTR? the state when the kernel_main runs is different from before
15:26:00 <gog> just that it's the size and address you expect
15:26:00 <gog> presumably somewhre above 1MiB
15:26:00 <gog> and 159 bytes of limit
15:27:00 <x8dcc> the gdt for example is 100050, which looks pretty normal to me
15:27:00 <x8dcc> but the idt is 447c0011 00004060
15:27:00 <gog> that is way off
15:27:00 <gog> well no
15:27:00 <gog> it should be 4095
15:28:00 <x8dcc> well its one of the things that makes me think I'm missing something
15:28:00 <x8dcc> what exactly should be 4095?
15:28:00 <x8dcc> I mean, what does that number represent
15:28:00 <gog> the limit of your idtr
15:29:00 <gog> since you declared it with 256 entries
15:29:00 <gog> and it's 8 bytes
15:29:00 <gog> its limit will be 4095
15:29:00 <gog> 8 bytes per descriptor
15:29:00 <x8dcc> the size of the struct is 8, sizeof(idt_entry)
15:29:00 <x8dcc> I looked that up before with a simple printf
15:30:00 <x8dcc> the limit is set in idt_init as well
15:35:00 <x8dcc> but the first 447c... part should be fine? that also seems off
15:37:00 <gog> no it should be near your gdt
15:37:00 <gog> in the 1MiB area
15:37:00 <gog> 100050, 0x50 1MiB + 80 bytes
15:37:00 <x8dcc> :/
15:38:00 <x8dcc> well at least is a start, I know *what* is wrong
15:39:00 <gog> so basically your lidt instruction is wrong
15:39:00 <gog> but i don't understand why yet
15:39:00 <x8dcc> I will try to debug the stack when calling idt_load later
15:40:00 <x8dcc> I have to leave for a while again... thanks for having a look, gog
15:40:00 <j`ey> ddevault: getting 502 errors on sr.ht
15:40:00 <ddevault> aware
15:40:00 <ddevault> our tech just arrived at the datacenter
15:41:00 <gog> i should really try to do some work
15:41:00 <j`ey> ddevault: I hope he has his hammer
16:14:00 <ddevault> j`ey: back online
16:18:00 <j`ey> ddevault: I see, and congrats on fixing the cacheu issue
16:18:00 <ddevault> thanks!
16:19:00 <ddevault> and on the outage <_<
16:19:00 <ddevault> hardware failure on the main database server
17:08:00 <kaichiuchi> nice.
17:09:00 <kaichiuchi> we bypassed read out protection on our equipment
17:10:00 <kaichiuchi> STM32F* is ridiculous
17:29:00 <geist> ridiculous how? that there are a bazillion of em?
18:32:00 <Bitweasil> Hm. PMSA on ARM, R-series. It's set by the SCRs. This implies the mappings are per-CPU-core, not global, correct?
18:33:00 <Bitweasil> I can't see how it would be any other way.
18:35:00 <geist> Yah almost certainly is per core
18:35:00 <geist> Or more generically, i dont think in pretty much any situation is anything sort of thing like that global, unless it’s a separate peripheral (like GIC, etc(
18:36:00 <Bitweasil> Right.
18:36:00 <Bitweasil> Ok, thanks. Need more coffee or something this morning.
18:39:00 <geist> ddevault: grats! Yeah, just as a suggestion, you really need to be super careful with cache/tlb stuff, since it can show up as Heisenbugs all over the place. Conversely if you see a lot of weird randomness, first instinct should be to suspect cache maintenance
18:39:00 <geist> Less so on x86, but on ARM/riscv/etc it’s a bit more of a thing to worry about
18:39:00 <Bitweasil> It really, really is. :/ The manual says, "Thou Shalt Do Updates This Way," and if Thou Doesn't, well, good luck.
18:39:00 <Bitweasil> Because it's absolutely heisenbugs all the way down.
18:40:00 <Bitweasil> We had a bug in the emulator where a TLB invalidate wasn't working properly in some cases, and it took a couple of us north of a week to run down.
18:40:00 <geist> Also to be clear and a bit pedantic, the DSB after TLB ops is not really a memory barrier as much as a strong device barrier. That’s kinda the difference between DMBs and DSBs. DSBs are stronger than DMBs and synchronize any other outstanding things (like cache flushes)
18:40:00 <Bitweasil> Because the kernel was getting a ton of "impossible" errors.
18:40:00 <geist> Yeah. If there’s one place that’s worth getting some peer review and whatnot its your fundamental cache routines because if you dont have them right you’ll be tearing out your hair forever
18:41:00 <Bitweasil> That's one of those places where inner-shared vs outer-shared matters, right?
18:41:00 <geist> Yeah, though in general outer doesn’t really mean anything, in any reasonable SOC. So usually inner is sufficient when you’re talking about synchronizing things within your OS
18:41:00 <geist> Ie, all cpus and all memory you’re dealing with for your OS image are basically by definition part of the inner domain
18:42:00 <geist> Outer is hypothetically there so you could have some sort of loosely coupled cores somewhere else in the system running some other os and would let you be a little more fine grained about synchronization
18:42:00 <geist> But i think in practice nothing uses it
18:43:00 <geist> But there’s also ‘SY’ domain which covers all of inner/outer
18:43:00 <Bitweasil> Hm, ok. That would explain why I can't seem to find much in the way of definitions for when it matters!
18:43:00 <geist> And i think it’s the default domain if you dont specify any flags on the DMB/DSB instructions
18:43:00 <geist> Yeah,m it’s mentioned somewhere in the arm manual that all cores/memory/etc that a single OS image runs on must be within the same inner domain
18:44:00 <Bitweasil> Ah, ok.
18:44:00 <geist> Doesn’t mean stuff outside of the os image (ie, GPUS, other cpus, etc) cant also be within the same inner domain, however
18:44:00 <geist> And that’s how it’s generally done in most docs
18:44:00 <Bitweasil> So outer might be relevant for something like those "One A core running something, two R cores running something different" hybrid SoCs?
18:44:00 <geist> Yah totally
18:44:00 <Bitweasil> Ok, that's useful. Thanks!
18:44:00 <geist> That’s precisely what the idea is, but i think in practice nothing really implements that
18:46:00 <geist> So as a result the rules are basically ‘use inner domain for synchronizing between your cpus and stuff on the cpus (TLB/caches)’ and ‘use sy domain for synching with hardware’
18:47:00 <geist> Ie, a DMB ISH is good as a memory barrier to make sure all other cpus in your kernel ‘see’ what you just did
18:47:00 <geist> A DMB SY would be overkill
18:48:00 <geist> But a cache flush + DSB SY would ensure that whatever you wrote makes it out to memory
18:51:00 <geist> Also note that individual cores are allowed to elevate a more fine grained barrier to something stronger, since strictly speaking larger domains encompass the smaller one
18:51:00 <geist> Ie SY > outer > inner. And in fact IIRC the a53 manual says ‘actually everything is SY’ or something like that, but dont quote me on it
18:52:00 <geist> This is another example of the ARM manual giving everyone (hardware and software) the rules, but not telling you what to do, you’re supposed to interpret the rules
18:52:00 <geist> Definitely more cognitive load
19:23:00 <zid> oh x8dcc came back while I was ansleep
19:24:00 <zid> [15:27] <x8dcc> but the idt is 447c0011 00004060
19:24:00 <zid> leading zeros suggests *hex* for the length too
19:24:00 <zid> so it's set to some weird value above 16 thousand :P
19:26:00 <zid> ah you fucked up the asm
19:32:00 <x8dcc> hey
19:32:00 <zid> you accidentally the pointer
19:36:00 <heat> man I sure hate it when i accidentally the pointer
19:36:00 <x8dcc> I was having a look now, the idt descriptor address is fine when calling the assembly function
19:36:00 <zid> yes
19:36:00 <zid> it's the asm that's broken
19:36:00 <x8dcc> I moved the idt_init call (not idt_load) to another part of the code and the address in "info registers" changed like a lot
19:37:00 <x8dcc> now its 00000011 0004060
19:37:00 <zid> yes, it's the asm that's broken
19:37:00 <x8dcc> what's broken? I removed the pushes and the mov's and now its just lidt [esp + 4]
19:37:00 <zid> pushing it to the stack makes it a void **, [esp+8] dereferences it once to get a void *
19:37:00 <zid> so you loaded the actual value of the shit on your stack as the IDTR
19:38:00 <x8dcc> huh? a void* as arg is a void**?
19:38:00 <zid> no, a void * you take the address of is a void **
19:38:00 <x8dcc> ah wait
19:38:00 <x8dcc> I understand
19:38:00 <zid> you mean mov eax, [esp+8]; lidt [eax]
19:38:00 <zid> meant*
19:38:00 <x8dcc> okay, let me try that
19:38:00 <heat> note: __asm__ __volatile__("lidt %0" :: "m"(idtr));
19:38:00 <zid> or just that
19:38:00 <x8dcc> believe it or not, I thought about it
19:39:00 <heat> ok
19:39:00 <x8dcc> but once the stack looked fine, I thought it was something else
19:39:00 <heat> then do it
19:39:00 <zid> I mean.. it's best and easiest to do that
19:40:00 <heat> the wiki has simultaneously a strong phobia of inline assembly and a strong taste for hacky inline asm
19:40:00 <x8dcc> I personally don't like it a lot
19:40:00 <zid> It's the only way to get it optimizing
19:41:00 <zid> https://gcc.gnu.org/onlinedocs/gcc/Using-Assembly-Language-with-C.html#Using-Assembly-Language-with-C You just need to read this and it makes a lot more sense
19:41:00 <bslsk05> gcc.gnu.org: Using Assembly Language with C (Using the GNU Compiler Collection (GCC))
19:41:00 <heat> calling an actual asm function that simply loads an IDT is silly
19:41:00 <x8dcc> probably
19:41:00 <zid> at least on 64bit it's just 'lidt [rdi]; ret'
19:42:00 <heat> sorry? you mean lidt (%rdi); ret
19:42:00 <zid> I do not.
19:42:00 <heat> also using ret directly is unsafe
19:42:00 <zid> shouldn't that be lidtH where H is 'idk, like. 48 bits?'
19:42:00 <heat> create a macro for RET
19:42:00 <x8dcc> 00114080 000007ff... thank you
19:43:00 <heat> where you can then safely mitigate exploits
19:43:00 <zid> ta-da
19:43:00 <x8dcc> heat what macro?
19:43:00 <zid> ENDBR
19:43:00 <zid> RET
19:43:00 <zid> wait we need to REP RET
19:43:00 <heat> https://github.com/heatd/Onyx/blob/master/kernel/include/onyx/x86/asm.h
19:43:00 <bslsk05> github.com: Onyx/asm.h at master · heatd/Onyx · GitHub
19:43:00 <zid> in case this is an athlon 64
19:43:00 <heat> jmp __x86_return_thunk!!!11!111
19:44:00 <heat> also need an int3 for sls mitigation
19:44:00 <x8dcc> huh, never heard of that
19:44:00 <zid> Imagine thinking your OS is secure enough to care about security
19:47:00 <x8dcc> and software interrupts actually work!
19:47:00 <zid> pointers too stronk for x8dcc
19:48:00 <zid> lidt is kinda weird though ngl
19:48:00 <zid> it's not often you're dealing with weird 48bit structs instead of dwords
19:48:00 <x8dcc> now I think I only need to remap the IRQs, although I will have to search a bit more
19:48:00 <zid> I mean I gave you exact code that does it
19:48:00 <x8dcc> I know
19:48:00 <x8dcc> but I want to know what it means :(
19:48:00 <zid> and it's just copy pasted from the PIC docs
19:48:00 <zid> 8259
19:48:00 <x8dcc> okay
19:49:00 <zid> http://www.brokenthorn.com/Resources/OSDevPic.html
19:49:00 <bslsk05> www.brokenthorn.com: Operating Systems Development Series
19:49:00 <x8dcc> thank you for the help god bless you all
19:51:00 <zid> x8dcc: please don't do that
19:51:00 <x8dcc> huh?
19:52:00 <zid> the thing you did 3 seconds before I asked you not to
19:52:00 <x8dcc> ...uhm okay
19:53:00 <zid> I think you mean "oh, sorry"
19:53:00 <x8dcc> I don't understand what I did
19:54:00 * zid adds short-term memory loss to the symptoms list
19:54:00 <zid> You sent ma private message about channel stuff
19:54:00 <x8dcc> I can't do that?
19:54:00 <zid> You 100% did it.
19:54:00 <x8dcc> I just said thank you
19:54:00 <zid> Yes, do it *on the channel*
19:55:00 <zid> Some people are in a) hundreds of channels and b) It makes my client flash and I have to go find the new window
19:55:00 <GeDaMo> It's impolite to send private messages without asking in the channel first
19:55:00 <zid> and it's pointless
19:55:00 <x8dcc> I didn't know that, sorry
19:55:00 <GeDaMo> I have private messages turned off anyway :P
19:56:00 <zid> I leave them on so that people can bitch about other people in private when I argue with them and they don't wanna get involved :D
19:56:00 <zid> get a lot of privmsgs that are like "lol, that guy's a fucking idiot, tell him his mum smells next"
19:57:00 <x8dcc> didn't know it was like that
19:58:00 <zid> It's just kinda pointless to drag me out of the channel to look at messages that were for the channel
19:59:00 <x8dcc> I did it for not spamming the chat, but looks like it had the opposite effect
20:14:00 <Bitweasil> Yup. Welcome to IRC.
21:04:00 <epony> that message too 27 years to arrive ;-)
21:04:00 <epony> took too long
21:48:00 <heat> zid, for the record my mum doesn't smell
21:49:00 <zid> heat: mine does
21:49:00 <heat> poortugal no nose
21:49:00 * moon-child smells zid's mum
21:49:00 <heat> 2 expensive
21:49:00 <zid> moon-child: You need to pay for that
21:50:00 <zid> flat rate of €20 for fetish activity
21:50:00 <x8dcc> portugal is great
21:50:00 <x8dcc> and I won't justify my statement
21:50:00 <zid> protugal stronk liek albania
21:50:00 <heat> like polan
21:50:00 <zid> polan is much stronker
21:50:00 <heat> polan can into space, portu can into polan
21:51:00 <heat> actually, portu can into spain, germany can into france and polan
21:51:00 <geist> spay an fran
21:52:00 <heat> spay sounds either dirty or the new name for google pay
21:53:00 <Ermine> allemagne
21:53:00 <geist> spai? i dunno, i thought the Dolan style country meme was funny
21:53:00 <x8dcc> spain should invade france
21:53:00 <Ermine> Let's deal with ohio first
21:56:00 <Bitweasil> Yeah! Invade the potato farmers!
21:56:00 <Bitweasil> Or corn, or... uh... whatever it is that state does!
21:57:00 <Bitweasil> (the confusion of people between Idaho, Iowa, and Ohio being legendary if you've lived in one or more of those states)
21:57:00 <jimbzy> Hah
21:57:00 <x8dcc> all of them sound funny
22:04:00 <geist> ohai
22:04:00 <heat> geist: computer
22:05:00 <geist> yay comput
22:53:00 <heat> https://www.reddit.com/r/linuxmasterrace/comments/1097uxy/heh_heh_heh/
22:53:00 <bslsk05> www.reddit.com: heh heh heh!!! : linuxmasterrace
22:54:00 <heat> this is either a great circlejerk meme or a typical r/linux meme
22:54:00 <heat> i'm not sure which
22:55:00 * kof123 sees lambda salamander on SICP cover FIRE FIRE
23:10:00 <zid> But unstable is cool, I got to report a bug in qemu :(
23:30:00 * sortie continued work on his dhclient(8)