AHCI and IDE - A problem?

R

Robin Bignall

When I installed Win7 I had trouble loading drivers and ended up using
IDE on SATA HDDs. Later, I saw how I could change to AHCI.

A while ago I applied the registry fixes for Win7 Ult to support AHCI. I
had already loaded my motherboard's AHCI drivers. It apparently worked,
but I didn't see any major change in performance. I went back to IDE
for some reason that I can't remember. (Probably because I lost SMART -
see below.) I now find TRIM for my SSD will only be enabled if I use
AHCI, so I changed back again. *Or maybe I didn't*: I can't tell,
because going from AHCI to IDE back to AHCI in BIOS did not appear to
load any drivers each double reboot.

Looking at Device Manager "Disk Drives", my SATA SSD and 2 SATA HDDS are
described in properties as "ATA.... SCSI Disk device".

In "IDE ATA/ATAPI Controllers" I have 3 entries for" ATA Channel 0", 3
entries for "ATA Channel 1" and 3 entries for "Standard ACHI 1.0 SATA
Controller".

In "Storage Controllers" I have an entry "Intel C600 Series Chipset SATA
AHCI Controller" and one for "Microsoft iSCSI Initiator"

I have a feeling that this is screwed up somehow. It appears as though
the IDE and AHCI drivers are both loaded, and one can skip between them
just by changing BIOS? Doesn't sound right.

What I do know was that under IDE my HDDs were enabled for SMART and
various programs I have (Perfect Disk, Speedfan) could report it.

With this latest apparent move to AHCI, SMART has gone. The disks and
SSD are reported either as non-SMART devices or SMART is disabled.

How do I clear this mess up? Delete all the drivers for HDDs and
controllers, or what? For AHCI, which drivers should I have installed?
It's driving me nuts to figure out what's happened. (Incidentally,
device manager is clean.)
 
B

BillW50

In Robin Bignall typed:
When I installed Win7 I had trouble loading drivers and ended up using
IDE on SATA HDDs. Later, I saw how I could change to AHCI.

A while ago I applied the registry fixes for Win7 Ult to support
AHCI. I had already loaded my motherboard's AHCI drivers. It
apparently worked, but I didn't see any major change in performance.
I went back to IDE for some reason that I can't remember. (Probably
because I lost SMART - see below.) I now find TRIM for my SSD will
only be enabled if I use AHCI, so I changed back again. *Or maybe I
didn't*: I can't tell, because going from AHCI to IDE back to AHCI in
BIOS did not appear to load any drivers each double reboot.

Looking at Device Manager "Disk Drives", my SATA SSD and 2 SATA HDDS
are described in properties as "ATA.... SCSI Disk device".

In "IDE ATA/ATAPI Controllers" I have 3 entries for" ATA Channel 0",
3 entries for "ATA Channel 1" and 3 entries for "Standard ACHI 1.0
SATA Controller".

In "Storage Controllers" I have an entry "Intel C600 Series Chipset
SATA AHCI Controller" and one for "Microsoft iSCSI Initiator"

I have a feeling that this is screwed up somehow. It appears as
though the IDE and AHCI drivers are both loaded, and one can skip
between them just by changing BIOS? Doesn't sound right.

What I do know was that under IDE my HDDs were enabled for SMART and
various programs I have (Perfect Disk, Speedfan) could report it.

With this latest apparent move to AHCI, SMART has gone. The disks and
SSD are reported either as non-SMART devices or SMART is disabled.

How do I clear this mess up? Delete all the drivers for HDDs and
controllers, or what? For AHCI, which drivers should I have
installed? It's driving me nuts to figure out what's happened.
(Incidentally, device manager is clean.)
Whoa! Vista and Windows 7 should have zero problems with AHCI. The first
thing I would be interested in is the machine you are talking about. Got
a make and model?
 
G

Gordonbp

When I installed Win7 I had trouble loading drivers and ended up using
IDE on SATA HDDs.
I don't understand. AFAIK Windows 7 installs on SATA disks without the need
for third-party drivers. It always has done here...
 
R

Robin Bignall

In Robin Bignall typed:

Whoa! Vista and Windows 7 should have zero problems with AHCI. The first
thing I would be interested in is the machine you are talking about. Got
a make and model?
It's based on a Gigabyte GA-X79-UD3 m/b but I think that's irrelevant.
It's got two separate SATA controllers: one with internal connections
that I use and another with rear connections for quite complex RAID
setups, which I don't use. The two have separate drivers.
When I installed W7U I had not discovered this group and only had the
M/B guide. For some reason the AHCI drivers gave a hex return code that
was meaningless so I reset BIOS to IDE and it ran.

Then, later, I found that with two registry tweaks one could implement
AHCI. So I did, it found the new drivers and ran.

Now, I have the device manager entries I listed in my previous post. It
*appears* that all the drivers for IDE and AHCI are all installed at the
same time and the mode can be set merely by changing BIOS. That sounds
weird to me. Hard Disk Monitor (product) assures me that the disks are
using AHCI.

I just wondered if I could remove the unused drivers from device
manager.
 
R

Robin Bignall

I don't understand.
Neither do I!
AFAIK Windows 7 installs on SATA disks without the need
for third-party drivers. It always has done here...
Well, I didn't know that when I installed W7 on a new m/b. The m/b
manual told me to install drivers when windows asked which disk it
should be installed on, by clicking on 'drivers' and choosing AHCI or
RAID, 32 or 64. AHCI just would not install for some unknown reason.
 
P

Paul

Robin said:
It's based on a Gigabyte GA-X79-UD3 m/b but I think that's irrelevant.
It's got two separate SATA controllers: one with internal connections
that I use and another with rear connections for quite complex RAID
setups, which I don't use. The two have separate drivers.
When I installed W7U I had not discovered this group and only had the
M/B guide. For some reason the AHCI drivers gave a hex return code that
was meaningless so I reset BIOS to IDE and it ran.

Then, later, I found that with two registry tweaks one could implement
AHCI. So I did, it found the new drivers and ran.

Now, I have the device manager entries I listed in my previous post. It
*appears* that all the drivers for IDE and AHCI are all installed at the
same time and the mode can be set merely by changing BIOS. That sounds
weird to me. Hard Disk Monitor (product) assures me that the disks are
using AHCI.

I just wondered if I could remove the unused drivers from device
manager.
Some drivers are built into the OS.

IDE (Compatible and Native). Compatible means using I/O Space addressing
and INT14/INT15 for interrupts. Native means sitting in PCI Address space
and using PCI interrupts. Hardware register definitions are standardized.
There is an IDE driver built into the OS. (Support for both versions,
Compatible and Native, might have appeared late in WinXP. Compatible
has been around the longest. At one time, you had to install your
own PCI space driver, if that's where the storage controller was mapped.)

AHCI is a relatively new standard, supporting native command queueing,
for out-of-order completion of disk commands. The "MSAHCI" driver
is built-in. Command queueing existed previously in the SCSI world,
so the concept isn't really new. Just new to the IDE disk world.

RAID is usually a custom driver. Certain drivers were shipped
with your installed OS, including "IASTORV" for Intel. That allows
Intel RAID arrays to come up, without a separate driver. If a
person installs Matrix storage or RST driver from Intel, that
will be given a separate name, such as "IASTOR". The "V" on the
built-in driver, stands for Vista, and indicates that the practice
of including that driver, started with Vista. The Intel RAID
driver at least, is a combined AHCI/RAID, as they're both
in the same txtsetup.oem based package. A person is not
precluded, from installing the Intel RST driver, over top
of the OS built-in. It just complicates matters later, when
doing driver re-arming.

For all the built-in drivers, you wouldn't delete them. They're
not hurting anything. And if you use the Regedit based
"driver re-arming" procedure, you'll want those built-in
drivers to remain as install candidates.

If you want to remove drivers, you'd look in the
equivalent of "Add/Remove", the Programs and Features
thing, and see what you've installed there. Most likely,
a person who idly install the Intel RST package, and
perhaps end up with a second solution for RAID or AHCI.

*******

The references to SCSI, point out the two paths a driver
writer has, when writing a driver.

If a driver writer uses a "direct" style of driver, then
the driver writer has to deal with each kind of OS API
storage call (whatever they are). If the OS changes,
perhaps the model changes. The advantage of doing it
this way, is there's only one entry in Device Manager.

But Windows also has a SCSI driver stack, which is a second
means to communicate with hardware. Whereas the "internal"
storage path, would have calls specific to the OS design,
the SCSI stack deals in standard commands in the form
of a SCSI CDB (command/data block). The SCSI standard
would define those. They're honored by hardware devices
directly (say a SCSI or SAS hard drive perhaps). A driver
writer can write a "CDB interpreter", accept CDBs from
the OS, and translate them into one or more disk hardware
specific commands. Sometimes, you'll see two driver entries
in Device Manager, one of which might make reference to
SCSI. And seeing that, that tells you the driver listens
for CDBs from the OS, and the OS is informed the subsystem
is "SCSI". The whole notion is referred to sometimes as
"pseudo-SCSI", because the hardware isn't really SCSI hardware,
but the driver hides the details. As an example, the SCSI stack
would be a good way to hook a hardware RAID to the OS, giving
the impression there is "one volume" when in fact an array
of disks in RAID is delivering the data. The OS just
gets the impression data is coming from "one virtual disk".

In any case, evidence of what's happened, would be
sitting in your INF folder, and in the setupapi.* files.
The INF folder is not straight forward, because when
a driver is installed, the vendor INF file is renamed.
Perhaps "mystor.inf" from the original installer,
becomes "oem23.inf" in the INF folder. If the driver writer
is smart, in the "mystor.inf" file, the original file
name appears at the top of the file. Doing a text
search for "mystor", against the INF folder, will locate
the "oem23.inf" file as being the renamed candidate.
That's how you'd figure out where it went. Other options
for finding it, include searching for the VEN/DEV numbers
of the associated installed hardware. That is for times,
when the mystor.inf doesn't have a self-referential
line of text near the top of the file.

The setupapi.log file in WinXP, used to be a very reliable
source of information, as it logs every twist and turn
in the driver story. If a user has been "flipping their
BIOS settings", dated entries in the log file, tell you
precisely which days the user did the flipping. Now, in
Vista or later, I'm not at all sure how to get the same
level of good information. There is certainly a set of files
by that name (now more than one setupapi.* file), but
I don't recollect being as impressed with the information
inside. The old setupapi.log file was "one stop shopping"
on WinXP, and I could learn a lot from what's in there,
as to what went wrong. I can't really be as positive,
about the ability to trace how the system got that way,
on Windows 7.

You only uninstall drivers, if you know there'll be
a mechanism for the OS to "come back up" on the next
boot. While the OS has things like a "last known good"
configuration, one level of driver rollback and the like,
to fix up minor problems, you don't really want an OS
that can't boot. So if you're going to tear out a
driver via the equivalent of "Add/Remove", you want
to make sure there is a driver to take its place, if
the OS needs that driver to boot with. The reason
you can remove your video card driver, is because
the OS has a built-in VESA driver, which people rely
on so they can see their screen. That's an example
of knowing you have an alternative ready-to-go. In
the storage area, you have to be a little bit careful
you don't "cut the legs off your OS". It needs a leg
to stand on. Built-in IDE, AHCI, and a couple RAID
drivers, are examples of those legs. And on the
latest OSes, there is the notion of using registry
settings for "driver re-arming", so the OS will
consider all the candidates on the next boot.

Paul
 
R

Robin Bignall

I'm much obliged for this, Paul. It's a keeper for my Windows Internals
file.

I should add that Hard Disk Sentinel reports my SATA drives to be in
ACHI mode and performing well. Even my oldest drive, a three-year-old,
10,000 RPM drive called after a dinosaur is 100% on SMART. (I notice
they don't seem to make these 10,000 drives anymore. Reliability
problems?
For all the built-in drivers, you wouldn't delete them. They're
not hurting anything. And if you use the Regedit based
"driver re-arming" procedure, you'll want those built-in
drivers to remain as install candidates.
I certainly don't want to delete drivers; merely to understand the
multiplicity of line items in "device manager / IDE ATA/ATAPI
controllers", where I have 3 sets of 3 entries for 3 drives. I wonder if
they are all necessary or whether W7 is "stacking" drivers like Win98
used to, and all I need are the AHCI ones, removing the IDE ones.
 
P

Paul

Robin said:
I'm much obliged for this, Paul. It's a keeper for my Windows Internals
file.

I should add that Hard Disk Sentinel reports my SATA drives to be in
ACHI mode and performing well. Even my oldest drive, a three-year-old,
10,000 RPM drive called after a dinosaur is 100% on SMART. (I notice
they don't seem to make these 10,000 drives anymore. Reliability
problems?


I certainly don't want to delete drivers; merely to understand the
multiplicity of line items in "device manager / IDE ATA/ATAPI
controllers", where I have 3 sets of 3 entries for 3 drives. I wonder if
they are all necessary or whether W7 is "stacking" drivers like Win98
used to, and all I need are the AHCI ones, removing the IDE ones.
If you wish to dump the contents of Device Manager,
you can use Devcon for that (a Microsoft utility).

The only problem with Devcon, is getting a copy. The
32 bit version, is easy to download from a KB article.
But when 64 bit OSes came out, they didn't add Devcon64
to the same KB article. To get it, I think I had to
download a CD from Microsoft, and it was on there.
The IA64 version, available in the KB article, is
*not* for Intel/AMD processor users, it's for Itanium.

In here, I386\DevCon.exe is suitable for Win7 x32. For
Devcon64, you have to look elsewhere.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q311272

For Devcon64, you have to look elsewhere.
The usual Microsoft hayride... :-( Enjoy the trip.

http://social.technet.microsoft.com...ion-of-device-console-utility-devcon-exe.aspx

This is a snippit of devcon output from my WinXP box.
My CR52 is a relic, but I like it. It doesn't
read DVDs, which is why I have a couple more drives
to throw in the box when needed :)

IDE\CDROMMSI_CD-RW_CR52__________________________3.90____\6&360A8F2&0&0.0.0
Name: MSI CD-RW CR52
Driver installed from c:\windows\inf\cdrom.inf [cdrom_install].
4 file(s) used by driver:
C:\WINDOWS\system32\DRIVERS\cdrom.sys
C:\WINDOWS\system32\DRIVERS\redbook.sys
C:\WINDOWS\system32\DRIVERS\imapi.sys
C:\WINDOWS\system32\storprop.dll
IDE\DISKST3500418AS_____________________________CC46____\5&5C4DDEF&0&0.0.0
Name: ST3500418AS
Driver installed from c:\windows\inf\disk.inf [disk_install].
1 file(s) used by driver:
C:\WINDOWS\system32\DRIVERS\disk.sys
IDE\DISKST3500418AS_____________________________CC46____\5&CF4D2B6&0&0.0.0
Name: ST3500418AS
Driver installed from c:\windows\inf\disk.inf [disk_install].
1 file(s) used by driver:
C:\WINDOWS\system32\DRIVERS\disk.sys

The command to use in an elevated command window would
be something like:

devcon driverfiles * > output.txt

Then open output.txt in Notepad.

That's a way to get info from Device Manager,
without taking screenshots to do it.

Paul
 
R

Robin Bignall

If you wish to dump the contents of Device Manager,
you can use Devcon for that (a Microsoft utility).

The only problem with Devcon, is getting a copy. The
32 bit version, is easy to download from a KB article.
But when 64 bit OSes came out, they didn't add Devcon64
to the same KB article. To get it, I think I had to
download a CD from Microsoft, and it was on there.
The IA64 version, available in the KB article, is
*not* for Intel/AMD processor users, it's for Itanium.
Thanks again. I'm 32 bit, have got the package and will give it a go
tomorrow when I'm not half asleep.
 
C

charlie

Neither do I!


Well, I didn't know that when I installed W7 on a new m/b. The m/b
manual told me to install drivers when windows asked which disk it
should be installed on, by clicking on 'drivers' and choosing AHCI or
RAID, 32 or 64. AHCI just would not install for some unknown reason.
I had a similar situation with an older asus MBD using the BIOS version
as shipped.
The first indication was that the MBD BIOS "saw" the HD, and not the
SATA CD Drive. It would see an IDE CD drive, or even a bootable USB
stick. Further when Linux was loaded the CD Drive was recognized.

I toggled the IDE mode in BIOS, and back to ACHI. Then, all of a sudden,
the CD Drive was visible. Since then there were several BIOS updates,
with the last one in 2010. Even with the last version, selecting the
boot drive and the boot sequence can be a bit tricky.

Using the same system, I recently went through a hassle setting up some
SSD drives as a boot drive. Turned out that the ACHI drivers were AMD
drivers, and the SSD firmware updates required the generic MS ACHI
drivers. Live and learn!
 
Y

Yousuf Khan

When I installed Win7 I had trouble loading drivers and ended up using
IDE on SATA HDDs. Later, I saw how I could change to AHCI.

A while ago I applied the registry fixes for Win7 Ult to support AHCI. I
had already loaded my motherboard's AHCI drivers. It apparently worked,
but I didn't see any major change in performance. I went back to IDE
for some reason that I can't remember. (Probably because I lost SMART -
see below.) I now find TRIM for my SSD will only be enabled if I use
AHCI, so I changed back again. *Or maybe I didn't*: I can't tell,
because going from AHCI to IDE back to AHCI in BIOS did not appear to
load any drivers each double reboot.
A couple of different points in this paragraph:

(1) Performance change between IDE and AHCI. You won't see much
difference when using hard drives, they are limited by their own
mechanical speeds. So either IDE or AHCI will yield the same results in
performance as they are both much faster than the mechanical hard
drives' ability to transfer.

(2) TRIM should work with either IDE or AHCI drivers, as it's not really
part of either one's standards. It's a command that exists only for
SSD's, and is built on a layer higher than the IDE/AHCI level.

(3) As for reloading drivers after changing between AHCI and IDE and
back in the BIOS, that only happens the first time. After that, the
entries are stored in the registry and it will never have to do that again.
Looking at Device Manager "Disk Drives", my SATA SSD and 2 SATA HDDS are
described in properties as "ATA.... SCSI Disk device".

In "IDE ATA/ATAPI Controllers" I have 3 entries for" ATA Channel 0", 3
entries for "ATA Channel 1" and 3 entries for "Standard ACHI 1.0 SATA
Controller".

In "Storage Controllers" I have an entry "Intel C600 Series Chipset SATA
AHCI Controller" and one for "Microsoft iSCSI Initiator"
My desktop system has two different sets of controllers for its drives.
One is the built-in motherboard SATA, and the other is a plug-in PCIe
SATA board. The motherboard SATA uses the standard Microsoft AHCI
drivers (or when it was running in IDE mode, it used the Microsoft IDE
drivers). The plug-in board on the other hand uses the Microsoft IDE
drivers all of the time.
I have a feeling that this is screwed up somehow. It appears as though
the IDE and AHCI drivers are both loaded, and one can skip between them
just by changing BIOS? Doesn't sound right.
Yes, it's entirely possible to have both loaded simultaneously, for
example in the setup I have listed up there, there are two controllers
which are totally separate: one is running IDE, while the other runs
AHCI. Also since the one running in AHCI can also optionally run as IDE,
at those times it too will show up as IDE.

Basically, IDE is known as the ATA7 protocol, while AHCI is known as the
ATA8 protocol. That's why SATA controllers can appear like IDE
controllers, all it has to do is identify itself as an ATA7 device,
rather than an ATA8.
What I do know was that under IDE my HDDs were enabled for SMART and
various programs I have (Perfect Disk, Speedfan) could report it.

With this latest apparent move to AHCI, SMART has gone. The disks and
SSD are reported either as non-SMART devices or SMART is disabled.
Now, I have no trouble reading SMART from my disks while AHCI is
enabled. However, I have known SMART to be problematic if the controller
isn't acting as merely AHCI, but instead it may be acting as a RAID
controller. In some RAID configurations, the SMART information may be
hidden.

From your motherboard description, I think you are using the Intel X79
chipset, right? I think that implements a RAID feature. So you maybe
using a RAID rather than standard AHCI.
How do I clear this mess up? Delete all the drivers for HDDs and
controllers, or what? For AHCI, which drivers should I have installed?
It's driving me nuts to figure out what's happened. (Incidentally,
device manager is clean.)
You could try going back to IDE, and I think you'll find that your SSD's
TRIM feature is supported under it. Check your Hard Disk Sentinel, it
should tell you whether TRIM support is enabled or not, in the overview
page for the SSD.

Yousuf Khan
 
R

Robin Bignall

First of all, thank you Yousef. This post is also a keeper.
A couple of different points in this paragraph:

(1) Performance change between IDE and AHCI. You won't see much
difference when using hard drives, they are limited by their own
mechanical speeds. So either IDE or AHCI will yield the same results in
performance as they are both much faster than the mechanical hard
drives' ability to transfer.

(2) TRIM should work with either IDE or AHCI drivers, as it's not really
part of either one's standards. It's a command that exists only for
SSD's, and is built on a layer higher than the IDE/AHCI level.

(3) As for reloading drivers after changing between AHCI and IDE and
back in the BIOS, that only happens the first time. After that, the
entries are stored in the registry and it will never have to do that again.
That explains a lot.
My desktop system has two different sets of controllers for its drives.
One is the built-in motherboard SATA, and the other is a plug-in PCIe
SATA board. The motherboard SATA uses the standard Microsoft AHCI
drivers (or when it was running in IDE mode, it used the Microsoft IDE
drivers). The plug-in board on the other hand uses the Microsoft IDE
drivers all of the time.
OK.


Yes, it's entirely possible to have both loaded simultaneously, for
example in the setup I have listed up there, there are two controllers
which are totally separate: one is running IDE, while the other runs
AHCI. Also since the one running in AHCI can also optionally run as IDE,
at those times it too will show up as IDE.

Basically, IDE is known as the ATA7 protocol, while AHCI is known as the
ATA8 protocol. That's why SATA controllers can appear like IDE
controllers, all it has to do is identify itself as an ATA7 device,
rather than an ATA8.
OK.


Now, I have no trouble reading SMART from my disks while AHCI is
enabled. However, I have known SMART to be problematic if the controller
isn't acting as merely AHCI, but instead it may be acting as a RAID
controller. In some RAID configurations, the SMART information may be
hidden.

From your motherboard description, I think you are using the Intel X79
chipset, right? I think that implements a RAID feature. So you maybe
using a RAID rather than standard AHCI.
No, RAID and its setup is definitely yet another option in the driver
choice that I have not chosen.
You could try going back to IDE, and I think you'll find that your SSD's
TRIM feature is supported under it. Check your Hard Disk Sentinel, it
should tell you whether TRIM support is enabled or not, in the overview
page for the SSD.
Thanks again. Everything appears to be working OK, and Sentinel can see
the SMART readings. TRIM is enabled for the SSD. I have no idea why
Perfect Disk can't see SMART.
 
Y

Yousuf Khan

Thanks again. Everything appears to be working OK, and Sentinel can see
the SMART readings. TRIM is enabled for the SSD. I have no idea why
Perfect Disk can't see SMART.
Yeah, Hard Disk Sentinel tends to stay a little uptodate with its
technologies. I've even paid for its registered version, I find it
useful enough.

If you want to verify that Sentinel is not alone in seeing the SMART
readings, then you might want to download CrystalDiskInfo, it's
completely free.

Yousuf Khan
 
R

Robin Bignall

Yeah, Hard Disk Sentinel tends to stay a little uptodate with its
technologies. I've even paid for its registered version, I find it
useful enough.
Yes, me too.
If you want to verify that Sentinel is not alone in seeing the SMART
readings, then you might want to download CrystalDiskInfo, it's
completely free.
I'm sure it will. I wonder why Perfect Disk Pro (paid for) won't. I
shall ask them.
 
R

Robin Bignall

Yes, me too.

I'm sure it will. I wonder why Perfect Disk Pro (paid for) won't. I
shall ask them.
Very weird. I started PD to do just that and SMART came up immediately
for my 2 SATA HDDs but not the SSD.
 
Y

Yousuf Khan

Very weird. I started PD to do just that and SMART came up immediately
for my 2 SATA HDDs but not the SSD.
It might have just been a passing gremlin.

Yousuf Khan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top