[gentoo-user] hdparm -d 1 -X 68 ?

[gentoo-user] hdparm -d 1 -X 68 ?

[James]

Hello,


hdparm -i /dev/hda 

Model=IBM-DJNA-371350, FwRev=J76OA30K, SerialNo=GM0GMGB6505
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=34
 BuffType=DualPortCache, BuffSize=1966kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=26520480
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 *udma2 udma3 udma4
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: ATA/ATAPI-4 T13 1153D revision 17:  ATA/ATAPI-1,2,3,4

 * signifies the current active mode


Should I put the drive into udma4 mode?

If so, wouldn't I use:

hdparm -d 1 -X 68  /dev/hda


???


James

Re: [gentoo-user] hdparm -d 1 -X 68 ?

[Volker Armin Hemmann]

On Donnerstag 18 Februar 2010, James wrote:
> Hello,
> 
> 
> hdparm -i /dev/hda
> 
> Model=IBM-DJNA-371350, FwRev=J76OA30K, SerialNo=GM0GMGB6505
>  Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
>  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=34
>  BuffType=DualPortCache, BuffSize=1966kB, MaxMultSect=16, MultSect=16
>  CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=26520480
>  IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
>  PIO modes:  pio0 pio1 pio2 pio3 pio4
>  DMA modes:  mdma0 mdma1 mdma2
>  UDMA modes: udma0 udma1 *udma2 udma3 udma4
>  AdvancedPM=no WriteCache=enabled
>  Drive conforms to: ATA/ATAPI-4 T13 1153D revision 17:  ATA/ATAPI-1,2,3,4
> 
>  * signifies the current active mode
> 
> 
> Should I put the drive into udma4 mode?
> 
> If so, wouldn't I use:
> 
> hdparm -d 1 -X 68  /dev/hda
> 
> 
> ???
> 
> 
> James

no

usually the kernel chooses the right mode. If this one is lower than expected, 
you shouldn't mess with it. Either grep for your drive or controller in the 
kernel sources - it might be blacklisted - or get a different cable.

Never set udma modes.

Re: [gentoo-user] hdparm -d 1 -X 68 ?

[Jesús Guerrero]

On Thu, 18 Feb 2010 14:33:38 +0000 (UTC)
James <wireless@tampabay.rr.com> wrote:
...
>  UDMA modes: udma0 udma1 *udma2 udma3 udma4
...
> Should I put the drive into udma4 mode?
> 
> If so, wouldn't I use:
> 
> hdparm -d 1 -X 68  /dev/hda

Sincerely, I haven't seen the need of manually tuning this with hdparm
for ages. The kernel is pretty good these days at that, and the drive
is probably already working at its max speed.

Looking at the specs and age of that model, there's nothing else you
can get from this drive.




-- 
Jesús Guerrero <i92guboj@terra.es>

[gentoo-user] Re: hdparm -d 1 -X 68 ?

[James]

Jesús Guerrero <i92guboj <at> terra.es> writes:


> Looking at the specs and age of that model, there's nothing else you
> can get from this drive.


OK thanks to all that answered.

I' just going to leave it alone.



James

Re: [gentoo-user] hdparm -d 1 -X 68 ?

[Mick]

[-- Attachment #1: Type: Text/Plain, Size: 1170 bytes --]

On Thursday 18 February 2010 14:33:38 James wrote:
> Hello,
> 
> 
> hdparm -i /dev/hda
> 
> Model=IBM-DJNA-371350, FwRev=J76OA30K, SerialNo=GM0GMGB6505
>  Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
>  RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=34
>  BuffType=DualPortCache, BuffSize=1966kB, MaxMultSect=16, MultSect=16
>  CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=26520480
>  IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
>  PIO modes:  pio0 pio1 pio2 pio3 pio4
>  DMA modes:  mdma0 mdma1 mdma2
>  UDMA modes: udma0 udma1 *udma2 udma3 udma4
>  AdvancedPM=no WriteCache=enabled
>  Drive conforms to: ATA/ATAPI-4 T13 1153D revision 17:  ATA/ATAPI-1,2,3,4
> 
>  * signifies the current active mode
> 
> 
> Should I put the drive into udma4 mode?
> 
> If so, wouldn't I use:
> 
> hdparm -d 1 -X 68  /dev/hda


According to the hitachi manual (who made this drive for IBM) the DJNA-3XXXXX 
series has a Ultra ATA Mode 2 (33.3 MB per second) capability.  So the kernel 
is not lying in this case and you can trust hdparm in what it shows.  I 
suggest you leave alone.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-user] Re: hdparm -d 1 -X 68 ?

[walt]

On 02/18/2010 01:57 PM, Mick wrote:
> On Thursday 18 February 2010 14:33:38 James wrote:

>> Should I put the drive into udma4 mode?
>>
>> If so, wouldn't I use:
>>
>> hdparm -d 1 -X 68  /dev/hda
>
>
> According to the hitachi manual (who made this drive for IBM) the DJNA-3XXXXX
> series has a Ultra ATA Mode 2 (33.3 MB per second) capability.  So the kernel
> is not lying in this case and you can trust hdparm in what it shows.  I
> suggest you leave alone.

Shouldn't the drive just refuse any command that it can't do?

Re: [gentoo-user] Re: hdparm -d 1 -X 68 ?

[Volker Armin Hemmann]

On Donnerstag 18 Februar 2010, walt wrote:
> On 02/18/2010 01:57 PM, Mick wrote:
> > On Thursday 18 February 2010 14:33:38 James wrote:
> >> Should I put the drive into udma4 mode?
> >> 
> >> If so, wouldn't I use:
> >> 
> >> hdparm -d 1 -X 68  /dev/hda
> > 
> > According to the hitachi manual (who made this drive for IBM) the
> > DJNA-3XXXXX series has a Ultra ATA Mode 2 (33.3 MB per second)
> > capability.  So the kernel is not lying in this case and you can trust
> > hdparm in what it shows.  I suggest you leave alone.
> 
> Shouldn't the drive just refuse any command that it can't do?

udma4 has not additional commands. It is just faster. And no, some drivers 
don't. With desastrous results.

Don't set the udma mode.

Ever.

Re: [gentoo-user] Re: hdparm -d 1 -X 68 ?

[Dale]

chrome://messenger/locale/messengercompose/composeMsgs.properties:
> On 02/18/2010 01:57 PM, Mick wrote:
>> On Thursday 18 February 2010 14:33:38 James wrote:
>
>>> Should I put the drive into udma4 mode?
>>>
>>> If so, wouldn't I use:
>>>
>>> hdparm -d 1 -X 68  /dev/hda
>>
>>
>> According to the hitachi manual (who made this drive for IBM) the 
>> DJNA-3XXXXX
>> series has a Ultra ATA Mode 2 (33.3 MB per second) capability.  So 
>> the kernel
>> is not lying in this case and you can trust hdparm in what it shows.  I
>> suggest you leave alone.
>
> Shouldn't the drive just refuse any command that it can't do?
>

I would think it would but since the drive can't run at that setting, 
why do it?  The drive can't most likely from hardware so why take the 
chance of messing something up?

Dale

:-)  :-)