I've played around changing the spinloop to using DELAY (like the Linux model),
but this didn't prevent the controller from either "just" locking up or
crashing the whole machine with it. Changing various other places in a similar
manner (like replacing the bcopy() in amr_quartz_get_work() with s
> I've found the easiest way to wedge the box is to perform a 'cvs up'
> (not cvsup) from a local repository over /usr/src or /usr/ports, this
> would always lockup my box with amr, if you have the time and disk
> space that would be a much better stressor than just make world.
I have done a cvs
> Can you try instead the changes that I just committed to -current? I
> think that the problem shows up when the controller is heavily loaded;
> your patch will keep the load on the controller down, which may mask the
> 'real' bug.
I tried your approach (that was what I described with "fiddl
> The BIOS RAID on the HPT370 and the Promise Fasttrak's are now supported
> both under stable and current. Let me know if doesn't work for you...
As far as I can tell, the ar-device hasn't been added to sysinstall/devices.c
yet, so currently I don't see how you could install a system on a HPT370
> OK, i tested this. Sysinstall works fine now, and the system installs OK
> from the SNAP 5 ftp server. ON reboot, however, the computer thing refuses
> to boot of the RAID device. After the BIOS message "verifying
> DMI.."(or similar) the system hangs.
Because of the offset 10, sysinstall w
