* [Regression, post-2.6.35] ath9k occasionally drops out of PCI config space
@ 2010-11-05 20:50 Rafael J. Wysocki
2010-11-05 21:19 ` Luis R. Rodriguez
0 siblings, 1 reply; 5+ messages in thread
From: Rafael J. Wysocki @ 2010-11-05 20:50 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Felix Fietkau, John W. Linville, linux-wireless, LKML, linux-pci
Hi,
For some time I've been experiencing a regression associated with ath9k
that occasionally it drops the connection with the AP and goes into a state
in which reading from its PCI config registers (as done by lspci) return all
ones.
It may be sort of brought back to life by a suspend/resume afterwards, but
then the driver cannot really handle it and realoding the driver doesn't help
(probe fails). Basically, full machine reboot is needed to revive the adapter.
The device is:
09:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)
Subsystem: Foxconn International, Inc. Device e01f
and the kernel says:
[ 9.623217] ath9k 0000:09:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 9.631518] ath9k 0000:09:00.0: setting latency timer to 64
[ 10.071497] ath: EEPROM regdomain: 0x65
[ 10.071502] ath: EEPROM indicates we should expect a direct regpair map
[ 10.071510] ath: Country alpha2 being used: 00
[ 10.071514] ath: Regpair used: 0x65
[ 10.096025] phy0: Selected rate control algorithm 'ath9k_rate_control'
[ 10.097803] Registered led device: ath9k-phy0::radio
[ 10.098035] Registered led device: ath9k-phy0::assoc
[ 10.098249] Registered led device: ath9k-phy0::tx
[ 10.098483] Registered led device: ath9k-phy0::rx
[ 10.098496] phy0: Atheros AR9280 Rev:2 mem=0xffffc900017e0000, irq=19
The issue is not really bisectable, because I'm unable to trigger it on demand
and it occurs approx. 1-2 times a day. So, if you have any ideas what to test,
please let me know.
It is not reproducible with the 2.6.35 kernel.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [Regression, post-2.6.35] ath9k occasionally drops out of PCI config space 2010-11-05 20:50 [Regression, post-2.6.35] ath9k occasionally drops out of PCI config space Rafael J. Wysocki @ 2010-11-05 21:19 ` Luis R. Rodriguez 2010-11-08 20:47 ` Rafael J. Wysocki 0 siblings, 1 reply; 5+ messages in thread From: Luis R. Rodriguez @ 2010-11-05 21:19 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Luis Rodriguez, Felix Fietkau, John W. Linville, linux-wireless@vger.kernel.org, LKML, linux-pci@vger.kernel.org On Fri, Nov 05, 2010 at 01:50:02PM -0700, Rafael J. Wysocki wrote: > Hi, > > For some time I've been experiencing a regression associated with ath9k > that occasionally it drops the connection with the AP and goes into a state > in which reading from its PCI config registers (as done by lspci) return all > ones. > > It may be sort of brought back to life by a suspend/resume afterwards, but > then the driver cannot really handle it and realoding the driver doesn't help > (probe fails). Basically, full machine reboot is needed to revive the adapter. > > The device is: > > 09:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01) > Subsystem: Foxconn International, Inc. Device e01f > > and the kernel says: > > [ 9.623217] ath9k 0000:09:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 > [ 9.631518] ath9k 0000:09:00.0: setting latency timer to 64 > [ 10.071497] ath: EEPROM regdomain: 0x65 > [ 10.071502] ath: EEPROM indicates we should expect a direct regpair map > [ 10.071510] ath: Country alpha2 being used: 00 > [ 10.071514] ath: Regpair used: 0x65 > [ 10.096025] phy0: Selected rate control algorithm 'ath9k_rate_control' > [ 10.097803] Registered led device: ath9k-phy0::radio > [ 10.098035] Registered led device: ath9k-phy0::assoc > [ 10.098249] Registered led device: ath9k-phy0::tx > [ 10.098483] Registered led device: ath9k-phy0::rx > [ 10.098496] phy0: Atheros AR9280 Rev:2 mem=0xffffc900017e0000, irq=19 > > The issue is not really bisectable, because I'm unable to trigger it on demand > and it occurs approx. 1-2 times a day. So, if you have any ideas what to test, > please let me know. > > It is not reproducible with the 2.6.35 kernel. Please try this patch. From: Vasanthakumar Thiagarajan <vasanth@atheros.com> Date: Tue, 2 Nov 2010 23:57:34 -0700 Subject: [PATCH] ath9k_hw: Fix AR9280 surprise removal during frequent idle on/off Bit 22 of AR_WA should be set to fix the situation where chip reset is asynchronous to clock of analog shift registers, such that when reset is released, it could mess up the values of analog shift registers and cause some hw issue on AR9280. This bit is write only, but the driver does a read-modify-write on AR_WA without setting bit 22 in ar9002_hw_configpcipowersave() during radio disable. This causes surprise removal of hw. It can never recover from this state and the hw will become usable only after a power on/off cycle, and sometimes only during a cold reboot. This issue can be triggered by doing frequent roaming with the simple/test-roam script available from the wifi-test project [1] when roaming between APs quickly. When roaming there is a is a high possibility that the device being put into idle (radio disable) state by mac80211 during AUTH->ASSOC. A device hardware reset would fail and the kernel would output: [40251.363799] ath: AWAKE -> FULL-SLEEP [40251.363815] ieee80211 phy17: device no longer idle - working [40251.363817] ath: Marking phy17 as not-idle [40251.363819] ath: FULL-SLEEP -> AWAKE [40251.415978] pciehp 0000:00:1c.3:pcie04: Card not present on Slot(3) [40251.419896] ath: ah->misc_mode 0x4 [40251.428138] pciehp 0000:00:1c.3:pcie04: Card present on Slot(3) [40251.532247] ath: timeout (100000 us) on reg 0x9860: 0xffffffff & 0x00000001 != 0x00000000 [40251.532250] ath: Unable to reset channel (2462 MHz), reset status -5 [40251.532422] ath: Set channel: 5745 MHz [40251.540639] ath: Failed to stop TX DMA in 100 msec after killing last frame [40251.548826] ath: Failed to stop TX DMA in 100 msec after killing last frame [40251.557023] ath: Failed to stop TX DMA in 100 msec after killing last frame [40251.565211] ath: Failed to stop TX DMA in 100 msec after killing last frame [40251.573415] ath: Failed to stop TX DMA in 100 msec after killing last frame [40251.581603] ath: Failed to stop TX DMA in 100 msec after killing last frame [40251.581606] ath: Failed to stop TX DMA. Resetting hardware! [40251.592679] ath: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff [40251.703330] ath: timeout (100000 us) on reg 0x7000: 0xffffffff & 0x00000003 != 0x00000000 [40251.703333] ath: RTC stuck in MAC reset [40251.703334] ath: Chip reset failed [40251.703335] ath: Unable to reset hardware; reset status -22 This is currently only reproducible with some HB92 (Half Mini-PCIE) cards but the fix applies to all AR9280 cards. This patch fixes this issue by setting bit 22 during radio disable. [1] http://wireless.kernel.org/en/developers/Testing/wifi-test Cc: Amod.bodas@atheros.com Cc: David.Quan@atheros.com Cc: Kyungwan.Nam@atheros.com Cc: stable@kernel.org Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> --- drivers/net/wireless/ath/ath9k/ar9002_hw.c | 3 +++ drivers/net/wireless/ath/ath9k/reg.h | 1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/ar9002_hw.c b/drivers/net/wireless/ath/ath9k/ar9002_hw.c index a0471f2..48261b7 100644 --- a/drivers/net/wireless/ath/ath9k/ar9002_hw.c +++ b/drivers/net/wireless/ath/ath9k/ar9002_hw.c @@ -410,6 +410,9 @@ static void ar9002_hw_configpcipowersave(struct ath_hw *ah, val &= ~(AR_WA_BIT6 | AR_WA_BIT7); } + if (AR_SREV_9280(ah)) + val |= AR_WA_BIT22; + if (AR_SREV_9285E_20(ah)) val |= AR_WA_BIT23; diff --git a/drivers/net/wireless/ath/ath9k/reg.h b/drivers/net/wireless/ath/ath9k/reg.h index 42976b0..fa05b71 100644 --- a/drivers/net/wireless/ath/ath9k/reg.h +++ b/drivers/net/wireless/ath/ath9k/reg.h @@ -703,6 +703,7 @@ #define AR_WA_RESET_EN (1 << 18) /* Sw Control to enable PCI-Reset to POR (bit 15) */ #define AR_WA_ANALOG_SHIFT (1 << 20) #define AR_WA_POR_SHORT (1 << 21) /* PCI-E Phy reset control */ +#define AR_WA_BIT22 (1 << 22) #define AR9285_WA_DEFAULT 0x004a050b #define AR9280_WA_DEFAULT 0x0040073b #define AR_WA_DEFAULT 0x0000073f -- 1.7.3.2.90.gd4c43 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [Regression, post-2.6.35] ath9k occasionally drops out of PCI config space 2010-11-05 21:19 ` Luis R. Rodriguez @ 2010-11-08 20:47 ` Rafael J. Wysocki 2010-11-08 21:06 ` Luis R. Rodriguez 0 siblings, 1 reply; 5+ messages in thread From: Rafael J. Wysocki @ 2010-11-08 20:47 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Luis Rodriguez, Felix Fietkau, John W. Linville, linux-wireless@vger.kernel.org, LKML, linux-pci@vger.kernel.org On Friday, November 05, 2010, Luis R. Rodriguez wrote: > On Fri, Nov 05, 2010 at 01:50:02PM -0700, Rafael J. Wysocki wrote: > > Hi, > > > > For some time I've been experiencing a regression associated with ath9k > > that occasionally it drops the connection with the AP and goes into a state > > in which reading from its PCI config registers (as done by lspci) return all > > ones. > > > > It may be sort of brought back to life by a suspend/resume afterwards, but > > then the driver cannot really handle it and realoding the driver doesn't help > > (probe fails). Basically, full machine reboot is needed to revive the adapter. > > > > The device is: > > > > 09:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01) > > Subsystem: Foxconn International, Inc. Device e01f > > > > and the kernel says: > > > > [ 9.623217] ath9k 0000:09:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 > > [ 9.631518] ath9k 0000:09:00.0: setting latency timer to 64 > > [ 10.071497] ath: EEPROM regdomain: 0x65 > > [ 10.071502] ath: EEPROM indicates we should expect a direct regpair map > > [ 10.071510] ath: Country alpha2 being used: 00 > > [ 10.071514] ath: Regpair used: 0x65 > > [ 10.096025] phy0: Selected rate control algorithm 'ath9k_rate_control' > > [ 10.097803] Registered led device: ath9k-phy0::radio > > [ 10.098035] Registered led device: ath9k-phy0::assoc > > [ 10.098249] Registered led device: ath9k-phy0::tx > > [ 10.098483] Registered led device: ath9k-phy0::rx > > [ 10.098496] phy0: Atheros AR9280 Rev:2 mem=0xffffc900017e0000, irq=19 > > > > The issue is not really bisectable, because I'm unable to trigger it on demand > > and it occurs approx. 1-2 times a day. So, if you have any ideas what to test, > > please let me know. > > > > It is not reproducible with the 2.6.35 kernel. > > Please try this patch. It _appears_ to help. At least I haven't been able to reproduce the problem since I applied it, which was on Saturday early in the morning. Still, I also haven't used wireless a lot since that time, because I've been traveling mostly. Thanks, Rafael > From: Vasanthakumar Thiagarajan <vasanth@atheros.com> > Date: Tue, 2 Nov 2010 23:57:34 -0700 > Subject: [PATCH] ath9k_hw: Fix AR9280 surprise removal during frequent idle on/off > > Bit 22 of AR_WA should be set to fix the situation where chip reset > is asynchronous to clock of analog shift registers, such that when > reset is released, it could mess up the values of analog shift registers > and cause some hw issue on AR9280. > > This bit is write only, but the driver does a read-modify-write > on AR_WA without setting bit 22 in ar9002_hw_configpcipowersave() > during radio disable. This causes surprise removal of hw. It can > never recover from this state and the hw will become usable only > after a power on/off cycle, and sometimes only during a cold reboot. > > This issue can be triggered by doing frequent roaming with the > simple/test-roam script available from the wifi-test project [1] > when roaming between APs quickly. When roaming there is a is a high > possibility that the device being put into idle (radio disable) state > by mac80211 during AUTH->ASSOC. A device hardware reset would fail > and the kernel would output: > > [40251.363799] ath: AWAKE -> FULL-SLEEP > [40251.363815] ieee80211 phy17: device no longer idle - working > [40251.363817] ath: Marking phy17 as not-idle > [40251.363819] ath: FULL-SLEEP -> AWAKE > [40251.415978] pciehp 0000:00:1c.3:pcie04: Card not present on Slot(3) > [40251.419896] ath: ah->misc_mode 0x4 > [40251.428138] pciehp 0000:00:1c.3:pcie04: Card present on Slot(3) > [40251.532247] ath: timeout (100000 us) on reg 0x9860: 0xffffffff & 0x00000001 != 0x00000000 > [40251.532250] ath: Unable to reset channel (2462 MHz), reset status -5 > [40251.532422] ath: Set channel: 5745 MHz > [40251.540639] ath: Failed to stop TX DMA in 100 msec after killing last frame > [40251.548826] ath: Failed to stop TX DMA in 100 msec after killing last frame > [40251.557023] ath: Failed to stop TX DMA in 100 msec after killing last frame > [40251.565211] ath: Failed to stop TX DMA in 100 msec after killing last frame > [40251.573415] ath: Failed to stop TX DMA in 100 msec after killing last frame > [40251.581603] ath: Failed to stop TX DMA in 100 msec after killing last frame > [40251.581606] ath: Failed to stop TX DMA. Resetting hardware! > [40251.592679] ath: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff > [40251.703330] ath: timeout (100000 us) on reg 0x7000: 0xffffffff & 0x00000003 != 0x00000000 > [40251.703333] ath: RTC stuck in MAC reset > [40251.703334] ath: Chip reset failed > [40251.703335] ath: Unable to reset hardware; reset status -22 > > This is currently only reproducible with some HB92 (Half Mini-PCIE) > cards but the fix applies to all AR9280 cards. This patch fixes this > issue by setting bit 22 during radio disable. > > [1] http://wireless.kernel.org/en/developers/Testing/wifi-test > > Cc: Amod.bodas@atheros.com > Cc: David.Quan@atheros.com > Cc: Kyungwan.Nam@atheros.com > Cc: stable@kernel.org > Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> > --- > drivers/net/wireless/ath/ath9k/ar9002_hw.c | 3 +++ > drivers/net/wireless/ath/ath9k/reg.h | 1 + > 2 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/drivers/net/wireless/ath/ath9k/ar9002_hw.c b/drivers/net/wireless/ath/ath9k/ar9002_hw.c > index a0471f2..48261b7 100644 > --- a/drivers/net/wireless/ath/ath9k/ar9002_hw.c > +++ b/drivers/net/wireless/ath/ath9k/ar9002_hw.c > @@ -410,6 +410,9 @@ static void ar9002_hw_configpcipowersave(struct ath_hw *ah, > val &= ~(AR_WA_BIT6 | AR_WA_BIT7); > } > > + if (AR_SREV_9280(ah)) > + val |= AR_WA_BIT22; > + > if (AR_SREV_9285E_20(ah)) > val |= AR_WA_BIT23; > > diff --git a/drivers/net/wireless/ath/ath9k/reg.h b/drivers/net/wireless/ath/ath9k/reg.h > index 42976b0..fa05b71 100644 > --- a/drivers/net/wireless/ath/ath9k/reg.h > +++ b/drivers/net/wireless/ath/ath9k/reg.h > @@ -703,6 +703,7 @@ > #define AR_WA_RESET_EN (1 << 18) /* Sw Control to enable PCI-Reset to POR (bit 15) */ > #define AR_WA_ANALOG_SHIFT (1 << 20) > #define AR_WA_POR_SHORT (1 << 21) /* PCI-E Phy reset control */ > +#define AR_WA_BIT22 (1 << 22) > #define AR9285_WA_DEFAULT 0x004a050b > #define AR9280_WA_DEFAULT 0x0040073b > #define AR_WA_DEFAULT 0x0000073f > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Regression, post-2.6.35] ath9k occasionally drops out of PCI config space 2010-11-08 20:47 ` Rafael J. Wysocki @ 2010-11-08 21:06 ` Luis R. Rodriguez 2010-11-09 19:26 ` Rafael J. Wysocki 0 siblings, 1 reply; 5+ messages in thread From: Luis R. Rodriguez @ 2010-11-08 21:06 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Luis Rodriguez, Felix Fietkau, John W. Linville, linux-wireless@vger.kernel.org, LKML, linux-pci@vger.kernel.org On Mon, Nov 8, 2010 at 12:47 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Friday, November 05, 2010, Luis R. Rodriguez wrote: >> On Fri, Nov 05, 2010 at 01:50:02PM -0700, Rafael J. Wysocki wrote: >> > Hi, >> > >> > For some time I've been experiencing a regression associated with ath9k >> > that occasionally it drops the connection with the AP and goes into a state >> > in which reading from its PCI config registers (as done by lspci) return all >> > ones. >> > >> > It may be sort of brought back to life by a suspend/resume afterwards, but >> > then the driver cannot really handle it and realoding the driver doesn't help >> > (probe fails). Basically, full machine reboot is needed to revive the adapter. >> > >> > The device is: >> > >> > 09:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01) >> > Subsystem: Foxconn International, Inc. Device e01f >> > >> > and the kernel says: >> > >> > [ 9.623217] ath9k 0000:09:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 >> > [ 9.631518] ath9k 0000:09:00.0: setting latency timer to 64 >> > [ 10.071497] ath: EEPROM regdomain: 0x65 >> > [ 10.071502] ath: EEPROM indicates we should expect a direct regpair map >> > [ 10.071510] ath: Country alpha2 being used: 00 >> > [ 10.071514] ath: Regpair used: 0x65 >> > [ 10.096025] phy0: Selected rate control algorithm 'ath9k_rate_control' >> > [ 10.097803] Registered led device: ath9k-phy0::radio >> > [ 10.098035] Registered led device: ath9k-phy0::assoc >> > [ 10.098249] Registered led device: ath9k-phy0::tx >> > [ 10.098483] Registered led device: ath9k-phy0::rx >> > [ 10.098496] phy0: Atheros AR9280 Rev:2 mem=0xffffc900017e0000, irq=19 >> > >> > The issue is not really bisectable, because I'm unable to trigger it on demand >> > and it occurs approx. 1-2 times a day. So, if you have any ideas what to test, >> > please let me know. >> > >> > It is not reproducible with the 2.6.35 kernel. >> >> Please try this patch. > > It _appears_ to help. At least I haven't been able to reproduce the problem > since I applied it, which was on Saturday early in the morning. > > Still, I also haven't used wireless a lot since that time, because I've been > traveling mostly. Thanks, please let us know when you are satisfied with this as a fix. Its going upstream so either way if you find you hit the issue just let us know. Luis ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Regression, post-2.6.35] ath9k occasionally drops out of PCI config space 2010-11-08 21:06 ` Luis R. Rodriguez @ 2010-11-09 19:26 ` Rafael J. Wysocki 0 siblings, 0 replies; 5+ messages in thread From: Rafael J. Wysocki @ 2010-11-09 19:26 UTC (permalink / raw) To: Luis R. Rodriguez Cc: Luis Rodriguez, Felix Fietkau, John W. Linville, linux-wireless@vger.kernel.org, LKML, linux-pci@vger.kernel.org On Monday, November 08, 2010, Luis R. Rodriguez wrote: > On Mon, Nov 8, 2010 at 12:47 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > On Friday, November 05, 2010, Luis R. Rodriguez wrote: > >> On Fri, Nov 05, 2010 at 01:50:02PM -0700, Rafael J. Wysocki wrote: > >> > Hi, > >> > > >> > For some time I've been experiencing a regression associated with ath9k > >> > that occasionally it drops the connection with the AP and goes into a state > >> > in which reading from its PCI config registers (as done by lspci) return all > >> > ones. > >> > > >> > It may be sort of brought back to life by a suspend/resume afterwards, but > >> > then the driver cannot really handle it and realoding the driver doesn't help > >> > (probe fails). Basically, full machine reboot is needed to revive the adapter. > >> > > >> > The device is: > >> > > >> > 09:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01) > >> > Subsystem: Foxconn International, Inc. Device e01f > >> > > >> > and the kernel says: > >> > > >> > [ 9.623217] ath9k 0000:09:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19 > >> > [ 9.631518] ath9k 0000:09:00.0: setting latency timer to 64 > >> > [ 10.071497] ath: EEPROM regdomain: 0x65 > >> > [ 10.071502] ath: EEPROM indicates we should expect a direct regpair map > >> > [ 10.071510] ath: Country alpha2 being used: 00 > >> > [ 10.071514] ath: Regpair used: 0x65 > >> > [ 10.096025] phy0: Selected rate control algorithm 'ath9k_rate_control' > >> > [ 10.097803] Registered led device: ath9k-phy0::radio > >> > [ 10.098035] Registered led device: ath9k-phy0::assoc > >> > [ 10.098249] Registered led device: ath9k-phy0::tx > >> > [ 10.098483] Registered led device: ath9k-phy0::rx > >> > [ 10.098496] phy0: Atheros AR9280 Rev:2 mem=0xffffc900017e0000, irq=19 > >> > > >> > The issue is not really bisectable, because I'm unable to trigger it on demand > >> > and it occurs approx. 1-2 times a day. So, if you have any ideas what to test, > >> > please let me know. > >> > > >> > It is not reproducible with the 2.6.35 kernel. > >> > >> Please try this patch. > > > > It _appears_ to help. At least I haven't been able to reproduce the problem > > since I applied it, which was on Saturday early in the morning. > > > > Still, I also haven't used wireless a lot since that time, because I've been > > traveling mostly. > > Thanks, please let us know when you are satisfied with this as a fix. OK, I'm now quite confident that it really helps. > Its going upstream so either way if you find you hit the issue just > let us know. Great, thanks, I will. Rafael ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-11-09 19:27 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-11-05 20:50 [Regression, post-2.6.35] ath9k occasionally drops out of PCI config space Rafael J. Wysocki 2010-11-05 21:19 ` Luis R. Rodriguez 2010-11-08 20:47 ` Rafael J. Wysocki 2010-11-08 21:06 ` Luis R. Rodriguez 2010-11-09 19:26 ` Rafael J. Wysocki
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).