Bug 164500 - RHEL3, 2.4.21-32.0.1.ELsmp: Nvidia 7664 complains about 'bad caching on address 0xf2f50000 ...'
Summary: RHEL3, 2.4.21-32.0.1.ELsmp: Nvidia 7664 complains about 'bad caching on addre...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ernie Petrides
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: 170445
TreeView+ depends on / blocked
 
Reported: 2005-07-28 12:10 UTC by Issue Tracker
Modified: 2007-11-30 22:07 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-11-02 19:39:35 UTC
Target Upstream Version:
Embargoed:


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

Description Issue Tracker 2005-07-28 12:10:14 UTC
Escalated to Bugzilla from IssueTracker

Comment 12 Ernie Petrides 2005-07-28 19:33:35 UTC
Ingo, I think this might be related to bug 163239.

Comment 13 AJ Johnson 2005-08-05 19:11:20 UTC
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 21:30:42 UTC
Neither problem has been addressed in U6 (which is already in beta).

Comment 21 Alan Matsuoka 2005-09-07 14:47:26 UTC
Anything else on this ? The customer is getting pretty upset.

Comment 22 Brian Maly 2005-09-07 15:35:50 UTC
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 13:37:45 UTC
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 21:14:33 UTC
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 23:10:29 UTC
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 21:43:35 UTC
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> and post
 the answer here.  You might need to check directly with the customer.)

Comment 46 Ernie Petrides 2005-11-02 19:39:35 UTC
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 20:14:06 UTC
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.