=== asac_ is now known as asac | ||
lool | cwillu_at_work: It's in lucid now | 09:18 |
---|---|---|
lool | cwillu_at_work: I updated the bug, thanks | 09:18 |
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:19 |
lool | cwillu_at_work: This bug only mentions earlier NEON bits though | 09:24 |
lool | cwillu_at_work: We currently have upstream release 0.16.2 | 09:25 |
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:26 |
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:27 |
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:32 |
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:34 |
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:35 |
cwillu_at_work | well, first time around the block with pixman, but you know what I mean ;p | 09:37 |
cwillu_at_work | giving lucid's a shot | 09:40 |
lool | It's probably enough to update just libpixman-1-0 from a karmic install | 09:41 |
cwillu_at_work | yep | 09:41 |
cwillu_at_work | restarting x | 09:42 |
cwillu_at_work | okay, looks like the relevant patches are in lucid's version | 09:44 |
cwillu_at_work | or at least, I get the same display corruption under lucids as I did under head and on 0.15 | 09:45 |
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:47 |
cwillu_at_work | beagleboard | 09:48 |
cwillu_at_work | nope, 0.14.x is fine | 09:48 |
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:49 |
cwillu_at_work | I can post a photo if that's useful | 09:50 |
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:52 |
cwillu_at_work | no idea, it's just a random version I found on the web | 09:54 |
cwillu_at_work | the head test was compiled on the board itself, not sure if that's relevant to toolchains | 09:55 |
cwillu_at_work | (uploading images) | 10:01 |
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:02 |
cwillu_at_work | photos at http://cwillu.com/files/arm/ | 10:04 |
cwillu_at_work | forgive the filesize, although the pattern is visible in the corruption at that resolution | 10:05 |
lool | cwillu_at_work: So the red stripes are corruption? | 10:06 |
cwillu_at_work | yes | 10:06 |
lool | Oh and number 4 is pretty clear too | 10:07 |
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:09 |
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:11 |
cwillu_at_work | (build is running) | 10:12 |
cwillu_at_work | hmm | 10:12 |
cwillu_at_work | ./autogen.sh dies with "Illegal instruction" | 10:12 |
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:13 |
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:14 |
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:15 |
cwillu_at_work | yep, one sec | 10:16 |
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:18 |
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:19 |
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:21 |
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:22 |
cwillu_at_work | okay, things are proceeding now | 10: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_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:29 |
* 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:30 |
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:31 |
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:37 |
cwillu_at_work | build finished, installing | 10:40 |
cwillu_at_work | and restarting x... | 10:41 |
cwillu_at_work | lool, rebuild under 4.3 still has corruption | 10:43 |
cwillu_at_work | git head | 10:44 |
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:45 |
* cwillu_at_work rebuilds | 10:48 | |
cwillu_at_work | geez | 10:49 |
cwillu_at_work | oh, no, good | 10:49 |
cwillu_at_work | thought I had rebooted and did that last test against 4.4 | 10:50 |
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 | 10:52 |
cwillu_at_work | build finished | 11:01 |
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:05 |
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:06 |
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:07 |
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:08 |
* 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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:22 |
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:23 |
cwillu_at_work | _wear_levelled_ compressed swap for free :) | 11:24 |
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:26 |
kblin | nice | 11:28 |
kblin | but what do you do that uses swap? :) | 11:28 |
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:29 |
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:30 |
cwillu_at_work | browser session really | 11:31 |
kblin | ah, my beagles run as headless servers :) | 11:31 |
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:32 |
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:33 | |
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:34 |
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:36 |
cwillu_at_work | I: Unpacking the base system... | 11:43 |
* cwillu_at_work plans to head home after this finishes, and as such starts his car | 11:55 | |
cwillu_at_work | I: Base system installed successfully. | 11:58 |
* cwillu_at_work grabs squeezes pixman | 12:00 | |
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:04 |
cwillu_at_work | lool, squeeze's binary package works without corruption | 12:05 |
* cwillu_at_work waits for apt to finis | 12:07 | |
lool | cwillu_at_work: You might want to do a test rebuild before trying with 4.4 + squeeze | 12:17 |
* cwillu_at_work waits for debian/rules to do its thing | 12:34 | |
cwillu_at_work | installing squeeze-chroot-built 4.3 | 12:53 |
cwillu_at_work | lool, ^ | 12:53 |
cwillu_at_work | lool, no corruption on 4.3, rebuilding with 4.4 | 12:55 |
cwillu_at_work | lool, incidently, it looks like a simple CC=gcc-4.4 works with debian/rules | 13:07 |
* cwillu_at_work waits for 4.4 to build | 13:11 | |
cwillu_at_work | built, installing | 13:22 |
cwillu_at_work | restarting x | 13:24 |
cwillu_at_work | lool, still around? | 13:27 |
cwillu_at_work | squeeze's 0.16.2-1 works fine (no corruption) against gcc 4.4 and 4.3 | 13:28 |
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:29 |
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:30 |
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:31 |
cwillu_at_work | yep | 13:32 |
cwillu_at_work | okay, I'll try that when I get back | 13:32 |
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 | 13:33 |
=== jmc93739653 is now known as jmc93739653_AWAY |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!