Re: Linux-2.4.0-test9-pre2
On Tue, 19 Sep 2000, Tom Rini wrote: > On Tue, Sep 19, 2000 at 09:36:30PM -0700, David Ford wrote: > > The VM work has been scheduled to go in for a while. If you check the TODO > > emails from months back, it's always been there. > > I wasn't arguing that (really) it's just that it really should > have gone in sooner. It's all really a moot point I understand, The VM patch went in as soon as none of the people testing the patch was able to make it crash or behave very badly. Of course then the increased test base showed up some locking issues which caused a deadlock on single-cpu machines ;) (good thing I have connectivity here at Linux Kongress so I can log in from the other end of the world and fix the problems as soon as we find them ;)) 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: Linux-2.4.0-test9-pre2
On Tue, 19 Sep 2000, Tom Rini wrote: On Tue, Sep 19, 2000 at 09:36:30PM -0700, David Ford wrote: The VM work has been scheduled to go in for a while. If you check the TODO emails from months back, it's always been there. I wasn't arguing that (really) it's just that it really should have gone in sooner. It's all really a moot point I understand, The VM patch went in as soon as none of the people testing the patch was able to make it crash or behave very badly. Of course then the increased test base showed up some locking issues which caused a deadlock on single-cpu machines ;) (good thing I have connectivity here at Linux Kongress so I can log in from the other end of the world and fix the problems as soon as we find them ;)) 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: Linux-2.4.0-test9-pre2 (version numbering)
> "Barry K. Nathan" <[EMAIL PROTECTED]> said: > > > In other words, if I understand things correctly, once we have Linux > > 2.4.0-test4294967296 ;) and 2.4 is stable enough for the last phase of > > testing before release, 2.4.0-pre1 will be next... > > That so? Must get Linus an Alpha or SPARC64 ASAP so 2.4.0-test isn't unduly > restricted by version numbers... I just picked 2^32 as a jokingly large number - if I meant to imply a 32-bit limit, I would have done 2^32 - 1 (4294967295) instead. :) (When I was writing the email, I was wondering if I should have made it 4294967297 instead...) -Barry K. Nathan <[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: Linux-2.4.0-test9-pre2 (version numbering)
"Barry K. Nathan" <[EMAIL PROTECTED]> said: [...] > In other words, if I understand things correctly, once we have Linux > 2.4.0-test4294967296 ;) and 2.4 is stable enough for the last phase of > testing before release, 2.4.0-pre1 will be next... That so? Must get Linus an Alpha or SPARC64 ASAP so 2.4.0-test isn't unduly restricted by version numbers... -- 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: Linux-2.4.0-test9-pre2
On Tue, 19 Sep 2000, Andrea Arcangeli wrote: > I'm tired of you screwing up the VM and then complaining the elevator. At least > try to vary and choose something else to complain. At test1 time you may been > right, but now we're so permissive in the default settings exactly to be sure > the elevator isn't hurting performance. Hmm...Do I sense a little hostility here? Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - 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.4.0-test9-pre2
On Tue, 19 Sep 2000, Andrea Arcangeli wrote: > On Tue, Sep 19, 2000 at 05:58:48AM -0300, Rik van Riel wrote: > > One of the issues which seems to be affecting performance > > is the elevator starvation bug, though, so I'm not sure how > > You are contraddicting yourself. If you decrease the latency (so > if you fix the starvation) the global disk throughput can only > decrease. Umm, where did I define "performance" as being the same as "global disk throughput" ?? You're imagining things again, and blaming me for it ;) > > Once the elevator problem has been solved, we should be able > > I'm tired of you screwing up the VM and then complaining the > elevator. At least try to vary and choose something else to > complain. There was a known starvation issue in the elevator, at least up to 2.4.0-test9-pre2. Until that problem is resolved, that is the logical thing to "blame" for the phenomenon that one process stalls while some others are still running at full speed. Besides, if it was a VM issue, all allocators would stall. That did not happen, so VM wasn't the subsystem to blame in this case. That said, there may be some interactivity issues with the VM, but with the elevator bug present, there is not much possibility to test for those. About screwing up the VM subsystem, why didn't you help with the details? (remember that you agreed about the design in Ottawa) 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: networking todo, was Re: Linux-2.4.0-test9-pre2
On Wed, Sep 20, 2000 at 03:24:28PM +0200, Andi Kleen wrote: > That would just break the whole idea behind softnet. When you're juggling I agree ;(. 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: networking todo, was Re: Linux-2.4.0-test9-pre2
On Wed, Sep 20, 2000 at 03:29:39PM +0200, Andrea Arcangeli wrote: > On Wed, Sep 20, 2000 at 04:38:24AM +0200, Andi Kleen wrote: > > We must be talking about different things. It of course detects it on > > ACK input, but only for data it did send itself. Every TCP detects > > reordering automatically on the input with the sequence number check, > > but all we still do is to send an ACK immediately and go into > > quickack mode. > > Agreed. I couldn't see how to "detect" the reordering in the receiver without > additional informations from the dev.c layer (I don't think it's possible to > detect it from the TCP layer without adding something like described by > Andi in the below section that looks not very nice because it would > hurt links with real packet loss). Assuming you have outgoing traffic on the NIC as well it isn't that bad, because there will be likely some queueing delay for the ACK in which you could in theory still cancel it of you know better (it would hurt the abstraction between device drivers and dev.c a lot though) > The solution consists in a sequence number protected by the spinlock in the NIC > device driver (as DaveM suggested) and to increase this sequence number for > each packet received and to set the sequence number value of the moment in each > skb. Then we'd need a secondary (shared :( ) sequence numbers in the > net_rx_action layer that will tell us the sequence number of the last packet > that entered the higher level layer (IP in our case). With this per packet > sequence number information we'll know if we're generating reordering by > pushing the next packet in the softnet queue from net_rx_action to the IP > layer. In that case we should only set up a wake-up-me-later logic and giveup. That would just break the whole idea behind softnet. When you're juggling the cache line for the sequence counter you could as well juggle the cache line with a shared queue head, e.g. we would be at 2.2 level again. > The other almost zero cost way to fix the reordering is of course to set the > irq affinity of each nic only to one CPU :)) (this applies to the less smart > protocol as well) That's the real solution long term, right. -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: networking todo, was Re: Linux-2.4.0-test9-pre2
On Wed, Sep 20, 2000 at 04:38:24AM +0200, Andi Kleen wrote: > We must be talking about different things. It of course detects it on > ACK input, but only for data it did send itself. Every TCP detects > reordering automatically on the input with the sequence number check, > but all we still do is to send an ACK immediately and go into > quickack mode. Agreed. I couldn't see how to "detect" the reordering in the receiver without additional informations from the dev.c layer (I don't think it's possible to detect it from the TCP layer without adding something like described by Andi in the below section that looks not very nice because it would hurt links with real packet loss). > Or did I miss something ? > > The only way to do true reordering handling on the receiver I can think of > would be to use something like the soft-timers to do very very fast delayed > acks even for rcv_mss sized packets and hope that you collect packets from > all CPUs in the delay, but overall it could still cost you a lot by > disturbing the ACK clock > > [I talked a lot with Andrea about this during OLS, and we couldn't > figure out a good way] I couldn't figure out a good way to fix that internally to TCP, but I have a quite simple solution at the dev.c layer (that would address also the problem with the not smart protocols that needs to retransmit everything once an hole in the sequence space is found). The solution consists in a sequence number protected by the spinlock in the NIC device driver (as DaveM suggested) and to increase this sequence number for each packet received and to set the sequence number value of the moment in each skb. Then we'd need a secondary (shared :( ) sequence numbers in the net_rx_action layer that will tell us the sequence number of the last packet that entered the higher level layer (IP in our case). With this per packet sequence number information we'll know if we're generating reordering by pushing the next packet in the softnet queue from net_rx_action to the IP layer. In that case we should only set up a wake-up-me-later logic and giveup. No idea how much this additional logic hurts. Certainly it could be enabled per-device/per-protocol basis. The other almost zero cost way to fix the reordering is of course to set the irq affinity of each nic only to one CPU :)) (this applies to the less smart protocol as well) 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: networking todo, was Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 08:56:57PM -0700, David S. Miller wrote:
>Just use __cacheline_aligned instead, like I did with the
>ip_local_data in the patch you just rejected. There is still the
>problem that generic SMP x86 kernels use a 32byte cacheline. Not a
>problem currently because the only x86 SMP is pII/pIII which has
>32byte, but with Williamette/Athlon SMP it'll be a problem because
>these have 64byte and 128byte cache lines. With __cacheline_aligned
>it'll be easy though to pick up such changes.
>
> Ok, feel free to send me a patch which does only this. I may doctor
> it up a bit, be warned :-)
Here is the complete patch I'm using, pick what you want from it.
This time I documented my intentions properly, see the source code
comments. I removed all power-of-two paddings because the shift/add
sequences seem to be always short enough.
I also documented a bigger potential win on machines with immediate
memory access and sane interrupt model (and an even bigger --
Dimitris Michailidis's PDA patches) which both need more extensive
modifications
>On the other hand, the inetpeer code is only really exercised on
>machines that talk to lots and lots of destinations (=real
>servers), and 2.4 testing on such machines still has to begin.
>
>Given that 2.4 testing has not really begun yet I would guess that
>it is safer to remove it now @)
>
> True, but the following is what I'm really thinking about. Suppose a
> few weeks from now Alexey greets both of our mailboxes with a fabulous
> solution to the tw recycle masqeurading problem, wouldn't it be quite
> a pain in the ass to put back in and retest all the inetpeer code?
>
> Let's sit on this until Alexey gives a forecast about the
> possibilities of a solution in the near future ok?
Ok. I just don't want the code uselessly wasting cycles and cache lines in
2.4.0 if possible.
-Andi
Index: include/net/snmp.h
===
RCS file: /cvs/linux/include/net/snmp.h,v
retrieving revision 1.16
diff -u -u -r1.16 snmp.h
--- include/net/snmp.h 2000/08/09 11:59:03 1.16
+++ include/net/snmp.h 2000/09/20 11:19:25
@@ -14,17 +14,34 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
+ * $Id$
+ *
*/
#ifndef _SNMP_H
#define _SNMP_H
+
+#include
/*
* We use all unsigned longs. Linux will soon be so reliable that even these
* will rapidly get too small 8-). Seriously consider the IpInReceives count
* on the 20Gb/s + networks people expect in a few years time!
*/
-
+
+/*
+ * The rule for padding:
+ * Best is power of two because then the right structure can be found by a simple
+ * shift. The structure should be always cache line aligned.
+ * gcc needs n=alignto(cachelinesize, popcnt(sizeof(bla_mib))) shift/add instructions
+ * to emulate multiply in case it is not power-of-two. Currently n is always <=3 for
+ * all sizes so simple cache line alignment is enough.
+ *
+ * The best solution would be a global CPU local area , especially on 64 and 128byte
+ * cacheline machine it makes a *lot* of sense -AK
+ */
+
+
struct ip_mib
{
unsigned long IpInReceives;
@@ -44,8 +61,8 @@
unsigned long IpFragOKs;
unsigned long IpFragFails;
unsigned long IpFragCreates;
- unsigned long __pad[32-19];
-};
+ unsigned long __pad[0];
+} cacheline_aligned;
struct ipv6_mib
{
@@ -71,8 +88,8 @@
unsigned long Ip6FragCreates;
unsigned long Ip6InMcastPkts;
unsigned long Ip6OutMcastPkts;
- unsigned long __pad[32-22];
-};
+ unsigned long __pad[0];
+} cacheline_aligned;
struct icmp_mib
{
@@ -102,8 +119,8 @@
unsigned long IcmpOutTimestampReps;
unsigned long IcmpOutAddrMasks;
unsigned long IcmpOutAddrMaskReps;
- unsigned long __pad[32-26];
-};
+ unsigned long __pad[0];
+} cacheline_aligned;
struct icmpv6_mib
{
@@ -140,8 +157,8 @@
unsigned long Icmp6OutRedirects;
unsigned long Icmp6OutGroupMembResponses;
unsigned long Icmp6OutGroupMembReductions;
- unsigned long __pad[32-28];
-};
+ unsigned long __pad[0];
+} cacheline_aligned;
struct tcp_mib
{
@@ -159,8 +176,8 @@
unsigned long TcpRetransSegs;
unsigned long TcpInErrs;
unsigned long TcpOutRsts;
- unsigned long __pad[16-14];
-};
+ unsigned long __pad[0];
+} cacheline_aligned;
struct udp_mib
{
@@ -168,8 +185,8 @@
unsigned long UdpNoPorts;
unsigned long UdpInErrors;
unsigned long UdpOutDatagrams;
- unsigned long __pad[0];
-};
+ unsigned long __pad[0];
+} cacheline_aligned;
struct linux_mib
{
@@ -237,9 +254,15 @@
unsigned long TCPAbortOnLinger;
Re: Linux-2.4.0-test9-pre2
David S. Miller writes: > Why not just > tell these people "why are you working on experimental stuff, put > together PPC stress test and kernel regression suites if you are > bored, because we know 2.4.x isn't read for prime time" Mainly because: 1. the people providing the new "features" have not provided the "features" that are in 2.4.x. 2. Some people just don't subscribe to this idea, and, like Cort, they will go off and produce their own tree. I have a real example of (2) which happened *because* I wanted to make 2.2 stable - ARM now has a CVS tree which is used by a lot of people. This CVS tree was created, IMHO, because I tried to reduce the number of features going into late 2.1/early 2.2. Hence, the traditional argument that is applied to the "x86" side of Linux just doesn't hack it everywhere - if you try to apply it, you end up with people forking the tree left right and center. And no, they don't come back in a rush when you eventually get around to 2.5. They come back just before you finish 2.5. If I take what I believe to be Linus' attitude that I shouldn't care about this, then I'm just kidding myself - my code will just become a basis of all these other trees, and the only thing I'll be doing from that point on is providing a service to them where Linus' patches are cleanly merged with what my tree was a couple of years ago (ie, no new patches come in). I'm not agreeing that the fundamental "development/stable" cycles are bad, but trying to stop new features 100% is a bit like trying to build a damn out of sand for some of the architecture maintainers - it just doesn't work. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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.4.0-test9-pre2
On Tue, 19 Sep 2000, Andrea Arcangeli wrote: On Tue, Sep 19, 2000 at 05:58:48AM -0300, Rik van Riel wrote: One of the issues which seems to be affecting performance is the elevator starvation bug, though, so I'm not sure how You are contraddicting yourself. If you decrease the latency (so if you fix the starvation) the global disk throughput can only decrease. Umm, where did I define "performance" as being the same as "global disk throughput" ?? You're imagining things again, and blaming me for it ;) Once the elevator problem has been solved, we should be able I'm tired of you screwing up the VM and then complaining the elevator. At least try to vary and choose something else to complain. There was a known starvation issue in the elevator, at least up to 2.4.0-test9-pre2. Until that problem is resolved, that is the logical thing to "blame" for the phenomenon that one process stalls while some others are still running at full speed. Besides, if it was a VM issue, all allocators would stall. That did not happen, so VM wasn't the subsystem to blame in this case. That said, there may be some interactivity issues with the VM, but with the elevator bug present, there is not much possibility to test for those. About screwing up the VM subsystem, why didn't you help with the details? (remember that you agreed about the design in Ottawa) 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: Linux-2.4.0-test9-pre2
On Tue, 19 Sep 2000, Andrea Arcangeli wrote: I'm tired of you screwing up the VM and then complaining the elevator. At least try to vary and choose something else to complain. At test1 time you may been right, but now we're so permissive in the default settings exactly to be sure the elevator isn't hurting performance. Hmm...Do I sense a little hostility here? Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - 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.4.0-test9-pre2 (version numbering)
"Barry K. Nathan" [EMAIL PROTECTED] said: [...] In other words, if I understand things correctly, once we have Linux 2.4.0-test4294967296 ;) and 2.4 is stable enough for the last phase of testing before release, 2.4.0-pre1 will be next... That so? Must get Linus an Alpha or SPARC64 ASAP so 2.4.0-test isn't unduly restricted by version numbers... -- 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: Linux-2.4.0-test9-pre2 (version numbering)
"Barry K. Nathan" [EMAIL PROTECTED] said: In other words, if I understand things correctly, once we have Linux 2.4.0-test4294967296 ;) and 2.4 is stable enough for the last phase of testing before release, 2.4.0-pre1 will be next... That so? Must get Linus an Alpha or SPARC64 ASAP so 2.4.0-test isn't unduly restricted by version numbers... I just picked 2^32 as a jokingly large number - if I meant to imply a 32-bit limit, I would have done 2^32 - 1 (4294967295) instead. :) (When I was writing the email, I was wondering if I should have made it 4294967297 instead...) -Barry K. Nathan [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: networking todo, was Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 08:56:57PM -0700, David S. Miller wrote:
Just use __cacheline_aligned instead, like I did with the
ip_local_data in the patch you just rejected. There is still the
problem that generic SMP x86 kernels use a 32byte cacheline. Not a
problem currently because the only x86 SMP is pII/pIII which has
32byte, but with Williamette/Athlon SMP it'll be a problem because
these have 64byte and 128byte cache lines. With __cacheline_aligned
it'll be easy though to pick up such changes.
Ok, feel free to send me a patch which does only this. I may doctor
it up a bit, be warned :-)
Here is the complete patch I'm using, pick what you want from it.
This time I documented my intentions properly, see the source code
comments. I removed all power-of-two paddings because the shift/add
sequences seem to be always short enough.
I also documented a bigger potential win on machines with immediate
memory access and sane interrupt model (and an even bigger --
Dimitris Michailidis's PDA patches) which both need more extensive
modifications
On the other hand, the inetpeer code is only really exercised on
machines that talk to lots and lots of destinations (=real
servers), and 2.4 testing on such machines still has to begin.
Given that 2.4 testing has not really begun yet I would guess that
it is safer to remove it now @)
True, but the following is what I'm really thinking about. Suppose a
few weeks from now Alexey greets both of our mailboxes with a fabulous
solution to the tw recycle masqeurading problem, wouldn't it be quite
a pain in the ass to put back in and retest all the inetpeer code?
Let's sit on this until Alexey gives a forecast about the
possibilities of a solution in the near future ok?
Ok. I just don't want the code uselessly wasting cycles and cache lines in
2.4.0 if possible.
-Andi
Index: include/net/snmp.h
===
RCS file: /cvs/linux/include/net/snmp.h,v
retrieving revision 1.16
diff -u -u -r1.16 snmp.h
--- include/net/snmp.h 2000/08/09 11:59:03 1.16
+++ include/net/snmp.h 2000/09/20 11:19:25
@@ -14,17 +14,34 @@
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
+ * $Id$
+ *
*/
#ifndef _SNMP_H
#define _SNMP_H
+
+#include linux/cache.h
/*
* We use all unsigned longs. Linux will soon be so reliable that even these
* will rapidly get too small 8-). Seriously consider the IpInReceives count
* on the 20Gb/s + networks people expect in a few years time!
*/
-
+
+/*
+ * The rule for padding:
+ * Best is power of two because then the right structure can be found by a simple
+ * shift. The structure should be always cache line aligned.
+ * gcc needs n=alignto(cachelinesize, popcnt(sizeof(bla_mib))) shift/add instructions
+ * to emulate multiply in case it is not power-of-two. Currently n is always =3 for
+ * all sizes so simple cache line alignment is enough.
+ *
+ * The best solution would be a global CPU local area , especially on 64 and 128byte
+ * cacheline machine it makes a *lot* of sense -AK
+ */
+
+
struct ip_mib
{
unsigned long IpInReceives;
@@ -44,8 +61,8 @@
unsigned long IpFragOKs;
unsigned long IpFragFails;
unsigned long IpFragCreates;
- unsigned long __pad[32-19];
-};
+ unsigned long __pad[0];
+} cacheline_aligned;
struct ipv6_mib
{
@@ -71,8 +88,8 @@
unsigned long Ip6FragCreates;
unsigned long Ip6InMcastPkts;
unsigned long Ip6OutMcastPkts;
- unsigned long __pad[32-22];
-};
+ unsigned long __pad[0];
+} cacheline_aligned;
struct icmp_mib
{
@@ -102,8 +119,8 @@
unsigned long IcmpOutTimestampReps;
unsigned long IcmpOutAddrMasks;
unsigned long IcmpOutAddrMaskReps;
- unsigned long __pad[32-26];
-};
+ unsigned long __pad[0];
+} cacheline_aligned;
struct icmpv6_mib
{
@@ -140,8 +157,8 @@
unsigned long Icmp6OutRedirects;
unsigned long Icmp6OutGroupMembResponses;
unsigned long Icmp6OutGroupMembReductions;
- unsigned long __pad[32-28];
-};
+ unsigned long __pad[0];
+} cacheline_aligned;
struct tcp_mib
{
@@ -159,8 +176,8 @@
unsigned long TcpRetransSegs;
unsigned long TcpInErrs;
unsigned long TcpOutRsts;
- unsigned long __pad[16-14];
-};
+ unsigned long __pad[0];
+} cacheline_aligned;
struct udp_mib
{
@@ -168,8 +185,8 @@
unsigned long UdpNoPorts;
unsigned long UdpInErrors;
unsigned long UdpOutDatagrams;
- unsigned long __pad[0];
-};
+ unsigned long __pad[0];
+} cacheline_aligned;
struct linux_mib
{
@@ -237,9 +254,15 @@
unsigned long TCPAbortOnLinger;
Re: Linux-2.4.0-test9-pre2
David S. Miller writes: Why not just tell these people "why are you working on experimental stuff, put together PPC stress test and kernel regression suites if you are bored, because we know 2.4.x isn't read for prime time" Mainly because: 1. the people providing the new "features" have not provided the "features" that are in 2.4.x. 2. Some people just don't subscribe to this idea, and, like Cort, they will go off and produce their own tree. I have a real example of (2) which happened *because* I wanted to make 2.2 stable - ARM now has a CVS tree which is used by a lot of people. This CVS tree was created, IMHO, because I tried to reduce the number of features going into late 2.1/early 2.2. Hence, the traditional argument that is applied to the "x86" side of Linux just doesn't hack it everywhere - if you try to apply it, you end up with people forking the tree left right and center. And no, they don't come back in a rush when you eventually get around to 2.5. They come back just before you finish 2.5. If I take what I believe to be Linus' attitude that I shouldn't care about this, then I'm just kidding myself - my code will just become a basis of all these other trees, and the only thing I'll be doing from that point on is providing a service to them where Linus' patches are cleanly merged with what my tree was a couple of years ago (ie, no new patches come in). I'm not agreeing that the fundamental "development/stable" cycles are bad, but trying to stop new features 100% is a bit like trying to build a damn out of sand for some of the architecture maintainers - it just doesn't work. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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: networking todo, was Re: Linux-2.4.0-test9-pre2
On Wed, Sep 20, 2000 at 04:38:24AM +0200, Andi Kleen wrote: We must be talking about different things. It of course detects it on ACK input, but only for data it did send itself. Every TCP detects reordering automatically on the input with the sequence number check, but all we still do is to send an ACK immediately and go into quickack mode. Agreed. I couldn't see how to "detect" the reordering in the receiver without additional informations from the dev.c layer (I don't think it's possible to detect it from the TCP layer without adding something like described by Andi in the below section that looks not very nice because it would hurt links with real packet loss). Or did I miss something ? The only way to do true reordering handling on the receiver I can think of would be to use something like the soft-timers to do very very fast delayed acks even for rcv_mss sized packets and hope that you collect packets from all CPUs in the delay, but overall it could still cost you a lot by disturbing the ACK clock [I talked a lot with Andrea about this during OLS, and we couldn't figure out a good way] I couldn't figure out a good way to fix that internally to TCP, but I have a quite simple solution at the dev.c layer (that would address also the problem with the not smart protocols that needs to retransmit everything once an hole in the sequence space is found). The solution consists in a sequence number protected by the spinlock in the NIC device driver (as DaveM suggested) and to increase this sequence number for each packet received and to set the sequence number value of the moment in each skb. Then we'd need a secondary (shared :( ) sequence numbers in the net_rx_action layer that will tell us the sequence number of the last packet that entered the higher level layer (IP in our case). With this per packet sequence number information we'll know if we're generating reordering by pushing the next packet in the softnet queue from net_rx_action to the IP layer. In that case we should only set up a wake-up-me-later logic and giveup. No idea how much this additional logic hurts. Certainly it could be enabled per-device/per-protocol basis. The other almost zero cost way to fix the reordering is of course to set the irq affinity of each nic only to one CPU :)) (this applies to the less smart protocol as well) 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: networking todo, was Re: Linux-2.4.0-test9-pre2
On Wed, Sep 20, 2000 at 03:29:39PM +0200, Andrea Arcangeli wrote: On Wed, Sep 20, 2000 at 04:38:24AM +0200, Andi Kleen wrote: We must be talking about different things. It of course detects it on ACK input, but only for data it did send itself. Every TCP detects reordering automatically on the input with the sequence number check, but all we still do is to send an ACK immediately and go into quickack mode. Agreed. I couldn't see how to "detect" the reordering in the receiver without additional informations from the dev.c layer (I don't think it's possible to detect it from the TCP layer without adding something like described by Andi in the below section that looks not very nice because it would hurt links with real packet loss). Assuming you have outgoing traffic on the NIC as well it isn't that bad, because there will be likely some queueing delay for the ACK in which you could in theory still cancel it of you know better (it would hurt the abstraction between device drivers and dev.c a lot though) The solution consists in a sequence number protected by the spinlock in the NIC device driver (as DaveM suggested) and to increase this sequence number for each packet received and to set the sequence number value of the moment in each skb. Then we'd need a secondary (shared :( ) sequence numbers in the net_rx_action layer that will tell us the sequence number of the last packet that entered the higher level layer (IP in our case). With this per packet sequence number information we'll know if we're generating reordering by pushing the next packet in the softnet queue from net_rx_action to the IP layer. In that case we should only set up a wake-up-me-later logic and giveup. That would just break the whole idea behind softnet. When you're juggling the cache line for the sequence counter you could as well juggle the cache line with a shared queue head, e.g. we would be at 2.2 level again. The other almost zero cost way to fix the reordering is of course to set the irq affinity of each nic only to one CPU :)) (this applies to the less smart protocol as well) That's the real solution long term, right. -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: networking todo, was Re: Linux-2.4.0-test9-pre2
On Wed, Sep 20, 2000 at 03:24:28PM +0200, Andi Kleen wrote: That would just break the whole idea behind softnet. When you're juggling I agree ;(. 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: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 09:36:30PM -0700, David Ford wrote: > Tom Rini wrote: > > > >that. I see that 2.4 is getting all kinds of changes merged in > > >that should be going on with 2.5. The recent VM changes have left > > >us with deadlocks that we didn't have before. Shouldn't that have > > >gone into 2.5 not 2.4? > > Well, I think the bitterness comes from (partily anyways) it going into > > 2.4.0-test9-pre1, along with other seemingly large updates, which did need > > to go in but really don't sound right for a -test. I guess Linus didn't want > > to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like > > small stuff (maybe my memory just sucks tho). > > The VM work has been scheduled to go in for a while. If you check the TODO > emails from months back, it's always been there. I wasn't arguing that (really) it's just that it really should have gone in sooner. It's all really a moot point I understand, but still. major overhauls should get in before the -testX IMHO. This is the point I think Cort was going after. Sure it's been well tested. But it's a major rewrite and it has introduced deadlocks (I'm going to have to track one down myself I think, this weekend) that weren't there. I'm sure it also fixed some. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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.4.0-test9-pre2 (version numbering)
On Tue, Sep 19, 2000 at 09:26:44PM -0700, Barry K. Nathan wrote: > > to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like > > small stuff (maybe my memory just sucks tho). > > I don't think there ever were any 2.2.0-testX patches - my recollection is > that we went from 2.1.1xx to 2.2.0-preX, with no -testX in between like we > seem to be having now. Ah yes, oops. I also then think people are assuming (possibly wrongly) that 2.4.0-testX == 2.4.0-preX. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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.4.0-test9-pre2
Tom Rini wrote: > >that. I see that 2.4 is getting all kinds of changes merged in > >that should be going on with 2.5. The recent VM changes have left > >us with deadlocks that we didn't have before. Shouldn't that have > >gone into 2.5 not 2.4? > Well, I think the bitterness comes from (partily anyways) it going into > 2.4.0-test9-pre1, along with other seemingly large updates, which did need > to go in but really don't sound right for a -test. I guess Linus didn't want > to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like > small stuff (maybe my memory just sucks tho). The VM work has been scheduled to go in for a while. If you check the TODO emails from months back, it's always been there. The VM patch required a lot of work and naturally such a big thing is going to uncover or trigger other bugs as well as expose bugs of it's own. It's gone in so we can find all those bugs and fix them before 2.4 gets released. In it's previous state, 2.4 was really bad for VM handling, that would have looked great for -all- enthusiasts to say "well...sure, 2.2 has better handling, but 2.4 is out!" *blink* *blink* -d -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President 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: Linux-2.4.0-test9-pre2 (version numbering)
> to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like > small stuff (maybe my memory just sucks tho). I don't think there ever were any 2.2.0-testX patches - my recollection is that we went from 2.1.1xx to 2.2.0-preX, with no -testX in between like we seem to be having now. In other words, if I understand things correctly, once we have Linux 2.4.0-test4294967296 ;) and 2.4 is stable enough for the last phase of testing before release, 2.4.0-pre1 will be next... -Barry K. Nathan <[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: networking todo, was Re: Linux-2.4.0-test9-pre2
Date:Wed, 20 Sep 2000 04:38:24 +0200 From: "Andi Kleen" <[EMAIL PROTECTED]> We must be talking about different things. It of course detects it on ACK input, but only for data it did send itself. Every TCP detects reordering automatically on the input with the sequence number check, but all we still do is to send an ACK immediately and go into quickack mode. Or did I miss something ? ... [I talked a lot with Andrea about this during OLS, and we couldn't figure out a good way] Nevermind, I've apparently got my directions reversed. :-) I'll think about this a bit. Just use __cacheline_aligned instead, like I did with the ip_local_data in the patch you just rejected. There is still the problem that generic SMP x86 kernels use a 32byte cacheline. Not a problem currently because the only x86 SMP is pII/pIII which has 32byte, but with Williamette/Athlon SMP it'll be a problem because these have 64byte and 128byte cache lines. With __cacheline_aligned it'll be easy though to pick up such changes. Ok, feel free to send me a patch which does only this. I may doctor it up a bit, be warned :-) On the other hand, the inetpeer code is only really exercised on machines that talk to lots and lots of destinations (=real servers), and 2.4 testing on such machines still has to begin. Given that 2.4 testing has not really begun yet I would guess that it is safer to remove it now @) True, but the following is what I'm really thinking about. Suppose a few weeks from now Alexey greets both of our mailboxes with a fabulous solution to the tw recycle masqeurading problem, wouldn't it be quite a pain in the ass to put back in and retest all the inetpeer code? Let's sit on this until Alexey gives a forecast about the possibilities of a solution in the near future ok? 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: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 05:14:39PM -0700, David S. Miller wrote: >Date: Tue, 19 Sep 2000 18:07:20 -0600 >From: Cort Dougan <[EMAIL PROTECTED]> > >Do you really think that's forcing people to concentrate of fixing >bugs? Tell me if you disagree, I'd like to understand how you see >that. I see that 2.4 is getting all kinds of changes merged in >that should be going on with 2.5. The recent VM changes have left >us with deadlocks that we didn't have before. Shouldn't that have >gone into 2.5 not 2.4? > > The VM performance in 2.4.x was a major regression from 2.2.x and is > required to be fixed for 2.4.0 release. Riel did the bulk of this > work, and it's now just dealing with a few remaining details on very > low memory systems. His changes fixed a major problem, and > structurally I believe his changes are completely sound and were > justifiably included in 2.4.x. > > So I think this was a bad example. Well, I think the bitterness comes from (partily anyways) it going into 2.4.0-test9-pre1, along with other seemingly large updates, which did need to go in but really don't sound right for a -test. I guess Linus didn't want to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like small stuff (maybe my memory just sucks tho). > I'll say this much, if 2.5.x existed I'd be spending most of my time > on a clean zero-copy TCP framework instead of walking over the net > stack and sparc64 code verifying things every day, that is for sure. > So yes, I am really thinking that it is forcing people to concentrate > on fixing bugs, because at least it is doing so for me. I know that > the faster 2.4.x happens the faster the "fun" 2.5.x stuff comes along. What Cort didn't mention is that at least some of this fun experimental stuff is things like better support for new machines, along with bug fixing for 2.4 (ie people can use all their PCI cards without resource conflicts again). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: networking todo, was Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 06:54:30PM -0700, David S. Miller wrote: >Date: Wed, 20 Sep 2000 03:51:37 +0200 >From: "Andi Kleen" <[EMAIL PROTECTED]> > >>Receiver side SMP reordering is still there, but I'm not sure if it is >>fixable (but it'll surely hit people that cannot use Linux senders, I >>just see the reports) >> >> Reordering is a non-issue for ipv4/ipv6, all of the massive TCP input >> rewrite was strictly about dealing with this. No SMP reordering >> should cause any bogus fast retransmits etc. for example. > >You mean TCP output rewrite ? The fix was strictly sender side only >(I first thought one of the ack changes alexey did was an attempt at a >hackish receiver side solution, but he told me that was false) > >> What is the problem? Are you referering to the LAPB/X25 stuff? > >When you have a non linux 2.4 sender you lose. > > Alexey's changes detect reordering on the input side, regardless of > whether it is speaking to a Linux senders or not, to avoid false > retransmits. We must be talking about different things. It of course detects it on ACK input, but only for data it did send itself. Every TCP detects reordering automatically on the input with the sequence number check, but all we still do is to send an ACK immediately and go into quickack mode. Or did I miss something ? The only way to do true reordering handling on the receiver I can think of would be to use something like the soft-timers to do very very fast delayed acks even for rcv_mss sized packets and hope that you collect packets from all CPUs in the delay, but overall it could still cost you a lot by disturbing the ACK clock [I talked a lot with Andrea about this during OLS, and we couldn't figure out a good way] > Please show me (and even more importantly Alexey) an example of where > receive reordering detection is dependant upon Linux TCP sender > behavior, his code it is as generic as I can imagine it to be. In > fact, his code got lots of the testing on a web server serving almost > exclusively clients running windows :-) Web clients probably do not send enough data to make reordering a problem because the request fits into 1-2 packets and the 3way handshake is not reordering sensitive. (I haven't looked at SpecWeb that closely, but has it really any client sent data that is >packet size?) > Ok, linux_mib is obviously not exact but in that case I would argue > that the extra size needed (to get to the next a power of 2) would > outweight whatever instruction performance gain we'd get. > > As for the udp etc. case, how do we pick a "number" to make these > arrays as you say they should be? Just use __cacheline_aligned instead, like I did with the ip_local_data in the patch you just rejected. There is still the problem that generic SMP x86 kernels use a 32byte cacheline. Not a problem currently because the only x86 SMP is pII/pIII which has 32byte, but with Williamette/Athlon SMP it'll be a problem because these have 64byte and 128byte cache lines. With __cacheline_aligned it'll be easy though to pick up such changes. > I would only make these changes for the snmp mibs which are "smaller" > than this "number" we pick, the larger ones won't see much false > sharing at all. > > I think this is really a small and trite issue actually. I don't think so. There was so much pain to avoid cache line bouncing for fast paths, it would be a shame to add it again for silly statistics keeping. > Removing a lot of code also means undoing all the testing done so far > with that code present :-))) True. On the other hand, the inetpeer code is only really exercised on machines that talk to lots and lots of destinations (=real servers), and 2.4 testing on such machines still has to begin. Given that 2.4 testing has not really begun yet I would guess that it is safer to remove it now @) -Andi (who is off to bed now) - 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: networking todo, was Re: Linux-2.4.0-test9-pre2
Date: Wed, 20 Sep 2000 03:51:37 +0200 From: "Andi Kleen" <[EMAIL PROTECTED]> >Receiver side SMP reordering is still there, but I'm not sure if it is >fixable (but it'll surely hit people that cannot use Linux senders, I >just see the reports) > > Reordering is a non-issue for ipv4/ipv6, all of the massive TCP input > rewrite was strictly about dealing with this. No SMP reordering > should cause any bogus fast retransmits etc. for example. You mean TCP output rewrite ? The fix was strictly sender side only (I first thought one of the ack changes alexey did was an attempt at a hackish receiver side solution, but he told me that was false) > What is the problem? Are you referering to the LAPB/X25 stuff? When you have a non linux 2.4 sender you lose. Alexey's changes detect reordering on the input side, regardless of whether it is speaking to a Linux senders or not, to avoid false retransmits. Please show me (and even more importantly Alexey) an example of where receive reordering detection is dependant upon Linux TCP sender behavior, his code it is as generic as I can imagine it to be. In fact, his code got lots of the testing on a web server serving almost exclusively clients running windows :-) When I count correctly sizeof(udp_mib) is 16 bytes currently (lots of false sharing on 32/64byte cacheline sized architectures) and linux_mib is 288 bytes currently (does not make any sense at all) Ok, linux_mib is obviously not exact but in that case I would argue that the extra size needed (to get to the next a power of 2) would outweight whatever instruction performance gain we'd get. As for the udp etc. case, how do we pick a "number" to make these arrays as you say they should be? I would only make these changes for the snmp mibs which are "smaller" than this "number" we pick, the larger ones won't see much false sharing at all. I think this is really a small and trite issue actually. >UDP recvmsg error handling for csum errors is bogus (fix pending) > > Ok, send me a patch so I can see what the problem is. Appended. Applied. The "unknown gain" is just removing a lot of complexity => speed and less bugs. Removing a lot of code also means undoing all the testing done so far with that code present :-))) The only advantage I know left is saving pmtus for a bit longer, but I doubt it is worth the complexity. Neither of us are experts in this area, Alexey is. Do you have any specific plan for salvaging tw recycling ? Just keeping such an intrusive piece of code for benchmarks around looks wasteful to me. Nope, but this also requires Alexey's input. 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: networking todo, was Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 06:13:38PM -0700, David S. Miller wrote:
>Date: Wed, 20 Sep 2000 03:14:10 +0200
>From: "Andi Kleen" <[EMAIL PROTECTED]>
>
>The ipid handling is still fishy, it will break when you talk to
>more destinations than the inetpeer cache can take (I fixed it in
>my local tree with the appended patch)
>
> I don't like this change, please work with Alexey on this one.
What do you dislike ? Stateless ipid looks much nicer to me than stateful
one (and the "security" lost by not refetching the secret is minimal,
especially given the state of the random device on machines without diskio
and keyboard input)
>Receiver side SMP reordering is still there, but I'm not sure if it is
>fixable (but it'll surely hit people that cannot use Linux senders, I
>just see the reports)
>
> Reordering is a non-issue for ipv4/ipv6, all of the massive TCP input
> rewrite was strictly about dealing with this. No SMP reordering
> should cause any bogus fast retransmits etc. for example.
You mean TCP output rewrite ? The fix was strictly sender side only
(I first thought one of the ack changes alexey did was an attempt at a
hackish receiver side solution, but he told me that was false)
> What is the problem? Are you referering to the LAPB/X25 stuff?
When you have a non linux 2.4 sender you lose.
>The TCP connect running out of ports problem is still there (I
>fixed it locally, but the changes are probably far too extensive
>for 2.4.x now)
>
> I think people can change their ip_local_port_range and I really
> consider this a non-issue, at least, it's not a 2.4.x show stopper.
I agree.
>
>The TCP ISN computation is not SMP safe.
>
> "Big deal". So how much effort will you go to to get how much more
> protection and how much of it do we really need? How less secure are
> our TCP ISN's because of this? Not a show-stopper.
>
> I think you're reading too much tcp-impl :-)
No, it has nothing to do with tcp-impl ;), I discovered it while playing
with the ipids much earlier. With some bad luck could could get very similar
ISNs, which is probably bad (an easy fix is to do the secret hash with a
stack copy instead of the static)
(but it is not a show stopper I agree)
>
>include/linux/snmp.h is probably still not properly aligned for all
>cache line sizes.
>
> Read, and reread what Alexey tries to tell you over and over about
> this. It is not meant to be cache line aligned, it is meant to be a
> power of two and nothing more.
It has to be at least cache line aligned, otherwise the arrays wouldn't
make any sense at all, the power of two would just be a (imho misguided but
anyways) optimization.
When I count correctly sizeof(udp_mib) is 16 bytes currently (lots of
false sharing on 32/64byte cacheline sized architectures) and linux_mib
is 288 bytes currently (does not make any sense at all)
>UDP recvmsg error handling for csum errors is bogus (fix pending)
>
> Ok, send me a patch so I can see what the problem is.
Appended.
>
>I also would like to remove the inetpeer cache code before 2.4.0, now
>that nobody managed to salvage tw recycling and ipid can do without it.
>
> I would prefer not to, it seems to be too potentially destabilizing
> for questionable and unknown gain (ie. we don't know if tw recycling
> can be salvaged, so lets not take any changes).
The "unknown gain" is just removing a lot of complexity => speed and less
bugs.
The only advantage I know left is saving pmtus for a bit longer, but
I doubt it is worth the complexity.
Do you have any specific plan for salvaging tw recycling ? Just keeping
such an intrusive piece of code for benchmarks around looks wasteful
to me.
-Andi
Index: net/ipv4/udp.c
===
RCS file: /cvs/linux/net/ipv4/udp.c,v
retrieving revision 1.85
diff -u -u -d -r1.85 udp.c
--- net/ipv4/udp.c 2000/08/09 11:59:04 1.85
+++ net/ipv4/udp.c 2000/09/17 11:55:29
@@ -493,8 +493,6 @@
if (usin->sin_family != AF_INET) {
if (usin->sin_family != AF_UNSPEC)
return -EINVAL;
- if (net_ratelimit())
- printk("Remind Kuznetsov, he has to repair %s
eventually\n", current->comm);
}
ufh.daddr = usin->sin_addr.s_addr;
@@ -678,6 +676,8 @@
if (flags & MSG_ERRQUEUE)
return ip_recv_error(sk, msg, len);
+
+ retry:
/*
* From here the generic datagram does a lot of the work. Come
* the finished NET3, it will do _ALL_ the work!
@@ -733,26 +733,21 @@
csum_copy_err:
UDP_INC_STATS_BH(UdpInErrors);
- /* Clear queue. */
- if (flags_PEEK) {
- int clear = 0;
+ if (flags&(MSG_PEEK|MSG_DONTWAIT)) {
+ struct sk_buff *skb2;
+
Re: networking todo, was Re: Linux-2.4.0-test9-pre2
Date: Wed, 20 Sep 2000 03:14:10 +0200 From: "Andi Kleen" <[EMAIL PROTECTED]> The ipid handling is still fishy, it will break when you talk to more destinations than the inetpeer cache can take (I fixed it in my local tree with the appended patch) I don't like this change, please work with Alexey on this one. Do not assume we are removing the inetpeer cache also, see below. Receiver side SMP reordering is still there, but I'm not sure if it is fixable (but it'll surely hit people that cannot use Linux senders, I just see the reports) Reordering is a non-issue for ipv4/ipv6, all of the massive TCP input rewrite was strictly about dealing with this. No SMP reordering should cause any bogus fast retransmits etc. for example. What is the problem? Are you referering to the LAPB/X25 stuff? The TCP connect running out of ports problem is still there (I fixed it locally, but the changes are probably far too extensive for 2.4.x now) I think people can change their ip_local_port_range and I really consider this a non-issue, at least, it's not a 2.4.x show stopper. The TCP ISN computation is not SMP safe. "Big deal". So how much effort will you go to to get how much more protection and how much of it do we really need? How less secure are our TCP ISN's because of this? Not a show-stopper. I think you're reading too much tcp-impl :-) include/linux/snmp.h is probably still not properly aligned for all cache line sizes. Read, and reread what Alexey tries to tell you over and over about this. It is not meant to be cache line aligned, it is meant to be a power of two and nothing more. Not a bug. UDP recvmsg error handling for csum errors is bogus (fix pending) Ok, send me a patch so I can see what the problem is. I also would like to remove the inetpeer cache code before 2.4.0, now that nobody managed to salvage tw recycling and ipid can do without it. I would prefer not to, it seems to be too potentially destabilizing for questionable and unknown gain (ie. we don't know if tw recycling can be salvaged, so lets not take any changes). 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/
networking todo, was Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 05:14:39PM -0700, David S. Miller wrote:
> And hey, guess what, as a result of this right now my "non-driver
> caused" core/ipv4/ipv6 networking bug list is pretty much empty right
> now. Only a few netfilter glitches appear to remain.
Some items for your list:
The ipid handling is still fishy, it will break when you talk to more
destinations than the inetpeer cache can take (I fixed it in my local
tree with the appended patch)
Receiver side SMP reordering is still there, but I'm not sure if it is
fixable (but it'll surely hit people that cannot use Linux senders, I
just see the reports)
The TCP connect running out of ports problem is still there (I fixed it
locally, but the changes are probably far too extensive for 2.4.x now)
The TCP ISN computation is not SMP safe.
include/linux/snmp.h is probably still not properly aligned for all
cache line sizes.
UDP recvmsg error handling for csum errors is bogus (fix pending)
net/ipv6/route.c:struct rt6_info ip6_null_entry initialisation seems
to be out of date (fix pending)
I also would like to remove the inetpeer cache code before 2.4.0, now
that nobody managed to salvage tw recycling and ipid can do without it.
-Andi
Index: drivers/char/random.c
===
RCS file: /cvs/linux/drivers/char/random.c,v
retrieving revision 1.47
diff -u -u -d -r1.47 random.c
--- drivers/char/random.c 2000/07/26 01:03:56 1.47
+++ drivers/char/random.c 2000/09/17 11:55:03
@@ -1994,6 +1994,13 @@
#define REKEY_INTERVAL 300
#define HASH_BITS 24
+/* Most of the following procedures have SMP races, which are mostly harmless
+ (it is possible that you get duplicated ISNs/or non monotonic IDs with some bad
+ luck)
+ You should definitely make sure that only start sending packets _after_
+ the random pool has been restored from disk.
+*/
+
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
__u32 secure_tcpv6_sequence_number(__u32 *saddr, __u32 *daddr,
__u16 sport, __u16 dport)
@@ -2099,24 +2106,22 @@
#endif
return seq;
}
+__u16 ip_id_counter;
/* The code below is shamelessly stolen from secure_tcp_sequence_number().
* All blames to Andrey V. Savochkin <[EMAIL PROTECTED]>.
+ * Changed by Andi Kleen to never rekey (blames to him now)
+ * Should be inlined.
*/
__u32 secure_ip_id(__u32 daddr)
{
- static time_t rekey_time = 0;
- static __u32secret[12];
- time_t t;
-
- /*
-* Pick a random secret every REKEY_INTERVAL seconds.
-*/
- t = CURRENT_TIME;
- if (!rekey_time || (t - rekey_time) > REKEY_INTERVAL) {
- rekey_time = t;
- /* First word is overwritten below. */
- get_random_bytes(secret+1, sizeof(secret)-4);
+ static __u32 ip_id_secret[12];
+ static int init;
+
+ if (!init) {
+ get_random_bytes(ip_id_secret+1, sizeof(ip_id_secret)-4);
+ get_random_bytes(_id_counter, 2);
+ init = 1;
}
/*
@@ -2127,9 +2132,9 @@
* hashing fixed data into it isn't going to improve anything,
* so we should get started with the variable data.
*/
- secret[0]=daddr;
+ ip_id_secret[0]=daddr;
- return halfMD4Transform(secret+8, secret);
+ return halfMD4Transform(ip_id_secret+8, ip_id_secret);
}
#ifdef CONFIG_SYN_COOKIES
Index: include/linux/random.h
===
RCS file: /cvs/linux/include/linux/random.h,v
retrieving revision 1.12
diff -u -u -d -r1.12 random.h
--- include/linux/random.h 2000/01/29 07:39:40 1.12
+++ include/linux/random.h 2000/09/17 11:55:09
@@ -56,6 +56,8 @@
extern void get_random_bytes(void *buf, int nbytes);
void generate_random_uuid(unsigned char uuid_out[16]);
+extern __u16 ip_id_counter;
+
extern __u32 secure_ip_id(__u32 daddr);
extern __u32 secure_tcp_sequence_number(__u32 saddr, __u32 daddr,
__u16 sport, __u16 dport);
Index: include/net/dst.h
===
RCS file: /cvs/linux/include/net/dst.h,v
retrieving revision 1.20
diff -u -u -d -r1.20 dst.h
--- include/net/dst.h 2000/08/09 11:59:03 1.20
+++ include/net/dst.h 2000/09/17 11:55:09
@@ -45,6 +45,7 @@
unsignedcwnd;
unsignedadvmss;
unsignedreordering;
+ unsignedidbase;
unsigned long rate_last; /* rate limiting for ICMP */
unsigned long rate_tokens;
Index: include/net/ip.h
===
RCS file: /cvs/linux/include/net/ip.h,v
retrieving revision 1.38
diff -u -u -d -r1.38 ip.h
--- include/net/ip.h2000/07/07 22:29:42 1.38
+++
Re: Linux-2.4.0-test9-pre2
Date: Tue, 19 Sep 2000 18:07:20 -0600 From: Cort Dougan <[EMAIL PROTECTED]> Do you really think that's forcing people to concentrate of fixing bugs? Tell me if you disagree, I'd like to understand how you see that. I see that 2.4 is getting all kinds of changes merged in that should be going on with 2.5. The recent VM changes have left us with deadlocks that we didn't have before. Shouldn't that have gone into 2.5 not 2.4? The VM performance in 2.4.x was a major regression from 2.2.x and is required to be fixed for 2.4.0 release. Riel did the bulk of this work, and it's now just dealing with a few remaining details on very low memory systems. His changes fixed a major problem, and structurally I believe his changes are completely sound and were justifiably included in 2.4.x. So I think this was a bad example. I'll say this much, if 2.5.x existed I'd be spending most of my time on a clean zero-copy TCP framework instead of walking over the net stack and sparc64 code verifying things every day, that is for sure. So yes, I am really thinking that it is forcing people to concentrate on fixing bugs, because at least it is doing so for me. I know that the faster 2.4.x happens the faster the "fun" 2.5.x stuff comes along. And hey, guess what, as a result of this right now my "non-driver caused" core/ipv4/ipv6 networking bug list is pretty much empty right now. Only a few netfilter glitches appear to remain. And hey, if you want the real proof, believe that even Alexey Kuznetsov has not worked on a new feature in nearly 2 months. :-)) 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: Linux-2.4.0-test9-pre2
}Date: Tue, 19 Sep 2000 16:49:00 -0600 }From: Cort Dougan <[EMAIL PROTECTED]> } }If anyone else wants access to the 2.5 tree we have as a place to }keep experimental changes I'm happy to open it up to the outside. } } Well, let's first step back for a second and really think about } what is being said here: } } 1) 2.4.x is taking too long } } 2) We have this backlog of new PPC features people are writing, }I can't put them into the 2.4.x tree, but I don't want to lose }them either. } } 3) So I've made a 2.5.x tree so the experimental stuff can occur }somewhere. My PPC guys want to change things. I can't stop them, but I can prevent them from screwing with 2.4 which needs to stay stable. If they don't wan to fix bugs in 2.4 then I can't force them to. They don't work for me, and I don't work for anyone who cares about PPC. So I'm not going to put a great deal of effort into forcing them to them to do something they don't want to. I've effectively kept them from making 2.4 unstable on PPC. That's a good thing, I think. I've also given them a place to do their experimentation before it becomes safe. Once it does, I can move it into 2.4 or wait for 2.5 if the changes don't become stable. } The _whole reason_ 2.5.x isn't started is so that people concentrate } on stabilizing 2.4.x instead of working on new stuff. Why not just } tell these people "why are you working on experimental stuff, put } together PPC stress test and kernel regression suites if you are } bored, because we know 2.4.x isn't read for prime time" Do you really think that's forcing people to concentrate of fixing bugs? Tell me if you disagree, I'd like to understand how you see that. I see that 2.4 is getting all kinds of changes merged in that should be going on with 2.5. The recent VM changes have left us with deadlocks that we didn't have before. Shouldn't that have gone into 2.5 not 2.4? I agree with the idea of getting people to concentrate on stabilizing 2.4. Some people want to work on other things, though. I'd like to give them a place to make their experimental changes outside of a stable tree. There's no place to do that. Instead, we get experimental changes in 2.4 and a buggy 2.4. } You cannot complain about 2.4.x not being timely if you are doing } things which directly encourage folks to not work on 2.4.x at all. } Right? What I've done has kept PPC-specific parts of 2.4 from becoming a mess of bugs. I've also allowed people to do their experimentation somewhere else, that won't break 2.4. Do you think that's wrong? Do you think I should have done it differently? If so, tell me how. I'm open to changing the way things work. If you'd suggest I just "make" people fix 2.4 then I suggest you do it, then tell me how. - 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.4.0-test9-pre2
Date:Tue, 19 Sep 2000 16:49:00 -0600 From: Cort Dougan <[EMAIL PROTECTED]> If anyone else wants access to the 2.5 tree we have as a place to keep experimental changes I'm happy to open it up to the outside. Well, let's first step back for a second and really think about what is being said here: 1) 2.4.x is taking too long 2) We have this backlog of new PPC features people are writing, I can't put them into the 2.4.x tree, but I don't want to lose them either. 3) So I've made a 2.5.x tree so the experimental stuff can occur somewhere. The _whole reason_ 2.5.x isn't started is so that people concentrate on stabilizing 2.4.x instead of working on new stuff. Why not just tell these people "why are you working on experimental stuff, put together PPC stress test and kernel regression suites if you are bored, because we know 2.4.x isn't read for prime time" You cannot complain about 2.4.x not being timely if you are doing things which directly encourage folks to not work on 2.4.x at all. Right? 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: Linux-2.4.0-test9-pre2
} Cort Dougan writes: } > I've had to create a 2.5 for the PPC tree so we aren't stuck with either no } > experimentation or experimentation in the stable trees. } } Well, you're not alone. There's a lot going on in the ARM side of Linux } which looks very promising; yes it is true that ARM is not the fastest } or the most optimal processor that Linux runs on, but there is a lot of } people who want to run it, both from the individual and the commercial } circles. } } As such, the ARM hardware that Linux now runs on is, ahem, quite varied, } and new hardware is coming along at an astounding rate - currently its } about one a week for the past 4 months (looking at the rate at which the } requests for architecture numbers come into my automated system). } } So yes, you can say that I'm probably in the same boat as you are as an } architecture maintainer, albeit I've currently got a little more room } to move for the time being. } } Maybe someone ought to kick off a 2.5 kernel series now, so that there's } somewhere for all these features to go (and I don't mean a private 2.5 } tree). This can then be handed (maybe piecemeal) to Linus? Maybe we can } use a version number like 2.5.0-u1 upwards? (u for unofficial, or maybe } even "unoff")? } } The only problem I can see with this (which I believe has been aired before) } is that it will detract from the bug fixing exercise for 2.4, since people } will be more interested in the new features of 2.5 rather than the bugs with } 2.4, but then again, I'd like to be proven wrong. My opinion is that 2.4 bug fixes are less common than unnecessary rewrites of working code that brings about even more instability and delays for a real and stable 2.4. Bitterness leaks out... I have a start to the 2.5 tree for PPC. We're keeping up-to-date with 2.4 changes so when the official 2.5 does come out we can merge our changes into it without too much trouble. I'm only allowing bugfixes into our 2.4 tree now that we have some place to play. If anyone else wants access to the 2.5 tree we have as a place to keep experimental changes I'm happy to open it up to the outside. - 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.4.0-test9-pre2
Cort Dougan writes: > I've had to create a 2.5 for the PPC tree so we aren't stuck with either no > experimentation or experimentation in the stable trees. Well, you're not alone. There's a lot going on in the ARM side of Linux which looks very promising; yes it is true that ARM is not the fastest or the most optimal processor that Linux runs on, but there is a lot of people who want to run it, both from the individual and the commercial circles. As such, the ARM hardware that Linux now runs on is, ahem, quite varied, and new hardware is coming along at an astounding rate - currently its about one a week for the past 4 months (looking at the rate at which the requests for architecture numbers come into my automated system). So yes, you can say that I'm probably in the same boat as you are as an architecture maintainer, albeit I've currently got a little more room to move for the time being. Maybe someone ought to kick off a 2.5 kernel series now, so that there's somewhere for all these features to go (and I don't mean a private 2.5 tree). This can then be handed (maybe piecemeal) to Linus? Maybe we can use a version number like 2.5.0-u1 upwards? (u for unofficial, or maybe even "unoff")? The only problem I can see with this (which I believe has been aired before) is that it will detract from the bug fixing exercise for 2.4, since people will be more interested in the new features of 2.5 rather than the bugs with 2.4, but then again, I'd like to be proven wrong. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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.4.0-test9-pre2
} On Tue, Sep 19, 2000 at 09:53:41PM +0200, [EMAIL PROTECTED] wrote: } > } > } > >> Linus, } > > } > >> Where do architecture maintainers stand when they don't submit their } > >> problems to linux-kernel or the great Ted Bug List(tm)? } > > } > >Up against the wall so we can shoot them? } > > } > >:) } > } > So I am one of the guys who will be shot ... I wanted to do an update for } > the s/390 architecture since weeks but there was always something more } > important. I finally cut some hours out of my ribs and made a patch against } > linux-2.4.0-test8. The diff for files in arch/s390, include/asm-s390 and } > drivers/s390 is pretty big, about 1 MB. The diffs for non s/390 files is } > smaller, only 35 KB. } > The question is now do you want to have the patch or do we wait until 2.4.1 } > ? } } Well, I'm not Linus (thank $DEITY for that; in that case, Linux would've } been an operating-system for the C=64...), but imho it would be cool if } we for once managed to release a v2.4.0 which actually managed to build } at least for some configurations on each platform. Oh, and I do firmly } believe that the S390 would be pretty non-critical to change, as it's } a new platform anyway, and the userbase is probably not that large yet } (hopefully it will become!) } } As for me, I'm content as long as MCA-support and MPC7400 support works } properly for respectively x86 and PPC... The problem for getting a stable 2.4.0 out is not with the architectures, they've been stable mostly. I'm fighting a tidal wave of changes from the PPC guys that I can't let into 2.4 or 2.2 since they're both supposed to be stable. We have to endure VM rewrites but the architecture-specific code has been pretty stable. If we could get a damned 2.4 our then we could also have a 2.5 and there would be some place for these experimental changes to go instead of the two stable trees. I've had to create a 2.5 for the PPC tree so we aren't stuck with either no experimentation or experimentation in the stable trees. - 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.4.0-test9-pre2
On Tue, Sep 19, 2000 at 09:53:41PM +0200, [EMAIL PROTECTED] wrote: > > > >> Linus, > > > >> Where do architecture maintainers stand when they don't submit their > >> problems to linux-kernel or the great Ted Bug List(tm)? > > > >Up against the wall so we can shoot them? > > > >:) > > So I am one of the guys who will be shot ... I wanted to do an update for > the s/390 architecture since weeks but there was always something more > important. I finally cut some hours out of my ribs and made a patch against > linux-2.4.0-test8. The diff for files in arch/s390, include/asm-s390 and > drivers/s390 is pretty big, about 1 MB. The diffs for non s/390 files is > smaller, only 35 KB. > The question is now do you want to have the patch or do we wait until 2.4.1 > ? Well, I'm not Linus (thank $DEITY for that; in that case, Linux would've been an operating-system for the C=64...), but imho it would be cool if we for once managed to release a v2.4.0 which actually managed to build at least for some configurations on each platform. Oh, and I do firmly believe that the S390 would be pretty non-critical to change, as it's a new platform anyway, and the userbase is probably not that large yet (hopefully it will become!) As for me, I'm content as long as MCA-support and MPC7400 support works properly for respectively x86 and PPC... /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
inlines [was Re: Linux-2.4.0-test9-pre2]
Linus Torvalds writes: > > >On Tue, 19 Sep 2000, Rogier Wolff wrote: >> >> If gcc starts shouting: >> >> somefile.c:1234: declared inline function 'serial_paranoia_check' is >> somefile.c:1234: larger than 1k. Declining to honor the inline directive. > >That's not what gcc does. > >Gcc silently just doesn't inline it. > >From the gcc-2.95.2 manual: `-Winline' Warn if a function can not be inlined, and either it was declared as inline, or else the `-finline-functions' option was given. Ralph. - 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.4.0-test9-pre2
>> Linus, > >> Where do architecture maintainers stand when they don't submit their >> problems to linux-kernel or the great Ted Bug List(tm)? > >Up against the wall so we can shoot them? > >:) So I am one of the guys who will be shot ... I wanted to do an update for the s/390 architecture since weeks but there was always something more important. I finally cut some hours out of my ribs and made a patch against linux-2.4.0-test8. The diff for files in arch/s390, include/asm-s390 and drivers/s390 is pretty big, about 1 MB. The diffs for non s/390 files is smaller, only 35 KB. The question is now do you want to have the patch or do we wait until 2.4.1 ? blue skies, Martin Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247 E-Mail: [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: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 07:50:05AM -0700, Linus Torvalds wrote: > > > On Tue, 19 Sep 2000, Rogier Wolff wrote: > > > > If gcc starts shouting: > > > > somefile.c:1234: declared inline function 'serial_paranoia_check' is > > somefile.c:1234: larger than 1k. Declining to honor the inline directive. > > That's not what gcc does. > > Gcc silently just doesn't inline it. Unless you define -Winline I always wondered why it isn't the default in the kernel source, I use it regularly. -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: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 05:58:48AM -0300, Rik van Riel wrote: > One of the issues which seems to be affecting performance > is the elevator starvation bug, though, so I'm not sure how You are contraddicting yourself. If you decrease the latency (so if you fix the starvation) the global disk throughput can only decrease. > Once the elevator problem has been solved, we should be able I'm tired of you screwing up the VM and then complaining the elevator. At least try to vary and choose something else to complain. At test1 time you may been right, but now we're so permissive in the default settings exactly to be sure the elevator isn't hurting performance. 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: Linux-2.4.0-test9-pre2
On Tue, 19 Sep 2000, Rogier Wolff wrote: > > If gcc starts shouting: > > somefile.c:1234: declared inline function 'serial_paranoia_check' is > somefile.c:1234: larger than 1k. Declining to honor the inline directive. That's not what gcc does. Gcc silently just doesn't inline it. And the error message you get is ld: undefined function 'serial_paranoia_check' which is not exactly helpful. That, together with the fact that gcc's notion of "large" is completely undefined (for a while, it had absolutely nothing to do with size, but with what kinds of things the function did, like having the address of a label taken) means that it's basically not useful for what you suggest anyway.. Linus - 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.4.0-test9-pre2
On Sun, 17 Sep 2000, Mark Orr wrote: > Has anyone else tried 240-test9-pre2 on low-memory systems? > > I compiled 240t9p2, bzlilo'ed it, and rebooted. During > boot it tripped up on e2fsck -- it was at maximum mount count > and it stopped during the check. > Sys: pentium 100, 16Mb RAM + 17 Mb swap This is interesting to hear. I'm doing tests booting my system with mem=8m and am busy trying to fix the performance of low-memory systems. One of the issues which seems to be affecting performance is the elevator starvation bug, though, so I'm not sure how much of the problem is a VM issue. (my test machine is SCSI and has a decent size queue in hardware so the elevator algorithm problem doesn't hit ... my workstation, with 192MB RAM and an IDE disk, is seeing the starvation though) Once the elevator problem has been solved, we should be able to see if there is still a big VM problem left, but the tests with low memory on my SCSI-based test box seem to suggest that it may well be an elevator related problem... 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: Linux-2.4.0-test9-pre2
Linus Torvalds wrote: > > > On Mon, 18 Sep 2000, David Woodhouse wrote: > > > > [EMAIL PROTECTED] said: > > > Note that with most versions of gcc this is all a complete non-issue, > > > as most versions of gcc will _always_ inline a function that the user > > > has asked to be inlined. So the issue seldom actually comes up. > > > > I thought that 'extern inline' was in fact the intended usage. That way, if > > gcc decides it's not going to obey our explicit instruction to inline a > > certain function, we get to know about it. > > And what could we do about it? Basically nothing. If gcc starts shouting: somefile.c:1234: declared inline function 'serial_paranoia_check' is somefile.c:1234: larger than 1k. Declining to honor the inline directive. [...] /tmp/cc39I5yn.o(.text+0x4): undefined reference to `serial_paranoia_check' you'll get a pile of Email, so that you can decide what's wrong. I thought that you thought that that was better than just having it silently bloat enormously. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein - 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.4.0-test9-pre2
Linus Torvalds wrote: On Mon, 18 Sep 2000, David Woodhouse wrote: [EMAIL PROTECTED] said: Note that with most versions of gcc this is all a complete non-issue, as most versions of gcc will _always_ inline a function that the user has asked to be inlined. So the issue seldom actually comes up. I thought that 'extern inline' was in fact the intended usage. That way, if gcc decides it's not going to obey our explicit instruction to inline a certain function, we get to know about it. And what could we do about it? Basically nothing. If gcc starts shouting: somefile.c:1234: declared inline function 'serial_paranoia_check' is somefile.c:1234: larger than 1k. Declining to honor the inline directive. [...] /tmp/cc39I5yn.o(.text+0x4): undefined reference to `serial_paranoia_check' you'll get a pile of Email, so that you can decide what's wrong. I thought that you thought that that was better than just having it silently bloat enormously. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * Common sense is the collection of* ** prejudices acquired by age eighteen. -- Albert Einstein - 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.4.0-test9-pre2
On Tue, 19 Sep 2000, Rogier Wolff wrote: If gcc starts shouting: somefile.c:1234: declared inline function 'serial_paranoia_check' is somefile.c:1234: larger than 1k. Declining to honor the inline directive. That's not what gcc does. Gcc silently just doesn't inline it. And the error message you get is ld: undefined function 'serial_paranoia_check' which is not exactly helpful. That, together with the fact that gcc's notion of "large" is completely undefined (for a while, it had absolutely nothing to do with size, but with what kinds of things the function did, like having the address of a label taken) means that it's basically not useful for what you suggest anyway.. Linus - 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.4.0-test9-pre2
On Tue, Sep 19, 2000 at 05:58:48AM -0300, Rik van Riel wrote: One of the issues which seems to be affecting performance is the elevator starvation bug, though, so I'm not sure how You are contraddicting yourself. If you decrease the latency (so if you fix the starvation) the global disk throughput can only decrease. Once the elevator problem has been solved, we should be able I'm tired of you screwing up the VM and then complaining the elevator. At least try to vary and choose something else to complain. At test1 time you may been right, but now we're so permissive in the default settings exactly to be sure the elevator isn't hurting performance. 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: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 07:50:05AM -0700, Linus Torvalds wrote: On Tue, 19 Sep 2000, Rogier Wolff wrote: If gcc starts shouting: somefile.c:1234: declared inline function 'serial_paranoia_check' is somefile.c:1234: larger than 1k. Declining to honor the inline directive. That's not what gcc does. Gcc silently just doesn't inline it. Unless you define -Winline I always wondered why it isn't the default in the kernel source, I use it regularly. -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/
inlines [was Re: Linux-2.4.0-test9-pre2]
Linus Torvalds writes: On Tue, 19 Sep 2000, Rogier Wolff wrote: If gcc starts shouting: somefile.c:1234: declared inline function 'serial_paranoia_check' is somefile.c:1234: larger than 1k. Declining to honor the inline directive. That's not what gcc does. Gcc silently just doesn't inline it. From the gcc-2.95.2 manual: `-Winline' Warn if a function can not be inlined, and either it was declared as inline, or else the `-finline-functions' option was given. Ralph. - 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.4.0-test9-pre2
} On Tue, Sep 19, 2000 at 09:53:41PM +0200, [EMAIL PROTECTED] wrote: } } }Linus, } } Where do architecture maintainers stand when they don't submit their } problems to linux-kernel or the great Ted Bug List(tm)? } } Up against the wall so we can shoot them? } } :) } } So I am one of the guys who will be shot ... I wanted to do an update for } the s/390 architecture since weeks but there was always something more } important. I finally cut some hours out of my ribs and made a patch against } linux-2.4.0-test8. The diff for files in arch/s390, include/asm-s390 and } drivers/s390 is pretty big, about 1 MB. The diffs for non s/390 files is } smaller, only 35 KB. } The question is now do you want to have the patch or do we wait until 2.4.1 } ? } } Well, I'm not Linus (thank $DEITY for that; in that case, Linux would've } been an operating-system for the C=64...), but imho it would be cool if } we for once managed to release a v2.4.0 which actually managed to build } at least for some configurations on each platform. Oh, and I do firmly } believe that the S390 would be pretty non-critical to change, as it's } a new platform anyway, and the userbase is probably not that large yet } (hopefully it will become!) } } As for me, I'm content as long as MCA-support and MPC7400 support works } properly for respectively x86 and PPC... The problem for getting a stable 2.4.0 out is not with the architectures, they've been stable mostly. I'm fighting a tidal wave of changes from the PPC guys that I can't let into 2.4 or 2.2 since they're both supposed to be stable. We have to endure VM rewrites but the architecture-specific code has been pretty stable. If we could get a damned 2.4 our then we could also have a 2.5 and there would be some place for these experimental changes to go instead of the two stable trees. I've had to create a 2.5 for the PPC tree so we aren't stuck with either no experimentation or experimentation in the stable trees. - 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.4.0-test9-pre2
Cort Dougan writes: I've had to create a 2.5 for the PPC tree so we aren't stuck with either no experimentation or experimentation in the stable trees. Well, you're not alone. There's a lot going on in the ARM side of Linux which looks very promising; yes it is true that ARM is not the fastest or the most optimal processor that Linux runs on, but there is a lot of people who want to run it, both from the individual and the commercial circles. As such, the ARM hardware that Linux now runs on is, ahem, quite varied, and new hardware is coming along at an astounding rate - currently its about one a week for the past 4 months (looking at the rate at which the requests for architecture numbers come into my automated system). So yes, you can say that I'm probably in the same boat as you are as an architecture maintainer, albeit I've currently got a little more room to move for the time being. Maybe someone ought to kick off a 2.5 kernel series now, so that there's somewhere for all these features to go (and I don't mean a private 2.5 tree). This can then be handed (maybe piecemeal) to Linus? Maybe we can use a version number like 2.5.0-u1 upwards? (u for unofficial, or maybe even "unoff")? The only problem I can see with this (which I believe has been aired before) is that it will detract from the bug fixing exercise for 2.4, since people will be more interested in the new features of 2.5 rather than the bugs with 2.4, but then again, I'd like to be proven wrong. _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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.4.0-test9-pre2 (version numbering)
to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like small stuff (maybe my memory just sucks tho). I don't think there ever were any 2.2.0-testX patches - my recollection is that we went from 2.1.1xx to 2.2.0-preX, with no -testX in between like we seem to be having now. In other words, if I understand things correctly, once we have Linux 2.4.0-test4294967296 ;) and 2.4 is stable enough for the last phase of testing before release, 2.4.0-pre1 will be next... -Barry K. Nathan [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: Linux-2.4.0-test9-pre2 (version numbering)
On Tue, Sep 19, 2000 at 09:26:44PM -0700, Barry K. Nathan wrote: to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like small stuff (maybe my memory just sucks tho). I don't think there ever were any 2.2.0-testX patches - my recollection is that we went from 2.1.1xx to 2.2.0-preX, with no -testX in between like we seem to be having now. Ah yes, oops. I also then think people are assuming (possibly wrongly) that 2.4.0-testX == 2.4.0-preX. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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.4.0-test9-pre2
On Tue, Sep 19, 2000 at 09:36:30PM -0700, David Ford wrote: Tom Rini wrote: that. I see that 2.4 is getting all kinds of changes merged in that should be going on with 2.5. The recent VM changes have left us with deadlocks that we didn't have before. Shouldn't that have gone into 2.5 not 2.4? Well, I think the bitterness comes from (partily anyways) it going into 2.4.0-test9-pre1, along with other seemingly large updates, which did need to go in but really don't sound right for a -test. I guess Linus didn't want to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like small stuff (maybe my memory just sucks tho). The VM work has been scheduled to go in for a while. If you check the TODO emails from months back, it's always been there. I wasn't arguing that (really) it's just that it really should have gone in sooner. It's all really a moot point I understand, but still. major overhauls should get in before the -testX IMHO. This is the point I think Cort was going after. Sure it's been well tested. But it's a major rewrite and it has introduced deadlocks (I'm going to have to track one down myself I think, this weekend) that weren't there. I'm sure it also fixed some. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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.4.0-test9-pre2
Date:Tue, 19 Sep 2000 16:49:00 -0600 From: Cort Dougan [EMAIL PROTECTED] If anyone else wants access to the 2.5 tree we have as a place to keep experimental changes I'm happy to open it up to the outside. Well, let's first step back for a second and really think about what is being said here: 1) 2.4.x is taking too long 2) We have this backlog of new PPC features people are writing, I can't put them into the 2.4.x tree, but I don't want to lose them either. 3) So I've made a 2.5.x tree so the experimental stuff can occur somewhere. The _whole reason_ 2.5.x isn't started is so that people concentrate on stabilizing 2.4.x instead of working on new stuff. Why not just tell these people "why are you working on experimental stuff, put together PPC stress test and kernel regression suites if you are bored, because we know 2.4.x isn't read for prime time" You cannot complain about 2.4.x not being timely if you are doing things which directly encourage folks to not work on 2.4.x at all. Right? 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: networking todo, was Re: Linux-2.4.0-test9-pre2
Date: Wed, 20 Sep 2000 03:51:37 +0200 From: "Andi Kleen" [EMAIL PROTECTED] Receiver side SMP reordering is still there, but I'm not sure if it is fixable (but it'll surely hit people that cannot use Linux senders, I just see the reports) Reordering is a non-issue for ipv4/ipv6, all of the massive TCP input rewrite was strictly about dealing with this. No SMP reordering should cause any bogus fast retransmits etc. for example. You mean TCP output rewrite ? The fix was strictly sender side only (I first thought one of the ack changes alexey did was an attempt at a hackish receiver side solution, but he told me that was false) What is the problem? Are you referering to the LAPB/X25 stuff? When you have a non linux 2.4 sender you lose. Alexey's changes detect reordering on the input side, regardless of whether it is speaking to a Linux senders or not, to avoid false retransmits. Please show me (and even more importantly Alexey) an example of where receive reordering detection is dependant upon Linux TCP sender behavior, his code it is as generic as I can imagine it to be. In fact, his code got lots of the testing on a web server serving almost exclusively clients running windows :-) When I count correctly sizeof(udp_mib) is 16 bytes currently (lots of false sharing on 32/64byte cacheline sized architectures) and linux_mib is 288 bytes currently (does not make any sense at all) Ok, linux_mib is obviously not exact but in that case I would argue that the extra size needed (to get to the next a power of 2) would outweight whatever instruction performance gain we'd get. As for the udp etc. case, how do we pick a "number" to make these arrays as you say they should be? I would only make these changes for the snmp mibs which are "smaller" than this "number" we pick, the larger ones won't see much false sharing at all. I think this is really a small and trite issue actually. UDP recvmsg error handling for csum errors is bogus (fix pending) Ok, send me a patch so I can see what the problem is. Appended. Applied. The "unknown gain" is just removing a lot of complexity = speed and less bugs. Removing a lot of code also means undoing all the testing done so far with that code present :-))) The only advantage I know left is saving pmtus for a bit longer, but I doubt it is worth the complexity. Neither of us are experts in this area, Alexey is. Do you have any specific plan for salvaging tw recycling ? Just keeping such an intrusive piece of code for benchmarks around looks wasteful to me. Nope, but this also requires Alexey's input. 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: Linux-2.4.0-test9-pre2
}Date: Tue, 19 Sep 2000 16:49:00 -0600 }From: Cort Dougan [EMAIL PROTECTED] } }If anyone else wants access to the 2.5 tree we have as a place to }keep experimental changes I'm happy to open it up to the outside. } } Well, let's first step back for a second and really think about } what is being said here: } } 1) 2.4.x is taking too long } } 2) We have this backlog of new PPC features people are writing, }I can't put them into the 2.4.x tree, but I don't want to lose }them either. } } 3) So I've made a 2.5.x tree so the experimental stuff can occur }somewhere. My PPC guys want to change things. I can't stop them, but I can prevent them from screwing with 2.4 which needs to stay stable. If they don't wan to fix bugs in 2.4 then I can't force them to. They don't work for me, and I don't work for anyone who cares about PPC. So I'm not going to put a great deal of effort into forcing them to them to do something they don't want to. I've effectively kept them from making 2.4 unstable on PPC. That's a good thing, I think. I've also given them a place to do their experimentation before it becomes safe. Once it does, I can move it into 2.4 or wait for 2.5 if the changes don't become stable. } The _whole reason_ 2.5.x isn't started is so that people concentrate } on stabilizing 2.4.x instead of working on new stuff. Why not just } tell these people "why are you working on experimental stuff, put } together PPC stress test and kernel regression suites if you are } bored, because we know 2.4.x isn't read for prime time" Do you really think that's forcing people to concentrate of fixing bugs? Tell me if you disagree, I'd like to understand how you see that. I see that 2.4 is getting all kinds of changes merged in that should be going on with 2.5. The recent VM changes have left us with deadlocks that we didn't have before. Shouldn't that have gone into 2.5 not 2.4? I agree with the idea of getting people to concentrate on stabilizing 2.4. Some people want to work on other things, though. I'd like to give them a place to make their experimental changes outside of a stable tree. There's no place to do that. Instead, we get experimental changes in 2.4 and a buggy 2.4. } You cannot complain about 2.4.x not being timely if you are doing } things which directly encourage folks to not work on 2.4.x at all. } Right? What I've done has kept PPC-specific parts of 2.4 from becoming a mess of bugs. I've also allowed people to do their experimentation somewhere else, that won't break 2.4. Do you think that's wrong? Do you think I should have done it differently? If so, tell me how. I'm open to changing the way things work. If you'd suggest I just "make" people fix 2.4 then I suggest you do it, then tell me how. - 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.4.0-test9-pre2
Date: Tue, 19 Sep 2000 18:07:20 -0600 From: Cort Dougan [EMAIL PROTECTED] Do you really think that's forcing people to concentrate of fixing bugs? Tell me if you disagree, I'd like to understand how you see that. I see that 2.4 is getting all kinds of changes merged in that should be going on with 2.5. The recent VM changes have left us with deadlocks that we didn't have before. Shouldn't that have gone into 2.5 not 2.4? The VM performance in 2.4.x was a major regression from 2.2.x and is required to be fixed for 2.4.0 release. Riel did the bulk of this work, and it's now just dealing with a few remaining details on very low memory systems. His changes fixed a major problem, and structurally I believe his changes are completely sound and were justifiably included in 2.4.x. So I think this was a bad example. I'll say this much, if 2.5.x existed I'd be spending most of my time on a clean zero-copy TCP framework instead of walking over the net stack and sparc64 code verifying things every day, that is for sure. So yes, I am really thinking that it is forcing people to concentrate on fixing bugs, because at least it is doing so for me. I know that the faster 2.4.x happens the faster the "fun" 2.5.x stuff comes along. And hey, guess what, as a result of this right now my "non-driver caused" core/ipv4/ipv6 networking bug list is pretty much empty right now. Only a few netfilter glitches appear to remain. And hey, if you want the real proof, believe that even Alexey Kuznetsov has not worked on a new feature in nearly 2 months. :-)) 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/
networking todo, was Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 05:14:39PM -0700, David S. Miller wrote:
And hey, guess what, as a result of this right now my "non-driver
caused" core/ipv4/ipv6 networking bug list is pretty much empty right
now. Only a few netfilter glitches appear to remain.
Some items for your list:
The ipid handling is still fishy, it will break when you talk to more
destinations than the inetpeer cache can take (I fixed it in my local
tree with the appended patch)
Receiver side SMP reordering is still there, but I'm not sure if it is
fixable (but it'll surely hit people that cannot use Linux senders, I
just see the reports)
The TCP connect running out of ports problem is still there (I fixed it
locally, but the changes are probably far too extensive for 2.4.x now)
The TCP ISN computation is not SMP safe.
include/linux/snmp.h is probably still not properly aligned for all
cache line sizes.
UDP recvmsg error handling for csum errors is bogus (fix pending)
net/ipv6/route.c:struct rt6_info ip6_null_entry initialisation seems
to be out of date (fix pending)
I also would like to remove the inetpeer cache code before 2.4.0, now
that nobody managed to salvage tw recycling and ipid can do without it.
-Andi
Index: drivers/char/random.c
===
RCS file: /cvs/linux/drivers/char/random.c,v
retrieving revision 1.47
diff -u -u -d -r1.47 random.c
--- drivers/char/random.c 2000/07/26 01:03:56 1.47
+++ drivers/char/random.c 2000/09/17 11:55:03
@@ -1994,6 +1994,13 @@
#define REKEY_INTERVAL 300
#define HASH_BITS 24
+/* Most of the following procedures have SMP races, which are mostly harmless
+ (it is possible that you get duplicated ISNs/or non monotonic IDs with some bad
+ luck)
+ You should definitely make sure that only start sending packets _after_
+ the random pool has been restored from disk.
+*/
+
#if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
__u32 secure_tcpv6_sequence_number(__u32 *saddr, __u32 *daddr,
__u16 sport, __u16 dport)
@@ -2099,24 +2106,22 @@
#endif
return seq;
}
+__u16 ip_id_counter;
/* The code below is shamelessly stolen from secure_tcp_sequence_number().
* All blames to Andrey V. Savochkin [EMAIL PROTECTED].
+ * Changed by Andi Kleen to never rekey (blames to him now)
+ * Should be inlined.
*/
__u32 secure_ip_id(__u32 daddr)
{
- static time_t rekey_time = 0;
- static __u32secret[12];
- time_t t;
-
- /*
-* Pick a random secret every REKEY_INTERVAL seconds.
-*/
- t = CURRENT_TIME;
- if (!rekey_time || (t - rekey_time) REKEY_INTERVAL) {
- rekey_time = t;
- /* First word is overwritten below. */
- get_random_bytes(secret+1, sizeof(secret)-4);
+ static __u32 ip_id_secret[12];
+ static int init;
+
+ if (!init) {
+ get_random_bytes(ip_id_secret+1, sizeof(ip_id_secret)-4);
+ get_random_bytes(ip_id_counter, 2);
+ init = 1;
}
/*
@@ -2127,9 +2132,9 @@
* hashing fixed data into it isn't going to improve anything,
* so we should get started with the variable data.
*/
- secret[0]=daddr;
+ ip_id_secret[0]=daddr;
- return halfMD4Transform(secret+8, secret);
+ return halfMD4Transform(ip_id_secret+8, ip_id_secret);
}
#ifdef CONFIG_SYN_COOKIES
Index: include/linux/random.h
===
RCS file: /cvs/linux/include/linux/random.h,v
retrieving revision 1.12
diff -u -u -d -r1.12 random.h
--- include/linux/random.h 2000/01/29 07:39:40 1.12
+++ include/linux/random.h 2000/09/17 11:55:09
@@ -56,6 +56,8 @@
extern void get_random_bytes(void *buf, int nbytes);
void generate_random_uuid(unsigned char uuid_out[16]);
+extern __u16 ip_id_counter;
+
extern __u32 secure_ip_id(__u32 daddr);
extern __u32 secure_tcp_sequence_number(__u32 saddr, __u32 daddr,
__u16 sport, __u16 dport);
Index: include/net/dst.h
===
RCS file: /cvs/linux/include/net/dst.h,v
retrieving revision 1.20
diff -u -u -d -r1.20 dst.h
--- include/net/dst.h 2000/08/09 11:59:03 1.20
+++ include/net/dst.h 2000/09/17 11:55:09
@@ -45,6 +45,7 @@
unsignedcwnd;
unsignedadvmss;
unsignedreordering;
+ unsignedidbase;
unsigned long rate_last; /* rate limiting for ICMP */
unsigned long rate_tokens;
Index: include/net/ip.h
===
RCS file: /cvs/linux/include/net/ip.h,v
retrieving revision 1.38
diff -u -u -d -r1.38 ip.h
--- include/net/ip.h2000/07/07 22:29:42 1.38
+++
Re: networking todo, was Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 06:13:38PM -0700, David S. Miller wrote:
Date: Wed, 20 Sep 2000 03:14:10 +0200
From: "Andi Kleen" [EMAIL PROTECTED]
The ipid handling is still fishy, it will break when you talk to
more destinations than the inetpeer cache can take (I fixed it in
my local tree with the appended patch)
I don't like this change, please work with Alexey on this one.
What do you dislike ? Stateless ipid looks much nicer to me than stateful
one (and the "security" lost by not refetching the secret is minimal,
especially given the state of the random device on machines without diskio
and keyboard input)
Receiver side SMP reordering is still there, but I'm not sure if it is
fixable (but it'll surely hit people that cannot use Linux senders, I
just see the reports)
Reordering is a non-issue for ipv4/ipv6, all of the massive TCP input
rewrite was strictly about dealing with this. No SMP reordering
should cause any bogus fast retransmits etc. for example.
You mean TCP output rewrite ? The fix was strictly sender side only
(I first thought one of the ack changes alexey did was an attempt at a
hackish receiver side solution, but he told me that was false)
What is the problem? Are you referering to the LAPB/X25 stuff?
When you have a non linux 2.4 sender you lose.
The TCP connect running out of ports problem is still there (I
fixed it locally, but the changes are probably far too extensive
for 2.4.x now)
I think people can change their ip_local_port_range and I really
consider this a non-issue, at least, it's not a 2.4.x show stopper.
I agree.
The TCP ISN computation is not SMP safe.
"Big deal". So how much effort will you go to to get how much more
protection and how much of it do we really need? How less secure are
our TCP ISN's because of this? Not a show-stopper.
I think you're reading too much tcp-impl :-)
No, it has nothing to do with tcp-impl ;), I discovered it while playing
with the ipids much earlier. With some bad luck could could get very similar
ISNs, which is probably bad (an easy fix is to do the secret hash with a
stack copy instead of the static)
(but it is not a show stopper I agree)
include/linux/snmp.h is probably still not properly aligned for all
cache line sizes.
Read, and reread what Alexey tries to tell you over and over about
this. It is not meant to be cache line aligned, it is meant to be a
power of two and nothing more.
It has to be at least cache line aligned, otherwise the arrays wouldn't
make any sense at all, the power of two would just be a (imho misguided but
anyways) optimization.
When I count correctly sizeof(udp_mib) is 16 bytes currently (lots of
false sharing on 32/64byte cacheline sized architectures) and linux_mib
is 288 bytes currently (does not make any sense at all)
UDP recvmsg error handling for csum errors is bogus (fix pending)
Ok, send me a patch so I can see what the problem is.
Appended.
I also would like to remove the inetpeer cache code before 2.4.0, now
that nobody managed to salvage tw recycling and ipid can do without it.
I would prefer not to, it seems to be too potentially destabilizing
for questionable and unknown gain (ie. we don't know if tw recycling
can be salvaged, so lets not take any changes).
The "unknown gain" is just removing a lot of complexity = speed and less
bugs.
The only advantage I know left is saving pmtus for a bit longer, but
I doubt it is worth the complexity.
Do you have any specific plan for salvaging tw recycling ? Just keeping
such an intrusive piece of code for benchmarks around looks wasteful
to me.
-Andi
Index: net/ipv4/udp.c
===
RCS file: /cvs/linux/net/ipv4/udp.c,v
retrieving revision 1.85
diff -u -u -d -r1.85 udp.c
--- net/ipv4/udp.c 2000/08/09 11:59:04 1.85
+++ net/ipv4/udp.c 2000/09/17 11:55:29
@@ -493,8 +493,6 @@
if (usin-sin_family != AF_INET) {
if (usin-sin_family != AF_UNSPEC)
return -EINVAL;
- if (net_ratelimit())
- printk("Remind Kuznetsov, he has to repair %s
eventually\n", current-comm);
}
ufh.daddr = usin-sin_addr.s_addr;
@@ -678,6 +676,8 @@
if (flags MSG_ERRQUEUE)
return ip_recv_error(sk, msg, len);
+
+ retry:
/*
* From here the generic datagram does a lot of the work. Come
* the finished NET3, it will do _ALL_ the work!
@@ -733,26 +733,21 @@
csum_copy_err:
UDP_INC_STATS_BH(UdpInErrors);
- /* Clear queue. */
- if (flagsMSG_PEEK) {
- int clear = 0;
+ if (flags(MSG_PEEK|MSG_DONTWAIT)) {
+ struct sk_buff *skb2;
+
spin_lock_irq(sk-receive_queue.lock);
- if (skb ==
Re: networking todo, was Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 06:54:30PM -0700, David S. Miller wrote: Date: Wed, 20 Sep 2000 03:51:37 +0200 From: "Andi Kleen" [EMAIL PROTECTED] Receiver side SMP reordering is still there, but I'm not sure if it is fixable (but it'll surely hit people that cannot use Linux senders, I just see the reports) Reordering is a non-issue for ipv4/ipv6, all of the massive TCP input rewrite was strictly about dealing with this. No SMP reordering should cause any bogus fast retransmits etc. for example. You mean TCP output rewrite ? The fix was strictly sender side only (I first thought one of the ack changes alexey did was an attempt at a hackish receiver side solution, but he told me that was false) What is the problem? Are you referering to the LAPB/X25 stuff? When you have a non linux 2.4 sender you lose. Alexey's changes detect reordering on the input side, regardless of whether it is speaking to a Linux senders or not, to avoid false retransmits. We must be talking about different things. It of course detects it on ACK input, but only for data it did send itself. Every TCP detects reordering automatically on the input with the sequence number check, but all we still do is to send an ACK immediately and go into quickack mode. Or did I miss something ? The only way to do true reordering handling on the receiver I can think of would be to use something like the soft-timers to do very very fast delayed acks even for rcv_mss sized packets and hope that you collect packets from all CPUs in the delay, but overall it could still cost you a lot by disturbing the ACK clock [I talked a lot with Andrea about this during OLS, and we couldn't figure out a good way] Please show me (and even more importantly Alexey) an example of where receive reordering detection is dependant upon Linux TCP sender behavior, his code it is as generic as I can imagine it to be. In fact, his code got lots of the testing on a web server serving almost exclusively clients running windows :-) Web clients probably do not send enough data to make reordering a problem because the request fits into 1-2 packets and the 3way handshake is not reordering sensitive. (I haven't looked at SpecWeb that closely, but has it really any client sent data that is packet size?) Ok, linux_mib is obviously not exact but in that case I would argue that the extra size needed (to get to the next a power of 2) would outweight whatever instruction performance gain we'd get. As for the udp etc. case, how do we pick a "number" to make these arrays as you say they should be? Just use __cacheline_aligned instead, like I did with the ip_local_data in the patch you just rejected. There is still the problem that generic SMP x86 kernels use a 32byte cacheline. Not a problem currently because the only x86 SMP is pII/pIII which has 32byte, but with Williamette/Athlon SMP it'll be a problem because these have 64byte and 128byte cache lines. With __cacheline_aligned it'll be easy though to pick up such changes. I would only make these changes for the snmp mibs which are "smaller" than this "number" we pick, the larger ones won't see much false sharing at all. I think this is really a small and trite issue actually. I don't think so. There was so much pain to avoid cache line bouncing for fast paths, it would be a shame to add it again for silly statistics keeping. Removing a lot of code also means undoing all the testing done so far with that code present :-))) True. On the other hand, the inetpeer code is only really exercised on machines that talk to lots and lots of destinations (=real servers), and 2.4 testing on such machines still has to begin. Given that 2.4 testing has not really begun yet I would guess that it is safer to remove it now @) -Andi (who is off to bed now) - 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.4.0-test9-pre2
On Tue, Sep 19, 2000 at 05:14:39PM -0700, David S. Miller wrote: Date: Tue, 19 Sep 2000 18:07:20 -0600 From: Cort Dougan [EMAIL PROTECTED] Do you really think that's forcing people to concentrate of fixing bugs? Tell me if you disagree, I'd like to understand how you see that. I see that 2.4 is getting all kinds of changes merged in that should be going on with 2.5. The recent VM changes have left us with deadlocks that we didn't have before. Shouldn't that have gone into 2.5 not 2.4? The VM performance in 2.4.x was a major regression from 2.2.x and is required to be fixed for 2.4.0 release. Riel did the bulk of this work, and it's now just dealing with a few remaining details on very low memory systems. His changes fixed a major problem, and structurally I believe his changes are completely sound and were justifiably included in 2.4.x. So I think this was a bad example. Well, I think the bitterness comes from (partily anyways) it going into 2.4.0-test9-pre1, along with other seemingly large updates, which did need to go in but really don't sound right for a -test. I guess Linus didn't want to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like small stuff (maybe my memory just sucks tho). I'll say this much, if 2.5.x existed I'd be spending most of my time on a clean zero-copy TCP framework instead of walking over the net stack and sparc64 code verifying things every day, that is for sure. So yes, I am really thinking that it is forcing people to concentrate on fixing bugs, because at least it is doing so for me. I know that the faster 2.4.x happens the faster the "fun" 2.5.x stuff comes along. What Cort didn't mention is that at least some of this fun experimental stuff is things like better support for new machines, along with bug fixing for 2.4 (ie people can use all their PCI cards without resource conflicts again). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: networking todo, was Re: Linux-2.4.0-test9-pre2
Date:Wed, 20 Sep 2000 04:38:24 +0200 From: "Andi Kleen" [EMAIL PROTECTED] We must be talking about different things. It of course detects it on ACK input, but only for data it did send itself. Every TCP detects reordering automatically on the input with the sequence number check, but all we still do is to send an ACK immediately and go into quickack mode. Or did I miss something ? ... [I talked a lot with Andrea about this during OLS, and we couldn't figure out a good way] Nevermind, I've apparently got my directions reversed. :-) I'll think about this a bit. Just use __cacheline_aligned instead, like I did with the ip_local_data in the patch you just rejected. There is still the problem that generic SMP x86 kernels use a 32byte cacheline. Not a problem currently because the only x86 SMP is pII/pIII which has 32byte, but with Williamette/Athlon SMP it'll be a problem because these have 64byte and 128byte cache lines. With __cacheline_aligned it'll be easy though to pick up such changes. Ok, feel free to send me a patch which does only this. I may doctor it up a bit, be warned :-) On the other hand, the inetpeer code is only really exercised on machines that talk to lots and lots of destinations (=real servers), and 2.4 testing on such machines still has to begin. Given that 2.4 testing has not really begun yet I would guess that it is safer to remove it now @) True, but the following is what I'm really thinking about. Suppose a few weeks from now Alexey greets both of our mailboxes with a fabulous solution to the tw recycle masqeurading problem, wouldn't it be quite a pain in the ass to put back in and retest all the inetpeer code? Let's sit on this until Alexey gives a forecast about the possibilities of a solution in the near future ok? 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: Linux-2.4.0-test9-pre2
On Sun, Sep 17, 2000 at 10:37:51AM -0700, Linus Torvalds wrote: > > Ok. I think we're getting to the point where there are no major known > bugs. That means that as of the final 2.4.0-test9 I will no longer accept > any patches that don't have a critical problem (as defined by Teds list) > associated with them. > > So when you send me a patch, either bug Ted to mark the issue as > "critical" first, or pay me money. It's that easy. I have been doing some testing just to see how well the new VM stuff works. I think I have found a bug in both test9-pre1 and test9-pre2. If I boot my machine (400MHz AMD-K6 3D+, 128M Ram, IDE disks, 512M swap) with mem=48M added to the LILO command line and try and build mozilla, the machine will eventually die. I can still ping it, but I cant connect to the http or sshd servers, I cant get anything to show up on the monitor, and the disk does not make any noise. After I reboot (and fsck :-<), the logs do not contain any information about what happened. If I run test8 instead of one of the test9 kernels then everything seems to work. If I dont limit the memory to 48M then the test9 kernels work fine. I am attaching the script that I use to build mozilla just in case anyone wants to try and reproduce this. Thanks, Jim #!/bin/sh CMD="/home/jlnance/src/19980429/mozilla/configure --disable-tests --enable-nspr-autoconf" UNAMER=`uname -r` if [ ! -d $UNAMER ]; then mkdir $UNAMER; fi for x in 1 2 3 4; do TFILE=$UNAMER/time.$x if [ -f $TFILE ]; then echo $TFILE exists. Skipping continue fi echo -n "starting" date echo -n "erasing " rm -rf nbt/* date echo -n "configuring " (cd nbt; exec $CMD) > log 2>&1 date echo -n "building" csh -c "time sh -c \"exec make -s -C nbt >>log 2>&1\"" >$TFILE 2>&1 date echo done
Re: Linux-2.4.0-test9-pre2
Hi! > Ok. I think we're getting to the point where there are no major known > bugs. That means that as of the final 2.4.0-test9 I will no longer accept > any patches that don't have a critical problem (as defined by Teds list) > associated with them. > So when you send me a patch, either bug Ted to mark the issue as > "critical" first, or pay me money. It's that easy. Does PCMCIA work for you? I get reliable (and fatal) oops whenever I plug or unplug PCMCIA card at runtime (at least ne2k and ide cause same oops). This is toshiba satellite 4030cdt. 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: Linux-2.4.0-test9-pre2
"Dunlap, Randy" <[EMAIL PROTECTED]> said: [] > > Good thing I promised Ted to bring another bottle of > > that Brazillian liquor to the next event we meet ;) > Rik, does it have to be Brazilian liquor? > I still have patches for 2.4.0-final also. You'd have to ask Ted... BTW folks, please don't overdo this "exotic liquor for patch urgencies" swap: If Ted is over the edge, he won't do anything about it. ;-) On a more serious note: What about documentation patches? 'perl scripts/checkhelp.pl $(find . -name "[Cc]onfig.in")' counts 301 help texts missing in 2.2.18pre9 and 238 in 2.4.0-test9-pre2... -- Horst von Brand [EMAIL PROTECTED] Casilla 9G, Vin~a del Mar, Chile +56 32 672616 - 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.4.0-test9-pre2
On Mon, Sep 18, 2000 at 05:11:35PM +0100, David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > Linus, > > > Where do architecture maintainers stand when they don't submit their > > problems to linux-kernel or the great Ted Bug List(tm)? > > Up against the wall so we can shoot them? I know that was a joke, but it's a good question. I know PPC still has some issues that need to be sorted out (We got lots of PCI resource collisions on most(all?) new machines, which really shouldn't be). I'm sure other arches have problems which haven't been posted on l-k but have been on their respective -dev list. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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.4.0-test9-pre2
[EMAIL PROTECTED] said: > Linus, > Where do architecture maintainers stand when they don't submit their > problems to linux-kernel or the great Ted Bug List(tm)? Up against the wall so we can shoot them? :) -- dwmw2 - 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.4.0-test9-pre2
On Mon, 18 Sep 2000, David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > Note that with most versions of gcc this is all a complete non-issue, > > as most versions of gcc will _always_ inline a function that the user > > has asked to be inlined. So the issue seldom actually comes up. > > I thought that 'extern inline' was in fact the intended usage. That way, if > gcc decides it's not going to obey our explicit instruction to inline a > certain function, we get to know about it. And what could we do about it? Basically nothing. So we might as well use "static inline". Linus - 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.4.0-test9-pre2
On Sun, 17 Sep 2000, Mark Orr wrote: > Has anyone else tried 240-test9-pre2 on low-memory systems? Hmmm... I am getting periodic hangs on reading floppies AFTER initrd inititialization Maybe once every 20 boots.. same thing.. strange hang, and a control gets by whatever process was hanging and it continues... Thought it was maybe a floppy hardware read issue, but wondering... -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - 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.4.0-test9-pre2
[EMAIL PROTECTED] said: > Note that with most versions of gcc this is all a complete non-issue, > as most versions of gcc will _always_ inline a function that the user > has asked to be inlined. So the issue seldom actually comes up. I thought that 'extern inline' was in fact the intended usage. That way, if gcc decides it's not going to obey our explicit instruction to inline a certain function, we get to know about it. -- dwmw2 - 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.4.0-test9-pre2
Ted, How does one identify the "critical" items in the 2.4 Status/TODO list? Will you be adding a "critical" section or adding "(critical)" on some items on the 2.4 Status/TODO list? I'm updating the USB list now and wondering how to mark items as critical. Thanks, ~Randy ___ > Ok. I think we're getting to the point where there are no major known > bugs. That means that as of the final 2.4.0-test9 I will no > longer accept > any patches that don't have a critical problem (as defined by > Teds list) associated with them. > > So when you send me a patch, either bug Ted to mark the issue as > "critical" first, or pay me money. It's that easy. > > Linus - 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.4.0-test9-pre2
Linus Torvalds writes: > So when you send me a patch, either bug Ted to mark the issue as > "critical" first, or pay me money. It's that easy. Linus, Where do architecture maintainers stand when they don't submit their problems to linux-kernel or the great Ted Bug List(tm)? _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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.4.0-test9-pre2
When trying to compile I get: drivers/scsi/scsidrv.o: In function `init_sd': drivers/scsi/scsidrv.o(.text+0x68ae): undefined reference to `scsi_register_module' drivers/scsi/scsidrv.o: In function `exit_sd': drivers/scsi/scsidrv.o(.text+0x68c3): undefined reference to `scsi_unregister_module' drivers/scsi/scsidrv.o: In function `init_sr': drivers/scsi/scsidrv.o(.text.init+0x646): undefined reference to `scsi_register_module' I am compile for the aic7xxx and no modules. This also happened on 2.4.0-test8. What else can I tell? Thanks, : Gene Imes http://www.ozob.net : - 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.4.0-test9-pre2
H. Peter Anvin wrote: > Ideally, the linker should have some kind of merging pass to merge > these multiple instances -- this really could help C++ template > instantiation problems as well -- but for now, the only "safe" way is > pretty much to provide a library with non-inlined versions and hope > nothing gets linked from it. The linker does merge multiple instances of C++ template functions. It's GCC you'd need to teach about merging the non-inlined functions. - 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.4.0-test9-pre2
Linus Torvalds writes: So when you send me a patch, either bug Ted to mark the issue as "critical" first, or pay me money. It's that easy. Linus, Where do architecture maintainers stand when they don't submit their problems to linux-kernel or the great Ted Bug List(tm)? _ |_| - ---+---+- | | Russell King[EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/personal/aboutme.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ - /\\\ | - 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.4.0-test9-pre2
Ted, How does one identify the "critical" items in the 2.4 Status/TODO list? Will you be adding a "critical" section or adding "(critical)" on some items on the 2.4 Status/TODO list? I'm updating the USB list now and wondering how to mark items as critical. Thanks, ~Randy ___ Ok. I think we're getting to the point where there are no major known bugs. That means that as of the final 2.4.0-test9 I will no longer accept any patches that don't have a critical problem (as defined by Teds list) associated with them. So when you send me a patch, either bug Ted to mark the issue as "critical" first, or pay me money. It's that easy. Linus - 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.4.0-test9-pre2
[EMAIL PROTECTED] said: Note that with most versions of gcc this is all a complete non-issue, as most versions of gcc will _always_ inline a function that the user has asked to be inlined. So the issue seldom actually comes up. I thought that 'extern inline' was in fact the intended usage. That way, if gcc decides it's not going to obey our explicit instruction to inline a certain function, we get to know about it. -- dwmw2 - 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.4.0-test9-pre2
On Sun, 17 Sep 2000, Mark Orr wrote: Has anyone else tried 240-test9-pre2 on low-memory systems? Hmmm... I am getting periodic hangs on reading floppies AFTER initrd inititialization Maybe once every 20 boots.. same thing.. strange hang, and a control c gets by whatever process was hanging and it continues... Thought it was maybe a floppy hardware read issue, but wondering... -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - 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.4.0-test9-pre2
On Mon, 18 Sep 2000, David Woodhouse wrote: [EMAIL PROTECTED] said: Note that with most versions of gcc this is all a complete non-issue, as most versions of gcc will _always_ inline a function that the user has asked to be inlined. So the issue seldom actually comes up. I thought that 'extern inline' was in fact the intended usage. That way, if gcc decides it's not going to obey our explicit instruction to inline a certain function, we get to know about it. And what could we do about it? Basically nothing. So we might as well use "static inline". Linus - 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.4.0-test9-pre2
[EMAIL PROTECTED] said: Linus, Where do architecture maintainers stand when they don't submit their problems to linux-kernel or the great Ted Bug List(tm)? Up against the wall so we can shoot them? :) -- dwmw2 - 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.4.0-test9-pre2
On Mon, Sep 18, 2000 at 05:11:35PM +0100, David Woodhouse wrote: [EMAIL PROTECTED] said: Linus, Where do architecture maintainers stand when they don't submit their problems to linux-kernel or the great Ted Bug List(tm)? Up against the wall so we can shoot them? I know that was a joke, but it's a good question. I know PPC still has some issues that need to be sorted out (We got lots of PCI resource collisions on most(all?) new machines, which really shouldn't be). I'm sure other arches have problems which haven't been posted on l-k but have been on their respective -dev list. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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.4.0-test9-pre2
Hi! Ok. I think we're getting to the point where there are no major known bugs. That means that as of the final 2.4.0-test9 I will no longer accept any patches that don't have a critical problem (as defined by Teds list) associated with them. So when you send me a patch, either bug Ted to mark the issue as "critical" first, or pay me money. It's that easy. Does PCMCIA work for you? I get reliable (and fatal) oops whenever I plug or unplug PCMCIA card at runtime (at least ne2k and ide cause same oops). This is toshiba satellite 4030cdt. 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: Linux-2.4.0-test9-pre2
On Sun, Sep 17, 2000 at 10:37:51AM -0700, Linus Torvalds wrote: Ok. I think we're getting to the point where there are no major known bugs. That means that as of the final 2.4.0-test9 I will no longer accept any patches that don't have a critical problem (as defined by Teds list) associated with them. So when you send me a patch, either bug Ted to mark the issue as "critical" first, or pay me money. It's that easy. I have been doing some testing just to see how well the new VM stuff works. I think I have found a bug in both test9-pre1 and test9-pre2. If I boot my machine (400MHz AMD-K6 3D+, 128M Ram, IDE disks, 512M swap) with mem=48M added to the LILO command line and try and build mozilla, the machine will eventually die. I can still ping it, but I cant connect to the http or sshd servers, I cant get anything to show up on the monitor, and the disk does not make any noise. After I reboot (and fsck :-), the logs do not contain any information about what happened. If I run test8 instead of one of the test9 kernels then everything seems to work. If I dont limit the memory to 48M then the test9 kernels work fine. I am attaching the script that I use to build mozilla just in case anyone wants to try and reproduce this. Thanks, Jim #!/bin/sh CMD="/home/jlnance/src/19980429/mozilla/configure --disable-tests --enable-nspr-autoconf" UNAMER=`uname -r` if [ ! -d $UNAMER ]; then mkdir $UNAMER; fi for x in 1 2 3 4; do TFILE=$UNAMER/time.$x if [ -f $TFILE ]; then echo $TFILE exists. Skipping continue fi echo -n "starting" date echo -n "erasing " rm -rf nbt/* date echo -n "configuring " (cd nbt; exec $CMD) log 21 date echo -n "building" csh -c "time sh -c \"exec make -s -C nbt log 21\"" $TFILE 21 date echo done
Re: Linux-2.4.0-test9-pre2
Followup to: <[EMAIL PROTECTED]> By author:Linus Torvalds <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Let's assume that gcc decides that it won't inline a function, because > it's too "big", according to some gcc definition of "big". > > With "extern inline", the function will not exist AT ALL, and you'll end > up getting a link-time error complaining about the lack of that function. > > With "static inline", gcc will emit the function as a separate function > for that compilation block if it didn't get inlined. > > Both are valid things. You use "extern inline" when you have a "backing > store" for the funcion (ie you do have the non-inlined version in a > library somewhere). You use "static inline" when you don't. > > For the kernel, we very seldom have the non-inlined versions in any > library, so for the kernel "extern inline" is almost always the wrong > thing. > > Note that with most versions of gcc this is all a complete non-issue, as > most versions of gcc will _always_ inline a function that the user has > asked to be inlined. So the issue seldom actually comes up. > Well, the major issue is if we want an error message (extern inline) or potentially majorly bloated code because the same code has been produced in multiple translation units (static inline). Ideally, the linker should have some kind of merging pass to merge these multiple instances -- this really could help C++ template instantiation problems as well -- but for now, the only "safe" way is pretty much to provide a library with non-inlined versions and hope nothing gets linked from it. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - 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.4.0-test9-pre2
Has anyone else tried 240-test9-pre2 on low-memory systems? I compiled 240t9p2, bzlilo'ed it, and rebooted. During boot it tripped up on e2fsck -- it was at maximum mount count and it stopped during the check. Once I got past the check, and was able to get it to a prompt. I tried to compile the kernel modules. Once again, it stopped during the compile of the first file (either loop.c or floppy.c). By "stopped", I mean the _program_ acted as though it had hung. The system didnt hang, I was able to ctrl-c out of it, and there was no oops or panic.It doesnt seem to be able to run any substantial program w/o stopping. Previous kernel was 240-test8, no problems there. Sys: pentium 100, 16Mb RAM + 17 Mb swap -- Mark Orr [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: Linux-2.4.0-test9-pre2
> > Ok. I think we're getting to the point where there are no major > > known bugs. That means that as of the final 2.4.0-test9 I will > > no longer accept any patches that don't have a critical problem > > (as defined by Teds list) associated with them. > > > > So when you send me a patch, either bug Ted to mark the issue as > > "critical" first, or pay me money. It's that easy. > > Hmm, the new VM doesn't have the out of memory killer > integrated yet. I'll do some out of memory / low on > swap work and will send you the patch soon, dependant > on how connected I will be during Linux Kongress... > > Good thing I promised Ted to bring another bottle of > that Brazillian liquor to the next event we meet ;) > > cheers, > > Rik Rik, does it have to be Brazilian liquor? I still have patches for 2.4.0-final also. ~Randy - 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.4.0-test9-pre2
Erick Kinnee wrote: > > On Sun, Sep 17, 2000 at 10:37:51AM -0700, Linus Torvalds wrote: > > - pre2: > > - "extern inline" -> "static inline". It doesn't matter right now, > > but it's proactive for future gcc versions. > > - various net drvr updates and fixes > > - more initcall updates > > - PPC updates (including PPC-related drivers etc) > > - disallow re-mounting same filesystem in same place multiple times. > > Too confusing. And /etc/mtab gets strange. > > - Riel VM update > > - sparc updates > > - PCI bridge scanning fix: assign numbers properly > > - network updates > > - scsi fixes > > Building for a sun4c I get this: > > In file included from pcic.c:26: > /org/scratch/cerb/linux/include/linux/pci.h:556: warning: static declaration for >`pcibios_present' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:558: warning: static declaration for >`pcibios_find_class' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:568: warning: static declaration for >`pcibios_read_config_byte' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:568: warning: static declaration for >`pci_read_config_byte' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:568: warning: static declaration for >`pcibios_read_config_word' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:568: warning: static declaration for >`pci_read_config_word' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:568: warning: static declaration for >`pcibios_read_config_dword' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:568: warning: static declaration for >`pci_read_config_dword' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:569: warning: static declaration for >`pcibios_write_config_byte' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:569: warning: static declaration for >`pci_write_config_byte' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:569: warning: static declaration for >`pcibios_write_config_word' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:569: warning: static declaration for >`pci_write_config_word' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:569: warning: static declaration for >`pcibios_write_config_dword' follows >non-static/org/scratch/cerb/linux/include/linux/pci.h:569: warning: static >declaration for `pci_write_config_dword' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:572: warning: static declaration for >`pci_find_device' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:575: warning: static declaration for >`pci_find_class' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:578: warning: static declaration for >`pci_find_slot' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:582: warning: static declaration for >`pci_find_subsys' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:584: warning: static declaration for >`pci_set_master' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:585: warning: static declaration for >`pci_enable_device' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:587: warning: static declaration for >`pci_assign_resource' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:588: warning: static declaration for >`pci_register_driver' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:589: warning: static declaration for >`pci_unregister_driver' follows non-static > /org/scratch/cerb/linux/include/linux/pci.h:591: warning: static declaration for >`pci_find_capability' follows non-static > pcic.c:39: redefinition of `pcibios_present' > /org/scratch/cerb/linux/include/linux/pci.h:556: `pcibios_present' previously >defined here > make[1]: *** [pcic.o] Error 1 > make[1]: Leaving directory `/org/scratch/cerb/linux/arch/sparc/kernel' > make: *** [_dir_arch/sparc/kernel] Error 2 Looks like the !CONFIG_PCI case is conflicting with the prototypes. Thanks, I'll fix it up. 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: Linux-2.4.0-test9-pre2
On Sun, 17 Sep 2000, Alan Cox wrote: > > bugs. That means that as of the final 2.4.0-test9 I will no longer accept > > any patches that don't have a critical problem (as defined by Teds list) > > associated with them. > > Argh. Im not going to have time to push all the driver fixes from 2.2 into > 2.4 then, I've got a house move to do yet Alan, 'it happens that is why most distros will not ship a 2.4.0 kernel and will wait for 2.4.1 or 2.4.2. Cheers, Andre Hedrick The Linux ATA/IDE guy - 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.4.0-test9-pre2 -> still CardBus problems
Linus Torvalds wrote: > Ok. I think we're getting to the point where there are no major known > bugs. That means that as of the final 2.4.0-test9 I will no longer accept > any patches that don't have a critical problem (as defined by Teds list) > associated with them. [snip] > - PCI bridge scanning fix: assign numbers properly [snip] Don't know if this was intended to fix the CardBus problem on certain DELL (others?) laptops. It doesn't work on mine, anyway. I do get a slightly more informative error message though... And my CardBus is now bus #6 and not #4 as it was with test8. If that makes a difference. I have enbled some debugging in the output below. All pcmcia/cardbus stuff is built as modules. Using the native kernel bits only. (It is no better with the standalone package from David Hinds.) Linux version 2.4.0-test9 (root@dagblap) (gcc version 2.95.2 19991024 (release)) #4 Sun Sep 17 22:31:09 CE ST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 05ef @ 0010 (usable) BIOS-e820: 0001 @ 05ff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 24560 zone(0): 4096 pages. zone(1): 20464 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=test9p2d ro root=/dev/discs/disc0/part5 Initializing CPU#0 Detected 363965751 Hz processor. Console: colour dummy device 80x25 Calibrating delay loop... 725.81 BogoMIPS Memory: 94180k/98240k available (1497k kernel code, 3672k reserved, 104k data, 196k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) CPU: Intel Mobile Pentium II stepping 0a Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: BIOS32 Service Directory structure at 0xc00ffe80 PCI: BIOS32 Service Directory entry at 0xffe90 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=01 PCI: PCI BIOS revision 2.10 entry at 0xfc0ee, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: IDE base address fixup for 00:07.1 PCI: Scanning for ghost devices on bus 0 PCI: Scanning for ghost devices on bus 1 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbda0 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource f400-f7ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource ec80-ecbf (f=101, d=0, p=0) PCI: Resource fb00-fbff (f=1208, d=0, p=0) PCI: Resource fdc0-fdff (f=200, d=0, p=0) PCI: Resource fdb0-fdbf (f=200, d=0, p=0) PCI: Resource fac0-faff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) PCI: Sorting device list... Limiting direct PCI/PCI transfers. [snip] # lsmod Module Size Used by # modprobe yenta_socket # lsmod Module Size Used by yenta_socket9836 2 pcmcia_core43840 0 [yenta_socket] # dmesg [snip] Linux PCMCIA Card Services 3.1.20 options: [pci] [cardbus] [pm] cs.c 1.267 2000/08/30 22:07:31 (David Hinds) Yenta IRQ list 0098, PCI irq11 Socket status: 3006 cs: pcmcia_register_socket(0xc6a7a280) Yenta IRQ list 0098, PCI irq11 Socket status: 3020 cs: pcmcia_register_socket(0xc6a7a280) # modprobe ds # dmesg [snip] ds.c 1.108 2000/08/07 19:06:15 (David Hinds) cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 PCI: Failed to allocate resource 0 for PCI device 115d:0003 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: Device 06:00.0 not available because of resource collisions PCI: Failed to allocate resource 0 for PCI device 115d:0103 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: Device 06:00.1 not available because of resource collisions # lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 00:03.0 CardBus bridge: Texas Instruments PCI1225
Re: Linux-2.4.0-test9-pre2
On Mon, Sep 18, 2000 at 07:07:18AM +1200, Chris Wedgwood wrote: > - "extern inline" -> "static inline". It doesn't matter right now, > but it's proactive for future gcc versions. > > can someone please explain the difference? info gcc 'c ext' inline "extern inline" implies that an external definition exists, and that if the compiler chooses not to inline the function, that it needn't provide a out of line definition. "static inline" implies that the function needn't be visible outside the unit of translation, and so if an out of line version isn't needed, it needn't be emitted. "inline" currently implies that the function does need to be visible outside the unit of translation, and that an out of line version must always be provided. This may change in the future, since ISO C99 added the inline keyword and made it work like C++, i.e. static inline. The old behaviour would still be available from --std=gnu89. r~ - 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.4.0-test9-pre2
> > Argh. Im not going to have time to push all the driver fixes from 2.2 into > > 2.4 then, I've got a house move to do yet > > Alan, 'it happens that is why most distros will not ship a 2.4.0 kernel > and will wait for 2.4.1 or 2.4.2. Historically distros ship something about version 5-6, significant stability occurs about 10-14 and by 20+ its getting really good :) Yeah I know we have time but there are serious security issues, exploitable memory leaks and stuff fixed in 2.2 but not yet in 2.4test. Having said that Im sure Ted would mark those 'urgent' 8) - 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.4.0-test9-pre2
On Mon, 18 Sep 2000, Chris Wedgwood wrote: > On Sun, Sep 17, 2000 at 10:37:51AM -0700, Linus Torvalds wrote: > > - "extern inline" -> "static inline". It doesn't matter right now, > but it's proactive for future gcc versions. > > can someone please explain the difference? Let's assume that gcc decides that it won't inline a function, because it's too "big", according to some gcc definition of "big". With "extern inline", the function will not exist AT ALL, and you'll end up getting a link-time error complaining about the lack of that function. With "static inline", gcc will emit the function as a separate function for that compilation block if it didn't get inlined. Both are valid things. You use "extern inline" when you have a "backing store" for the funcion (ie you do have the non-inlined version in a library somewhere). You use "static inline" when you don't. For the kernel, we very seldom have the non-inlined versions in any library, so for the kernel "extern inline" is almost always the wrong thing. Note that with most versions of gcc this is all a complete non-issue, as most versions of gcc will _always_ inline a function that the user has asked to be inlined. So the issue seldom actually comes up. Linus - 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.4.0-test9-pre2
On Sun, 17 Sep 2000, Linus Torvalds wrote: > Ok. I think we're getting to the point where there are no major > known bugs. That means that as of the final 2.4.0-test9 I will > no longer accept any patches that don't have a critical problem > (as defined by Teds list) associated with them. > > So when you send me a patch, either bug Ted to mark the issue as > "critical" first, or pay me money. It's that easy. Hmm, the new VM doesn't have the out of memory killer integrated yet. I'll do some out of memory / low on swap work and will send you the patch soon, dependant on how connected I will be during Linux Kongress... Good thing I promised Ted to bring another bottle of that Brazillian liquor to the next event we meet ;) 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: Linux-2.4.0-test9-pre2
> bugs. That means that as of the final 2.4.0-test9 I will no longer accept > any patches that don't have a critical problem (as defined by Teds list) > associated with them. Argh. Im not going to have time to push all the driver fixes from 2.2 into 2.4 then, I've got a house move to do yet - 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.4.0-test9-pre2
On Sun, 17 Sep 2000, Linus Torvalds wrote: Ok. I think we're getting to the point where there are no major known bugs. That means that as of the final 2.4.0-test9 I will no longer accept any patches that don't have a critical problem (as defined by Teds list) associated with them. So when you send me a patch, either bug Ted to mark the issue as "critical" first, or pay me money. It's that easy. Hmm, the new VM doesn't have the out of memory killer integrated yet. I'll do some out of memory / low on swap work and will send you the patch soon, dependant on how connected I will be during Linux Kongress... Good thing I promised Ted to bring another bottle of that Brazillian liquor to the next event we meet ;) 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: Linux-2.4.0-test9-pre2
On Mon, 18 Sep 2000, Chris Wedgwood wrote: On Sun, Sep 17, 2000 at 10:37:51AM -0700, Linus Torvalds wrote: - "extern inline" - "static inline". It doesn't matter right now, but it's proactive for future gcc versions. can someone please explain the difference? Let's assume that gcc decides that it won't inline a function, because it's too "big", according to some gcc definition of "big". With "extern inline", the function will not exist AT ALL, and you'll end up getting a link-time error complaining about the lack of that function. With "static inline", gcc will emit the function as a separate function for that compilation block if it didn't get inlined. Both are valid things. You use "extern inline" when you have a "backing store" for the funcion (ie you do have the non-inlined version in a library somewhere). You use "static inline" when you don't. For the kernel, we very seldom have the non-inlined versions in any library, so for the kernel "extern inline" is almost always the wrong thing. Note that with most versions of gcc this is all a complete non-issue, as most versions of gcc will _always_ inline a function that the user has asked to be inlined. So the issue seldom actually comes up. Linus - 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.4.0-test9-pre2 - still CardBus problems
Linus Torvalds wrote: Ok. I think we're getting to the point where there are no major known bugs. That means that as of the final 2.4.0-test9 I will no longer accept any patches that don't have a critical problem (as defined by Teds list) associated with them. [snip] - PCI bridge scanning fix: assign numbers properly [snip] Don't know if this was intended to fix the CardBus problem on certain DELL (others?) laptops. It doesn't work on mine, anyway. I do get a slightly more informative error message though... And my CardBus is now bus #6 and not #4 as it was with test8. If that makes a difference. I have enbled some debugging in the output below. All pcmcia/cardbus stuff is built as modules. Using the native kernel bits only. (It is no better with the standalone package from David Hinds.) Linux version 2.4.0-test9 (root@dagblap) (gcc version 2.95.2 19991024 (release)) #4 Sun Sep 17 22:31:09 CE ST 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 05ef @ 0010 (usable) BIOS-e820: 0001 @ 05ff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 24560 zone(0): 4096 pages. zone(1): 20464 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=test9p2d ro root=/dev/discs/disc0/part5 Initializing CPU#0 Detected 363965751 Hz processor. Console: colour dummy device 80x25 Calibrating delay loop... 725.81 BogoMIPS Memory: 94180k/98240k available (1497k kernel code, 3672k reserved, 104k data, 196k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) CPU: Intel Mobile Pentium II stepping 0a Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: BIOS32 Service Directory structure at 0xc00ffe80 PCI: BIOS32 Service Directory entry at 0xffe90 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=01 PCI: PCI BIOS revision 2.10 entry at 0xfc0ee, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: IDE base address fixup for 00:07.1 PCI: Scanning for ghost devices on bus 0 PCI: Scanning for ghost devices on bus 1 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbda0 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource f400-f7ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource ec80-ecbf (f=101, d=0, p=0) PCI: Resource fb00-fbff (f=1208, d=0, p=0) PCI: Resource fdc0-fdff (f=200, d=0, p=0) PCI: Resource fdb0-fdbf (f=200, d=0, p=0) PCI: Resource fac0-faff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) PCI: Sorting device list... Limiting direct PCI/PCI transfers. [snip] # lsmod Module Size Used by # modprobe yenta_socket # lsmod Module Size Used by yenta_socket9836 2 pcmcia_core43840 0 [yenta_socket] # dmesg [snip] Linux PCMCIA Card Services 3.1.20 options: [pci] [cardbus] [pm] cs.c 1.267 2000/08/30 22:07:31 (David Hinds) Yenta IRQ list 0098, PCI irq11 Socket status: 3006 cs: pcmcia_register_socket(0xc6a7a280) Yenta IRQ list 0098, PCI irq11 Socket status: 3020 cs: pcmcia_register_socket(0xc6a7a280) # modprobe ds # dmesg [snip] ds.c 1.108 2000/08/07 19:06:15 (David Hinds) cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003 PCI: Failed to allocate resource 0 for PCI device 115d:0003 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: Device 06:00.0 not available because of resource collisions PCI: Failed to allocate resource 0 for PCI device 115d:0103 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: Device 06:00.1 not available because of resource collisions # lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 00:03.0 CardBus bridge: Texas Instruments PCI1225 (rev
Re: Linux-2.4.0-test9-pre2
On Sun, 17 Sep 2000, Alan Cox wrote: bugs. That means that as of the final 2.4.0-test9 I will no longer accept any patches that don't have a critical problem (as defined by Teds list) associated with them. Argh. Im not going to have time to push all the driver fixes from 2.2 into 2.4 then, I've got a house move to do yet Alan, 'it happens that is why most distros will not ship a 2.4.0 kernel and will wait for 2.4.1 or 2.4.2. Cheers, Andre Hedrick The Linux ATA/IDE guy - 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/
