=== dl9pf_ is now known as dl9pf | ||
=== JaMa|Zzzz is now known as JaMa | ||
=== rtp_ is now known as rtp | ||
=== ynezz_ is now known as ynezz | ||
=== hrw|gone is now known as hrw | ||
=== jamie_ is now known as JamieBennett | ||
=== the_eye_ is now known as dimitris | ||
=== JaMa is now known as JaMa|Off | ||
=== hrw is now known as hrw|gone | ||
armin76 | asac: whats the status of db-4.8 failure with thumb2? | 18:44 |
---|---|---|
armin76 | did you fix it? | 18:44 |
samuel_Sayag | hello | 20:30 |
NCommander | armin76: it appears to be fixed | 20:34 |
nosse1 | What is the best approach for debugging Ubuntu startup issues? upstart starts, but hangs somewhere during boot. "--verbose" doesn't reveal anything | 20:37 |
nosse1 | I suspect some missing kernel feature. The kernel is cross compiled because I don't have a running target system running yet. | 20:38 |
NCommander | nosse1: what SoC? | 20:38 |
nosse1 | AM3517 | 20:38 |
* prpplague wants to play with AM3517 | 20:39 | |
nosse1 | I am capable of injecting "init=/bin/bash" and thus start upstart manually from the prompt, but it doesn't help | 20:39 |
nosse1 | How do you guys do the initial bringup of Ubuntu on some target? | 20:46 |
nosse1 | JTAG debugger? | 20:46 |
armin76 | Martyn: got audio working on the tegra? | 20:47 |
rsalveti | nosse1: what do you mean initial? boot loader? kernel? | 20:47 |
nosse1 | I've got boot loader and I've got a (cross compiled) kernel, so that's fine. | 20:48 |
nosse1 | The thing is I've created a rootstock image which I'm trying to boot on (or perhaps more correctly "root" on) | 20:48 |
rsalveti | cool, so I guess that you can work to the other steps just booting the kernel and debugging by uart connection | 20:49 |
Martyn | armin76 : No, since it's not relevant to using ARM as a server | 20:49 |
nosse1 | But I can't build a kernel natively for the target as I don't have a target system running with Ubuntu | 20:49 |
Martyn | I'm even working on disabling video, and getting back the 64MB that steals | 20:49 |
rsalveti | nosse1: so, are you able to mount the filesystem and start the init stuff? | 20:49 |
Martyn | armin76 : What Im dissapointed in, though, is that the tegra2 PCIe suffers from a deadlock | 20:49 |
nosse1 | Yes. It hangs sometime after upstart and before terminal login | 20:49 |
Martyn | armin76 : So I can't use the PCIe interface | 20:49 |
rsalveti | nosse1: oh, ok, so you basically need to debug the upstart scripts | 20:50 |
armin76 | Martyn: why as a server? don't like it for tablet/smartbook? | 20:50 |
rsalveti | nosse1: are you able to fully boot and get the terminal, at least once? | 20:50 |
nosse1 | rsalveti: Yes. And I've tried to use "init=/sbin/init --verbose" in the kernel params. But it doesn't reveal anything useful | 20:51 |
nosse1 | rsalveti: Using "init=/bin/bash" gives me a working console, yes | 20:52 |
Martyn | armin76 : Smooth-stone is making a Server-on-Chip out of the arm cortex A9 .. we use other C-C9 based platforms to test our theories before our own chip tapes out | 20:52 |
rsalveti | nosse1: oh, so you can try the initscripts by hand, until you identify what's actually breaking your system | 20:52 |
rsalveti | maybe running upstart with strace | 20:53 |
rsalveti | if you have it available | 20:53 |
nosse1 | I can get strace. Because qemu lets med download any app to my system using apt-get | 20:53 |
rsalveti | with strace you can see easily what initscript is breaking your system | 20:54 |
rsalveti | then you can try to remove it and move on, until you can get a working environment to be able to debug it further | 20:54 |
rsalveti | let me check if you can debug upstart in a different way, since verbose is not helping you | 20:55 |
nosse1 | I do have a suspicion that its some feature missing from the kernel, since the kernel is not build natively in ubuntu-land. But I do need to get the system up and running natively before I can build native packages :D | 20:57 |
rsalveti | yeah, verbose shows almost nothing :-) | 20:57 |
nosse1 | I'll certainly try the strace | 20:58 |
rsalveti | nosse1: sure :-) you can try to use qemu or scratchbox | 20:58 |
rsalveti | but scratchbox is more a scarebox than anything else | 20:58 |
nosse1 | well, I did. qemu crashes on lucid and the network is somewhat broken, #548353 | 20:59 |
rsalveti | nosse1: if you have a cross compiler set up on your host, you can try to build the kernel with most of the features as built-int, then you'll probably be able to boot it fine | 20:59 |
rsalveti | nosse1: are you able to mount the rootfs without any problem? | 20:59 |
nosse1 | Yes. Both via SD or NFS. Both are viable and stable | 21:00 |
rsalveti | oh, so yeah, probably a bug when trying to set something at your hardware | 21:00 |
rsalveti | as it's hanging | 21:00 |
rsalveti | let me check the bug | 21:00 |
nosse1 | I had a really hard afternoon not understanding why I couldn't get ssh login to my qemu target system | 21:01 |
nosse1 | My strategy has been to make a rootstock ubuntu-minimal, and then use qemu to access apt-get for everything else I need for my physical target | 21:02 |
nosse1 | qemu does work, it's just that I'm stuck with 80x24 console | 21:03 |
nosse1 | I hoped I could use qemu to compile the native kernel for the real target, but gcc dies with internal compiler error, so I didn't feel the urge to go down that road. | 21:04 |
rsalveti | nosse1: hm, it seems to be really a bug in qemu itself | 21:05 |
rsalveti | ouch, internal compiler error :-) | 21:05 |
nosse1 | Yeah, I didn't know where to stick the bug rootstock or qemu. ogra wanted me to post it on rootstock so there it is | 21:05 |
rsalveti | nosse1: you could try to use qemu with this rootfs but getting inside it using chroot | 21:05 |
nosse1 | How do I do that? I mean, I am now using a ext2 image file which is passed to qemu | 21:06 |
rsalveti | nosse1: you could mount that as a loop device | 21:07 |
rsalveti | register the arm emulator using binfmt | 21:07 |
rsalveti | and get inside using chroot | 21:07 |
nosse1 | When mounting the real target I use loop device, and then mount it using NFS | 21:07 |
rsalveti | nosse1: similar with scratchbox and what we did with mamona (openembedded based distro) | 21:08 |
rsalveti | that was our sdk, basically | 21:08 |
nosse1 | But when i start qemu i do get the lucid image as root. I'm sorry I don't see why I need chroot, that's all | 21:08 |
rsalveti | nosse1: oh, chroot is basically to get inside the lucid enviroment and use the native binaries, that will then be emulated by qemu | 21:09 |
rsalveti | it's not a full emulation solution | 21:09 |
rsalveti | you'll just emulate what you execute inside chroot | 21:09 |
rsalveti | so once you get inside chroot, you can use the native arm compiler, if needed | 21:09 |
rsalveti | the chroot is just to limit the compiler and linker enviroment, so it can find the arm libraries and so on | 21:09 |
nosse1 | Ah. You are not running a full system emulator; only a bin-per-bin emulation. This is new to me. Do you have any links to how-tos? | 21:10 |
rsalveti | different from a full emulation solution, you can get inside the distro with chroot instead of ssh | 21:10 |
rsalveti | sure, let me try some links with what we worked on at mamona | 21:10 |
nosse1 | excellent! | 21:11 |
rsalveti | can change the scripts and post something regarding this later when I get home :-) | 21:11 |
nosse1 | What timezone are you in? | 21:11 |
rsalveti | nosse1: brazil, utc-3 | 21:11 |
nosse1 | Ah. Because it's getting late PM here, so I'll have to leave for the evening. I will go at it tomorrow morning | 21:12 |
rsalveti | this is the script we created to get inside the chroot enviroment: http://dev.openbossa.org/mamona/gitweb?p=tools.git;a=blob;f=mamona-installer/scripts/mamona-chroot.in | 21:13 |
nosse1 | Eh. Norway, CET-1 i forgot | 21:13 |
rsalveti | basically it mounts the proc, dev and pts, if needed | 21:13 |
rsalveti | nosse1: oh, ok, so you can check it tomorrow | 21:13 |
rsalveti | just ping me, will test it later | 21:13 |
rsalveti | http://dev.openbossa.org/mamona/gitweb?p=tools.git;a=blob;f=mamona-installer/scripts/mamona-stdcheck.in | 21:13 |
nosse1 | thanks, really appreciate it | 21:13 |
rsalveti | this is the one that has most of the interesting functions | 21:14 |
rsalveti | the binfmt_register is the one that we register inside the kernel that we want it to use the qemu in case you're running an arm binary | 21:14 |
rsalveti | nosse1: will change it to fit in a more generic way so we can easily use it in any rootfs | 21:15 |
rsalveti | hopefully qemu will work fine with gcc and so on | 21:15 |
rsalveti | and you're then able to built whatever you need | 21:15 |
nosse1 | The ultimate goal it to make the real target work :D | 21:16 |
rsalveti | nosse1: yeah, sure :-) | 21:16 |
rsalveti | nosse1: what board are you trying to use with ubuntu? | 21:16 |
nosse1 | Well now we're using the TI AM3517-EVM kit | 21:17 |
nosse1 | But we're developing some products that will have the same SoC | 21:17 |
rsalveti | oh, cool | 21:17 |
nosse1 | And I'm exploring the possibility to use Ubuntu behind the scenes | 21:17 |
nosse1 | It's going to be a end-user product, where the user will never see Ubuntu directly | 21:18 |
rsalveti | nice, for sure ubuntu seems to be a good target as the os for this board | 21:18 |
nosse1 | But I hoped Ubuntu could ease up the system maintenance part of this project. | 21:18 |
rsalveti | nosse1: oh, got it | 21:19 |
nosse1 | So that we can focus on our Qt based app | 21:19 |
rsalveti | nosse1: so you basically need the platform up and running and then you'll customize the UI stack | 21:19 |
nosse1 | Yes | 21:19 |
rsalveti | nosse1: are you runnint Qt with X11? or directly at the framebuffer? | 21:19 |
nosse1 | And if lucid fits (mostly) out of the box, then I'd be very happy | 21:19 |
rsalveti | nice, too bad it's so hard to get development kits here in brazil :-( | 21:20 |
nosse1 | We are exploring if X11 or fb gives the best perforamce. TI has Open GL accel on both | 21:20 |
rsalveti | nosse1: sure, and I guess that the X11 omapfb driver is running quite well | 21:20 |
rsalveti | I think it's supporting EXA, DRI2 and etc | 21:20 |
rsalveti | I would say that X11 is better, if you have all these hardware acceleration implemented as a video driver | 21:21 |
nosse1 | I does have issues on some kinds of objects, but we're evaluating as we speak | 21:21 |
rsalveti | nosse1: the opengl is always a problem :-( | 21:21 |
rsalveti | the n900 is always facing many many issues with the opengl stack | 21:22 |
rsalveti | by imagination | 21:22 |
nosse1 | Well. gfx acceleration is critical for the app. The product is solely a 5.7" screen with touch, nothing more | 21:22 |
rsalveti | nosse1: oh, got it, it's just one single application as the window manager and composite manager? | 21:23 |
rsalveti | nosse1: qt does that very well if you use the opengles backend | 21:23 |
rsalveti | and nokia is improving the support a lot, to use it for the next devices | 21:23 |
nosse1 | one single app. Or more precise: we can make it that way | 21:23 |
rsalveti | cool | 21:24 |
nosse1 | Yes, and since "Trolltech" is here in norway, support isnt far away | 21:24 |
rsalveti | nosse1: oh, true :-) I know a couple of people from the new qt-software, they are very accessible | 21:25 |
rsalveti | qt will be the future for new UI concepts and products | 21:25 |
nosse1 | Yes, I agree. With SoC CPUs being as powerful as they are, Qt has become very available | 21:26 |
nosse1 | Ah. But this has been a productive conversation. Unfortunately I have to leave for the evening. I'll leave my irc open in case you want to post any more urls. | 21:27 |
nosse1 | I'll be back in the morning. Thank you very much | 21:27 |
rsalveti | nosse1: sure, np :-) | 21:27 |
rsalveti | talk to you tomorrow | 21:27 |
NCommander | nosse1: sorry, I had to go AFK, but you usually need a proper initramfs to boot an ubuntu based system as of lucid | 21:28 |
nosse1 | now, that interesting. Because the rootstock image does not have a initramfs installed. And it is no problem to start qemu-system-arm without one | 21:29 |
rsalveti | guess you don't need it if you're just builting everything in | 21:30 |
NCommander | nosse1: I can't say for sure, but things break if you don't have one | 21:30 |
Martyn | NCommander : Heh .. I do pretty good without one :) | 21:30 |
NCommander | rsalveti: not due to kernel modules | 21:30 |
nosse1 | Unless, there's a initramfs inside the zImage referenced from https://wiki.ubuntu.com/ARM/RootfsFromScratch | 21:30 |
Martyn | NCommander : But then again, I've gotten used to creating non-initramfs based dists for testing @ Smooth-Stone ... since I'm only using base + server | 21:31 |
NCommander | Martyn: that's probably it, since desktop now is trying to use plymouth and mountall voodoo | 21:31 |
Martyn | NCommander : The trick is to have -everything- you need compiled into the kernel at boot too. | 21:31 |
rsalveti | yeah, but if you build a kernel without any module, you're free to go without initramfs | 21:31 |
Martyn | rsalveti: No, you're not | 21:31 |
Martyn | rsalveti : On desktop -- there are /scripts/ running in the initramfs that you can't get away with. | 21:31 |
Martyn | rsalveti: They need to be copied out of initramfs and put in the main rootFS if you want to do away with the initramfs | 21:32 |
nosse1 | How come the rootstock image works without a kernel nor initrd image installed? | 21:32 |
NCommander | Martyn: even with the server, you *really* should be using an initramfs | 21:32 |
rsalveti | oh, sure, because of the desktop scripts | 21:32 |
Martyn | NCommander : Can't .. not enough RAM | 21:32 |
NCommander | Martyn: how little RAM are we talking?!, we used an initramfs on NSLU2 | 21:32 |
Martyn | NCommander : Not with LUCID you didn't :) | 21:33 |
Martyn | you try to get lucid working on lslu2 .. go on :) | 21:33 |
NCommander | Martyn: *cough*, ok, when we supportred NSLU | 21:33 |
NCommander | Martyn: I just need a new SoC and a steady hand :-) | 21:33 |
Martyn | NCommander : <512MB ram at this point, means lucid initramfs won't work | 21:33 |
NCommander | Martyn: should work just fine | 21:33 |
Martyn | you simply won't get enough ramdisk | 21:33 |
NCommander | Martyn: Dove Y0 only booted with 364MiB | 21:33 |
NCommander | Martyn: and I know we've managed to boot as far down as 128MiB before | 21:34 |
Martyn | NCommander : I've tried booting desktop (twice) on a non-published multicore A9 platform with only 256M .. failure | 21:34 |
Martyn | I haven't tried limiting the tegra2 to 384M though .. would be worth an experiment. | 21:34 |
nosse1 | Since the rootstock image works without the initrd image, I'd bet that given a kernel with enough statically built resources, that you don't need the initrd for the initial bootup. | 21:34 |
armin76 | ubuntu failure? :D | 21:35 |
Martyn | nosse1 : Under karmic, sure. | 21:35 |
NCommander | Martyn: tegra2? Damn, you get fun hardware | 21:35 |
Martyn | NCommander : I always get fun hardware, you know that. | 21:35 |
rsalveti | yeah, I wish I had one of those in my hands | 21:35 |
Martyn | and the tegra2 250 is a nice chip :) | 21:35 |
Martyn | it's the second chip we've gotten in-house that even comes CLOSE to what our server chip will finally be like | 21:35 |
armin76 | Martyn: without neon :) | 21:35 |
nosse1 | Martyn: But lucid rootstock image _does_ work without. I'm using it here... | 21:36 |
Martyn | and the second one to clock >GHz | 21:36 |
NCommander | Martyn: I do have a 1Ghz snapdragon (in my phone) | 21:36 |
Martyn | NCommander : Not multicore though, and that's the big difference | 21:36 |
NCommander | Martyn: wait, multicore >Ghz?!?!@?!?!?!@#$ | 21:36 |
NCommander | ... | 21:36 |
Martyn | linux gets -really- snappy when you have a second core to offload tasks on | 21:36 |
* NCommander stares | 21:36 | |
Martyn | NCommander : What did you think the tegra2 is? It's DUAL core, 1.0->1.2 GHz | 21:37 |
NCommander | Martyn: I thought tegra was single core SoC; I've never seen one in person | 21:37 |
Martyn | and (unpublished chip under NDA) is TRI core, 1.2 GHz :) | 21:37 |
Martyn | tegra was .. tegra2 is dual | 21:37 |
NCommander | Martyn: *drooooooooooooool* | 21:37 |
rsalveti | yeah, it's a increadible hardware, missing just neon | 21:37 |
NCommander | rsalveti: we don't have any plans to use NEON in Ubuntu ATM | 21:37 |
NCommander | Pretty much the Cortex A8/A9 are the only chips that suppor tNEON and ARMv7 | 21:38 |
Martyn | ( Small paste-flood ) | 21:38 |
NCommander | AND thumb2 | 21:38 |
Martyn | Processor: ARMv7 Processor rev 0 (v7l) | 21:38 |
Martyn | processor: 0 | 21:38 |
Martyn | BogoMIPS: 1998.84 | 21:38 |
Martyn | processor: 1 | 21:38 |
Martyn | BogoMIPS: 1998.84 | 21:38 |
NCommander | Martyn: O_O;;;;;;;;;; | 21:38 |
rsalveti | NCommander: oh, ok | 21:38 |
NCommander | Martyn: I want some to put in our datacenter | 21:38 |
rsalveti | it could be useful for multimedia, but yeah, not all hardware supports it | 21:38 |
Martyn | Features: swp half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16 neon | 21:38 |
armin76 | NCommander: I HAVE ONE! | 21:38 |
Martyn | and no, I'm not telling who produced that chio :) | 21:38 |
rsalveti | man hahaha | 21:39 |
NCommander | Martyn: I will tell you BogoMIPS aren't 100% accurate | 21:39 |
Martyn | but that last entry makes ALL the difference to science apps :) | 21:39 |
armin76 | Martyn: hows that you have neon? | 21:39 |
NCommander | Martyn: my Dove board reportds 400 BogoMIPS, but its 600/800Mhz core | 21:39 |
Martyn | NCommander : this is definitely hardware clocked at 1.1 GHz :) I checked with a scope :) | 21:39 |
NCommander | Martyn: indeed, I need to poke Marvell and ask | 21:39 |
Martyn | armin76 : That's not a tegra or tegra2 | 21:39 |
nosse1 | My AM3517 (500MHz) shows 500 BogoMIPS | 21:40 |
* NCommander thinks we're running at 800Mhz, but isn't 100% sure | 21:40 | |
Martyn | armin76 : Thats (unpublishable manufacturer) making a chip for (some device coming out in December) with three cores | 21:40 |
armin76 | Martyn: ah... | 21:40 |
Martyn | the tegra2 reports : | 21:40 |
Martyn | Features: swp half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16 | 21:40 |
Martyn | CPU implementer: 0x41 | 21:40 |
Martyn | CPU architecture: 7 | 21:40 |
armin76 | Hostname: tegra200 - OS: Linux 2.6.29-arm2/armv7l - Distro: Gentoo 1.12.13 - CPU: ARMv7 rev 0 (v7l) - Processes: 73 - Uptime: 15h 3m - Users: 1 - Load Average: 0.00 - Memory Usage: 30.18MB/629.16MB (4.80%) - Disk Usage: 1.57GB/7.66GB (20.46%) | 21:40 |
armin76 | *g* | 21:40 |
* armin76 laughs at NCommander | 21:41 | |
armin76 | *g* | 21:41 |
NCommander | armin76: I've been 0wned | 21:41 |
Martyn | Linux tegra2 2.6.29-arm2 #1 SMP PREEMPT Fri Mar 26 15:33:45 CDT 2010 armv7l GNU/Linux | 21:41 |
armin76 | yey | 21:41 |
NCommander | armin76: I'll come back and surpass you soon | 21:41 |
armin76 | Linux tegra200 2.6.29-arm2 #4 SMP PREEMPT Sat Mar 27 10:46:32 GMT 2010 armv7l ARMv7 Processor rev 0 (v7l) Tegra generic GNU/Linux | 21:41 |
* NCommander has seem some amazing hardware in the pipe | 21:41 | |
armin76 | NCommander: from who? | 21:42 |
Martyn | NCommander : But you'll never TOUCH what I've got in the pipe :) | 21:42 |
Martyn | NCommander : At least, not until and unless you get better connections that direct-from-ARM :) | 21:42 |
* nosse1 thinks ARM soon catches up with IA CPUs | 21:42 | |
Martyn | nosse1 : No, I think IA32 will still be ahead in raw performance for a while | 21:42 |
armin76 | Martyn: how much ram do you have? | 21:42 |
nosse1 | Martyn: As well as the Atom product line? | 21:43 |
Martyn | nosse1 : Getting 28nm foundries is one thing, and also there's a long way to go before arm supports things like 40 bit memory space, a /good/ floating point unit, and there are a lot of changes needed to get close to some of the base performance the IA32 gets with it's CISC architecture for some kinds of math | 21:43 |
armin76 | binutils took 9m to build, vs 4m on a dual core atom 330 | 21:44 |
Martyn | armin76 : On tegra2 -- 1GB, 128 megs of which is taken by video and there are other issues : MemTotal: 644024 kB | 21:44 |
armin76 | compared to the 30m it took on the efika mx | 21:44 |
nosse1 | We considered atom in our product, but the hw cost and complexity is much higher than any ARM system | 21:44 |
armin76 | Martyn: same as me then :) | 21:44 |
Martyn | armin76: On ( unpublished platform ) we have 3196 MB of ram available, and a full 2M of L2 cache | 21:45 |
armin76 | Martyn: the difference is that i run a better distro than you *g* | 21:45 |
armin76 | j/k | 21:45 |
Martyn | it's much more powerful | 21:45 |
Martyn | and it uses DDR3 ram | 21:45 |
armin76 | sounds fun, thats the server thing? | 21:45 |
Martyn | armin76 : I'm on lucid half the time, karmic the other half... | 21:45 |
Martyn | armin76 : That's our chip (smooth-stone) which will probably be available at the end of the year | 21:46 |
armin76 | what will be it useful for? | 21:46 |
rsalveti | man, you got so much ram! | 21:46 |
Martyn | armin76: Data center .. it's a -server- chip, not a tablet chip | 21:46 |
Martyn | armin76 : It's meant to bring ARM to the server market, where people are huring for power | 21:46 |
Martyn | you can stick 10 of our chips in a cluster where you can only run one core2quad | 21:47 |
rsalveti | Martyn: cool, didn't think that arm would head to server side so quickly :-) | 21:47 |
Martyn | so with our chip, you get 40 cores for the same power as one quad-core intel chip | 21:47 |
nosse1 | I'm coming here with my newly aquired Audi (which I'm proud of), and then you guys are swining Ferraris and Bugatties... *sigh* I can't compete | 21:47 |
nosse1 | :D | 21:48 |
rsalveti | hahaha, same feeling | 21:48 |
Martyn | although generation 1 chips from us will suffer from a memory limitation (only 3.5 GB of accesible memory per chip .. that's a limitation of the Cortex A9) | 21:48 |
armin76 | rsalveti: i got 3G on a marvell board! :) | 21:48 |
Martyn | but that won't matter ... | 21:48 |
armin76 | Martyn: but that server, what would it be used for, for example? webpages? | 21:48 |
rsalveti | armin76: cool :-) | 21:49 |
armin76 | rsalveti: Hostname: ganesha - OS: Linux 2.6.31-01335-g86d7101/armv5tel - Distro: Gentoo 2.0.1 - CPU: Feroceon rev 0 (v5l) - Processes: 78 - Uptime: 158d 19h 19m - Users: 2 - Load Average: 1.25 - Memory Usage: 286.34MB/3042.39MB (9.41%) - Disk Usage: 5.40GB/20.73GB (26.06%) | 21:49 |
armin76 | :) | 21:49 |
rsalveti | argh! haha :-) | 21:50 |
rsalveti | I just have a sheevaplug! and that's a very old hardware comparing to these | 21:50 |
Martyn | armin76 : Think .. hadoop cluster with 8196 cores, 8 TB of RAM, 64TB of SSD storage.... | 21:51 |
rsalveti | but at work I can play with a more interesting board, the ste u8500 :-) | 21:51 |
Martyn | All in .. say .. half a rack? | 21:51 |
rsalveti | Martyn: hahaha, man, that's something :D | 21:51 |
Martyn | maybe a full rack if you want it to run nice and cool? | 21:51 |
Martyn | Yeah .. that's what we're after, and we're at least a full year ahead of anyone else. | 21:52 |
armin76 | i see | 21:55 |
=== JaMa|Off is now known as JaMa | ||
Sarvatt | lool or NCommander - incase you didn't see my message in #ubuntu-x i fixed up xserver-xorg-video-dove to work with xserver 1.7+ and brought in all the fbdev changes since it was forked incase its useful: http://sarvatt.com/downloads/patches/xserver-xorg-video-dove.diff | 22:36 |
samuel_Sayag | hello, can I load xfce on the beagle did someone tried it ? | 23:07 |
=== JaMa is now known as JaMa|Zzzz | ||
rcn-ee | samuel_Sayag, yes.. and it's more responsive then gnome.. | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!