Upgrading from kernel 2.4 to 2.6 the CHS information for the same hardware
changed. This behaviour is correct?
Using 2.4:
hda: 12594960 sectors (6449 MB) w/2048KiB Cache, CHS=784/255/63, UDMA (33)
Using 2.6:
hda: 12594960 sectors (6449 MB) w/2048KiB Cache, CHS=13328/15/63, UDMA (33)
regards,
--
Fl?vio Bruno Leitner <[email protected]>
[ E74B 0BD0 5E05 C385 239E 531C BC17 D670 7FF0 A9E0 ]
On Wed, 5 Nov 2003, Flavio Bruno Leitner wrote:
> Upgrading from kernel 2.4 to 2.6 the CHS information for the same hardware
What are the exact kernel versions?
> changed. This behaviour is correct?
I am just investigating it.
> Using 2.4:
> hda: 12594960 sectors (6449 MB) w/2048KiB Cache, CHS=784/255/63, UDMA (33)
>
> Using 2.6:
> hda: 12594960 sectors (6449 MB) w/2048KiB Cache, CHS=13328/15/63, UDMA (33)
>
> regards,
>
> --
> Fl?vio Bruno Leitner <[email protected]>
> [ E74B 0BD0 5E05 C385 239E 531C BC17 D670 7FF0 A9E0 ]
On Wed, Nov 05, 2003 at 06:29:07PM +0100, Bartlomiej Zolnierkiewicz wrote:
>
>
> On Wed, 5 Nov 2003, Flavio Bruno Leitner wrote:
>
> > Upgrading from kernel 2.4 to 2.6 the CHS information for the same hardware
>
> What are the exact kernel versions?
All versions up to 2.4.20 report the same information and 2.6
is one snapshot from Linus bk 2003-10-29.
I tested on another machine which the same chipset (but more recent
bk snapshot) and the behaviour is ok. I'm updating the kernel on
the machine that reproduces this bug to see if happens again.
> > changed. This behaviour is correct?
>
> I am just investigating it.
Thanks!
--
Fl?vio Bruno Leitner <[email protected]>
[ E74B 0BD0 5E05 C385 239E 531C BC17 D670 7FF0 A9E0 ]
On Wed, 5 Nov 2003, Flavio Bruno Leitner wrote:
> On Wed, Nov 05, 2003 at 06:29:07PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > On Wed, 5 Nov 2003, Flavio Bruno Leitner wrote:
> > > Using 2.4:
> > > hda: 12594960 sectors (6449 MB) w/2048KiB Cache, CHS=784/255/63, UDMA (33)
> > >
> > > Using 2.6:
> > > hda: 12594960 sectors (6449 MB) w/2048KiB Cache, CHS=13328/15/63, UDMA (33)
>
> The line with CHS=784/255/63 is LBA and CHS=13328/15/63 is NORMAL.
>
> Where kernel check to see if is LBA or NORMAL? BIOS? Which line is correct?
Nowhere, kernel uses LBA whenever possible.
In 2.6.x it doesn't even read BIOS info (which is wrong IMO, it should
do this but only as last resort - if partition can't be mounted).
Difference in CHS translation should matter only if you have some old DOS
partitions created using CHS information. Then you can force geometry
using boot parameter "hd?=". Unfortunately I've seen recently bugreport
when 2.4.20 (?) works and 2.6.x fails even with forced geometry.
--bartlomiej
On Wed, Nov 05, 2003 at 03:23:10PM -0200, Flavio Bruno Leitner wrote:
> Upgrading from kernel 2.4 to 2.6 the CHS information for the same hardware
> changed. This behaviour is correct?
>
> Using 2.4:
> hda: 12594960 sectors (6449 MB) w/2048KiB Cache, CHS=784/255/63, UDMA (33)
>
> Using 2.6:
> hda: 12594960 sectors (6449 MB) w/2048KiB Cache, CHS=13328/15/63, UDMA (33)
Yes, correct in the sense that it is not wrong.
Probably your disk reports 15 and 2.4 invented 255.
CHS is something that stopped being meaningful a decade ago.
Today it is random garbage, to be ignored whenever possible.
Don't worry about CHS when you don't have problems.
On Wed, Nov 05, 2003 at 08:41:58PM +0100, Bartlomiej Zolnierkiewicz wrote:
> In 2.6.x it doesn't even read BIOS info (which is wrong IMO, it should
> do this but only as last resort - if partition can't be mounted).
How can reading information that is not used by any kernel
help in mounting a partition?
> Difference in CHS translation should matter only if you have some old DOS
> partitions created using CHS information. Then you can force geometry
> using boot parameter "hd?=". Unfortunately I've seen recently bugreport
> when 2.4.20 (?) works and 2.6.x fails even with forced geometry.
Fails? What do you mean?
(Are you referring to the problem of finding the last cylinder?)
Andries
On Tue, Nov 11, 2003 at 12:46:49PM +0100, Andries Brouwer wrote:
> On Wed, Nov 05, 2003 at 03:23:10PM -0200, Flavio Bruno Leitner wrote:
>
> > Upgrading from kernel 2.4 to 2.6 the CHS information for the same hardware
> > changed. This behaviour is correct?
> >
> > Using 2.4:
> > hda: 12594960 sectors (6449 MB) w/2048KiB Cache, CHS=784/255/63, UDMA (33)
> >
> > Using 2.6:
> > hda: 12594960 sectors (6449 MB) w/2048KiB Cache, CHS=13328/15/63, UDMA (33)
>
> Yes, correct in the sense that it is not wrong.
> Probably your disk reports 15 and 2.4 invented 255.
>
> CHS is something that stopped being meaningful a decade ago.
> Today it is random garbage, to be ignored whenever possible.
> Don't worry about CHS when you don't have problems.
Parted was complaining about this change but I still have to check with
version of parted they used. Anyway, it's booting and working normaly.
Regards,
--
Fl?vio Bruno Leitner <[email protected]>
[ E74B 0BD0 5E05 C385 239E 531C BC17 D670 7FF0 A9E0 ]
In article <[email protected]>,
Andries Brouwer <[email protected]> wrote:
| On Wed, Nov 05, 2003 at 03:23:10PM -0200, Flavio Bruno Leitner wrote:
|
| > Upgrading from kernel 2.4 to 2.6 the CHS information for the same hardware
| > changed. This behaviour is correct?
| >
| > Using 2.4:
| > hda: 12594960 sectors (6449 MB) w/2048KiB Cache, CHS=784/255/63, UDMA (33)
| >
| > Using 2.6:
| > hda: 12594960 sectors (6449 MB) w/2048KiB Cache, CHS=13328/15/63, UDMA (33)
|
| Yes, correct in the sense that it is not wrong.
I'll remember that phrase, interesting way to put it.
| Probably your disk reports 15 and 2.4 invented 255.
Almost looks as if the BIOS is using the faked values to keep the
cylinders < 1024 to make the old BIOS calls work, and the 2.6 init is
looking at the real geometry of the device (in the sense of "what the
device itself reports, of course).
|
| CHS is something that stopped being meaningful a decade ago.
Unfortunately while this is true at the kernel level, applications do
use it. The ones of interest to most people are parted (as noted) and
fdisk. Changing the values will make them whine, and may actually cause
malfunction.
| Today it is random garbage, to be ignored whenever possible.
| Don't worry about CHS when you don't have problems.
In general the BIOS should be told to report drive size in
non-translated values, using LBA or LARGE or similar options depending
on the BIOS. I suspect this was not done prior to the initial install.
And if this machine dual boots you really don't want to change it now!
The CHS can be set on the boot line. I haven't used this in years, so I
have no idea if that still works or even exists.
You can also go into the expert menu of fdisk and change the values
used there. Another thing I haven't done in ages, but the commands to
do so are still present. This mainly allows you to avoid "partition
does not start on a track boundary" warnings.
As you note, most of this is better not used, but it might have been
better to try the boot time setting of CHS before using parted, just to
avoid possible problems, *but I certainly wouldn't do that now*.
It seems parted doesn't handle Win/XP partitions, which is too bad,
since adding Linux to commercial laptops was the most frequent use I
made of it. Perhaps there's a newer version, I haven't looked in some
months.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Tuesday 11 of November 2003 12:53, Andries Brouwer wrote:
> On Wed, Nov 05, 2003 at 08:41:58PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > In 2.6.x it doesn't even read BIOS info (which is wrong IMO, it should
> > do this but only as last resort - if partition can't be mounted).
>
> How can reading information that is not used by any kernel
> help in mounting a partition?
You are of course right, only ibm.c and nec98.c use HDIO_GETGEO.
> > Difference in CHS translation should matter only if you have some old DOS
> > partitions created using CHS information. Then you can force geometry
> > using boot parameter "hd?=". Unfortunately I've seen recently bugreport
> > when 2.4.20 (?) works and 2.6.x fails even with forced geometry.
>
> Fails? What do you mean?
Sorry, it was "hd.c instead of ide.c" problem.
> (Are you referring to the problem of finding the last cylinder?)