[00:06] <GrueMaster> mpoirier: ping - I updated bug 591941 with my own test results.  Summary:  fail.
[00:06] <ubot2> Launchpad bug 591941 in linux (Ubuntu Maverick) (and 1 other project) "SDHC card not recognized (affects: 2) (dups: 1) (heat: 20)" [High,In progress] https://launchpad.net/bugs/591941
[00:07] <mpoirier> GrueMaster: how many partition do you have on your SD card ?
[00:07] <GrueMaster> 2.  Same as our pre-installed images.
[00:08] <mpoirier> weird - 'cause that error is not caused by the misbehaving card.
[00:10] <GrueMaster> One thing I noticed is that the card I have been running Lucid on (same card I have used for this test in the past) indicates that the partitions are not on cylinder boundaries.  I am backing up the card and will reformat/recopy the data back & retest.
[07:55] <lag> Morning Ogra
[08:04] <lag> Does anyone still see bug 605488 on the Panda?
[08:04] <ubot2> Launchpad bug 605488 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "BUG: scheduling while atomic: mmcqd/46/0x00000002 (affects: 1) (heat: 177)" [High,In progress] https://launchpad.net/bugs/605488
[08:14] <zyga> hello
[08:14]  * zyga starts to hate django :P
[08:15] <zyga> _why_ oh _why_ didn't the authors provide a _standard_ and _supported_ RPC system :-(
[08:25] <hrw> mogning
[08:42] <kblin> too easy?
[10:24] <lag> ogra: ping
[10:33] <ogra> lag, i havent seen bug 605488 recently, but iirc it never showed up immediately
[10:33] <ubot2> Launchpad bug 605488 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "BUG: scheduling while atomic: mmcqd/46/0x00000002 (affects: 1) (heat: 177)" [High,In progress] https://launchpad.net/bugs/605488
[10:34] <cooloney> ogra, lag, me either
[10:34] <lag> ogra: You ever seen this? http://paste.ubuntu.com/473947/
[10:35] <lag> --^ On XM
[10:35] <ogra> lag, yeah, could be
[10:35] <cooloney> lag: i never saw that. could you try the latest upload.
[10:35] <cooloney> oh, XM
[10:35] <ogra> lag, that might be the memory bug in the XM
[10:36] <ogra> lag, iirc rcn-ee has workaround patches for u-boot and the kernel somewhere
[10:36] <ogra> until the final HW comes out
[10:37] <ogra> i planned to pull the u-boot side of them into the next upload
[10:38] <ogra> i dont exactly know how the memory bug manifests so i'm only guessing
[10:39] <lag> cooloney: Do you have XM?
[10:39] <lag> ogra: Do you know when the new HW comes out?
[10:39] <ogra> lag, once all bugs are fixed :) no idea
[10:40] <ogra> lag, #beagle might be of help
[10:46] <cooloney> lag: no
[10:46] <cooloney> lag: i just have beagle C3 and panda
[12:42] <rcn-ee> hey lag, yeap those are on my list. ;)
[12:42] <dcordes_> hi
[12:54] <lag> rcn-ee: List?
[12:57] <rcn-ee> basicly every error on xm's boot.. say does your XM have Micron 512?
[12:59] <rcn-ee> Numonyx is the other possibility (working)..
[13:05] <rcn-ee> lag, if your's is a 512 model, make sure your x-load has this patch http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=b4c5ef7e0e06890b1369bfbd5c767820024adb21  (r15 from rcn-ee.net)
[13:10] <lag> rcn-ee: What's the easiest way to find out?
[13:11] <rcn-ee> there really isn't a good way.. no 'version' bumps, only way I know is the "rX" value angstrom auto addes to the file name..
[13:12] <lag> And what's the easiest way to find out if I have a Micron or Numonyx?
[13:12] <rcn-ee> considering Koen did the tweak 9 days ago... it might have been too quick specially with alpha 3..
[13:13] <ogra_cmpc> right, our x-loader doesnt have it yet
[13:13] <rcn-ee> I'm hoping Numonyx sticks their logo on the memory module.. Micron should have a weird "M", i know Elpida sticks their name on it..
[13:14] <lag> Yeah, I have an M with a circle round it
[13:14] <rcn-ee> is it 512?
[13:14] <rcn-ee> looks back at pastbin..
[13:14] <ogra_cmpc> are there non-512 ones ?
[13:14] <lag> Hang on
[13:14] <ogra_cmpc> it is
[13:14] <ogra_cmpc> all the ones we have are 512
[13:15] <ogra_cmpc> no need to check
[13:15] <ogra_cmpc> though i'm surprised there are others
[13:15] <rcn-ee> yeap yours is like mine...  the Micron memory has been dropped till Micron figures why they dont' work properly, some boards work fine, some fail weirdly..
[13:16] <lag> So will that patch help me?
[13:16] <ogra_cmpc> nope
[13:17] <rcn-ee> it'll only help the production Numonyx ones coming out in a week or two..
[13:17] <ogra_cmpc> i might have one (not near it atm)
[13:17] <ogra_cmpc> lag, you still got the same board you always had ?
[13:18] <ogra_cmpc> or was yours replaced too ?
[13:18] <lag> Not yet
[13:18] <rcn-ee> they were weird, according to gerald, some of the micron ones were fine (passed testing) but others had to be de-soldered and replaced, half yields..
[13:18] <lag> I think I'm just going to have to leave it until I get new HW
[13:19] <ogra_cmpc> well, the mmc error isnt memory induced, is it ?
[13:20] <rcn-ee> myself, i'm just taking care of bugs i can.. cause as soon as i do an "aptitude update" or "update-initframs" my memory corrupts and takes the board down..
[13:21] <rcn-ee> nope it isn't.. it seems config related, my 2.6.35+lots of patches custom config doesn't do it.. but my 2.6.35+xm does hit the error.. so more config testing this morning..
[13:21] <ogra_cmpc> yeah, i saw the lots of bugmail :)
[13:21] <rcn-ee> i'm kinda supprised about the Bx/Cx hitting it too now.. that one should be solid..
[13:22] <ogra_cmpc> probably its two different bugs
[13:22]  * cwillu_at_work perks up
[13:23] <ogra_cmpc> i at least have seen two issues i think, one is the -110 error, with the other one the card is found but readonly
[13:23] <rcn-ee> specially from atleast cwillu_at_work ;).. he's tested every card known to man..
[13:23] <cwillu_at_work> well, I've tested c3 and c4 :p
[13:23] <cwillu_at_work> a dozen or so
[13:23] <ogra_cmpc> using mainline kernels ?
[13:23] <cwillu_at_work> no, rcn
[13:24] <ogra_cmpc> right
[13:24] <cwillu_at_work> close enough :p
[13:25] <rcn-ee> yeah the 'ro' is to parts, the xm the wp bit.. the bx/cx is a weird regression over possibly a broken implementation.. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ed8303fc111e58530e22bd29b0d7e08dced75999 (bisected..)
[13:26] <rcn-ee> if you revert that commit.. the 'ro' issue doesn't happen with bx/cx... But if you play with the wp slot on any SD card it's not even detected, which leads to the gpio mux on the wp line doesn't work..
[13:30] <rcn-ee> ogra_cmpc, here's my 'ro' bx testing 2.6.34/2.6.35 SD card wp handle testing: http://pastebin.com/Hx08KR5G
[14:15] <lag> ogra: What's meant to be in boot.scr in the new daily image?
[14:30] <ogra_cmpc> lag, the file is in cleartext stored in /boot/boot.script
[14:30] <ogra_cmpc> in the rootfs
[14:32] <lag> What's the one in boot all about?
[14:33] <lag> I mean before first boot
[14:54] <ogra> the one in /boot is the one the user uses to make changes
[14:54] <ogra> like /boot/grub/menu.lst
[15:00] <hrw> user usually tweak /etc/default/grub
[15:00] <hrw> lcuk: hi here
[15:01] <lcuk> heya :)
[15:03] <lag> ogra: The one in boot is full of 0x150 zeros!
[15:04] <ogra> lag, i'll take a look after the call
[15:04] <lag> ogra: Can't you multitask ;)
[15:05] <ogra> no, i'm no girl :P
[15:05] <lag> Really? My mistake
[15:05] <lag> Must be the hair :)
[15:06] <ogra> i might slowly grow big enough to wear a bra though ... working from home changes you ;)
[15:06] <lag> :)
[15:10] <ogra> fun :)
[15:10] <ogra> https://lists.ubuntu.com/archives/ubuntu-devel/2010-August/031073.html
[15:10] <hrw> ogra: buy nice one ;d
[15:10] <ogra> hrw, i'D never buy ugly underwear :)
[15:29] <ogra> lag, my boot.scr looks proper (if i ignore the uboot header)
[15:30] <lag> Okay
[15:30] <lag> I'll re-dd
[15:30] <lag> Probably a dd error
[15:30] <ogra> http://paste.ubuntu.com/474071/
[15:30] <lag> np
[15:30] <ogra> (thats omap3)
[15:30] <ogra> panda looks a bit different
[15:32] <lag> cat your boot.scr from the new Panda image
[15:32] <ogra> i need to dd that first
[15:40] <ogra> lag, http://paste.ubuntu.com/474075/
[15:40] <ogra> ndec, http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/alpha-3/
[15:42] <ogra> asac, !
[15:42] <asac> ogra: !
[15:42] <asac> what can i do?
[15:43] <ogra> see #arm
[19:39] <rcn-ee_lpt> mpoirier, ping.. ;)
[19:42] <mpoirier> rcn-ee_lpt: hello !
[19:43] <rcn-ee_lpt> how's it going mpoirier any news in the deep depths of CONFIG_SOUND.. ;)
[19:43] <mpoirier> I also get the same result: CONFIG_SND_OMAP_SOC seems to be the culprit !
[19:44] <mpoirier> how it related to sdhc card is a mystery.
[19:44] <mpoirier> I am currently rebuilding, just to make sure all the hours spend looking at config files havent' damaged my brain.
[19:44] <zumbi> hrw|gone: do you mind to point me to your source packages?
[19:44] <rcn-ee_lpt> no idea either, other then the possible SPI based sound card? or maybe we are getting hte same clocks?
[19:45] <mpoirier> remember that CONFIG_CPU_IDLE|FREQ are also curing the issue/
[19:45] <mpoirier> clock is definitively an option.
[19:45] <mpoirier> sound is going to sleep, the clock is killed...
[19:46] <mpoirier> and the sdhc card dies.
[19:46] <rcn-ee_lpt> which if it just happens to be the same 'clock' on the xm.. (we get more clock sources with the dm37xx, some are still not being taken care off..)
[19:46] <lool> zumbi: It's probably late for hrw
[19:47] <mpoirier> do you know for sure that sdhc and sound are on the same clock ?
[19:47] <zumbi> lool: where are their sources? :)
[19:47] <zumbi> s,their,his
[19:48] <rcn-ee_lpt> no, i'm actually assuming... based on what seems like a direct link..
[19:48] <mpoirier> indeed - I was looking for a quick break.
[19:49] <rcn-ee_lpt> do you guys have better contacts at ti? maybe the dm37xx clock tree would give some hints.. (i'm thinking they inserted a new clock between to existing ones?)
[19:49] <mpoirier> now that the problem seem to have been cornered, looking at code is the next step
[19:49] <mpoirier> yes, we have an open door to TI.
[19:50] <mpoirier> in a couple of sentence, what is hte dm37xx you're referring to ?
[19:50] <rcn-ee_lpt> oh, that's what the xm's chip will be called...
[19:50] <rcn-ee_lpt> dm replaces omap... (for this model)
[19:51] <mpoirier> you mean the XM has a dm rather than omap ?
[19:52] <rcn-ee_lpt> blaim it on marketing... the omap is now 'dm'....
[19:52] <mpoirier> ok, but on your XM, do you have an omap3530 ?
[19:53] <rcn-ee_lpt> the omap3530 is only on the Bx/Cx.. the xm gets the improved omap3630 which then got tweaked/tuned and renamed into dm37xx
[19:53] <mpoirier> ha. I get it thanks for the clarification.
[19:54] <mpoirier> seems like the clocks are the same though since the problem occur on both.
[19:54] <rcn-ee_lpt> no problem.. it's a crazy nightmare... ;)
[19:54] <mpoirier> ok, next I'll poke my TI contact and put them on the case.
[19:55] <rcn-ee_lpt> cool, we had another user ask today, and they keep pointing to use the am3715 doc's.. so hopefully you guys have more push. ;)
[19:55] <mpoirier> I also have access to the original people who wrote the driver.
[19:55] <mpoirier> they are in india.
[19:55] <mpoirier> I'll send them an email with our little findings.
[19:58] <rcn-ee_lpt> it'll be interesting... do you think there's much point to retrying on 2.6.34 to see if maybe we can maybe bisect? i wouldn't go lower then that for the xm..
[19:59] <mpoirier> as far as I can tell, the problem started with 2.6.34, nope, no point going lower
[19:59] <mpoirier> bisect is also something to consider.
[19:59] <mpoirier> but we still don't know that to look for.
[20:00] <mpoirier> we have a better idea but...
[20:00] <mpoirier> there would be a lot of bisects.
[20:01] <rcn-ee_lpt> 4 minutes per build, 30 seconds to copy, 30 to boot..  i've done worse bisecting on a beagle (6hrs between..)
[20:01] <rcn-ee_lpt> ;)
[20:03] <lag_> rcn-ee: mpoirier: Good work! Keep it up
[20:03] <lag_> ;
[20:03] <lag_> ;)
[20:04] <mpoirier> lag: you're supposed to be in a bar by this time
[20:04] <lag_> mpoirier: Meh!
[20:04] <lool> zumbi: I don't know
[20:04] <lag_> I'm working on something for myself (Bluetooth)
[20:05] <rcn-ee_lpt> what, you guys don't drink and code?
[20:05] <mpoirier> lag: do you at least have a beer next to you ?
[20:05] <lag_> I'm 3/4 bottle of wine down ;)
[20:06] <mpoirier> fabulous !
[20:06] <mpoirier> rcn-ee_lpt: i'll checkout 2.6.34-rc1 to rc7 and try to isolate where the problem was introduced.
[20:07] <mpoirier> from there I'
[20:07] <mpoirier> I'll start a bisect.
[20:07] <rcn-ee_lpt> i got my machine going too.. just gota tweak the one patch for 2.6.34..
[20:10] <rsavoye> rcn-ee: hey, did you see that error log I pasted last night ?
[20:11] <rcn-ee_lpt> yeah rsavoye although it was on my other machine..
[20:11] <rsavoye> ok. hope it was useful
[20:14] <rcn-ee> yeah... http://paste.ubuntu.com/473807/  i've been fighting that one too on my normal beagles..  plenty of ram, and swap.. but it starts oom'ing..
[20:14] <rsavoye> I tried using -O0 tp reduce stress, but no such luck
[20:15] <rsavoye> after a few dozen of those stack dumps, my XM often hangs completely
[20:16] <rcn-ee_lpt> yeap after the first one it's just a matter of time...  i'm kinda hoping either the ramz or ram-defrag stuff takes care of it in 2.6.35.. i know cwillu_at_work was fighting it too..
[20:26] <rsalveti> rcn-ee_lpt: have you ever tested ramz on beagle? don't know how stable or unstable it is
[20:26] <rsalveti> I heard from ogra that was quite unstable, with bugs
[20:26] <rsalveti> but no more than that
[20:27] <rcn-ee_lpt> sorry, been to busy with the xm, so other then enabling it, haven't really tested it..
[20:27] <rcn-ee_lpt> it's based of the compcache ubuntu's been shipping for awhile right?
[20:29] <rcn-ee_lpt> nope.. pre 2.6.34: [    4.296813] mmc0: error -110 whilst initialising SD card
[20:32] <rsalveti> yep, but it's disabled for omap, I believe
[20:34] <prpplague> someone refresh my memory, where is the location in ubuntu (x86 desktop) to tweak the removable media settings?
[20:35] <XorA> prpplague: I think they ate it
[20:35] <XorA> prpplague: I dont have the gnome removable media tool in my menus by default
[20:35] <prpplague> XorA: seems like there is a command line you cna issue
[20:36] <rcn-ee_lpt> yeah it's gone..  right a script for and pray the device id never changes. ;)
[20:36] <XorA> or run KDE :_)
[20:37] <XorA> not that I would wish that hell on anyone
[20:37] <prpplague> rcn-ee_lpt: i just don't want it to pop up a window every time it mounts
[20:38] <rcn-ee_lpt> yeah, it's annoying.. not sure how to take care of that, i know my 'setup_sd.sh' flashes the pop up 4-5 times..
[20:43]  * prpplague has done it before
[20:47] <prpplague> ahh found it
[20:47] <rcn-ee_lpt> prpplague, give https://answers.launchpad.net/ubuntu/+question/30501 a try.. gconf-editor has a media_automount_open..
[20:48] <prpplague> rcn-ee_lpt: if you open a window browsing the contents, you can go edit preferences and there are some options there
[20:50] <rcn-ee_lpt> cool. i see it too.. disabled..
[21:43] <GrueMaster> NCommander: Should we enable netboot images for omap4?
[21:54] <mpoirier> rcn-ee_lpt: did you try 2.6.35-rc1 to rc5 ?
[21:54] <mpoirier> rcn-ee_lpt: meant 2.6.34-rc1 to rc5
[21:56] <GrueMaster> mpoirier: Not sure how difficult it would be, but have you taken the omap kernel config and tried it on the Working Lucid kernel?
[21:56] <GrueMaster> Or is there no significant changes in the config?
[21:57] <NCommander> GrueMaster: that can be done with a little fiddling to DI, assign me a bug
[21:57] <GrueMaster> NCommander: Not sure if it is already part of the preinstalled image blueprint.  Need to check there first.
[21:58] <rcn-ee_lpt> mpoirier, i went as low as 2.6.34-rc7 anything else won't post on the Xm..
[21:58] <mpoirier> 2.6.34-rc1 to rc5 don't output anything on the console
[21:59] <mpoirier> here's the kicker: 2.6.33.rc8 works fine.
[21:59] <rcn-ee_lpt> that's funny...
[21:59] <mpoirier> and the next booting tag, 2.6.34-rc6 is broken.
[21:59] <rcn-ee_lpt> so it's somewhere between 2.6.33-rc8 - 2.6.34-rc7
[22:00] <rcn-ee_lpt> this is on the Bx right?
[22:00] <mpoirier> 2.6.33-rc8 and 2.6.34-rc6
[22:00] <mpoirier> Cx
[22:00] <rcn-ee_lpt> c4.. i mean.. i'm the only one with old stuff
[22:00] <mpoirier> somewhere in there...
[22:01] <mpoirier> but it is impossible to find since the kernel won't boot.
[22:01] <mpoirier> hence you can't bisect that.
[22:02] <mpoirier> I just asked about the r1 to rc5 in #beagle but nobody replied.
[22:04] <rcn-ee_lpt> mpoirier, yeah #beagle doesn't really care unless it's angstrom's kernel.. ;) ..
[22:04] <rcn-ee_lpt> one small problem... http://pastebin.com/APevgWD6
[22:04] <rcn-ee_lpt> i need to dig thru my sdhc cards...
[22:06] <hrw|gone> zumbi: https://edge.launchpad.net/~hrw/+archive/arm-cross-compiler/
[22:07] <mpoirier> rcn-ee_lpt: what is this link you just sent ?
[22:08] <rcn-ee_lpt> that is the same micro sd card.. that fails on my Xm... but not on my Bx... (Bx needs a Micro to BIG convertor)
[22:14] <rcn-ee_lpt> yeah, i was asleep during 2.6.34 develment, i can't find any notes about the console in my old trees..
[22:23] <rcn-ee_lpt> guys kridner just posted the xm schematics: http://beagleboard.org/hardware/design
[22:25] <rsalveti> nice
[22:36] <rcn-ee_lpt> okay back in businness, found a pny sdhc card that fails on my bx "mmc0: error -110"
[22:38] <GrueMaster> Who do I ping with spelling errors in the XM manual? (And if they used OpenOffice it would have already found these.)
[22:38] <GrueMaster> :P
[22:38] <rcn-ee_lpt> gerald on beagleboard.org..
[22:39] <GrueMaster> Grumble.  4 years of college and all I really know is how to proofread.
[22:41] <lool> Oh there's an A2 now
[22:43] <hrw|gone> lool: xm a2?
[22:45] <rcn-ee_lpt> mpoirier, 2.6.34-rc5 is bad.. this patch will take care of most of 2.6.34-rc's.. http://rcn-ee.homeip.net:81/testing/patch-2.6.34-rc.diff
[22:45] <rcn-ee_lpt> yeap the xm A2 is the first production one..
[22:45] <mpoirier> are you tacking our little mmc problem or the console not coming out ?
[22:46] <rcn-ee_lpt> the patch is a console patch... earlyprintk (serial boot) was converted in that rc cycle..
[22:46] <rcn-ee_lpt> omap specific to generic conversion...
[22:47] <mpoirier> fantastic - I was actually bisecting between 2.6.33-rc8 and 2.6.34-rc1 to find what broke the console output.
[22:55] <lool> hrw|gone: Yeah
[22:57] <rcn-ee_lpt> crap, for 2.6.34-rc2, remove the omap_vram/dss2 stuff.. it breaks..
[23:03] <rcn-ee_lpt> mpoirier, for 2.6.34-rc2 you'll need: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5c1f96f4
[23:03] <mpoirier> console again ?
[23:03] <rcn-ee_lpt> vram.c failes to compile.. so 2.6.34-rc2 won't build..  (2.6.34-rc3 fails mmc -110)
[23:07] <rcn-ee_lpt> 2.6.34-rc2 fails.. i really hope it isn't the rc1 merge...
[23:11] <rcn-ee_lpt> for 2.6.34-rc1 we need: (for serial) http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=21b9034
[23:17] <rcn-ee_lpt> crap 2.6.34-rc1 fails...  so that leaves 2.6.33-rc8 -> 2.6.34-rc1...
[23:28] <rcn-ee_lpt> mpoirier, are you guys sure 2.6.33 failed?  there was a large omap conversion from 2.6.33->34-rc1
[23:28] <mpoirier> 2.6.33-rc8 works.
[23:29] <mpoirier> rc2 fails,
[23:29] <mpoirier> therefore it is between 2.6.33-rc8 and 34-rc1
[23:32] <rcn-ee_lpt> yay.. ;) crabs another beer... there's lots of config changes..
[23:34] <mpoirier> you're always one step ahead of me.
[23:35] <mpoirier> i'm currently compiling 34-rc1 after cherry-picking 21b9034
[23:35] <rcn-ee_lpt> ;) it's just easier when you have all the patches from the last time i had to build it for real..
[23:36] <mpoirier> and a lot of experience doing it.
[23:36] <mpoirier> do you know how many patches between 33-rc8 and 34-rc1 ?
[23:37] <rcn-ee_lpt> well, i'm just trying to get 2.6.33 built right now.. (and praying to rule out rc1) but alot of the config names changed...
[23:43] <mpoirier> rcn-ee_lpt: still no console output on 34-rc1, even after cherry picking 21b9034.
[23:43] <mpoirier> did i miss something ?
[23:44] <rcn-ee_lpt> for rc1 you need 21b9034 (merge rc2) and then the previous one too...
[23:45] <rcn-ee_lpt> this is the 'pervious' one mimized as much as possible http://rcn-ee.homeip.net:81/testing/patch-2.6.34-rc-take2.diff
[23:46] <mpoirier> ok, let me try
[23:47] <rcn-ee_lpt> sure.. well 2.6.33 works...  i'll post my config in second just incase i ended up remving too much..  but itlooks like 2.6.33 -> 2.6.34-rc..
[23:48] <mpoirier> you mean 33-rc8 -> 34-rc1 ?
[23:48] <rcn-ee_lpt> http://rcn-ee.homeip.net:81/testing/2.6.33-config
[23:48] <rcn-ee_lpt> well i got 2.6.33 to boot (no problems with mmc card...) but i'm going to double check the config.. incase oldconfig removed too much
[23:49] <mpoirier> you can go all the way to 33-rc8 if you want.
[23:51] <mpoirier> ok, got console output on 34-rc1.
[23:51] <rcn-ee_lpt> cool