| DanaG | oh yeah, so are we going to have an omap kernel in the repos? | 00:45 |
|---|---|---|
| DanaG | argh, not enough free space on my sd card for a whole kernel tree. | 00:46 |
| DanaG | And no cross-compiler in the amd64 host's repos. | 00:46 |
| rcn-ee | yeap, it looks like it.. just emailed amit the usb config changes. ;) | 00:47 |
| DanaG | oh yeah, I hope it'll have the usb-audio gadget, and such. =þ | 00:47 |
| DanaG | the rcn-ee kernel doesn't have those. | 00:48 |
| rcn-ee | laughs, what's the config change, and it will. ;) | 00:48 |
| DanaG | here are the lines I see relevant in the config right now: | 00:49 |
| DanaG | CONFIG_USB_ETH=y CONFIG_USB_ETH_RNDIS=y CONFIG_USB_ETH_EEM=y # CONFIG_USB_GADGETFS is not set # CONFIG_USB_FILE_STORAGE is not set # CONFIG_USB_MASS_STORAGE is not set # CONFIG_USB_G_SERIAL is not set # CONFIG_USB_MIDI_GADGET is not set # CONFIG_USB_G_PRINTER is not set # CONFIG_USB_CDC_COMPOSITE is not set # CONFIG_USB_G_MULTI is not set CONFIG_USB_OTG_UT | 00:49 |
| DanaG | Which ones to enable, is partly subjective. | 00:50 |
| DanaG | oh, and the audio one doesn't seem to be there. | 00:50 |
| DanaG | time for some googling. | 00:51 |
| DanaG | http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:usb-gadget:audio | 00:52 |
| rcn-ee | those can be tricky.. if you look in my 2.6-stable repo, under patches/rcn/ there is a 002-defconfig-disable-ga***.diff, basicly you can break usb based rootfs on bx and c2 boards.. ;) | 00:52 |
| rcn-ee | sd card based rootfs don't care. .;) | 00:52 |
| DanaG | hmm, which repo should I clone, to go experimenting with the stuff? | 00:53 |
| DanaG | I'm curious how that file gadget thingy works.... what does the host see... a raw disk, or some magic files? | 00:53 |
| rcn-ee | 2.6-stable is 2.6.32, 2.6-dev is 2.6.33, 2.6-mailine is broken (2.6.34-rc1) and lucid-ti-omap is what ubuntu will have. | 00:54 |
| DanaG | oh, and one issue I do notice: [10468.479431] Class driver suspend failed for cpu0 | 00:54 |
| DanaG | hmm, I do see... allowing raw disk access from both host system and the ARM device... sounds like a way to have Very Bad Things happen. | 00:55 |
| DanaG | =þ | 00:55 |
| DanaG | oh, I see... it's file-backed, not raw-disk-backed. | 00:56 |
| rcn-ee | yeah it does, i did that on an 8-bit usb micro to see what would happen.; | 00:56 |
| DanaG | 8-bit usb micro? micro-sd card? | 00:57 |
| DanaG | http://www.linux-usb.org/gadget/ | 00:58 |
| DanaG | Oooh, u-boot environment vars for MAC address and such. | 00:58 |
| rcn-ee | oh, it was an avr 8bit usb micro, was messing around with usb file systems.. | 00:58 |
| DanaG | er, wait, no, they just go to cmdline. =þ | 00:58 |
| DanaG | I'm curious how the audio gadget would work... playback to device from host would appear as an input stream on the guest, I suppose. | 00:59 |
| DanaG | oh yeah, and for rndis in win7 64-bit, you can just manually choose "RNDIS-Compatible" in device manager -- and it's even signed. | 01:00 |
| rcn-ee | i'm guessing it would be just like those cheap usb 5.1 audio plugins, the beagle would play the stream.. | 01:00 |
| DanaG | I have one of those USB sound cards (CM106). | 01:00 |
| DanaG | It does some rather weird stuff. | 01:00 |
| DanaG | http://pulseaudio.org/ticket/678 | 01:00 |
| DanaG | also weird: there's no kernel here -- http://rcn-ee.net/deb/kernel/beagle/lucid/v2.6.33.1-dl.2/ | 01:02 |
| rcn-ee | yeap, i messed up the script last week and didn't clear the queye.. ;) | 01:02 |
| DanaG | I wish the beagleboard had more audio outputs. | 01:03 |
| DanaG | ... or would at least hide the non-relevant stuff in the hideously complicated mixer. =þ | 01:03 |
| rcn-ee | when one of those missing stuff, just take a look at: http://rcn-ee.homeip.net:81/dl/farm/log/ shows the status of my farm.. ;) | 01:04 |
| rcn-ee | basicly the *.deb file wasn't spelled exactly as i was expecting.. . | 01:04 |
| DanaG | oh, and ureadahead main process terminates with status 5 -- happens on my host system, too (drm-next kernel). Does ureadahead need some non-upstream patches? | 01:05 |
| rcn-ee | it's chewing on that one right now.. http://rcn-ee.homeip.net:81/dl/farm/log/BUILDING-2.6.33.1-dl2_1.0-lucid.txt should be done in another 4-5 hours... | 01:05 |
| rcn-ee | yeah it does... | 01:05 |
| DanaG | It also breaks the plymouth splash on my host. And makes it slow to log in. | 01:06 |
| DanaG | oh yeah, and thank you greatly for making those kernel and rootfs images available -- it's a great help for using the board. | 01:06 |
| rcn-ee | or i thought it did... http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=shortlog;h=refs/heads/ti-omap i'm going blind... | 01:06 |
| DanaG | also funny on ARM: things like nvidia-kernel-common and virtualbox-guest-additions still exist. | 01:07 |
| rcn-ee | i've had reports that "console-setup-mini" greatly speeds up serial prompt login... | 01:07 |
| DanaG | I've come to have a great appreciation for serial console -- my host laptop has serial-over-lan; awesome for grabbing stacktraces. | 01:08 |
| rcn-ee | yeah there's a lot of funny ones, libdrm_intel/radeon/etc.. plymouth actually kinda worked for me today on bootup... although it didn't go any farther.. | 01:08 |
| DanaG | I got a kernel panic on my other laptop (a netbook)... and had NO way whatsoever to get a full stacktrace. | 01:08 |
| DanaG | I'm using drm-next on the host, for the sake of radeon KMS power-management. | 01:09 |
| rcn-ee | me too, i'm torn between getting the xm beagle working or test agd5x's new pm patches.. ;) | 01:09 |
| DanaG | I'll wait for it to go into the kernel-ppa stuff. | 01:10 |
| DanaG | oh yeah, does xm have gigabit ethernet, or just 10/100? | 01:10 |
| rcn-ee | not sure, it's smsc and i'm guessing 10/100.. | 01:11 |
| rcn-ee | lan9514 | 01:11 |
| rcn-ee | cool, it's a usbhub/usbethernet.. so it should be faster then micrel's zippy2... | 01:12 |
| DanaG | SPI ethernet strikes me as weird. | 01:12 |
| rcn-ee | it is... but it's perfect for ethernet enabling a pic 8/16bit... | 01:13 |
| DanaG | That 3-port-hub-with-ethernet that specialcomp.com sells is pretty cool -- it's also what the macbook air should have come with. =þ | 01:13 |
| DanaG | oh yeah, do you have the monochrome LCD from specialcomp.com? I couldn't quite figure out how you'd tell the kernel to use 480x272. | 01:14 |
| rcn-ee | nope i don't.. usually headless installs.. are you connecting between the lcd pins or hdmi connector? | 01:14 |
| DanaG | er, a classmate has it (and is going to try it this weekend); it goes to the lcd-controller pins and expansion connector. | 01:15 |
| rcn-ee | not sure.. it's the one thing i haven't spent enough time trying to do a one of these boards.. | 01:17 |
| DanaG | what I've done with mine so far: mostly just mess around with pulseaudio. It works awesomely well even over usb-net. | 01:18 |
| rcn-ee | yeap, that was too easy.. xm still locks.. | 01:18 |
| DanaG | Do you talk to the people who do the kernel-ppa stuff? I've noticed that it has all of STAGING disabled, as well as CONFIG_MMC_RICOH_MMC. | 01:19 |
| rcn-ee | I think they use the same config as the offical release, so what ever was enabled, gets enabled... | 01:20 |
| DanaG | .config:2069:warning: symbol value 'm' invalid for MMC_RICOH_MMC .config:4418:warning: override: reassigning to symbol STAGING | 01:22 |
| === NCommand1r is now known as NCommander | ||
| JaMa | Hi, https://bugs.launchpad.net/ubuntu/+source/pixman/+bug/535183 patch V2, which was now included in upstream pixman http://cgit.freedesktop.org/pixman/commit/?id=18f0de452dc7e12e4cb544d761a626d5c6031663, checks for uqadd8 with forced -marm, which means that when we build that binary with thumb enabled, then it will contain not available uqadd8 and fail with SIGILL on ie armv4t | 06:48 |
| ubot4` | Launchpad bug 535183 in pixman (Ubuntu) "pixman doesn't autodetect SIMD support at build time on arm. (affects: 1)" [Undecided,Fix released] | 06:48 |
| JaMa | If you really want to do it this way, then there should probably be -marm also in coresponding ARM_SIMD_CFLAGS="-mcpu=arm1136j-s" | 06:50 |
| JaMa | ah, there is -marm in ARM_SIMD_CFLAGS but somehow not used somewhere.. | 07:00 |
| persia | JaMa: Am I reading the patch incorrectly? I'd expect the failure to unset have_arm_simd=yes, so that it wouldn't compile that bit in. | 07:00 |
| persia | I think we're expecting that failure for ARMv4t, so that ./configure can do the right thing. | 07:00 |
| JaMa | persia: but that 2nd run, detects uqadd8 usable but with -marm in CFLAGS | 07:01 |
| JaMa | persia: and than it builds pixmap probably without forced -marm (ARM_SIMD_CFLAGS is maybe used only in this configure test) | 07:02 |
| JaMa | persia: and resulting thumb binary is created with supposed uqadd8 support | 07:02 |
| JaMa | persia: trying that patch v1, which looks safer to me | 07:02 |
| persia | But shouldn't the second run only happen if the first run is successful? | 07:03 |
| lool | JaMa: are you setting -mthumb via CFLAGS? | 07:04 |
| lool | JaMa: see <20100314172510.GA3901@bee.dooz.org> on pixman@lists.freedesktop.org | 07:05 |
| JaMa | lool: yes | 07:05 |
| JaMa | here is my config.log http://paste.pocoo.org/show/191446/ | 07:05 |
| lool | http://article.gmane.org/gmane.comp.graphics.pixman/59 | 07:05 |
| lool | JaMa: So I think configure is kind of doing the right thing here, but in an ideal world we could avoid it | 07:07 |
| lool | JaMa: You're using CFLAGS which in autotools is an override over the per-file and global upstream CFLAGS | 07:07 |
| lool | JaMa: So even if we try with proper -mcpu= and -marm, it doesn't build because you override with -mthumb; perhaps the check could build the piece of code with a newer CPU and -mthumb as well to cover this case more nicely though | 07:08 |
| lool | It's a bit ugly as it is, and would make it worse I guess | 07:09 |
| lool | ideally, we'd move the code to a separate .S file and turn on what we need in there | 07:09 |
| JaMa | this is crosscompile build with OE, so I work-arounded it with --disable-arm-simd for now, but thanks for help, I'll try better, but now I have to go to work.. | 07:09 |
| lool | Ok | 07:10 |
| lool | I don't think you should have to --disable-arm-simd; it should be the default?! | 07:10 |
| JaMa | lool: after this commit it changes detected value from No to Yes | 07:11 |
| JaMa | lool: so with --disable-arm-simd only for armv4t I'm forcing it to stay disabled as it was before | 07:11 |
| JaMa | lool: as -mthumb was there for all builds before and after | 07:12 |
| lool | Your config.log indicates USE_ARM_SIMD is false?! | 07:12 |
| JaMa | lool: yes for 933540861383da27402680593edefe8d61e6fb02 and older | 07:13 |
| lool | Oh, that's an older config.log | 07:13 |
| lool | well I'm interested in a newer one :) | 07:13 |
| JaMa | lool: but that's I guess expected, because before it wasn't tried with -marm, mmt I'll pastebin new | 07:15 |
| JaMa | 933540861383da27402680593edefe8d61e6fb02 http://paste.pocoo.org/show/191449/ | 07:17 |
| JaMa | 18f0de452dc7e12e4cb544d761a626d5c6031663 http://paste.pocoo.org/show/191450/ | 07:19 |
| JaMa | and now really off, see you in an hour or so | 07:19 |
| lool | that's odd, I see only one compile with -mcpu=arm1136j-s, not the one wihtout | 07:21 |
| lool | JaMa: So it detects it, and then it fails to build? | 07:23 |
| persia | Hrm? That test certainly looked like "compile without, on success, compile with, on success, set variable" | 07:24 |
| lool | I wonder why it's called as: | 07:25 |
| lool | arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb -c -mcpu=arm1136j-s -marm | 07:25 |
| lool | I wrote: CFLAGS="$ARM_SIMD_CFLAGS $CFLAGS" | 07:25 |
| lool | So I would think it should look like arm-oe-linux-gnueabi-gcc -mcpu=arm1136j-s -marm -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb -c | 07:25 |
| lool | which should fail | 07:25 |
| persia | Could it potentially be doing $COMPILER_DEFAULT_CFLAGS $USER_SUPPLIED_CFLAGS ? | 07:26 |
| lool | $COMPILER_DEFAULT_CFLAGS doesn't appear on the cmdline usually | 07:26 |
| persia | True. Hrm. | 07:26 |
| persia | Looking at the command line, I wonder if maybe the -march and -mtune stuff is added later, using the same $NEW_CFLAGS $CFLAGS approach. | 07:29 |
| persia | They all seem to be based on arguments passed to configure. | 07:29 |
| persia | But I'm grasping at straws at this point. | 07:30 |
| lool | it seems configure is playing clever with the args | 07:32 |
| lool | arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb -c -isystem/OE/tmpdir-dev-shr/staging/armv4t-oe-linux-gnueabi/usr/include | 07:32 |
| lool | and then arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb -c -mcpu=arm1136j-s -marm -isystem/OE/tmpdir-dev-shr/staging/armv4t-oe-linux-gnueabi/usr/include | 07:32 |
| lool | so clearly the only way for flags to end up in the middle is that someone reorders them | 07:32 |
| persia | Indeed. That is being overly clever. | 07:32 |
| lool | and it's done before running CC since the flags only appear once | 07:33 |
| lool | Well, I'm tempted to walk away in disgust :-) | 07:33 |
| lool | ah perhaps I'm actually wrong | 07:35 |
| lool | -include stuff might be CPPFLAGS | 07:35 |
| lool | ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5' | 07:35 |
| persia | Aha! | 07:35 |
| persia | So $CC is the culprit. | 07:35 |
| persia | $CC is evaluating to "arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb" | 07:35 |
| persia | Followed by -c $CFLAGS $CPPFLAGS | 07:36 |
| lool | JaMa: So you're setting the flags in CC, not in CFLAGS? | 07:38 |
| ssvb_ | JaMa: are you getting pixman build failure or SIGILL at runtime? | 07:44 |
| JaMa | ssvb_: SIGILL at runtime | 08:09 |
| JaMa | lool: yes it's in CC | 08:10 |
| JaMa | lool: here is whole environment, how bitbake runs configure http://pastebin.ca/1845506 | 08:12 |
| ssvb_ | JaMa: that's pretty bad, looks like runtime cpu features detection is failing for you | 08:12 |
| ssvb_ | JaMa: can you add some debugging stuff in pixman-cpu.c to check whether/why 'arm_has_v6' variable gets set to true? | 08:14 |
| persia | JaMa: What breaks if you put that stuff in $CFLAGS instead of in $CC ? Having it in $CC subverts the test, causing the issue. | 08:14 |
| JaMa | ssvb_: runtime? this is crosscompile build and SIMD wasn't enabled before, so SIMD code should workarround missing uqadd8 in runtime? | 08:15 |
| ssvb_ | JaMa: I know that autodetection was behaving weird in qemu | 08:15 |
| JaMa | I don't use qemu here.. | 08:15 |
| ssvb_ | JaMa: so you haven't run your binary on real device yet? | 08:16 |
| JaMa | it works ok if I disable simd wiht --disable-arm-simd and probably also work if I disable thumb for whole pixman | 08:16 |
| ssvb_ | JaMa: if you don't want any armv6 simd optimizations and want to save some space, --disable-arm-simd is your choice | 08:17 |
| JaMa | the same bitbake build for armv5te works ok without any work-arround and with thumb enabled | 08:17 |
| ssvb_ | JaMa: what is your definition of 'works ok'? | 08:17 |
| JaMa | ssvb_: that's what I used before, but I'm asking why it's autodetected now as available (not respecting -mthumb, well in wrongly used CC) | 08:18 |
| JaMa | ssvb_: works ok = no SIGILL on device and Xorg running ok | 08:18 |
| JaMa | ssvb_: doesn't work at all = SIGILL when starting Xorg | 08:18 |
| ssvb_ | JaMa: so can you confirm SIGILL? | 08:19 |
| JaMa | ssvb_: yes | 08:19 |
| JaMa | ssvb_: that was first message I sent here :) | 08:19 |
| ssvb_ | JaMa: I just wanted to have a confirmation | 08:20 |
| ssvb_ | JaMa: do you have any way to debug this stuff on the device? | 08:20 |
| JaMa | ssvb_: and I already prepared --disable-arm-simd builds to get usable device again, because it "restores" old behavior for armv4t with thumb forced | 08:21 |
| ssvb_ | JaMa: function 'pixman_arm_read_auxv' is the most likely culprit if it detects availability of armv6 instructions wrong | 08:21 |
| JaMa | ssvb_: and do I really want simd enabled? as you already said I probably don't need it, so I can debug it, but I'm not sure it's worth it | 08:22 |
| * lool is back | 08:22 | |
| ssvb_ | JaMa: yes, if you don't want to debug this issue, then you can use this as a workaround for sure | 08:22 |
| lool | JaMa: So to recap, two issues here: one is SIMD gets turned on as intended when CFLAGS allow it (CFLAGS override CC, so it's correct); this is working as expected; second issue is runtime detection which triggers a SIGILL on your device, that's a bug | 08:23 |
| ssvb_ | JaMa: what I wanted to know is whether 'arm_has_v6' variable evaluates to true (that would be one possible bug), and if it is not, then where exactly is the location of the wrong instruction | 08:24 |
| lool | JaMa: In practice you don't care about SIMD, but perhaps you care that everybody with the same use case as yours doesn't have to pass --disable-simd | 08:24 |
| JaMa | lool: why cannot you pass -marm to CFLAGS if SIMD is enabled only in that second run? | 08:25 |
| JaMa | lool: this would if I get you right, enable working simd for cost of overriding thumb from CC | 08:25 |
| lool | JaMa: That's what's happening actually | 08:25 |
| lool | JaMa: which is why you can build and run it | 08:26 |
| JaMa | lool: but only in conftest not build | 08:26 |
| lool | That should be the case during build | 08:26 |
| JaMa | mmt I'll check | 08:26 |
| lool | JaMa: Note that it's only used to build a couple of files | 08:26 |
| lool | Only one actually, -pixman-arm-simd.c | 08:26 |
| JaMa | lool: with -mthumb moved from CC to CFLAGS, configure detects simd as "no" | 08:27 |
| lool | JaMa: Yes | 08:28 |
| lool | JaMa: that's a limitation due to the fact that user-specified CFLAGS override our CFLAGS | 08:28 |
| lool | JaMa: But as ssvb_ points out, the bug here is a runtime one; the only real life problem we're seeing is that you get a SIGILL, and it's not clear why | 08:30 |
| lool | it would seem the detection code reports v6 as present at runtime while it's not | 08:30 |
| JaMa | this is how it fails http://pastebin.ca/1845518 | 08:31 |
| ssvb_ | JaMa: can you also add 'info registers' output? | 08:33 |
| JaMa | ssvb_: sure mmt, have to reinstall faulty version | 08:33 |
| lool | I wonder whether it's a thumb/non-thumb issue | 08:34 |
| JaMa | I think so | 08:34 |
| lool | JaMa: What's your CPU again? | 08:34 |
| JaMa | samsung s3c2442 ARM920T rev 0 (v4l) | 08:35 |
| lool | JaMa: and in configure output, do you get NEON detected or not detected? | 08:36 |
| JaMa | lool: neon is disabled with configure option | 08:36 |
| JaMa | with thumb disabled in OE (resulting in -mno-thumb in CC) no SIGILL, but SIMD is detected as disabled, so it's not interesting case | 08:39 |
| lool | that's odd | 08:41 |
| lool | it should turn on SIMD if you only set -mno-thumb in CC | 08:41 |
| lool | (but not in cflags) | 08:41 |
| persia | JaMa: If you run that ./configure natively, does it work as expected? (I don't expect a real compile, just curious if it's an OE-only thing, or a hardware thing). | 08:42 |
| ssvb_ | JaMa: do you have -mthumb-interwork option somewhere? | 08:44 |
| lool | ssvb_: Oh good point | 08:44 |
| ssvb_ | JaMa: I wonder if not having it may also cause some kind of screwup in the linker (even if arm/thumb calls are not supposed to be happening at runtime) | 08:45 |
| JaMa | ssvb_: http://pastebin.ca/1845528 | 08:46 |
| JaMa | ssvb_: configure:11496: arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mno-thumb -c -mcpu=arm1136j-s -marm | 08:47 |
| JaMa | ssvb_: and with thumb enabled | 08:48 |
| JaMa | ssvb_: configure:11479: arm-oe-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb | 08:48 |
| ssvb_ | JaMa: the most interesting address 0x401af86a (pc register value) is missing in the disassembly | 08:48 |
| lool | Weird, I don't find -mthumb-interwork in our Ubuntu defaults, but we don't seem to have screwups without it | 08:48 |
| JaMa | ssvb_: http://pastebin.ca/1845535 but still missing I'll try to disassm with objdump instead gdb | 08:49 |
| ssvb_ | JaMa: it could be that it is just some garbage padding data between functions and not a real instruction, in this case it would be interesing to know how it managed to get there | 08:52 |
| ssvb_ | JaMa: if it was a function call, then 'lr' register should point to the return address (and call instruction itself should be just before it) | 08:54 |
| ssvb_ | JaMa: what toolchain are you using? gcc, and binutils versions | 09:01 |
| JaMa | gcc-4.4.3 binutils-2.20 | 09:02 |
| ssvb_ | JaMa: now I suspect that the 'alien' object file with arm code may create some kind of bubble in the resulting binary and the function addresses may get all wrong and shifted on one of the sides of the 'bubble' | 09:04 |
| JaMa | mmt binutils for target already built, I'll provide disassm with thumb forced | 09:04 |
| ssvb_ | JaMa: just tried googling a bit: http://old.nabble.com/binutils-2.20.1-td27432353.html | 09:19 |
| ssvb_ | it says something about "broken thumb->arm intersection branches", don't know if it is relevant | 09:19 |
| ssvb_ | JaMa: but if you could downgrading binutils to 2.19 just for testing, it would be interesting | 09:20 |
| JaMa | ssvb_: http://jama.homelinux.org/org.openembedded.shr.images/om-gta02/pixman/ | 09:22 |
| JaMa | ssvb_: here is disassembled lib with objdump with and without -M force-thumb, but with it fails later on some instruction and Aborts | 09:23 |
| ssvb_ | JaMa: btw, I'm trying to reproduce your environment now (gcc, binutils, CC, CFLAGS), I have a gut feeling that it could be one of the bugs in binutils 2.20 | 09:26 |
| JaMa | ssvb_: trying to downgrade now | 09:26 |
| ssvb_ | JaMa: could not break anything here with CC="gcc -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb" CFLAGS="-fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os" | 10:32 |
| ssvb_ | though I have armv7 CPU, and just noticed that I actually used binutils 2.20.1 | 10:33 |
| JaMa | ssvb_: on armv5te it works for me too | 10:34 |
| ssvb_ | JaMa: did you try running the same binary on armv5te? or it had its own CC and CFLAGS? | 10:36 |
| ssvb_ | JaMa: if something runs on armv5te but does not run on armv4t, then it could be a PLD instruction somewhere | 10:38 |
| ssvb_ | UQADD8 and the other ARM SIMD instructions would only run on armv6 and newer | 10:39 |
| JaMa | ssvb_: yeah same binary | 10:40 |
| suihkulokki | pld or clz | 10:40 |
| asac | JamieBennett: all fine wrt to langpack.mk ? | 10:42 |
| asac | or blocked ;) | 10:42 |
| asac | ? | 10:42 |
| JamieBennett | asac: still working on it, I have a branch if your available to inspect it | 10:43 |
| JamieBennett | (and using distutils) | 10:43 |
| asac | JamieBennett: yeah if you have that i can look ;) | 10:43 |
| JamieBennett | asac: Its not ready so I would appreciate pointers | 10:44 |
| asac | let me look | 10:44 |
| JamieBennett | https://code.edge.launchpad.net/~jamiebennett/+junk/webservice-office-zoho-translation-support | 10:44 |
| asac | i guess in +junk? | 10:44 |
| asac | ok found ;) . oh hehe | 10:44 |
| JamieBennett | lots of noise as I had to reorganise it | 10:44 |
| JamieBennett | asac: probably lots wrong at the moment | 10:45 |
| asac | hmm | 10:46 |
| asac | why was all that needed? | 10:46 |
| asac | thought we just needed to make .desktop translatable | 10:46 |
| JamieBennett | there was a comment about the code being translatable too and persia recommended doing it 'properly' | 10:47 |
| JamieBennett | Also had to add setup.py | 10:47 |
| asac | where is the bug? https://bugs.edge.launchpad.net/ubuntu/+source/webservice-office-zoho | 10:48 |
| asac | there is nothing ;) | 10:48 |
| JamieBennett | asac: It was the MIR which has now been approved | 10:48 |
| asac | JamieBennett: but you were supposed to file a high bug about this ;) | 10:49 |
| asac | also the MIR bug isnt even there ,) | 10:49 |
| asac | https://bugs.edge.launchpad.net/ubuntu/+source/webservice-office-zoho/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&assignee_option=any&field.assignee=&field.bug_reporter=& | 10:49 |
| JamieBennett | asac: https://bugs.edge.launchpad.net/webservice-office-zoho/+bug/539626 | 10:49 |
| lool | Ouch | 10:49 |
| JamieBennett | :) | 10:49 |
| ubot4` | Launchpad bug 539626 in webservice-office-zoho "Needs translation support (affects: 1)" [Critical,Confirmed] | 10:49 |
| asac | JamieBennett: thats not an ubuntu bug | 10:49 |
| asac | added | 10:50 |
| JamieBennett | I know, the project got moved and now the bug is on the wrong project | 10:50 |
| JamieBennett | asac: thanks | 10:50 |
| asac | JamieBennett: where is the MIR bug? | 10:50 |
| JamieBennett | bug: 537323 | 10:51 |
| ssvb_ | JaMa: Don't know what to advise in this case, the problems could be also related to buggy/misconfigured kernel or silicon bugs in CPU. But in this case you would have stability issues with the other packages too. | 10:51 |
| JamieBennett | https://bugs.edge.launchpad.net/webservice-office-zoho/+bug/537323 | 10:51 |
| lool | lp #537323 | 10:51 |
| ubot4` | Launchpad bug 537323 in webservice-office-zoho (Ubuntu) (and 1 other project) "[MIR] Main inclusion request for webservice-office-zoho (affects: 1)" [Undecided,New] | 10:51 |
| ubot4` | Launchpad bug 537323 in webservice-office-zoho (Ubuntu) (and 1 other project) "[MIR] Main inclusion request for webservice-office-zoho (affects: 1)" [Undecided,New] https://launchpad.net/bugs/537323 | 10:51 |
| asac | ok added ubuntu there too | 10:52 |
| asac | i dont think upstream .desktop files can be translated with gettext | 10:53 |
| asac | but maybe i am wrong | 10:53 |
| ssvb_ | JaMa: extracting the problematic instruction at pc address from gdb somehow would provide some insights. Can you at least read it as just binary data (via x gdb command)? | 10:53 |
| asac | for real code stuff sure | 10:53 |
| JamieBennett | .desktop files should be .desktop.in | 10:54 |
| persia | asac: Upstream .desktop can be translated with gettext just fine. A large number of GNOME packages do that. | 10:54 |
| ssvb_ | JaMa: it would be 'x/4b $pc' when it dies with SIGILL | 10:55 |
| === ogra_ is now known as ogra | ||
| gaspa | what happen if I run Lucid on a armv5 board? (nothing|broken|just slow) | 12:01 |
| persia | gaspa: It won't run. | 12:09 |
| lool | SIGILL | 12:09 |
| persia | gaspa: I suspect that you won't even be able to boot, because upstart will SIGILL | 12:09 |
| gaspa | right, as expected, thanks. | 12:09 |
| gaspa | further question, given a binary, can I know for which armvX is compiled? | 12:10 |
| persia | I don't know of any way. There may be some trick you can do with magic numbers, but I'm unsure how far I'd trust it beyond ARM vs. Thumb | 12:19 |
| JaMa | ssvb_: 0x401af7c2 <pixman_transform_init_identity+10>: -128 -24 -128 32 | 12:23 |
| JaMa | ssvb_: all info also sent to pixman list now | 12:24 |
| gaspa | persia: ok, thanks again. | 12:29 |
| persia | gaspa: I have a couple ARMv5 devices myself, but I have decided Debian is the right distribution for them. It's close enough, and it works. The alternative is sticking with Jaunty, but that expires soon enough. | 12:30 |
| gaspa | debian compiles for armv4, as i know. | 12:31 |
| persia | Yeah, but the performance difference isn't that huge. | 12:32 |
| persia | If you need performance, get a newer board :) | 12:32 |
| gaspa | and I got a big downspeed, in respect with the montavista default filesystem. | 12:32 |
| gaspa | lol. | 12:33 |
| armin76 | gaspa: readelf -a /binary | 12:50 |
| armin76 | gaspa: you can use gentoo :D | 12:50 |
| persia | armin76: Nifty! Thanks. | 12:57 |
| Laibsch | persia: I heard you were looking into mending the chroot build scripts and pbuilder. Is that correct? | 13:08 |
| Laibsch | Anything available for testing somewhere? | 13:08 |
| lool | Laibsch: Not sure how aligned it is with your research, but | 13:09 |
| lool | https://wiki.ubuntu.com/UbuntuDevelopment/Ports has some bits I wrote down and which might relate | 13:09 |
| Laibsch | thanks | 13:09 |
| * Laibsch is reading | 13:09 | |
| Laibsch | I've been out of the loop since about two weeks | 13:09 |
| lool | Let us know where it lacks | 13:09 |
| persia | Laibsch: I've pushed most of my stuff into Lucid. | 13:09 |
| Laibsch | great | 13:10 |
| Laibsch | I should already have it, then | 13:10 |
| persia | Laibsch: http://people.ubuntu.com/~persia/pull-soyuz-chroot may also interest you | 13:10 |
| persia | (that's still WIP) | 13:10 |
| Laibsch | looks like you guys really did some amazing work on making this a *LOT* easier | 13:14 |
| Laibsch | sudo pbuilder --create --basetgz /var/cache/base-armel.tgz --debootstrap qemu-debootstrap --mirror http://ports.ubuntu.com/ubuntu-ports/ --distribution lucid --architecture armel | 13:14 |
| Laibsch | all there seems to be to it | 13:14 |
| lool | persia: Oh didn't know one can download premade chroots from LP | 13:14 |
| lool | that's great :-) | 13:14 |
| lool | persia: Do you actually require bash? | 13:15 |
| persia | I thought I did. | 13:16 |
| persia | I might not, at that. | 13:17 |
| persia | Give it a try. I think I started with sh and something broke. | 13:17 |
| persia | Maybe the getopts stuff. | 13:17 |
| * Laibsch suggests /var/cache/pbuilder/base-armel.tgz instead of /var/cache/base-armel.tgz in the wiki instructions | 13:19 | |
| Laibsch | comments? | 13:19 |
| lool | fixed | 13:19 |
| Laibsch | thanks | 13:20 |
| lool | persia: Is there any signing available for the soyuz chroot tarballs? | 13:20 |
| lool | This is great material because it puts people on par with lanuchpad buildds to start their buil | 13:20 |
| lool | builds | 13:20 |
| persia | lool: That's why wgrant exported them, and why I put together a script to grab them. | 13:22 |
| persia | I don't think there's signing now : that probably needs Soyuz extension. | 13:22 |
| persia | The part that's stumping me is how to use that chroot with pbuilder. I can't find the pbuilder configuration file that I need to tweak. Do you know how the last bit shoud work? | 13:23 |
| lool | persia: So you've just put up for a very nice alternative to the qemu-debootstrap stuff for the pbuilder use case | 13:23 |
| lool | persia: (Will get to your point in a sec) | 13:23 |
| persia | That's part of the idea. | 13:23 |
| persia | The other thing is that some stuff FTBFS on the buildds, and not locally, and it turns out to be some odd buildd config thingy. This helps track that down. | 13:24 |
| lool | persia: What I hate with the current approach is the "cp /usr/bin/qemu-arm-static /somechroot" approach; it's ugly because we mix files from various architectures with no tracking, e.g. no updates to them, pollute the namespace etc. | 13:25 |
| persia | Indeed. | 13:26 |
| lool | persia: Having a pbuilder hook which starts from an armel tarball but copies the qemu binary on every build would be an improvement already (I think) | 13:26 |
| persia | That's a much better idea, although I'd want it in sbuild :) | 13:26 |
| persia | Or better, in schroot, so it gets updated on every schroot instantiation. | 13:26 |
| lool | Back to your point, I think pbuilder is broken with respect to handling of .tar.bz2 tarballs, but "tar" will actually figure out compression if the file uses proper extension | 13:27 |
| lool | So it would be possible to remove the -z flag from tar calls and have pbuilder support .bz2 tarballs transparently | 13:27 |
| lool | persia: Note that until now the cp was needed to finish the debootstrap; it was kind of logical to keep that stuff around for actual chroot use | 13:28 |
| * lool phone call & | 13:28 | |
| asac_ | bug 517300 | 14:19 |
| ubot4` | Launchpad bug 517300 in likewise-open (Ubuntu Lucid) (and 1 other project) "[armel] likewise-open needs porting to ARM (affects: 1)" [High,In progress] https://launchpad.net/bugs/517300 | 14:19 |
| asac_ | bug 537356 | 14:21 |
| ubot4` | Launchpad bug 537356 in webservice-office-zoho (Ubuntu Lucid) (and 1 other project) "application menu entries dont do anything (affects: 1)" [High,Triaged] https://launchpad.net/bugs/537356 | 14:21 |
| asac_ | bug 457878 | 14:22 |
| ubot4` | Launchpad bug 457878 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "imx51 on board ethernet plug/unplug events not detected (affects: 2)" [Medium,Confirmed] https://launchpad.net/bugs/457878 | 14:22 |
| asac | plars: were there any arm specific RC issues discovered in beta testing? | 14:27 |
| asac | bug 513732 | 14:28 |
| ubot4` | Launchpad bug 513732 in gmp (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged] https://launchpad.net/bugs/513732 | 14:28 |
| asac | bug 528887 | 14:28 |
| ubot4` | Launchpad bug 528887 in maximus (Ubuntu Lucid) (and 2 other projects) "maximus does not give default focus to newly started apps in combination with efl launcher (affects: 2)" [Medium,Triaged] https://launchpad.net/bugs/528887 | 14:28 |
| asac | bug 537083 | 14:29 |
| ubot4` | Launchpad bug 537083 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "Suspend no longer works after updating to 2.6.31-605.9 kernel (affects: 2)" [High,In progress] https://launchpad.net/bugs/537083 | 14:29 |
| ogra | qemu hang ? | 14:29 |
| asac | bug 499881 | 14:30 |
| ubot4` | Launchpad bug 499881 in linux-fsl-imx51 (Ubuntu Lucid) (and 1 other project) "usb storage with ext4 does not work in lucid on imx51 hardware (dup-of: 515023)" [High,Fix released] https://launchpad.net/bugs/499881 | 14:30 |
| ubot4` | Launchpad bug 515023 in linux (Ubuntu) "ATA pass-through commands preventing external HDD to be mounted (affects: 10) (dups: 1)" [Undecided,Confirmed] https://launchpad.net/bugs/515023 | 14:30 |
| asac | ogra: qemu hang is RC still | 14:30 |
| ogra | ok | 14:30 |
| asac | no news on that front afaik | 14:30 |
| ogra | i wasnt sure | 14:30 |
| === NCommand1r is now known as NCommander | ||
| asac | bug 528524 | 14:34 |
| ubot4` | Launchpad bug 528524 in totem (Ubuntu Lucid) (and 5 other projects) "Sound not working in all apps on dove (affects: 2)" [High,Invalid] https://launchpad.net/bugs/528524 | 14:34 |
| asac | bug 532733 | 14:39 |
| ubot4` | Launchpad bug 532733 in qemu-kvm (Ubuntu) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 2)" [Medium,Incomplete] https://launchpad.net/bugs/532733 | 14:39 |
| ogra | should probably be "in progress" | 14:40 |
| ogra | incomplete was added by the server team ages ago | 14:40 |
| rcn-ee | hey ogra, testing 2.6.33-500-omap with an initramfs, it's been a long time, what should i normally add to the bootargs.. ;) | 14:43 |
| ogra | root=UUID=<uuid of your rootfs> should be in there | 14:44 |
| ogra | beyond that "ro quiet splash" are ususally the defaults | 14:44 |
| ogra | i dont know the exact runes for uboot (loadaddr etc) yet but i think you provided a rootstock patch for that (that i was planning to merge soon) | 14:45 |
| rcn-ee | ah found it.. initrd=address. ;) | 14:47 |
| ogra | hmm, that shouldnt be needed | 14:48 |
| asac | bug 527720 | 14:48 |
| ubot4` | Launchpad bug 527720 in klibc (Ubuntu Lucid) (and 1 other project) "thumb2 porting issues identified: klibc uses mov.*pc (affects: 1)" [High,Triaged] https://launchpad.net/bugs/527720 | 14:48 |
| ogra | as long as uboot loads it to the proper place in ram | 14:48 |
| rcn-ee | sorry, main reason i don't login to irc at work, people keep calling.. ;) | 14:50 |
| rcn-ee | okay, anything beyond 'sudo update-initramfs -c -k 2.6...' | 14:57 |
| persia | rcn-ee: The thing about IRC is that it can also be asynchronous. Lots of us idle here when we're out, when we're sleeping, when we're on the phone, etc., and just answer later. In many clients there are ways to show the last few lines where someone highlighted you. | 14:57 |
| ogra | rcn-ee, i think you need to make an uInitramfs out of it | 15:03 |
| ogra | or uInitrd | 15:03 |
| rcn-ee | yeap i did: mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs -d ./initrd.img-2.6.33-500-omap ./uInitrd | 15:04 |
| rcn-ee | i'm searching google for how other people have done it.. ;) | 15:04 |
| ogra | that should be fine | 15:04 |
| rcn-ee | so i did this for the boot.scr : http://pastebin.com/byy5u0dR | 15:05 |
| rcn-ee | it loads the uIinitrd at boot... but the kernel doesn't like it.. | 15:06 |
| rcn-ee | [ 31.217498] Trying to unpack rootfs image as initramfs... | 15:06 |
| rcn-ee | [ 31.217803] rootfs image is not initramfs (junk in compressed archive); looks like an initrd | 15:07 |
| ogra | i think you need to include the initrd address in your bootm command | 15:08 |
| ogra | mmcinit; setenv bootargs 'console=ttymxc0,115200 console=tty0 root=UUID=bfdf1232-7400-4198-a89b-821e69e2fdd2 ro quiet splash'; fatload mmc 0:2 0x90800000 uImage; fatload mmc 0:2 0x91600000 /uinitrd; bootm 0x90800000 0x91600000 | 15:09 |
| ogra | thats the line i use for an imx51 board with uboot | 15:09 |
| rcn-ee | it's weird cause i got away with it here: http://elinux.org/BeagleBoardDebian#Development_PC:_Setup_SD_U-boot_Partition | 15:09 |
| rcn-ee | i'll add the bootm change.. | 15:09 |
| rcn-ee | cool, the bootm change did change things.. | 15:13 |
| ogra | works ? | 15:13 |
| rcn-ee | that would be too easy.. ;) now just: "[ 33.794677] Trying to unpack rootfs image as initramfs... " | 15:14 |
| ogra | try to drop the initrd= option | 15:14 |
| ogra | you shouldnt need it | 15:15 |
| rcn-ee | actually that was the other change i did.. | 15:15 |
| rcn-ee | was going to put it back.. ;) | 15:15 |
| ogra | oh, wait | 15:15 |
| ogra | -C gzip might be wrong | 15:15 |
| ogra | should be none | 15:16 |
| rcn-ee | yeah wasn't sure about that one, pulled from a sheevaplug example... | 15:16 |
| ogra | mkimage -A arm -O linux -T ramdisk -C none -a 0x0 -e 0x0 -n UbuntuInitrd -d "$INITRD" "$UINITRD" ... thats what we used for testing on imx51 | 15:17 |
| rcn-ee | thanks, i'll use that.. | 15:18 |
| rcn-ee | weird still no go, here's what i got.. http://pastebin.com/h8Hq2Ksh | 15:21 |
| ogra | hmm | 15:27 |
| rcn-ee | i have week or two old .config from the imx tree, the initrd options seem to match up... | 15:28 |
| ogra | well, try dropping rootwait rootfstype=ext3 | 15:28 |
| rcn-ee | sure | 15:29 |
| rcn-ee | no change... | 15:32 |
| ogra | well, it definately loads it | 15:32 |
| ogra | [ 33.773162] Trying to unpack rootfs image as initramfs... | 15:33 |
| ogra | [ 34.684265] Freeing initrd memory: 7128K | 15:33 |
| rcn-ee | yeap, loads and then cleans it up.. | 15:33 |
| ogra | wait, no change ? i.e. it still gets you a login prompt | 15:33 |
| rcn-ee | yeap, command prompt still comes up... | 15:34 |
| ogra | but you dropped the rootwait ? | 15:34 |
| rcn-ee | yeap: [ 0.000000] Kernel command line: console=ttyS2,115200n8 console=tty0 root=/dev/mmcblk0p2 ro vram=12M omapfb.mode=dvi:1280x720MR-16@60 | 15:34 |
| rcn-ee | rootwait is only really useful for usb rootfs... | 15:34 |
| rcn-ee | the sd card is happy without it.. | 15:35 |
| ogra | i need it here to make the kernel not panic | 15:35 |
| rcn-ee | which board do you have again? | 15:35 |
| ogra | revB | 15:36 |
| rcn-ee | this is on a B5, hopefully you don't have a really old B3/4 | 15:36 |
| ogra | i do :) | 15:36 |
| ogra | [ 45.171386] VFS: Cannot open root device "mmcblk0p2" or unknown-block(0,0) | 15:36 |
| ogra | [ 45.178344] Please append a correct "root=" boot option; here are the available partitions: | 15:36 |
| ogra | [ 45.186889] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) | 15:36 |
| ogra | OMAP3430-GP rev 2, CPU-OPP2 L3-133MHz | 15:37 |
| ogra | its really old :) | 15:37 |
| rcn-ee | That's very weird.. are you: Ubuntu-2.6.33-500.2 or Ubuntu-2.6.33-500.1 | 15:37 |
| rcn-ee | same core here.. ;) | 15:38 |
| ogra | 500.2 | 15:38 |
| ogra | ah, no its some kernel amitk uploaded for testing for me | 15:38 |
| ogra | saldy my rootfs is ext4 (default) and there are ext4 issues atm so i cant try building an initramfs | 15:39 |
| amitk | ogra: that kernel is equivalent to 500.2 | 15:39 |
| ogra | yeah, i thought so | 15:39 |
| rcn-ee | yeah, 500.1 won't do anything.. other then uncompressing.. | 15:39 |
| ogra | yep | 15:39 |
| amitk | the lack of initramfs is the reason for most of those issues, including the rtc one. | 15:40 |
| ogra | amitk, right, we just try to solve that :) | 15:40 |
| amitk | I am in two minds whether to compile everything in now and then make them modules again when we have installable images with initramfs | 15:40 |
| ogra | but see above | 15:40 |
| ogra | [ 33.773162] Trying to unpack rootfs image as initramfs... | 15:41 |
| ogra | [ 34.684265] Freeing initrd memory: 7128K | 15:41 |
| ogra | so it loads but doesnt exec it | 15:41 |
| amitk | initramfs size related? | 15:41 |
| ogra | 7M shouldnt be to bad | 15:41 |
| rcn-ee | amitk, full log: http://pastebin.com/h8Hq2Ksh | 15:41 |
| ogra | well, 7M is a lot ... but still should work | 15:42 |
| * amitk will be back in a few | 15:42 | |
| rcn-ee | and it might be a kernel bug, we've never used an initrd in angstrom.. ;) | 15:42 |
| ogra | ogra@babbage2:~$ ls -lh /boot/initrd.img-2.6.31-605-imx51 | 15:42 |
| ogra | -rw-r--r-- 1 root root 3.8M 2010-03-12 09:57 /boot/initrd.img-2.6.31-605-imx51 | 15:42 |
| ogra | rcn-ee, i think the ubuntu kernel uses the proper options for booting initramfs | 15:42 |
| plars | asac: sorry for the delay, on holiday today and away alot | 15:43 |
| plars | asac: probably the most critical issue I found was bug #540477 | 15:43 |
| ubot4` | Launchpad bug 540477 in xorg-server (Ubuntu) "X restarted, but no .crash file (affects: 1)" [Undecided,New] https://launchpad.net/bugs/540477 | 15:43 |
| plars | asac: it's annoying, but can be worked past, and I think is a dup of an issue that was also seen on x86 | 15:44 |
| plars | asac: which is supposed to already be fixed, we just didn't catch the right version | 15:44 |
| rcn-ee | we are about 7M -rwxr-xr-x 1 root root 7.0M 2010-03-19 10:17 uInitrd | 15:44 |
| ogra | ogra@beagle:~$ ls -lh /boot/initrd.img-2.6.33-500-omap | 15:44 |
| ogra | -rw-r--r-- 1 root root 2.1M Jan 1 00:02 /boot/initrd.img-2.6.33-500-omap | 15:44 |
| ogra | though it might not contain everything, i get a lot of ext4 errors while rolling it | 15:45 |
| plars | asac: also, I believe that GrueMaster hit some bad problems with the netboot images | 15:45 |
| rcn-ee | yeah, i haven't had good luck with ext4 on my beagles yet, whereas cwillu_at_work as been using brtfs just fine... | 15:45 |
| plars | bug #541399 on dove, and bug #541029 on imx51 | 15:45 |
| ogra | well, ext4 is the default ubuntu uses | 15:45 |
| ubot4` | Launchpad bug 541399 in linux-mvl-dove (Ubuntu) "netboot image fails to boot. (affects: 1)" [Undecided,New] https://launchpad.net/bugs/541399 | 15:45 |
| ubot4` | Launchpad bug 541029 in linux-fsl-imx51 (Ubuntu) "netboot image fails to connect to the network (affects: 1)" [Undecided,New] https://launchpad.net/bugs/541029 | 15:45 |
| plars | asac: ^ | 15:45 |
| ogra | so the beagle images will use that too | 15:46 |
| asac | plars: X crash ... reproducible? | 15:46 |
| plars | asac: yes | 15:46 |
| plars | asac: boot, press enter | 15:46 |
| ogra | (unless you pick something differently on purpose) | 15:46 |
| asac | ok gdm bug | 15:46 |
| asac | can you make the title better for bug 540477 ? | 15:46 |
| ubot4` | Launchpad bug 540477 in xorg-server (Ubuntu) "X restarted, but no .crash file (affects: 1)" [Undecided,New] https://launchpad.net/bugs/540477 | 15:46 |
| asac | thats a awful title ;) | 15:46 |
| ogra | asac, plars, huh ? i thought that was fixed with the last plymouth upload | 15:46 |
| ogra | (it was a plymouth bug afaik) | 15:47 |
| plars | ogra: I didn't check the version we had in that particular image, and can't really from where I'm at right now | 15:47 |
| plars | ogra: but yes, sounds like the same issue | 15:47 |
| persia | plars: Do you know which image it was? | 15:47 |
| rcn-ee | ogra, for refeence, what uboot version on your bx? | 15:48 |
| ogra | rcn-ee, U-Boot 1.1.4 (Apr 2 2008 - 13:42:13) | 15:48 |
| plars | persia: candidate image on iso tracker - 20100317 | 15:48 |
| ogra | the one that was in NAND | 15:48 |
| rcn-ee | ouch.. ;) i think we still have one of those laying around, going to track it down and try the latest u-boot for comparison.. | 15:49 |
| * cwillu_at_work pokes his head in | 15:49 | |
| cwillu_at_work | what's the problem with ext4? | 15:50 |
| ogra | it makes my kernel panic | 15:50 |
| ogra | but that might be a .33 bug, who knows | 15:50 |
| cwillu_at_work | that was the "cannot find rootfs"? | 15:50 |
| ogra | no | 15:51 |
| ogra | i can boot just fine but as soon as i start FS operations it spills lots of errors and at some point panics | 15:51 |
| cwillu_at_work | re: rootwait, I've always needed it | 15:51 |
| ogra | you dont with initramfs :) | 15:51 |
| ogra | but yes, without i also always needed it | 15:52 |
| persia | plars: libplymouth2 0.8.0~-16 | 15:52 |
| ogra | thats what made me curious in rcn-ee's boot | 15:52 |
| ogra | persia, outdated | 15:52 |
| cwillu_at_work | and this isn't something like a journal having worn out a section of an sd card because there was lots of writes performed while it was nearly full, right? :p | 15:53 |
| cwillu_at_work | been bit by that more times than I care to admit | 15:53 |
| cwillu_at_work | (hence the btrfs :p) | 15:53 |
| ogra | no, the SD is new | 15:53 |
| ogra | 4GB and only carries ubuntu-minimal yet | 15:53 |
| persia | ogra: Right. Just confirming because plars couldn't look it up. | 15:53 |
| ogra | ~17 has the fix | 15:53 |
| ogra | https://launchpad.net/ubuntu/+source/plymouth/0.8.0~-17/+build/1566604 | 15:54 |
| ogra | and obviously built fine | 15:54 |
| plars | right, so it *should* be fixed in the latest... just need to confirm that | 15:54 |
| ogra | i wonder why its not on the image | 15:54 |
| persia | Right, just needed a respin. | 15:54 |
| persia | No respin, probably. | 15:54 |
| ogra | aah | 15:54 |
| persia | But too late now. | 15:54 |
| ogra | it was only uploaded last night | 15:54 |
| persia | Yes, which is why beta was delayed. | 15:54 |
| * ogra didnt notice since KEybuk is raving about the fix since a week | 15:55 | |
| persia | But nobody did the release coordination to get respins for all three images. | 15:55 |
| ogra | i thought he had uploaded it since ages | 15:55 |
| persia | (-server is actually from the 15th still) | 15:55 |
| persia | Could have been stuck in unapproved | 15:55 |
| rcn-ee | ogra, just tested on the oldest bx board i have (b4) it boots, follow this for the latest uboot http://elinux.org/BeagleBoardUbuntu#Upgrade_U-Boot there is a lot of issues with 1.1.4... | 15:58 |
| plars | asac: there are also some other issues like 528887, that are medium, and thus not typically marked RC by default. However, I think they are likely important/annoying enough that we should make sure they are addressed before release | 15:58 |
| plars | bug #528887 | 15:58 |
| ubot4` | Launchpad bug 528887 in maximus (Ubuntu Lucid) (and 2 other projects) "maximus does not give default focus to newly started apps in combination with efl launcher (affects: 2)" [Medium,Triaged] https://launchpad.net/bugs/528887 | 15:58 |
| rcn-ee | and make sure to follow the 'old' notes in that section.. | 15:58 |
| ogra | rcn-ee, heh, my initrd boots fine here | 16:00 |
| rcn-ee | what? cool.. | 16:00 |
| asac | plars: maximus is on our RC list atm | 16:00 |
| ogra | http://paste.ubuntu.com/397873/ | 16:00 |
| asac | https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid | 16:00 |
| asac | plars: ^^ | 16:00 |
| plars | asac: ok, good | 16:00 |
| asac | i will try to get some support fo rthat | 16:01 |
| ogra | rcn-ee, try fatload mmc 0:1 0x80000000 uImage; fatload mmc 0:1 0x81600000 uInitrd; bootm 0x80000000 0x81600000 | 16:01 |
| ogra | though i'm worried about the size of your initrd | 16:02 |
| ogra | mine definately only has 2.1M | 16:02 |
| amitk | ogra: rcn-ee: so initramfs issue fixed? | 16:05 |
| ogra | amitk, well see the above paste ... | 16:05 |
| ogra | http://paste.ubuntu.com/397873/ | 16:06 |
| * amitk likes it when problems get fixed behind his back | 16:06 | |
| ogra | though ext4 bugs me hard | 16:06 |
| ogra | i cant modprobe rtc atm | 16:06 |
| amitk | ogra: please file a bug on ext4, csurbhi is tracking those | 16:06 |
| ogra | will do | 16:06 |
| rcn-ee | i haven't looked at the rtc yet to see if it's enabled right either.. ;) | 16:06 |
| amitk | it is a module | 16:07 |
| ogra | yeah | 16:07 |
| amitk | as I said before, I am in two minds whether to compile everything in now and then make them modules again when we have installable images with initramfs | 16:07 |
| ogra | ogra@beagle:~$ ls /lib/modules/2.6.33-500-omap/kernel/drivers/rtc | 16:07 |
| ogra | [ 425.706848] EXT4-fs error (device mmcblk0p2): ext4_lookup: deleted inode referenced: 128377 | 16:07 |
| ogra | ls: cannot access /lib/modules/2.6.33-500-omap/kernel/drivers/rtc: Input/output error | 16:07 |
| ogra | i would love to load it :) | 16:07 |
| ogra | amitk, i'll have images next week | 16:08 |
| amitk | heh, your ext4 rootfs might be fried | 16:08 |
| ogra | dont put time into it | 16:08 |
| rcn-ee | the address didn't change it for me, same as the last, although i forgot to log the boot... | 16:08 |
| ogra | initramfs and bootloaders were my main concern | 16:08 |
| ogra | both should be done on the weekend | 16:08 |
| ogra | the rest is image build scripts fiddling | 16:08 |
| rcn-ee | exactly.. ;) you guys have a shippment of xm boards coming in right? | 16:09 |
| amitk | already have 'em | 16:09 |
| rcn-ee | cool, i haven't got mine to boot yet either, so that's going to be fun this weekend.. | 16:10 |
| rcn-ee | 0x8000000, doesn't help the initd.. http://pastebin.com/E22QL3iW as far as the size, i just ran 'sudo update-initramfs -c -k 2.6....' on the beagle... | 16:13 |
| amitk | rcn-ee: 500.2 ought to boot on XM | 16:13 |
| rcn-ee | cool, i'll try that in an hour over lunch, i was trying to get my 2.6-dev (2.6.32) to work.. | 16:14 |
| amitk | rcn-ee: I'm going to concentrate on core functionality next week (DSS2/PM) instead of flipping modules to built-ins since ogra will have images for us next week | 16:14 |
| rcn-ee | okay sounds good, get it working first, then move stuff around.. ;) I'll cleanup my dss2 patch in my 2.6.33 tree to easily merge into yours... | 16:17 |
| ogra | rcn-ee, weird initramfs works even with a newer uboot here with the same commands | 16:17 |
| ogra | U-Boot 2009.11 (Feb 24 2010 - 10:58:59) | 16:17 |
| rcn-ee | i guess i'm confused... where's the best indicator the initrd worked. ;) | 16:18 |
| ogra | Loading, please wait... | 16:18 |
| ogra | thats printed from /init in initramfs | 16:18 |
| ogra | and all the: "Running /scripts/...." lines | 16:19 |
| asac | bug 541399 | 16:19 |
| ubot4` | Launchpad bug 541399 in linux-mvl-dove (Ubuntu) "netboot image fails to boot. (affects: 1)" [Undecided,New] https://launchpad.net/bugs/541399 | 16:19 |
| rcn-ee | ahh.. okay, i'll look for that... | 16:19 |
| ogra | rcn-ee, probably drop console=tty0 ;) | 16:19 |
| ogra | or attach a monitor | 16:19 |
| rcn-ee | i can do that... monitor is attached, but dss2 isn't patched to work yet... ;) | 16:20 |
| ogra | initramfs will definately spit out messages on the second console arg you set (if you set one) | 16:20 |
| ogra | well, then just drop it from cmdline | 16:20 |
| ogra | that should show the messages on serial | 16:20 |
| DanaG | hmm, I set it this way: console=tty0 console=ttyS2,115200n8 | 16:23 |
| DanaG | the second one is the one that gets kernel stdin, stdout, stderr. | 16:23 |
| rcn-ee | bingo, that did it.. http://pastebin.com/Y42WTD3S .... ;) so it's loading the initd... | 16:24 |
| DanaG | Starting kernel ... | 16:24 |
| DanaG | Uncompressing Linux... | 16:24 |
| DanaG | uncompression error | 16:24 |
| DanaG | -- System halted | 16:24 |
| DanaG | hmm, it might be good to revise install-me.sh to allow it to work on host system (without dpkg -i step, of course). | 16:26 |
| rcn-ee | no usb devices.. back to the config from this morning.. it doesn't look like it can be an external module .. http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fstable%2Flinux-2.6.33.y.git&a=search&h=HEAD&st=grep&s=CONFIG_USB_MUSB_HDRC | 16:26 |
| rcn-ee | Yeah, DanaG i was thinking, if arch != arm stop. .. ;) | 16:27 |
| DanaG | On my host, mmcblk0p1 is still mmcblk0p1. | 16:27 |
| ogra | rcn-ee, yeah, i was suspecting that, you dropping rootwait and cwillu_at_work confirming it's needs somehow indicated that :) | 16:28 |
| DanaG | so, install-me.sh works if I do "dpkg -i ... || true" | 16:28 |
| DanaG | weird... uncompression error on 2.6.33.1-dl2 | 16:28 |
| rcn-ee | but it could be as simple as... ". install-me.sh" -> arm... ". install-me.sh /dev/sdb1" -> on x86... | 16:28 |
| DanaG | ah yeah. | 16:28 |
| DanaG | Oh, and perhaps check if partition is already mounted somewhere. | 16:29 |
| DanaG | Or even better: pass it the dir, not the device. | 16:30 |
| DanaG | okay, so 33.1-dl2 doesn't uncompress. | 16:31 |
| rcn-ee | It just dies before uncompression? | 16:32 |
| DanaG | Yeah. | 16:36 |
| DanaG | Starting kernel ... Uncompressing Linux... uncompression error -- System halted (replaced line-breaks with 8 spaces.) | 16:37 |
| amitk | DanaG: could be your addresses? Kernel overwriting itself? | 16:37 |
| rcn-ee | DanaG, it's close to lunch, so i'm going to put on my c4 lucid and test... | 16:38 |
| DanaG | You can do that after your lunch, if you want. =þ | 16:39 |
| rcn-ee | nah, then i can 'unbrick' it during lunch.. ;) i run home... | 16:39 |
| rcn-ee | yeap, bricked it... 2.6.33.1-dl2 is bad.. | 16:40 |
| rcn-ee | what's weird, it's based off the head of https://code.launchpad.net/~beagleboard-kernel/+junk/2.6-dev when i cross built in the lab for lucid/squeeze but with angstrom's 4.3.3... i'll investigate it tonight... | 16:41 |
| rcn-ee | 2.6.33-dl1 had been fine on that machine... | 16:42 |
| DanaG | handily for me, I just stick the card back in my host laptop and replace uimage. | 16:42 |
| rcn-ee | i just saw sd cards between running beagles and run install-me.sh again.. ;) | 16:43 |
| rcn-ee | saw/swap | 16:43 |
| ogra | tsk | 16:45 |
| ogra | just dont break your installs all the time :) | 16:45 |
| rcn-ee | hehe.. it's okay, that's the 2.6-dev branch.. things are allowed to break... ;) 2.6-stable now that can't ever break.. ;) i removed it from rcn-ee.net, so it shouldn't propgate to the mirrors... | 16:47 |
| rcn-ee | what's scarry, it was just the kernel stable bump to 2.6.33.1... | 16:47 |
| === asac__ is now known as asac_ | ||
| === asac_ is now known as asac_the_2nd | ||
| === powderluv_ is now known as powderluv | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!