sebonirc has quit [Remote host closed the connection]
sebonirc has joined #osdev
MiningMarsh has joined #osdev
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #osdev
dude12312414 has quit [Remote host closed the connection]
PSedlacek has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
<gog>
intereting
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
<geist>
yah interesting read. now i really know what tile based gpus actually means
<gog>
it seems like buffer handling is a weird thing to delegate to firmware
gog has quit [Ping timeout: 255 seconds]
<mrvn>
sounds more like it's the driver dealing with it.
<mrvn>
Like "snprintf" the firmware tells you when the buffer is insufficient. Then instead of rendering the frame again with a larger buffer the driver says: Hey, nobody will notice a boken frame. Lets ignore it and fix it for the next frame."
<mrvn>
rendering a frame twice would probably mean the frame gets skipped altogether as you exceed the rendering time. Which would be a much bigger error in the average casse with just a bunch of triangles missing. It's only the step from 0 to 10000000 triangles that makes it obvious.
<Mutabah>
No quite from my reading?
<Mutabah>
It overflows, then restarts rendering and merges the results together
<Mutabah>
So, modulo shader bugs, you get a complete frame (just degraded performance for a bit until the driver/firmware expands buffers)
Matt|home has joined #osdev
<mrvn>
Mutabah: thats the part where it renders the image in chunks.
<mrvn>
I'm talking just about the expanding part
<Mutabah>
Sure.
<mrvn>
Wasn't the problem that the "broken" driver didn't do that render+merge loop?
<Mutabah>
I think it just didn't upload the right shader to prepare for the subsequent render attempts
<Mutabah>
So the tiles that had to render twice were cleared for the subsequent attempts instead of being initialised with the results of the last pass
PSedlacek has quit [Quit: Connection closed for inactivity]
vdamewood has joined #osdev
Burgundy has joined #osdev
X-Scale` has joined #osdev
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
Ali_A has quit [Quit: Connection closed]
<zid>
My faulting instruction causing a page fault is
<zid>
imul r12, r12, 0x77747af5
<zid>
*wat*
<zid>
CR2 is.. 0
<Mutabah>
Something's strange there.
<Mutabah>
Sure it's a PF and not another fault?
<geist>
yep. absolutely
<Mutabah>
Or an interrupt
<geist>
or is that the right instruction?
<Mutabah>
To qemu's debug trace!
<zid>
That's what I used
<zid>
It's an instruction trace, cpu goes from 205fd2 to fff...2032
<mrvn>
or another fault that causes a pf?
<zid>
imul to 'push r11' in my pf handler
<Mutabah>
Qemu's interrupt trace?
<Mutabah>
Or are you looking at another one?
<zid>
log cpu
<mrvn>
Is this 32bit?
<zid>
qemu set to -singlestep, gdb attached with break int_pf then c
<Mutabah>
`-d int` is a nice for tracing errors
<zid>
it doesn't print both, unfortunately
<zid>
but the traces I was getting without -singlestep (so -d int worked) was showing RIP=0
<mrvn>
That matches you seeing "CR2 is.. 0"
<zid>
things that also might explain it.. that 205xxx page having permission issues
<mrvn>
What fault caused RIP=0?
sonny has left #osdev [#osdev]
<zid>
but the instruction before 205fd2 is.. 205fc8
<zid>
which doesn't fault
<mrvn>
and the one after?
<zid>
I also tested for silent register corruption via IRQs, loaded every reg with a constant and span it in a while(1); nothing happens, all regs stay fine
<geist>
the heavy hammer is -d exec,cpu,int i think
<geist>
it should dump the state of the registers at interrupt itme
<mrvn>
What is the instruction after imul and what did the trace show before RIP=0?
<geist>
actually might not need exec and cpu in that case
<zid>
-d int dumps the regs anyway
<geist>
i dunno what log cpu does precisely
<zid>
shows the register contents every time
<zid>
stepi -> qemu spits out every single register
the_lanetly_052_ has joined #osdev
<zid>
I'm starting to think qemu is wrong, which is silly
<geist>
could be you'renot running the instruction you think you are
<geist>
usually sets off warning signs when you PF on instructions that dont seem to touch memory
<zid>
the imul is the result of x /1i in qemu
<zid>
it aligns with objdump -d
<geist>
what about the instructions around it?
<geist>
would they have trapped with that address?
<zid>
mov rax, imul, cdq
<zid>
mov rax, r12, so not from memory
<geist>
yah so that's really really odd
<zid>
Just did another session, single stepped through that area fine
<zid>
so it isn't the only time this codepath is hit, this is frame 0, it died on frame 352 before
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Mutabah>
Run with just `-d int` and use an external disassembler
Burgundy has quit [Ping timeout: 246 seconds]
<zid>
like objdump -d?
<Mutabah>
That'll tell you exactly what instruction caused the interrupt, and what vector, and if it's chaining
<Mutabah>
Yep
<zid>
If I run it without -singlestep it faults at rip=0
<zid>
most of the time at least
<geist>
theory: you have some sort of memory corruption of your text segment, and -singlestep changes the granularity at which it decodes and runs instructions
<zid>
I've lost a window somewhere that's pinging the VM..
<zid>
I can see the irq spam in the console
<zid>
okay crashed
<zid>
v=0e, e=0014, cpl=3, ip=23:0, pc=0, cr2:0
<mrvn>
is your .text mapped read-only?
<geist>
are you using a bus mastering ethernet device?
<zid>
200000-20a000 a000 ur-
<geist>
possible you're dmaing over text?
<zid>
ooh DMA
<zid>
I had not infact considered DMA
<zid>
DMA won't trip W^X or anything right?
<mrvn>
only with iommu
<mrvn>
without it's plain phyiscal memory
FatAlbert has joined #osdev
<geist>
yah, and how exactly qemu emulates dma trashing text i dunno
<zid>
Would need an iommu for that
<geist>
it may or may not cause it to instantly decode instructions differently, or may (probably) wait until the next trace point
<geist>
so singlestep vs non would have different behavior there
<mrvn>
the dynamic translations probably act similar to an icache
<geist>
so if you wrote 0s to it, it'd for example start decoding it as the canonical x86 0 instruction
<geist>
whichi s something dumb like `mov eax, 0(eax)` or some shit like that
<zid>
same crash without the e1000 connected
<mrvn>
zid: isn't there an interrupt before "v=0e, e=0014, cpl=3, ip=23:0, pc=0, cr2:0"?
<geist>
what about without even initializing the e1000?
<zid>
It's not connected to the machine
<geist>
got it
<zid>
It'd struggle to do DMA from the source repository only
<zid>
instead of while it's emulating a device
<zid>
It switched it to some 8086:10d3 at least, which I don't have an if() for, only 100E
<geist>
usually i'd thing a bug would be for example a double allocate of the pages behind the text seghment when setting up the TX/RX queue n the driver
<FatAlbert>
the books are catalog fro mmots recommended eto least ?
<FatAlbert>
from most
<zid>
Yea that sounds good
<zid>
I mean, bad for me, but it's a very good idea
<zid>
that I reused a physical address somehow, combined with qemu not showing the corrupt memory when in singlestep
<geist>
i've personally made that mistake before. forgetting to account for text segment pages when setting up the pmm
<geist>
and then working fine for a whiel until something double allocates the kernel pages
<zid>
This code is old and was working fine before, is the problem
<geist>
yah but those kinda bugs can hang around for a long time
<zid>
I'm not sure I even remember how any of this memory code works anymore :P
<zid>
but I do notice I have some memory marked user that totally shouldn't be
<mrvn>
I had a bug once that only triggered when using the last page of memory because that was double used.
<zid>
info tlb is sadly useless for me, I touch basically every 4k page at boot and it's so long it's taller than my "Infinite scrollback" option on my terminal >_<
<mrvn>
zid: I always whish for that to display contiguos ranges compact.
<zid>
oh duh, the machine boots fine with 32M of ram, let's just do that
<zid>
user text is mapped to 0x454000 physical, and appears precisely twice, once there, and once again in kernel space at.. fffff...454000 which is an identity offset
<zid>
weird my X flag got knocked off on the user binary at some point
<Andrew>
Bochs :)
<zid>
oh, I think info tlb is just inverted because it's showing the *nx* bit
<zid>
so that was a lovely goose which was wild
<geist>
yah lots of times it's a goose chase, but not bad to do every once in a while
<geist>
causes you to reevaulate or refresh your memory on stuff you hadn't thought about in a while
<zid>
I mean, it would be nice, if I had fixed it
<zid>
but I am literally less close to a solution the more I look at it because I've ruled more things out
<mrvn>
“When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.” ~ Arthur Conan Doyle, The Case-Book of Sherlock Holmes
<mrvn>
cosmic rays?
Starfoxxes has quit [Ping timeout: 240 seconds]
Starfoxxes has joined #osdev
Starfoxxes has quit [Ping timeout: 255 seconds]
Starfoxxes has joined #osdev
terminalpusher has joined #osdev
terminalpusher has quit [Remote host closed the connection]
Starfoxxes has quit [Ping timeout: 260 seconds]
Starfoxxes has joined #osdev
Starfoxxes has quit [Ping timeout: 258 seconds]
Starfoxxes has joined #osdev
Starfoxxes has quit [Ping timeout: 255 seconds]
Starfoxxes has joined #osdev
muffin has joined #osdev
Starfoxxes has quit [Ping timeout: 244 seconds]
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
<Andrew>
"The system is a thing; "programs" are patches to the thing
<FatAlbert>
where's GeDaMo ?
<FatAlbert>
seems to me like you guys need a bit of GeDaMo
Burgundy has joined #osdev
<FatAlbert>
:-)
<FatAlbert>
you guys can proceed :D
<FatAlbert>
don't let me interrupt
<FatAlbert>
ok im leaving ..
FatAlbert has left #osdev [i have such a good friends in #osdev]
FatAlbert has joined #osdev
Likorn has joined #osdev
toluene has quit [Ping timeout: 255 seconds]
toluene has joined #osdev
FatAlbert has left #osdev [WeeChat 3.5]
GeDaMo has joined #osdev
immibis has joined #osdev
pretty_dumm_guy has joined #osdev
Vercas has quit [Quit: Ping timeout (120 seconds)]
Vercas has joined #osdev
muffin has quit [Quit: WeeChat 3.5]
pwng has joined #osdev
<stephe>
i have a dumb question about setting up the page tables when entering long mode described here https://wiki.osdev.org/Setting_Up_Long_Mode : it says that each page table entry in long mode is 8 bytes long, but the asm seems to be doing mov dword, wont that just store in the first 4 bytes?
<bslsk05>
wiki.osdev.org: Setting Up Long Mode - OSDev Wiki
arch-angel has joined #osdev
arch-angel has quit [Ping timeout: 244 seconds]
<pwng>
Hello - for the QEMU virtio-blk device, I am getting one request done, and then I catch the virtio interrupt and, presumably, properly acknowledge the interrupt via both VirtIO INTERRUPT_ACK MMIO reg and the interrupt controller (RISC-V PLIC), I then can get other requests done, but I stop receiving the interrupt after the first request
<pwng>
I can't spot the problem, any ideas what the problem might be? I don't think the virtio-blk initialization or sending the request is causing a problem as the requests are done exactly as I want them, but the interrupts are suppressed for some reason
<pwng>
There's a part of the standard that mentions "used buffer notifications suppression"; I can suppress them by setting the `flags` field in the "used" area of a virtqueue to 1, and I don't set it anywhere, and on time of writing to QUEUE_NOTIFY, it's set to 0.
<pwng>
Ahh yes -- turns out I unintentionally negotiated the VIRTIO_F_EVENT_IDX feature...
<pwng>
The feature bit was only mentioned in the virtq implementation appendix of the standard, and not in the Feature Bits section :D
nj0rd has quit [Ping timeout: 276 seconds]
dennis95 has joined #osdev
pwng has quit [Ping timeout: 252 seconds]
pwng has joined #osdev
arch-angel has joined #osdev
arch-angel has quit [Max SendQ exceeded]
arch-angel has joined #osdev
arch-angel has quit [Remote host closed the connection]
Starfoxxes has joined #osdev
gildasio has quit [Quit: WeeChat 3.5]
nj0rd has joined #osdev
nyah has joined #osdev
gildasio has joined #osdev
Vercas has quit [Quit: Ping timeout (120 seconds)]
Vercas has joined #osdev
immibis has quit [Remote host closed the connection]
<mrvn>
stephe: the upper 4 bytes are always 0
<mrvn>
stephe: "First we will clear the tables"
gog has joined #osdev
<stephe>
mrvn: aha, i was thinking it should be mov qword ... but of course thats not allowed until youre running in long mode?
<mrvn>
yes. And rather than alternate writing 4 byte low and 4 byte high (0) they clear the tables and then just write the low bits.
<mrvn>
notice how the address is incremented by 8
<stephe>
makes sense now, thanks
immibis has joined #osdev
<mrvn>
it's always fun seeing people trying so hard to parallelize their O(n^3) matrix multiply using a 512 core cluster when they could get the same speedup on a single core using Strassen's algorithm or a >1000 times speedup by using Alman-Williams and then go on and parallelize that.
<bslsk05>
en.wikipedia.org: Computational complexity of matrix multiplication - Wikipedia
_73 has joined #osdev
<mrvn>
Reminds me on the best algorithm for sorting numbers in parallel: if (N < 1000000) { sort any which way, that's a trivial problem } else { split into sqrt(N) parts and sort them in parallel }
<mrvn>
So with 32bit you do at most one split, with 64bit at most 2 splits.
the_lanetly_052_ has quit [Ping timeout: 244 seconds]
gog has quit [Quit: byee]
gog has joined #osdev
vdamewood has joined #osdev
<_73>
I had a discussion here a few days ago on the idea of kernel threads executing a syscall being given a higher priority than user space threads. I was told that this would be a problem because simply a call to getchar() would DOS the system. However, is this still the case if the kernel uses a turnstile data structure to manage blocked threads? In the getchar() case the syscalling thread would be inserted into the turnstile as waiting
<_73>
for input from STDIN, and its high priority would be irrelevant because it would have to just sleep until STDIN got input. Is this correct or incorrect?
<mrvn>
obviously it assumes it doesn't block
<_73>
I don't know what you mean.
<mrvn>
Instead of getchar you can call read on a non-blocking socket. Or any other syscall. The point was that the program could just waste time in syscalls and since it gets priority that would block any real work getting done.
<_73>
So in the getchar() it would be ok for the syscalling thread to have a higher priority?
<mrvn>
Anything that unconditionally gives priority will be used as a DoS eventually.
vinleod has joined #osdev
<mrvn>
_73: no. You could just make 2 processes connected by pipe that getchar() / putchar()
<_73>
Oh wow I see the problem there.
<_73>
Ok I understand now
vdamewood has quit [Killed (osmium.libera.chat (Nickname regained by services))]
vinleod is now known as vdamewood
<mrvn>
In older unixes programs that recieved input fropm stdin where given priority. So users waiting for their programs to finish would hit "space" every few seconds so their program would run faster.
jjuran has quit [Ping timeout: 276 seconds]
jjuran has joined #osdev
<kingoffrance>
that...makes me think of at least win9x or so, does active window get priority
<kingoffrance>
"at least" later there was some setting favor "background" or "active" things IIRC
<sbalmos>
gave rise to the server OSs. You could still change it in the Computer Advanced Properties IIRC. It was a radio button switch to favor interactive desktop apps vs server processes
<kingoffrance>
hmm, i guess one could simulate it too, with renice and ionice or something -- for X, screen, whatever. :D
<mrvn>
You have to consider 2 fundamental states for processes: idle or burning CPU. It everyhing is idle then whenever some process wakes up you just run it. If everything bruns CPU you want to give every process the same fraction of time to run to be fair. (subject to manual priorities like not having sound/video stutter).
<mrvn>
The only interesting case is if you have a mix.
<mrvn>
In many systems you have a metric called "load" being the number of processes not blocked waiting for something, the number of awake processes. My aim in the scheduler is to minimize that load by running the process likely to go to sleep the quickest.
<mrvn>
My simplistic heuristic for that is: Does the process being woken up have time left in it's time slice or slept longer than 1 loop of the round-robin scheduler?
<kingoffrance>
"running the process likely to go to sleep the quickest." makes sense, for permanent sleep (end) too :)
<mrvn>
Hard to predict anything for processes or threads that run less than a timeslice.
<kingoffrance>
agree, just had similar thoughts if a specialized case (real time) you knew
<mrvn>
With `fork()` there is the assumption that likely the child will `exec()` and free all the COW stuff. So it's run first generally.
<mrvn>
If a process keeps starting threads that quickly quit you can maybe record that in the processe. Keep track of avg. thread lifetime.
<kingoffrance>
yeah, as cool as it sounds, there is surely a sweet spot of "when is this overhead worth it?"
<mrvn>
All stuff you should measure first to see what the actual usage pattern is on your OS before you think of schemes to optimize something that might not be there in the end.
<kingoffrance>
^^^
<mrvn>
Example: Linux has to huge and complex `O(1)` fair scheduler that decides what to run next. I have a round-robin scheduler that just runs "task->next". When I switch to e.g. the keyboard driver the process goes back to sleep before linux has even made up it's mind what process to run next.
ripmalware has quit [Quit: Leaving]
<mrvn>
sometimes less is more.
archenoth has joined #osdev
pwng has quit [Quit: Client closed]
Ali_A has joined #osdev
srjek has quit [Ping timeout: 255 seconds]
mahmutov has joined #osdev
dennis95 has quit [Quit: Leaving]
gorgonical has quit [Quit: Client closed]
gildasio has quit [Quit: WeeChat 3.5]
terminalpusher has joined #osdev
gog has quit [Ping timeout: 255 seconds]
Likorn_ has joined #osdev
<geist>
yah i find it hard to optimize that stuff until you have actual real load
Likorn has quit [Ping timeout: 272 seconds]
terminalpusher has quit [Remote host closed the connection]
<zid>
I have a load for you, mov rax, [rsi]
<zid>
Keep it, I have a bunch
mykernel has joined #osdev
ripmalware has joined #osdev
Ali_A has quit [Quit: Connection closed]
wootehfoot has joined #osdev
mykernel has quit [Quit: leaving]
<mrvn>
zid: but that's a virtual load
srjek has joined #osdev
gxt has quit [Ping timeout: 240 seconds]
gxt has joined #osdev
wootehfoot has quit [Ping timeout: 276 seconds]
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
auronandace has joined #osdev
wootehfoot has joined #osdev
wootehfoot has quit [Quit: Leaving]
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
Vercas has quit [Quit: buh bye]
nyah has quit [Quit: leaving]
toluene has quit [Ping timeout: 272 seconds]
terminalpusher has joined #osdev
toluene has joined #osdev
terminalpusher has quit [Remote host closed the connection]
radens has quit [Quit: Connection closed for inactivity]