I just tried out the new ahc driver. All seemed fine (ran bonnie)
until I started building the world, and accessing a large file at
the same time. Unfortunately, the computer froze solidly, so all
I could do was restart, and nothing could be written to
/var/log/messages. The few clues are:

ahc0 at pci2 dev 8 function 0
ahc0: interrupting at irq 10
ahc0: aic7860: Ultra Single Channel A, SCSI Id=7, 3/253 SCBs
scsibus0 at ahc0: 8 targets, 8 luns per target
sd0 at scsibus0 target 0 lun 0: <IBM, DNES-318350, SA30> disk fixed
sd0: 17501 MB, 11474 cyl, 10 head, 312 sec, 512 bytes/sect x 35843670 sectors
sd0: sync (50.00ns offset 15), 8-bit (20.000MB/s) transfers, tagged queueing
sd1 at scsibus0 target 2 lun 0: <QUANTUM, XP34550S, LYK8> disk fixed
sd1: 4341 MB, 5899 cyl, 10 head, 150 sec, 512 bytes/sect x 8890760 sectors
sd1: sync (50.00ns offset 15), 8-bit (20.000MB/s) transfers, tagged queueing

/dev/sd0a on / type ffs (local)
/dev/sd0h on /usr type ffs (local)
/dev/sd0e on /var type ffs (local)
/dev/sd0f on /home type ffs (local)
/dev/sd0g on /usr/src type ffs (NFS exported, local)
/dev/sd1a on /altroot type ffs (local)
/dev/sd1e on /usr/obj type ffs (soft dependencies, local)
/dev/wd0a on /usr/local/pgsql type ffs (soft dependencies, local)

fsck found hardly anything wrong with the partitions, except for
/usr/obj, where it found plenty of duplicate inodes. Now, it is
hard to judge whether /usr/obj was "trashed" because it is the
one that was being written to most as there was a build going on,
or whether it is because it is the only SCSI partition mounted
with soft dependencies enabled.. I have not manually fsck'd the
/usr/obj, so maybe some more clues are still available there?
Thoughts on tracking this down? (April 16th kernel/userland is
all OK)

Cheers,

Patrick