RE: temperature standard - global config option?
> From: L. K. [mailto:[EMAIL PROTECTED]] > I really do not belive that for a CPU or a motherboard +- 1 > degree would make any difference. You haven't pushed your system, or run it in a hostile environment then. There are many places where systems are run right up to the edge of thermal breakdown, and it's a firm requirement to know exactly what that edge is. > If a CPU runs fine at, say, 37 degrees C, I do not belive it > will have any problems running at 38 or 36 degrees. I support > the ideea of having very good sensors for temperature > monitoring, but CPU and motherboard temperature do not depend > on the rise of the temperature of 1 degree, but when the > temperature rises 10 or more degrees. I hope you understand > what I want to say. I have a CPU that runs great up to 43C, and shuts down hard at 44C so I obviously want to know how close I am to that. I don't want rounding errors to get in the way, and I don't want changes between kernel revs to affect it either. If we've got the bitspace, keep the counters as granular as possible within the useable range that we're designing for. counter = .01 * degrees kelvin - 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: temperature standard - global config option?
From: L. K. [mailto:[EMAIL PROTECTED]] I really do not belive that for a CPU or a motherboard +- 1 degree would make any difference. You haven't pushed your system, or run it in a hostile environment then. There are many places where systems are run right up to the edge of thermal breakdown, and it's a firm requirement to know exactly what that edge is. If a CPU runs fine at, say, 37 degrees C, I do not belive it will have any problems running at 38 or 36 degrees. I support the ideea of having very good sensors for temperature monitoring, but CPU and motherboard temperature do not depend on the rise of the temperature of 1 degree, but when the temperature rises 10 or more degrees. I hope you understand what I want to say. I have a CPU that runs great up to 43C, and shuts down hard at 44C so I obviously want to know how close I am to that. I don't want rounding errors to get in the way, and I don't want changes between kernel revs to affect it either. If we've got the bitspace, keep the counters as granular as possible within the useable range that we're designing for. counter = .01 * degrees kelvin - 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: 2.4.5 -ac series broken on Sparc64
Alan Cox responded to: > Leif Sawyer, who wrote: >> include/linux/irq.h:61: asm/hw_irq.h: No such file or directory >> *** [sched.o] Error 1 >> >> a find . -name 'hw_irq.h' shows appropriate versions >> in i386, ia64, mips, mips64, alpha, ppc, parisc, um, and sh >> > The sparc64 tree isnt very well integrated with -ac. What I > have I merge but where -ac varies from the Linus tree or the > Linus tree requires new files tends to break it. > > It can probably be an empty file This worked for me: sed 's/_SH_/_SPARC64_/g' include/asm-sh/hw_irq.h > include/asm-sparc64/hw_irq.h make mrproper cp ../.config . make oldconfig make dep && make In file included from /usr/src/linux-2.4.5-ac4/include/linux/sched.h:9 /usr/src/linux-2.4.5-ac4/include/linux/binfmts.h:45: warning: `struct mm_struct' declared inside parameter list /usr/src/linux-2.4.5-ac4/include/linux/binfmts.h:45: warning: its scope is only this definition or declaration, /usr/src/linux-2.4.5-ac4/include/linux/binfmts.h:45: warning: which is probably not what you want. This warning is repeated for quite a good portion of the source files during the make process, however the kernel seems to build correctly. Haven't tried a reboot though.. :-\ - 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: 2.4.5 -ac series broken on Sparc64
Alan Cox responded to: Leif Sawyer, who wrote: include/linux/irq.h:61: asm/hw_irq.h: No such file or directory *** [sched.o] Error 1 a find . -name 'hw_irq.h' shows appropriate versions in i386, ia64, mips, mips64, alpha, ppc, parisc, um, and sh The sparc64 tree isnt very well integrated with -ac. What I have I merge but where -ac varies from the Linus tree or the Linus tree requires new files tends to break it. It can probably be an empty file This worked for me: sed 's/_SH_/_SPARC64_/g' include/asm-sh/hw_irq.h include/asm-sparc64/hw_irq.h make mrproper cp ../.config . make oldconfig make dep make In file included from /usr/src/linux-2.4.5-ac4/include/linux/sched.h:9 /usr/src/linux-2.4.5-ac4/include/linux/binfmts.h:45: warning: `struct mm_struct' declared inside parameter list /usr/src/linux-2.4.5-ac4/include/linux/binfmts.h:45: warning: its scope is only this definition or declaration, /usr/src/linux-2.4.5-ac4/include/linux/binfmts.h:45: warning: which is probably not what you want. This warning is repeated for quite a good portion of the source files during the make process, however the kernel seems to build correctly. Haven't tried a reboot though.. :-\ - 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/
2.4.5 -ac series broken on Sparc64
i've successfully built the 2.4.5 vanilla kernel. I went to check the -ac series, and each [1-4] breaks in the same way on Sparc64 platform: include/linux/irq.h:61: asm/hw_irq.h: No such file or directory *** [sched.o] Error 1 a find . -name 'hw_irq.h' shows appropriate versions in i386, ia64, mips, mips64, alpha, ppc, parisc, um, and sh Is this is a ports-maintainer issue, or what? Surely breaking the sparc platform is not in the future plans... Thanks. - 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/
2.4.5 -ac series broken on Sparc64
i've successfully built the 2.4.5 vanilla kernel. I went to check the -ac series, and each [1-4] breaks in the same way on Sparc64 platform: include/linux/irq.h:61: asm/hw_irq.h: No such file or directory *** [sched.o] Error 1 a find . -name 'hw_irq.h' shows appropriate versions in i386, ia64, mips, mips64, alpha, ppc, parisc, um, and sh Is this is a ports-maintainer issue, or what? Surely breaking the sparc platform is not in the future plans... Thanks. - 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/
DHCP comiling issues under sparc linux
Below is the end of a thread between myself and Ted Lemon regarding building DHCP under Sparc Linux. I'm not well versed in parsing the kernel code to know what the subtle differences in the different implementations of this IOCtl, and am looking for some guidance from the appropriate maintainers. Please read below for the summary. I'll be happy to fill in the blanks off-list. Thanks, Leif -Original Message- Ted Lemon responds to: > Leif Sawyer who wrote: > Under Kernel 2.4.3, at least for Sparc64, the following > define in includes/cf/linux.h creates the problem: > > 154: #define SIOCGIFCONF_NULL_BUF_GIVES_CORRECT_LEN > > undef'ing this out allows the server to build correctly > and initialize properly. > > #if !(defined(__sparc__) && (LINUX_MAJOR >= 2 && LINUX_MINOR >= 4)) > #define SIOCGIFCONF_NULL_BUF_GIVES_CORRECT_LEN > #endif Hm. So Linux 2.4 on Sparc provides a different API than Linux 2.4 on Intel. That's lame. But I would like to think that this would be considered a bug, and therefore fixed. > I'll try this on my i386 box at home and see if it compiles correctly > as well. That won't be until late tonight, if i'm lucky. Cool, thanks. The code *should* work unmodified on Linux 2.4/i386. Really, it should work for the sparc version as well - I don't suppose I could talk you into reporting this to the Linux/sparc people as a bug? The deal is that you're supposed to be able to call SIOCGIFCONF with a length of zero, and SIOCGIFCONF will return the length of the buffer needed to record all the interface configuration information, and then you allocate a buffer that size and call SIOCGIFCONF again. This supposedly works on 2.4 for intel, and on 2.2 for intel, so it makes sense that it should work on 2.2 and 2.4 for sparc as well. :'} _MelloN_ - 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/
DHCP comiling issues under sparc linux
Below is the end of a thread between myself and Ted Lemon regarding building DHCP under Sparc Linux. I'm not well versed in parsing the kernel code to know what the subtle differences in the different implementations of this IOCtl, and am looking for some guidance from the appropriate maintainers. Please read below for the summary. I'll be happy to fill in the blanks off-list. Thanks, Leif -Original Message- Ted Lemon responds to: Leif Sawyer who wrote: Under Kernel 2.4.3, at least for Sparc64, the following define in includes/cf/linux.h creates the problem: 154: #define SIOCGIFCONF_NULL_BUF_GIVES_CORRECT_LEN undef'ing this out allows the server to build correctly and initialize properly. #if !(defined(__sparc__) (LINUX_MAJOR = 2 LINUX_MINOR = 4)) #define SIOCGIFCONF_NULL_BUF_GIVES_CORRECT_LEN #endif Hm. So Linux 2.4 on Sparc provides a different API than Linux 2.4 on Intel. That's lame. But I would like to think that this would be considered a bug, and therefore fixed. I'll try this on my i386 box at home and see if it compiles correctly as well. That won't be until late tonight, if i'm lucky. Cool, thanks. The code *should* work unmodified on Linux 2.4/i386. Really, it should work for the sparc version as well - I don't suppose I could talk you into reporting this to the Linux/sparc people as a bug? The deal is that you're supposed to be able to call SIOCGIFCONF with a length of zero, and SIOCGIFCONF will return the length of the buffer needed to record all the interface configuration information, and then you allocate a buffer that size and call SIOCGIFCONF again. This supposedly works on 2.4 for intel, and on 2.2 for intel, so it makes sense that it should work on 2.2 and 2.4 for sparc as well. :'} _MelloN_ - 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: [OT] Re: CML2 1.3.1, aka "I stick my neck out a mile..."
Jeff Garzik writes:
> Does anybody have a procmail recipe that filters out e-mail to
> linux-kernel that contain ridiculously long .sigs?
> --
> Jeff Garzik | Game called on account of naked chick
Oh for fsck's sake. You've now wasted 1000x more bandwidth bitching
about sig length than the the actual sig used up.
Get a life. Ignore that which displeases you. Ignorance is bliss.
You are no longer a republican. Eat your vegatables.
Just stop whining about ESR's sigs already.
And now back to your regularly scheduled kernel hacking.
(woo! sluggy freelance. poing!)
#insert
--
Leif Sawyer -- Pi@4398680
[EMAIL PROTECTED] || [EMAIL PROTECTED] || internic: LS2540
(907) 868 - 0116 || ICQ - 3749190 || http://home.gci.net/~leif
Network Engineer -- General Communication Inc.
PGP Fingerprint: 77 C8 34 B8 FD BC C6 32 5F FE 93 4B AE 6C F7 4E
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GAT d+ s: a C+++(++)$ US$ UL$ P+++ L++(+++) E---
W+++ N+ o+ K w O- M- V PS+ PE Y+ PGP(+) t+@ 5- X R- tv b++(+++)
DI D++ G+ e(+)* h-- r++ y+ PP HH A19 NT{--}
--END GEEK CODE BLOCK--
Decode it! http://www.ebb.org/ungeek/
-
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: [OT] Re: CML2 1.3.1, aka I stick my neck out a mile...
Jeff Garzik writes:
Does anybody have a procmail recipe that filters out e-mail to
linux-kernel that contain ridiculously long .sigs?
--
Jeff Garzik | Game called on account of naked chick
Oh for fsck's sake. You've now wasted 1000x more bandwidth bitching
about sig length than the the actual sig used up.
Get a life. Ignore that which displeases you. Ignorance is bliss.
You are no longer a republican. Eat your vegatables.
Just stop whining about ESR's sigs already.
And now back to your regularly scheduled kernel hacking.
(woo! sluggy freelance. poing!)
#insert longsig.h
--
Leif Sawyer -- Pi@4398680
[EMAIL PROTECTED] || [EMAIL PROTECTED] || internic: LS2540
(907) 868 - 0116 || ICQ - 3749190 || http://home.gci.net/~leif
Network Engineer -- General Communication Inc.
PGP Fingerprint: 77 C8 34 B8 FD BC C6 32 5F FE 93 4B AE 6C F7 4E
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GAT d+ s: a C+++(++)$ US$ UL$ P+++ L++(+++) E---
W+++ N+ o+ K w O- M- V PS+ PE Y+ PGP(+) t+@ 5- X R- tv b++(+++)
DI D++ G+ e(+)* h-- r++ y+ PP HH A19 NT{--}
--END GEEK CODE BLOCK--
Decode it! http://www.ebb.org/ungeek/
-
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: IP Acounting Idea for 2.5
> > Jesse Pollard replies: > > to Leif Sawyer who wrote: > > >> Besides, what would be gained in making the counters RO, if > > >> they were cleared every time the module was loaded/unloaded? > > > > > > 1. Knowlege that the module was reloaded. > > > 2. Knowlege that the data being measured is correct > > > 3. Having reliable measures > > > 4. being able to derive valid statistics > > > > > > > Good. Now that we have valid objectives to reach, which of these > > are NOT met by making the fixes entirely in userspace, say by > > incorporating a wrapper script to ensure that no external > applications > > can flush the table counters? > > > > They're still all met, right? > > Nope - some of the applications that may be purchased do not have > to go through the scripts to reset the counters. They just need access > to the counters, and reset is built into the applications. > This violates > all 4 objectives. > > > And we haven't had to fill the kernel with more cruft. > > Removing/no-oping the reset code would make the module > SMALLER, and simpler. > NO. Don't remove the functionality that is required. Fix your userspace applications to behave correctly. If _you_ require your userspace applications to not clear counters, then fix the application. The counters are not gospel. The modules are not omnipresent. Time and again, people beg and plead the kernel developers to change the kernel to suit their personal biases and applications. Historically they have been vehemently against it. Of what purpose does breaking EVERY application out there by performing this kernel mod have? As Matti Aarnio points out, this is nearly beaten to death. Since none of the 'Big Boys' have commented, my guess is that this is a moot argument, and no changes to the kernel will take place. /me steps off of soapbox /me retires this thread - 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: IP Acounting Idea for 2.5
Jesse Pollard replies: to Leif Sawyer who wrote: >> Besides, what would be gained in making the counters RO, if >> they were cleared every time the module was loaded/unloaded? > > 1. Knowlege that the module was reloaded. > 2. Knowlege that the data being measured is correct > 3. Having reliable measures > 4. being able to derive valid statistics > Good. Now that we have valid objectives to reach, which of these are NOT met by making the fixes entirely in userspace, say by incorporating a wrapper script to ensure that no external applications can flush the table counters? They're still all met, right? And we haven't had to fill the kernel with more cruft. - 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: IP Acounting Idea for 2.5
Jesse Pollard continues with: > Leif Sawyer <[EMAIL PROTECTED]>: >>> Ian Stirling [mailto:[EMAIL PROTECTED]] >>>> Manfred Bartz responded to >>>>> Russell King <[EMAIL PROTECTED]> who writes: >>>>> >>>>> You just illustrated my point. While there is a >>>>> reset capability people will use it and accounting/ >>>>> logging programs will get wrong data. Resetable >>>>> counters might be a minor convenience when debugging >>>>> but the price is unreliable programs and the loss of the >>>>> ability of several programs to use the same counters. >>>> >>>> You of course, are commenting from the fact that your >>>> applications are stupid, written poorly, and cannot handle >>>> 'wrapped' data. Take MRTG >>>> >>>> Similarly, if my InPackets are at 102345 at one read, and >>>> 2345 the next read, and I know that my counter is 32 bits, >>>> then I know i've wrapped and can do >>> >>> I think the point being made is that if InPackets are at >>> 102345 at one read, and 2345 the next, and you know it's >>> a 32 bit counter, it's completely unreliable to assume that >>> you have in fact recieved 4294867295 packets, if the counter >>> can be zeroed. You can say nothing other than at least 2345 >>> packets, at most 2345+n*2^32 have been got since you last >>> checked. >> >> Ah, yes.. I seem to have misplaced a bit of text in my reply. >> >> The continuation of thought: >> >> How the application derives the status of a wrapped counter or >> a zero'ed counter is dependant on the device being monitored. >> >> Yes, you have to know what your interface is capable of >> (maxbytes/sec) so that you can do a simple calculation where: >> >> maximum_throughput = maxbytes_sec * (time_now - time_last_read) >> >> and if your previous good counter + the maximum throughput wraps >> the counter, you have a good chance that you've simply wrapped. >> >> If not, then you can assume that your counters were cleared >> at some point, log the data you've got, and keep moving forward. > > And that introduces errors in measurement. It also depends on > how frequently an uncontroled process is clearing the counters. > You may never be able to get a valid measurement. This is true. Which is why application programmers need to write code as if they are not the only [ab]users of data. Which brings me back to my point. Don't force the kernel to uphold your local application requirements of stable counters. Enforce it in the userspace portion of the code. Yes, you could extend the proc filesystem (ugh) with a flag that could be read by the ip[chains|tables] user app to determine if clearing flags were allowed. Then a simple echo 1 > /proc/sys/net/ipv4/counters_locked or some such cruft. But I don't see this extension making into the standard kernel at this time. It just seems to be wasteful. If you (at your site) really need this type of functionality, it's pretty darn simple to write a wrapper to ip[tables|chains] which silently (or not so) drops the option to clear the counters before calling the real version. Besides, what would be gained in making the counters RO, if they were cleared every time the module was loaded/unloaded? - 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: IP Acounting Idea for 2.5
Jesse Pollard continues with: Leif Sawyer [EMAIL PROTECTED]: Ian Stirling [mailto:[EMAIL PROTECTED]] Manfred Bartz responded to Russell King [EMAIL PROTECTED] who writes: You just illustrated my point. While there is a reset capability people will use it and accounting/ logging programs will get wrong data. Resetable counters might be a minor convenience when debugging but the price is unreliable programs and the loss of the ability of several programs to use the same counters. You of course, are commenting from the fact that your applications are stupid, written poorly, and cannot handle 'wrapped' data. Take MRTG snip Similarly, if my InPackets are at 102345 at one read, and 2345 the next read, and I know that my counter is 32 bits, then I know i've wrapped and can do I think the point being made is that if InPackets are at 102345 at one read, and 2345 the next, and you know it's a 32 bit counter, it's completely unreliable to assume that you have in fact recieved 4294867295 packets, if the counter can be zeroed. You can say nothing other than at least 2345 packets, at most 2345+n*2^32 have been got since you last checked. Ah, yes.. I seem to have misplaced a bit of text in my reply. The continuation of thought: How the application derives the status of a wrapped counter or a zero'ed counter is dependant on the device being monitored. Yes, you have to know what your interface is capable of (maxbytes/sec) so that you can do a simple calculation where: maximum_throughput = maxbytes_sec * (time_now - time_last_read) and if your previous good counter + the maximum throughput wraps the counter, you have a good chance that you've simply wrapped. If not, then you can assume that your counters were cleared at some point, log the data you've got, and keep moving forward. And that introduces errors in measurement. It also depends on how frequently an uncontroled process is clearing the counters. You may never be able to get a valid measurement. This is true. Which is why application programmers need to write code as if they are not the only [ab]users of data. Which brings me back to my point. Don't force the kernel to uphold your local application requirements of stable counters. Enforce it in the userspace portion of the code. subtopic Yes, you could extend the proc filesystem (ugh) with a flag that could be read by the ip[chains|tables] user app to determine if clearing flags were allowed. Then a simple echo 1 /proc/sys/net/ipv4/counters_locked or some such cruft. But I don't see this extension making into the standard kernel at this time. It just seems to be wasteful. /subtopic If you (at your site) really need this type of functionality, it's pretty darn simple to write a wrapper to ip[tables|chains] which silently (or not so) drops the option to clear the counters before calling the real version. Besides, what would be gained in making the counters RO, if they were cleared every time the module was loaded/unloaded? - 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: IP Acounting Idea for 2.5
Jesse Pollard replies: to Leif Sawyer who wrote: Besides, what would be gained in making the counters RO, if they were cleared every time the module was loaded/unloaded? 1. Knowlege that the module was reloaded. 2. Knowlege that the data being measured is correct 3. Having reliable measures 4. being able to derive valid statistics Good. Now that we have valid objectives to reach, which of these are NOT met by making the fixes entirely in userspace, say by incorporating a wrapper script to ensure that no external applications can flush the table counters? They're still all met, right? And we haven't had to fill the kernel with more cruft. - 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: IP Acounting Idea for 2.5
Jesse Pollard replies: to Leif Sawyer who wrote: Besides, what would be gained in making the counters RO, if they were cleared every time the module was loaded/unloaded? 1. Knowlege that the module was reloaded. 2. Knowlege that the data being measured is correct 3. Having reliable measures 4. being able to derive valid statistics Good. Now that we have valid objectives to reach, which of these are NOT met by making the fixes entirely in userspace, say by incorporating a wrapper script to ensure that no external applications can flush the table counters? They're still all met, right? Nope - some of the applications that may be purchased do not have to go through the scripts to reset the counters. They just need access to the counters, and reset is built into the applications. This violates all 4 objectives. And we haven't had to fill the kernel with more cruft. Removing/no-oping the reset code would make the module SMALLER, and simpler. NO. Don't remove the functionality that is required. Fix your userspace applications to behave correctly. If _you_ require your userspace applications to not clear counters, then fix the application. The counters are not gospel. The modules are not omnipresent. Time and again, people beg and plead the kernel developers to change the kernel to suit their personal biases and applications. Historically they have been vehemently against it. Of what purpose does breaking EVERY application out there by performing this kernel mod have? As Matti Aarnio points out, this is nearly beaten to death. Since none of the 'Big Boys' have commented, my guess is that this is a moot argument, and no changes to the kernel will take place. /me steps off of soapbox /me retires this thread - 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: IP Acounting Idea for 2.5
> From: Ian Stirling [mailto:[EMAIL PROTECTED]] > > Manfred Bartz responded to > > > Russell King <[EMAIL PROTECTED]> who writes: > > > > You just illustrated my point. While there is a reset capability > > > people will use it and accounting/logging programs will get wrong > > > data. Resetable counters might be a minor convenience > when debugging > > > but the price is unreliable programs and the loss of the > ability of > > > several programs to use the same counters. > > > > You of course, are commenting from the fact that your > applications are > > stupid, written poorly, and cannot handle 'wrapped' data. Take MRTG > > > Similarly, if my InPackets are at 102345 at one read, and > 2345 the next > > read, > > and I know that my counter is 32 bits, then I know i've > wrapped and can do > > I think the point being made is that if InPackets are at > 102345 at one read, > and 2345 the next, and you know it's a 32 bit counter, it's completely > unreliable to assume that you have in fact recieved 4294867295 > packets, if the counter can be zeroed. > You can say nothing other than at least 2345 packets, at most > 2345+n*2^32 have been got since you last checked. Ah, yes.. I seem to have misplaced a bit of text in my reply. The continuation of thought: How the application derives the status of a wrapped counter or a zero'ed counter is dependant on the device being monitored. Yes, you have to know what your interface is capable of (maxbytes/sec) so that you can do a simple calculation where: maximum_throughput = maxbytes_sec * (time_now - time_last_read) and if your previous good counter + the maximum throughput wraps the counter, you have a good chance that you've simply wrapped. If not, then you can assume that your counters were cleared at some point, log the data you've got, and keep moving forward. - 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: CML2 1.1.3 release announcement
It also appears that upon a re-configuration of 2.4.3 from 2.2.17: > cd /usr/src/linux > cp ../linux-2.2.17/.config . > make oldconfig where the old configuration did not include FrameBuffer support, then performing an Xconfig to tweak some settings and enable FB, no default fonts were allocated. This is contrary to CML1 behavoir. > grep ^CONFIG_FB .config CONFIG_FB=y CONFIG_FB_VESA=y CONFIG_FB_MACH64=y however CML1, after only selecting the applicable drivers gives: > grep ^CONFIG_FB ~/myotherbox-2.4.3.config CONFIG_FB=y CONFIG_FB_VESA=y CONFIG_FB_VGA16=y CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB16=y CONFIG_FBCON_CFB24=y CONFIG_FBCON_CFB32=y CONFIG_FBCON_VGA_PLANES=y - 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: IP Acounting Idea for 2.5
Manfred Bartz responded to > Russell King <[EMAIL PROTECTED]> who writes: > > > On Mon, Apr 16, 2001 at 12:07:31PM +1000, Manfred Bartz wrote: > > > There is another issue with logging in general: > > > > > > *COUNTERS MUST NOT BE RESETABLE!!!* > > > > Umm, no. Counters can be resetable - you just specify that > > accounting programs should not reset them, ever. > > > > The ability to reset counters is extremely useful if you're a human > > looking at the output of iptables -L -v. (I thus far know of no one > > who can memorise the counter values for around 40 rules). > > You just illustrated my point. While there is a reset capability > people will use it and accounting/logging programs will get wrong > data. Resetable counters might be a minor convenience when debugging > but the price is unreliable programs and the loss of the ability of > several programs to use the same counters. You of course, are commenting from the fact that your applications are stupid, written poorly, and cannot handle 'wrapped' data. Take MRTG as one example of a good application, for it can handle counters that have been cleared between reads. > Also, do you always reset the date and time everytime you make time > measurements? No, but i realize that if my time has incremented, and my date has not changed, then it's later. If my time has _decremented_ and my date has not, then I've time-warped. If my time has decremented and my date has incremented, then it's simply the next-date-increment. Similarly, if my InPackets are at 102345 at one read, and 2345 the next read, and I know that my counter is 32 bits, then I know i've wrapped and can do my own math. Applications need to get smarter. Don't place arbitrary rules where they don't belong. - 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: CML2 1.1.3 release announcement
Hmm. Looking better - I'm in the process of configuring v2.4.3.. It looks as if the TUN/TAP selection isn't being grok'd right. It should be available as a module, yet the 'm' is greyed out and not selectable. I don't see any prerequistes in the drivers/net/rules.cml either, although i'm not exactly proficient at reading these yet.. if the functionality of tun/tap as a module has been removed, perhaps the help text should also be updated, but CML1 does allow me to select it as a module.. As far as the colors go, it never really bothers me, although my color-blind friend my have some input -- but he's out sick with pink-eye. (okay, not pink-eye, but that just sounded funny for a color-blind person) Leif - 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: CML2 1.1.3 release announcement
Hmm. Looking better - I'm in the process of configuring v2.4.3.. It looks as if the TUN/TAP selection isn't being grok'd right. It should be available as a module, yet the 'm' is greyed out and not selectable. I don't see any prerequistes in the drivers/net/rules.cml either, although i'm not exactly proficient at reading these yet.. if the functionality of tun/tap as a module has been removed, perhaps the help text should also be updated, but CML1 does allow me to select it as a module.. As far as the colors go, it never really bothers me, although my color-blind friend my have some input -- but he's out sick with pink-eye. (okay, not pink-eye, but that just sounded funny for a color-blind person) Leif - 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: IP Acounting Idea for 2.5
Manfred Bartz responded to Russell King [EMAIL PROTECTED] who writes: On Mon, Apr 16, 2001 at 12:07:31PM +1000, Manfred Bartz wrote: There is another issue with logging in general: *COUNTERS MUST NOT BE RESETABLE!!!* Umm, no. Counters can be resetable - you just specify that accounting programs should not reset them, ever. The ability to reset counters is extremely useful if you're a human looking at the output of iptables -L -v. (I thus far know of no one who can memorise the counter values for around 40 rules). You just illustrated my point. While there is a reset capability people will use it and accounting/logging programs will get wrong data. Resetable counters might be a minor convenience when debugging but the price is unreliable programs and the loss of the ability of several programs to use the same counters. You of course, are commenting from the fact that your applications are stupid, written poorly, and cannot handle 'wrapped' data. Take MRTG as one example of a good application, for it can handle counters that have been cleared between reads. Also, do you always reset the date and time everytime you make time measurements? No, but i realize that if my time has incremented, and my date has not changed, then it's later. If my time has _decremented_ and my date has not, then I've time-warped. If my time has decremented and my date has incremented, then it's simply the next-date-increment. Similarly, if my InPackets are at 102345 at one read, and 2345 the next read, and I know that my counter is 32 bits, then I know i've wrapped and can do my own math. Applications need to get smarter. Don't place arbitrary rules where they don't belong. - 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: CML2 1.1.3 release announcement
It also appears that upon a re-configuration of 2.4.3 from 2.2.17: cd /usr/src/linux cp ../linux-2.2.17/.config . make oldconfig where the old configuration did not include FrameBuffer support, then performing an Xconfig to tweak some settings and enable FB, no default fonts were allocated. This is contrary to CML1 behavoir. grep ^CONFIG_FB .config CONFIG_FB=y CONFIG_FB_VESA=y CONFIG_FB_MACH64=y however CML1, after only selecting the applicable drivers gives: grep ^CONFIG_FB ~/myotherbox-2.4.3.config CONFIG_FB=y CONFIG_FB_VESA=y CONFIG_FB_VGA16=y CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB16=y CONFIG_FBCON_CFB24=y CONFIG_FBCON_CFB32=y CONFIG_FBCON_VGA_PLANES=y - 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: IP Acounting Idea for 2.5
From: Ian Stirling [mailto:[EMAIL PROTECTED]] Manfred Bartz responded to Russell King [EMAIL PROTECTED] who writes: snip You just illustrated my point. While there is a reset capability people will use it and accounting/logging programs will get wrong data. Resetable counters might be a minor convenience when debugging but the price is unreliable programs and the loss of the ability of several programs to use the same counters. You of course, are commenting from the fact that your applications are stupid, written poorly, and cannot handle 'wrapped' data. Take MRTG snip Similarly, if my InPackets are at 102345 at one read, and 2345 the next read, and I know that my counter is 32 bits, then I know i've wrapped and can do I think the point being made is that if InPackets are at 102345 at one read, and 2345 the next, and you know it's a 32 bit counter, it's completely unreliable to assume that you have in fact recieved 4294867295 packets, if the counter can be zeroed. You can say nothing other than at least 2345 packets, at most 2345+n*2^32 have been got since you last checked. Ah, yes.. I seem to have misplaced a bit of text in my reply. The continuation of thought: How the application derives the status of a wrapped counter or a zero'ed counter is dependant on the device being monitored. Yes, you have to know what your interface is capable of (maxbytes/sec) so that you can do a simple calculation where: maximum_throughput = maxbytes_sec * (time_now - time_last_read) and if your previous good counter + the maximum throughput wraps the counter, you have a good chance that you've simply wrapped. If not, then you can assume that your counters were cleared at some point, log the data you've got, and keep moving forward. - 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 compile linux 0.0.0.1?
On Fri, 30 Mar 2001, Alan Olsen wrote: > On Fri, 30 Mar 2001, David Relson wrote: > >> At 03:06 PM 3/30/01, Alan Olsen wrote: >>>On Fri, 30 Mar 2001, Bruno Avila wrote: >>> I can't find this anywhere. What is the version of the tools to compile linux kernel 0.0.0.1 (../Historic)? And where can i find them? >>> >>>Well, first you have to find a good source of obsidean, a >>> couple of sharp rocks, and some flint... >> >> I have a friend who's a flintknapper. He's been doing it >> for decades and does good work. I'm sure he could set you >> up with raw materials or with finished products, i.e. >> arrowheads, knife blades, etc. > > Yeah, but then you have to find the buffalo and that gets > hard. (Actually Linus used a carabou, but those are even > harder to find...) Well, I remember back to 0.12ish and the Caribou around here (Alaska) were plentiful then. Ah, those were the days. I did find my 0.95 disk the other day (Yggdrasil distro) and toyed with the idea of installing it, just to see how much things had really changed. But i don't have anything pre-80686 :-( - 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 compile linux 0.0.0.1?
On Fri, 30 Mar 2001, Alan Olsen wrote: On Fri, 30 Mar 2001, David Relson wrote: At 03:06 PM 3/30/01, Alan Olsen wrote: On Fri, 30 Mar 2001, Bruno Avila wrote: I can't find this anywhere. What is the version of the tools to compile linux kernel 0.0.0.1 (../Historic)? And where can i find them? Well, first you have to find a good source of obsidean, a couple of sharp rocks, and some flint... I have a friend who's a flintknapper. He's been doing it for decades and does good work. I'm sure he could set you up with raw materials or with finished products, i.e. arrowheads, knife blades, etc. Yeah, but then you have to find the buffalo and that gets hard. (Actually Linus used a carabou, but those are even harder to find...) Well, I remember back to 0.12ish and the Caribou around here (Alaska) were plentiful then. Ah, those were the days. offtopic level=2 I did find my 0.95 disk the other day (Yggdrasil distro) and toyed with the idea of installing it, just to see how much things had really changed. But i don't have anything pre-80686 :-( /offtopic - 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: [PATCH] Prevent OOM from killing init
Patrick O'Rourke, who wrote: > Since the system will panic if the init process is chosen by > the OOM killer, the following patch prevents select_bad_process() > from picking init. > (Patch deleted) What happens when init is not pid == 1, as is often the case during installs, booting off of cdrom, etc.. - 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: [PATCH] Prevent OOM from killing init
Patrick O'Rourke, who wrote: Since the system will panic if the init process is chosen by the OOM killer, the following patch prevents select_bad_process() from picking init. (Patch deleted) What happens when init is not pid == 1, as is often the case during installs, booting off of cdrom, etc.. - 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: Linux stifles innovation...
> From: Dr. Kelsey Hudson [mailto:[EMAIL PROTECTED]] > > 'good' in this case was meant to mean working properly, well-coded, > does-what-it's-suppossed-to-do, eg not broken in one way or > another. English should have a better word that 'good...' > Functional, perfect, clean, documented, readable, understandable, tight, tuned, grok-able. Don't use one word to mean multiple things if you're trying to make a clear case. Otherwise you sound like a Micro$oft lawyer. :-) Really, this thread should just DIE already. We now return you to your regularly scheduled kernel bashing. - 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: Linux stifles innovation...
From: Dr. Kelsey Hudson [mailto:[EMAIL PROTECTED]] 'good' in this case was meant to mean working properly, well-coded, does-what-it's-suppossed-to-do, eg not broken in one way or another. English should have a better word that 'good...' Functional, perfect, clean, documented, readable, understandable, tight, tuned, grok-able. Don't use one word to mean multiple things if you're trying to make a clear case. Otherwise you sound like a Micro$oft lawyer. :-) Really, this thread should just DIE already. We now return you to your regularly scheduled kernel bashing. - 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: named streams, extended attributes, and posix
[EMAIL PROTECTED] [[EMAIL PROTECTED]] wrote: > Here's an idea: streams/etc are reached by appending > "/.../xxx" or some such to paths, thus: > for streamname on /dir/file, we have "/dir/file/.../streamname" > for a directory /dir/dir, we get /dir/dir/.../streamname" >-- "..." is a special subdirectory of any directories which have An interesting point to note here would be that the directory '...' has been used for many years to 'hide' things from un-skilled sysadmins. In other words, warez ftp sites pop up all over the place, and this directory name is pretty close to being the number one stash point, right next to ".. " - 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: named streams, extended attributes, and posix
[EMAIL PROTECTED] [[EMAIL PROTECTED]] wrote: Here's an idea: streams/etc are reached by appending "/.../xxx" or some such to paths, thus: for streamname on /dir/file, we have "/dir/file/.../streamname" for a directory /dir/dir, we get /dir/dir/.../streamname" -- "..." is a special subdirectory of any directories which have An interesting point to note here would be that the directory '...' has been used for many years to 'hide' things from un-skilled sysadmins. In other words, warez ftp sites pop up all over the place, and this directory name is pretty close to being the number one stash point, right next to ".. " - 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: Error compiling for sparc64
David S. Miller [[EMAIL PROTECTED]] wrote: > Wrong, your one-line fix may make it build correctly but it > will not produce working quota 32-bit syscall code there. > > Someone needs to fixup the conversion code, I don't have time to track > the AC series (it actually duplicates a lot of networking stuff I just > pushed to Linus and ended up in 2.4.1-pre10) which means it likely > won't be fixed until Linus takes those quota code changes. > > Please stick to 2.4.1-preX on sparc64, and if using 2.4.1-pre10 please > apply this patch to get a clean build :-) Hmm. Well, this i can understand. I'm not using quotas, so I probably wouldn't have ever introduced any bugs. I don't have a lot of time to try to understand the quota system, so I was just looking for the quick fix. I'll rebuild under 2.4.1-pre10 with the patch and see how things go from there. Thanks, Leif - 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/
Error compiling for sparc64
I reported this to Alan around -ac5, but never saw the patch included.
In arch/sparc64/kernel/sys_sparc32.c:~900
struct dqblk32 {
__u32 dqb_bhardlimit;
__u32 dqb_bsoftlimit;
__u32 dqb_curblocks;
__u32 dqb_ihardlimit;
__u32 dqb_isoftlimit;
__u32 dqb_curinodes;
__kernel_time_t32 dqb_btime;
__kernel_time_t32 dqb_itime;
};
extern asmlinkage int sys_quotactl(int cmd, const char *special, int id,
caddr_t addr);
asmlinkage int sys32_quotactl(int cmd, const char *special, int id, unsigned
long addr)
{
int cmds = cmd >> SUBCMDSHIFT;
int err;
struct dqblk d;
^
You can see the typo pretty easily.
The following patch allows the kernel to compile correctly
and has been working fine for the last 2 weeks under 2.4.0-ac5.
It should apply cleanly to ac11 as well.
--- linux/arch/sparc64/kernel/sys_sparc32.cWed Jan 10 13:08:10 2001
+++ linux/arch/sparc64/kernel/sys_sparc32.c~Fri Dec 29 13:07:21 2000
@@ +904,7 -904,7 @@
{
int cmds = cmd >> SUBCMDSHIFT;
int err;
+ struct dqblk32 d;
- struct dqblk d;
mm_segment_t old_fs;
char *spec;
Thanks.
--
Leif Sawyer -- Pi@4398680
[EMAIL PROTECTED] || [EMAIL PROTECTED] || internic: LS2540
(907) 868 - 0116 || ICQ - 3749190 || http://home.gci.net/~leif
Network Engineer -- General Communication Inc.
PGP Fingerprint: 77 C8 34 B8 FD BC C6 32 5F FE 93 4B AE 6C F7 4E
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GAT d+ s: a C+++(++)$ US$ UL$ P+++ L++(+++) E---
W+++ N+ o+ K w O- M- V PS+ PE Y+ PGP(+) t+@ 5- X R- tv b++(+++)
DI D++ G+ e(+)* h-- r++ y+ PP HH A19 NT{--}
--END GEEK CODE BLOCK--
Decode it! http://www.ebb.org/ungeek/
-
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/
Error compiling for sparc64
I reported this to Alan around -ac5, but never saw the patch included.
In arch/sparc64/kernel/sys_sparc32.c:~900
struct dqblk32 {
__u32 dqb_bhardlimit;
__u32 dqb_bsoftlimit;
__u32 dqb_curblocks;
__u32 dqb_ihardlimit;
__u32 dqb_isoftlimit;
__u32 dqb_curinodes;
__kernel_time_t32 dqb_btime;
__kernel_time_t32 dqb_itime;
};
extern asmlinkage int sys_quotactl(int cmd, const char *special, int id,
caddr_t addr);
asmlinkage int sys32_quotactl(int cmd, const char *special, int id, unsigned
long addr)
{
int cmds = cmd SUBCMDSHIFT;
int err;
struct dqblk d;
^
You can see the typo pretty easily.
The following patch allows the kernel to compile correctly
and has been working fine for the last 2 weeks under 2.4.0-ac5.
It should apply cleanly to ac11 as well.
--- linux/arch/sparc64/kernel/sys_sparc32.cWed Jan 10 13:08:10 2001
+++ linux/arch/sparc64/kernel/sys_sparc32.c~Fri Dec 29 13:07:21 2000
@@ +904,7 -904,7 @@
{
int cmds = cmd SUBCMDSHIFT;
int err;
+ struct dqblk32 d;
- struct dqblk d;
mm_segment_t old_fs;
char *spec;
Thanks.
--
Leif Sawyer -- Pi@4398680
[EMAIL PROTECTED] || [EMAIL PROTECTED] || internic: LS2540
(907) 868 - 0116 || ICQ - 3749190 || http://home.gci.net/~leif
Network Engineer -- General Communication Inc.
PGP Fingerprint: 77 C8 34 B8 FD BC C6 32 5F FE 93 4B AE 6C F7 4E
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GAT d+ s: a C+++(++)$ US$ UL$ P+++ L++(+++) E---
W+++ N+ o+ K w O- M- V PS+ PE Y+ PGP(+) t+@ 5- X R- tv b++(+++)
DI D++ G+ e(+)* h-- r++ y+ PP HH A19 NT{--}
--END GEEK CODE BLOCK--
Decode it! http://www.ebb.org/ungeek/
-
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/
