From: Nicolas Aspert <Nicolas.Aspert@epfl.ch>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Alessandro Morelli <alex@alphac.it>, linux-kernel@vger.kernel.org
Subject: Re: PROBLEM: memory corruption with i815 chipset variant
Date: Mon, 27 May 2002 10:56:32 +0200 [thread overview]
Message-ID: <3CF1F4C0.5080201@epfl.ch> (raw)
In-Reply-To: <fa.mm4ng1v.vmenaj@ifi.uio.no> <fa.gciunnv.cnaf99@ifi.uio.no> <3CF1EA3F.4070608@epfl.ch> <1022493086.11859.191.camel@irongate.swansea.linux.org.uk>
Alan Cox wrote:
>
> It certainly could be. If bits 29-31 maybe control things like memory
> timings then it could do quite horrible things. Fixing it to leave the
> ERRSTS register alone and keep bits 29-31 is definitely worth trying. If
> that fixes it then its going to be easy enough to drop a fix into the
> mainstream code
>
OK, I have a patch almost ready to do that except, I am not sure about
what to do for those 3 bits...
The *usual* call is :
pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE,
agp_bridge.gatt_bus_addr);
Where 'gatt_bus_addr' is returned from a 'virt_to_phys' on
'gatt_table_real'.
Should I mask those three bits out when writing or write
'gatt_bus_addr >> 3' instead ? I am not too sure about the assumptions
that can be made about what returns 'virt_to_phys' ...
Thanks in advance.
Nicolas.
--
Nicolas Aspert Signal Processing Institute (ITS)
Swiss Federal Institute of Technology (EPFL)
next prev parent reply other threads:[~2002-05-27 8:56 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.mm4ng1v.vmenaj@ifi.uio.no>
[not found] ` <fa.gciunnv.cnaf99@ifi.uio.no>
2002-05-27 8:11 ` PROBLEM: memory corruption with i815 chipset variant Nicolas Aspert
2002-05-27 9:51 ` Alan Cox
2002-05-27 8:56 ` Nicolas Aspert [this message]
2002-05-27 10:17 ` Alan Cox
2002-05-27 9:32 ` [PATCH,CFT] Tentative fix for mem. corruption caused by intel 815 AGP Nicolas Aspert
2002-05-27 11:03 ` Alan Cox
2002-05-27 10:09 ` Nicolas Aspert
[not found] ` <1022498304.11859.239.camel@irongate.swansea.linux.org.uk>
2002-05-27 11:11 ` Nicolas Aspert
2002-05-27 14:33 ` Alan Cox
2002-05-27 14:08 ` [PATCH,CFT] Tentative fix for agpgart (writing on 'reserved' bits) Nicolas Aspert
[not found] ` <5.1.0.14.0.20020528103408.02ab1260@shiva.intra.alphac.it>
[not found] ` <5.1.0.14.0.20020530110655.02afbb20@shiva.intra.alphac.it>
2002-05-30 9:41 ` Nicolas Aspert
2002-05-24 23:15 PROBLEM: memory corruption with i815 chipset variant Steve Kieu
-- strict thread matches above, loose matches on Subject: below --
2002-05-21 13:00 Alessandro Morelli
2002-05-21 11:44 Alessandro Morelli
2002-05-21 12:54 ` Alan Cox
2002-05-22 8:47 ` Alessandro Morelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3CF1F4C0.5080201@epfl.ch \
--to=nicolas.aspert@epfl.ch \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=alex@alphac.it \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.