Skip to contentSkip to conversation

Gentoo Linux BUG 18612 - cfdisk

DISCUSSION Brandon Low 3 participants 4 messages Apr 3, 2003 – Apr 4, 2003

lore
Share & tools
lore

Brandon Low

author
#0 lore raw

http://bugs.gentoo.org/show_bug.cgi?id=18612

This bug appears to be caused by using cfdisk's default allocation on the last partition on a drive. From the looks of it on the user's LBA mapped drive, cfdisk allocated a bunch of non-existant sectors when the user allowed it to pick the default size for that last partition.

--Brandon Low

#1 lore raw
Quoted 6 lines · Brandon Low

http://bugs.gentoo.org/show_bug.cgi?id=18612

This bug appears to be caused by using cfdisk's default allocation on the last partition on a drive. From the looks of it on the user's LBA mapped drive, cfdisk allocated a bunch of non-existant sectors when the user allowed it to pick the default size for that last partition.

(please break lines)

(in case something is wrong with cfdisk, tell the cfdisk maintainer, not the kernel list)

(what kernel version is this? - I see, 2.4.20)

According to WD, this disk has 78,165,360 sectors.
So, in case it was partitioned with such a size maybe nothing was wrong.

The boot messages shown say:
kenny kernel: hda: setmax LBA 78165360, native 78125000
How come setmax has the right value and native has not? Did other software clip the disk?
What is the identify data for this drive?

Was the partitioning done with a kernel that had CONFIG_IDEDISK_STROKE enabled?

Andries

author
#2 lore raw
Quoted 10 lines · Andries Brouwer
Quoted 6 lines · Brandon Low

http://bugs.gentoo.org/show_bug.cgi?id=18612

This bug appears to be caused by using cfdisk's default allocation on the last partition on a drive. From the looks of it on the user's LBA mapped drive, cfdisk allocated a bunch of non-existant sectors when the user allowed it to pick the default size for that last partition.

(please break lines)

Heh, sorry about that.

Quoted 6 lines

(in case something is wrong with cfdisk, tell the cfdisk maintainer, not the kernel list)

(what kernel version is this? - I see, 2.4.20)

It is indeed 2.4.20 in the report.

Quoted 8 lines

According to WD, this disk has 78,165,360 sectors.
So, in case it was partitioned with such a size maybe nothing was wrong.

The boot messages shown say:
kenny kernel: hda: setmax LBA 78165360, native 78125000
How come setmax has the right value and native has not? Did other software clip the disk?
What is the identify data for this drive?

Interesting, I wonder why stock 2.4.20 would report it differently than the new IDE stuff that is in our kernel, as that seems to be the problem.

Quoted 3 lines

Was the partitioning done with a kernel that had CONFIG_IDEDISK_STROKE enabled?

Haven't heard of that option, I'll check with the bug reporter.

Quoted 4 lines

Andries

Thanks a lot for the reply, it has at least helped us much to narrow things down.

--Brandon

#3 lore raw
In reply to Brandon Low

Am Don, 2003-04-03 um 19.11 schrieb Brandon Low:

Quoted 4 lines

This bug appears to be caused by using cfdisk's default allocation on the last partition on a drive. From the looks of it on the user's LBA mapped drive, cfdisk allocated a bunch of non-existant sectors when the user allowed it to pick the default size for that last partition.

Actually I've seen several CFs fail when used in LBA mode, not just those partitioned with cfdisk. I claim there's either a problem of the manufacturers taking commands with LBAs or some driver problem on the linux to address the CFs correctly.

Anyway, I see this as rather minor; drop down to CHS in BIOS and everything works fine (here at least).

Signature · 2 lines
Servus,
       Daniel