Re: Status of ReiserFS + Journalling
On Thu, Oct 05, 2000 at 01:54:59PM +1100, Neil Brown wrote: > 2/ Arrange your filesystem so that you write new data to an otherwise >unused stripe a whole stripe at a time, and store some sort of >chechksum in the stripe so that corruption can be detected. This >implies a log structured filesystem (though possibly you could come >close enough with a journalling or similar filesystem, I'm not >sure). You don't need a checksum I think, just an atomically updated fs block -> actually stripe map would be enough. It can be only updated after you wrote the new independent stripe completely. Simply using ordered writes for it (only write map after you wrote stripe) may be tricky though, because you could get cyclic dependencies in a single HW map block when the file system allocates many new stripes in parallel [so you would probably need something like soft updates and handling of multiple versions of the map in core] Another method when you have a logging fs is to simply log the map block change into your normal log. At least for ext3 and reiserfs it would be expensive though, because they can only log complete changed hardware blocks of the map. JFS or XFS with item logging could do it relatively cheaply. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] test9: another vm lockup bug - squashed
Hi,
This is applicable on Riels latest addition.
(freepages v. zone->"limit")
That is probably not needed, and you should be able
to change your limits with this patch.
This patch adds equality check in several comparisons.
It is strictly only the one in __alloc_pages_limit
that is needed, it interacts with the test in
free_shortage. Without this patch you get stuck on
exactly zone->pages_min. Too few pages to alloc and
too many to free...
Ying Chen has reported that this patch cures his problem.
/RogerL
--
Home page:
http://www.norran.net/nra02596/
--- linux/mm/page_alloc.c.orig Wed Oct 4 21:27:41 2000
+++ linux/mm/page_alloc.c Wed Oct 4 21:32:17 2000
@@ -268,7 +268,7 @@ static struct page * __alloc_pages_limit
water_mark = z->pages_high;
}
- if (z->free_pages + z->inactive_clean_pages > water_mark) {
+ if (z->free_pages + z->inactive_clean_pages >= water_mark) {
struct page *page = NULL;
/* If possible, reclaim a page directly. */
if (direct_reclaim && z->free_pages < z->pages_min + 8)
@@ -329,7 +329,7 @@ struct page * __alloc_pages(zonelist_t *
* wake up bdflush.
*/
else if (free_shortage() && nr_inactive_dirty_pages > free_shortage()
- && nr_inactive_dirty_pages > freepages.high)
+ && nr_inactive_dirty_pages >= freepages.high)
wakeup_bdflush(0);
try_again:
@@ -347,7 +347,7 @@ try_again:
if (!z->size)
BUG();
- if (z->free_pages > z->pages_low) {
+ if (z->free_pages >= z->pages_low) {
page = rmqueue(z, order);
if (page)
return page;
Re: Tux2 - evil patents sighted
Eirik Fuller wrote: > Is that really your email address? No, but my email address can easily be contructed putting together my last name and innominate.de. > I work at Network Appliance. I hate patents. I can't find anything in > your position on patents that I disagree with. I tried to be as accurate as I could. > I have seriously considered writing a patent rant for my web page > (http://hackrat.com/). Would you like to help? I have no objection to > making my connection with NetApp a highly visible part of my rant. Yes, by all means. You are not the first to ask permission to use my rant. I don't need credit for it; if it does some good, that is enough. > I've fallen behind on the Linux kernel email archives (I just got back > from a long weekend), but I would have seen your message eventually, > after I started catching up. As it happens, I found it because there > was internal discussion of your message here at NetApp. Dave Hitz > thinks that if NetApp leaves you alone, you'll go away. He thinks wrongly. There is no chance of that. > Steven Kleiman > presumes the correct strategy is to go after those who attempt to > distribute it commercially rather than going after you (he doesn't spell > out what he means by "it", but I assume your code). I won't accept *any* form of restriction on what I do with it, for two reasons: 1) I dreamed this up several years before you guys did 2) Patents are evil I'm not sure which one matters more to me. They both do. I'd like to reply to every point in your post, it's all interesting, but I should not, because I have a very simple point to make now: Netapp has a lot more to gain by doing the right thing now and releasing these patents under a GPL-compatible license than by trying to preserve their government-granted monopoly on the ideas. Please do the right thing. Does Walmart have a patent on their business process? No. Does Walmart make tons of money? Yes. Why? Because they give people what they need, in the most efficient way, and they make their customers feel *good* while they're doing it. That way of making money works, and I could swear that it works better than patent-aided extortion does. Netapp does not need the protection of patents to make money. If anybody does need such protection, then that is because they are lame and useless. Netapp will make more money by capitalizing on the goodwill and PR resulting from a high-profile giveaway then they ever would by forestalling competition with their patent. And it is not clear at all that these particular patents can be successfully used to forestall competition, either from free or commercial software. If Netapp opens up, Netapp can be known as the friend of the Linux community. I think that translates more or less directly into dollars. > If you'd like to contact me outside of NetApp, you can use the mailto > link in http://hackrat.com/resume.html (but feel free to use my NetApp > address too). I certainly will, and perhaps I will see you in Atlanta next week, and later in Miami. I would look forward to it. -- Daniel - 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 v2.4.x] Yet Another Boot Logo
Gábor Lénárt <[EMAIL PROTECTED]> wrote: > IMHO, 2 lines are not enough. It should be costumizable setting. It'll be in the next patch. (in a day or so) > (If you're crazy enough :) you can use settings to set X,Y offset and > X,Y size of window for "text", and you can get illusion to boot in > a window of logo has border around the used window ;-) I don't think I'm crazy enough for that. ;-) > And a question: will memory used by Linux logo be freed after hiding it ? It's marked as __initdata, so yes, all of that memory is freed immediately before /bin/init is execed. -- Jason McMullan, Senior Linux Consultant, Linuxcare, Inc. 412.422.8077 tel, 412.656.3519 cell, 415.701.0792 fax [EMAIL PROTECTED], http://www.linuxcare.com/ Linuxcare. Support for the revolution. - 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/
Happy 9th Anniversary, Linux !
On Oct-05-1991, Linux was announced to the world. It has been nine long years since, and look what Linux has turned out to be? Congratulations on your 9th Anniversary, Linux ! Many thanks to all those who have contributed to the development of Linux ! Lee - 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/
Phase tree algorithm defined
I have finally produced something resembling a formal definition of the phase tree algorithm. As you will see, this algorithm is somewhat subtle, and not easy to express in clear simple terms. But I think that I have in fact expressed it clearly in simply. If I have not, I wish very much to be told so, and why. You can get a copy here: http://innominate.org/~phillips/tux2/phase.tree.algorithm.txt Please, if you are especially anal and nasty and have little regard for anyone's feelings, read this and complain about every little thing that is wrong with it, and I will greatly appreciate that. I will also appreciate comments of the form 'you left out this or that', or 'this part sounds like so much bafflegab' and so on. Enjoy. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test9
From: "Albert D. Cahalan" <[EMAIL PROTECTED]> Date: Thu, 5 Oct 2000 00:23:33 -0400 (EDT) David S. Miller writes: > These items are specifically placed into the data section, not the > BSS, because these alignment games are not possible in the BSS. That would mean the BSS needs support alignment games. The problem is it doesn't work, please go try it. So until it does work, I am going to revert this change. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: aaaah! complete lockup 2.4.0-test9 SPARC32
> I just had my box completely lock up under 2.4.0-test9. I had insmodded > the dbri.o audio driver, which for some reason was refusing to work, at > all. So I rmmodded it, and at that point, the screen flickered once and > wham, complete lockup, nothing responds at all, no network, no SysRQ, > anything...Not even an oops printed to the screen. > > Machine: > SPARCstation 20, 1xTMS390Z55 50MHz SuperSPARC II w/1MB SuperCACHE > 48MB RAM, about 9G total disk space spanned over 3 drives, TGX... Short answer: don't use the dbri module :) It is buggy and requires someone to fix it. Anton - 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: kapmd cpu usage
Rik writes: > On Wed, 4 Oct 2000, Stephen Rothwell wrote: >> Seriously, the kapmd is doing the job of yje idle loop. The >> processor is almost always asleep, but the time just gets >> accounted to kapmd. > > I have the idea we should really fix this dirty accounting > thing and properly account kapmd time to idle time. The easy answer: rename "kapmd" to "IdleTask". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test9
David S. Miller writes: > These items are specifically placed into the data section, not the > BSS, because these alignment games are not possible in the BSS. That would mean the BSS needs support alignment games. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 module sd.o didn't get installed
Lee Mitchell wrote: > Compiled 2.4.0-test9 with an aic7xxx card (all scsi stuff compiled as > modules). > > make modules_install did not install the module sd.o as i found out when > rebooting. The scsi disk (sd) module has been named "sd_mod.o" for some time but in July this year in the development kernels it was accidentally renamed "sd.o" . It has now reverted to its former name. Doug Gilbert - 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.4.0-test9 ipv6 module refcount problem?
known bug? xanadu:/home/brendan# modprobe ipv6 xanadu:/home/brendan# cat /proc/modules ipv6 142240 -1 es1370 26192 1 (autoclean) r128 70848 1 nfsd 67344 8 (autoclean) xanadu:/home/brendan# -- Don't make Godzilla mad! PGP signature
Would you help me ...?
Dear: My kernel is 2.2.5-15. I am studying buffer.c . And I can not understand the relation or difference between generic_readpage() and getblk(). When I read a data file through a process they both are called . But I don't understand their order,relation,difference. Would you please help me ? Thanks. Best Wishes! yours Huang QingHua [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Status of ReiserFS + Journalling
On Wednesday October 4, [EMAIL PROTECTED] wrote: > Andi Kleen wrote: > > On Wed, Oct 04, 2000 at 01:42:46AM -0600, Andreas Dilger wrote: > > > You should ask the reiserfs mailing list for outstanding problems. As > > > far as LVM is concerned, I don't think there is a problem, but watch out > > > for software RAID 5 and journalling filesystems (reiser or ext3, at least > > > under 2.2) - it can have problems if there is a disk crash. > > > > It is not inherent to journaling file systems, linux software raid 5 > > can always corrupt your data when you have a system crash with a disk > > crash (no way to write stripe sets atomically and half writen strip sets > > usually give random data for any crashed block in it when xored against parity) > > 'Atomic' - a word that makes my ears perk up. Tux2 is all about atomic > updating. Could you please give a simple statement of the problem for a > person who doesn't know much more about RAID than that it stands for > Redundant Array of Inexpensive Disks (Drives?) [that's I == "independant" these days. You are allowed to use expensive devices] Stepping in infront of Andi (you aren't a bus are you?) For RAID5 a 'stripe' is a set of blocks, one from each underlying device, which are all at the same offset within their device. For each stripe, one of the blocks is a "parity" block - though it is a different block for each stripe (parity is rotated). Content of the parity block is computed from the xor of the content of all the other (data) blocks. To update a data block, you must also update the parity block to keep it consistant. For example, you can read old partity block, read old data block, compute newparity = oldparity xor olddata xor newdata and then write out newparity and newdata. It is not possible (on current hardware:-) to write both newparity and newdata to the different devices atomically. If the system fails (e.g. power failure) between writing one and writing the other, then you have an inconsistant stripe. A raid5 array has a 'superblock' which can contain a number of things. One of which is a flag to indicate that all stripes are consistant. When a raid5 array is made writable, this flag is cleared. When it is reverted to readonly (e.g. at shutdown) this flag is set after all other writes have completed. At initialisation time, the raid5 system checks this flag. If it is clear, then all stripes must be checked for consistancy. We go through computing parity and comparing with the current parity and writing it out if there is a difference. But, suppose at initialisation time: - The flag is clear, so some stripes might be inconsistant. - One drive has failed. In this state we cannot check consistancy. Is that a problem? We might have lost data, but you do that when systems crash Suppose, for stripe X the parity device is device 1 and we were updating the block on device 0 at the time of system failure. What had happened was that the new parity block was written out, but the new data block wasn't. Suppose further than when the system come back, device 2 has failed. We now cannot recover the data that was on stripe X, device 2. If we tried, we would xor all the blocks from working devices together and I hope that you can see that this would be the wrong answer. This poor, innocent, block, which hasn't been modified for years, has just been corrupted. Not good for PR. > > Given a clear statement of the problem, I think I can show how to update > the stripes atomically. At the very least, I'll know what interface > Tux2 needs from RAID in order to guarantee an atomic update. From my understanding, there are two ways to approach this problem. 1/ store updates to a separate device, either NV ram or a separate disc drive. Providing you write address/oldvalue/newvalue to the separate device before updating the main array, you could be safe against single device failures combined with system failures. 2/ Arrange your filesystem so that you write new data to an otherwise unused stripe a whole stripe at a time, and store some sort of chechksum in the stripe so that corruption can be detected. This implies a log structured filesystem (though possibly you could come close enough with a journalling or similar filesystem, I'm not sure). Basically, as restart time you need to be able to find where you last wrote data, and check if it is valid or not. If Tux2 can do that, then you probably only need to get stripe-size and some sort of 'help-me-out-here' call from the raid software. > > > In this case "safe" just means that you don't need a fsck to be sure that > > the metadata is consistent -- data is never guaranteed to be consistent > > unless you have applications that use fsync/O_SYNC properly (=basically do > > their own journaling) > > I truly believe that's a temporary situation. I actually think that it is worse than that. Without a 'start-transaction / end-transaction'
What I miss for test9? dead network
Booting up 2.4.0-test9 results in my network being unusable due to routes not being setup right. Booting back test7 or 8 and its back to normal. I don't see anything in the Changes file that referances anything I need to upgrade and everything on my system is either at the level required or newer. Can supply more info as required and just didn't want to spam the list with my config info. remove nospam to reply to me directly - 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/
aaaah! complete lockup 2.4.0-test9 SPARC32
I just had my box completely lock up under 2.4.0-test9. I had insmodded the dbri.o audio driver, which for some reason was refusing to work, at all. So I rmmodded it, and at that point, the screen flickered once and wham, complete lockup, nothing responds at all, no network, no SysRQ, anything...Not even an oops printed to the screen. Machine: SPARCstation 20, 1xTMS390Z55 50MHz SuperSPARC II w/1MB SuperCACHE 48MB RAM, about 9G total disk space spanned over 3 drives, TGX... Lemme know if you need more info. Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
{PATCH] Re: wasting time on page fault
Mikulas Patocka wrote: > > Hi. > > arch/i386/kernel/entry.S > xchgl %eax, ORIG_EAX(%esp) # orig_eax (get the error code. ) > movl %esp,%edx > xchgl %ecx, ES(%esp)# get the address and save es. > pushl %eax # push the error code > > xchg with memory operand has implicit lock prefix and is slooow. It is Here is a patch that removes the xchg instructions. As an interesting note, I tested the difference in cycles between one xchgl and two movl instructions on 3 different processors (a Celeron, a K6-2, and an Athlon, all UP). The celeron and K6-2 showed noticable improvements. The real surprise was the the Athlon, where the times were identical. This means that either the Athlon has a really fast lock cycle or it is ignoring it. -- Brian Gerst diff -urN linux-2.4.0t9/arch/i386/kernel/entry.S linux/arch/i386/kernel/entry.S --- linux-2.4.0t9/arch/i386/kernel/entry.S Tue Oct 3 20:05:10 2000 +++ linux/arch/i386/kernel/entry.S Wed Oct 4 20:17:09 2000 @@ -305,16 +305,18 @@ pushl %ebx cld movl %es,%ecx - xchgl %eax, ORIG_EAX(%esp) # orig_eax (get the error code. ) + movl ORIG_EAX(%esp), %esi # get the error code + movl ES(%esp), %edi # get the function address + movl %eax, ORIG_EAX(%esp) + movl %ecx, ES(%esp) movl %esp,%edx - xchgl %ecx, ES(%esp)# get the address and save es. - pushl %eax # push the error code - pushl %edx + pushl %esi # push the error code + pushl %edx # push the pt_regs pointer movl $(__KERNEL_DS),%edx movl %edx,%ds movl %edx,%es GET_CURRENT(%ebx) - call *%ecx + call *%edi addl $8,%esp jmp ret_from_exception
Re: May I ask you some question
> Huang QingHua wrote: > > Dear: > May I ask you some question? > 1.I try to make a filesystem. But if my block size have to be 1M > ,then what should I do ? Or is it possible? I'm not sure why you'd want a block size of 1M, most block sizes tend to be between 512 bytes and 4K. > 2.When to reading a hardware page from disk and when to read a > block from disk? Is there a order between them? just for a easy > example. When I want to read a big file ,It seems to use getblk > function (from my studying source code...) ,Is it right? When is > reading a page called. For an ordinary filesystem, I think you'd always want to read a block from disk. Pages generally refer to memory (as in RAM or swap space), not hard disk space, so I suppose you'd load a page from disk if you were doing a virtual memory filesystem (but from your description it sounds like you're doing an ordinary filesystem). - 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: TODO list for new VM (oct 2000)
:On Mon, 2 Oct 2000, Rik van Riel wrote: :> On Mon, 2 Oct 2000, Linus Torvalds wrote: :> :> > Why do you apparently ignore the fact that page-out write-back :> > performance is horribly crappy because it always starts out :> > doing synchronous writes? :> :> Because it is fixed in the patch I mailed yesterday? : :One small warning though. Please don't apply that patch :yet because I fixed 3 more small problems today. I'll :send you an updated patch... :... :regards, : :Rik My experience with FreeBSD's asynchronous paging is that you have to carefully limit the number of I/O's you queue at once. Or, more specifically, you have to limit the seeking load the async pageouts place on the system. The performance curve from the point of user processes in the system looks like a bell, while the paging performance looks like a log curve (increased performance with diminishing returns)... if you queue too few pages (degenerate into synchronous paging), you have low paging performance and high user process performance, but you can't clean pages fast enough in a heavily loaded system. If you queue too many pages at once, you have high paging performance (but with diminishing returns) and low user process performance due to the seeking load you've placed on the disk. Excessive seeking from pageouts will ruin the disk's performance from the point of view of other processes in the system. FreeBSD has a sysctl variable called vm.max_page_launder which limits the number of pages the pageout daemon will queue to I/O at once. The default is 32. Numbers between 16 and 32 were found to fit the sweet spot of the curve the best. Numbers lower then 16 reduced system performance because potentially contiguous pageouts would get split (causing more seeking rather then less when mixed with I/O initiated from user processes), and numbers higher then 32 reduced user process performance due to the additional seeking from the queued pageouts. The sysadmin can adjust the value to effectively give paging more or less priority. A smaller number reduces paging performance but increasing system performance for other processes (though anything less then 4 will reduce performance for everyone). A higher number increases paging performance at the cost of system performance for other processes. Virtually all FreeBSD installations that I know about leave the sysctl variable alone. Note that the performance bell holds true whether you sort disk requests or not, the whole bell simply moves up or down on the graph. There are a number of things that can be done to mitigate the seeking issue, which I discussed with Rik a few months ago. The jist of it, though, is that there is a trade-off between page-in and page-out performance based on how you try to cluster swap allocation. FreeBSD clusters swap allocations to optimize page-out performance at the cost of page-in performance and that seems to work very well under heavy system loads. -Matt Matthew Dillon <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
May I ask you some question
Dear: May I ask you some question? 1.I try to make a filesystem. But if my block size have to be 1M ,then what should I do ? Or is it possible? 2.When to reading a hardware page from disk and when to read a block from disk? Is there a order between them? just for a easy example. When I want to read a big file ,It seems to use getblk function (from my studying source code...) ,Is it right? When is reading a page called. Would you help me again? Thank you very much! best wishes! yours Huang QingHua [EMAIL PROTECTED]
Re: linux-2.4.0-test9
Date:Tue, 3 Oct 2000 09:43:35 -0700 (PDT) From: Linus Torvalds <[EMAIL PROTECTED]> - pre8: - initialize to zero -> put it in the .bss instead Can the person who made these changes in tcp_ipv4.c talk to me? That particular instance screwed up all the cache line games I was playing there for the hash tables and locks. The "__tcp_clean_cacheline_pad" sitting around these changes should have been a clue that something more clever than usual was going on here. These items are specifically placed into the data section, not the BSS, because these alignment games are not possible in the BSS. This kind of stuff is why I like networking changes to go through me whenever possible, to catch these sorts of misunderstandings. Alas I was away for a week, so this time it slipped through :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Weightless process class
It dost seem to me that even when the process is not in the kernel, it could hold other sorts of fs locks. Also, what if the process is caught in a signal handler? Couldn't you end up being unable to kill the thing in an overactive system? -- This message has been brought to you by the letter alpha and the number pi. David Feuer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
patch installation
Hi, I am installing a RAID patch to my present kernel which is 2.2.12. This is the procedure I am following: 1.I get the patch file in /usr/src/linux 2. #patch -p1 < patchfilename After this is done it asks me something like this: Already available . creating a patch file /usr/src/ And asks me to use Assume -R[n] what does Assume -R[n] mean , what should I do? I went further & tried as n , thinking it as normal operation. It creates a .rej file I patched some files manually by looking at .rej file and some were done by patch command. Now after I do : make bzImage I get many compilation errors . Ex: member not avialable in struct This member & structure are available only in the patch file, but not in the file which is modified after the patch & not available in .rej too. I dont know whats happenning? with regards, Anil __ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Weightless process class
On Thu, 5 Oct 2000, Matti Aarnio wrote: > On Wed, Oct 04, 2000 at 06:16:57PM -0300, Rik van Riel wrote: [priority inversion] > > We don't need that. > > > > We just need one boolean per thread ... is it holding a kernel > > lock or not? > > The BKL or *any* (kernel) lock ? > > For my knowledge there is no limitation on how many > locks a thread can hold. Having a single bool might > not be enough. A counter is better ? On return_to_userspace, you /know/ the thread has released the kernel locks. Though this might not work for IPC semaphores... Then again, if the Montavista people (maybe together with SGI or IBM folks?) can get a light-weight priority inversion scheme working, then we'll have everything right ;) > > If it is, make sure its scheduling latency isn't too high. > > e.g. all processes having *any* locks are raised to the highest > possible class to make sure they are not starved out ? SCHED_OTHER is enough for most purposes. OTOH, you could have one SCHED_FIFO process block execution of a higher priority SCHED_FIFO process that wants a lock ... priority inversion anyway? > > If it isn't holding any lock, we can do with it what we want, > > including completely starving the task for several seconds > > (or even minutes) if scheduling latency or VM pressure warrants > > it. > > Yes, that is obvious. *grin* regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Weightless process class
On Wed, 4 Oct 2000, Rik van Riel wrote: > On Wed, 4 Oct 2000, LA Walsh wrote: > > > I had another thought regarding resource scheduling -- has the > > idea of a "weightless" process been brought up? > > Yes, look for "idle priority", etc.. > It also turned out to have some problems ... > > > Weightless means it doesn't count toward 'load' and the class > > strictly has lowest priority in the system and gets *no* CPU > > unless there are "idle" cycles. So even a process niced to -19 > > could CPU starve a weightless process. > > One problem here is that you might end up with a weightless > process having grabbed a superblock lock, after which a > normal priority CPU hog kicks in and starves the weightless > process. > > The result is that that superblock lock never gets released, > and everybody needing to grab that lock blocks forever, even > if they have a higher priority than the CPU hog that's starving > our idle process... > > The solution to this would be only starve these processes > when they are in user space and can no longer be holding > any kernel locks. The general solution, which SGI implements in IRIX, is to implement priority inheritance for blocking locks. So the weightless process gets the priority of the blocked process until it releases the lock. IRIX multi-reader semaphores initially did not implement priority inheritance, until this type of starvation scenario occured! I'm working on making the linux kernel fully preemptible (as I did for IRIX when I used to work at SGI), and will need priority inheritance mutexes to enable real-time behavior for SCHED_FIFO and SCHED_RR tasks. So someone at MontaVista will be looking at this in the 2.5 timeframe. Nigel Gamble [EMAIL PROTECTED] www.mvista.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: execve replacement.
Abel Muñoz Alcaraz wrote: > I have replaced the execve() kernel [syscall] > with my own implementation but it doesn't work well. In Linux, hooking into sys_call_table[] is a pretty painful way to interpose on system calls. Unfortunately, there's no other way to do it (in Linux) that I know of... Your problem at the moment is that sys_execve() is implemented with an ugly hack. Usual C call-by-value semantics would give you a private copy of the struct argument. However, sys_execve() is declared with the "asmlinkage" keyword, so in this case you get passed a struct _which is aliased to the argument the caller passed_, and the implementation of sys_execve() relies on this fact. This optimization makes it really painful to wrap sys_execve() in the natural way. The solution is to cut-and-paste code ... but don't expect it to be architecture-independent (argh!). I think the sigreturn() and rt_sigsuspend() system calls have similar issues. Probably the next few things you'll run into are: - If you want to install a hook (a function) that gets called when a process dies, it's very difficult. - If you want to keep extra per-process state reliably, it's difficult. - If you want to examine system call arguments, it's difficult. - If you want to interpose on sys_socketcall(), you may have to cut-and-paste code from the implementation of sys_socketcall(). Oh, how I wish Linux provided a cleaner, architecture-independent interface for system call interposition... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Support for CS89x0 based PCMCIA cards
Hi, Oops. I forgot the patch. Peter. diff -u --new-file -x *.o -x .* linux.old/drivers/net/pcmcia/Config.in linux/drivers/net/pcmcia/Config.in --- linux.old/drivers/net/pcmcia/Config.in Sun Aug 13 19:21:20 2000 +++ linux/drivers/net/pcmcia/Config.in Sun Sep 24 19:02:19 2000 @@ -15,6 +15,7 @@ dep_tristate ' SMC 91Cxx PCMCIA support' CONFIG_PCMCIA_SMC91C92 $CONFIG_PCMCIA dep_tristate ' Xircom 16-bit PCMCIA support' CONFIG_PCMCIA_XIRC2PS $CONFIG_PCMCIA dep_tristate ' COM20020 ARCnet PCMCIA support' CONFIG_ARCNET_COM20020_CS $CONFIG_ARCNET_COM20020 $CONFIG_ARCNET $CONFIG_PCMCIA + dep_tristate ' IBM EtherJet support' CONFIG_PCMCIA_CS89X0 if [ "$CONFIG_IBMTR" != "y" ]; then dep_tristate ' IBM PCMCIA tokenring adapter support' CONFIG_PCMCIA_IBMTR $CONFIG_TR $CONFIG_PCMCIA fi diff -u --new-file -x *.o -x .* linux.old/drivers/net/pcmcia/Makefile linux/drivers/net/pcmcia/Makefile --- linux.old/drivers/net/pcmcia/Makefile Sun Aug 6 20:23:40 2000 +++ linux/drivers/net/pcmcia/Makefile Wed Sep 27 17:09:17 2000 @@ -27,6 +27,7 @@ obj-$(CONFIG_PCMCIA_SMC91C92) += smc91c92_cs.o obj-$(CONFIG_PCMCIA_XIRC2PS) += xirc2ps_cs.o obj-$(CONFIG_ARCNET_COM20020_CS)+= com20020_cs.o +obj-$(CONFIG_PCMCIA_CS89X0) += cs89x0_cs.o # 16-bit wireless client drivers obj-$(CONFIG_PCMCIA_RAYCS) += ray_cs.o diff -u --new-file -x *.o -x .* linux.old/drivers/net/pcmcia/cs89x0_cs.c linux/drivers/net/pcmcia/cs89x0_cs.c --- linux.old/drivers/net/pcmcia/cs89x0_cs.cThu Jan 1 01:00:00 1970 +++ linux/drivers/net/pcmcia/cs89x0_cs.cWed Oct 4 23:22:51 2000 @@ -0,0 +1,1683 @@ +/* cs89x0.c: A Crystal Semiconductor (Now Cirrus Logic) CS89[02]0 + * driver for linux. + */ + +/* + Written 1996 by Russell Nelson, with reference to skeleton.c + written 1993-1994 by Donald Becker. + + This software may be used and distributed according to the terms + of the GNU Public License, incorporated herein by reference. + +The author may be reached at [EMAIL PROTECTED], Crynwr +Software, 521 Pleasant Valley Rd., Potsdam, NY 13676 + + Changelog: + + Mike Cruse: [EMAIL PROTECTED] +: Changes for Linux 2.0 compatibility. +: Added dev_id parameter in net_interrupt(), +: request_irq() and free_irq(). Just NULL for now. + + Mike Cruse: Added MOD_INC_USE_COUNT and MOD_DEC_USE_COUNT macros +: in net_open() and net_close() so kerneld would know +: that the module is in use and wouldn't eject the +: driver prematurely. + + Mike Cruse: Rewrote init_module() and cleanup_module using 8390.c +: as an example. Disabled autoprobing in init_module(), +: not a good thing to do to other devices while Linux +: is running from all accounts. + + Russ Nelson : Jul 13 1998. Added RxOnly DMA support. + + Melody Lee: Aug 10 1999. Changes for Linux 2.2.5 compatibility. +: email: [EMAIL PROTECTED] + + Alan Cox : Removed 1.2 support, added 2.1 extra counters. + + Andrew Morton : [EMAIL PROTECTED] +: Kernel 2.3.48 +: Handle kmalloc() failures +: Other resource allocation fixes +: Add SMP locks +: Integrate Russ Nelson's ALLOW_DMA functionality back in. +: If ALLOW_DMA is true, make DMA runtime selectable +: Folded in changes from Cirrus (Melody Lee +: <[EMAIL PROTECTED]>) +: Don't call netif_wake_queue() in net_send_packet() +: Fixed an out-of-mem bug in dma_rx() +: Updated Documentation/cs89x0.txt + + Andrew Morton : [EMAIL PROTECTED] / Kernel 2.3.99-pre1 +: Use skb_reserve to longword align IP header (two places) +: Remove a delay loop from dma_rx() +: Replace '100' with HZ +: Clean up a couple of skb API abuses +: Added 'cs89x0_dma=N' kernel boot option +: Correctly initialise lp->lock in non-module compile + + Andrew Morton : [EMAIL PROTECTED] / Kernel 2.3.99-pre4-1 +: MOD_INC/DEC race fix (see +: +http://www.uwsg.indiana.edu/hypermail/linux/kernel/0003.3/1532.html) + + Peter De Schrijver: [EMAIL PROTECTED] + : changes to support PCMCIA + +*/ + +static char *version = +"cs89x0.c: v2.3.99-pre1-2 Russell Nelson <[EMAIL PROTECTED]>, Andrew Morton +<[EMAIL PROTECTED]>\n"; + +/* === end of configuration === */ + + +/* Always include 'config.h' first in case the user wants to turn on + or override something. */ +#ifdef MODULE +#include +#include +#else +#define MOD_INC_USE_C
Re: VM in v2.4.0test9
Ok, those two patches (well, I applied both, so I can't decide which was the triggering factor) makes the system able to deplete the swap before hanging. Thus, things are fine, right?! I just hope that we can get a decent OOM-killer now. Two other considerations, which I remember have been discussed in this forum before (I can't remember what was said, though): Why does the kernel overcommit even if overcommit is turned off via /proc/sys/vm/overcommit_memory? And, why oh why, can't we implement SIGDANGER just like AIX. This has to be one of the smartest things with AIX mm (for those not into AIX: when the system runs low on memory, every program receives the signal DANGER. If the processes does not catch this signal, they get killed if the memory runs out. If they catch it, they can chose to flush their buffers and other other non-critical data. The OOM-killer will still kill processes which catch DANGER if REALLY needed, but it will start with those that does not catch DANGER.) /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
CDROM/STREAMS ioctl conflicts
Hi,
I encountered an ioctl conflict when attempting detect to STREAMS
support in glibc 2.1.94 via a configure script test. The
[EMAIL PROTECTED] mailing list suggested that I post the bug report I
posted there to this list. It is listed below.
Ossama Othman wrote:
>
> Hi,
>
> Conflicts exist between glibc 2.1.94's STREAMS ioctls and the Linux
> kernel's CDROM ioctls.
>
> In :
>
> /* Macros used as `request' argument to `ioctl'. */
> #define __SID ('S' << 8)
>
> #define I_NREAD (__SID | 1) /* Counts the number of data bytes in the data
>block in the first message. */
> #define I_PUSH (__SID | 2) /* Push STREAMS module onto top of the current
>STREAM, just below the STREAM head. */
> #define I_POP (__SID | 3) /* Remove STREAMS module from just below the
>STREAM head. */
> .
> .
> .
>
> In (in both the 2.2.x and the 2.4-pre kernels):
>
> /***
> * The CD-ROM IOCTL commands -- these should be supported by
> * all the various cdrom drivers. For the CD-ROM ioctls, we
> * will commandeer byte 0x53, or 'S'.
> ***/
> #define CDROMPAUSE 0x5301 /* Pause Audio Operation */
> #define CDROMRESUME 0x5302 /* Resume paused Audio Operation */
> #define CDROMPLAYMSF0x5303 /* Play Audio MSF (struct cdrom_msf) */
> .
> .
> .
>
> I encountered this problem when attempting to set the I_SRDOPT ioctl
> to RMSGN. ioctl() returned with an EINVAL error.
>
> Running strace revealed that the CDROMREADTOCENTRY ioctl was used
> instead of I_SRDOPT.
The original post is at:
http://mail.gnu.org/pipermail/bug-glibc/2000-October/000191.html
TIA!
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
-
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: PIIX4-ide still not working in 2.4-test9...
Time to bug Andre :) -d Bruno Boettcher wrote: > On Wed, Oct 04, 2000 at 01:53:34AM -0700, David Ford wrote: > > When you enable PIIXn support in the IDE section, make sure you DISABLE PIIXn > > tuning which is the very next line. > ok i even tryed with a freshly downloaded complete 2.4-test9 tree. > nothing to do: just before init comes, i get: > > ide_dmaproc: chipset supported ide_dma_lostirq func only : 13 > > any other hint i could try? > nice that this non-working kernel is called test but i suspect that > the final version will not run either on my laptop :( -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Support for CS89x0 based PCMCIA cards
Hi *, Attached you will find a patch which adds support for CS89x0 base PCMCIA cards such as the IBM EtherJet. The code is based on the existing CS89x0 driver. Tests where done on an IBM A20m with the IBM EtherJet card. Future improvements include better integration with the non PCMCIA CS89x0 code and patches for other cards based on the same chipset. Cheers, Peter. - 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/
ppa driver failure in 2.4.0-test8 (fwd)
I sent this to the maintainer of the ppa driver some time ago, and have received no response. Please CC me on replies, I'm not on the list. -- -Matt SNAPPY REPARTEE: What you'd say if you had another chance. -- Forwarded message -- Date: Sat, 16 Sep 2000 20:40:26 -0400 (EDT) From: Matthew Gabeler-Lee <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: ppa driver failure in 2.4.0-test8 I have a relatively old ZIP drive (well back into the ppa era). I recently upgraded to 2.4.0-test8 from 2.4.0-test7, and the ppa driver now no longer seems to work properly. When I load the drier, the following gets put in the syslog: kernel: ppa: Version 2.05 (for Linux 2.2.x) kernel: ppa: Found device at ID 6, Attempting to use EPP 32 bit kernel: ppa: Communication established with ID 6 using EPP 32 bit kernel: scsi1 : Iomega VPI0 (ppa) interface kernel: scsi : 2 hosts. At this point, the system hangs up pretty bad. Alt-PrtScn stuff to set the console log level reveals that there is an infinite series of "Detected scsi disk sdXX", where it keeps incrementing the XX through all the letters, and into punctuation, etc. -- -Matt You can't have everything. Where would you put it? -- Steven Wright - 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: Weightless process class
On Wed, Oct 04, 2000 at 06:16:57PM -0300, Rik van Riel wrote: > > > --- > > > One way would be to set a flag "I'm holding a lock" and when > > > it releases the lock(s), deschedule it? > > > > There is a well-known name for this -- priority inversion. > > > > Implement the whole shebang of starvation avoidance tricks, > > and we can whak the scheduler to group processes into separate > > subsets, which in current system leads to starvation lockups. > > > > A thing for 2.5 ? (With possible backport to 2.4 latter.) > > We don't need that. > > We just need one boolean per thread ... is it holding a kernel > lock or not? The BKL or *any* (kernel) lock ? For my knowledge there is no limitation on how many locks a thread can hold. Having a single bool might not be enough. A counter is better ? For example: Two filesystems are locking on their respective superblocks, and then they are locking on some underlying IO facility which both are sharing. Should the lock-count be incremented before the lock acquisition has happened, or only afterwards, that is other story. > If it is, make sure its scheduling latency isn't too high. e.g. all processes having *any* locks are raised to the highest possible class to make sure they are not starved out ? > If it isn't holding any lock, we can do with it what we want, > including completely starving the task for several seconds > (or even minutes) if scheduling latency or VM pressure warrants > it. Yes, that is obvious. > regards, > > Rik > http://www.conectiva.com/ http://www.surriel.com/ /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[linux-fbdev] Re: [PATCH] console palette fix
Here is patch to fix console palettes for the 2.2.X kernels. Its against
2.2.17.
--- console.c.orig Wed Oct 4 22:23:34 2000
+++ console.c Wed Oct 4 22:28:50 2000
@@ -575,10 +575,13 @@
}
if (redraw) {
+ int update;
+
set_origin(currcons);
+ update = sw->con_switch(vc_cons[currcons].d);
set_palette(currcons);
- if (sw->con_switch(vc_cons[currcons].d) && vcmode != KD_GRAPHICS)
- /* Update the screen contents */
+ if (update && vcmode != KD_GRAPHICS)
+ /* Update the screen contents */
do_update_region(currcons, origin, screenbuf_size/2);
}
set_cursor(currcons);
Re: IDE problems 2.4.0-t9p8 and later
I did not change it and I have yet to get a good reason from the person
who did. I have explained why it was wrong to change, but I guess things
will have to start crashing again when Linus accepts changes that I never
looked at or discussed.
Take it up with ManDrake Linux folks, it was there person that submitted
the change directly. I have VETOed the change, that only works in an
environment that respects boundaries and specialities.
I do not like the final changes that are in pre9-final.
There appears no valid reason for the change.
The one line delete and replace ment for the extra 20 (twenty) is bloat.
The change dorks up the modes if it PCI or Legacy.
Since ALL modern PCI-IDE chipsets that are onboard do not behave in native
mode because the first 4 PCI BARS are empty (is everyone listening?)
This is not "native mode" but "compatable mode".
Only devices that fill the first for BARS with the legacy IO's can claim
"native"; regardless, I am sorry that your system is crapped out.
Bitch Linus and not me
Cheers,
On Thu, 5 Oct 2000, Martin Diehl wrote:
>
> Hi,
> the following change from t9p7->t9p8 in ide-pci.c
>
> - if ((dev->class & ~(0xfa)) != ((PCI_CLASS_STORAGE_IDE << 8) | 5)) {
> + if ((dev->class & ~(0xff)) != (PCI_CLASS_STORAGE_IDE << 8)) {
>
> causes a lot of trouble to me. Seems to be the same thing, which has
> already been reported to l-k, but to my best knowledge it's unsolved.
> So I had a look into this issue:
> My IDE-Chipset is a SiS 5513 integrated into SiS 5591 Northbridge.
> dev->class is 0x01018a. Hence the old test (there from 2.2.* to
> 2.4.0-t9p7) said "true" (due to the "|5") while the new one says "false".
> So the chipset mode is now identified "native" although it's in
> compatibility mode. PCI-IRQ 14 is used for both ports instead of IRQ 15
> for ide1 in compatibility mode. Needless to say, everything (including
> BM-DMA) works fine for me before t9p8 but now hangs when initializing the
> devices on the 2nd ide port. (hdc/hdd: lost interrupt). Reverting the
> changes cures everything.
> I've double checked the crucial "|5" change against the documentation
> for the SiS 5591 chipset, which I have here. Value=0x8a in PCI-register 9
> definitely means "bus master capable" (0x80) and "operating mode is
> programmable" (0x0a) and "compatibility mode" (~0x05) for both channels.
> So the old code was the correct one.
> I've seen several complains on this to l-k during the last days which
> appeared to be misunderstood as broken changes wrt PCI_CLASS_STORAGE_IDE
> (the leading 0x0101 in dev->class). The crucial point however is the
> "|5" on the trailing byte.
> So, may I ask if there was some good reason for this change?
> What have I missed?
> Comments?
>
> Regards
> Martin
>
> -
> 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/
>
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
IDE problems 2.4.0-t9p8 and later
Hi,
the following change from t9p7->t9p8 in ide-pci.c
- if ((dev->class & ~(0xfa)) != ((PCI_CLASS_STORAGE_IDE << 8) | 5)) {
+ if ((dev->class & ~(0xff)) != (PCI_CLASS_STORAGE_IDE << 8)) {
causes a lot of trouble to me. Seems to be the same thing, which has
already been reported to l-k, but to my best knowledge it's unsolved.
So I had a look into this issue:
My IDE-Chipset is a SiS 5513 integrated into SiS 5591 Northbridge.
dev->class is 0x01018a. Hence the old test (there from 2.2.* to
2.4.0-t9p7) said "true" (due to the "|5") while the new one says "false".
So the chipset mode is now identified "native" although it's in
compatibility mode. PCI-IRQ 14 is used for both ports instead of IRQ 15
for ide1 in compatibility mode. Needless to say, everything (including
BM-DMA) works fine for me before t9p8 but now hangs when initializing the
devices on the 2nd ide port. (hdc/hdd: lost interrupt). Reverting the
changes cures everything.
I've double checked the crucial "|5" change against the documentation
for the SiS 5591 chipset, which I have here. Value=0x8a in PCI-register 9
definitely means "bus master capable" (0x80) and "operating mode is
programmable" (0x0a) and "compatibility mode" (~0x05) for both channels.
So the old code was the correct one.
I've seen several complains on this to l-k during the last days which
appeared to be misunderstood as broken changes wrt PCI_CLASS_STORAGE_IDE
(the leading 0x0101 in dev->class). The crucial point however is the
"|5" on the trailing byte.
So, may I ask if there was some good reason for this change?
What have I missed?
Comments?
Regards
Martin
-
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/
Integrating Andre IDE patch into 2.2.18/19 kernel
Hi Alan. I hope you will consider to integrate Andre IDE patche into the 2.2.18 or 2.2.19 kernel. For Linux to become a successful desktop platform, it needs better IDE support. Andre has done a tremendous job in getting the IDE driver support for so many chipsets such as Promise, CMD, VIA, and HPT. Today, most modern motherboards have such integrated Ultra/100 IDE controllers. This will cause installation problem on most Linux distributions. For example, Red Hat 7.0 cannot be installed on machines that have onboard Promise 20265 controller. An experienced user can get around the problem through various methods such as creating a custom install floppy or using the onboard ATA/66 controller first for installation. This process can be cumbersome and complicated for an average user. In the end, a lot of the users will not be able to install Linux successfully on their machines. The Linux 2.2.x kernel has reached a new level of functionality with the inclusion of the NFS V3 patch. I hope Andre IDE patch can follow that path. Regards, Jeff ASL Inc. - 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: Weightless process class
On Thu, 5 Oct 2000, Matti Aarnio wrote: > On Wed, Oct 04, 2000 at 12:49:43PM -0700, LA Walsh wrote: > > > One problem here is that you might end up with a weightless > > > process having grabbed a superblock lock, after which a > > > normal priority CPU hog kicks in and starves the weightless > > > process. > > --- > > One way would be to set a flag "I'm holding a lock" and when > > it releases the lock(s), deschedule it? > > There is a well-known name for this -- priority inversion. > > Implement the whole shebang of starvation avoidance tricks, > and we can whak the scheduler to group processes into separate > subsets, which in current system leads to starvation lockups. > > A thing for 2.5 ? (With possible backport to 2.4 latter.) We don't need that. We just need one boolean per thread ... is it holding a kernel lock or not? If it is, make sure its scheduling latency isn't too high. If it isn't holding any lock, we can do with it what we want, including completely starving the task for several seconds (or even minutes) if scheduling latency or VM pressure warrants it. regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: acquiring resources shared or exclusive
Jerry Kelley writes: > I have a rudimentary question as I'm new to the Linux kernel. Is there a > resource that can be acquired shared so that multiple threads can read data > from a protected region and not block each other? It seems that the > semaphore in the Linux kernel is only exclusively acquirable. I need to be > able to share read access from several threads to some global structures and > don't want them to block. > > I do want blocking whenever I have to modify the structures though. Thus I'm > looking for a way to perform synchronization for reads (shared) and writes > (exclusively) in the kernel. I assume it can be done it's just that I'm not > sure how to do it yet. This is probably a very easy question. There are read/write locks available in the kernel. Look in include/linux/spinlock.h and include/linux/brlock.h. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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: Weightless process class
On Wed, Oct 04, 2000 at 12:49:43PM -0700, LA Walsh wrote: > > One problem here is that you might end up with a weightless > > process having grabbed a superblock lock, after which a > > normal priority CPU hog kicks in and starves the weightless > > process. > --- > One way would be to set a flag "I'm holding a lock" and when > it releases the lock(s), deschedule it? There is a well-known name for this -- priority inversion. Implement the whole shebang of starvation avoidance tricks, and we can whak the scheduler to group processes into separate subsets, which in current system leads to starvation lockups. A thing for 2.5 ? (With possible backport to 2.4 latter.) > -l /Matti Aarnio - 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: instability after increasing file-max and inode-max
On Wed, Oct 04, 2000 at 11:55:02PM +0300, Matti Aarnio wrote: > On Wed, Oct 04, 2000 at 09:28:41PM +0200, Magnus Naeslund wrote: > > From: "Adam McKenna" <[EMAIL PROTECTED]> > > > [SNAP] > > > > This is what i have in one of our webservers (dual p3 512MB) configuration > > (in rc.local): > > > > echo "65536" > /proc/sys/fs/file-max > > echo "262144" > /proc/sys/fs/inode-max > > echo "10240 61000" > /proc/sys/net/ipv4/ip_local_port_range > > echo "134217728" > /proc/sys/kernel/shmmax > > echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time Thanks for the reply. Any idea why my system is rebooting itself at exactly 7:03 am on random days then, if it's not these parameters? I've checked all cron jobs, at jobs, etc, and there's nothing running at that time. --Adam -- Adam McKenna <[EMAIL PROTECTED]> | "No matter how much it changes, http://flounder.net/publickey.html | technology's just a bunch of wires GPG: 17A4 11F7 5E7E C2E7 08AA| connected to a bunch of other wires." 38B0 05D0 8BF7 2C6D 110A| Joe Rogan, _NewsRadio_ - 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: VM in v2.4.0test9
Rik van Riel wrote:
>
> On Wed, 4 Oct 2000, Roger Larsson wrote:
> > Rik van Riel wrote:
> > > On Wed, 4 Oct 2000, Rik van Riel wrote:
> > >
> > > > > > First, you have MORE free memory than freepages.high. In this
> > > > > > case I really don't see why __alloc_pages() wouldn't give the
> > > > > > memory to your processes
> > > > >
> > > > > Hmm...
> > > > > Can't it be a zone problem?
> > > > > Free pages is the total free - all zones.
> > > > > But suppose you want a page from a specific zone - DMA, the more
> > > > > memory you have the less likely that you have a DMA page free...
> > > > > Does all test take this into consideration?
> > > >
> > > > Free_shortage() /should/ take this into consideration, and unless
> > > > I'm wrong, it does ;)
> > >
> > > Also, a zone problem CANNOT cause the problem in
> > > David's 16MB test ...
> > >
> > > (this is getting stranger and stranger)
> >
> > Now I know from where the 125 pages limit comes from.
> > static int zone_balance_ratio[MAX_NR_ZONES] = { 32, 128, 128, };
> > 16M/4k/32 = 125
> >
> > Probably there is a mismatch between zone->free_pages and
> > free_pages.{min,low,high}
>
> Argh
>
> The potential for this bug has been around since 2.3.51, when
> different balance_ratios for different zones became possible.
>
> The bug hasn't bitten us yet since then because 1) the balance
> ratio for ZONE_DMA wasn't changed until some time later and
> 2) we didn't use freepages.{min,low,high}.
>
> Now that we /are/ using the values in the freepages array again,
> we're running into the very big problem that freepages.high has
> a value LOWER than zone->pages_min for the DMA zone, on 16MB
> machines. This caused David's system to behave the way it did.
>
Hi again,
I wonder if something like this is needed to...
when checking if we could take a page the test was:
free > limit
when checking for free_shortage, the test is:
free < min
And sometimes limit == min...
can't we then be stuck on exactly limit?
Patch attached (more places/files?)
/RogerL
--
Home page:
http://www.norran.net/nra02596/
--- linux/mm/page_alloc.c.orig Wed Oct 4 21:27:41 2000
+++ linux/mm/page_alloc.c Wed Oct 4 21:32:17 2000
@@ -268,7 +268,7 @@ static struct page * __alloc_pages_limit
water_mark = z->pages_high;
}
- if (z->free_pages + z->inactive_clean_pages > water_mark) {
+ if (z->free_pages + z->inactive_clean_pages >= water_mark) {
struct page *page = NULL;
/* If possible, reclaim a page directly. */
if (direct_reclaim && z->free_pages < z->pages_min + 8)
@@ -329,7 +329,7 @@ struct page * __alloc_pages(zonelist_t *
* wake up bdflush.
*/
else if (free_shortage() && nr_inactive_dirty_pages > free_shortage()
- && nr_inactive_dirty_pages > freepages.high)
+ && nr_inactive_dirty_pages >= freepages.high)
wakeup_bdflush(0);
try_again:
@@ -347,7 +347,7 @@ try_again:
if (!z->size)
BUG();
- if (z->free_pages > z->pages_low) {
+ if (z->free_pages >= z->pages_low) {
page = rmqueue(z, order);
if (page)
return page;
Re: instability after increasing file-max and inode-max
On Wed, Oct 04, 2000 at 09:28:41PM +0200, Magnus Naeslund wrote: > From: "Adam McKenna" <[EMAIL PROTECTED]> > [SNAP] > > This is what i have in one of our webservers (dual p3 512MB) configuration > (in rc.local): > > echo "65536" > /proc/sys/fs/file-max > echo "262144" > /proc/sys/fs/inode-max > echo "10240 61000" > /proc/sys/net/ipv4/ip_local_port_range > echo "134217728" > /proc/sys/kernel/shmmax > echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time While this stuff in rc.local is the classical way, at leat RedHat initscripts package carries /etc/sysctl.conf file. See it and sysctl.conf(5) man page for info. > Magnus Naeslund /Matti Aarnio - 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: Weightless process class
On Wed, 4 Oct 2000, Nathan Paul Simons wrote: > On Wed, Oct 04, 2000 at 04:16:22PM -0300, Rik van Riel wrote: > > Do we have something like an in_kernel(proc) macro ??? > > "user_mode()" in include/asm/ptrace.h? But that only checks to > see if the regs struct you passed it are from a kernel thread or > not. No checks to see if the process has any kernel locks. A process can't grab a kernel lock and then switch back to user mode, can it?(if it could, I can imagine some nasty DoS attacks...) Problem is, when we decide to schedule in a process or not, we know the process was last stuck in schedule() ... in kernel mode ;( I'd love to be proven wrong though ... this would be some extremely useful functionality ;) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Weightless process class
On Wed, Oct 04, 2000 at 04:16:22PM -0300, Rik van Riel wrote: > Do we have something like an in_kernel(proc) macro ??? "user_mode()" in include/asm/ptrace.h? But that only checks to see if the regs struct you passed it are from a kernel thread or not. No checks to see if the process has any kernel locks. -- Nathan Paul Simons, Junior Software Engineer for FSMLabs http://www.fsmlabs.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM in v2.4.0test9
On Wed, 4 Oct 2000, Roger Larsson wrote:
> Rik van Riel wrote:
> > On Wed, 4 Oct 2000, Rik van Riel wrote:
> >
> > > > > First, you have MORE free memory than freepages.high. In this
> > > > > case I really don't see why __alloc_pages() wouldn't give the
> > > > > memory to your processes
> > > >
> > > > Hmm...
> > > > Can't it be a zone problem?
> > > > Free pages is the total free - all zones.
> > > > But suppose you want a page from a specific zone - DMA, the more
> > > > memory you have the less likely that you have a DMA page free...
> > > > Does all test take this into consideration?
> > >
> > > Free_shortage() /should/ take this into consideration, and unless
> > > I'm wrong, it does ;)
> >
> > Also, a zone problem CANNOT cause the problem in
> > David's 16MB test ...
> >
> > (this is getting stranger and stranger)
>
> Now I know from where the 125 pages limit comes from.
> static int zone_balance_ratio[MAX_NR_ZONES] = { 32, 128, 128, };
> 16M/4k/32 = 125
>
> Probably there is a mismatch between zone->free_pages and
> free_pages.{min,low,high}
Argh
The potential for this bug has been around since 2.3.51, when
different balance_ratios for different zones became possible.
The bug hasn't bitten us yet since then because 1) the balance
ratio for ZONE_DMA wasn't changed until some time later and
2) we didn't use freepages.{min,low,high}.
Now that we /are/ using the values in the freepages array again,
we're running into the very big problem that freepages.high has
a value LOWER than zone->pages_min for the DMA zone, on 16MB
machines. This caused David's system to behave the way it did.
Does the attached patch fix the problem?
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
--- mm/page_alloc.c.origTue Oct 3 10:20:41 2000
+++ mm/page_alloc.c Wed Oct 4 17:01:52 2000
@@ -795,21 +795,6 @@
printk("On node %d totalpages: %lu\n", nid, realtotalpages);
- /*
-* Select nr of pages we try to keep free for important stuff
-* with a minimum of 10 pages and a maximum of 256 pages, so
-* that we don't waste too much memory on large systems.
-* This is fairly arbitrary, but based on some behaviour
-* analysis.
-*/
- i = realtotalpages >> 7;
- if (i < 10)
- i = 10;
- if (i > 256)
- i = 256;
- freepages.min += i;
- freepages.low += i * 2;
- freepages.high += i * 3;
memlist_init(&active_list);
memlist_init(&inactive_dirty_list);
@@ -875,6 +860,20 @@
zone->pages_min = mask;
zone->pages_low = mask*2;
zone->pages_high = mask*3;
+ /*
+* Add these free targets to the global free target;
+* we have to be SURE that freepages.high is higher
+* than SUM [zone->pages_min] for all zones, otherwise
+* we may have bad bad problems.
+*
+* This means we cannot make the freepages array writable
+* in /proc, but have to add a separate extra_free_target
+* for people who require it to catch load spikes in eg.
+* gigabit ethernet routing...
+*/
+ freepages.min += mask;
+ freepages.low += mask*2;
+ freepages.high += mask*3;
zone->zone_mem_map = mem_map + offset;
zone->zone_start_mapnr = offset;
zone->zone_start_paddr = zone_start_paddr;
-
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: Weightless process class
> One problem here is that you might end up with a weightless > process having grabbed a superblock lock, after which a > normal priority CPU hog kicks in and starves the weightless > process. --- One way would be to set a flag "I'm holding a lock" and when it releases the lock(s), deschedule it? > This makes little sense. If the system doesn't page out > the least used page in the system, the disks will be more > busy on page faults than they need to be, taking away IO > bandwidth from more important processes ;) --- Strictly speaking, true, probably nothing to make an exception for. -l - 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: VM in v2.4.0test9
Rik van Riel wrote:
>
> On Wed, 4 Oct 2000, Rik van Riel wrote:
>
> > > > First, you have MORE free memory than freepages.high. In this
> > > > case I really don't see why __alloc_pages() wouldn't give the
> > > > memory to your processes
> > >
> > > Hmm...
> > > Can't it be a zone problem?
> > > Free pages is the total free - all zones.
> > > But suppose you want a page from a specific zone - DMA, the more
> > > memory you have the less likely that you have a DMA page free...
> > > Does all test take this into consideration?
> >
> > Free_shortage() /should/ take this into consideration, and unless
> > I'm wrong, it does ;)
>
> Also, a zone problem CANNOT cause the problem in
> David's 16MB test ...
>
> (this is getting stranger and stranger)
Now I know from where the 125 pages limit comes from.
static int zone_balance_ratio[MAX_NR_ZONES] = { 32, 128, 128, };
16M/4k/32 = 125
Probably there is a mismatch between zone->free_pages and
free_pages.{min,low,high}
/RogerL
--
Home page:
http://www.norran.net/nra02596/
-
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: asm-i386/uaccess.h changes: bug or feature?
To clarify: you're getting missing-symbol errors (not duplicate-symbols)?
I believe that the "return" versions of these macros have been deprecated.
There's an effort going on to replace these functions with a standard
"put_user(); return;" pair. People think that having a macro which returns
from a function is a bad idea. I imagine the source you're using hasn't been
updated; I would suggest removing the xxx_ret macros from the package you're
compiling (or contacting its maintainer).
chris
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Wes McRae
> Sent: Wednesday, October 04, 2000 3:00 PM
> To: [EMAIL PROTECTED]
> Subject: asm-i386/uaccess.h changes: bug or feature?
>
>
> Hello
>
> Background: compiling lm_sensors 2.5.2 on RedHat 7.0 running 2.4.0-test8
> kernel. (vanilla intel system)
>
> Attempting to compile the sensor package gave symbol errors regarding
> the xxx_ret symbols (copying to/from user space, putting/getting. These
> have been removed from uaccess.h in recent kernels. These were present
> in 2.2.16 and at least some 2.3.x kernels. As you can see from the
> appended diff, these appear to be the only changes. I tend to assume
> there's a reason, but could find no explanation in the kernel docs for
> it.
>
> For what it's worth, I could still compile the application--just not
> load its modules.
>
> Many apologies if this is not the right place to send this--it seemed
> the most likely place after checking MAINTAINERS and REPORTING-BUGS.
>
> bye
> wes
>
> --- /usr/include/asm/uaccess.h Fri Aug 25 08:31:57 2000
> +++ /usr/src/linux/include/asm/uaccess.hFri Sep 29 12:09:04 2000
>
> @@ -232,20 +232,6 @@
> : "=r"(err), ltype (x) \
> : "m"(__m(addr)), "i"(-EFAULT), "0"(err))
>
> -/*
> - * The "xxx_ret" versions return constant specified in third argument,
> if
> - * something bad happens. These macros can be optimized for the
> - * case of just returning from the function xxx_ret is used.
> - */
> -
> -#define put_user_ret(x,ptr,ret) ({ if (put_user(x,ptr)) return ret; })
> -
> -#define get_user_ret(x,ptr,ret) ({ if (get_user(x,ptr)) return ret; })
> -
> -#define __put_user_ret(x,ptr,ret) ({ if (__put_user(x,ptr)) return ret;
> })
> -
> -#define __get_user_ret(x,ptr,ret) ({ if (__get_user(x,ptr)) return ret;
> })
> -
>
> /*
> * Copy To/From Userspace
> @@ -582,10 +568,6 @@
> (__builtin_constant_p(n) ? \
> __constant_copy_from_user((to),(from),(n)) : \
> __generic_copy_from_user((to),(from),(n)))
> -
> -#define copy_to_user_ret(to,from,n,retval) ({ if
> (copy_to_user(to,from,n)) return retval; })
> -
> -#define copy_from_user_ret(to,from,n,retval) ({ if
> (copy_from_user(to,from,n)) return retval; })
>
> #define __copy_to_user(to,from,n) \
> (__builtin_constant_p(n) ? \
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: asm-i386/uaccess.h changes: bug or feature?
Wes McRae wrote: > > Hello > > Background: compiling lm_sensors 2.5.2 on RedHat 7.0 running 2.4.0-test8 > kernel. (vanilla intel system) > > Attempting to compile the sensor package gave symbol errors regarding > the xxx_ret symbols (copying to/from user space, putting/getting. These > have been removed from uaccess.h in recent kernels. These were present > in 2.2.16 and at least some 2.3.x kernels. As you can see from the > appended diff, these appear to be the only changes. I tend to assume > there's a reason, but could find no explanation in the kernel docs for > it. > > For what it's worth, I could still compile the application--just not > load its modules. > > Many apologies if this is not the right place to send this--it seemed > the most likely place after checking MAINTAINERS and REPORTING-BUGS. These macros were removed. Just replace the usage with the appropriate if statement. See this thread for the reason: http://marc.theaimsgroup.com/?l=linux-kernel&m=96721877032003&w=2 -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: instability after increasing file-max and inode-max
From: "Adam McKenna" <[EMAIL PROTECTED]> > Hello, I have a system here that was up for over 100 days, using kernel > 2.2.15. We are running Oracle 8i on it. The middle of last week, we ran out > of file handles, so I increased /proc/sys/fs/file-max to 16384 and > /proc/sys/fs/inode-max to 16384. This appears to have caused instability, as > the box has crashed twice since last friday (once on Saturday morning, and > once this morning), at exactly 7:03 am. > [SNAP] This is what i have in one of our webservers (dual p3 512MB) configuration (in rc.local): echo "65536" > /proc/sys/fs/file-max echo "262144" > /proc/sys/fs/inode-max echo "10240 61000" > /proc/sys/net/ipv4/ip_local_port_range echo "134217728" > /proc/sys/kernel/shmmax echo 300 > /proc/sys/net/ipv4/tcp_keepalive_time As i've read and been told the inode-max should be atleast file-max*3, but as you see i have it four times higher. My system seems to be very stable, and i know i have overdimensioned everything :) Magnus Naeslund -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Programmer/Networker [|] Magnus Naeslund PGP Key: http://www.genline.nu/mag_pgp.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PIIX4-ide still not working in 2.4-test9...
Bruno Boettcher <[EMAIL PROTECTED]> said: > On Wed, Oct 04, 2000 at 01:53:34AM -0700, David Ford wrote: > > When you enable PIIXn support in the IDE section, make sure you DISABLE PIIXn > > tuning which is the very next line. > ok i even tryed with a freshly downloaded complete 2.4-test9 tree. > nothing to do: just before init comes, i get: > > ide_dmaproc: chipset supported ide_dma_lostirq func only : 13 > > any other hint i could try? > nice that this non-working kernel is called test but i suspect that > the final version will not run either on my laptop :( Works fine on my Toshiba Satellite Pro 4280 XDVD (mostly Red Hat 6.2). -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 on SPARC64: Undefined symbols in modules
Anton Blanchard <[EMAIL PROTECTED]> said: > > Lots of: > > > > __atomic_add > > __atomic_sub > > __test_and_set_bit > > __test_and_clear_bit > > > > (This machine is the result of transplanting the disks with RH 6.2 + > > updates + local hacks from a SPARC, so this might be an artifact; but I > > don't think so). > I am not seeing it here. Are the symbols visible in /proc/ksyms? Just booted 2.4.0-test9 here (my report was from "make modules_install"), now "depmod -ae" is completely silent. Very strange. And yes, the symbols do show up in /proc/ksyms. Sorry for the false alarm. -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Weightless process class
On Wed, 4 Oct 2000, LA Walsh wrote: > I had another thought regarding resource scheduling -- has the > idea of a "weightless" process been brought up? Yes, look for "idle priority", etc.. It also turned out to have some problems ... > Weightless means it doesn't count toward 'load' and the class > strictly has lowest priority in the system and gets *no* CPU > unless there are "idle" cycles. So even a process niced to -19 > could CPU starve a weightless process. One problem here is that you might end up with a weightless process having grabbed a superblock lock, after which a normal priority CPU hog kicks in and starves the weightless process. The result is that that superblock lock never gets released, and everybody needing to grab that lock blocks forever, even if they have a higher priority than the CPU hog that's starving our idle process... The solution to this would be only starve these processes when they are in user space and can no longer be holding any kernel locks. Do we have something like an in_kernel(proc) macro ??? > Perhaps if memory was needed, the paging code would page out > weightless processes first... etc?... This makes little sense. If the system doesn't page out the least used page in the system, the disks will be more busy on page faults than they need to be, taking away IO bandwidth from more important processes ;) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: asm-i386/uaccess.h changes: bug or feature?
In article <[EMAIL PROTECTED]> you wrote: > Attempting to compile the sensor package gave symbol errors regarding > the xxx_ret symbols (copying to/from user space, putting/getting. These > have been removed from uaccess.h in recent kernels. These were present > in 2.2.16 and at least some 2.3.x kernels. As you can see from the > appended diff, these appear to be the only changes. I tend to assume > there's a reason, but could find no explanation in the kernel docs for > it. 2 possible causes: you forgot to use -O on the commandline when compiling the modules, or you didn't use kgcc Greetings, Arjan van de Ven - 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/
asm-i386/uaccess.h changes: bug or feature?
Hello
Background: compiling lm_sensors 2.5.2 on RedHat 7.0 running 2.4.0-test8
kernel. (vanilla intel system)
Attempting to compile the sensor package gave symbol errors regarding
the xxx_ret symbols (copying to/from user space, putting/getting. These
have been removed from uaccess.h in recent kernels. These were present
in 2.2.16 and at least some 2.3.x kernels. As you can see from the
appended diff, these appear to be the only changes. I tend to assume
there's a reason, but could find no explanation in the kernel docs for
it.
For what it's worth, I could still compile the application--just not
load its modules.
Many apologies if this is not the right place to send this--it seemed
the most likely place after checking MAINTAINERS and REPORTING-BUGS.
bye
wes
--- /usr/include/asm/uaccess.h Fri Aug 25 08:31:57 2000
+++ /usr/src/linux/include/asm/uaccess.hFri Sep 29 12:09:04 2000
@@ -232,20 +232,6 @@
: "=r"(err), ltype (x) \
: "m"(__m(addr)), "i"(-EFAULT), "0"(err))
-/*
- * The "xxx_ret" versions return constant specified in third argument,
if
- * something bad happens. These macros can be optimized for the
- * case of just returning from the function xxx_ret is used.
- */
-
-#define put_user_ret(x,ptr,ret) ({ if (put_user(x,ptr)) return ret; })
-
-#define get_user_ret(x,ptr,ret) ({ if (get_user(x,ptr)) return ret; })
-
-#define __put_user_ret(x,ptr,ret) ({ if (__put_user(x,ptr)) return ret;
})
-
-#define __get_user_ret(x,ptr,ret) ({ if (__get_user(x,ptr)) return ret;
})
-
/*
* Copy To/From Userspace
@@ -582,10 +568,6 @@
(__builtin_constant_p(n) ? \
__constant_copy_from_user((to),(from),(n)) : \
__generic_copy_from_user((to),(from),(n)))
-
-#define copy_to_user_ret(to,from,n,retval) ({ if
(copy_to_user(to,from,n)) return retval; })
-
-#define copy_from_user_ret(to,from,n,retval) ({ if
(copy_from_user(to,from,n)) return retval; })
#define __copy_to_user(to,from,n) \
(__builtin_constant_p(n) ? \
-
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: Benchmark results for elv_test (2.4.0-test9 and back).
Grab NWFS at vger.timpanogas.org. It has a really good ASYNCH I/O abstraction in kernel that is pluggable and will allow very agressive testing of the elevator code in 2.4.0. Check the file BLOCK.C for the 2.4 support and ASYNC.C. Theres a nice way to pump ons of AIO requests into Linux with this interface, and it's fully asynch. Jeff "J. Robert von Behren" wrote: > > Greetings, Robert. > > Looking over your test program, I don't think you are actually testing > the elevator algorithm at all. There are a couple of key flaws: > > * The reads and writes are synchronous, so the elevator algorithm > at _most_ gets to effect the blocks within a single read or > write (ie - inside the same file). > > * The fact that you have written the files out all at once will not > place all 240 megs of data consecutively on the disk. The file > system spreads out data on disk to allow breathing room for > adding new files, or appending to existing files. In particular, > this means that although large subsections of blocks that are > adjacent in the logical file _will_ be close by on disk, you cannot > generalize from this that these large subsections will be close to > each other - either within a single file, or between the files > created by the test program. > > * Unless the partition is completely empty, existing file data will > effect where new data is placed (and in particular how well > co-located > it can be). > > A better approach to testing the elevator algorithm would be to write > directly to a raw device, instead of going through the file system. > This would allow you better control over actual disk placement of > blocks, and let you know what you were testing. It would also allow you > to make sure that subsequent re-tests would be repeatable, as they > shouldn't be effected by existing data. Finally, to do this test right, > you need to be able to issue multiple IO requests to the disk at > essentially the same time. To do this, you'll probably need to go > multithreaded, and use a barrier of some sort to make sure the threads > stay synchronized. > > Best regards, > > -Rob von Behren > > Robert Cohen wrote: > > > > Here are the latest results for my elv_test elevator benchmark. > > This benchmark gives three numbers, a baseline figure for writing > > sequentially and write and read results for writing and reading in a > > pattern designed to give the elevator a hard time. > > The source code is available at > > http://tltsu.anu.edu.au/~robert/elv_test.c. > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Benchmark results for elv_test (2.4.0-test9 and back).
Greetings, Robert. Looking over your test program, I don't think you are actually testing the elevator algorithm at all. There are a couple of key flaws: * The reads and writes are synchronous, so the elevator algorithm at _most_ gets to effect the blocks within a single read or write (ie - inside the same file). * The fact that you have written the files out all at once will not place all 240 megs of data consecutively on the disk. The file system spreads out data on disk to allow breathing room for adding new files, or appending to existing files. In particular, this means that although large subsections of blocks that are adjacent in the logical file _will_ be close by on disk, you cannot generalize from this that these large subsections will be close to each other - either within a single file, or between the files created by the test program. * Unless the partition is completely empty, existing file data will effect where new data is placed (and in particular how well co-located it can be). A better approach to testing the elevator algorithm would be to write directly to a raw device, instead of going through the file system. This would allow you better control over actual disk placement of blocks, and let you know what you were testing. It would also allow you to make sure that subsequent re-tests would be repeatable, as they shouldn't be effected by existing data. Finally, to do this test right, you need to be able to issue multiple IO requests to the disk at essentially the same time. To do this, you'll probably need to go multithreaded, and use a barrier of some sort to make sure the threads stay synchronized. Best regards, -Rob von Behren Robert Cohen wrote: > > Here are the latest results for my elv_test elevator benchmark. > This benchmark gives three numbers, a baseline figure for writing > sequentially and write and read results for writing and reading in a > pattern designed to give the elevator a hard time. > The source code is available at > http://tltsu.anu.edu.au/~robert/elv_test.c. - 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/
instability after increasing file-max and inode-max
Hello, I have a system here that was up for over 100 days, using kernel 2.2.15. We are running Oracle 8i on it. The middle of last week, we ran out of file handles, so I increased /proc/sys/fs/file-max to 16384 and /proc/sys/fs/inode-max to 16384. This appears to have caused instability, as the box has crashed twice since last friday (once on Saturday morning, and once this morning), at exactly 7:03 am. Here are the last few syslog messages before the crash: on Saturday: Sep 30 06:53:54 burger ctlinnd[9454]: Reading config from /etc/news/inn.conf Sep 30 06:53:54 burger innd: s Sep 30 06:55:01 burger /USR/SBIN/CRON[9581]: (list) CMD ([ -x /usr/bin/python -a -f /usr/lib/mailman/cron/gate_news ] && /usr/bin/python /usr/lib/mailman/cron/g ate_news) Sep 30 07:03:04 burger syslogd 1.3-3#33: restart. Today: Oct 4 06:51:54 burger ctlinnd[4101]: Reading config from /etc/news/inn.conf Oct 4 06:51:54 burger innd: s Oct 4 06:55:01 burger /USR/SBIN/CRON[4216]: (list) CMD ([ -x /usr/bin/python -a -f /usr/lib/mailman/cron/gate_news ] && /usr/bin/python /usr/lib/mailman/cron/g ate_news) Oct 4 07:03:03 burger syslogd 1.3-3#33: restart. dmesg: Linux version 2.2.15 (herbert@gondor) (gcc version 2.95.2 2313 (Debian GNU/Linux)) #1 Thu Jun 1 10:47:16 EST 2000 Detected 596929811 Hz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1189.48 BogoMIPS Memory: 516308k/524224k available (1740k kernel code, 416k reserved, 5620k data, 140k init) Dentry hash table entries: 65536 (order 7, 512k) Buffer cache hash table entries: 524288 (order 9, 2048k) Page cache hash table entries: 131072 (order 7, 512k) VFS: Diskquotas version dquot_6.4.0 initialized CPU: Intel Pentium III (Coppermine) stepping 01 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. Checking for popad bug... OK. POSIX conformance testing by UNIFIX mtrr: v1.35a (19990819) Richard Gooch ([EMAIL PROTECTED]) PCI: PCI BIOS revision 2.10 entry at 0xfdab0 PCI: Using configuration type 1 PCI: Probing PCI hardware Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP TCP: Hash tables configured (ehash 524288 bhash 65536) Starting kswapd v 1.5 Detected PS/2 Mouse Port. pty: 256 Unix98 ptys configured apm: BIOS not found. Real Time Clock Driver v1.09 RAM disk driver initialized: 16 RAM disks of 4096K size loop: registered device at major 7 PIIX4: IDE controller on PCI bus 00 dev 91 PIIX4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x2860-0x2867, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x2868-0x286f, BIOS settings: hdc:DMA, hdd:pio keyboard: Too many NACKs -- noisy kbd cable? keyboard: Too many NACKs -- noisy kbd cable? hda: QUANTUM FIREBALLP LM30, ATA DISK drive hdc: CD-540E, ATAPI CDROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: QUANTUM FIREBALLP LM30, 28629MB w/1900kB Cache, CHS=3649/255/63 hdc: ATAPI 40X CD-ROM drive, 128kB Cache Uniform CDROM driver Revision: 2.56 Floppy drive(s): fd0 is 1.44M FDC 0 is a National Semiconductor PC87306 md driver 0.36.6 MAX_MD_DEV=4, MAX_REAL=8 (scsi0) found at PCI 0/12/0 (scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs (scsi0) Downloading sequencer code... 392 instructions downloaded (scsi1) found at PCI 0/12/1 (scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs (scsi1) Downloading sequencer code... 392 instructions downloaded scsi: Detection failed (no card) NCR53c406a: no available ports found sym53c416.c: Version 1.0.0 Failed initialization of WD-7000 SCSI card! IBM MCA SCSI: No Microchannel-bus support present -> Aborting. megaraid: v107 (December 22, 1999) aec671x_detect: 3w-: tw_findcards(): No cards found. scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.29/3.2.4 scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.29/3.2.4 scsi : 2 hosts. scsi : detected total. Partition check: hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 hda11 > VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 140k freed NET4: Unix domain sockets 1.0 for Linux NET4.0. Adding Swap: 136544k swap-space (priority -1) Adding Swap: 1028120k swap-space (priority -2) eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html eepro100.c: $Revision: 1.20.2.3 $ 2000/03/02 Modified by Andrey V. Savochkin <[EMAIL PROTECTED]> and others eth0: Intel PCI EtherExpress Pro100 at 0xe00aa000, 00:D0:B7:65:DF:BE, IRQ 10. Receiver lock-up bug exists -- enabling work-around. Board assembly 00-000, Physical connectors present: RJ45 Primary interface chip i82555 PHY #1. General self-test: passed. Serial sub-system self-test: passed. Internal registers self-test: passed. ROM checksum self-test: passed (0x04f4518b). Serial driver version 4.27 with no serial options enabled ttyS00 at 0x03f8 (irq = 4)
Weightless process class
I had another thought regarding resource scheduling -- has the idea of a "weightless" process been brought up? Weightless means it doesn't count toward 'load' and the class strictly has lowest priority in the system and gets *no* CPU unless there are "idle" cycles. So even a process niced to -19 could CPU starve a weightless process. Perhaps if memory was needed, the paging code would page out weightless processes first... etc?... ?? -linda -- L A Walsh| Trust Technology, Core Linux, SGI [EMAIL PROTECTED] | Voice/Vmail: (650) 933-5338 - 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: test9-pre9 lockups using pine
On Tue, 3 Oct 2000, Rik van Riel wrote: > On Tue, 3 Oct 2000, Christoph Lameter wrote: > > > I frequently experience lockups since test9-pre7. It usually > > happens when leaving pine. Pine asks if the deleted messages > > should be purged. Say yes and everything freezes up. > > > # CONFIG_MAGIC_SYSRQ is not set > > Maybe you want to switch on this option and tell us some > more useful information ;) > > - system hardware configuration (how much memory) 64M Ram AMD K2-400. > - running X or not X yes > - compiler version used to compile the kernel bash-2.04$ gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs gcc version 2.95.2 2220 (Debian GNU/Linux) bash-2.04$ > - what do you see after the system 'hangs' and > you type sysrq-T, sysrq-M and/or sysrq-P ? Not tried that yet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 module sd.o didn't get installed
doh! forget it, my fault, didn't notice the filename changed. Lee Mitchell www.spamtastic.demon.co.uk [EMAIL PROTECTED] - Original Message - From: Lee Mitchell <[EMAIL PROTECTED]> To: Linux Kernel development list <[EMAIL PROTECTED]> Sent: Wednesday, October 04, 2000 6:25 PM Subject: 2.4.0-test9 module sd.o didn't get installed > Compiled 2.4.0-test9 with an aic7xxx card (all scsi stuff compiled as > modules). > > make modules_install did not install the module sd.o as i found out when > rebooting. > > copying the file manually from the kernel source tree fixed it. > > Lee Mitchell > www.spamtastic.demon.co.uk > [EMAIL PROTECTED] > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.0-test9
Hi all, I've tried Linux-2.4.0-test[7-9] kernel on my laptop, and got a trouble with them. When yenta_socket and apm driver are installed, system hangs. Each driver works fine without another one. Why? Thanks, A.Yoshiyama <[EMAIL PROTECTED]> p.s. My Laptop: NEC LaVie NX (Japan local model of NEC Versa all-in-one). - 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: cannot connect to linuxtoday.com 80 with test9-pre9
On Wed, 4 Oct 2000, Andi Kleen wrote: > On Wed, Oct 04, 2000 at 09:34:18AM -0700, Christoph Lameter wrote: > > Is there something wrong with the tcp stack? > > More with their firewall. But try > > echo 0 > /proc/sys/net/ipv4/tcp_ecn Wow. I suddenly can access lots of hosts again. And we feel that we need to force linuxtoday and others to fix their firewall right? Could we introduce a new errorcode like E_BROKENFIREWALL so that we can get a correct errormessage and everyone can then notify linuxtoday and others about their broken firewalls? - 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.4.0-test9 module sd.o didn't get installed
Compiled 2.4.0-test9 with an aic7xxx card (all scsi stuff compiled as modules). make modules_install did not install the module sd.o as i found out when rebooting. copying the file manually from the kernel source tree fixed it. Lee Mitchell www.spamtastic.demon.co.uk [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] acpi: release on failure
Hi,
Please consider applying. Jeff, if you think something is missing, please
tell me.
- Arnaldo
--- linux-2.4.0-test9/arch/i386/kernel/acpi.c Tue Oct 3 12:38:06 2000
+++ linux-2.4.0-test9.acme/arch/i386/kernel/acpi.c Wed Oct 4 09:48:59 2000
@@ -27,6 +27,8 @@
* - check copy*user return
* - get rid of check_region
* - get rid of verify_area
+ * Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> - 2000/09/28
+ * - do proper release on failure in acpi_claim_ioports and acpi_init
*/
#include
@@ -81,6 +83,7 @@
struct file *file,
void *buffer,
size_t *len);
+static void acpi_release(unsigned long start, unsigned long size);
static struct ctl_table_header *acpi_sysctl = NULL;
@@ -1300,15 +1303,28 @@
static int acpi_claim_ioports(struct acpi_facp *facp)
{
// we don't get a guarantee of contiguity for any of the ACPI registers
- if (acpi_claim(facp->pm1a_evt, facp->pm1_evt_len)
- || acpi_claim(facp->pm1b_evt, facp->pm1_evt_len)
- || acpi_claim(facp->pm1a_cnt, facp->pm1_cnt_len)
- || acpi_claim(facp->pm1b_cnt, facp->pm1_cnt_len)
- || acpi_claim(facp->pm_tmr, facp->pm_tm_len)
- || acpi_claim(facp->gpe0, facp->gpe0_len)
- || acpi_claim(facp->gpe1, facp->gpe1_len))
- return -EBUSY;
+ if (acpi_claim(facp->pm1a_evt, facp->pm1_evt_len))
+ goto return_ebusy;
+ if (acpi_claim(facp->pm1b_evt, facp->pm1_evt_len))
+ goto release_pm1a_evt;
+ if (acpi_claim(facp->pm1a_cnt, facp->pm1_cnt_len))
+ goto release_pm1b_evt;
+ if (acpi_claim(facp->pm1b_cnt, facp->pm1_cnt_len))
+ goto release_pm1a_cnt;
+ if (acpi_claim(facp->pm_tmr, facp->pm_tm_len))
+ goto release_pm1b_cnt;
+ if (acpi_claim(facp->gpe0, facp->gpe0_len))
+ goto release_pm_tmr;
+ if (acpi_claim(facp->gpe1, facp->gpe1_len))
+ goto release_gpe0;
return 0;
+release_gpe0: acpi_release(facp->gpe0, facp->gpe0_len);
+release_pm_tmr:acpi_release(facp->pm_tmr, facp->pm_tm_len);
+release_pm1b_cnt: acpi_release(facp->pm1b_cnt, facp->pm1_cnt_len);
+release_pm1a_cnt: acpi_release(facp->pm1a_cnt, facp->pm1_cnt_len);
+release_pm1b_evt: acpi_release(facp->pm1b_evt, facp->pm1_evt_len);
+release_pm1a_evt: acpi_release(facp->pm1a_evt, facp->pm1_evt_len);
+return_ebusy: return -EBUSY;
}
/*
@@ -1523,8 +1539,10 @@
error = -ENOMEM;
}
if (data)
- if (copy_from_user(data, buffer, size))
+ if (copy_from_user(data, buffer, size)) {
+ acpi_destroy_table(info);
error = -EFAULT;
+ }
write_unlock(&acpi_do_table_lock);
}
@@ -1838,7 +1856,7 @@
&acpi_facp)) {
printk(KERN_ERR "ACPI: SCI (IRQ%d) allocation failed\n",
facp->sci_int);
- goto err_out;
+ goto cleanup_ioports;
}
#ifndef CONFIG_ACPI_S1_SLEEP
@@ -1846,6 +1864,8 @@
#endif
acpi_sysctl = register_sysctl_table(acpi_dir_table, 1);
+ if (!acpi_sysctl)
+ goto cleanup_irq;
pm_power_off = acpi_power_off;
@@ -1863,7 +1883,10 @@
pm_idle = acpi_idle;
return 0;
-
+cleanup_irq:
+free_irq(facp->sci_int, &acpi_facp);
+cleanup_ioports:
+acpi_release_ioports(facp);
err_out:
if (pci_driver_registered)
pci_unregister_driver(&acpi_driver);
-
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: 32-bit pid_t / security
On Wed, 4 Oct 2000, Richard B. Johnson wrote: > On Wed, 4 Oct 2000, Michael van den broek wrote: > > > > > > > On Wed, 4 Oct 2000, Richard B. Johnson wrote: > > > > > On Tue, 3 Oct 2000, Brett Frankenberger wrote: > > > > > > > > > > > > > S/390 folks run 70,000 sessions active within the same 60 second period off > > > > > one big box. Not on Linux (yet ;)) but its worth bearing in mind. > > > > > > > > > > Linux 2.2.17 only allows 255 processes at any one time. Is this a > > > 'feature'. If so, there is no security to be gained by having 32-bit > > > pids wrap at 32-bits. Note they already are 32 bits. > > > > > > > Hya, > > > > Did you raise the max process ulimit ?, > > > > the standard limit is: 256 processes > > > > greets, > > > > Michael > > > To the best of my knowledge, I don't have ulimits turned on! > Script started on Wed Oct 4 13:01:30 2000 > $ ulimit > unlimited > $ exit > Script done on Wed Oct 4 13:01:36 2000 Use 'ulimit -a' to see your limits - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.0-test9: USB-Mouse half recognized
> From: Jan Niehusmann [mailto:[EMAIL PROTECTED]] > > On Wed, Oct 04, 2000 at 04:15:54PM +0200, Meino Christian > Cramer wrote: > > I tried it both: uhci and usb.uhci: > > Same behaviour for both: Boot into runlevel 2. do a cat on > > /dev/input/mouse0 and move the mouse: OK, some glibberish bytes > > found their way onto the console. > > Oh well you're right... but I have a workaround (that made me > think the > other driver works): > > Start X. The mouse doesn't work. Switch to a console. > rmmod uhci; modprobe uhci > Switch back to X. Now the mouse works. (until you switch away > from X, again) > > > Jan Well, it's nice if you have a workaround, but I (or we [royal]) really messed some USB stuff up in 2.4.0-test9 -- affects lots of USB devices. We're working on fixes. Sorry about that. ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Incomplete Adaptec 29160 support!?
On Wed, Oct 04, 2000 at 02:49:34AM -0500, Dave Madsen wrote: > Based on what I've been able to find out on the net, it > appears that the support of the Adaptec 29160 is not complete > (optimal?), but because the card works in a degraded mode with the > current driver, there haven't been many complaints. > > A recent benchmark in Open Magazine (1.2, Sep 2000) describes this. > Their comments on page 26 address this issue. They say the card is > recognized as a "7892", and works in Ultra2 mode instead of Ultra160. > The use Redhat 6.2 for their benchmark. Which might be their problem. i haven't used RedHat for a while (switched to Debian), but the Redhat kernel might not have the right support compiled in. Also, were they using an Ultra160 drive? And an Ultra160 cable? > Looking at the driver, the README.aic7xxx file does not say that the > 29160 (or any other Adaptec Ultra160 card, for that matter) is > supported. Which is a bunch of bullsh*t. i have an Adaptec 39160 and it works beautifully. With regards to the docs, i found this under the "Supported cards/chipsets" section around line 42 of drivers/scsi/README.aic7xxx (in both 2.4.0 and 2.2.17): AHA-29160M -- Nathan Paul Simons, Junior Software Engineer for FSMLabs http://www.fsmlabs.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM in v2.4.0test9
On Wed, 4 Oct 2000, Rik van Riel wrote: > > > First, you have MORE free memory than freepages.high. In this > > > case I really don't see why __alloc_pages() wouldn't give the > > > memory to your processes > > > > Hmm... > > Can't it be a zone problem? > > Free pages is the total free - all zones. > > But suppose you want a page from a specific zone - DMA, the more > > memory you have the less likely that you have a DMA page free... > > Does all test take this into consideration? > > Free_shortage() /should/ take this into consideration, and unless > I'm wrong, it does ;) Also, a zone problem CANNOT cause the problem in David's 16MB test ... (this is getting stranger and stranger) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 32-bit pid_t / security
On Wed, 4 Oct 2000, Mark Hahn wrote: > > Linux 2.2.17 only allows 255 processes at any one time. Is this a > ... > > Can't fork any more after 255 processes > > ulimit -u > > getting back OT, current entry-level PCs (duron/600) can easily > do 7000 fork/wait pairs per second. Maybe I have a broken 'something', but: Script started on Wed Oct 4 13:04:04 2000 $ ulimit -u 32767 $ exit exit Script done on Wed Oct 4 13:04:15 2000 Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 32-bit pid_t / security
On Wed, 4 Oct 2000, Michael van den broek wrote: > > > On Wed, 4 Oct 2000, Richard B. Johnson wrote: > > > On Tue, 3 Oct 2000, Brett Frankenberger wrote: > > > > > > > > > > S/390 folks run 70,000 sessions active within the same 60 second period off > > > > one big box. Not on Linux (yet ;)) but its worth bearing in mind. > > > > > > > Linux 2.2.17 only allows 255 processes at any one time. Is this a > > 'feature'. If so, there is no security to be gained by having 32-bit > > pids wrap at 32-bits. Note they already are 32 bits. > > > > Hya, > > Did you raise the max process ulimit ?, > > the standard limit is: 256 processes > > greets, > > Michael > To the best of my knowledge, I don't have ulimits turned on! Script started on Wed Oct 4 13:01:30 2000 $ ulimit unlimited $ exit Script done on Wed Oct 4 13:01:36 2000 Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM in v2.4.0test9
On Wed, 4 Oct 2000, Roger Larsson wrote: > Rik van Riel wrote: > > On Wed, 4 Oct 2000, David Weinehall wrote: > > > > > Running the included program on a clean v2.4.0test9 kernel I can > > > hang the computer practically in no time. > > > > > What seems most strange is that the doesn't even get depleated. > > > The machine still answers to SysRq and ping, but nothing else. > > > > Looking again at this report in more detail, something > > very strange is going on ... > > > > > This is what I got from SysRq+M (manual copy): > > > > > > Free pages: 500 kB (0 highmem) > > > Active: 8 inactive dirty: 1009, inactive clean:0 > > > free: 125 (31 62 93) > > > > First, you have MORE free memory than freepages.high. In this > > case I really don't see why __alloc_pages() wouldn't give the > > memory to your processes > > > > Hmm... > Can't it be a zone problem? > Free pages is the total free - all zones. > But suppose you want a page from a specific zone - DMA, the more > memory you have the less likely that you have a DMA page free... > Does all test take this into consideration? Free_shortage() /should/ take this into consideration, and unless I'm wrong, it does ;) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM in v2.4.0test9
Rik van Riel wrote: > > On Wed, 4 Oct 2000, David Weinehall wrote: > > > Running the included program on a clean v2.4.0test9 kernel I can > > hang the computer practically in no time. > > > What seems most strange is that the doesn't even get depleated. > > The machine still answers to SysRq and ping, but nothing else. > > Looking again at this report in more detail, something > very strange is going on ... > > > This is what I got from SysRq+M (manual copy): > > > > Free pages: 500 kB (0 highmem) > > Active: 8 inactive dirty: 1009, inactive clean:0 > > free: 125 (31 62 93) > > First, you have MORE free memory than freepages.high. In this > case I really don't see why __alloc_pages() wouldn't give the > memory to your processes > Hmm... Can't it be a zone problem? Free pages is the total free - all zones. But suppose you want a page from a specific zone - DMA, the more memory you have the less likely that you have a DMA page free... Does all test take this into consideration? > > Free swap: 64772 > > And there is tons of swap free... > > Are you absolutely sure this is VM related? This almost looks > like the system puts a in a read request but the request queue > doesn't get unplugged, or something strange like that ... > > There is more than enough memory to satisfy all VM requests and > the loop in __alloc_pages() is straightforward enough to give > your processes their memory without strange bugs ... > > regards, > > Rik > -- > "What you're running that piece of shit Gnome?!?!" >-- Miguel de Icaza, UKUUG 2000 > > http://www.conectiva.com/ http://www.surriel.com/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ -- Home page: http://www.norran.net/nra02596/ - 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: cannot connect to linuxtoday.com 80 with test9-pre9
On Wed, Oct 04, 2000 at 09:34:18AM -0700, Christoph Lameter wrote: > Is there something wrong with the tcp stack? More with their firewall. But try echo 0 > /proc/sys/net/ipv4/tcp_ecn -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 32-bit pid_t / security
> Linux 2.2.17 only allows 255 processes at any one time. Is this a ... > Can't fork any more after 255 processes ulimit -u getting back OT, current entry-level PCs (duron/600) can easily do 7000 fork/wait pairs per second. - 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/
cannot connect to linuxtoday.com 80 with test9-pre9
Is there something wrong with the tcp stack? bash-2.04$ ping linuxtoday.com PING linuxtoday.com (63.236.72.248) from 216.59.82.89 : 56 data bytes 64 bytes from 63.236.72.248: icmp_seq=0 ttl=244 time=103.7 ms 64 bytes from 63.236.72.248: icmp_seq=1 ttl=244 time=104.3 ms --- linuxtoday.com ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 103.7/104.0/104.3 ms bash-2.04$ telnet linuxtoday.com 80 Trying 63.236.72.248... telnet: Unable to connect to remote host: Connection refused bash-2.04$ - 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: 32-bit pid_t / security
On Wed, 4 Oct 2000, Richard B. Johnson wrote: > On Tue, 3 Oct 2000, Brett Frankenberger wrote: > > > > > > > S/390 folks run 70,000 sessions active within the same 60 second period off > > > one big box. Not on Linux (yet ;)) but its worth bearing in mind. > > > > Linux 2.2.17 only allows 255 processes at any one time. Is this a > 'feature'. If so, there is no security to be gained by having 32-bit > pids wrap at 32-bits. Note they already are 32 bits. > Hya, Did you raise the max process ulimit ?, the standard limit is: 256 processes greets, Michael - 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: Request for net guru help: waitqueue oops
On Wed, 4 Oct 2000, Petko Manolov wrote: > > The timer routines (there are 4) are used to switch hardware states and > > must therefore be mutually exclusive with respect to the interrupt handler. > > There are no bottom halves used in this driver. Andrew Morton suggested > > that the problem could be in my use of the skb pointers, which seems > > a likely candidate. I'll check that. > > It might be, but it might not. Be careful about locking and calling > procedures which can sleep from interrupt context. > > Sorry if i am not enough specific, i haven't seen the code ;-) I have found another driver in the standard kernel that also causes this oops and have posted to linux-net (as this appears to be networking related). Thanks -- Hans. - 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: Proposing patches for Linux 2.2.1[89] ...
On Wed, Oct 04, 2000 at 06:15:14PM +0200, Richard Ems wrote: > It's great that the NFS patches got into 2.2.18, but why only the client > and not the server patches? Having clients capable of NFSv3 but no > servers doesn't make much sense IMHO! How shall I test the NFSv3 > patches whitout servers capable of NFSv3! Oh, just the NFSv3 client makes lots of sense. It's made our day here. Gone are problems with communication vs Solaris & AIX servers. Gone are the speed-problems. All in all, just the client made us party. Because our web-server get's its data via NFS. Of course, we'd be happy to get the NFSv3 server patches in too, but I think Alan is right here; be careful and take one step at a time. > It would be great to see Dave Higgen's patches get into 2.2.18 ... I'd opt for early in v2.2.19pre instead. + the NLM4 support. I'm quite annoyed by now getting all those "Service not supported" messages. > And for 2.2.19 ... > > What about autofs version 4 ? I have no opinion here. > And the badram patch? Works great here on 2 machines, UP and SMP! No > need to buy new RAM modules ... > > Great work, thank you all a lot! > > Having fun with linux ... Don't we all?! :^) /David Weinehall _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
2.4.0-test9 load problem
Hi I have a Dual Pentium III 500 Mhz machine. It has 1GB of memory, an internal amimegaraid controller, two additional scsi ultra-wide controller sym53c875E (using sym53c8xx.o) and acenic gigabit ethernet card. I'm patching every kernel to use vlan (802.1Q) and reiserfs. Currently a 2.4.0-test4 kernel i running on it and it is really stable. uptime 2 months. But no support for the 1GB of memory. Just the ~900 MB. I decided to use the newest patch for reiserfs and vlan and the newest kernel. 2.4.0-test8 and 2.4.0-test9. Both kernels had the 4GB support enabled. They boot fine but the load keeps rising. Sendmail didn't start anymore and the ftpserver (proftpd), though connections were established, didn't let you transfer anything. There was no real load on the computer but the load kept rising until it reached 150, which was the point where i rebooted the thing an switched back to 2.4.0-test4. Adrian - 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: VM in v2.4.0test9
I'd second that this is most likely a VM related problem. Last few days I sent you an example that I would make system hang simply by doing a mkfs on 90 GB file system. This happens when low 1GB memory is used up (but I still have high 1GB available). I think David probably ran into the same problem as I did. I'd trace the problem down a bit. It seems that the system goes into a loop that consists of the following call sequence: alloc_pages --> try_to_free_pages --> do_try_to_free_pages (but doesn't seem to go through page_launder in do_try_to_free_pages) --> kmem_cache_reap (so skipped the refill_inactive() in the if statement) --> backto try_again in alloc_pages. If I kill mkfs, the system would go on nicely for some small applications. It is still a bit slow. If I do a "make bzImage", the system would hang again. If I look at the Sysrq output, I had more than 2000 pages available in inactive_clean list. I wonder why alloc_pages doesn't take it. I had no problem with these kinds of things with test6 or test7. Ying Rik van Riel <[EMAIL PROTECTED]>@vger.kernel.org on 10/04/2000 09:31:21 AM Sent by: [EMAIL PROTECTED] To: David Weinehall <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED], Linus Torvalds <[EMAIL PROTECTED]> Subject: Re: VM in v2.4.0test9 On Wed, 4 Oct 2000, David Weinehall wrote: > Running the included program on a clean v2.4.0test9 kernel I can > hang the computer practically in no time. > What seems most strange is that the doesn't even get depleated. > The machine still answers to SysRq and ping, but nothing else. Looking again at this report in more detail, something very strange is going on ... > This is what I got from SysRq+M (manual copy): > > Free pages: 500 kB (0 highmem) > Active: 8 inactive dirty: 1009, inactive clean:0 > free: 125 (31 62 93) First, you have MORE free memory than freepages.high. In this case I really don't see why __alloc_pages() wouldn't give the memory to your processes > Free swap: 64772 And there is tons of swap free... Are you absolutely sure this is VM related? This almost looks like the system puts a in a read request but the request queue doesn't get unplugged, or something strange like that ... There is more than enough memory to satisfy all VM requests and the loop in __alloc_pages() is straightforward enough to give your processes their memory without strange bugs ... regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - 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/
Proposing patches for Linux 2.2.1[89] ...
It's great that the NFS patches got into 2.2.18, but why only the client and not the server patches? Having clients capable of NFSv3 but no servers doesn't make much sense IMHO! How shall I test the NFSv3 patches whitout servers capable of NFSv3! It would be great to see Dave Higgen's patches get into 2.2.18 ... And for 2.2.19 ... What about autofs version 4 ? And the badram patch? Works great here on 2 machines, UP and SMP! No need to buy new RAM modules ... Great work, thank you all a lot! Having fun with linux ... richard -- Richard Ems ... e-mail: [EMAIL PROTECTED] ... Computer Science, University of Hamburg - 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: VM in v2.4.0test9
On Wed, Oct 04, 2000 at 01:01:21PM -0300, Rik van Riel wrote: > On Wed, 4 Oct 2000, David Weinehall wrote: > > > Running the included program on a clean v2.4.0test9 kernel I can > > hang the computer practically in no time. > > > What seems most strange is that the doesn't even get depleated. > > The machine still answers to SysRq and ping, but nothing else. > > Looking again at this report in more detail, something > very strange is going on ... > > > This is what I got from SysRq+M (manual copy): > > > > Free pages: 500 kB (0 highmem) > > Active: 8 inactive dirty: 1009, inactive clean:0 > > free: 125 (31 62 93) > > First, you have MORE free memory than freepages.high. In this > case I really don't see why __alloc_pages() wouldn't give the > memory to your processes Beats the hell out of me. > > Free swap: 64772 > > And there is tons of swap free... > > Are you absolutely sure this is VM related? This almost looks Nope. All I'm sure of is that the v2.2.xx kernels doesn't show the same behaviour, so it _shouldn't_ (but you never know...) be broken hardware. Of course, the v2.4 might stress the memory harder or something like that. > like the system puts a in a read request but the request queue > doesn't get unplugged, or something strange like that ... > > There is more than enough memory to satisfy all VM requests and > the loop in __alloc_pages() is straightforward enough to give > your processes their memory without strange bugs ... Yup. If you want to, I can put some debugging printk's into the kernel whereever you might want them and run more tests. I don't compile the kernel on this machine, so I have no problems recompiling. And it's a dedicated test-machine anyway, so there's nothing on that machine which I'd cry over if lost. I'm about to perform the same test on a K6-3/350 with 64 MB mem and >200 MB swap now, just for the fun of it. /David _ _ // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
esound over tcp problem with linux-2.4.0-test[89]
Package: esound
Version: 0.2.19
i've emailed various people about this already, but i've figured out a
couple new things.
basically, when i added ram to my linux-2.4.0-test8 box taking it from
96M to 192M of ram. esd over tcpip started popping, hesitating,
distorting. if i limit the memory at kernel boot to 127M (and no
more) it works fine. also if i convince esd to use unix sockets
(which took a patch and recompile from debian source) it also works
with any my 192M ram. tcp seems broken in stock esound source too.
other people have confirmed this problem.
is this a kernel problem or an esd problem? thank you.
}John Flinchbaugh{__
| [EMAIL PROTECTED] http://www.hjsoft.com/~glynis/ |
~~Powered by Linux: Reboots are for hardware upgrades only~~
-
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: VM in v2.4.0test9
On Wed, 4 Oct 2000, David Weinehall wrote: > Running the included program on a clean v2.4.0test9 kernel I can > hang the computer practically in no time. > What seems most strange is that the doesn't even get depleated. > The machine still answers to SysRq and ping, but nothing else. Looking again at this report in more detail, something very strange is going on ... > This is what I got from SysRq+M (manual copy): > > Free pages: 500 kB (0 highmem) > Active: 8 inactive dirty: 1009, inactive clean:0 > free: 125 (31 62 93) First, you have MORE free memory than freepages.high. In this case I really don't see why __alloc_pages() wouldn't give the memory to your processes > Free swap: 64772 And there is tons of swap free... Are you absolutely sure this is VM related? This almost looks like the system puts a in a read request but the request queue doesn't get unplugged, or something strange like that ... There is more than enough memory to satisfy all VM requests and the loop in __alloc_pages() is straightforward enough to give your processes their memory without strange bugs ... regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM in v2.4.0test9
On Wed, 4 Oct 2000, David Weinehall wrote:
> On Wed, Oct 04, 2000 at 12:31:13PM -0300, Rik van Riel wrote:
> > On Wed, 4 Oct 2000, David Weinehall wrote:
> >
> > > Running the included program on a clean v2.4.0test9 kernel I can
> > > hang the computer practically in no time. The only other
> >
> > [OUT OF MEMORY PROGRAM]
> >
> > > runnning process that can be of interest is dnetc. Running the
> > > same on a v2.2.xx kernel will just depleat the memory then kill
> > > the offending process, leaving everything nice and dandy.
> >
> > Handling out-of-memory in a clean and predictable way is the
> > next thing on the feature list. I'll add it RSN (I'm reasonably
> > sure now that the current VM features are stable ... time for
> > OOM handling).
> >
> > > What seems most strange is that the doesn't even get depleated.
> > > The machine still answers to SysRq and ping, but nothing else.
>
> I missed out a swap above ("is that the swap doesn't")
> > We do that on purpose. This would allow eg. swap-over-nbd
> > to send out TCP packets, even though all "normal" allocations
> > are blocked on low memory.
>
> Mmmm, still, why doesn't it at least begin to swap?!
Hmmm, that shouldn't happen. The box should continue to run
until swap has been depleted and memory is almost gone...
regards,
Rik
--
"What you're running that piece of shit Gnome?!?!"
-- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8 on SPARC build failure
On Wed, 4 Oct 2000, Jakub Jelinek wrote: > This does tell nothing if the pcibios thing is fixed or not, because you > most probably did not configure PCI on your sparc32 (why would you do that, > when you don't have a JavaStation?). > So you have to either look at the code or configure PCI in... Of course it does. When I compiled it before I didn't have PCI support on either, but it tried to compile it anyways, and barfed and died. It no longer barfs and dies, so yes, it is fixed. :) Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 32-bit pid_t / security
On Tue, 3 Oct 2000, Brett Frankenberger wrote:
> >
> > S/390 folks run 70,000 sessions active within the same 60 second period off
> > one big box. Not on Linux (yet ;)) but its worth bearing in mind.
>
Linux 2.2.17 only allows 255 processes at any one time. Is this a
'feature'. If so, there is no security to be gained by having 32-bit
pids wrap at 32-bits. Note they already are 32 bits.
Script started on Wed Oct 4 11:56:25 2000
cat zzz.c
#include
#include
main() {
printf("Length of pid_t is %u\n", sizeof(pid_t));
}
# gcc -o zzz zzz.c
# ./zzz
Length of pid_t is 4
# exit
exit
Script done on Wed Oct 4 11:56:44 2000
Script started on Wed Oct 4 11:48:14 2000
# cat xxx.c
#include
#include
#include
void reaper(int unused) {
while(wait3(&unused, WNOHANG, 0) > 0)
;
}
main() {
unsigned long count;
count = 0;
setgid();
setuid();
setsid();
signal(SIGCHLD, reaper);
for(;;) {
switch(fork())
{
case 0:
pause();
exit(0);
case -1:
fprintf(stderr, "Can't fork any more after %lu processes\n", count);
kill(-1, 9);
exit(0);
default:
count++;
break;
}
}
}
# gcc -o xxx xxx.c
# ./xxx
Can't fork any more after 255 processes
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: execve replacement.
John Levon wrote: > > On Wed, 4 Oct 2000, [iso-8859-1] Abel Muñoz Alcaraz wrote: > > > I need that somebody says to my module when a user application has started > > or finished, and what is its name and pid. > > > you do not need to trace system calls then. Provide a misc char device, > and get the user app to open it. Then you can trace its existence via the > open/close routines. I think he meant 'any user application'. -- Daniel - 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: Would you please help me?
On Wed, 4 Oct 2000, Huang QingHua wrote: > When I am studying source code.I can not understand the > relation between "reading a page from" and "reading a block from > disk". A "page" is the hardware VM page size (usually 4kB or 8 kB) A "block" is usually the size in which the filesystem allocates disk space (usually 1kB to 4kB). regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VM in v2.4.0test9
On Wed, 4 Oct 2000, Chris Evans wrote: > On Wed, 4 Oct 2000, Rik van Riel wrote: > > > Handling out-of-memory in a clean and predictable way is the > > next thing on the feature list. I'll add it RSN (I'm reasonably > > sure now that the current VM features are stable ... time for > > OOM handling). > > Stable is good. But before moving on, wouldn't it be nice to > have some test8 vs. test9 vs. 2.2.14 (or so) benchmarks, to > confirm it was worth the pain of a whole pre-patch series > weeding out deadlocks? Go ahead. I'm interested in the results ;) Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kapmd cpu usage
On Wed, 4 Oct 2000, Stephen Rothwell wrote: > Geoffrey Gallaway <[EMAIL PROTECTED]> writes: > > in 2.4.0-test9, kampd is taking up between 70% and 80% of cpu usage on my > > Good! > > Seriously, the kapmd is doing the job of yje idle loop. The > processor is almost always asleep, but the time just gets > accounted to kapmd. I have the idea we should really fix this dirty accounting thing and properly account kapmd time to idle time. regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[ot] Re: MIME QP encoded good/bad ...
Matti Aarnio wrote: > Least of the wonders being increasing number of EBCDIC systems appearing in the net. EBCDIC code: Extended Binary Coded Decimal Interchange Code - a platypus if there ever was one. Code - I thought I already knew that Interchange - So there's a code that doesn't? Decimal - Great, support those Lixie tubes Coded - See 'Code' Binary - No, you're *kidding* Extended - Wow, BCD is great! Let's make it even better! People have ten fingers to count on; computers have two and that's why we have conversion routines. The concept took a little while to sink in with some people. -- Daniel - 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: VM in v2.4.0test9
On Wed, 4 Oct 2000, Rik van Riel wrote: > Handling out-of-memory in a clean and predictable way is the > next thing on the feature list. I'll add it RSN (I'm reasonably > sure now that the current VM features are stable ... time for > OOM handling). Stable is good. But before moving on, wouldn't it be nice to have some test8 vs. test9 vs. 2.2.14 (or so) benchmarks, to confirm it was worth the pain of a whole pre-patch series weeding out deadlocks? Cheers Chris - 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: VM in v2.4.0test9
On Wed, Oct 04, 2000 at 12:31:13PM -0300, Rik van Riel wrote:
> On Wed, 4 Oct 2000, David Weinehall wrote:
>
> > Running the included program on a clean v2.4.0test9 kernel I can
> > hang the computer practically in no time. The only other
>
> [OUT OF MEMORY PROGRAM]
>
> > runnning process that can be of interest is dnetc. Running the
> > same on a v2.2.xx kernel will just depleat the memory then kill
> > the offending process, leaving everything nice and dandy.
>
> Handling out-of-memory in a clean and predictable way is the
> next thing on the feature list. I'll add it RSN (I'm reasonably
> sure now that the current VM features are stable ... time for
> OOM handling).
>
> > What seems most strange is that the doesn't even get depleated.
> > The machine still answers to SysRq and ping, but nothing else.
I missed out a swap above ("is that the swap doesn't")
> We do that on purpose. This would allow eg. swap-over-nbd
> to send out TCP packets, even though all "normal" allocations
> are blocked on low memory.
Mmmm, still, why doesn't it at least begin to swap?!
/David
_ _
// David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander \\
// Project MCA Linux hacker// Dance across the winter sky //
\> http://www.acc.umu.se/~tao/http://www.tux.org/lkml/
Re: PIIX4-ide still not working in 2.4-test9...
On Wed, Oct 04, 2000 at 01:53:34AM -0700, David Ford wrote: > When you enable PIIXn support in the IDE section, make sure you DISABLE PIIXn > tuning which is the very next line. ok i even tryed with a freshly downloaded complete 2.4-test9 tree. nothing to do: just before init comes, i get: ide_dmaproc: chipset supported ide_dma_lostirq func only : 13 any other hint i could try? nice that this non-working kernel is called test but i suspect that the final version will not run either on my laptop :( -- ciao bboett == [EMAIL PROTECTED] http://inforezo.u-strasbg.fr/~bboett http://erm1.u-strasbg.fr/~bboett === the total amount of intelligence on earth is constant. human population is growing - 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: VM in v2.4.0test9
On Wed, 4 Oct 2000, David Weinehall wrote: > Running the included program on a clean v2.4.0test9 kernel I can > hang the computer practically in no time. The only other [OUT OF MEMORY PROGRAM] > runnning process that can be of interest is dnetc. Running the > same on a v2.2.xx kernel will just depleat the memory then kill > the offending process, leaving everything nice and dandy. Handling out-of-memory in a clean and predictable way is the next thing on the feature list. I'll add it RSN (I'm reasonably sure now that the current VM features are stable ... time for OOM handling). > What seems most strange is that the doesn't even get depleated. > The machine still answers to SysRq and ping, but nothing else. We do that on purpose. This would allow eg. swap-over-nbd to send out TCP packets, even though all "normal" allocations are blocked on low memory. regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: wasting time on page fault
Andi Kleen wrote: > > On Wed, Oct 04, 2000 at 11:00:41AM -0400, Brian Gerst wrote: > > Mikulas Patocka wrote: > > > > > > Hi. > > > > > > arch/i386/kernel/entry.S > > > xchgl %eax, ORIG_EAX(%esp) # orig_eax (get the error code. ) > > > movl %esp,%edx > > > xchgl %ecx, ES(%esp)# get the address and save es. > > > pushl %eax # push the error code > > > > > > xchg with memory operand has implicit lock prefix and is slooow. It is > > > really bad idea to have it in page fault handler. > > > > Thank the small register set of the x86 for this. If you can come up > > with a way to do it in fewer cycles and preserve all the registers and > > stack layout, your input is welcome. > > You don't need to preserve any registers which are not %eax, they are already > saved. There are tons of ways to do it via the stack or with a temporary > register. You are correct. That's what I get for posting before my normal dose of caffeine. Something like this should work (untested): --- entry.S Tue Oct 3 13:05:07 2000 +++ entry.S.new Wed Oct 4 11:29:45 2000 @@ -305,16 +305,18 @@ pushl %ebx cld movl %es,%ecx - xchgl %eax, ORIG_EAX(%esp) # orig_eax (get the error code. ) + movl ORIG_EAX(%esp), %esi # get the error code + movl ES(%esp), %edi # get the address movl %esp,%edx - xchgl %ecx, ES(%esp)# get the address and save es. - pushl %eax # push the error code - pushl %edx + movl %eax, ORIG_EAX(%esp) + movl %ecx, ES(%esp) + pushl %esi # push the error code + pushl %edx # push pt_regs pointer movl $(__KERNEL_DS),%edx movl %edx,%ds movl %edx,%es GET_CURRENT(%ebx) - call *%ecx + call *%edi addl $8,%esp jmp ret_from_exception -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9 on SPARC64: Undefined symbols in modules
> Lots of: > > __atomic_add > __atomic_sub > __test_and_set_bit > __test_and_clear_bit > > (This machine is the result of transplanting the disks with RH 6.2 + > updates + local hacks from a SPARC, so this might be an artifact; but I > don't think so). I am not seeing it here. Are the symbols visible in /proc/ksyms? Anton - 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/
