Linux-Development-Sys Digest #707, Volume #6 Thu, 13 May 99 00:13:58 EDT
Contents:
Translatable programs ("Kalaznikov")
Re: You can now use Winmodems in Linux!!!!!!! (Christopher Mahmood)
Re: I want to learn to make drivers (Christopher Mahmood)
Re: Glibc rant (Ulrich Drepper)
glibc-2.1.1 compiled broken (Xiphos Fuhr)
Re: I want to learn to make drivers (Scott Lanning)
gettimeofday timewarps with XiG Xaccel-5.0, 2.2.7 ("dave madden")
Re: glibc-2.1 compiled broken (Xiphos Fuhr)
Posix semaphores support? (Valentin Bazavan)
Drivers for specialised hardware (Rajarshi Bandyopadhyay)
Re: How to make linux boot/shutdown rapidly (Pat Crean)
Re: Reliable (!) nic for 2.2 kernel? (Leslie Mikesell)
what the ??!! happened to system headers in redhat 6?? (dave linenberg)
Re: what the ??!! happened to system headers in redhat 6?? (dave linenberg)
Re: You can now use Winmodems in Linux!!!!!!! (Christopher Browne)
Re: Linux disk defragmenter (Christopher Browne)
tcdrain(serial_fd) program (Kuang-chun Cheng)
Re: gettimeofday timewarps with XiG Xaccel-5.0, 2.2.7 ("dave madden")
----------------------------------------------------------------------------
From: "Kalaznikov" <[EMAIL PROTECTED]>
Subject: Translatable programs
Date: Thu, 13 May 1999 00:49:22 +0200
Reply-To: "Kalaznikov" <[EMAIL PROTECTED]>
I am a guy, who wants to translate programs into my native
language(faroese!).Can anyone give examples of well-written, useful and
popular programs, which are actually translatable from english into other
languages without you having to redesign the whole program? Thinking
especially about OS'es, browsers, word-processors and things like
that. Looking forward hearing from you.
Yours sincerely Kal
------------------------------
From: Christopher Mahmood <[EMAIL PROTECTED]>
Subject: Re: You can now use Winmodems in Linux!!!!!!!
Date: 12 May 1999 04:24:37 -0700
that's why i was being sarcastic...IMO, linux developers spend too much
time trying to fix or work around problems that MS or manufacturers
of crappy pc hardware create.
-ckm
------------------------------
From: Christopher Mahmood <[EMAIL PROTECTED]>
Subject: Re: I want to learn to make drivers
Date: 12 May 1999 04:26:56 -0700
There's an O'Reily book on it.
-ckm
------------------------------
From: Ulrich Drepper <[EMAIL PROTECTED]>
Crossposted-To: gnu.misc.discuss
Subject: Re: Glibc rant
Date: 12 May 1999 17:52:31 -0700
Reply-To: [EMAIL PROTECTED] (Ulrich Drepper)
"G. Sumner Hayes" <[EMAIL PROTECTED]> writes:
> Is this level of binary compatibility a goal of the glibc
> developers? If so, what should the Linux community be doing to help?
> If not, then there appears to be a real split between the glibc camp
> and the Linux camp; what's the best way to go about mending it?
I'll comment on all this once, so don't bother sending me any mail:
- we care about binary compatibility. Why else should we have implemented
symbol versioning? It wasn't anybody of those complaining.
- some parts of the system (esp low-level libraries) are too tightly coupled
to the C library to prevent them from failing. But this is no big problem
since only those libraries and not the programs using them have to be
recompiled.
- all binary incompatibilities which are not documented are unexpected. They
are not fixed because
a) nobody has reported them
b) nobody helped fixing them
We only have very limited resources to test the new versions and to fix
problems. The only people who are paid to do these jobs and so can spend
their day with it are the distribution makers. My systems are exclusively
used for development, what the hell do I know what a system used for, say,
web serving requires.
The only way to ensure that nothing breaks is
- participating in the testing; there are always a number of test releases
- report and preferably *fix* problems
Those who don't do anything have not the slightest right to complain. At
least not to the glibc developers. One might have a right to complain if
one pays for something and then it is the distribution makers problem. They
should have tested things (I know they do but they also have limitations).
- for the 2.1 release especially some programs had problems because they use
undocumented *internal* interfaces. We simply had not the technology to
prevent stupid people from using these functions and variables.
Now we have the technology (again, implemented by Eric Youngdale and me).
No internal interface is exported and to make things clear, the headers
are also cleaned up and should not mention any internal interface anymore.
But we can't undo the damage caused by programmers who didn't follow the
rules in the past. There are ways around this and at least SuSE will
implement the way I suggested. But this solution *cannot* be part of the
libc since it would again allow writing non-conforming programs.
- some programs are written unclean. E.g., programs using
fp = setmntent (...);
...
fclose (fp);
do crash now. If the program would have been written correctly by using
endmntent (fp);
instead of the `fclose' call everything would be nice and easy. It only
accidently worked in the past.
- I really think that with symbol versioning it is possible to write
compatible libraries. Maybe other libraries should adapt it.
- the libc development will not continue indefinitely. There is an end in
sight. I have a few more large changes on the list but after that glibc
will be feature-complete. Changes will be limited to bug fixes, new
functionality and in limited amount of new features. All should be very
well implementable with breaking binary incompatibility.
And one more thing: I constantly keep reading something about "glibc
folks" versus "Linux folks". This is completely bogus. Except for
the, nowadays, three guys working on Hurd all active developers are
using Linux. HJ Lu and I are using Linux longer than 99.9999% of all
Linux users. Our main development platform is Linux. So stop this
nonsense!
I have stated this a few times already but newsgroups repeat itself
since people are too lazy to look up the archives. Maybe somebody can
put the above in an newsgroup-FAQ or so.
--
===============. drepper at gnu.org ,=. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com `------------------------
------------------------------
From: Xiphos Fuhr <[EMAIL PROTECTED]>
Subject: glibc-2.1.1 compiled broken
Date: Wed, 12 May 1999 17:12:01 -0700
I sincerely hope this is the proper location for assistance.
These past few days have found me with the wacky notion I could upgrade
my system from libc5 straight to glibc-2.1
Apparently, I was wrong. I have followed the GLibc2 HowTo
(http://lagrange.la.asu.edu/VirtualClass/LinuxOnline/Glibc2-HOWTO/index.html)
to the letter, with the following exception; I upgraded to egcs-1.1.2,
as per the instructions in the glibc-2.1 INSTALL documentation.
glibc-2.1 compiled and pased make check with flying colors.
I followed ever step as outlined in the How-To, triple checking every
command before executing.
current relevent setup information:
linux kernel 2.2.8
GNU Make 3.77
egcs 1.1.2
binutils 2.9.1
GNU awk 3.0.3
Perl 5
errors when attempt is made to compile simple "hello world" program:
frenzy$ gcc hellow.c -o hellow
/usr/local/lib/libc.so.6: undefined reference to `_dl_sysdep_start@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `_r_debug@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `_dl_starting_up@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `_dl_unload_cache@@GLIBC_2.1'
/usr/local/lib/libc.so.6: undefined reference to `_dl_init_next@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `_dl_signal_error@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `_dl_relocate_object@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `_dl_initial_searchlist@@GLIBC_2.1'
/usr/local/lib/libc.so.6: undefined reference to `_dl_profile@@GLIBC_2.1'
/usr/local/lib/libc.so.6: undefined reference to `_dl_global_scope_alloc@@GLIBC_2.1'
/usr/local/lib/libc.so.6: undefined reference to `_dl_fpu_control@@GLIBC_2.1'
/usr/local/lib/libc.so.6: undefined reference to `_dl_debug_message@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `_dl_mcount@@GLIBC_2.1'
/usr/local/lib/libc.so.6: undefined reference to `_dl_debug_initialize@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `_dl_start_profile@@GLIBC_2.1'
/usr/local/lib/libc.so.6: undefined reference to `_dl_check_all_versions@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `_dl_catch_error@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `_dl_map_object@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `_dl_loaded@@GLIBC_2.1'
/usr/local/lib/libc.so.6: undefined reference to `_dl_main_searchlist@@GLIBC_2.1'
/usr/local/lib/libc.so.6: undefined reference to `_dl_profile_map@@GLIBC_2.1'
/usr/local/lib/libc.so.6: undefined reference to `_dl_profile_output@@GLIBC_2.1'
/usr/local/lib/libc.so.6: undefined reference to `_dl_map_object_deps@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `_dl_debug_impcalls@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `_dl_debug_state@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `_dl_lookup_symbol@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `__libc_enable_secure@@GLIBC_2.0'
/usr/local/lib/libc.so.6: undefined reference to `__libc_stack_end@@GLIBC_2.1'
collect2: ld returned 1 exit status
frenzy$
questions:
What did I do wrong?
Can it be fixed without reinstalling Linux?
Thank you for your time
--
Xiphos <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Scott Lanning)
Subject: Re: I want to learn to make drivers
Date: 13 May 1999 01:06:43 GMT
Enrique Cespedes ([EMAIL PROTECTED]) wrote:
: Hi, I'd like to learn how to make drivers. Here can I found
: documentation. There is a site at the wed ? Or a good book ?
Linux Device Drivers by Alessandro Rubini es muy bueno.
Three LDP guides: (1) http://www.linux.org.za/LDP/LDP/tlk/tlk.html
describes "The Linux Kernel" in easy to understand language; also
includes a chapter on device drivers. (2) "Linux Kernel Module
Programming Guide" at http://www.linux.org.za/LDP/LDP/lkmpg/mpg.html.
(3) http://khg.redhat.com/HyperNews/get/khg.html is the
"Linux Kernel Hacker's Guide".
--
Scott Lanning: [EMAIL PROTECTED], http://physics.bu.edu/~slanning
------------------------------
From: "dave madden" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.x
Subject: gettimeofday timewarps with XiG Xaccel-5.0, 2.2.7
Date: 12 May 1999 17:37:41 -0700
I'm having a wierd problem with XiG's new X server on a dual-CPU PIII
running 2.2.7. The server seems to think that the clock is bouncing
forwards and back, which causes it to turn on the screen blanking.
This happens every 1-2 seconds, and I can see (through strace) that
the server is running a gettimeofday() syscall and getting back values
that increase monotonically for a second or two, then jump forward
4295 seconds (exactly, always) and then back again. Of course, with
the jump forward, the screen saver is turned on.
I've also run a simple program that just runs gettimeofday over and
over, but it never notices the time warp, even while the server is
warping. Also, the server warp doesn't happen immediately or always;
usually, the first server started after a reboot works OK (delta some
annoying mouse wierdness). However, problems begin to occur on the
n-th server restart, where n is a small number (less than 5) that I
haven't been able to determine exactly.
Does this sound familiar to anybody? (It was news to XiG's support
people.) Any suggestions?
regards,
dave madden
--
header address is anti-spamified. use caution when replying by
email to <[EMAIL PROTECTED]> because my real address
omits the hostname.
------------------------------
From: Xiphos Fuhr <[EMAIL PROTECTED]>
Subject: Re: glibc-2.1 compiled broken
Date: Wed, 12 May 1999 17:21:15 -0700
Addendum: 2.1, not 2.1.1
woops :)
------------------------------
From: Valentin Bazavan <[EMAIL PROTECTED]>
Subject: Posix semaphores support?
Date: Wed, 12 May 1999 18:47:21 -0700
Right now, support for Posix semaphores on Linux is incomplete. There
is no support for named
semaphores, and only partial support for memory-based semaphores. In
particular, the memory-based
semaphores can't be used between processes, which is the main rationale
of having semaphores in
the first place. Is there any work going on to fill in the missing
features?
Thanks,
Valentin Bazavan
------------------------------
From: Rajarshi Bandyopadhyay <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.hardware
Subject: Drivers for specialised hardware
Date: Thu, 13 May 1999 07:49:37 +0530
Hi
I am working on a project involving specialised H/W , eg , nudaq
PCI-9118 high-speed data acquisition card with linux. Is there any place
where drivers of such specialised hardware are archived? Also, if anyone
is acquainted with this card, could that person pls get in touch with
me?
TIA
Raj
------------------------------
From: Pat Crean <[EMAIL PROTECTED]>
Subject: Re: How to make linux boot/shutdown rapidly
Date: Wed, 12 May 1999 21:58:38 -0400
On Wed, 12 May 1999, Michael Hirsch wrote:
>When I close the cover of my think pad, or hit the right key
>combination, it immediately writes the RAM to disk, then shuts off.
>On power-up it does the opposite--reads the disk file into RAM and
>starts executing where it left off. This even works when running
>Linux.
>
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To: comp.os.linux.networking
Subject: Re: Reliable (!) nic for 2.2 kernel?
Date: 12 May 1999 21:38:46 -0500
In article <[EMAIL PROTECTED]>,
Johan Kullstam <[EMAIL PROTECTED]> wrote:
>>
>> >> sounds like a single mode hub (choose 1: 10 or 100, and everyone on
>> >> the hub MUST speak that speed. right?)
>> >
>> >yes. exactly.
>> >
>> [...]
>> >i only have 2 computers. they are both in 100/full duplex mode.
>>
>> If you are using a hub you have to use half duplex. Full duplex
>> only works with switches.
>
>ok thanks! i didn't know that.
As others have pointed out there are some things that are called
hubs that really aren't shared media repeaters, but anything
that allows the possibility of collisions requires half duplex
operation and that is the case for normal hubs where all
ports operate at the same speed.
>does full duplex mode work with a direct cross-over cable?
Yes, both sides are allowed to transmit at the same time
in this configuration.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: dave linenberg <[EMAIL PROTECTED]>
Subject: what the ??!! happened to system headers in redhat 6??
Date: Thu, 13 May 1999 02:33:29 GMT
I have been writing programs in red hat 5.2 for the past 6 months or
so, and after installing redhat 6.0, it seems like header files are
strewn all over the place in odd places !!! I am trying to port my
5.2 programs over, and I cannot seem to find headers such as stdio.h .
/usr/include/g++ (redhat 5.2) seems to be now /usr/include/g++-2
there is no rpc directory which normally contains files like xdr.h (
which sun remote procedure calls is based on)
Perhaps I did not install one of the rpms. Please help me find all my
headers!!! What am I doing wrong,
or is the new redhat 6.0 soc ompletely different from rh 5.2 when it
comes to header files ???!!!
( I MUST be doing something wrong if I haven't found standard files like
xdr.h !!)
Dave Linenberg
[EMAIL PROTECTED]
------------------------------
From: dave linenberg <[EMAIL PROTECTED]>
Subject: Re: what the ??!! happened to system headers in redhat 6??
Date: Thu, 13 May 1999 02:49:56 GMT
OK... I managed to track down a number of the headers...
find / -name xdr.h -print
/usr/src/linux-2.2.5/include/linux/lockd/xdr.h
/usr/src/linux-2.2.5/include/linux/nfsd/xdr.h
/usr/src/linux-2.2.5/include/linux/sunrpc/xdr.h
/usr/i386-glibc20-linux/include/linux/lockd/xdr.h
/usr/i386-glibc20-linux/include/linux/nfsd/xdr.h
/usr/i386-glibc20-linux/include/linux/sunrpc/xdr.h
/usr/i386-glibc20-linux/include/rpc/xdr.h
my question remains,.... what the !!?? is going on with all the header
trees??
I've managed to also gain some success by linking against glibc20 headers,
but is this
outdated??
Thanks for all your help again,
Dave Linenberg
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: You can now use Winmodems in Linux!!!!!!!
Reply-To: [EMAIL PROTECTED]
Date: Thu, 13 May 1999 02:54:54 GMT
On 12 May 1999 19:27:52 GMT, bill davidsen <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Philip Boucherat <[EMAIL PROTECTED]> wrote:
>| What is a Winmodem anyway, and why would I want to use it?
>
>A winmodem is a device which uses a $200 CPU to substitute for a $4 UART
>in generating the clocked bit values for the modem output. This allows
>you to slow your system performance, and your modem performance, while
>reducing the initial hardware cost a little and boosting the
>manufacturer's profit at your expense.
>
>You would want to use it because (a) someone gave it to you and you
>can't afford a real modem, or (b) you are stupid and didn't read past
>"specially for Windows" on the box.
... Add to this the factor that the WinModem requires that the
operating system provide real time Quality of Service guarantees to
the process of Servicing the Modem.
... But add the mitigating factor that the "consuming CPU portion"
involved consuming about 25% of the processing power of a P90.
In these power-inflated days where a 300MHz AMD chip costs $100, the
portion of the CPU's power being "wasted" falls from 25% of a $200 P90
to something more like 1/12 * $100 CPU, which is thus around $8.
That's more than $4, but it's certainly less than the
"$50-worth-of-CPU" that used to be consumed by WinModem use.
Don't misread this as an argument that WinModems are thereby a
wonderful thing; I wouldn't touch one with a many-foot-pole, and
prefer to have modems that I can shut off/reset without having to
reboot my server.
The point is that the strength of the economic argument concerning
"wasting expensive CPUs" is weakened with CPU power increases and
prices fall.
--
"Few people are capable of expressing with equanimity opinions which
differ from the prejudices of their social environment. Most people are
even incapable of forming such opinions." (Albert Einstein)
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Linux disk defragmenter
Reply-To: [EMAIL PROTECTED]
Date: Thu, 13 May 1999 02:54:58 GMT
On 12 May 1999 19:21:48 GMT, bill davidsen <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>The Ghost In The Machine <[EMAIL PROTECTED]> wrote:
>| On 10 May 1999 03:48:59 -0700, Tim Smith <[EMAIL PROTECTED]> wrote:
>| >Mark Hahn <[EMAIL PROTECTED]> wrote:
>
>| >Seek time is monotonic in linear address, but access time is not. On modern
>| >disks, rotational latency is much larger than seek latency for typical
>| >requests.
>
>| It gets even goofier when one realizes that a lot of disks
>| are variable-geometry, meaning that there are a different
>| number of sectors depending on which cylinder is being
>| discussed. How does one optimize disk access for such
>| a beast without detailed knowledge of where each
>| sector is?
>
>The answer is that in absolute terms you can't. And more to the point,
>I'm not sure if you want to optimize disk access time to maximize
>io/sec, or if you want to treat a set of pending requests as a single
>problem and optimize for sets/sec. If you always do the fastest io next,
>you can leave requests unsatisfied for a very long time.
Discussion of this came up this week on the Reiserfs mailing list; my
reading of the answers attained would be to suggest the following
algorithm:
- For each request, insert it into two queues:
a) A priority queue, Queue A, where we'll try to optimize disk access,
and
b) A FIFO queue, Queue B, timestamped with the future time, T+Omega,
at which point we want to "deliver" the change.
The "optimizing process" then goes, and does its thing, looking at
Queue A to "intelligently reorder" the requests sitting in Queue A.
When it satisfies requests, it naturally removes them from both
queues.
If all goes well, requests will get handled before that "future time"
recorded in Queue B.
But if all does not go well, and there is a request that is being
starved, the time will eventually come when we have passed time
T+Omega.
At which point the "FIFO" process kicks in, and says:
"There's a request that hasn't been satisfied in the time ``Omega''
since it was submitted. *Do it now.* And again delete from both
queues.
The question will be "How large to set Omega?" If it's too small,
then you get little value from bothering with Queue A. If it's too
large, some requests will have excessive latency if the system gets
busy.
A "cool part" is that one might add in some application-oriented
priority information.
For instance, you might want certain updates to take place in order,
irrespective of what optimizations might *want* to take place, or to
indicate that "This is a metadata update; give it priority over
non-metadata." (Some of this might get overridden by the FIFO; No
Free Lunch...)
[Implementational detail: I think that what *truly* happens is that
this represents *three* queues: two in which things are queued up for up
to Omega time, one of which that attempts to order in optimal fashion
based on whether requests are "near" to one another, the second of
which that eventually pushes through requests that stay queued too long,
and then a third "real" queue to which the other two forward requests,
which has access to the device and actually *does* the disk access...
Essentially, there are two "paths" that requests take in getting into the
"true queue."]
>I believe that bidirectional would be a win for most cases, and a small
>loss for the exceptions. However, your comment on rotational speed is
>the key one, you have to know all the details include settling time vs
>position and length of seek before you could do a good job getting the
>optimal solution.
Indeed.
--
"I've discovered that P=NP, but the proof is too long to fit within the
confines of this signature..."
[EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
------------------------------
From: Kuang-chun Cheng <[EMAIL PROTECTED]>
Subject: tcdrain(serial_fd) program
Date: 13 May 1999 03:54:41 GMT
Hi,
In my simple test program, I open /dev/cua1 or /dev/ttyS1
with options O_RDWR|O_SYNC. After open, I setup the serial port to
raw mode by using tcflush() and tcsetattr() and I turn on the CRTSCTS
hardware flow control.
I simply wire RTS and CTS together. And look at the TD and RTS
by oscilloscope. In my program looks like this
unsigned char status = TIOCM_RTS;
... /* setup serial port */
for(;;) {
ioctl(fd, TIOCMBIS, &status); /* set RTS */
write(fd, prt_to_char_array, 4);
tcdrain(fd); /* wait until send */
ioctl(fd, TIOCMBIC, &status); /* clear RTS */
/* some delay */
}
I expect the timing diagram looks like this:
==================+ +============ RTS set
| |
| |
| |
+------ some delay -----+ RTS clear
--++-++-++-++--------------------------------++-++-++
|| || || || || || ||
|| || || || || || ||
|| || || || || || ||
++ ++ ++ ++ ++ ++ ++
That meant RTS clear should happen after all data had been transmitted.
However, what I saw is
=========+ +============ RTS set
| |
| |
| |
+------ some delay -----+ RTS clear
--++-++-++-++--------------------------------++-++-++
|| || || || || || ||
|| || || || || || ||
|| || || || || || ||
++ ++ ++ ++ ++ ++ ++
That meant the tcdrain() doesn't work as I expected. Does anyone has
similar experience or can tell me what's going on. Thanks
--
Kuang-chun Cheng
Soliton Technologies Co., LTD.
3F, No176-1, Chien-Kang Road, Taipei, Taiwan, ROC
Tel: 886-2-27624891 Fax: 886-2-27624965
[EMAIL PROTECTED]
------------------------------
From: "dave madden" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.x
Subject: Re: gettimeofday timewarps with XiG Xaccel-5.0, 2.2.7
Date: 12 May 1999 19:57:46 -0700
In article <[EMAIL PROTECTED]> I wrote:
=>I'm having a wierd problem with XiG's new X server on a dual-CPU PIII
=>running 2.2.7. The server seems to think that the clock is bouncing
=>forwards and back, which causes it to turn on the screen blanking.
=>
=>This happens every 1-2 seconds, and I can see (through strace) that
=>the server is running a gettimeofday() syscall and getting back values
=>that increase monotonically for a second or two, then jump forward
=>4295 seconds (exactly, always) and then back again. Of course, with
=>the jump forward, the screen saver is turned on.
=>
=>I've also run a simple program that just runs gettimeofday over and
=>over, but it never notices the time warp, even while the server is
=>warping.
Oops, incorrect observation. The warp duration is very short, and the
simple program was only checking the time every 0.1 or 0.05 seconds.
When I check every 0.01 seconds (timed by select()), I *do* notice the
time warping forward 4294 seconds, then back again almost immediately.
This is wierd.
--
header address is anti-spamified. use caution when replying by
email to <[EMAIL PROTECTED]> because my real address
omits the hostname.
------------------------------
** 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
******************************
