Announcement

Collapse
No announcement yet.

resuming from standby issues

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

  • resuming from standby issues

    I haven't been able to figure out the exact sequence of events that reproduce this StreetDeck crash but I believe it has to do with USB device driver issues upon resuming from standby. At least one USB device directly connected to the motherboard fails to become usable (usually the touchscreen) and StreetDeck will crash within a few seconds of resuming from standby.

    This does not happen all the time. More like every 3rd or 4th resume:

    power up -> standby -> resume ok -> standby -> resume ok -> standby -> usb device "issue" -> StreetDeck crash

    During standby, I force some USB devices to lose power (xenarc screen power cut, extigy power cut) while others retain standby power (GPS, USBUirt) via the motherboard.

    I am going to try to use devcon.exe to "unplug" all usb devices prior to going into standby and see if that helps (and "replug" upon resume)...

  • #2
    Yea, I'm having somewhat the same issue with the touchscreen as well. I'm using devcon.exe and sometimes that works, however, most of the time it doesn't.

    I make a simple batch file and have:

    "devcon.exe disable usb/ID"
    "devcon.exe enable usb/ID"

    and put that into startup folder for windows and that barely ever works. I even tried putting that batch into resume/launch folders of streetdeck and the result is poor as well. I could be using devcon incorrectly so I'll need to play with that syntax and arguments of that command a bit more.

    -twantrd

    Comment


    • #3
      That's disappointing to hear. Are you "unplugging" all usb devices? I have to read more on the syntax also. I think the best thing to do is unplug all usb devices using devcon.exe. Then reattach all.

      I was going to try a powered hub that is disconnected via a relay (hard disconnect) while in standby, but I started thinking that devcon.exe should theoretically stop the power draw also.

      Will experiment with devcon parameters and let you know...

      This is what I was going to try:

      Prior to standby:
      devcon disable @usb\*

      Upon resume:
      devcon enable @usb\*


      It's possible to actually do a "remove", but then the pc will search for drivers when doing the "rescan"; not sure that is optimal.

      GOD_OF_CPU, can you elaborate if StreetDeck will wait from accessing devices until after the batch file finishes executing?

      Comment


      • #4
        God_of_cpu - ?

        Does StreetDeck execute .BAT (batch) files when placed in the exit, launch, or resume folders? I know it execute .exe and shortcuts to .exe - just confirming .bat is considered "executable".

        Do the files in the "exit" folder get executed when going into standby (vs. really exiting)?

        (I have got the above devcon commands in batch files, called enableUSB.bat in the resume folder, and disableUSB.bat in the exit folder - will let you know if it helps after using it for a few days like that).

        Comment


        • #5
          Hi RcDash,

          (I have got the above devcon commands in batch files, called enableUSB.bat in the resume folder, and disableUSB.bat in the exit folder - will let you know if it helps after using it for a few days like that).
          Is it necessary to disable all the usb devices when you exit SD? I thought disabling and then enabling all during launch/resume should take care of it.

          Anyhow, yes, please let us know if the commands you posted work for you. Thanks!

          -twantrd

          Comment


          • #6
            I don't think it's executing the BAT file before exiting... Or if it is, then it is multithreaded because there is no pause and devcon takes at least a full second to do its thing.

            What do I need to do? Put a shortcut to the BAT file?

            Or maybe a shortcut to the devcon.exe file with the parameters in the shortcut? Will try that.

            EDIT: that didn't fare much better. The commands are NOT executing to disable USB devices prior to standby.

            Will have to wait for GOD_OF_CPU to review this thread...

            EDIT #2: Well, whilst waiting, I found out that the reason the commands were not executing was because this FAQ posted in the forum is wrong. The commands need to go into the My Documents folder, not the Application Data folder. However, now the commands execute on resume, but the "Exit" folder commands DO NOT execute on standby.

            EDIT #3: Twantrd, I could follow your suggestion but I have found that once the usb device driver "hangs", devcon hangs as well - so doing a disable and re-enable after the fact will do no good. The driver needs to be stopped before standby, then restarted after resuming.

            EDIT #4: A possibility to consider is that the Exit folder shortcuts are not being executed because I actually have the shutdown mode set to "Save Settings", not Standby. StreetDeck is out-of-sync somehow with the true function, because it WILL do a standby. If I actually set it to Standby, it will do HIBERNATE (even though hibernation is disabled in Windows). I will try to re-enable hibernation and see if StreetDeck gets back "in sync". Then I will try to set the shutdown mode to "Standby" and FINALLY hope that the Exit folder shortcuts get called.

            EDIT #5: So even though I enabled hibernation in Windows, StreetDeck behaves the same. If I select "Standby" in Settings, it will actually do a "Hibernate". I have confirmed that it DOES execute the shortcuts on actually closing StreetDeck. I cannot confirm that it executes the shortcuts on going into standby. I am now using the following commands only on resume/launch: devcon restart usb\vid* to restart all USB devices (but not controllers, which do not have hw ids that start with "vid").

            Still need help, GOD_OF_CPU...

            Comment


            • #7
              The more I tinker with this, the more I think the problem IS StreetDeck related.

              Today despite the above devcon script running upon resume, the touchscreen failed to recover after resuming from standby. I killed StreetDeck by pressing CTRL+ALT+DEL and I could see the devcon command "hung" in a CMD window. I started killing processes - as soon as I killed the StreetDeckTrayApp, devcon went through and the touchscreen started working.

              What does StreetDeck do upon resume that might affect USB device initialization?

              Comment


              • #8
                Originally posted by rcdash
                I haven't been able to figure out the exact sequence of events...
                Suspect/check your USB drivers/devices. Many are actually a Virtual Com Port (VCP) driver for devices manufactured by FTDI.

                Some vendors (GPS TripNAV TN200for example) ship with an ancient buggy driver with power management issues, while the FTDI reference driver has been continually updated.

                If any of your devices are FTDI VCP go to their site and get the latest drivers.

                http://www.ftdichip.com/Drivers/VCP.htm

                Comment


                • #9
                  Originally posted by rcdash
                  What does StreetDeck do upon resume that might affect USB device initialization?
                  Whenever streetdeck suspends it stops all media and closes all open COM ports. On resume it reopens all COM ports and other devices it uses. It starts playing the last media again.
                  StreetDeck.com Developer (I am Chuck)
                  Get StreetDeck at http://www.streetdeck.com
                  The Official StreetDeck Forums have moved, please visit us at http://www.streetdeck.com/forum for official support for Streetdeck.

                  Comment


                  • #10
                    FYI and FWIW

                    I think my XMPCR, Xenarc touchscreen USB interface, TripNAV GPS and OBII, devices all use an FTDI USB chip. If you've got multiple instances of FTDI chips and an older driver, contention issues between them and the order of re-enumeration/timing on resume could explain the spurious resume issues.

                    If I had installed each device in the order of PNP detection using the mfgr.-suppled drivers, who knows what rev. of the actual one set of drivers running all the devices I would have actually ended up with. When doing a clean install for SD, I just kept pointing at the FTDI driver on detection until one of them matched; subsequent devices that could use their driver did on auto-detect...

                    Just keep trying the devman driver update wizard for various USB devices pointing it at the FTDI driver (except for things with built-in drivers like mass storage, pointer devices etc.) and see if it "likes" the FTDI MSFT logo'd VCP driver they posted in January. If it got a logo it properly supports power management. The Jan. '06 direver works quite well and USB resume issues with missing/unavalable devices disappeared.

                    The problem with virtual COM ports is that they map to a legacy non-PNP bus/OS driver stack (chipset south bridge/ISA), and when they stuff things up only a reboot cures it usually.

                    If you can update the driver set for one device, you've updated the driver set for any/all FTDI devices most likely.

                    Comment


                    • #11
                      Hey All,

                      Thanks for the suggestions - will check them out. (EDIT: none of my devices recognized those drivers. Also the TouchKit driver IS a signed driver.)

                      1. Why would devcon.exe hang until the SD tray app was killed though?

                      2. It is still not clear to me how SD is/can execute shortcuts PRIOR to going into standby since it does not appear to "wait" for tasks to complete.

                      Comment


                      • #12
                        Found the source of my problem (resume from standby always fails)... I think.

                        Opus acknowledged an issue with some motherboards which take a while to POST. iBase MB896 is one of them. They need to update the firmware on my PS, which only they can do. Have to send it in. DOH!

                        ... and resume from hibernate is taking 1 minute from ignition on to system available. I'm thinking I might downgrade from 1GB of memory to 512 to see if that speeds things up..

                        Half the memory, the hiberfile is cut in half and that means a quicker resume right? Who knows.

                        If anyone does...

                        Comment


                        • #13
                          It should help - I have found that hibernate is slow on the MB896. Was much faster on the MB870. Both 512MB, both 7200 rpm SATA laptop drive. Posting from a cold boot is faster on the MB896 though. I use standby/resume almost exclusively now unless SD crashes. The Carnetix power supply P1900 does a great job of safely supporting standby mode in conjunction with my Travla C138 case and internal PS. I now have an OPUS 150W collecting dust...

                          Comment


                          • #14
                            Restating pending questions...

                            1. Why would devcon.exe hang until the SD tray app was killed though?

                            EDIT: after another "hang up", it appears that it was NOT the tray app, but SD itself - just took a few seconds after SD process ended to allow devcon to go through. Sometimes I DO need to kill both SD and the tray app in order to get devcon to go ahead and restart the USB devices. Not certain if there is some "parent thread" that is locking up a USB device or something????

                            2. It is still not clear to me how SD is/can execute shortcuts PRIOR to going into standby since it does not appear to "wait" for tasks to complete.

                            Comment


                            • #15
                              It appears StreetDeck is the app that is causing the USB "hang" issue after resuming. It just takes a few seconds after killing the process for devcon to go through and restart the USB devices.

                              It seems like SD accessing the COM ports (perhaps the USB GPS Com port?) before they are ready might be the issue???

                              To debug this and perhaps solve the problem, there needs to be a way for SD to execute tasks SYNCHRONOUSLY both before and after standby.

                              GOD_OF_CPU - any way to get SD to wait before accessing devices until after the "resume" tasks are completed?

                              Comment

                              Working...
                              X