<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <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#c24">Comment # 24</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 <a class="email" href="mailto:detringj@gmail.com" title="Jason Detring <detringj@gmail.com>"> Jason Detring</a> <pre>Ah, yeah, sorry about that. This ticket got away from me. I've got a small pile of research and resources I'd promised myself to post Real Soon Now. So I guess I should. I haven't reinstalled the blob, but from what I recall it did work without problems last time it was loaded. I don't remember if it left a console message describing which AGP mode it was running at, but it likely had the 2x limiter since those drivers were from 2009. Answering the big question: yes. Setting agpmode=2 makes things stable. Hooray. But it is sort of a hollow victory to say things work great at half-speed. As fpgahardwareengineer said, the problem is likely in the KT133. The linked NVIDIA document points to the AGP signalling drive strength being insufficent. Following up on "AGP drive strength", I found copies of a document called the "BIOS Optimization Guide" floating around the internet. Parts of it are reposted on various bulletin boards [1] [2] [3] [4] and websites [5] [6]. An older version talks about upping the drive strength from 0xCA or 0xDA to 0xEA or 0xEE when running GeForce boards. [1] <a href="http://forums.pcper.com/showthread.php?99837-A7M266-Infinite-Loop-Troubleshooting-(detailed)&p=681721#post681721">http://forums.pcper.com/showthread.php?99837-A7M266-Infinite-Loop-Troubleshooting-(detailed)&p=681721#post681721</a> [2] <a href="http://www.rage3d.com/board/showpost.php?p=1331276579&postcount=2">http://www.rage3d.com/board/showpost.php?p=1331276579&postcount=2</a> [3] <a href="http://www.scrigroup.com/calculatoare/tutorials/414/OPTIMIZING-WINDOWS-TIPS64128.php">http://www.scrigroup.com/calculatoare/tutorials/414/OPTIMIZING-WINDOWS-TIPS64128.php</a> [4] <a href="http://arstechnica.com/civis/viewtopic.php?f=8&t=737578">http://arstechnica.com/civis/viewtopic.php?f=8&t=737578</a> [5] <a href="http://hardwarehell.com/articles/videobios.htm">http://hardwarehell.com/articles/videobios.htm</a> [6] <a href="http://archive.arstechnica.com/guide/building/bios/m-bios-3.html">http://archive.arstechnica.com/guide/building/bios/m-bios-3.html</a> It also sounds like ATI had a similiar problem and did a thorough investigation at one point [7]. Their solution was to force down to 2x mode on a chipset blacklist, and only allow 4x if the "VIA chipset driver" had been installed. The advisory document talks about something called the "AGP Read Synchronization bit" needing set at register 0xAC[6]. I'm guessing this chipset driver is some combination of this read synchronization register poke or the abovementioned drive strength register poke. [7] <a href="http://www.rage3d.com/board/showthread.php?p=1331422045#post1331422045">http://www.rage3d.com/board/showthread.php?p=1331422045#post1331422045</a> The ATI document is slightly at odds with the KT133(a) programmer's guide [8], which lists 0xAC[6] as "CPU Stall on AGP command FIFO GART Address Request", but I didn't see anything else remotely resembling a "Read synchronization bit". [8] <a href="http://gkernel.sourceforge.net/specs/via/KT133a.pdf.bz2">http://gkernel.sourceforge.net/specs/via/KT133a.pdf.bz2</a> So, I tried testing these theories. It didn't go so well. 1. My BIOS has a pretty spartan set of options since the PC is a mass-market consumer box. There was no option to adjust AGP drive strength. Darn. 2. I tried to adjust the drive strength while Linux was running. According to the VIA doc, AGP drive strength is set from PCI register 0xB1[7-0]. It looks like this entire register is the P Ctrl and N Ctrl values for drive strength. On the console with nouveau already loaded, I wrote 0xEA. Nothing broke, so I started X. It had the same lockup as usual. Darn. I tried 0xEB through 0xEE as well. No good. 3. I tried to adjust the read synchronization bit. It was already set. So, no use in that. Presently, I'm stuck. There's not a whole lot else I can think of that might be worth trying. Maybe there's some commit register or reinit procedure that needs to take place after writing the drive strength? I don't know enough about AGP to figure out where to go next. At this time, I agree with fpgahardwareengineer's assessment. A quirk for those chipsets listed in the ATI doc should be added to allow negotiation up to AGP 2x maximum. It is the safest option in all cases. Maybe at the same time leave a note in the dmesg describing "buggy chipset detected, defaulting to 2x, please read fd.o <a class="bz_bug_link bz_status_REOPENED " title="REOPENED --- - [NV31] lockup when using AGP. agpmode=0 fixes it." href="show_bug.cgi?id=20341">bug 20341</a> for more information", and also allow agpmode=4 to override the safe default. I'm not sure whether this quirk should be in nouveau or in via-agp.ko, since it sounds like the problem affects all major vendors.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>