RE: The WHY's (RE: ide drive w/dma ... system crash)

Dan Hollis (goemon@sasami.anime.net)
Tue, 11 May 1999 13:42:42 -0700 (PDT)


On Tue, 11 May 1999, Andre M. Hedrick wrote:
> On Tue, 11 May 1999, Dan Hollis wrote:
> > Oh really? So the fact BIOS returns 16383,16,63 instead of 19650,16,63 is
> > not a BIOS bug? (Linux could *NOT!!* use the whole 10gb until I manually
> > passed in the CHS on the kernel command line).
> Wait, the BIOS is doing what it is suppose to do.
> The translation rule state that if words 1,3,6 == 16383,16,63 and LBA
> capacity exceeds or is equal to 16514064 that you need to calculate the
> cylinder value since the hardware is defined wrong.
> I challenge your statement that "Linux could *NOT!!* ...." now with the
> present kernel code.

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.

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)

> 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.

> > 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

> > 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

> 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

> > Sorry, but it does.
> The single case issue will never fly by Linus and we all know it.

So how did the scsi blacklists get in then

> 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)

-Dan

-
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/