Leighton,<br><br>Also, it appears that using the remote to wakeup again in 2.6.17 isn't working. Ubuntu 6.06 was using 2.6.15, and the remote was no trouble to wakeup with. 2.6.17 it appears to not work, even after fiddling with enabling USB1 in /proc/acpi/wakeup.
<br><br>What else did you fumble with?<br><br>Thanks,<br><br>Mario<br><br><div><span class="gmail_quote">On 10/27/06, <b class="gmail_sendername">Mario Limonciello</b> <<a href="mailto:mario.mailing@gmail.com">mario.mailing@gmail.com
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Leighton,<br><br>I recently moved my myth frontend box up to edgy. This included a newer nvidia driver by default.
<br><br>Consequently, I am able to suspend with the nvidia module still loaded, but mythfrontend doesn't work with lirc after the resume. It seems the frontend process doesn't like loosing lirc for a little bit and then getting it back. Any workarounds for this?
<br><br>Regards,<br><span class="sg"><br>Mario</span><div><span class="e" id="q_10e8884830013055_2"><br><br><div><span class="gmail_quote">On 10/25/06, <b class="gmail_sendername">Leighton Brough</b> <<a href="mailto:brough@baremetalsoft.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
brough@baremetalsoft.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Leighton Brough wrote:<br>> "Nearly perfect" is exactly where I'm up to now as well. I find I get
<br>> occasional (hard lockup) crashes on resume from S3, and the playback of<br>> some recordings stutter after resume too. But it is probably only a<br>> matter of time before I get to the bottom of these since I've only had
<br>> it working like this for a few days.<br>><br>><br>For the archive:<br><br>I've got the resume from suspend-to-RAM going completely reliably now.<br>With a 2.6.18 kernel there is a bug whereby the reset timer hardware is
<br>not correctly re-synchronised with the restored state of the kernel on<br>resume. Consequently the kernel sometimes goes into a _very_ long loop<br>looking for the next tick which means it locks up hard. The workaround
<br>hack is:<br><br>echo jiffies > /sys/devices/system/clocksource/clocksource0<br><br>before suspending.<br><br>Strangely, I also needed to choose the QT painter in the frontend, as<br>the OpenGL one sometimes results in crashes on resume. Maybe this is
<br>also related to the clocksource too?<br><br>The playback issue is still there - I believe this is also due to the<br>same clocksource problem - resulting in broken frame timing. There are<br>changes in the 2.6.19 kernel which look like they should fix this.
<br><br>Leighton<br><br>_______________________________________________<br>mythtv-users mailing list<br><a href="mailto:mythtv-users@mythtv.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mythtv-users@mythtv.org
</a><br><a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users</a><br></blockquote></div><br>
</span></div></blockquote></div><br>