> Out of the box redhat 5.2 couldnt see the correct geometry. I had to
> calculate it by hand and pass it in on the kernel command line.
Okay lets back up a few steps.
Yes 2.0.36 will generally fail to get it right.
Andries and I have about 90% of the problem resolved in the 2.0.37pre11,
if not all of it addressed. Therefore 2.0.37 is almost is not completely
capable of getting the geometry correct.
You are free to nail me for neglecting 2.0.X, but the big fish was to
resolve it in 2.1.1XX a development kernel. Backcoding developmently
geometry stuff from the development to stable was not a safe option.
It was not until 2.2.0pre8 that we got it togather and we still missed
that 15/16 head booger.
> Maybe 2.2.x gets it right now but 2.0.x is what most people are probably
> using considering 2.2.x isnt production ready yet (eg isofs is broked in
> 2.2.7, and ac4 broke smbfs)
Until 2.0.37 development is final, 2.0.36 users will need to manually pass
the geometry to the kernel.
> > I started with a blank 12.7GB drive and stepped through the code to
> > insure that it would see the problem and fix it. I knew a long time ago
> > that 8.4GB geometry issue would be coming soon.
>
> Redhat 6.0 is relatively new most people are still using 5.2 I suspect and
> this bogus CHS crap is a pain in the arse. Its bitten me twice.
I know pain, several scars on both cheeks.......
> > > Having a CHS table for this drive would have helped.
> > Nope that list would grow faster than our (USA) national debt.
> > Name the fool that would maintain that list.......NIMBY......
>
> So there needs to be good probing routines then that ignore BIOS totally
> since you really cant depend on it getting it right
The routines are present, but the onboard BIOS still gets first crack at
defining hda/hdb's geometry. You bring to the forefront an issue plaguing
me that BIOS geometries need to be verified and not taken for truth.
> > > Drive is a WDC AC310100B (~10gb). BIOS returns CHS that is completely
> > > wrong. We know true CHS is 19650,16,63. So we override the BIOS and use
> > > true CHS. Ta dah. We win, even though the BIOS is broken.
> > KABOOM you die.........second example IBM DeskStar 15/16 heads..
> > [...]
> > It is better that we play be the ATA rules and adapt for anomolies.
>
> Which is what ive been saying all along
Well good, we are on or near the same page.......
> > FYI on AWARD. Never ever use the silly drive detect tool in the BIOS.
> > Set the drive size and translations to AUTO/AUTO and it will see
> > everything. That tool of theirs is broken and sets up the CMOS/BIOS
> > values to fail or diminsih capacity.
>
> So what do you do with old AWARD bios without AUTO
Can you not get an upgrade?
You may need to use the offboard option in conjunction to calling
pci=reverse to force the onboard hwif's to be scanned last.
This is what I do since PIIX3 does not do much with ATA-33 and I can not
part with my SMP PPro 200's (OC233) w/ 512K cache, yet.
Waiting on that 64-bit Merced thingy to poke its nose up.
> So how did the scsi blacklists get in then
I do not know.......outside of my field, but I will look at it.
Aha.........there are other widgits than storage devices attached to
SCSI adapters. Since SCSI handles LUNs that IDE does not know about
and that I am talking out of my hat, it seems that the SCSI subsystem
has many more variables to address.
./drivers/scsi/scsi.c
/*
* This is what was previously known as the blacklist. The concept
* has been expanded so that we can specify other types of things we
* need to be aware of.
*/
> > If the current code still fails you at the BIOS level then we should
> > possible consider not using BIOS geometry for IDE-PCI adapters.
> > We then begin to rely solely on the drive, but some of them are kooky
> > kludges. Suggestions are welcome but reality usually molds the final
> > solution.
>
> Well what do we do on non-x86 architectures especially with the promise
> card? Eg mips or sparc or does the promise even run on those yet B)
In principle, they should handle the geometry identically as the
x86 architectures since the chipset code and ide-disk perform setups
regardless. This should be in practice for offboard adapters, that have
no tie to mapping data back to the mainboard.
Andre Hedrick
The Linux IDE guy
Candidate for pre-patch-2.2.8-series or pre-patch-2.2.9-series
http://www.dyer.vanderbilt.edu/server/udma/
2.2.7.uniform-ide-6.19.golf.patch.gz
http://www.dyer.vanderbilt.edu/server/udma/2.2.7.uniform-ide-6.19.patch.gz
http://www.dyer.vanderbilt.edu/server/udma/ide.2.0.37pre11+pat7.gz
http://www.dyer.vanderbilt.edu/server/udma/hdparm-3.5i.patch.gz
APC UPS Daemon Support Center.
http://www.brisse.dk/site/apcupsd/
GPLed source on April 7, 1999
-
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/