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.
>Nov 23 20:59:40 standard kernel: hda: 3419720 sectors (1751 MB)
w/256KiB Cache, CHS=904/60/63, UDMA(33)
>Nov 23 20:59:40 standard kernel: hdc: 40011300 sectors (20486 MB)
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..
>Dec 6 17:34:22 duron kernel: ide1 at 0x170-0x177,0x376 on irq 15
>Dec 6 17:34:22 duron kernel: hda: 40011300 sectors (20486 MB) w/512KiB
Cache, CHS=2490/255/63
>Dec 6 17:34:22 duron kernel: Partition check:
>Dec 6 17:34:22 duron kernel: hda: hda1 hda2 hda4 < hda5 hda6 hda7
hda8 hda9 hda10 >
>Dec 6 17:34:22 duron kernel: Floppy drive(s): fd0 is 1.44M
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?
On Fri, Dec 22, 2000 at 03:25:20AM +0900, Ishikawa wrote:
[a long and very well documented story]
> How can I "erase" this 2940/255/63 CHS setting from the disk
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.)
> I can't get linux to properly recognize the C/H/S
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.
> On 586SG motherboard, Linux 2.4.0-testXX reported acceptable
> 39693/16/63 (QUESTION: why 39693 is one less the number reported by
> AMI BIOS? Oh well.)
You can do the computation for yourself: 40011300/(16*63) = 39693.
Apparently the AMI BIOS is buggy here.
> Nov 23 20:59:40 standard kernel: hdc: 40011300 sectors (20486 MB)
> w/512KiB Cache, CHS=39693/16/63, UDMA(33)
> 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.
>
> After digging up the old log, I found that the initially
> all was well.
>
> Nov 24 13:21:45 standard kernel: hda: 40011300 sectors (20486 MB)
> w/512KiB Cache, CHS=39693/16/63
>
> 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.)
>
> Dec 6 05:37:09 duron kernel: hda: 40011300 sectors (20486 MB)
> w/512KiB Cache, CHS=2490/255/63
>
> (3) CHS=2490/255/63 stuck?
>
> 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.)
Precisely. It doesnt help at all.
> 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?)
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.
> 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
Disk managers only make your life much more complicated.
Stay far away from them, if you can.
> 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)
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
Thank you for your tips.
Guest section DW wrote:
> 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.
>
255 head geometry seems to have crept in after I tried
the 2.2.1x installation. That is for sure.
>
> (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.
>
No I don't see [PTBL] entry in the log.
>
> (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.
>
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.
>
> 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.)
>
I will do so over the weekend and report the result..
>
> > On 586SG motherboard, Linux 2.4.0-testXX reported acceptable
> > 39693/16/63 (QUESTION: why 39693 is one less the number reported by
> > AMI BIOS? Oh well.)
>
> You can do the computation for yourself: 40011300/(16*63) = 39693.
> Apparently the AMI BIOS is buggy here.
>
Oh, how embarrassing for AMI programmers.
> > (3) CHS=2490/255/63 stuck?
> >
> > 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.)
>
> Precisely. It doesnt help at all.
>
Right, it seemed to wipe out the boot record, but the
mysterious partition info was still there.
> > 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?)
>
> 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.
>
Well, I might try just for completeness's sake.
>
> > 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
>
> Disk managers only make your life much more complicated.
> Stay far away from them, if you can.
>
Too late...
>
> > 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)
>
> 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.
>
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
On Sat, Dec 23, 2000 at 12:11:41AM +0900, Ishikawa wrote:
> I have to think more deeply then what the best measure would be.
I suppose you can get all systems involved to agree on 255 heads
if you select LBA in the BIOS.
Andries
Guest section DW wrote:
> On Sat, Dec 23, 2000 at 12:11:41AM +0900, Ishikawa wrote:
>
> > I have to think more deeply then what the best measure would be.
>
> I suppose you can get all systems involved to agree on 255 heads
> if you select LBA in the BIOS.
>
> Andries
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.
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.