Oz3.5.3 (collie) On/off Button Problem

[ironstorm]

I'm sorry, but I don't think that will change anything. At the moment, we don't have any developers left to look into the suspend/resume issues. I'm afraid that someone outside the core team will have to look into this bug.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=85138\"][{POST_SNAPBACK}][/a][/div]

What is surprising is why this bug should creep in to OZ in the first place.
....
 
Its unlikely that this could be a kernel bug, as i am assuming that no one has done any changes to the ancient kernel 2.4.18-rmk etc which is in use on collie for a long time. So if we use the same kernel that is used for a previous OZ release (3.5.2) we should be able to see if the bug occurs in it too. [div align=\"right\"][a href=\"index.php?act=findpost&pid=85169\"][{POST_SNAPBACK}][/a][/div]

@Mickeyl: what's cookin' (3xxx series?, nokia 770?)?  Know anyone in Toronto with a Z serial cable I could borrow?  

@weasel123:
While I shared your surprise about it creeping in, I don't agree that it's probably not the kernel...   I think there's quite a bit of patching that goes on to the baseline kernel to get support into it for everything required to run an 5xxx series Z...

It also probably wouldn't do you any good to flash an older kernel against OZ3.5.3 unless your are able to repack the FS with the kernel modules that go with it, you're best bet would be to see if you can dig up OZ 3.5.2 somewhere and just continue to run off that (or try the Qtopia 2.1 series ROMs)...

As far as solving it goes, it will probably be a bitch to trace what is happening on the Z without a serial cable to watch the kernel messages as it suspends.   (Any record of what happen disappears with a hard reset.)

[rsq]

I'm sorry, but I don't think that will change anything. At the moment, we don't have any developers left to look into the suspend/resume issues. I'm afraid that someone outside the core team will have to look into this bug.

And I'm afraid this is rather impertinent, as I don't have the skills to develop OZ myself, but I'm going to say it anyway:

Isn't there a problem with priorities here? I mean, this bug is going to affect every last user of OZ with a 5500d, 5500 or 5600. It cripples your OS by taking away fundamental functionality (power-on, alarm-clock, reliable time-keeping) What could be more important?

Disclaimer: I use OZ, I like OZ, I respect everyone's voluntary contributions, etc., etc., but there are already >90 posts in this thread. Someone had to say it.

[niv]

How about we pass the hat and contrib to get it fixed?

[malcolmxavier]

Today I am having a strange problem (actually, I've had it before but it's frequent today).  If I hold the Cancel button to suspend the Zaurus (as I always do) then usually it just suspends.  However, sometimes (more often than sometimes today) it will look like it's suspending, but only get halfway.  The screen is dimmed and the unit doesn't respond, but it's not completely suspended.  The only way to recover is a reset with the replace battery switch.

Is this a related problem?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=84271\"][{POST_SNAPBACK}][/a][/div]

I have been affected by this issue as well.  I will tell you that I have been  playing about with things and how I suspend.  Suspending with the menu, never works for me, it always seems to go to the "To-Do" appliaction.  However when I suspend with the cancel button it does suspend and return.  What I have noticed however, is that if I have anything in the CF slot it will not suspend properly, sometimes I get the dim screen sometimes it will freeze when I come back from suspend.  If I "eject" the card before I suspend, I have never had an issue. Could the issue be in the way the CF module interacts with the OS?  Just a thought.  

[schadfield]

I'm sorry, but I don't think that will change anything. At the moment, we don't have any developers left to look into the suspend/resume issues. I'm afraid that someone outside the core team will have to look into this bug.

And I'm afraid this is rather impertinent, as I don't have the skills to develop OZ myself, but I'm going to say it anyway:

Isn't there a problem with priorities here? I mean, this bug is going to affect every last user of OZ with a 5500d, 5500 or 5600. It cripples your OS by taking away fundamental functionality (power-on, alarm-clock, reliable time-keeping) What could be more important?

Disclaimer: I use OZ, I like OZ, I respect everyone's voluntary contributions, etc., etc., but there are already >90 posts in this thread. Someone had to say it.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=85305\"][{POST_SNAPBACK}][/a][/div]

I speak as someone who has tried OZ and given up on it as nothing more than a cool developers project. Its focus is not end users. It is of no use to end users.

If the Zaurus doesn't spiral into obscurity it will be on account of the efforts made by Sharp or Trolltech to develop an environment focussed on the needs of end users NOT on the OZ doodles.

Pat Volkerding can support a viable Linux distro for x86 by himself because he is focussed on producing a real product of use to other people. I have no idea what the OZ team are trying to achieve because it certainly doesn't appear to be a stable, user orientated environment for the Sharp Zaurus.

[Zauruman]

I speak as someone who has tried OZ and given up on it as nothing more than a cool developers project. Its focus is not end users. It is of no use to end users.

Nonsense. I can't hack to save my life but it does more than what I need it to (I use Hentges' roms as I find them to be better fitted to my needs). I  can understand that you may be frustrated with the speed of progress but all the chaps are working in their own time and doing a pretty good job of it. The suspend issue may be a little frustrating - I just remember to use my stylus to suspend it - not the end of the world and something I accepted when using OZ which is after all still in testing phase (correct me if I'm wrong on that).

[Gouri]

What is surprising is why this bug should creep in to OZ in the first place. This bug has not been in previous versions upto know.
The problem should be easy to trace,  its either a kernel bug or a bug in one of the programs that are running from the  filesystem(s).
 
Its unlikely that this could be a kernel bug, as i am assuming that no one has done any changes to the ancient kernel 2.4.18-rmk etc which is in use on collie for a long time. So if we use the same kernel that is used for a previous OZ release (3.5.2) we should be able to see if the bug occurs in it too.

Someone did it and the problem occured, see https://www.oesf.org/forums/index.php?showtopic=11948&st=75.

The kernel is reponsible for the stability of the system and peripherals (including power management). So when this fails, the kernel has to be corrected.

Nevertheless, some incorrect usage of some kernel API brought in by some recent change in OZ may have triggered a problem that was invisible before.

[koen]

Nevertheless, some incorrect usage of some kernel API brought in by some recent change in OZ may have triggered a problem that was invisible before.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=85496\"][{POST_SNAPBACK}][/a][/div]

After hearing the kernel people comment on the sharp kernels quality of code, I wouldn't be surprised if a proper, but different behaviour is being used which causes this bug.

[Mickeyl]

I have no idea what the OZ team are trying to achieve because it certainly doesn't appear to be a stable, user orientated environment for the Sharp Zaurus.

Excellent observation. The OZ people have fun working in their precious spare time on a Linux distribution for their Zaurus devices. We heard it's also of some use to others, that's why we make it available for free - oh yes and because of we believe in open source software.

I'm afraid if you want to have a stable, user oriented environment, you've got to work on one for yourself or pay someone else to do that. Open Source has always been

"I have an issue => I fix it => I make it available to others."

I'm sorry, but it never has been

"I do what pleases you".

Yes we try to fix bugs that get reported, however it is our precious spare time and there is no way that people like you define our priorities.

[nik42]

Hi,
I'm running 3.5.3 on my 5500 and just "downgraded" libapm1 to the version from 3.5.2. Now I'm able to suspend and resume with the cancel-button without the need to reboot (tested more than 10 times).
The "cursor-right-problem" is not solved by this. And I don't know if it introduces new problems.
Hope it helps

nik

[Mickeyl]

The cursor-right-problem definitly looks like a kernel bug to me. suspend/resume looks - like I suspected - like a race condition between the crappy embedix kernel code and the apm userland.

[marcan]

I am willing to help as much as I can on this problem. I've been testing with a current OE build of bootstrap-image. It suspends when pressing cancel, but if apmd is running and the device is there, it fails to resume and needs a battery swith flip (and then reboots). If I remove the device, it suspends properly but kills usbnet (because the suspend/resume scripts do not run). Killing apmd of course has the same effect.

[marcan]

Someone please confirm this: does the Z suspend with:

 - Cancel button
 - Right button
 - Center button
 - Menu button

I've been doing some testing - all those seem to trigger the suspend GPIO. And they all happen to be the outermost row on the extensible keypad  (misconfigured driver chip? The sleep input is a GPIO pin, which presumably is some special output from the keyboard scanner chip (LoCoMo?). It is being triggered by all buttons in that row, not only the Cancel button.)

EDIT: fixed. Patch is in bugzilla and was commited to OE tree. This bug was probably in the kernel for a while, but previous userspace behaviour probably overrode it.

[Hrw]

updated kernels are available in upgrades feed - grab then and reflash

[niv]

cool :-)