From: Andries.Brouwer@cwi.nl
To: etrapani@unesco.org.uy, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clipped disk reports clipped lba size
Date: Wed, 30 Jan 2002 20:12:55 GMT [thread overview]
Message-ID: <UTC200201302012.UAA81755.aeb@cwi.nl> (raw)
On Wed, Jan 30, 2002 at 12:02:14PM -0300, Eduardo Trpani wrote:
> Since my BIOS does not support my disk (WD400) I had to clip to 33.8G.
> At boot time Linux (2.4.17) uses the lba size reported by the disk,
> that is 33.8 and does not allow me to access the rest of the disk.
> + /* If the geometry has been forced recalculate lba_capacity */
> + if ((id->capability & 2) && lba_capacity_is_ok(id) &&
> + drive->forced_geom)
> + {
> + id->lba_capacity = drive->bios_head * drive->bios_sect * drive->bios_cyl;
> + }
This is not really the right patch, although it may solve your problem.
It looks a bit silly to first test lba_capacity_is_ok() and then throw
away lba_capacity anyway.
Using a product of strange numbers is a bad idea.
Often this simple patch will not help, see below.
My point of view would be more like: we now have three levels of information.
First C/H/S - very outdated. On all large disks it will be 16383/16/63.
Then LBA. When it looks reasonable, we believe it, and let it override C/H/S.
Third what the disk returns for READ_NATIVE_MAX_ADDRESS. Especially when LBA
says 33.8GB we have a good reason to ask for this and see whether it is more.
Some disk types fake LBA at 33.8GB, but allow access past this point.
Some disks actually give I/O errors past the 33.8GB (when jumpered),
and a SETMAX command is needed to make the rest accessible.
Two years ago I wrote a tiny utility setmax that does this.
If I am not mistaken this stuff is now part of the 2.5 kernel.
No doubt some of it will eventually be backported to 2.4 / 2.2 / 2.0.
It is in 2.4.18-pre7-ac1.
[Just looked at patch-2.5.3-pre1. And indeed, some nice code.
Andre, others: is there a reason to make CONFIG_IDEDISK_STROKE
a configuration option? I very much dislike configuration options,
especially in cases like this, where the user may choose between
things happening correctly and things not happening correctly.
And it looks like the option is undocumented as well.
Is setting CONFIG_IDEDISK_STROKE ever harmful?
It looks like the code
+ /* if OK, compute maximum address value */
+ if ((args.tfRegister[IDE_STATUS_OFFSET] & 0x01) == 0) {
+ addr = ((args.tfRegister[IDE_SELECT_OFFSET] & 0x0f) << 24)
+ | ((args.tfRegister[ IDE_HCYL_OFFSET] ) << 16)
+ | ((args.tfRegister[ IDE_LCYL_OFFSET] ) << 8)
+ | ((args.tfRegister[IDE_SECTOR_OFFSET] ));
+ }
+ addr++; /* since the return value is (maxlba - 1), we add 1 */
+ return addr;
has a bug: the addr++ should be inside the if(), I suppose.
The same bug occurs a number of places.]
Andries
next reply other threads:[~2002-01-30 20:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-30 20:12 Andries.Brouwer [this message]
2002-02-01 12:10 ` [PATCH] clipped disk reports clipped lba size Paul Gortmaker
-- strict thread matches above, loose matches on Subject: below --
2002-02-02 13:38 Andries.Brouwer
2002-02-01 21:55 Andries.Brouwer
2002-02-02 0:20 ` Andre Hedrick
2002-02-02 11:11 ` Paul Gortmaker
2002-01-30 15:02 Eduardo Trápani
2002-01-30 15:34 ` Alan Cox
2002-01-30 17:04 ` Andre Hedrick
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=UTC200201302012.UAA81755.aeb@cwi.nl \
--to=andries.brouwer@cwi.nl \
--cc=etrapani@unesco.org.uy \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox