Announcement

Collapse
No announcement yet.

Lenovo Yoga 2 & Corsair Voyager GT - Device descriptor request failed

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Lenovo Yoga 2 & Corsair Voyager GT - Device descriptor request failed

    Update: I thought this fixed it, but it didn't, see post #2 for the continuing story.

    Just attempted to debug this USB issue & will post the solution here for others.

    The problem was with a Lenovo Yoga 2 Pro Ultrabook, whose USB3 port wasn't working with a Corsair Voyager GT 32GB USB3.0 flash drive in Win8.1.

    The same USB port work with other USB devices. So the port was working OK, except for with the Voyager flash drive.

    The same Corsair Voyager flash drive worked on other machines. So the flash drive was also OK.

    The error message displayed in Windows device manager was,
    "Device descriptor request failed" and
    "A request for the USB device device descriptor failed" and
    "(Code 43)"

    The USB3.0 port in device manager was running the new Microsoft "eXtensible Host Controller". This is new to Win8. In older Windows releases the USB3.0 device driver was supplied by the manufacturer of the host controller (Intel, NEC, etc..).

    After some investigation it seems that the Corsair Voyager GT flash drive is missing the Binary Device Object Store (BOS) in its setup data. The BOS descriptor returns a set of device-level capability descriptors for the USB device. If the USB version field, bcdUSB, is set to be greater than 2.0 then the BOS is mandatory. But despite being mandatory it seems to be missing in the Corsair Voyager.

    This lack of BOS causes the Device descriptor request failed message.

    There is a work around however. You need to add a key to the registry to stop Win8 enforcing this BOS requirement.

    To apply the workaround for a specific device, add a REG_DWORD value named SkipBOSDescriptorQuery that has a value of 1 to the following registry subkey:


    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\usbflags\vvvvpppprrrr

    (where vvvv is the device's Vendor ID, pppp is the device's Product ID, and rrrr is the device's Revision number)

    My Corsair Voyager GT 32GB had a VID of 1B1C and PID of 1A01. So the required entry for me was,

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\usbflags\1B1C1A010000

    Additional details can be found here,
    http://blogs.msdn.com/b/usbcoreblog/...h-code-43.aspx

  • #2
    This process (above) for some reason, initially worked. But them started to fail reliably the next day. So don't bother with the steps above.

    Today, I did some additional message tracing on the USB3.0 bus.

    USB message traces on Win8.1 show that the Voyager flash drive returns USBD_STATUS_XACT_ERROR after the USB3 host controller sends a SET_SEL message to set the U1 and U2 latencies. These U1 and U2 latencies are for power management, to ensure USB devices use a minimum amount of power when the machine is asleep.

    This appears to be a design flaw in the USB drive, as according to USB 3.0 Specification Section 9.4.12, the SET_SEL message has to be supported. This causes enumeration failure. I tried a few other USB3 devices and they handled the SET_SEL message correctly.

    The USB drive also fails to correctly respond to the set ISOCH delay message, but in this case the drive returns an error code of, USBD_STATUS_STALL_PID. Which isn't so bad, as the Microsoft USB3 driver ignores "Stall" responses and continues on.

    So I have opened up a support ticket with Corsair to see what they have to say about the issue.

    Comment


    • #3
      Got a brief reply from Corsair.
      "I have approved your rma".

      Which is a bit funny as I wasn't asking for a RMA.

      So I don't know if this is an admission that all their 2012 drives had a design flaw, or that their support staff couldn't be bothered looking at the trace data I sent. We'll see what happens once they send out a replacement drive (from Taiwan it seems, as they are asking me to ship it internationally).

      Comment


      • #4
        Received a replacement drive from Corsair (labelled as a factory reconditioned unit). Surprisingly enough, it works.

        So it seems like it was a design flaw / firmware issue in the original drive.

        I am not sure if this is my original drive with a firmware upgrade, or a drive someone else returned as faulty. So I'll give it a good burn in test before using it.

        Comment


        • #5
          My 2012 Corsair Voyager GT 32GB also recently broke, and I saw some similar error messages in dmesg on Linux.
          The pen would work for around 10-20 seconds before disconnecting or locking up. Then it would have to "cool off" for a few minutes before I could use it again; the longer I let it cool off, the longer it would last in the next run.

          I managed to restore the whole drive using a little monitoring script and GNU ddrescue (package gddrescue on Ubuntu, ddrescue on Arch Linux).

          Here's the script (gtrescue.sh):
          Code:
          #!/bin/sh
          INFILE=/dev/sdb1
          ready=1
          while sleep 0.5; do
              [ -e "$INFILE" ] || {
                  if [ $ready = 1 ]; then
                      echo "Waiting for $INFILE..."
                      ready=0
                  fi
                  continue
              }
              ready=1
              ddrescue -A "$INFILE" "`basename "$INFILE"`.img" "`basename "$INFILE"`_ddrescue_log" && exit 0
          done
          Once finished, the ddrescue log would have some bad blocks registered due to the constant disconnection. To retrieve these last bits from the drive, I changed the blocks to "non-tried" in the log and ran my script one last time:
          Code:
          cp -a sdb1_ddrescue_log sdb1_ddrescue_log.bak
          ddrescuelog -a "-,*" sdb1_ddrescue_log.bak >sdb1_ddrescue_log
          Once I had all the contents, I could just "fsck.vfat -a" the dump image file and mount it with the "-o loop" option.

          Now, the only thing left to do is RMA
          Last edited by helge; Oct-28-2014, 08:00 AM. Reason: grammar

          Comment


          • #6
            I had the very same issue, at first the Lenovo Yoga 2 Pro port didn't work at all, and I have read guides for fixing this issue over 78h just to find out that it works again ...

            Comment

            Working...
            X