Re: Why system call need to copy the date from the userspace before using it
>if you want actual concrete examples, let me know. I'd love a few, but maybe privately? I can certainly see where always copying is simpler; I certainly consider this to be an optimization, which must be looked at carefully, lest you end up with that which speed things up a little, but adds a big maintenance headache. But this strikes me as a potentially big speed up for movement through devices. (Or is there already a mechanism for that?) >It checks if the LAST page belongs to userland, and fails if not; I can't claim to know how memory assignment goes. I suppose that this statement means that the address space the userland program sees is continuous? If not I could see a scenario where that would allow someone to get at data that isn't theirs, by allocating around until they got an chunk far up in memory, then just specified a start address way lower with the right size to end up on their chunk. I'm assuming this isn't a workable scenario, right? -- You are in a maze of twisty passages, all alike. Again. http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD - 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: Why system call need to copy the date from the userspace before using it
Sorry if this bugs anyone, but I'm learning things here.
What I would expect the kernel to do is this:
system_call_data_prep (userdata, size){
if !4G/4G {
for each page from userdata to userdata+size
{
if the page is swapped out, swap it in
if the page is not owned by the user process, return -ENOWAYMAN
otherwise, lock the page
}
return userdata;
}
else { //kernel land and userland are mutually exclusive
copy the data into kernel land
return kernelland_copy_of_userdata;
}
}
(And then the syscall would need to run the opposite function
sys_call_data_unprep to unlock pages.)
Hmm, maybe that interface sucks.
Is it anything close to that?
--
The best is the enemy of the good -- Voltaire
The Good Enough is the enemy of the Great -- Me
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
-
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: Why system call need to copy the date from the userspace before using it
>>Why not use it directly >Some of these reasons are: It seems like you gave reason why userland pointers shouldn't be trusted, not why userland data should be copied into kernel land. All the problems you mentioned would have to be solved by the kernel regardless of copying the data around. Ummm... Except for the who's mapped now problem. That's pretty weird. I guess that's something that comes with trying to use tons of RAM in a 32 bit system. I thought the big issue was the need to lock the page(s) during the call, and maybe some tricky races which made the idea difficult. -- The key is realizing the whole world is stupid and being happy anyway http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD - 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 2.6.11.4
+ while (dlen >= 2 && dlen >= data[1] && data[1] >= 2) {
Not that it matters much to me, since I don't have to maintain it, but
couldn't this be:
while (data[1] >= 2 && dlen >= data[1]) {
I think this captures the relationship and priority.
--
http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD
-
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: indirect lcall without `*'
Ahh, okay. I'm just jumpy because this is a production server. Thanks for the answer. :-) -- Nothing can plugh you now http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD - 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/
indirect lcall without `*'
In compiling 2.4.29 I get this during the compilation of pci-pc.c: Warning: indirect lcall without `*' I note from looking around the net that this is an old "problem", dating back at least to 2.4.18, if not earlier. What does it mean? Should I care? If I shouldn't, shouldn't there be a message somewhere in the build process that says "This isn't a problem" so people don't write to lkml and ask about it? Thanks in advance for your time and consideration. -- That which is impossible has become necessary. http://www.hacksaw.org -- http://www.privatecircus.com -- KB1FVD - 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: Cosmetic JFFS patch.
>No 'debug=' could then simply cause the kernel to kprint any info from >drivers/modules that failed to load, else keep schtum. My idea is that the driver announces itself, and then what it has found/initialized, in the minimum number of screen lines possible. I'd want that to be the default, because it gives you a decent idea of where it was if it failed. I am envisioning an algorithm like this: 1. Printk name and version 2. initialize self 3. Hunt for devices, printk when you find one 4. Initialize this device 5. Go back to 3 until you don't detect any more devices 6. Do whatever final thing needs doing Note that I only advocate the two printk's mentioned explicitly. I think this provides just enough of a clue to give one an idea of what might have gone wrong, so you might be able to make a quick fix even before needing to enter a "tell me everything you are doing" mode for debugging. More might be nice, but balance is good. I agree with some folks that this is way too much from some drivers. The giant per CPU tables are an example. That's a useful thing if you are a kernel developer, or are trying to debug something weird, but it too much information for someone like me, who knows the code works most of the time. If I see an error, I'm going to replace the CPU, not write new code. On the other hand, I do like the v for version, etc thing, but I think I would have it like this: v for version i for initiation progress (devices and options) d for debugging (or tell me every major step you take) q for quiet (Just the kernel version and the word "Loading" and a spinner of some sort) s for "shut up shuttin' up!" (Nothing, or maybe some custom module for the embedded installations) Obviously, the last two are exclusive with the first three. I'd make it so including them after the other cancels them, so you could add something temporarily without losing your default. I would default to "vi", no pun intended. - 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: Cosmetic JFFS patch.
Given that seeing as much as possible on a potentially small screen would be good, maybe tighter would be nice. In example: kswapd:v1.8 ptyDevices: 256 Unix98 ptys configured serial:v5.05b (2001-05-03) with Options: MANY_PORTS SHARE_IRQ SERIAL_PCI Devices: ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A rtclock: v1.10d ide: v6.31 net: v4.0 for Linux 2.2, from Swansea University Computer Society NET3.039 Unix domain sockets 1.0 for NET4.0. TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP TCP: Hash tables configured (ehash 524288 bhash 65536) IPv4 over IPv4 tunneling driver early initialization of device tunl0 is deferred AppleTalk 0.18 for NET4.0 My hope would be that the name at the extreme left column would be the name of the module that would be loaded if it were a module, and the name of the main code file of the driver in question. That way, those trying to debug stuff could go right to the appropriate file, and start reading the code or nearby documentation. Of course, the spacing I have above is optimistic, but just making sure that a new driver prints it's version line against the left margin, and everything else a few spaces out would help readability. You might note that I eliminated the word Linux in 5 or 6 places. We know the driver works with Linux if it is booting. On the other hand "vX.X for Linux 2.X" is useful, since it's part of the version number. Your opinion may vary. - 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: GCC3.0 Produce REALLY slower code!
>Apart from questions of optimization, compiling the same code with two >different compilers is a very good way to find bugs, both in the code >and in the compilers. I agree that this is a workable idea. On the other hand, I'd bet Linus would put that idea right up there with shipping a debugger in kernel. If you need to use tricks like that to find bugs, you might not understand your code as well as you should. The optimization angle is an important one. I'd like to see intel's optimizations tested against the kernel, *and then released in gcc*, or something specialized like pgcc. (Anyone know if pgcc ever compiled a good kernel that was notably faster?) Overall, though, I'd bet such optimizations would give no more than a few percentage points of speed overall. The big gains are to be had by serious redesign like the cache change or the zero copy stuff. When your design is mediocre, an optimizing compiler makes the the wrong idea faster. - 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: GCC3.0 Produce REALLY slower code!
Well, I haven't gone and looked at every line of assembler, but I'd bet this is a hasty characterization. According to someones recent count there are around 144000 lines of assembler in the 2.4.2 kernel. It seems to me you'd have to jump through a lot of hoops to test this compiler. Then there's the other question: Why should we test a compiler that seems to be quite proprietary? The invitation indicates it uses FLexLM to manage the license. I somehow doubt Linus or just about anyone else is going to care, save for the folks in Intel, who can do this for themselves just fine. But, hey, I won't try and stop you. Have fun. - 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: GCC3.0 Produce REALLY slower code!
>Here is link to Intel C compiler, that provide really faster code. > >http://developer.intel.com/software/products/compilers/linuxbeta.htm A quote from the site: * Not all of the GNU C language extensions, including the GNU inline assembly format, are currently supported and, due to this, one cannot build the Linux kernel with the beta release of the Intel compilers and the initial product release. - 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: LANANA: To Pending Device Number Registrants
>This is the problem with all sorts of ID-based naming. In this case >the kernel could simply change the conflicting names a bit, >and leave the cleanup to the administrator. (Who probably >is around as he just inserted those disks) NO, NO, NO, NO, NO. The kernel, when asked to report on the disks physically attached to the machine, should report the location and *volume* name. It should never just mount things when there is a conflict. Make the user resolve the conflict immediately by being more specific. Partition names are sacrosanct. They should always work within the relative filesystem. If I have a disk with /, /usr and /var, I want mentions of ../var to work correctly in scripts in usr, assuming I have usr and var mounted into /. - 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: LANANA: To Pending Device Number Registrants
>So what is your solution for preventing a boot failure after disks/partitions >change ? >volume labels/UUID ? As a sys-admin, let me add a vote for this. Having (one day) a prom monitor program that looks at all the disks, and gives a menu of which one to boot from would make life so nice. I very often had to move disks from one platform to another, and changing ID's on the was hard or impossible in some cases, and required in others. Being able to find the disk by a label is a thousand times better. - 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: Not a typewriter
>If clarity is the most important consideration, then other things should be >changed as well. For instance, the command we use to search for text strings in >files should be called "textsearch." That's a lot more clear than "grep." Well, I can't disagree. Unix's biggest turn off was the stupid command names. It's a big reason why Unixoid systems aren't more commonplace. I only learned it because I was stuck at a desk with a Wyse terminal. Otherwise I probably would have played with the Autocad machines more. Once I understood the basics, I understood the power of the system. However, I was a CS major, smart, and a voracious reader. - I have often thought of an alternate naming scheme that would apply to the most basic utilities. With command completion longer names become less annoying. But first we need a better help system. The absolute most stupid convention of Unix is the man command. The fact that SCCS before, and now Bash usurp the keyword "help" is beyond the pale. >If the wording is going to be changed, then it's better to abandon the tradition I say abandon tradition when tradition doesn't serve. Arcane messages prevent understanding, arbitrary command names sometimes can't be avoided. The process is annoying at best, and painful on Linux systems where the documentation isn't unified, and is often incomplete. A beautiful example that came up on my RedHat 6.2 system: [From ppd_file_new_from_filep(3)] ENOTTY no idea what these errors are. Probably PPD parse errors. I run into things like this all the time. "Textsearch" is better than grep, except sometimes you aren't searching through text. "Search" is more general. "Find" would be even better. I wish that find had the functions of grep as well, ala the MacOS "find", which can (these days) search for files names and attributes, and also search for things inside files. >My point is that someone who sees the "typewriter" message and doesn't >understand it will have to dig a bit to find out what it means. All well and good if you have the time. If you are in a business or academic settings, the learning curve is an important part of the total cost of ownership. Ob. LKML: Error messages from the kernel should be examined with this in mind. The more clear that error message is, the less likely we'll see a question about it here. - 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: Not a typewriter
>I disagree. "Not a typewriter" is part of Unix tradition, and ought to be >retained as a historical reference. It's also an opportunity for "the >uninitiated" to learn a little more and move a little closer to becoming "the >initiated." Heaven help us when tradition is more important than clarity. Typewriter has always been wrong. I'd agree that "Not a teletypewriter" would suffice. On the other hand "Inappropriate ioctl for device" is also not very clear. I'd like to see "Not a serial or character device" or "Not a serial device" if that's more appropriate. Something like that... - 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: someody help me out
>I am just a beginner in linux programming and I want to write a >script for disconnecting users in cisco router. This would be the wrong list to ask such a question. It is for the discussion of the inner workings of the Linux kernel, not for questions about applications which can be run on a Linux based system. - 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" terminal type
Look in section 4 of the man pages for entries starting with "console". console console_codes 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: Ideas for the oom problem
> On Wed, Mar 28, 2001 at 06:33:04PM -0500, Hacksaw wrote: > Why are they logged in as root in the first place? Is there something they > can't do over sudo? I have the "Gnome workstation" version of rawhide (7.0.xxx) on my new laptop. I don't see sudo. Of course, it's rawhide, but you'd think, if it were in 7.0, it'd make it. Or maybe they decided that the gnome workstation didn't need it... Hmmm. > I definitely remember seeing a document saying `if you find yourself needing to > `man foo', do it in another terminal as your non-root self'; it might or might > not've been the SAG. Sucks if you are trying to figure out a VT problem. > In any case, what happened to `if you use this rope you will hang yourself'? > There has to be a point where you abandon catering for all kinds of fool and > get on with writing something useful, I think. Let's accept one thing: Root, should in fact, be allowed to do anything a regular user can. The fact that hanging is a possibility might ought to be pointed out. I have my shell set up to tell me I'm root. But the fact is, the typical sys-admin is essentially always logged in as root somewhere, and changing terminals to look at man pages is sometimes not an option. For that matter, I have often figured out that something had funny permission problems by discovering that the problem goes away if I run a program as root. Assuming everything root is doing must be sacrosanct is a pipe dream. Assuming everything a regular user is doing is expendable is BOFH think. I do agree that you have to draw a line. I'm just saying that's the wrong one. > > I completely agree that doing general work as root is a bad idea. I do most > > root things via sudo. It sure would be nice if all the big dists supplied it > > (Hey, RedHat! You listening?) as part of their normal set. > > RH have been listening since v7.0. Good. I hope it comes out well in 7.1, considering my experience with rawhide. - 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: Ideas for the oom problem
> --On Wednesday, March 28, 2001 09:38:04 -0500 Hacksaw <[EMAIL PROTECTED]> > wrote: > > > > Deciding what not to kill based on who started it seems like a bad idea. > > Root can start netscape just as easily as any user, but if the choice of > > processes to kill is root's netscape or a user's experimental database, > > I'd want the netscape to go away. > > root does not use netscape -FULLSTOP- Making assumptions about what users will do is foolish. > Anyone working as root is (sorry) an idiot! root's processes are normally > quite system-relevant and so they should never be killed, if we can avoid > it. The real world intrudes. Root sometimes needs to look at documentation, which, these days is often available as html. Sometimes it's only as html. And people in a panic who aren't trained sys-admins aren't going to remember to log in as someone else. I completely agree that doing general work as root is a bad idea. I do most root things via sudo. It sure would be nice if all the big dists supplied it (Hey, RedHat! You listening?) as part of their normal set. > There can however be processes owned by other users which shouldn't be > killed in OOM-Situation, but generally root's processes are more important > than a normal user's processes. I'd suggest that this is going to change. Not to regular users, though, so it's still a good point. But we should be figuring out how to compartmentalize all our servers. Rarely do most servers need to run as root. Just login ones, and those should be limited. So which should die, the users experiment, or identd? > What about doing something really critical to avoid the upcoming OOM-situ > and get your shell killed because you were to slow? Right. I agree that roots shell should be exempt. It may be that all shells should be exempt, or maybe all recent shells. Better, though, would be to establish the idea of "linchpins". A linchpin is a process marked with a don't kill for OOM flag (a capability?). Only those in root group should be able to start one. And darn few things should be marked as such. Some very small shell, vi, ed, maybe a small emacs. Just enough so that our heroic admin can gracefully ease the OOM situ by changing a few bits of /etc or killing off a few well chosen processes. On the other hand, a flag that says "kill me first" might be even better. In any case, I'd certainly expect the OOM killer to sort by memory usage, and kill off the hogs first. I assume it does that. - 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: Ideas for the oom problem
> a. don't kill any task with a uid < 100 > > b. if uid between 100 to 500 or CAP-SYS equivalent enabled > set it too a lower priority, so if it is at fault it will happen slower > > giving more time before the system collapses Deciding what not to kill based on who started it seems like a bad idea. Root can start netscape just as easily as any user, but if the choice of processes to kill is root's netscape or a user's experimental database, I'd want the netscape to go away. - 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: Index of Kernel Configuration Options
>latest Linux kernel? I am waiting on a kernel mode driver for my USB >digital camera, but I don't want to go ahead and download the full 24Mb For USB stuff, try: http://www.linux-usb.org/ I like the idea of the hardware index, 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: To Linus: kdb in 2.4?
S! Do not nudge sleeping penguin. Here is blow-by-blow of last incident: http://kt.linuxcare.com/kernel-traffic/kt20001002_87.epl#1 - 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: Disk is cheap?
> On Sam, 03 Feb 2001 you wrote: > > Actually, most of that time is spent running bash/sleep 1. Startup > > scripts tend to be poorly designed. > > Yes! I'm not so sure. I'm using RedHat 6.2, and it seems the only time a startup script calls sleep is when it gives you a chance to do interactive startup, and when you are looking for an NIS server. You could certainly remove those. All the other calls to sleep are in the stop sections, where you want to make sure the thing died before proceeding. But paring down the startup scripts is a good idea. For something like an embedded device, you might even want to go with a custom init, that just runs your main program. - 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] Major Clock Drift
>I've discovered that heavy use of vesafb can be a major source of clock >drift on my system, especially if I don't specify "ypan" or "ywrap". On my This is extremely interesting. What version of ntp are you using? - 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] Major Clock Drift
Technical explanations aside, some sort of clock drift exists in all computers. My experience with Sun hardware, for instance, was that the hardware and software clocks rarely agreed. You should set up your machines to use some sort of time synchronization software, such as ntp or rdate. When I didn't have a 24/7 net presence, I had my ppp script run ntpdate when the connection was complete. See http://www.eecis.udel.edu/~ntp/ - 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: unexplained high load
> .nfs00ca40250006 > > so i think there is some lock from the nfs server or client > > will try to restart nfs client > and see if this fixes it. > Most likely you will have to restart the nfs server on the other side as well, but it's worth a try. Tripwire watches the checksum of the binaries you deem important, and complains if they change. There are a few things like it. See http://freshmeat.net/search/?q=tripwire - 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: unexplained high load
Ahh, a D state. D means disk wait, which the only thing that can postpone a -9. Basic, the process is stuck in a loop inside a routine that needs to be atomic. You'll have to reboot to clear it. I believe this is a kernel bug. Try going back to 2.2.14, or maybe up to 2.2.19pre2. - 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: unexplained high load
>don't think >w,uptime,top give the same value The fact that they all give the same value does not indicate that you have not been cracked. Obviously, part of the hacking is to cover trails; it'd be a pretty poor job if they reported different values. The mm stuff from your other message is, I think, an indication that you might be being hit by a memory management bug that was corrected in 2.2.19pre2. It is my sincere belief that you will need to upgrade your kernel, but you are in no serious danger. If it's a firewall box, you should be running tripwire or some free variation, to help eliminate the possibility that cracking would go undetected. - 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: unexplained high load
> Could someone maybe explain this ? > (top output, but same load is given with 'uptime') > there is no cpu or disk activity > kernel is 2.2.18pre9 on sun ultra10-300 (ultrasparc IIi) > >9:25pm up 112 days, 1:52, 1 user, load average: 1.24, 1.05, 1.02 > 91 processes: 90 sleeping, 1 running, 0 zombie, 0 stopped > CPU states: 2.5% user, 2.3% system, 0.0% nice, 95.1% idle > Mem: 515144K av, 506752K used, 8392K free, 73464K shrd, 58472K buff > Swap: 131528K av, 15968K used, 115560K free358904K cached You have no processes??? My gosh, that is a problem. :-) The load average is how many processes are runnable, therefore you have runnable processes. If you have Netscape or Mozilla running on your box, it may be in a permanently runnable state. Another amusing possibility is that you have a hacked box, and top is reporting the stupid IRC bot that is running, but not showing you the actuall process, because it too is hacked. Replace ps and top, and have a look. Don't believe ls, either. If none of these things are true, you might have another problem. - 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: Topic for discussion: OS Design
> Another linux caveat. Scads of undocumented and virtually undiscoverable > behaviours :-) Undiscoverable? You have the source code, what more do you want? Start documenting! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.17 memory bug?
I apologize if this is a known issue. I am running Linux version 2.2.17 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #2 SMP Sun Oct 8 02:37:43 EDT 2000 On a dual Pentium III with 256M of SDRAM, aix-7xxx, sblive, kingston tulip, 3c905, 3dfx Voodoo3 AGP. It seems to run out of memory pretty quickly if I have much to do with netscape, and especially mozilla. This in and of itself is not surprising, I expect bad things from alphaware. However, if I quit the processes, I don't seem to get the memory back. I run two X servers on virtual consoles, each take up about 65M - 70M. I am led to understand that part of this is the memory mapping from the video card, which has 16M. Then the netscapes take up between 30 and 40M. If I run mozilla, I end up with 4 processes claiming to have 23M a piece. I am guessing this is really shared memory threads, or at least I hope so. If I quit all of them, bag mozilla, bag netscapes, bag the X servers, my memory foot print drops to about 192M from 262M. So I stop swapping. It never gets down near to the 95M or so of the regular boot footprint, yet the other processes don't seem to claiming any more memory. If anyone could shed some light on this, I'd appreciate it. I am interested in a very stable kernel, as this is a mailhost and web server. Thanks folks. The machine boot - 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/
