public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.



  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