Subject: Linux-Development Digest #5
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:     Mon, 8 Aug 94 20:13:10 EDT

Linux-Development Digest #5, Volume #2            Mon, 8 Aug 94 20:13:10 EDT

Contents:
  Re: SLIP speeds 1.0 vs 1.1 (Brian Edmonds)
  Kernel change summary 1.1.39 -> 1.1.40 (Russell Nelson)
  Where should i386/string.h be?  And floppy code report. (FEARNLCJ@DUVM.OCS.DREXEL.EDU)
  Re: Interesting idea for lilo developers (Bill Kress)
  iso9660 file system post v1.1.36 (Allan Clearwaters)
  1.1.29 kernel breaks networking ?! inn/rtin unable to post ! (Andreas Klemm)
  Re: memory segmentation problem (Mike Dowling)
  Something wrong in fs/devices.c (Martin Seine)
  Re: IRQs attached to what? (Donald Becker)
  Re: Linux backup of MSDOS? (bobs@apgea.army.mil (J. Robert Suckling ))
  Re: Interesting idea for lilo developers (Werner Almesberger)
  Re: DEC EtherWorks DE204 support in Linux? (Stephen Thompson)

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

From: bedmonds@prodigy.bc.ca (Brian Edmonds)
Subject: Re: SLIP speeds 1.0 vs 1.1
Date: 8 Aug 1994 10:43:55 -0700
Reply-To: edmonds@cs.ubc.ca

In article <31ttnt$dbg@owl.csrv.uidaho.edu>,
Dan Saunders <saund921@cs.uidaho.edu> wrote:
>: Under 1.0.x kernels, slip (ftp) transfer has averaged about 1.45 K/s
>: Under 1.1.x kernels, slip (ftp) transfer has averaged about 1.01 K/s
>
>I've noticed the same thing.  If anybody knows why, PLEASE let me know!

Strange, I just upgraded from 0.99.13 (with net-2 beta) to 1.1.37 a
couple weekends ago, and noticed no change in my slip transfer speeds.
It still ftps at the 1.6kBps on precompressed data that I've been
getting since the net-2 alpha patches.

--
Brian Edmonds <bedmonds@prodigy.bc.ca>  Prodigy Technologies Corporation
Likely speaking for me.  Nobody pays me enough to speak for anyone else.

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

From: nelson@crynwr.crynwr.com (Russell Nelson)
Subject: Kernel change summary 1.1.39 -> 1.1.40
Date: 08 Aug 1994 17:04:28 GMT

Removed various dead code.
Bug fixed in NCR5380 driver wherein NCR5380_reset would return the
        wrong status.
Forgot to reset status in aha1542_reset().
Avoid problems in scsi drivers by setting the entire struct to zero.
Seagate SCSI driver didn't timeout correctly if status remained busy.
SCSI tape drivers didn't set their device name to NULL.
Added missing umsdos to .../fs/Makefile SUBDIRS.
isofs driver now uses dcache.
isofs driver combines the unixify with the copy to fs.
mmap removed from /proc.
--
-russ <nelson@crynwr.com>    http://www.crynwr.com/crynwr/nelson.html
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)  | What is thee doing about it?
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

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

From: FEARNLCJ@DUVM.OCS.DREXEL.EDU
Subject: Where should i386/string.h be?  And floppy code report.
Date: 8 Aug 1994 17:44:27 GMT

When I recompiled ftape for the 1.1.41 kernel, make died because it             
couldn't find the include line (added in patch41) from                          
linux/include/linux/string.h line 15:                                           
+#include <i386/string.h>       /* inline functions for i386.. */.              
I fixed it with:                                                                
#include </usr/src/linux/include/i386/string.h> /* inline functions             
for i386.. */                                                                   
but I don't like the long path name.  How should this be set up?  In            
/usr/include/i386 I have 3 files (from Slackware 1.1.2 days):                   
-rw-r--r--   1 root     root         2632 Jan 11  1994 fpu_control.h            
-rw-r--r--   1 root     root          274 Jan 10  1994 jmp_buf.h                
-rw-r--r--   1 root     root         3571 Jan 10  1994 syscall.h                
Should /usr/src/linux/include/i386/string.h be moved to                         
/usr/include/i386 or should /usr/include/i386 be made a symbolic link           
to /usr/src/linux/include/i386 like the asm and linux directories?              
 
I decided to test the new floppy code.  It feels much faster.  I can            
move files from a mounted DOS partition to the / partition (which I             
think failed previously - had to cp then rm before).  But reading a             
tar gzipped archive from floppy failed:                                         
(1)~# mount -t msdos /dev/fd0 ~/a:                                              
(1)~# tar ztvf ~/a:/xmitbin.tgz                                                 
/root/a: unknown host                                                           
tar (child): can't open archive /root/a:/xmitbin.tgz : I/O error                
gzip: stdin: unexpected end of file                                             
tar: child returned status 1                                                    
 
I don't believe I ever tried this before, so it may not be new behavior.        
When I cd ~/a: and redo the tar command it works.  So it's an across            
partitions thing.  It's also a floppy code thing, because the same              
failure occurs when I mount an ext2 partition on floppy.  Finally, it's         
definitely a floppy thing because I can tar ztvf across harddrive (ext2         
and msdos) partitions.  Sorry I'm not yet a hacker, so I have no                
suggestions (just reports :).                                                   
 
When I had a floppy mounted, I couldn't access the tape with ftape:             
mt: /dev/ftape: Device or resource busy.  Unmounting the floppy solved          
the problem.  Yesterday I'm quite sure this worked under 1.1.40 (but            
memory could be tricking me :)                                                  
 
I also noticed another bug(?) (though it may not be kernel related). If         
a file is moved from someplace in $PATH to another place in $PATH, the          
shell can't find it and reports "No such file or directory" mentioning          
the old filename and path.  I'm using GNU bash, version 1.13.1-CWRU from        
slackware.  I can logout and log back in and it finds it, implying this         
could be a bash bug??? I really don't understand the way the $PATH is           
stored - must be doing some type of smart stuff to find the files so            
quickly (a hash table???).                                                      
 
These kernels feel pretty stable to me.  Thanks to everyone for the             
hard work.                                                                      
 
Do Enjoy!                                                                       
--                                                                              
Christopher J. Fearnley         UNIX SIG Leader at PACS                         
cfearnl@pacs.pha.pa.us          (Philadelphia Area Computer Society)            
fearnlcj@duvm.bitnet            Design Science Revolutionary                    
fearnlcj@duvm.ocs.drexel.edu    Explorer in Universe                            
503 S 44th ST                   Linux Advocate                                  
Philadelphia PA 1914-3907       (215)349-9681                                   

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

From: kress@kentrox.com (Bill Kress)
Subject: Re: Interesting idea for lilo developers
Date: Mon, 8 Aug 1994 18:38:50 GMT

>In comp.os.linux.development, article <31t0lo$jq6@news.u.washington.edu>,
>  tzs@u.washington.edu (Tim Smith) writes:
>> 
>> If "loadlin" does what it sounds like it does, what is the need
>> for boot managers, anyway?  Note that MS-DOS 6.xx allows you to
>> have multiple configurations, which you can easily select from
>> a menu when config.sys is processed.

I came to the same conclusion over the weekend.  I pulled out my old
batch utility (I wrote it in Debug about 10 years ago on my XT for
the same reason) set up loadlin.  It worked really well.  I can now
choose Linux, Linux/80 rows, Dos, Dos (No TSRs), Dos (Windows), and I'm trying 
tofigure out how to force init level 6 so that it will boot up 
X when I start.  That's 6 configurations.  My program recognizes 9
joystic positions, so I guess I still have room for a few more (Perhaps
I can use one to force linux to auto-dial a slip connection...)

>The big problem with this is that MS-DOG isn't free. 
Well, at least it seems to be a little more flexable than llio, to my
complete supprise. (At least to do what I was attempting to do).  Of
course what makes it so flexable is that Linux has a bootup command
line...

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

From: allan@mct.uucp (Allan Clearwaters)
Date: 08 Aug 1994 16:09:42 GMT
Subject: iso9660 file system post v1.1.36

Has anyone else noticed that the iso9660 filesystem is hosed in
v1.1.41 (I compiled this version of the kernel and it hangs trying to
mount my cdrom).  My cd is a Sony cdu31a - it worked up to patch level
36 - I haven't tried the levels between this and 41.  Is there some
explanation for this??

While I'm on the air, is there a version of gdb that works under the
later 3* kernels??

Any insight would be greatly appreciated.

Thanx,
Al
--

=======================================================================
= Allan Clearwaters             Phone:  44+(684)569292                =
= MCT Ltd.                      Fax:    44+(684)561153                =
= 62 Albert Rd. North           Email:  allan%mct.uucp@britain.eu.net =
= Malvern, Worcs.                       (allan@mct.uucp)              =
= England  WR14 2TL                     The first address guarantees  =
=                                         delivery                    =
=======================================================================

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

From: andreas@knobel.knirsch.de (Andreas Klemm)
Subject: 1.1.29 kernel breaks networking ?! inn/rtin unable to post !
Date: 7 Aug 1994 19:37:43 GMT

When I switched to the Linux 1.1 kernel (I have up to PL 29),
then I get strange network results ...

I can read from a nntp server ( inn 1.4) using rtin, but I 
cannot post either as user nor as root.

The error:

nnrpd[560]: knobel.knirsch.de connect
nnrpd[558]: knobel.knirsch.de post failed 480 Transfer permission denied
                                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
nnrpd[560]: knobel.knirsch.de exit articles 0 groups 0
nnrpd[560]: knobel.knirsch.de times user 0.080 system 0.090 elapsed 0.211
nnrpd[558]: knobel.knirsch.de exit articles 0 groups 0
nnrpd[558]: knobel.knirsch.de posts received 0 rejected 1
nnrpd[558]: knobel.knirsch.de times user 0.400 system 0.450 elapsed 23.064


Has anybody else made some experiences or has anybody a workaround ?
Or perhaps: is this network problem solved in later patches ?

BTW: I'm running Slackware 2.0.0 ... with kernel 1.0.9 everything is fine !

Please answer via e-mail, I'll summarize.

        Andreas ///


--
Andreas Klemm                 /\/\____ Wiechers & Partner Datentechnik GmbH 
andreas@knobel.knirsch.de ___/\/\/     andreas@wupmon.wup.de (Unix Support)

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

From: mike@MooCow.math.nat.tu-bs.de (Mike Dowling)
Subject: Re: memory segmentation problem
Date: 08 Aug 1994 18:11:40 GMT
Reply-To: on.dowling@zib-berlin.de


EHippo> I have a program which works fine when compiled with Borland C++ but
EHippo> yields a segmentation fault when I run it under linux.

I thought that ANSI programs never work with Borland's compiler!  It appears
that the converse is also true.

I compiled your program.  It initially bombed because you did not include the
line 

#include <string.h>

Then it bombed because memset wants 3 args, but only got two.  How did you
compile it? 

More comments in prog.

======== twodim.c ==============
#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>

void *getmem(int);
void fillMatrix(double **, int, int);
void printMatrix(double **, int, int);

main()
{
  int i, j, m, n;
  double **matrix;
  char ans, temp[5];
    
  printf("How many rows? ");
  m = atoi(gets(temp));
    
  printf("How many columns? ");
  n = atoi(gets(temp));
    

This is Pascal!  In C you would use arguments to get n and m.


  matrix = (double **)getmem(m*sizeof(double *));
  
  for (i=0; i<m; i++)
    matrix[i] = (double *)getmem(n*sizeof(double *));



Never allocate a matrix like that!  If you are going to do numerical stuff, the
first rule is to make access to your memory contiguouly.  You cannot, because
the compiler will allocate memory where it sees fit.  For large matrices, that
can be very slow.

Instead, allocate a block of m*n*sizeof(double), and approtion yourself to the
row pointers.



#ifdef PRINT
  printMatrix(matrix, m, n);
#endif

  fillMatrix(matrix, m, n);
  
  printMatrix (matrix, m, n);
}

void *getmem(int size)
{
  void *p;

  p = malloc(size);
  
  if (p == NULL) 
    {
      fprintf(stderr, "Memory problem!\n");
      exit(1);
    }

  memset(p, size);

This is your error.  2 args instaed of 3.  Why call memset at all?  I don't see
the point of it.

etc etc


The program compiles correctly, and runs "as is" on another system, so I
thought I'd ask here.  I hope this is the right newsgroup.

It would not surprise me at all if that program runs with every DOS compiler.
Similarly, it would surprise me if it ran with any UNIX compiler.
--
P.D. Dr. Michael L. Dowling               (__)       on.dowling@zib-berlin.de
Abteilung fuer Mathematische Optimierung  (oo)
Institut fuer Angewandte Mathematik        \/-------\
TU Braunschweig                             ||     | \
Pockelsstr. 14                              ||---W||  *
38106 Braunschweig, Germany                 ^^    ^^    Ph.: +49 (531) 391-7553


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

From: martin@erde.GUN.de (Martin Seine)
Subject: Something wrong in fs/devices.c
Date: Fri, 5 Aug 1994 13:21:09 GMT

Hello,

With Level 24 there was a new kind of device-driver handling introduced. The
check_media_change routine went from buffer.c to devices.c. There's still a
switch-Statement for 'old-coded' device driver, which depends on
config-defines. But nowhere in fs/devices.h is the linux/config.h included,
so the config defines are generally undefined.

I found this, having problems to adapt the LMS-205 CD-ROM (which no works
:-) ) and it's not fixed till .34.

So, if you wonder, why on removeable medias no change was detected ...

ciao
Martin

--
=====================================================================
Martin Seine                                       martin@erde.gun.de
                                        Martin.Seine@FernUni-Hagen.de
Never make anything simple and efficient when a way can be found to 
make it complex and wonderful.


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

From: becker@cesdis.gsfc.nasa.gov (Donald Becker)
Crossposted-To: comp.os.linux.help
Subject: Re: IRQs attached to what?
Date: 8 Aug 1994 18:14:35 -0400

In article <31tqop$6rs@delphinium.cig.mot.com>,
Walter F. Lundby <lundby@rtsg.mot.com> wrote:
>Does linux have any way to show what IRQs are associated with
>what devices while you are running?
>
>I need to know. (Linux 1.06  kernel - Slackware 2.0)

No, it doesn't.

The obvious way to implement this would be with an additional parameter to
irqaction(), but that would change its format from sigaction() and involve
changing a lot of existing code.

A better solution is to add a device name table, irq2name_map[16], and have
drivers register themselves after they successfully get the corresponding
IRQ line with irqaction().

Something like this would be good:

In drivers/net/auto_irq.c add

  struct device *irq2dev_map[16] = {0, 0, /* ... zeroed */};
+ char *irq2name_map[16] = {"Timer", /* ... other standard devices */};

  int irqs_busy = 0x01;         /* The set of fixed IRQs always enabled. */

And add the following to /usr/include/asm/irq.h

+ #define HAVE_IRQ_NAME
+ extern char *irq2name_map[16];


Then drivers that wanted to could do

   if (irqaction(irq,...) ... 
       irq2dev_map[irq] = dev; 
       irq2name_map[irq] = "Frobbitz SuperHyper 6000"; 

and
    free_irq(irq);
    irq2dev_map[irq] = NULL;
    irq2name_map[irq] = NULL;

Once this was in place it would easy to add /proc/net/irq,

prompt% cat /proc/net/irq
IRQ     Count   Flags   Device
 0      79879       0   Timer
...
 11         7       0   Frobbitz SuperHyper 6000
...

-- 
Donald Becker                                     becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center,  Greenbelt, MD.  20771
301-286-0882         http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html

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

From: bobs@apgea.army.mil (J. Robert Suckling <bobs>)
Subject: Re: Linux backup of MSDOS?
Date: Mon, 8 Aug 94 19:26:11 GMT

In article <325hp2$7hi@sun.cais.com>
toehser@cais2.cais.com (Tom Oehser) writes:
>*Actually*, having started this misbegotten thread, the *idea* was not to 
>make gzip do a better job.  Since what I am doing is putting 540mb of 
>data onto a 525mb tape, the *idea* was to find a much dumber faster 
>compression program than gzip --fast, so as to not waste time compressing 
>it down to 300mb of data.

Well, If the data fits do not compress it.  That is the fastest.
And if that is the case, The only speed up might be useful is if
you can compress faster then the tape can write.  Somehow, I think
you need to do some bench marking to be sure if that is the case.

Also be warned, that compresion can not skip over tape errors.
But a raw tar or cpio with out compression can skip over a file.
Ie. should something happen to part of the tape. You can still
read past that and recover data.  Compression is always not a good
thing.  The reason for back up, I assume, is to lower risk.
Using compression is a higher risk then not using compression.

> I would like gzip to do a much worse job.
> Is there a compression program that uses
> much less cpu for less compression, 
> but which will still fit 540 on 525?

"cat"

Note: You will not be filling the disk, so it will all
fit.  Remember 5% of the space is reserved for the super-user,
there are also other places where space is saved.  What ever you do
use some sort of dump program(eg. tar, cpio...) do not do a raw DD.

You coulds do CPIO on each disk one per tape and do incremental
dumps of all your disks most of the time on a single tape.
And when things get tight, For incremental using CPIO you can sum
the space needed while you make the file list.  And if you are
about to over flow a tape.  Simply send the operator(your self)
e-mail so you know what incremental you need to do on the next tape.

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

From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger)
Subject: Re: Interesting idea for lilo developers
Date: 8 Aug 1994 21:27:04 GMT

In article <31t0lo$jq6@news.u.washington.edu> tzs@u.washington.edu (Tim Smith) writes:
> If "loadlin" does what it sounds like it does, what is the need
> for boot managers, anyway?

Well, maybe because ...

 - people may not want to buy/upgrade/borrow/... DOS in order to run Linux
 - creating/leaving one partition for DOS just to act as a boot loader is
   a bit wasteful
 - there are plans to install more operating systems than DOS and Linux,
   so some kind of boot manager is needed anyway

Of course, for people who already have DOS installed and want to keep it
and don't mind taking that extra step when booting, loadlin is probably a
convenient alternative to LILO.

> It seems to me that instead of bothering with fancy boot managers,

Hmm, if you really only want bare-bones functionality, LILO configuration
can be as simple as

# echo compact image=/vmlinuz >/etc/lilo.conf; /sbin/lilo

(Actually, the "compact" is already luxury.) Naturally, this quite
system-independent example even removes "boot manager" functionality.

The problems typically start when funny hardware (e.g. very large disks),
the desire for more features, complex boot setups, etc. come into play.
Life sometimes just ain't easy ;-)

- Werner
-- 
   _________________________________________________________________________
  / Werner Almesberger, ETH Zuerich, CH      almesber@nessie.cs.id.ethz.ch /
 /_______________________________________________almesber@bernina.ethz.ch_/

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

From: steve@redbck.stl.dec.com (Stephen Thompson)
Subject: Re: DEC EtherWorks DE204 support in Linux?
Date: 8 Aug 1994 07:45:24 GMT
Reply-To: steve@redbck.stl.dec.com (Stephen Thompson)




|>This has probably been asked numerous times already, but here goes:
|>
|>Is anyone working on a driver for the DEC EtherWorks DE204 and DE205
|>cards or is support already available?  
|>

No I am sorry, no luck in that department.. We don't even have a beta available
internally but keep an eye out.. 


--
Stephen Thompson - South Pacific Technical Support
Digital Equipment Corp
DTN: 730-5566
+61-2-561-5566                     thompsons@a1.snofsa1.sno.MTS.dec.com
                                   steve@snopc50.stl.dec.com 

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


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