Messages in this thread | | | Date | Fri, 4 Dec 1998 14:40:47 -0600 (CST) | From | "Andre M. Hedrick" <> | Subject | Re: IDE disk geometry + patch |
| |
On Fri, 4 Dec 1998 Andries.Brouwer@cwi.nl wrote:
No history and experience are his guide (about 6+ years).
> Hmm. It sounds like you react without thinking. > Look at the code I want to replace. It corrects bios_cyl > under certain circumstances. I want to correct bios_cyl > under a wider set of circumstances. > It is not at all the case today that the Linux kernel > preserves the BIOS view on the number of cylinders.
Please try this before you get to far.....
Reset the BIOS on your mainboard for AUTO/AUTO and do not use the silly disk-detect which gets the RAW CHS correct, but it to stupid to adjust for LBA. I am will ing to bet if you poke your nose into what the BIOS declares for each disk. The RAW LBA settings are wrong by the total missing number of cylinders that you claim are not detected by the kernel.
Trust me I know this does/can/usually is the case........
I have a disk that is exactly 16383,16,63 and the BIOS gets it dead wrong everytime I auto-detect........Now if I go and manually enter the 'TRUE' CHS values into the bios-disk parameters as a user defined setting, it will work.......Second is to skip this pain in the rear, and set the flags to AUTO/AUTO and include that PIO settings are AUTO also.
An AWARD Bios's config options that are effected are at the top of each column of options.
AMI Bios's require the former method be used....drat......
The key clue to you problem was detection of "1024,255,63" this is my classic 'screaming red-flag' warning that the BIOS can't or is not allowed to count beyond a sector limit for an 8.0 Gig device (using the REAL definition of a MEG of disk space)
1Meg != 1,000,000 bytes (sales pitch) 1Meg != 1,024,000 bytes (memory) 1Meg == 1,048,576 bytes (reality) == 2^20
Now FDISK and LILO are a whole other issue.......
> Now think about the fdisk and LILO interaction. > What is the effect of a too small number of cylinders? > That part of the disk is inaccessible.
Yes if you choose not to inform the kernel that your computer is an idiot that can't count.
ide_setup: hda=1247,255,63 ide_setup: hdc=1247,255,63 ide: Intel 82371 (single FIFO) DMA Bus Mastering IDE Controller on PCI bus 0 function 57 ide: timings == a307e377 ide0: BM-DMA at 0xf000-0xf007 ide1: BM-DMA at 0xf008-0xf00f hda: QUANTUM FIREBALL EL10.2A, 9787MB w/418kB Cache, CHS=1247/255/63, (U)DMA hdb: QUANTUM FIREBALL EL10.2A, 9787MB w/418kB Cache, CHS=1247/255/63, (U)DMA ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15
(Note, beginning steps of hardware RAID 1)
ide: PDC20246 UDMA Bus Mastering with ROM enabled but no address Controller on PCI bus 0 function 152 ide: timings == 000003ee ide0: BM-DMA at 0x7c00-0x7c07 ide1: BM-DMA at 0x7c08-0x7c0f ide: Intel 82371 (single FIFO) DMA Bus Mastering IDE Controller on PCI bus 0 function 57 ide: ports are not enabled (BIOS) hda: QUANTUM FIREBALL EL10.2A, 9787MB w/418kB Cache, CHS=19885/16/63, UDMA hdc: QUANTUM FIREBALL EL10.2A, 9787MB w/418kB Cache, CHS=19885/16/63, UDMA ide0 at 0x6c00-0x6c07,0x7002 on irq 11 ide1 at 0x7400-0x7407,0x7802 on irq 11 (shared with ide0)
ide_setup: hda=1247,255,63 ide_setup: hdc=1247,255,63 hda: QUANTUM FIREBALL EL10.2A, 9787MB w/418kB Cache, CHS=1247/255/63, UDMA hdc: QUANTUM FIREBALL EL10.2A, 9787MB w/418kB Cache, CHS=1247/255/63, UDMA
This logs from a modified version of 2.0.35. Note that all three cases work with on/off board chipsets
> For LILO one may live with that - there have always > been restrictions on the place of the kernel on disk. > But for fdisk that is inacceptable - people struggle > with this, and - as far as I can see - there is no > reason at all to inflict these problems unto them. > > The number of people with 8+ GB disks increases quickly. > The handling of large IDE disks has always been broken, > but in 2.0.35 and 2.1.90 this problem was partially > corrected by inserting the test for C/H/S=16383/16/63. > However, this only solves the problem if the BIOS is > not using a translation (`LBA' or `Large' or so). > People with a large IDE disk and translating BIOS > still cannot use the entire disk (without overriding > the kernel view by giving LILO additional hda=C,H,S > parameters, or going into expert mode of fdisk, etc.). > > The sooner this is corrected, the better.
I agree, but lets not carelessly blind-side the BIOS....I have done this many times by disregarding Mark's and Gadi's warnings.......thus trashed my various systems at least one order of magnitude that you have. However I did learn..........
As for the issue at hand.......I have been looking to that problem for several months, well the next day after I got my first 8.0+ Gig drive. I have dirty solutions that are getting cleaner everyday.
Feel free to post a real patch and document it and ask people to test it and report back...........did I forget the FLAME factor.........
When I started to begin maintaining the IDE-driver at 2.1.121/122 transistion........I got out my asbestos suit and needed it.......not til 2.1.126/127 did I resolve the need parts of patch code not submitted in the beginning. I thought I got it right with 6 different system tests and various mainboards.
Except for that ASUS P55T2P4D (decouple PIIX3 from host/isa bridges) with a Promise Ultra33......but I had a quick solution, because I guess every possible breaks and gamble/lost/re-patched what I thought was obvious.
My warning is to make ever WAG (wild a** guess) of problems and test the limits of every combination you can think of to break and bust you solution, note you will miss at least one.........
> Andries >
Cheers, Andre Hedrick The IDE-FNG for Linux The APC UPS Specialist for Linux
http://www.dyer.vanderbilt.edu/server/udma/ http://www.dyer.vanderbilt.edu/server/apcupsd/apcupsd-3.5.0.bin.tar.gz
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |