Bigggg Maxtor drives (fwd)

Bigggg Maxtor drives (fwd)

[Andre Hedrick]

another update request --


---------- Forwarded message ----------
Date: Mon, 31 Dec 2001 12:16:12 -0800
From: ablew@internetcds.com
To: andre@linux-ide.org
Subject: Bigggg Maxtor drives

Hi there.  As I understand it you're the linux IDE guy,
so if you don't mind answering a question for me, I'd
appriciate it.

I recently bought a Maxtor 4G160J8.  This hard drive is
Maxtor's biggest harddrive as of yet, coming in at
160GB.  Linux sees this drive as a mere 134 or so gigs
as shown by the below:

hde: Maxtor 4G160J8, ATA DISK drive
hde: 268435455 sectors (137439 MB) w/2048KiB Cache,
CHS=266305/16/63, UDMA(33) hde: hde1

Do I need to pass the kernel any arguments though grub
to see the full size, or is this just a kernel level
limitation?

Any help is appriciated.

Thanks,
-Aaron

Re: Bigggg Maxtor drives (fwd)

[Benjamin S Carrell]

I would think that you lose that space to formatting (would it not get 
the size of the drive from the bios?), but I stand open for correction.

-Ben Carrell
ben@xmission.com

Andre Hedrick wrote:

>another update request --
>
>
>---------- Forwarded message ----------
>Date: Mon, 31 Dec 2001 12:16:12 -0800
>From: ablew@internetcds.com
>To: andre@linux-ide.org
>Subject: Bigggg Maxtor drives
>
>Hi there.  As I understand it you're the linux IDE guy,
>so if you don't mind answering a question for me, I'd
>appriciate it.
>
>I recently bought a Maxtor 4G160J8.  This hard drive is
>Maxtor's biggest harddrive as of yet, coming in at
>160GB.  Linux sees this drive as a mere 134 or so gigs
>as shown by the below:
>
>hde: Maxtor 4G160J8, ATA DISK drive
>hde: 268435455 sectors (137439 MB) w/2048KiB Cache,
>CHS=266305/16/63, UDMA(33) hde: hde1
>
>Do I need to pass the kernel any arguments though grub
>to see the full size, or is this just a kernel level
>limitation?
>
>Any help is appriciated.
>
>Thanks,
>-Aaron
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>

Re: Bigggg Maxtor drives (fwd)

[Chris Ball]

On Wed, Jan 09, 2002 at 08:14:32PM -0700, Benjamin S Carrell wrote:
> I would think that you lose that space to formatting

That would be irrelevant.  We're looking at the kernel's summation of
the geometry, not the filesystem's description of usable space.

> (would it not get the size of the drive from the bios?)

No, the kernel tends not to rely on the BIOS for geometry.  Which is
usually very wise.

> but I stand open for correction.

Same here.  It's always a good idea.  :-)

Is this perhaps Maxtor providing their own 'non-standard'[1] definition
of gigabyte, rather than a technical issue?

- Chris.

[1]: (viz. 'wrong')
-- 
$a="printf.net"; Chris Ball | chris@void.$a | www.$a | finger: chris@$a
As to luck, there's the old miners' proverb: Gold is where you find it.

Re: Bigggg Maxtor drives (fwd)

[Jim Crilly]

Actually it would seem this is just Andre's, not so subtle, way of 
trying to prove that his ATA133/48-bit addressing patches need included 
in 2.4.

-Jim

Chris Ball wrote:

> On Wed, Jan 09, 2002 at 08:14:32PM -0700, Benjamin S Carrell wrote:
> 
>>I would think that you lose that space to formatting
>>
> 
> That would be irrelevant.  We're looking at the kernel's summation of
> the geometry, not the filesystem's description of usable space.
> 
> 
>>(would it not get the size of the drive from the bios?)
>>
> 
> No, the kernel tends not to rely on the BIOS for geometry.  Which is
> usually very wise.
> 
> 
>>but I stand open for correction.
>>
> 
> Same here.  It's always a good idea.  :-)
> 
> Is this perhaps Maxtor providing their own 'non-standard'[1] definition
> of gigabyte, rather than a technical issue?
> 
> - Chris.
> 
> [1]: (viz. 'wrong')
> 

Re: Bigggg Maxtor drives (fwd)

[Rik van Riel]

On Wed, 9 Jan 2002, Jim Crilly wrote:

> Actually it would seem this is just Andre's, not so subtle, way of
> trying to prove that his ATA133/48-bit addressing patches need
> included in 2.4.

I think you'll agree with him the moment you end up with
a cheap 160 GB drive in your machine and the old driver
(which is limited to 32(?)-bit LBA) won't let you use a
large portion of the disk ;)

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: Bigggg Maxtor drives (fwd)

[Jens Axboe]

On Thu, Jan 10 2002, Rik van Riel wrote:
> On Wed, 9 Jan 2002, Jim Crilly wrote:
> 
> > Actually it would seem this is just Andre's, not so subtle, way of
> > trying to prove that his ATA133/48-bit addressing patches need
> > included in 2.4.
> 
> I think you'll agree with him the moment you end up with
> a cheap 160 GB drive in your machine and the old driver
> (which is limited to 32(?)-bit LBA) won't let you use a
> large portion of the disk ;)

It's 28-bit LBA, which means

2^28 * 512 == 137GB (hard disk manufacturer gigs)

So waste is just 23GB :-)

Once the ide stuff has been proven, of course it will get integrated.

-- 
Jens Axboe

Re: Bigggg Maxtor drives (fwd)

[Marcel J.E. Mol]

On Thu, Jan 10, 2002 at 01:15:57PM +0100, Jens Axboe wrote:
> On Thu, Jan 10 2002, Rik van Riel wrote:
> > On Wed, 9 Jan 2002, Jim Crilly wrote:
> > 
> > > Actually it would seem this is just Andre's, not so subtle, way of
> > > trying to prove that his ATA133/48-bit addressing patches need
> > > included in 2.4.
> > 
> > I think you'll agree with him the moment you end up with
> > a cheap 160 GB drive in your machine and the old driver
> > (which is limited to 32(?)-bit LBA) won't let you use a
> > large portion of the disk ;)
> 
> It's 28-bit LBA, which means
> 
> 2^28 * 512 == 137GB (hard disk manufacturer gigs)
> 
> So waste is just 23GB :-)

At the current rate the 200GB or 32GB disk will appear in a couple of 
days:  320-137 = 183 GB :-)

> 
> Once the ide stuff has been proven, of course it will get integrated.
> 

At this time it is stale enough to keep my laptop from filesystem
corruption (write cash flush)...

-Marcel
-- 
     ======--------         Marcel J.E. Mol                MESA Consulting B.V.
    =======---------        ph. +31-(0)6-54724868          P.O. Box 112
    =======---------        marcel@mesa.nl                 2630 AC  Nootdorp
__==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____
 They couldn't think of a number,           Linux user 1148  --  counter.li.org
    so they gave me a name!  -- Rupert Hine  --  www.ruperthine.com

Re: Bigggg Maxtor drives (fwd)

[Hans Reiser]

Marcel J.E. Mol wrote:

>
>At this time it is stale enough to keep my laptop from filesystem
>corruption (write cash flush)...
>
>-Marcel
>

Can you say more about this?

Hans

Re: Bigggg Maxtor drives (fwd)

[Jens Axboe]

On Thu, Jan 10 2002, Hans Reiser wrote:
> Marcel J.E. Mol wrote:
> 
> >
> >At this time it is stale enough to keep my laptop from filesystem
> >corruption (write cash flush)...
> >
> >-Marcel
> >
> 
> Can you say more about this?

Search the archive, it was discussed here a few days back. Key words:
suspend flush

-- 
Jens Axboe

Re: Bigggg Maxtor drives (fwd)

[Lionel Bouton]

Rik van Riel wrote:

>On Wed, 9 Jan 2002, Jim Crilly wrote:
>
>>Actually it would seem this is just Andre's, not so subtle, way of
>>trying to prove that his ATA133/48-bit addressing patches need
>>included in 2.4.
>>
>
>I think you'll agree with him the moment you end up with
>a cheap 160 GB drive in your machine and the old driver
>(which is limited to 32(?)-bit LBA) won't let you use a
>
28-bit addressing space with 512 byte sectors in fact.
Max corresponding capacity : 2^28 x 512  = 2^37 = 128 GiB ~ 137 GB

LB.

Re: Bigggg Maxtor drives (fwd)

[Alan Cox]

> I think you'll agree with him the moment you end up with
> a cheap 160 GB drive in your machine and the old driver
> (which is limited to 32(?)-bit LBA) won't let you use a
> large portion of the disk ;)

Its also the only thing that is stable on my highpoint secondary controllers

Re: Bigggg Maxtor drives (fwd)

[David Weinehall]

On Thu, Jan 10, 2002 at 12:40:40PM +0000, Alan Cox wrote:
> > I think you'll agree with him the moment you end up with
> > a cheap 160 GB drive in your machine and the old driver
> > (which is limited to 32(?)-bit LBA) won't let you use a
> > large portion of the disk ;)
> 
> Its also the only thing that is stable on my highpoint secondary controllers

What is, the new or the old driver?


Regards: David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Maintainer of the v2.0 kernel   //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: Bigggg Maxtor drives (fwd)

[Alan Cox]

> > Its also the only thing that is stable on my highpoint secondary controllers
> 
> What is, the new or the old driver?

New driver. With the old driver I have to run them PIO non UDMA

Re: Bigggg Maxtor drives (fwd)

[Aaron Blew]

This is where I am right now :).  25+GB of space I can't use is
frustrating, especially considering that I've only got 30-40GB free,
with space dissappearing regularly (I obsessively capture video off TV
:)).

Hope it gets included,
-Aaron

On Thu, 2002-01-10 at 04:11, Rik van Riel wrote:
> On Wed, 9 Jan 2002, Jim Crilly wrote:
> 
> > Actually it would seem this is just Andre's, not so subtle, way of
> > trying to prove that his ATA133/48-bit addressing patches need
> > included in 2.4.
> 
> I think you'll agree with him the moment you end up with
> a cheap 160 GB drive in your machine and the old driver
> (which is limited to 32(?)-bit LBA) won't let you use a
> large portion of the disk ;)
> 
> Rik
> -- 
> "Linux holds advantages over the single-vendor commercial OS"
>     -- Microsoft's "Competing with Linux" document
> 
> http://www.surriel.com/		http://distro.conectiva.com/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Bigggg Maxtor drives (fwd)

[Jens Axboe]

On Thu, Jan 10 2002, Aaron Blew wrote:
> This is where I am right now :).  25+GB of space I can't use is
> frustrating, especially considering that I've only got 30-40GB free,
> with space dissappearing regularly (I obsessively capture video off TV

I always read emails like that, what exactly is wrong with having
patches out-of-kernel for a while? Surely nothing prevents you from
applying them when you upgrade your kernel?!

Note that this is not an email saying we should not include Andre's
work, I'm quite sure we will do that eventually.

-- 
Jens Axboe

Re: Bigggg Maxtor drives (fwd)

[Ricky Beam]

On Wed, 9 Jan 2002, Jim Crilly wrote:
>Actually it would seem this is just Andre's, not so subtle, way of
>trying to prove that his ATA133/48-bit addressing patches need included
>in 2.4.

And I'm sure many of his patches would be accepted if he sent them in the
method prescribed by Linus (loudly and on multiple occasions.)  That is,
ONE patch to fix or support *ONE* thing. (Translation: minimize the amount
of stuff you screw up with your patch.) The "megapatch" is deleted on sight.

*I* would certainly appreciate individual patches.

--Ricky

Re: Bigggg Maxtor drives (fwd)

[Alan Cox]

> And I'm sure many of his patches would be accepted if he sent them in the
> method prescribed by Linus (loudly and on multiple occasions.)  That is,

Loudly  - check. Believe me Andre is -LOUD-

> ONE patch to fix or support *ONE* thing. (Translation: minimize the amount
> of stuff you screw up with your patch.) The "megapatch" is deleted on sight.

I really don't think you can split that IDE stuff. I worked over some of
that with Andre for the -ac merge, and you just can't split it. Instead it
does the next best thing - you can run some code paths with the old or new
style

Re: Bigggg Maxtor drives (fwd)

[Ricky Beam]

On Thu, 10 Jan 2002, Chris Ball wrote:
>> (would it not get the size of the drive from the bios?)
>
>No, the kernel tends not to rely on the BIOS for geometry.  Which is
>usually very wise.

Except for rare cases involving LILO.  It needs to know what the BIOS thinks
the geometry is.  In the case of my laptop (Compaq LTE 5400 -- I know, buy
something less that a decade old), I have to guess since linux doesn't keep
anything the BIOS provides.

--Ricky

Re: Bigggg Maxtor drives (fwd)

[Andre Hedrick]

Sorry but the amount of capacity we are talking about is vastly different.

hdg: Maxtor 4G160J8, ATA DISK drive
hdg: 320173056 sectors (163929 MB) w/2048KiB Cache, CHS=317632/255/63, UDMA(133)


> >hde: Maxtor 4G160J8, ATA DISK drive
> >hde: 268435455 sectors (137439 MB) w/2048KiB Cache,
> >CHS=266305/16/63, UDMA(33) hde: hde1

Only the patches I have created will allow Linux to address the drives
correctly, since this is a new protocol for loading the taskfile
registers with 48-bit mode.  The other drive is being addressed in 28-bit
mode, and can NEVER access the remaining difference under this protocol.

320,173,056 - 268,435,455 = 5,173,7601 sectors

5,173,7601 * 512 = 26,489,651,712 

Roughly 26.4GB of drive capacity lost, the kernel without patches
will never address more that 137GB, and the loss of usable capacity will
continue to grow until the problem in the kernel is addressed.

All it will take is to have the 2.2/2.4/2.5 kernel maintainers to agree to
the corrective patches.

Regards,

Andre Hedrick
CEO/President, LAD Storage Consulting Group
Linux ATA Development
Linux Disk Certification Project

On Wed, 9 Jan 2002, Benjamin S Carrell wrote:

> I would think that you lose that space to formatting (would it not get 
> the size of the drive from the bios?), but I stand open for correction.
> 
> -Ben Carrell
> ben@xmission.com
> 
> Andre Hedrick wrote:
> 
> >another update request --
> >
> >
> >---------- Forwarded message ----------
> >Date: Mon, 31 Dec 2001 12:16:12 -0800
> >From: ablew@internetcds.com
> >To: andre@linux-ide.org
> >Subject: Bigggg Maxtor drives
> >
> >Hi there.  As I understand it you're the linux IDE guy,
> >so if you don't mind answering a question for me, I'd
> >appriciate it.
> >
> >I recently bought a Maxtor 4G160J8.  This hard drive is
> >Maxtor's biggest harddrive as of yet, coming in at
> >160GB.  Linux sees this drive as a mere 134 or so gigs
> >as shown by the below:
> >
> >hde: Maxtor 4G160J8, ATA DISK drive
> >hde: 268435455 sectors (137439 MB) w/2048KiB Cache,
> >CHS=266305/16/63, UDMA(33) hde: hde1
> >
> >Do I need to pass the kernel any arguments though grub
> >to see the full size, or is this just a kernel level
> >limitation?
> >
> >Any help is appriciated.
> >
> >Thanks,
> >-Aaron
> >
> >-
> >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >Please read the FAQ at  http://www.tux.org/lkml/
> >
> >
> 
> 

Re: Bigggg Maxtor drives (fwd)

[Henning P. Schmiedehausen]

Andre Hedrick <andre@linux-ide.org> writes:

>All it will take is to have the 2.2/2.4/2.5 kernel maintainers to agree to
>the corrective patches.

So you do have 2.2 patches? Where can I get them?

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: Bigggg Maxtor drives (fwd)

[Rogier Wolff]

Andre Hedrick wrote:
> 
> 
> Sorry but the amount of capacity we are talking about is vastly different.
> 
> hdg: Maxtor 4G160J8, ATA DISK drive
> hdg: 320173056 sectors (163929 MB) w/2048KiB Cache, CHS=317632/255/63, UDMA(133)

Hi Andre, 

I have one of these drives. Should I be able to run it off the promise 
controller? (Which didn't boast 48-bit compatibilty when I bought it?)

  Bus  0, device  10, function  0:
    Unknown mass storage controller: Promise Technology, Inc. 20262 (rev 1).
      IRQ 11.
      Master Capable.  Latency=32.  
      I/O at 0x9400 [0x9407].
      I/O at 0x9800 [0x9803].
      I/O at 0x9c00 [0x9c07].
      I/O at 0xa000 [0xa003].
      I/O at 0xa400 [0xa43f].
      Non-prefetchable 32 bit memory at 0xf74c0000 [0xf74dffff].

I tried it before on a "test-machine" where it ran off the onboard
controller just fine. But in my fileserver on the fast promise 
controller it just hangs while scanning the partition table. 

We're running 2.4.16 with your patch off linux-ide.org. 

	Roger. 

-----
I appreciate an Email copy on replies: I sometimes forget about the 
list for quite a while.... 
-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 

Re: Bigggg Maxtor drives (fwd)

[Andre Hedrick]

Rogier,

Please look at the pdc202xx.c code and see that it is addessed by using
the formerly unpublished DMA-ATAPI locations for the backwards support.

Please note this will require the very latest BIOS updates for the acards.

Regards,

Andre Hedrick
Linux Disk Certification Project                Linux ATA Development

On Fri, 11 Jan 2002, Rogier Wolff wrote:

> Andre Hedrick wrote:
> > 
> > 
> > Sorry but the amount of capacity we are talking about is vastly different.
> > 
> > hdg: Maxtor 4G160J8, ATA DISK drive
> > hdg: 320173056 sectors (163929 MB) w/2048KiB Cache, CHS=317632/255/63, UDMA(133)
> 
> Hi Andre, 
> 
> I have one of these drives. Should I be able to run it off the promise 
> controller? (Which didn't boast 48-bit compatibilty when I bought it?)
> 
>   Bus  0, device  10, function  0:
>     Unknown mass storage controller: Promise Technology, Inc. 20262 (rev 1).
>       IRQ 11.
>       Master Capable.  Latency=32.  
>       I/O at 0x9400 [0x9407].
>       I/O at 0x9800 [0x9803].
>       I/O at 0x9c00 [0x9c07].
>       I/O at 0xa000 [0xa003].
>       I/O at 0xa400 [0xa43f].
>       Non-prefetchable 32 bit memory at 0xf74c0000 [0xf74dffff].
> 
> I tried it before on a "test-machine" where it ran off the onboard
> controller just fine. But in my fileserver on the fast promise 
> controller it just hangs while scanning the partition table. 
> 
> We're running 2.4.16 with your patch off linux-ide.org. 
> 
> 	Roger. 
> 
> -----
> I appreciate an Email copy on replies: I sometimes forget about the 
> list for quite a while.... 
> -- 
> ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
> *-- BitWizard writes Linux device drivers for any device you may have! --*
> * There are old pilots, and there are bold pilots. 
> * There are also old, bald pilots. 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Bigggg Maxtor drives (fwd)

[Andries.Brouwer]

On Thu, Jan 10, 2002 at 04:03:09AM +0000, Chris Ball wrote:
> On Wed, Jan 09, 2002 at 08:14:32PM -0700, Benjamin S Carrell wrote:
> > I would think that you lose that space to formatting
>
> Is this perhaps Maxtor providing their own 'non-standard'[1] definition
> of gigabyte, rather than a technical issue?
>
> [1]: (viz. 'wrong')

No, *all* disk manufacturers *always* use decimal, correctly following
the standard. And it has been like this for many years.

No, this is an entirely different phenomenenon.
In the Large Disk Howto you can read in
        http://www.win.tue.nl/~aeb/linux/Large-Disk-4.html#ss4.2
about IDE limits:

ATA Specification (for IDE disks) - the 137 GB limit

    At most 65536 cylinders (numbered 0-65535), 16 heads (numbered 0-15),
    255 sectors/track (numbered 1-255), for a maximum total capacity of
    267386880 sectors (of 512 bytes each), that is, 136902082560 bytes
    (137 GB). This is not yet a problem (in 1999), but will be a few
    years from now.

And indeed, in 2001 the 137 GB limit was crossed.
In order to make addressing of larger disks possible, a new addressing
mode was introduced (in the ATA6 draft, rev 0b), that uses 48-bit
addressing (instead of 28-bit). Thus, the new limit is roughly 
a million times larger.

Thus, we need new code that implements the new addressing.
Since one only hears positive reports on Andre's patch, probably
we should take all of it, but the code for 48-bit addressing
is a small fragment that could also easily be separated out.

Andries