If you have been following my adventures with the Viliv S5 Premium UMPC then you are aware I have been so impressed with the little PC that I have ordered one for my own. I am getting a tremendous amount of good use out of the S5, and everyone I have shown it to is duly impressed with Viliv’s UMPC. This weekend a problem cropped up with the S5 that had me doubting my own judgement until I figured out what was causing it and I was able to get it solved. Now I am back to happy mobile computing, so I’ll pass on what happened in case it will be helpful.
One of the things that has most impressed me about the S5 is the power management that Viliv has incorporated. The user doesn’t have to do anything to get great battery life, and a big part of that has to do with how well the S5 enters and exits Standby mode. The common usage scenario is to pop the device into standby and to resume when it’s needed again. I usually find it only takes about two seconds to go into Standby and 2-5 seconds to resume. Unlike other mobile computers I have used in the past the S5 is able to resume from Standby and reconnect to the WiFi network very quickly, at least until yesterday.
The problem set in all at once, as they often do. I found that the S5 was having trouble resuming from Standby. The desktop would appear right away as usual, but I found that the system didn’t want to execute programs, sometimes for as long as a few minutes. I watched the process many times to determine what might be causing this and began to suspect that the USB systems were not resuming from standby very well. There are many USB systems on the S5, as there are on most mobile PCs. The visible USB systems that were not resuming properly were the WiFi adapter and the Bluetooth adapter. Both of these devices are USB, and I felt pretty certain that one of them was not making the transition from running to standby to running again.
I tested this with repeated standby cycles and hard boots. The USB systems would always work as they should after a hard boot, it was just with a resume that they would fail and cause the system delays I’ve indicated. I set about scouring the Device Manager to see if some power management settings had been changed somehow but nothing really stood out. So I thought long and hard about what could have caused a major change to this system to interfere with this process, one that had been so solid before the problem set in?
The answer was ultimately the hardware driver for the WiFi adapter. My efforts to troubleshoot this went as far as doing a complete system restore to factory conditions. That went well as Viliv has a recovery partition and an easy method to reimage the system using the device buttons. The restore was followed by a Windows Update session to bring it up-to-date and that’s where I noticed what could easily be creating my problem.
I must share the blame for this new driver install as I saw a new Marvell driver update in Windows Update and thinking it was the Ethernet adapter, I checked the box to install it. I don’t remember applying this update before the restore, but I must have done so. I still had the resume problem after the restore so now that I was aware the WiFi adapter had been updated I could deal with it. The fix to my problem that I wasted hours on troubleshooting was to simply roll the driver back to what it was originally. Windows makes that very simple to do and that has fixed my problem.
My system is back happily resuming from standby as it did before. I suspect that Viliv has done a good job customizing the Marvell driver for the S5 and the generic Windows Update driver lost those customizations, thus creating my problem. It goes to show that you have to pay close attention to updates that Windows wants to apply and make darn sure you need a hardware update.