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