USB-UIRT locking up

[perf]

Before the new version of the plugin was released, my USB-UIRT would not work after my computer resumed from standby. With the driver restart option, this has been solved.

However, I have now noticed that I have a new problem. I use Showshifter to record TV shows. Showshifter starts based on a Windows scheduler event, which wakes the computer from standby. When the recording has ended, the computer goes back into standby. At this point, my USB-UIRT seems to lock up. I can not get it to wake up the computer (otherwise not a problem), and after wake-up, it will not work. When I try to send anything with it, Girder displays an error message similar to "USB TX error" in its status bar. Girder starts misbehaving, and the Girder plugin for my IRMAN IR receiver also stops working.

I have tried scheduling other events than Showshifter recordings, and the behaviour is the same. My conclusion is that USB-UIRT has a problem with wake-up initiated by Windows Scheduler, although the problem does not manifest itself until after suspend. (The USB-UIRT works during the recording.)

Any ideas?

/Per

[jrhees]

Per,

First let's determine if the USB-UIRT's microcontroller is still working in this situation -- when you point a remote at it and press a button does the LED blink?

I suspect the 'Restart Driver' option in the plugin still has some wrinkles to iron out...

Are you suggesting that if you create an Windows scheduler event to wake your computer (not necessarily running ShowShifter) vs. simply manually resuming from standby that the USB-UIRT behaves differently?

Thanks,

-Jon

[perf]

First let's determine if the USB-UIRT's microcontroller is still working in this situation -- when you point a remote at it and press a button does the LED blink?

I had turned this off. Interestingly, the LED does blink (now when I turned it on), even though the USB-UIRT seems dead in relation to the PC.

Are you suggesting that if you create an Windows scheduler event to wake your computer (not necessarily running ShowShifter) vs. simply manually resuming from standby that the USB-UIRT behaves differently?

Exactly. And the problems do not seem to start until the computer goes into standby again.

An interesting finding from testing: If I use the remote during the time of the recording to send an event learned by USB-UIRT in Girder, the problems do not appear. They seem to appear when the computer is "left alone". However, it seems that having the USB-UIRT send IR during the recording does not prevent the problem from appearing. But I still have not been able to reproduce the problem without having the computer started by Windows Scheduler.

/Per

/Per

[jrhees]

OK,

I'll take a look at this. The Girder plugin uses a separate 'Receive' thread which runs all of the time looking for IR input. It is possible this thread, in conjunction with the 'Restart Driver' option is having some issues.

-Jon

[perf]

Testing the new Girder plugin gave an interesting result, which might provide a lead to the root cause of my problems:

If I use the new option to disable Wakeup Hardware Support, I can disable the "Suppress error messages" and "Restart Driver" options without receiving error messages when coming back from Standby. Everything works, exept for having the USB-UIRT wake up the computer. The LED still blinks during Standby, so there is power to the USB-UIRT.

A guess, based on your various posts on related topics (especially the "Suspend to RAM with no fans?" thread) and what I have experienced, is that something goes wrong at the point when the computer is going into standby. The MB might ask the USB-UIRT if it is OK to go into S3, the USB-UIRT says no (not knowing that it would still be powered?), but the system still goes into S3, and somehow this miscommunication blocks the driver or the communication between the USB-UIRT and the driver. When Wakeup Hardware Support is disabled, the USB-UIRT accepts that the system goes into S3, and the problem does not appear.

So: Could there be a way to eat the cake and still have it? Can I have the positive effect of disabling Wakeup Suppport, and still have Wakeup Support?

FYI: My BIOS lets me choose between S1 and S3 suspend modes, and has an option to enable/disable "USB Resume from S3". I have had it set to S3 all the time, with USB Resume enabled, and it has always gone into S3, and the USB-UIRT has always been able to wake it up. Maybe I should test whether the problem appears when going to S1, even though I am not interested in S1. I changed to S3 when I got the computer because I need the fans turned off. So my computer (a Shuttle SK 41G, bought in December) indeed seems to be proof that there are USB controllers that support resume from S3.

/Per

[perf]

An update from further testing: Setting the BIOS to go to S1 suspend mode instead of S3 makes no difference to the USB-UIRT. (But the computer is louder .)

/Per

[Guest]

Any news on this?

/Per

[perf]

Bump!

/Per

[jrhees]

Per,

Sorry to delay on this. Things have been hectic with supply issues on new builds. Hopefully that will be over soon!

Will keep you posted.

-Jon

[perf]

Some new very interesting discoveries.

I installed SP4 for W2k, and now the problems manifest themselves in a different way.

I can now turn on remote wake-up in the configuration dialog box, without selecting "suppress error messages" and "restart driver on start-up". The computer goes in and out of suspend without problems, unless in this case:

When I let the computer wake on a scheduler event to do a recording, wait for it to finish recording and go back to suspend, and then re-awake it, it crashes to a blue screen. These problems do not appear when remote wake-up is disabled.

In summary: The Error message when waking up from suspend is gone, but the problem of the USB-UIRT locking up have turned into the system crashing. For a while my problems seemed solved.

I guess the conclusion of this is that the code for restarting the driver has nothing to do with the problem. Instead something seems to happen to the state of the USB-UIRT or the driver or the plug-in when the computer is woken up and goes back to sleep without the USB-UIRT being used.

/Per

[jrhees]

Per,

I know this is a band-aid approach but if you could...

What happens if you allow the computer to wake to a scheduled event and go back to sleep automatically as you described, but in the meantime (while the machine is awake) you initiate a USB-UIRT transmit. Will the machine still crash on the next power-up?

What I'm thinking about here is that this is something you could do in a Girder script.

-Jon

[perf]

I already do this - the Showshifter recordings trigger the transmission of signals to my cable box. It seems that the USB-UIRT needs to be used for reception for the problems not to appear.

I have tested extensively during the weekend, and the behaviour is now consistent. By disabling USB-UIRT in Girder at suspend and enabling it at resume from suspend, I have minimised the problems to this:

The computer resumes from suspend to do a scheduled recording. The recording is performed, starting by the USB-UIRT transmitting signals to the cable box. After the recording is finished, the computer suspends again. If I resume the computer at this point by touching the mouse, I have no problems. If I instead try to resume it by sending the wake-up signal to the USB-UIRT, nothing happens (it stays suspended), and if I then wake the computer up with the mouse, most of the times it crashes (after a few seconds).

When no unattended recording is involved I am able to wake the computer up using the USB-UIRT.

Could there be a problem with the firmware? I guess the driver and the OS are not much involved in what happens at wake-up. Could it be that the USB-UIRT in this situation does not get told/does not understand that the computer is suspended, and therefore does not try to wake up the computer upon receipt of the wake-up signal?

/Per

[jrhees]

Per,

To further prove your possible theory of the USB-UIRT needing to be used for reception:

Schedule an unattended wake-up, and after the wake-up occurs but before the PC shuts back down, send a signal into the USB-UIRT with the remote (possibly a key that isn't programmed to do anything). Does this make a difference?

-Jon

[perf]

I was wrong. If I use the USB-UIRT for some reception during the scheduled recording, it still does not work after the computer has suspended. The computer needs more interaction for the problem not to appear after suspend.

Can I do any other testing?

/Per

[perf]

FYI: I have now switched OS to Windows XP, with the latest USB patch

http://support.microsoft.com/?kbid=822603

and using the registry hack mentioned in

http://65.36.202.170/phpBB2/viewtopic.php?t=92

now everything works as it should. (And the system works much smoother overall with Win XP than with W2k.)

/Per