<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED --- - [NV31] lockup when using AGP. agpmode=0 fixes it."
href="https://bugs.freedesktop.org/show_bug.cgi?id=20341#c21">Comment # 21</a>
on <a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED --- - [NV31] lockup when using AGP. agpmode=0 fixes it."
href="https://bugs.freedesktop.org/show_bug.cgi?id=20341">bug 20341</a>
from <span class="vcard"><a class="email" href="mailto:mypersonalmailbox1@mail.com" title="mypersonalmailbox1@mail.com">mypersonalmailbox1@mail.com</a>
</span></b>
<pre>Hi,
I believe VIA Technologies KT133's AGP may be the culprit.
<a href="http://us.download.nvidia.com/XFree86/Linux-x86/173.14.09/README/chapter-12.html">http://us.download.nvidia.com/XFree86/Linux-x86/173.14.09/README/chapter-12.html</a>
KT133's (VT8363) AGP is likely to be generationally be closer to Apollo Pro133A
(VT82C694X) and KX133 (VT8371).
KT133 and KX133 are fairly similar with KT133 correctly supporting AMD Socket
A.
KX133 supposedly did not implement a certain type of I/O buffer for EV6 bus to
support Socket A, and as a result, it will not be able to support Socket A.
Of course, that issue is not related to AGP, but since KT133 came out fairly
quickly after the EV6 bus issue was acknowledged, it is probably a minor
updated version of KX133.
Nouveau may have to add special code to detect the chipset, and if it detects
certain known VIA Technologies chipsets, it should turn off AGP 4X mode (i.e.,
run at 2X mode).
I do not know if VIA Technologies really fixed the AGP for these chipsets, or
perhaps they fixed it with their newer chipsets.
I hope this information adds to the discussion.
Regards,
fpgahardwareengineer</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>