lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Message-Id: <BF56C133-8810-4AA7-B8AF-325424869A76@gmail.com>
Date:	Thu, 7 Feb 2008 16:30:01 -0600
From:	William Dinkel <wdinkel@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Invalid size values in /proc/mtrr output

Has anyone else seen extraordinarily large sizes in /proc/mtrr  
output?  We're running v2.6.24 on some Tyan S5383 dual-socket systems  
with the following characteristics:
  - qty(1) Intel(R) Xeon(R) CPU E5345 @ 2.33GHz (quad-core, the other  
socket is unoccupied)
  - 32GB RAM (qty(16) 2GB DIMMS)
  - MTRR Discrete ENABLED in the BIOS
  - PCI Memory Hole set to 512MB in the BIOS (other options are  
256MB, 1GB and 2GB, all of which produce similar results)
  - CONFIG_MTRR, CONFIG_SMP and CONFIG_MCORE2 enabled

Here's some relevant output from a shell session:
---
[root@...e003 ~]# uname -r
2.6.24
[root@...e003 ~]# free -m
              total       used       free     shared    buffers      
cached
Mem:         32245        320      31925          0         15         
162
-/+ buffers/cache:        142      32103
Swap:         2047          0       2047
[root@...e003 ~]# cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=198656MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=197632MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=200704MB: write-back, count=1
reg03: base=0x200000000 (8192MB), size=204800MB: write-back, count=1
reg04: base=0x400000000 (16384MB), size=212992MB: write-back, count=1
reg05: base=0x800000000 (32768MB), size=197632MB: write-back, count=1
reg06: base=0xbff80000 (3071MB), size=196608MB: uncachable, count=1
---

I have a hunch that those 192GB+ sizes aren't "correct."  We're in  
communication with Tyan, and they say the MTRRs look OK from their  
end on a similarly configured system (using a utility unknown to me):

---
Here is the MTRR that we dumped from S5383 with 32G memory,BIOS SETUP  
for PCI memory hole 512MB and MTRR discrete ENABLED:

MSR                 EDX                  EAX                   
description
200H                 00000000H        00000006H        MTRR physical  
base 0,start at address 0
201H                 0000000FH        80000800H        MTRR physical  
mask 0,size 2G
202H                 00000000H        80000006H        MTRR physical  
base 1,start at address 2G
203H                 0000000FH        C0000800H       MTRR physical  
mask 1,size 1G
204H                 00000001H        00000006H        MTRR physical  
base 2,start at address 4G
205H                 0000000FH        00000800H        MTRR physical  
mask2,size 4G
206H                 00000002H        00000006H        MTRR physical  
base 3,start at address 8G
207H                 0000000EH       00000800H        MTRR physical  
mask3,size 8G
208H                 00000004H        00000006H        MTRR physical  
base 4,start at address 16G
209H                 0000000CH       00000800H        MTRR physical  
mask 4,size 16G
20AH                00000008H        00000006H        MTRR physical  
base 5,start at address 32G
20BH                0000000FH        C0000800H       MTRR physical  
mask 5,size 1G
20CH                00000000H        BFF80000H       MTRR physical  
base 6,start at address 3G-512K
20DH                0000000FH        FFF80800H       MTRR physical  
mask6 ,size 512K
20EH                00000000H        00000000H        MTRR physical  
base 7
20FH                00000000H        00000000H        MTRR physical  
mask7
---

Although it's not running v2.6.24 at the moment, we also have an  
Intel S5400SF system exhibiting similar behavior:

---
[root@...d ~]# ssh n00001 uname -r
2.6.18-8.1.15.el5
[root@...d ~]# ssh n00001 free -m
              total       used       free     shared    buffers      
cached
Mem:         16039        425      15613          0          0         
335
-/+ buffers/cache:         89      15949
Swap:            0          0          0
[root@...d ~]# ssh n00001 cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=198656MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=197120MB: write-back, count=1
reg02: base=0x9fc00000 (2556MB), size=196612MB: uncachable, count=1
reg03: base=0x100000000 (4096MB), size=200704MB: write-back, count=1
reg04: base=0x200000000 (8192MB), size=204800MB: write-back, count=1
reg05: base=0x400000000 (16384MB), size=212992MB: write-back, count=1
---

We'll continue to work with the board vendors on this, but we wanted  
to get feedback from any MTRR experts out there.

Please CC me when replying.  Thanks.

Will Dinkel
wdinkel@...il.com



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ