**** BEGIN LOGGING AT Sat Dec 19 02:59:56 2009
Dec 19 03:12:24 <KenYoung> ping raster
Dec 19 06:27:45 <raster> kennyz:  boo
Dec 19 06:27:50 <raster> oops
Dec 19 06:27:54 <raster> tab-complete wrong...
Dec 19 06:42:51 <rhkfin> fail
Dec 19 06:43:35 <rhkfin> so once again - is anyone using shr-testing and could tell me the good, the bad and the ugly of it..?
Dec 19 10:41:16 <panicking> PaulFertser, hi
Dec 19 10:41:23 <panicking> can you take a look of this patch?
Dec 19 10:41:24 <PaulFertser> panicking: hey
Dec 19 10:41:50 <PaulFertser> panicking: i can try to look at it right now, yes. Not promising i have enough skills to do anything useful but still :)
Dec 19 10:42:07 <PaulFertser> panicking: btw, can you tell me a little about FCSE? 
Dec 19 10:42:17 <PaulFertser> panicking: did you manage to get any measureable benefits?
Dec 19 10:42:19 <panicking> http://pastebin.com/m2774c980
Dec 19 10:44:56 <panicking> this is the other one
Dec 19 10:44:57 <panicking> http://pastebin.com/m48cfe9d5
Dec 19 10:45:05 <PaulFertser> panicking: ok, will look at it right now, thanks a lot
Dec 19 10:45:15 <panicking> I think that the next is not good in general
Dec 19 10:45:32 <panicking> When the system is poweroff I don't want
Dec 19 10:45:36 <panicking> wake up for alarm
Dec 19 10:45:50 <panicking> Does the people use alarm to poweron the mobile?
Dec 19 10:46:39 <PaulFertser> panicking: i think mostly no, they use alarm to wake from suspend.
Dec 19 10:47:20 <panicking> I'm scared about application that set an RTC_ALARM and we don't wake
Dec 19 10:47:26 <panicking> up for poweroff
Dec 19 10:47:54 <panicking> so the second patch avoid power on on rtc alarm
Dec 19 10:48:37 <PaulFertser> panicking: can you please rephrase the last statement?
Dec 19 10:49:08 <panicking> When you power off the device with the second patch
Dec 19 10:49:14 <panicking> the system doen't wake up
Dec 19 10:49:32 <panicking> for a pending (bogus) rtc alarm set by some application
Dec 19 10:49:47 <panicking> that basiscally is used for suspend
Dec 19 10:50:02 <PaulFertser> panicking: why can an application set a bogus alarm?
Dec 19 10:50:25 <panicking> for example android set rtc alarm for advice of incoming sms
Dec 19 10:50:31 <panicking> to wake up for suspend
Dec 19 10:50:34 <panicking> mms
Dec 19 10:50:44 <panicking> or somenthig to advice the user
Dec 19 10:50:47 <panicking> you have somenthing
Dec 19 10:51:03 <panicking> it can be used for reapet vibrate
Dec 19 10:51:06 <panicking> led blink
Dec 19 10:51:07 <panicking> etc
Dec 19 10:51:18 <PaulFertser> panicking: so why doesn't it disable it before powering off?
Dec 19 10:51:18 <panicking> but if you shutdown the device
Dec 19 10:51:43 <panicking> because the expecting beahvior of the framework is to wakeup
Dec 19 10:51:49 <panicking> for suspend and not for poweroff
Dec 19 10:51:53 <panicking> I would like to know
Dec 19 10:52:05 <panicking> if this beahvior is the same in other distribuition
Dec 19 10:53:05 <PaulFertser> panicking: when you shutdown the device usual way you have enough hooks both in userspace and in the kernel to do the necessary cleanup, right?
Dec 19 10:53:47 <PaulFertser> panicking: if the framework expects to be able to turn the device on with RTC alarm, it should just work. If it doesn't want that, it should disable the alarm on shutdown. What is the problem?
Dec 19 10:54:01 <panicking> ok, 
Dec 19 10:54:05 <panicking> I understand
Dec 19 10:54:15 <panicking> and what do you think about the first one patch
Dec 19 10:54:16 <panicking> ?
Dec 19 10:54:34 <panicking> is it correct the new mask
Dec 19 10:54:35 <panicking> ?
Dec 19 10:56:38 <PaulFertser> panicking: (qi patch) 0xd3 there looks definetely bogus, since exton1 is tied to VB_SYS. And yet have you seen the device waken up by that? It's tied to VB_SYS hard, where can a glitch come from?
Dec 19 10:57:24 <PaulFertser> panicking: i mean the patch looks perfectly correct but the mistake should be harmless anyway.
Dec 19 10:57:26 <panicking> Yes, but sometimes people report wakeup. So the reason can be
Dec 19 10:57:32 <panicking> a wrong RTC clock
Dec 19 10:57:34 <gena2x> hi, guys. have a problem on shr-unstable upgrade: [/usr/lib/opkg/info/phonefsod.postinst: line 7: update-rc.d: not found], anyone know how where update-rc.d?
Dec 19 10:57:35 <panicking> or a glitch
Dec 19 10:57:45 <PaulFertser> panicking: just the comment should be altered.
Dec 19 10:57:59 <PaulFertser> panicking: i doubt there can be a glitch on a 10k-tied line.
Dec 19 10:58:26 <PaulFertser> panicking: also if you say "wakeup" it most probably comes from e.g. wifi WOL rather than exton1.
Dec 19 10:58:43 <PaulFertser> panicking: the kernel already has enough diagnostics to be able to tell for sure the wakeup reason, you know.
Dec 19 10:58:57 <panicking> yes I know, but I can't answer to the user
Dec 19 10:59:02 <panicking> take a look on the sysfs
Dec 19 10:59:07 <panicking> and report me the reason
Dec 19 10:59:25 <PaulFertser> panicking: why?
Dec 19 10:59:26 <panicking> ok so the glitch is impossible
Dec 19 10:59:39 <PaulFertser> panicking: A has no sysfs mounted or what?
Dec 19 10:59:42 <panicking> Because I want that gta02 can be used as a mobile
Dec 19 10:59:54 <panicking> not only for people that want to 
Dec 19 11:00:00 <panicking> cat sysfs
Dec 19 11:00:03 <PaulFertser> panicking: so you compile out sysfs support or what?
Dec 19 11:00:04 <panicking> yes is mounted
Dec 19 11:00:07 <PaulFertser> :)))
Dec 19 11:00:55 <gena2x> panicking: Same mistake om did. They target geek phone to ordinary people.
Dec 19 11:00:55 <panicking> This is my idea:
Dec 19 11:01:17 <PaulFertser> panicking: wifi wol would be interesting to debug in fact.
Dec 19 11:01:27 <PaulFertser> panicking: it's one of the things i wanted to do myself but was too lazy.
Dec 19 11:01:47 <panicking> Can you describe the situation?
Dec 19 11:02:04 <panicking> On thusday I will receive a new debug board
Dec 19 11:02:04 <PaulFertser> panicking: but from what i saw it looks quite possibly for it to work and it looks like when wifi is off it can produce spurious wake-ups, i saw the code and schematics.
Dec 19 11:02:11 <panicking> so I can work on 2.6.3x
Dec 19 11:04:03 <panicking> Ok, so why put in out
Dec 19 11:04:09 <panicking> the pin during suspend
Dec 19 11:04:09 <panicking> ?
Dec 19 11:05:46 <panicking> gena2x, the error was to have a mobile that was not stable
Dec 19 11:05:48 <panicking> for 2 year
Dec 19 11:05:57 <panicking> in hw and sw
Dec 19 11:07:29 <SpeedEvil> sw mainly
Dec 19 11:07:44 <SpeedEvil> gta01 was - pretty much - usable as a phone from a hw pov 
Dec 19 11:08:21 <SpeedEvil> some minor tweaks would have been nice - but the software stack - the UI - in march 2007 was usableish - though needed a tiny bit of fixing - for basic SMS and call. 
Dec 19 11:08:47 <gena2x> panicking: nope, it's easy to predict that completely new very complex hw with completely new software cann't be stable.
Dec 19 11:08:51 <SpeedEvil> Get it working, though unpretty, and the kernel fixed, and a minor hardware bugfix release possibly - and you're ready for xmas 2007
Dec 19 11:09:05 <SpeedEvil> gena2x: rubbish.
Dec 19 11:09:08 <SpeedEvil> IMO
Dec 19 11:09:37 <SpeedEvil> There is complex hardware that is hard to get right, and concentrating on shiny UI when the kernel is unstable in many ways.
Dec 19 11:09:38 <panicking> yes, but when android (that was a complete mobile framework)
Dec 19 11:09:45 <gena2x> panicking: but all that boot time optimizations, boot pictures only dust to someone's face.
Dec 19 11:09:51 <panicking> went out
Dec 19 11:09:55 <panicking> nobody care about it
Dec 19 11:11:24 <SpeedEvil> panicking: Still - I would have bought one in xmas 2007 - released with a basic stack and GTK
Dec 19 11:11:33 <SpeedEvil> (if I hadn't bought earlier of course)
Dec 19 11:12:08 <gena2x> ok, in fact i am wrong, hw was not new.
Dec 19 11:12:22 <panicking> Yes, the problem was that it the first or (i don't know) linux mobile
Dec 19 11:12:25 <panicking> is it correct?
Dec 19 11:13:07 <gena2x> in fact linux was used in mobile long before om.
Dec 19 11:14:08 <gena2x> panicking: how your android with new kernel?
Dec 19 11:14:57 <SpeedEvil> It was the first linux mobile with an open stack.
Dec 19 11:15:04 <panicking> I think that is quite good, but I have the idea it can be better
Dec 19 11:15:22 <panicking> but no time a lot of time to busrt performace
Dec 19 11:15:32 <panicking> we have 60 or 70 issue
Dec 19 11:15:36 <panicking> on the bugtrack
Dec 19 11:15:42 <panicking> some of them are feauture
Dec 19 11:16:01 <panicking> so wifi is ok
Dec 19 11:16:18 <panicking> to many things to say
Dec 19 11:16:21 <panicking> let's try
Dec 19 11:16:35 <panicking> wait for a daily build
Dec 19 11:16:41 <panicking> because I fix somenthing now
Dec 19 11:16:44 <panicking> and install it
Dec 19 11:17:22 <panicking> I think that is possible to use 440mhz
Dec 19 11:17:26 <panicking> frequency too
Dec 19 11:18:58 <gena2x> panicking: I like you point of view on optimization :) But before reflashing once again I am planning to do something useful :)
Dec 19 11:23:47 <gena2x> For example I think that true developer phone should have cpu and memory load indicatiors, and better to have percent bettery and recieving signal strength indicatior
Dec 19 11:25:13 <gena2x> So it's easy to understand what's going on device.
Dec 19 11:28:32 <gena2x> who knows which package start-stop-daemon and update-rc.d belongs to in shr?
Dec 19 11:33:47 <gena2x> and what to do with fso-apm/apm...
Dec 19 11:40:36 <gena2x> Seem i am asking too many simple questions...
Dec 19 11:47:45 <gena2x> Ok, last question, not so simple: I am getting host lockup on openmoko unplug. My host is x86-64 debian with self compiled kernel. I can't handle this problem myself. I post mail linux-usb, but noone seem can take care of this problem. What to do with it? Do anyone have similar problem?
Dec 19 11:48:58 <Weiss> gena2x: I get fairly regular oopses when plugging it in, but unplugging+re-plugging fixes it. maybe it's related
Dec 19 11:50:13 <gena2x> here is my mail: http://www.spinics.net/lists/linux-usb/msg24453.html
Dec 19 11:52:17 <gena2x> Anyone can recommend the way that whould I do to have this problem fixed?
Dec 19 11:53:32 <gena2x> Weiss: Mb. and you lucky. I am getting complete lockup.
Dec 19 11:53:54 <gena2x> Weiss: opses in host kernel?
Dec 19 11:53:56 <Weiss> the most useful thing you can do at this point would be to bisect and find the revision where the problem started
Dec 19 11:53:59 <Weiss> gena2x: yep
Dec 19 11:54:43 <gena2x> Weiss: with backtrace?
Dec 19 11:55:20 <gena2x> Weiss: so i have to dig up into usb subsystem...
Dec 19 11:55:20 <Weiss> git bisect
Dec 19 11:56:00 <gena2x> Weiss: ok, i'll try this opensource way...
Dec 19 11:56:30 <Weiss> start by maybe going back to 2.6.30 and seeing if it happens there, if it doesn't, run git bisect to narrow it down between those versions (this doesn't take as long as it sounds, but count on an entire evening)
Dec 19 11:57:00 <gena2x> Weiss: mb this is because of kernel change at openmoko
Dec 19 11:57:08 <Weiss> the people developing the subsystem can usually fix it very quickly if you can give then this information
Dec 19 11:57:11 <Weiss> them*
Dec 19 11:57:45 <Weiss> maybe an OM kernel change made it show up, but a kernel oops ALWAYS represents a bug in that kernel
Dec 19 11:58:30 <gena2x> Weiss: i sent mail to maintainer, he asked me to retest on latest rc, I retested, posted and nothing happened.
Dec 19 11:58:50 <gena2x> ;9
Dec 19 11:58:52 <gena2x> :(
Dec 19 11:59:11 <Weiss> the problem still existed?
Dec 19 12:00:49 <gena2x> Weiss: I should retest 5th time on latest kernel to find out that
Dec 19 12:01:23 <panicking> do it in qemu
Dec 19 12:01:29 <panicking> freeeze the qemu machine
Dec 19 12:01:49 <panicking> and test the qemu machine
Dec 19 12:01:52 <gena2x> panicking: Interesting idea.
Dec 19 12:02:06 <panicking> but it can not be freeze :D
Dec 19 12:02:18 <panicking> -usb -usbdevice:host:id:xx
Dec 19 12:02:40 <gena2x> panicking: yes, I know that qemu can do usb
Dec 19 12:05:01 <gena2x> panicking: thanks, i had to realise it by myself.
Dec 19 12:05:38 <gena2x> Weiss: So I'll try latest 32.1...
Dec 19 12:06:22 <panicking> sorry :)
Dec 19 12:06:26 <panicking> I would like to helop
Dec 19 12:07:18 <gena2x> panicking: really never mind against right ideas :)
Dec 19 12:07:58 <panicking> Do you have stack protector in your config
Dec 19 12:07:59 <panicking> ?
Dec 19 12:09:07 <gena2x> panicking: no
Dec 19 12:09:41 <panicking> can you activate it
Dec 19 12:12:22 <PaulFertser> panicking: so, do you agree i apply the Qi patch (amending the comment) but not the kernel patch since we agreed it's wrong?
Dec 19 12:12:44 <gena2x> panicking: ... read about it. nice idea.
Dec 19 12:13:52 <Weiss> gena2x: try to see it from the developer's perspective: "oh crap, someone found a bug.  I wonder if went away with the latest version - if so, I don't have to fix it.  Nope, still happens.  I have no idea what caused it and can't reproduce it"
Dec 19 12:14:02 <PaulFertser> panicking: so what about FCSE? Does it work at all given all the limitations (pid and address space)? I assume you run in "best effort mode" so what are the measurable benefits?
Dec 19 12:14:46 <panicking> I have no measure yet, because there are to many changes and I must isolate
Dec 19 12:14:49 <panicking> one each one
Dec 19 12:14:57 <Weiss> gena2x: so YOU need to go back in time and see if it happened with EARLIER versions. if you can find a time where the bug didn't happen, you can step forward and find out where it was introduced.  That's the most valuable information for the developer.  "git bisect" can help you do it much faster
Dec 19 12:14:59 <panicking> can be a good computation of ram refresh rate too
Dec 19 12:15:15 <panicking> git bisect and qemu
Dec 19 12:15:19 <panicking> if you can reproduce it
Dec 19 12:16:18 <PaulFertser> Weiss: isn't oops on host usually easy enough to debug without bisecting?
Dec 19 12:17:23 <gena2x> Weiss: I already so it from developer perspective, as a developer first i thought "crap, it now hangs, some bug in kernel, guess this will be fixed in next version", wait... next version, compile retest, no fix... ok. How to report bugs? mail maintainer? ok... big mail... answer 'please retest and mail to linux-usb'... ok, i know developer perspective... retest... other big mail... wait for answer...
Dec 19 12:17:24 <PaulFertser> But i see, it's not oops this time.
Dec 19 12:18:01 <PaulFertser> gena2x: have you tried reproducing with bleeding-edge kernel?
Dec 19 12:18:37 <gena2x> Ok, now I have plan. Thanks all :)
Dec 19 12:18:38 <Weiss> PaulFertser: perhaps..but a bisection is always very valuable - means the developer can go straight to the bit where they broke it..
Dec 19 12:18:58 <PaulFertser> Weiss: yes, indeed. USB stuff is hard to dive in anyway even for an experienced person :|
Dec 19 12:19:23 <PaulFertser> gena2x: sorry for useless questions, i see now you tried 32-rc8 as well. :)
Dec 19 12:19:59 <PaulFertser> gena2x: before doing bisection i'd advice to cut down the quantity of modules you compile because it contributes to the build (and therefore test) time a lot.
Dec 19 12:25:57 <PaulFertser> panicking: i mean how do you know if some process is using FCSE or not and (most important) what amount of context switches happens with with FCSE and what without.
Dec 19 12:26:41 <PaulFertser> panicking: also i'd expect a lot of latency in a typical usage caused by context switches to/from X server and that's an example of process which clearly needs more than 32M of address space.
Dec 19 12:26:42 <panicking> ok, I can do that and add account statiscs to the openmoko kernel
Dec 19 12:26:58 <panicking> android version
Dec 19 12:26:59 <PaulFertser> Weiss: any thoughts on this?
Dec 19 12:28:23 <gena2x> PaulFertser: it's already cut down to fit exactly my machine. I'm traditionally build custom kernel for my home machine for years.
Dec 19 12:28:31 <PaulFertser> panicking: i mean FCSE seems to be quite specialised stuff, beneficial mostly for small hard realtime tasks. TBH i've no idea about amount of address space needed for e.g. enlightment or other apps one is supposed to run on FR.
Dec 19 12:29:32 <panicking> I know exaclty
Dec 19 12:29:35 <panicking> what fcse do
Dec 19 12:29:45 <panicking> but maybe can be benefict only android
Dec 19 12:29:47 <PaulFertser> gena2x: same here. It was funny when i needed to recompile my kernel right during a class to be able to use student's portable player as a cardreader because i forgot to enable MULTI_LUN
Dec 19 12:30:36 <PaulFertser> panicking: is the descrition linked from the OM kernel ML accurate enough? If yes, then 95 pid and 32MiB address space limitation seems pretty tough.
Dec 19 12:31:40 <Weiss> PaulFertser: have to go and do all my christmas shopping now :).. but will think about it and get back to you tomorrow..
Dec 19 12:31:58 <PaulFertser> Weiss: thanks :)))
Dec 19 12:32:02 <PaulFertser> Weiss: good luck
Dec 19 12:33:16 <gena2x> PaulFertser: That's why i said 'home'. Wait? MULTI_LUN? :)
Dec 19 12:33:22 <panicking> PaulFertser, I don't think so
Dec 19 12:33:24 <panicking> why?
Dec 19 12:33:28 <panicking> give me an example
Dec 19 12:33:29 <PaulFertser> panicking: and "best effort" benchmarks didn't look very promising, and as far as i understood that's a necessity to be able to run a non-specialised system.
Dec 19 12:33:49 <PaulFertser> gena2x: yes, when one USB device have several LUNs (internal memory, cardreader, etc).
Dec 19 12:34:03 <panicking> i have about 95 running task
Dec 19 12:34:06 <panicking> maybe more
Dec 19 12:34:08 <PaulFertser> panicking: http://lwn.net/images/conf/rtlws11/papers/proc/p01.pdf
Dec 19 12:34:28 <panicking> but how many task do you think that can use
Dec 19 12:34:30 <panicking> it in the fso
Dec 19 12:34:34 <panicking> distribuition
Dec 19 12:34:34 <panicking> ?
Dec 19 12:34:39 <gena2x> panicking: I've read exactly that article
Dec 19 12:34:58 <panicking> What are your conclusion
Dec 19 12:35:01 <gena2x> panicking: And tried to measure context switching overhead on OM.
Dec 19 12:35:06 <panicking> ok
Dec 19 12:35:19 <panicking> so do yoiu have some measure
Dec 19 12:35:20 <PaulFertser> panicking: it's not the question to ask, i think what's important is if most of the context switches are done between the task that can be constraned by 32M address space limit.
Dec 19 12:35:38 <PaulFertser> the tasks
Dec 19 12:35:46 <panicking> We need some measure ok
Dec 19 12:35:51 <panicking> that's is true
Dec 19 12:35:57 <panicking> but for now daily use
Dec 19 12:35:59 <panicking> of the kernel
Dec 19 12:36:04 <gena2x> panicking: I did easy thing - do memcpy in 1 and 2 processes.
Dec 19 12:36:05 <panicking> is a good banckmark
Dec 19 12:36:22 <gena2x> panicking: And compare speed
Dec 19 12:36:34 <PaulFertser> panicking: i mean you want to improve latency by cutting down time of context switching. If most of the switches involve something that is incompatible with FCSE constraints, you're out of luck anyway.
Dec 19 12:36:53 <gena2x> panicking: And found out that context switch is negligible, exactly as told in article
Dec 19 12:37:27 <gena2x> panicking: This really matter only if you want to so special stuff like precise timing.
Dec 19 12:37:50 <PaulFertser> panicking: and yes, for hard realtime cache flush time matters. If you can avoid it, great. But users do not need hard realtime, they cannot have it anyway in fact.
Dec 19 12:38:35 <panicking> ok, but if you avoid cache flush
Dec 19 12:38:36 <gena2x> panicking: I'll parse article to find out their estimation...
Dec 19 12:38:41 <DocScrutinizer51> honestly for a standard system thats futile. 'latency' is not due to taskswitching. rather it is mere computing load to process any event 
Dec 19 12:39:15 <panicking> I'm obly trying to increase performace
Dec 19 12:39:23 <panicking> All the point of view are correct
Dec 19 12:39:27 <panicking> but the daily use
Dec 19 12:39:32 <panicking> is the banchmark
Dec 19 12:39:42 <panicking> Numbers are ok
Dec 19 12:39:48 <gena2x> panicking: moment...
Dec 19 12:39:59 <PaulFertser> panicking: it looks like FCSE is not the way to improve user experience, it looks like it should be really neglegible.
Dec 19 12:40:27 <panicking> I must try to check each patch
Dec 19 12:40:37 <panicking> because I have introduce
Dec 19 12:40:40 <panicking> 10 commits
Dec 19 12:40:41 <gena2x> panicking: i wrote several long mails about performance to community maillist.
Dec 19 12:40:45 <panicking> in android kernel
Dec 19 12:40:58 <panicking> I don't read anything
Dec 19 12:40:59 <panicking> sorry
Dec 19 12:41:18 <PaulFertser> It'd interesting to understand why ARM decided to do such a constrained implementation. And it's interesting to read about clever hacks that allow to benefit from it. But it looks like it's not something that can actually help in this particular case.
Dec 19 12:41:19 <panicking> I'm only in kernel mailing list
Dec 19 12:41:48 <gena2x> panicking: they not really straightforward
Dec 19 12:42:09 <panicking> I give frequency scaling 1 month ago
Dec 19 12:42:35 <panicking> ok
Dec 19 12:42:38 <panicking> I can retest it
Dec 19 12:42:43 <panicking> again and measure performance
Dec 19 12:42:54 <panicking> but I don't push on andy-kernel
Dec 19 12:43:01 <panicking> people can try
Dec 19 12:43:04 <panicking> and said
Dec 19 12:43:13 <panicking> It's good
Dec 19 12:43:16 <panicking> or it's no good
Dec 19 12:43:33 <panicking> The same of freq-scaling
Dec 19 12:43:43 <panicking> or buttery mutex recharge
Dec 19 12:43:51 <panicking> or scatter list on mmc
Dec 19 12:44:09 <panicking> the last one are in the linux-2.6.3x
Dec 19 12:44:22 <panicking> the freq-scaling can be reused in 2.6.3x
Dec 19 12:44:29 <panicking> in the part of voltage scaling 
Dec 19 12:44:39 <panicking> people can take the code and do a better one
Dec 19 12:44:52 <panicking> I just follow the android branch
Dec 19 12:45:16 <panicking> I only recevie mail about people that said is slow
Dec 19 12:45:28 <panicking> so I want to try all
Dec 19 12:46:45 <gena2x> panicking: yes, first reference in article: http://opensrc.sec.samsung.com/document/uc-linux-04_sait.pdf
Dec 19 12:47:35 <panicking> thanks
Dec 19 12:47:40 <PaulFertser> panicking: (trying all) i'd suggest to those complaining about slowness to get some weed, probably it'd be a reliable way to solve the problem. The device wouldn't become faster but those people will stop caring and will feel happy anyway.  
Dec 19 12:47:43 <panicking> I'm going to read the articale
Dec 19 12:48:07 <gena2x> panicking: Oh, can't find exactly place where i read about performance affect.
Dec 19 12:48:53 <gena2x> panicking: But context switch is not problem.
Dec 19 12:49:30 <panicking> But using fcse you avoid cache flushing
Dec 19 12:49:31 <gena2x> panicking: Wait a moment, you mean you have serie of performance patches?
Dec 19 12:49:52 <panicking> I mean that the performace can be related to:
Dec 19 12:50:13 <gena2x> panicking: I propose to decrase HZ.
Dec 19 12:50:17 <panicking> - io-timing that recalculate the refreash rate of gta02 ram
Dec 19 12:50:23 <panicking> - fcse in android
Dec 19 12:50:37 <gena2x> panicking: Why not just do profiling?
Dec 19 12:50:47 <panicking> - avoid unusedn dcache flashing in armv-fault
Dec 19 12:51:11 <panicking> I'm going to eat
Dec 19 12:51:29 <PaulFertser> panicking: enjoy your meal :)
Dec 19 12:51:39 <gena2x> panicking: yes. 
Dec 19 12:52:45 <gena2x> panicking: I did some lmbenching, so if you want someone to help testing some performance idea, I'll be glad to participate.
Dec 19 12:53:15 <gena2x> panicking: today or tomorrow.
Dec 19 12:53:53 <gena2x> panicking: after I'll do something with my usb...
Dec 19 12:54:33 <PaulFertser> gena2x: if you have openmoko kernel repository already cloned and no mainline kernel you can cut down on cloning times by using OM repo as a --reference.
Dec 19 12:54:57 <PaulFertser> gena2x: or just add upstream as another remote source to your existing repo.
Dec 19 12:57:07 <gena2x> PaulFertser: hm... no need to track upstream for my usb issue, now I'm just traditionally compiling from tarbz2ball.
Dec 19 12:57:23 <PaulFertser> gena2x: how are you going to do git bisect then?
Dec 19 12:57:40 <gena2x> PaulFertser: Hm.
Dec 19 12:57:56 <gena2x> PaulFertser: yes.
Dec 19 12:58:08 <PaulFertser> gena2x: because finding the particular commit that broked things will really help for the upstream devs to solve the issue.
Dec 19 12:58:48 <PaulFertser> s/for /
Dec 19 12:59:59 <gena2x> PaulFertser: I gues if I'll find particular commit (if it is exist and if it is not my quite stable hw/bios/ bug), then I'll try to hurt them badly with patch ;)
Dec 19 13:06:01 <PaulFertser> gena2x: nice plan
Dec 19 16:04:25 <panicking> PaulFertser, so what about spurius wakeup of lan
Dec 19 16:04:25 <panicking> ?
Dec 19 16:04:36 <panicking> so why don't change the beahvior of the pin
Dec 19 16:04:40 <panicking> before suspend
Dec 19 16:04:40 <panicking> ?
Dec 19 16:06:35 <lindi-> panicking: wakeup of lan=
Dec 19 16:06:41 <lindi-> s/=/?/
Dec 19 16:06:42 <apt> lindi- meant: panicking: wakeup of lan?
Dec 19 16:06:55 <PaulFertser> panicking: have you confirmed it ever happened?
Dec 19 16:07:05 <PaulFertser> panicking: because i'm a lazy ass :|
Dec 19 16:07:40 <PaulFertser> lindi-: there's a suspicion with wifi module off one can experience strange wakeups from suspend.
Dec 19 16:07:58 <PaulFertser> lindi-: it looks quite possible, i had a look at the code and schematics.
Dec 19 16:09:08 <PaulFertser> panicking: if you experience any strange wakeup, pretty please report the details!
Dec 19 16:09:23 <panicking> ok
Dec 19 16:09:38 <panicking> For now we only report PMU wakeup reason
Dec 19 16:10:09 <PaulFertser> panicking: it'd be nice to report both, we have everything needed in place already.
Dec 19 16:10:31 <panicking> yes I know
Dec 19 16:10:39 <panicking> but it's a bug in our bug tracker
Dec 19 16:11:05 <PaulFertser> panicking: i thought we all agreed to keep kernel and other low-level bugs at OM bugtracker component "System software"?
Dec 19 16:11:38 <panicking> yes, but this is for sure a android bad design
Dec 19 16:12:03 <PaulFertser> Oh
Dec 19 16:12:10 <PaulFertser> I knew that :P
Dec 19 16:12:18 <panicking> When I find a bug in the kernel
Dec 19 16:12:21 <panicking> I will report
Dec 19 16:12:27 <panicking> I have one but I must investigate
Dec 19 16:12:38 <panicking> panic on resume with usb plug in
Dec 19 16:13:41 <panicking> Paul I always submit patch agaist a problem or panic
Dec 19 16:13:48 <panicking> but I never fill a bug report
Dec 19 16:13:52 <panicking> for my poor english
Dec 19 16:15:47 <mwester> Your english is better than my italian, though. :)
Dec 19 16:20:19 <PaulFertser> Same here :)
Dec 19 16:20:40 <PaulFertser> panicking: we all appreciate your desire to improve OM kernel, honestly.
Dec 19 16:21:18 * mwester is happy that somebody is still serious about making Android work on the FR.
Dec 19 16:22:20 <panicking> This is a pleusure for me
Dec 19 16:22:27 <panicking> I have contact all the world
Dec 19 16:22:34 <mwester> hehe! Off-topic: I think I found a technical loop-hole that will let me get online whilst I'm imprisoned behind my customer's draconian firewalls.  :D
Dec 19 16:22:49 <mwester> So maybe I can become active here again.
Dec 19 16:22:56 <d1b> mwester: lol.
Dec 19 16:23:13 <d1b> mwester: there is a web interface for freenode...
Dec 19 16:24:40 <mwester> d1b,  I didn't know that, but I suspect its blocked too -- they block all the so-called "social networking" sites.
Dec 19 16:25:16 <d1b> mwester: yes freenode is a big offender in that category :P
Dec 19 16:25:55 <ndnihil> easy enough to set up your own http->irc gateway, they're likely only blocking by name/ip
Dec 19 16:26:08 <d1b> i would be suprised if they blocked ssh out on port 443. etc.
Dec 19 16:26:25 <mwester> I tried the ssh on 443.
Dec 19 16:26:36 <d1b> oh... proxy?
Dec 19 16:26:38 <mwester> It works for a few minutes, then their firewall kills the connection.
Dec 19 16:27:07 <d1b> interesting.
Dec 19 16:30:17 <lindi-> panicking: "we only report ..." -- aren't there two resume_reason nodes?
Dec 19 16:30:38 <lindi-> panicking: what is "we" here? "kernel"?
Dec 19 16:32:37 <panicking> can rewrite what I said sorry 
Dec 19 17:19:20 <PBeck> hi
Dec 19 18:25:42 <lindi-> larsc: PaulFertser: is there some sysfs node that can tell me if the display is on or off? "xset q" says "monitor is off" but is there some other way to see this?
Dec 19 18:29:58 <larsc> lindi-: /sys/class/lcd/*/lcd_power
Dec 19 18:30:01 <larsc> 0 is on
Dec 19 18:30:05 <larsc> everything else is off
Dec 19 18:31:25 <lindi-> head: cannot open `/sys/class/lcd/*/lcd_power' for reading: No such file or directory
Dec 19 18:31:28 <lindi-> not with andy-tracking
Dec 19 18:32:00 <lindi-> larsc: has this changed recently?
Dec 19 18:32:15 <larsc> hm... yes
Dec 19 18:32:26 <larsc> not recently, but it has changed
Dec 19 18:32:28 <lindi-> larsc: what's the old way?
Dec 19 18:32:58 <lindi-> (also note that I'm using xserver-xorg-video-fbdev in case it matters)
Dec 19 18:33:05 <larsc> wait. have to read the source code
Dec 19 18:34:01 <lindi-> larsc: my suspend script saves the status of display power, turns display off, locks touchscreen and goes to suspend
Dec 19 18:34:19 <lindi-> larsc: the resume hook then reacts to resume-reason and may or may not enable the display
Dec 19 18:34:57 <lindi-> larsc: currently i'm using "xset q" but this does not work if xdm is showing its login prompt and not letting X clients connect
Dec 19 18:35:47 <larsc> lindi-: it's /sys/bus/platform/devices/jbt*/state
Dec 19 18:35:53 <larsc> at least should be
Dec 19 18:36:05 <lindi-> head: cannot open `/sys/bus/platform/devices/jbt*/state' for reading: No such file or directory
Dec 19 18:36:40 <larsc> `ls /sys/bus/platform/devices` ?
Dec 19 18:37:50 <larsc> but you probably want to use the framebuffers status anyway
Dec 19 18:38:00 <larsc> /dev/class/graphics/fb0/blank
Dec 19 18:38:27 <larsc> aeh sys instead of dev...
Dec 19 18:39:13 <lindi-> $ ls /sys/bus/platform/devices|nc paste.dyndns.org 1234
Dec 19 18:39:14 <lindi-> http://paste.debian.net/54462/
Dec 19 18:39:50 <lindi-> larsc: '/sys/class/graphics/fb0/blank' is empty file
Dec 19 18:40:05 <larsc> ah... right... the jbt is connected through spi
Dec 19 18:40:34 <larsc> find /sys -name "*jbt*" 
Dec 19 18:40:44 <lindi-> only one hit.  /sys/bus/spi/drivers/jbt6k74
Dec 19 18:40:56 <lindi-> has 'bind  spi2.0  uevent  unbind'
Dec 19 18:41:26 <larsc> then it is /sys/bus/spi/drivers/jbt6k74/spi2.0/state i guess
Dec 19 18:41:28 <lindi-> /sys/bus/spi/drivers/jbt6k74/spi2.0/state !
Dec 19 18:41:31 <lindi-> works
Dec 19 18:41:33 <lindi-> thanks
Dec 19 18:41:58 <lindi-> thanks
Dec 19 18:42:01 <lindi-> whoops :)
Dec 19 18:42:31 <lindi-> larsc: however "echo normal > /sys/bus/spi/drivers/jbt6k74/spi2.0/state" is not enough to wake the display up. might be X issue
Dec 19 18:43:44 <lindi-> larsc: now http://paste.debian.net/54463/ and the display is indeed blanked
Dec 19 18:43:53 <lindi-> larsc: so "normal" does not mean that display is on
Dec 19 18:44:36 <larsc> but it should
Dec 19 18:44:43 <larsc> iirc
Dec 19 18:45:30 <lindi-> larsc: ok, i guess i need to read X source code
Dec 19 20:50:58 <zing> is there some way to make phonelog faster in shr-u?  starting is slow and a pause when switching between tabs.
Dec 19 21:49:17 <PaulFertser> Hey guys, do you have any suggestion how my FR can help me to memorise ~120 words of toki pona? 
Dec 19 21:51:13 <ndnihil> toki pona?
Dec 19 21:51:20 <PaulFertser> ndnihil: yep
Dec 19 21:51:28 <ndnihil> whassat?
Dec 19 21:51:35 <PaulFertser> ndnihil: an interesting minimalistic dao-ist language :)
Dec 19 21:51:55 <ndnihil> flashcards?
Dec 19 21:52:06 <PaulFertser> ndnihil: probably, i've no idea, never used anything like that.
Dec 19 21:52:28 <ndnihil> ooh, or run an x86 emu, to run wine, to run rosetta stone
Dec 19 21:53:08 <PaulFertser> ndnihil: do i fucking look like a one who runs proprietary shit unless really forced to?
Dec 19 21:53:08 <ndnihil> I'd start with flashcards
Dec 19 21:53:36 <ndnihil> eh, sometimes I run windows stuff just to shut people up
Dec 19 21:53:40 <ndnihil> "you can't do..."
Dec 19 21:53:43 <ndnihil> "oh yes I can"
Dec 19 21:53:56 * mwester is a pragmatist.
Dec 19 21:54:07 <mwester> I run whatever it takes on whatever is necessary.
Dec 19 21:54:36 <PaulFertser> mwester: hey
Dec 19 21:54:41 <ndnihil> the software I use on my car is windows only
Dec 19 21:54:46 <ndnihil> works great under wine though
Dec 19 21:55:02 <PaulFertser> mwester: can you share what trick have you found to break through the draconian firewalls?
Dec 19 21:55:02 <mwester> There's already to much religious fanaticism in the world, IMO there's no good to come of making my hobby into a religion ;)
Dec 19 21:55:22 <mwester> You won't like it PaulFertser -- it involves proprietary software!
Dec 19 21:55:37 <PaulFertser> mwester: i'd still like to hear about it
Dec 19 21:56:23 <ndnihil> stunnel not doing it?
Dec 19 21:56:38 <PaulFertser> mwester: and btw i want to congratulate you with finding it, i hope it'll make your working experience more enjoyable :)
Dec 19 21:57:13 <mwester> It's really simple, as most solutions ultimately end up being -- I created a Fedora virtual machine, and attach a USB-based wifi dongle to it.  I cloned the MAC address of a vendor device that's allowed on the vendor/guest WIFI lan...
Dec 19 21:57:46 <mwester> So now I have a connection that is free of the draconian internal network.
Dec 19 21:58:11 <mwester> And as a bonus, I have a usable Linux environment on the company-owned laptop.
Dec 19 21:59:08 <PaulFertser> mwester: is the proprietary software you used VirtualBox?
Dec 19 21:59:23 <mwester> No - it's VMware Workstation.
Dec 19 21:59:56 <mwester> The latest version (7.0) finally got the USB stuff working to where the wifi device actually connects.
Dec 19 22:00:05 * ndnihil gave up on being 100% open
Dec 19 22:00:18 <ndnihil> it's nice in theory, but not practical
Dec 19 22:00:20 * PaulFertser gave up on being 100% saint
Dec 19 22:00:35 * mwester set a goal to be 0% saint.
Dec 19 22:00:36 <PaulFertser> But it'd be still nice to try ;)
Dec 19 22:00:41 <mwester> I like attainable goals.
Dec 19 22:00:58 <ndnihil> it is nice to try, but you'll always have to compromise somewhere
Dec 19 22:02:22 * PaulFertser fails to set any goals for his life, it goes its own way regardless of what i dream of.
Dec 19 22:03:54 <mwester> But I've got to say that some of the desktop Linux distros have come a very very long way in the past couple of years -- it's more practical now to "live" in Linux in a corporate env than ever before.  One of my co-workers (with a more "enlightended" customer) has inverted my solution -- he runs Fedora, with a VMware windows env for those few apps that still need windows.
Dec 19 22:04:01 <PaulFertser> mwester: (proprietary software) btw, one local company producing various measuring equipment gave me the source for the windows driver of their PCI DAQ board when i requested for more information to be able to write a driver. That's an attitude i like.
Dec 19 22:04:26 <ndnihil> that's rare
Dec 19 22:05:39 <PaulFertser> Not that it helped me to manage to figure what's wrong with my basic driver but i still has hope.
Dec 19 22:05:42 <mwester> I'm liking those companies that release hardware with an open linux driver to begin with, rather than waiting for a dev to ask for docs to write a linux driver.  I think the days of the "all you need is a windows reference driver" are fading.
Dec 19 22:06:03 <Wonka> mwester: my orkplace runs xen-domUs. some clients want virtualized windows servers because they don't trust linux to be stable enough... now guess what the dom0s run?
Dec 19 22:06:19 <PaulFertser> Wonka: LOL
Dec 19 22:06:29 <ndnihil> heh
Dec 19 22:06:34 * ndnihil *hearts* xen
Dec 19 22:06:39 <mwester> Wonka,  that's hilarious!  Do any of the managers understand that?! :D
Dec 19 22:07:00 <Wonka> the clients don't, obviously
Dec 19 22:07:14 <PaulFertser> mwester: intel released their wimax solution with a good driver, that's even accepted mainline.
Dec 19 22:07:21 <Wonka> our managers do, they're all from the techie world
Dec 19 22:07:26 <mwester> Yeah, and I suppose it wouldn't be good for business to "educate" the clients, huh?
Dec 19 22:07:29 <PaulFertser> mwester: too bad it required proprietary suppliant to be actually useful :)
Dec 19 22:08:15 <Wonka> one could still argue that the linux dom0 only does limited stuff and does not run the real applications, so is less likely to be unstable anyway
Dec 19 22:09:34 <ndnihil> up 231 days
Dec 19 22:09:48 <ndnihil> ^one of my dom0's, and it's domU's have the same
Dec 19 22:09:48 <PaulFertser> mwester: also intel released a free X driver for their video chips but it (i think still) requires proprietary vbios for modesetting.
Dec 19 22:10:05 <ndnihil> and it was only rebooted because of a power outage in the building
Dec 19 22:10:46 <lindi-> Wonka: aren't the linux dom0 patches still not even in mainline?
Dec 19 22:14:05 <PaulFertser> lindi-: i think mainline decided to go away from xen
Dec 19 22:18:27 <Wonka> lindi-: I am not really involved there.
Dec 19 22:32:22 <PaulFertser> ndnihil: from all popular flashcard programs apt-get install granule seems to fit my debian system best as it doesn't depend on Qt :)
Dec 19 23:29:26 <pooze> I just upgraded my SHR and got a collection of errors.
Dec 19 23:29:46 <pooze> it seems a package called 'libvorbis0' wants to install a couple of files provided by 'libvorbis'
Dec 19 23:29:55 <pooze> seems like the package has been renamed or something.
Dec 19 23:30:07 <pooze> anybody has a clue how to fix it?
Dec 19 23:30:39 <Heinervdm> pooze: just remove the old package
Dec 19 23:31:00 <pooze> heinervdm: ok, thanks.
Dec 19 23:31:14 <pooze> but it also seems my upgrade wants to install openssh, which conflicts with dropbear.
Dec 19 23:31:24 <pooze> should I also remove dropbear and let openssh be installed?
Dec 19 23:31:39 <Heinervdm> you can
Dec 19 23:31:47 <pooze> I'm kind of using dropbear at the moment.
Dec 19 23:31:56 <Heinervdm> it seems you haven't upgraded for a long time
Dec 19 23:32:38 <Heinervdm> for openssh you have to set a root password
Dec 19 23:33:14 <pooze> heinervdm: that's true, my task-base is upgrading from 1.0-r85.4 to 1.0-r87.4, I think it was around 1st of December.
Dec 19 23:33:28 <pooze> heinervdm: I always have a root password.
Dec 19 23:34:03 <Heinervdm> then you wont have a problem with openssh
Dec 19 23:34:45 <pooze> the phone hung completely when upgrading, and after rebooting it the hard way (battery removal), it didn't start X. So I would like my current upgrade to be successful so I can start X and do the dropbear -> openssh switch from the terminal.
Dec 19 23:35:21 <pooze> since ssh is my only way of interacting with the phone right now.
Dec 19 23:35:53 <Heinervdm> then just ignore openssh for now
Dec 19 23:37:04 <pooze> ok, I'll see if I can do that.
Dec 19 23:37:18 <pooze> just removed 'apm' as well, since 'fso-apm' conflicted with it.
Dec 19 23:37:38 <Heinervdm> everything else will be upgraded
Dec 19 23:37:43 <Heinervdm> thats right
Dec 19 23:38:01 <Heinervdm> also remove shr-today
Dec 19 23:38:44 <pooze> ops.. "ERROR: Package fso-apm (parent fso-apm) is not available from any configured src."
Dec 19 23:38:53 <pooze> what does that error mean?
Dec 19 23:39:23 <pooze> "installing fso-apm ( ... ) to root..."
Dec 19 23:39:33 <pooze> followed by "cannot find package fso-apm."
Dec 19 23:41:17 <Heinervdm> fso-apm is there...
Dec 19 23:41:33 <pooze> it is.. it can even find the version number for it.
Dec 19 23:41:33 <Heinervdm> its in Packages and the package exists
Dec 19 23:41:59 <pooze> which is why it's strange it later says it can't find it.
Dec 19 23:42:18 <pooze> but I didn't get the "parent fso-apm" thing.
Dec 19 23:42:44 <Heinervdm> hmm, don't know
Dec 19 23:43:46 <pooze> ah, perhaps I shouldn't install fso-apm directly, but through upgrading task-base-apm?
Dec 19 23:45:08 <Heinervdm> don't know, it should work
Dec 19 23:45:45 <Heinervdm> but i have to go now, i need some sleep :)
Dec 19 23:45:54 <pooze> ok, thanks for the help so far anyway. :)
Dec 19 23:49:17 <pooze> anybody else has a clue on this one?
Dec 19 23:49:22 <pooze> root@om-gta02 ~ $ opkg install task-base-apm
Dec 19 23:49:22 <pooze> Installing task-base-apm (1.0-r87.4) to root...
Dec 19 23:49:22 <pooze> Downloading http://build.shr-project.org/shr-unstable/ipk//om-gta02/task-base-apm_1.0-r87.4_om-gta02.ipk
Dec 19 23:49:22 <pooze> Installing fso-apm (1:2.0.0+gitr800+1dcf546fb0423930f938129a51f538874c172226-r0.4) to root...
Dec 19 23:49:22 <pooze> Collected errors:
Dec 19 23:49:23 <pooze>  * ERROR: Package fso-apm (parent fso-apm) is not available from any configured src.
Dec 19 23:49:25 <pooze>  * Failed to download fso-apm. Perhaps you need to run 'opkg update'?
Dec 19 23:49:27 <pooze>  * Cannot find package task-base-apm.
Dec 19 23:49:40 <pooze> I did an 'opkg update' of course.
Dec 20 00:04:24 * Weiss did all his Christmas shopping in 128 minutes
Dec 20 00:04:33 <pooze> ok, I'm struggling a bit with this one.
Dec 20 00:04:42 <pooze> I removed task-base-apm, so I could reinstall it.
Dec 20 00:04:46 <pooze> but it won't install
Dec 20 00:05:41 <pooze> 'ERROR: Package fso-apm (parent fso-apm) is not available from any configured src.'
Dec 20 00:06:00 <pooze> but it does show up on 'opkg list | grep fso-apm'
Dec 20 00:06:18 <pooze> and it does also print the version number of the package it apparently can't find.
Dec 20 00:06:40 <ndnihil> just wget the package and install it locally
Dec 20 00:06:53 <pooze> I could try that.
Dec 20 00:06:58 <pooze> will I get updates then?
Dec 20 00:07:48 <ndnihil> if they're available
Dec 20 00:10:59 <pooze> ndnihil: should I find the fso-apm package at this location? http://build.shr-project.org/shr-unstable/ipk/om-gta02/
Dec 20 00:11:08 <pooze> since I can't actually seem to find it there.
Dec 20 00:11:15 <pooze> I do find the task-base-apm package though.
Dec 20 00:11:17 <ndnihil> if that's the appropriate repository for whatever dist you're running, yes
Dec 20 00:11:39 <pooze> that's at least where it tries to download task-base-apm from.
Dec 20 00:11:44 <ndnihil> it's complaining about fso-apm, not task-base-apm, so that would explain the error
Dec 20 00:12:46 <pooze> yes, indeed.
Dec 20 00:13:02 <pooze> so that means the task-base-apm is referring to a package that doesn't exist (any more?)
Dec 20 00:13:14 <ndnihil> it depends on that package
Dec 20 00:15:49 <ndnihil> grab it from another repo and see if it works
Dec 20 00:16:19 <pooze> ndnihil: just scanned through the /etc/opkg files and opened the urls manually.
Dec 20 00:16:34 <pooze> found it in armv4t and managed to install it now by downloading locally
Dec 20 00:17:11 <pooze> waiting in excitement to see if task-base-apm wants to successfully install now.
Dec 20 00:17:21 <pooze> which it did. :)
Dec 20 00:25:22 <pooze> one last question (I hope).
Dec 20 00:25:42 <pooze> task-base doesn't seem to want to upgrade until it has its' dependencies resolved.
Dec 20 00:26:04 <pooze> and it seems to depend on openssh, which I would like to delay the installation of for now.
Dec 20 00:26:11 <pooze> does anybody know how I can do that?
Dec 20 00:30:41 <pooze> I kind of don't like the idea of opening a screen-session, typing in 'opkg remove --force-depends dropbear && opkg install openssh'
Dec 20 00:32:13 <SpeedEvil> can telnetd be installed?
Dec 20 00:33:11 <pooze> it doesn't show up on my opkg list
Dec 20 00:33:19 <pooze> but that could certainly be an option.
Dec 20 00:56:35 <pooze> whoo...
Dec 20 00:56:39 <pooze> thanks SpeedEvil :)
Dec 20 00:56:54 <pooze> I didn't find a telnetd available, so I wrote my own in python.
Dec 20 00:57:02 <pooze> and now I'm in with openssh instead of dropbear.
Dec 20 00:57:06 <pooze> *phew*
Dec 20 01:03:43 <SpeedEvil> :)
Dec 20 01:57:22 <BillK_> gstreamer
**** ENDING LOGGING AT Sun Dec 20 02:59:56 2009