[00:00] <cwillu> rcn-ee, null pointer patch -> http://marc.info/?l=linux-netdev&m=127490516731906&w=2
[00:00] <cwillu> going to try to run with that, and check if the memory leak was fixed elsewhere in 2.6.35
[02:38] <cwillu> rcn-ee, okay, that patch fixes the null pointer at least, just got it booting
[02:39] <cwillu> currently 36 objects in slab size-2048
[02:39] <cwillu> ... and no increases yet
[02:39] <cwillu> I'll ping back in an hour
[02:41] <cwillu> rcn-ee, note that this is _with_ the micrel patches, plus an additional one which I'll email you
[02:42] <cwillu> (er, it's actually the one from the link, so I'll only email you if you want a known-to-be-working copy of it :p)
[02:57] <rcn-ee> cool cwillu, was playing with the patch.. http://marc.info/?l=linux-netdev&m=127490516731906&w=2 needed for 2.6.34 and 2.6.35 ? ;)
[02:58] <cwillu> rcn-ee, haven't tested it under 2.6.34
[02:59] <cwillu> rcn-ee, I'm suspicious that the null-pointer was a resulting from freeing the memory (i.e., what wasn't happening in .34 and earlier)
[02:59] <cwillu> you're referring to the 2 -> 4 line?
[02:59] <rcn-ee> okay, will queue up for 2.6.35 and get a build out, will test 2.6.34 tomorrow too just for kicks..
[02:59] <cwillu> k
[03:00] <cwillu> re, leak test, it's still holding at 36 objects
[03:00] <cwillu> I've seen it go up to 100 or so, but it came back down
[03:00] <cwillu> so, it seems to be working properly
[03:00] <rcn-ee> yeah, it's more stablized then the previous version which shot up too fast..
[03:04] <cwillu> going for a walk for an hour
[03:04] <cwillu> I might dance a little while I'm walking :p
[03:05] <cwillu> (road trip to replace / upgrade a bunch of hardware with bb + zippy's, and that wasn't going to work out to well if the max uptime of a zippy is a day :p)
[03:05] <rcn-ee> you should... too much stress from the ks8851 driver for you this weekend..
[03:05] <cwillu> now I can actually write features to pack in before I leave wednesday :) :D \o/
[03:05] <rcn-ee> yeah that would have sucked big time, nothing like hardware that refuses to stay up..
[03:07] <cwillu> yep
[03:07] <cwillu> I knew I had this problem, but I thought I remembered that 2.6.33 didn't have it
[03:07] <cwillu> as it turns out, I just never used the ethernet under 2.6.33 :)
[03:08] <cwillu> I mean, I had a couple crappy workarounds, but I didn't want to have to explain their need to my boss :p
[03:08] <cwillu> hardware that stays up is better
[03:09] <rcn-ee> yeap... :) (crap replaced device 1 with 2, migrate to 2, shutdown 1, device 1 no longer repsonding..)
[03:09] <rcn-ee> (device 2 no longer responding)
[03:09] <cwillu> we get enough lightning strikes that I already have enough issues :p
[03:10] <cwillu> had a customer call me up saying my system was rebooting every few seconds
[03:10] <cwillu> he didn't feel the need to mention that his desktop was also doing the same
[03:10] <rcn-ee> yeah, you need good ups in the summer.. (or two or three in line..)
[03:13] <cwillu> in this case, if the power is out, they're not doing anything anyway
[03:13] <cwillu> and I've gone through the sd testing routine and so forth
[03:13] <cwillu> I'm actually considering reimplementing reboot as "sync; dontechodangerous b > /proc/sys-rq-trigger"
[03:13] <cwillu> nice and quick :)
[10:07] <hrw> mornig
[10:36]  * cwillu_at_work dances with hrw 
[10:38] <hrw> que?
[10:38] <cwillu_at_work> my beagles are no longer leaking memory like little 2kb sieves
[13:26] <furibondox> hi to everybody...
[13:26] <furibondox> I've the same problem... segmentation fault on line 282 in rootstock
[13:27] <furibondox> now I'm using a physical ubuntu Lucid installation
[13:27] <furibondox> any idea?
[13:30] <furibondox> http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg2382346.html
[13:30] <rsalveti> furibondox: known issue
[13:31] <rsalveti> furibondox: what rootstock version are you using?
[13:31] <rsalveti> bug 604872
[13:31] <ubot2> Launchpad bug 604872 in qemu-kvm (Ubuntu) (and 1 other project) "qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm (affects: 1) (heat: 8)" [Medium,Triaged] https://launchpad.net/bugs/604872
[13:31] <rsalveti> depends on what you're installing
[13:31] <rsalveti> sometimes it just get stuck and sometimes you'll get the segfault
[13:31] <furibondox> rsalveti: the latest from ubuntu repository
[13:32] <rsalveti> furibondox: you can try upstream version, I'm still fixing other bugs before releasing a new version
[13:32] <furibondox> from svn?
[13:32] <rsalveti> but you're still going to have the seg fault, the only difference is that it's going to try qemu more than once
[13:32] <rsalveti> furibondox: bzr
[13:32] <furibondox> ok
[13:32] <furibondox> I will try
[13:33] <rsalveti> bzr branch lp:project-rootstock
[13:34] <furibondox> I'm installing bzr
[13:34] <cwillu_at_work> rootstock reworked to use a chroot works great :)
[13:35] <furibondox> cwillu_at_work: using chroot instead of qemu????
[13:35] <cwillu_at_work> furibondox, chroot with qemu-static
[13:35] <rsalveti> chroot with qemu
[13:35] <furibondox> ah ok
[13:35] <cwillu_at_work> it actually works spectacularly well :p
[13:36] <rsalveti> furibondox: the problem is that the additional packages are installed with apt-get
[13:36] <cwillu_at_work> as you can make use of as many cores as you have available, etc
[13:36] <rsalveti> with a full vm
[13:36] <cwillu_at_work> rsalveti, I reworked it to not use the vm at all beyond the chroot itself
[13:36] <rsalveti> so, if you're still getting lots of segfault, try installing ubuntu-minimal and then installs the rest at your board
[13:37] <rsalveti> cwillu: yeah, with root this is the best way
[13:37] <rsalveti> still need to take a better look at that
[13:37] <rsalveti> cwillu_at_work: gota a patch?
[13:37] <cwillu_at_work> not really;  I've really had my way with the script
[13:37] <cwillu_at_work> actually, I guess alot of it would be patchable
[13:37] <furibondox> rsalveti: if I try to install ubuntu-minimal and then I create a script to install all the other packages I need and I call it with --script it should work?
[13:38] <rsalveti> yeah, don't worry, will take a better look at it later
[13:38] <cwillu_at_work> it's pretty straightforward though
[13:38] <rsalveti> yep
[13:38] <rcn-ee> it'll need some tweaks after the rootless changes.. ;)
[13:38] <rsalveti> rcn-ee: yep, but still somehow an easy change
[13:39] <rsalveti> furibondox: nops, because the script runs inside the vm
[13:39] <rsalveti> what you can do is to mount the filesystem, copy qemu static on it and chroot
[13:39] <rsalveti> then you are free to work on whatever you want
[13:39] <furibondox> ok
[13:39] <rsalveti> https://wiki.ubuntu.com/ARM/RootfsFromScratch
[13:40] <rsalveti> furibondox: see sing qemu user mode emulation (with chroot)
[13:40] <rsalveti> *using
[13:41] <furibondox> OK, however now I try with the latest bzr release
[14:05] <lag_> ogra: Can you send me the line to make boot.scr please?
[14:05] <lag_> mkimage ***
[14:05] <ogra> mkimage -A arm -T script -C none -n "Ubuntu boot script" -d <source> <target>
[14:18] <hrw> ogra: how many bytes does mkimage adds to initrd?
[14:18] <ogra> hrw, i think 64 ... one sec
[14:19] <ogra> hrw, 72 :) https://wiki.ubuntu.com/ARM/BeagleEditBootscr
[14:19]  * ogra knew he wrote that up somewhere
[14:19] <hrw> thx
[14:21] <slangasek> ogra: ok, why does this not work?: dd if=/mnt/uInitrd skip=1 bs=72 | gunzip -c | cpio -t
[14:21] <lag_> ogra: Cheers
[14:23] <ukleinek> ogra: a vanilla mkimage only adds 64, no?
[14:26] <ogra> slangasek, probably because -T ramdisk adds different stuff
[14:26] <ogra> ukleinek, might be, i think it varies with the comment (-n option)
[14:27] <slangasek> ogra: well, so how do I unpack it? :)
[14:27] <ogra> so the 72 might only be true if the comment is "Ubuntu boot script"
[14:27] <ukleinek> ogra: IIRC, no
[14:27] <ogra> slangasek, i never unpacked a uInitrd
[14:28] <slangasek> the comment is "Ubuntu Initrd"
[14:28] <ogra> ukleinek, funny, then i wonder why 72 works
[14:28] <ogra> slangasek, you flipped bs and skip options ?
[14:29] <ukleinek> http://git.denx.de/?p=u-boot.git;a=blob;f=include/image.h;h=bcc08d1a73224bb715d15983adea4767ce0e85fc;hb=HEAD#l176, 7*4 + 4 + 32
[14:30] <slangasek> ogra: er, they're reversible
[14:30] <slangasek> except that the way I've done it gives better performance :)
[14:30] <slangasek> (and may spit a warning at the end due to a partial read)
[14:58] <lag_> ogra: And the uimage mkimage script? (my 'useful commands' file is at home)
[15:05] <cooloney> lag_: mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Ubuntu Kernel" -d zImage uImage
[15:05] <lag_> Thanks cooloney
[15:08] <rsalveti> cooloney: I'm looking at bug 566645, because I got the same thing here with latest lucid kernel
[15:08] <ubot2> Launchpad bug 566645 in linux-ti-omap (Ubuntu Maverick) (and 2 other projects) "OTG configuration is broken on omap kernel (affects: 3) (heat: 49)" [High,Confirmed] https://launchpad.net/bugs/566645
[15:09] <rsalveti> cooloney: if you want to test it here, or debug, I have the proper cable here
[15:15] <cooloney> rsalveti: thanks, actually, i don't have the HW for testing,
[15:16] <cooloney> rsalveti: can you test that lucid kernel? i did not prepare the maverick kernel
[15:16] <rsalveti> cooloney: I got it with lucid
[15:16] <rsalveti> didn't test maverick one yet
[15:16] <rsalveti> neither upstream
[15:17] <cooloney> rsalveti: cool, how's the result of lucid testing kernel?
[15:17] <rsalveti> cooloney: if you're at prague we cat probably give you one beagleboard so you can reproduce it
[15:18] <rsalveti> cooloney: same issue with latest lucid kernel, 2.6.33-502-omap
[15:18] <cooloney> rsalveti: awesome, i am in kernel room and love to test
[15:19] <ogra> robclark, https://code.edge.launchpad.net/~ogra/jasper-initramfs/trunk has the code in jasper_setup
[15:19]  * robclark looks
[15:20] <ogra> http://bazaar.launchpad.net/~ogra/jasper-initramfs/trunk/files rather
[15:21] <rsalveti> cooloney: can you get by the arm room later? just because there are lots of cables and devices to be moving around
[15:21] <ogra> GrueMaster, http://rcn-ee.net/deb/tools/UBOOT/u-boot-beagleboard-2010.03+r52+gitrca6e1c136ddb720c3bb2cc043b99f7f06bc46c55-r52.bin
[15:21] <cooloney> rsalveti: no problem. i'd love to
[15:21] <rsalveti> cooloney: don't need to hurry, will be here for the whole week :-)
[15:21] <ogra> .oO(why did i just read "i love you" above ... )
[16:18] <rsalveti> cooloney: now it doesn't work at all :D
[16:18] <rsalveti> was finally able to test it
[17:02] <Guest78932> cooloney: mkimage -A arm -T script -C none -n "Ubuntu boot script" -d <source> <target>
[17:04] <cooloney> Guest78932: sudo dd if=/media/4C43-C886/boot.scr of=boot.script skip=64 bs=1
[17:04] <cooloney> Guest78932: is this right? ^^
[17:05] <Guest78932> Yep
[17:12] <hrw> bye
[19:27] <godstar> Hello
[19:28] <godstar> I am looking to install Ubuntu on a Archos 5 IT, any pointers?
[20:09] <loluengo> hi folks!
[20:09] <loluengo> i have a little question
[20:10] <loluengo> i'mm looking for  a small system to begin with ubuntu/arm development
[20:10] <loluengo> i would like to have  some advice
[20:11] <loluengo> which one you think is most suitable to begin??
[20:12] <loluengo> beagleboard? or tincantools' hammer?
[20:12] <pcacjr> loluengo, beagleboard
[20:12] <loluengo> why?
[20:12] <loluengo> i mean... why pcacjr?
[20:13] <loluengo> any advantage?
[20:13] <pcacjr> hmm
[20:13] <pcacjr> it's simple to use
[20:13] <pcacjr> you could get the beagleboard C4
[20:13] <pcacjr> it's a good hw
[20:14] <loluengo> i think the tincantools' nail kit is also very easy
[20:14] <pcacjr> loluengo, well i've only been hacking on beagleboard lately
[20:15] <pcacjr> loluengo, http://beagleboard.org is a good start
[20:15] <loluengo> and flyswatter for jtag progamming?
[20:16] <pcacjr> maybe :-), depends on you mate
[20:16] <pcacjr> heh
[20:18] <loluengo> any other not-so-expensive jtag emulator recommendation?
[20:19] <godstar> What image do I use to install Ubuntu on an ARM device?
[20:21] <loluengo> i looked at ti.com page and all of the emulator the recommend are VERY expensive!
[20:23] <prpplague> loluengo: it all depends on what you want to do
[20:24] <prpplague> loluengo: for alot of the basic operations of OMAP3 you don't really need a jtag
[20:25] <loluengo> prpplague, what do you mean by basic operations?
[20:25] <prpplague> loluengo: the OMAP3 has internal rom code that supports booting from SD card, uart, USB and nand flash
[20:26] <prpplague> loluengo: so jtag isn't really needed for initial bootloader programming
[20:26] <loluengo> prpplague, programming? debugging? tracing?
[20:27] <prpplague> loluengo: basic programming debugging can be done via uart or other I/O, but if you really need jtag, you can use something like the flyswatter with openocd
[20:27] <loluengo> hmmm
[20:28] <loluengo> that sounds like a great PLUS for beagleboard
[20:28] <loluengo> (over tincantools' hammer)
[20:29] <prpplague> loluengo: beagle and hammer aren't exactly in the same ball park
[20:29] <prpplague> loluengo: they are for different purposes
[20:35] <loluengo> prpplague, why do you say that?
[20:35] <loluengo> i see them similar
[20:35] <loluengo> both are arm-based boards
[20:35] <loluengo> both run linux
[20:35] <prpplague> loluengo: the hammer was designed as a hardware developers platform with limited resources
[20:36] <prpplague> loluengo: the beagle was designed as a software development platform with very little hardware expansion
[20:36] <prpplague> loluengo: they are vastly different target audience
[20:36] <prpplague> s/are/have
[20:36] <loluengo> aaahhh ok
[20:37] <loluengo> if i understood hammer is like a processor module - no peripherals added
[20:38] <loluengo> and beagleboard has plenty of peripherals, intended to develop software
[20:40] <prpplague> exactly
[20:40] <prpplague> loluengo: the hammer is available with some peripherals, but those are mainly for testing and reference for the developer
[20:43] <loluengo> good advice prpplague
[20:43] <loluengo> i think hammer is for me...
[20:44] <loluengo> my work is more hardware oriented than software oriented
[20:49] <prpplague> loluengo: is there something specific you are planning to work on?
[20:51] <loluengo> prpplague, yes... some kind of data logging device
[20:51] <prpplague> loluengo: ahh
[20:52] <loluengo> prpplague, not so interesting, but veeery useful
[22:10] <james_> Hello
[22:10] <james_> I'm trying to port Ubuntu to an armv6 device, that uses fbdev and am writing an xorg.conf
[22:10] <james_> It uses a fbdev device
[22:11] <james_> But I'm getting (ee) fbioblank Invalid argument error
[22:11] <james_> Any ideas?
[22:12] <james_> ogra_cmpc: Did you write rootstock by the way?