GA-P55A-UD4P and Marvell 91xx Config ATA Device

[gaktoid]

I'm running Windows 7 x64. I have installed all the drivers from Gigabytes website (except Intel raid and inf).

My issue is with the Marvell 9128 chip. I do not have any drives connected to SATA3_6 or SATA3_7. However, the "Marvell 91xx Config ATA Device" appears in the Safely Remove Device dialog box in the system tray and in Devices and Printers.

According to Microsoft (http://www.microsoft.com/whdc/device/storage/eSATA.mspx) this is an indication that Windows thinks the internal SATA ports are external.

First, has one one else seen this issue?
Second, is there a fix?

Thanks.

-Gak Toid

 

[bilbat]

My guess: it's installed in AHCI mode, which supports 'hot-plug (and, therefore, by extension, 'hot-unplug!'); windoze just wants to make sure the cache is flushed before you 'yank it'...

 

[gaktoid]

That does make some sense. It is configured in the BIOS in "RAID" mode.

However, I don't think that's the whole picture. In the Device Manager it shows that the 'Marvell 91xx Config ATA Device' has the "Capability" set to "Removable" (CM_DEVCAP_REMOVABLE [0x00000004] from cfgmgr32.h). This setting resides in the registry, but I believe it is set by the driver.

I would expect any drives attached to show up a removable. This seems to indicate that the chip/ports are removable.

-Gak Toid

 

[bilbat]

You mean you haven't seen the little 'flip tab' that lets you pop the 9128 out and use it in your laptop?

Seriously - my second guess - 'early adopter's blues'! I know that RAID drivers were not yet available when the new boards were released - and are, now... I'm curious myself - are they 'WHQL'd yet? I have tried to get 'spec level' info on Marvell's chip - and they don't appear to make it available; they appear to only have mechanisms in place to deal with wholesale customers. There's always a certain amount of 'suffering' that goes with the advent of new technologies - and I always try to sidestep it for, like, the first year; but, lately, it never stops. I predicted, and avoided, the early debacles with the 1366/1156 stuff, but have been drooling over the hardware for a while, now. It seemed like they only ever released one 'second gen' board (the X58-UD3R 1.6/1.7) with the early hardware kinks ironed out, and then it's off to the races again with the 'A' suffix boards, and not one, but two untried technologies - SATA3 and USB3! Eeek! The 'hexacores' are due for release, and I'm thinking 'server board' (wish GB made some - better the devil you know than the devil you don't!)

 

[gaktoid]

I picked this board because I needed ESATA and coax digital audio out. It's hard to find a board with both of those features that has as good reviews as this one did, even with the SATA3 and USB3 situation.

According to Gigabyte:

it is normal since it is an 3rd party controller

Which to me sounds like not an answer.

Anyway, so far I can't complain about the board. It's a long way to the front panel audio header, but other these minor quibbles it's been solid.

-Gak Toid

 

[skool]

I have the same board and the same problem on Windows 7 Ultimate 64-bit. I fixed the problem by installing the Marvell Console Driver (SATA3) update Gigabyte had listed under the GA-P55A-UD4P drivers page. Give that a shot! Might solve the problem. Good luck!

 

[bilbat]

Ya gotta cut the 'driver and BIOS guys' some slack they'll get it all ironed out eventually

I'm loking at a server board, as I've developed an app that could really use 58 lanes of PCIe, and so have been trying to 'digest' the 5520 IOH docs; here's a piece on message ordering from Intel:

6.2.1 Inbound Ordering Requirements

In general, there are no ordering requirements between transactions received on different PCI Express interfaces. However, the rules below apply to inbound transactions received on the same interface.

Rule 1. Outbound non-posted read and non-posted write completions must be allowed to progress past stalled inbound non-posted requests.

Rule 2. Inbound posted write requests and messages must be allowed to progress past stalled inbound non-posted requests.

Rule 3. Inbound posted write requests, inbound messages, inbound read requests, outbound non-posted read and outbound non-posted write completions cannot pass enqueued inbound posted write requests. The Producer - Consumer model prevents read requests, write requests, and non-posted read or non-posted write completions from passing write requests. Refer to PCI Local Bus Specification, Revision 2.3 for details on the Producer - Consumer ordering model.

Rule 4. Outbound non-posted read or outbound non-posted write completions must push ahead all prior inbound posted transactions from that PCI Express port.

Rule 5. The IOH is unaware of which destination I/O bus (for example, PCI-X* on the PXH) the read completion comes for outbound transactions. Therefore, the IOH prevents forwarding the read or non-posted write completion to the Intel QuickPath Interconnect until all currently enqueued inbound writes are complete (independent of the VC value).

Rule 6. Inbound, coherent, posted writes will issue requests for ownership (RFO) without waiting for prior ownership requests to complete. Local-local address
conflict checking still applies.

Rule 7. Inbound messages follow the same ordering rules as inbound posted writes (FENCE messages have their own rules).

Rule 8. Similarly to inbound posted writes, reads should push these commands ahead.

Rule 9. If an inbound read completes with multiple sub-completions (for example, a cache line at a time), those sub-completions must be returned on PCI Express in linearly increasing address order.

The above rules apply whether the transaction is coherent or non-coherent. Some regions of memory space are considered non-coherent (for example, the Don’t Snoop attribute is set). The IOH will order all transactions regardless of its destination.

Rule 10. For PCI Express ports, different read requests should be completed without any ordering dependency. For the ESI interface, however, all read requests
with the same Tag must be completed in the order that the respective requests were issued.

Different read requests issued on a PCI Express interface should be completed in any order. This attribute is beneficial for the Intel 5500 Platform where the Intel QuickPath Interconnect is an unordered, multipath interface. However, the read completion ordering restriction on ESI implies that the IOH must guarantee stronger ordering on that interface.

6.3.1 Outbound Ordering Requirements

There are no ordering requirements between outbound transactions targeting different outbound interfaces. For deadlock avoidance, the following rules must be ensured for outbound transactions targeting the same outbound interface:

Rule 1. Inbound non-posted completions must be allowed to progress past stalled outbound non-posted requests.

Rule 2. Outbound posted requests must be allowed to progress past stalled outbound non-posted requests.

Rule 3. Outbound non-posted requests and inbound completions cannot pass enqueued outbound posted requests. The Producer - Consumer model prevents read requests, write requests, and read completions from passing write requests. Refer to PCI Local Bus Specification, Revision 2.3 for details on the Producer -
Consumer ordering model.

Rule 4. If a non-posted inbound request requires multiple sub-completions, those sub-completions must be delivered on PCI Express in linearly addressing order.
This rule is a requirement of the PCI Express protocol. For example, if the IOH receives a request for 4 KB on the PCI Express interface and this request targets the Intel QuickPath Interconnect port (main memory), the IOH splits up the request into multiple 64 B requests. Since the Intel QuickPath Interconnect is an unordered domain, it is possible that the IOH receives the second cache line of data before the first. Under such unordered situations, the IOH must buffer the
second cache line until the first one is received and forwarded to the PCI Express requester.

Rule 5. If a configuration write transaction targets the IOH, the completion must not be returned to the requester until after the write has actually occurred to the register. Writes to configuration registers could have side-effects and the requester expects that it has taken effect prior to receiving the completion for that write. The IOH will not respond to the configuration write until after the register is actually written (and all expected side-effects have completed).

If you're anything like me - my head hurt pretty soon after rule 2 And those guys gotta make this all happen in hardware, transparently to the users! We think we've got it tough keeping up with the 'driver of the week' club

 

[bilbat]

Oh - and might wanna read this, before deciding where to apportion those valuable PCIe lanes to:
http://benchmarkreviews.com/index.php?option=com_content&task=view&id=413&Itemid=38&limit=1&limitstart=7

 

[gaktoid]

Sorry about the thread necromancy...

I have the same board and the same problem on Windows 7 Ultimate 64-bit. I fixed the problem by installing the Marvell Console Driver (SATA3) update Gigabyte had listed under the GA-P55A-UD4P drivers page. Give that a shot! Might solve the problem. Good luck!

I don't see any update on the gigabyte web site(s). I tried gigabyte.com.tw, giga-byte.com, and gigabyte.us. Version: 1.0.0.1027 is the latest I see (and what I have installed).

-Gak Toid

 

[bilbat]

Yeah the whole Marvell thing is a royal PITA!
http://www.tomshardware.com/forum/268610-30-marvell-tray-gigabyte-mobo

 

[Guest]

I have the same board and the same problem on Windows 7 Ultimate 64-bit. I fixed the problem by installing the Marvell Console Driver (SATA3) update Gigabyte had listed under the GA-P55A-UD4P drivers page. Give that a shot! Might solve the problem. Good luck!

Thanks so much for posting this! Worked for me and probably saved me hours of trying to figure it out my self.

 

[Guest]

I have the same issue. I have a Gigabyte GA-X58A-UD3 Mother Board and am also running Windows 7 Home Premium 64 bit. In fact, I was looking for an answer myself when I ran across your comments.

I also have another issue someone might have an answer for. Whenever I start Windows, the Gigabyte logo pops up. Does anyone know how to get rid of this quirk?

 

[gaktoid]

I have the same issue. I have a Gigabyte GA-X58A-UD3 Mother Board and am also running Windows 7 Home Premium 64 bit. In fact, I was looking for an answer myself when I ran across your comments.

I also have another issue someone might have an answer for. Whenever I start Windows, the Gigabyte logo pops up. Does anyone know how to get rid of this quirk?

My memory is fuzzy, but I think that's the "Marvell RAID Utility". I just uninstalled that app.

-Gak Toid

 

[brinkerz]

I have the same board and the same problem on Windows 7 Ultimate 64-bit. I fixed the problem by installing the Marvell Console Driver (SATA3) update Gigabyte had listed under the GA-P55A-UD4P drivers page. Give that a shot! Might solve the problem. Good luck!

Kudos to you mate!

Sure - 6 month old thread but this issue popped up for me today after adding 2 sata dvd burners to my board on sata 6 & 7 (upgraded from IDE).
Followed as above and all sorted.

My many thanks!

 

[ggvideo]

I found the solution in another forum and wanted to explain in detail how I solved my problem. I installed LG HD-ROM burner with lightscribe. I did a mistake in connecting it to white SATA port. That has resulted in getting the error for Marvell 91xx config ATA Device - driver not installed. One solution to my type of problem is disconnect the HD-ROM Drive from White Port of the motherboard and connect it to other color (I connected it to green). Then my problem solved.