Opie Dies - Not Responding To Input

[selektor]

SL-5500 running Hentges 64-0 Opie with the newest OZ kernel.
1G SD card - Viking

I have owned my Z for a little over a week now and have had this repeated problem of Opie becoming non-responsive yet the OS is still running. Today I was playing mp3s in xmms and when the playlist ran to the end Opie was locked up. No reponse to the touchpad or keys. I can put in my CF wifi card then shell in and reboot, but when Opie comes back up it is still not responding to any input.

This is the third time it's happened and I have only been able to fix it by reflashing the ROM.  

Did a just get a bad Z or is there a configuration within Opie that will prevent this (such as turning of the Doctab search thing)? I suppose if I can't find a way to fix this from the shell I need to look into RMAing it, which I really don't want to do.

Any suggestions?

 

[selektor]

Another thing to add:
The cancel key will still suspend the system and resume, though Opie excepts no input.

Some progress to report:
I did rm -rf  /home/root/* and rebooted. This put me throught the initial base config script and Opie was up. It's at least a relief to know I can get around this without a re-flash.

After reconfiguring a few things I tried to drop into the console with Logout. Opie would have none of that as it locked up again. From a remote shell I stop and start opie and it is responsive again. Again from the remote shell an attempt to reboot locked her up hard with considerable screen corruption requiring a hard reset from under the battery lid.  

It does suspend/resume nicely with this new kernel. I think I just need to find out what setting in Opie is borking this little tiger.    

[lardman]

I wonder if it would be possible to start Opie via ssh and then be able to see its output at the point where it hangs,


Si

[selektor]

Well, I had been starting and stopping Opie through ssh (that's what I refer to as a "remote shell"    ).  I did get some output but nothing I could relate to the problem.

I used it all evening and have been listening to mp3s today.... no problems at all since I wiped /home/root/* which basically reset Opie's configurations. What I did do was disable the 'autostart after resume' feature of the Today PIM app, which also had the weather plugin enabled. I also disabled the Doctab search feature.

All is well so far.

[lardman]

Doctab - hmm, this can make Opie appear to hang if it has to search a large disk, etc.


Si

[selektor]

I thought that too, lardman, since I have a 1G SD card. So once when it was 'locked' I stuck it in the cradle, ran some errands and and when I came back home it was still dead.

Does that Doctab feature work very well, in your opinion? How much time does it take to scan a drive? I always have some mp3 and avi in /mnt/card/Documents but I could never count on Doctab to list them. <shrug>

[lardman]

Does that Doctab feature work very well, in your opinion?

I don't use it, nor do (m)any of the developers afaik - what it could do with is someone who's interested in having a Documents tab of some sort to give it an overhaul - for one thing, the fact that it locks up (and the same goes for the Sharp 'ROMs') while scanning is not acceptable imho.

Personally I think the idea is not too bad (for those who just want to use the machine), but I'd also like to see the same kind of tab as the Sharp 3.xx 'ROMs' have with a file browser, previews, etc.


Si

[selektor]

The system locked up again last night while attempting to stream audio in xmms.  Like before, after a switch reset (reboot) Opie does not respond.

This morning I'm thinking, right, rather than a shotgun approach of removing the whole of /home/root, I would boot into the console (selection 3 in Hentges boot menu) and methodically rename the directories there until Opie works. I would do the Settings dir last to save the hassle of reconfiguring everything. So I first  rename Applications, start Opie from the console,  and  Opie's working again.  Sorted!  

So now I know there is a file within /home/root/Applications that keeps Opie from starting up properly, and that it's happened twice after xmms has hard-locked  the system.

Nearly there.

Is xmms notoriously wobbly in OZ or am I just having bad luck?

[selektor]

Alright then, to see if I could systematically break Opie I would begin to copy directories over from the saved Application dir to the newly created one. Opiemail had the most files in it so I copied it over first. So I dropped into the console with Logout and restarted Opie /etc/init.d/opie start.

Opie comes up but does not repspond to input.  

Perhaps there is a switch within opiemail I need to turn off.  

[lardman]

/home/root/Applications ??

This should just provide the .desktop file which produce the icons on the screen - the settings should be in ~/Settings

I can't think why opie-mail would cause any failure if you've not run it - but perhaps it's set with fast-load on - hold down the stylus on the icon until the dialog pops up.


Si

P.S. If you edit (I'd save a copy though) the /etc/init.d/opie script should be able to produce more output info - either by removing the daemon switch, or by running syslogd beforehand and then looking in logread via ssh

[selektor]

Well, my /home/root/Applications/opiemail has the email & news accounts stored there.  Check yours, I'm curious.

Removing the file from there smtp-0 fixes my Opie failures. Go figure.