* [ath9k-devel] ath9k buggy in 2.6.31-rc7 @ 2009-08-22 21:24 Thomas Backlund 2009-11-10 19:26 ` Kemble Wagner 2009-11-10 19:57 ` Luis R. Rodriguez 0 siblings, 2 replies; 5+ messages in thread From: Thomas Backlund @ 2009-08-22 21:24 UTC (permalink / raw) To: ath9k-devel Hi, I'm tracking a bug in ath9k in 2.6.31-rc7 series, and have been cherrypicking patches from wireless-testing to try to get a stable ath9k... The problem is that if the user configures the interface it works, but have a weak signal and tends to drop the connection. If he reboots, the signal is even weaker, and also drops the connection faster. He has to reconfigure the interface to get it back up. So here is what I have applied: net-wireless-ath9k-downgrade-ASSERT-in-ath_clone_txbuf.patch net-wireless-ath9k-Manipulate-and-report-the-correct-RSSI.patch net-wireless-ath9k-RX-stucks-during-heavy-traffic-in-HT40-mode.patch net-wireless-ath9k-Handle-tx-desc-shortage-more-appropriately.patch net-wireless-ath9k-Trivial-fix-in-Kconfig.patch net-wireless-ath9k-Update-beacon-RSSI.patch net-wireless-ath9k-Fix-bug-in-PCI-resume.patch net-wireless-ath9k-Set-HW-state-properly.patch net-wireless-ath9k-Fix-bug-in-retrieving-average-beacon-rssi.patch Now with theese patches the signal strength is correct, and the connection survives the reboot, but does disconnect when transfer load increases. The good part of the above patches is that only a simple network restart is needed to get the connection back... (In some cases the connection resets itself and starts working again) The fix for the connection dropping is to apply the patch: net-wireless-ath9k-Fix-TX-hang-issue-with-Atheros-chipsets.patch with this patch applied the link is stable, and keeps working no matter how much data is pushed through it ... But the patch has bad side-effects.... The transfers are slower, and loading webpages in firefox takes longer... It also makes cpu usage higher... So... What am I missing to get this stable for 2.6.31 ? (going full wireless-testing is not an option, as this intended for main distribution kernel.) And to help debug the connection dropping issue, attached is a kernel 2.6.31-rc7 log with "debug=0xffffffff" (and without the last patch) seems that AR_INTR_SYNC_LOCAL_TIMEOUT happends just before the link dies... I seem to recall a fix for that, but cant find it now... -- Thomas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ath9k.messages.bug Url: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20090823/9893fe48/attachment.txt ^ permalink raw reply [flat|nested] 5+ messages in thread
* [ath9k-devel] ath9k buggy in 2.6.31-rc7 2009-08-22 21:24 [ath9k-devel] ath9k buggy in 2.6.31-rc7 Thomas Backlund @ 2009-11-10 19:26 ` Kemble Wagner 2009-11-12 8:10 ` Thomas Backlund 2009-11-10 19:57 ` Luis R. Rodriguez 1 sibling, 1 reply; 5+ messages in thread From: Kemble Wagner @ 2009-11-10 19:26 UTC (permalink / raw) To: ath9k-devel could you please send me an attachment of the net-wireless-ath9k-Fix-TX-hang-issue-with-Atheros-chipsets.patch patch file i want to try testing it On Sun, Aug 23, 2009 at 8:24 AM, Thomas Backlund <tmb@mandriva.org> wrote: > Hi, > > I'm tracking a bug in ath9k in 2.6.31-rc7 series, and have been > cherrypicking patches from wireless-testing to try to get a stable ath9k... > > The problem is that if the user configures the interface it works, but have > a weak signal and tends to drop the connection. > > If he reboots, the signal is even weaker, and also drops the connection > faster. He has to reconfigure the interface to get it back up. > > So here is what I have applied: > > net-wireless-ath9k-downgrade-ASSERT-in-ath_clone_txbuf.patch > net-wireless-ath9k-Manipulate-and-report-the-correct-RSSI.patch > net-wireless-ath9k-RX-stucks-during-heavy-traffic-in-HT40-mode.patch > net-wireless-ath9k-Handle-tx-desc-shortage-more-appropriately.patch > net-wireless-ath9k-Trivial-fix-in-Kconfig.patch > net-wireless-ath9k-Update-beacon-RSSI.patch > net-wireless-ath9k-Fix-bug-in-PCI-resume.patch > net-wireless-ath9k-Set-HW-state-properly.patch > net-wireless-ath9k-Fix-bug-in-retrieving-average-beacon-rssi.patch > > > Now with theese patches the signal strength is correct, and the connection > survives the reboot, but does disconnect when transfer > load increases. > > The good part of the above patches is that only a simple network restart > is needed to get the connection back... > (In some cases the connection resets itself and starts working again) > > The fix for the connection dropping is to apply the patch: > > net-wireless-ath9k-Fix-TX-hang-issue-with-Atheros-chipsets.patch > > with this patch applied the link is stable, and keeps working no > matter how much data is pushed through it ... > > But the patch has bad side-effects.... > The transfers are slower, and loading webpages in firefox takes longer... > It also makes cpu usage higher... > > So... What am I missing to get this stable for 2.6.31 ? > (going full wireless-testing is not an option, as this intended for > main distribution kernel.) > > And to help debug the connection dropping issue, attached is a kernel > 2.6.31-rc7 log with "debug=0xffffffff" (and without the last patch) > > seems that AR_INTR_SYNC_LOCAL_TIMEOUT happends just before the link > dies... > > I seem to recall a fix for that, but cant find it now... > > -- > Thomas > > Aug 22 22:00:48 localhost klogd: cfg80211: Calling CRDA to update world > regulatory domain > Aug 22 22:00:48 localhost klogd: cfg80211: World regulatory domain updated: > Aug 22 22:00:48 localhost klogd: ^I(start_freq - end_freq @ bandwidth), > (max_antenna_gain, max_eirp) > Aug 22 22:00:48 localhost klogd: ^I(2402000 KHz - 2472000 KHz @ 40000 KHz), > (300 mBi, 2000 mBm) > Aug 22 22:00:48 localhost klogd: ^I(2457000 KHz - 2482000 KHz @ 20000 KHz), > (300 mBi, 2000 mBm) > Aug 22 22:00:48 localhost klogd: ^I(2474000 KHz - 2494000 KHz @ 20000 KHz), > (300 mBi, 2000 mBm) > Aug 22 22:00:48 localhost klogd: ^I(5170000 KHz - 5250000 KHz @ 40000 KHz), > (300 mBi, 2000 mBm) > Aug 22 22:00:48 localhost klogd: ^I(5735000 KHz - 5835000 KHz @ 40000 KHz), > (300 mBi, 2000 mBm) > Aug 22 22:00:48 localhost klogd: ath9k 0000:03:00.0: PCI INT A -> GSI 17 > (level, low) -> IRQ 17 > Aug 22 22:00:49 localhost klogd: Registered led device: ath9k-phy0::radio > Aug 22 22:00:49 localhost klogd: Registered led device: ath9k-phy0::assoc > Aug 22 22:00:49 localhost klogd: Registered led device: ath9k-phy0::tx > Aug 22 22:00:49 localhost klogd: Registered led device: ath9k-phy0::rx > Aug 22 22:00:49 localhost klogd: phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 > RF Rev:d0: mem=0xffffc900110e0000, irq=17 > Aug 22 22:00:53 localhost klogd: cfg80211: Calling CRDA for country: FR > Aug 22 22:00:53 localhost klogd: cfg80211: Regulatory domain changed to > country: FR > Aug 22 22:00:53 localhost klogd: ^I(start_freq - end_freq @ bandwidth), > (max_antenna_gain, max_eirp) > Aug 22 22:00:53 localhost klogd: ^I(2402000 KHz - 2482000 KHz @ 40000 KHz), > (N/A, 2000 mBm) > Aug 22 22:00:53 localhost klogd: ^I(5170000 KHz - 5250000 KHz @ 40000 KHz), > (N/A, 2000 mBm) > Aug 22 22:00:53 localhost klogd: ^I(5250000 KHz - 5330000 KHz @ 40000 KHz), > (N/A, 2000 mBm) > Aug 22 22:00:53 localhost klogd: ^I(5490000 KHz - 5710000 KHz @ 40000 KHz), > (N/A, 2700 mBm) > Aug 22 22:00:53 localhost klogd: ADDRCONF(NETDEV_UP): wlan0: link is not > ready > Aug 22 22:00:53 localhost klogd: > Aug 22 22:00:54 localhost klogd: ADDRCONF(NETDEV_CHANGE): wlan0: link > becomes ready > Aug 22 22:00:56 localhost klogd: > Aug 22 22:00:57 localhost klogd: > Aug 22 22:00:58 localhost klogd: NET: Registered protocol family 17 > Aug 22 22:00:58 localhost klogd: > Aug 22 22:00:59 localhost klogd: > Aug 22 22:00:59 localhost klogd: > Aug 22 22:01:02 localhost klogd: qnum: 1, txq depth: 2 > Aug 22 22:01:02 localhost klogd: tx queue 1 (a4fa2d20), link > ffff8800a4fa2d20 > Aug 22 22:01:02 localhost klogd: > Aug 22 22:01:04 localhost klogd: 0xf4041071 => 0x0 > Aug 22 22:01:19 localhost klogd: tx queue 1 (a4fa46a8), link > ffff8800a4fa46a8 > Aug 22 22:01:22 localhost klogd: TX complete: skb: ffff8800a4e14900 > Aug 22 22:01:23 localhost klogd: 0x0 => 0xf4041071 > Aug 22 22:01:38 localhost klogd: transmitting packet, skb: ffff8800ad5fa700 > Aug 22 22:01:38 localhost klogd: qnum: 1, txq depth: 2 > Aug 22 22:01:38 localhost klogd: link[1] (ffff8800a4fa8cb8)=50 > (ffff8800a4fa8d50) > Aug 22 22:01:42 localhost klogd: transmitting packet, skb: ffff8800aa9c6d00 > Aug 22 22:02:02 localhost klogd: 0xf4041071 => 0x0 > Aug 22 22:02:02 localhost klogd: link[1] (ffff8800a4faeeb0)=48 > (ffff8800a4faef48) > Aug 22 22:02:02 localhost klogd: Enable TXE on queue: 1 > Aug 22 22:02:09 localhost klogd: > Aug 22 22:02:09 localhost klogd: > Aug 22 22:02:23 localhost klogd: transmitting packet, skb: ffff8800af0d0c00 > Aug 22 22:02:23 localhost klogd: new IMR 0x0 > Aug 22 22:02:23 localhost klogd: enable IER > Aug 22 22:02:24 localhost klogd: transmitting packet, skb: ffff8800a4e16e00 > Aug 22 22:02:24 localhost klogd: qnum: 1, txq depth: 3 > Aug 22 22:02:24 localhost klogd: qnum: 1, txq depth: 2 > Aug 22 22:02:24 localhost klogd: 0xf4041071 => 0x0 > Aug 22 22:02:24 localhost klogd: qnum: 1, txq depth: 2 > Aug 22 22:02:24 localhost klogd: new IMR 0x0 > Aug 22 22:02:27 localhost klogd: transmitting packet, skb: ffff88008a9396f8 > Aug 22 22:02:27 localhost klogd: qnum: 1, txq depth: 2 > Aug 22 22:02:30 localhost klogd: disable IER > Aug 22 22:02:31 localhost klogd: transmitting packet, skb: ffff88007024d900 > Aug 22 22:02:31 localhost klogd: Enable TXE on queue: 1 > Aug 22 22:02:31 localhost klogd: transmitting packet, skb: ffff8800a75df000 > Aug 22 22:02:34 localhost klogd: qnum: 1, txq depth: 3 > Aug 22 22:02:34 localhost klogd: new IMR 0x0 > Aug 22 22:02:37 localhost klogd: disable IER > Aug 22 22:02:37 localhost klogd: qnum: 1, txq depth: 1 > Aug 22 22:02:37 localhost klogd: 0xf4041071 => 0x0 > Aug 22 22:02:40 localhost klogd: link[1] (ffff8800a4fa7b80)=18 > (ffff8800a4fa7c18) > Aug 22 22:02:40 localhost klogd: Enable TXE on queue: 1 > Aug 22 22:02:41 localhost klogd: transmitting packet, skb: ffff8800a206fd00 > Aug 22 22:02:41 localhost klogd: disable IER > Aug 22 22:02:41 localhost klogd: disable IER > Aug 22 22:02:41 localhost klogd: 0xf4041071 => 0x0 > Aug 22 22:02:41 localhost klogd: 0xf4041071 => 0x0 > Aug 22 22:02:41 localhost klogd: disable IER > Aug 22 22:02:41 localhost klogd: link[1] (ffff8800a4faa348)=e0 > (ffff8800a4faa3e0) > Aug 22 22:02:41 localhost klogd: new IMR 0x0 > Aug 22 22:02:41 localhost klogd: qnum: 1, txq depth: 3 > Aug 22 22:02:41 localhost klogd: new IMR 0x918414b4 > Aug 22 22:02:41 localhost klogd: transmitting packet, skb: ffff8800af0d0300 > Aug 22 22:02:43 localhost klogd: link[1] (ffff8800a4faca78)=10 > (ffff8800a4facb10) > Aug 22 22:02:43 localhost klogd: transmitting packet, skb: ffff8800a4dac200 > Aug 22 22:02:43 localhost klogd: new IMR 0x0 > Aug 22 22:02:43 localhost klogd: qnum: 1, txq depth: 2 > Aug 22 22:02:46 localhost klogd: AR_IMR 0x918414b4 IER 0x1 > Aug 22 22:02:46 localhost klogd: AR_IMR 0x918414b4 IER 0x1 > Aug 22 22:02:46 localhost klogd: enable IER > Aug 22 22:02:46 localhost klogd: Writing ofdmbase=12582412 > cckbase=12582712 > Aug 22 22:02:47 localhost klogd: enable IER > Aug 22 22:02:47 localhost klogd: AR_INTR_SYNC_LOCAL_TIMEOUT > Aug 22 22:02:48 localhost klogd: AR_INTR_SYNC_LOCAL_TIMEOUT > Aug 22 22:02:48 localhost klogd: 0x0 => 0xf4041071 > Aug 22 22:02:49 localhost klogd: CE: hpet increasing min_delta_ns to 15000 > nsec > Aug 22 22:02:52 localhost klogd: 0x0 => 0xf4041071 > Aug 22 22:02:53 localhost klogd: new IMR 0x918414b4 > Aug 22 22:02:53 localhost klogd: 0x0 => 0xf4041071 > Aug 22 22:02:54 localhost klogd: 0xf4041071 => 0x0 > Aug 22 22:02:54 localhost klogd: enable IER > Aug 22 22:02:54 localhost klogd: AWAKE -> AWAKE > Aug 22 22:02:55 localhost klogd: ADDRCONF(NETDEV_UP): wlan0: link is not > ready > Aug 22 22:03:07 localhost klogd: > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20091111/406734e5/attachment-0001.htm ^ permalink raw reply [flat|nested] 5+ messages in thread
* [ath9k-devel] ath9k buggy in 2.6.31-rc7 2009-11-10 19:26 ` Kemble Wagner @ 2009-11-12 8:10 ` Thomas Backlund 0 siblings, 0 replies; 5+ messages in thread From: Thomas Backlund @ 2009-11-12 8:10 UTC (permalink / raw) To: ath9k-devel Kemble Wagner skrev: > could you please send me an attachment of the > net-wireless-ath9k-Fix-TX-hang-issue-with-Atheros-chipsets.patch patch > file i want to try testing it > It wont help you on its own... You need a lot of patches to get it fully working again. After a lot of testing with different sets/combinations of patches, here is what I ended up with: # Fixes for ath9k (# 52739) net-wireless-ath9k-downgrade-ASSERT-in-ath_clone_txbuf.patch net-wireless-ath9k-Make-sure-we-configure-a-non-zero-beacon-interval.patch net-wireless-ath9k-differentiate-quality-reporting-between-legacy-and-HT-configurations.patch net-wireless-ath9k-remove-unnecessary-STATION-mode-check.patch net-wireless-ath9k-stop-ani-when-the-STA-gets-disconnected.patch net-wireless-ath9k-race-condition-in-SCANNING-state-check-during-ANI-calibration.patch net-wireless-ath9k-Handle-different-TX-and-RX-streams-properly.patch net-wireless-ath9k-downgrade-assert-in-rc.c-for-invalid-rate.patch net-wireless-ath9k-Manipulate-and-report-the-correct-RSSI.patch net-wireless-ath9k-RX-stucks-during-heavy-traffic-in-HT40-mode.patch net-wireless-ath9k-Fix-TX-hang-issue-with-Atheros-chipsets.patch net-wireless-ath9k-Remove-bogus-assert-in-ath_clone_txbuf.patch net-wireless-ath9k-Handle-tx-desc-shortage-more-appropriately.patch net-wireless-ath9k-do-not-stop-the-queues-in-driver-stop.patch net-wireless-ath9k-Trivial-fix-in-Kconfig.patch net-wireless-ath9k-Update-beacon-RSSI.patch net-wireless-ath9k-Fix-bug-in-PCI-resume.patch net-wireless-ath9k-Set-HW-state-properly.patch net-wireless-ath9k-Fix-TX-poll-cancelling.patch net-wireless-ath9k-Fix-bug-in-retrieving-average-beacon-rssi.patch net-wireless-ath9k-Fix-read-buffer-overflow.patch net-wireless-ath9k-claim-irq-for-ath9k-not-ath-for-pci.patch net-wireless-ath9k-Fix-bug-in-ANI-channel-handling.patch net-wireless-ath9k-Do-a-full-reset-for-AR9280.patch net-wireless-ath9k-Disable-autosleep-feature-by-default.patch net-wireless-ath9k-Fix-RFKILL-bugs.patch net-wireless-ath9k-fix-misplaced-semicolon-on-rate-control.patch Now theese are all merged in upstream linus git tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git but to make it easier for you, and since some of them had to be rediffed to apply cleanly as I only cherrypicked ath9k specific fixes, you can find them all here: http://tmb.mine.nu/Mandriva/Cooker/bugs/ath9k_bug52739/patches/ http://tmb2.mine.nu/Mandriva/Cooker/bugs/ath9k_bug52739/patches/ along with a series file that shows the order they have to be applied in... Now with all theese in place I have no complaints about the ath9k in our 2.6.31.x series kernels... -- Have fun Thomas ^ permalink raw reply [flat|nested] 5+ messages in thread
* [ath9k-devel] ath9k buggy in 2.6.31-rc7 2009-08-22 21:24 [ath9k-devel] ath9k buggy in 2.6.31-rc7 Thomas Backlund 2009-11-10 19:26 ` Kemble Wagner @ 2009-11-10 19:57 ` Luis R. Rodriguez 2009-11-10 20:01 ` Luis R. Rodriguez 1 sibling, 1 reply; 5+ messages in thread From: Luis R. Rodriguez @ 2009-11-10 19:57 UTC (permalink / raw) To: ath9k-devel On Sat, Aug 22, 2009 at 1:24 PM, Thomas Backlund <tmb@mandriva.org> wrote: > Hi, > > I'm tracking a bug in ath9k in 2.6.31-rc7 series, and have been > cherrypicking patches from wireless-testing to try to get a stable ath9k... > > The problem is that if the user configures the interface it works, but have > a weak signal and tends to drop the connection. > > If he reboots, the signal is even weaker, and also drops the connection > faster. He has to reconfigure the interface to get it back up. > > So here is what I have applied: > > net-wireless-ath9k-downgrade-ASSERT-in-ath_clone_txbuf.patch > net-wireless-ath9k-Manipulate-and-report-the-correct-RSSI.patch > net-wireless-ath9k-RX-stucks-during-heavy-traffic-in-HT40-mode.patch > net-wireless-ath9k-Handle-tx-desc-shortage-more-appropriately.patch > net-wireless-ath9k-Trivial-fix-in-Kconfig.patch > net-wireless-ath9k-Update-beacon-RSSI.patch > net-wireless-ath9k-Fix-bug-in-PCI-resume.patch > net-wireless-ath9k-Set-HW-state-properly.patch > net-wireless-ath9k-Fix-bug-in-retrieving-average-beacon-rssi.patch > > > Now with theese patches the signal strength is correct, and the connection > survives the reboot, but does disconnect when transfer > load increases. BTW if you notice any *small* patch which made a huge difference in something very significant please consider e-mailing linux-wireless and Cc'ing stable at kernel.org about it with as much details as you can provide. Stable will not apply large patches to fix small issues or large non-trivial patches to fix some non-oops. It really varies what will get applied.. but if some few small patches *really* help its worth noting at the very least. Because we cannot get some of these patches into 2.6.31 what we tend to recommend is to upgrade just your wireless subsystem to the newer stable kernel release. This can be done with something like: http://wireless.kernel.org/en/users/Download/stable Luis ^ permalink raw reply [flat|nested] 5+ messages in thread
* [ath9k-devel] ath9k buggy in 2.6.31-rc7 2009-11-10 19:57 ` Luis R. Rodriguez @ 2009-11-10 20:01 ` Luis R. Rodriguez 0 siblings, 0 replies; 5+ messages in thread From: Luis R. Rodriguez @ 2009-11-10 20:01 UTC (permalink / raw) To: ath9k-devel On Tue, Nov 10, 2009 at 11:57 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote: > On Sat, Aug 22, 2009 at 1:24 PM, Thomas Backlund <tmb@mandriva.org> wrote: >> Hi, >> >> I'm tracking a bug in ath9k in 2.6.31-rc7 series, and have been >> cherrypicking patches from wireless-testing to try to get a stable ath9k... >> >> The problem is that if the user configures the interface it works, but have >> a weak signal and tends to drop the connection. >> >> If he reboots, the signal is even weaker, and also drops the connection >> faster. He has to reconfigure the interface to get it back up. >> >> So here is what I have applied: >> >> net-wireless-ath9k-downgrade-ASSERT-in-ath_clone_txbuf.patch >> net-wireless-ath9k-Manipulate-and-report-the-correct-RSSI.patch >> net-wireless-ath9k-RX-stucks-during-heavy-traffic-in-HT40-mode.patch >> net-wireless-ath9k-Handle-tx-desc-shortage-more-appropriately.patch >> net-wireless-ath9k-Trivial-fix-in-Kconfig.patch >> net-wireless-ath9k-Update-beacon-RSSI.patch >> net-wireless-ath9k-Fix-bug-in-PCI-resume.patch >> net-wireless-ath9k-Set-HW-state-properly.patch >> net-wireless-ath9k-Fix-bug-in-retrieving-average-beacon-rssi.patch >> >> >> Now with theese patches the signal strength is correct, and the connection >> survives the reboot, but does disconnect when transfer >> load increases. > > BTW if you notice any *small* patch which made a huge difference in > something very significant please consider e-mailing linux-wireless > and Cc'ing stable at kernel.org about it with as much details as you can > provide. I'll also note that we try to be good about this and once we fix something in wireless-testing we CC stable at kernel.org so the fix is also propagated to stable kernels but *sometimes* some few fixes go through without a CC, so if you do notice something worthy please don't hesitate to note. > Stable will not apply large patches to fix small issues or large > non-trivial patches to fix some non-oops. It really varies what will > get applied.. but if some few small patches *really* help its worth > noting at the very least. > > Because we cannot get some of these patches into 2.6.31 what we tend > to recommend is to upgrade just your wireless subsystem to the newer > stable kernel release. This can be done with something like: > > http://wireless.kernel.org/en/users/Download/stable Oh and as an example Ubuntu ships the linux-backport-modules package and in it it has the stable compat-wireless stuff. Luis ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-11-12 8:10 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2009-08-22 21:24 [ath9k-devel] ath9k buggy in 2.6.31-rc7 Thomas Backlund 2009-11-10 19:26 ` Kemble Wagner 2009-11-12 8:10 ` Thomas Backlund 2009-11-10 19:57 ` Luis R. Rodriguez 2009-11-10 20:01 ` Luis R. Rodriguez
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.