**** BEGIN LOGGING AT Mon Sep 13 02:59:58 2010 Sep 13 06:23:59 cooloney: for the highmem issue, it'd be nice to test it upstreams Sep 13 06:24:02 *upstream Sep 13 06:24:05 http://marc.info/?l=linux-omap&m=128413257515288&w=2 Sep 13 06:24:32 it seems we have a tree that can boot at the es2, but for me it was unable to find the mmc Sep 13 06:24:41 so can't test it Sep 13 06:25:13 once we have a better answer from Ghorai, pointing us what is needed to make it work, we can easily test if we can reproduce the highmem issue with upstream Sep 13 06:33:53 rsalveti: thanks, man Sep 13 06:34:21 rsalveti: did you try the audio things on your ES2.0 Sep 13 06:34:44 i need to reinstall the daily-live image on my board, but lost my HDMI cable Sep 13 07:27:34 morning Sep 13 08:36:41 ogra_omap4: Hi! Today's image checks the drives at boot, and finds errors! "Press F to attempt to fix..." Sep 13 08:38:46 vstehle, smells like the rsizing didnt happen Sep 13 08:38:51 *re Sep 13 08:39:24 vstehle, is that completely unmodified ? Sep 13 08:39:43 ogra: Yes. zcat, reboot. Sep 13 08:40:06 ogra: I saw the resize happen. Sep 13 08:40:07 hmm Sep 13 08:40:25 and it reboots too ? Sep 13 08:40:54 after resize ... Sep 13 08:41:53 ogra: Yes. Sep 13 08:41:59 hrm Sep 13 08:42:05 ogra: The disk checks happens before reboot. Sep 13 08:42:15 *before* ?!? Sep 13 08:42:48 now thats weird, there is nothing that could do an interactive check at that point Sep 13 08:42:54 ogra: Ok, not completely accurate: it rebooted after checks :) Sep 13 08:43:12 ogra: Probably because slash was "fixed" ? Sep 13 08:43:26 slash ? Sep 13 08:43:31 ogra: / Sep 13 08:43:35 no Sep 13 08:44:10 there is one fsck right before resizing, but thats completely /dev/null'ed Sep 13 08:44:24 after resizing there isnt any fsck until the reboot command Sep 13 08:44:26 ogra: This one I did not see Sep 13 08:44:41 "checking filesystem before resizing..." Sep 13 08:44:47 thats the one Sep 13 08:44:48 ogra: I don't know the exact command; it was the graphical frontend, with the dots Sep 13 08:45:05 ogra: It was not in text mode any more Sep 13 08:45:06 but there should be no output ot the screen and definitely no interaction Sep 13 08:45:18 then it was after reboot Sep 13 08:45:20 ogra: There were messages about filesystem check Sep 13 08:45:41 ogra: And it definitely asked me to type 'F' to confirm that it should "fix" the filesystem Sep 13 08:45:59 ogra: It complained also for a fraction of a second about tmp not being there or not ready Sep 13 08:46:03 ogra: and then reboot Sep 13 08:46:04 there is no splash screen before reboot at all Sep 13 08:46:24 ogra: maybe it rebooted also between resize and dots, probably. Sep 13 08:46:37 well, you would have noticed Sep 13 08:46:43 it takes a while for u-boot Sep 13 08:46:58 ogra: But I don't have the serial console in front of me always Sep 13 08:47:18 no, but you would have a black screen for about 30sec at least Sep 13 08:47:29 until kernel/initrd are there Sep 13 08:47:44 ogra: I'll redo the steps more carefully and take notes :) Sep 13 08:47:55 k, i'll try to reproduce it here too Sep 13 08:48:06 ogra: I can run a terminal ok, today :) Sep 13 08:48:11 did you have network plugged in btw ? Sep 13 08:48:28 ogra: Yes Sep 13 08:48:38 hmm, k Sep 13 08:49:05 * ogra zsyncs todays image to check whats going on Sep 13 08:49:12 ogra: Oh, wait, you mean: when the "checks" happened? The board had no network. Sep 13 08:49:20 aha Sep 13 08:49:46 might be an issue with the fixrtc script that sets the clock to last mount time of the disk Sep 13 08:50:23 it is to prevent fsck if the clock is wrong Sep 13 08:51:08 (which it always is if there is no ntp server reachable and no RTC closk) Sep 13 08:51:11 *clock Sep 13 08:51:17 err Sep 13 08:51:20 s/clock/battery/ Sep 13 08:53:04 ogra: Also, we don't have a gnome "bar" any more. Is this awaited? Sep 13 08:53:13 no, its not Sep 13 08:54:01 ogra: I would have sworn it was there during the installer... Sep 13 08:54:09 thats not gnome :) Sep 13 08:54:23 the installer has its own minimal panel now Sep 13 08:54:37 (i'll switch our desktop to it during natty) Sep 13 08:56:02 ogra: There is something weird with the console colors; the red is black. Sep 13 08:56:29 checked your cable ? Sep 13 08:56:41 we didnt have a kernel upgrade or anything afaik Sep 13 08:56:51 so the framebuffer shouldnt have changed Sep 13 08:57:26 ogra: :) Looks like a software thing this time. Try typing 'z' in top in text mode. Sep 13 08:57:48 well, let me get an image first, still zsyncing Sep 13 08:57:57 3min to go Sep 13 08:57:58 ogra: You can do the same in a gnome terminal and see the difference Sep 13 08:58:10 ogra: I'll redo the zcat and install. Sep 13 08:58:13 and i need to find some breakfast first Sep 13 08:58:33 hmm you are using zcat ... ? Sep 13 08:58:44 * ogra has never done it that way ... Sep 13 09:28:51 anyone here know anything about this http://www.embeddedarm.com/products/board-detail.php?tab=options&product=TS-7800# like if ubuntu can be put on it? Sep 13 09:37:34 neil_d, thats ARM9 (ARMv5) ... ubuntu only supports v7 (cortex-a8 and upwards) Sep 13 09:37:47 use debian on ARM9 Sep 13 09:40:27 neil_d: as ogra said debian or with some little work openembedded(angstrom) and openwrt Sep 13 09:40:58 neil_d: there's support for ts72xx boards in OpenEmbedded already Sep 13 09:42:10 neil_d: and here's quite old but a good starting point for ts7800 http://ted.openavr.org/OE-for-ts7800/ Sep 13 11:03:07 so is the ARM9 a different thing to the cotex-a8 etc.? Sep 13 11:03:28 cortex-a8 is ARMv7 Sep 13 11:03:46 while ARM9 is only ARMv5 Sep 13 11:03:54 different specifications Sep 13 11:04:20 all ubuntu binaries are built specifically for v7 Sep 13 11:04:30 so they wont run on older stuff Sep 13 11:04:49 oh! Sep 13 11:04:57 imagine you try to run binaries that are compiled for i686 on a real 386 machine Sep 13 11:05:12 386 wont have all the instructions the 686 has Sep 13 11:05:30 been trying to find an ARM card with SATA for a dedicated server... but they are hard to find. Sep 13 11:06:00 yeah Sep 13 11:06:13 SATA is very rare on ARM SoCs Sep 13 11:06:17 neil_d: grab guruplug Sep 13 11:06:24 right Sep 13 11:06:34 but that wont run ubuntu either Sep 13 11:06:36 neil_d: or other kirkwood based device with sata and run debian on it Sep 13 12:00:06 vstehle, so i had no fsck yet with todays daily image Sep 13 12:01:29 * ogra wonders if vstehle's SD card is somewhat worn out Sep 13 12:01:58 ogra: I could not reproduce it. I think I might have not waited enough for shutdown Sep 13 12:02:10 ah, yeah, that could be Sep 13 12:02:13 ogra: Btw, the gnome menu is back; was probably linked to my bad fs somehow Sep 13 12:02:24 we only flush the cache for the Sd at unmount Sep 13 12:02:25 ogra: I am now trying SGX on top of daily; promising Sep 13 12:02:34 sweet Sep 13 12:04:03 jasper sets vm.vfs_cache_pressure=50 and vm.dirty_writeback_centisecs = 6000 ... that causes the kernel to write to the SD less often which results in a massive speedup, but requires that you properly shut down Sep 13 12:04:05 vstehle: cool, with the latest driver? Sep 13 12:04:35 (as a rule of thumb, just wait until the monitor shuts off) Sep 13 12:10:41 rsalveti: Yes. But it is not completely ok now :) Sep 13 12:12:10 vstehle: oh, ok :-) Sep 13 13:57:30 ogra: If I boot up my ES2.0 and install a new kernel using dpkg, do I have to do anything after? Sep 13 13:57:41 I am 'downgrading' the kernel Sep 13 13:58:09 ls Sep 13 13:59:29 lag: besides updating uInitrd and uImage, nothing Sep 13 14:00:04 just make sure flash-kernel is taking the kernel you want Sep 13 14:00:18 How do I do that from inside the image? Sep 13 14:00:36 So far I've issued: dpkg -i linux-* Sep 13 14:02:06 that should suffice Sep 13 14:02:11 try it :) Sep 13 14:02:16 That does everything? Sep 13 14:02:19 a reboot only takes a minute Sep 13 14:02:27 It's still installing Sep 13 14:02:34 I should, I believe Sep 13 14:02:36 it generates an initrd and calls flash-kernel in the end, yes Sep 13 14:02:57 k Sep 13 14:03:13 if you have any issues, file a bug against flash-kernel Sep 13 14:03:23 but i dont think you will have any Sep 13 14:07:01 0 bytes read Sep 13 14:07:01 ## Booting image at 80000000 ... Sep 13 14:07:01 Bad Magic Number Sep 13 14:07:01 PANDA # Sep 13 14:07:04 :( Sep 13 14:07:31 lag: could be the case that you're still using the old u-boot Sep 13 14:07:38 smells like it Sep 13 14:07:47 It's a fresh flash Sep 13 14:07:52 From today's image Sep 13 14:08:08 It booted the first time Sep 13 14:08:32 Oh wait! Sep 13 14:32:36 lag, we're still waiting :) Sep 13 14:32:53 * lag is reflashing Sep 13 14:32:57 ah Sep 13 15:02:55 ogra: omap not building images? I only got a blank email. Sep 13 15:03:30 Yeah, that happens if the builder is down Sep 13 15:03:39 Ah. Sep 13 15:03:40 I pinged lamont already Sep 13 15:04:10 At least omap4 worked fine Sep 13 15:18:53 How do you retrieve this number: 2.6.35-903.X Sep 13 15:34:51 lag: grep :D Sep 13 15:36:26 hi all, I have a problem using --no-root with the latest rootstock (version 126): http://paste.ubuntu.com/493171/ Sep 13 15:36:47 armin76: grep what for what? Sep 13 15:37:19 furibondox: can you paste your log file? Sep 13 15:37:22 yes Sep 13 15:38:01 lag, uname -r Sep 13 15:38:28 http://paste.ubuntu.com/493172/ Sep 13 15:38:34 this is the last part of the file Sep 13 15:38:36 ogra_cmpc: Tried that Sep 13 15:39:30 lag, and ? Sep 13 15:39:42 rsalveti: I'm running the rootstock from a lucid pc Sep 13 15:40:05 Displays 2.6.35-903-omap4 Sep 13 15:40:25 I need to know X where X is a number Sep 13 15:40:28 oh tou want the abi Sep 13 15:40:30 furibondox: interesting, the error message is "Success" :-) Sep 13 15:40:34 Yeah Sep 13 15:40:36 *you Sep 13 15:40:37 right... it seems that genext2fs return a right error code (0) Sep 13 15:40:37 furibondox: let me try it here Sep 13 15:40:46 yep Sep 13 15:40:56 rsalveti: I try to insert an echo $? and the output was 0 Sep 13 15:43:19 lag, dpkg -l|grep linux-image|grep ^ii|grep $(uname -r) Sep 13 15:43:35 and then some cut magic to get the second field Sep 13 15:43:36 What's ^ii? Sep 13 15:43:58 it greps only installed packages Sep 13 15:44:27 (filter for dpkg -l) Sep 13 15:44:50 It just locked up on me :( Sep 13 15:44:59 what ? dpkg Sep 13 15:45:06 furibondox: for now, try commenting the if part of genext2fs (calling it directly) to see if rootstock is able to create the rootfs Sep 13 15:45:07 No, the board Sep 13 15:45:16 Went to screen saver and refused to come out Sep 13 15:45:29 try switching consoles Sep 13 15:45:32 Rebooting Sep 13 15:45:36 gah Sep 13 15:45:36 Next time Sep 13 15:45:42 yeah Sep 13 15:45:46 furibondox: I'm looking why genext2fs trying to be verbose Sep 13 15:45:59 *is trying Sep 13 15:46:08 ok Sep 13 15:46:11 i noticed something similar but console switching solves it ... i cant reproduce it reliably yet though Sep 13 15:46:15 now i try commenting the if part... Sep 13 15:47:38 ogra: What's the current ABI? Sep 13 15:47:53 * ogra_cmpc cant tell from here Sep 13 15:48:36 When I installed it, it said "downgrading to x.x.x-903.8 from x.x.x-902.11 Sep 13 15:48:42 But only 5 and 8 are installed Sep 13 15:48:53 hmm Sep 13 15:49:19 thats also not a downgrade Sep 13 15:49:28 903 > 902 Sep 13 15:51:08 rsalveti: after commenting the if part it seems that it stops again... but I don't understand why Sep 13 15:51:35 http://paste.ubuntu.com/493180/ Sep 13 15:52:03 after line 7 it return to the prompt Sep 13 15:53:12 ogra_cmpc: What? Sep 13 15:53:22 furibondox: probably because of genext2fs return code (the script has set -e) Sep 13 15:53:40 ogra_cmpc: Oh, I see Sep 13 15:53:45 No, that's a typo Sep 13 15:53:51 Both were 903 Sep 13 15:55:19 yes... I see Sep 13 15:56:13 furibondox: after failing, try running genext2fs by hand Sep 13 15:56:22 so we can understand why it's failing Sep 13 15:57:19 I can try to print the same command line used by genext2fs and then execute the same command... Sep 13 15:57:40 furibondox: yep, or call it with bash -x ./rootstock Sep 13 15:58:13 I've done it before but the /tmp/tmp.XXXXX/rootfs folder is not more present... Sep 13 15:59:10 may be now without the if part the cleanup function is not called so the rootfs folder extracted should be leaved in the /tmp/tmp.XXXXXX Sep 13 15:59:11 right? Sep 13 16:00:48 furibondox: yep, without the if part the clean_up is not called Sep 13 16:01:09 so you can still go to the generated directory Sep 13 16:01:45 i can check but I have to run the rootstock again with the set -x in order to check the exact parameters to pass to genext2fs Sep 13 16:02:53 furibondox: or you can try to look for the /tmp/tmp.XXX directory that was't wiped out Sep 13 16:03:20 genext2fs -b 104857 -i 4096 -d rootfs rootfs.img should be ok Sep 13 16:04:21 furibondox: genext2fs -b 2097152 -i 4096 -d rootfs rootfs.img as you requested 2GB Sep 13 16:04:25 genext2fs -b 2097152 -i 4096 -d /tmp/tmp.8DXifxNx1k/rootfs /tmp/tmp.8DXifxNx1k/qemu-armel-201009131759.img Sep 13 16:04:39 I'm waiting the exit of the program... Sep 13 16:04:53 ok Sep 13 16:08:25 http://paste.ubuntu.com/493184/ Sep 13 16:08:39 very strange... the qemu image is 0 byte long Sep 13 16:09:07 furibondox: did it fail with the same message? Sep 13 16:09:35 genext2fs: output filesystem image: Success Sep 13 16:09:38 yes Sep 13 16:09:39 furibondox: try using -b 1048576 Sep 13 16:09:58 genext2fs consumes a lot of ram Sep 13 16:10:23 I'm trying Sep 13 16:10:42 yes, you need as much free ram as the imagesize is Sep 13 16:11:31 genext2fs is a quite old code, and it was created to generate small images, so they just map everything into memory Sep 13 16:12:04 great! using -b 1048576 the image is generated correctly Sep 13 16:12:34 furibondox: so try running with -i 1GB Sep 13 16:13:55 yes I'm just trying ;) Sep 13 16:15:29 I've also remove the comment to the if part... Sep 13 16:26:46 * rsalveti lunch Sep 13 16:48:16 ogra: On bug 628204, should I refile it against the go-home-applet? Sep 13 16:48:16 Launchpad bug 628204 in ubuntu-netbook-efl-default-settings (Ubuntu Maverick) (and 1 other project) "go-home-applet not accessable on armel images (affects: 2) (heat: 506)" [Medium,Confirmed] https://launchpad.net/bugs/628204 Sep 13 16:48:38 yeah Sep 13 16:50:13 Done. I had been looking at the gconf settings between Lucid & Maverick and not seeing anything different there. Sep 13 16:52:50 i doubt its gconf Sep 13 16:54:48 Like I said, I didn't find anything there. Just a blank entry. Nothing in the go-home-applet source indicates that it uses more than that. Sep 13 19:10:55 http://www.anandtech.com/show/3912/boxee-box-the-inside-story Sep 13 19:52:36 robclark: good afternoon Sep 13 19:53:45 hi mpoirier Sep 13 19:54:33 robclark: a few weeks ago we had a chat about EDID Sep 13 19:54:54 I read it from user space, you from the driver. Sep 13 19:55:22 could you point me to your patch one again pls ? Sep 13 19:55:23 yeah.. and I talked a bit w/ mythripk about it since then.. since we have a similar issue with the DVI-D interface on panda.. Sep 13 19:55:35 sure hang on.. Sep 13 19:56:25 fwiw, mythripk was suggesting adding an API to the panel driver to return either the fixed timings (for LCD type device, with hard-coded resolution), or EDID for things like HDMI/DVI monitor.. Sep 13 19:56:44 so probably we should have a talk with her one of these mornings Sep 13 19:57:18 at this time, we are looking to do a back port of your work in omap3 - do you think this is possible ? Sep 13 19:57:32 possibly.. Sep 13 19:58:00 although mythripk was talking about splitting out EDID code into separate utility within DSS2.. that would make your life a bit easier, but not sure about the timeframe Sep 13 19:58:07 I wanted to investigat first Sep 13 19:58:35 fwiw, my most current branch right now is http://gitorious.org/~robclark/pandaboard/robclarks-kernel-omap4/commits/drm-lite ... but the patches you are interested in are a bit further down.. Sep 13 19:58:55 let check... Sep 13 19:59:15 I guess look at the commits that have EDID or HDMI in the name ;-) Sep 13 20:00:01 mpoirier, did you talk to ricardo ? he owns teh EDEI spec now Sep 13 20:00:15 *EDID Sep 13 20:01:30 robclark: thanks for your time Sep 13 20:01:35 (just to make sure we dont duplicate work here, i'm not sure if he doesnt work on the u-boot implementation right now) Sep 13 20:01:59 rsalveti ^^^ Sep 13 20:02:16 mpoirier: also.. dss2/omapfb don't deal well with dynamic resizing.. have a look at the commits cad4d0c, c07189e Sep 13 20:03:13 mpoirier: I have a patch already trying to add the EDID parsing in omap3 Sep 13 20:03:20 that's what I'm currently working on Sep 13 20:04:38 what I'm trying at the moment is probing and parsing the edid at the panel-generic Sep 13 20:04:50 using the api we already have at the kernel Sep 13 20:04:57 omap4 is not using the edid api Sep 13 20:05:06 but getting and parsing everything by hand Sep 13 20:06:36 robclark: the idea for now would be just to probe and get it right while booting the kernel Sep 13 20:06:48 the second step would be changing it, when needed Sep 13 20:08:21 rsalveti: just keep in mind, that omapfb might end up initializing itself (and therefore reading the resolution) before the HDMI driver has a chance to read the EDID Sep 13 20:08:37 so even if the monitor is plugged in a boot, the order of things at bootup might screw you Sep 13 20:09:04 robclark: oh, sure Sep 13 20:12:00 argh, sgx packaging is just terrible Sep 13 20:12:12 we have 3 different sets of libraries Sep 13 20:12:29 each one for a different hardware Sep 13 20:12:35 at least the kernel modules are the same Sep 13 20:12:56 and just the .so files Sep 13 22:39:32 NCommander: Any chance of reviving apport-retrace this cycle? Sep 13 22:43:16 GrueMaster: now that I'm back home, maybe Sep 13 22:43:25 depends on how stable my A0 is Sep 13 22:45:37 Other than the stupid parallel port driver, it should be fine. Mine is. Sep 13 22:46:41 GrueMaster: indeed. the A0 is much more stable IMHO **** ENDING LOGGING AT Tue Sep 14 02:59:57 2010