[04:07] <twb> lilstevie: do you know if TF has a "multi-channel sound card" ?
[04:08] <twb> I'm afraid the answer is no, which makes me sad
[04:09] <twb> I tried using two mpg123 processes at the same time, the second one gave up
[04:50] <infinity> twb: Try running mpg123 under padsp so it passes through a software mixer?
[04:55] <twb> infinity: pulseaudio?
[04:56] <twb> I don't allow pulse on my systems :P
[04:56] <twb> I was asking because I'm trying to get emacspeak up and running again
[05:00] <infinity> twb: Heh.
[05:05] <twb> I can't actually get emacspeak to work at all yet
[12:20] <jamespage> hello - anyone around who can help me with this armel/armhf build failure - bug 920871
[12:20] <ubot2`> Launchpad bug 920871 in zookeeper "zookeeper 3.3.4+dfsg1-2ubuntu2 FTBFS on armel and armhf" [High,Confirmed] https://launchpad.net/bugs/920871
[12:21] <jamespage> not quite sure where to start :-)
[12:21] <jamespage> (have reproduced locally)
[12:28] <ogra_> jamespage, does this help https://wiki.ubuntu.com/ARM/Thumb2 ?
[12:35] <jamespage> ogra_, yes thanks
[13:35] <rbasak> I'm having bus powered USB disk issues on the pandaboard. Should I just give up? Does this work for anyone else?
[13:36] <taruti> rbasak: I have an usb disk but it wants external power with the pand
[13:36] <taruti> *panda
[13:37] <rbasak> so doesn't work without?
[13:37] <rbasak> even though it in theory should?
[13:37] <taruti> not sure why, that is just my experience
[13:37] <rbasak> I'm giving the panda a beefy enough PSU I think. But perhaps a varying load is causing issues. I get combinations of kernel panics and disk spindowns
[13:39] <ogra_> rbasak, the PSU TI shipped with my first panda is 5V 4A, what do you use ? i wouldnt go below 3A for hub powered USb disks
[13:39] <rbasak> 5V 4A, and I also have been trying a 200W AT PSU
[13:40] <ogra_> well, that should work, whats the issue you see ?
[13:40] <rbasak> kernel panics
[13:40] <ogra_> actually USB related ones ?
[13:41] <rbasak> and sometimes the disk keeps spinning on and off in a fast (maybe 0.8s) cycle
[13:41] <rbasak> I don't think the panics are USB specific
[13:41] <ogra_> well why blame the disk then ? :)
[13:41] <rbasak> I suspect maybe the disk is causing the board voltage to drop, though I've metered it I won't be able to see short interval drops
[13:41] <rbasak> only this disk does it. my sata/usb docking station which is externally powered does not have the same issue
[13:42] <ogra_> hmm, well, might even be a driver issue
[13:42] <ogra_> i think there are plenty people running host powered usb disks on their pandas ... not that i have empirical data though
[13:43] <rbasak> OK I'm pretty sure it's a power issue. taruti gave me an idea - I connected the second bus power connector to a usb hub powered by my AT PSU instead of into the panda. And powered the panda from the power brick I have. Now it seems to be going OK
[13:44] <rbasak> Perhaps I need to make a "USB power boost" harness which supplies 5V to those secondary connectors outside the panda
[13:46] <rbasak> perhaps this particular drive model causes more noise on the usb power affecting the panda?
[13:46] <rbasak> I just bought the cheapest one
[13:46] <rbasak> it's an intenso 320GB
[15:48] <tedg> Hey folks.  I was curious if someone could build the HUD feature for ARM and check to see if it's responsive.
[15:49] <tedg> It's very much so on my computer, so I haven't spent much time optimizing, but I'd like to ensure that's across platforms.
[15:49] <tedg> I'm not super worried, but I want to make sure :-)
[15:49] <ogra_> if it is as responsive as the dash it will take 10-15sec to come up
[15:50] <tedg> ogra_, On Unity or UnityQt?
[15:54] <ogra_> can it run in unity-2d too ?
[15:54] <ogra_> (GLES support for 3D unity isnt merged yet, so we can only run under -2d)
[15:54] <ogra_> -2d == Qt
[15:54] <ogra_> :)
[15:55] <tedg> ogra_, 2d is Qt only until Qt5 is out, then they're all 3d :-)
[15:55] <ogra_> we only have the Qt version on arm atm until the GLES patches from linaro get merged into unity
[15:55] <tedg> ogra_, I thought Unity could run on the Pandaboards?  no?
[15:55] <tedg> ogra_, Is that with the ES patches?
[15:56] <ogra_> right, they are a) not merged (waiting since the dublin sprint) and b) still have a few bugs
[15:56] <ogra_> so all we can currently run proper is unity-2d (Qt)
[15:57] <GrueMaster> rbasak: Most USB powered drives require two USB connectors to get enough power, but unfortunately even then the panda doesn't deliver enough power from the usb ports.  All of my USB<>SATA drives have separate power source, which isn't easy to find on 2.5" enclosures.
[15:57] <tedg> ogra_, Hmm, okay.  Is that plan updated?  I thought there was a plan to merge those branches discussed in Budapest.  Have you talked to the Unity guys about that since then?
[15:57] <rbasak> GrueMaster: aha, that'll be my problem then. I've tried connecting the second connector to an external source but that only seem to work some of the time. Thanks!
[15:57] <ogra_> tedg, once a week, yep. its in the process and hopefully ready by feature freeze
[15:58] <tedg> ogra_, Cool, I'll leave you to it then!  :-)
[15:58] <ogra_> tedg, btw, the HUD is public stuff now ?
[15:58]  * rbasak wonders what to do with this drive that's going spare now
[15:58]  * ogra_ didnt see any blogpost yet 
[15:58] <tedg> ogra_, Yup: http://www.markshuttleworth.com/archives/939
[15:59] <ogra_> ah, k, had no time to follow planet since budapest
[15:59] <tedg> ogra_, But you're a voracious reader of OMG! Ubuntu!, right?  ;-)
[16:00] <ogra_> heh, rather planet than OMG :)
[16:15] <LetoThe2nd> k1l: didn't know you also hang out here ;)
[16:15] <k1l> ;)
[16:23] <GrueMaster> ppisati: Any chance of getting the omap4 kernel fixed or at least removed from the pool today?
[16:30] <rbasak> GrueMaster, AIUI ppisati sent a fix to the list today
[16:32] <ppisati> GrueMaster: yep, sent, waiting for the upload
[16:32] <GrueMaster> Ok.
[16:32] <ppisati> btw, do anyone know why the arguments for the kernel cmdline changed?
[16:33] <ppisati> dpkg -S /boot/boot.script says it doesn't belong to any package
[16:33] <ppisati> so it must some hand-crafted stuff coming from the installer
[16:33] <ppisati> *it must be
[16:33] <GrueMaster> The boot script is generated during install, not by any packages.  For preinstalled, it is created by jasper.
[16:34] <GrueMaster> For netinstall, it is generated by f-k-i (I think).
[16:42] <ppisati> ok
[16:42] <ppisati> and do we have a changelog of it? why an arg was added/deleted?
[16:43] <GrueMaster> What arg was added/deleted?
[16:44] <ppisati> GrueMaster: mem=456M@0x80000000 mem=512M@0xA0000000
[16:45] <ppisati> GrueMaster: these two are not of boot.script anymore and one of the feature of our kernel (CMA) craps out without it
[16:45] <ppisati> s/it/them/
[16:45] <GrueMaster> That arg is only necessary when using the closed source video decoder.  Shouldn't have any affect when running server/headless.
[16:45] <ppisati> it has with CMA
[16:46] <ppisati> without these args it doens't initialize the pool at boot, and when the usb ask for some DMA buffers, kaboom
[16:46] <ppisati> that's what you get yesterday
[16:46] <ppisati> i sent a revert of this CMA
[16:46] <ppisati> since it's not mandatory and it's not even in mainline
[16:46] <ppisati> but the camera driver needs it
[16:46] <ppisati> so
[16:46] <ppisati> we either drop the camera driver, or we revert these args
[16:47] <GrueMaster> Then that is a new change, as I have been running w/o those settings on all headless images since Maverick.
[16:47] <ppisati> yep
[16:47] <ppisati> it was bropught in with the last TI bits
[16:47] <ppisati> btw i had these args since i started working here
[16:47] <ppisati> that's why i didn't notice CMA panicng at boot
[16:48] <GrueMaster> As to the netinstall cmdline parameters, they were never added when netinstall was created.  I'd have to look, but I'm not sure they are even in the server preinstalled images.
[16:48] <ppisati> uhm ok
[16:48] <ppisati> anyway the revert is on its way
[16:48] <ppisati> so...
[16:49] <GrueMaster> Those parameters create a hw memory hole so that a specific hw device can use that address range.  Not sure why it can't be a bit more intelligent and request it on module load.
[16:50] <ppisati> perhaps because if you don't explicitely say so at boot time, the entire memory would be mapped (and couldn't be reclaimed later) i guess
[16:51] <GrueMaster> Ok, those parameters are on the server preinstalled (which makes sense as they are hardcoded in jasper).
[16:52] <GrueMaster> I'll bug NCommander to add them to the netinstaller when he comes online.
[16:52] <ppisati> no no
[16:52] <GrueMaster> But as I said, we were told they were only needed for the closed source decoder bits.
[16:52] <ppisati> i already asked for the revert
[16:52] <ppisati> these won't be necessary anymore after nex upload
[16:53] <GrueMaster> But is that what TI wants going forward?
[16:53] <ppisati> well, CMA is not even mainline
[16:53] <ppisati> so when it will hit mainline, we'll see
[16:53] <GrueMaster> If their patches are now enabling it, then we should make sure all images are consistent.
[16:54] <GrueMaster> (we should make sure netinstall is consistent anyways).
[16:54] <ppisati> i was wondering why linaro has no such problems
[16:56] <GrueMaster> They may have that parameter as default on their images.
[16:56] <ppisati> could be
[16:57] <ppisati> i tried to ask it to agreen
[16:57] <ppisati> but he didn't answer yet
[16:57] <GrueMaster> For now, if that is all that is required for netinstall to work, that is easy to fix (w/o reverting the patch).  Netinstall can be preseeded to include those parameters during install and the netinstall image can be fixed to have them on boot.
[16:57] <ppisati> yes, that would fix it
[16:58] <GrueMaster> My concern now is that by reverting it, are we causing issues to TI's development work down the road?
[16:58] <ppisati> revert the patches?
[16:58] <ppisati> this is just for 3.2
[16:59] <ppisati> and since TI won't support it/as, we stay as it is
[16:59] <ppisati> for 3.3 we will get it, and bunch of new drivers exploiting it (i guess)
[17:00] <GrueMaster> Then we are better off leaving the kernel as is and fixing netinstall.  Less pain in the long run.
[17:01] <ppisati> GrueMaster: when you say the binary driver, do you mean the pvr-omap4 dkms?
[17:02] <GrueMaster> Not sure if it is that one or the gstreamer code (think it was gstreamer though).
[17:02] <GrueMaster> ogra_ would know.
[17:02] <GrueMaster> Or ndec.
[17:03] <ppisati> k
[17:03]  * ogra_ looks up
[17:04] <ogra_> ah
[17:04]  * ndec too
[17:04] <ogra_> the cmdline is created at buildtime, only the root= parameter is added by jasper
[17:04] <ogra_> the memory hole is needed for ducati (the multimedia framework)
[17:05] <ndec> ppisati: GrueMaster: i saw the email on kernel list, i am not sure i understand what the proposed fix is
[17:05] <ppisati> ndec: the problem is in the new memocry allocator (CMA)
[17:06] <ndec> does it require the memory hole in bootargs?
[17:06] <ppisati> this CMA has never been in mailine, but we got it via tilt
[17:06] <ogra_> GrueMaster, the netinst images should have that cmdline params too, if not, NCommander should add them at build time
[17:06] <ppisati> because the camera driver needs it
[17:06] <ndec> yes, it's in tilt because we use it for v4l2 camera driver.
[17:06] <GrueMaster> ogra_: Ok.  I'll file a bug and assign to him.
[17:06] <ndec> and later for MM with syslink3.0
[17:06] <ppisati> since the usb crap was due to this memory allocator, i reverted it and now everything works
[17:07] <ogra_> GrueMaster, great, if he doesnt have the time, infinity or i can do it as well
[17:07] <ppisati> dunno why it doesn't init the pool at boot time if we don't pass the args stuff
[17:07] <ndec> the camera driver should not need it. or there is something else missing.
[17:07] <ppisati> that's what agreen told me
[17:07] <ppisati> but i handed a couple of kernels without this cma to rbasak today, he testd it
[17:07] <ppisati> and all the panicing on boot&c are gone
[17:08] <ppisati> so i pushed the revert since we are close to kernel freeze
[17:08] <ndec> i think the memory hole is just helping to hide another issue ;-)
[17:08] <GrueMaster> ogra_: iirc, we (NCommander and I ) had this discussion last cycle.  Iirc, there was a problem getting others to accept the change.
[17:08] <ndec> I will look into this, i would prefer we make the real fix instead.
[17:08] <ppisati> ndec: that's why i don't want it in (i mean the CMA)
[17:08] <ndec> and our MM stuff with syslink3 will no longer require the memory hole anyways.
[17:09] <ppisati> but that's 3.3+ and we talking about a P kernel
[17:09] <ndec> ppisati: no, i think we should keep it, but you might be missing another config somewhere.
[17:09] <ndec> if you revert this one, you might want to revert the v4l2 camera driver as well, to ensure that nobody will attempt to use it.
[17:10] <ppisati> let me check one thing
[17:10] <ndec> on the other hand if you keep it, and if we fix it properly, then all the boards that have a camera (blaze have, and some panda do) will get support for camera out of the box with 12.04...
[17:10] <ppisati> ndec: does our kernel boot on that boards?
[17:10] <ndec> yep
[17:11] <ndec> sebjan maintains blaze support in tilt tree
[17:12] <ndec> ppisati: let me reply on the mail and let's try to sort it out. you can use the mem hole as a temp workaround. since it's really no longer needed moving forward, i would prefer to get rid of it...
[17:13]  * ogra_ wouldnt be opposed 
[17:13] <ogra_> its one hack less we have in the image builds
[17:14] <ppisati> ok, but then remember to get the memory hole back in place
[17:14] <ogra_> ppisati, i thought ndec just proposed to get rid of it
[17:15] <ppisati> ogra_: actually the opposite
[17:15] <ndec> ;-)
[17:15] <ppisati> ogra_: he wants to reintroduce it to workaround this problem
[17:15] <ogra_> ppisati, anyways, we didnt change anything wrt kernel cmdline in precise yet
[17:16] <ppisati> ogra_: yep
[17:16] <ogra_> its still there, hasnt gone anywhjere
[17:16] <ppisati> ogra_: it's just that this cma came via last kernel update
[17:16] <ogra_> unless you used a netinstall
[17:16] <ppisati> ogra_: and my default boot.scr has those mem args in it
[17:16] <ogra_> right
[17:16] <ppisati> that's whty i didn't notice the panic on boot
[17:17] <ogra_> you will only see it on netinst since apprently NCommander didnt take them into account when building the image *or* in f-k-i
[17:17] <ogra_> not sure where they are missing there exactly
[17:18] <GrueMaster> So, what is going to be the goal here?  a) fix netinstall to include the hole, or b) fix the kernel cma to not need the parameter on the cmdline?
[17:19] <ogra_> sounds like b) as the final goal and a) as the interim
[17:19] <ppisati> right
[17:20] <ogra_> not sure how long b) will take
[17:20] <ogra_> if its only a few days, changing netinst might be wasted time
[17:21] <ogra_> GrueMaster, so the answer is "depends ... "
[17:21] <GrueMaster> Well, we can work around the netinstall issue for now, but I wouldn't recommend it long term.
[17:22] <GrueMaster> If the kernel can be fixed before freeze, then netinstall workaround is the way to go.
[17:22] <ogra_> right
[17:22] <GrueMaster> If not, a more permanent netinstall fix is required.
[17:26] <GrueMaster> Ugh.  Now I remember why it wasn't in the netinstall (or at least on my testing).  u-boot cmdline is limited to ~256 characters.  I'm getting ready to verify it now, but if that is still the case, it screws up automation in a huge way.
[17:33] <GrueMaster> Grrr.  And netinstall doesn't seem to care about debian-installer/add-kernel-opts in the preseed.  grumble.
[17:40] <ndec> GrueMaster: does latest 12.04 image boot on panda and es?
[17:40] <ndec> i was told (didn't try) it wouldn't boot
[17:40] <ndec> on es
[17:41] <GrueMaster> I just booted today's daily-preinstalled desktop image ok.
[17:41] <GrueMaster> And I have a couple of systems running netinstall now.
[17:41] <ndec> on panda ES?
[17:41] <GrueMaster> The desktop is running on my 4460 ES.  Haven't seen any issues.
[17:44] <ndec> ok. thx
[17:44] <GrueMaster> I haven't done a "full" test, but desktop is installed and running.  I'm currently sitting in unity2D with an open terminal.  Couple of kernel warnings in dmesg (early during boot), but nothing serious.
[18:22] <ogra_> bug 920618
[18:22] <ubot2`> Launchpad bug 920618 in debian-installer "Setting "d-i base-installer/kernel/image none" fails to ignore installation w/o kernel" [Undecided,New] https://launchpad.net/bugs/920618