On Monday 15 January 2001 10:10, you wrote:
> On Sunday 14 January 2001 16:32, you wrote:
> > Addressed to Civileme:
> > Once I looked at what you posted in your article, re-read some of the
> > hdparm info page, and did some experimentation I became somewhat
> > confused.
> >
> > Here is the except out of the info page:
> >
> >
> > -i Display the identification info that was obtained
> > from the drive at boot time, if available. This is
> > a feature of modern IDE drives, and may not be sup
> > ported by older devices. The data returned may or
> > may not be current, depending on activity since
> > booting the system. However, the current multiple
> > sector mode count is always shown. For a more
> > detailed interpretation of the identification info,
> > refer to AT Attachment Interface for Disk Drives
> > (ANSI ASC X3T9.2 working draft, revision 4a, April
> > 19/93).
> >
> > Version 3.9 February 2000 2
> >
> > HDPARM(8) HDPARM(8)
> >
> > -I Request identification info directly from the
> > drive, which is displayed in its raw form with no
> > endian changes or corrections. Otherwise similar
> > to the -i option.
> >
> > When I ran through both options I got this:
> > [root@tick /root]# hdparm -i /dev/hdg
> >
> > /dev/hdg:
> >
> > Model=IBM-DTLA-307045, FwRev=TX6OA50C, SerialNo=YMDYMM67566
> > Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> > RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
> > BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=16
> > CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=90069840
> > 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 udma0 udma1 udma2 udma3 udma4 *udma5
> > [root@tick /root]# hdparm -I /dev/hdg
>
> That's a udma 100 setting
>
> > /dev/hdg:
> >
> > Model=TDAL3-7040 5 o?, FwRev=5AC0BI-M, SerialNo=
> > Y DMMY6M5766b
> > Config={ NotMFM Fixed Removeable DTR<=5Mbs DTR>5Mbs DTR>10Mbs dStbOff
> > TrkOff } RawCHS=16/0/0, TrkSize=63, SectSize=0, ECCbytes=13903
> > BuffType=40, BuffSize=10796kB, MaxMultSect=0
> > (maybe): CurCHS=63/64528/251, CurSects=1531969808, LBA=yes,
> > LBAsects=458752 IORDY=no
> > PIO modes: pio0
> > DMA modes:
> >
> > My understanding is that the -i option is showing what the kernel sees at
> > boot time when it auto configures the drive. When I have the auto
> > configure option set for /dev/hde and /dev/hdg, the system hangs on
> > /dev/hdg with a Promise Utra100 controller. Tracing this further, after
> > boot I typed in 'hdparm -u1 -c1 /dev/hde; hdparm -u1 -c1 -d1 /dev/hdg'.
> > This seemed to execute, but when I typed in 'hdparm -t /dev/hdg' the
> > system complained about a DMA time-out and hung. (Console did not
> > respond to anything.) When I hit the reset switch and brought the system
> > back up I did the following. At the prompt I typed in 'hdparm -u1 -c1
> > /dev/hde; hdparm -u1 -c1 -d1 -X69 /dev/hdg'. (Note the -X 69 option).
> > When I typed in 'hdparm -t /dev/hdg' I got:
> >
> > [root@tick /root]# hdparm -t /dev/hdg
> >
> > /dev/hdg:
> > Timing buffered disk reads: 64 MB in 1.79 seconds = 35.75 MB/sec
> >
> > Now if the highest defined rate so far in the IDE world is UDMA mode 5
> > and the kernel seems to detect that that is the highest mode available
> > and the controller supports UDMA mode 5, then how can your why be true?
> > ("Some Hard disk drives advertise to the software that they are capable
> > of higher data rates than they actually can do.")
>
I took another look at this and at the Promise site tech support and realized
I didn't answer your question.
First of all, a drive out of spec is only one of many reasons to use this
dodge. Another big one is the autotune process.
This is a buggy process. The bug is not hardware. The bug is not software.
The bug is secrecy. The linux community contributes software drivers openly,
but what Promise's engineers do is secret.
Autotune is not not not like hdparm -c1 -u1 -d1 -X69 /somedevice. It is more
like
hdparm -c3 -u3 -d3 -X(whatever the hardware answers for the 3s) /someidedevice
Well -c3 is defined for hdparm, but u3 and d3 are not. But if they were
offered they would have much the same definition.
Look carefully at Promise's site. You will find they offer different drivers
for many of their products based on whether you have one processor or smp.
Obviously they know a lot more about their hardware than we do.
And they aren't talking. Their engineers _could_ read our drivers and design
their hardware round them, but usually things work the other way--they do the
hardware then their software engineers adapt the drivers.... The linux
community has to reverse engineer much of that. So the devices work with
user tweaking instead of automatic tuning.
But it is also true and far more prevalent that the drive manufacturers are
releasing out of spec devices.
Civileme
