Rampage V Windows lockup fault codes fd and 61 solved!

[AquaRelliux]

Hello everyone

I would like to share some research I did on this board. I have notcied that many users seem to have problems with thier windows hanging on loading screen. This is my previous post about it:

http://rog.asus.com/forum/showthread.php?54591-Windows-boot-uo-hangs-with-fault-codes-fd-61-system-i...

Here are some more users with the same problem:

http://rog.asus.com/forum/showthread.php?53759-Rampage-V-Extreme-won-t-boot-with-2-SLI-GeForce-Titan...
http://rog.asus.com/forum/showthread.php?54976-Rampage-V-Extreme-X99-and-Thrustmaster-Warhog-HOTAS

I have seen more threads about this but I can't seem to find them now. The solution to my windows hanging seems to be disconnecting my USB 2.0 hub that goes to my Dell u2412m screen. After that the problem seems to have vanished. But I am wondering why this is happening and not every boot but just randomly. It always hangs on fd or 61 error codes when it hangs.

Really to me this board seems like it is still in the beta phase, there is so many bugs on glitches that it should not have been released. I am considering switching to EVGA since my friend has that board and it works just flawlessly even with the usb 2.0 hub on his screen. Could Asus please release a bios that fixes this? I have owned all Rampage boards since the II for x58 and I have never had so many problems like I have had with this one.

//AquaRelliux

[Raja]

The Dell monitor's hub may be leaking DC back into the board. Have seen this before - it causes problems if this is the case as 5V will be present when it should not be. USB spec stipulates that the input side of any USB device/hub should not have 5V present. Sadly, many devies don't adhere to this and cause issues.

[Onimax]

This is exactly what I am experiencing.
The problem is I am using an internal USB 2.0 hub to plug in several thermal sensors, the pump of my AIO watercooling (Kraken X61) etc. as we only get two USB 2.0 headers and one is already taken by the ROG-Panel. So manually disconnecting the hub and connecting it after boot is not very practical 😞

Is there/will there be any other solution to this problem?
Maybe manually solder in a diode to stop the back-leakage on the 5V rail?
Or can we expect a bios update to fix this? Even if it is not within standard speccs this problem seems to arise with almost every second USB device I have laying around...

[Raja]

Onimax wrote:
This is exactly what I am experiencing.
The problem is I am using an internal USB 2.0 hub to plug in several thermal sensors, the pump of my AIO watercooling (Kraken X61) etc. as we only get two USB 2.0 headers and one is already taken by the ROG-Panel. So manually disconnecting the hub and connecting it after boot is not very practical 😞

Is there/will there be any other solution to this problem?
Maybe manually solder in a diode to stop the back-leakage on the 5V rail?
Or can we expect a bios update to fix this? Even if it is not within standard speccs this problem seems to arise with almost every second USB device I have laying around...

Is that a self powered hub - or are there any self powered dvices attached to it? If so, then DC could be an issue (would need to be checked).

Using a diode to prevent reverse voltage sounds okay until we take Vfd of the diode into account. You would end up with voltage lower than 5V as a result (and need a suitable diode to handle the forward supply current), which some connected USB devices that rely on that rail may not like. This is why we dont put such diodes on the boards. If we did, we'd end up with more issues. Imagine a situation where the 5V rail is regulated to a lower voltage by a regulator with a dropout voltage that is close to spec at 5V input. If the dropout voltage is breached the regulator output sags or it stops regulating altogether. The second reason is the obvious one; the USB device vendor should adhere to spec.


That is all assuming DC is the cause and not some kind of incompatibility elsewhere of course.

UEFI updates cannot prevent reverse current via USB. The issue can only be solved by device vendors who need to adhere to USB spec.

-Raja

[Onimax]

Raja@ASUS wrote:
Is that a self powered hub - or are there any self powered dvices attached to it? If so, then DC could be an issue (would need to be checked).

Using a diode to prevent reverse voltage sounds okay until we take Vfd of the diode into account. You would end up with voltage lower than 5V as a result (and need a suitable diode to handle the forward supply current), which some connected USB devices that rely on that rail may not like. This is why we dont put such diodes on the boards. If we did, we'd end up with more issues. Imagine a situation where the 5V rail is regulated to a lower voltage by a regulator with a dropout voltage that is close to spec at 5V input. If the dropout voltage is breached the regulator output sags or it stops regulating altogether. The second reason is the obvious one; the USB device vendor should adhere to spec.


That is all assuming DC is the cause and not some kind of incompatibility elsewhere of course.

UEFI updates cannot prevent reverse current via USB. The issue can only be solved by device vendors who need to adhere to USB spec.

-Raja

I am using the NZXT IU01 which is a self powered device (via a molex connector) the connected devices however are not.

Also I was thinking about using a shottkey diode or something like that to prevent leakage to minimize voltage dropout.
An update of all the USB devices out there not performing within the new parameters seems very unlikely to me, but you never know...

[AquaRelliux]

I have had the same monitor since my Rampage III, it did not cause problems on that board nor the Rampage IV. Why can't this be fixed by a bios update?

[Raja]

AquaRelliux wrote:
I have had the same monitor since my Rampage III, it did not cause problems on that board nor the Rampage IV. Why can't this be fixed by a bios update?

If DC is the problem then using the monitor on different boards models isn't really an indicator that the device is not to blame. Different motherboard models rely on the 5V rail in different ways to power onboard devices, therefore how the board reacts in presence of 5V when/where it should not be present will also be different. A UEFI update cannot prevent a device from leaking power into the board. The only thing a UEFI update could provide is a fix for something on our side regarding how the hub is seen as a BOOTable device etc.


The other thing to note is that Intel changed the way UEFI handles legacy USB devices - the device vendors themselves need to provide updates to affected devices.

[Raja]

The only way vendors will update devices that leak DC is if enough people that have issues call them out. That still won't help those that purchased devices with the issue, unless the vendor in question offers them an exchange.

The Intel update for USB is also touchy for some of the smaller vendors, they may not have the capabilities to go back and update older devices at this stage.

If you have a DMM handy, check the input side of the hub to see if it is supplying 5V - it should not be. If it is, I'd think about what you want to do with that hub going forwards. Depending on how that hub is put together, you might be able to cut the 5V trace to the input connector (depends if it is needed for handshaking or not. If it is then you need it connected). That way no blocking device is needed because no power can go back to the board.

If it does not have 5V present then contact your local ASUS support department and report the issue to them for elevation.

[AquaRelliux]

Well the dell moniter uses a powered USB hub, the Rampage V must be weak then since the EVGA board hanadles it fine.

[Raja]

AquaRelliux wrote:
Well the dell moniter uses a powered USB hub, the Rampage V must be weak then since the EVGA board hanadles it fine.

"Weakness" has nothing to do with it. Its to do with how the board uses 5V for onboard devices and has nothing to do with strength or weakness.