Re: IDE woes:linux and BIOS won't agree on C/H/S detection
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/
Re: IDE woes:linux and BIOS won't agree on C/H/S detection
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 BootStart EndBlocks Id System /dev/hda1 * 1 249 2616 FAT16 /dev/hda2 250 2490 18000832+ f Win95 Ext'd (LBA) /dev/hda5 250 498 2616 FAT16 /dev/hda6 499 747 2616 FAT16 /dev/hda7 748 996 2616 FAT16 /dev/hda8 997 1245 2616 FAT16 /dev/hda9 1246 1494 2616 FAT16 /dev/hda10 1495 1743 2616 FAT16 /dev/hda11 1744 1992 2616 FAT16 /dev/hda12 1993 2241 2616 FAT16 /dev/hda13 2242 2490 2616 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
Re: IDE woes:linux and BIOS won't agree on C/H/S detection
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 BootStart EndBlocks Id System /dev/hda1 * 1 249 2616 FAT16 /dev/hda2 250 2490 18000832+ f Win95 Ext'd (LBA) /dev/hda5 250 498 2616 FAT16 /dev/hda6 499 747 2616 FAT16 /dev/hda7 748 996 2616 FAT16 /dev/hda8 997 1245 2616 FAT16 /dev/hda9 1246 1494 2616 FAT16 /dev/hda10 1495 1743 2616 FAT16 /dev/hda11 1744 1992 2616 FAT16 /dev/hda12 1993 2241 2616 FAT16 /dev/hda13 2242 2490 2616 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: IDE woes:linux and BIOS won't agree on C/H/S detection
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/
Re: IDE woes:linux and BIOS won't agree on C/H/S detection
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 - 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/
Re: IDE woes:linux and BIOS won't agree on C/H/S detection
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 BootStart EndBlocks Id System > > /dev/hda1 * 1 3969 2616 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 - 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/
Re: IDE woes:linux and BIOS won't agree on C/H/S detection
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 BootStart EndBlocks Id System /dev/hda1 * 1 3969 2616 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 - 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/
Re: IDE woes:linux and BIOS won't agree on C/H/S detection
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 - 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/
Re: IDE woes:linux and BIOS won't agree on C/H/S detection
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 BootStart EndBlocks Id System > /dev/hda1 * 1 3969 2616 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
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. >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
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. 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
Re: IDE woes:linux and BIOS won't agree on C/H/S detection
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 BootStart EndBlocks Id System /dev/hda1 * 1 3969 2616 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 - To unsubscribe from this list: send the line
