Hi Again,
In reply to Eddie, I believe you have to be using the on board esp SCSI to trigger the bug. Everyone that has replied and doesn't have a problem isn't using the onboard SCSI it seems. I think it is also dependant on the disk used, as I have fujitsu drives that behave much worse than the IBM one I currently have installed. It seems the best way to go currently is to use another SCSI card or netboot your machine with an NFS root. I'll probably go the netboot route eventually.
It took me a little longer to get to do some testing, I had other stuff going on. The -current build I had didn't turn out as well as the daily binary I downloaded, it froze fairly quickly, but I believe it may have been my fault as I built it using my own configuration, which basically removes drivers for hardware my machine doesn't have as well as the dbri driver which doesn't work with a MP kernel. Is it possible it froze because of that missing driver(s)?
So when it came to building the patched 7 kernel I built both a
generic.mp and custom kernel (same configuration) and gave both a whirl. The
generic.mp with the patch applied was as good as the daily binary I downloaded, which is good news. Essentially the machine worked through everything I tested, ran at idle all night (~7-8 hours) and in the morning only froze on a particular program. The program in question is the fstime portion of the bytebench package, it ran the first time (just after boot) so I don't know what can really be blamed second time round.
The custom kernel froze fairly quickly, less than a minute, when running 3 dd instances putting load on the disk. Which confirms for me that at the moment at least you need to ensure any custom kernel has drivers for all your hardware. I had excluded the dbri driver because it doesn't work with MP kernels, and wished essentially to disable it so programs wouldn't try to use sound. I'll just have to find another way to disable it.