From: baldyeti <e_...@ho...> - 2008-02-24 20:25:04
|
Hello, I am not sure this is the place to post bug reports, bu anyway here's my story. I've been using colinux for the past 2-3 years. I had very good (stable) results when my system was an aging (5yrs) Athlon system (0.6.x then 0.7.1 starting an installed debian) ABout 3 months ago I built myself a new pentium dual-core based system, and I am sorry to report that colinux started to misbehave. I initially used 0.7.1 to start an etch installation, but things haven't improved with 0.7.2 (0.7.3 untested yet) What I am seeing is that if I start colinux early after i log into XP Pro, it generally will work fine (like it pretty much always did on the older single core system). If I try starting colinux later, it will often fail, displaying the error message copied below. On occasions, it will completely crash the systm - I don't even get the BSOD - just a straight reboot! This may have nothing to do with the processor change, please let me know what systematic tests might help. Thanks for your attention, --bald ---------> error message below <--------- C:\Apps\coLinux>C:\Apps\coLinux\colinux-daemon.exe kernel=vmlinux mem=160 sda4=\Device\Harddisk0\Partition3 sda7=\Device\Harddisk0\Partition6 sda8=\Device\Harddisk0\Partition7 sda9=\Device\Harddisk0\Partition8 root=/dev/sda4 eth0=tuntap cofs0=C:\ cofs1=D:\ Cooperative Linux Daemon, 0.7.2 Compiled on Jan 18 2008 21:47:09 error loading image daemon: exit code 89a09401 daemon: error - CO_RC_ERROR_ERROR, line 37, file src/colinux/kernel/pages.c (77) |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-02-24 23:34:35
|
baldyeti wrote: > Hello, > > I am not sure this is the place to post bug reports, > bu anyway here's my story. I've been using colinux > for the past 2-3 years. I had very good (stable) > results when my system was an aging (5yrs) Athlon > system (0.6.x then 0.7.1 starting an installed debian) > > ABout 3 months ago I built myself a new pentium > dual-core based system, and I am sorry to report that > colinux started to misbehave. I initially used 0.7.1 > to start an etch installation, but things haven't > improved with 0.7.2 (0.7.3 untested yet) > > What I am seeing is that if I start colinux early > after i log into XP Pro, it generally will work fine > (like it pretty much always did on the older single > core system). If I try starting colinux later, it > will often fail, displaying the error message copied below. > On occasions, it will completely crash the systm - I > don't even get the BSOD - just a straight reboot! > This may have nothing to do with the processor change, > please let me know what systematic tests might help. > > Thanks for your attention, > > --bald > > ---------> error message below <--------- > C:\Apps\coLinux>C:\Apps\coLinux\colinux-daemon.exe kernel=vmlinux > mem=160 sda4=\Device\Harddisk0\Partition3 > sda7=\Device\Harddisk0\Partition6 sda8=\Device\Harddisk0\Partition7 > sda9=\Device\Harddisk0\Partition8 root=/dev/sda4 eth0=tuntap > cofs0=C:\ cofs1=D:\ > > Cooperative Linux Daemon, 0.7.2 > Compiled on Jan 18 2008 21:47:09 > > error loading image > daemon: exit code 89a09401 > daemon: error - CO_RC_ERROR_ERROR, line 37, file > src/colinux/kernel/pages.c (77) This error let me think, the memory (RAM) is unstable. Or any driver or coLinux driver self changed the area of coLinux variables. Try one of my ideas step by step: Check the memory with memtest86. Change the memory speed slower in bios settings. Can you change the memory or CPU cache settings inside the bios? Try to disable the cache. Can you temporaly disable one core? Diable the Online-Virus-Scanner, if you have. How many RAM do you have? Have you shared memory for graphic card? Ones heared from buggy graphic driver. What is exactly the cpu model? "cat /proc/cpuinfo" Ask Google for memory/chache problems on such cpu models. For debugging, follow http://colinux.svn.sourceforge.net/svnroot/colinux/branches/devel/doc/debugging -- Henry N. |
From: baldyeti <e_...@ho...> - 2008-02-25 02:58:35
|
Thanks Henry > How many RAM do you have? Have you shared memory for graphic card? Ones > heared from buggy graphic driver. 2Gb total. The IGP (nvidia 7100) has 128 Mb allocated. > What is exactly the cpu model? "cat /proc/cpuinfo" processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Pentium(R) Dual CPU E2180 @ 2.00GHz stepping : 13 cpu MHz : 2000.000 cache size : 1024 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni mon itor ds_cpl est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 4731.69 clflush size : 64 There is no overclocking applied, all default BIOS settings. The machine has been very stable so far under XP. I'll try your other suggestions and report back. |
From: baldyeti <e_...@ho...> - 2008-02-27 21:33:44
|
> Try one of my ideas step by step: > Check the memory with memtest86. Done, for over 24h with no error detected. > Change the memory speed slower in bios settings. > Can you change the memory or CPU cache settings inside the bios? > Try to disable the cache. Sorry, I didn't want to mess with the default settings given that the machine has been so stable otherwise. I couldn't find a way to disable caching either. > Can you temporaly disable one core? Done, crashed all the same. Dunno what to try next... --bald PS: I have also observed the following error message: (besides the original CO_RC_ERROR_ERROR) Linux version 2.6.22-co-0.7.2 (hn@hn-lt) (gcc version 4.1.2) #1 PREEMPT Fri Jan 18 21:44:04 UTC 2008 160MB LOWMEM available. Entering add_active_range(0, 0, 40960) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 0 Normal 0 -> 40960 early_node_map[1] active PFN ranges 0: 0 -> 40960 On node 0 totalpages: 40960 colinux: Linux VM terminated colinux: BUG at ...p/stable-0.7.2-snapshot/linux-2.6.22-source/mm/bootmem.c:151 |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-02-27 23:39:38
|
Hello Baldyeti, baldyeti wrote: > PS: I have also observed the following error message: > (besides the original CO_RC_ERROR_ERROR) > > Linux version 2.6.22-co-0.7.2 (hn@hn-lt) (gcc version 4.1.2) > #1 PREEMPT Fri Jan 18 21:44:04 UTC 2008 > 160MB LOWMEM available. > Entering add_active_range(0, 0, 40960) 0 entries of 256 used > Zone PFN ranges: > DMA 0 -> 0 > Normal 0 -> 40960 > early_node_map[1] active PFN ranges > 0: 0 -> 40960 > On node 0 totalpages: 40960 > colinux: Linux VM terminated > colinux: BUG at > ...p/stable-0.7.2-snapshot/linux-2.6.22-source/mm/bootmem.c:151 static void __init free_bootmem_core(bootmem_data_t *bdata, unsigned ... BUG_ON(PFN_DOWN(addr + size) > bdata->node_low_pfn); <=== trap Full code: http://lxr.linux.no/linux/mm/bootmem.c#L150 The other was > daemon: exit code 89a09401 > daemon: error - CO_RC_ERROR_ERROR, line 37, file > src/colinux/kernel/pages.c (77) 23: co_rc_t co_manager_get_page(struct co_manager *manager, co_pfn_t ... 31: if (*pfn >= manager->hostmem_pages) { <=== trap 32: /* Surprise! We have a bug! */ 34: co_debug_error("PFN too high! %ld >= %ld", 35: *pfn, manager->hostmem_pages); 37: return CO_RC(ERROR); Full code: http://colinux.svn.sourceforge.net/viewvc/colinux/tags/0.7.2/src/colinux/kernel/pages.c?view=markup 1. On this step the linux side was never run. We only are in the windows driver. This helps a liddle more, where we need to search: Not in linux kernel. It is inside the windows kernel driver. 2. Both errors says, that some will access a page behind the limit (160MB in your case). The limit checkers traps into the error. 3. Both errors fails with an access to pfn and max pfn. Was a variable overwritten? Why memory are changed? Or why the requested pfn number are not in range of max pfn? Don't know. I'm a liddle out of ideas. Memory you have tested with memtest. So, the chips are ok. What physicaly memory recource used your graphics card? Have you other devices, that used memory regions over 2GB? Limit the memory size to 1GB, /maxmem=1024 in C:\boot.ini. Better? Interesting question: Is PAE currently enabled? Press keys LeftWin + Pause. On System properties a text "Physical Adress Extension" is seen or not? Disable PAE in boot.ini. Or if PAE is enabled, enable it. Better? 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. 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 -- Henry N. |
From: baldyeti <e_...@ho...> - 2008-03-02 22:36:21
|
> 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 |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-02 23:41:18
|
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. |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-03 19:34:17
|
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. |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-03 21:23:35
|
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. |
From: baldyeti <e_...@ho...> - 2008-03-03 22:55:29
|
> > 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 |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-03 21:53:52
|
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. |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-03 22:19:33
|
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. |
From: baldyeti <e_...@ho...> - 2008-03-03 23:00:12
|
> 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! |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-03 23:16:09
|
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. |
From: baldyeti <e_...@ho...> - 2008-03-04 09:51:38
|
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 |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-04 19:42:37
|
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. |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-04 20:50:19
|
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. |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-04 22:58:05
|
Hello Baldyeti, would be nice to check the next step, before I use the values. Download and extract this http://www.henrynestler.com/colinux/testing/pfn-check-0.7.3/daemons-0.7.3-20080304.zip Download DebugView.exe from http://www.sysinternals.com (redirected to MS), exist under "Miscellaneous Utilities". Direct link: http://download.sysinternals.com/Files/DebugView.zip Unpack and start DebugView.exe, let this window opened Open a new command prompt and reload coLinux driver with: colinux-daemon --remove-driver colinux-daemon --install-driver Check driver state with colinux-daemon --status-driver should give: Driver compiled on: Tue Mar 4 23:20:25 2008 Watch in the WebugView, save the output to log file. You should see such lines: ... Rage[0] 0x1000 0x9e000 (647168 MB) ... Rage[1] 0x100000 0xeff000 (15724544 MB) ... Rage[2] 0x1000000 0x1eef0000 (518979584 MB) ... Rage[3] 0x1ff00000 0x100000 (1048576 MB) ... allocating reversed physical mapping for 131072 pages This are the physicaly pages of my system (the "MB" are Bytes, please ignore my typofix). Please send me this text file, or post your short version here (see my shorts). Hope to see your graphic card hole there. 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. There you should see the current memory. The same as from coLinux? -- Henry N. |
From: baldyeti <e_...@ho...> - 2008-03-05 12:34:19
|
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 |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-06 00:35:44
|
baldyeti wrote: > 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. Yes, was the same as automicly detect by coLinux driver. Thanks. Graphic card is not in list. Very good. That should be run: http://www.henrynestler.com/colinux/testing/pfn-check-0.7.3/daemons-0.7.3-20080305.zip Debugs on startup are enabled for DebugView. If my idea works, you should see exactly this line: "... big Range[2] 0x0.01000000 0x0.77000000" and some lines later two or more of: "... co_winnt_new_mdl_bucket] FixRange used 0x1000000 0x77000000" All other 'Range' should automaticly ignored. No errors with 'pfn to big' or 'pfn out of range' should be have now (in colinux-debug only, not in DebugView). If that works, I can remove some of the debuggings and made a clean runable version. -- Henry N. |
From: baldyeti <e_...@ho...> - 2008-03-06 01:47:46
|
> Debugs on startup are enabled for DebugView. > If my idea works, you should see exactly this line: > "... big Range[2] 0x0.01000000 0x0.77000000" > > and some lines later two or more of: > "... co_winnt_new_mdl_bucket] FixRange used 0x1000000 0x77000000" I see the second one (FixRange) repeated numerous times in the rather verbose log, but not the 1st one (BigRange). > All other 'Range' should automaticly ignored. > No errors with 'pfn to big' or 'pfn out of range' should be have now (in > colinux-debug only, not in DebugView). I am still seeing "Bug: PFN too high! 521536 >= 491520" but didn't you tell me that one was safe to ignore? Cheers, --bald |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-06 09:18:37
|
baldyeti wrote: >> Debugs on startup are enabled for DebugView. >> If my idea works, you should see exactly this line: >> "... big Range[2] 0x0.01000000 0x0.77000000" >> >> and some lines later two or more of: >> "... co_winnt_new_mdl_bucket] FixRange used 0x1000000 0x77000000" > > I see the second one (FixRange) repeated numerous times in the > rather verbose log, but not the 1st one (BigRange). DebugView is totaly ok. No errors, no "Bug: ...", very good. "big Range" can not see on coLinux starts. You can only see it at driver load: colinux-daemon.exe --remove-driver colinux-daemon.exe --install-driver "FixRange" is the usage of "big range" finder on startup. So it is no problem, that you not have seen it in log. It is still working. >> All other 'Range' should automaticly ignored. >> No errors with 'pfn to big' or 'pfn out of range' should be have now (in >> colinux-debug only, not in DebugView). > > I am still seeing "Bug: PFN too high! 521536 >= 491520" but didn't > you tell me that one was safe to ignore? Yes, you can double ignore this. ;-) 1. This was an false/positive on co_os_map. 2. In the new code don't exist such text. There exist a new text "Bug: PFN out of range", and this should not ignore. The debug xml contains an old plus new debug (file was append). Behind the text "Daemon compiled on Thu Mar 6 00:31:32 2008" all is ok, no more errors. Thanks. I will cleanup the code next weekend. -- Henry N. |
From: baldyeti <e_...@ho...> - 2008-03-06 17:46:52
|
On 06/03/2008 09:18, Henry Nestler wrote: > DebugView is totaly ok. No errors, no "Bug: ...", very good. > > "big Range" can not see on coLinux starts. > You can only see it at driver load: > colinux-daemon.exe --remove-driver > colinux-daemon.exe --install-driver > Just for confirmation: [m:colinux-driver f:0 l:10 src/colinux/os/winnt/kernel/manager.c:134:co_os_manager_init] big Range[2] 0x0.01000000 0x0.77000000 and then later: [m:colinux-driver f:0 l:10 src/colinux/os/winnt/kernel/alloc.c:65:co_winnt_new_mdl_bucket] FixRange used 0x1000000 0x77000000 So Henry ... is this all pointing to a problem in the nvidia graphics driver, or a bug that might have bitten anyone with an IGP using shared memory? |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-06 21:20:23
|
baldyeti wrote: > On 06/03/2008 09:18, Henry Nestler wrote: >> DebugView is totaly ok. No errors, no "Bug: ...", very good. >> >> "big Range" can not see on coLinux starts. >> You can only see it at driver load: >> colinux-daemon.exe --remove-driver >> colinux-daemon.exe --install-driver >> > Just for confirmation: > > [m:colinux-driver f:0 l:10 > src/colinux/os/winnt/kernel/manager.c:134:co_os_manager_init] big > Range[2] 0x0.01000000 0x0.77000000 > > and then later: > > [m:colinux-driver f:0 l:10 > src/colinux/os/winnt/kernel/alloc.c:65:co_winnt_new_mdl_bucket] FixRange > used 0x1000000 0x77000000 > > So Henry ... is this all pointing to a problem in the nvidia > graphics driver, or a bug that might have bitten anyone with > an IGP using shared memory? I have tryed to allocating memory in the range of my shared graphic adapter. Failed, and don't got memory from this area. So, my graphics driver (ATI) works right and block coLinux from getting this memory area. My laptop has 512MB total ram, from that are 32MB shared graphic. This is coLinux driver debug from testing: Rage[0] 0x1000 0x9e000 (647168 0MB) Rage[1] 0x100000 0xeff000 (15724544 14MB) Rage[2] 0x1000000 0x1cff0000 (486473728 463MB) Try to get from 0x1e000000 to 0x20000000 size 262144 MmAllocatePagesForMdl failed It's a double fault on both drivers. It's a bug in your graphic card driver and in coLinux driver. Would coLinux ask for specific range instead "any" ram, then would no have problems. The last workarround does exactly this. If your card would mark the memory as "in use", then colinux driver would not got it. We know, that MmAllocatePagesForMdl is undocumented. But, I can not find a simple way to get a big list of pages without having virtual memory before. All the functions needs to have virtual memory as parameter. With virtual bufer would have to create a MDL from that, than can fill the MDL with pages... Interesing links: "Address Mappings and MDLs" http://msdn2.microsoft.com/en-us/library/ms796200.aspx "Long-Term Internal Driver Buffers" http://msdn2.microsoft.com/en-us/library/ms796250.aspx -- Henry N. |
From: Henry N. <Henry.Ne@Arcor.de> - 2008-03-06 23:08:07
|
Hello Baldyeti, http://www.henrynestler.com/colinux/testing/pfn-check-0.7.3/daemons-0.7.3-20080306.zip this is the final code. All debugs removed. Should run properly on your machine. -- Henry N. |