Very Computer

Hi there,

until now I wasted approx. 30 hrs trying to install FreeBSD 2.1.0R on
a DEC Prioris LX 590 server.

It's a combined PCI/EISA machine with networking and SCSI 2 on board.
Chipset is Intel Neptune. HD is a Seagate Medalist 1080sl (1 GB), as
tape we use a HP C1536A DAT drive, CD-ROM is a Toshiba XM5301. All
this SCSI stuff is hooked up to the onboard Adaptec AIC7850. Not too
bad, really. But FreeBSD 2.1 refuses to install on it.

After booting from FD I'm able to go through the setup procedure
(partitioning, file systems, package selection) just until the end
when I'm asked from what kind of media I wish to do the install.
Whatever I select: A small window ("Writing partition information to
drive sd0") pops up and the install hangs.

In the Phoenix BIOS I set HD access mode to either "DOS" or "Other"
with no avail. Extended BIOS translation has been disabled (our HD has
1030 cylinders). But even if I set it to enabled, there's no
difference.

I really want to exchange our old comm server (a 386/40 running
FreeBSD 1.1.5R) for something better. Please, if anybody is able to
give me a clue, I would be most grateful.

Thanks in advance, Uwe

--
Uwe Gruentjes, GfS mbH, Abt. EDV, Luschendorf, Germany
Voice +49 4504 8100 36    Fax +49 4504 8100 37

--
cheers, J"org

Never trust an operating system you don't have sources for. ;-)

        The information in this guide applies to the following Adaptec                  
        PCI-to-SCSI host adapters, which are referred to collectively as the
        Adaptec 7800 Family host adapters:

        - AHA-2940 PCI-to-Fast SCSI
        - AHA-2940W PCI-to-Fast and Wide Single-ended SCSI
        - AHA-2944W PCI-to-Fast and Wide Differential SCSI
        - AHA-3940 MultiChannel SCSI-to-PCI
        - AHA-3940W MultiChannel Wide SCSI-to-PCI
        - AIC-7850 single-chip PCI-to-Fast SCSI
        - AIC-7870 single-chip PCI-to-Fast and Wide SCSI

Therefore as you can see this controller is PCI and should be AHA-2940
compatible (?) except that it's a single-chip version.

doesn't support this controller. He told me to try 2.2-960501-SNAP ...

[ Posted and eMailed ]

Regards, Uwe

--
Uwe Gruentjes, GfS mbH, Abt. EDV, Luschendorf, Germany
Voice +49 4504 8100 36    Fax +49 4504 8100 37

--
cheers, J"org

Never trust an operating system you don't have sources for. ;-)

I think I will have to live with 2.2-SNAP until 2.2R becomes available
(or even longer; remember, we're upgrading from the last 4.3 based and
_very_ stable release). With the 2.1 compatibility package I can run
most 2.1 applications. I don't know yet if 2.2-SNAP is buggy, but I
think we'll find out pretty soon.

Thanks to all for your help and for one of the best OS available.

Uwe

--
Uwe Gruentjes, DSW SECURITY Management GmbH, Abt. EDV CIT
Voice +49 4504 8100 36    Fax +49 4504 8100 37

]

] >Ah, yes, i remember that some of the newer controllers aren't
] >supported by stock 2.1R.  When in doubt, it's perhaps the best to ask
] >the maintainer of the ahc driver.  You should also not that he
] >back-ported his changes from -current to -stable, means that you can
] >use them even in a ``less development-like'' system.
]
] Meanwhile I managed to install 2.2-960501-SNAP without problems. In
] the process I noticed that 2.2-SNAP probes for PCI devices before it
] looks for ISA devices, while 2.1R does look for ISA devices first.
] Maybe it has something to do with this order of bus probing.

More likely, the controller wasn't supported by the driver in
the older release.

The probe order change was because PCI devices are
non-destructively probe-able, and changing the order let
BSD find the non-destructively probe-able devices and map
their resources out of the "possible" list for destructive
ISA probes.

The net effect is that ISA probes that used to be dangerous
for some exiting PCI (EISA/MCA/PCMCIA/ISA PnP/etc.) devices
will no longer break anything (other than other bogus ISA
devices).  This is part of a move to a unified, deterministic
probe architecture that has been a long term project that
is only now starting to bear some *significant* fruit.

If anything, this has caused some problems with machines
that weren't strictly conformant with the 2.x PCI spec, but
liked and said they were (ie: some Compaq systems).  I
believe this is all fixed via bridge chipset detection
(ie: we know when the Compaq PCI data is lying to us).

In any case, if it's causing less problems for you, it's
probably unrelated to the controller problem you were
seeing.

                                        Terry Lambert

---
Any opinions in this posting are my own and not those of my present
or previous employers.