Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 86593

Summary: Celeron L2 Cache on kernel 2.4.18-27.8.0
Product: [Retired] Red Hat Linux Reporter: Juan <jfcamino>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED UPSTREAM QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-06-05 16:58:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Juan 2003-03-26 05:10:07 UTC
Description of problem:
Kernel 2.4.18-27.8.0 does not print L2 Cache size for the Celeron
processor at boot time. The L1 Cache appears fine. Applying Patch
patch-2.4.21-pre5 does not seems to identify the L2 cache either.

Or what is more likely to be: I am missing to configure something.

Version-Release number of selected component (if applicable):

How reproducible:
intall/upgrate to kernel kernel 2.4.18-27.8.0 or patch-2.4.21-pre5 

Steps to Reproduce:
1.
2.
3.
    
Actual results:
CPU: L1 I cache: 0K, L1 D cache: 8K

Expected results:
CPU: L2 cache: 128K

Additional info:
dmesg
Linux version 2.4.18-27.8.0 (bhcompile@sylvester.devel.redhat.com) (gcc version
3.2 20020903 (Red Ha
t Linux 8.0 3.2-7)) #1 Fri Mar 14 06:45:49 EST 2003
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fffc000 (usable)
 BIOS-e820: 000000001fffc000 - 000000001ffff000 (ACPI data)
 BIOS-e820: 000000001ffff000 - 0000000020000000 (ACPI NVS)
 BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
0MB HIGHMEM available.
511MB LOWMEM available.
On node 0 totalpages: 131068
zone(0): 4096 pages.
zone(1): 126972 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=linux ro
BOOT_FILE=/boot/vmlinuz-2.4.18-27.8.0 root=LABEL=/ agp
_try_unsupported=1
Initializing CPU#0
Detected 2100.150 MHz processor.
Speakup v-1.00 CVS: Tue Jun 11 14:22:53 EDT 2002 : initialized
Console: colour VGA+ 80x25
Calibrating delay loop... 4171.80 BogoMIPS
Memory: 511508k/524272k available (1315k kernel code, 10200k reserved, 990k
data, 172k init, 0k high
mem)
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount cache hash table entries: 8192 (order: 4, 65536 bytes)
ramfs: mounted with options: <defaults>
ramfs: max_pages=64210 max_file_pages=0 max_inodes=0 max_dentries=64210
Buffer cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
CPU: Before vendor init, caps: bfebfbff 00000000 00000000, vendor = 0
CPU: L1 I cache: 0K, L1 D cache: 8K
CPU: After vendor init, caps: bfebfbff 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU:     After generic, caps: bfebfbff 00000000 00000000 00000000
CPU:             Common caps: bfebfbff 00000000 00000000 00000000
CPU: Intel(R) Celeron(R) CPU 2.10GHz stepping 07
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
U: After vendor init, caps: bfebfbff 00000000 00000000 00000000

Comment 1 Juan 2003-03-27 04:05:33 UTC
patch-2.4.21-pre6 fix this bug

Comment 2 Alan Cox 2003-06-05 16:58:25 UTC
This is cosmetic and resolved upstream so closing