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