| --- Log opened Wed Aug 21 00:00:21 2013 | ||
| stekern | _franck_: the store buffer is placed between the lsu and the memory | 02:14 |
|---|---|---|
| stekern | it could be placed *before* the cache too I guess, but I have it running in parallell with the cache since we only have write through caches ritght now | 02:15 |
| stekern | the one I'm designing will be dumb as a stone (at least in it's first incarnation), writes are filled up in it in-order, any incoming load while the buffer is not empty will stall the pipeline | 02:17 |
| stekern | a more advanced store-buffer would keep track of the contents of the store-buffer and would only stall when an load to something currently in the store-buffer occurs | 02:18 |
| stekern | an even more advanced one would read the value out of the store buffer | 02:19 |
| stekern | a really advanced one would re-order the writes and bundle together several smaller than word writes to the same word into one write (imagine for example copying data into to a char* buffer) | 02:22 |
| stekern | so, the benefits of our dumb as a stone store buffer will be quite limited, but it will have one important case where it will help. The typical C function. | 02:24 |
| stekern | because there you very often have: a set of stack writes. actual code (which often at least start with a non-load instruction). a set of stack loads | 02:25 |
| stekern | so you get the stack writes filling up the buffer and having the buffer emptying while running your function | 02:28 |
| stekern | one problem I hadn't considered - to get the pc of an dbus error exception, I need to save that in the store buffer as well... | 03:32 |
| stekern | tintenammae: you mean in newlib/libgloss? | 05:47 |
| tintenammae | stekern: yep | 05:47 |
| tintenammae | not sure it is supposed to work out of the box or not? thanks for replying :) | 05:48 |
| stekern | not sure neither, I'd assume it doesn't work and check in the source ;) | 05:52 |
| tintenammae | I should probably build the toolchain then, rather than using the one in that virtualbox image :| | 05:56 |
| olofk | tintenammae: stdin/stdout is connected to your UART, right? | 05:57 |
| tintenammae | stdout is... so I assumed stdin would be | 05:58 |
| olofk | You could try to send something to the UART and read out the UART rx register manually, with a debugger, or a small C program | 05:59 |
| tintenammae | good point | 05:59 |
| olofk | Just to rule out any hardware problems | 06:00 |
| tintenammae | I did just notice there were two extra uarts in board.h I don't remember seeing in quartus. Input works in bootloader. | 06:00 |
| jeremybennett | tintenammae: It is possible that just stdout is supported, if the newlib is based on the simulator newlib. | 06:01 |
| stekern | simulator newlib? | 06:01 |
| jeremybennett | The minimal newlib was designed for regression testing the tool chain against Or1ksim, and all it provided was support for stdout using l.nop 3 | 06:01 |
| jeremybennett | stekern: Should have been more precise - the libgloss BSP to support the Or1ksim simulator | 06:02 |
| jeremybennett | That is the original newlib implementation. | 06:02 |
| tintenammae | oh right... also some things might have changed since that virualbox image, right? | 06:02 |
| jeremybennett | tintenammae: Certainly - always a good idea to build from source | 06:03 |
| tintenammae | hehe I'm now checking out that or1k-gcc, takes ages | 06:04 |
| tintenammae | 450 MB down... | 06:04 |
| jeremybennett | yup - GCC is big | 06:04 |
| jeremybennett | third biggest program on any Linux system (after the kernel and Mozilla) | 06:04 |
| jeremybennett | 5MLOC | 06:04 |
| stekern | jeremybennett: ah, well, he obviously have stdout connected to the uart and not l.nop 3 | 06:05 |
| jeremybennett | stekern: Yes - of course. But if it started from the old newlib, the syscalls to support stdin may not be there. | 06:05 |
| jeremybennett | So you'll just have stdout connected to the UART. | 06:05 |
| jeremybennett | Just a hypothesis of course. From memory I was sure we fixed stdin for real HW. | 06:06 |
| stekern | juliusb probably knows since he was the one seriously poking at libgloss last | 06:06 |
| stekern | jeremybennett: how about Xorg? | 06:06 |
| stekern | actually, google tells me its not that big.. 500KLOC | 06:08 |
| jeremybennett | stekern: Xorg or GCC? | 06:08 |
| jeremybennett | LOC is a black art anyway. I rely on the figures from David Wheeler's sloccount program. | 06:09 |
| stekern | Xorg | 06:09 |
| stekern | true, especially when they are taken from a random google hit ;) | 06:09 |
| stekern | libreoffice is probably among the top anyway | 06:10 |
| stekern | again, random google number: 7MLOC | 06:11 |
| jeremybennett | Wikipedia has a bit on the subject http://en.wikipedia.org/wiki/Source_lines_of_code | 06:12 |
| tintenammae | another question - when connecting debug proxy, it tends to steal or mix up the ttyUSBx. does that happen for everyone? | 06:12 |
| stekern | yes, but when you switch over to openocd you get rid of that problem | 06:13 |
| jeremybennett | Always used to for me. A nicety of the USB interface on Linux. Never really got to the bottom of it. | 06:13 |
| tintenammae | ok, that openocd seems pretty good then | 06:14 |
| stekern | I guess it's probably something the closed source ftd2xx does | 06:14 |
| stekern | openocd use libftdi | 06:15 |
| jeremybennett | The FTDI chip needs two channels - one for USB UART, one for USB JTAG. | 06:15 |
| jeremybennett | It always seems to get muddled about which one is which. A race somewhere in the setup I guess. | 06:16 |
| tintenammae | I see | 06:16 |
| stekern | yeah, and then the ttyUSBx would be swapped for ttyUSBy | 06:16 |
| tintenammae | out of interest do most people use linux or not? | 06:20 |
| tintenammae | as opposed to newlib | 06:21 |
| jeremybennett | tintenammae: As their development machine or on OpenRISC? | 06:22 |
| olofk | No idea actually. We mostly hear about the linux stuff, but I guess that most commercial applications use it for bare-metal | 06:22 |
| tintenammae | I see :P | 06:23 |
| tintenammae | yeah on openrisc | 06:23 |
| stekern | yeah, but I wonder how many of the baremetal actually "use" newlib | 06:23 |
| olofk | stekern: As opposed to using an RTOS? | 06:24 |
| stekern | yeah, that's what I'm getting at | 06:24 |
| olofk | I think most people use Windows CE | 06:25 |
| stekern | I, for some reason, believe you are not serious ;) | 06:25 |
| jeremybennett | The TechEdSat system used Linux. I would guess the Samsung set top boxes also do. The NXP/Jennic Zigbee is almost certainly bare metal | 06:26 |
| olofk | stekern: Have you figured out what the Allwinner A31 is running? | 06:27 |
| stekern | olofk: yeah, it's baremetal | 06:29 |
| tintenammae | (building gcc now, wondered what the meaning of --enable-sim --disable-or1ksim was?) | 06:29 |
| stekern | bare-bare, not newlib or modified newlib | 06:30 |
| stekern | since it has that (nice) exception vector workaround | 06:30 |
| olofk | tintenammae: Good question. I'm not sure about most of the configure options. Sounds like stuff that could be mentioned on the wiki as soon as someone writes an explanation | 06:31 |
| stekern | --enable-sim enables the cgen simulator, --disable-or1ksim disables or1ksim | 06:33 |
| stekern | but that's not gcc that you're building, it's or1k-src | 06:33 |
| olofk | Is the cgen simulator any useful? IIRC it required some peripheral emulators to be useful for running the testsuite | 06:35 |
| tintenammae | I see. So probably should enable-or1ksim, right? (I am thinking of it while gcc is building slowly :P) | 06:35 |
| stekern | olofk: you can use it to run the testsuite against the or1k-elf toolchain | 06:36 |
| tintenammae | wait another question... I remember reading something in the post about porting newlib about it being different for the sim and for hardware? What's up with that? | 06:37 |
| olofk | Does that mean that we only need or1ksim as a stand-alone simulator now? | 06:37 |
| olofk | tintenammae: The board-specific parts (memory map and UART drivers and stuff) are kept in a separate archive. That part is different between the simulator and hw | 06:38 |
| stekern | I think you need it to run the gdb testsuite (_franck_ help me out here) and you of course need it to run the or1k-linux-* toolchain | 06:39 |
| olofk | stekern: "run" the or1k-linux- toolchain? Do you mean build or test here? | 06:39 |
| stekern | but you can use a stand-alone or1ksim for the or1k-linux-* toolchains | 06:39 |
| stekern | sorry, run the gcc regression test suite against a simulator | 06:40 |
| stekern | you can run it against real hardware too | 06:40 |
| olofk | ah.. ok. That makes sense. | 06:40 |
| tintenammae | olofk: thanks, but so long as the gcc command has -mboard=ordb2a, am I right in thinking I shouldn't have to worry about that any more? | 06:40 |
| stekern | theoretically, with native gcc, we should even be able to run the regression suite *on* the hardware | 06:41 |
| olofk | To sum it up then, should we use --enable-sim --disable-or1ksim for or1k-src then? | 06:42 |
| stekern | I think so yes, I think knowledge about or1ksim all together in or1k-src was brought in by _franck_, so he would be able to run the gdb tests | 06:43 |
| stekern | basically, if you're not intending to run any regression tests, you could do --disable-sim as well | 06:44 |
| tintenammae | ok then :P | 06:47 |
| stekern | olofk: (DOTT) I feel you... | 06:53 |
| olofk | I love that about gentoo, that you can just do equery uses <package> to get a quick to-the-point explanation of all config options | 07:02 |
| _franck_ | --enable-sim makes gdb to include a simulator (target sim), by default, the simulator used is or1ksim | 07:05 |
| _franck_ | if you want the cgen sim, use --disable-or1ksim | 07:05 |
| _franck_ | and yes, it is only usefull for regression tests | 07:06 |
| _franck_ | olofk: in orpsocv3, is it possible to apply some patch to a core only for some choosen system ? | 07:08 |
| _franck_ | let's say I need a patch to make the xxx_core to work on the yyy_board | 07:08 |
| olofk | _franck_: No, I've been thinking about adding that feature, but I wanted to wait to see if it is really needed to have board-specific patches | 07:17 |
| olofk | For example, I know that the current ethmac is a bit problematic as it only supports MII, but I plan to solve that by adding a separe MII<->RMII and MII<->SMII converters | 07:18 |
| _franck_ | this board specific patch feature could be a staging area for patch. This could be usefull when you work localy on a new patch on your own board | 07:27 |
| _franck_ | of course you can add this new patch in the core directory | 07:27 |
| stekern | I think you can avoid most of board specific patches by having patches that also add a config parameter to apply the functionality the patch offer | 07:28 |
| olofk | _franck_: orpsocv3 supports multiple cores_root directories that you can set in orpsoc.conf (not sure if that works as intended) or by adding one or more --cores_root= arguments on the command line (quite sure that works). The idea is that if you have cores with the same name in several cores directories, the last one takes precedence (quite sure that doesn't work right now) | 07:32 |
| olofk | Very much like gentoo overlays | 07:32 |
| _franck_ | ok | 07:32 |
| olofk | But it's really good to know what features people are looking for, so keep the questions coming | 07:33 |
| _franck_ | olofk: the cores will be get from github openrisc now ? If we want to add a core we add it there ? | 07:33 |
| olofk | orpsoc supports downloading stuff from github or opencores svn right now, but it will be easy to add more options. You can also use a core directly on your machine | 07:34 |
| olofk | The [provider] section in the .core file tells orpsoc if it should get the core from opencores/github, or if it's stored in the same directory as the .core file | 07:36 |
| _franck_ | I got this part ;) Let me be more clear | 07:36 |
| _franck_ | I have a de1.core, with depend = wb_sdram_crtl | 07:37 |
| _franck_ | so there will be a wb_sdram_ctrl.core in $install_patch/cores right ? | 07:37 |
| _franck_ | s/will/must | 07:38 |
| stekern | ...which reminds me, I should put that little beast somewhere seperately | 07:38 |
| _franck_ | s/patch/path | 07:38 |
| stekern | _and_ write some proper testbenches for it | 07:38 |
| tintenammae | when building or1k-src with --disable-itcl --disable-tk --disable-tcl, when make calls configure again it fails with "could not find private tcl headers". Any easy way round that? | 07:38 |
| _franck_ | stekern: true | 07:38 |
| olofk | Yes. The collection of cores on openrisc/orpsoc-cores shouldn't have any dependencies on cores in other collections. Hopefully this will work out fine, but only time will tell :) | 07:39 |
| stekern | as it is now, I've only run the orpsoc tests (and a fair amount of "real world use") against it | 07:39 |
| olofk | _franck_: But if you for some reason would like to keep both wb_sdram_ctrl and de1 in a separate collection, that would work too | 07:40 |
| olofk | But please don't :) | 07:40 |
| stekern | I wonder if I can pull out the git history from orpsocv2 and apply that to a seperate git repository | 07:40 |
| stekern | maybe my new friend filter-branch knows how to do that | 07:40 |
| stekern | *separate | 07:41 |
| _franck_ | olofk: I mean do you fetch this openrisc/orpsoc-cores directory from github or it is included in your orpsocv3 base ? | 07:42 |
| * _franck_ and olofk have hard time to understand each other ;) | 07:43 | |
| olofk | hahaha | 07:43 |
| stekern | tintenammae: that sounds familiar, but I'm not sure how I solved it, perhaps just installed tcl | 07:44 |
| olofk | _franck_: orpsoc-cores is a separate project now. I might add something to orpsoc to automatically download it, but right now it needs to be downloaded as a separate package | 07:44 |
| _franck_ | if there is any modification to wb_arbiter.v, should the patch be applied to orpsoccores/cores/wb_arbiter.v | 07:45 |
| stekern | git submodule? | 07:45 |
| olofk | Man, this will cause some confusion for those who used orpsocv2 where everything but the kitchen sink is included | 07:45 |
| olofk | Yes | 07:45 |
| olofk | I might move wb_bfm and wb_intercon to separate projects at some point. The could be useful in other contexts too, but right now it's too much overhead | 07:47 |
| _franck_ | this openrisc/orpsoc-cores confused me | 07:47 |
| olofk | Also, if you want to package jtag_vpi as a separate project, that would be cool. I stored a local copy to avoid pulling in your whole orpsocv2 fork | 07:47 |
| olofk | _franck_: Are you less confused, or should we continue to try and understand each other :) | 07:48 |
| _franck_ | let's wait 2 or 3 more questions to come, I'll tell you later about my confusion degree :) | 07:48 |
| _franck_ | if I want to add stekern wb_sdram_ctrl.core should I send it to you ? | 07:49 |
| olofk | _franck_: Yes | 07:50 |
| stekern | olofk: what was the motivation behind breaking out the orpsoc-cores? (I'm not saying it's wrong) | 07:50 |
| _franck_ | so this openrisc/orpsoc-cores is useless ? | 07:50 |
| _franck_ | you sould move orpsocv3 to github so we can send you patch easily | 07:51 |
| olofk | stekern: I think the collection of cores will be updated much more often than orpsoc itself. It will also allow people to use orpsoc for other non-openrisc related things | 07:51 |
| olofk | _franck_: I am planning to do that now when I have a tagged release | 07:51 |
| _franck_ | ok great | 07:52 |
| stekern | I see, so orpsoc is actually not an orpsoc anymore but a build system | 07:52 |
| _franck_ | for now, I'll put the wb_sdram_ctrl in my system/de1 directory | 07:52 |
| olofk | _franck_: Do that. | 07:53 |
| stekern | _franck_: why does it matter where the git repo is? In regard to easiness of sending patches? | 07:53 |
| olofk | _franck_: We probably want wb_sdram_ctrl in the official orpsoc-cores, so you could also pull the openrisc/orpsoc-cores tree and give me a pull request when you are happy with the .core file | 07:55 |
| stekern | olofk: orpsoc not being orpsoc is fine I suppose, it'll just cause some initial confusion (as you said) for orpsocv2 users | 07:55 |
| tintenammae | stekern: thanks, already had it installed on gentoo but may need another package | 07:55 |
| _franck_ | stekern: well it doesn't | 07:55 |
| olofk | stekern: Yes. I'm confident that this will cause a lot of confusion. Hopefully I will have some time to do a few blog posts and write some documentation | 07:56 |
| olofk | tintenammae: Which configure options do you use? | 07:58 |
| tintenammae | olofk ../configure --target=or1k-elf --prefix=whatever --enable-shared --disable-itcl --disable-tk --disable-tcl --disable-winsup --disable-libgui --disable-rda --disable-sid --disable-sim --disable-or1ksim --enable-gdb --with-sysroot --enable-newlib --enable-libgloss | 08:02 |
| tintenammae | I just installed tcllib and I already had tcl installed on gentoo before this... I think the part that trips it up is "configuring in build-gnulib | 08:04 |
| olofk | Only thing I can see is that I use --disable-gdb in mine | 08:05 |
| tintenammae | not sure what is meant by configure --disable-option-checking? | 08:05 |
| tintenammae | bother now another one... gcc -g -O2 -o spu spu.o / gcc error: spu.o no such file or directory | 08:10 |
| -!- Netsplit *.net <-> *.split quits: blueCmd | 08:11 | |
| -!- Netsplit over, joins: blueCmd | 08:12 | |
| tintenammae | olofk: thanks for your hint about disable-gdb, I think I have toolchain now | 08:51 |
| tintenammae | olofk: the tcl one appeared fixed by the --disable-gdb and the spu one something to do with build directory | 08:51 |
| tintenammae | I wondered if anyone experienced hanging in __uart_getc() and why? Busy waiting for uart data ready without using that function works fine. As does reading from Uart fifo without waiting in __uart_getc() | 11:17 |
| stekern | what does it do? | 11:21 |
| stekern | I mean code wise | 11:22 |
| tintenammae | this is for reading input... | 11:22 |
| tintenammae | what it does is a do loop until bit 0 of the uart status register is 1, and then return the value in the uart data register | 11:23 |
| stekern | so isn't that the same as your "busy waiting for uart data"? | 11:24 |
| tintenammae | I thought it was hence why I was asking... | 11:24 |
| stekern | sounds weird, but I don't think I've ever used it | 11:27 |
| tintenammae | ok, I'll look at it a bit more | 11:28 |
| _franck_ | olofk: what about an "orpsoc clean my_system" ? | 12:25 |
| olofk | _franck_: I need to handle that better, but in the meantime you can just do rm -rf build or run "orpsoc sim --force" to clean out before running | 13:09 |
| olofk | Same problem with caches. There are no checks to see if they are outdated | 13:10 |
| olofk | Was that what you meant, or did we misunderstand each other again? :) | 13:11 |
| _franck_ | c'etait exactement ce que j'avais compris ! :) | 13:19 |
| _franck_ | that is perfectly clear | 13:19 |
| olofk | :) | 13:23 |
| olofk | Just curious, how frustrated did you get before you realized that the code wasn't recompiled? :) | 13:24 |
| _franck_ | not that much, that's a classic one | 13:26 |
| olofk | I propose that we officially rename the signal name of the date returned from wishbone slaves. It's a fucking pain to avoid name clashes with data going in the other direction | 14:17 |
| olofk | I've been using sdt (Slave data) internally when I needed to distinguish. | 14:17 |
| _franck_ | while I was copying your job (in system/generic) I was wondering what sdt stand for | 14:30 |
| _franck_ | is that "intgen" usefull in orpsoc ? | 14:31 |
| olofk | _franck_: I think intgen is used for generating interrupts from software. It seems like a good thing to have. | 14:33 |
| _franck_ | ok, I'll remove it :) | 14:34 |
| olofk | Not sure if it's used except for in one testcase in orpsocv2 | 14:35 |
| stekern | olofk: I agree, but I think 'read' and 'write' would be more appropriate | 14:50 |
| stekern | ...and I was confused what date you were speaking about first ;) | 14:51 |
| olofk | stekern: How about keeping write as dat and renaming read to rdt? That could also mean return | 14:51 |
| stekern | and I'm getting more and more convinced that the _o and _i notion is not a great idea | 14:52 |
| olofk | I would also like to rename we to wre, as it fucks up my pretty columns all the time :) | 14:52 |
| stekern | at least in the light of interconnect | 14:53 |
| olofk | Yes. And interconnects seem to be 90% of what I'm doing in orpsoc | 14:53 |
| stekern | if you have problem keeping track of your in and outputs in the module, then it's probably on the edge of bloated | 14:55 |
| olofk | ...said the guy who smacked on a Avalon interface to mor1kx ;) | 14:56 |
| stekern | ah, but I can keep track of'em, don't worry | 14:57 |
| stekern | the nicest solution to that problem would be if we'd have the top level generated with the bus interface the user wants | 15:04 |
| olofk | I agree. I'm currently writing my first orpsoc code generator to help with the interconnects | 15:06 |
| olofk | I try to avoid generated code as much as possible, but it makes sense in some cases | 15:07 |
| stekern | as long as there's no real logic in it I reckon generated code is fine | 15:12 |
| olofk | Yeah, I think that's the key. It can get really messy if you try to autogenerate RTL | 15:13 |
| stekern | i.e. code you wouldn't change by hand anyway | 15:13 |
| stekern | like the mor1kx top module | 15:13 |
| olofk | Yes, that would be really nice to have | 15:14 |
| ysionneau | maybe you could use migen for that? | 15:46 |
| ysionneau | verilog code generated from python description | 15:46 |
| stekern | ysionneau: that thought has certainly crossed my mind | 15:47 |
| ysionneau | it has a library for wishbone interconnect | 15:47 |
| stekern | I got most of the mor1kx-dev-env tests running with the store buffer now | 19:33 |
| stekern | failing are of course the dbus error ones, since I haven't fixed that | 19:33 |
| stekern | but it seems it has brought out another bug, something in the register file | 19:34 |
| stekern | which of course is "nice", then that get bonus fixed | 19:36 |
| stekern | no, scratch that, I thought it was a normal function call that would be writing r9, but it's a tail call so the value of r9 is loaded from the stack and then a normal jump is performed to the function I was looking at | 19:40 |
| stekern | and that load is not right | 19:40 |
| olofk | Just noticed two weird things about DOTT | 19:53 |
| olofk | 1. Why doesn't Ted turn red in the future when Bernard paints him to fool IRS | 19:53 |
| olofk | 2. IT'S TWENTY YEARS OLD! | 19:53 |
| _franck_ | olofk: http://pastie.org/8257663 | 20:02 |
| olofk | _franck_: Thanks | 20:30 |
| olofk | applied and pushed | 20:30 |
| olofk | ysionneau: migen is your baby too, right? | 20:31 |
| _franck_ | there is more like this | 20:31 |
| stekern | olofk: 1. I remember always wondering about that too ;) | 20:33 |
| olofk | Just give me a shout if you find anything that should be applied. I haven't touched the generic system for a while. Most of the work has been on or1200-generic | 20:33 |
| _franck_ | olofk: are you sure your wb_data_resize works great ? | 20:33 |
| _franck_ | assign wbs_adr_o = wbm_adr_i; | 20:33 |
| olofk | _franck_: whoops | 20:33 |
| ysionneau | olofk: not at all, it's lekernel's baby | 20:34 |
| ysionneau | (Sébastien Bourdeauducq) | 20:35 |
| olofk | Ahh.. I see that the generic system uses wb_utils. That should be replaced with stuff from wb_intercon instead | 20:35 |
| olofk | ysionneau: Ah ok. Sorry for the mix up | 20:36 |
| ysionneau | no problem | 20:36 |
| _franck_ | olofk: wb_utils and wb_intercon files looks similar | 20:37 |
| olofk | _franck_: wb_intercon is based on the stuff in wb_utils, but it has been improved. | 20:38 |
| _franck_ | we still have assign wbs_adr_o = wbm_adr_i there. And I don't think this is correct. | 20:42 |
| _franck_ | if you do a byte access at address 1 on a 32bits bus, you'll have 0 on the address and sel will be 0010 on the 8bits side of the bridge you'll have address = 1 | 20:42 |
| _franck_ | *(add a "." after 0010) | 20:43 |
| olofk | hmm.. | 20:44 |
| olofk | I see it now | 20:47 |
| olofk | I'll just add a static 32<->8 conversion. I haven't seen any usecases for converting between other widths | 20:48 |
| _franck_ | ok | 20:49 |
| _franck_ | plus in system/generic, there is a byte wide bus but no wb_data_resize core instanciated | 20:53 |
| olofk | I plan to replace the whole interconnect in system/generic with something that looks more like the interconnect in systems/or1200-generic | 20:55 |
| olofk | My interconnect generator is almost finished now | 20:56 |
| _franck_ | ok I'll wait until then | 20:56 |
| _franck_ | I'm sorry I have only criticism agains orpsocv3 :| | 20:58 |
| olofk | _franck_: Criticism is probably what I need most right now to get things done :) | 21:07 |
| _franck_ | :) | 21:19 |
| _franck_ | good night | 21:19 |
| olofk | Good night | 21:19 |
| olofk | There is support for wishbone over USB in the 3.10 kernels. That's cool. | 21:22 |
| --- Log closed Thu Aug 22 00:00:22 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!