--PAE00195.896102052/wigner.cstc.org
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
The original message was received at Mon, 25 May 1998 06:31:27 +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 -----
451 <linux-kernel@vger.rutgers.edu>... vger.rutgers.edu: Name server timeout
451 <linux-kernel@vger.rutgers.edu>... vger.rutgers.edu: Name server timeout
451 "|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"... vger.rutgers.edu: Name server timeout
451 "|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"... vger.rutgers.edu: Name server timeout
451 "|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"... mbox.est.it: Name server timeout
"|exec /usr/lib/mailagent/filter >> /home/pol/var/log/mailagent.bak 2>&1"... Deferred: Name server: host name lookup failure
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old
451 <linux-kernel@vger.rutgers.edu>... vger.rutgers.edu: Name server timeout
--PAE00195.896102052/wigner.cstc.org
Content-Type: message/delivery-status
Reporting-MTA: dns; wigner.cstc.org
Arrival-Date: Mon, 25 May 1998 06:31:27 +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.4.3
Last-Attempt-Date: Mon, 25 May 1998 15:14:12 +0200
Will-Retry-Until: Sat, 30 May 1998 06:31:27 +0200
--PAE00195.896102052/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 GAA01385
for <pol@wigner.cstc.org>; Mon, 25 May 1998 06:31:27 +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); Mon, 25 May 1998 06:31:28 CEST
Message-ID: <294169@bbs.eureka.est.it>
To: Pumilia@mbox.est.it
Date: 25 May 1998 05:31:20 GMT +0100
Subject: linux-kernel-digest V1 #2012
<<< Questo messaggio e' la parte 4 di un precedente messaggio >>>
printk("%s: module auto-load (kmod) support not present.\n", driver);
printk("%s: unable to auto-load required 8390 module.", driver);
return -ENOSYS;
}
printk("%s: Attepmting to auto-load 8390 module.\n", driver);
request_mod = (void*)get_module_symbol("", "request_module");
if (request_mod("8390")) {
printk("%s: request to load the 8390 module failed.\n", driver);
return -ENOSYS;
}
/* Check if module really loaded and is valid */
if (! NS8390_KSYSMS_PRESENT) {
printk("%s: 8390.o not found or invalid or failed to load.\n", driver);
return -ENOSYS;
}
printk("%s: 8390 module loaded.\n", driver);
}
/* Map the functions into place */
S_ethdev_init = (void*)get_module_symbol(0, "ethdev_init");
S_NS8390_init = (void*)get_module_symbol(0, "NS8390_init");
S_ei_open = (void*)get_module_symbol(0, "ei_open");
S_ei_close = (void*)get_module_symbol(0, "ei_close");
S_ei_interrupt = (void*)get_module_symbol(0, "ei_interrupt");
return 0;
}
- -----------------------------------
> Without knowing exactly what you are up to, I would recommend an
> interface like the following:
Ok, perhaps the above helps to clarify what I'm hacking at. I'll
have a look at using bits like what you outlined to flag the connection
between the two modules and see what I come up against. At the moment
8390.c doesn't require an init_module() function at all. I can see the
following case requiring some thought already:
wd.o loads, and subsequently autoloads 8390, marks it in use as
per your outlined method.
ne.o now loads, now 8390 is already present, but we must mark it as
in use by ne.o as well.
Anyways, thanks for the quick reply.
Paul.
------------------------------
From: David Burrows <snadge@gemcorp.com.au>
Date: Mon, 25 May 1998 13:11:26 +1000 (EST)
Subject: Re: [SOUND] Aztech Sound Galaxy broken/not supported?
I didn't have any parallel port drivers loaded at the time, but I tried
changing the value of the IRQ from 7 to 10 (which was free), and got the
same result:
/lib/modules/2.1.103/misc/sgalaxy.o: init_module: Device or resource busy
On Sun, 24 May 1998, Derrik wrote:
> On Sun, 24 May 1998, David Burrows wrote:
>
> > I have managed to get isapnp to activate the card, as I have been
> > successfully using the internal plug and play modem to dial into the net.
> > After insmodding sound, ad1848.. I try to insmod sgalaxy io=0x220 irq=7
> > dma=1 dma2=5 sgbase=0x534, and it fails giving some quite generic error
> > which I can't quite remember at the moment (resource busy?) I've tried
> > swapping the values of io and sgbase, and at a hunch tried using 0x530
> > instead of 0x534, but to no avail..
>
> Have you tried a different IRQ? If you have the parport driver or anything
> else that makes use of the parallel port loaded, that may be causing your
> troubles. If it supports it, try IRQ 5, 9 or 10 (if those are free). You
> may have better luck.
>
> Derrik Pates
> dpates@kalifornia.com
> dpates@acm.org
>
>
------------------------------
From: Mail Delivery Subsystem <MAILER-DAEMON@mbox.est.it>
Date: Mon, 25 May 1998 05:49:02 +0200
Subject: Warning: could not send message for past 4 hours
This is a MIME-encapsulated message
- --FAC00201.896068142/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:13:06 +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
- --FAC00201.896068142/wigner.cstc.org
Content-Type: message/delivery-status
Reporting-MTA: dns; wigner.cstc.org
Arrival-Date: Sun, 24 May 1998 21:13:06 +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:02 +0200
Will-Retry-Until: Fri, 29 May 1998 21:13:06 +0200
- --FAC00201.896068142/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 VAA03622
for <pol@wigner.cstc.org>; Sun, 24 May 1998 21:13:06 +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:13:07 CEST
Message-ID: <294147@bbs.eureka.est.it>
To: Pumilia@mbox.est.it
Date: 24 May 1998 18:43:20 GMT +0100
Subject: linux-kernel-digest V1 #2010
<<< Questo messaggio e' la parte 5 di un precedente messaggio >>>
>> ( > 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?
As far as I can recall slow start is not the problem here, and the
problem will be present with 2.0.x kernels as well. The problem is not
quite so simple as slow start detecting the correct maximum window when
a drop occurs. I seem to recall seeing actual extra delays being introduced
in some traces that could not be attributed to simple packet loss.
Also, slow start behaves rather badly (correctly implemented mind you)
when the bandwidth*delay product of your real path is significantly
smaller than your window size setting. Van Jacobson noted this in his
original paper on slow start and stated that this should be considered
punishment for failing to correctly choose window size settings.
Alternatively this can also be viewed as TCP performs badly when the
available queueing on a path for a particular flow greatly
exceeds badwidth*delay. The problem is that a packet loss detection will
be delayed a long time due to the long queue length, and this starts
to have bad effects on the timing of the whole enterprise.
Summary: until someone deploys a TCP that actually tries to detect
bandwidth*delay for its path, window size settings are going to be
necessary to achieve best performance.
Cheers,
- - --
Eric Schenk www: http://www.loonie.net/~eschenk
email: eschenk@loonie.net, eschenk@rogers.wave.ca
- ------------------------------
From: miquels@cistron.nl (Miquel van Smoorenburg)
Date: 24 May 1998 18:51:16 +0200
Subject: Re: Poor TCP throughput in 2.1.103
In article <Pine.LNX.3.95.980524163000.590A-100000@shawc.demon.co.uk>,
Shaw Carruthers <shaw@shawc.demon.co.uk> wrote:
>Sorry that doesn't help, as I am still advertising a receive window of
>16060, which makes the Ascend fire of a string of packets and then stall
>when I don't ack them.
But. The Ascend is just a router "in between" - why should it know about
window sizes, ACKs etc? MaxMTU - I can see that. But the rest should be
an end-to-end thing.
Mike.
- - --
Miquel van Smoorenburg | Our vision is to speed up time,
miquels@cistron.nl | eventually eliminating it.
- ------------------------------
From: Shaw Carruthers <shaw@shawc.demon.co.uk>
Date: Sun, 24 May 1998 18:13:41 +0100 (GMT+0100)
Subject: Re: Poor TCP throughput in 2.1.103
On 24 May 1998, Andi Kleen wrote:
>
> Seems like the test failed.
>
The problem is that the Ascend can't send a sequence of packets correctly
because of a bug in its VJ compression.
To match the tcpdump log, I also have:
May 22 14:13:18 shawc kernel: TCPv4 bad checksum from 194.159.255.135:0014 to 158.152.146.90:0416, len=1480/1480/1500
May 22 14:13:18 shawc kernel: TCPv4 bad checksum from 194.159.255.135:0014 to 158.152.146.90:0416, len=344/344/364
May 22 14:13:18 shawc kernel: TCPv4 bad checksum from 194.159.255.135:0014 to 158.152.146.90:0416, len=1480/1480/1500
May 22 14:13:22 shawc last message repeated 7 times
If I set a small window at my end, then the Ascend doesn't outreach its
capabilities.
- - --
Shaw Carruthers - shaw@shawc.demon.co.uk
London SW14 7JW UK
This is not a sig( with homage to Magritte).
- ------------------------------
From: Andi Kleen <ak@muc.de>
Date: 24 May 1998 18:26:37 +0200
Subject: Re: Poor TCP throughput in 2.1.103
Shaw Carruthers <shaw@shawc.demon.co.uk> writes:
> On 24 May 1998, Andi Kleen wrote:
>
> >
> > Seems like the test failed.
> >
>
>
> The problem is that the Ascend can't send a sequence of packets correctly
> because of a bug in its VJ compression.
Then disable VJ compression on your end (with the -vj option of pppd).
That should give you a small penalty for small packets (telnet etc.),
but looks like the cleanest way to me.
- - -Andi
- ------------------------------
From: "Eric Schenk" <eschenk@pc-37249.bc.rogers.wave.ca>
Date: Sun, 24 May 1998 10:25:48 -0600
Subject: Re: Poor TCP throughput in 2.1.103
Shaw Carruthers <shaw@shawc.demon.co.uk> writes:
>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.
Just to clarify here, am I correct in assuming that in this trace
you where sending data from the linux box 194.159.255.135 to some
other box at 158.152.146.90?
If so, then this sequence:
>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]
Would seem to indicate a problem with our TCP code.
If the data was flowing the other way, then I cannot make a clear
deduction on where the problem was from this small data sample.
Cheers,
- - --
Eric Schenk www: http://www.loonie.net/~eschenk
email: eschenk@loonie.net, eschenk@rogers.wave.ca
- ------------------------------
End of linux-kernel-digest V1 #2010
***********************************
To subscribe to linux-kernel-digest, send the command:
subscribe linux-kernel-digest
in the body of a message to "Majordomo@vger.rutgers.edu". If you want
to subscribe something other than the account the mail is coming from,
such as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-linux-kernel":
subscribe linux-kernel-digest local-linux-kernel@your.domain.net
A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "linux-kernel-digest"
in the commands above with "linux-kernel".
- --FAC00201.896068142/wigner.cstc.org--
------------------------------
From: Mail Delivery Subsystem <MAILER-DAEMON@mbox.est.it>
Date: Mon, 25 May 1998 05:49:14 +0200
Subject: Warning: could not send message for past 4 hours
This is a MIME-encapsulated message
- --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
<<< Continua nel prossimo messaggio >>>
--PAE00195.896102052/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