the 333mhz problem
 

The following is how my friend Aceman and I were able to solve our high FSB problem on his NF7-S. As I posted earlier, we have not had the time to test this with multiple boards or chips, and were going to wait until we had done that before jumping to conclusions. We can not be sure this will solve everyones' problem, but feel that it should work. If you break anything, it is your fault . We can not do the testing I wanted to until the day after Christmas, but since everyone wanted to hear what we had come up with, I am posting our results and how we arrived at them. I apologize for the length. As I had posted earlier, my friend Aceman and I had been able to easily run high FSB speeds (220+ MHz) with his XP2200 in his NF7-S. When trying to run my XP2700 we were getting the exact same problems I saw many people here posting: corruption messages and errors when attempting any FSB even remotely high. Among others, two thoughts we had were:
1: The two different cores had different tolerances for high FSB, or
2: When lowering the multiplier on my 2700 when testing high FSB, the board was not correctly handling the multipliers.
The theory that my 2700 did not like high FSB was not coinciding with the fact that I have had the chip running in other boards at 200 MHz FSB before with no problems. I also noted that many people have stated this exact same scenario. We started trying to change the multiplier with the 5th L3 bridge unlocking trick, but that did not help. Next I tried manually connecting certain bridges to achieve a specific multiplier, which also failed. Still thinking about the possibility of differences in the cores affecting the FSB the chip could run in this board, we tried running an XP1900+ of mine in the NF7-S and it ran perfectly fine at the same FSB speeds as Aceman's 2200. Knowing that my 2700 could run higher FSB speeds in other boards, we started to think that maybe the NF7-S in particular has some problem handling my XP2700. I noticed too, that most people having this problem were also running the new family of chips (2600, 2700, etc...). We then started to look at the differences between the two chips and how they would be seen by the NF7-S. We attempted to find any differences in the "bridge" layout and settings between our older chips which seemed to run fine in the board, and the new chips, which seemed to be having trouble. For any differences we saw, we tried to trace down exactly what the bridges did. The best ones we found were the L12 bridges. On the 2200 and below, the 4 bridges ran cut-connected-cut-connected. On my 2700 and other new chips, they ran cut-connected-connected-connected. These bridges set the default FSB, with the former being 133, and the latter being 166. To test whether this affected the chip being able to run a high FSB in this board, I connected the third L12 bridge (one away from the "L12") on Aceman's 2200 - This would in effect make it look like a new XP2800 (166x13.5). We began testing and the chip was defaulting to a 166 FSB. We then procedded to make small increases in FSB in BIOS. We were hoping we would run into the problems that my 2700 was having. Sure enough, his chip could no longer run high FSB speeds. It started producing the exact same error screens and messages that my 2700 was, and at nearly identical FSB speeds. To further test, we pulled the 2200 out, and I broke the connection I had made on the third L12 bridge. We then immediately put the chip back in without changing anything else. The chip was instantly able to run 220+ FSB speeds again just like before. This really seemed like conclusive evidence that these bridges affected if a chip could run high FSB in this board. I then took a model knife (x-acto knife) and cut the third L12 bridge on my 2700. This made it match the factory setup of Aceman's 2200, and when we booted up, the chip did indeed default to a 133 MHz FSB. We started increasing the FSB with our fingers crossed, and I was amazed to see the chip booting perfectly fine as we started running all the way into the 200's! We tested what we could in the limited time we had, and the chip breezed through 3DMark at 220 MHz FSB. We did not have time to accomplish any in depth testing, but running Prime and Sandra at high FSB speeds was perfectly fine. It seems that by simply cutting the third L12 bridge, all of our problems were solved. We also noticed that we could run many different multipliers in his board with just the L12 bridge cut and no other modifications to the chip, but we did not have time to test every one. We were using one 512MB stick of XMS3500 for all of our FSB testing. Every single onboard device was enabled, including an IDE HDD and the SATA with two drives in RAID 0, which XP's swap file was stored on. I really wish we had had time to do more testing, but we hope this method will work on any of the new chips that have the L12 bridges set to default to 166 MHz FSB. If anyone tries this method, I would be interested in hearing the results. If I left anything out, I apologize - I have not slept since Sunday. Here is a picture of the bridge to cut, for clarification:

sorry for the long post, i've read this on xtremesystems

what do i really have to do, cut the bridge, what does this mean, is this just make a cut over the bridge?, so the to ends of metal don't make contact anymore?