--FAD00201.896068154/wigner.cstc.org
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
The original message was received at Sun, 24 May 1998 21:12:32 +0200
from pol@wigner.cstc.org [192.168.1.2]
----- The following addresses had transient non-fatal errors -----
"|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"
(expanded from: <pol@wigner.cstc.org>)
----- Transcript of session follows -----
"|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"... Deferred
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old
--FAD00201.896068154/wigner.cstc.org
Content-Type: message/delivery-status
Reporting-MTA: dns; wigner.cstc.org
Arrival-Date: Sun, 24 May 1998 21:12:32 +0200
Final-Recipient: RFC822; <pol@wigner.cstc.org>
X-Actual-Recipient: RFC822; |exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1@wigner.cstc.org
Action: delayed
Status: 4.2.0
Last-Attempt-Date: Mon, 25 May 1998 05:49:14 +0200
Will-Retry-Until: Fri, 29 May 1998 21:12:32 +0200
--FAD00201.896068154/wigner.cstc.org
Content-Type: message/rfc822
Return-Path: <linux-kernel@vger.rutgers.edu>
Received: from wigner.cstc.org (pol@wigner.cstc.org [192.168.1.2])
by wigner.cstc.org (8.8.8/8.8.8/Debian/GNU) with ESMTP id VAA03606
for <pol@wigner.cstc.org>; Sun, 24 May 1998 21:12:32 +0200
From: linux-kernel@vger.rutgers.edu
Received: from mbox.est.it
by wigner.cstc.org (fetchmail-4.3.9 POP3)
for <pol/wigner.cstc.org> (single-drop); Sun, 24 May 1998 21:12:41 CEST
Message-ID: <294143@bbs.eureka.est.it>
To: Pumilia@mbox.est.it
Date: 24 May 1998 18:43:16 GMT +0100
Subject: linux-kernel-digest V1 #2010
linux-kernel-digest Sunday, 24 May 1998 Volume 01 : Number 2010
In this issue:
Re: SMM Mode!
Re: SB16 lockup with kernel 2.1.102/103
Re: 2.1.104-1 (and lots of older kernels): loopback mistery...
Re: Modularized net bridging PATCH against pre-2.1.104-1
Re: Poor TCP throughput in 2.1.103
EtherTap device /dev/tap0 not mentioned in devices.t*
Re: Poor TCP throughput in 2.1.103
Re: Poor TCP throughput in 2.1.103
egcs and 2.0.x
Re: Poor TCP throughput in 2.1.103
2.1.104-1 Intel EtherExpress 10/100
New Cyrix patch for 2.0.33
Re: Possible cause of "spurious APIC interrupt"
[SOUND] Aztech Sound Galaxy broken/not supported?
Re: More on smbfs - I got it working...
Re: More on smbfs - I got it working...
Re: Poor TCP throughput in 2.1.103
Re: Poor TCP throughput in 2.1.103
2.0.34p15/16 stuck sockets
Tyan 1662D new Award BIOS bugs
Re: Poor TCP throughput in 2.1.103
Re: smbfs in 2.1.x
Re: Tyan 1662D new Award BIOS bugs
Re: To Bogomips or not to Bogomips?
Re: 2.1.102: ipchains: REJECT does only DENY - network gurus please
Re: Modularized net bridging PATCH against pre-2.1.104-1
Re: 2.1.103 MSS?
Re: 2.1.102: ipchains: REJECT does only DENY - network gurus please
Re: Poor TCP throughput in 2.1.103
Re: port_t again, sorry didn't type the whole thing.
Re: Poor TCP throughput in 2.1.103
Re: Poor TCP throughput in 2.1.103
Re: Poor TCP throughput in 2.1.103
Re: Poor TCP throughput in 2.1.103
Re: Poor TCP throughput in 2.1.103
See the end of the digest for information on subscribing to the linux-kernel
or linux-kernel-digest mailing lists.
----------------------------------------------------------------------
From: Daniel.Egger@t-online.de (Daniel Egger)
Date: Sat, 23 May 1998 03:39:42 +0200
Subject: Re: SMM Mode!
On Fri, 22 May 1998, Perry Harrington wrote:
>Err, you're wrong. The Enhanced Am486 chips support the standard SMM
>2 pin interface. Have a look see at:
Sorry for my question but since I have such a chip: what does
SMM mean?
- --
Servus,
Daniel
------------------------------
From: Gert Vervoort <gert.vervoort@wxs.nl>
Date: Sun, 24 May 1998 12:18:44 -0400
Subject: Re: SB16 lockup with kernel 2.1.102/103
At 09:00 AM 5/23/98 -0700, Derrik wrote:
>On Sat, 23 May 1998, Gert Vervoort wrote:
>
>> Hi,
>>
>> When using the audio device of my soundblaster 16 ASP
>> with linux kernel version 2.1.102/103, the system locks hard.
>>
>> e.g. when I use cat someaudiofile.au >/dev/audio, the file is
>> played and after the system is ready playing the audio-file, the
>> system locks up.
>
>Well, just as a data-point, I'm running 2.1.103 (did run 2.1.102 also)
>with my SB AWE32 (pre-PnP, pre-IDE) without a problem. I've been playing
>MP3s like mad, and I've not had any problems at all. Are you running an
>SMP kernel? I heard someone mention some SB-related twitches in 2.1.102 or
>103 recently, and they were running an SMP kernel. You might check on
>that.
>
>Derrik Pates
>dpates@kalifornia.com
>dpates@acm.org
>
>
I am not running an SMP kernel. All programs using /dev/audio or /dev/dsp give
the same problem (playing wav-files, mp3's, etc.)
Midi-files are oke.
------------------------------
From: David Woodhouse <Dave@imladris.demon.co.uk>
Date: Sun, 24 May 1998 11:49:05 +0200
Subject: Re: 2.1.104-1 (and lots of older kernels): loopback mistery...
vonbrand@sleipnir.valparaiso.cl said:
> When I do a:
> ping -c 1 127.0.0.1
> *two* packets are transmitted through the loopback device.
Yep. One echo request, and the echo reply that it triggers.
If you use tcpdump to watch the lo device, you'll see each packet twice - that
is two requests and two replies. That's just because tcpdump sees both
incoming and outgoing packets, not because each packet gets sent twice.
- ---- ---- ----
David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355
Dave@imladris.demon.co.uk http://www.imladris.demon.co.uk
finger pgp@dwmw2.robinson.cam.ac.uk for PGP key.
------------------------------
From: David Woodhouse <Dave@imladris.demon.co.uk>
Date: Sun, 24 May 1998 12:02:53 +0200
Subject: Re: Modularized net bridging PATCH against pre-2.1.104-1
> +#elif defined(CONFIG_BRIDGE_MODULE)
> + if (handle_bridge_hook) (*handle_bridge_hook)(skb,type);
> #endif
Is this kind of hook permitted?
How many other modules are there that require modular support to be built into
the kernel? I know the PC Speaker does it, and I assumed that was one of the
reasons it wasn't accepted.
- ---- ---- ----
David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355
Dave@imladris.demon.co.uk http://www.imladris.demon.co.uk
finger pgp@dwmw2.robinson.cam.ac.uk for PGP key.
------------------------------
From: Shaw Carruthers <shaw@shawc.demon.co.uk>
Date: Sun, 24 May 1998 12:09:36 +0100 (GMT+0100)
Subject: Re: Poor TCP throughput in 2.1.103
On 24 May 1998, Andi Kleen wrote:
>
> Try to define CONFIG_RTNL_OLD_IFINFO in net/ipv4/fib_semantics.c
>
> It is a bit unfortunate that TCP needs this setting, it would be better if
> it would work without user tuning.
>
The problem is suspected to lie with my ISP's Ascend servers, using larger
( > 12k ) windows causing them to stall the TCP pipeline. So many other
people could have the same problem as Ascends are very popular.
Many thanks for the tip, which solves the problem.
I did:
- --- /usr/src/linux/include/linux/rtnetlink.h~ Thu May 21 10:40:27 1998
+++ /usr/src/linux/include/linux/rtnetlink.h Sat May 23 12:43:53 1998
@@ -5,7 +5,7 @@
#include <linux/netlink.h>
#define RTNL_DEBUG 1
- -/* #define CONFIG_RTNL_OLD_IFINFO 1 */
+#define CONFIG_RTNL_OLD_IFINFO 1
/****
- --
Shaw Carruthers - shaw@shawc.demon.co.uk
London SW14 7JW UK
This is not a sig( with homage to Magritte).
------------------------------
From: Tigran Aivazian <tigran@aivazian.demon.co.uk>
Date: Sun, 24 May 1998 12:23:23 +0100 (BST)
Subject: EtherTap device /dev/tap0 not mentioned in devices.t*
Hello guys,
Just to remind you that since ethertap device is in the official
source perhaps it should be documented along the route-netlink and enSKIP
devices on char major 36.
Regards,
Tigran.
------------------------------
From: ak@muc.de
Date: Sun, 24 May 1998 13:43:04 +0200
Subject: Re: Poor TCP throughput in 2.1.103
On Sun, May 24, 1998 at 01:09:36PM +0200, Shaw Carruthers wrote:
> On 24 May 1998, Andi Kleen wrote:
>
> >
> > Try to define CONFIG_RTNL_OLD_IFINFO in net/ipv4/fib_semantics.c
> >
> > It is a bit unfortunate that TCP needs this setting, it would be better if
> > it would work without user tuning.
> >
>
> The problem is suspected to lie with my ISP's Ascend servers, using larger
> ( > 12k ) windows causing them to stall the TCP pipeline. So many other
> people could have the same problem as Ascends are very popular.
Slow start should detect that. If it doesn't something is fishy in 2.1
TCP. Do you have the same problem with 2.0 too?
- -Andi
>
------------------------------
From: ajs@pigpond.com (Andrew Snare)
Date: 24 May 1998 22:38:42 +1000
Subject: Re: Poor TCP throughput in 2.1.103
- --pgp-sign-Multipart_Sun_May_24_22:38:38_1998-1
Content-Type: text/plain; charset=US-ASCII
Content-Type: text/plain; charset=US-ASCII
>>>>> "Shaw" == Shaw Carruthers <shaw@shawc.demon.co.uk> writes:
Shaw> The problem is suspected to lie with my ISP's Ascend servers,
Shaw> using larger ( > 12k ) windows causing them to stall the TCP
Shaw> pipeline. So many other people could have the same problem as
Shaw> Ascends are very popular.
This rings a bell with me. When I used to connect to an Ascend server,
I found that when my PPP link was running at capacity the connection
would "stall" after about 10 seconds. It used to drive me nuts... at
the time I assumed it was a buffer problem with the ascend. Ie, when
the ascend's buffer was exceeded, packets were dropped and I stopped
ACKing. I then assumed the stall was the pause waiting for the sending
host to retransmit. This explanation is probably wrong, but I didn't
know enough about the mechanics of TCP/IP to formulate a proper
explanation and haven't thought about it since switching ISP. :)
I found this problem with every 2.1.x kernel I tried, from about
2.1.4x (just before the dud kernel release that trashed Linus' HD?)
until the early 2.1.9x kernels (at which point I went back to 2.0).
- Andrew Snare
- --
#!/usr/bin/env python
print(lambda s:s+"("+`s`+")")\
('#!/usr/bin/env python\012print(lambda s:s+"("+`s`+")")\\\012')
print(lambda x:x%`x`)('print(lambda x:x%%`x`)(%s)')
- --pgp-sign-Multipart_Sun_May_24_22:38:38_1998-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
- -----BEGIN PGP MESSAGE-----
Version: 2.6.3i
Comment: If you don't know what this is, you can safely ignore it.
iQCVAwUBNWgU0j9oumhqYnjxAQE4AQP/fZOry010/4ZQni40oFcVsC5iXwzRD/XJ
kAGtsW28Mwrb0iVamUpn+2+O/wFFWnIk02TcIQ2GJuw98BPzUkc7EX2//Z7zIs7r
adi0Gj83OwHa9vLnrXUvFk723hZLFHLaKU0ISX63FdpNvCixseHKV2OPt0gmektF
NpN7o6GPeTg=
=yr8P
- -----END PGP MESSAGE-----
- --pgp-sign-Multipart_Sun_May_24_22:38:38_1998-1--
------------------------------
From: glouis@consultronics.com
Date: Sun, 24 May 1998 08:40:33 -0400 (EDT)
Subject: egcs and 2.0.x
Could someone please point me to information on why 2.0.x shouldn't be
compiled with egcs? I have tried doing so, compiling both 2.0.33 and
2.0.34pre15 with egcs-1.0.2 (and binutils 2.8.1.0.23), and so far I
haven't encountered any anomalous behaviour of the resulting kernels
(though I only ran the 2.0.33 one for about one hour). Right now I'm
writing this on a machine running 2.0.34pre16, also compiled with
egcs-1.0.2, that I've used fairly heavily since installing that kernel
yesterday. ("Fairly heavily" is relative, of course, since I'm the
only user of this particular box, which is why I can afford to take the
risk. My production boxen are all using kernels built with gcc
2.7.2.3.)
It was with egcs-compiled 2.0.34pre15 that I found the Building Number
Three web page yesterday, where Alan Cox wrote:
> 2.0.34pre15 is out. Im especially interested to know if it is now
> stable on the 3c59x cards. This one has no known bugs but probably
> several unknowns.
>
> Don't bother letting me know about bugs if you build it with
> gcc 2.8.* or egcs. It won't work and it's too tricky to fix 2.0.x for
> this.
I don't wanna bother Alan himself with this question, because I'm
enjoying, and reaping benefit from, the work he's doing and I'd
rather he spent his time more profitably on getting 2.0.34 out the door
:) The fact that I haven't hit any troubles doesn't mean there aren't
any, of course.
BTW, if anybody else wants to try it, the following trivial patch to
../include/asm/string.h will eliminate a couple hundred "control falls
off the end" warnings. The switch variable is modulo 4, so the patch
changes no functionality.
- --- string.h~ Tue Apr 8 11:47:46 1997
+++ string.h Sun May 17 10:03:05 1998
@@ -437,7 +437,7 @@
case 0: COMMON(""); return to;
case 1: COMMON("\n\tmovsb"); return to;
case 2: COMMON("\n\tmovsw"); return to;
- - case 3: COMMON("\n\tmovsw\n\tmovsb"); return to;
+ default: COMMON("\n\tmovsw\n\tmovsb"); return to;
}
#undef COMMON
}
@@ -588,7 +588,7 @@
case 0: COMMON(""); return s;
case 1: COMMON("\n\tstosb"); return s;
case 2: COMMON("\n\tstosw"); return s;
- - case 3: COMMON("\n\tstosw\n\tstosb"); return s;
+ default: COMMON("\n\tstosw\n\tstosb"); return s;
}
#undef COMMON
}
- --
| G r e g L o u i s | pgp: keys.pgp.com |
| Technical Director, Systems Group | id glouis@dynamicro.on.ca |
| Consultronics Limited | 2BC6 4F5A 6657 FF4E 9FBC |
| http://www.consultronics.com | 5DAA 2304 76A9 CCA6 5B45 |
------------------------------
From: Shaw Carruthers <shaw@shawc.demon.co.uk>
Date: Sun, 24 May 1998 13:37:21 +0100 (GMT+0100)
Subject: Re: Poor TCP throughput in 2.1.103
On Sun, 24 May 1998 ak@muc.de wrote:
>
> Slow start should detect that. If it doesn't something is fishy in 2.1
> TCP. Do you have the same problem with 2.0 too?
>
Yes I have the same problem with 2.0.33. The magic window size is 13140,
up to this size I get no stalls.
Here is what happens in 2.1.103 with the default window:- stalls of about
20 secs.
14:13:17.829699 158.152.146.90.1046 > 194.159.255.135.20: . ack 60833 win
16060 (DF) [tos 0x8]
14:13:17.839699 194.159.255.135.20 > 158.152.146.90.1046: .
60833:62293(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:18.339699 158.152.146.90.1046 > 194.159.255.135.20: . ack 62293 win
16060 (DF) [tos 0x8]
14:13:18.359699 194.159.255.135.20 > 158.152.146.90.1046: .
62293:63753(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:18.469699 194.159.255.135.20 > 158.152.146.90.1046: P
63753:64077(324) ack 1 win 8760 (DF) [tos 0x8]
14:13:18.989699 194.159.255.135.20 > 158.152.146.90.1046: .
64077:65537(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:19.509699 194.159.255.135.20 > 158.152.146.90.1046: .
65537:66997(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:20.019699 194.159.255.135.20 > 158.152.146.90.1046: .
66997:68457(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:20.529699 194.159.255.135.20 > 158.152.146.90.1046: .
68457:69917(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:21.039699 194.159.255.135.20 > 158.152.146.90.1046: .
69917:71377(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:21.559699 194.159.255.135.20 > 158.152.146.90.1046: .
71377:72837(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:22.079699 194.159.255.135.20 > 158.152.146.90.1046: .
72837:74297(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:22.579699 194.159.255.135.20 > 158.152.146.90.1046: .
74297:75757(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:23.399699 194.159.255.135.20 > 158.152.146.90.1046: .
62293:63753(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:23.899699 158.152.146.90.1046 > 194.159.255.135.20: . ack 63753 win
16060 (DF) [tos 0x8]
/* stalls here */
14:13:42.289699 194.159.255.135.20 > 158.152.146.90.1046: .
63753:65213(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:42.799699 158.152.146.90.1046 > 194.159.255.135.20: . ack 65213 win
16060 (DF) [tos 0x8]
14:13:43.459699 194.159.255.135.20 > 158.152.146.90.1046: .
65213:66673(1460) ack 1 win 8760 (DF) [tos 0x8]
14:13:43.969699 158.152.146.90.1046 > 194.159.255.135.20: . ack 66673 win
16060 (DF) [tos 0x8]
- --
Shaw Carruthers - shaw@shawc.demon.co.uk
London SW14 7JW UK
This is not a sig( with homage to Magritte).
------------------------------
<<< Continua nel prossimo messaggio >>>
--FAD00201.896068154/wigner.cstc.org--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu