| 11:25 | NotRelevant | I've managed to crash Linux on ARM (archlinux and xubuntu) with something like: grep -r -e ajadsoifjajfjasf / |
| 11:25 | NotRelevant | as a regular user |
| 11:26 | NotRelevant | can someone try it? |
| 11:33 | Coolgeek | I'm not at home, so no :p |
| 11:39 | rabeeh | NotRelevant: which distro? |
| 11:45 | wump | if you're doing that as root you may be grepping in some scary device node, or sys entry |
| 11:45 | wumpus | be sure to exclude those directories for a system-wide grep |
| 11:58 | NotRelevant | rabeeh: I tried on ArchLinux and Xubuntu. And as regular user |
| 15:06 | rabeeh | dv_: just figured out some issue with the 3.6.9 kernel on vmeta CPU utilization - |
| 15:06 | dv_ | oh? |
| 15:06 | rabeeh | http://www.solid-run.com/phpbb/viewtopic.php?f=11&t=1201&start=10#p6946 |
| 15:07 | dv_ | ! |
| 15:07 | dv_ | I will try this out ASAP |
| 15:07 | rabeeh | listener->event_count = event_count; |
| 15:07 | dv_ | btw: http://www.solid-run.com/phpbb/viewtopic.php?f=11&t=1241 |
| 15:08 | rabeeh | without that line, libvmetahal would poll a lot on an uncached registers that consumes the cpu to death |
| 15:08 | rabeeh | dv_: i'v seen it. great work |
| 15:08 | rabeeh | would you like me to unpack the packages.tar.gz for this job? |
| 15:08 | dv_ | hmm I am not sure about it. you see, I am a bit worried about mirroring |
| 15:09 | dv_ | all of these essential packages are hosted in only one place. would mirror not be a good idea? |
| 15:09 | dv_ | or are there legal issues? |
| 15:09 | dv_ | anyway, one big tarball is actually nice for services like dropbox |
| 15:09 | rabeeh | no worries about legal |
| 15:09 | rabeeh | we control the solidrun web site |
| 15:09 | dv_ | um ... but then again, no wait, thats actually nonsense I just noticed. |
| 15:10 | dv_ | keep the big tarball for now, I will give you a list of packages that would nice to have isolated out |
| 15:10 | dv_ | *extracted |
| 15:11 | dv_ | or would it be no problem to have the entire contents of the tarball lying around like that? |
| 15:13 | dv_ | ah - now I see what my worries were. the big tarball contains .deb packages and other tarballs - but the libgfx is not compressed. you would have lots of headers etc. lying around. so perhaps unpack everything except the libgfx directory (or make a tarball out of it) |
| 19:27 | rabeeh | dv_: 11% ? |
| 19:27 | dv_ | yes |
| 19:27 | rabeeh | 1080p? |
| 19:27 | dv_ | just video, no audio decoding |
| 19:27 | rabeeh | which bitrate |
| 19:27 | dv_ | video is 1080p |
| 19:27 | rabeeh | aah |
| 19:27 | rabeeh | ok |
| 19:27 | rabeeh | h.264? |
| 19:27 | dv_ | but with audio its something like 20% |
| 19:27 | dv_ | yes |
| 19:27 | rabeeh | nice :) |
| 19:28 | rabeeh | armhf |
| 19:28 | rabeeh | right ? |
| 19:28 | dv_ | http://www.sintel.org/download <- the mp4 1080p trailer |
| 19:28 | dv_ | yes, armhf |
| 19:29 | dv_ | with --march=armv7-a and -mfpu=vfpv3-d16 |
| 19:29 | dv_ | (-mfloat-abi=hard is added by OE automatically) |
| 19:30 | dv_ | also: the display is currently configured at 1024x768. so the image is getting downscaled. i do not know how much of an impact this has. |
| 19:35 | dv_ | note however that gst-ffmpeg (which is used for AAC audio decoding) isnt built with the iwmmxt code paths enabled, so it is slower than it could be. it is unfortunately not trivial to fix this, and other things had priority. |
| 19:50 | rabeeh | the downscale is done by hardware anyway; there wouldn't be any performance impact |
| 20:21 | dv_ | ah, okay. |
| 20:22 | dv_ | as for the cubox-packages.tar.gz tarball, keep it on the page please, but yes, you can unpack it. but watch out for the libgfx/ folder, which unlike the rest of the contents of the big package is not in its own tarball. |
| 20:29 | dv_ | oh, rabeeh , btw, what about xbmc? your fork is quite old now, and the arch PKGBUILD uses tons of patches: https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/xbmc-cubox-git/PKGBUILD |
| 20:29 | dv_ | so what do you know of the current situation? is vmeta support mainlined? |