Linux-Development-Sys Digest #11, Volume #7 Fri, 30 Jul 99 15:13:51 EDT
Contents:
Re: SIGFPE delivery (Andi Kleen)
Re: Pre-emptiveness of Linux (Alexander Viro)
DVD-ROM Driver Project (ryan.tecco)
Re: Pre-emptiveness of Linux (Sami Tikka)
Re: Linux Journal - worth or not? (Keith Brown)
SCSI disk number limit?
Re: JFS for linux? (Andreas Dilger)
Re: drives mount in linux and dos-like OS's (Karl Heyes)
Re: Writing shared libraries (Karl Heyes)
"Unresolved Symbols" reported by depmod, though the module works fine. (Chris Jensen)
Re: Linux Journal - worth or not? (Mr Williams)
Re: Adaptec 7897 (or PERC2) driver? ([EMAIL PROTECTED])
Re: timer-create ("Robert H. de Vries")
Re: switching switchbox makes mouse go crazy: any fix? (David T. Blake)
----------------------------------------------------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: SIGFPE delivery
Date: 29 Jul 1999 21:56:16 +0200
[EMAIL PROTECTED] (David H. Munro) writes:
>
> I was told by Cygnus support that the new fenv.h interface replaces
> the __setfpucw functionality. I have read the C9X draft standard
> describing fenv.h very carefully, and it provides no means for setting
> the FPE mask bits -- you can use the fenv.h interface only to set,
> query, and test the bits which determine whether an exception
> condition has occurred. Numerical software requires that the FPU
> actually generate an interrupt; it doesn't do any good to know
> something happened long afterward. I also spoke with a Livermore
> representative on the C9X committee, who told me that delivery or
> non-delivery of any signal is not regarded as a C language issue (by
> way of an excuse for the fenv.h interface not providing this crucial
> functionality). Unless GNU libc extends the fenv.h interface, it is
> useless.
ISO C9x does not define the possible exception modi, but it has fesetenv()
and it says that the flags are implementation dependent. Thus glibc
has FE_INEXACT, FE_DIVBYZERO etc. Those can be tested for with ifdef
(if they are not defined the current architecture does not support them)
It sounds useless to reinvent your own functions when these glibc versions
already exist (with a good chance for portability too - perhaps other
C9x implementation will follow the glibc names - even if not it is still
much more easy to parametrize than with a custom function)
-Andi
--
This is like TV. I don't like TV.
------------------------------
From: [EMAIL PROTECTED] (Alexander Viro)
Subject: Re: Pre-emptiveness of Linux
Date: 30 Jul 1999 11:21:59 -0400
In article <[EMAIL PROTECTED]>,
Sami Tikka <[EMAIL PROTECTED]> wrote:
>On Wed, 28 Jul 1999 18:20:54 GMT, Viraj Alankar <[EMAIL PROTECTED]> wrote:
>> Next we were going to install Oracle 8i on the Linux machine. We
>>un-tarred the 100+meg file. Then for some reason we needed to remove the
>>directory that was untarred. So 'rm -rf' and put in the background.
>>Next, while the rm was going, we tried to remove another big tar file in
>>the foreground. That paused for awhile, and then we tried CTRL-Z to put
>>it in the background. What is strange that at this point it took about
>>10-15 seconds for it to even accept the CTRL-Z! It was like the system
>>was waiting for the original rm to finish with something (system call?)
>>before being able to pre-empt this rm process. This was all done on the
>>console.
Slowness with accepting ^Z (i.e. SIGTSTP) is not about the background
process - it's foreground one sitting in unlink(). Signals directed to
process do not preempt unlink(). That is, foreground process was pretty
busy. unlink() on Linux does (used to do, anyway) a lot of unneeded
work since it uses generic ->truncate() (in case when we are removing the
last link, nobody keeps the file open, etc.). It is overkill since
normal ->truncate() has to deal with situations when we have another
process(es) writing to the file. I.e. deal with races. In case of final
removal we are guaranteed that nobody else accesses the thing. Another
thing being that unlink may generate a lot of disk traffic and with IDE
it may be rather painful. Using larger blocks also helps big way - 4Kb blocks
give a lot of speedup.
>I think we are all familiar with this behaviour. I would also like to hear
>some knowledgeable person tell me what exactly is it that causes this.
>My guess is that the Linux scheduler is reluctant to switch a process doing
>disk I/O to another process doing disk I/O. The reasoning here could be that
>it will allow the first process to finish quicker than it would if another
>disk I/O bound process was allowed to run in between.
No. Nothing like that. It's not about scheduler.
[snip]
>> What's more, during all of this, the system is very slow. 'ps
>>aux' takes a few seconds to display, shell commands pause a bit too.
Check the interrupts rate (vmstat) and block IO rate. BTW, what version are
you using?
>My theory does not explain this. If I'm correct, this should not happen. "ps
>aux" does not access disk. At least not any real hardware.
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
------------------------------
From: [EMAIL PROTECTED] (ryan.tecco)
Subject: DVD-ROM Driver Project
Date: Fri, 30 Jul 1999 14:55:27 GMT
Hello all. I have started work on building a suite of software for using DVD-ROM
drivers under Linux. The suite would include a driver as well as a limited form
of a playback program. Help is definitely welcome, feel free to e-mail. I would
like to have the suite working for the release of 2.4, whenever that may be this
fall.
Take care.
rt
==============
ryan.tecco
734.476.6646
the university of michigan
"i'll never forget my life
as a carrot."
------------------------------
From: [EMAIL PROTECTED] (Sami Tikka)
Subject: Re: Pre-emptiveness of Linux
Date: Fri, 30 Jul 1999 00:59:23 +0300
Reply-To: [EMAIL PROTECTED]
On Wed, 28 Jul 1999 18:20:54 GMT, Viraj Alankar <[EMAIL PROTECTED]> wrote:
> Next we were going to install Oracle 8i on the Linux machine. We
>un-tarred the 100+meg file. Then for some reason we needed to remove the
>directory that was untarred. So 'rm -rf' and put in the background.
>Next, while the rm was going, we tried to remove another big tar file in
>the foreground. That paused for awhile, and then we tried CTRL-Z to put
>it in the background. What is strange that at this point it took about
>10-15 seconds for it to even accept the CTRL-Z! It was like the system
>was waiting for the original rm to finish with something (system call?)
>before being able to pre-empt this rm process. This was all done on the
>console.
I think we are all familiar with this behaviour. I would also like to hear
some knowledgeable person tell me what exactly is it that causes this.
My guess is that the Linux scheduler is reluctant to switch a process doing
disk I/O to another process doing disk I/O. The reasoning here could be that
it will allow the first process to finish quicker than it would if another
disk I/O bound process was allowed to run in between.
This scheme will maximise throughput. On the other hand it will affect
poorly to multiprocessing. On the other hand if you were running Linux on
your desktop, you are not probably doing very much multiprocessing (some but
not much). If you were running a login-server for a department of people, a
lot of people would be very angry when one of them decides to do something
very disk-intensive.
So my guess is that the Linux scheduler is tuned to be used in single-user
desktop systems. In short... to make compilations faster :)
> What's more, during all of this, the system is very slow. 'ps
>aux' takes a few seconds to display, shell commands pause a bit too.
My theory does not explain this. If I'm correct, this should not happen. "ps
aux" does not access disk. At least not any real hardware.
--
Sami Tikka, [EMAIL PROTECTED], http://www.iki.fi/sti/
"One World, One Web, One Program" - Microsoft Promotional Ad
"Ein Volk, Ein Reich, Ein Fuhrer" - Adolf Hitler
------------------------------
From: Keith Brown <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Linux Journal - worth or not?
Date: Fri, 30 Jul 1999 08:59:51 -0500
Bonn wrote:
>
> i started using linux for a while. is it worthwhile to subscribe the
> 'Linux Journal'?
> any comment?
Ditto what everyone else has said (definitely worth it). There is also
'Linux Magazine' which has been out for a few months (I've been lucky
enough to get all the issues on the newstand so far). I highly recommend
this as well, though it costs an arm and a leg to subscribe. I suppose
the price will come down if they become more successful and fixed costs
are less of the business equation.... http://www.linux-mag.com
--
_ _ ___ __ ________________________________
| | (_)_ _ _ ___ __ |_ ) / \ | Keith Brown [EMAIL PROTECTED] |\
| |__| | ' \ || \ \ / / / | () | | http://web.wt.net/~bahalana |\
|____|_|_||_\_,_/_\_\ /___(_)__/ |________________________________|\
THE SOURCE IS OUT THERE.... \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
------------------------------
From: <[EMAIL PROTECTED]>
Subject: SCSI disk number limit?
Date: 30 Jul 1999 16:20:07 GMT
I've got an interesting problem. I've got a number of SCSI drives that
I'm connecting to a system, but the system refuses to recognize disks past
sdg (i.e. the 7th scsi disk). I can use the disks in smaller numbers on
the secondary controller, but when I try to load up all six in it,
/proc/partitions stops at sdg1, even though the module load says that it
finds disks up to sdi, as expected. The primary controller is an aha2940
with three main system partitions on it. The secondary controller (with
the 6 disks) is an NCR53c825 card. One more thing of note is that when I
unload and reload the NCR module, it doesn't relinquish two of the sd
devices when the module loads (ie the 6 disks go from sdf-sdk the second
time instead of sdd-sdi. third time is sdh-sdm, etc).
Any ideas? There are enough entries in /dev, BTW
-Cory
------------------------------
From: [EMAIL PROTECTED] (Andreas Dilger)
Subject: Re: JFS for linux?
Date: 30 Jul 1999 16:28:56 GMT
In article <[EMAIL PROTECTED]>,
Stefan Opperskalski <[EMAIL PROTECTED]> wrote:
>does anybody know, where I can get informations on the JFS-project for
>linux?
There is an implementation of JFS which is mostly based on ext2 FS. I
don't know the URL offhand, but it can be found from the LVM home page at:
http://linux.msede.com/lvm/
Cheers, Andreas
--
Andreas Dilger University of Calgary \"If a man ate a pound of pasta and
Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \ cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert
------------------------------
From: Karl Heyes <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.setup
Subject: Re: drives mount in linux and dos-like OS's
Date: Tue, 27 Jul 1999 16:12:04 +0100
YamYam wrote:
> Hi...
>
> I want to ask about the difference in mount/umount the drivers in
>
> linux 'is it necessary, if so why?' and the easy one in Dos-like
>
> OS's 'e.g., Win95, Win98, ...'.
>
> I found it very complicated for the Dos-like users to switch to linux at
>
> this point. Is there any suggessions to make easy for that user, such as
>
> writing a script to mount/umount the floppy and cdrom?
>
The big problem here is the manual mechanical eject button, namely on floppy
drives. This can make a mess of caching, linux caches much better than
windows.
You can do three things :-
Use supermount, (a utility I've not touched myself),
Adding "noauto,user" into /etc/fstab as options, ok but the user has to
manually
specify the mount, unmount commands explicity, an extra bit of education
really
but doesn't distinguish between users.
autofs. automatically mount/unmount filesystems on the fly. Something on
par
with DOS drive letters. For the floppy drive you will probably want a short
timeout (1s) whilst other filesystems have larger timeouts (default 60s).
I personnally use the autofs mechanisms myself.
eg
/misc/removeable - one autofs mount point for floppy cdrom
/misc/fixed - another for NFS/hard disks
/mnt/cdrom - symlink to /misc/removeable/ide-cd
/mnt/floppy - symlink to /misc/removeable/dosfloppy
The symlinks are there because the dosfloppy and ide-cd directories don't
appear
until they are used. Obviously if the floppy disk is ejected whilst an
application is
in the dosfloppy directory then odd things can happen (but then the ground
on which
you stand has disappeared!). With the cdrom the drive is locked and the
eject button
is electronic and will be ignored until it has been released.
You are right in that, it would be nice if the distributions have this
setup, ease of
installation but things are progressing, there are a few things that could
be improved
upon. eg would it correct for the autofs to kill the program accessing an
ejected disk
or for the application to handle the error condition when there's a program
with reading
and/or writing to the disk. Bear in mind the ejected disk is only one
case, an NFS
server may not be reachable..etc!.
On a side note, I think linux 2.2 handles these cases better than 2.0.
karl.
------------------------------
From: Karl Heyes <[EMAIL PROTECTED]>
Subject: Re: Writing shared libraries
Date: Tue, 27 Jul 1999 16:59:38 +0100
Kevin Woodward wrote:
> Thanks. From that I assume libx.a is a.out format and libx.so is for
> ELF?
>
>
No. libx.a is static whilst libx.so is shared. try
file libx.a
file libx.so
a.out was the original executable format, now superceeded by ELF
karl.
------------------------------
From: Chris Jensen <[EMAIL PROTECTED]>
Subject: "Unresolved Symbols" reported by depmod, though the module works fine.
Date: Fri, 30 Jul 1999 09:13:54 -0800
I recently finished my first linux driver/module and it
works fine. I'm currently working on the
automated loading/installing side of it. Playing around, I
put it in /lib/modules/preferred/misc and ran "depmod -a
-e". It then says my module has unresolved symbols and
spews out all of the kernel calls that my module makes (i.e.
printk(), free_irq(), jiffies, etc.). No other module in
the system has any unresolved symbols, though they obviously
make calls to the kernel, so what did I do wrong? Is there
something during link/compile that I should do, or is there
a file I need to edit? It's kind of perplexing, obviously
they are unresolved, they are only resolved once you run
insmod to load the module, but apparently I am missing
something, because my module is the only one getting these
"errors". Any help would be greatly appreciated.
Chris Jensen
[EMAIL PROTECTED]
* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!
------------------------------
From: Mr Williams <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Linux Journal - worth or not?
Date: Fri, 30 Jul 1999 13:06:26 +0600
Bonn wrote:
>
> i started using linux for a while. is it worthwhile to subscribe the
> 'Linux Journal'?
None of these magazines is worth subscribing to. These are ads catalogs
with some questionable-usefulness bs attached. Peruse them in a store,
and if you find an issue that interests you, buy this issue.
--
len
if you must email, reply to:
len bel at world net dot att dot net (no spaces, ats2@, dots2.)
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Adaptec 7897 (or PERC2) driver?
Date: 30 Jul 1999 15:28:30 GMT
bill davidsen <[EMAIL PROTECTED]> wrote:
: I just got a new Linux box from Dell, and while I'm waiting for them to
: get back to me I'll ask here. Has anyone done a driver for the RAID
: controller they use? The box is otherwise a nice little server,
: 2xXeon-500, 1GB RAM, 210GB disk, but if I can't run Linux it does me no
: good.
: I asked if this would run Linux before I ordered, the answer does not
: appear to have been correct:-(
We have some of these big Dells (4 Xeon processors,
1 GB RAM, PERC controller). Linux works very well
on them, needless to say. The PERC controller is
a rebranded AMI MegaRAID. It's a piece of junk. Throw
it away and use software RAID and you'll get at
least 5 times the performance. However, if you really
must use it, there is a Linux driver for it in
the standard kernel.
Rich.
--
[EMAIL PROTECTED] | Free email for life at: http://www.postmaster.co.uk/
BiblioTech Ltd, Unit 2 Piper Centre, 50 Carnwath Road, London, SW6 3EG.
+44 171 384 6917 | Click here to play XRacer: http://xracer.annexia.org/
--- Original message content Copyright � 1999 Richard Jones ---
------------------------------
From: "Robert H. de Vries" <[EMAIL PROTECTED]>
Subject: Re: timer-create
Date: Fri, 30 Jul 1999 19:12:07 +0200
==============8134D9A39B227AEF974449D7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
[EMAIL PROTECTED] wrote:
> Hi,
>
> Anyone know of a linux system call which can create a new timer based on
> a specified clock_id? On the SunOS one can use timer_create(). I'd
> suspect it to be found in time.h but I can't seem to find anything.
> Anyhow, if anybody can be of any help I'd appreciate it.
>
>
I am currently trying to get a patch implementing the posix timers (and
clocks) in the latest development kernel (2.3.12).
You can get the patch from http://www.rhdv.cistron.nl/
Have fun,
Robert
--
Robert de Vries
[EMAIL PROTECTED]
==============8134D9A39B227AEF974449D7
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
[EMAIL PROTECTED] wrote:
<blockquote TYPE=CITE>Hi,
<p>Anyone know of a linux system call which can create a new timer based
on
<br>a specified clock_id? On the SunOS one can use timer_create().
I'd
<br>suspect it to be found in time.h but I can't seem to find anything.
<br>Anyhow, if anybody can be of any help I'd appreciate it.
<br>
<br> </blockquote>
I am currently trying to get a patch implementing the posix timers (and
clocks) in the latest development kernel (2.3.12).
<p>You can get the patch from <A
HREF="http://www.rhdv.cistron.nl/">http://www.rhdv.cistron.nl/</A>
<p> Have fun,
<p> Robert
<br>
<pre>--
Robert de Vries
[EMAIL PROTECTED]</pre>
</html>
==============8134D9A39B227AEF974449D7==
------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Subject: Re: switching switchbox makes mouse go crazy: any fix?
Date: 29 Jul 1999 21:35:35 GMT
Reply-To: [EMAIL PROTECTED]
tom bergerson <[EMAIL PROTECTED]> wrote:
> the problem is similar to the 04/99 post about killing the mouse.
Try ClearDTR or ClearRTS
or ,
echo "*n" > /dev/mouse
Or, read /usr/doc/HOWTO/mini/3-Button-Mouse
and man gpm and man XF86Config.
Hope there is help in there for you somewhere.
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
** 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: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
