* Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
From: David Miller @ 2006-08-16 23:32 UTC (permalink / raw)
To: linas
Cc: akpm, arnd, jeff, netdev, jklewis, linux-kernel, linuxppc-dev,
Jens.Osterkamp
In-Reply-To: <20060816233028.GO20551@austin.ibm.com>
From: linas@austin.ibm.com (Linas Vepstas)
Date: Wed, 16 Aug 2006 18:30:28 -0500
> Why would you want o do this? It seems like a cruddier strategy
> than what we can already do (which is to never get an transmit
> interrupt, as long as the kernel can shove data into the device fast
> enough to keep the queue from going empty.) The whole *point* of a
> low-watermark interrupt is to never have to actually get the interrupt,
> if the rest of the system is on its toes and is supplying data fast
> enough.
As long as TX packets get freed within a certain latency
boundary, this kind of scheme should be fine.
^ permalink raw reply
* Re: [RFC PATCH 1/4] powerpc 2.6.16-rt17: to build on powerpc w/ RT
From: Benjamin Herrenschmidt @ 2006-08-16 23:38 UTC (permalink / raw)
To: john stultz; +Cc: linux-kernel, linuxppc-dev, Paul Mackerras, mingo, tglx
In-Reply-To: <1155318983.5337.2.camel@localhost.localdomain>
> You might take a peek at the patch set here:
> http://sr71.net/~jstultz/tod/ for a somewhat rough powerpc conversion to
> CONFIG_GENERIC_TIME.
Afaik, as-is, this patch will remove updating of the various bits used
by the vDSO for userland gettimeofday without actually removing the vdso
itself. Thus, with a recent glibc, it will break gettimeofday,
clock_gettime, .... Pretty bad :)
Ben.
^ permalink raw reply
* Re: [PATCH 2/4]: powerpc/cell spidernet low watermark patch.
From: Benjamin Herrenschmidt @ 2006-08-16 23:43 UTC (permalink / raw)
To: Linas Vepstas
Cc: Arnd Bergmann, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp
In-Reply-To: <20060811170813.GJ10638@austin.ibm.com>
On Fri, 2006-08-11 at 12:08 -0500, Linas Vepstas wrote:
>
> Implement basic low-watermark support for the transmit queue.
>
> The basic idea of a low-watermark interrupt is as follows.
> The device driver queues up a bunch of packets for the hardware
> to transmit, and then kicks he hardware to get it started.
> As the hardware drains the queue of pending, untransmitted
> packets, the device driver will want to know when the queue
> is almost empty, so that it can queue some more packets.
>
> This is accomplished by setting the DESCR_TXDESFLG flag in
> one of the packets. When the hardware sees this flag, it will
> interrupt the device driver. Because this flag is on a fixed
> packet, rather than at fixed location in the queue, the
> code below needs to move the flag as more packets are
> queued up. This implementation attempts to keep te flag
> at about 3/4's of the way into the queue.
>
> This patch boosts driver performance from about
> 300-400Mbps for 1500 byte packets, to about 710-740Mbps.
Sounds good (without actually looking at the code though :), that was a
long required improvement to that driver. Also, we should probably look
into using NAPI polling for tx completion queue as well, no ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
From: Linas Vepstas @ 2006-08-16 23:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: akpm, jeff, netdev, jklewis, linux-kernel, linuxppc-dev,
Jens.Osterkamp, David Miller
In-Reply-To: <200608170103.21097.arnd@arndb.de>
On Thu, Aug 17, 2006 at 01:03:20AM +0200, Arnd Bergmann wrote:
>
> Could well be related to latencies when going to the remote
> node for descriptor DMAs. Have you tried if the hch's NUMA
> patch or using numactl makes a difference here?
No. I guess I should try.
> > > sounds like the right approach to simplify the code.
> >
> > Its not a big a driver. 'wc' says its 2.3 loc, which
> > is 1/3 or 1/5 the size of tg3.c or the e1000*c files.
>
> Right, I was thinking of removing a lock or another, not
> throwing out half of the driver ;-)
There's only four lock points grand total.
-- One on the receive side,
-- one to protect the transmit head pointer,
-- one to protect the transmit tail pointer,
-- one to protect the location of the transmit low watermark.
The last three share the same lock. I tried using distinct
locks, but this worsened things, probably due to cache-line
trashing. I tried removing the head pointer lock, but this
failed. I don't know why, and was surprised by this. I thought
hard_start_xmit() was serialized.
--linas
^ permalink raw reply
* Re: [PATCH] fix gettimeofday vs. update_gtod race
From: Benjamin Herrenschmidt @ 2006-08-16 23:48 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060811204105.GK3233@localdomain>
On Fri, 2006-08-11 at 15:41 -0500, Nathan Lynch wrote:
> + /* Sampling the time base must be done after loading
> + * do_gtod.varp in order to avoid racing with update_gtod.
> + */
> + rmb();
> + tb_ticks = get_tb() - temp_varp->tb_orig_stamp;
The barrier isn't necessary and the race not completely closed imho... I
need to think about it a bit more closely but what about instead just
check if tb_ticks goes negative, and if yes, just do get_tb() again ?
That might be faster than having a sync in there and should still be
correct.
> temp_tb_to_xs = temp_varp->tb_to_xs;
> temp_stamp_xsec = temp_varp->stamp_xsec;
> xsec = temp_stamp_xsec + mulhdu(tb_ticks, temp_tb_to_xs);
> @@ -464,7 +469,7 @@ void do_gettimeofday(struct timeval *tv)
> tv->tv_usec = usec;
> return;
> }
> - __do_gettimeofday(tv, get_tb());
> + __do_gettimeofday(tv);
> }
>
> EXPORT_SYMBOL(do_gettimeofday);
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] no-execute -- please test
From: Benjamin Herrenschmidt @ 2006-08-16 23:55 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Albert Cahalan, linuxppc-dev, debian-powerpc
In-Reply-To: <17633.2179.582261.162544@cargo.ozlabs.ibm.com>
> We have a bit per page that says if the page is icache dirty or not.
> On machines with no-execute support, we already avoid flushing the
> page until some process first tries to execute from it. If we
> extended that to this scheme, when we made a segment executable, we
> would have to find and flush all icache-dirty pages in the segment (up
> to 65536 pages). We wouldn't want to do that every time we made a
> segment executable - it would need to be optimized (e.g. keep a count
> per segment of icache-dirty pages in the segment).
Note that we need to change the icache flush mecanism anyway as it's
always been racy on ppc32 SMP (though very few people noticed so far :)
and ppc64 SMP with < POWER3 CPUs (without N bit).
Ben.
^ permalink raw reply
* Re: [RFC PATCH 1/4] powerpc 2.6.16-rt17: to build on powerpc w/ RT
From: john stultz @ 2006-08-17 0:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, mingo, tglx
In-Reply-To: <1155771487.11312.114.camel@localhost.localdomain>
On Thu, 2006-08-17 at 01:38 +0200, Benjamin Herrenschmidt wrote:
> > You might take a peek at the patch set here:
> > http://sr71.net/~jstultz/tod/ for a somewhat rough powerpc conversion to
> > CONFIG_GENERIC_TIME.
>
> Afaik, as-is, this patch will remove updating of the various bits used
> by the vDSO for userland gettimeofday without actually removing the vdso
> itself. Thus, with a recent glibc, it will break gettimeofday,
> clock_gettime, .... Pretty bad :)
Hey Ben,
I appreciate your looking over my patch. You are correct, the
conversion is a bit rough and I've not yet been able to work on the
powerpc vDSO, although I'd like to get it working so any help or
suggestions would be appreciated (is there a reason the vDSO is written
in ASM?).
If you have any other concerns w/ that patch, or the generic timekeeping
code, please let me know and I'll do what I can to address them.
thanks
-john
^ permalink raw reply
* Re: Trouble with 85xx CDS cascade irq (i8259)
From: Benjamin Herrenschmidt @ 2006-08-17 0:04 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <7B853E2B-4156-4601-A272-9A9098310240@freescale.com>
> I'm currently working on getting the 85xx platform working with the
> new IRQ code. Specifically, I'm working on the 8555 CDS right now.
> The 85xx CDS consists of a PCI carrier card (with the 8555 processor,
> serial, and networking interfaces), placed in one of 4 PCI slots on a
> custom motherboard (the Arcadia). The PCI interrupts are routed into
> the carrier card through the standard PCI interrupt pins, which
> requires some mucking around with interrupt assignments depending on
> which slot the card is in. There is also a VIA chipset on the
> Arcadia motherboard, which provides IDE (among other things), and the
> i8259 PIC in there is routed in through PCI interrupt A.
<bell rings> VIA chipsets are known to do very strange things with
interrupt routing depending on magic bits in some PCI config space
registers </bell rings>. No specifics in mind right now though...
One of the issue with some of those legacy chipsets is that they tend to
route IDE IRQs to 14 and 15 regardless of the PCI interrupt assigned to
the controller (that is they don't completely follow the native mode).
You might need a specific hack to set the right IRQs for your IDE
channels thus as the driver might not have a clue.
As you can see, init_hwif_via82cxxx() already has ugly hackes. A cleaner
way to do that would be to use the hook I added for such things:
pci_get_legacy_ide_irq(). It's currently used by the amd74xx driver but
via82cxxx could be fixd too. It will, on powerpc, call into a ppc_md.
hook that you can use to "fixup" your IDE interrupts manually from the
platform code.
.../...
> At this point, I have determined that I am caught in a never-ending
> cycle of interrupts on the i8259 cascade (that is, the mpic interrupt
> that the i8259 is cascaded through). i8259_irq() returns that it's
> irq 7.
7 doesn't seem like a proper i8259 irq in that setup ...
=
> /*
> * Since only primary interface works, force the
> * IDE function to standard primary IDE interrupt
> * w/ 8259 offset
> */
> dev->irq = 14;
> pci_write_config_byte(dev, PCI_INTERRUPT_LINE, dev-
> >irq);
> pci_dev_put(dev);
> }
The above looks ok, but make sure that's really what the driver is
using ... Since it's a legacy irq, it should indeed not need any virtual
mapping (irqs below 16 are reserved for i8259)
So overall, sounds good to me, there is something lurking around but I
can't see it. (BTW. Why do you need to fixup all those IRQs ? Can't you
just have a proper interrupt-map ?
Ben.
^ permalink raw reply
* Re: [PATCH] fix gettimeofday vs. update_gtod race
From: Nathan Lynch @ 2006-08-17 0:18 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1155772134.11312.119.camel@localhost.localdomain>
Benjamin Herrenschmidt wrote:
> On Fri, 2006-08-11 at 15:41 -0500, Nathan Lynch wrote:
>
> > + /* Sampling the time base must be done after loading
> > + * do_gtod.varp in order to avoid racing with update_gtod.
> > + */
> > + rmb();
> > + tb_ticks = get_tb() - temp_varp->tb_orig_stamp;
>
> The barrier isn't necessary
No? I didn't find anything about mftb having synchronizing
behavior. How should we ensure that temp_varp is assigned before
reading the timebase?
Surely at least a compiler barrier is needed?
> and the race not completely closed imho...
How so? I could've missed something, but I've hammered the patch
pretty hard, fwiw.
> I need to think about it a bit more closely but what about instead
> just check if tb_ticks goes negative, and if yes, just do get_tb()
> again ? That might be faster than having a sync in there and should
> still be correct.
I did try something like that but found that a loop (i.e. multiple
get_tb's to "catch up") was necessary.
^ permalink raw reply
* Re: [PATCH 1/2]: powerpc/cell spidernet bottom half
From: Linas Vepstas @ 2006-08-17 0:23 UTC (permalink / raw)
To: David Miller
Cc: akpm, arnd, jeff, netdev, jklewis, linux-kernel, linuxppc-dev,
Jens.Osterkamp
In-Reply-To: <20060816.163252.64000941.davem@davemloft.net>
On Wed, Aug 16, 2006 at 04:32:52PM -0700, David Miller wrote:
> From: linas@austin.ibm.com (Linas Vepstas)
> > Why would you want to do this? It seems like a cruddier strategy
> > than what we can already do (which is to never get an transmit
> > interrupt, as long as the kernel can shove data into the device fast
> > enough to keep the queue from going empty.) The whole *point* of a
> > low-watermark interrupt is to never have to actually get the interrupt,
> > if the rest of the system is on its toes and is supplying data fast
> > enough.
>
> As long as TX packets get freed within a certain latency
> boundary, this kind of scheme should be fine.
I just had some fun making sure I wasn't making a liar out of myself.
So far, I'm good.
Did
echo 768111 > /proc/sys/net/core/wmem_max
echo 768111 > /proc/sys/net/core/wmem_default
to make sure that the app never blocked on a full socket.
(If the socket is small, then the app blocks,
the transmit queue drains, and we do get an interupt --
about 1K/sec, which is what is expected).
Ran 'vmstat 10' to watch the interrupts in real time.
Ran netperf, got 904 Mbits/sec, and *no* interrupts.
Yahoo!
Ran oprofile to see where he time went:
CPU: ppc64 Cell Broadband Engine, speed 3200 MHz (estimated)
Counted CYCLES events (Processor Cycles) with a unit mask of 0x00 (No unit mask) count 100000
samples % image name app name symbol name
13748742 77.6620 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .cbe_idle
936172 5.2881 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .__copy_tofrom_user
569353 3.2161 spidernet.ko spidernet .spider_net_xmit
450826 2.5466 spidernet.ko spidernet .spider_net_release_tx_chain
220374 1.2448 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 ._spin_unlock_irqrestore
112432 0.6351 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 ._spin_lock
91328 0.5159 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .__qdisc_run
84804 0.4790 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .packet_sendmsg
76167 0.4302 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .kfree
74321 0.4198 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .sock_alloc_send_skb
65323 0.3690 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .kmem_cache_free
60334 0.3408 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 ._read_lock
60071 0.3393 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .dev_queue_xmit
56900 0.3214 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .kmem_cache_alloc_node
55281 0.3123 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .sock_wfree
51242 0.2894 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .dev_get_by_index
50438 0.2849 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .compat_sys_socketcall
49247 0.2782 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .fput
48589 0.2745 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .sync_buffer
46055 0.2601 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 system_call_common
40607 0.2294 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .local_bh_enable
40273 0.2275 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .__might_sleep
38757 0.2189 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .fget_light
38219 0.2159 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .__kfree_skb
36804 0.2079 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .sock_def_write_space
36443 0.2059 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .skb_release_data
32174 0.1817 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .sys_sendto
31828 0.1798 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .sock_sendmsg
30676 0.1733 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .pfifo_fast_dequeue
29607 0.1672 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .add_event_entry
25870 0.1461 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 syscall_exit
25329 0.1431 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .__alloc_skb
23885 0.1349 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .__do_softirq
22046 0.1245 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .kmem_find_general_cachep
21610 0.1221 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .__dev_get_by_index
21059 0.1190 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .dma_map_single
21044 0.1189 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 ._spin_lock_irqsave
20105 0.1136 vmlinux-2.6.18-rc2 vmlinux-2.6.18-rc2 .memset
.__copy_tofrom_user -- ouch spider does not currently do scatter-gather
.spider_net_xmit -- hmmm ?? why is it this large ??
.spider_net_release_tx_chain -- ?? a lot of time being spent cleaning up tx queues.
._spin_unlock_irqrestore -- hmm ? why so high? lock contention?
I presume the rest is normal.
^ permalink raw reply
* Re: [RFC PATCH 1/4] powerpc 2.6.16-rt17: to build on powerpc w/ RT
From: Benjamin Herrenschmidt @ 2006-08-17 0:26 UTC (permalink / raw)
To: john stultz; +Cc: linux-kernel, linuxppc-dev, Paul Mackerras, mingo, tglx
In-Reply-To: <1155772859.15360.12.camel@localhost.localdomain>
> Hey Ben,
> I appreciate your looking over my patch. You are correct, the
> conversion is a bit rough and I've not yet been able to work on the
> powerpc vDSO, although I'd like to get it working so any help or
> suggestions would be appreciated (is there a reason the vDSO is written
> in ASM?).
>
> If you have any other concerns w/ that patch, or the generic timekeeping
> code, please let me know and I'll do what I can to address them.
Well, I've been wanting to look at your stuff and possibly do the
conversion for some time, provided we don't lose performances ... Our
current implementation is very optimized to avoid even memory barriers
in most cases and I doubt we'll be able to be as fine tuned using your
generic code, thus it's a tradeoff decision that we have to do. But
then, I need to look into the details before doing any final
statement :)
As for why the vDSO is in assembly, well... because it's kewl ? :) More
seriously, because it's much more simpler that way (and it's hand
optimized in a couple of places, though that would probably benefit
going through a proper scheduling analysis). The vDSO code has "special"
calling conventions (like the need to tweak cr.so, the non-use of the
TOC, the lack of procedure descriptors, symbols are offsets to the
functions, etc...) that makes it awkward to write it in C.
Ben
^ permalink raw reply
* Re: [PATCH] fix gettimeofday vs. update_gtod race
From: Benjamin Herrenschmidt @ 2006-08-17 0:27 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060817001807.GB354@localdomain>
On Wed, 2006-08-16 at 19:18 -0500, Nathan Lynch wrote:
> No? I didn't find anything about mftb having synchronizing
> behavior. How should we ensure that temp_varp is assigned before
> reading the timebase?
I sync an isync would be enough.
> Surely at least a compiler barrier is needed?
Yeah.
> > and the race not completely closed imho...
>
> How so? I could've missed something, but I've hammered the patch
> pretty hard, fwiw.
Nah you are right, but you may be using a too big hammer
> > I need to think about it a bit more closely but what about instead
> > just check if tb_ticks goes negative, and if yes, just do get_tb()
> > again ? That might be faster than having a sync in there and should
> > still be correct.
>
> I did try something like that but found that a loop (i.e. multiple
> get_tb's to "catch up") was necessary.
Hrm... even with an isync ?
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Make RTAS console init generic
From: Michael Ellerman @ 2006-08-17 0:44 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20060816152303.7AF4967B5A@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 2991 bytes --]
On Wed, 2006-08-16 at 10:22 -0500, Michael Neuling wrote:
> In message <1155705695.12715.7.camel@localhost.localdomain> you wrote:
> >
> > --=-PNKyW5KJv4630LcmkXVt
> > Content-Type: text/plain
> > Content-Transfer-Encoding: quoted-printable
> >
> > On Tue, 2006-08-15 at 23:00 -0500, Michael Neuling wrote:
> > > The RTAS console doesn't have to be Cell specific. If we have both
> > > the put and get char RTAS functions, init the rtas console.
> > >=20
> > > Index: linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/rtas.c
> > > +++ linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
> > > @@ -910,6 +910,11 @@ int __init early_init_dt_scan_rtas(unsig
> > > basep =3D of_get_flat_dt_prop(node, "get-term-char", NULL);
> > > if (basep)
> > > rtas_getchar_token =3D *basep;
> > > +
> > > + if (rtas_putchar_token !=3D RTAS_UNKNOWN_SERVICE &&
> > > + rtas_getchar_token !=3D RTAS_UNKNOWN_SERVICE)
> > > + udbg_init_rtas_console();
> > > +
> > > #endif
> > > =20
> > > /* break now */
> > > Index: linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > --- linux-2.6-ozlabs.orig/arch/powerpc/platforms/cell/setup.c
> > > +++ linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
> > > @@ -150,10 +150,6 @@ static int __init cell_probe(void)
> > > !of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
> > > return 0;
> > > =20
> > > -#ifdef CONFIG_UDBG_RTAS_CONSOLE
> > > - udbg_init_rtas_console();
> > > -#endif
> > > -
> >
> > I'd like to see it still guarded by UDBG_RTAS_CONSOLE, otherwise there's
> > no way to select a different type of early console on a machine which
> > has those tokens in the device tree.
>
> Agreed but that section in rtas.c is already guarded by
> UDBG_RTAS_CONSOLE. After applying the patch, it looks like:
>
> #ifdef CONFIG_UDBG_RTAS_CONSOLE
> basep = of_get_flat_dt_prop(node, "put-term-char", NULL);
> if (basep)
> rtas_putchar_token = *basep;
>
> basep = of_get_flat_dt_prop(node, "get-term-char", NULL);
> if (basep)
> rtas_getchar_token = *basep;
>
> if (rtas_putchar_token != RTAS_UNKNOWN_SERVICE &&
> rtas_getchar_token != RTAS_UNKNOWN_SERVICE)
> udbg_init_rtas_console();
>
> #endif
Ah sorry, I just looked at the patch.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Linux hanging on Xilinx SystemACE
From: Jeff Angielski @ 2006-08-17 0:51 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0608161448y26e13398v3b818ed5f1124295@mail.gmail.com>
On Wed, 2006-08-16 at 15:48 -0600, Grant Likely wrote:
> On 8/16/06, Clint Thomas <cthomas@soneticom.com> wrote:
> >
> >
> > Hey,
> >
> > Using the powerpc development tree of Linux 2.4, I am trying to boot my
> > system from CompactFlash using Xilinx SystemACE. My compact flash card has
> > two partitions, a 16MB FAT16 that holds the combination FPGA image / Linux
> > Kernel ELF file, and an Ext2 partition that holds the root file system. The
> > system starts the boot process, uncompresses the Linux kernel and begins
> > loading drivers. Part way into this process, it conducts a partition check
> > of the drive being reported to it by SystemACE, however, it hangs at that
> > point. No kernel panic, no error message, it simply hangs. Here is the
> > output at that point...
> >
> > Partition check:
> > xsysacea:
> >
> > what I am trying to find out is if this problem has been seen/fixed in the
> > past? or did I format the CF card incorrectly?
I forgot to mention that we used to see this problem when the identify
command that is sent during intialization fails. The driver is written
in such a way that if any of this fails, the system hangs because it
sits in a polling loop waiting for the correct response. There are no
timeout failures... :( In our case we saw this error because we forgot
to put a CF into the system [usually during development with NFS
rootfs].
It is fairly easy to printk() the drivers init code to find out which
step is stuck in the polling loop.
> Checking partitions is a user-space activity (fsck). Remove it from
> your init scripts. Besides, unless your using a microdrive, your ext2
> rootfs should be mounted read-only which greatly reduces the need for
> fsck. (because FLASH will wear out after too many writes)
The partition check he is referring to is part of a block device driver
initialization. It is not fsck. If he were only so luck to be that far
in the startup sequence... :)
Jeff Angielski
The PTR Group
^ permalink raw reply
* Re: [RFC PATCH 1/4] powerpc 2.6.16-rt17: to build on powerpc w/ RT
From: john stultz @ 2006-08-17 0:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, mingo, tglx
In-Reply-To: <1155774368.11312.135.camel@localhost.localdomain>
On Thu, 2006-08-17 at 02:26 +0200, Benjamin Herrenschmidt wrote:
> > Hey Ben,
> > I appreciate your looking over my patch. You are correct, the
> > conversion is a bit rough and I've not yet been able to work on the
> > powerpc vDSO, although I'd like to get it working so any help or
> > suggestions would be appreciated (is there a reason the vDSO is written
> > in ASM?).
> >
> > If you have any other concerns w/ that patch, or the generic timekeeping
> > code, please let me know and I'll do what I can to address them.
>
> Well, I've been wanting to look at your stuff and possibly do the
> conversion for some time, provided we don't lose performances ... Our
> current implementation is very optimized to avoid even memory barriers
> in most cases and I doubt we'll be able to be as fine tuned using your
> generic code, thus it's a tradeoff decision that we have to do. But
> then, I need to look into the details before doing any final
> statement :)
Ok, although do let me know if you see places where the generic code
could use any of the optimizations used in powerpc.
thanks
-john
^ permalink raw reply
* Re: Linux hanging on Xilinx SystemACE
From: Grant Likely @ 2006-08-17 1:40 UTC (permalink / raw)
To: Jeff Angielski; +Cc: linuxppc-embedded
In-Reply-To: <1155775917.10357.37.camel@sumo-jaa>
On 8/16/06, Jeff Angielski <jangiels@speakeasy.net> wrote:
> On Wed, 2006-08-16 at 15:48 -0600, Grant Likely wrote:
> > Checking partitions is a user-space activity (fsck). Remove it from
> > your init scripts. Besides, unless your using a microdrive, your ext2
> > rootfs should be mounted read-only which greatly reduces the need for
> > fsck. (because FLASH will wear out after too many writes)
>
> The partition check he is referring to is part of a block device driver
> initialization. It is not fsck. If he were only so luck to be that far
> in the startup sequence... :)
heh; I grepped the 2.6 kernel tree for "Partition check" and didn't
find anything, and I assumed that it wasn't in 2.4 either. Therefore
it must be a fsck message...
You know what they say about assuming.
oops
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH] Fix irq radix tree remapping typo
From: Benjamin Herrenschmidt @ 2006-08-17 1:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Manoj Iyer
The code for using the radix tree for reverse mapping of interrupts has
a typo that causes it to create incorrect mappings if the software and
hardware numbers happen to be different. This would, among others, cause
the IDE interrupt to fail on js20's. This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Please apply to 2.6.18
Index: linux-work/arch/powerpc/kernel/irq.c
===================================================================
--- linux-work.orig/arch/powerpc/kernel/irq.c 2006-08-17 09:26:19.000000000 +1000
+++ linux-work/arch/powerpc/kernel/irq.c 2006-08-17 11:27:30.000000000 +1000
@@ -693,7 +693,7 @@ unsigned int irq_radix_revmap(struct irq
/* If not there, try to insert it */
virq = irq_find_mapping(host, hwirq);
if (virq != NO_IRQ)
- radix_tree_insert(tree, virq, &irq_map[virq]);
+ radix_tree_insert(tree, hwirq, &irq_map[virq]);
bail:
spin_unlock_irqrestore(&irq_big_lock, flags);
return virq;
^ permalink raw reply
* Re: [PATCH] powerpc: Make RTAS console init generic
From: Michael Ellerman @ 2006-08-17 2:04 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20060816194225.C9F1F67B32@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1246 bytes --]
On Wed, 2006-08-16 at 14:42 -0500, Michael Neuling wrote:
> The rtas console doesn't have to be Cell specific. If we get both
> rtas tokens, we should just enabled the console then and there.
>
Seems to work fine on Cell.
> Updated Kconfig so we can enable it.
I enable it via the early debugging menu (under kernel hacking), is that
not good enough?
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/kernel/rtas.c | 5 +++++
> arch/powerpc/platforms/cell/setup.c | 4 ----
> 3 files changed, 6 insertions(+), 5 deletions(-)
>
> Index: linux-2.6-ozlabs/arch/powerpc/Kconfig
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/Kconfig
> +++ linux-2.6-ozlabs/arch/powerpc/Kconfig
> @@ -426,7 +426,7 @@ config PPC_IBM_CELL_BLADE
> select UDBG_RTAS_CONSOLE
>
> config UDBG_RTAS_CONSOLE
> - bool
> + bool "RTAS based debug console"
> default n
This should probably depend on RTAS?
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Make RTAS console init generic
From: Michael Neuling @ 2006-08-17 3:27 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <1155780267.6910.3.camel@localhost.localdomain>
> Seems to work fine on Cell.
Kewl
> > Updated Kconfig so we can enable it.
>
> I enable it via the early debugging menu (under kernel hacking), is that
> not good enough?
Doesn't that enable CONFIG_PPC_EARLY_DEBUG_RTAS_CONSOLE not
CONFIG_UDBG_RTAS_CONSOLE?
Without the Kconfig update you don't seem to get presented with an
option but I'm no kbuild expert.
> > config UDBG_RTAS_CONSOLE
> > - bool
> > + bool "RTAS based debug console"
> > default n
>
> This should probably depend on RTAS?
Yeap.
Mikey
^ permalink raw reply
* Re: [PATCH] powerpc: Make RTAS console init generic
From: Michael Ellerman @ 2006-08-17 3:45 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20060817032723.25A2767B6D@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 812 bytes --]
On Wed, 2006-08-16 at 22:27 -0500, Michael Neuling wrote:
> > Seems to work fine on Cell.
>
> Kewl
>
> > > Updated Kconfig so we can enable it.
> >
> > I enable it via the early debugging menu (under kernel hacking), is that
> > not good enough?
>
> Doesn't that enable CONFIG_PPC_EARLY_DEBUG_RTAS_CONSOLE not
> CONFIG_UDBG_RTAS_CONSOLE?
Yeah, but that then turns on CONFIG_UDBG_RTAS_CONSOLE also. I guess you
guys want to be able to turn on the later without the former, so fair
enough. We turn it on always on the Cell via the PPC_IBM_CELL_BLADE
entry.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Make RTAS console init generic
From: Michael Neuling @ 2006-08-17 4:02 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <1155786333.10665.3.camel@localhost.localdomain>
> Yeah, but that then turns on CONFIG_UDBG_RTAS_CONSOLE also. I guess
> you guys want to be able to turn on the later without the former, so
> fair enough.
Yeap.
Mikey
^ permalink raw reply
* [PATCH] powerpc: Make RTAS console init generic
From: Michael Neuling @ 2006-08-17 4:12 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, anton
The rtas console doesn't have to be Cell specific. If we get both
RTAS tokens, we should just enabled the console then and there.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Fixed RTAS dependency bug.
arch/powerpc/Kconfig | 3 ++-
arch/powerpc/kernel/rtas.c | 5 +++++
arch/powerpc/platforms/cell/setup.c | 4 ----
3 files changed, 7 insertions(+), 5 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/Kconfig
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/Kconfig
+++ linux-2.6-ozlabs/arch/powerpc/Kconfig
@@ -426,7 +426,8 @@ config PPC_IBM_CELL_BLADE
select UDBG_RTAS_CONSOLE
config UDBG_RTAS_CONSOLE
- bool
+ bool "RTAS based debug console"
+ depends on PPC_RTAS
default n
config XICS
Index: linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/rtas.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
@@ -910,6 +910,11 @@ int __init early_init_dt_scan_rtas(unsig
basep = of_get_flat_dt_prop(node, "get-term-char", NULL);
if (basep)
rtas_getchar_token = *basep;
+
+ if (rtas_putchar_token != RTAS_UNKNOWN_SERVICE &&
+ rtas_getchar_token != RTAS_UNKNOWN_SERVICE)
+ udbg_init_rtas_console();
+
#endif
/* break now */
Index: linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/cell/setup.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
@@ -150,10 +150,6 @@ static int __init cell_probe(void)
!of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
return 0;
-#ifdef CONFIG_UDBG_RTAS_CONSOLE
- udbg_init_rtas_console();
-#endif
-
hpte_init_native();
return 1;
^ permalink raw reply
* Re: [RFC PATCH 1/4] powerpc 2.6.16-rt17: to build on powerpc w/ RT
From: Benjamin Herrenschmidt @ 2006-08-17 4:43 UTC (permalink / raw)
To: john stultz; +Cc: linux-kernel, linuxppc-dev, Paul Mackerras, mingo, tglx
In-Reply-To: <1155776171.15360.22.camel@localhost.localdomain>
> > Well, I've been wanting to look at your stuff and possibly do the
> > conversion for some time, provided we don't lose performances ... Our
> > current implementation is very optimized to avoid even memory barriers
> > in most cases and I doubt we'll be able to be as fine tuned using your
> > generic code, thus it's a tradeoff decision that we have to do. But
> > then, I need to look into the details before doing any final
> > statement :)
>
> Ok, although do let me know if you see places where the generic code
> could use any of the optimizations used in powerpc.
Difficult... but maybe. One of the main idea is that the 3 values used
for "calibration" (pre-mult offset, multiplier and post-mult offset) are
in a structure. There is an array of 2 of these and a pointer to the
"current" one. When changing those values, we update the "other" one,
wmb, then flip the pointer. The readers can then mostly be barrier-less
since there is a natural data dependency on the pointer.
Ben.
^ permalink raw reply
* Re: [PATCH] Gunzip call fix for PPC kernel images >4MB
From: Tom Rini @ 2006-08-17 5:04 UTC (permalink / raw)
To: Benjamin Heyne; +Cc: linuxppc-dev, Paul Mackerras, Milton Miller
In-Reply-To: <20060816113137.7a8e5608@bob.dt.e-technik.uni-dortmund.de>
On Wed, Aug 16, 2006 at 11:31:37AM +0200, Benjamin Heyne wrote:
> If Kernel images for PPC grow >4MB inflating of the kernel fails.
> Increasing the link/load address doesn't help. Problem is
> solved by replacing the fixed address of the gunzip() call in
> misc-embedded.c with CONFIG_BOOT_LOAD.
I've thought about this a bit and I think the general concept is OK, but
this works with a bit of luck I think.
The arch/ppc/boot code makes some assumptions such as that 4MB-8MB (except
on 40x which is end of the wrapper code to 8MB, and BOOT_LOAD defaults
to 4MB here) is free to use for malloc()'ing for the inflate routine.
It also assumes that the vmlinux.gz will live at BOOT_LOAD + a bit, when
the wrapper is set to kick off linux.
Finally, in arch/ppc/boot/ (for both OF and !OF cases) gunzip looks
like:
void gunzip(void *dst, int dstlen, unsigned char *src, int *lenp)
So I see 2 problems here.
First, there are other calls to gunzip with dstlen hard-coded to 4MB, so
the problem would still exist.
Second, and more complexly we want to make sure that we don't tell
gunzip that the destination size grows into the area it would also be
using to malloc buffers, unless someone can (and please do if possible)
explain that it's really OK to uncompress into our zalloc space (there
is no zfree so maybe it's going to be OK, but I don't know that the
algorithm wouldn't try and reuse buffers which would be bad).
Thanks!
--
Tom Rini
^ permalink raw reply
* [POWERPC] iseries: remove some gcc 4.1 warnings
From: Stephen Rothwell @ 2006-08-17 6:28 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <200608161515.26166.arnd.bergmann@de.ibm.com>
gcc 4.1 produces some warnings that say it is ignoring the packed
attribute on some structure elements, so, since all the elements of
these structs are packed, pack the structs instead.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/main_store.h | 126 ++++++++++++++-------------
1 files changed, 63 insertions(+), 63 deletions(-)
This version takes into account Arnds good suggestion.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/arch/powerpc/platforms/iseries/main_store.h b/arch/powerpc/platforms/iseries/main_store.h
index 74f6889..1a7a3f5 100644
--- a/arch/powerpc/platforms/iseries/main_store.h
+++ b/arch/powerpc/platforms/iseries/main_store.h
@@ -61,9 +61,9 @@ struct IoHriMainStoreSegment4 {
};
/* Main Store VPD for Power4 */
-struct IoHriMainStoreChipInfo1 {
- u32 chipMfgID __attribute((packed));
- char chipECLevel[4] __attribute((packed));
+struct __attribute((packed)) IoHriMainStoreChipInfo1 {
+ u32 chipMfgID;
+ char chipECLevel[4];
};
struct IoHriMainStoreVpdIdData {
@@ -73,72 +73,72 @@ struct IoHriMainStoreVpdIdData {
char serialNumber[12];
};
-struct IoHriMainStoreVpdFruData {
- char fruLabel[8] __attribute((packed));
- u8 numberOfSlots __attribute((packed));
- u8 pluggingType __attribute((packed));
- u16 slotMapIndex __attribute((packed));
+struct __attribute((packed)) IoHriMainStoreVpdFruData {
+ char fruLabel[8];
+ u8 numberOfSlots;
+ u8 pluggingType;
+ u16 slotMapIndex;
};
-struct IoHriMainStoreAdrRangeBlock {
- void *blockStart __attribute((packed));
- void *blockEnd __attribute((packed));
- u32 blockProcChipId __attribute((packed));
+struct __attribute((packed)) IoHriMainStoreAdrRangeBlock {
+ void *blockStart;
+ void *blockEnd;
+ u32 blockProcChipId;
};
#define MaxAreaAdrRangeBlocks 4
-struct IoHriMainStoreArea4 {
- u32 msVpdFormat __attribute((packed));
- u8 containedVpdType __attribute((packed));
- u8 reserved1 __attribute((packed));
- u16 reserved2 __attribute((packed));
-
- u64 msExists __attribute((packed));
- u64 msFunctional __attribute((packed));
-
- u32 memorySize __attribute((packed));
- u32 procNodeId __attribute((packed));
-
- u32 numAdrRangeBlocks __attribute((packed));
- struct IoHriMainStoreAdrRangeBlock xAdrRangeBlock[MaxAreaAdrRangeBlocks] __attribute((packed));
-
- struct IoHriMainStoreChipInfo1 chipInfo0 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo1 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo2 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo3 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo4 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo5 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo6 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo7 __attribute((packed));
-
- void *msRamAreaArray __attribute((packed));
- u32 msRamAreaArrayNumEntries __attribute((packed));
- u32 msRamAreaArrayEntrySize __attribute((packed));
-
- u32 numaDimmExists __attribute((packed));
- u32 numaDimmFunctional __attribute((packed));
- void *numaDimmArray __attribute((packed));
- u32 numaDimmArrayNumEntries __attribute((packed));
- u32 numaDimmArrayEntrySize __attribute((packed));
-
- struct IoHriMainStoreVpdIdData idData __attribute((packed));
-
- u64 powerData __attribute((packed));
- u64 cardAssemblyPartNum __attribute((packed));
- u64 chipSerialNum __attribute((packed));
-
- u64 reserved3 __attribute((packed));
- char reserved4[16] __attribute((packed));
-
- struct IoHriMainStoreVpdFruData fruData __attribute((packed));
-
- u8 vpdPortNum __attribute((packed));
- u8 reserved5 __attribute((packed));
- u8 frameId __attribute((packed));
- u8 rackUnit __attribute((packed));
- char asciiKeywordVpd[256] __attribute((packed));
- u32 reserved6 __attribute((packed));
+struct __attribute((packed)) IoHriMainStoreArea4 {
+ u32 msVpdFormat;
+ u8 containedVpdType;
+ u8 reserved1;
+ u16 reserved2;
+
+ u64 msExists;
+ u64 msFunctional;
+
+ u32 memorySize;
+ u32 procNodeId;
+
+ u32 numAdrRangeBlocks;
+ struct IoHriMainStoreAdrRangeBlock xAdrRangeBlock[MaxAreaAdrRangeBlocks];
+
+ struct IoHriMainStoreChipInfo1 chipInfo0;
+ struct IoHriMainStoreChipInfo1 chipInfo1;
+ struct IoHriMainStoreChipInfo1 chipInfo2;
+ struct IoHriMainStoreChipInfo1 chipInfo3;
+ struct IoHriMainStoreChipInfo1 chipInfo4;
+ struct IoHriMainStoreChipInfo1 chipInfo5;
+ struct IoHriMainStoreChipInfo1 chipInfo6;
+ struct IoHriMainStoreChipInfo1 chipInfo7;
+
+ void *msRamAreaArray;
+ u32 msRamAreaArrayNumEntries;
+ u32 msRamAreaArrayEntrySize;
+
+ u32 numaDimmExists;
+ u32 numaDimmFunctional;
+ void *numaDimmArray;
+ u32 numaDimmArrayNumEntries;
+ u32 numaDimmArrayEntrySize;
+
+ struct IoHriMainStoreVpdIdData idData;
+
+ u64 powerData;
+ u64 cardAssemblyPartNum;
+ u64 chipSerialNum;
+
+ u64 reserved3;
+ char reserved4[16];
+
+ struct IoHriMainStoreVpdFruData fruData;
+
+ u8 vpdPortNum;
+ u8 reserved5;
+ u8 frameId;
+ u8 rackUnit;
+ char asciiKeywordVpd[256];
+ u32 reserved6;
};
--
1.4.1.1
^ permalink raw reply related
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