* [Qemu-devel] [PATCH] sparc32 esp fix spurious interrupts in chip reset @ 2010-05-30 22:35 Artyom Tarasenko 2010-06-01 17:42 ` [Qemu-devel] " Blue Swirl 0 siblings, 1 reply; 9+ messages in thread From: Artyom Tarasenko @ 2010-05-30 22:35 UTC (permalink / raw) To: qemu-devel; +Cc: blauwirbel, Artyom Tarasenko lower interrupt during chip reset. Otherwise the ESP_RSTAT register may get out of sync with the IRQ line status. This effect became visible after commit 65899fe3 Signed-off-by: Artyom Tarasenko <atar4qemu@gmail.com> --- hw/esp.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/esp.c b/hw/esp.c index 0a8cf6e..0532c67 100644 --- a/hw/esp.c +++ b/hw/esp.c @@ -423,6 +423,7 @@ static void esp_reset(DeviceState *d) { ESPState *s = container_of(d, ESPState, busdev.qdev); + esp_lower_irq(s); memset(s->rregs, 0, ESP_REGS); memset(s->wregs, 0, ESP_REGS); s->rregs[ESP_TCHI] = TCHI_FAS100A; // Indicate fas100a -- 1.6.2.5 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: [PATCH] sparc32 esp fix spurious interrupts in chip reset 2010-05-30 22:35 [Qemu-devel] [PATCH] sparc32 esp fix spurious interrupts in chip reset Artyom Tarasenko @ 2010-06-01 17:42 ` Blue Swirl 2010-06-01 19:56 ` Artyom Tarasenko 0 siblings, 1 reply; 9+ messages in thread From: Blue Swirl @ 2010-06-01 17:42 UTC (permalink / raw) To: Artyom Tarasenko; +Cc: qemu-devel, Artyom Tarasenko [-- Attachment #1: Type: text/plain, Size: 748 bytes --] On Sun, May 30, 2010 at 10:35 PM, Artyom Tarasenko <atar4qemu@googlemail.com> wrote: > lower interrupt during chip reset. Otherwise the ESP_RSTAT register > may get out of sync with the IRQ line status. This effect became > visible after commit 65899fe3 Hard reset handlers should not touch qemu_irqs, because on cold start, the receiving end may be unprepared to handle the signal. See 0d0a7e69e853639b123798877e019c3c7ee6634a, bc26e55a6615dc594be425d293db40d5cdcdb84b and 42f1ced228c9b616cfa2b69846025271618e4ef5. For ESP there are two other sources of reset: signal from DMA and chip reset command. On those cases, lowering IRQ makes sense. So the correct fix is to refactor the reset handling a bit. Does this patch also fix your test case? [-- Attachment #2: 0001-esp-lower-IRQ-on-soft-reset.patch --] [-- Type: application/x-patch, Size: 2025 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: [PATCH] sparc32 esp fix spurious interrupts in chip reset 2010-06-01 17:42 ` [Qemu-devel] " Blue Swirl @ 2010-06-01 19:56 ` Artyom Tarasenko 2010-06-01 20:09 ` Blue Swirl 0 siblings, 1 reply; 9+ messages in thread From: Artyom Tarasenko @ 2010-06-01 19:56 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-devel 2010/6/1 Blue Swirl <blauwirbel@gmail.com>: > On Sun, May 30, 2010 at 10:35 PM, Artyom Tarasenko > <atar4qemu@googlemail.com> wrote: >> lower interrupt during chip reset. Otherwise the ESP_RSTAT register >> may get out of sync with the IRQ line status. This effect became >> visible after commit 65899fe3 > > Hard reset handlers should not touch qemu_irqs, because on cold start, > the receiving end may be unprepared to handle the signal. Wouldn't the real hardware lower irq on the hardware reset? And if it would not, would it still clear the corresponding bit in the ESP_RSTAT register? > See > 0d0a7e69e853639b123798877e019c3c7ee6634a, > bc26e55a6615dc594be425d293db40d5cdcdb84b and > 42f1ced228c9b616cfa2b69846025271618e4ef5. > > For ESP there are two other sources of reset: signal from DMA and chip > reset command. On those cases, lowering IRQ makes sense. > > So the correct fix is to refactor the reset handling a bit. Does this > patch also fix your test case? It does, but +static void esp_soft_reset(DeviceState *d) +{ + ESPState *s = container_of(d, ESPState, busdev.qdev); + + qemu_irq_lower(s->irq); Shouldn't it be esp_lower_irq(s)? What's going to happen to the DMA_INTR bit if dma was the source of the irq? + esp_hard_reset(d); +} + -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: [PATCH] sparc32 esp fix spurious interrupts in chip reset 2010-06-01 19:56 ` Artyom Tarasenko @ 2010-06-01 20:09 ` Blue Swirl 2010-06-01 20:16 ` Artyom Tarasenko 0 siblings, 1 reply; 9+ messages in thread From: Blue Swirl @ 2010-06-01 20:09 UTC (permalink / raw) To: Artyom Tarasenko; +Cc: qemu-devel On Tue, Jun 1, 2010 at 7:56 PM, Artyom Tarasenko <atar4qemu@googlemail.com> wrote: > 2010/6/1 Blue Swirl <blauwirbel@gmail.com>: >> On Sun, May 30, 2010 at 10:35 PM, Artyom Tarasenko >> <atar4qemu@googlemail.com> wrote: >>> lower interrupt during chip reset. Otherwise the ESP_RSTAT register >>> may get out of sync with the IRQ line status. This effect became >>> visible after commit 65899fe3 >> >> Hard reset handlers should not touch qemu_irqs, because on cold start, >> the receiving end may be unprepared to handle the signal. > > Wouldn't the real hardware lower irq on the hardware reset? Yes, but since qemu_irqs have no state, and on a cold start or system reset all other devices are guaranteed to be reset, the callback would be useless. > And if it would not, would it still clear the corresponding bit in > the ESP_RSTAT register? All registers are set to zero in the lines below. > >> See >> 0d0a7e69e853639b123798877e019c3c7ee6634a, >> bc26e55a6615dc594be425d293db40d5cdcdb84b and >> 42f1ced228c9b616cfa2b69846025271618e4ef5. >> >> For ESP there are two other sources of reset: signal from DMA and chip >> reset command. On those cases, lowering IRQ makes sense. >> >> So the correct fix is to refactor the reset handling a bit. Does this >> patch also fix your test case? > > It does, but > > +static void esp_soft_reset(DeviceState *d) > +{ > + ESPState *s = container_of(d, ESPState, busdev.qdev); > + > + qemu_irq_lower(s->irq); > > Shouldn't it be esp_lower_irq(s)? What's going to happen to the > DMA_INTR bit if dma was the source of the irq? Again, the registers are zeroed in esp_hard_reset(). Thanks for testing. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: [PATCH] sparc32 esp fix spurious interrupts in chip reset 2010-06-01 20:09 ` Blue Swirl @ 2010-06-01 20:16 ` Artyom Tarasenko 2010-06-04 19:13 ` Blue Swirl 0 siblings, 1 reply; 9+ messages in thread From: Artyom Tarasenko @ 2010-06-01 20:16 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-devel 2010/6/1 Blue Swirl <blauwirbel@gmail.com>: > On Tue, Jun 1, 2010 at 7:56 PM, Artyom Tarasenko > <atar4qemu@googlemail.com> wrote: >> 2010/6/1 Blue Swirl <blauwirbel@gmail.com>: >>> On Sun, May 30, 2010 at 10:35 PM, Artyom Tarasenko >>> <atar4qemu@googlemail.com> wrote: >>>> lower interrupt during chip reset. Otherwise the ESP_RSTAT register >>>> may get out of sync with the IRQ line status. This effect became >>>> visible after commit 65899fe3 >>> >>> Hard reset handlers should not touch qemu_irqs, because on cold start, >>> the receiving end may be unprepared to handle the signal. >> >> Wouldn't the real hardware lower irq on the hardware reset? > > Yes, but since qemu_irqs have no state, and on a cold start or system > reset all other devices are guaranteed to be reset, the callback would > be useless. > >> And if it would not, would it still clear the corresponding bit in >> the ESP_RSTAT register? > > All registers are set to zero in the lines below. > >> >>> See >>> 0d0a7e69e853639b123798877e019c3c7ee6634a, >>> bc26e55a6615dc594be425d293db40d5cdcdb84b and >>> 42f1ced228c9b616cfa2b69846025271618e4ef5. >>> >>> For ESP there are two other sources of reset: signal from DMA and chip >>> reset command. On those cases, lowering IRQ makes sense. >>> >>> So the correct fix is to refactor the reset handling a bit. Does this >>> patch also fix your test case? >> >> It does, but >> >> +static void esp_soft_reset(DeviceState *d) >> +{ >> + ESPState *s = container_of(d, ESPState, busdev.qdev); >> + >> + qemu_irq_lower(s->irq); >> >> Shouldn't it be esp_lower_irq(s)? What's going to happen to the >> DMA_INTR bit if dma was the source of the irq? > > Again, the registers are zeroed in esp_hard_reset(). How does it zero the _DMA_ registers? And sparc32_dma does share the IRQ line with ESP, doesn't it? > > Thanks for testing. > -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: [PATCH] sparc32 esp fix spurious interrupts in chip reset 2010-06-01 20:16 ` Artyom Tarasenko @ 2010-06-04 19:13 ` Blue Swirl 2010-06-04 20:30 ` Artyom Tarasenko 0 siblings, 1 reply; 9+ messages in thread From: Blue Swirl @ 2010-06-04 19:13 UTC (permalink / raw) To: Artyom Tarasenko; +Cc: qemu-devel On Tue, Jun 1, 2010 at 8:16 PM, Artyom Tarasenko <atar4qemu@googlemail.com> wrote: > 2010/6/1 Blue Swirl <blauwirbel@gmail.com>: >> On Tue, Jun 1, 2010 at 7:56 PM, Artyom Tarasenko >> <atar4qemu@googlemail.com> wrote: >>> 2010/6/1 Blue Swirl <blauwirbel@gmail.com>: >>>> On Sun, May 30, 2010 at 10:35 PM, Artyom Tarasenko >>>> <atar4qemu@googlemail.com> wrote: >>>>> lower interrupt during chip reset. Otherwise the ESP_RSTAT register >>>>> may get out of sync with the IRQ line status. This effect became >>>>> visible after commit 65899fe3 >>>> >>>> Hard reset handlers should not touch qemu_irqs, because on cold start, >>>> the receiving end may be unprepared to handle the signal. >>> >>> Wouldn't the real hardware lower irq on the hardware reset? >> >> Yes, but since qemu_irqs have no state, and on a cold start or system >> reset all other devices are guaranteed to be reset, the callback would >> be useless. >> >>> And if it would not, would it still clear the corresponding bit in >>> the ESP_RSTAT register? >> >> All registers are set to zero in the lines below. >> >>> >>>> See >>>> 0d0a7e69e853639b123798877e019c3c7ee6634a, >>>> bc26e55a6615dc594be425d293db40d5cdcdb84b and >>>> 42f1ced228c9b616cfa2b69846025271618e4ef5. >>>> >>>> For ESP there are two other sources of reset: signal from DMA and chip >>>> reset command. On those cases, lowering IRQ makes sense. >>>> >>>> So the correct fix is to refactor the reset handling a bit. Does this >>>> patch also fix your test case? >>> >>> It does, but >>> >>> +static void esp_soft_reset(DeviceState *d) >>> +{ >>> + ESPState *s = container_of(d, ESPState, busdev.qdev); >>> + >>> + qemu_irq_lower(s->irq); >>> >>> Shouldn't it be esp_lower_irq(s)? What's going to happen to the >>> DMA_INTR bit if dma was the source of the irq? >> >> Again, the registers are zeroed in esp_hard_reset(). > > How does it zero the _DMA_ registers? And sparc32_dma does share the > IRQ line with ESP, doesn't it? I'd suppose DMA registers are separate and they would not be cleared by for example ESP chip reset command. The IRQ goes from ESP to DMA, DMA has another line going to interrupt controller. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: [PATCH] sparc32 esp fix spurious interrupts in chip reset 2010-06-04 19:13 ` Blue Swirl @ 2010-06-04 20:30 ` Artyom Tarasenko 2010-06-09 20:35 ` Blue Swirl 0 siblings, 1 reply; 9+ messages in thread From: Artyom Tarasenko @ 2010-06-04 20:30 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-devel 2010/6/4 Blue Swirl <blauwirbel@gmail.com>: > On Tue, Jun 1, 2010 at 8:16 PM, Artyom Tarasenko > <atar4qemu@googlemail.com> wrote: >> 2010/6/1 Blue Swirl <blauwirbel@gmail.com>: >>> On Tue, Jun 1, 2010 at 7:56 PM, Artyom Tarasenko >>> <atar4qemu@googlemail.com> wrote: >>>> 2010/6/1 Blue Swirl <blauwirbel@gmail.com>: >>>>> On Sun, May 30, 2010 at 10:35 PM, Artyom Tarasenko >>>>> <atar4qemu@googlemail.com> wrote: >>>>>> lower interrupt during chip reset. Otherwise the ESP_RSTAT register >>>>>> may get out of sync with the IRQ line status. This effect became >>>>>> visible after commit 65899fe3 >>>>> >>>>> Hard reset handlers should not touch qemu_irqs, because on cold start, >>>>> the receiving end may be unprepared to handle the signal. >>>> >>>> Wouldn't the real hardware lower irq on the hardware reset? >>> >>> Yes, but since qemu_irqs have no state, and on a cold start or system >>> reset all other devices are guaranteed to be reset, the callback would >>> be useless. >>> >>>> And if it would not, would it still clear the corresponding bit in >>>> the ESP_RSTAT register? >>> >>> All registers are set to zero in the lines below. >>> >>>> >>>>> See >>>>> 0d0a7e69e853639b123798877e019c3c7ee6634a, >>>>> bc26e55a6615dc594be425d293db40d5cdcdb84b and >>>>> 42f1ced228c9b616cfa2b69846025271618e4ef5. >>>>> >>>>> For ESP there are two other sources of reset: signal from DMA and chip >>>>> reset command. On those cases, lowering IRQ makes sense. >>>>> >>>>> So the correct fix is to refactor the reset handling a bit. Does this >>>>> patch also fix your test case? >>>> >>>> It does, but >>>> >>>> +static void esp_soft_reset(DeviceState *d) >>>> +{ >>>> + ESPState *s = container_of(d, ESPState, busdev.qdev); >>>> + >>>> + qemu_irq_lower(s->irq); >>>> >>>> Shouldn't it be esp_lower_irq(s)? What's going to happen to the >>>> DMA_INTR bit if dma was the source of the irq? >>> >>> Again, the registers are zeroed in esp_hard_reset(). >> >> How does it zero the _DMA_ registers? And sparc32_dma does share the >> IRQ line with ESP, doesn't it? > > I'd suppose DMA registers are separate and they would not be cleared > by for example ESP chip reset command. The IRQ goes from ESP to DMA, > DMA has another line going to interrupt controller. But do we have separate DMA lines in qemu? If we do, I'm absolutely fine with qemu_irq_lower(s->irq) . If we don't, imagine the following scenario: DMA rises an IRQ, then esp chip reset happens, and then... DMA can't rise the IRQ anymore. -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: [PATCH] sparc32 esp fix spurious interrupts in chip reset 2010-06-04 20:30 ` Artyom Tarasenko @ 2010-06-09 20:35 ` Blue Swirl 2010-06-10 8:15 ` Artyom Tarasenko 0 siblings, 1 reply; 9+ messages in thread From: Blue Swirl @ 2010-06-09 20:35 UTC (permalink / raw) To: Artyom Tarasenko; +Cc: qemu-devel On Fri, Jun 4, 2010 at 8:30 PM, Artyom Tarasenko <atar4qemu@googlemail.com> wrote: > 2010/6/4 Blue Swirl <blauwirbel@gmail.com>: >> On Tue, Jun 1, 2010 at 8:16 PM, Artyom Tarasenko >> <atar4qemu@googlemail.com> wrote: >>> 2010/6/1 Blue Swirl <blauwirbel@gmail.com>: >>>> On Tue, Jun 1, 2010 at 7:56 PM, Artyom Tarasenko >>>> <atar4qemu@googlemail.com> wrote: >>>>> 2010/6/1 Blue Swirl <blauwirbel@gmail.com>: >>>>>> On Sun, May 30, 2010 at 10:35 PM, Artyom Tarasenko >>>>>> <atar4qemu@googlemail.com> wrote: >>>>>>> lower interrupt during chip reset. Otherwise the ESP_RSTAT register >>>>>>> may get out of sync with the IRQ line status. This effect became >>>>>>> visible after commit 65899fe3 >>>>>> >>>>>> Hard reset handlers should not touch qemu_irqs, because on cold start, >>>>>> the receiving end may be unprepared to handle the signal. >>>>> >>>>> Wouldn't the real hardware lower irq on the hardware reset? >>>> >>>> Yes, but since qemu_irqs have no state, and on a cold start or system >>>> reset all other devices are guaranteed to be reset, the callback would >>>> be useless. >>>> >>>>> And if it would not, would it still clear the corresponding bit in >>>>> the ESP_RSTAT register? >>>> >>>> All registers are set to zero in the lines below. >>>> >>>>> >>>>>> See >>>>>> 0d0a7e69e853639b123798877e019c3c7ee6634a, >>>>>> bc26e55a6615dc594be425d293db40d5cdcdb84b and >>>>>> 42f1ced228c9b616cfa2b69846025271618e4ef5. >>>>>> >>>>>> For ESP there are two other sources of reset: signal from DMA and chip >>>>>> reset command. On those cases, lowering IRQ makes sense. >>>>>> >>>>>> So the correct fix is to refactor the reset handling a bit. Does this >>>>>> patch also fix your test case? >>>>> >>>>> It does, but >>>>> >>>>> +static void esp_soft_reset(DeviceState *d) >>>>> +{ >>>>> + ESPState *s = container_of(d, ESPState, busdev.qdev); >>>>> + >>>>> + qemu_irq_lower(s->irq); >>>>> >>>>> Shouldn't it be esp_lower_irq(s)? What's going to happen to the >>>>> DMA_INTR bit if dma was the source of the irq? >>>> >>>> Again, the registers are zeroed in esp_hard_reset(). >>> >>> How does it zero the _DMA_ registers? And sparc32_dma does share the >>> IRQ line with ESP, doesn't it? >> >> I'd suppose DMA registers are separate and they would not be cleared >> by for example ESP chip reset command. The IRQ goes from ESP to DMA, >> DMA has another line going to interrupt controller. > > But do we have separate DMA lines in qemu? If we do, I'm absolutely fine with > qemu_irq_lower(s->irq) . If we don't, imagine the following scenario: DMA > rises an IRQ, then esp chip reset happens, and then... DMA can't rise > the IRQ anymore. What ESP does with its IRQ line does not stop DMA from using its line. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: [PATCH] sparc32 esp fix spurious interrupts in chip reset 2010-06-09 20:35 ` Blue Swirl @ 2010-06-10 8:15 ` Artyom Tarasenko 0 siblings, 0 replies; 9+ messages in thread From: Artyom Tarasenko @ 2010-06-10 8:15 UTC (permalink / raw) To: Blue Swirl; +Cc: qemu-devel 2010/6/9 Blue Swirl <blauwirbel@gmail.com>: > On Fri, Jun 4, 2010 at 8:30 PM, Artyom Tarasenko > <atar4qemu@googlemail.com> wrote: >> 2010/6/4 Blue Swirl <blauwirbel@gmail.com>: >>> On Tue, Jun 1, 2010 at 8:16 PM, Artyom Tarasenko >>> <atar4qemu@googlemail.com> wrote: >>>> 2010/6/1 Blue Swirl <blauwirbel@gmail.com>: >>>>> On Tue, Jun 1, 2010 at 7:56 PM, Artyom Tarasenko >>>>> <atar4qemu@googlemail.com> wrote: >>>>>> 2010/6/1 Blue Swirl <blauwirbel@gmail.com>: >>>>>>> On Sun, May 30, 2010 at 10:35 PM, Artyom Tarasenko >>>>>>> <atar4qemu@googlemail.com> wrote: >>>>>>>> lower interrupt during chip reset. Otherwise the ESP_RSTAT register >>>>>>>> may get out of sync with the IRQ line status. This effect became >>>>>>>> visible after commit 65899fe3 >>>>>>> >>>>>>> Hard reset handlers should not touch qemu_irqs, because on cold start, >>>>>>> the receiving end may be unprepared to handle the signal. >>>>>> >>>>>> Wouldn't the real hardware lower irq on the hardware reset? >>>>> >>>>> Yes, but since qemu_irqs have no state, and on a cold start or system >>>>> reset all other devices are guaranteed to be reset, the callback would >>>>> be useless. >>>>> >>>>>> And if it would not, would it still clear the corresponding bit in >>>>>> the ESP_RSTAT register? >>>>> >>>>> All registers are set to zero in the lines below. >>>>> >>>>>> >>>>>>> See >>>>>>> 0d0a7e69e853639b123798877e019c3c7ee6634a, >>>>>>> bc26e55a6615dc594be425d293db40d5cdcdb84b and >>>>>>> 42f1ced228c9b616cfa2b69846025271618e4ef5. >>>>>>> >>>>>>> For ESP there are two other sources of reset: signal from DMA and chip >>>>>>> reset command. On those cases, lowering IRQ makes sense. >>>>>>> >>>>>>> So the correct fix is to refactor the reset handling a bit. Does this >>>>>>> patch also fix your test case? >>>>>> >>>>>> It does, but >>>>>> >>>>>> +static void esp_soft_reset(DeviceState *d) >>>>>> +{ >>>>>> + ESPState *s = container_of(d, ESPState, busdev.qdev); >>>>>> + >>>>>> + qemu_irq_lower(s->irq); >>>>>> >>>>>> Shouldn't it be esp_lower_irq(s)? What's going to happen to the >>>>>> DMA_INTR bit if dma was the source of the irq? >>>>> >>>>> Again, the registers are zeroed in esp_hard_reset(). >>>> >>>> How does it zero the _DMA_ registers? And sparc32_dma does share the >>>> IRQ line with ESP, doesn't it? >>> >>> I'd suppose DMA registers are separate and they would not be cleared >>> by for example ESP chip reset command. The IRQ goes from ESP to DMA, >>> DMA has another line going to interrupt controller. >> >> But do we have separate DMA lines in qemu? If we do, I'm absolutely fine with >> qemu_irq_lower(s->irq) . If we don't, imagine the following scenario: DMA >> rises an IRQ, then esp chip reset happens, and then... DMA can't rise >> the IRQ anymore. > > What ESP does with its IRQ line does not stop DMA from using its line. Then I'm fine with your patch. -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/ ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2010-06-10 8:15 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-05-30 22:35 [Qemu-devel] [PATCH] sparc32 esp fix spurious interrupts in chip reset Artyom Tarasenko 2010-06-01 17:42 ` [Qemu-devel] " Blue Swirl 2010-06-01 19:56 ` Artyom Tarasenko 2010-06-01 20:09 ` Blue Swirl 2010-06-01 20:16 ` Artyom Tarasenko 2010-06-04 19:13 ` Blue Swirl 2010-06-04 20:30 ` Artyom Tarasenko 2010-06-09 20:35 ` Blue Swirl 2010-06-10 8:15 ` Artyom Tarasenko
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).