Very Computer

Background:

Using 2 GB SCSI drive with old BIOS (AMIBIOS 1994 A775 020695 for SIS 85C50X
chipset, no known way to get an upgrade). SCSI adapter is Adaptec 1542.
Windows installs
and runs, but the only 1 GB is available. If the same disk drive is moved to
another system
with a newer BIOS, Windows is able to use the entire 2 GB.

RH Linux 7.2 installation on the same system (with the 1994 AMIBIOS) (with a
given custom
set of packages to install, removing all existing partitions) creates new
partitions using the full
2 GB. It fails to create /etc/grub.conf. /tmp/install.log shows problem
installing kernel-headers:

    unpacking of archive failed on file
    /usr/include/linux/hdreg.h; 3c020871 :
    cpio: MD5 sum mismatch

The install finally hangs at the end of kernel installation "unable to
handle kernel paging request".

Question 1 (top priority): Could someone familiar with BIOS internals please
explain (at the
pseudocode level) how the BIOS is involved in limiting the maximum supported
disk size.

Question 2 (top priority): Could someone familiar with Linux internals
please explain how
Linux relies on the BIOS (or, in this case, can fail to heed limitations in
the BIOS) in determining
the maximum practical effective drive size. (There seems to be an
opportunity here to improve
Linux.)

Question 3 (lower priority - knowledge is more valuable than results!): Any
suggestions for how
to make the Linux installation work, other than the obvious: 1. Replace the
disk drive with a
smaller one. 2. Upgrade the BIOS. 3. Replace the motherboard. 4. Modify
Linux source.

The AHA1542 series is notoriously nitpicking as far as the settings
of the adapter and the cableing used are concerened.

Quote:>Windows installs
>and runs, but the only 1 GB is available. If the same disk drive is moved to
>another system
>with a newer BIOS, Windows is able to use the entire 2 GB.

That's rubbish. The motherboard's BIOS is completely irrelevant as far
as the maximum partition size of a SCSI disk is concerned. It's up
to the settings of the SCSI adapter to provide support for DOS disks
above 1GB (there's a specific setting tro allow for that in the AHA1542
BIOS).

Quote:>RH Linux 7.2 installation on the same system (with the 1994 AMIBIOS) (with a
>given custom
>set of packages to install, removing all existing partitions) creates new
>partitions using the full
>2 GB. It fails to create /etc/grub.conf. /tmp/install.log shows problem
>installing kernel-headers:
>    unpacking of archive failed on file
>    /usr/include/linux/hdreg.h; 3c020871 :
>    cpio: MD5 sum mismatch

This is a setup error, which usually pinpoints to either
- faulty CDROM distribution media
- bad RAM
- bad CPU cooler or
- incorrect SCSI setup (termination)

Quote:>The install finally hangs at the end of kernel installation "unable to
>handle kernel paging request".
>Question 1 (top priority): Could someone familiar with BIOS internals
>please
>explain (at the
>pseudocode level) how the BIOS is involved in limiting the maximum
>supported
>disk size.

The motherboard's BIOS is irrelevant, as the BIOS support there is
just for the onboard EIDE adapters. Win* uses the BIOS information
to define the partition table layout and how to handle the disk,
but that's it.

A SCSI adapter has its own BIOS that manages the connected peripherals,
and therefor tells the OS installed what kind of devices are available
and how to deal with them (that is, if you have an adapter with support
for bootable media). With older operating systems, one needed to enable
support for DOS drives above 1GB manually; ISTR that in recent models
this option has been changed to the default behaviour.

Quote:>Question 2 (top priority): Could someone familiar with Linux internals
>please explain how
>Linux relies on the BIOS

It doesn't.

Quote:>(or, in this case, can fail to heed limitations in
>the BIOS) in determining
>the maximum practical effective drive size. (There seems to be an
>opportunity here to improve
>Linux.)

Linux queries the drives and/or the controllers itself. Again, your problem
is a hardware fault of sorts; it's not a generic Linux problem, nor
does it have anything to do with Linux per se.

Quote:>Question 3 (lower priority - knowledge is more valuable than results!): Any
>suggestions for how
>to make the Linux installation work, other than the obvious: 1. Replace the
>disk drive with a
>smaller one. 2. Upgrade the BIOS. 3. Replace the motherboard. 4. Modify
>Linux source.

None of the above. Correct your setup.

Michael

--

          Lumber Cartel Unit #456 (TINLC) & Official Netscum
    Note: If you want me to send you email, don't munge your address.

Michael,

Thank your for your very helpful reply. What you said about the role of the
1542 BIOS is
particularly interesting. Sorry about my overemphasis on the motherboard
BIOS, but this
was reinforced when RH support urged me to upgrade the motherboard BIOS to
fix the
problem.

Since this system has successfully run Win95 for years, interspersed with
short periods
when I successfully installed and ran three different, older versions of
Linux, I think it
somewhat unlikely that the problem is with termination, RAM, or cooling.
Back when
I wanted Windows to see the entire 2 GB, I also double-checked the
terminations.
Bad media may be a reason, but RH didn't think so.

Anyway, your explanation that a setting in the 1542 BIOS is incorrect is
definitely of interest.
It would explain why both Windows and Linux seem to have a problem utilizing
over 1 GB
of the drive. (I don't have a definite recollection, but I can easily
believe that my earlier,
successful Linux installations were small enough not to attempt to exceed 1
GB, while the
current installation probably did in some sense.)

The fact remains that Windows and the current Linux are behaving differently
in the face of
the alleged incorrect setting in the 1542 BIOS: Windows behaves entirely as
if the disk is
1 GB, whereas the Linux installation gets itself into trouble (under the
reasonable assumption
that the bus termination etc are still correct).

Now I just looked through the Adaptec AHA-1540B/1542B User's Manual (and it
is not
the first time). This book is Rev 1.1, May 1990. The jumper blocks have two
jumpers for
BIOS Address Select and twojumpers for BIOS Wait State Select, but I don't
see any
jumper relating to large-disk support. I have also looked at the description
of utilities
contained in the BIOS. Apparently there are only four functions: 1. List
devices, 2. low level
format, 3. Verify drive, 4. DMA channel test.  Do you remember how to access
the setting
for support of large disk drives? I would be grateful for any hint.

My next step is to actually run the 1542 utilities to see if there is
functionality not covered
in the manual.

Do you happen to know if there is a later version of the 1542, or a later
version of the BIOS,
where the support for larger drives was added?

Thanks again for the help.

Pleasure :-)

Quote:>What you said about the role of the
>1542 BIOS is
>particularly interesting. Sorry about my overemphasis on the motherboard
>BIOS, but this
>was reinforced when RH support urged me to upgrade the motherboard BIOS to
>fix the
>problem.

Uhuh. As noted before, the motherboard's BIOS supports booting from
devices _without_ separate BIOS functionality as provided by other
adapters. As long as you're booting of a SCSI disk that is connected
to a SCSI controller with BIOS, you may safely ignore the motherboard's
BIOS.

Quote:>Since this system has successfully run Win95 for years, interspersed with

This is, sad enough, irrelevant. Win* may run for years on broken
hardware without anyone noticing it.

Quote:>short periods
>when I successfully installed and ran three different, older versions of
>Linux,

That's better.

Quote:>I think it
>somewhat unlikely that the problem is with termination, RAM, or cooling.

True enough.

Quote:>Back when
>I wanted Windows to see the entire 2 GB, I also double-checked the
>terminations.
>Bad media may be a reason, but RH didn't think so.
>Anyway, your explanation that a setting in the 1542 BIOS is incorrect is
>definitely of interest.

A SCSI controller tells the OS about the layout of the drive _as it
sees it_. There is a difference in how IDE and SCSI controllers
interfere with the connected drives; an IDE controller is nothing else
but a mere data pump and IO device, whereas a SCSI controller is a
rather sophisticated subsystem.

[...]

Quote:>The fact remains that Windows and the current Linux are behaving differently
>in the face of
>the alleged incorrect setting in the 1542 BIOS: Windows behaves entirely as
>if the disk is
>1 GB, whereas the Linux installation gets itself into trouble (under the
>reasonable assumption
>that the bus termination etc are still correct).
>Now I just looked through the Adaptec AHA-1540B/1542B User's Manual

                                              ^^^^^^^^
[...]

That might explain a lot of things. I thought you were using the
1542C with menu-driven BIOS selection. That one definitely _has_
a separate setting for supporting DOS drives above 1G. The 1542B
may not support that at all, depending from the BIOS date.

Given the fact that this adapter is really obsolete (and broken in
many respects), I'd probably not invest too much time in trying
to fix it. A cheap PCI controller for roughly USD 60.-- will
do.

Michael
--

          Lumber Cartel Unit #456 (TINLC) & Official Netscum
    Note: If you want me to send you email, don't munge your address.