Very Computer

I have an old motherboard for which I bought a Maxtor (6Y080P0) 80 gig
EIDE hard drive.  When I connected the drive to the motherboard, the
system hung.  I did some reading and found that the drive has a
capacity limit jumper that causes the BIOS to see about 34 gig and
that some old BIOSes will do this* thing.  I'd really like to
use the whole drive.  More reading turned up a program called 'setmax'
which can (and does) soft enable the full size of the drive even with
the capacity limit jumper installed.  What I couldn't find is exactly
how I can use this program in a boot script.  One response in a forum
said to use it in /etc/rc.sysinit and his comment was he put it "at
the top", though didn't specify exactly where.  I tried that, putting
it just after the banner code and before fsck is run and doing that
really screwed things up.  I restored the system's function by moving
the drive to another server, mounting it and removing the call to
setmax for now.

With the system running again, I did these:

hdparm /dev/hda says this:

/dev/hda:
 multcount    = 16 (on)
 I/O support  =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 65531/16/63, sectors = 66055248, start = 0
 busstate     =  1 (on)

if I run setmax /dev/hda I get this:

Using device /dev/hda
native max address: 160086527
that is 81964302336 bytes, 82.0 GB
lba capacity: 66055248 sectors (33820286976 bytes)

This agrees with hdparm.

and this command:

setmax -d 0 /dev/hda      gives this:

Using device /dev/hda
setting delta=0
nativemax=160086527 (0x98ab9ff)
lba capacity: 160086528 sectors (81964302336 bytes)

From what I can see, the setmax program looks like it is doing what
it's supposed to.  And running it after the system is fully booted
causes no problems.

The last partition on the drive is a share that is limited to 20 gigs,
(the first three partitions are small enough to fit into the first 34
gigs) what I'd like to do (if possible) is to remove the last
partition, run setmax and add the last partition again, but after
running setmax I'm assuming I should be able to get a much larger
share partition.  

Is that going to work?  If not, how should I approach repartitioning
the drive so that I can use it with setmax?

Once I get the drive properly partitioned, one option I've considered
is to edit fstab so that /share is not mounted automatically at boot
time and then run setmax in rc.local followed by a mount command for
/share.  I'll also want to turn off fsck for that partition and run it
in rc.local (I think).

This is a Red Hat 7.3 system.  The CPU is a 400 MHz K6/2 which is
still quite useful and would be more so with this larger drive,
especially if I can get all of it working.  So far, web and forum
searches have only given hints, such as using setmax, but I found no
how-to that spells out exactly where it should be run at boot time and
what else needs to be done to the drive to get it to work properly.

Has anyone had experience with this kind of thing?

Is there a more detailed how-to I can read?

Help greatly appreciated, I really don't want to retire what is a
working motherboard just because of this presumably fixable problem.

I have two more of these drives and I can plug one of them into the
system to do experiments on if that helps.

-- Scott

Quote:> I have an old motherboard for which I bought a Maxtor (6Y080P0) 80 gig
> EIDE hard drive.  When I connected the drive to the motherboard, the
> system hung.  I did some reading and found that the drive has a
> capacity limit jumper that causes the BIOS to see about 34 gig and
> that some old BIOSes will do this* thing.  I'd really like to
> use the whole drive.  More reading turned up a program called 'setmax'
> which can (and does) soft enable the full size of the drive even with
> the capacity limit jumper installed.  What I couldn't find is exactly
> how I can use this program in a boot script.  One response in a forum
> said to use it in /etc/rc.sysinit and his comment was he put it "at
> the top", though didn't specify exactly where.  I tried that, putting
> it just after the banner code and before fsck is run and doing that
> really screwed things up.  I restored the system's function by moving
> the drive to another server, mounting it and removing the call to
> setmax for now.

I've dealt with things like this before on older systems.  On one
system, a Compaq Pentium 166, I wanted to hook up a 200g drive that
would be a samba share basically for me.  The drive could not be seen by
the bios but Linux itself dealt with the drive without some additional
utility.  So what I did was add a small drive that the bios could see up
front on /dev/hda1 like perhaps a 10 or 20 or something gig drive.  
Basically a drive that is a known good thing for the bios.  Then I added
the second drive and told the bios to ignore that drive.  The system
booted on the /dev/hda that the bios supported with no problems and
ignored the second drive.  Instead of using a bundled disk management
program, I just used linux since it takes over from the bios effectively
and will see that second drive with no problems.  I fdisk'ed the second
drive (/dev/hdb) while in Linux and added the shares I wanted to use.  
Linux itself saw the whole drive and did not need a secondary utility
program to run.  Then I just added the drive to /etc/fstab, created
shares for samba there, and was done.

If you just use Linux, you won't have to worry about how to launch some
utility from an init script.  This would depend on you having an
acceptable drive at /dev/hda to use as the so-called "boot drive" and
turning off or having the older system's bios ignore the second drive.
--
Michael Perry | Do or do not. There is no try --Master Yoda

On Wed, 19 Oct 2005 09:13:37 -0700, Michael Perry

Yes, I did read about this method, and I will use it as a last resort.
I believe I have a working 6 gig drive.  I was hoping to do this all
on the one drive.  The setmax utility seems to work, but the partition
table was created before I knew about it.  I'm hoping that I can copy
the partition's data to another server, then run setmax -d 0 to tell
the drive to report the full LBA capacity and then remove and re-add
the last partition which is upper bound by the current cyl limit of
65531 set by the jumper.  I can tell fdisk that the drive has 158816
cylinders before adding the partition.  Then I think I'm OK if I don't
mount the partition until after setmax is executed.  Since it's just a
file service share for Samba and NFS, this should work fine.  Tonight
I will play with an extra 80 gig drive so I can see if it works
without risking crashing the system again.  

Thanks for the response.