Re: [patch-required!] Recent kernels show problems in handling VERY large HDs

From: Andreas Eibach (a.eibach@gmx.net)
Date: Sat Sep 09 2000 - 14:18:23 EST


> Interesting. So far I have been able to help three or four people
> with a similar setup, but without EZDrive.

Hmmm...maybe it's me who let himself fool by the docs.
Well they told me if Capacity Limiter is used, you MUST use EZDrive to get
full capacity.
Let's hope this _is_ a must. I get to believe it's not and I could have
skipped that part.

>
> The present theory is:
> (i) AWARD BIOS 4.51PG crashes when it sees a disk larger than 32 GB.
Yup. Well I would change 'crashes' into 'stops', though. :)
It just doesn't move on.

> (ii) Applying the J46 jumper is equivalent to a SETMAX command
> and turns the disk into a 32 GB one. (The precise effect depends
> on the model. Early models also require a utility JUMPON.EXE.)

^^^^^^^^^^^^
> This allows one to boot.

Yup I got JumpOn.exe. But since my jumper works, I probably don't need it.

> (iii) EZDrive/MaxBlast or Linux can issue a SETMAX command to get
> full capacity again.

Hmm...and this works WITHOUT removing the jumper first?
Hey, I must try that ... can't wait :)

> By separate mail I'll send you a setmax utility, so that you
> can play a bit with these things.

thank you very much.

> (I cannot really release utilities like setmax before the ioctl
> code in ide.c has been adapted very slightly. Will produce a patch
> if I have time later this evening.)
Amazing.

> > (Note: I've got latest 2.10o tarball here now, one of my suspects
> > causing the errors below was Fdisk at first)
>
> With large disks it is always good to have a recent fdisk.
> (Forgot whether 2.9f is too old.) But your problem is elsewhere.
I think so.

> > OUCHIE...
> >
> > ide0: reset: success
> > [EZD] [remap 0->1] [7473/255/63] hda1 hda2 hda3 < hda5 hda6 hda7 hda8
hda9
> > hda10 hda11 hda12hda: read_intr: status=0x59 { DriveReady SeekComplete
> > DataRequest Error }
> > hda: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=71987265,
sector=0
> > hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest
Error }
> > hda: read_intr: error=0x10 { SectorIdNotFound }, LBAsect=71987265,
sector=0
> > hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest
Error }
>
> This is clear: the kernel tries to read sector 71987265, that
> is 71987265*512=36857479680 bytes (37 GB) from the start, but
> the disk was clipped to 32 GB, so the disk reports that it
> cannot find such a sector: DriveReady SeekComplete SectorIdNotFound.

Argh...now that I see it a 2nd time, everything is so obvious. :-)

> Apparently you have been able to partition the disk.
> Was that under Linux?

Nope, of course not. [MS-DOS 7]
That's the trick the original maxtor documentation described:
If you use the J46, your hard disk appears 32GB in size for the *BIOS*, but
for the OS it's still
full capacity _if and ONLY if_ EZDrive is used.

But after all your posts here, I believe it would also worked WITHOUT
EZDrive, though.. Damn.
I swear I'd do anything to get this undone. But restoring 25 GB of data is
not an easy task...

> What interests me: did you boot Linux via MaxBlast?

WELL ......... hold on. I believe I must say 'yes' now :)

I boot Linux via LOADLIN by pressing [F8] before I start Windows.
This leads me to DOS mode, however, this EZDrive bastard _is_ _active_
_already_.
How true, actually.

You could be right - this would work if I pressed [F5] to bypass EZDrive,
perhaps.
However, if it turns out that I MUST bypass EZDrive, I cannot longer quit
windows 95 into
MS-DOS and boot up Linux after my Windows session *without* rebooting
because EZDrive is still in memory..
Got it?

> In that case I would have expected that MaxBlast already
> had unlocked the upper part of the disk.
I don't get this. What do you mean?

Andreas

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:12 EST