All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
@ 2014-08-22  5:53 Allen Pais
  2014-08-23 18:51 ` David Miller
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: Allen Pais @ 2014-08-22  5:53 UTC (permalink / raw)
  To: sparclinux

 The following patch adds support for correctly
recognising M7 cpu type.

Signed-off-by: Allen Pais <allen.pais@oracle.com>
---
 arch/sparc/include/asm/spitfire.h |  1 +
 arch/sparc/kernel/cpu.c           |  6 ++++++
 arch/sparc/kernel/head_64.S       | 14 ++++++++++++++
 3 files changed, 21 insertions(+)

diff --git a/arch/sparc/include/asm/spitfire.h b/arch/sparc/include/asm/spitfire.h
index 3fc58691..9aec17b 100644
--- a/arch/sparc/include/asm/spitfire.h
+++ b/arch/sparc/include/asm/spitfire.h
@@ -45,6 +45,7 @@
 #define SUN4V_CHIP_NIAGARA3	0x03
 #define SUN4V_CHIP_NIAGARA4	0x04
 #define SUN4V_CHIP_NIAGARA5	0x05
+#define SUN4V_CHIP_SPARC_M7	0x08
 #define SUN4V_CHIP_SPARC64X	0x8a
 #define SUN4V_CHIP_UNKNOWN	0xff
 
diff --git a/arch/sparc/kernel/cpu.c b/arch/sparc/kernel/cpu.c
index 82a3a71..55dfb62 100644
--- a/arch/sparc/kernel/cpu.c
+++ b/arch/sparc/kernel/cpu.c
@@ -494,6 +494,12 @@ static void __init sun4v_cpu_probe(void)
 		sparc_pmu_type = "niagara5";
 		break;
 
+	case SUN4V_CHIP_SPARC_M7:
+		sparc_cpu_type = "SPARC-M7";
+		sparc_fpu_type = "SPARC-M7 integrated FPU";
+		sparc_pmu_type = "sparc-m7";
+		break;
+
 	case SUN4V_CHIP_SPARC64X:
 		sparc_cpu_type = "SPARC64-X";
 		sparc_fpu_type = "SPARC64-X integrated FPU";
diff --git a/arch/sparc/kernel/head_64.S b/arch/sparc/kernel/head_64.S
index 452f04f..577abba0 100644
--- a/arch/sparc/kernel/head_64.S
+++ b/arch/sparc/kernel/head_64.S
@@ -414,6 +414,8 @@ sun4v_chip_type:
 	cmp	%g2, 'T'
 	be,pt	%xcc, 70f
 	 cmp	%g2, 'M'
+	be,pt	%xcc, 71f
+	 nop
 	bne,pn	%xcc, 49f
 	 nop
 
@@ -430,6 +432,14 @@ sun4v_chip_type:
 	ba,pt	%xcc, 49f
 	 nop
 
+71:
+	ldub	[%g1 + 7], %g2
+	cmp	%g2, '7'
+	be,pt	%xcc, 5f
+	 mov	SUN4V_CHIP_SPARC_M7, %g4
+	ba,pt	%xcc, 49f
+	 nop
+
 91:	sethi	%hi(prom_cpu_compatible), %g1
 	or	%g1, %lo(prom_cpu_compatible), %g1
 	ldub	[%g1 + 17], %g2
@@ -586,6 +596,10 @@ niagara_tlb_fixup:
 	be,pt	%xcc, niagara4_patch
 	 nop
 
+	cmp	%g1, SUN4V_CHIP_SPARC_M7
+	be,pt	%xcc, niagara4_patch
+	 nop
+
 	call	generic_patch_copyops
 	 nop
 	call	generic_patch_bzero
-- 
1.8.4.2


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
  2014-08-22  5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
@ 2014-08-23 18:51 ` David Miller
  2014-08-24  6:18 ` David Miller
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: David Miller @ 2014-08-23 18:51 UTC (permalink / raw)
  To: sparclinux

From: Allen Pais <allen.pais@oracle.com>
Date: Fri, 22 Aug 2014 11:22:51 +0530

>  The following patch adds support for correctly
> recognising M7 cpu type.
> 
> Signed-off-by: Allen Pais <allen.pais@oracle.com>

I don't think this is correct.

> @@ -414,6 +414,8 @@ sun4v_chip_type:
>  	cmp	%g2, 'T'
>  	be,pt	%xcc, 70f
>  	 cmp	%g2, 'M'
> +	be,pt	%xcc, 71f
> +	 nop
>  	bne,pn	%xcc, 49f
>  	 nop

This code block is supposed to fallthrough when %g2 is 'M' so that
we accept all of "{T,M}345..." but your change is breaking that
such that we will now only accept "M" as a prefix for "7".

That's a regression.

All you have to do is add the new comparison against '7' in the
"70:" label code block, and you're done.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
  2014-08-22  5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
  2014-08-23 18:51 ` David Miller
@ 2014-08-24  6:18 ` David Miller
  2014-08-24  6:19 ` Allen Pais
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: David Miller @ 2014-08-24  6:18 UTC (permalink / raw)
  To: sparclinux

From: Allen Pais <allen.pais@oracle.com>
Date: Sun, 24 Aug 2014 11:37:09 +0530

>> 
>> I don't think this is correct.
>> 
>>> @@ -414,6 +414,8 @@ sun4v_chip_type:
>>>  	cmp	%g2, 'T'
>>>  	be,pt	%xcc, 70f
>>>  	 cmp	%g2, 'M'
>>> +	be,pt	%xcc, 71f
>>> +	 nop
>>>  	bne,pn	%xcc, 49f
>>>  	 nop
>> 
>> This code block is supposed to fallthrough when %g2 is 'M' so that
>> we accept all of "{T,M}345..." but your change is breaking that
>> such that we will now only accept "M" as a prefix for "7".
>> 
>> That's a regression.
>> 
>> All you have to do is add the new comparison against '7' in the
>> "70:" label code block, and you're done.
> 
>  The idea was to also have M5 and M6-32 cpu types supported too with M7. 
> 
> +71:
> +	ldub	[%g1 + 7], %g2
> +	cmp	%g1, '5'
> +	be,pt	%xcc, 5f
> +	 mov	SUN4V_CHIP_SPARC_M5, %g4
> +	cmp	%g1, '6'
> +	be,pt	%xcc, 5f
> +	 mov	SUN4V_CHIP_SPARC_M6, %g4
> +       cmp     %g2, '7'
> +       be,pt   %xcc, 5f
> +        mov    SUN4V_CHIP_SPARC_M7, %g4
> +       ba,pt   %xcc, 49f
> +        nop
> +

Again, why are you bothing with a special code path at all?  You don't
need to.

Just add the M7 test to the "70:" label code block, and you're done.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
  2014-08-22  5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
  2014-08-23 18:51 ` David Miller
  2014-08-24  6:18 ` David Miller
@ 2014-08-24  6:19 ` Allen Pais
  2014-08-24  6:31 ` Allen Pais
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Allen Pais @ 2014-08-24  6:19 UTC (permalink / raw)
  To: sparclinux

> 
> I don't think this is correct.
> 
>> @@ -414,6 +414,8 @@ sun4v_chip_type:
>>  	cmp	%g2, 'T'
>>  	be,pt	%xcc, 70f
>>  	 cmp	%g2, 'M'
>> +	be,pt	%xcc, 71f
>> +	 nop
>>  	bne,pn	%xcc, 49f
>>  	 nop
> 
> This code block is supposed to fallthrough when %g2 is 'M' so that
> we accept all of "{T,M}345..." but your change is breaking that
> such that we will now only accept "M" as a prefix for "7".
> 
> That's a regression.
> 
> All you have to do is add the new comparison against '7' in the
> "70:" label code block, and you're done.

 The idea was to also have M5 and M6-32 cpu types supported too with M7. 

+71:
+	ldub	[%g1 + 7], %g2
+	cmp	%g1, '5'
+	be,pt	%xcc, 5f
+	 mov	SUN4V_CHIP_SPARC_M5, %g4
+	cmp	%g1, '6'
+	be,pt	%xcc, 5f
+	 mov	SUN4V_CHIP_SPARC_M6, %g4
+       cmp     %g2, '7'
+       be,pt   %xcc, 5f
+        mov    SUN4V_CHIP_SPARC_M7, %g4
+       ba,pt   %xcc, 49f
+        nop
+

 I haven't tested it yet on M5, I should have perhaps sent all them together. 
lemme know what you think.

- Allen
 


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
  2014-08-22  5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
                   ` (2 preceding siblings ...)
  2014-08-24  6:19 ` Allen Pais
@ 2014-08-24  6:31 ` Allen Pais
  2014-08-24  6:43 ` David Miller
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: Allen Pais @ 2014-08-24  6:31 UTC (permalink / raw)
  To: sparclinux

David,
> 
>> @@ -414,6 +414,8 @@ sun4v_chip_type:
>>  	cmp	%g2, 'T'
>>  	be,pt	%xcc, 70f
>>  	 cmp	%g2, 'M'
>> +	be,pt	%xcc, 71f
>> +	 nop
>>  	bne,pn	%xcc, 49f
>>  	 nop
> 
> This code block is supposed to fallthrough when %g2 is 'M' so that
> we accept all of "{T,M}345..." but your change is breaking that
> such that we will now only accept "M" as a prefix for "7".
> 
> That's a regression.
> 
> All you have to do is add the new comparison against '7' in the
> "70:" label code block, and you're done.
> 

 When we are on this topic, here's a patch that attempts to simplify 
cpu detection. 

Here's a quick diff.

diff --git a/arch/sparc/kernel/cpu.c b/arch/sparc/kernel/cpu.c
index 5c51258..c06e27e 100644
--- a/arch/sparc/kernel/cpu.c
+++ b/arch/sparc/kernel/cpu.c
@@ -460,6 +460,36 @@ static int __init cpu_type_probe(void)
 #endif /* CONFIG_SPARC32 */
 
 #ifdef CONFIG_SPARC64
+
+static struct sun4v_chip_names {
+       const char *name;
+       unsigned long chip;
+} sun4v_names[] __initdata = {
+       {"SUNW,UltraSPARC-T1", SUN4V_CHIP_NIAGARA1},
+       {"SUNW,UltraSPARC-T2", SUN4V_CHIP_NIAGARA2},
+       {"SUNW,UltraSPARC-T2+", SUN4V_CHIP_NIAGARA2},
+       {"SUNW,UltraSPARC-T3", SUN4V_CHIP_NIAGARA3},
+       {"SPARC-T4", SUN4V_CHIP_NIAGARA4},
+       {"SPARC64-X", SUN4V_CHIP_SPARC64X},
+       {"SPARC-T5", SUN4V_CHIP_NIAGARA5},
+       {"SPARC-M7", SUN4V_CHIP_SPARC_M7},
+};
+
+unsigned long __init determine_sun4v_cpu(void)
+{
+       unsigned int nr_chips = ARRAY_SIZE(sun4v_names);
+       unsigned long chip_type = SUN4V_CHIP_UNKNOWN;
+       unsigned int i;
+
+       for (i = 0; i < nr_chips; i++) {
+               if (strcmp(prom_cpu_compatible, sun4v_names[i].name) = 0) {
+                       chip_type = sun4v_names[i].chip;
+                       break;
+               }
+       }
+       return chip_type;
+}
+
 static void __init sun4v_cpu_probe(void)
 {
        switch (sun4v_chip_type) {
diff --git a/arch/sparc/kernel/head_64.S b/arch/sparc/kernel/head_64.S
index 26b706a..be49bef 100644
--- a/arch/sparc/kernel/head_64.S
+++ b/arch/sparc/kernel/head_64.S
@@ -130,12 +130,6 @@ prom_set_trap_table_name:
        .asciz  "SUNW,set-trap-table"
 prom_sun4v_name:
        .asciz  "sun4v"
-prom_niagara_prefix:
-       .asciz  "SUNW,UltraSPARC-T"
-prom_sparc_prefix:
-       .asciz  "SPARC-"
-prom_sparc64x_prefix:
-       .asciz  "SPARC64-X"
        .align  4
 prom_root_compatible:
        .skip   64
@@ -376,91 +370,10 @@ sun4v_chip_type:
        call    %l7
         add    %sp, (2047 + 128), %o0          ! argument array
 
+       call    determine_sun4v_cpu
        add     %sp, (192 + 128), %sp
 
-       sethi   %hi(prom_cpu_compatible), %g1
-       or      %g1, %lo(prom_cpu_compatible), %g1
-       sethi   %hi(prom_niagara_prefix), %g7
-       or      %g7, %lo(prom_niagara_prefix), %g7
-       mov     17, %g3
-90:    ldub    [%g7], %g2
-       ldub    [%g1], %g4
-       cmp     %g2, %g4
-       bne,pn  %icc, 89f
-        add    %g7, 1, %g7
-       subcc   %g3, 1, %g3
-       bne,pt  %xcc, 90b
-        add    %g1, 1, %g1
-       ba,pt   %xcc, 91f
-        nop
-
-89:    sethi   %hi(prom_cpu_compatible), %g1
-       or      %g1, %lo(prom_cpu_compatible), %g1
-       sethi   %hi(prom_sparc_prefix), %g7
-       or      %g7, %lo(prom_sparc_prefix), %g7
-       mov     6, %g3
-90:    ldub    [%g7], %g2
-       ldub    [%g1], %g4
-       cmp     %g2, %g4
-       bne,pn  %icc, 4f
-        add    %g7, 1, %g7
-       subcc   %g3, 1, %g3
-       bne,pt  %xcc, 90b
-        add    %g1, 1, %g1
-
-       sethi   %hi(prom_cpu_compatible), %g1
-       or      %g1, %lo(prom_cpu_compatible), %g1
-       ldub    [%g1 + 6], %g2
-       cmp     %g2, 'T'
-       be,pt   %xcc, 70f
-        cmp    %g2, 'M'
-       bne,pn  %xcc, 49f
-        nop
-
-70:    ldub    [%g1 + 7], %g2
-       cmp     %g2, '3'
-       be,pt   %xcc, 5f
-        mov    SUN4V_CHIP_NIAGARA3, %g4
-       cmp     %g2, '4'
-       be,pt   %xcc, 5f
-        mov    SUN4V_CHIP_NIAGARA4, %g4
-       cmp     %g2, '5'
-       be,pt   %xcc, 5f
-        mov    SUN4V_CHIP_NIAGARA5, %g4
-       ba,pt   %xcc, 49f
-        nop
-
-91:    sethi   %hi(prom_cpu_compatible), %g1
-       or      %g1, %lo(prom_cpu_compatible), %g1
-       ldub    [%g1 + 17], %g2
-       cmp     %g2, '1'
-       be,pt   %xcc, 5f
-        mov    SUN4V_CHIP_NIAGARA1, %g4
-       cmp     %g2, '2'
-       be,pt   %xcc, 5f
-        mov    SUN4V_CHIP_NIAGARA2, %g4
-       
-4:
-       /* Athena */
-       sethi   %hi(prom_cpu_compatible), %g1
-       or      %g1, %lo(prom_cpu_compatible), %g1
-       sethi   %hi(prom_sparc64x_prefix), %g7
-       or      %g7, %lo(prom_sparc64x_prefix), %g7
-       mov     9, %g3
-41:    ldub    [%g7], %g2
-       ldub    [%g1], %g4
-       cmp     %g2, %g4
-       bne,pn  %icc, 49f
-       add     %g7, 1, %g7
-       subcc   %g3, 1, %g3
-       bne,pt  %xcc, 41b
-       add     %g1, 1, %g1
-       mov     SUN4V_CHIP_SPARC64X, %g4
-       ba,pt   %xcc, 5f
-       nop
-
-49:
-       mov     SUN4V_CHIP_UNKNOWN, %g4
+       or      %o0, %g0, %g4
 5:     sethi   %hi(sun4v_chip_type), %g2
        or      %g2, %lo(sun4v_chip_type), %g2
        stw     %g4, [%g2]


- Allen


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
  2014-08-22  5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
                   ` (3 preceding siblings ...)
  2014-08-24  6:31 ` Allen Pais
@ 2014-08-24  6:43 ` David Miller
  2014-08-24  6:43 ` Allen Pais
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: David Miller @ 2014-08-24  6:43 UTC (permalink / raw)
  To: sparclinux

From: Allen Pais <allen.pais@oracle.com>
Date: Sun, 24 Aug 2014 11:49:29 +0530

> David,
>> 
>>> @@ -414,6 +414,8 @@ sun4v_chip_type:
>>>  	cmp	%g2, 'T'
>>>  	be,pt	%xcc, 70f
>>>  	 cmp	%g2, 'M'
>>> +	be,pt	%xcc, 71f
>>> +	 nop
>>>  	bne,pn	%xcc, 49f
>>>  	 nop
>> 
>> This code block is supposed to fallthrough when %g2 is 'M' so that
>> we accept all of "{T,M}345..." but your change is breaking that
>> such that we will now only accept "M" as a prefix for "7".
>> 
>> That's a regression.
>> 
>> All you have to do is add the new comparison against '7' in the
>> "70:" label code block, and you're done.
>> 
> 
>  When we are on this topic, here's a patch that attempts to simplify 
> cpu detection. 
> 
> Here's a quick diff.

You can't call C code until you've cleared the BSS, you can't clear
the BSS until you hook up the proper optimized routines, you can't
hook up the proper optimized routined until you know the cpu type.

I would have done this years ago otherwise.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
  2014-08-22  5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
                   ` (4 preceding siblings ...)
  2014-08-24  6:43 ` David Miller
@ 2014-08-24  6:43 ` Allen Pais
  2014-08-24 12:35 ` Bob Picco
  2014-08-24 19:06 ` David Miller
  7 siblings, 0 replies; 9+ messages in thread
From: Allen Pais @ 2014-08-24  6:43 UTC (permalink / raw)
  To: sparclinux

David,
>>  The idea was to also have M5 and M6-32 cpu types supported too with M7. 
>>
>> +71:
>> +	ldub	[%g1 + 7], %g2
>> +	cmp	%g1, '5'
>> +	be,pt	%xcc, 5f
>> +	 mov	SUN4V_CHIP_SPARC_M5, %g4
>> +	cmp	%g1, '6'
>> +	be,pt	%xcc, 5f
>> +	 mov	SUN4V_CHIP_SPARC_M6, %g4
>> +       cmp     %g2, '7'
>> +       be,pt   %xcc, 5f
>> +        mov    SUN4V_CHIP_SPARC_M7, %g4
>> +       ba,pt   %xcc, 49f
>> +        nop
>> +
> 
> Again, why are you bothing with a special code path at all?  You don't
> need to.
> 
> Just add the M7 test to the "70:" label code block, and you're done.
> 

 I was a little confused when you initially mentioned about using "70:" label
code block, now I see the point. I'll re-do the patch and test it.

- Allen

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
  2014-08-22  5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
                   ` (5 preceding siblings ...)
  2014-08-24  6:43 ` Allen Pais
@ 2014-08-24 12:35 ` Bob Picco
  2014-08-24 19:06 ` David Miller
  7 siblings, 0 replies; 9+ messages in thread
From: Bob Picco @ 2014-08-24 12:35 UTC (permalink / raw)
  To: sparclinux

Hi,
David Miller wrote:	[Sun Aug 24 2014, 02:43:11AM EDT]
> From: Allen Pais <allen.pais@oracle.com>
> Date: Sun, 24 Aug 2014 11:49:29 +0530
> 
> > David,
> >> 
> >>> @@ -414,6 +414,8 @@ sun4v_chip_type:
> >>>  	cmp	%g2, 'T'
> >>>  	be,pt	%xcc, 70f
> >>>  	 cmp	%g2, 'M'
> >>> +	be,pt	%xcc, 71f
> >>> +	 nop
> >>>  	bne,pn	%xcc, 49f
> >>>  	 nop
> >> 
> >> This code block is supposed to fallthrough when %g2 is 'M' so that
> >> we accept all of "{T,M}345..." but your change is breaking that
> >> such that we will now only accept "M" as a prefix for "7".
> >> 
> >> That's a regression.
> >> 
> >> All you have to do is add the new comparison against '7' in the
> >> "70:" label code block, and you're done.
> >> 
> > 
> >  When we are on this topic, here's a patch that attempts to simplify 
> > cpu detection. 
> > 
> > Here's a quick diff.
> 
> You can't call C code until you've cleared the BSS, you can't clear
> the BSS until you hook up the proper optimized routines, you can't
> hook up the proper optimized routined until you know the cpu type.
I'm aware of BSS and cpu initialization routines. Many issues are subtle
until paging_init finishes.

What BSS does this code touch or reference? None that I'm aware of.

The code is executing on OBP stack and the kernel has been remapped and
doesn't require PIC address manipulation any longer. Your only assumptions
should be OBP handling register window events and accessing compile time
initialized data. BSS is taboo for the reason you state.

One obviously has to be VERY careful. The "VERY" part is true of all code
here. Should there be fear of strcmp then implement it in simple "C" and name
it "boot_strcmp".

Perhaps I've missed an issue.

thanx,

bob
> 
> I would have done this years ago otherwise.
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type
  2014-08-22  5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
                   ` (6 preceding siblings ...)
  2014-08-24 12:35 ` Bob Picco
@ 2014-08-24 19:06 ` David Miller
  7 siblings, 0 replies; 9+ messages in thread
From: David Miller @ 2014-08-24 19:06 UTC (permalink / raw)
  To: sparclinux

From: Bob Picco <bpicco@meloft.net>
Date: Sun, 24 Aug 2014 08:35:06 -0400

> What BSS does this code touch or reference? None that I'm aware of.

You cannot control what code the compiler emits, it is therefore not
safe to call C code.

Please just drop this for now, thank you.

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2014-08-24 19:06 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-22  5:53 [PATCH v1 1/3] sparc64: correctly recognise M7 cpu type Allen Pais
2014-08-23 18:51 ` David Miller
2014-08-24  6:18 ` David Miller
2014-08-24  6:19 ` Allen Pais
2014-08-24  6:31 ` Allen Pais
2014-08-24  6:43 ` David Miller
2014-08-24  6:43 ` Allen Pais
2014-08-24 12:35 ` Bob Picco
2014-08-24 19:06 ` David Miller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.