Re: Running HGST's DFT utility from a flash drive
On Thu, 22 Oct 2020 at 08:45, David <bouncingcats@gmail.com> wrote:
Hmmm again. Ignore my previous message. I didn't read the thread
carefully enough. I still haven't done that, because I should be
doing other things, but I have looked a little bit more carefully
so I have slightly better suggestions.
First,
https://www1.hgst.com/hdd/support/download.htm#DFT
says:
"""
Drive Fitness Test Version 4.16
The Drive Fitness Test (DFT) quickly and reliably tests SCSI, IDE and
SATA drives. [...] Supports Leading Drives
- SCSI.
- Serial ATA.
- Parallel ATA.
- IDE.
"""
So apparently it claims to work with all those interfaces. But
read the notes.
Next, check pages 5 and 6 and 31 of
https://www1.hgst.com/hdd/support/downloads/Dft32_User_Guide_415.pdf
in particular
"""
>From release 3.50, DFT supports Hitachi Serial-ATA drives when these
drives are attached to
- Motherboards and Plug-in PCI controllers, which utilises the Highpoint HPT374
and 372A (with Marvel bridge chip) chipsets, Silicon Image SIL3112A and 0680
chipset and Intel ICH5 chipset.
Configurations NOT supported:
- Drives attached using ATA RAID controllers where direct access to the attached
devices is blocked by the controller also not supported are Multi-Channel SCSI
RAID controllers.
- Serial-ATA controllers based on the Silicon Image Promise and Intel
chipsets are
not currently supported
"""
It seems to be a 2009 document, pretty ancient.
I downloaded the bootable image
https://www1.hgst.com/hdd/support/downloads/ftool_215_install.IMG
and looked inside it using:
sudo mount -r -t msdos -o loop dft32_v416_b00_install.IMG /mnt/junk
The CONFIG.SYS file in the image shows what drivers are expected
to be loaded. A lot of what is in there is standard guff (ramdrive, upper
memory use, that may well be unnecessary) and causing the error
messages you reported earlier. It could be greatly simplified.
It looks like no additional drivers are loaded for ATA drives.
The AUTOEXEC.BAT file in the image contains the essential
PATH=A:\DOS;A:\DFT;A:\;
cd DFT
LOADDFT.EXE DFT-V300.EXE DFT.EXE /PSR >NUL
The final line is the most important.
That shows the correct use of the LOADDFT.EXE and
DFT-V300.EXE files, and invalidates my previous advice.
The >NUL might be hiding diagnostic messages.
And I wonder if /PSR is anything like "terminate and stay resident"
so I would be wary of expecting sensible results if running that
line more than one time.
What I would do is rename AUTOEXEC.BAT in the image, to disable
it, and I would run the above commands manually at the DOS prompt.
And I would run them without the >NUL and perhaps also without the /PSR
Reply to: