/srv/irclogs.ubuntu.com/2010/01/02/#ubuntu-arm.txt

=== asac_ is now known as asac
loolcwillu_at_work: It's in lucid now09:18
loolcwillu_at_work: I updated the bug, thanks09:18
cwillu_at_worklool, I noticed a bunch of neon stuff in pixman git head , mid/late december09:19
cwillu_at_workwould those be included?09:19
loolcwillu_at_work: This bug only mentions earlier NEON bits though09:24
loolcwillu_at_work: We currently have upstream release 0.16.209:25
cwillu_at_workwhich might have the neon stuff simply disabled, if I read the mailing lists correctly09:26
loolApparently the latest release 0.16.4 is very similar to .2 and was out mid december09:26
loolcwillu_at_work: Sorry could you be more specific?09:26
loolWhich NEON bits and which mailing-list?09:26
cwillu_at_worklool, a moment, just checking a head build09:27
loolOur pixman is from Sep 2009 so it definitely doesn't have anything from December commits09:27
cwillu_at_workhead still shows some screen corruption of the same sort I saw on 0.15 (and don't on 0.16.2)09:32
cwillu_at_workdoing a quick reboot to check a different display depth09:32
cwillu_at_worklool, sanity check, is it sufficient to upgrade libpixman/replace /usr/lib/pixman-1-0.so, or does cairo or X or anything need to match it?09:34
loolIt should be sufficient to replace it, but it's not a good idea to replace the /usr/lib lib09:35
loolInstall to /usr/local or create an updated pixman .deb09:35
cwillu_at_workyep09:35
loolOtherwise your changes will be lost wiht next upgrade09:35
cwillu_at_worknot my first time around the block ;)09:35
cwillu_at_workwell, first time around the block with pixman, but you know what I mean ;p09:37
cwillu_at_workgiving lucid's a shot09:40
loolIt's probably enough to update just libpixman-1-0 from a karmic install09:41
cwillu_at_workyep09:41
cwillu_at_workrestarting x09:42
cwillu_at_workokay, looks like the relevant patches are in lucid's version09:44
cwillu_at_workor at least, I get the same display corruption under lucids as I did under head and on 0.1509:45
loolSo you have a regression with NEON enabled pixmans?  Not an issue in 0.14.x?09:47
loolWhat's your hardware?09:47
cwillu_at_worklool, for reference, libpixman-1-0_0.16.2-1em1_armel.deb from emdebian.org doesn't have the display cheese09:47
cwillu_at_workwhile lucid's and head's does09:47
cwillu_at_workbeagleboard09:48
cwillu_at_worknope, 0.14.x is fine09:48
cwillu_at_workrunning firefox, scrolling a relatively simple page.  I get squares of varying patterns obscuring the page as I scroll, different for each redraw09:49
cwillu_at_workthe obscured sections appear to line up with the existing page items, and don't always obscure the entire item09:49
cwillu_at_workI can post a photo if that's useful09:50
loolcwillu_at_work: Looks like a toolchain issue09:52
loolIs libpixman-1-0_0.16.2-1em1_armel.deb patched in any way?09:52
cwillu_at_workno idea, it's just a random version I found on the web09:54
cwillu_at_workthe head test was compiled on the board itself, not sure if that's relevant to toolchains09:55
cwillu_at_work(uploading images)10:01
loolcwillu_at_work: If you grabbed libpixman from http://emdebian.org/grip/pool/main/p/pixman/ then its exactly the same source as in Debian/Ubuntu and only toolchain differ10:02
cwillu_at_workokay, yes, that's what I grabbed10:02
loolcwillu_at_work: Could you try rebuilding with gcc 4.3?10:02
lool(Was the default in Debian until recently)10:02
loolEither head or lucid's package10:02
cwillu_at_workk, that'll take a couple minutes10:02
cwillu_at_workphotos at http://cwillu.com/files/arm/10:04
cwillu_at_workforgive the filesize, although the pattern is visible in the corruption at that resolution10:05
loolcwillu_at_work: So the red stripes are corruption?10:06
cwillu_at_workyes10:06
loolOh and number 4 is pretty clear too10:07
cwillu_at_workthe corruption changes from frame to frame, and not every frame is corrupted (in fact, I'd say only about a third of the frames are corrupted, although they can be bunched up10:09
cwillu_at_workthe colour, region, and direction of the pattern change (i.e., angled left vs right)10:11
cwillu_at_workand it's not clear in the photos, but the corruption begins and ends partway through a given horizontal line10:11
cwillu_at_work(build is running)10:12
cwillu_at_workhmm10:12
cwillu_at_work./autogen.sh dies with "Illegal instruction"10:12
cwillu_at_workshould I run gcc and company from karmic instead of lucid?10:13
loolEither should work10:13
cwillu_at_work(original head build was done with gcc from karmic10:13
loolBut I'm interested in gcc-4.3's build result in any case10:14
cwillu_at_workwell, autogen.sh doesn't even finish10:14
loolWhat's your kernel?10:14
cwillu_at_workone of rcn's10:14
loolWhich upstream version?10:14
cwillu_at_workLinux overo 2.6.32.1-x1.0 #1 PREEMPT Thu Dec 17 02:23:37 UTC 2009 armv7l GNU/Linux10:14
loolThat's quite good hmm10:14
loolcwillu_at_work: I'm a bit scared that you get an illegal instruction with lucid + custom 2.6.3210:15
loolcwillu_at_work: It's definitely another bug, but I'd like to take a look at that one too10:15
loolcwillu_at_work: Could you set -x autogen and see which command triggers that?10:15
cwillu_at_workyep, one sec10:16
cwillu_at_workautoreconf: configure.ac: tracing10:18
cwillu_at_workIllegal instruction10:18
loolcwillu_at_work: autoreconf -v should tell you what it's running exactly10:18
cwillu_at_work+ autoreconf -v --install10:19
cwillu_at_workautoreconf: Entering directory `.'10:19
cwillu_at_workautoreconf: configure.ac: not using Gettext10:19
cwillu_at_workautoreconf: running: aclocal10:19
cwillu_at_workautoreconf: configure.ac: tracing10:19
cwillu_at_workIllegal instruction10:19
cwillu_at_workhmm, that might have been a redherring10:21
lool?10:21
cwillu_at_workwhat's the right way to use 4.3 instead of 4.4?10:21
loolCC=gcc-4.3 should work with most sources10:21
loolIf you're building by hand; if you're building packages, you might have to -eCC or set it in rules instead10:22
cwillu_at_workone moment10:22
cwillu_at_workokay, things are proceeding now10:25
cwillu_at_work(I mean, why use an environment variable when I could just install gcc-4.3 and remove 4.4? :p)\10:26
cwillu_at_workmake[3]: Entering directory `/home/cwillu/work/pixman/pixman'10:29
cwillu_at_work  CC     pixman-access.lo10:29
cwillu_at_work  CC     pixman-access-accessors.lo10:29
cwillu_at_work  CC     pixman-cpu.lo10:29
cwillu_at_work  CC     pixman-gradient-walker.lo10:29
cwillu_at_work../libtool: line 970:  6075 Segmentation fault      gcc-4.3 -DHAVE_CONFIG_H -I. -I.. -g -O2 -Wall -fno-strict-aliasing -fvisibility=hidden -MT pixman-gradient-walker.lo -MD -MP -MF .deps/pixman-gradient-walker.Tpo -c pixman-gradient-walker.c -o pixman-gradient-walker.o > /dev/null 2>&110:29
cwillu_at_workmake[3]: *** [pixman-gradient-walker.lo] Error 110:29
cwillu_at_workmake[3]: Leaving directory `/home/cwillu/work/pixman/pixman'10:29
cwillu_at_workmake[2]: *** [all] Error 210:29
cwillu_at_worklool,10:29
* lool whistles10:30
loolcwillu_at_work: This is kind of unfortunate10:30
loolcwillu_at_work: You could do the reverse, build under sid + gcc 4.3 and then rebuild against gcc 4.410:30
loolcwillu_at_work: Basically, it's always the same source, so it's the build env which differs; I really suspect gcc here, and it just switched in Debian, but pixman did build with 4.3 in Debian10:31
cwillu_at_worksorry, I'm confounding things10:37
cwillu_at_workran make clean (which I could have sworn I ran before), and now the build proceedeth10:37
cwillu_at_workbuild finished, installing10:40
cwillu_at_workand restarting x...10:41
cwillu_at_worklool, rebuild under 4.3 still has corruption10:43
cwillu_at_workgit head10:44
loolHmm10:45
cwillu_at_workcheckout 0.16.2 and rebuild?10:45
loolYeah, it's probably safer to always use the same source10:45
* cwillu_at_work rebuilds10:48
cwillu_at_workgeez10:49
cwillu_at_workoh, no, good10:49
cwillu_at_workthought I had rebooted and did that last test against 4.410:50
loolSo lucid + gcc-4.3 pixman 0.16.2 works?10:52
cwillu_at_workhasn't finished building yet10:52
cwillu_at_workI wasn't sure if I had run head against gcc-4.3, but I had10:52
cwillu_at_workbuild finished11:01
cwillu_at_worklool, gcc-4.3 pixman 0.16.2 still has corruption11:05
loolHmm11:05
cwillu_at_workthis is on an otherwise largely stock karmic11:05
loolcwillu_at_work: Well you could try the opposite approach of starting from squeeze which has 4.3, and then rebuilding with 4.411:05
cwillu_at_worklool, not sure I follow11:06
loolI don't quite know what else than gcc could cause a different in the runtime lib causing corruption11:06
loolcwillu_at_work: All libs you used were built from the same source, but some have display corruption and some have not; I proposed changing the corrupted build env into a working one by using gcc 4.3, but that didn't work, we could try changing a working build env (squeeze) into a broken one by upgrading gcc to 4.411:07
loolcwillu_at_work: Does that make sense?11:07
cwillu_at_workokay, so I need a squeeze rootfs?11:07
loolyeah; just debootstrap it from beagleboard11:08
loolI'd guess you'll need around 400MB counting build-deps11:08
looldebootstrap squeeze /path/to/new-chroot11:08
lool(as root obviously)11:08
* cwillu_at_work would have used fakeroot :p11:09
loolThen chroot into it and apt-get source pixman + apt-get build-dep pixman + apt-get install build-essential gcc-4.311:09
lools/4.3/4.411:09
loolYou mean fakechroot11:09
cwillu_at_workmake any sense to use a git checkout of pixman instead of the apt-get source pixman?11:10
loolThat's possible; it's a debootstrap variant; I don't usually bother fighting this additional layer  ;-)11:10
cwillu_at_workalternatively, should I redo my current work based on an apt-get source checkout?11:10
loolNo, I recommend you stick to a single source, the Debian/Ubuntu source package11:10
cwillu_at_work(and what's the deb-src line for ubuntu ports anyway?)11:10
loolIf you change the source tree, you should redo all your tests to see which works and which don't (i.e. don't change multiple things at once)11:10
loolcwillu_at_work: deb-src for ports is just like deb11:11
* cwillu_at_work points out that he's been using a git checkout11:11
looli.e. http://ports.ubuntu.com/ubuntu-ports karmic main restricted universe multiverse11:11
cwillu_at_workhmm, I tried that, didn't work11:11
loolcwillu_at_work: Well you also said you have been using binaries from emdebian and that *these* work11:11
cwillu_at_workyep11:11
loolThe deb line certainly works for me; did you apt-get update?11:11
cwillu_at_workjust making sure you're not under the impression that I did something that I didn't do11:11
cwillu_at_workoh, probably not11:12
cwillu_at_workalthough I thought I did11:12
cwillu_at_work(if memory serves, it was the update that didn't like it)11:12
cwillu_at_workokay, so I'm going to debootstrap squeeze, and then build pixman from apt-get source11:12
loolYup11:13
cwillu_at_workand in the mean time find out if my btrfs root is really as good at load-levelling as I hope it is :p11:13
loolYou might also want to test squeeze's libpixman to be on the safe side11:13
loolload-levelling?  does that relate to wear-levelling?11:13
cwillu_at_workI'll snag it out of the debootstrap after it finishes11:13
cwillu_at_worksorry, wear-levelling is what I meant to say11:14
cwillu_at_workI always start by thinking "load-balancing, no that's not right, load-levelling, that's right"11:14
loolNot sure btrfs is what you want for wear levelling11:14
loolIt usually causes more writes than other filesystems11:14
cwillu_at_worknot a whole lot of good options for an sd card;  mounted with ssd_spread it seems to do a decent job11:15
loolOh right, I remember there's an SSD mode in btrfs now11:15
cwillu_at_workhas been for a while now actually11:15
loolToo bad we don't have the underlying flash device easily accessible   :-/11:15
cwillu_at_workbtrfs generally provides some nice-to-haves11:16
cwillu_at_workcompression is useful, although at some point I want to get it using lzo instead of gzip11:16
cwillu_at_workand the checksumming provides a nice way of telling when my sd cards are starting to go bad11:16
loolDoesn't it make your IO slower on beagleboard during builds when you're CPU bound?11:17
* lool didn't dare the switch to btrfs just yet, but has been tempted11:17
cwillu_at_workit would, although you can always remount without compress;  existing data stays compressed until you write to it11:17
loolNice11:17
cwillu_at_workI've been using it on a couple machines with good backups, haven't run into anything scary yet11:17
loolWhat would be cool is per file or directory attributes to achieve compression or not11:18
cwillu_at_worknot sure you can do that without a reboot currently though11:18
loolLike chattr's11:18
cwillu_at_workyep11:18
cwillu_at_worksub-volumes would allow it pretty easily11:18
cwillu_at_work(shares the storage pool, but mounted separately with whatever args)11:18
cwillu_at_workhaven't played with that end of things yet though11:19
cwillu_at_workI've got a rootfs working, call me easily satisfied :)11:19
cwillu_at_workthey do some braindead thing with df though:  df against the mountpoint of a btrfs raid reports the total capacity of the underlying storage devices, not the available space in the raid11:20
cwillu_at_workI'm also using a 1gb swapfile on that btrfs partition11:22
cwillu_at_workwhich I find kinda hilarious :)11:22
cwillu_at_work2.0gb usage (including the 1gb swap file) ends up using 663mb on the card11:23
loolOh nice11:23
loolSo you get compressed swap for free11:23
cwillu_at_workthat's the hilarious part :)11:23
cwillu_at_work_wear_levelled_ compressed swap for free :)11:24
cwillu_at_workthe #beagleboard folks never seem impressed by that for some reason :p11:26
cwillu_at_work#beagle rather, but ya11:26
kblinnice11:28
kblinbut what do you do that uses swap? :)11:28
cwillu_at_workI'm lazy about removing things from my image that I don't need11:29
lool512 MB isn't that much for large builds such as oo.o or xulrunner and then at runtime GNOME + firefox is pretty big too11:29
loolAt least IME11:29
cwillu_at_workkblin, I usually only have 10 megs or so in swap, although I have to figure that on a beagleboard gaining 10mb ram is a win11:30
kblinoh, right, compiling would do it11:30
cwillu_at_workwell, I meant in normal usage11:30
cwillu_at_workbrowser session really11:31
kblinah, my beagles run as headless servers :)11:31
cwillu_at_workI end up with 10 megs or so of used swap;  I haven't done much in the way of rigorous benchmarking11:32
kblinbut at least on the revB, ram is a bit on the short side if I start up samba4 and bind11:32
cwillu_at_workthe compression + ssd_spread is a win just for the storage, as long as the interface itself remains usable, which it does11:32
cwillu_at_workI basically see swap as the means by which I can extend my working set size11:33
cwillu_at_workfirefox always ends up with a couple megs paged out with no visible delay in the ui11:33
cwillu_at_workso right there it's a win11:33
* kblin nods11:33
cwillu_at_workre: compression of the filesystem, there's definitely a cost, although my particular use isn't heavy on the reads or writes11:34
cwillu_at_workI'm interested in an lzo compression to replace gzip though for that reason11:34
kblinI'm running a fileserver :)11:34
cwillu_at_worklzo being an order of magnitude faster than gzip on the compression side, and I think 50% quicker or so on decompression11:34
cwillu_at_worknot even sure what a good way of benchmarking throughput would be in this case11:36
cwillu_at_workhard to get away from the data dependence11:36
cwillu_at_workI: Unpacking the base system...11:43
* cwillu_at_work plans to head home after this finishes, and as such starts his car11:55
cwillu_at_workI: Base system installed successfully.11:58
* cwillu_at_work grabs squeezes pixman12:00
cwillu_at_worklool, sorry, you wanted me using gcc-4.4 under the squeeze chroot?  or should I start with the default, confirm that it works, and then do gcc-4.4?12:04
cwillu_at_worklool, squeeze's binary package works without corruption12:05
* cwillu_at_work waits for apt to finis12:07
loolcwillu_at_work: You might want to do a test rebuild before trying with 4.4 + squeeze12:17
* cwillu_at_work waits for debian/rules to do its thing12:34
cwillu_at_workinstalling squeeze-chroot-built 4.312:53
cwillu_at_worklool, ^12:53
cwillu_at_worklool, no corruption on 4.3, rebuilding with 4.412:55
cwillu_at_worklool, incidently, it looks like a simple CC=gcc-4.4 works with debian/rules13:07
* cwillu_at_work waits for 4.4 to build13:11
cwillu_at_workbuilt, installing13:22
cwillu_at_workrestarting x13:24
cwillu_at_worklool, still around?13:27
cwillu_at_worksqueeze's 0.16.2-1 works fine (no corruption) against gcc 4.4 and 4.313:28
loolGah13:29
loolcwillu_at_work: Well I have no idea what part of the toolchain / build env breaks it then   :-(13:29
cwillu_at_workheh13:29
cwillu_at_workI'm going to do a build against the git tree, although I'm going to go to bed first13:29
loolThe builddeps are pretty short13:29
loolBuild-Depends: debhelper (>= 5), automake, autoconf, libtool, pkg-config, quilt13:29
loolIt certainly is not one of these13:30
loolIt could be binutils, but it would be kind of weird13:30
cwillu_at_workis there anything relevant to assembling the neon code?13:30
cwillu_at_work(the blit optimizations are handcoded iirc)13:30
loolyeah, the assembler is in binutils13:30
loolOh right, it's manual assembly13:31
loolWell you could try installing Ubuntu's binutils under squeeze and see if that regresses the build13:31
loolBut these quWe have 2.20-4ubuntu4 and squeeze/sid have 2.20-4, but we have some custom patches13:31
cwillu_at_workyep13:32
cwillu_at_workokay, I'll try that when I get back13:32
cwillu_at_workI have to play hockey in 8 hours, so it's time for bed :p13:33
cwillu_at_workthanks for the help, I'll poke you again13:33
=== jmc93739653 is now known as jmc93739653_AWAY

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!