Subject: Linux-Development Digest #9
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:     Wed, 10 Aug 94 03:13:21 EDT

Linux-Development Digest #9, Volume #2           Wed, 10 Aug 94 03:13:21 EDT

Contents:
  Re: THANKS. (Wallace Roberts)
  Re: lint for linux (Thomas G. McWilliams)
  Re: Repost: *MATROX* Support ? (Henry A Worth)
  Re: Workman doesn't work with kernel 1.1.41?? (R. D. Thomas)
  Asynchronous socket I/O (SIGIO)? (Chance C. Geurin)
  Re: 1.1.36 -> 1.1.41 - Something broke ESDI support! (Mark Lord)
  Re: IFS (Inherited File System) (Matthias Urlichs)
  Re: g++ 2.6.0 kernel compiler problem (Steffen R. Mueller)
  Re: SLIP speeds 1.0 vs 1.1 (Jerry Ablan)
  Re: Does anyone use SONY CDU-535 CD-ROM anymore? (Jeffrey Comstock)
  cdu31a: Too many consecutive attentions: 11 (Vincent Fatica)
  Re: IRQs attached to what? (Matthias Urlichs)
  Re: Where should i386/string.h be?  And floppy code report. (Matthias Urlichs)
  (Some) NFS-mounted Executables Won't Run on 1.1.41 (Brian Capouch)
  Files written from Linux via NFS begin with null bytes (Oliver Schoett)

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

From: robertsw@agcs.com (Wallace Roberts)
Subject: Re: THANKS.
Date: 9 Aug 1994 09:00:53 -0700

cmay@titan.ucs.umass.edu (Christopher M. May) writes:
>Hi, I wanted to thank everyone involved, for making Linux
>what it is today.  I think Linux is the best thing to 
>ever happen to ibm compatibles since the 386.
>
>Somebody, wake me up, I must be dreaming.

i agree.  i've used many commercial unices, even intel ones; linux is at
least on par with them & in many ways puts them to shame.

maybe we can start a "linus beer fund" or something like that to pay him
back in some small way.

ok, what's his snail-mail address?  let's start sending him donations.

gears,
ye wilde ryder
--
robertsw@agcs.com | 86 cr250 "dirt devil"    83 v65 magna "animal"
"E Pluribus Unix" | 79 it250 "mr. reliable"  84 650 nighthawk ">> for sale <<"
"Criminals (especially tyrants) prefer unarmed victims."
"Ignorance can be cured; stupidity, on the other hand, is hereditary."

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

From: tgm@netcom.com (Thomas G. McWilliams)
Subject: Re: lint for linux
Date: Tue, 9 Aug 1994 21:16:46 GMT

Jonathan Magid (jem@bittyblue.oit.unc.edu) wrote:
: There is a free lint on the 'Net called "LCLint", by David Evans
: (evs@larch.lcs.mit.edu).  There are a few people working on a port 
: to linux (I was going to be one of them but work and then vacation
: caught up to me).  

This package is seriously flawed. I would not recommend this for
the faint hearted. While LCLlint is sound in concept, its
implementation with regard to memory management is horrible.
Memory is allocated willy-nilly without any way to track it or
recover it. Malloced pointers are passed and assigned in a
labyrinth of complex internal data structures. It becomes
impossible to find their true scope, let alone determine when
they might be safely freed.

I have never seen memory leaks so bad.  One memory diagnostic
tool which I use reported 200000 lost memory blocks. I even
tried running this under 'checker' but after running over 24
hours on a trivial test case, I killed it. This program is too
much for 'checker' to handle.

When LCLint does try to free memory it often crashes because it
is trying to free a block that was already freed.  Because of
these problems,  LCLint requires tens of megabytes of memory to
analyze any non-trivial program.  I've watched it eat up 50 megs
of virtual memory easily. LCLint works as a proof of concept but
it needs a complete re-write with an eye on memory management.
There is no easy fix; believe you me, I have spent many, many
long hours looking for one!. I hope that the author finds the
time to re-work this into a release 2.0 because it has a lot of
potential otherwise.

Thomas
tgm@netcom.com

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

From: haw30@eng.amdahl.com (Henry A Worth)
Subject: Re: Repost: *MATROX* Support ?
Date: Tue, 9 Aug 1994 16:56:11 GMT

In article <3271sv$d8b@renux.frmug.fr.net>, rene@renux.frmug.fr.net (Rene COUGNENC) writes:
|> Ce brave Michael Teper ecrit:
|> 
|> > I posted a question regarding support for Matrox MGA based video cards
|> > under Linux and have not received any sort of a response.  I find it
|> 
|> This is because you asked your question in the wrong group.
|> As far as XFree86 is concerned, the newsgroup where the XFree86 team
|> can be reached is comp.windows.x.i386unix; they don't read the
|> Linux groups: XFree86 is not Linux-specific.

Actually, very few of the core team or developers seem to have the time 
anymore to actively participate with any newsgroup, though c.w.x.i is
the correct one to try (even c.o.l.help would have been more appropriate). 
If you really want to contact the XFree86[tm] team send email to XFree86@XFree86.Org.

|> 
|> BTW, I may be wrong but I think that Matrox is not supported, because
|> Matrox does'nt want to (sort of :-)). You'll get more details in
|> the right newsgroup I hope.
|> 

Other posts have gone into the whys, another X-server commercial vendor
that is supporting Linux now is Xinside, I think they can be reached
at something like info@xinside.com.
  

-- 
Henry Worth - henry.worth@amail.amdahl.com
No, I don't speak for Amdahl... I'm not even sure I speak for myself.

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

From: rdt@kaiwan.com (R. D. Thomas)
Subject: Re: Workman doesn't work with kernel 1.1.41??
Date: 9 Aug 1994 15:29:12 -0700

In article <1994Aug9.033647.6277@umr.edu>,
Eric Jui-Lin Lu <jlu@cs.umr.edu> wrote:
>Hi *,
>
>This is the 2nd problem I encountered since I upgraded from 1.1.21
>to 1.1.41.  Is it true?  Thanks!!
>
>
>  --Eric
>
>-- 
>***************************************---       Grad. student          ---*
>* Obviousness is always the enemy of  *   \     Jui-Lin Lu (Eric)      /   *
>* correctness.  -- Bertrand Russell   *   /      jlu@cs.umr.edu        \   *
>***************************************---   Univ. of Missouri-Rolla    ---*

    I don't have any problem with workman (from Slackware 2.0) on the
v1.1.41 kernel with Adaptec 1542 SCSI and a Toshiba 3401 CDROM.


-- 
===========================================================================
                                                             rdt@kaiwan.com
===========================================================================

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

From: interred@TexasEx.nosc.mil (Chance C. Geurin)
Subject: Asynchronous socket I/O (SIGIO)?
Reply-To: geurin@nosc.mil
Date: Tue, 9 Aug 1994 21:12:22 GMT

Hi-

I'm trying to use a SIGIO signal under Linux 1.0.9 (Slackware 2.0) to get asynchronous
I/O on a socket.  Seeing as how Linux doesn't have a #define for FASYNC in fcntl.h, I 
used an ioctl (there _is_ an FIOASYNC #defined in sys/ioctl.h).

The following is the relevant code (edited for brevity):

fcntl(sd, F_SETOWN, getpid());          /* Works fine, verified with F_GETOWN and getpid() */
int flag = 1;
ioctl(sd, FIOASYNC, (char *)&flag);     /* Doesn't return an error */

sigpause(0);                                    /* Waits forever for a signal that never comes */


I checked the fcntl_flags (with fcntl(sd, F_GETFL, NULL)) on sd before and after the 
ioctl and received surprising results:
 
Before the ioctl:
fcntl_flags = 0x00             /* OK */

After the ioctl:
fcntl_flags = 0x1000         

If one checks the fcntl.h file, 0x1000 (10000 octal) corresponds to a fcntl_flag of O_SYNC.
Which, besides being wrong, is currently unsupported!  Just for grins, I thought I'd check
and see if an ioctl(sd, FIONBIO, (char *)&flag) followed by an fcntl(sd, F_GETFL, NULL)
returned the correct bits according to fcntl.h.  It did indeed (0x800/04000).

So, what's up with this?  Is the SIGIO signal not supported under Linux, or am I just doing it
wrong?

BTW, I was able to set up a notfier on a socket descriptor under Xview that functioned
flawlessly.

Thanks in Advance,
===============================================================================
Chance C. Geurin
Naval Command, Control & Ocean Surveillance Center, Research, Development,
Test & Evaluation Division (NCCOSC RDT&E or just NRaD).
San Diego, Ca
geurin@nosc.mil
===============================================================================


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

From: mlord@bnr.ca (Mark Lord)
Subject: Re: 1.1.36 -> 1.1.41 - Something broke ESDI support!
Date: 9 Aug 1994 22:31:42 GMT

In article <327r7uINNbav@ope001.iao.ford.com> ekimmina@eve180.cpd.ford.com writes:
> 
>I upgraded from 1.1.36 to 1.1.41 last night. 1.1.36 works perfectly. I have a 
>486/33, 16MB Ram and a Western Digital 1007WAH ESDI controller with 16K H/W 
>cache onboard. It has worked perfectly since 99.14. After the upgrade to 1.1.41, I 
>get failures trying to read SuperBlock for xiafs, EXT, EXT2, and MSDos type file
> systems on hda1 and then a kernel panic. There is also a similar message to the 

Try setting HD_DELAY to 100 (inside hd.c) and try again.  Email if it still
is misbehaving.
-- 
mlord@bnr.ca    Mark Lord       BNR Ottawa,Canada       613-763-7482

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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: IFS (Inherited File System)
Date: 9 Aug 1994 19:48:27 +0200

In comp.os.linux.development, article <3263kd$ed8@elna.ethz.ch>,
  almesber@nessie.cs.id.ethz.ch (Werner Almesberger) writes:
> 
> Not quite, but I plan to do an (experimental) NFS-based IFS later this
> year. The kernel-based one has the problems of a) depending on too many
> other kernel internals and b) being a bit complex.

You're right, _but_ if I were you I'd use the userfs code to do this.

-- 
BRILLIANT'S OBSERVATION ON MODERN ART:
   Not all our artists are playing a joke on the public.
   Some are genuinely mad.
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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

From: steffen@laguna.schiele-ct.de (Steffen R. Mueller)
Subject: Re: g++ 2.6.0 kernel compiler problem
Date: 10 Aug 1994 01:26:12 GMT

: Anyone has tried to use 2.6.0 for kernel builing ?

Yep... Had similar problems here.. I re-installed 2.5.8 and everything is
fine again... 
With a 2.6.0 cmpilte of the 1.140 kernel, my machine was hanging after heavy
netload. After re-installing the 2.5.8 stuff I don't have any problems !
Seems to be a bug in the compiler....

BTW : Had heared of similar problems by a friend of mine using it on a IBM
RS/6000 platform.

Get back to 2.5.8... 

Bye

Steffen

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

From: munster@MCS.COM (Jerry Ablan)
Subject: Re: SLIP speeds 1.0 vs 1.1
Date: 9 Aug 1994 20:48:59 -0500

On 5 Aug 1994 17:43:25 GMT, Dan Saunders spake thusly:
: Sam Oscar Lantinga (slouken@cs.ucdavis.edu) wrote:

: :     I'm using a generic 14.4 internal modem to connect to 
: : UCDavis SLIP server.  Under the 1.0 and 1.1 kernels, I have clocked
: : the raw (zmodem) transfer rate at 2.0 K/s

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

: :     The speed shift happened very early in the 1.1.x series,

: : Any thoughts?
: : I figured I'd post this one little gripe.  Actually, it is only this
: : minor difference in the kernels that prevents me from completely
: : converting to the 1.1.x series of Linux kernels.  I'd love for SLIP 
: : to speed up to 1.0.x levels.

: : Thanks!

: :     -Sam

: I've noticed the same thing.  If anybody knows why, PLEASE let me know!

I jumped from v1.0.8 to v1.1.20 something and noticed no changes.

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

From: jrc01@maroon.tc.umn.edu (Jeffrey Comstock)
Subject: Re: Does anyone use SONY CDU-535 CD-ROM anymore?
Date: Wed, 10 Aug 1994 01:52:48 GMT

In article <31v4q6$50f@solaris.cc.vt.edu>,
David La Croix <dlacroix@guilder.bevd.blacksburg.va.us> wrote:
>I just got a SONY CDU 535 type CD-ROM drive, and I'd like to use it under
>LINUX... I'm using 1.1.38, and the patch I found sony535-0.5 doesn't patch
>cleanly into the 1.1.38.  I would like to know if anyone is using one of these 
>drives, and also, if this patch, (if done by hand) will cause problems with
>the 1.1.30 and up kernels.  I'd like to use 1.1.39 if possible.
>
>Could support for these drives be put into the stock kernel?  (since this is
>extremely close to the CDU 31A type drives.)


I am using the yggdrasil kernel, and it works with my CDU535.  I don't know
which patch level the ygg kernel is at..
--
Jeffrey Comstock
INET: jrc@brainiac.mn.org               AT&T: 317-578-0884
CW:   -. .-. ----- -..             

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

From: vefatica@cockpit.syr.edu (Vincent Fatica)
Subject: cdu31a: Too many consecutive attentions: 11
Date: 10 Aug 1994 02:51:28 GMT
Reply-To: vefatica@mailbox.syr.edu

I had been on a long streak of kernels which mounted mt cdu31a at boot-time
with no problems. That streak came to an end with 1.1.41 and things have not
gotten better with 1.1.42.

On booting, I get a lot of "cdu31a: Too many consecutive attentions: 11"
messages followed by a register dump, then nothing. At this point, a
cold reboot is required.

Earlier kernels continue to work well. I'd like to know what's up.

Respectfully,

Vincent Fatica
Syracuse University


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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: IRQs attached to what?
Date: 9 Aug 1994 20:48:11 +0200

In comp.os.linux.development, article <326aob$f5r@cesdis1.gsfc.nasa.gov>,
  becker@cesdis.gsfc.nasa.gov (Donald Becker) writes:
> 
>    if (irqaction(irq,...) ... 
>        irq2dev_map[irq] = dev; 
>        irq2name_map[irq] = "Frobbitz SuperHyper 6000"; 

Hmm. Better to have a diferent call, along the lines of register_XXXdev.
(I never understood the rationale for the struct sigaction stuff in the
 kernel, anyway.) 

> prompt% cat /proc/net/irq
> IRQ   Count   Flags   Device
>  0      79879     0   Timer

/proc/irq, please, and the title line doesn't belong in the kernel.

-- 
I'd love to, but there's a disturbance in the Force.
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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

From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Where should i386/string.h be?  And floppy code report.
Date: 9 Aug 1994 20:50:29 +0200

In comp.os.linux.development, article <1994Aug8.222928.10455@kf8nh.wariat.org>,
  bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:
> 
> /usr/include/i386 is now unusual in that both libc and linux expect to provide
> it, and the linux-provided one expects to be symlinked into the kernel source
> tree.  I suspect the kernel one should be renamed to /usr/include/linux/i386
> to avoid this, but that's up to Linus.  (I tripped over it rebuilding the
> iBCS2 emulator under 1.1.41.)
> 
Under 1.1.42, Linux moved it to include/asm.

-- 
Q: What's a polar bear?

A: A rectangular bear after a coordinate transform.
-- 
Matthias Urlichs        \ XLink-POP N|rnberg  | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12  \  Unix+Linux+Mac    | Phone: ...please use email.
90491 N|rnberg (Germany)  \   Consulting+Networking+Programming+etc'ing     42

Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.

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

From: brianc@saintjoe.edu (Brian Capouch)
Subject: (Some) NFS-mounted Executables Won't Run on 1.1.41
Date: Tue, 9 Aug 94 22:34:27 CDT

I think there are some VFS problems in the more recent kernels.  I 
only had around 1.1.35, 1.1.40, and 1.1.41--the problem occurs in the 
1.1.4x but not the older kernel.

Some, but not all, executables that I have NFS-mounted on another Linux
box give a segmentation violation when run under the newer kernels but 
are just fine under the older ones.  

Running ldd on the executable enables prediction of failure: if it 
returns silently then the app isn't going to execute, if it shows anything
at all it will run just fine. 

Some programs that exhibit the problem: xv 3.01, rlogin
Some programs that don't: Mosaic 2.4, login

Moving the executables onto a "real" disk solves the problem in every 
case. 

Sorry I don't have more info on version numbers, configuration, etc.

Brian Capouch
brianc@saintjoe.edu

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

From: Oliver Schoett <schoett@informatik.tu-muenchen.de>
Subject: Files written from Linux via NFS begin with null bytes
Date: 9 Aug 1994 19:36:32 GMT

I have a serious problem with Linux's NFS: Many of the files written
via NFS to an SNI RM400 begin with a lot of null bytes, followed by
the correct tail of the file from a certain (apparently random) point.
Most frequently (50% probability), this happens to files generated by
a macro processor compiled under approx. 0.99pl14, but it has also
happened occasionally to files I wrote out from GNU Emacs (19.24, I
think).

The bug started to occur _around_ kernel version 1.1.30 and has
persisted until 1.1.41 so far.  Can anyone help me, has anyone seen
something like this bug?

Details of my setup: 486 DX2/66, VL bus, 3c509 ethernet card, IDE
disk, Slackware 1.2.0.3, net-tools 1.1.38 (and earlier for earlier
kernels).  The target machine is an SNI (Siemens Nixdorf) RM400 M10
(MIPS Processor) with SINIX 5.41 (SysVR4).  The NFS mount has options
hard, bg, intr, rsize=1024, wsize=8192, but the bug occurred also with
wsize=1024. (rsize > 1024 does not work reliably on my system when it
becomes loaded.)

Oliver Schoett  <schoett@informatik.tu-muenchen.de>
Schraudolphstr. 24, 80799 Muenchen, Germany.  Phone +49 89 272 51 58

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


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