604 lines
27 KiB
Plaintext
604 lines
27 KiB
Plaintext
From: Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
|
|
To: Linux-Development@senator-bedfellow.mit.edu
|
|
Reply-To: Linux-Development@senator-bedfellow.mit.edu
|
|
Date: Thu, 31 Mar 94 00:13:10 EST
|
|
Subject: Linux-Development Digest #591
|
|
|
|
Linux-Development Digest #591, Volume #1 Thu, 31 Mar 94 00:13:10 EST
|
|
|
|
Contents:
|
|
Re: PC as C64 file server (Wesp Gerhard)
|
|
IDE Performance Package (Jon Green)
|
|
Re: NFS timeouts (Donald J. Becker)
|
|
Writing AST _EIGHT_ port driver, coprogrammer wanted. (M. van der Laan)
|
|
Cluster patches and closing files (Clayton Haapala)
|
|
Diffs for /proc locking info (J. den Ouden)
|
|
Re: PC as C64 file server (Bernhard Schwall)
|
|
Tips on writing serial drivers. (CHRISTOPHER D DUKES)
|
|
Re: IDE Performance Package (Byron Thomas Faber)
|
|
>> IDE Performance Package Mk.II << (Mark Lord)
|
|
Re: TCP/IP-Bug in 1.0 Kernel? (Mike Horwath)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
Crossposted-To: comp.sys.cbm
|
|
From: gwesp@wst.edvz.sbg.ac.at (Wesp Gerhard)
|
|
Subject: Re: PC as C64 file server
|
|
Date: Wed, 30 Mar 1994 10:35:58 GMT
|
|
|
|
In <2n8em0$jo7@harbinger.cc.monash.edu.au>,
|
|
Andrew Bulhak (acbul1@lindblat.cc.monash.edu.au) wrote:
|
|
[...]
|
|
> I was thinking of a Linux daemon which polls a device on /dev/lp0 or
|
|
> somewhere and acts as a virtual 1541. That way, this would place a very
|
|
> light load on the machine, allowing it to be used for other tasks as
|
|
> well.
|
|
Great idea! But I don't think it would work that simple... As far as I
|
|
can remember, the usual c64 <-> 1541 transmission protocol uses no hand-
|
|
shaking, i.e. the c64 doesn't wait until the 1541 has processed a bit be-
|
|
fore it sends the next one. And the daemon you propose may be sleeping as
|
|
long as it likes if there is heavy load on the machine. I think it's better
|
|
to design your own protocol and implement it in the *kernel* (as a
|
|
standard unix device driver). The commodore protocol is much to slow anyway.
|
|
|
|
BTW, polling is generally NOT recommended on a real OS like Linux.
|
|
|
|
> Another Linux/1541 project, the reciprocal of this, would be a 1541 file
|
|
> system which uses the X1541 cable.
|
|
|
|
Also a great idea! But instaed of a 1541 filesystem I'd rather recommend a
|
|
1541 block device driver just like the usual /dev/fd* interface and some
|
|
utilities similar to the mtools that operate on that device.
|
|
(with this design, you could even create an ext2fs on a 1541 floppy if you're
|
|
funny enough!)
|
|
|
|
Greetings,
|
|
-Gerhard
|
|
|
|
------------------------------
|
|
|
|
From: jcgreen@iastate.edu (Jon Green)
|
|
Subject: IDE Performance Package
|
|
Date: 30 Mar 94 13:43:01 GMT
|
|
|
|
I just installed the patch to enable Multimode with my IDE drives, and
|
|
got the following message on bootup:
|
|
|
|
hda: WDC AC2340H (325MB IDE w/128KB Cache)
|
|
hda: older drive, multiple mode not enabled
|
|
hda: hda1 hda2
|
|
hdb: st3144AT (124MB IDE w/32KB Cache)
|
|
hdb: older drive, multiple mode not enabled
|
|
hdb: hdb1
|
|
|
|
I would have thought the Western Digital drive would have this feature, as
|
|
it is practically brand new. Oh well, it matches the rest of my system. :)
|
|
My question is this: Since multimode is not available, can I expect to see
|
|
any performance increase by installing this patch?
|
|
|
|
--
|
|
* Jon Green * Still searching for the * Friley 5646 Lorch-Russell *
|
|
* jcgreen@iastate.edu * queen of my double-wide * Ames, Iowa 50012-0001 *
|
|
* Jon2@irc * trailer :) * Phone (515) 296-0648 *
|
|
|
|
------------------------------
|
|
|
|
From: becker@super.org (Donald J. Becker)
|
|
Subject: Re: NFS timeouts
|
|
Date: Wed, 30 Mar 1994 06:00:51 GMT
|
|
|
|
In article <1994Mar29.223105.5702@unlv.edu>,
|
|
Frank Lofaro <ftlofaro@unlv.edu> wrote:
|
|
>>But back to the questions: why is Linux NFS limited to 1K buffers? How
|
|
>>difficult would it be to fix?
|
|
>>
|
|
>
|
|
>First you say it is not broken, then you ask how hard it would be to _fix_.
|
|
>A slight contradiction there.
|
|
|
|
Well, any implementation that doesn't handle infinite-sized buffers is
|
|
"broken". How may NFS server will happily serve 63K+ buffers? Where do you
|
|
draw the line?
|
|
|
|
>It should be easy to get the buffers up to almost 4k, trivial in fact.
|
|
>After that you'd need to hack kmalloc, use vmalloc, or have the net code
|
|
>use 2 buffers per large packet or somesuch.
|
|
|
|
The limit right now is due to the unfragmented UDP packet size on ethernet
|
|
of about 1500 bytes. 1K is the largest power of two that will fit
|
|
completely into a single UDP packet / ethernet frame. If you think about
|
|
it, 1K is thus the most logical size for the NFS limit. Any larger size
|
|
will require fragmenting the UDP packet, which has the bad attribute that
|
|
losing any single fragment will require retransmitting the whole thing.
|
|
|
|
You certainly wouldn't pick an unusual value like 2^13... nahhh, no one
|
|
would do that.
|
|
|
|
>P.S. Is calling vmalloc from an interrupt bad?
|
|
|
|
Yes.
|
|
|
|
|
|
--
|
|
|
|
Donald Becker becker@super.org
|
|
IDA Supercomputing Research Center
|
|
17100 Science Drive, Bowie MD 20715 301-805-7482
|
|
|
|
------------------------------
|
|
|
|
From: mvdl@et.tudelft.nl (M. van der Laan)
|
|
Subject: Writing AST _EIGHT_ port driver, coprogrammer wanted.
|
|
Date: 30 Mar 94 16:46:24 +0100
|
|
|
|
|
|
Hello,
|
|
|
|
I intend to write a driver for linux for the AST EIGHTport
|
|
adapter (note, NOT the 4port). The eighport adapater is an intelligent
|
|
8 port serial port adapter. Writing the code that is to be loaded
|
|
into the adapter's memory is do-able for me, but I am looking for someone
|
|
who is willing to help me to adapt this code it to linux, to
|
|
establish the interfacing between the linux-code and this board.
|
|
|
|
Would there be anyone interested in joining me in this task?
|
|
|
|
Please answer by e-mail (mvdl@et.tudelft.nl)
|
|
|
|
Michel.
|
|
|
|
==============================================================================
|
|
Michel van der Laan | WaterGate Development
|
|
At Dept. of Electrical Engineering : MVDL@ET.TUDelft.NL
|
|
At System affairs WLINK BBS domain : system@wlink.nl / wtrlnd!system
|
|
At BBS Waterland [+31 (2990) 40202] : Michel@wlink.nl
|
|
At BBS Waterland on FidoNet : 2:280/802.16
|
|
** If you're afraid of the answer, don't ask the question **
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.os.linux.help
|
|
From: clay@haapi.mn.org (Clayton Haapala)
|
|
Subject: Cluster patches and closing files
|
|
Date: Tue, 29 Mar 1994 21:55:49 GMT
|
|
|
|
Hmmm. "Haapi" is a fairly up-to-date Linux system, running the .21 libraries,
|
|
the latest kernels, the gcc 2.5.8. Processor is 486DX50, SCSI controller
|
|
is an Adaptec 1542b.
|
|
|
|
It runs CNews, Taylor, and Smail as its main purpose in life, and does it
|
|
all quite nicely.
|
|
|
|
Back around PL15h, I installed the cluster diffs, and grew misty-eyed as the
|
|
perceived performance of the SCSI drive improved dramatically. Next day,
|
|
however, "newswatch" reported something like the following to me:
|
|
|
|
relaynews: error closing history file (I/O error)
|
|
|
|
I got several per day, though not every run of relaynews produced the error.
|
|
|
|
I upgraded to 1.04 with NO cluster diffs and ran that for several days, and
|
|
saw no errors, then installed a 1.05 kernel+cluster diffs, and IT'S BACK.
|
|
|
|
Now, I can't find anything wrong with the history file, and I get no other
|
|
reports of problems from the system, but I'm curious as to why such low-level
|
|
driver changes could cause such errors. Anybody else seen 'em?
|
|
--
|
|
Clay Haapala "Well, there was the process of sitting around
|
|
clay@haapi.mn.org and wishing I had more computer stuff."
|
|
-- Dilbert
|
|
|
|
------------------------------
|
|
|
|
From: denouden@inter.NL.net (J. den Ouden)
|
|
Subject: Diffs for /proc locking info
|
|
Date: Wed, 30 Mar 1994 15:55:16 GMT
|
|
|
|
The uuencoded part of this message contains my rather trivial
|
|
quick & dirty kernel diffs for adding file locking information
|
|
to the proc filesystem.
|
|
|
|
DISCLAIMER: I don't really know what I'm doing. This code seems to
|
|
work for me, but don't hang me up on it.
|
|
|
|
After applying the diffs (which are for kernel 1.0.5) and building
|
|
a new kernel, for every process there will be a file
|
|
/proc/some_process_id/locks which contains a line for every lock
|
|
the process holds.
|
|
|
|
Example:
|
|
=================================
|
|
$ cd /proc/92
|
|
$ cat locks
|
|
4 1 0 2147483520 2147483520
|
|
3 1 0 2147483520 2147483520
|
|
3 0 0 85928 85928
|
|
5 1 0 0 2147483647
|
|
================================= EoE
|
|
|
|
Every line consists of 5 numbers:
|
|
|
|
fl_fd file descriptor
|
|
fl_type lock type 0=read lock, 1=write lock
|
|
fl_whence 'whence' I'm not sure about this one since
|
|
my database apps only use SEEK_SET
|
|
fl_start first byte of lock
|
|
fl_end last byte of lock
|
|
|
|
Send you comments (if any) to :
|
|
|
|
Jan den Ouden
|
|
denouden@inter.nl.net
|
|
|
|
Cheers
|
|
|
|
begin 644 procdiffs.gz
|
|
M'XL("*>2F2T``W!R;V-D:69F<P"E56UOXD80_HQ_Q8BJD8W78/-Z0$')!;BB
|
|
M2Q.)I&JKZ\DR]AI6,3;RRR5W*?_]9M<&-N"K&A6)]>Z\[>P^S\QZS/?!,&+J
|
|
M9G'"OE`P,ER&],GP64`A8&'VW/"31A"YCTG=A6T<N5R32$+%,(PSR\H?U(,)
|
|
M=0$LL%J#=GM@=<#J]UN*KNNE883';TX,+1.L[J#5'31;W*.M7%Z"T6J3+N@X
|
|
M6A9<7BJ0I$[*7/S$F9L"CV7S.,>9G3K+@'ZZ7=BS^<W4OKF[_GC_>?ACQ]K1
|
|
MTX\ISEB2HKFB?XF8!RN:VB>AU?,0-:$@+$RA1L,T9C31X$71`7+-Z"3$4*@*
|
|
MR]&K5%&UXUH%&C4%C>#:"0*\(">%912ED+(-A30"%K*4.0'[AJLU`L;S$+&A
|
|
M7J]SQX;B_4>,.2@-)XZ=KZ=`RYK7:,N:$P#;_0.`9Y#_BQOB;O:/N#<MCCN.
|
|
M[P3L/['0#3*/PB].LFDD=+7!VZNOQZ<:%@FAHA_%OANF`9?J:.Q1GX44;NZN
|
|
M)O;\]D%]UD#EPW@,L_M?Y[,'[<1HMKBZY@8'#V%^`>IL_N=T8EN&I6F(DF6:
|
|
MZ"DR;W=$ZNU.BS1[(OE*3-,L#B'YAL3:\>SH<TI1\#\IAEQ1](+77,$CB:)2
|
|
M^6K+/`+N&B^XMLQ\3=&1D)42^@=(=[W"/8JX)*"A8&C^JZ"V+,<+]"074BY[
|
|
M!W0?F=+Z.'M:<^*IA8]A%$6R_S$?5`QJC/W`CIY"&FNRMD1OC/&0HQ$.FKS-
|
|
M(0U]E&QC/)FOX@WH*"#5GUL>'/Z6F0]_AU5RZ@ZPW\KWR'Z:?MW2P^)I34.7
|
|
MECBJ69BP58CTQKVUO3D"%:>D7$=#3[Y!L;>N2Y+=\3(+-JEX'"WO%@H4?-J3
|
|
M8!-Y69"W,C5G@,9;&DA<$45HQ]3Q]F1C883E4LN_1&Z4*.0?DH<"O$LB8KA1
|
|
MAF<0I.^8?4[Z3JM)^CGG*ZZ34+!Z`SZO8+*K=`TCD=XCST/=.BO*TT+M$O-X
|
|
M')Y?I`C1-`?G&@GD8]R<^X+W1?`?^A4[XN98[$X6I'F:X@7@ONH1IR`*5QI(
|
|
MV1;5;$S?7TUFP[>UV26>J+3+YHJ2)ILKWO"LGGI)+;8SZ$@MMMLB/=!QS%ML
|
|
MY06[&.F1JKOQ,`5:A1W)I19IDRK'["AJDDXNV@B9P64=;K9QM@F*D*8G$JE.
|
|
M7A!3[B_PXL:P$_3<-UY\$-]?W4_MR7PQO7U8_(4M.L&'+L+RY^>R/19K6N-,
|
|
M]LG\K&G:V_`09"\%I-"4(%)HQ.7.Z!+PM3/?#=J]P^660R*[2:]E<]"4,+&Z
|
|
M35Y'_--[54?6X#AO2O-.27$<RH:S56QKC!EO"A0+Y=Z>SQ;3#_`/GRU^_W`W
|
|
A?&T6;='H@F=LYSU":%!,8VP>49C(13#\#N3$VP-("@``
|
|
`
|
|
end
|
|
|
|
|
|
------------------------------
|
|
|
|
From: schwall@uran.informatik.uni-bonn.de (Bernhard Schwall)
|
|
Crossposted-To: comp.sys.cbm
|
|
Subject: Re: PC as C64 file server
|
|
Date: 30 Mar 1994 15:44:08 GMT
|
|
Reply-To: schwall@uran.informatik.uni-bonn.de
|
|
|
|
In article 45y@wst.edvz.sbg.ac.at, gwesp@wst.edvz.sbg.ac.at (Wesp Gerhard) writes:
|
|
>[...]
|
|
>> I was thinking of a Linux daemon which polls a device on /dev/lp0 or
|
|
>> somewhere and acts as a virtual 1541. That way, this would place a very
|
|
>> light load on the machine, allowing it to be used for other tasks as
|
|
>> well.
|
|
> Great idea! But I don't think it would work that simple... As far as I
|
|
>can remember, the usual c64 <-> 1541 transmission protocol uses no hand-
|
|
>shaking, i.e. the c64 doesn't wait until the 1541 has processed a bit be-
|
|
>fore it sends the next one.
|
|
|
|
It's just a bit harder! Not only the c64 doesn't wait for the 1541, you must
|
|
look for the correct times, too. This means that ther can't be any activity
|
|
while using the PC and a drive for the c64. Only while waiting for the c64
|
|
the PC can do other things.
|
|
|
|
>> Another Linux/1541 project, the reciprocal of this, would be a 1541 file
|
|
>> system which uses the X1541 cable.
|
|
>
|
|
> Also a great idea! But instaed of a 1541 filesystem I'd rather recommend a
|
|
>1541 block device driver just like the usual /dev/fd* interface and some
|
|
>utilities similar to the mtools that operate on that device.
|
|
>(with this design, you could even create an ext2fs on a 1541 floppy if you're
|
|
>funny enough!)
|
|
|
|
|
|
|
|
This would be very nice. But as you mentioned above this is not easy to do.
|
|
I've tried to run my transferroutines under Linux and they worked only if
|
|
I didn't use the PC for any other work. Even if the system writes the diskbuffer
|
|
back to disk the routines hang and I had to kill the process.
|
|
Mention that I had to disapbe the keyboard in the dos program Disk64E so the
|
|
OInterrupt isn't called while accessing the 1541. I think the driver is
|
|
only possible if you find a way to stop ALL system activities while accessing
|
|
the 1541.
|
|
|
|
|
|
|
|
Bernhard Schwall
|
|
schwall@athene.informatik.uni-bonn.de
|
|
|
|
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
From: cddukes@eos.ncsu.edu (CHRISTOPHER D DUKES)
|
|
Subject: Tips on writing serial drivers.
|
|
Date: 30 Mar 1994 15:35:02 GMT
|
|
|
|
I'm just now at the point where I want to start poking around
|
|
at the low level parts of Linux and as a project I am looking
|
|
at the possibility of getting an 8 port serial card from an RT PC
|
|
work in my Linux box.
|
|
I am looking for tips on writing serial drivers specifically,
|
|
and device drivers for Linux in general (Outside of doing
|
|
async with a 68000 in assembler this my first attempt at a device driver).
|
|
|
|
Failing that, does anyone have any tips on successfully removing
|
|
soldered on 16550s?
|
|
--
|
|
"Very Pete Townshendish." "Who?" "Exactly."
|
|
cddukes@eos.ncsu.edu cdukes@nyx.cs.du.edu pakrat@vnet.ibm.com
|
|
|
|
------------------------------
|
|
|
|
From: bf11620@ehsn3.cen.uiuc.edu (Byron Thomas Faber)
|
|
Subject: Re: IDE Performance Package
|
|
Date: 30 Mar 1994 14:33:55 GMT
|
|
|
|
jcgreen@iastate.edu (Jon Green) writes:
|
|
|
|
>I just installed the patch to enable Multimode with my IDE drives, and
|
|
>got the following message on bootup:
|
|
|
|
>hda: WDC AC2340H (325MB IDE w/128KB Cache)
|
|
>hda: older drive, multiple mode not enabled
|
|
>hda: hda1 hda2
|
|
>hdb: st3144AT (124MB IDE w/32KB Cache)
|
|
>hdb: older drive, multiple mode not enabled
|
|
>hdb: hdb1
|
|
|
|
>I would have thought the Western Digital drive would have this feature, as
|
|
>it is practically brand new. Oh well, it matches the rest of my system. :)
|
|
>My question is this: Since multimode is not available, can I expect to see
|
|
>any performance increase by installing this patch?
|
|
|
|
>--
|
|
>* Jon Green * Still searching for the * Friley 5646 Lorch-Russell *
|
|
>* jcgreen@iastate.edu * queen of my double-wide * Ames, Iowa 50012-0001 *
|
|
>* Jon2@irc * trailer :) * Phone (515) 296-0648 *
|
|
|
|
I had a Connor 170, which wasn't supported either. Hph. Older drive my ass!
|
|
|
|
As far as I understand, the package won't speed anything up if it isn't
|
|
running in multimode.
|
|
|
|
Byron
|
|
--
|
|
PGP 2.3 key available (in plan file) at: Support public code:
|
|
b-faber@uiuc.edu Use GNU software and others.
|
|
other accts at: btf57346@sumter.cso.uiuc.edu & bf11620@coewl.cen.uiuc.edu
|
|
|
|
------------------------------
|
|
|
|
From: mlord@bnr.ca (Mark Lord)
|
|
Subject: >> IDE Performance Package Mk.II <<
|
|
Date: 30 Mar 1994 17:41:06 GMT
|
|
|
|
Okay. Thanks to everyone who has patiently tried the previous
|
|
iterations of these patches. The following is the UUencoded .tgz
|
|
file that I have submitted to Linus for eventual kernel inclusion.
|
|
|
|
These patches are for Linux systems using IDE hard drives.
|
|
They should not negatively impact systems with older drives (MFM,RLL..).
|
|
|
|
Several new features are provided over those of the stock kernel:
|
|
|
|
(1) IDE drive identification at boot time, with an option for even more info.
|
|
(2) Support for IDE multiple sector transfer mode, which reduces kernel
|
|
overhead during disk I/O, and speeds up data throughput. On my system,
|
|
kernel overhead drops by 20-30% for I/O, and data throughput improves
|
|
by about 15%. Turned "off" by default.
|
|
(3) Provision to run with interrupts unmasked most of the time inside the
|
|
hard disk driver routines. This eliminates "serial port overrun"
|
|
errors due to disk activity on most systems. Turned "off" by default.
|
|
(4) New ioctl() calls to enable/adjust the settings for features (2) and (3),
|
|
as well as a sample C program you can use "out of the box" to do this.
|
|
|
|
Have fun.
|
|
|
|
begin 644 ide.tgz
|
|
M'XL(`"0#F2T``^P\_7?:QK+]%?Z*"3U.P$BVQ)<=;)P/&S=^]4>*27MS4C^.
|
|
M0,+H6$A4$K%YJ?_W-S.[$I(0.'V]Z;WWO-(&).W.[,SL['QIU[9I[7[WC3_0
|
|
MT/::3?@.Z*-E?N4--)N-5DW3&[4&WN^UM/IWT/S6A-%G'H2&#_"=[WGAIGY/
|
|
MM?^'?FR<_XDY,_SISNA;C:%K6JO16#O_>K-5$_.O[^W5]IKX1*\W</ZU;T50
|
|
M\O/_?/YWMV%JW%DP#VSWMDW3,1J!>@6J![OSP-\=VJ[4#XC4!+9WB\7O;7?D
|
|
MS$T+#AW;G3]@']^ZW9D<)1J"1;!K>Z/0R3P.3=M;[1DN9E:0?CQW;>R<?C8>
|
|
MN0)A$2FW'D++=\%V0R1NP&.5@]"?CT)\YF'W;?&K@'PZMAUZ2#]*$2_R/G,W
|
|
ML&]=RV2THZFI+)\XGGL+AG];.2BR$#Y[MHGBLUTH4V=L&2DPFJ`^;>/UYT\W
|
|
ME>*78H&:QHAF.F52;/\W<>&/#HK8.H8R`<*S#C0J@/T+XYF/,&-DQ;1\7RE]
|
|
M"(Q;"^=F*P`X-*W/]L@Z@L.+N1->(*)C;^Z&;4UM-8Y(9%,CN&MKN_K1KVY)
|
|
M$70@N86"]6"'4-;I^K%8&)O0`6]F(>7;U2IU4N!JT#NYNCS_2%V(*NQS")H@
|
|
M25`$Y1+#C`T4H`DJO-@*7N#/EKD<3$%>XP'C\9AW'-((/3L:D9K\$3[DB:/Q
|
|
M%'AW<G8UN.[V+SZ<]\_>GW<'5Z>G50:FWE(N)0$06"&DA-#9,DFJ'4G.-!(S
|
|
M,R2D_A4DR)ZOF)0/EQ=OKG\\N^SWVGP?W>53(Z2?(2,QWPCU6/Q7K_CT1]C_
|
|
M'=,>CX-O-<9F^U_7:WNMV/ZW&AK;_V;S;_O_5WQ45073MS];?K`[=+S1'6G#
|
|
M:,?S[=O"J6_#?QDNU'30]MI-K:WKH+]\V2A6J]4<H$)_;L$%"K/V$FKU-H(T
|
|
M]D3_UZ]!U1O*2ZCBM]Z$UZ^+`-OT#Z`_,=R[`$(/WOIXY<$Y?EL!&G8%''GY
|
|
M>GQO[\P_&SNNH\#]Q(,Q+G<3#!C.;P46-,'AQ`++\)T%NP77M$P5_55HA[;G
|
|
MHE&V1CB*05`F-L')!<2M0;&*U%0)S]E)%\YZ/ZEB)<-SP::*9OXY3-'6V#/'
|
|
M4MF0C.A+X!HNB.T[./=\<X?HV2U"L?J]:8UMUX*3[ND;M&8#,FF#XZL/EWU4
|
|
M_@)Z+[(8R+9&7Z8=&$/T3=$8P&,8(0Q1[0CA"CIAF09DC%;1;5]>];>E.2(#
|
|
M]")`A+X%WA@EDT+W<[?W]NJZ.SCIG?W<16RG5VGJ=)2U+X!9%"CIL1<3%MI3
|
|
M*V(W=M%&,-W%,<E)0S9,0'_F>KDMY&(-)[\)9X_#`-*CFK:OM*!:(TVJUUF5
|
|
M"MX\'`YF97+6U>K,\T-RT(_)2?CE[)(GH-=]<U+0'HX;Q*)O&>92XH$U"CT_
|
|
M*"2E$X']TCOK=PFN27#WOAU:3P-*-T9@+0*S7)[BU*B%%2C4P,O^V>E'!.L>
|
|
M$QA-H1`]3@>::S>TQPNPP\!RQ@Q=K*()"^T1<#B"@9!O_3;'90-E>H"BJ*9"
|
|
M&HG"QEOX=/'F'X-W)S?H`;]HRN,!X'@ZWHCQSD[`<(C<!>GGS#$6!,/JD\(H
|
|
M]&R`E_Y:C%(7<6T%8,[1<]["V>Z5#+E6,$Z-AP&)B!KS,&)[)';6SR@,B(.X
|
|
M58S8@P2S#J.4&?:.<8THIG@"H^R3AW$T]WV4--DCGO@5S"L86:\&Z6$1(V@'
|
|
M^(L8W?DTYAH-GAQ`JB,J/ZQJ@V_<8^A+TBZ+N'3FHZH]1%%JH/#`;J58_5*L
|
|
M<M0G.N`#&?3=14\.9(<`GC]'2(H+L0]K%#45:![*=@>)M3%N=*E7\,G^;QV%
|
|
MTH$7\.(`JE6[PJ()[NP9#!TV_$2S!%Z!%"`%6@5CAT`6H15!"%K$`,]X`/C]
|
|
M=RB7[:I>66+AVV67"O,5<U;:&I44@8/9>RQ6'TF"WR/N5<-(+4)LH_'M`,7Z
|
|
M"5E#P15*&.65X)WAF]<X.WQSC98VOKGTPHO3"]')O+X_TIMS;!/]9K9[X87'
|
|
MH5-2D(`2G-H/ELE-/6OJ?;9(<_CVI-\[[#0OAD%T=Y2ZT36^8QP]+[R>F7W/
|
|
M.=II;G$/\SH<7HW'?-WW[Z++TVGX@S'K6;_1'0$_'BR9O':\^PO+/#6"\!,K
|
|
M=BG`)]1S:IGV?$I78VPL$9``>3L?C_N8Q\G^KZB+'HGA9&XX[]$V)Z^/#33M
|
|
M)3%J9`0_7I:'E4*YC-^=CE9Y57*]4KNTL()2):O=YG2&TY!5[;2UBU7]TTVF
|
|
M"8V(+15_5=/E$]1H.!(]X14@1]`FW;P!ZO2X0L]\.AL(^QHNH)P:#?.VQ/C!
|
|
M!+D'>T@IHEAZT3IB:DTCF%@!B['TJUM5__RGBKG(DB\HBQ$JR4>EB;DUPC3S
|
|
M1!A_Z29&!@=09^CVVYS/("/5%\8+!DV8EQ*0:7,Z)45.1^4YLE?;NU$:VDI?
|
|
M!4[O>];G;.?ZC;*?T_?:\FW#N?0RW77M1JEI:19^=>'8<\?V;>=+B5L25NFP
|
|
MHS?QIUJM`-D.Q*#=8%A7U@\/[4H%(AS1XK9OTJCA$=G//#JQQ@:YJ='N9#?`
|
|
MA&^7_U=HC5W;_V-Q)DCZ']]TCX_9B,GDD"TH<G*CX'>=OUO\W>#O)JHLR:4F
|
|
M2(G4O0310D.)4#L*(GJBU(6A1A1[R%T'M(?3TQ31"D-+BGY\JV#L^D">B>B,
|
|
M<U9$JM_LUO@*$678/K6,<.Y;01M.ALXO&/6>776VT)><OWW#OR<7]"O8P^5,
|
|
M./9OGNL51=Z\O'FN/>#4I>YUK9+F4H'P/2)F%IOZS='1OI*P24HM]D@)%&3U
|
|
MZ;Y9I_'(?A`-291$FT!96X,RJ4SEK:#2AF/I:5>FV8ND)GA%HY4:^U5I:BR&
|
|
M%IJOSX9CFZ5*-.%-.;]-\8-SOLT5)*'832GP%&\U+>&3F164=A"-#DGXEG:S
|
|
MGI'$5"/8$P0+KJA+-$6OXIO3T[:6-P59,E'@JG[?V=(:_Q`W4W$CU*Q5$SK>
|
|
MJF=HW@I($Y=F"HWM]YC5X6`8#>1D+:NQ#V8P'$12*L7!J8B'A;W-VF:TM"?=
|
|
MG\^.NX/+7OGX0Z^'4;AZA`T5*AYBOM/!GI1DO#L97/??]#]<5]AK,?>)`/@3
|
|
M@MRP"(+0+B^#)D*!JOGVP_5'AO^]V^OQ144&4E&`R@APM&5X&3W1#E*2!1#V
|
|
MFA*U=-HHRG,KQOH1+">P9-B&-)57AT@1(8.EE0&C<';+5$4TFAX^LFNX[,3@
|
|
M2I87IJ9`Q.0/()-A<Q5OFA_\M\QVA*Q]"PV3F^>;H\SI3VC"0;)W[,%;N):_
|
|
MM8KD3GQZTEU,QX/YC++?G+E/S+P;W!.%)V_Z;V)W:@^55D/$YK<6E<E]3!_U
|
|
MVCZE@,N@>UU8C#.=#'S*'.K80QI8+-E<\C,4+GU^^?+#^;D"V3`"9!Q1B)+#
|
|
M2&DC7X>N;CS.K)'REGGQEJLZ][OD[8`CSMCGH1&LQ/K*CGB;'?$V.V+8A9K6
|
|
MV(_<X=&1KD!J<$'/4Q(=._-@@@DFO2B@D*:^WTC+=3.*KVA_<B6`7`FLXA3>
|
|
M#8;S8"%7`>H%I%<!!J)<:FGJBMZ`*A*LU'11:F%51==OA16Z*]QZH8>\S3`B
|
|
M.,`'CT6U@!'6`?V06\!,[+*'F;$P<O0(,[KTPY7E@8&7:(C3M(Q9L/W?9($.
|
|
MQ4G39R^UJ)#&%)O-QVBDV,1A(R:,"=/TY+@KYB@Y;A)O)XTV002*#"?*FX=E
|
|
M6Z%75AA58X<=LJ.;[B>68:JZPA)//!XM'(4K3>^[QV>G'Y7G/#&#"15]GIXJ
|
|
M=@<X4073&V2U)Z-.7$Q#76:UJ.L:E7(;34W1A5;$^B5J#DALTLJB4-4HOQ$7
|
|
MJ)N^C<K?`5VCS\$?-L,RM<LBPO7)H@.7?@ZH`OB4]2UP>6%F^5,[!"^<6'ZJ
|
|
M2/4PQ@=4X40I\4(IV#A:G-I5<DR^E+R-%BFVY14AN5I+J;=0=*U]I=$2"RK2
|
|
MM7<G[:7DVBS0.3&F/6QIM0?6-L8=H8Z=@Z`*Y\OR??3%6>*(-.Q[1:^LU,*Z
|
|
MX2+8Y6@1PDK"HD8K8B-@Y/43"(`U?XA`_KW0#'XX<MC]J7D*F-&_V)R!=S<(
|
|
MO0%1T&9M2AC&6$N&F.!8OE)KMA@7Z\1J2(5-S(AK/81MJ2C<-6&7RJZ$C7'+
|
|
MJMO`]0>R%E>A"@'#L2&((*9"!<EA\1.U$VEE%(I16]1;%UJ]@1ON>7@H$N2X
|
|
M449@U03R#&#<=GCXDB09-_/L!,(XJ7E03;V6:A%C2>N.<*H:-RVE08V)AE5Q
|
|
M,:.DICG`L9`X<@(,.$QKC';@[8<?$&U""4VJPPC6.T"IV):9\+!HYR07V*CM
|
|
MLUJ2\E^<75ZM1/<9]A2R*_$S(#"!*UD62JR#B(Z@O.68*OZK*$M*.GBO2%HP
|
|
MZ=EW'J)H(XZ-5X;/BIOEP3`Y`L,PB38E5"`S?=5R-.645(,,PX13?F9SI70)
|
|
M,:&L^=GUA[?7W>,^"LBN<,3)^K]A(I>3!8>H1.QD<)QXW>H)>W4D-A)$/GBY
|
|
M6J13DLN0C>=UM\^OM<K/8SLC;)<,E[%+;`W8L`@_DV>)*6+E!=4]?_.1B<#N
|
|
M#J;Z_"J@(P:FEUC"(L5BRC%(A$D*HY+C()<DD:MD8]^J*TT=JDV]J33WV-B3
|
|
MI9:.$/XICO`K_-N?]UP4.XP\#.W=N17WX4[4SELB*E1?Y[NK'P7`$$5[Q[.6
|
|
M5J.$^J#2Z!561<)UTOLI2G;42"^$K>?W&P>1[CS+])8A&S4EWY\@/3KASANX
|
|
MPP,+N!6-K>;H#'=<JS:))*>PHB:%K*;PLS@X+\C(-)F;)W&DZ#Y"L@5\KG0>
|
|
M.:B[G]`>I[*J1KI%'-"T27504R&`$-G&D"-K])X`B0S;GX]6H+"6U(WARC\_
|
|
MVN"AV]_&%>:Z8]C@CO^("<^AMYKG1E0U,G'/-A*<:^/5M(U7DQ9\.6G"A&/F
|
|
M\V3`MK3TZG)=J#G+4MVP*-78EJ_.M\IIZG(-?@U1U75,B=0HG?^,#">3`(F5
|
|
M<&^[2$>`86BYPJ+,*.G7Z&8R$VO4-64//<S^OK(GT_/DY&C18OCCB!L"\<L(
|
|
M,6S#O4=%H7!BA#`R7)@8,]H*:`?B$3Z9HP>?H9Z@ZWIWHB)/J-'S&?;VIA:_
|
|
ML#9<DS%A1AKP=IT29Z<E^&SX-N^-H/TYM!]+MO-L5L2.&C7UHBW%C2SFY>^"
|
|
M6%ODX(U+9*X.LBVH[`IEW`KEUZ%OC.Y$/:2QU^1Z2*M>CW8Q96-2A)`!*2&0
|
|
MEZE`=34P!8X&%8(58`RA9$.Z5(`BC9E<L[GN7W:!1!E`A@$R`J'K]$M[KLJ(
|
|
M5V3LQ%F3[:%OA)8H8W"6(C%3:6MHA3C+0%M#`-/GP!A;"A@!\'`!&+[%\TBK
|
|
ME)Y1Q91SZ4)4J"AOCNP$Z4LBF#GD@F?CI:;4:S@;C9?*7E2=DL45DF=4)R$8
|
|
M45#1^#\JF/2ZUV@ENU0PB=;JTR63=706I`5<VLVI23$&;QJ2%C%!EXCG4SI&
|
|
M)'%O)6U;Y/0N=^S$`J!@*/T4XNG):@,'D"N;Q@Y67SKP;I/5[6I1/2AB0$L(
|
|
M,MJMI#Q/U=>_2IAL$0T['&`P5ZY(0:5<?FJ9M\'U*.X3;V&I:\9Z5I-QU6.4
|
|
MT*<X?+92!)#"3+"7@DBP*K=S*<]7WBM5XN!T`[>/?]S]Y2Z'K);1CK:O5C+J
|
|
MK*32*M:7](;WG)=/&'G"J]0F.K1U$<*L?N2,33OS4L-^]5*KIFH`N94HROBW
|
|
MS)PT/"_O7B;>@LR5_)L[Y>;@JKXNVTXG`:M*N-8RY$B?I8FF]1>+W:SG.@N8
|
|
M8P@4;QXC(XO/T)^6/-=2@XF''I1TL1V]3,`115GI<'4F,4R4):<G:EHB%1'J
|
|
MD-H&*;*69*Z5J#VE$YDE]%I(?5F=_PH5REC'I`Y5LSKTA.80JG\WS5FUB-6,
|
|
M15QG#JNYYC`C$"GGS48H,3VBV+ABA6:&:X_*I;E[YWKW&`B:*D9X4PS=2E$8
|
|
M65T;JT'RS:M\L3*P_=^(G+/>3SEQ:;4@WC=G>F7?:OU?SO^LK+V\HSY%&6XT
|
|
MFR]IW_%><X]*^.*M!VJX@<K^]OS'7N_]FUZ_33%1SU)YB^]R\WE(]`<R\I'"
|
|
MQ%GA+188U:!X4!)W9295/;('/H>#NGQ[+,9(G3YIIQ\G#JFLO`*3`4!96IY,
|
|
M?ZDFDB1M9<#,29SV^M;:AK;&AK;]#6UZ:T-C?=.(+3'D%RF.Y)R.'>,V.(C-
|
|
MD]K)Y51T"(S/UH`!ROPMQ27B7]Z;3;O&,(2.M'MJWTXP#`YMQ\'8F&STS/=N
|
|
MT4*E=JW2N$>9-\FR&.539J!VSRY_?G/.(^!B!6\,ON'>6KS569S_BM"QL?VJ
|
|
M."<]`)7W&#^]!U8@]!=@W-)!MB1>62'+[DR)G%2$34O4L2BP1[.7)S6I9`@3
|
|
MF2):#KVKP=G5<?_\.J/^\I0=65W>8M=.KIU(0/]F9ZG^$S_B_!>=W?QV1\">
|
|
M.O_;J,?GOUI[C3H^J6EU_>_S7W_%A\Y_R>,VNZF3O.((V"]T5,H:X930$;!&
|
|
MHZTWZ4A7G8^`Y<(5KHV03X'I+T';;]>T=FU_>0JLV51T#:KX4]-$80G`,:B&
|
|
M0)Z0762T#YS-<J_[$V@/=4W///^AV_^A>R6;JNN;(L>/X<&MY4TM,G1?BMF3
|
|
MOKRAAB)-=`RY;7&]-MLJ=H%A?&J[II77@7T.E[0H-CK(T!KYX4*!R*UE6I=^
|
|
M6K37,^T9GT5]=&U#GUJAG'N^ME;9`-18`]38!+2_!FA_$Y#>6@.EMS:!U=>Q
|
|
M5=_(5VL=8RWD+"JT_:M7Y[?_D/VG)/ZBNS,QO]$83]C_>D//_/T/7=>;VM_V
|
|
M_Z_XT-;(]Y:/D25F<!A7=MT)_4XM-PR*G0V?8K$_L0.@,\"4XV",2F>`(Y\0
|
|
M1'M1.68-[SWP9I0+&0Z7*H)VL5C6*]"?6+2][H[/`OH8Z^)2#;CN@:DE^',7
|
|
M[NUP`O&[A$">([3,8F'J!1P:1R\*:&_F'>_^F%A3#']'$QC[-JYCQT;W@GGP
|
|
M!(/S8B&8662W^4@)$(7B5+#8^14L@A"!C5%H?[;#Q0Y26:O`M63%#B+V3&:+
|
|
M9%>ZB#8%7HLJ/]5HZ)S!A/ZFAE4L((7W$QN)(:Y\RYR/$BS?6;YK.>"A%/E]
|
|
MP7`!NJ;6M2V$<Y$?=R%)"A0A"0-&GH\Q]LQSN>Z%O6O:%I&%.2>E`FZQ@)[4
|
|
MP/%1G+>3V3Q$)MXN0(;1"@R14QC+`QQ<H8_V-RK,%.;R,\RJA[9#9YAH4)29
|
|
MH`&0)L$+<K=`\A;(%-6F0AR+4EP<JN]%YUQI&A0D.)@:F`UQ'F1,DS)L0_PG
|
|
M18K'.*K-0-B!_Q;)U_PEDB+-'([C<H7,Y@/+8O3=Z$`US8-KW<<<\^N)L><X
|
|
MWCTI(9++&05R5J_E;F=7,BH(\<Y3!"](@G8Q94'B#$0">K%X-H:%-X<)IH_B
|
|
MZ'0XX5*>/$/-4K$0D$(>63N!>V_NF$@JZE;H%0J4/0;!7&H:<8'$X:3+H[G(
|
|
MQ+WE.(J4%;<;4PLH0;2ICH/KMQA8(96X`NJ-:\Y&[5NE>0AZZW_;N9:="F$@
|
|
MNK9?P=(%X>)C2Z*Y<6],_(!2BJ*%D@X7P]][9EJ(7C5QX\K;!>'5Z3Q/H>V4
|
|
M>=XTT;9'/N)C;GU<%)X$@+Z_$[_,2J%4V\$\]YP3SS7'#_BR<F>L_'7^1`0N
|
|
M-QAU)OGE38,_W&I[7%-U45Y>O\8LVNJJ_/5KQPV)X'_14H3&)VB*H(J6/4!V
|
|
M'FCY0W?N[!L56<8NOTZ037X"&EFG1V+[HQ'*5;(Q6R]IT7`2$@!E?__(%N!Q
|
|
MJ\QJP1:R(/D`P"0+,`&QB0&.E$0$P8X[W.;$<3@1=0AG67W$4]$I:L59X;4A
|
|
M:_7L):5X\Y]N0"?I>`FT/DR^YT$W7"Z?M@'(U>BTB>(D12?7/B=>V@%&^-'.
|
|
M3F873-'PP7G0D=&X0MTZWLL'I&?KEER"Q4A((`B9;ZZ<YJ8(8:)#4MRX=CT"
|
|
M!L'6APZ5^#QQO4%`!%M(>S>\^"57O?.AN:F'4!C]#[[T3N54OI9WP-V$%P!0
|
|
"``#6
|
|
`
|
|
end
|
|
--
|
|
mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482
|
|
|
|
------------------------------
|
|
|
|
From: drechsau@winternet.mpls.mn.us (Mike Horwath)
|
|
Subject: Re: TCP/IP-Bug in 1.0 Kernel?
|
|
Date: 30 Mar 1994 02:42:30 GMT
|
|
|
|
Rene COUGNENC (rene@renux.frmug.fr.net) wrote:
|
|
|
|
: The problem is not only whith ftp, but whith any program. The network works
|
|
: proprely whith 1.0.4 between 2 linux boxes on Ethernet, but as soon as I
|
|
: connect an Annex terminal server whith SLIP or PPP, these connexions
|
|
: work randomly; I can telnet or rlogin or ftp or anything whith no problem,
|
|
: but receiving data blocks. A "cat" of a text file may show the first lines,
|
|
: then stop for a few minutes, then restart or hang definitively...
|
|
|
|
: linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux
|
|
|
|
Hmm...
|
|
|
|
Our configuration matches almost exactly. I have a small network at home
|
|
here with normally 2 linux machines, sometimes 3 or 4. I also connect up
|
|
to an Annex Micro XL for my PPP link.
|
|
|
|
Now, I never ever have problems or errors. I also push the Annex at the
|
|
full DTE it supports (57,600) and using 2 Hayes 28.8K modems. Transfers
|
|
of ftp, news, and mail are just smooth as can be, both up and downloading.
|
|
And I never have hung connections and stay online from 3-20 days at a time
|
|
without loss of connection or an unreasonable ammount of errors (sometimes
|
|
collisions, which I think is odd).
|
|
|
|
I wonder where the fundamental differences are that cause problems.
|
|
|
|
(thinking hard...)
|
|
|
|
--
|
|
Mike Horwath IRC: Drechsau LIFE: Lover drechsau@winternet.mpls.mn.us
|
|
Winternet: info@winternet.mpls.mn.us root@jacobs.mn.org <- Linux!
|
|
Twin Cities area Internet Access: 612-941-9177 for more info
|
|
|
|
------------------------------
|
|
|
|
|
|
** FOR YOUR REFERENCE **
|
|
|
|
The service address, to which questions about the list itself and requests
|
|
to be added to or deleted from it should be directed, is:
|
|
|
|
Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU
|
|
|
|
You can send mail to the entire list (and comp.os.linux.development) via:
|
|
|
|
Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU
|
|
|
|
Linux may be obtained via one of these FTP sites:
|
|
nic.funet.fi pub/OS/Linux
|
|
tsx-11.mit.edu pub/linux
|
|
sunsite.unc.edu pub/Linux
|
|
|
|
End of Linux-Development Digest
|
|
******************************
|