Open tsharp opened 10 years ago
Hey, great to know :) I already noticed problems on a physical machine, however i had no time to track it.... very likely heap_init writes to a region it is not allowed to write to :/
Hint for debugging: tachyon already writes trace logs to com1. Good luck.
Cheers, Markus
Still tracking it down ... i've added debug output to heap_init, which is the definite source of this issue. More specifically it seems that the macro HEAP_BL_SET is the source of this.
\ Connected To COM1 *
[0] trace: setting handler for interrupt 14: 0xffffffff801200f2
wow, you're pretty far. Impressive :) maybe i can find some time to also setup a hyper-v environment, so i could help you, but i fear not i the next few days...
Have fun, Markus
Thinking about it, i assume that there is a page mapped to a physical region that is not accessible. How many physical adress bits does your cpu have? Maybe there is a physical region tachyon should not be allowed to access. Also, do you have a chance in hyper-v to log which interrupts are fired on cpu0?
You could try to modify the kernel heap region in defs.h to move the heap somewhere else just to test.
Markus
I have checked some code (currently only have my tablet, so i cannot try out things...), and i'm pretty sure that the problem is in the memory layout. KHEAP and KSHEAP are placed in a non-canonical region for less-than-48-bit physical cpus. A new layout is required there. To verify, it should be enough to set KHEAP_START to 0xFFFFFF8000000000 (assuming 40 bit physical). Otherwise to something higher depening on what the cpu can do... :)
There is some documentation in defs.h on the layout, and all relevant defines are in this one place. Tell me if you need more info.
If you could confirm that this is the (or one of the) problem, i'd happily accept a patch, or assist in creating one :)
Cheers, Markus
I have not tracked down exactly which part of the function causes the reset but it is within this function that causes a physical-machine to reset. This was first discovered when running the ISO image on a Hyper-V machine and re-confirmed when running on real hardware.
I will need to do some more debugging but it is a bit difficult to track down atm, I will be attempting to utilize the named pipes within hyper-v for the COM2 interface to see if that'll help track this down.
This is the entry point to where I started tracing the origin of the bug ...
/* initialize the physical memory */ pmem_init();
edit Ah - I should also mention that the machine im running on ... AMD Athlon x640, 16GB Ram