Linux-Development-Sys Digest #302, Volume #8 Sun, 26 Nov 00 15:13:16 EST
Contents:
Re: XFree 4 crashes kernel 2.4.0-test5 (Philip Armstrong)
Re: XFree 4 crashes kernel 2.4.0-test5 (ratz)
Re: Triton problem with 2.2.X... (was Re: slow connection?) ("Guennadi V.
Liakhovetski")
Modify the scheduler to manage shortest-job first (Frank Meier)
Re: Stack access speed (Nix)
Re: Runtime file size modifying (Nix)
Re: Message queues: real world applications (Nix)
Re: Modify the scheduler to manage shortest-job first (Todd Knarr)
Re: rdtsc() timestamps synchronized between SMP CPU's? (Robert Redelmeier)
Re: Adding a system call (Andi Kleen)
Re: Modify the scheduler to manage shortest-job first (Kaz Kylheku)
Re: What distro does Linus Torvalds use? (J.H.M. Dassen (Ray))
Re: Modify the scheduler to manage shortest-job first (Dave Platt)
How to implement a timer (Christopher GAUTIER)
Re: How to implement a timer (Bruce Stephens)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Philip Armstrong)
Crossposted-To: linux.debian.devel
Subject: Re: XFree 4 crashes kernel 2.4.0-test5
Date: 26 Nov 2000 09:45:28 -0000
In article <[EMAIL PROTECTED]>,
Otto Wyss <[EMAIL PROTECTED]> wrote:
>> > I have upgraded to XFree86 version 4.0.1e on my computer (i386) running
>> > kernel 2.4.0-test5 with framebuffer support. While XFree86 version 3.3.6
>>
>> Upgrade to 2.4.0-test11. This is a known issue. BTW if you'd like
>> to reproduce it could you check if there are alot of shm segments
>> cludging in your system before the crash?
>>
>I'll going to get test-11, but a 20MB download is not that easy for me,
>I only have a 56k modem line.
If you've got 2.4.0test5, then the patches -> 2.4.0test11 should be < 20Mb.
Phil
--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt
------------------------------
From: ratz <[EMAIL PROTECTED]>
Crossposted-To: linux.debian.devel
Subject: Re: XFree 4 crashes kernel 2.4.0-test5
Date: Sun, 26 Nov 2000 11:42:57 +0100
Hi Otto,
First off, I think we're getting OT in these newsgroups so therefor
we should take this off and discuss it privatly. I reckon we are
even working in the same building guessing from you email address ;)
> I'll going to get test-11, but a 20MB download is not that easy for me,
> I only have a 56k modem line.
Download the appropriate diffs and do incremental patching. Maybe you
even want to download and compile test11-ac4 [some minor bugfixes :)]
> Later, now I just unmount any unnecessary partitions. Currently I only
> need just my 2GB root which I have mirrored to a second partition.
Whatever.
> My reasons to use development kernels are:
This is ok, I mean you don't have to justify ...
> - needs USB support for my keyboard/mouse
has been backported to 2.2.x
> - likes to have framebuffer support for console mode
has been backported to 2.2.x
> - likes to play around with a rather uptodate system
Yep, this is a very good reason. And it's stable anyway.
> dmesg is useless, doesn't give any more informations. kdb is out of
> questions since don't know enough of the sources. ksymoops might be
> right, I'll try it. But I guess it won't help. Form what I've gathered
> sofar, the crash is so bad the kernel doesn't even generate an Oops. Is
> there a switch either in the kernel and/or XFree86 which produces more
> log messages?
Enable sysrq in the kernel and dump the register entries and
pipe them through ksymoops.
Best regards,
Roberto Nibali, ratz
http://www.security-architects.com
--
mailto: `echo [EMAIL PROTECTED] | sed 's/[NOSPAM]//g'`
------------------------------
From: "Guennadi V. Liakhovetski" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: Triton problem with 2.2.X... (was Re: slow connection?)
Date: Sun, 26 Nov 2000 12:17:41 +0000
In my case disk supports PIO4 and DMA multiword2, it doesn't support
UDMA. BIOS is AMIBIOS 1.00.03.AC0 and chipset is triton (Intel
430FX). Everything is supposed to support DMA mw2, but I can't get
it. Repeated attempts to upgrade BIOS with the help from the computer
vendor failed (they first suggested that the right newest BIOS for this
motherboard - Morrison - is 10009BT0, but then they suggested it was
10009AC0, but none of them worked - both just produced an error like 'BIOS
file either unsuitable for this system or damaged). A 'simple' question -
can I visually identify if I have a flash BIOS or another type of
PROM? BIOS identifies both the hard disk and the CD-ROM fine.
Guennadi
On Fri, 24 Nov 2000, JB wrote:
> Check if your disk supports PIO4 with
> Check your bios and switch off UDMA detection (Award 4.51 is broken - it
> damages UDMA/66-100 disks, so linux wont detect them correctly)
>
> ZB
> <[EMAIL PROTECTED]> wrote in message news:8vlvpt$cno$[EMAIL PROTECTED]...
> > In article <Pine.GSO.4.21.0011221739390.25237-100000@acms23>,
> > "Guennadi V. Liakhovetski" <[EMAIL PROTECTED]> writes:
> > >
> > > PIIX: IDE controller on PCI bus 00 dev 38
> > > PIIX: not 100% native mode: will probe irqs later
> > > PIIX: neither IDE port enabled (BIOS)
> > >
> >
> > I would like the explaination too. However it is at least somewhat
> > bogus in that I get this message when the bios clearly thinks the ide
> > ports are enabled. Common consumer os will boot too.
> >
> > --
> > Recreational Calculus - Just For Fun!
> > P.S. "From" header is bogus, use below email address.
> > --
> > Chris Wagner
> > [EMAIL PROTECTED]
___
Dr. Guennadi V. Liakhovetski
Department of Applied Mathematics
University of Sheffield, U.K.
email: [EMAIL PROTECTED]
------------------------------
From: Frank Meier <[EMAIL PROTECTED]>
Subject: Modify the scheduler to manage shortest-job first
Date: Sun, 26 Nov 2000 15:45:48 +0100
Hi,
I'm looking for a linux scheduler who use shortest-job-first estimation.
Could anybody help me??
Thanks
Frank Meier
--
=============================================
eMail: mailto:[EMAIL PROTECTED]
WWW: http://www.deDanaan.de
===============================================
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Stack access speed
Date: 26 Nov 2000 13:03:50 +0000
Peter Pointner <[EMAIL PROTECTED]> writes:
> Nix <$}xinix{[email protected]> wrote:
>
> [snip]
>
> > Good, that includes -fdefer-pops, which would speed up this sort of
> > thing a lot.
>
> [snip]
>
> Why?? AFAIK -fdefer-pops is about (not) popping arguments.
> Which arguments?
Gak. Brain failure; it would affect things if libcalls were being made,
but of course they are not. You're right.
(Repeat after me: `never post when exhausted'...)
--
`The phrase `causes storage to be reserved', doesn't mean that it causes
storage to be reserved. This is a fundamental misunderstanding of
Standardeze.' --- Mike Stump on the GCC list
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Runtime file size modifying
Date: 26 Nov 2000 13:18:11 +0000
[EMAIL PROTECTED] (Alexander Viro) writes:
> In article <[EMAIL PROTECTED]>,
> Nix <$}xinix{[email protected]> wrote:
>
> >I meant `it would fill a hole[1] in the APIs' in that at present there is
> >no way to make a hole in a file anywhere but at the end.
>
> Sure, there is. If your filesystem allows holes and you care to do such
> "optimization" - feel free to insert the check that data being written
> consists of zeroes and let write() (->commit_write(), actually) punch
> the hole for you. Transparent, doesn't require any new syscalls,
... and why I didn't think of it I'll never know. I've been reading the
AIX reference manuals recently. Blame it on IBM-caused brain damage.
*selfLART*
(But of course the automatic scheme would be *almost* as much of a
horror... or would it? Because you could choose not to autopunch a hole
if nasty things were happening to the inode elsewhere, I guess it
wouldn't be... hmmm.)
> [2] and that's a _very_ mild term, trust me. The only thing that stops me
> from posting a long rant about choice pieces of POSIX/SuS idiocy to Other
> Place is the lack of a thread that could be conveniently drifted in that
> direction.
Start a rant, then. We always need more rants.
> I'm in the middle of getting the union-mounts[3] into the minimal
> compliance with POSIX semantics and it's not a pretty sight.
But POSIX doesn't mention union-mounts --- oh, hell, but it mentions
directories, so the mounted-on-objects had better look like them. Argh.
> [3] Example of braindamage: chdir(2) requires exec permissions on new pwd.
> That's nice, but what, in name of Cthulhu, does it mean for a union? And
God only knows. You could cheat and steal it from the way mounts work;
the permissions/ownership of the last mount point are inherited by the
mountee. (Er. No you couldn't. That would let you union-mount
/home/foo/bin (writable by you) on /bin (not so writable) and then
delete /bin/ls. But that would just delete it from the topmost mount,
not from /bin, wouldn't it? ... )
> it's not like we had a warranty that pwd is searchable - chmod 0 . does
> the trick quite fine... Good for Plan 9 folks, they could send POSIX to
> hell where it belongs. We are slightly less lucky...
Still, at least it's pronounceable. (IEEIX, ugh.)
(And we could always adopt something like POSIXLY_CORRECT in userspace;
a per-process attribute that flicks off the most annoying POSIXish
stuff, and by default such things are off. But of course that means
that it still has to be *implemented*....)
--
`The phrase `causes storage to be reserved', doesn't mean that it causes
storage to be reserved. This is a fundamental misunderstanding of
Standardeze.' --- Mike Stump on the GCC list
------------------------------
From: Nix <$}xinix{[email protected]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Message queues: real world applications
Date: 26 Nov 2000 13:10:15 +0000
ChromeDome <[EMAIL PROTECTED]> writes:
> Nix wrote:
> >
> > This makes message queues almost totally useless. Like the other parts
> > of sysvipc, their APIs are so broken that they might as well never have
> > been implemented, IMNSHO.
>
> Your vehemence seems a bit overly dogmatic to me. While it is true that
> message queues, like much of Unix, are not perfect, I've found them
> quite useful, especially in process control and data acquisition
> applications. OTOH, I've never needed a select :-).
Ah. I tend to use a buffering subprocess and select(1) on a pipe, rather
than cope with the horrible APIs of message queues.
> As to persistence, I've used that to enhance robustness. For example,
> if a watchdog task determines that another task has died, or has hung
> and must be killed, the watchdog can, after starting a replacement task,
> examine any pertinent message queues for leftover messages to the dead
> task (message type = pid) and redirect them to its replacement.
But at least one (the one that it was processing when it died) will be
gone, so you need to cater for dropped messages anyway.
This advantage is more than countered by the disadvantage that the
objects are not reference-counted, so you can never clean them up, even
if you want to. I often find myself with scores of the things eating
dozens of megabytes of memory, but I can never kill any of them, because
I don't know which are in use and which are not.
(Well, OK, they *can* be reference counted, but the old delete-and-use-
and-assume-removal-on-last-close trick is not standardized for sysvipc
like it is for real filesystem objects, IIRC.)
> And persistence isn't a detriment to a system that runs for months on
> end without a reboot and where all needed message queues ae set up at
> boot.
You could use that criterion to argue that the corresponding feature for
filesystem objects is unnecessary.
Their fundamental problem is that they violate the core of Unix
philosophy; `everything is a file'. It's now `everything is a file,
except for SysVIPC objects, for no good reason'. This is ugly,
complicates code, introduces bugs... and why? Because of (as near as I
can tell) lazy designers. (I'd ask aviro for his opinion here, except
that I think I already know his opinion of the SysV people's grasp of
engineering elegance...)
--
`The phrase `causes storage to be reserved', doesn't mean that it causes
storage to be reserved. This is a fundamental misunderstanding of
Standardeze.' --- Mike Stump on the GCC list
------------------------------
From: Todd Knarr <[EMAIL PROTECTED]>
Subject: Re: Modify the scheduler to manage shortest-job first
Date: 26 Nov 2000 16:15:32 GMT
In comp.os.linux.development.system <[EMAIL PROTECTED]> Frank Meier
<[EMAIL PROTECTED]> wrote:
> I'm looking for a linux scheduler who use shortest-job-first estimation.
I doubt you'll find one. The problem is, how does the scheduler go about
analyzing a program to decide how long it'll take to run? Unless I'm
mistaken, this turns into a variation of the halting problem, for which
no known solution exists in the general case. At best, I suspect it'd
wind up having to let each job run and see how long it took before deciding
which one to let run, which kind of defeats the purpose.
--
Remember: every member of your 'target audience' also owns a broadcasting
station. These 'targets' can shoot back.
-- Michael Rathbun to advertisers
in n.a.n-a.e
------------------------------
Date: Sun, 26 Nov 2000 10:48:47 -0600
From: Robert Redelmeier <[EMAIL PROTECTED]>
Subject: Re: rdtsc() timestamps synchronized between SMP CPU's?
Kaelin Colclasure wrote:
>
> Are the 64-bit timestamps (well, clock cycle counts) that are accessed
> via rdtsc() synchronized between CPU's on an SMP Linux system? That
> is, supposing it were somehow possible to execute a rdtsc instruction
> on each CPU in the system at the exact same instant, would they all
> have the same value?
>
> If not, would they be close enough to allow reasonably meaningful
> comparisons between values from two different CPU's?
On an SMP machine, try: `dmesg | grep TSC`
You should see a nice message saying " TSC synchronization: passed"
Have a grep through arch/i386/kernel and you will see the code
that generated that message.
If you don't like what the kernel does, remember that the TSC is
_writable_, but only in Ring0. So you can write a module driver
to do whatever you like.
You can issue an IPI (Interprocessor Interrupt) to all CPUs and
have them execute some unspinlocked synchronization code. This
should get you close (<200 CPU clocks), but I'll bet the remote
CPUs take a little longer to receive the acknowledge the IPI.
You could try a spinlock to synchronize the CPUs, but then you
are guaranteed some offset.
If you suspect the CPUs have different multipliers, which violates
both the SMP specification and common sense, this is very obvious
from /proc/cpuinfo. Anyone who sticks in different CPUs deserves
the scheduling favoritism they are sure to get. Plus the hardware
instability that might occur.
-- Robert
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: Adding a system call
Date: 26 Nov 2000 17:56:51 +0100
Macro <[EMAIL PROTECTED]> writes:
> I tried to add a system call using the following method. I succeed in
> Redhat 6.1 but I failed in Redhat 7.0. After compiling the new kernel in
> Redhat 7.0. The system blocks on the statement "Starting system
> logger..." when bootup. Would anyone tell me the reason ???
RH 7.0 uses 2.4 system calls for LFS in the libc. These clash with your test call,
but are not implemented in their standard kernel (but they are for example implemented
in the SuSE kernel)
To avoid booting problems you would need to start after the 2.4 range, but even that
is risky without reserving a slot with Linus first.
In general you should use ioctl on character devices instead of system calls,
because the devices have a better managed name space. There is a major/minor
defined for private devices, see Documentation/devices.txt. Adding new system calls
is usually the wrong approach.
-Andi
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: Modify the scheduler to manage shortest-job first
Reply-To: [EMAIL PROTECTED]
Date: Sun, 26 Nov 2000 17:35:21 GMT
On Sun, 26 Nov 2000 15:45:48 +0100, Frank Meier <[EMAIL PROTECTED]> wrote:
>Hi,
>I'm looking for a linux scheduler who use shortest-job-first estimation.
I think you are confused by your operating systems class in school. It is
*long term schedulers* that can perform this kind of scheduling. Such
schedulers were used in batch processing systems in the 1960's. Long term
scheduling decides which jobs are admitted for execution on the machine (if
there is no multitasking then only one job at a time).
This disappeared with the advent of timesharing, since jobs were submitted
interactively by the users themselves rather than from a long-term scheduler.
The issue then became how many timeshare users to admit and what priorities to
assign.
In the Linux kernel, scheduling is done in fine-grained timeslices (short term)
scheduling, not at the job level. So the ``longest job'' is a task which uses
up a full timeslice of computation. So essentially here you are looking at the
distinction between CPU versus I/O intensive tasks, rather than long or short
jobs.
Things in Linux that are roughly analogous to long term scheduling are various
ways of controlling what process to run: bash scripting, cron, make. WWW and
other servers act as schedulers too; they take job requests from clients on the
network and do them. This type of software can contain rules for prioritizing
jobs. E.g. a database server might treat a large, complex query with a lower
priority in order to remain responsive to little requests from clients.
------------------------------
From: [EMAIL PROTECTED] (J.H.M. Dassen (Ray))
Subject: Re: What distro does Linus Torvalds use?
Date: Sat, 25 Nov 2000 21:23:20 +0100
Paul Kimoto <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Michael V. Ferranti wrote:
>> Crap. Guess I'll go with Debian then.
>
>I don't think that's one he's ever been reported to use ...
AFAIK Transmeta's "Mobile Linux" is based on Debian GNU/Linux, so while it
may not have been reported, it seems reasonable to assume he's used a
Debian-based distro.
--
Ray Dassen <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Dave Platt)
Subject: Re: Modify the scheduler to manage shortest-job first
Date: Sun, 26 Nov 2000 19:25:30 -0000
>I doubt you'll find one. The problem is, how does the scheduler go about
>analyzing a program to decide how long it'll take to run? Unless I'm
>mistaken, this turns into a variation of the halting problem, for which
>no known solution exists in the general case.
It's worse than that. The halting problem is provably insoluble in
the general case. It'd be nice to have such a beast (a
general-purpose when-will-it-halt predictor), but Godel and Turing
have shown that you can't create one which will actually work in all
cases.
Probably the best popular explanation of why this is the case that
I've seen, is in Hofstadter's "Godel, Escher, Bach".
> At best, I suspect it'd
>wind up having to let each job run and see how long it took before deciding
>which one to let run, which kind of defeats the purpose.
Yeah, that tends to make the Causality Police very nervous.
The best approximation I can suggest, in the short term, would be for
the "batch" program/daemon to be enhanced, so that a person submitting
a batch job for processing could specify a set of resource limits for
the job. These limits would actually be enforced via the "ulimit"
feature when the job was submitted for processing by the "atd" daemon.
The daemon could schedule lower-resource-requirement jobs first, and
could perhaps even play around with the niceness of the job, so that
CPU-pig jobs would be forced to run at a high "nice" level.
The man page for "batch" says:
At and batch as presently implemented are not suitable
when users are competing for resources. If this is the
case for your site, you might want to consider another
batch system, such as nqs.
So, the original poster might want to take a look at the "nqs" package.
--
Dave Platt [EMAIL PROTECTED]
Visit the Jade Warrior home page: http://www.radagast.org/jade-warrior/
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!
------------------------------
From: Christopher GAUTIER <[EMAIL PROTECTED]>
Subject: How to implement a timer
Date: Sun, 26 Nov 2000 20:36:01 +0100
Hello,
I am trying to implement a server which should send informations at a
regular time, that is, it should send a packet of messages every nth
milliseconds. I don't know to code this in a regular program in C, is it
possible to use a system call ? (in Windows, there are timer callbacks
procedures). Is it possible to stop a call if it had taken too much time
? Where can I find documentation about this topic ?
Thanks in advance
------------------------------
From: Bruce Stephens <[EMAIL PROTECTED]>
Subject: Re: How to implement a timer
Date: 26 Nov 2000 19:47:37 +0000
Christopher GAUTIER <[EMAIL PROTECTED]> writes:
> I am trying to implement a server which should send informations at a
> regular time, that is, it should send a packet of messages every nth
> milliseconds. I don't know to code this in a regular program in C, is it
> possible to use a system call ? (in Windows, there are timer callbacks
> procedures). Is it possible to stop a call if it had taken too much time
> ? Where can I find documentation about this topic ?
It's in the standard C library, libc. You should have manpages (for
the specific functions) and an info manual (readable using the "info"
program or within Emacs or XEmacs).
Look up setitimer, alarm, and the handler-setting functions signal and
sigaction.
------------------------------
** 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
******************************
