[00:21] <sniperjo_> if i connected to my board with serial, it would say last login from …. would it sound weird to have ttyS2 instead of tty02 ?
[09:20] <ndec1> ogra_: infinity: you know that the alsa-lib updates from last night is wrong?
[09:20] <ndec1> grep SDP4430 /usr/share/alsa/ucm/Panda/*
[09:20] <ndec1> is wrong...
[09:20] <ogra_> aww, thats alsa-lib instead of alsa, right ?
[09:21] <ogra_> hmm, no
[09:21] <ogra_> whats wrong about it =
[09:21] <ogra_> ?
[09:22] <ndec1> no. the ucm files are in share/alsa/ucm
[09:22] <ndec1> do you have audio working?
[09:22] <ogra_> the .conf is in the subdir here
[09:22]  * ogra_ isnt near a panda and actually on his way out atm
[09:22] <ogra_> i'll test when i come back
[09:23] <ogra_> (some RL stuff)
[09:24] <ndec1> if you run alsaucm it use the UCM config to config the driver, and the config params are taken in the script. in the Panda scripts we have thinkgs like hw:SDP4430 which will fail on Panda...
[09:25] <ndec1> GrueMaster: ^^
[09:25] <ogra_> right
[09:25] <ogra_> so that might need a fix then
[09:26] <ogra_> infinity, ^^^
[09:27] <infinity> It was fixed.
[09:27]  * ogra_ -> really out now ... will be back for the call
[09:28] <ndec1> infinity: nope. you didn't change the params in the config file. you still have references to hw:SDP4430 *inside* the files.
[09:28] <ndec1> on my panda:
[09:28] <ndec1> alsaucm -c Panda set _verb HiFi
[09:28] <ndec1> Im setting defaults
[09:28] <ndec1> ALSA lib main.c:260:(execute_sequence) unable to open ctl device 'hw:SDP4430'
[09:28] <ndec1> ALSA lib main.c:1287:(set_verb_user) error: failed to initialize new use case: HiFi
[09:29] <infinity> Oh, feh.  I forgot the sed on the version I uploaded.
[09:29] <ndec1> after the upgrade
[09:29] <infinity> Balls.
[09:29] <infinity> It was right in the local test version. :/
[09:33] <infinity> ndec1: Fixed.
[09:33] <ndec1> great.
[09:33] <infinity> ndec1: Thanks for the catch.  Annoyance of testing on one machine and uploading on another. :/
[09:33] <ndec1> while(1) apt-get update && apt-get upgrade ;-)
[10:00] <janimo> infinity, are idle arm builders assigned build jobs randomly or is there a prioritization?
[10:05] <infinity> janimo: It's either alphabetical or based on a serial in the table (ie: it's just a table lookup), but you could talk to wgrant about seeing if they can be reordered. ;)
[10:05] <janimo> infinity, would make sense to reoder and put pandas first no?
[10:06] <infinity> janimo: I suppose, except that armel isn't keeping those anyway.
[10:06] <wgrant> It's pretty much random and difficult to change.
[10:06] <infinity> wgrant: Shouldn't be random, surely.  I'm sure it's deterministic.
[10:06] <janimo> wgrant, so not even alphabetical as infinity said?
[10:06] <wgrant> infinity: Deterministic, but not predictable.
[10:06] <infinity> wgrant: I'm assuming based on the order they get spit out of the table.
[10:06] <wgrant> infinity: Not any more.
[10:06] <infinity> Oh.
[10:07] <infinity> Because SQL is hard, and we had to do it even worse? :)
[10:07] <wgrant> Each builder has its own state machine in the Twisted daemon.
[10:07] <infinity> Oh, right.
[10:07] <wgrant> It's entirely asynchronous.
[10:07] <janimo> the name is fitting
[10:07] <infinity> I forgot about the parallel rewrit.
[10:07] <infinity> e
[10:07] <wgrant> Once a builder is done, we schedule the next scan for 15s from whenever it finished.
[10:07] <wgrant> And dispatching is done on a per-builder basis.
[10:08] <wgrant> So whenever a builder is not building anything, the next scan will query the DB to see if there are any jobs.
[10:08] <wgrant> We could possibly rework it to queue a bit differently, but at present no statement can be made about the ordering.
[10:08] <infinity> Yeah, like I said, I forgot entirely about that rewrite.
[10:08] <infinity> No point trying to weight them.
[10:09] <wgrant> Speaking of armhf... when's it going to happen?
[10:09] <infinity> wgrant: Well, we may have missed our cutoff for getting a gcc upload in. :/
[10:09] <infinity> wgrant: So, it might just have to open with P.
[10:10] <wgrant> Yeah.
[10:10] <infinity> Not happy about all the delays, but whatever.  Life goes on.
[10:10] <infinity> We'll just have to get an army of Pandas to make up for it.
[10:11] <janimo> or imx53s as they are easier to get
[10:12] <wgrant> Maybe we'll have A15s of some variety eventually...
[10:19] <janimo> infinity: bzr commit, git log -p|less. you are not alone
[11:51] <ogra_> janimo, the panda cluster took a year to happen from when i made the first proposal to today
[11:52] <ogra_> janimo, better bet for mx56 or so :)
[11:52] <ogra_> or mx58 or however freescale will call the overnext generation
[12:02] <janimo> ogra_, a difference is pandas were scarce, whereas imx53 seems to be in good supply
[12:03] <ogra_> janimo, still you need to desing the whole crap
[12:03] <janimo> and the needs more pressing now and also the communication better
[12:03] <janimo> davidm, said they'd fit in the same case he designed
[12:58] <brandini> imx53 eh?
[13:23] <Neko> ogra, i.MX615 probably is the next big chip
[13:25] <Neko> with a D or a Q at the end for how many cores it has
[14:10] <ppisati> actually if i disable SUSPEND*, panda doesn't hang anymore
[14:10] <ppisati> i really don't understand how they reproduced it without SUSPEND support
[14:10] <ppisati> doh
[14:10] <ogra_> yeah, me neither
[14:10] <ogra_> but they also use the pvr driver
[14:13] <ppisati> but that is still triggered only from suspend
[14:33] <sebjan> ppisati: you disabled SUSPEND support in the kernel, right?
[14:34] <ppisati> sebjan: as a test?
[14:34] <ppisati> sebjan: yes, and it doesn' hang anymore
[14:34] <sebjan> ok
[14:34] <ppisati> the kernel in the archive has
[14:34] <ppisati> (wait)
[14:35] <ppisati> http://paste.ubuntu.com/699814/
[14:35] <ppisati> this is what i reverted
[14:35] <ppisati> this way, no more hangs
[14:35] <ogra_> well, as i said in the call, its mostly a gnome-power-manager bug ....
[14:35] <ogra_> which is being worked on
[14:35] <ppisati> so, we keep it on?
[14:35] <ogra_> well, it doesnt work on the kernel side either ... we might want to switch it off :)
[14:36] <ppisati> asd :)
[14:36] <ogra_> that suspend doesnt work and that g-p-m triggers suspend are surely two separate bugs
[14:36] <ppisati> well, actually i think the only bug is kernel side
[14:36] <ppisati> g-p-m is a bit too aggressive IMO
[14:36] <ppisati> to suspend the thing after 30mins
[14:36] <ogra_> well, the system forcefully goes to suspend after 30min idle time
[14:37] <ppisati> yep
[14:37] <ogra_> thats the g-p-m bug
[14:37] <ppisati> yep
[14:37] <ppisati> anyway
[14:37] <ppisati> if we can't work it out, i switch it off
[14:37] <ppisati> ok?
[14:37] <ogra_> yep
[14:37] <ogra_> doesnt do any good to have it on :)
[14:37] <ogra_> if it just locks the system at least
[14:38] <ppisati> righty right my friend :)
[14:38] <sebjan> yes, it's safer/easier to deactivate it for now
[14:43] <ppisati> sebjan: does it happen with
[14:43] <ppisati> sebjan: git://git.linaro.org/ubuntu/linux-linaro-oneiric.git too?
[14:46] <sebjan> ppisati: I don't know. Not sure if this tree has the TI patches
[14:47] <sebjan> ppisati: I use the tilt-linux-linaro-3.0 branch from Andy's tree
[14:47] <ppisati> sebjan: ok, and it does exhibit the problem even with no SUSPEND, right?
[14:49] <sebjan> ppisati: well, we can see a similar problem with no suspend but are unsure of its origin. It could be related to the sgx driver activation. That will be interesting to test Ubuntu kernel + sgx
[14:49] <sebjan> (in this case we don't have any suspend traces in the console)
[14:50] <ppisati> sebjan: and how do you reproduce it?
[14:50] <ppisati> sebjan: just leave the board idle?
[14:50] <sebjan> ppisati: well, just wait some time :)
[14:50] <brandini> anyone build mongodb lately?
[14:50] <brandini> the 2.0 release builds
[14:55] <ppisati> sebjan: half an hour is enought?
[14:57] <sebjan> ppisati: not sure. I know it happens quickly sometimes
[15:01] <ndec1> ogra_: i remember there was an installer bug yesterday. what was this problem?
[15:08] <ogra_> bug 806751
[15:08] <prpplague> ndec1: you have a ti branch you are using to test 4460 support?
[15:08] <ubot2> Launchpad bug 806751 in debian-installer "Boot partition on SD is too small on omap/omap4" [Medium,New] https://launchpad.net/bugs/806751
[15:08] <ogra_> bug 820621
[15:08] <ubot2> Launchpad bug 820621 in flash-kernel "netinstall fails to make omap system bootable during install" [High,Fix released] https://launchpad.net/bugs/820621
[15:08] <ogra_> bug 709245
[15:08] <ubot2> Launchpad bug 709245 in linux-ti-omap4 "ARM SMP scheduler performance bug" [High,Fix committed] https://launchpad.net/bugs/709245
[15:08] <ogra_> bug 779410
[15:08] <ubot2> Launchpad bug 779410 in flash-kernel "package initramfs-tools 0.98.8ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Medium,Fix released] https://launchpad.net/bugs/779410
[15:09] <ndec1> all fix are in the archives?
[15:09] <ndec1> since when?
[15:11] <ogra_> ndec1, sorry, that wasnt for you, i'm preparing the release report for #ubuntu-meeting
[15:11] <ndec1> ah!
[15:13] <ndec1> ogra_: we are getting 'installer crashed' with one of our recent image. could we be missing a pkg?
[15:14] <ndec1> that you've fixed?
[15:16] <ogra_> hmm, we fixed plenty things
[15:19] <ndec1> ogra_: does the very latest image work fine ? e.g. for the installer?
[15:19] <ogra_> for me the last image worked, yeah
[15:19] <ogra_> i used it yesterday to hunt down the icon bug
[15:32] <GrueMaster> ndec1: There are still issues during oem-config that I see, but they are very timing specific.  I can reliably reproduce them here on some SD cards, but not others.
[15:32] <GrueMaster> This is the 20110928 image.
[15:46] <rsalveti> prpplague: there's one from the ti landing team
[15:46] <rsalveti> prpplague: http://git.linaro.org/gitweb?p=people/andygreen/kernel-tilt.git;a=shortlog;h=refs/heads/tilt-linux-linaro-3.0
[15:46] <rsalveti> I know this branch works fine at 4460
[15:47] <prpplague> rsalveti: yea ndec1 pointed me to that one
[15:47] <rsalveti> there's also the tracking branch, based on 3.1
[15:47] <rsalveti> but not working properly I believe
[15:47] <rsalveti> missing some hwmod changes
[15:47] <ndec1> correct
[15:47] <ndec1> prpplague: what was the question?
[15:49] <prpplague> ndec1: just need a build for some 4460 testing
[15:50] <ndec1> prpplague: funny you ask... because if I needed one i would generally ask you ;-)
[15:50] <prpplague> ndec1: hehe, well, i;'ve been testing the head of all the TI trees and everyone has something wrong with them
[15:51] <ndec1> prpplague: there isn't just 1 tree?
[15:51] <prpplague> ndec1: no
[15:52] <ndec1> ;-)
[15:56] <rsalveti> haha :-)
[16:09] <ppisati> sebjan: i left the board idle for a while but no hang
[16:09] <ppisati> sebjan: titl-linux-linaro + ubuntu userspace
[16:09] <ppisati> dist-upgrade an hour ago or so
[16:19] <ppisati> sebjan: ok, if i force the suspend it hangs
[16:19] <ppisati> as expected
[18:35] <prpplague> ndec1: core 4460 support so far looks good on that one you referenced
[19:14] <kyleN> I am going to try my cruzer key (not the kingston)
[22:26] <infinity> Hey look, the slideshow works.
[22:26] <infinity> That's much less ugly.
[23:06] <prpplague> GrueMaster / ogra_ any of you guys know if userspace spi dev is enabled in the panda supported kernels?
[23:07] <prpplague> (for ubuntu releases that is )