Fdisk and disk size

Fdisk seems to be broken with big disks.

If I use disk_get_entry() to get info about a 30GB disk, the info
obtained shows:

./disk /dev/hd0

blk_offset = 0
num_sectors = 58633344
disk_sectors = 58633344
cylinders = 38778
heads = 16
track_sectors = 10
disk_type = 2
disk_drv = 0
reserved = [0 0 0]
driver_name = EIDE Drvr

size = 30020.3MB

Where size is disk_sectors * 512.0 / 1000000

If I use fdisk it reports C/H/S as 38778/16/10 and a size of 3029MB,
a factor of 10 too small. I imagine it got this by doing
C * H * S * 512 / (1024*1024)

(Note that the Linux big disk HOWTO says 1MB should be 10e6 not
1024*1024 which implies that fdisk is wrong here too.)

Am I wrong? I am using QNX 4.25E - is there a more recent version of
fdisk? Can one force fdisk to use LBA instead of CHS?

Where is disk_get_entry() getting its information from, the BIOS or
the disk itself (the latter would seem more reasonable)?

I mention this in relation to on-going problems installing on some big
disks (yes I know about the 1024 cylinder boot problem). How should I
partition and format these disks under QNX if fdisk is broken? Is
there a port of cfdisk anywhere?

Thanks in advance

William Morris
wrm@innovation-tk.com

Hi William,

How is the disk setup in the BIOS? It should be set to LBA in the BIOS.
It doesn’t sound like it is.

Erick.


William Morris <wrm@innovation-tk.com> wrote:

Fdisk seems to be broken with big disks.

If I use disk_get_entry() to get info about a 30GB disk, the info
obtained shows:

./disk /dev/hd0

blk_offset = 0
num_sectors = 58633344
disk_sectors = 58633344
cylinders = 38778
heads = 16
track_sectors = 10
disk_type = 2
disk_drv = 0
reserved = [0 0 0]
driver_name = EIDE Drvr

size = 30020.3MB

Where size is disk_sectors * 512.0 / 1000000

If I use fdisk it reports C/H/S as 38778/16/10 and a size of 3029MB,
a factor of 10 too small. I imagine it got this by doing
C * H * S * 512 / (1024*1024)

(Note that the Linux big disk HOWTO says 1MB should be 10e6 not
1024*1024 which implies that fdisk is wrong here too.)

Am I wrong? I am using QNX 4.25E - is there a more recent version of
fdisk? Can one force fdisk to use LBA instead of CHS?

Where is disk_get_entry() getting its information from, the BIOS or
the disk itself (the latter would seem more reasonable)?

I mention this in relation to on-going problems installing on some big
disks (yes I know about the 1024 cylinder boot problem). How should I
partition and format these disks under QNX if fdisk is broken? Is
there a port of cfdisk anywhere?

Thanks in advance

William Morris
wrm@innovation-tk.com

Hardware Support Account <hw@qnx.com> wrote:

Hi William,

How is the disk setup in the BIOS? It should be set to LBA in the BIOS.
It doesn’t sound like it is.

Erick

You had me worried there, but I went and checked a system and, yes,
according to the BIOS setup screens and the boot flash screen, LBA is
turned ON. But fdisk still gave the wrong result.

How does LBA manifest itself at run time? Is there a QNX function I
can use to check that LBA is really in use? Where does turning LBA
on in the BIOS take effect (disk or controller or …)?

Thanks for replying so quickly
Regards

William Morris
wrm@innovation-tk.com

Hi William

I don’t know what the dfeal is with the off by a facor of 10 issues is. And
in yoyur case, I think that that is significant. But, here is what I have
found in the past.

If the BIOS setup changes or the parameters passed to the Fsys.eide driver
change, then the disk needs to be repartitioned. I.E. know exactly what you
need to do before you do it.


Bill Caroselli – 1(530) 510-7292
Q-TPS Consulting
QTPS@EarthLink.net


“William Morris” <wrm@innovation-tk.com> wrote in message
news:9r6k6a$1ds$1@inn.qnx.com

Hardware Support Account <> hw@qnx.com> > wrote:
Hi William,

How is the disk setup in the BIOS? It should be set to LBA in the BIOS.
It doesn’t sound like it is.

Erick

You had me worried there, but I went and checked a system and, yes,
according to the BIOS setup screens and the boot flash screen, LBA is
turned ON. But fdisk still gave the wrong result.

How does LBA manifest itself at run time? Is there a QNX function I
can use to check that LBA is really in use? Where does turning LBA
on in the BIOS take effect (disk or controller or …)?

Thanks for replying so quickly
Regards

William Morris
wrm@innovation-tk.com

“Bill Caroselli (Q-TPS)” <qtps@earthlink.net> wrote:

Hi William

I don’t know what the deal is with the off by a facor of 10 issues is. And
in your case, I think that that is significant. But, here is what I have
found in the past.

If the BIOS setup changes or the parameters passed to the Fsys.eide driver
change, then the disk needs to be repartitioned. I.E. know exactly what you
need to do before you do it.

Bill

Thanks for the hint. In the case of the system I just looked at,
there is no existing partition, so "re"partitioning is not possible.

I think I know what you mean though. I have in the past got the
impression that once a good partition table has been written to a
disk (eg with Windows fdisk) that QNX fdisk then gets the right idea
about the disk size. This would imply that QNX fdisk knows how to
read partition tables but isn’t so good at reading disk geometry
info. It is probably pure superstition gained from sequences such as:

try QNX fdisk in installation script - failed
try QNX fdisk in installation script - failed
try QNX fdisk in installation script - failed
run Windows fdisk before running script - OK
try QNX fdisk in installation script - success

…therefore Window fdisk fixed the problem. But maybe it would have
worked the last time anyway.

Regards

William Morris
wrm@innovation-tk.com

William Morris <wrm@innovation-tk.com> wrote:

Hardware Support Account <> hw@qnx.com> > wrote:
Hi William,

How is the disk setup in the BIOS? It should be set to LBA in the BIOS.
It doesn’t sound like it is.

Erick

You had me worried there, but I went and checked a system and, yes,
according to the BIOS setup screens and the boot flash screen, LBA is
turned ON. But fdisk still gave the wrong result.

How does LBA manifest itself at run time? Is there a QNX function I
can use to check that LBA is really in use? Where does turning LBA
on in the BIOS take effect (disk or controller or …)?

Hi William,

LBA should take effect in the controller (you are changing how the system
see’s the attached device).

What you can do is in the BIOS you KNOW what the cyl, head, sec are. So
When you start Fsys, try forcing those values. Somehow the BIOS is reporting
the incorrect values to QNX. See if forcing the drive parameters helps or
not.

Thanks

Erick.


Thanks for replying so quickly
Regards

William Morris
wrm@innovation-tk.com

Hardware Support Account <hw@qnx.com> wrote:

What you can do is in the BIOS you KNOW what the cyl, head, sec are. So
When you start Fsys, try forcing those values. Somehow the BIOS is reporting
the incorrect values to QNX. See if forcing the drive parameters helps or
not.

Erick

You say that in the BIOS we KNOW the C/H/S. But C/H/S is obsolete and
for sizes above 7.8G, disks report 16383/16/63 by convention. So
assuming my new disks are doing that (any reason not to assume this?)
the BIOS must be getting some other info and turning that into an
obsolete C/H/S pattern to report to me and to QNX. But while it tells
me the truth, it lies to QNX… This is all rather strange.

It doesn’t explain how disk_get_entry(), which is part of QNX, is
getting a correct value for #sectors. Where does it get this from?
Why doesn’t Fsys use it and ignore the BIOS?

I have tried specifying C/H/S successfully in the past, but am unhappy
with it as a general installation solution. There are many disk sizes
out there and I want my installation tool to be usable by staff for
whom finding and specfying C/H/S is impractical.

Can I expect a future version of the filesystems to be “fixed” in this
respect?

Thanks again

William Morris
wrm@innovation-tk.com

Hi William,

I just tried out a 30GB Quantum Fireball AS harddisk under QNX 4.25E.

I set the mode to LBA which reported:

Cyls - 3649
Head - 255
Sec - 63

I then ran the OS, used the Fsys.eide driver (no options), then started
fdisk, which yielded:

Cyls - 3649
Head - 255
Sec - 63

Size: 28623 Mbytes

So I don’t think its fdisk that is broken.

I also tried passing the drive parameters to Fsys.eide and that seemed to
work.

Just so we both know we have the same versions:

fdisk 52062 Jan 16 1998


Your certain that LBA mode is on in the BIOS? Perhaps there is a bug
in your systems BIOS that doesn’t handle large drives correctly. Could
you possibly see if there is an update for your systems BIOS? or try this
on another motherboard?

E.


William Morris <wrm@innovation-tk.com> wrote:

Hardware Support Account <> hw@qnx.com> > wrote:
What you can do is in the BIOS you KNOW what the cyl, head, sec are. So
When you start Fsys, try forcing those values. Somehow the BIOS is reporting
the incorrect values to QNX. See if forcing the drive parameters helps or
not.

Erick

You say that in the BIOS we KNOW the C/H/S. But C/H/S is obsolete and
for sizes above 7.8G, disks report 16383/16/63 by convention. So
assuming my new disks are doing that (any reason not to assume this?)
the BIOS must be getting some other info and turning that into an
obsolete C/H/S pattern to report to me and to QNX. But while it tells
me the truth, it lies to QNX… This is all rather strange.

It doesn’t explain how disk_get_entry(), which is part of QNX, is
getting a correct value for #sectors. Where does it get this from?
Why doesn’t Fsys use it and ignore the BIOS?

I have tried specifying C/H/S successfully in the past, but am unhappy
with it as a general installation solution. There are many disk sizes
out there and I want my installation tool to be usable by staff for
whom finding and specfying C/H/S is impractical.

Can I expect a future version of the filesystems to be “fixed” in this
respect?

Thanks again

William Morris
wrm@innovation-tk.com

Hardware Support Account <hw@qnx.com> wrote:

Just so we both know we have the same versions:

fdisk 52062 Jan 16 1998

Yes, we have the same version.

Your certain that LBA mode is on in the BIOS?

Only if one believes the BIOS, which I’m beginning to think is
unwise. Is there no way to determine the mode from QNX?

Perhaps there is a bug in your systems BIOS that doesn’t handle
large drives correctly. Could you possibly see if there is an
update for your systems BIOS? or try this on another motherboard?

Mmm, you could be right. We are restricted to using an older
BIOS (2 years old) for some reason, so I will have trouble
trying this. Our “motherboard” is custom designed for our
application, so trying another type would be an invalid test.

I am not convined that fdisk, if not faulty, is not at least culpable
for ignoring the sector count available to it with disk_get_entry().

Thanks for all your help.

William Morris
wrm@innovation-tk.com