From: Phillip Susi <psusi@cfl.rr.com>
To: "linux-os (Dick Johnson)" <linux-os@analogic.com>
Cc: "Jeff V. Merkey" <jmerkey@wolfmountaingroup.com>,
Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: C/H/S from user space
Date: Fri, 17 Feb 2006 16:04:25 -0500 [thread overview]
Message-ID: <43F63A59.6090401@cfl.rr.com> (raw)
In-Reply-To: <Pine.LNX.4.61.0602171452520.4290@chaos.analogic.com>
linux-os (Dick Johnson) wrote:
>
> Yes, it's a very good model, in fact what I've been talking about.
> However, several people who refused to read or understand, insisted
> upon obtaining the exact same C/H/S that the machine claimed to
> use when it was booted.
>
That's because if you don't use the same geometry that the bios reports
when calculating the CHS addresses of the sectors you intend to load,
you won't be requesting the right sectors from int 13.
> So, since Linux doesn't destroy that information remaining in
> the BIOS tables, I show how to make it available to a 'root' user.
> Observation over several machines will show that the BIOS always
> uses the same stuff for large media and, in fact, it has no choice.
> Basically, this means that the first part of the boot-code, the
> stuff that needs to be translated to fit into the int 0x13 registers,
> needs to be below 1024 cylinders, 63 sectors-track, and 256 heads.
> Trivial... even LILO was able to do that! Once the machine boots
> past the requirement to use the BIOS services, it's a CHS=NOP.
>
Generally yes, modern large disks will get clamped at 1024 cylinders,
255 heads, and 63 sectors. You seem to be arguing that this will always
be the case. If that is so, then the kernel doesn't need to store these
values since it is known a priori does it? But it isn't always going to
be 255/63, there are some bioses ( I forget which ) that cap the number
of heads at 240, and disks that are smaller than 8 gigs also will have
less than 255 heads.
next prev parent reply other threads:[~2006-02-17 21:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-17 17:01 C/H/S from user space linux-os (Dick Johnson)
2006-02-17 18:37 ` Jeff V. Merkey
2006-02-17 19:59 ` Phillip Susi
2006-02-17 20:04 ` linux-os (Dick Johnson)
2006-02-17 20:24 ` Nick Warne
2006-02-17 20:39 ` linux-os (Dick Johnson)
2006-02-17 21:04 ` Phillip Susi [this message]
2006-02-17 21:22 ` linux-os (Dick Johnson)
2006-02-17 22:20 ` Phillip Susi
2006-02-18 3:42 ` Marcin Dalecki
2006-02-18 16:20 ` Phillip Susi
2006-02-17 22:24 ` Jeff V. Merkey
2006-02-17 22:22 ` Jeff V. Merkey
-- strict thread matches above, loose matches on Subject: below --
2006-02-17 20:30 Seewer Philippe
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=43F63A59.6090401@cfl.rr.com \
--to=psusi@cfl.rr.com \
--cc=jmerkey@wolfmountaingroup.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.com \
/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