In this issue:
Re: R: Do not use stock RedHat 6.0 kernels with SMBFS! [OFF-TOPIC]
[PPC] ext2 filesytem corruption on linux 2.2.9 PowerPC
Re: Profanity in the Linux Kernel?!?!?
Re: R: Do not use stock RedHat 6.0 kernels with SMBFS! [OFF-TOPIC]
Re: pre2.3.6-2 PAGE_OFFSET_RAW & pcmcia
Re: generalizing khttpd
Re: Profanity in the Linux Kernel?!?!?
Re: ICMP in 2.2.9 (was 3c575)
Re: generalizing khttpd
Re: Profanity in the Linux Kernel?!?!?
Improving capabilities support: need your opinion
Re: generalizing khttpd
Re: NR_TASKS as config option.
Re: init failing in 2.3.6
Re: init failing in 2.3.6
Re: SPARCstation's power led goes off upon kernel init
Re: 2.3.6 (mmap fails)
Re: Profanity in the Linux Kernel?!?!?
Re: generalizing khttpd
Re: Profanity in the Linux Kernel?!?!?
Re: Yamaha Opl3-Sa3 problems...
Re: New schedule() and semaphore implementation ...
Re: New semaphore __wake_up() implementation ...
0E is a stack fault?? (Was RE: Profanity in the Linux Kernel?!?! ? )
Re: ICMP in 2.2.9 (was 3c575)
Re: Improving capabilities support: need your opinion
Re: New semaphore __wake_up() implementation ...
Re: Profanity in the Linux Kernel?!?!?
[PATCH RFC] 2.3.6 nfs & sunrpc modules won't load.
Re: 2.3.6 (mmap fails)
Re: New schedule() and semaphore implementation ...
Re: ICMP in 2.2.9 (was 3c575)
Re: Profanity in the Linux Kernel?!?!?
Re: PIII.patch
Re: New semaphore __wake_up() implementation ...
See the end of the digest for information on subscribing to the linux-kernel
or linux-kernel-digest mailing lists.
----------------------------------------------------------------------
From: "Michael H. Warfield" <mhw@wittsend.com>
Date: Fri, 11 Jun 1999 07:58:29 -0400 (EDT)
Subject: Re: R: Do not use stock RedHat 6.0 kernels with SMBFS! [OFF-TOPIC]
A. Wik enscribed thusly:
> On Thu, 10 Jun 1999, Steve Dodd wrote:
> > On Thu, Jun 10, 1999 at 06:48:30PM +0000, A. Wik wrote:
> > > Besides, unless public-key
> > > cryptography is used, passwords have to be stored in plain-text (or
> > > another sensitive format) on disk if they are to be encrypted on the
> > > network.
> > Rubbish. Store a secure one-way hash of the password. The problem is just
> > in choosing a secure algorithm.
> No, the one-way hashes are still sensitive (more so than a shadow file).
And what exactly do you think is stored in the shadow file?
Clue alert: They are one-way hashes! It uses either a DES based
hash with the password as the key to encrypt a known value or using MD5!
The only additional security with the shadow file is that it is readable
only by root, and that's actually one thing that Windows NT does BETTER.
On Window NT, the SAM database is actually open and locked by the operating
system and is not directly readable by ANYONE (not even the administrators)
while the OS is booted. That means crack the OS, physical access to reboot,
or brute force. With the shadow password, you only have to break root.
Then you have full access.
BTW... NTLM hashes (as opposed to LanMan hashes) are just as hard
to crack as the MD5 hashes in the shadow password file and a hell of a lot
harder to crack than the DES based hashes. Things like L0phtCrack for
cracking NT passwords depends on getting at the LanMan hashes which are
much easier to bust (lame comes to mind there).
There are "other techniques" which are not in general circulation
for busting certain password attributes off the wire with SMB protocols
but nothing that's inherent with one-way hashes in general.
Mike
- --
Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
(The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Patrick Lerda <LERDA@microprocess.com>
Date: Fri, 11 Jun 1999 14:03:50 +0200
Subject: [PPC] ext2 filesytem corruption on linux 2.2.9 PowerPC
My ext2 filesystem is quickly corrupted on my PowerPC board.
I suppose a little endian to big endian conversion missing somewhere
in the ext2 code.
Have you the same problem on PowerPC ?
Patrick LERDA
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Riley Williams <rhw@MemAlpha.CX>
Date: Fri, 11 Jun 1999 13:03:43 +0100 (GMT)
Subject: Re: Profanity in the Linux Kernel?!?!?
Hi Arvind.
>>>> cd /usr/src/linux ; grep -i fuck `find . -name '*.[ch]'`
>>> Why not:
>>> find /usr/src/linux -name '*.[ch]' -exec grep -i fuck {} \;
>> It doesn't work on my system, for starters. However, the following
>> variant works...
>> Q> find /usr/src/linux/ -name '*.[ch]' -exec grep -i fuck '{}' \;
> While we're being pedantic, notice that the last form won't work
> if /usr/src/linux happens to be a symlink.
On my system, /usr/src/linux IS a SymLink, and the above works fine.
> So
> cd /usr/src/linux && find . -type f -a \! -name \*.o
> -a \! -name \*.a -a \! -name vmlin\* | xargs grep -i fuck
> ...would be slightly better.
What on earth for!!! It doesn't even begin to match the original
command and its aims.
> Also, note that there is no reason why Makefile's and
> Config.in's etc etc can't contain `fuck'.
Note also that the sequence 'fuck' is a valid compression sequence
that could easily be generated by gzip when it compresses the code.
Your command will quite happily report it as well...
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Michael H. Warfield" <mhw@wittsend.com>
Date: Fri, 11 Jun 1999 08:07:24 -0400 (EDT)
Subject: Re: R: Do not use stock RedHat 6.0 kernels with SMBFS! [OFF-TOPIC]
A. Wik enscribed thusly:
> On Thu, 10 Jun 1999, Michael H. Warfield wrote:
> > A. Wik enscribed thusly:
> > > "Michael H. Warfield" <mhw@wittsend.com> wrote:
> > > > > (if you call share passwords security at all), they passwords are not
> > > > encrypted,
> > > Neither are telnet and FTP passwords. Besides, unless public-key
> > I use neither... I use SSH and do not allow unencrypted access
> > to interactive connections.
> SSH is great, but unfortunately, not always installed.
> > > cryptography is used, passwords have to be stored in plain-text (or
> > > another sensitive format) on disk if they are to be encrypted on the
> > > network.
> > Not true at all...
> > challenge response system for the client to prove that it knows the hashes
> > without revealing them. In theory, if you broke into the server and stole
> > the hashes, you could create a fake client who could then fake out the
> > server, but you already own the server from having broken into it. You do
> > not have to store passwords in clear, or in any reversible format anywhere.
> No, but the hash file is still more sensitive than a shadow file.
It really would be nice if you knew what you were talking about.
The shadow password file also stores one-way hashes. The smbpassword file
(assuming that's what you are talking about) can be just as secure as the
shadow file (readable only to root), so how is it "more sensitive"?
> SMB password encryption in it's current form just doesn't seem (to me)
> worth the trouble of keeping a separate password database, incompatible
> with anything else.
And your choice is? All you have are hashes. You can not reverse
the hashing. If you don't have the NTLM hashes, you can not generate them
from the one-way hashes in the shadow file or anywhere else. And without
them you are not going to be able to authenticate against the NTLM challenge
response system. They don't give you a password to validate. You have to
have the NTLM hashes that the client is going to regenerate as part of the
challenge response protocol. That protocol could still use some hardening
even in NTLM SSP v2, but the hashes themselves are pretty tough nuts to
crack. Just as tough as the MD5 hashes in the shadow file (if you bothered
to enable MD5 hashes - if you didn't, well, what can I say).
Mike
- --
Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
(The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Garst R. Reese" <reese@isn.net>
Date: Fri, 11 Jun 1999 09:15:39 -0300
Subject: Re: pre2.3.6-2 PAGE_OFFSET_RAW & pcmcia
David Hinds wrote:
>
> On Fri, Jun 11, 1999 at 12:56:49AM -0300, Garst R. Reese wrote:
>
> > But it isn't :) Same error msgs.
>
> Sorry, there's still a stupid bug in Configure. Look for the spot
> where I set the BIGMEM option... and change "$LINUX/include/asm" to
> "$LINUX/include/asm-i386/page_offset.h"
>
> -- Dave
Steve Hirsch wrote:
> Asking for the kernel config.h won't cut it on its own. The preprocessor
> directive:
>
> #include <linux/config.h>
>
> will pickup up the _pcmcia_ config.h due to "-I../include" being specified
> first in the include search sequence.
>
> Also, asm/pgtable.h must directly include asm/page.h.
>
> For a quick workaround, try applying this to the kernel tree (in
> include/asm):
>
David's latest in NEW almost works. With the fix above and testing uname
- -m against all of the i*86's instead of just i386, it works fine. I'm
sure that by the end of the day he will have a completely fixed version
of. Watch for 11-Jun.
Garst
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Bjorn Wesen <bjorn@sparta.lu.se>
Date: Fri, 11 Jun 1999 13:28:52 +0200 (MET DST)
Subject: Re: generalizing khttpd
On Fri, 11 Jun 1999, Tigran Aivazian wrote:
> I think I have already explained to you that computers exist to perform
> the work as fast as possible and in a manner as elegant as possible, so if
> khttpd is elegant and fast it should be in the kernel.
>
> What is the point of saying "are Linux system calls so slow that we can't
> write network servers using them?"?
As I wrote, it's a philosophy question. The more stuff that gets put into
the kernel due to speed issues, the more it turns into an embedded system
or a system like Windows. You can obviously design the system in any way
imaginable between OS and userland, there's no absolute right or wrong.
My point is, that the main purpose of the OS is to abstract the HW and
internal OS design so that applications can run on top of it. One of Linux
main points is that it's one of the fastest networking OS'es available -
and therefore, it should be possible to write efficient networking
applications _without_ bypassing the OS.
This is not bashing khttpd, this is bashing the Linux architecture itself
if anything, but in a constructive manner (I hope).
> Remember that the reason why, e.g. ktar or kgzip do not exist is not
> because it wouldn't be a good idea but because nobody runs tar/gzip often
> enough (i.e. not 3000 times per second) to justify a major effort of
> writing an inkernel version.
Again, that is a philosophy question. Stuff like the filesystem is not
primarily in the kernel because it's used a lot, it's there because it
can't be in userland due to the security needed. The same with drivers -
it's safer to keep them in the kernel than having setuid user programs
accessing the HW (compare with the problems with XFree86).
It seems like there is a misconception that code runs faster just because
it's in kernel mode. Why would gzip be faster if it was in the kernel? It
wouldn't, and it would slow the entire system because the Linux kernel is
not pre-empted, so while in your fat gzip loop that cpu won't switch.
You'd have to keep polling need_resched equivalents etc. And if this
wasn't the case, it'd still not be faster than user-mode.
For the same reason it would be stupid to put audio codecs and processing
algorithms inside the kernel.
In short, the OS development strives to minimize any user-mode latencies,
and putting everything that's used a lot into the kernel only means we
risk taking a step back into an era filled with incompatibilities, upgrade
nightmares and architectural locking since too much depend on the internal
architecture of the kernel.
> The situation with web serving is rather
> different - a lot of people want it to be faster and faster so one
> solution is to put it in the kernel. Also, it may be worth it even for the
> sake of winning those stinking benchmarks that people of little
> understanding use to compare Linux with the "other" OSes.
One solution, maybe. Not necessarily _the_ solution.
/Bjorn
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Horst von Brand <vonbrand@inf.utfsm.cl>
Date: Fri, 11 Jun 1999 08:38:25 -0400
Subject: Re: Profanity in the Linux Kernel?!?!?
David <david@kalifornia.com> said:
> "Michael B. Trausch" wrote:
> > Hm. Which would you rather have in YOUR kernel?
> > "Fatal Exception 0E at address 349f930d:020a34ff"
> >
> > Or
> >
> > "Something fucked up. This shouldn't happen."
> > "oops 00"
> >
> > Well, they may be unprofessional, however, they are very concise, and well
> > understood among all of us humans, no?
>
> so...what really broke? something happened that shouldn't have happened and
> it's happening is an expletive. not very concise, descriptive, or well
> understood.
OK, so you have a point. How about looking around for comments or printk's
that arent't clear enough (foul language or not) and proposing patches, or
at least asking the relevant maintainers or this list what the
message/comment should say and asking for clarification? Call it "Kernel
Language Spring Cleaning Project" (KLSC for short, so it's a 4-letter word ;-)
Bitching here about foul language in general doesn't get the kernel anywhere.
> on the other hand;
> "fatal exception 0e" a fatal processor exception was trapped. the exception
> code is 0x0e
>
> "at address nnnn" this describes where it happened.
How do I find out what code 0x0E means? What use is the address? Sorry, I
have bad memories of an IBM RT and its "error codes", some hex gibberish
you had to look up in a manual, that very often simply wasn't at hand. And
having the relevant manual on line isn't at all useful if the machine just
crashed. This particular type of stuff is handled by Oopsen in Linux, quite
well I might add.
- --
Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Fri, 11 Jun 1999 13:46:46 +0100 (BST)
Subject: Re: ICMP in 2.2.9 (was 3c575)
> > Yes. Just fine. You probably have a buggy ping binary.
>
> But it's a buggy ping binary on three different releases of redhat
> on four different kernels then.
Then you have a corrupt Red Hat methinks
(RH 4.2 to a 2.2.9 box)
[alan@lightning]$ ping -s 1475 roadrunner
PING roadrunner (194.168.151.2): 1475 data bytes
1483 bytes from 194.168.151.2: icmp_seq=0 ttl=255 time=6.9 ms
(RH 5.0 to a 2.2.9 box)
[alan@pingviini]$ ping -s 1475 roadrunner
PING roadrunner (194.168.151.2): 1475 data bytes
1483 bytes from 194.168.151.2: icmp_seq=0 ttl=255 time=6.2 msb
(RH 6.0 to a 2.2.9 box)
[alan@scoobysna]$ ping -s 1475 roadrunner
PING roadrunner (194.168.151.2): 1475 data bytes
- --- roadrunner ping statistics ---
6 packets transmitted, 0 packets received, 100% packet loss
(egcs miscompiled ping in RH 6.0)
Alan
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Tigran Aivazian <tigran@sco.COM>
Date: Fri, 11 Jun 1999 13:54:25 +0100 (BST)
Subject: Re: generalizing khttpd
Bjorn,
Your comments on OS design are of course interesting, but perhaps before
studying OS internals it is also worth to study network etiquette a bit -
namely, if I wished my words to appear on linux-kernel mailing list I
would have cc'd:linux-kernel myself.
As for "misconception of things being faster when in kernel mode", I am
well aware of the trivial scenario you are describing but was rather
mentioning it because of no need to switch between user<->kernel as
opposed to running the loop itself in the kernel (otherwise almost the
same can be achieved by running RT userspace code). This is why things
like sys_copyfile() or sys_movedirectorytree_atomically() would be a good
idea, i.e. doing things in atomic manner and without too many mode
switches. In the same manner (assuming gzip is de-facto standard of
compression, which it is) it would be nice to say sys_gzip("file",
"file.gz") and end up with the result atomically, rather than observing a
slowly increasing file.gz and then suddenly disappearing file.
Your definition of OS is valid but you seem to give a very narrow
(though widely-accepted) meaning to the "application" as "userspace
program". One can treat khttpd as a "kernelspace application", perhaps a
revolutionary and a unique (until all other vendors start shipping
their own inkernel web servers - just a guess) notion but so what?
As Lenin said "revolution is the merge of the city with a countryside" (or
something along those lines) so one can make a revolutionary OS by merging
applications+kernel ;)
Regards,
- ------
Tigran A. Aivazian | http://www.sco.com
Escalations Research Group | tel: +44-(0)1923-813796
Santa Cruz Operation Ltd | http://www.aivazian.demon.co.uk
On Fri, 11 Jun 1999, Bjorn Wesen wrote:
> On Fri, 11 Jun 1999, Tigran Aivazian wrote:
> > I think I have already explained to you that computers exist to perform
> > the work as fast as possible and in a manner as elegant as possible, so if
> > khttpd is elegant and fast it should be in the kernel.
> >
> > What is the point of saying "are Linux system calls so slow that we can't
> > write network servers using them?"?
>
> As I wrote, it's a philosophy question. The more stuff that gets put into
> the kernel due to speed issues, the more it turns into an embedded system
> or a system like Windows. You can obviously design the system in any way
> imaginable between OS and userland, there's no absolute right or wrong.
>
> My point is, that the main purpose of the OS is to abstract the HW and
> internal OS design so that applications can run on top of it. One of Linux
> main points is that it's one of the fastest networking OS'es available -
> and therefore, it should be possible to write efficient networking
> applications _without_ bypassing the OS.
>
> This is not bashing khttpd, this is bashing the Linux architecture itself
> if anything, but in a constructive manner (I hope).
>
> > Remember that the reason why, e.g. ktar or kgzip do not exist is not
> > because it wouldn't be a good idea but because nobody runs tar/gzip often
> > enough (i.e. not 3000 times per second) to justify a major effort of
> > writing an inkernel version.
>
> Again, that is a philosophy question. Stuff like the filesystem is not
> primarily in the kernel because it's used a lot, it's there because it
> can't be in userland due to the security needed. The same with drivers -
> it's safer to keep them in the kernel than having setuid user programs
> accessing the HW (compare with the problems with XFree86).
>
> It seems like there is a misconception that code runs faster just because
> it's in kernel mode. Why would gzip be faster if it was in the kernel? It
> wouldn't, and it would slow the entire system because the Linux kernel is
> not pre-empted, so while in your fat gzip loop that cpu won't switch.
> You'd have to keep polling need_resched equivalents etc. And if this
> wasn't the case, it'd still not be faster than user-mode.
>
> For the same reason it would be stupid to put audio codecs and processing
> algorithms inside the kernel.
>
> In short, the OS development strives to minimize any user-mode latencies,
> and putting everything that's used a lot into the kernel only means we
> risk taking a step back into an era filled with incompatibilities, upgrade
> nightmares and architectural locking since too much depend on the internal
> architecture of the kernel.
>
> > The situation with web serving is rather
> > different - a lot of people want it to be faster and faster so one
> > solution is to put it in the kernel. Also, it may be worth it even for the
> > sake of winning those stinking benchmarks that people of little
> > understanding use to compare Linux with the "other" OSes.
>
> One solution, maybe. Not necessarily _the_ solution.
>
> /Bjorn
>
>
>
>
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Stephen Frost <sfrost@mail.snowman.net>
Date: Fri, 11 Jun 1999 13:01:54 -0400 (EDT)
Subject: Re: Profanity in the Linux Kernel?!?!?
On Fri, 11 Jun 1999, Horst von Brand wrote:
> OK, so you have a point. How about looking around for comments or printk's
> that arent't clear enough (foul language or not) and proposing patches, or
> at least asking the relevant maintainers or this list what the
> message/comment should say and asking for clarification? Call it "Kernel
> Language Spring Cleaning Project" (KLSC for short, so it's a 4-letter word ;-)
>
> Bitching here about foul language in general doesn't get the kernel anywhere.
Except that you all havn't been looking at actual kernel code. Here's
an actual segment of code from the kernel (arch/sparc64/kernel/traps.c):
printk("SHIT[%s:%d]: "
"(PP[%016lx] CACH[%016lx] CTX[%x] g1g3[%016lx] g2[%016lx]) ",
current->comm, current->pid,
pgd_phys, pgd_cache, ctx, g1_or_g3, g2);
printk("SHIT[%s:%d]: "
"[PP[%016lx] CACH[%016lx] CTX[%x:%x]] PC[%016lx:%016lx]\n",
current->comm, current->pid,
__pa(current->mm->pgd),
pgd_val(current->mm->pgd[0]),
current->mm->context & 0x3ff,
current->tss.ctx,
regs->tpc, regs->tnpc);
As you can see, LOTS of info is printed out. I don't really follow what
it all means, except the 'SHIT', which happily tells me something BAD happened. :)
Of course, for all I know 'SHIT' could be a valid reister. ;)
Stephen
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: iglio@fub.it (Pietro Iglio)
Date: Fri, 11 Jun 1999 15:03:52 +0200
Subject: Improving capabilities support: need your opinion
Sorry for the long message, but I'm working on an extension of the linux
capabilities to support fine-grained capabilities to access specified files
and I need your opinion.
Using the current implementation, if a program is setuid root only because
it needs to override some file permission problems, we give it
CAP_DAC_OVERRIDE instead of giving it ALL roots capabilities
(eventually, only for a short period of time).
That's good, but if we run unmodified setuid0 applications, most of them
need CAP_DAC_OVERRIDE (eg. to write on /var/utmp, /etc/shadow, etc.).
However, a setuid0 application with CAP_DAC_OVERRIDE is still very dangerous,
because an attacker that breaks such an application can become root, for
example adding a new entry in /etc/passwd, even if the setuid0 application
is running with euid = nobody.
One solution is to add a 'sandbox user' for the application instead of using
CAP_DAC_OVERRIDE, but this can probably work well only if we have ACLs and
it is still hard to track what a setuid0 application can do.
PROPOSED SOLUTION: to enforce least privilege explicitly specifying files
for which the standard access control should be overriden, along with the
required access mask.
I can explain with an example. Suppose that you have an application myapp
that needs write permission on a file owned by root with access mask 000,
eg. /etc/myapp.conf. You want to create a "safe setuid0", so that every user
can run myapp.
I have modified Pavel Machek's elf capabilities hack
(http://atrey.karlin.mff.cuni.cz/~pavel/elfcap.html) so that you can write
(as root):
#> chmod u+s myapp
#> setcap -u nobody -c FILE_ACCESS:/etc/myapp.conf:w myapp
that means: myapp is a setuid that will run with euid = nobody and that
has write access to /etc/myapp.conf.
IMPLEMENTATION DETAILS:
The list of files corresponding to the CAP_FILE_ACCESS (new) capability is
stored in the elf header. When myapp is executed, the kernel associates
a list of entries (inode_number, rdev, mask) to the corresponding process.
For this reason, I have extended task_struct. (inode_number, rdev) are
used to identify the file and are determined using the paths stored in
the elf header.
The file access control is performed as follows:
permission(inode, mask):
- - if inode can be accessed with normal UNIX access control, then it's OK;
- - otherwise, go through the list of file capabilities of the current process
and find an entry corresponding to inode, and check access according to
the corresponding mask;
Thanks in advance for your comments.
- -- Pietro Iglio (iglio@fub.it)
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Bjorn Wesen <bjorn@sparta.lu.se>
Date: Fri, 11 Jun 1999 14:13:02 +0200 (MET DST)
Subject: Re: generalizing khttpd
On Fri, 11 Jun 1999, Tigran Aivazian wrote:
> same can be achieved by running RT userspace code). This is why things
> like sys_copyfile() or sys_movedirectorytree_atomically() would be a good
what about sendfile() for copying ? or rename() for moving a directory
tree ? if rename() can't do it, you're on different filesystems and that'd
require locking both. hairy..
> idea, i.e. doing things in atomic manner and without too many mode
> switches. In the same manner (assuming gzip is de-facto standard of
> compression, which it is) it would be nice to say sys_gzip("file",
that's why you have libraries. "nicety" has little to do with the kernel.
> program". One can treat khttpd as a "kernelspace application", perhaps a
> revolutionary and a unique (until all other vendors start shipping
that's why I suggested the "low latency services" as something between
kernel and userland, if this is deemed necessary.
/bjorn
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Manfred Spraul" <masp0008@stud.uni-sb.de>
Date: Fri, 11 Jun 1999 15:12:50 +0200
Subject: Re: NR_TASKS as config option.
Ingo wrote:
> ... FYI, i have a patch in the queue that makes nr_tasks a /proc/sys
> runtime configurable option and removes the GDT limitation in the
> x86 case. I've run a kernel with 11000 processes.
I've seen an older version of your patch, and in that version, you used
one TSS for each processor, and you copy the IO-access bitmap
around.
Is that fast enough?
Which processes usually use ioperm(), is the X-server among them?
We could also have
- - 1 TSS structure for each thread
- - one GDT entry for the TSS for each processor
- - on task switch: we modify the GDT entry, it points to the TSS struct
of the new task.
OR:
use the IO-base address:
at system startup, 64 kb memory is allocated. One TSS for each
processor (each 100 byte) one behind each other, and the remaining
memory is used for the ioperm() bitmaps.
around 4 kB for all TSS, this means 60 kb free memory can
be addressed by the 16-bit I/O MAP BASE ADDRESS field
from every TSS.( "alloc nr"*128+4096-sizeof(TSS)*"cpu number")
First ioperm()-call: 128 bytes get allocated from this area.
on thread-switch: modify the base address
This would limit the number of ioperm()-processes to
~ 480, but that shouldn't be a real limitation.
- --
Manfred
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Helmut Naughton" <naughton@poweronline.net>
Date: Fri, 11 Jun 1999 15:14:50 +0200
Subject: Re: init failing in 2.3.6
On 11 Jun 99, at 13:24, Paul Mackerras wrote:
> I am seeing a problem with 2.3.6 where init is failing to start
> correctly with an error about not being able to map shared libraries.
> (This is on my powermac with the current vger tree, but that's very
> close to the official tree these days.)
>
> The problem is that an mmap is failing with ENOMEM. I tracked this
> down to the do_munmap call from do_mmap failing because the address
> was not page-aligned. It wasn't page-aligned because
> get_unmapped_area was returning an non-page-aligned address, because
> there was a vma with a non-page-aligned end value. This in turn was
> because earlier on, during an execve syscall, load_elf_interp had
> called do_brk with a len parameter which wasn't a multiple of the page
> size.
>
> I am about to try this patch, which makes do_brk page-align its len
> parameter:
>
> --- mm/mmap.c~ Thu Jun 10 09:49:31 1999
> +++ mm/mmap.c Tue Jun 11 21:48:50 2019
> @@ -728,6 +728,9 @@
> struct vm_area_struct * vma;
> unsigned long flags, retval;
>
> + if ((len = PAGE_ALIGN(len)) == 0)
> + return addr;
> +
> /*
> * mlock MCL_FUTURE?
> */
>
> If instead all callers of do_brk should ensure that len is a multiple
> of the page-size, I'm sure someone will post a better patch. :-)
I had this booting problem too. My specs are:
SuSE 6.1 (mostly unchanged),
egcs-2.91.66, binutils 2.9.1.0.22,
glibc 2.0.7pre6 on an i686 system.
2.3.5 worked ok, but with 2.3.6 i had this problem.
However this patch helped me. It compiled ok and the problem was
fixed.
The only thing i noticed was an error message during the end of the
kernel boot sequence, which i have never seen before:
kmem_grow: called nonatomically from int - size-32
If anybody wants to know more, please mail me.
- -Helmut
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Mike Bennett <mbennett@cfcc.cc.fl.us>
Date: Fri, 11 Jun 1999 09:23:36 -0400
Subject: Re: init failing in 2.3.6
FWIW, log another initial failure to boot 2.3.6 and success
with this patch applied.
Thanks Paul!
Mike
On Fri, Jun 11, 1999 at 01:24:23PM +1000, Paul Mackerras wrote:
> I am seeing a problem with 2.3.6 where init is failing to start
> correctly with an error about not being able to map shared libraries.
>
> --- mm/mmap.c~ Thu Jun 10 09:49:31 1999
> +++ mm/mmap.c Tue Jun 11 21:48:50 2019
> @@ -728,6 +728,9 @@
> struct vm_area_struct * vma;
> unsigned long flags, retval;
>
> + if ((len = PAGE_ALIGN(len)) == 0)
> + return addr;
> +
> /*
> * mlock MCL_FUTURE?
> */
>
>
> Paul.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Alex Holden <alex@linuxhacker.org>
Date: Thu, 10 Jun 1999 21:14:19 +0100 (GMT)
Subject: Re: SPARCstation's power led goes off upon kernel init
On Wed, 9 Jun 1999, Michael B. Trausch wrote:
> > Why should this be a problem or a bug? I used to run NetBSD on a SS5-170
> > and you could get the LED to indicate the load! Blink once a second for
> Damn... Makes me wanna drop the Intel computers! J/K
The NetWinder does the same thing... It has a red and a green LED on the
front which are software addressable. If you enable the CPU load LED
function, we light the red LED whenever we are _not_ running the idle
task. So when the machine is idle the light goes out, and when it's
working the light comes on. It can be pretty useful, as well as pretty.
- --------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
- -------------------- http://www.linuxhacker.org/ --------------------
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Bill Broadhurst <bbroad@CX601758-a.dt1.sdca.home.com>
Date: Fri, 11 Jun 1999 06:33:01 -0700
Subject: Re: 2.3.6 (mmap fails)
On Fri, Jun 11, 1999 at 07:33:20AM +0100, Alex Buell wrote:
>
> Someone posted this patch - try it. I don't have time to do it now. =)
>
Seems to work. I'll give this machine a workout and see if it holds
up under load.
- -bb
- --
- ----------------------------------------------------------------------
Dr. Bill Broadhurst | Independent contract Engineer.
(619)296-3710 | BIOS, Firmware, & Diagnostics.
bbroad@CX601758-a.dt1.sdca.home.com | Finger for PGP 5.0 public key.
- ----------------------------------------------------------------------
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Marek Habersack <grendel@vip.net.pl>
Date: Fri, 11 Jun 1999 15:36:51 +0200
Subject: Re: Profanity in the Linux Kernel?!?!?
- --yEPQxsgoJgBvi8ip
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
* Riley Williams said:
> > Aren't there translations for it, anyway? I mean, it should be
> > that hard to have language strings of some sort and be able to
> > use it. Even without it, most English language descriptions may
> > not have much weight to one who doesn't know English very
> > well... I think that it's a loss that could be accepted.
>=20
> Personally, I'd prefer to see Linux move over to having any error call
> a separate module to generate the actual error message, and leave that
> module to sort out the precice wording thereof. That way, it could be
Why litter the kernel with messages? Why not just add error interpretation
to some external daemon - sysklogd is an excellent place to do that. It
would simply parse all kerenel messages looking for, say
"kernel: kerror 00 at 0x0000:0x0000"
then look it up in some erorr database and output the translated message -
and even localized one if you will. Less kernel space, more convenience for
users, and no more such longish discussions as this one. I would gladly code
it, if there was consent it's a good approach.
> However, when I proposed such a system some months back, and offered
> to do the necessary, it was turned down by all concerned, apparently
> on the basis of the loss of performancee that such a system was
> claimed to inevitably suffer from.
If put in the kernel, yes, but in the userland?
regards,
marek
=20
- --yEPQxsgoJgBvi8ip
Content-Type: application/pgp-signature
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
iQCVAwUBN2EQ851EuNB7BOoNAQG7GgQAzl9PNpHj0QmY7iq3laYd1U1UBFiFDV5Y
oTkgLB1L/6/LZWOli5xP93eZvBPSrK7M6fi+p7E1lMMilTngrjrHSGN2urR3rSXu
tGcIt4jQJQ430y500XXuvEAiTqUUULCqDgwONiurrVQ6rT0YPgSEuvV/TjPlV1AD
ervAMjYWfnc=
=sIK+
- -----END PGP SIGNATURE-----
- --yEPQxsgoJgBvi8ip--
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Tigran Aivazian <tigran@sco.COM>
Date: Fri, 11 Jun 1999 14:33:50 +0100 (BST)
Subject: Re: generalizing khttpd
On Fri, 11 Jun 1999, Bjorn Wesen wrote:
> On Fri, 11 Jun 1999, Tigran Aivazian wrote:
> > same can be achieved by running RT userspace code). This is why things
> > like sys_copyfile() or sys_movedirectorytree_atomically() would be a good
>
> what about sendfile() for copying ? or rename() for moving a directory
> tree ? if rename() can't do it, you're on different filesystems and that'd
> require locking both. hairy..
Being on different filesystems is the only situation I was talking about.
What do you mean by "hairy.." ? That it cannot be done efficiently or
what?
Tigran.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Matti Aarnio <matti.aarnio@sonera.fi>
Date: Fri, 11 Jun 1999 16:37:33 +0300
Subject: Re: Profanity in the Linux Kernel?!?!?
On Fri, Jun 11, 1999 at 01:01:54PM -0400, Stephen Frost wrote:
....
> As you can see, LOTS of info is printed out. I don't really follow what
> it all means, except the 'SHIT', which happily tells me something BAD happened. :)
> Of course, for all I know 'SHIT' could be a valid reister. ;)
Indeed, this entire talk reminds me of names/abbreviations that cisco
egineering seems to give to their gadgets. I just noticed that some
LAN-switch had a new CAM (Content Addressable Memory) unit called:
SuperCAM
naturally its abbreviation is SCAM :-)
Also the Cisco 12000 router used to be called "BFR", until somebody at
marketing (?) finally heard the words behind the abbreviation, and now
it is "GSR" ... ("Big Fucking Router" -> "Giga Switch Router")
(It could have been originally something like: Billion Frame Router,
but that isn't as cheeky as the latter meaning...)
We could of course change all apparently english profanities to e.g.
finnish ones, and only tight-minded finns (they do exist, unfortunately)
would take offence...
But this entire P.C. talk is pointless.
If you can IMPROVE some error report, then go ahead and submit it,
otherwise don't mess with things that don't need messing with.
> Stephen
/Matti Aarnio <matti.aarnio@sonera.fi>
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Johan Andersson <zrq501j@tninet.se>
Date: Fri, 11 Jun 1999 16:05:01 +0200
Subject: Re: Yamaha Opl3-Sa3 problems...
> > I am using "make menuconfig" to setup the configure file, and when i have configured it right (i think) i compile the kernel, boot with the new kernel and try to use some programs that uses sound, but it will not work anyway.
> > (I get the soundchip-info from the Opensound (the version that not is free).
>
> And even when you buy it is sucks. It's buggy, slow and non-linux-ettiqueted (costs money, of course).
It came with the computer.
It is a rent-computer... *isch*
I am going to buy a new one...
> > When I use opensound i can get sound, in 20 minutes for the demo version only: Not so fun.)
> >
>
> It's a PnP chip so you need to initialize it first. There are 2 ways: using the BIOS PnP extension (uglyyy)
> or isapnp ( Gee, you have a /<linux source tree>/Documentation/sound/OPL3-SA2 file! What could it be? Where
> do I learn about it? Well, when you compile a kernel in a tremendous way and hilight many unuseful options
> don't forget there is a <Help> button waiting down there).
I have read that files... Didnīt help.
> > My computer is a Dell Dimesion XPS D266.
> > It is a 266MHz PII with 64mb ram.
> > The soundchip is built in to the moderboard, so i cant get it of from the moderboard =(.
>
> Well, this time use a chainsaw !:))
Ok...
I tried to hit the screen as hard as i could but it didnīt fix it...
Chainsaw you say... I will test ;-) *hehe*
> > I am using SuSE 6.0 (and freebsd 3.1-release) and have tried Debian 2.0 too, but the sound will not work...
>
> Well, you might have better chances with redhat, it has a soundconf or something like this that <kinda>
> works in some peculiar strange cases.
Well, i have tested Redhat 5.0 one time, but i took it away very fast becouse it wasnīt as good as Debian was.
'sndconf' thought the soundcard was a Soundblaster 32, so it didnīt work.
// Johan
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Andrea Arcangeli <andrea@suse.de>
Date: Fri, 11 Jun 1999 15:59:51 +0200 (CEST)
Subject: Re: New schedule() and semaphore implementation ...
On Fri, 11 Jun 1999, Davide Libenzi wrote:
>I've done a global patch to kernel 2.3.5 that include my new
>schedule() implementation ( try it, gives great benchmarks ! )
Talking about design, how do you handle the `mm' and the `processor'
information in SMP? You are trashing them. For the processor thing you may
workaround the thing by using NR_CPU slots and then accounting two
different queues for every smp_num_cpus, but you would have an impressive
latency updating all such queues. For the mm thing you may browse the
higher slot and the one below in one pass but you would increase the
latency of your code this way too.
Even when there are tons of tasks in the system you may really want to get
the processor and mm informations accounted. And it's not true that if
there are N tasks running you have more schedule overhead and that's the
case you must optimize. If they are all doing `for(;;);' then you will
have the same schedule cost of one task that does `for(;;);'. I agree that
probably N tasks are going to sleep a lot (as in the network case).
About implementation details you are not using the helper functions in
list.h that would make the code easily readable. You are allowing the
first task with goodness > gdsmax to go ahead while there may be a more
priority task in the higer priority slot (RT processes). Then there is
some other minor detail that should be cleaned up according to me.
About the wake_up_sem the right thing to do is to make the semaphore
sleeping a wakeone thing.
Andrea Arcangeli
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Andrea Arcangeli <andrea@suse.de>
Date: Fri, 11 Jun 1999 16:08:32 +0200 (CEST)
Subject: Re: New semaphore __wake_up() implementation ...
On Fri, 11 Jun 1999, V Ganesh wrote:
>but if the semaphore was being used for mutual exclusion then you should
>wake up the highest priority process, which is what I think Davide is
>doing. previously we just kicked the herd in the ass and they all thundered
I think we should wakeup the last process that gone to sleep even in the
up() case. We should simple ask for an EXCLUSIVE wakeup.
Here a patch to do that:
Index: linux/kernel/sched.c
===================================================================
RCS file: /var/cvs/linux/kernel/sched.c,v
retrieving revision 1.1.2.46
diff -u -r1.1.2.46 sched.c
- --- linux/kernel/sched.c 1999/05/24 01:50:14 1.1.2.46
+++ linux/kernel/sched.c 1999/06/11 12:32:28
@@ -930,9 +930,6 @@
init_waitqueue_entry(&wait, tsk);
#define DOWN_HEAD(task_state) \
- - \
- - \
- - tsk->state = (task_state); \
add_wait_queue(&sem->wait, &wait); \
\
/* \
@@ -950,10 +947,11 @@
* Multiple waiters contend for the semaphore lock to see \
* who gets to gate through and who has to wait some more. \
*/ \
- - for (;;) {
+ for (;;) { \
+ tsk->state = (task_state|TASK_EXCLUSIVE);
- -#define DOWN_TAIL(task_state) \
- - tsk->state = (task_state); \
+#define DOWN_TAIL() \
+ schedule(); \
} \
tsk->state = TASK_RUNNING; \
remove_wait_queue(&sem->wait, &wait);
@@ -964,8 +962,7 @@
DOWN_HEAD(TASK_UNINTERRUPTIBLE)
if (waking_non_zero(sem))
break;
- - schedule();
- - DOWN_TAIL(TASK_UNINTERRUPTIBLE)
+ DOWN_TAIL()
}
int __down_interruptible(struct semaphore * sem)
@@ -973,7 +970,6 @@
int ret = 0;
DOWN_VAR
DOWN_HEAD(TASK_INTERRUPTIBLE)
- -
ret = waking_non_zero_interruptible(sem, tsk);
if (ret)
{
@@ -982,8 +978,7 @@
ret = 0;
break;
}
- - schedule();
- - DOWN_TAIL(TASK_INTERRUPTIBLE)
+ DOWN_TAIL()
return ret;
}
NOTE: There is at least one very important detail in the
semaphore-helper.h. The i386 port would be just fine about this detail.
The detail is that waking_non_zero_interruptible() _must_ first check if
it can exits succesfully from down_interruptible(). Only if it can't own
the seamphore it has to check if there is a signal pending and fail only
in such case. Otherwise we may wakeup a task in exclusive mode, and then
such task will exit because it's been interrupted and other tasks won't be
wokenup for the exclusive thing -> deadlock.
Davide if you'll do benchmarkes of your wake_up_sem, please do a bench
also over the patch above. Thanks.
Andrea Arcangeli
PS. for the equation complain, sorry, I mistaken M for N :) (you defined N
but you never used it).
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Fagerburg, Eric D" <eric.d.fagerburg@intel.com>
Date: Fri, 11 Jun 1999 07:12:05 -0700
Subject: 0E is a stack fault?? (Was RE: Profanity in the Linux Kernel?!?! ? )
> "processor exception" != "interrupt". 0E is a stack fault.
Just for the record. 0E is a page fault.
Regards,
Eric
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Kastus Shchuka <pike@usis.minsk.by>
Date: Fri, 11 Jun 1999 17:13:54 +0300 (EET DST)
Subject: Re: ICMP in 2.2.9 (was 3c575)
On Fri, 11 Jun 1999, Alan Cox wrote:
> > > Yes. Just fine. You probably have a buggy ping binary.
> >
> > But it's a buggy ping binary on three different releases of redhat
> > on four different kernels then.
>
> Then you have a corrupt Red Hat methinks
>
> (RH 4.2 to a 2.2.9 box)
>
> [alan@lightning]$ ping -s 1475 roadrunner
> PING roadrunner (194.168.151.2): 1475 data bytes
> 1483 bytes from 194.168.151.2: icmp_seq=0 ttl=255 time=6.9 ms
>
> (RH 5.0 to a 2.2.9 box)
>
> [alan@pingviini]$ ping -s 1475 roadrunner
> PING roadrunner (194.168.151.2): 1475 data bytes
> 1483 bytes from 194.168.151.2: icmp_seq=0 ttl=255 time=6.2 msb
>
> (RH 6.0 to a 2.2.9 box)
> [alan@scoobysna]$ ping -s 1475 roadrunner
> PING roadrunner (194.168.151.2): 1475 data bytes
>
> --- roadrunner ping statistics ---
> 6 packets transmitted, 0 packets received, 100% packet loss
>
> (egcs miscompiled ping in RH 6.0)
Do you mean that egcs version shipped in RH60 is not of production
quality? I've had a weird problem which dissapeared by itself and points
at egcs, I would say. Kernels up to 2.2.9 compiled with gcc 2.7.2.3 on
RH52 worked fine on the same system after its upgrading to RH60. My first
2.2.9 kernel compiled on RH60 refused to load ide-cd module. The other day
egcs produced a working ide-cd.
>
> Alan
>
>
- --------------------------------------------
Kastus Shchuka <pike@usis.minsk.by>
LAN Manager/SysAdmin ph.: +375-17-217-0481
USIS Minsk fax: +375-17-217-8828
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Matthew Kirkwood <weejock@ferret.lmh.ox.ac.uk>
Date: Fri, 11 Jun 1999 15:15:20 +0100 (GMT)
Subject: Re: Improving capabilities support: need your opinion
On Fri, 11 Jun 1999, Pietro Iglio wrote:
> Using the current implementation, if a program is setuid root only
> because it needs to override some file permission problems, we give it
> CAP_DAC_OVERRIDE instead of giving it ALL roots capabilities
> (eventually, only for a short period of time).
> PROPOSED SOLUTION: to enforce least privilege explicitly specifying
> files for which the standard access control should be overriden, along
> with the required access mask.
I wouldn't do that. There are ACL patches out there, which seem
to be stabilising quite nicely.
> #> chmod u+s myapp
> #> setcap -u nobody -c FILE_ACCESS:/etc/myapp.conf:w myapp
# addgroup myapp
# chacl myapp:g+w /etc/myapp.conf # I haven't used the ACL tools so
# don't know the right syntax
# chgrp myapp `which myapp`
# chown g+s `which myapp`
> IMPLEMENTATION DETAILS:
>
> The list of files corresponding to the CAP_FILE_ACCESS (new)
> capability is stored in the elf header. When myapp is executed, the
> kernel associates a list of entries (inode_number, rdev, mask) to the
> corresponding process. For this reason, I have extended task_struct.
> (inode_number, rdev) are used to identify the file and are determined
> using the paths stored in the elf header.
I'd avoid that, since inodes get reused. An attacker can start up
a priveleged binary, and suspend it until /etc/shadow gets the old
inode, and which point the app can start writing to the shadow file.
Better to store file permissions in files.
Matthew.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: V Ganesh <ganesh@vxindia.veritas.com>
Date: Fri, 11 Jun 1999 19:46:41 +0530 (IST)
Subject: Re: New semaphore __wake_up() implementation ...
> I think we should wakeup the last process that gone to sleep even in the
> up() case. We should simple ask for an EXCLUSIVE wakeup.
wait a sec, what about starvation issues ? if the semaphore is used for
resource counting then it's ok. but if it is used as a mutex then we're
in trouble. LIFO is unacceptable, FIFO might have priority inversion.
calculating goodness() on all the processes in the waitqueue and picking
the winner sounds like the way to go, IMHO.
ganesh
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Richard B. Johnson" <root@chaos.analogic.com>
Date: Fri, 11 Jun 1999 10:22:07 -0400 (EDT)
Subject: Re: Profanity in the Linux Kernel?!?!?
On Fri, 11 Jun 1999, Horst von Brand wrote:
[SNIPPED]
>
> > "fatal exception 0e" a fatal processor exception was trapped. the exception
> > code is 0x0e
> >
> > "at address nnnn" this describes where it happened.
>
> How do I find out what code 0x0E means? What use is the address? Sorry, I
> have bad memories of an IBM RT and its "error codes", some hex gibberish
> you had to look up in a manual, that very often simply wasn't at hand. And
> having the relevant manual on line isn't at all useful if the machine just
> crashed. This particular type of stuff is handled by Oopsen in Linux, quite
> well I might add.
> --
FYI, the usual "blue screen" is:
Microsoft (R) Windows NT (TN) Version 4.0 (Build 1381: Service Pack 3).
*** STOP: 0x00000078 (0x00000000,0x00000000,0x00000000,0x00000000)
PHASE0EXCEPTION
CPUID:GenuineIntel 6.5.2 irql:1 SYSVER 0xf0000565
This sure tells one hell of a lot. I'd much rather have:
"qlogicfc.c: got a null value out of handle_ptrs, this sucks", actual
error message from a Linux SCSI driver.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.2.6 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Jeff Hittman <jhittman@slip.net>
Date: Fri, 11 Jun 1999 07:31:03 -0700 (PDT)
Subject: [PATCH RFC] 2.3.6 nfs & sunrpc modules won't load.
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
- ---1463811756-524064205-929111463=:460
Content-Type: TEXT/PLAIN; charset=US-ASCII
nfs & sunrpc modules won't load under 2.3.6 do to missing symbols. I took
a stab at the patch but I'm not overly confident that it is correct.
Comments anyone?
- -----------------------------
Jeff Hittman
jhittman@slip.net
- -----------------------------
- ---1463811756-524064205-929111463=:460
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=nfs-prob
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9906110731030.460@jhittman.jmh.org>
Content-Description:
Content-Disposition: attachment; filename=nfs-prob
LS0tIGxpbnV4L2tlcm5lbC9rc3ltcy5jLm9sZAlUaHUgSnVuIDEwIDExOjM5
OjIwIDE5OTkNCisrKyBsaW51eC9rZXJuZWwva3N5bXMuYwlUaHUgSnVuIDEw
IDExOjQwOjA3IDE5OTkNCkBAIC0zOSw2ICszOSw3IEBADQogI2luY2x1ZGUg
PGxpbnV4L2NvbnNvbGUuaD4NCiAjaW5jbHVkZSA8bGludXgvcG9sbC5oPg0K
ICNpbmNsdWRlIDxsaW51eC9tbS5oPg0KKyNpbmNsdWRlIDxuZXQvY2hlY2tz
dW0uaD4NCg0KICNpZiBkZWZpbmVkKENPTkZJR19QUk9DX0ZTKQ0KICNpbmNs
dWRlIDxsaW51eC9wcm9jX2ZzLmg+DQpAQCAtOTAsNiArOTAsNyBAQA0KDQog
LyogaW50ZXJuYWwga2VybmVsIG1lbW9yeSBtYW5hZ2VtZW50ICovDQogRVhQ
T1JUX1NZTUJPTChfX2dldF9mcmVlX3BhZ2VzKTsNCitFWFBPUlRfU1lNQk9M
KF9fd2FpdF9vbl9wYWdlKTsNCiBFWFBPUlRfU1lNQk9MKGZyZWVfcGFnZXMp
Ow0KIEVYUE9SVF9TWU1CT0woX19mcmVlX3BhZ2UpOw0KIEVYUE9SVF9TWU1C
T0woa21lbV9maW5kX2dlbmVyYWxfY2FjaGVwKTsNCkBAIC0zODMsNiArMzgz
LDcgQEANCiBFWFBPUlRfU1lNQk9MKF9fZG93bl90cnlsb2NrKTsNCiBFWFBP
UlRfU1lNQk9MKF9fdXApOw0KIEVYUE9SVF9TWU1CT0woYnJ3X3BhZ2UpOw0K
K0VYUE9SVF9TWU1CT0woY3N1bV9wYXJ0aWFsX2NvcHlfZ2VuZXJpYyk7DQoN
CiAvKiBhbGwgYnVzbWljZSAqLw0KIEVYUE9SVF9TWU1CT0woYWRkX21vdXNl
X3JhbmRvbW5lc3MpOw0KLS0tIGxpbnV4L2ZzL25mcy9kaXIuYy5vbGQJVGh1
IEp1biAxMCAwOToxNjo0NCAxOTk5DQorKysgbGludXgvZnMvbmZzL2Rpci5j
CVRodSBKdW4gMTAgMTE6MzY6MzQgMTk5OQ0KQEAgLTM2LDYgKzM2LDkgQEAN
CiAjZGVmaW5lIE5GU19QQVJBTk9JQSAxDQogLyogI2RlZmluZSBORlNfREVC
VUdfVkVSQk9TRSAxICovDQoNCit1bnNpZ25lZCBsb25nIHBhZ2VfY2FjaGVf
c2l6ZSA9IDA7DQorc3RydWN0IHBhZ2UgKiBwYWdlX2hhc2hfdGFibGVbUEFH
RV9IQVNIX1NJWkVdOw0KKw0KIHN0YXRpYyBpbnQgbmZzX3NhZmVfcmVtb3Zl
KHN0cnVjdCBkZW50cnkgKik7DQoNCiBzdGF0aWMgc3NpemVfdCBuZnNfZGly
X3JlYWQoc3RydWN0IGZpbGUgKiwgY2hhciAqLCBzaXplX3QsIGxvZmZfdCAq
KTsNCi0tLSBsaW51eC9pbmNsdWRlL2FzbS1pMzg2L2NoZWNrc3VtLmgub2xk
CVRodSBKdW4gMTAgMTM6MDU6NTAgMTk5OQ0KKysrIGxpbnV4L2luY2x1ZGUv
YXNtLWkzODYvY2hlY2tzdW0uaAlUaHUgSnVuIDEwIDEzOjA2OjI2IDE5OTkN
CkBAIC0yNCw3ICsyNCw3IEBADQogICogYmV0dGVyIDY0LWJpdCkgYm91bmRh
cnkNCiAgKi8NCg0KLWFzbWxpbmthZ2UgdW5zaWduZWQgaW50IGNzdW1fcGFy
dGlhbF9jb3B5X2dlbmVyaWMoIGNvbnN0IGNoYXIgKnNyYywgY2hhciAqZHN0
LCBpbnQgbGVuLCBpbnQgc3VtLA0KK2V4dGVybiBhc21saW5rYWdlIHVuc2ln
bmVkIGludCBjc3VtX3BhcnRpYWxfY29weV9nZW5lcmljKCBjb25zdCBjaGFy
ICpzcmMsIGNoYXIgKmRzdCwgaW50IGxlbiwgaW50IHN1bSwNCiAJCQkJCQkg
ICBpbnQgKnNyY19lcnJfcHRyLCBpbnQgKmRzdF9lcnJfcHRyKTsNCg0KIC8q
DQo=
- ---1463811756-524064205-929111463=:460--
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Horst von Brand <vonbrand@inf.utfsm.cl>
Date: Fri, 11 Jun 1999 10:36:58 -0400
Subject: Re: 2.3.6 (mmap fails)
Jeremy Katz <katzj@linuxpower.org> said:
> On Thu, 10 Jun 1999, Horst von Brand wrote:
> > German Jose Gomez Garcia <german@pinon.ccu.uniovi.es> said:
> > > As more people have already reported 2.3.6 fails when loading shared
> > > libraries (when trying to load init) [...]
[...]
> > I'd suspect your configuration is somehow broken (Used xconfig, perhaps? Or
> > didn't do "make oldconfig"?), or you are using broken compiler flags (with
> > gcc-2.95 snapshots the -fno-strict-aliasing is _mandatory_)
> I'm not sure that's the case. Having this problem on stock RH 6, i586 UP
> (also tried SMP for the sake of trying). egcs-19990314,
Why that version? egcs-1.1.2 is from 19990315, and if you are using a
prerelease of some sort instead of the version your distribution carries...
Or go the whole mile, and fool around with gcc-2.95/2.96 snapshots and beta
binutils ;-)
- --
Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Davide Libenzi" <davidel@maticad.it>
Date: Fri, 11 Jun 1999 16:47:04 +0200
Subject: Re: New schedule() and semaphore implementation ...
>On Fri, 11 Jun 1999, Davide Libenzi wrote:
>
>>I've done a global patch to kernel 2.3.5 that include my new
>>schedule() implementation ( try it, gives great benchmarks ! )
>
>Talking about design, how do you handle the `mm' and the `processor'
>information in SMP? You are trashing them. For the processor thing you may
>workaround the thing by using NR_CPU slots and then accounting two
>different queues for every smp_num_cpus, but you would have an impressive
>latency updating all such queues. For the mm thing you may browse the
>higher slot and the one below in one pass but you would increase the
>latency of your code this way too.
>
Why I must keep NR_CPU slots ??
Processor and mm info are taken in account in goodness() calculation that
called as:
goodness(tsk, tsk, tsk->processor);
<<<< This means max mm goodness ( tsk->mm == tsk->mm ) and
max SMP goodness ( same processor ) >>>>
give the higher result and hence ensure that no process in slot (N - 1) will
give a goodness greater then one in slot N.
When at the end of a slot computation is executed this code:
...
/* Goodness promise has been maintained, we've found the President ! */
if (c >= SLOT_GDS_BASE(ii))
goto task_found;
...
we are sure, having task in slot N maintained his "promise", that we can
skip out
with the right process for the previous definition.
>About implementation details you are not using the helper functions in
>list.h that would make the code easily readable.
I can agree here.
I'll code a new version with linux lists.
>And it's not true that if
>there are N tasks running you have more schedule overhead and that's the
>case you must optimize. If they are all doing `for(;;);' then you will
>have the same schedule cost of one task that does `for(;;);'. I agree that
>probably N tasks are going to sleep a lot (as in the network case).
Andrea having tasks doing for(;;); is not a common environment to test,
isn't it ?
Anyway my algo has a cost near to O(1) while the previous as a cost of O(N)
where N is running tasks.
>You are allowing the
>first task with goodness > gdsmax to go ahead while there may be a more
>priority task in the higer priority slot (RT processes). Then there is
>some other minor detail that should be cleaned up according to me.
Agree.
I'll correct this behaviour.
Cheers,
Davide.
- --
"Debian, the Freedom in Freedom"
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Fri, 11 Jun 1999 15:42:42 +0100 (BST)
Subject: Re: ICMP in 2.2.9 (was 3c575)
> > 6 packets transmitted, 0 packets received, 100% packet loss
> > (egcs miscompiled ping in RH 6.0)
>
> Do you mean that egcs version shipped in RH60 is not of production
> quality? I've had a weird problem which dissapeared by itself and points
Well if you want to be technically accurate about it then there is no
officially production quality egcs until gcc 3.0.0, but egcs sucks noticably
less than the 'production quality' gcc 2.8.1
> at egcs, I would say. Kernels up to 2.2.9 compiled with gcc 2.7.2.3 on
> RH52 worked fine on the same system after its upgrading to RH60. My first
> 2.2.9 kernel compiled on RH60 refused to load ide-cd module. The other day
> egcs produced a working ide-cd.
The only known egcs-1.1.2 kernel problems where sparc, and are fixed in the
errata. Im not sure right now if the ping bug is egcs or ping relying on a
gcc quirk
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Arvind Sankar <arvinds@mit.edu>
Date: Fri, 11 Jun 1999 10:41:54 -0400
Subject: Re: Profanity in the Linux Kernel?!?!?
On Fri, Jun 11, 1999 at 01:32:06AM -0400, Alexander Viro wrote:
> Since this is the time-critical path (paging and copy-on-write go
> here) nobody sane would share it with floppy IRQ handling. On 8086-based
> boxen reserved range is much smaller - 0--5 instead of 0--0x11, so IBM
> guys originally mapped the IRQs to range 8--0x0f. The rest is history -
> many DOS programs depend on that setup and even on post-80286 boxen BIOS
> uses the same mapping for compatibility reasons. That's it. Nobody sane
> would use it in protected mode and IRQs are remapped by the kernel on
> very early stages of bootup.
iirc, Intel actually reserved interrupts 0-0x1f even on the 8086, but IBM went
ahead and used 'em anyway.
- -- arvind
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: I Lee Hetherington <ilh@sls.lcs.mit.edu>
Date: Fri, 11 Jun 1999 10:47:14 -0400
Subject: Re: PIII.patch
The problem with CONFIG_X86_XMM does not appear to be related to SMP. I
have duplicated the problem on a UP machine (with SMP kernel).
- --Lee Hetherington
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Mark Hull-Richter <markh@procom.com>
Date: Fri, 11 Jun 1999 07:52:39 -0700
Subject: Re: New semaphore __wake_up() implementation ...
[Sorry, I meant to post this to the list.]
Andrea Arcangeli wrote:
>
> On Fri, 11 Jun 1999, V Ganesh wrote:
>
> >but if the semaphore was being used for mutual exclusion then you should
> >wake up the highest priority process, which is what I think Davide is
> >doing. previously we just kicked the herd in the ass and they all thundered
>
> I think we should wakeup the last process that gone to sleep even in the
> up() case. We should simple ask for an EXCLUSIVE wakeup.
>
The traditional approach is to wake up the first process that blocked on
the semaphore. It preserves the order of acquisition (FIFO) and removes
the possibility of process starvation, which can easily occur in a LIFO
approach. It also tends to promote data integrity (order of updates is
preserved).
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
End of linux-kernel-digest V1 #3952
***********************************
To subscribe to linux-kernel-digest, send the command:
subscribe linux-kernel-digest
in the body of a message to "Majordomo@vger.rutgers.edu". If you want
to subscribe something other than the account the mail is coming from,
such as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-linux-kernel":
subscribe linux-kernel-digest local-linux-kernel@your.domain.net
A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "linux-kernel-digest"
in the commands above with "linux-kernel".
-
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/