Jon said:
I have a workstation I built with Windows XP Pro
running on it. Every time I reboot, before rebooting
everything is a-ok, but after rebooting it starts up
with the hard drive corrupted. I have to make
sometimes as many as four passes of bootup disk
check (a reboot each time) before I can get it to
boot successfully without errors. Repeat at next
manual reboot... !
What is the cause of this? I've checked the voltage
going to the power supply, it's 117 volts, which is fine.
I have not yet checked the voltage going into the hard
drive from the power supply, but I don't know how to
do that.
Anything else I can do? I am stumped!
Jon
The following is a copy of a post I made to the:
microsoft.windows.xp.general
newsgroup with the Title:
Re: xp is *NOT* flushing disk cache before shutdown
--------------------------------begin repost text--------------------------
The following are the results of my latest investigations
regarding the HPT366 Controller Chip problems with both W2K
and WXP -- where the OS is unable to flush the hard disk cache
before shutdown.
This text is taken from an email I sent to Highpoint in regards to
this issue:
----------------------------------begin email text--------------------------
I have three different clients using the Abit BE6-2 motherboard.
In each case, when I have upgraded the user to Windows 2000
or Windows XP, the system has become unstable on shutdown.
I have upgraded each machine to the latest version of the Abit
Motherboard BIOS available for this motherboard. I have also
manually added the latest Version 1.28b BIOS insert in place of
the 1.25 insert found in the latest version of the Abit BIOS.
The 1.28b BIOS solves the problem of an invalid disk size display
for drives larger than 64GB. (I am using 80GB or 120GB drives
in the three machines under test).
However, the disk-controller driver used under both Windows 2000
and Windows XP is Version 1.25.1. As far as I am aware, this is
the latest driver available. I am using the 1.25.1 drivers, as the info
in the 1.25.1 archive has later filedates and newer info than the files
in the 1.28b driver archive.
The 1.25.1 driver -- as well as the various beta drivers -- are unable
to communicate between Windows 2000 or Windows XP and the
hardware cache on the Hard Disk. As a result, at Windows shutdown
the machine shuts off while there is still info in the drive's hard disk
cache. This leads to Windows 2000 or Windows XP's scandisk
running on the first restart after shutdown. Scandisk then identifies
lost clusters on the hard disk which were not properly flushed from
the hardware disk cache to the hard disk platters before the
preceding shutdown.
I have confirmed the problem occurs due to a communication error
in the driver. The Windows 2000/XP dskcache tool identifies the
problem as follows:
Error getting Write Cache value.
(1117) The request could not be performed because of an
I/O device error.
According to the Microsoft Knowledge Base Article 811392, the
above error occurs because of a flaw in the hard disk controller
driver -- which does not properly pass cache-control and status
info between the OS and the Hard Disk.
The Microsoft Information for the above error is as follows:
This error message indicates that the disk device does not
return information about its write caching status in response
to the appropriate SCSI or ATAPI command. This error
message is simply an indication of the capabilities (or lack
thereof) of the device or its driver, and it typically implies
that either the device does not support write caching or that
the device driver does not support the commands that are
required to query and set the device's write cache setting.
To resolve this issue, contact the vendor of the disk device.
For further info on the disk tool and the results from queries
and commands to the Hard Disk through the dskcache tool,
please see the following Microsoft Knowledge Base article:
http://support.microsoft.com/default.aspx?scid=kb;en-us;811392
The four different Hard Disk drives I have tried are:
a) Maxtor 6Y080L0 - 80GB, 7200RPM,
2MB onboard hardware disk cache,
firmware version YAR41BW0
b) Seagate Barracuda 7200.7 - ST380011A - 80GB, 7200RPM,
2MB onboard hardware disk
cache, firmware version 3.06
c) Seagate Barracuda 7200.7 - ST312022A - 120GB, 7200RPM,
2MB onboard hardware disk
cache, firmware version 3.06
d: Samsung SpinPoint P80 Series - SP8004H - 80GB, 7200RPM,
2MB onboard hardware
disk cache, firmware
version TK10
I observed the following deficiencies:
a) Both Seagate drives stalled during write operations when
moving large files or large numbers of small files under
Windows XP. In some cases, Windows XP recovered after
about 5 seconds and continued operation. In other cases,
Windows XP stalled completely and required a hardware
power-off-reset to regain control of the OS.
Upon restart after a complete stall, Windows ran chkdsk on
startup and found a large number of lost clusters.
b) The Maxtor hard disk was able to reliably complete disk
write operations when moving large files or large numbers
of small files under both Windows XP and Windows 2000.
However, the Maxtor hard disk would intermittently fail to
write all its files to disk before shutdown, leading Windows
2000 or Windows XP to run chkdsk on startup and find
small numbers of lost clusters.
The disk-cache-commit failures would cause the OS to
gradually degrade, as in some cases the info in-cache at
shutdown was Registry updates made as a result of the
installation of software patches from Windows Update.
In some cases, this would result in substantial damage
to Windows 2000 or Windows XP which required full OS
reinstallation to resolve.
c) The Samsung disk drive was the most reliable of the
three brands tested. This drive was able to reliably
complete disk write operations when moving large
files or large numbers of small files under Windows
XP. However, the disk-cache-commit failure would
occasionally leave the Windows XP disk-dirty-flag
set on shutdown, leading Windows XP to run chkdsk
on the next startup. Chkdsk would run, find no errors
and Windows XP would then start up normally.
d) With both the Maxtor and Samsung drives, instructing
Windows 2000 or Windows XP to perform a restart
rather than a shutdown -- and then manually shutting
down the machine using the power button at the BIOS
startup screen -- allowed the Hard Disk to reliably
flush its cache buffers. Windows started normally
on any subsequent restart if this procedure was
performed -- which confirms the need for functional
cache-control so Windows 2000 or Windows XP can
shut down safely.
For now, I am running the Samsung disk drive in one of
the affected machines, as this client is a Doctor who
requires a working machine. The other two machines
are awaiting further developments. Please advise if disk
drivers capable of working reliably with Windows XP
and/or Windows 2000 will be made available for the
HPT366 Controller Chip.
----------------------------------end email text--------------------
Highpoint Technologies sent me a return email where they
told me they will not be supplying any updated drivers for
Windows 2000 or Windows XP for this controller chip.
The above leaves users with these chips as "orphans".
There is nothing particularly wrong with the hardware,
all that is required is a rewrite of the driver to properly
communicate the cache-flush and status commands
between the OS and the Hard Disk firmware.
If you could forward this info into the appropriate hands
for the Microsoft Driver Development team -- they may
be able to either make the necessary changes and add
an updated driver to XP SP-2 -- or they could talk to
Highpoint in regards to getting this problem fixed.
--------------------------------end repost text-----------------------
The problem described above is not limited to the
disks/drivers/hardware noted above.
Another test which verifies whether you have a cache-flush
flaw in the hardware/software interfacing is to do a restart
and then shut down the machine once it has rebooted and
has begun to restart, but the system is still in the BIOS
screen.
The above will allow sufficient time for the Hard Disk to
flush its cache buffers -- regardless of whether Windows
is properly managing the hard disk cache buffers or not.
If the above workaround solves your problem, you have
probably confirmed another instance of the bug I describe
above. This can be further confirmed by using the utility
I describe and seeing if you get the status message that
indicates the drive's caching-state is not being properly
controlled by Windows.
If you do confirm the problem, please report it back to the
newsgroup and to MS Product Support, as the more
people we have reporting the problem the higher the
probability that MS will include a proper fix for this in the
WXP SP2 update.
Best I can do for now. <tm>
Bill
