[00:06] mpoirier: ping - I updated bug 591941 with my own test results. Summary: fail. [00:06] 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] GrueMaster: how many partition do you have on your SD card ? [00:07] 2. Same as our pre-installed images. [00:08] weird - 'cause that error is not caused by the misbehaving card. [00:10] 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. === fta_ is now known as fta [07:55] Morning Ogra [08:04] Does anyone still see bug 605488 on the Panda? [08:04] 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 === lag is now known as tjmjigtx [08:14] hello [08:14] * zyga starts to hate django :P === tjmjigtx is now known as lag [08:15] _why_ oh _why_ didn't the authors provide a _standard_ and _supported_ RPC system :-( === hrw|gone is now known as hrw [08:25] mogning [08:42] too easy? === fta_ is now known as fta === fta_ is now known as fta [10:24] ogra: ping === JamieBen1ett is now known as JamieBennett [10:33] lag, i havent seen bug 605488 recently, but iirc it never showed up immediately [10:33] 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] ogra, lag, me either [10:34] ogra: You ever seen this? http://paste.ubuntu.com/473947/ [10:35] --^ On XM [10:35] lag, yeah, could be [10:35] lag: i never saw that. could you try the latest upload. [10:35] oh, XM [10:35] lag, that might be the memory bug in the XM [10:36] lag, iirc rcn-ee has workaround patches for u-boot and the kernel somewhere [10:36] until the final HW comes out [10:37] i planned to pull the u-boot side of them into the next upload [10:38] i dont exactly know how the memory bug manifests so i'm only guessing [10:39] cooloney: Do you have XM? [10:39] ogra: Do you know when the new HW comes out? === fta_ is now known as fta [10:39] lag, once all bugs are fixed :) no idea [10:40] lag, #beagle might be of help [10:46] lag: no [10:46] lag: i just have beagle C3 and panda === amitk is now known as amitk-afk === fta_ is now known as fta === fta_ is now known as fta [12:42] hey lag, yeap those are on my list. ;) [12:42] hi === fta_ is now known as fta [12:54] rcn-ee: List? [12:57] basicly every error on xm's boot.. say does your XM have Micron 512? [12:59] Numonyx is the other possibility (working).. === amitk-afk is now known as amitk [13:05] 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] rcn-ee: What's the easiest way to find out? [13:11] 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] And what's the easiest way to find out if I have a Micron or Numonyx? [13:12] considering Koen did the tweak 9 days ago... it might have been too quick specially with alpha 3.. [13:13] right, our x-loader doesnt have it yet === amitk is now known as amitk-afk [13:13] 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] Yeah, I have an M with a circle round it [13:14] is it 512? [13:14] looks back at pastbin.. [13:14] are there non-512 ones ? [13:14] Hang on [13:14] it is [13:14] all the ones we have are 512 [13:15] no need to check [13:15] though i'm surprised there are others [13:15] 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] So will that patch help me? [13:16] nope [13:17] it'll only help the production Numonyx ones coming out in a week or two.. [13:17] i might have one (not near it atm) [13:17] lag, you still got the same board you always had ? [13:18] or was yours replaced too ? [13:18] Not yet [13:18] 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] I think I'm just going to have to leave it until I get new HW [13:19] well, the mmc error isnt memory induced, is it ? [13:20] 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] 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] yeah, i saw the lots of bugmail :) [13:21] i'm kinda supprised about the Bx/Cx hitting it too now.. that one should be solid.. [13:22] probably its two different bugs [13:22] * cwillu_at_work perks up [13:23] 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] specially from atleast cwillu_at_work ;).. he's tested every card known to man.. [13:23] well, I've tested c3 and c4 :p [13:23] a dozen or so [13:23] using mainline kernels ? [13:23] no, rcn [13:24] right [13:24] close enough :p [13:25] 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] 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] 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] ogra: What's meant to be in boot.scr in the new daily image? [14:30] lag, the file is in cleartext stored in /boot/boot.script [14:30] in the rootfs [14:32] What's the one in boot all about? [14:33] I mean before first boot === bjf[afk] is now known as bjf [14:54] the one in /boot is the one the user uses to make changes [14:54] like /boot/grub/menu.lst === amitk-afk is now known as amitk [15:00] user usually tweak /etc/default/grub [15:00] lcuk: hi here [15:01] heya :) [15:03] ogra: The one in boot is full of 0x150 zeros! [15:04] lag, i'll take a look after the call [15:04] ogra: Can't you multitask ;) [15:05] no, i'm no girl :P [15:05] Really? My mistake [15:05] Must be the hair :) [15:06] i might slowly grow big enough to wear a bra though ... working from home changes you ;) [15:06] :) [15:10] fun :) [15:10] https://lists.ubuntu.com/archives/ubuntu-devel/2010-August/031073.html [15:10] ogra: buy nice one ;d [15:10] hrw, i'D never buy ugly underwear :) [15:29] lag, my boot.scr looks proper (if i ignore the uboot header) [15:30] Okay [15:30] I'll re-dd [15:30] Probably a dd error [15:30] http://paste.ubuntu.com/474071/ [15:30] np [15:30] (thats omap3) [15:30] panda looks a bit different [15:32] cat your boot.scr from the new Panda image [15:32] i need to dd that first [15:40] lag, http://paste.ubuntu.com/474075/ [15:40] ndec, http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/alpha-3/ === asac_ is now known as asac [15:42] asac, ! === amitk is now known as amitk-afk [15:42] ogra: ! [15:42] what can i do? [15:43] see #arm === JaMa is now known as JaMa|Away === hrw is now known as hrw|gone === bjf is now known as bjf[afk] === JaMa|Away is now known as JaMa [19:39] mpoirier, ping.. ;) [19:42] rcn-ee_lpt: hello ! [19:43] how's it going mpoirier any news in the deep depths of CONFIG_SOUND.. ;) [19:43] I also get the same result: CONFIG_SND_OMAP_SOC seems to be the culprit ! [19:44] how it related to sdhc card is a mystery. [19:44] I am currently rebuilding, just to make sure all the hours spend looking at config files havent' damaged my brain. [19:44] hrw|gone: do you mind to point me to your source packages? [19:44] no idea either, other then the possible SPI based sound card? or maybe we are getting hte same clocks? [19:45] remember that CONFIG_CPU_IDLE|FREQ are also curing the issue/ [19:45] clock is definitively an option. [19:45] sound is going to sleep, the clock is killed... [19:46] and the sdhc card dies. [19:46] 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] zumbi: It's probably late for hrw [19:47] do you know for sure that sdhc and sound are on the same clock ? [19:47] lool: where are their sources? :) [19:47] s,their,his [19:48] no, i'm actually assuming... based on what seems like a direct link.. [19:48] indeed - I was looking for a quick break. [19:49] 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] now that the problem seem to have been cornered, looking at code is the next step [19:49] yes, we have an open door to TI. [19:50] in a couple of sentence, what is hte dm37xx you're referring to ? [19:50] oh, that's what the xm's chip will be called... [19:50] dm replaces omap... (for this model) [19:51] you mean the XM has a dm rather than omap ? [19:52] blaim it on marketing... the omap is now 'dm'.... [19:52] ok, but on your XM, do you have an omap3530 ? [19:53] 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] ha. I get it thanks for the clarification. [19:54] seems like the clocks are the same though since the problem occur on both. [19:54] no problem.. it's a crazy nightmare... ;) [19:54] ok, next I'll poke my TI contact and put them on the case. [19:55] 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] I also have access to the original people who wrote the driver. [19:55] they are in india. [19:55] I'll send them an email with our little findings. [19:58] 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] as far as I can tell, the problem started with 2.6.34, nope, no point going lower [19:59] bisect is also something to consider. [19:59] but we still don't know that to look for. [20:00] we have a better idea but... [20:00] there would be a lot of bisects. [20:01] 4 minutes per build, 30 seconds to copy, 30 to boot.. i've done worse bisecting on a beagle (6hrs between..) [20:01] ;) [20:03] rcn-ee: mpoirier: Good work! Keep it up [20:03] ; [20:03] ;) [20:04] lag: you're supposed to be in a bar by this time [20:04] mpoirier: Meh! [20:04] zumbi: I don't know [20:04] I'm working on something for myself (Bluetooth) [20:05] what, you guys don't drink and code? [20:05] lag: do you at least have a beer next to you ? [20:05] I'm 3/4 bottle of wine down ;) [20:06] fabulous ! [20:06] rcn-ee_lpt: i'll checkout 2.6.34-rc1 to rc7 and try to isolate where the problem was introduced. [20:07] from there I' [20:07] I'll start a bisect. [20:07] i got my machine going too.. just gota tweak the one patch for 2.6.34.. [20:10] rcn-ee: hey, did you see that error log I pasted last night ? [20:11] yeah rsavoye although it was on my other machine.. [20:11] ok. hope it was useful [20:14] 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] I tried using -O0 tp reduce stress, but no such luck [20:15] after a few dozen of those stack dumps, my XM often hangs completely [20:16] 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] rcn-ee_lpt: have you ever tested ramz on beagle? don't know how stable or unstable it is [20:26] I heard from ogra that was quite unstable, with bugs [20:26] but no more than that [20:27] sorry, been to busy with the xm, so other then enabling it, haven't really tested it.. [20:27] it's based of the compcache ubuntu's been shipping for awhile right? [20:29] nope.. pre 2.6.34: [ 4.296813] mmc0: error -110 whilst initialising SD card [20:32] yep, but it's disabled for omap, I believe [20:34] someone refresh my memory, where is the location in ubuntu (x86 desktop) to tweak the removable media settings? [20:35] prpplague: I think they ate it [20:35] prpplague: I dont have the gnome removable media tool in my menus by default [20:35] XorA: seems like there is a command line you cna issue [20:36] yeah it's gone.. right a script for and pray the device id never changes. ;) [20:36] or run KDE :_) [20:37] not that I would wish that hell on anyone [20:37] rcn-ee_lpt: i just don't want it to pop up a window every time it mounts [20:38] 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] ahh found it [20:47] prpplague, give https://answers.launchpad.net/ubuntu/+question/30501 a try.. gconf-editor has a media_automount_open.. [20:48] rcn-ee_lpt: if you open a window browsing the contents, you can go edit preferences and there are some options there [20:50] cool. i see it too.. disabled.. [21:43] NCommander: Should we enable netboot images for omap4? [21:54] rcn-ee_lpt: did you try 2.6.35-rc1 to rc5 ? [21:54] rcn-ee_lpt: meant 2.6.34-rc1 to rc5 [21:56] 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] Or is there no significant changes in the config? [21:57] GrueMaster: that can be done with a little fiddling to DI, assign me a bug [21:57] NCommander: Not sure if it is already part of the preinstalled image blueprint. Need to check there first. [21:58] mpoirier, i went as low as 2.6.34-rc7 anything else won't post on the Xm.. [21:58] 2.6.34-rc1 to rc5 don't output anything on the console [21:59] here's the kicker: 2.6.33.rc8 works fine. [21:59] that's funny... [21:59] and the next booting tag, 2.6.34-rc6 is broken. [21:59] so it's somewhere between 2.6.33-rc8 - 2.6.34-rc7 [22:00] this is on the Bx right? [22:00] 2.6.33-rc8 and 2.6.34-rc6 [22:00] Cx [22:00] c4.. i mean.. i'm the only one with old stuff [22:00] somewhere in there... [22:01] but it is impossible to find since the kernel won't boot. [22:01] hence you can't bisect that. [22:02] I just asked about the r1 to rc5 in #beagle but nobody replied. [22:04] mpoirier, yeah #beagle doesn't really care unless it's angstrom's kernel.. ;) .. [22:04] one small problem... http://pastebin.com/APevgWD6 [22:04] i need to dig thru my sdhc cards... [22:06] zumbi: https://edge.launchpad.net/~hrw/+archive/arm-cross-compiler/ [22:07] rcn-ee_lpt: what is this link you just sent ? [22:08] 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] yeah, i was asleep during 2.6.34 develment, i can't find any notes about the console in my old trees.. [22:23] guys kridner just posted the xm schematics: http://beagleboard.org/hardware/design [22:25] nice [22:36] okay back in businness, found a pny sdhc card that fails on my bx "mmc0: error -110" [22:38] Who do I ping with spelling errors in the XM manual? (And if they used OpenOffice it would have already found these.) [22:38] :P [22:38] gerald on beagleboard.org.. [22:39] Grumble. 4 years of college and all I really know is how to proofread. [22:41] Oh there's an A2 now [22:43] lool: xm a2? [22:45] 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] yeap the xm A2 is the first production one.. [22:45] are you tacking our little mmc problem or the console not coming out ? [22:46] the patch is a console patch... earlyprintk (serial boot) was converted in that rc cycle.. [22:46] omap specific to generic conversion... [22:47] fantastic - I was actually bisecting between 2.6.33-rc8 and 2.6.34-rc1 to find what broke the console output. [22:55] hrw|gone: Yeah [22:57] crap, for 2.6.34-rc2, remove the omap_vram/dss2 stuff.. it breaks.. [23:03] 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] console again ? [23:03] vram.c failes to compile.. so 2.6.34-rc2 won't build.. (2.6.34-rc3 fails mmc -110) [23:07] 2.6.34-rc2 fails.. i really hope it isn't the rc1 merge... [23:11] 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] crap 2.6.34-rc1 fails... so that leaves 2.6.33-rc8 -> 2.6.34-rc1... [23:28] mpoirier, are you guys sure 2.6.33 failed? there was a large omap conversion from 2.6.33->34-rc1 [23:28] 2.6.33-rc8 works. [23:29] rc2 fails, [23:29] therefore it is between 2.6.33-rc8 and 34-rc1 [23:32] yay.. ;) crabs another beer... there's lots of config changes.. [23:34] you're always one step ahead of me. [23:35] i'm currently compiling 34-rc1 after cherry-picking 21b9034 [23:35] ;) it's just easier when you have all the patches from the last time i had to build it for real.. [23:36] and a lot of experience doing it. [23:36] do you know how many patches between 33-rc8 and 34-rc1 ? [23:37] 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] rcn-ee_lpt: still no console output on 34-rc1, even after cherry picking 21b9034. [23:43] did i miss something ? [23:44] for rc1 you need 21b9034 (merge rc2) and then the previous one too... [23:45] 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] ok, let me try [23:47] 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] you mean 33-rc8 -> 34-rc1 ? [23:48] http://rcn-ee.homeip.net:81/testing/2.6.33-config [23:48] 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] you can go all the way to 33-rc8 if you want. [23:51] ok, got console output on 34-rc1. [23:51] cool