Uwe Hermann wrote: > On Thu, Aug 30, 2007 at 11:43:41PM -0400, Corey Osgood wrote: > >>> I guess (from looking at the boot log diffs) that this may be the reason >>> for the slow boot, but how do I fix it? >>> >>> CPU: L1 I cache: 16K, L1 D cache: 16K >>> -CPU: L2 cache: 128K >>> >>> (i.e., it seems the L2 cache is never enabled when using LinuxBIOS) >>> >>> >> Is your cpu id in model_6xx_init.c? I'm not seeing any attempt even at >> cpu init in the LB boot log, and IIRC there should be something printed. >> And if I'm reading the kernel boot log right, your model ID is 0x06a5, >> which isn't currently in there and not added by your patch. I'll fire up >> the mew-vm tomorrow and see if it has the same problem, the boot on that >> board is slow but not that slow, I figured it was just my old 400MHz >> celeron running over a serial connection. >> > > I checked that, but it looks correct to me. If I'm not mistaken I have > a 0x0665 (Mendocino), but maybe I got the format of those IDs wrong? > > See CPU info below: > > $ proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 6 > model name : Celeron (Mendocino) > stepping : 5 > cpu MHz : 434.356 > cache size : 128 KB > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 2 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat > pse36 mmx fxsr up > bogomips : 869.78 > clflush size : 32 > > > $ cpuid > eax in eax ebx ecx edx > 00000000 00000002 756e6547 6c65746e 49656e69 > 00000001 00000665 00000000 00000000 0183f9ff > 00000002 03020101 00000000 00000000 0c040841 > > Vendor ID: "GenuineIntel"; CPUID level 2 > > Intel-specific functions: > Version 00000665: > Type 0 - Original OEM > Family 6 - Pentium Pro > Model 6 - Celeron > Stepping 5 > Reserved 0 > > > Feature flags 0183f9ff: > FPU Floating Point Unit > VME Virtual 8086 Mode Enhancements > DE Debugging Extensions > PSE Page Size Extensions > TSC Time Stamp Counter > MSR Model Specific Registers > PAE Physical Address Extension > MCE Machine Check Exception > CX8 COMPXCHG8B Instruction > SEP Fast System Call > MTRR Memory Type Range Registers > PGE PTE Global Flag > MCA Machine Check Architecture > CMOV Conditional Move and Compare Instructions > FGPAT Page Attribute Table > PSE-36 36-bit Page Size Extension > MMX MMX instruction set > FXSR Fast FP/MMX Streaming SIMD Extensions save/restore > > TLB and cache info: > 01: Instruction TLB: 4KB pages, 4-way set assoc, 32 entries > 02: Instruction TLB: 4MB pages, 4-way set assoc, 2 entries > 03: Data TLB: 4KB pages, 4-way set assoc, 64 entries > 41: 2nd-level cache: 128KB, 4-way set assoc, 32 byte line size > 08: 1st-level instruction cache: 16KB, 4-way set assoc, 32 byte line size > 04: Data TLB: 4MB pages, 4-way set assoc, 8 entries > 0c: 1st-level data cache: 16KB, 4-way set assoc, 32 byte line size > > > $ x86info -a > x86info v1.20. Dave Jones 2001-2006 > Feedback to <[EMAIL PROTECTED]>. > > Found 1 CPU > -------------------------------------------------------------------------- > eax in: 0x00000000, eax = 00000002 ebx = 756e6547 ecx = 6c65746e edx = > 49656e69 > eax in: 0x00000001, eax = 00000665 ebx = 00000000 ecx = 00000000 edx = > 0183f9ff > eax in: 0x00000002, eax = 03020101 ebx = 00000000 ecx = 00000000 edx = > 0c040841 > > Family: 6 Model: 6 Stepping: 5 Type: 0 Brand: 0 > CPU Model: Celeron (Mendocino) Original OEM > Feature flags: > fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr > > Cache info > L1 Instruction cache: 16KB, 4-way associative. 32 byte line size. > L1 Data cache: 16KB, 4-way associative. 32 byte line size. > L2 unified cache: 128KB, 4-way associative. 32 byte line size. > TLB info > Instruction TLB: 4KB pages, 4-way associative, 32 entries > Instruction TLB: 4MB pages, fully associative, 2 entries > Data TLB: 4KB pages, 4-way associative, 64 entries > Data TLB: 4MB pages, 4-way associative, 8 entries > (null) > Connector type: Socket 370 (370 Pin PGA) > > > MTRR registers: > MTRRcap (0xfe): MTRRphysBase0 (0x200): MTRRphysMask0 (0x201): MTRRphysBase1 > (0x202): MTRRphysMask1 (0x203): MTRRphysBase2 (0x204): MTRRphysMask2 (0x205): > MTRRphysBase3 (0x206): MTRRphysMask3 (0x207): MTRRphysBase4 (0x208): > MTRRphysMask4 (0x209): MTRRphysBase5 (0x20a): MTRRphysMask5 (0x20b): > MTRRphysBase6 (0x20c): MTRRphysMask6 (0x20d): MTRRphysBase7 (0x20e): > MTRRphysMask7 (0x20f): MTRRfix64K_00000 (0x250): MTRRfix16K_80000 (0x258): > MTRRfix16K_A0000 (0x259): MTRRfix4K_C8000 (0x269): MTRRfix4K_D0000 0x26a: > MTRRfix4K_D8000 0x26b: MTRRfix4K_E0000 0x26c: MTRRfix4K_E8000 0x26d: > MTRRfix4K_F0000 0x26e: MTRRfix4K_F8000 0x26f: MTRRdefType (0x2ff): > > 450MHz processor (estimate). > > > >>> $ lspci -xxx >>> >>> 00:00.0 Host bridge: Intel Corporation 82810 GMCH [Graphics Memory >>> Controller Hub] (rev 03) >>> 00: 86 80 20 71 06 00 80 20 03 00 00 06 00 00 00 00 >>> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 20 71 >>> 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 50: 68 51 a0 3c 00 00 00 00 00 00 00 00 00 00 00 00 >>> 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 70: cc 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 80: c6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> 90: 00 00 9a dd 00 00 00 00 00 00 00 00 00 00 00 00 >>> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> f0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 >>> >> Can you send lspci -xxx from linuxbios? I really can't see anything too >> alarming in the boot logs, although I could be overlooking it. >> > > Sure. > > 00: 86 80 20 71 06 01 80 20 03 00 00 06 00 00 00 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 50: 60 ff 0a 20 00 00 00 00 00 00 00 00 00 00 00 00 > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 90: 00 00 da 77 00 00 00 00 00 00 00 00 00 00 00 00 > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > f0: 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 > > I already tried playing a bit with the northbridge > registers and RAM init (GMCHCFG, DRAMT, BUFF_SC etc.) > but that doesn't seem to have much influence. >
I think it's BUFF_SC, can you use the factory value for this? It's 0x92 btw, so you don't have to look it up. I used a single sided 128mb stick to get that value, and then tested it with about 5 other similar sticks, only 1 passed ram_check but hung while copying LB. And just realized something else, directly related to the email I just sent for Joe. Please change the MRS value from 0x1d0 to 0xad0. Heh, that could seriously bork things up, my bad. >> Can you also try memtest86? >> > > I already did, and it works, it's just very slow. > > * Memtest86 with vendor BIOS: > 229 MB/s, L1: 4256 MB/s, L2: 1116 MB/s > > * Memtest with LinuxBIOS: > 16 MB/s, L1: 16 MB/s, L2: off (?) > Eww, you weren't kidding. Hopefully the above will take care of the mem issue, not sure about the L2 cache still. Can you put a printk into model_6xx_init so you can see if it's actually running or not? I'll fire up the mem-vm tomorrow, I've got a new bios savior to try on it anyways. -Corey -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios