colinux-users

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?

[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:
>> 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.

Yes, of curse. But, perhaps windows does some special workarrounts to
fix the buggy cache on your cpu?

Intel P4 and Xeon was old candidate for problems with caching long time
ago. Has Intel a new buggy chipset now? An idea only.

I found inside Linux kernel:
arch/i386/kernel/cpu/intel.c:31
void __cpuinit early_intel_workaround(struct cpuinfo_x86 *c)
{
        if (c->x86_vendor != X86_VENDOR_INTEL)
                return;
        /* Netburst reports 64 bytes clflush size, but does IO in 128
bytes */
        if (c->x86 == 15 && c->x86_cache_alignment == 64)
                c->x86_cache_alignment = 128;
}

This is exactly your CPU, I'm afraid. You have model: 15 and clflush
size 64. But, I not know how it is interesting for coLinux.

-- 
Henry N.

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

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

> Intel P4 and Xeon was old candidate for problems with caching long time
> ago. Has Intel a new buggy chipset now? An idea only.

I don't know. This is not an "old" CPU (it will quickly become one !-)
but essentially a cheap core duo with a smaller cache.

> This is exactly your CPU, I'm afraid. You have model: 15 and clflush
> size 64. But, I not know how it is interesting for coLinux.

So... the code you found would mean that linux also has this case
covered and a workaround in place, wouldn't it?

Anyway, I'll try your other suggestions before I post back.
Might not be before a week or so, though.

BTW, thanks a lot for your dedication in releasing and
supporting colinux, Henry.

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

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

Henry Nestler wrote:
> baldyeti wrote:
>>> 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.
> 
> Yes, of curse. But, perhaps windows does some special workarrounts to
> fix the buggy cache on your cpu?
> 
> Intel P4 and Xeon was old candidate for problems with caching long time
> ago. Has Intel a new buggy chipset now? An idea only.
> 
> I found inside Linux kernel:
> arch/i386/kernel/cpu/intel.c:31
> void __cpuinit early_intel_workaround(struct cpuinfo_x86 *c)
> {
>         if (c->x86_vendor != X86_VENDOR_INTEL)
>                 return;
>         /* Netburst reports 64 bytes clflush size, but does IO in 128
> bytes */
>         if (c->x86 == 15 && c->x86_cache_alignment == 64)
>                 c->x86_cache_alignment = 128;
> }
> 
> This is exactly your CPU, I'm afraid. You have model: 15 and clflush
> size 64. But, I not know how it is interesting for coLinux.

Sorry, you have not that cpu. Yours is
cpu family      : 6	<=== c->x86
model           : 15	<=== c->x86_model
stepping        : 13	<=== c->x86_mask

Inside the current kernel 2.6.25-rc3 found this
arch/i386/kernel/cpu/intel.c:33
void __cpuinit early_init_intel(struct cpuinfo_x86 *c)
{
        /* Netburst reports 64 bytes clflush size, but does IO in 128
bytes */
        if (c->x86 == 15 && c->x86_cache_alignment == 64)
                c->x86_cache_alignment = 128;
        if ((c->x86 == 0xf && c->x86_model >= 0x03) ||
                (c->x86 == 0x6 && c->x86_model >= 0x0e))
                set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
}

If I read this, only TSC will be change for your cpu. But should no
depend on the memory bug you found.

-- 
Henry N.