From: owner-linux-kernel-digest@vger.rutgers.edu
Received: from vger.rutgers.edu by eole.ERE.UMontreal.CA (950221.405.SGI.8.6.10/5.17)
id VAA28021; Thu, 20 Jul 1995 21:50:12 -0400
Received: (from majordomo@localhost) by vger.rutgers.edu (8.6.12/8.6.12) id EAA24860 for linux-kernel-digest-outgoing; Wed, 19 Jul 1995 04:44:21 -0400
Date: Wed, 19 Jul 1995 04:44:21 -0400
Message-Id: <199507190844.EAA24860@vger.rutgers.edu>
To: linux-kernel-digest@vger.rutgers.edu
Subject: linux-kernel-digest V1 #121
Reply-To: linux-kernel@vger.rutgers.edu
Errors-To: owner-linux-kernel-digest@vger.rutgers.edu
Precedence: bulk
linux-kernel-digest Wednesday, 19 July 1995 Volume 01 : Number 121
----------------------------------------------------------------------
From: Albert Cahalan <albert@ccs.neu.edu>
Date: Tue, 18 Jul 1995 00:51:02 -0400
Subject: Kernel loadable modules
I'd like to use .klm or .km as a module extension instead of .o
------------------------------
From: Jim Lynch <jimlynch@netcom.com>
Date: Mon, 17 Jul 1995 22:18:32 -0700 (PDT)
Subject: Re: using "core" as directory name
My feeling is also that the dir named "core" ought to be changed. What
happens if the system tries to produce a core file just outside the core
dir?
By all means, change the dir name: it's an honest mistake to initially
make such a naming goof, but it would be highly stupid not to correct it
now.
- -Jim Lynch aka enOne (jimlynch@netcom.com)
------------------------------
From: iialan@iifeak.swan.ac.uk (Alan Cox)
Date: Tue, 18 Jul 1995 09:16:48 +0100 (BST)
Subject: Re: linux-kernel-digest V1 #118
> From: Albert Cahalan <albert@ccs.neu.edu>
> Date: Sun, 16 Jul 1995 12:57:13 -0400
> Subject: Serial driver
>
> > I'm in the (ugly) process of porting the x86 serial driver
> > to the 680x0 version of Linux. (I'm working on a prototype ISA->Zorro
> > board). Aside from the obvious problem, that x86 linux hasn't yet
> > incorportated the mach-ind extensions found in 1.2pl1 (680x0),
> > I'm wondering if there is a way to get rid of the static rs_table
> > arrays, which probably take up a decent chunk of memory.
>
> Perhaps you should write a 680x0-only driver.
No the rs_table is a silly piece of bloat (about 10K). I already take all
the spare slots out of kernels I build for 4Mb machines.. thats two more
precious pages of memory saved.
> You can use that driver for a PC (x86 or Alpha), but I think it might
> be easier to write from scratch for 680x0 hardware. You don't even
> use the same UARTs, do you?
Depends on the boards.
Alan
------------------------------
From: Linus Torvalds <Linus.Torvalds@cs.Helsinki.FI>
Date: Tue, 18 Jul 1995 08:54:05 +0300
Subject: Re: splx()
Greg Wolodkin: "splx()" (Jul 17, 12:44):
> Hiya. I'm working on a linux port of a BSD-based MIDI driver, and
> I'm looking for a function splx() so that I can block interrupts and
> then later restore them to whatever the state was before I blocked.
_please_ don't use splx(): it's not a very good interface for any
reason. I despise the stupid interface, all the more because it has
resulted in bad things for hardware as well..
[ Preacher mode on: this isn't specifically to Greg, but is just
something I feel very strongly about: ]
I say this every once in a while: spl-levels are BAD. There is _no_
good reason to use prioritized interrupts. Only broken hardware uses
them, and the right way to handle interrupts is with a bit-mask, not
with a priority. Look at the linux low-level interrupt handling
routines to see how this is done (<asm-i386/irq.h>).
For things that want to be atomic, it's easier to just disable all
interrupts, and do whatever you want to do quickly. If you're doing
something that is so slow that you don't want to disable all interrupts,
you're doing something wrong, and spl-levels wouldn't be the solution to
this problem anyway.
(slow things that need lots of locking are more appropriately handled by
software interrupts, the linux "bottom half handlers". They can be
blocked individually without blocking any hardware interrupts at all,
and they have much nicer atomicity guarantees anyway. This is how the
slow and race-prone tty and network processing is done).
> int splx (int new_level) {
> register int old_level, tmp;
>
> save_flags(tmp);
> old_level = (tmp & 0x200) ? 7 : 0;
> if (new_level)
> sti();
> else
> cli();
> return old_level;
> }
>
> The file it was in was apparently splx.c.
This is very much i386-specific and won't work on anything else. Please
don't use this.
> At any rate I couldn't find this function in the new 1.2.x, 1.3.x kernels.
> For now I've just added it to the driver module and it seems to work fine,
> but I thought I'd ask to see why it had disappeared, and also to see if
> there isn't a better/cleaner solution already existing in the 1.2.x kernel.
What's wrong with:
unsigned long flags;
save_flags(flags); /* old "spl-level" for BSD people */
cli(); /* disable all interrupts */
...
restore_flags(flags); /* restore old "spl-level" */
which does the same thing, except
- you aren't fooled into thinking that "spl's are ok - we're just
blocking part of the interrupts".
- it's more flexible (you can save the flags just once, and then do any
amount of cli()/restore_flags(): see "serial.c" for an example of this)
- it's the way everything else in the kernel does it.
If you need to have the same source-tree for both BSD and linux, I'd
suggest something like
#ifdef __linux__
#define disable_irq() ({ unsigned long flags; save_flags(flags); cli(); flags; })
#define restore_irq(x) restore_flags(x)
#else
#define disable_irq() splx(7)
#define restore_irq(x) splx(x)
#endif
and then you use
old = disable_irq();
...
restore_irq(old)
which is actually more readable than either format, but loses (very
little - it's seldom used) of the flexibility of the linux format.
Linus
------------------------------
From: "Leonard N. Zubkoff" <lnz@dandelion.com>
Date: Tue, 18 Jul 1995 01:22:28 -0700
Subject: Re: Fragments in Ext2 fs
Cc: "Leonard N. Zubkoff" <lnz@dandelion.com>
Date: Mon, 17 Jul 1995 21:59:17 -0500
From: "Michael K. Johnson" <johnsonm@nigel.vnet.net>
Have you checked to make sure that the clustering is really working
in the 1K cases? Larry McVoy told me some time ago when I talked to
him about this subject that he had added a system call to use to
check to see if any clustering was happening, and he didn't see a
single instance of it actually happening.
Hmmm. I must admit that I just assumed that the clustering patches were doing
their job as they've been in the kernel for quite a long time now. I'll have
to read over the clustering code enough to understand how it works and run some
further tests.
I seem to recall that benchmarks made in the early days of the clustering
patches made against 4KB blocks that were virtually indistinguishable
from those made with 1KB blocks. Since this doesn't agree with your
benchmarks, it seems that before thinking too hard about adding fragments,
it would be worth seeing if the buffer cache needs any tuning to take
better advantage of clustering.
Agreed. I would much prefer to stay with 1K blocks if the same or nearly the
same performance can be achieved with them. However, I vaguely recall that the
clustering code wasn't supposed to matter that much if the SCSI driver
supported reasonable scatter/gather operations, and that's certainly the case
with the tests I reported on.
Leonard
------------------------------
From: andrew@zycad.com (Andrew Pollard)
Date: Tue, 18 Jul 95 10:53:06 BST
Subject: Re: linux-kernel-digest V1 #118
Hello,
On Sun, 16 Jul 95 19:31:10 BST I wrote:
>PS. I haven't received a kernel digest for about 10 days now.. Has something
>gone horribly wrong? Someone please mail me if they see this.
They are now coming thick and fast again :-)
PS. Thanks to everyone who replied...
Andrew.
===============================================================================
| Andrew Pollard, Zycad RP Division (InCA) UK | Work: andrew@zycad.com |
| Tel:+44(0)1344 51515 Fax:+44(0)1344 421231 | Home: Andrew@odie.demon.co.uk |
===============================================================================
------------------------------
From: P.B.Schuller@WI.LeidenUniv.NL (Bart Schuller)
Date: Tue, 18 Jul 1995 12:34:20 +0200 (MET DST)
Subject: Re: [doughera@lafcol.lafayette.edu: Re: Perl 5.001/Linux ELF pipe.t error test 7]
> On Mon, 17 Jul 1995, Frank Bennett wrote:
> > I've just compiled Perl 5.001 under Linux 1.3.8, using GCC 2.7.0
> > and version 5.0.9 of libc.
> >
> > The compilation went smoothly, but I get one failed test, the 7th
> > test in pipe.t. (It looks like maybe this tests whether Perl will
> > be able to provide error handling for a broken pipe condition
> > (?).)
>
> The problem is (apparently) that Linux uses more than one signal name for
> a specific signal number. I don't know if this is just for the 1.3.x
> series of kernels or not, but it appears to be a recent change. I'm also
No it isn't. I already reported this to perl5-porters.
The problem is that the signal names are defined in a different include
file since somewhere in the 1.3.x kernel series.
The fix is to change a bit of the perl Configure script to read
echo "Generating a list of signal names..." >&4
xxx=`./findhdr signal.h`" "`./findhdr sys/signal.h`
xxx="$xxx "`./findhdr linux/signal.h`" "`./findhdr asm/signal.h`
^^^^^^^^^^^^^^^^^^^^^^^^^^
this is new
- --
Bart talk: schuller@acme.wi.leidenuniv.nl
Schuller WWW: http://www.wi.leidenuniv.nl/~schuller/
------------------------------
From: linux@pe1chl.ampr.org (Rob Janssen reading Linux mailinglist)
Date: Tue, 18 Jul 1995 09:18:15 +0200 (MET DST)
Subject: Re: linux-kernel-digest V1 #118
According to owner-linux-kernel-digest@vger.rutgers.edu:
> From: Scott Johnson <johnsos@ECE.ORST.EDU>
> Date: Sun, 16 Jul 1995 15:56:39 -0700
> Subject: Re: rmdir hangs on bad ext2 directory (1.2.11)
>
> I've been having a similar problem (rather rarely) on my system as well. I've
> got 1.2.10 running, and my entire Linux filesystem is mounted on a single
> partition (about 200 Mbytes, I've considered repartitioning to give Linux
> more, and OS/2 Warp less space, but thats another story.) The drive is a WD
> 540 "Caviar" drive, (the device is /dev/hdb5, in case that matters). Every
> once in a while, some process will try to access the /var/adm directory, and
> for some reason die (enter uninterruptable sleep). When this happens, the
> HD makes a strange noise, similar to being powered up for the first time. (My
> PC is a desktop, so the HD should not be spinning down for any reason...) It
> may be hardware trouble, it may be something Linux is doing, I dunno. At any
> rate, ANY process which tries to access this directory (/var/adm) gets put to
> sleep. syslogd is usually the first to die, but init soon follows. Any
> process which terminates after, instead of dying gracefully, becomes a
> zombie. And
> shutting down properly with a hung init process is a pain... :) I end up having
> to give the computer the One Fingered Salute (shutdown hangs when trying to
> kill off these hung processes), and pray when I reboot and run fsck.
Resilience to disk errors certainly isn't Linux's best point...
I while ago I had some bad sectors on my SCSI disk (which does not have
automatic re-allocation of those bad sectors), and it was quite difficult
to recover from that. Fortunately I had good backups.
Indeed, as you describe, any process that hits a bad sector is put in
an uninterruptable sleep and cannot be killed. This causes attempts to
shutdown to fail, and hence results in filesystem damage that would not
have been necessary.
I think a process that suffers a disk error should get back an error code
or a signal, so that it can decide itself how to handle the error. Given
the fact that no software seems to bother to check returncodes, it is
probably best to use a signal (in addition to returning an error).
The complicated path of critical errors (via a user process "syslogd")
does not help either. As you describe, that process easily can get stuck
and you have no display of errors anymore.
(it is worst when using X, because you can't see the messages that are
written directly to the console screen until you exit X, which is of course
impossible without locking up the entire system)
It would be nice if you could get the messages printed on a fixed device
directly by the kernel, so that you could send them to the first console
(instead of the current one), to a terminal on a serial port, to a
printer, etc. That would make them less dependent on complex stuff like
syslogd and X.
Rob
- --
+------------------------------------+--------------------------------------+
| Rob Janssen rob@knoware.nl | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@wab-tis.rabobank.nl | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+------------------------------------+--------------------------------------+
------------------------------
From: iwj10@cus.cam.ac.uk (Ian Jackson)
Date: Tue, 18 Jul 95 02:43 BST
Subject: Re: 1.2.11 and 1.3.2+ breaks ps
Marek Michalkiewicz writes ("1.2.11 and 1.3.2+ breaks ps"):
> It is good that 1.2.11 fixes /proc security problems. But many people
> don't like another change made in this version as well as in 1.3.2.
> In previous versions (up to 1.2.10 and 1.3.1) ps always displayed the
> effective uid of the process. Now it displays the real uid.
There is a good reason for this change: it makes pidentd work
correctly for rsh connections. Otherwise pidentd would always return
`root'.
> This trivial change causes ps to show ftpd running as root (since it
> has real uid 0). I'm not sure if everyone will like it. I think in
> 1.2.xx we should keep things working the way they always did, and only
> make changes which are necessary to fix bugs.
It seems to me that the real fixes are one or both of:
* Add an extra euid field to /proc/<nnn>/stat and let ps display it
(optionally perhaps)
* Change ftpd to use saved-setuid rather than setting its real uid
to 0. For this we really need setresuid, which Linux doesn't have.
Ian.
------------------------------
From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
Date: Tue, 18 Jul 1995 16:44:07 +0200 (MET DST)
Subject: Re: 1.2.11 and 1.3.2+ breaks ps
Ian Jackson:
> Marek Michalkiewicz writes ("1.2.11 and 1.3.2+ breaks ps"):
> > It is good that 1.2.11 fixes /proc security problems. But many people
> > don't like another change made in this version as well as in 1.3.2.
> > In previous versions (up to 1.2.10 and 1.3.1) ps always displayed the
> > effective uid of the process. Now it displays the real uid.
>
> There is a good reason for this change: it makes pidentd work
> correctly for rsh connections. Otherwise pidentd would always return
> `root'.
[...]
> It seems to me that the real fixes are one or both of:
> * Add an extra euid field to /proc/<nnn>/stat and let ps display it
> (optionally perhaps)
> * Change ftpd to use saved-setuid rather than setting its real uid
> to 0. For this we really need setresuid, which Linux doesn't have.
Thanks for explaining this. But, at least on SunOS and SCO, ps shows the
effective uid (tested by logging in via ftp to my account; assuming that
their ftpd works the same way as wu-ftpd on Linux). Maybe pidentd should
be changed to read the real uid (from the extra /proc/<nnn>/stat field)
instead?
SunOS and SCO don't seem to have setresuid (at least no man pages), I don't
have access to anything else. What systems have setresuid? I guess this
would not be very portable...
Marek
------------------------------
From: Andreas Koppenhoefer <koppenas@koppenas.informatik.uni-stuttgart.de>
Date: Tue, 18 Jul 1995 14:29:54 +0200 (MET DST)
Subject: Re: Running headless
- -----BEGIN PGP SIGNED MESSAGE-----
> > - linux cannot redirect console to serial line, yet. But there are
> > some hooks which make that possible. In linux/drivers/char/console.c
> > you can find a call
> > register_console(console_print);
> > which registers system console as output channel for printk's.
>
> I saw this when I was looking around recently. It would be good to be
> able have /dev/tty1 go to /dev/cua0 as well; this would make init and
> the /bin/login in /etc/rc.d/rc.M (slackware) work with the serial port
> with no other changes. Where is it written that the terminal that
> /etc/rc.d/* gets is tty1?
There is no need in pointing /dev/ttyX to /dev/cuaX! The behaviour of
login and getty is defined via init process and /etc/inittab (which is
in user space). /dev/ttyX is the physical device of your console while
/dev/cuaX is that of the serial lines.
What we need is a kernel function which is capable of redirecting
printk's text output to serial device. And this function must be
registered with register_console(serial_print). Just implenent
serial_print() and you're finished.
> I'm surprised that noone has written this before. It seems such a
> useful thing to have. I would, but I don't have the time (who does!).
I'm surprised, too. Maybe there are some functions in serial driver
which can be used for that?
Andreas
- - --
Andreas Koppenhoefer, Student der Universitaet Stuttgart, BR Deutschland
prefered languages: German, English, C, perl ("Just another Perl hacker,")
SMTP: koppenas@informatik.uni-stuttgart.de (university address)
Andreas.Koppenhoefer@studbox.uni-stuttgart.de (my home address)
privat: Belaustr. 5/3, D-70195 Stuttgart, Germany,
Earth, Sector ZZ9 plural Z alpha
phone: +49 711 694111 and +49 711 6999006 (19-22h MEZ=GMT+1)
- -----BEGIN PGP SIGNATURE-----
Version: 2.6
iQBVAgUBMAupKUVdjNvyndGpAQGwhAH9EhFv35SK6cl8XYJ+LpCWne0bKzU9YEzy
q3rJEgOL735aItxjMR5I2Spl/22K1ubBBfuTdS0SlagLX6eZqftmqg==
=WatO
- -----END PGP SIGNATURE-----
------------------------------
From: "E.J. Wilburn" <ej@ns1.woodtech.com>
Date: Mon, 17 Jul 1995 23:26:43 -0500 (CDT)
Subject: PPP Idle-time
I'm trying to get PPP to change the idletime reported by the program w to
reflect when it sent or recieved the last packet instead of when the
program was run. To do this I need to have the kernel touch the device
being used by the spefic ppp channel. I'm thinking I need to find the
exact place in the kernel were ppp<channel> recieves or transmits a
packet and add a line like this -
utime(stdout, buftime);
Am I on the right track? Would this signifigantly slow down the kernel
or would it just be an unnoticable increase? Currently I'm running a max
of 27 PPP channels and average about 20. Also where could I find where
a specfic PPP channel inputs or outputs a packet? I'm running 1.2.11 on
that particular system.
- -E.J. Wilburn
System Administrator - Woodtech Information Systems, Inc.
ej@woodtech.com
------------------------------
From: "mark (m.s.) lord" <mlord@bnr.ca>
Date: Tue, 18 Jul 1995 11:15:00 -0400
Subject: fw:phantom ide drives with 1.3.9
>The 2 drives are detected as usual, but things get weird when it checks
>the partition table. (No, no DOS or DM on this machine.)
>
>hda: WDC AP4200, 202MB w/64KB Cache, CHS=987/12/35, MaxMult=16
>hdb: Conner Peripherals 40MB - CP3044, 40MB w/8KB Cache, CHS=980/5/17, MaxMult=16
>ide0: primary interface on irq 14
>
>[...]
>
>Partition check:
> hda: hda1 hda2 hda3 hda4
> hdb: hdb1
> hda: hda1 hda2 hda3 hda4 <-- bogus
> hda: hda1 hda2 hda3 hda4 <-- bogus
...
>VFS: Root device 3/2: prepare for armageddon.
>VFS: Inode busy on removed device 3/2 (get eight of these)
Mmmm.. looks like your "hda" drive identified itself as
a "removeable" disk system (like a SYQUEST).
>It seems to operate normally even with the the above scare tactics.
Yup. No worries there.. even safer than normal.
I'll eventually add an update of some sort to eliminate the "scares".
Thanks!
- -ml
------------------------------
From: Linus Torvalds <Linus.Torvalds@cs.Helsinki.FI>
Date: Tue, 18 Jul 1995 18:26:07 +0300
Subject: Task switch timing tests?
Hi,
I just made 1.3.11 available on the normal ftp-sites (ftp.funet.fi and
ftp.cs.helsinki.fi). I also have an experimental patch to go on top of
that, and I'd like to know if it (a) works and (b) speeds up
task-switching. Does anybody want to test this out (the byte pipe
benchmarks should show the effects if any, and there are other purely
context-switch sensitive benchmarks as well)?
(I am actually using this patch on my own system, so it _should_ work ok
for others too. I just don't have anything good to test context
switches with).
A plain 1.3.11 kernel will only make a rather small difference (the
scheduling is cleaned up, but not much optimized), so the real
difference should show up if you apply the accompanying patch on top of
the 1.3.11 kernel (you get a kernel that says "1.3.12", but it isn't,
really).
Linus
- ----------
diff -u --recursive --new-file v1.3.11/linux/Makefile linux/Makefile
- --- v1.3.11/linux/Makefile Tue Jul 18 16:28:55 1995
+++ linux/Makefile Tue Jul 18 16:29:38 1995
@@ -1,6 +1,6 @@
VERSION = 1
PATCHLEVEL = 3
- -SUBLEVEL = 11
+SUBLEVEL = 12
ARCH = i386
Binary files v1.3.11/linux/drivers/scsi/aic7770 and linux/drivers/scsi/aic7770 differ
diff -u --recursive --new-file v1.3.11/linux/kernel/fork.c linux/kernel/fork.c
- --- v1.3.11/linux/kernel/fork.c Tue Jul 18 16:28:59 1995
+++ linux/kernel/fork.c Tue Jul 18 17:15:38 1995
@@ -192,6 +192,8 @@
p->state = TASK_UNINTERRUPTIBLE;
p->flags &= ~(PF_PTRACED|PF_TRACESYS);
p->pid = last_pid;
+ p->next_run = NULL;
+ p->prev_run = NULL;
p->p_pptr = p->p_opptr = current;
p->p_cptr = NULL;
p->signal = 0;
diff -u --recursive --new-file v1.3.11/linux/kernel/sched.c linux/kernel/sched.c
- --- v1.3.11/linux/kernel/sched.c Tue Jul 18 16:28:59 1995
+++ linux/kernel/sched.c Tue Jul 18 17:56:31 1995
@@ -92,32 +92,77 @@
struct kernel_stat kstat = { 0 };
+static inline void add_to_runqueue(struct task_struct * p)
+{
+#if 1 /* sanity tests */
+ if (p->next_run || p->prev_run) {
+ printk("task already on run-queue\n");
+ return;
+ }
+#endif
+ if (p->counter > current->counter + 3)
+ need_resched = 1;
+ nr_running++;
+ (p->next_run = init_task.next_run)->prev_run = p;
+ p->prev_run = &init_task;
+ init_task.next_run = p;
+}
+
+static inline void del_from_runqueue(struct task_struct * p)
+{
+ struct task_struct *next = p->next_run;
+ struct task_struct *prev = p->prev_run;
+
+#if 1 /* sanity tests */
+ if (!next || !prev) {
+ printk("task not on run-queue\n");
+ return;
+ }
+#endif
+ if (p == &init_task) {
+ printk("idle task may not sleep\n");
+ return;
+ }
+ nr_running--;
+ next->prev_run = prev;
+ prev->next_run = next;
+ p->next_run = NULL;
+ p->prev_run = NULL;
+}
+
/*
* Wake up a process. Put it on the run-queue if it's not
* already there. The "current" process is always on the
- - * run-queue, and as such you're allowed to do the simpler
+ * run-queue (except when the actual re-schedule is in
+ * progress), and as such you're allowed to do the simpler
* "current->state = TASK_RUNNING" to mark yourself runnable
* without the overhead of this.
- - *
- - * (actually, the run-queue isn't implemented yet, so this
- - * function is mostly a dummy one)
*/
inline void wake_up_process(struct task_struct * p)
{
- - long oldstate;
+ unsigned long flags;
- - oldstate = xchg(&p->state, TASK_RUNNING);
- - /* already on run-queue? */
- - if (oldstate == TASK_RUNNING || p == current)
- - return;
- - if (p->counter > current->counter + 3)
- - need_resched = 1;
+ save_flags(flags);
+ cli();
+ p->state = TASK_RUNNING;
+ if (!p->next_run)
+ add_to_runqueue(p);
+ restore_flags(flags);
+}
+
+static void process_timeout(unsigned long __data)
+{
+ struct task_struct * p = (struct task_struct *) __data;
+
+ p->timeout = 0;
+ wake_up_process(p);
}
/*
* 'schedule()' is the scheduler function. It's a very simple and nice
* scheduler: it's not perfect, but certainly works for most things.
- - * The one thing you might take a look at is the signal-handler code here.
+ *
+ * The goto is "interesting".
*
* NOTE!! Task 0 is the 'idle' task, which gets called when no other
* tasks can run. It can not be killed, and it cannot sleep. The 'state'
@@ -128,6 +173,7 @@
int c;
struct task_struct * p;
struct task_struct * next;
+ unsigned long timeout = 0;
/* check alarm, wake up any interruptible tasks that have got a signal */
@@ -137,31 +183,39 @@
}
run_task_queue(&tq_scheduler);
- - if (current->state == TASK_INTERRUPTIBLE) {
- - if (current->signal & ~current->blocked)
- - current->state = TASK_RUNNING;
- - }
need_resched = 0;
- - nr_running = 0;
+ cli();
+ switch (current->state) {
+ case TASK_INTERRUPTIBLE:
+ if (current->signal & ~current->blocked)
+ goto makerunnable;
+ timeout = current->timeout;
+ if (timeout && (timeout <= jiffies)) {
+ current->timeout = 0;
+ timeout = 0;
+ makerunnable:
+ current->state = TASK_RUNNING;
+ break;
+ }
+ default:
+ del_from_runqueue(current);
+ case TASK_RUNNING:
+ }
+ p = init_task.next_run;
+ sti();
+/*
+ * Note! there may appear new tasks on the run-queue during this, as
+ * interrupts are enabled. However, they will be put on front of the
+ * list, so our list starting at "p" is essentially fixed.
+ */
/* this is the scheduler proper: */
c = -1000;
next = &init_task;
- - for_each_task(p) {
- - switch (p->state) {
- - case TASK_INTERRUPTIBLE:
- - if (!p->timeout)
- - continue;
- - if (p->timeout > jiffies)
- - continue;
- - p->timeout = 0;
- - p->state = TASK_RUNNING;
- - /* fall through */
- - case TASK_RUNNING:
- - nr_running++;
- - if (p->counter > c)
- - c = p->counter, next = p;
- - }
+ while (p != &init_task) {
+ if (p->counter > c)
+ c = p->counter, next = p;
+ p = p->next_run;
}
/* if all runnable processes have "counter == 0", re-calculate counters */
@@ -169,10 +223,21 @@
for_each_task(p)
p->counter = (p->counter >> 1) + p->priority;
}
- - if (current == next)
- - return;
- - kstat.context_swtch++;
- - switch_to(next);
+ if (current != next) {
+ struct timer_list timer;
+
+ kstat.context_swtch++;
+ if (timeout) {
+ init_timer(&timer);
+ timer.expires = timeout - jiffies;
+ timer.data = (unsigned long) current;
+ timer.function = process_timeout;
+ add_timer(&timer);
+ }
+ switch_to(next);
+ if (timeout)
+ del_timer(&timer);
+ }
}
asmlinkage int sys_pause(void)
- ----------
------------------------------
From: Andreas Koppenhoefer <koppenas@koppenas.informatik.uni-stuttgart.de>
Date: Tue, 18 Jul 1995 17:53:23 +0200 (MET DST)
Subject: Re: [doughera@lafcol.lafayette.edu: Re: Perl 5.001/Linux ELF pipe.t error
A fix/workaround for this was sent to Larry Wall (12 Jun 95) and Andy
Doughera (10 Jun 95). I don't know whether my fixes are included in
the newest set of perl patches or not.
> Subject: [doughera@lafcol.lafayette.edu: Re: Perl 5.001/Linux ELF pipe.t error test 7]
>
> > The subject line says most of it. I hope this is not an
> > intrusion; I am a novice at C, and can't offer a solution to the
> > problem that I've come across.
> >
> > I've just compiled Perl 5.001 under Linux 1.3.8, using GCC 2.7.0
> > and version 5.0.9 of libc.
> >
> > The compilation went smoothly, but I get one failed test, the 7th
> > test in pipe.t. (It looks like maybe this tests whether Perl will
> > be able to provide error handling for a broken pipe condition
> > (?).)
>
> The problem is (apparently) that Linux uses more than one signal name for
> a specific signal number. I don't know if this is just for the 1.3.x
> series of kernels or not, but it appears to be a recent change. I'm also
> not sure if this will continue to be the case for new kernels or if it will
> go away, so I don't know if it's worth it to work hard in Configure &
> perl to compensate.
>
> For now, I'm not certain offhand if there's a graceful way to handle this
> in perl itself, though it seems there ought to be.
>
> Anyway, you can just change manually change the names in config.sh (e.g.
> change IOT to ABRT) and to compensate for whatever duplicates are in
> /usr/include/linux/signal.h.
The history: At April, 21st, I'd sent a patch to Larry which should
fix sigtrap package. That patch made its way to Andy's patch-5.001i or
earlier. Unfortunately my fix was wrong. The result was failing test
pipe.t on all linux systems. Therefore I sent a second workaround
patch.
I'll include last my mail to Larry and Andy.
- - Andreas
PS: This mail is not pgp signed by exception, 'cause it would mangle
the patch included (lines starting with dashes).
- -----------------------------------------------------------------------------
>From koppenas Mon Jul 10 20:07:24 1995
Subject: patch for perl5.001i/Configure - signal names - second try (fwd)
To: doughera@lafcol.lafayette.edu
Date: Mon, 10 Jul 1995 20:07:25 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 4854
Status: RO
Hello Andy,
about a month ago I've sent a patch to Larry which fixes a little bug
in Config.sh. The bug causes t/io/pipe.t fail on Linux. Since it's not
yet included in your latest patches, I send it to you too.
Thank you very much for your work on perl.
Andreas
- ----- cut here ----- snip snap -------------------------------------
>From koppenas Mon Jun 12 17:49:33 1995
Subject: patch for perl5.001i/Configure - signal names - second try
To: lwall@netlabs.com
Date: Mon, 12 Jun 1995 17:49:33 +0200 (MET DST)
Reply-To: Andreas.Koppenhoefer@studbox.uni-stuttgart.de (Andreas Koppenhoefer)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 4121
Hello Larry,
some time ago I'd you sent a simple patch for Configure. Unfortunately
my patch introduced another bug to perl. I'm sorry about that - mea
culpa. In the hope perl5.002 is not yet release, I send you a
correction!
I've found my own bug while compiling/testing perl5.001i:
perl5.001i/t/io/pipe.t fails because
$SIG{'PIPE'} = 'broken_pipe';
installs an interrupt handler for SIGALRM instead of SIGPIPE! Perl is
not able to handle more than one signal name for a given signal number
as I thought before.
Therefore it's necessary to patch Configure once more.
=============================================================================
- --- perl5.001i/Configure.orig Wed Jun 7 09:09:12 1995
+++ perl5.001i/Configure Mon Jun 12 17:18:14 1995
@@ -7358,8 +7358,6 @@
$1 ~ /^#define$/ && $2 ~ /^SIG[A-Z0-9]*$/ && $3 ~ /^[1-9][0-9]*$/ {
if (sig[$3] == "")
sig[$3] = substr($2,4,20)
- - else
- - sig[$3] = sig[$3] " " substr($2,4,20)
if (max < $3 && $3 < 60) {
max = $3
=============================================================================
This patch makes sure that
a) only one signal name gets defined for each signal number and
b) the first signal name for a given signal number is used.
Comparing to plain 5.001 or 5.000 the last signal name defined in
signal.h was used formerly.
Just for your information I'll include my first patch here again.
=============================================================================
Forwarded message:
> From koppenas Fri Apr 21 18:25:33 1995
> Subject: patch for perl5.001/Configure - signal names
> To: lwall@netlabs.com
> Date: Fri, 21 Apr 1995 18:25:33 +0200 (MET DST)
> Reply-To: Andreas.Koppenhoefer@studbox.uni-stuttgart.de (Andreas Koppenhoefer)
>
> Hello Larry,
>
> here is a simple improvement (patch) for your perl5.001 Configure
> script. Hope you like it.
>
> Linux and maybe other unix systems have more than one signal name for a
> specific signal number.
>
> Excerpt from /usr/include/linux/signal.h (Linux 1.2.5):
> - -----------------------------------------------------------------------------
> [...]
> #define SIGQUIT 3
> #define SIGILL 4
> #define SIGTRAP 5
> #define SIGABRT 6
> #define SIGIOT 6
> #define SIGBUS 7
> #define SIGFPE 8
> #define SIGKILL 9
> [...]
> - -----------------------------------------------------------------------------
> Take a close look at signal number 6...
>
> In the current version of Configure (perl5.001 with Andy Dougherty's
> patches a..e) only the last signal name listed in signal.h
> will make its way thru Configure. In the case of Linux SIGABRT is
> thrown away, because there is an alias SIGIOT.
>
> As a result, package sigtrap will mumble about unknown signal ABRT!
>
> A simple patch for Configure which avoids this...
> -----------------------------------------------------------------------------
> --- perl5.001e/Configure.orig Sun Mar 12 08:35:24 1995
> +++ perl5.001e/Configure Fri Apr 21 12:09:24 1995
> @@ -7016,7 +7063,11 @@
> xxx=`./findhdr signal.h`" "`./findhdr sys/signal.h`" "`./findhdr linux/signal.h`
> set X `cat $xxx 2>&1 | $awk '
> $1 ~ /^#define$/ && $2 ~ /^SIG[A-Z0-9]*$/ && $3 ~ /^[1-9][0-9]*$/ {
> - sig[$3] = substr($2,4,20)
> + if (sig[$3] == "")
> + sig[$3] = substr($2,4,20)
> + else
> + sig[$3] = sig[$3] " " substr($2,4,20)
> +
> if (max < $3 && $3 < 60) {
> max = $3
> }
> -----------------------------------------------------------------------------
> As far as I can see, this patch doesn't hurd on other systems.
> [...]
=============================================================================
Hope I'm right this time.
- - Andreas
- --- cut here ----- snip snap -------------------------------------
- --
Andreas Koppenhoefer, Student der Universitaet Stuttgart, BR Deutschland
prefered languages: German, English, C, perl ("Just another Perl hacker,")
SMTP: koppenas@informatik.uni-stuttgart.de (university address)
Andreas.Koppenhoefer@studbox.uni-stuttgart.de (my home address)
privat: Belaustr. 5/3, D-70195 Stuttgart, Germany,
Earth, Sector ZZ9 plural Z alpha
phone: +49 711 694111 and +49 711 6999006 (19-22h MEZ=GMT+1)
------------------------------
End of linux-kernel-digest V1 #121
**********************************