**** BEGIN LOGGING AT Wed Feb 18 02:59:57 2009
Feb 18 12:38:51 <WyrM> hi.
Feb 18 12:41:21 <WyrM> is suspend/resume working with current linus kernel on palm pxa27x devices?
Feb 18 13:42:37 <WyrM> hi marex.
Feb 18 13:42:51 <WyrM> is suspend/resume working with current linus kernel on palm pxa27x devices?
Feb 18 13:43:24 <Sleep_Walker> WyrM: hi
Feb 18 13:43:37 <Sleep_Walker> it depends from device to device
Feb 18 13:43:41 <marex> WyrM, hi, on palmt5 it's working completely with ycmiao's kernel tree (patch-tracking KT)
Feb 18 13:43:51 <marex> WyrM, see RTFM from topic for a link
Feb 18 13:44:18 <Sleep_Walker> oh, pure linus' kernel?
Feb 18 13:44:42 <WyrM> not pure.
Feb 18 13:44:49 <marex> impure !
Feb 18 13:44:53 <WyrM> but a kernel that is based at least on .28 :)
Feb 18 13:44:54 <marex> :D
Feb 18 13:45:12 <marex> WyrM, see RTFM for a link, navigate to devel branch, there it is
Feb 18 13:45:22 <Sleep_Walker> well, Treo680 is not working yet :(
Feb 18 13:45:22 <marex> dunno if Eric already pushed it into LAKT
Feb 18 13:46:23 <WyrM> any needed changes to resume code?
Feb 18 13:46:27 <WyrM> I can't resume on EZX.
Feb 18 13:47:07 <WyrM> the kernel just freezes, and it is very hard to trace where it stops (no framebuffer, no usb, no nothing) :(
Feb 18 13:47:49 <marex> WyrM, well porting it to EZX would be hard
Feb 18 13:48:10 <marex> suspend-to-mem (that is - resuming using bootloader) is platform dependent
Feb 18 13:48:38 <WyrM> I can see that the bootloader gave control to kernel on resume with an asm hack on pxa_cpu_resume on sleep.S
Feb 18 13:48:42 <marex> you can try doing "cough-cough" to the bootloader using arm-something-objdump
Feb 18 13:48:52 <marex> ah I see
Feb 18 13:49:09 <marex> so you can clearly see it jumped back to kernel on resume ?
Feb 18 13:49:18 <WyrM> I hacked my bootloader to resume the linux way (resume address stored on PSPR), it is working.
Feb 18 13:49:31 <marex> so what's the issue ?
Feb 18 13:49:44 <WyrM> the kernel stops somewhere.. :)
Feb 18 13:50:14 <marex> well do you have some indication the loader at least passes control back to linux ?
Feb 18 13:50:23 <WyrM> I found pointers on lakml about GPDR/GADR restore ordering issues.
Feb 18 13:50:29 <marex> of you do know it happens, you are probably facing some memory corruption from the loader
Feb 18 13:50:31 <WyrM> but it doesn't seems to help.
Feb 18 13:51:08 <WyrM> no, my bootloader is hacked and it does not write anything to memory.
Feb 18 13:51:35 <WyrM> it just branches to whatever is stored on PSPR if the reset cause is a resume.
Feb 18 13:52:56 <marex> WyrM, wasnt there something like "do not blank FB on suspend ?
Feb 18 13:53:03 <marex> WyrM, lemme take a look
Feb 18 13:53:16 <WyrM> good idea.
Feb 18 13:53:44 <alegra> hi
Feb 18 13:53:47 <WyrM> I remember this a long ago, on .16 or something.. (btw, my resume worked with older kernels).
Feb 18 13:54:13 <marex> WyrM, yup ... that was it back then
Feb 18 13:54:36 <marex> WyrM, pxafb went through a lot of changes, but I suppose pxafb_blank() is what you are looking for
Feb 18 13:56:19 <marex> WyrM, hang on ... that was also some config option in debug
Feb 18 14:00:24 <marex> dang, cant find the right one now
Feb 18 14:00:56 <WyrM> I can't find the old config option to not blank the frame buffer. :/
Feb 18 14:01:42 <WyrM> its a pain to debug, im currently corrupting memory to debug and see how far the kernel goes..
Feb 18 14:02:07 <WyrM> as my RAM is preserved even after some seconds without battery.
Feb 18 14:02:29 <marex> jeez, yes, that happens but anyway ;)
Feb 18 14:02:41 <marex> WyrM, cant you use serial console ?
Feb 18 14:02:48 <marex> (or jtag)
Feb 18 14:03:14 <WyrM> no, I would need to use SPI to enable a serial console or USB.
Feb 18 14:03:22 <WyrM> and the kernel doesn't go that far :)
Feb 18 14:03:39 <WyrM> jtag would work.
Feb 18 14:03:52 <marex> ah yes, that USB thingamie, I recall ezx has something like that ...
Feb 18 14:04:02 <WyrM> but I have no jtag adapter here, and also I don't want to solder stuff to the phone board .
Feb 18 14:05:23 <marex> WyrM, just a silly question, but I suppose it cant be some driver causing problems with resume, right ?
Feb 18 14:05:33 <WyrM> yes, its possible.
Feb 18 14:05:43 <marex> try stripping down the kernel as much as possible then
Feb 18 14:05:44 <WyrM> I will try disabling most stuff I can.
Feb 18 14:05:49 <marex> right
Feb 18 14:06:03 <marex> since if it worked for you before, it's weird
Feb 18 14:06:10 <WyrM> but I still need a lot of drivers to get usb working to get a console.
Feb 18 14:06:48 <WyrM> it worked a long ago, and I have no idea when it stopped.
Feb 18 14:06:50 <WyrM> :/
Feb 18 14:07:09 <marex> WyrM, dont you have framebuffer ?
Feb 18 14:07:26 <marex> pxafb should work
Feb 18 14:07:56 <WyrM> then I need to figure a way to send the phone to suspend, without using the console :)
Feb 18 14:08:22 <marex> use initramfs with busybox
Feb 18 14:08:22 <WyrM> as Im currently writing "mem" to /sys/power/state.
Feb 18 14:08:38 <marex> yup, you can compile initramfs right into kernel image
Feb 18 14:27:43 <WyrM> marex: the kernel that resumes successfully on palm, has cpufreq support on .config?
Feb 18 14:28:10 <marex> yes, but throwing it out will help you in debuging as well
Feb 18 14:29:12 <WyrM> 2 months ago a kernel without cpufreq was freezing on boot.
Feb 18 14:29:18 <WyrM> at "freeing init memory".
Feb 18 14:32:08 <WyrM> same state.
Feb 18 14:32:31 <WyrM> if I remove cpufreq the kernel boots up to "Freeing init memory" and freezes.
Feb 18 14:34:18 <marex> something's very wrong in your setup then
Feb 18 14:34:35 <marex> you'd better start by fixing this
Feb 18 14:34:47 <marex> it might be just an issue of a improper GPIO setup (see MFP)
Feb 18 14:35:10 <WyrM> what's the relation of cpufreq and mfp?
Feb 18 14:35:41 <WyrM> it may also be something on the rootfs.
Feb 18 14:36:15 <WyrM> as it mounts the rootfs, and then freezes with no error message.
Feb 18 14:36:38 <WyrM> I will just leave cpufreq enabled for now :)
Feb 18 14:43:10 <marex> WyrM, cpufreq might hang the boot as well since it's reseting the CPU powerstate at resume
Feb 18 14:43:37 <marex> throw away everything you dont need ... if it doesnt work without cpufreq, something it really wrong
Feb 18 14:46:10 <WyrM> everything seems to work without cpufreq, I can see the mmc being recognized and mounted, the usb works, everything works.
Feb 18 14:46:33 <WyrM> except that when it loads /bin/init it freezes,
Feb 18 14:51:25 <WyrM> I will try without cpufreq, and with init=/bin/sh on the cmdline
Feb 18 14:56:11 <WyrM> no luck, still freezes :/
Feb 18 15:03:37 <marex> you might have some console-related issue then
Feb 18 15:03:51 <marex> I know this problem can happen and I already saw it
Feb 18 15:03:55 <WyrM> lol.
Feb 18 15:04:00 <WyrM> this is really weird.
Feb 18 15:04:05 <marex> never in relation with cpufreq though
Feb 18 15:04:06 <WyrM> and very fishy.
Feb 18 15:04:20 <WyrM> I enabled user_debug on the kernel cmdline.
Feb 18 15:04:29 <WyrM> and it DOES NOT freeze without cpufreq.
Feb 18 15:04:49 <WyrM> console is pxafb.
Feb 18 15:05:00 <WyrM> it seems more like some scheduling issue.
Feb 18 15:05:18 <WyrM> now it freeze just after loading portmap.
Feb 18 15:07:37 <WyrM> sorry about the reconnects btw, ubuntu seems crazy, reconfiguring eth0 every time I reconnect usb0.
Feb 18 15:07:39 <WyrM> lol.
Feb 18 15:12:46 <Sleep_Walker> old version of NetworkManager? :b
Feb 18 15:13:00 <WyrM> its up-to-date.
Feb 18 15:13:22 <WyrM> don't know why this is happening. :/
Feb 18 15:13:54 <Sleep_Walker> it happened to me with some older versions
Feb 18 15:14:20 <Sleep_Walker> now I've got usb0 not driven by NM, but automatic configuration by YaST
Feb 18 15:23:54 <WyrM> I enabled a lot of debugging output, but still nothing useful about the no-cpufreq freeze.
Feb 18 15:36:28 <marex> Sleep_Walker, SuSE is fucked up ... another shitty distro joins my ubuntu-distro-blacklist
Feb 18 15:36:43 <marex> now actually suse-ubuntu-distro-blacklist
Feb 18 15:38:05 <Sleep_Walker> marex: fault was on your side...
Feb 18 15:38:19 <marex> Sleep_Walker, no, fault was on suse side
Feb 18 15:38:41 <Sleep_Walker> marex: SuSE != Debian != Windows
Feb 18 15:39:02 <marex> Sleep_Walker, right ... but I doubt transitiveness
Feb 18 15:39:49 <Sleep_Walker> marex: fcuk :b
Feb 18 15:40:09 <Sleep_Walker> marex: SuSE != Windows != Debian
Feb 18 15:40:18 <Sleep_Walker> that should be enough
Feb 18 15:40:32 <Sleep_Walker> you can't use Windows same way as Debian
Feb 18 15:40:42 <Sleep_Walker> you can't use SuSE same way as Debian
Feb 18 15:40:44 <marex> suse (is much worse than) windows (which is much worse than) debian
Feb 18 15:40:47 <marex> right
Feb 18 15:41:14 <marex> you cant use SuSE. that should be enough
Feb 18 15:41:19 <Sleep_Walker> marex: that's different relation which I didn't speak about
Feb 18 15:41:30 <marex> or rather my parents cant, because it screws itself up randomly
Feb 18 15:41:31 <Sleep_Walker> marex: _I_ can ;)
Feb 18 15:41:41 <WyrM> lol
Feb 18 15:41:42 <Sleep_Walker> _YOU_ can't
Feb 18 15:41:52 <WyrM> you can't compare windows to any linux distro.
Feb 18 15:41:55 <marex> Sleep_Walker, _I_ dont use that notebook anymore
Feb 18 15:42:05 <WyrM> you will go to hell for doing that.
Feb 18 15:42:36 <Sleep_Walker> WyrM: that's fine, I can now rape small children without fear...
Feb 18 15:43:05 <Sleep_Walker> :D
Feb 18 15:43:13 <Sleep_Walker> WyrM: that's fine, I can now rape small children without fear...
Feb 18 15:43:46 <WyrM1> rtfl :D
Feb 18 15:55:04 <WyrM1> no clue for the cpufreq issue.
Feb 18 15:55:33 <WyrM1> I will change the gcc version as a last try. :/
Feb 18 15:56:33 <marex> WyrM1, what version did you used to compile the kernel ?
Feb 18 15:56:52 <marex> it seems that <= 4.1 generated broken code in some cases
Feb 18 15:57:28 <WyrM1> was using:
Feb 18 15:57:28 <WyrM1> arm-angstrom-linux-gnueabi-gcc (GCC) 4.1.2
Feb 18 15:57:28 <WyrM1> will try with:
Feb 18 15:57:28 <WyrM1> arm-none-eabi-gcc (Sourcery G++ Lite 2008q3-66) 4.3.2
Feb 18 15:58:04 <WyrM1> rootfs was built with the older one.
Feb 18 15:59:40 <WyrM1> LOL
Feb 18 15:59:49 <WyrM1> it works with the newer gcc.
Feb 18 16:00:05 <WyrM1> it was really a gcc issue.
Feb 18 16:00:24 <WyrM1> now I can try resume without cpufreq. :)
Feb 18 16:00:48 <WyrM1> No, it won't work.
Feb 18 16:00:52 <WyrM1> freeze on portmap.
Feb 18 16:15:13 <WyrM1> back to the old write to ram debug :(
Feb 18 16:20:45 <marex> WyrM1, cant you flash leds or something ?
Feb 18 16:21:08 <WyrM1> heh, if I was sure that spi was working...
Feb 18 16:21:09 <marex> or wait ... you are writing to the memory from linux and then reading that ?
Feb 18 16:21:17 <WyrM1> yes.
Feb 18 16:21:25 <marex> oh my :)
Feb 18 16:21:30 <WyrM1> I read it after removing/placing the battery
Feb 18 16:22:09 <WyrM1> lots of "*(unsigned long *)(phys_to_virt(0xa0000000)) =" on the code. ;)
Feb 18 16:22:49 <marex> jeez
Feb 18 16:43:12 <WyrM1> heh, ugly but this works ;)
Feb 18 16:44:02 <WyrM1> pxa27x_cpu_pm_finish() is called.
Feb 18 16:45:16 <WyrM1> what is the normal resume code path?
Feb 18 16:45:28 <WyrM1> what should I check after pm_finish()?
Feb 18 16:53:23 <WyrM1> kernel/power/main.c
Feb 18 17:00:17 <WyrM1> *(unsigned long *)(phys_to_virt(0xa0000000)) = 0x00000014;
Feb 18 17:00:17 <WyrM1>         device_resume(PMSG_RESUME);
Feb 18 17:00:17 <WyrM1> *(unsigned long *)(phys_to_virt(0xa0000000)) = 0x00000015;
Feb 18 17:00:27 <WyrM1> it freezes here.
Feb 18 17:00:37 <WyrM1> between 14 and 15 :)
Feb 18 17:02:07 <marex> well it calls device_resume, you should dig further in there
Feb 18 17:02:21 <WyrM1> sure.
Feb 18 17:02:32 <WyrM1> as soon as I figure out where it is declared.
Feb 18 17:02:36 <WyrM1> lol
Feb 18 17:03:11 <marex> there was some project for it - linux identifier search
Feb 18 17:04:44 <WyrM1> drivers/base/power/main.c
Feb 18 17:05:26 <WyrM1> its indeed some driver that is failing.
Feb 18 17:06:12 <marex> WyrM1, see, I told you
Feb 18 17:06:32 <WyrM1> since it works for you, I think I can probably eliminate whatever drivers you use.
Feb 18 17:06:35 <marex> hey, hang on ... do you recall that platform_driver device_driver platform_device etc. mess ?
Feb 18 17:07:10 <WyrM1> lets see, you use pxa-mmc and pxa27x-udc, correct?
Feb 18 17:07:13 <marex> WyrM1, use only those drivers that are in kernel (that is - pxafb), you probably dont need anything else
Feb 18 17:07:17 <marex> suspend should work then
Feb 18 17:07:31 <marex> WyrM1, throw them away as well, you dont need them with initramfs
Feb 18 17:08:05 <WyrM1> heh, but I need to trace where its failing, I need suspend/resume working with all the drivers :/
Feb 18 17:08:25 <marex> WyrM1, right ... so you will be adding them back one after another
Feb 18 17:08:29 <WyrM1> ahh, I think I have a clue.
Feb 18 17:08:41 <WyrM1> I think its probably my TS driver.
Feb 18 17:08:52 <marex> I see ... is the code available somewhere ?
Feb 18 17:09:30 <WyrM1> as it has PM support, but depends on my MFD driver, which has no PM support currently, and probably the .parent is not being handled correctly.
Feb 18 17:09:46 <WyrM1> yes, my code is at http://git.openezx.org/openezx.git
Feb 18 17:09:52 <WyrM1> the ezx/current branch
Feb 18 17:10:40 <marex> WyrM1, which driver is it ?
Feb 18 17:10:55 <WyrM1> input/touchscreen/pcap_ts.c
Feb 18 17:11:05 <WyrM1> and drivers/mfd/ezx-pcap.c
Feb 18 17:11:17 <WyrM1> pcap is a multi function ASIC.
Feb 18 17:11:30 <WyrM1> and the TS is a subdriver of the ezx-pcap.c driver.
Feb 18 17:12:14 <WyrM1> im trying with the TS driver out.
Feb 18 17:13:00 <marex> remove the whole asic maybe
Feb 18 17:13:16 <WyrM1> if I do, everything else would need to be removed.
Feb 18 17:13:35 <marex> (platform driver seems fine to me ... dunno if the ezx_pcap_read() cant die after resume - that is in case the ASIC doesnt kick in)
Feb 18 17:13:36 <WyrM1> as USB, MMC, sound, etc.. are all dependent on this asic
Feb 18 17:13:57 <WyrM1> I think it's a ordering issue.
Feb 18 17:14:18 <WyrM1> as the whole SPI subsystem needs to be ready before the TS driver resumes.
Feb 18 17:16:22 <marex> WyrM1, well I still dont see a point in having such a pile of drivers compiled in
Feb 18 17:16:39 <WyrM1> its how I develop.
Feb 18 17:16:47 <WyrM1> I send the kernel directly to RAM.
Feb 18 17:16:57 <marex> if I were to debug such issue, I'd remove everything and left only framebuffer
Feb 18 17:17:10 <WyrM1> easier to have everything built-in, so I don't need to edit my rootfs every time.
Feb 18 17:17:22 <marex> then I'd suspend-resume using initramfs (or kernel/main.c, see there how to suspend without any fs)
Feb 18 17:17:35 <WyrM1> I would need to build a initramfs.
Feb 18 17:17:35 <marex> errr .... init.c
Feb 18 17:17:38 <WyrM1> im lazy :)
Feb 18 17:18:07 <marex> and then add the drivers one after another to precisely pinpoint which on is the bad one
Feb 18 17:18:17 <marex> hm ... well it's your suffering ;-)
Feb 18 17:23:31 <WyrM1> now I don't get a resume at all.
Feb 18 17:23:33 <WyrM1> weird.
Feb 18 17:23:50 <WyrM1> not even the debug at sleep.S early resume.
Feb 18 17:24:17 <WyrM1> oh, maybe my only wakeup source was the ts driver. :/
Feb 18 17:25:13 <marex> WyrM1, you can set GPIO[0-15] as a wakeup source so map some button
Feb 18 17:27:08 <WyrM1> I have no buttons connected to these gpios.
Feb 18 17:28:39 <WyrM1> I will leave the ts driver in, and remove just the resume code.
Feb 18 17:28:43 <WyrM1> easier :)
Feb 18 17:31:41 <marex> WyrM1, how come it resumes from it ?
Feb 18 17:31:56 <marex> WyrM1, where must be a "display touched" GPIO, use that one
Feb 18 17:32:02 <marex> s/w/t/
Feb 18 17:32:19 <WyrM1> well, I think that its not only 0-15 gpios which may be configured as wake-up.
Feb 18 17:32:26 <WyrM1> im not sure :)
Feb 18 17:32:59 <WyrM1> the keys on this device are using the pxa matrix keypad driver.
Feb 18 17:33:10 <WyrM1> with keys on gpio93 and higher.
Feb 18 17:34:33 <WyrM1> good, now it resumes again, but still freezes, so its not the ts driver :/
Feb 18 17:34:48 <WyrM1> there is no resume code on the ezx-pcap.c driver, so it can't be it either.
Feb 18 17:37:08 <WyrM1> how do I set correct dependency chain for suspend resume?
Feb 18 17:37:35 <WyrM1> I want SPI to be resumed before USB and MMC, how do I do that?
Feb 18 17:39:50 <WyrM1> btw, do you use pxa2xx-spi on palm?
Feb 18 17:40:12 <WyrM1> I suspect it's the issue.
Feb 18 17:40:47 <WyrM1> previously, when I had suspend/resume working, I was not using the pxa2xx-spi driver, I was using arch/arm/mach-pxa/ssp.c directly
Feb 18 17:42:56 <WyrM1> now I disabled sound driver, and added debug code to pxa2xx_spi resume...
Feb 18 17:47:11 <WyrM1> no, spi resume gets executed ok :/
Feb 18 17:48:33 <WyrM1>         GPIO12_GPIO | WAKEUP_ON_LEVEL_HIGH,
Feb 18 17:48:46 <WyrM1> is this enough to make the pin a wakeup source?
Feb 18 17:51:22 <marex> WyrM1, see how palmt5 resumes
Feb 18 17:51:34 <marex> WyrM1, you have to preserve power levels in some GPIOs
Feb 18 17:51:37 <marex> at least on T5
Feb 18 17:52:20 <WyrM1> gpio12 is an input gpio.
Feb 18 17:52:29 <WyrM1> for the phone's flip.
Feb 18 17:53:55 <WyrM1> I use it with the gpio_keys driver
Feb 18 17:59:09 <WyrM1> does palmtx resumes on any key?
Feb 18 18:17:03 <marex> pxa27x-matrix can be used as a wakeup source, yes (see PKWR)
Feb 18 18:17:26 <WyrM1> how do I do it?
Feb 18 18:17:33 <WyrM1> setting pkwr directly?
Feb 18 18:49:01 <cuddlefish> my TX will not boot linux. it says it cannot mount the rootfs...
Feb 18 18:49:21 <cuddlefish> any suggestions?
Feb 18 18:50:45 <cuddlefish> i have tried cocoaboot and garux...
Feb 18 18:51:33 <cuddlefish> i have been following handhelds.org's BinaryHowTo
Feb 18 18:51:41 <WyrM> maybe you should setup your rootfs, on whatever place the kernel expects it to be.
Feb 18 18:52:00 <cuddlefish> yeah, I copied opie-rootfs
Feb 18 18:52:21 <cuddlefish> now I'm trying to grok the default linux.boot.cfg
Feb 18 18:54:37 <cuddlefish> wait, does the kernel support SDHC?
Feb 18 18:55:05 <Sleep_Walker> sure
Feb 18 18:55:18 <cuddlefish> ok, good.
Feb 18 18:57:02 <cuddlefish> let's try again...
Feb 18 19:00:17 <cuddlefish> cocoboot returned c01d
Feb 18 19:03:37 <Mba7eth> hi guys ..... how can i unlock my hauwei mobile modem
Feb 18 19:06:56 <cuddlefish> Could someone walk me through it, since I'm obviously doing sumting wrong?
Feb 18 19:21:58 <cuddlefish> ...
Feb 18 20:14:08 <cuddlefish> ok, I'm back...
Feb 18 20:14:32 <cuddlefish> my TX will not boot linux. it says it cannot mount the rootfs...
Feb 18 20:15:12 <cuddlefish> and the exact error is...
Feb 18 20:15:34 <cuddlefish> Loading /zImage... 1292432 b OK.
Feb 18 20:15:52 <cuddlefish> Loading /initrd.gz... 147456b OK.
Feb 18 20:15:59 <cuddlefish> Returned: c01d
Feb 18 20:16:29 <cuddlefish> then the command line options are "init=/linuxrc root=/dev/ram0
Feb 18 20:17:15 <Sleep_Walker> cuddlefish: which version of cocoboot do you have?
Feb 18 20:17:27 <cuddlefish> 0.3
Feb 18 20:17:34 <cuddlefish> the one comes w/ the package
Feb 18 20:17:41 <Sleep_Walker> cuddlefish:
Feb 18 20:17:42 <Sleep_Walker> version 0.4:
Feb 18 20:17:44 <Sleep_Walker>   - Fixed 'c01d' error introduced in 0.3 on LD, TX etc.
Feb 18 20:17:53 <cuddlefish> b'Doh!
Feb 18 20:17:54 <Sleep_Walker> just grab newest coco
Feb 18 20:18:22 * cuddlefish bangs head against wall hard
Feb 18 20:18:39 <Sleep_Walker> that happens
Feb 18 20:18:48 <Sleep_Walker> cuddlefish: was it |miska|'s package?
Feb 18 20:19:04 <cuddlefish> yep
Feb 18 20:19:14 <Sleep_Walker> |miska|: could you please fix your release?
Feb 18 20:19:47 <Sleep_Walker> cuddlefish: sorry for late answer - I'm still at work :(
Feb 18 20:20:22 <cuddlefish> it's ok. I'm still asleep after an incident last night involving root beer and motherboards :-(
Feb 18 20:20:33 <|miska|> Oh, seems like an easy fix, will take a look at it
Feb 18 20:20:38 <cuddlefish> ok, recieving file...
Feb 18 20:21:14 <|miska|> During the weekend
Feb 18 20:21:22 <Sleep_Walker> of course :)
Feb 18 20:21:28 <|miska|> Writing to todo now
Feb 18 20:21:59 <marex> cuddlefish, http://hackndev.com/node/269
Feb 18 20:22:06 <marex> download 0.6.0 there
Feb 18 20:22:30 <Sleep_Walker> yeah, we need to hunt bugs on current version :b
Feb 18 20:23:29 <cuddlefish> Whee! Boot screen!
Feb 18 20:23:34 <cuddlefish> Thanks to everyone!
Feb 18 20:23:40 <Sleep_Walker> enjoy
Feb 18 20:24:06 <cuddlefish> interesting logo.
Feb 18 20:24:20 <cuddlefish> hey, cool voice!
**** ENDING LOGGING AT Thu Feb 19 02:59:57 2009