* Re: RFC: Reproducible oops with lockdep on count_matching_names()
From: Peter Zijlstra @ 2007-11-05 12:00 UTC (permalink / raw)
To: Michael Buesch
Cc: Luis R. Rodriguez, Michael Wu, linux-wireless, John W. Linville,
Ingo Molnar, Johannes Berg, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Michael Chan, netdev-u79uwXL29TY76Z2rM5mHXA, Pekka Enberg,
Christoph Lameter
In-Reply-To: <200711032106.56569.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
On Sat, 2007-11-03 at 21:06 +0100, Michael Buesch wrote:
> On Saturday 03 November 2007 20:58:09 Luis R. Rodriguez wrote:
> > I was using SLAB and ran into other strange oops, as the one below,
> > but after switching to SLUB, after Michael Buesch's suggestion that
> > one went away... The lockdep segfault is still present, however.
>
> Who is responsible for slab btw?
> I mean, someone should be interested in getting this bug fixed. :)
> When using slab I see random corruptions. I think related to rmmod, but
> I'm not sure. I don't see this with slub.
Pekka and Christoph do most SLAB work.
the snipped oops:
> ----- oops with slab, not reproducible with slub:
>
> mcgrof@pogo:~$ sudo rmmod tg3
> mcgrof@pogo:~$ sudo rmmod sr_mod
>
> *** dmesg -c
>
> ACPI: PCI interrupt for device 0000:02:00.0 disabled
> BUG: unable to handle kernel paging request at virtual address f88a4a05
> printing eip: f88a4a05 *pde = 02000067 *pte = 00000000
> Oops: 0000 [#1]
> Modules linked in: sr_mod uinput thinkpad_acpi hwmon backlight nvram
> ipv6 acpi_cpufreq cpufreq_userspace cpufreq_powersave cpufreq_ondemand
> cpufreq_conservative dock arc4 ecb blkcipher cryptomgr crypto_algapi
> rc80211_simple ath5k mac80211 cfg80211 pcmcia crc32 snd_hda_intel
> snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_hwdep snd_seq_oss
> ipw2200 snd_seq_midi_event ieee80211 ieee80211_crypt sg ehci_hcd
> uhci_hcd yenta_socket rsrc_nonstatic snd_seq snd_timer snd_seq_device
> firmware_class cdrom pcmcia_core usbcore evdev rng_core rtc snd
> soundcore
>
> Pid: 2908, comm: modprobe Not tainted (2.6.24-rc1 #18)
> EIP: 0060:[<f88a4a05>] EFLAGS: 00010086 CPU: 0
> EIP is at 0xf88a4a05
> EAX: c20b75c8 EBX: c2f86f38 ECX: f88a4a05 EDX: c2f86f38
> ESI: c20b75c8 EDI: c2f89c00 EBP: c3897bfc ESP: c3897be0
> DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
> Process modprobe (pid: 2908, ti=c3896000 task=c3935150 task.ti=c3896000)
> Stack: c01b2afc c2f82d98 c3897bf4 c01ba8b6 c2f86f38 c20b75c8 c2f82c00 c3897c24
> c02186dd c2f86f38 c3897c24 c01b54c0 c20b75c8 00000001 c20b75c8 c2f86f38
> c20b75c8 c3897c30 c01b54ed 00000001 c3897c54 c01b556c 00000001 c3897cd4
> Call Trace:
> [<c0104cec>] show_trace_log_lvl+0x1a/0x2f
> [<c0104d9e>] show_stack_log_lvl+0x9d/0xa5
> [<c0104e53>] show_registers+0xad/0x17c
> [<c0105017>] die+0xf5/0x1c6
> [<c0112715>] do_page_fault+0x450/0x537
> [<c02a835a>] error_code+0x6a/0x70
> [<c02186dd>] scsi_request_fn+0x5f/0x2ec
> [<c01b54ed>] __generic_unplug_device+0x20/0x23
> [<c01b556c>] blk_execute_rq_nowait+0x7c/0x8f
> [<c01b69e5>] blk_execute_rq+0xb1/0xcf
> [<c0217f53>] scsi_execute+0xc4/0xd7
> [<c0218014>] scsi_execute_req+0xae/0xcb
> [<f885f571>] sr_probe+0x1d5/0x557 [sr_mod]
> [<c020fd33>] driver_probe_device+0xe8/0x168
> [<c020fec9>] __driver_attach+0x6a/0xa1
> [<c020f271>] bus_for_each_dev+0x36/0x5b
> [<c020fb7f>] driver_attach+0x19/0x1b
> [<c020f556>] bus_add_driver+0x73/0x1aa
> [<c02100a5>] driver_register+0x67/0x6c
> [<c021b4f8>] scsi_register_driver+0xf/0x11
> [<f8863023>] init_sr+0x23/0x3d [sr_mod]
> [<c013a461>] sys_init_module+0x1142/0x1262
> [<c0103d7e>] sysenter_past_esp+0x5f/0xa5
> =======================
> Code: Bad EIP value.
> EIP: [<f88a4a05>] 0xf88a4a05 SS:ESP 0068:c3897be0
>
^ permalink raw reply
* Re: RFC: Reproducible oops with lockdep on count_matching_names()
From: Pekka Enberg @ 2007-11-05 12:23 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Michael Buesch, Luis R. Rodriguez, Michael Wu, linux-wireless,
John W. Linville, Ingo Molnar, Johannes Berg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Michael Chan,
netdev-u79uwXL29TY76Z2rM5mHXA, Christoph Lameter
In-Reply-To: <1194264016.27652.428.camel@twins>
Hi Michael,
On Sat, 2007-11-03 at 21:06 +0100, Michael Buesch wrote:
> Who is responsible for slab btw?
> I mean, someone should be interested in getting this bug fixed. :)
> When using slab I see random corruptions. I think related to rmmod, but
> I'm not sure. I don't see this with slub.
Is CONFIG_DEBUG_SLAB enabled? Usually these kind of random corruptions
are caused by someone passing a bad pointer to kfree() or
kmem_cache_free().
Pekka
^ permalink raw reply
* Re: Endianness problem with u32 classifier hash masks
From: Radu Rendec @ 2007-11-05 12:59 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: jamal, netdev
In-Reply-To: <20071105091231.GA1933@ff.dom.local>
Jarek, thanks for replying my message on the list and pointing it to the
right direction.
Your example with "1" bits laying on exact nibble boundary is much
easier to analyze than my original example. And your computation seems
to be right: u32_hash_fold() would return 00.f0.00.0f (and would be cut
off to 0f after applying the divisor mask).
When I ran into this issue and figured out what was happening in
u32_classify(), at first I thought it could be fixed without any change
at all (in either kernel or tc). For a moment, computing the mask and
resulting bucket by taking into account the host<->net conversions and
supplying them "correctly" to tc seemed to be the best/easiest approach.
Then I figured out what the real problem is: if you look at network
ordered bytes and treat them as a host ordered u32, logically adjacent
bits from different bytes (in network order) will no longer be adjacent
in the host ordered u32. And this has nothing to with bitwise anding
(masking) or shifting. In other words, whatever mask or fshift values
you choose, those bits will still not be adjacent.
Jamal, I am aware that any computation on the fast path involves some
performance loss. However, I don't see any speed gain with your patch,
because you just moved the ntohl() call inside u32_hash_fold(). Since
u32_hash_fold() is called unconditionally and the only call is that one
in u32_classify(), htohl() will be called exactly the same number of
times.
After almost a week of dealing with this, I still don't think it can be
solved without byte re-ordering. If you guys think my patch is good, I
would be more than glad to send it properly (change the comments as
Jarek suggested and use git). Since I'm quite a newbie with git and
haven't worked with kernel maintainers before, please be patient if it's
not perfect at the first attempt :) What tree/branch should I make the
patch against?
Thanks,
Radu Rendec
On Mon, 2007-11-05 at 10:12 +0100, Jarek Poplawski wrote:
> On Sun, Nov 04, 2007 at 06:58:13PM -0500, jamal wrote:
> > On Sun, 2007-04-11 at 02:17 +0100, Jarek Poplawski wrote:
...
> > diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c
> > index 9e98c6e..6dd569b 100644
> > --- a/net/sched/cls_u32.c
> > +++ b/net/sched/cls_u32.c
> > @@ -93,7 +93,7 @@ static __inline__ unsigned u32_hash_fold(u32 key, struct tc_u32_sel *sel, u8 fsh
> > {
> > unsigned h = (key & sel->hmask)>>fshift;
> >
> > - return h;
> > + return ntohl(h);
> > }
>
> Seems not good or I miss something:
>
> host order:
> address: xx.xx.xf.fx
> hmask : 00.00.0f.f0
>
> net order:
> address: fx.xf.xx.xx
> hmask : f0.0f.00.00
>
> fshift after ntohl(s->hmask): 4
> so, above:
> h = (fx.xf.xx.xx & f0.0f.00.00) >> 4;
> h == 0f.00.f0.00
> return 00.f0.00.0f (?)
>
> But, I hope, maybe Radu could check this better - after his analyze
> it looks like his coffee is the best!
>
> Currently I think this should be possible to get this one important
> byte with 2 shifts, but it needs much more coffee on my slow path...
> But, this wouldn't be very readable and I'm not sure the gain would
> be really visible with current cpus, so maybe this first proposal is
> quite reasonable. Then, I'd only suggest to Radu to change the '*'
> style a bit in the comment and to sign this off, if you agree?
>
> Cheers,
> Jarek P.
>
> BTW: when looking around this I think, maybe, in u32_change():
>
> 1) if (--divisor > 0x100) should be probably ">=", but is it really
> needed to check this 2 times (including tc)?
> 2) this while() loop for n->fshift could be replaced with ffs()?
^ permalink raw reply
* Re: RFC: Reproducible oops with lockdep on count_matching_names()
From: Michael Buesch @ 2007-11-05 13:03 UTC (permalink / raw)
To: Pekka Enberg
Cc: Peter Zijlstra, Luis R. Rodriguez, Michael Wu, linux-wireless,
John W. Linville, Ingo Molnar, Johannes Berg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Michael Chan,
netdev-u79uwXL29TY76Z2rM5mHXA, Christoph Lameter
In-Reply-To: <84144f020711050423r7a1f0e55g36c8c5ad29bfc700-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Monday 05 November 2007 13:23:50 Pekka Enberg wrote:
> Hi Michael,
>
> On Sat, 2007-11-03 at 21:06 +0100, Michael Buesch wrote:
> > Who is responsible for slab btw?
> > I mean, someone should be interested in getting this bug fixed. :)
> > When using slab I see random corruptions. I think related to rmmod, but
> > I'm not sure. I don't see this with slub.
>
> Is CONFIG_DEBUG_SLAB enabled? Usually these kind of random corruptions
> are caused by someone passing a bad pointer to kfree() or
> kmem_cache_free().
Yeah.
What I also saw was random "one-bit-errors" once and then on rmmod of modules.
I have absolutely no idea how they were caused, though (I read the freeing
codes of the stuff hundreds of times). I don't have any of the oops messages
anymore.
But I do _not_ see this behaviour with slub anymore.
--
Greetings Michael.
^ permalink raw reply
* [PATCH] netX: update ethernet driver to firmware 1007
From: Robert Schwebel @ 2007-11-05 13:08 UTC (permalink / raw)
To: netdev
From: Sascha Hauer <s.hauer@pengutronix.de>
The ethernet firmware revision 1007 fixes several issues with the
network chip. This update makes the driver work with that firmware
revision.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/net/netx-eth.c | 91 +++++++++++++++++++++++++++++++++++++++----------
1 file changed, 73 insertions(+), 18 deletions(-)
Index: drivers/net/netx-eth.c
===================================================================
--- drivers/net/netx-eth.c.orig
+++ drivers/net/netx-eth.c
@@ -71,18 +71,29 @@
#define FIFO_PTR_ERROR_MASK (0xf << 28)
#define ISR_LINK_STATUS_CHANGE (1<<4)
-#define ISR_IND_LO (1<<3)
-#define ISR_CON_LO (1<<2)
-#define ISR_IND_HI (1<<1)
-#define ISR_CON_HI (1<<0)
+#define ISR_IND_LO (priv->xc_version >= 1007 ? (1<<1) : (1<<3))
+#define ISR_CON_LO (priv->xc_version >= 1007 ? (1<<3) : (1<<2))
+#define ISR_IND_HI (priv->xc_version >= 1007 ? (1<<0) : (1<<1))
+#define ISR_CON_HI (priv->xc_version >= 1007 ? (1<<2) : (1<<0))
#define ETH_MAC_LOCAL_CONFIG 0x1560
-#define ETH_MAC_4321 0x1564
-#define ETH_MAC_65 0x1568
+
+/* Firmware >= 1.007 */
+#define ETH_MAC_IRQ_ENABLE 0x1564
+#define IRQ_ENABLE_IND_HI (1<<0)
+#define IRQ_ENABLE_IND_LO (1<<1)
+#define IRQ_ENABLE_CON_HI (1<<2)
+#define IRQ_ENABLE_CON_LO (1<<3)
+#define IRQ_ENABLE_LINK_STATUS (1<<4)
+
+#define ETH_MAC_4321 (0x1564 + ((priv->xc_version >= 1007) ? 4 : 0))
+#define ETH_MAC_65 (0x1568 + ((priv->xc_version >= 1007) ? 4 : 0))
#define MAC_TRAFFIC_CLASS_ARRANGEMENT_SHIFT 16
#define MAC_TRAFFIC_CLASS_ARRANGEMENT_MASK (0xf<<MAC_TRAFFIC_CLASS_ARRANGEMENT_SHIFT)
#define MAC_TRAFFIC_CLASS_ARRANGEMENT(x) (((x)<<MAC_TRAFFIC_CLASS_ARRANGEMENT_SHIFT) & MAC_TRAFFIC_CLASS_ARRANGEMENT_MASK)
+
+/* Firmware < 1.007 */
#define LOCAL_CONFIG_LINK_STATUS_IRQ_EN (1<<24)
#define LOCAL_CONFIG_CON_LO_IRQ_EN (1<<23)
#define LOCAL_CONFIG_CON_HI_IRQ_EN (1<<22)
@@ -101,6 +112,8 @@ struct netx_eth_priv {
u32 msg_enable;
struct xc *xc;
spinlock_t lock;
+
+ int xc_version;
};
static void netx_eth_set_multicast_list(struct net_device *ndev)
@@ -128,8 +141,8 @@ netx_eth_hard_start_xmit(struct sk_buff
FIFO_PTR_FRAMELEN(len));
ndev->trans_start = jiffies;
- dev->stats.tx_packets++;
- dev->stats.tx_bytes += skb->len;
+ ndev->stats.tx_packets++;
+ ndev->stats.tx_bytes += skb->len;
netif_stop_queue(ndev);
spin_unlock_irq(&priv->lock);
@@ -155,7 +168,7 @@ static void netx_eth_receive(struct net_
if (unlikely(skb == NULL)) {
printk(KERN_NOTICE "%s: Low memory, packet dropped.\n",
ndev->name);
- dev->stats.rx_dropped++;
+ ndev->stats.rx_dropped++;
return;
}
@@ -169,8 +182,8 @@ static void netx_eth_receive(struct net_
ndev->last_rx = jiffies;
skb->protocol = eth_type_trans(skb, ndev);
netif_rx(skb);
- dev->stats.rx_packets++;
- dev->stats.rx_bytes += len;
+ ndev->stats.rx_packets++;
+ ndev->stats.rx_bytes += len;
}
static irqreturn_t
@@ -226,13 +239,23 @@ static int netx_eth_open(struct net_devi
ndev->dev_addr[5]<<8,
priv->xpec_base + NETX_XPEC_RAM_START_OFS + ETH_MAC_65);
- writel(LOCAL_CONFIG_LINK_STATUS_IRQ_EN |
- LOCAL_CONFIG_CON_LO_IRQ_EN |
- LOCAL_CONFIG_CON_HI_IRQ_EN |
- LOCAL_CONFIG_IND_LO_IRQ_EN |
- LOCAL_CONFIG_IND_HI_IRQ_EN,
- priv->xpec_base + NETX_XPEC_RAM_START_OFS +
- ETH_MAC_LOCAL_CONFIG);
+ if (priv->xc_version >= 1007) {
+ writel(IRQ_ENABLE_LINK_STATUS |
+ IRQ_ENABLE_CON_LO |
+ IRQ_ENABLE_CON_HI |
+ IRQ_ENABLE_IND_LO |
+ IRQ_ENABLE_IND_HI,
+ priv->xpec_base + NETX_XPEC_RAM_START_OFS +
+ ETH_MAC_IRQ_ENABLE);
+ } else {
+ writel(LOCAL_CONFIG_LINK_STATUS_IRQ_EN |
+ LOCAL_CONFIG_CON_LO_IRQ_EN |
+ LOCAL_CONFIG_CON_HI_IRQ_EN |
+ LOCAL_CONFIG_IND_LO_IRQ_EN |
+ LOCAL_CONFIG_IND_HI_IRQ_EN,
+ priv->xpec_base + NETX_XPEC_RAM_START_OFS +
+ ETH_MAC_LOCAL_CONFIG);
+ }
mii_check_media(&priv->mii, netif_msg_link(priv), 1);
netif_start_queue(ndev);
@@ -249,6 +272,9 @@ static int netx_eth_close(struct net_dev
writel(0,
priv->xpec_base + NETX_XPEC_RAM_START_OFS + ETH_MAC_LOCAL_CONFIG);
+ writel(0,
+ priv->xpec_base + NETX_XPEC_RAM_START_OFS + ETH_MAC_IRQ_ENABLE);
+
free_irq(ndev->irq, ndev);
return 0;
@@ -303,6 +329,30 @@ netx_eth_phy_write(struct net_device *nd
while (readl(NETX_MIIMU) & MIIMU_SNRDY);
}
+static int netx_eth_get_xc_version(struct net_device *ndev)
+{
+ struct netx_eth_priv *priv = netdev_priv(ndev);
+ unsigned long val;
+
+ val = readl(priv->xc->xmac_base + 0x48);
+
+ switch (val) {
+ case 0x20c000c9:
+ priv->xc_version = 1006;
+ break;
+ case 0x0137fe41:
+ priv->xc_version = 1007;
+ break;
+ default:
+ printk(KERN_ERR "%s: could not determine firmware version: 0x%08lx\n", ndev->name, val);
+ return -1;
+ }
+
+ printk(KERN_INFO "%s: found firmware version %d\n", ndev->name, priv->xc_version);
+
+ return 0;
+}
+
static int netx_eth_enable(struct net_device *ndev)
{
struct netx_eth_priv *priv = netdev_priv(ndev);
@@ -335,6 +385,9 @@ static int netx_eth_enable(struct net_de
* loaded the firmware for us
*/
if (running) {
+ if (netx_eth_get_xc_version(ndev))
+ return -ENODEV;
+
/* get Node Address from hardware */
mac4321 = readl(priv->xpec_base +
NETX_XPEC_RAM_START_OFS + ETH_MAC_4321);
@@ -352,6 +405,8 @@ static int netx_eth_enable(struct net_de
printk(CARDNAME ": requesting firmware failed\n");
return -ENODEV;
}
+ if (netx_eth_get_xc_version(ndev))
+ return -ENODEV;
}
xc_reset(priv->xc);
^ permalink raw reply
* Re: Endianness problem with u32 classifier hash masks
From: jamal @ 2007-11-05 13:43 UTC (permalink / raw)
To: Radu Rendec; +Cc: Jarek Poplawski, netdev
In-Reply-To: <1194267561.2987.141.camel@localhost.localdomain>
On Mon, 2007-05-11 at 14:59 +0200, Radu Rendec wrote:
> Jarek, thanks for replying my message on the list and pointing it to the
> right direction.
>
> Your example with "1" bits laying on exact nibble boundary is much
> easier to analyze than my original example. And your computation seems
> to be right: u32_hash_fold() would return 00.f0.00.0f (and would be cut
> off to 0f after applying the divisor mask).
Yes, that example i believe would work just fine today as is with no
changes.
[...]
> Jamal, I am aware that any computation on the fast path involves some
> performance loss. However, I don't see any speed gain with your patch,
> because you just moved the ntohl() call inside u32_hash_fold(). Since
> u32_hash_fold() is called unconditionally and the only call is that one
> in u32_classify(), htohl() will be called exactly the same number of
> times.
>
Sorry, I didnt mean that to be a better approach - it suffers the same
problem as what you posted and infact is just your patch simplified
essentially (or my attempt at doing that).
A simpler version would be to do something in u32_change() only and
nowhere else. Thats what i alluded at using fshift. And even after
taking a shower i cant think of a simple way to achieve it.
> After almost a week of dealing with this, I still don't think it can be
> solved without byte re-ordering. If you guys think my patch is good, I
> would be more than glad to send it properly (change the comments as
> Jarek suggested and use git). Since I'm quite a newbie with git and
> haven't worked with kernel maintainers before, please be patient if it's
> not perfect at the first attempt :) What tree/branch should I make the
> patch against?
>
Please try the patch i sent since it is simpler. It is your work more or
less - so you should get the credit as author.
Use Davem's net-2.6 as basis. If it works send it to him and CC me and i
will just wsignoff/ack.
If it doesnt work, can you cutdown on the conversion in u32_change()
instead and send that?
cheers,
jamal
^ permalink raw reply
* Re: Endianness problem with u32 classifier hash masks
From: Jarek Poplawski @ 2007-11-05 13:52 UTC (permalink / raw)
To: Radu Rendec; +Cc: jamal, netdev
In-Reply-To: <1194267561.2987.141.camel@localhost.localdomain>
On Mon, Nov 05, 2007 at 02:59:21PM +0200, Radu Rendec wrote:
...
> Jamal, I am aware that any computation on the fast path involves some
> performance loss. However, I don't see any speed gain with your patch,
> because you just moved the ntohl() call inside u32_hash_fold(). Since
> u32_hash_fold() is called unconditionally and the only call is that one
> in u32_classify(), htohl() will be called exactly the same number of
> times.
It seems this performance loss shouldn't be so big because ntohl()
is probably quite well optimized in assembler. But, as I've written,
since there is max. 1 byte meaningful to us there is some additional
possibility to get it other way, but I doubt it's worth to bother,
and this can be done with some later patch, after all.
>
> After almost a week of dealing with this, I still don't think it can be
> solved without byte re-ordering. If you guys think my patch is good, I
> would be more than glad to send it properly (change the comments as
> Jarek suggested and use git). Since I'm quite a newbie with git and
> haven't worked with kernel maintainers before, please be patient if it's
> not perfect at the first attempt :) What tree/branch should I make the
> patch against?
If we manage to convince Jamal, IMHO a patch to something current like
2.6.24-rc1-git14 (or maybe -rc2 soon), should suffice (plus some
options to diff to get function names etc. eg.: diff -Nurp). Try with
Documentation/SubmittingPatches. Git isn't necessary at all. And don't
forget about a changelog.
Regards,
Jarek P.
^ permalink raw reply
* Re: Endianness problem with u32 classifier hash masks
From: jamal @ 2007-11-05 13:47 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Radu Rendec, netdev
In-Reply-To: <20071105091231.GA1933@ff.dom.local>
On Mon, 2007-05-11 at 10:12 +0100, Jarek Poplawski wrote:
> BTW: when looking around this I think, maybe, in u32_change():
>
> 1) if (--divisor > 0x100) should be probably ">=",
Does it really matter? Divisor can be max of 0xff.
> but is it really needed to check this 2 times (including tc)?
I dont mind letting users shoot themselves in the foot by sending crap.
If it can be avoided with simplicity, then better.
> 2) this while() loop for n->fshift could be replaced with ffs()?
I think so. Can you please send a patch (after some testing of course
maybe using Radu's test data)?
cheers,
jamal
^ permalink raw reply
* Re: RFC: Reproducible oops with lockdep on count_matching_names()
From: Pekka Enberg @ 2007-11-05 13:56 UTC (permalink / raw)
To: Michael Buesch
Cc: Peter Zijlstra, Luis R. Rodriguez, Michael Wu, linux-wireless,
John W. Linville, Ingo Molnar, Johannes Berg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Michael Chan,
netdev-u79uwXL29TY76Z2rM5mHXA, Christoph Lameter
In-Reply-To: <200711051403.39479.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
Hi Michael,
On Monday 05 November 2007 13:23:50 Pekka Enberg wrote:
> > Is CONFIG_DEBUG_SLAB enabled? Usually these kind of random corruptions
> > are caused by someone passing a bad pointer to kfree() or
> > kmem_cache_free().
On 11/5/07, Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org> wrote:
> Yeah.
>
> What I also saw was random "one-bit-errors" once and then on rmmod of modules.
> I have absolutely no idea how they were caused, though (I read the freeing
> codes of the stuff hundreds of times). I don't have any of the oops messages
> anymore.
> But I do _not_ see this behaviour with slub anymore.
It is possible that the corruption is still there but SLUB doesn't
show it. Have you tried with slub_debug enabled?
Anyway, looking at the oops:
> BUG: unable to handle kernel paging request at virtual address f88a4a05
> printing eip: f88a4a05 *pde = 02000067 *pte = 00000000
>
> EIP: 0060:[<f88a4a05>] EFLAGS: 00010086 CPU: 0
> EIP is at 0xf88a4a05
> EAX: c20b75c8 EBX: c2f86f38 ECX: f88a4a05 EDX: c2f86f38
> ESI: c20b75c8 EDI: c2f89c00 EBP: c3897bfc ESP: c3897be0
> DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
> Process modprobe (pid: 2908, ti=c3896000 task=c3935150 task.ti=c3896000)
> Stack: c01b2afc c2f82d98 c3897bf4 c01ba8b6 c2f86f38 c20b75c8 c2f82c00 c3897c24
> c02186dd c2f86f38 c3897c24 c01b54c0 c20b75c8 00000001 c20b75c8 c2f86f38
> c20b75c8 c3897c30 c01b54ed 00000001 c3897c54 c01b556c 00000001 c3897cd4
> Call Trace:
> [<c0104cec>] show_trace_log_lvl+0x1a/0x2f
> [<c0104d9e>] show_stack_log_lvl+0x9d/0xa5
> [<c0104e53>] show_registers+0xad/0x17c
> [<c0105017>] die+0xf5/0x1c6
> [<c0112715>] do_page_fault+0x450/0x537
> [<c02a835a>] error_code+0x6a/0x70
> [<c02186dd>] scsi_request_fn+0x5f/0x2ec
> [<c01b54ed>] __generic_unplug_device+0x20/0x23
We jump to a bogus address 0xf88a4a05 via a function pointer from
scsi_request_fn(). Can you work out the exact file and line for
scsi_request_fn+0x5f (look for "gdb vmlinux" in
Documentation/BUG-HUNTING) please?
Pekka
^ permalink raw reply
* Re: Endianness problem with u32 classifier hash masks
From: jamal @ 2007-11-05 14:06 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Radu Rendec, netdev
In-Reply-To: <20071105135246.GB1933@ff.dom.local>
On Mon, 2007-05-11 at 14:52 +0100, Jarek Poplawski wrote:
> It seems this performance loss shouldn't be so big because ntohl()
> is probably quite well optimized in assembler. But, as I've written,
> since there is max. 1 byte meaningful to us there is some additional
> possibility to get it other way, but I doubt it's worth to bother,
> and this can be done with some later patch, after all.
Agreed on optimizing later. It will probably keep nagging at me for
sometime....
> If we manage to convince Jamal, IMHO a patch to something current like
> 2.6.24-rc1-git14 (or maybe -rc2 soon), should suffice (plus some
> options to diff to get function names etc. eg.: diff -Nurp). Try with
> Documentation/SubmittingPatches. Git isn't necessary at all. And don't
> forget about a changelog.
That code hasnt changed at all in a few years, so even against
2.6.24-rc1 should be fine and can be applied cleanly to Daves net-2.6.
Radu, please refer to my earlier email on things to try.
cheers,
jamal
^ permalink raw reply
* A difficult question regarding problems due to neighboring subsystem state changes
From: Ian Brown @ 2007-11-05 14:12 UTC (permalink / raw)
To: netdev
Hi,
This might seem a little insane/crazy question; yet this is a real kernel
networking problem I encountered; I scratched my head a lot,
probed into the Linux kernel neighboring code, still could not
find an answer. And it still might be that the solution is a lot easier than
I can imagine in my wild dreams!
OK, this is the scenario:
I configure on machine B a second IP on eth0:1 ; this machine has a single nic.
This IP is the same as machine A has. (machines A and B are on
the same LANs). I disabled answering ARP requests
(ARPOP_REQUEST requests) on machine B with they query for that new address
(this can easily done by dropping arp request with NF_ARP_IN hook).
The reasons for using such an architecture are not so relevant here,
as this is part of a large project; but such configuration is indeed needed
in this case.
Now, I cannot ping to the original ip address of machine B from other machines
on the LAN. "ip neigh show" shows that, after adding the new IP
address on eth0:1 of machine B, that this address of machine B
is in a "FAILED" state. (this is due to a timer handler of the neighboring
system, which changes the state as a result of adding IP address to
machine B, as far as I can understand).
(I of course cannot ping the **new** IP address which I added on machine B
since ARPs are disabled on that new IP , as I said before)
Suppose, for example, that the original IP address (on eth0) of
machine B was 192.168.0.154.
The solution I found to this problem was this:
In order to enable pings (and opening sockets, etc) from other
machines to machine B ,I should add on these machines:
"ip neigh add 192.168.0.154 dev eth0 lladdr 00:0C:60:11:A8:12 nud permanent"
or:
"ip neigh change 192.168.0.154 dev eth0 lladdr 00:0C:60:11:A8:12 nud permanent"
in case there is already a (FAILED) entry for this IP in the neighbor (ARP)
table.
This solves the problem (and it could be that there are more (easier) solutions,
I am not an expert on that).
However,I cannot ping from machine A to B when I ping the original address of B!
And the "ip neigh add"/"ip neigh change" solution **can not** solve the
problem here!
The reason this cannot solve the problem here, as far as I can
understand, is this:
when I ping from machine A to B with the original IP of B, it reaches B.
B wants to send a reply to A . Alas, eth0:1 has the IP of A ! so it does not
send reply to A (and instead it gets the reply packets itself).
And of course on machines different than A this does not cause any
problems (becuase they have different IPs than eth0:1 of B, which is A
IP address)
Any ideas if I can enable pings from A to the original IP address of B in
such a case (where I ping the
original IP of B?)
Regards,
Ian
^ permalink raw reply
* Re: [PATCH] ehea: add kexec support
From: Christoph Raisch @ 2007-11-05 14:24 UTC (permalink / raw)
To: Michael Neuling
Cc: Jan-Bernd Themann, Jeff Garzik, linux-kernel, linux-ppc,
Marcus Eder, michael, netdev, ossthema, Stefan Roscher,
Thomas Q Klein
In-Reply-To: <24042.1194069991@neuling.org>
Michael Neuling <mikey@neuling.org> wrote on 03.11.2007 07:06:31:
> > DD allocates HEA resources and gets firmware_handles for these
resources.
> > To free the resources DD needs to use exactly these handles.
> > There's no generic firmware call "clean out all resources".
> > Allocating the same resources twice does not work.
>
> Can we get a new firmware call to do this?
Well, there's no simple answer to this. I'm not working on firmware.
I'm trying to get an answer... but don't expect anything "real soon".
>
> > So a new kernel can't free the resources allocated by an old kernel,
> > because the numeric values of the handles aren't known anymore.
>
> How many possible handles are there?
Depends on system configuration, between
4 and 64 per port.
>
> If the handles are lost, is the only way to clear out the HEA resources
> is to reset the partition?
Yes, that's exactly the problem.
>
> > Potential Solution:
> > Hea driver cleanup function hooks into ppc_md.machine_crash_shutdown
> > and frees all firmware resources at shutdown time of the crashed
kernel.
>
> This means the crashed kernel now has to be trusted to shut down and
> free up the resources. Isn't trusting the crashing kernel in this way
> against the whole kdump idea?
I would hope that if the cleanup routine only does hcalls
and does not change any kernel memory areas, then the risk to damage
anything
else in kernel should be pretty small. This should allow to catch most
cases,
but as always you can imagine situations where the kernel memory is broken
beyond hope to even restart the kdump kernel.
>
> > crash_kexec continues and loads new kernel.
> > The new kernel restarts the HEA driver within kdump kernel, which will
work
> > because resources have been freed before.
> >
> > Michael, would this work?
Is ppc_md.machine_crash_shutdown the right hook?
Gruss/Regards
Christoph R
^ permalink raw reply
* Re: RFC: Reproducible oops with lockdep on count_matching_names()
From: Michael Buesch @ 2007-11-05 14:26 UTC (permalink / raw)
To: Pekka Enberg
Cc: Peter Zijlstra, Luis R. Rodriguez, Michael Wu, linux-wireless,
John W. Linville, Ingo Molnar, Johannes Berg,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Michael Chan,
netdev-u79uwXL29TY76Z2rM5mHXA, Christoph Lameter
In-Reply-To: <84144f020711050556m6675ea90g1b6c8054a3940ec0-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Monday 05 November 2007 14:56:22 Pekka Enberg wrote:
> Hi Michael,
>
> On Monday 05 November 2007 13:23:50 Pekka Enberg wrote:
> > > Is CONFIG_DEBUG_SLAB enabled? Usually these kind of random corruptions
> > > are caused by someone passing a bad pointer to kfree() or
> > > kmem_cache_free().
>
> On 11/5/07, Michael Buesch <mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org> wrote:
> > Yeah.
> >
> > What I also saw was random "one-bit-errors" once and then on rmmod of modules.
> > I have absolutely no idea how they were caused, though (I read the freeing
> > codes of the stuff hundreds of times). I don't have any of the oops messages
> > anymore.
> > But I do _not_ see this behaviour with slub anymore.
>
> It is possible that the corruption is still there but SLUB doesn't
> show it. Have you tried with slub_debug enabled?
Hm, I don't really remember. Though, I usually have all almost kernel-hacking
options enabled.
I'll check and enable some more.
> > BUG: unable to handle kernel paging request at virtual address f88a4a05
> > printing eip: f88a4a05 *pde = 02000067 *pte = 00000000
> >
> > EIP: 0060:[<f88a4a05>] EFLAGS: 00010086 CPU: 0
> > EIP is at 0xf88a4a05
> > EAX: c20b75c8 EBX: c2f86f38 ECX: f88a4a05 EDX: c2f86f38
> > ESI: c20b75c8 EDI: c2f89c00 EBP: c3897bfc ESP: c3897be0
> > DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
> > Process modprobe (pid: 2908, ti=c3896000 task=c3935150 task.ti=c3896000)
> > Stack: c01b2afc c2f82d98 c3897bf4 c01ba8b6 c2f86f38 c20b75c8 c2f82c00 c3897c24
> > c02186dd c2f86f38 c3897c24 c01b54c0 c20b75c8 00000001 c20b75c8 c2f86f38
> > c20b75c8 c3897c30 c01b54ed 00000001 c3897c54 c01b556c 00000001 c3897cd4
> > Call Trace:
> > [<c0104cec>] show_trace_log_lvl+0x1a/0x2f
> > [<c0104d9e>] show_stack_log_lvl+0x9d/0xa5
> > [<c0104e53>] show_registers+0xad/0x17c
> > [<c0105017>] die+0xf5/0x1c6
> > [<c0112715>] do_page_fault+0x450/0x537
> > [<c02a835a>] error_code+0x6a/0x70
> > [<c02186dd>] scsi_request_fn+0x5f/0x2ec
> > [<c01b54ed>] __generic_unplug_device+0x20/0x23
>
> We jump to a bogus address 0xf88a4a05 via a function pointer from
> scsi_request_fn(). Can you work out the exact file and line for
> scsi_request_fn+0x5f (look for "gdb vmlinux" in
> Documentation/BUG-HUNTING) please?
That'd be Luis' task then :)
--
Greetings Michael.
^ permalink raw reply
* Re: Endianness problem with u32 classifier hash masks
From: Jarek Poplawski @ 2007-11-05 14:35 UTC (permalink / raw)
To: jamal; +Cc: Radu Rendec, netdev
In-Reply-To: <1194270426.4438.100.camel@localhost>
On Mon, Nov 05, 2007 at 08:47:06AM -0500, jamal wrote:
> On Mon, 2007-05-11 at 10:12 +0100, Jarek Poplawski wrote:
>
> > BTW: when looking around this I think, maybe, in u32_change():
> >
> > 1) if (--divisor > 0x100) should be probably ">=",
>
> Does it really matter? Divisor can be max of 0xff.
But, according to this max is 0x100... It doesn't really matter,
but we have to wonder which one check is correct if they differ.
>
> > but is it really needed to check this 2 times (including tc)?
>
> I dont mind letting users shoot themselves in the foot by sending crap.
> If it can be avoided with simplicity, then better.
>
> > 2) this while() loop for n->fshift could be replaced with ffs()?
>
> I think so. Can you please send a patch (after some testing of course
> maybe using Radu's test data)?
Since this would be cosmetics here, I think it could wait for this
main patch. But, since testing isn't my best side, maybe I'd ask
Radu for including this "btw"... I mean only something like this:
{
u8 i = 0;
u32 mask = s->hmask;
if (mask) {
- while (!(mask & 1)) {
- i++;
- mask>>=1;
- }
i = ffs(mask) + 1;
}
n->fshift = i;
}
Thanks,
Jarek P.
^ permalink raw reply
* Re: Endianness problem with u32 classifier hash masks
From: Jarek Poplawski @ 2007-11-05 14:49 UTC (permalink / raw)
To: jamal; +Cc: Radu Rendec, netdev
In-Reply-To: <1194270212.4438.95.camel@localhost>
On Mon, Nov 05, 2007 at 08:43:32AM -0500, jamal wrote:
> On Mon, 2007-05-11 at 14:59 +0200, Radu Rendec wrote:
> > Jarek, thanks for replying my message on the list and pointing it to the
> > right direction.
> >
> > Your example with "1" bits laying on exact nibble boundary is much
> > easier to analyze than my original example. And your computation seems
> > to be right: u32_hash_fold() would return 00.f0.00.0f (and would be cut
> > off to 0f after applying the divisor mask).
>
> Yes, that example i believe would work just fine today as is with no
> changes.
...
> Please try the patch i sent since it is simpler. It is your work more or
> less - so you should get the credit as author.
Jamal + Houston, we have a problem...
...Or talk about different things or patches...
IMHO, both 'today as is' and your 1-st proposal get this example
wrong: we need 00.00.00.ff at the end, don't we?
Jarek P.
^ permalink raw reply
* [PATCH] prevent that myri_do_handshake lies about ticks in drivers/net/myri_sbus.c
From: Roel Kluin @ 2007-11-05 15:06 UTC (permalink / raw)
To: netdev
With '<=' tick can be incremented up to 26, The last loop is redundant since
even when 'softstate' becomes 'STATE_READY', 'if (tick > 25)' will still cause
the function to return -1,
Signed-off-by: Roel Kluin <12o3l@tiscali.nl>
---
diff --git a/drivers/net/myri_sbus.c b/drivers/net/myri_sbus.c
index 8d29319..656a260 100644
--- a/drivers/net/myri_sbus.c
+++ b/drivers/net/myri_sbus.c
@@ -134,7 +134,7 @@ static int myri_do_handshake(struct myri_eth *mp)
myri_disable_irq(mp->lregs, cregs);
- while (tick++ <= 25) {
+ while (tick++ < 25) {
u32 softstate;
/* Wake it up. */
^ permalink raw reply related
* Re: [PATCH 2/2] NFS: handle IPv6 addresses in nfs ctl
From: Aurélien Charbon @ 2007-11-05 15:17 UTC (permalink / raw)
To: Neil Brown; +Cc: Mailing list NFSv4, netdev ML
In-Reply-To: <18214.46206.94270.229728@notabene.brown>
Hi Neil,
Thank you for the reply.
Neil Brown wrote:
>>I think this patch is unnecessary and hence not wanted.
>>The getfs / getfs calls should be considered legacy calls.
>>Adding functionality to them is not appropriate.
>>
>>
I agree with that.
But I don't think we really add functionality here.
Modifications are just necessary to match the auth_unix_lookup new
prototype.
I don't see how we can avoid that.
Aurélien
--
********************************
Aurelien Charbon
Linux NFSv4 team
Bull SAS
Echirolles - France
http://nfsv4.bullopensource.org/
********************************
^ permalink raw reply
* Re: Endianness problem with u32 classifier hash masks
From: Radu Rendec @ 2007-11-05 16:12 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: jamal, netdev
In-Reply-To: <20071105144959.GD1933@ff.dom.local>
On Mon, 2007-11-05 at 15:49 +0100, Jarek Poplawski wrote:
> > Yes, that example i believe would work just fine today as is with no
> > changes.
> ...
> > Please try the patch i sent since it is simpler. It is your work more or
> > less - so you should get the credit as author.
>
> Jamal + Houston, we have a problem...
> ...Or talk about different things or patches...
>
> IMHO, both 'today as is' and your 1-st proposal get this example
> wrong: we need 00.00.00.ff at the end, don't we?
>
> Jarek P.
"Today as is" certainly doesn't work with masks extending across byte
boundary. I think Jarek's example (with all "1" bits in nibbles) is the
most straightforward to illustrate this.
Jarek, after I had replied you earlier, I figured out it can indeed be
solved with two shifts, but results need to be masked separately and
then merged to properly align resulting bits. Of course, this is my idea
about the two shifts, maybe you thought of something else.
On the other hand, after a quick browsing through a lxr, it seems that
(at least on i386) ntohl() is actually a swab32(), which is defined in
include/asm-i386/byteorder.h on line 13. In the worst scenario (with
CONFIG_X86_BSWAP being undefined) it's done in 3 instructions (asm
level). It may actually be faster than the two shift approach in C.
Jamal, sometime later in the evening I'll try the patch you sent,
although my guess is that it won't work (most probably it will produce
what Jarek suggested earlier). What exactly did you mean by "cutdown on
the conversion in u32_change()"?
Cheers,
Radu Rendec
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix fs_enet module build
From: Scott Wood @ 2007-11-05 16:19 UTC (permalink / raw)
To: Jochen Friedrich
Cc: linuxppc-embedded@ozlabs.org, linux-kernel, Jeff Garzik, netdev
In-Reply-To: <472CDE02.1020804@scram.de>
Jochen Friedrich wrote:
> diff --git a/drivers/net/fs_enet/Makefile b/drivers/net/fs_enet/Makefile
> index 02d4dc1..2f7563a 100644
> --- a/drivers/net/fs_enet/Makefile
> +++ b/drivers/net/fs_enet/Makefile
> @@ -4,7 +4,15 @@
>
> obj-$(CONFIG_FS_ENET) += fs_enet.o
>
> -obj-$(CONFIG_8xx) += mac-fec.o mac-scc.o mii-fec.o
> -obj-$(CONFIG_CPM2) += mac-fcc.o mii-bitbang.o
> +fs_enet-$(CONFIG_8xx) += mac-fec.o mac-scc.o
> +fs_enet-$(CONFIG_CPM2) += mac-fcc.o
> +
> +ifeq ($(CONFIG_8xx),y)
> + obj-$(CONFIG_FS_ENET) += mii-fec.o
> +endif
> +
> +ifeq ($(CONFIG_CPM2),y)
> + obj-$(CONFIG_FS_ENET) += mii-bitbang.o
> +endif
>
> fs_enet-objs := fs_enet-main.o
If we're going to mess with this, we should probably just make
CONFIG_FS_ENET_SCC, CONFIG_FS_ENET_FCC, and CONFIG_FS_ENET_FEC, and have
them depend on CONFIG_FS_ENET.
-Scott
^ permalink raw reply
* Re: 2.6.24-rc1: hangs when logging in to X session
From: Marcus Better @ 2007-11-05 16:44 UTC (permalink / raw)
To: Herbert Xu; +Cc: Andrew Morton, linux-kernel, netdev
In-Reply-To: <20071105092632.GA10468@gondor.apana.org.au>
Herbert Xu wrote:
> > > > > My laptop hangs when I try to log in to X with the current git
> > > > > kernel (commit 2a397e82c7db18019e408f953dd58dc1963a328c). It runs
> > > > > fine with 2.6.23. At boot time kdm starts normally, but hangs with
> > > > > the caps lock LED blinking immediately after I press Enter after
> > > > > typing the password.
>
> This was fixed after the changeset you quoted so if you update
> to the latest it should work again.
Yes, it works now. Thanks,
Marcus
^ permalink raw reply
* Re: [2.6 patch] remove Documentation/networking/net-modules.txt
From: Adrian Bunk @ 2007-11-05 17:04 UTC (permalink / raw)
To: Pekka Pietikainen; +Cc: jgarzik, netdev, linux-kernel
In-Reply-To: <20071029151813.GA22960@ee.oulu.fi>
On Mon, Oct 29, 2007 at 05:18:14PM +0200, Pekka Pietikainen wrote:
> On Wed, Oct 24, 2007 at 06:25:03PM +0200, Adrian Bunk wrote:
> > According to git, the only one who touched this file during the last
> > 5 years was me when removing drivers...
>
> That's not the only obsolete thing there:
> > ncsa-telnet
> > - notes on how NCSA telnet (DOS) breaks with MTU discovery enabled.
> And probably others too. Then again, the information there isn't wrong, it's
> just totally useless these days :P
OMG
Thanks for the pointer, this kind of useless crap makes it harder to
find the part of the documentation that might actually still be useful.
> Pekka Pietikainen
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* [2.6 patch] remove comx driver docs
From: Adrian Bunk @ 2007-11-05 17:04 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linux-kernel
The drivers have already been removed 3.5 years ago.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
Documentation/networking/00-INDEX | 2
Documentation/networking/comx.txt | 248 -----------------
Documentation/networking/slicecom.hun | 371 --------------------------
Documentation/networking/slicecom.txt | 369 -------------------------
4 files changed, 990 deletions(-)
89b45c57a2a74c6497cd808e15f9ef33077bf352
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index f5a5e6d..c48892e 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -26,8 +26,6 @@ baycom.txt
- info on the driver for Baycom style amateur radio modems
bridge.txt
- where to get user space programs for ethernet bridging with Linux.
-comx.txt
- - info on drivers for COMX line of synchronous serial adapters.
cops.txt
- info on the COPS LocalTalk Linux driver
cs89x0.txt
diff --git a/Documentation/networking/comx.txt b/Documentation/networking/comx.txt
deleted file mode 100644
index d1526eb..0000000
--- a/Documentation/networking/comx.txt
+++ /dev/null
@@ -1,248 +0,0 @@
-
- COMX drivers for the 2.2 kernel
-
-Originally written by: Tivadar Szemethy, <tiv@itc.hu>
-Currently maintained by: Gergely Madarasz <gorgo@itc.hu>
-
-Last change: 21/06/1999.
-
-INTRODUCTION
-
-This document describes the software drivers and their use for the
-COMX line of synchronous serial adapters for Linux version 2.2.0 and
-above.
-The cards are produced and sold by ITC-Pro Ltd. Budapest, Hungary
-For further info contact <info@itc.hu>
-or http://www.itc.hu (mostly in Hungarian).
-The firmware files and software are available from ftp://ftp.itc.hu
-
-Currently, the drivers support the following cards and protocols:
-
-COMX (2x64 kbps intelligent board)
-CMX (1x256 + 1x128 kbps intelligent board)
-HiCOMX (2x2Mbps intelligent board)
-LoCOMX (1x512 kbps passive board)
-MixCOM (1x512 or 2x512kbps passive board with a hardware watchdog an
- optional BRI interface and optional flashROM (1-32M))
-SliceCOM (1x2Mbps channelized E1 board)
-PciCOM (X21)
-
-At the moment of writing this document, the (Cisco)-HDLC, LAPB, SyncPPP and
-Frame Relay (DTE, rfc1294 IP encapsulation with partially implemented Q933a
-LMI) protocols are available as link-level protocol.
-X.25 support is being worked on.
-
-USAGE
-
-Load the comx.o module and the hardware-specific and protocol-specific
-modules you'll need into the running kernel using the insmod utility.
-This creates the /proc/comx directory.
-See the example scripts in the 'etc' directory.
-
-/proc INTERFACE INTRO
-
-The COMX driver set has a new type of user interface based on the /proc
-filesystem which eliminates the need for external user-land software doing
-IOCTL calls.
-Each network interface or device (i.e. those ones you configure with 'ifconfig'
-and 'route' etc.) has a corresponding directory under /proc/comx. You can
-dynamically create a new interface by saying 'mkdir /proc/comx/comx0' (or you
-can name it whatever you want up to 8 characters long, comx[n] is just a
-convention).
-Generally the files contained in these directories are text files, which can
-be viewed by 'cat filename' and you can write a string to such a file by
-saying 'echo _string_ >filename'. This is very similar to the sysctl interface.
-Don't use a text editor to edit these files, always use 'echo' (or 'cat'
-where appropriate).
-When you've created the comx[n] directory, two files are created automagically
-in it: 'boardtype' and 'protocol'. You have to fill in these files correctly
-for your board and protocol you intend to use (see the board and protocol
-descriptions in this file below or the example scripts in the 'etc' directory).
-After filling in these files, other files will appear in the directory for
-setting the various hardware- and protocol-related informations (for example
-irq and io addresses, keepalive values etc.) These files are set to default
-values upon creation, so you don't necessarily have to change all of them.
-
-When you're ready with filling in the files in the comx[n] directory, you can
-configure the corresponding network interface with the standard network
-configuration utilities. If you're unable to bring the interfaces up, look up
-the various kernel log files on your system, and consult the messages for
-a probable reason.
-
-EXAMPLE
-
-To create the interface 'comx0' which is the first channel of a COMX card:
-
-insmod comx
-# insmod comx-hw-comx ; insmod comx-proto-ppp (these are usually
-autoloaded if you use the kernel module loader)
-
-mkdir /proc/comx/comx0
-echo comx >/proc/comx/comx0/boardtype
-echo 0x360 >/proc/comx/comx0/io <- jumper-selectable I/O port
-echo 0x0a >/proc/comx/comx0/irq <- jumper-selectable IRQ line
-echo 0xd000 >/proc/comx/comx0/memaddr <- software-configurable memory
- address. COMX uses 64 KB, and this
- can be: 0xa000, 0xb000, 0xc000,
- 0xd000, 0xe000. Avoid conflicts
- with other hardware.
-cat </etc/siol1.rom >/proc/comx/comx0/firmware <- the firmware for the card
-echo HDLC >/proc/comx/comx0/protocol <- the data-link protocol
-echo 10 >/proc/comx/comx0/keepalive <- the keepalive for the protocol
-ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255 <-
- finally configure it with ifconfig
-Check its status:
-cat /proc/comx/comx0/status
-
-If you want to use the second channel of this board:
-
-mkdir /proc/comx/comx1
-echo comx >/proc/comx/comx1/boardtype
-echo 0x360 >/proc/comx/comx1/io
-echo 10 >/proc/comx/comx1/irq
-echo 0xd000 >/proc/comx/comx1/memaddr
-echo 1 >/proc/comx/comx1/channel <- channels are numbered
- as 0 (default) and 1
-
-Now, check if the driver recognized that you're going to use the other
-channel of the same adapter:
-
-cat /proc/comx/comx0/twin
-comx1
-cat /proc/comx/comx1/twin
-comx0
-
-You don't have to load the firmware twice, if you use both channels of
-an adapter, just write it into the channel 0's /proc firmware file.
-
-Default values: io 0x360 for COMX, 0x320 (HICOMX), irq 10, memaddr 0xd0000
-
-THE LOCOMX HARDWARE DRIVER
-
-The LoCOMX driver doesn't require firmware, and it doesn't use memory either,
-but it uses DMA channels 1 and 3. You can set the clock rate (if enabled by
-jumpers on the board) by writing the kbps value into the file named 'clock'.
-Set it to 'external' (it is the default) if you have external clock source.
-
-(Note: currently the LoCOMX driver does not support the internal clock)
-
-THE COMX, CMX AND HICOMX DRIVERS
-
-On the HICOMX, COMX and CMX, you have to load the firmware (it is different for
-the three cards!). All these adapters can share the same memory
-address (we usually use 0xd0000). On the CMX you can set the internal
-clock rate (if enabled by jumpers on the small adapter boards) by writing
-the kbps value into the 'clock' file. You have to do this before initializing
-the card. If you use both HICOMX and CMX/COMX cards, initialize the HICOMX
-first. The I/O address of the HICOMX board is not configurable by any
-method available to the user: it is hardwired to 0x320, and if you have to
-change it, consult ITC-Pro Ltd.
-
-THE MIXCOM DRIVER
-
-The MixCOM board doesn't require firmware, the driver communicates with
-it through I/O ports. You can have three of these cards in one machine.
-
-THE SLICECOM DRIVER
-
-The SliceCOM board doesn't require firmware. You can have 4 of these cards
-in one machine. The driver doesn't (yet) support shared interrupts, so
-you will need a separate IRQ line for every board.
-Read Documentation/networking/slicecom.txt for help on configuring
-this adapter.
-
-THE HDLC/PPP LINE PROTOCOL DRIVER
-
-The HDLC/SyncPPP line protocol driver uses the kernel's built-in syncppp
-driver (syncppp.o). You don't have to manually select syncppp.o when building
-the kernel, the dependencies compile it in automatically.
-
-
-
-
-EXAMPLE
-(setting up hw parameters, see above)
-
-# using HDLC:
-echo hdlc >/proc/comx/comx0/protocol
-echo 10 >/proc/comx/comx0/keepalive <- not necessary, 10 is the default
-ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255
-
-(setting up hw parameters, see above)
-
-# using PPP:
-echo ppp >/proc/comx/comx0/protocol
-ifconfig comx0 up
-ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255
-
-
-THE LAPB LINE PROTOCOL DRIVER
-
-For this, you'll need to configure LAPB support (See 'LAPB Data Link Driver' in
-'Network options' section) into your kernel (thanks to Jonathan Naylor for his
-excellent implementation).
-comx-proto-lapb.o provides the following files in the appropriate directory
-(the default values in parens): t1 (5), t2 (1), n2 (20), mode (DTE, STD) and
-window (7). Agree with the administrator of your peer router on these
-settings (most people use defaults, but you have to know if you are DTE or
-DCE).
-
-EXAMPLE
-
-(setting up hw parameters, see above)
-echo lapb >/proc/comx/comx0/protocol
-echo dce >/proc/comx/comx0/mode <- DCE interface in this example
-ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255
-
-
-THE FRAME RELAY PROTOCOL DRIVER
-
-You DON'T need any other frame relay related modules from the kernel to use
-COMX-Frame Relay. This protocol is a bit more complicated than the others,
-because it allows to use 'subinterfaces' or DLCIs within one physical device.
-First you have to create the 'master' device (the actual physical interface)
-as you would do for other protocols. Specify 'frad' as protocol type.
-Now you can bring this interface up by saying 'ifconfig comx0 up' (or whatever
-you've named the interface). Do not assign any IP address to this interface
-and do not set any routes through it.
-Then, set up your DLCIs the following way: create a comx interface for each
-DLCI you intend to use (with mkdir), and write 'dlci' to the 'boardtype' file,
-and 'ietf-ip' to the 'protocol' file. Currently, the only supported
-encapsulation type is this (also called as RFC1294/1490 IP encapsulation).
-Write the DLCI number to the 'dlci' file, and write the name of the physical
-COMX device to the file called 'master'.
-Now you can assign an IP address to this interface and set routes using it.
-See the example file for further info and example config script.
-Notes: this driver implements a DTE interface with partially implemented
-Q933a LMI.
-You can find an extensively commented example in the 'etc' directory.
-
-FURTHER /proc FILES
-
-boardtype:
-Type of the hardware. Valid values are:
- 'comx', 'hicomx', 'locomx', 'cmx', 'slicecom'.
-
-protocol:
-Data-link protocol on this channel. Can be: HDLC, LAPB, PPP, FRAD
-
-status:
-You can read the channel's actual status from the 'status' file, for example
-'cat /proc/comx/comx3/status'.
-
-lineup_delay:
-Interpreted in seconds (default is 1). Used to avoid line jitter: the system
-will consider the line status 'UP' only if it is up for at least this number
-of seconds.
-
-debug:
-You can set various debug options through this file. Valid options are:
-'comx_events', 'comx_tx', 'comx_rx', 'hw_events', 'hw_tx', 'hw_rx'.
-You can enable a debug options by writing its name prepended by a '+' into
-the debug file, for example 'echo +comx_rx >comx0/debug'.
-Disabling an option happens similarly, use the '-' prefix
-(e.g. 'echo -hw_rx >debug').
-Debug results can be read from the debug file, for example:
-tail -f /proc/comx/comx2/debug
-
-
diff --git a/Documentation/networking/slicecom.hun b/Documentation/networking/slicecom.hun
deleted file mode 100644
index bed2f04..0000000
--- a/Documentation/networking/slicecom.hun
+++ /dev/null
@@ -1,371 +0,0 @@
-
-SliceCOM adapter felhasznaloi dokumentacioja - 0.51 verziohoz
-
-Bartók István <bartoki@itc.hu>
-Utolso modositas: Wed Aug 29 17:26:58 CEST 2001
-
------------------------------------------------------------------
-
-Hasznalata:
-
-Forditas:
-
-Code maturity level options
- [*] Prompt for development and/or incomplete code/drivers
-
-Network device support
- Wan interfaces
- <M> MultiGate (COMX) synchronous
- <M> Support for MUNICH based boards: SliceCOM, PCICOM (NEW)
- <M> Support for HDLC and syncPPP...
-
-
-A modulok betoltese:
-
-modprobe comx
-
-modprobe comx-proto-ppp # a Cisco-HDLC es a SyncPPP protokollt is
- # ez a modul adja
-
-modprobe comx-hw-munich # a modul betoltodeskor azonnal jelent a
- # syslogba a detektalt kartyakrol
-
-
-Konfiguralas:
-
-# Ezen az interfeszen Cisco-HDLC vonali protokoll fog futni
-# Az interfeszhez rendelt idoszeletek: 1,2 (128 kbit/sec-es vonal)
-# (a G.703 keretben az elso adatot vivo idoszelet az 1-es)
-#
-mkdir /proc/comx/comx0.1/
-echo slicecom >/proc/comx/comx0.1/boardtype
-echo hdlc >/proc/comx/comx0.1/protocol
-echo 1 2 >/proc/comx/comx0.1/timeslots
-
-
-# Ezen az interfeszen SyncPPP vonali protokoll fog futni
-# Az interfeszhez rendelt idoszelet: 3 (64 kbit/sec-es vonal)
-#
-mkdir /proc/comx/comx0.2/
-echo slicecom >/proc/comx/comx0.2/boardtype
-echo ppp >/proc/comx/comx0.2/protocol
-echo 3 >/proc/comx/comx0.2/timeslots
-
-...
-
-ifconfig comx0.1 up
-ifconfig comx0.2 up
-
------------------------------------------------------------------
-
-A COMX driverek default 20 csomagnyi transmit queue-t rendelnek a halozati
-interfeszekhez. WAN halozatokban ennel hosszabbat is szokas hasznalni
-(20 es 100 kozott), hogy a vonal kihasznaltsaga nagy terheles eseten jobb
-legyen (bar ezzel megno a varhato kesleltetes a csomagok sorban allasa miatt):
-
-# ifconfig comx0 txqueuelen 50
-
-Ezt a beallitasi lehetoseget csak az ujabb disztribuciok ifconfig parancsa
-tamogatja (amik mar a 2.2 kernelekhez keszultek, mint a RedHat 6.1 vagy a
-Debian 2.2).
-
-A 2.1-es Debian disztribuciohoz a http://www.debian.org/~rcw/2.2/netbase/
-cimrol toltheto le ujabb netbase csomag, ami mar ilyet tamogato ifconfig
-parancsot tartalmaz. Bovebben a 2.2 kernel hasznalatarol Debian 2.1 alatt:
-http://www.debian.org/releases/stable/running-kernel-2.2
-
------------------------------------------------------------------
-
-A kartya LED-jeinek jelentese:
-
-piros - eg, ha Remote Alarm-ot kuld a tuloldal
-zold - eg, ha a vett jelben megtalalja a keretszinkront
-
-Reszletesebben:
-
-piros: zold: jelentes:
-
-- - nincs keretszinkron (nincs jel, vagy rossz a jel)
-- eg "minden rendben"
-eg eg a vetel OK, de a tuloldal Remote Alarm-ot kuld
-eg - ez nincs ertelmezve, egyelore funkcio nelkul
-
------------------------------------------------------------------
-
-Reszletesebb leiras a hardver beallitasi lehetosegeirol:
-
-Az altalanos,- es a protokoll-retegek beallitasi lehetosegeirol a 'comx.txt'
-fajlban leirtak SliceCOM kartyanal is ervenyesek, itt csak a hardver-specifikus
-beallitasi lehetosegek vannak osszefoglalva:
-
-Konfiguralasi interfesz a /proc/comx/ alatt:
-
-Minden timeslot-csoportnak kulon comx* interfeszt kell letrehozni mkdir-rel:
-comx0, comx1, .. stb. Itt beallithato, hogy az adott interfesz hanyadik kartya
-melyik timeslotja(i)bol alljon ossze. A Cisco-fele serial3:1 elnevezesek
-(serial3:1 = a 3. kartyaban az 1-es idoszelet-csoport) Linuxon aliasing-ot
-jelentenenek, ezert mi nem tudunk ilyen elnevezest hasznalni.
-
-Tobb kartya eseten a comx0.1, comx0.2, ... vagy slice0.1, slice0.2 nevek
-hasznalhatoak.
-
-Tobb SliceCOM kartya is lehet egy gepben, de sajat interrupt kell mindegyiknek,
-nem tud meg megosztott interruptot kezelni.
-
-Az egesz kartyat erinto beallitasok:
-
-Az ioport es irq beallitas nincs: amit a PCI BIOS kioszt a rendszernek,
-azt hasznalja a driver.
-
-
-comx0/boardnum - hanyadik SliceCOM kartya a gepben (a 'termeszetes' PCI
- sorrendben ertve: ahogyan a /proc/pci-ban vagy az 'lspci'
- kimeneteben megjelenik, altalaban az alaplapi PCI meghajto
- aramkorokhoz kozelebb eso kartyak a kisebb sorszamuak)
-
- Default: 0 (0-tol kezdodik a szamolas)
-
-
-Bar a kovetkezoket csak egy-egy interfeszen allitjuk at, megis az egesz kartya
-mukodeset egyszerre allitjak. A megkotes hogy csak UP-ban levo interfeszen
-hasznalhatoak, azert van, mert kulonben nem vart eredmenyekre vezetne egy ilyen
-paranccsorozat:
-
- echo 0 >boardnum
- echo internal >clock_source
- echo 1 >boardnum
-
-- Ez a 0-s board clock_source-at allitana at.
-
-Ezek a beallitasok megmaradnak az osszes interfesz torlesekor, de torlodnek
-a driver modul ki/betoltesekor.
-
-
-comx0/clock_source - A Tx orajelforrasa, a Cisco-val hasonlatosra keszult.
- Hasznalata:
-
- papaya:# echo line >/proc/comx/comx0/clock_source
- papaya:# echo internal >/proc/comx/comx0/clock_source
-
- line - A Tx orajelet a vett adatfolyambol dekodolja, igyekszik
- igazodni hozza. Ha nem lat orajelet az inputon, akkor
- atall a sajat orajelgeneratorara.
- internal - A Tx orajelet a sajat orajelgeneratora szolgaltatja.
-
- Default: line
-
- Normal osszeallitas eseten a tavkozlesi szolgaltato eszkoze
- (pl. HDSL modem) adja az orajelet, ezert ez a default.
-
-
-comx0/framing - A CRC4 ki/be kapcsolasa
-
- A CRC4: 16 PCM keretet (A PCM keret az, amibe a 32 darab 64
- kilobites csatorna van bemultiplexalva. Nem osszetevesztendo a HDLC
- kerettel.) 2x8 -as csoportokra osztanak, es azokhoz 4-4 bites CRC-t
- szamolnak. Elsosorban a vonal minosegenek a monitorozasara szolgal.
-
- papaya:~# echo crc4 >/proc/comx/comx0/framing
- papaya:~# echo no-crc4 >/proc/comx/comx0/framing
-
- Default a 'crc4', a MATAV vonalak altalaban igy futnak. De ha nem
- egyforma is a beallitas a vonal ket vegen, attol a forgalom altalaban
- at tud menni.
-
-
-comx0/linecode - A vonali kodolas beallitasa
-
- papaya:~# echo hdb3 >/proc/comx/comx0/linecode
- papaya:~# echo ami >/proc/comx/comx0/linecode
-
- Default a 'hdb3', a MATAV vonalak igy futnak.
-
- (az AMI kodolas igen ritka E1-es vonalaknal). Ha ez a beallitas nem
- egyezik a vonal ket vegen, akkor elofordulhat hogy a keretszinkron
- osszejon, de CRC4-hibak es a vonalakon atvitt adatokban is hibak
- keletkeznek (amit a HDLC/SyncPPP szinten CRC-hibaval jelez)
-
-
-comx0/reg - a kartya aramkoreinek, a MUNICH (reg) es a FALC (lbireg)
-comx0/lbireg regisztereinek kozvetlen elerese. Hasznalata:
-
- echo >reg 0x04 0x0 - a 4-es regiszterbe 0-t ir
- echo >reg 0x104 - printk()-val kiirja a 4-es regiszter
- tartalmat a syslogba.
-
- WARNING: ezek csak a fejleszteshez keszultek, sok galibat
- lehet veluk okozni!
-
-
-comx0/loopback - A kartya G.703 jelenek a visszahurkolasara is van lehetoseg:
-
- papaya:# echo none >/proc/comx/comx0/loopback
- papaya:# echo local >/proc/comx/comx0/loopback
- papaya:# echo remote >/proc/comx/comx0/loopback
-
- none - nincs visszahurkolas, normal mukodes
- local - a kartya a sajat maga altal adott jelet kapja vissza
- remote - a kartya a kivulrol vett jelet adja kifele
-
- Default: none
-
------------------------------------------------------------------
-
-Az interfeszhez (Cisco terminologiaban 'channel-group') kapcsolodo beallitasok:
-
-comx0/timeslots - mely timeslotok (idoszeletek) tartoznak az adott interfeszhez.
-
- papaya:~# cat /proc/comx/comx0/timeslots
- 1 3 4 5 6
- papaya:~#
-
- Egy timeslot megkeresese (hanyas interfeszbe tartozik nalunk):
-
- papaya:~# grep ' 4' /proc/comx/comx*/timeslots
- /proc/comx/comx0/timeslots:1 3 4 5 6
- papaya:~#
-
- Beallitasa:
- papaya:~# echo '1 5 2 6 7 8' >/proc/comx/comx0/timeslots
-
- A timeslotok sorrendje nem szamit, '1 3 2' ugyanaz mint az '1 2 3'.
-
- Beallitashoz az adott interfesznek DOWN-ban kell lennie
- (ifconfig comx0 down), de ugyanannak a kartyanak a tobbi interfesze
- uzemelhet kozben.
-
- Beallitaskor leellenorzi, hogy az uj timeslotok nem utkoznek-e egy
- masik interfesz timeslotjaival. Ha utkoznek, akkor nem allitja at.
-
- Mindig 10-es szamrendszerben tortenik a timeslotok ertelmezese, nehogy
- a 08, 09 alaku felirast rosszul ertelmezze.
-
------------------------------------------------------------------
-
-Az interfeszek es a kartya allapotanak lekerdezese:
-
-- A ' '-szel kezdodo sorok az eredeti kimenetet, a //-rel kezdodo sorok a
-magyarazatot jelzik.
-
- papaya:~$ cat /proc/comx/comx1/status
- Interface administrative status is UP, modem status is UP, protocol is UP
- Modem status changes: 0, Transmitter status is IDLE, tbusy: 0
- Interface load (input): 978376 / 947808 / 951024 bits/s (5s/5m/15m)
- (output): 978376 / 947848 / 951024 bits/s (5s/5m/15m)
- Debug flags: none
- RX errors: len: 22, overrun: 1, crc: 0, aborts: 0
- buffer overrun: 0, pbuffer overrun: 0
- TX errors: underrun: 0
- Line keepalive (value: 10) status UP [0]
-
-// Itt kezdodik a hardver-specifikus resz:
- Controller status:
- No alarms
-
-// Alarm: hibajelzes:
-//
-// No alarms - minden rendben
-//
-// LOS - Loss Of Signal - nem erzekel jelet a bemeneten.
-// AIS - Alarm Indication Signal - csak egymas utani 1-esek jonnek
-// a bemeneten, a tuloldal igy is jelezheti hogy meghibasodott vagy
-// nincs inicializalva.
-// AUXP - Auxiliary Pattern Indication - 01010101.. sorozat jon a bemeneten.
-// LFA - Loss of Frame Alignment - nincs keretszinkron
-// RRA - Receive Remote Alarm - a tuloldal el, de hibat jelez.
-// LMFA - Loss of CRC4 Multiframe Alignment - nincs CRC4-multikeret-szinkron
-// NMF - No Multiframe alignment Found after 400 msec - ilyen alarm a no-crc4
-// es crc4 keretezesek eseten nincs, lasd lentebb
-//
-// Egyeb lehetseges hibajelzesek:
-//
-// Transmit Line Short - a kartya ugy erzi hogy az adasi kimenete rovidre
-// van zarva, ezert kikapcsolta az adast. (nem feltetlenul veszi eszre
-// a kulso rovidzarat)
-
-// A veteli oldal csomagjainak lancolt listai, debug celokra:
-
- Rx ring:
- rafutott: 0
- lastcheck: 50845731, jiffies: 51314281
- base: 017b1858
- rx_desc_ptr: 0
- rx_desc_ptr: 017b1858
- hw_curr_ptr: 017b1858
- 06040000 017b1868 017b1898 c016ff00
- 06040000 017b1878 017b1e9c c016ff00
- 46040000 017b1888 017b24a0 c016ff00
- 06040000 017b1858 017b2aa4 c016ff00
-
-// A kartyat hasznalo tobbi interfesz: a 0-s channel-group a comx1 interfesz,
-// es az 1,2,...,16 timeslotok tartoznak hozza:
-
- Interfaces using this board: (channel-group, interface, timeslots)
- 0 comx1: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
- 1 comx2: 17
- 2 comx3: 18
- 3 comx4: 19
- 4 comx5: 20
- 5 comx6: 21
- 6 comx7: 22
- 7 comx8: 23
- 8 comx9: 24
- 9 comx10: 25
- 10 comx11: 26
- 11 comx12: 27
- 12 comx13: 28
- 13 comx14: 29
- 14 comx15: 30
- 15 comx16: 31
-
-// Hany esemenyt kezelt le a driver egy-egy hardver-interrupt kiszolgalasanal:
-
- Interrupt work histogram:
- hist[ 0]: 0 hist[ 1]: 2 hist[ 2]: 18574 hist[ 3]: 79
- hist[ 4]: 14 hist[ 5]: 1 hist[ 6]: 0 hist[ 7]: 1
- hist[ 8]: 0 hist[ 9]: 7
-
-// Hany kikuldendo csomag volt mar a Tx-ringben amikor ujabb lett irva bele:
-
- Tx ring histogram:
- hist[ 0]: 2329 hist[ 1]: 0 hist[ 2]: 0 hist[ 3]: 0
-
-// Az E1-interfesz hiba-szamlaloi, az rfc2495-nek megfeleloen:
-// (kb. a Cisco routerek "show controllers e1" formatumaban: http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/rbook/rinterfc.htm#xtocid25669126)
-
-Data in current interval (91 seconds elapsed):
- 9516 Line Code Violations, 65 Path Code Violations, 2 E-Bit Errors
- 0 Slip Secs, 2 Fr Loss Secs, 2 Line Err Secs, 0 Degraded Mins
- 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 11 Unavail Secs
-Data in Interval 1 (15 minutes):
- 0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
- 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
- 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
-Data in last 4 intervals (1 hour):
- 0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
- 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
- 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
-Data in last 96 intervals (24 hours):
- 0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
- 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
- 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
-
------------------------------------------------------------------
-
-Nehany kulonlegesebb beallitasi lehetoseg (idovel beepulhetnek majd a driverbe):
-Ezekkel sok galibat lehet okozni, nagyon ovatosan kell oket hasznalni!
-
- modified CRC-4, for improved interworking of CRC-4 and non-CRC-4
- devices: (lasd page 107 es g706 Annex B)
- lbireg[ 0x1b ] |= 0x08
- lbireg[ 0x1c ] |= 0xc0
- - ilyenkor ertelmezett az NMF - 'No Multiframe alignment Found after
- 400 msec' alarm.
-
- FALC - a vonali meghajto IC
- local loop - a sajat adasomat halljam vissza
- remote loop - a kivulrol jovo adast adom vissza
-
- Egy hibakeresesre hasznalhato dolog:
- - 1-es timeslot local loop a FALC-ban: echo >lbireg 0x1d 0x21
- - local loop kikapcsolasa: echo >lbireg 0x1d 0x00
diff --git a/Documentation/networking/slicecom.txt b/Documentation/networking/slicecom.txt
deleted file mode 100644
index c82c0cf..0000000
--- a/Documentation/networking/slicecom.txt
+++ /dev/null
@@ -1,369 +0,0 @@
-
-SliceCOM adapter user's documentation - for the 0.51 driver version
-
-Written by Bartók István <bartoki@itc.hu>
-
-English translation: Lakatos György <gyuri@itc.hu>
-Mon Dec 11 15:28:42 CET 2000
-
-Last modified: Wed Aug 29 17:25:37 CEST 2001
-
------------------------------------------------------------------
-
-Usage:
-
-Compiling the kernel:
-
-Code maturity level options
- [*] Prompt for development and/or incomplete code/drivers
-
-Network device support
- Wan interfaces
- <M> MultiGate (COMX) synchronous
- <M> Support for MUNICH based boards: SliceCOM, PCICOM (NEW)
- <M> Support for HDLC and syncPPP...
-
-
-Loading the modules:
-
-modprobe comx
-
-modprobe comx-proto-ppp # module for Cisco-HDLC and SyncPPP protocols
-
-modprobe comx-hw-munich # the module logs information by the kernel
- # about the detected boards
-
-
-Configuring the board:
-
-# This interface will use the Cisco-HDLC line protocol,
-# the timeslices assigned are 1,2 (128 KiBit line speed)
-# (the first data timeslice in the G.703 frame is no. 1)
-#
-mkdir /proc/comx/comx0.1/
-echo slicecom >/proc/comx/comx0.1/boardtype
-echo hdlc >/proc/comx/comx0.1/protocol
-echo 1 2 >/proc/comx/comx0.1/timeslots
-
-
-# This interface uses SyncPPP line protocol, the assigned
-# is no. 3 (64 KiBit line speed)
-#
-mkdir /proc/comx/comx0.2/
-echo slicecom >/proc/comx/comx0.2/boardtype
-echo ppp >/proc/comx/comx0.2/protocol
-echo 3 >/proc/comx/comx0.2/timeslots
-
-...
-
-ifconfig comx0.1 up
-ifconfig comx0.2 up
-
------------------------------------------------------------------
-
-The COMX interfaces use a 10 packet transmit queue by default, however WAN
-networks sometimes use bigger values (20 to 100), to utilize the line better
-by large traffic (though the line delay increases because of more packets
-join the queue).
-
-# ifconfig comx0 txqueuelen 50
-
-This option is only supported by the ifconfig command of the later
-distributions, which came with 2.2 kernels, such as RedHat 6.1 or Debian 2.2.
-
-You can download a newer netbase packet from
-http://www.debian.org/~rcw/2.2/netbase/ for Debian 2.1, which has a new
-ifconfig. You can get further information about using 2.2 kernel with
-Debian 2.1 from http://www.debian.org/releases/stable/running-kernel-2.2
-
------------------------------------------------------------------
-
-The SliceCom LEDs:
-
-red - on, if the interface is unconfigured, or it gets Remote Alarm-s
-green - on, if the board finds frame-sync in the received signal
-
-A bit more detailed:
-
-red: green: meaning:
-
-- - no frame-sync, no signal received, or signal SNAFU.
-- on "Everything is OK"
-on on Reception is ok, but the remote end sends Remote Alarm
-on - The interface is unconfigured
-
------------------------------------------------------------------
-
-A more detailed description of the hardware setting options:
-
-The general and the protocol layer options described in the 'comx.txt' file
-apply to the SliceCom as well, I only summarize the SliceCom hardware specific
-settings below.
-
-The '/proc/comx' configuring interface:
-
-An interface directory should be created for every timeslot group with
-'mkdir', e,g: 'comx0', 'comx1' etc. The timeslots can be assigned here to the
-specific interface. The Cisco-like naming convention (serial3:1 - first
-timeslot group of the 3rd. board) can't be used here, because these mean IP
-aliasing in Linux.
-
-You can give any meaningful name to keep the configuration clear;
-e.g: 'comx0.1', 'comx0.2', 'comx1.1', comx1.2', if you have two boards
-with two interfaces each.
-
-Settings, which apply to the board:
-
-Neither 'io' nor 'irq' settings required, the driver uses the resources
-given by the PCI BIOS.
-
-comx0/boardnum - board number of the SliceCom in the PC (using the 'natural'
- PCI order) as listed in '/proc/pci' or the output of the
- 'lspci' command, generally the slots nearer to the motherboard
- PCI driver chips have the lower numbers.
-
- Default: 0 (the counting starts with 0)
-
-Though the options below are to be set on a single interface, they apply to the
-whole board. The restriction, to use them on 'UP' interfaces, is because the
-command sequence below could lead to unpredictable results.
-
- # echo 0 >boardnum
- # echo internal >clock_source
- # echo 1 >boardnum
-
-The sequence would set the clock source of board 0.
-
-These settings will persist after all the interfaces are cleared, but are
-cleared when the driver module is unloaded and loaded again.
-
-comx0/clock_source - source of the transmit clock
- Usage:
-
- # echo line >/proc/comx/comx0/clock_source
- # echo internal >/proc/comx/comx0/clock_source
-
- line - The Tx clock is being decoded if the input data stream,
- if no clock seen on the input, then the board will use it's
- own clock generator.
-
- internal - The Tx clock is supplied by the builtin clock generator.
-
- Default: line
-
- Normally, the telecommunication company's end device (the HDSL
- modem) provides the Tx clock, that's why 'line' is the default.
-
-comx0/framing - Switching CRC4 off/on
-
- CRC4: 16 PCM frames (The 32 64Kibit channels are multiplexed into a
- PCM frame, nothing to do with HDLC frames) are divided into 2x8
- groups, each group has a 4 bit CRC.
-
- # echo crc4 >/proc/comx/comx0/framing
- # echo no-crc4 >/proc/comx/comx0/framing
-
- Default is 'crc4', the Hungarian MATAV lines behave like this.
- The traffic generally passes if this setting on both ends don't match.
-
-comx0/linecode - Setting the line coding
-
- # echo hdb3 >/proc/comx/comx0/linecode
- # echo ami >/proc/comx/comx0/linecode
-
- Default a 'hdb3', MATAV lines use this.
-
- (AMI coding is rarely used with E1 lines). Frame sync may occur, if
- this setting doesn't match the other end's, but CRC4 and data errors
- will come, which will result in CRC errors on HDLC/SyncPPP level.
-
-comx0/reg - direct access to the board's MUNICH (reg) and FALC (lbireg)
-comx0/lbireg circuit's registers
-
- # echo >reg 0x04 0x0 - write 0 to register 4
- # echo >reg 0x104 - write the contents of register 4 with
- printk() to syslog
-
-WARNING! These are only for development purposes, messing with this will
- result much trouble!
-
-comx0/loopback - Places a loop to the board's G.703 signals
-
- # echo none >/proc/comx/comx0/loopback
- # echo local >/proc/comx/comx0/loopback
- # echo remote >/proc/comx/comx0/loopback
-
- none - normal operation, no loop
- local - the board receives it's own output
- remote - the board sends the received data to the remote side
-
- Default: none
-
------------------------------------------------------------------
-
-Interface (channel group in Cisco terms) settings:
-
-comx0/timeslots - which timeslots belong to the given interface
-
- Setting:
-
- # echo '1 5 2 6 7 8' >/proc/comx/comx0/timeslots
-
- # cat /proc/comx/comx0/timeslots
- 1 2 5 6 7 8
- #
-
- Finding a timeslot:
-
- # grep ' 4' /proc/comx/comx*/timeslots
- /proc/comx/comx0/timeslots:1 3 4 5 6
- #
-
- The timeslots can be in any order, '1 2 3' is the same as '1 3 2'.
-
- The interface has to be DOWN during the setting ('ifconfig comx0
- down'), but the other interfaces could operate normally.
-
- The driver checks if the assigned timeslots are vacant, if not, then
- the setting won't be applied.
-
- The timeslot values are treated as decimal numbers, not to misunderstand
- values of 08, 09 form.
-
------------------------------------------------------------------
-
-Checking the interface and board status:
-
-- Lines beginning with ' ' (space) belong to the original output, the lines
-which begin with '//' are the comments.
-
- papaya:~$ cat /proc/comx/comx1/status
- Interface administrative status is UP, modem status is UP, protocol is UP
- Modem status changes: 0, Transmitter status is IDLE, tbusy: 0
- Interface load (input): 978376 / 947808 / 951024 bits/s (5s/5m/15m)
- (output): 978376 / 947848 / 951024 bits/s (5s/5m/15m)
- Debug flags: none
- RX errors: len: 22, overrun: 1, crc: 0, aborts: 0
- buffer overrun: 0, pbuffer overrun: 0
- TX errors: underrun: 0
- Line keepalive (value: 10) status UP [0]
-
-// The hardware specific part starts here:
- Controller status:
- No alarms
-
-// Alarm:
-//
-// No alarms - Everything OK
-//
-// LOS - Loss Of Signal - No signal sensed on the input
-// AIS - Alarm Indication Signal - The remote side sends '11111111'-s,
-// it tells, that there's an error condition, or it's not
-// initialised.
-// AUXP - Auxiliary Pattern Indication - 01010101.. received.
-// LFA - Loss of Frame Alignment - no frame sync received.
-// RRA - Receive Remote Alarm - the remote end's OK, but signals error cond.
-// LMFA - Loss of CRC4 Multiframe Alignment - no CRC4 multiframe sync.
-// NMF - No Multiframe alignment Found after 400 msec - no such alarm using
-// no-crc4 or crc4 framing, see below.
-//
-// Other possible error messages:
-//
-// Transmit Line Short - the board felt, that it's output is short-circuited,
-// so it switched the transmission off. (The board can't definitely tell,
-// that it's output is short-circuited.)
-
-// Chained list of the received packets, for debug purposes:
-
- Rx ring:
- rafutott: 0
- lastcheck: 50845731, jiffies: 51314281
- base: 017b1858
- rx_desc_ptr: 0
- rx_desc_ptr: 017b1858
- hw_curr_ptr: 017b1858
- 06040000 017b1868 017b1898 c016ff00
- 06040000 017b1878 017b1e9c c016ff00
- 46040000 017b1888 017b24a0 c016ff00
- 06040000 017b1858 017b2aa4 c016ff00
-
-// All the interfaces using the board: comx1, using the 1,2,...16 timeslots,
-// comx2, using timeslot 17, etc.
-
- Interfaces using this board: (channel-group, interface, timeslots)
- 0 comx1: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
- 1 comx2: 17
- 2 comx3: 18
- 3 comx4: 19
- 4 comx5: 20
- 5 comx6: 21
- 6 comx7: 22
- 7 comx8: 23
- 8 comx9: 24
- 9 comx10: 25
- 10 comx11: 26
- 11 comx12: 27
- 12 comx13: 28
- 13 comx14: 29
- 14 comx15: 30
- 15 comx16: 31
-
-// The number of events handled by the driver during an interrupt cycle:
-
- Interrupt work histogram:
- hist[ 0]: 0 hist[ 1]: 2 hist[ 2]: 18574 hist[ 3]: 79
- hist[ 4]: 14 hist[ 5]: 1 hist[ 6]: 0 hist[ 7]: 1
- hist[ 8]: 0 hist[ 9]: 7
-
-// The number of packets to send in the Tx ring, when a new one arrived:
-
- Tx ring histogram:
- hist[ 0]: 2329 hist[ 1]: 0 hist[ 2]: 0 hist[ 3]: 0
-
-// The error counters of the E1 interface, according to the RFC2495,
-// (similar to the Cisco "show controllers e1" command's output:
-// http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/rbook/rinterfc.htm#xtocid25669126)
-
-Data in current interval (91 seconds elapsed):
- 9516 Line Code Violations, 65 Path Code Violations, 2 E-Bit Errors
- 0 Slip Secs, 2 Fr Loss Secs, 2 Line Err Secs, 0 Degraded Mins
- 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 11 Unavail Secs
-Data in Interval 1 (15 minutes):
- 0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
- 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
- 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
-Data in last 4 intervals (1 hour):
- 0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
- 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
- 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
-Data in last 96 intervals (24 hours):
- 0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
- 0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
- 0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
-
------------------------------------------------------------------
-
-Some unique options, (may get into the driver later):
-Treat them very carefully, these can cause much trouble!
-
- modified CRC-4, for improved interworking of CRC-4 and non-CRC-4
- devices: (see page 107 and g706 Annex B)
- lbireg[ 0x1b ] |= 0x08
- lbireg[ 0x1c ] |= 0xc0
-
- - The NMF - 'No Multiframe alignment Found after 400 msec' alarm
- comes into account.
-
- FALC - the line driver chip.
- local loop - I hear my transmission back.
- remote loop - I echo the remote transmission back.
-
- Something useful for finding errors:
-
- - local loop for timeslot 1 in the FALC chip:
-
- # echo >lbireg 0x1d 0x21
-
- - Switching the loop off:
-
- # echo >lbireg 0x1d 0x00
^ permalink raw reply related
* [2.6 patch] remove Documentation/networking/Configurable
From: Adrian Bunk @ 2007-11-05 17:05 UTC (permalink / raw)
To: netdev, linux-kernel
After more than 11 years this file does no longer contain much useful
information.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
Documentation/networking/00-INDEX | 2 -
Documentation/networking/Configurable | 34 --------------------------
2 files changed, 36 deletions(-)
f200fa4962996e11967e7c1040771b6669829fca
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index c48892e..a9f4acc 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -4,8 +4,6 @@
- information on the 3Com EtherLink Plus (3c505) driver.
6pack.txt
- info on the 6pack protocol, an alternative to KISS for AX.25
-Configurable
- - info on some of the configurable network parameters
DLINK.txt
- info on the D-Link DE-600/DE-620 parallel port pocket adapters
PLIP.txt
diff --git a/Documentation/networking/Configurable b/Documentation/networking/Configurable
deleted file mode 100644
index 69c0dd4..0000000
--- a/Documentation/networking/Configurable
+++ /dev/null
@@ -1,34 +0,0 @@
-
-There are a few network parameters that can be tuned to better match
-the kernel to your system hardware and intended usage. The defaults
-are usually a good choice for 99% of the people 99% of the time, but
-you should be aware they do exist and can be changed.
-
-The current list of parameters can be found in the files:
-
- linux/net/TUNABLE
- Documentation/networking/ip-sysctl.txt
-
-Some of these are accessible via the sysctl interface, and many more are
-scheduled to be added in this way. For example, some parameters related
-to Address Resolution Protocol (ARP) are very easily viewed and altered.
-
- # cat /proc/sys/net/ipv4/arp_timeout
- 6000
- # echo 7000 > /proc/sys/net/ipv4/arp_timeout
- # cat /proc/sys/net/ipv4/arp_timeout
- 7000
-
-Others are already accessible via the related user space programs.
-For example, MAX_WINDOW has a default of 32 k which is a good choice for
-modern hardware, but if you have a slow (8 bit) Ethernet card and/or a slow
-machine, then this will be far too big for the card to keep up with fast
-machines transmitting on the same net, resulting in overruns and receive errors.
-A value of about 4 k would be more appropriate, which can be set via:
-
- # route add -net 192.168.3.0 window 4096
-
-The remainder of these can only be presently changed by altering a #define
-in the related header file. This means an edit and recompile cycle.
-
- Paul Gortmaker 06/96
^ permalink raw reply related
* [2.6 patch] remove Documentation/networking/pt.txt
From: Adrian Bunk @ 2007-11-05 17:05 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, linux-kernel
There's no no point in keeping documentation for a driver that was
removed many years ago.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
Documentation/networking/00-INDEX | 2 -
Documentation/networking/pt.txt | 58 ------------------------------
2 files changed, 60 deletions(-)
cfe9580e99bc2406a5a05bae24487ca84619bec7
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index 9c64042..5e21f37 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -80,6 +80,4 @@ olympic.txt
policy-routing.txt
- IP policy-based routing
-pt.txt
- - the Gracilis Packetwin AX.25 device driver
ray_cs.txt
- Raylink Wireless LAN card driver info.
diff --git a/Documentation/networking/pt.txt b/Documentation/networking/pt.txt
deleted file mode 100644
index 72e888c..0000000
--- a/Documentation/networking/pt.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-This is the README for the Gracilis Packetwin device driver, version 0.5
-ALPHA for Linux 1.3.43.
-
-These files will allow you to talk to the PackeTwin (now know as PT) and
-connect through it just like a pair of TNCs. To do this you will also
-require the AX.25 code in the kernel enabled.
-
-There are four files in this archive; this readme, a patch file, a .c file
-and finally a .h file. The two program files need to be put into the
-drivers/net directory in the Linux source tree, for me this is the
-directory /usr/src/linux/drivers/net. The patch file needs to be patched in
-at the top of the Linux source tree (/usr/src/linux in my case).
-
-You will most probably have to edit the pt.c file to suit your own setup,
-this should just involve changing some of the defines at the top of the file.
-Please note that if you run an external modem you must specify a speed of 0.
-
-The program is currently setup to run a 4800 baud external modem on port A
-and a Kantronics DE-9600 daughter board on port B so if you have this (or
-something similar) then you're right.
-
-To compile in the driver, put the files in the correct place and patch in
-the diff. You will have to re-configure the kernel again before you
-recompile it.
-
-The driver is not real good at the moment for finding the card. You can
-'help' it by changing the order of the potential addresses in the structure
-found in the pt_init() function so the address of where the card is is put
-first.
-
-After compiling, you have to get them going, they are pretty well like any
-other net device and just need ifconfig to get them going.
-As an example, here is my /etc/rc.net
---------------------------
-
-#
-# Configure the PackeTwin, port A.
-/sbin/ifconfig pt0a 44.136.8.87 hw ax25 vk2xlz mtu 512
-/sbin/ifconfig pt0a 44.136.8.87 broadcast 44.136.8.255 netmask 255.255.255.0
-/sbin/route add -net 44.136.8.0 netmask 255.255.255.0 dev pt0a
-/sbin/route add -net 44.0.0.0 netmask 255.0.0.0 gw 44.136.8.68 dev pt0a
-/sbin/route add -net 138.25.16.0 netmask 255.255.240.0 dev pt0a
-/sbin/route add -host 44.136.8.255 dev pt0a
-#
-# Configure the PackeTwin, port B.
-/sbin/ifconfig pt0b 44.136.8.87 hw ax25 vk2xlz-1 mtu 512
-/sbin/ifconfig pt0b 44.136.8.87 broadcast 44.255.255.255 netmask 255.0.0.0
-/sbin/route add -host 44.136.8.216 dev pt0b
-/sbin/route add -host 44.136.8.95 dev pt0b
-/sbin/route add -host 44.255.255.255 dev pt0b
-
-This version of the driver comes under the GNU GPL. If you have one of my
-previous (non-GPL) versions of the driver, please update to this one.
-
-I hope that this all works well for you. I would be pleased to hear how
-many people use the driver and if it does its job.
-
- - Craig vk2xlz <csmall@small.dropbear.id.au>
^ permalink raw reply related
* [2.6 patch] remove Documentation/networking/ncsa-telnet
From: Adrian Bunk @ 2007-11-05 17:05 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Pekka Pietikainen
Newsflash: There once was a version of NCSA telnet that had some bug.
Spotted by Pekka Pietikainen.
Signed-off-by: Adrian Bunk <bunk@kernel.org>
---
Documentation/networking/00-INDEX | 2 --
Documentation/networking/ncsa-telnet | 16 ----------------
2 files changed, 18 deletions(-)
b9ccc5424cc83b4c0ca9c8d380a4b7567916a463
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index a9f4acc..9c64042 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -74,8 +74,6 @@ ltpc.txt
- the Apple or Farallon LocalTalk PC card driver
multicast.txt
- Behaviour of cards under Multicast
-ncsa-telnet
- - notes on how NCSA telnet (DOS) breaks with MTU discovery enabled.
netdevices.txt
- info on network device driver functions exported to the kernel.
olympic.txt
diff --git a/Documentation/networking/ncsa-telnet b/Documentation/networking/ncsa-telnet
deleted file mode 100644
index d77d28b..0000000
--- a/Documentation/networking/ncsa-telnet
+++ /dev/null
@@ -1,16 +0,0 @@
-NCSA telnet doesn't work with path MTU discovery enabled. This is due to a
-bug in NCSA that also stops it working with other modern networking code
-such as Solaris.
-
-The following information is courtesy of
-Marek <marekm@i17linuxb.ists.pwr.wroc.pl>
-
-There is a fixed version somewhere on ftp.upe.ac.za (sorry, I don't
-remember the exact pathname, and this site is very slow from here).
-It may or may not be faster for you to get it from
-ftp://ftp.ists.pwr.wroc.pl/pub/msdos/telnet/ncsa_upe/tel23074.zip
-(source is in v230704s.zip). I have tested it with 1.3.79 (with
-path mtu discovery enabled - ncsa 2.3.08 didn't work) and it seems
-to work. I don't know if anyone is working on this code - this
-version is over a year old. Too bad - it's faster and often more
-stable than these windoze telnets, and runs on almost anything...
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox