[09:18] <lool> cwillu_at_work: It's in lucid now
[09:18] <lool> cwillu_at_work: I updated the bug, thanks
[09:19] <cwillu_at_work> lool, I noticed a bunch of neon stuff in pixman git head , mid/late december
[09:19] <cwillu_at_work> would those be included?
[09:24] <lool> cwillu_at_work: This bug only mentions earlier NEON bits though
[09:25] <lool> cwillu_at_work: We currently have upstream release 0.16.2
[09:26] <cwillu_at_work> which might have the neon stuff simply disabled, if I read the mailing lists correctly
[09:26] <lool> Apparently the latest release 0.16.4 is very similar to .2 and was out mid december
[09:26] <lool> cwillu_at_work: Sorry could you be more specific?
[09:26] <lool> Which NEON bits and which mailing-list?
[09:27] <cwillu_at_work> lool, a moment, just checking a head build
[09:27] <lool> Our pixman is from Sep 2009 so it definitely doesn't have anything from December commits
[09:32] <cwillu_at_work> head 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_work> doing a quick reboot to check a different display depth
[09:34] <cwillu_at_work> lool, 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:35] <lool> It should be sufficient to replace it, but it's not a good idea to replace the /usr/lib lib
[09:35] <lool> Install to /usr/local or create an updated pixman .deb
[09:35] <cwillu_at_work> yep
[09:35] <lool> Otherwise your changes will be lost wiht next upgrade
[09:35] <cwillu_at_work> not my first time around the block ;)
[09:37] <cwillu_at_work> well, first time around the block with pixman, but you know what I mean ;p
[09:40] <cwillu_at_work> giving lucid's a shot
[09:41] <lool> It's probably enough to update just libpixman-1-0 from a karmic install
[09:41] <cwillu_at_work> yep
[09:42] <cwillu_at_work> restarting x
[09:44] <cwillu_at_work> okay, looks like the relevant patches are in lucid's version
[09:45] <cwillu_at_work> or at least, I get the same display corruption under lucids as I did under head and on 0.15
[09:47] <lool> So you have a regression with NEON enabled pixmans?  Not an issue in 0.14.x?
[09:47] <lool> What's your hardware?
[09:47] <cwillu_at_work> lool, for reference, libpixman-1-0_0.16.2-1em1_armel.deb from emdebian.org doesn't have the display cheese
[09:47] <cwillu_at_work> while lucid's and head's does
[09:48] <cwillu_at_work> beagleboard
[09:48] <cwillu_at_work> nope, 0.14.x is fine
[09:49] <cwillu_at_work> running firefox, scrolling a relatively simple page.  I get squares of varying patterns obscuring the page as I scroll, different for each redraw
[09:49] <cwillu_at_work> the obscured sections appear to line up with the existing page items, and don't always obscure the entire item
[09:50] <cwillu_at_work> I can post a photo if that's useful
[09:52] <lool> cwillu_at_work: Looks like a toolchain issue
[09:52] <lool> Is libpixman-1-0_0.16.2-1em1_armel.deb patched in any way?
[09:54] <cwillu_at_work> no idea, it's just a random version I found on the web
[09:55] <cwillu_at_work> the head test was compiled on the board itself, not sure if that's relevant to toolchains
[10:01] <cwillu_at_work> (uploading images)
[10:02] <lool> cwillu_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 differ
[10:02] <cwillu_at_work> okay, yes, that's what I grabbed
[10:02] <lool> cwillu_at_work: Could you try rebuilding with gcc 4.3?
[10:02] <lool> (Was the default in Debian until recently)
[10:02] <lool> Either head or lucid's package
[10:02] <cwillu_at_work> k, that'll take a couple minutes
[10:04] <cwillu_at_work> photos at http://cwillu.com/files/arm/
[10:05] <cwillu_at_work> forgive the filesize, although the pattern is visible in the corruption at that resolution
[10:06] <lool> cwillu_at_work: So the red stripes are corruption?
[10:06] <cwillu_at_work> yes
[10:07] <lool> Oh and number 4 is pretty clear too
[10:09] <cwillu_at_work> the 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 up
[10:11] <cwillu_at_work> the colour, region, and direction of the pattern change (i.e., angled left vs right)
[10:11] <cwillu_at_work> and it's not clear in the photos, but the corruption begins and ends partway through a given horizontal line
[10:12] <cwillu_at_work> (build is running)
[10:12] <cwillu_at_work> hmm
[10:12] <cwillu_at_work> ./autogen.sh dies with "Illegal instruction"
[10:13] <cwillu_at_work> should I run gcc and company from karmic instead of lucid?
[10:13] <lool> Either should work
[10:13] <cwillu_at_work> (original head build was done with gcc from karmic
[10:14] <lool> But I'm interested in gcc-4.3's build result in any case
[10:14] <cwillu_at_work> well, autogen.sh doesn't even finish
[10:14] <lool> What's your kernel?
[10:14] <cwillu_at_work> one of rcn's
[10:14] <lool> Which upstream version?
[10:14] <cwillu_at_work> Linux overo 2.6.32.1-x1.0 #1 PREEMPT Thu Dec 17 02:23:37 UTC 2009 armv7l GNU/Linux
[10:14] <lool> That's quite good hmm
[10:15] <lool> cwillu_at_work: I'm a bit scared that you get an illegal instruction with lucid + custom 2.6.32
[10:15] <lool> cwillu_at_work: It's definitely another bug, but I'd like to take a look at that one too
[10:15] <lool> cwillu_at_work: Could you set -x autogen and see which command triggers that?
[10:16] <cwillu_at_work> yep, one sec
[10:18] <cwillu_at_work> autoreconf: configure.ac: tracing
[10:18] <cwillu_at_work> Illegal instruction
[10:18] <lool> cwillu_at_work: autoreconf -v should tell you what it's running exactly
[10:19] <cwillu_at_work> + autoreconf -v --install
[10:19] <cwillu_at_work> autoreconf: Entering directory `.'
[10:19] <cwillu_at_work> autoreconf: configure.ac: not using Gettext
[10:19] <cwillu_at_work> autoreconf: running: aclocal
[10:19] <cwillu_at_work> autoreconf: configure.ac: tracing
[10:19] <cwillu_at_work> Illegal instruction
[10:21] <cwillu_at_work> hmm, that might have been a redherring
[10:21] <lool> ?
[10:21] <cwillu_at_work> what's the right way to use 4.3 instead of 4.4?
[10:21] <lool> CC=gcc-4.3 should work with most sources
[10:22] <lool> If you're building by hand; if you're building packages, you might have to -eCC or set it in rules instead
[10:22] <cwillu_at_work> one moment
[10:25] <cwillu_at_work> okay, things are proceeding now
[10:26] <cwillu_at_work> (I mean, why use an environment variable when I could just install gcc-4.3 and remove 4.4? :p)\
[10:29] <cwillu_at_work> make[3]: Entering directory `/home/cwillu/work/pixman/pixman'
[10:29] <cwillu_at_work>   CC     pixman-access.lo
[10:29] <cwillu_at_work>   CC     pixman-access-accessors.lo
[10:29] <cwillu_at_work>   CC     pixman-cpu.lo
[10:29] <cwillu_at_work>   CC     pixman-gradient-walker.lo
[10: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>&1
[10:29] <cwillu_at_work> make[3]: *** [pixman-gradient-walker.lo] Error 1
[10:29] <cwillu_at_work> make[3]: Leaving directory `/home/cwillu/work/pixman/pixman'
[10:29] <cwillu_at_work> make[2]: *** [all] Error 2
[10:29] <cwillu_at_work> lool,
[10:30]  * lool whistles
[10:30] <lool> cwillu_at_work: This is kind of unfortunate
[10:30] <lool> cwillu_at_work: You could do the reverse, build under sid + gcc 4.3 and then rebuild against gcc 4.4
[10:31] <lool> cwillu_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 Debian
[10:37] <cwillu_at_work> sorry, I'm confounding things
[10:37] <cwillu_at_work> ran make clean (which I could have sworn I ran before), and now the build proceedeth
[10:40] <cwillu_at_work> build finished, installing
[10:41] <cwillu_at_work> and restarting x...
[10:43] <cwillu_at_work> lool, rebuild under 4.3 still has corruption
[10:44] <cwillu_at_work> git head
[10:45] <lool> Hmm
[10:45] <cwillu_at_work> checkout 0.16.2 and rebuild?
[10:45] <lool> Yeah, it's probably safer to always use the same source
[10:48]  * cwillu_at_work rebuilds
[10:49] <cwillu_at_work> geez
[10:49] <cwillu_at_work> oh, no, good
[10:50] <cwillu_at_work> thought I had rebooted and did that last test against 4.4
[10:52] <lool> So lucid + gcc-4.3 pixman 0.16.2 works?
[10:52] <cwillu_at_work> hasn't finished building yet
[10:52] <cwillu_at_work> I wasn't sure if I had run head against gcc-4.3, but I had
[11:01] <cwillu_at_work> build finished
[11:05] <cwillu_at_work> lool, gcc-4.3 pixman 0.16.2 still has corruption
[11:05] <lool> Hmm
[11:05] <cwillu_at_work> this is on an otherwise largely stock karmic
[11:05] <lool> cwillu_at_work: Well you could try the opposite approach of starting from squeeze which has 4.3, and then rebuilding with 4.4
[11:06] <cwillu_at_work> lool, not sure I follow
[11:06] <lool> I don't quite know what else than gcc could cause a different in the runtime lib causing corruption
[11:07] <lool> cwillu_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.4
[11:07] <lool> cwillu_at_work: Does that make sense?
[11:07] <cwillu_at_work> okay, so I need a squeeze rootfs?
[11:08] <lool> yeah; just debootstrap it from beagleboard
[11:08] <lool> I'd guess you'll need around 400MB counting build-deps
[11:08] <lool> debootstrap squeeze /path/to/new-chroot
[11:08] <lool> (as root obviously)
[11:09]  * cwillu_at_work would have used fakeroot :p
[11:09] <lool> Then chroot into it and apt-get source pixman + apt-get build-dep pixman + apt-get install build-essential gcc-4.3
[11:09] <lool> s/4.3/4.4
[11:09] <lool> You mean fakechroot
[11:10] <cwillu_at_work> make any sense to use a git checkout of pixman instead of the apt-get source pixman?
[11:10] <lool> That's possible; it's a debootstrap variant; I don't usually bother fighting this additional layer  ;-)
[11:10] <cwillu_at_work> alternatively, should I redo my current work based on an apt-get source checkout?
[11:10] <lool> No, I recommend you stick to a single source, the Debian/Ubuntu source package
[11:10] <cwillu_at_work> (and what's the deb-src line for ubuntu ports anyway?)
[11:10] <lool> If 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:11] <lool> cwillu_at_work: deb-src for ports is just like deb
[11:11]  * cwillu_at_work points out that he's been using a git checkout
[11:11] <lool> i.e. http://ports.ubuntu.com/ubuntu-ports karmic main restricted universe multiverse
[11:11] <cwillu_at_work> hmm, I tried that, didn't work
[11:11] <lool> cwillu_at_work: Well you also said you have been using binaries from emdebian and that *these* work
[11:11] <cwillu_at_work> yep
[11:11] <lool> The deb line certainly works for me; did you apt-get update?
[11:11] <cwillu_at_work> just making sure you're not under the impression that I did something that I didn't do
[11:12] <cwillu_at_work> oh, probably not
[11:12] <cwillu_at_work> although I thought I did
[11:12] <cwillu_at_work> (if memory serves, it was the update that didn't like it)
[11:12] <cwillu_at_work> okay, so I'm going to debootstrap squeeze, and then build pixman from apt-get source
[11:13] <lool> Yup
[11:13] <cwillu_at_work> and in the mean time find out if my btrfs root is really as good at load-levelling as I hope it is :p
[11:13] <lool> You might also want to test squeeze's libpixman to be on the safe side
[11:13] <lool> load-levelling?  does that relate to wear-levelling?
[11:13] <cwillu_at_work> I'll snag it out of the debootstrap after it finishes
[11:14] <cwillu_at_work> sorry, wear-levelling is what I meant to say
[11:14] <cwillu_at_work> I always start by thinking "load-balancing, no that's not right, load-levelling, that's right"
[11:14] <lool> Not sure btrfs is what you want for wear levelling
[11:14] <lool> It usually causes more writes than other filesystems
[11:15] <cwillu_at_work> not a whole lot of good options for an sd card;  mounted with ssd_spread it seems to do a decent job
[11:15] <lool> Oh right, I remember there's an SSD mode in btrfs now
[11:15] <cwillu_at_work> has been for a while now actually
[11:15] <lool> Too bad we don't have the underlying flash device easily accessible   :-/
[11:16] <cwillu_at_work> btrfs generally provides some nice-to-haves
[11:16] <cwillu_at_work> compression is useful, although at some point I want to get it using lzo instead of gzip
[11:16] <cwillu_at_work> and the checksumming provides a nice way of telling when my sd cards are starting to go bad
[11:17] <lool> Doesn'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 tempted
[11:17] <cwillu_at_work> it would, although you can always remount without compress;  existing data stays compressed until you write to it
[11:17] <lool> Nice
[11:17] <cwillu_at_work> I've been using it on a couple machines with good backups, haven't run into anything scary yet
[11:18] <lool> What would be cool is per file or directory attributes to achieve compression or not
[11:18] <cwillu_at_work> not sure you can do that without a reboot currently though
[11:18] <lool> Like chattr's
[11:18] <cwillu_at_work> yep
[11:18] <cwillu_at_work> sub-volumes would allow it pretty easily
[11:18] <cwillu_at_work> (shares the storage pool, but mounted separately with whatever args)
[11:19] <cwillu_at_work> haven't played with that end of things yet though
[11:19] <cwillu_at_work> I've got a rootfs working, call me easily satisfied :)
[11:20] <cwillu_at_work> they 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 raid
[11:22] <cwillu_at_work> I'm also using a 1gb swapfile on that btrfs partition
[11:22] <cwillu_at_work> which I find kinda hilarious :)
[11:23] <cwillu_at_work> 2.0gb usage (including the 1gb swap file) ends up using 663mb on the card
[11:23] <lool> Oh nice
[11:23] <lool> So you get compressed swap for free
[11:23] <cwillu_at_work> that's the hilarious part :)
[11:24] <cwillu_at_work> _wear_levelled_ compressed swap for free :)
[11:26] <cwillu_at_work> the #beagleboard folks never seem impressed by that for some reason :p
[11:26] <cwillu_at_work> #beagle rather, but ya
[11:28] <kblin> nice
[11:28] <kblin> but what do you do that uses swap? :)
[11:29] <cwillu_at_work> I'm lazy about removing things from my image that I don't need
[11:29] <lool> 512 MB isn't that much for large builds such as oo.o or xulrunner and then at runtime GNOME + firefox is pretty big too
[11:29] <lool> At least IME
[11:30] <cwillu_at_work> kblin, I usually only have 10 megs or so in swap, although I have to figure that on a beagleboard gaining 10mb ram is a win
[11:30] <kblin> oh, right, compiling would do it
[11:30] <cwillu_at_work> well, I meant in normal usage
[11:31] <cwillu_at_work> browser session really
[11:31] <kblin> ah, my beagles run as headless servers :)
[11:32] <cwillu_at_work> I end up with 10 megs or so of used swap;  I haven't done much in the way of rigorous benchmarking
[11:32] <kblin> but at least on the revB, ram is a bit on the short side if I start up samba4 and bind
[11:32] <cwillu_at_work> the compression + ssd_spread is a win just for the storage, as long as the interface itself remains usable, which it does
[11:33] <cwillu_at_work> I basically see swap as the means by which I can extend my working set size
[11:33] <cwillu_at_work> firefox always ends up with a couple megs paged out with no visible delay in the ui
[11:33] <cwillu_at_work> so right there it's a win
[11:33]  * kblin nods
[11:34] <cwillu_at_work> re: compression of the filesystem, there's definitely a cost, although my particular use isn't heavy on the reads or writes
[11:34] <cwillu_at_work> I'm interested in an lzo compression to replace gzip though for that reason
[11:34] <kblin> I'm running a fileserver :)
[11:34] <cwillu_at_work> lzo being an order of magnitude faster than gzip on the compression side, and I think 50% quicker or so on decompression
[11:36] <cwillu_at_work> not even sure what a good way of benchmarking throughput would be in this case
[11:36] <cwillu_at_work> hard to get away from the data dependence
[11:43] <cwillu_at_work> I: Unpacking the base system...
[11:55]  * cwillu_at_work plans to head home after this finishes, and as such starts his car
[11:58] <cwillu_at_work> I: Base system installed successfully.
[12:00]  * cwillu_at_work grabs squeezes pixman
[12:04] <cwillu_at_work> lool, 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:05] <cwillu_at_work> lool, squeeze's binary package works without corruption
[12:07]  * cwillu_at_work waits for apt to finis
[12:17] <lool> cwillu_at_work: You might want to do a test rebuild before trying with 4.4 + squeeze
[12:34]  * cwillu_at_work waits for debian/rules to do its thing
[12:53] <cwillu_at_work> installing squeeze-chroot-built 4.3
[12:53] <cwillu_at_work> lool, ^
[12:55] <cwillu_at_work> lool, no corruption on 4.3, rebuilding with 4.4
[13:07] <cwillu_at_work> lool, incidently, it looks like a simple CC=gcc-4.4 works with debian/rules
[13:11]  * cwillu_at_work waits for 4.4 to build
[13:22] <cwillu_at_work> built, installing
[13:24] <cwillu_at_work> restarting x
[13:27] <cwillu_at_work> lool, still around?
[13:28] <cwillu_at_work> squeeze's 0.16.2-1 works fine (no corruption) against gcc 4.4 and 4.3
[13:29] <lool> Gah
[13:29] <lool> cwillu_at_work: Well I have no idea what part of the toolchain / build env breaks it then   :-(
[13:29] <cwillu_at_work> heh
[13:29] <cwillu_at_work> I'm going to do a build against the git tree, although I'm going to go to bed first
[13:29] <lool> The builddeps are pretty short
[13:29] <lool> Build-Depends: debhelper (>= 5), automake, autoconf, libtool, pkg-config, quilt
[13:30] <lool> It certainly is not one of these
[13:30] <lool> It could be binutils, but it would be kind of weird
[13:30] <cwillu_at_work> is there anything relevant to assembling the neon code?
[13:30] <cwillu_at_work> (the blit optimizations are handcoded iirc)
[13:30] <lool> yeah, the assembler is in binutils
[13:31] <lool> Oh right, it's manual assembly
[13:31] <lool> Well you could try installing Ubuntu's binutils under squeeze and see if that regresses the build
[13:31] <lool> But these quWe have 2.20-4ubuntu4 and squeeze/sid have 2.20-4, but we have some custom patches
[13:32] <cwillu_at_work> yep
[13:32] <cwillu_at_work> okay, I'll try that when I get back
[13:33] <cwillu_at_work> I have to play hockey in 8 hours, so it's time for bed :p
[13:33] <cwillu_at_work> thanks for the help, I'll poke you again