**** BEGIN LOGGING AT Mon Mar 08 02:59:57 2010 Mar 08 03:32:41 how to use the qemu in the rootstock Mar 08 03:34:16 You'll have to wait at least 5 hours for good rootstock support. Mar 08 05:47:35 hi guys i dont see the mini2440 as being a supported board is possible and just untested ? Mar 08 05:49:25 * persia tries to figure out what a "mini2440" is Mar 08 05:49:45 tkmedia: It might be able to run Jaunty, but nothing newer. Mar 08 05:49:55 I'd recommend using Debian on that platform. Mar 08 05:50:10 (assuming we're talking about a board with a Samsung S3C2440A ARM920T ) Mar 08 05:50:26 yes thankyou Mar 08 05:50:55 Glad to help. If you decide to run Jaunty, the install may be a bit tricky, but ought work. Mar 08 05:51:18 intrepid actually would be nice Mar 08 05:51:24 If you decide to run Debian, the install may be a bit tricky, but you should have continued support for longer (Jaunty runs out of support in October). Mar 08 05:51:36 Intrepid wasn't compiled for armel. Mar 08 05:51:41 k Mar 08 05:52:05 whats the best way to try jaubty Mar 08 05:52:14 juanty Mar 08 05:53:53 Do you have a working 2.6.28 or newer kernel for the board? Mar 08 05:54:09 2.6.29 Mar 08 05:54:17 That ought work. Mar 08 05:54:30 Do you have a local Ubuntu install from which to prep stuff? Mar 08 05:54:42 (if so, which release?) Mar 08 05:54:51 i have severla vm's Mar 08 05:55:05 ones a 0910 Mar 08 05:55:27 OK. So the easiest way to get a rootfs is probably to run rootstock in the 9.10 environment. Mar 08 05:55:35 yep did that Mar 08 05:55:44 And you created a jaunty rootfs? Mar 08 05:56:10 hmm let me chk Mar 08 05:56:25 i used the example Mar 08 05:56:38 with minal lxde Mar 08 05:57:28 Which example? Mar 08 05:57:38 top Mar 08 05:57:45 From which page? Mar 08 05:57:51 sec Mar 08 05:58:29 sudo rootstock \ Mar 08 05:58:30 --fqdn myhostname \ Mar 08 05:58:32 --login ubuntu \ Mar 08 05:58:33 --password temppwd \ Mar 08 05:58:34 --imagesize 2G \ Mar 08 05:58:36 --seed xubuntu-desktop Mar 08 05:58:39 but changed seed Mar 08 05:58:45 to lxde Mar 08 05:58:49 Right. Mar 08 05:58:49 ,gdm Mar 08 05:59:21 so that should work with the .29 kernel right? Mar 08 05:59:30 Yes, but. Mar 08 06:00:21 You want to add --dist jaunty Mar 08 06:00:22 kernel panic Mar 08 06:00:28 The default is --dist karmic Mar 08 06:00:28 ahhh Mar 08 06:00:41 And that will generate binaries that include instructions not supported on your chip. Mar 08 06:00:56 ok cool Mar 08 06:01:17 So try again, and if that doesn't work, please ask again. Mar 08 06:01:20 so thats why i got kernel panic ? Mar 08 06:01:34 I'm not sure, but possibly. How did you construct your kernel? Mar 08 06:01:46 Are you sure your kernel works? Mar 08 06:01:50 yes Mar 08 06:02:10 let mtry with dist-juanty Mar 08 06:02:19 If you're sure the kernel works, then yeah, I'd blame the rootfs, especially if I expected the rootfs to generate instructions the processor can't handle. Mar 08 06:02:26 "jaunty" Mar 08 06:02:43 and will be back if any more questions Mar 08 06:02:46 thanks Mar 08 06:02:51 Good luck! Mar 08 06:03:26 so just -dist jaunty on the bottom Mar 08 06:03:43 added Mar 08 06:12:10 hmm, weird thing about the rcn-ee images: the ubuntu username isn't uid 1000. Mar 08 06:12:17 same for GID: not 1000. Mar 08 06:49:30 DanaG: It isn't on the Live CD either, since that would conflict with installed systems Mar 08 06:49:44 (And then you could potientally read other users files) Mar 08 06:52:06 Though, with livecd, you can read them anyway, as root. Mar 08 06:52:29 And the UID was like 1002 (which still could collide), and the image was an installed system. Mar 08 06:53:35 Right, but that falls under "You have physical access, so ..." Mar 08 06:55:20 Oh, and the UID of things like "fuse" were different too. Mar 08 06:55:54 I fiddled with the things a bit, and made them match better (along with finding files that were owned by corresponding old UID, and chowning them. Mar 08 06:58:52 hello Mar 08 07:00:29 can somebody help me? Mar 08 07:02:19 go ahead and ask the issue itself, instead of just asking if anyone's around. =þ Mar 08 07:05:02 ok, I have PDA Asus A363 can I install ubuntu on this device? Mar 08 07:06:07 hmm, you'd have to find out more about what the chip is, for one. Mar 08 07:07:08 one moment Mar 08 07:07:45 processor type - Intel XScale PXA272 416 MHz Mar 08 07:08:09 weird, I see nothing about "asus a363" on the internet. Mar 08 07:08:22 er, not "nothing", but not too much. Mar 08 07:08:23 ROM 128 Mb, RAM 64 Mb Mar 08 07:08:30 64 megs RAM is tiny. Mar 08 07:09:24 http://vip.asus.com/forum/view.aspx?id=20070507004052843&board_id=6&model=MyPal+A636&SLanguage=en-us&page=2 Mar 08 07:11:25 :) I don`t like a Windows Mar 08 07:11:37 I want ubuntu ;) Mar 08 07:13:46 gevz: OK. What device do you have? Mar 08 07:14:37 A363 Mar 08 07:15:10 ASUS MyPal A363? Mar 08 07:15:14 yes Mar 08 07:15:59 OK. According to http://www.handhelds.org/moin/moin.cgi/MyPal you should be able to run linux Mar 08 07:16:14 Or maybe not Mar 08 07:16:17 * persia looks harder Mar 08 07:17:01 Really a A363 and not a A636> Mar 08 07:17:10 s/>/?/ Mar 08 07:18:16 I can't find any information about the A363, unfortunately. Mar 08 07:18:30 The A626 can run Linux, but only Ubuntu 9.04 and nothing newer. Mar 08 07:18:45 The resolution is also low enough the experience may leave something to be desired. Mar 08 07:18:51 I'd recommend Debian for such a device. Mar 08 07:18:54 oh... excuse me, I mistake Mar 08 07:19:04 A636 Mar 08 07:19:05 Which is the mistake? Mar 08 07:19:09 Ah, that's better :) Mar 08 07:19:10 not A363 Mar 08 07:20:02 But yeah, for the A636 you can run Jaunty if you hack it. Mar 08 07:20:29 how i can do it? Mar 08 07:20:48 I'd recommend starting from http://www.handhelds.org/moin/moin.cgi/A636 Mar 08 07:21:04 Once you have figured out how to install linux, installing Debian or Ubuntu becomes easier. Mar 08 07:25:14 ok, I do not quite understand where I start Mar 08 07:26:13 this link to list of hardware, but I can`t understand how to install linux? Mar 08 07:27:10 For devices of that class, one usually has to construct a replacement firmware and proceed with the "firmware upgrade" procedure. Mar 08 07:27:34 I recommend searching for available documentation carefully, as there is a risk you can make the device unbootable. Mar 08 07:28:07 I don't see any good guides from a quick search myself. Mar 08 07:28:33 ok, please help me Mar 08 07:29:20 I have compiled a list of equipment, what next? Mar 08 07:31:52 I'm really not sure how to help, and don't want to give advice that will make your device useless. Mar 08 07:32:03 The next step is to understand how the device boots. Mar 08 07:32:22 Once you have that, compile a customised kernel, and get the device to boot that kernel. Mar 08 07:32:33 Once you have that, you can start considering what you want for a filesystem. Mar 08 07:32:53 But the first two steps are big ones. Mar 08 07:34:02 What image do I download ubuntu? Mar 08 07:34:19 There exists no image of Ubuntu that will work on your hardware. Mar 08 07:34:33 You can potentially construct something that works, but it's non-trivial. Mar 08 07:34:50 ok, thanx Mar 08 07:35:11 I ran "sudo ~/bin/qemu-debootstrap --arch=armel lucid lucid-armel-chroot http://rie:3142/ports.ubuntu.com/ubuntu-ports", but the chroot sources.list file does not contain any entries for package sources. Mar 08 07:35:16 Is that to be expected? Mar 08 07:35:28 Yes. Mar 08 07:36:18 hm Mar 08 07:36:21 please explain Mar 08 07:36:38 I kind of expected the file to be populated, obviously. Mar 08 07:36:44 I don't believe debootstrap automatically populates that. Mar 08 07:36:54 So this is expected behaviour. Mar 08 07:37:08 let's rephrase the question Mar 08 07:37:17 From your ability to run that command, I presume you're using lucid. Mar 08 07:37:19 Shouldn't debootstrap populate the file? Mar 08 07:37:22 No. Mar 08 07:37:29 why not? Mar 08 07:37:33 I run lucid, yes Mar 08 07:38:07 So, if you want to create a chroot for use, I'll recommend you use `mk-sbuild --arch=armel lucid` Mar 08 07:38:22 This will work, populate everything, and give you a summary of ways to use the chroot. Mar 08 07:38:23 lool: asked me to test his scripts Mar 08 07:38:43 Oh, if that's what your're doing, then you're doing it right. Mar 08 07:38:43 and I don't mind a few rough edges here or there Mar 08 07:40:00 why do you think debootstrap ought not to populate sources.list? Mar 08 07:40:20 because there's extensive logic in mk-sbuild to populate it after the debootstrap run. Mar 08 07:40:28 gevz: you may also have a look at openembedded Mar 08 07:40:57 what this? Mar 08 07:41:07 gevz: google should tell you Mar 08 07:41:19 I have ban on google ;) Mar 08 07:41:22 or any other search tool, really. Mar 08 07:41:28 Then use something else :) Mar 08 07:41:52 Laibsch: morning Mar 08 07:42:10 gevz: OE is very well suited for your problem of getting a kernel compiled Mar 08 07:42:18 lool: good morning Mar 08 07:42:36 OE is also well suited to that class of device. Mar 08 07:42:50 probably Mar 08 07:43:06 * Laibsch hopes to lower the bar for ubuntu-arm eventually Mar 08 07:43:23 But I fully support the decision to focus on more powerful devices first Mar 08 07:43:54 Laibsch: Not first: only. We expect the market to catch up with us by the time we're sorted. Mar 08 07:44:38 yes, I was afraid that may be the case Mar 08 07:44:58 There ain't nobody there to tell me I can't try, though ;-) Mar 08 07:45:20 Speaking of which Mar 08 07:45:35 persia: (from this night) ARM920T + jaunty isn't going to work I'm afraid Mar 08 07:45:45 Now that I have my armv7l chroot, how would I go about trying to compile armv5te software? Mar 08 07:46:06 what knobs do I need to fiddle with? Mar 08 07:46:17 lool: No? Why not. Mar 08 07:46:34 Laibsch: You need to change the compiler defaults. Mar 08 07:46:50 Laibsch: debootstrap is now expected to create a binary sources.list, but most people don't need source entries, so it defaults to disabled for these Mar 08 07:47:00 Laibsch: sbuild usually pulls the source by its own means IIRC Mar 08 07:47:07 persia: ARM920T is v4 Mar 08 07:47:16 lool: Ah. So it needs to be ARM11+ ? Mar 08 07:47:27 I thought it was ARM9+ Mar 08 07:47:27 I think some ARM9xxs are v5, but rare Mar 08 07:47:49 Best to check the wikipedia page Mar 08 07:47:50 That makes sense. Still, I think anyone with older hardware should be running Debian anyway. Mar 08 07:47:56 yes Mar 08 07:48:02 It's frustrating to get stuck not being able to upgrade. Mar 08 07:48:34 Anyway, sbuild doesn't do anything special with sources.list. It just presumes that one exists in the chroot. Mar 08 07:48:44 mk-sbuild populates one based on the arguments it gets passed. Mar 08 07:48:54 persia: where are those changed? Mar 08 07:49:05 Laibsch: Which? Mar 08 07:50:45 the compiler defaults Mar 08 07:50:52 so that I can compile for armv5te Mar 08 07:50:57 No idea. I'd guess in the gcc package. Mar 08 07:51:59 lool: ? Mar 08 07:52:08 I guess the question can be put another way Mar 08 07:52:28 who changed what where to specify that lucid is armv7l? Mar 08 07:52:36 I'll just turn that back locally ;-) Mar 08 07:52:38 Laibsch: gcc-4.4 package Mar 08 07:52:42 we configure it with the defaults Mar 08 07:53:01 Laibsch: I'm not sure you realize how long and complex and heavy that's going to be Mar 08 07:53:39 It's not impossible, but building gcc-4.4 takes days espcially under qemu or older v5 hardware Mar 08 07:53:42 probably Mar 08 07:53:59 Then you need to bootstrap everything such as eglibc, binutils etc. Mar 08 07:54:01 I don't mind days of compilation Mar 08 07:54:19 Laibsch: You intend to build on v5 hardware? Mar 08 07:54:21 When I started with OE my machine was seriously underpowered (it kind of always was) Mar 08 07:54:30 It took about a week to build the toolchain for me Mar 08 07:54:47 and things broke often, so it may have been a month before I had anything working Mar 08 07:54:49 You should expect a similar amount of pain. Mar 08 07:55:00 not a big problem Mar 08 07:55:12 especially since I can always use OE-compiled software Mar 08 07:55:22 But I want to move slowly away Mar 08 07:55:30 uh? Mar 08 07:55:33 I think native compilation makes more sense Mar 08 07:55:38 Laibsch: If you intend to build on v5 hardware, the easiest path for you (in terms of man hours) is probably to build the Ubuntu toolchain source packages after changing their defaults inside a Debian armel chroot Mar 08 07:55:45 Laibsch: tired of OE? :p Mar 08 07:55:51 ynezz: yes Mar 08 07:56:14 but basically I understood that OE is not the right tool going into the future Mar 08 07:56:16 for me Mar 08 07:56:34 I'm looking more for a desktop experience on the devices I have Mar 08 07:56:41 isn't it more about koen? Mar 08 07:56:50 Openembedded is of course, more embedded Mar 08 07:57:03 yes and no Mar 08 07:57:10 ok Mar 08 07:57:30 I sat down and thought about if OE gives me what I need Mar 08 07:57:43 and if it's going in the direction I want it to go Mar 08 07:58:19 I've been with OE for 5 years and I'd say OE has never managed to put out anything usable for end-users Mar 08 07:58:34 I don't see that changing and I'm more of an end-user Mar 08 07:58:55 My hope is ubuntu-arm/debian-arm will eventually be able to output something usable for the ordinary user Mar 08 07:59:14 [02:45] persia: (from this night) ARM920T + jaunty isn't going to work I'm afraid Mar 08 07:59:25 tkmedia: Sorry about that. My mistake. Mar 08 07:59:31 hmm looks like troouble Mar 08 07:59:33 np Mar 08 07:59:46 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3) Mar 08 07:59:50 tkmedia: Should be able to run Debian, I'd think. Mar 08 08:00:11 k Mar 08 08:00:25 Laibsch: I've started using ubuntu for the same reason, for headless boards with 32MB RAM is OE the best... Mar 08 08:00:29 Congratulation of all women in this chatroom with 8 March!!! Mar 08 08:00:44 bye Mar 08 08:01:35 how can you tell which ver arm the device will run Mar 08 08:02:15 http://en.wikipedia.org/wiki/ARM_architecture gives some useful guidance Mar 08 08:02:31 ynezz: yes, I agree that for the seriously low-powered devices and embedded devices, OE still makes a lot of sense. But that's not necessarily my area of interest. I hope I can lower the bar enough so that the spitz becomes usable. Otherwise, I'll have to wait for some sexy hardware (the Palm Pre might be something I like) Mar 08 08:02:58 cooloney: Do you happen to know if our kernels do anything with XN ? Mar 08 08:03:17 tkmedia: This is not related to jaunty thouhg Mar 08 08:03:45 tkmedia: a binary incomptibility would show up as a sigill, like init being killed Mar 08 08:06:16 ok what is a good dev board .... i like the beagle boards but want a 7" lcd like the samsung Mar 08 08:10:50 tkmedia: DO you need 7"? The NetWalker has 5" and is a complete netbook to boot. Mar 08 08:12:17 prefer a little larger but will look into it thanks Mar 08 08:13:08 You could also get one of the 7" USB displays. As long as you get one that uses DisplayLink it ought to work with lucid+ Mar 08 08:13:21 (or if it doesn't, complain to me about it, and I'll try to fix that) Mar 08 08:13:49 tkmedia: in month or so, there should be LCD+Touchscreen avialable for BB from Tincantools Mar 08 08:14:31 persia: sorry, have no idea about that? what's XN? for fsl-imx51? Mar 08 08:14:32 yes I want something that could be wall mounted Mar 08 08:14:52 tkmedia: Always Innovating Touchbook may be something to check out Mar 08 08:15:19 cooloney: According to the ARM wikipedia page, XN is a technology available in newer ARM cores that it similar to NX for x86. I'd like to see us enable that if we can. Mar 08 08:15:40 Laibsch: Have they solved the shipment delay issue? Mar 08 08:15:48 no idea Mar 08 08:15:58 I was just visiting their homepage this minute Mar 08 08:16:03 which is why I mentioned it Mar 08 08:16:12 what backlog do they have? Mar 08 08:18:04 interesting Mar 08 08:18:15 nice form factor Mar 08 08:18:25 Laibsch: I heard it took a couple months to get delivered. I'd be glad to be wrong. Mar 08 08:19:24 ynezz: I believe specialcomp.com also has some sort of touchscreen, though probably low-res. Mar 08 08:20:04 When I was shopping around for a new netbook last month I had a brief look at it, but was disappointed by 512MB RAM only. So, I went for a pinetrail atom instead :-P I'm very happy so far. Mar 08 08:20:14 DanaG: that show dog board from tincantools should have 800x480 for price about $149 Mar 08 08:20:51 DanaG: 7" Mar 08 08:20:57 forget to mention that Mar 08 08:21:16 what's the difference between zippy and zippy2? Mar 08 08:21:20 ynezz: Which driverdoes it use? Mar 08 08:21:36 I see no LCD at tincantools. Mar 08 08:21:40 persia: dunno :) ask prpplague on #beagle Mar 08 08:21:47 oh yeah, I used these kernels: http://rcn-ee.net/deb/kernel/beagle/ Mar 08 08:22:02 ah, 10/100 in zippy2. Mar 08 08:22:02 DanaG: it should be available in month or so Mar 08 08:22:23 ynezz: Oh, it's a special Beagle expansion? Mar 08 08:22:29 * persia was hoping for something generic Mar 08 08:22:34 persia: ok, i see, just a quick digging Mar 08 08:22:49 cooloney: If you can get that to work, the security team will love you :) Mar 08 08:22:54 it is available since ARMv6 Mar 08 08:23:05 Right, but I don't think we ever turned it on. Mar 08 08:23:18 persia: yes, beagle related Mar 08 08:23:20 #define PMD_SECT_XN (1 << 4) /* v6 */ Mar 08 08:24:42 persia: but i am not sure how to use it. Mar 08 08:24:55 persia: need some time to take a look Mar 08 08:24:56 persia: I think Kees had a look and flipped a logic bug in arm code Mar 08 08:25:03 So I actually think it's working and enabled Mar 08 08:25:33 lool: Really? That's different than what I last heard, but I would be glad to have missed something. Mar 08 08:25:49 cooloney: Cool. Maybe check with kees: if lool is right, nothing to do. Mar 08 08:25:56 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/364358 http://www.outflux.net/blog/archives/2009/11/24/missing-kernel-features-in-arm/ Mar 08 08:26:00 Launchpad bug 364358 in linux (Ubuntu Jaunty) (and 1 other project) "ARM: image is running with READ_IMPLIES_EXEC (affects: 1) (dups: 1)" [Undecided,Fix released] Mar 08 08:26:28 cooloney: ^ Mar 08 08:26:41 So I'm pretty XN works now Mar 08 08:26:42 Cool! Mar 08 08:26:45 +sure Mar 08 08:26:53 I caught the original blog post, but not the followup. Mar 08 08:28:02 what does "ASLR" stand for? Mar 08 08:28:52 http://en.wikipedia.org/wiki/Address_space_layout_randomization Mar 08 08:29:17 Makes it harder to take advantage of buffer overflow exploits, poke exploits, etc. Mar 08 08:35:23 ah. Mar 08 08:35:28 anyway, bedtime now. =þ Mar 08 08:35:36 lool: thanks, Mar 08 08:36:02 cooloney: Did you manage to look into the kexec problem? Mar 08 08:36:03 and from the code arch/arm/mm/mmu.c Mar 08 08:36:20 lool: yeah, we found a way in imx51 and mvl-dove Mar 08 08:36:34 i prepared a kernel package for versatile alreayd Mar 08 08:36:41 and going to test it now Mar 08 08:36:58 if you wanna test, please take a look at this bug Mar 08 08:37:15 https://bugs.launchpad.net/adana/+bug/517841 Mar 08 08:37:16 cooloney: Error: Bug #517841 is private. Mar 08 08:38:17 persia: XN bit is enabled when arch >= ARMv7 Mar 08 08:38:19 http://kernel.ubuntu.com/git?p=roc/ubuntu-lucid.git;a=shortlog;h=refs/heads/kexec-versatile is the branch Mar 08 08:38:24 http://people.canonical.com/~roc/kernel/kexec/ has the binary kernels Mar 08 08:41:21 yeah, Mar 08 08:41:38 but we still have to patch the kexec-tools Mar 08 08:42:51 cooloney: That's fine. Mar 08 08:44:44 Only for initramfs support though Mar 08 08:46:50 lool: do you mean another issue about initramfs on versatile? Mar 08 08:47:05 lool: i saw your config patch was merged Mar 08 08:47:47 cooloney: Didn't yet try with Mar 08 08:47:50 my patch in Mar 08 08:47:59 cooloney: But we should really fix the initramfs issue Mar 08 08:48:07 perhaps it's a similar problem actually! Mar 08 08:48:12 perhaps our kernel is too big! Mar 08 08:48:15 I didn't think of that Mar 08 08:48:45 yeah, the issue is very similar, without patching the kexec-tools to increase the size Mar 08 08:48:54 we can not kexec reboot the kernel Mar 08 08:48:57 cooloney: Question Mar 08 08:49:06 it looks like the similar in qemu Mar 08 08:49:14 cooloney: the kernel knows where it's loaded, how big it is, and where the initramfs is supposed to me Mar 08 08:49:29 cooloney: Don't you think the kernel should test whether kernel start + kernel size < initramfs start? Mar 08 08:50:33 lool: normally, the bootloader should take care of that, such as uboot or qemu Mar 08 08:53:09 cooloney: Don't you think it's a good idea to have such a sanity check to avoid debugging kexec like we did? Mar 08 08:55:45 cooloney: With your kernel, I still can't load initrds *gah* Mar 08 08:55:57 cooloney: I think it's due to the same bug as for kexec, or similar Mar 08 08:56:15 cooloney: Do you have a recipe for converting a vmlinuz to a vmlinux? Mar 08 08:57:00 lool: you wanna try vmlinux, right? i can uploaded for you Mar 08 08:57:06 cooloney: Would be nice, thanks Mar 08 08:57:22 I do see "cramfs" in the list of attempted file systems now; but it doesn't work Mar 08 09:00:03 cooloney: So with your kernel to run qemu and loaded with kexec, it still hangs as before Mar 08 09:00:18 "Starting new kernel" and nothing more Mar 08 09:00:24 ok Mar 08 09:00:54 there is no "Uncompressing...," right? Mar 08 09:01:11 cooloney: Let me try with the serial console trick Mar 08 09:01:14 I get more output in this way Mar 08 09:01:42 * ogra glares at klibc buildlog ... -march=armv4 -mtune=strongarm Mar 08 09:01:43 cooloney: Well using an uncompressed kernel might improve the test; let's try with one Mar 08 09:01:44 hrm Mar 08 09:02:36 lool: no problem, i am uploading, but it will take some time Mar 08 09:02:46 due to the slow connection at my home Mar 08 09:03:05 cooloney: Press the "FAST" button below your modem Mar 08 09:03:20 sometimes it's labeled TURBO instead Mar 08 09:03:34 ogra: Please fix :) Mar 08 09:03:50 persia, well, thats not the cause of the ftbfs Mar 08 09:04:48 Yeah, but :) Mar 08 09:05:22 lool, isnt that a software switch that needs this proprietary program from www.modemspeedier.com ? Mar 08 09:06:49 ogra: Depends on the modem. The better class have external controls that do the same thing as the extended AT sequences. Mar 08 09:07:18 heh Mar 08 09:10:51 cooloney: Updated the kexec/versatile bug Mar 08 09:10:57 lp #518567 Mar 08 09:10:58 Launchpad bug 518567 in linux (Ubuntu) (and 1 other project) "armel/versatile: Can't kexec (affects: 1)" [Undecided,New] https://launchpad.net/bugs/518567 Mar 08 09:14:55 cooloney: Found how to convert the image (I think) Mar 08 09:15:52 Hmm not sure Mar 08 09:16:26 I get no vidoe output, so seems my vmlinux is busted Mar 08 09:18:31 lool: i found 2 vmlinux in my build dir Mar 08 09:18:37 one is 61M, Mar 08 09:18:46 one is 3M, which is not for this Mar 08 09:19:03 lool: or just Image? Mar 08 09:19:13 cooloney: I think we want vmlinux Mar 08 09:19:16 cooloney: but you can strip it Mar 08 09:19:29 vmlinuz is stripped and gzipped which is why it's much smaller Mar 08 09:20:24 My vmlinux is 6.3 MB so that seems about right Mar 08 09:20:29 ok, will do that Mar 08 09:21:56 cooloney: YES! Mar 08 09:22:09 cooloney: So booting your vmlinuz and kexecing the vmlinux I created works Mar 08 09:24:13 cooloney: So don't bother uploading Mar 08 09:24:37 So many problems here, vmlinuz loading broken, vmlinux boot broken, need to test initrd support... Mar 08 09:26:24 ok, understand now Mar 08 09:26:37 you convert the vmlinx from my vmlinuz Mar 08 09:26:42 and kexec that, right? Mar 08 09:27:35 Yes Mar 08 09:28:13 ok, cool Mar 08 09:29:17 ericm_: why do we use CONFIG_OABI_COMPAT=y ? Mar 08 09:29:28 cooloney: That's a good workaround, but would you be interested in chasing the other issues? Mar 08 09:29:43 asac, that's for old ABI binary to be still able to run Mar 08 09:29:58 asac, it's harmless - any issue you found related to this? Mar 08 09:31:04 lool: i'd love to, Mar 08 09:31:15 lool: Are you certain that we don't need to use qemu to support ppc64 on ppc, sparc64 on sparc, and amd64 on i386? Mar 08 09:31:35 persia: I'm not, I applied the same heuristics as the qemu Debian package Mar 08 09:31:46 OK. I'll just follow along then. Mar 08 09:32:07 persia: I think it's only possible to run ppc64 on powerpc if you have ppc64 hardware and you run a 64-bits kernel (with a powerpc 32-bits userspace) Mar 08 09:32:14 ericm_: mvl asked why we still have that. i think they thought it would help if we'd drop it Mar 08 09:32:22 iirc there were also some performance claims Mar 08 09:32:30 lool: I think the same is true in every case in my example. Mar 08 09:32:31 if you say it shouldnt hurt at all, fine. Mar 08 09:32:32 persia: but I don't have hardware and I didn't want to write overly complex code I couldn't test Mar 08 09:32:46 persia: Yes, I'm only giving an example Mar 08 09:34:08 asac, so far no related issues with that Mar 08 09:34:34 ericm_: we could get rid of OABI. We don't care about letting older ABI binaries run on Ubuntu... Mar 08 09:34:42 ericm_: but is there any reason to keep it? e.g. EABI is already really really old Mar 08 09:34:53 right Mar 08 09:35:20 persia: Similarly, it might be possible to use qemu-x86_64-static under i386, but I don't think we actually have a binfmt for that as it might mess up config_32 for users of amd64 hardware with a 64-bits kernel Mar 08 09:35:46 Anyway, if someone wants to support using qemu there and has a patch which I can understand, I'm happy to review + merge it :-) Mar 08 09:36:33 lool: I think you're right, and I don't want to fuss with it enough to try to fix it now. Mar 08 09:36:48 ericm_: I remember that I turned it off on FSL Mar 08 09:37:04 asac, amitk, no specific reason, just want to keep a certain degree of backward compatibility, but it's OK to remove I agree Mar 08 09:37:41 asac, amitk, it's actually not very old, EABI became popular in less than 2 years Mar 08 09:38:17 ericm_: with the distro compiled for armv7+, backward compatibility is not one of our stated goals :) Mar 08 09:38:53 amitk, agree Mar 08 09:38:54 and we want to make sure that we run all EABI code. Debian does a great job of supporting OABI and EABI as it is. Mar 08 09:39:40 Does OABI support hurt? Mar 08 09:39:43 lool: is there any option in qemu to enable a host directory to share with the running qemu virtual system Mar 08 09:39:47 ISTR it caused some weird bugs on dove Mar 08 09:40:01 well, in some cases, that depends on the source code availability to be recompiled with new EABI and new toolchain Mar 08 09:40:02 cooloney: There is, but I don't use it Mar 08 09:40:16 lool: ok, Mar 08 09:40:19 cooloney: Consider either a nfs export if you have that, or just loop mount your image Mar 08 09:40:23 (I do the latter) Mar 08 09:40:28 but it's not always true - esp. in some areas source code is not available, but anyway those are corner cases Mar 08 09:40:57 cooloney: Mar 08 09:40:59 http://people.canonical.com/~lool/loop-mnt-do Mar 08 09:41:09 lool, I don't think OABI support is harmful - so far no evidence Mar 08 09:41:10 cooloney: loop-mnt-do some.img Mar 08 09:41:25 ericm_: I think there was a suspend resume bug under dove triggered by this config Mar 08 09:41:48 lool, that's caused by other issue but could be worked around by turning this option off Mar 08 09:42:00 lool, Marvell has provided a right fix to that bug Mar 08 09:42:02 lp #453682 Mar 08 09:42:03 Launchpad bug 453682 in linux-mvl-dove (Ubuntu Karmic) (and 2 other projects) "late resume failure on dove (affects: 2)" [High,Fix released] https://launchpad.net/bugs/453682 Mar 08 09:42:29 ericm_: I agree, this bug is fixed, I just don't know whether OABI_COMPAT is exposing us to more of such bugs, or whether it's truly harmless Mar 08 09:44:36 lool, so far none - I tend to keep a certain backward compatibility, but as amitk said, this might not be necessary, and I'm totally fine to turn this off if everyone agrees Mar 08 09:44:42 The only other reasons I can think of to drop it: * size of the kernel (but then it's a pig anyway), * security issue in one of the OABI code pathes (no track thereof until now though) Mar 08 09:45:12 lool, fair enough Mar 08 09:45:16 ericm_: Frankly, I have no opinion either way; I'm just curious of what would justify the config either way -- as to be able to answer questions on this choice Mar 08 09:46:22 I didn't face someone running an OABI binary on Ubuntu so far, and didn't have to run one myself; perhaps it's useful for e.g. flash tools or proprietary software like skype or flash? no idea really Mar 08 09:46:30 lool, could you include me in the CC loop when discussing these config options with Marvell, I know they intend to keep their kernel config as close as ours so to minimize the future developing effort Mar 08 09:46:32 i doubt it Mar 08 09:46:43 ericm_: I actually don't discuss this with marvell myself Mar 08 09:46:50 (flash/skype) Mar 08 09:47:09 ericm_: If I ever do, I'll Cc: you :-) Mar 08 09:47:15 lool, thanks Mar 08 09:47:35 * lool is just polluting the amitk/ericm discussion out of curiosity Mar 08 09:47:45 ericm_: amitk: so i take it that we can drop this? /me goes files a bug Mar 08 09:48:37 asac, thanks Mar 08 09:49:43 bug 534277 Mar 08 09:49:44 Launchpad bug 534277 in linux-mvl-dove (Ubuntu) "disable OABI_COMPAT (affects: 1)" [Medium,Triaged] https://launchpad.net/bugs/534277 Mar 08 09:51:20 cooloney: is that on for -fsl too? Mar 08 09:51:37 (see above) Mar 08 09:52:02 disabling oabi compat gives a tiny performance improvement on making syscalls Mar 08 09:52:37 good... we want performance ;) Mar 08 09:54:17 then you should start with disabling the PIE binary stuff which has major impact in performance Mar 08 09:55:16 the PIE/address randomizing stuff is snakeoil for security on 32bit archs anyway Mar 08 09:58:49 asac: i just checked that Mar 08 09:58:58 it is disabled in fsl-imx51 Mar 08 09:59:11 ericm_: cooloney: ^^^ what suihkulokki said about PIE is very pertinent. Mar 08 09:59:25 grep -r CONFIG_OABI_COMPAT ../Ubuntu/fsl-imx51-lucid/debian.fsl-imx51/config/ Mar 08 09:59:29 ../Ubuntu/fsl-imx51-lucid/debian.fsl-imx51/config/config.common.ubuntu:# CONFIG_OABI_COMPAT is not set Mar 08 09:59:32 roc@roc-macubuntu:~/Work/qemu-arm$ Mar 08 09:59:48 cooloney: I disabled it very early in Karmic I think Mar 08 09:59:56 amitk: yeah, thx, man, heh Mar 08 10:07:30 suihkulokki, what is PIE binary, sorry? Mar 08 10:09:55 http://en.wikipedia.org/wiki/Position-independent_code#Position-independent_executables Mar 08 10:13:25 so we need to disalbe that PIE stuff in kernel? Mar 08 10:13:59 will some apps fail to run due to that? Mar 08 10:14:31 we should try :) Mar 08 10:14:53 if the performance penalty is really that high it might be worth to look at Mar 08 10:16:34 Um, why? Mar 08 10:16:56 PIC sounds more familiar to me, but anyway - how's this related to oabi? Mar 08 10:17:00 PIE isn't that useful for security on 32-bit architectures, but PIC is critical for sane shared libraries. Mar 08 10:18:07 And we probably have to unwind some other things: kees implemented the ASLR stuff a while back. Mar 08 10:18:40 ericm_: its not related to OABI, it is related to performance Mar 08 10:18:54 persia, oh, i meant pie Mar 08 10:19:02 err Mar 08 10:19:02 pic Mar 08 10:19:20 ogra: no, you meant PIE ;) Mar 08 10:19:21 * ogra curses the similarity of all these abbrev.'s Mar 08 10:19:21 that's true, PIC hurts performance a bit Mar 08 10:19:35 ericm_: no, we are talking about PIE Mar 08 10:19:45 PIC hurts perf, but it necessary for .so Mar 08 10:20:04 why do we need PIE anyway? Mar 08 10:20:04 i have no idea about PIE stuff as well as ericm_ Mar 08 10:20:11 Right. We aren't giving up PIC. Once we have PIC, PIE doesn't generally matter that much, performance-wise. Mar 08 10:20:24 and what kind of app is using PIE binary Mar 08 10:20:59 persia: so PIE is an older trick than PIC? Mar 08 10:21:07 ericm_: for security, It randomizes the address space layout Mar 08 10:21:14 lool, apparently I missed the discussion of kexec vmlinux, it looks the arm kexec-tools doesn't support vmlinux/vmlinuz, but the one generated with objcopy can be used directly by kexec to avoid the zImage uncompressing code overwritting initramfs data issue Mar 08 10:21:31 cooloney: PIE just means the *entire executable* is PIC. Mar 08 10:21:48 and give a better performance since uncompressing can be skipped Mar 08 10:21:50 so there is no well-known location for the executable code Mar 08 10:22:16 but we'll need to talk to the security team about disabling it for ARM. They might have other views. Mar 08 10:29:47 lool: I assume you are using glibc for ubuntu-arm? Have you guys considered eglibc? The OE toolchain guru swears by it. Mar 08 10:30:48 Laibsch: Have you checked? I think we are using a variant of eglibc Mar 08 10:31:07 persia: no, I have not Mar 08 10:31:10 "assume" Mar 08 10:31:29 I thought it was quicker to just give that information and let lool decide what he wants to do with it Mar 08 10:31:39 I wouldn't even know where to check ;-) Mar 08 10:31:53 Laibsch: It's almost always more efficient to investigate a bit :) Mar 08 10:31:59 Or ask questions generally. Mar 08 10:32:03 we use eglibc by default Mar 08 10:32:10 on all arches iirc Mar 08 10:32:15 persia: I did ask, see above Mar 08 10:32:42 By "generally" I meant "without highlighting any individual" :) Mar 08 10:32:44 morning persia Mar 08 10:32:57 NCommander: So it is :) Mar 08 10:33:20 persia: I'm trying to help by pointing out possible lessons learned for ubuntu-arm from what I know about OE. If I need to finish an IT education first before being allowed to do that, I'll just simply stop. Becuase my time is limited. Mar 08 10:34:40 OE is nifty because they cross-compile everything, which makes it a lot easier to build than say Ubuntu which requires native building Mar 08 10:34:57 it's both a blessing and a curse, I guess Mar 08 10:35:12 Laibsch: indeed, some packages are mindbogglingly difficult to cross-build Mar 08 10:35:15 * NCommander glares at mySQL Mar 08 10:35:48 Laibsch: It's not about an education. It's just about trying things, and asking questions not of specific folk so that they aren't distracted if someone else has the answer. Mar 08 10:36:33 * NCommander sighs Mar 08 10:36:50 we've spent more time discussing this now than it will take an expert to decide what to do with the info Mar 08 10:36:56 I'm not an expert Mar 08 10:37:28 if you want me to become one before I can point out possible differences then I'm sorry, I can't do that Mar 08 10:37:41 Laibsch: You've taken that wrong. My apologies. Mar 08 10:38:07 I will try my best not to waste people's time Mar 08 10:38:17 But there's two sides to the equation Mar 08 10:38:43 Absolutely :) Mar 08 10:38:45 lool's time and mine. I'm looking at overall efficiency. I think that may be where our diffrences are Mar 08 10:39:06 It will cost me an immense amount of time to understand the toolchain issues Mar 08 10:39:30 it will be only seconds to either discard or decide to look further into it for an expert Mar 08 10:39:37 hence the decision I made Mar 08 10:39:47 btw, no offense taken, don't worry Mar 08 10:40:10 Cool! Mar 08 10:43:26 funnily i cant find the public discussion for it, but we switched to eglibc in karmic Mar 08 10:43:41 great Mar 08 10:43:54 * amitk remembers it being posted to ubuntu-devel Mar 08 10:44:04 I understand that ubuntu on arm still has some speed issue, though, correct? Mar 08 10:44:48 Sorry, I was interrupted by someone at my door Mar 08 10:45:36 lool: for the kexec on versatile Mar 08 10:45:45 hmm axis build failure looks odd https://edge.launchpad.net/~asac/+archive/armel1/+build/1543870 Mar 08 10:45:50 is java working at all on armel atm? Mar 08 10:45:53 lool: you mentioned kexec -l vmlinux works on your side Mar 08 10:46:04 lool: is on versatile hardware? Mar 08 10:46:16 cooloney, ericm_: http://people.canonical.com/~lool/vmlinuz-to-vmlinux Mar 08 10:46:17 lool: but failed on qemu, right? Mar 08 10:46:21 That converts a vmlinuz to vmlinux Mar 08 10:46:37 lool: got you, thanks, Mar 08 10:46:40 cooloney: It's in qemu Mar 08 10:47:30 cooloney: a) I can't qemu-boot the vmlinux kernel (unrelated to kexec), only the vmlinuz one b) I can't kexec the vmlinuz kernel (original bug); that seems to be a bug in the way kexec choses addresses (perhaps) Mar 08 10:47:54 cooloney: I don't have versatile hardware (probably nobody does around here); I just use qemu Mar 08 10:48:12 lool: understand. i cannot kexec vlinux, it does not work on my qemu Mar 08 10:48:31 lool: right, just was confused by your post in the bug Mar 08 10:48:32 heh Mar 08 10:48:47 'I can't boot the vmlinux in qemu though.' hehe Mar 08 10:49:07 cooloney: I need to update the bug again Mar 08 10:49:08 i played versatile hw before, so i assume you got it Mar 08 10:49:12 lool: ok Mar 08 10:49:16 That was after testing your kernel, but before testing vmlinux Mar 08 10:49:31 lool: let me try your vmlinuz-to-vmlinux Mar 08 10:49:34 cooloney: I don't have it; we just use versatile because it's well supported in qemu Mar 08 10:52:08 cooloney: you need to pipe the output Mar 08 10:52:24 cooloney: e.g. vmlinuz-to-vmlinux ~/yourvmlinuz > output-vmlinux Mar 08 10:53:39 lool: yeah, just got an vmlinux file with the pipe after the funny symbols popped up on my screen w/o pipe Mar 08 10:54:22 thumb2 rebuild ftbfs: http://paste.ubuntu.com/390975/ Mar 08 10:55:00 lool: OMG, the vmlinux generated by your script works with kexec Mar 08 10:55:08 lool: cool Mar 08 10:55:20 asac: Not bad at all! Mar 08 10:55:34 ~4% of the rebuilds Mar 08 10:55:41 Laibsch: So as pointed out above, we use eglibc by default everywhere, just like Debian Mar 08 10:55:50 great Mar 08 10:56:29 suihkulokki: Do you know of public benchmarks of PIE versus non-PIE on armel? Mar 08 10:56:32 anybody here using a native arm compile host coupled with a bunch of icecc clients? Mar 08 10:56:49 I can expect that basically any security feature has a cost, but I wish we had some data to quantify Mar 08 10:57:06 then we can comfirm what patches need to be applied into our master.versatile, fsl-imx51, mvl-dove Mar 08 10:57:43 Laibsch: To clarify, there is exactly one source packages pool which is the Ubuntu archive; the Ubuntu armel port uses the very same source as the Ubuntu Desktop Edition for instance Mar 08 10:58:10 cooloney: Let me test a pristine vmlinuz to see whether your patches are required Mar 08 10:58:14 yes, that is my understanding Mar 08 10:58:27 and that is the benefit of ubuntu-arm over OE imho Mar 08 10:58:39 it will likely scale better going into the future Mar 08 10:59:54 IMHO, s/likely// in the above sentence :) Mar 08 11:00:39 future is always uncertain ;-) Mar 08 11:02:30 its worked for Ubuntu for over 4 years now... Mar 08 11:03:00 and in the Linux kernel for much longer (embedded -> PC -> mainframe) Mar 08 11:03:12 lool: thanks please update the status of launchpad Mar 08 11:04:34 cooloney: done Mar 08 11:04:35 amitk: right now, I think OE-derived stuff is more usable. the debian-arm project apparently predates OE, yet I would venture to guess that Angstrom is more usable currently than debian-arm. Mar 08 11:05:37 Depends of the purpose Mar 08 11:05:56 OE doesn't provide an end-user installer, or security support Mar 08 11:06:11 or easy upgradeability Mar 08 11:06:13 People running Debian on ARM NAS devices care about these Mar 08 11:06:27 And it works great for that use case. Mar 08 11:06:38 I know a bunch of folks happy with Debian on handhelds as well. Mar 08 11:07:48 Laibsch: for a different definition of "usable" from our typical users. Mar 08 11:07:53 OE is not meant to provide that. That would be distro stuff Mar 08 11:08:37 ... developers as well, in fact Mar 08 11:08:40 an end-user installer in that sense may not be necessary Mar 08 11:08:51 devices have traditionally been flashed with a complete rootfs Mar 08 11:09:13 upgradeability is something that Angstrom does care very much about Mar 08 11:09:30 security is indeed a very weak point Mar 08 11:09:36 Laibsch: That only works for pre-sold stuff, and even pre-sold stuff may want a refresh for a variety of reasons (e.g. install Kubuntu Netbook on a Netwalker) Mar 08 11:09:38 but there's been some work there lately Mar 08 11:10:02 persia: what do you mean pre-sold stuff? Mar 08 11:10:11 I don't understand what you are trying to say Mar 08 11:10:12 err, stuff sold pre-installed. Mar 08 11:10:15 i think he means pre-installed Mar 08 11:10:22 no, that is not true Mar 08 11:10:30 * persia goes to find calories in hopes of thinking better Mar 08 11:11:13 I'm not aware of any device with angstrom installed as shipped (althought that may have changed lately) Mar 08 11:11:21 Laibsch, what we want is that your sister can buy that arm netbook ... and if she doesnt like the perinstalled OS is able to install ubuntu on it and use it like on x86 with no drawbacks Mar 08 11:11:36 sure Mar 08 11:11:44 (and without prior computer knowledge) Mar 08 11:11:47 that's how OE got staretd Mar 08 11:12:00 people replaced Sharp ROM with OZ ROM for example Mar 08 11:12:15 your sister would be able to replace os-blah on her arm netbook with OE ? Mar 08 11:12:18 so, I don't understand the point being made there Mar 08 11:12:42 would that even be possible without knowing how to use a serial console ? Mar 08 11:12:51 of course Mar 08 11:13:02 you guys seem to have some serious misconceptions Mar 08 11:13:27 no, i've just seen a lot of hard to work with arm hardware :) Mar 08 11:13:30 I think it's much easier to change the OS on a Z with OE-derived stuff than put Ubuntu on it Mar 08 11:13:33 Laibsch: are you surprised? this is an ubuntu chennel :) Mar 08 11:13:35 and i want to meet your sister ! Mar 08 11:13:45 *g* Mar 08 11:13:56 My sisters are older than me and married Mar 08 11:14:00 sorry ;-) Mar 08 11:14:01 heh Mar 08 11:14:11 Laibsch: it's a bit like talking about the benefits of perl on #python Mar 08 11:14:29 heh Mar 08 11:14:29 well, it's good to know what else is out there Mar 08 11:14:42 and I think there is a lot that can be learned from OE Mar 08 11:14:42 kblin, nah ... OE surely has its advantages Mar 08 11:14:50 so that the wheel doesn't need reinvention Mar 08 11:14:58 ogra: good point Mar 08 11:15:08 but there is a reason why endusers pick ubuntu over gentoo on theirt x86 machines :) Mar 08 11:15:31 kblin: Oh don't worry we often debate python versus shell here Mar 08 11:15:36 There was no alternative to OE at the time it was invented Mar 08 11:15:42 native compilation was not possible Mar 08 11:15:42 and i think the same reasons apply if you look at OE vs ubuntu-arm Mar 08 11:15:53 that's changing and that's why I'm considering to switch Mar 08 11:16:06 lool, well, if asac joins the discussion there will also be C involved :) Mar 08 11:16:09 You need to look back 5+ years when OE came to life Mar 08 11:16:20 sure Mar 08 11:16:27 there was no ubuntu-arm back then Mar 08 11:16:59 Laibsch: the reason why I run ubuntu on my ARM boxes is one of convenience rather than a technical one Mar 08 11:17:01 Laibsch: It is safe to say that most people here have played with Zaurii, OE, familiar, etc. in a previous life. Mar 08 11:17:26 then it's pretty amazing to read "OE is hard to install" Mar 08 11:17:30 for two reasons Mar 08 11:17:44 1) you never install OE on your device Mar 08 11:17:54 so? Mar 08 11:18:19 2) OE-derived distros do provide an easy to use installer mechnism (at least for the devices I'm familiar with) Mar 08 11:18:22 Folks, I'm not sure the Ubuntu versus OE discussion is leading anywhere Mar 08 11:18:39 yeah, lets turn it into a gnome vs kde one rather ! Mar 08 11:18:52 lool: I'm not sure anybody is trying to convince anybody else Mar 08 11:18:56 Different projects stand in different states and fit different people; I'm happy to discuss specific things we can rip from OE if there's something we can easily rip right now and it fits with the priorities of Ubuntu ARM Mar 08 11:19:05 for me it's an exchange of facts, more than anything else Mar 08 11:19:18 * amitk gets back to real work Mar 08 11:19:21 lool: armv5 support? ;) Mar 08 11:19:31 kblin: good idea! Mar 08 11:20:47 lool: cheap shot, I know :) Mar 08 11:21:23 Laibsch: not really important, ogra's sister won't buy a netbook with an armv5, so that's not a problem :) Mar 08 11:21:51 she only buys what i tell her is easiest to use for her :) Mar 08 11:22:12 cooloney: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/534324 Mar 08 11:22:15 Launchpad bug 534324 in qemu-kvm (Ubuntu) "Can't run uncompressed (vmlinux) kernels (affects: 1)" [Undecided,New] Mar 08 11:22:37 * kblin gets back to work Mar 08 11:22:39 cooloney: So a vmlinux from the archive vmlinuz just works Mar 08 11:22:57 oh my ... so klibc defines armv4 and tunes for strongarm upstream Mar 08 11:22:59 hrm Mar 08 11:23:01 cooloney: So your patches/build aren't needed to load vmlinux; perhaps these are needed for initramfs? Mar 08 11:23:13 kblin: Oh it's absolutely desirable Mar 08 11:23:15 * ogra was hoping that was a debian setting from rules Mar 08 11:23:38 kblin: I have some thoughts on that, but it wasn't really a high priority until now Mar 08 11:25:09 lool: like doing two builds? Mar 08 11:25:27 Wow, I end up with apex on my versatile install; I bet the kernel did it Mar 08 11:25:38 kblin: I don't think we would build this all the time Mar 08 11:26:06 kblin: What would be ok is taking Ubuntu's armel archive, using some clever machinery to rebuild everything a couple of times, and storing this new archive somewhere else Mar 08 11:26:43 Where that machinery could either be an expensive set of ARM hosts or qemu on a lot cheap x86 hosts (such as EC2) Mar 08 11:28:14 apw: I'm considering a d-i upload; do you plan uploading linux-fsl and linux-mvl this week? if you do, I'll hold it a bit Mar 08 11:28:37 lool, yes i think i have patches pending on both branches Mar 08 11:28:46 i'll have a look shortly and let you know ... Mar 08 11:29:24 Thanks Mar 08 11:30:14 lool, apex is in universe Mar 08 11:30:37 lool, but only moved out of the d-i deps recently Mar 08 11:30:50 so it depends when you installed Mar 08 11:32:04 I'm not sure why it got pulled really Mar 08 11:32:24 I created the chroot with debootstrap Mar 08 11:32:30 Hmm it might be the d-i build-deps Mar 08 11:32:50 Right Mar 08 11:32:59 seeing that CPU cycles on arm are still scarce, I'd like to reiterate my earlier question. Anybody here using a native arm compile host coupled with a bunch of icecc clients? Mar 08 11:33:01 So nm, just my setup Mar 08 11:34:07 Laibsch: Just use the emulation if you can't do native. It's not that slow. Mar 08 11:34:33 I'm really interested in that question, though. Mar 08 11:34:44 I don't think anybody here does that Mar 08 11:34:51 I see Mar 08 11:34:58 I think it's used in the OBS, in the Xandros ARM builds, and perhaps in the mojo tools Mar 08 11:35:04 Any technical reason to make that infeasible? Mar 08 11:35:09 OK Mar 08 11:35:23 Maybe I'll have a bit of fun with something like that, too Mar 08 11:35:24 We just use different solutions Mar 08 11:35:37 I've previously used OE and distributed that with icecc Mar 08 11:35:42 It worked pretty nicely Mar 08 12:21:22 JamieBennett: https://launchpad.net/ubuntu/+source/fio/1.33.1-1ubuntu1/+build/1550048/+files/buildlog_ubuntu-lucid-ia64.fio_1.33.1-1ubuntu1_FAILEDTOBUILD.txt.gz ;) Mar 08 12:21:44 * JamieBennett looks Mar 08 12:21:55 its ia64 Mar 08 12:21:58 /build/buildd/fio-1.33.1/verify.c:907: undefined reference to `write_barrier' Mar 08 12:22:07 guess we can ignore it ;) Mar 08 12:22:15 unless you see the problem right away Mar 08 12:22:30 Why is that code being included on IA64 ? Mar 08 12:22:39 not sure Mar 08 12:22:45 most likely the problem is that its not included :;) Mar 08 12:22:50 the symbol isnt defined Mar 08 12:22:58 e.g. it lacks a ia64 implementation Mar 08 12:23:04 Its ARM specific though (in arch/arch-arm.h) Mar 08 12:23:09 or the ia64 implementation currently in the code is not picked up Mar 08 12:23:15 JamieBennett: verify.c Mar 08 12:23:26 * JamieBennett didn't touch verify.c Mar 08 12:23:30 ./arch/arch-ia64.h Mar 08 12:23:53 JamieBennett: #define nop asm volatile ("hint @pause" ::: "memory"); Mar 08 12:23:56 #define read_barrier() asm volatile ("mf" ::: "memory") Mar 08 12:23:58 feels like its a missing _ Mar 08 12:24:00 #define writebarrier() asm volatile ("mf" ::: "memory") Mar 08 12:24:12 simple fix we could try in the next upload Mar 08 12:24:59 asac: still don't understand what the current fix could of done to effect that unless IA64 was broken before Mar 08 12:26:21 JamieBennett: its not a regression Mar 08 12:26:25 the problem existed before Mar 08 12:26:29 (i am quite sure) Mar 08 12:26:38 asac: so yes, missing '_' it seems Mar 08 12:26:49 sorry if i made you feel that way ;) Mar 08 12:26:58 JamieBennett: ok. have you updated the patch? i can just add the _ for next upload Mar 08 12:26:59 asac: np Mar 08 12:27:13 asac: I was looking for what I had 'broken' ;) Mar 08 12:27:20 heh :) Mar 08 12:27:24 this time it wasnt you Mar 08 12:27:28 :) Mar 08 12:27:48 I'll update the patch and attach it to the bug Mar 08 12:28:01 unless its easier for you to just do it ? Mar 08 12:30:07 i will wait for you Mar 08 13:16:10 asac, so you were complaining about http://people.canonical.com/~ogra/babbage2-lucid-20100211-3.png boottimes ... i did a test on a similar scaled x86 system with the same software ... http://people.canonical.com/~ogra/celeron-M-lucid-20100308-3.png Mar 08 13:16:38 i dont think we look so bad on babbage compared to that Mar 08 13:17:29 (note the celeron has even 10MB/s higher disk throughput) Mar 08 13:19:10 ogra: when is the UI up? Mar 08 13:19:20 e.g. what do i need to look for? Mar 08 13:19:34 netbook-launcher Mar 08 13:19:38 and then gnome-panel Mar 08 13:19:47 so its 50s v. 60s? Mar 08 13:20:20 or 35 vs 45 Mar 08 13:20:25 depends what you look at Mar 08 13:20:32 launcher is up very fast Mar 08 13:20:40 panel has 10-15s delay Mar 08 13:20:58 but its definately not arch specific if you compare two similar systems Mar 08 13:21:11 (similar slow) Mar 08 13:30:25 lool, bah, you broke rootstock packaging ... "qemu-kvm-extras-static | qemu-kvm-extras" .... qemu-system-arm is still needed for the image building and system setup, oem-config installation etc Mar 08 13:36:59 ogra: Back then, I think it used to use either system emulation or syscall emulation but not both, didn't it? Mar 08 13:37:19 nope Mar 08 13:37:53 it always did use qemu-system-arm for the system configuration, user steup and preparation for running on real HW Mar 08 13:38:02 mono was always my showstopper Mar 08 13:39:07 syscall emu is only used for the debootstrap part (which is the smallest bit of rootstock) Mar 08 16:24:48 lool, soo, our versatile kernel ... would you expect it to do thumb2 instructions properly ? i now ran a rootstock build of karmic ubuntu-desktop under lucid that seems to properly finish (not done yet but all the steps where lucid hangs are definately done) ... that somnewhat points to userspace imho Mar 08 16:25:38 i wonder if the versatile hack that enables a v7 cpu actually enables the needed bits and pieces to execute lucid binaries Mar 08 16:26:33 (though its still weird that it just silently hangs withouot errors, segfaults or anything) Mar 08 16:26:38 ogra: I don't understand what you're saying Mar 08 16:26:53 lool, well, you know about my hang of qemu Mar 08 16:26:56 ogra: I can run a lucid thumb2 userspace under qemu-system-arm with our versatile kernel Mar 08 16:27:13 but can you run it under heavy IO disk load ? Mar 08 16:27:28 I don't see how that relates to thumb2 Mar 08 16:27:30 * ogra refers to bug 532733 Mar 08 16:27:32 Launchpad bug 532733 in qemu-kvm (Ubuntu) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 1)" [Medium,Incomplete] https://launchpad.net/bugs/532733 Mar 08 16:28:05 well, i dont know why it hangs but installing karmic ubuntu-desktop doesnt expose the hang Mar 08 16:28:17 ogra: did you strace the processes as I suggested? Mar 08 16:28:28 while using a lucid userspace inside qemu does Mar 08 16:28:33 yes, nothing Mar 08 16:28:42 nothing? Mar 08 16:28:42 well, i straced apt ... Mar 08 16:28:57 It's certainly in one syscall, or its hung using all CPU; no? Mar 08 16:29:00 no, nothing, it just stops Mar 08 16:29:12 On which syscall? Mar 08 16:29:39 * ogra will need to re-run ... i threw away the image to make room Mar 08 16:30:15 these qemu-system-arm images start to eat my disk space :/ Mar 08 16:31:47 ogra: You mean the expensive megabytes of your SSD :) Mar 08 16:32:27 heh, yeah Mar 08 17:09:55 What's the state of Lucid regarding arm support ? Mar 08 17:10:22 dpkg goes segfault on my Touch Book.. Mar 08 17:10:36 lucid is v7 and thumb2 Mar 08 17:10:45 hmm Mar 08 17:10:49 does your CPU support both ? Mar 08 17:11:01 lemme see Mar 08 17:11:51 * ogra thinks touchbook was omap ... some cortex-a8 so it should actually work Mar 08 17:13:06 it's based on beagle board Mar 08 17:13:22 thumb is supported, i'm not sure about thumb2 :( Mar 08 17:13:22 right Mar 08 17:13:38 it should be supported ... Mar 08 17:14:14 how exactly does it fail ? Mar 08 17:15:22 for example: "apt-get install something" it starts downloading but very soon says http method died unexpectedly (Segmentation Fault)) Mar 08 17:15:47 thats not dpkg Mar 08 17:16:00 and if i repeat it enough it will eventually get it all downloaded, but then dpkg fails to unpack packages because of Segmentation Fault Mar 08 17:16:15 hmm, intresting Mar 08 17:16:19 Yes they both segfault Mar 08 17:16:47 we dont see that on imx51 or dove boards Mar 08 17:17:11 According to elinux.org lucid does run on BB as well.. Mar 08 17:17:35 where did you get the kernel ... and what kernel version are you running ? Mar 08 17:18:04 The kernel is a mess.. provided by Always Innovating (the company selling TB) Mar 08 17:18:13 what version Mar 08 17:18:18 lucid needs .32 Mar 08 17:18:18 2.6.29 Mar 08 17:18:22 alright Mar 08 17:18:25 that's it :) Mar 08 17:18:29 hmm, might be :) Mar 08 17:18:30 thanks for all the help Mar 08 17:18:37 welcome ... Mar 08 17:18:52 there is a beagle kernel for lucid on the beagle wiki though Mar 08 17:18:57 Meizirkki: this sounds like a hardware stability proble Mar 08 17:18:59 m Mar 08 17:19:02 not sure that has all the touchbook drivers though Mar 08 17:19:17 Meizirkki: Is the segfault happening always at the same place? Mar 08 17:19:25 lool, Mar 08 17:19:26 yes Mar 08 17:19:33 Meizirkki: Is it actually a "segfault", or is it e.g. a sigbus? Mar 08 17:19:41 segfault Mar 08 17:20:08 lool, knowing there are some hardware bugs.. it might be a hw stability problem as well Mar 08 17:20:41 Meizirkki: Unless your libc/dpkg are heavily modified causing the segv, it rather points at hardware stability issues to me Mar 08 17:21:06 Meizirkki: If random programs segfault, not just dpkg, then it's certainly the case Mar 08 17:21:14 Meizirkki: Out of curiosity, where did you get it? Mar 08 17:21:22 Touch Book ir Ubuntu ? Mar 08 17:21:23 o Mar 08 17:21:27 cant you buy it at AI ? Mar 08 17:21:36 Meizirkki: the TB Mar 08 17:21:43 I bought my Touch Book from AI Mar 08 17:21:54 It's from the second batch i guess.. Mar 08 17:22:08 Meizirkki: If you want to rule out userspace changes, you can debootstrap Ubuntu lucid into a local clean chroot, dpkg is stable for us Mar 08 17:22:44 AI kernel is a bit strange too, size 5MB and it doesn't have any omap3 powersave stuff or even IP multicasting.. but some android patches.. Mar 08 17:24:45 Meizirkki: So that it can run android! Mar 08 17:24:58 instead of lucid :P Mar 08 17:25:14 haha Mar 08 17:26:05 I'm looking forward seeing a recent omap-pm kernel running on it though, they will never get 10-15 hours of USE with this kernel Mar 08 17:26:16 (on one charge) Mar 08 17:27:09 sure ... with the extra car battery attached :) Mar 08 17:27:24 lol Mar 08 17:28:08 it does 16 hours without wlan which is nowhere near enough Mar 08 17:28:55 They'll send me a new keyboard-part for free => 12A extra battery :P Mar 08 17:34:56 * Meizirkki boots up lucid Mar 08 17:40:45 persia: poke Mar 08 17:40:52 if [ ! -f "/usr/bin/build-arm-chroot" ]; then Mar 08 17:40:52 sudo apt-get install qemu-kvm-extras-static Mar 08 17:40:53 fi Mar 08 17:40:53 DEBOOTSTRAP_COMMAND=qemu-debootstrap Mar 08 17:41:26 persia: Sounds like DEBOOTSTRAP_COMMAND=qemu-debootstrap should be first and you should test with if ! which $DEBOOTSTRAP_COMMAND >/dev/null 2>&1 ... Mar 08 17:57:07 Meizirkki: Cortex-A8 r1pX (typically r1p3) from OMAP34xx/OMAP35xx chips has quite a number of thumb/thumb2 hardware bugs Mar 08 17:57:31 if you really want to use thumb, you need to apply some workarounds Mar 08 17:59:25 Meizirkki: at the very least you need to have CONFIG_ARM_ERRATA_430973=y option in the kernel configuration Mar 08 17:59:42 okay, thanks Mar 08 17:59:43 and some of the fixes have to go to the bootloader Mar 08 18:03:08 so without this option enabled, you are going to have segfaults in thumb code for sure. If it does not help, then your bootloader did not set IBE bit in AUXCR and you will have to fix it there too Mar 08 18:05:03 Meizirkki: additionally your binutils package should be recent enough to have this workaround: http://sourceware.org/ml/binutils/2009-05/msg00297.html Mar 08 18:05:17 thanks Mar 08 18:06:25 good luck and if you get stuck, you can poke me regarding all this thumb stuff :-) Mar 08 18:07:25 I'm stuck already :P as I'm not that familiar with the hardware.. but i'll at least file bug to AI so they can fix their kernel and u-boot :) Mar 08 18:10:00 ok, that may be the best solution, don't forget to provide them with these errata numbers and links, if they have Cortex-A8 errata list pdf, they will be able to dig up all the necessary details from it Mar 08 23:27:44 lool: Indeed. That's a much better way to do it. **** ENDING LOGGING AT Tue Mar 09 02:59:58 2010