Input Lockup On Resume/wake With Rc9

[dvdrw]

I've been using pdaXrom since waaay back (awesome ROM, guys!)

anyway, earlier versions had an intermittent problem with the input panel and buttons all ignoring input when the device is turned back on from sleep.  this went away for some time with the new 1.1 work that has been going on.

however I moved to RC9 over the weekend and it now almost _always_ happens.  if I turn off the device (enter sleep mode), and turn it back on, X comes back, and it repaints whatever was on the screen, but all input (stylus or keyboard) is ignored.  I can turn the device off again with the power button, but that is it.  if I want to recover the device and make it usable again I have to do a battery pull and cold restart to get it working again.

I have two SL-C750s (large root partition, ext3 formatted SD card, lots of free space on both) and now have RC8 on one and RC9 on the other, and the RC8 version doesn't show the problem at all; whereas the RC9 is basically unusable...

any ideas?  I haven't hacked the init script yet to keep it from nuking the messages file at reboot, should I try that and add "klogd" to see if there are any messages from the kernel/something that might indicate what the problem is at sleep exit time?  or is there something else I should try?

thanks!

[dvdrw]

it seems the "sleep 1" following the "cardctl eject" in "/usr/bin/apm" (line 16) isn't long enough of a delay for one of my SanDisk CF wi-fi cards...  changing this to "sleep 2" fixes the problem.  perhaps this should be something noted in a FAQ or for RC10?

[Laze]

Anybody else have this issue - we will look into it right anyway now..

[dvdrw]

Anybody else have this issue - we will look into it right anyway now..
[div align=\"right\"][a href=\"index.php?act=findpost&pid=64835\"][{POST_SNAPBACK}][/a][/div]

hi laze,

actually by working with this more this evening, I found increasing the sleep time didn't completely help avoid the problem...it would still happen sporadically.

so I just spent a lot of changes and reboots and found that by removing the "cardctl insert" that follows the "$APM --suspend" in "/usr/bin/apm" this appears to have completely fixed it for me.

I noticed that on resume, another process already automatically does the effect of the "cardctl insert", so the one in the "resume" portion of this script is redundant.  perhaps having two done at the same time could cause conflicts that could hang things intermittently?

anyway, again, by removing this unnecessary "cardctl insert" from the "apm" script all is well (I've done 40-50 sleep/wake cycles and it hasn't hung once.)

best regards

[Laze]

Ok that might be right - will test it now.

[Alf]

Oh, you seem to have same problem I have with my C3000/zdebian as described here:

https://www.oesf.org/forums/index.php?showtopic=10517

If it is the same problem, it is a segfault of the Xvnc server, with no fall back to the console. I have now replaced the Xf4vnc that was installed with the more common vncserver from official Debian unstable repository, and the system seems stable now (for the moment... I will tell later if it is long-term stable).