Subject: Linux-Development Digest #78
From: Digestifier <Linux-Development-Request@senator-bedfellow.MIT.EDU>
To: Linux-Development@senator-bedfellow.MIT.EDU
Reply-To: Linux-Development@senator-bedfellow.MIT.EDU
Date:     Thu, 9 Sep 93 04:28:50 EDT

Linux-Development Digest #78, Volume #1           Thu, 9 Sep 93 04:28:50 EDT

Contents:
  Re: ** IDE Multiple Mode Patch ** (Steve Lord)
  Re: Linux Standards (was Re: Debian: a brief status report) (Robert W. Brewer)
  Re: Linux Standards (was Re: Debian: a brief status report) (Daniel Quinlan)
  Re: kernel/utility fixes to telnet and rlogin (Craig Milo Rogers)
  Re: ** IDE Multiple Mode Patch ** (Kai Kretschmann)
  Re: SLIP, Compressed vs. uncompressed Headers (Bill Davidsen)
  Re: ISODE on Linux? (Phil Packer)
  Re: AT1500&AT1700 Ethernet cards (Donald J. Becker)
  AT1500&AT1700 Ethernet cards  (Russell Nelson)
  Re: ** IDE Multiple Mode Patch ** ident drive failure ** (Kevin Smolkowski)
  Re: ** IDE Multiple Mode Patch ** (Michael O'Reilly)
  Re: Linux Standards (was Re: Debian: a brief status report) (Lars Wirzenius)
  Re: ** IDE Multiple Mode Patch ** (Simon J Ferrett)

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

From: lord@pecan.cray.com (Steve Lord)
Subject: Re: ** IDE Multiple Mode Patch **
Date: 8 Sep 93 12:42:39 CDT


In article <1993Sep7.155843.3260@bmerh85.bnr.ca>, mlord@bnr.ca (Mark Lord) writes:

> In article <1993Sep7.030025.25084@bmerh85.bnr.ca> mlord@bnr.ca writes:
> >This patch (unofficial) can be applied to enable "multiple sector mode"
> >operation in systems with IDE drives.  Virtually all recent IDE drives include
> >support for this, and those that don't should be unaffected by the patch.
> ...
> >+#define MAX_NO_INTR 10      /* max sector I/O with interrupts masked */
> >+                            /* most reads are (blocksize+readahead) = 10 */
> 
> If you have trouble with missed serial port interrupts, you will want to
> adjust the MAX_NO_INTR count to a value smaller than the default of 10.
> Try 4 or 2 or 1 instead.  I may eventually make 2 the default.
> 
> ... 
> >Also included is a bit of bloat-potential, with #ifdefs to remove if desired,
> >to query the drive parameters of an IDE drive, and to display the results
> ...
> >+#define IDENTIFY_DRIVE      1       /* undef to conserve kernel memory */
> 
> It has now been noted by one respondent that the drive identification toy     caused a kernel panic for one IDE drive on his system, so he had to undef
> it from the patch.  No harm done.
> -- 
> mlord@bnr.ca  Mark Lord       BNR Ottawa,Canada       613-763-7482

We are not related (so far as I know) :-)



This gave me about a 35% speed up using iozone (with 19 Mbyte files),
but it also meant that I couldn't touch my modem and disk at the same
time, it must be missing those interrupts like crazy. I experimented
with MAX_NO_INTR all the way down to 2, the interrupt loss was still
there (less frequently), but the throughput gain disappeared
all together :-(, in fact dropping MAX_NO_INTR below 10 meant that
most of the speed up disappeared.

Have other people had this problem? Is there a solution, some form of
dynamic tuning of MAX_NO_INTR perhaps? Although that doesn't feel like
a guaranteed solution.

Steve
-- 

==============================================================================
Steve Lord                                      voice: +1-612-683-5291
Cray Research Inc                               email: lord@cray.com

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

From: rwb114@cac.psu.edu (Robert W. Brewer)
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Date: 8 Sep 1993 20:19:00 GMT
Reply-To: rwb114@cac.psu.edu

Patrick J. Volkerding (bf703@cleveland.Freenet.Edu) wrote in <26ii8m$m6i@usenet.INS.CWRU.Edu>:
>By all means though, feel free to start with the install scripts from
>the Slackware boot disk. They work with the same package format, so it
>should be easy enough. Make sure to get them from version 1.0.2, because 
>earlier versions still contained pieces of "forbidden" code.

There's something called StopALOP available in the BETA/packages
directory on tsx-11 which is supposed to do this.  StopALOP is 
short for "Stop A Lot Of Problems" and is supposed to be a pretty good
package maintenance/version control/installation script.  I haven't 
used it much yet, but the docs are promising.  I think the Debian
developer is going to use it as his installation system.

-Rob
--
Robert W. Brewer        Linux and XFree86:  Two great tastes...

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

From: quinlan@ivory.cs.bucknell.edu (Daniel Quinlan)
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Date: 08 Sep 1993 21:19:30 GMT
Reply-To: quinlan@spectrum.cs.bucknell.edu


bill@fs1.rockefeller.edu (Bill Rielly) writes:

> >sens@FASECON.ECON.NYU.EDU (Sunando Sen) writes:
> >
> >Yes, it would simplify the whole story, if we would accept the
> >System V R4 directory structure as a quasi standard.
> 
> If I remeber correctly, there is a directory structure described in the
> Linux System Administration Guide. Why not use that as the "standard"? Or
> at least coordinate with its authors so that it can document a standard for
> use by software delvelopers.

First of all, the Linux System Administration Guide is documentation,
not a standard, mind you, even worse it is documentation that is only
in the ALPHA stage.

Second, it only explains how to work with the broken standard
filesystem arrangement that substandard packages like SLS utilize.

Third, it is not comprehensive (in terms of naming all standard
directories).

Fourth, a single person wrote most of it, seemingly to help people to
work with SLS (and exclude other better releases).  It even goes so
far to document to poorly documented SLS that it names SLS specific
(i.e. utterly nonstandard) directories.  If people used MCC (with
excellent (wonderful!) documentation and installation directions) this
guide would not even be required.

Fifth, there is a group of people (administrators, users, and
developers) and so on already working on a file standard to be used.
The FSSTND channel of the Linux-activists mailing list is conducting
an extensive attempt to find solutions to the many problems of Linux
not having a file system standard.  If you wish to join, we welcome
input, but we ask that you not flame or post without knowing what is
going on.  Discussion has been going on for a long time and most
topics have been discussed.  The eventual product of the group will be
a standard (voluntary, of course) for developers to follow.

Now, before you flame me, I do wish to say that the SAG is a very
excellent piece of documentation that will really help people run
their systems.  Lars Wirzenius and everyone else of the LDP has done a
great job helping SLS do the job they could not.

You may wish to know that I am coordinating the compilation and
writing of the FSSTND's first draft of the filesystem standard (which
is not ready for public release quite yet, no ALPHA's here folks,
sorry) so if you have any questions or flame me for not liking SLS, I
would be very happy to answer anyone through email.

 Dan

--
================================
Daniel Quinlan
quinlan@spectrum.cs.bucknell.edu

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

From: rogers@drax.isi.edu (Craig Milo Rogers)
Subject: Re: kernel/utility fixes to telnet and rlogin
Date: 8 Sep 1993 16:29:50 -0700

In article <Sep.8.01.03.48.1993.15980@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
>The code works on both, except that rlogin does not always
>send the window size with the netBSD code.  I'm not sure exactly what
>the problem is, but I suspect SIGURG is not being sent somewhere that
>it should be in the kernel.

        Er, this is speculation on my part, but, after all, rlogin is
not strictly a TCP protocol: it requires guaranteed delivery of Urgent
pointers, while the TCP spec. (RFC 793, Sep. 1981) allows Urgent
pointer compaction (p. 42, p. 47).  BSD Unix' TCP implementation
extends the TCP protocol and attempts to guarantee Urgent pointer
delivery.  If Linux' "native" TCP was written to spec. without
knowledge of the BSD extensions, then there's a good chance that
rlogin will break.

        One solution is to use the telnet protocol, which has recently
had options defined to allow it to substitute for rlogin.

                                        Craig Milo Rogers

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

From: kai@fix.kmk.rhein-main.de (Kai Kretschmann)
Subject: Re: ** IDE Multiple Mode Patch **
Date: Wed, 8 Sep 1993 13:41:23 GMT

Hello, I did include your patch but it failed to boot.
I disabled it thru hacking for my first drive and now
it works for the second one like a champ!
Do you know what could be wrong with this configuration:

+-------------------------------------------------------------------+
hda:  Drive identification info:
 Model=Maxtor 7120 AT, FwRev=305730, SerialNo=A20RRH1S
 Config={ sHard NotMFM HdSw>15uSec Fixed DTR>5Mbs FmtGapReq }
 Default c/h/s=936/16/17, TrkSize=10336, SectSize=608, ECCbytes=4
 BuffType=DualPortCache, BuffSize=64KB, MaxMultSect=16
 DblWordIO=yes, LBA=no, DMA=no, tPIO=slow, tDMA=slow
 (maybe): Current c/h/s=0/0/0, TotSect=0, LBAsect=0
 (maybe): MultSect=0, DMA-1w=0000, DMA-mw=0000
+-------------------------------------------------------------------+

  hda: hda1 hda2 hda3

+-------------------------------------------------------------------+
hdb:  Drive identification info:
 Model=Maxtor 7245 AT, FwRev=6ADJ1E57, SerialNo=C400FRHS
 Config={ sHard NotMFM HdSw>15uSec Fixed DTR>5Mbs FmtGapReq }
 Default c/h/s=967/16/31, TrkSize=19778, SectSize=638, ECCbytes=11
 BuffType=DualPortCache, BuffSize=64KB, MaxMultSect=32
 DblWordIO=yes, LBA=no, DMA=no, tPIO=fast, tDMA=fast
 (valid): Current c/h/s=967/16/31, TotSect=1368391687, LBAsect=0
 (valid): MultSect=0, DMA-1w=0000, DMA-mw=0000
+-------------------------------------------------------------------+

  hdb: Enabled 16-sector multiple mode
  hdb: hdb1 hdb2



The pure patch always enabled multiple mode on hda, too. Nut then I
got interupt status 50 for eight times until it finaly gave up.

Nevertheless, it's worth trying this thing. It doubled my speed up
to about 1MB/sec!

You won a cup of coffee :-)
-- 
Kai Kretschmann,
  >>>   FidoNet:  2:248/312, 21:100/5729, 16:100/6006    <<<
  >>>   Internet: kai@fix.kmk.rhein-main.de              <<<
  >>>   FAX/BBS:  +49-6172-305379                        <<<

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

From: davidsen@sixhub.tmr.com (Bill Davidsen)
Subject: Re: SLIP, Compressed vs. uncompressed Headers
Reply-To: davidsen@tmr.com (bill davidsen)
Date: Thu, 9 Sep 1993 00:49:14 GMT

In article <1993Sep4.182653.3792@sky.GUN.de> gt@sky.GUN.de (Guido Thater) writes:
| Is it planned to toggle between compressed and uncompressed SLIP-Headers
| without rebooting Linux with a differend Kernel?
| 
| As far as I know all of the relevant stuff is in /usr/src/linux/net/inet/slip.c
| and it seems to me that it is a not a big job to change SLIP's behaviour at
| runtime, for example depending on a configuration-file.

I'd love to see something a bit more robust than that. UUCP can change
paramaters on a site basis, why not SLIP? I have to link to a brain-dead
Sun which runs uncompressed headers. I would like to also talk to others
who have gone to CSLIP.
-- 
Bill Davidsen, davidsen@tmr.com
    TMR Associates, +1 518-370-5654
    C programming, training, data gathering, porting to open systems,
    heterogeneous environments, computer controlled housing, custom software

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

From: pep@wicked.demon.co.uk (Phil Packer)
Subject: Re: ISODE on Linux?
Reply-To: pep@wicked.demon.co.uk
Date: Wed, 1 Sep 1993 07:46:02 +0000

In article <341.2C83B57B@purplet.demon.co.uk> jaggy@purplet.demon.co.uk (Mike Jagdis) writes:
> * In message <746690354snx@wicked.demon.co.uk>, Phil Packer said:
> 
> PP> Now if you could mail the _patches_..... <grin> I could get
> PP> straight on with PP which is the bit I really want to get going!
> 
> Well, after waiting a day or so for ISODE to compile maybe :-). Not to 
> mention wading through the 5+ manuals figuring out how to configure things 
> :-).
>                                 Mike  
>  
Yes it's great for exercising your processor, hard disk, ram, mind......

<grin>

PeP


|          Cuius testiculos habes, habeas cardia et cerebellum                |
+-----------------------------+-----------------------------------------------+
|Phil Packer                  | pep@wicked.demon.co.uk          (home)        |
|165 Stourton Avenue Hanworth | pep@cix.compulink.co.uk         (deprecated!) |
|Middlesex, England TW13 6LD  | pp1071bh.bbc-bh@mail.radio.bbc.co.uk (in beta)|
| 044 +81 898 0101            | PP1071BH@BBC-BH [via NHUB]      (MHS)         |
| #include <very_long_x400_address.h>                                         |
|         wicked is not associated with any other demon dial-up site          |
+-----------------------------------------------------------------------------+

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

From: becker@super.org (Donald J. Becker)
Subject: Re: AT1500&AT1700 Ethernet cards
Date: Wed, 8 Sep 1993 17:43:34 GMT

In article <1993Sep8.115916.14543@cognos.com> naubertp@cognos.COM (Patrick Naubert) writes:
>
>Remember not too long ago, someone posted a message about Allied Telesis
>selling an Ethernet card for < $32.00 ?
>
>Here's the info : Company : Allied Telesis
>                  Card    : AT-1700T 
>                  Medium  : 10-baseT
>                  IRQs    : 3 4 5 9
>                  Base IO : 300h (def), 240h,260h,280h,2a0h,320h,340h,380h
>                  ROM addr: (disabled), C4000h,C8000h,CC000h,D0000h,D400h,D8000h
>                     (This is ROM chip address, not shared RAM.  There is no
>                      shared RAM as far as I can tell...)
>                  Chipset : Dunno, but the main chip is AM79C960KC 309MVX7 B1 @1992 AMD
>                  Bus     : ISA
>   Didn't come with packet drivers, only NDIS and ODI.

The AT1500 is a bus-master ethercard based on a recently released AMD LANCE,
the AM79C960 "PCnet-ISA".  This single chip handles almost everything
needed for a fast ISA bus-master ethercard.  The only thing unique to
the Allied Telesis design is the EEPROM setup. 

The 0.99pl12 kernel includes my AT1500 driver.  You probably should
wait for the pl13 kernel, or may wish to test the alpha-pl13 on
nic.funet.fi.

I'm a little confused by your report above -- is it correct? I thought
the AT1700 used a new Fujitsu chip.  

>If anyone has any info on these things to run on Linux, please gimme a "ring".
>Also, if I am going to have to write a driver for these guys, please send
>me examples on how to go about it (I know C...).  Donald ?
>I will call the company to get any necessary info.

Please do call them and ask about the Linux driver, or at least tell
them you are using it with Linux and ask about driver upgrades.  If
they hear that people are using their product with Linux they are more
likely to support future Linux device drivers.

-- 

Donald Becker                                          becker@super.org
IDA Supercomputing Research Center
17100 Science Drive, Bowie MD 20715                        301-805-7482

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

From: nelson@crynwr.com (Russell Nelson)
Subject: AT1500&AT1700 Ethernet cards 
Date: Thu, 09 Sep 93 02:53:18 GMT

In article <1993Sep8.115916.14543@cognos.com> naubertp@cognos.COM writes:

   Remember not too long ago, someone posted a message about Allied Telesis
   selling an Ethernet card for < $32.00 ?

   Well, I bought 2 : an AT1500 and an AT1700.

   They look nice :-)   Linux (P9) doesn't recognize them :-(

The Hyperactive Donald Becker has an AT1500 driver.  Dunno if he
plans to do an AT1700 driver.

      Didn't come with packet drivers, only NDIS and ODI.

They told me that the next release of their driver disk would have
them on it.  In the meantime, they're in the usual places (ask me) as
at1500.zip and at1700.zip.

-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

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

From: kevins@aragorn.ori.org (Kevin Smolkowski)
Subject: Re: ** IDE Multiple Mode Patch ** ident drive failure **
Date: 09 Sep 1993 05:13:27 GMT


Running 99.12 kernel on a 386-40 w/ 8megs.  Two Conner IDE 
drives.  One a 170 meg and other 109 meg.  System runs great
been running linux since 99.6 without a problem.

Patch applies and compiles clean, at boot, I get the message:

hda: identify drive failed, ere_reg = 04
hda: identify drive failed, ere_reg = 04

Since inb_p is returning a error code multiple sector mode is
not enabled.  :(

What does this error code mean?  Anything I can/should do about it?

-Kevins





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

From: oreillym@tartarus.uwa.edu.au (Michael O'Reilly)
Subject: Re: ** IDE Multiple Mode Patch **
Date: 9 Sep 1993 05:31:59 GMT

Mark Lord (mlord@bnr.ca) wrote:

: Hmm.. does Linux give you a "multiple mode enabled" message right underneath
: this info when booting?  I ask because the patch is currently hardcoded to
: use 16-sector multiple mode, and the above info indicates that your drive
: does not support more than 8-sector multiple mode.  You are probably not
: obtaining the max. benefits as is, as I suspect that multiple mode is not
: actually being enabled!  The write performance is likely being improved 
: regardless due to a slight cleanup of the write code in hd.c..

: If multiple mode is not being enabled (no message), then change the 
:       #define MULT_COUNT     16
: line to read
:       #define MULT_COUNT     8
: and rebuild the kernel for another try.

Well, I did this on my drive, and read performance didn't change at
all...

time dd if=/dev/hda of=/dev/null bs=16384 count=1024
run 5 times (on an 8 meg machine), and takeing average of last 4 times
gave  17.73 seconds.

With multi-mode enabled (yes, it did show up at bootup), the average
dropped to 17.55 seconds... 

At the same time, %cpu time went from 25% w/o multi-mode, to 78%
with... 

Sorry, didn't check write speed.  Planning to do that in about 8 hrs
when andrew finishes uploading
        
Mind you, the patches did improve thruput from 770K/s to 950K/s before
the patches went in. That other stuff made a different, but the
multi-sector mode doesn't seem to.


Michael.

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

From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Date: 9 Sep 1993 10:29:11 +0300

quinlan@spectrum.cs.bucknell.edu writes:
> Fourth, a single person wrote most of it, seemingly to help people to
> work with SLS (and exclude other better releases).

While I otherwise agree with most of quinlan's article, I'll point out
that my SAG is not intended to be specific to any single release.  At
the moment it contains several references to SLS, and mentions things
that are specific to SLS, but that is strictly because I haven't been
able to afford the time and disk space to play with all the different
releases, and until recently, had only installed SLS (after having run
a system cultivated from the boot+root disks).

Even if I could do that, I probably wouldn't, because I don't want it
to be something that documents some existing distributions, but a book
that explains how things work so that people can understand how any
Unix system works (not necessarily even a Linux system, except where
necessary, e.g., the /proc filesystem or bootup messages).  That gives
two advantages: I don't have to update the book every time a new
distribution (or significantly modified distribution) comes out, and
it will hopefully result in that people _understand_ things, or _grok_
things if you understand that word.  Teaching, not documenting, is
what I'm trying to do.

[ From the crowd: Enough ranting, stupid, more book-writing! ]

OK, OK.  Bye.

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.

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

From: c9108932@peach.newcastle.edu.au (Simon J Ferrett)
Subject: Re: ** IDE Multiple Mode Patch **
Date: Thu, 9 Sep 1993 07:24:04 GMT

mlord@bnr.ca (Mark Lord) writes:

>In article <1993Sep7.030025.25084@bmerh85.bnr.ca> mlord@bnr.ca writes:
>>This patch (unofficial) can be applied to enable "multiple sector mode"
>>operation in systems with IDE drives.  Virtually all recent IDE drives include

yeah the identifcation biso tells me some stuff about my drive including:
Model = Maxstor7120AT, firmware=305730
bfftyope= dualportcache,  b-size=64k, max_mult_sec=16
dblwordIO= yes,

however when it goes to enable multisector
hda: enabled 16 sector ...

I then start to get some errors
HD read_intr: status 0x50
HD-controlooer reset
...
Hard Disk IO error
panic: unable to mount root

-> so does the code cope with a drive that cant do multisector
and disable it? (although the info status tends to indicate that i
the drive is capable of it)
or is there something bodgey about my controller card?

occasionally when I do a df I get a 'HD read_intr: status 0x50 error 0x32'
(0x32 is from memory, might be wrong)

help/comments/comiserations appreciated....

-- 
c9108932@cs.newcastle.edu.au - Simon Ferrett
Due to technical difficuties, we are unable to bring you your
regularly scheduled .signature - normal transmission will resume
as soon as possible...

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


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