OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Angstrom & OpenZaurus => Topic started by: ronbus on April 14, 2005, 09:25:10 am
-
When I press the on/off button, collie goes to sleep but won't wake up again unless I flip the "replace battery" switch. I know this problem was documented in 3.5.2 but I thought it was fixed in 3.5.3-official. Does anyone else have this problem, or do I have something messed up. If it is something that I can fix--without building from OE--pleas let me know.
Thanks,
-Ron
-
I tried it a few times, it woke up each time.
-
When I press the on/off button, collie goes to sleep but won't wake up again unless I flip the "replace battery" switch.
...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=75135\"][{POST_SNAPBACK}][/a][/div]
I saw this yesterday with 3.5.3 after installing a number of packages but it woke up fine this morning.
-- sojourner
-
Are you sure the kernel flashed correctly?
Si
-
I loved 3.5.2 and 3.5.3 looks like it is better so far.
Thanks to the team.
I can confirm that this bug exists. Not all the time but whenever it has been swithced off for a while.
Everything flashed okay as far as I know.
Chas
-
Sorry I should have said oz 3.5.3 Opie 64/0
-
I have no idea what could cause that. Guess some kernel experts should take a look at that...
-
I should have been more specific, like charlie. The GPE version works fine, it only affects the OPIE version. I've also only tried the 64/0 version. I don't know if it is normal or not, but there is an odd message when it boots for the first time: something about a tainted kernel due to the sharp SD module?
I'm pretty sure the kernel flashed properly. The lights came on for a few minutes. The system info says 2.4.18-rmk7-pxa3-embedix-3.5.3.
I just reflashed to the OPIE 64/0 version and I had the same problem. However, I flipped the replace battery switch and rebooted, removed the SD card and CF card, hit the on/off button and it came back to life. I put the CF card in, it also worked fine. I took the CF card out, put the SD card in and it worked fine. I put both the CF and SD card in and....it still worked fine. I don't know what's going on but it seems to be working since I removed the CF and SD card and replaced them.
-
...
I can confirm that this bug exists. Not all the time but whenever it has been swithced off for a while.
Everything flashed okay as far as I know.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=75346\"][{POST_SNAPBACK}][/a][/div]
Ok, after my first post on this yesterday I am now seeing this every time I suspend. Not sure what the issue is. OZ 3.5.3 32-32 zImage w/Opie, md5sums checked out fine.
-- sojourner
-
...
I can confirm that this bug exists. Not all the time but whenever it has been swithced off for a while.
Everything flashed okay as far as I know.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=75346\"][{POST_SNAPBACK}][/a][/div]
Ok, after my first post on this yesterday I am now seeing this every time I suspend. Not sure what the issue is. OZ 3.5.3 32-32 zImage w/Opie, md5sums checked out fine.
-- sojourner
[div align=\"right\"][a href=\"index.php?act=findpost&pid=75358\"][{POST_SNAPBACK}][/a][/div]
Yup. I can also confirm that this bug exists. I just flashed my Zaurus last night, and since then, this has happened to me about 6 times. It's also probably woke up successfully about 6 times too. I'm using the Opie image and a 32/32 kernel.
If this only happens with the Opie image, could this really be an issue with the kernel build? If it is in fact, occurring only the Opie image, it's probably some other issue. Not that I know, I'm just suggesting...
I've had other instabilities with the Opie image in OZ before too. In OZ 3.5.2 and now in OZ 3.5.3, the entire desktop will die (processes go bye-bye - not running anymore) and leave the VT useless, assumedly after some program crash. Restarting Opie via remote login works fine at these points, but this is not an option at work. SysAdmin no-likey install software and USB networking on these boxen.
Anyhow, does anyone have a guess as to what is causing this On/Off button problem yet?
-
Confirmed. Suspending a collie with the "cancel" button freezes the device on resume
about 90% of the time. This has been the case for some time now.
Also pressing "right-arrow" for a few seconds will suspend the device, too and it won't wake up again.
-
Confirmed. Suspending a collie with the "cancel" button freezes the device on resume
about 90% of the time. This has been the case for some time now.
Also pressing "right-arrow" for a few seconds will suspend the device, too and it won't wake up again.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=75422\"][{POST_SNAPBACK}][/a][/div]
Now, since everyone's in agreeance, what do we about it? ;-) It's likely fixable, since the Sharp ROM doesn't have this problem.
Honestly, I'd love to try and fix this (and a whole host of other OZ bugs) myself. If I wasn't so busy coding at work, I might be inclined to dive in and help, but spare time is pretty slim. Now, if I had a better idea about where to look, I'd be more inclined to try and fix this myself. Without knowing where to look, and having never hacked at the OZ source code before, this would otherwise take a while.
Anyhow, another coding project is exactly what I need to get my girlfriend to kill me.
-
Confirmed. Suspending a collie with the "cancel" button freezes the device on resume about 90% of the time.
This is also confirmed now on the 5600 (OZ3.5.3-Opie)... about 90% of the time.
For a temporary fix that beats the reset method you can use the O-menu> suspend instead of the On/Off button... then the On button will bring it back on again.(works for poodle I haven't tried the collie yet with 3.5.3)
Greg
-
This 'fix' has been applied in the gpe-image for collie handhelds only - if you have problems resuming after suspend, try this:
-Remove the line containing /dev/apm_bios from /etc/device_table
-Reboot
If that doesn't fix things, I'm afraid I don't know. The problem, with collie at least, is a buggy apm implementation in the kernel - I will fix this as soon as I get a Zaurus serial cable (donations welcome!)
-
This 'fix' has been applied in the gpe-image for collie handhelds only - if you have problems resuming after suspend, try this:
-Remove the line containing /dev/apm_bios from /etc/device_table
-Reboot
...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=75463\"][{POST_SNAPBACK}][/a][/div]
Thanks for the info. I just made the change and will let everyone know how it goes...
-- sojourner
-
Well Cwiiis, thanks for the hint. It resolves also another bug a little bit. When you hold the cursor to right the Z goes to suspend. Before your hint it didnt resume after such a case and you had to use soft reset. Now it still goes to suspend but resumes by using the on/off button. This makes it much more useable.
Cheers,
Sam
-
This 'fix' has been applied in the gpe-image for collie handhelds only - if you have problems resuming after suspend, try this:
-Remove the line containing /dev/apm_bios from /etc/device_table
-Reboot
That also works for the poodle with Opie.
Thanks Cwiiis
Greg
-
Looks like it's working here too. :-D
Thanks Cwiiis!
-- sojourner
-
This 'fix' has been applied in the gpe-image for collie handhelds only - if you have problems resuming after suspend, try this:
-Remove the line containing /dev/apm_bios from /etc/device_table
-Reboot
...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=75463\"][{POST_SNAPBACK}][/a][/div]
Thanks for the info. I just made the change and will let everyone know how it goes...
-- sojourner
[div align=\"right\"][a href=\"index.php?act=findpost&pid=75472\"][{POST_SNAPBACK}][/a][/div]
Thus far, it seems to be working great for me.
Edit: I first put in the fix last night, and have suspended then resumed several times since then.
-
Well Cwiiis, thanks for the hint. It resolves also another bug a little bit. When you hold the cursor to right the Z goes to suspend. Before your hint it didnt resume after such a case and you had to use soft reset. Now it still goes to suspend but resumes by using the on/off button. This makes it much more useable.
Cheers,
Sam
[div align=\"right\"][a href=\"index.php?act=findpost&pid=75503\"][{POST_SNAPBACK}][/a][/div]
Yeah, it's more usable like this, but I really think that it should be removed from the build since it's a pretty annoying "feature". Holding down arrow keys to move your cursor around is a very common usage pattern for almost any user. Putting the PDA to sleep when an arrow key is held down sounds more like an April Fools prank then a feature. ;-)
-
Donate a Zaurus serial cable to me and I'll fix it for the next release (collie only I'm afraid, unless I get given a poodle too..)
-
Don't know how much this comment will help: I am using hentget T7 64/0 kernel and it displays the same "sleep on right arrow" so-called feature. This distro is using kernel 2.4.18 embedix-r15.
-
Has anyone figured out the permanent fix to this problem?
I removed the line that was suggested from the /etc/device_table file. However, I tried setting an alarm in the qpe-alarmclock package and the Zaurus didn't wake up at the time specified. When I turned on the Zaurus manually with the On/Off button 20 minutes after the alarm was scheduled to go off, the alarm sounded.
Also, now the thing doesn't suspend unless I actually press the On/Off button.
Any thoughts?
I'm using OZ 3.5.3 64-0 on my SL-5500.
Thanks,
--db
-
I had this problem in a really bad way when I first flashed the ROM. It got so bad I edited the boot scripts to stop using the timestamp because that was just resetting my clock every time I turned the thing on rather than using the correctly set h/w clock.
Weirdly, shortly after that the problem went away and it started working fine.
This happened to me with the previous ROM, too, but it only happened a few times before it fixed itself. Maybe there is something not being initialised correctly?
-
ok, this is weird. How come I never had this problem 'til the first time I tried it after reading this thread? Like watching the tape, it's the curse of the post
I can't get it to lock up again, though, even after suspending/resuming several times. So unless it happens again, I'll leave well enough alone.
weird
-
I have the same problem with holding right on the pad and the zaurus sleeps. Since I browse the web and play snes9x on the thing, it kinda sucks. Games are pretty much impossible to play in the state the button is in now, which is really unfortunate since otherwise this version of oz is really good in almost all other respects.
-kaplanfx
-
I started having the problem much more frequently so I applied the 'fix' on my poodle & have had no problems yet (other than the right -button suspend, which I can live with). thanks
-
I've gone back to 3.5.2 on my 5500 due to this problem.
I need to have reliable suspend and resume and until that's fixed in 3.5.3 I'll stick with 3.5.2.
-
Has anyone figured out the permanent fix to this problem?
I removed the line that was suggested from the /etc/device_table file. However, I tried setting an alarm in the qpe-alarmclock package and the Zaurus didn't wake up at the time specified. When I turned on the Zaurus manually with the On/Off button 20 minutes after the alarm was scheduled to go off, the alarm sounded.
Also, now the thing doesn't suspend unless I actually press the On/Off button.
Any thoughts?
I'm using OZ 3.5.3 64-0 on my SL-5500.
Thanks,
--db
[div align=\"right\"][a href=\"index.php?act=findpost&pid=76316\"][{POST_SNAPBACK}][/a][/div]
A better fix, for opie users (gpe users need not apply, obviously):
- Restore the apm_bios line in device_table
- From a console, run 'killall -9 atd'
That should make things better and alarms should still work (I think). If they don't, replace 'atd' with 'apmd'. If someone could test this and report back, that'd be nice.
-
Whaaaaaaaaaaaaaaaaat ? atd is in our Opie image?
-
I haven't installed at (yet) on my poodle, so the problem isn't coming from that (at least not for me).
-
Whaaaaaaaaaaaaaaaaat ? atd is in our Opie image?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=77097\"][{POST_SNAPBACK}][/a][/div]
Ah, perhaps not then... Maybe I should actually try this image before advising on it
-
I have this problem too, opie 32-0.
-
Well, all kind of things can happen. I can't confirm right now, but I know that atd really steps over apmd's toes, so we made both packages CONFLICTing each other. If atd managed to get into the base image, I'm not surprised that we have suspend/resume problems.
-
Well, all kind of things can happen. I can't confirm right now, but I know that atd really steps over apmd's toes, so we made both packages CONFLICTing each other. If atd managed to get into the base image, I'm not surprised that we have suspend/resume problems.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=77321\"][{POST_SNAPBACK}][/a][/div]
atd is not part of the opie image:
root@collie:~# find / | grep atd
root@collie:~#
-
Same issue's issues here. The little guy would not wake up *sometimes* after being put to sleep and the only way to get them up would be to flip the "replace" battery switch. I also get the suspend on holding "right". I've made the change to comment out the /dev/apm_bios line in the device table and things seem stable, but I still get the sleeping when holding "right". Is there some way I can help to figure out what's wrong?
Oz 3.5.3
SL-5500
root on SimpleTech 1Gb SD
Socket 10/100 CF
Netgear MA701 wireless CF
-
Yes, you could try to discover the instruction path from the keyboard driver to the suspend code by inserting printk's all over the suspicious places. This would help to find out where things are going wrong.
-
Hello everybody! I am the happy owner of a new to me collie, and I think the thing is awesome. I took me a few days of mucking around to figure out that the 32 meg SD card I bought was too small for what I wanted to do. A 128 does the job nicely, now running Hentges 3.5.3 quite happily. I do have a problem with the suspend issue though. I would like to play games and it kinda sux when I'm driving and reach down to seek ahead in xmms and the thing locks. I removed the apm line from the /etc/device_table file and the on/off button seems to work better now. Before that fix I had some luck fiddling with the buttons (press power, hold and release menu a few times, press ok, press power, life!), but that was diiiirty and it would be cool to avoid such methods.
I would love to help in any way I can, though I cannot afford to donate anything but time right now. Mickeyl: Wanna drop a hint as to where the printk's should go? I have not really moved out of my palm yet due to these issues so I can flash and reflash anything that won't make a brick. Would it be possible to replace (or cripple) apm with a dummy that catches and logs signals (from the keyboard?) but won't actually turn the unit off? Sorry if I am displaying my ignorance here. Other than the above, OZ + OPIE rocks so far.
Cheers
-Anthony
-
@cwiiis: How much does such a cable costs where you live? And do you have Paypal? Everybody having this problem could donate 5 or 10 €/$/... so we could get a working solutions and not just hacks ;-)
I'm willing to help buying you a serial cable for getting a better OZ. Anybody else?
PS for german readers: Was ist nun eigentlich mit zaurus.help4free.de? Ist oesf.org die neue, bevorzugte Plattform oder sind beide gleichwertig?
-
Summary :
-synthesis of symptoms seen on my zaurus, consequences of fix
-suggestion : use old kernel (of OZ3.5.1 ?) on OZ3.5.3 ?
Standard OpenZaurus setup freshly flashed from the release :
Zaurus SL-5500
2.4.18-rmk7-pxa3-embedix-3.5.3
Opie 1.2.0 Apr 8, 2005
upgrade on 07.05.2005
The "On/off button problem" is confirmed here, too. It's rather a suspend/resume problem. I normally use the suspend menu to stop the zaurus and the same problems happen.
* Symptoms :
-Z doesn't turn on quickly using the On/Off button. I have to insist, press several times and longer. It eventually goes on.
-Z doesn't always turn off when idle (has to be confirmed). Anyway, I had it hang several times, staying on and screen lit until battery runs out or I notice and switch to "replace battery", only way to switch it off (no touchscreen, no keyboard work).
-after suspend and resume, sometimes not always, inner keyboard and/or outer buttons don't work (not always both), but touchscreen does. I think that suspending again and re-resuming fixed the keyboard at least once (unsure)
-holding right button suspends here, too
-holding contextmenu button (to switch off backlight) suspends also
-clock problems
-tried apm -S and apm -s to suspend instead. Doesn't fix.
* Tried the fix about commenting apm entry in /etc/device_table and rebooted.
Fixes all problems above, but introduces new ones :
-Z doesn't turn off when idle.
-suspend menu doesn't work
-alarm can't wake the zaurus, they only wait and fire when I resume using the button
-apm -S or apm -s don't work
* Other information
Used OZ 3.5.1 before. Never had the problem. It appears after flashing OZ-Opie image.
MD5 ok, flashed again for other reason. Problem remains.
* Suggestion
I need alarms to ring on time so I can't afford the fix.
I'm considering reflashing only the kernel part to put the kernel that was part of OZ 3.5.1 . Anyone has advice about it ? Good idea ? Dangerous ?
(I have backup of all my data of course.)
* For the curious
I upgraded from 3.5.1 because
-Konqueror did not work well on 3.5.1 (crashed on page bigger than about 15k)
-dropbear sshd did not support key-based identification
-some minor issues with USB (7 seconds to configure is a bit long, transfers a bit slow about 160-200kbyte/s, I had 600kbyte/s two years ago with exact same hardware)
I'd like to have apache+php+mysql+konqueror working well as it dit in late 2003, will try again after fixing this problem.
Thank for any advice.
-
FYI. I've ran a few tests with the device_table fix & have noticed that with the fix applied the display backlight will turn off when it's set to, but then will come back on when after the same timespan, almost as if when the instruction is reached to suspend the process crashes/fails & the whole thing starts over. So the Z never does suspend by itself.
Of course without the 'fix' the Z will suspend as it's set to, but then I still get the lock up problem.
-
So far the problem is confirmed on the OPIE image, kernels 2.4.18-rmk7-pxa3-embedix-3.5.3 with 64-0, 32-32 and 40-24 (my case).
I tried a workaround : assigning to a long press of the "home" key an "off.desktop" that does
sh -c "echo 1 >/proc/sys/pm/suspend"
which fixes symptoms (I've let /etc/device_table with its original content).
It is handy but prevents alarms to wake up the Zaurus (showstopper for a PDA).
This problem seemed never to happen till openzaurus 3.5.1 included.
I'd be happy to test any new kernel and report.
-
I tried a workaround : assigning to a long press of the "home" key an "off.desktop" that does
sh -c "echo 1 >/proc/sys/pm/suspend"[div align=\"right\"][a href=\"index.php?act=findpost&pid=79564\"][{POST_SNAPBACK}][/a][/div]
I've implemented this workaround on my 5600 & IMHO it works better than altering the device_table 'cause at least my Z will suspend itself now. Thanks Gouri.
-
If it works for you, it's fine - however most people will notice problems when their suspend/resume scripts don't run.
Looks like I can't encourage people to find out where the problem exactly lays, instead of trying potentially dangerous hacks and workarounds :/
(No, I can't spend the time myself, because I even can't reproduce the problem with my hardware)
-
Looks like I can't encourage people to find out where the problem exactly lays, instead of trying potentially dangerous hacks and workarounds :/[div align=\"right\"][a href=\"index.php?act=findpost&pid=79591\"][{POST_SNAPBACK}][/a][/div]
I'd love to fix this problem & I'll do what I can, but I'll need guidance since I'm not a Z developer. What do you suggest? What tests can I run & what debugging info would be helpful?
-
A structured approach to fixing this bug would be to first learn how apmd and suspend/resume works on Linux, then trying to track the code path in kernel and userland, inserting printk() respectively printf() statements to see where exactly things differ from the way they're supposed to work.
Sorry if this is not detailed enough for you, but I'm not a kernel developer.
-
A structured approach to fixing this bug would be to first learn how apmd and suspend/resume works on Linux, then trying to track the code path in kernel and userland, inserting printk() respectively printf() statements to see where exactly things differ from the way they're supposed to work.
Sorry if this is not detailed enough for you, but I'm not a kernel developer.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79626\"][{POST_SNAPBACK}][/a][/div]
It's hard to tell if you're begin sarcastic or not , but I do understand. I may not be a Z or kernel developer, but I am a developer, so I do understand what you mean. It just requires some basic troubleshooting, which requires someone to be able to devote some time to it. Not an easy thing, I know.
So it's possibly a (mis)interaction between the kernel & apm? That makes sense. Are there any other known issues with apm right now? I've noticed that opie's been locking up on me quite a bit in the last day or so. I can ssh in & restart it, but if I'm not next to a pc, then I have to hard boot. Trying to figure out what changes I may have made to cause it. At first I thought it might have been the opie-networkapplet, I seem to remember some issue with that, but I removed it & no fix.
I wish I had the time to set up a development environment, grab the kernel sources & play around. Maybe one day. thanks Mickey.
-
I wish I had the time to set up a development environment, grab the kernel sources & play around. Maybe one day. thanks Mickey.
You could have a go at building with my QEMU virtual machine image of a bitbake build environment...
( see https://www.oesf.org/forums/index.php?showtopic=12564 (https://www.oesf.org/forums/index.php?showtopic=12564) )
-
I wish I had the time to set up a development environment, grab the kernel sources & play around. Maybe one day. thanks Mickey.
You could have a go at building with my QEMU virtual machine image of a bitbake build environment...
( see https://www.oesf.org/forums/index.php?showtopic=12564 (https://www.oesf.org/forums/index.php?showtopic=12564) )
[div align=\"right\"][a href=\"index.php?act=findpost&pid=79645\"][{POST_SNAPBACK}][/a][/div]
Interesting. So I could have a dev environment even on my 'doze box (it's all I have available)? kewl. I thought I'd have to get linux installed back on there first (which is yet another thing I want to eventually make time for anyway, after all).
I just may get into this game sooner than I thought. As soon as I can make time I'll give'er a whirl. thanks ironstorm.
-
I just may get into this game sooner than I thought. As soon as I can make time I'll give'er a whirl. thanks ironstorm.
I wouldn't waste your time till the devs get around to addressing the problem with the build system...
http://bugs.openembedded.org/show_bug.cgi?id=2 (http://bugs.openembedded.org/show_bug.cgi?id=2)
-
That's not the build system, that's one of the patches for a package built by the build system, and specifically for users wanting a uclibc based system.
As OZ hasn't moved to using uclibc yet - we still use libc like the rest of the world, but a later version thankfully - it won't make any difference (unless you want to build your own bleeding edge image and feed).
Si
-
I'm glad I stumbled across this topic now the suspend resume finally works, now I can give that reset button a rest.
Shame about this right arrow reset thing, personally I hadn't noticed it except for when playing the odd game. I wasn't sure what was causing it, I just though the game was crashing it lol.
-
I've filed a bug report about the problem, see
http://bugs.openembedded.org/show_bug.cgi?id=54 (http://bugs.openembedded.org/show_bug.cgi?id=54)
and add possible relevant comments there.
-
-Remove the line containing /dev/apm_bios from /etc/device_table
-Reboot
I did this and as noted by other people it fixes the on/off button problem, however the USB network will now only connect after a reboot. It will not reconnect after a suspend.
Any suggestions ?
samac
-
-Remove the line containing /dev/apm_bios from /etc/device_table
-Reboot
I did this and as noted by other people it fixes the on/off button problem, however the USB network will now only connect after a reboot. It will not reconnect after a suspend.[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=82753\")
You need to save & run the script from [a href=\"https://www.oesf.org/forums/index.php?showtopic=9765&st=0&p=60420&#entry60420]this message[/url] (read the whole thread for more info) & set up a desktop shortcut for it to make it painless to run. HTH
-
You need to save & run the script from this message (read the whole thread for more info) & set up a desktop shortcut for it to make it painless to run. HTH
I remember that thread, I even contributed very late to it.
I just restored the /etc/device_table as it is breaks more than it fixes, and I will just have to remember to suspend from the menu.
samac
-
I second that samac. At first it seems removing that line makes everything better but as time goes on you see how much stuff is failing to work.
Is there no way to remap what the buttons do?
-
Is there no way to remap what the buttons do?[div align=\"right\"][a href=\"index.php?act=findpost&pid=82959\"][{POST_SNAPBACK}][/a][/div]
I was wondering that too. Is there any way to at least disable the cancel button, or remap it so something else?
-
You need to save & run the script from this message (read the whole thread for more info) & set up a desktop shortcut for it to make it painless to run. HTH
I remember that thread, I even contributed very late to it.
I just restored the /etc/device_table as it is breaks more than it fixes, and I will just have to remember to suspend from the menu.
samac
[div align=\"right\"][a href=\"index.php?act=findpost&pid=82777\"][{POST_SNAPBACK}][/a][/div]
Foolishly, I seem to have deleted the /etc/device_table apm line, instead of commenting it out. I don't want to go through a complete reinstall to find out what it said, so could someone please post the line here? Thanks.
-
/dev/apm_bios c 660 0 46 10 134 - - -
it is just below the line /boot/var/empty
You will have to space it out so that it looks nice in the table.
samac
-
I'm running 3.5.3 with the GPE image, and the only problems I have suspending are that it doesn't lock the screen when I do it (even though I have the "lock screen on suspend" option set) and it won't wake up for alarms. Susending and waking up using the cancel key works every time, although the apm --suspend command doesn't work at all.
-
IIRC in GPE/OZ 3.5.3 the /dev/apm_bios line in /etc/device_table is either commented out or removed by default. If it's entirely missing you'll have to add it, but doing this will can also lead to the problem where the device won't come out of suspend if you use the cancel button to suspend it.
-
Nothing quite like replying to your own post. I've been looking at the suspend problem a little bit and just thought I'd put up some of my ideas so other people can shoot them down. Here is what I have found:
with /dev/apm_bios commented out (#/dev/apm_bios in /etc/device_table):
1) I can boot into a shell (init=/bin/bash) and suspend with the cancel button (To me that means that the Zaurus can suspend without any intervention from apm or needing to have apm_bios in the device_table)
2) apm --suspend returns without doing anything (ie apm can't suspend the zaurus)
with /dev/apm_bios uncommented (/dev/apm_bios in /etc/device_table):
1) If apmd is running, holding cancel button results in a suspend that I can't resume from
2) If apmd is not running apm --suspend does nothing, and I can suspend with the cancel button and resume without problems
3) as long as I suspend from the menu or by running apm --suspend from a terminal I can resume fine
What this problem seems like to me is apmd and the kernel stepping on each other's toes. If someone who has:
1) a 5500, 5500G or 5000D
2) that can suspend fine with the cancel button with apmd running, and /dev/apm_bios in /etc/device_table
Maybe you could run a couple of the tests I did and see what results you get? That might shed some light on this.
If anyone wants me to run tests/reflash and mess with different stuff I will. I'm in the process of setting up bitbake on a machine, and I'll start trying to track down the "right cursor causes suspend." No guarantees I'll find anything though, as I'm pretty bad with C and I'm not familiar at all with the inner workings of the kernel. :rollseyes:
-John
-
/dev/apm_bios is not commented out on mine (and I haven't changed it from the default), however it exhibits the behavior that you describe as happening with it commented out. How odd.
-
Hmm...Well that is interesting. Could you see if apmd is running?
Update: I found this in the execution script for /etc/X11/Xserver:
# Horrible hack required to enable resuming after suspend
rm -f /dev/apm_bios
killall -9 apmd
Now I just need someone to tell me about the how a Zaurus that doesn't have these problems in the first place behaves with no apmd running.
-
Now I just need someone to tell me about the how a Zaurus that doesn't have these problems in the first place behaves with no apmd running.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=83566\"][{POST_SNAPBACK}][/a][/div]
Wait, I don't quite understand what you need tested... My 5500 seems to have pretty much the same issue; with the apm_bios line in, it won't resume after suspend about 25% of the time. You're looking for someone with a 5500 who can suspend/resume consistently with the line in?
This would mean I can't help... but if I got it mixed up and I have what you need, I'd be happy to
-
Hmm...Well that is interesting. Could you see if apmd is running?
Update: I found this in the execution script for /etc/X11/Xserver:
# Horrible hack required to enable resuming after suspend
rm -f /dev/apm_bios
killall -9 apmd
Now I just need someone to tell me about the how a Zaurus that doesn't have these problems in the first place behaves with no apmd running.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=83566\"][{POST_SNAPBACK}][/a][/div]
Aha, it would seem that on my machine, even though the /dev/apm_bios line in /etc/device_table exists, there is no apmd running and /dev/apm_bios doesn't exist (which would explain the error that apm -s gives - Cannot open APM device: No such file or directory).
-
Penguin Man: Exactly, I didn't remember correctly how apm was diabled in the GPE release. I thought it was by commenting out the line in /etc/device_table but it must be through that little script that runs as part of X startup.
You're looking for someone with a 5500 who can suspend/resume consistently with the line in?
Fray: Thanks for the offer. Unfortunately, you're correct. Some people seem to have no problems at all suspending the 5500 with the /dev/apm_bios line in /etc/device_table. One of those people is Mickeyl, one of the main OZ developers. And since he can't reproduce the crash he can't fix it.
On that note: I've been trying to get my Zaurus to do the "resume of death" all afternoon and now for whatever reason it seems to be working fine. Bah. I might reflash back to a base OZ 3.5.3 image soon in hopes of getting it to show up again so I test some other things...
-
Isn't a 5500 a 5550? They didn't put any different software in did they if not then theres probably something running that's causing the problem. Perhaps it's something to do with my wireless card or some taskbar apps I have open? I'll have to mess about with my Z disabling/enabling various things, I'll let you know if I come across anything interesting.
-
As this appears to be pointing towards an apm problem, I called up the PID for apm found this line
/usr/sbin/apmd -P /etc/apm/apmd_proxy --proxy-timeout 30
and killed it.
My Zaurus could then suspend and resume from the on/off button.
Suspend with the right arrow and resume from the on/off button.
Suspend from the menu and resume from the on/off button.
All would seem to be fixed with a simple command, but all was not well in the land of Zaurus.
Upon resume I could not connect to the Z from my slackware box, it appears to effect the network connection in some way, because normally I just have to give my usb port an IP address and a route and I have connection.
With apm suspended I would have to manually start the network at the zaurus side as per the thread here:
You need to save & run the script from this message (read the whole thread for more info) & set up a desktop shortcut for it to make it painless to run. HTH
Why would Power Management effect networks?
samac
-
Re: samac killing apmd causing usb network problems
I have left my device_table at 'factory default' & apmd is still running & I always have to restart my usb modules after disconecting from my desktop without rebooting. So at least in my case the two don't seem to be related.
-
Strange I only have to do this on the desktop side
ifconfig usb0 192.168.0.4 netmask 255.255.255.0 up
route add -host 192.168.0.5 usb0and if I could be bothered I could probably add it in to my rc.hotplug script, and not even have to do that.
I have to do nothing on the zaurus side, could that be because I have set usbd0 to start automatically.
samac
-
Strange I only have to do this on the desktop sideifconfig usb0 192.168.0.4 netmask 255.255.255.0 up
route add -host 192.168.0.5 usb0and if I could be bothered I could probably add it in to my rc.hotplug script, and not even have to do that.
I have to do nothing on the zaurus side, could that be because I have set usbd0 to start automatically.[div align=\"right\"][a href=\"index.php?act=findpost&pid=83695\"][{POST_SNAPBACK}][/a][/div]
I could try that if my desktop was a nice, workable nix box. Unfortunately I use my Z on 2 stations, both 'doze (one 2000 the other XP).
Is the problem on the desktop side, even though the os's are different? Interesting. I'll try disabling then re-enabling the Z's network icon & see what happens.
[testing...]
Now it reconnects just fine (of course), even when I suspend/resume in between. Maybe I was imagining it all?? I don't think so. I'll do some more testing & report back.
-
Upon resume I could not connect to the Z from my slackware box, it appears to effect the network connection in some way, because normally I just have to give my usb port an IP address and a route and I have connection.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=83676\"][{POST_SNAPBACK}][/a][/div]
The USB networking can be resumed after suspending that way by calling /etc/apm/scripts.d/usbnet (as root of course). For the moment I'm perfectly happy suspending/resuming from the cancel key and running that script when I resume and want a network connection (I just setup a "resume usb" icon on my desktop so I can do it quickly).
-
On that note: I've been trying to get my Zaurus to do the "resume of death" all afternoon and now for whatever reason it seems to be working fine. Bah. I might reflash back to a base OZ 3.5.3 image soon in hopes of getting it to show up again so I test some other things...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=83646\"][{POST_SNAPBACK}][/a][/div]
It seems to happen more consistently when you have an app running, like -- bring up calendar, then suspend.
Also I think it helps to suspend and leave it suspended a long time before waking it up.
-
Hi all,
I have the same problem here with OZ 3.5.3 and 3.5.2 on a SL-5000D. OZ 3.5.1 has no such problems. Did some investigations, perhaps they help:
- Installed OZ 3.5.1
- Used OZ 3.5.3 feeds for all other install/updates
- Uninstalled all opie packages, libqpe1, libqte2, tslib
- Forced reinstall off libgcc2
- installed task-opie-base
After that, i got a (very basic) running version of Opie 1.2 on a 3.5.1 ROM.
Had the same Suspend/Resume Problem as described above.
Seems not to be a kernel/apmd problem...
What do you think?
Greetings,
Andreas
-
Ditto 5000d with oz3.5.3, my symptoms are that it will resume after pressing cancel button if done immediately but fails if left for some time.
-
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?
-
Is this a related problem?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=84271\"][{POST_SNAPBACK}][/a][/div]
Yes, the suspend/resume issues are all releated to broken APM/Kernel interactions and there is no reliable fix for the issue(s) other then to use something other then OZ3.5.3.
Edit: I should say this only effects collies (5000d/5500) AFAIK.
-
Edit: I should say this only effects collies (5000d/5500) AFAIK.[div align=\"right\"][a href=\"index.php?act=findpost&pid=84292\"][{POST_SNAPBACK}][/a][/div]
poodles too
-
I can confirm this error.
As an additional note, if the Collie is suspended with the suspend menu things appear to work.
Dan
-
As an additional note, if the Collie is suspended with the suspend menu things appear to work.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=84748\"][{POST_SNAPBACK}][/a][/div]
Sounds anecdotal to me... how many times have you done it successfully in a row?
-
ironstorm: I've never had it fail to come back from a suspend as long as I suspended from the menu. I think a better question would be: Has anyone ever suspended from the menu and had it fail fo resume with a press of the cancel key?
-
ironstorm: I've never had it fail to come back from a suspend as long as I suspended from the menu. I think a better question would be: Has anyone ever suspended from the menu and had it fail fo resume with a press of the cancel key?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=84767\"][{POST_SNAPBACK}][/a][/div]
I've 'never' had it fail to resume when suspended from the menu... (collie or poodle) with OZ 3.5.3-Opie.
Greg
-
I've 'never' had it fail to resume when suspended from the menu... (collie or poodle) with OZ 3.5.3-Opie.[div align=\"right\"][a href=\"index.php?act=findpost&pid=84774\"][{POST_SNAPBACK}][/a][/div]
My poodle has yet to fail to come back after suspending from the menu, whereas opie itself seems to lock up quite often when it suspends by itself (apm?). Of course when not next to a pc, that that requires a hard reset.
-
My poodle has yet to fail to come back after suspending from the menu, whereas opie itself seems to lock up quite often when it suspends by itself (apm?).
Hmm... I wonder what the difference in how suspend begins is... maybe we can use the menu's suspend method on an idle timer instead of apm...
-
I finally downgraded to OZ3.5.2 . Now my Zaurus is back to a usable state (the buggy state reminded me of Windows 95 :-p ). I had to add the missing "devel" feed to ipkg.conf for libstdc++ and could reinstall iqnotes and other useful apps.
If you can vote or comment on the bug report on
http://bugs.openembedded.org/show_bug.cgi?id=54 (http://bugs.openembedded.org/show_bug.cgi?id=54)
it might somehow attract more attention among openembedded developpers, at least going from NEW state to ASSIGNED.
Regards,
-
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.
-
deleted double post
-
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. 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.
I unfortunately have only a single CF card and i am afraid to change the kernel as if something goes wrong i would be left with a brick, with no way to reflash it
-
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.)
-
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.
-
How about we pass the hat and contrib to get it fixed?
-
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.
-
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.
-
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).
-
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 (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.
-
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.
-
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.
-
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
-
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.
-
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.
-
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.
-
updated kernels are available in upgrades feed - grab then and reflash
-
cool :-)
-
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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=85813\"][{POST_SNAPBACK}][/a][/div]
The same bug seems to exist on Poodle (sl5600) as well. I just tested it under OZ 3.5.2. It does not suspend, but on the main console window (vt1) I get messages from the powerirq_handler for all of these buttons.
-
The same bug seems to exist on Poodle (sl5600) as well. I just tested it under OZ 3.5.2. It does not suspend, but on the main console window (vt1) I get messages from the powerirq_handler for all of these buttons.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=86059\"][{POST_SNAPBACK}][/a][/div]
Yeah - the GPIO responsible for the suspend request was being triggered from all those buttons too. I checked and this behaviour was on earlier releases too (you can check by loading the registers module and monitoring the lowest bit of /proc/cpu/registers/GPLR). I added an extra test for a Cancel keypress (through the normal keyboard driver "pressed" matrix) and it works fine now.
I've been looking at the crash-on-suspend bug. It seems to be fixed after some changes (the original APM code is really horrid, there were some serious bugs), but now the usbnet driver (and then the whole kernel) seems to go down after the third suspend or so (if the script in /etc/apm/scripts.d is disabled, suspend/resume works fine). I'll have a look at that.
-
updated kernels are available in upgrades feed - grab then and reflash
[div align=\"right\"][a href=\"index.php?act=findpost&pid=86057\"][{POST_SNAPBACK}][/a][/div]
must I reflash?
-
you can reflash the kernel without the initrd.bin
-
Reflashing with just the zImage or zImage plus initrd.bin result in the same problem. See this thread 3.5.3 Upgrade Thread (https://www.oesf.org/forums/index.php?showtopic=11967&st=50)
It will then stop.
samac
-
5500 using opie :
ok second flash works, so far
I boot with the SD out of slot and cf in.
cf shows up , using the file manager I can't access it.
mmc doesnt even show up.
-
Niv
I cannot even get passed booting, even after re-downloading the zImage.
What zImage are you using, I am trying the 64-0.
samac
-
me too.
I think you should download the currnt zImage. its differnet me think
cooler startup screen :->
-
niv
I'm downloading from upgrades and the version number is:
http://www.openzaurus.org/official/unstabl...50627085413.bin (http://www.openzaurus.org/official/unstable/3.5.3/upgrades/zImage-collie-64-0-20050627085413.bin)
I can't see anything being newer than that.
samac
-
http://www.openzaurus.org/official/unstabl...50627085413.bin (http://www.openzaurus.org/official/unstable/3.5.3/upgrades/zImage-collie-64-0-20050627085413.bin)
if I aint mistaken
-
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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=85516\"][{POST_SNAPBACK}][/a][/div]
The package manager is the heart and soul of any Linux distro. IMHO you don't consider releasing even an early beta if the package manager isn't working. What use is an OS if the end user can't easily install and uninstall applications? Including those in the "feed" and under direct control of the distro he is using?
My experience of OZ is that the graphical installer is broken and is not even capable of installing packages from the OZ feed.
To be a credible Linux distro for the Zaurus OZ is required to support a much smaller range of hardware than a standard X86 distro. It also needs to support a much smaller range of user applications - just stable replacements for the Sharp ROM applications would be good start.
OZ + Opie fail on both counts.
-
hell, Ill just go out and say it: shut up!
do something - what use is it to complain here?
contrib - or but out
-
The package manager is the heart and soul of any Linux distro. IMHO you don't consider releasing even an early beta if the package manager isn't working. What use is an OS if the end user can't easily install and uninstall applications? Including those in the "feed" and under direct control of the distro he is using?
Hmmm...Looking at your signature information seems to somewhat minimize your argument:
SL-5500, Sharp ROM 3.13,
Windows XP Pro SP2,
Intellisync 3.2E, Outlook 2003.
Last I remember, Windows' package manager was at the mercy of the whatever programs get installed, and it is a constant fight against cruft. I'm not trying to start an OS war here, but you really need to either lend a hand or shut up. Your constant needling of the openzaurus developers is couterproductive.
And by the way, does your diatribe above mean that Slackware is not a real Linux distro?
My experience of OZ is that the graphical installer is broken and is not even capable of installing packages from the OZ feed.
There is always the command line. Whats so hard about ipkg install <package>? I have not used the gui package manager since I installed 3.5.3...Not because it is broken, but because the command line is generally quicker than a gui.
To be a credible Linux distro for the Zaurus OZ is required to support a much smaller range of hardware than a standard X86 distro. It also needs to support a much smaller range of user applications - just stable replacements for the Sharp ROM applications would be good start.
OZ + Opie fail on both counts.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=86232\"][{POST_SNAPBACK}][/a][/div]
Really? Then you object to Debian as well? Since we have tens of thousands of packages in our repository, does that mean we also fail as a credible Linux distro? Please go back to the Sharp forums.
--Storm
-
http://www.openzaurus.org/official/unstabl...50627085413.bin (http://www.openzaurus.org/official/unstable/3.5.3/upgrades/zImage-collie-64-0-20050627085413.bin)
if I aint mistaken
[div align=\"right\"][a href=\"index.php?act=findpost&pid=86116\"][{POST_SNAPBACK}][/a][/div]
I think the image is correct. I had the same problem but then I make a ctrl-c (I don't remember which combination is the correct one, but try 'calendar+c', 'fn+c' or even 'fn+shift+c') and the boot process continued. Then it stopped configuring the network and again I used "the magic" and finally the oz boot process finished ok. The bad news are the suspend process. Now, the right button doesn't trigger the suspend but I tried it with the menu option and I blocked the zaurus
-
First of all, thanks Hrw for having taken the time out of your schedule to give a whack at fixing the problems mentioned in this thread.
I have to say though, like ialiende, it takes two Ctrl-C (Calendar+c) to boot, and locks up on any suspend or halt.
It may be related to the kernel oops I logged at
http://www.codespell.com/user/web/kmsg (http://www.codespell.com/user/web/kmsg)
I know about as much about hacking kernels as I do picking up women, but if there's any scud work that'll make yours or anyone else's life easier, PM me.
-
Today I will update kernels to newer version - with one more fix for APM.
-
Today I will update kernels to newer version - with one more fix for APM.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=86415\"][{POST_SNAPBACK}][/a][/div]
I hate to break my own rule "keep replies on topic" but...
Does anyone know if the buzzer as dsp code is in this kernel?
Ie at one point someone had a driver to make the buzzer behave like a dsp device. You could play any sound over the buzzer(albeit very badly).
GPE doesn't seem to use the buzzer. I've taped a CF case containing cut down ear bud speakers onto the back of my Z just so the calendar alarms would work. This solution works but is UGGLY.
I'd really like to link /dev/dsp to the buzzer device and be happy....
(I included this one since hrw seems to be building the kernels for the 5500...sorry to be off topic)
(pps- THANKS HRW! It's awesome what you're doing. I'll pay $25 for a working SL-5500 64/0 kernel that supports buzzer/dsp and apm(reliably) and no right arrow suspend. Email me at bsaunder2002 somewhere yahoo com to collect.)
Bill
-
I'm pretty busy atm. but I will promise to take a look at reintegrating that buzzer thingy.
-
bsaunder2002: I can build that kernel for you - but you will loose alarm sound, keyclick, screen click sound.
-
The package manager is the heart and soul of any Linux distro. IMHO you don't consider releasing even an early beta if the package manager isn't working. What use is an OS if the end user can't easily install and uninstall applications? Including those in the "feed" and under direct control of the distro he is using?
Hmmm...Looking at your signature information seems to somewhat minimize your argument:
SL-5500, Sharp ROM 3.13,
Windows XP Pro SP2,
Intellisync 3.2E, Outlook 2003.
Last I remember, Windows' package manager was at the mercy of the whatever programs get installed, and it is a constant fight against cruft. I'm not trying to start an OS war here, but you really need to either lend a hand or shut up. Your constant needling of the openzaurus developers is couterproductive.
And by the way, does your diatribe above mean that Slackware is not a real Linux distro?
My experience of OZ is that the graphical installer is broken and is not even capable of installing packages from the OZ feed.
There is always the command line. Whats so hard about ipkg install <package>? I have not used the gui package manager since I installed 3.5.3...Not because it is broken, but because the command line is generally quicker than a gui.
To be a credible Linux distro for the Zaurus OZ is required to support a much smaller range of hardware than a standard X86 distro. It also needs to support a much smaller range of user applications - just stable replacements for the Sharp ROM applications would be good start.
OZ + Opie fail on both counts.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=86232\"][{POST_SNAPBACK}][/a][/div]
Really? Then you object to Debian as well? Since we have tens of thousands of packages in our repository, does that mean we also fail as a credible Linux distro? Please go back to the Sharp forums.
--Storm
[div align=\"right\"][a href=\"index.php?act=findpost&pid=86250\"][{POST_SNAPBACK}][/a][/div]
Firstly, comments about Windows package management are completely irrelevant. Windows XP is not a Linux distro - OZ is.
Slackware does have package management. It doesn't handle dependancies but it reliably installs and removes packages - particularly those distributed as part of Slackware.
Sharp made no mistake in not including a terminal app as part of the default installation for the original Linux based Zaurus line. A graphical installer is the correct solution for this class of devices. Use of the command line should not be required for basic administrative tasks on a device with a low resolution screen and a tiny keyboard.
The OZ/Opie graphical installer is broken. Installing packages from the OZ feed via the command line is extremely unreliable and usually requires trawling through the forums for fixes for each broken package.
Given how critical power managment is to the Zaurus line and package management is to any Linux distro I am amazed that anyone is prepare to push out releases with those key features broken yet still expects to maintain any credibility.
-
schadfield: ok you hate OZ. pls go away.
thanks,
-
hrw,
In regards to loosing somethings...
Am I correct in saying that "OPIE knows about the buzzer and the DSP but GPE does not"?
Also, do all Zauri (SL-xxxx and SL-Cxxx) have the buzzer?
Do they behave the same ie no internal speakers for the nice sounding dsp?
I can't believe that OPIE doesn't let you configure the destination for all of the different sounds.
(I really like OPIE but I hate the no X11 stuff...(yeah I've tried keypebble/xvnc and also Xqt but none of those are perfect).
(another side question - how come noone has compiled a fb for X11 so we could make OPIE run on top of X?))
Also OPIE's integration with the buzzer should be able to be faked if the buzzer is a true DSP right? That shouldn't be too hard...I think.
So hrw, yes I'd love the kernel with DSP buzzer, then GPE's calendar would work. If I get that I'll try to hack together some OPIE -> my hack -> buzzer DSP solution.
Bill
ps- I'm trying to follow 12 threads...I have NOT gotten one of your kernels to work yet hrw. (not complaining, I appreciate the builds, I'll keep testing)
-
This 'fix' has been applied in the gpe-image for collie handhelds only - if you have problems resuming after suspend, try this:
-Remove the line containing /dev/apm_bios from /etc/device_table
-Reboot
If that doesn't fix things, I'm afraid I don't know. The problem, with collie at least, is a buggy apm implementation in the kernel - I will fix this as soon as I get a Zaurus serial cable (donations welcome!)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=75463\"][{POST_SNAPBACK}][/a][/div]
Ummm... I tried the removing thing and I don't recommend anyone do it without knowing what it actually does. I tried it and all the keys became disabled. I have to reflash again.
-
I see mention of "fixed" images, but the images in updates are only Colle and C700.
The poodle definitely has the problem.
Possible new info:
1. If you set on AC power to not go into standby or reduced light, the unit never locks up.
2. If have found that if I suspend with the MENU and leave for an hour or more - then when I hit the Cancel button nothing happens. If I hit again - I see a reduced light screen where I left off. Nothing is responsive (keyboard or touch). The light goes to full brightness after a bit (apparently all by itself). If I hit cancel again, it will go off and never come back without a reset.
3. I am using Altboot to boot to image on SD.
-
schadfield: ok you hate OZ. pls go away.
thanks,
[div align=\"right\"][a href=\"index.php?act=findpost&pid=86529\"][{POST_SNAPBACK}][/a][/div]
I think we need more people like schadfield to tell the brutal truth around here.
-
schadfield: ok you hate OZ. pls go away.
thanks,
[div align=\"right\"][a href=\"index.php?act=findpost&pid=86529\"][{POST_SNAPBACK}][/a][/div]
I think we need more people like schadfield to tell the brutal truth around here.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=90520\"][{POST_SNAPBACK}][/a][/div]
We also need people to learn to either try the fixes mentioned in the bugtrackers or keep one thread per problem. Why do we have a zillion threads about the collie suspend problem in OZ?
-
We also need people to learn to either try the fixes mentioned in the bugtrackers or keep one thread per problem. Why do we have a zillion threads about the collie suspend problem in OZ?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=90539\"][{POST_SNAPBACK}][/a][/div]
koen,
Excuse me, but it appeared to me that this was in fact the proper forum to talk about this problem "Oz3.5.3 On/Off Button Problem".
I have indeed searched all over (Google and this forum) for solutions to my issues and have not yet found them. I have tried many of the solutions and tried to post which worked and did not. I have probably invested 35+ hours in trying to get OZ 3.5.3 to work on my Zaurus SL5600 and on SD which is the first time I have tried OZ.
You mention the bugtracker - I went there and it appeared to require an account to view anything and looked like it was for the developers (ala TestTrack, etc). If I am supposed to be using that, I will do so.
I am hoping to get OZ working well enough on my Zaurus to be useful and I will start developing some code for it to share. Although I have been developing code (including a lot of embedded code) for 36 years, I am new to the open source development community.
-
We also need people to learn to either try the fixes mentioned in the bugtrackers or keep one thread per problem. Why do we have a zillion threads about the collie suspend problem in OZ?
[div align=\"right\"][{POST_SNAPBACK}][/a][/div] (http://index.php?act=findpost&pid=90539\")
koen,
Excuse me, but it appeared to me that this was in fact the proper forum to talk about this problem "Oz3.5.3 On/Off Button Problem".
I have indeed searched all over (Google and this forum) for solutions to my issues and have not yet found them. I have tried many of the solutions and tried to post which worked and did not. I have probably invested 35+ hours in trying to get OZ 3.5.3 to work on my Zaurus SL5600 and on SD which is the first time I have tried OZ.
You mention the bugtracker - I went there and it appeared to require an account to view anything and looked like it was for the developers (ala TestTrack, etc). If I am supposed to be using that, I will do so.
I am hoping to get OZ working well enough on my Zaurus to be useful and I will start developing some code for it to share. Although I have been developing code (including a lot of embedded code) for 36 years, I am new to the open source development community.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=90548\"][{POST_SNAPBACK}][/a][/div]
This thread could be designated 'the place to be', but there are different threads on the subject, which is annoying to me, and confusing to users. This was no attack on you, just an observation how a forum confuses the hell out of people when they treat is a bug tracker.
The bugtracker for OZ is located at [a href=\"http://bugs.openembedded.org/]http://bugs.openembedded.org/[/url] , which is configured to send emails to the developer mailinglist to make sure the right people get to see it. It would be nice if the people on this forum (NOT the developers for a change) could update bugzilla once in a while with new information. That way everybody wins: people can share experiences on the forum, and usefull information ends up where it doesn't get lost (bugzilla).
The bugzilla entry in question: http://bugs.openembedded.org/show_bug.cgi?id=54 (http://bugs.openembedded.org/show_bug.cgi?id=54)
-
This thread could be designated 'the place to be', but there are different threads on the subject, which is annoying to me, and confusing to users. This was no attack on you, just an observation how a forum confuses the hell out of people when they treat is a bug tracker.
The bugtracker for OZ is located at http://bugs.openembedded.org/ (http://bugs.openembedded.org/) , which is configured to send emails to the developer mailinglist to make sure the right people get to see it. It would be nice if the people on this forum (NOT the developers for a change) could update bugzilla once in a while with new information. That way everybody wins: people can share experiences on the forum, and usefull information ends up where it doesn't get lost (bugzilla).
The bugzilla entry in question: http://bugs.openembedded.org/show_bug.cgi?id=54 (http://bugs.openembedded.org/show_bug.cgi?id=54)
[div align=\"right\"][a href=\"index.php?act=findpost&pid=90551\"][{POST_SNAPBACK}][/a][/div]
Well thank you sir - I will see if I can setup a development environment and see if that code fixes the problem for the poodle. From the looks of the development environment setup, that may take me a wee bit of time.
-
I just installed 3.5.3 on my poodle yesterday. I've read this thread, and it's great to see that the problem with the APM suspend has been partially resolved.
I've found the instructions at http://openzaurus.org/wordpress/2005/07/27...rnel-on-collie/ (http://openzaurus.org/wordpress/2005/07/27/howto-get-r21-kernel-on-collie/) for how to fix the problem on the collie. However, I don't know how that can help me, since I have a poodle.
Has anyone figured out how to repair the problem on an SL5600?
Thanks for the hard work, guys.
-
I just installed 3.5.3 on my poodle yesterday. I've read this thread, and it's great to see that the problem with the APM suspend has been partially resolved.
I've found the instructions at http://openzaurus.org/wordpress/2005/07/27...rnel-on-collie/ (http://openzaurus.org/wordpress/2005/07/27/howto-get-r21-kernel-on-collie/) for how to fix the problem on the collie. However, I don't know how that can help me, since I have a poodle.
Has anyone figured out how to repair the problem on an SL5600?
Thanks for the hard work, guys.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=93441\"][{POST_SNAPBACK}][/a][/div]
Here is the state of things as I see it. I have posted regarding these, but the current edition of the Hentges image is quite good - the suspend is a least mostly fixed. I still had a few problems but far far less. Unfortunately it does not work with the Socket WLAN Low Power card. Or at least I was never able to get it to. Apparently it has a bad copy of the Orinico in as a kernel load so it cannot be replaced.
The stock 3.5.3 image unfortunately also has a bad orinoco module but for a different reason. It does not have the spectrum_cs "in" it apparently. And of course it has the suspend issue.
So if you don't have a Socket WLAN card, I highly recommend the Hentges image.
But for me, since I need the unit for the next three weeks, I am going to have to go back to Sharp ROM - so I can get wifi. I have not had the time (due to working overtime at work) to try to setup a build environment which appears like it will take several days.
-
< snip >
The stock 3.5.3 image unfortunately also has a bad orinoco module but for a different reason. It does not have the spectrum_cs "in" it apparently. And of course it has the suspend issue.
So if you don't have a Socket WLAN card, I highly recommend the Hentges image.
< snip >
[div align=\"right\"][a href=\"index.php?act=findpost&pid=93452\"][{POST_SNAPBACK}][/a][/div]
My Socket LP CF works fine in my 3.5.3 Hentges Collie (5500). Do you have a 5600 (Poodle)? Just want to clarify, since the OP was talking about the Collie APM problem (which Hentges has pretty much handled, as best I can tell).
- Ab
-
Sorry guys for the late reply ... but I have been on an extended journey out of the lower 48 and needed my Zaurus to work - so I loaded Watapon which worked great on my Poodle (SL5600 and Socket WLAN).
I will check back in on OZ eventually when I get a bit of time.
-
This 'fix' has been applied in the gpe-image for collie handhelds only - if you have problems resuming after suspend, try this:
-Remove the line containing /dev/apm_bios from /etc/device_table
-Reboot
...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=75463\"][{POST_SNAPBACK}][/a][/div]
Thanks for the info. I just made the change and will let everyone know how it goes...
-- sojourner
[div align=\"right\"][a href=\"index.php?act=findpost&pid=75472\"][{POST_SNAPBACK}][/a][/div]
How did it go? I'm seeing this problem 6 months after this thread so I guess that it hasn't been fixed yet.
I'm booting Opie from an SD card but the last flash I did was with GPE. I'll try this workaround and see what happens, did it work for you?
-
[span style=\'font-size:21pt;line-height:100%\']ARggghhhh![/span]
I hate users which are not able to read OpenZaurus homepage.
-
[span style=\'font-size:21pt;line-height:100%\']ARggghhhh![/span]
I hate users which are not able to read OpenZaurus homepage.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=97374\"][{POST_SNAPBACK}][/a][/div]
No need to get shirty!
I came across this while searching for something else. I hadn't really registered that the suspend issue was a bug as opposed to just something wrong on my machine so hadn't bothered doing any research into it to see how to fix it. Finding this post out of the blue made me realise that I wasn't the only one with the problem so I thought I'd respond. As the last poster said that they would try something and get back with results I just asked for their results.