Subject: Linux-Development Digest #226
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sun, 25 Sep 94 17:13:11 EDT

Linux-Development Digest #226, Volume #2         Sun, 25 Sep 94 17:13:11 EDT

Contents:
  Re: [STATUS] Linus Floppy Driver Development (H. Peter Anvin)
  Re: polled ports ("Theodore Ts'o")
  ftape 1.13b overrun ([email-masked])
  Re: 1+ Gig SCSI Drives (H. Peter Anvin)
  Re: elf benchmarks (getting closer) (H.J. Lu)
  Re: AX25 & KISS Amateur Radio Protocols in Linux?? (Mark A. Horton KA4YBR)
  Re: memory leakage in 1.1.51 ? (FIX) (Guenther Thomsen)
  Re: Missing stdarg.h and (sort of) varargs.h (H.J. Lu)
  more floppy problems with 1.1.51 (Steve DuChene)
  Warnings with libc 4.5.26. (Michael H. Price II)
  Re: A badly missed feature in gcc (H. Peter Anvin)

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

From: [email-masked] (H. Peter Anvin)
Subject: Re: [STATUS] Linus Floppy Driver Development
Date: Sun, 25 Sep 1994 16:54:26 GMT

In article <[email-masked]>,
Steve Kneizys <[email-masked]> wrote:
>
>: What if they did something like on the sgi's, where you can specify 
>: a mount point for dos disks, and run a daemon that will mount the floppy
>: automagically (at least, for a dos disk).  Pretty neat though.  Perhaps
>: if we had something like that for msdos disks only, all others needing
>: to be mounted manually (therefore, by root)?
>
>Sounds like a neat idea...if root starts such a daemon, then I like it!
>Having msdos automount, but not minix, would solve much of the security
>problem that I would run into.
>

I personally still prefer the explicit mount command (using the "user"
option in /etc/fstab) for one reason: that way the OS knows who owns
the disk.  If a disk is inserted and something like SGI's mediad is
used, there is nothing that can be done except making it world
read/writeable.  SGI uses it for CD-ROMs, which is much less of a
problem.  It means someone telnetted in can read and wipe your data if
you put it in the disk.

The final problem is that the hardware on PCs doesn't keep you from
ejecting the disk, and if people can insert a disk to have it
mounted, I can guarantee they will not remember to use an explicit
umount.  The only way it can be solved is in hardware (with a
motorized eject mechanism and an eject button that can be overridden
by the OS.  Ideally, the eject button should trap the OS, which could
umount the disk and then eject it).

        /hpa

-- 
This message was sent from a system running Linux, the freeware UNIX
clone.  Get yours from tsx-11.mit.edu or sunsite.unc.edu.

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

From: "Theodore Ts'o" <[email-masked]>
Subject: Re: polled ports
Date: 25 Sep 1994 14:49:52 -0400
Reply-To: [email-masked]

   Date: Sat, 24 Sep 94 20:40:53 -0400
   From: Theodore Ts'o <[email-masked]>

   Sorry for the late followup, but I only had a chance to look at this
   now... Actually FIFO's are disabled a speeds below 2400 --- the only
   thing that happens is that the FCR_TRIGGER is set at 1, so that an
   interrupt is signalled after one character is in the FIFO.  Of course,
   this makes no difference if you are polling.  So the FIFO's are enabled
   even at speeds below 2400 bps, and so getting a 16550A chip if you are
   doing polled operations is highly recommended.

Oops... typo.  The second line should read, "Actually, FIFO's *aren't*
disabled at speeds below 2400"....

Hopefully the general thrust of the message was still clear, but just in
case it wasn't, I wanted to clear things up.

                                                - Ted

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

From: [email-masked]
Subject: ftape 1.13b overrun
Date: 25 Sep 1994 14:53:17 -0400
Reply-To: [email-masked]

Date: Sun, 25 Sep 1994 17:03:58 +0000
From: Andre Couture <[email-masked]>
Sender: Andre Couture <[email-masked]>
Reply-To: Andre Couture <[email-masked]>
Subject: ftape 1.13b overrun
To: Bas Laarhoven <[email-masked]>
cc: "comp.os.linux.help" <[email-masked]>, 
    "comp.os.linux.development" <[email-masked]>
Message-ID: <Pine.3.89.9409251602.A3133-0100000@cyborg>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII

I have installed the ftape1.13b, 
compiled ok, installed ok, ...

The problems are when I write to tapes, I get a lots of write errors and 
also a lots of overruns.

The tape has been formatted under DOS or Windows (CBWLITE) ? not too sure 
as my brother did it!

Is there any formatting tools comming up for Linux?

Does anybody experiencing the same problems?

My system is:
486dx50 EISA
20MB RAM
Adaptec 1742A (EISA-Enhanced mode)
Colorado 250MB attached to the floppy.
Quantum LPS525 HDD

OS Kernel 1.1.51

Here is some info from the messages file:

[005]    fdc-io.c (fdc_config) - FC-10 controller not found.
[006]    fdc-io.c (fdc_probe) - Type 82077 or compatible FDC found.
[007]    fdc-io.c (fdc_fifo_enable) - fifo already enabled, thresshold 0.
[008]   fdc-io.c (fdc_init) - FDC fifo successfully enabled.
[009]  ftape-io.c (_ftape_open) - drive wakeup method: Colorado.
[010]    ftape-io.c (ftape_report_raw_drive_status) - warning: error status

set!
...
[023]   ftape-io.c (ftape_report_error) - errorcode: 26.
[024]   ftape-io.c (ftape_report_error) - Non-Fatal ERROR:.
[025]   ftape-io.c (ftape_report_error) - Power On Reset Occurred ....
[026]   ftape-io.c (ftape_report_error) - ... caused by unknown command 0.
[027]  ftape-io.c (_ftape_open) - error code   : 26.
[028]  ftape-io.c (_ftape_open) - error command: 0.
[029]  ftape-io.c (_ftape_open) - status: new cartridge.
[030]   ftape-io.c (ftape_report_vendor_id) - got 16 bit id: 0047.
[031]   ftape-io.c (ftape_report_vendor_id) - CMS rom version: 87.
[032]   ftape-io.c (ftape_report_vendor_id) - CMS signature: a5.
[033]   ftape-io.c (ftape_report_vendor_id) - CMS status: 4.
[034]  ftape-io.c (_ftape_open) - ftape drive type is: Colorado
DJ-10/DJ-20.
[035]   ftape-io.c (ftape_set_data_rate) - Data rates set to 1 Mbps.
[036]   ftape-io.c (ftape_get_tape_parameters) - segments_per_cylinder 4.
[037]   ftape-io.c (ftape_get_tape_parameters) - segments_per_track 150.
[038]   ftape-io.c (ftape_get_tape_parameters) - segments_per_head 600.
[039]   ftape-io.c (ftape_get_tape_parameters) - sectors_per_segment 32.
[040]   ftape-io.c (ftape_get_tape_parameters) - tracks_per_tape 28.
[041]   fdc-io.c (fdc_init) - FDC fifo successfully enabled.
[042]    ftape-read.c (read_header_segment) - segments-per-track:   150.
[043]    ftape-read.c (read_header_segment) - tracks-per-cartridge: 28.
[044]    ftape-read.c (read_header_segment) - max-floppy-side:      6.
[045]    ftape-read.c (read_header_segment) - max-floppy-track:     149.
[046]    ftape-read.c (read_header_segment) - max-floppy-sector:    128.
[047]    ftape-read.c (read_header_segment) - first data segment: 2.
[048]    ftape-read.c (read_header_segment) - `last' segment is 4199, 29
Kb.
[049]    ftape-read.c (read_header_segment) - 121652 Kb usable on this
tape.
[050]     ftape-eof.c (extract_file_marks) - number of file marks: 10.
[051]     ftape-eof.c (extract_file_marks) - eof mark in segment 17, sector
10.
[052]     ftape-eof.c (extract_file_marks) - eof mark in segment 18, sector
1.
[053]     ftape-eof.c (extract_file_marks) - eof mark in segment 20, sector
17.
[054]     ftape-eof.c (extract_file_marks) - eof mark in segment 21, sector
1.
[055]     ftape-eof.c (extract_file_marks) - eof mark in segment 500,
sector 6.
[056]     ftape-eof.c (extract_file_marks) - eof mark in segment 501,
sector 1.
[057]     ftape-eof.c (extract_file_marks) - eof mark in segment 554,
sector 7.
[058]     ftape-eof.c (extract_file_marks) - eof mark in segment 555,
sector 1.
[059]     ftape-eof.c (extract_file_marks) - eof mark in segment 641,
sector 9.
[060]     ftape-eof.c (extract_file_marks) - eof mark in segment 642,
sector 1.
[061]   fdc-io.c (fdc_init) - FDC fifo successfully enabled.
[062]   fdc-io.c (fdc_init) - FDC fifo successfully enabled.
[063]   fdc-io.c (fdc_init) - FDC fifo successfully enabled.
[064]   ftape-write.c (_write_segment) - empty segment, nothing written.
[065]   ftape-write.c (_write_segment) - empty segment, nothing written.
[066]  fdc-isr.c (fdc_isr) - single overrun error.
[067]   fdc-isr.c (determine_progress) - Unexpected error at sector offset
0.
[068]     ftape-rw.c (ftape_smart_stop) - tape stopped passing segment: 12.
[069]   ftape-write.c (_write_segment) - write error, retrying (0).
[070]  fdc-isr.c (fdc_isr) - single overrun error.
[071]   fdc-isr.c (determine_progress) - Error at sector offset 2.
[072]   fdc-isr.c (retry_sector) - request skipping of 3 sectors.
[073]     ftape-rw.c (ftape_smart_stop) - tape stopped passing segment: 23.
[074]   ftape-write.c (_write_segment) - write error, retrying (0). 
[075]     ftape-write.c (copy_and_gen_ecc) - bad sectors in map: 1.
[076]           ftape-rw.c (setup_segment) - segment: 30, bad sector map:
000000
[077]        fdc-isr.c (fdc_isr) - single overrun error.
[078]         fdc-isr.c (determine_progress) - Error at sector offset 13.
[079]         fdc-isr.c (retry_sector) - request skipping of 15 sectors.
[080]     ftape-rw.c (ftape_smart_stop) - tape stopped passing segment: 31.
[081]       ftape-rw.c (setup_segment) - segment: 30, bad sector map:
00000040.
...
[244]  ftape-io.c (_ftape_close) - error: unable to update header segments.
[245]  ftape-io.c (_ftape_close) - == Non-fatal errors this run: ==.
[246]  ftape-io.c (_ftape_close) - fdc isr statistics:.
[247]  ftape-io.c (_ftape_close) -  id_am_errors     : 4.
[248]  ftape-io.c (_ftape_close) -  id_crc_errors    : 0.
[249]  ftape-io.c (_ftape_close) -  data_am_errors   : 0.
[250]  ftape-io.c (_ftape_close) -  data_crc_errors  : 0.
[251]  ftape-io.c (_ftape_close) -  overrun_errors   : 78.
[252]  ftape-io.c (_ftape_close) -  no_data_errors   : 9.
[253]  ftape-io.c (_ftape_close) -  retries          : 91.
[254]  ftape-io.c (_ftape_close) - repositions       : 90.
[255]  ftape-io.c (_ftape_close) - last segment      : 2251.
[000] kernel-interface.c (ftape_close) - _ftape_close failed.

=====
Andre Couture,
[email-masked] (prefered)
     _/_/_/_/  _/_/_/_/  _/_/_/_/         Centre Informatique Couture
    _/           _/     _/         938934 Ontario Inc.  Phone:
+1-613-762-0262
   _/           _/     _/          155 Queen St.        FAX:  
+1-819-775-9697
  _/           _/     _/           Suite 900            Roma: 
+39/6-5125-745
 _/           _/     _/            Ottawa, Ontario      Delphi:    
CoutureA
_/_/_/_/. _/_/_/_/. _/_/_/_/.

@receiver file

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

From: [email-masked] (H. Peter Anvin)
Subject: Re: 1+ Gig SCSI Drives
Reply-To: [email-masked] (H. Peter Anvin)
Date: Sun, 25 Sep 1994 17:45:32 GMT

Followup to:  <[email-masked]>
By author:    [email-masked]
In newsgroup: comp.os.linux.development
> 
> > I once read a rumor about a new filesystem standard.  I believe that
> > ALL unices are limited to 2G partition sizes due to the 32 bit file
> > pointer accepted by the standard OS entry points.  Perhaps there is a
> > movement afoot to go to 64 bit pointers as did Microsoft with Windows
> > NT.
> 
> Linus introduced 64 bit pointers recently. 
> 

No.  They are, however, limited to 2 Gb *files* unless long is more
than 32 bits.

-- 
INTERNET: [email-masked]             --- Allah'u'abha ---
IBM MAIL: I0050052 at IBMMAIL     HAM RADIO:   N9ITP or SM4TKN
FIDONET:  1:115/511 or 1:115/512  STORMNET:    181:294/1 or 181:294/101
#include <sig/virus.h>

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

From: [email-masked] (H.J. Lu)
Subject: Re: elf benchmarks (getting closer)
Date: 25 Sep 1994 12:43:34 GMT

H.J. Lu ([email-masked]) wrote:
: John Richardson ([email-masked]) wrote:
: : As a quick followup to my very unscientific benchmark: 
: :  
: : The with the latest gcc (23-Sept) and the 4.6.11 elf libraries,  
: : elf narrows the time gap to about a 3.5% difference using the qsort() test.

: The ELF/PIC library may not be in core all the time. The ELF binary
: may have to load it everytime it runs. Please re-compile your login
: shell with ELF and then re-run the "benchmark." If that is the case,
: ELF may be faster :-).

Here are my 100000 qsort results:

# time aout; time aout; time aout; time elf; time elf; time elf
117.76user 0.05system 1:58.87elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
95.44user 0.02system 1:35.74elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
124.47user 0.02system 2:05.69elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
98.95user 0.06system 1:39.52elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
85.78user 0.08system 1:26.96elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps
105.15user 0.15system 1:46.06elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+0minor)pagefaults 0swaps

No, that is not a typo. ELF may be faster than a.out. But don't take
the result as is. 1000000 iterations are too small. The "benchmark"
varies a lot for both a.out and ELF. We need a better benchmark for
the ELF/PIC library. Also an ELF login shell makes a big diference.

BTW, my login is an ELF zsh and my machine is 486DX2/66 with 16 MB RAM.

--
First I thought he was on hunger strike. Later I was told he was
praticing YanXin QiGong.

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

From: [email-masked] (Mark A. Horton KA4YBR)
Subject: Re: AX25 & KISS Amateur Radio Protocols in Linux??
Date: Sun, 25 Sep 1994 14:55:25 GMT

Grant Edwards ([email-masked]) wrote:
: Alan Cox ([email-masked]) wrote:
: : [email-masked] (Vassili Leonov) writes:

: : >The original identity of the HAM radio is to be at the frontier and
: : >benefit the humanity - and free of charge... It's public service -
: : >running a NON-COMMERCIAL network on top of that is no contradiction.

: : ROTFL. The real motivation for most Governments allowing amateur radio is a 
: : handy supply of radio trained people in case a war turns up.

: Back when knowing Morse code was considered a useful skill by the
: military, that was probably (at least partially) true.  Does anybody
: besides hams use Morse these days?

Hi Grant!

        Not trying to start any arguments or anything :) , but I know of some
        (I'm sure there are others, but I don't know them) non-ham uses for
        Morse these days that I've heard. :

                Aircraft navigation and communication (the station ids
                on omnis and such so you can tell which one you're
                homing on)
                        
                Commercial repeaters (paging systems, etc.)

                Some marine navigation beacons (I don't know very much about
                these. )

        -- Mark 
--
"Linux!     Guerrilla UNIX Development     Venimus, Vidimus, Dolavimus."
============================================================
Mark A. Horton       ka4ybr             [email-masked]
P.O. Box 747 Decatur GA US 30031-0747         [email-masked]
+1.404.371.0291                     33 45 31 N / 084 16 59 W

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

From: [email-masked] (Guenther Thomsen)
Subject: Re: memory leakage in 1.1.51 ? (FIX)
Date: 23 Sep 1994 16:17:15 GMT

'xcuse me, I'm sorry. It's not a bug, it's a feature !  Yes,
really. Since 1.1.? there is a new swapping strategy implemented:
pages swapped in (paged in from swap-space) aren't removed from the
swap- space like in older linux versions. This should improve speed,
if the pages are often swapped in but not modified. But the
disadvantage is, that you need now more swap space (like the old
sys5(?)-rule: 2 times your RAM), because now the max. usage of swap
space per process, if the process can't share memory with others, is
it's virtual memory size - the size of the text-segment, wich is
stored in the file system and is read-only.

So, if I start two gnuchessx processes, with a virtual size of about 8MB
each, and X is running and a few net daemons,gettys,xterms and shells
 are sleeping, then the total virtual size is about 30MB. With 8MB RAM
I then have to offer about 20..30 MB of swap space. In this Example
Linux-1.1.51 used about 18MB, but it takes a while, until every page of
the processes is swapped out at least one time. The swap space usage
seems to grow, but it will reach a maximum.

Ok, not a bug, but for an 'old' linuxer somewhat strange.

PS: It may be a FAQ, or it will be. I have to say, that I didn't read
the recent ones ;-)

-- 
G\"unther Thomsen                          send eMail to [email-masked]

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

From: [email-masked] (H.J. Lu)
Subject: Re: Missing stdarg.h and (sort of) varargs.h
Date: 25 Sep 1994 17:09:30 GMT

In article <[email-masked]>, [email-masked] (Stephen Vance) writes:
|> Has anyone noticed the conspicuous absence of stdarg.h?  Or that there is
|> a <sys/varargs.h> which tries to include a non-existant <varargs.h>?  This
|> is true of the 1.0.8 source tree as well as a 1.1.49 tree patched up from
|> a 1.1.29 base.  It sort of complicates a port I'm working on, but I'll
|> create one for everyone if I need to.
|> 

Just do

#include <stdarg.h>

it will be there. It is a magic :-). Seriously, your compiler was not
installed right. Where did you get your system? Slackware?

H.J.

|> Steve

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

From: [email-masked] (Steve DuChene)
Subject: more floppy problems with 1.1.51
Date: 25 Sep 1994 15:06:11 -0400

        I applied the patch suggested to floppy.c (changing 
        if(filp->f_mode & 2) to if(filp && (filp->f_mode & 2)) and that
        seemed to take care of the kernel dumps I was getting everytime 
        I umounted a floppy. However I had a umount go into uninterruptible 
        sleep yesterday and I am getting the following errors in /var/adm/
        messages:       

Sep 24 07:35:07 jaguar kernel: floppy: timeout
Sep 24 07:35:07 jaguar kernel: floppy I/O error
Sep 24 07:35:07 jaguar kernel: dev 024C, sector 2
Sep 24 07:35:52 jaguar kernel: floppy: unexpected interrupt
Sep 24 07:35:52 jaguar kernel: VFS: Disk change detected on device 2/28
 
        I didn't get an kernel dump occurring though so I guess progress is 
        being made on this problem. BTW, I had several of these same error
        message sets in the message file but not all caused the process to
        go into uninterruptible sleep. It was only after mounting and 
        umounting several floppies in trying to clean up some of the 
        downloaded files that had been accumulating on my harddrive that the 
        sleeping process happened. 
-- 
| Steven A. DuChene   [email-masked]  or  [email-masked]      
| Youngstown State University  | Computer Science / Math / Mech. Eng.
|-------------------------------------------------------------------
|       Friends don't let friends do DOS

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

From: [email-masked] (Michael H. Price II)
Subject: Warnings with libc 4.5.26.
Date: 23 Sep 1994 19:52:35 GMT
Reply-To: [email-masked]

Before I actually install libc-4.5.26, am I supposed to get a million
warnings while compiling it or should it compile quietly?

Michael

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

From: [email-masked] (H. Peter Anvin)
Subject: Re: A badly missed feature in gcc
Reply-To: [email-masked] (H. Peter Anvin)
Date: Fri, 23 Sep 1994 16:04:55 GMT

Followup to:  <[email-masked]>
By author:    [email-masked] (H. Peter Anvin)
In newsgroup: comp.os.linux.development
> 
> Append to the line immediately following it:
> 
> %{!ansi:-lang-c++ %{c:-U__cplusplus}}
                    ^^^^^^^^^^^^^^^^^^

Actually this turns out to be both redundant and incorrect.  The best,
thus, I have managed to come up with is:

%{!ansi:-lang-c++}

This should work as long as there are no files in the C++ include
directories that conflict with any in the C include directories.  I
haven't still figured out how to get it to properly pass the
-nostdinc++ flag if you are not compiling a C++ program.  Nothing I
have tried has worked properly, so it is probably best to leave it
out.

-- 
INTERNET: [email-masked]             --- Allah'u'abha ---
IBM MAIL: I0050052 at IBMMAIL     HAM RADIO:   N9ITP or SM4TKN
FIDONET:  1:115/511 or 1:115/512  STORMNET:    181:294/1 or 181:294/101
"NT is not a bad thing if I don't have to use it..."  -- [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
******************************