From: Digestifier 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 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:69FZ\[>P^S\QZS/?!,&+J M9G'"OE`P,ER&],GP64`A8&'VW/"31A"YCTG=A6T9G3K+@'ZZ7=BS^?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#IL_N=T8EN&I6F(DF6: MZ"DR;W=$ZNU.BS1[(OE*3-,L#B'YAL3:\>SH'/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$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@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 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%'AWGW<'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]4GQO[\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[./=\];>E.2(# M]")`A+X%WA@EDT+W<[?W]NJZ.SCIG?W<16RG5VGJ=)2U+X!9%"CIL1<3%MI3 M*V(W=M%&,-W%,KDMY&(-)[\)9X_#`-*CFK:OM*!:(TVJUUF5 M"MX\'`YF97+6U>K,\T-RT(_)2?CE[)(GH-=]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[`<(CGGS#$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)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,5RQ6'TF"WR/N5<-(+4)LH_'M`,7Z M"5E#P15*&.65X)WAF]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=OUO\W>#O)JHLR:4F M2(G4O0310D.)4#L*(GJBU(6A1A1[R%T'M(?3TQ31"D-+BGY\JV#L^D">B>B, M776VT)>#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;H\SI3VC"0;)W[,%;N):_ MM8KD3GQZTEU,QX/YC++?G+E/S+P;W!.%)V_Z;V)W:@^55D/$YK<6EUU8C#.=#'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(_ M#8;S8"%7`>H%I%\S3`B M.,`'CT6U@!'6`?V06\!,[+*'F;$P68:JZPA)//!XM'(4K3>^[QV>G'Y7G/#&#"15]GIXJ M=@6%F^5,[!"^<6'ZJ M2/4PQ@=4X40I\4(IV#A:G-I5*(-.Q[1:^LU,*Z MX2+8Y6@1PDK"HD8K8B-@Y/43"(`U?XA`_KW0#'XXR%E>A"@'#L2&((*9"!7@H$N2X M449@U03R#&#<=GCXDB09-_/L!,(XJ7E03;V6:A%C2>N.<*H:-RVE08V)AE5Q M,:.DICG`L9`X<@(,.$QKC';@[8,^"LBN<,3)^K]A(I>3!8>H1.QD<)QXW>H)>W4D-A)$/GBY M6J13DLN0C>=UM\^OM)*6+E!=4]?_.1B<#N M#J;Z_"J@(P:FEUC"(L5BRC%(A$D*HY+C()?W&P>1[CS+])8A&S4EWY\@/3KASANX MPP,+N!6-K>;H#'=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//?H9Z@ZWIWHB)/J-'S&?;VIA:_ ML#9^" 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_2IAL$0T['&`P5ZY(0:5/?]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):3SEQ:;4@WC=G>F7?:OU?SO^LK+V\HSY%&6XT MFR]IW_%>#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=G58M=.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-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`(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$Z%O6O:%I&%.2>E`FZQ@)[4 MP/%1G+>3V3Q$)MXN0(;1"@R14QC+`QQK%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'#_BRL_'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;ZZS>\^"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 ******************************