Re: Test 8 Kernel Unable to get the password prompt?

[Miles Lane]

On Mon, 11 Sep 2000, David Freedom wrote:

> I tried configuring the kernel to the least amount of
> configured options to almost none and I still cannot
> get the password prompt.
> 
> My system hangs and is unable to do anything. 
> unfortunetly the only thing I can do is power down my
> PC the incorrect and most unfortunate way leading to
> filesys errors upon reboot to an older saved kernel
> image.

Are you getting both the username and password prompts
and then getting nothing after entering the password?
This is a behavior I am seeing on a laptop Pentium II.
In my case, I can CTRL-ALT-F[1-6] to get to another
VT.  All attempts to log in any VT display meet the same
fate.  Also, attempting to log in using GDM fail in
this way.  In my case, the UI GDM continues to respond.

Lastly, trying to CTRL-ALT-DEL to initiate a shutdown
does cause the TERM and KILL signals to be sent to
all processes.  Then the shutdown process locks up
after a message is printed about unloading the 
keyboard driver.

Interestingly, if I boot in single mode ("linux single"
at the boot prompt), and then load GDM, I am able to 
log on with no trouble.

I have sent a message to the maintainer of the 
shadow-utils package, but have gotten no response.

I suspect this problem has to do with a fsck-up on
my part in getting util-linux configured properly when
I built it.  I rebuilt util-linux with the sources
pointed to by Changes several development kernel 
revisions ago (~2.4.0-test7).

Miles

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[David A. Gatwood]

On Mon, 11 Sep 2000, Horst von Brand wrote:

> 
> mberglund <[EMAIL PROTECTED]> said:
> 
> [...]
> 
> > License:
> > This project will not be restricted to any one license. If a piece
> > of software is desirable, but under an Artistic-, BSD-, or even
> > GPL-style license, it will be used, so long as it allows
> > free(no cost) distribution.
> 
> Can't do that. The pieces that go into this (gcc, the Linux kernel, and
> minor pieces) are under licences granted by _other_ people, which you can't
> just change at your whim. And I doubt it _very_ much indeed Linus or the
> FSF will allow you to distribute their respective properties under other
> licences than the GPL.

I'm fairly sure that's not what the original poster meant.  I think the
statement was intended to mean that free software would be included on the
CD/ftp site without a Debian-like aversion to anything "free but
commercial or closed source".


Later,
David

-
A brief Haiku:

Microsoft is bad.
It seems secure at first glance.
Then you read your mail.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Test 8 Kernel Unable to get the password prompt?

[David Freedom]

I tried configuring the kernel to the least amount of
configured options to almost none and I still cannot
get the password prompt.

My system hangs and is unable to do anything. 
unfortunetly the only thing I can do is power down my
PC the incorrect and most unfortunate way leading to
filesys errors upon reboot to an older saved kernel
image.

Brand New Dell Laptop Inspirion 600/750 Intel PIII
Speed Step.

256 SDRAM.

20 Gig hard drive.

8 meg ATI mobility video card.

Card bus, Adaptec 148oA slim SCSI.
3 COM combo ethernet and winmodem 3cxfem656c.

Dual boot Win98SE and linux Red Hat 6.2

I have all the updated needed as mentioned in your
'changes' document.

pcmcia-cs is a bit tricky though.  Even though I know
3.19 is installed it version shows up as 3.11?  Maybe
because the RPM version is still not available as 3.19
or the header files still show up as 3.11?


__
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmsg SCM_RIGHTS problem

[Andrey Savochkin]

On Mon, Sep 11, 2000 at 06:31:34PM +0600, Andrey G. Kaplanov wrote:
> Respected colleagues!
> 
> I have are problem of send SCM_RIGHTS message 
> through AF_UNIX socket.
> Below - examples of server and client sources.
> Sendmsg gives an error : Invalid argument.
> That I do;make wrong?

Null pointers in accept call.
See ftp://ftp.nc.orc.ru/pub/Linux/people/saw/bindd
for SCM_RIGHTS example.

Regards
Andrey V.
Savochkin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18pre5

[Keith Owens]

On Mon, 11 Sep 2000 22:31:15 +0100 (BST), 
Alan Cox <[EMAIL PROTECTED]> wrote:
>2.2.18pre5
>o  Fix illegal use of section attributes   (Arjan van de Ven)

Which bit of the patch is this?  Nothing changes any section
statements, the only attribute changes are to emu10k1/emu_wrapper.h.
I'm guessing it is the #ifndef __ASSEMBLY__ change in init.h.

>o  Save DR6 condition into the TSS (Ryan Wallach)

Has anybody sent a 2.4 update for this change?  2.4.0-test8 does not
save DR_STATUS.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Booting into /bin/bash

[Jesse Pollard]

On Mon, 11 Sep 2000, Ion Badulescu wrote:
>In article <8pjlk6$vnf$[EMAIL PROTECTED]> you wrote:
>
>>>However, ^C does not stop anything. No signal gets sent to anybody.
>>>I don't want to make it too large because it won't fit on a floppy
>>>if I do.
>> 
>> That means you don't have a controlling tty.
>
>But why is /dev/console not a tty? Is there any good reason,
>or is just "because nobody has done it"?

Sometimes /dev/console is a printer, or an uninitialized
tty being used as a printer (serial dot matrix printers make
excellent trace logs).
-- 
-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Horst von Brand]

mberglund <[EMAIL PROTECTED]> said:

[...]

> License:
> This project will not be restricted to any one license. If a piece
> of software is desirable, but under an Artistic-, BSD-, or even
> GPL-style license, it will be used, so long as it allows
> free(no cost) distribution.

Can't do that. The pieces that go into this (gcc, the Linux kernel, and
minor pieces) are under licences granted by _other_ people, which you can't
just change at your whim. And I doubt it _very_ much indeed Linus or the
FSF will allow you to distribute their respective properties under other
licences than the GPL.

Good luck in any case!
-- 
Dr. Horst H. von Brand   mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [BUG] threaded processes get stuck in rt_sigsuspend/fillonedir/exit_notify

[Ulrich Drepper]

David Ford <[EMAIL PROTECTED]> writes:

> Regardless of who does it or whether or not it goes in testX patch, I'd
> surely like to have a patch(es) for my systems.  Depending on what gets run,
> I could easily end up with hundreds+ of hung programs and zombies.

This is completely unrelated.  The fix for your problem is to change
the CLONE_SIGHAND flag back to it's original behavior.  Changing
linuxthreads to take advantage of the new kernel functionality is on a
different plate.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch]2.4.0-test6 "spinlock" preemption patch

[Andrea Arcangeli]

On Mon, 11 Sep 2000, Rik van Riel wrote:

>Hmmm, maybe the Montavista people can volunteer to clean
>up all those places in the kernel code? ;)

That would be nice and welcome indipendently of the preemptible kernel
indeed. The right construct to convert that stuff is
spin_is_locked/spin_trylock (so spin_trylock will take care to forbid
kernel reschedules within the critical section).

One example that cames to mind to better show what this cleanup consists
of (not a matter to this case because it's code that doesn't get compiled
in UP) is the global_irq_lock variable. The i386 one is the example of the
old style one and the alpha one is the new style spin_is_locked/trylock
one.

The new rule should be that places that uses test_and_set_bit should never
spin. They can be of course schedule-locks like lock_page() (infact being
a schedule aware lock still means not to spin on the lock :).

Those cleanups can start in the 2.4.x timeframe but I'd rather not depend
on them during 2.4.x to have a stable kernel. (2.5.x looks a better time
to change such an ancient API) This is just my humble opinion of course.

Andrea

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [BUG] threaded processes get stuck in rt_sigsuspend/fillonedir/exit_notify

[David Ford]

Ulrich Drepper wrote:

> Ray Bryant <[EMAIL PROTECTED]> writes:
>
> > Is there a succinct description of the the thread group changes
> > someplace?  I'd be willing to take a look at fixing linuxthreads,
> > but haven't seen any description (other than the kernel source) of
> > what the changes are.  Or is someone already working on this?
>
> "Fixing" alone won't cut it.  I've started a rewrite and send Linus
> more comments about what is needed but not even got a reply.  Seems
> the short interest span is already over.

Regardless of who does it or whether or not it goes in testX patch, I'd
surely like to have a patch(es) for my systems.  Depending on what gets run,
I could easily end up with hundreds+ of hung programs and zombies.

-d

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."




begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;28256
fn:David Ford
end:vcard

Re: [BUG] threaded processes get stuck in rt_sigsuspend/fillonedir/exit_notify

[David Ford]

Ulrich Drepper wrote:

> David Ford <[EMAIL PROTECTED]> writes:
>
> > On the recent test kernels, processes get stuck.  A kill -9 results in
> > zombies.
>
> The thread group changes broke the signal handling in linuxthreads.
> The CLONE_SIGHAND is now also used to enable thread groups but since
> linuxthreads already used CLONE_SIGHAND and is not prepared for thread
> groups all hell breaks loose.
>
> I've told Linus several times about this problems but he puts out one
> test release after the other without this fixed.

This is kinda important, I run DNS tools which are threaded amongst
numerous other threaded programs a lot.  What needs to be done to fix it?

-d

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."




begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;28256
fn:David Ford
end:vcard

Re: [patch]2.4.0-test6 "spinlock" preemption patch

[Rik van Riel]

On Tue, 12 Sep 2000, Andrea Arcangeli wrote:
> On Wed, 6 Sep 2000, George Anzinger wrote:
> 
> >The times a kernel is not preemptable under this patch are:
> >
> >While handling interrupts.
> >While doing "bottom half" processing.
> >While holding a spinlock, writelock or readlock.
> >
> >At all other times the algorithm allows preemption.
> 
> So it can deadlock if somebody is doing:
> 
>   while (test_and_set_bit(0, )) {
>   /* critical section */
>   mb();
>   clear_bit(0, );
>   }

> The above construct it's discouraged of course when you can do
> the same thing with a spinlock but some place is doing that.

Hmmm, maybe the Montavista people can volunteer to clean
up all those places in the kernel code? ;)

cheers,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Multiple Keyboards in 2.2/2.4?

[James Simmons]

> > Don't forget about where printk goes to. Should it goe to every VT or just
> > one? As for SysRq do users want the option to disable for everyone, have
> > it work for one VT or allow it for everyone? Do we want a all or nothing
> > policy?
> 
> It is actually very easy. Just one keyboard, and just one monitor is
> "system console". All others are just normal terminals. 
> 
> There's already same problem with serial console / vt problem. There's
> solution saying "user selects using command line what _real_ console
> is". No new problem here.
> 
> [And yes, serial console can do both sysrq and printing kernel
> messages. No new problems here.]

Yes I know serial console works just as well as video console. I came up
with the idea of a "system console" as well. I just wanted to see if
people seen this also a "good" solution. This _real_ console is the one
where you can do things like ctrl_alt_del from it where other VTs you
can't.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Signal handling different for root and others

[Andi Kleen]

On Tue, Sep 12, 2000 at 02:45:48AM +0200, jury gerold wrote:
> Andi Kleen wrote:
> > 
> > On Tue, Sep 12, 2000 at 02:20:02AM +0200, jury gerold wrote:
> > > I ran into a problem with 2.2.x kernels, posix signals and sockets.
> > >
> > > I have a program that creates a serversocket, puts it into listen state,
> > > attaches the socket to a realtime signal and simply waits for the signal.
> > >
> > > When i create a connection (telnet a.b.c.d port) the signal is delivered 
>depending
> > > on the user that does the telnet.
> > > If root creates the socket, then only root or another machine is able to trigger 
>the signal
> > > by connecting to the socket.
> > > Normal users are only able to create a SIGIO signal when connecting.
> > 
> > That's very unlikely. TCP does not propagate gid/uid information over sockets,
> > not even over localhost.
> > There was probably some other factor during your tests. When you overflow
> > the rt signal queue then the kernel will fall back to sending SIGIO. In
> > this case you have to collect outstanding events using poll.
> > 
> > -Andi
> > -
> 
> Thats right. A connection from a different machine always triggers the realtime 
>signal.
> On the same machine however, it depends on the user that does the connect and on the
> user that creates the listening socket.

I doubt it.

> 
> While you mention it : Somewhere in net/socket.c there is a connection between SIGIO 
>and SO_NOSPACE.

The sending socket has no ties at all to the receiving socket other than
that they speak TCP/IP with each other.  The receiver socket socket simply does 
not know the uid, so it cannot change behaviour based on it.

The "connection" to SO_NOSPACE is easy to explain, see the table of I/O events 
in socket(7). It is the POLLOUT event. 

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [patch]2.4.0-test6 "spinlock" preemption patch

[Andrea Arcangeli]

On Wed, 6 Sep 2000, George Anzinger wrote:

>The times a kernel is not preemptable under this patch are:
>
>While handling interrupts.
>While doing "bottom half" processing.
>While holding a spinlock, writelock or readlock.
>
>At all other times the algorithm allows preemption.

So it can deadlock if somebody is doing:

while (test_and_set_bit(0, )) {
/* critical section */
mb();
clear_bit(0, );
}

The above is 100% correct code in all linux kernels out there. It
won't be correct anymore when you make the kernel preemtable with your
patch or also with the patch from [EMAIL PROTECTED] of last month.

http://www.uwsg.iu.edu/hypermail/linux/kernel/0008.1/0842.html

The above construct it's discouraged of course when you can do the same
thing with a spinlock but some place is doing that.

I did a very fast grep I found several places that will deadlock with your
patch applied. (just grep for test_and_set_bit all over the kernel and
search for `while' in the output of the grep, this will give you the
obvious places, then we should as well check for all the other atomic
operations also the one that doesn't spin because the spin could happen
w/o an atomic operation... infact all spinning should be done w/o atomic
operations to avoid cacheline pingpong)

About the title "hard real-time fully preemptable Linux kernel prototype"
I'd say it's a little misleading given that the preemptable kernel have
nothing to do with hard real time.

Andrea

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Signal handling different for root and others

[jury gerold]

Andi Kleen wrote:
> 
> On Tue, Sep 12, 2000 at 02:20:02AM +0200, jury gerold wrote:
> > I ran into a problem with 2.2.x kernels, posix signals and sockets.
> >
> > I have a program that creates a serversocket, puts it into listen state,
> > attaches the socket to a realtime signal and simply waits for the signal.
> >
> > When i create a connection (telnet a.b.c.d port) the signal is delivered depending
> > on the user that does the telnet.
> > If root creates the socket, then only root or another machine is able to trigger 
>the signal
> > by connecting to the socket.
> > Normal users are only able to create a SIGIO signal when connecting.
> 
> That's very unlikely. TCP does not propagate gid/uid information over sockets,
> not even over localhost.
> There was probably some other factor during your tests. When you overflow
> the rt signal queue then the kernel will fall back to sending SIGIO. In
> this case you have to collect outstanding events using poll.
> 
> -Andi
> -

Thats right. A connection from a different machine always triggers the realtime signal.
On the same machine however, it depends on the user that does the connect and on the
user that creates the listening socket.

While you mention it : Somewhere in net/socket.c there is a connection between SIGIO 
and SO_NOSPACE.

int sock_wake_async(struct socket *sock, int how)
...

I am trying to follow the code, but it's a little bit difficult for me.

Gerold
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH][RFC] check fib6_lookup_1 return in fib6_lookup_1

[Arnaldo Carvalho de Melo]

Em Mon, Sep 11, 2000 at 05:27:56PM -0700, David S. Miller escreveu:
>Date: Mon, 11 Sep 2000 18:34:22 -0300
>From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
> 
>  fib6_lookup_1 can return NULL, please consider applying.
> 
> (Note that CONFIG_IPV6_SUBTREES is never turned on :-)

heh

> I think more to the intent is to just continue the main search logic
> if it returns NULL at this spot, and hence is the change I have
> put into my sources.
> 
> --- net/ipv6/ip6_fib.c.~1~Wed May  3 00:08:47 2000
> +++ net/ipv6/ip6_fib.cMon Sep 11 17:26:03 2000
> @@ -638,10 +638,8 @@
>   if (narg->addr) {
>   st = fib6_lookup_1(fn->subtree, narg);
>  
> - if (!(st->fn_flags & RTN_ROOT))
> - {
> + if (st && !(st->fn_flags & RTN_ROOT))
>   return st;
> - }
>   }
>   }
>  #endif

cool, spotted a problem and learned something. :-)

/me goes back to eyeballing code

- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Memtest suite 0.0.4

[Juan J. Quintela]

Memory test suite v0.0.4


This intends to be a set of programs to test the memory management
system.  I am releasing this version with the idea of gather more
programs for the suite.  If you have some program to test the system,
please send it to me ([EMAIL PROTECTED]).

Thanks to Tom Hull and Arjan van de Ven for fixing the C++ warnings.

If you found values/combinations of tests for what the system
crash/Oops/whatever please report it to me.  Then I can include it in
the tests and the people who tune the MM system can test it next time.

This version has:
An improved README
new shm test
removing several compilations warnings
added Tests file
Now RAMSIZE is a parameter that you can change at runtime
test   (this patch has been done by 
Marcelo Tosatti <[EMAIL PROTECTED]> and then
extended by me)

I have been having requests for people for the Linux Test Project
 about merging the two test suites,
comments about that are welcome.

Any comments/suggestions/code are welcome.


If some C++, thread guru wants to change shm-stress to use something
more portable than , help is welcome.


This tests can be made possible thanks to the collaboration of:
Conectiva 
LFCIA (my University group) 
that kindly donated to me an SMP machine.

Thanks for your time,
Juan Quintela
[EMAIL PROTECTED]

The home of this package is:

http://carpanta.dc.fi.udc.es/~quintela/memtest/


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Bryan O'Sullivan]

l> If you can get me a tarball of the CVS repository, I'll import the
l> history into a BK tree and then we can do side by side tests.

I know BK is the best thing since sliced yams, but can you please take
this thread to some BK mailing list and do your performance
comparisons there?

http://www.tux.org/lkml/

Re: [PATCH][RFC] check fib6_lookup_1 return in fib6_lookup_1

[David S. Miller]

   Date: Mon, 11 Sep 2000 18:34:22 -0300
   From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>

   fib6_lookup_1 can return NULL, please consider applying.

(Note that CONFIG_IPV6_SUBTREES is never turned on :-)

I think more to the intent is to just continue the main search logic
if it returns NULL at this spot, and hence is the change I have
put into my sources.

--- net/ipv6/ip6_fib.c.~1~  Wed May  3 00:08:47 2000
+++ net/ipv6/ip6_fib.c  Mon Sep 11 17:26:03 2000
@@ -638,10 +638,8 @@
if (narg->addr) {
st = fib6_lookup_1(fn->subtree, narg);
 
-   if (!(st->fn_flags & RTN_ROOT))
-   {
+   if (st && !(st->fn_flags & RTN_ROOT))
return st;
-   }
}
}
 #endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Signal handling different for root and others

[Andi Kleen]

On Tue, Sep 12, 2000 at 02:20:02AM +0200, jury gerold wrote:
> I ran into a problem with 2.2.x kernels, posix signals and sockets.
> 
> I have a program that creates a serversocket, puts it into listen state,
> attaches the socket to a realtime signal and simply waits for the signal.
> 
> When i create a connection (telnet a.b.c.d port) the signal is delivered depending
> on the user that does the telnet.
> If root creates the socket, then only root or another machine is able to trigger the 
>signal
> by connecting to the socket.
> Normal users are only able to create a SIGIO signal when connecting.

That's very unlikely. TCP does not propagate gid/uid information over sockets,
not even over localhost.
There was probably some other factor during your tests. When you overflow
the rt signal queue then the kernel will fall back to sending SIGIO. In
this case you have to collect outstanding events using poll. 


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH][RFC] check fib6_lookup_1 return in fib6_lookup_1

[Arnaldo Carvalho de Melo]

Hi,

fib6_lookup_1 can return NULL, please consider applying.

- Arnaldo

--- linux-2.4.0-test8/net/ipv6/ip6_fib.cWed May  3 05:48:04 2000
+++ linux-2.4.0-test8.acme/net/ipv6/ip6_fib.c   Mon Sep 11 18:28:48 2000
@@ -638,6 +638,9 @@
if (narg->addr) {
st = fib6_lookup_1(fn->subtree, narg);
 
+   if (!st)
+   return NULL;
+
if (!(st->fn_flags & RTN_ROOT))
{
return st;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Signal handling different for root and others

[jury gerold]

I ran into a problem with 2.2.x kernels, posix signals and sockets.

I have a program that creates a serversocket, puts it into listen state,
attaches the socket to a realtime signal and simply waits for the signal.

When i create a connection (telnet a.b.c.d port) the signal is delivered depending
on the user that does the telnet.
If root creates the socket, then only root or another machine is able to trigger the 
signal
by connecting to the socket.
Normal users are only able to create a SIGIO signal when connecting.

If a normal user runs the program, then any user, as well as root is able to trigger 
the realtime signal.
No SIGIO is delivered.

The program is attached.

best regards

Gerold

/* compile with gcc -o rtsigsock rtsigsock.c -lpthread */
/* start it and do a telnet 127.0.0.1 2 */

#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define SERVERPORT 2

static int RT_DISPATCHSIG;

static void setAsync( int fd, int sig )
{
  int ret;

  // printf( "setasync %d %d\n", fd, sig );
  ret = fcntl( fd, F_SETOWN, getpid() );
  if( ret == -1 ) perror( "SETOWN" );
  ret = fcntl( fd, F_SETSIG, sig );
  if( ret == -1 ) perror( "SETSIG" );
  ret = fcntl( fd, F_SETFL, fcntl( fd, F_GETFL, 0) | FASYNC);
  if( ret == -1 ) perror("F_SETFL" );
}

int setPortReuse( int iSockFd )
{
  int ret;
  int iReuse = 1;

  ret = setsockopt( iSockFd, SOL_SOCKET, SO_REUSEADDR, (char *), sizeof( iReuse 
) );
  if( ret == -1 ) perror( "SO_REUSEADDR" );
  return ret;
}

int main( int argc, char *argv[] )
{
  int iFd, ret, sig;
  struct sockaddr_in sa;
  sigset_t waitset;
  siginfo_t info;

  RT_DISPATCHSIG = (SIGRTMIN);

  sigemptyset(  );
  sigaddset( , RT_DISPATCHSIG );
  sigaddset( , SIGIO );
#if 0
  sigprocmask( SIG_SETMASK, , NULL );
#else
  pthread_sigmask( SIG_BLOCK, , NULL );
#endif

  iFd = socket (AF_INET, SOCK_STREAM, 0);
  if( iFd == -1 ) {
perror( "socket" );
return 0;
  }

  sa.sin_family = AF_INET;
  sa.sin_port = htons( SERVERPORT );
  sa.sin_addr.s_addr = htonl( INADDR_ANY );
  setPortReuse( iFd );
  ret = bind( iFd, (struct sockaddr*), sizeof(sa) ); // connect to host
  if( ret == -1 ) {
perror( "bind" );
return 0;
  }
  ret = listen( iFd, 8 );
  if( ret == -1 ) {
perror( "listen" );
return 0;
  }
  setAsync( iFd, RT_DISPATCHSIG );
  for(;;) {
sig = sigwaitinfo( ,  );
if( sig == RT_DISPATCHSIG ) break;
  }
  printf( "got the signal %d\n", sig );
  return 0;
}

Re: [ANNOUNCE] Darkstar Development Project

[Jonathan Lemon]

On Mon, Sep 11, 2000 at 05:05:08PM -0700, Larry McVoy wrote:
> On Mon, Sep 11, 2000 at 06:49:43PM -0500, Jonathan Lemon wrote:
> > I don't know why I'm bothering to reply to this, but yes, if you're
> > trying to synchronize CVS source trees with only CVS, it will be slow.
> > Now, if you were to compare CVSup vs Bitkeeper, then things might get
> > more interesting.
> > --
> > Jonathan
> > 
> > (for those unaware of it, CVSup is a high-speed mechanism to
> > distribute CVS repositories, and uses several algorithms including
> > "rsync" to accomplish this.)
> 
> I'd be happy to do this.  I've already gone over the details in private
> mail with Dave Miller, he was suggesting something similar and I explained
> how much disk & net I/O you have to with each case and the BK case is
> dramatically less.  
> 
> The reason is that BK does all the work when you do a local commit, it
> captures the state of the entire tree once, at the time you commit your
> changes.  CVSup, rsync, CVS, etc., all have to look at the whole tree
> because there is no fanin/fanout like BK has with the ChangeSet file.
> You can play all the games you want, but the bottom line is that you
> have to look at some version of the data, be it all the inodes, or the
> actual data.  With BK, we've distilled the state of about 9,000 files
> in the Linux tree down to about 6,000 bytes.  We have to do a single
> roughly 32KB disk I/O to get that state and then we compress to 6K and
> transfer it across the wire.
> 
> No matter what you do with rsync, there is no bloody way you can even
> come close to a single 32K disk read and then a 6K over the wire transfer.
> At least, I can't think of one, can you?
> 
> We do just as much I/O on the commit, then we walk the tree, and diff
> against the checked in version, so if you have the entire tree editted,
> we'll diff the entire tree.  But that happens when you commit your
> changes, not every time you update.
> 
> The fundemental observation is as the tree size/age grows, the amount of
> change you make to it stays relatively constant but the updates grow with
> tree size.  One human can only make so much change, but many can make a 
> lot.  BK takes advantage of that and does the hard work when you do hard
> work, not every time you update.
> 
> It's just a different design, no offense is intended against CVS, we have
> all used and learned from CVS.  But just because CVS is useful doesn't mean
> it is the best answer.

Oh, no disagreement there, CVS has quite a few shortcomings, so I'm
in no way holding it up as anything near an ideal solution, it's just
what we have now.  And yes, the cvsup daemon will take quite a bit of
I/O and memory as well.  I merely pointing out that a comparision of
cvsup vs BK would be far more interesting than native CVS alone.
--
Jonathan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Larry McVoy]

On Mon, Sep 11, 2000 at 06:49:43PM -0500, Jonathan Lemon wrote:
> I don't know why I'm bothering to reply to this, but yes, if you're
> trying to synchronize CVS source trees with only CVS, it will be slow.
> Now, if you were to compare CVSup vs Bitkeeper, then things might get
> more interesting.
> --
> Jonathan
> 
> (for those unaware of it, CVSup is a high-speed mechanism to
> distribute CVS repositories, and uses several algorithms including
> "rsync" to accomplish this.)

I'd be happy to do this.  I've already gone over the details in private
mail with Dave Miller, he was suggesting something similar and I explained
how much disk & net I/O you have to with each case and the BK case is
dramatically less.  

The reason is that BK does all the work when you do a local commit, it
captures the state of the entire tree once, at the time you commit your
changes.  CVSup, rsync, CVS, etc., all have to look at the whole tree
because there is no fanin/fanout like BK has with the ChangeSet file.
You can play all the games you want, but the bottom line is that you
have to look at some version of the data, be it all the inodes, or the
actual data.  With BK, we've distilled the state of about 9,000 files
in the Linux tree down to about 6,000 bytes.  We have to do a single
roughly 32KB disk I/O to get that state and then we compress to 6K and
transfer it across the wire.

No matter what you do with rsync, there is no bloody way you can even
come close to a single 32K disk read and then a 6K over the wire transfer.
At least, I can't think of one, can you?

We do just as much I/O on the commit, then we walk the tree, and diff
against the checked in version, so if you have the entire tree editted,
we'll diff the entire tree.  But that happens when you commit your
changes, not every time you update.

The fundemental observation is as the tree size/age grows, the amount of
change you make to it stays relatively constant but the updates grow with
tree size.  One human can only make so much change, but many can make a 
lot.  BK takes advantage of that and does the hard work when you do hard
work, not every time you update.

It's just a different design, no offense is intended against CVS, we have
all used and learned from CVS.  But just because CVS is useful doesn't mean
it is the best answer.
-- 
---
Larry McVoy[EMAIL PROTECTED]   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Debugger (was Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linu)

[almesber]

Kai Henningsen wrote:
> A classical memory corruption bug, and like most late-effect bugs hell to  
> find without some sort of support for poking around in the actual program  
> state.

Agreed. My usual debugging procedure is as follows:

 1. try to reproduce the problem
 2. make an educated guess what may be wrong and look in the code to
see if that's what's happening
 3. repeat 2. a few times
 4. sprinkle the suspected location and surrounding functions with
printk("[a]"); printk("[b]"); etc. to see where exactly it dies
(ksymoops is pretty useless if your system is dead after the bug,
and I don't want to maintain the infrastructure for a serial
console (if feasible at all))
 5. based on the findings, try 2. again
 6. add more printks to show the contents of all interesting variables
 7. based on the findings, try 2. again
 8. check assembler code
 9. try to work around the bug ;-)

Steps 4. and 6. taint the source tree, so there's a certain risk that
I break something and/or debugging changes end up in the patch with
the fix. Sometimes, the changes are big enough that, after finding a
satisfying fix, I need to start over with a fresh tree. Again, this
adds the risk of missing some changes.

I'm quite used to this procedure by now, but a "standard" kernel
debugger would certainly improve steps 4. and 6. It might also help
with the rather annoying problems of a long sequence of Oops following
the first one, or the Oops output getting too long.

Also, I don't think the absence of a debugger is sufficient protection
against placebo or voodoo "fixes", or vice versa.

- Werner

-- 
  _
 / Werner Almesberger, ICA, EPFL, CH   [EMAIL PROTECTED] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [BUG] threaded processes get stuck in rt_sigsuspend/fillonedir/exit_notify

[Ulrich Drepper]

Ray Bryant <[EMAIL PROTECTED]> writes:

> Is there a succinct description of the the thread group changes
> someplace?  I'd be willing to take a look at fixing linuxthreads,
> but haven't seen any description (other than the kernel source) of
> what the changes are.  Or is someone already working on this?

"Fixing" alone won't cut it.  I've started a rewrite and send Linus
more comments about what is needed but not even got a reply.  Seems
the short interest span is already over.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Keith Owens wrote:
> 
> On Mon, 11 Sep 2000 16:19:14 -0600,
> "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
> >Who pays you?
> 
> I used to work on kdb in my own time, for free.  Then I joined SGI and
> now I get paid to work on it.  If I left SGI I would continue to work
> on kdb, the original kdb developer left SGI but still contributes.

It's good they see the value of kdb and are willing to do this.  I
commend them.

> 
> >> The kernel debuggers that are kept up to date get used.  The ones that
> >> are used get feedback for kernel changes which keep them up to date.
> >> kdb has taken off precisely because it is being kept up to date with
> >> the kernel.  And if I miss something, I know that people will tell me.
> >
> >I'm sure this is all true.  kdb was just rejected by Linus however, what
> >message does that send to you?
> 
> That Linus does not like kernel debuggers.  This is news?  There are
> several examples of code that Linus did not like originally but enough
> people wanted them and they eventually got included in the kernel.
> Complaining to Linus does nothing, "show me the code".

You know where the code is -- go look at it.

> 
> >kdb is about 1/100th the size of the MANOS debugger in terms of source
> >code size, and isn't a hacked in after thought like kdb.  It uses task
> >gates and other tables beneath the OS that just are not there in kdb and
> >that will impinge on architectural freedom for Linus.  It also uses
> >nested task gates, and requires changes to the xcall layer in Linux to
> >plug it in.
> 
> kdb is not a hacked in after thought.  It was designed from scratch as
> a minimalist kernel debugger which coexists with the existing kernel
> design.  Note "minimalist", adding kdb to a kernel has little effect on
> the running kernel, the biggest impact is the symbol table (adds 20-30%
> to loaded kernel size) and the last branch recording in the page fault
> handler which probably slows page faulting slightly, although I have
> not measured it.

I support source level in the kernel.  Based on Andi Klein's review, I
have grabbed ext2utils and am looking at a minimal int 0x13 interface to
load files into memory.  hardest problem here for Linux is having a tiny
FS that won't deadlock to load source files.

> 
> kdb does a reasonable job at the binary level which is exactly what it
> was designed to do.  If you have to change the kernel design to
> incorporate a debugger then you seriously need to think if your
> debugger design is suitable.
> 
> >If Linus doesn't support the concept, it could be a lot of
> >work.  I know my code, you know yours -- Linus habit of breaking things
> >as he puts in new and better features that you stated aealier is true,
> >so where does that leave us?
> 
> In exactly the same position as every other kernel developer.  Nobody
> promised us that kernel APIs would remain stable in development
> kernels, if it breaks we fix it in the next patch.  This is the Linux
> development model, everyone else lives with it.

I have to look at long term support.  We get very busy around here and
spending money I will do if it makes sense.  I do appreciate your
input.  

Jeff

> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

The code is at vger.timpanogas.org.  If you want to review it, it's
there.  We are posting another MANOS kernel with full VM end of the
month.  The version Darren and I are hacking on now has the debugger
broken out as a module as a prelude to put it in Linux.  I am working on
your kdb stubs in 2.4 to put it in.  Darren is finishing the VM
subsystem.

Jeff

Keith Owens wrote:
> 
> On Mon, 11 Sep 2000 16:24:32 -0600,
> "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
> >Keith,
> >
> >If you are volunteering to maintain the MANOS debugger after I hack it
> >into Linux, then I accept.  I'll give you an ftp and telnet account on
> >vger.timpanogas.org and you can run with it.
> 
> How on earth did you make that jump?  I maintain kdb because I like it
> and it has a lot of my code in it.  MANOS is your code, you maintain
> it or persuade people to help you maintain it.  Show people the code
> and see if they use it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Jonathan Lemon]

In article [EMAIL PROTECTED]> you write:
>On Mon, Sep 11, 2000 at 05:48:44PM -0500, Tony Mantler wrote:
>> 
>> "It's the latency, stupid". I wouldn't care to argue whether CVS is slower
>> than BK or not, but consider that if you had a router between you and the
>> CVS server that was dropping even 5% of your packets, or even just bumping
>> the latency by a quarter second (and I've seen routers that do that. evil
>> things), the timing numbers will jump *significantly*.
>
>Well, err, I guess I'm pretty stupid, but how about this?  If the lxr guy
>is listening to all this, he could download a copy of BK, clone the FSMlabs
>tree, then I'll do a null pull from him, and we'll have an apples to apples
>comparison, now won't we?
>
>I think it's a pointless thing to do, I already know that CVS transfers way
>more data to do the same operation so it's a foregone conclusion it will be
>slower.  But I'm very happy to do it if the lxr guy (sorry, I've forgotten
>your name, I apologize) is willing.  Send me private mail, it shouldn't take
>very long at all to get you set up.

I don't know why I'm bothering to reply to this, but yes, if you're
trying to synchronize CVS source trees with only CVS, it will be slow.
Now, if you were to compare CVSup vs Bitkeeper, then things might get
more interesting.
--
Jonathan

(for those unaware of it, CVSup is a high-speed mechanism to
distribute CVS repositories, and uses several algorithms including
"rsync" to accomplish this.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Larry McVoy]

On Mon, Sep 11, 2000 at 07:44:52PM -0400, James Lewis Nance wrote:
> On Mon, Sep 11, 2000 at 03:45:18PM -0700, Larry McVoy wrote:
> 
> > the 120MB for the checked out files and some mem for inodes.  But the
> > difference in price is reasonable and if we have to buy memory for the
> > kernel developers, we'll do it once we can afford to do it.  It's _really_
> > nice to measure your operations in seconds rather than minutes.
> 
> Larry,
> It would be interesting to see the speed difference between bk and cvs
> for the mozilla sources.  Doing a cvs update takes at least 10 minutes even
> if no files have changed.  It took significantly longer when I was using
> a modem instead of a DSL line.  You haven't benchmarked this case have you?

If you can get me a tarball of the CVS repository, I'll import the
history into a BK tree and then we can do side by side tests.  I know
Mitchell Baker somewhat, so if she is still there, you might ping her.
I'd be interested to see this as well, so please let me know if the
CVS tarball is available.  Just to be clear, I am not talking about the
results of a CVS checkout, I am talking about the actual CVS tree with
the RCS files - if I just imported the most recent versions, BK would
be unfairly faster because it would be storing a lot less history.
-- 
---
Larry McVoy[EMAIL PROTECTED]   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Using Yarrow in /dev/random

[Marc Mutz]

Pravir Chandra wrote:
> 
> I've been working to change the implementation of /dev/random over to the
> Yarrow-160a algorithm created by Bruce Schneier and John Kelsey. We've been
> working on parallel development for Linux and NT so that the algorithms are
> matching. The Yarrow 160A algorithm is a variant of Yarrow-160 that has come
> about from discussions with John Kelsey. We've been in contact with him
> throughout our development effort.
> 

Why? What's wrong with the current implementation. And more important
still: How well-known is Yarrow160A? I cannot find it in my copy of
[Schneier96], so it is probably not older than four years.

> In any case, this requires use of a hash function (sha1) and a block cipher
> (3des). We were going to do a replacement of /dev/random (it's nearly finished)
> but in retrospect, it seemed that I hadn't looked into the current state of
> incorporating crypto into the kernel. If anyone has any suggestions, comments,
> questions, please email.
> 

_Please_ use the crypto api. It provides for a cipher and a digest(hash)
api. sha1 is implemented and functional (AFAICS), but 3des will have to
be converted to use the new api. That is not hard. If it does not fit
your needs, try convincing astor to make changes. It's really time that
the crypto api gets used by more than loopvack crypto, esp. now that it
is distributed on ftp.*.kernel.org.

> Also, does anyone have any complaints against incorporating a new /dev/random
> into the kernel?
> 

Do you mean /rev/random or /dev/urandom?


Marc

-- 
Marc Mutz <[EMAIL PROTECTED]>http://marc.mutz.com/Encryption-HOWTO/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics

PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [BUG] threaded processes get stuck in rt_sigsuspend/fillonedir/exit_notify

[Ray Bryant]

Is there a succinct description of the the thread group changes someplace?
I'd be willing to take a look at fixing linuxthreads, but haven't seen any
description
(other than the kernel source) of what the changes are.  Or is someone already
working on this?

Ulrich Drepper wrote:

>
> The thread group changes broke the signal handling in linuxthreads.
> The CLONE_SIGHAND is now also used to enable thread groups but since
> linuxthreads already used CLONE_SIGHAND and is not prepared for thread
> groups all hell breaks loose.
>
> I've told Linus several times about this problems but he puts out one
> test release after the other without this fixed.
>
> --
> ---.  ,-.   1325 Chesapeake Terrace
> Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
> Red Hat  `--' drepper at redhat.com   `
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

--

Best Regards,

Ray Bryant
IBM Linux Technology Center
[EMAIL PROTECTED]
512-838-8538
http://oss.software.ibm.com/developerworks/opensource/linux

We are Linux. Resistance is an indication that you missed the point.

"...the Right Thing is more important than the amount of flamage you need
to go through to get there"
--Eric S. Raymond


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[James Lewis Nance]

On Mon, Sep 11, 2000 at 03:45:18PM -0700, Larry McVoy wrote:

> the 120MB for the checked out files and some mem for inodes.  But the
> difference in price is reasonable and if we have to buy memory for the
> kernel developers, we'll do it once we can afford to do it.  It's _really_
> nice to measure your operations in seconds rather than minutes.

Larry,
It would be interesting to see the speed difference between bk and cvs
for the mozilla sources.  Doing a cvs update takes at least 10 minutes even
if no files have changed.  It took significantly longer when I was using
a modem instead of a DSL line.  You haven't benchmarked this case have you?

Thanks,

Jim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] af_ipv6.c: check proc_net_create and cleanups

[David S. Miller]

   Date: Mon, 11 Sep 2000 11:56:12 -0300
   From: Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>

   Em Mon, Sep 11, 2000 at 08:35:59PM +0400, [EMAIL PROTECTED] escreveu:
   > It is a remnant of the past. Delete it here and in af_inet.c,
   > when you will send new patch to David.

   Here it is.

Patch applied, thanks.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Notebook disk spindown

[almesber]

Andre Hedrick wrote:
> On Sat, 9 Sep 2000 [EMAIL PROTECTED] wrote:
> > Would it be possible to detect when the disk spins up, and do the flush then?
> Yes if you had a continuious polling of power status wrt standby.

I think the following flushing policy would work almost as well, while
remaining generic:

 - if there's a read that is not handled from the buffer cache, flush
   (write) all dirty buffers
 - if we need to flush (write) one dirty buffers, flush all others too

This wouldn't catch cases like an explicit spin-up without data I/O,
but I don't think this is much of a problem in real life.

- Werner

-- 
  _
 / Werner Almesberger, ICA, EPFL, CH   [EMAIL PROTECTED] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [BUG] threaded processes get stuck in rt_sigsuspend/fillonedir/exit_notify

[Ulrich Drepper]

David Ford <[EMAIL PROTECTED]> writes:

> On the recent test kernels, processes get stuck.  A kill -9 results in
> zombies.

The thread group changes broke the signal handling in linuxthreads.
The CLONE_SIGHAND is now also used to enable thread groups but since
linuxthreads already used CLONE_SIGHAND and is not prepared for thread
groups all hell breaks loose.

I've told Linus several times about this problems but he puts out one
test release after the other without this fixed.

-- 
---.  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \,---'   \  Sunnyvale, CA 94089 USA
Red Hat  `--' drepper at redhat.com   `
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

emu10k1 reversing channels

[Jan Niehusmann]

The current kernel is reversing the right and left channels on emu10k1 
sound cards. After isolating and fixing the bug, I found out the fix is
already in the current CVS on http://opensource.creative.com/ :-|

I think it should be included in the official kernel. Patch attached.

Jan




--- linux-2.4.0-test8/drivers/sound/emu10k1/main.c.orig Tue Sep 12 00:20:59 2000
+++ linux-2.4.0-test8/drivers/sound/emu10k1/main.c  Tue Sep 12 00:55:16 2000
@@ -121,14 +121,14 @@
 
/* stereo voice */
card->waveout.send_a[1] = 0x00;
-card->waveout.send_b[1] = 0xff;
-card->waveout.send_c[1] = 0x00;
+card->waveout.send_b[1] = 0x00;
+card->waveout.send_c[1] = 0xff;
 card->waveout.send_d[1] = 0x00;
 card->waveout.send_routing[1] = 0xd01c;
 
card->waveout.send_a[2] = 0x00;
-card->waveout.send_b[2] = 0x00;
-card->waveout.send_c[2] = 0xff;
+card->waveout.send_b[2] = 0xff;
+card->waveout.send_c[2] = 0x00;
 card->waveout.send_d[2] = 0x00;
 card->waveout.send_routing[2] = 0xd01c;
 

Re: [ANNOUNCE] Darkstar Development Project

[Larry McVoy]

On Mon, Sep 11, 2000 at 05:48:44PM -0500, Tony Mantler wrote:
> 
> "It's the latency, stupid". I wouldn't care to argue whether CVS is slower
> than BK or not, but consider that if you had a router between you and the
> CVS server that was dropping even 5% of your packets, or even just bumping
> the latency by a quarter second (and I've seen routers that do that. evil
> things), the timing numbers will jump *significantly*.

Well, err, I guess I'm pretty stupid, but how about this?  If the lxr guy
is listening to all this, he could download a copy of BK, clone the FSMlabs
tree, then I'll do a null pull from him, and we'll have an apples to apples
comparison, now won't we?

I think it's a pointless thing to do, I already know that CVS transfers way
more data to do the same operation so it's a foregone conclusion it will be
slower.  But I'm very happy to do it if the lxr guy (sorry, I've forgotten
your name, I apologize) is willing.  Send me private mail, it shouldn't take
very long at all to get you set up.
-- 
---
Larry McVoy[EMAIL PROTECTED]   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[BUG] threaded processes get stuck in rt_sigsuspend/fillonedir/exit_notify

[David Ford]

On the recent test kernels, processes get stuck.  A kill -9 results in
zombies.

# cat /tmp/ps.out
  PID USER STAT WCHAN  COMMAND
1 root Sfillon init [5]
2 root SW   acpi_i [kapmd]
3 root SW   swap_o [kswapd]
4 root SW   brw_pa [kflushd]
5 root SW   block_ [kupdate]
6 root SW   down   [i2oevtd]
7 root SW   tcp_rc [i2oblock]
8 root SW   tcp_da [khubd]
   10 root SW   devfsd [khttpd manager]
   11 root SW   indire [kreiserfsd]
   17 root Stry_mo devfsd /dev
   23 root Stimer_ /sbin/noflushd -n 5 /dev/hda
   29 root Sfillon syslogd
   31 root Sregist klogd -c 3 -k /boot/System.map-2.4.0-test8
   52 root Stimer_ crond -l10
   85 root Sdo_sel nscd
   86 root Sdo_sel nscd
   87 root Sdo_sel nscd
   88 root Sdo_sel nscd
   89 root Sdo_sel nscd
   90 root Sdo_sel nscd
   91 root Sdo_sel nscd
   93 root Sfillon apmd -W -P /etc/apmd/apmd_proxy
  101 bin  Sfillon portmap
  104 root Sfillon inetd
  105 root Sfillon sendmail: [Blue]: accepting connections
  108 root Sfillon sshd
  112 root Sfillon /usr/local/apache/bin/httpd
  114 postgres Sfillon /usr/local/pgsql/bin/postmaster -D
/usr/local/pgsql/d
  116 junkbust Sacpi_c ./junkbuster junkbstr.ini
  118 root Sincr_c /sbin/agetty 38400 vc/6 linux
  119 root Sexit   /usr/local/bin/gdm -nodaemon
  120 httpdSacpi_c /usr/local/apache/bin/httpd
  122 root Sfillon /usr/X11R6/bin/X -auth
/usr/local/var/gdm/:0.Xauth :0
  172 davidSexit   /bin/bash
/usr/local/etc/gdm/Sessions//Enlightenment
  173 davidSexit   /bin/sh /usr/local/bin/run-cafire
/usr/local/etc/inpu
  174 davidSfillon /usr/local/bin/xscreensaver -no-splash
  175 davidSfillon /usr/local/enlightenment/bin/enlightenment
  177 davidSN   ipc/usr/local/bin/cafire -back
  179 davidSfillon esd -terminate -nobeeps -as 2 -spawnpid 175
  181 davidSdo_sel gtkapm
  183 davidSfillon rxvt
  184 davidSexit   -bash
  202 root Sexit   -bash
  327 davidSfillon rxvt
  328 davidSexit   -bash
  342 davidSfillon ssh shiftq.linux.com
 1029 davidSfillon rxvt
 1030 davidSexit   -bash
 1060 davidSfillon netscape
 1061 davidSfillon (dns helper)
 1063 root Sincr_c -bash
 1097 root Zexit_n [host ]
 1098 root Zexit_n [host ]
 1110 root Zexit_n [host ]
  root Zexit_n [host ]
 1115 root Zexit_n [nslookup ]
 1116 root Zexit_n [nslookup ]
 1117 root Zexit_n [nslookup ]
 1118 root Zexit_n [nslookup ]
 1124 root Zexit_n [nslookup ]
 1125 root Zexit_n [nslookup ]
 1126 root Zexit_n [nslookup ]
 1170 root Sfillon host -h
 1175 root Srt_sig host -W 2 blue-labs.org
 1177 root Sfillon host -W 2 blue-labs.org
 1182 root Srt_sig host -T -W 2 blue-labs.org
 1184 root Sfillon host -T -W 2 blue-labs.org
 1190 root Srt_sig host -v -T -W 2 blue-labs.org
 1192 root Sfillon host -v -T -W 2 blue-labs.org
 1197 root Srt_sig host -v -T -W 2 afcu.net
 1199 root Sfillon host -v -T -W 2 afcu.net
 1168 root Srt_sig host -h
 1317 root R-  ps -ax -o pid,user,stat,wchan,args


[...]

 1097 root Z[host ] exit_notify
 1098 root Z[host ] exit_notify
 1110 root Z[host ] exit_notify
  root Z[host ] exit_notify
 1115 root Z[nslookup 

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:http://www.kalifornia.com/images/paradise.jpg">
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Blue Labs Developer
x-mozilla-cpt:;28256
fn:David Ford
end:vcard

Re: [ANNOUNCE] Darkstar Development Project

[Larry McVoy]

Note: trimmed the 390 list, they don't care according to Alan..

On Tue, Sep 12, 2000 at 12:21:16AM +0200, Jamie Lokier wrote:
> Larry McVoy wrote:
> > That's a benefit [for BK] of having changesets, I only need to compare
> > the ChangeSet file to know that 4 files were updated 2 were moved, and
> > 5 were created, then I move those *portions* of those files across the
> > wire.
> 
> What happens when I lose the ChangeSet file, or misplace it?

Life really sucks.  It's like losing a superblock, sort of.  We can 
reconstruct them but almost never do because people typically have 
more than once copy of a repository sitting around.  So you can copy
it back, do a "bk -r check -a" (the moral equiv of an fsck, no we don't
really have an fsck -y yet), and fix up the errors.  The revision control
files and the ChangeSet files point at each other and need to be in sync.

That's how we get all the performance, by the way, all we need to compare
is a tiny subset of the ChangeSet files (32KB out of 5MB in one tree, that's
pretty typical).  And we could compare a lot less, it just hasn't been
worth it to do so, we gzip that 32K down to less than 6K so...)
-- 
---
Larry McVoy[EMAIL PROTECTED]   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18pre5

[Eyal Lebedinsky]

Alan Cox wrote:
> 
> 2.2.18pre5

Just did a build on Debian2.2. Is it a misspellet IDE_PCI_DEVID_EQ?

ld -m elf_i386 -T /usr/local/src/linux/arch/i386/vmlinux.lds -e stext
arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o
init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o
mm/mm.o fs/fs.o ipc/ipc.o \
fs/filesystems.a \
net/network.a \
drivers/block/block.a drivers/char/char.o drivers/misc/misc.a
drivers/net/net.a drivers/cdrom/cdrom.a drivers/pci/pci.a
drivers/net/fc/fc.a drivers/video/video.a
drivers/net/hamradio/hamradio.a \
/usr/local/src/linux/arch/i386/lib/lib.a
/usr/local/src/linux/lib/lib.a /usr/local/src/linux/arch/i386/lib/lib.a
\
--end-group \
-o vmlinux
drivers/block/block.a(ide-pci.o): In function `ide_scan_pcibus':
ide-pci.o(.text.init+0x8a6): undefined reference to `IDE_PCI_DEVID_RQ'
ide-pci.o(.text.init+0x8e5): undefined reference to `IDE_PCI_DEVID_RQ'
make: *** [vmlinux] Error 1

--
Eyal Lebedinsky ([EMAIL PROTECTED])
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: -2.2.18-5

[Ted Gervais]

On Mon, 11 Sep 2000, Bob Lorenzini wrote:

Yes!  What is that. I get the same? 
Nice to know that I am not the only one..

Any thoughts anyone?

---
ux/arch/i386/lib/lib.a \
--end-group \
-o vmlinux
drivers/block/block.a(ide-pci.o): In function `ide_scan_pcibus':
ide-pci.o(.text.init+0x8a2): undefined reference to `IDE_PCI_DEVID_RQ'
ide-pci.o(.text.init+0x8b4): undefined reference to `IDE_PCI_DEVID_RQ'
make: *** [vmlinux] Error 1




> Date: Mon, 11 Sep 2000 15:49:24 -0700 (PDT)
> From: Bob Lorenzini <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: -2.2.18-5
> 
> /kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \
>   --start-group \
>   arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o
> mm/mm.o fs/fs.o ipc/ipc.o \
>   fs/filesystems.a \
>   net/network.a \
>   drivers/block/block.a drivers/char/char.o drivers/misc/misc.a
> drivers/net/net.a drivers/scsi/scsi.a drivers/cdrom/cdrom.a
> drivers/sound/sound.a drivers/pci/pci.a drivers/video/video.a
> drivers/net/hamradio/hamradio.a \
>   /usr/src/linux-2.2.17/arch/i386/lib/lib.a
> /usr/src/linux-2.2.17/lib/lib.a /usr/src/linux-2.2.17/arch/i386/lib/lib.a
> \
>   --end-group \
>   -o vmlinux
> drivers/block/block.a(ide-pci.o): In function `ide_scan_pcibus':
> ide-pci.o(.text.init+0x8a2): undefined reference to `IDE_PCI_DEVID_RQ'
> ide-pci.o(.text.init+0x8b4): undefined reference to `IDE_PCI_DEVID_RQ'
> make: *** [vmlinux] Error 1
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
> 

---
"I don't have a solution, but I admire the problem"

Ted Gervais <[EMAIL PROTECTED]>
44.135.34.201 linux.ve1drg.ampr.org


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Tony Mantler]

At 5:13 PM -0500 9/11/2000, Larry McVoy wrote:
[...]
>> > > > over a 384Kbits/sec link.
>
>That's a 48Kbyte/sec link.  Hardly a "horribly fast network".  In fact,
>the bandwidth to FSMlabs.com and innominate.org seems to be identical,
>I suspect that my link is the bottleneck, not either of theirs.
>In order for the link to be the reason for the performance difference,
>innominate.org would need to be a .9Kbyte/second link.  I kinda doubt
>that seeing as a 128MB cvs checkout took 23 minutes (works out to around
>90Kbyte/sec uncompressed, so cvs must compress it, so I'd guesstimate
>they have around a 30Kbyte/sec link or so).
[...]

"It's the latency, stupid". I wouldn't care to argue whether CVS is slower
than BK or not, but consider that if you had a router between you and the
CVS server that was dropping even 5% of your packets, or even just bumping
the latency by a quarter second (and I've seen routers that do that. evil
things), the timing numbers will jump *significantly*.

The best way to test network performance between the two protocols would be
to get yourself a good ol'fasioned serial cable and connect your test
client and test server to eachother via PPP at about ~9600bps or so, *then*
do your tests. Equal (though low) latency, equal (definatley low)
bandwidth, equal server and client performance.

Of course, all the CVS work I do is either over local 10/100 ethernet or
through my 6d/1uMbit cablemodem (which actually gets 6d/1u, up here in the
great white north), so what do I care? 8)


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - [EMAIL PROTECTED]
Winnipeg, Manitoba, Canada   --   http://nicoya.feline.pp.se/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

-2.2.18-5

[Bob Lorenzini]

/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \
--start-group \
arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o
mm/mm.o fs/fs.o ipc/ipc.o \
fs/filesystems.a \
net/network.a \
drivers/block/block.a drivers/char/char.o drivers/misc/misc.a
drivers/net/net.a drivers/scsi/scsi.a drivers/cdrom/cdrom.a
drivers/sound/sound.a drivers/pci/pci.a drivers/video/video.a
drivers/net/hamradio/hamradio.a \
/usr/src/linux-2.2.17/arch/i386/lib/lib.a
/usr/src/linux-2.2.17/lib/lib.a /usr/src/linux-2.2.17/arch/i386/lib/lib.a
\
--end-group \
-o vmlinux
drivers/block/block.a(ide-pci.o): In function `ide_scan_pcibus':
ide-pci.o(.text.init+0x8a2): undefined reference to `IDE_PCI_DEVID_RQ'
ide-pci.o(.text.init+0x8b4): undefined reference to `IDE_PCI_DEVID_RQ'
make: *** [vmlinux] Error 1


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Jamie Lokier]

David A. Gatwood wrote:
> > I'd love to see a filesystem feature where I could efficiently identify
> > "changed files", where "changed" is defined by last time this application
> > checked or something similar.
> 
> An in-filesystem revision number would do the trick.  Could be REALLY
> efficient.  All you have to do is stat and you know if the thing really
> changed, instead of just knowing a date that can be horked.  I like!  I
> like a lot!

Yes indeed.  There aren't many bits to play with in an ext2 inode so you
have to be careful, but it can be done.  Especially when you combine it
with the timestamp (there's no need to update a revision number if the
time changes).  I think this can even run over NFS (as a dubious
extension in the cookie or something ;-)

> Something else that'd be nice would be to make Linux deal better with NFS
> dates.  The date presented by an NFS server for files is its timestamp. 
> If the linux NFS client code were to subsequently check the stamp after
> performing an operation, it could use that to approximate the time error
> and this problem would about 99% disappear, with a fudge factor of under a
> second.  Comments?

AFS does something like that.  ntpd is better :-)

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Larry McVoy]

> > Fourth, non-null pulls are similarly faster, again, by design.  BK only
> > moves the data it needs to move.  That means if you have a 100GB file
> > in which you have changed one byte, BK will move on the order of 1 byte
> > to update that file.  And that's it - it doesn't compare the two files,
> > or read the two files, or in any way look at the two files to figure out
> > that they need to be updated.
> 
> This is an interesting point.  As far as changes are concerned, it should
> have lower network utilization.  However, in effect, it does compare the
> files.  It compared the file when you checked it into your local
> repository.  It's just shifting the burden of the comparison to a local
> repository instead of doing it over the network.  Faster, yes, but it
> still does the same thing, just in a different way that uses less
> bandwidth.

You just summed up one of the main reasons why BK is better.  We shifted
work to the client.  There is one server and many, many clients in a 
CVS tree.  The same problem solved using BK inherently distributes the
load over all the machines, moving 99% of to the clients and off loading
the server (and hence the network) almost completely.

BitKeeper isn't any faster than CVS when you do the same operation, or at
least not much faster.  If we both have 10,000 files we have to update,
we're both going to be doing a lot of work.  In fact, I suspect that CVS
is faster at that than BK is because it is just updating a clear text file
and we are updating a revision history - we have more work to do so it 
stands to reason we'd be slower.

BitKeeper is faster in practice because it isn't trying to talk to the
CVS server for all of the operations.  By far the vast majority of the
operations never reach out across the network.  So on a slow client,
BK is slow, on a fast client, BK is fast.  By contrast, with a slow CVS
server, both a slow and a fast client are slow.

So perhaps a better way to look at it is that if you can afford decent
hardware, your life should be quite pleasant using BK.  Our definition
of decent, for Linux kernel repositories, is a 466Mhz celeron with at
least 256MB, and you really want 384.  The kernel is about around 120MB
checked out, the revision history is about 160MB, and you need some mem
for the inodes.  CVS is lighter weight in that respect, it just needs
the 120MB for the checked out files and some mem for inodes.  But the
difference in price is reasonable and if we have to buy memory for the
kernel developers, we'll do it once we can afford to do it.  It's _really_
nice to measure your operations in seconds rather than minutes.
-- 
---
Larry McVoy[EMAIL PROTECTED]   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Keith Owens]

On Mon, 11 Sep 2000 16:24:32 -0600, 
"Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
>Keith,
>
>If you are volunteering to maintain the MANOS debugger after I hack it
>into Linux, then I accept.  I'll give you an ftp and telnet account on
>vger.timpanogas.org and you can run with it.

How on earth did you make that jump?  I maintain kdb because I like it
and it has a lot of my code in it.  MANOS is your code, you maintain
it or persuade people to help you maintain it.  Show people the code
and see if they use it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Jamie Lokier]

Larry McVoy wrote:
> We thought about this too (filesystems are where I got into kernel hacking),
> but dismissed it as a Linux only solution.  As much as I'd like it to be
> otherwise, BK is not a Linux only product.  Whatever we do needs to work on
> NT (shudder) as well as all the dinosaur Unixen.

NT has a facility to monitor changing files.  You could run a daemon :-)

> We do have more to work with because we have both the revision history and
> the checked out file in each work area.  So we can play games with those
> to try and simulate the "what's changed since" operator.  It's NFS which
> screws that up.  

Not just NFS.  It's me when I back-touch files to control Make (Emacs
backtouch-mode ;-), or rename files, or my CMOS clock breaks, or I have
to do an fsck.  The last applies especially to kernel development on one
machine...

Just checking 100GB of files _locally_ is pretty tedious.

Heck, just calling _stat_ on a typical source tree can be immensely time
consuming over NFS.  Like, a minute.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[David A. Gatwood]

On Tue, 12 Sep 2000, Jamie Lokier wrote:

> I'd love to see a filesystem feature where I could efficiently identify
> "changed files", where "changed" is defined by last time this application
> checked or something similar.

An in-filesystem revision number would do the trick.  Could be REALLY
efficient.  All you have to do is stat and you know if the thing really
changed, instead of just knowing a date that can be horked.  I like!  I
like a lot!

Something else that'd be nice would be to make Linux deal better with NFS
dates.  The date presented by an NFS server for files is its timestamp. 
If the linux NFS client code were to subsequently check the stamp after
performing an operation, it could use that to approximate the time error
and this problem would about 99% disappear, with a fudge factor of under a
second.  Comments?


Later,
David

-
A brief Haiku:

Microsoft is bad.
It seems secure at first glance.
Then you read your mail.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Keith Owens]

On Mon, 11 Sep 2000 16:19:14 -0600, 
"Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
>Who pays you?  

I used to work on kdb in my own time, for free.  Then I joined SGI and
now I get paid to work on it.  If I left SGI I would continue to work
on kdb, the original kdb developer left SGI but still contributes.

>> The kernel debuggers that are kept up to date get used.  The ones that
>> are used get feedback for kernel changes which keep them up to date.
>> kdb has taken off precisely because it is being kept up to date with
>> the kernel.  And if I miss something, I know that people will tell me.
>
>I'm sure this is all true.  kdb was just rejected by Linus however, what
>message does that send to you?

That Linus does not like kernel debuggers.  This is news?  There are
several examples of code that Linus did not like originally but enough
people wanted them and they eventually got included in the kernel.
Complaining to Linus does nothing, "show me the code".

>kdb is about 1/100th the size of the MANOS debugger in terms of source
>code size, and isn't a hacked in after thought like kdb.  It uses task
>gates and other tables beneath the OS that just are not there in kdb and
>that will impinge on architectural freedom for Linus.  It also uses
>nested task gates, and requires changes to the xcall layer in Linux to
>plug it in.

kdb is not a hacked in after thought.  It was designed from scratch as
a minimalist kernel debugger which coexists with the existing kernel
design.  Note "minimalist", adding kdb to a kernel has little effect on
the running kernel, the biggest impact is the symbol table (adds 20-30%
to loaded kernel size) and the last branch recording in the page fault
handler which probably slows page faulting slightly, although I have
not measured it.

kdb does a reasonable job at the binary level which is exactly what it
was designed to do.  If you have to change the kernel design to
incorporate a debugger then you seriously need to think if your
debugger design is suitable.

>If Linus doesn't support the concept, it could be a lot of
>work.  I know my code, you know yours -- Linus habit of breaking things
>as he puts in new and better features that you stated aealier is true,
>so where does that leave us?

In exactly the same position as every other kernel developer.  Nobody
promised us that kernel APIs would remain stable in development
kernels, if it breaks we fix it in the next patch.  This is the Linux
development model, everyone else lives with it.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[David A. Gatwood]

On Mon, 11 Sep 2000, Larry McVoy wrote:

> That's a 48Kbyte/sec link.  Hardly a "horribly fast network".  In fact,

I meant FSMlabs, but yeah.  ;-)


> Second of all, if you ask around, you'll find that I'm a performance guy
> more than anything and that I'm not given to skewing the numbers and *if*
> that was your point, I resent the implication.

No, wasn't my point.  Sorry if it came out that way.  My point was for
anyone reading not to jump to conclusions based on just those numbers, and
that I'd like to see some real-world tests on comparable systems.


> Fourth, non-null pulls are similarly faster, again, by design.  BK only
> moves the data it needs to move.  That means if you have a 100GB file
> in which you have changed one byte, BK will move on the order of 1 byte
> to update that file.  And that's it - it doesn't compare the two files,
> or read the two files, or in any way look at the two files to figure out
> that they need to be updated.

This is an interesting point.  As far as changes are concerned, it should
have lower network utilization.  However, in effect, it does compare the
files.  It compared the file when you checked it into your local
repository.  It's just shifting the burden of the comparison to a local
repository instead of doing it over the network.  Faster, yes, but it
still does the same thing, just in a different way that uses less
bandwidth.


Later,
David

-
A brief Haiku:

Microsoft is bad.
It seems secure at first glance.
Then you read your mail.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Larry McVoy]

On Tue, Sep 12, 2000 at 12:24:26AM +0200, Jamie Lokier wrote:
> Larry McVoy wrote:
> > We have a hack in BK for this, at least I think we do, where we can look at
> > the time stamps to notice that you haven't modified the files.  We don't 
> > use it because of NFS screwing up timestamps.  I suppose we could enable
> > it on a per repository basis so that if you knew you were running NTP or
> > some other thing to keep your time stamps right, then we could diff as
> > fast as we can stat.  
> 
> I'd love to see a filesystem feature where I could efficiently identify
> "changed files", where "changed" is defined by last time this application
> checked or something similar.  A bonus would be to propagate this up
> directory trees.  Yes I know about hard links, and it's not necessary to
> propagate up trees in those cases.  (The application can just remember
> paths of directories containing hard links, and not depend on the
> per-directory bits for those paths).

We thought about this too (filesystems are where I got into kernel hacking),
but dismissed it as a Linux only solution.  As much as I'd like it to be
otherwise, BK is not a Linux only product.  Whatever we do needs to work on
NT (shudder) as well as all the dinosaur Unixen.

We do have more to work with because we have both the revision history and
the checked out file in each work area.  So we can play games with those
to try and simulate the "what's changed since" operator.  It's NFS which
screws that up.  
-- 
---
Larry McVoy[EMAIL PROTECTED]   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] (was: [OOPS] dquot_transfer() - 2.4.0-test8)

[Marc Duponcheel]

Hi Martin

> well, was a little bit to pessimistic. After some look at the code
> I'm pretty sure the obvious check will solve it - succesfully tested
> on local UP box.

FYI: your patch made my 2 (quota enabled) boxes happy
(they did not boot 2.4.0-test8 to completion)

Thanks!

-- Marc Duponcheel.
[work] [EMAIL PROTECTED]
[home] [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Bitkeeper vs. CVS update times (was Darkstar Development Project)

[Larry McVoy]

> The timing is typical over repeated tries.  The GCC tree contains 98.1
> megabytes of data in 9105 files, 532 directory.  A little more than
> Linux (but I don't have an unpacked fresh tree to count for sure).
> 
> I'm not going to try touching all the files.
> 
> Conclusion: CVS is pretty fast when not many files have changed.
> Comparable with BK.  Just don't touch all your local files!

That's right but not exactly very helpful for developers, I would expect.
The problem is that it works as long as you are a read only CVS user
but as you do work, it gets slower and slower.  That's a problem - it
means that the very users that have the greatest need for it to be fast
(the active developers as opposed to the read only folks), get punished
the most.

Don't get me wrong, I am fully aware that by far the vast majority
of CVS work areas are read only, in fact, I'd guess it would be more
than 99% of them.  And it's nice that CVS is fast for all those guys.
But the point is to help the *developers*, i.e., Linus & Co, and those
guys tend to have trees with changes a lot of the time.  I don't care if
the difference is 2x or 50x, I don't want the tool to be even 2x slower
for Linus than it is for some read only guy.  And more importantly,
Linus isn't going to use any tool that slows down as you start to do
real work with it.

And I'm not saying BK is fast enough, in many cases, I'm pissed that it
isn't faster and we're working on it, and will keep working on it until
it can't be any faster.  It's fast enough when you can imagine the best
way to solve a problem, count up the number of disk accesses required 
for that solution, count up BK's disk accesses, and there isn't any
difference or only a very slight one.  We aren't there yet, but we're
working on it.
-- 
---
Larry McVoy[EMAIL PROTECTED]   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Keith,

If you are volunteering to maintain the MANOS debugger after I hack it
into Linux, then I accept.  I'll give you an ftp and telnet account on
vger.timpanogas.org and you can run with it.

:-)

Jeff

"Jeff V. Merkey" wrote:
> 
> Who pays you?
> 
> Keith Owens wrote:
> >
> > On Mon, 11 Sep 2000 09:46:15 -0600,
> > "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
> > >Thanks Ted.  I know, but a kernel debugger is one of those nasty pieaces
> > >of software that can quickly get out of sync if it's maintained
> > >separately from the tree -- the speed at which changes occur in Linux
> > >would render it a very difficult project to maintain.
> >
> > Bullshit.  It takes me about 30 minutes for most 2.4 kernel patches to
> > see if kdb needs to be changed.  A combination of a decent source
> > control system (PRCS, ftp://ftp.XCF.Berkeley.EDU/pub/prcs) to merge and
> > compare source branches, a little bit of Perl to standardize the patch
> > and tkdiff to compare the old and new patches tells me very quickly if
> > I need to release a new kdb patch.  If the kernel changes might have
> > affected kdb then I compile and test, 1-5 hours depending on the extent
> > of the kernel changes.  Most of the time I don't bother compiling.
> 
> Who is paying for this, BTW.  Who pays your salary?
> 
> >
> > The kernel debuggers that are kept up to date get used.  The ones that
> > are used get feedback for kernel changes which keep them up to date.
> > kdb has taken off precisely because it is being kept up to date with
> > the kernel.  And if I miss something, I know that people will tell me.
> 
> I'm sure this is all true.  kdb was just rejected by Linus however, what
> message does that send to you?
> 
> >
> > >Linus' dislike of the kernel debugger concept would also
> > >assure that it would not be considered in design decisions moving
> > >forward, which is probably the biggest disuader in the whole debate.
> >
> > Irrelevant.  Linus can change any kernel interface in the developing
> > kernels at any time and does.  Half the time this breaks existing
> > kernel code, never mind external patches.  But we manage to keep up to
> > date with API changes.  kdb is very low level, no I/O, restricted VFS
> > and SMP dependencies.  My biggest problem is gcc changes, not the
> > kernel.
> >
> > >I don't spend money on things I believe are destined to fail.  Until Linus
> > >changes his mind, there's no point ...
> >
> > Destined to fail?  Tell that to all the people downloading and using
> > kdb and watch them laugh.
> 
> kdb is about 1/100th the size of the MANOS debugger in terms of source
> code size, and isn't a hacked in after thought like kdb.  It uses task
> gates and other tables beneath the OS that just are not there in kdb and
> that will impinge on architectural freedom for Linus.  It also uses
> nested task gates, and requires changes to the xcall layer in Linux to
> plug it in.  If Linus doesn't support the concept, it could be a lot of
> work.  I know my code, you know yours -- Linus habit of breaking things
> as he puts in new and better features that you stated aealier is true,
> so where does that leave us?
> 
> Jeff
> 
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [EMAIL PROTECTED]
> > Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

ide-pci-patch for 2.2.18pre5

[Dag Wieers]

I, or someone who was pretending to be me, found an undefined reference in
ide-pci.c, please submit this patch to 2.2.18pre5. Thanks,

--- linux/drivers/block/ide-pci.c-new   Tue Sep 12 00:11:12 2000
+++ linux/drivers/block/ide-pci.c   Tue Sep 12 00:07:51 2000
@@ -467,12 +467,12 @@
/*
 *  Don't try and tune a VIA 82C586 or 586A
 */
-   if (IDE_PCI_DEVID_RQ(devid, DEVID_VP_IDE))
+   if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_IDE))
{
autodma_default = 0;
break;
}
-   if (IDE_PCI_DEVID_RQ(devid, DEVID_VP_OLDIDE))
+   if (IDE_PCI_DEVID_EQ(devid, DEVID_VP_OLDIDE))
{
autodma_default = 0;
break;

--  dag wieers, <[EMAIL PROTECTED]>, http://mind.be/  --
   Computers are useless. They can only
   give you answers. -- Picasso


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Jamie Lokier]

Larry McVoy wrote:
> We have a hack in BK for this, at least I think we do, where we can look at
> the time stamps to notice that you haven't modified the files.  We don't 
> use it because of NFS screwing up timestamps.  I suppose we could enable
> it on a per repository basis so that if you knew you were running NTP or
> some other thing to keep your time stamps right, then we could diff as
> fast as we can stat.  

I'd love to see a filesystem feature where I could efficiently identify
"changed files", where "changed" is defined by last time this application
checked or something similar.  A bonus would be to propagate this up
directory trees.  Yes I know about hard links, and it's not necessary to
propagate up trees in those cases.  (The application can just remember
paths of directories containing hard links, and not depend on the
per-directory bits for those paths).

There are ways to do it but not much enthusiasm last time I brought it
up.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

Who pays you?  

Keith Owens wrote:
> 
> On Mon, 11 Sep 2000 09:46:15 -0600,
> "Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
> >Thanks Ted.  I know, but a kernel debugger is one of those nasty pieaces
> >of software that can quickly get out of sync if it's maintained
> >separately from the tree -- the speed at which changes occur in Linux
> >would render it a very difficult project to maintain.
> 
> Bullshit.  It takes me about 30 minutes for most 2.4 kernel patches to
> see if kdb needs to be changed.  A combination of a decent source
> control system (PRCS, ftp://ftp.XCF.Berkeley.EDU/pub/prcs) to merge and
> compare source branches, a little bit of Perl to standardize the patch
> and tkdiff to compare the old and new patches tells me very quickly if
> I need to release a new kdb patch.  If the kernel changes might have
> affected kdb then I compile and test, 1-5 hours depending on the extent
> of the kernel changes.  Most of the time I don't bother compiling.

Who is paying for this, BTW.  Who pays your salary?  

> 
> The kernel debuggers that are kept up to date get used.  The ones that
> are used get feedback for kernel changes which keep them up to date.
> kdb has taken off precisely because it is being kept up to date with
> the kernel.  And if I miss something, I know that people will tell me.

I'm sure this is all true.  kdb was just rejected by Linus however, what
message does that send to you?

> 
> >Linus' dislike of the kernel debugger concept would also
> >assure that it would not be considered in design decisions moving
> >forward, which is probably the biggest disuader in the whole debate.
> 
> Irrelevant.  Linus can change any kernel interface in the developing
> kernels at any time and does.  Half the time this breaks existing
> kernel code, never mind external patches.  But we manage to keep up to
> date with API changes.  kdb is very low level, no I/O, restricted VFS
> and SMP dependencies.  My biggest problem is gcc changes, not the
> kernel.
> 
> >I don't spend money on things I believe are destined to fail.  Until Linus
> >changes his mind, there's no point ...
> 
> Destined to fail?  Tell that to all the people downloading and using
> kdb and watch them laugh.

kdb is about 1/100th the size of the MANOS debugger in terms of source
code size, and isn't a hacked in after thought like kdb.  It uses task
gates and other tables beneath the OS that just are not there in kdb and
that will impinge on architectural freedom for Linus.  It also uses
nested task gates, and requires changes to the xcall layer in Linux to
plug it in.  If Linus doesn't support the concept, it could be a lot of
work.  I know my code, you know yours -- Linus habit of breaking things
as he puts in new and better features that you stated aealier is true,
so where does that leave us?

Jeff



> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Jamie Lokier]

Larry McVoy wrote:
> That's a benefit [for BK] of having changesets, I only need to compare
> the ChangeSet file to know that 4 files were updated 2 were moved, and
> 5 were created, then I move those *portions* of those files across the
> wire.

What happens when I lose the ChangeSet file, or misplace it?

> Other than the initial repository create (aka cvs checkout), BK
> *never* moves an entire file across the wire.  Never means never and
> includes the process of deciding what to do.  CVS moves whole files
> just to discover there is nothing to do.

Yes, CVS over rsync is much better for that.  IMHO the ideas underlying
the rsync protocol are most cool.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Booting into /bin/bash

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Richard B. Johnson <[EMAIL PROTECTED]> wrote:
>Whmm. I have a shell-script that makes a RAM-Disk bootable "Rescue Disk".
>It allows one to boot from two floppies and repair stuff, even execute
>vi, fdisk, mke2fs, tar, tar-gz, etc. Just about everything one would
>need (even modules) to rescue a system.
>
>However, ^C does not stop anything. No signal gets sent to anybody.
>I don't want to make it too large because it won't fit on a floppy
>if I do.

That means you don't have a controlling tty.

Try opening /dev/tty1 instead of /dev/console. Something like this
should do it:

#! /bin/bash

# Get a real controlling tty instead of /dev/console
exec 0<>/dev/tty1 1>&0 2>&0

Mike.
-- 
Deadlock, n.:
Deceased rastaman.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Larry McVoy]

On Tue, Sep 12, 2000 at 12:09:29AM +0200, Juan J. Quintela wrote:
> > "david" == David A Gatwood <[EMAIL PROTECTED]> writes:
> But I think that the null update is a "typical" usage, and more
> typical indeed a cvs diff (and how that it is spelled in bk).  I want
> to be able to use cvs diff for a whole tree, when I have changed only
> 2-5 files to be very fast, (i.e. speed of diff -r between hardlinkend
> trees).

We have a hack in BK for this, at least I think we do, where we can look at
the time stamps to notice that you haven't modified the files.  We don't 
use it because of NFS screwing up timestamps.  I suppose we could enable
it on a per repository basis so that if you knew you were running NTP or
some other thing to keep your time stamps right, then we could diff as
fast as we can stat.  
-- 
---
Larry McVoy[EMAIL PROTECTED]   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Larry McVoy]

On Mon, Sep 11, 2000 at 02:58:25PM -0700, David A. Gatwood wrote:
> > On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
> > > > Err, "faster"?  The following is the moral equiv of 4 kernel updates
> > > > which had nothing to do using BitKeeper instead of CVS.  The local copy
> > > > was in San Francisco and the remote copy is Cort's machine in New Mexico
> > > > over a 384Kbits/sec link.  All 4 updates in 5 seconds.  Anyone have a
> > > > CVS tree they can try to get comparable numbers?
> > >
> > > Try: http://innominate.org/~tgr/projects/lksr/
> >
> > Thanks, that was helpful.  Comparison numbers for a null update of the
> > 2.3 kernel, which means you update and then update again, timing the
> > second update to get some idea of the system's best case throughput,
> > are:
> >
> > CVS: 139.5 seconds
> > BK:1.6 seconds
> >
> > The BK tree is the 2.3 kernel tree maintained by FSMlabs.
> 
> All right, this is ridiculous.  Those statistics are worthless.  The BK
> tree was on a horribly fast network and the CVS repository was on a
> horribly slow one.  There's just no way that BK is that much faster than
> CVS in a comparable environment.
> 
> I'm sorry, but I can't believe those numbers.  It takes longer than 1.6
> seconds to stat all the kernel directories unless the BK machine has a
> huge disk cache.  

Calm down, David.  BK really is pretty fast.  Here's a point by point 
rebuttal to your mail.

First of all, I don't think you read the mail.  Let me quote:

> > > > over a 384Kbits/sec link.  

That's a 48Kbyte/sec link.  Hardly a "horribly fast network".  In fact,
the bandwidth to FSMlabs.com and innominate.org seems to be identical,
I suspect that my link is the bottleneck, not either of theirs.
In order for the link to be the reason for the performance difference,
innominate.org would need to be a .9Kbyte/second link.  I kinda doubt
that seeing as a 128MB cvs checkout took 23 minutes (works out to around
90Kbyte/sec uncompressed, so cvs must compress it, so I'd guesstimate
they have around a 30Kbyte/sec link or so).

Second of all, if you ask around, you'll find that I'm a performance guy
more than anything and that I'm not given to skewing the numbers and *if*
that was your point, I resent the implication.

Third, BK is designed to be that much faster.  It's inherent in the
nature of a distributed repositories with changesets.  I can, and did,
reboot the machine, did the test again, and it took an average of 1.56
seconds per tree to do a null pull.

Fourth, non-null pulls are similarly faster, again, by design.  BK only
moves the data it needs to move.  That means if you have a 100GB file
in which you have changed one byte, BK will move on the order of 1 byte
to update that file.  And that's it - it doesn't compare the two files,
or read the two files, or in any way look at the two files to figure out
that they need to be updated.  It knows.  That's a benefit of having 
changesets, I only need to compare the ChangeSet file to know that 4 files
were updated 2 were moved, and 5 were created, then I move those *portions*
of those files across the wire.  Other than the initial repository create
(aka cvs checkout), BK *never* moves an entire file across the wire.
Never means never and includes the process of deciding what to do.  CVS
moves whole files just to discover there is nothing to do.
-- 
---
Larry McVoy[EMAIL PROTECTED]   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Bitkeeper vs. CVS update times (was Darkstar Development Project)

[Jamie Lokier]

David A. Gatwood wrote:
> I'm sorry, but I can't believe those numbers.  It takes longer than 1.6
> seconds to stat all the kernel directories unless the BK machine has a
> huge disk cache.  It sounds like the BK server was a much more powerful
> machine.

Use treescan for fast stat preload :-)  Anyway, of course all the stat
info is in cache.  This is a null update run after another null update...

> 1.Raw checkout of a full tree
> 2.Raw checkin of a full tree
> 
> and does not include a "null update", as that is an atypical usage pattern
> for most trees that unfairly skews the test towards software or kernels
> that does caching of file stat results, which has little bearing on
> typical use.

Actually "null update" is quite typical of CVS usage.  You do it often
(like, daily or more) to keep up to date with recent changes, and
definitely before submitting a patch.

When there are changes, "nearly null update" is closer to what happens.

Do you really do full checkouts and checkins that often?  I don't on the
CVS projects I manage.

> Critically, the test should be with two otherwise identically configured
> servers and two identically configured clients, across identical networks.
> Only then do the tests mean anything.  I'd be very curious to see the
> results.  :-)

BK should be faster simply because it's designed to be fast.
However, let's try another project: GCC.

I am at CERN in Switzerland.  Good net connection but transatlantic.
Ping time 300-400ms to anoncvs.cygnus.com.

Just now, I did "cvs update" from the EGCS project repository.

real0m36.738s
user0m6.790s
sys 0m4.070s

Quite a lot of files were updated.  I did "treescan -stat -silent ." to
pull stat information into my local cache first.

Now here's a "null update":

real0m8.786s
user0m2.240s
sys 0m0.520s

The timing is typical over repeated tries.  The GCC tree contains 98.1
megabytes of data in 9105 files, 532 directory.  A little more than
Linux (but I don't have an unpacked fresh tree to count for sure).

I'm not going to try touching all the files.

Conclusion: CVS is pretty fast when not many files have changed.
Comparable with BK.  Just don't touch all your local files!

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Juan J. Quintela]

> "david" == David A Gatwood <[EMAIL PROTECTED]> writes:

Hi
[stuff about unfair test]

I don't arguee if the test was fair or not.

david> and does not include a "null update", as that is an atypical usage pattern
david> for most trees that unfairly skews the test towards software or kernels
david> that does caching of file stat results, which has little bearing on
david> typical use.

But I think that the null update is a "typical" usage, and more
typical indeed a cvs diff (and how that it is spelled in bk).  I want
to be able to use cvs diff for a whole tree, when I have changed only
2-5 files to be very fast, (i.e. speed of diff -r between hardlinkend
trees).

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Keith Owens]

On Mon, 11 Sep 2000 09:46:15 -0600, 
"Jeff V. Merkey" <[EMAIL PROTECTED]> wrote:
>Thanks Ted.  I know, but a kernel debugger is one of those nasty pieaces
>of software that can quickly get out of sync if it's maintained
>separately from the tree -- the speed at which changes occur in Linux
>would render it a very difficult project to maintain.

Bullshit.  It takes me about 30 minutes for most 2.4 kernel patches to
see if kdb needs to be changed.  A combination of a decent source
control system (PRCS, ftp://ftp.XCF.Berkeley.EDU/pub/prcs) to merge and
compare source branches, a little bit of Perl to standardize the patch
and tkdiff to compare the old and new patches tells me very quickly if
I need to release a new kdb patch.  If the kernel changes might have
affected kdb then I compile and test, 1-5 hours depending on the extent
of the kernel changes.  Most of the time I don't bother compiling.

The kernel debuggers that are kept up to date get used.  The ones that
are used get feedback for kernel changes which keep them up to date.
kdb has taken off precisely because it is being kept up to date with
the kernel.  And if I miss something, I know that people will tell me.

>Linus' dislike of the kernel debugger concept would also
>assure that it would not be considered in design decisions moving
>forward, which is probably the biggest disuader in the whole debate.

Irrelevant.  Linus can change any kernel interface in the developing
kernels at any time and does.  Half the time this breaks existing
kernel code, never mind external patches.  But we manage to keep up to
date with API changes.  kdb is very low level, no I/O, restricted VFS
and SMP dependencies.  My biggest problem is gcc changes, not the
kernel.

>I don't spend money on things I believe are destined to fail.  Until Linus
>changes his mind, there's no point ...

Destined to fail?  Tell that to all the people downloading and using
kdb and watch them laugh.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Jamie Lokier]

Larry McVoy wrote:
> On the other hand, if you do a
> 
> find . -type f | xargs touch
> time cvs update .
> 
> it will melt down your DSL line for what seems forever.  I killed it after
> 20 minutes, I have better things to do with my bandwidth.   It's pretty
> clear that CVS is comparing timestamps so if your files get modified at
> all, it's going to transfer them to see what needs to be updated.  The
> same sort of "touch all, then update" operation in BK has no effect on
> performance, BK doesn't do its work that way.

The recommended way to do CVS in such situations is rsync your local
tree with somewhere closer to the CVS server.  Of course it's obvious
CVS should have something rsync-like built in.
I bet BK does exactly that :-)

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[David A. Gatwood]

On Mon, 11 Sep 2000, Larry McVoy wrote:

> 
> On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
> > > Err, "faster"?  The following is the moral equiv of 4 kernel updates
> > > which had nothing to do using BitKeeper instead of CVS.  The local copy
> > > was in San Francisco and the remote copy is Cort's machine in New Mexico
> > > over a 384Kbits/sec link.  All 4 updates in 5 seconds.  Anyone have a
> > > CVS tree they can try to get comparable numbers?
> >
> > Try: http://innominate.org/~tgr/projects/lksr/
> 
> Thanks, that was helpful.  Comparison numbers for a null update of the
> 2.3 kernel, which means you update and then update again, timing the
> second update to get some idea of the system's best case throughput,
> are: 
> 
> CVS: 139.5 seconds
> BK:1.6 seconds
> 
> The BK tree is the 2.3 kernel tree maintained by FSMlabs.

All right, this is ridiculous.  Those statistics are worthless.  The BK
tree was on a horribly fast network and the CVS repository was on a
horribly slow one.  There's just no way that BK is that much faster than
CVS in a comparable environment.

I'm sorry, but I can't believe those numbers.  It takes longer than 1.6
seconds to stat all the kernel directories unless the BK machine has a
huge disk cache.  It sounds like the BK server was a much more powerful
machine.

Also, the innominate server is WAY out.  It took _25_ hops to get to that
server from here.  It only took 11 to fsmlabs.  Since bitmover is in San
Jose as I am (or at least bitmover.com's server is), I suspect you will
see a similarly dramatic difference in the distance.  That's just not a
valid test by any measure.

I'd like someone to do a valid test of these two systems, as I'm curious
myself as to which is faster.  A valid test includes the following things:

1.  Raw checkout of a full tree
2.  Raw checkin of a full tree

and does not include a "null update", as that is an atypical usage pattern
for most trees that unfairly skews the test towards software or kernels
that does caching of file stat results, which has little bearing on
typical use.

Critically, the test should be with two otherwise identically configured
servers and two identically configured clients, across identical networks.
Only then do the tests mean anything.  I'd be very curious to see the
results.  :-)


Later,
David

-
A brief Haiku:

Microsoft is bad.
It seems secure at first glance.
Then you read your mail.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Booting into /bin/bash

[Richard B. Johnson]

On Mon, 11 Sep 2000, Adam wrote:

> > Does anybody know off the top of their head if there is an easy
> > way to have ^C work with /bin/bash as a shell, without having
> > to set up ptys?? Just setting terminal parameters to allow signals
> > doesn't do anything.
> 
> not exactly the answer, but what I do is just run command 'open bash' few
> times and create in this way few ready-to-use shells.
> 

Whmm. I have a shell-script that makes a RAM-Disk bootable "Rescue Disk".
It allows one to boot from two floppies and repair stuff, even execute
vi, fdisk, mke2fs, tar, tar-gz, etc. Just about everything one would
need (even modules) to rescue a system.

However, ^C does not stop anything. No signal gets sent to anybody.
I don't want to make it too large because it won't fit on a floppy
if I do.

I thought I did everything right, but

The shell-script is appended.


Cheers,
Dick Johnson

Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.



#!/bin/sh
#
#
export VER=$1
RAMDISK_IMAGE=/tmp/RamImage-${VER}
RAMDISK=/tmp/Ramdisk
TMPF=/tmp/TmpExe
TMPC=/tmp/TmpC.c
DISKSIZE=4096
SYS=/usr/src/linux-${VER}/arch/i386/boot/bzImage
if [ "$1" = "" ] ;
   then
   echo "Usage:"
   echo "Make_Rescue "
   exit 1
fi
if [ ! -f ${SYS} ] ;
   then
echo "File not found, ${SYS}"
exit 1
fi
if ! dd if=/dev/fd0 of=/dev/null bs=1k count=1 2>/dev/null ;
then
   echo "Floppy drive error!"
   echo "Maybe no diskette in the drive?"
   exit 1
fi
#
#  Make a RAM Disk file and mount it using the loop device.
#  Remove the lost+found directory to save space.
#

umount ${RAMDISK} 2>/dev/null
rm -rf ${RAMDISK} 2>/dev/null
mkdir  ${RAMDISK} 2>/dev/null
dd if=/dev/zero of=${RAMDISK_IMAGE} bs=1k count=${DISKSIZE}
/sbin/mke2fs -Fq ${RAMDISK_IMAGE} ${DISKSIZE}
mount -o loop -t ext2 ${RAMDISK_IMAGE} ${RAMDISK}
rmdir ${RAMDISK}/lost+found
#
#  Make the required directories in the RAM Disk.
#
mkdir -m 777 ${RAMDISK}/dev
mkdir -m 777 ${RAMDISK}/etc
mkdir -m 777 ${RAMDISK}/lib
mkdir -m 777 ${RAMDISK}/usr
mkdir -m 777 ${RAMDISK}/usr/local
mkdir -m 777 ${RAMDISK}/usr/bin
mkdir -m 777 ${RAMDISK}/sbin
mkdir -m 777 ${RAMDISK}/tmp
mkdir -m 777 ${RAMDISK}/proc
mkdir -m 777 ${RAMDISK}/mnt
#
#  Make the required devices.
#
mknod ${RAMDISK}/dev/null   c 1 3
mknod ${RAMDISK}/dev/ram0   b 1 0 
mknod ${RAMDISK}/dev/ram1   b 1 1
mknod ${RAMDISK}/dev/memc 1 1
mknod ${RAMDISK}/dev/ttyS0  c 4 64 
mknod ${RAMDISK}/dev/tty0   c 4 0
mknod ${RAMDISK}/dev/tty1   c 4 1
mknod ${RAMDISK}/dev/tty2   c 4 2
mknod ${RAMDISK}/dev/tty3   c 4 3
mknod ${RAMDISK}/dev/tty4   c 4 4
mknod ${RAMDISK}/dev/ttyc 5 0
mknod ${RAMDISK}/dev/ttyp0  c 3 0
mknod ${RAMDISK}/dev/ttyp1  c 3 1 
mknod ${RAMDISK}/dev/ttyp2  c 3 2 
mknod ${RAMDISK}/dev/ttyp3  c 3 3 
mknod ${RAMDISK}/dev/ttyp4  c 3 4 
mknod ${RAMDISK}/dev/ttyp5  c 3 5 
mknod ${RAMDISK}/dev/ptyp0  c 2 0 
mknod ${RAMDISK}/dev/ptyp1  c 2 1 
mknod ${RAMDISK}/dev/ptyp2  c 2 2 
mknod ${RAMDISK}/dev/ptyp3  c 2 3 
mknod ${RAMDISK}/dev/ptyp4  c 2 4 
mknod ${RAMDISK}/dev/ptyp5  c 2 5 
mknod ${RAMDISK}/dev/zero   c 1 5
mknod ${RAMDISK}/dev/sdab 8 0
mknod ${RAMDISK}/dev/sda1   b 8 1
mknod ${RAMDISK}/dev/sda2   b 8 2 
mknod ${RAMDISK}/dev/sdbb 8 16
mknod ${RAMDISK}/dev/sdb1   b 8 17
mknod ${RAMDISK}/dev/sdb2   b 8 18
mknod ${RAMDISK}/dev/sdcb 8 32
mknod ${RAMDISK}/dev/sdc1   b 8 33
mknod ${RAMDISK}/dev/sdc2   b 8 34
mknod ${RAMDISK}/dev/st0c 9 0
mknod ${RAMDISK}/dev/st1c 9 1
mknod ${RAMDISK}/dev/st2c 9 2
mknod ${RAMDISK}/dev/st3c 9 4
mknod ${RAMDISK}/dev/st4c 9 5
mknod ${RAMDISK}/dev/fd0b 2 0
mknod ${RAMDISK}/dev/hdab 3 0
mknod ${RAMDISK}/dev/hda1   b 3 1
mknod ${RAMDISK}/dev/hda2   b 3 2
#
#  Set some compatibility links.
#
ln -s /dev/tty0 ${RAMDISK}/dev/systty
ln -s /dev/tty0 ${RAMDISK}/dev/console
ln -s /dev/ram1 ${RAMDISK}/dev/ram
ln -s /lib  ${RAMDISK}/usr/lib
ln -s /sbin ${RAMDISK}/bin
ln -s /lib  ${RAMDISK}/usr/local/lib
ln -s /lib/ld-linux.so.2${RAMDISK}/lib/ld.so
ln -s /sbin/bash${RAMDISK}/sbin/sh
ln -s /sbin/gunzip  ${RAMDISK}/sbin/gzip
#
#
#  Copy some files and libraries.
#
files="modprobe bash rm mkdir rmdir cat ls cp mount umount \
insmod gunzip tar df" 

for x in $files ; do cp `which $x` ${TMPF} ; strip ${TMPF} ;\
  cp ${TMPF} ${RAMDISK}/sbin/$x ; done
 
cp /lib/libc.so.6   ${TMPF}
strip   ${TMPF}
cp ${TMPF}  ${RAMDISK}/lib/libc.so.6

cp /lib/libm.so.6   ${TMPF}
strip   

Re: Availability of kdb

[Rik van Riel]

On Mon, 11 Sep 2000, Jamie Lokier wrote:
> Jeff V. Merkey wrote:

> > In NetWare, we didn't care if the page was touched or not since we
> > used our own bits in field bits 11-9 to store page specific stuff,
> > like whether the page was dirty or not.
> 
> Linux does actually look at both bits, but the optimisation
> still applies.  Accessed in particular -- ptes are mapped on
> page faults so you know the page is about to be accessed.

The main difference between Linux and Netware here is the
fact that Linux has a real userland, which can touch the
pages on its own without going through the kernel.

This causes "spontaneously" dirtied or accessed pages,
meaning that we really want to use the hardware bits ...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Larry McVoy]

On Mon, Sep 11, 2000 at 02:08:42PM -0700, Larry McVoy wrote:
> 
> On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
> > > Err, "faster"?  The following is the moral equiv of 4 kernel updates
> > > which had nothing to do using BitKeeper instead of CVS.  The local copy
> > > was in San Francisco and the remote copy is Cort's machine in New Mexico
> > > over a 384Kbits/sec link.  All 4 updates in 5 seconds.  Anyone have a
> > > CVS tree they can try to get comparable numbers?
> >
> > Try: http://innominate.org/~tgr/projects/lksr/
> 
> Thanks, that was helpful.  Comparison numbers for a null update of the 2.3
> kernel, which means you update and then update again, timing the second update
> to get some idea of the system's best case throughput, are:
> 
> CVS: 139.5 seconds
> BK:1.6 seconds

In fairness to CVS, I ran this a third time and got 78 seconds, so the net
must have been busy.  It's still about a 50:1 performance difference.

On the other hand, if you do a

find . -type f | xargs touch
time cvs update .

it will melt down your DSL line for what seems forever.  I killed it after
20 minutes, I have better things to do with my bandwidth.   It's pretty
clear that CVS is comparing timestamps so if your files get modified at
all, it's going to transfer them to see what needs to be updated.  The
same sort of "touch all, then update" operation in BK has no effect on
performance, BK doesn't do its work that way.
-- 
---
Larry McVoy[EMAIL PROTECTED]   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: sound in 2.4.0test8 (cs46xx.c)

[UK Steve]

Hi, Bernd & Fellow 'Kernel Krunchers' :-),

Ciao Amigos,

How yer all doin'?

Bernd, mate, I've not long since experienced more or less the exact same problem
that you've recently experienced.

After four attempts at unsuccessfully trying to overcome this irritatin'
problem (on kernels 2.4.0-test7 & 8), and as such, attemptin' to obtain a full
'audio' compilation, I too decided to see if the same problem occurred when I
moved on to compiling 2.2.18pre4.

Fortunately, like yourself, Bernd, mate, in doin' so, everything went smoothly.

Without going into too much technical detail, I'm running a customised version
of Mandrake 7, on an extremely tired, yet much-loved and 99% reliable (most
of the f*ckin' time :-)) P166 on a TX motherboard with 96 Mb RAM...ridin'
alongside a 10Gb IDE drive, etc., etc., etc..

So, Bernd, mate...if it's of any consolation, you're not the only person
experiencin' this problem.

However, I've just this minute read the comments made by Rasmus Andersen
(who, I'd just like to personally thank - cheers, mate!) in response to your
comments; and am therefore just about to recompile 'K' 2.4.0-test8 and make the
alterations/adjustments recommended by Rasmus. 

All the best & thanks a lot for the problem shared; not to mention, Rasmus's
invaluable advice...

I'd just like to extend my thanks to Linus and the dedicated team of Linux
gurus around the globe, for givin' me the opportunity to experience the
excellence, fascination and wonderment, that is 'Linux'...

Cheers!

Steve Weatherburn!



On Mon, 11 Sep 2000, Bernd Jucknischke wrote:
> Hi there!
> 
>   I've just tried to compile a 2.4.0-test8 on an IBM thinkpad T20 and got the   
> following error:
> 
>   cs46xx.c: 107: warning: `SND_DEV_DSP16' redefined
>   /usr/src/linux/include/sound.h: 12: warning: this is the location of the
>   previous definition
>   cs46xx.c: 2488: cards causes a section type conflict
>   cs46xx.c: 2630: warning: `cs_remove' defined but never used
> 
>   due to this test8 doesn't compile (had to disable the driver). I tried the
> 2.2 branch of the kernel (2.2.18pre2) and all went well.  I've mailed this
> compilation error to Alan Cox. He answered he'd only work on 2.2 at the moment
> and there it runs well...
> 
>   TIA,
> 
> Bernd
> 
> PS: CC me in answers to this mail since I'm not on the list.
> -- 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Linux 2.2.18pre5

[Alan Cox]

2.2.18pre5
o   Added older VIA ide chipsets to the not to be   (me)
autotuned list
o   Fix crash on boot problem with __setup stuff(me)
o   Small acenic fix(Matt Domsch)
o   Fix hfc_pci isdn driver (Jens David)
o   Fix smbfs configuration problem (Urban Widmark)
o   Emu10K wrapper/build fixes  (Rui Sousa)
o   Small cleanups  (Arjan van de Ven)
o   Fix sparc32 build bug   (Horst von Brand)
o   Fix quota oops  (Martin Diehl)
o   Add i810 random number driver   (Jeff Garzik)
o   Clear suid bits on ext2 truncate as per SuS (Andi Kleen)
o   Fix illegal use of section attributes   (Arjan van de Ven)
o   Documentation for nmi watchdog  (Marcelo Tosatti)
o   Fix uninitialised variable warnings (Arjan van de Ven)
o   Save DR6 condition into the TSS (Ryan Wallach)
o   Add additional __init's to the kernel   (Andrzej M. Krzysztofowicz)
o   Backport 2.4 wdt_pci driver (JP Nollman, me)
o   AGP i810 fixes  (Chip Salzenberg)
o   UDMA support for ALI1543 & 1543C IDE devices(ALI)
o   2.4 MSR/CPUID driver backport   (Dave Jones, 
H Peter Anvin)
o   Fix incorrect use of kernel v user ptr in NCPfs (Petr Vandrovec)
o   Updated scsi tape driver(Kai Makisara)

2.2.18pre4
o   Remove the aacraid driver again, having looked  (me)
at what is needed to make it acceptable and 
debug it - Im dumping it back on Adaptec
o   DAC960 update   (Leonard Zubkoff)
o   Add setup vmlinuz.lds changes for Sparc (Arjan van den Ven)
o   Sparc updates for drm, ioctl and other  (Dave Miller)
o   Megaraid driver update  (Peter Jarrett)
o   Add cd volume 0 to the amp power off on the
crystal cs46xx  (Bill Nottingham)
o   Fix IPV6 fragment and kfree bugs(Alexey Kuznetsov)
o   Fix emu10k build bug(me)
o   Emu10K driver upgrade. Adds emu-aps support (Rui Sousa)
o   Updated IBM serveraid driver to 4.20(IBM)
o   Ext2 block handling cleanup from 2.4(Al Viro)
o   Make the ATI128 driver modular  (Marcelo Tosatti)
o   Fix megaraid build bug with gcc 2.7.2   (Arjan van de Ven)
o   Fix some of the dquot races (Jan Kara)
o   x86 setup code cleanup  (Dave Jones)
o   Implement 2.4 compatible __setup and __initcall (Arjan van de Ven)
o   Tidy up smp_call_function stuff (Keitaro Yosimura)
o   Remove 2.4 compat glue from cs4281 driver   (Marcelo Tosatti)
o   Fix minor bugs in bluesmoke now someone actually
has a faulty CPU and logs   (me)
o   Fix definition of IPV6_TLV_ROUTERALERT  (Dave Miller)
o   Fix in6_addr, ip_decrease_ttl, other(Dave Miller)
minor bits
o   cp932 fixes (Kazuki Yasumatsu)
o   Updated gdth driver (Andreas Koepf)
o   Acenic update   (Jes Sorensen)
o   Update USB serial drivers   (Greg Kroah-Hartman)
o   Move pci_resource_len into pci compat   (Marcelo Tosatti)

2.2.18pre3  (versus 2.2.17pre20)
o   Clean up most of the compatibility macros   (me)
that various people use. I've systematically
moved the 100% correct ones to the headers
used in 2.4
o   Fix newly introduced bug in kmem_cache_shrink   (Daniel Roesen)
o   Further updates to symbios drivers  (Gerhard Roudier)
o   Remove emu10K warning and mtrr warning  (Daniel Roesen)
o   Fix symbol clash between cs4281 and esssolo1(Arjan van de Ven)
o   Fix acenic non modular/module build issues  (Arjan van de Ven)
o   Fix bug in alpha csum_partial_copy that could   (Herbert Xu)
cause spurious EFAULTs
o   Yet another eepro100 variant sighted(Torben Mathiasen)
o   Minor microcode.c final tweak   (Daniel Roesen)
o   Document that ATIFB is now modular  (Marcelo Tosatti)
o   Parport update  (Tim Waugh)
o   First set of ext2 updates/fixes (Al Viro)
o   Bring smbfs back into line with 2.2 (Urban Widmark)
| This should make OS/2 work again
o   Fix S/390 _stext (still doesnt build dasd)  (Kurt Roeckx)
o   Remove unused 

Re: Availability of kdb

[Rik van Riel]

On Mon, 11 Sep 2000, Jamie Lokier wrote:
> Rik van Riel wrote:
> > The main difference between Linux and Netware here is the
> > fact that Linux has a real userland, which can touch the
> > pages on its own without going through the kernel.
> > 
> > This causes "spontaneously" dirtied or accessed pages,
> > meaning that we really want to use the hardware bits ...
> 
> Of course you don't _have_ to do things that way with a real
> userland. You can take page faults and update your own bits.  I
> think some of the ports actually do this.

Meaning you have to blindly unmap pages and see if they get
faulted back in again. I believe you need to do this trick
with the VAX (and OpenBSD and NetBSD still use this method).

> But we prefer the hardware, even though in some cases
> software-driven faults give better guidance to the paging
> heuristics.

The difference is a locked cycle vs. handling a page fault.
This isn't a very hard choice to make ;)

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
   -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/   http://www.surriel.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Booting into /bin/bash

[Adam]

> Does anybody know off the top of their head if there is an easy
> way to have ^C work with /bin/bash as a shell, without having
> to set up ptys?? Just setting terminal parameters to allow signals
> doesn't do anything.

not exactly the answer, but what I do is just run command 'open bash' few
times and create in this way few ready-to-use shells.

-- 
Adam
http://www.eax.com  The Supreme Headquarters of the 32 bit registers


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: write permissions and root.

[Andrew McNabb]

On Mon, 11 Sep 2000, Igmar Palsenberg wrote:

> > Correct me if I'm wrong, but I believe that all non-TOS
> > unices have behaved this way since the 70s.
> 
> I see no reason why it shouldn't behave this way. Root can do su - user
> and screw up the file that way.
> 
> Users with UID 0 are capable of doing about anything possible.

In a non-TOS system, you are correct.  The alternative I was
referring to is a Trusted Operating System, where UID 0 has
no more power than any other user.  The point of my original
message was that in a standard, non-trusted UNIX, the current
behavior is correct.


--
Andrew McNabb
[EMAIL PROTECTED]
http://www.mcnabbs.org/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

a bug in the command-line parser

[OKUJI Yoshinori]

  I found a bug in the command-line parser, parse_options in
init/main.c. I examined only 2.2.16 and 2.2.17, but there might remain
the same problem in 2.4.0-test?.

  The phenomenon is that argv_init becomes {"init", "", NULL}, when
one inputs a command-line like:

root=/dev/ram  ro
 ^^
  two spaces

This is harmful for some shell programs. You might think he just
need to be careful enough not to insert multiple spaces between two
options, but things are not so trivial. On i386 (I haven't tested any
other architecture), "mem=XXX" is handled in arch/i386/kernel/setup.c
but the function setup_arch doesn't remove any space after the option
correctly, so if the user enters "mem=128M root=/dev/hda", the string
command_line returned by the function setup_arch will be
" root=/dev/hda" instead of "root=/dev/hda", and then argv_init will
be {"init", "", NULL}, even though the user doesn't input multiple
spaces.

  It is possible to avoid this problem in boot loaders (yes, in fact,
I did in GRUB), but I think it would be better to fix the bug itself
in Linux. Thus, I propose this simple patch:

*** linux-2.2.17.orig/init/main.c   Tue Sep  5 02:39:28 2000
--- linux-2.2.17/init/main.cTue Sep 12 06:02:34 2000
***
*** 1254,1259 
--- 1254,1262 
  }
  if (next != NULL)
  *next++ = 0;
+   if (!*line)
+   continue;
+   
/*
 * check for kernel options first..
 */


Thanks,
Okuji
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Booting into /bin/bash

[Richard B. Johnson]

Does anybody know off the top of their head if there is an easy
way to have ^C work with /bin/bash as a shell, without having
to set up ptys?? Just setting terminal parameters to allow signals
doesn't do anything.

Cheers,
Dick Johnson

Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jamie Lokier]

Rik van Riel wrote:
> The main difference between Linux and Netware here is the
> fact that Linux has a real userland, which can touch the
> pages on its own without going through the kernel.
> 
> This causes "spontaneously" dirtied or accessed pages,
> meaning that we really want to use the hardware bits ...

Of course you don't _have_ to do things that way with a real userland.
You can take page faults and update your own bits.  I think some of the
ports actually do this.

But we prefer the hardware, even though in some cases software-driven
faults give better guidance to the paging heuristics.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.2.18pre4

[Martin Diehl]

On Sun, 10 Sep 2000, Alan Cox wrote:

> 2.2.18pre4
> o Fix some of the dquot races (Jan Kara)

this appears to be basically the same patch as applied to 2.4.0t8 vs. t7
producing an Oops in dquot_transfer(). This issue can (at least) be
triggered by chown'ing a file on an (userquota && !groupquota) filesystem
from an user with unlimited quota to one who is restricted.
I've sent a fix for this to the diskquota-maintainer ([EMAIL PROTECTED])
and l-k yesterday. With a few lines offset the same patch should be
applicable to 2.2.18pre4 - but haven't tested in this context!

Martin

--- linux-2.4.0-test8/fs/dquot.c.orig   Mon Sep 11 01:42:56 2000
+++ linux-2.4.0-test8/fs/dquot.cMon Sep 11 02:12:04 2000
@@ -1285,12 +1285,15 @@
blocks = isize_to_blocks(inode->i_size, BLOCK_SIZE_BITS);
else
blocks = (inode->i_blocks >> 1);
-   for (cnt = 0; cnt < MAXQUOTAS; cnt++)
+   for (cnt = 0; cnt < MAXQUOTAS; cnt++) {
+   if (transfer_to[cnt] == NODQUOT)
+   continue;
if (check_idq(transfer_to[cnt], 1) == NO_QUOTA ||
check_bdq(transfer_to[cnt], blocks, 0) == NO_QUOTA) {
cnt = MAXQUOTAS;
goto put_all;
}
+   }
 
if ((error = notify_change(dentry, iattr)))
goto put_all; 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Larry McVoy]

On Mon, Sep 11, 2000 at 09:55:01PM +0200, Jamie Lokier wrote:
> > Err, "faster"?  The following is the moral equiv of 4 kernel updates
> > which had nothing to do using BitKeeper instead of CVS.  The local copy
> > was in San Francisco and the remote copy is Cort's machine in New Mexico
> > over a 384Kbits/sec link.  All 4 updates in 5 seconds.  Anyone have a
> > CVS tree they can try to get comparable numbers?
> 
> Try: http://innominate.org/~tgr/projects/lksr/

Thanks, that was helpful.  Comparison numbers for a null update of the 2.3
kernel, which means you update and then update again, timing the second update
to get some idea of the system's best case throughput, are:

CVS: 139.5 seconds
BK:1.6 seconds

The BK tree is the 2.3 kernel tree maintained by FSMlabs.
-- 
---
Larry McVoy[EMAIL PROTECTED]   http://www.bitmover.com/lm 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: bizarre problems with Athlon system after upgrdaing motherboard

[Alan Cox]

> > When we upgraded the motherboard, we got consistant GPFs right after
> > the line:
> > Enabling extended fast FPU save
> 
> It sounds like Redhat patched the kernel to support the Pentium III XMM
> extensions and the kernel is misdetecting the Athlon as a PIII.

The Athlon claims to support FXSAVE, so I dont think that explains it. There
is a problem with the older RH kernel (2.2.14 one) which sees the PSN flag
is set and tries to disable PSN but the AMD chips use the flag for a
different purpose

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

PROBLEM: Xircom Realport gets MAC 00:00:00...... Card known good.

[Dag B]

This is very verbose. Sorry. I much prefer to toss all the pieces on the
table at the same time.

Dag B

[1.] One line summary of the problem: 
-test7/8 version of xircom_tulip_cb does not enable my Xircom Realport
(RBEM56G-100)

Nor any of the other kernels I have tried...

   
[2.] Full description of the problem/report:
My Xircom Realport (RBEM56G-100) is causing headaches. It works with
NT4/SP5 on my Dell CPi laptop, so the hardware is functional. (Tested
this morning. )
When loading the xircom_tulip_cb.c:v0.91 driver, things looks ok, until
you study the MAC address, which is all zeros. What follows is the
output from -test7 and test8:

-test7:
Linux PCMCIA Card Services 3.1.11
  options:  [pci] [cardbus] [pm]
Yenta IRQ list 0098, PCI irq11
Socket status: 3006
Yenta IRQ list 0098, PCI irq11
Socket status: 3020
devfs: v0.102 (2622) Richard Gooch ([EMAIL PROTECTED])
devfs: boot_options: 0x0
kmem_create: Forcing size word alignment - nfs_fh
cs: cb_alloc(bus 4): vendor 0x115d, device 0x0003
PCI: Failed to allocate resource 1 for PCI device 115d:0003
PCI: Failed to allocate resource 2 for PCI device 115d:0003
PCI: Failed to allocate resource 6 for PCI device 115d:0003
PCI: Enabling device 04:00.0 ( -> 0003)
PCI: Failed to allocate resource 1 for PCI device 115d:0103
PCI: Failed to allocate resource 2 for PCI device 115d:0103
PCI: Failed to allocate resource 6 for PCI device 115d:0103
PCI: Enabling device 04:00.1 ( -> 0003)
[snip]
tulip_attach(04:00.0)
PCI: Setting latency timer of device 04:00.0 to 64
xircom_tulip_cb.c:v0.91 4/14/99 [EMAIL PROTECTED] (modified by
[EMAIL PROTECTED] for XIRCOM CBE, fixed by Doug Ledford)
eth1: Xircom Cardbus Adapter (DEC 21143 compatible mode) rev 3 at
0x1800, 00:00:00:00:00:00, IRQ 11.

-test8:
Linux PCMCIA Card Services 3.1.20
  options:  [pci] [cardbus] [pm]
Yenta IRQ list 0298, PCI irq11
Socket status: 3006
devfs: v0.102 (2622) Richard Gooch ([EMAIL PROTECTED])
devfs: boot_options: 0x2
kmem_create: Forcing size word alignment - nfs_fh
Yenta IRQ list 0298, PCI irq11
Socket status: 3020
cs: cb_alloc(bus 4): vendor 0x115d, device 0x0003
PCI: Failed to allocate resource 1 for PCI device 115d:0003
PCI: Failed to allocate resource 2 for PCI device 115d:0003
PCI: Failed to allocate resource 6 for PCI device 115d:0003
PCI: Enabling device 04:00.0 ( -> 0003)
PCI: Failed to allocate resource 1 for PCI device 115d:0103
PCI: Failed to allocate resource 2 for PCI device 115d:0103
PCI: Failed to allocate resource 6 for PCI device 115d:0103
PCI: Enabling device 04:00.1 ( -> 0003)
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 204k freed
Warning: unable to open an initial console.
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0800-0x08ff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x300-0x307 0x378-0x37f
0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
eth0: first available media type: MII
tulip_attach(04:00.0)
PCI: Setting latency timer of device 04:00.0 to 64
xircom_tulip_cb.c:v0.91 4/14/99 [EMAIL PROTECTED] (modified by
[EMAIL PROTECTED] for XIRCOM CBE, fixed by Doug Ledford)
eth1: Xircom Cardbus Adapter (DEC 21143 compatible mode) rev 3 at
0x1800, 00:00:00:00:00:00, IRQ 11.

I can use ifconfig to set a hw-address (does the card really support
this?), but if I try to set an IP-address, the system hangs hard.

Donald Becker's tulip-diag says:
dagblap:/tmp# ./tulip-diag -p 0x1800 -t 4 -ee
tulip-diag.c:v2.03 7/31/2000 Donald Becker ([EMAIL PROTECTED])
 http://www.scyld.com/diag/index.html
Assuming a Digital DS21143 Tulip adapter at 0x1800.
 Port selection is MII, half-duplex.
 Transmit stopped, Receive stopped, half-duplex.
  The Rx process state is 'Stopped'.
  The Tx process state is 'Stopped'.
  PCI bus error!: Parity Error.
  The transmit threshold is 128.
  The NWay status register is 00c6.
EEPROM size is 8.
WARNING: The EEPROM is missing or erased!
 This interface is missing the EEPROM.
  This is likely the non-primary interface on a multiport board.
EEPROM contents:
         
         
         
         
         
         
         
         
 ID block CRC 0xfa (vs. 0xff).
  Full contents CRC 0x6a15 (read as 0x).
  Internal autonegotiation state is 'Invalid state'.

This is a 10/100BaseTX/56K modem combo card. Loading serial_cb produces
nothing. And the card still works under that other OS...



[3.] Keywords (i.e., modules, networking, kernel):
Xircom, cardbus, xircom_tulip_cb, mac, hwaddress


[4.] Kernel version (from /proc/version):
2.4.0-test8 (gcc version 2.95.2 19991024 (release)) 

[5.] Output of Oops.. message (if applicable) with symbolic information 
 resolved (see Documentation/oops-tracing.txt)
[6.] A small 

Re: bizarre problems with Athlon system after upgrdaing motherboard

[Brian Gerst]

Marty Leisner wrote:
> When we upgraded the motherboard, we got consistant GPFs right after
> the line:
> Enabling extended fast FPU save

It sounds like Redhat patched the kernel to support the Pentium III XMM
extensions and the kernel is misdetecting the Athlon as a PIII.

--

Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

write_space in kernel

[Lee Chin]

Hello,
I have a call beack registered on write_space in kernel, so when I do a
asynchronous sock_sendmsg in the kernel, I get notified.  However, I want to
know how much data was sent on that socket, so I can free the socket after
all data has been sent.  How do I check for this condition?

Thanks
Lee


__
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

write_space in kernel

[Lee Chin]

Hello,
I have a call beack registered on write_space in kernel, so when I do a
asynchronous sock_sendmsg in the kernel, I get notified.  However, I want to
know how much data was sent on that socket, so I can free the socket after
all data has been sent.  How do I check for this condition?

Thanks
Lee


__
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM

[Pavel Machek]

Hi!

> > (2) Make the architecture a configuration variable (!)
> 
> Why?
> 
> You still need to have all the damn cross-compilers etc. At which point
> being a configuration variable is the _least_ of your worries. You're
> better off with just a new tree.

Crosscompilers are easy: take pre-compiled cross-compiler, unpack it
to /usr/mipsel-linux and you are done. But inability to share sources
between i386 and mips/r39xx is a problem for me: each tree is 100MB in
size. [Not easily solved as mips/r39xx uses cvs etc...] 

> > (3) A collection of RPM's so that people can download and install
> > all the cross tools easily.
> 
> Hey, maybe you have a few 18GB disks lying around, but none of the
> machines I use every day could afford to have another 5-6 cross-
> compilation environments lying around. It's just not practical.

What? Cross compilation environment for mips is ... just under
40MB. That's three times smaller than my linux tree:

root@bug:~# ls -al /usr/mipsel-linux
lrwxrwxrwx   1 root root   31 May 29 16:02
/usr/mipsel-linux -> /usr/src/velo/usr/mipsel-linux//
root@bug:~# du -s /usr/src/velo/usr/mipsel-linux/
38388   /usr/src/velo/usr/mipsel-linux
root@bug:~# du -s /usr/src/linux
139280  /usr/src/linux
root@bug:~#

Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Multiple Keyboards in 2.2/2.4?

[Pavel Machek]

Hi!

> > On Thu, Sep 07, 2000 at 10:00:05AM -0400, James Simmons wrote:
> > > On the console level their are complex issues as well. Consider a
> > > system with 4 VTs attached to one machine. What if one person pressed
> > > Ctrl-Alt-Del. Anyone can bring the system down when multiple people depend
> > > on it.
> > 
> > That particular one is a userspace issue; you can simply tell init not to do
> > anything when Ctrl-Alt-Del is pressed. (You'd also want to disable
> > magic-sysrq for the same reason.)
> 
> Don't forget about where printk goes to. Should it goe to every VT or just
> one? As for SysRq do users want the option to disable for everyone, have
> it work for one VT or allow it for everyone? Do we want a all or nothing
> policy?

It is actually very easy. Just one keyboard, and just one monitor is
"system console". All others are just normal terminals. 

There's already same problem with serial console / vt problem. There's
solution saying "user selects using command line what _real_ console
is". No new problem here.

[And yes, serial console can do both sysrq and printing kernel
messages. No new problems here.]
Pavel
-- 
I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Val Henson]

One way of increasing signal to noise ratio (place in .procmailrc):

:0
* ^FROM.*jmerkey@timpanogas\.com
/dev/null

On Mon, Sep 11, 2000 at 03:53:48PM -0400, [EMAIL PROTECTED] wrote:
> On Mon, 11 Sep 2000, Jeff V. Merkey wrote:

> Now will you stop trying to incite pointless riots and allow those of us
> who are trying to use linux-kernel as a useful means of communicating
> development issues a chance for a decent signal to noise ratio?

-VAL
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: fun ?

[Roy C. Bixler]

On Mon, 11 Sep 2000, Marcelo Tosatti wrote:
> On Mon, 11 Sep 2000, Marcelo Tosatti wrote:
> > On Mon, 11 Sep 2000, octave klaba wrote:
> > 
> > > Hello,
> > > upgrading from 2.2.16 to 2.2.17 a raid-soft config (adaptec 5x36Go)
> > > 
> > > /sbin/lilo gave a D process ( :) )
> > > 
> > > root 14823  0.0  0.1  1184  496 ?DSep10   0:00 /sbin/lilo
> > > 
> > > one question:
> > > reboot or not to reboot ?
> > > 
> > > I have no flopy disk on this server.
> > 
> > Could you please see where lilo is sleeping? 
> > 
> > You can do this with: ps xeo "command wchan" | grep lilo
> > 
> > Note that System.map must be in the correct place. 
> 
> Another thing: are you using stock raid or 0.90? 

Ooh, this seems familiar.  My configuration is very similar to the one
mentioned above (with Adaptec controller, driver is AIC7xxx) and I have
seem this problem of LILO hanging with RAID 0.90.  This was after the
'popper' got stuck in the R state as an unkillable process and 'kupdate'
and 'kswapd' were stuck in the D state.  I originally ran 2.2.17 with
stock RAID and the same thing happened with the 'popper' daemon there
although I did not try LILO that time.

Well, the machine with the problem is a production server and I have
reverted to 2.2.16 with RAID 0.90.  All is well there so far and,
hopefully, I can have the same stability as I had with 2.2.16 + stock
RAID.  I can't help with any further debugging but, both times the
'popper' and 'kupdate' got stuck, it was a result of a user with a large
mailbox connecting.  The 'popper' copies the mailbox over to a temporary
file on the same RAID partition (/var), so a guess would be this burst of
heavy I/O might be a trigger.  I would like to know if there is a patch to
fix this so I could reconsider upgrading from 2.2.16.

Thanks,

-- 
Roy Bixler
The University of Chicago Press
[EMAIL PROTECTED]


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Re: sound in 2.4.0test8 (cs46xx.c)

[Dan Aloni]

On Mon, 11 Sep 2000, Jeff Garzik wrote:

> Dan Aloni wrote:
> > On Mon, 11 Sep 2000, Bernd Jucknischke wrote:
> > >   I've just tried to compile a 2.4.0-test8 on an IBM thinkpad T20 and got the
> > > following error:
> > >   cs46xx.c: 2488: cards causes a section type conflict
> > Linus'-not-Maxwell, please consider applying this patch.
> > 
> > @@ -2494,7 +2494,7 @@
> > {PCI_VENDOR_ID_IBM, 0x0132, "Thinkpad 570", amp_none, clkrun_hack},
> > {PCI_VENDOR_ID_IBM, 0x0153, "Thinkpad 600X/A20/T20", amp_none, 
>clkrun_hack},
> > {PCI_VENDOR_ID_IBM, 0x1010, "Thinkpad 600E (unsupported)", NULL, NULL},
> > -   {0, 0, NULL, NULL}
> > +   {0, 0, NULL, NULL, NULL}
> >  };
> 
> Just leave it at "{ 0, }" and gcc will fill in the rest of the struct
> members as zero.

I guess you're right, I was just trying not to break any consistency.

Dan Aloni (dax)
[EMAIL PROTECTED]



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Oops on boot with both 2.2.17 and 2.4.0t8p6

[Rasmus Andersen]

On Mon, Sep 11, 2000 at 09:00:02PM +0200, Mike Galbraith wrote:
> The symptom is _different_ than without the patch being applied?  That
> should be impossible.  With Kernel Debugging disabled, the patch should
> have zero effect.. you should have your original oops back.

Yeah, sorry about that :) I'll play around with it some and see if I
fscked up or if it is true.

> 
> Anyway, it boots fine with ikd:foo enabled, so what's different from
> stock kernel.  Frame-pointers?.. no way in hell.  Linking?..
> 
> 
> 
> If you edit arch/i386/vmlinux.lds in test8-virgin and just delete..
> 
>  /* Sections to be discarded */
>  /DISCARD/ : {
>  *(.text.exit)
>  *(.data.exit)
>  *(.exitcall.exit)
>  }
> 
> ..do your symptoms change?
> 

This gives me the original oops. No change from vanilia test8.

-- 
Rasmus([EMAIL PROTECTED])

"I begin by taking. I shall find scholars later to demonstrate my 
perfect right." - Frederick (II) the Great
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Using Yarrow in /dev/random

[Sandy Harris]

Pravir Chandra wrote:
> 
> I've been working to change the implementation of /dev/random over to the
> Yarrow-160a algorithm created by Bruce Schneier and John Kelsey.

For some old discussions on related topics, see:
http://www.openpgp.net/random/

> We've been
> working on parallel development for Linux and NT so that the algorithms are
> matching. The Yarrow 160A algorithm is a variant of Yarrow-160 that has come
> about from discussions with John Kelsey. We've been in contact with him
> throughout our development effort.
> 
> In any case, this requires use of a hash function (sha1) and a block cipher
> (3des).

I think (I'm in a minority here) that 3DES would be a mistake. DES was designed
for hardware implementation and is inconvenient to do in software. Schneier's
Applied Crytography says more modern ciphers like CAST-128 or Blowfish are a bit
over 3 times the speed of single DES in software, so roughly 10x triple DES
speed.
Several of the AES candidate ciphers included "faster than DES and more secure
than 3DES" among their stated design goals. My guess would be they've achieved
this.

> We were going to do a replacement of /dev/random (it's nearly finished)

I'd be interested in seeing the code.

> but in retrospect, it seemed that I hadn't looked into the current state of
> incorporating crypto into the kernel. If anyone has any suggestions, comments,
> questions, please email.

I've argued that the current /dev/random has a design flaw. /dev/urandom draws
on the same randomness pool, so heavy use of urandom can cause random to
block.

If I understood him correctly, /dev/random author T'so does not consider
that a serious flaw. If you need lots of random numbers, then you should be
using a userspace library, not either of the random devices. From one of his
messages in a recent thread with subject "/dev/random blocks forever ..."

> My recommendation has always been that applications use /dev/random for
> long-term public key generation, and to seed a pseudo-RNG for session
> keys.  The reasoning behind this is that true, high-quality random
> numbers is a very precious resource (even with a real high, quality
> random number generator, it is still a limited resource), and so it's
> better to periodically get randomness from /dev/random, and then use
> that as seeds for a cryptographically secure, pseudo-random number
> generator.

I've written such a generator based on Rijndael cipher, and posted an
early buggy version here. Mail for current version if you want it. It
is a library of routines to be called from an application that requires
a lot of high grade random numbers. It is neither well reviewed nor
well tested yet.

My inclination would be to keep the existing /dev/random entropy
collection code, which I consider superior to Yarrow's. Use it as the
first stage of a Yarrow-like design and add my Rijndael-based code as
the second stage.

For 2.4, Ts'o has changed the design considerably, adding a second
stage (hashing, rather than Yarrow's block cipher) and implementing
"catastrophic reseeding" as recommended in the Yarrow papers. Since
I consider that the most important design idea in those papers, I
suspect that this version of /dev/random answers all my concerns.
I'm not certain because I haven't looked at the code in detail yet.
  
> Also, does anyone have any complaints against incorporating a new
> /dev/random into the kernel?

It would need extensive review and analysis before that should be
considered.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

[EMAIL PROTECTED] wrote:

> Now will you stop trying to incite pointless riots and allow those of us
> who are trying to use linux-kernel as a useful means of communicating
> development issues a chance for a decent signal to noise ratio?
> 
> -ben

Ben,

Read the thread before getting out your shotgun and pointing it at me. 
Rik asked me a question, I answered it.  It wasn't related to any code
-- if he asks me a question again, I'll answer it.  

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jeff V. Merkey]

I'll give it some thought.  Most of Linux has better paging than NetWare
already -- NetWare is pretty simple in this respect.  THe process
mapping stuff in Netware (PCB's are mapped to recursively point to
themselves with a global brach table) is unique, but not as good as
what's in Linux.

:-)

Jeff

Jamie Lokier wrote:
> 
> Jeff V. Merkey wrote:
> > One of the best references that describes the bus transaction model for
> > Intel in "plain english"  is the Pentium Pro Processor System
> > Architecture Manual by Tom Shanley of Mindshare, Inc., Addison Wesley,
> > ISBN: 0-201-47953-2.  It explains a very good detail how the cache
> > controllers and MESI works on Intel.
> 
> Agreed, it is a very informative book.  More detail than you need unless
> you're cloning the chips ;-)  Full of good ideas, especially for anyone
> interested in memory hierarchies.
> 
> > In NetWare, we didn't care if the page was touched or not since we
> > used our own bits in field bits 11-9 to store page specific stuff,
> > like whether the page was dirty or not.
> 
> Linux does actually look at both bits, but the optimisation still
> applies.  Accessed in particular -- ptes are mapped on page faults so
> you know the page is about to be accessed.
> 
> > We saw a 4% performance improvement for Network I/O by avoiding the
> > "hidden" locking in Intel's architecture.  You should check if you need
> > this bit, and if not, always create the PTE with it set.  I don't know
> > how much it would help Linux.  NetWare is well optimized for Intel
> > processors and any little thing that increased bus memory utilization
> > was very noticeable on NetWare, since it supports such huge user loads
> > already.
> >
> > :-)
> 
> Use Linux.  Grok Linux.  Read the source and weep :-)
> But thanks for the tip :-)
> 
> Btw, any good tips you have on effective paging heuristics -- now they
> _would_ be useful I'm sure.  Linux paging is still rather experimental
> after all these years.  As in, it works but could do better.
> 
> -- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [ANNOUNCE] Darkstar Development Project

[Jamie Lokier]

Larry McVoy wrote:
> > Development:
> > In addition, by maintaining the system in CVS we can offer much
> > faster and convenient source updates than are currently available
> > from other Linux-based systems currently available.
> 
> Err, "faster"?  The following is the moral equiv of 4 kernel updates
> which had nothing to do using BitKeeper instead of CVS.  The local copy
> was in San Francisco and the remote copy is Cort's machine in New Mexico
> over a 384Kbits/sec link.  All 4 updates in 5 seconds.  Anyone have a
> CVS tree they can try to get comparable numbers?

Try: http://innominate.org/~tgr/projects/lksr/

Actually rather handy.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: fun ?

[Marcelo Tosatti]

On Mon, 11 Sep 2000, Marcelo Tosatti wrote:

> 
> On Mon, 11 Sep 2000, octave klaba wrote:
> 
> > Hello,
> > upgrading from 2.2.16 to 2.2.17 a raid-soft config (adaptec 5x36Go)
> > 
> > /sbin/lilo gave a D process ( :) )
> > 
> > root 14823  0.0  0.1  1184  496 ?DSep10   0:00 /sbin/lilo
> > 
> > one question:
> > reboot or not to reboot ?
> > 
> > I have no flopy disk on this server.
> 
> Could you please see where lilo is sleeping? 
> 
> You can do this with: ps xeo "command wchan" | grep lilo
> 
> Note that System.map must be in the correct place. 

Another thing: are you using stock raid or 0.90? 

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]

Re: Availability of kdb

[kernel]

On Mon, 11 Sep 2000, Jeff V. Merkey wrote:

> If you need to know if the page has been accessed, you can clear this
> bit when a page is first mapped, and when someone touches it, the
> hardware will set this bit.  It set's it by doing a R/M/W operation on

We've set the accessed bit for a long time.  From asm-i388/pgtable.h:

#define PAGE_SHARED __pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | 
_PAGE_ACCESSED)
#define PAGE_COPY   __pgprot(_PAGE_PRESENT | _PAGE_USER | _PAGE_ACCESSED)
#define PAGE_READONLY   __pgprot(_PAGE_PRESENT | _PAGE_USER | _PAGE_ACCESSED)

Now will you stop trying to incite pointless riots and allow those of us
who are trying to use linux-kernel as a useful means of communicating
development issues a chance for a decent signal to noise ratio?

-ben

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: fun ?

[Marcelo Tosatti]

On Mon, 11 Sep 2000, octave klaba wrote:

> Hello,
> upgrading from 2.2.16 to 2.2.17 a raid-soft config (adaptec 5x36Go)
> 
> /sbin/lilo gave a D process ( :) )
> 
> root 14823  0.0  0.1  1184  496 ?DSep10   0:00 /sbin/lilo
> 
> one question:
> reboot or not to reboot ?
> 
> I have no flopy disk on this server.

Could you please see where lilo is sleeping? 

You can do this with: ps xeo "command wchan" | grep lilo

Note that System.map must be in the correct place. 

Thanks 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: Availability of kdb

[Jamie Lokier]

Jeff V. Merkey wrote:
> One of the best references that describes the bus transaction model for
> Intel in "plain english"  is the Pentium Pro Processor System
> Architecture Manual by Tom Shanley of Mindshare, Inc., Addison Wesley,
> ISBN: 0-201-47953-2.  It explains a very good detail how the cache
> controllers and MESI works on Intel.

Agreed, it is a very informative book.  More detail than you need unless
you're cloning the chips ;-)  Full of good ideas, especially for anyone
interested in memory hierarchies.

> In NetWare, we didn't care if the page was touched or not since we
> used our own bits in field bits 11-9 to store page specific stuff,
> like whether the page was dirty or not.

Linux does actually look at both bits, but the optimisation still
applies.  Accessed in particular -- ptes are mapped on page faults so
you know the page is about to be accessed.

> We saw a 4% performance improvement for Network I/O by avoiding the
> "hidden" locking in Intel's architecture.  You should check if you need
> this bit, and if not, always create the PTE with it set.  I don't know
> how much it would help Linux.  NetWare is well optimized for Intel
> processors and any little thing that increased bus memory utilization
> was very noticeable on NetWare, since it supports such huge user loads
> already.
> 
> :-)

Use Linux.  Grok Linux.  Read the source and weep :-)
But thanks for the tip :-)

Btw, any good tips you have on effective paging heuristics -- now they
_would_ be useful I'm sure.  Linux paging is still rather experimental
after all these years.  As in, it works but could do better.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/