Re: [coLinux-users] 0.7.2 less reliable on dual core?

[baldyeti <e_...@ho...>]

On 04/03/2008 23:57, Henry Nestler wrote:
 > ...
 > Watch in the WebugView, save the output to log file.

Here's dbgview's output (maybe usenet will mess up the formatting,
let me know if you want the file sent to you)
Note that I haven't actually started colinux, only re-installed
the driver as requested if I understood you correctly.

--------> start of capture <--------
[m:colinux-driver f:0 l:10 
src/colinux/os/winnt/kernel/manager.c:51:co_os_manager_init] Rage[0] 
0x1000 0x9d000 (643072 MB)
colinux-debug: section created: sections: 1, total: 4096, filled: 0
[m:colinux-driver f:0 l:10 
src/colinux/os/winnt/kernel/manager.c:51:co_os_manager_init] Rage[1] 
0x100000 0xeff000 (15724544 MB)
[m:colinux-driver f:0 l:10 
src/colinux/os/winnt/kernel/manager.c:51:co_os_manager_init] Rage[2] 
0x1000000 0x76000000 (1979711488 MB)
[m:colinux-driver f:0 l:10 
src/colinux/os/winnt/kernel/manager.c:51:co_os_manager_init] Rage[3] 
0x7f000000 0xdf0000 (14614528 MB)
[m:colinux-driver f:0 l:10 
src/colinux/kernel/reversedpfns.c:30:co_manager_alloc_reversed_pfns] 
allocating reversed physical mapping for 491520 pages
[m:colinux-driver f:0 l:10 
src/colinux/kernel/reversedpfns.c:34:co_manager_alloc_reversed_pfns] 
allocating top level pages map (1920 bytes)
[m:colinux-driver f:0 l:10 
src/colinux/kernel/reversedpfns.c:41:co_manager_alloc_reversed_pfns] 
allocating 480 top level pages
[m:colinux-driver f:0 l:10 
src/colinux/os/winnt/kernel/alloc.c:49:co_winnt_new_mdl_bucket] Limit 
page request to 0x78000000
[m:colinux-driver f:0 l:10 
src/colinux/kernel/reversedpfns.c:56:co_manager_alloc_reversed_pfns] 
using 4 table entries for reversed physical mapping
--------> end of capture <--------

> Last please verify these ranges with the Registry. It should be the
> same: Run regedit.exe and open key
> "HKEY_LOCAL_MACHINE\HARDWARE\RESOURCEMAP\System Resources\Physical Memory"
> Double click on key ".Translated", select  "intern" and than the button
> "view". The output is not very nice, is scroll area with 2 lines only.

I my case there are 4 entries:
Phys addre	Length
0x001000	0x9d000
0x100000	0xeff00
0x1000000	0x76000000
0x7f000000	0xdf0000

All blocks have R/W access.
I think I copied those right, they're identical to the 4 dbgview
output lines indeed.

--bald