I just bumped into a flaw with fdisk. It doesn’t seem to use LBA as the
device size reference.
When the device CHS values disagree with the LBA value, in this case I
think CHS is all zero. Fdisk seems to make up it’s best guess for CHS
and then enforces those as the reference even when it doesn’t match the
LBA value, in this case reduced a 32 MB CF card down to 24 MB!
Any chance this might get some improvement in the not too distant future?
Evan Hillas <blarg@blarg.blarg> wrote:
I just bumped into a flaw with fdisk. It doesn’t seem to use LBA as the
device size reference.When the device CHS values disagree with the LBA value, in this case I
think CHS is all zero. Fdisk seems to make up it’s best guess for CHS
and then enforces those as the reference even when it doesn’t match the
LBA value, in this case reduced a 32 MB CF card down to 24 MB!Any chance this might get some improvement in the not too distant future?
Hm… not sure if this is fdisk, or devb-eide. I thought it was
the driver that got that information, and fdisk just asked the
driver for it.
If you know the geometry, take a look at the docs for devb-eide,
in particular the geometry= option.
Please follow-up to newsgroup, rather than personal email.
David Gibbs
QNX Training Services
dagibbs@qnx.com
David Gibbs wrote:
Evan Hillas <> blarg@blarg.blarg> > wrote:
I just bumped into a flaw with fdisk. It doesn’t seem to use LBA as the
device size reference.
When the device CHS values disagree with the LBA value, in this case I
think CHS is all zero. Fdisk seems to make up it’s best guess for CHS
and then enforces those as the reference even when it doesn’t match the
LBA value, in this case reduced a 32 MB CF card down to 24 MB!
Any chance this might get some improvement in the not too distant future?
Hm… not sure if this is fdisk, or devb-eide. I thought it was
the driver that got that information, and fdisk just asked the
driver for it.If you know the geometry, take a look at the docs for devb-eide,
in particular the geometry= option.
I suspect devb-eide doesn’t care beyond operating in the correct mode,
it’ll try to read and write whatever is asked of it. But yep, I’ve
tried the geometry numbers and lots of other switches too, fdisk ignores
them all.
Here’s the report I get with a completely zeroed clean CF card:
…
Physical disk characteristics: (/dev/hd1)
Disk type : Direct Access (0)
Cylinders : 3
Heads : 255
Sectors/Track : 63
Total Sectors : 62592
Warning: total sectors field does not agree with
cylinderssectors/trackheads!! (62592 vs 48195)
As you can see, 48195 == 3 * 255 * 63, which does not equal the LBA
number of 62592.
I’m quite confident the problem is 100% in fdisk’s court. Btw: I did
reset the capacity back to the correct 30.5 MB by wiping the bootblocks
and giving the blank CF card to MSDOG’s FDISK.EXE and setting up a dos
partition on it. After that when I run QNX’s fdisk I get:
Physical disk characteristics: (/dev/hd1)
Disk type : Direct Access (0)
Cylinders : 489
Heads : 4
Sectors/Track : 32
Total Sectors : 62592
Funnily, this is a matching set of numbers, 62592 == 489 * 4 * 32. 
Cheers,
Evan
Evan Hillas wrote:
I’m quite confident the problem is 100% in fdisk’s court.
No. fdisk uses only the geometry advertised by the devb driver in a
DCMD_CAM_DEVINFO query and does not invent one itself. devb itself will
use a variety of different sources to determine the disk geometry: the
ATA_IDENTIFY, the BIOS, an existing partition table configuration, the
geometry= option.
Btw: I did
reset the capacity back to the correct 30.5 MB by wiping the bootblocks
and giving the blank CF card to MSDOG’s FDISK.EXE and setting up a dos
Sounds as if either the CF is not correctly responding to ATA_IDENTIFY
or devb is not interpretting it correctly (is there anything in sloginfo
about this?), and that the fallback mechanism (eg partition table) was
incorrect (until another fdisk wrote some valid values which were then
picked up). The disk driver guy will have to comment. But fdisks only
source for the CHS geometry is from devb.
John Garvey wrote:
Evan Hillas wrote:
I’m quite confident the problem is 100% in fdisk’s court.No. fdisk uses only the geometry advertised by the devb driver in a
DCMD_CAM_DEVINFO query and does not invent one itself.
Okay, scratch that one. It’s about time the CHS thing disappeared from
user sight though.
devb itself will
use a variety of different sources to determine the disk geometry: the
ATA_IDENTIFY, the BIOS, an existing partition table configuration, the
geometry= option.
I would hazard a guess that geometry= should be an override setting but
it certainly isn’t doing so.
Btw: I did reset the capacity back to the correct 30.5 MB by wiping
the bootblocks and giving the blank CF card to MSDOG’s FDISK.EXE and
setting up a dos
Sounds as if either the CF is not correctly responding to ATA_IDENTIFY
or devb is not interpretting it correctly (is there anything in sloginfo
about this?), and that the fallback mechanism (eg partition table) was
incorrect (until another fdisk wrote some valid values which were then
picked up). The disk driver guy will have to comment. But fdisks only
source for the CHS geometry is from devb.
That makes sense. Just that the LBA value listed by fdisk is correct
and that devb-eide should be choosing LBA over CHS unless it has a very
good reason not to, ie: me specifying a geometry= parameter.
Thanks for the feedback,
Evan
John Garvey wrote:
Sounds as if either the CF is not correctly responding to ATA_IDENTIFY
or devb is not interpretting it correctly (is there anything in sloginfo
about this?), and that the fallback mechanism (eg partition table) was
Here is the relevant slog info (Same result in both the wiped state and
the partitioned state):
Aug 29 22:21:34 2 19 0 eide_identify_devices: Generic IDE vid
0, did 0, class 0 rev 0, busno 0, dfunc 0
Aug 29 22:21:34 2 19 0 eide_identify_devices: cmd_addr 300,
cntl_addr 30c, irq 3, chnl 0, udma -1, mdma -1, sdma -1, pio 0
Aug 29 22:21:34 2 19 0 eide_display_devices: Hitachi ATA 6.1
tid 0, cable 40, max udma -1, cur udma -1, max mdma -1, cur mdma -1, max
sdma -1, cur sdma -1, pio 0, mblk 1
Aug 29 22:21:34 2 19 0 eide_init_devices: Hitachi ATA 6.1
path 0, tid 0, udma -1, mdma -1, sdma -1, pio 0, mblk 1
… A bunch of SCSI sense errors …
Aug 29 22:21:34 2 5 0 [00] SIM="" HBA=“Generic IDE”
Aug 29 22:21:34 2 5 0 [00,0,0] type=00 ver=01 resp=00
Hitachi ATA 6.1Rev
Let me add one more comment from experience.
The geometry on the devb-* must be set up correctly first.
If you find it necessary to change the geometry of the drive,
THEN YOU MUST REPARTITION THE DRIVE FROM SCRATCH!
Otherwise it just won’t work right.
In other words, the geometry that was in effect when the drive was
partitioned must match the geometry that is in effect when you try to
access the drive.
Evan Hillas <blarg@blarg.blarg> wrote:
EH > John Garvey wrote:
Sounds as if either the CF is not correctly responding to ATA_IDENTIFY
or devb is not interpretting it correctly (is there anything in sloginfo
about this?), and that the fallback mechanism (eg partition table) was
EH > Here is the relevant slog info (Same result in both the wiped state and
EH > the partitioned state):
EH > Aug 29 22:21:34 2 19 0 eide_identify_devices: Generic IDE vid
EH > 0, did 0, class 0 rev 0, busno 0, dfunc 0
EH > Aug 29 22:21:34 2 19 0 eide_identify_devices: cmd_addr 300,
EH > cntl_addr 30c, irq 3, chnl 0, udma -1, mdma -1, sdma -1, pio 0
EH > Aug 29 22:21:34 2 19 0 eide_display_devices: Hitachi ATA 6.1
EH > tid 0, cable 40, max udma -1, cur udma -1, max mdma -1, cur mdma -1, max
EH > sdma -1, cur sdma -1, pio 0, mblk 1
EH > Aug 29 22:21:34 2 19 0 eide_init_devices: Hitachi ATA 6.1
EH > path 0, tid 0, udma -1, mdma -1, sdma -1, pio 0, mblk 1
EH > … A bunch of SCSI sense errors …
EH > Aug 29 22:21:34 2 5 0 [00] SIM="" HBA=“Generic IDE”
EH > Aug 29 22:21:34 2 5 0 [00,0,0] type=00 ver=01 resp=00
EH > Hitachi ATA 6.1Rev
Bill Caroselli wrote:
If you find it necessary to change the geometry of the drive,
THEN YOU MUST REPARTITION THE DRIVE FROM SCRATCH!
Otherwise it just won’t work right.
Yep, re-partitioning from scratch is exactly the procedure I’m
attempting, that’s what I mean by wiping or zeroed clean.
I use, dd if=/dev/zero of=/dev/hd1 count=10000
Cheers,
Evan
Evan Hillas wrote:
Yep, re-partitioning from scratch is exactly the procedure I’m
attempting, that’s what I mean by wiping or zeroed clean.
I use, dd if=/dev/zero of=/dev/hd1 count=10000
The relevant information is kept within the first block, so you only
need “count=1”. Also, “fdisk -z” will zero the old partition table.
Need to reboot afterwards (or slay relevant disk driver), because devb
will have already read the old geometry. Note this is all because it
appears drive itself is not reporting correct geometry (or there is
otherwise some geometry mismatch) - “fdisk /dev/hd1 info” will show the
current configuration.
John Garvey wrote:
Evan Hillas wrote:
Yep, re-partitioning from scratch is exactly the procedure I’m
attempting, that’s what I mean by wiping or zeroed clean.
I use, dd if=/dev/zero of=/dev/hd1 count=10000
The relevant information is kept within the first block, so you only
need “count=1”. Also, “fdisk -z” will zero the old partition table.
Need to reboot afterwards (or slay relevant disk driver), because devb
will have already read the old geometry. Note this is all because it
appears drive itself is not reporting correct geometry (or there is
otherwise some geometry mismatch) - “fdisk /dev/hd1 info” will show the
current configuration.
yep, I’m slaying devb-eide each time.
I understand that the CF card is mis-reporting it’s CHS values but my
point is that it’s LBA value is correct and that LBA should be the
default value used by devb-eide anyway, ie: CHS should only be a
fall-back for ancient devices!
And devb-eide’s geometry= parameter doesn’t work either.
Evan Hillas wrote:
And devb-eide’s geometry= parameter doesn’t work either.
What is your invocation? I think you have to use it like:
“eide master=geometry=…” (or slave= as appropriate). If the media is
not the primary, then you may need to also use indicate which device the
geometry is applying to (whether via ioport= or chnl= or maybe in a
second “eide” group, as in “eide master= eide master=geometry=”); sorry
I am not sure of the exact syntax for this, kchiles will have to comment
I still suspect part of the problem lies with fdisk, if it didn’t spend
it’s life struggling with the long dead CHS system then maybe this would
all be a non-issue.
John Garvey wrote:
Evan Hillas wrote:
And devb-eide’s geometry= parameter doesn’t work either.What is your invocation? I think you have to use it like:
“eide master=geometry=…” (or slave= as appropriate). If the media is
not the primary, then you may need to also use indicate which device the
geometry is applying to (whether via ioport= or chnl= or maybe in a
second “eide” group, as in “eide master= eide master=geometry=”); sorry
I am not sure of the exact syntax for this, kchiles will have to comment
Thanks, I needed that little nudge. Alas, I still can’t get any
response from “geometry”, my current command is now: devb-eide disk
nobios eide ioport=0x300,irq=3,master=geometry=4:489:32
What I’ve found is that the new option of “disk nobios” changes the
reported CHS values from 3:255:63 to 30:64:32. Sadly, this is still not
adding up to the LBA value of 62592.
Also, to prove that the “geometry” parameter should be making a
difference I tried the following: devb-eide disk nobios eide
ioport=0x300,irq=3,master=geometry=4:489:32,chs
With the added “chs” devb-eide fails to load reporting that “No eide
interface found”.
Try using the translation command line option ie
devb-eide disk translation=heads:sectors eide ioport=0x300,irq=3
Evan Hillas <blarg@blarg.blarg> wrote:
John Garvey wrote:
Evan Hillas wrote:
And devb-eide’s geometry= parameter doesn’t work either.What is your invocation? I think you have to use it like:
“eide master=geometry=…” (or slave= as appropriate). If the media is
not the primary, then you may need to also use indicate which device the
geometry is applying to (whether via ioport= or chnl= or maybe in a
second “eide” group, as in “eide master= eide master=geometry=”); sorry
I am not sure of the exact syntax for this, kchiles will have to comment
Thanks, I needed that little nudge. Alas, I still can’t get any
response from “geometry”, my current command is now: devb-eide disk
nobios eide ioport=0x300,irq=3,master=geometry=4:489:32What I’ve found is that the new option of “disk nobios” changes the
reported CHS values from 3:255:63 to 30:64:32. Sadly, this is still not
adding up to the LBA value of 62592.Also, to prove that the “geometry” parameter should be making a
difference I tried the following: devb-eide disk nobios eide
ioport=0x300,irq=3,master=geometry=4:489:32,chsWith the added “chs” devb-eide fails to load reporting that “No eide
interface found”.
On Tue, 31 Aug 2004 09:43:10 +1200, Evan Hillas <blarg@blarg.blarg> wrote:
I still suspect part of the problem lies with fdisk, if it didn’t spend
it’s life struggling with the long dead CHS system then maybe this would
all be a non-issue.
I wouldn’t discard CHS so hastily.
In my experience, sometimes it’s the only way
to install on an EIDE on one system
and then takes it across to a completely different one…
–
Using Opera’s revolutionary e-mail client: http://www.opera.com/m2/
inn.qnx.com wrote:
On Tue, 31 Aug 2004 09:43:10 +1200, Evan Hillas <> blarg@blarg.blarg> > wrote:
I still suspect part of the problem lies with fdisk, if it didn’t
spend it’s life struggling with the long dead CHS system then maybe
this would all be a non-issue.
I wouldn’t discard CHS so hastily.
In my experience, sometimes it’s the only way
to install on an EIDE on one system
and then takes it across to a completely different one…
That’s a pretty easy argument to dis, clearly one of those systems so
broken it wasn’t able to process LBA.
Kevin Chiles wrote:
Try using the translation command line option ie
devb-eide disk translation=heads:sectors eide ioport=0x300,irq=3
That works perfectly, thanks, good catch. My excuse is I was doing it
at work. 
I find this result intriguing as it can only be using LBA for it’s
sizing. This is great of course but I do wonder why LBA was not the
default choice.
Thank you all,
Evan