<geist>
huh finally got around to trying to read the 68040 mmu docs
<geist>
it's kinda interesting. standard 3 level page table (with 4 and 8k stuff) but the funny thing is the last level can also have an entry that points to another entry
<geist>
ie, instead of a PTE, it's a 30 bit pointer (4 byte aligned) to somewhere else
<mrvn>
having what meaning?
<geist>
basically you can point multiple PTEs at a shared PTE
<kazinsal>
ooh. neat.
<mrvn>
So it's a full PTE you point to with all the bits and not a 32bit pointer?
<geist>
well 30 bits (bit 0 and 1 are used to signify that it's an indirect pointer)
<geist>
but yeah, kinda weird
<geist>
you could do a really slick shared memory system with that. would only have to update a single set of page tables to update mappings in all aspaces
<mrvn>
I mean the thing you point to.
<Mutabah>
Oh, I get it. Neat
<geist>
mrvn: can you rephrase the question?
<mrvn>
The 2 bit in the original PTE don't leave much space to flag R/W/X, kernel/user, present/not present, ...
<Mutabah>
An entry in the lowest-level table can be indirect (pointing to another entry)
<geist>
right. it's that the entry is isntead of a final PTE a pointer to another one
<geist>
i think it says it can't infinitely indirect of course
<geist>
and no in the next paragraph it says it cant point to another indirect entry, or it'll treat it as invalid
<mrvn>
But it's nice. You can make the page table use indirection into your VM structs and then you can change them without having to page table walk or care.
<geist>
yep
<geist>
it doesn't care what it points to, so it can be an array hanging off your shared memory object or something (though the pointers are physical)
<geist>
also kinda unsurprising, the 68030 MMU is actually *more* complicated and more flexible
<geist>
lets you support up to 5 levels of page table by specifying the radix essentially
<geist>
040 simplified it and only lets you do 3 levels + 4K/8K pages, though 8K pages doenst effect the inner page tables, just ends up with half as many at the final level
<mrvn>
how about 060?
<geist>
dunno
<geist>
at quick glance looks to be basically identical to 040
<geist>
anwyay, looks pretty simple. also has a cute set of 4 direct translations on large power of 2 (16MB+) so that's nice for mapping in large blocks of ram or whatnot
<mrvn>
I really should see if my Amiga still works and port my kernel to it. It's sad to have this lost tech rotting away.
Burgundy has joined #osdev
<geist>
that's my role here. to trigger folks with old devices so they'll do retro it
Brnocrist has quit [Ping timeout: 246 seconds]
MiningMa- has joined #osdev
gamozo has quit [Ping timeout: 246 seconds]
nur has quit [Ping timeout: 246 seconds]
MiningMarsh has quit [Ping timeout: 246 seconds]
Terlisimo has quit [Ping timeout: 246 seconds]
lanodan has quit [Ping timeout: 246 seconds]
Celelibi has quit [Ping timeout: 246 seconds]
MiningMa- is now known as MiningMarsh
Brnocrist has joined #osdev
gamozo has joined #osdev
Terlisimo has joined #osdev
lanodan has joined #osdev
Celelibi has joined #osdev
<kazinsal>
geist will not be satisfied until every channel regular owns a vax
<geist>
speaking of....
* geist
looks expectedly
<mrvn>
sorry, only m68k, ppc, alpha, mips, arm, x86, x86_64 here
<kazinsal>
I gotta figure out what I want to do with mine
<mrvn>
I do need a monitor cable for an Indy though.
<kazinsal>
I should try to set up a simh config to simulate it and start doing a bit of hackery on it
<kazinsal>
but I also have this horrible idea of hosting a dial-up BBS on it...
<mrvn>
Do dial-up modems even work well anymore with modern telephones?
<kazinsal>
dial-up yes, faxes sometimes
<mrvn>
faxes should work better, lower BAUD
<kazinsal>
you would think, but faxes are the devil
<kazinsal>
fax machines really do not like VOIP
<geist>
i did see someone doing some retro stuff online with a dialup simulator
<mrvn>
can't see a 56k modem working to actually get 56k
<geist>
kinda a neat looking box, basically emulates the entire dialup networking stuff
<geist>
in the sense that it does the tone dialing, he still provided two modems on either end
<kazinsal>
we used to have this old callmanager book from the late 90s at work that had a whole chapter about faxes over VOIP
<mrvn>
geist: what does that involve? 2 relays to make the dial-tone and connect signal should be enough.
<kazinsal>
because faxes just hate VOIP links
<geist>
mrvn: dunno, this actually emulates the whole dial tone + accepting dialing to something and routing it through
<mrvn>
geist: if you need more than point-to-point with actual numbers it gets complex.
<geist>
but yeah i thnk you can generally just run two modems into each other, i think
<mrvn>
you would need something huge to emulate that, like a ATTiny. :)
<geist>
kinda curious now if someone has tried to just emulate the whole thing with a sound card
<geist>
just software implement a whole modem on the dialup end
<mrvn>
geist: most (all?) builtin modems are sound cards.
<geist>
sure, i mean it's been done. i more mean has someone recently just brute forced it with some open source software
<mrvn>
Thing is the good and high speed modems use multiple BAUD rates in parallel. Might need multiple instances of software defined radio.
the_lanetly_052_ has quit [Ping timeout: 248 seconds]
rpnx-phone has quit [Remote host closed the connection]
_73 has quit [Remote host closed the connection]
the_lanetly_052 has quit [Ping timeout: 240 seconds]
Ram-Z has joined #osdev
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
_73 has joined #osdev
Burgundy has joined #osdev
Vercas has joined #osdev
mahmutov has joined #osdev
gog has joined #osdev
blockhead has joined #osdev
<stephe>
do you guys have an IDT set up all the way from real mode -> protected mode -> long mode, or do you just set one up in long mode?
<mrvn>
yes
<bauen1>
the classical answer to any or question
<bauen1>
stephe: iirc grub multiboot1/multiboot2 throws you into protected mode, so i just setup my IDT there (never went to long mode with my kernel), apart from CPU Exceptions if you mess up you're not expecting any interrupts anyway
<mrvn>
For me both branches are even true at the same time.
<stephe>
hrmmm
<stephe>
im gonna have to meditate on this one
<mrvn>
FYI you can go from real mode to long mode in one step too
<bslsk05>
en.wikipedia.org: Guru Meditation - Wikipedia
gorgonical has joined #osdev
gorgonical has quit [Client Quit]
gorgonical has joined #osdev
ThinkT510 has quit [Quit: WeeChat 3.5]
ThinkT510 has joined #osdev
gog has quit [Ping timeout: 252 seconds]
the_lanetly_052 has joined #osdev
srjek has joined #osdev
<mrvn>
geist: ever tried -static-pie with gcc?
<geist>
I have not
<mrvn>
"Produce a static position independent executable on targets that support it. A static position independent executable is similar to a static executable, but can be loaded at any address without a dynamic linker." Sounds like it will put it's own relocation code in _start for you.
<geist>
Ah interesting
<zid>
did we magically think of how cr2=0 rip=0 is possible yet? :P
<mrvn>
zid: still thinking it's a double fault
<mrvn>
Your IDT is broken so the first fault goes to rip=0 and faults again
tds5 has joined #osdev
paulbarker_ has joined #osdev
mxshift_ has joined #osdev
sham1_ has joined #osdev
Benjojo_ has joined #osdev
PotatoGim_ has joined #osdev
Arsen_ has joined #osdev
energizer_ has joined #osdev
bleb_ has joined #osdev
<geist>
i'd put my money on observation error
<zid>
what's one of those
<zid>
I mean, in this case
Stary_ has joined #osdev
<zid>
I think qemu is just not reporting the info I'd need here
PotatoGim has quit [Ping timeout: 248 seconds]
paulbarker has quit [Ping timeout: 248 seconds]
mxshift has quit [Ping timeout: 248 seconds]
sham1 has quit [Ping timeout: 248 seconds]
bleb has quit [Ping timeout: 248 seconds]
ephemer0l has quit [Ping timeout: 248 seconds]
energizer has quit [Ping timeout: 248 seconds]
Stary has quit [Ping timeout: 248 seconds]
mrkajetanp has quit [Ping timeout: 248 seconds]
ecs has quit [Ping timeout: 248 seconds]
tds has quit [Ping timeout: 248 seconds]
Benjojo has quit [Ping timeout: 248 seconds]
Arsen has quit [Ping timeout: 248 seconds]
ids1024 has quit [Ping timeout: 248 seconds]
<geist>
correct
paulbarker_ is now known as paulbarker
mxshift_ is now known as mxshift
tds5 is now known as tds
PotatoGim_ is now known as PotatoGim
Benjojo_ is now known as Benjojo
<geist>
as in what you tink you see isn't whats happening
<zid>
movabs rax, 0x1234; jmp rax -> nothing contains the old RIP
<zid>
does the cpu really do that? :/
<geist>
yah i think you're gathering pretty good info for it's not even running code yo think it is
<geist>
seems to be mounting evidence of that
<zid>
does the cpu really do this though?
<geist>
do what?
<zid>
delete the old rip in the decode fault case
Raito_Bezarius has quit [Ping timeout: 250 seconds]
<geist>
not sure i understand what you're asking
<zid>
if you do mov rax, 0x1234; jmp rax
<zid>
from 0xDEADBEEF
<zid>
0xDEADBEEF does not appear to be recoverable
<geist>
that's right
<zid>
That's.. highly annoying, thanks x86
<geist>
it branched to 0x1234, then it faulted
<geist>
thats how all cpus behave
<zid>
I guess you'd need two CR2s
<zid>
wtb CR5 that contains the value of RIP during an instruction fetch pf
<geist>
but i gt what you mean, but it's as far as i know basically universal that if the branch can succeeed, it happens, but then it's the new instruction that explodes at the address
<zid>
you get a much more useful fault out of qemu at least
<zid>
where it reports the rip *of the faulting instruction*
<geist>
right, because it's the same model
<geist>
the mov instruction faults so it fails
<geist>
the jmp didn't fail, the instruction at the target of the jmp did
<zid>
yea it makes sense, but it's the most annoying interpretation of *how* it should work
* geist
nods
<geist>
computers are hard
<zid>
I'd need to go full emulation to catch this then.. bochs time? :P
xenos1984 has quit [Read error: Connection reset by peer]
<zid>
not sure if I even have bochs
<geist>
thought you were doing singlestep and whatnot
<geist>
can't you just see what the instruction was before?
<zid>
yep and it gives an entirely different fault
<mrvn>
zid: what if you do b 1; 1: b 2; 2: b 3; 3: b 4; 4 ... Should it have N CR2s?
<zid>
I get a fault on imul r12
<geist>
then debug that
<zid>
which similarly, makes no fucking sense
<geist>
i'm guessing it's the same thing
pie__ has quit []
<geist>
so debug that
vancz_ has quit []
<zid>
or some other random instruction
<zid>
we tried, and failed
<geist>
as in you have something fucked up meory wise, etc etc
<zid>
neither of us could think of something I hadn't checked
<geist>
so it's all heisenbugs
<zid>
yep
<geist>
right, so rewind before the imul and see where it fails there
<zid>
it decodes as an imul r12 before and after the fault with gdb + qemu's x commands
<geist>
there's bound to be a smoking gun there
vancz has joined #osdev
pie_ has joined #osdev
<zid>
I can't because it's not deterministic enough
<zid>
it faults in random places in singlestep mode
<geist>
so multiple runs fails differently?
<geist>
or if yo modify something it fails differently?
<zid>
as best as I can tell yea, it's hard to get these singlestep crashes logged though because it takes a while to print the 40GB of instructions :P
<mrvn>
zid: maybe whatever was there before faults?
<geist>
does the imul happen to be a target of a branch, or on a particular aligned boundary?
<zid>
and if I use breakpoints to toggle `log cpu` on and off then I've changed all the timings
<zid>
nope, it just ran straight through a mov rax, r12; imul r12, ... section
<geist>
i'm sure you have but i've found that catting the logs through gzip helps immensely
<mrvn>
zid: what's the CS and page permissions?
<geist>
is the imul on a particularly interesting address? like it's the first instruction in a new page
<zid>
nope, checked
<geist>
still, i'd start with that, that's though 'random' a conceptually simpler problem
<geist>
as in it's outright impossible, doesn't involve a branch, etc
<zid>
start with what
<geist>
the imul case + singlestep
<zid>
I have the full singlestep log
<zid>
it runs really normal instructions inside that page
<zid>
gets to the imul and randomly jumps to the PF handler
<mrvn>
And that log shows imul r12, and then the 0 access?
<geist>
but clearly it's not running imul, so what instruction does it run?
<geist>
you can add more tracing to figure that out if log cpu doesn't do it
<geist>
-d in_asm maybe, or one of cpu or exec
<zid>
more tracing than the full register state
<geist>
in_asm is neat because it shows you the block of instructions it is grabbing before it interprets it
<zid>
every single instruction?
<geist>
of course
<zid>
hmm why is addr2line being a poo all of a sudden
<geist>
it's possible it already ran the instructions before and cached it, so yo might have to rewind into the log a bit to find the first time it hits that block
<zid>
oh I don't think it likes not having an 0x m aybe
<geist>
right, so you're looking at i think 'exec' maybe
<geist>
you want some more switches
<geist>
or maybe 'cpu'
<geist>
-d cpu,exec is interesting
<geist>
also -d in_asm,cpu,exec
<zid>
no singlestep with that, or also?
<geist>
shows you the blocks as it starts them
<geist>
whatever triggers whateve ryou want
<geist>
probably do whatever gets you the shortest trace to failure
<zid>
I can't do this
<zid>
It's going to take about 3-4 weeks to get that far unless I can toggle it at runtime after the OS has booted
<geist>
ah bummer
<zid>
also would probably help if I removed the movabs rax, 01234; jmp rax frm main() :P
<geist>
also i highly recommend routing all the logs through gzip or something
<zid>
yea I need to erm
<geist>
generates a much smaller log and may ctually be faster since it wont be disk bound or whatnot
<zid>
stop printing it, and it should speed up a lot
<zid>
I know -D logs to file, I need it to log to stdio in a way I can redirect it, -monitor stdio 1> doesn't work
<geist>
yah hang on. it's tricky foo
<geist>
so simplest thing is route stderr only (which is where the trace is)
<zid>
oh fair enough
<geist>
so `2> trace.txt` keeps it from spamming the console
<geist>
trying to regenerate the pipe logic
<zid>
I can do that bit
<zid>
I already did it, infact
<geist>
`qemu-system-x86_64 -d in_asm,cpu,exec 2>&1 | gzip > foo.txt.gz` for example
<geist>
sometimes the gzip helps immensely since it's highly repetitive
<zid>
oh I just did mkfifo log; gzip <log >log.gz
Vercas8 has joined #osdev
<zid>
qemu 2>log
<geist>
oh that's even nicer
<geist>
depending on how fast your sysem is the gzip may or may not help. gzip -1 may be nice too, since you really just want it to do a bunch of redundant stuff
<zid>
but now gdb won't connect.. nice
Vercas has quit [Ping timeout: 240 seconds]
Vercas8 is now known as Vercas
<zid>
and I can't give it a 'c' command in the montitor anymore because of the redirect
<geist>
anyway, the key is the log you've been looking at is 'cpu' which shows the state of the cpu before it runs a trace
<geist>
'exec' shows when it switches traces
<geist>
and in_asm shows what it thinks the input is the first time i saw a trce
<geist>
so actually 'exec,in_asm' may be nicer
<geist>
since you might not need to see the full register state, and would generate way less nonsense
<zid>
maybe gzip is blocking or something
<geist>
but you could see when it goes off on the weeds
<zid>
it's.. not actually any faster
<zid>
so I guess my terminal output speed was plenty fast already