RE: How to optimize routing performance
> > Or are you saying that the bottleneck is somewhere > > else completely, > > Indeed. The bottleneck is with processing the incoming network > packets, at the interrupt level. Where is the counter for these dropped packets? If we run a few mbit of traffic through the box, we see noticeble percentages of lost packets (via stats from the Ixia traffic generator). But where in Linux are these counts stored? ifconfig does not appear to have the #. Cheers! Jon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: How to optimize routing performance
Or are you saying that the bottleneck is somewhere else completely, Indeed. The bottleneck is with processing the incoming network packets, at the interrupt level. Where is the counter for these dropped packets? If we run a few mbit of traffic through the box, we see noticeble percentages of lost packets (via stats from the Ixia traffic generator). But where in Linux are these counts stored? ifconfig does not appear to have the #. Cheers! Jon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [UPDATE] Fresh zerocopy patch on kernel.org
> Malcolm Beattie writes: > > Alexey has mailed me suggesting the problem may be that netfilter > > is turned on. > > Oh yes, netfilter being enabled will cause some performance > degradation, that is for sure. Do you think that netfilter being enabled would also cause a decrease in routing throughput (ie: causing packet loss)? Cheers! Jon - 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: [UPDATE] Fresh zerocopy patch on kernel.org
Malcolm Beattie writes: Alexey has mailed me suggesting the problem may be that netfilter is turned on. Oh yes, netfilter being enabled will cause some performance degradation, that is for sure. Do you think that netfilter being enabled would also cause a decrease in routing throughput (ie: causing packet loss)? Cheers! Jon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] doc update/fixes for sysrq.txt
> On Sun, 28 Jan 2001 11:35:50 +, David Ford wrote: > > AFAIK, this hasn't ever been true. I have never had to specifically > > enable it at run time. > > I was suspicious of that in the old doc but thought I'd leave it in... > Should have asked for feedback on it, but you caught it > anyway, thanks! > > Here's a patch against the first that simply removes the lines. I'd suggest leaving those lines in; I've never had it enabled by default. I've run Debian and Redhat systems, and both had to have the option specifically turned ON via startup script - simply compiling it into a kernel did not enable it. Jon - 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: CBQ simply doesn't work
Hi, /sbin/insmod cls__u32 insmod: cls__u32: no module by that name found I think you meant cls_u32, not cls__u32. Your script output seems to indicate that you've already got the modules loaded somewhere. tc class add dev ppp0 parent 10:1 classid 10:300 cbq bandwidth 28Kbit rate 3Kbit allot 1514 weight 3Kbit prio 5 maxburst 20 avpkt 1000 To get a 3kbit flow, you need the 'bounded' keyword in that line. Without it, it will borrow all available bandwidth. Further, you didn't appear to include your filter definitions in your script. If the bounded keyword doesn't fix it, check what you are matching in your filters. Packets not matching will sail right between your queues without a care in the world. Jon > I can't get the CBQ running on 2.2.17. Alexey look like he > doesn't reply to his > mails. I made one more man to check it over me. We both > can't find a problem. > The file with config info is attached. > > Eager for any idea > > Clock > > - 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: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
> Throughput: 100Mbps is really nothing. Linux never had a problem with > 4-500Mbps file serving. So throughput is an important number. so is > end to end latency, but in file serving case, latency might > not be a big deal so ignore it. If I try to route more than 40mbps (40% line utilization) through a 100mbps port (tulip) on a 2.4.0-test kernel running on a pIII 500 (or higher) system, not only does the performance drop to nearly 0, the system gets all sluggish and unusable. This is with or without Jamal's FF patches. How are you managing to get such high throughput? Jon - 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: CBQ simply doesn't work
Hi, /sbin/insmod cls__u32 insmod: cls__u32: no module by that name found I think you meant cls_u32, not cls__u32. Your script output seems to indicate that you've already got the modules loaded somewhere. tc class add dev ppp0 parent 10:1 classid 10:300 cbq bandwidth 28Kbit rate 3Kbit allot 1514 weight 3Kbit prio 5 maxburst 20 avpkt 1000 To get a 3kbit flow, you need the 'bounded' keyword in that line. Without it, it will borrow all available bandwidth. Further, you didn't appear to include your filter definitions in your script. If the bounded keyword doesn't fix it, check what you are matching in your filters. Packets not matching will sail right between your queues without a care in the world. Jon I can't get the CBQ running on 2.2.17. Alexey look like he doesn't reply to his mails. I made one more man to check it over me. We both can't find a problem. The file with config info is attached. Eager for any idea Clock - 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: sendfile+zerocopy: fairly sexy (nothing to do with ECN)
Throughput: 100Mbps is really nothing. Linux never had a problem with 4-500Mbps file serving. So throughput is an important number. so is end to end latency, but in file serving case, latency might not be a big deal so ignore it. If I try to route more than 40mbps (40% line utilization) through a 100mbps port (tulip) on a 2.4.0-test kernel running on a pIII 500 (or higher) system, not only does the performance drop to nearly 0, the system gets all sluggish and unusable. This is with or without Jamal's FF patches. How are you managing to get such high throughput? Jon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] doc update/fixes for sysrq.txt
On Sun, 28 Jan 2001 11:35:50 +, David Ford wrote: AFAIK, this hasn't ever been true. I have never had to specifically enable it at run time. I was suspicious of that in the old doc but thought I'd leave it in... Should have asked for feedback on it, but you caught it anyway, thanks! Here's a patch against the first that simply removes the lines. I'd suggest leaving those lines in; I've never had it enabled by default. I've run Debian and Redhat systems, and both had to have the option specifically turned ON via startup script - simply compiling it into a kernel did not enable it. Jon - 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: [UPDATE] Zerocopy patches, against 2.4.1-pre10
> > What are "zerocopy patch set"s? > > Basically, if you want to send something to the network, the > kernel has to > copy your data to its memory space. It is an overhead and with these > patches, the kernel doesn't has to do it. So it is faster. > Moreover, few > ethernet cards are able to compute the ip checksum so linux > doesn't need > anymore to do that. Hmm.. so things like routing should be faster then? What caveats should one watch for (ie: what functionalities will not work as before - if any)? Cheers! Jon - 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: [UPDATE] Zerocopy patches, against 2.4.1-pre10
> I'm back from OZ, and to help deal with my sudden lack of Victoria > Bitter, I've made a new zerocopy patch set. What are "zerocopy patch set"s? Cheers! Jon - 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: [UPDATE] Zerocopy patches, against 2.4.1-pre10
What are "zerocopy patch set"s? Basically, if you want to send something to the network, the kernel has to copy your data to its memory space. It is an overhead and with these patches, the kernel doesn't has to do it. So it is faster. Moreover, few ethernet cards are able to compute the ip checksum so linux doesn't need anymore to do that. Hmm.. so things like routing should be faster then? What caveats should one watch for (ie: what functionalities will not work as before - if any)? Cheers! Jon - 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: [UPDATE] Zerocopy patches, against 2.4.1-pre10
I'm back from OZ, and to help deal with my sudden lack of Victoria Bitter, I've made a new zerocopy patch set. What are "zerocopy patch set"s? Cheers! Jon - 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: [OT?] Coding Style
That's just nasty! Funny, but nasty. :) Jon > -Original Message- > From: Stephen Satchell [mailto:[EMAIL PROTECTED]] > It took a while to prepare the source for this jerk. Here is > what I did to > the source I gave the 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: [OT?] Coding Style
Title: RE: [OT?] Coding Style I prefer descriptive variable and function names - like comments, they help to make code so much easier to read. One thing I wonder though... why do people prefer 'some_function_name()' over 'SomeFunctionName()'? I personally don't like the underscore character - it's an odd character to type when you're trying to get the name typed in, and the shifted character, I find, is easier to input. Cheers! Jon > -Original Message- > From: Steve Underwood [mailto:[EMAIL PROTECTED]] Some people still seem to be living in the age of K C, with 6 or 7 character variable names that demand some explanation. Maybe some day they will awake to the expressive power of long (and well chosen) names.
RE: 2.4.1-test10
> -Original Message- > From: Jeff Garzik [mailto:[EMAIL PROTECTED]] > > Do the tulip driver updates address the increasingly common > NETDEV timeout > > repots? > > I don't see increasingly common timeout reports.. with which > hardware? > They are likely on the newer LinkSys 4.1 cards, and there are still > problesm with PNIC. Outside of that, other cards should be ok. Hi Jeff, Have you looked at the packet loss issue on the Znyx 4port cards? Even using the latest tulip driver, packet loss is still apparent with moderate loads. Cheers! Jon - 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: Coding Style
> -Original Message-
> From: adrian
>
> On Mon, 22 Jan 2001, Mark I Manning IV wrote:
>
> > It is alot neater tho :P~
> >
> > // even for multi line comments
> > // no visual clutter over there -->
>
> /*
> * I tend to find standard C comments easier to read. They stand out,
> * especially for multiple lines (although I always try to put the :end:
> * on a separate line for clarity).
> */
I like this style for multiple line comments, but prefer the '//' for single
liners. Two less characters to type after all. :)
> int function(int x)
> {
> /* Bleh. Comments take up space.
>*/
> function body;
> }
int function(int x) {
// I like comments. 'Sides, what else would you use the space for?
function body;
}
Cheers!
Jon
-
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: Coding Style
-Original Message-
From: adrian
On Mon, 22 Jan 2001, Mark I Manning IV wrote:
It is alot neater tho :P~
// even for multi line comments
// no visual clutter over there --
/*
* I tend to find standard C comments easier to read. They stand out,
* especially for multiple lines (although I always try to put the :end:
* on a separate line for clarity).
*/
I like this style for multiple line comments, but prefer the '//' for single
liners. Two less characters to type after all. :)
int function(int x)
{
/* Bleh. Comments take up space.
*/
function body;
}
int function(int x) {
// I like comments. 'Sides, what else would you use the space for?
function body;
}
Cheers!
Jon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.1-test10
-Original Message- From: Jeff Garzik [mailto:[EMAIL PROTECTED]] Do the tulip driver updates address the increasingly common NETDEV timeout repots? I don't see increasingly common timeout reports.. with which hardware? They are likely on the newer LinkSys 4.1 cards, and there are still problesm with PNIC. Outside of that, other cards should be ok. Hi Jeff, Have you looked at the packet loss issue on the Znyx 4port cards? Even using the latest tulip driver, packet loss is still apparent with moderate loads. Cheers! Jon - 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: [OT?] Coding Style
Title: RE: [OT?] Coding Style I prefer descriptive variable and function names - like comments, they help to make code so much easier to read. One thing I wonder though... why do people prefer 'some_function_name()' over 'SomeFunctionName()'? I personally don't like the underscore character - it's an odd character to type when you're trying to get the name typed in, and the shifted character, I find, is easier to input. Cheers! Jon -Original Message- From: Steve Underwood [mailto:[EMAIL PROTECTED]] Some people still seem to be living in the age of KR C, with 6 or 7 character variable names that demand some explanation. Maybe some day they will awake to the expressive power of long (and well chosen) names.
RE: [OT?] Coding Style
That's just nasty! Funny, but nasty. :) Jon -Original Message- From: Stephen Satchell [mailto:[EMAIL PROTECTED]] It took a while to prepare the source for this jerk. Here is what I did to the source I gave the 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: [OT?] Coding Style
> -Original Message- > From: Larry McVoy [mailto:[EMAIL PROTECTED]] > > On Mon, Jan 22, 2001 at 11:04:50AM -0500, Jonathan Earle wrote: > > > -Original Message- > > > From: profmakx.fmp [mailto:[EMAIL PROTECTED]] > > > > > > So, every good programmer > > > should know where to put comments. And it is unnecessary to > > > put comments to > > > explain what code does. One should see this as stated in the > > > CodingStyle doc. > > > Ok, there are points where a comment is good, but for example > > > at university > > > we are to comment on every single line of code ... > > > > WRONG!!! > > > > Not documenting your code is not a sign of good coding, but > rather shows > > arrogance, laziness and contempt for "those who would dare > tamper with your > > code after you've written it". Document and comment your > code thoroughly. > > Do it as you go along. I was also taught to comment nearly > every line - as > > part of the coding style used by a large, international > company I worked for > > several years ago. It brings the logic of the programmer > into focus and > > makes code maintenance a whole lot easier. It also helps > one to remember > > the logic of your own code when you revisit it a year or more hence. > > Please don't listen to this. The only place you really want > comments is > > a) at the top of files, describing the point of the file; > b) at the top of functions, if the purpose of the > function is not obvious; > c) in line, when the code is not obvious. > > If you are writing code that requires a comment for every > line, you are > writing bad, obscure, unobvious code and no amount of > commenting will fix > it. The point of comments is not to "fix" bad code, it's to provide understanding. As the original poster said, _you_ may understand your code, but that in no way implies that _I_ will, or your co-worker down the hall will, etc. I'm not suggesting that a statement like "counter=0;" at the start of a function be commented, but other operations should be. "Why do we want this file written in /proc - wouldn't syslog have worked better?" "Why is this loop skipping the first seven elements?" "Why is this structure used here instead of a simple array?" "What on earth does m->n->o->num represent?" > The real reason to sparing in your comments is that code and > comments are > not semantically bound to each other: the program doesn't > stop working when > the comment becomes incorrect. It's incredibly frustrating > to read a comment, > believe you understand what is going on, only to find out > that the comment > and the code no longer match. Comments should be updated when code is updated. I believe that documentation is of far greater value than code itself. Code can be changed, however, logic drives the code. Without a good understanding of the latter, the former is of little value, IMHO. Cheers! Jon - 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: [OT?] Coding Style
> -Original Message- > From: profmakx.fmp [mailto:[EMAIL PROTECTED]] > > So, every good programmer > should know where to put comments. And it is unnecessary to > put comments to > explain what code does. One should see this as stated in the > CodingStyle doc. > Ok, there are points where a comment is good, but for example > at university > we are to comment on every single line of code ... WRONG!!! Not documenting your code is not a sign of good coding, but rather shows arrogance, laziness and contempt for "those who would dare tamper with your code after you've written it". Document and comment your code thoroughly. Do it as you go along. I was also taught to comment nearly every line - as part of the coding style used by a large, international company I worked for several years ago. It brings the logic of the programmer into focus and makes code maintenance a whole lot easier. It also helps one to remember the logic of your own code when you revisit it a year or more hence. Jon - 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: [OT?] Coding Style
-Original Message- From: profmakx.fmp [mailto:[EMAIL PROTECTED]] So, every good programmer should know where to put comments. And it is unnecessary to put comments to explain what code does. One should see this as stated in the CodingStyle doc. Ok, there are points where a comment is good, but for example at university we are to comment on every single line of code ... WRONG!!! Not documenting your code is not a sign of good coding, but rather shows arrogance, laziness and contempt for "those who would dare tamper with your code after you've written it". Document and comment your code thoroughly. Do it as you go along. I was also taught to comment nearly every line - as part of the coding style used by a large, international company I worked for several years ago. It brings the logic of the programmer into focus and makes code maintenance a whole lot easier. It also helps one to remember the logic of your own code when you revisit it a year or more hence. Jon - 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: [OT?] Coding Style
-Original Message- From: Larry McVoy [mailto:[EMAIL PROTECTED]] On Mon, Jan 22, 2001 at 11:04:50AM -0500, Jonathan Earle wrote: -Original Message- From: profmakx.fmp [mailto:[EMAIL PROTECTED]] So, every good programmer should know where to put comments. And it is unnecessary to put comments to explain what code does. One should see this as stated in the CodingStyle doc. Ok, there are points where a comment is good, but for example at university we are to comment on every single line of code ... WRONG!!! Not documenting your code is not a sign of good coding, but rather shows arrogance, laziness and contempt for "those who would dare tamper with your code after you've written it". Document and comment your code thoroughly. Do it as you go along. I was also taught to comment nearly every line - as part of the coding style used by a large, international company I worked for several years ago. It brings the logic of the programmer into focus and makes code maintenance a whole lot easier. It also helps one to remember the logic of your own code when you revisit it a year or more hence. Please don't listen to this. The only place you really want comments is a) at the top of files, describing the point of the file; b) at the top of functions, if the purpose of the function is not obvious; c) in line, when the code is not obvious. If you are writing code that requires a comment for every line, you are writing bad, obscure, unobvious code and no amount of commenting will fix it. The point of comments is not to "fix" bad code, it's to provide understanding. As the original poster said, _you_ may understand your code, but that in no way implies that _I_ will, or your co-worker down the hall will, etc. I'm not suggesting that a statement like "counter=0;" at the start of a function be commented, but other operations should be. "Why do we want this file written in /proc - wouldn't syslog have worked better?" "Why is this loop skipping the first seven elements?" "Why is this structure used here instead of a simple array?" "What on earth does m-n-o-num represent?" The real reason to sparing in your comments is that code and comments are not semantically bound to each other: the program doesn't stop working when the comment becomes incorrect. It's incredibly frustrating to read a comment, believe you understand what is going on, only to find out that the comment and the code no longer match. Comments should be updated when code is updated. I believe that documentation is of far greater value than code itself. Code can be changed, however, logic drives the code. Without a good understanding of the latter, the former is of little value, IMHO. Cheers! Jon - 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/
Ethernet Bonding Performance under kernel 2.4.0
Hi all, I've a system comprosed of two PIII machines, equipped with Znyx 346Q 4port ethernet cards (tulip driver) which I'd like to connect together in a bonded configuration. For various reasons, we require 2.4.0 kernels on our machines - currently we are using 2.4.0-test9. The setup is simple: each port on a 346Q in one machine is connected to the corresponding port on the 346Q in the other machine via a crossover cable. +---+ +---+ | |--| | -| Box A |--| Box B |- | |--| | | |--| | +---+ +---+ Problem #1 -- Initally, after bootup, the performance of each of the four networks between the two PCs is subpar. Transfer rates will vary from a few hundred KB/s to perhaps a few MB/s, and the transfer time is appreciably long. This, on a forced 100TX-FD link. After a few minutes however, things appear to settle down, and I can achieve 11.2MB/s when transferring a large binary file via ftp (rate as reported by ncftp). The de4x5 driver shows the same behaviour. Problem #2 -- I built the bonding driver, and using a copy of ifenslave.c which I found for kernel 2.3.50, I was able to make a bonded channel. The trouble I found is that the performance was not at all what I expected. Using the first eth port, I achieved a throughput (FTP transfer of a large binary file) of 10.4 MB/s (11.2MB/s if set to full duplex). Using 2 ports, the performance dropped to about 3.5MB/s. Adding a third port brings the throughput to about 5.2MB/s and adding the fourth port only takes it up to 5.75MB/s. The de4x5 driver shows the same drop in performance as the tulip driver. Using the TEQL (trivial link equalizer) (instructions from the Adv-routing howto) provides the same measurements exactly. Thoughts? Cheers! Jon - 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/
Ethernet Bonding Performance under kernel 2.4.0
Hi all, I've a system comprosed of two PIII machines, equipped with Znyx 346Q 4port ethernet cards (tulip driver) which I'd like to connect together in a bonded configuration. For various reasons, we require 2.4.0 kernels on our machines - currently we are using 2.4.0-test9. The setup is simple: each port on a 346Q in one machine is connected to the corresponding port on the 346Q in the other machine via a crossover cable. +---+ +---+ | |--| | -| Box A |--| Box B |- | |--| | | |--| | +---+ +---+ Problem #1 -- Initally, after bootup, the performance of each of the four networks between the two PCs is subpar. Transfer rates will vary from a few hundred KB/s to perhaps a few MB/s, and the transfer time is appreciably long. This, on a forced 100TX-FD link. After a few minutes however, things appear to settle down, and I can achieve 11.2MB/s when transferring a large binary file via ftp (rate as reported by ncftp). The de4x5 driver shows the same behaviour. Problem #2 -- I built the bonding driver, and using a copy of ifenslave.c which I found for kernel 2.3.50, I was able to make a bonded channel. The trouble I found is that the performance was not at all what I expected. Using the first eth port, I achieved a throughput (FTP transfer of a large binary file) of 10.4 MB/s (11.2MB/s if set to full duplex). Using 2 ports, the performance dropped to about 3.5MB/s. Adding a third port brings the throughput to about 5.2MB/s and adding the fourth port only takes it up to 5.75MB/s. The de4x5 driver shows the same drop in performance as the tulip driver. Using the TEQL (trivial link equalizer) (instructions from the Adv-routing howto) provides the same measurements exactly. Thoughts? Cheers! Jon - 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/
Porting network driver to 2.4.0
Hey all, Still working with kernel 2.4.0-test9 (other things we use require it for now), and I was looking at a driver for a Znyx zx346q network card that I grabbed from the znyx.com website. The driver is for a 2.2.x kernel, but figuring I'd try it anyway, downloaded and tried to build it. It choked on three struct net_device entries which are no longer present: zxe.c:1200: structure has no member named `tbusy' zxe.c:1201: structure has no member named `interrupt' zxe.c:1202: structure has no member named `start' ... make[2]: *** [zxe.o] Error 1 Where do I go from here? Is there info somewhere to help with this? Is this a bigger job than it looks on the surface? Cheers! Jon - 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/
Porting network driver to 2.4.0
Hey all, Still working with kernel 2.4.0-test9 (other things we use require it for now), and I was looking at a driver for a Znyx zx346q network card that I grabbed from the znyx.com website. The driver is for a 2.2.x kernel, but figuring I'd try it anyway, downloaded and tried to build it. It choked on three struct net_device entries which are no longer present: zxe.c:1200: structure has no member named `tbusy' zxe.c:1201: structure has no member named `interrupt' zxe.c:1202: structure has no member named `start' ... make[2]: *** [zxe.o] Error 1 Where do I go from here? Is there info somewhere to help with this? Is this a bigger job than it looks on the surface? Cheers! Jon - 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: Kernel oops in mm/slab.c [ kmem_cache_grow() ] with test4-8
Title: RE: Kernel oops in mm/slab.c [ kmem_cache_grow() ] with test4-8 > -Original Message- > From: Andrew Morton [mailto:[EMAIL PROTECTED]] > Sent: Friday, September 15, 2000 11:47 PM > To: Earle, Jonathan [KAN:1A31:EXCH] > Cc: Linux MPLS List (E-mail); Linux Kernel List (E-mail) > Subject: Re: Kernel oops in mm/slab.c [ kmem_cache_grow() ] > with test4-8 > > > > Jonathan Earle wrote: > > > > Hi, > > > > I've been having kernel oopses with the 2.4.0-test series and am > > including ksymoops processed output from both test4 and test5 > > kernels. The same oops happens in later kernels too (Tested with > > test6, test7 and test8). > > > > Presumably mpls_output() is doing a kmalloc(..., GFP_KERNEL) > from within > a softirq. Hunt that down and turn it into GFP_ATOMIC. Okay... Did that (turned all the GFP_KERNEL refereces in net/mpls to GFP_ATOMIC, and the problem seems to have gone away, I'll post a more confident summary when I'm more sure that things are working properly. Now, what did I do (aside from fixing the problem) by changing that reference? Many thanks for the hint!! Jon
RE: Kernel oops in mm/slab.c [ kmem_cache_grow() ] with test4-8
Title: RE: Kernel oops in mm/slab.c [ kmem_cache_grow() ] with test4-8 -Original Message- From: Andrew Morton [mailto:[EMAIL PROTECTED]] Sent: Friday, September 15, 2000 11:47 PM To: Earle, Jonathan [KAN:1A31:EXCH] Cc: Linux MPLS List (E-mail); Linux Kernel List (E-mail) Subject: Re: Kernel oops in mm/slab.c [ kmem_cache_grow() ] with test4-8 Jonathan Earle wrote: Hi, I've been having kernel oopses with the 2.4.0-test series and am including ksymoops processed output from both test4 and test5 kernels. The same oops happens in later kernels too (Tested with test6, test7 and test8). Presumably mpls_output() is doing a kmalloc(..., GFP_KERNEL) from within a softirq. Hunt that down and turn it into GFP_ATOMIC. Okay... Did that (turned all the GFP_KERNEL refereces in net/mpls to GFP_ATOMIC, and the problem seems to have gone away, I'll post a more confident summary when I'm more sure that things are working properly. Now, what did I do (aside from fixing the problem) by changing that reference? Many thanks for the hint!! Jon
Kernel oops in mm/slab.c [ kmem_cache_grow() ] with test4-8
Title: Kernel oops in mm/slab.c [ kmem_cache_grow() ] with test4-8 Hi, I've been having kernel oopses with the 2.4.0-test series and am including ksymoops processed output from both test4 and test5 kernels. The same oops happens in later kernels too (Tested with test6, test7 and test8). The scenario is this: I have an incoming UDP stream at 1mbit. The router marks packets in this stream, according to port ranges, with 3 (or any # of) marks (via iptables v1.1.1). iproute2 builds new routing tables based on these marks, and mplsadm, with the tc patch, is called to build LSPs using these routing tables. Finally, the 3 egress LSPs are rate limited using tc (employing cbq classes) to a value less than the ingress rate (ie: I limited each LSP to 200kbit, for an aggregate egress output rate of 600kbit). When I start the traffic flowing from our generator, the box panics and freezes quite solidly. Policing via filters also crashes the box. If I move the egress rate limiting function to another box, it works okay. I've also noted that the crash only occurs if I throttle the traffic flow to an egress rate which is less than the ingress rate (ie: ingress flow at 1mbit and egress flow at 1mbit works fine. If the egress rate is reduced, boom!) I copied down the oopses and ran 'ksymoops < oops.txt > oops_proc.txt' and pasted them here. The first is from kernel 2.4.0-test4 and the second from 2.4.0-test5. NEW: Here's the funny part. In mm/slab.c, the function kmem_cache_grow() contains a check as follows: /* * The test for missing atomic flag is performed here, rather than * the more obvious place, simply to reduce the critical path length * in kmem_cache_alloc(). If a caller is seriously mis-behaving they * will eventually be caught here (where it matters). */ /* Commented out Sep 15 since it was crashing my router. */ /* if (in_interrupt() && (flags & SLAB_LEVEL_MASK) != SLAB_ATOMIC) BUG(); */ This is the check that fails and causes the oops. Not understanding what is actually being checked, and not knowing the repercussions of tampering with it, I commented out the check, recompiled and reran the test. I understand that this is not really a fix (it's more akin to just turning my head and pretending that the problem doesn't exist, but... it seems to work.) The result: Great joy and much celebration! I'm throwing 7.2mbps at the box, limiting the rate to 900kbit aggregate throughput and it's working! The numbers I'm getting also seem to jive with anticipated results. Cheers! Jon ksymoops 0.7c on i686 2.4.0-test4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test4/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. invalid operand: CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 001b ebx: c7ffd0c0 ecx: edx: 0082 esi: 0246 edi: c7ffd0c0 ebp: 0007 esp: c024fe70 ds: 0018 es: 0018 ss: 0018 Process swapper (pid:0, stackpage=c024f000) Stack: c01fb794 c01fb834 0412 c7ffd0c0 0247 0007 c024fed4 c7d1602e c0127aaf c7ffd0c0 0007 c7d170e0 c7d1602e c01eb196 0008 0007 c7d170e0 c7d1602e c7f8be00 c01b6aaf c7d170e0 Call trace: [][][][][][][] [][][][][][][][] [][][][][][][][] Code: 0f 0b 83 c4 0c c7 44 24 10 01 00 00 00 89 ee 83 e6 07 b8 03 >>EIP; c01277fd <= Trace; c01fb794 Trace; c01fb834 Trace; c0127aaf Trace; c01eb196 Trace; c01b6aaf Trace; c01b6c6f Trace; c01b6a84 Trace; c019b1c4 Trace; c01b6936 Trace; c01b6a84 Trace; c019efe3 Trace; c011b17f Trace; c010b8ee Trace; c01087e0 Trace; c01087e0 Trace; c010a518 Trace; c01087e0 Trace; c01087e0 Trace; c0100018 Trace; c0108803 Trace; c0108864 Trace; c0105000 Trace; c0100192 Code; c01277fd <_EIP>: Code; c01277fd <= 0: 0f 0b ud2a <= Code; c01277ff 2: 83 c4 0c add $0xc,%esp Code; c0127802 5: c7 44 24 10 01 00 00 movl $0x1,0x10(%esp,1) Code; c0127809 c: 00 Code; c012780a d: 89 ee mov %ebp,%esi Code; c012780c f: 83 e6 07 and $0x7,%esi Code; c012780f 12: b8 03 00 00 00 mov $0x3,%eax Aiee, killing interrupt handler Kernel panic: Attempted to kill the
Kernel oops in mm/slab.c [ kmem_cache_grow() ] with test4-8
Title: Kernel oops in mm/slab.c [ kmem_cache_grow() ] with test4-8 Hi, I've been having kernel oopses with the 2.4.0-test series and am including ksymoops processed output from both test4 and test5 kernels. The same oops happens in later kernels too (Tested with test6, test7 and test8). The scenario is this: I have an incoming UDP stream at 1mbit. The router marks packets in this stream, according to port ranges, with 3 (or any # of) marks (via iptables v1.1.1). iproute2 builds new routing tables based on these marks, and mplsadm, with the tc patch, is called to build LSPs using these routing tables. Finally, the 3 egress LSPs are rate limited using tc (employing cbq classes) to a value less than the ingress rate (ie: I limited each LSP to 200kbit, for an aggregate egress output rate of 600kbit). When I start the traffic flowing from our generator, the box panics and freezes quite solidly. Policing via filters also crashes the box. If I move the egress rate limiting function to another box, it works okay. I've also noted that the crash only occurs if I throttle the traffic flow to an egress rate which is less than the ingress rate (ie: ingress flow at 1mbit and egress flow at 1mbit works fine. If the egress rate is reduced, boom!) I copied down the oopses and ran 'ksymoops oops.txt oops_proc.txt' and pasted them here. The first is from kernel 2.4.0-test4 and the second from 2.4.0-test5. NEW: Here's the funny part. In mm/slab.c, the function kmem_cache_grow() contains a check as follows: /* * The test for missing atomic flag is performed here, rather than * the more obvious place, simply to reduce the critical path length * in kmem_cache_alloc(). If a caller is seriously mis-behaving they * will eventually be caught here (where it matters). */ /* Commented out Sep 15 since it was crashing my router. */ /* if (in_interrupt() (flags SLAB_LEVEL_MASK) != SLAB_ATOMIC) BUG(); */ This is the check that fails and causes the oops. Not understanding what is actually being checked, and not knowing the repercussions of tampering with it, I commented out the check, recompiled and reran the test. I understand that this is not really a fix (it's more akin to just turning my head and pretending that the problem doesn't exist, but... it seems to work.) The result: Great joy and much celebration! I'm throwing 7.2mbps at the box, limiting the rate to 900kbit aggregate throughput and it's working! The numbers I'm getting also seem to jive with anticipated results. Cheers! Jon ksymoops 0.7c on i686 2.4.0-test4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test4/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. invalid operand: CPU: 0 EIP: 0010:[c01277fd] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 001b ebx: c7ffd0c0 ecx: edx: 0082 esi: 0246 edi: c7ffd0c0 ebp: 0007 esp: c024fe70 ds: 0018 es: 0018 ss: 0018 Process swapper (pid:0, stackpage=c024f000) Stack: c01fb794 c01fb834 0412 c7ffd0c0 0247 0007 c024fed4 c7d1602e c0127aaf c7ffd0c0 0007 c7d170e0 c7d1602e c01eb196 0008 0007 c7d170e0 c7d1602e c7f8be00 c01b6aaf c7d170e0 Call trace: [c01fb794][c01fb834][c0127aaf][c01eb196][c01b6aaf][c01b6c6f][c01b6a84] [c019b1c4][c01b6936][c01b6a84][c019efe3][c011b17f][c010b8ee][c01087e0][c01087e0] [c010a518][c01087e0][c01087e0][c0100018][c0108803][c0108864][c0105000][c0100192] Code: 0f 0b 83 c4 0c c7 44 24 10 01 00 00 00 89 ee 83 e6 07 b8 03 EIP; c01277fd kmem_cache_grow+69/254 = Trace; c01fb794 tvecs+1500/14d4c Trace; c01fb834 tvecs+15a0/14d4c Trace; c0127aaf kmalloc+73/ac Trace; c01eb196 mpls_output+12/26c Trace; c01b6aaf ip_rcv_finish+2b/21c Trace; c01b6c6f ip_rcv_finish+1eb/21c Trace; c01b6a84 ip_rcv_finish+0/21c Trace; c019b1c4 nf_hook_slow+7c/b4 Trace; c01b6936 ip_rcv+356/38c Trace; c01b6a84 ip_rcv_finish+0/21c Trace; c019efe3 net_rx_action+123/1e8 Trace; c011b17f do_softirq+4f/70 Trace; c010b8ee do_IRQ+a6/b8 Trace; c01087e0 default_idle+0/28 Trace; c01087e0 default_idle+0/28 Trace; c010a518 ret_from_intr+0/20 Trace; c01087e0 default_idle+0/28 Trace; c01087e0 default_idle+0/28 Trace; c0100018 startup_32+18/13a Trace; c0108803 default_idle+23/28 Trace; c0108864 cpu_idle+3c/50 Trace; c0105000 empty_bad_page+0/1000 Trace; c0100192 L6+0/2 Code; c01277fd kmem_cache_grow+69/254 _EIP: Code; c01277fd kmem_cache_grow+69/254 = 0: 0f 0b ud2a = Code; c01277ff
Kernel oops on 2.4.0-test4 and test5 (and later): kmem_cache_grow
ce; c01b511f Trace; c0199a8c Trace; c01b4de9 Trace; c01b4f3c Trace; c019d833 Trace; c011ad5f Trace; c010b84e Trace; c01087e0 Trace; c01087e0 Trace; c010a478 Trace; c01087e0 Trace; c01087e0 Trace; c0100018 Trace; c0108803 Trace; c0108864 Trace; c0105000 Trace; c0100192 Code; c01270ed <_EIP>: Code; c01270ed <= 0: 0f 0b ud2a <= Code; c01270ef 2: 83 c4 0c add $0xc,%esp Code; c01270f2 5: c7 44 24 10 01 00 00 movl $0x1,0x10(%esp,1) Code; c01270f9 c: 00 Code; c01270fa d: 89 f5 mov %esi,%ebp Code; c01270fc f: 83 e5 07 and $0x7,%ebp Code; c01270ff 12: 68 03 00 00 00 push $0x3 Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! 1 warning issued. Results may not be reliable. --- Jonathan Earle Linux Admin, ONC Software Development Nortel Networks * Email: [EMAIL PROTECTED] * Phone: 613-768-1371 * Cell: 613-612-0946
Kernel oops on 2.4.0-test4 and test5 (and later): kmem_cache_grow
) Stack: c01fa0fa c01fa19a 0412 c7ffd0c0 0246 0007 c024dee8 c6702842 c670282e c012736f c7ffd0c0 0007 c7e70140 c670282e c01e96a6 0008 0008 c7e70140 c670282e c7f8be00 c01b4f67 Call trace: [c01fa0fa][c01fa198][c012736f][c01e96a6][c01b4f67][c01b511f][c0199a8c] [c01b4de9][c01b4f3c][c019d833][c011ad5f][c010b84e][c01087e0][c01087e0][c010a478] [c01087e0][c01087e0][c0100018][c0108803][c0108864][c0105000][c0100192] Code: 0f 0b 83 c4 0c c7 44 24 10 01 00 00 00 89 f5 83 e5 07 68 03 EIP; c01270ed kmem_cache_grow+69/228 = Trace; c01fa0fa tvecs+15fe/156c4 Trace; c01fa198 tvecs+169c/156c4 Trace; c012736f kmalloc+6f/a8 Trace; c01e96a6 mpls_output+12/26c Trace; c01b4f67 ip_rcv_finish+2b/214 Trace; c01b511f ip_rcv_finish+1e3/214 Trace; c0199a8c nf_hook_slow+c4/f8 Trace; c01b4de9 ip_rcv+ed/11c Trace; c01b4f3c ip_rcv_finish+0/214 Trace; c019d833 net_rx_action+123/1e8 Trace; c011ad5f do_softirq+4f/70 Trace; c010b84e do_IRQ+a6/b8 Trace; c01087e0 default_idle+0/28 Trace; c01087e0 default_idle+0/28 Trace; c010a478 ret_from_intr+0/20 Trace; c01087e0 default_idle+0/28 Trace; c01087e0 default_idle+0/28 Trace; c0100018 startup_32+18/13a Trace; c0108803 default_idle+23/28 Trace; c0108864 cpu_idle+3c/50 Trace; c0105000 empty_bad_page+0/1000 Trace; c0100192 L6+0/2 Code; c01270ed kmem_cache_grow+69/228 _EIP: Code; c01270ed kmem_cache_grow+69/228 = 0: 0f 0b ud2a = Code; c01270ef kmem_cache_grow+6b/228 2: 83 c4 0c add $0xc,%esp Code; c01270f2 kmem_cache_grow+6e/228 5: c7 44 24 10 01 00 00 movl $0x1,0x10(%esp,1) Code; c01270f9 kmem_cache_grow+75/228 c: 00 Code; c01270fa kmem_cache_grow+76/228 d: 89 f5 mov %esi,%ebp Code; c01270fc kmem_cache_grow+78/228 f: 83 e5 07 and $0x7,%ebp Code; c01270ff kmem_cache_grow+7b/228 12: 68 03 00 00 00 push $0x3 Aiee, killing interrupt handler Kernel panic: Attempted to kill the idle task! 1 warning issued. Results may not be reliable. --- Jonathan Earle Linux Admin, ONC Software Development Nortel Networks * Email: [EMAIL PROTECTED] * Phone: 613-768-1371 * Cell: 613-612-0946
