[OSy] Problem so zapisovanim do do virtualnej pamete
Jozef Ruzinsky
JosephXI at post.cz
Wed Dec 5 23:25:44 CET 2007
Ahojte.
Ten problem stale pretrvava, ale dostal som sa aspon dalej s debugovanim.
zaujimava cast kodu: ( teda aspon myslim ):
80006F24 lw a2, 0x18(sp) # 0x18=24, a2: 0x0->0xc0003000
80006F28 lui v0, 0xce5f # 0xce5f=52831, v0: 0x20->0xce5f0000
80006F2C ori v0, v0, 0xea17 # 0xffffea17h=59927, v0:
0xce5f0000->0xce5fea17
80006F30 sw v0, (a2) # 0x0=0, cp0_context:
0x00000000->0x00600010, cp0_badvaddr: 0x00000000->0xc0003000,
cp0_entryhi: 0x00000001->0xc0002001
-- tu sa obsluzi TLB exception, a vlozi sa mapovanie
Toto je prva iteracia cyklu:
80006F30 sw v0, (a2) # 0x0=0
80006F34 addu a1, v0, 0 # a1: 0x8040af68->0xce5fea17
80006F38 addiu a0, 0, 0x10 # 0x10=16, a0: 0x80407054->0x10
80006F3C addu v1, a2, a0 # v1: 0x20->0xc0003010
80006F40 addiu v0, 0, 0x2000 # 0x2000=8192, v0:
0xce5fea17->0x2000
80006F44 addiu a0, a0, 0x10 # 0x10=16, a0: 0x10->0x20
80006F48 bne a0, v0, -0x4 # 0xfffffffc=4294967292
80006F4C sw a1, (v1) # 0x0=0
-- tu uz bezi iteracia bez prerusenia....
pre vysvetlenie:
0xce5fea17 je magicka konstanta, ktoru sa snazim zapisat
0xc0003010 je virtualna pamet, kam nieco chcem zapisovat, a je
namapovana priblizne na 0x40f000
iteracia bezi 512x.
z configu msim:
add rwm mainmembig 0x00400000 16M
mainmembig generic 0
bohuzial nedokazem zistit, preco instrukcia " sw a1, (v1)" zapise
nulu na adresu 0x0, ked "v1 = 0xc0003010" a "a1 = 0xce5fea17" teda
presne to, co chcem zapisat a presne miesto kam to chcem zapisat.
Dakujem za akukolvek pomoc.
J.R.
Rastislav Wartiak napsal(a):
> Děkuji za nápad. V mém případě byl problém docela jednoduchý -
> vma_free nesmazalo příslušný záznam v TLB a tedy pokud jsem později
> přidelil stejnou stránku na jiný rámec, tak až do přemazání záznamu v
> TLB to zapisovalo úplně jinam. Vaše testy mě ale nepustily :-)
>
> Hezký den,
> Rastislav Wartiak
>
>
>> Dobry den,
>>
>> podobny, ne-li stejny problem se tu kdysi resil, zapatral jsem v
>> archivech a nasel zde
>> https://dsrg.mff.cuni.cz/pipermail/osy/2004-December/thread.html
>> thready "TLB" a "TLB - vyreseno". Tak se zkuste podivat zda vas to
>> nenakopne spravnym smerem :)
>>
>> Vlastimil Babka
>>
>> Rastislav Wartiak wrote:
>>
>>> Ano, bojuji s podobným problémem.
>>>
>>> Rastislav Wartiak
>>>
>>>
>>>
>>>> jj, tak ten podivny vypis bol sposobeny tym cim popisujes. Stale, ale mame
>>>> problem so zapisom do virtualnej pamate.
>>>>
>>>> To co sa nam deje je detailne popisane tu ..
>>>>
>>>> 0.
>>>> TLB je prazdne
>>>>
>>>> 1.
>>>> Test si naalokuje pamat 0xc0000000 a zapise do nej;
>>>> <0,0> .. cycle 0 (actionno: 0) -- vma_alloc (size=0x1000) = EOK,
>>>> ptr=0xc0000000
>>>>
>>>> TLB vyhlada mapovanie a zapise do tabulky zaznam;
>>>> [30] : Virtual Address=0xc0000000 ;Even=0x40a800 [D=1,V=1,G=0]; ODD=0x0
>>>> [D=1,V=0,G=0] ; ASID=1
>>>>
>>>> (Uz v tomto momente pri vypise virtualnej pamate 0xc0000000 vypise 255, co
>>>> je obsah FYZICKEJ pamate aj na 0xc0000000
>>>> stranka 0x40a800 obsahuje same 00.)
>>>>
>>>> 2.
>>>> Test sa poskusi pristupit k naalokovanej pamati a nenajde tam ocakavanu
>>>> hodnotu;
>>>> <0,0> .. cycle 0 (actionno: 1) -- access (ptr=0xc0000492) = 255,
>>>> expected 18
>>>>
>>>> Ziadna tlb exception sa nevyhodi a v tabulke je stale ten jediny zaznam;
>>>> [30] : Virtual Address=0xc0000000 ;Even=0x40a800 [D=1,V=1,G=0]; ODD=0x0
>>>> [D=1,V=0,G=0] ; ASID=1
>>>>
>>>> Mame pocit, ze bezime v nejakom divnom rezime. Ako keby pri nacitani pamate
>>>> pouzival virtualnou adresou namiesot namapovanej fyzickej,
>>>> pripadne sa dival niekam este uplne ako ma. Zapisuje tiez ktoviekam. Nemali
>>>> ste niekto z Vas podobny problem? Dakujem za odpoved.
>>>>
>>>>
>>>> On 12/5/07, Andrej Krutak <andree182 at gmail.com> wrote:
>>>>
>>>>
>>>>> Aha,
>>>>>
>>>>> teraz ma napadla este jedna vec - co sa stala aj mne pri testovani.. :-)
>>>>>
>>>>> Mozno mate "blbo" napisany ten testovaci kod - v tom zmysle, ze je
>>>>> prekladac
>>>>> hyperinteligentny a zoptimalizuje ten kod tak, ze ked si date vypisat
>>>>> obsah
>>>>> pamati, kam ste predtym zapisali, tak to vlastne vypise iba nieco, co si
>>>>> ten
>>>>> program "pamata" este v registroch (napr.), miesto toho aby sa naozaj
>>>>> pozrel
>>>>> cez TLB a do RAM.... (cache to urcite nebude, pretoze msim ziadnu
>>>>> nesimuluje,
>>>>> afaik :-D)
>>>>>
>>>>> Mohlo by pomoct nastavit ten pointer do pamati ako volatile, alebo medzi
>>>>> zapis
>>>>> a citanie pridat nejaku pointerovu aritmetiku (ptr+=1, -=1) - cim by sa
>>>>> mohla "vypnut" optimalizacia...
>>>>>
>>>>> (Ta optimalizacia ma prave take zaujimave efekty, ze aj ked zapises cislo
>>>>> na
>>>>> uplne nahodnu adresu (napr. neexistujucu pamat v KSEG0), tak ked precitas
>>>>> spat, tak tam ta hodnota bude - aj ked sa nikde do ram nezapisala...)
>>>>>
>>>>> Andrej
>>>>>
>>>>>
>>>>> On Wednesday 05 December 2007 01:40:08 Martin Choma wrote:
>>>>>
>>>>>
>>>>>> Caute,
>>>>>>
>>>>>> riesime jeden zahadny problem. Mame alokovany blok pamete vo virt.
>>>>>> priestore a k nemu alok. blok fyzickej.
>>>>>> Pri pokuse o zapis na virtualnu adresu sa nam vyhlada tlb zaznam so
>>>>>> spravnym mapovanim a zapiseme.
>>>>>> Este vypis premennej hned po tomto zapise vypise spravne priradenu
>>>>>> hodnotu (co moze byt sposobene cache).
>>>>>> Ale ak si vypiseme predchadzajucu premennu, do ktorej sme priradovali,
>>>>>> tak ta obsahuje hodnotu 255
>>>>>> (co je hodnota pri pohlade na fyz. adresu 0xCxxxxxxxx v memory dumpe
>>>>>> msimu). Ked sa pozrieme na danu
>>>>>> fyzicku pamat memory dumpom, tak je skutocne nevyplnena. Ako keby sa
>>>>>> to nezapisovalo alebo zapisovalo
>>>>>> niekam inam. Nenapada niekoho, cim by to mohlo byt? Diky.
>>>>>>
>>>>>> priznaky ksu exl a erl mame nastavene takto;
>>>>>> ksu = 0, exl=0, erl=0
>>>>>>
>>>>>> nase zaznamy v TLB vyzeraju asi takto:
>>>>>>
>>>>>> [0] : Virtual Address=0xc00ec000 ;Even=0x4fd800 [D=1,V=1,G=0];
>>>>>> ODD=0x4fe800 [D=1,V=1,G=0] ; ASID=1
>>>>>> [1] : Virtual Address=0xc00ee000 ;Even=0x4ff800 [D=1,V=1,G=0];
>>>>>> ODD=0x500800 [D=1,V=1,G=0] ; ASID=1
>>>>>> [2] : Virtual Address=0xc00d4000 ;Even=0x4e5800 [D=1,V=1,G=0];
>>>>>> ODD=0x4e6800 [D=1,V=1,G=0] ; ASID=1
>>>>>> [3] : Virtual Address=0xc00e4000 ;Even=0x4f5800 [D=1,V=1,G=0];
>>>>>> ODD=0x4f6800 [D=1,V=1,G=0] ; ASID=1
>>>>>> [4] : Virtual Address=0xc00ea000 ;Even=0x4fb800 [D=1,V=1,G=0];
>>>>>> ODD=0x4fc800 [D=1,V=1,G=0] ; ASID=1
>>>>>> .
>>>>>> .
>>>>>> .
>>>>>>
>>>>>> Martin Choma
>>>>>>
>>>>>> _______________________________________________
>>>>>> OSy mailing list
>>>>>> OSy at dsrg.mff.cuni.cz
>>>>>> https://dsrg.mff.cuni.cz/mailman/listinfo/osy
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> OSy mailing list
>>>>> OSy at dsrg.mff.cuni.cz
>>>>> https://dsrg.mff.cuni.cz/mailman/listinfo/osy
>>>>>
>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> OSy mailing list
>>> OSy at dsrg.mff.cuni.cz
>>> https://dsrg.mff.cuni.cz/mailman/listinfo/osy
>>>
>>>
>> _______________________________________________
>> OSy mailing list
>> OSy at dsrg.mff.cuni.cz
>> https://dsrg.mff.cuni.cz/mailman/listinfo/osy
>>
>>
>
>
>
> _______________________________________________
> OSy mailing list
> OSy at dsrg.mff.cuni.cz
> https://dsrg.mff.cuni.cz/mailman/listinfo/osy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/nswi004/attachments/20071205/7cf3fd70/attachment.html>
More information about the NSWI004
mailing list