[07:44] <sveinse> We've been running our prototypes from maverick using rootstock which does not install a kernel nor a initrd file. Why do Ubuntu need a initrd script and why does it apparently seem to work without one?
[09:00] <ppisati> morning
[10:40] <sveinse> We've been running our prototypes from maverick using rootstock which does not install a kernel nor a initrd file. Why do Ubuntu need a initrd script and why does it apparently seem to work without one?
[10:42] <sveinse> I.e. all necessary features are compiled into the kernel, so I don't need modules. Apart from that, what is initrd doing?
[10:43] <ogra_> read up about initramfs-tools, its deeply integrated with the packaging system (packages can put bits and pieces into the initrd) ...
[10:44] <ogra_> some packages rely on functions that are only possible while / isnt mounted yet (fsck, lvm, dmraid, entrypted filesystems etc)
[10:44] <ogra_> *encrypted
[10:45] <ogra_> while ubuntu will work fine without initrd, if one of your users installs something like the encryption stuff, encrypts / and reboots without initrd, he trashed his install
[10:46] <ogra_> if you can take that risk ... live without initrd :)
[10:47] <sveinse> one point though (and only one from your list): fsck. Rather important.
[10:47] <sveinse> Thanks
[10:49] <sveinse> in this natty release frenzy, how is armel doing?
[11:00] <ogra_> quite well, though there was a heavy issue with libreoffice
[12:23] <sempil> how
[12:42] <ericb2> hi
[12:42] <ericb2> I did an apt-get dist-upgrade on my OMAP3 (Beagleboard xM) and X.org is frozen ... :/
[12:42] <ericb2> more precisely, the mouse cursor is frozen
[12:43] <ericb2> is there a known reason and in this case,  what is the guilty archive, what has to be done ? .. and so on
[12:43] <ericb2> thanks in advance
[12:58] <ericb2> looks like ssh works ... better than nothing :/
[13:16] <rsalveti> ericb2: are you using it with a sd card?
[13:31] <rsalveti> janimo: have any idea why some packages from libreoffice didn't contain armel at it's architecture?
[13:32] <janimo> rsalveti, no, I only saw your bugreport today
[13:32] <janimo> AFAIK LibO used to build and work fine on arm during natty
[13:32] <janimo> since about 3.3.1 at least when it started building fully
[13:32] <rsalveti> janimo: hm, ok, do you remember how many hours it usually takes to finish the build at our builders?
[13:32] <janimo> over 1 day
[13:33] <rsalveti> 10 hours until now, and still building, hopefully it will work just fine
[13:33] <janimo> did some armhf patches get in via debian?
[13:33] <rsalveti> janimo: yes
[13:45] <ogra_> rsalveti, so you are rebuilding locally atm ?
[13:45] <rsalveti> ogra_: both locally and at the PPA
[13:46] <ogra_> ah, k
[13:46] <ogra_> so we could pocket-copy it from the PPA ?
[13:46] <ogra_> (once the binaries are there)
[13:47] <rsalveti> ogra_: that's the idea
[13:47] <ogra_> ah, cool
[13:48] <ogra_> bah, i cant commit to desktop-webmail upstream
[13:48] <ogra_> JamieBennett owns it
[13:48]  * JamieBennett hides
[13:48] <JamieBennett> ogra_: you can have it now ;)
[13:49] <ogra_> heh, assign it to canonical-arm then
[13:49] <JamieBennett> ogra_: infact -webmail is asac's
[13:49] <ogra_> though probably a general core-dev approval would be better
[13:50] <ogra_> asac, ^^^ can you hand that over to core-dev ?
[13:50] <ericb2> rsalveti: yes, I'm using it using an sd card
[13:50] <rsalveti> ericb2: so it could be that the heavy i/o from dpkg is making your beagle useless
[13:51] <ericb2> rsalveti:  :-/
[13:51] <ericb2> rsalveti: what has to be done ?
[13:51] <ogra_> fix dpkg to require less resources ;)
[13:51] <ogra_> or more likely debconf than dpkg
[13:51] <ogra_> or switch to use an USB disk
[13:51] <ericb2> ogra_: what does the bug exactly ? (what are the symptoms ? )
[13:52] <rsalveti> even a faster sd card can help already
[13:52] <ogra_> yeah
[13:53] <ericb2> rsalveti: I can connect to the beagle using ssh
[13:53] <JamieBennett> mine is -office
[13:53] <ericb2> rsalveti: at least I did once. e.g. I restarted gdm, but unsuccessfully
[13:54] <ericb2> janimo: FYI, OOoLight works well on the beagleboard too
[13:54] <janimo> ericb2, great to hear that :)
[13:54] <janimo> fast enough?
[13:54] <ericb2> janimo: first launch is 10s
[13:54] <ogra_> form SD ?
[13:54] <ogra_> thats fast !
[13:54] <ericb2> janimo: the proc is 800MHz and I got 512 MB of RAM
[13:54] <ericb2> ogra_: from sd, yes
[13:55] <ericb2> compiled from sd too
[13:55] <asac> ogra_: what do you need it for?
[13:55] <ericb2> and starting second launch around 3 s
[13:55] <asac> ogra_: committing? i dont even see an attempt to propose or merging ;)
[13:55] <ogra_> asac, we ship it by default ... bug 769235 has a fix
[13:55] <ubot2> Launchpad bug 769235 in desktop-webmail "Icons & app names identical for desktop-email & desktop-email-config" [Low,Confirmed] https://launchpad.net/bugs/769235
[13:56] <asac> ogra_: junk is probably not the best place to push such patches
[13:56] <ogra_> asac, well, i'm lazy with LP ...
[13:56] <ogra_> asac, well, bzr push lp:desktop-webmail didnt work and i need to move on ... +junk is still better than losing it from my disk ;)
[13:56] <asac> ogra_: can you push that to lp:~ogra/desktop-webmail/lp769235 and just hit propose for merge?
[13:57] <asac> ogra_: you dont know how launchpad works, right?
[13:57] <ericb2> rsalveti: do you have the dpkg bug report at hand please ?
[13:58] <asac> i think bzr could be improved to have a command: bzr push-merge-proposal-for lp:desktop-webmail ;)
[13:58] <ogra_> asac, slow, right ?
[13:58] <asac> ogra_: no ... but you can just push to the proper project and dont need to use junk
[13:58] <asac> ogra_: like i said: lp:~ogra/desktop-webmail/lp769235 would be appropriate
[13:58] <ogra_> pushed that way now
[13:58] <asac> cool
[13:58] <ogra_> opening the page will take me 20min though
[13:58] <ogra_> so i will do the proposal later
[13:58] <StevenK> asac: bzr lp-propose
[13:59] <asac> ogra_: i can propose. thanks
[14:42] <pgraner> GrueMaster, ping
[14:46] <rsalveti> ogra_: the slideshow seems to be disabled at the latest netbook daily image, is this expected?
[14:47] <rsalveti> got from 20110426.4
[15:08] <rsalveti> ogra: GrueMaster: from 20110426.4: slideshow disabled at the installed, software center gave me a "not found" while trying to install the omap 4 extras because it seems that it didn't run apt-get update and I'm getting a lot of fifo underflow :-(
[15:08] <rsalveti> *installer
[15:09] <ogra> missing apt-get update is a fee we have to pay for changing the sources.list from jasper
[15:10] <ogra> (no network, so no update run)
[15:17] <rsalveti> ogra: and still a lot of "asoc" error messages at the kernel log, shouldn't this be fixed already?
[15:17] <rsalveti> or are we waiting the fix to hit the updates?
[15:17] <ogra> no, its fixed, but tobin seems to have found that one reboot is needed for it to properly take effect
[15:18] <rsalveti> hm, interesting, will try
[15:18] <ogra> i guess we need to create the state file from jasper
[15:18] <ogra> or some such ...
[15:18] <ogra> havent looked deeper yet
[15:34] <rsalveti> ogra: showing just pandahdmi output and still reporting the error messages
[15:34] <rsalveti> and no packages to update, using latest stuff
[15:34] <ogra> yes, the fixes are in the packages sine a week
[15:34] <ogra> *since
[15:35] <ogra> it shoudl just work
[15:35] <rsalveti> ogra: what was the fix?
[15:35] <ogra> adding the patches and a proper udev rule to select the right ucm profiles
[15:38] <GrueMaster> pgraner: Pong
[15:38] <rsalveti> ogra: udev rule is there, but still broken
[15:38] <GrueMaster> ogra: Audio does not come up after a single reboot.  It appears that alsaucm is never run.
[15:42] <ogra> GrueMaster, well, thats strange sinc ethe udev rule runs it
[15:42] <ogra> and that just matches against the device name
[15:42]  * ogra has a netbook image ready, will test myself
[15:43] <GrueMaster> Does it?  Because I am not seeing audio until I run alsaucm manually then reboot.
[15:43] <ogra> well, there *should* be a udev rule :)
[15:44] <GrueMaster> There is, but I don't think it gets executed.
[15:44] <rsalveti> udev rule is there, could be that the device name is not right
[15:44] <ogra> ask diwic if it actually ended up in the upload where the changelog claims it did :)
[15:44] <rsalveti> or something similar
[15:48] <ogra> for anyone intrested, i think we can have proper images for the ac100 now with the .37 kernel ... you can actually update kernel and initrd from the running device
[15:48] <ericb2> looks like I got the network working. Can I downgrade dpkg or something to make it work again ?
[15:48] <ogra> i think i'll roll a community image for it in oneiric
[15:49]  * ericb2 still wondering why x.org does not work after a big apt-get dist-upgrade on Beagleboard (xM) 
[15:52] <ogra> err
[15:52] <ogra> where is the slideshow ?
[15:52] <ogra> (and more important, why isnt there a bug for it missing)
[15:52] <rsalveti> ogra: I said you earlier, the slideshow seems to be gone
[15:53] <rsalveti> I asked you if this is expected or not
[15:53] <GrueMaster> ogra: I was trying to debug it and got sidetracked yesterday.  It is only affecting armel.
[15:53] <rsalveti> that's why I didn't fill a bug yet
[15:53] <rsalveti> ogra: http://paste.ubuntu.com/599329/
[15:53] <GrueMaster> I tested it on x86 in a VM.
[15:53] <ogra> hmm
[15:53] <ogra> it surely speeds up the install
[15:54] <ogra> ARGH !
[15:54] <ogra> rsalveti, thanks, that says everything
[15:54] <ogra> oh my
[15:55] <pgraner> GrueMaster, FYI I tested the OMAP4 images and no issues according to the test on the ISO tracker
[15:55] <ogra> GrueMaster, rsalveti: sudo ln -s /usr/bin/alsaucm /lib/udev/alsaucm
[15:55] <GrueMaster> pgraner: How exactly did you test them?  There are several issues.
[15:56] <rsalveti> ogra: yep, testing that
[15:56] <ogra> that should fix it
[15:56] <ericb2> what is the last dpkg version correctly working ?
[15:56] <ogra> i dont really know if i can use absolute paths in udev rules
[15:56] <pgraner> GrueMaster, like I said following the tests on the iso tracker
[15:56] <ogra> but i guess that would be the right fix
[15:56] <ogra> i wouldnt have expected the helper to look in a hardcoded path
[15:57] <rsalveti> 85-usbmuxd.rules:ACTION=="remove", SUBSYSTEM=="usb", ENV{PRODUCT}=="5ac/12[9a][0-9a-f]/*", ENV{INTERFACE}=="255/*", RUN+="/usr/sbin/usbmuxd -x"
[15:57] <rsalveti> ogra: seems we can
[15:57] <pgraner> GrueMaster, http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage
[15:57] <rsalveti> let me test with the full path
[15:57] <ogra> rsalveti, ah, didnt think of just grepping :P
[15:57] <pgraner> GrueMaster, if there are others let me know I have two Panda's here to test with
[15:58] <rsalveti> ogra: :-)
[15:58] <GrueMaster> pgraner: Bugs I had listed yesterday:  bug 758486, bug 746023, bug 769235.
[15:58] <ubot2> Launchpad bug 758486 in linux-ti-omap4 "omapdss DISPC error on Panda platform" [Medium,New] https://launchpad.net/bugs/758486
[15:58] <ubot2> Launchpad bug 746023 in alsa-utils "No sound on omap4" [High,Fix released] https://launchpad.net/bugs/746023
[15:58] <ubot2> Launchpad bug 769235 in desktop-webmail "Icons & app names identical for desktop-email & desktop-email-config" [Low,Confirmed] https://launchpad.net/bugs/769235
[15:59] <ogra> 769235 has a fix already and will be an SRU
[15:59] <GrueMaster> Also, there is an installer bug yet to be filed, oem-config doesn't run the slideshow during installation.
[15:59] <ogra> which is cosmetic ...
[15:59] <pgraner> GrueMaster, I'm not seeing test cases for any of those issues, I only see the one I posted to you or am I missing something
[16:00] <GrueMaster> pgraner: Also, the image seed was changed last Thursday, so there are a lot of apps that haven't been tested.
[16:00] <GrueMaster> pgraner: I list all known bugs during release testing.
[16:00] <GrueMaster> Not just what the testcase says to look for.
[16:01] <pgraner> GrueMaster, do you have additional test cases?
[16:01] <GrueMaster> And since we had the seed change, I have been going over everything.
[16:01] <GrueMaster> No, I don't.
[16:01] <GrueMaster> I just run programs and see what works & what doesn't.
[16:03] <GrueMaster> The main testcase you refer to is specific to armel installation on omap3/omap4 platforms.  The rest is just like testing the desktop apps.
[16:03] <ogra> pgraner, "use the image and all apps" is our main testcase
[16:05] <pgraner> ogra, GrueMaster, thanks
[16:06] <rsalveti> ogra: http://paste.ubuntu.com/599337/ worked when I triggered udev add events by hand
[16:06] <rsalveti> let me try rebooting
[16:06] <ogra> ah, cool
[16:06]  * GrueMaster goes to get massively caffeinated prior to starting testing.
[16:07] <ogra> hmm, the slideshow is still isted for the netbook-live task
[16:07] <ogra> but it doesnt end up on the image
[16:07]  * ogra scratches head
[16:10] <GrueMaster> It is in the manifest.
[16:13] <ogra> not in mine
[16:13] <GrueMaster> which package are you looking at?
[16:14] <ogra> i search for slideshow
[16:14] <GrueMaster> ubiquity-slideshow-ubuntu 40
[16:15] <ogra> i dont have it in the current manifest
[16:15] <GrueMaster> Thats what fgrep ubiquity 20110426/natty-preinstalled-netbook-armel+omap4.manifest reports.
[16:15] <ogra> not sure what you look at
[16:15] <ogra> GAR !
[16:15]  * ogra curses chromium
[16:15] <ogra> just FYI ... the slideshow is definitely not installed on headless
[16:15] <rsalveti> ogra: ok, worked fine, will prepare the debdiff
[16:15]  * ogra grumbles
[16:16] <GrueMaster> why would we have a slideshow in headless?  :P
[16:16]  * GrueMaster offers coffee infusion to ogra
[16:16] <ogra> GrueMaster, ask chromium why it gave me the cdimage page i just *didnt* want
[16:16] <ogra> it should guess the right one from my thoughts !!!
[16:17] <GrueMaster> Actually, I should ask why you don't just pull a local copy with wget when you zsync the image.
[16:17] <ogra> i rarely look at the manifest unless something is wrong
[16:18] <GrueMaster> I always look at the manifest because it is rare that something isn't wrong.
[16:19] <ogra> heh
[16:20] <GrueMaster> Besides, doing a diff between builds lets me know what changed and what to focus testing on.
[16:20] <GrueMaster> (especially when someone changes the image seed close to release).
[16:20] <GrueMaster> :P
[16:22] <ericb2> is there somebody able to help me on the channel : got Ubuntu on BeagleBoard, and after I did a big apt-get dist-upgrade, I got x.org started, but no keyboard, nor mouse .... thanks in advance for any help or hint
[16:23] <ogra> rsalveti, hmm, just using the udev rule doesnt help for me
[16:23] <ericb2> could be gdm broken, or one lib gdm depends. But can be something completel different
[16:23] <ogra> rsalveti, it only works after i ran alsaucm manually
[16:23] <rsalveti> ogra: hm, I just triggered udev by hand and then rebooted
[16:23] <rsalveti> now it's fine
[16:23] <ericb2> ssh works, the network too and I can install, update
[16:23] <GrueMaster> ericb2: Try logging into a console and rerunning "sudo apt-get -f install" to make sure all packages are installed and updated.
[16:24] <ericb2> GrueMaster: I did one minute ago
[16:24] <ogra> rsalveti, well, it might be that it needs the init once
[16:24] <ericb2> GrueMaster: maybe some missing modules (or not loaded )
[16:25] <ericb2> something around usb
[16:25] <ogra> i definitely had no sound (and did about 5 reboots to make sure) without running the command once
[16:25] <rsalveti> ogra: ok, will fire up a new image with just this fix included to see how it goes
[16:26] <ogra> sigh, and GDM takes about a century on a class2 card
[16:26] <ericb2> GrueMaster: the exact state is :  my login name  (eric) selected, and under the mouse cursor, I can read "Login as eric"
[16:26] <ericb2> GrueMaster: but the cursor is stalled, like the keyboard and mouse
[16:27] <GrueMaster> ericb2: Do you see any messages in dmesg regarding keyboard & mouse?
[16:28] <ogra> rsalveti, i didnt run the Record verb and even after several reboots i have no input device (which is what record creates)
[16:29] <rsalveti> ogra: hm, weird
[16:29] <ogra> so your manual trigger has done the initialization i guess and the state file brings it back to the state it had on shutdown
[16:30] <ogra> i bet even removing the rule will still get you working sound after reboot
[16:30]  * ogra tries that
[16:31] <rsalveti> ogra: the manual trigger should be the same trigger that happens while booting the device
[16:31] <ericb2> GrueMaster: [    4.711303] input: PS/2+USB Mouse as /devices/platform/ehci-omap.0/usb1/1-2/1-2.3/1-2.3:1.1/input/input2
[16:31] <ericb2> GrueMaster: looks ok at least for the mouse
[16:32] <ogra> rsalveti, well, lets see, i removed the rule and am just rebooting
[16:32] <ericb2> GrueMaster: imho, this rather could be an x.org issue with keyboard + mouse or something
[16:34] <ogra> rsalveti, yup, sound is there even without the rules file, it is restored from the state file
[16:34] <ericb2> GrueMaster: and /var/log/syslog says :  http://paste.lisp.org/display/121603
[16:35] <ogra> (and record is still missing as well)
[16:36] <ericb2> GrueMaster: interesting : click either the mouse buttons or the keyboard do nothing (meant : nothing is detected)
[16:37] <rsalveti> ogra: janimo: why do we have mpurate=900 at the headless image for omap 3?
[16:37] <rsalveti> that's not compatible with old beagles, like C4
[16:37] <ogra> rsalveti, does it do any harm ?
[16:37] <rsalveti> I can't even boot at my C4
[16:37] <ogra> argh
[16:37] <GrueMaster> ericb2: Why do you have oem-config installed?
[16:37] <ericb2> GrueMaster: let me check
[16:38] <ogra> rsalveti, i added that a while ago to get the XM to full speed
[16:38] <GrueMaster> rsalveti: My beagle C4 is working fine on headless.
[16:38] <ogra> i thought kernels not capable of using 900 would just ignore it
[16:38] <rsalveti> ogra: did you add this just at the headless image?
[16:38] <ogra> GrueMaster, check your cmdline
[16:38] <ogra> rsalveti, i dont think so
[16:39] <rsalveti> hm, let me check it again, but after removing it I'm able to boot
[16:39] <ogra> should be on all omap3 ones
[16:39]  * ogra checks the code
[16:39] <ericb2> GrueMaster: looks like it isn"t. Shall I install it ?
[16:39] <GrueMaster> It is in your pastebin, that is why I ask.
[16:40] <ogra> yeah, its in all omap3 images
[16:40] <rsalveti> ok, so it could be a different but, let me check it properly
[16:40] <rsalveti> *bug
[16:40] <GrueMaster> ogra: rsalveti http://paste.ubuntu.com/599358/
[16:41] <ericb2> GrueMaster: don't ask me why :)  I'll try to install it, and I'll keep you informed about the progress. Thanks anyway :)
[16:41] <rsalveti> GrueMaster: is this a C4?
[16:41] <GrueMaster> ericb2: YOu don't need it.
[16:41] <ericb2> GrueMaster: arf ..
[16:41] <GrueMaster> rsalveti: yes.
[16:41] <ericb2> GrueMaster: so what shall I do ? uninstall it ?
[16:41] <ogra> GrueMaster, thats a C4 ?
[16:41] <GrueMaster> ogra: yes.
[16:41] <ogra> wow
[16:42] <ogra> i didnt know they could run that fast :)
[16:42] <rsalveti> hm, the only difference is that I'm also using it with the zippy expansion board
[16:42] <GrueMaster> It is the only beagleboard I have.
[16:42] <rsalveti> it probably can, but not that stable I'd say
[16:42] <ogra> oh, i thought you got an XM replacement at some point
[16:42] <GrueMaster> That is an XM.
[16:42] <ogra> you said C4
[16:42] <GrueMaster> This is an original beagleboard.
[16:42] <ogra> C4 != XM
[16:42] <GrueMaster> I know that.
[16:43]  * ogra is confused now
[16:43] <GrueMaster> I have both.  But I don't have any other rev of beagleboard.
[16:43] <GrueMaster> BeagleXM is a different product.
[16:43] <ericb2> GrueMaster: I got an xM if this can help you
[16:43] <ogra> you have a C4 and an XM but you only have one beagleboard ?!?
[16:43]  * ogra is even more confused now
[16:43] <GrueMaster> ericb2: Sadly, I am a bit usy with last minute release work.
[16:44] <ericb2> GrueMaster: I understand. thanks anyway :)
[16:44] <GrueMaster> ogra: The beagleboards include up to Rev C4.  The beagleXM is an entirely different product.
[16:44] <ogra> GrueMaster, XM and Cx or Bx are the same product ...
[16:44] <GrueMaster> Similar to Panda.
[16:45] <ogra> different revision, but same product
[16:45] <GrueMaster> No, XM has a different rev CPU.
[16:45] <phh> beagleXM similar to panda ?
[16:45] <phh> wut ?
[16:45] <GrueMaster> Check your specs.
[16:45] <ogra> still, the product is called beagleboard
[16:45] <GrueMaster> sigh.
[16:45] <GrueMaster> No, it is called beagleXM.
[16:45] <ogra> ask TI why they prevented us from finding the difference in cpuinfo :)
[16:45] <phh> BeagleBoard-xM delivers extra ARM ® Cortex TM -A8 MHz now at 1 GHz and extra memory with 512MB of low-power DDR RAM,
[16:45] <phh> I stopped at the first line.
[16:45] <phh> it's not like panda.
[16:46] <GrueMaster> Ok, there is too much noise in the channel.
[16:46]  * GrueMaster goes back to testing.
[16:47] <ogra> GrueMaster, so does your C4 behave stable then at 900MHz ?
[16:47] <GrueMaster> Seems to, at least for headless.
[16:47]  * ogra wouldnt have expected it to even scale to 900)
[16:47] <ppisati> do anyone know where i can find a gdb for arm? i.e. arm-linux-gnueabi-gdb
[16:47] <GrueMaster> It was running all night untill I reimaged it this morning.
[16:47] <ppisati> or do i have to roll my own?
[16:48] <ogra> apt-get install gdb ?
[16:48] <ppisati> i need ar arm one
[16:48] <ericb2> GrueMaster: apt-get autoremove + disconnect/reconnect all usb stuff fixed the issue
[16:48] <ogra> (which should actually be installed)
[16:48] <phh> ppisati: apt-get install gdb should install an arm one :p
[16:48] <phh> oh well you need an arm system.
[16:48] <ogra> ppisati, that gets you an arm one on the right platform ;)
[16:48] <ppisati> :)
[16:48] <ppisati> ok
[16:48] <phh> everyone here got an arm as main system no ? :p
[16:48] <ppisati> i'm chasing the kexec stuff
[16:48] <ppisati> it hangs after relocation
[16:48] <ppisati> so i need jtag now
[16:49] <ppisati> i managed to setup openocd on panda
[16:49] <ppisati> so fa so good
[16:49] <ppisati> but now i need a proper gdb
[16:49] <ogra> phh, one at least ... some of us are exaggerating though like GrueMaster ... he has many :P
[16:49] <ogra> one arm for every hand !!!
[16:49] <ppisati> one arm for my reign!
[16:49] <phh> one ac100 for every hand here yeah
[16:49] <ppisati> ok, i tri the codesourcery toolchain
[16:49] <ogra> phh, oh, you have a second one ?
[16:49]  * ogra is envious
[16:50] <phh> ogra: how the fuck do you test on your main system ? :p
[16:50] <ogra> by using a different one while testing
[16:50] <ogra> thats why i do it so rarely :)
[16:50] <ogra> over easter i switched completely to 2.6.37 though
[16:51] <phh> i was fed up of doing tests only once a month, so I got another ac100 :p
[16:51] <ogra> that makes everything easier
[16:51] <phh> it's still the cheap french ones though
[16:51] <phh> no 3G no BT
[16:51] <GrueMaster> We can't even get them in the States.
[16:51] <ogra> well, the shop i got mine from still wants 299€ for it ... and i havent gotten around ordering one from the cheaper shops online
[16:51] <phh> hihihi
[16:52] <ogra> but i plan to ... and a mPCI SD
[16:52] <ogra> *SSD
[16:52] <phh> GrueMaster: you can't have everything
[16:52] <phh> ogra: I only plan to change my panel
[16:52] <phh> with planning being something really long term :D
[16:52] <GrueMaster> Sure we can, as long as it runs Windows 7.
[16:52] <ogra> that possibly too
[16:52] <ogra> first of all i want a usable disk
[16:53] <phh> ogra: and your '...' is soldering some more ram ?
[16:53] <phh> (just saying.)
[16:53] <ogra> HD screen is next on my list :)
[16:53] <phh> well, the panel has two  goals:
[16:53] <phh> get an HD screen
[16:53] <ogra> more ram would be awesome but i'm not good at SMD soldering
[16:53] <phh> get a new screen
[16:53] <phh> not that I killed my current panel
[16:53] <phh> but err, yes.
[16:53] <ogra> heh
[16:54] <ericb2> For the record : disconnect/reconnect all USB devices , is mandatory when you log out / login
[16:54] <ogra> well, $90 isnt bad for a replacement that also does HD
[16:54] <phh> yeah
[16:54] <ericb2> now it works ...
[16:54] <GrueMaster> I have 8G of DDR2 sitting here on my desk waiting for testing to finish so I can upgrade my desktop from the current 3G.
[16:54] <ogra> but thats lame ... doesnt involve soldering at all
[16:55] <phh> :)
[16:55] <ogra> its more exciting if you can break it :)
[16:55] <GrueMaster> ericb2: Sounds like something else is wrong.  The natty images work fine here on beagle/XM/Panda w/o hotplugging the USB.
[16:58] <GrueMaster> Whoa, this is interesting.  mpurate=900 is on both headless & netbook images.  My beagleboard (C4) is showing 893 bogomips, and my XM is showing 782.
[16:59] <GrueMaster> Oh, and cpuinfo does show a difference between the two.  C4: CPU Variant 0x1  XM: CPU Variant 0x3
[17:02] <ppisati> code sourcery toolchain had one, and it works
[17:02] <phh> ppisati: good to know
[17:05] <ogra> ppisati, i'm pretty sure we have a packaged one in the cross toolchain, hrw would know where though
[17:06] <ogra> GrueMaster, yeah, but they explicitly have not changed the Hardware entry between the revisions
[17:06] <ogra> btw, all apps that were added with the recent meta change have been working here
[17:07] <ogra> i gave all of them some small function tests
[17:07] <GrueMaster> Yes, I tested them here over the weekend.
[17:07] <ogra> great
[17:08]  * ogra would like to know if mpurate can actually cause any instabilities ... honestly i would prefer to go with 900MHz on the XM (instead of 600) and rather say we stop supporting C4 officially without image modification
[17:09] <GrueMaster> I would say leave headless w/o mpurate and mark the netbook for XM only.
[17:09] <ogra> GrueMaster, i think bogomips are more than just cpu speed, to get the actual MHz value look in dmesg
[17:09] <ogra> ugh, adding a flavour specific hack additionally?
[17:10] <ogra> i dont think that flies two days before release ... its either all omap3 image on or all of them off
[17:10] <GrueMaster> Well, you could always add a hack in jasper to detect the cpu variant.
[17:10] <GrueMaster> I was thinking of Oneiric.
[17:11] <ogra> sure, and i can grow grass on my knee if i dont move for long enough :)
[17:11] <GrueMaster> For now, we release note it.
[17:11] <ogra> yeah
[17:11] <ogra> well, i sense a respin anyway
[17:11] <GrueMaster> why?
[17:11] <ogra> so we still have a chance to drop it ... but its an all or nothing thing in natty
[17:11] <ogra> GrueMaster, if we find an easy fix for slideshow and sound, wouldnt you want them in ?
[17:12] <GrueMaster> slideshow is not a showstopper.  Audio can easily be fixed with an update.
[17:12]  * ogra doubts audio is fixable easily outside of jasper
[17:12] <GrueMaster> I'd rather not respin unless it is critical or the entire mess is respun (all arches).
[17:13] <GrueMaster> Can't the udev rule be updated with the correct path to alsaucm?
[17:13] <ogra> sure, but it changes nothing
[17:13] <rsalveti> ogra: GrueMaster: up, can't boot: http://paste.ubuntu.com/599371/
[17:13] <ogra> at least here
[17:14] <rsalveti> finished the headless installation without the mpurate argument, and then added it again by hand
[17:14] <rsalveti> at next reboot the kernel get stuck
[17:14] <ogra> weird, i dont even see it setting the mpurate
[17:15] <ogra> [    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
[17:15] <ogra> you should actually have another line where it tells you that it re-sets to a different value
[17:15] <rsalveti> let me try with different values
[17:15] <rsalveti> that's all I have
[17:16] <ogra> yeah, i belive you :)
[17:16] <ogra> i just know it looks quite different on my XM if it actually changes the value during boot
[17:17] <GrueMaster> Out of curiosity, why is the uboot delay on omap3 10 seconds, and only 3 seconds on panda?
[17:17] <ogra> GrueMaster, blame jcrigby :)
[17:18] <rsalveti> GrueMaster: there's a patch to fix this upstream already
[17:18] <ogra> its a compile time default
[17:18] <rsalveti> yeah
[17:18] <rsalveti> ogra: mpurate=720 boots fine
[17:18] <ogra> grmbl
[17:18] <rsalveti> ogra: this is what should be the next line:
[17:18] <rsalveti> [    0.527679] Switched to new clocking rate (Crystal/Core/MPU): 26.0/332/720 MHz
[17:18] <ogra> yeah
[17:18] <rsalveti> so it seems it got stuck while trying to set the clock
[17:18] <ogra> thats what i have on XM (with different values)
[17:19] <ogra> damned
[17:19] <rsalveti> OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz
[17:19] <rsalveti> from u-boot
[17:19] <rsalveti> beagle c4 should be stable with 720
[17:19] <ogra> NCommander, janimo, rsalveti, GrueMaster, persia ... votes ... do we respin or not ?
[17:20] <rsalveti> ogra: I think we have a kernel patch that changes that at the kernel side, let me try to look for it first
[17:20] <ogra> doesnt help much if you cant install at all
[17:20] <GrueMaster> I vote no unless it is required.  Make the changes so they are there if we do need to respin.
[17:20] <rsalveti> yeah, we would need a respin or at least a big note at the release notes
[17:22]  * ogra waits for more votes ... thats +1 vs -1 atm
[17:23] <GrueMaster> List the fixes that would be picked up in a respin.
[17:23] <ogra> GrueMaster, well, we dont have any fix for sound nor for slideshow atm
[17:24] <ogra> so mpurate would be the only one if we respun right now
[17:24] <GrueMaster> If you don't have a fix for them, respin currently does nothing.
[17:24] <ogra> it makes old beagle work
[17:24] <ogra> and new beagle slower
[17:24] <GrueMaster> I haven';t seen a problem on my old beagle yet.
[17:24] <GrueMaster> I only run it headless though.
[17:24] <rsalveti> that probably depends on the hardware
[17:25] <rsalveti> it's an overclock
[17:25] <GrueMaster> right.
[17:25] <ogra> right
[17:25] <ogra> for C series its an overclock
[17:25] <GrueMaster> Can be release noted.
[17:25] <rsalveti> I can't get mine to boot even with 800
[17:25] <ogra> XM is actually supposed to run up to 1GHz
[17:25] <rsalveti> let me check if our u-boot is setting the mpurate value
[17:26] <ogra> my XM runs at 600MHz if you dont set it on cmdline
[17:26] <GrueMaster> ubuntu@beagle:~$ dmesg|fgrep Crystal
[17:26] <GrueMaster> [    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/500 MHz
[17:26] <GrueMaster> [    0.357208] Switched to new clocking rate (Crystal/Core/MPU): 26.0/332/900 MHz
[17:26] <ogra> so i would say u-boot doesnt
[17:26] <GrueMaster> From my beagle C4
[17:26] <rsalveti> u-boot just sets the mpurate var
[17:26] <ogra> yeah
[17:26] <rsalveti> you still need something like mpurate=$mpurate
[17:26] <rsalveti> something like that
[17:26] <ogra> but no value
[17:27] <rsalveti> yup, seems to be setting it up
[17:27] <ogra> davidm, thoughts ?
[17:27] <rsalveti> let me see if I can get that with our kernel
[17:28] <rsalveti> if we can get it to get the right value from u-boot, then I believe we should make a respin
[17:28] <rsalveti> because it'll always be the right clock
[17:28] <rsalveti> ogra: http://paste.ubuntu.com/599374/
[17:28] <rsalveti> 600 for beagle a/b
[17:28] <rsalveti> 720 for c4
[17:28] <rsalveti> and 1000 for xM
[17:28] <ogra> 1000 doesnt work
[17:29] <rsalveti> why not?
[17:29] <ogra> 900 is the highest i could get (i tested the option before adding it )
[17:29] <rsalveti> hm
[17:29] <ogra> (indeed i didnt test on Cx)
[17:29] <phh> the bootloader scripts i've seen states that there is a bug in kernel that prevents it from going to 1G
[17:29] <ogra> i think there is some linux-omap patch that enhances it to 1000
[17:30] <ogra> which we dont have in our mainline kernel
[17:30] <ogra> some koen magic :)
[17:30] <rsalveti> argh, we can include it but then it'll probably not boot with 1000
[17:33] <rsalveti> ogra: yup, just need to use mpurate=${mpurate}
[17:33] <rsalveti> and you'll get the value from u-boot
[17:33] <rsalveti> with that I'm getting 720 at my C4
[17:33] <ogra> hmm, could somone try with XM?
[17:34] <rsalveti> sure, a sec
[17:34] <ogra> i clearly saw probs with 1000 here
[17:34] <davidm> ogra, rsalveti is the issue some boards currently can't boot but with the single change mpurate=${mpurate} all boards will boot?
[17:35] <ogra> davidm, not sure yet, as we stand atm we can only boot XM reliably and Cx with luck
[17:35] <rsalveti> with current setup we may have problems with old beagles, like beagle a/b and c
[17:35] <rsalveti> but it should work better for xM
[17:35] <rsalveti> using mpurate=${mpurate} will fix for beagle a/b/c but will also set 1000 for xM
[17:35] <rsalveti> and it seems our kernel doesn't support it
[17:35] <rsalveti> testing right now
[17:35] <ogra> davidm, dropping the aparm completely will drop XMs to 600MHz but make Cx and Bx work
[17:36] <ogra> davidm, setting mpurate=${mpurate} will set a value that didnt work on XM during my tsets
[17:36] <phh> you have no control on bootloader's config file ?
[17:36] <ogra> phh, we have a release on thu ...
[17:37] <rsalveti> ogra: I prefer doing a respin without any mpurate, putting on the release notes how to use the mpurate from u-boot while we try to fix the kernel bug at the xM
[17:37] <ogra> the archive is frozen ... uploads and respins of images cost a lot
[17:37] <GrueMaster> Just rebooted with mpurate=${mpurate} on my XM.  Logging in now.
[17:37] <phh> ogra: ah
[17:37] <phh> ogra: the way i've seen is changing boot script, if beagleboardxm then mpurate=600
[17:37] <ogra> GrueMaster, check dmesg :)
[17:37] <GrueMaster> Failed to set it.
[17:37] <ogra> phh, not that easy, but yeah. thats the proper fix
[17:38] <ogra> GrueMaster, yeah., thats what i had too
[17:38] <phh> no the proper fix is to fix your kernel ;)
[17:38] <rsalveti> ogra: yup, failed to set it
[17:38] <rsalveti> [    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/332/600 MHz
[17:38] <rsalveti> but that's fine!
[17:38] <rsalveti> once the kernel is fixed it'll work
[17:38] <rsalveti> and the kernel fix can be an SRU
[17:38] <ogra> no, thats to slow to use netbook
[17:38] <GrueMaster> Along with the DVI EDID code.
[17:38] <rsalveti> well, we don't have other choices
[17:38] <ogra> we do
[17:39] <ogra> go with GrueMaster's suggestion and dont do a respin
[17:39] <GrueMaster> The other choice is to document.
[17:39] <ogra> right
[17:39] <rsalveti> but that will break on older beagles
[17:39] <GrueMaster> It is easy enough to edit the boot.script.
[17:39] <rsalveti> and even after the kernel fix is included, it'll still run with 900 and not 1000
[17:39] <rsalveti> the user would then need to edit again by hand
[17:39] <phh> GrueMaster: easy enough but ubuntu can't do it itself :D
[17:39] <ogra> yes
[17:40] <rsalveti> I don't like this solution, but not my call
[17:40] <GrueMaster> phh: We have a wiki documenting how to change it.
[17:40] <davidm> OK let me get a complete picture,this is beagle only
[17:40] <ogra> phh, thats rather a safety thing ... we could but we usually dont touch boot stuff after installation
[17:40] <rsalveti> davidm: yes
[17:40] <rsalveti> davidm: with mpurate=900 (current setup) we may break old beagles, like beagle a/b/c
[17:40] <davidm> if we do nothing at this point early beagles won't boot but current beagle  anb beagle xm will work?
[17:40] <rsalveti> but have xM working with 900mhz
[17:41] <ogra> davidm, current = XM, but yes
[17:41] <davidm> How hard is iti to mount the image and add something to make it work from release notes?
[17:41] <GrueMaster> davidm: beagle C4 is hit or miss.  XM works.
[17:41] <rsalveti> with mpurate=${mpurate} we'll have the best mhz available for beagle a/b/c, but xM will behave with 600mhz
[17:41] <rsalveti> because it fails to set 1000
[17:41] <ogra> davidm, as GrueMaster said, not hard
[17:41] <phh> GrueMaster: if it boots on C4 you might damage it no,
[17:41] <phh> ?
[17:41] <ogra> davidm, but our screwup is permanent as rsalveti says
[17:41] <rsalveti> GrueMaster: and probably always miss with B or A
[17:42] <rsalveti> as it can do at most 600
[17:42] <rsalveti> 900 is too high
[17:42] <davidm> What is the process for the community?  Can  it be made the default sothey don't have to edit u-boot each boot?
[17:42] <rsalveti> let u-boot to decide
[17:42] <ogra> davidm, while mpurate=${mpurate}  could fix the issue through a kernel and bootloader update
[17:42] <rsalveti> that's why mpurate=${mpurate}
[17:42] <davidm> Whoops, we might damage boards with the current setting?  That is different
[17:42] <rsalveti> the mpurate is a variable that's set by u-boot
[17:42] <rsalveti> davidm: yeah
[17:42] <rsalveti> it's overclock
[17:42] <ogra> davidm, we dont damage them but we will shorten their lifecycle
[17:43] <phh> there is a dynamic voltage thing ?
[17:43] <rsalveti> I don't mind having xM running with 600mhz until the first kernel upgrade
[17:43] <davidm> can this be fixed with an SRU post release?
[17:44] <ogra> davidm, no, because we dont re-write boot.scr
[17:44] <GrueMaster> davidm: If we respin with  mpurate=${mpurate}, then XM can go full speed with a kernel SRU.
[17:44] <rsalveti> that's why I believe we should release with  mpurate=${mpurate}, even with xM running only at 600mhz
[17:44] <ogra> mpurate=${mpurate}  could be fixed by a bootloader and kernel update
[17:44] <davidm> to me shortening the life of a board is damage
[17:44] <rsalveti> the kernel fix can go with SRU
[17:44] <ogra> davidm, we'Re the only distro running the XM at 600MHz afaik
[17:44] <rsalveti> then at the first kernel update the user will have his xM running with 1000
[17:44] <rsalveti> even better than 900
[17:45] <rsalveti> well, it's a bug
[17:45] <ogra> yes
[17:45] <rsalveti> and we'll be the only distro that the image doesn't even boot on older beagles :-(
[17:45] <rsalveti> even now that we have the headless option
[17:45] <davidm> so fewer people are effected if we switch to mpurate=${mpurate}, and there is no chance of damage to any boards?
[17:45] <rsalveti> more and more people will try installing ubuntu on older beagles
[17:46] <rsalveti> davidm: yes
[17:46] <GrueMaster> On one side, we release note (similar to BeagleXM DVI issue with maverick requiring user intervention before booting), on the other, we respin and SRU.
[17:46] <davidm> OK I'm going to talk to pgraner and skaet
[17:46]  * ogra just pinged cjwatson 
[17:46] <ogra> to see if we can respin only omap3
[17:47] <ogra> which i think we cant
[17:47] <ogra> which in turn means re-testing *all* images
[17:47] <GrueMaster> which is why I vote no, but that's just me.
[17:48] <ogra> we can respin just omap3
[17:48] <rsalveti> just omap3 seems fine
[17:48] <rsalveti> I think this is our best option
[17:48] <davidm> Why is this just being found now?
[17:48] <GrueMaster> Because all of my systems work fine as is.
[17:49] <ogra> same here
[17:49] <rsalveti> because I decided to try an older beagle here, to do another work, not related with testing, and boom
[17:49] <ogra> and we discussed the setting a while ago with the conclusion that it wouldnt do harm
[17:49] <rsalveti> didn't boot
[17:49] <ogra> i had it on my TODO list from end of maverick still
[17:50] <GrueMaster> ogra: Will this require a jasper fix?
[17:50] <ogra> GrueMaster, no, jasper doesnt touch the cmdline (only preseeding options and root= are parsed)
[17:50] <GrueMaster> ok
[17:51] <ogra> jasper could carry a board specific fix (looking for cpu revision)  but apparently we dont need that  with ricardos solution
[17:51] <GrueMaster> I'm going to test here with a fresh image to make sure it gets passed through anyways.
[17:52] <ogra> the sound thing really annoys me :(
[17:52] <ogra> having put in weeks of work over two releases and still not having it working proper is depressing :(
[17:53] <rsalveti> yeah, the sound issue doesn't help
[17:56] <GrueMaster> Well, we still don't have sound on omap3 either, and this fix won't even help it even if I were able to get working ucm scripts for omap3.
[17:57] <ogra_> who cares about omap3 (as long as we dont break the HW)
[17:59] <rsalveti> sound is kind of a minor bug, annoying but not critical
[17:59] <davidm> how long does it take to resping OMAP 3
[17:59] <GrueMaster> All I am saying is that omap3 audio and omap4 audio are pretty much at the same state at this point.  kernel-side they both work.
[17:59]  * NCommander is alive now and reading backscroll
[17:59] <ogra_> davidm, 90min for netbook, about 30 for headless
[18:00] <GrueMaster> retesting is minimal as the changes are small.
[18:00] <ogra_> indeed, its just a boot option
[18:00] <ogra_> if it boots everywhere we're fine
[18:00] <rsalveti> yup
[18:00] <phh> ah release is in two days
[18:00] <phh> no need to hurry
[18:00] <ogra_> thats what i said above, yeah :)
[18:00] <rsalveti> will have a look for the xM kernel fix
[18:00] <GrueMaster> The headache is the respin/post/download process.
[18:01] <ogra_> rsalveti, ask koen, i think he wrote it
[18:01] <rsalveti> should probably be at l-o already, just need to find the patch
[18:02] <GrueMaster> The question is if we do a respin, do we try to get other fixes in as well?  The ubiquity slideshow issue would affect all platforms (even though they already work).
[18:03] <davidm> OK call made
[18:03] <GrueMaster> Possibly the same with audio.
[18:03] <davidm> please fix package upload we are going to resping
[18:03] <ogra_> no package
[18:03] <ogra_> :)
[18:03] <ogra_> its a one line buildsystem change
[18:03] <davidm> rsalveti, ogra OK make change and let colin and skaet know its done
[18:04] <ogra_> on it already
[18:04] <rsalveti> davidm: cool
[18:05] <skaet> davidm,  which is the version of u-boot we are keeping an eye on?
[18:05] <davidm> skaet, it's not even a package change it's a build system change
[18:05] <davidm> no archive change needed
[18:06] <davidm> one line change to  adding mpurate=${mpurate}
[18:06] <cjwatson> where's that?
[18:06] <cjwatson> (sorry, lacking scrollback)
[18:07] <rsalveti> ogra: should know where to change
[18:07] <cjwatson> ogra should but I want to know for planning purposes
[18:07] <davidm> ogra, rsalveti please explain where change is going to cjwatson
[18:07] <cjwatson> is this in post-boot-natty-armel+omap?
[18:08] <davidm> GrueMaster, no changes except this boot fix change NONE
[18:08] <GrueMaster> davidm: Understood.  Testing fix here to ensure it doesn't break something else.
[18:10] <cjwatson> ok, so it's just in debian-cd on antimony - so ogra can commit that, we can deploy it on antimony, and then we don't even need to rebuild the livefs
[18:10] <cjwatson> so it's actually a really quick rebuild
[18:10] <cjwatson> headless or netbook or both?
[18:10] <rsalveti> both
[18:10] <cjwatson> which subarch?
[18:11] <ogra_> cjwatson, oh, you are here
[18:11]  * ogra_ ignored the channel
[18:11] <apw> davidm, i think i heard there would be a kernel change needed after for performance on some cards ... whats the bug number, and do we already have the patch
[18:11] <ogra_> cjwatson, fis is already in debian-cd in the tools/boot/natty/post-boot-armel+omap script
[18:11] <ogra_> *fix
[18:12] <rsalveti> apw: I'm looking for the patch right now
[18:12] <rsalveti> will also report the bug soon
[18:12] <davidm> cjwatson, thanks
[18:13] <davidm> apw, rsalveti has point and will get info into bug and to you on this one
[18:16] <apw> rsalveti, can you sub me to the bug, and drop the number in privmsg
[18:16] <rsalveti> apw: sure
[18:17] <apw> rsalveti, cool, so i can make sure any change is in the earliest sru
[18:20] <cjwatson> I'm just waiting for existing builds to complete
[18:20] <cjwatson> shouldn't be too long
[18:25] <rsalveti> apw: ogra: davidm: got the patch, will try it and open the bug when I'm sure it works
[18:26] <ogra_> yeah, no hurry
[18:26] <ogra_> updating the bootloaders is complex anyway
[18:26] <ogra_> well, not complex, but requires manual cmdline action
[18:27] <rsalveti> ok, out for lunch while the kernel is building
[18:29] <cjwatson> headless/netbook omap3 rebuilding
[18:30] <ogra_> thx
[18:57] <GrueMaster> ogra: Not sure that it matters, but if we have mpurate=${mpurate} in the initial boot.scr, jasper will only use the u-boot translated value for subsequent boots (i.e. mpurate=1000 on my XM after oem-config runs).
[18:58] <ogra_> GrueMaster, hmm, right, that needs a note (and an oneiric bug i guess)
[18:58] <GrueMaster> This should be release noted in case someone wants to use the same SD for beagle C4 (or earlier) & XM.
[18:59] <ogra_> yep
[18:59] <ogra_> and jasper needs special casing for that var
[19:01] <GrueMaster> Another issue for Oneiric:  wifi in omap4 headless.  Not sure what to file a bug against, but we need wireless-tools and possibly some other package for this to work ootb.
[19:02] <cjwatson> ubuntu headless omap3 posted
[19:02] <GrueMaster> cjwatson: Thanks.
[19:02] <ogra_> awesome !
[19:58] <GrueMaster> ogra_: Will the omap3 image build change also affect kubuntu-[desktop|mobile]?  If so, they also need to be respun.
[19:59] <ogra_> bah, sigh, indeed
[20:16] <GrueMaster> omap3 headless retested on beagle.  XM is finishing install.  Looks good.
[20:17] <ogra_> great
[20:23] <GrueMaster> I updated bug 746023 as the udev rule is still failing.  I'm looking into how to fix it completely now.
[20:23] <ubot2> Launchpad bug 746023 in alsa-utils "No sound on omap4" [High,In progress] https://launchpad.net/bugs/746023
[20:24] <ogra_> i fear we need to call alsaucm once from the alsa-utils postinst
[20:25] <GrueMaster> Shouldn't need to.
[20:25] <ericb2> do you need testers  ?
[20:25] <ogra_> with UCM you need to init the default verbs you want once
[20:25] <GrueMaster> ericb2: do you have a pandaboard?
[20:25] <ericb2> GrueMaster: no, sorry. only an xM
[20:26] <ericb2> GrueMaster: I think I'll buy one soon, but I think I'll have to wait some weeks anyway
[20:26] <GrueMaster> ericb2: If you can come up with a ucm config for XM, great.  We can add it to natty-updates.
[20:26] <ericb2> GrueMaster: sorry, what means ucm ?
[20:27] <ericb2> GrueMaster: I'm not native speaker, and sometimes I need more explanations, sorru
[20:27] <GrueMaster> ogra_: calling alsaucm the way we do in the current udev rule looks right, but needed a path.  Now we just need to figure out how to fire it.
[20:27] <ericb2> sorry
[20:27] <GrueMaster> ericb2: ucm == Use Case Manager, part of the recent alsa release.
[20:27] <ericb2> GrueMaster: ah, ok. no problem for me to make some tests
[20:28] <ogra_> GrueMaster, well, when i tested that was a few kernels ago, not sure the device name udev sees is still the same
[20:29] <ogra_> though rsalveti's lost looked like the rule fired just fine
[20:29] <GrueMaster> ogra_: run "sudo udevadm test /class/sound/card0" and it will show you.
[20:29] <ogra_> s/lost/logs/
[20:29] <ericb2> GrueMaster: what is the process ?
[20:29] <rsalveti> ogra: GrueMaster: it worked when I fired the udev events again
[20:30] <GrueMaster> Well, I updated the alsa-ucm.rules to have the proper path prior to starting a fresh image and it still failed.
[20:30] <rsalveti> and I could also see it at the logs
[20:30] <rsalveti> just didn't check yet if that's also happening during boot
[20:30] <ogra_> rsalveti, yeah, it didnt fire automatically here though
[20:30] <rsalveti> need to find a way to debug udev
[20:30] <GrueMaster> I'll try some more things here.
[20:30] <rsalveti> see why it's not calling the rule
[20:30] <GrueMaster> udevadm has a lot of debug capabilities.
[20:31] <rsalveti> I know, I just want to trace the events that udev gets while booting
[20:31] <ogra_> rsalveti, hmm, try to remove the conditions at the top and bottom and only leave the ID lines in place
[20:31] <rsalveti> when I trigger them by hand it works
[20:31] <ogra_> might be they prevent execution somehow
[20:32] <GrueMaster> udevadm info --attribute-walk --name=/dev/snd/by-path/platform-soc-audio.0 will tell you.
[20:35] <GrueMaster> at any rate, I need lunch.  biab.
[20:49] <rsalveti> ogra: put "exec udevd --daemon --debug >> /var/run/udev.log 2>&1" at your /etc/init/udev.conf
[20:49] <rsalveti> it should give you all events
[20:49] <rsalveti> and here it's still running the alsaucm just fine
[20:51] <ogra_> how do you get back to a virgin state ? or do you test it with a fresh image every time ?
[20:52] <rsalveti> ogra: I'm currently just checking if the udev rule is being called
[20:52] <rsalveti> and it should be called on everyboot
[20:52] <ogra_> hmm
[20:52] <ogra_> yes
[20:52] <rsalveti> as it doesn't depend on the alsaucm state
[20:52] <ogra_> every time an SDP4430 device shows up in the sound stack it should be called
[20:53] <ogra_> but that doesnt happen for tobin  or me
[20:54] <rsalveti> ogra: ok, at this boot I'm getting only the hdmi output
[20:54] <rsalveti> even after calling alsaucm by hand
[20:54] <ogra_> killall pulseaudio
[20:54] <ogra_> and re-open the prefs
[20:54] <ogra_> pulse doesnt update properly apparently
[20:55] <rsalveti> yup, it's there now
[20:55] <rsalveti> let me reboot
[20:56] <rsalveti> maybe a racing condition?
[20:56] <ogra_> hmm
[20:56] <ogra_> i think the SDP4430 is builtin, the trigger should happen very early
[21:07] <rsalveti> ogra_: now it's working all the time =\
[21:08] <rsalveti> it was working before, stopped working and now it got back to work after I called alsaucm by hand
[21:08] <ogra_> you run from SD, right ?
[21:08] <rsalveti> and restarted pulseaudio
[21:08] <rsalveti> yes
[21:08] <ogra_> not from USB disk :)
[21:08] <rsalveti> I have one with usb disk and another with sd :-)
[21:08] <ogra_> you only need the alsaucm call once
[21:09] <ogra_> we dont need it on every boot
[21:09] <rsalveti> what happens after you call it?
[21:09] <rsalveti> can we restore the state to where it was before calling it?
[21:09] <ogra_> its is the same f*cking problem we had last release
[21:09] <rsalveti> let me strace it
[21:09] <ogra_> i dont know, i guess removing the upstart job that stores state and removing the state file might help
[21:10] <ogra_> if you called alsaucm and alsa stores the state it will restore that state so you get working sound all the time
[21:10] <ogra_> i have that here
[21:10] <rsalveti> yeah, I tried removing the alsa state file but still worked
[21:11] <ogra_> the alsaucm call should actually not come from a udev rule
[21:11] <rsalveti> even after a cold reboot
[21:11] <ogra_> well, did you remove the upstart job too ?
[21:11] <rsalveti> yeah, makes sense
[21:11] <rsalveti> not yet, thought that would be part of the package
[21:11] <ogra_> or only the state file
[21:11] <rsalveti> and not something generated while calling the command
[21:11] <rsalveti> let me check
[21:11] <ogra_> sure it is, but it will store your state in any case
[21:13] <rsalveti> ok, alsa-store is not going to be called anymore
[21:13] <rsalveti> and removed /var/lib/alsa/asound.state
[21:13] <ogra_> k
[21:13] <ogra_> so reboot :)
[21:14] <rsalveti> alsaucm is just loading the configuration from /usr
[21:14] <rsalveti> not writing anything
[21:14] <rsalveti> so this state file should be all
[21:14] <ogra_> yep
[21:16] <rsalveti> ok, rebooted, with the working udev rule, without alsa.state file
[21:16] <rsalveti> and sound is working
[21:16] <ogra_> now remove the udev rule and reboot :)
[21:16] <ogra_> to see if its really gone
[21:17] <rsalveti> yup, doing that right now
[21:17] <ogra_> the prob with the udev rule is that it will always set to hifi on boot, regardless what use case you selected
[21:18] <rsalveti> got it
[21:19] <rsalveti> ogra: ok, finally, [   28.309753] asoc: no valid backend routes for PCM: SDP4430 Media
[21:19] <ogra_> yeah
[21:19] <rsalveti> so the udev rules was actually working just fine
[21:19] <ogra_> weird that it didnt for GrueMaster and me
[21:19] <rsalveti> why the hell it didn't work for you neither GrueMaster once you fixed the udev rule?
[21:19] <rsalveti> yeah
[21:19] <ogra_> hmm
[21:19] <rsalveti> even after removing the state file?
[21:19] <ogra_> probably a different race :)
[21:20] <rsalveti> ok, trying again, without the rule and saving the broken state file
[21:20] <ogra_> i.e. the state file with the non working state gets loaded *after* the udev rule fires
[21:20] <ogra_> that would revert the udev changes
[21:20] <rsalveti> yup, that seems to be possible
[21:22] <ogra_> the only real fix is to call the commands from the rules brefore the first stae file is created
[21:22] <ogra_> for oneric i would solve that in jasper
[21:23] <ogra_> sadly thats not possible for natty
[21:23] <ogra_> not sure how we can actually solve it reliably for natty ... as i said, same prob as in maverick
[21:23] <rsalveti> yeah, we should put the correct files and remove old state file
[21:23] <rsalveti> otherwise this is not going to work
[21:24] <rsalveti> if we remove the state file it should always work
[21:24] <rsalveti> let me know fix the udev rule with the broken state file to see if I can get the race
[21:24] <ogra_> right, we would need to remove the state  file from the postinst, call alsaucm ... and for safety, create the new statefile too
[21:24] <rsalveti> *now
[21:25] <rsalveti> yeah
[21:25] <rsalveti> true, if we don't create a new one once the user reboots the old state will go to the file
[21:25] <ogra_> another super ugly hack in alsa postinst script :(
[21:25] <rsalveti> weeeee :-)
[21:25] <ogra_> this is depressing
[21:26] <rsalveti> yeah =\
[21:26] <rsalveti> ogra: and we should also fix the alsaucm path, that's not yet fixed
[21:27] <ogra_> the path ?
[21:27] <ogra_> if we remove the rule ?
[21:27] <ogra_> the SRU should remove it and just call the above postinst stuff
[21:30] <rsalveti> yeah, right
[21:30] <rsalveti> once the state file is there it should be fine
[21:31] <rsalveti> the only problem is that the user end up removing the state file it'll never be right again
[21:31] <rsalveti> *if the user
[21:31] <rsalveti> as you're setting up the state file at postinst
[21:31] <rsalveti> so I believe we should still keep the udev rule
[21:31] <rsalveti> as it's called before restoring the alsa-state, it should be fine
[21:32] <rsalveti> unless the racing condition is really happening
[21:32] <rsalveti> then it can be annoying for the user
[21:32] <ogra_> right
[21:32] <rsalveti> ok, confirmed that with the proper udev rule and with the wrong state file it fails
[21:32] <ogra_> \o/
[21:33] <rsalveti> let me reboot a couple of times to see if I can see the racing condition
[21:34] <rsalveti> failed again
[21:34] <rsalveti> one more time
[21:35] <rsalveti> failed again
[21:35] <rsalveti> last time
[21:37] <rsalveti> ogra_: ok, 4 times and it always failed
[21:37] <rsalveti> let me now remove the state file
[21:38] <ogra_> sounds good
[21:40] <rsalveti> ogra_: yup, worked like a charm
[21:41] <ogra_> awesome
[21:41] <rsalveti> ogra_: let me know once you have the debdiff, I can help you testing
[21:42] <ogra_> k, wont do that tonight anymore though (nearly 11pm here, i need some rest)
[21:42] <rsalveti> ogra_: haha, true :-)
[21:42] <rsalveti> let me comment this at the bug report
[21:42] <ogra_> thx
[21:51] <rsalveti> ok, this should finally solve the sound issue
[21:51] <ogra_> heh ... dejavu
[21:51] <rsalveti> :P
[21:52] <ogra_> :)
[22:26] <GrueMaster> back
[22:58] <ericb2> GrueMaster: booting
[22:58] <ericb2> GrueMaster: "checking filesystem before resizing ..."
[23:04] <GrueMaster> yep
[23:04] <ericb2> GrueMaster: what is the default root password ?
[23:04] <GrueMaster> ???
[23:04] <GrueMaster> It should boot into oem-config.
[23:05] <GrueMaster> There is no password.
[23:05] <ericb2> GrueMaster: indeed. I just did CTRL +ALT + Fn  :)
[23:05] <GrueMaster> Ah.  Don't do that.  :P
[23:06] <ericb2> GrueMaster: got the install in french. Nice :)
[23:08] <ericb2> GrueMaster: there is something strange with the windows size:  too little, or the fonts too big ..choose one
[23:09] <ericb2> GrueMaster: I meant the "System configuration window" after, the TZ and the user name
[23:09] <GrueMaster> What type of monitor do you have?  The default resolution is 1280x720 in the image.
[23:10] <rsalveti> argh, pyside doesn't fail when building at my panda
[23:10] <ericb2> GrueMaster: maybe 1400 x ...  not sure, but for sure > 1280 x720
[23:10] <GrueMaster> It looks wonky on a widescreen that is capable of higher resolutions.
[23:10] <ericb2> GrueMaster: this monitor is able to display higher resolutions, indeed
[23:12] <ericb2> GrueMaster: got mpurate=1000, but 600MHz in the dmesg
[23:12] <GrueMaster> Yes, that will be fixed with the next kernel update after release.
[23:13] <GrueMaster> The kernel can't handle mpurate>900 at the moment.
[23:13] <ericb2> clock :  dpll1_ck: unable to set MPU rate to 1000: -22
[23:13] <ericb2> GrueMaster: ok
[23:14] <ericb2> GrueMaster: so recreate a boot.something  + use mpurate=900 should basicaly work ?
[23:14] <GrueMaster> rsalveti is checking on a patch now, should be ready for the first kernel update.
[23:14] <GrueMaster> Yes, you can edit /boot/boot.script then rerun flash-kernel.
[23:14] <ericb2> GrueMaster: great ...  thanks rsalveti  :)
[23:14] <rsalveti> ericb2: mpurate=900 should work for you, I'm just testing the patch that should make it work with 1000
[23:15] <ericb2> GrueMaster: what test case do you need now ?
[23:15] <GrueMaster> rsalveti: Once you have a kernel .deb, care to share?  That way we can get more testers on it.
[23:15] <rcn-ee_at_work> for the xM, 800 was the recommend max for the default voltage, so 900 may or may not work.. ;)
[23:15] <rsalveti> GrueMaster: sure
[23:15] <rsalveti> rcn-ee_at_work: yup
[23:15] <rsalveti> rcn-ee_at_work: is your kernel still using 800 as default?
[23:16] <GrueMaster> ericb2: Start running some apps and see what you can break.  :P
[23:16] <ericb2> I tested 800 with sakoman distro, works fine
[23:16] <rcn-ee_at_work> yeap it is..  i was betting on dvfs entering 2.6.39, but it didn't...
[23:16] <rsalveti> yeah...
[23:17] <rcn-ee_at_work> sounds like it might not for 2.6.40 either now with the arm shakeup.. ;)
[23:20] <ericb2> GrueMaster: I'll test OOo4Kids for OMAP3
[23:20] <ericb2> OOoLight in fact
[23:21] <GrueMaster> Haven't heard of that.  Not really on my radar this week.
[23:27] <rsalveti> ok, found the cause of the pyside ftbfs
[23:32] <GrueMaster> nice.
[23:34] <GrueMaster> rsalveti: Did you get a bug number for the omap mpurate issue?
[23:34] <rsalveti> GrueMaster: nope, not yet
[23:34] <rsalveti> GrueMaster: you can create it if you want, but I'm planning to do this in a few hours
[23:34] <rsalveti> just need to get dinner
[23:35] <GrueMaster> Yea, I'll file in the next few minutes.
[23:35] <GrueMaster> Need it for iso tracker.
[23:35] <rsalveti> GrueMaster: oh, ok
[23:36] <GrueMaster> Don't worry about it.  You can add the patch once it is filed.
[23:37] <GrueMaster> grrr.  Still seeing random oem-config crashes midway through.  Nothing in the logs.
[23:37] <GrueMaster> And it doesn't happen often.
[23:38] <rsalveti> sigh
[23:38] <rsalveti> ok, dinner time
[23:38]  * rsalveti brb
[23:53] <GrueMaster> rsalveti: Bug #771537
[23:53] <ubot2> Launchpad bug 771537 in linux "mpurate=1000 fails on beagleXM" [Medium,In progress] https://launchpad.net/bugs/771537