PE> Amibios says that they are:

PE> 826 16 63
PE> 1050 16 63
PE> 4969 16 63
PE> 4969 16 63

RS> Presumably you meant that thats what the bios says in
RS> the autoidentify, 

That is correct.

RS> in the normal mode, without LBA enabled.

It makes no difference whether I use normal mode or not, it always comes up
with the same parameters in the auto-identify.

PE> My program says that they are:

PE> 825 16 64
PE> 524 32 64
PE> 873 16 64
PE> 873 16 64

RS> The difference of one in the cylinder count with the first drive
RS> is complicated. There is a reserved maintenance cylinder as far
RS> as DOS is concerned. So you do usually find that the manufacturers
RS> label data on the drive itself is one more than the bios finds with
RS> an autoidentify. Tho some of the manufacturers have started to make
RS> those numbers match because of the confusion that can cause.

Hey, I paid good money for that 1 cylinder.  I am glad I'm not the
manufacturer having to decide whether to set the parameters assuming first
or non-first drive.

RS> The 63/64 with the sectors is just because DOS numbers those from 0, not 1.
RS> Just to fuck things up completely, the head number from 1, not 0. Bizarre.

You didn't actually state here that it IS 63/64, just that there is an
issue regarding 63/64.  I already know there is an issue.

RS> The Sirrocco data is certainly rather odd. OTOH presumably FDISK does
RS> see the full capacity of the drive, so it cant actually be seeing those
RS> numbers you list. 

Good point.  You are right, fdisk does see the lot.  It just won't let me
select >504 meg for my installable partitions.

RS> Come to think of it, I dunno what the OS/2 FDISK does
RS> specifically about that stuff, whether it notices that LBA is enabled and
RS> just uses the maximum block number and ignores that CHS data completely.

"uses the maximum block number" is outside my understanding of fdisk.

RS> And you dont say just how you ran that program, it doesnt prove too
RS> much if you ran it inside OS/2, 

I ran it in a DOS box under OS/2.

RS> as far as what the bios itself reports.
RS> You really need to run it with plain booted DOS atleast, say from a floppy.

Did that.  Got very interesting results indeed!

RS> Just what INT 13 reports is complicated by a wide variety of issues.

PE> Note that 4969 % 1024 = 873.

RS> God knows what you mean here.

C syntax is "%" means remainder.  4969 divided by 1024 gives 4,
with a remainder of 873.  The remainder is what is being reported to me by
the OS/2 bios.  Coincidence?  Unlikely.  Bug?  Very likely.

PE> I therefor conclude that there is a bug in Amibios
PE> that is causing LBA to not remap the drive correctly.

RS> Thats a pretty rash conclusion at this stage.

Hey, how was I supposed to know that OS/2 was intercepting the BIOS! If I'd
known that, I would have said "OS/2 or Amibios".

PE> Note that LBA on the 540 meg drive is
PE> working fine, as the figures above show.

RS> Well, there certainly is some problem with the Siroccos, but just
RS> where that problem lies is another matter entirely at this stage.

OS/2!

PE> BTW, can you tell me whether there are 63 or 64 sectors
PE> per track. I added 1 to get the # heads right, but not
PE> sure if I should do the same with sectors.

RS> See above.

You could have just given me a straight answer to the question. There are
either 63 sectors per track or there are 64.  In my program I assumed 64. 
Is that correct?  (YES/NO).

Ok, here's the results of running my test program after booting from a floppy:

825  16 64
524  32 64
620 128 64      (was 873 16 64)
768  16 64      (was 873 16 64)

Note that 768*16*64*512/1024/1024 = 384 meg.  This doesn't make any sense
to me, why would DOS be reporting that, instead of the full 504 meg it is
allowed?  ie 1024 cylinders.

Note that the third drive has LBA enabled, whilst the fourth DOESN'T.
OS/2's BIOS still reports the same figures for the 3rd + 4th drive.

Also note that I need to disable LBA on the 4th drive, because otherwise
the partitions do not become visible to boot manager and I cannot use boot
manager to boot my Linux partition.  Note that regardless of LBA setting, I
am able to boot Linux by using a floppy disk as a replacement to Boot
Manager.

Conclusions:

1. OS/2 is fucked when running from an LBA drive > 2 gig, as documented.
2. OS/2's boot manager is fucked when querying an LBA drive > 2 gig.
3. The reboot-straight-away-from-specified-drive command is fucked on
either my motherboard or OS/2.
4. My motherboard knows how to do LBA.


I still have one anomaly though - what happens to my HPFS partitions in
this changeover?  Ie who was responsible for fucking up my big HPFS
partition in the first place?  I enabled LBA, I assume I could read the
data fine, then I installed OS/2, which managed to write ~7 disks fine,
then whammo, the data was gone.  At least with FAT
the data seems to stick around, and OS/2 at least manages to get its logo up.

Next question - I've seen the APAR, I've downloaded the fixpack, now how do
I fix WHAT?  It is obvious that I need bootmanager fixed. But how do I get
the fixpack to fix bootmanager?!  What file is boot manager?  Part of
fdisk?  Good idea, I'll try running a patched fdisk and see what happens. 
I don't know how I'm meant to patch the rest of OS/2 to fix the rest of the
install problems though.  The fixpack is meant to fix an installed OS/2,
catch 22 and all that!  BFN.  Paul.


rc is 0
tracks is 825
sectors is 64
heads is 16
attached is 4
drivetype is 186
rc is 0
tracks is 524
sectors is 64
heads is 32
attached is 4
drivetype is 186
rc is 0
tracks is 620
sectors is 64
heads is 128
attached is 4
drivetype is 186
rc is 0
tracks is 768
sectors is 64
heads is 16
attached is 4
drivetype is 186
@EOT:

---