Release Hotfix 5 - Rc2. Last One Before Going Final

[EvilDragon]

HotFix 5 RC2 is finished. We've come a long way, and hopefully, most evil bugs have been squashed.
This will be the last one before the final - and maybe it already will be the final one.

It's still not in PND-form, so flashing this puts your Pandora back to the state you got it. Be sure to backup anything you put on the internal storage if you need it.
I'll work on making a PND-HF5-Installer for the final release.

Here are the changes that happened from Beta RC1 to RC2:

* Bugfix: libpnd - inotify was catching all modifications instead of closed-writable files. Thanks to Demitar for the catch!
* Various bugfixes and enhancements to the category / subcategory system of MiniMenu
* DaveC donated some nice folder graphics for the subcats in MiniMenu
* op_power.sh: Fixed a bug which crashed the script when going to low-power mode while connected to WLAN network
* Kernel: Set higher functional clock constraint. This allows hardware scaler to work with higher resolutions, allowing 720p video playback, for example.
* Various other small fixes!

In case you haven't checked them (or forgot about it) - here is the list of changes that happened from HF4

Spoiler

Fixes:
* LCD-Settings: Fixed the bug where the user could delete the default gamma setting
* Mass Storage Settings: Fixed a bug where it didn't remount the card under certain conditions
* First Run Wizard + Date / Time-Setting: Fixed timezone-selection.
* WiFi: New driver and firmware version with a lot of fixes (Yuri Ershov, notaz and Denis 'GNUtoo' Carikli)
* xf86-video-omapfb: Handle cycle/forcer events better
* Automount: Unmount from Thunar / XFCE4 is now possible
* Low-Power-Mode: Speed now set to 125 MHz (works more stable and doesn't use more power)
* Lid Closing: Disabled LCD Blanking, since that has issues with some programs
* Brightness-Buttons: Changed values so that the screen doesn't flicker anymore
* pnd_run: Lots of fixes and cleanups (sebt3)
* pnd_run: Fixed running of directories with PXMLs inside (Paul Brook)
* pnd_run.sh: Remove empty AUFS-Directories after unmounting (thanks to sebt3)
* U-Boot: Add WiFi reset on boot (fixes occassional power eating from WiFi Chip even if it was switched off)
* Fixed broken OPP after the unit crashed (patch by urjaman)
* Included latest SGX PowerVR drivers (thanks to notaz)
* MiniMenu: A lot of bugfixes and optimizations.
* omap3-sgx-modules: backport spinlock fix from omap3630 (thanks to notaz)
* mount.sh: Small optimization (changed rm to rmdir)
* MiniMenu: Now using only 3-4% CPU when idling
* Kernel: Various fixed, especially the errors when copying from one SD Card to the other one should be fixed (thanks to urjaman and notaz).

New Features:
* LCD-Settings: Added Video-FIR-Selector (current and default one)
* Applications: Removed Pidgin, Gnumeric, AbiWord, Clawsmail (use the PNDs for sebt3!)
* Applications: Added GCalcTool (Calculator)
* Tools: Added xdotool
* CPU-Speed: Now configurable using /etc/pandora/conf/cpu.conf or using the new CPU-Settings-Editor
* Pandora-State: Can now set a default CPU Speed during startup
* XFCE4: Enabled Icons in Startmenu, added Pandora-Splashscreen
* pnd_run: Script now popups a message if mount fails (sebt3)
* U-Boot: Pandora Menu: Always add serial option (for sure)
* Libraries: Added libsamplerate
* MiniMenu: Added new config options (i.e. do not quit on app run, remove detail panel, etc.)
* MiniMenu: Added Subcategories in the Grid (for quicker browsing).
* MiniMenu: Included OVR-Editor (so you can rename, move or change other settings of PNDs)
* MiniMenu: Added Directory Browser
* OS: Added Version number to Splashscreen

Download the latest version here.

How to flash the image?

Easy: Download the zipped image and extract the full contents onto the root of your SD Card.
Put the SD Card into slot 1 (the left one), switch on the Pandora while holding the R-Shoulder button and select "boot from SD1:1"

The flashing process should start. After it's finished, reboot the unit.
The first boot will take a while (up to 10 minutes). Patiently wait and you'll be greeted with the First Boot Wizard.

Additionally, we are currently organizing the Firmware development so that it's much easier to participate for everyone who wants to help and submit patches.
There's a mailing list, IRC, the boards, etc.

 

[fearofshorts]

This may not be very helpful as feedback (as I don't have my Pandy yet) but I just wanted to thank you, and all of the other devs, for continuing to improve the Pandora's OS.

 

[gruso]

+1

 

[goldenegg]

I don't know about anyone else, but I'm getting really slow transfer speeds trying to get this release. It says it's going to take 6 hours to complete. I guess I'll have to wait until the morning to give it a try

 

[Lorkile]

I hate to ask, but will it finally be automated that when I sink my bluetooth headphones I can set it to automatically output my audio via them whenever synced?

That minor bit aside, I really look forward to this update. So very many changes.

 

[goldenegg]

I've been playing with RC2 for about 12 hours or so. I'm still running in to random PND mounting issues, requiring a reboot to resolve. Here's an example error output.

sudo /usr/pandora/scripts/pnd_run.sh -m -p /media/PANDORA_SD1/pandora/menu/ComputerEmulators//ViceX64.pnd -e x64.gpe -b vicex64.pickle
not mounted on loop yet, doing so
LoopMountedon: 
losetup: could not find any free loop device

usedminor 1
freeminor 2
mknod: `/dev/loop2': File exists
losetup: /dev/loop2: device is busy
Filetype is Squashfs
Mounting PND (mount -t squashfs) :
/dev/loop2 on /mnt/pnd/vicex64.pickle type squashfs (ro)
Filesystem is vfat
Mounting the Union FS using /media/PANDORA_SD1/pandora/appdata/vicex64.pickle as Write directory:
mount -t aufs -o exec,noplink,dirs=/media/PANDORA_SD1/pandora/appdata/vicex64.pickle=rw+nolwh:/mnt/pnd/vicex64.pickle=rr none /mnt/utmp/vicex64.pickle
none on /mnt/utmp/vicex64.pickle type aufs (rw,si=6e80ec77,noplink)
none on /mnt/utmp/vicex64.pickle type aufs (rw,si=6e80ec77,noplink)
[------------------------------]{ App start }[---------------------------------]
/usr/pandora/scripts/pnd_run.sh: line 77: ./x64.gpe: No such file or directory
[-------------------------------]{ App end }[----------------------------------]

Usage:
 losetup loop_device                             give info
 losetup -a | --all                              list all used
 losetup -d | --detach <loopdev> [<loopdev> ...] delete
 losetup -f | --find                             find unused
 losetup -c | --set-capacity <loopdev>           resize
 losetup -j | --associated <file> [-o <num>]     list all associated with <file>
 losetup [ options ] {-f|--find|loopdev} <file>  setup

Options:
 -e | --encryption <type> enable data encryption with specified <name/num>
 -h | --help              this help
 -o | --offset <num>      start at offset <num> into file
      --sizelimit <num>   loop limited to only <num> bytes of the file
 -p | --pass-fd <num>     read passphrase from file descriptor <num>
 -r | --read-only         setup read-only loop device
      --show              print device name (with -f <file>)
 -v | --verbose           verbose mode

rm: missing operand
Try `rm --help' for more information.
cleanup done

 

[JDGBOLT]

If people want to try out the 720P video playback, you can try using the beta that me and EvilDragon worked on called PanPlayer, which is an optimized mplayer which will be able to play divx 720P content without breaking a sweat, probably a lot of them using the default cpu speed of 600 mhz. Has a nice picklelauncher frontend within in, including a feature that was added after I mentioned it to pickle, which is filtering by entering in a string, so you can type in who and it'll display only files with the word who within it. It can also play back a lot of SD resolution h264 files, though it depends how they were encoded, some work great at 600mhz, but others you have to overclock a bit to get them to work smoothly. Would like feedback on what kinds of videos play, how well, etc... Also in the post is just a standalone mplayer with binary that you can launch from the command line, if you wish to do it that way as well. The link it is located at is:

http://www.gp32x.de/board/index.php?/topic/58769-panplayer-beta/

Thanks for any feedback you have.

JDGBOLT

 

[kloplop321]

Is it just me? Or am I only able to open up like 5 PNDs total and then I run out of loop devices? (Add more please?), this includes toggling wifi, Chromium, DeadBeef, some other system utility, and Pidgin(which crashes like every 10 minutes...(Why?))
EDIT: Looks like goldenegg reports the same. This is a very urgent thing that needs to be fixed.

I also find how ridiculous it is in how to shut down the device, I have to do sudo shutdown -r now, or sudo restart.
Please change "Log out" on the panda menu to something more along the lines of "Power options", as the 2 out of 3 buttons are actually for power, as opposed to the 1 being for logging out.

Also... Why is the toggle WiFi a pnd? That's another loop resource that should not need to be taken up just for what can be accomplished with an sh script and or a binary.
It seems that more memory has to be used just for this toggle, why have all this overhead?

 

[Esn]

Looks like some people may be having trouble with software compatibility due to updated Qt libraries:
link (if I understood that correctly)

 

[meandu229]

Is it just me? Or am I only able to open up like 5 PNDs total and then I run out of loop devices? (Add more please?), this includes toggling wifi, Chromium, DeadBeef, some other system utility, and Pidgin(which crashes like every 10 minutes...(Why?))
EDIT: Looks like goldenegg reports the same. This is a very urgent thing that needs to be fixed.

I get the same thing after running a few PNDs.

 

[torpor]

I also think its silly to have things like toggling Wifi in a PND .. why is that?

 

[kloplop321]

In my own tests, and linux knowledge, I looked at the /tmp/pndrun_'s and the general consensus is: it runs out of memory.
Here's an example
I mount deadbeef: Ram was at 172, goes down to 148, so I'm like "okay", that's a little bit understandable.
I mount chromium: Ram was at 140(after loading songs), goes down to 20. I'm like: "this shouldn't take that much, on my desktop, chrome takes 35.5MB of RAM on start, this should use even less"
So I exit chromium, it jumps up to about 40 MB free, so "Where is all this other 100MB going?"

There seems to be a TON of memory overhead on just mounting the pnds.

I'm currently using swap(512MB) on an SD card, and things are going a lot more happy than before, however, this SHOULD NOT BE NECESSARY. (Especially if only using 3 basic programs like chat, music and browsing..)

 

[skeezix]

ED turned a bunch of short scripts into pnds, so that they show up for both mmenu and xfce; mmenu uses only pnd's as source of input (for now), not .desktops (that are generated from pnd.) (and yesm there are good reasons for this, its not arbitrary; consider, that mmenu can run entirely without anything else on the system, and .dedsktop files are missing some info; one of these day I'll make a .desktop alternative app pool source for mmenu so folks can togglr between, but its not there yet.)

A lo gets retrned to the pool when closed; you can onyl have so many pnds open at the same time, but just running one pnd in a row 30 times shoudl be no problem, unless that pnd is somehow hanging around and the loop is unable to be returned...

jeff

I know for instance than it in general works; I ran a single pnd about 30 times in a row just the other day, monitoring memory consumption (and all mem was returned to system on exit of it, btw.)

 

[torpor]

Well then, Houston, we have a problem: Memory is not being returned to the system after a few basic things, like wifi toggling, and so on. I just ran a few PND's, and oila: OOM.

 

[sebt3]

In my own tests, and linux knowledge, I looked at the /tmp/pndrun_'s and the general consensus is: it runs out of memory.
Here's an example
I mount deadbeef: Ram was at 172, goes down to 148, so I'm like "okay", that's a little bit understandable.
I mount chromium: Ram was at 140(after loading songs), goes down to 20. I'm like: "this shouldn't take that much, on my desktop, chrome takes 35.5MB of RAM on start, this should use even less"
So I exit chromium, it jumps up to about 40 MB free, so "Where is all this other 100MB going?"

There seems to be a TON of memory overhead on just mounting the pnds.

I'm currently using swap(512MB) on an SD card, and things are going a lot more happy than before, however, this SHOULD NOT BE NECESSARY. (Especially if only using 3 basic programs like chat, music and browsing..)

Do you know how linux memory work ?
I'm not using swap here, and I dont plan too. I'm pretty sure your swap is unused, or worst (because firefox and chromium tune their memory usage based on total memory) it is used to put some binary into swap while having a large cache of unused stuff.

It is normal to have no memory left displayed using top. If your OS dont use all your memory (at least for file-caching) then it's a stupid and bad OS (/me look at winxp...). Linux cache every file read operation into a memory space named "Cached" (see it's value in top). The linux kernel will kick out the last recently used buffer-cache to allocate new memory to programs. Currently I do have 140M of cache used on my pandora (most probably mp3 files, I do have zim, audacious, a console, gedit open). I see that as free memory (just being smartly used) with more than half of my memory basically free, I'm far from seeing a point of usinga swap...

 

[skeezix]

How are you checking RAM?

ie: use 'free' or 'top' you can see that RAM does not decrease; sometimes it goes to cached status, but its still available for use, no?

jeff

If there is a problem (may well be, who knows), then shoudl check if its also in HF4 (which probably is), and if so, HF5 can still go out and then can work on the issue for HF6. ie: No point in holding back everything for one (newly identified) issue. Better to ship, get all the patches and such out, and then work on it, imho.

However, if it is new in HF5, thats something.

edit: btw 'cached memory' _is_ returned to apps when needed; what it is -- when cachable resources like filesystems are hit, the data is put into memory for an app; if the app exits, the cached pages are still kept -- in case an app wants that same resouce and its cache friendly, there it is for free; but if an app needs to alloc RAM, and cache is taking up too much.. the system gives them that cached space and its nolonger in the cache; this is all kernel managed, invisible to the user. But 'free' and 'top' and other tools will show it.. so when peopel see "free ram" going down they often freak out.. but its not; "free + cache" == free.

 

[GroteBlup]

"free + cache" == free.

It's even worse: if you have "free" memory, you actually do not have free memory, you have UNUSED memory. Unused memory is a crime. Well, not completely because you need unused memory for kernel modules to load. So at least 4 MB should be unused on a server with 24G ram. If you have much more memory unused, your system is out of balance: you should uninstall some memory ;-).

You can get unused memory if an application exits, and it's heap is returned to the system. But it's executable code that is in memory will stay there, until it's needed again, or the memory is needed for something else.

OOM however are a different story: that means that there really was not enough memory. If you see an OOM in the dmesg, you should tell it, and especially the application maker/packager.
The system only has 256MB ram, and we are not running android, so sometimes it is necessary to use swap. Remember that the Nokia N900 (about the same chips) has about 800MB swap on the internal sd card.

 

[skeezix]

Some pnds are 'bad'; consider Powder which is set up badly..

Powder has a run-script like most pnds, but the powder main binary actualyl fork-and-exits for some reason; so the runscript runs and then neatly exits, and the poweder app keeps happily going. When the runscript exits, the system can't clean up the loopback or the like, since the app is still actually going, and so theres a leak.

Thats not a system/pnd fault, thats a packaging fault.. the packager didn't know the app does that goofy trick, and just didn't notice (since it does run okay, but doesn't exit properly later.) The packager needs to put a wait-loop in the runscript for odd ones like that.

But consider some pnds that can spawn servers (stay open forever), etc; those will cause what looks like 'mem leaks', but isn't really.. its just how the packager dedsigned it.

--

But if somethign like thw wifi-toggle pnd is losing real memory or loopbacks, then theres a problem.

--

I ran a couple pnd games 30 times in a row no problem just last week, to watch the RAM issue someone had reported (turns out it was just user not knowing what 'cached' was.)

But it could be a problem for certain pnds, or maybe a systemic issue that comes up in some scenario ..

jeff

 

[kloplop321]

Do you know how linux memory work ?
I'm not using swap here, and I dont plan too. I'm pretty sure your swap is unused, or worst (because firefox and chromium tune their memory usage based on total memory) it is used to put some binary into swap while having a large cache of unused stuff.

It is normal to have no memory left displayed using top. If your OS dont use all your memory (at least for file-caching) then it's a stupid and bad OS (/me look at winxp...). Linux cache every file read operation into a memory space named "Cached" (see it's value in top). The linux kernel will kick out the last recently used buffer-cache to allocate new memory to programs. Currently I do have 140M of cache used on my pandora (most probably mp3 files, I do have zim, audacious, a console, gedit open). I see that as free memory (just being smartly used) with more than half of my memory basically free, I'm far from seeing a point of usinga swap...

I know the following:
It should not be causing programs like pidgin to spam cannot allocate memory errors, sebt3, if they are just buffer caches

I know I am using swap because free reports the following:

kloplop321-pandora:~$ free -m
               total       used       free     shared    buffers     cached
  Mem:           243        165         77          0          0         76
  -/+ buffers/cache:         88        154
  Swap:          511         63        448

This is after running Terminal, Deadbeef, Chromium(3 tabs), pidgin, qOrganizer, and Mupen64(exited to see the free -m).
Earlier, it would die randomly on pidgin, in that order, after about 10 minutes.

Also, I was having issues with the whole system locking up with just fennec and wifi. I doesn't seem so now.

 

[sebt3]

I know the following:
It should not be causing programs like pidgin to spam cannot allocate memory errors, sebt3, if they are just buffer caches

I know I am using swap because free reports the following:

kloplop321-pandora:~$ free -m
                 total       used       free     shared    buffers     cached
    Mem:           243        165         77          0          0         76
    -/+ buffers/cache:         88        154
    Swap:          511         63        448

This is after running Terminal, Deadbeef, Chromium(3 tabs), pidgin, qOrganizer, and Mupen64(exited to see the free -m).
Earlier, it would die randomly on pidgin, in that order, after about 10 minutes.

Also, I was having issues with the whole system locking up with just fennec and wifi. I doesn't seem so now.

I learn something : mupen use 76M of memory. That's the freed memory when you closed it (and is still marked as cached).
With you current usage (Terminal, Deadbeef, Chromium(3 tabs), pidgin, qOrganizer), you still have 154M free memory (well 77M free + 88M cache) that's good for me.
What puzzle me is these 63M of swap used. My wild guess is that your swapiness is too high. Is your xfce menu slow on opening ?
If you remove the swap (and think that all this swap space is real memory usage, I dont but no proff so...) you still have 91M of free memory or 2/5 of total physical memory (or enough to have that mupen started on top of all your current apps).

In the end, I still dont think there is a memory issue and a swap should not be requiered

EDIT: but if you indeed have memory issues (aka OOM repported by dmesg) with pidgin, I would like to see the pndrun_pidgin.log file (which should also contain a message saying it was unable to allocate xk of memory) in the pidgin thread.