Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I've decided to add ACPICA to my OS, but despite having what seems to be correct implimetations of all the OS shim functions (linked below), the ACPI tables on qemu appear partially corrupted (despite the pointer being correct)
(Edit: On Bochs / VirtualBox the tables are sane, and I hit a page fault in the ACPICA code - somewhere around the AML VM from memory - I'm pretty sure that's my fault somehow)
Last edited by thepowersgang on Fri Dec 07, 2012 9:12 pm, edited 1 time in total.
I'm not 100% certain but it looks like a problem in the mapping. ACPICA appears to be trying to locate additional tables but ends up pulling out what looks like AML code values. So either something is wrong with your mapping function or there's some other memory corruption that's disrupting the values read in from the RSDT (which appears valid).
I would blame the mapping code too, if that code wasn't known stable (the function used is integral to my MM code, and has been tested thoroughly) and works in the same situation on two other VMs.
I'll check if that memory is writable, then work on validating if it's being corrupted (I gave a brief check of my page allocator, but didn't find anything)
Here is the bochs output for comparison (from bochs 2.6, the qemu dump was from 1.2.0)
It's very possible that it's just a small amount of memory being overwritten, maybe a single byte or word given that the pointer is still in the right ballpark. Another thing worth trying might be configuring ACPICA to use it's internal cache implementation to see if it runs into similar errors, that might narrow it down to your own caching implementation (though it looks fine). One thing I'll note that can really screw things up is simply updating your ACPICA revision incorrectly. I was chasing a phantom bug in my code for months once due to a botched update. ACPICA can dump a ton of debug info if it's configured for it too, you can probably narrow things down fairly quickly at this point as only the tables are being parsed so there's a lot less info to go through. At any rate if the mapping code is solid the next most likely candidate is the object cache implementation and probably the heap after that.
Actually, I've just found out why it broke, and it's because this is the first time this MM function has been used in this way (repeated map/unmap)... TLB. Running a page dump after each mapping caused tables to parse correctly, hence it was most probably the TLB not being flushed. Adding an invlpg after the unmap fixed the problem.
