**** BEGIN LOGGING AT Wed Jun 30 02:59:57 2010 Jun 30 07:44:36 ogra, Amitk: ping Jun 30 07:44:45 lag: wassup? Jun 30 07:44:51 Hey amitk Jun 30 07:45:57 I'm chatting with someone on another channel Jun 30 07:46:06 He says "I am presenting about the BB at OSCON and want to get Ubuntu working to demo" Jun 30 07:46:19 Would like eye-candy Jun 30 07:46:29 Do we have eye candy for Beagle yet? Jun 30 07:49:10 lag: not really. They could showoff the normal desktop. But more eyecandy than that would mean integrated 3d graphics drivers which we don't do yet. Jun 30 07:49:49 morning Jun 30 07:49:51 Eye candy == Desktop (in my Luddite kernel speak) :)# Jun 30 07:50:07 Is Desktop running on Beagle? Jun 30 07:50:13 lag: it does Jun 30 07:50:21 Great Jun 30 07:50:26 Where do I (he) get it from? Jun 30 07:51:39 lag: download the images from http://cdimage.ubuntu.com/ports/releases/10.04/release/ Jun 30 07:51:48 the maverick images are a WIP Jun 30 08:20:57 ARGH Jun 30 08:21:06 Bug #579227 ¬_¬ Jun 30 08:21:08 Launchpad bug 579227 in qemu-kvm (Ubuntu) "[qemu-system-arm] hardware error: pl011_read: Bad offset 16000018 (affects: 4) (heat: 83)" [Low,Confirmed] https://launchpad.net/bugs/579227 Jun 30 08:38:15 directhex, why dont you use an ubuntu kernel and the recommended way to run the vm ? Jun 30 08:39:04 directhex: Looks like you're passing too much RAM Jun 30 08:39:10 directhex: How do you run QEMU? Jun 30 08:39:33 lool, as suggested on http://www.aurel32.net/info/debian_arm_qemu.php Jun 30 08:40:07 directhex, https://wiki.ubuntu.com/ARM/RootfsFromScratch Jun 30 08:40:19 directhex, look at "Using a qemu image with full emulation" Jun 30 08:40:24 directhex: With the images from there as well? Jun 30 08:41:28 ogra, didn't do anything useful either (gets stuck with a blinky cursor partway through booting). plus i need a debian environment, not just ubuntu Jun 30 08:41:33 * ogra thinks that aurel wikipage is several years old Jun 30 08:41:34 really what i need is both, of course Jun 30 08:41:50 directhex, then you need two kernels and two images Jun 30 08:42:01 ogra, right. Jun 30 08:42:41 directhex, well the above ubuntu instructions are used by many users Jun 30 08:42:57 if you follow the howto corretly it should just work Jun 30 08:43:02 *correctly Jun 30 08:43:41 directhex: So I downloaded the armel images from aurel32's site, and I could start and execute the initrd with: qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.26-1-versatile -initrd initrd.img-2.6.26-1-versatile -m 128 Jun 30 08:43:50 it did crash without -m 128 though Jun 30 08:43:58 looking at www.aurel32.net that page seems to be last edited in 2008, no idea how accurate that still is Jun 30 08:44:10 directhex: It looks like someone borke the default -m value Jun 30 08:44:17 directhex: Just pass -m 128 or -m 256 systematically Jun 30 08:44:26 lool, that seems to help Jun 30 08:44:31 directhex: if this is for package builds, you might be interested in qemubuilder Jun 30 08:44:46 lool, for mono chroots wont work Jun 30 08:44:49 lool, right now this is for debugging Jun 30 08:45:49 directhex: I started this page https://wiki.ubuntu.com/UbuntuDevelopment/Ports listing possible ways to develop for Ubuntu ports, it links back to RootfsFromScratch pages to create rootfses, but there are other ways Jun 30 08:46:26 ogra: qemubuilder uses a real vm AFAIK Jun 30 08:46:37 ah, i thought it was like pbuilder Jun 30 08:46:44 it is like pbuilder Jun 30 08:46:49 lool, oh, some of that looks useful Jun 30 08:47:02 lool, hmm, doesnt our pbuilder use chroots ? Jun 30 08:47:10 lool, which -cpu value is closest to the debian baseline? Jun 30 08:47:16 directhex: It's not very well advertized (ie not at all), I was suggested to mature it a bit before it's linked more proeminently Jun 30 08:47:18 at least the implementationm emmet worked on Jun 30 08:47:34 directhex: You dont need to worry about the CPU value of your emulated machine Jun 30 08:48:03 directhex: Unless you're trying to debug something where you're generating code that requires a too recent CPU Jun 30 08:48:13 e.g. you're generating v7 code for Debian binaries Jun 30 08:48:24 lool, i'm trying to debug something where i'm generating code that requires a too recent CPU Jun 30 08:48:30 assuming that's causing the SIGILL anyway Jun 30 08:48:54 Ok Jun 30 08:48:56 let me look Jun 30 08:49:13 directhex: I'm grabbing gcc-4.4 sources to see how it's configured Jun 30 08:52:17 WOHOOOO !!!!! \o/ Jun 30 08:52:23 http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/ Jun 30 08:52:33 not sure how well it works though Jun 30 08:53:00 I'm stupid, I should just look at the build log Jun 30 08:53:43 "--with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16" is used for Ubuntu Jun 30 08:53:53 --target=arm-linux-gnueabi Jun 30 08:53:57 hrw: Debian one Jun 30 08:54:17 Debian do not force any tune flags Jun 30 08:54:27 yup, exactly Jun 30 08:54:30 so gcc defaults are used Jun 30 08:54:49 armv4t probably but maybe even armv4 Jun 30 08:55:04 because gcc 4.4.x is able to do EABI for armv4 (strongarm etc) Jun 30 08:56:30 directhex: Oldest I can find is arm946, which is already armv5t Jun 30 08:56:51 directhex: It might not work with your versatile kernel though Jun 30 08:57:04 arm946? rather arm926 Jun 30 08:57:29 lool, so i can't emulate armv4t? and even armv5t is troublesome? man, ARM is messy :/ Jun 30 08:58:25 directhex, qemu is Jun 30 08:58:32 directhex: qemu-arm is able to do arm926 and higher Jun 30 08:58:57 hmm.. omap310 may be arm920 but I am not sure Jun 30 08:59:11 dont blame arm for drawbacks of an emulator, thats like saying intel is crap because vmware is buggy :) Jun 30 09:00:04 nope. omap310 is arm925 which is armv4t Jun 30 09:00:30 ogra, in the absence of an ubuntu arm porterbox for mere mortals, i need to make do Jun 30 09:00:55 there are porterboxes, they are just not accessible for everyone Jun 30 09:01:11 directhex: not being able to emulate armv4t is a qemu limitation, but I dont consider that a big deal given the age of it... you might be able to use qemu's versatile emulation with a special kernel built for versatile and for v5t, but by default it my expect more than that Jun 30 09:01:49 ogra, hence "for mere mortals" Jun 30 09:02:02 directhex, we'll get there Jun 30 09:02:09 likely this year Jun 30 09:03:00 ogra: Hmm really? Jun 30 09:03:27 lool, matter of affordable powerful HW Jun 30 09:03:58 pandas for everyone! Jun 30 09:04:01 lool, the panda should be available by end of the year for a reasonable price Jun 30 09:04:04 ogra: i dont think that's the issue, we have a porter box already Jun 30 09:04:40 ogra: Oh you dont mean that porter boxes will be available to more people by the end of the year, you mean people will be able to get fast hardware? Jun 30 09:04:48 lool, if we can have PPAs because its cheap to put up a bunch of pandas thats nearly as good as a porter box imho Jun 30 09:05:15 ogra: having cheap powerful hardware doesn't give us PPAs though Jun 30 09:05:16 but indeed i also mean you can just buy one for under $150 Jun 30 09:05:43 lool: but if we get 10 pandas for LP/PPA? Jun 30 09:05:56 or 50 Jun 30 09:06:08 (which is more what i'm after :P) Jun 30 09:06:21 this will make big build farm Jun 30 09:06:37 right, thats what i would like to have Jun 30 09:06:50 you can stack pandas, give each SD card for rootfs + nfs storage for builds and it will fly Jun 30 09:06:50 it's not a problem of buildd power I'm afraid Jun 30 09:06:55 That's certainly one of the issues Jun 30 09:06:58 indeed a PPA doesnt give you shell access but it will improve the situation a lot Jun 30 09:07:02 but another one is security Jun 30 09:07:20 yes, thats something we need to sort Jun 30 09:07:43 and i'm positive we can do that with joined effort of ubuntu-arm and linaro Jun 30 09:07:46 hrw: nfs for builds is a terrible idea, it breaks plenty due to timestamp skews and other issues, but it's possible to use networked storage -- or simply USB Jun 30 09:08:02 ogra: What's your security story then? Jun 30 09:08:34 lool, dedicated pandas with the same setup the other PPAs use but with real HW instead of kvm ? Jun 30 09:08:34 lool: having 4U 20TB storage is easier to maintain then 50 USD harddrives Jun 30 09:10:13 rather than nfs use iscsi or ata-over-ethernet Jun 30 09:10:45 suihkulokki: Yes, exactly, or even nbd Jun 30 09:11:02 <3 nbd Jun 30 09:11:30 ogra: So real hardware in the DC is not going to fly I'm afraid Jun 30 09:11:51 lool, why not ? Jun 30 09:12:02 ogra: We would have to ensure a way to really wipe anything from the board, such as changes to the u-boot config or things like that Jun 30 09:12:22 otherwise, it might be possible to do nasty things in one PPA build, which would affect the next one Jun 30 09:12:31 lool, aufs ftw ;) Jun 30 09:12:59 ogra: IS has the details, but essentially we cant allow direct hardware access, especially on ARM where it might mean changing the bootloader and such Jun 30 09:13:10 which is why we use xen / kvm on x86 Jun 30 09:13:18 anyway - nfs was just a nane Jun 30 09:13:21 name Jun 30 09:13:39 lool, i'll write a spec for m+1, lets see what IS says about the ideas i have Jun 30 09:13:42 apt-cacher-ng ftw Jun 30 09:14:20 ogra: I'm not sure it's a specable thing, but having a wiki page explaining the proposed plan and running it through IS is a good idea Jun 30 09:14:22 lool, essentially my plan would be to run the boards like ltsp clients (nbd squashfs image remotely merged with a tmpfs in ram) Jun 30 09:15:12 ogra: Now I'm a bad PPA builds, I flash a new kernel which will insert a rootkit into any gcc builds, but otherwise chainloads the normal setup, how do you avoid that? Jun 30 09:15:21 lool, everything works out of the initramfs, no need to touch the bootloader in that setup and you can maintain everything on an x86 machine ... after a build the panda gets rebooted and becomes virgin again Jun 30 09:15:35 ogra: Problem is that you cant prevent the build from touching it Jun 30 09:15:47 sure you can, especially on a panda Jun 30 09:15:47 since it has root permissions in the form of installing any other PPA package Jun 30 09:16:12 you make the vfat inaccessible so nobody can fiddle with kernels and the like Jun 30 09:16:13 ogra: Ok; I might like background on this hardware then Jun 30 09:16:21 ogra: How do you make it inaccessible? Jun 30 09:17:04 on a partition level, setting a type the kernel wont touch for example, i guess there are other ways Jun 30 09:17:16 "wont touch" Jun 30 09:17:35 what if I build a kernel module which allows me to overcome that, and then modprobe it Jun 30 09:17:37 or wait, you remote boot anyway Jun 30 09:17:46 there doesnt need to be a vfat Jun 30 09:17:53 yes, but that doesn't prevent me from changing the config that says to remoteboot Jun 30 09:18:15 e.g. fconfig or uboot-env-tool to update the bootcmd Jun 30 09:18:38 how would you do that if everything lives on a remote boot server ? Jun 30 09:18:56 ogra: I'm sure there are ways to protect from that, such as signatures or some form of container for ARM (e.g. lxc, even if not very secure, would allow hiding a bunch of devices) Jun 30 09:19:37 ogra: Certainly the boards have their boot setup stored in flash somewhere? Jun 30 09:19:44 no flash on panda Jun 30 09:19:52 how do you tell it to network boot? Jun 30 09:20:02 there are only two ways you can boot a panda, serial or SD Jun 30 09:20:31 you pull the bootloader via serial, then let it tftpboot Jun 30 09:20:43 ogra: ok, that might a good way then, always providing the boot bits on SD and rebooting after each build; it needs some kind of hardware remote reboot though Jun 30 09:21:00 so everything lives on a remote x86 machine the user doesnt have access to Jun 30 09:21:33 I feel you get a better sense of the issues at hand now, and with you knowledge of the hardware you should be in a position to write something up :-) Jun 30 09:21:44 right, thats my plan Jun 30 09:21:53 and then get elmo drunk and sign it off ;) Jun 30 09:25:56 is there an easy way to see which instruction caused a SIGILL? Jun 30 09:32:40 directhex: if you do that under gdb, you should get a backtrace and you can also disassemble at the point of the sigill Jun 30 09:33:42 alternatively, compiling your kernel with CONFIG_DEBUG_USER and booting with debug_user=1 should do the trick Jun 30 09:34:48 user_debug=, sorry. Jun 30 09:41:25 oh for the love of... qemu segfaulted whilst installing lucid Jun 30 10:01:44 amitk: Are you around? Jun 30 10:02:04 And ogra Jun 30 10:02:19 * ogra_cmpc is here with half an eye Jun 30 10:02:50 asac, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/ Jun 30 10:03:03 (no idea if it work though) Jun 30 10:03:10 *works Jun 30 10:03:35 ogra_cmpc: I am having troubles with my Beagle XM and Lucid Jun 30 10:03:46 lucid ? Jun 30 10:03:48 Can you get a console? Jun 30 10:03:54 that wont work Jun 30 10:03:54 Yes, Lucid Jun 30 10:03:59 Doh! Jun 30 10:04:02 lag: yeah? Jun 30 10:04:08 kernel is missing bits Jun 30 10:04:20 amitk: I think my question has been answered Jun 30 10:04:28 Balls Jun 30 10:04:37 lag: you're expected to fix the missing bits in maverick :-p Jun 30 10:04:41 So I won't be able to bug-fix on Lucid OMAP3 Jun 30 10:04:44 you also need the maverick x-loader/u-boot Jun 30 10:04:56 I have it working for Maverick Jun 30 10:05:07 you do ?!? Jun 30 10:05:20 with the default bits? Jun 30 10:05:20 amitk: No one specified that Jun 30 10:05:37 lucid is beagle C4 only Jun 30 10:05:44 lag: that is why you got the board. Implied specification? ;) Jun 30 10:05:55 * lag thinks people need to tell me these things Jun 30 10:06:27 I thought I received it so I could fix bugs on OMAP3 and the Panda to fix bugs on OMAP4? Jun 30 10:06:31 woo Jun 30 10:06:34 * amitk agrees and beats himself up Jun 30 10:06:34 That to me was implied Jun 30 10:06:43 maverick is supposed to work on as many omap3 platforms as we can make possibkle plus panda and blaze Jun 30 10:06:56 Okay Jun 30 10:07:04 So I am a Maverick guy? Jun 30 10:07:06 lag: the XM appeared towards the end of the lucid cycle, so there wasn't enough time to enable it in Lucid Jun 30 10:07:35 lag, well, dont you have a C4 too ? Jun 30 10:07:35 I only learned that it was a new board a little while ago Jun 30 10:07:37 lag: but if a few patches make it work in lucid, then I guess an SRU is possible Jun 30 10:07:42 I thought Beagle was Beagle Jun 30 10:07:55 http://paste.ubuntu.com/456338/ Jun 30 10:08:01 That is my Lucid run Jun 30 10:08:13 amitk, it needs a new bootloader, i doubt we can SRU that Jun 30 10:08:58 ogra_cmpc: What's the difference in bootloaders? More sysIDs? Jun 30 10:09:07 ogra_cmpc: I'm not sure if lag flashed a non-Lucid bootloader onto the XM Jun 30 10:09:38 lag: is this console capture from a stock lucid image? Jun 30 10:09:57 amitk, it comes withou preinstalled bootloader afaik Jun 30 10:10:19 ogra_cmpc: Not true Jun 30 10:10:39 Well, not for me anyways Jun 30 10:10:42 mine did and i havent seen one that had anything in nand Jun 30 10:11:01 amitk: Yes, I built it from git Jun 30 10:11:09 though ours were early ones Jun 30 10:11:40 ogra_cmpc: It doesn't have NAND Jun 30 10:11:58 afaik the XM isnt shipped yet anyway, there are stll ram issues according to #beagle Jun 30 10:12:29 lag, q ah, right, that was the issue :) Jun 30 10:12:43 Yes, that would do it :) Jun 30 10:13:00 So amitk, I am to work on Maverick Jun 30 10:13:04 Check Jun 30 10:13:30 * ogra_cmpc has a hard time typing sitting in position that only allows i finger typing atm Jun 30 10:13:36 I'll stop assigning myself to Lucid bugs then :) Jun 30 10:13:45 s/i/1/ Jun 30 10:13:58 ogra_cmpc: Are you in jail? Jun 30 10:14:05 ;) Jun 30 10:14:24 kind of, i got a sick cat on my lap sitting in my living room Jun 30 10:14:38 Oh dear Jun 30 10:14:52 holding the cmpc with 1 hand above my haed trying to type Jun 30 10:14:52 Did NCommander manage to kill his cat in the end? Jun 30 10:15:00 What is cmpc? Jun 30 10:15:01 ask him :) Jun 30 10:15:09 classmate pc Jun 30 10:15:25 lag: you should confirm with your lead, but basically whoever has the HW should support it in whatever releases we want to support it in. This includes new features + bugs. Jun 30 10:15:29 lag: I managed to put Ubuntu on my Nexus One, then NFS mount my laptop's HDD Jun 30 10:15:36 Lol, looks like a toy Jun 30 10:15:37 conveniently small for use in the living room where i dont want other computetrs Jun 30 10:16:10 NCommander: Nicely done Jun 30 10:16:14 * ogra_cmpc is having a coffee break watching the presidential election in germany on TV Jun 30 10:16:16 amitk: Who's my lead? Jun 30 10:16:27 amitk: I think here lies the issue Jun 30 10:16:40 lag: rtg Jun 30 10:16:44 NCommander, how is your cat related to that ? Jun 30 10:16:44 amitk: I'm a floater Jun 30 10:16:59 amitk: He hasn't asked me to do anything - ever :S Jun 30 10:17:04 I'll speak with him today Jun 30 10:17:11 ogra_cmpc: well, I could put my phone in my cat, then connect it over wifi, and have Ubuntu running in my cat! Jun 30 10:17:21 lag: I'll sound him out for you ;) Jun 30 10:17:27 shudder Jun 30 10:17:47 amitk: It's okay. I can speak with him direct via other means Jun 30 10:17:55 lag: and if TZ is an issue, then perhaps apw Jun 30 10:17:58 He should be on soon Jun 30 10:18:09 It's not an issue Jun 30 10:19:35 amitk: Which OMAP3 board does mpoirier have? Jun 30 10:19:49 C4 afaik Jun 30 10:19:53 balls Jun 30 10:20:18 he might have an XM too, not sure Jun 30 10:20:18 We were working together yesterday to try and get my Beagle up and running Jun 30 10:20:26 I assumed he had an XM Jun 30 10:20:45 Okay Jun 30 10:20:52 I'll have to re-touch base with him today Jun 30 10:21:08 Thanks for clearing things up ogra & amitk Jun 30 10:21:25 in any case talk to the guys in #beagle too, about the issues why XM isnt shipped yet Jun 30 10:21:39 I've been talking to them this morning Jun 30 10:21:43 It's due in July Jun 30 10:21:49 perhaps your oopses are related Jun 30 10:21:53 As I say, I have a console running Jun 30 10:22:02 No, my oopses are Lucid only Jun 30 10:22:12 with the archive kernel and archive bootloaders ? Jun 30 10:22:16 Maverick works Jun 30 10:22:19 cool Jun 30 10:22:42 * lag uses the word 'works' loosely Jun 30 10:22:49 I have a running console Jun 30 10:23:14 well, as long as the default binaries we provide get you that, thats a good step already Jun 30 10:23:42 Kind of - there is one issue with SDHC cards Jun 30 10:23:59 You have to turn off preempt to get them to work Jun 30 10:24:31 i think we have that on the C4 too Jun 30 10:24:41 there is a bug mpoirier is working on Jun 30 10:24:52 Correct Jun 30 10:24:57 Same thing Jun 30 10:25:03 so not XM specific Jun 30 10:25:10 Nope Jun 30 11:10:17 lag: there's issues with memory on the xm, though Jun 30 11:11:00 kai: What issues are those? Jun 30 11:11:01 hm, I just realized that my work account isn't in #beagle, so I guess they already told you that Jun 30 11:11:06 kai, are you incognito today ? Jun 30 11:11:38 ogra: no, I'm kblin from my "home" box and kai at work Jun 30 11:11:44 ah Jun 30 11:11:46 I have a different channel selection Jun 30 11:11:50 i never saw you as kai :) Jun 30 11:12:13 yeah, #ubuntu-arm technically isn't related to work :) Jun 30 11:14:04 work is more related to high performace computing, not really a playground for ARMs Jun 30 11:14:39 kai: http://paste.ubuntu.com/457317 Jun 30 11:17:28 kai, pfft ... if you stick enough beagles together you can have a HPC cluster too Jun 30 11:26:41 ogra: right, and I get data off them with ultra-high-speed USB connections :) Jun 30 11:27:09 at least ... if not these super fast serial connections :) Jun 30 11:27:35 lag: not entirely convinced Jun 30 11:27:38 er Jun 30 11:27:47 ogra: ^^^ Jun 30 11:28:27 lag: if you're saying this only happens with specific kernels, that's probably not the memory issue Jun 30 11:28:37 but ask jkridner about the memory thing Jun 30 11:29:51 It's the first time I've seen it Jun 30 11:29:56 And I've only seen it once Jun 30 11:33:25 ok Jun 30 11:33:47 as I said, ask one of the TI folks about the memory issues with the xm Jun 30 13:15:53 ogra: ping Jun 30 13:16:51 ogra_cmpc: This perhaps? Jun 30 13:18:34 heh Jun 30 13:18:52 lag, whats up ? Jun 30 13:19:54 Have you been asked to have a think about syslink? Jun 30 13:20:16 we discussed it here yesterday, yes Jun 30 13:20:29 I've been asked to lend my services Jun 30 13:20:35 How may I assist you Jun 30 13:21:12 err, i didnt do anything with it, only gave a recommendation how to handle the loading of the module best with regard to our images Jun 30 13:22:09 since the kernel apparently cant do it alone Jun 30 13:22:55 fixing that part would help, beyond that, fixing the module itself is in sebjan's TODO i think Jun 30 13:23:49 lag, i also think there are some patches in sebjan's branch we dont have yet to fix the loop issues Jun 30 13:24:05 That's correct Jun 30 13:24:09 I'm keeping an eye on those Jun 30 13:24:20 I've also been asked to touch base with you Jun 30 13:24:41 Have we come a conclusion as to which method would be best? Jun 30 13:24:55 a way to probe the platform bus for devices to make the module autoload would be the best Jun 30 13:25:10 but i'm not sure about the technical possibilities here Jun 30 13:25:17 wrt kernel Jun 30 13:25:48 How about something in /etc/modules, or upstart? Jun 30 13:25:56 i know we had platform devices for NIC drivers before under imx51 and these were autoloaded without /etc/modules Jun 30 13:26:13 That's interesting Jun 30 13:26:15 well, both are workarounds Jun 30 13:26:25 Okay, but non-standard? Jun 30 13:26:29 if we could fix it in kernel that would be preferred Jun 30 13:26:51 well, it was the fec NIC driver on imx51, amitk made it autoload back then Jun 30 13:27:04 not sure how Jun 30 13:27:50 if we cant fix it in kernel i'll simply add a line to jasper_setup do the module gets added to /etc/modules, thats trivial Jun 30 13:28:20 i perfer to not use an upstart job, since that will require an extra package only to ship the job Jun 30 13:30:04 Auto loading within the kernel seems a little weird Jun 30 13:30:25 Usually, if you want it to auto-load you just build it in Jun 30 13:30:53 well, usually if there is a device on a bus (acpi or pci come to mind) the module is loaded automatically Jun 30 13:31:19 indeed these buses work differently and can be walked by a probing process Jun 30 13:31:40 Okay, so perhaps something similar might be in order Jun 30 13:31:57 the kernel is supposed to work on multiple SoCs, i'm not sure you will have the HW on all of them Jun 30 13:32:29 which is likely the basic reason that ndec decided to modularize it first place Jun 30 13:32:51 Makes sense Jun 30 13:33:07 I'll do a little more research Jun 30 13:33:26 So the final word from you is; you'd put it in userspace, but you'd prefer not to? Jun 30 13:33:33 yeah, probably amitk can give some info how/why the fec driver worked that way Jun 30 13:33:38 right Jun 30 13:34:00 userspace is trivial but if we could solve it in kernel that would absolutely rock Jun 30 13:35:25 Naturally - the kernel does rock! :) Jun 30 13:35:33 I'll get back to you Jun 30 13:35:39 if its not broken, yeah :) Jun 30 13:35:57 cooloney: I have pushed the updates in my for-ubuntu-2.6.34 branch Jun 30 13:36:31 cooloney: the changes are pointed to by tag: ti-ubuntu-2.6.34-901.2+ti+panda+release0 Jun 30 13:36:47 sebjan: thanks, man Jun 30 13:37:04 cooloney: as usual, you do not want to take the last commit which is just a changelog update for package version Jun 30 13:37:10 sebjan, cooloney: Let me know when you have that sorted and I'll be happy to test again Jun 30 13:48:24 ogra_cmpc: lag: jeremy kerr had a patch in jaunty and/or karmic to convert the fec driver to use platform_driver. If that hasn't made it to mainline yet, it should Jun 30 13:49:27 amitk, right, would just be intresting to see how the autoloading of the module was handled in that Jun 30 13:49:48 amitk: Sounds like a good start Jun 30 13:50:10 Would you mind reducing my search area a bit? Jun 30 13:50:49 i guess looking at fec.c in our imx51 tree might be a start Jun 30 13:52:19 * lag takes his sniffer-dog 'grep' from the kennel Jun 30 13:54:33 is "imx51" == "mx51 upstream maintainer tree" Jun 30 13:55:00 i would guess so Jun 30 13:55:09 but better ask a kernel person :) Jun 30 13:55:34 It's Amit's tree, so I guess I'm asking him Jun 30 13:55:38 amitk -^ Jun 30 13:57:22 lag: check the fsl-imx51 branch of the jaunty/karmic kernels Jun 30 13:58:08 it isn't really a imx51 problem since the part is used on other platforms. So the driver is maintained by someone else Jun 30 13:58:37 * lag wishes people would stop assuming he knows where stuff is and it a little more forthcoming with information Jun 30 13:58:40 =;-) Jun 30 13:58:57 is* Jun 30 14:00:23 it is called "institutional memory". :) All of it should be downloaded to wiki ideally, but not possible in practice. Jun 30 14:01:05 That would be a pointless exercise anyway, as the search doesn't work Jun 30 14:01:16 You'd have to know which page it's in and where do find that page Jun 30 17:25:41 sigh. add some debugging printf to mono, mono stops throwing sigill... Jun 30 17:27:32 sweet Jun 30 17:27:40 just keep the printf ;) Jun 30 17:29:23 just what every arm user needs - a list of detected arm abilities on every app execution Jun 30 22:38:27 GrueMaster, http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/20100630.6/ Jun 30 22:38:53 must have just shown up. Jun 30 22:39:01 Checked 10 minutes ago. Jun 30 22:41:06 I'll have it in ~20 minutes. Jun 30 22:41:18 I dont' see anything in that dir Jun 30 22:43:10 * ogra_cmpc rsyncs already Jun 30 22:43:33 rsync isnt much better with bz2 files though Jun 30 22:47:01 ogra_cmpc: where are the image build logs stored? Jun 30 22:48:25 http://people.canonical.com/~ubuntu-archive/ Jun 30 22:48:52 they are mirrored by a cronjob so you have to wait until they show up Jun 30 22:50:51 Too bad they can't be monitored in real time. Jun 30 22:51:00 Like the buildds. Jun 30 22:51:36 you can monitor the livefs build in real time from chinstrap Jun 30 22:57:13 aha! Jun 30 22:57:20 looks like it's not the thumb2 patch at all Jun 30 22:57:33 * ogra_cmpc said so yesterday already Jun 30 22:57:41 what is it then ? Jun 30 22:58:21 the cpuinfo parsing patch. written by... Jun 30 22:58:36 author Loïc Minier Jun 30 22:58:39 sorry lool Jun 30 22:58:41 heh Jun 30 22:58:57 well, he improved the situation a lot with it iirc Jun 30 22:59:09 knowing that it wasnt perfect yet Jun 30 22:59:31 * ogra_cmpc remembers a discussion about it Jun 30 23:01:43 the patch introduced a MAYBE definition, sets {v5,v7,thumb}_supported to MAYBE, then uses ifs to turn those true or false Jun 30 23:01:56 except it doesn't ever set v7_supported to false on non-v7 Jun 30 23:02:06 ah Jun 30 23:02:14 so it stays at MAYBE, and later in the code, if (v7_supported) { Jun 30 23:02:20 explode_horribly(); Jun 30 23:02:20 } Jun 30 23:03:33 14 hours of building to add one printf: totally paid off ^_^ Jun 30 23:03:55 MCS [basic] System.Xml.dll Jun 30 23:03:56 features: v5: 1, v7: 2, thumb: 1 Jun 30 23:03:56 Illegal instruction Jun 30 23:03:58 heh, ther wonderful world of arm :) Jun 30 23:04:24 -r Jun 30 23:04:26 this is why i wish i could make qemu work - i reckon my core i7 would be a pretty fast ARM Jun 30 23:04:33 nah Jun 30 23:04:40 qemu is always slow Jun 30 23:05:09 better invest $120 and buy a beagleboard Jun 30 23:05:44 or wait for the pandaboard Jun 30 23:05:46 i'm not investing my money in ARM - my concern is for debbuntu Jun 30 23:05:58 (dual core 1GHz, 512M similar price) Jun 30 23:07:52 ogra_cmpc, i'm trying to work out the most minimal way to fix this. can you sanity-check my idea? Jun 30 23:07:58 let me pull up a URL to the file in question Jun 30 23:09:02 http://git.debian.org/?p=pkg-mono/packages/mono.git;a=blob;f=mono/mini/mini-arm.c;h=84caef95c1af83bc70cebab8826485a67b89d963;hb=HEAD Jun 30 23:09:25 wait, no Jun 30 23:09:30 wrong branch Jun 30 23:10:17 http://git.debian.org/?p=pkg-mono/packages/mono.git;a=blob;f=mono/mini/mini-arm.c;h=9593f9951510d0dacfc8f5b3a65307476b01a197;hb=refs/heads/master-experimental Jun 30 23:10:47 okay, now around the line 545 mark, you see the iffing to assign values to {v5,v7,thumb}_supported Jun 30 23:11:11 the defaults here are MAYBE (i.e. all features assumed to be on) Jun 30 23:12:09 the assumption is to help qemu, i.e. "if you get no values, just roll with everything on, it'll probably be fine". which given our dicussion earlier, is probably the case Jun 30 23:13:22 so why not just insert "v7_supported = FALSE;" between lines 553 and 554? Jun 30 23:14:41 sounds ok to me Jun 30 23:14:56 test it :) Jun 30 23:15:09 yeah, just ran make. see you tomorrow! Jun 30 23:15:59 mpoirier: On bug 591941, if I remove the SD card, then reinsert it and restart ./init, it seems to work ok. Might want to explore that a little when you work on that bug. Jun 30 23:16:00 Launchpad bug 591941 in linux (Ubuntu Maverick) (and 1 other project) "SDHC card not recognized (affects: 2) (dups: 1) (heat: 171)" [High,In progress] https://launchpad.net/bugs/591941 Jun 30 23:16:18 my gut says "apologise to lool", let me check something in the git logs... Jun 30 23:17:45 yup, apologies to lool - seems it was meebey that broke it when porting lool's patch from mono 2.4 to mono 2.6. i shall go and poke him Jun 30 23:23:02 * mattman_ is away: Jun 30 23:28:03 so by the looks of it the resizing routine runs now Jun 30 23:30:21 MCS [basic] System.Xml.dll Jun 30 23:30:21 features: v5: 1, v7: 0, thumb: 1 Jun 30 23:30:21 System.Xml/XmlTextReader.cs(1811,40): warning CS0219: The variable `dummyValue' is assigned but its value is never used Jun 30 23:30:23 looks healthy! Jun 30 23:30:36 great Jun 30 23:30:52 i'll try to push a 2.6.3-3 to experimental tomorrow Jun 30 23:30:57 then merges can happen based on that Jun 30 23:31:13 sweet Jun 30 23:47:47 hang on, main's frozen... so no hurry! Jul 01 00:31:07 I'm eyeing that "port glxgears to ES" bit... wanna' try it on libgles1-mesa-drivers-kms (or whatever it is) on my netbook. **** ENDING LOGGING AT Thu Jul 01 02:59:57 2010