Search logs:

channel logs for 2004 - 2010 are archived at ·· 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

Tuesday, 7 June 2022

03:34:00 <geist> huh finally got around to trying to read the 68040 mmu docs
03:34:00 <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
03:35:00 <geist> ie, instead of a PTE, it's a 30 bit pointer (4 byte aligned) to somewhere else
03:36:00 <mrvn> having what meaning?
03:37:00 <geist> basically you can point multiple PTEs at a shared PTE
03:37:00 <kazinsal> ooh. neat.
03:37:00 <mrvn> So it's a full PTE you point to with all the bits and not a 32bit pointer?
03:38:00 <geist> well 30 bits (bit 0 and 1 are used to signify that it's an indirect pointer)
03:38:00 <geist> but yeah, kinda weird
03:40:00 <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
03:40:00 <mrvn> I mean the thing you point to.
03:41:00 <Mutabah> Oh, I get it. Neat
03:41:00 <geist> mrvn: can you rephrase the question?
03:41:00 <mrvn> The 2 bit in the original PTE don't leave much space to flag R/W/X, kernel/user, present/not present, ...
03:41:00 <Mutabah> An entry in the lowest-level table can be indirect (pointing to another entry)
03:42:00 <geist> right. it's that the entry is isntead of a final PTE a pointer to another one
03:42:00 <geist> i think it says it can't infinitely indirect of course
03:42:00 <mrvn> can it indirect more than once?
03:42:00 <geist>
03:42:00 <bslsk05> ​IRCCloud pastebin | Raw link:
03:43:00 <geist> (the PDT field is bit 0 and 1)
03:43:00 <geist> and no in the next paragraph it says it cant point to another indirect entry, or it'll treat it as invalid
03:45:00 <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.
03:45:00 <geist> yep
03:45:00 <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)
03:47:00 <geist> also kinda unsurprising, the 68030 MMU is actually *more* complicated and more flexible
03:47:00 <geist> lets you support up to 5 levels of page table by specifying the radix essentially
03:49:00 <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
03:49:00 <mrvn> how about 060?
03:49:00 <geist> dunno
03:50:00 <geist> at quick glance looks to be basically identical to 040
03:58:00 <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
04:05:00 <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.
04:06:00 <geist> that's my role here. to trigger folks with old devices so they'll do retro it
04:36:00 <kazinsal> geist will not be satisfied until every channel regular owns a vax
04:36:00 <geist> speaking of....
04:36:00 * geist looks expectedly
04:36:00 <mrvn> sorry, only m68k, ppc, alpha, mips, arm, x86, x86_64 here
04:36:00 <kazinsal> I gotta figure out what I want to do with mine
04:37:00 <mrvn> I do need a monitor cable for an Indy though.
04:37:00 <kazinsal> I should try to set up a simh config to simulate it and start doing a bit of hackery on it
04:37:00 <kazinsal> but I also have this horrible idea of hosting a dial-up BBS on it...
04:38:00 <mrvn> Do dial-up modems even work well anymore with modern telephones?
04:38:00 <kazinsal> dial-up yes, faxes sometimes
04:38:00 <mrvn> faxes should work better, lower BAUD
04:38:00 <kazinsal> you would think, but faxes are the devil
04:39:00 <kazinsal> fax machines really do not like VOIP
04:39:00 <geist> i did see someone doing some retro stuff online with a dialup simulator
04:39:00 <mrvn> can't see a 56k modem working to actually get 56k
04:39:00 <geist> kinda a neat looking box, basically emulates the entire dialup networking stuff
04:40:00 <geist> in the sense that it does the tone dialing, he still provided two modems on either end
04:40:00 <kazinsal> we used to have this old callmanager book from the late 90s at work that had a whole chapter about faxes over VOIP
04:40:00 <mrvn> geist: what does that involve? 2 relays to make the dial-tone and connect signal should be enough.
04:40:00 <kazinsal> because faxes just hate VOIP links
04:40:00 <geist> mrvn: dunno, this actually emulates the whole dial tone + accepting dialing to something and routing it through
04:41:00 <mrvn> geist: if you need more than point-to-point with actual numbers it gets complex.
04:41:00 <geist> but yeah i thnk you can generally just run two modems into each other, i think
04:41:00 <mrvn> you would need something huge to emulate that, like a ATTiny. :)
04:41:00 <geist> kinda curious now if someone has tried to just emulate the whole thing with a sound card
04:41:00 <geist> just software implement a whole modem on the dialup end
04:42:00 <mrvn> geist: most (all?) builtin modems are sound cards.
04:42:00 <geist> sure, i mean it's been done. i more mean has someone recently just brute forced it with some open source software
04:43:00 <mrvn> Thing is the good and high speed modems use multiple BAUD rates in parallel. Might need multiple instances of software defined radio.
04:43:00 <geist> seems to do the basic schematic to wire two modems together
04:43:00 <bslsk05> ​'56k and 33.6k Modems Connecting to Each Other with no Phone Service' by Gadget Reboot (00:14:55)
04:51:00 <kazinsal> I need to dig around in some old disco documentation and see if I can kind of "softmodem" up an inbound dial-peer from a SIP trunk
04:52:00 <kazinsal> and connect inbound modem calls on a DID up to a telnet connection
05:06:00 <mrvn> geist: Did you ver have a dialing robot for your rotary phone and accoustic coupler so you don't have to dial BSSes by hand?
05:18:00 <Andrew>
05:19:00 <Andrew> sorry, broken client
05:19:00 <moon-child>
05:53:00 <geist> mrvn: not quite that early for me. i always had modems with built in dialers
16:53:00 <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?
16:56:00 <mrvn> yes
16:58:00 <bauen1> the classical answer to any or question
16:58:00 <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
16:59:00 <mrvn> For me both branches are even true at the same time.
17:01:00 <stephe> hrmmm
17:02:00 <stephe> im gonna have to meditate on this one
17:02:00 <mrvn> FYI you can go from real mode to long mode in one step too
17:02:00 <GeDaMo>
17:02:00 <bslsk05> ​ Guru Meditation - Wikipedia
18:17:00 <mrvn> geist: ever tried -static-pie with gcc?
18:18:00 <geist> I have not
18:19:00 <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.
18:20:00 <geist> Ah interesting
18:36:00 <zid> did we magically think of how cr2=0 rip=0 is possible yet? :P
18:38:00 <mrvn> zid: still thinking it's a double fault
18:39:00 <mrvn> Your IDT is broken so the first fault goes to rip=0 and faults again
18:49:00 <geist> i'd put my money on observation error
18:50:00 <zid> what's one of those
18:50:00 <zid> I mean, in this case
18:50:00 <zid> I think qemu is just not reporting the info I'd need here
18:50:00 <geist> correct
18:50:00 <geist> as in what you tink you see isn't whats happening
18:51:00 <zid> Can i blame shannon, or mr nyquist maybe
18:51:00 <geist> blame is irrelevant
18:51:00 <geist> could be you, could be qemu, could be whatever. but i'm putting money on something like that
18:52:00 <zid> Oh it's almost certainly me, but qemu is not being helpful about what I did :P
18:56:00 <zid> okay so I tested the contents of rip & cr2 in qemu for known cases.. and that's actually really unhelpful
18:56:00 <zid>
18:56:00 <zid> movabs rax, 0x1234; jmp rax -> nothing contains the old RIP
18:56:00 <zid> does the cpu really do that? :/
18:57:00 <geist> yah i think you're gathering pretty good info for it's not even running code yo think it is
18:57:00 <geist> seems to be mounting evidence of that
18:57:00 <zid> does the cpu really do this though?
18:57:00 <geist> do what?
18:57:00 <zid> delete the old rip in the decode fault case
18:58:00 <geist> not sure i understand what you're asking
18:58:00 <zid> if you do mov rax, 0x1234; jmp rax
18:58:00 <zid> from 0xDEADBEEF
18:58:00 <zid> 0xDEADBEEF does not appear to be recoverable
18:58:00 <geist> that's right
18:58:00 <zid> That's.. highly annoying, thanks x86
18:58:00 <geist> it branched to 0x1234, then it faulted
18:58:00 <geist> thats how all cpus behave
18:59:00 <zid> I guess you'd need two CR2s
18:59:00 <zid> wtb CR5 that contains the value of RIP during an instruction fetch pf
19:00:00 <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
19:00:00 <zid> if you do mov [rax], 0
19:00:00 <zid>
19:00:00 <zid> you get a much more useful fault out of qemu at least
19:00:00 <zid> where it reports the rip *of the faulting instruction*
19:01:00 <geist> right, because it's the same model
19:01:00 <geist> the mov instruction faults so it fails
19:01:00 <geist> the jmp didn't fail, the instruction at the target of the jmp did
19:01:00 <zid> yea it makes sense, but it's the most annoying interpretation of *how* it should work
19:01:00 * geist nods
19:02:00 <geist> computers are hard
19:02:00 <zid> I'd need to go full emulation to catch this then.. bochs time? :P
19:02:00 <zid> not sure if I even have bochs
19:02:00 <geist> thought you were doing singlestep and whatnot
19:03:00 <geist> can't you just see what the instruction was before?
19:03:00 <zid> yep and it gives an entirely different fault
19:03:00 <mrvn> zid: what if you do b 1; 1: b 2; 2: b 3; 3: b 4; 4 ... Should it have N CR2s?
19:03:00 <zid> I get a fault on imul r12
19:03:00 <geist> then debug that
19:03:00 <zid> which similarly, makes no fucking sense
19:03:00 <geist> i'm guessing it's the same thing
19:03:00 <geist> so debug that
19:03:00 <zid> or some other random instruction
19:03:00 <zid> we tried, and failed
19:03:00 <geist> as in you have something fucked up meory wise, etc etc
19:03:00 <zid> neither of us could think of something I hadn't checked
19:03:00 <geist> so it's all heisenbugs
19:03:00 <zid> yep
19:03:00 <geist> right, so rewind before the imul and see where it fails there
19:03:00 <zid> it decodes as an imul r12 before and after the fault with gdb + qemu's x commands
19:04:00 <geist> there's bound to be a smoking gun there
19:04:00 <zid> I can't because it's not deterministic enough
19:04:00 <zid> it faults in random places in singlestep mode
19:04:00 <geist> so multiple runs fails differently?
19:04:00 <geist> or if yo modify something it fails differently?
19:04:00 <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
19:04:00 <mrvn> zid: maybe whatever was there before faults?
19:05:00 <geist> does the imul happen to be a target of a branch, or on a particular aligned boundary?
19:05:00 <zid> and if I use breakpoints to toggle `log cpu` on and off then I've changed all the timings
19:05:00 <zid> nope, it just ran straight through a mov rax, r12; imul r12, ... section
19:05:00 <geist> i'm sure you have but i've found that catting the logs through gzip helps immensely
19:05:00 <mrvn> zid: what's the CS and page permissions?
19:05:00 <geist> is the imul on a particularly interesting address? like it's the first instruction in a new page
19:05:00 <zid> nope, checked
19:06:00 <geist> still, i'd start with that, that's though 'random' a conceptually simpler problem
19:06:00 <geist> as in it's outright impossible, doesn't involve a branch, etc
19:06:00 <zid> start with what
19:06:00 <geist> the imul case + singlestep
19:06:00 <zid> I have the full singlestep log
19:06:00 <zid> it runs really normal instructions inside that page
19:06:00 <zid> gets to the imul and randomly jumps to the PF handler
19:07:00 <mrvn> And that log shows imul r12, and then the 0 access?
19:07:00 <geist> but clearly it's not running imul, so what instruction does it run?
19:07:00 <geist> you can add more tracing to figure that out if log cpu doesn't do it
19:08:00 <geist> -d in_asm maybe, or one of cpu or exec
19:08:00 <zid> more tracing than the full register state
19:08:00 <geist> in_asm is neat because it shows you the block of instructions it is grabbing before it interprets it
19:08:00 <zid> every single instruction?
19:08:00 <geist> of course
19:08:00 <zid> hmm why is addr2line being a poo all of a sudden
19:09:00 <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
19:09:00 <zid> oh I don't think it likes not having an 0x m aybe
19:10:00 <zid>
19:10:00 <zid> I think my brain is too frazzled
19:10:00 <geist> yah frankly i'd just use objdump -d
19:10:00 <geist> gives you more context, etc
19:11:00 <geist> but yeah this is a weird one, but gotta be something like it's not running what it says
19:11:00 <geist> also if timing is a thing i'd try to reduce the system as much as you can, in case you haven't
19:11:00 <zid> I'm too dumb at bash to figure out how to grep this
19:11:00 <geist> one cpu, less memory, less devices, maybe no timer (if possible, etc)
19:12:00 <geist> then dont grep it, open it in a window and search it
19:12:00 <zid> I just need to figure it out
19:12:00 <geist> i always keep a gvim or vim up with a dissassembly
19:12:00 <geist> objdump -d > some file is nice because then you can open the file with your editor and tell it to reload it if it chaanges
19:12:00 <geist> with vim i have it `:set autoread`
19:12:00 <zid> I am being dumb at pipes
19:13:00 <zid> Trying to avoid an actual bash script, I am bad at bash scripts even moreso
19:14:00 <zid> I need to xargs into a subclause or some shit, dunno how to explain it
19:15:00 <geist> what are you trying to do?
19:15:00 <zid> I want to substitute into objdump -d | grep xxx
19:16:00 <geist> can put it in a variable
19:16:00 <zid> I think I need to xargs -i sh -c 'command | command {}'
19:16:00 <geist> FOO=address then $FOO
19:16:00 <zid> then the sh is a single command
19:19:00 <zid> okay got it working
19:19:00 <geist> but again frankly i'd just open a window with an editor looking at the disasm
19:19:00 <geist> then you get some context around it
19:20:00 <zid> I've.. also done that, but turning your head and matching numbers up and stuff is tedious and error prone
19:20:00 <geist> okey dokey
19:20:00 <zid> that's how I know it's a mov rax, r12; imul r12, ...
19:20:00 <zid> and you were curious whether it crossed a page boundary and other things, this shows it nicely
19:21:00 <geist> sure
19:21:00 <zid>
19:21:00 <zid> That's the last 11 instructions executed
19:21:00 <geist> cool
19:23:00 <zid> no memory access, this code is ran literally millions of times, x /1i 0x205fd2 in qemu shows the right bytes/instruction for that region
19:23:00 <zid> not straddling a page
19:23:00 <zid> no interrupts happened
19:24:00 <zid> so in what *specific* way is qemu lying to me, I wonder
19:27:00 <geist> that's why this just needs a trace
19:27:00 <geist> to see what it actually ran
19:27:00 <zid> I have a trace of what it ran
19:27:00 <zid> this is that
19:28:00 <zid> according to it, anyway
19:29:00 <geist> yes but did yo get a trace of what instruction it thinks it ran the last time
19:29:00 <zid> what option might that be?
19:29:00 <geist> i dunno, can you pastebin the block of log aroun dit?
19:29:00 <geist> i'm curious what you're looking at
19:29:00 <zid> what's 'go to end' in vim? >_<
19:30:00 <zid> okay :283983928392 worked lol, probably not proper
19:30:00 <geist> :%
19:30:00 <geist> (i literally had to open a vim and type it, because i couldn't think of what it is off the top of my head, but muscle memory did)
19:30:00 <zid> 40GB of this
19:31:00 <geist> right, so you're looking at i think 'exec' maybe
19:31:00 <geist> you want some more switches
19:31:00 <geist> or maybe 'cpu'
19:31:00 <geist> -d cpu,exec is interesting
19:31:00 <geist> also -d in_asm,cpu,exec
19:31:00 <zid> no singlestep with that, or also?
19:31:00 <geist> shows you the blocks as it starts them
19:32:00 <geist> whatever triggers whateve ryou want
19:32:00 <geist> probably do whatever gets you the shortest trace to failure
19:32:00 <zid> I can't do this
19:33:00 <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
19:33:00 <geist> ah bummer
19:33:00 <zid> also would probably help if I removed the movabs rax, 01234; jmp rax frm main() :P
19:33:00 <geist> also i highly recommend routing all the logs through gzip or something
19:33:00 <zid> yea I need to erm
19:33:00 <geist> generates a much smaller log and may ctually be faster since it wont be disk bound or whatnot
19:34:00 <zid> stop printing it, and it should speed up a lot
19:35:00 <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
19:36:00 <geist> yah hang on. it's tricky foo
19:37:00 <geist> so simplest thing is route stderr only (which is where the trace is)
19:37:00 <zid> oh fair enough
19:37:00 <geist> so `2> trace.txt` keeps it from spamming the console
19:38:00 <geist> trying to regenerate the pipe logic
19:39:00 <zid> I can do that bit
19:39:00 <zid> I already did it, infact
19:40:00 <geist> `qemu-system-x86_64 -d in_asm,cpu,exec 2>&1 | gzip > foo.txt.gz` for example
19:40:00 <geist> sometimes the gzip helps immensely since it's highly repetitive
19:40:00 <zid> oh I just did mkfifo log; gzip <log >log.gz
19:40:00 <zid> qemu 2>log
19:40:00 <geist> oh that's even nicer
19:41:00 <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
19:41:00 <zid> but now gdb won't connect.. nice
19:41:00 <zid> and I can't give it a 'c' command in the montitor anymore because of the redirect
19:41:00 <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
19:41:00 <geist> 'exec' shows when it switches traces
19:42:00 <geist> and in_asm shows what it thinks the input is the first time i saw a trce
19:42:00 <geist> so actually 'exec,in_asm' may be nicer
19:42:00 <geist> since you might not need to see the full register state, and would generate way less nonsense
19:42:00 <zid> maybe gzip is blocking or something
19:42:00 <geist> but you could see when it goes off on the weeds
19:42:00 <zid> it's.. not actually any faster
19:42:00 <zid> so I guess my terminal output speed was plenty fast already
19:44:00 <geist>
19:44:00 <bslsk05> ​IRCCloud pastebin | Raw link:
19:44:00 <geist> is the sort of thing you get with in_asm,exec
19:44:00 <zid> The only difference in the actual output seems to be it prints Trace 0: <some number> before each cpu log entry
19:44:00 <geist> first time it hits a trace it shows you the disassembly, then it just shows that it's execing the trace next time
19:44:00 <zid> I don't get machine code
19:44:00 <geist> in_asm does
19:44:00 <geist> but it only shows you the first time i hits the trace
19:45:00 <geist> from then on it's cached, so you have to search backwards to find the first instance of it
19:45:00 <zid> ah lemme do grep -A1 IN or something then
19:45:00 <zid> and see if I do
19:47:00 <zid> 0 movs
19:48:00 <zid> zgrep mov log.gz on a large file
19:49:00 <zid> I wonder of 'nochain' is useful
19:50:00 <zid> I think maybe out_asm is just empty for host==target?
19:51:00 <zid> "show generated host assembly code for each compiled TB"
19:51:00 <zid> It doesn't need to JIT anything it just.. memcpy's it doesn't it? :p
20:25:00 <zid> I noticed OBJ-T: EBFE somewhere so I rebuilt with capstone
20:25:00 <zid> and a nice qemu person said I could work around the slowdown via a snapshot before the crash, then re-loading it with my debug options on
20:33:00 <zid> huzzah, it now fails on a retq, glorious day
20:36:00 <zid> *way way way* better trace
20:49:00 <zid> so turns out, it isn't even really a crash, it's just main() returning after an abort
21:15:00 <geist> ah sorry had to go to a meeting there
21:16:00 <zid> nochain was the important part, anyway
21:16:00 <zid> it was doing JIT things to coallasce blocks of code and removing the jmps/rets/etc like a uop cache does
21:16:00 <geist> aaaah
21:17:00 <zid> so the jmp to 0 just wasn't in the output
21:17:00 <geist> and yeah out_asm isn't useful really
21:17:00 <geist> in_asm is what you want because you want to see what it thinks the block it ran was at the time it fetched it
21:17:00 <zid> I fixed that up at least, installed capstone :P
21:53:00 <geist> for some reason these sort of debugging things where you generate a crapton of data and then search through it and whatnot feels proper
21:54:00 <geist> like what computers are really for
21:55:00 <zid> Tonight I'm going to eat healthy, have some fruit. Limes specifically. Garnished with a bit of salt and tequila
21:56:00 <zid> Prost!
21:56:00 <zid> (I don't have any tequila that's a total lie, I might have a beer left over somewhere though)