Interesting, I just came cross the same problem. I actually reported it
yesterday on this list. I haven't heard any comments about the proposed
fix.
> The 2.2 problems are somewhat conjectural, but I wrote a test
> kernel-module which sets `jiffies' to 0xf000000; this machine then
> exhibits the select bug.
Well, I was not that careful with 2.2. I just quickly looked whether the
exact same error was being made, and it wasn't.
> Other visible problems:
> times() returns -1; perhaps this is inevitable/correct...
According to man page, times should return number of clock ticks that have
elapsed since the system has been up, so I think that's not correct.
I have not experienced that problem with times - clock() on the other hand
does just that. (Are you using glibc or libc5?) The problem with clock()
is/was that kernel passes the (unsigned long) jiffies to glibc clock() as
it is, but glibc expects a signed int (time_t). If the values glibc gets
from the kernel, glibc intrepets that as an error and returns -1. Kernel
even uses some negative error codes when it can't allocate memory. This
has been fixed in the CVS glibc according to the glibc maintainers I was
in touch with. (Glibc doesn't return error in any case, even if kernel
returned an error code (-501...-1). OTOH, kernel can return -501...-1
also, when jiffies is in that range.)
> The way we discovered the select problem, btw, was that `zsh's
> interface depends on the select() returned time.
Same here. I'm not sure about zsh-3.0.5, but I did investigate 3.1.5.
There the problem lied in Zle/zle_main.c. The zsh team has already fixed
this:
=================================================================
Date: Wed, 28 Apr 1999 09:51:16 +0200
From: Peter Stephenson <pws@ibmth.df.unipi.it>
Subject: Re: [Solved] Re: Terminal problem with linux-2.0.34
To: Ville Herva <vherva@babbage.tky.hut.fi>,
zsh-workers@sunsite.auc.dk (Zsh hackers list)
Ville Herva wrote:
>
> This proved to be the select call in line 517 in Zle/zle_main.c (zsh-3.1.5
> vanilla):
>
> if (!kungetct && select(SHTTY+1, (SELECT_ARG_2_T) & foofd,
> NULL, NULL, &tv) <= 0)
>
> If I add the following line before the above call, zsh works well:
>
> tv.tv_sec = 0;
Thanks, this is the diff for 3.1.5-pws-16 (Bart's already put something
into 3.0.6).
--- Src/Zle/zle_main.c.tv Mon Apr 19 11:40:09 1999
+++ Src/Zle/zle_main.c Wed Apr 28 09:48:30 1999
@@ -413,7 +413,6 @@
baud = getiparam("BAUD");
costmult = (baud) ? 3840000L / baud : 0;
- tv.tv_sec = 0;
#endif
/* ZLE doesn't currently work recursively. This is needed in case a
*
@@ -523,6 +522,7 @@
#ifdef HAVE_SELECT
if (baud && !(lastcmd & ZLE_MENUCMP)) {
FD_SET(SHTTY, &foofd);
+ tv.tv_sec = 0;
if ((tv.tv_usec = cost * costmult) > 500000)
tv.tv_usec = 500000;
if (!kungetct && select(SHTTY+1, (SELECT_ARG_2_T) & foofd,
=================================================================
> Are there any plans to fix these issues? Are they known problems?
I proposed yesterday the following:
=================================================================
If the timeout is reached during do_select, current->timeout becomes zero.
The line
if ((long) timeout < 0)
timeout = 0;
is propably for that. However, if jiffies > 2**31, that won't work (since
timeout wraps around and actually becomes positive), and select returns
false values. I would suggest something like
timeout = current->timeout ? current->timeout - jiffies - 1 : 0;
instead of
timeout = current->timeout - jiffies - 1;
=================================================================
But I have no clue whether Alan Cox is planning to include the fix in
2.0.37.
-- v --
v@iki.fi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/