AW: 160gb disk showing up as 137gb

AW: 160gb disk showing up as 137gb

[Martin Bene]

Hi,

> It's not on a raid controller.  The machine has a PIIX3 ide 
> controller and a
> AHA-2940UW scsi controller.  Both exibit the same problem.

Actually, no: To fully use 160GB ATA drives, whatever device is on the other end of the ATA bus needs to actively support 48-bit address mode. In for the two cases you tried, that means 

IDE: The kernel IDE driver needs to support 48-bit addresseing to support 160GB.

SCSI: The firmware in your IDE<->SCSI Adapter needs to support 48-bit addressing.

So, while the symptoms are the same in both cases the problem is actually in two completely different places.

Most probably, you can't do anything about the IDE<->SCSI adapters firmware; however, you can do something about the linux ATA driver: code is in the 2.4.19-pre tree, it went in with 2.4.19-pre3.

Bye, Martin

48-bit IDE [Re: 160gb disk showing up as 137gb]

[Ville Herva]

On Sat, Apr 27, 2002 at 12:16:06PM +0200, you [Martin Bene] wrote:
> 
> IDE: The kernel IDE driver needs to support 48-bit addresseing to support
> 160GB.
> 
> (...) however, you can do something about the linux ATA driver: code
> is in the 2.4.19-pre tree, it went in with 2.4.19-pre3.

But which IDE controllers support 48-bit addressing? Not all of them? Does
linux IDE driver support 48-bit for all of them? Do they require BIOS
upgrade in order to operate 48-bit?

Or can I just grab a 160GB Maxtor and 2.4.19-preX, stick them into whatever
box I have and be done with it?


-- v --

v@iki.fi

RE: 48-bit IDE [Re: 160gb disk showing up as 137gb]

[Kevin Krieser]

You need an IDE controller that supports ATA133.  For most existing
computers, that is going to require a new card.-----Original Message-----


From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Ville Herva
Sent: Saturday, April 27, 2002 7:56 AM
To: Martin Bene; linux-kernel@vger.kernel.org
Subject: 48-bit IDE [Re: 160gb disk showing up as 137gb]


On Sat, Apr 27, 2002 at 12:16:06PM +0200, you [Martin Bene] wrote:
>
> IDE: The kernel IDE driver needs to support 48-bit addresseing to support
> 160GB.
>
> (...) however, you can do something about the linux ATA driver: code
> is in the 2.4.19-pre tree, it went in with 2.4.19-pre3.

But which IDE controllers support 48-bit addressing? Not all of them? Does
linux IDE driver support 48-bit for all of them? Do they require BIOS
upgrade in order to operate 48-bit?

Or can I just grab a 160GB Maxtor and 2.4.19-preX, stick them into whatever
box I have and be done with it?

RE: 48-bit IDE [Re: 160gb disk showing up as 137gb]

[Anton Altaparmakov]

At 14:51 27/04/02, Kevin Krieser wrote:
>You need an IDE controller that supports ATA133.  For most existing
>computers, that is going to require a new card.

Rubbish! The drives are backwards compatible with all ATA standards (do a 
hparm -i on the drive and you will see). I certainly don't have an ATA133 
controller and use one of the new Maxtor ATA133 drives just fine on it.

For LBA48 support I am not too sure whether you need a special controller 
(for what it's worth I use a Promise ATA100 controller and it works fine on 
my Maxtor 120G, LBA48, ATA133 disk but the disk is possibly not big enough 
for any problems to manifest).

Perhaps Andre (cc-ed) could shed some light on this?

Best regards,

Anton

>-----Original Message-----
>
>
>From: linux-kernel-owner@vger.kernel.org
>[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Ville Herva
>Sent: Saturday, April 27, 2002 7:56 AM
>To: Martin Bene; linux-kernel@vger.kernel.org
>Subject: 48-bit IDE [Re: 160gb disk showing up as 137gb]
>
>
>On Sat, Apr 27, 2002 at 12:16:06PM +0200, you [Martin Bene] wrote:
> >
> > IDE: The kernel IDE driver needs to support 48-bit addresseing to support
> > 160GB.
> >
> > (...) however, you can do something about the linux ATA driver: code
> > is in the 2.4.19-pre tree, it went in with 2.4.19-pre3.
>
>But which IDE controllers support 48-bit addressing? Not all of them? Does
>linux IDE driver support 48-bit for all of them? Do they require BIOS
>upgrade in order to operate 48-bit?
>
>Or can I just grab a 160GB Maxtor and 2.4.19-preX, stick them into whatever
>box I have and be done with it?
>
>
>
>-
>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/

-- 
   "I've not lost my mind. It's backed up on tape somewhere." - Unknown
-- 
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: 48-bit IDE [Re: 160gb disk showing up as 137gb]

[Vojtech Pavlik]

On Sat, Apr 27, 2002 at 03:55:51PM +0300, Ville Herva wrote:
> On Sat, Apr 27, 2002 at 12:16:06PM +0200, you [Martin Bene] wrote:
> > 
> > IDE: The kernel IDE driver needs to support 48-bit addresseing to support
> > 160GB.
> > 
> > (...) however, you can do something about the linux ATA driver: code
> > is in the 2.4.19-pre tree, it went in with 2.4.19-pre3.
> 
> But which IDE controllers support 48-bit addressing? Not all of them?

ALL IDE controllers support 48-bit addressing. Actually, they don't need
to know about it.

> Does
> linux IDE driver support 48-bit for all of them?

Yes, since 2.4.19-pre3 as far as I know.

> Do they require BIOS
> upgrade in order to operate 48-bit?

Only if you need to boot from the drive and then you still can boot from
the first 140 megs or so.

> Or can I just grab a 160GB Maxtor and 2.4.19-preX, stick them into whatever
> box I have and be done with it?

That's it, yes.

-- 
Vojtech Pavlik
SuSE Labs

Re: 48-bit IDE [Re: 160gb disk showing up as 137gb]

[Vojtech Pavlik]

On Sat, Apr 27, 2002 at 04:02:54PM +0100, Anton Altaparmakov wrote:
> At 14:51 27/04/02, Kevin Krieser wrote:
> >You need an IDE controller that supports ATA133.  For most existing
> >computers, that is going to require a new card.
> 
> Rubbish! The drives are backwards compatible with all ATA standards (do a 
> hparm -i on the drive and you will see). I certainly don't have an ATA133 
> controller and use one of the new Maxtor ATA133 drives just fine on it.
> 
> For LBA48 support I am not too sure whether you need a special controller 
> (for what it's worth I use a Promise ATA100 controller and it works fine on 
> my Maxtor 120G, LBA48, ATA133 disk but the disk is possibly not big enough 
> for any problems to manifest).
> 
> Perhaps Andre (cc-ed) could shed some light on this?

For ATA133 you need a new controller if you want the 133 MB/sec speed.
But the drives will work with any lower speed controller just fine, and
the speed difference is not really noticeable.

For LBA48 you don't need any special hardware, just support for it in
the kernel. So even an old PIIX4 will do just fine. The onboard BIOS may
refuse to boot from that drive, though.

> 
> Best regards,
> 
> Anton
> 
> >-----Original Message-----
> >
> >
> >From: linux-kernel-owner@vger.kernel.org
> >[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Ville Herva
> >Sent: Saturday, April 27, 2002 7:56 AM
> >To: Martin Bene; linux-kernel@vger.kernel.org
> >Subject: 48-bit IDE [Re: 160gb disk showing up as 137gb]
> >
> >
> >On Sat, Apr 27, 2002 at 12:16:06PM +0200, you [Martin Bene] wrote:
> > >
> > > IDE: The kernel IDE driver needs to support 48-bit addresseing to support
> > > 160GB.
> > >
> > > (...) however, you can do something about the linux ATA driver: code
> > > is in the 2.4.19-pre tree, it went in with 2.4.19-pre3.
> >
> >But which IDE controllers support 48-bit addressing? Not all of them? Does
> >linux IDE driver support 48-bit for all of them? Do they require BIOS
> >upgrade in order to operate 48-bit?
> >
> >Or can I just grab a 160GB Maxtor and 2.4.19-preX, stick them into whatever
> >box I have and be done with it?
> >
> >
> >
> >-
> >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/
> 
> -- 
>    "I've not lost my mind. It's backed up on tape somewhere." - Unknown
> -- 
> Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
> Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
> WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
> 
> -
> 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/

-- 
Vojtech Pavlik
SuSE Labs

RE: 48-bit IDE [Re: 160gb disk showing up as 137gb]

[Daniela Engert]

On Sat, 27 Apr 2002 16:02:54 +0100, Anton Altaparmakov wrote:

>>You need an IDE controller that supports ATA133.  For most existing
>>computers, that is going to require a new card.
>
>Rubbish! The drives are backwards compatible with all ATA standards (do a 
>hparm -i on the drive and you will see). I certainly don't have an ATA133 
>controller and use one of the new Maxtor ATA133 drives just fine on it.

True.

>For LBA48 support I am not too sure whether you need a special controller 
>(for what it's worth I use a Promise ATA100 controller and it works fine on 
>my Maxtor 120G, LBA48, ATA133 disk but the disk is possibly not big enough 
>for any problems to manifest).

Nobody should take for granted, that LBA48 mode works flawlessly on any
IDE controller chip. In fact it doesn't! While you may safely assume
that LBA48 addressing is fine with PIO mode transfers, there are
controller chips out which simply fail with LBA48 in DMA mode (like
almost all ALi chips) or need "special treatment" (like Promise Ultra66
or pre-TX2 Ultra100 ) - there are probably more.

[BTW: the Linux driver's Promise LBA48 workaround will fail in
non-Ultra DMA mode because it is hard-wired for Ultra DMA only].

>Perhaps Andre (cc-ed) could shed some light on this?

Let's address a larger audience :-)

I've added an additional column to my "IDE drivers capabilities,
features and bug list" which summarizes my tests with LBA48 DMA modes.
A "?" means "no test conducted" (usually because of lack of hardware),
a "x" means supported, a "-" means "unsupported". and a "x!" means
"supported, special treatment required".

If there are people with hardware which still has a "?" I'd like to
hear of their experiences.


>>-----Original Message-----
>>[mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Ville Herva
>>
>>But which IDE controllers support 48-bit addressing? Not all of them? Does
>>linux IDE driver support 48-bit for all of them? Do they require BIOS
>>upgrade in order to operate 48-bit?

AFAIK the BIOS is out of the picture. Most OS son't rely on the BIOS
for regular operation.

>>Or can I just grab a 160GB Maxtor and 2.4.19-preX, stick them into whatever
>>box I have and be done with it?

It *might* work, but your mileage will vary.

Ciao,
  Dani


 Vendor
 | Device
 | | Revision			      ATA  LBA48  ATAPI      
ATA66  ATA133
 | | | south/host bridge id	    PIO DMA DMA  PIO DMA  ATA33 |
ATA100|   Docs
 | | | | south/host bridge rev.    32bit |   |	32bit |    
|	|   |	|  avail
 | | | | |			     |	 |   |	  |   |  
  |	|   |	|    |
 v v v v v			     v	 v   v	  v   v  
  v	v   v	v    v

 0x8086 Intel
   0x1230 PIIX			     x	 x   ?	  x  
x     -	-   -	-    x
     < 02			     x	 -   -	  x   -   
 -	-   -	-    x
       0x84C4 Orion
	 < 04			     x	 -   -	  x  
-     -	-   -	-    x
   0x7010 PIIX3 		     x	 x   x	  x   x    
-	-   -	-    x
   0x7111 PIIX4 		     x	 x   x	  x   x    
x	-   -	-    x
   0x7199 PIIX4 MX		     x	 x   x	  x   x  
  x	-   -	-   (x)
   0x2411 ICH			     x	 x   x	  x  
x     x	x   -	-    x
   0x7601 ICH			     x	 x   x	  x  
x     x	x   -	-   (x)
   0x2421 ICH0			     x	 x   x	  x  
x     x	-   -	-    x
   0x244B ICH2			     x	 x   x	  x  
x     x	x   x  (x)   x
   0x244A ICH2 mobile		     x	 x   x	  x  
x     x	x   x  (x)   x
   0x245B C-ICH 		     x	 x   x	  x   x    
x	x   x  (x)   x
   0x248B ICH3			     x	 x   x	  x  
x     x	x   x  (x)   x
   0x248A ICH3 mobile		     x	 x   x	  x  
x     x	x   x  (x)   x

 known bugs and features:
   - PIIX3: some chips 'forget' to assert the IRQ sometimes. These
chips are not
	    detectable in advance.
   - ICH2+: despite the docs, the ATA/100 capable chips also can do
ATA/133

------------------------------------------------------------------------
--------
 0x1106 VIA
   0x1571 571			     x	 x   ?	  x  
x     -	-   -	-    -
   0x0571 571
       0x0586
	 < 0x20  586		     x	 x   ?	  x   x
    -	-   -	-    x
	 >=0x20  586A/B 	     x	 x   x	  x   x    
x	-   -	-    x
       0x0596
	 < 0x10  596/A		     x	 x   x	  x  
x     x	-   -	-    x
	 >=0x10  596B		     x	 x   x	  x  
x     x	x   -	-    x
       0x0686
	 < 0x10  686		     x	 x   x	  x   x
    x	-   -	-    -
	 < 0x40  686A		     x	 x   x	  x  
x     x	x   -	-    x
	 >=0x40  686B		     x	 x   x	  x  
x     x	x   x	-    x
       0x8231	 VT8231 	     x	 x   x	  x  
x     x	x   x	-    -
       0x3074	 VT8233 	     x	 x   x	  x  
x     x	x   x	-    x
       0x3109	 VT8233c	     x	 x   x	  x  
x     x	x   x	-    -
       0x3147	 VT8233a	     x	 x   x	  x  
x     x	x   x	x    -

 known bugs:
   - all:  no host side cable type detection.
   - all:  the busmaster 'active' bit doesn't match the actual
busmaster state.
   - 596B: don't touch the busmaster registers too early after
interrupt
	   don't touch taskfile registers before stopping the
busmaster!
   - 686 rev 40/41 and VT8231 rev 10/11 have the PCI corruption
bug!

------------------------------------------------------------------------
--------
 0x10B9 ALi
   0x5229 M5229
     < 0x20			     x	 x   -	  x   - 
   -	-   -	-   (x)
     < 0xC1	 1533, 1543E/F	     x	 x   -	 
x   -     x	-   -	-   (x)
     < 0xC2	 1543C		     x	 x   -	 
x   xR    x	-   -	-   (x)
	 0xC3/
	 0x12	 1543C-E	     x	 x   -	  x  
xR   (x)	-   -	-   (x)
     < 0xC4	 1535, 1553,	     x	 x   -	  x 
 x     x	x   -	-    x
		 1543C-B, 1535D
     ==0xC4	 1535D+ 	     x	 x   -	  x   x 
   x	x   x	-    x
     > 0xC4	 1535D+ 	     x	 x   x	  x   x 
   x	x   x	x    -

 known bugs:
   - 1535 and better: varying methods of host side cable type
detection.
   - up to 1543C: busmaster engine 'active' status bit is nonfunctional
		  in UltraDMA modes.
   - up to 1543C: can't do ATAPI DMA writes.
   - 1543C-E:	  UltraDMA CRC checker fails with older WDC disks.
   - 1543C-Bx:	  must stop busmaster reads with 0x00 instead of
0x08.

------------------------------------------------------------------------
--------
 0x1039 SiS
   0x5513 5513
     < 0xD0			     x	 x   ?	  x   x 
   -	-   -	-    x
     >=0xD0			     x	 x   ?	  x   x 
   x	-   -	-    x
       >= 0x0530		     x	 x   ?	  x   x    
x	x   -	-   (x)
       >  0x0630		     x	 x   ?	  x   x    
x	x   x	-   (x)
       6/746 6/751		     x	 x   ?	  x   x  
  x	x   x	x    -

   - older SiS: don't touch the busmaster registers too early after
interrupt

------------------------------------------------------------------------
--------
 0x1095 CMD/Silicon Image
   0x0640 CMD 640		     -	 -   -	  -   -   
 -	-   -	-    x
     00   refuse!
   0x0643 CMD 643
     < 03			     x	 x   ?	  x   x   
 -	-   -	-    x
     >=03			     x	 x   ?	  x   x   
 x	-   -	-    x
   0x0646 CMD 646
     < 03			     x	 x   ?	  x   x   
 -	-   -	-    x
     >=03			     x	 x   ?	  x   x   
 x	-   -	-    x
   0x0648 CMD 648		     x	 x   ?	  x   x   
 x	x   -	-    x
   0x0649 CMD 649		     x	 x   x	  x   x   
 x	x   x	-   (x)
   0x0680 SiI 680		     x	 x   x	  x   x   
 x	x   x	x    x

 known bugs:
   - 640: the enable bit of the secondary channel is erratic. You need
to check
	  both settings '0' and '1' for a populated channel.
   - 640: revision 0 doesn't work reliably.
   - up to 646: both channels share internal resources. Serialization
is
	 
required.

------------------------------------------------------------------------
--------
 0x105A Promise
   0x4D33 PDC20246   Ultra33	     x	 x   ?	  -   -
    x	-   -	-    x
   0x4D38 PDC20262   Ultra66	     x	 x   x!   -  (x)   
x	x   -	-    x
   0x0D38 PDC20263   Ultra66	     x	 x   x!   -  (x)   
x	x   -	-   (x)
   0x0D30 PDC20265   Ultra100	     x	 x   x!   -  (x)   
x	x   x	-    x
   0x4D30 PDC20267   Ultra100	     x	 x   x!   -  (x)   
x	x   x	-    x
   0x4D68 PDC20268   Ultra100 TX2    x	 x   x	  x   x    
x	x   x	-   (x)
   0x6268 PDC20270   Ultra100 TX2    x	 x   x	  x   x    
x	x   x	-   (x)
   0x4D69 PDC20269   Ultra133 TX2    x	 x   x	  x   x    
x	x   x	x    x
   0x6269 PDC20271   Ultra133 TX2    x	 x   x	  x   x    
x	x   x	x   (x)
   0x1275 PDC20275   Ultra133 TX2    x	 x   x	  x   x    
x	x   x	x   (x)
   0x5275 PDC20276   Ultra133 TX2    x	 x   x	  x   x    
x	x   x	x    x
   0x7275 PDC20277   Ultra133 TX2    x	 x   x	  x   x    
x	x   x	x   (x)

 known bugs:
   - up to Ultra100: don't issue superfluous PIO transfer mode setups.
   - up to Ultra100: if any device is initialized to UltraDMA, you need
to
	  reset the channel if you want to select MultiWord DMA
instead.
   - Ultra66/100: a LBA48 DMA mode transfer needs an extra "kick".
   - Ultra66/100: ATAPI DMA should work according to Windows drivers,
but the
	  register model is very
"strange".

------------------------------------------------------------------------
--------
 0x1078 Cyrix
   0x0102 CX5530		     x	 x   ?	  x   x    
x	-   -	-    x

 known bugs:
   - all: busmaster transfers need to be 16 byte aligned instead of
word
	  aligned.
   - all: a DMA block of 64KiB comes out as 0 bytes in the DMA
engine

------------------------------------------------------------------------
--------
 0x1103 HighPoint
   0x0004 HPT 36x/37x
     <=01 HPT 366		     x	 x   x	  x   x   
 x	x   -	-    x
       02 HPT 368		     x	 x   x	  x   x   
 x	x   -	-    -
       03 HPT 370		     x	 x   x	  x   x   
 x	x   x	-    x
       04 HPT 370A		     x	 x   x	  x   x  
  x	x   x	-   (x)
       05 HPT 372		     x	 x   x	  x   x   
 x	x   x	x    x
   0x0005 HPT 372		     x	 x   x	  x   x   
 x	x   x	x   (x)
   0x0008 HPT 36x/37x dual
       07 HPT 374		     x	 x   x	  x   x   
 x	x   x	x    x

 known bugs:
   - HPT366: random failures with several disks.
   - HPT366: random PCI bus lockups in case of too long bursts.
   - HPT366: IBM DTLA series drives must be set to Ultra DMA mode 5
(!!) to work
	     reliably at Ultra DMA mode 4
speed.

------------------------------------------------------------------------
--------
 0x1022 AMD
   0x7401 AMD 751		     x	 x   ?	  x   x   
 x	-   -	-    -
   0x7409 AMD 756		     x	 x   ?	  x   x   
 x	x   -	-    x
   0x7411 AMD 766  MP		     x	 x   ?	  x  
x     x	x   x	-    x
   0x7441 AMD 768  MPX		     x	 x   ?	  x  
x     x	x   x	-    x
   0x7469 AMD 8111		     x	 x   ?	  x   x  
  x	x   x	-    -

 known bugs:
   - 756: no host side cable type detection.
   - 756: SingleWord DMA doesn't work on early chip revisions.
   - 766: read/write prefetches must be disabled to defeat infinite
	  PCI bus
retries.

------------------------------------------------------------------------
--------
 0x1191 AEC/Artop
   0x0005 AEC 6210		     x	 x   ?	  ?   ?  
  x	-   -	-    -
   0x0006 AEC 6260		     x	 x   ?	  ?   ?  
  x	x   -	-    -
   0x0007 AEC 6260		     x	 x   ?	  ?   ?  
  x	x   -	-    -
   0x0009 AEC 6280/6880 	     x	 x   ?	  ?   ?    
x	x   x	x    -

 known bugs:
   - 6210 (possibly 6260): task file registers are inaccessible until
busmaster
		 engine is stopped.
   - possibly all: both channels share internal resources.
Serialization is
		
required.

------------------------------------------------------------------------
--------
 0x1055 SMSC
   0x9130 SLC90E66		     ?	 x   ?	  ?   ?  
  x	x   -	-   
x

------------------------------------------------------------------------
--------
 0x1166 ServerWorks
   0x0211 OSB4			     x	 x   ?	  ?  
?     x	-   -	-    x
   0x0212 CSB5
     < 0x92			     x	 x   ?	  ?   ? 
   x	x   -	-    -
    >= 0x92			     x	 x   ?	  ?   ? 
   x	x   x	-    -
   0x0213 CSB6
     < 0xA0			     x	 x   ?	  ?   ? 
   x	3   -	-    -
    >= 0xA0			     x	 x   ?	  ?   ? 
   x	x   x	-    -

 known bugs:
   - OSB4: at least some chip revisions can't do Ultra DMA mode 1 and
above
   - OSB4: some chip revisions may get stuck in the DMA engine in Ultra
DMA
	   with some disks
   - CSB5: no host side cable type detection (vendor specific).
   - CSB6: no host side cable type detection (vendor
specific).

------------------------------------------------------------------------
--------
 0x1045 Opti
   0xC621     n/a		     x	 -   -	  -   -   
 -	-   -	-    x
   0xC558     Viper		     x	 x   ?	  ?   ? 
   -	-   -	-    x
   0xD568			     x	 x   ?	  ?   ?   
 -	-   -	-    x
     < 0xC700 Viper		     x	 x   ?	  ?   ? 
   -	-   -	-    x
     >=0xC700 FireStar/Vendetta?     x	 x   ?	  x   x    
x	-   -	-    x
   0xD721     Vendetta? 	     x	 x   ?	  x   x    
x	-   -	-    x
   0xD768     Vendetta		     x	 x   ?	  x  
x     x	-   -	-    x

 known bugs:
   - C621: both channels share internal resources. Serialization is
required.
   - FireStar: Ultra DMA works reliably only at mode 0.
	       Update: not even that! Better do MWDMA2 at
most.

------------------------------------------------------------------------
--------
 0x10DE Nvidia
   0x01BC     nForce		     x	 x   ?	  x   x
    x	x   x	-    -

 known bugs:
   - nForce: no host side cable type
detection.

------------------------------------------------------------------------
--------
 0x100B National Semiconductor
   0x0502 SCx200		     x	 x   ?	  x   x    
x	-   -	-    -

 known bugs:
   - all: busmaster transfers need to be 16 byte aligned instead of
word
	  aligned.

RE: 48-bit IDE [Re: 160gb disk showing up as 137gb]

[Andre Hedrick]

No, you need a host that is capable of 48-bit command set operations.
Only a few hosts fail to support the double pump of the taskfile
registers, and it requires a control register for high ordered bit
operations.

cheers,


Andre Hedrick
LAD Storage Consulting Group

On Sat, 27 Apr 2002, Kevin Krieser wrote:

> You need an IDE controller that supports ATA133.  For most existing
> computers, that is going to require a new card.-----Original Message-----
> 
> 
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Ville Herva
> Sent: Saturday, April 27, 2002 7:56 AM
> To: Martin Bene; linux-kernel@vger.kernel.org
> Subject: 48-bit IDE [Re: 160gb disk showing up as 137gb]
> 
> 
> On Sat, Apr 27, 2002 at 12:16:06PM +0200, you [Martin Bene] wrote:
> >
> > IDE: The kernel IDE driver needs to support 48-bit addresseing to support
> > 160GB.
> >
> > (...) however, you can do something about the linux ATA driver: code
> > is in the 2.4.19-pre tree, it went in with 2.4.19-pre3.
> 
> But which IDE controllers support 48-bit addressing? Not all of them? Does
> linux IDE driver support 48-bit for all of them? Do they require BIOS
> upgrade in order to operate 48-bit?
> 
> Or can I just grab a 160GB Maxtor and 2.4.19-preX, stick them into whatever
> box I have and be done with it?
> 
> 
> 
> -
> 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: 48-bit IDE [Re: 160gb disk showing up as 137gb]

[Andre Hedrick]

On Sat, 27 Apr 2002, Vojtech Pavlik wrote:

> On Sat, Apr 27, 2002 at 03:55:51PM +0300, Ville Herva wrote:
> > On Sat, Apr 27, 2002 at 12:16:06PM +0200, you [Martin Bene] wrote:
> > > 
> > > IDE: The kernel IDE driver needs to support 48-bit addresseing to support
> > > 160GB.
> > > 
> > > (...) however, you can do something about the linux ATA driver: code
> > > is in the 2.4.19-pre tree, it went in with 2.4.19-pre3.
> > 
> > But which IDE controllers support 48-bit addressing? Not all of them?
> 
> ALL IDE controllers support 48-bit addressing. Actually, they don't need
> to know about it.

Sorry this is not correct, I have a list that fail.
However I need to compose a test to revoke their 48-bit operations
regardless if the device supports.

> > Does
> > linux IDE driver support 48-bit for all of them?
> 
> Yes, since 2.4.19-pre3 as far as I know.
> 
> > Do they require BIOS
> > upgrade in order to operate 48-bit?
> 
> Only if you need to boot from the drive and then you still can boot from
> the first 140 megs or so.
> 
> > Or can I just grab a 160GB Maxtor and 2.4.19-preX, stick them into whatever
> > box I have and be done with it?
> 
> That's it, yes.
> 
> -- 
> Vojtech Pavlik
> SuSE Labs
> -
> 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/
> 

Andre Hedrick
LAD Storage Consulting Group

RE: 48-bit IDE [Re: 160gb disk showing up as 137gb]

[Kevin Krieser]

Unfortunately, I was recalling some article I read last year that said you
needed upgraded firmware (such as upgraded motherboard or new PCI card) to
get > 137GB support.  I should have verified that my information was still
correct.

And here I made sure the motherboard I bought this month had 133 support so
I could use future large hard drives on it :)  At least I finally have
support for my ATA100 drives at something faster than ATA33.

-----Original Message-----
From: Martin Bene [mailto:martin.bene@icomedias.com]
Sent: Saturday, April 27, 2002 10:34 AM
To: Kevin Krieser; linux-kernel@vger.kernel.org
Subject: AW: 48-bit IDE [Re: 160gb disk showing up as 137gb]


Hi Kevin,

> You need an IDE controller that supports ATA133.  For most existing
> computers, that is going to require a new card.

That actually turns out not to be the case.

While you do need a new controller if you want to use ATA133, the LBA48
addressing scheme in no way depends on ATA133. Running a 160GB disk on your
old ATA100 (or ATA66 or ATA33) controller works just fine.

Bye, Martin

-----Original  Message-----
>
>
> From: linux-kernel-owner@vger.kernel.org
> [mailto:linux-kernel-owner@vger.kernel.org]On Behalf Of Ville Herva
> Sent: Saturday, April 27, 2002 7:56 AM
> To: Martin Bene; linux-kernel@vger.kernel.org
> Subject: 48-bit IDE [Re: 160gb disk showing up as 137gb]
>
>
> On Sat, Apr 27, 2002 at 12:16:06PM +0200, you [Martin Bene] wrote:
> >
> > IDE: The kernel IDE driver needs to support 48-bit
> addresseing to support
> > 160GB.
> >
> > (...) however, you can do something about the linux ATA driver: code
> > is in the 2.4.19-pre tree, it went in with 2.4.19-pre3.
>
> But which IDE controllers support 48-bit addressing? Not all
> of them? Does
> linux IDE driver support 48-bit for all of them? Do they require BIOS
> upgrade in order to operate 48-bit?
>
> Or can I just grab a 160GB Maxtor and 2.4.19-preX, stick them
> into whatever
> box I have and be done with it?
>
>
>
> -
> 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: 48-bit IDE [Re: 160gb disk showing up as 137gb]

[Vojtech Pavlik]

On Sat, Apr 27, 2002 at 02:36:07PM -0700, Andre Hedrick wrote:

> On Sat, 27 Apr 2002, Vojtech Pavlik wrote:
> 
> > On Sat, Apr 27, 2002 at 03:55:51PM +0300, Ville Herva wrote:
> > > On Sat, Apr 27, 2002 at 12:16:06PM +0200, you [Martin Bene] wrote:
> > > > 
> > > > IDE: The kernel IDE driver needs to support 48-bit addresseing to support
> > > > 160GB.
> > > > 
> > > > (...) however, you can do something about the linux ATA driver: code
> > > > is in the 2.4.19-pre tree, it went in with 2.4.19-pre3.
> > > 
> > > But which IDE controllers support 48-bit addressing? Not all of them?
> > 
> > ALL IDE controllers support 48-bit addressing. Actually, they don't need
> > to know about it.
> 
> Sorry this is not correct, I have a list that fail.

Care to bless the mailing-list with the names of the chipsets that have
trouble?

> However I need to compose a test to revoke their 48-bit operations
> regardless if the device supports.

If you have a list, then the test is quite easy, ain't it?

-- 
Vojtech Pavlik
SuSE Labs

Re: 48-bit IDE [Re: 160gb disk showing up as 137gb]

[Rogier Wolff]

Anton Altaparmakov wrote:
> At 14:51 27/04/02, Kevin Krieser wrote:
> >You need an IDE controller that supports ATA133.  For most existing
> >computers, that is going to require a new card.
> 
> Rubbish! The drives are backwards compatible with all ATA standards (do a 
> hparm -i on the drive and you will see). I certainly don't have an ATA133 
> controller and use one of the new Maxtor ATA133 drives just fine on it.
> 
> For LBA48 support I am not too sure whether you need a special controller 
> (for what it's worth I use a Promise ATA100 controller and it works fine on 
> my Maxtor 120G, LBA48, ATA133 disk but the disk is possibly not big enough 
> for any problems to manifest).

For some reason, my 160G disks work on the "native" controllers, but
not on the promise cards that I bought for the purpose... After
figuring this out I haven't taken the time to find the root cause, as
I'm just a user in this respect...

			Roger. 


-- 
** 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: 48-bit IDE [Re: 160gb disk showing up as 137gb]

[Mike Dresser]

> For some reason, my 160G disks work on the "native" controllers, but
> not on the promise cards that I bought for the purpose... After
> figuring this out I haven't taken the time to find the root cause, as
> I'm just a user in this respect...
>
> 			Roger.

I seem to remember something about new Promise BIOS's that fix that
LBA48 issue.  Try updating the bios, and see what happens.

Looking at their bios page, I see the Ultra 100 TX2 supports LBA48, don't
see any info on the Ultra 100, Ultra 66, etc though.  I believe the 133
TX2 has it built in.

Hope this helps,

Mike

Re: 48-bit IDE [Re: 160gb disk showing up as 137gb]

[Mike Fedyk]

On Sat, Apr 27, 2002 at 05:50:43PM +0200, Daniela Engert wrote:
> I've added an additional column to my "IDE drivers capabilities,
> features and bug list" which summarizes my tests with LBA48 DMA modes.
> A "?" means "no test conducted" (usually because of lack of hardware),
> a "x" means supported, a "-" means "unsupported". and a "x!" means
> "supported, special treatment required".

Can you post this as an attachment, or is it on the web somewhere?