colinux-users — coLinux users mailing list

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

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

Henry Nestler wrote:
> baldyeti wrote:
>> 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.

This has interesting comments, we need to know:
http://www.jungo.com/support/tech_docs/td129.html

MmGetPhysicalMemoryRanges should use to get the usable memory ranges, or
the highest usable physicaly page. I will try some with this function.

I know, MmGetPhysicalMemoryRanges and MmGetPhysicalMemoryRanges are
reserved and non official documented by MS. Bu, we use
MmGetPhysicalMemoryRanges and can not change it for now in fast way. So
we also need to use MmGetPhysicalMemoryRanges to get the "usable" list
of memory here.

-- 
Henry N.

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.

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

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

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 ? 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

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.

--bald

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

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

baldyeti wrote:
>>>> Have you other devices, that used memory regions over 2GB?

Not over. I can see inside 2GB here ;-(

> "winmsd" makes it easy to get that information in plain text:
> 
> [Memory]
> 
> Resource	Device	Status	
> 0xA0000-0xBFFFF	PCI bus
> 0xA0000-0xBFFFF	NVIDIA GeForce 7100 / NVIDIA nForce 630i
> 0xC0000-0xDFFFF	PCI bus

... ok. normal low memory and text graphic.

> 0x7FF00000-0xFEBFFFFF	PCI bus

... an other hole at 2047MB (of 2048 you have)

> 0x77000000-0x7EFFFFFF	Motherboard resources

... this are 128MB at 1904MB. Think, it's your graphic memory.

> 0x0000-0x9FFFF	System board
> 0x100000-0x7FEEFFFF	System board

... 2046MB (2GB minus a 1MB PCI hole, minus the 1MB low memory)

I'm not shure, is the max PFN now 0x77000000 (1904MB), or 0x77000000
minus 1MB, or 1920MB (2GB - 128MB)?

I can not say, what is right.
The workarround would set the value to 1920MB in your case. If that not
helps, we need to find a way to exclude such "Motherboard resources" in
middle of the memory. Or limit the PFN to some value or manualy.

-- 
Henry N.

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

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

baldyeti wrote:
>> Here an other build:
>> http://www.henrynestler.com/colinux/testing/pfn-check-0.7.3/20080303-pfn-check/workarround/
>>
>> There have limited the memory to the value we got from ntkernel (1920 in
>> your case). With that workarround coLinux should run on your machine :-)
> 
> Does this build override the other one, or are you trying
> another fix? Is the 1920MB value hard-coded?

The older build has only bugchecks and would help to find the buggy
function. I'm feel 99% it is "MmAllocatePagesForMdl". But, not shure.

This build has bugchecks and additional a workarround on this function.

No, is not hard coded. :-o Is getting from your system, you have seen as
"491520". This value will be forwarded to the allocation function. I'm
afraid, we tap in a M$ bug.

-- 
Henry N.

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

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

> Your left values are in the memory between 1920MB and 2048MB.

Good detective work!

> But should not! That's your graphic card. Why this area is not reserved
> by graphic card driver?

Er I wish I knew! It's an nvidia 7100 IGP (aka MCP73) and
performed correctly for the last three months under windows
mostly (and also linux but for shorter periods i am sorry
to report ;-)

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

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

>>> Have you other devices, that used memory regions over 2GB?
>> Sorry, don't know where to look...
> 
> I have only a german view:
> http://home.arcor.de/henryn/colinux/screenshoots/Device-manager-recource-memory.png
> 
"winmsd" makes it easy to get that information in plain text:

[Memory]

Resource	Device	Status	
0xA0000-0xBFFFF	PCI bus
0xA0000-0xBFFFF	NVIDIA GeForce 7100 / NVIDIA nForce 630i
0xC0000-0xDFFFF	PCI bus
0x7FF00000-0xFEBFFFFF	PCI bus
0xFEFF0000-0xFEFF03FF	High precision event timer
0xE5108000-0xE5108FFF	Standard OpenHCD USB Host Controller
0xE5107000-0xE51070FF	Standard Enhanced PCI to USB Host Controller
0xE5100000-0xE5103FFF	Microsoft UAA Bus Driver for High Definition Audio
0xE5004000-0xE50047FF	Texas Instruments OHCI Compliant IEEE 1394 Host 
Controller
0xE5000000-0xE5003FFF	Texas Instruments OHCI Compliant IEEE 1394 Host 
Controller
0xE5104000-0xE5105FFF	NVIDIA nForce Serial ATA Controller
0xE5109000-0xE5109FFF	NVIDIA Network Bus Enumerator
0xE510A000-0xE510A0FF	NVIDIA Network Bus Enumerator
0xE5106000-0xE510600F	NVIDIA Network Bus Enumerator
0xE2000000-0xE2FFFFFF	NVIDIA GeForce 7100 / NVIDIA nForce 630i
0xD0000000-0xDFFFFFFF	NVIDIA GeForce 7100 / NVIDIA nForce 630i
0xE3000000-0xE3FFFFFF	NVIDIA GeForce 7100 / NVIDIA nForce 630i
0xFEFE0000-0xFEFE01FF	Motherboard resources
0xFEFE1000-0xFEFE10FF	Motherboard resources
0x77000000-0x7EFFFFFF	Motherboard resources
0xE0000000-0xE1FFFFFF	Motherboard resources
0xD2800-0xD3FFF	System board
0xF0000-0xF7FFF	System board
0xF8000-0xFBFFF	System board
0xFC000-0xFFFFF	System board
0x7FEF0000-0x7FEFFFFF	System board
0xFFFF0000-0xFFFFFFFF	System board
0x0000-0x9FFFF	System board
0x100000-0x7FEEFFFF	System board
0xFEC00000-0xFEC00FFF	System board
0xFEE00000-0xFEE00FFF	System board

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

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

> Here an other build:
> http://www.henrynestler.com/colinux/testing/pfn-check-0.7.3/20080303-pfn-check/workarround/
> 
> There have limited the memory to the value we got from ntkernel (1920 in
> your case). With that workarround coLinux should run on your machine :-)

Does this build override the other one, or are you trying
another fix? Is the 1920MB value hard-coded?

> Please test this, and give an result.

Will do, thank you!

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

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

> 
> Here is a special build:
> http://www.henrynestler.com/colinux/testing/pfn-check-0.7.3/20080303-pfn-check/
> 

Thanks Henry, I'll try this and report back.
Might take a while, though.

Cheers,

--bald

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

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

Henry Nestler wrote:
> Henry Nestler wrote:
>> Hello baldyeti,
>>
>>>> Anyway it had the following:
>>>>
>>>> 	PFN too high! 523367 >= 491520
>>>> and
>>>> 	PFN too high! 523444 >= 491520
>>> For left value have no idea.
>>> The right value seems me ok. 491520 * 4K = 2013265920 Bytes (1920 MB)
>>> This are the 2GB minus your graphic card.
> 
> Some calcutations for left value
> 2GB = 2048MB = 2147483648 Bytes
> PFN max for all memory = 2GB / 4K - 1
> PFN max for all memory = 524287
> PFN max for usable memory = (2GB - 128MB) / 4K - 1
> PFN max for usable memory = 491520
> Your left values are in the memory between 1920MB and 2048MB.
> But should not! That's your graphic card. Why this area is not reserved
> by graphic card driver?
> 

Here an other build:
http://www.henrynestler.com/colinux/testing/pfn-check-0.7.3/20080303-pfn-check/workarround/

There have limited the memory to the value we got from ntkernel (1920 in
your case). With that workarround coLinux should run on your machine :-)

Please test this, and give an result.
Please remember to reload the driver, before you starts this build!

  colinux-daemon.exe --remove-driver
  colinux-daemon.exe --status-driver   <<--- should say not installed
  colinux-daemon.exe --install-driver
  colinux-daemon.exe --status-driver   <<--- should say:
       Driver compiled on: Mon Mar  3 22:05:55 2008

-- 
Henry N.

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

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

Henry Nestler wrote:
> Hello baldyeti,
> 
>>> Anyway it had the following:
>>>
>>> 	PFN too high! 523367 >= 491520
>>> and
>>> 	PFN too high! 523444 >= 491520
>> For left value have no idea.
>> The right value seems me ok. 491520 * 4K = 2013265920 Bytes (1920 MB)
>> This are the 2GB minus your graphic card.

Some calcutations for left value
2GB = 2048MB = 2147483648 Bytes
PFN max for all memory = 2GB / 4K - 1
PFN max for all memory = 524287
PFN max for usable memory = (2GB - 128MB) / 4K - 1
PFN max for usable memory = 491520
Your left values are in the memory between 1920MB and 2048MB.
But should not! That's your graphic card. Why this area is not reserved
by graphic card driver?

-- 
Henry N.

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

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

Henry Nestler wrote:
> Hello baldyeti,
> 
>>> Anyway it had the following:
>>>
>>> 	PFN too high! 523367 >= 491520
>>> and
>>> 	PFN too high! 523444 >= 491520
>> For left value have no idea.
>> The right value seems me ok. 491520 * 4K = 2013265920 Bytes (1920 MB)
>> This are the 2GB minus your graphic card.
> 
> This can be a bug in memory allocation. Perhaps a race condition. I will
> add some bug checks near this code and send a special version later.
> 

One interesting found.
http://msdn2.microsoft.com/en-us/library/ms802812.aspx

We use MmAllocatePagesForMdl. MSDN says, that it can allocate AGP
memory. That is graphic mem. Can this the probleme here, because you
have shared memory for your graphic card? Give ntkernel such memory to
colinux?

Currenty we use HighAddress = 0x100000000
Should we use the system max mem here? (1920 MB in your case)

Here is a special build:
http://www.henrynestler.com/colinux/testing/pfn-check-0.7.3/20080303-pfn-check/

I have added many bugchecks near the memory allocations. Please run this
on your system with debug-daemon and give me all the lines you found
with "Bug: " and the "PFN". Please, complete XML lines with location to
the source code.

Before you starts colinux, please run the debuger:
   del debug.xml
   colinux-debug-daemon.exe -p -d -s prints=31,misc=31 -f debug.xml

-- 
Henry N.

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

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

Hello baldyeti,

>> Anyway it had the following:
>>
>> 	PFN too high! 523367 >= 491520
>> and
>> 	PFN too high! 523444 >= 491520
> 
> For left value have no idea.
> The right value seems me ok. 491520 * 4K = 2013265920 Bytes (1920 MB)
> This are the 2GB minus your graphic card.

This can be a bug in memory allocation. Perhaps a race condition. I will
add some bug checks near this code and send a special version later.

-- 
Henry N.

Re: [coLinux-users] Fedora 7 has been identified with Toroyan virus !!

[wathavy w. <wa...@ya...>]

Hi, Henry.
Thank you.
So, something not right with my AVG 7.5 side,then.
I try to use your newly indicated download.
Thank you again.

Toshi.

Henry Nestler wrote:
Have tested with f-prot scanner
  Antivirus Scanning Engine version number: 4.4.2
  Virus signature file from: 29.02.2008, 20:55

[Found possible archive bomb]  
D:\Download\Fedora-7-20070718.exe->(RAR)

A trojan not found. Says only, some about archive bomp. That is truely
normal because it contains a big image file.

The file Fedora-7-20070906 is totaly clean.

> By the while, on SF exist a newer file:
> http://downloads.sourceforge.net/colinux/Fedora-7-20070906.exe

Here are my MD5 checksums:
14cb6df2f709e5ec855795f737162a33 *Fedora-7-20070718.exe
  (downloaded from SF today)

f7fb1ce864c13aa92862b66973e9a0ce *Fedora-7-20070906.exe
  (downloaded from SF at 09 Nov 2006)

-- 
Henry N.


       
---------------------------------
Never miss a thing.   Make Yahoo your homepage.

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

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

baldyeti wrote:
>> What physicaly memory recource used your graphics card?
> 
> It's an integrated controller, using 128 MB of shared RAM.
> 
>> Have you other devices, that used memory regions over 2GB?
> 
> Sorry, don't know where to look...

I have only a german view:
http://home.arcor.de/henryn/colinux/screenshoots/Device-manager-recource-memory.png

Press keys LeftWinMenu + Pause
Register: Hardware
Button: Device Manager
Menu: View
Pulldownmenu: Recources sorted from type

Than open the tree memory or RAM

>> Limit the memory size to 1GB, /maxmem=1024 in C:\boot.ini. Better?
> 
> Actually that seemed to help indeed. I'll do another longer
> test, but that wouldn't really be a satisfactory solution,
> would it? Note that this is a single 2GB chip (plus memtest
> has not pointed to faulty RAM anyway)

Ok. I think, is a problem between 1GB and 2GB. Perhaps with the 128MB
shared memory. Set the limit some steps highter. Go stepwide highter
starts with 1536 (2GB-512BM), than 1792 (2048-256) and last 1920 (2048-128).

>> Disable PAE in boot.ini. Or if PAE is enabled, enable it. Better?
> 
> PAE was enabled. I had to include "/nopae /noexecute=alwaysoff" to
> disable it. At first (over 24h) this seemed to help but unfortunately
> it crashed again later on. Directly after rebooting I started lots
> of application to have over 1GB taken, and colinux failed after 2 or
> 3 successfull launches...

/noexecute=alwaysoff is no longer needed. It is solved any time.
Because /nopae also crashes, yoiu can remove it away an use PAE defaults.

>> The output from line 34 would be interesting. Fails it with constant or
>> random values? Is it one count over the range, or totaly badly?
>> Start
>>   colinux-debug-daemon.exe -p -d -s prints=31,misc=31 -f debug.xml
>> Than start colinux.
>> If the error comes again, grep for the text "PFN too high" and lets see
>> values here.
> 
> Weird file format that one ?!? There's semi-binary data at first
> then an empty xml section at the end.

The XML should be only text format, if the daemon properly closed the
file (without BSOD crash). Have you removed the older output from
crashing, before starts the debug daemon appends?

> Anyway it had the following:
> 
> 	PFN too high! 523367 >= 491520
> and
> 	PFN too high! 523444 >= 491520

For left value have no idea.
The right value seems me ok. 491520 * 4K = 2013265920 Bytes (1920 MB)
This are the 2GB minus your graphic card.

-- 
Henry N.

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

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

> What physicaly memory recource used your graphics card?

It's an integrated controller, using 128 MB of shared RAM.

> Have you other devices, that used memory regions over 2GB?

Sorry, don't know where to look...

> Limit the memory size to 1GB, /maxmem=1024 in C:\boot.ini. Better?

Actually that seemed to help indeed. I'll do another longer
test, but that wouldn't really be a satisfactory solution,
would it? Note that this is a single 2GB chip (plus memtest
has not pointed to faulty RAM anyway)

> Disable PAE in boot.ini. Or if PAE is enabled, enable it. Better?

PAE was enabled. I had to include "/nopae /noexecute=alwaysoff" to
disable it. At first (over 24h) this seemed to help but unfortunately
it crashed again later on. Directly after rebooting I started lots
of application to have over 1GB taken, and colinux failed after 2 or
3 successfull launches...

> The output from line 34 would be interesting. Fails it with constant or
> random values? Is it one count over the range, or totaly badly?
> Start
>   colinux-debug-daemon.exe -p -d -s prints=31,misc=31 -f debug.xml
> Than start colinux.
> If the error comes again, grep for the text "PFN too high" and lets see
> values here.

Weird file format that one ?!? There's semi-binary data at first
then an empty xml section at the end. Anyway it had the following:

	PFN too high! 523367 >= 491520
and
	PFN too high! 523444 >= 491520

> You not need to start linux completely, please trimm down parameters for
> all test as follow:
>   colinux-daemon kernel=vmlinux initrd=initrd.gz root=/dev/ram0 mem=160

Thanks for your time,

--bald

[coLinux-users] help with networking

[Richard D. M. <mo...@mi...>]

I've read several guides to getting this working, but to no avail. I 
installed CoLinux 0.7.2 with the Ubuntu 6.06 image, and the OS boots 
fine. I also installed WinPcap, and am trying to get coLinux configured 
so that I can use the network. So far, nothing works. I've used 
Wireshark to confirm that the net packets are being sent from Colimux, 
but it looks like Colinux is not recognizing any responses.

So far, my configuration is eth0 - winPcap, and eth1 - taptun. I can't 
get either working. Here are more details:

My wireless card is an Intel(R) PRO/Wireless 3945ABG, running on Vista 
Home Premium.


router : 192.168.254.254, 00:17:3f:df:94:d3
host   : 192.168.254.2  , 00:19:d2:78:ca:91
colinux: 192.168.254.40 , 19:00:d2:78:ca:91

Pinging the router
$ ping 192.168.254.254

Message in Colinux (Ubuntu 6):
PING 192.168.254.254 (192.168.254.254) 56(84) bytes of data.
 From 192.168.254.40 icmp_seq=2 Destination Host Unreachable

Message in Wireshark (host computer, Vista):
5527	2159.993941	19:00:d2:78:ca:91	Broadcast	ARP	Who has 
192.168.254.254?  Tell 192.168.254.40
5528	2160.127706	Intel_78:ca:91	Belkin_df:94:d3	ARP	Who has 
192.168.254.254?  Tell 192.168.254.2
5529	2160.128808	Belkin_df:94:d3	Intel_78:ca:91	ARP	192.168.254.254 is 
at 00:17:3f:df:94:d3



Pinging the host computer
$ ping 192.168.254.2

Message in Colinux (Ubuntu 6):
PING 192.168.254.2 (192.168.254.2) 56(84) bytes of data.
 From 192.168.254.40 icmp_seq=2 Destination Host Unreachable

Message in Wireshark (host computer, Vista):
5805	2307.564346	192.168.254.40	192.168.254.2	ICMP	Echo (ping) request
5806	2308.564364	19:00:d2:78:ca:91	Intel_78:ca:91	ARP	Who has 
192.168.254.2?  Tell 192.168.254.40
5807	2308.564397	Intel_78:ca:91	19:00:d2:78:ca:91	ARP	192.168.254.2 is 
at 00:19:d2:78:ca:91


################Line from colinux.conf:

eth0=pcap-bridge,"Wireless Network Connection",19:00:D2:78:CA:91
eth1=tuntap

##############
$ifconfig

eth0      Link encap:Ethernet  HWaddr 19:00:D2:78:CA:91
           inet addr:192.168.254.40  Bcast:192.168.255.255  Mask:255.255.0.0
           inet6 addr: fe80::1b00:d2ff:fe78:ca91/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:120 errors:0 dropped:0 overruns:0 frame:0
           TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:14881 (14.5 KiB)  TX bytes:258 (258.0 b)
           Interrupt:2

eth1      Link encap:Ethernet  HWaddr 00:FF:BC:42:80:00
           inet addr:10.0.0.2  Bcast:10.0.0.255  Mask:255.255.255.0
           inet6 addr: fe80::2ff:bcff:fe42:8000/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:112 errors:0 dropped:0 overruns:0 frame:0
           TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:14348 (14.0 KiB)  TX bytes:594 (594.0 b)
           Interrupt:2

lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           inet6 addr: ::1/128 Scope:Host
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:3 errors:0 dropped:0 overruns:0 frame:0
           TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:336 (336.0 b)  TX bytes:336 (336.0 b)

##############################3

snippet of ipconfig on host (Local Area Connection 4 is TAP)

Ethernet adapter Local Area Connection 4:

    Connection-specific DNS Suffix  . :
    Link-local IPv6 Address . . . . . : fe80::8006:1c97:617e:888e%34
    IPv4 Address. . . . . . . . . . . : 10.0.0.1
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Default Gateway . . . . . . . . . :

Wireless LAN adapter Wireless Network Connection:

    Connection-specific DNS Suffix  . : moreyhome
    Link-local IPv6 Address . . . . . : fe80::15ff:8a36:2293:3087%9
    IPv4 Address. . . . . . . . . . . : 192.168.254.2
    Subnet Mask . . . . . . . . . . . : 255.255.0.0
    Default Gateway . . . . . . . . . : 192.168.254.254


-- 
Richard D. Morey, M.A.
Research Assistant, Perception and Cognition Lab
University of Missouri-Columbia

Re: [coLinux-users] Fedora 7 has been identified with Toroyan virus !!

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

Henry Nestler wrote:
> wathavy wathavy wrote:
>> HI, I just tried out Fedora 7.0 core.
>> And I happened to have it detected with AVG 7.5 that the exe file is
>> infected with toroyan virus vault.
>> http://www.postimage.org/image.php?v=aVRrO8A
> 
> I can not believe. Have you checked it with an second scanner?
> I'm yust downloading to check it. Please wait.

Have tested with f-prot scanner
  Antivirus Scanning Engine version number: 4.4.2
  Virus signature file from: 29.02.2008, 20:55

[Found possible archive bomb] 	<RAR Bomb (not disinfectable)>
D:\Download\Fedora-7-20070718.exe->(RAR)

A trojan not found. Says only, some about archive bomp. That is truely
normal because it contains a big image file.

The file Fedora-7-20070906 is totaly clean.

> By the while, on SF exist a newer file:
> http://downloads.sourceforge.net/colinux/Fedora-7-20070906.exe

Here are my MD5 checksums:
14cb6df2f709e5ec855795f737162a33 *Fedora-7-20070718.exe
  (downloaded from SF today)

f7fb1ce864c13aa92862b66973e9a0ce *Fedora-7-20070906.exe
  (downloaded from SF at 09 Nov 2006)

-- 
Henry N.

Re: [coLinux-users] Fedora 7 has been identified with Toroyan virus !!

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

wathavy wathavy wrote:
> HI, I just tried out Fedora 7.0 core.
> And I happened to have it detected with AVG 7.5 that the exe file is
> infected with toroyan virus vault.
> http://www.postimage.org/image.php?v=aVRrO8A

I can not believe. Have you checked it with an second scanner?
I'm yust downloading to check it. Please wait.

By the while, on SF exist a newer file:
http://downloads.sourceforge.net/colinux/Fedora-7-20070906.exe

-- 
Henry N.

Re: [coLinux-users] TAP-Win32 INSATLL(please confirm Windows-Logo Test) ---> And Stalled.

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

wathavy wathavy wrote:
> Hi, the installer stalled at this state.
> The installing dialog is shown below.
> http://www.postimage.org/image.php?v=aVPoaHS
> 
> Now I waited almost an hour, what I can do is to terminate the
> installation process.
> Any idea or suggestion to avoid having this installation issue?

Have seen, you found a way.

For all other users: A popup window from windows system is sometimes
behind exactly the installer window. Move the Installer windows to oter
place on your desktop, to see the window behind.

Windows is waiting for accept this:
http://www.henrynestler.com/colinux/screenshoots/tap32-win-logo-testing.png

In this screen should click to the "Continue Anyway".

-- 
Henry N.

[coLinux-users] Fedora 7 has been identified with Toroyan virus !!

[wathavy w. <wa...@ya...>]

HI, I just tried out Fedora 7.0 core.
And I happened to have it detected with AVG 7.5 that the exe file is infected with toroyan virus vault.
http://www.postimage.org/image.php?v=aVRrO8A
Please check the file.
Thank you.

       
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.

Re: [coLinux-users] TAP-Win32 INSATLL(please confirm Windows-Logo Test) ---> And Stalled.

[wathavy w. <wa...@ya...>]

Hi, Somehow I restarted and succeeded.
Thank you.

       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

[coLinux-users] TAP-Win32 INSATLL(please confirm Windows-Logo Test) ---> And Stalled.

[wathavy w. <wa...@ya...>]

Hi, the installer stalled at this state.
The installing dialog is shown below.
http://www.postimage.org/image.php?v=aVPoaHS

Now I waited almost an hour, what I can do is to terminate the installation process.
Any idea or suggestion to avoid having this installation issue?

Thank you for your attention.

       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

Re: [coLinux-users] LVM over DM-CRYPT ??

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

Wael Nasreddine wrote:
> This One Time, at Band Camp, Henry Nestler <Hen...@Ar...> said, On Thu, Feb 28, 2008 at 09:41:11PM +0100:
>> Wael Nasreddine wrote:
>>> I currently dual or actually tripple boot Windows XP with Gentoo linux
>>> and Arch Linux, my hard disk is partitioned as following:
> 
>>> /dev/sda1       10G         Fat32       Windows XP
>>> /dev/sda2       100M        ext2        /boot partition
>>> /dev/sda3       110G        DM-CRYPT
> 
>>> the /dev/sda3 is an encrypted partition ( LUKS Encrypted.. ), over it
>>> I have an LVM array with 12 LVs 2 of them are gentoo and arch roots, I
>>> have home, 2 swap etc...
> 
>>> is there a way I can boot Gentoo or Arch from the LVM array ( that is
>>> over DM-CRYPT ) with coLinux.... it would be excellent if I could boot
>>> it because I'm really annoyed that I can't access any of LVMed
>>> partition from windows, I have to reboot If I want one file... I also
>>> miss Mutt...
> 
>> Yes, this should go. Some user have a raid setup running. So your LVM is
>> similar.
> 
>> You need colinux with LVM and DM-Crypt supprt (as module or kernel build
>> in). I not know, what modules you need. Please check the kernel config
>> [1]. "CONFIG_DM_CRYPT=m" I can see there. But not know what else you need.
> 
>> You need manualy change the initrd for this. Basic steps are:
>> - unpack (gunzip and cpio) the boot/initrd from your native Gentoo boot
>> - View into th file linuxrc, and check how an what modules are
>> installed. (modprobe or insmod)
>> - Locate the modules path inside the initrd (lib/modules/...)
>> - Remove all non coLinux modules. Replace/Add all modules you need with
>> coLinux version.
>> - create the gzipped cpio initrd from the tree now.
>> - Use the new initrd as "initrd=..." for colinux boot.
>> - For the first start should run with non graphical runlevel, add "init
>> 2" into the colinux config as kernel command line.
> 
>> The partition should configure as alias in coLinux config, for example:
>>   sda3=\Device\Harddisk0\Partition3
> 
>> [1]
>> http://colinux.svn.sourceforge.net/svnroot/colinux/branches/devel/conf/linux-2.6.22.18-config
> 
> Okay I see what I should do, but What if I used the Gentoo
> kernel/initrd I have in gentoo for coLinux, would it work?? I'm going
> to try it but tonight when I'll be home, I'll try it and report back
> the results....

The coLinux initrd has only one script to copy modules into a root
filesystem. But your rootfs is encrypted. So, the simple "mount" would
no work in your case.

The Gentoo initrd must have some more programs to load modules and
activate the LVM and encryption. I think and hope. But Gentoo initrd
would have wrong module version (from non coLinux kernel). That's why
modules should have to replace.
And, don't try to use the Gentoo kernel. That would alltimes crash with
BSOD.

-- 
Henry N.

Re: [coLinux-users] LVM over DM-CRYPT ??

[Wael N. <wa...@na...>]

This One Time, at Band Camp, Henry Nestler <Hen...@Ar...> said, On Thu, Feb 28, 2008 at 09:41:11PM +0100:
> Wael Nasreddine wrote:
> > I currently dual or actually tripple boot Windows XP with Gentoo linux
> > and Arch Linux, my hard disk is partitioned as following:

> > /dev/sda1       10G         Fat32       Windows XP
> > /dev/sda2       100M        ext2        /boot partition
> > /dev/sda3       110G        DM-CRYPT

> > the /dev/sda3 is an encrypted partition ( LUKS Encrypted.. ), over it
> > I have an LVM array with 12 LVs 2 of them are gentoo and arch roots, I
> > have home, 2 swap etc...

> > is there a way I can boot Gentoo or Arch from the LVM array ( that is
> > over DM-CRYPT ) with coLinux.... it would be excellent if I could boot
> > it because I'm really annoyed that I can't access any of LVMed
> > partition from windows, I have to reboot If I want one file... I also
> > miss Mutt...

> Yes, this should go. Some user have a raid setup running. So your LVM is
> similar.

> You need colinux with LVM and DM-Crypt supprt (as module or kernel build
> in). I not know, what modules you need. Please check the kernel config
> [1]. "CONFIG_DM_CRYPT=m" I can see there. But not know what else you need.

> You need manualy change the initrd for this. Basic steps are:
> - unpack (gunzip and cpio) the boot/initrd from your native Gentoo boot
> - View into th file linuxrc, and check how an what modules are
> installed. (modprobe or insmod)
> - Locate the modules path inside the initrd (lib/modules/...)
> - Remove all non coLinux modules. Replace/Add all modules you need with
> coLinux version.
> - create the gzipped cpio initrd from the tree now.
> - Use the new initrd as "initrd=..." for colinux boot.
> - For the first start should run with non graphical runlevel, add "init
> 2" into the colinux config as kernel command line.

> The partition should configure as alias in coLinux config, for example:
>   sda3=\Device\Harddisk0\Partition3

> [1]
> http://colinux.svn.sourceforge.net/svnroot/colinux/branches/devel/conf/linux-2.6.22.18-config

Okay I see what I should do, but What if I used the Gentoo
kernel/initrd I have in gentoo for coLinux, would it work?? I'm going
to try it but tonight when I'll be home, I'll try it and report back
the results....

Thanks

-- 
Wael Nasreddine
http://wael.nasreddine.com
PGP: 1024D/C8DD18A2 06F6 1622 4BC8 4CEB D724  DE12 5565 3945 C8DD 18A2

.: An infinite number of monkeys typing into GNU emacs,
   would never make a good program. (L. Torvalds 1995) :.