Subject: Linux-Development Digest #82
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:     Fri, 10 Sep 93 09:13:15 EDT

Linux-Development Digest #82, Volume #1          Fri, 10 Sep 93 09:13:15 EDT

Contents:
  Re: how to debug kernel: malloc pb? in ultrastor scsi driver?? (Flemming Sylvest Johansen)
  Re: [Q] Where is threads library ??? (Kai-Uwe Sattler)
  Re: ** IDE Multiple Mode Patch ** (Rob Malouf)
  QIC Vol.1  Special Edition #5 (Jesus Monroy Jr)
  Re: Status of the NET-2 port (Robert Smart)
  Re: Status of the NET-2 port (Karl Holmstrom)
  Re: Status of the NET-2 port (Alan Cox)
  Re: A FINAL ANSWER TO THE ext2fs DEBATE (WAS: Re: efs2 isn't stable...) (Andreas Klemm)
  Re: Idea, donate a Pentium machine to Linus, anyone? (Stephen R. van den Berg)

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

From: fsj@csd.cri.dk (Flemming Sylvest Johansen)
Subject: Re: how to debug kernel: malloc pb? in ultrastor scsi driver??
Date: Thu, 9 Sep 1993 10:25:22 GMT

Basile STARYNKEVITCH (basile@soleil.serma.cea.fr) wrote:
> Hello,
> 
> I'm linuxing at home on my home 486DX66 PC (but emailing & posting from
> work).  I have a 240Mb IDE drive, 16=4*4Mb*70ns RAM, ET4000 VLB
> videocard, ultrastor34f scsi2 VLB controller with a 240Mb scsi2 disk
> and a Qic150 scsi2 archive viper tape streamer.  My developpment kernel
> and system (99pl12, slackware 1.01) runs only on IDE (and is compiled
> without scsi support).
> 
> I need to debug the UltraStor scsi driver, because it does not work on
> my machine (with an UltraStor34F VLB scsi2 controller).
> 
> Under Linux99pl12 the standard kernel/blk_drv/scsi/ultrastor.c driver
> doesn't really work. Any big accesses (eg a 80MB mke2fs /dev/sda5)
> panic the system. Small accesses (eg fdisk reading or writing
> partition) are ok.  The scheduler in kernel/sched.c have trouble: in
> the schedule routine, the task scanning loops  got their p (current
> scanned task pointer temporary) nil, and makes the kernel panic
> (without syncing).

I run Linux 0.99.pl12 (SLS1.03) on a 486DX2/66, 16Mb RAM, Ultrastor 34F
VLB SCSI, V7 Mirage VGA (also VLB) and a Maxtor 340M SCSI disk. The disk
is partitioned into two 110 MB ext2 filesystems, with the rest shared
between DOS, swap, etc. For backups, i borrow an external IBM tapedrive
at work. This system has been running without a hitch for over a month
now. So it is not obvious to me that your problem is confined to the
Ultrastor driver. I have certainly been able to create those two 110 MB
ext2 filesystems and run them for several weeks without kernel panics
or any other problems. Perhaps there is some undesired interaction between
the SCSI and IDE drivers ?

--
  ----------------------------------------------------------------------
        Flemming S. Johansen
        fsj@csd.cri.dk          or      ...!uunet!dkuug!cri!fsj

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

From: sattler@news.cs.TU-Magdeburg.DE (Kai-Uwe Sattler)
Subject: Re: [Q] Where is threads library ???
Date: 10 Sep 1993 10:11:11 +0200

sohail@trixie (Sohail M. Parekh) writes:

>I know someone was working on a threads lib for linux sometime back. Does 
>anybody know if its complete yet ? Is their any other support available for
>threads (and/or POSIX threads 1003.4a).

I know there is a library called lwp-0.1.tar.gz on sunsite.unc.edu in
/pub/Linux/libs. This is a portable lightweight process library (the
Rex threads library for sun, 386bsd and Linux (Author: Stephen Crane).
The threads are non-preemptive.

Is there a port of pthreads (from the Florida State University) for Linux ?

Cheers, Kai

-- 
Kai-Uwe Sattler                | "And though the reason now is gone -
kus@sunpool.cs.tu-magdeburg.de |  the battle rages on"  -  Deep Purple

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

From: malouf@leland.Stanford.EDU (Rob Malouf)
Subject: Re: ** IDE Multiple Mode Patch **
Date: Wed, 8 Sep 93 17:24:05 GMT

In article <1993Sep7.155843.3260@bmerh85.bnr.ca> mlord@bnr.ca (Mark Lord) writes:
>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.

I have always had trouble with heavy disk access causing a "HD Reset"
and hanging the system.  Since this happens only once a month or so,
it doesn't concern me too much.  However, the IDE multiple mode patch
made the problem much worse.  With the patch, iozone consistently
causes a HD Reset (and corrupts the file system).  Do you know what
might be causing this?  Is it just the result of a cheapo too-slow HD
controller?  At any rate, I don't think the patch should be included
by default in the regular Linux kernel.

Rob Malouf
malouf@csli.stanford.edu

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

Crossposted-To: comp.os.os2.programmer.misc,comp.os.minix,comp.periphs,comp.unix.bsd,comp.unix.pc-clone.32bit,comp.os.386bsd.development,comp.sys.ibm.pc.hardware,comp.sys.ibm.ps2.hardware
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: QIC Vol.1  Special Edition #5
Date: Fri, 10 Sep 1993 10:19:43 GMT

Released
        +----------------------------------------+
          QQQQQQ   II   CCCCCC
          QQ  QQ   II   CC        N  E  W  S   and   N  O  T  E  S
          QQ  QQ   II   CC        for 386bsd-Linux-Mach-OS/2
          QQ  QQ   II   CC        (and sometimes minix & coherent)
          QQQQQQ   II   CCCCCC    Vol.1  Special Edition #5
             QQ               (r)
          Quarter  Inch Cartridge (Tape Drives)
        +----------------------------------------+
                News about QIC-40/80
 
   From the desk of the quasi-editor-in-chief:
        "Just because I am numbering these things don't get the idea
         that I am going to do any more of these".
         (Disclaimers move to bottom.. getting to big.) (crowd:YEAH!!)
 
        *=======================================*
        |       Tabloid Contents                |
        *=======================================*
        |  <1>__ The Meeting itself             |
        |  <2>__ The Responses to Requests      |
        |  <M>__ Meaningless dribble.           |
        |  <N>__ NEXT ISSUE                     |
        *=======================================*
        hint: search for "<?>__"
 
 
 
  <1>__ The Meeting itself
 
                For those with that indescribable quench to get more
        information on QIC, here it is.  The meeting notes will be
        mailed on Tuesday, till then here are some of my notes.
        On Wensday, 09-01-1993, the Technical Committee for the QIC
        meet.  There was some discussion on various uninteresting
        items before the various subcommittees reported.  Here is a
        breakdown of the reports by committee.  Also, I had to leave
        early and missed the last half of the "Minicartridge" meeting
        and the entire "Cartridge" meeting.
 
        ID (Industry Development) committee
        -----------------------------------
                A Buyers' Guide will be available later this year.
        In addition, a Market Perspective - Why buy QIC - will also be
        available.  A set of European conference is also planned for
        the end of January and early February.  Lastly, the QIC group
        is still waiting for ANSI approval of a SCSI II implementation.
 
                At this time a rumor ensued that possibly the
        SCSI-II standards would not be published.  The speculation
        followed that this was possible because of SCSI-III is in
        progress.   A member of the SCSI-II committee was present and
        quickly quashed the rumor by stating that the editor and some
        members were in a disagreement as to the semantics of SCSI-II
        and that ANSI documentation would be available, in time.
 
                Central Point Software suggested some possible new
        additions to the QIC "standard" procedures.  Namely, that each
        QIC device should have REV (revision) query support built-in to
        the firmware, so that software designers can take full advantage
        of any new features available.  The idea was sent to committee
        and is scheduled for full discussion later this year.
 
                At the same time a suggestion was made that a
        "Revision History Page" now be made part of all QIC printed
        standards.  The action was voted on immediately and history
        pages will now be a part of all QIC standards published in the
        future.  A retroactive history scan was requested so that
        previous QIC documents could have a history page.  The item
        was shelved for full discussion later this year.
 
        Widetape subcommittee
        ---------------------
                The Technical committee approved the lock out feature as
        proposed.  The question as to 3M's patent on the lock out
        feature was resolved.
 
 
        Interface and format subcommittee
        ---------------------------------
                Some SCSI drives will have appendable point for file
        marks as an option.  A previous proposals had it as required
        for all new drives.  It was marked as optional to preserve
        the usefulness of units already in field service.
 
 
        Minicartridge subcommittee
        --------------------------
                The proposal was passed to add hardware recognition of
        a cleaning tape via a physical cutout.
 
                IOMeg had concerns with SCSI interface for the proposed
        93-55C.  Once completed the drive will be a 750 Mega-byte
        unit.  Their concerns were:
 
             1. The drive may not technically feasible.
             2. Without the upward compatible 2 Gigabyte drive specs
                this drive would be difficult to sell.
             3. The overlap on read/write track seems to be excessive;
                the standard calls for servo tracks to be used.
             4. Writing to the physical edge of the tape may make data
                unreadable in the future, if it is written at all.
 
 
        The proposed 400' minicartridge was left as an open item.
 
 
 
                I don't have any copies of these proposed changes.
        So, the alternatives are - wait till the changes are done and
        approved _or_ write the QIC Facilitator and ask for a copy
        of the proposals. (See QIC News and Notes vol.1 no.1 for
        the Facilitator's address and phone number.)
 
        --------------------------oOo----------------------------
 
  <2>__ The Responses to Requests
 
        1)  Ask for a field in the QIC-80 to indicate an
            experimental file system on the tape.
 
        Response:
                More than one member of the QIC group suggest that for
                experimental file systems the VENDOR UNIQUE BIT
                be used in the Volume Information Segment. Please
                refer to the QIC document that applies to you.  For
                QIC-40/80 tapes it is the QIC-40/80 documents.
                (More on how to apply this in regular issues of
                QIC NEWS and Notes.)
 
        2)  Ask that all QIC specifications and standards be
            keep in electronic format.
 
        Response:
                The request was met with enthusiasm by the
                facilitator and the people at Wangtek and Archive.
                A promise was made to look into the feasibility of
                the situation.  They asked me to call them on this
                later this month.
 
        3)  Ask that the Facilitator keep the standards information
            on an accessible resource (BBS, FTP, UUCP, e-mail, etc.).
 
        Response:
                As mentioned they will look in to the matter, but of
                course for us FTP would be the most acceptable
                solution.  etext.archive.umich.edu will get the first
                opportunity to be the FTP site,  but in the
                eventuality that they do not have the facility for
                this other sites will be solicited.
 
 
  <M>__ Meaningless dribble.
 
 
        "My idea of the perfect date is: I want to take them out.
         Take them home. I want to cum on their back.
         Steal $30,$40 dollars out of their purse.
         Crawl out a window and never call them again."
 
                                -Sam Kinison
                                -Have you seen me lately?
 
 
 
        A 10 to the 11th power bit memory Resource was available in 1960
        at LLNL (Lawerance Livermore National Laboratory).
 
 
        GOB - Generous Omnipotent Benefactor - The operating system in
              use at LLNL in 1963.  In russia, please spell backwards.
 
___________________________________________________________________
 
  <N>__ NEXT ISSUE
 
        o....   "Documentation. Us and Them."
        o....   QIC devices on the port/IRQ level.
        o....   "Update on the tape drives that work!"
 
        ====================================================
 
        "QIC" is a registered trademark of the
        Quarter-Inch Cartridge Drive Standards, Inc. (QIC).
 
        This publication is not affiliated with "QIC" or "QIC DATA NEWS".
 
        All comments, issues, and errors are only attributable
        to the quasi-editor-in-chief.
 
        Back issues of QIC NEWS and NOTES are available via "anonymous"
        FTP at etext.archive.umich.edu in  /pub/Zines/QIC-News.
 
        IF you have specific questions, don't be afraid to send them
        to:
                jmonroy@netcom.com
                subject: [QIC NEWS and NOTES: question]
 
___________________________________________________________________________
Jesus Monroy Jr                                          jmonroy@netcom.com
/386BSD/device-drivers /fd /qic /clock /documentation
___________________________________________________________________________
:

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

From: smart@squid.mel.dit.CSIRO.AU (Robert Smart)
Subject: Re: Status of the NET-2 port
Date: Fri, 10 Sep 93 06:07:28 GMT

I wrote:

>The USL lawsuit is very dead - they're only arguing about how much
>compensation UC should get for being maligned. 

Others have pointed out that I am not in a position to know. It is
true that I am only combining the judges reported comments with
some common sense. Surely nobody out there thinks that someone in
Australia is in a position to make an authoritative statement on
this matter. I retract my assertion in case anybody out there
finds it confusing.

(The antipodean) Bob Smart

Disclaimer: these views and the views in the previous posting are
mine and not those of my employer.

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

From: kalle@kyyppi.kyyppi.kcl.fi (Karl Holmstrom)
Subject: Re: Status of the NET-2 port
Date: 10 Sep 1993 10:53:27 GMT

In article <1993Sep10.002132.13102@mel.dit.csiro.au> smart@squid.mel.dit.CSIRO.AU (Robert Smart) writes:

   Lots of stuff removed about the blessings of BSD networking...

>    4. Low level support for lots of networking devices: ethernet, token
>       ring, FDDI, ISDN, ATM/BISDN, etc...

And you would lose the work done by Donald Becker et al, which gives us
autoconfiguring drivers for the ten most popular PC ethernet cards.
It is amazing to see how the newest Linux distributions install
without any hardware configuration.  It would be interesting to
see which is more important for the average Linux user: good support
for the cheap and omnipresent hardware or token ring, FDDI, ISDN,
and ATM/BISON.  Some of these might well become "standard" one day,
but no doubt there will be drivers available when this takes place.

>   I fear that this has a nasty potential to fragment the Linux software
>   development. What worries me even more is that I could be forced to
>   leave Linux to run one of the BSD derivatives for practical reasons.

Why should BSD and Linux be clones of each other?  BSD is oriented
towards doing things the Right Way(tm) whereas Linux developers seem
to be more interested in making things work.  It probably results
in code that is not always so beautiful or portable, but Linux 
seems to have found its niche.  On the other hand, if you really 
need some of the advanced features of BSD, why don't you simply 
switch to BSD?

  regards, kalle
--
==============================

Karl Holmstr|m
Finnish Pulp and Paper Research Institute
P.O. Box 70, SF-02151 ESPOO, Finland
Tel +358 0 4371306
email: kalle@sihti.kcl.fi

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

From: iiitac@swan.pyr (Alan Cox)
Subject: Re: Status of the NET-2 port
Date: Fri, 10 Sep 1993 11:39:38 GMT

In article <26p9pl$1rp@pdq.coe.montana.edu> nate@bsd.coe.montana.edu (Nate Williams) writes:
>In article <1993Sep10.033246.28836@super.org>,
>Donald J. Becker <becker@super.org> wrote:
>
>Hmm, that may be the case, but I'll bet you dollars to donuts that it'll
>be awhile before the Linux networking code (not BSD Net/2 code) can
>saturate an ethernet.  Not bad for *slow* code, is it?

On our hardware the Linux net code is faster than the BSD net code. The
device drivers are an order of magnitude better but the upper layers need
work. I'm actually planning on taking a hatchet to the Linux net code
and trying to produce a solid stable release with better list handlers.

Alan
iiitac@pyr.swan.ac.uk


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

From: andreas@knobel.knirsch.de (Andreas Klemm)
Subject: Re: A FINAL ANSWER TO THE ext2fs DEBATE (WAS: Re: efs2 isn't stable...)
Date: Thu, 9 Sep 1993 16:00:58 GMT

sdh@fishmonger.nouucp (Scott D. Heavner) writes:

>RAVET, STEVEN (s0r1282@zeus.tamu.edu) wrote:
>> someone post fairly direct instructions for fscking (how is that pronounced)
>> on bootup before mounting, if that is the proper thing to do.  what should

>       This is mostly derived from one of H.J.'s boot disks.  It requires
>that the shutdown package you use creates the file /etc/fastboot (which
>it probably does, you will have to learn to use shutdown -f and reboot -f, or
>get used to waiting on bootup).  The following lines should be in your
>/etc/rc before you do any file operations (like mounting or writing).

>------------------
># If we we shut down with "shutdown -f" don't check file systems.
>if [ -f /etc/fastboot ]
>then
>        rm -f /etc/fastboot
>else
>        /etc/afsck
>fi
>------------------

>On my system afsck is just a shell which checks all the file
>systems.  You could just include all the fsck commands in 
>/etc/rc, but I like to be able to run afsck by hand if I think
>something is messed up.

>-------------------
>#!/bin/sh
>echo "Checking all file systems..."
>echo /dev/hda3: /
>fsck -a /dev/hda3
>echo /dev/hda2: /usr
>fsck -a /dev/hda2
>echo /dev/hda6: /share
>xfsck -a /dev/hda6
>echo /dev/hda5: /tmp
>fsck -a /dev/hda5
>echo /dev/hdb2: /var/local/src
>fsck -a /dev/hdb2
>echo /dev/hdb5: /home
>fsck -a /dev/hdb5
>--------------------

So you have each time to check the filesystems,
even if it's unnecessary ... and that is hopefully the default...

To avoid unnecessary checking -> get bootutils ...

Another good message ... Slackware distrib. now contains bootutils.

        Andreas ///
-- 
/-\       Andreas Klemm   <andreas@knobel.knirsch.de>      +-----------------+
|@|########################################################-@ "pay for it !" |
\-/   41469 Neuss     Germany     phone +49/ 2137 12609    +-----------------+

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

From: berg@pool.informatik.rwth-aachen.de (Stephen R. van den Berg)
Subject: Re: Idea, donate a Pentium machine to Linus, anyone?
Date: 10 Sep 1993 12:38:08 GMT

In article <1993Sep10.003825.28075@kf8nh.wariat.org>,
Brandon S. Allbery <bsa@kf8nh.wariat.org> wrote:
>In <26n39a$odv@noc.usfca.edu> callis@noc.usfca.edu (Kim C. Callis) writes:

>>I do realize that this is wistful thinking. Why would anyone in their
>>right mind want to donate a dollar for something that is available all
>>over the Internet for free?

>It worked for Cygnus (gcc Solaris 2 port), didn't it?

Yes, they did a splendid job.  Asking everyone to pay money for a port
that was already done (and not by Cygnus, no).  Evidently many payed.
Sad.  Sigh.
-- 
Sincerely,                                  berg@pool.informatik.rwth-aachen.de
           Stephen R. van den Berg (AKA BuGless).    berg@physik.tu-muenchen.de
You are currently aboard a fully automated plane.  There is no pilot on board.
Rest assured, you have nothing to worry about... worry about... worry about...

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


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