Bug 164500 - RHEL3, 2.4.21-32.0.1.ELsmp: Nvidia 7664 complains about 'bad caching on address 0xf2f50000 ...'
RHEL3, 2.4.21-32.0.1.ELsmp: Nvidia 7664 complains about 'bad caching on addre...
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Ernie Petrides
Brian Brock
Depends On:
Blocks: 170445
  Show dependency treegraph
Reported: 2005-07-28 08:10 EDT by Issue Tracker
Modified: 2007-11-30 17:07 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-11-02 14:39:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
lspci output from machine exhibiting problem (12.40 KB, text/plain)
2005-10-06 09:37 EDT, Neil Horman
no flags Details

  None (edit)
Description Issue Tracker 2005-07-28 08:10:14 EDT
Escalated to Bugzilla from IssueTracker
Comment 12 Ernie Petrides 2005-07-28 15:33:35 EDT
Ingo, I think this might be related to bug 163239.
Comment 13 AJ Johnson 2005-08-05 15:11:20 EDT
Any progress on this?  I have a customer who is running into lockups on their
system, and they are reporting that they are seeing the bad cacheing messages. 
nVidia's response is to update your kernel :)  How likely is this issue related
to bug 163239 - i.e. is it likely that it's fixed in U6?
Comment 14 Ernie Petrides 2005-08-05 17:30:42 EDT
Neither problem has been addressed in U6 (which is already in beta).
Comment 21 Alan Matsuoka 2005-09-07 10:47:26 EDT
Anything else on this ? The customer is getting pretty upset.
Comment 22 Brian Maly 2005-09-07 11:35:50 EDT
since being assigned this bug yesterday, I have tried to find some hardware to
replicate this issue but so far no success. a search of the inventory system did
not produce any results for Nvidia cards (but I believe inventory is broken as
we must have a system somewhere with at least one Nvidia card). So I still need
to locate some hardware somehow...

do we know what the PCI deviceid is? can we maybe get a "lspci" output?
Comment 27 Neil Horman 2005-10-06 09:37:45 EDT
Created attachment 119669 [details]
lspci output from machine exhibiting problem

As requested, lspci output from a machine exhibiting the issue
Comment 30 Ernie Petrides 2005-10-11 17:14:33 EDT
Apparently, there is bogus info in comment #17.  According to comment #28,
this is an i686-only problem.  Fixing "hardware" field to reflect this.
Comment 33 Ernie Petrides 2005-10-19 19:10:29 EDT
Removing link to IT 75537, which is a different problem against a
different release.  Brian, please ignore comment #31.
Comment 35 Ernie Petrides 2005-10-20 17:43:35 EDT
Hello, Terence.  I believe you've got the wrong bit.  The discrepency
according to the messages is that bit 9 was not set (0x200), and this
bit is _PAGE_BIT_NX (defined in include/asm-i386/pgtable.h).

Does the hardware that produces the warnings contain cpus with NX support?

(Eric, please propagate this question to <tripperda@nvidia.com> and post
 the answer here.  You might need to check directly with the customer.)
Comment 46 Ernie Petrides 2005-11-02 14:39:35 EST
The problem reported in this bugzilla is due to an incorrect assumption
in NVidia's driver (which is not part of RHEL3) that expects the soft-NX
bit to be set in PTEs on non-NX-capable systems.

Closing as NOTABUG.
Comment 49 Ernie Petrides 2005-11-03 15:14:06 EST
SteffenMann, in regards to BZ comment #47, this problem is *not* the
result of a RHEL3 kernel bug, which is why this is closed as NOTABUG.
The warning is the result of a bug in NVidia's driver (which is external).

Jeffrey Layton, I don't know how why your comment  #48 about BZ 171129
has landed in BZ 164500 (via IT 75455).  If you've got ITs incorrectly
cross-linked, please fix them.  Thanks.

Note You need to log in before you can comment on or make changes to this bug.