On 3/13/21 5:42 AM, Adam Nielsen via Freedos-user wrote:
As I said before, I suspect what's happening is that the adapter
is detecting something that the BIOS is doing while trying to figure
out the capacity of the disk, and "helpfully" setting up an HPA on
the drive (and doing so so aggressively that all but a thousandth of
the capacity of the disk is lost).
It wouldn't be a Host Protected Area (HPA) as that by definition is an
area the host (PC) can't access under normal conditions.
The thing is, an HPA can be either "permanent" or "temporary" (the former
case is the default power-on capacity of the drive until the HPA is next
resized, the latter lasts only as long as the drive remains powered).
I suspect in this case that the adapter is detecting that the BIOS is
struggling
with the disk size, and "helpfully" setting up a very small HPA on the disk.
Each time an the IDE standard was changed to work around a limitation,
the standard dictated what to set in the "old" variables which
typically were the maximum value possible. So if you plug in a 200 GB
disk, a PC with a 504MB limit will see a 504MB disk, a system with a
137GB limit will see a 137GB disk, etc. So the device wouldn't have to
do anything special to support an old BIOS.
That is indeed what *should* be happening, but I don't think it is.
1) The BIOS in this machine has a 504 MB limit for manually configured
drive geometries, but will autodetect some larger geometries (up to a limit
I've not yet determined. Often a disk will be detected at something larger
than 504 MB but smaller than 8GB, and for most disks, it's different, but
generally smaller than the actual size of the drive). However, the
autodetected size of the drive in question is only 130 MB.
It might, however, have gotten these fixed values wrong. Since modern
systems ignore all the obsolete capacity fields if newer ones are
present, they wouldn't notice any mistake. But if your system is
looking at one of the old capacity fields and seeing the wrong values,
perhaps this is why.
That could easily be the case for the BIOS, but past kernel version 2.5
Linux is supposed to ignore BIOS information and get the size of the disk
directly from the disk. All the Linux kernels I've tried to boot are 2.6
kernels. And the kernel isn't subject to any of the old BIOS limitations,
so when it asks the disk it should be asking for the newer capacity fields,
and should be getting the full size of the disk. This is indeed what
happens when the disk is plugged in to a machine with a newer BIOS. The
same applies to OnTrack: it's entire reason for existence is to get disk
size information from the disk directly and to intercept BIOS calls for
access to large disks that the BIOS would mishandle. So there is no reason
it should be seeing the same crippled total disk size that BIOS sees unless
the disk (or the SATA adapter) is lying about the total size of the disk.
Since this doesn't occur on a machine with a newer BIOS, I think that the
adapter is picking up on something the old BIOS is doing and is trying to
"help" by telling the drive to set a temporary HPA. Once that happens, the
drive under-reports its size to software that can handle the actual size,
and refuses reads/writes to LBA values in the HPA.
I imagine a diagnostic program might be able to do some probing for IDE
devices and show what values are reported by which fields.
On a newer machine, hdparm shows CHS values totaling to 8 GB, and LBA values
totaling to the correct size of the disk. On the machine in question, I
haven't
been able to get a Linux instance with hdparm available booted (the Debian
installer CD I'm booting from doesn't have hdparm, and the Linux instance
I'm trying to bring up on disk won't boot).
These also
bypass the BIOS and talk to the hardware directly. I used HWINFO to
diagnose an issue on a PC once where a drive wasn't visible, and it
turned out the PnP ICU I was using had moved the IDE port to the
tertiary spot which the BIOS didn't support. So that one definitely
bypasses the BIOS as it could see the drive on the 3rd IDE controller
the BIOS didn't know about.
The machine has 40 MiB of RAM installed. I notice that all three
boards show a maximum capacity of 128 MiB of RAM. If I could ever
find compatible RAM, that's a tempting option.
Is it 72-pin RAM, in pairs? Most Pentium boards were. Although it's
becoming less common, it still comes up pretty regularly on eBay where
I am. Curious how you get to 40 MB if it's in pairs though as it's not
a power of 2, unless it's 48 MB and the video adapter is stealing 8 MB
for itself or something like that.
One of my replies to Liam has some links to motherboards that are candidates
to be the one in this machine, with the 40 MB configuration given as 4M * 36
on the first two banks and either 1M * 36 on the 3rd and 4th, or 2M * 36 on
the third.
Unless I buy an entirely new optical drive, that will at least stay
on IDE, as all the SATA optical drives in the house are in use by
other computers. OTOH, the prospect of actually being able to boot
the thing directly from optical is enticing.
You can get IDE/SATA converters quite cheaply. I bought a few of
these ones as they cost me under $5 each including shipping, and they
are bidirectional, allowing IDE drives to plug into SATA controllers,
but also allowing (one) SATA drive to plug into an IDE controller:
https://www.aliexpress.com/item/4000263683410.html
You don't have another old IDE drive larger than 130 MB you could plug
in just to rule out the BIOS as the problem?
I have various such drives. The BIOS *is* a problem, but there's something
going on beyond *just* the BIOS being a problem: it should be surmountable
for Linux/OnTrack at the very least, and it's not. Anyway, one of the drives
I have is 40 GB direct IDE (no SATA adapter), and BIOS sees a size of
something like 1.3 GB, while Linux and OnTrack see the full real size of the
drive. A ~300 GB SATA drive on the same adapter shows the same size +/- a
megabyte or so (one shows 130 MB, the other shows 131) for both BIOS and
OnTrack, whereas drives attached without the adapter will tend to autodetect
at various different sizes in BIOS, and to be seen by Linux/OnTrack at their
actual sizes. This is why I suspect that the adapter is pulling some kind of
monkey business trying to "help".
I think the next thing I'll try for the older machine is Liam's
suggestion of
a PCI SATA card. If that works, I'll probably just use the IDE/SATA adapter
I already have on the newer machine where I know that it works without
issue.
It really sounds to me like the SSD is just reporting the wrong values.
Does the manufacturer have any configuration programs you can use?
Many drives can have their capacity reprogrammed to work in
environments where a specific size is required (e.g. an existing RAID
array) so experimenting with that could be an option.
On the newer machine that detects the full size of the drive, stock Linux
hdparm can be used to set a permanent HPA that is honored on the next boot.
This has no effect on the crippled capacity seen by BIOS/Linux/OnTrack on
the older machine.
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
