Goswin von Brederlow <brederlo@xxxxxxxxxxxxxxxxxxxxxxxxxxx> writes:
> Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> writes:
>
>> On 23/9/07 06:29, "Goswin von Brederlow"
>> <brederlo@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>>
>>> Now here is an example output of this loop:
>>>
>>> ERROR: -22 pinning failed: addr = 90000 [212000], op = 0, mfn = 212
>>> ERROR: -22 pinning failed: addr = 91000 [0], op = 0, mfn = 0
>>> ERROR: -22 pinning failed: addr = 92000 [b3d5000], op = 0, mfn = b3d5
>>> ERROR: -22 pinning failed: addr = 93000 [2000], op = 0, mfn = 2
>>> ERROR: -22 pinning failed: addr = 96000 [2000], op = 0, mfn = 2
>>> ERROR: -22 pinning failed: addr = 97000 [1000000], op = 0, mfn = 1000
>>> ERROR: -22 pinning failed: addr = 98000 [0], op = 0, mfn = 0
>>> ERROR: -22 pinning failed: addr = 99000 [1000], op = 0, mfn = 1
>>> ERROR: -22 pinning failed: addr = 9a000 [0], op = 0, mfn = 0
>>
>> The [phys] values look screwed. There are duplicates and many are 0! So it
>> looks rather like your p2m lookup logic is broken somehow.
>>
>> -- Keir
>
> I can't fathom what could be wrong with this:
>
> unsigned long *phys_to_machine_mapping;
> phys_to_machine_mapping = (unsigned long *)start_info.mfn_list;
>
> machine_address = phys_to_machine_mapping[(addr - VIRT_START) >> PAGE_SHIFT]
> << PAGE_SHIFT;
>
> The code is too simple and it works for all other pages outside that
> one range. No I don't think it is this piece of code. But if there is
> nothing to be there than the data itself must be corrupt. Although I
> can't think of anything that could be overwriting that
> phys_to_machine_mapping array.
>
> Maybe I could hack the domain creator to map the array read-only and
> see if I get a segfault?
>
> MfG
> Goswin
It seems that my stack ends up in the middle of the
phys_to_machine_mapping for some reason. I don't know if that is
already broken in Mini-OS or if I broke something though.
MfG
Goswin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel