2.6 and IDE "geometry"

2.6 and IDE "geometry"

[Wakko Warner]

Is there anyway to get kernel 2.6 to use the geometry the bios has for an
IDE drive?

I have a installation setup that installs a non-linux os and I partition the
drive under linux.  In 2.4 this has worked flawlessly, however, 2.6 reports
as # cylinders/16 heads/63 sectors.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: 2.6 and IDE "geometry"

[Andries Brouwer]

On Fri, Dec 12, 2003 at 01:17:04PM -0500, Wakko Warner wrote:

> Is there anyway to get kernel 2.6 to use the geometry
> the bios has for an IDE drive?

The kernel does not use any geometry.

> I have a installation setup that installs a non-linux os and I partition the
> drive under linux.  In 2.4 this has worked flawlessly, however, 2.6 reports
> as # cylinders/16 heads/63 sectors.

Aha. So your real question is:
"Is there any way to get *fdisk to use my favorite geometry?"
The answer is: all common fdisk versions allow you to set the geometry.

Andries

Re: 2.6 and IDE "geometry"

[Wakko Warner]

> > Is there anyway to get kernel 2.6 to use the geometry
> > the bios has for an IDE drive?
> 
> The kernel does not use any geometry.

This I know, however, the kernel in the past has the geometry from the BIOS

> > I have a installation setup that installs a non-linux os and I partition the
> > drive under linux.  In 2.4 this has worked flawlessly, however, 2.6 reports
> > as # cylinders/16 heads/63 sectors.
> 
> Aha. So your real question is:
> "Is there any way to get *fdisk to use my favorite geometry?"
> The answer is: all common fdisk versions allow you to set the geometry.

I realize this too, however, I need it to happen automatically and be
consistent with the bios idea of the disk.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: 2.6 and IDE "geometry"

[Andries Brouwer]

On Fri, Dec 12, 2003 at 04:35:45PM -0500, Wakko Warner wrote:

> > The kernel does not use any geometry.
> 
> This I know, however, the kernel in the past has the geometry from the BIOS

The kernel made some attempts. It often worked and often failed.

> > So your real question is:
> > "Is there a way to get *fdisk to use my favorite geometry?"
> > The answer is: all common fdisk versions allow you to set the geometry.
> 
> I realize this too, however, I need it to happen automatically and be
> consistent with the bios idea of the disk.

So you script sfdisk or so in order to setup large numbers of disks
and cannot use constant geometry settings because this is on many
different BIOSes that disagree on the desired geometry?

And this is all on disks smaller than 8 GB so that at least there can be
some geometry?

Re: 2.6 and IDE "geometry"

[Wakko Warner]

> > This I know, however, the kernel in the past has the geometry from the BIOS
> 
> The kernel made some attempts. It often worked and often failed.

On all the different PCs I've worked with, it always worked.  Most of those
were dells and old FIC boards.

> > I realize this too, however, I need it to happen automatically and be
> > consistent with the bios idea of the disk.
> 
> So you script sfdisk or so in order to setup large numbers of disks
> and cannot use constant geometry settings because this is on many
> different BIOSes that disagree on the desired geometry?

Not quite, each is 1 PC and 1 Hard disk.

> And this is all on disks smaller than 8 GB so that at least there can be
> some geometry?

Thus far, the smallest has been 1.2gb and the largest being 80gb.  2.4.x (x
= any version upto 21  I have not used 22 or 23 yet) has worked for me
flawlessly.

The script does use sfdisk to aquire the size and the user tells it just how
large the partition to be and defaulting to the largest possible.  If the
geometry is wrong, the other OS won't boot.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: 2.6 and IDE "geometry"

[Andries Brouwer]

On Sat, Dec 13, 2003 at 05:18:00PM -0500, Wakko Warner wrote:

> The script does use sfdisk to aquire the size and the user tells it just how
> large the partition to be and defaulting to the largest possible.  If the
> geometry is wrong, the other OS won't boot.

What interests me is: do you need varying geometry?
That is: do you sometimes need */16/63 and sometimes */255/63
or even other values?

Or does it suffice to take */255/63 always?

Re: 2.6 and IDE "geometry"

[Wakko Warner]

> > The script does use sfdisk to aquire the size and the user tells it just how
> > large the partition to be and defaulting to the largest possible.  If the
> > geometry is wrong, the other OS won't boot.
> 
> What interests me is: do you need varying geometry?
> That is: do you sometimes need */16/63 and sometimes */255/63
> or even other values?
> 
> Or does it suffice to take */255/63 always?

I would say most cases use the 255/63, but I'm not 100% sure on that, just
with drives >4gb.  Is there anyway to query the bios to ask it?

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: 2.6 and IDE "geometry"

[Andries Brouwer]

On Sun, Dec 14, 2003 at 11:27:28AM -0500, Wakko Warner wrote:

> > Or does it suffice to take */255/63 always?
> 
> I would say most cases use the 255/63

Good. So you can try constant geometry setting with *fdisk.

> with drives >4gb.  Is there anyway to query the bios to ask it?

Yes, and that is what the kernel used to do.
In general, however, the answer is unreliable. 

Re: 2.6 and IDE "geometry"

[Wakko Warner]

> > > Or does it suffice to take */255/63 always?
> > 
> > I would say most cases use the 255/63
> 
> Good. So you can try constant geometry setting with *fdisk.
> 
> > with drives >4gb.  Is there anyway to query the bios to ask it?
> 
> Yes, and that is what the kernel used to do.
> In general, however, the answer is unreliable. 

anyway to get this unreliable answer back?  =)

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: 2.6 and IDE "geometry"

[Andries Brouwer]

On Sun, Dec 14, 2003 at 04:23:48PM -0500, Wakko Warner wrote:

> > > > Or does it suffice to take */255/63 always?
> > > 
> > > I would say most cases use the 255/63
> > 
> > Good. So you can try constant geometry setting with *fdisk.
> > 
> > > with drives >4gb.  Is there anyway to query the bios to ask it?
> > 
> > Yes, and that is what the kernel used to do.
> > In general, however, the answer is unreliable. 
> 
> anyway to get this unreliable answer back?  =)

Easy enough, the code is still there, just the result is no longer used.

But unless you have good reason, you should not wish those old times
back. This geometry stuff has caused such a large amount of pain.

Set your geometry to the constant */255/63 - depending on precisely
what you did, that may already have been what you got from 2.4 anyway.
Complain if you have troubles - specify BIOS type, geometry, operating
system that has problems booting.

I hope we'll find out that everything can be made to work without
kernel support.

Re: 2.6 and IDE "geometry"

[Wakko Warner]

> > > Yes, and that is what the kernel used to do.
> > > In general, however, the answer is unreliable. 
> > 
> > anyway to get this unreliable answer back?  =)
> 
> Easy enough, the code is still there, just the result is no longer used.
> 
> But unless you have good reason, you should not wish those old times
> back. This geometry stuff has caused such a large amount of pain.

Maybe atleast an option?  I personally have not had any pain with it.

> Set your geometry to the constant */255/63 - depending on precisely
> what you did, that may already have been what you got from 2.4 anyway.
> Complain if you have troubles - specify BIOS type, geometry, operating
> system that has problems booting.

The OS Is one of Windows 98, 2000, NT4, and in the future possibly XP.  BIOS
type varies.  Could be Dell's, the ones on hp compaq, award, phoenix, or
ami.

I use this so I don't ever have to boot dos to configure the drive
(partition) then boot back to linux to do what I need to do.

(OT: IT takes me 10 minutes or less to load the OS and everything with the
linux boot system I'm using.  I can't get the OS loaded from their CD that
quick!)

> I hope we'll find out that everything can be made to work without
> kernel support.

For me, this would be the easiest.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: 2.6 and IDE "geometry"

[Sven Luther]

On Fri, Dec 12, 2003 at 08:44:39PM +0100, Andries Brouwer wrote:
> On Fri, Dec 12, 2003 at 01:17:04PM -0500, Wakko Warner wrote:
> 
> > Is there anyway to get kernel 2.6 to use the geometry
> > the bios has for an IDE drive?
> 
> The kernel does not use any geometry.
> 
> > I have a installation setup that installs a non-linux os and I partition the
> > drive under linux.  In 2.4 this has worked flawlessly, however, 2.6 reports
> > as # cylinders/16 heads/63 sectors.
> 
> Aha. So your real question is:
> "Is there any way to get *fdisk to use my favorite geometry?"
> The answer is: all common fdisk versions allow you to set the geometry.

I believe parted does not. Nor any of the libparted frontends. I may be
wrong though.

Friendly,

Sven Luther

Re: 2.6 and IDE "geometry"

[John Bradford]

Quote from Sven Luther <sven.luther@wanadoo.fr>:
> On Fri, Dec 12, 2003 at 08:44:39PM +0100, Andries Brouwer wrote:
> > On Fri, Dec 12, 2003 at 01:17:04PM -0500, Wakko Warner wrote:
> > 
> > > Is there anyway to get kernel 2.6 to use the geometry
> > > the bios has for an IDE drive?
> > 
> > The kernel does not use any geometry.
> > 
> > > I have a installation setup that installs a non-linux os and I partition the
> > > drive under linux.  In 2.4 this has worked flawlessly, however, 2.6 reports
> > > as # cylinders/16 heads/63 sectors.
> > 
> > Aha. So your real question is:
> > "Is there any way to get *fdisk to use my favorite geometry?"
> > The answer is: all common fdisk versions allow you to set the geometry.
> 
> I believe parted does not. Nor any of the libparted frontends. I may be
> wrong though.

If so, I consider it a missing feature in parted - why should the BIOS
geometry resemble the disk it describes at all?  Some machines have no
user-definable drive types, forcing you to use an incorrect geometry
if you install a disk which is not in the table of supported drives.

This is no problem for recent Linux kernels, and doesn't even prevent
you booting from that disk.

John.

Re: 2.6 and IDE "geometry"

[bill davidsen]

In article <20031214202741.GA11909@win.tue.nl>,
Andries Brouwer  <aebr@win.tue.nl> wrote:
| On Sun, Dec 14, 2003 at 11:27:28AM -0500, Wakko Warner wrote:
| 
| > > Or does it suffice to take */255/63 always?
| > 
| > I would say most cases use the 255/63
| 
| Good. So you can try constant geometry setting with *fdisk.
| 
| > with drives >4gb.  Is there anyway to query the bios to ask it?
| 
| Yes, and that is what the kernel used to do.
| In general, however, the answer is unreliable. 

Unless I misread his question, he didn't ask how to make it reliable,
he just wants the partitioning software to use it. Not to use something
he provides by hand, to ask the BIOS and use the numbers, right or
wrong.

With old BIOS versions I will agree that using any other geometry, no
matter how correct or reliable, will result in a failure to boot.

I wish I had an answer to the original question, but I don't. Fdisk
tries to intuit what partition info if there is at least one partition
already created, if that's the partitioning software you are already
using, I can't offer any other help.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: 2.6 and IDE "geometry"

[Wakko Warner]

> > I believe parted does not. Nor any of the libparted frontends. I may be
> > wrong though.
> 
> If so, I consider it a missing feature in parted - why should the BIOS
> geometry resemble the disk it describes at all?  Some machines have no
> user-definable drive types, forcing you to use an incorrect geometry
> if you install a disk which is not in the table of supported drives.
> 
> This is no problem for recent Linux kernels, and doesn't even prevent
> you booting from that disk.

I think noone has really understood why I want it.  The machines in question
will not ever boot linux from the hard disk.  Only from the CD that I built. 
The OS that is installed from the CD is one of the windows OSs which depend
on the bios geometry definition to boot properly.  The kernel doesn't care
about the geometry, that's all well and good except when I create the
partitions.  Most of the pcs I work with use */255/63 notation,
occasionally, I'll come across one that uses */128/63 notation.  Never one
with */16/63 notation.  The smallest disk I work with would be a 1.2gb disk.

I have tried to make this CD as simple to use as possible, which means
passing the geometry on the command line is out of the question and setting
it for every invocation of *fdisk is pretty much out as well.  I liked the
"bogus bios"geometry the kernel was able to get from the bios.  Out of the
hundreds of PCs I've used this on, not one has ever failed me.

I have stuck with 2.4.x for now, but at some point, it'll have to be
upgraded due to hardware support.  2.4 will eventtually become with 2.0 is
now, stable, no new drives, only critial bug fixes.  As time progresses, the
kernel will not support newer hardware (For instance network drivers which
is used havily in this CD as well).

All I really want is to beable to get the kernel to get the bios parameters
for me.  If this means a patch or something, that's fine.  (I don't know
anything about the ide drivers to do this)

This CD has made my life easier at my job and it's not something I want to
give up while I still have this job =)

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: 2.6 and IDE "geometry"

[Wakko Warner]

Please keep me CCed

> | Yes, and that is what the kernel used to do.
> | In general, however, the answer is unreliable. 
> 
> Unless I misread his question, he didn't ask how to make it reliable,
> he just wants the partitioning software to use it. Not to use something
> he provides by hand, to ask the BIOS and use the numbers, right or
> wrong.

Correct.

> With old BIOS versions I will agree that using any other geometry, no
> matter how correct or reliable, will result in a failure to boot.
> 
> I wish I had an answer to the original question, but I don't. Fdisk
> tries to intuit what partition info if there is at least one partition
> already created, if that's the partitioning software you are already
> using, I can't offer any other help.

I pretty much summed it up in the last message I sent.

If it wasn't for what I'm doing here, I wouldn't have cared.  In some cases,
I don't even use a geometry, I just mke2fs /dev/hdx and use the whole disk. 
But that's only on machines that run linux primarily.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: 2.6 and IDE "geometry"

[Richard B. Johnson]

On Wed, 17 Dec 2003, Wakko Warner wrote:

> > > I believe parted does not. Nor any of the libparted frontends. I may be
> > > wrong though.
> >
> > If so, I consider it a missing feature in parted - why should the BIOS
> > geometry resemble the disk it describes at all?  Some machines have no
> > user-definable drive types, forcing you to use an incorrect geometry
> > if you install a disk which is not in the table of supported drives.
> >
> > This is no problem for recent Linux kernels, and doesn't even prevent
> > you booting from that disk.
>
> I think noone has really understood why I want it.  The machines in question
> will not ever boot linux from the hard disk.  Only from the CD that I built.
> The OS that is installed from the CD is one of the windows OSs which depend
> on the bios geometry definition to boot properly.  The kernel doesn't care
> about the geometry, that's all well and good except when I create the
> partitions.  Most of the pcs I work with use */255/63 notation,
> occasionally, I'll come across one that uses */128/63 notation.  Never one
> with */16/63 notation.  The smallest disk I work with would be a 1.2gb disk.
>
> I have tried to make this CD as simple to use as possible, which means
> passing the geometry on the command line is out of the question and setting
> it for every invocation of *fdisk is pretty much out as well.  I liked the
> "bogus bios"geometry the kernel was able to get from the bios.  Out of the
> hundreds of PCs I've used this on, not one has ever failed me.
>
> I have stuck with 2.4.x for now, but at some point, it'll have to be
> upgraded due to hardware support.  2.4 will eventtually become with 2.0 is
> now, stable, no new drives, only critial bug fixes.  As time progresses, the
> kernel will not support newer hardware (For instance network drivers which
> is used havily in this CD as well).
>
> All I really want is to beable to get the kernel to get the bios parameters
> for me.  If this means a patch or something, that's fine.  (I don't know
> anything about the ide drivers to do this)
>
> This CD has made my life easier at my job and it's not something I want to
> give up while I still have this job =)
>

The problem is that this phony geometry is only available in
"real-mode" from the BIOS. One needs to execute interrupt 0x13,
function-code 0x15, to get a pointer to the drive parameter
table. This is all 16-bit, BIOS residual stuff. In the "olden-
days" Linux had an "elevator" procedure for ordering read/writes
to drives. This required that Linux "know" about the geometry.
Once developers learned that the drives "know" better than
anybody else how to order reads/writes, this code was removed.
The code necessary to get the drive parameters from the BIOS,
when still in real-mode, was also removed because it has no
use anymore.

So, if you need to use that BIOS information now, you really
need to write it down. It's really that simple. Certainly you
don't expect an operating system to retrieve parameters upon
startup that might be useful to another operating system, do
you? If you MUST get that information for a program, you
can still get that information, but YOU, not the operating
system, needs to get it.

There are major problems obtaining this real-mode information
even from a custom driver (module). However, the old interrupt
table remains, starting at offset 0. Each table entry contains
an offset and a segment (4 bytes). You can therefore take
0x15 and shift it left twice to get the offset into the
interrupt table. Most of the segments will be 0x40. The offset
will be the offset off the segment value (0x40). That's 16 times
0x40 = 0x400. You add the offset to that, to get the absolute
offset of the table from C:, from a BIOS book, you can
find what each of the table entries mean. These can be returned
to your program. You actually don't need a driver to do this,
you can mmap() offset 0 without any NULL-pointer problems.
My simple debugger does this (like DOS debug, but 32-bit mode).
Note that Intel has the low byte in the lowest memory location,
also the lowest word is in the lowest memory location.

0x15 * 4 = 0x54

Script started on Wed Dec 17 11:03:15 2003
# ./debug
-d 0
00000000  01 00 00 00 6F EF 00 F0-C3 E2 00 F0 6F EF 00 F0   ....o.......o...
00000010  6F EF 00 F0 54 FF 00 F0-08 80 00 F0 6F EF 00 F0   o...T.......o...
00000020  A5 FE 00 F0 87 E9 00 F0-6F EF 00 F0 6F EF 00 F0   ........o...o...
00000030  6F EF 00 F0 6F EF 00 F0-57 EF 00 F0 6F EF 00 F0   o...o...W...o...
00000040  75 57 00 C0 4D F8 00 F0-41 F8 00 F0 64 25 00 C8   uW..M...A...d%..
00000050  39 E7 00 F0 59 F8 00 F0-2E E8 00 F0 D2 EF 00 F0   9...Y...........
                      ^^^^^^^^^^^
                      Table is at f000:f859 = ff859

00000060  A4 E7 00 F0 F2 E6 00 F0-6E FE 00 F0 53 FF 00 F0   ........n...S...
00000070  53 FF 00 F0 A4 F0 00 F0-C7 EF 00 F0 C8 5B 00 C0   S............[..
00000080  6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0   o...o...o...o...
00000090  6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0   o...o...o...o...
000000A0  6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0   o...o...o...o...
000000B0  6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0   o...o...o...o...
000000C0  6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0   o...o...o...o...
000000D0  6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0   o...o...o...o...
000000E0  6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0   o...o...o...o...
000000F0  6F EF 00 F0 6F EF 00 F0-6F EF 00 F0 6F EF 00 F0   o...o...o...o...
-q
# exit
exit
Script done on Wed Dec 17 11:04:11 2003


Cheers,
Dick Johnson
Penguin : Linux version 2.4.22 on an i686 machine (797.90 BogoMips).
            Note 96.31% of all statistics are fiction.