All of lore.kernel.org
 help / color / mirror / Atom feed
From: jbrunet@baylibre.com (Jerome Brunet)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH] ARM64: meson-gxl: disable broken eee
Date: Mon, 24 Jul 2017 18:09:30 +0200	[thread overview]
Message-ID: <1500912570.2401.3.camel@baylibre.com> (raw)
In-Reply-To: <7519c9ee-54f0-d5fb-1683-11d6e24f0822@baylibre.com>

On Mon, 2017-07-24 at 14:26 +0200, Neil Armstrong wrote:
> On 07/24/2017 02:06 PM, Neil Armstrong wrote:
> > On 07/23/2017 07:03 PM, Joseph Kogut wrote:
> > > Hi Kevin,
> > > 
> > > I tested on a P212 reference board, which is currently the only GXL
> > > based board I have.
> > > 
> > > Before applying the patch, high activity on the ethernet interface
> > > would cause the link to break, requiring the interface to be brought
> > > down and back up before it would work again. After applying the patch,
> > > I could not get the link to break with any transfers.
> > > 
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > > 
> > 
> > Hi Joseph,
> > 
> > [please keep the history of the conversation when replying]
> > 
> > Is it a original P212 board, or a board based on the P212 ref design ?
> > 
> > I'm currently testing the v4.13-rc2 on the official P212 board we received
> > from Amlogic
> > and using iperf3 in both directions, I have an issue after a few minutes
> > running iperf3 with :
> > 
> > # while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ; done
> > 
> > That cycles between the two iperf directions.
> > 
> > After a few minutes, it stalls with :
> > 
> > Connecting to host 192.168.1.21, port 5201
> > [??4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201
> > [ ID] Interval???????????Transfer?????Bandwidth???????Retr??Cwnd
> > [??4]???0.00-1.00???sec??1.64 MBytes??13.7 Mbits/sec????2???1.41 KBytes
> > [??4]???1.00-2.00???sec??0.00 Bytes??0.00 bits/sec????1???1.41 KBytes
> > [??4]???2.00-3.00???sec??0.00 Bytes??0.00 bits/sec????0???1.41 KBytes
> > [??4]???3.00-4.00???sec??0.00 Bytes??0.00 bits/sec????1???1.41 KBytes
> > [??4]???4.00-5.00???sec??0.00 Bytes??0.00 bits/sec????0???1.41 KBytes
> > [??4]???5.00-6.00???sec??0.00 Bytes??0.00 bits/sec????0???1.41 KBytes
> > [??4]???6.00-7.00???sec??0.00 Bytes??0.00 bits/sec????1???1.41 KBytes
> > [??4]???7.00-8.00???sec??0.00 Bytes??0.00 bits/sec????0???1.41 KBytes
> > [??4]???8.00-9.00???sec??0.00 Bytes??0.00 bits/sec????0???1.41 KBytes
> > 

Same kind of test shows no issue on the libretech-cc and the khadas-vim
In this case, I don't think meson-gxl.dtsi is where you should make your change.

> > 
> > And then, after:
> > # ifconfig eth0 down
> > # ifconfig eth0 up
> > 
> > It cycles between :
> > [ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> > 100Mbps/Full - flow control rx/tx
> > [ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down
> > [ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> > 100Mbps/Full - flow control rx/tx
> > [ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down

This does not look like the issue we had on the odroid-c2.
However, I have seen behavior like this (link down/up flickering) when the rgmii
 delays are way off.

Maybe you could try playing with "amlogic,tx-delay-ns" property ?

> > 
> > and so on.
> > 
> > And this patch does not fix this at all.
> > 
> > It seems to be more a PHY driver issue here.
> > 
> > Could you share the results with the same command ?
> > 
> > Neil
> > 
> 
> I forgot to precise, this issue occurs when the "GXL PHY driver" is disabled,
> only relying on the
> Generic PHY Driver.
> 
> [??630.767538] Generic PHY 0.e40908ff:08: attached PHY driver [Generic PHY]
> (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
> 
> 
> When the PHY driver is loaded the issue disappears, with and without your
> patch.
> 
> [???25.355620] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver
> [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
> 
> Could you please check the PHY Driver is loaded ?
> 
> Thanks,
> Neil

WARNING: multiple messages have this Message-ID (diff)
From: jbrunet@baylibre.com (Jerome Brunet)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM64: meson-gxl: disable broken eee
Date: Mon, 24 Jul 2017 18:09:30 +0200	[thread overview]
Message-ID: <1500912570.2401.3.camel@baylibre.com> (raw)
In-Reply-To: <7519c9ee-54f0-d5fb-1683-11d6e24f0822@baylibre.com>

On Mon, 2017-07-24 at 14:26 +0200, Neil Armstrong wrote:
> On 07/24/2017 02:06 PM, Neil Armstrong wrote:
> > On 07/23/2017 07:03 PM, Joseph Kogut wrote:
> > > Hi Kevin,
> > > 
> > > I tested on a P212 reference board, which is currently the only GXL
> > > based board I have.
> > > 
> > > Before applying the patch, high activity on the ethernet interface
> > > would cause the link to break, requiring the interface to be brought
> > > down and back up before it would work again. After applying the patch,
> > > I could not get the link to break with any transfers.
> > > 
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel at lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > > 
> > 
> > Hi Joseph,
> > 
> > [please keep the history of the conversation when replying]
> > 
> > Is it a original P212 board, or a board based on the P212 ref design ?
> > 
> > I'm currently testing the v4.13-rc2 on the official P212 board we received
> > from Amlogic
> > and using iperf3 in both directions, I have an issue after a few minutes
> > running iperf3 with :
> > 
> > # while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ; done
> > 
> > That cycles between the two iperf directions.
> > 
> > After a few minutes, it stalls with :
> > 
> > Connecting to host 192.168.1.21, port 5201
> > [??4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201
> > [ ID] Interval???????????Transfer?????Bandwidth???????Retr??Cwnd
> > [??4]???0.00-1.00???sec??1.64 MBytes??13.7 Mbits/sec????2???1.41 KBytes
> > [??4]???1.00-2.00???sec??0.00 Bytes??0.00 bits/sec????1???1.41 KBytes
> > [??4]???2.00-3.00???sec??0.00 Bytes??0.00 bits/sec????0???1.41 KBytes
> > [??4]???3.00-4.00???sec??0.00 Bytes??0.00 bits/sec????1???1.41 KBytes
> > [??4]???4.00-5.00???sec??0.00 Bytes??0.00 bits/sec????0???1.41 KBytes
> > [??4]???5.00-6.00???sec??0.00 Bytes??0.00 bits/sec????0???1.41 KBytes
> > [??4]???6.00-7.00???sec??0.00 Bytes??0.00 bits/sec????1???1.41 KBytes
> > [??4]???7.00-8.00???sec??0.00 Bytes??0.00 bits/sec????0???1.41 KBytes
> > [??4]???8.00-9.00???sec??0.00 Bytes??0.00 bits/sec????0???1.41 KBytes
> > 

Same kind of test shows no issue on the libretech-cc and the khadas-vim
In this case, I don't think meson-gxl.dtsi is where you should make your change.

> > 
> > And then, after:
> > # ifconfig eth0 down
> > # ifconfig eth0 up
> > 
> > It cycles between :
> > [ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> > 100Mbps/Full - flow control rx/tx
> > [ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down
> > [ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> > 100Mbps/Full - flow control rx/tx
> > [ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down

This does not look like the issue we had on the odroid-c2.
However, I have seen behavior like this (link down/up flickering) when the rgmii
 delays are way off.

Maybe you could try playing with "amlogic,tx-delay-ns" property ?

> > 
> > and so on.
> > 
> > And this patch does not fix this at all.
> > 
> > It seems to be more a PHY driver issue here.
> > 
> > Could you share the results with the same command ?
> > 
> > Neil
> > 
> 
> I forgot to precise, this issue occurs when the "GXL PHY driver" is disabled,
> only relying on the
> Generic PHY Driver.
> 
> [??630.767538] Generic PHY 0.e40908ff:08: attached PHY driver [Generic PHY]
> (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
> 
> 
> When the PHY driver is loaded the issue disappears, with and without your
> patch.
> 
> [???25.355620] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver
> [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
> 
> Could you please check the PHY Driver is loaded ?
> 
> Thanks,
> Neil

WARNING: multiple messages have this Message-ID (diff)
From: Jerome Brunet <jbrunet-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
To: Neil Armstrong
	<narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	Joseph Kogut
	<joseph.kogut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org,
	linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] ARM64: meson-gxl: disable broken eee
Date: Mon, 24 Jul 2017 18:09:30 +0200	[thread overview]
Message-ID: <1500912570.2401.3.camel@baylibre.com> (raw)
In-Reply-To: <7519c9ee-54f0-d5fb-1683-11d6e24f0822-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>

On Mon, 2017-07-24 at 14:26 +0200, Neil Armstrong wrote:
> On 07/24/2017 02:06 PM, Neil Armstrong wrote:
> > On 07/23/2017 07:03 PM, Joseph Kogut wrote:
> > > Hi Kevin,
> > > 
> > > I tested on a P212 reference board, which is currently the only GXL
> > > based board I have.
> > > 
> > > Before applying the patch, high activity on the ethernet interface
> > > would cause the link to break, requiring the interface to be brought
> > > down and back up before it would work again. After applying the patch,
> > > I could not get the link to break with any transfers.
> > > 
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > > 
> > 
> > Hi Joseph,
> > 
> > [please keep the history of the conversation when replying]
> > 
> > Is it a original P212 board, or a board based on the P212 ref design ?
> > 
> > I'm currently testing the v4.13-rc2 on the official P212 board we received
> > from Amlogic
> > and using iperf3 in both directions, I have an issue after a few minutes
> > running iperf3 with :
> > 
> > # while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ; done
> > 
> > That cycles between the two iperf directions.
> > 
> > After a few minutes, it stalls with :
> > 
> > Connecting to host 192.168.1.21, port 5201
> > [  4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201
> > [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
> > [  4]   0.00-1.00   sec  1.64 MBytes  13.7 Mbits/sec    2   1.41 KBytes
> > [  4]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
> > [  4]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > [  4]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
> > [  4]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > [  4]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > [  4]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
> > [  4]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > [  4]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > 

Same kind of test shows no issue on the libretech-cc and the khadas-vim
In this case, I don't think meson-gxl.dtsi is where you should make your change.

> > 
> > And then, after:
> > # ifconfig eth0 down
> > # ifconfig eth0 up
> > 
> > It cycles between :
> > [ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> > 100Mbps/Full - flow control rx/tx
> > [ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down
> > [ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> > 100Mbps/Full - flow control rx/tx
> > [ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down

This does not look like the issue we had on the odroid-c2.
However, I have seen behavior like this (link down/up flickering) when the rgmii
 delays are way off.

Maybe you could try playing with "amlogic,tx-delay-ns" property ?

> > 
> > and so on.
> > 
> > And this patch does not fix this at all.
> > 
> > It seems to be more a PHY driver issue here.
> > 
> > Could you share the results with the same command ?
> > 
> > Neil
> > 
> 
> I forgot to precise, this issue occurs when the "GXL PHY driver" is disabled,
> only relying on the
> Generic PHY Driver.
> 
> [  630.767538] Generic PHY 0.e40908ff:08: attached PHY driver [Generic PHY]
> (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
> 
> 
> When the PHY driver is loaded the issue disappears, with and without your
> patch.
> 
> [   25.355620] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver
> [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
> 
> Could you please check the PHY Driver is loaded ?
> 
> Thanks,
> Neil

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Jerome Brunet <jbrunet@baylibre.com>
To: Neil Armstrong <narmstrong@baylibre.com>,
	Joseph Kogut <joseph.kogut@gmail.com>,
	Kevin Hilman <khilman@baylibre.com>
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	robh+dt@kernel.org, carlo@caione.org,
	linux-amlogic@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM64: meson-gxl: disable broken eee
Date: Mon, 24 Jul 2017 18:09:30 +0200	[thread overview]
Message-ID: <1500912570.2401.3.camel@baylibre.com> (raw)
In-Reply-To: <7519c9ee-54f0-d5fb-1683-11d6e24f0822@baylibre.com>

On Mon, 2017-07-24 at 14:26 +0200, Neil Armstrong wrote:
> On 07/24/2017 02:06 PM, Neil Armstrong wrote:
> > On 07/23/2017 07:03 PM, Joseph Kogut wrote:
> > > Hi Kevin,
> > > 
> > > I tested on a P212 reference board, which is currently the only GXL
> > > based board I have.
> > > 
> > > Before applying the patch, high activity on the ethernet interface
> > > would cause the link to break, requiring the interface to be brought
> > > down and back up before it would work again. After applying the patch,
> > > I could not get the link to break with any transfers.
> > > 
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > > 
> > 
> > Hi Joseph,
> > 
> > [please keep the history of the conversation when replying]
> > 
> > Is it a original P212 board, or a board based on the P212 ref design ?
> > 
> > I'm currently testing the v4.13-rc2 on the official P212 board we received
> > from Amlogic
> > and using iperf3 in both directions, I have an issue after a few minutes
> > running iperf3 with :
> > 
> > # while true ; do iperf3 -c 192.168.1.21 ; iperf3 -c 192.168.1.21 -R ; done
> > 
> > That cycles between the two iperf directions.
> > 
> > After a few minutes, it stalls with :
> > 
> > Connecting to host 192.168.1.21, port 5201
> > [  4] local 192.168.1.183 port 51286 connected to 192.168.1.21 port 5201
> > [ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
> > [  4]   0.00-1.00   sec  1.64 MBytes  13.7 Mbits/sec    2   1.41 KBytes
> > [  4]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
> > [  4]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > [  4]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
> > [  4]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > [  4]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > [  4]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes
> > [  4]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > [  4]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes
> > 

Same kind of test shows no issue on the libretech-cc and the khadas-vim
In this case, I don't think meson-gxl.dtsi is where you should make your change.

> > 
> > And then, after:
> > # ifconfig eth0 down
> > # ifconfig eth0 up
> > 
> > It cycles between :
> > [ 1483.009919] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> > 100Mbps/Full - flow control rx/tx
> > [ 1487.105725] meson8b-dwmac c9410000.ethernet eth0: Link is Down
> > [ 1490.177943] meson8b-dwmac c9410000.ethernet eth0: Link is Up -
> > 100Mbps/Full - flow control rx/tx
> > [ 1494.273713] meson8b-dwmac c9410000.ethernet eth0: Link is Down

This does not look like the issue we had on the odroid-c2.
However, I have seen behavior like this (link down/up flickering) when the rgmii
 delays are way off.

Maybe you could try playing with "amlogic,tx-delay-ns" property ?

> > 
> > and so on.
> > 
> > And this patch does not fix this at all.
> > 
> > It seems to be more a PHY driver issue here.
> > 
> > Could you share the results with the same command ?
> > 
> > Neil
> > 
> 
> I forgot to precise, this issue occurs when the "GXL PHY driver" is disabled,
> only relying on the
> Generic PHY Driver.
> 
> [  630.767538] Generic PHY 0.e40908ff:08: attached PHY driver [Generic PHY]
> (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
> 
> 
> When the PHY driver is loaded the issue disappears, with and without your
> patch.
> 
> [   25.355620] Meson GXL Internal PHY 0.e40908ff:08: attached PHY driver
> [Meson GXL Internal PHY] (mii_bus:phy_addr=0.e40908ff:08, irq=-1)
> 
> Could you please check the PHY Driver is loaded ?
> 
> Thanks,
> Neil

  reply	other threads:[~2017-07-24 16:09 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-07  1:32 [PATCH] ARM64: meson-gxl: disable broken eee Joseph Kogut
2017-07-07  1:32 ` Joseph Kogut
2017-07-07  1:32 ` Joseph Kogut
2017-07-22 15:26 ` Kevin Hilman
2017-07-22 15:26   ` Kevin Hilman
2017-07-22 15:26   ` Kevin Hilman
2017-07-22 15:26   ` Kevin Hilman
2017-07-23 17:03   ` Joseph Kogut
2017-07-23 17:03     ` Joseph Kogut
2017-07-23 17:03     ` Joseph Kogut
2017-07-23 17:03     ` Joseph Kogut
2017-07-24 12:06     ` Neil Armstrong
2017-07-24 12:06       ` Neil Armstrong
2017-07-24 12:06       ` Neil Armstrong
2017-07-24 12:06       ` Neil Armstrong
2017-07-24 12:26       ` Neil Armstrong
2017-07-24 12:26         ` Neil Armstrong
2017-07-24 12:26         ` Neil Armstrong
2017-07-24 12:26         ` Neil Armstrong
2017-07-24 16:09         ` Jerome Brunet [this message]
2017-07-24 16:09           ` Jerome Brunet
2017-07-24 16:09           ` Jerome Brunet
2017-07-24 16:09           ` Jerome Brunet
2017-07-24 18:20           ` Martin Blumenstingl
2017-07-24 18:20             ` Martin Blumenstingl
2017-07-24 18:20             ` Martin Blumenstingl
2017-07-24 18:32             ` Jerome Brunet
2017-07-24 18:32               ` Jerome Brunet
2017-07-24 18:32               ` Jerome Brunet
2017-07-24 18:32               ` Jerome Brunet
2017-07-25 17:03               ` crow
2017-07-25 17:03                 ` crow
2017-07-25 17:03                 ` crow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1500912570.2401.3.camel@baylibre.com \
    --to=jbrunet@baylibre.com \
    --cc=linus-amlogic@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.