**** BEGIN LOGGING AT Thu Sep 23 02:59:58 2010 Sep 23 03:00:02 cooloney: cool, also think the same Sep 23 03:00:12 so I it seems I finally have a proper answer for the issue :-) Sep 23 03:00:13 thanks Sep 23 03:00:18 will submit the patch Sep 23 03:01:43 rsalveti: cool, man. that's conflict wasted me some time before Sep 23 03:02:08 can imagine, hard to find Sep 23 03:04:20 rsalveti: i still lost in the mem=1G highmem issue Sep 23 03:04:23 rsalveti: no clue for that Sep 23 03:04:35 comradekingu: me neither Sep 23 03:04:38 ouch, sorry Sep 23 03:04:43 cooloney: ^ Sep 23 03:05:58 npitre fixed some highmem issues in the past, maybe he could give us some directions Sep 23 03:06:38 I have a doubt Sep 23 03:06:48 what is the Alsa drivers used on omap? Sep 23 03:07:09 the normal ones that run on my laptop? or the striped down ones? Sep 23 03:08:25 rsalveti: cool. npitre is master. i need to talk with him Sep 23 03:09:12 I'm here btw ;-) Sep 23 03:09:39 although I WOULDN'T QUALIFY MYSELF AS "MASTER" Sep 23 03:10:39 (especially when hitting capslock by mistake) Sep 23 03:11:59 hey Sep 23 03:12:40 npitre: we're currently facing a weird bug with highmem on omap4, if we use 1gb the memory some times gets corrupted Sep 23 03:12:54 and then the system turns unstable Sep 23 03:13:15 we'd like to test upstream, but can't atm as the mmc support is broken Sep 23 03:13:45 rsalveti: what kernel version are you using? Sep 23 03:14:26 npitre: one provided by TI, based on 2.6.35: http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=shortlog;h=refs/heads/for-ubuntu-2.6.35 Sep 23 03:15:12 that's why we'd like to try upstream, to avoid all other patches Sep 23 03:16:34 all the highmem fixes I know about are included in 2.6.35 Sep 23 03:18:08 can you boot it with only one CPU? Sep 23 03:18:54 yep, while looking at 2.6.36 we just noticed one patch that could help: http://lkml.org/lkml/2010/9/7/390 Sep 23 03:19:16 we can, and we tried it already, but still faced the issue Sep 23 03:19:28 the other thing to try out is to use mem=512m vmalloc=1g in the kernel cmdline string Sep 23 03:19:42 with this patch applied things seems to be better, but still breaks Sep 23 03:19:50 hm, ok Sep 23 03:21:54 OK that patch might help if the hardware ends up needing bounce buffers (mine didn't) Sep 23 03:22:02 npitre: hey, man how's going Sep 23 03:23:28 rsalveti: those kernel cmdnline arguments will force 512 mb OF ram ,AND FORCE ALMOST ALL OF IT INTO HIGHMEM, WHICH SHOULD BE A GOOD TEST Sep 23 03:23:44 cooloney: GOOD GOOD Sep 23 03:24:02 npitre and rsalveti, i think we might need some simple testcase to catch this subtle issue Sep 23 03:24:08 arch damn capslock Sep 23 03:24:24 npitre: np, heh Sep 23 03:24:38 npitre: nice, will test it here Sep 23 03:24:40 npitre: ok, i will try that cmdline Sep 23 03:24:46 rsalveti: cool Sep 23 03:24:50 cooloney: currently the best test I have is to try to compile the kernel Sep 23 03:24:58 it breaks in one or two minutes Sep 23 03:25:11 with internal compiler error Sep 23 03:26:24 rsalveti: yeah, i also got that, if i built kernel in a ssh console, i will got Bad Mode oops in my serial console Sep 23 03:26:37 Unhandled abort Sep 23 03:26:50 yep, that's the error Sep 23 03:27:28 right, but this test is quite complex. do you guys know any other highmem test SW? Sep 23 03:28:11 maybe something to stress the memory Sep 23 03:28:22 but it usually takes quite a while before giving any error Sep 23 03:28:57 what if highmem is turned off? does this still fail? Sep 23 03:30:22 when setting mem to 716 (460 + 256) with or without highmem we don't face this issue Sep 23 03:30:34 what is the storage device used? Sep 23 03:30:39 does it use DMA? Sep 23 03:30:42 the hole is a fixed memory region for decode I guess Sep 23 03:30:49 npitre: if we don't use mem=1G, there is no such issue Sep 23 03:30:55 mmc and usb Sep 23 03:31:04 yeah, mmc and usb Sep 23 03:31:17 i tried booting from mmc and rootfs on mmc Sep 23 03:31:29 but built kernel on NFS or USB Sep 23 03:31:42 does it happen if you use only mmc or usb at once? Sep 23 03:31:49 got this compiler error every time when mem=1G Sep 23 03:31:54 yep, I'm using only USB Sep 23 03:32:17 never tested with full mmc, but I believe cooloney tested it already Sep 23 03:32:32 rsalveti: i think npitre is asking whether we can booting and building kernel only on mmc Sep 23 03:32:53 rsalveti: oh, no, i just test build kernel on usb and nfs Sep 23 03:32:59 let me try it Sep 23 03:33:06 need a big mmc card Sep 23 03:33:13 try just on mmc, but I believe people from TI tried it already Sep 23 03:33:18 what I want to know is wether the problem occurs if you use only USB, or only MMC, or only NFS, etc. Sep 23 03:33:36 npitre: ok, i got it Sep 23 03:33:37 ok, got it Sep 23 03:33:57 rsalveti: can we boot from usb? Sep 23 03:33:59 cooloney: do you have a big sd card with you? Sep 23 03:34:05 i don't think so Sep 23 03:34:15 rsalveti: i got one 8G SD card Sep 23 03:34:22 not directly, I just use the mmc to load the kernel from u-boot Sep 23 03:34:37 rsalveti: ok cool Sep 23 03:34:37 my rootfs is in a usb disk Sep 23 03:34:43 then I don't use mmc anymore Sep 23 03:34:48 so could you try that USB only test? Sep 23 03:34:54 i will try mmc only test Sep 23 03:35:19 another thing to test is CONFIG_VMSPLIT_2G Sep 23 03:35:21 cooloney: yep, this is my usual build environment, and I always face this issue when using 1g Sep 23 03:35:59 npitre: good point. Sep 23 03:37:05 rsalveti: ok, let me prepare the 8G SD card Sep 23 03:40:53 another test: just add a flush_dcache_all() at the beginning of dma_cache_maint_page() and see if that makes the issue go away Sep 23 03:41:09 note this is not a fix just a test Sep 23 03:41:44 hm, nice test Sep 23 03:42:01 time to go to bed ... just drop me an email with your findings and I might have another clue Sep 23 03:42:20 npitre, have a nice dream Sep 23 03:42:32 npitre: nice, thanks a lot! Sep 23 03:42:37 we can inception your dream and tell you the result Sep 23 03:42:46 :-) Sep 23 03:42:53 npitre: if you watched the movie inception. Sep 23 03:42:54 heh Sep 23 03:44:09 I'm rather heavy on TumbleOnThatDamnCapsLockKey tonight Sep 23 03:44:25 that's usually a sign that I should go to bed Sep 23 03:44:28 just pull it off, who needs caps lock Sep 23 03:44:37 :-) Sep 23 05:08:30 cooloney: going to bed now, please let me know if you have any success on this highmem testing Sep 23 05:08:42 interested at the flush_dcache_all testing Sep 23 05:08:54 can continue tomorrow Sep 23 05:09:08 Bed? It's only 2am there. Sep 23 05:09:22 Pfft. Sep 23 05:09:29 * rsalveti getting old Sep 23 05:10:52 heh. Sep 23 05:11:21 Old is when you forget where you left your coffee mug, while drinking it. Sep 23 05:11:36 hm, happens all the time with me Sep 23 05:11:40 dammit Sep 23 05:13:24 Yea, but mine is a 20oz silver & black keg. Sep 23 05:17:38 haha :-) Sep 23 05:17:47 well, time to go, see ya Sep 23 05:17:58 Night Sep 23 05:42:46 persia: about? Sep 23 06:06:14 * GrueMaster crawls to bed. Will pick up in the morning. Sep 23 06:11:12 morning Sep 23 06:31:16 GrueMaster, Sorry to have missed you. Sleep well. Sep 23 06:37:02 hi, .. any one knows configuration to control or switch governors ... any sysfs entry ??? Sep 23 06:41:57 avinashhm: cd /sys/devices/system/cpu/cpufreq/ and check there Sep 23 06:43:19 hrw, i am obseving .. it switchs from performance --> ondemand after some time .. during boot ... any script to do this configuration ... Sep 23 06:45:21 i observe the samething isn't there in busybox ... it always stays at performance .. so was curios , is it some script doing this ?? Sep 23 06:46:39 probably yes Sep 23 06:50:40 hrw, thanks ... Sep 23 06:51:47 I would do grep ondemand /etc -r Sep 23 06:52:09 hrw, i will try this .... Sep 23 06:53:49 hrw, .. found bunch of things ... etc/init.d/ondemand ... Sep 23 06:54:55 , ... now i wan't configure similar things for my busybox here .. let me try ... thanks again hrw Sep 23 07:49:23 i am working on an ARM based device and when working on the mozilla web browser i am facing a problem... Sep 23 07:49:44 there are number of scroll bars appearing on the screen... Sep 23 07:49:50 i have taken screen shots of the same... Sep 23 07:50:06 please have a look at them at the following link Sep 23 07:50:09 http://picasaweb.google.co.in/patwardhan.shreerang/ARMBasedMozilla?authkey=Gv1sRgCLeMjMPZha67kAE# Sep 23 07:50:26 Which release of Ubuntu are you running? Sep 23 07:50:29 has anyone of u faced a similar problem? Sep 23 07:52:35 i m using a customized ubuntu Sep 23 07:52:53 Customised from which release? Also, customised how? Sep 23 07:54:21 ubuntu 9.10 Sep 23 07:54:38 by using rootstock Sep 23 07:55:11 I'd recommend trying with 10.04. I think I remember that problem in the past, but I believe it to be solved. Sep 23 07:55:15 9.10? Sep 23 07:55:23 hrw, karmic Sep 23 07:55:24 ShreeRang: which cpu you are using? Sep 23 07:55:40 OMAP 3503 Sep 23 07:55:59 ShreeRang: try 10.04 then Sep 23 07:56:19 ok... Sep 23 07:56:23 dats an option... Sep 23 07:56:35 anything else that i can do? Sep 23 07:57:11 You might try one of the firefox backports from the mozillateam PPAs, but you'd have to compile it locally. Sep 23 07:57:37 * persia wonders if anyone has tried Ubuntu on the Mini6410 Sep 23 07:58:02 persia: 6410 is armv6 - right? Sep 23 07:58:07 fine...il try dat n update... Sep 23 07:58:45 hrw, Is it? My quick search misinformed me then. I'll believe you (and I see 9.10 images of it about) Sep 23 08:11:19 persia: according to samsung datasheet it is arm1176jzf-s Sep 23 08:11:40 so arm11vfp3 Sep 23 08:27:53 So no support. Thanks for double-checking. Sep 23 09:55:40 NCommander, getting along with gconf ? Sep 23 10:18:16 ndec, around ? Sep 23 10:19:21 ogra: yep. Sep 23 10:20:41 ndec, i will soon need a list with binary package names to install from the ppa Sep 23 10:20:59 with the next software-center upload the feature will be fully enabled Sep 23 10:21:15 ogra: argh... Sep 23 10:21:45 ogra: can this be just a meta package, something like ubuntu-omap4? then I can manage my dependencies in this pkg? Sep 23 10:21:50 Yes. Sep 23 10:22:16 persia: is this 'yes' for me? Sep 23 10:22:18 ndec, indeed ... what we need is one postinst snippet that removes the .desktop file in one of your packages Sep 23 10:22:32 but persia is right, easiest will be a metapackage Sep 23 10:22:32 ndec, Yes :) Sep 23 10:22:44 persia: ;-) Sep 23 10:22:54 (and the sprecific postinst bit in there) Sep 23 10:23:04 ogra, Might be easier to remove the .desktop file from the source, rather than adding it and removing it. Sep 23 10:23:28 persia, from the source ? Sep 23 10:23:45 Yep. Sep 23 10:23:47 its not in any package ... Sep 23 10:23:52 and it cant be Sep 23 10:23:55 Then from where does it come? Sep 23 10:24:02 No file shouldn't have a package Sep 23 10:24:13 jasper (or if we ever use live images it would have to come from casper) Sep 23 10:24:21 (yes, there are exceptions, but they are each special for their own, specific, special reasons, and *NONE* of them are .desktop files) Sep 23 10:24:29 Why? Sep 23 10:24:54 app-install-data-tippa would be such a better place to put it ... Sep 23 10:25:06 because it has to be dynamically created during first boot/install time unless we want to have even more subarch specific images Sep 23 10:25:47 No. Just have jasper purge app-install-data-tippa if it's not the right subarch Sep 23 10:25:58 hrm Sep 23 10:26:08 Unowned files are bad. Sep 23 10:26:24 not for such hacks as PPA enablement for specific subarches Sep 23 10:26:36 Yes. Sep 23 10:26:40 they are always bad. Sep 23 10:26:49 hacks are bad, but bad hacks are extra bad. Sep 23 10:26:54 Please avoid extra badness :) Sep 23 10:26:55 i dont really want to jump through all the hoops of paperwork that would involve Sep 23 10:27:06 especially since everything is implemented and works now Sep 23 10:27:23 Please talk about the architecture with me beforehand next time :p Sep 23 10:27:34 Also, please file a bug to fix this already immediately post-maverick :) Sep 23 10:27:39 sure, we can change all that when we rewrite jasper Sep 23 10:27:50 You told me not to do that this cycle back around FF :) Sep 23 10:28:03 ogra: persia: is ubuntu-omap4 a good name? what else would you propose? Sep 23 10:28:03 But yeah, that's an OK time. Sep 23 10:28:04 for now jasper will dynamically create the apturl file for omap3 or 4 Sep 23 10:28:19 ndec, ubuntu-omap4-addons ? Sep 23 10:28:24 ndec, I'd probably use ubuntu-panda-extras Sep 23 10:28:35 i dont think its panda specific Sep 23 10:28:41 ogra, "addons" has a special semantic value, and should be avoided. Sep 23 10:28:43 persia: no, i don't want panda since it works on other OMAP4 platforms too Sep 23 10:28:45 will be for blaze too Sep 23 10:29:01 ndec, If you're *sure* it's going to be good for all omap4, then "ubuntu-omap4-extras" Sep 23 10:29:02 well, then ubuntu-omap4-extras Sep 23 10:29:27 persia, well, for all *existing* omap4 platforms at least :) Sep 23 10:29:41 some of them are restricted by the way... since I have put some debconf to get clickwrap (like sun java)? Sep 23 10:29:58 thats fine Sep 23 10:30:24 ndec, i also need a text for the "eula" (its not really an eula, but it is shown by sw-center if you want to enable the PPA Sep 23 10:30:29 ) Sep 23 10:30:57 well in fact there could be a few bits specific to board. e.g. wlan chip is not the same on panda and blaze. so we could either install both packages, or make different meta packages. I prefer first option. Sep 23 10:31:08 you can try it on todays image to see what i mean Sep 23 10:31:19 (currently it shows some broken html text) Sep 23 10:31:43 * ogra prefers both too Sep 23 10:31:46 ndec, Would it be possible to have one package that does runtime autodetection to make one or the other work, or has parallel auto-enabled configuration? Sep 23 10:31:54 ogra: so it's a welcome message, right? something like ' you are reading to enable an OMAP PPA and enter a whole new world of improved user experience' ;-) Sep 23 10:32:05 Doing it that way will also reduce long-term merge pain. Sep 23 10:32:15 ndec, well, you could also put all eula txts there if you wanted to :) Sep 23 10:32:18 let's have a less marketing-friendly message there :p Sep 23 10:32:36 ndec, but that would duplicate the eula stuff i guess Sep 23 10:32:46 especially because EULA are different for our various packages, we don't have 1 EULA overall Sep 23 10:32:55 since they are required to be in the packages too (a user can always enable the ppa without sw-center) Sep 23 10:33:41 ndec, yeah, you could put all of them in ... would be ugly but be possible ... though as i said you will need them in the packages too because you can always manually switch the PPA on on cmdline Sep 23 10:33:50 persia: ideally I should be able to install ti-wlan-127x (panda) and ti-wlan-128x (blaze) package. and have the same root FS work on both. is that okay? Sep 23 10:33:59 so a 2welcome text" would likely be best Sep 23 10:34:37 >The Ubuntu 10.10 TI OMAP4 channel contains applications that are made Sep 23 10:34:37 available for Ubuntu by TI to improve the user experience and hardware Sep 23 10:34:37 support on OMAP4 hardware Sep 23 10:34:41 thats the current text Sep 23 10:34:59 ogra: yes a user can install packages without using the desktop icon... that's an argument against removing the icon in the ubuntu-omap4-extra, no? Sep 23 10:35:07 (i just made that up quickly to have some placeholder text) Sep 23 10:35:30 so, now we need to translate the message too ;-) Sep 23 10:35:31 ndec, no, the icon should be removed as soon as the meta is installed Sep 23 10:35:42 shriek ! Sep 23 10:35:49 i didnt think of translations ! Sep 23 10:35:54 sigh Sep 23 10:36:32 ogra: can you make the initial ubuntu-omap4-extras package with the postinst and push it in PPA? I will push updates when we are ready. Sep 23 10:36:37 Well, we can hit three languages quick-like: the rest will be slower. Sep 23 10:36:56 ogra: i don't care about translation! Sep 23 10:36:58 persia, my prob is that i in no case want to add gettext to jasper Sep 23 10:37:11 that will massively bloat it Sep 23 10:37:49 * persia mumbles about architectural integrity and pretends everyone reads English for the next few months Sep 23 10:38:24 well, lets call it a wart we will carry in maverick and do better in natty Sep 23 10:38:35 persia: I think the website where one can order pandaboard will be in english... so we can assume that if someone buys a panda, he understands english ;-) Sep 23 10:38:44 When we ignore all prior work and write jasper correctly :) Sep 23 10:39:02 I promise I won't be out-of-touch for 10-12 weeks in a row for the next cycle :) Sep 23 10:39:03 well, then we wont have the PPA stuff in it anymore anyway Sep 23 10:39:24 we should switch to packages as you said above Sep 23 10:39:32 and they can then easily be gettextized Sep 23 10:39:43 * persia goes off to do less computationally intensive things Sep 23 10:40:22 my prob in maverik is that the cool sw-center stuff only came late ... i threw away all the hacky oemä-config stuff i had done for PPA enablement just last week Sep 23 10:40:38 in favor of the new apturl feature Sep 23 10:42:17 ndec, what about the discussed split for single features (-omap4-wireless, -omap4-graphics ... etc) should we use these as deps in the toplevel metapackage ? Sep 23 10:42:32 or was that for a different PPA anyway ? Sep 23 10:42:49 (i mean the stuff chris wanted) Sep 23 11:17:54 rsalveti, I have wired networking! :) Sep 23 11:18:38 now for wireless, I only need to install libertas-firmware? Sep 23 11:20:35 except... I can't find it. I find it in apt-cache on my laptop, but not on the igep board. Sep 23 11:21:41 oh, it's in multiverse. Sep 23 11:38:13 ndec, do you think your lawyers would sue me for that ? http://people.canonical.com/~ogra/ti-ppa.svg Sep 23 11:40:01 (th elogo is from wikipedia) Sep 23 11:40:05 *the logo Sep 23 11:41:05 ogra, Take care: you'd need a license to use the logo. Make ndec upload it :) Sep 23 11:41:23 persia, yeah, he shoudl just use it as team logo :) Sep 23 11:41:33 then i can "officially" pull it from LP Sep 23 11:41:45 Unfortunately, trademark law requires that every case be prosecuted, or the trademark is lost. Sep 23 11:41:54 (at least in some jurisdictions) Sep 23 11:42:34 For example, Bayer is the only company that can sell "Aspirin" in some countries, but in others anyone can sell under that name, because of insufficient defense. Sep 23 11:43:01 yep Sep 23 12:01:08 this is looking good! Everything seems to be working nicely on my igepv2 board now, though there are things I haven't had time to test yet. Sep 23 12:39:25 I have a 16GB memory card which I'm installing on now. The image was written to it at 3MB/s. How long should the first boot take, with resizing partitions, etc? Sep 23 12:41:00 Maybe 10 minutes. Sep 23 12:41:14 But depends on the hardware inside the card as well, really. Sep 23 12:41:27 ok. Does this happen before the welcome screen appears? Sep 23 12:42:21 Yes. Sep 23 12:42:51 Depending on your configuration, you may get text to console, which may end up on serial or display, during the rebuild. Sep 23 12:43:22 it went too quickly for me to notice, apparently. :) Sep 23 12:43:52 That's a good thing :) Sep 23 12:44:21 the difference between those to memory card was rather significant. Using the first one, a normal boot took about 3-4 minutes. Using the other one, it took less than a minute. Sep 23 12:44:49 That's the internal hardware differences. Sep 23 12:45:22 You will probably notice the system feeling "snappier" as well, as you use it, if you run off that SD. Sep 23 12:45:48 looking forward to testing it. :) Sep 23 12:57:07 persia, I'm not sure I'd use the phrase "snappy", but it's far less sluggish. :) Sep 23 12:58:07 makes me want to try using a usb harddisk, just to see how fast it is when the storage isn't such a bottleneck. Sep 23 12:58:09 "snappier" == "less sluggish". Sep 23 12:59:01 hehe, yes, except for the slightly different connotations :) Sep 23 12:59:06 Hi mpoirier Sep 23 12:59:20 lag: hey good morning ! Sep 23 13:00:28 Evening :) Sep 23 13:00:46 How are you progressing with sound? Sep 23 13:01:48 lag: hold on. Sep 23 13:02:24 lag: i spent a lot of time in sdp4430.c and twl6040.c Sep 23 13:02:39 Okay Sep 23 13:02:42 lag: the "dai" (digital audio interface) are key. Sep 23 13:02:54 So what do you plan to do? Sep 23 13:03:04 lag: still unknown. Sep 23 13:03:31 * persia idly notes that the userspace solution turns out not to work with current kernel reporting Sep 23 13:04:09 lag: now that I know how the system works, I'll start looking in other files for a possible solution. Sep 23 13:04:16 persia: How do you mean? Sep 23 13:04:30 * ogra_ac was wondering too Sep 23 13:04:47 lag: twl6040.c was written by TI guys, I'll get in touch with them. Sep 23 13:05:09 lag, berco put together an alsa configuration fragment that would do what running amixer.sh would do, but ALSA isn't even reporting the card type, so there's no way to load the config fragment. Sep 23 13:05:32 lag: ultimately we can do it at the card level, once all the DAIs are registered, but it won't be upstrem'able. Sep 23 13:05:40 We also looked at how pulse's module-udev-detect works, and all the values it pulls from /sys/... end up as "unknown", so it can't assign things. Sep 23 13:06:11 mpoirier, Why won't it be upstreamable? Sep 23 13:06:16 mpoirier: If it's not upstreamable, then it's the wrong way to do it Sep 23 13:06:22 * persia agrees Sep 23 13:07:07 lag: make no mistake, I don't like it. Sep 23 13:07:17 * ogra_ac just notes that the majority of omap4 patches we use isnt upstreamable currently Sep 23 13:07:32 ogra, That's different. Sep 23 13:07:38 how ? Sep 23 13:07:59 we use a hackish un-upstreamable kernel in maverick Sep 23 13:08:09 Ugly! Sep 23 13:08:10 which will be fixed later Sep 23 13:08:30 so i personally would mind a hackish fix in the sound driver Sep 23 13:08:36 *wouldnt Sep 23 13:08:54 mpoirier: What makes you think dai is key? Sep 23 13:08:56 ogra, just hardcoding the DAIs is unlikely to result in anything compatible for both Blaze and panda: reports indicate they require slightly different handling. Sep 23 13:09:03 its still better than hacking around in userspace with weird scripts Sep 23 13:09:18 We *can't* hack around in userspace: we tried that. Sep 23 13:09:33 persia: *if* i hack it, it would be on a board level, not system wide. Sep 23 13:09:35 we obviously can when using the ugly amixer script Sep 23 13:09:35 Mind you, it may be possible to use a less-critical hack in the kernel side to enable userspace hacking, but... Sep 23 13:09:36 ogra_ac: How is it better Sep 23 13:09:38 ? Sep 23 13:09:53 mpoirier, Oh, with the machine drivers? How is that not upstreamable? Sep 23 13:10:04 lag, one change in one place instead of three changes in three places Sep 23 13:10:11 I'd say it was less hacky to do it in user space Sep 23 13:10:20 It's what amixer was designed for Sep 23 13:10:23 ogra, Ah, yeah, the amixer script. That doesn't have sufficient elegance to even be called "hack" in my book. Sep 23 13:10:37 ogra_ac: We only need the script Sep 23 13:10:41 lag, plus the fact that we break all ubuntu policies with it Sep 23 13:10:43 Just to turn the thing up! Sep 23 13:10:46 and packaging Sep 23 13:10:48 lag, No. the scipt is unusable. Sep 23 13:11:10 lag, *if* the kernel reported the card, we could set mixer policy with userspace config. Sep 23 13:11:24 Then that's what we need to do Sep 23 13:11:32 Not hack the volume in userspace Sep 23 13:11:50 Wrong: kernel Sep 23 13:12:01 s/userspace/kernel Sep 23 13:12:17 jo-erlend_nb: nice to know, sent both fixes to the kernel team, let's see when they will get applied Sep 23 13:12:23 Minimal kernel work would mean passing CARDINFO so we can use a userspace hack for ALSA, and passing something in /sys/... so that udev would be able to identify headset, speakers, etc. Sep 23 13:12:51 Better kernel work would be to correctly identify and name the device, and pass the correct naming to userspace policy. Sep 23 13:13:20 main problem right now it a misconnection between front and backend DAIs Sep 23 13:13:24 Best kernel work would be to correctly identify and name the device, and perform correct basic initialisation on the device (turn on the useful amps, turn off the useless ones, etc.) Sep 23 13:13:49 userspace tries to open a stream but can't 'cause kernel returns an error. Sep 23 13:14:10 running the scripts fixes the connection between DAIs, hence returning a proper stream to sink to. Sep 23 13:14:20 The key bit is that with the current design of ALSA (and yes, there are discussions to move more to userspace), the kernel is responsible for identification, initialisation, and initial configuration. Sep 23 13:14:57 persia: mpoirier: I have a kernel change for audio that I need to test Sep 23 13:14:58 Getting the DAIs connected properly (on a per card basis) will fix our problems. Sep 23 13:15:08 Do we have a working example of how it 'should' work? Sep 23 13:15:20 lag, intel HDA i think Sep 23 13:15:21 berco, Excellent! What does it do? Sep 23 13:15:35 Intel HDA is another pile of pain Sep 23 13:15:47 'good example' Sep 23 13:16:08 all other soundcards ? Sep 23 13:16:26 And they work in the same way? Sep 23 13:16:34 I don't know of one. I'd really suggest asking in #alsa-soc Sep 23 13:16:47 Report all relevant information to userspace? Sep 23 13:16:53 ogra, Most soundcards don't use the SoC layer, making them poor examples. Sep 23 13:16:59 Good plan Sep 23 13:17:01 ah, right Sep 23 13:17:03 persia: it adds long name support in soc Sep 23 13:17:17 berco, Cool! Great find. Sep 23 13:17:23 mpoirier, Could you take a look at that? Sep 23 13:17:41 persia: sure but what does "long name support" do ? Sep 23 13:17:55 persia: trying to get a new kernel with that change in place for testing Sep 23 13:17:57 size matters ? Sep 23 13:18:02 even with sound ? Sep 23 13:18:09 Should be reporting of the card name, so that CARDINFO lets us use userspace policy config hacks. Sep 23 13:18:30 berco, mpoirier can probably spin you one fairly quickly, if you can point at the patch. Sep 23 13:18:51 berco: yes, send me the patch and I'll test this. Sep 23 13:19:00 berco: within 30 minutes that is... Sep 23 13:19:21 check how twl4030 does it? Sep 23 13:19:24 mpoirier, The userspace config stuff isn't packaged, so you'll want to come back for instructions on how to test :) Sep 23 13:19:45 most omap3 uses twl4030 but has it connected in zyllion ways Sep 23 13:20:02 hrw, twl4030 reports CARDINFO, sets amps and volumes, and reports the right parameters to udev? Sep 23 13:20:07 hrw, which obviously breaks it on Xm Sep 23 13:20:26 hrw, Ah, yeah, not an ideal example: this is why we don't have working sound on beagle C4/XM Sep 23 13:20:39 (well, it kinda works, sorta, on beagle) Sep 23 13:20:44 i think C4 works Sep 23 13:20:53 persia: no idea. I used few omap3 devices with sound. n900/beagleboard b7+c3/bug2 Sep 23 13:20:55 kinda, sorta, if you don't do anything tricky Sep 23 13:21:20 hrw, Making it seem like it works on any of those is trivial: fiddle with alsamixer for 5 minutes, and never think about it again. Sep 23 13:21:32 hrw: yes, twl4030 was in my list of things to look at today. Sep 23 13:21:32 The trick is having it work perfectly in an autodetected manner on first install. Sep 23 13:21:36 for me "works" = i hear a login sound :P Sep 23 13:21:43 ogra, On first boot. Sep 23 13:21:49 sure Sep 23 13:22:23 GrueMaster was reporting issues with that for both C4 and XM, I thought. I may be misremembering. Sep 23 13:22:28 persia: for me "alsactl restore" with prepared asound.conf is fine Sep 23 13:22:38 hrw, thats so broken Sep 23 13:22:51 "prepared asound.conf" ... Sep 23 13:23:37 ogra_ac: kernel people tends to move more and more to userspace anyway Sep 23 13:24:05 hrw, That means "not working" to me. Sep 23 13:24:43 And moving more to userspace is fine, but it needs to be done right (and that discussion is ongoing in ALSA upstream). Sep 23 13:25:00 Just expecting endusers to magically know how to write a config file isn't acceptable user experience. Sep 23 13:26:35 make alsa-config package which will keep asound.conf-boardname + script which will check /proc/cpuinfo? Sep 23 13:26:49 ugh Sep 23 13:26:57 We have something like that already. Sep 23 13:27:07 It is part of alsa-utils, which you have installed already. Sep 23 13:27:30 But it depends on the kernel reporting *which* card is installed. When the kernel doesn't tell userspace which card is in use, userspace can't do anything at all. Sep 23 13:27:40 mpoirier: I'm attaching that patch to the bug 637947 Sep 23 13:27:41 Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 12)" [High,Confirmed] https://launchpad.net/bugs/637947 Sep 23 13:27:49 What EXACTLY does userspace need from the kernel (do you need from me) Sep 23 13:27:53 And /proc/cpuinfo is exceedingly unlikely to accurately report the audio interface Sep 23 13:27:54 mpoirier: just a min Sep 23 13:27:58 berco: fantastic Sep 23 13:28:09 persia: It must be reported Sep 23 13:28:19 persia: How does ALSA know what to change? Sep 23 13:28:42 berco, Could you expand on what was preventing the custom config from loading? Sep 23 13:30:04 rsalveti, you're confident they'll make it in time for maverick? Sep 23 13:30:42 jo-erlend_nb: not sure for the release, let's see Sep 23 13:30:45 rsalveti, I did a clean install of todays preinstall on a new memory card, using the new kernel so I could see the process on my screen. It still doesn't setup the filesystems properly. Sep 23 13:30:56 if not release, at least as an update Sep 23 13:31:13 hm, what do you get on your screen Sep 23 13:31:14 ? Sep 23 13:31:45 mpoirier: #17 and #18 in the bug 637947 log activity Sep 23 13:31:46 Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "no sound devices on current ES2.0 boards (affects: 1) (heat: 12)" [High,Confirmed] https://launchpad.net/bugs/637947 Sep 23 13:31:56 well, everything works nicely, except the rootfs isn't resized. I don't know if bootfs is cleaned with each reboot yet. I'll know that in a little while. Sep 23 13:32:16 berco: cool, hold on, checking. Sep 23 13:32:48 jo-erlend_nb: ok, would be good to see the messages from the first boot, you should be able to see if it's resizing it or not Sep 23 13:32:53 persia: from my understanding in the /proc/asound/cards we only reported "- SDP4430" instead of something like "OMAP4 - SDP4430" Sep 23 13:33:12 persia: hence, alsa was not looking for any .conf file Sep 23 13:33:26 Aha, so longname should be enough then, right? Sep 23 13:33:55 persia: if you have this omap4 field or whatever, you can just name your .conf file the same as this field i.e OMAP4.conf and it would get loaded by alsa Sep 23 13:33:58 berco: I'll apply and test - this should be very quick. Sep 23 13:34:18 persia: my understanding from the audio guy, is that this fix should be enough, right Sep 23 13:34:28 mpoirier: thanks, let me know Sep 23 13:34:40 rsalveti, it went very quickly. I didn't see anything special. Then the welcome screen appeared. I filled out all the details, and it worked for a while, then it rebooted. Sep 23 13:34:50 berco, If lrg told you that's what it takes, I'm pretty sure it's correct :) Sep 23 13:35:18 mpoirier: I used iwatch to verify my .conf was loaded by alsa. At least we can make sure after this change a .conf file get read and then make this .conf file look good :) Sep 23 13:35:31 the .conf should contain all our amixer settings Sep 23 13:36:21 Right, which then just leaves pulse Sep 23 13:36:26 * persia goes and looks at source again Sep 23 13:36:36 jo-erlend_nb: after booting try searching for /var/log/jasper.log Sep 23 13:38:29 rsalveti, I did see a message that Jasper was being removed. Sep 23 13:38:56 jo-erlend_nb: but the log should still be there at least Sep 23 13:39:37 whats the prob ? Sep 23 13:39:45 rsalveti, let me install an irc client on it, then it's easier to paste. Sep 23 13:39:59 cool Sep 23 13:40:32 it does say it's resizing partitions, at the top of the log file. Sep 23 13:41:01 For pulse, the immediately obvious missing bit is missing values for /sys/class/sound/card.../pcmC.../pcm_class Sep 23 13:41:15 oh. And I have no sound. Sep 23 13:41:55 But to get a real answer, best to have someone with the hardware to load module-udev-detect with debugging on to track down what's missing. Sep 23 13:42:05 jo-erlend_nb: anything else? Sep 23 13:42:16 rsalveti, bluetooth doesn't seem to be recognized. Sep 23 13:42:37 That's concerning. Anything in dmesg at all? Sep 23 13:43:59 rsalveti, but I haven't installed that deb you sent me yet, so perhaps that's causing some problems? I'll do that when I fix the filesystem issues. I have about 50MB free space now. :) Sep 23 13:49:24 jo-erlend_nb: sure, np Sep 23 13:49:38 with default uImage and uInitrd you should be able to run the resize without issues Sep 23 13:50:47 rsalveti, you mean I should just do it manually? Sep 23 13:52:00 rsalveti, http://paste.ubuntu.com/499149/ Sep 23 13:52:04 jo-erlend_nb: no, I mean that I believe it should just work Sep 23 13:52:06 that's the jasper log. Sep 23 13:52:57 aha Sep 23 13:52:58 first issue with jasper, it expects MLO Sep 23 13:53:04 right Sep 23 13:53:33 ogra_ac: hey, I see you committed directly to lp:ubuntu/flash-kernel and not to lp:~ubuntu-core-dev/flash-kernel/ubuntu; do you mind if I completely kill the latter now? Sep 23 13:53:43 and the script is running with set -e Sep 23 13:53:58 so yes, jasper is not running the resize Sep 23 13:54:04 hm, that'd explain Sep 23 13:54:18 ogra_ac: I can help you merge rebase remaining branches based on lp:~ubuntu-core-dev/flash-kernel/ubuntu to lp:ubuntu/flash-kernel if you like Sep 23 13:54:20 lool go ahead i committed there because i dont want two branches Sep 23 13:54:35 just kill the old one Sep 23 13:54:39 rsalveti, can I just do it myself while the board is running? Sep 23 13:55:09 ogra_ac: Done; thanks Sep 23 13:55:12 I mean while rootfs is mounted. Sep 23 13:55:13 i'll do the rebases locally for my personal branches ... if others have probs i'll point them to you though ;) Sep 23 13:55:25 jo-erlend_igep: nops, you need to unmount it first Sep 23 13:55:56 no, resize2fs should be able to do an online resize while mounted Sep 23 13:55:57 it works during boot because of uInitrd, that loads a shell in memory Sep 23 13:56:08 even while mounted? Sep 23 13:56:10 never tried Sep 23 13:56:10 That's ok; it's basically a matter of updating .bzr/branch/branch.conf to point at the new parent, which can be done when pulling or pushing with --remember Sep 23 13:56:16 but yu miss the bits from jasper_growroot that run afterwards Sep 23 13:56:30 lool yeah Sep 23 13:57:05 rsalveti yeah, but the fs needs to be clean Sep 23 13:57:53 it keeps deleting everything on my boot partition. How do I fix that? Sep 23 13:58:42 I'd say that jasper is running on every boot, as you didn't generate another uInitrd Sep 23 13:59:43 sigh ... tegra wlan ... sigh Sep 23 14:00:06 whats the content of your boot partition ? Sep 23 14:00:32 can you pastebin the ls output somewhere Sep 23 14:05:00 I have boot.ini, uImage and uInitrd. Sep 23 14:05:28 create an empty file caled MLO Sep 23 14:05:34 *called Sep 23 14:06:27 are you sure the IGEP2 cant read a boot.scr ? Sep 23 14:06:29 I'm currently resizing the rootfs. I'll try that afterwards. Sep 23 14:06:34 thats tricky to add Sep 23 14:06:38 ogra_ac, seems so. Sep 23 14:19:03 lool, i know you use IGEP2 in linaro, how do you handle the fact that it requires a boot.ini instead of a boot.scr by default ? Sep 23 14:19:18 do you just replace u-boot in NAND ? Sep 23 14:21:18 * ogra cant imagine that flash-kernel every worked in that scenario Sep 23 14:21:21 *ever Sep 23 14:21:27 rsalveti, can you give me the url to that deb you uploaded? I seem to have misplaced it. :) Sep 23 14:21:56 ogra: maybe u-boot upstream uses boot.scr Sep 23 14:22:18 rsalveti, well, i would expect jo-erlend to use the in NAND one Sep 23 14:22:32 and linaro too actually Sep 23 14:22:57 if that requires .ini while its weird, flash-kernel and jasper wont be able to handle that Sep 23 14:23:08 Morning. Sep 23 14:24:15 GrueMaster, morning ... did you have any success with the omap image from yesterday ? Sep 23 14:24:25 (does it still boot with the new u-boot) Sep 23 14:25:01 mpoirier: I was looking at the alsa SOC source yesterday for beagle and had an epiphany. By looking at soc/omap/omap3pandora.c and comparing it to omap3beagle.c, I think I have an idea of how to make it work. Sep 23 14:25:23 ogra: yes, everything works the same (from what I can tel). Sep 23 14:25:31 \o/ Sep 23 14:25:37 awesome Sep 23 14:27:35 back to audio. Pandora is an opensource handheld using similar hardware to beagle. But they actually only enable the pins on the codec that are connected in the system. Beagleboard just maps the entire codec in the dai. Sep 23 14:28:03 I think we can use the pandora as a roadmap to make beagle work properly. Sep 23 14:28:43 No need to look at the twl4030 code, except to get proper channel names for the omap3beagle.c Sep 23 14:28:44 berco: got results for you. Sep 23 14:29:49 berco: 'cat /proc/asound/cards' indeed reports "TI OMAP4 SDP4430 Board" Sep 23 14:31:00 GrueMaster, pandora ? i thought that was still vaporware ... did they ever actually release something ? Sep 23 14:31:19 Yes. They are actually shipping. Sep 23 14:31:32 mpoirier: cool Sep 23 14:31:47 GrueMaster: I'll get back to you. Sep 23 14:31:48 wow Sep 23 14:32:00 berco: we are not out of the woods Sep 23 14:32:02 * ogra remembers them announcing it in 2007 or so Sep 23 14:32:15 mpoirier: is that the only string? Sep 23 14:33:05 berco: hummm... good question. you get a kernel message and a user space returned messages. Sep 23 14:33:08 on the daily image it currently reports SDP4430 too fwiw Sep 23 14:33:19 berco: I'll use a pastebin - hold on. Sep 23 14:33:34 (not TI OMAP4 in front nor Board in the end though) Sep 23 14:34:07 are imap4 boards already available? Sep 23 14:34:09 berco: http://paste.ubuntu.com/499164/ Sep 23 14:34:47 jo-erlend_nb, no Sep 23 14:34:51 but soon Sep 23 14:35:16 mpoirier: looks better. however asoc string should be replaced to something else to my thinking Sep 23 14:36:02 berco: we have a bigger problem - let me explain. Sep 23 14:36:47 I did 3 longs days of soul searching in sdp4030.c and twl6040.c. Know how things get initialized. Sep 23 14:37:37 berco: to about 90 % i'd say. With what you wrote in the scripts, I think you can bridge the last 10% for me. Sep 23 14:38:35 so, when the kernel boots all the DAIs are associated to the SDP4030 card. Sep 23 14:38:49 things stay still until a user log in. Sep 23 14:39:35 when logging in, 'snd_soc_pcm_open' in soc-core.c gets called. Sep 23 14:39:43 this is where things go south... Sep 23 14:40:02 * berco is still listening Sep 23 14:40:45 in there, 'snd_soc_get_backend_dais' is called, which is where I've isolated the problem to. Sep 23 14:41:34 I've enable debugging and get the following output: (let me use a pastebin). Sep 23 14:42:33 berco: http://paste.ubuntu.com/499170/ Sep 23 14:43:13 berco, over and over again, which tells me someone in userspace is trying to get information from the card . Sep 23 14:44:38 berco, when running the scripts DAIs get resolved and the messages go away (I'll use another pastebin). Sep 23 14:44:48 mpoirier: hold on a second please Sep 23 14:44:54 ok Sep 23 14:44:59 jo-erlend_nb: sorry, got distracted: http://people.canonical.com/~rsalveti/kernel/linux-image-2.6.35.4+_2.6.35.4+-43_armel.deb Sep 23 14:45:17 thanks. Sep 23 14:47:25 mpoirier: ok, just explaining my colleague what we discussed so far as he has a better audio background than me :) Sep 23 14:47:37 mpoirier: everything makes sense in your findings Sep 23 14:48:03 berco: That's the 10% i get lost and would welcome help from people in the know. Sep 23 14:48:30 mpoirier: now, our understanding is that you have a string "AsoC - SDP4430" reported by "cat /proc/asound/cards" Sep 23 14:48:48 berco: absolutely Sep 23 14:49:07 berco: hold on actually. Sep 23 14:49:09 mpoirier: and we should write a "/usr/share/alsa/cards/asoc.conf" file that would include all our amixer script settings Sep 23 14:49:41 berco: this is new to me. let me check. Sep 23 14:50:44 berco: let me guess, I should find a "SDP4430.conf " in there ? Sep 23 14:50:49 mpoirier: I did the test on my PC which as an HDA-Intel audio card Sep 23 14:51:22 This HDA-Intel string is reported in /proc/asound/cards on my PC and I can see the HDA-Intel.conf gets read Sep 23 14:51:45 mpoirier: no SDP4430.conf is for me a wrong name Sep 23 14:52:08 mpoirier: the file name should correspond to the first half of the string before the hyphen character Sep 23 14:52:31 mpoirier: "AsoC - SDP4430" Sep 23 14:53:05 mpoirier: I can see in the patch that "AsoC" is the card->snd_card_driver name Sep 23 14:53:24 rsalveti, after I installed libertas-firmware, I can see wireless networks in nm-applet. However, I can't seem to connect to my AP. I'm using wpa2+. Do you know any reason why that wouldn't work? Sep 23 14:53:33 mpoirier: not a good name but for testing it should be enough Sep 23 14:54:25 jo-erlend_nb: hm, don't know, could be a firmware/driver limitation Sep 23 14:54:33 berco: let's go back to http://paste.ubuntu.com/499164/ Sep 23 14:54:35 mpoirier: do you have mean to share the kernel? And can work on the script file if you want Sep 23 14:55:13 mpoirier: ok Sep 23 14:55:32 berco: the first line comes from the kernel. Sep 23 14:55:39 the second is in user space. Sep 23 14:55:42 mpoirier: yes Sep 23 14:56:32 mpoirier: all is kernel. AsoC is a generic framework for audio driver. Probably why they chose that name. Sep 23 14:56:47 berco: if I follow you properly, it's not reading "ASoc" but "TI OMAP4 SDP4430 Board" Sep 23 14:56:51 mpoirier: this driver can manage several sound cards from several companies Sep 23 14:57:07 mpoirier: ? Sep 23 14:57:18 mpoirier: what is reading "TI ... ? Sep 23 14:57:52 berco: brain bug on my side. Sep 23 14:58:22 mpoirier: I think it's alsa in user space which is calling the snd_xxx functions... Sep 23 14:58:31 I was under the impression the content of /proc/asound/cards was "TI OMAP4 SDP4430" only. Sep 23 14:58:50 and 0 [SDP4430 ]: ASoC - SDP4430 was a debug messages coming from the query request. Sep 23 14:58:53 it is not the case. Sep 23 14:59:10 mpoirier: ok :) I see. No everything comes from it Sep 23 14:59:26 berco: let's resume. Sep 23 14:59:51 therefore, we should find ASoC.conf under /usr/share/alsa/cards ? Sep 23 14:59:59 mpoirier: now, I understand why we disconnected :) Sep 23 15:00:13 mpoirier: absolutely Sep 23 15:00:25 mpoirier: that's my understanding Sep 23 15:01:20 berco: I have a feeling this fine should contains settings that are related to my second pastebin. Am I correct ? Sep 23 15:01:29 s/fine/file Sep 23 15:02:51 mpoirier: exactly. This .conf file should contain the amixer settings and that should provide valid audio path to alsa and get rid of your second pastebin error message Sep 23 15:03:18 mpoirier: now, an other funny part is the format of this .conf file :) Sep 23 15:03:58 mpoirier: I need to fix my cross compile environment to build my own kernel and help you with this testing Sep 23 15:04:44 berco: I can accept and test any patches you can give me. Sep 23 15:05:32 berco: my turn around is very quick - everything is setup on my side. Sep 23 15:05:41 ogra: We currently copy the boot.scr into the boot.ini when writing the image Sep 23 15:05:50 berco: it depends on how tedious you think the process will be. Sep 23 15:05:54 lool, but not with flash-kernel Sep 23 15:05:56 mpoirier: thanks a lot for your help. I should be able to get back to you tomorrow Sep 23 15:06:09 i.e. when updating the kernel Sep 23 15:06:31 ogra: I didn't think flash-kernel had to touch it in our case Sep 23 15:06:42 ah Sep 23 15:07:10 well, we use a /boot/boot.script file as input so we regenerate it on every flash-kernel run Sep 23 15:07:21 mpoirier, berco: fwiw, this file + driver patch is still work in progress. Should be a newer fix tomorrow. Sep 23 15:07:23 (since we hide the actual vfat partition) Sep 23 15:08:32 lrg: are you also preparing this .conf file? Sep 23 15:08:55 berco: yes, the audio team is working on this. Sep 23 16:18:24 GrueMaster: I will start looking in omap3-beagle.c and omap3-pandora.c . Sep 23 16:19:53 What I was going to say was that the omap3beagle maps the entire codec in the dai, whereas the omap3pandora only maps the used channels. The omap3evm should map the entire codec as it is an evaluation board. Beagle is not. Sep 23 16:20:38 But if ASOC is heading towards a userspace conf file format, that may be the better solution. Sep 23 16:21:44 I only spent about an hour looking at the code. But we should be able to get a solution fairly quickly. Sep 23 17:31:41 Something happened to the dove image. It no longer has a partition table in today's image. Very odd. Sep 23 17:32:20 ogra, NCommander: ^^^ Sep 23 17:46:04 GrueMaster, a partition table ? Sep 23 17:46:14 in a *dove* image ? Sep 23 17:46:29 Yes. It should have 1 partition, vfat. Sep 23 17:46:41 right but no table Sep 23 17:46:59 If you have a partition, you have a partition table. Sep 23 17:47:14 Otherwise the raw device is one big filessytem. Sep 23 17:47:30 I.e. /dev/sdh vs /dev/sdh1 Sep 23 17:47:54 ogra@antimony:~/branches/debian-cd$ bzr pull Sep 23 17:47:56 No revisions to pull. Sep 23 17:47:58 ... Sep 23 17:48:01 no changes Sep 23 17:48:30 i dont think we ever partitioned dove Sep 23 17:49:21 After running dd if=maverick-netbook-armel+dove.img of=/dev/sdh bs=4M, I should see /dev/sdh1. I do not with todays image. Sep 23 17:49:54 parted -s "$IMAGE" mklabel msdos Sep 23 17:50:02 hmm, we apparently do Sep 23 17:53:14 well, there are no code changes at all Sep 23 17:53:41 GrueMaster, are you 100% sure thats only with todays image ? Sep 23 17:53:59 i.e. yesterdays was for sure ok Sep 23 17:54:22 As soon as I am done flashing today's omap image for my beagle, I will double check yesterdays. Sep 23 17:54:31 k Sep 23 17:54:42 I know for a fact that 20100920 was good. No build on 20100921. Sep 23 17:54:47 i know antimony was upgraded to lucid but thats a few days ago Sep 23 17:55:20 Should have been done earlier in the cycle. Sep 23 17:55:29 yes ... Sep 23 17:55:34 but now its there Sep 23 17:55:53 checking the partitioning code, its identical for omap, omap4 and dove Sep 23 17:56:04 so it cant be a newer parted or some such Sep 23 17:56:04 Gah, flashing images to SD takes forever. Sep 23 17:56:12 yeah :( Sep 23 17:57:03 And if I try to flash to two USB devices at the same time, my Core2Quad becomes quite unstable. Sep 23 17:57:15 Even though they are on separate USB busses. Sep 23 17:57:28 file a bug ... kernel issue Sep 23 17:57:48 or HW Sep 23 17:58:03 No, I think it is hardware related. Wife's computer has the same issue, and she runs that "other" OS. Sep 23 17:58:20 its the CPU ! Sep 23 17:58:26 Pffft. Sep 23 17:58:28 wrong vendor ! Sep 23 18:00:06 I do need to nuke & pave it though. Running i386 install. Should run x86_64. Sep 23 18:12:30 ogra, see ubiquity bug, making real progress on this :] Sep 23 18:13:03 there is an upstart bug that means it won't "stop" an already running thing, so gdm and ubiquity-dm will just fight it out because it will refuse to quit running gdm just because ubiquity is running Sep 23 18:13:23 but, I could connect to wireless from in oem-config GUI and apart from how ugly as sin it is, it worked great until it nuked trying to do a symlink :D Sep 23 18:14:20 Neko_, well, we use iit daily on our images and never hit such bugs Sep 23 18:14:38 i personally also find it quite beautiful Sep 23 18:14:51 Neko_, you are using maverick, right ? Sep 23 18:15:40 yes :) Sep 23 18:15:51 I think part of it is we're using a fat partition for /boot Sep 23 18:16:05 did you ever consider just using the readily produced images ? Sep 23 18:16:07 what are you using for disks on your systems? Sep 23 18:16:11 what readily produced images Sep 23 18:16:23 the dailies we build Sep 23 18:16:31 there are the dailies for dove etc. but they're installers Sep 23 18:16:35 we can't hack in our kernel to those Sep 23 18:17:06 gimme a URL so I can see what you're talking about? :/ Sep 23 18:17:11 Neko_: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/ Sep 23 18:17:14 http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-preinstalled/current/ Sep 23 18:17:39 ugh .img? Sep 23 18:18:06 Neko_, you need to generate the inird with the rootfs on the second partition but beyond that it shouldnt be difficult to add another kernel Sep 23 18:18:19 what's the 16MB of difference between the two, just kernel stuff? Sep 23 18:18:23 (initrd is essential) Sep 23 18:18:30 yes Sep 23 18:18:44 I mean given the choice they're identical in terms of packages Sep 23 18:18:49 and it's UNE right Sep 23 18:18:55 yes Sep 23 18:18:58 right Sep 23 18:19:02 but we don't want UNE. Sep 23 18:19:19 UNE is too touchscreeny and weird Sep 23 18:19:59 * ogra_cmpc uses it on a 24" 1920x1280 screen on omap4 ... i dont find it touchscreeny Sep 23 18:20:11 the scrollbar is backwards like a touchscreen "drag" would be Sep 23 18:20:17 you drag it up and it scrolls down Sep 23 18:20:19 no Sep 23 18:20:30 that was a bug that was fixed long ago Sep 23 18:20:54 have you ever considered that people might just want a normal gnome desktop? ;_; Sep 23 18:21:10 the image ships a normal gnome desktop too Sep 23 18:21:18 It is there as well. You can select it at the gdm login. Sep 23 18:21:27 ... oem-config first though right? :) Sep 23 18:21:36 jasper first Sep 23 18:21:41 then oem-config Sep 23 18:21:47 whats jasper and what is it doing for me Sep 23 18:21:49 then netbook UI Sep 23 18:21:58 it does the initial system setup Sep 23 18:22:18 growing the rootfs to teh full size of the SD ... Sep 23 18:22:29 system setup ... Sep 23 18:22:31 oh fuck that I am going to loop mount the image and make a tarball Sep 23 18:22:37 optimization for SD card Sep 23 18:22:45 the thing is going to be on a 16GB SSD Sep 23 18:22:50 jasper lives in the inird Sep 23 18:22:58 which we don't have :D so... good Sep 23 18:23:03 (thats why i said initrd is essential on these images) Sep 23 18:23:25 well, its easy to roll one Sep 23 18:23:38 you'd think.. Sep 23 18:23:57 install your kernel package in the rootfs and just run update-initramfs Sep 23 18:24:04 we don't haaave a kernel package Sep 23 18:24:05 tr8ivial Sep 23 18:24:10 ugh Sep 23 18:24:21 for some reason the kernel stuff is all reliant on some weirdo 2.6.33+ stuff Sep 23 18:24:22 how do you apply security updates ? Sep 23 18:24:33 oh Sep 23 18:24:36 markos is having trouble getting our 2.6.31 to build using the correct packaging Sep 23 18:24:43 well, then i see why you have upstart probs Sep 23 18:24:48 ogra_cmpc: Issue with today's omap4 image. Running oem-config, something has used up my entire 7.2G of root partition. May be related to encrypted home dir. Sep 23 18:24:53 oh no, do not blame this on the kernel:D Sep 23 18:25:04 upstart has absolutely no reliance on any feature of the kernel in that manner Sep 23 18:25:13 Neko_, upstart relies on a 2.6.35 kernel Sep 23 18:25:17 in what way Sep 23 18:25:29 ask Keybuk in #ubuntu-devel Sep 23 18:25:48 upstart and udev in ubuntu are always tied to the kernel Sep 23 18:26:19 is this something that got hastily put in after you dropped mx51 support or has it always been that way? Sep 23 18:26:22 there are surely more userspace tools that expect certain kernel features Sep 23 18:26:34 it has always been that way Sep 23 18:26:42 christ.... Sep 23 18:26:48 in some releases more in some less Sep 23 18:27:13 ask our kernelteam how much they suffered from backporting changes to the imx kernels :) Sep 23 18:27:53 oh we had the same troubles here believe me Sep 23 18:27:59 Freescale keep promising a 2.6.35 Sep 23 18:28:08 i bet they still do Sep 23 18:28:19 the last we heard was "we can get you a snapshot maybe october 15th" Sep 23 18:28:25 then they said "no shapshot just wait for the bsp" Sep 23 18:28:35 that's probably november 30th Sep 23 18:28:41 we are pushing it to higher management Sep 23 18:28:44 yeah ... enjoy the wait Sep 23 18:28:51 get some icecream meanwhile :P Sep 23 18:29:04 Nah. It would melt too fast. Sep 23 18:29:19 no, you eat it and get more :) Sep 23 18:29:22 they really really want Maverick because they just realised Karmic blows donkey cock.. we explained they had better back us up and then they said "but we have no roadmap we thought you would do it all" Sep 23 18:29:33 it's really a mess.. Linaro are too focused on mainline, we need BSPs Sep 23 18:29:57 well, letting BSPs die is linaros mission Sep 23 18:30:18 and a good one imho Sep 23 18:30:55 it's a 5 year mission Sep 23 18:31:00 in any case, if your oem-config issues are upstart related i'd take a look at the kernel Sep 23 18:31:01 to boldly go where no man has gone before Sep 23 18:31:14 no doubt, like every other ship that isn't the Enterprise, it will end up as a debris field Sep 23 18:31:24 the more people help, the shorter the timefarme will get Sep 23 18:35:05 ogra_cmpc: For some reason, my omap4 image swap file is 5.5G. Jasper log looks ok, so I doubt it has anything to do with it. Sep 23 18:35:40 GrueMaster, the swap file ? Sep 23 18:35:45 * ogra_cmpc blames rsalveti Sep 23 18:35:53 :P Sep 23 18:36:09 Why? Jasper looks ok. Sep 23 18:36:36 ogra@panda:~$ ls -lh /SWAP.swap Sep 23 18:36:36 -rw-r--r-- 1 root root 512M 2010-09-22 11:38 /SWAP.swap Sep 23 18:36:49 its exactly as big as it should be here Sep 23 18:37:45 ls -lh mnt/SWAP.swap Sep 23 18:37:45 -rw-r--r-- 1 root root 5.5G 2010-09-23 11:11 mnt/SWAP.swap Sep 23 18:37:52 woah Sep 23 18:38:09 Yea. bit on the plus side. Sep 23 18:38:14 i'll try to reproduce tomorrow Sep 23 18:38:52 I'll continue on it now. I think it has to do with encrypted home directory. What would I file this under if I reproduce it? Sep 23 18:39:02 hmm Sep 23 18:39:06 good question Sep 23 18:39:21 this is why I have a hard time filing some bugs. Sep 23 18:39:39 I can spend hours trying to find the right package. Sep 23 18:39:47 ecryptfs-utils probably Sep 23 18:39:59 or cryptsetup Sep 23 18:40:13 if you reliably can point to the encrypted home Sep 23 18:40:38 I'll pick one. It will be wrong, but let someone in triage figure it out. Sep 23 18:40:46 :P Sep 23 18:40:55 well, they are deps of ubiquity Sep 23 18:41:08 one of them is responsible for the homedir stuff Sep 23 18:41:38 First I will try on my 16G SD. If that gets bloated, I'll go from ther. Sep 23 18:41:40 there Sep 23 18:41:47 afaik vstehle uses encrypted home on all his test installs Sep 23 18:42:18 i havent heard from him since we enabled swap creation again Sep 23 18:42:31 which i'd see as a good sign Sep 23 18:43:01 i really wouldnt mind dropping swap on omap4 to be honest Sep 23 18:43:32 Could. It is not as critical as on beagle. Sep 23 18:43:45 well, even there only on C4 Sep 23 18:43:52 Might actually speed it up a bit due to SD I/O. Sep 23 18:44:10 only if it swaps :) Sep 23 18:44:14 And I meant beagle, not XM. Sep 23 18:44:31 heh Sep 23 18:44:34 And apparently mine did swap a little. Sep 23 18:45:21 well, it cant swap beyond the size we gave it Sep 23 18:45:37 its not some magically autogrowing file Sep 23 18:46:05 Yea, I'll keep that in mind when I look at the 5.5G file again. Sep 23 18:46:32 it can actually only have happened at creation time Sep 23 18:46:58 I looked at the jasper log and it looked ok. Sep 23 18:47:21 dd if=/dev/zero of=${DIR}/root/SWAP.swap bs=1048576 count=512 >>$LOGFILE 2>&1 Sep 23 18:47:23 The size reported in the log was nowhere close to this. Sep 23 18:47:33 i dont see how that would create a 5.5G file Sep 23 18:48:03 yes, but it cant just grow Sep 23 18:49:19 Theory vs Reality. I don't know either, but will look at the logs more as soon as I finish flashing the other SD. Sep 23 18:50:00 And XM is fine (although I didn't add encrypted home dir on it). Sep 23 18:50:02 ouch, 5.5G of swap? Sep 23 18:50:17 makes no sense Sep 23 18:50:18 Yea. I'm big, but not that big. Sep 23 18:51:12 Also, why am I seeing mtdblock 0 errors during jasper on beagle (not XM). Sep 23 18:51:13 why don't you just use qualifiers for the dd arguments Sep 23 18:51:17 bs=1M count=512 Sep 23 18:51:28 precision :) Sep 23 18:54:46 From the dmesg log: [ 7.045257] Adding 524284k swap on /SWAP.swap. Priority:-1 extents:137 across:2219040k SS Sep 23 18:54:55 Looks ok so far. Sep 23 18:55:19 yes Sep 23 18:55:43 do you see 5.5G on the running system too ? Sep 23 18:56:05 (with ls) Sep 23 18:56:07 Just booted it. oem-config now up. Sep 23 18:56:23 oem-config ? Sep 23 18:57:23 Yes. Fresh SD install. Sep 23 18:57:54 oh, i meant the one that had the 5.5G file Sep 23 18:57:54 I have two SD cards I use for panda. One I am looking at, the other is now booting to reproduce the issue. Sep 23 18:58:36 On the SD with 5.5G, oem-install failed with an out of space error. Sep 23 18:58:45 Stopped at that point to debug. Sep 23 18:59:00 ah Sep 23 18:59:02 From oem-config.log: debconf: DbDriver "config": could not write /var/cache/debconf/config.dat-new: No space left on device Sep 23 18:59:19 Not sure what stage that is. Sep 23 18:59:34 relatively to the end Sep 23 18:59:39 but doesnt matter Sep 23 19:00:13 as long as the user can input stuff debconf is only read afaik Sep 23 19:00:21 Interesting. After creating the user, there is a message in oem-config that it is wiping swap space for security. Sep 23 19:00:30 That may be doing it. Sep 23 19:00:45 only the content though Sep 23 19:00:55 the file shouldnt grow Sep 23 19:01:39 depends on how it is trying to wipe it. If it is just doing "dd if=/dev/zero of=". Sep 23 19:02:08 Since we are using a file, it is very possible that this is what is happening. Sep 23 19:02:13 oh, that would be a possibiltty Sep 23 19:02:23 It is used to wiping a predefined partition. Sep 23 19:02:39 well, kees is busy talking in -devel Sep 23 19:02:55 he's the security expert Sep 23 19:03:22 * ogra_cmpc gets dinner and will vanish until the call now Sep 23 19:05:06 hola Sep 23 19:05:13 hey Sep 23 19:06:05 So I am testing our daily images and found that when oem-install creates a new user with home dir encryption, our /SWAP.swp file ends up filling the entire SD card. Sep 23 19:06:22 How is ubiquity zeroing the swap space? Sep 23 19:06:42 ouch, interesting bug Sep 23 19:07:03 rsalveti: It's my hidden talent. Sep 23 19:07:06 so not caused by me :-) Sep 23 19:07:11 GrueMaster: haha :-) Sep 23 19:17:07 GrueMaster: well, first of all, oem-install probably shouldn't enable home dir encryption, that's not the default in the other ISOs Sep 23 19:17:21 GrueMaster: secondly, it writes zeros to the entire partition, IIRC. Sep 23 19:17:23 It isn't? Sep 23 19:18:32 Seems to me, it is part of user creation, which on preinstalled images would be appropriate for oem-install. Sep 23 19:18:57 As to the zeroing the entire partition, I can see that. Sep 23 19:19:41 http://www.engadget.com/2010/09/23/marvell-unveils-1-5ghz-triple-core-application-processor-all-cu/#comments Sep 23 19:19:44 Spiffy. **** BEGIN LOGGING AT Thu Sep 23 20:48:15 2010 Sep 23 20:49:27 Hmmm. "NAME = Sheep on Meth". Interesting. Sep 23 20:53:12 ogra, would you care to make a blueprint or something for "the perfect storm" of features on an arm system that would make your life easier re uboot configuration and system peripherals and suchlike? :D Sep 23 20:55:27 How about make-arm-poweron-self-programming-to-perfection? Sep 23 20:55:46 :) Sep 23 20:56:07 but I mean like "it would be nice if it booted ext4 native" or you know.. that kind of thing. Sep 23 20:56:13 Might increase the footprint of the silicon a bit though. Sep 23 20:57:33 "has some other storage than f**king SD card" Sep 23 20:57:33 :D Sep 23 20:59:03 Problem there is that the beagleXM and panda have no nand. Sep 23 20:59:18 So they boot from SD by default. Sep 23 20:59:32 It is in silicon (from what I understand). Sep 23 21:04:21 Persia: anyone home ? Sep 23 21:04:53 persia ^^^^^ Sep 23 21:05:51 * persia reads some backscroll, hoping to develop context Sep 23 21:06:12 persia: no need... Sep 23 21:06:25 mpoirier, What? Sep 23 21:06:40 you were talking about a "machine driver" at one point... Sep 23 21:06:49 yes. Sep 23 21:06:59 would you have an example of its usage (any usage really) somewhere ? Sep 23 21:07:24 I have pointers to documentation, but no pointers to code. Sep 23 21:07:37 documentation then... Sep 23 21:10:21 What's the difference between the Ubuntu and Linaro kernels? Sep 23 21:13:56 DanaG, All the kernels in the Ubuntu repos are Ubuntu kernels. Sep 23 21:14:13 Current kernels come from two upstreams (kernel.org mainline and linaro) Sep 23 21:15:20 Are there any significantly notable differences between the two? Sep 23 21:15:34 er, "significantly notable" is a bit redundant. Sep 23 21:15:51 mpoirier, /usr/share/doc/linux-doc/sound/alsa/soc/machine.txt Sep 23 21:16:54 DanaG, To the limit of my knowledge, Linaro is attempting to unify ARM trees, and so has a bunch of patches that may not yet be mainline from various sources plus a bunch of patches that help unify things. Sep 23 21:17:20 Additionally, Linaro has a whole bunch of folk working on enabling stuff, so likely carries those patches. Sep 23 21:17:22 persia: mpoirier: That would fall back on our earlier discussion re: omap3beagle.c, etc. Sep 23 21:20:05 persia: cliffnotes version of scrollback: I discovered last night that omap3pandora.c enables specific ports in the codec, whereas omap3beagle.c enables the entire codec. Sep 23 21:21:26 GrueMaster, Thanks! Yeah, something more targeted makes sense. That said, it may be that every port is wired to something on the beagle (although it would be nice if they had proper names) Sep 23 21:22:03 No, the beagle just enables every port on the codec, whether it is wired outside the chip or not. Sep 23 21:22:09 Did lrg's patches help with omap4? Sep 23 21:23:18 Not sure. For our immediate useage, probably not. It also requires hacking together an ASoC.conf in /usr/share/alsa/cards, which itsself is short lived. Sep 23 21:23:35 Why? Sep 23 21:24:22 Why not /usr/share/alsa/cards/KJH34987.conf (or whatever is appropriate for that specific board) Sep 23 21:24:39 But his patch does enable us to move forward to UCM Sep 23 21:25:20 Then we can use the reported card name to configure it. Sep 23 21:25:31 UCM? Sep 23 21:25:51 UCM Usage Case Manager. Will be in Natty. Sep 23 21:25:57 New to alsa-lib. Sep 23 21:26:02 Ah, OK. Sep 23 21:26:27 The idea is to make the driver open all controls and do the system config in userspace. Sep 23 21:26:42 I think berco already created the conf file to drop in /usr/share/alsa/cards so it's low-additional-effort to enable that, as much as it's not the right long-term solution. Sep 23 21:27:11 Not sure. Sep 23 21:27:15 And ASoC will be doing this also, not just regular ALSA? Sep 23 21:27:23 Won't help with omap3 though. Sep 23 21:27:41 This is all asoc I believe. Sep 23 21:27:50 The rest of alsa may adapt. Sep 23 21:28:17 Not having to quirk HDA would make lots of folk jump up and down in joy. Sep 23 21:28:29 I'd have to read the email threads in alsa-devel. I've seen it come up a few times recently in my mailbox. Sep 23 21:28:36 That said, I thought lots of folk were looking forward to devicetree to deal with some of this. Sep 23 21:29:07 Not sure how far out devicetree is, and atm it is PPC & arm specific. Sep 23 21:29:43 That's not so helpful :( Sep 23 21:30:04 It would require all arches to support devicetree. Sep 23 21:30:36 Indeed. Sep 23 21:30:46 Or, conversely, devicetree to support all arches Sep 23 21:36:07 persia: currently omap3 (beagle, and I assume pandora) return "twl4030" in /proc/asound/cards Sep 23 21:36:33 hence we'd need /usr/share/alsa/cards/twl4030.conf and we'd be set. Sep 23 21:37:07 doesn't offer a solution to differentiate beagle, pandora, gumstix, igep... Sep 23 21:41:08 only one question, what could be the reason that my board cant support this tipe of audio format S24_3LE? Sep 23 21:58:06 device-tree is also used for Microblaze. Sep 23 21:58:28 Though, last time I tried Microblaze, it was a "bag of hurt" (me using Jobs's words). Sep 23 22:16:53 everytime I unplug something from the usb hub, the board stops recognizing when i plug something again Sep 23 22:17:12 is there any way of "restarting" the usb detection system? Sep 23 22:17:22 or what is called Sep 23 22:36:29 vstehle: cool, thanks for the patch at bug 646368, this was the fix I was looking for yesterday Sep 23 22:36:30 Launchpad bug 646368 in linux (Ubuntu) "smsc911x has no module alias, does not get auto-loaded on OMAP3 EVM (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/646368 Sep 23 22:36:53 didn't know that just adding the module alias would make the kernel to request the proper module Sep 23 22:37:38 heh Sep 23 22:37:48 i was just about to point that out to you :) Sep 23 22:38:17 perfect timing :) Sep 23 22:38:24 * ogra goes to bed ... Sep 23 22:39:07 :-) Sep 23 22:39:08 see ya Sep 23 23:01:29 rsalveti: hi... i was looking at your omap3 sgx packages.. and learn quite a few nice tricks that I didn't know. cool! Sep 23 23:03:53 ndec: cool, feel free to copy from it :-) Sep 23 23:04:48 rsalveti: for sure... the thing I didn't know was the xx.udev and xx.upstart... we have such files in our pkgs, but we are handling them in .install... will fix this. Sep 23 23:05:44 ndec: yep, nowadays we have debhelpers for everything :-) Sep 23 23:09:41 ndec, It's worth checking all the completions of dh_ : most modern rules files don't invoke any of the debhelper scripts manually, but end up using lots of features. Sep 24 00:32:53 persia: still hanging around? I have questions regarding dove audio. Sep 24 01:06:52 GrueMaster, back now. Please ask. Sep 24 01:07:45 I was looking at the dove audio issue. We hit this before in bug 451635 early in Lucid & karmic. Sep 24 01:07:46 Launchpad bug 451635 in pulseaudio (Ubuntu Karmic) (and 8 other projects) "defaults need adjustment on dove X0 for audible audio (affects: 1) (heat: 11)" [Undecided,New] https://launchpad.net/bugs/451635 Sep 24 01:08:06 Unfortunately, Marvell has changed codecs since then. Sep 24 01:09:04 It used to be an AD1980 codec. It is now an RT655. Sep 24 01:10:00 From what I can tell, it only exposes what in HD audio would be the 3 main outputs (front, rear, and center/lfe). Sep 24 01:10:06 No headphone jack. Sep 24 01:11:06 Is it the case that those 6 channels are producing audio when one tries? Sep 24 01:11:35 Physically, it has 6 RCA jacks on what would be the back of the board. Sep 24 01:12:21 On the front between VGA and serial are the mic & headphone jacks. Sep 24 01:12:36 From what I can tell in the driver, these are not connected. Sep 24 01:12:50 Not sure about the physical wiring yet. Sep 24 01:13:49 Speaker-test works fine on the RCA plugs. But no playback from Rhythmbox (pulseaudio actually spikes up to 50% CPU). Sep 24 01:13:52 Do you get any input or output from anywhere? Sep 24 01:14:14 Ugh. That usually comes from internal resampling when it's misconfigured. Sep 24 01:14:52 I initially tried the fix we made to pulseaudio in Lucid, but no effect. Sep 24 01:15:40 I can try to muck up the alsa bits, but I really am out of my element on pulseaudio. Sep 24 01:16:04 At least I still have my X0 running Lucid for reference. Sep 24 01:16:17 That pulse hack doesn't seem like enough to me. Sep 24 01:16:18 Not that it does much good. Sep 24 01:17:31 The pulse hack is what got the right controls working in Lucid. I'll have to see if it still works on Maverick on that board. I doubt that it will, though. Sep 24 01:19:02 I guess I need to figure out how to get the existing audio to go through pa first. Then I can look into the HP & Mic. Sep 24 01:21:01 OK. Sep 24 01:21:12 I've just looked through the pulse mapping configuration. Sep 24 01:22:31 I think the method you used last time remains the right way to address it: first make sure you have all the outputs in ALSA, then review the mapping in the pulse configuration. Sep 24 01:24:25 Ok Sep 24 01:25:08 I'm looking at alsamixer now and will compare with lucid on X0. Sep 24 01:26:27 I think I understand what crimsun was doing, and we can probably replicate that if we need, but I think the more important part is that you aren't seeing the headphones in ALSA. Sep 24 01:27:36 (at least for the problem with the mic & headphone jacks) Sep 24 01:28:36 Ok, nothing in alsamixer affects HP jack. Very odd. Sep 24 01:28:36 For the "it doesn't work in Rhythmbox on the RCA jacks" issue, I have a sense that we'll end up with a slightly different solution if we try to sort that now vs. first getting everything represented in ALSA, and I'd rather only try to do it once. Sep 24 01:28:46 Not really, if the jack isn't exposed. Sep 24 01:29:13 alsamixer can only act on elements exposed by the driver Sep 24 01:29:16 Well, yea. Just odd that if it isn't used, why is it on the board. Sep 24 01:30:06 I guess I will need to dig for specs on that codec then. Usually the codec driver exposes all to alsamixer. Sep 24 01:30:30 It currently shows a lot more than the machine dai has defined. Sep 24 01:30:34 I expect there is intent to use it eventually, but it wasn't a priority for porting. Sep 24 01:31:09 It's not an issue if there is stuff not exposed in the DAI, as long as it's also not wired to anything :) Sep 24 01:31:59 cooloney: hey! Sep 24 01:32:13 cooloney: third time I'm compiling the kernel and seems to be fine Sep 24 01:32:26 will continue stressing the system to see if I still get the bus error Sep 24 01:33:05 rsalveti: hey, man. do you mean 2G:2G split with npitre's VMALLOC_END patch? Sep 24 01:33:16 cooloney: yep Sep 24 01:33:25 yeah, i think so Sep 24 01:33:42 highmem = 0k Sep 24 01:33:55 that's is workaround for us, if we have to workaround it before 10/10 release Sep 24 01:34:03 rsalveti: exactly Sep 24 01:34:04 will let it running during the night, let's see if it'll go well Sep 24 01:34:10 cool Sep 24 01:34:29 i am trying to find out highmem usage when bus errors pop up Sep 24 01:34:40 any suggestion? Sep 24 01:34:53 i think we already enabled CONFIG_DEBUG_USER Sep 24 01:35:07 cooloney: hm, that's what I was going to ask you Sep 24 01:35:34 CONFIG_DEBUG_USER=y Sep 24 01:35:36 yep Sep 24 01:38:24 i enabled CONFIG_DEBUG_PAGEALLOC=y Sep 24 01:39:03 cooloney: just recreate the bus error, then see what dmesg says about it Sep 24 01:39:40 also, shouldn't we set user_debug at the cmdline? Sep 24 01:40:07 cooloney: you should get a full register dump and stack trace, etc. Sep 24 01:40:08 npitre: Unhandled fault: imprecise external abort (0x1406) at 0x2b805000 Sep 24 01:40:29 rsalveti: yeah, like that. Sep 24 01:40:32 and the kernel build: internal compiler error: Bus error Sep 24 01:41:27 npitre: http://pastebin.ubuntu.com/499410/ Sep 24 01:41:31 something like this Sep 24 01:46:01 hmmmmmm Sep 24 01:46:50 you will have to dig in the OMAP4 and/or the Cortex A9 manual to find out about what may cause an imprecise external abort Sep 24 01:47:13 is it possible to boot this thing with L2 cache disabled? Sep 24 01:47:31 that would be another thing to test Sep 24 01:51:44 also, does the stack backtrace go back to __dabt_svc or __dabt_usr? **** BEGIN LOGGING AT Fri Sep 24 02:05:42 2010