* Re: [ipw3945-devel] [PATCH 2/5] iwlwifi: iwl3945 synchronize interruptand tasklet for down iwlwifi
From: Joonwoo Park @ 2008-01-14 9:42 UTC (permalink / raw)
To: Zhu, Yi, netdev
Cc: Chatre, Reinette, linux-wireless, ipw3945-devel, linux-kernel
In-Reply-To: <478B1EBF.8030701@gmail.com>
I'm so sorry for mangled patch.
resending patch with preformat html from thunderbird.
After disabling interrupts, it's possible irq & tasklet is pending or running
This patch eleminates races for down iwlwifi.
Since synchronize_irq can introduce iwl_irq_tasklet, tasklet_kill should be
called after doing synchronize_irq.
To avoid races between iwl_synchronize_irq and iwl_irq_tasklet
STATUS_INT_ENABLED flag is needed.
Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
---
drivers/net/wireless/iwlwifi/iwl3945-base.c | 33 ++++++++++++++++++++++-----
1 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 6e20725..f98cd4f 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -4405,6 +4405,14 @@ static void iwl_print_rx_config_cmd(struct iwl_rxon_cmd *rxon)
}
#endif
+static void iwl_synchronize_interrupts(struct iwl_priv *priv)
+{
+ synchronize_irq(priv->pci_dev->irq);
+ /* synchornize_irq introduces irq_tasklet,
+ * tasklet_kill should be called after doing synchronize_irq */
+ tasklet_kill(&priv->irq_tasklet);
+}
+
static void iwl_enable_interrupts(struct iwl_priv *priv)
{
IWL_DEBUG_ISR("Enabling interrupts\n");
@@ -4413,7 +4421,7 @@ static void iwl_enable_interrupts(struct iwl_priv *priv)
iwl_flush32(priv, CSR_INT_MASK);
}
-static inline void iwl_disable_interrupts(struct iwl_priv *priv)
+static inline void __iwl_disable_interrupts(struct iwl_priv *priv)
{
clear_bit(STATUS_INT_ENABLED, &priv->status);
@@ -4427,6 +4435,13 @@ static inline void iwl_disable_interrupts(struct iwl_priv *priv)
iwl_flush32(priv, CSR_INT);
iwl_write32(priv, CSR_FH_INT_STATUS, 0xffffffff);
iwl_flush32(priv, CSR_FH_INT_STATUS);
+}
+
+static inline void iwl_disable_interrupts(struct iwl_priv *priv)
+{
+ __iwl_disable_interrupts(priv);
+
+ iwl_synchronize_interrupts(priv);
IWL_DEBUG_ISR("Disabled interrupts\n");
}
@@ -4708,7 +4723,8 @@ static void iwl_irq_tasklet(struct iwl_priv *priv)
IWL_ERROR("Microcode HW error detected. Restarting.\n");
/* Tell the device to stop sending interrupts */
- iwl_disable_interrupts(priv);
+ __iwl_disable_interrupts(priv);
+ IWL_DEBUG_ISR("Disabled interrupts\n");
iwl_irq_handle_error(priv);
@@ -4814,8 +4830,11 @@ static void iwl_irq_tasklet(struct iwl_priv *priv)
IWL_WARNING(" with FH_INT = 0x%08x\n", inta_fh);
}
- /* Re-enable all interrupts */
- iwl_enable_interrupts(priv);
+ /* To avoid race when device goes down,
+ * it should be discarded to enable interrupts */
+ if (test_bit(STATUS_INT_ENABLED, &priv->status))
+ /* Re-enable all interrupts */
+ iwl_enable_interrupts(priv);
#ifdef CONFIG_IWLWIFI_DEBUG
if (iwl_debug_level & (IWL_DL_ISR)) {
@@ -4876,8 +4895,10 @@ unplugged:
return IRQ_HANDLED;
none:
- /* re-enable interrupts here since we don't have anything to service. */
- iwl_enable_interrupts(priv);
+ if (test_bit(STATUS_INT_ENABLED, &priv->status))
+ /* re-enable interrupts here since we don't have anything
+ * to service. */
+ iwl_enable_interrupts(priv);
spin_unlock(&priv->lock);
return IRQ_NONE;
}
---
Thanks,
Joonwoo
^ permalink raw reply related
* Re: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22
From: Zhang, Yanmin @ 2008-01-14 9:38 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: LKML, Netdev
In-Reply-To: <Pine.LNX.4.64.0801141118450.31652@kivilampi-30.cs.helsinki.fi>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1096 bytes --]
On Mon, 2008-01-14 at 11:21 +0200, Ilpo Järvinen wrote:
> On Mon, 14 Jan 2008, Ilpo Järvinen wrote:
>
> > On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
> >
> > > On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
> > > >
> > > > As a matter of fact, 2.6.23 has about 6% regression and 2.6.24-rc's
> > > > regression is between 16%~11%.
> > > >
> > > > I tried to use bisect to locate the bad patch between 2.6.22 and 2.6.23-rc1,
> > > > but the bisected kernel wasn't stable and went crazy.
> >
> > TCP work between that is very much non-existing.
>
> I _really_ meant 2.6.22 - 2.6.23-rc1, not 2.6.24-rc1 in case you had a
> typo
I did bisect 2.6.22 - 2.6.23-rc1. I also tested it on the latest 2.6.24-rc.
> there which is not that uncommon while typing kernel versions... :-)
Thanks. I will retry bisect and bind the server/client to the same logical processor, where
I hope the result is stable this time when bisecting.
Manual testing showed there is still same or more regression if I bind the
processes on the same cpu.
Thanks a lot!
-yanmin
^ permalink raw reply
* Re: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22
From: Ilpo Järvinen @ 2008-01-14 9:21 UTC (permalink / raw)
To: Zhang, Yanmin; +Cc: LKML, Netdev
In-Reply-To: <Pine.LNX.4.64.0801141036400.31652@kivilampi-30.cs.helsinki.fi>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 628 bytes --]
On Mon, 14 Jan 2008, Ilpo Järvinen wrote:
> On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
>
> > On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
> > >
> > > As a matter of fact, 2.6.23 has about 6% regression and 2.6.24-rc's
> > > regression is between 16%~11%.
> > >
> > > I tried to use bisect to locate the bad patch between 2.6.22 and 2.6.23-rc1,
> > > but the bisected kernel wasn't stable and went crazy.
>
> TCP work between that is very much non-existing.
I _really_ meant 2.6.22 - 2.6.23-rc1, not 2.6.24-rc1 in case you had a
typo there which is not that uncommon while typing kernel versions... :-)
--
i.
^ permalink raw reply
* Re: [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
From: David Miller @ 2008-01-14 8:54 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: herbert, netdev
In-Reply-To: <Pine.LNX.4.64.0801140952100.31652@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Mon, 14 Jan 2008 10:33:34 +0200 (EET)
> Thanks anyway for the tips & all, I think we have it now working
> and I can return to inlines and rexmit_skb_hint things & other TCP
> stuff rather than this hinderance. I've some interesting results
> from net header inlines checks I ran overnight :-).
Great, I look forward to seeing it :)
^ permalink raw reply
* Re: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22
From: Ilpo Järvinen @ 2008-01-14 8:44 UTC (permalink / raw)
To: Zhang, Yanmin; +Cc: LKML, Netdev
In-Reply-To: <1200043854.3265.24.camel@ymzhang>
On Fri, 11 Jan 2008, Zhang, Yanmin wrote:
> On Wed, 2008-01-09 at 17:35 +0800, Zhang, Yanmin wrote:
> > The regression is:
> > 1)stoakley with 2 qual-core processors: 11%;
> > 2)Tulsa with 4 dual-core(+hyperThread) processors:13%;
> I have new update on this issue and also cc to netdev maillist.
> Thank David Miller for pointing me the netdev maillist.
>
> >
> > The test command is:
> > #sudo taskset -c 7 ./netserver
> > #sudo taskset -c 0 ./netperf -t TCP_RR -l 60 -H 127.0.0.1 -i 50,3 -I 99,5 -- -r 1,1
> >
> > As a matter of fact, 2.6.23 has about 6% regression and 2.6.24-rc's
> > regression is between 16%~11%.
> >
> > I tried to use bisect to locate the bad patch between 2.6.22 and 2.6.23-rc1,
> > but the bisected kernel wasn't stable and went crazy.
TCP work between that is very much non-existing.
Using git-reset's to select a nearby merge point instead of default
commit where bisection lands might be help in case the bisected kernel
breaks.
Also, limiting bisection under a subsystem might reduce probability of
brokeness (might at least be able to narrow it down quite a lot), e.g.
git bisect start net/
--
i.
^ permalink raw reply
* Re: [ipw3945-devel] [PATCH 2/5] iwlwifi: iwl3945 synchronize interruptand tasklet for down iwlwifi
From: Joonwoo Park @ 2008-01-14 8:35 UTC (permalink / raw)
To: Zhu, Yi, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Chatre, Reinette, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
ipw3945-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b25c3fa70801101838o7a71cc60h1c8b8a71624aeff9-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Joonwoo Park wrote:
> 2008/1/11, Chatre, Reinette <reinette.chatre-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>:
>> On Thursday, January 10, 2008 5:25 PM, Joonwoo Park wrote:
>
>> What modification are you considering?
>
> Roughly, I'm considering make synchronize_irq() be moved into
> iwl_disable_interrupts() and fix iwl_irq_tasket not to call
> iwl_disable_interrupts with irq disabled.
> For now iwl_irq_tasklet calls iwl_disable_interrupts() with local irq disabled.
> like this:
>
> static void iwl_irq_tasklet(struct iwl_priv *priv)
> {
> ...
> spin_lock_irqsave(&priv->lock, flags);
>
> ...
> /* Now service all interrupt bits discovered above. */
> if (inta & CSR_INT_BIT_HW_ERR) {
> IWL_ERROR("Microcode HW error detected. Restarting.\n");
>
> /* Tell the device to stop sending interrupts */
> iwl_disable_interrupts(priv);
> ...
> spin_unlock_irqrestore(&priv->lock, flags);
> return;
> }
>
>
After disabling interrupts, it's possible irq & tasklet is pending or running
This patch eleminates races for down iwlwifi
Since synchronize_irq can introduce iwl_irq_tasklet, tasklet_kill
should be called after doing synchronize_irq
To avoid races between iwl_synchronize_irq and iwl_irq_tasklet STATUS_INT_ENABLED
flag is needed.
Signed-off-by: Joonwoo Park <joonwpark81-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/wireless/iwlwifi/iwl3945-base.c | 33 ++++++++++++++++++++++-----
1 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 6e20725..f98cd4f 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -4405,6 +4405,14 @@ static void iwl_print_rx_config_cmd(struct iwl_rxon_cmd *rxon)
}
#endif
+static void iwl_synchronize_interrupts(struct iwl_priv *priv)
+{
+ synchronize_irq(priv->pci_dev->irq);
+ /* synchornize_irq introduces irq_tasklet,
+ * tasklet_kill should be called after doing synchronize_irq */
+ tasklet_kill(&priv->irq_tasklet);
+}
+
static void iwl_enable_interrupts(struct iwl_priv *priv)
{
IWL_DEBUG_ISR("Enabling interrupts\n");
@@ -4413,7 +4421,7 @@ static void iwl_enable_interrupts(struct iwl_priv *priv)
iwl_flush32(priv, CSR_INT_MASK);
}
-static inline void iwl_disable_interrupts(struct iwl_priv *priv)
+static inline void __iwl_disable_interrupts(struct iwl_priv *priv)
{
clear_bit(STATUS_INT_ENABLED, &priv->status);
@@ -4427,6 +4435,13 @@ static inline void iwl_disable_interrupts(struct iwl_priv *priv)
iwl_flush32(priv, CSR_INT);
iwl_write32(priv, CSR_FH_INT_STATUS, 0xffffffff);
iwl_flush32(priv, CSR_FH_INT_STATUS);
+}
+
+static inline void iwl_disable_interrupts(struct iwl_priv *priv)
+{
+ __iwl_disable_interrupts(priv);
+
+ iwl_synchronize_interrupts(priv);
IWL_DEBUG_ISR("Disabled interrupts\n");
}
@@ -4708,7 +4723,8 @@ static void iwl_irq_tasklet(struct iwl_priv *priv)
IWL_ERROR("Microcode HW error detected. Restarting.\n");
/* Tell the device to stop sending interrupts */
- iwl_disable_interrupts(priv);
+ __iwl_disable_interrupts(priv);
+ IWL_DEBUG_ISR("Disabled interrupts\n");
iwl_irq_handle_error(priv);
@@ -4814,8 +4830,11 @@ static void iwl_irq_tasklet(struct iwl_priv *priv)
IWL_WARNING(" with FH_INT = 0x%08x\n", inta_fh);
}
- /* Re-enable all interrupts */
- iwl_enable_interrupts(priv);
+ /* To avoid race when device goes down,
+ * it should be discarded to enable interrupts */
+ if (test_bit(STATUS_INT_ENABLED, &priv->status))
+ /* Re-enable all interrupts */
+ iwl_enable_interrupts(priv);
#ifdef CONFIG_IWLWIFI_DEBUG
if (iwl_debug_level & (IWL_DL_ISR)) {
@@ -4876,8 +4895,10 @@ unplugged:
return IRQ_HANDLED;
none:
- /* re-enable interrupts here since we don't have anything to service. */
- iwl_enable_interrupts(priv);
+ if (test_bit(STATUS_INT_ENABLED, &priv->status))
+ /* re-enable interrupts here since we don't have anything
+ * to service. */
+ iwl_enable_interrupts(priv);
spin_unlock(&priv->lock);
return IRQ_NONE;
}
---
Thanks,
Joonwoo
^ permalink raw reply related
* Re: Netconf at conf.au 2008?
From: Andy Johnson @ 2008-01-14 8:34 UTC (permalink / raw)
To: David Miller; +Cc: gdt, netdev
In-Reply-To: <20080113.180802.243708508.davem@davemloft.net>
Hello,
Sorry to hear that; I believe many would want to attend netconf in case
it was a part of LCA08. I must add that I followed some of the presentations
slides of netconf from recent years and it seemed very interesting and
very advanced.
I also watched the "Linux IPSEC Scaling" video (available on the internet)
from LCA 2007 and found it really interesting . (I don't think that there is
any video from netconf conferences from recent years).
I wish that in LCA09 things will be different.
(And of course I did not mean any netconf stuff from martin krafft,
which I already knew before)
Regards,
Andy
On Jan 14, 2008 4:08 AM, David Miller <davem@davemloft.net> wrote:
> From: Glen Turner <gdt@gdt.id.au>
> Date: Mon, 14 Jan 2008 01:23:45 +1030
>
> >
> > On Sat, 2008-01-12 at 08:52 +0200, Andy Johnson wrote:
> > > I saw somewhere (maybe in this mailing list a while ago) that there
> > > might be a Linux Kernel Developers' Netconf conference at conf.au
> > > 2008.
> > >
> > > Does anyone here know if such a thing is planned ?
> >
> > I don't know.
>
> We wanted to do a netconf in Sydney right before LCA08, but an unnamed
> company with a multi billion dollar market capitalization that uses
> Linux networking technology on thousands upon thounsands of their
> servers didn't want to pony up for some funding to cover airfare and
> hotel expenses for several of the attendees. They wanted to provide
> nothing more than a conference room and then get their names in bright
> lights so they could say they "sponsored" netconf.
>
> So, no, there will be no netconf at LCA08. But many of us will be
> there anyways and chatting in any event :-)
>
> Thanks for the offer for the network pipe. I'm not interested
> personally as I like to relax during the conference not hack actively
> on anything too seriously. I'm there to present, keep up semi
> regularly with my email, and chat with folks.
>
> Now, if this were available outside of the conference so that we could
> play with it remotely from where we work, that's more interesting.
>
^ permalink raw reply
* Re: [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
From: Ilpo Järvinen @ 2008-01-14 8:33 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Netdev
In-Reply-To: <20080113.235113.170762359.davem@davemloft.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3687 bytes --]
On Sun, 13 Jan 2008, David Miller wrote:
> From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Mon, 14 Jan 2008 09:43:08 +0200 (EET)
>
> > I'd prefer sending them as iso-8859-1 compliant (and I guess you are able
> > to test your fix-to-utf-8 machinery with it as well :-)), as it would also
> > make my mails compatible with other people's git apply tools you're not
> > using (otherwise I'd probably forget to change it occassionally when
> > interacting with others than you).
>
> For now either way is fine with me. If the situation changes I'll
> let you know.
Ok, I'll remain in iso-8859-1, it's something that is known to work from
my end. Thanks anyway for fixing it, wasn't any big deal for me at any
point of time but people started asking me privately to correct it which
I of course couldn't... :-)
> I'm surprised git-send-email can't get it purely utf8 correctly.
The problem is that my system is ISO natively, so git-send-email might
encode a ISO native .patch file's content while sending, which in this
case was intentionally already utf-8.
It might surprise you but it wasn't a long time ago when git-send-email
wouldn't care less e.g. about header encoding and I got rejects from
netdev due to my name which wasn't encoded properly, I've 1.5.0.6
currently and it seemed still fail to encode Cc addresses it adds from
signed-offs unless I explicitly ask for it to not do that (I explicitly
ask for especific, encoded, from header anyway because it was broken at
some point of time and my sending template is copy-paste originating
from that time). There was some recent fixes in the git's logs regarding
that encoding, so I intend to check if a later g-s-e is more able and if
it isn't I'll report it to git folks.
> I wonder if there is some issue with how it gets your name
> string for the commit author etc.
I've had it working well since the encoding header got relatively recently
added (wasn't available at early dawn of git era), before that it was just
a mess locally. Funny enough, you were able to magically mangle my emails
to utf-8'ed commits nicely back then so I got a "fixed" commit back after
an RTT :-).
> I wonder if getting it into your global GIT config file in proper
> UTF8 encoding would fix things.
>
> Put something like this into ~/.gitconfig
>
> --------------------
> [user]
> name = Ilpo Järvinen
> email = ilpo.jarvinen@helsinki.fi
> --------------------
I have this. In addition I have this (required to make my local system
consistent):
[i18n]
commitencoding = ISO-8859-1
The problem was just that the API (or better, ABI) between us
wasn't properly working :-)). While Herbert was working as the
replacement-Dave in November, correct commit entries were created,
so git has been working fine (I guess he used git applying tools
instead of handmade scripts and they handle email correclt based
on it's encoding).
I tried logOutputEncoding = utf-8 in the last patch sets I sent (now
could again remove it) but git-send-email problem appeared with it
because the system is ISO natively.
> The GIT maintainer is Finnish which makes this situation even
> more perplexing to me, you might want to discuss it with him :-)
Junio? Never heard that a Finnish name... ;-) Perhaps
git-send-email wasn't written by that Finnish guy... :-)
...Besides, that Finnish git aintainer doesn't have any funny
characters in his name... ;-)
Thanks anyway for the tips & all, I think we have it now working
and I can return to inlines and rexmit_skb_hint things & other TCP
stuff rather than this hinderance. I've some interesting results
from net header inlines checks I ran overnight :-).
--
i.
^ permalink raw reply
* Re: [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
From: David Miller @ 2008-01-14 7:51 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: herbert, netdev
In-Reply-To: <Pine.LNX.4.64.0801140920580.31652@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Mon, 14 Jan 2008 09:43:08 +0200 (EET)
> So which test case you prefer? :-) Is iso-8859-1 from+content ok? Or
> should I keep trying to live with mixed utf-8 which I didn't got even
> fully working last time because git-send-email is probably either too dumb
> or too intelligent (I'm not even sure which), but you were able correct it
> by your tools so the flawed signed-off never entered to the git logs as
> incorrectly formatted :-).
>
> I'd prefer sending them as iso-8859-1 compliant (and I guess you are able
> to test your fix-to-utf-8 machinery with it as well :-)), as it would also
> make my mails compatible with other people's git apply tools you're not
> using (otherwise I'd probably forget to change it occassionally when
> interacting with others than you).
For now either way is fine with me. If the situation changes I'll
let you know.
I'm surprised git-send-email can't get it purely utf8 correctly.
I wonder if there is some issue with how it gets your name
string for the commit author etc.
I wonder if getting it into your global GIT config file in proper
UTF8 encoding would fix things.
Put something like this into ~/.gitconfig
--------------------
[user]
name = Ilpo Järvinen
email = ilpo.jarvinen@helsinki.fi
--------------------
The GIT maintainer is Finnish which makes this situation even
more perplexing to me, you might want to discuss it with him :-)
^ permalink raw reply
* Re: [RFC PATCH 8/8] [PKTGEN]: uninline getCurUs
From: Ilpo Järvinen @ 2008-01-14 7:43 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Netdev
In-Reply-To: <20080112.202414.192104180.davem@davemloft.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1113 bytes --]
On Sat, 12 Jan 2008, David Miller wrote:
> From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
> Date: Sat, 12 Jan 2008 14:59:50 +0200 (EET)
>
> > ...Maybe I just fall-back to changing my last name, it's the only
> > full-proof solution... ;-)
>
> Don't do this! Otherwise I won't have a frequent test case to make
> sure my patch applying scripts are working properly. :-))))
So which test case you prefer? :-) Is iso-8859-1 from+content ok? Or
should I keep trying to live with mixed utf-8 which I didn't got even
fully working last time because git-send-email is probably either too dumb
or too intelligent (I'm not even sure which), but you were able correct it
by your tools so the flawed signed-off never entered to the git logs as
incorrectly formatted :-).
I'd prefer sending them as iso-8859-1 compliant (and I guess you are able
to test your fix-to-utf-8 machinery with it as well :-)), as it would also
make my mails compatible with other people's git apply tools you're not
using (otherwise I'd probably forget to change it occassionally when
interacting with others than you).
--
i.
^ permalink raw reply
* Re: [PATCH 1/8] [TCP]: Uninline tcp_set_state
From: Ilpo Järvinen @ 2008-01-14 7:20 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Netdev
In-Reply-To: <20080112130355.74c39ae7@deepthought>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2871 bytes --]
On Sat, 12 Jan 2008, Stephen Hemminger wrote:
> On Sat, 12 Jan 2008 11:40:10 +0200
> "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> wrote:
...snip...
> > built-in.o:
> > 12 functions changed, 250 bytes added, 1695 bytes removed, diff: -1445
...snip...
> > include/net/tcp.h | 35 +----------------------------------
> > net/ipv4/tcp.c | 35 +++++++++++++++++++++++++++++++++++
> > 2 files changed, 36 insertions(+), 34 deletions(-)
> >
> > diff --git a/include/net/tcp.h b/include/net/tcp.h
> > index 48081ad..306580c 100644
> > --- a/include/net/tcp.h
> > +++ b/include/net/tcp.h
> > @@ -926,40 +926,7 @@ static const char *statename[]={
> > "Close Wait","Last ACK","Listen","Closing"
> > };
> > #endif
> > -
> > -static inline void tcp_set_state(struct sock *sk, int state)
> > -{
> > - int oldstate = sk->sk_state;
> > -
> > - switch (state) {
> > - case TCP_ESTABLISHED:
> > - if (oldstate != TCP_ESTABLISHED)
> > - TCP_INC_STATS(TCP_MIB_CURRESTAB);
> > - break;
> > -
> > - case TCP_CLOSE:
> > - if (oldstate == TCP_CLOSE_WAIT || oldstate == TCP_ESTABLISHED)
> > - TCP_INC_STATS(TCP_MIB_ESTABRESETS);
> > -
> > - sk->sk_prot->unhash(sk);
> > - if (inet_csk(sk)->icsk_bind_hash &&
> > - !(sk->sk_userlocks & SOCK_BINDPORT_LOCK))
> > - inet_put_port(&tcp_hashinfo, sk);
> > - /* fall through */
> > - default:
> > - if (oldstate==TCP_ESTABLISHED)
> > - TCP_DEC_STATS(TCP_MIB_CURRESTAB);
> > - }
> > -
> > - /* Change state AFTER socket is unhashed to avoid closed
> > - * socket sitting in hash tables.
> > - */
> > - sk->sk_state = state;
> > -
> > -#ifdef STATE_TRACE
> > - SOCK_DEBUG(sk, "TCP sk=%p, State %s -> %s\n",sk, statename[oldstate],statename[state]);
> > -#endif
> > -}
> >
>
>
> Since the function is called with a constant state, I guess the assumption
> was that gcc would be smart enough to only include the code needed, it looks like
> either code was bigger or the compiler was dumber than expected
I'd guess that compiler was just dumber... :-) It might be an interesting
experiment to convert it to if's and see if it would make a difference,
maybe it just gets confused by the switch or something.
Besides, it not always that obvious that gcc is able to determine "the
constant state", considering e.g., the complexity in the cases with
tcp_rcv_synsent_state_process, tcp_close_state, tcp_done. In such cases
uninlining should be done and gcc is probably not able to mix both cases
nicely for a single function?
However, after looking a bit, I'm partially leaning towards the other
option too:
> > tcp_done | -145
> > tcp_disconnect | -141
...These called for tcp_set_state just _once_, while this calls for it
twice:
> > tcp_fin | -86
...Obviously the compiler was able to perform some reductions but 43 bytes
per inlining seems still a bit high number.
--
i.
^ permalink raw reply
* Re: [TOKENRING]: rif_timer not initialized properly
From: David Miller @ 2008-01-14 6:33 UTC (permalink / raw)
To: dada1; +Cc: netdev
In-Reply-To: <478B0168.1060809@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Mon, 14 Jan 2008 07:30:00 +0100
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Applied to net-2.6, thanks Eric.
^ permalink raw reply
* Re: [FIB]: full_children & empty_children should be uint, not ushort
From: David Miller @ 2008-01-14 6:32 UTC (permalink / raw)
To: Robert.Olsson; +Cc: dada1, stephen.hemminger, robert.olsson, netdev
In-Reply-To: <18314.35427.947982.424287@robur.slu.se>
From: Robert Olsson <Robert.Olsson@data.slu.se>
Date: Sun, 13 Jan 2008 23:02:11 +0100
>
> Eric Dumazet writes:
> > Eric Dumazet a écrit :
> > > 4) full_children & empty_children being 'unsigned short',
> > > we probably are limited to 2^15 elements, but I could not
> > > find this limit enforced somewhere.
>
> > Two fixes are possible : Enlarge full_children & empty_children to 32bits, or
> > force a limit in code to never exceed 2^15 children in a tnode. I chose the
> > first solution since it can be done with 0 memory cost on 64bit arches.
...
> Thanks for spotting this. No we don't want put limits on the (root) node size.
> You see the comment in code is correct so unsigned short are some leftover from
> old testing which could have hit us hard as the routing table slowly grows.
...
> Signed-off-by: Robert Olsson <robert.olsson@its.uu.se>
Applied, thanks everyone.
^ permalink raw reply
* [TOKENRING]: rif_timer not initialized properly
From: Eric Dumazet @ 2008-01-14 6:30 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 50 bytes --]
Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
[-- Attachment #2: tr.patch --]
[-- Type: text/plain, Size: 435 bytes --]
diff --git a/net/802/tr.c b/net/802/tr.c
index a2bd0f2..1e115e5 100644
--- a/net/802/tr.c
+++ b/net/802/tr.c
@@ -642,7 +642,7 @@ struct net_device *alloc_trdev(int sizeof_priv)
static int __init rif_init(void)
{
init_timer(&rif_timer);
- rif_timer.expires = sysctl_tr_rif_timeout;
+ rif_timer.expires = jiffies + sysctl_tr_rif_timeout;
rif_timer.data = 0L;
rif_timer.function = rif_check_expire;
add_timer(&rif_timer);
^ permalink raw reply related
* Re: [AX25]: sparse cleanups
From: David Miller @ 2008-01-14 6:29 UTC (permalink / raw)
To: dada1; +Cc: netdev
In-Reply-To: <4789EF88.9090303@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Sun, 13 Jan 2008 12:01:28 +0100
> net/ax25/ax25_route.c:251:13: warning: context imbalance in
> 'ax25_rt_seq_start' - wrong count at exit
> net/ax25/ax25_route.c:276:13: warning: context imbalance in 'ax25_rt_seq_stop'
> - unexpected unlock
> net/ax25/ax25_std_timer.c:65:25: warning: expensive signed divide
> net/ax25/ax25_uid.c:46:1: warning: symbol 'ax25_uid_list' was not declared.
> Should it be static?
> net/ax25/ax25_uid.c:146:13: warning: context imbalance in 'ax25_uid_seq_start'
> - wrong count at exit
> net/ax25/ax25_uid.c:169:13: warning: context imbalance in 'ax25_uid_seq_stop'
> - unexpected unlock
> net/ax25/af_ax25.c:573:28: warning: expensive signed divide
> net/ax25/af_ax25.c:1865:13: warning: context imbalance in 'ax25_info_start' -
> wrong count at exit
> net/ax25/af_ax25.c:1888:13: warning: context imbalance in 'ax25_info_stop' -
> unexpected unlock
> net/ax25/ax25_ds_timer.c:133:25: warning: expensive signed divide
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Applied, thanks.
^ permalink raw reply
* Re: [X25]: Avoid divides and sparse warnings
From: David Miller @ 2008-01-14 6:29 UTC (permalink / raw)
To: dada1; +Cc: netdev
In-Reply-To: <4789E8DD.2020901@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Sun, 13 Jan 2008 11:33:01 +0100
> CHECK net/x25/af_x25.c
> net/x25/af_x25.c:117:46: warning: expensive signed divide
> CHECK net/x25/x25_facilities.c
> net/x25/x25_facilities.c:209:30: warning: expensive signed divide
> CHECK net/x25/x25_in.c
> net/x25/x25_in.c:250:26: warning: expensive signed divide
> CHECK net/x25/x25_proc.c
> net/x25/x25_proc.c:48:11: warning: context imbalance in 'x25_seq_route_start'
> - wrong count at exit
> net/x25/x25_proc.c:72:13: warning: context imbalance in 'x25_seq_route_stop' -
> unexpected unlock
> net/x25/x25_proc.c:112:11: warning: context imbalance in
> 'x25_seq_socket_start' - wrong count at exit
> net/x25/x25_proc.c:129:13: warning: context imbalance in 'x25_seq_socket_stop'
> - unexpected unlock
> net/x25/x25_proc.c:190:11: warning: context imbalance in
> 'x25_seq_forward_start' - wrong count at exit
> net/x25/x25_proc.c:215:13: warning: context imbalance in
> 'x25_seq_forward_stop' - unexpected unlock
> CHECK net/x25/x25_subr.c
> net/x25/x25_subr.c:362:57: warning: expensive signed divide
>
> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Applied, thanks Eric.
We might just want to make sk_rcvbuf et al. unsigned, it
crops up a lot and I can't see any valid reason for it
to be negative or for uses of it to matter with other
signed values.
Or did we discuss that to death already? :-)
^ permalink raw reply
* Re: sparc oops in ip_fast_csum
From: David Miller @ 2008-01-14 6:19 UTC (permalink / raw)
To: kaber; +Cc: herbert, viro, m.kozlowski, sparclinux, netdev, linux-kernel
In-Reply-To: <478AFC92.50508@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Mon, 14 Jan 2008 07:09:22 +0100
> But I agree to your suggestion, that will allow us to properly
> handle packets with IP options. I'll take care of this.
Thanks a lot Patrick.
^ permalink raw reply
* Re: sparc oops in ip_fast_csum
From: Patrick McHardy @ 2008-01-14 6:09 UTC (permalink / raw)
To: Herbert Xu; +Cc: Al Viro, m.kozlowski, davem, sparclinux, netdev, linux-kernel
In-Reply-To: <20080106041430.GA3784@gondor.apana.org.au>
Herbert Xu wrote:
> Patrick, please have a look at the former. In fact it's not just
> that ihl may be bogus (which might be harmless as long as the REJECT
> hook only gets called from within the IP stack), I think REJECT would
> also do the wrong thing if the packet had IP options. So perhaps we
> should just make it create a packet from scratch rather than being
> too clever in reusing the old one.
We currently silently drop packets with IP options in the reject
target. The length check should be fine since its only called
through the IP stack or bridge netfilter, which replicates the
IP stack checks.
But I agree to your suggestion, that will allow us to properly
handle packets with IP options. I'll take care of this.
^ permalink raw reply
* Re: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22
From: Zhang, Yanmin @ 2008-01-14 3:11 UTC (permalink / raw)
To: Rick Jones; +Cc: LKML, netdev
In-Reply-To: <4787ADDA.7090602@hp.com>
On Fri, 2008-01-11 at 09:56 -0800, Rick Jones wrote:
> >>The test command is:
> >>#sudo taskset -c 7 ./netserver
> >>#sudo taskset -c 0 ./netperf -t TCP_RR -l 60 -H 127.0.0.1 -i 50,3 -I 99,5 -- -r 1,1
>
> A couple of comments/questions on the command lines:
Thanks for your kind comments.
>
> *) netperf/netserver support CPU affinity within themselves with the
> global -T option to netperf. Is the result with taskset much different?
> The equivalent to the above would be to run netperf with:
>
> ./netperf -T 0,7 ..
I checked the source codes and didn't find this option.
I use netperf V2.3 (I found the number in the makefile).
> .
>
> The one possibly salient difference between the two is that when done
> within netperf, the initial process creation will take place wherever
> the scheduler wants it.
>
> *) The -i option to set the confidence iteration count will silently cap
> the max at 30.
Indeed, you are right.
-yanmin
^ permalink raw reply
* Re: Netconf at conf.au 2008?
From: David Miller @ 2008-01-14 2:12 UTC (permalink / raw)
To: madduck; +Cc: netdev
In-Reply-To: <20080113181751.GA15063@lapse.madduck.net>
From: martin f krafft <madduck@madduck.net>
Date: Sun, 13 Jan 2008 19:17:51 +0100
> also sprach Andy Johnson <johnsonzjo@gmail.com> [2008.01.12.0752 +0100]:
> > I saw somewhere (maybe in this mailing list a while ago) that
> > there might be a Linux Kernel Developers' Netconf conference at
> > conf.au 2008.
>
> I think you may be mixing things up, and it may be my fault in ways.
> I am developing netconf: http://netconf.alioth.debian.org. I am
> aware of the NETCONF protocol and have considered renaming my
> project, but looking around, it seemed to me that NETCONF isn't
> really all that active, and so I chose to keep the name. If people
> think that wasn't wise, I'm willing to listen...
Netconf is the name of the usually annual conference the core
Linux networking developer organize.
^ permalink raw reply
* Re: [PATCH] fib_semantics: prevent long hash chains in access server config
From: David Miller @ 2008-01-14 2:11 UTC (permalink / raw)
To: bcrl; +Cc: netdev
In-Reply-To: <20080113175849.GC12775@kvack.org>
From: Benjamin LaHaise <bcrl@kvack.org>
Date: Sun, 13 Jan 2008 12:58:49 -0500
> Ah, you're right indeed. It's probably easier for me to change how the
> daemon adds the local ip address for these point to point interfaces.
I guess you didn't understand, I checked in the following
patch which implements things correctly.
commit d5414fdd4098742a5a9d255c4b9af587318c525f
Author: David S. Miller <davem@davemloft.net>
Date: Sat Jan 12 21:49:01 2008 -0800
[IPV4] FIB: Include nexthop device indexes in fib_info hashfn.
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 3ed920b..0e08df4 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -194,6 +194,15 @@ static __inline__ int nh_comp(const struct fib_info *fi, const struct fib_info *
return 0;
}
+static inline unsigned int fib_devindex_hashfn(unsigned int val)
+{
+ unsigned int mask = DEVINDEX_HASHSIZE - 1;
+
+ return (val ^
+ (val >> DEVINDEX_HASHBITS) ^
+ (val >> (DEVINDEX_HASHBITS * 2))) & mask;
+}
+
static inline unsigned int fib_info_hashfn(const struct fib_info *fi)
{
unsigned int mask = (fib_hash_size - 1);
@@ -202,6 +211,9 @@ static inline unsigned int fib_info_hashfn(const struct fib_info *fi)
val ^= fi->fib_protocol;
val ^= (__force u32)fi->fib_prefsrc;
val ^= fi->fib_priority;
+ for_nexthops(fi) {
+ val ^= fib_devindex_hashfn(nh->nh_oif);
+ } endfor_nexthops(fi)
return (val ^ (val >> 7) ^ (val >> 12)) & mask;
}
@@ -232,15 +244,6 @@ static struct fib_info *fib_find_info(const struct fib_info *nfi)
return NULL;
}
-static inline unsigned int fib_devindex_hashfn(unsigned int val)
-{
- unsigned int mask = DEVINDEX_HASHSIZE - 1;
-
- return (val ^
- (val >> DEVINDEX_HASHBITS) ^
- (val >> (DEVINDEX_HASHBITS * 2))) & mask;
-}
-
/* Check, that the gateway is already configured.
Used only by redirect accept routine.
*/
^ permalink raw reply related
* Re: Netconf at conf.au 2008?
From: David Miller @ 2008-01-14 2:08 UTC (permalink / raw)
To: gdt; +Cc: johnsonzjo, netdev
In-Reply-To: <1200236025.6171.79.camel@andromache>
From: Glen Turner <gdt@gdt.id.au>
Date: Mon, 14 Jan 2008 01:23:45 +1030
>
> On Sat, 2008-01-12 at 08:52 +0200, Andy Johnson wrote:
> > I saw somewhere (maybe in this mailing list a while ago) that there
> > might be a Linux Kernel Developers' Netconf conference at conf.au
> > 2008.
> >
> > Does anyone here know if such a thing is planned ?
>
> I don't know.
We wanted to do a netconf in Sydney right before LCA08, but an unnamed
company with a multi billion dollar market capitalization that uses
Linux networking technology on thousands upon thounsands of their
servers didn't want to pony up for some funding to cover airfare and
hotel expenses for several of the attendees. They wanted to provide
nothing more than a conference room and then get their names in bright
lights so they could say they "sponsored" netconf.
So, no, there will be no netconf at LCA08. But many of us will be
there anyways and chatting in any event :-)
Thanks for the offer for the network pipe. I'm not interested
personally as I like to relax during the conference not hack actively
on anything too seriously. I'm there to present, keep up semi
regularly with my email, and chat with folks.
Now, if this were available outside of the conference so that we could
play with it remotely from where we work, that's more interesting.
^ permalink raw reply
* Re: Top 10 kernel oopses for the week ending January 5th, 2008
From: Neil Brown @ 2008-01-14 1:36 UTC (permalink / raw)
To: Al Viro
Cc: Linus Torvalds, Kevin Winchester, J. Bruce Fields,
Arjan van de Ven, Linux Kernel Mailing List, Andrew Morton,
NetDev, gregkh
In-Reply-To: <20080110055359.GA27894@ZenIV.linux.org.uk>
On Thursday January 10, viro@ZenIV.linux.org.uk wrote:
> On Thu, Jan 10, 2008 at 03:13:48PM +1100, Neil Brown wrote:
> > > What guarantees that it doesn't happen before we get to callback? AFAICS,
> > > nothing whatsoever...
> >
> > Yes, that's bad isn't it :-)
> >
> > I think I should be using sysfs_schedule_callback here. That makes the
> > required 'get' and 'put' calls.... but it can fail with -ENOMEM. I
> > wonder what I do if -ENOMEM??? Maybe I'll just continue to roll my
> > one :-(
>
> How about this instead (completely untested)
>
> * split failure exits
> * switch to kick_rdev_from_array()
> * fold unbind_rdev_from_array() into it (no other callers anymore)
> * take export_rdev() into failure case in bind_rdev_to_array()
> * in kick_rdev_from_array() do what export_rdev() does sans
> kobject_put() and do that before schedule_work(). Take kobject_put() into
> delayed_delete().
While there are probably some good ideas in there, I think fixing this
particular bug is much simpler. Just take a reference to the object
before scheduling the worker, and drop it when the worker has done
its work.
I have a closer look at the idea of no required export_rdev after a
failed bind_rdev_to_array. On the surface it does seem to make the
code nicer.
Thanks,
NeilBrown
^ permalink raw reply
* Re: [Bugme-new] [Bug 9721] New: wake on lan fails with sky2 module
From: supersud501 @ 2008-01-13 22:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Andrew Morton, Stephen Hemminger, netdev, linux-acpi,
bugme-daemon
In-Reply-To: <200801132227.59229.rjw@sisk.pl>
Rafael J. Wysocki wrote:
> I wonder if commit 84cd2dfb04d23a961c5f537baa243fa54d0987ac
> "sky2: remove check for PCI wakeup setting from BIOS" has anything to do with
> it, btw.
>
> supersud501, can you please check if the bug is still present in the current
> Linus' tree?
>
I checked it (after git pulling the dir), and it still doesn't work. but
the dmesg-output wasn't filled with those errors i reported before anymore.
after removing that one commit ("enable PCI config writes") wol works
again, but the dmesg output is filled too! so that seems to be the
source of the full dmesg-output. here a little bit more of the
dmesg-output (but maybe i should open a new bug report?)
[...] rmmod sky2 --->
[ 1182.964000] sky2 eth0: disabling interface
[ 1183.255862] ACPI: PCI interrupt for device 0000:02:00.0 disabled
modprobe syk2 -->
[ 1192.951021] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 19 (level,
low) -> IRQ 19
[ 1192.951034] PCI: Setting latency timer of device 0000:02:00.0 to 64
[ 1192.951618] sky2 0000:02:00.0: v1.20 addr 0xf89fc000 irq 19 Yukon-EC
(0xb6) rev 2
[ 1192.951636] sky2 0000:02:00.0: ignoring stuck error report bit
[ 1192.952425] sky2 eth0: addr 00:18:f3:fe:93:11
ifdown eth0 && ifup eth0 -->
[ 1207.425171] sky2 eth0: enabling interface
[ 1209.806138] printk: 97 messages suppressed.
[ 1209.806143] sky2 0000:02:00.0: error interrupt status=0x80000010
[ 1209.807184] sky2 eth0: Link is up at 100 Mbps, full duplex, flow
control rx
[ 1209.807502] sky2 0000:02:00.0: error interrupt status=0x80000000
[ 1210.621117] sky2 0000:02:00.0: error interrupt status=0xc0000000
[ 1210.660325] sky2 0000:02:00.0: error interrupt status=0x80000000
[ 1210.996873] sky2 0000:02:00.0: error interrupt status=0xc0000000
[ 1211.645470] printk: 1 messages suppressed.
[ 1211.645474] sky2 0000:02:00.0: error interrupt status=0xc0000000
[ 1216.656564] printk: 328 messages suppressed.
[ 1216.656569] sky2 0000:02:00.0: error interrupt status=0x80000000
[ 1221.653677] printk: 17 messages suppressed.
[ 1221.653681] sky2 0000:02:00.0: error interrupt status=0x80000000
--> every 5 sec a new error
[...]
-------------
and i noticed one more thing (i thought would just happen occasionally):
everytime wol does not work (sending the magic packet does nothing), i
have to cut off my pc completely from power because otherwise (powering
it up by power button) it hangs endless on hard-disk-dedection (s-ata).
other users with my mobo report same issues from time to time, but mine
seems to be 100% reproducable.
reenabling wol by removing the commit fixes this problem, too. the next
new bug report i think.
-------------
btw, if anyone could tell me a way to rebuild only some modules (so i
get the .ko file directly and can replace it by hand in
/lib/modules/...) i could hack around a little bit too in sky2.c (or so)
without the need to reinstall the whole kernel in order to test it...
^ permalink raw reply
* Re: [PATCH 0/4] Pull request for 'ipg-fixes' branch
From: Francois Romieu @ 2008-01-13 22:34 UTC (permalink / raw)
To: Jeff Garzik; +Cc: David Miller, linux, Andrew Morton, netdev
In-Reply-To: <20080113155028.GA30392@electric-eye.fr.zoreil.com>
Francois Romieu <romieu@fr.zoreil.com> :
> Jeff Garzik <jeff@garzik.org> :
> > Francois Romieu wrote:
> [...]
> >> Distance from 'net-2.6/master' (27d1cba21fcc50c37eef5042c6be9fa7135e88fc)
> >> -------------------------------------------------------------------------
> [...]
> > hrm... tried to pull this, but received non-ipg stuff too
>
> It is based on one of davem's branches (see the 'distance' line above).
>
> Do you want a branch against your upstream-fixes ?
It is available at:
git://git.kernel.org/pub/scm/linux/kernel/git/romieu/netdev-2.6.git upstream-jeff
Distance from 'upstream-linus' (cb8da8a38015ded1df319a39b7298e69f89036ac)
-------------------------------------------------------------------------
f1f443e6276aae3862a970b141102c51f5e25e4b
b76c7331afe11544063d2c3390de8c9a7ba6db83
98ae57a0dada63ab9b811e89a4b70ca4e4da7497
184c6cf5e4b8e659095fd9e2b54ef37f131b5810
It is up to you and davem to decide who wants to pull it.
--
Ueimor
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox