(Continued from previous message)


PE> There are either 63 sectors per track or there are 64.

There are 63, they are numbered from 0 instead of 1.

PE> In my program I assumed 64.  Is that correct?  (YES/NO).

Depends entirely on whether you are talking about the total number of sectors,
or if you are talking about the maximum value the sector number can get to.

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

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

Whoops, rather odd difference between two physically identical drives.

The first one makes sense, keep doubling the heads until the cylinders
goes below 1025, int it, subtract one for the maint cylinder.

The second one is completely fucked, nothing like enough total sectors.

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

PE> Note that the third drive has LBA enabled, whilst the fourth DOESN'T.

Yeah, that will be it for sure. Tho that would normally result in DOS just
truncating the cylinder number down to 1023, retaining the head number that
the autoidentify found. Not at all clear where its getting the 768 from.
Maybe thats coming from the first physical sector on that drive, the result
of that farting with params around without zeroing out the first sector.

PE> OS/2's BIOS still reports the same figures for the 3rd + 4th drive.

Which also supports the proposition that its some quirk
of DOS with the data out of the first physical sector
on the drive which OS2 isnt bothering with but DOS is.

PE> Also note that I need to disable LBA on the 4th drive, because
PE> otherwise the partitions do not become visible to boot manager
PE> and I cannot use boot manager to boot my Linux partition.

Presumably you mean the Warp boot manager.

PE> Note that regardless of LBA setting, I am able to boot Linux
PE> by using a floppy disk as a replacement to Boot Manager.

Which certainly indicates some significant problem with the Warp BM.

PE> Conclusions:

PE> 1. OS/2 is fucked when running from an LBA drive > 2 gig, as documented.

Was it really that specific ?

PE> 2. OS/2's boot manager is fucked when querying an LBA drive > 2 gig.

True.

PE> 3. The reboot-straight-away-from-specified-drive
PE> command is fucked on either my motherboard or OS/2.

Almost certainly OS2 given the two above.

PE> 4. My motherboard knows how to do LBA.

Yeah, it would have been very surprising if it did not.

PE> I still have one anomaly though - what happens to my HPFS
PE> partitions in this changeover?  Ie who was responsible
PE> for fucking up my big HPFS partition in the first place?

Presumably that reboot part way thru the install of Warp managed
to use the wrong params for that drive when it rebooted, and so
for that partition, and so rooted the data on it. Hardly surprising
that the wrong params root the directory structures etc.

PE> I enabled LBA, I assume I could read the data fine, then I installed
PE> OS/2, which managed to write ~7 disks fine, then whammo, the data
PE> was gone.  At least with FAT the data seems to stick around,

Probably no great significance in that, just
the effect of the dud params is different.

PE> and OS/2 at least manages to get its logo up.

Just another side effect of the directory structure not going bye bye.

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

Classic situation in which you get to put the boot into IBM for some answers.
@EOT:

---