Subject: Linux-Development Digest #401
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:     Sat, 22 Jan 94 18:14:12 EST

Linux-Development Digest #401, Volume #1         Sat, 22 Jan 94 18:14:12 EST

Contents:
  Re: Missing sgtty.h in MGR v0.56 compile? (Eric Merth)
  Broadcast Bug? (Derek Hackbardt)
  Re: kmalloc for more then 4096 Bytes ? (Uppie)
  Asynchronous I/O (Matthew Donadio)
  Re: scsi 8mm tape (exabyte 8200) (Keith Smith)
  Re: Is there an _official_ directory structure for linux? (Bill Hogan)
  is there a scsi device detect routine ? (Michael Hemy)
  Re: Broadcast Bug? (Dominik Kubla)
  /dev/midi vs. /dev/sequencer (Kreijkamp J)
  Re: Better than Xmag ? (Dan Miner)
  Re: kmalloc for more then 4096 Bytes ? (Eric Youngdale)
  Re: Block size setting for SCSI-Tape not working? (Kai Makisara)
  Re: Van Jacobson slow start (Re: Linux v1.0: what's in it?) (Otmar Lendl)
  Re: Linux v1.0: what's in it? (Daniel Quinlan)
  Re: Broadcast Bug? (Klaus Steinberger)
  Problem with libc 4.5.8 and nfs (locking problem) (Klaus Steinberger)
  Re: Linux v1.0: what's in it? (Christopher Shaulis)

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

From: emerth@gpu.srv.ualberta.ca (Eric Merth)
Subject: Re: Missing sgtty.h in MGR v0.56 compile?
Date: Fri, 21 Jan 1994 21:23:56 GMT

emerth@gpu.srv.ualberta.ca (Eric Merth) writes:

>I'm  trying to get MGR v0.56 going with Slackware's
>Linux distribution. I believe that I've got gcc 2.5.8 
>& the 4.4.4 libraries. My kernel is 0.99.14.

        { ... }

        Thankyou to all the good people who sent 
        me mail explaining the error(s) of my ways. 
        (I got MGR working).

        -EWM

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

From: hackbard@egr.msu.edu (Derek Hackbardt)
Crossposted-To: comp.os.linux.help
Subject: Broadcast Bug?
Date: 21 Jan 1994 21:34:46 GMT

I am not sure if this is a kernel bug or not..

It seems that when my default route is set to our gateway, broadcast 
packets carry the wrong netmask.  This problem occurs when using yp
under Slackware 1.1.1 and 0.99.14s kernel.  Although when I set the
default route to the nisserver everything appears to work properly..

The netmask should be: 255.255.255.0
Broadcast: 150.220.40.255

The outgoing broadcast packets go to 150.220.255.255.

Any ideas?  I can provide more details to who ever would like..

Thanks..

-derek A. hackbardt
hackbard@mced.kodak.com



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

From: juphoff@tarsier.cv.nrao.edu (Uppie)
Subject: Re: kmalloc for more then 4096 Bytes ?
Date: Sat, 22 Jan 1994 11:36:37 GMT

Dr. Franz Mach Elektroenergieversorgung 463 5336 (mach@urz.tu-dresden.de) wrote:
: I have have running Slackware 1.1.1 with pl14-kernel. I have a problem with NFS 
: to a HP-UX 8.7 system. This causes to allocate 4408 Bytes and kmalloc crashes.

: My Version of "kmalloc.c" is written by R.E. Wolff in Sept/Oct. '93.

: Is there anywhere a Version of "kmalloc.c" with can allocate more then one page
: (4096 Bytes).

I don't know...I tried modifying the kernel to change the page
size, and rapidly found it was a _bad_ idea.  (at least for me)  :)

I've worked around my NFS problems by only mounting my linux machine's
drives on other machines with mount options of "rsize=1024,wsize=1024".
Works beautifully from Suns, even via the automounter.  AIX machines seem to
have troubles though...don't seem to honor the size options for some
reason.

--
Jeff Uphoff -- "Uppie"  |  "The secret to good teaching is sincerity. 
                        |  As soon as you learn to fake that, you've got
juphoff@nrao.edu        |  it made."

Check out my WWW/Mosaic home page at:  http://tarsier.cv.nrao.edu/juphoff/home

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

From: donadio@mxd120.rh.psu.edu (Matthew Donadio)
Subject: Asynchronous I/O
Date: 21 Jan 1994 23:16:31 GMT

Are there any plans to add asynchronous I/O to the kernel any time in
the near future?

--
Beaker aka Matt Donadio   | Life is short,     ---   __ o    __~o    __ o
donadio@mxd120.rh.psu.edu |    ride like    ----    _`\<,   _`\<,   _`\<,
--- Penn State Cycling ---|      the wind.    ---  ( )/( ) ( )/( ) ( )/( )

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

From: keith@ksmith.com (Keith Smith)
Subject: Re: scsi 8mm tape (exabyte 8200)
Date: Thu, 20 Jan 94 18:20:06 GMT

In article <1994Jan15.151906.4004@news.csuohio.edu>,
tim werner <thx1139@knuth.cba.csuohio.edu> wrote:
>
>Hi,
>
>Is anyone working on a driver for this?
>
>Also, does anyone have any experience with it in general? I just
>bought one for my 486, and I bought the Corel SCSI driver package,
>and I am having some problems. The driver can format the tape, but
>gets a seek error once the backup program starts. I haven't been
>in touch with the vendors yet. That's next.

Your problem may be the drive itself.  Some of the early 8200's had
flakey firmware and soft heads.  I have 2 8200's here on an SCO box, and
occasionally "borrow" one and take it home.  It works fine under linux.

Note that Helical Scan tapes behave quite differently to certian SCSI
commands like "unload".  In QIC, unload means take the head off of the
tape, in HS it means pop the tape out of the drive! since HS drives
_have_ to load the tape around the head when you stick it in.

>I was hoping to use the tape drive under Linux, and figured a good
>first step would be to verify that it works under windows. So far
>no luck.

Actually, I'd try it under linux with TAR.  Linux/Unix does not "format"
tapes, you just write on them.

>Is it true that SCSI tape is SCSI tape, no matter whether 4mm or 8mm?


Weeeeeellllll, Yea, sorta.  As long as the driver doesn't get too fancy
you should be alright.

-- 
Keith Smith          keith@ksmith.com              5719 Archer Rd.
Digital Designs      BBS 1-919-423-4216            Hope Mills, NC 28348-2201
Somewhere in the Styx of North Carolina ...

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

From: bhogan@crl.com (Bill Hogan)
Subject: Re: Is there an _official_ directory structure for linux?
Date: 22 Jan 1994 05:40:51 -0800

Jeffrey Wescott (wescott@spectrum.cs.bucknell.edu) wrote:

: First of all, this message should NOT have been posted in
: comp.os.linux.development.  c.o.l.d is intended to be used for kernel
: deveopment discussion.  Your question does not have anything to do
: with the kernel. ...

  If this is really and truly such a big deal that it has to be said
first, before even so much as saying "G'day", instead of being put at the
end, where it belongs, as in "BTW", then why isn't this newsgroup _called_
"comp.os.linux.kernel"? 

  BH
-- 
  Bill Hogan
{bhogan@crl.com}

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

From: mhemy+@cs.cmu.edu (Michael Hemy)
Subject: is there a scsi device detect routine ?
Date: Sat, 22 Jan 1994 07:31:39 GMT

Is there a separate routine or a program that will list the SCSI devices
information (like what is shown during boot?). 
Is this information available only through driver code specific to the
SCSI adapter installed ? In other words, is it possible to write a
small self-contained program that will list the information recorded
on the devices without going through the driver?

Thanks,
--Michael




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

From: kubla@goofy.zdv.Uni-Mainz.DE (Dominik Kubla)
Crossposted-To: comp.os.linux.help
Subject: Re: Broadcast Bug?
Date: 22 Jan 1994 07:55:06 GMT

In article <2hphpm$uk2@msuinfo.cl.msu.edu>, hackbard@egr.msu.edu (Derek Hackbardt) writes:
"> "I am not sure if this is a kernel bug or not..
"> "
"> "It seems that when my default route is set to our gateway, broadcast 
"> "packets carry the wrong netmask.  This problem occurs when using yp
"> "under Slackware 1.1.1 and 0.99.14s kernel.  Although when I set the
"> "default route to the nisserver everything appears to work properly..
"> "
"> "The netmask should be: 255.255.255.0
"> "Broadcast: 150.220.40.255
"> "
"> "The outgoing broadcast packets go to 150.220.255.255.
"> "
"> "Any ideas?  I can provide more details to who ever would like..
"> "
"> "Thanks..
"> "
"> "-derek A. hackbardt
"> "hackbard@mced.kodak.com
"> "
"> "

Yes, its a bug, but in libc/yp. As i examined the code i got the impression,
that there is an implication of 8bit subnet masks :(
There was a new version of the yp-linux package announce with fixes in the
libc part but you will need to recompile libc. I haven't checked this out.
Anyway the fixes should be in the next libc release.
 
-- 
Cheers,
  Dominik

+---------------------------------------------------------------------------+
| eMail: kubla@goofy.zdv.Uni-Mainz.DE                                       |
| sMail: Dominik Kubla, Steinsberg 34, 56355 Nast"atten, F. R. Germany      |
+---------------------------------------------------------------------------+
|                                                                           |
|        "Linux: The choice of a GNU generation"      --S. Frampton         |
|                                                                           |
+---------------------------------------------------------------------------+
DISCLAIMER:  Everything written above are the expressed thoughts of the
author and in no way connected to 'Johannes Gutenberg Universit"at', Mainz
(Germany). This way, they do not have to care about what I say ...

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

From: jaap@cs.vu.nl (Kreijkamp J)
Subject: /dev/midi vs. /dev/sequencer
Date: Sat, 22 Jan 1994 15:31:31 GMT

Am I the only one who would expect the midi in/out in /dev/midi opposed
to /dev/sequencer? Why IS it placed in dev/sequencer? AND is there some
sort of manual of all events and ioctl's for the sound-driver stuff?

Greetings,
        Jaap

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

Crossposted-To: comp.os.linux.help
From: dminer@nyx10.cs.du.edu (Dan Miner)
Subject: Re: Better than Xmag ?
Date: Sat, 22 Jan 94 08:09:50 GMT

In article <1994Jan21.150906.24321@waikato.ac.nz>,
 <phys2108@waikato.ac.nz> wrote:

[...]

>> -- 
>>   /--------------------------------------------------------------------------\
>>   | Mark A. Davis    | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
>>   | Sys.Administrator|  Computer Services   | mark@taylor.wyvern.com   .uucp |
>>   \--------------------------------------------------------------------------/
>How about getting a lcd projection unit and putting the output on a wall.

What bottomless bank account do you have?!  *grin*

Dan
--
Dan Miner                                       dminer@nyx.cs.du.edu

Future student                                  Linux: try it, you'll like.
"Your program is encoded in pi."                I started with a 64

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

From: eric@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: kmalloc for more then 4096 Bytes ?
Date: Sat, 22 Jan 1994 15:55:41 GMT

In article <CK1491.BtL@news.cv.nrao.edu> juphoff@tarsier.cv.nrao.edu (Uppie) writes:
>Dr. Franz Mach Elektroenergieversorgung 463 5336 (mach@urz.tu-dresden.de) wrote:
>: I have have running Slackware 1.1.1 with pl14-kernel. I have a problem with NFS 
>: to a HP-UX 8.7 system. This causes to allocate 4408 Bytes and kmalloc crashes.
>
>: My Version of "kmalloc.c" is written by R.E. Wolff in Sept/Oct. '93.
>
>: Is there anywhere a Version of "kmalloc.c" with can allocate more then one page
>: (4096 Bytes).
>
>I don't know...I tried modifying the kernel to change the page
>size, and rapidly found it was a _bad_ idea.  (at least for me)  :)

        Newer kernels have vmalloc which allows you to allocate memory in more
or less any size you want.  kmalloc is still available, and it is preferable
for blocks that are < PAGE_SIZE since it makes better use of the memory, and I
think it is faster.

        If you need to free a pointer and you are not sure whether it was
allocated with vmalloc or kmalloc, you can do the following:

        if(addr > high_memory)
          vfree(addr);
        else
          kfree(addr);

-Eric
-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

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

From: makisara@vtinsx.ins.vtt.fi (Kai Makisara)
Subject: Re: Block size setting for SCSI-Tape not working?
Date: 22 Jan 1994 08:27:33 GMT

In article <1994Jan21.125301.15095@wavehh.hanse.de> cracauer@wavehh.hanse.de (Martin Cracauer) writes:

   I want to read tapes written with of blocksize of 1024 byte.

   Linux' default is 512 byte, so this does not work. The error message
   is "I/O error" to the terminal running the application and "st0:
   Incorrect block size" to the console.

...
   -- 
   %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   Martin Cracauer <cracauer@wavehh.hanse.de>,Voice+4940-5221829,Fax.-5228536

         Source is the greatest good in computing

The linux SCSI tape driver can operate with tape block sizes up to
the size of the internal buffer. The driver does not change the block
size of the driver unless explicitly told to do that with the MTSETBLK
ioctl. When the tape device is opened the driver asks the block size
from the drive and uses it. An attempt to use the block size of
512 bytes is used only if the drive does not respond to the mode sense
telling the block size. (The ST_BLOCKSIZE in st.c is only used as a
component in sizing the internal buffer and does not affect the
block size being used.)

dd and most other programs allowing the user to determine the block
size only use it to determine the size of the read and write calls.
If the tape drive is in variable block mode this determines also the
size of the tape blocks. In fixed block mode the block size is not
visible to the program and the ioctl MTSETBLK must be used to set
the physical block size. The mt program can be used to give the
ioctl's.

        Kai
--
DISCLAIMER: The views expressed here are mine and may not always
coincide with the views of my employer.

*  Kai Makisara                *  email Kai.Makisara@vtt.fi    *

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

From: lendl@cosy.sbg.ac.at (Otmar Lendl)
Subject: Re: Van Jacobson slow start (Re: Linux v1.0: what's in it?)
Date: Sat, 22 Jan 1994 15:24:50 GMT

Harald T. Alvestrand <hta@uninett.no> wrote:
>hedrick@geneva.rutgers.edu (Charles Hedrick) writes:
>
>>Retransmission is now using a fairly simply slow start strategy.
>>Jacobson has come up with more clever things, which the Hosts
>>Requirements RFC says should be implemented.  However at the moment we
>>don't need cleverness -- we need reliability.
>
[...] 
>
>That's why it is a *MUST*, not a *SHOULD* - and I think it should
>be fairly high up on the list of things that Linux networking should adhere to.
>
I must second this. Although SlowStart can be very annoying in 
long rtt environments (as I painfully found out using a satellite 
to link lans...), it is vitally important for congested networks.

>Unfortunately, the only reference seems to be:
>
>[TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88,
>     August 1988.
>
>I don't know if this is online.

Try:  ftp.ee.lbl.gov:/congavoid.ps.Z

(sorry, if sombody already pointed this out, my news-server is
having a bad time coping with this weeks traffic spike.)

otmar
-- 
| Otmar Lendl (lendl@cosy.sbg.ac.at) | University of Salzburg / Austria |
| <a href="http://www.cosy.sbg.ac.at/people/lendl.html">WWW</a> MIME PGP|
|                 So what ? Death to ICMP Source Quench !               |

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

From: quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan)
Subject: Re: Linux v1.0: what's in it?
Date: 22 Jan 1994 08:49:53 GMT
Reply-To: quinlan@spectrum.cs.bucknell.edu


Patrick writes:

> BTW, everybody can have version 1.0 NOW! Just change VERSION in
> /usr/src/linux/Makefile and recompile. You will feel much better,
> then!

This shows how much real meaning the "1.0" really has.

However, it is time to admit that Linux is well-beyond beta test and
bump the version to 1.  The code freeze used to make sure that the
version 1.0 kernel is quite stable is a wise move and I'm sure it also
gives Linus a chance to catch his breath.

On a lighter note, you KNOW that ftp to ftp.funet.fi is going to be an
absolute nightmare on the day that 1.0 comes out.  Perhaps the kernel
source could be made available on the other sites sooner than usual.

Dan

--
Daniel Quinlan  <quinlan@spectrum.cs.bucknell.edu>

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

Crossposted-To: comp.os.linux.help
From: k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
Subject: Re: Broadcast Bug?
Date: Sat, 22 Jan 1994 17:57:19 GMT

hackbard@egr.msu.edu (Derek Hackbardt) writes:

>under Slackware 1.1.1 and 0.99.14s kernel.  Although when I set the
>default route to the nisserver everything appears to work properly..

>The netmask should be: 255.255.255.0
>Broadcast: 150.220.40.255

>The outgoing broadcast packets go to 150.220.255.255.

I seem to have the same problem, ypbind times out, and routed doesn't 
work. I will be very interested in a solution.

Sincerely,
Klaus


--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-85748 Garching, Germany
Internet: Klaus.Steinberger@Physik.Uni-Muenchen.DE

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

From: k2@bl.physik.tu-muenchen.de (Klaus Steinberger)
Subject: Problem with libc 4.5.8 and nfs (locking problem)
Date: Sat, 22 Jan 1994 18:00:29 GMT


Hello,

I have the following problem with libc 4.5.8:

Accounts on our Linux box have their homedirectorys located
on a NFS mounted filesystem (from a large CDC MIPS Server box).
This led to a problem with filelocking. xauth and frineds will not
work. With libc 4.4.4 and previous, this was not a problem, we
just disabled authority in xdm-config, and opend up with xhost.

But now with 4.5.8, no applications come up, and after some seconds
the X-server restarts. xdm-errors shows that it had catched a SIG 11.
I suspect this is due to a access to .Xauthority. Local accounts will work.

Any hints? Or is somebody working on a port of rpc.lockd?

Sincerely,
Klaus


--
Klaus Steinberger               Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287        Hochschulgelaende
FAX:   (+49 89)3209 4280        D-85748 Garching, Germany
Internet: Klaus.Steinberger@Physik.Uni-Muenchen.DE

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

From: cjs@netcom.com (Christopher Shaulis)
Subject: Re: Linux v1.0: what's in it?
Date: Sat, 22 Jan 1994 18:15:22 GMT

quinlan@spectrum.cs.bucknell.edu (Daniel Quinlan) writes:

>On a lighter note, you KNOW that ftp to ftp.funet.fi is going to be an
>absolute nightmare on the day that 1.0 comes out.  Perhaps the kernel
>source could be made available on the other sites sooner than usual.

I agree to that! It would make A LOT of sense to put the 1.0 (and 
probably 0.99.15) release on a few American sites as well. It would take
alot of strain off of ftp.funet.fi. I reacall that when 0.99.14 came out, 
I ended up having to get the entire kernel three times 'cuz it was about
10K longer then Netcom's idle deamon would allow me to wait and transfer.

I know that sunsite.unc.edu allow stuff to be gotton from the incoming 
directory, so it would be an ideal choice. tsx-11.mit-edu would be a 
natural choice for a second site. Topquark.cecer.army.mil never has any 
traffic, might also be a good site. Someone could put it up on Netcom for 
a week or so (I'd volunteer disk space on my account) -- Netcomm is like 
a major back-bone setup, it would take only seconds to transfer plus 
folks already there could just "sz" it from the ftp directory.
 
Christopher
  ___     _  ___   ____  _  _ ___ _____  ___  ___  __  __     ___  ___  __  __ 
 / __|_  | |/ __| / __ \| \| | __|_   _|/ __|/ _ \|  \/  |   / __|/ _ \|  \/  |
| (__| |_| |\__ \/ / _` | .` | _|  | | | (__| (_) | |\/| | _| (__| (_) | |\/| |
 \___|\___/ |___/\ \__,_|_|\_|___| |_|  \___|\___/|_|  |_|(_)\___|\___/|_|  |_|
==================\____/=======================================================


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


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