Sign in with
Sign up | Sign in
Your question

Sata 0 recognized as Sata 2

Last response: in Motherboards
Share
January 22, 2010 8:20:49 AM

Hi
I have a new build that consists of a Gigabyte 790X-UD4P mobo, WD veloci-raptore HDD, DVD burner, Windows 7 Pro installed. I have the HDD plugged into Sata 0 and the DVD plugged into Sata 1 ( the yellow SB terminals ). Nothing intricate, no RAID, no ACHI enabled, etc. In the BIOS, the HDD is displayed as being plugged into Master 2 and the DVD into Master 3. Any reason to concerned? Is there anyway to fix this without too much screaming and hair pulling? The system boots up and runs for now. Thanks alot for any help.

More about : sata recognized sata

a c 435 V Motherboard
January 22, 2010 10:31:07 AM

What are you worried about? It makes no difference which sata port you use, or how it's detected.
m
0
l
a c 177 V Motherboard
January 22, 2010 3:49:17 PM

I see this, and a related question, often - I believe I have (hopefully) found the underlying explanation, but it involves more detail than (I think) anyone really wants to know... The ancillary question is "why do my drives show up in Device Manager as 'SCSI' drives, when they're not?" - and the short answer is the one that oldie posted - if your drives 'show up', and are accessible, to quote the Great and Powerful Oz, "pay no attention to the man behind the curtain..." - they work, don' matter at all what they're shown as...

The long (underlying) answer is:

Hardware devices are sometimes represented to software as something called a 'protocol stack', this is especially true of drives and networks. The best illustrated example I could quickly find is this Wiki entry on the OSI stack, which recently replaced the previous TCP/IP stack:
http://en.wikipedia.org/wiki/OSI_model
The reason they are called a 'stack', is that they are implemented as a series of 'layers', each one 'hiding' (and simplifying) the details of the layer below. For pretty much all stacks, the lowest layer is the actual physical interface to the device: in the case of a NIC, it's the shared memory that 'delivers' its packets, its MAC address, and the like; for the drives, it's the physical organization of the physical drive itself (sectors, cylinders, platters...) and the command set to handle these...

As I've said elsewhere, at its heart, an OS is simply and mainly an API - an application programmer's interface. If I'm writing a program, I don't want to have to know (or deal with) how many sectors and cylinders your drives are, or if I'll need to split the file into a few peices in different areas, or how the indices to those area are handled - I just pass a message to windoze asking for a file handle - and windoze takes care of the gory details. However, let's say I want to write a drive defragger, or a 'mil-spec' 'file shredder' - in that case, I might want lower-level access to the device, or maybe the error-handling of a given layer is too non-specific; the protocol stack gives me access to varying degrees of depth of control, balanced with the amount of detail to be coped with...

This is one of the reasons that hardware RAID cards are so much faster than 'FakeRAID' run on a chipset; running off your chipset, both the protocol stack handling, and the RAID5/6 parity calculations have to be done by your CPU; on a hardware RAID card, these are dealt with by a seperate processor - and, in the case of the more expensive ones, a dual-core, so it can run the protocol stack on one core, while it does the parity calcs on the other...

Anyway, assuming I've explained this well enough for you to 'get' the 'stack' idea, the problem with stacks is that they 'wear out'; as advances are made, usually at the hardware end, the old stack structure no longer supports the features that the new hardware adds. Typically, when this happens, and a new protocol is adopted, it contains a 'backward compatible' structure that allows older programs to 'get their stuff' in the manner for which they were written. One good example of this is that every video card, independent of complexity and processing power, contains a small (compared to its main 'memory map') 'chunk' of memory 'mapped out' of your main RAM, to give universal support to old, or low-level, stuff that only can 'talk' VGA - even though the VGA standard is now just a not-so-fond memory for some of us, and means nothing to the last couple generations of users. The trick is, that the BIOS itself, and utility programs that want to run in DOS (another memory) can operate 'like' there's a VGA card there...

So, the current protocol stack for disks is the SAS (serial attached SCSI), even though your drives aren't likely (unless you're running a server MOBO or RAID cars) actually SAS, nor SCSI - depnding on how the stack is implemented in the driver, windoze may 'see' it as a SCSI, and the BIOS shows them as 'master' and 'slave' - even though there is no relevance of the terms as applied to SATA drives...
m
0
l
January 22, 2010 5:44:15 PM

Thanks for the come back guys. I was groping through the dark with this first time build. I appreciate bilbat's detailed respose and believe I understood most of it. Thanks again.
m
0
l
Related resources
!