Excerpts from mail: 19-Dec-101 Re: Ultra 30 almost working by eeh@netbsd.org 
> Hm.  Interesting.  Let's see...  That's the maximum 35 msec retry
> interval.  You say you're getting SCSI timeouts?  SCSI timeouts 
> should be in the 1s range.  What other devices do you have and 
> what sort of load are you running?
This happens at boot, so there should be no load. I have 2 ST34371WC
disks and a scsi cdrom on one bus. It happens even if only one of the
ST34371WC's is present.

Here are the messages from a bad boot:
siop0 at pci0 dev 3 function 0: Symbios Logic 53c875 (ultra-wide scsi)
siop0: using on-board RAM                                               
       siop0: interrupting at ivec 20                                   
              scsibus0 at siop0: 16 targets, 8 luns per target
siop1 at pci0 dev 3 function 1: Symbios Logic 53c875 (ultra-wide scsi)
siop1: using on-board RAM
siop1: interrupting at ivec 26
scsibus1 at siop1: 16 targets, 8 luns per target
[...]
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 0 lun 0: <SEAGATE, ST34371W SUN4.2G, 7462> SCSI20/direc
sd0: 4094 MB, 3882 cyl, 16 head, 135 sec, 512 bytes/sect x 8385121 sectors
sd0: sync (50.0ns offset 15), 16-bit (40.000MB/s) transfers, tagged queueing 
probe(siop0:0:1:0): command timeout
[hang]
Interestingly, the kernel that the 20011205 snapshot installs doesn't
hang until after the root filesystem is mounted, whereas every other
kernel I've tried fails immediately after probing sd0.
  
> Let's see...  256 iterations of a 66.7Mhz clock is about a 3-6usec
> retry interval.  Well, I fail to see why tweaking this should have
> any influence on SCSI timeouts, but since you say it does let's try
> the following patch:

Not unexpectedly, this patch causes my machine to work fine.