IDE woes:linux and BIOS won't agree on C/H/S detection

IDE woes.

Sorry for this lengthy post, I read ide.txt, large-disk-howto.txt and experimented with fdisk (DOS/WIN), dd, and a few other tricks, but can't seem to be able to solve a question.

Big Question - 1:

I have a 20GB seagate ATA disk.
My Board BIOS recognizes the CHS geometry when it auto-detects the disk as

        C/H/S=39694/16/63.

However, linux refuses to recognize this and tries to report

      C/H/S=2490/255/63.

This 2490/255/63 seems to get stuck after I tried partitioning the disk using OLD 2.2.yy (probably 2.2.12?)
Debian GNU/Linux CD installer. (beta version of stormlinux CD in fact.)

How can I get rid of this "unnatural" C/H/S information so that linux boots with the geometry that BIOS uses. This is necessary for me to make win98 co-exist with linux on this disk. I tried a few commands :

fdisk /mbr
dd if=/dev/null of=/dev/hdaZ bs=512 count=1 Run Seagate Disk Manager to partition the disk with motherboard BIOS C/H/S setting hopefully,

but no luck so far.

The boot command line parameter saved the day for now. I added the following to the boot command line:

        hda=39694,16,63

But this is a little awkward since I tend to forget to add the hda=39694,16,63 paramater to the command line when I make emergency loadlin DOS disk, etc.

How can I "erase" this 2940/255/63 CHS setting from the disk so that linux will use 39694/16/63 WITHOUT boot command line parameter?

The rest is the long background of hardware and
the history that led to the current problem.

Lengthy background and historical information.

OS version: uname -a
Linux duron 2.4.0-test12 #16 Thu Dec 21 03:07:26 JST 2000 i686 unknown
CPU: AMD K7 Duron 750 (100x7.5)

Motherboard: Gigabyte GA-7IXE4
Chipset : AMD 751 PCI/AGP controller
+ AMD 756 PCI IDE controller

BIOS AMI BIOS.
Disk in question: Seagate ST320423A 20GB ATA disk.
This is the only IDE/ATA disk (on primary controller as a master device.
I have an ATAPI CDROM on the secondary controller.) My main linux stays on a SCSI disk via Tekram SCSI controller.

Symptom:

I can't get linux to properly recognize the C/H/S with the hardware combination above. I would like to make win98 and linux co-exist on this disk and the motherboard (MB) BIOS and linux not agreeing on this is a disaster.

My Board BIOS recognizes the CHS geometry
when it auto-detects the disk as

        C/H/S=39694/16/63.

However, linux refuses to recognize this and tries to report

      C/H/S=2490/255/63.

(These numbers seemed to picked up by 2.2.yy installation I tried on the disk earlier.)

Right now, I am forced to add

      ... hda=39694,16,63 ...

on the boot command line.

/usr/src/linux/Documentation/ide.txt states:

Drives are normally found by auto-probing and/or examining the CMOS/BIOS data. For really weird situations, the apparent (fdisk) geometry can also be specified on the kernel "command line" using LILO. The format of such lines is:

hdx=cyls,heads,sects,wpcom,irq
or hdx=cdrom

I am not sure why my hardware combo became weired, but something is wrong here. I suspect that incorrect fdisk information left by 2.2.12 kernel tool might be the culprit, but can't pin point where the problem lies and thus am posting this for experts' opinion.

What prompted me to think like this is the following history.

(1) The disk was originally used on a Gigabyte 586SG motherboard as a secondary master device. (586SG uses AWARD BIOS.) I think it uses VIA chip set.(I can dig up documentation if this proves important.)

On 586SG motherboard, Linux 2.4.0-testXX reported accetable 39693/16/63 (QUESTION: why 39693 is one less the number reported by AMI BIOS? Oh well.)

The disk was formatted as a big Linux partition using Linux fdisk. Since this was a big linux-only disk, I didn't have to worry about this CHS mismatch with other OS.

The following is an excerpt from the /var/log/messages: the device hdc is the disk in question.

w/256KiB Cache, CHS=904/60/63, UDMA(33)

w/512KiB Cache, CHS=39693/16/63, UDMA(33)

(cf. The CPU on 586SG was AMD K6-III/400. I had two IDE disks as the log
above showed and one SCSI CDROM.)

(2) New motherboard: part-1.

Then the disk is moved onto Soyo SY-K7VTA motherboard with AMD K7 Duron 750 (the current CPU I use) and used there for two weeks.

Soyo SY-K7VTA uses VIA chipset (apollo KT133 + 686A) and uses AWARD BIOS. I put the seagate drive as the single IDE/ATA disk as primary master device. I put an ATAPI CDROM as secondary slave.

(Later on, I moved the main scsi disk where my linux 2.4.0-testXX is stored to this motherboard. I could boot the 2.4.0-testXX using loadlin floppy.)

(2-a) SOYO Motheboard. Initial attempt.

After digging up the old log, I found that the initially all was well.

On this Soyo motherboard, the disk was recognized during the boot process as below. Since the linux kernel seemed to recognize the "natural" C/H/S, I didn't seem to have much problem on this motherboard even if I tried to partition the drive with multiple partitions and tried to install DOS/win98 near the beginning of the disk area. Initially, anyway.

I booted the Linux 2.4.0-testXX off the scsi disk using loadlin from a boot disk.

This is the log : Please note the "CHS=39693/16/63" line. This seems to be an OK number except that the later on I see 39694 as cylinder number in AMI BIOS on the second new motherboard.

Uniform Multi-Platform E-IDE driver Revision: 6.31
Nov 24 13:21:45 standard kernel: ide: Assuming 33MHz system bus
speed
for PIO modes; override with idebus=xx
Nov 24 13:21:45 standard kernel: VP_IDE: IDE controller on PCI bus
00

    dev 39
    Nov 24 13:21:45 standard kernel: VP_IDE: chipset revision 16
    Nov 24 13:21:45 standard kernel: VP_IDE: not 100%% native mode: will

    probe irqs later
    Nov 24 13:21:45 standard kernel:     ide0: BM-DMA at 0xa000-0xa007,

BIOS
settings: hda:DMA, hdb:pio
Nov 24 13:21:45 standard kernel: ide1: BM-DMA at 0xa008-0xa00f,
BIOS

    settings: hdc:DMA, hdd:pio
    Nov 24 13:21:45 standard kernel: hda: ST320423A, ATA DISK drive
    Nov 24 13:21:45 standard kernel: hdc: MATSHITA CR-583, ATAPI CDROM

drive

    Nov 24 13:21:45 standard kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

    Nov 24 13:21:45 standard kernel: ide1 at 0x170-0x177,0x376 on irq 15

    Nov 24 13:21:45 standard kernel: hda: 40011300 sectors (20486 MB)
    w/512KiB Cache, CHS=39693/16/63
    Nov 24 13:21:45 standard kernel: Partition check:
    Nov 24 13:21:45 standard kernel:  hda: hda1 hda2 hda4 < hda5 hda6
hda7
    hda8 >

So far, so good.

(2-b) Tried partitioning with 2.2.1? and fdisk.

I wanted to experimenting repartition the whole seagate disk into a main linux partition, linux swap, and DOS/Win98 partition, etc.. While playing with this using somewhat old Debian Gnu/Linux disk that had 2.2.yy on it, the incorrect C/H/S crept in. (I think it was 2.2.12. Ugh, very old.)

What did I do here? Most likely simply re-partitioned the drive. But what tool did I use?
It is the partition tool on the old 2.2.yy Debian GNU/linux CD. More specifically a beta Stormix Debian GNU/Linux CD I had: it came as an experimental CD with a Japanese UNIX magazine. My guess is that it simply calls fdisk or cfdisk.

=== Now the CHS reported is somewhat not bios/win98-friendly. ===

I rebooted the system using the 2.4.0-test11 on the scsi disk using loadlin.

This is the log from such boot.:
Please note the "CHS=2490/255/63" near the end. (This CHS info is problematic for DOS/Win98 co-existence since BIOS reports 39694/16/63.)

    Dec  6 05:37:09 duron kernel: Linux version 2.4.0-test11
(root@duron)
    (gcc version 2.95.2 20000220 (Debian GNU/Linux)) #11 Sun Dec 3
01:20:19
    JST 2000
         ...
    Dec  6 05:37:09 duron kernel: Kernel command line: root=/dev/sda6 ro

    sym53c8xx=mpar:n scsihosts=sym53c8xx:tmscsim
    Dec  6 05:37:09 duron kernel:  BOOT_IMAGE=240t11.i2c
         ...

    Dec  6 05:37:09 duron kernel: Uniform Multi-Platform E-IDE driver
    Revision: 6.31
    Dec  6 05:37:09 duron kernel: ide: Assuming 33MHz system bus speed

for
PIO modes; override with idebus=xx
Dec 6 05:37:09 duron kernel: VP_IDE: IDE controller on PCI bus 00
dev

    39
    Dec  6 05:37:09 duron kernel: VP_IDE: chipset revision 16
    Dec  6 05:37:09 duron kernel: VP_IDE: not 100%% native mode: will
probe
    irqs later
    Dec  6 05:37:09 duron kernel:     ide0: BM-DMA at 0xa000-0xa007,

BIOS
settings: hda:DMA, hdb:pio
Dec 6 05:37:09 duron kernel: ide1: BM-DMA at 0xa008-0xa00f,
BIOS

    settings: hdc:DMA, hdd:pio
    Dec  6 05:37:09 duron kernel: hda: ST320423A, ATA DISK drive
    Dec  6 05:37:09 duron kernel: hdc: MATSHITA CR-583, ATAPI CDROM
drive
    Dec  6 05:37:09 duron kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
    Dec  6 05:37:09 duron kernel: ide1 at 0x170-0x177,0x376 on irq 15
    Dec  6 05:37:09 duron kernel: hda: 40011300 sectors (20486 MB)
w/512KiB
    Cache, CHS=2490/255/63
    Dec  6 05:37:09 duron kernel: Partition check:
    Dec  6 05:37:09 duron kernel:  hda: hda1 hda2 hda4 < hda5 hda6 >

(3) CHS=2490/255/63 stuck?

Problem is that this 2490/255/63 stuck.

Once the CHS value came into use, re-partitioning was done using this value on the linux side no matter what I tried..

Cache, CHS=2490/255/63

hda8 hda9 hda10 >

Initially, I only had 2.2.yy kernel and a single DOS partition (which was well below 2GB) on this seagate disk and I didn't have a practical problem. But once I tried to create larger partitions to store Win98 and linux together on this disk,
the discrepancy of

            CHS=39693/16/63  (presumably used by DOS [and win98?])

and

            CHS=2490/255/63  (linux)

became very annoying. The larger partitions later in the disk cause the boundary mismatch(?) or some such messages. This is disturbing.

After the two weeks of usage with the Soyo motherboard, now the disk has been moved to the current Gigabyte 7IXE4 motherboard. The "unnatural" CHS still got stuck to the disk.
The BIOS now reports 39694/16/63.

(4) What I tried: boot line parameter, fdisk /mbr, dd, etc..

How can I clear this "incorrect"(?) CHS information? When I boot Linux, the boot command line parameter solved this as a bandaid (hda=39694,16,63 ), but it is easy to forget this when I create an emergency loadlin floppy, etc..

Linux recognizes 2490/255/63 no matter what the BIOS setting. This naturally led me to think the information is on the disk platter. I tried

fdisk /mbr

from the DOS/Win. (This may not clear the whole 512bytes as explained in the ide.txt and large-disk-howto doc.) I also tried

dd if=/dev/null of=/dev/hdaZ bs=512 count=1

But this didn't to seem to work.
(I am now not sure which value of Z I used. Maybe I should try simple hda without Z?)

I even used the Seagate partition tool that could be used to partition large disk from DOS (even on a machine without BIOS support for large ATA disk). The tool, called Disk manager happily partitioned (and formated it very quickly!) the disk into 10 partitions (one primary, 9 logical each less than the FAT16 2G limit.) This was done after the BIOS setting of CHS=39694/16/63 was in place: actually automatic recognition picked this value.

But even then the strange C/H/S recognition on the linux side stuck. Hmm...

Example: After the disk manager partition:

If I don't specify hda=xxx on the boot command line, we still get CHS=2940/255/63 on the linux side.

Dec 21 08:06:30 duron kernel: AMD7409: IDE controller on PCI bus 00 dev
39
Dec 21 08:06:30 duron kernel: AMD7409: chipset revision 7
Dec 21 08:06:30 duron kernel: AMD7409: not 100%% native mode: will probe

irqs later

Dec 21 08:06:30 duron kernel:     ide0: BM-DMA at 0xf000-0xf007, BIOS
settings: hda:DMA, hdb:pio
Dec 21 08:06:30 duron kernel:     ide1: BM-DMA at 0xf008-0xf00f, BIOS
settings: hdc:DMA, hdd:pio
Dec 21 08:06:30 duron kernel: hda: ST320423A, ATA DISK drive
Dec 21 08:06:30 duron kernel: hdc: MATSHITA CR-583, ATAPI CDROM drive
Dec 21 08:06:30 duron kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Dec 21 08:06:30 duron kernel: ide1 at 0x170-0x177,0x376 on irq 15
Dec 21 08:06:30 duron kernel: hda: 40011300 sectors (20486 MB) w/512KiB
Cache, CHS=2490/255/63
Dec 21 08:06:30 duron kernel: Partition check:
Dec 21 08:06:30 duron kernel:  hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9

hda10 hda11 hda12 hda13 >

With "hda=..." command line parameter, Linux uses the desirable CHS value.

Dec 21 08:09:14 duron kernel: hda: 40011300 sectors (20486 MB) w/512KiB
Cache, CHS=39694/16/63
Dec 21 08:09:14 duron kernel: Partition check:
Dec 21 08:09:14 duron kernel:  hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9

hda10 hda11 hda12 hda13 >

With the boot line command line parameter, fdisk /dev/hda prints the following.
I take that as long as I stay away from the first and the last partition,
I can make linux and win98 co-exist.

command (m for help): p

Disk /dev/hda: 16 heads, 63 sectors, 39693 cylinders Units = cylinders of 1008 * 512 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 3969 2000061 6 FAT16
Partition 1 does not end on cylinder boundary:

     phys=(248, 254, 63) should be (248, 15, 63)
/dev/hda2          3969     39685  18000832+   f  Win95 Ext'd (LBA)
Partition 2 does not end on cylinder boundary:
     phys=(1023, 254, 63) should be (1023, 15, 63)
/dev/hda5          3969      7937   2000061    6  FAT16
/dev/hda6          7937     11906   2000061    6  FAT16
/dev/hda7         11906     15874   2000061    6  FAT16
/dev/hda8         15874     19843   2000061    6  FAT16
/dev/hda9         19843     23811   2000061    6  FAT16
/dev/hda10        23811     27780   2000061    6  FAT16
/dev/hda11        27780     31748   2000061    6  FAT16
/dev/hda12        31748     35716   2000061    6  FAT16
/dev/hda13        35717     39685   2000061    6  FAT16

Anyway, back to the original question:
What can I do to let the disk "forget" the 2940/255/63 CHS setting?

I can wipe out the initial portion of the disk and try re-install.

PS: Come to think of it, I no longer see UDMA(33) message in the log. Is this also a potential problem?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

On Fri, Dec 22, 2000 at 03:25:20AM +0900, Ishikawa wrote:

[a long and very well documented story]

It is far from clear that it is on your disk, so it is far from clear that something can be erased.

First a few warnings - probably you know already, but just to be sure:

(i) The geometry you get is mostly determined by the BIOS settings (Normal / Large / LBA / PartitionTable).

(ii) The 2.2.14+ and 2.4 behaviours are both correct, but differ. The difference consists in that 2.2.14 will use a 255 head geometry by default (on a large disk), while 2.4 will not.
2.2.12 is broken for large disks.

(iii) The geometry seen on a partition table may override the geometry detected earlier. If this happens you see lines like

	 hde: [PTBL] [4441/255/63] hde1 hde2 hde3 < hde5 > hde4

in the dmesg, but you did not report any PTBL, so as far as Linux is concerned the partition table did not play a role.

(iv) It is impossible to guess what geometry the BIOS will invent, but Linux makes a feeble attempt. For your hda it asks the BIOS about hd0, the 0x80 disk. But if you also have SCSI disks, then the BIOS may number the disks such that 0x80 is the SCSI disk. (This may depend on which disk you boot from.)
In such a case the geometry the BIOS reports is the geometry it uses for that SCSI disk.

So, if you play with these things in order to understand all details, you can try with and without SCSI disks and see whether it makes a difference. (On my machine it does.)

A disk does not have a geometry, so there is no proper value. So, one has to invent something, rather arbitrarily. Since each BIOS invents different things, a disk may get a different geometry when you move it to a different machine.

However, these days both Linux and Windows and all BIOSes can cope with different geometries, so all should be well for all parties involved with 16 heads, and all should also be well with 255 heads. Just make sure to select the proper thing in the BIOS setup.

You can do the computation for yourself: 40011300/(16*63) = 39693. Apparently the AMI BIOS is buggy here.

Precisely. It doesnt help at all.

Yes, you should. But this changes something for Linux only in case it earlier reported PTBL which it didnt. So, it won't help, unless this changes something for the BIOS.

Disk managers only make your life much more complicated. Stay far away from them, if you can.

Interesting. It looks like you are trying to get 39693/16/63 while Windows in fact uses the 2940/255/63 that you are trying to get rid of.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Thank you for your tips.

255 head geometry seems to have crept in after I tried the 2.2.1x installation. That is for sure.

No I don't see [PTBL] entry in the log.

Aha, this might be playing a role.
I am booting from SCSI! Namely I use loadlin from the command only prompt of Win98 and boots it.

I will do so over the weekend and report the result..

Oh, how embarrassing for AMI programmers.

Right, it seemed to wipe out the boot record, but the mysterious partition info was still there.

Well, I might try just for completeness's sake.

Too late...

Are you sure of this?
Gee I am glad I attached this fdisk partition table, but then I have to think more deeply then what the best measure would be.

TIA

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I suppose you can get all systems involved to agree on 255 heads if you select LBA in the BIOS.

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hi,

I think I misunderstood one thing before all the tips came in. I somehow assumed that the Win98 would use the
disk geometry that AMI BIOS reported during boot for the hard disk. I was wrong.
Win98 seems to have its own idea of picking up convenient CHS just as linux might do.
(And incidentally, this CHS seems to agree between w98 and linux!) Or AMI BIOS is lying to me during the boot and
pass a different info to the OS when inquired afterward as suggested by someone.

Anyway, when the geometry mismatch was reported in linux fdisk after trying to install win98 and found that linux picked up CHS geometry different from that of BIOS's, I thought this was the problem.

But as Andries pointed out Win98 seemed to use the same geometry information as linux used before I made it to use the BIOS geometry by means of boot command line parameter.
This means two to one favor against BIOS's idea of CHS! The two OSs used 255 heads geometry.

So what I did was this.
(In the end, I didn't have to remove SCSI disk to check if the linux or BIOS gets confused with the SCSI disk geometry info.)

Firstly, from linux, I did the following in order to
try my another attempt to wipe out the partition information for sure.

    dd if=/dev/zero of=/dev/hda bs=16kb count=1

Please note the much larger bs than I originally used.
Also note the generic hda device rather than the
/dev/hdaZ (Z=1 or whatever).
I probably should have made count much bigger, but
I ran the command in this mannter. And it seemed to do the trick anyway.

[This obviously wiped out the partition information completely. Good.]

Then I rebooted the computer (reboot from linux).
During the boot, I entered the BIOS setup mode.
I manually set the BIOS geometry for the disk from AUTO to USER and set 2940/255/63, which was used by Linux and seemingly win98 too.

Next, I booted the PC using win98 installation floppy and found that it reported
"no partition exists" warning!
Good. Wiping out of the partition info confirmed.
(As a matter of fact, previously when I experimented with dd, etc., the partition information somehow persisted. At this stage in my previous attempt, I could run Win98 format command and it simplay answered all the data on c drive would
disappear, and I was forced to wonder WHERE format picked up the idea of the C driver partition. Obviously, my dd command was not clearing large enough area or I was mistyping the command parameter(?))

As a next step, although I was advised to stay away from disk manager tools, which I believe is a good advice in general, I used Seagate Disk Manager DM.exe for partition/formating purpose ONLY (I think).
If you compare the speed of formating of this tool agains MS's, this tool
wins hands down. It is BLAZINGLY fast. (Actually I found that Western Digital's similar tool also runs very fast. Maybe the same origin.)

Anyway, using DM.exe, I ended up again with 10 FAT16 partitions on the disk,
one of which is the primary partition, and the rest are logical partions in the
extended partition.

Now it is time to learn whether both the win98 (or more to the point the DM.exe) , and linux used the same geometry now recorded in the BIOS explicitly.

So I rebooted Linux using loadlin floppy WITHOUT specifiying hda=ccc,hhh.sss. : previously I had hda=39694/16/63, which was the natural CHS picked up on AWARD BIOS motherboards for this disk somehow. (Without hda parameter, it used the 2940/255/63 after I began playing with old Debian GNU/Linux CD as explained in my previous post.).

After booting linux, I checked the print out of the fdisk: the following is
the output.
As you can see below, no boundary mismatch information reported anymore. Perfect.
---------------------------------------------
Command (m for help): p

Disk /dev/hda: 255 heads, 63 sectors, 2490 cylinders Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1       249   2000061    6  FAT16
/dev/hda2           250      2490  18000832+   f  Win95 Ext'd (LBA)
/dev/hda5           250       498   2000061    6  FAT16
/dev/hda6           499       747   2000061    6  FAT16
/dev/hda7           748       996   2000061    6  FAT16
/dev/hda8           997      1245   2000061    6  FAT16
/dev/hda9          1246      1494   2000061    6  FAT16
/dev/hda10         1495      1743   2000061    6  FAT16
/dev/hda11         1744      1992   2000061    6  FAT16
/dev/hda12         1993      2241   2000061    6  FAT16
/dev/hda13         2242      2490   2000061    6  FAT16

------------------------------------------------

So I think in my case the command with a large bs worked:

dd if=/dev/zero of=/dev/hda bs=16kb count=1

Under this partitioning scheme, I re-installed win98 in the /dev/hda1 partition above, and as far as I can see,
win98 boots just fine.
My 2.4.0-test12 image resides in a separate scsi disk and
I can boot it using loadlin and the boot image that reside in the /dev/hda1 partition: I enter win98 commad only mode and run loadlin from there. I am thinking of installing 2.2.18 on one of the

logical partitions now.

I would like to thank people including Andries and those who sent me tips via e-mailed, too.

PS: Given that there was off-by-one error in the BIOS calculation of CHS, I wonder if the AMI BIOS is returning the appropriate info to the inquirying OS (linux or win98). I don't understand why linux and win98 use different CHS inforamtion than the one BIOS used (when AUTO detection is turned on). As far as linux was concerned, the BIOS and linux geometry matched on AWARD BIOS motherboards.
On the other hand, there seems to be
enough freedom in picking up the mapping (for LBA, etc..) in the handling of large disks and that AWARD BIOS seems to use an algorithm that is friendly or idential to the geometry alogrithm used by linux and win98. So AMI BIOS may not be to blame after all.

Very puzzling situation until things settled down somehow.

Thank you again.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I sent out a longish response a few minutes ago which explained the my problem was solved somehow!

One thing I missed explaining in my original post is the AMI BIOS on the GA-7IXE4 motherboard
has a very spartan set of options.

For the geometry translation of ATA disk, only On/Off choice was available and according to help message On means LBA and Off is non-LBA (normail?).
I let LBA on during my trials and errors.

AWARD BIOS would have shown
none/auto/large/lba, etc. for the same choice.

Well, AMI BIOS seems to be pretty minor these days. I have seen it lately
on my current motherboard as well as onthe low-price end machines from small vendors, inside VMware's virtual PC environment(!), but nowhere else. There could be some rough edges still around due to smaller
user base.

I am glad I have been using SCSI disk.
If it had not been for my 2.4.0-test12 on a scsi disk I moved from my old PC,
I would not have been able to
use linux successfully with Win98 partition on
this motherboard for a couple of weeks.

I guess my motherboard is somewhat exceptional case where BIOSreports a geometry
that didn't match the geometry used by popular OSes.

Again thank you everybody for helpful tips.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/