Returned mail

Mail Router (MAILER-DAEMON@npvsrv1.napervilleil.NCR.COM)
26 Jul 95 20:16:17 CDT


Your mail could not be delivered because of the following reason:

----- Transcript of session follows -----
Executing: /usr/lib/mail/surrcmd/smtpqer -n -B -C -u npvsrv1.NapervilleIL.NCR.COM!ncrhub4!ncrgw1!vger.rutgers.edu!linux-kernel frsos.napervilleil.attgis.com jejb@frsos.napervilleil.attgis.com
smtpqer: Binary contents cannot be sent via SMTP
server "/usr/lib/mail/surrcmd/smtpqer" failed - unknown mailer error 1

----- Unsent message follows -----
>From ncrgw1!vger.rutgers.edu!linux-kernel Wed Jul 26 21:10 EDT 1995 remote from ncrhub4
Received: by ncrhub4.ATTGIS.COM; 26 Jul 95 21:10:01 EDT
Received: by ncrgw1.ATTGIS.COM; 26 Jul 95 21:09:50 EDT
Received: (from majordomo@localhost) by vger.rutgers.edu (8.6.12/8.6.12) id XAA29710 for linux-kernel-digest-outgoing; Sun, 23 Jul 1995 23:53:25 -0400
Date: Sun, 23 Jul 1995 23:53:25 -0400
Message-Id: <199507240353.XAA29710@vger.rutgers.edu>
From: owner-linux-kernel-digest@vger.rutgers.edu
To: linux-kernel-digest@vger.rutgers.edu
Subject: linux-kernel-digest V1 #128
Reply-To: linux-kernel@vger.rutgers.edu
Errors-To: owner-linux-kernel-digest@vger.rutgers.edu
Precedence: bulk

linux-kernel-digest Sunday, 23 July 1995 Volume 01 : Number 128

----------------------------------------------------------------------

From: "Louis-D. Dubeau" <ldd@step.polymtl.ca>
Date: Sat, 22 Jul 1995 12:30:05 -0400
Subject: Re: linux-kernel-digest V1 #123

>>>>> "RJrLm" == Rob Janssen reading Linux mailinglist <linux@pe1chl.ampr.org> writes:

RJrLm> I'm not sure what klogd is, my system currently runs only
RJrLm> syslogd. Is there an advantage to getting and running
RJrLm> klogd? (I don't have it) Note that when the disk is dead,
RJrLm> processes that are not very active and suddenly need to do
RJrLm> something stand a high chance of failure. (because they
RJrLm> have been swapped out)

klogd is supposed to handle kernel messages more cleanly than
syslogd... whatever this means.

RJrLm> I know it is against the "do it in user mode" religion, but
RJrLm> I really think that critical error message printing should
RJrLm> be done in the kernel, not in a user process that probably
RJrLm> dies with the system.

If the process dies, the syslog interface to the kernel is closed.
When this interface is closed (because of a crash or because syslogd
has not been started), error messages are just sent by the kernel to
the console. Syslogd is only an utility program that allows you to
filter and redirect those messages. The real work of creating and
sending the message is done in the kernel.

ldd

------------------------------

From: "Harik A'ttar" <harik@chaos.rutgers.edu>
Date: Fri, 21 Jul 1995 21:31:55 -0400 (EDT)
Subject: Re: 3rd/4th.. IDE ports

On Thu, 20 Jul 1995, mark (m.s.) lord wrote:

> That's how it is being implemented.. command line parms for all
> IDE ports, probing is done only for the primary/secondary at the
> "standard" ports.

Hmm... Where is a list of commandline params? I recently
had to specify the parameters for someone's HD, finally
found the information in the LILO configs. Then, they had
an ethernet card on a strange address (SMC Ultra on 360, it tests
340, 380... not good) And even though I went in all the core
setup files, I couldn't figure out what the heck to send it.
(and when I did, it was ignored.. suprise?)

Changing parametrs like addresses w/o a recompile is a _GOOD_ thing,
but it is the devil itself to find an actual list of what commands
are supported.

I remember this being discussed a month or so ago, but that degraded
into another mount root ro or rw debate. ack!

#include <stupid/signature>
chaos@dynamic.ip.don't.reply Guess what? I really _DO_ speak for my
Dan Merillat / Harik A'ttar system. And if you share my opinions,
in00621@pegasus.cc.ucf.edu you should seek professional help.

------------------------------

From: Michael Nelson <mikenel@netcom.com>
Date: Sat, 22 Jul 1995 13:02:45 -0700 (PDT)
Subject: init/main.c

Is there any reason that the 200 lines worth of function definitions and
structure definitions for drivers in init/main.c couldn't be moved
into another source file -- such as init/config.c?

Moreover, what would be really slick (for those who are working on a new
configuration system) is to automatically generate a config.c which would
invoke the init procedures for the appropriate drivers.

I don't have Linux installed (other than the sources) right now -- but if
it is felt to be beneficial -- I might take a stab at it...

Comments?

- -- Mike

- --
Michael Nelson (mikenel@netcom.com) | Real programmers don't comment their
Rockville, Maryland | code. It was hard to write, it should
BSD/OS, WinNT, OLE2 Development | be hard to understand.

------------------------------

From: Michael Nelson <mikenel@netcom.com>
Date: Sat, 22 Jul 1995 12:55:17 -0700 (PDT)
Subject: Re: kernel config

On Fri, 21 Jul 1995, Roland Dunkerley wrote:

> Proper documentation would be nice. Man pages for kernel internal
> functions would be really nice. Probably wouldn't take too long to
> have most of the major ones if someone were to volunteer to collect
> the kernel-man pages and ask people to write just one. I'm too busy
> lately myself to collect them, but I'd be willing to write a page or
> two. The current configuration doesn't bother me too much. I hate it

This would be great -- especially for fledgling kernel developers... I am
currently in the process of figuring out how the kernel all fits together
- -- and spend most of my time tracking down procedures/macros/etc... and
then deciphering what they mean.

Unfortunately, some of the procedure names are ambigious, which makes it
hard (at first) to figure out what they do. Sure, they mean something to
current developers -- but they don't mean much who haven't really worked
with the kernel.

- -- Mike

- --
Michael Nelson (mikenel@netcom.com) | Real programmers don't comment their
Rockville, Maryland | code. It was hard to write, it should
BSD/OS, WinNT, OLE2 Development | be hard to understand.

------------------------------

From: scott snyder <SNYDER@D0SB10.FNAL.GOV>
Date: Sat, 22 Jul 1995 22:15:10 -0500 (CDT)
Subject: Re: Sanyo CDR C3 G

>I have a Sanyo 3 Disk changer in my Gateway P5-120 machine, 2940
>Controller, ATI Mach64/2Meg VRAM and have been working to get access to
>the drive.
>...
> Is there any way to access the other two
>platters with the current drivers, or will there have to be a specialized
>driver developed for this CDROM Drive ?

With the present driver, i don't think there's any way to make it use
the other platters. I've noticed some cd changer commands in v2 of the
atapi spec, but i haven't looked at in in detail. Since i don't have
access to one of these drives myself, i'm not likely to implement this
any time soon; however, i'd be happy to receive changes to support it
from someone who does have such a device.

sss

------------------------------

From: Michael Nelson <mikenel@netcom.com>
Date: Sat, 22 Jul 1995 16:03:22 -0700 (PDT)
Subject: Kernel questions...

I have few kernel-related questions...

1) Are there any particular caveats when using kmalloc (i.e. allocs must
be in 4k pages, kmallocs must be < n bytes, etc...). How does it
different from vmalloc (pageable memory?)

2) Does task[0] exist as a user or kernel mode process?

3) With regards to executables: Can someone explain brk and bss? I
vaguely understand that the former has something to do with limits on
data segments, but that's it.

4) How do user mode programs allocate memory? I don't have libc handy,
but I haven't noticed that there is any sort of "malloc" system call...

Thanks.

- -- Mike

- --
Michael Nelson (mikenel@netcom.com) | Real programmers don't comment their
Rockville, Maryland | code. It was hard to write, it should
BSD/OS, WinNT, OLE2 Development | be hard to understand.

------------------------------

From: cjs <noone@nowhere.com>
Date: Sat, 22 Jul 1995 12:53:34 -0500 (CDT)
Subject: Re: Benchmarks - 1.3.11

> Hmm, I wouldn't call a 59.77% change 'minute.' In general, I have discounted
> anything that is less than 1% change as being noise. Probably impacted by

If you look again, you'll find that most of the numbers are +/- 1.5%
or less. I don't think it requires a great leap of faith to grasp what
I was trying to say. The 59.77% you sight is thethe exception, not the
rule.

The big problem is that a lot of the time are no kernel changes that
would effect whats being timed -- so we have to figure that those +/-
1.5% are just error margins of the tests and are in no way
significant.

Chrisotpher

------------------------------

From: linux@pe1chl.ampr.org (Rob Janssen reading Linux mailinglist)
Date: Sat, 22 Jul 1995 23:29:25 +0200 (MET DST)
Subject: Re: linux-kernel-digest V1 #124

According to owner-linux-kernel-digest@vger.rutgers.edu:
> From: friebe@xvnews.unconfigured.domain (Bernhard Friebe Student (SV S.N J.L))
> Date: 19 Jul 1995 15:34:58 GMT
> Subject: 16-bit read/write operations on ISA bus
>
> Hi folks,
>
> I'm new to this newsgroup (and Linux), and not shure if this question really belongs here, but anyway here it comes:
>
> I am trying to comunicate with a custom pc board with help of the linux provided
> device /dev/port and the open/write/read operations. However these are 8-bits (char) only (that's what I think) and I need to perform 16-bit operations.
>
> I'm aware that there are existing operations like outb, inb, ... for direct ISA-bus
> comunication, but unfortunately I have no information which file I have to include
> in my C source or in which files these operations are defined (if I include io.h,
> where a definition of inb, outb, ... is given, the internal functions __outb, __inb, ... are unknown on compilation).
>
> I'm aware that this is a really unprecise question, but I would be very happy if
> anyone could give me some help.

One thing that is unclear to many users of inb/outb/etc is that you need
to compile with -O2 (optimization) to force GCC to expand the inline
functions __outb etc. If you don't, they will be undefined.
(I think there is also a specific flag to enable only this expansion and
don't do optimization. see the GCC docs)

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: dholland@husc.harvard.edu
Date: Sat, 22 Jul 1995 18:00:31 -0400 (EDT)
Subject: Re: kernel config

> :> And what format shall this take? It needs to be parsable from
> :> sh using only expr, sed, and awk.
>
> Only if not a single kernel hacker understands lex/yacc well enough to
> write a parser to do the necessary Makefile/header configuration.
> Seriously, why would it need to be parsable from sh at all? Can
> include a flex/bison grammar (pre flexed/bisoned even, though I doubt
> this would at all be necessary, I would guess that flex and bison are
> much more ubiquitous on machines with development tools installed than
> perl would be.) with the rest of the kernel sources, that would get
> built with make config. The sound driver already has a configure
> program written in C.

I'd be happy to write it, and make the syntax as complicated as anyone
wants, but I refuse to do it using lex and yacc.

Since the only free parser generators around are basically yacc, and I
doubt a non-free solution would be welcomed in the kernel, I'll have
to stay out of it except for suggestions and kibitzing.

That said, how about something along the lines of

config file ::= section...

section
::= identifier, doc-string, flag..., '{', config option... '}'

flag
::= "require", identifier
::= "provide", identifier
::= "cflags", quoted string
::= "module"

config option
::= typename, identifier, doc-string, flag..., ';'

typename
::= "bool"
::= "int"
::= "int", constant, "..", constant

doc-string ::= quoted string

where identifier, constant, and quoted string are what you'd expect.

If anyone tries to build this, note that identifiers can't begin with
a digit or you'll get a conflict.

This lets you, for instance, specify that SCSI tape support requires
SCSI support, in the following way:

scsi-adapters "Support for SCSI host adapters (disk/device
controllers). This is required if you want support for other SCSI
devices (hard disks, tapes, cdroms, scanners)."
{
aha1542 "Support for Adaptec 1542 SCSI cards."
provide scsi cflags "-DCONFIG_AHA_1542";
aic7xxx "Support for Adaptec 274x/284x/294x SCSI cards."
provide scsi cflags "-DCONFIG_AIC7XXX";
ABCDE "Support for the A.B.C.D.E. Super SCSI 1998 Edition."
provide scsi cflags "-DCONFIG_ABCDE";
}

scsi-devices "Support for SCSI devices (hard drives, tapes, cdroms,
scanners, etc.) Support for SCSI host adapters is required."
{
tapes "Support SCSI tape drives."
require scsi provide tape cflags "-DCONFIG_SCSI_TAPE";
disks "Support SCSI hard drives."
require scsi provide disk cflags "-DCONFIG_SCSI_DISK";
cdrom "Support SCSI cdroms."
require scsi provide cdrom cflags "-DCONFIG_SCSI_CDROM";
}

etc.

The idea is that you can select the adapters section all you like, but
unless you actually choose a controller, it won't let you turn on any
of the scsi devices.

Hmm. Thinking about it there ought to be an option "suggest". For
instance, since iso9660 support isn't useful without a cdrom, you'd
have "suggest cdrom", and you'd have the cdroms "suggest iso9660".
Presumably the config utility would do something intelligent with
"suggest" operations that were references to things the user hadn't
gotten to yet.

> :> Maybe. I'm not convinced the configuration is that badly
> :> broken. Proper documentation of the sources is more important,
> :> in my opinion. ;-)
>
> Proper documentation would be nice. Man pages for kernel internal
> functions would be really nice. Probably wouldn't take too long to
> have most of the major ones if someone were to volunteer to collect
> the kernel-man pages and ask people to write just one.

There's already somebody who maintains the man-pages package; I'm sure
if people sent him section 9 man pages he'd be willing to include
them. (I don't remember who it is though.)

> I'm too busy lately myself to collect them, but I'd be willing to
> write a page or two.

Same here.

> The current configuration doesn't bother me too much. I hate it
> when I have to start all over or go manually edit the files when I
> flub a single one up though. So I think some improvement could be
> achieved in that area, just don't think it is the most important
> thing happening with linux right now.

Right.

> NSA: plutonium Mossad NSA Panama Croatian Qaddafi domestic disruption
> munitions Noriega jihad Honduras NORAD genetic DES [Hello to all my
> fans in domestic surveillance]

That's not good enough - I'm sure they have better text retrieval
systems than that. :-p

- --
- David A. Holland | Peer pressure (n.): The force from the
dholland@husc.harvard.edu | eyeballs of everybody watching you.

------------------------------

From: miquels@drinkel.ow.org (Miquel van Smoorenburg)
Date: Sat, 22 Jul 1995 14:04:10 +0200 (MET DST)
Subject: Re: Patches for serial console available

In article <199507201321.PAA21549@lrcsun1.epfl.ch>,
Werner Almesberger <almesber@lrc.epfl.ch> wrote:
>Miquel van Smoorenburg wrote:
>> I've hacked up serial console support for Linux 1.3.10.
>> The diffs are pretty big (17k)
>
>Argl. I knew there was a reason why I didn't want to merge my serial
>consoles with the tty driver ;-)
>
>For your amusement, I've attached my 1638 bytes patch (should work with
>most recent kernels).

[patches deleted]

Okay, your patches are smaller. But mine do some things yours don't:

- - supports /dev/console
- - initializes UART speed. I know LILO already lets the BIOS do this at
boot time, but what if you don't boot through LILO ? (bootfloppy)
- - Turns off 16550 FIFO mode before it prints and turns it on
afterwards if needed.
- - Has a nice serial kernel monitor built in :)

Just depends on what you want, really.

Mike.
- --
+ Miquel van Smoorenburg + Cistron Internet Services + Living is a |
| miquels@cistron.nl | Independent Dutch ISP | horizontal |
+ miquels@drinkel.ow.org + http://www.cistron.nl/ + fall +

------------------------------

From: Michael Nelson <mikenel@netcom.com>
Date: Sat, 22 Jul 1995 20:58:01 -0700 (PDT)
Subject: i386 switch_to() question...

(I will be looking for 386 books tomorrow<g>)

[snip]

#define switch_to(tsk) do { \
__asm__("cli\n\t" \
"xchgl %%ecx,_current\n\t" \
"ljmp %0\n\t" \
"sti\n\t" \
"cmpl %%ecx,_last_task_used_math\n\t" \
"jne 1f\n\t" \
"clts\n" \
"1:" \
: /* no output */ \
:"m" (*(((char *)&tsk->tss.tr)-4)), \
"c" (tsk) \
:"cx"); \

[etc...]

I am thrououghly confused as to why the kernel is "ljmp"ing to (tss.tr)-4
(if I am interpreting this correctly).

1) Where is it going?
2) What is "tr"? My first guess was "task register" -- but I am just
confused now.

I have been trying to compare Linux's switch to the 4.4BSD-Lite (BSDI)
switch to try to understand what is going on -- but they are radically
different (BSD's is a lot more involved).

- -- Mike

- --
Michael Nelson (mikenel@netcom.com) | Real programmers don't comment their
Rockville, Maryland | code. It was hard to write, it should
BSD/OS, WinNT, OLE2 Development | be hard to understand.

------------------------------

From: "Harik A'ttar" <harik@chaos.rutgers.edu>
Date: Fri, 21 Jul 1995 21:58:46 -0400 (EDT)
Subject: Re: Benchmarks - 1.3.11

On Thu, 20 Jul 1995, cjs wrote:

> > On Thu, 20 Jul 1995, cjs wrote:
> >
> > > > *******
> > > > Results
> > > > *******
> > > >
> > > > Pipe-based Context Switching Test || 3007.4 -> 4804.9 +59.77%
> > > > Pipe Throughput Test || 18574.4 -> 18774.0 +1.07%
> > > > Execl Throughput Test || 60.9 -> 61.4 +0.82%
> > > [stuff deleted]
> > >
>
> Sounds to me like you are making an good effort to have simular
> testing conditions every time. =)

For a non-official benchmark, thats pretty damm good. Even
cleaner then my compile tests-- I may shutdown unneded proci, but
I don't clean reboot for a compile (even though I _DO_ time it. bah)

>
> > Each test is run 20 times (10 for the most time-consuming). If I find the
> > time, I will add the calculation of the standard deviation.
>
> I would be interested in seeing that. Its all fine and well to say
> that task switching times or something has increased + or - 0.82% over
> the previous version, however when there haven't been any changes that
> could make a difference in such a thing, then you have to figre that
> you are actually detecting something else.

Taking the above oft-quoted numbers, pipe-based context switching
went up by ~60%. Changes in other numbers _WILL_ occur, simply because
the kernel has changed. Things are different. the .0x% changes in the
timings would be best described as the secondary effects of the major
patches. Even one extra clause in the task switcher.... (shiver)
how many times would that be evoked? How about tossing an extra
line of code into the tty driver? Or the memory managment?
Would that not affect the execution of floating point math? It would,
if only by 1% or so. The 20 (or 10) run testing eliminates most of the
noise (50-100 would be better, but, as he said, it allready runs 4 hours)

On the same idea, Is it possible that you could nuke the results
of tests that are < 2% (a good number) simply because most changes
of .02% Don't affect anyone. Full figures on request or something,
but noise level changes are just eating bandwidth.

BTW: Earlier tests had a lot of HUGE negative %s, like -50 or -200%
any comments? Changes that big on the - side should have evoked some
reaction :) I'll go hunting through old mail sometime today or
tomorrow to see if I can find what specific things changed.

Anyway, Thanks for the numbers (Hey, I don't have to get locked
out of MY system for 4-5 hours! Thanks!)

chaos@dynamic.ip.don't.reply Guess what? I really _DO_ speak for my
Dan Merillat / Harik A'ttar system. And if you share my opinions,
in00621@pegasus.cc.ucf.edu you should seek professional help.

------------------------------

From: "W. Bryan Thrasher" <thrasher@mindspring.com>
Date: Sun, 23 Jul 1995 10:03:49 -29900
Subject: Re: kernel config

On Fri, 21 Jul 1995, Roland Dunkerley wrote:

> Proper documentation would be nice. Man pages for kernel internal
> functions would be really nice. Probably wouldn't take too long to
> have most of the major ones if someone were to volunteer to collect
> the kernel-man pages and ask people to write just one. I'm too busy

I'm your volunteer. I am relatively new to Linux development, but think
I could handle assembling the man pages. So, to anyone interested in
writing one, please let me know. I will assume that in the case of
developing apps where different people are working on different
functions, there is some existing method for posting items that are
needed and letting people know what's not. Since I haven't been involved
in such a development, I'm not aware of that method. If someone could
fill me in, I'd appreciate it. From my own thoughts, I could post needs,
haves, and completed files on my web page:
(http://www.mindspring.com/~thrasher)

Thanks,
Bryan Thrasher

------------------------------

From: Jaakko Hyvatti <Jaakko.Hyvatti@www.fi>
Date: Sun, 23 Jul 1995 17:09:38 +0200 (EET DST)
Subject: Re: Benchmarks - 1.3.11

Anyone doing this kind of performance analysis should read Jain,
Raj: The art of computer systems performance analysis: techniques for
experimental design, measurement, simulation, and modelling (1991),
chapter 13: Comparing systems using sample data. Or something similar.

`The basic idea is that a definitive statement cannot be made about
the characteristics of all systems, but a propabilistic statement
about the range in which the characteristics of most systems would lie
can be made. The concept of confidence intervals introduced in this
chapter is one of the fundamental concepts that every performance
analyst needs to understand well. In the remainder of this book, most
conclusions drawn from samples are stated interms of confidence
intervals.' - Raj Jain.

Earlier in the book he mentions some pitfalls of perf.analysis,
one of which is not doing enough analysis after collecting data.

I will now take some time to explain what should be done with the
analysis of these kernel benchmarks. Someone with greater
understanding of performance analysis and statistics: please correct
me if I got it wrong.

In 13.4.2 comparing unpaired observations is explained. This is what
we are doing, as we have two sets of nA=nB=20 (or 10) observations
xA[0..19] and xB[0..19] for two different kernel releases A and B.
The steps of the so called t-test are:

1. compute the sample means meanA = sum(xA)/nA and meanB..
2. compute the sample standard deviations:
sA = sqrt((sum(xA**2)-nA*(meanA**2))/nA-1) and sB similarily.
3. compute the mean difference meanA-meanB
4. compute the standard deviation of the mean difference:
s = sqrt(sA**2/nA + sB**2/nB)
5. compute the effective number of degrees of freedom: (this gets tricky)
v = (sA**2/nA + sB**2/nB)/(sA**4/nA**2/(nA+1) + sB**4/nB**2/(nB+1)) - 2
6. compute the confidence interval for the mean difference.
That is, look at the table for a value for t=t[1-alpha/2,v],
where 1-alpha/2 is 0.95 for 90% confidence level etc.
Then the conf.interval is: (meanA-meanB) +- t*s.
7. If the confidence interval includes zero, the difference is not
significant at 100*(1-alpha) % confidence level. If the zero is
not included, the system with better mean value is better.

The alpha parameter above says how much uncertainty we can tolerate
when we want to see if the difference is significant. 0.1 or 0.05 are
commonly used for 90% and 95% confidence levels, but this does not say
what should we use. I do not know.

Now you only need some t[]-tables. You should find one in any book
of statistics.

Be careful out there, statistics is dangerous.
- --
#Jaakko Hyvdtti Jaakko.Hyvatti@WWW.FI http://www.fi/~jaakko/ +358 40 5011222
echo 'movl $36,%eax;int $128;movl $0,%ebx;movl $1,%eax;int $128'|as -o/bin/sync

------------------------------

From: Robin Cutshaw <robin@intercore.com>
Date: Sun, 23 Jul 1995 11:09:49 -0400 (EDT)
Subject: Re: Crashing Problems

>
> I am running kernel 1.3.11, and am having system lockup problems. It

I've noticed that after upgrading from 1.2.8 to 1.2.11 that the system
will periodically lock up after running a few hours.

robin

------------------------------

From: Eric Bosch <ecbosch@tyrell.net>
Date: Sun, 23 Jul 1995 11:22:26 -0500 (CDT)
Subject: 1.3.11 Kernel Crashes

As I reported in a previous message, I had been having hard system
crashes while attempting to backup my system. I made some changes in my
AHA2940 controller config, ie I disabled disconnection for all devices,
and did succesfully get through the backup. However I then ran X and ran
Seyon for a dialout, and upon exit from X, the system froze again. I
feel this may be pointing to 1) Disconnect/Reconnect code problem in
AIC7xxx code, and possibly a memory leak (Just a gut feeling) somewhere
in the kernel.

------------------------------

From: dholland@husc.harvard.edu
Date: Sun, 23 Jul 1995 12:47:53 -0400 (EDT)
Subject: Re: Benchmarks - 1.3.11

> > Each test is run 20 times (10 for the most time-consuming). If I find the
> > time, I will add the calculation of the standard deviation.
>
> I would be interested in seeing that. Its all fine and well to say
> that task switching times or something has increased + or - 0.82% over
> the previous version, however when there haven't been any changes that
> could make a difference in such a thing, then you have to figre that
> you are actually detecting something else.

Any change can make a small difference in just about anything. Suppose
somebody added three lines of code to the SCSI driver, and this (by
being slightly larger) caused the task-switch code to lie across a
page boundary. Presto! A few more cycles every task-switch, probably,
and perhaps a 1% drop in switching performance.

Don't underestimate the effects of things like that.

- --
- David A. Holland | Peer pressure (n.): The force from the
dholland@husc.harvard.edu | eyeballs of everybody watching you.

------------------------------

From: Linus Torvalds <Linus.Torvalds@cs.Helsinki.FI>
Date: Sun, 23 Jul 1995 19:59:45 +0300
Subject: Re: goto

Tommy Thorn: "goto" (Jul 21, 16:22):
> Linus Torvalds wrote/ecrit/skrev:
> | + *
> | + * The goto is "interesting".
> | *
> ......
> | + 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:
> | + }
>
> I suppose this is the Linus Torvalds version of Fermats Last Theorem :-)
> (Leaving people wondering "why" for hundreds of years...)

Nothing strange about this at all: look at the assembly code this
generates, and you'll find that this is a good way to make gcc do better
machine code. I could have used more "goto" statements to get _exactly_
what I wanted, but this mixture of a switch and a goto gets rather good
results.

Now, looking at the code, you can obviously replace the goto statement
with the cleaner (?) "{ current->state = TASK_RUNNING; break; }". Now,
use "make kernel/sched.s" to find out what assembly code this results
in, and you'll notice that by using the goto we avoid one jump for the
common case and use some shared code instead.

(I _like_ using goto's every once in a while: it can often mess up the
gcc optimizer just enough to get better code out of it. In this case,
as the signal test is not usually true, the goto forces gcc to use
better jump placement and avoid the branch in the usual case).

As to whether it reall matters: no, it doesn't. The largest reason I do
this once in a while is that I look at the assembly gcc produces for
quite other reasons, and use a goto to make it slightly easier to read
(not the C code, the assembly ;-)

Linus

------------------------------

From: "Gregory L. Galloway" <gregg@localhost.gtri.gatech.edu>
Date: Sun, 23 Jul 1995 13:07:47 -0400
Subject: Null derefence in 1.3.9

I switched from 1.2.8 to 1.3.9 to get support for my GCD-R540 ATAPI CDROM.
The next day my machine locked up twice with the following message:

Jul 21 19:52:40 mu-shu kernel: Unable to handle kernel NULL pointer dereference
at virtual address c0000000
Jul 21 19:52:40 mu-shu kernel: current->tss.cr3 = 0040c000, nr3 = 0040c000
Jul 21 19:52:40 mu-shu kernel: *pde = 00102067
Jul 21 19:52:40 mu-shu kernel: *pte = 00000027
Jul 21 19:52:40 mu-shu kernel: Oops: 0000
Jul 21 19:52:40 mu-shu kernel: EIP: 0010:00112e23
Jul 21 19:52:40 mu-shu kernel: EFLAGS: 00013202
Jul 21 19:52:40 mu-shu kernel: eax: 00000000 ebx: 00000004 ecx: 001cda2c e
dx: 0000b000
Jul 21 19:52:40 mu-shu kernel: esi: 003bf2e8 edi: 00286000 ebp: 0026efa0 e
sp: 0026ef90
Jul 21 19:52:40 mu-shu kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0
018
Jul 21 19:52:40 mu-shu kernel: Process X (pid: 2908, process nr: 14, stackpage=0
026e000)
Jul 21 19:52:40 mu-shu kernel: Stack: 0026efbc 003bf2e8 003bf2e4 0025cb10 bffff8
2c 0010d3ce 00000000 0026efbc
Jul 21 19:52:40 mu-shu kernel: 0010c116 00000000 0026efbc 00383900 000000
04 00222474 003bf2e8 003bf2e4
Jul 21 19:52:40 mu-shu kernel: bffff82c 00143570 ffff002b 0010002b 001000
2b 0000002b fffffffe 0013db47
Jul 21 19:52:40 mu-shu kernel: Call Trace: 0010d3ce 0010c116 00143570 0013db47
Jul 21 19:52:40 mu-shu kernel: Code: 00 00 19 c0 83 c1 08 01 db 75 d6 fa ff 05 a
4 13 1b 00 a1 a4
Jul 21 19:52:40 mu-shu kernel: Aiee, killing interrupt handler

Here is the EIP info from vmlinux:

001128b4 t _timer_bh
00112954 T _tqueue_bh
001129a4 T _immediate_bh
001129f4 t _do_timer
00112e94 T _sys_alarm
00112ee4 T _sys_getpid
00112f04 T _sys_getppid
00112f24 T _sys_getuid
00112f44 T _sys_geteuid

More information can be provided if needed,

Greg
- ----
Gregory L. Galloway E-mail: greg.galloway@gtri.gatech.edu
Research Scientist I Mail: Georgia Institute of Technology
GTRI / EOEML / Baker 247
Voice: +1 404 853-3076 Atlanta, Georgia 30332-0834
Fax: +1 404 894-6285 WWW: http://eoeml-www.gtri.gatech.edu/~gregg/

------------------------------

From: Bernie Doehner <bad@ee.WPI.EDU>
Date: Sun, 23 Jul 1995 12:25:15 -0500 (EDT)
Subject: Console/getty handling bug

Since I upgraded from kernel 1.2.3 to 1.2.11, I noticed a bug
with the way getty's (I use agetty) are handled. I run two Linux systems:
One is a 386 with 5MB of RAM and NO monitor (my ax25 router and nfs print/
fileserver) The other is a 486 notebook with 8MB of RAM (my "user" machine).

Since the 386 is tight on memory and has no monitor, I disabled all getty's
from running on it (not even on on the serial port).

With kernel version 1.2.11 and beyond (I even tried 1.3.11), whenever NO
gettys are running on the system, and one logs in via the ethernet network
"init" ends up running all the time and grabs
roughly 80-90% of system cpu time, even while the system is idle
To make sure this wasn't related to something on my
386, I also disabled all gettys on my 486 and logged in via the network
and noticed the same "init" behavior. This strange init behavior
immediately goes away when I edit /etc/inittab, and kill -1 1 to start at
least one getty.

I definitely did NOT see this happen in kernel 1.2.3 and before, and I don't
even know where to try to find the source. I can tell you what is not
the problem. Here is a summary of some of the software differences between the
two machines:

386: 486:
- -3c503 network card -maxtech pcmcia (ne2000 compat) network card
- -Kernel 1.2.11 with Alan Cox's -straight kernel 1.2.11 without ANY patches
ax25028 patches
- -No modules of any kind -pcmcia card services and modules

>From information in /usr/adm/messages it seems that whenever a command is
executed init starts forking uncontrolably.

I even disabled all of my nfs and other network stuff to see wether any of
the network stuff was causing this and it had NO effect on init's behavior.

Here are the /usr/adm/messages and top outputs for the case when the 386
has been idle for a while and has NOT getty's of any kind running:

Jul 23 10:17:23 zeus syslogd: restart
Jul 23 10:17:24 zeus kernel: Kernel logging (proc) started.
Jul 23 10:17:24 zeus kernel: Console: mono EGA+ 80x25, 1 virtual console (max 63)
Jul 23 10:17:24 zeus kernel: Calibrating delay loop.. ok - 6.50 BogoMips
Jul 23 10:17:24 zeus kernel: Serial driver version 4.11 with no serial options enabled
Jul 23 10:17:24 zeus kernel: tty00 at 0x03f8 (irq = 4) is a 16450
Jul 23 10:17:24 zeus kernel: tty01 at 0x02f8 (irq = 3) is a 16450
Jul 23 10:17:24 zeus kernel: lp1 at 0x0378, using polling driver
Jul 23 10:17:24 zeus kernel: hda: WDC AC1210F, 202MB w/64KB Cache, CHS=989/12/35, MaxMult=16
Jul 23 10:17:24 zeus kernel: ide0: primary interface on irq 14
Jul 23 10:17:24 zeus kernel: Floppy drive(s): fd0 is 1.44M, fd1 is 1.2M
Jul 23 10:17:24 zeus kernel: FDC 0 is a 8272A
Jul 23 10:17:24 zeus kernel: Memory: 4240k/5376k available (572k kernel code, 384k reserved, 180k data)
Jul 23 10:17:24 zeus kernel: Swansea University Computer Society NET3.019
Jul 23 10:17:24 zeus kernel: GW4PTS AX.25 for Linux. Version 0.25 ALPHA for Linux NET3.016 (Linux 1.1.51)
Jul 23 10:17:24 zeus kernel: Portions (c) Copyright 1984 University Of British Columbia
Jul 23 10:17:24 zeus kernel: Portions (c) Copyright 1990 The Regents of the University Of California
Jul 23 10:17:24 zeus kernel: Swansea University Computer Society TCP/IP for NET3.019
Jul 23 10:17:24 zeus kernel: IP Protocols: ICMP, UDP, TCP
Jul 23 10:17:24 zeus kernel: PPP: version 0.2.7 (4 channels) NEW_TTY_DRIVERS OPTIMIZE_FLAGS
Jul 23 10:17:24 zeus kernel: TCP compression code copyright 1989 Regents of the University of California
Jul 23 10:17:24 zeus kernel: PPP line discipline registered.
Jul 23 10:17:24 zeus kernel: SLIP: version 0.8.3-NET3.019-NEWTTY (4 channels) (6 bit encapsulation enabled)
Jul 23 10:17:24 zeus kernel: AX25: KISS encapsulation enabled
Jul 23 10:17:24 zeus kernel: 3c503.c:v1.10 9/23/93 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Jul 23 10:17:24 zeus kernel: eth0: 3c503 at 0x300, 02 60 8c 3e 5c d3
Jul 23 10:17:24 zeus kernel: eth0: 3C503 with shared memory at 0xdc000-0xddfff,
Jul 23 10:17:24 zeus kernel: Checking 386/387 coupling... Ok, fpu using old IRQ13 error reporting
Jul 23 10:17:24 zeus kernel: Checking 'hlt' instruction... Ok.
Jul 23 10:17:24 zeus kernel: Linux version 1.2.11 (root@flint) (gcc version 2.6.3) #1 Fri Jul 21 14:43:17 EDT 1995
Jul 23 10:17:24 zeus kernel: Partition check:
Jul 23 10:17:24 zeus kernel: hda: hda1 hda2
Jul 23 10:17:24 zeus kernel: VFS: Mounted root (ext2 filesystem) readonly.
Jul 23 10:17:24 zeus kernel: Adding Swap: 8604k swap-space
Jul 23 10:17:28 zeus sendmail[57]: starting daemon (8.6.12): SMTP+queueing@00:10:00
Jul 23 10:17:29 zeus init[1]: No more processes left in this runlevel
Jul 23 10:17:45 zeus last message repeated 482 times
Jul 23 10:17:45 zeus in.telnetd[62]: connect from flint.nu1s.ampr.org
Jul 23 10:17:45 zeus init[1]: No more processes left in this runlevel
Jul 23 10:17:49 zeus last message repeated 84 times
Jul 23 10:17:49 zeus login: ROOT LOGIN ON ttyp0 FROM flint.nu1s.ampr.org
Jul 23 10:17:49 zeus init[1]: No more processes left in this runlevel
Jul 23 10:18:20 zeus last message repeated 733 times
Jul 23 10:19:21 zeus last message repeated 1581 times
Jul 23 10:20:22 zeus last message repeated 1581 times
Jul 23 10:21:22 zeus last message repeated 1581 times
Jul 23 10:22:23 zeus last message repeated 1568 times
Jul 23 10:23:23 zeus last message repeated 1556 times
Jul 23 10:24:23 zeus last message repeated 1556 times
Jul 23 10:25:23 zeus last message repeated 1556 times
Jul 23 10:26:23 zeus last message repeated 1556 times
Jul 23 10:27:23 zeus last message repeated 1556 times
Jul 23 10:28:23 zeus last message repeated 1554 times
Jul 23 10:29:23 zeus last message repeated 1543 times
Jul 23 10:30:23 zeus last message repeated 1483 times
Jul 23 10:31:23 zeus last message repeated 1505 times
Jul 23 10:32:23 zeus last message repeated 1503 times
Jul 23 10:33:23 zeus last message repeated 1506 times
Jul 23 10:34:23 zeus last message repeated 1506 times
Jul 23 10:35:24 zeus last message repeated 1506 times
Jul 23 10:36:24 zeus last message repeated 1504 times
Jul 23 10:37:24 zeus last message repeated 1504 times
Jul 23 10:38:24 zeus last message repeated 1502 times
Jul 23 10:39:24 zeus last message repeated 1504 times
Jul 23 10:40:24 zeus last message repeated 1504 times
Jul 23 10:41:24 zeus last message repeated 1504 times
Jul 23 10:42:24 zeus last message repeated 1504 times
Jul 23 10:43:24 zeus last message repeated 1504 times
Jul 23 10:44:24 zeus last message repeated 1504 times
Jul 23 10:45:24 zeus last message repeated 1504 times
Jul 23 10:46:24 zeus last message repeated 1504 times

10:56am up 39 min, 1 user, load average: 1.16, 1.11, 0.97
15 processes: 13 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 16.2% user, 0.0% nice, 94.5% system, 0.0% idle
Mem: 4236K av, 4108K used, 128K free, 2408K shrd, 1580K buff
Swap: 8604K av, 0K used, 8604K free

PID USER PRI NI SIZE RES SHRD STAT %CPU %MEM TIME COMMAND
1 root 30 0 55 236 304 S 83.0 5.5 33:53 init auto
77 root 21 0 156 408 428 R 17.1 9.6 0:00 top
38 root 6 0 65 272 332 R 10.5 6.4 4:45 /usr/sbin/syslogd
62 root 1 0 90 312 356 S 0.0 7.3 0:00 in.telnetd
63 root 1 0 348 520 484 S 0.0 12.2 0:01 -tcsh
57 root 1 0 255 440 456 S 0.0 10.3 0:00 sendmail: accepting
6 root 1 0 4 8 0 S 0.0 0.1 0:00 /sbin/bdflushd
7 root 1 0 4 8 0 S 0.0 0.1 0:00 /sbin/updated
40 root 1 0 40 236 312 S 0.0 5.5 0:00 /usr/sbin/klogd
42 bin 1 0 84 248 312 S 0.0 5.8 0:00 /usr/sbin/rpc.portmap
44 root 1 0 76 268 320 S 0.0 6.3 0:00 /usr/sbin/inetd
46 root 1 0 64 232 296 S 0.0 5.4 0:00 /usr/sbin/lpd
49 root 1 0 100 340 400 S 0.0 8.0 0:00 /usr/sbin/rpc.mountd
51 root 1 0 116 344 404 S 0.0 8.1 0:00 /usr/sbin/rpc.nfsd
53 root 1 0 96 264 356 S 0.0 6.2 0:00 /etc/rpc.pcnfsd /var

I 'd be interrested to see if anyone else can duplicated the above behavior.
Please also let me know if you need additional information.

Regards,

Bernie Doehner
bad@ee.wpi.edu

------------------------------

End of linux-kernel-digest V1 #128
**********************************