[05:57] <davidm> hello
[10:35] <ogra_> diwic, hey ... no upload of the alsa-libs config files yet ? i think they are harmless and we need them
[10:36] <ogra_> (and having them in now will prevent from asking for freeze exceptions for pluse *and* alsa-lib)
[10:36] <diwic> TheMuso, ^^ (if you're still awake)
[10:37] <diwic> ogra_, TheMuso, I don't think we need an FFE for just the alsa-lib config files, what do you think?
[10:38] <diwic> maybe I got so focused on the big PA patch that I forgot about the config files
[10:38] <ogra_> well, its an upload ... it will end up in the queue and need review after todays freeze
[10:38] <ogra_> so getting it in now saves some work for everyone
[10:38] <diwic> ogra_, FYI, there just was a new upload of alsa-lib but the build failed due to some gcc stuff on the buildds
[10:39] <ogra_> i already talked to te release team about pulse uploads/freezes and we can go forward if we think its safe
[10:39] <diwic> at least on amd64
[10:40] <ogra_> well, if it needs a re-upload adding the configs would be good
[10:44] <diwic> ogra_, how much testing has been done of the config files
[10:44] <ogra_> do they need much testing ? they enable the devices on my panda after running alsaucm
[10:45] <diwic> well, if you have tested them, then that's at least something :-)
[10:45] <ogra_> i must admit i trust TI here that they will work
[10:52] <diwic> ogra_, as TheMuso is the uploader, there is not much I can do - I hope you two can agree on what needs an FFe and what doesn't and that the FFe paperwork is done where it's needed.
[11:05] <TheMuso> Sorry was away for dinner.
[11:08] <ogra_> TheMuso, can we get an alsa-lib upload with the config files added ? they should do no harm
[11:08] <ogra_> and save is a freeze exception
[11:09] <TheMuso> Hrm ok, it seems we are frozen now though...
[11:09] <ogra_> hrm
[11:13] <ppisati> so, what's the magic to get kexec working on arm?
[11:14] <ppisati> kexec -l /boot/vmlinuz-2.6.38-1207-omap4 -append="console=ttyO2,115200 ..."
[11:14] <ppisati> Memory for crashkernel is not reserved
[11:14] <ppisati> Please reserve memory by passing "crashkernel=X@Y" parameter to the kernel
[11:14] <ppisati> but if i add"
[11:14] <ppisati> :
[11:14] <ogra_> kexec is depending on the moon phase and humidity
[11:14] <ppisati> crashkernel=16M
[11:14] <ogra_> only if both match the tight values at the right time it will work ;)
[11:15] <ogra_> *s/tight/right/
[11:15] <ppisati> to /boot/boot.script and flash-kernel, the board doesn't boot anymore
[11:15] <ppisati> :)
[11:15] <ppisati> sounds like a work for the A-Team
[11:15] <ppisati> tataratataaaaaaaa...
[11:15] <ppisati> no, really
[11:15] <ogra_> there were several A teams on it in the last few years
[11:15] <ppisati> do i need that crashkernel thing? and if yes, acceptable value?
[11:16] <ogra_> it usually works exactly one upload long .. the next change usually breaks it
[11:16] <ppisati> :(
[11:16]  * ogra_ has no idea about crashkernel= 
[11:16] <ppisati> k
[11:16] <ogra_> ask in #ubuntu-kernbel i guess
[11:16] <ogra_> -b
[11:28] <TheMuso> ogra_: ok so given what you said in -devel, do you want me to get the alsa-lib config files in the queue?
[11:29] <ogra_> TheMuso, that would be awesome, i'll make sure to have the pulse bits tested before final freeze too
[11:29] <TheMuso> ogra_: Ok thanks, will do.
[11:29]  * TheMuso checks to see if the bug for this work has an alsa-lib task.
[11:29]  * ogra_ adds a pulse task to the bug so only the alsa-lib bit gets closed on upload
[11:30] <ogra_> it has :)
[11:30] <TheMuso> Right.
[11:30] <TheMuso> yeah jsut confirmed.
[11:35] <TheMuso> ogra_: I am going to put these config files in libasound2 only, and not in any bi-arch packaging, since 1) they're not needed in bi-arch packages afaict and 2) they're only for arm anyway.
[11:35] <ogra_> yeah, sounds fine
[11:36] <TheMuso> sweet.
[11:48] <TheMuso> ogra_: Just to check that the files in this tarball, http://afuera.cortijodelrio.net/~ddiaz/paucm/PA_UCM_cofigFiles.tar.gz are the ones you want?
[11:51] <ogra_> TheMuso, righto
[11:51] <TheMuso> ok thanks again.
[11:51] <TheMuso> Uploading now.
[11:51]  * ogra_ hugs TheMuso 
[11:51] <TheMuso> sorry about all the trouble with this. :)
[11:51] <ogra_> lets hope we get the pulse patches solved asap then :)
[11:52] <ogra_> not your fault ... you didnt provide patches short before freeze ;)
[11:52] <TheMuso> Yeah hope so.
[11:52] <ogra_> its not a new problem, we already released maverick without sound, TI could have started earlier
[11:52] <TheMuso> I'll make another package available with the namereg patches included, as per David's review.
[11:53] <ogra_> k, i'll do an armel build and test then
[11:53] <TheMuso> And will start testing here on x86.
[11:53] <ogra_> great
[12:21] <TheMuso> ogra_: Ok an updated package of UCM enabled pulse has been uploaded to my PPA, ppa:themuso/ppa.
[12:21] <TheMuso> Source should be published in an hour or so.
[12:21] <ogra_> thanks, will pull and build then
[12:22] <TheMuso> np.
[12:43] <hrw> I see that janimo works on gconf
[13:45] <ogra_> janimo, any isea about the segfaults of evo-indicator and gnome-games ?
[13:46] <janimo> ogra_, I hope the gconf build fixes indicator
[13:46] <ogra_> i gave both back today and they actually ended up on other buildds but with the same result
[13:46] <janimo> gnome-games was a libgles not found issue, unrelated to the gconftool crashers
[13:46] <janimo> these are liferea, tomboy, indicator-session and evo-indicator
[13:47] <ogra_> ah, tomboy too ? great
[13:47]  * ogra_ was just opening the log
[13:47] <janimo> ogra_, I could not reproduce the gconf crash if I rebuilt locally with -O0 so I uploaded that and fingers crossed
[13:47]  * ogra_ crosses too
[13:54] <hrw> and then some packages needs to be rebuilt
[14:01] <janimo> ogra_, not sure if you said anything else, but I needed to reboot because of natty upgrades being funny again
[14:01] <ogra_> nope, i didnt
[15:11] <ppisati> cooloney: is the XM ok for the test?
[15:19] <rsalveti> ppisati: for the usb otg, yes
[15:20] <ppisati> rsalveti: k
[15:20] <ppisati> rsalveti: BTW, all that memory bugs in omap[3|4}
[15:20] <ppisati> rsalveti: don't you think are somehow related?
[15:21] <ogra_> what are "all that memory bugs" ?
[15:21] <ppisati> 633227, 746137 and 690370
[15:21] <rsalveti> ppisati: sorry, which ones?
[15:21] <ogra_> snap :=
[15:21] <ogra_> :)
[15:21] <rsalveti> let me take a look
[15:21] <rsalveti> bug 633227
[15:21] <rsalveti> where is our bot? :-)
[15:21] <ogra_> bot still dead ?
[15:22]  * ogra_ thought we were over all memory bugs now ... at least on omap4
[15:23] <rsalveti> ppisati: I believe 690370 is a side effect of both 633227 and 746137
[15:23] <rsalveti> ppisati: for now let's just add a comment there requesting a new test with beta-2 image
[15:24] <rsalveti> that should have the workaround for the page allocation and the new boot args for 1g
[15:24] <ppisati> k
[15:24] <rsalveti> ogra_: janimo: btw, thanks for the uploads
[15:24] <ogra_> thanks for the code :)
[15:24] <janimo> rsalveti, cheers
[15:25] <rsalveti> :-)
[15:25]  * ogra_ would appreciate someone who is not him to also test the pulse packages from https://bugs.launchpad.net/ubuntu/natty/+source/alsa-lib/+bug/746023
[15:26] <rsalveti> ogra_: sure, can give it a try
[15:26] <ogra_> awesome
[15:27] <ogra_> you might need to wait for alsa-lib to appear, not sure it has hit the arcive yet
[15:29] <rsalveti> np
[15:31] <rsalveti> ppisati: do you have a proper cable to test the usb otg?
[15:31] <rsalveti> otherwise I can also help testing that
[15:31] <ppisati> rsalveti: yep
[15:31] <rsalveti> ppisati: cool
[15:31] <ppisati> rsalveti: i mean, i have the cable
[15:38] <rsalveti> sebjan: now x-loader package should now be gitorious's head
[15:38] <rsalveti> sebjan: with the additional 3 patches that I sent to the m-l
[15:39] <rsalveti> that should help with panda es >= 2.2 and newer beagle xm
[15:42] <ppisati> can't we enable tftp support in uboot?
[15:42] <ppisati> flashing new kernel is really a waste of time...
[15:42] <rsalveti> well, it'd need usb and ethernet support
[15:42] <rsalveti> don't know if they are working already
[15:42] <rsalveti> jcrigby should know the answer
[15:47] <jcrigby> rsalveti, I have discussions about musb for beagle to enable ethernet but I don't think it works upsteam right now.  I may be working in some other tree.
[15:47] <jcrigby> s/have/have seen/
[15:47] <jcrigby> sorry can't type
[15:48] <jcrigby> also there are other usb protocols that would allow easier testing
[15:49] <ppisati> jcrigby: but that would mean another cable lying around
[15:49] <jcrigby> yes
[15:49] <ppisati> jcrigby: while we all have an eth attached to the boards
[15:49] <ppisati> and tftp is so handy
[15:49] <ppisati> i can compile/rootstock everything on my desktop
[15:49] <ppisati> and boot from there
[15:49] <rsalveti> problem is that the ethernet part is connected with the usb hub
[15:49] <jcrigby> ppisati, I agree that usb/ethernet in u-boot would be useful
[15:49] <ppisati> yep, i know
[15:50] <rsalveti> so, no easy workaround for you here
[15:50] <ppisati> anyway, if it's not ready yet, there's not much we can do
[15:50] <rsalveti> flashing into the sd is still the easiest solution
[15:59] <sebjan> rsalveti: thanks!
[17:18] <ppisati> rsalveti: lp608312
[17:19] <ppisati> rsalveti: i should just connect the usb cable to the board, right?
[17:19] <ppisati> flag@omap:~$ ls -la /sys/devices/platform/musb_hdrc
[17:19] <ppisati> ls: cannot access /sys/devices/platform/musb_hdrc: No such file or directory
[17:20] <rsalveti> ppisati: in theory, yes
[17:20] <rsalveti> hm, weird
[17:21] <ppisati> flag@omap:~$ uname -a
[17:21] <ppisati> Linux omap 2.6.38-8-omap #42 Mon Apr 11 16:48:29 CEST 2011 armv7l GNU/Linux
[17:21] <ppisati> natty kernel
[17:21] <rsalveti> check the config options for OTG
[17:22] <ppisati> [flag@newluxor ubuntu-natty]$ grep -i otg debian/build/build-omap/.config
[17:22] <ppisati> CONFIG_ARCH_OMAP_OTG=y
[17:22] <ppisati> CONFIG_USB_OTG=y
[17:22] <ppisati> # CONFIG_USB_OTG_WHITELIST is not set
[17:22] <ppisati> # CONFIG_USB_OTG_BLACKLIST_HUB is not set
[17:22] <ppisati> CONFIG_USB_MUSB_OTG=y
[17:22] <rsalveti> ppisati: /sys/devices/platform/musb-omap2430/musb-hdrc/mode
[17:22] <ppisati> # OTG and related infrastructure
[17:22] <ppisati> CONFIG_USB_OTG_UTILS=y
[17:22] <ppisati> ok
[17:22] <rsalveti> probably just changed the sysfs path
[17:22] <rsalveti> at least this is what I have at my panda
[17:22] <ppisati> ok ok
[17:22] <ppisati> find will do it
[17:23] <ppisati> btw, i just attached the usb-power cable to the mini-usb socket, right?
[17:23] <ppisati> s/attached/attach/
[17:23] <rsalveti> ppisati: yes, the usb powered one
[17:23] <ppisati> k
[17:38] <GrueMaster> rsalveti: Can the edid data be probed through the i2c hooks on panda?  I want to see if I can detect what may be happening on my panda when it is using the switchbox.  Figure I could easily monitor with the headless image.
[17:39] <GrueMaster> (assuming I can get that to work).
[17:39] <rsalveti> GrueMaster: I know you can if you're using dvi, not sure with hdmi
[17:39] <GrueMaster> ok
[17:41]  * rsalveti lunch
[19:30] <GrueMaster> marvin24: ogra said you are working on the AC100 audio.  Do you have access to the datasheet for the audio codec?
[19:33] <ogra_> marvin24_DT, ^^^
[19:33] <marvin24_DT> GrueMaster: yes
[19:33] <marvin24_DT> em
[19:34] <marvin24_DT> you need a pdf or is an online version sufficient?
[19:34] <GrueMaster> I have one.  Didn't know if you did or not.
[19:34] <GrueMaster> I used to work on HDA drivers.
[19:35] <marvin24_DT> I only have a leaked draft from baidu
[19:35] <marvin24_DT> so you are also working on a codec driver?
[19:36] <GrueMaster> ogra said it is the realtek alc5623.
[19:36] <marvin24_DT> no, alc5632
[19:36] <GrueMaster> I don't have a system, and am too involved with ubuntu testing to do dev work atm.
[19:36] <marvin24_DT> I only used the 23 for reference
[19:36] <GrueMaster> Oh.
[19:36] <ogra_> ah
[19:36] <marvin24_DT> they are similar
[19:36] <marvin24_DT> but you cannot do it in the same driver
[19:37] <marvin24_DT> I think the difference is too large
[19:37] <ogra_> pfft, its only 9 product revisions :P
[19:38] <marvin24_DT> the id register says its revision 0x5c!
[19:38] <marvin24_DT> that's even more
[19:38] <ogra_> heh
[19:38] <marvin24_DT> maybe that's why this register is undocumentated
[19:38] <GrueMaster> Nah, the revisions are just how many changes it took to get it working.
[19:39] <GrueMaster> :P
[19:39] <GrueMaster> I used to have a contact at realtek, but that was 5 years ago.  Wish I could help more.  I don't even have a system to play with (even if I had the time).
[19:40] <ogra_> i thought you sit on michaels ac100 now :)
[19:40] <GrueMaster> ENOTIME.
[19:41] <GrueMaster> I could work on getting that working and just skip beta 2 release testing, but it may reflect poorly on my review.  :P
[19:41] <ogra_> tsk, you sound like if we had a release in a few weeks
[19:56] <GrueMaster> rsalveti: I think I figured out the problem with HDMI and my switchbox.  During boot, the port is reset along with the board causing the switch to jump to the next active port (I catch this and switch back before the kernel loads).  When X starts, the port is again reset and immediately probed.  This reset also causes a switch and the read immediately after gets junk data.
[19:57] <GrueMaster> I think there needs to be a slight delay between reset and read.
[20:18] <GrueMaster> I have a new HDMI switch with "built in equalizer".  Will see how it performs.
[20:19] <rsalveti> GrueMaster: hm, ok, good to know
[20:20] <rsalveti> yeah, give it a try and we'll see the behavior
[20:47] <rsalveti> ogra_: still got 2 asoc: no valid backend routes for PCM: SDP4430 Media messages
[20:50] <rsalveti> now let me test the sound
[20:50] <rsalveti> seems that it'll only work with hdmi
[21:26] <rsalveti> ogra_: can't get audio to work here
[21:45] <GrueMaster> Gahh.  Getting a dpkg error upgrading pulseaudio-utils.
[21:59] <GrueMaster> Appears that pulseaudio-utils is trying to remove a non-existant man page (that I don't think is even pulseaudio related).
[22:01] <rsalveti> ogra_: why deb-src is not setting universe and multiverse too?
[22:01] <rsalveti> $ cat /etc/apt/sources.list
[22:01] <rsalveti> deb http://ports.ubuntu.com/ubuntu-ports natty main restricted universe multiverse
[22:01] <rsalveti> deb-src http://archive.ubuntu.com/ubuntu natty main restricted
[22:01] <rsalveti> same for natty-security
[22:04] <GrueMaster> This should really be fixed in oem-config, not a jasper hack.
[22:04] <rsalveti> agree, but not the case atm
[22:04] <rsalveti> do you know if we have a bug for oem-config for it?
[22:04] <GrueMaster> I remember filing one.  Let me look
[22:07] <ogra_> that might be solvable through a preseed option, let me check
[22:08] <ogra_> rsalveti, can you try running alsaucm ?
[22:09] <rsalveti> ogra_: still nothing
[22:11] <ogra_> did you get any output from alsaucm ?
[22:12] <rsalveti> ogra_: Im setting defaults
[22:13] <ogra_> well, that somewhat suggests it sets up something
[22:13] <GrueMaster> rsalveti: The sources.list bug was 659754, but against jasper-initramfs.
[22:14] <ogra_> it is set there
[22:14] <ogra_> oem-config doesnt ship apt-setup
[22:14] <ogra_> iirc
[22:14] <GrueMaster> How is it done on x86?  Because that works.
[22:14] <ogra_> in oem-config ?
[22:15] <ogra_> on the live image casper sets it up
[22:15] <GrueMaster> Ah.
[22:15] <ogra_> but ubiquity goes over that sources list later
[22:15] <GrueMaster> And since we don't use jasper...
[22:15] <ogra_> we do use jasper
[22:16] <GrueMaster> Is there a rc.once hook we could add to first-boot?
[22:16] <GrueMaster> I meant casper.
[22:16] <ogra_> why would we do that ?
[22:17] <GrueMaster> To better use the apt api and update the sources.list properly.
[22:17] <ogra_> jasper uses python-apt just fine to set it up, it just doesnt set up the deb-src lines, i'll simply add them to the script
[22:17] <GrueMaster> Universe & multiverse are there, just commented.  The api properly uncomments them instead of hacking them on to the end of an existing line.
[22:18] <GrueMaster> How does casper do it?  Jasper should mimic that functionality.
[22:20] <ogra_> GrueMaster, we use the same api
[22:20] <ogra_> its also the same api software-properties uses
[22:21] <GrueMaster> Very odd.  The sources.list on my panda doesn't look the same as on my x86 VM.
[22:23] <ogra_> http://paste.ubuntu.com/592844/
[22:23] <ogra_> thats the script
[22:26] <GrueMaster> yea, I have the bzr branch.
[22:28] <GrueMaster> At any rate, more critical issue with pulseaudio-utils.  Bug 758073.  Not sure if it will clobber new images, and since we are in beta freeze with image builds emminent, I think this should take some priority.
[22:34] <ogra_> grmbl, where is the bugbot
[22:39] <GrueMaster> awol.
[22:46] <ogra_> GrueMaster, are you sure your SD is still ok ?
[22:46] <ogra_> the bug looks more like a filesystem corruption than anything else
[22:49] <ogra_> GrueMaster, hmm, did you rip out the card while the panda was running ? else your dmesg shows some serious SD errors
[22:52] <GrueMaster> I installed several other packages ok.  Of course, this is the *great* SD card from Dallas.
[22:53] <marvin24_DT> GrueMaster: where to report errors in alc5623.c?
[22:54] <GrueMaster> alsa-devel ml.
[22:54] <marvin24_DT> ok
[22:57] <ogra_> hmpf, disconnects ...
[22:58] <ogra_> GrueMaster, the pulse bug looks like a corrupt FS, the manpage belongs to the pa package
[23:02] <ogra_> i also wonder why you got ubuntu2 ... ubuntu3 is in the archive since yesterday already
[23:04] <GrueMaster> Reread the bug report.  Errors were encountered while processing:
[23:04] <GrueMaster>  /var/cache/apt/archives/pulseaudio-utils_1%3a0.9.22+stable-queue-24-g67d18-0ubuntu3_armel.deb
[23:04] <ogra_> oh, grrr apport
[23:04] <GrueMaster> yep
[23:04] <ogra_> Package: pulseaudio-utils 1:0.9.22+stable-queue-24-g67d18-0ubuntu2 [modified:
[23:04] <ogra_> :P
[23:05] <GrueMaster> I renamed the bug report to be a little more readable.  The main info is in the description.
[23:05] <ogra_> well, its doing valid stuff there, the fact that the file it wants to remove ends in .dpkg-tmp is worrying, but at first glance it looks like a filesystem issue
[23:06] <ogra_> you pull the SD out without shutting down, right ?
[23:07] <GrueMaster> I'm not seeing any filesystem issues in dmesg or syslog that correlate time-wise.  The sd issues were from first boot (when my HDMI swithc mangled screen output and I had to reset).
[23:07] <ogra_> well, at the end of dmesg there is a bunch of IO errors
[23:13] <GrueMaster> Not sure what they are from.  Corresponding lines in syslog show it to be prior to first login, way before apt-get update;apt-get dist-upgrade.
[23:13] <ogra_> your disk isnt full, is it ? :)
[23:13] <GrueMaster> 16GB SD???  No.
[23:13] <ogra_> its weird that it happens during unpack
[23:14] <GrueMaster> Yea, well.  As I said earlier, this is on one of the wonderful SD cards we got in Dallas.  I'm trying again on a known good SD.
[23:15] <ogra_> well, check twice, probably the partition was resized but the fs resize failed or some such
[23:16] <ogra_> given that we add 50MB spare space that would work a while before you run out of space
[23:16] <GrueMaster> I've already spent most of the day on this, mainly due to the slow speed of these SD cards.
[23:16] <GrueMaster> Time to move on an redo.
[23:16] <ogra_> k
[23:16] <ogra_> did you upgrade right after install ?
[23:16] <ogra_> or was that an old install ?
[23:17] <GrueMaster> This was the 20110410 image, and I tried to do a dist-upgrade shortly after first login (mainly to see if the gconf crash I had was legit.
[23:18] <ogra_> well, good to know 0410 worked at least :)
[23:20] <GrueMaster> Well, headless was fubar, but I haven't figured that one out yet.  Only one platform supports serial console and I needed it to test the netbook image.
[23:21] <ogra_> i can take over QA responsibility for headless if you want but only after the sound stuff is solved
[23:21] <ogra_> that occupies my time a bit atm
[23:21] <GrueMaster> No, I can handle it.  Biggest issue is a lack of images.
[23:21] <GrueMaster> With freeze, it should help.
[23:21] <ogra_> heh, yeah, that will change soon
[23:21] <ogra_> and with a hopefully working acorn
[23:21] <ogra_> (thats the omap buildd)
[23:22] <ogra_> it crashes way to often recently
[23:22] <GrueMaster> maybe we should have it switched to one of the beaglexm's.  Little more stable.
[23:22] <ogra_> funnily it worked fine most of the release with one or two outages to fail close to release ...
[23:23] <ogra_> its like a deja vu ... i'm 100% positive we had the same in maverick
[23:23] <GrueMaster> Are they special images or can any of the buildds do image building?
[23:24] <ogra_> they need to be native and dedicated
[23:24] <GrueMaster> Might be a good idea to have some sort of intelligent failover.
[23:24] <ogra_> the pandas will help
[23:24] <ogra_> it only has to survive until release day
[23:24] <GrueMaster> I understand both of those, but was currios if the image on them was specific.
[23:24] <ogra_> yes
[23:24] <ogra_> its a special setup afaik
[23:25] <GrueMaster> ok.
[23:25] <GrueMaster> Still, not a bad idea to have a failover mechanism in case a platform goes out to lunch.
[23:26] <ogra_> i think the build script can do that as soon as we have more HW
[23:27] <ogra_> it has mechanisms, but they are currently working on a per-subarch base because we only have two buildds
[23:27] <GrueMaster> Well, this is good news.  I have a new HDMI switchbox that doesn't auto-jump on signal loss, meaning I can go from poweron first boot to oem-config and still see the screen.
[23:28] <ogra_> if acorn doesnt come up anymore i can switch omap manually over to the omap4 one for now, if we have more HW i'll switch it to an automated behavior
[23:28] <ogra_> well, but your switch box was a good stresstest for the driver :)
[23:30] <GrueMaster> Yes, and still a valid test (since the driver is broken when I use it).  I bought a new one as I plan to reconfigure my office with 3 different stations:  1 VGA, 1 DVI, 1 HDMI/1080p.
[23:31] <GrueMaster> The DVI will have the systems that don't do 1080p (and will be close enough for crossover testing).
[23:31] <GrueMaster> I.E. Beagle/BeagleXM/Babbage.