search

mduft / tachyon3

tachyon - another version
MIT License
18 stars 6 forks source link

bool heap_init(heap_t* heap) causes Hyper-V and Physical Machine To Reboot Continuously #3

Open tsharp opened 10 years ago

tsharp commented 10 years ago

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

mduft commented 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

tsharp commented 10 years ago

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 (old: 0x0000000000000000) [0] debug: try to reserve physical memory at 0x0000000000000000 (length: 4096 bytes) [0] debug: try to reserve physical memory at 0x0000000000001000 (length: 647168 bytes) [0] debug: try to reserve physical memory at 0x00000000000a0000 (length: 700416 bytes) [0] debug: heap_init - begin [0] debug: HEAP_CHECK [0] debug: pmem_alloc [0] debug: vmem_map [0] debug: HEAP_BL_SET [0] debug: * Block Size: 4080 [0] debug: * Heap Start: 0xffffff0000000000 [0] debug: * Heap End: 0xffffffff70000000 [0] debug: * Heap Page Flags: 0x0000000000000102 [0] debug: * Heap Space: 0x0000000000119000 [0] debug: \ Heap State: [0] debug: ** Valid: 0 [0] debug: ** VMem Mark: 0xffffff0000001000 [0] debug: ** Used Bytes: 0 [0] debug: ** Block Count: 0

mduft commented 10 years ago

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

mduft commented 10 years ago

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

mduft commented 10 years ago

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