Having run 1.2 into the turf, and getting one of those snazzy new UltraDMA 
drives with > 8 GB, and seeing 1.4D converted to ELF...I decided to migrate.

I have 1.2 still running on an old 1 GB SCSI drive (Micropolis MC4100), and 
have installed 1.4D on the UltraDMA drive (Maxtor 6800, 2-platter 12.67 GB, 
5400 RPM).

Issues that have arisen so far:

1.  The new boot sectors from FreeBSD, which use extended BIOS calls for LBA 
access (and thus let you boot from beyond 8 GB) work great.  I have 1.4D in a 
partition that occupies exactly all of the drive beyond 8 GB -- because I 
don't have any other OSes that can do that -- and am using the MBR menu as 
well.  It all just works.

Oddly, the latest FreeBSD release (3.3, mid-Sept) does not have this feature 
yet!  I had to install it down near DOS.  (I know, but I have no other use for 
all this drive space yet...)

Also oddly, Maxtor apparently numbers sectors starting with the innermost 
cylinder, because 1.4D seems to have the fastest partition.  (We won't mention 
the other possibility.)

2.  There is a problem with the 386BSD partition ID compatibility.  1.4D is 
able to see, mount and access my 1.2 partition over on the SCSI drive, and do 
all kinds of transfers without trouble, but is unable to _unmount_ that file 
system.  In fact, the unmount hangs -- whether on the command line or during 
shutdown -- and ultimately I must reboot unclean.

I haven't tried the FreeBSD partition on the (same) UDMA drive yet.

3.  The lost "pciide lost interrupt" problem:  In my opinion, this is not 
cabling, but the drive doing a thermal recalibration.  Notice everyone says 
this happens while doing a very large transfer of some kind.  It happens to me 
while extracting huge tarballs -- exactly once in mid-extraction.  This 
happens on my SCSI drive, but because that drive is so noisy I can tell it's a 
recalibration due to heat from the heavy use.  Because SCSI has a protocol, 
the driver knows not to complain.  This "UltraDMA" is just a controller pin 
connection, basically, so I guess the only way to make this go away is to use 
a longer timeout for _all_ transfers.

4.  There seems to be a problem with SCSI LUNs and CD-ROM drives.  I have an 
old TEAC, which an older version of ncr (backported into 1.2) thinks has 8 
LUNs.   1.4D, however, while booting reports several errors probing LUN 1 and 
gives up.  I did a new config with cd0 specified as LUN 0, because with LUN ? 
I was getting a kernel panic trying to load the cd9660 lkm.  With LUN 0 I can 
mount, access and unmount the CD-ROM fine, despite the boot time errors.


--Jim Howard  <jiho@mail.c-zone.net>