Subject: Linux-Development Digest #25
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:     Mon, 15 Aug 94 02:13:05 EDT

Linux-Development Digest #25, Volume #2          Mon, 15 Aug 94 02:13:05 EDT

Contents:
  Linux NFS client performance (Dan Pop)
  Re: GP faults (Nicolas BOUGUES)
  Re: Novell NE2000 Network Card on Linux (Paul Makeev)
  NCR SCSI and 53c825 (John Grossman)
  Re: DOSEMU 0.53: Developers and testers needed! (Andrew Anderson)
  Please fix Pro Audio SCSI biosparam (Thomas E Zerucha)
  Mouse problem... (Timo Kokkonen)
  Re: FPE signal problem (Help) (WE Metzenthen)
  Re: Linux NFS client performance (Charles V. Carlson)
  VGA monochrome trouble (JL Gomez)
  Re: Anyone want T1 access from Linux? (Jonathan Dasteel)
  Was: [hd] Do you recognize this error message? Now: Error survey (The Answer is 42.)
  Re: Registrar for major device #s? (Paul Stewart)
  Re: 1.1.43 won't link on my system (Rob Janssen)

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

From: danpop@cernapo.cern.ch (Dan Pop)
Subject: Linux NFS client performance
Date: Sun, 14 Aug 1994 18:19:47 GMT

I have a notebook and a D-Link DE-620 and I'm currently running
1.1.44. I was surprised by the poor NFS client performance on my
system, especially when writing data to the server. These are the
numbers:

FTP performance on reading: 100 KB/s
NFS performance on reading:  70 KB/s

FTP performance on writing: 150 KB/s
NFS performance on writing:  25 KB/s

The server is an idle HP/UX box, if it matters. Has anybody a clue about
how to improve the NFS performance? 

BTW, using 1.1.22 I get the same results.

Dan
--
Dan Pop 
CERN, CN Division
Email: danpop@cernapo.cern.ch
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

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

From: nicolas@magix.uucp (Nicolas BOUGUES)
Subject: Re: GP faults
Date: 14 Aug 1994 16:53:06 +0200

Rob Janssen (rob@pe1chl.ampr.org) a ecrit:
: In <32ghft$85@magix.uucp> nicolas@magix.uucp (Nicolas BOUGUES) writes:

: >By the way, I am a little bit surprised to see that Linux uses 3.4 Mb of
: >system data, on my 20 Mb machine.

: >My kernel is standard, except I do not avec mathco emu, neither minix fs nor
: >xiafs. I use SLIP, PPP, NE2000, SBPCD, verbose SCSI errors, and an SB16
: >with all sound driver options enabled.

: How did you get that memory usage information?

I got it from the memory info during boot process. Here is the line I get
with 1.1.44 :
Memory: 15900/20480k available (728k kernel code, 384k reserved, 3468k data)

And with 1.1.39 (with the same kernel config) :
Memory: 18248/20480k available (696k kernel code, 384k reserved, 1152k data)

I do not look at it carefully each time I boot up Linux, but as far as I
remember, it has always looked like (more or less) 1.1.39.

: Rob
: -- 
: -------------------------------------------------------------------------
: | Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
: | e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
: -------------------------------------------------------------------------

--
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Nicolas BOUGUES
nbougues@renux.frmug.fr.net
Sysop of magix : ++ 33 (1) 45 21 02 52 (shell & uucp)

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

From: Paul Makeev <mac@glas.apc.org>
Date: 14 Aug 94 23:43 GMT+0400
Subject: Re: Novell NE2000 Network Card on Linux

Hmm. NE2000 cards are not Novell anymore, since Artisoft bought Eagle.
I have 4 CNET cards working as NE2000 under Linux (CNET-650). They are
one of the best clones. No problems detected.

SY, Paul.

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

From: jgrossma@clark.net (John Grossman)
Subject: NCR SCSI and 53c825
Date: 14 Aug 1994 19:20:45 -0400



 
        Does anyone out there know if a driver has been written for
an NCR scsi card that uses the 53c825?  I know there is one for the
810, but I am not so sure about the 825?  Is it just being developed?
I tried the 810 driver but it didn't work, and the author said something
about having trouble developing for the 825 because he didn't have a
card to test it on.  Is there a way I can offer to be an alpha tester?
On another note, I was looking at the compatibility list on the slackware
distribution box and it mentioned just Ultrastor under the list of scsi
cards.  Does this mean that ultrastor keeps its interface so standard that
one driver will work with all cards?  if so, does ultrastor make a PCI
scsi card?  Last question, if anyone has an NCR that uses the 810 chip,
do you know if it has onboard bios for starting on dos, and does it come
with an add driver for os2?  thanks for your help, please reply either to
this newsgroup or e-mail.

jgrossma@clark.net







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

From: andrew@amelia.db.erau.edu (Andrew Anderson)
Subject: Re: DOSEMU 0.53: Developers and testers needed!
Date: 15 Aug 1994 00:00:43 GMT

Sam Oscar Lantinga (slouken@cs.ucdavis.edu) wrote:
: Mark Rejhon (mdrejhon@calum.csclub.uwaterloo.ca) wrote:
: : I am interested in having more DOSEMU developers on the team,
: : even those who only want to look through DOSEMU and offer suggetions
: : on how it can be improved!  Testers are also welcome.

:       I'm testing it out, and I have found that under ansi_xterm
: and regular xterm, dosemu doesn't recognize <CR>
: It works fine in the console.  Is this a termcap problem, or is it
: something with dosemu?

The thing I noticed in Xwindows using dos -X is that you have to have
the window that you started DOSEMU in in focus.  I assume this is because
this is a new feature, and under development, but just in case it's
not already known... :)

--
|===========================================================================|
|  Andrew Anderson                              andersoa@erau.db.erau.edu   |
|  Novell Network System Administrator          andersoa@bart.db.erau.edu   |
|  Linux System Administrator                   andrew@wilbur.db.erau.edu   |
|                                                                           |
| I don't speak for ERAU, and God knows I don't want them to speak for me!  | 
|===========================================================================|

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

From: zerucha@shell.portal.com (Thomas E Zerucha)
Subject: Please fix Pro Audio SCSI biosparam
Date: 15 Aug 1994 00:06:24 GMT

All that needs to be done is to add support for >1G partitions.  I think
the following addition will work.

401,405d400
<   if( ip[2] > 1024 ) {
<     ip[0] = 255;
<     ip[1] = 63;
<     ip[2] = size / (255*63);
<   }

and you might want to insert

    if( ip[2] > 1023 )
      ip[2] = 1023;

between the ip[2] = size... and the } just in case of an 8GB+ drive.
---
zerucha@shell.portal.com - main email address
      

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

From: tjko@tarzan.math.jyu.fi (Timo Kokkonen)
Subject: Mouse problem...
Date: 15 Aug 1994 00:52:52 GMT

I have a mouse (TrueMouse 300) that emulates both microsoft and 
mousesystem mouses.  It's working fine under DOS (with microsoft driver 
it works like ms-mouse and with mousesystem driver it works like 
mousesystem-mouse...) 

But under Linux / X (kernel v1.1.42, XFree86 v2.1.1) it will work only as
mickeysoft mouse :-(  

So is the problem in kernel or X-server ? 

I think, that the X-server doesn't initialize mouse in the same way as
the mousesystem's DOS driver does, so the autodetect mechanism
in my mouse won't change the mode to mousesystems...

So I examided the utilities that came with the mouse with debugger...
and found that I can force the mouse to MouseSystem mode quite simply:

mox dx, 3F8        ; COM1....
add dx, 4
mov al, 8          ; 08 = 3-button mode, 0b = 2-button mode
out dx,al
sub dx, 4
in  al,dx
add dx, 5
in  al,dx


Since, I ain't very familiar with Linux, yet. I would really appreciate
any help how to patch mouse init routine in X-server (in kernel?) to
enable MouseSystems mode.

-- 
=======================================================111010=101101=101001===
 Timo Kokkonen, Student of Computer Science, University of Jyvaskyla, Finland
 email: tjko@math.jyu.fi, tjko@jyu.fi            URL: http://www.jyu.fi/~tjko
====================================="In space no one can hear you scream."===

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

From: billm@jacobi.maths.monash.edu.au (WE Metzenthen)
Subject: Re: FPE signal problem (Help)
Date: 15 Aug 1994 01:08:08 GMT

Olaf Flebbe (flebbe@pluto.tat.physik.uni-tuebingen.de) wrote:
: s3176015@techst02.technion.ac.il (Studnitzky Boaz ) writes:

: >Hi, i am wondering if anyone can tell me why the following code
: >produces an FPE exception after the addition ....

: >#include <stdio.h>
: >#include <signal.h>

: >void fp_ex(int sig)
: >{
: >  printf("FPE\n");
: >}

: >void init_signals(void)
: >{
: >  struct sigaction a;
: >  a.sa_handler=fp_ex;
: >  a.sa_mask=0;
: >  a.sa_flags=SA_RESTART;
: >  a.sa_restorer=NULL;
: >  sigaction(SIGFPE,&a,NULL);
: >}

: >main()
: >{
: >  double a,b,c;
: >  init_signals();
: >  a=1;
: >  b=0;
: >  printf("1\n");
: >  c=a/b;
: >  printf("2\n");
: >  a=b+1;
: >  printf("3\n");
: >  printf("a=%f\n",a);
: >}

: >I would appreciate any comments on the above code, or the behavior.

: 1) Floating point exceptions are raised for the *next* floating point
: operation after a illegal operation was made. This is due to the
: design of the i387.

: 2) Therefore you cannot trap the exceptions, like you want to.

: 3) Try the libieee.a library to trap all exceptions and enabling
:   a IEEE 765 conformant behaviour.

: olaf

It might be useful to add a little more detail:
  the statement c=a/b causes gcc (but only if you do not compile with
  optimizations) to generate:
             fld
             fdiv
             fstp
  The first error occurs with the fdiv and, as Olaf points out, the
  floating point interrupt occurs when the _next_ floating point instruction
  is encountered (in this case it is the fstp instruction).
  The reason for this delay in the interrupt is to allow for the fact
  that an 80486 has concurrent execution of FPU instructions and other
  instructions (see an Intel 80486 book for further dsicussion).

  So far so good. Now the fun starts. It is the responsibility of your
  signal handler to find the cause of the signal and take appropriate
  action. For SIGFPE this means doing more than simply returning to
  the code which caused the interrupt. If you really want to return to
  the point where the interrupt occured then you should:
     (a) determine the precise cause of the interrupt,
     (b) set up the FPU stack with the appropriate values,
     (c) set the FPU status flags as required,
     (d) you can then return to the point where the interrupt occured.
  Doing all of this is quite tricky and unfortunately is impossible to
  do in many circumstances with gcc 2.5.8 (and probably with gcc 2.6.0,
  but I haven't checked yet). The maintainer of the 386 parts of gcc is
  aware of this problem (or at least was when I raised this matter some
  months [or years?] ago).

  The Linux kernel allows proper handling of SIGFPE's. The most appropriate
  action for a SIGPFE signal handler is probably to do a longjump() to
  some error handling code. To allow for this case, the kernel clears
  the FPU stack and the status flags. This means that the error handling
  code in "C" programs gets the FPU in a state such that it does not need
  to know about the details of an Intel FPU.

  Now you should be able to see what is happening in the original program
  above. As pointed out, the first interrupt occurs when the "fstp"
  instruction is encountered. The kernel then clears the FPU stack and
  then when the signal handler returns to the "fstp" instruction another
  FPU exception condition is found, i.e. attempting to store from an
  empty stack. The interrupt due to this exception occurs when the next
  FPU instruction is encountered, which in the program above occurs at 
  the     a=b+1;   statement.


(ps: I rarely read c.o.l.d, so I may miss any follow-up to this message unless
it is emailed to me.)

--
Bill Metzenthen
Mathematics Department
Monash University
Clayton, Victoria, Australia
email: billm@vaxc.cc.monash.edu.au
       billm@euler.maths.monash.edu.au

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

From: carlsc@medtronic.COM (Charles V. Carlson)
Subject: Re: Linux NFS client performance
Date: 15 Aug 1994 01:28:08 GMT

Dan Pop (danpop@cernapo.cern.ch) wrote:
: NFS performance on reading:  70 KB/s
: NFS performance on writing:  25 KB/s

These numbers jive with what I get off of DOS NFS clients to Sun server.
(doesn't seem to matter to much what model).
Remember, NFS writes are synchronous, which means the data has to be
committed to disk before the client can continue.  This is what gives
NFS its stateless nature so servers can go up and down with low probabilty
of clients losing data.
At work, everytime one of the Novel 3.12 servers goes down, 250 people
have to reboot.  Everytime one of the Unix servers goes down ( less 
frequent than the novell :) ) people just have to hang tight for a few
minutes.

: The server is an idle HP/UX box, if it matters. Has anybody a clue about
: how to improve the NFS performance? 

I believe HP/UX has the ability to turn off synchronous writes (ie, make
them asynch writes) check your manuals.  There was a patch posted to
the Sun groups a while back to do the same for them.  You can also
buy various hardware disk NFS caches that cache to NOV ram.

However, in a business environment, I would leave the synch writes on.
The amount of data corruption that could result in a crash don't
make the speed increases worth it.

Charles


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

From: kitana!sysop@caprica.com (JL Gomez)
Crossposted-To: comp.os.linux.help
Subject: VGA monochrome trouble
Date: 14 Aug 1994 22:34:03 -0500

I'm running 1.1.44.

I'm using an IBM PS/2 VGA monochrome monitor attached to a 16-bit ISA
256K video card.

My problem is when I run 'seejpeg' and leave the program, my screen
image jumps around.  I've tried using 'reset' to no avail and the only
solution is to re-boot the machine.

Is there a way to tell Linux that my console is a VGA monochrome?

Thanks for the help!
-- 
sysop@kitana.org

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

From: jbd@laplata.dasteel.com (Jonathan Dasteel)
Subject: Re: Anyone want T1 access from Linux?
Date: 15 Aug 1994 04:01:27 GMT
Reply-To: jbd@durango.net

>>>>> "Bill" == Bill Kress <kress@kentrox.com> writes:

    Bill>   My company produces high bandwidth access products, mostly
    Bill> CSUs and DSUs.  We currently have a PC card with software
    Bill> for Novel Netware, and I was wondering if there was anyone
    Bill> who thinks that this kind of product would be usefull under
    Bill> Linux.

    Bill> So, basically, is there anyone out there who wants an
    Bill> internal CSU/DSU card for Linux, or Linux still too hobbie
    Bill> oriented to support this kind of a product?

This would be very usefull. I am especially in a product which can do
Frame Relay. 

--jbd 
--
Jonathan Dasteel                     Snail-mail:
(303) 385-4177                       DurangoNet, Inc.
(303) 385-6745    (Facsimile)        777 Main Avenue, Suite 205
jbd@durango.net   (Internet)         Durango, Colorado 81301

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

From: jwiegand@odie.temple.edu (The Answer is 42.)
Subject: Was: [hd] Do you recognize this error message? Now: Error survey
Date: 15 Aug 1994 04:42:40 GMT

In article <317fdd$bvd@aurora.engr.LaTech.edu> ramos@engr.latech.edu (Alex Ramos) writes:
>Might some hd.c guru tell me a possible cause for the following errors?
>Here I was running 1.0.9:
>
>       Jul 20 02:27:18 crash kernel: HD: write_intr: status = 0x51
>       Jul 20 02:27:19 crash kernel: HD: write_intr: error = 0x04
>       [repeats 10 times]
>And here, 1.1.33:
>       Jul 27 01:24:41 crash kernel: HD: write_intr: status = 0x51
>       Jul 27 01:24:41 crash kernel: HD: write_intr: error = 0x04
>       [repeats 4 times]
>Both of these resulted in a filesystem crash with lockup.
[snip]
I have developed soft errors on my hdb, and the soft errors result in
file/file-system corruption. The problem, as far as I can tell, is
that the hd controller is garbaged after an error and the code in
the kernel is not clearing out the error condition. Debugging code
shows the buffers are all ok, and all the data structures are in line.

So the big question is: what is the right way to recover from hd errors?
I don't have the AT BIOS listings or IDE controller documentation on the
register level, so hopefully someone can point me to documentation or
give me a hand :-). 

So, if you find filesystem problems on your IDE partition, don't blame
Linus or Linux, check your syslog for HD write_intr errors. Getting one
of these can seriously hose a file/directory/partition. Let me know if
you find these problems and send some system info to

jweigand@astro.ocis.temple.edu
jwiegand@opus.eng.temple.edu   <-- preferred.

Hopefully, I can get the driver straightened out with your help. As soon
as the versions settle down, I can post some patches that will give more
informative error messages and/or debugging.

jim

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

From: stewart@hibp6.ecse.rpi.edu (Paul Stewart)
Subject: Re: Registrar for major device #s?
Date: 15 Aug 1994 05:28:39 GMT

Matthias Urlichs (urlichs@smurf.noris.de) wrote:
: In comp.os.linux.development, article <1994Aug12.212609.27300@dali.cti-software.nl>,
:   pim@dali.cti-software.nl (Pim Zandbergen) writes:
: > 
: > Might it be an idea to adopt the mdevice/sdevice scheme from
: > System V ? There, drivers need not know which major # they'll
: > get, yet they'll linke fine and all devices get created
: > automatically after a kernel rebuild.

: What for? We have /proc/devices and a nice MAKEDEV script which uses it.

: Offhand, I can't think of anything you're getting from the SysV ?devices
: stuff (which is rather difficult to understand) you can't get from MAKEDEV
: (which anybody with workable /bin/sh knowledge can analyze, if necessary).

Actually, I thought of this idea earlier today, and decided to just forget
about it, but let's give it a whirl.  I think that sticking with this scheme
(static device numbering) has its advantages, but it would be a major step
forward to have something paralleling the proc file system as a device 
structure.

Device drivers could, at init time, register themselves as a pathname in
/devices.  For example, the mt driver could identify itself as 
"/proc/devices/tape/mt", and then below that, it could register special files
for all the subdevices (perhaps only the ones physically available?), and
perhaps a few others like "info" and "debug".  This would be a good way
to hierchially place information, and a standardized way of getting more
in-depth information and debugging from the driver, instead of isolated
attempts like /dev/sndstat.

This could relegate special numbers persay to just a convenience in the
lower levels.  /dev/ could contain symbolic links to the /proc/device
pathnames, and user programs could easily find out about physical 
configuration, without explicitly poking at the kernel, or secret ioctl
handshakes.  This is a similar argument to that which brought us /proc
to begin with, I'd imagine.


The problem with just /proc/devices and MAKEDEV is that they are still
only addressing the major numbers.  Any minor device info like sndstat,
mixer, etc, that gets added needs to be manuallly updated in MAKEDEV.
In the case of the device filesystem, a new link from /dev/ may need to
be created, but that's about it.  mknod not necessary (however it's 
possible to support both schemes simultaneously).  Of course, this would
require all existing drivers to add a little code to create a request, 
and then an encouragement to add special devices that output status info,
and probably another for debug info...

Just my haphazard badly-thought-out $0.02..

--
Paul


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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: 1.1.43 won't link on my system
Reply-To: pe1chl@rabo.nl
Date: Sun, 14 Aug 1994 21:38:12 GMT

In <JOK.94Aug14204226@gamma.hut.fi> jok@snakemail.hut.fi (Jouni A Kosonen) writes:

>In article <dhdCuJ7FK.FKo@netcom.com> dhd@netcom.com (David H Dennis) writes:
>> I picked up version 1.1.43 (for some reason, 1.1.44 wasn't available) from
>> Sunsite and it compiled fine.  But when the make ran LD, I got the following
>> message:
>>
>> "ld: unrecognized option -qmagic"
>>
>> What did I do wrong?
>>
>> Thanks!

>You are doing the same mistake I am: using an old compiler (I use 2.4.5).
>Worry not, the answer is simple:
>- in your /usr/src/linux/Makefile, around lines 92 and 93, comment
>  out the LOWLDFLAGS and HIGHLDFLAGS - lines
>- around lines 87 and 88, uncomment the corresponding lines
>- enjoy

The problem is not in the compiler, but in the linker (ld)
You may want to upgrade it...  it is in the "binutils" package.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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


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