[02:25] <GrueMaster> Daviey: I'll start looking at them this week.  Just returning from holiday/vacation.  Need a vacation just to relax from the vacation.
[09:45] <Daviey> ogra_: Do you have a minute?
[09:45] <Daviey> ogra_: I was hoping you could help me with qemu-system-arm? :)
[11:42] <ogra_> Daviey, whats up ?
[11:45] <Daviey> ogra_: I'm really sucking in trying to get either the server cloudimg's or the core images running in qemu-system-arm
[11:45] <Daviey> They don't seem to output to tty.. and i couldn't get data over serial.
[11:45] <Daviey> So i'm not convinced i'm doing it right.
[11:46] <Daviey> I've been trying versatile(a|p)b
[11:46] <ogra_> on what host ?
[11:46] <Daviey> amd64
[11:46] <ogra_> versatile is rather dead
[11:46] <ogra_> no, which release i mean :)
[11:46] <ogra_> (on the host)
[11:46] <Daviey> Oh, oneiric
[11:46] <ogra_> ah, better use vexpress
[11:47] <Daviey> vexpress is the favoured machine?
[11:47] <ogra_> right, omap should also work i think
[11:48] <nicofs> I am having issues installing libscrollkeeper0 from karmic/lucid repos. all i get is 404... what can i do?
[11:48] <Daviey> ogra_: Could i ask you to try, http://cloud-images.ubuntu.com/oneiric/20110821-armel/oneiric-server-cloudimg-armel.tar.gz (tarball contains a disk img and kernel))
[11:49] <ogra_> phew, sure, let me install the qemu stuff, i havent used that since a year or so
[11:49] <ogra_> hmm, though i have no oneiric x86 machine
[11:50] <Daviey> ogra_: I can give you ssh access to a virtual machine if that helps?
[11:50] <Daviey> but no graphical interface if you want that
[11:50] <ogra_> nah, let me roll an oeniric chroot quickly
[11:50] <Daviey> ogra_: expect beer.
[12:01] <ogra_> Daviey, oh, btw, http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/20110822/ ac100 images ... (they dont work yet, but are close)
[12:01] <Daviey> ogra_: Oh awesome!
[12:02] <Daviey> ogra_: although, for bare metal arm - i care more about the images working through D-I. :/
[12:03] <ogra_> indeed
[12:03] <ogra_> we dont use them yet untl we have real arm server HW ...
[12:03] <Daviey> .. unless someone writes a pxe enabled dd script :)
[12:03] <ogra_> thats trivial
[12:32] <ogra_> Daviey, so how is your image expected to work ? for the beagle emulation you need a full disk image with boot partitions
[12:32] <ogra_> *partition
[12:33] <ogra_> (containing x-loader and u-boot etc)
[12:39] <Daviey> ogra_: We don't have much idea :)
[12:39] <ogra_> well, you should produce something similar to what we build on the imagebuilders
[12:39] <ogra_> a two partition image with the boot bits in the first (vfat) partition
[12:40] <ogra_> and then go from here https://wiki.linaro.org/Resources/HowTo/Qemu-beagleboard
[12:40] <Daviey> ogra_: I'm loathed to try and replicate what your team is doing.
[12:41] <ogra_> well, probably vexpress can boot more similar to what versatile was
[12:41] <ogra_> that would make it easier
[12:41] <Daviey> ogra_: Does it have isa-serial per chance? :)
[12:41] <ogra_> no idea
[12:41] <ogra_> i never used it :)
[12:42] <Daviey> yeah, libvirt seems to think everyone wants it :)
[12:42] <ogra_> https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress
[12:42] <ogra_> that looks more backwards compatible to versatile than qemu
[12:42] <ogra_> and it seems to be able to emulate 1G
[12:43] <ogra_> heh, ..."If you want you can add "-smp 4" to make it boot as a 4-core SMP model."
[12:44] <Daviey> heh
[12:44] <Daviey> ogra_: Who would be the best person for utlemming to work with to fix our build process?
[12:45] <Daviey> utlemming is our cloud image master. :)
[12:45] <ogra_> well, lets find a proper concept first :)
[12:46] <ogra_> hummmm....
[12:46] <Daviey> ogra_: Well use case is two fold:  1) Emulated ARM hardware using qemu-system-arm.. 2) Some manipulation to get it running on bare metal (probably pandaboard) via LXC.
[12:46] <ogra_> we dont seem to build vexpress netinst images anymore
[12:47] <ogra_> so there is no vmlinuz :(
[12:47] <Daviey> argh
[12:48] <ogra_> i wonder if linaro has something like that
[13:09] <ogra_> Daviey, so using vexpress it cant determine the filesystem of the img it seems
[13:09] <Daviey> argh
[13:10] <ogra_> what fs is it ?
[13:10] <Daviey> $ file oneiric-server-cloudimg-armel.img
[13:10] <Daviey> oneiric-server-cloudimg-armel.img: Linux rev 1.0 ext4 filesystem data, UUID=87915972-5866-47e0-af76-306c3a1143b4, volume name "cloudimg-rootfs" (extents) (large files) (huge files)
[13:10] <ogra_> oh
[13:10] <ogra_> it doesnt try ext4 at all
[13:11] <Daviey> ah, ok - what should it be?
[13:11] <ogra_> it checks ext2/3 above the mount error
[13:11] <ogra_> [    1.231251] No filesystem could mount root, tried:  ext3 ext2 cramfs vfat btrfs
[13:12] <Daviey> Odd that it supports btrfs but not ext4 :/
[13:12] <ogra_> Daviey, so here is what i did ...
[13:12] <ogra_> pulling the latest vexpress hwpack from http://snapshots.linaro.org/oneiric/vexpress-oneiric/20110822/0/images/hwpack/
[13:13] <ogra_> (there is sadly no "current" link and the hwpacks have version numbers in their filename)
[13:13] <ogra_> unpack it, dpkg -x pkgs/linux-image-3.0.0-1001-linaro-vexpress_3.0.0-1001.1~ppa~natty_armel.deb .
[13:14] <ogra_> qemu-system-arm -kernel boot/vmlinuz-3.0.0-1001-linaro-vexpress -M vexpress-a9 -cpu cortex-a9 -m 1024 -append 'root=/dev/mmcblk0 rw mem=1024M raid=noautodetect console=ttyAMA0,38400n8 rootwait vmalloc=256MB devtmpfs.mount=0' -sd oneiric-server-cloudimg-armel.img -nographic
[13:17] <ogra_> ...
[13:17] <ogra_> heh
[13:17] <ogra_> root@osiris:/root/tmp# grep EXT4 boot/config-3.0.0-1001-linaro-vexpress
[13:17] <ogra_> # CONFIG_EXT4_FS is not set
[13:17] <ogra_> intresting, not even a module
[13:18] <Daviey> ogra_: that is great!  What do we need to do, to get the hwpack into Oneiric?
[13:18] <ogra_> the vexpress package might be in the archive somewhere actually
[13:18] <Daviey> Ah ok, does vexpress max out at 512MB of RAM like versatile?
[13:19] <ogra_> there you go http://ports.ubuntu.com/pool/main/l/linux-linaro-vexpress/
[13:19] <ogra_> it should apparently support 1G
[13:20] <Daviey> groovy.
[13:22] <ogra_> Daviey, if you download the kernel-image udeb (you can also extract that with dpkg -x), that only contains vmlinuz and System.map
[13:23] <Daviey> ah, worth knowing
[13:24] <Daviey> ogra_: So, is there a reason it shouldn't support ext4?  Ie, should i raise a bug - or is there a logical reason?
[13:24] <ogra_> are your instrances supposed to survive reboots ? or is it some throw away thing ?
[13:25] <ogra_> i dotn see a reason to not support ext4
[13:25] <ogra_> if its throw-away i would actually go without journal, that speeds up I/O (and if you dont need reboot-recovery the journal is rather moot anyway)
[13:31] <Daviey> ogra_: should be persistent across reboots
[13:31] <ogra_> ah, k, then better keep a journal ;)
[13:32] <Daviey> although perf is probably more importiant than reliability at this stage IMO :)
[13:32] <ogra_> well, talk to linaor if you need config chaneges in the kernel
[13:32] <ogra_> *linaro
[13:33] <Daviey> linaro being on a different release cycle to us kind of concerns me to rely upon their kernel TBH.
[13:34] <ogra_> the packages in the ubuntu archive fall under the ubuntu release schedule
[13:34] <ogra_> (not more QA than other universe packages indeed)
[13:35] <ogra_> but indeed you can use omap instead, but with less ram and more complex image creation
[13:36] <ogra_> (since the vm behaves exactly like a beagle you also need a matching image)
[13:37] <Daviey> Yeah, i want to be able to allocate as much memory as possible.
[13:37] <Daviey> Ieally up to 16GB :)
[13:38] <ogra_> lol
[13:38] <Daviey> Ideally*
[13:38] <ogra_> so you should go into qemu hacking and invent a VM that can do that
[13:38] <ogra_> i think the vexpress is the biggest we have up to now
[13:39] <ogra_> also dont expect great performance of qemu in general
[14:40] <nicofs> I'm trying to do "sudo -s" in console, but all i get is "sudo: must be setuid root" - what can I do?
[14:41] <nicofs> The system I use (Ubuntu inside maemo on N900) arrived with that glitch. I did nothing to provoke that, I can't reinstall to fix it.
[14:52] <rajendra> help
[15:52] <Daviey> utlemming: Hello!
[15:52] <utlemming> howdy Daviey
[15:53] <Daviey> utlemming: meet ogra_ and NCommander.. they are your new best friends, which we will have to buy lots of beer for at UDS>
[15:53] <utlemming> hello ogra_ and NCommander
[15:55] <Daviey> utlemming: So ogra_ managed to get your images working by doing, http://pb.daviey.com/nINF/
[15:56] <Daviey> ext4 isn't supported by the kernel at this stage, which is why you've changed it to ext3.
[15:56] <utlemming> I just pulled ext4 out of the recipe
[15:56] <utlemming> and I was working on the in-image kernel
[15:57] <utlemming> looking at your pastebin, do we not have a working Ubuntu-provided kernel?
[15:57] <Daviey> You should be able to use, http://ports.ubuntu.com/pool/main/l/linux-linaro-vexpress/
[15:58] <Daviey> utlemming: I got a proof of concept with openstack starting the instance, but i lucked out with the options.. If you are able to ack that process works.. we should be able to land that soon.
[15:59] <utlemming> yeah, the change shouldn't be too difficult. I should have confirmation shortly.
[16:04] <utlemming> do we not have a 3.0.0.x kernel for arm images in the ports pool?
[16:06] <Daviey> utlemming: apparently, https://launchpad.net/ubuntu/+source/linux/3.0.0-9.12/+build/2733971
[16:07] <utlemming> ah...okay, so I was using the right kernel :)
[16:08] <Daviey> pass. someone from the arm team is best placed to answer that.
[16:09] <GrueMaster> utlemming: We do for omap/omap4, not sure why there isn't one for vexpress.
[16:10] <utlemming> I was building the cloud images with the omap kernel simply because it was the only one current for the 3.0.0.x kernel tree.
[16:11] <GrueMaster> Might be a question for ppisati.
[16:14] <utlemming> ppisati: can you chime in on the building of vexpress arm kernels?
[16:24] <NCommander> Daviey: why am I buying utlemming beer?
[16:27] <Daviey> NCommander: Awesome!  You can buy me one aswell.
[16:27] <Daviey> NCommander: I think you didn't parse it correctly, beer is being provided for you, not by you.
[16:27] <NCommander> Daviey: er,I just asked why you are buying me beer
[16:27] <NCommander> oh, awesome
[16:27] <NCommander> yay
[16:28]  * NCommander got wired crashed and might be semi-sleep deprieved
[16:28] <charlie-tca> Can I get one too?
[16:29] <Daviey> charlie-tca: no.
[16:29] <charlie-tca> oh, well. Worth asking, anyway :)
[16:30] <Daviey> charlie-tca: heh, sure you can - utlemming is buying.
[16:31]  * GrueMaster sighs.  Everyone always ignores the QA guy when beer is involved.
[16:33] <charlie-tca> +1 GrueMaster
[16:35] <rajendra> Hi, ogra_
[16:35] <rajendra> this is regarding USB OTG
[16:36] <rajendra> last tuesday u had mentioned that u will update the status on USB OTG
[17:30] <nicofs> How can I generate a new .Xauthority file?
[18:42] <utlemming> has anyone had success with the vexpress kernel and networking?
[18:42] <utlemming> I'm seeing "qemu: hardware error: lan9118: Unimplemented MAC register write: 9 = 0x8100"
[19:56] <Daviey> utlemming: lool experienced that a while ago
[19:56] <utlemming> Daviey: thanks
[19:57] <Daviey> utlemming: we need to cherry pick, http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg02900.html
[19:58] <Daviey> Or with a better comment, http://git.linaro.org/gitweb?p=qemu/qemu-linaro.git;a=commitdiff;h=a0313c00fc
[20:01]  * utlemming looks to test patch
[20:10] <Daviey> utlemming: If that resolves it, lets get a debdiff / branch together to upload.
[20:11] <utlemming> Daviey: sure thing
[20:22] <utlemming> Daviey: patch confirmed
[20:27] <Daviey> utlemming: rocking, show me the money^D debdiff
[20:33] <utlemming> Daviey: http://uec-images.ubuntu.com/oneiric/20110822-armel.2 (new images)
[20:33] <Daviey> utlemming: ROCKING.. can you throw me the qemu-system-arm command line you tested it with?
[20:37] <utlemming> Daviey: give me a minute...the image isn't pinging so I think my network setup needs some work
[20:38] <Daviey> bah, who needs network access.
[20:43] <lool> utlemming: vexpress networking only half works sadly; I get some packet drops when doing a netinst  :-/
[20:43] <lool> utlemming: but I didn't get your failure
[20:43] <lool> https://bugs.launchpad.net/qemu-linaro/+bug/799757
[20:43] <ubot2> Ubuntu bug 799757 in qemu-linaro "Network unstable with vexpress model" [Undecided,New]
[20:44] <utlemming> lool: well then, whats your qemu invocation?
[20:44] <utlemming> I'm using: qemu-system-arm -kernel boot/vmlinuz-3.0.0-1001-linaro-vexpress -M vexpress-a9 -cpu cortex-a9 -m 1024 -append 'root=/dev/mmcblk0 rw mem=1024M raid=noautodetect console=ttyAMA0 ip=10.1.6.2::10.1.6.1:255.255.255.0 rootwait vmalloc=256MB devtmpfs.mount=0' -sd oneiric-server-cloudimg-armel.img -net nic,vlan=0 -net tap,vlan=0 --nographic
[20:47] <lool> utlemming: I'm not passing any -net, not sure what raid=noautodetect does and the one thing which is bad here is your -sd which should be -drive file=sd.img,if=sd,cache=writeback
[20:47] <lool> you don't actually need -cpu
[20:48] <lool> I believe you want console=ttyAMA0,115200
[20:48] <lool> I don't know why you pass vmalloc=256MB devtmpfs.mount=0 either
[20:49] <utlemming> both those were feed to me by http://pb.daviey.com/nINF/
[20:50] <utlemming> lool: well, that worked better
[20:52] <utlemming> Daviey: use qemu-system-arm -kernel boot/vmlinuz-3.0.0-1001-linaro-vexpress -M vexpress-a9 -cpu cortex-a9 -m 1024 -append 'root=/dev/mmcblk0 rw mem=1024M console=ttyAMA0,115200 rootwait ' -drive file=oneiric-server-cloudimg-armel.img,if=sd,cache=writeback --nographic
[20:52] <Daviey> utlemming: is this on oneiric?
[20:52] <utlemming> I'm using natty. Firing up oneiric now
[20:53] <lool> utlemming: --nographic should be -nographic
[20:53] <utlemming> yup, it should. But qemu didn't spawn an SDL window
[20:55] <Daviey> utlemming: Argh!  That explains why it's not fixed for you :)
[20:55] <Daviey> .. and why i started ranting :(
[20:55] <utlemming> My pleasure to increase your stress level a bit
[20:59] <Daviey> utlemming: I live for stress, yeah baby!
[20:59] <utlemming> Asside from being _dog_ slow, I can confirm the image boots
[21:00] <lool> utlemming: drop -nographic if you want the SDL window
[21:00] <utlemming> lool: is SDL faster?
[21:00] <lool> no
[21:00] <lool> but it gives more features
[21:00] <lool> you can switch between qemu console, serial console and fb
[21:01] <lool> I usually disable graphics and use -serial stdio to get the output of ttyAMA0 on my terminal
[21:02] <utlemming> lool: do you have any suggestion for making it run any faster?
[21:03] <lool> utlemming: only use one CPU, not SMP (1 x cortex-a9 is fine); disable safe writes (-drive above); put the -sd in tmpfs; run on a fast intel box  :-)
[21:03] <lool> utlemming: it will be slow though
[21:04] <lool> utlemming: some useful things can be run under qemu-arm-static instead; you will be using your intel kernel and hosts' files
[21:04] <lool> depends what you're doing, and some things also fail utterly in that mode
[21:05] <utlemming> the images are being installed under qemu-system-arm -- it takes about an hour to generate the images, but works well for debootstrap
[23:20] <michaelh1> Anyone about?  I'm seeing a 20 % drop in performance after updating my PandaBoard kernel to 3.0.  Looking for some kernel hackers...
[23:21] <GrueMaster> michaelh1: Describe your test method.
[23:22] <michaelh1> GrueMaster: CoreMark, which is a CPU bound benchmark.  First noticed on my own NEON benchmark which shows the same results.
[23:23] <michaelh1> GrueMaster: NFS root.  Build CoreMark.  Boot into a random 2.6.35.  Run CoreMark.  Boot into linux-linaro 3.0.  Run same binary.  Compare.
[23:23] <michaelh1> GrueMaster: The bogomips in /proc/cpuinfo is also at ~80 %
[23:24] <michaelh1> LP: #831683
[23:24] <GrueMaster> michaelh1: I'd have to check, but I believe there was an issue with the cpu speed above 900mhz in the kernel (may have been beagleXM).
[23:24] <GrueMaster> lp 831683
[23:24] <ubot2> Launchpad bug 831683 in linux-linaro "Performance regression between 2.6.35 and 3.0" [Undecided,New] https://launchpad.net/bugs/831683
[23:25] <GrueMaster> thanks, ubot2.
[23:26] <michaelh1> Ah, that's the incantation!
[23:26] <michaelh1> GrueMaster: the board is stable with a .35 kernel (it's used in a build farm and works quite hard)
[23:28] <GrueMaster> It is highly possible that this may be related to bug 709245
[23:28] <ubot2> Launchpad bug 709245 in linux-ti-omap4 "ARM SMP scheduler performance bug" [High,Confirmed] https://launchpad.net/bugs/709245
[23:29] <GrueMaster> Try running with nosmp on the kernel cmdline and see if that helps performance.  Or, try ping -f to the machine while it is busy.
[23:32] <michaelh1> GrueMaster: will do
[23:33] <michaelh1> GrueMaster: note that the machine is idle and this is a single threaded benchmark
[23:34] <GrueMaster> Well, the benchmarks we ran earlier were mainly hdparm and discovered a 10x boost with nosmp.
[23:38] <michaelh1> GrueMaster: nope, nosmp has no effect.  Noted on the bug.
[23:39] <GrueMaster> Ok.  Worth a shot though.
[23:40] <michaelh1> GrueMaster: is there a debug flag I can set to show the clocks/frequencies that have been set?
[23:41] <GrueMaster> It should be in the dmesg output or /var/log/syslog.
[23:45] <michaelh1> GrueMaster: no, nothing.  We'll see what people think of the bug...