On Fri, Jan 20, 2012 at 2:00 PM, Goran Narancic <[email protected]>wrote:
> On 20 January 2012 15:40, avadh patel <[email protected]> wrote: > >> >> On Fri, Jan 20, 2012 at 11:32 AM, Goran Narancic < >> [email protected]> wrote: >> >>> >>> This error is due to memory bounds setup in virtual to physical mapping. >> By default when qemu allocates RAM size > 4GB it creates a whole between >> 3.5 to 4GB RAM space. This check is just for validation purpose. The >> address range in your log seems between this 3.5 to 4GB address space but >> by looking at code the log print is done when total RAM size is less than >> 3.5GB. What is your RAM size? and if you see these address range with ram >> size lower than 3.5 then I am not sure why there are addresses allocated in >> this memory region. >> > > I usually use 1024 MB (-m 1024), but same thing used to happen when I put > in 512 and 2048. I haven't yet tried 4096. > > In that case you'll have to check with android memory mappings. Like in standard x86 systems you can find out how RAM, MMIO and Kernel is located into the whole memory address space (look into intel/amd manuals). You are using 1G RAM and your address is clearly above that value. The simulation doesn't crash and instead prints *ERROR* means that it has a *valid* 'virtual' to 'physical' translation but that translation doesn't makes sense to simulator. If the system you'r emulating/simulation does have some memory in that physical address range then you can happily ignore these message (or comment them out). I have an idea it might be caused by unknown instruction, since when I > start qemu with image that has Android installed, I get this message: > [ XXXXX ] microcode : no support for this CPU vendor > > where "XXXXX" is a decimal number that changes. It doesn't seem to be > Android itself complaining since next line is about finding Android > installation, but I'm guessing it has something to do with all the problems. > > This error is from linux kernel. The message you'r seeing is from kernel's logger and XXXX is the time since system has booted. This error is not due to any RAM issue, its just that CPU type (read from cpuid) is not supported. If you run 'cat /proc/cpuinfo' you'll find out the type of CPU and its vendor. I think its set to QEMU by default. > This can start and end multiple times in one simulation - though what >>> effect it is having, I cannot say. Since MARSS regularly crashes at several >>> different points (I'll probably be posting a question on that in future), I >>> cannot say if this is actually important/harmful or just odd. >>> >>> We are trying to hunt bugs that cause random crashes in simulation. Are >> your running your simulations from checkpoints or without checkpoints? We >> are having issues with some checkpoints and also some times when we have >> lots of switch between simulation and emulation mode. >> > > I'm running simulation without checkpoints (though I do plan to use them). > I also don't switch a lot between simulation and emulation. My plan is to > make a list of the most common errors I had (several asserts seem to be > popular), then send a message about that. I was just wondering if you had > any idea if the outside RAM problem is related or not. > > That's great. As we are short in manpower we always welcome some help with debugging, so send as much information as possible about the issues you have which makes its little easier to find the bugs. - Avadh > Goran > > >> >> - Avadh >> >> Thank you, >>> Goran >>> >>> _______________________________________________ >>> http://www.marss86.org >>> Marss86-Devel mailing list >>> [email protected] >>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >>> >>> >> >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
