Bug 39845
| Summary: | mtrr not working properly (kernel 2.4.2-2) | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Bernhard Ege <bme> |
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
| Status: | CLOSED RAWHIDE | QA Contact: | Brock Organ <borgan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | CC: | per.starback |
| 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: | 2001-05-14 12:20:02 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Bernhard Ege
2001-05-09 09:37:03 UTC
Please file all bugs regarding the binary-only NVidia driver to NVidia This is *not* a nvidia related bug as it turns out it still exists when I shut down X and unload the NVdriver module. I can empty the mtrr register: echo "disable=reg00" > /proc/mtrr /proc/mtrr is empty now and the system is *slow*. I enter this to mtrr: echo "base=0x00000000 size=0x10000000 type=write-back" > /proc/mtrr /proc/mtrr now has this to say: reg00: base=0x00000000 ( 0MB), size=16773376MB: write-back, count=1 This is without any nvidia related binaries or anything else loaded. Please retry without the nvidia modules EVER being loaded since the reboot. I have now performed a reboot and without ever having started the nvidia module the problem still persists. This is what I did just after the reboot: [root@overmind /root]# cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=16711936MB: write-back, count=1 [root@overmind /root]# echo "disable=reg00" > /proc/mtrr [root@overmind /root]# echo "base=0x00000000 size=0x10000000 type=write-back" > /proc/mtrr [root@overmind /root]# cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=16773376MB: write-back, count=1 [root@overmind /root]# lsmod Module Size Used by nfsd 69696 8 (autoclean) lockd 52464 1 (autoclean) [nfsd] sunrpc 61328 1 (autoclean) [nfsd lockd] libafs-2.4.2-2 381264 2 autofs 11264 2 (autoclean) 8139too 16480 1 (autoclean) ipchains 38976 0 (unused) ide-scsi 8352 0 scsi_mod 95104 1 [ide-scsi] ide-cd 26848 0 cdrom 27232 0 [ide-cd] nls_iso8859-1 2880 2 (autoclean) nls_cp437 4384 2 (autoclean) vfat 9392 2 (autoclean) fat 32672 0 (autoclean) [vfat] Any ideas? Is it correct that you have 256Mb of ram ? Yes, that is correct. Sometimes, e.g. starting X, I see the same "mtrr: type mismatch" messages on Athlon MS-6195 motherboard (AMD-751/756) with Rage 128 pro AGP card. Do you need more information? I just tried on my home athlon machine, and it works there. Although I have 768Mb of ram... This is a strange problem. I have just installed the rawhide kernel, 2.4.3-2.14.14, rebooted and now MTRR works as expected. Now alsasound cannot be recompiled (/usr/src/linux-2.4.3/include/asm/pgalloc-2level.h is missing). kernel-headers are also too old. "pgalloc-2level.h" is no longer present in the kernel. It is really surprising ALSA needs this header as it is a very very architecture specific file and normal drivers shouldn't need to include it. As this is a generic kernel change, I would not be surprised if a newer ALSA driver is released that fixes this. I forgot a make clean in alsasound and that caused the problem. alsasound works just fine with kernel-2.4.3-2.14.14. This problem seems to have been a symptom of changes to the MTRR support in 2.4
The fix is mtrr.c version 1.39 which contains the comment
v1.39
20010312 Dave Jones <davej>
Ugh, I broke AMD support.
Reworked fix by Troels Walsted Hansen <troels>
This is included in 2.4.3 kernels from RawHide so all AMD users seeing errors
like this should probably consider upgrading.
This was an initialisation problem in the mtrr coding. For current Athlon CPUs it was pretty likely that the and/or mask values didnt get initialized and therfore gigantic size values got composed from CPU registers. The bug is fixed in official Linux Kernel 2.4.4 and later. |