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