* PowerDomain 3940UWD
@ 1999-09-09 17:14 Ryuichi Oikawa
1999-09-09 18:14 ` Michel Lanners
0 siblings, 1 reply; 5+ messages in thread
From: Ryuichi Oikawa @ 1999-09-09 17:14 UTC (permalink / raw)
To: linuxppc-dev
Hello all,
I've tried Adaptec PowerDomain 3094UWD, dual channel UW SCSI card
with PCI-PCI bridge and two SCSI controllers under the bridge,
and I noticed driver related and OF related problems.
First I tried vger 2.2.12 kernel that caused machine check exception
at first IO write transaction. I thought that this was normal because
OF didn't properly set up P2P bridge's IO forwarding window.
The real problem was this part(aic7xxx.c):
#ifdef MMAPIO
if ( !(temp_p->flags & AHC_MULTI_CHANNEL) ||
((temp_p->chip != (AHC_AIC7870 | AHC_PCI)) &&
(temp_p->chip != (AHC_AIC7880 | AHC_PCI))) )
{
...... select MMIO and does ioremap ....
...... if it fails select normal IO ....
}
#endif
that rejected my SCSI card from MMIO forcing normal IO resulting in machin
check. So I had to ignore this statement by #if !defined(__powerpc__) ...
#endif statement.
Does anyone know what is this restriction for?
After that aic7xxx.c properly detected two SCSI chips but entered in a
timeout/resetting loop:-( Apparently interrupts weren't fixed-up by
pcibios_fixup. So I scanned OF searching for correnct IRQ number and
found it at AAPL,interrupts field of P2P bridge. SCSI controllers didn't
have any AAPL,interrupts of course. It seems OF inserts AAPL,interrupts
only at the top node of the slot when it detects a card in the physical
slot. Therefore I had to change arch/ppc/kernel/prom.c as
--- prom.c.orig Sun Aug 29 00:22:21 1999
+++ prom.c Thu Sep 9 22:38:07 1999
@@ -915,8 +915,12 @@
}
ip = (int *) get_property(np, "AAPL,interrupts", &l);
- if (ip == 0)
- ip = (int *) get_property(np, "interrupts", &l);
+ if (ip == 0) {
+ if(get_property(np, "AAPL,slot-name", &l) != 0 && np->parent != 0)
+ ip = (int *) get_property(np->parent, "AAPL,interrupts", &l);
+ else
+ ip = (int *) get_property(np, "interrupts", &l);
+ }
if (ip != 0) {
np->intrs = (struct interrupt_info *) mem_start;
np->n_intrs = l / sizeof(int);
,and now aic7xxx.c is working fine for both SCSI channel.
I don't know if it is OF(PowerMac8500, OF 1.0.5) version specific,
or SCSI card specific, or PowerMac OF nature. Any ideas?
Regards,
Ryuichi Oikawa
roikawa@rr.iij4u.or.jp
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: PowerDomain 3940UWD 1999-09-09 17:14 PowerDomain 3940UWD Ryuichi Oikawa @ 1999-09-09 18:14 ` Michel Lanners 1999-09-11 17:57 ` Ryuichi Oikawa 0 siblings, 1 reply; 5+ messages in thread From: Michel Lanners @ 1999-09-09 18:14 UTC (permalink / raw) To: roikawa; +Cc: linuxppc-dev On 10 Sep, this message from Ryuichi Oikawa echoed through cyberspace: > I've tried Adaptec PowerDomain 3094UWD, dual channel UW SCSI card > with PCI-PCI bridge and two SCSI controllers under the bridge, > and I noticed driver related and OF related problems. > > First I tried vger 2.2.12 kernel that caused machine check exception > at first IO write transaction. I thought that this was normal because > OF didn't properly set up P2P bridge's IO forwarding window. > The real problem was this part(aic7xxx.c): > > #ifdef MMAPIO > if ( !(temp_p->flags & AHC_MULTI_CHANNEL) || > ((temp_p->chip != (AHC_AIC7870 | AHC_PCI)) && > (temp_p->chip != (AHC_AIC7880 | AHC_PCI))) ) > { > ...... select MMIO and does ioremap .... > ...... if it fails select normal IO .... > } > #endif > > that rejected my SCSI card from MMIO forcing normal IO resulting in machin > check. So I had to ignore this statement by #if !defined(__powerpc__) ... > #endif statement. > > Does anyone know what is this restriction for? I could imagine that certain Adaptec SCSI chips use a regular PCI memory region for their registers, while others use a PCI I/O region. There are chances that the PCI I/O region is not enabled on your board, and therefore accessing it results in a machine check. Can you send me the output of lspci -vv, preferably once without the aic7xxx driver in the kernel, and once with your fixes? > After that aic7xxx.c properly detected two SCSI chips but entered in a > timeout/resetting loop:-( Apparently interrupts weren't fixed-up by > pcibios_fixup. IRQs do get fixed, even on devices behind P2P bridges... iff OF did assing IRQs, that is, as you found below. > So I scanned OF searching for correnct IRQ number and > found it at AAPL,interrupts field of P2P bridge. SCSI controllers didn't > have any AAPL,interrupts of course. It seems OF inserts AAPL,interrupts > only at the top node of the slot when it detects a card in the physical > slot. Therefore I had to change arch/ppc/kernel/prom.c as > [snip'ed code] Your fix looks OK to me; on PowerMacs, all PCI devices in any one slot share the same interrupt, as the four PCI interrupt pins are OR'ed together per slot. > I don't know if it is OF(PowerMac8500, OF 1.0.5) version specific, > or SCSI card specific, or PowerMac OF nature. Any ideas? Either OF-specific in general, or one of the many bugs in OF 1.0.5. Anyway, as I said, your patch wouldn't break anything, even if OF did assign IRQs already. Michel ------------------------------------------------------------------------- Michel Lanners | " Read Philosophy. Study Art. 23, Rue Paul Henkes | Ask Questions. Make Mistakes. L-1710 Luxembourg | email mlan@cpu.lu | http://www.cpu.lu/~mlan | Learn Always. " ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PowerDomain 3940UWD 1999-09-09 18:14 ` Michel Lanners @ 1999-09-11 17:57 ` Ryuichi Oikawa 1999-09-12 21:02 ` Michel Lanners 0 siblings, 1 reply; 5+ messages in thread From: Ryuichi Oikawa @ 1999-09-11 17:57 UTC (permalink / raw) To: mlan; +Cc: linuxppc-dev From: Michel Lanners <mlan@cpu.lu> Subject: Re: PowerDomain 3940UWD > > #ifdef MMAPIO > > if ( !(temp_p->flags & AHC_MULTI_CHANNEL) || > > ((temp_p->chip != (AHC_AIC7870 | AHC_PCI)) && > > (temp_p->chip != (AHC_AIC7880 | AHC_PCI))) ) > > { > > ...... select MMIO and does ioremap .... > > ...... if it fails select normal IO .... > > } > > #endif > I could imagine that certain Adaptec SCSI chips use a regular PCI > memory region for their registers, while others use a PCI I/O region. > There are chances that the PCI I/O region is not enabled on your board, > and therefore accessing it results in a machine check. Sorry, but my question was: It looks like the author of this driver assumes adaptec chips with temp_p->flags & AHC_MULTI_CHANNEL) || temp_p->chip == (AHC_AIC7870 | AHC_PCI) || temp_p->chip == (AHC_AIC7880 | AHC_PCI) cannot support MMIO and it even skips the check for MMIO ability(of course, check is done after enabling PCI_COMMAND_MEMORY bit), but PowerDomain3940UWD (AHC_MULTI_CHANNEL && (AHC_AIC7880 | AHC_PCI)) does support MMIO and works fine, so that I wonder if there are some broken cards or bioses with the above feature. Is this patch below dangerous? I'd like to use MMIO on the PPC. --- aic7xxx.c.orig Thu Sep 9 23:00:59 1999 +++ aic7xxx.c Thu Sep 9 23:03:06 1999 @@ -9660,9 +9660,11 @@ } #ifdef MMAPIO +#if !defined(__powerpc__) if ( !(temp_p->flags & AHC_MULTI_CHANNEL) || ((temp_p->chip != (AHC_AIC7870 | AHC_PCI)) && (temp_p->chip != (AHC_AIC7880 | AHC_PCI))) ) +#endif { unsigned long page_offset, base; > Can you send me the output of lspci -vv, preferably once without the > aic7xxx driver in the kernel, and once with your fixes? I'm very sorry, but I can't show the lspci output without the aic7xxx driver because the SCSI card is now connected to the root device. I attached current lspci -vv output and /proc/device-tree list at the end of this mail. > IRQs do get fixed, even on devices behind P2P bridges... iff OF did > assing IRQs, that is, as you found below. Accoring to the list at the end, OF doesn't assign any IRQ to the adaptec SCSI controller behind the bridge and IO forwarding to the CH.A device is disable, though memory forwarding is enabled. If disabled IO forwarding is a problem, I think the fixing is a pcibios_fixupbus()'s job that is currently empty. It should be scanning all PCI devices' base addresses behind the bridge and setting/expanding IO/memory limits recursively. For that purpose, some methods will be necessary that can judge properly whether the base address is right or wrong because some broken logic board may write wrong values to the base address registers. And I have no idea on that metohd... > Your fix looks OK to me; on PowerMacs, all PCI devices in any one slot > share the same interrupt, as the four PCI interrupt pins are OR'ed > together per slot. I see. Then assignig IRQ's to the only the top of the device node per physical slot may be curious but reasonable, even if it is a non-interrupt generating PCI-bridge. > > I don't know if it is OF(PowerMac8500, OF 1.0.5) version specific, > > or SCSI card specific, or PowerMac OF nature. Any ideas? > > Either OF-specific in general, or one of the many bugs in OF 1.0.5. > Anyway, as I said, your patch wouldn't break anything, even if OF did > assign IRQs already. Thank you, then would someone apply the patch to the kernel development tree? Regards, Ryuichi Oikawa roikawa@rr.iij4u.or.jp Attached lists from here------ lspci -vv: 00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21050 (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 32 set, cache line size 08 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 00001000-00001fff Memory behind bridge: 80800000-808fffff Prefetchable memory behind bridge: 80800000-807fffff BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- 01:04.0 SCSI storage controller: Adaptec AIC-7882U Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 8 min, 8 max, 32 set, cache line size 08 Interrupt: pin A routed to IRQ 23 Region 0: I/O ports at <unassigned> Region 1: Memory at 80800000 (32-bit, non-prefetchable) 01:05.0 SCSI storage controller: Adaptec AIC-7882U Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 8 min, 8 max, 32 set, cache line size 08 Interrupt: pin A routed to IRQ 23 Region 0: I/O ports at 1000 Region 1: Memory at 80801000 (32-bit, non-prefetchable) and list of /proc/device-tree: /proc/device-tree/bandit/pci-bridge: name "pci-bridge" vendor-id 00001011 (4113) device-id 00000001 revision-id 00000002 class-code 00060400 (394240) devsel-speed 00000001 fast-back-to-back AAPL,interrupts 00000017 (23) AAPL,slot-name "A1" device_type "pci" reg 00006800 00000000 00000000 00000000 00000000 #address-cells 00000003 #size-cells 00000002 ranges bus-range 00000001 00000001 power-consumption 007270e0 007270e0 assigned-addresses AAPL,address driver-ist 000651a0 00000007 00000000 00000000 00000000 00000000 /proc/device-tree/bandit/pci-bridge/ADPT,3940UW: name "ADPT,3940UW" vendor-id 00009004 (36868) device-id 00008278 (33400) revision-id 00000000 class-code 00010000 (65536) interrupts 00000001 min-grant 00000008 max-latency 00000008 devsel-speed 00000001 fast-back-to-back AAPL,slot-name "A1" fcode-rom-offset 00000000 device_type "scsi-2" model "ADPT,942106-00" compatible "ADPT,AIC-7880" ADPT,fcode-date "04/07/99" reg 00012000 00000000 00000000 00000000 00000000 02012014 00000000 00000000 00000000 00000100 02012030 00000000 00000000 00000000 00010000 power-consumption 00000000 00000000 007270e0 007270e0 00000000 00000000 007b98a0 007b98a0 assigned-addresses 82012030 00000000 80820000 00000000 00010000 82012014 00000000 80800000 00000000 00000100 AAPL,address 80820000 80800000 driver-ist 00065fb0 00000001 00000000 00000000 00000000 00000000 driver-descriptor 6d74656a 00000000 0b414450 542c3339 34305557 00000000 00000000 00000000 00000000 00000000 04108000 00000004 0d2e4164 61707465 63204348 494d0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 73637369 00000000 01000000 driver-ptr 0006c590 (443792) /proc/device-tree/bandit/pci-bridge/pci9004,8278: name "pci9004,8278" vendor-id 00009004 (36868) device-id 00008278 (33400) revision-id 00000000 class-code 00010000 (65536) interrupts 00000001 min-grant 00000008 max-latency 00000008 devsel-speed 00000001 fast-back-to-back AAPL,slot-name "A1" reg 00012800 00000000 00000000 00000000 00000000 01012810 00000000 00000000 00000000 00000100 02012814 00000000 00000000 00000000 00001000 02012830 00000000 00000000 00000000 00010000 assigned-addresses 81012810 00000000 00001000 00000000 00000100 82012830 00000000 80810000 00000000 00010000 82012814 00000000 80801000 00000000 00001000 AAPL,address f2001000 80810000 80801000 driver-ist 00065fb0 00000002 00000000 00000000 00000000 00000000 ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PowerDomain 3940UWD 1999-09-11 17:57 ` Ryuichi Oikawa @ 1999-09-12 21:02 ` Michel Lanners 1999-09-18 19:07 ` Ryuichi Oikawa 0 siblings, 1 reply; 5+ messages in thread From: Michel Lanners @ 1999-09-12 21:02 UTC (permalink / raw) To: roikawa; +Cc: linuxppc-dev On 12 Sep, this message from Ryuichi Oikawa echoed through cyberspace: >> I could imagine that certain Adaptec SCSI chips use a regular PCI >> memory region for their registers, while others use a PCI I/O region. >> There are chances that the PCI I/O region is not enabled on your board, >> and therefore accessing it results in a machine check. > Sorry, but my question was: > It looks like the author of this driver assumes adaptec chips with > temp_p->flags & AHC_MULTI_CHANNEL) || > temp_p->chip == (AHC_AIC7870 | AHC_PCI) || > temp_p->chip == (AHC_AIC7880 | AHC_PCI) > cannot support MMIO and it even skips the check for MMIO ability(of course, > check is done after enabling PCI_COMMAND_MEMORY bit), but PowerDomain3940UWD > (AHC_MULTI_CHANNEL && (AHC_AIC7880 | AHC_PCI)) does support MMIO and works fine, > so that I wonder if there are some broken cards or bioses with the above feature. Ahhh... then you should get in touch with the author of the driver, and ask about his reasons for doing so. > Is this patch below dangerous? I'd like to use MMIO on the PPC. [patch snip'ed] I'd qualify it dangerous, as it assumes that you can do MMIO on _any_ Adaptec chip in a PowerPC machine.... >> Can you send me the output of lspci -vv, preferably once without the >> aic7xxx driver in the kernel, and once with your fixes? > I attached current lspci -vv output and /proc/device-tree list at the > end of this mail. I'll comment below... >> IRQs do get fixed, even on devices behind P2P bridges... iff OF did >> assing IRQs, that is, as you found below. > Accoring to the list at the end, OF doesn't assign any IRQ to the adaptec > SCSI controller behind the bridge and IO forwarding to the CH.A device is > disable, though memory forwarding is enabled. Yeah, OF didn't assign any IO region to controller 1. That's weired.... I wonder whether OF was confused because of two identical PCI devices... > If disabled IO forwarding is a problem, I think the fixing is a > pcibios_fixupbus()'s job that is currently empty. It should be scanning > all PCI devices' base addresses behind the bridge and setting/expanding > IO/memory limits recursively. For that purpose, some methods will be > necessary that can judge properly whether the base address is right or > wrong because some broken logic board may write wrong values to the > base address registers. And I have no idea on that metohd... Right now, there are no methods implemented in Linux for assigning resources to PCI devices _after_ startup; we're relying on the BIOS to do that. If it does a bad job, then that has to be fixed in pcibios_fixup(). However, there is work underway related to hotplug PCI support, where dynamic resource assigment is a must. pcibios_fixupbus() might be empty right now, but every machine type under the PPC arch has it's own pcibios_fixup() routine; the one for PowerMacs is in arch/ppc/kernel/pmac_pci.c. There is already some work done there for fixing IRQ numbers; I'm workjing on adding even more fixup. The IRQ problem you discovered is a good candidate for inclusion as well. >> Your fix looks OK to me; on PowerMacs, all PCI devices in any one slot >> share the same interrupt, as the four PCI interrupt pins are OR'ed >> together per slot. > I see. Then assignig IRQ's to the only the top of the device node per > physical slot may be curious but reasonable, even if it is a non-interrupt > generating PCI-bridge. > >> > I don't know if it is OF(PowerMac8500, OF 1.0.5) version specific, >> > or SCSI card specific, or PowerMac OF nature. Any ideas? >> >> Either OF-specific in general, or one of the many bugs in OF 1.0.5. >> Anyway, as I said, your patch wouldn't break anything, even if OF did >> assign IRQs already. > Thank you, then would someone apply the patch to the kernel development > tree? I'm only wondering about the more general case of a device without IRQ... Will this patch make interrupts appear on those devices? > lspci -vv: > 00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21050 (rev 02) > I/O behind bridge: 00001000-00001fff This IO wondow seems to be too small to accomodate both controllers.... I suppose OF assigned it too small? > 01:04.0 SCSI storage controller: Adaptec AIC-7882U > Region 0: I/O ports at <unassigned> ..... here OF didn't assign any IO region. > 01:05.0 SCSI storage controller: Adaptec AIC-7882U > > and list of /proc/device-tree: > /proc/device-tree/bandit/pci-bridge: > name "pci-bridge" > > /proc/device-tree/bandit/pci-bridge/ADPT,3940UW: > name "ADPT,3940UW" > > /proc/device-tree/bandit/pci-bridge/pci9004,8278: > name "pci9004,8278" That's the easy way to assign differing device names in OF... Although, if I remeber right, the OF code onboard should generate differing names by itslef, shouldn't it? Michel ------------------------------------------------------------------------- Michel Lanners | " Read Philosophy. Study Art. 23, Rue Paul Henkes | Ask Questions. Make Mistakes. L-1710 Luxembourg | email mlan@cpu.lu | http://www.cpu.lu/~mlan | Learn Always. " ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PowerDomain 3940UWD 1999-09-12 21:02 ` Michel Lanners @ 1999-09-18 19:07 ` Ryuichi Oikawa 0 siblings, 0 replies; 5+ messages in thread From: Ryuichi Oikawa @ 1999-09-18 19:07 UTC (permalink / raw) To: mlan; +Cc: linuxppc-dev From: Michel Lanners <mlan@cpu.lu> Subject: Re: PowerDomain 3940UWD Sorry for very late response. > > Is this patch below dangerous? I'd like to use MMIO on the PPC. > [patch snip'ed] > > I'd qualify it dangerous, as it assumes that you can do MMIO on _any_ > Adaptec chip in a PowerPC machine.... More precisely it assumes that we can _check_ if MMIO is actually accessible or not without causing machine check on any Adaptec card on a PPC, while the original code assumes that we can do normal IO on any Adaptec card, which made my card crashed. Which is more dangerous? Both? :-) > Yeah, OF didn't assign any IO region to controller 1. That's weired.... > I wonder whether OF was confused because of two identical PCI devices... $ hexdump /proc/bus/pci/01/04.0 (controller 1) 0000000 0490 7882 0700 8002 0000 0001 0820 0000 0000010 0100 0000 0000 8080 0000 0000 0000 0000 ^^^^^^^^^ 0000020 0000 0000 0000 0000 0000 0000 0000 0000 0000030 0000 8280 0000 0000 0000 0000 0001 0808 It looks like OF assined IO at 0x0000. Is '0' meaningless? Of course IO forwarding is disabled as $ hexdump /proc/bus/pci/00/0d.0 0000000 1110 0100 0700 8002 0200 0406 0820 0100 0000010 0000 0000 0000 0000 0001 0100 1010 8022 ^^^^ 0000020 8080 8080 8080 7080 0000 0000 0000 0000 0000030 0000 0000 0000 0000 0000 0000 0000 0400 > Right now, there are no methods implemented in Linux for assigning > resources to PCI devices _after_ startup; we're relying on the BIOS to > do that. If it does a bad job, then that has to be fixed in > pcibios_fixup(). However, there is work underway related to hotplug PCI > support, where dynamic resource assigment is a must. That sounds intereting. Does that work like CardBus? Can I access the code? > pcibios_fixupbus() might be empty right now, but every machine type > under the PPC arch has it's own pcibios_fixup() routine; the one for > PowerMacs is in arch/ppc/kernel/pmac_pci.c. There is already some work > done there for fixing IRQ numbers; I'm workjing on adding even more > fixup. The IRQ problem you discovered is a good candidate for inclusion > as well. I never disagree that. You can do everything in _fixup(), but I wonder if there is any job rest for _fixupbus()... > I'm only wondering about the more general case of a device without > IRQ... Will this patch make interrupts appear on those devices? Unfortunately no in general, if - the PCI card has more than one P2P bridge(what kind of card?) - OF doesn't insert AAPL,slot-name property - OF doesn't assign any IRQ to the card(how can we fix in this case??) > > 01:04.0 SCSI storage controller: Adaptec AIC-7882U > > Region 0: I/O ports at <unassigned> > > ..... here OF didn't assign any IO region. 0x0000? > > and list of /proc/device-tree: > > /proc/device-tree/bandit/pci-bridge: > > name "pci-bridge" > > > > /proc/device-tree/bandit/pci-bridge/ADPT,3940UW: > > name "ADPT,3940UW" > > > > /proc/device-tree/bandit/pci-bridge/pci9004,8278: > > name "pci9004,8278" > > That's the easy way to assign differing device names in OF... Although, > if I remeber right, the OF code onboard should generate differing names > by itslef, shouldn't it? OF seems to simply assign vendor,device as a name for nameless(?) devie... Regards, Ryuichi Oikawa roikawa@rr.iij4u.or.jp ** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/ ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~1999-09-18 19:07 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 1999-09-09 17:14 PowerDomain 3940UWD Ryuichi Oikawa 1999-09-09 18:14 ` Michel Lanners 1999-09-11 17:57 ` Ryuichi Oikawa 1999-09-12 21:02 ` Michel Lanners 1999-09-18 19:07 ` Ryuichi Oikawa
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).