| *** kylel1 is now known as kylel | 10:19 | |
| lkcl | found a bug in the PLRU code used for TLBs | 14:26 |
|---|---|---|
| lkcl | really obscure | 14:30 |
| lkcl | just restarted the linux kernel boot. it'll be an HOUR just "Allocating 0x5fb320 bytes for kernel" | 14:31 |
| lkcl | straight memcpy, no compression | 14:31 |
| lkcl | mental | 14:31 |
| *** iridium.libera.chat sets mode: +o toshywoshy | 15:32 | |
| *** iridium.libera.chat sets mode: +o lkcl | 15:32 | |
| ghostmansd[m] | Hi folks, hope you had good holidays! I have some updates on binutils code generation, but would like to know if I got correctly the way the data from CSV is handled. | 16:46 |
| ghostmansd[m] | Given, say, fdiv from minor_63.csv... | 16:47 |
| ghostmansd[m] | Where the opcode is -----10010... | 16:48 |
| ghostmansd[m] | Am I right that the mask we employ before doing the check is 0b11111, and the exact value we check is 0b10010? | 16:49 |
| ghostmansd | Another example... | 16:50 |
| ghostmansd | extra.csv, attn insn | 16:51 |
| ghostmansd | opcode is 000000---------------0100000000- | 16:51 |
| ghostmansd | mask is 0b11111100000000000000011111111110, value is 0b1000000000, right? | 16:52 |
| ghostmansd | under mask/value, I mean that we check for opcode as ((this_value & mask) == (that_value & mask)) | 16:53 |
| ghostmansd | I have no idea what nmigen Signal is, so it'd be great if you could give some clues on how these Signals map to C structures | 16:53 |
| lkcl | ghostmansd, yes, thank you :) | 17:00 |
| lkcl | yes | 17:00 |
| lkcl | "-" means "we do not care what that bit is, at all" | 17:01 |
| ghostmansd | ok, seems that `((this_value & mask) == (that_value & mask))` makes sense then | 17:02 |
| lkcl | treat them as arbitrary-length integers but with a set length. more like a python int than a c uint64_t | 17:02 |
| lkcl | yes | 17:02 |
| * lkcl is staring at tens of thousands of simulated instructions rolling by... | 17:03 | |
| lkcl | 9 million instructions to get to the point i'm tracking down a bug | 17:04 |
| ghostmansd | whoa | 17:07 |
| ghostmansd | is it possible to narrow the scope? | 17:07 |
| lkcl | possibly by taking a full snapshot of the processor "memory" (which is in a file, so is feasible) | 17:08 |
| lkcl | taking a full register dump | 17:08 |
| lkcl | i'm doing output currently of PC, insn, and all LD/STs to a text file (verilator) | 17:09 |
| lkcl | then running microwatt to get a "known good" | 17:09 |
| lkcl | and then doing a "diff -u" on the logs | 17:09 |
| lkcl | which are still 15 million lines long but hey | 17:09 |
| lkcl | lkcl@fizzy:~/src/libresoc/microwatt$ wc bram.microwatt.linux.dump | 17:10 |
| lkcl | 13145754 68823276 544792854 bram.microwatt.linux.dump | 17:10 |
| lkcl | 13 million. | 17:10 |
| ghostmansd | heck | 17:10 |
| ghostmansd | good luck with that | 17:10 |
| lkcl | :) | 17:10 |
| lkcl | has to be done. | 17:10 |
| lkcl | i quite like the verbose debug logs, i find it reassuring :) | 17:12 |
| lkcl | if only we had kernel-level debug access here, i could run gdb and find out what's going on that way | 17:16 |
| lkcl | it's really strange, writing python programs that are so bluntly unsophisticated | 17:22 |
| lkcl | there is a... unwritten rule to do as much abstraction and as much code-reuse as possible, almost as a matter of pride and principle | 17:23 |
| lkcl | yet in some cases it just becomes... | 17:24 |
| lkcl | well, i think i told other people here a story about a new web developer for a security company i worked for | 17:24 |
| lkcl | the customer needed a CPU reporting screen, as a full-screen "bar". | 17:25 |
| lkcl | i did it in... mmm.... 800 lines including the back-end? can't remember if i read /proc or just ran loadavg | cut | .... | 17:26 |
| lkcl | they gave the job of replacing it to the new employee | 17:26 |
| lkcl | six *weeks* later he had written 14 THOUSAND lines of code | 17:26 |
| lkcl | a full Model-View-Controller abstraction | 17:26 |
| programmerjake | were they rewriting htop in php? | 17:27 |
| lkcl | just to report a fricking CPU usage as a bar on the screen | 17:27 |
| lkcl | i think he decided to use django or some sort of vastly overblown framework | 17:27 |
| lkcl | whereas i'd knocked up a bit of python which outputted HTML after running os.popen() | 17:28 |
| lkcl | no, it was really just, "put the CPU usage on-screen as a single bar like you see in systray" | 17:29 |
| lkcl | not even as a rolling graph | 17:29 |
| programmerjake | model-view-controller is sometimes overused...just like object orientedness...we're not writing in smalltalk...or in VB | 17:29 |
| lkcl | how the hell he managed to turn that into 14,000 lines i will never know | 17:30 |
| lkcl | pc 603144 insn 95060008 | 17:30 |
| lkcl | wr @ 0006580c do | 17:30 |
| lkcl | ah maaaan, that has to get up to Allocating 0x5fb320 | 17:30 |
| programmerjake | maybe you unintentionally counted whatever library he included, so he only wrote a few of the lines? | 17:31 |
| lkcl | no, he really had written 14,000 lines in 6 weeks | 17:31 |
| programmerjake | or maybe it was a monero miner disguised as a MVC implementation | 17:32 |
| lkcl | they fired him 6 months later and he sued them for wrongful dismissal | 17:32 |
| lkcl | :) | 17:32 |
| lkcl | he wasn't able to listen to instructions properly. i had warned them to keep an eye on him but _they_ didn't listen. the whole company went to hell in a handbasket after it was sold a couple years later | 17:33 |
| lkcl | all a bit of a mess :) | 17:33 |
| lkcl | this is quite fascinating to see roll by | 17:34 |
| lkcl | rd @ 00135a95 di 74756d2065726120 sel ff .are.mut | 17:34 |
| lkcl | rd @ 00135a96 di 786520796c6c6175 sel ff ually.ex | 17:34 |
| lkcl | rd @ 00135a97 di 65766973756c63 sel ff clusive. | 17:34 |
| lkcl | the occasion ASCII string in a morass of instructions from the linux kernel, being copied from the vmlinux image into "RAM" | 17:35 |
| * lkcl am getting dizzy with the scrolling, have to walk away get some soup :) | 17:35 | |
| lkcl | okaay an mtmsr should have thrown an illegal exception | 18:43 |
| lkcl | oh wait... | 18:44 |
| lkcl | pc 1ca9c insn 7c0006ac | 18:44 |
| lkcl | pc 700 insn 7db243a6 | 18:44 |
| lkcl | whereas for microwatt: | 18:45 |
| lkcl | pc 1ca9c insn 7c0006ac | 18:45 |
| lkcl | pc 1caa0 insn 78691028 | 18:45 |
| lkcl | okaaay let's decode that.. | 18:45 |
| lkcl | lbzcix | 18:46 |
| lkcl | ahhhh i haven't implemented that yet :) | 18:46 |
| programmerjake | no wonder it broke... | 18:52 |
| lkcl | oh that's interesting: it's implemented, but is a privileged operation | 18:53 |
| lkcl | BUT | 18:53 |
| lkcl | urrr | 18:53 |
| lkcl | microwatt said "ok" to that. | 18:53 |
| lkcl | damn, i should have brought out MSR as well as PC, oh well | 18:54 |
| lkcl | i wonder if i'm checking the right bit | 18:54 |
| programmerjake | can you attach jtag remote debug to the verilator simulation? sounds likely to make it waay easier to check via gdb | 18:56 |
| octavius | lkcl, wow what a crazy example of code bloat XD | 18:56 |
| lkcl | err... ermermerm... i no unnerstand | 18:56 |
| lkcl | programmerjake, i'd have to implement it. | 18:56 |
| lkcl | i have that in the other verilator simulation (the one that can't run linux) | 18:57 |
| lkcl | it'd have to be manually (explicitly) added | 18:57 |
| lkcl | i mean, this is *real* basic. the microwatt verilator simulation used to only have... uart. that was it. | 18:57 |
| lkcl | the sum total of all possible interaction | 18:57 |
| programmerjake | would implementing it be faster than going through the simulation several more times cuz more bugs pop up? imho probably | 18:57 |
| lkcl | honestly not sure | 18:58 |
| lkcl | octavius, this is the linux kernel! | 18:58 |
| programmerjake | or at least some form of debug access | 18:58 |
| lkcl | normally, those 13 million instructions would be executed at what... 2 ghz? | 18:58 |
| lkcl | they'd normally be completed in under 50 ms, caches notwithstanding | 18:59 |
| lkcl | yyeah i have that in the other simulator, too. DMI dump is done that way | 18:59 |
| lkcl | but this is 13 MILLION instructions | 18:59 |
| programmerjake | idea: debug the verilator c++ in gdb then break when the correct output is printed... | 19:00 |
| lkcl | previously what i did was "if 0xnnnn < PC < 0xnnnnn" { enable debug } | 19:00 |
| lkcl | ooo that's a truly dreadful idea that might actually work really well :) | 19:00 |
| lkcl | ohh i think they even allow you to fire off gdb from verilator | 19:00 |
| lkcl | that makes sense now | 19:01 |
| programmerjake | other idea: add full simulation state save/restore, so you can start from a snapshot right before the error | 19:01 |
| * lkcl want to track down why lbzcix threw an illegal exception | 19:01 | |
| lkcl | ha, that's what lots of the debugging companies sell proprietary debug products for, for a whooole boat-load of cash :) | 19:02 |
| lkcl | yes, there's no reason why the entire memory should not be saved out. | 19:03 |
| programmerjake | ah...run verilatorin gdb with hardware reverse debugging enabled...iirc intel cpus have hw support for helping with that | 19:03 |
| lkcl | --savable | 19:04 |
| lkcl | Enable including save and restore functions in the generated model. | 19:04 |
| lkcl | cool! | 19:04 |
| programmerjake | https://sourceware.org/gdb/wiki/ReverseDebug | 19:07 |
| lkcl | ehn?? wtf?? lhzcix works fine, lbzcix - which by a coincidence we don't have a unit test for - raises an exception when i added it to the ldst_test_cases.py | 19:08 |
| lkcl | mmmm | 19:08 |
| lkcl | okaaay that's addeed... | 19:12 |
| * lkcl acieeeed | 19:12 | |
| lkcl | it's going to be bizarre things like this, i think. | 19:13 |
| lkcl | all the unit tests in the world are nothing compared to running a few hundred million instructions | 19:13 |
| lkcl | okaaay off we go again, another 13 million instructions... | 19:18 |
| * lkcl going to watch another episode of mythbusters, it's about how long it takes :) | 19:18 | |
| lkcl | must remember i am at line 7963511 of the dump file though, that's where the exception happened before | 19:19 |
| lkcl | frickin mad | 19:19 |
| programmerjake | reminds me of when I got a ryzen 1000 cpu, and it would randomly segfault when running compilers...very annoying, but also shows that the best aren't immune to issues | 19:19 |
| lkcl | oo that's usually a sign of a memory hardware fault | 19:20 |
| lkcl | or in my case, an incorrect BIOS factory setting, putting in the wrong DRAM timings | 19:20 |
| lkcl | which would have not been so serious if i hadn't bought 8 identical machines | 19:21 |
| programmerjake | no, the memory works just fine...i'm currently using it in my desktop. it was that particular cpu model. | 19:21 |
| lkcl | ah deep joy | 19:21 |
| programmerjake | https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Test-Stress-Run | 19:21 |
| programmerjake | after I bought the next generation of cpu as a replacement, i gave it to my dad, who isn't a developer so doesn't really encounter those issues | 19:24 |
| lkcl | nice | 19:53 |
| lkcl | ha, it was actually a missing instruction eieio | 23:54 |
| lkcl | which is the column one over from lbzcix in the opcode map minor 31 | 23:54 |
| lkcl | here we go again... | 23:57 |
| lkcl | loading dtbImage.microwatt at 0x600000 size 0x5d1018 | 23:58 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!