[okl4-developer] dcache issue, need some ideas on how to tell kernel to use WT page entries for UTCB

Gabi Voiculescu b304_a at yahoo.com
Wed May 7 18:47:47 EST 2008


Hello

I probably did not make a lot of sense in my last email. It was kind of late. It's kind of late now, so I apologize in advance.

I am having a problem when I'm turning on the L1 dcache on my arm1176 chip and I try to run okl4 2.1. This problem was not evident in the 1.5.2 release, when I used mostly the same code for the platform specific timer and interrupt.

My problem:
There is a communication problem between the kernel and any thread through the system call mechanism.

 Essentially the task (in my case the root task) is trying to use the virtual message registers to communicate with the kernel, but the reply does not get back to the task. 

 I think the root task uses one of the virtual memory cache areas for the UTCB, and virtual registers used in the messaging, and the kernel expects them in the other virtual cache area. Initially they were both writeback, so messages would not pas from the root task to the kernel and back. This would explain why the tests work with the dcache turned off.

  
What I believe to be the solution:
I want to make sure that both the kernel and the root task are using writethrough entries in their page tables, to pass virtual registers from/to UTCBs. One way to fix this would be to set the default page attributes (L4DefaultMemory and l4default) to writethrough, but at the cost of performance, and in the long run I need to fix this.


As you might see, I already changed the 4k entries for UTCB at user level from WB to WT, by making a change into:
utcb_t * generic_space_t::allocate_utcb(tcb_t * tcb) add_mapping function.
but the tests are still failing.

   
 Am I missing anything here? Is there a part of the OKL4 missing from the public release that does this?

Can you think of anything else that could lead to this?




1 -  Right now, I'm trying to find out (and I need some help on this) what is the best way to instruct the kernel to use the WT page entries in the table, for already mapped pages. For instance, I see the UTCB mapped at physical address 0x203000, and that has three entries in the f01026c8 space:

the WB 1MBentry
the WB 4k entry
the WT 1MB entry, 

I would like, without changing a lot of the code, to instruct the kernel to only access UTCB through the WT entries.

2 - Also I'm interested to know if I can find out, in kdb, what is the page table that the kernel (not roottask) sees, and what are the mem attributes for Its page entries.



The output of project=iguana test_libs=all looks like this:
OKL4 - built on May  6 2008 21:38:15 using gcc version 3.4.4.
[startup_system_mmu] sbz=0x0, sb1=0x1
Initialized tracebuffer @ 00240000
Init spaceids for 256 spaces
Initializing kernel space @ f001eb40...
Initializing kernel debugger...
Initializing interrupts...
System running with strict alignment exceptions disabled
System running with unaligned accesses enabled
...
Init mutexids for 256 mutexs
Init clistids for 16 clists
domain pairs: (0, 1)
Initialising scheduler...
Switching to idle thread
Initializing root servers
        root-servers: utcb_area: eff00100 (64KB)
        creating root server (00000001)
--- KD# System started (press 'g' to continue)  ---
> go
roottask write pagefault at 07fff000, ip=00106554 - deny
--- KD# roottask pagefault  ---
> ptab
Space [current]: current
Dumping space 0xf01026c8:
00000000 [00206801]: tree=f4108000
00000000 [00206801]:   tree=f4106800
00000000 [00000000]:     tree=f4106800
00002000 [0012383e]:       phys=00123000 pg=f4106808   4KB rwx (RWX) user    WB
00005000 [0019583e]:       phys=00195000 pg=f4106814   4KB rwx (RWX) user    WB
00010000 [001a083d]:     phys=001a0000 pg=f4106840    64KB rwx (RWX) user    WB
00100000 [00206c01]:   tree=f4106c00
00100000 [0018883e]:     tree=f4106c00
00100000 [0018883e]:       phys=00188000 pg=f4106c00   4KB rwx (RWX) user    WB
00101000 [0018983e]:       phys=00189000 pg=f4106c04   4KB rwx (RWX) user    WB
00102000 [0018a83e]:       phys=0018a000 pg=f4106c08   4KB rwx (RWX) user    WB
00103000 [0018b83e]:       phys=0018b000 pg=f4106c0c   4KB rwx (RWX) user    WB
00104000 [0018c83e]:       phys=0018c000 pg=f4106c10   4KB rwx (RWX) user    WB
00105000 [0018d83e]:       phys=0018d000 pg=f4106c14   4KB rwx (RWX) user    WB
00106000 [0018e83e]:       phys=0018e000 pg=f4106c18   4KB rwx (RWX) user    WB
00107000 [0018f83e]:       phys=0018f000 pg=f4106c1c   4KB rwx (RWX) user    WB
00108000 [0019083e]:       phys=00190000 pg=f4106c20   4KB rwx (RWX) user    WB
00109000 [0019183e]:       phys=00191000 pg=f4106c24   4KB rwx (RWX) user    WB
0010a000 [0019283e]:       phys=00192000 pg=f4106c28   4KB rwx (RWX) user    WB
0010b000 [0019383e]:       phys=00193000 pg=f4106c2c   4KB rwx (RWX) user    WB
0010c000 [0019483e]:       phys=00194000 pg=f4106c30   4KB rwx (RWX) user    WB
00110000 [00000000]:     tree=f4106c40
00114000 [0012283e]:       phys=00122000 pg=f4106c50   4KB rwx (RWX) user    WB
ef000000 [00000000]: tree=f410bbc0
eff00000 [00206401]:   tree=f4106400
eff00000 [0020383a]:     tree=f4106400
eff00000 [0020383a]:       phys=00203000 pg=f4106400   4KB rwx (RWX) user    WT
f0000000 [0010040e]: tree=f410bc00
f0000000 [0010040e]:   phys=00100000 pg=f410bc00       1MB ~~~ (RWX) kernel  WB
f0100000 [0020040e]:   phys=00200000 pg=f410bc04       1MB ~~~ (RWX) kernel  WB
f0200000 [0030040e]:   phys=00300000 pg=f410bc08       1MB ~~~ (RWX) kernel  WB
f0300000 [0040040e]:   phys=00400000 pg=f410bc0c       1MB ~~~ (RWX) kernel  WB
f0400000 [0050040e]:   phys=00500000 pg=f410bc10       1MB ~~~ (RWX) kernel  WB
f4000000 [0010040a]: tree=f410bd00
f4000000 [0010040a]:   phys=00100000 pg=f410bd00       1MB ~~~ (RWX) kernel  WT
f4100000 [0020040a]:   phys=00200000 pg=f410bd04       1MB ~~~ (RWX) kernel  WT
f4200000 [0030040a]:   phys=00300000 pg=f410bd08       1MB ~~~ (RWX) kernel  WT
f4300000 [0040040a]:   phys=00400000 pg=f410bd0c       1MB ~~~ (RWX) kernel  WT
f4400000 [0050040a]:   phys=00500000 pg=f410bd10       1MB ~~~ (RWX) kernel  WT
f9000000 [00200401]: tree=f410be40
f9000000 [00200401]:   tree=f4100400
f9000000 [10000052]:     tree=f4100400
f9000000 [10000052]:       phys=10000000 pg=f4100400   4KB ~~~ (RWX) kernel  NC
f9040000 [10040052]:     tree=f4100500
f9040000 [10040052]:       phys=10040000 pg=f4100500   4KB ~~~ (RWX) kernel  NC
f9041000 [10041052]:       phys=10041000 pg=f4100504   4KB ~~~ (RWX) kernel  NC
f9050000 [10050052]:     tree=f4100540
f9050000 [10050052]:       phys=10050000 pg=f4100540   4KB ~~~ (RWX) kernel  NC
f9051000 [10051052]:       phys=10051000 pg=f4100544   4KB ~~~ (RWX) kernel  NC
f9100000 [00200801]:   tree=f4100800
f9100000 [00000000]:     tree=f4100800
f9104000 [10104052]:       phys=10104000 pg=f4100810   4KB ~~~ (RWX) kernel  NC
f9107000 [10107052]:       phys=10107000 pg=f410081c   4KB ~~~ (RWX) kernel  NC
f910c000 [1010c052]:       phys=1010c000 pg=f4100830   4KB ~~~ (RWX) kernel  NC
f9120000 [10120052]:     tree=f4100880
f9120000 [10120052]:       phys=10120000 pg=f4100880   4KB ~~~ (RWX) kernel  NC
f9121000 [10121052]:       phys=10121000 pg=f4100884   4KB ~~~ (RWX) kernel  NC
f9400000 [00200c01]:   tree=f4100c00
f9400000 [e0000052]:     tree=f4100c00
f9400000 [e0000052]:       phys=e0000000 pg=f4100c00   4KB ~~~ (RWX) kernel  NC
ff000000 [00200001]: tree=f410bfc0
ff000000 [00200001]:   tree=f4100000
ff000000 [0012982e]:     tree=f4100000
ff000000 [0012982e]:       phys=00129000 pg=f4100000   4KB r~x (RWX) user    WB
fff00000 [00201401]:   tree=f4101400
ffff0000 [0012801e]:     tree=f41017c0
ffff0000 [0012801e]:       phys=00128000 pg=f41017c0   4KB ~~~ (RWX) kernel  WB
> listspaces
f001eb40/0:(  1) (idle_thr)
f01026c8/0:(  2) (roottask)
> frame
== Stack frame: f001db58 == 
cpsr = 60000193, pc = f000b024, sp  = f001db58, lr  = f000b024
r0  = f0013728, r1  =        8, r2  = f910c000, r3  =       98, r4  =        1
r5  = f0030000, r6  =  7fff000, r7  =   106554, r8  = f00280a0, r9  =        0
r10 = f00280a0, r11 =        0, r12 =        8

Thank you,
I hope you can help me on this,
Gabi Voiculescu

       
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.okl4.org/pipermail/developer/attachments/20080507/549bdb6d/attachment.htm 


More information about the Developer mailing list