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