ignore
Is there any event lately in vger kernel-list? I haven't been being received mails from it since Dec 17. -- "Where there is a will, there is a way." [EMAIL PROTECTED] For the future of you and me!hitel: jinbo21 - 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.2.19pre2
Andrea Arcangeli wrote:
>
> > > Other thing about your patch, adding TASK_EXCLUSIVE to
> > > wake_up/wake_up_interruptible is useless.
> >
> > This enables wake_up_all().
>
> It is useless as it is in 2.2.19pre2: there's no wake_up_all in 2.2.19pre2.
#define wake_up_all(x) __wake_up((x),TASK_UNINTERRUPTIBLE | TASK_INTERRUPTIBLE)
> > Anyway, this is all just noise.
> >
> > The key question is: which of the following do we want?
> >
> > a) A simple, specific accept()-accelerator, and 2.2 remains without
> >an exclusive wq API or
>
> To make the accellerator we need a minimal wake-one support. So a) doesn't
> make sense to me.
It makes heaps of sense. We've introduced into 2.2 an API
which has the same appearance as one in 2.4, but which is
subtly broken wrt the 2.4 one.
I suggest you change the names to something other than
add_waitqueue_exclusive() and TASK_EXCLUSIVE, add a
cautionary comment and then go ahead with your patch.
Except for this bit, which looks slightly fatal:
/*
* We can drop the read-lock early if this
* is the only/last process.
*/
if (next == head) {
read_unlock(_lock);
wake_up_process(p);
goto out;
}
Once the waitqueue_lock has been dropped, the task at `p'
is free to remove itself from the waitqueue and exit. This
CPU can then try to wake up a non-existent task, no?
-
-
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: recommended gcc compiler version
I'm sorry but this is incorrect. The recommended compiler version is not longer the same for the 2.2 and 2.4 kernels. >From Documentation/Changes in 2.4 (test12): "The recommended compiler for the kernel is egcs 1.1.2 (gcc 2.91.66), and it should be used when you need absolute stability. You may use gcc 2.95.2 instead if you wish, although it may cause problems. Later versions of gcc have not received much testing for Linux kernel compilation, and there are almost certainly bugs (mainly, but not exclusively, in the kernel) that will need to be fixed in order to use these compilers. In any case, using pgcc instead of egcs or plain gcc is just asking for trouble. Note that gcc 2.7.2.3 is no longer a supported kernel compiler. The kernel no longer works around bugs in gcc 2.7.2.3 and, in fact, will refuse to be compiled with it." For 2.2.18: " Note that the latest compilers (pgcc, gcc 2.95) may do Bad Things while compiling your kernel, particularly if absurd optimizations (like -O9) are used. Caveat emptor. In general, however, gcc-2.7.2.3 and egcs 1.1.2 are known to be stable on x86, while gcc 2.95 and others have not been as thoroughly tested yet." So egcs-1.1.2 is good for either, 2.7.2 is OK for 2.2, bad for 2.4. 2.95.2 and later are risky. RedHat just released a bugfixed "2.96" which is an unknown quantity AFAIK. Anybody brave enough to try it should probably post their results. No compiler is bug-free. In general, you will get the most reliable results when you use what most everybody else is using, 'cos that's how the bugs get fixed. YMMV :-) Regards, Tim On Fri, Dec 22, 2000 at 01:19:07AM -0500, Matthew D. Pitts wrote: > Robert, > gcc 2.7.2.3 is the safest, but egcs 1.1.2 will work. any kernels built with > gcc 2.95.x work but can be buggy. > > Matthew Pitts > [EMAIL PROTECTED] > > - Original Message - > From: Robert B. Easter <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, December 21, 2000 11:20 PM > Subject: recommended gcc compiler version > > > > This is a newbie question, but what are the recommended gcc compiler > versions > > for compiling, > > > > Linux 2.2.18? > > > > Linux 2.4.0? > > > > > > I'd rather use the recommended version than not and have difficult bugs. > > > > Thanks. If there is a FAQ, kindy direct me to it, or, if this info isn't > in > > there specificly, perhaps a FAQ maintainer can add this stuff. > > > > -- > > Robert B. Easter [EMAIL PROTECTED] - > > - CompTechNews Message Board http://www.comptechnews.com/ - > > - CompTechServ Tech Services http://www.comptechserv.com/ - > > -- http://www.comptechnews.com/~reaster/ > > - > > 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/ -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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: recommended gcc compiler version
Robert B. Easter wrote: > This is a newbie question, but what are the recommended gcc compiler versions > for compiling, This is discussed in the Documentation/Changes file, in a given kernel's source. Brief summaries follow (which assume you're using an x86 CPU). > Linux 2.2.18? gcc 2.7.2.3 is safest, but egcs 1.1.2 should be safe even for mission-critical stuff. gcc 2.95.2 seems to work for many people, but isn't necessarily safe. > Linux 2.4.0? egcs 1.1.2 is the safe choice, but gcc 2.95.2 seems to work. gcc 2.7.2.3 miscompiles 2.4 more often than not, so 2.4 has a preprocessor check that stops any attempts to compile it with 2.7.2.3. -Barry K. Nathan <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
The NSA's Security-Enhanced Linux (fwd)
Anyone looked into this? -- Mike A. Harris - Linux advocate - Open source advocate This message is copyright 2000, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- -- Forwarded message -- Date: Fri, 22 Dec 2000 00:14:42 +0100 From: Ralf-Philipp Weinmann <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: The NSA's Security-Enhanced Linux citing http://www.nsa.gov/selinux/background.html: "Researchers in the Information Assurance Research Office of the National Security Agency (NSA) worked with Secure Computing Corporation (SCC) to develop a strong, flexible mandatory access control architecture based on Type Enforcement, a mechanism first developed for the LOCK system. The NSA and SCC developed two Mach-based prototypes of the architecture: DTMach and DTOS. The NSA and SCC then worked with the University of Utah's Flux research group to transfer the architecture to the Fluke research operating system. During this transfer, the architecture was enhanced to provide better support for dynamic security policies. This enhanced architecture was named Flask. The NSA is now integrating the Flask architecture into the Linux operating system to transfer the technology to a larger developer and user community." [...] The result is available for download at the above URL as well. Has anyone here toyed with it already ? Cheers, -Ralf -- Ralf-P. Weinmann <[EMAIL PROTECTED]> PGP fingerprint: 2048/46C772078ACB58DEF6EBF8030CBF1724 Emacs is my operating system, and Linux its device driver. -- Bake Timmons - 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-test13 drivers/net/pcmcia fix
The files in drivers/net/pcmcia are skipped when configured to compile as modules. Here's a patch (against test13-pre4) for the Makefile: --- linux.old/drivers/net/Makefile Thu Dec 21 22:14:46 2000 +++ linux/drivers/net/Makefile Thu Dec 21 23:38:20 2000 @@ -8,7 +8,7 @@ obj-n := obj-:= -mod-subdirs := wan +mod-subdirs := pcmcia wan O_TARGET := net.o - 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: recommended gcc compiler version
Robert, gcc 2.7.2.3 is the safest, but egcs 1.1.2 will work. any kernels built with gcc 2.95.x work but can be buggy. Matthew Pitts [EMAIL PROTECTED] - Original Message - From: Robert B. Easter <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, December 21, 2000 11:20 PM Subject: recommended gcc compiler version > This is a newbie question, but what are the recommended gcc compiler versions > for compiling, > > Linux 2.2.18? > > Linux 2.4.0? > > > I'd rather use the recommended version than not and have difficult bugs. > > Thanks. If there is a FAQ, kindy direct me to it, or, if this info isn't in > there specificly, perhaps a FAQ maintainer can add this stuff. > > -- > Robert B. Easter [EMAIL PROTECTED] - > - CompTechNews Message Board http://www.comptechnews.com/ - > - CompTechServ Tech Services http://www.comptechserv.com/ - > -- http://www.comptechnews.com/~reaster/ > - > 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.0test12pre3ac4
On Fri, 22 Dec 2000, Alan Cox wrote:
> o Quota fixes/updates (Jan Kara)
This patch (?) to breaks compiling without quota's...
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.13pre3/mm/vmscan.c linux.ac/mm/vmscan.c
--- linux.13pre3/mm/vmscan.cTue Dec 19 13:30:29 2000
+++ linux.ac/mm/vmscan.cThu Dec 21 21:21:00 2000
@@ -943,6 +943,7 @@
*/
shrink_dcache_memory(priority, gfp_mask);
shrink_icache_memory(priority, gfp_mask);
+ shrink_dqcache_memory(priority, gfp_mask);
/*
* Then, try to page stuff out..
@@ -1004,6 +1005,7 @@
if (free_shortage() || inactive_shortage()) {
shrink_dcache_memory(6, gfp_mask);
shrink_icache_memory(6, gfp_mask);
+ shrink_dqcache_memory(6, gfp_mask);
ret += refill_inactive(gfp_mask, user);
} else {
/*
-
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/
PPPoE trouble
Not entirely sure whether this is the right place to ask support questions, but here goes... I have set up a gateway machine running SuSE 6.4 and kernel 2.4.0-test12 for a family I am staying with in NM. The gateway is running fine on a 28.8 modem now, but the intent is to use it with the ADSL connection (MindSpring). The pppoed appears to be able to contact the PPPoE servers at MindSpring, but cannot access the device to actually make the connection. eth0 is a 3c905 connected directly to the DSL modem. eth1 is a 3c905b connected to the internal LAN. Here's a dump from a connection attempt: frankenstein:~ # pppoed -I eth0 frankenstein:~ # !tail tail -n 11 /var/log/allmessages Dec 21 14:56:14 frankenstein pppoed[4716]: ppp_connect: total retries to go 1 Dec 21 14:56:14 frankenstein pppoed[4716]: PPPoE tag: type=0102 length=001d (AC Name) data (UTF-8): 41021030045982-redback-1.phx2 Dec 21 14:56:14 frankenstein pppoed[4716]: PPPoE tag: type=0101 length=000e (Service name) data (UTF-8): mindspring.com Dec 21 14:56:14 frankenstein pppoed[4716]: PPPoE tag: type=0101 length=0015 (Service name) data (UTF-8): tunnel.mindspring.com Dec 21 14:56:14 frankenstein pppoed[4716]: PPPoE tag: type=0102 length=001d (AC Name) data (UTF-8): 41021030045982-redback-1.phx2 Dec 21 14:56:14 frankenstein pppoed[4716]: PPPoE tag: type=0101 length=000e (Service name) data (UTF-8): mindspring.com Dec 21 14:56:14 frankenstein pppoed[4716]: PPPoE tag: type=0101 length=0015 (Service name) data (UTF-8): tunnel.mindspring.com Dec 21 14:56:14 frankenstein kernel: Registered PPPoX v0.5 Dec 21 14:56:14 frankenstein kernel: Registered PPPoE v0.6.4 Dec 21 14:56:14 frankenstein pppoed[4716]: cannot open /dev/pppox0: No such device Dec 21 14:56:14 frankenstein pppoed[4716]: Exit. frankenstein:~ # ls -l /dev/pppox0 crw-rw 1 root uucp 144, 0 Mar 24 2000 /dev/pppox0 The PPPoX and PPPoE drivers are loaded as modules with no arguments. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a19 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+ -END GEEK CODE BLOCK- - 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] Configure.help for CONFIG_IRDA_OPTIONS
Here is a micropatch to provide a help note for CONFIG_IRDA_OPTIONS. This applies against 2.4.0-test13-pre4. Steven diff -u linux/Documentation/Configure.help.orig linux/Documentation/Configure.help --- linux/Documentation/Configure.help.orig Thu Dec 21 21:16:50 2000 +++ linux/Documentation/Configure.help Thu Dec 21 21:17:12 2000 @@ -16677,6 +16677,10 @@ want to compile it as a module, say M here and read Documentation/modules.txt. +IrDA protocol options +CONFIG_IRDA_OPTIONS + Say Y here if you want to configure any of the following IrDA options. + IrDA Cache last LSAP CONFIG_IRDA_CACHE_LAST_LSAP Say Y here if you want IrLMP to cache the last LSAP used. This makes - 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: No more DoS
From: Michael Peddemors <[EMAIL PROTECTED]> Date: Thu, 21 Dec 2000 20:20:06 -0800 > I think not holding onto any state for an incoming SYN is nothing but > a dream in any serious modern TCP implementation. It can be reduced, > but not eliminated. The former is what most modern stacks have done > to fight these problems. A dream, maybe but hey so were most things that we now take for granted.. Worth kicking around a bit tho... At a minimum you have to remember the MSS value given by the remote host in the initial SYN, it is impossible to avoid this and provide a TCP implementation of any level of quality. The foundations of this person's scheme simply cannot work. 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/
2.4.0-test(4 - 11), iptables 1.1.2 and connect: invalid bug(?)
i have a problem with two machines (one running 2.4.0-t4, and the other 2.4.0-t11). The hardware in both machines is completely different (one is a 486dx4 and the other is a 533MHz celeron). i am starting to think that it is possibly a bug. The 2.4.0-t4 machine is running iptables v1.1.1 and the other is running 1.1.2. The first box is doing masq, port fowarding and normal firewalling stuff. The 2.4.0-t11 box is just doing standard port allow/deny type stuff. The test11 box has been working fine for a few weeks, today I installed openssl, ntop and mrtg. I then went to add some new dns records, and when I restarted bind 9.0.1, I noticed this error: Dec 22 03:00:44 avatar named[8079]: socket.c:921: unexpected error: Dec 22 03:00:44 avatar named[8079]: internal_send: Invalid argument Dec 22 03:00:44 avatar named[8079]: socket.c:921: unexpected error: Dec 22 03:00:44 avatar named[8079]: internal_send: Invalid argument Dec 22 03:00:44 avatar named[8079]: socket.c:921: unexpected error: Dec 22 03:00:44 avatar named[8079]: internal_send: Invalid argument repeated.. named stays as an active process but doesn't do anything. it appears that any kind of tcp/udp connection to any local interface on the server causes this problem. however, if you connect to the interface from a remote machine to the same service, it works fine.. local> telnet 65.27.144.37 80 Trying 65.27.144.37... telnet: Unable to connect to remote host: Invalid argument but if i try telnetting to the same ip on the same port from a remote machine, it works fine. ping also yields the same error: local> ping 65.27.144.37 connect: Invalid argument both machines behave exactly the same. both machines are using kernels without the use of modules (the 486dx4 with 64MB), one even boots from floppy. occasionally (usually during compiles) both the test11 and test4 machines will hardware lock. i have another machine that will do something similar and its running test10 but i don't run iptables on it. the test10 machine is an AMD-k6 III 400MHz with a VIA chipset. The test11 is the 533Mhz with an ALI chipset. i was wondering if anyone else had seen this connect: Invalid argument problem?? thanks -- John Buswell - 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: No more DoS
On Fri, Dec 22, 2000 at 01:24:44PM +1100, Mike OConnor wrote: > Hi > I would like to point who ever is in charge of the TCP stack for the linux > kernel at a site which claims to have a method of eliminate denial of service > (DoS) attacks > http://grc.com/r/nomoredos.htm > With my limited unstanding of TCP and DoS attacks this would seem to be the > answer, instead of a work around. Obviously written by someone with no real world experience with DoS attacks. He seems to think that the majority of DoS attacks are SYN floods and disregards all the rest by saying this will eliminate DoS attacks. In fact, SYN floods have been largely ineffective for some time now and comprise a very small percentage of attacks now. From all appearances, his approach would have no effect on attacks like NAPTHA which try to take advantage of more advanced states in the TCP state machine. He actually should take a look at the "Cookie Crumbs" attacks against ISAKMP/IKE (IPSec) which suffer from the same first packet saved state problem. Those guys haven't solved that problem and that's even a security protocol! Maybe he could be some help there (or learn something). We probably see more incidents of TIES bombing (sending packets with "\r+++ATH0\r" in payloads) to hang up modems than we see SYN flooding lately (IMHO). I recently helped and ISP that was virtually shut down by someone TIES bombing them with ping packets containing the TIES hangup sequence. Once we got THEIR modems fixed, the TIES bombs were hanging up their customers modem's (the ICMP Echo Reply) and we had to design a TIES Bomb packet that would reset the vulnerable customer modems to a safe S register value... Grrr... Quite frankly... My favorite DoS attack is NISNuke (which I researched and documented). His approach would have exactly zero effect in mitigating an NISNuke attack and I can take out and entire network with it (all you need is NIS and finger on the same large network). So he can NOT claim to eliminate DoS attacks since I have a small arsenal of them which would be untouched by his approach. While some DDoS (Distributed Denial of Service) attacks do incorporate SYN flooding, their most profound effect is in the bulk attack areas such as Smurf flooding (ICMP echo to broadcast addresses while spoofing the return address as the targeted party) and UDP data overloads. Those have other solutions (such as router filters which prevent spoofing) which we can't even get implimented, much less a tcp stack state machine redesign! He's got a solution (and an ineffective one at that) that's really in search of a problem. It's highly unlikely that it would even make a miniscule dent in the DoS problem. That's even assuming that it would work (which others such as Dave Miller have stated that it wouldn't). He gets a "nice try" but in the long run it boils down to the expression in the IETF... You vote with working code. Let's see the code in operation and see how it works and stands up. If it works and it more robust in the face of ongoing attacks, all hail! Kudos for all around. If not, then don't tell us how it should be. Demonstrate with working code. I didn't seen ANYTHING on that site but a description of how he thought it should work. Vote with working code... > Cheers > Mike OConnor Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - 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: [RFC] Semaphores used for daemon wakeup
On Fri, 22 Dec 2000, Daniel Phillips wrote:
> But isn't this actually a simple situation? How about:
I had only adapted that example because it had already been posted showing
one way to do it, and so provided something to compare the sv approach to.
> dmabuf_alloc(...)
> {
> while (1) {
> spin_lock(_lock);
> attempt to grab a free buffer;
> spin_unlock(_lock);
> if (success)
>return;
> down(_wait);
> }
> }
> dmabuf_free(...)
> {
> spin_lock(_lock);
> free up buffer;
> spin_unlock(_lock);
> up(_wait);
> }
This does things a little differently than the way the original did it.
I thought the original implied that dmabuf_free() might free up multiple
buffers. There's no indication in the comments that this is the case, but
the original, by using vall_sema(), wakes up all dmabuf_alloc()'s that had
gone to sleep.
The example wasn't meant to be an ideal use of sv's, but merely as an
example of how they could be used to achieve the same behavior as the code
that was posted.
--
Paul Cassella
[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/
recommended gcc compiler version
This is a newbie question, but what are the recommended gcc compiler versions for compiling, Linux 2.2.18? Linux 2.4.0? I'd rather use the recommended version than not and have difficult bugs. Thanks. If there is a FAQ, kindy direct me to it, or, if this info isn't in there specificly, perhaps a FAQ maintainer can add this stuff. -- Robert B. Easter [EMAIL PROTECTED] - - CompTechNews Message Board http://www.comptechnews.com/ - - CompTechServ Tech Services http://www.comptechserv.com/ - -- http://www.comptechnews.com/~reaster/ - 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.2.19pre3
> 2.2.19pre3 [snip] > o Optimise kernel compiler detect, kgcc before(Peter Samuelson) > gcc272 also I get an endless stream of this: kgcc:gcc272:cc:gcc: not found kgcc:gcc272:cc:gcc: not found /bin/sh: -D__KERNEL__: command not found /bin/sh: -D__KERNEL__: command not found /bin/sh: -D__KERNEL__: command not found /bin/sh: -D__KERNEL__: command not found I think the Makefile optimisation needs to be (cut-n-paste): --- Makefile~ Thu Dec 21 21:35:39 2000 +++ MakefileThu Dec 21 21:35:54 2000 @@ -28,7 +28,7 @@ # gcc272 for Debian # otherwise 'cc' # -CCFOUND :=$(shell $(CONFIG_SHELL) scripts/kwhich kgcc gcc272 cc gcc) +CCFOUND :=$(shell $(CONFIG_SHELL) scripts/kwhich kgcc:gcc272:cc:gcc) ## Faster, but requires GNU make 3.78, which postdates Linux 2.2.0 ##CC =$(if $(CROSS_COMPILE),$(CROSS_COMPILE)gcc,$(CCFOUND)) -D__KERNEL__ -I$(HPATH) CC =$(shell if [ -n "$(CROSS_COMPILE)" ]; then echo $(CROSS_COMPILE)gcc; else echo $(CCFOUND); fi) \ M (what's the old saying - the first rule of optimization is don't or something like that... ;) - 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: No more DoS
> Furthermore, it also cannot work because it makes retransmissions > of the SYN/ACK very non-workable. I suppose his TCP stack just hacks > around this by just waiting for the original client SYN to get > retransmitted or something like this. I question whether that can > even work reliably. Be interesting to see his response, but in truth, do we care if it gets retransmitted?? When it does, it does... > I think not holding onto any state for an incoming SYN is nothing but > a dream in any serious modern TCP implementation. It can be reduced, > but not eliminated. The former is what most modern stacks have done > to fight these problems. A dream, maybe but hey so were most things that we now take for granted.. Worth kicking around a bit tho... Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: No more DoS
Not only is this a well written article, and clearer than most other documents (Even Mine :>) but he is dead on track with his basic concepts.. Exactly what I have been looking into over at our company. (Well, close enough) The concept of trusting a SYN packet, has to go.. we have to assume that it is false/bad, and only after receiving the ACK in reply to our SYN/ACK can we start assuming that the previous packets were good.. All IMHO Nice find and a good read for anyone.. I am CC'ing the netfilter list as they might like the read.. in case they haven't read it. (Surprised I haven't seen more discussion on this topic) On Thu, 21 Dec 2000, Mike OConnor wrote: > Hi > > I would like to point who ever is in charge of the TCP stack for the linux > kernel at a site which claims to have a method of eliminate denial of > service (DoS) attacks > > http://grc.com/r/nomoredos.htm > > With my limited unstanding of TCP and DoS attacks this would seem to be the > answer, instead of a work around. > -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
reliable oops in test12: kswapd: submit_bh
i have a server that Oopsed 3 nights in a row at nearly the same time
04:04:{22,26,22} each /second/ night (presumably nightly locate
update) in the same place: in submit_bh while in kswapd.
kernel in question is test12.
machine is K6-233 with a DAC960 that does NFS/dialup/iptables
serving.
Test13-pre3 Ooopses on bootup in nfsd, so I've gone back to test10.
Here are the oopses after being put through ksymoops:
ksymoops 2.3.5 on i586 2.4.0-test10. Options used
-v /boot/vmlinux-2.4.0-test12 (specified)
-K (specified)
-L (specified)
-o /lib/modules/2.4.0-test12/ (specified)
-m /boot/System.map-2.4.0-test12 (specified)
No modules in ksyms, skipping objects
Dec 18 04:04:26 hibernia kernel: Unable to handle kernel NULL pointer dereference at
virtual address 0018
Dec 18 04:04:26 hibernia kernel: c015d3d5
Dec 18 04:04:26 hibernia kernel: *pde =
Dec 18 04:04:26 hibernia kernel: Oops:
Dec 18 04:04:26 hibernia kernel: CPU:0
Dec 18 04:04:26 hibernia kernel: EIP:0010:[submit_bh+5/92]
Dec 18 04:04:26 hibernia kernel: EFLAGS: 00010207
Dec 18 04:04:26 hibernia kernel: eax: ebx: ecx: 0001 edx:
c12c8104
Dec 18 04:04:26 hibernia kernel: esi: 0002 edi: c6ec7f00 ebp: c12ebf48 esp:
c12ebeec
Dec 18 04:04:26 hibernia kernel: ds: 0018 es: 0018 ss: 0018
Dec 18 04:04:26 hibernia kernel: Process kswapd (pid: 3, stackpage=c12eb000)
Dec 18 04:04:26 hibernia kernel: Stack: c0131701 0001 00041300
c10a54e4 00aa 1000
Dec 18 04:04:26 hibernia kernel:c0129dd7 0001 c10a54e4 3001 c12ebf44
1000 00041300 c10a54e4
Dec 18 04:04:26 hibernia kernel:00aa 0040 c12ebf44 0413 30010246
0413 c1ab7600
Dec 18 04:04:26 hibernia kernel: Call Trace: [brw_page+145/164]
[rw_swap_page_base+327/428] [rw_swap_page+117/188] [swap_writepage+14/20]
[page_launder+592/2056] [do_try_to_free_pages+52/128] [generic_unplug_device+0/40]
Dec 18 04:04:26 hibernia kernel: Code: 8b 43 18 a8 04 75 19 68 7f 03 00 00 68 a2 f9 1d
c0 68 05 f7
Using defaults from ksymoops -t elf32-i386 -a i386
Code; Before first symbol
<_EIP>:
Code; Before first symbol
0: 8b 43 18 mov0x18(%ebx),%eax
Code; 0003 Before first symbol
3: a8 04 test $0x4,%al
Code; 0005 Before first symbol
5: 75 19 jne20 <_EIP+0x20> 0020 Before first symbol
Code; 0007 Before first symbol
7: 68 7f 03 00 00push $0x37f
Code; 000c Before first symbol
c: 68 a2 f9 1d c0push $0xc01df9a2
Code; 0011 Before first symbol
11: 68 05 f7 00 00push $0xf705
ksymoops 2.3.5 on i586 2.4.0-test10. Options used
-v /boot/vmlinux-2.4.0-test12 (specified)
-K (specified)
-L (specified)
-o /lib/modules/2.4.0-test12/ (specified)
-m /boot/System.map-2.4.0-test12 (specified)
No modules in ksyms, skipping objects
Dec 16 04:04:22 hibernia kernel: Unable to handle kernel NULL pointer dereference at
virtual address 0018
Dec 16 04:04:22 hibernia kernel: c015d3d5
Dec 16 04:04:22 hibernia kernel: *pde =
Dec 16 04:04:22 hibernia kernel: Oops:
Dec 16 04:04:22 hibernia kernel: CPU:0
Dec 16 04:04:22 hibernia kernel: EIP:0010:[submit_bh+5/92]
Dec 16 04:04:22 hibernia kernel: EFLAGS: 00010207
Dec 16 04:04:22 hibernia kernel: eax: ebx: ecx: 0001 edx:
c12c8104
Dec 16 04:04:22 hibernia kernel: esi: 0002 edi: c40a6b00 ebp: c12ebf48 esp:
c12ebeec
Dec 16 04:04:22 hibernia kernel: ds: 0018 es: 0018 ss: 0018
Dec 16 04:04:22 hibernia kernel: Process kswapd (pid: 3, stackpage=c12eb000)
Dec 16 04:04:22 hibernia kernel: Stack: c0131701 0001 000a0500
c10a7a9c 00ba 1000
Dec 16 04:04:22 hibernia kernel:c0129dd7 0001 c10a7a9c 3001 c12ebf44
1000 000a0500 c10a7a9c
Dec 16 04:04:22 hibernia kernel:00ba 0040 c12ebf44 0a05 30010246
0a05 c6f633e0
Dec 16 04:04:22 hibernia kernel: Call Trace: [brw_page+145/164]
[rw_swap_page_base+327/428] [rw_swap_page+117/188] [swap_writepage+14/20]
[page_launder+592/2056] [do_try_to_free_pages+52/128] [generic_unplug_device+0/40]
Dec 16 04:04:22 hibernia kernel: Code: 8b 43 18 a8 04 75 19 68 7f 03 00 00 68 a2 f9 1d
c0 68 05 f7
Using defaults from ksymoops -t elf32-i386 -a i386
Code; Before first symbol
<_EIP>:
Code; Before first symbol
0: 8b 43 18 mov0x18(%ebx),%eax
Code; 0003 Before first symbol
3: a8 04 test $0x4,%al
Code; 0005 Before first symbol
5: 75 19 jne20 <_EIP+0x20> 0020 Before first symbol
Code; 0007 Before first symbol
7: 68 7f 03 00 00push $0x37f
Code; 000c Before first symbol
c: 68 a2 f9 1d c0push
Re: No more DoS
This has already been discused here and on slashdot, on 9/25/2000. On Fri, Dec 22, 2000 at 01:24:44PM +1100, Mike OConnor wrote: > I would like to point who ever is in charge of the TCP stack for the linux > kernel at a site which claims to have a method of eliminate denial of service > (DoS) attacks > > http://grc.com/r/nomoredos.htm -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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: [RFC] changes to buffer.c (was Test12 ll_rw_block error)
On Thu, 21 Dec 2000, Andreas Dilger wrote: > Marcelo Tosatti writes: > > It seems your code has a problem with bh flush time. > > > > In flush_dirty_buffers(), a buffer may (if being called from kupdate) only > > be written in case its old enough. (bh->b_flushtime) > > > > If the flush happens for an anonymous buffer, you'll end up writing all > > buffers which are sitting on the same page (with block_write_anon_page), > > but these other buffers are not necessarily old enough to be flushed. > > This isn't really a "problem" however. The page is the _maximum_ age of > the buffer before it needs to be written. If we can efficiently write it > out with another buffer > (essentially for free if they are on the same spot on disk) Are you sure this is true for buffer pages in most cases? - 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: [RFC] changes to buffer.c (was Test12 ll_rw_block error)
Marcelo Tosatti writes: > It seems your code has a problem with bh flush time. > > In flush_dirty_buffers(), a buffer may (if being called from kupdate) only > be written in case its old enough. (bh->b_flushtime) > > If the flush happens for an anonymous buffer, you'll end up writing all > buffers which are sitting on the same page (with block_write_anon_page), > but these other buffers are not necessarily old enough to be flushed. This isn't really a "problem" however. The page is the _maximum_ age of the buffer before it needs to be written. If we can efficiently write it out with another buffer (essentially for free if they are on the same spot on disk), then there is less work for us to do later. 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: No more DoS
Date:Fri, 22 Dec 2000 13:24:44 +1100 (CST) From: Mike OConnor <[EMAIL PROTECTED]> I would like to point who ever is in charge of the TCP stack for the linux kernel at a site which claims to have a method of eliminate denial of service (DoS) attacks http://grc.com/r/nomoredos.htm With my limited unstanding of TCP and DoS attacks this would seem to be the answer, instead of a work around. These people claim that no connection state needs to be saved for the beginning of the negotiation, and I claim this is unworkable because it ignores TCP timestamps entirely. Furthermore, it also cannot work because it makes retransmissions of the SYN/ACK very non-workable. I suppose his TCP stack just hacks around this by just waiting for the original client SYN to get retransmitted or something like this. I question whether that can even work reliably. I think not holding onto any state for an incoming SYN is nothing but a dream in any serious modern TCP implementation. It can be reduced, but not eliminated. The former is what most modern stacks have done to fight these problems. 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: [RFC] changes to buffer.c (was Test12 ll_rw_block error)
On Thu, 21 Dec 2000, Chris Mason wrote: > Ok guys, I think I've taken Linus' suggestion to have buffer.c use its > own writepage a bit too far. This patch marks pages dirty when the > buffer head is marked dirty, and changes flush_dirty_buffers and > sync_buffers to use writepage instead of ll_rw_block. The idea is > to allow filesystems to use the buffer lists and provide their own > i/o mechanism. > > The result is a serious semantics change for writepage, which now is > expected to do partial page writes when the page isn't up to date and > there are dirty buffers inside. For all the obvious reasons, this isn't > fit for 2.4.0, and if you all feel it is a 2.5. thing I'll send along > the shorter patch Linus originally suggested. But, I think it would > be pretty useful for the new filesystems (once I also fix > fsync_inode_buffers and sync_page_buffers). It is very powerful. With this on place, the filesystem is able to do write clustering at its writepage() function by checking if the on-disk physically nearby pages are dirty. > Other changes: submit_bh now cleans the buffers. I don't see how > they were getting cleaned before, it must have been try_to_free_buffers > sending the page through sync_page_buffers, meaning they were probably > getting written twice. Unless someone throws a clue my way, I'll send > this out as a separate diff. Ouch. > page_launder doesn't fiddle with the buffermem_pages counter, it is done > in try_to_free_buffers instead. > > Obvious bug, block_write_full_page zeros out the bits past the end of > file every time. This should not be needed for normal file writes. > > Most testing was on ext2, who actually calls mark_buffer_dirty, and > supports blocksizes < intel page size. More tests are running > overnight. It seems your code has a problem with bh flush time. In flush_dirty_buffers(), a buffer may (if being called from kupdate) only be written in case its old enough. (bh->b_flushtime) If the flush happens for an anonymous buffer, you'll end up writing all buffers which are sitting on the same page (with block_write_anon_page), but these other buffers are not necessarily old enough to be flushed. - 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/
No more DoS
Hi I would like to point who ever is in charge of the TCP stack for the linux kernel at a site which claims to have a method of eliminate denial of service (DoS) attacks http://grc.com/r/nomoredos.htm With my limited unstanding of TCP and DoS attacks this would seem to be the answer, instead of a work around. Cheers Mike OConnor - 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] Re: fs corruption with invalidate_buffers()
On Thu, 21 Dec 2000, Linus Torvalds wrote: > > > On Fri, 22 Dec 2000, Jan Niehusmann wrote: > > > > This is the result - against test12-pre7, but works well with > > test13-pre3: > > This looks bogus. It is bogus. My apologies. - 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: [RFC] changes to buffer.c (was Test12 ll_rw_block error)
On Thu, 21 Dec 2000, Chris Mason wrote: > Obvious bug, block_write_full_page zeros out the bits past the end of > file every time. This should not be needed for normal file writes. Unfortunately, it _is_ needed for pageout path. mmap() the last page of file. Dirty the data past the EOF (MMU will not catch that access). Let the pageout send the page to disk. You don't want to have the data past EOF end up on the backstore. Al, slowly getting back to life and sanity. Fsck the flu... - 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] Re: fs corruption with invalidate_buffers()
On Thu, Dec 21, 2000 at 05:01:00PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 22 Dec 2000, Jan Niehusmann wrote:
> >
> > The test I did initially was the following:
> >
> > if(!atomic_read(>b_count) &&
> > (destroy_dirty_buffers || !buffer_dirty(bh))
> > && ! (bh->b_page && bh->b_page->mapping)
> > )
> >
> > That is, I was explicitely checking for a mapped page. It worked well, too.
> > Is this more reasonable?
>
> I'd suggest just doing this instead (warning: cut-and-paste in xterm, so
> white-space damage):
> which just ignores mapped buffers entirely (and doesn't test for
> bh->b_page being non-NULL, because that shouldn't be allowed anyway).
Yes, looks good to me, and passes some tests. Here is a patch that has not
been cut and pasted:
--- linux/fs/buffer.c.orig Thu Dec 21 20:30:03 2000
+++ linux/fs/buffer.c Fri Dec 22 02:11:29 2000
@@ -643,7 +643,12 @@
continue;
for (i = nr_buffers_type[nlist]; i > 0 ; bh = bh_next, i--) {
bh_next = bh->b_next_free;
+
+ /* Another device? */
if (bh->b_dev != dev)
+ continue;
+ /* Part of a mapping? */
+ if (bh->b_page->mapping)
continue;
if (buffer_locked(bh)) {
atomic_inc(>b_count);
I have one additional question: invalidate_buffers normally gets called if
someone wants to make sure that, after the call, read accesses to a device
really go to the device and don't get served by a cache. Is there some
mechanismn that does the same thing to mapped pages?
Jan
-
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/
osst driver for 2.4.0
Hi Linus, I'd like to ask you to include the osst driver into the next 2.4 kernels. The osst driver is a new SCSI high-level driver, able to drive the OnStream SC-x0, DI-x0 and USBx0 tape driver, offering a st interface to the userspace. The reason for its existance is, that those OnStream devs are different from the SCSI-2 spec for SASDs (QIC157), but rather provide a QIC172 like interface. Unlike ide-tape, which includes a driver for the DI-30, after some discussion with Kai Makisara (st maintainer), we decided to not add lots of if (ST->onstream); to the code but to create a new driver, which was based on st, of course. Most work has been done by Willem Riede, BTW, who will also function as maintainer. See http://linux1.onstream.nl/ The thing has proven very stable during the beta test since April, so we believe it's time for integration into the mainstrean kernel. Alan just accepted the driver into 2.2.19pre1 and we'd like to have the driver in 2.4 as well. And no, there's no risk, otherwise I wouldn't dare to send it to you at this time. The only change to existing code is just preventing the st driver from attempting to drive those OnStream devices. The code for this is by Kai and has already been merged into the kernel ... So, please consider applying the patch against 2.4.0-test13-pre3, which I send to you in private mail. Regards, -- Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security PGP signature
Re: [RFC] Semaphores used for daemon wakeup
Paul Cassella wrote:
> The sync variable version of the dmabuf code snippet (assuming the
> dmabuf_mutex is never acquired from an interrupt) would look like this:
>
> dmabuf_init(...);
> {
> ...
> spin_lock_init(_spin);
> sv_init(_sv, _spin, SV_MON_SPIN);
> ...
> }
>
> dmabuf_alloc(...)
> {
>
> ...
> while (1) {
> spin_lock(_spin);
> attempt to grab a free buffer;
> if (success){
> spin_unlock(_spin);
> return;
> } else {
> sv_wait(_sv);
> }
> }
> }
>
> dmabuf_free(...)
> {
> ...
> spin_lock(_spin);
> free up buffer;
> sv_broadcast(_sv);
> spin_unlock(_spin);
> }
>
But isn't this actually a simple situation? How about:
dmabuf_alloc(...)
{
...
while (1) {
spin_lock(_lock);
attempt to grab a free buffer;
spin_unlock(_lock);
if (success)
return;
down(_wait);
}
}
dmabuf_free(...)
{
...
spin_lock(_lock);
free up buffer;
spin_unlock(_lock);
up(_wait);
}
--
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: 2.4.0 kernels and vpn
Not for a good solution IMHO, run don't walk to FreeS/WAN first, and save yourself a lot of grief On Thu, 21 Dec 2000, John Covici wrote: > Excuse my ignorance, but what is cipe? > > Also, I received a comment that all I had to do was enable gre > tunneling, is this correct? > > Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test13-pre4
More Makefile cleanups, otherwise mainly noticeable are the netfilter fix and the LVM update. Linus - - pre4: - Christoph Rohland: shmfs cleanup - Nicolas Pitre: don't forget loop.c flags - Geert Uytterhoeven: new-style m68k Makefiles - Neil Brown: knfsd cleanups, raid5 re-org - Andrea Arkangeli: update to LVM-0.9 - LC Chang: sis900 driver doc update - David Miller: netfilter oops fix - Andrew Grover: acpi update - pre3: - Christian Jullien: smc9194: proper dev_kfree_skb_irq - Cort Dougan: new-style PowerPC Makefiles - Andrew Morton, Petr Vandrovec: fix run_task_queue - Christoph Rohland: shmfs for shared memory handling - pre2: - Kai Germaschewski: ISDN update (including Makefiles) - Jens Axboe: cdrom updates - Petr Vandrovec; Matrox G450 support - Bill Nottingham: fix FAT32 filesystems on 64-bit platforms - David Miller: sparc (and other) Makefile fixup - Andrea Arkangeli: alpha SMP TLB context fix (and cleanups) - Niels Kristian Bech Jensen: checkconfig, USB warnings - Andrew Grover: large ACPI update - pre1: - me: drop support for old-style Makefiles entirely. Big. - me: check b_end_io at the IO submission path - me: fix "ptep_mkdirty()" (so that swapoff() works correctly) - fix fault case in copy_from_user() with a constant size, where ((size & 3) == 3) - 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] fix emu10k1 init breakage in 2.2.18
Juri Haberland wrote: >>> 2.2.18 broke the emu10k1 driver when compiled into the kernel. >> >> Is there also a fix available to make the bass and treble settings >> work again in mixer applications (for example, Gnome mix 1.2.0)? > > Yes, put something like "EXTRA_CFLAGS += -DTONE_CONTROL" into the > Makefile in drivers/sound/emu10k1/ Ah, TONE_CONTROL... yeah, that's it. Do you know the reason why bass/treble controls are disabled by default? Aren't they stable enough for production use? I'm just wondering why anybody wants to have this turned off. ;-) Greetings from Berlin to Berlin ... Andreas - 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: Purging the Page Table (was: Purging the Buffer Cache)
--- Juri Haberland <[EMAIL PROTECTED]> wrote: > Al Peat wrote: > > > > Is there any way to completely purge the buffer > > cache -- not just the write requests (ala 'sync' > or > > 'update'), but the whole thing? Can I just call > > invalidate_buffers() or destroy_buffers()? > > What about the ioctl BLKFLSBUF ? > If you are running a SuSE distrib there is already a > tool called flushb > that does what you want. If not, you can download > the simple tool from > http://innominate.org/~juri/flushb.tar.gz Another question: what if I need to purge the page table of all files as well? Is there a clean way to do that? I've been looking at /mm/memory.c, but it doesn't look like clear_page_tables, etc. get exported. I need /all/ read requests to go to disk, and it'd be nice if I could do that without a reboot (but I'll take the reboot if that's the only way to go about it :) Thanks again, Al __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.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: [RFC] Semaphores used for daemon wakeup
Paul Cassella wrote:
> > int atomic_read_and_clear(atomic_t *p)
> > {
> > int n = atomic_read(p);
> > atomic_sub(p, n);
> > return n;
> > }
>
> I don't think this will work; consider two callers doing the atomic_read()
> at the same time, or someone else doing an atomic_dec() after the
> atomic_read().
Oh yes, mea culpa, this is a terrible primitive, yet it works for this
application. 1) We don't have two callers 2) We only have atomic_inc
from the other processes, and it's ok for the atomic_inc to occur after
the atomic_read because that means the atomic_inc'er will then proceed
to up() the atomic_sub'ers semaphore, and it won't block.
I much preferred my original waiters = xchg(, 0), but as noted
it doesn't work with sparc. A satisfying approach would be to create
the new primitive up_down, which simplifies everything dramatically.
--
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/
[PATCH] Re: e820 memory detection fix for ThinkPad
David Weinhall wrote: > On Tue, Dec 19, 2000 at 07:16:40PM -0500, Marc Joosen wrote: > > > > This is a tiny patch to make the int15/e820 memory mapping work on IBM > > ThinkPads. Until now, I have had to give lilo a mem= option with one meg > > If this simple patch solves your problem, great! But in that case, > PLEASE add a note telling WHY the assignment is done for every > iteration; else some smarthead will probably submit a patch someday > in the future along the lines of "assigning this only once makes the > loop faster"... > > Anyhow, good spotting! Thanks for the tip, David. I hope that whoever wants to move that line out of the loop is aware that it is only executed ~10 times :) So I hereby submit a second version of the patch, that includes a link to the documentation and #defines the word SMAP (thanks to David Parsons for that): --- linux/arch/i386/boot/setup.S.origMon Oct 30 17:44:29 2000 +++ linux/arch/i386/boot/setup.S Thu Dec 21 19:37:12 2000 @@ -289,10 +289,11 @@ # a whole bunch of different types, and allows memory holes and # everything. We scan through this memory map and build a list # of the first 32 memory areas, which we return at [E820MAP]. -# +# This is documented at http://www.teleport.com/~acpi/acpihtml/topic245.htm + +#define SMAP 0x534d4150 meme820: -movl $0x534d4150, %edx# ascii `SMAP' xorl %ebx, %ebx # continuation counter movw $E820MAP, %di# point into the whitelist # so we can have the bios @@ -300,13 +301,15 @@ jmpe820: movl $0xe820, %eax# e820, upper word zeroed +movl $SMAP, %edx # do this every time, some + # bioses are forgetful movl $20, %ecx # size of the e820rec pushw %ds # data record. popw %es int $0x15# make the call jc bail820 # fall to e801 if it fails -cmpl $0x534d4150, %eax# check the return is `SMAP' +cmpl $SMAP, %eax # check the return is `SMAP' jne bail820 # fall to e801 if it fails # cmpl $1, 16(%di) # is this usable memory? Again, please copy any comments to me ([EMAIL PROTECTED]), since I'm not subscribed to linux-kernel. -- Marc Joosen Communication Link Design IBM T.J. Watson Research Center Yorktown Heights, NY - 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] Re: fs corruption with invalidate_buffers()
On Fri, 22 Dec 2000, Jan Niehusmann wrote:
>
> The test I did initially was the following:
>
> if(!atomic_read(>b_count) &&
> (destroy_dirty_buffers || !buffer_dirty(bh))
> && ! (bh->b_page && bh->b_page->mapping)
> )
>
> That is, I was explicitely checking for a mapped page. It worked well, too.
> Is this more reasonable?
I'd suggest just doing this instead (warning: cut-and-paste in xterm, so
white-space damage):
--- linux/fs/buffer.c.old Wed Dec 20 17:50:56 2000
+++ linux/fs/buffer.c Thu Dec 21 16:42:11 2000
@@ -639,8 +639,13 @@
continue;
for (i = nr_buffers_type[nlist]; i > 0 ; bh = bh_next, i--) {
bh_next = bh->b_next_free;
+
+ /* Another device? */
if (bh->b_dev != dev)
continue;
+ /* Part of a mapping? */
+ if (bh->b_page->mapping)
+ continue;
if (buffer_locked(bh)) {
atomic_inc(>b_count);
spin_unlock(_list_lock);
which just ignores mapped buffers entirely (and doesn't test for
bh->b_page being non-NULL, because that shouldn't be allowed anyway).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Linux 2.2.19pre3
2.2.19pre3 o Merge ADMtek-comet tulip support(Jim McQuillan) o Update microcode driver (Tigran Aivazian) o Merge Don Becker's NE2K full duplex support (Juan Lacarta) o Optimise kernel compiler detect, kgcc before(Peter Samuelson) gcc272 also o Fix compile combination problems(Arjan van de Ven) o Update via-rhine driver to include Don's changes(Urban Widmark) for VT6102 o Documentation updates (Tim Waugh) o Add ISDN PCI defines to pci.h (Kai Germaschewski) o Fix smb/fat handling for pre 1980 dates (Igor Zhbanov) o SyncLink updates(Paul Fulghum) o ICP vortex driver updates (Andreas Köpf) o mdacon clean up (Pavel Rabel) o Fix bugs in es1370/es1371/sonicvibes/solo1/ (Thomas Sailer) dabusb o Speed up x86 irq/fault paths by avoiding xchg (Mikael Pettersson) locked cycles (from Brian Gerst's 2.4test change) o Tighten up K6 check in bug tests(Mikael Pettersson) o Backport configure scripts bug fixes(Mikael Pettersson) o Fix duplicat help entries (Riley Williams) o Fix small asm bug in constant size uaccess (David Kutz) o Update ymfpci driver to handle legacy audio (Daisuke Nagano) o Remove ymfsb driver now no longer needed(Daisuke Nagano) o Add Empeg support to usb-serial (Gary Brubaker) o Fix e820 handling (Andrea Arcangeli) o Fix lanstreamer SMP locking (George Staikos) o Fix S/390 non SMP build (Kurt Roeckx) o Fix the PCI syscall on PowerMac (Benjamin Herrenschmidt) o Fix IPC_RMID behaviour (Christoph Rohland) o Fix NETCTL_GETFD on sparc64 (Dave Miller) o Tidy unneeded restore_flags/save sequence (Arnaldo Carvalho de Melo) on the ultrastor o Fix resource clean up on error in 89xo (Arnaldo Carvalho de Melo) driver o Update wireless headers (Jean Tourrilhes) o Fix non modular emu10k init (Mikael Pettersson) o Fix cpuid/msr driver crashes(Andrew Morton) o Write core files sparse (Christoph Rohland) o Merge the i810 tco (watchdog) timer (me) | original by Jeff Garzik 2.2.19pre2 o Drop the page aging for a moment to merge the Andrea VM o Merge Andrea's VM-global patch (Andrea Arcangeli) 2.2.19pre1 o Basic page aging(Neil Schemenauer) | This is a beginning to trying to get the VM right | Next stage is to go through Andrea's stuff and sort | it out the way I want it. o E820 memory detect backport from 2.4(Michael Chen) o Fix cs46xx refusing to run on emachines400 (me) o Fix parport docs(Tim Waugh) o Fix USB serial name reporting (me) o Fix else warning in initio scsi (John Fort) o Fix incorrect timeout (that couldnt occur fortunately) in sched.c (Andrew Archibald) o Fix A20 fix credits (Christian Lademann) o Support for OnStream SC-x0 tape drives (Willem Riede, Kurt Garloff) o Intel 815 added to the AGPGART code (Robert M Love) o 3Ware scsi fixes(Arnaldo Carvalho de Melo) o Clean up scsi_init_malloc no mem case (Arnaldo Carvalho de Melo) o Fix dead module parameter in ip_masq_user.c (Keith Owens) o Switch max_files and friends to a struct to (Tigran Aivazian) be sure they stay together o Update microcode driver (Tigran Aivazian) o Fix free memory dereference in lance driver (Eli Carter) o ISOfs fixes (Andries Brouwer) o Watchdog driver for Advantech boards(Marek Michalkiewicz) o ISDN updates(Karsten Keil) o Docs fix(Pavel Rabel) o wake_one semantics for accept() (Andrew Morton) o Masquerade updates (Juanjo Ciarlante) o Add support for long serialnums on the Metricom (Alex Belits) o Onboard ethernet driver for the Intel 'Panther' (Ard van Breemen, boards Andries Brouwer) o VIA686a timer reset to 18Hz
Re: 2.4.0 kernels and vpn
On Thu, Dec 21, 2000 at 07:25:18PM -0500, John Covici wrote: > Excuse my ignorance, but what is cipe? CIPE = Crypto IP Encapsulation. See http://sites.inka.de/~W1011/devel/cipe.html Some version of cipe is in the kerneli patches: ftp://ftp.YOURCOUNTRY.kernel.org/pub/linux/kernel/people/astor/ I'd recommend using FreeS/WAN, though as it's a standardized solution, even offering interoperability with other OSes. > Also, I received a comment that all I had to do was enable gre > tunneling, is this correct? This does not give you the P from VPN. Regards, -- Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security PGP signature
Re: [PATCH] Re: fs corruption with invalidate_buffers()
On Thu, Dec 21, 2000 at 04:37:30PM -0800, Linus Torvalds wrote: > This looks bogus. It may be - I just did what Al told me without really understanding it ;-) The test I did initially was the following: if(!atomic_read(>b_count) && (destroy_dirty_buffers || !buffer_dirty(bh)) && ! (bh->b_page && bh->b_page->mapping) ) That is, I was explicitely checking for a mapped page. It worked well, too. Is this more reasonable? Jan - 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 2.4.0test12pre3ac4
This is mostly so people can see what I have merged in my tree and what has gone from it. The patch for the adventurous is in ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4.0test/.. 2.4.0test13pre3-ac4 o Fix FPU emulation compile (Adam Richter) o M68K/PPC makefile fixes (Geert Uytterhoeven) o CCISS root= table (Charles White) o E820 handling fixup (Andrea Arcangeli) o Fix frame size on toshoboe (Christian Gennerat) o Quota fixes/updates (Jan Kara) o Fix keyspan usb config (Hugh Blemings) o Fix module handling in usb serial (Greg Kroah-Hartmann) o Work around a funny in the Solaris NFS client (Neil Brown) o Fix sparc64 build of fusion drivers (Eddie Dost) o Further NetROM tidies (Hans Grobler) o Further rose fixes (Hans Grobler) o Wireless include update (Jean Tourrilhes) o Fix eepro module warnings (Aristeu Filho) o Clean up config.h includes (Niels Jensen) o Fix most of the netfilter oops cases(David Miller) 2.4.0test13pre3-ac3 o Fix the patch file. Some stuff got corrupted. 2.4.0test13pre3-ac2 adds o Resync with the powerpc folks (Cort Dougan) o Fix appletalk config entry (William McGonigle) o Documentation/script fixes (Tim Waugh) o Parport experimental label fix (Tim Waugh) o Update credits to add Hans Grobler (Hans Grobler) o Make uhci return the same error code as the (David Brownell) other USB hub controllers o Merge Fusion drivers(Steve Ralston) o BPQ ethernet tidy (Hans Grobler) o Updated AX.25 tidy (Hans Grobler) o Shared memory fixes (Christoph Rohland) o Resync mac ethernet drivers (Cort Dougan) o Fix missing memory barrier in bootp/dhcp code (Cort Dougan) 2.4.0test13pre3-ac1 adds o Handle TLB flush reruns caused by APIC rexmit (me) o Fix leak in link() syscall (Christopher Yeoh) o Fix ramfs deadlock (Al Viro) o Fix udf deadlock(Al Viro) o Improve parport docs(Tim Waugh) o Document some of the macros (Tim Waugh) o Fix ppa timing issues (Tim Waugh) o Mark the parport fifo code as experimental (Tim Waugh) o Resynch ppa changelog (Tim Waugh) | Tim please double check as I got offsets o Fix Yam driver for Linux 2.4test(Hans Grobler) o Fix AF_ROSE sockets for 2.4 (Hans Grobler) o Fix AF_NETROM sockets for 2.4 (Hans Grobler) o Tidy AF_AX25 sockets for 2.4(Hans Grobler) o Teach kernel-doc about const(Jani Monoses) o Add documentation to the PCI api(Jani Monoses) o Fix inode.c documentation (Jani Monoses) o Push Davicom support into the main tulip driver (Tobias Ringstrom) o First block of mkiss driver fixes (Hans Grobler) o Fix bug in VFAT short name handling (Nicolas Goutte) o Clean up the i810 driver(Tjeerd Mulder) o RCPCI45 PCI cleanup fixes (mark 2) (Rasmus Andersen) o Improve the ALSxxx sound driver documentation (Jonathan Woithe) o Fix ext2 modular build (Jeff Raubitschek) o Fix bug in scripts/Configure.in matching(Matthew Wilcox) o Revert accidental amifb change (Geert Uytterhoeven) o Fix ext2 file size limiting for large files (Andreas Dilger) o Clean up misleading indenting in partition code (JAmes Antill) o Update SiS video drivers(Can-Ru Yeou) o Yamaha audio doc fix(Pavel Roskin) o Fix ACPI driver wakeup races(David Woodhouse) o Remove bogus asserts in 8139too driver (Jeff Garzik) o Fix timeout problms with rocktports at 249 days o Update acenic patches (Jes Sorensen) o Fix i810 tco locking(me) o Fix media makefiles (me) o Fix drm makefiles (Peter Samuelson) 2.4.0test12-ac1 adds o
Re: strange nfs behavior in 2.2.18 and 2.4.0-test12
On Thu, 21 Dec 2000, Andreas Dilger wrote: > John Covici writes: > > Here is my /etc/exports > > > > / ccs2(rw,no_root_squash) > > /usr ccs2(rw,no_root_squash) > > /usr/src ccs2(rw,no_root_squash) > > /home ccs2(rw,no_root_squash) > > /hard1 ccs2(rw,no_root_squash) > > /hard2 ccs2(rw,no_root_squash) > > /hard3 ccs2(rw,no_root_squash) > > /hard4 ccs2(rw,no_root_squash) > > /usr/bbs ccs2(rw,no_root_squash) > > According to your fstab, these are all separate devices, so they should > export OK. You trust this "ccs2" machine a lot, however... Exporting > root with no_root_squash is a big security hole. Yup, I do. > > > # /etc/fstab: static file system information. > > # > > # > > > /dev/hda2 / ext2defaults,errors=remount-ro 11 > > /dev/hdc2 noneswapsw 0 0 > > /dev/hdc4 noneswapsw 0 0 > > Having two swaps configured like this on the same disk is a net performance > loss. If anything, you should set one of them to have a lower priority > (via pri=), so that it will only be used if the first one is full. Thanks, I'll check it out. > > > /dev/hdb7 noneswapsw 0 0 > > proc/proc procdefaults0 0 > > /dev/fd0/floppy autodefaults,user,noauto0 0 > > /dev/cdrom /cdrom iso9660 defaults,ro,user,noauto 0 0 > > /dev/hdc3 /usrext2rw 1 2 > > /dev/hdb6 /usr/bbsext2rw 1 2 > > /dev/hda3 /usr/srcext2rw 1 2 > > /dev/hda4 /home ext2rw 1 3 > > > > and here are mounts executed out of /etc/rc.local > > > > mount -t vfat /dev/hdb1 /hard2 > > mount -t vfat /dev/hdb5 /hard4 > > mount -t vfat /dev/hdc1 /hard3 > > mount -t vfat /dev/hda1 /hard1 > > Out of curiosity, why not just put them into /etc/fstab? I tried this and I can't remember, but for somereason it didn't work. -- John Covici [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: [PATCH] Re: fs corruption with invalidate_buffers()
On Fri, 22 Dec 2000, Jan Niehusmann wrote: > > This is the result - against test12-pre7, but works well with > test13-pre3: This looks bogus. You can't test "bh->b_next!=0", because that is entirely meaningless. b_next can be NULL either because the buffer isn't hashed, or because the buffer _is_ hashed, but just happens to be last on the hash chain. So testing "bh->b_next" doesn't actually tell you anything at all. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
osst driver update 0.8.5->0.8.6.1
Hi Alan, thanks for merging the osst driver (a driver which support the OnStream SC-x0, DI-x0 and USB30 tape drives) into the 2.2.19pre1 kernel. I'd like to ask you to apply the attached patch on top of it, upgrading the driver version from 0.8.5 to 0.8.6.1. Changes: * README.osst does not talk about compilation with supplied Makefiles outside the kernel any more. * Handle another corner case when recovering read errors. * Try to graciously handle partial overwrites: - Warn when overwriting with an old Write Pass Counter - Update filemark counts etc. * Prevent filemark list corruption by preventing to fsf past EOD. * Error handling fixes for the polling mode (used on IDE). Patch is against 2.2.19pre2. Please apply! Regards, -- Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security diff -uNr linux-2.2.19-pre2/drivers/scsi/README.osst linux-2.2.19p2.osst/drivers/scsi/README.osst --- linux-2.2.19-pre2/drivers/scsi/README.osst Fri Dec 22 01:04:29 2000 +++ linux-2.2.19p2.osst/drivers/scsi/README.osstThu Dec 21 23:59:41 2000 @@ -1,6 +1,6 @@ README file for the osst driver === -(w) Kurt Garloff <[EMAIL PROTECTED]> 10/2000 +(w) Kurt Garloff <[EMAIL PROTECTED]> 11/2000 This file describes the osst driver as of version 0.8.x/0.9.x, the released version of the osst driver. @@ -34,8 +34,8 @@ are character devices with major no 206 and minor numbers like the /dev/stX devices. If those are not present, you may create them by calling Makedevs.sh as root (see below). -The driver started beig a copy of st and as such, the osst devices' -behaviour looks very much the same as st to the userspace applications. +The driver started being a copy of st and as such, the osst devices' +behavior looks very much the same as st to the userspace applications. History @@ -50,57 +50,9 @@ Installation -There is an easy and a correct approach to install the osst driver -(a) Without patching your kernel -(b) Full integration into your kernel -(c) The mainstream kernel does already include the osst driver - -While it is still possible to use possibility (a), i.e. to compile the osst -driver as a module without patching your kernel, this is not recommended, as -you then have only very limited possibility to take advantage of the possible -coexistence of st and osst. This possibility will be removed later. -Anyway here is a description of how installation works. - -Make sure you have a configured 2.2.1x Linux kernel in /usr/src/linux by -installing the approriate packages from your distro or by fetching the -source tarball from ftp.kernel.org or mirror and unpacking it in /usr/src/ -If your kernel is not yet configure, get a reasonable config file by doing -cd /usr/src/linux -make oldconfig # You may use make menuconfig if starting - # from scratch -make dep - -(a) Without patching your kernel - -cd /path/to/onstream/driver/ # REPLACE THIS WITH THE REAL PATH -make -make install - -That's all. You will get a couple of warnings on compilation, which you may -ignore. The osst.o module is now in your module directory ready for loading -and the device nodes have been created. - -(b) Full integration into the kernel. You need to have a reasonable kernel -config, otherwise you may be unable to use your system, as the produced -kernel may not support your hardware! IF YOU NEVER COMPILED YOUR OWN -KERNEL BEFORE, DON'T PROCEED, UNLESS YOU SUCEEDED USING YOUR SELF- -COMPILED KERNELS. - -cd /usr/src/linux -patch -p1 < /path/to/onstream/driver/osst-2X.diff # USE REAL PATH! X = 2,3,4 -cp -p /path/to/onstream/driver/osst.? drivers/scsi/# Install drv srcs -cp -p /path/to/onstream/driver/osst_options.h drivers/scsi/ - -(b) and (c) - -make oldconfig # or menuconfig / xconfig if you prefer - # enable the OSST driver! -make dep -make bzlilo# to recopmile your kernel and have it - # installed -make modules # to compile the kernel modules -make modules_install # to install your modules -depmod -a # append kernel version if necessary +osst got integrated into the linux kernel. Select it during kernel +configuration as module or compile statically into the kernel. +Compile your kernel and install the modules. Now, your osst driver is inside the kernel or available as a module, depending on your choice during kernel config. You may still need to create @@ -113,7 +65,7 @@ recognized. If you want to have the module autoloaded on access to /dev/osst, you may -add somethind like +add something like alias char-major-206 osst to your /etc/modules.conf (old name: conf.modules). @@ -122,6 +74,9 @@ to make
max number of ide controllers?
I have been running with the 2 onboard VIA ide hd controllers (ide 0 and ide 1) along with a creative labs ide contoller on a SB32 soundcard (ide 3). This has had the cdrom and zip drive. I just added a Promise Ultra100 and it has assumed the role of ide 3 and ide 4. The onboard controllers are still ide 0 and ide 1, but the creative labs controller isnt coming up. Is there a max number of ide controllers that linux-2.2.18 can support?
Re: 2.4.0 kernels and vpn
On Thu, Dec 21, 2000 at 01:40:16PM -0500, John Covici wrote: > Hi. Is there a way to support vpn in the 2.4.0 kernels like we had > with the patch for the 2.2.x kernels? > > Any assistance would be appreciated. FreeS/WAN: A Linux IPsec implementation: http://www.xs4all.nl/~freeswan/ Or look at CIPE (kerneli patches). Regards, -- Kurt Garloff <[EMAIL PROTECTED]> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security PGP signature
vm 2.2.18 (stock kernel) process hara-kiri's
I thought the 2.2.18 vm would be better :-)... nver have seen so much VM: do_try_to_free_pages failed for... messages. at first the system froze for several seconds. an emer sync worked just fine so I waited.. Dec 22 00:06:10 grobbebol kernel: VM: do_try_to_free_pages failed for telnet... Dec 22 00:06:10 grobbebol kernel: VM: do_try_to_free_pages failed for telnet... Dec 22 00:06:10 grobbebol kernel: VM: do_try_to_free_pages failed for telnet... Dec 22 00:06:10 grobbebol kernel: VM: do_try_to_free_pages failed for telnet... Dec 22 00:06:10 grobbebol kernel: VM: do_try_to_free_pages failed for mutt... Dec 22 00:06:12 grobbebol last message repeated 11 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for cron... Dec 22 00:06:12 grobbebol last message repeated 4 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for xntpd... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for miniserv.pl... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for miniserv.pl... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for rpc.nfsd... Dec 22 00:06:12 grobbebol last message repeated 13 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for nscd... Dec 22 00:06:12 grobbebol last message repeated 8 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for xntpd... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for xntpd... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for klogd... Dec 22 00:06:12 grobbebol last message repeated 5 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for klogd... Dec 22 00:06:12 grobbebol kernel: Syncing device 03:02 ... VM: do_try_to_free_pages failed for kflushd... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for kupdate... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for _upsd... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for rpc.mountd... Dec 22 00:06:12 grobbebol last message repeated 5 times Dec 22 00:06:12 grobbebol kernel: SysRq: Emergency Sync Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for rpc.mountd... Dec 22 00:06:12 grobbebol last message repeated 6 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for xntpd... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for kdeinit... Dec 22 00:06:12 grobbebol last message repeated 15 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for xntpd... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for syslogd... Dec 22 00:06:12 grobbebol last message repeated 6 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for xntpd... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for tin... Dec 22 00:06:12 grobbebol last message repeated 12 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for xntpd... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for kdeinit... Dec 22 00:06:12 grobbebol last message repeated 32 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for xntpd... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for sendmail... Dec 22 00:06:12 grobbebol last message repeated 13 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for kdeinit... Dec 22 00:06:12 grobbebol last message repeated 15 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for kdesud... Dec 22 00:06:12 grobbebol last message repeated 12 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for xntpd... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for xntpd... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for kdeinit... Dec 22 00:06:12 grobbebol last message repeated 32 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for inetd... Dec 22 00:06:12 grobbebol last message repeated 15 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for kdeinit... Dec 22 00:06:12 grobbebol last message repeated 15 times Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for xntpd... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for kdeinit... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for xntpd... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for kdeinit... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for xntpd... Dec 22 00:06:12 grobbebol kernel: VM: do_try_to_free_pages failed for kflushd... Dec 22 00:06:12 grobbebol kernel: OK Dec 22 00:06:12 grobbebol kernel: Syncing device 03:01 ... OK Dec 22 00:06:12 grobbebol kernel: Syncing device 03:03 ... OK Dec 22 00:06:12 grobbebol kernel: Syncing device 03:04 ... OK Dec 22 00:06:12 grobbebol kernel: Syncing device 08:01 ... OK Dec
Re: strange nfs behavior in 2.2.18 and 2.4.0-test12
John Covici writes: > Here is my /etc/exports > > / ccs2(rw,no_root_squash) > /usr ccs2(rw,no_root_squash) > /usr/src ccs2(rw,no_root_squash) > /home ccs2(rw,no_root_squash) > /hard1 ccs2(rw,no_root_squash) > /hard2 ccs2(rw,no_root_squash) > /hard3 ccs2(rw,no_root_squash) > /hard4 ccs2(rw,no_root_squash) > /usr/bbs ccs2(rw,no_root_squash) According to your fstab, these are all separate devices, so they should export OK. You trust this "ccs2" machine a lot, however... Exporting root with no_root_squash is a big security hole. > # /etc/fstab: static file system information. > # > # > > /dev/hda2 / ext2defaults,errors=remount-ro 11 > /dev/hdc2 noneswapsw 0 0 > /dev/hdc4 noneswapsw 0 0 Having two swaps configured like this on the same disk is a net performance loss. If anything, you should set one of them to have a lower priority (via pri=), so that it will only be used if the first one is full. > /dev/hdb7 noneswapsw 0 0 > proc /proc procdefaults0 0 > /dev/fd0 /floppy autodefaults,user,noauto0 0 > /dev/cdrom/cdrom iso9660 defaults,ro,user,noauto 0 0 > /dev/hdc3 /usrext2rw 1 2 > /dev/hdb6 /usr/bbsext2rw 1 2 > /dev/hda3 /usr/srcext2rw 1 2 > /dev/hda4 /home ext2rw 1 3 > > and here are mounts executed out of /etc/rc.local > > mount -t vfat /dev/hdb1 /hard2 > mount -t vfat /dev/hdb5 /hard4 > mount -t vfat /dev/hdc1 /hard3 > mount -t vfat /dev/hda1 /hard1 Out of curiosity, why not just put them into /etc/fstab? 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/
[PATCH] Re: fs corruption with invalidate_buffers()
The file corruption I reported on Dec 6 is still there in test13-pre3.
(I can only reproduce it easily with the ext2 online resizing patches,
but I really don't think it is caused by them)
The corruption happens if invalidate_buffers calls put_last_free() on
buffers that belong to mapped pages. These pages remain valid and may
get used later, while the buffers are marked free and may be reused
by something completely different, immediately causing corruption.
I changed my patch for the problem according to the following advice by
Al Viro:
On Thu, Dec 07, 2000 at 05:26:46PM -0500, Alexander Viro wrote:
> That invalidate_buffers() should leave the unhashed ones alone. If it can't
> be found via getblk() - just leave it as is.
>
> IOW, let it skip bh if (bh->b_next == NULL && !destroy_dirty_buffers).
> No warnings needed - it's a normal situation.
This is the result - against test12-pre7, but works well with
test13-pre3:
--- linux-2.4.0-test12-pre7-jn/fs/buffer.c.orig Fri Dec 8 14:59:28 2000
+++ linux-2.4.0-test12-pre7-jn/fs/buffer.c Fri Dec 8 15:05:11 2000
@@ -502,6 +502,10 @@
struct bh_free_head *head = _list[BUFSIZE_INDEX(bh->b_size)];
struct buffer_head **bhp = >list;
+ if(bh->b_page && bh->b_page->mapping) {
+ panic("put_last_free() on mapped buffer!");
+ }
+
bh->b_state = 0;
spin_lock(>lock);
@@ -652,7 +656,8 @@
write_lock(_table_lock);
if (!atomic_read(>b_count) &&
- (destroy_dirty_buffers || !buffer_dirty(bh))) {
+ (destroy_dirty_buffers ||
+ (!buffer_dirty(bh) && bh->b_next!=0) )) {
remove_inode_queue(bh);
__remove_from_queues(bh);
put_last_free(bh);
-
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: strange nfs behavior in 2.2.18 and 2.4.0-test12
Here is my /etc/exports / ccs2(rw,no_root_squash) /usr ccs2(rw,no_root_squash) /usr/src ccs2(rw,no_root_squash) /home ccs2(rw,no_root_squash) /hard1 ccs2(rw,no_root_squash) /hard2 ccs2(rw,no_root_squash) /hard3 ccs2(rw,no_root_squash) /hard4 ccs2(rw,no_root_squash) /usr/bbs ccs2(rw,no_root_squash) # Here is the fstab file. # /etc/fstab: static file system information. # # /dev/hda2 / ext2defaults,errors=remount-ro 1 1 /dev/hdc2 noneswapsw 0 0 /dev/hdc4 noneswapsw 0 0 /dev/hdb7 noneswapsw 0 0 proc/proc procdefaults0 0 /dev/fd0/floppy autodefaults,user,noauto0 0 /dev/cdrom /cdrom iso9660 defaults,ro,user,noauto 0 0 /dev/hdc3 /usr ext2 rw 1 2 /dev/hdb6 /usr/bbs ext2 rw 1 2 /dev/hda3 /usr/src ext2 rw 1 2 /dev/hda4 /home ext2 rw 1 3 and here are mounts executed out of /etc/rc.local mount -t vfat /dev/hdb1 /hard2 mount -t vfat /dev/hdb5 /hard4 mount -t vfat /dev/hdc1 /hard3 mount -t vfat /dev/hda1 /hard1 On Fri, 22 Dec 2000, Neil Brown wrote: > On Thursday December 21, [EMAIL PROTECTED] wrote: > > On Fri, 22 Dec 2000, Neil Brown wrote: > > > > > On Thursday December 21, [EMAIL PROTECTED] wrote: > > > > Hi. I am having strange nfs problems in both my 2.x and 2.4.0-test12 > > > > kernels. > > > > > > > > What is happening is that when the machine boots up and exports the > > > > directories for nfs, it complains that > > > > > > > > ccs2:/ invalid argument . > > > > > > > > The exports entry is > > > > > > > > / ccs2(rw,no_root_squash) > > > > > > Is there another export entry that exports another part of the same > > > file system to the same client? If so, that is your problem. > > > > Well I do want to export the mount points under the file system, for > > instance I have a partition mounted as /usr and so I have an entry > > such as > > /usr ccs2(rw,no_root_squash) > > > > in my exports list. Is there any other way to get this behaviour to > > work? > > Sounds like what you are doing is OK. > If you could send complete /etc/fstab and /etc/exports, that might > help to isolate the problem. > > NeilBrown > -- John Covici [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/
[RFC] changes to buffer.c (was Test12 ll_rw_block error)
Ok guys, I think I've taken Linus' suggestion to have buffer.c use its
own writepage a bit too far. This patch marks pages dirty when the
buffer head is marked dirty, and changes flush_dirty_buffers and
sync_buffers to use writepage instead of ll_rw_block. The idea is
to allow filesystems to use the buffer lists and provide their own
i/o mechanism.
The result is a serious semantics change for writepage, which now is
expected to do partial page writes when the page isn't up to date and
there are dirty buffers inside. For all the obvious reasons, this isn't
fit for 2.4.0, and if you all feel it is a 2.5. thing I'll send along
the shorter patch Linus originally suggested. But, I think it would
be pretty useful for the new filesystems (once I also fix
fsync_inode_buffers and sync_page_buffers).
Other changes: submit_bh now cleans the buffers. I don't see how
they were getting cleaned before, it must have been try_to_free_buffers
sending the page through sync_page_buffers, meaning they were probably
getting written twice. Unless someone throws a clue my way, I'll send
this out as a separate diff.
page_launder doesn't fiddle with the buffermem_pages counter, it is done
in try_to_free_buffers instead.
Obvious bug, block_write_full_page zeros out the bits past the end of
file every time. This should not be needed for normal file writes.
Most testing was on ext2, who actually calls mark_buffer_dirty, and
supports blocksizes < intel page size. More tests are running
overnight.
-chris
diff -urN linux.test13p3p/drivers/block/ll_rw_blk.c
linux-test12/drivers/block/ll_rw_blk.c
--- linux.test13p3p/drivers/block/ll_rw_blk.c Tue Dec 19 05:07:50 2000
+++ linux.test13p3/drivers/block/ll_rw_blk.cThu Dec 21 16:56:43 2000
@@ -954,6 +954,7 @@
if (!test_bit(BH_Lock, >b_state))
BUG();
+ mark_buffer_clean(bh) ;
set_bit(BH_Req, >b_state);
/*
diff -urN linux.test13p3p/fs/buffer.c linux-test12/fs/buffer.c
--- linux.test13p3p/fs/buffer.c Thu Dec 21 17:24:17 2000
+++ linux.test13p3/fs/buffer.c Thu Dec 21 17:28:46 2000
@@ -97,6 +97,16 @@
static int grow_buffers(int size);
static void __refile_buffer(struct buffer_head *);
+static int block_write_anon_page(struct page *);
+
+static struct address_space_operations anon_space_ops = {
+ writepage: block_write_anon_page,
+ sync_page: block_sync_page,
+} ;
+static struct address_space anon_space_mapping = {
+ pages: { _space_mapping.pages, _space_mapping.pages },
+ a_ops: _space_ops,
+} ;
/* This is used by some architectures to estimate available memory. */
atomic_t buffermem_pages = ATOMIC_INIT(0);
@@ -161,6 +171,37 @@
atomic_dec(>b_count);
}
+/*
+** util function for sync_buffers and flush_dirty_buffers
+** uses either the writepage func supplied in the page's mapping,
+** or the anon address space writepage
+*/
+static int dirty_list_writepage(struct page *page) {
+ int (*writepage)(struct page *) ;
+ int ret ;
+
+ writepage = page->mapping->a_ops->writepage ;
+
+ if (!writepage) {
+ writepage = anon_space_ops.writepage ;
+ }
+
+ page_cache_get(page) ;
+ ClearPageDirty(page) ;
+ ret = writepage(page) ;
+ /* note, when writepage returns 1, we mark the page dirty again
+ ** but the writepage func is responsible for making sure any
+ ** buffers that need to stay dirty really do stay dirty
+ ** ick.
+ */
+ if (ret == 1) {
+ SetPageDirty(page) ;
+ UnlockPage(page) ;
+ }
+ page_cache_release(page) ;
+ return ret ;
+}
+
/* Call sync_buffers with wait!=0 to ensure that the call does not
* return until all buffer writes have completed. Sync() may return
* before the writes have finished; fsync() may not.
@@ -175,6 +216,7 @@
{
int i, retry, pass = 0, err = 0;
struct buffer_head * bh, *next;
+ struct page *page ;
/* One pass for no-wait, three for wait:
* 0) write out all dirty, unlocked buffers;
@@ -230,10 +272,19 @@
if (!buffer_dirty(bh) || pass >= 2)
continue;
- atomic_inc(>b_count);
+ page = bh->b_page ;
+ if (TryLockPage(page)) {
+ if (!wait || !pass) {
+ retry = 1 ;
+ continue ;
+ }
+ spin_unlock(_list_lock);
+ wait_on_page(page) ;
+ goto repeat ;
+ }
spin_unlock(_list_lock);
- ll_rw_block(WRITE, 1, );
- atomic_dec(>b_count);
+
+ dirty_list_writepage(page) ;
retry = 1;
Re: strange nfs behavior in 2.2.18 and 2.4.0-test12
On Thursday December 21, [EMAIL PROTECTED] wrote: > On Fri, 22 Dec 2000, Neil Brown wrote: > > > On Thursday December 21, [EMAIL PROTECTED] wrote: > > > Hi. I am having strange nfs problems in both my 2.x and 2.4.0-test12 > > > kernels. > > > > > > What is happening is that when the machine boots up and exports the > > > directories for nfs, it complains that > > > > > > ccs2:/ invalid argument . > > > > > > The exports entry is > > > > > > / ccs2(rw,no_root_squash) > > > > Is there another export entry that exports another part of the same > > file system to the same client? If so, that is your problem. > > Well I do want to export the mount points under the file system, for > instance I have a partition mounted as /usr and so I have an entry > such as > /usr ccs2(rw,no_root_squash) > > in my exports list. Is there any other way to get this behaviour to > work? Sounds like what you are doing is OK. If you could send complete /etc/fstab and /etc/exports, that might help to isolate the problem. NeilBrown - 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: strange nfs behavior in 2.2.18 and 2.4.0-test12
On Fri, 22 Dec 2000, Neil Brown wrote: > On Thursday December 21, [EMAIL PROTECTED] wrote: > > Hi. I am having strange nfs problems in both my 2.x and 2.4.0-test12 > > kernels. > > > > What is happening is that when the machine boots up and exports the > > directories for nfs, it complains that > > > > ccs2:/ invalid argument . > > > > The exports entry is > > > > / ccs2(rw,no_root_squash) > > Is there another export entry that exports another part of the same > file system to the same client? If so, that is your problem. Well I do want to export the mount points under the file system, for instance I have a partition mounted as /usr and so I have an entry such as /usr ccs2(rw,no_root_squash) in my exports list. Is there any other way to get this behaviour to work? > You cannot export two different directories on the same filesystem to > the same client if one is an ancestor of the other (because exporting > a directory is really exporting the directory and all descendants on > that filesystem, and so exporting a directory and a subdirectory is > effectively exporting the subdirectory twice with potentially > different flags). > > NeilBrown > > > > > Now in Kernel 2.2.18, if I stop and restart the nfs daemons, all is > > OK, the invalid argument goes away, but in 2.4.0 I cannot get this to > > work at all and so I cannot mount nfs from a client on the ccs2 box. > > I am using the utilities 0.2.1-4 from the Debian distribution if that > > makes any difference. I did an strace once on exportfs and it was > > having trouble with the call to nfsservctl which returns invalid argument. > > > > > > Any assistance would be appreciated. > > > > -- > > John Covici > > [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/ > -- John Covici [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: Cleanup (PCI API and general) of drivers/net/rcpci.c (240t13p3)
On Thu, Dec 21, 2000 at 10:46:52PM +, Alan Cox wrote: > > o The driver currently allocates irqs during its initialization > > instead of postponing it until it is opened for use. Is there > > a reason for this? > > Shouldnt be - its an I2O network interface with some extra bits for > the cryptoconfig OK. I'll move the resource de-/allocation to the open/close call then and post a new patch in a few days. -- Rasmus([EMAIL PROTECTED]) Gates' Law: Every 18 months, the speed of software halves -- Anonymous - 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: Wiring down Pages
On Thu, Dec 21, 2000 at 06:46:33PM -0200, Rik van Riel wrote: > > page_cache_drop(page); <= removes your extra count I can't find that function, do you mean page_cache_free() and page_cache_release(), both are aliases for __free_page(). Maybe we need another alias. :) Should non-page cache related code use get_page() and __free_page() directly? Or should the page_cache_* macros be used everywhere? robert - 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: Cleanup (PCI API and general) of drivers/net/rcpci.c (240t13p3)
> Questions for the maintainers, should they read this (does anyone > know their email addresses?) (others should feel free to chip in): I've not heard from them for a long time > o The driver currently allocates irqs during its initialization > instead of postponing it until it is opened for use. Is there > a reason for this? Shouldnt be - its an I2O network interface with some extra bits for the cryptoconfig - 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/
Cleanup (PCI API and general) of drivers/net/rcpci.c (240t13p3)
Hi. This is the final version of my rcpci45.c patch. It is somewhat more ambitious than the last one (which only cleaned up the PCI API), so I would appreciate feedback since I don't know half of what I am doing (questions galore below). It features: o Conversion to new PCI API. o Removal of a bunch of #ifdef DEBUG around printk statements in favor of a dprintk define (dependent on DEBUG). o All printk now have a proper KERN_* message prefix. o Consolidation of device information into struct net_device where possible. This gave rise to some data structure (see below) and function parameter cleanup. o Removal of 32 adapters limit (see also questions). o Conversion of for-loops used for delays into udelay() calls (see also questions). o Conversion of return cases with resource deallocation to do to 'goto err_out' constructs. o General cleanup. Because of its larger scope the patch's size have also increased to the point where it is not suited for posting to lkml. It can be down- loaded from www.jaquet.dk/kernel/patches/rcpci.patch.gz (~22 Kb). (Most of the diff is trivial stuff.) I would also like to note that if my patch is accepted the patch size increase of running an 'indent -kr -i8' on the files is minimal (and would be nice). It is currently indented with four spaces (except the places where I slipped and used the standard eight). It would be really nice if somebody could test this patch on appro- priate hardware since I do not own one of these cards. Data structure reorganization: The current driver uses two static index arrays to point to a device's Driver Private Area and PCI Adapter Block, respectively. These blocks (structs) were located in one large kmalloced memory block allocated during init and accessed by offsets. The remaining part of this block was used for message buffers for the device. My patch makes these three areas be seperate kmalloced areas and uses the net_device->priv pointer to keep track of the relevant data structures for the given device. Thus the two static arrays can be done away with since the net_device->priv pointer is at hand all places where we need it. From this a number of simple cleanups then present themselves. (I have tried to keep the above desciption short since it might not be of interest to many. Detail level and (perhaps) readability has suffered as a result. Please comment if you would like more details.) Questions for the maintainers, should they read this (does anyone know their email addresses?) (others should feel free to chip in): o The driver currently allocates irqs during its initialization instead of postponing it until it is opened for use. Is there a reason for this? o You write that the private message buffer (referenced by pDpa->PLanApiPA) should be at least 16Kb but you never seem to check for the actual size of the allocated memory anywhere. Am I missing something or are you operating on assumptions here? General questions about PCI and mmio stuff: o The current driver uses two static arrays to keep track of device instances. I have eliminated these arrays in my patch. Is there some limitation in the pci interface that requires me to check for/limit the number of adapters (besides sanity checks)? o I use kmalloc without being totally familiar with the GFP_* flags. Could somybody please shortly descibe their use so I can check I haven't messed up? In particular, there is a requirement for a message buffer that 'must be in locked pages' and 'long word aligned'. The current drivers uses GFP_DMA | GFP_KERNEL|GFP_ATOMIC for this buffer (and some extra stuff for the alignment requirements. More about this below). Do we need all these? I have limited myself to GFP_DMA|GFP_KERNEL but really have no clue... o The current code uses a '+0xff) & ~0xff)'-thingie to align the message buffer for 'long word alignment'. Is there another (nicer) way to do this? Or is this the recommended way? o I have replaced a lot of 'for(i=0;i<1000;i++) ;' loops used to delay repeated PCI bus access with udelay(10), a value I randomly picked. Could anyone comment on this value? o The current driver ioremaps 64K of PCI address space. This seems to be (judging from the way it is written in the code) set to twice the memory reserved for the private message buffer. Is this the correct way to do this or is there a better way to determine the size of ioremaps? (I guess I show my ignorance here...) My patch uses pci_resources_len but this seems ... too easy? General questions: o If p32 is defined as a 'volatile PU32' is it necessary to use the cast (volatile PU32) when assigning to it? Isn't '(PU32)' enough? -- Regards, Rasmus([EMAIL PROTECTED]) I've always found profanity to be refuge of the inarticulate motherfucker. --Anonymous - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read
Re: [RFC] Semaphores used for daemon wakeup
Looks good. I'd like to play with you patch, but certainly from a first glance, it would seem to be sufficiently powerful, and significantly cleaner/clearer (at least to me :-) than the current mechanism involving the wait queue games. Regards, Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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: strange nfs behavior in 2.2.18 and 2.4.0-test12
On Thursday December 21, [EMAIL PROTECTED] wrote: > Hi. I am having strange nfs problems in both my 2.x and 2.4.0-test12 > kernels. > > What is happening is that when the machine boots up and exports the > directories for nfs, it complains that > > ccs2:/ invalid argument . > > The exports entry is > > / ccs2(rw,no_root_squash) Is there another export entry that exports another part of the same file system to the same client? If so, that is your problem. You cannot export two different directories on the same filesystem to the same client if one is an ancestor of the other (because exporting a directory is really exporting the directory and all descendants on that filesystem, and so exporting a directory and a subdirectory is effectively exporting the subdirectory twice with potentially different flags). NeilBrown > > Now in Kernel 2.2.18, if I stop and restart the nfs daemons, all is > OK, the invalid argument goes away, but in 2.4.0 I cannot get this to > work at all and so I cannot mount nfs from a client on the ccs2 box. > I am using the utilities 0.2.1-4 from the Debian distribution if that > makes any difference. I did an strace once on exportfs and it was > having trouble with the call to nfsservctl which returns invalid argument. > > > Any assistance would be appreciated. > > -- > John Covici > [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: Laptop system clock slow after suspend to disk. (2.4.0-test9/hinote VP)
On Thu, 21 Dec 2000 02:26:12 + (GMT), Ian Stirling <[EMAIL PROTECTED]> wrote: >I've not noticed this on earlier kernel versions, is there something >silly I'm missing that's making my DEC hinote VP (p100 laptop)s >system clock slow by a factor of five or so after resume? >Not the CPU or cmos clock, only the system clock. Try this. Index: 0-test13-pre3.2/arch/i386/kernel/apm.c --- 0-test13-pre3.2/arch/i386/kernel/apm.c Mon, 11 Dec 2000 09:23:40 +1100 kaos (linux-2.4/z/c/34_apm.c 1.1.1.7.2.5 644) +++ 0-test13-pre3.2(w)/arch/i386/kernel/apm.c Fri, 22 Dec 2000 09:04:28 +1100 kaos +(linux-2.4/z/c/34_apm.c 1.1.1.7.2.5 644) @@ -262,6 +262,7 @@ extern int (*console_blank_hook)(int); * David Chen <[EMAIL PROTECTED]> */ #undef INIT_TIMER_AFTER_SUSPEND +#define INIT_TIMER_AFTER_SUSPEND #ifdef INIT_TIMER_AFTER_SUSPEND #include - 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: bigphysarea support in 2.2.19 and 2.4.0 kernels
Alan, I am looking over the 2.4 bigphysarea patch, and I think I agree there needs to be a better approach. It's a messy hack -- I agree. :-) Jeff > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - 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] generic_file_map drop-behind fix
Hi Ingo,
the attached patch (against 2.4.0-test12-pre3) should fix the
problem where generic_file_write() causes a page to be moved
to the inactive list when the program is still writing to it.
Does this patch fix the web benching bottleneck in tux2 ? ;)
regards,
Rik
--
Hollywood goes for world dumbination,
Trailer at 11.
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com.br/
--- linux-2.4.0-test12-pre3/mm/filemap.c.orig 2000/12/21 18:20:17
+++ linux/mm/filemap.c 2000/12/21 21:31:39
@@ -2436,7 +2436,7 @@
}
while (count) {
- unsigned long bytes, index, offset;
+ unsigned long bytes, index, offset, partial = 0;
char *kaddr;
/*
@@ -2446,8 +2446,10 @@
offset = (pos & (PAGE_CACHE_SIZE -1)); /* Within page */
index = pos >> PAGE_CACHE_SHIFT;
bytes = PAGE_CACHE_SIZE - offset;
- if (bytes > count)
+ if (bytes > count) {
bytes = count;
+ partial = 1;
+ }
status = -ENOMEM; /* we'll assign it later anyway */
page = __grab_cache_page(mapping, index, _page);
@@ -2478,9 +2480,17 @@
buf += status;
}
unlock:
- /* Mark it unlocked again and drop the page.. */
+ /*
+* Mark it unlocked again and release the page.
+* In order to prevent large (fast) file writes
+* from causing too much memory pressure we move
+* completely written pages to the inactive list.
+* We do, however, try to keep the pages that may
+* still be written to (ie. partially written pages).
+*/
UnlockPage(page);
- deactivate_page(page);
+ if (!partial)
+ deactivate_page(page);
page_cache_release(page);
if (status < 0)
-
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: bigphysarea support in 2.2.19 and 2.4.0 kernels
On Thu, Dec 21, 2000 at 09:32:46PM +, Alan Cox wrote: > > A question related to bigphysarea support in the native Linux > > 2.2.19 and 2.4.0 kernels. > > > > I know there are patches for this support, but is it planned for > > rolling into the kernel by default to support Dolphin SCI and > > some of the NUMA Clustering adapters. I see it there for some > > of the video adapters. > > bigphysarea is the wrong model for 2.4. The bootmem allocator means that > drivers could do early claims via the bootmem interface during boot up. That > would avoid all the cruft. > > For 2.2 bigphysarea is a hack, but a neccessary add on patch and not one you > can redo cleanly as we don't have bootmem > > I belive Pauline Middelink had a patch implementing bigphysarea in terms of > bootmem > > Alan Alan, Thanks for the prompt response. I am merging the Dolphin SCI High Speed interconnect drivers into 2.2.18 and 2.4.0 for our M2FS project, and I am reviewing the big ugly nasty patch they have current as of 2.2.13 (really old). I will be looking over the 2.4 tree for a more clean manner to do what they want. What's in the patch alters the /proc filesystem, and the VM code. I will submit a patch against 2.2.19 and 2.4.0 for this support for their SCI adapters after I get a handle on it. :-) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: lockups from heavy IDE/CD-ROM usage
> I get this on the 440LX with the same DMA timeout message. Everyone says it's > the board's fault as well. Funny. Anyways this happens accross just about > any Dev kernel but more so in the -test12 and up versions. . Test10 works > fine without locking. Blaming the hardware reminds me of the help given by > some other company I can't seem to remember the name to. Well, think about it - if there are DMA/IRQ timeouts, the hardware IS rooted. Otherwise, why would it be timing out? I've been seeing these messages shortly before a hardlock (except for the fact numlock still works, but nothing else) when doing long, intensive hard drive activity. Because my hard drives are right next to each other, overheat sometimes and shut straight down when they do. But I'm gonna take a wild guess it's not Linux's fault, unless they've done some whacky stuff with the elevator ;) -- Daniel Stone Linux Kernel Developer [EMAIL PROTECTED] -BEGIN GEEK CODE BLOCK- Version: 3.1 G!>CS d s++:- a C++ ULS$>B P L+++> E+(joe)>+++ W++ N->++ !o K? w++(--) O M- V-- PS+++ PE- Y PGP>++ t--- 5-- X- R- tv-(!) b+++ DI+++ D+ G e->++ h!(+) r+(%) y? UF++ --END GEEK CODE BLOCK-- - 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: bigphysarea support in 2.2.19 and 2.4.0 kernels
> A question related to bigphysarea support in the native Linux > 2.2.19 and 2.4.0 kernels. > > I know there are patches for this support, but is it planned for > rolling into the kernel by default to support Dolphin SCI and > some of the NUMA Clustering adapters. I see it there for some > of the video adapters. bigphysarea is the wrong model for 2.4. The bootmem allocator means that drivers could do early claims via the bootmem interface during boot up. That would avoid all the cruft. For 2.2 bigphysarea is a hack, but a neccessary add on patch and not one you can redo cleanly as we don't have bootmem I belive Pauline Middelink had a patch implementing bigphysarea in terms of bootmem Alan - 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: IDE woes:linux and BIOS won't agree on C/H/S detection
On Fri, Dec 22, 2000 at 03:25:20AM +0900, Ishikawa wrote: [a long and very well documented story] > How can I "erase" this 2940/255/63 CHS setting from the disk It is far from clear that it is on your disk, so it is far from clear that something can be erased. First a few warnings - probably you know already, but just to be sure: (i) The geometry you get is mostly determined by the BIOS settings (Normal / Large / LBA / PartitionTable). (ii) The 2.2.14+ and 2.4 behaviours are both correct, but differ. The difference consists in that 2.2.14 will use a 255 head geometry by default (on a large disk), while 2.4 will not. 2.2.12 is broken for large disks. (iii) The geometry seen on a partition table may override the geometry detected earlier. If this happens you see lines like hde: [PTBL] [4441/255/63] hde1 hde2 hde3 < hde5 > hde4 in the dmesg, but you did not report any PTBL, so as far as Linux is concerned the partition table did not play a role. (iv) It is impossible to guess what geometry the BIOS will invent, but Linux makes a feeble attempt. For your hda it asks the BIOS about hd0, the 0x80 disk. But if you also have SCSI disks, then the BIOS may number the disks such that 0x80 is the SCSI disk. (This may depend on which disk you boot from.) In such a case the geometry the BIOS reports is the geometry it uses for that SCSI disk. So, if you play with these things in order to understand all details, you can try with and without SCSI disks and see whether it makes a difference. (On my machine it does.) > I can't get linux to properly recognize the C/H/S A disk does not have a geometry, so there is no proper value. So, one has to invent something, rather arbitrarily. Since each BIOS invents different things, a disk may get a different geometry when you move it to a different machine. However, these days both Linux and Windows and all BIOSes can cope with different geometries, so all should be well for all parties involved with 16 heads, and all should also be well with 255 heads. Just make sure to select the proper thing in the BIOS setup. > On 586SG motherboard, Linux 2.4.0-testXX reported acceptable > 39693/16/63 (QUESTION: why 39693 is one less the number reported by > AMI BIOS? Oh well.) You can do the computation for yourself: 40011300/(16*63) = 39693. Apparently the AMI BIOS is buggy here. > Nov 23 20:59:40 standard kernel: hdc: 40011300 sectors (20486 MB) > w/512KiB Cache, CHS=39693/16/63, UDMA(33) > Then the disk is moved onto Soyo SY-K7VTA motherboard with AMD K7 > Duron 750 (the current CPU I use) and used there for two weeks. > > After digging up the old log, I found that the initially > all was well. > > Nov 24 13:21:45 standard kernel: hda: 40011300 sectors (20486 MB) > w/512KiB Cache, CHS=39693/16/63 > > So far, so good. > > (2-b) Tried partitioning with 2.2.1? and fdisk. > > I wanted to experimenting repartition the whole seagate disk into a > main linux partition, linux swap, and DOS/Win98 partition, etc.. While > playing with this using somewhat old Debian Gnu/Linux disk that had > 2.2.yy on it, the incorrect C/H/S crept in. (I think it was 2.2.12. > Ugh, very old.) > > Dec 6 05:37:09 duron kernel: hda: 40011300 sectors (20486 MB) > w/512KiB Cache, CHS=2490/255/63 > > (3) CHS=2490/255/63 stuck? > > I tried > > fdisk /mbr > > from the DOS/Win. (This may not clear the whole 512bytes as explained > in the ide.txt and large-disk-howto doc.) Precisely. It doesnt help at all. > dd if=/dev/null of=/dev/hdaZ bs=512 count=1 > > But this didn't to seem to work. > (I am now not sure which value of Z I used. Maybe I should try simple > hda without Z?) Yes, you should. But this changes something for Linux only in case it earlier reported PTBL which it didnt. So, it won't help, unless this changes something for the BIOS. > I even used the Seagate partition tool that could be used to partition > large disk from DOS (even on a machine without BIOS support for large > ATA disk). The tool, called Disk manager Disk managers only make your life much more complicated. Stay far away from them, if you can. > With the boot line command line parameter, fdisk /dev/hda prints the > following. > I take that as long as I stay away from the first and the last > partition, > I can make linux and win98 co-exist. > > command (m for help): p > > Disk /dev/hda: 16 heads, 63 sectors, 39693 cylinders > Units = cylinders of 1008 * 512 bytes > >Device BootStart EndBlocks Id System > /dev/hda1 * 1 3969 2616 FAT16 > Partition 1 does not end on cylinder boundary: > phys=(248, 254, 63) should be (248, 15, 63) > /dev/hda2 3969 39685 18000832+ f Win95 Ext'd (LBA) > Partition 2 does not end on cylinder boundary: > phys=(1023, 254, 63) should be (1023, 15, 63) Interesting. It looks like you are trying to get 39693/16/63 while Windows in fact uses the 2940/255/63 that you are trying to get rid
Re: Wiring down Pages
On Fri, 22 Dec 2000, Sourav Sen wrote: > Suppose I want to wire-down( as they call in BSD ) a page > in memory, how I go about doing that? (I guess by setting the > PG_locked bit of the flags field in the struct page, I can do > it, am I right?) Linux simply uses page->count for this. By using the page->count, multiple parts of the kernel can pin the same page in memory at different times and unlock them at different times without any locking/unlocking conflicts... page_cache_get(page); <= increases page->count page_cache_drop(page); <= removes your extra count regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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/
bigphysarea support in 2.2.19 and 2.4.0 kernels
A question related to bigphysarea support in the native Linux 2.2.19 and 2.4.0 kernels. I know there are patches for this support, but is it planned for rolling into the kernel by default to support Dolphin SCI and some of the NUMA Clustering adapters. I see it there for some of the video adapters. Is this planned for the kernel proper, or will it remain a patch? At the rate the VM and mm subsystems tend to get updated, I am wondering if there's a current version out for this. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Blow Torch (Re: lockups from heavy IDE/CD-ROM usage)
On Thu, 21 Dec 2000, Andre Hedrick wrote: > On Thu, 21 Dec 2000, safemode wrote: > > > I get this on the 440LX with the same DMA timeout message. Everyone says it's > > the board's fault as well. Funny. Anyways this happens accross just about > > any Dev kernel but more so in the -test12 and up versions. . Test10 works > > fine without locking. Blaming the hardware reminds me of the help given by > > some other company I can't seem to remember the name to. > > 29063507.pdf Page 22 sections 9,10 > What is the Intel solution to the is system hang? > > 29063507.pdf Page 25 section 16 > Is this erratum valid to include all PIIX4-AB/EB, PIIX3, and PIIX a/b. > > It is the DAMN hardware and quit BITCHING. > I told everyone once that I was working on this issue. > If you think you can fix it before me, be my guest. > > I have given you the INTEL doc numbers and the page and the section. > Go read. > > Regards > FYI, I havn't found a decent motherboard (chipset) amongst the new boards released during the past year. Both ASUS and TYAN boards, including the expensive "Thunderbolt", have the infamous "Bit 17" memory errors, regardless of the amount/kind/speed/cost of SDRAM installed. If you get an Oops trace, see if the faulting address would be correct if bit 17 was changed. There is something wrong with the timing on the SDRAM controller so that all the timing skews pile up, occasionally corrupting bit 17. This can't be by chance, since I have now tested over 10 different systems, most with different motherboards, and or course different sets of RAM from single 32 MB sticks to 8 256 MB sticks, P-100, to 133 MHz, etc. Every system has an occasional error with bit 17! I even wrote a memory-test program which shows this. So, either the SDRAM controller used on these boards is bad, or all the RAM produced by a half/dozen vendors over the past year is bad. Take a choice. Cheers, Dick Johnson Penguin : Linux version 2.4.0-test12 on an i686 machine (799.54 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/
Wiring down Pages
Hi, I am a novice in this exciting kernel world, so my questions may be a bit naive, please bear with me.(I am student at IISc, Bangalore). Suppose I want to wire-down( as they call in BSD ) a page in memory, how I go about doing that? (I guess by setting the PG_locked bit of the flags field in the struct page, I can do it, am I right?) sourav SOURAV SENMSc(Engg.) CSA IISc BANGALORE URL : www2.csa.iisc.ernet.in/~sourav ROOM NO : N-78 TEL :(080)309-2454(HOSTEL) (080)309-2906 (COMP LAB) - 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/
Blow Torch (Re: lockups from heavy IDE/CD-ROM usage)
On Thu, 21 Dec 2000, safemode wrote: > I get this on the 440LX with the same DMA timeout message. Everyone says it's > the board's fault as well. Funny. Anyways this happens accross just about > any Dev kernel but more so in the -test12 and up versions. . Test10 works > fine without locking. Blaming the hardware reminds me of the help given by > some other company I can't seem to remember the name to. 29063507.pdf Page 22 sections 9,10 What is the Intel solution to the is system hang? 29063507.pdf Page 25 section 16 Is this erratum valid to include all PIIX4-AB/EB, PIIX3, and PIIX a/b. It is the DAMN hardware and quit BITCHING. I told everyone once that I was working on this issue. If you think you can fix it before me, be my guest. I have given you the INTEL doc numbers and the page and the section. Go read. Regards Andre Hedrick Linux ATA Development - 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.2.19pre2
On Wed, Dec 20, 2000 at 02:28:58PM +0100, Andrea Arcangeli wrote:
> I was in the process of fixing this (I also just backported the thinkpad
> %edx clobber fix), but if somebody is going to work on this please let
> me know so we stay in sync.
Ok this should fix the e820 memory detection, against 2.2.19pre2:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.19pre2/e820-fix-1
While fixing the code I noticed some bug was inerith from 2.4.x so I forward
ported the fixes to 2.4.0-test13-pre3:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.4/2.4.0-test13-pre3/e820-fix-1
I also include them below so they're handy for Linus:
diff -urN 2.4.0-test13-pre3/arch/i386/kernel/setup.c
2.4.0-test13-pre3-e820/arch/i386/kernel/setup.c
--- 2.4.0-test13-pre3/arch/i386/kernel/setup.c Thu Dec 14 22:33:59 2000
+++ 2.4.0-test13-pre3-e820/arch/i386/kernel/setup.c Thu Dec 21 21:12:47 2000
@@ -477,7 +477,7 @@
if (start < 0x10ULL && end > 0xAULL) {
if (start < 0xAULL)
add_memory_region(start, 0xAULL-start,
type);
- if (end < 0x10ULL)
+ if (end <= 0x10ULL)
continue;
start = 0x10ULL;
size = end - start;
@@ -518,7 +518,8 @@
e820.nr_map = 0;
add_memory_region(0, LOWMEMSIZE(), E820_RAM);
- add_memory_region(HIGH_MEMORY, mem_size << 10, E820_RAM);
+ add_memory_region(HIGH_MEMORY, (mem_size << 10)-HIGH_MEMORY,
+ E820_RAM);
}
printk("BIOS-provided physical RAM map:\n");
print_memory_map(who);
The above patches doesn't include the fix for the thinkpad from Marc Joosen,
a backport of such bugfix is separately backported here (because it's
orthogonal with the other bugfixes):
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.19pre2/thinkpad-e820-mjoosen-1
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: lockups from heavy IDE/CD-ROM usage
Zdenek Kabelac wrote: > Problem: When i am using my harddrive and cdrom, my computer will freeze. > It freezes in two different ways.. sometimes just the harddrive access > will freeze (can still do things in X as long as they dont require the > harddrive), and then everything freezes within a few seconds. or else > everything just locks instntly. the problem is reproducable, all i need to > do is be using the harddrive extensively for a couple separate functions > (like compiling the kernel, and copying a large file) and ripping cd audio > (cd paranoia) and i can lock the system in as little as seconds, or a few > minutes sometimes. This will happen more reliably, and much quicker and This is really very similar to my problem with BP6 I'm reporting for a long long time. But everyone says its faulty board. For BP6 somehow helps to set UDMA to mode 2. (I'm not getting these locks when I'm just using ATA33 controler) (hdparm -X66 /dev/hdX) Also could you look at what is being written to console ? (run those intesive programs and stay on console - BP6 lock with this message displayed: hdf: timeout waiting for DMA ide_dmaproc: chipset supported ide_dma_timeout: func only 14 In this point it looks like timers are dead... :( And the situation is the same with SMP & NoSMP kernel with apic & noapic. I get this on the 440LX with the same DMA timeout message. Everyone says it's the board's fault as well. Funny. Anyways this happens accross just about any Dev kernel but more so in the -test12 and up versions. . Test10 works fine without locking. Blaming the hardware reminds me of the help given by some other company I can't seem to remember the name to.
Re: [RFC] Semaphores used for daemon wakeup
The mechanism being developed here seems a lot like synchronization
variables (aka condition variables), which are a part of the "monitor"
synchronization construct. There is a simple implementation of them in
the xfs patch. I've been working on a more general version in order to
aid porting some other stuff, which I have appended to this post.
I had been holding off on posting about it since I didn't have any code
that used it ready, and probably wouldn't until 2.5 anyway, but due to
this thread, I think bringing it up now might be helpful.
Daniel Phillips wrote:
> Tim Wright wrote:
> > p_sema_v_lock(, priority, ); /* atomically release the lock AND */
> > /* go to sleep on the semaphore */
This in particular looks like sv_wait(), which atomically releases a
lock and goes to sleep.
The style is somewhat different, as a sync variable (sv) is not really a
lock, but is still something that a process can block on. A process goes
to sleep by calling sv_wait(sv), and is woken up by another process
calling sv_signal(sv) (wake one) or sv_broadcast(sv) (wake all). If there
is no process sleeping in sv_wait, signals and broadcasts have no effect;
they do not affect any process which subsequently calls sv_wait().
Each sync variable is associated with another lock, which provides mutual
exclusion guarantees. This lock must be held to call sv_wait(), and is
dropped atomically with the process going to sleep. This lock must also
be held to call sv_signal() or sv_broadcast(). Currently, this lock can
be a spinlock or a semaphore; other types of locks could be added if
necessary.
The sync variable version of the dmabuf code snippet (assuming the
dmabuf_mutex is never acquired from an interrupt) would look like this:
dmabuf_init(...);
{
...
spin_lock_init(_spin);
sv_init(_sv, _spin, SV_MON_SPIN);
...
}
dmabuf_alloc(...)
{
...
while (1) {
spin_lock(_spin);
attempt to grab a free buffer;
if (success){
spin_unlock(_spin);
return;
} else {
sv_wait(_sv);
}
}
}
dmabuf_free(...)
{
...
spin_lock(_spin);
free up buffer;
sv_broadcast(_sv);
spin_unlock(_spin);
}
If dmabuf_free() could be called from an interrupt, this would be modified
by passing the SV_INTS flag to sv_init(), using spin_lock_irq() in
dmabuf_alloc, and spin_lock_irqsave/restore in dmabuf_free().
> > As you can see, the spinlocks ensure no races, and the key is the atomicity
> > of p_sema_v_lock(). No-one can race in and sleep on dmabuf_wait, because
> > they have to hold dmabuf_mutex to do so. Exactly the same mechanism would
> > work for the bdflush problem.
The same protections are in place here, as the two methods are basically
the same.
> described. The main difference between this situation and bdflush is
> that dmabuf_free isn't really waiting on dmabuf_alloc to fullfill a
> condition (other than to get out of its exclusion region) while bdflush
> can have n waiters.
This could be done with two sv's. After all, there are two conditions:
"someone needs bdflush to run", and "bdflush is done".
> int atomic_read_and_clear(atomic_t *p)
> {
> int n = atomic_read(p);
> atomic_sub(p, n);
> return n;
> }
I don't think this will work; consider two callers doing the atomic_read()
at the same time, or someone else doing an atomic_dec() after the
atomic_read().
> the more involved wake_up_process(). What's clear is, they are all
> plenty fast enough for this application, and what I'm really trying for
> is readability.
I think sv's are pretty readable and clear, but I'd like to find out what
other people think.
If anyone finds this useful or finds any bugs, or has any questions or
suggestions, please let me know. I'll be reading the list, but I'm going
on vacation tomorrow, so I'd appreciate a Cc: so I have a better chance of
answering before then. Thanks.
--
Paul Cassella
[EMAIL PROTECTED]
And now, the code.
include/linux/sv.h:
/*
This is the version I'm using with a test8-pre1 kernel, so it uses the
old TASK_EXCLUSIVE semantics; it should be trivial to make it work with
new kernels. I haven't yet done so, since we're going to be using the
test8-pre1 kernel for a few more weeks yet.
In the interests of brevity, I've taken out most of the debugging code,
some typecasting, and some other things like the wrapper functions for
up() and spin_unlock(), which are needed because we need a function
pointer, and these may be macros or inline fuctions.
This was originally based on the version Steve Lord did for the xfs port.
This version had no problems when put into the xfs tree an run through a
stress test. I don't
Re: Oop in 2.4.0-test12
On Thu, 21 Dec 2000, Ian Hastie wrote: > Looks like page_launder is still causing problems. I was using > ReiserFS version 3.6.23. As far as I remember it was running > Seti@Home 3.03 and compile qt-2.2.3. I was able to run ksymoops > without rebooting. So, can you (or anyone) reproduce any oops/indication of a kernel problem without having 'other' stuff in the kernel? If so, describe please.. tis not of necessity an indicitation of problems with your favorite application or driver if it is required to reproduce problem, but _is_ much easier to diagnose the root if you can provide a formula for failure [even obscure] which does not include 'foreign' material. I've not seen a reproducable report yet.. but the reports which I've seen ~jibe wrt 'there is something fairly odd going on'. (yes, I've my share of oddities, and no, I don't have anything solid either;) -Mike - 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: kapm-idled : is this a bug?
>> Agree that it is different. But it confuses people to have two >> idle-tasks. I suggest that we throw it one big pile, unless having a >> separate apm idle task has a purpose. > > You can't do that. Sure you can, and it makes perfect sense. > Doing it this way is _way_ better for system > stability, because kidle-apmd sometimes dies due to APM > bug. kidle-apmd dying is recoverable error; swapper dieing is as fatal > as it can be. Good. Maybe the bugs will get fixed then. If the bugs are in the BIOS or motherboard hardware, we can have a blacklist. - 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: strange nfs behavior in 2.2.18 and 2.4.0-test12
I can confirm this problem exists in Mandrake-7.2 as well with kernel 2.2.17-21. - Original Message - From: "John Covici" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, December 21, 2000 1:37 PM Subject: strange nfs behavior in 2.2.18 and 2.4.0-test12 > Hi. I am having strange nfs problems in both my 2.x and 2.4.0-test12 > kernels. > > What is happening is that when the machine boots up and exports the > directories for nfs, it complains that > > ccs2:/ invalid argument . > > The exports entry is > > / ccs2(rw,no_root_squash) > > Now in Kernel 2.2.18, if I stop and restart the nfs daemons, all is > OK, the invalid argument goes away, but in 2.4.0 I cannot get this to > work at all and so I cannot mount nfs from a client on the ccs2 box. > I am using the utilities 0.2.1-4 from the Debian distribution if that > makes any difference. I did an strace once on exportfs and it was > having trouble with the call to nfsservctl which returns invalid argument. > > > Any assistance would be appreciated. > > -- > John Covici > [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: Oops with 2.4.0-test13pre3 - swapoff
On Wed, 20 Dec 2000, Zdenek Kabelac wrote: > > Zdenek Kabelac wrote: > > > This is oops I've got when rebooting after some heavy disk activity on > > > my SMP system: > > > > > > Written by hand: > > > > > > kernel BUG swap_state.c:78! > > [snip] > > > > Same here during a halt of a RH 6.2 based K6-2 500 MHz > > UP machine running lk240t13p3. The machine had been on > > for a while and had built a kernel amongst other things. > > > > I'll just append that my machine has been up for just several > minutes (maybe 10) but has been doing heavy copying - several > 600MB files between some partitions. > > So maybe the problem with memory thrashing is still not fully fixed ??? The bug was in new shm's code it seems. Christoph is already looking at it and should have a fix soon. - 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: Unknown PCI device?
"Mike A. Harris" wrote: > >> Anyone know what this is? > >> > >> 00:07.3 Host bridge: VIA Technologies, Inc.: Unknown device 3050 (rev 30) > >> Flags: medium devsel > > > >if its pci id is 0x11063050, then it's a VIA Power Management Controller. > > 00:07.3 Class 0600: 1106:3050 (rev 30) > Flags: medium devsel > > Yip. Someone might want to update the PCI ID db, or whatever > with that.. If this were to be adopted: ftp://autogen.linuxave.net/pub/PCIDEV.tgz I would finish it so that there would be one and only one place to update for any and all PCI devices for 2.2, 2.4 and any other kernel. However, it would take several days and I won't do it unless there were some reasonable chance for adoption. The referenced implementation only covers the 2.4 kernel: 1. the list of PCI manufacturers and devices 2. the IDE controllers still to do would be the dispatch tables for other kinds of devices, the tables for the 2.2 kernel and the device information for the non-IDE dispatch tables. (The latter being the hard [time consuming] part. Creating the tables from the data is easy.) Once this is all done, both the 2.2 and 2.4 (and future) kernels would be kept up to date by updating a single database and regenerating the tables. - 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 kernels and vpn
Hi. Is there a way to support vpn in the 2.4.0 kernels like we had with the patch for the 2.2.x kernels? Any assistance would be appreciated. -- John Covici [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/
strange nfs behavior in 2.2.18 and 2.4.0-test12
Hi. I am having strange nfs problems in both my 2.x and 2.4.0-test12 kernels. What is happening is that when the machine boots up and exports the directories for nfs, it complains that ccs2:/ invalid argument . The exports entry is / ccs2(rw,no_root_squash) Now in Kernel 2.2.18, if I stop and restart the nfs daemons, all is OK, the invalid argument goes away, but in 2.4.0 I cannot get this to work at all and so I cannot mount nfs from a client on the ccs2 box. I am using the utilities 0.2.1-4 from the Debian distribution if that makes any difference. I did an strace once on exportfs and it was having trouble with the call to nfsservctl which returns invalid argument. Any assistance would be appreciated. -- John Covici [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/
IDE woes:linux and BIOS won't agree on C/H/S detection
IDE woes. Sorry for this lengthy post, I read ide.txt, large-disk-howto.txt and experimented with fdisk (DOS/WIN), dd, and a few other tricks, but can't seem to be able to solve a question. Big Question - 1: I have a 20GB seagate ATA disk. My Board BIOS recognizes the CHS geometry when it auto-detects the disk as C/H/S=39694/16/63. However, linux refuses to recognize this and tries to report C/H/S=2490/255/63. This 2490/255/63 seems to get stuck after I tried partitioning the disk using OLD 2.2.yy (probably 2.2.12?) Debian GNU/Linux CD installer. (beta version of stormlinux CD in fact.) How can I get rid of this "unnatural" C/H/S information so that linux boots with the geometry that BIOS uses. This is necessary for me to make win98 co-exist with linux on this disk. I tried a few commands : fdisk /mbr dd if=/dev/null of=/dev/hdaZ bs=512 count=1 Run Seagate Disk Manager to partition the disk with motherboard BIOS C/H/S setting hopefully, but no luck so far. The boot command line parameter saved the day for now. I added the following to the boot command line: hda=39694,16,63 But this is a little awkward since I tend to forget to add the hda=39694,16,63 paramater to the command line when I make emergency loadlin DOS disk, etc. How can I "erase" this 2940/255/63 CHS setting from the disk so that linux will use 39694/16/63 WITHOUT boot command line parameter? The rest is the long background of hardware and the history that led to the current problem. Lengthy background and historical information. OS version: uname -a Linux duron 2.4.0-test12 #16 Thu Dec 21 03:07:26 JST 2000 i686 unknown CPU: AMD K7 Duron 750 (100x7.5) Motherboard: Gigabyte GA-7IXE4 Chipset : AMD 751 PCI/AGP controller + AMD 756 PCI IDE controller BIOS AMI BIOS. Disk in question: Seagate ST320423A 20GB ATA disk. This is the only IDE/ATA disk (on primary controller as a master device. I have an ATAPI CDROM on the secondary controller.) My main linux stays on a SCSI disk via Tekram SCSI controller. Symptom: I can't get linux to properly recognize the C/H/S with the hardware combination above. I would like to make win98 and linux co-exist on this disk and the motherboard (MB) BIOS and linux not agreeing on this is a disaster. My Board BIOS recognizes the CHS geometry when it auto-detects the disk as C/H/S=39694/16/63. However, linux refuses to recognize this and tries to report C/H/S=2490/255/63. (These numbers seemed to picked up by 2.2.yy installation I tried on the disk earlier.) Right now, I am forced to add ... hda=39694,16,63 ... on the boot command line. /usr/src/linux/Documentation/ide.txt states: Drives are normally found by auto-probing and/or examining the CMOS/BIOS data. For really weird situations, the apparent (fdisk) geometry can also be specified on the kernel "command line" using LILO. The format of such lines is: hdx=cyls,heads,sects,wpcom,irq or hdx=cdrom I am not sure why my hardware combo became weired, but something is wrong here. I suspect that incorrect fdisk information left by 2.2.12 kernel tool might be the culprit, but can't pin point where the problem lies and thus am posting this for experts' opinion. What prompted me to think like this is the following history. (1) The disk was originally used on a Gigabyte 586SG motherboard as a secondary master device. (586SG uses AWARD BIOS.) I think it uses VIA chip set.(I can dig up documentation if this proves important.) On 586SG motherboard, Linux 2.4.0-testXX reported accetable 39693/16/63 (QUESTION: why 39693 is one less the number reported by AMI BIOS? Oh well.) The disk was formatted as a big Linux partition using Linux fdisk. Since this was a big linux-only disk, I didn't have to worry about this CHS mismatch with other OS. The following is an excerpt from the /var/log/messages: the device hdc is the disk in question. >Nov 23 20:59:40 standard kernel: hda: 3419720 sectors (1751 MB) w/256KiB Cache, CHS=904/60/63, UDMA(33) >Nov 23 20:59:40 standard kernel: hdc: 40011300 sectors (20486 MB) w/512KiB Cache, CHS=39693/16/63, UDMA(33) (cf. The CPU on 586SG was AMD K6-III/400. I had two IDE disks as the log above showed and one SCSI CDROM.) (2) New motherboard: part-1. Then the disk is moved onto Soyo SY-K7VTA motherboard with AMD K7 Duron 750 (the current CPU I use) and used there for two weeks. Soyo SY-K7VTA uses VIA chipset (apollo KT133 + 686A) and uses AWARD BIOS. I put the seagate drive as the single IDE/ATA disk as primary master device. I put an ATAPI CDROM as secondary slave. (Later on, I moved the main scsi disk where my linux 2.4.0-testXX is stored to this motherboard. I could boot the 2.4.0-testXX using loadlin floppy.) (2-a) SOYO Motheboard. Initial attempt. After digging up the old log, I found that the initially all was well. On this Soyo motherboard, the disk was
Re: 2.2.18 signal.h
Andrea Arcangeli wrote:
>
> On Fri, Dec 15, 2000 at 05:55:08PM -0200, Rik van Riel wrote:
> > On Fri, 15 Dec 2000, Andrea Arcangeli wrote:
> >
> > > x()
> > > {
> > >
> > > switch (1) {
> > > case 0:
> > > case 1:
> > > case 2:
> > > case 3:
> > > ;
> > > }
> > > }
> > >
> > > Why am I required to put a `;' only in the last case and not in
> > > all the previous ones?
> >
> > That `;' above is NOT in just the last one. In your above
> > example, all the labels will execute the same `;' statement.
> >
> > In fact, the default behaviour of the switch() operation is
> > to fall through to the next defined label and you have to put
> > in an explicit `break;' if you want to prevent `case 0:' from
> > reaching the `;' below the `case 3:'...
>
> Are you kidding me?
Absolutely NOT.
switch (x) {
case 0:
case 1:
printf ("%d\n", x);
break;
case 2:
printf ("%d\n",x*x);
case 3:
printf ("%d\n", x*x*x);
}
if x==0 or 1, prints x (the 0 or one),
if x==2 , it prints 4 and 8 since no break statement exits the switch,
if x==3, it prints only 27,
any othe value of x, and nothing is printed.
Every C compile I have ever used does this.
Sun's C and C++, HP's C, Microsoft's VC++, Borland's C, and all versions
of gcc and g++.
Grab any C programming book, and find the switch statement.
-Thomas
-
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: CPU attachent and detachment in a running Linux system
Hi,
>> That's a good point and it would probably work for attachment of cpus,
but
>> it won't work for detachment because there are some data structures that
>> need to be updated if a cpu gets detached. For example it would be nice
>> [...]
>> So at least for detaching it would make sense to register functions
which
>> will be called whenever a cpu gets detached.
>I remember someone from SGI had a patch to merge all the per cpu
structures
>together which would make this easier. It would also save bytes especially
>on machines like the e10k where we must have NR_CPUS = 64.
Thanks for your comment, but I thought of an additional kernel parameter
max_dyn_cpus which would limit the maximum number of cpus that are allowed
to run. This way at least the waste of dynamically allocated memory which
depends on smp_num_cpus will be limited. This could be done by replacing
appropriate occurrences of smp_num_cpus with a macro MAX_DYN_CPUS which
could be defined the following way:
#ifdef CONFIG_DYN_CPU
extern volatile int smp_num_cpus; /* smp_num_cpus may change */
extern int max_dyn_cpus;
#define MAX_DYN_CPUS max_dyn_cpus
#else
extern int smp_num_cpus; /* smp_num_cpus won't change */
#define MAX_DYN_CPUS smp_num_cpus
#endif
Comming back to the question on how to realize an interface where per cpu
dependent parts of the kernel could register a function whenever a cpu gets
detached I think the following approach would work fine:
To register a function the following structure would be used:
typedef struct smp_dyncpu_func_s smp_dyncpu_func_t;
struct smp_dyncpu_func_s {
void (*f)(int);
smp_dyncpu_func_t *next;
};
The function which would be called when a function needs to be registered
would look like this:
smp_dyncpu_func_t *dyncpu_func; /* NULL */
...
void smp_register_dyncpu_func(smp_dyncpu_func_t *func)
{
func->next = dyncpu_func;
dyncpu_func = func;
return;
}
And finally every part of the kernel that needs to register a function
which would be used to clean up per cpu data structures would have some
additional code added which would look like this:
static smp_dyncpu_func_t smp_cleanup_func;
...
void local_dyncpu_handler(int killed_cpu){...}
...
static int __init local_dyncpu_init(void)
{
smp_cleanup_func.f = _dyncpu_handler;
smp_register_dyncpu_func(_cleanup_func);
return 0;
}
...
__initcall(local_dyncpu_init);
Thinking of modules which may have also per cpu structures there could
be a second function which allows to unregister prior registered
functions.
So what do you think of this approach? I would appreciate any comments
on this.
Best regards,
Heiko
-
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.2.19pre2
On Thu, 21 Dec 2000, Andrea Arcangeli wrote: > It would also be nice if you could show a real life > showstopper-production-bottleneck where we need C) to fix it. I > cannot see any useful usage of C in production 2.2.x. Me neither. I'm just wondering at the reason why 2.2 semantics would be different than 2.4 ones now we still have the choice of just cut'n'pasting over the (working) code from 2.4... regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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.2.19pre2
On Thu, Dec 21, 2000 at 03:07:08PM -0200, Rik van Riel wrote: > c) will also implement a) in an obviously right and simple way. So go ahead. If you think that's so simple and obviously right you can post here a patch here against 2.2.19pre2 that implements C) to show real facts. My B is here: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.19pre2/wake-one-2 Then we will see how much C) is obviously right and simple way compared to B). I don't need to see C) implemented to see how much it's obviously right and simple but if you think I'm wrong again: go ahead. It would also be nice if you could show a real life showstopper-production-bottleneck where we need C) to fix it. I cannot see any useful usage of C in production 2.2.x. Doing waitqueues in 2.2.x and 2.4.x is an irrelevant point (keeping the same API and semantics is much better than anything else for 2.2.x unless there's some serious showstopper that isn't possible to fix with B) and that I still cannot see). People backporting drivers from 2.4.x will use wake-all as they had to do during the whole 2.3.x, that's obviously safe and trivial. If they know what they're doing they can also use the 2.2.x wake-one API if their task is registered only in 1 waitqueues (as 99% of usages I'm aware of given whole 2.3.x implemented B too). Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Oop in 2.4.0-test12
Looks like page_launder is still causing problems. I was using
ReiserFS version 3.6.23. As far as I remember it was running
Seti@Home 3.03 and compile qt-2.2.3. I was able to run ksymoops
without rebooting.
ksymoops 2.3.5 on i686 2.4.0-test12. Options used
-v /boot/vmlinux-2.4.0-test12 (specified)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.0-test12/ (default)
-m /boot/System.map-2.4.0-test12 (specified)
Unable to handle kernel NULL pointer dereference at virtual address 000c
c012cf63
*pde =
Oops:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: ebx: c1097d0c ecx: 04ba edx: 0002
esi: c1097cf0 edi: 3a33 ebp: esp: c1479fb4
ds: 0018 es: 0018 ss: 0018
Process bdflush (pid: 6, stackpage=c1479000)
Stack: c1478000 c027703c 0008e000 c1478000 3a32
c01361bd 0003 00010f00 c145ff8c c145ffd8 c0109043
c145ffc4 c145ffc4 c145ffc4
Call Trace: [] []
Code: 8b 40 0c 8b 10 85 d2 0f 84 85 04 00 00 83 7c 24 18 00 75 4e
>>EIP; c012cf63<=
Trace; c01361bd
Trace; c0109043
Code; c012cf63
<_EIP>:
Code; c012cf63<=
0: 8b 40 0c mov0xc(%eax),%eax <=
Code; c012cf66
3: 8b 10 mov(%eax),%edx
Code; c012cf68
5: 85 d2 test %edx,%edx
Code; c012cf6a
7: 0f 84 85 04 00 00 je 492 <_EIP+0x492> c012d3f5
Code; c012cf70
d: 83 7c 24 18 00cmpl $0x0,0x18(%esp,1)
Code; c012cf75
12: 75 4e jne62 <_EIP+0x62> c012cfc5
--
Ian.
I don't have a sig either!
-
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] few fixes for ymf_sb.c in test13pre3-ac3
> CONFIG_SOUND_YMFPCI is declared twice - once outside CONFIG_OSS, then > inside CONFIG_OSS. I'm removing the later declaration. Its an in progress thing. The next stage is to remove ymf_sb completely as we have done in 2.2.19pre and to put the ymf_sb midi magic into it - 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] few fixes for ymf_sb.c in test13pre3-ac3
Hello, Alan! Thank you for applying my patch to test13pre3-ac3! However, there is a glaring bug in drivers/sound/Config.in - CONFIG_SOUND_YMFPCI is declared twice - once outside CONFIG_OSS, then inside CONFIG_OSS. I'm removing the later declaration. CONFIG_SOUND_YMPCI should be disabled if the native driver is compiled into the kernel. I'm fixing it as well. Also I tried ymf_sb.c without SUPPORT_UART401_MIDI defined (you have to edit ymf_sb.c to undefine it). I noticed that the "soundcore" module would remain in memory with usage count 1 after inserting and removing "ymf_sb". It appears that ymf_sb.c should never call sb_dsp_unload with the second argument being 1 (unload_mpu). It's a 1-byte fix. I decided not to change the signature of ymf7xxsb_unload_sb for now. The patch is also available here: http://www.red-bean.com/~proski/ymf/ymf_sb.patch P.S. The patch has been tested. My system is running test13pre3-ac3 and playing nice music :-) Regards, Pavel Roskin --- linux.orig/drivers/sound/Config.in +++ linux/drivers/sound/Config.in @@ -145,9 +145,8 @@ dep_tristate 'Yamaha FM synthesizer (YM3812/OPL-3) support' CONFIG_SOUND_YM3812 $CONFIG_SOUND_OSS dep_tristate 'Yamaha OPL3-SA1 audio controller' CONFIG_SOUND_OPL3SA1 $CONFIG_SOUND_OSS dep_tristate 'Yamaha OPL3-SA2, SA3, and SAx based PnP cards' CONFIG_SOUND_OPL3SA2 $CONFIG_SOUND_OSS - dep_tristate 'Yamaha YMF7xx PCI audio (legacy mode)' CONFIG_SOUND_YMPCI $CONFIG_SOUND_OSS $CONFIG_PCI - if [ "$CONFIG_SOUND_YMPCI" = "n" ]; then - dep_tristate 'Yamaha YMF7xx PCI audio (native mode) (EXPERIMENTAL)' CONFIG_SOUND_YMFPCI $CONFIG_SOUND_OSS $CONFIG_PCI $CONFIG_EXPERIMENTAL + if [ "$CONFIG_SOUND_YMFPCI" != "y" ]; then + dep_tristate 'Yamaha YMF7xx PCI audio (legacy mode)' CONFIG_SOUND_YMPCI +$CONFIG_SOUND_OSS $CONFIG_PCI fi dep_tristate '6850 UART support' CONFIG_SOUND_UART6850 $CONFIG_SOUND_OSS --- linux.orig/drivers/sound/ymf_sb.c +++ linux/drivers/sound/ymf_sb.c @@ -836,7 +836,7 @@ ymf7xxsb_unload_sb (_data[i], 0); ymf7xxsb_unload_midi (_data[i]); #else - ymf7xxsb_unload_sb (_data[i], 1); + ymf7xxsb_unload_sb (_data[i], 0); #endif } - 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: tighter compression for x86 kernels
> > Both source (GPLv2) and pre-compiled binary for x86 are available. >^ > That's not true. Read > http://wildsau.idv.uni-linz.ac.at/mfx/upx-license.html The UPX team owns all copyright in all of UPX and in each part of UPX. Therefore, the UPX team may choose which license(s), and has chosen two. One of them is GPLv2. The UPX team understands, and fully intends to abide by, its obligations under GPLv2 when any software that is subject to GPLv2 is contributed to UPX and re-distributed by the UPX team. The other license is detailed in the LICENSE file, but may be summarized as: free to use if unmodified, and if used only to invoke the program, and sublicensable only under the same terms. This permits using UPX to pack a non-GPL executable. Users of UPX (as distributed by the UPX team) may choose whether to use UPX according to GPLv2, or according to the other license. [I am not subscribed to this mailing list, so CC: or mail me if appropriate.] -- John Reiser, [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: [PATCH] Quota patches for test12
> I've ported my quota patches for 2.4.0-test12. > You can download the patches from > ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/ > quota-fix-2.4.0-test12-1.diff.gz > and > quota-patch-2.4.0-test12-1.diff.gz Sorry to follow up myself. I had better tell what those patches do :-): quota-fix patch fixes some bugs in quota code - fixes race between ext2 preallocation and chgrp (might be exploitable) fixes race in writing of message to console (some messages might be lost) make allocation of quota structures in memory fully dynamic (no more "No free dquots" messages) quota-patch patch implements new quotafile format. It allows quota for 32-bit UID/GID root is no more special user allows counting of disk quota in bytes (used currently only in ReiserFS) Note that to apply quota-patch you need to apply quota-fix first. Also you need to download new version of quota utilities if you want to use new quotafile format (ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/utils/quota-3.00-4.tar.gz). If you apply quota-patch you will be able to use quota support in ReiserFS (you need also to apply quota patch for ReiserFS which should be available for test12 at their ftp soon). Honza - 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.2.19pre2
On Thu, 21 Dec 2000, Andrea Arcangeli wrote: > > The key question is: which of the following do we want? > > > > a) A simple, specific accept()-accelerator, and 2.2 remains without > >an exclusive wq API or > > To make the accellerator we need a minimal wake-one support. So a) doesn't > make sense to me. > > > b) A general purpose exclusive wq mechanism which does not correctly > >support waiting on two queues simultaneuously where one is > >exclusive or > > That's what we had in whole 2.3.x and that is better suitable for 2.2.x > as it allows to do a) with obviously right approch and minimal effort. > > > c) A general purpose exclusive wq mechanism which _does_ support it. > > > > Each choice has merit! You seem to want b). davem wants c). > > I have not read any email from DaveM who proposes C for > 2.2.19pre3 (or 2.2.x in general). Are you sure he wasn't talking > about 2.4.x? c) will also implement a) in an obviously right and simple way. I've still not seen ANY reason why we'd want 2.2 to have different wake-one semantics from 2.4... > > And given that 2.2 has maybe 2-4 years life left in it, I'd > > I hope no ;). People are still converting their 2.0 systems to 2.2 as we speak. I really doubt that 2.2 has _less_ than 3 years of life left ... as much as I hate this idea ;) > > agree with David. Let's do it once and do it right while the issue > > is fresh in our minds. > > I disagree. The changes to separate the two waitqueues even only > for accept are not suitable for 2.2.x. Alan filter should forbid > that changes. They're simply not worthwhile because I cannot > even think at ... They're not worthwhile just because you can't think of an example ? The same could be said of `b)' above. Do you have an example where that is the preferable semantics ? If both are equally preferable (ie. nobody can think of any example where the corner case is being used), why do you keep insisting on giving 2.2 different wake-one semantics from 2.4 ? [these wake-one semantics may become rather important for people backporting drivers to 2.2 over the next years ... or to something else which nobody has even thought about ... 2-4 years is a long time, so 2.2 maintainability is still an issue] regards, Rik -- Hollywood goes for world dumbination, Trailer at 11. http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: [RFC] Semaphores used for daemon wakeup
On Wed, Dec 20, 2000 at 02:34:56AM +0100, Daniel Phillips wrote:
>
> Yes, I see. There are a lot of similarities to the situation I
> described. The main difference between this situation and bdflush is
> that dmabuf_free isn't really waiting on dmabuf_alloc to fullfill a
> condition (other than to get out of its exclusion region) while bdflush
> can have n waiters.
>
> If I could have a new primitive for this job it would be up_down(sem1,
> sem2), atomic with respect to a sleeper on sem1. And please give me an
> up_all for good measure. Then for a task wanting to wait on bdflush I
> could write:
>
> up_down(_request, _waiter);
>
> And in bdflush, just:
>
> up_all(_waiter);
> down(_request);
>
OK,
I believe that this would look like the following on ptx (omitting all the
obvious stuff :-)
lock_t bdflush_lock;
sema_t bdflush_request;
sema_t bdflush_waiters;
...
init_lock(_lock);
init_sema(_request, 0);
init_sema(_waiters, 0);
...
wakeup_bdflush(...)
{
...
(void) p_lock(_lock, SPLBUF);
v_sema(_request);
p_sema_v_lock(_waiters, PZERO, _lock);
}
bdflush(...)
{
spl_t s;
...
s = p_lock(_lock, SPLFS);
vall_sema(_waiters);
v_lock(_lock, s);
if (!flushed || ...
...
}
Once more, the use of p_sema_v_lock() avoids races.
>
> > One can argue the relative merits of the different approaches. I suspect that
> > the above code is less bus-intensive relative to the atomic inc/dec/count ops,
> > but I may be wrong.
>
> I couldn't say, because your mechanism would need to be elaborated a
> little to handle bdflush's multiple waiters, and I don't know exactly
> what your up_and_wait would look like. Do spinlocks work for bdflush,
> or would you have to go to semaphores? (If the latter you arrive at my
> up_down primitive, which is interesting.) It's even hard to say whether
> my approach is faster or slower than the existing approach. Ultimately,
> up() calls wake_up() and down() calls both add_wait_queue() and
> remove_wait_queue(), so I lose a little there. I win in the common case
> of the non-blocking wakeup, which normally runs through Ben Lahaises's
> lovingly handcrafted fast path in up(), whereas the existing code uses
> the more involved wake_up_process(). What's clear is, they are all
> plenty fast enough for this application, and what I'm really trying for
> is readability.
>
The above hopefully elaborates a little. I'm more than happy to give further
details etc. assuming it's not boring everybody to tears :-)
I agree with you that your changes improve the readability significantly.
Regards,
Tim
--
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
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] performance enhancement for simple_strtoul
> On Wed, 20 Dec 2000, Steve Grubb wrote:
>
> > +while (isdigit(c)) {
> > +result = (result*10) + (c & 0x0f);
> > +c = *(++cp);
> > +}
>
> x * 10 can be written as:
>
> (x << 2 + x) << 1 = (4x+x) * 2
> (x << 3) + (x << 1) = 8x + 2x
Since when has printk been performance critical. It isnt worth microoptimising
(or in your case for some cpus micropessimising) that stuff. Besides, gcc should
work it out if its worth doing
-
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: memmove() in 2.4.0-test12, alpha platform
On Wed, Dec 20, 2000 at 10:03:42PM +0300, Alexander Zarochentcev wrote: > New (since test12) optimized memmove function seems to be broken > on alpha platform. Indeed it is. > If dest and src arguments are misaligned, new memmove does wrong things. Actually it broke when dest < src. Incrementing pointers should be used in this case. This patch seems to work (tested in userspace). Ivan. --- linux/arch/alpha/lib/memmove.S.orig Tue Dec 12 00:46:26 2000 +++ linux/arch/alpha/lib/memmove.S Thu Dec 21 18:32:59 2000 @@ -26,12 +26,16 @@ memmove: bne $1,memcpy and $2,7,$2 /* Test for src/dest co-alignment. */ - bne $2,$misaligned + and $16,7,$1 + cmpule $16,$17,$3 + bne $3,$memmove_up /* dest < src */ and $4,7,$1 - beq $1,$skip_aligned_byte_loop_head + bne $2,$misaligned_dn + unop + beq $1,$skip_aligned_byte_loop_head_dn -$aligned_byte_loop_head: +$aligned_byte_loop_head_dn: lda $4,-1($4) lda $5,-1($5) unop @@ -48,13 +52,13 @@ $aligned_byte_loop_head: and $4,7,$6 stq_u $1,0($4) - bne $6,$aligned_byte_loop_head + bne $6,$aligned_byte_loop_head_dn -$skip_aligned_byte_loop_head: +$skip_aligned_byte_loop_head_dn: lda $18,-8($18) - blt $18,$skip_aligned_word_loop + blt $18,$skip_aligned_word_loop_dn -$aligned_word_loop: +$aligned_word_loop_dn: ldq $1,-8($5) nop lda $5,-8($5) @@ -63,22 +67,22 @@ $aligned_word_loop: stq $1,-8($4) nop lda $4,-8($4) - bge $18,$aligned_word_loop + bge $18,$aligned_word_loop_dn -$skip_aligned_word_loop: +$skip_aligned_word_loop_dn: lda $18,8($18) - bgt $18,$byte_loop_tail + bgt $18,$byte_loop_tail_dn unop ret $31,($26),1 .align 4 -$misaligned: +$misaligned_dn: nop fnop unop beq $18,$egress -$byte_loop_tail: +$byte_loop_tail_dn: ldq_u $3,-1($5) ldq_u $2,-1($4) lda $5,-1($5) @@ -91,8 +95,77 @@ $byte_loop_tail: bis $1,$2,$1 stq_u $1,0($4) + bgt $18,$byte_loop_tail_dn + br $egress + +$memmove_up: + mov $16,$4 + mov $17,$5 + bne $2,$misaligned_up + beq $1,$skip_aligned_byte_loop_head_up + +$aligned_byte_loop_head_up: + unop + ble $18,$egress + ldq_u $3,0($5) + ldq_u $2,0($4) + + lda $18,-1($18) + extbl $3,$5,$1 + insbl $1,$4,$1 + mskbl $2,$4,$2 + + bis $1,$2,$1 + lda $5,1($5) + stq_u $1,0($4) + lda $4,1($4) + + and $4,7,$6 + bne $6,$aligned_byte_loop_head_up + +$skip_aligned_byte_loop_head_up: + lda $18,-8($18) + blt $18,$skip_aligned_word_loop_up + +$aligned_word_loop_up: + ldq $1,0($5) + nop + lda $5,8($5) + lda $18,-8($18) + + stq $1,0($4) + nop + lda $4,8($4) + bge $18,$aligned_word_loop_up + +$skip_aligned_word_loop_up: + lda $18,8($18) + bgt $18,$byte_loop_tail_up + unop + ret $31,($26),1 + + .align 4 +$misaligned_up: + nop + fnop + unop + beq $18,$egress + +$byte_loop_tail_up: + ldq_u $3,0($5) + ldq_u $2,0($4) + lda $18,-1($18) + extbl $3,$5,$1 + + insbl $1,$4,$1 + mskbl $2,$4,$2 + bis $1,$2,$1 + stq_u $1,0($4) + + lda $5,1($5) + lda $4,1($4) nop - bgt $18,$byte_loop_tail + bgt $18,$byte_loop_tail_up $egress: ret $31,($26),1 - 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-12: Hard Hang related to Serial Mouse
I'm not on this list, so please respond directly to me for more info. I was running 2.4.0-12 (back to -10 now), K6-2 chip. With -12, the system would hard-hang quite frequently. Complete lockup: no response to alt-sysrq, so no info available. Eventually I figured out that this was only happening when I was moving the mouse. I'm also running xfree-4, which may be related, but that shouldn't be able to lock the system up completely. Jim http://as220.org/jb Public Key: http://as220.org/jb/key - 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.2.19pre2
On Thu, Dec 21, 2000 at 09:38:43PM +1100, Andrew Morton wrote: > Andrea Arcangeli wrote: > > > > The fact you could mix non-exclusive and exlusive wakeups in the same waitqueue > > was a feature not a misfeature. Then of course you cannot register in two > > waitqueues one with wake-one and one with wake-all but who does that anyways? > > Definitely not an issue for 2.2.x. > > Definitely? Let's think about that. If you can tell one showstopper bottleneck in 2.2.x that needs to register in two waitqueues at the same time, one exclusive and one non-exclusive, then I will think about it. > > I think the real reason for spearating the two things as davem proposed is > > because otherwise we cannot register for a LIFO wake-one in O(1) as we needed > > for accept. > > Yes. In other words, if we try to do O(1) LIFO, we can cause lost wakeups. We can do LIFO in O(N) just fine, no lost wakeups with the "mix" way. Only problem is additional complexity in the inserction operation. > > Other thing about your patch, adding TASK_EXCLUSIVE to > > wake_up/wake_up_interruptible is useless. > > This enables wake_up_all(). It is useless as it is in 2.2.19pre2: there's no wake_up_all in 2.2.19pre2. > Anyway, this is all just noise. > > The key question is: which of the following do we want? > > a) A simple, specific accept()-accelerator, and 2.2 remains without >an exclusive wq API or To make the accellerator we need a minimal wake-one support. So a) doesn't make sense to me. > b) A general purpose exclusive wq mechanism which does not correctly >support waiting on two queues simultaneuously where one is >exclusive or That's what we had in whole 2.3.x and that is better suitable for 2.2.x as it allows to do a) with obviously right approch and minimal effort. > c) A general purpose exclusive wq mechanism which _does_ support it. > > Each choice has merit! You seem to want b). davem wants c). I have not read any email from DaveM who proposes C for 2.2.19pre3 (or 2.2.x in general). Are you sure he wasn't talking about 2.4.x? BTW, you also implemented b) in 2.2.19pre2 ;) > And given that 2.2 has maybe 2-4 years life left in it, I'd I hope no ;). > agree with David. Let's do it once and do it right while the issue > is fresh in our minds. I disagree. The changes to separate the two waitqueues even only for accept are not suitable for 2.2.x. Alan filter should forbid that changes. They're simply not worthwhile because I cannot even think at one bottleneck-showstopper place that registers in two waitqueues and wants wake-one from one and wake-all from the other in 2.2.x. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Limiting disk-io
Hi I am going to create a shell-server for a networking-meeting with cd-writer. Usually, this is not a problem, but I would like to know if there are any kernel-patches which can limit the io-bandwidth for a user to the harddisk so that a user which is using the cd-writer has at least x kb/s. Renicing the cdrecord-process is only a little bit helpful. It is still possible to interrupt a cdrecord which is running with priority -20 with 3 or 4 processes which are running with priority 20. So if some users are starting mkisofs at the same time, then cdrecord will be interrupted. Or does anybody know a good userspace-solution? - 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: fs corruption in 2.4.0-test11?
David Weinehall <[EMAIL PROTECTED]> said: > On Thu, Dec 21, 2000 at 10:31:56AM -0300, Horst von Brand wrote: > > David Weinehall <[EMAIL PROTECTED]> said: > > > On Wed, Dec 20, 2000 at 04:47:42PM -0800, Larry McVoy wrote: > > > > I just need a sanity check - do other pages/blocks sometimes show > > > > up in recently created files in 2.4.0-test11? > > > Mmmm. Yes. I think the final fixes for this went into > > > v2.4.0-test12pre5, but since there's a test13-pre3 out that needs > > > testing, go for that one directly... :^) > > 2.4.0-test13-pre ate /usr/src at home (i686, RH7 + updates): Again, > > files turn into directories, massive ammounts of duplicate blocks, ... > > Not as bad as 2.4.0-test11 used to be (/ survived this time ;-) > ext2, ext3 or reiserfs (or xfs or jfs or ...) ext2. > Still, this sounds bad to me. Have you reported this to Linus+Alexander > Viro? Oh, never mind, I'm CC:ing them now. Nope, didn't. Thanks! -- 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/
Want to join
want to join linux-kernel __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.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/
