Subject: Linux-Development Digest #137
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Thu, 8 Sep 94 01:13:05 EDT

Linux-Development Digest #137, Volume #2          Thu, 8 Sep 94 01:13:05 EDT

Contents:
  Re: [Q] on Linux/MIPS port (Marc Fraioli)
  Re: Multiprocessing Pentium Systems (Marc Fraioli)
  Re: News Spool File System - new filesystem type?? (Rob Robertson)
  Re: Multiprocessing Pentium Systems (Jason V Robertson)
  Re: kernel 1.1.44/45 and serial drivers..... ("Theodore Ts'o")
  Re: Future of linux -- the sequel (David Hinds)
  UN: Future Domain SCSI HA (Donny Chan)
  Re: IDE Performance enhancement (Mark Lord)
  Linux for Mac (Mike Sheffer)
  Linux developers : an example for OS development companies! (Constantine Triantafillou)
  9-track tape drives? (Steven Charlton)
  There's a hole in my copy! (Mark Tomlinson)
  Re: time speeds up (John Saunders)
  Best PCI viceo and SCSI controller (Steve Wallace)
  Cabletron E21 network card (Steven Yampolsky)
  [SERIAL] Parity problems - an update (Joe George)
  Re: WARNING about shadow-mk package (Mohan Kokal)
  Linux OpenDoc  (was: CIL is open, OLE2 closed?) ([email-masked])
  Re: Undelete command for ext2 (Was: Re: Doe (John Saunders)
  Re: Incremental linking linux (close) (John Saunders)
  A fix for the mke2fs - floppy bug (WE Metzenthen)
  Debugging TCP connections (Steve Kann)

----------------------------------------------------------------------------

From: [email-masked] (Marc Fraioli)
Subject: Re: [Q] on Linux/MIPS port
Date: 7 Sep 1994 21:50:06 GMT
Reply-To: [email-masked]

In article 4362@ludens,  [email-masked] writes:
>Hello,
>
>I've read the annonuncement and FAQ on the MIPS/linux port, and there are
>still things I'd like to know...
>Does this port work only for that specific board ?
>What about other architectures based on MIPS processors ?
>Once this project is done, how difficult would be to port _that_
>to a MIPS based DECstation for example ? I'm curious because we have a bunch
>of DECstation 3100's (Running MIPS R3000 as I know and Ultrix). Currently
>we can only use them for X terminals (lack of memory and hd) but maybe with
>the efficient memory management of linux ( e.g. shared libs and dynamic buffer
>cache - things that Ultrix never heard about ) we could use them as regular
>workstations...

While I agree that DECstation 3100s and 5000s would be a nice target for
Linux (after all, DEC is dumping their MIPS-based machines in favor of 
Alphas so they should be available cheap used, but the 5000s at least
are still a good bit faster than 486s), it won't be that easy.  I think
the MIPS/Linux project which you heard of is to port to a system with
a MIPS CPU but which is otherwise a PC-- ie, EISA or PCI bus, and same
old PC peripherals you're used to.  The DECstations, on the other hand,
use an entirely different bus (TurboChannel) and different boards which
plug into that bus.  So it could be done (of course) but you would end
up having to write drivers for the bus, the SCSI adapter, the video
board, and so on.  Basically everything, all over again.  For a machine
which has been discontinued, perhaps it's not worth it, unless someone who
has a _lot_ of them already does it and the rest of us can benefit ;-).

---
Marc Fraioli          | "They couldn't hit an elephant at this dist- " 
[email-masked]         |    - Last words of Union General John Sedgwick,
                      |    Battle of Spotsylvania Court House, U.S. Civil War

------------------------------

From: [email-masked] (Marc Fraioli)
Subject: Re: Multiprocessing Pentium Systems
Date: 7 Sep 1994 21:42:23 GMT
Reply-To: [email-masked]

In article [email-masked],  [email-masked] (Ulrich Teichert) writes:
>In <[email-masked]> [email-masked]. (Tim Morley) writes:
>
>>In article <[email-masked]>,
>>David Williams <[email-masked]> wrote:
>>>
>>>I've just seen some new dual processor pentium systems in Computer
>>>Shopper.  They look swell for the money, but there isn't a single OS
>>>that can take advantage of them.  Anybody have any thoughts about how
>>>hard it might be to make Linux one of the first OS's to take advantage
>>>of these systems?
>
>>Well it would be hard to do so, as OS/2 SMP already exists and is
>>avaliable for dual processor machines...
>As is NT. There was a test in a german mag (c't), if you wrote about
>the ASUS MB.
>
If the machine supports Intel's SMP hardware standard, then it should
run OS/2 SMP, Windows NT, SCO MPX, Solaris 2.4 for x86, SVR4.2 MP,
and possibly others that I've missed.  But just because Linux wouldn't
be the first doesn't mean it's not worth doing...

---
Marc Fraioli          | "They couldn't hit an elephant at this dist- " 
[email-masked]         |    - Last words of Union General John Sedgwick,
                      |    Battle of Spotsylvania Court House, U.S. Civil War

------------------------------

From: [email-masked] (Rob Robertson)
Crossposted-To: news.software.b
Subject: Re: News Spool File System - new filesystem type??
Date: 07 Sep 1994 23:44:07 GMT

In article <[email-masked]> [email-masked] (Michael Dillon) writes:

   1. This is a compressed file system using LZ technology
   2. Since LZ compression replaces repeated strings with a dictionary
      reference and since news postings tend to have a lot of the
      same words over and over, the NSFS uses a two part dictionary.
      The first part of the dictionary is applied to all files in the
      NSFS and contains words that are likely to occur in many news postings.
      This includes headers and common English words and phrases. The
      second part is a file specific dictionary as is normally found in
      LZ compression systems.

I don't think this would work, as so many words in usenet postings are
misspelled that looking them up in a dictionary, probably won't buy
you anything, cuz they won't be found!
               ^
                c whut i meen?

Oh, I just got an idea, maybe we could use it to do spelling
correction!

rob

------------------------------

From: [email-masked] (Jason V Robertson)
Subject: Re: Multiprocessing Pentium Systems
Date: 7 Sep 1994 17:35:45 GMT

In article <[email-masked]> "David Williams" <[email-masked]> writes:
>
>I've just seen some new dual processor pentium systems in Computer
>Shopper.  They look swell for the money, but there isn't a single OS
>that can take advantage of them.  Anybody have any thoughts about how
>hard it might be to make Linux one of the first OS's to take advantage
>of these systems?
>

Are you sure NT doesn't support them?  I thought it supported SMP?
(I know.. It's not much of an OS, but it isn't all _that_ bad from what I hear.)
-- 
Email: [email-masked]
Ph or finger [email-masked] for PGP public key.
(Like I actually need one).

------------------------------

From: "Theodore Ts'o" <[email-masked]>
Subject: Re: kernel 1.1.44/45 and serial drivers.....
Date: 7 Sep 1994 20:02:38 -0400
Reply-To: [email-masked]

   From: [email-masked] (Martin Seine)
   Date: Mon, 22 Aug 1994 00:35:57 GMT

   Jaime Jofre ([email-masked]) wrote in msg <[email-masked]>:
   > Has anyone noticed any performance degradation in the serial
   > drivers with kernel version 1.1.44/45?  I've been using kernel
   > 1.0.9 for a long time now and tunning Mosaic with term compiled
   > in over a 14.4k modem with very nice results (~1500 cps)  But with
   > kernels 1.1.44/45 I noticed that my term connections dropped in
   > performance (~400 cps)  Does anyone have any ideas as to why?  Thanks
   > in advanced,

   No ideas, but I have this problem since 1.1.41. I've upgraded to .45 and
   tested the versions in between and nothing solved the problem. The
   uucp-connections are very bad, because chars are lost. Now I've diabled in
   drivers/char/serial.c the CONFIG_NEW_SERIAL_ISR but there is only a slightly
   better performance. The port has a 16550A ...

   So, if anyone has a idea, where the bug is ...

I've since gotten the following reply from Jaime Jofre when I asked for
more details:

|I've been using the IDE performance package with kernell 1.1.49 with
|great success.  I the umask for the drive to 1 and now I get no
|input over runs and performace is back up to ~1500 cps.
|
|Jaime

If you need more details, why don't you send mail to Jaime....

                                                        - Ted

------------------------------

From: [email-masked] (David Hinds)
Subject: Re: Future of linux -- the sequel
Date: 7 Sep 1994 17:47:30 GMT

Corey Brenner ([email-masked]) wrote:
: Well... here's the scoop... Indy will take a major performance hit when 
: SGI dumps IRIX and moves to NT.  Sad, but true.

Pardon me?

SGI will dump IRIX for NT when hell freezes over.

This is not to say that there will never be an SGI box that runs NT.
But I doubt the Indy ever will.  And there's no chance that SGI will
ever "dump" IRIX.

For perspective, a year or two ago, SGI showed an Indigo running NT as
a "technology demonstration" or some such.  No product.  I wonder why.

        -- David Hinds
           [email-masked]

------------------------------

Subject: UN: Future Domain SCSI HA
From: [email-masked] (Donny Chan)
Date: Wed,  7 Sep 94 00:15:00 -0400

Would like to know is Future Domain's new PCI SCSI HA TMC-3260
compatible with Linux?
---
 * DeLuxe2 1.21 #6922 * 

------------------------------

From: [email-masked] (Mark Lord)
Subject: Re: IDE Performance enhancement
Date: 7 Sep 1994 17:49:43 GMT

In article <[email-masked]> [email-masked] writes:
>In article <[email-masked]> [email-masked] (Pete Deuel) writes:
>:
>:>About IDE multiple-sector: the rate of a "dd" off the disk doubles when
>:>setting 8-sector transfer on the Quantum disk in my machine at work.
>:>I did not time the difference in compilation speed, but again it will
>:>probably not make so much difference.
>:
>:I have to think that, if there is to be any noticible speed difference, you 
>:really must stick to disk-intensive applications.  I would guess kernel 
>:compilation is not THE thing to test this with.

For the purists (like me, :)) I have updated the next version (1.3) of hdparm
to include disk-throughput measurements (for reads only). 

Look for it to appear on tsx-11 next week, after I add CPU-usage measurements
as well.
-- 
[email-masked]    Mark Lord       BNR Ottawa,Canada       613-763-7482

------------------------------

From: [email-masked] (Mike Sheffer)
Subject: Linux for Mac
Date: 8 Sep 1994 01:14:41 GMT

Is anyone out there working on 68K Mac binaries?  

------------------------------

From: [email-masked] (Constantine Triantafillou)
Subject: Linux developers : an example for OS development companies!
Date: Thu, 8 Sep 1994 01:48:05 GMT

Hi,

This is my opinion and only my opinion. Linux developers are awesome!
Congratulations, guys! I've not seen before people like you contributing
so much, not asking for $$$, and still creating and improving such great
O.S..The OS product(s) of some software companies (Microsoft, e.t.c) is so 
poor, when compared to yours! Boy, I wish I could be a Linux developer and help out!  

                                                            Best Regards!
                                                             
                                                             Constantine

--
*******************************************************************
*Constantine Triantafillou    e-mail: [email-masked]* 
*"HELLAS=Science,Arts,Civilization,Democracy"                     *
*******************************************************************

------------------------------

From: [email-masked] (Steven Charlton)
Subject: 9-track tape drives?
Date: 7 Sep 1994 18:12:38 GMT

A friend is looking to hook up a 9-track tape drive (specifically
StorageTek 9914 scsi) and wants to know if there is a driver in the
kernel that will support such a beast, or (failing that) how hard it
would be to write such a beast.  Any info would be appreciated.

Please e-mail responses to [email-masked], as my news feed is
dead for the next week or two...

Steve

------------------------------

Subject: There's a hole in my copy!
From: [email-masked] (Mark Tomlinson)
Date: Thu, 8 Sep 94 09:10:44 +1200

This maybe should be in a GNU group, since it's about GNU's cp program
more than linux, but there's probably more knowledgeable people here
anyway.

Yesterday, while trying to work out how to create a file with holes in it
(to save disk space), I found that merely copying the file did the job
without me having to do anything special. I thought this was a great
feature, but when I looked at the source code to cp, I found that this was
not was intended. (from fileutils-3.9).

The relevant piece of code looks like this:

      /* If the file has fewer blocks than would normally
         be needed for a file of its size, then
         at least one of the blocks in the file is a hole. */
      if (S_ISREG (sb.st_mode) &&
          sb.st_size - (sb.st_blocks * DEV_BSIZE) >= DEV_BSIZE)
        make_holes = 1;

Since sb.st_blocks is unsigned, the comparison is unsigned also. For any
file which does not have holes, and the last block is not completely full
(that's most files), then the LHS evaluates to a negative number, and
make_holes is set true. Even using signed numbers, I don't see why the
comparison is against DEV_BSIZE. Surely it should simply be:
     if ( .. && sb.st_size > (sb.st_blocks * DEV_BSIZE))

I am using kernel 1.0 (in case the type of st_blocks has changed since
then), and the cp source is from fileutils3.9 which came with Slackware
1.2.

If this has been fixed since then you can ignore all the above, but could
someone tell me if there is an accepted way of creating holes in files to
compact them? (I was actually a bit surprised to find that executables
didn't have holes in them!).

-- 
 -------------------------------------------------------------------------
       [email-masked]         A garden is a thing of beauty
 || [email-masked]             and a job forever.
 -------------------------------------------------------------------------

------------------------------

From: [email-masked] (John Saunders)
Subject: Re: time speeds up
Date: Tue, 6 Sep 1994 11:01:29 GMT

York Lam - ACPS/F93 ([email-masked]) wrote:
> Has anyone experienced the clock running abnormally fast?  I set the correct
> time, have had the system up for 1 week or so and the time is now almost
> 15 mins fast.  I gain about 2 mins a day for no apparent reason.

I also get my clock running fast. However after seeing many system unable
to keep accurate time I doubt there is any kernel bug causing it. It's
most likely inaccurate hardware, clocks or timer chips. I would suggest
doing a 'man 8 clock' and reading the stuff about the -a option. Since
doing this I have only gained 7 seconds in the last month. I might even
take the time to tune that down to zero.
-- 
--     .   +----------------------------------------------+
   ,-._|\  | John SAUNDERS - Home  [email-masked] |
  /  OZ  \ |               - Work  [email-masked] |
  \_.-\__/ | "Mmmmmmmm beer..." - Homer Simpson           |
        v  +----------------------------------------------+

------------------------------

From: [email-masked] (Steve Wallace)
Subject: Best PCI viceo and SCSI controller
Date: 8 Sep 1994 03:57:50 GMT

Ok..basicly im looking at a ATI Mach 64 because i need high speed in dos 
and linux and as large a display area as possible. So i'd like to hear 
anything anyones experieced with some of the high end cards. Secondly im 
looking for a nice high speed PCI SCSI controller for my pentium.... I 
like the adaptec 2940 but have heard that its not supported 
currently..and since my MAIN drive will run off it this is going to be a 
key part.....

Thanks for any input
        Steve Wallace Aka Wolruf

------------------------------

From: [email-masked] (Steven Yampolsky)
Subject: Cabletron E21 network card
Date: 8 Sep 1994 03:07:22 GMT

Is there a driver for Cabletron e21 cards in progress?

Does anyone has any idea if this card works with linux.

Any conmments are greatly appreciated.

Steven Yampolsky

P.S. I did look in compatability HOWTO and sunsite: nothing.

------------------------------

From: [email-masked] (Joe George)
Subject: [SERIAL] Parity problems - an update
Date: Wed, 7 Sep 1994 16:23:23 GMT

Hello again,

I've commented on the KERNEL mailing list (and c.o.l.d) about the problems
I'm having with serial communications under DOSEMU, and I wasn't certain if
the problems were in the DOSEMU code or the kernel drivers... I have resons
to believe now that the problems are in the kernel serial drivers. I've had
a hunch about this since my original problem cropped up in the new tty code
when it came out, but all my previous indications seemed to point to DOSEMU.

I've run Minicom and called the odd host that I need to talk to with 7E1
parity (I really have to call it using 7-mark-1 but 7-e-1 gives mostly
correct results) under Linux 1.0.9 and Linux 1.1.49 -- *nothing* had changed
in these two tests except the kernel version (and the two kernels are
configured identically in terms of any options or patches):

Under Linux 1.0.9 I get these results calling 7E1:

* settings set to 38400,7,e,1, kernel 1.0.9
CONNECT 9600

??ENTER SWITCH CHARACTERS
v
??READY TO HOST
??
VM/ESA ONLINE--        --PRESS BREAK KEY TO BEGIN SESSION??
!
S? 
S?Enter one of the following commands: 
S? 
S?   LOGON userid             (Example:  LOGON VMUSER1) 
S?   DIAL userid              (Example:  DIAL VMUSER2) 
S?   MSG userid message       (Example:  MSG VMUSER2 GOOD MORNING) 
S?   LOGOFF 
S?.Q
S?.Qlogoff
S?LOGOFF AT 06:19:03 MDT WEDNESDAY 09/07/94
S?
??ENTER SWITCH CHARACTERS

The "S?" and "??" you see are high order ASCII characters from calling 7E1
instead of 7M1... They're not supposed to be there under 7M1, but under
kernel 1.1.49 and the *exact* same configuration I get:

* settings at 38400,7,e,1, kernel 1.1.49

CONNECT 9600

??NSHHAAS

??NVADSHHAAS
v
??ADYHS
??/E OLIECC   RE RE E TO EI EIO??S? S?En n  h ng mmands  S?   LOO usd             Eamp  LOO ER1) S?   IL usd              Eamp  IL ER2) S?    usd mssag       Eamp   ER2 OO ORI) S?   LOOFF S?S?logoffS?LOOFF T 212 T WEE/7/4S?
??NSHHAAS

??NVADSHHAAS

You see the difference? bits being shuffled all over the place. I should get
*exactly* the same results under 1.0.9 and 1.1.49 but I don't even get close.

Joe

-- 
Joe George ([email-masked], [email-masked])
Great Moments in Usenet news:
"Usenet is a cesspool, a dungheap." -Patrick Townson
"No." -Tim Pierce

------------------------------

Crossposted-To: comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc,comp.os.linux.announce
From: [email-masked] (Mohan Kokal)
Subject: Re: WARNING about shadow-mk package
Reply-To: [email-masked] (Mohan Kokal)
Date: Wed, 7 Sep 1994 18:21:33 GMT

A new release of the package has been uploaded on to :

ftp.procyon.com:/pub/linux/shadow/shadow-mk.tar.gz

This release has the source code for the login.secure program mentioned
by [email-masked]  (Bauke Jan Douma) . The program is abosolutely harmless
and the earlier posts were just an over reaction. If you already have the
package installed from before today, then you do *not* have to get rid of
your /bin/login [which is login.secure] . /bin/login in the mk package
is a wrapper type of program that gets rid of the original /bin/login security
holes of -froot and -h.

Also in this package, the file perms have been fixed for the /bin/login and
/bin/_login files. If you have :

/bin/login as mode 4711 and
/bin/_login as mode 4755

then please change this to

/bin/login as mode 4511 and
/bin/_login as mode 4500

For those of you curious about the login.secure program, the original posting
with the source code is available on ftp.procyon.com in the directory
/pub/linux/shadow as login.secure.gz . As mentioned before, the source code is
also available in the latest release of shadow-mk.

If you have any questions , please email me at any of the following addresses:
[email-masked]
[email-masked]
-- 
Consistency Is Victory. 
[email-masked]                              -Mohan Kokal
--
Send submissions for comp.os.linux.announce to: [email-masked]
Be sure to include Keywords: and a short description of your software.

------------------------------

From: [email-masked]
Subject: Linux OpenDoc  (was: CIL is open, OLE2 closed?)
Date: Wed, 7 Sep 1994 17:24:50 GMT
Reply-To: [email-masked]

In <[email-masked]>, [email-masked] (Jed Harris) writes:
>In article <[email-masked]>, [email-masked]
>(Richard Krehbiel) wrote:
>
>> In article <1994Aug25.140957.1582@debet> [email-masked] (Terje
>Bergesen) writes:
>> >   According to recent articles in comp.sys.powerpc [OpenDoc source is]
>> >   supposed to be free. I wouldn't know though,
>> >   just reporting what I read...
>> 
>> I'll believe that when I see OpenDoc for Linux...
>
>   I'd be very interested in talking with anyone who would like to
>implement OpenDoc for Linux.  I think we could work something out.  
>
>   --Jed Harris, President, Component Integration Labs

OpenDoc is a framework for linking, embedding, and distibuting documents in applictions
across platforms.   The main competing technology is OLE2.  Component Integration
Labs is the company founded by Apple, IBM, Wordperfect and others to manage this technology.
Development of a Linux version of this programming framework would open the possibility
of many commercial OpenDoc applications being developed with Linux versions.

If anyone is interested, they can get information about the technologies from
ftp:\\ftp.cil.org\pub\cilabs.  Then contact Jed Harris.

Cheers!
Bernie Thompson

------------------------------

From: [email-masked] (John Saunders)
Subject: Re: Undelete command for ext2 (Was: Re: Doe
Date: Tue, 6 Sep 1994 10:27:12 GMT

Karl Keyte ([email-masked]) wrote:

> There's no doubt that VMS (through RMS, etc) offers very powerful file
> versioning and control. Problem is - it's a performance nightmare.  I
> remember very well the headaches and disbelief at the time it took to
> do file operations under VMS.

I worked with VMS for about 2 years. Coming from a Unix background I
couldn't come to terms with having multiple file versions cluttering
up the directory. So eventually my subconsious would make me type
PURGE after any command without thinking about it. So in this case I
was suffering the bad performance but not getting any benefit. I
still prefer RCS/SCCS for version control and think that the filesystem
doing version control is stupid. But that's MHO.
-- 
--     .   +----------------------------------------------+
   ,-._|\  | John SAUNDERS - Home  [email-masked] |
  /  OZ  \ |               - Work  [email-masked] |
  \_.-\__/ | "Mmmmmmmm beer..." - Homer Simpson           |
        v  +----------------------------------------------+

------------------------------

Crossposted-To: comp.soft-sys.ptolemy
From: [email-masked] (John Saunders)
Subject: Re: Incremental linking linux (close)
Date: Tue, 6 Sep 1994 10:52:50 GMT

S. Joel Katz ([email-masked]) wrote:
>       If by 'incremental linking' you mean dynamic linking (at run 
> time), libdld works great.

I think the 'ld -r' is what is meant by incremental linking. This allows
several .o files to be linked into another .o file rather than an
executable file. This is an alternative to creating an archive library
.a file. In the first case the .o file isn't scanned but is included
in whole, the .a file is scanned for any modules that are needed.
-- 
--     .   +----------------------------------------------+
   ,-._|\  | John SAUNDERS - Home  [email-masked] |
  /  OZ  \ |               - Work  [email-masked] |
  \_.-\__/ | "Mmmmmmmm beer..." - Homer Simpson           |
        v  +----------------------------------------------+

------------------------------

From: [email-masked] (WE Metzenthen)
Subject: A fix for the mke2fs - floppy bug
Date: 8 Sep 1994 00:45:27 GMT

Hi,
   the bug which causes mke2fs to produce bad floppy disks has been
bugging me, so I decided to have a quick look at it.

   The problem is due to the way in which requests are queued in the
kernel.  A new request is merged with an existing request whenever
possible.  This leads to a "race" condition with the existing floppy
code if the merging amounts to "prepending" a new request to the
request which is currently being processed by the floppy code.

   I can't claim to understand the intent of the authors, but I am not
sure that it makes much sense to "prepend" stuff to the request which
is currently being processed.  Appending can have advantages if the
block device is one which is accessed sequentially, such as is the
case with data on a track of a disk.

   The following patch fixes the floppy problem with mke2fs.  I don't
think that it can introduce a new bug...

--Bill

========================== start of patch ===============================
--- ll_rw_blk.c.old     Tue Aug 16 13:02:32 1994
+++ ll_rw_blk.c Thu Sep  8 09:08:50 1994
@@ -249,7 +249,8 @@
                                return;
                        }
 
-                       if (req->dev == bh->b_dev &&
+                       if (req != blk_dev[major].current_request &&
+                           req->dev == bh->b_dev &&
                            !req->sem &&
                            req->cmd == rw &&
                            req->sector - count == sector &&
=========================== end of patch ================================

--
Bill Metzenthen
Mathematics Department
Monash University
Clayton, Victoria, Australia
email: [email-masked]
       [email-masked]

------------------------------

From: [email-masked] (Steve Kann)
Subject: Debugging TCP connections
Date: 8 Sep 1994 00:45:32 -0400

Since upgrading to 1.1.49, I have been having various problems with
networking, mostly with TCP connections flaking out on me...

(I also have been having nfs server/client problems, so it may not be a
TCP problem, but what makes me think that it is is that one connection
will freeze, while others will continue to operate properly.).

How would one go about debugging this kind of thing?  Is there any way
to get at the "status" of a TCP connection -- i.e. how long since an
apparently lost packet was retried, etc.

This may be due to some changes I made to fix a bug in the lance.c
driver (better changes are in the works), but it does not appear that
that is the case (my changes only are effected when a transmit timeout
occurs, and this case is logged,  I have not seen these timeouts when
the TCP problems happen.

Thanks for any help!

--
- Steve

[email-masked]
[email-masked]

------------------------------

** 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: [email-masked]

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: [email-masked]

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
******************************