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

[Henry N. <Hen...@Ar...>]

baldyeti wrote:
> Alright Henry first report (I am afraid we'll need
> more testing if you're willing to bear with me)
> 
> On first start I got a straight reboot (no BSOD).
> Sorry I stupidly deleted the debug.xml output.
> Perhaps the new driver needed rebooting to get
> activated ?

No need reboot. But the memory can be corrupted from old driver. A
debugout from bsod would often corruptly. Or have you a networking
debugging?

> Anyway after that I've got the new
> version running *yet* there is this suspicious
> line in debug.xml (whih I am sending to you):
> 
> Bug: PFN too high! 521536 > 491520

This lines comes from reading cpu register cr3 and mapping this memory.
In this area exist your page tables. This area on 2037MB (521536 * 4K).

The error marks "Bug: PFN too high! 521536 > 491520" comes not from
memory allocation. It's from mapping "in used" memory. This is more
false/positive here. You can ignore. But, it was interesting to see
where you have the missing bytes from "2GB minux 128MB", my problem with
1920MB/1940MB values ;-)

I currently not know where you have the memory exactly and where exist
some holes. What I see is you have
1904MB real memory starts at 0
 128MB shared graphic memory starts at 1904MB
 ~16MB memory for page tables starts at 2032MB up to limit 2048MB

Winnt reports you have 1920MB non memory free usable. In your case it is
non continues, it starts from 0, than the 128BM hole and than 16MB.
Now the problem: Colinux "thinks" all memory starts from 0 and checks
this by a limit (1920MB in your case). But we need to check the first
1904MB continues, than remember to skip over the hole and then allow the
last 16MB.

My last changes has not handled the 16MB behind the graphic. So, I'm
badly with diff of 16MB. Because colinux request memory in 65MB hunks
and not acccepts lower sizes (16MB), this helps us to not crash here.

We need a ntkernel function to ask for reserved memory regions inside
the physicaly ram, for example such line from your winmsd:
"0x77000000-0x7EFFFFFF	Motherboard resources"
This memory recources should exclude from colinux memory requests.

The right values in your case should be:
1.) 1904MB (0x77000000) should be the max value for alloating memory.
Currently it is 1920MB = pfn 491520 * 4K.
2.) We should allow to map without error message the pages from 2032MB
to 2048MB.
Currently all pages over 1920MB are marked as error.

> Anyway the rest of our discussion about PCI devices
> and chunks of memory they use or shadow got me wondering.
> Isn't colinux a user-land windows process, and as such
> immune to those low-level, physical RAM layout issues?
> Pardon my ignorance, I can imagine the driver being
> somehow privileged, but I a am curious.

The linux.sys works in ring0, the highest privilege. CoLinux can and
must do anything with cpu. CoLinux frees the cpu completely on evey OS
switch and loads alls from the "other OS" before switched back.

CoLinux gets "free memory" from windows with funktion
"MmAllocatePagesForMdl".
After the memory was allocated, every memory page will be "forward" to
Linux as pseude physicaly ram. We must need to know the physicaly page,
because Linux would map exactly this page to an virtual memory on linux
side.

And *I* wonder why we got a "reserved" memory, that is not free. In
normal case this function gets only free memory that was not allocated
from any other proccess, other drivers or coLinux driver self before.
Under normal cases a call to MmAllocatePagesForMdl gets never the same
memory page again, unless we have freed it before.

BIOS or Windows should not give the reserved memory here us.
Why the graphic driver not gets its memory and prevents colinux from
allocate the same memory again?
Is this a general design problem of coLinux or is this specific to your
board?
 --- needs to study many more on MSDN about memory mapping ---

***

I have also shared graphic memory on my laptop. Never had problems. I
have 512MB real memory and, my 64MB shared graphic starts at 0xE0000000
(at 3584MB). This is far distance from real memory and would never make
a problem.
By the while, all special maps starts at 0x1F000000 (496MB), that is
over my 480MB usable ram area.

Ressource       Device  Status
0xA0000-0xBFFFF PCI-Bus OK
0xA0000-0xBFFFF SiS Accelerated Graphics Port
0xA0000-0xBFFFF SiS 650 OK
0xCB000-0xDFFFF PCI-Bus OK
0xDF000-0xDFFFF O2Micro OZ6912-CardBus-Controller
0x1F000000-0xFFDFFFFF   PCI-Bus OK
0xCFC00000-0xDFCFFFFF   SiS Accelerated Graphics Port
0xD0000000-0xD7FFFFFF   SiS 650
0xDFE00000-0xDFEFFFFF   SiS Accelerated Graphics Port
0xDFEE0000-0xDFEFFFFF   SiS 650
0xDFFF8800-0xDFFF8FFF   VIA OHCI-konformer IEEE 1394-Hostcontroller
0xDFFF9000-0xDFFF9FFF   SiS 900-Based PCI Fast Ethernet Adapter
0xDFFFA000-0xDFFFAFFF   SiS 7001 PCI-zu-USB Open Host-Controller
0xDFFFB000-0xDFFFBFFF   SiS 7001 PCI-zu-USB Open Host-Controller
0xE0000000-0xE3FFFFFF   SiS Accelerated Graphics Port    <=== 64MB vram
0xFBDFE000-0xFFDFDFFF   O2Micro OZ6912-CardBus-Controller
0xFFDFE000-0xFFDFEFFF   O2Micro OZ6912-CardBus-Controller
0xFFDFF000-0xFFDFFFFF   O2Micro OZ6912-CardBus-Controller


***

User land memory is virtual only. The ntkernel can swapout every time.
The real page than would be use by other "task". On next OS switch from
Windows to Linux, than Linux would have a problem. Linux would have this
page mapped and not know that no longer exist now (or filled with other
data). Linux has a self managed mapping. Completely separated from
Windows. All memory paged used by Linux are nonswapable memory. That's
why you can not give coLinux more memory as you have in real build in.

linux.sys swaps the cpu and all memory mappings between an OS switch.
To have non paged memory on Linux side, we use nonpaged pages.

-- 
Henry N.