| 00:01.53 | *** join/#openmoko SpeedEvil (~user@tor/regular/SpeedEvil) |
| 00:02.17 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 00:05.39 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 00:07.56 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 00:11.12 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 00:11.52 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 00:15.09 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 00:18.14 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 00:21.53 | *** join/#openmoko Dunedan (~dunedan@phoenitydawn.de) |
| 00:25.02 | *** join/#openmoko kkb110 (~kkb110@NYUFGA-WLESSAUTHCLIENTS-01.NATPOOL.NYU.EDU) |
| 00:26.33 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 00:29.55 | DocScrutinizer | this will be enough to introduce errors into an ongoing data transmission |
| 00:30.28 | DocScrutinizer | and that's something you don't like to see ever. |
| 00:30.32 | SpeedEvil | Only inbound though |
| 00:31.23 | DocScrutinizer | that's what I meant: you need to stop and newly set up all UARTs |
| 00:31.35 | DocScrutinizer | for each CPUCLK change |
| 00:31.40 | SpeedEvil | yeah |
| 00:32.19 | DocScrutinizer | 7th hell of manageability |
| 00:32.20 | gena2x | uarts look working guys. |
| 00:32.35 | gena2x | so no problem. |
| 00:32.41 | DocScrutinizer | muhaha |
| 00:33.18 | DocScrutinizer | sorry |
| 00:33.59 | DocScrutinizer | you can't declare an identified problem moot just because it doesn't show up in a single speedy test |
| 00:34.24 | SpeedEvil | Yes you can. |
| 00:34.34 | SpeedEvil | 'Ship it, it compiles'. |
| 00:34.50 | SpeedEvil | OTOH. |
| 00:34.52 | DocScrutinizer | the problem persists, and you got an aditional one that's either your understanding of the original problem, or your test setup |
| 00:35.01 | SpeedEvil | What potential data corruption issues are there? |
| 00:35.04 | gena2x | hey, i want first to see problem |
| 00:35.16 | SpeedEvil | GPS should be largely unproblematic - it will resend more data |
| 00:35.19 | gena2x | then start thinking is it solvable or not |
| 00:35.33 | DocScrutinizer | gena2x: is this how russia builds nuklear powe rplants? |
| 00:35.34 | SpeedEvil | modem will be unproblematic in some cases, and fail in others. |
| 00:35.39 | gena2x | so far my modem registers and recieve smses |
| 00:35.49 | SpeedEvil | gena2x: try a gprs connect |
| 00:36.00 | SpeedEvil | though ppp can cope with link-level errors |
| 00:36.03 | gena2x | DocScrutinizer: where is difference between power plant and mobile phone |
| 00:36.34 | DocScrutinizer | gena2x: FFS! just because you not yet met the coincidence of cpufreq switch while receiving an important byte of serial data |
| 00:37.21 | DocScrutinizer | gena2x: exactly none. Both shall *eliminate* possible problems |
| 00:37.39 | gena2x | i see no theretical problem |
| 00:37.46 | DocScrutinizer | not wait until they show up, to appreciate them |
| 00:38.01 | gena2x | what the speed of switching FCLK on s3c? |
| 00:38.26 | SpeedEvil | gena2x: several hundred microseconds IIRC |
| 00:38.26 | gena2x | tell me if you want to speak without 'experinets' |
| 00:38.37 | DocScrutinizer | you don't suggest your code is "fast enough"??? |
| 00:39.00 | gena2x | SpeedEvil: microseconds to just change divisors? why so long? |
| 00:39.03 | SpeedEvil | Or around a byte at 115200 IIRC |
| 00:39.25 | SpeedEvil | gena2x: Hmm - the PLL needs to stabilise |
| 00:39.33 | SpeedEvil | I thought |
| 00:39.46 | gena2x | It's then you turn it on or off |
| 00:39.46 | SpeedEvil | I forget the architecture |
| 00:40.08 | gena2x | then you, but how long does it take to change dividers? |
| 00:40.25 | gena2x | s/then you,// |
| 00:40.26 | SpeedEvil | If it's just changing dividers, it might be quasi-instant. |
| 00:40.42 | gena2x | and this is what you do in cpufreq |
| 00:40.56 | gena2x | so i see no reason to get problems with serials |
| 00:41.03 | DocScrutinizer | BS |
| 00:41.07 | SpeedEvil | So, if you can change the frequency divider, and the UART clock at almost the same time, it may work - but the documents aren't clear on this point. |
| 00:41.19 | DocScrutinizer | s/almost// |
| 00:41.20 | SpeedEvil | From memory - it's a long time since I read the docs on this. |
| 00:41.29 | gena2x | more, cpufreq in implemented on huge amount of devices, and seem that work |
| 00:41.37 | gena2x | i mean s3c24xx devices of course |
| 00:41.52 | gena2x | so i see no reason why it should not work on FR |
| 00:42.11 | SpeedEvil | If it's in under 1/nth bit-time - where n is probably 4 or 8 - the skew - and if the underlying hardware is not reset, it's plausible it should 'just work'. |
| 00:42.14 | DocScrutinizer | gena2x: sorry, that's complete crap |
| 00:42.30 | SpeedEvil | But there are a lot of assumptions here. |
| 00:42.38 | DocScrutinizer | yes |
| 00:42.41 | DocScrutinizer | exactly |
| 00:42.46 | SpeedEvil | I'd first want to measure the divider latency |
| 00:42.55 | SpeedEvil | read some other clock before, and after. |
| 00:43.03 | gena2x | SpeedEvil: 1 bit is 1ms, and our cycle is 1/100 ms |
| 00:43.03 | SpeedEvil | Or emit a signal that can be measured externally |
| 00:43.07 | DocScrutinizer | and my assumption is the systems claiming "WFM" are just not noticing the problems |
| 00:43.21 | gena2x | it's good idea in fact |
| 00:43.25 | DocScrutinizer | or attributing them to something else |
| 00:43.29 | SpeedEvil | gena2x: 1 bit is 1ms at 1000 baud |
| 00:43.30 | gena2x | and relatively easy to measure |
| 00:43.46 | SpeedEvil | gena2x: you have 9us/bit at 115200 |
| 00:43.53 | gena2x | ah, sorry i mean us |
| 00:44.08 | SpeedEvil | gena2x: And you need skew to be lower than ~2us, and interruptions to be of the same order |
| 00:44.38 | DocScrutinizer | unfeasible |
| 00:44.58 | gena2x | SpeedEvil: it's easy to measure speed of changing - just do 100'000'000 of them and measure time |
| 00:45.09 | SpeedEvil | My 0th order approach would be to set a GPIO before clock down, and raise it at clock up |
| 00:45.09 | DocScrutinizer | WAAAH |
| 00:45.16 | SpeedEvil | and then hit it with a scope |
| 00:45.23 | SpeedEvil | gena2x: that's not the time you care about |
| 00:45.38 | SpeedEvil | gena2x: though that would work too. |
| 00:45.47 | gena2x | then divide time to 100'000'000 and you'll see 1 switch time |
| 00:45.53 | SpeedEvil | gena2x: though it would give considerably more than the down/up time |
| 00:45.55 | DocScrutinizer | learn to design system architecture |
| 00:45.57 | DocScrutinizer | !!! |
| 00:46.09 | DocScrutinizer | gena2x: ^^^ |
| 00:46.12 | SpeedEvil | gena2x: as you don't care about the whole time - simply the time it's not clocked. |
| 00:46.18 | gena2x | DocScrutinizer: which book you can recommend? |
| 00:46.45 | DocScrutinizer | something along the line "writing kernel driver for RTOS" maybe |
| 00:46.45 | gena2x | SpeedEvil: time may be measured with external timer |
| 00:46.48 | SpeedEvil | gena2x: Then you need to address the issue of how the serial module responds to being re-clocked in the middle of a byte. |
| 00:47.10 | gena2x | SpeedEvil: simple test on large scale |
| 00:47.13 | DocScrutinizer | IT WONT WORK |
| 00:47.30 | DocScrutinizer | it's botch |
| 00:47.32 | gena2x | hey, no heat, we can just test :) |
| 00:48.01 | SpeedEvil | gena2x: Reasonable tests might be to connect the serial port to something external, and run 10 meg of data through it while switching much more often than you would normally |
| 00:48.07 | SpeedEvil | At various baudrates. |
| 00:48.11 | SpeedEvil | Is this ideal - no. |
| 00:48.11 | DocScrutinizer | gena2x: I'm not interested in a (linux) system that just *happens* to work |
| 00:48.41 | DocScrutinizer | I could have a few monkeys code some shit and then test if it seems to do what I want |
| 00:48.43 | SpeedEvil | Ideally you'd want clarification of how the internal clocking of the UART works. I would be surprised if samsung would answer a query on this. |
| 00:49.11 | DocScrutinizer | you need to stop UARTs, then set up all clocks new, then continue UARTs |
| 00:49.21 | SpeedEvil | Why? |
| 00:49.30 | gena2x | why should i resetup UART clocks if clock source is same? |
| 00:50.04 | gena2x | probably only stop them |
| 00:50.06 | SpeedEvil | There are plausible - perhaps even likely architectures for the UARTs that would mean that the above scheme is sane. |
| 00:50.17 | SpeedEvil | If you can keep the skew to under 1/8th bit or so. |
| 00:50.22 | gena2x | this is absolutely not a problem |
| 00:50.35 | gena2x | as cpufreq has special notifications |
| 00:50.50 | gena2x | and if modem has cts/rts no problem at all to pause it |
| 00:51.02 | DocScrutinizer | SpeedEvil: 1/8bit is maximum tolerance on arbitrary UARTs for clock jitter over a whole byte |
| 00:51.26 | gena2x | and GPS is at 9600, and data is repeated, so all this problem is sucket out of finger |
| 00:51.32 | SpeedEvil | DocScrutinizer: Indeed. 1/8th is pretty much the absolute max you'd want. |
| 00:51.48 | SpeedEvil | GPS isn't the problem - problem is the modem. |
| 00:51.51 | gena2x | afair 10% |
| 00:52.02 | gena2x | SpeedEvil: does it have cts/rts? |
| 00:52.24 | gena2x | yeah |
| 00:52.31 | gena2x | according to schematic |
| 00:52.35 | DocScrutinizer | gena2x: now you say "oh well, there might be errors but we don't care"??? DUDE! |
| 00:52.39 | gena2x | so no problem to pause it. |
| 00:52.59 | gena2x | DocScrutinizer: where did i told that? |
| 00:53.07 | SpeedEvil | gena2x: I vaguely recall that tehre were issues with the modem speedily responding to rts/cts |
| 00:53.15 | DocScrutinizer | [2010-12-31 01:51:25] <gena2x> and GPS is at 9600, and data is repeated, so all this problem is sucket out of finger |
| 00:53.33 | gena2x | DocScrutinizer: in GPS single byte error is really not a problem |
| 00:53.42 | gena2x | as data is crced and repeated. |
| 00:53.47 | DocScrutinizer | gena2x: TTY is not made for gps |
| 00:54.02 | DocScrutinizer | FREAKINgF'ng SHIT |
| 00:54.13 | DocScrutinizer | TTY has to WORK! |
| 00:54.56 | gena2x | ok, guys, are you really thinking this will not work reliably? |
| 00:54.57 | DocScrutinizer | ***UNCONDITIONALLY*** |
| 00:55.08 | gena2x | i mean cpufreq? |
| 00:55.11 | SpeedEvil | gena2x: However - will the parser cope well with single byte errors |
| 00:55.25 | gena2x | s/?/./ |
| 00:55.26 | SpeedEvil | gena2x: that is uart. |
| 00:55.56 | gena2x | i have working cpufreq right now |
| 00:56.05 | gena2x | so i can do simple tests of any kind. |
| 00:56.25 | DocScrutinizer | no kernel dev will be interested in this kind of tests |
| 00:56.33 | SpeedEvil | gena2x: I think it is plausible it could work without errors. Even if there are errors, in general, if the user is informed about these, it's not an issue. As some may find cpufreq more useful. |
| 00:56.45 | DocScrutinizer | the code is flawed, the concept is buggy |
| 00:56.50 | lindi- | DocScrutinizer: gena2x is a kernel dev now :) |
| 00:56.56 | DocScrutinizer | LOL |
| 00:57.05 | SpeedEvil | Barring deep documentation of the UART, I'm not seeing any other nice way. |
| 00:57.24 | gena2x | DocScrutinizer: what's so funny? |
| 00:58.01 | gena2x | DocScrutinizer: you may try to ask people to exclude my patches from kernel from all distros. |
| 00:59.16 | DocScrutinizer | gena2x: fuck you |
| 00:59.28 | gena2x | DocScrutinizer: excellent answer. |
| 00:59.33 | lindi- | calm down :) |
| 00:59.36 | gena2x | DocScrutinizer: fuck you self. |
| 00:59.38 | SpeedEvil | wonders if alcohol may be involved. |
| 01:00.12 | gena2x | no, i just have old problem with DocScrutinizer, and i really can't understand what is cause of this. |
| 01:00.33 | gena2x | EVRYTHING i am trying to do got LOTS of negative from him. |
| 01:00.42 | gena2x | and i don't know why :( |
| 01:00.49 | SpeedEvil | While I don't in principle disagree with what Doc's saying, I think that with enough testing, and perhaps a note that concerns have been raised about possible lost bytes when switching, so users can be aware of it, I don't see a major issue. |
| 01:01.27 | SpeedEvil | gena2x: the approach you are taking is not adequately documented in the documentation, and would ideally be avoided, in a good product. |
| 01:01.32 | SpeedEvil | However. |
| 01:02.01 | DocScrutinizer | absolutely not. He's telling me "I don't care about proper system architecture. I like to have my botched design with evidently race conditions occuring any time. I don't care about and I'll push it upstream. And you can't do anything." He told ME to fuck off. My answer was accordingly |
| 01:02.17 | SpeedEvil | Umm. |
| 01:02.23 | gena2x | i am taking care |
| 01:02.28 | gena2x | this is not true |
| 01:02.28 | SpeedEvil | It's plausible that it's not a race condition. |
| 01:02.49 | *** part/#openmoko DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 01:03.04 | SpeedEvil | If you can guarantee that the skew is under a critical amount, which is possible, then tehre may be no errors. |
| 01:03.12 | SpeedEvil | sighs. |
| 01:03.17 | lindi- | gena2x: do you know how it is done on other systems? |
| 01:03.44 | gena2x | lindi-: unfortunately not. i never implemented cpufreq before |
| 01:04.04 | SpeedEvil | In general, it's not related to serial at all. |
| 01:04.08 | lindi- | gena2x: on x86 it is probably not a problem since serial is not affected |
| 01:04.18 | SpeedEvil | It's only in the case of SoCs that it will be an issue. |
| 01:04.25 | gena2x | lindi-: but i can see that where is many s3c24xx cpufreq implementations |
| 01:04.36 | SpeedEvil | As only there will the clocking be related. |
| 01:04.55 | lindi- | gena2x: "The cpufreq notifier on drivers/serial/s3c2410.c is responsible for (if possible) pausing both sides of the serial transmission before the frequency change and reloading the baud generator (and unpausing the serial transmission) after the change. " |
| 01:05.23 | lindi- | -- http://wiki.openmoko.org/wiki/User:CesarB/cpufreq#Serial_driver |
| 01:05.46 | gena2x | lindi-: where is no such code in mainline i as far as i know |
| 01:05.52 | SpeedEvil | That's the way to do it - ideally. |
| 01:06.02 | lindi- | gena2x: maybe it's only in cesarb's branch? |
| 01:06.03 | SpeedEvil | However - it's also possible to do it 'live' |
| 01:06.07 | gena2x | lindi-: also, this is only significant than you change PCKL |
| 01:06.07 | SpeedEvil | And it may be safe. |
| 01:06.11 | gena2x | *PCLK |
| 01:06.22 | gena2x | guys, really i see no problem. |
| 01:06.22 | SpeedEvil | It is certainly not safe if the PLL needs to re-clock |
| 01:06.40 | gena2x | i'll just implement all and we can test |
| 01:06.42 | SpeedEvil | At any other than the lowest baudrates anyway |
| 01:06.46 | SpeedEvil | Sounds sane. |
| 01:07.00 | gena2x | if no user will have any problem with serials -> what to investigate? |
| 01:07.10 | SpeedEvil | I'd totally agree with DocScrutinizer51 if resources are unlimited - but... |
| 01:07.24 | gena2x | i told about thoeretical grounds |
| 01:07.29 | SpeedEvil | I would say test for a day at various serial rates with data coming in flat-out. |
| 01:07.34 | gena2x | i think dividers switching FAST. |
| 01:08.15 | gena2x | so i see no reason to invent problems on flat ground |
| 01:08.31 | gena2x | if we'll see problems with serial, we'll fix em |
| 01:08.37 | gena2x | that's all |
| 01:08.58 | gena2x | i disagree that switch should take long time |
| 01:09.06 | SpeedEvil | You can't disagree. |
| 01:09.11 | gena2x | why? |
| 01:09.16 | SpeedEvil | The hardware doesn't care if you agree or not. |
| 01:09.21 | gena2x | hey. see |
| 01:09.24 | SpeedEvil | It either is a problem, or it's not. |
| 01:09.27 | gena2x | we have document |
| 01:09.37 | gena2x | nothing is written in document |
| 01:09.58 | gena2x | i think this means switch is instant. DocScrutinizer thinks it takes long time |
| 01:10.16 | gena2x | it's impossible to tell who is right |
| 01:10.39 | SpeedEvil | yes - the hardware doesn't care about opinions. |
| 01:10.40 | gena2x | without investigation or requset to samsung |
| 01:11.38 | gena2x | so i see no grounding to tell that i or DocScrutinizer is wrong |
| 01:12.00 | gena2x | and really don't understand grade of discussion from Doc's side |
| 01:12.41 | SpeedEvil | In principle, your approach is wrong. You cannot validate that your suppositions are correct. The behaviour of the chip is free to change without notification if it conforms to datasheet. Doing this is bad design. |
| 01:12.50 | SpeedEvil | However. |
| 01:13.09 | SpeedEvil | The hardware is all out there - with one revision of the chip - and more are not coming out. |
| 01:13.11 | *** join/#openmoko Dunedan (~dunedan@phoenitydawn.de) |
| 01:13.41 | gena2x | you not right, sorry :) in datasheet it is written: "IT IS SUBJECT TO CHANGE WITHOUT NOTICE" |
| 01:13.59 | gena2x | on first page with uppercase letters |
| 01:14.07 | SpeedEvil | Sure - but they issue a new revision of the datasheet if that happens |
| 01:14.24 | SpeedEvil | If they change it such that it still complies with the datasheet they don't. |
| 01:14.30 | SpeedEvil | I know someone that got bitten by this. |
| 01:14.56 | SpeedEvil | A CPU specified the clock accuracy as +-1%. This was fine, and the new and old parts both met this. |
| 01:15.33 | SpeedEvil | However - the old parts happened to have the error of +-1% average frequency, and would be short-term stable within .005% or so. |
| 01:15.43 | lindi- | gena2x: does s3c24xx_serial_stop_tx get called when you change frequency? |
| 01:15.48 | SpeedEvil | The new parts would actually vary cycle-by-cycle by .05% |
| 01:16.26 | SpeedEvil | This meant that the product failed in the field (the jitter caused servos controlled by the micro to use unacceptably high power when idle) |
| 01:18.02 | gena2x | lindi-: let me consider how to implement it. i think as long as we not changing PCLK, no need to stop and reconfigure serials. |
| 01:18.53 | gena2x | lindi-: the default behaviour of cpufreq is actually to _change_ PCLK, so it NEEDS reconfiguration |
| 01:19.12 | *** join/#openmoko Broam (~brian@c-69-255-119-127.hsd1.md.comcast.net) |
| 01:19.33 | gena2x | lindi-: i am on _purpose_ writing such implementation to _NOT_ touch PCLK and _NOT_ stop serials. |
| 01:20.01 | gena2x | lindi-: if this will not work, will implement everything need to start/stop. |
| 01:20.36 | SpeedEvil | I can't really comment more than the above - as I'd have to re-read the datasheet - and - well - I have little motivation to, as I don't even have a FR. (though the neo is probably similar) |
| 01:20.45 | SpeedEvil | Good luck though! |
| 01:20.49 | gena2x | SpeedEvil: gn |
| 01:21.05 | gena2x | SpeedEvil: and thank you |
| 01:21.09 | SpeedEvil | wishes for gta05 |
| 01:21.56 | gena2x | heh, have to add DocScrutinizer to ignore list, can stand suck lack of respect any more... no chance to find common language. |
| 01:22.12 | *** join/#openmoko SpeedEvil (1000@tor/regular/SpeedEvil) |
| 01:24.07 | *** join/#openmoko DieMumiee (~DieMumiee@p579CB9DD.dip.t-dialin.net) |
| 01:27.42 | gena2x | the main advocate against removing debug info were DocScrutinizer, against jitterless touchscreen too, he even told i stolen his battery charging script for n900 from him, now he tells something about cpufreq and tell me 'fuck you', i think this is much more than any person should tolerate. |
| 01:29.08 | gena2x | but it is him, not me who NOT implementes jitterless TS, and were CAUSE of using DEBUGGING kernels for YEARS. |
| 01:29.20 | gena2x | so FR FAILs. |
| 01:30.05 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 01:30.07 | gena2x | have to sleep |
| 01:30.22 | gena2x | gn all, sorry, just tired a bit of this... |
| 01:30.33 | lindi- | good night, i'm still watching the ccc talk about desktop environment wars :P |
| 01:30.55 | gena2x | lindi-: oh, thanks, nice idea, i've downloaded it too :) |
| 01:32.30 | lindi- | my download list is http://paste.debian.net/103508/ |
| 01:34.22 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 01:37.39 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 01:38.59 | Broam | evening folks |
| 01:41.59 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 01:43.57 | lindi- | "console-kit does not kill people. people kill people." this is more hilarious than I thought :P |
| 01:45.16 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 02:02.18 | *** join/#openmoko redarrow (~redarrow@unaffiliated/redarrow) |
| 03:03.14 | *** join/#openmoko PragmaticAnarchy (~b0b@host218.186-124-2.telecom.net.ar) |
| 03:22.17 | *** join/#openmoko pcfe (~pcfe@a83-245-162-100.elisa-laajakaista.fi) |
| 03:22.17 | *** join/#openmoko pcfe (~pcfe@redhat/pcfe) |
| 03:28.04 | *** join/#openmoko Amorphous (jan@unaffiliated/amorphous) |
| 04:03.12 | *** join/#openmoko kkb110 (~kkb110@user-12lcboo.cable.mindspring.com) |
| 04:05.51 | *** join/#openmoko rooly (~chris@ip184-187-144-61.lf.br.cox.net) |
| 04:42.38 | *** join/#openmoko Kame2 (~manuel@port-92-196-57-10.dynamic.qsc.de) |
| 07:27.12 | *** join/#openmoko Bryanstein (bryan@shellium/admin/bryanstein) |
| 07:45.04 | *** join/#openmoko kkb110 (~kkb110@user-12lcboo.cable.mindspring.com) |
| 07:58.54 | *** join/#openmoko ferluszt (~peter@p5DD285E0.dip0.t-ipconnect.de) |
| 08:02.20 | *** join/#openmoko alexxy (~alexxy@gentoo/developer/alexxy) |
| 08:19.45 | *** join/#openmoko geaaru (~geaaru@95.237.222.220) |
| 08:57.55 | *** join/#openmoko badcloud (~raanan@CBL217-132-239-62.bb.netvision.net.il) |
| 09:01.51 | *** join/#openmoko dvermd (~david@ijo32-1-78-234-93-192.fbx.proxad.net) |
| 09:01.58 | *** join/#openmoko tim_abell (~tim.abell@213.106.149.212) |
| 09:15.01 | *** join/#openmoko DieMumie1 (~DieMumiee@p579CBF72.dip.t-dialin.net) |
| 09:19.41 | *** join/#openmoko risca_deb (~risca@dynamic-adsl-94-36-99-118.clienti.tiscali.it) |
| 09:23.09 | *** join/#openmoko DieMumiee (~DieMumiee@p579CBC43.dip.t-dialin.net) |
| 10:18.55 | *** join/#openmoko pb_|sick (~pb@blundell.swaffham-prior.co.uk) |
| 10:19.25 | *** join/#openmoko naeg (~naeg@194.208.239.170) |
| 10:21.19 | *** join/#openmoko risca_deb (~risca@dynamic-adsl-94-36-92-194.clienti.tiscali.it) |
| 10:40.45 | *** join/#openmoko naeg (~naeg@194.208.239.170) |
| 10:45.34 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 10:47.25 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 10:50.50 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 10:51.43 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 10:53.42 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 10:57.02 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 10:58.52 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 11:02.13 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 11:04.04 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 11:07.22 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 11:10.42 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 11:12.43 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 11:15.04 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 11:19.57 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 11:21.20 | *** join/#openmoko pH5 (~ph5@e178193037.adsl.alicedsl.de) |
| 11:27.52 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 11:30.07 | *** join/#openmoko zedstar (~john@cpc1-haye16-2-0-cust48.haye.cable.virginmedia.com) |
| 11:30.07 | *** join/#openmoko zedstar (~john@fsf/member/zedstar) |
| 11:51.40 | *** join/#openmoko spydon (~spydon@nl103-146-152.student.uu.se) |
| 11:59.09 | *** join/#openmoko alexxy (~alexxy@gentoo/developer/alexxy) |
| 12:07.18 | *** join/#openmoko lebowski_ (~lebowski@94.72.103.146) |
| 12:25.46 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:27.44 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:28.47 | *** join/#openmoko Sup3rkiddo (~sudharsh@unaffiliated/sudharsh) |
| 12:30.04 | *** join/#openmoko b0b_ (~b0b@host183.201-253-166.telecom.net.ar) |
| 12:31.15 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:31.43 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:33.41 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:35.32 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:38.59 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:41.16 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:42.52 | *** join/#openmoko Martix (~martix@4.177.broadband3.iol.cz) |
| 12:43.11 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:44.27 | *** join/#openmoko fove48 (~fove48@41.248.178.114) |
| 12:44.31 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:47.48 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:48.44 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:52.10 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:52.47 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:54.47 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:56.41 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 12:58.35 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:00.34 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:03.56 | *** join/#openmoko samgee_ (~samgee@2.104-200-80.adsl-dyn.isp.belgacom.be) |
| 13:04.00 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:06.39 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:08.25 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:10.25 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:11.05 | *** join/#openmoko playya (~playya@93.216.223.19) |
| 13:11.05 | *** join/#openmoko playya (~playya@unaffiliated/playya) |
| 13:11.54 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:12.43 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:14.38 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:15.09 | *** join/#openmoko risca_deb (~risca@dynamic-adsl-94-36-106-88.clienti.tiscali.it) |
| 13:17.55 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:20.17 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:26.35 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:30.01 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:32.04 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:32.30 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:34.27 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:35.06 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:35.40 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:37.02 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:38.57 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 13:44.52 | *** join/#openmoko pa4wdh (~pa4wdh@lt30598-lnx.ipv6.pa4wdh.nl.eu.org) |
| 13:49.11 | *** join/#openmoko playya (~playya@unaffiliated/playya) |
| 13:55.42 | *** join/#openmoko b0b_ (~b0b@host34.190-226-155.telecom.net.ar) |
| 13:57.16 | *** join/#openmoko tim_abell (~tim.abell@213.106.149.212) |
| 14:32.22 | *** join/#openmoko ferluszt (~peter@p5DD285E0.dip0.t-ipconnect.de) |
| 14:59.15 | *** join/#openmoko badcloud (~raanan@CBL217-132-239-62.bb.netvision.net.il) |
| 15:02.52 | *** join/#openmoko chomwitt (~chomwitt@ppp-94-66-136-162.home.otenet.gr) |
| 15:04.31 | *** join/#openmoko badcloud (~raanan@CBL217-132-239-62.bb.netvision.net.il) |
| 15:12.29 | *** join/#openmoko playya (~playya@unaffiliated/playya) |
| 15:24.10 | *** join/#openmoko DieMumiee (~DieMumiee@p579CBC43.dip.t-dialin.net) |
| 15:27.11 | *** join/#openmoko macko (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 15:27.45 | *** join/#openmoko samgee_ (~samgee@fsf/member/samgee) |
| 15:31.54 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 15:35.27 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 15:39.44 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 15:44.39 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 15:50.56 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 15:54.21 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 15:59.26 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 16:01.58 | *** join/#openmoko ferluszt (~peter@p5DD285E0.dip0.t-ipconnect.de) |
| 16:02.56 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 16:12.28 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 16:15.09 | *** join/#openmoko kirun (~kirun@78-86-154-194.zone2.bethere.co.uk) |
| 16:23.23 | *** join/#openmoko CVirus (~Satan@82.201.174.124) |
| 16:35.28 | *** join/#openmoko fove48 (~fove48@41.249.88.65) |
| 16:37.29 | *** join/#openmoko ferluszt1 (~peter@p5DD28503.dip0.t-ipconnect.de) |
| 16:44.49 | *** join/#openmoko [Rui] (~Rui@62.169.115.2.rev.optimus.pt) |
| 17:35.34 | *** join/#openmoko badcloud (~raanan@DSL217-132-222-218.bb.netvision.net.il) |
| 17:46.44 | *** join/#openmoko Q-Master (~qmaster@2.94.200.188) |
| 17:48.19 | *** join/#openmoko playya (~playya@93.216.223.19) |
| 17:48.20 | *** join/#openmoko playya (~playya@unaffiliated/playya) |
| 18:12.25 | *** join/#openmoko Bane^ (bane@shelli.fi) |
| 18:13.29 | *** join/#openmoko playya (~playya@93.216.223.19) |
| 18:13.33 | *** join/#openmoko playya (~playya@unaffiliated/playya) |
| 18:21.56 | *** join/#openmoko [Rui] (~Rui@88.210.101.143.rev.optimus.pt) |
| 18:22.10 | *** join/#openmoko Bane^ (bane@shelli.fi) |
| 18:57.09 | *** join/#openmoko playya (~playya@unaffiliated/playya) |
| 19:27.22 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 19:44.36 | *** join/#openmoko badcloud (~raanan@DSL217-132-222-218.bb.netvision.net.il) |
| 19:58.45 | *** join/#openmoko [Kame2] (~manuel@port-92-196-57-10.dynamic.qsc.de) |
| 20:27.36 | *** join/#openmoko kkb1101 (~kkb110@user-12lcboo.cable.mindspring.com) |
| 20:27.56 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 20:28.11 | *** join/#openmoko kkb110 (~kkb110@user-12lcboo.cable.mindspring.com) |
| 20:31.09 | *** join/#openmoko |Marco| (~marco@84.49.21.170) |
| 20:40.11 | *** join/#openmoko kkb110 (~kkb110@user-12lcboo.cable.mindspring.com) |
| 20:40.17 | *** join/#openmoko Kame2 (~manuel@port-92-196-57-10.dynamic.qsc.de) |
| 20:41.04 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 20:42.21 | *** join/#openmoko kkb110 (~kkb110@user-12lcboo.cable.mindspring.com) |
| 20:52.28 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 21:07.42 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 21:18.35 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 21:27.51 | *** join/#openmoko playya (~playya@unaffiliated/playya) |
| 21:29.35 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 21:40.24 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 21:53.14 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 22:04.19 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 22:15.10 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 22:29.59 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 22:40.47 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 22:49.37 | *** join/#openmoko t0t0 (~t0t0@hermes.weelya.com) |
| 22:51.08 | *** join/#openmoko badcloud (~raanan@DSL217-132-222-218.bb.netvision.net.il) |
| 22:51.45 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 22:54.27 | *** join/#openmoko Fox_Muldr (quakeman@frnk-4d01e007.pool.mediaWays.net) |
| 23:05.36 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 23:19.06 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 23:29.52 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 23:30.07 | *** join/#openmoko playya (~playya@unaffiliated/playya) |
| 23:40.45 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |
| 23:51.36 | *** join/#openmoko straszek (straszek@h-87-199-65-17.dolsatbelchatow.pl) |