Subject: Linux-Development Digest #950
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:     Tue, 26 Jul 94 22:13:11 EDT

Linux-Development Digest #950, Volume #1         Tue, 26 Jul 94 22:13:11 EDT

Contents:
  Re: GOTO haters ..Re: Linux Performance En (Gregory Trubetskoy)
  Re: Parallel Port QIC-80 and FTAPE (Brett Coon)
  Re: IDE patch won't work w/new kernels? (Mark Lord)
  Re: 1.1.34 won't compile (Slackware 1.1.1) (Dennis Flaherty)
  Re: Bug? Bursty refresh in emacs under X in 1.1.x (Caleb Epstein)
  Re: threads in kernel (John Richardson)
  FYI -- context switching times (Elan Feingold)
  Re: Energy Star Screen Saver for X? Monitor Shutdown codes? (matthew c. mead)
  Re: CD-ROM tray control (BCL)
  Re: 1060 cyliders a problem? (Steffen W. Schilke)
  help with garbled sockets: linux<->sun,hp--fine with alpha (Dorwin Shields)
  Re: threads in kernel (Robert Sanders)
  Panasonic CD-ROM broke under >1.1.31 (lcvanveen@et.tudelft.nl)
  Re: ARP broken ?! (S.G. de Bruijn)

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

From: grisha@cais.cais.com (Gregory Trubetskoy)
Subject: Re: GOTO haters ..Re: Linux Performance En
Date: 26 Jul 1994 21:38:09 GMT

Bill C. Riemers (bcr@k9.via.term.none) wrote:
: In article <30n92c$8kc@picasso.cssc-syd.tansu.com.au> chrisb@tansu.com.au (Chris Bitmead) writes:

:    while (0 < (size = read(in, buf, sizeof(buf))))
:          if (write(STDOUT_FILENO, buf, size) != size)
:                  {
:                  fprintf(stderr, "Write Error\n");
:                  rtn = 1;
:                  }

: It isn't any better than a for() loop.  But in this case you have a
: counter of the file size, so this is the equivilent of a for() loop!!!
: Sorry to waist more bandwidth on this, but it seems a # of people
: where confused by my comment.


Now I'm confused even more. How is the above while similar to for? For's 
are used to keep a counter and such, whereas the above loop will repeat 
the reads from the file if the file does not fit in the buffer (buf) and 
will stop when there is no more to read...

There is nothing finite in the condition, as a matter of fact this piece
of code should run infinitely if the file is infinite (not unusual!). I
can see the point of using for's instead of while's (although I've never
heard of this before), and the above example is bad because it can be an
infinite loop. And the paragraph that follows it is even more confusing
:)))

There are times when you must use while's....

Gregory


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

Crossposted-To: comp.os.linux.help,comp.os.linux.admin
From: brett@iit.com (Brett Coon)
Subject: Re: Parallel Port QIC-80 and FTAPE
Date: Tue, 26 Jul 1994 21:43:40 GMT

habi@bauv.unibw-muenchen.de (Venant Habiyambere) writes:

>Hi.

Hi.

>I' m trying to get my Parallel Port QIC 80 drive to run
>with Linux. ( There is no problem with Dos )

>Please let me know how i can Backups using FTAPE.

This is a common question.  Currently there is NO Linux support for
any parallel-port backup system.  The reason for this is that the
various parallel port adapters use proprietary hardware, and their
manufacturers aren't keen on releasing programming info.  If anyone
could actually get detailed programming info for one of these devices,
I'm sure there would be plenty of people willing to help develop drivers.

-Brett

--
+------------------------------------------------------------+
| Brett Coon  -  brett@iit.com or brettc@leland.stanford.edu |
| Integrated Information Technology Inc. (408) 727-1885 x367 |
+------> finger brettc@leland.stanford.edu for PGP key <-----+

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

From: mlord@bnr.ca (Mark Lord)
Subject: Re: IDE patch won't work w/new kernels?
Date: 26 Jul 1994 19:08:14 GMT

In article <30r817$jsj@network.cc.jyu.fi> tjko@tarzan.math.jyu.fi writes:
>
>IDE Performance Patch v2.0 [by Mark Lord] doesn't work with new 
>WD540 drives??? Or is it just my kernel 1.1.30 that causes the problem?
..
>And here's what happens when I try to enable multi-sector mode:
>
>technocore:/root# hdparm /dev/hda
>MultModeCount=0, rc=0
>unmask=0, rc=0
>technocore:/root# hdparm /dev/hda 16 1
>MultModeCount=16, rc=0                  <-- mode change seems to be OK..
>unmask=1, rc=0
>technocore:/root# hdparm /dev/hda
>MultModeCount=0, rc=0                   <-- but NOT...
>unmask=1, rc=0
>technocore:/root# hdparm /dev/hda 16 1
>MultModeCount=16, rc=-1                 <-- mode change won't work anymore
>unmask=1, rc=0

Nothing is wrong.  Really!

The problem here, is that the multmode changes don't actually occur
until the next physical access to the drive.  To prevent a second change
from interfering with one already in progress, the ioctl interface simply
rejects the subsequent ones.

To cure this, just access the hard drive between attempts.. making sure that
whatever you access is not completely satisfied from the buffer cache.

For r/w mounted root filesystems, just typing 'sync' is good enough.


And now, the challenge:  any ideas on what I can do to *force* a disk access
(read-only) inside hdparm.c, to remove this problem completely?
-- 
mlord@bnr.ca    Mark Lord       BNR Ottawa,Canada       613-763-7482

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

From: dennisf@denix.elk.miles.com (Dennis Flaherty)
Subject: Re: 1.1.34 won't compile (Slackware 1.1.1)
Date: Sun, 24 Jul 1994 17:47:35 GMT

In article <30qb50$i3k@nwfocus.wa.com>, Vince Skahan <poster> wrote:
> 
> Has there been a major change in 'ld' that I have missed in the recent
> past ? I'm running Slackware 1.1.1 with a 1.1.23 kernel (which is nice and stable),
> gcc2.4.5, shlibs 4.5.24.
> 
> In trying to keep semi-current with the new kernels, I grabbed
> 1.1.34 and got the following problem :
> 
> ld -qmagic -Ttext 0xfffe0 boot/head.o init/main.o tools/version.o \
>         kernel/kernel.o mm/mm.o fs/fs.o net/net.o ipc/ipc.o \
>         fs/filesystems.a \
>         drivers/block/block.a drivers/char/char.a drivers/net/net.a ibcs/ibcs.o drivers/FPU-emu/math.a \
>         lib/lib.a \
>         -o tools/zSystem
> ld: unrecognized option `-qmagic'
> Usage: ld [-d] [-dc] [-dp] [-e symbol] [-l lib] [-n] [-noinhibit-exec]
>        [-nostdlib] [-o file] [-r] [-s] [-t] [-u symbol] [-x] [-y symbol]
>        [-z] [-A file] [-Bstatic] [-D size] [-L libdir] [-M] [-N]
>        [-static] [-nojump] [-dll-verbose] [-S] [-T[{text,data}] addr]
>        [-V prefix] [-X] [file...]
> make: *** [tools/zSystem] Error 1
>

Go into the Makefile, the section that looks like,

# 
# Set these to indicate how to link it..
#
# -zmagic:
#
#LOWLDFLAGS      = -Ttext 0x1000
#HIGHLDFLAGS     = -Ttext 0x100000
#
# -qmagic (we need to remove the 32 byte header for bootup purposes)
#
LOWLDFLAGS     =-qmagic -Ttext 0xfe0
HIGHLDFLAGS    =-qmagic -Ttext 0xfffe0


Uncomment the two zmagic lines, and comment out the two qmagic lines.

-- 
Dennis T. Flaherty              Home: dennisf@denix.elk.miles.com
Flaherty Nanobreweries          Work: dennisf@se01.elk.miles.com
     Oatmeal Stout: It's the Right Thing to Drink!

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

From: cae@cae.ny.jpmorgan.com (Caleb Epstein)
Subject: Re: Bug? Bursty refresh in emacs under X in 1.1.x
Date: 26 Jul 1994 12:52:17 GMT

Delman Lee (delman@mipg.upenn.edu) wrote:
| Hi! First some system info:
|   486DX2-66, Asus PCI/I-486SP3G (PCI/ISA) motherboard, XFree86 2.1.1,
|   emacs 18.59, et4000 based ISA video card.

| In X in 1024x768 using XF86_SVGA server, screen refresh in emacs with
| CTRL-L becomes bursty and slow (chucks of text at a time with a long
| interval before the next chunk) after about half a dozen of
| consecutive CTRL-L's. The bug is repeatable. It appears in Linux
| 1.1.{19,24,27,34}.

        I have the same problem and have had since the introduction of
the new tty code written by Ted T'so (kernel 1.1.13, I believe).  I
mentioned it to Ted when I first noticed it and we exchanged some
email, but he was never able to reproduce it on his system.  I'm glad
I'm not the only one who is experiencing this annoying syndrome.

        My config: 486 DX2/66 EISA/VLB motherboard, Linux 1.1.13
through 1.1.35 XFree86-2.1, libc-4.5.26, emacs-19.25 (compiled by me),
et4000-based VLB video.

        Anyone else?

--
[ cae@jpmorgan.com ][ Caleb Epstein ][ JP Morgan & Co. Incorporated ]

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

From: jrichard@cad3.uml.edu (John Richardson)
Subject: Re: threads in kernel
Date: 26 Jul 1994 19:35:31 GMT

In article <313igq$i33@Times.Stanford.EDU> lm@stanford.edu (Larry McVoy) writes:

>   SGI has a model which is like the clone() stuff discussed here recently.
>   A "thread" is simply a new process that happens to share (part of) the 
>   parent's address space.  That is easy to implement, easy to scale, and
>   simple.

I think people implementing threads are basing them on the pthread
model (I could easily be wrong!).

I must have missed the clone class as discussed with the SGI.  Can you 
give us a quick overview of what the SGI does that is so nice?


>   G Dinesh Dutt (brat@htilbom.ernet.in) wrote:
>   : I have been seeing a lot of messages with people interested in seeing threads
>   : in Linux kernel. Well, development for one has already started. We'll let you
>   : know as and when results come in.

Are you (brat@htilbom.ernet.in) doing this?  Maybe you could let us know 
what's going on to avoid duplications...  I need (want) kernel
threads for some stuff I'm doing and am willing to put in 40 or so hours
into getting them to work...


John

--
John Richardson
jrichard@cs.uml.ledu

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

From: feingold@avette.zko.dec.com (Elan Feingold)
Subject: FYI -- context switching times
Date: 26 Jul 1994 19:13:58 GMT
Reply-To: feingold@avette.zko.dec.com (Elan Feingold)



Got this off of a *.os.* group:

Date: Wed, 9 Feb 94 14:56:13 PST
From: Larry.McVoy@eng.sun.com (Larry McVoy)
To: dck@cse.nd.edu

68     99 Mhz HP-735 HP-UX 9.01
80     33 MHz 486DX QNX 4.2
87    160 Mhz DEC 4000/610 DEC OSF/1 v1.3
98     40 MHz R3000 DEC 5000/240 Ultrix 4.2
98     66 MHz 486DX2 Linux 0.99.10      ***** Cool! *****
102     62 MHz IBM-RS6000/580 AIX 3.2
106     66 Mhz snake HP-UX 9.x
128     40 Mhz SS10 SunOS 4.1.3
154     25 MHz R3000 DEC 5000/200
158     50 MHz R4000 SGI
188     48 Mhz + 1Me$ SS10 SunOS 5.2
198     33 MHz Sparc 4/470 SunOS 4.1.1
210     33 Mhz 486 386BSD 0.1
212     50 Mhz RIOS AIX 3.2
225     40Mhz SS10 SunOS 5.2
230     40Mhz SS2 SunOS 4.1.2
281     20 MHz R3000 DEC 5000/120
345     33 MHz R3000/3010 SGI Irix 4.0.5
380     33 MHz 486 NetBSD
454     40Mhz SS2 SunOS 5.2
628     50Mhz Sparc classic SunOS 5.2

%Title Context switch times in microseconds (raw numbers)

I wonder how we do with the later kernels...

elan

--
===============================================================================
|| Elan Feingold                  || "Two of the most famous products of     ||
|| Software Engineer II           ||  Berkeley are LSD and Unix. I don't     ||
|| Digital Equipment Corporation  ||  think that is a coincidence."          ||
|| Work: 603.881.1115             ||                       - Anonymous       ||
===============================================================================

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

From: mmead@csugrad.cs.vt.edu (matthew c. mead)
Crossposted-To: comp.os.linux.help
Subject: Re: Energy Star Screen Saver for X? Monitor Shutdown codes?
Date: 25 Jul 1994 09:56:52 -0400

In article <30tnth$97f@vishnu.jussieu.fr>,
Kim-Minh Kaplan <kkaplan@cdfhp3.in2p3/fr> wrote:
>here if anyone is interested.  The original patch was from Christoph
>Rimek, chrimek@toppoint.de.  I don't know why, but turning off both
>HSYNC and VSYNC doesn't goes into `complete-off' mode

        Please post the patches or put them anon-ftp somewhere.  Thanks!


-matt




-- 
Matthew C. Mead -- System/Network Administration, User Support, Software Devel.
Virginia Tech Center for Transportation Research
Work Related: mmead@hq.ctr.vt.edu | All Other: mmead@vt.edu
WWW: http://thumbtack.bevc.blacksburg.va.us:/~mmead

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

From: cypress@connected.com (BCL)
Subject: Re: CD-ROM tray control
Date: 26 Jul 1994 12:37:12 -0700

Eberhard Moenkeberg (emoenke@gwdu03.gwdg.de) wrote:
: BCL (cypress@connected.com) wrote:
: :   I have just gotten my Matsushita CR-563 working with Linux and my SB16
: : card. There are no problems with normal operations, but I need to be able to
: : control the tray when there is no disk in it, and when it is already
: : open(ie. close it).

: The current sbpcd.c code (only in the 1.1.x kernels, last regarding change
: was last week, I think) automatically closes the tray during an "open"
: request and locks it.
: If you say "CDROMEJECT" (you can only say that if the drive is "opened"), I
: open the tray. Next "open" request closes it again (workman users have to
: hurry :-).

  Hehe, and watch that the fingers don't get caught in the door.

  After another late night, I finally have it working like I want it. I
don't know if what I did will adversly effect using it for everyone else,
but it works for me. Basicly what I did is remove the DiskInfo call in the
open routine, and put conditions around the DiskInfo call in the ioctl
processing routine(I think that was all). The problem was that when an open
was done it expected a disk in a closed drive. Now You can do a CDROMEJECT
to open the tray, and a CDROMSTOP to close the tray!

  Thanks,

      Brian
-- 
============================================+================================
 Linux: The choice of a GNU generation      |  cypress@connected.com
 sysop  of FreeZone datahaven (206)569-2911 |  finger for PGP key
============================================+================================

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

From: sws@tora.RoBIN.de (Steffen W. Schilke)
Subject: Re: 1060 cyliders a problem?
Date: Tue, 26 Jul 1994 19:15:29 GMT

David Monro (davidm@dmssyd.syd.dms.CSIRO.AU) wrote:

: In article <1994Jul20.164639.16726@cc.ntnu.edu.tw>, s21008@cc.ntnu.edu.tw (DL83-08) writes:
: |> When fdisking my new Maxtor 7546AT hard drive (1060 cyl, 16 HD, 63 Sect.),
: |> fdisk told me that having over 1024 cylinders could cause problems; it did!
: |> When I hit 'p' to look at the new partitions, I got a wad of error messages
: |> telling me that real and virtual 'this & that' (sorry, I don't remember --
: |> it was a long day; see above posting). 

: Well I run a drive with 1048 cylinders without problems. You get a silly message

My Toshiba MK538 has 1120 cyl. and I have no problems at all. I just had
to switch off the most options on my Adaptec 1542CF (exept scanning)

Cheese          steffen
--
[Standard Disclaimer] in addition I would like to speak with my lawyer ....
S. Schilke; PoBox 1213; 61102 Bad Vilbel; Germany  a.k.a  sws@tora.RoBIN.de
                  Sokonoke Sokonoke tora-sama ga touru
$@%9%F%U%'%s(J  $@CN2H!Z%7%k%1![(J  $@$=$3$N$1$=$3$N$18WMM$,DL$k(J
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

From: parprods@hellcat.ecn.uoknor.edu (Dorwin Shields)
Subject: help with garbled sockets: linux<->sun,hp--fine with alpha
Date: 26 Jul 1994 19:38:56 GMT



   could anyone  help me figure out why my sockets don't seem to work
when I send data to sun's and hp's--they work fine between linux boxes
and when a linux box talks to an alpha--but suns and hp's won't
work--I never get an error during the write and read calls but the data
is useless--I'm doing things like
  read(sockfd,&cmd,sizeof(int));
  write(sockfd,&cmd,sizeof(int));
  if I try to pass 1 through (cmd=1, then send as above) I get something
like 16777216 on the sun end--thereafter, whenever I try to read from the 
linux end I seem to get that number there too--any suggestions --
I also use reads and writes like:
  read(sockfd,&xinc,sizeof(double));
  and read(sockfd,&colors[0],nx*sizeof(double));

Thanks,

Dorwin

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

From: rsanders@mindspring.com (Robert Sanders)
Subject: Re: threads in kernel
Date: 26 Jul 1994 23:50:10 GMT

On Tue, 26 Jul 1994 17:10:20 GMT, rob@pe1chl.ampr.org (Rob Janssen) said:

> I'm confused...  I think threads *already are* in the Linux kernel.
> What are you developing?  Is it a library to make them more easily
> usable from a C program?

A usable thread system is *not* in the Linux kernel.  clone() is only
partway there; there's more to threads than sharing an address space.
In most models, threads share more of the process state, like open
file descriptors.  For example, once a process clone()s itself under
Linux, a subsequent open() by one of the threads will not be seen by
the others.  Neither do clone processes truly share an address space;
the cloned process receives a *copy* of the parent's MM region list,
but, as with the file descriptor table, a change by one of the
processes does not update the MM list of the other.

Updating the C library is another problem altogether.  It looks like
the pthreads package available from sipb.mit.edu provides thread-safe
versions of many C functions, including sleep() and the stdio suite.

  -- Robert

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

From: lcvanveen@et.tudelft.nl
Subject: Panasonic CD-ROM broke under >1.1.31
Date: 25 Jul 94 15:40:10 +0200

When mounting my CD-ROM (panasonic cr-562b) under 1.1.35 I got
this nice error:
mount: block device /dev/sbpcd is not permitted on its filesystem
It wasn't in at 1.1.30 so it came later (I presume at 1.1.32).
Does anybody have a fix here.
Audio cd's still work, as you would have guessed.
Thank's a lot in advance.
Martijn.

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

From: debruijn@cs.utwente.nl (S.G. de Bruijn)
Subject: Re: ARP broken ?!
Date: Tue, 26 Jul 1994 17:06:33 GMT

Hans-Christoph Rohland (hrohlan@gwdg.de) wrote:
: David Marples (dmarples@voyager.comms.eee.strath.ac.uk) wrote:

: : Thank god someone else has this problem - I thought it was just me!
: : The prob. does not exist on the 1.0.* kernels, but certainly does to
: : date on all 1.1.* kernels from 1.1.22 upwards (I didn't test before
: : that, compilation takes a while, you know).  So, since I want to use
: : bootp, I'm stuck with 1.0.9 for now!  I didn't go backwards through
: : the 1.1's to find out when it did occour though, 'cos I was bored by
: : then.

: I am using bootpd with kernel 1.1.3 (the last with old networking code)
: without probs.
: Christoph

You did not read the previous posts. The problem arose with
1.1.18.  My Xterminal broke with it too, using bootp (well.. not
literally ;)  After some very long searching, I found at least a
fix for me. My bootp clients (bootless Xterminal, ncsa) work
again. (It took me weeks just to find it was an arp problem...:(

Patch of file ....linux/net/inet/arp.c ( I did this from 1.1.33 kernel)
=====8<=====8<=====8<=====8<=====8<=====
*** arp.c.orig  Tue Jul 26 18:38:44 1994
--- arp.c       Tue Jul 26 18:39:56 1994
***************
*** 988,993 ****
--- 988,996 ----
         */
        
        switch (r.arp_ha.sa_family) {
+               case 0:
+                       /* Moan about this. ARP family 0 is NetROM and _will_ be needed */
+                       printk("Application using old BSD convention for arp set. Please recompile it.\n");
                case ARPHRD_ETHER:
                        htype = ARPHRD_ETHER;
                        hlen = ETH_ALEN;
=====8<=====8<=====8<=====8<=====8<=====
.. And I finally can upgrade!!!

Any comments on this?

Regards,
Steef
==============
S.G. de Bruijn              E-Mail: debruijn@cs.utwente.nl
Twente University of Technology, Dept. of Computer Science 
Enschede                                   The Netherlands
Phone: Work: +53 894191                   Home: +53 334812
=========================== @@ ===========================
signature: file not found

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


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