Re: Unreliable TCP?

[Willy Tarreau]

On Sat, Mar 19, 2005 at 09:59:16PM -0500, Ioan Ionita wrote:
> Hello.  I apologize if this may sound stupid/unknowledgeable.  I'm
> currently fooling around with real time voice conferencing
> applications which use the UDP protocol.  However, certain firewalls
> don't allow UDP traffic, therefore I tried UDP over TCP as a
> workaround.

I don't agree with this reason. One more valid reason could have been the
non-connected aspect of UDP which is not easy to manage through all
firewalls (timeouts, etc...). But all firewalls support UDP (eg: DNS).
If the firewall you're trying to bypass supports DNS, then encapsulate
your voice in DNS requests/responses, and when the admin complains, then
ask him to open another port.

>  This failed miserably, as the ACK aspect of TCP, which
> delays everything when a packet is lost or received out of order makes
> voice conferencing anything but real time.  So I was wondering if
> there's any way to disable the whole reliability checking of TCP in
> the linux kernel. Maybe configure the kernel to never request the
> retransmission of a packet, even if it detects packet loss/bad order?

If you disable retransmission, then some firewalls will sometimes block
because some packets will be out of window. And not only data are sent
in TCP, but control bits (SYN, FIN, RST) must not be lost. Some TCP
options such as window scaling will have a terrible impact if they are
lost and not retransmitted.

At most, you should lower the retransmit timeout. The 3s initial timeout
is far too high with todays local networks, and prevent real-time
applications from using TCP. However, if you use something like a few
tens or hundreds ms (depending on the RTT), you might get your voice
working on TCP.

Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RDMA (Remote Direct Memory Access)

[regatta]

Hi

Is there any plan to support RDMA in Linux ? what is the status ?

my question is because I know that windows HPC project will support
RDMA in release 2 and they also will support infiniband

They also will support Intel Xeon 64 or the AMD Opteron  only



-- 
Best Regards,

-*- If Linux doesn't have the solution, you have the wrong problem -*-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/4] crypto/sha256.c: fix sparse warnings

[Herbert Xu]

[EMAIL PROTECTED] wrote:
>
> diff -puN crypto/sha256.c~sparse-crypto_sha256 crypto/sha256.c
> --- kj/crypto/sha256.c~sparse-crypto_sha256 2005-03-18 20:05:34.0 
> +0100
> +++ kj-domen/crypto/sha256.c2005-03-18 20:05:34.0 +0100
> @@ -58,7 +58,7 @@ static inline u32 Maj(u32 x, u32 y, u32 
> 
> static inline void LOAD_OP(int I, u32 *W, const u8 *input)
> {
> -   W[I] = __be32_to_cpu( ((u32*)(input))[I] );
> +   W[I] = __be32_to_cpu( ((__be32*)(input))[I] );

I don't get any warnings here (sparse version dated 12/03/2005).
What warnings are you getting exactly?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch] cpusets policy kill no swap

[Paul Jackson]

Interesting comments, Andrew.  Thanks

It will likely be a couple of days before
I respond to them.  I suspect a couple
of us SGI folks should powwow first.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Patch] cpusets policy kill no swap

[Andrew Morton]

Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> This mechanisms differs from a general purpose out-of-memory
>  killer in various ways, including:
> 
>   * An oom-killer tries to score the bad buy, to avoid shooting
> the innocent little task that just happened to ask for one
> page too many.
>   * The policy_kill_no_swap hook kills the current requester.
>   * It takes severe memory pressure to wake up an oom-killer.
>   * The policy_kill_no_swap hook triggers on the slightest
> pressure that exceeds readily free memory.
>   * The oom-killer can be useful on a general purpose system.
>   * The policy_kill_no_swap hook is only useful for carefully
> tuned apps running on dedicated nodes on large systems.
> 

There are a lot of reasons why we would wake kswapd apart from starting
swapout.  Such as to reclaim clean pagecache or some dcache+icache.

>  In short - simple enough, but quite specialized.

Way too specialised, I suspect.  Is it not possible to have a little
userspace daemon which monitors the long-running applications's rss and
whacks it if the rss gets too large?

The patch you have simply kills the process when all the eligible zones
reach their upper watermark.  Again, we can probably determine that state
from userspace right now.  If not, it would be simple enough to add the
required info to /proc somewhere.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Error in ERR_PTR usage

[Yum Rayan]

Was trying to understand ERR_PTR and friends and surprisingly the
first 2 references via LXR seem to be erroneous. Did grep and found 1
additional incorrect reference "return ERR_PTR(0)" and another
"ERR_PTR(PTR_ERR(p))" usage. Please let me know if this patch is good.
If need be, I can chop it up for the individual maintainers, but it
would be nice if someone can comment first.

Thanks,
Rayan

Signed-off-by: Yum Rayan <[EMAIL PROTECTED]>

diff -Nur linux-2.6.11.5.orig/drivers/video/backlight/backlight.c
linux-2.6.11.5/drivers/video/backlight/backlight.c
--- linux-2.6.11.5.orig/drivers/video/backlight/backlight.c 2005-03-18
22:34:50.0 -0800
+++ linux-2.6.11.5/drivers/video/backlight/backlight.c  2005-03-19
22:21:45.058128838 -0800
@@ -174,7 +174,7 @@
 
new_bd = kmalloc(sizeof(struct backlight_device), GFP_KERNEL);
if (unlikely(!new_bd))
-   return ERR_PTR(ENOMEM);
+   return ERR_PTR(-ENOMEM);
 
init_MUTEX(&new_bd->sem);
new_bd->props = bp;
diff -Nur linux-2.6.11.5.orig/drivers/video/backlight/lcd.c
linux-2.6.11.5/drivers/video/backlight/lcd.c
--- linux-2.6.11.5.orig/drivers/video/backlight/lcd.c   2005-03-18
22:35:04.0 -0800
+++ linux-2.6.11.5/drivers/video/backlight/lcd.c2005-03-19
22:22:02.923823575 -0800
@@ -173,7 +173,7 @@
 
new_ld = kmalloc(sizeof(struct lcd_device), GFP_KERNEL);
if (unlikely(!new_ld))
-   return ERR_PTR(ENOMEM);
+   return ERR_PTR(-ENOMEM);
 
init_MUTEX(&new_ld->sem);
new_ld->props = lp;
diff -Nur linux-2.6.11.5.orig/fs/jfs/namei.c linux-2.6.11.5/fs/jfs/namei.c
--- linux-2.6.11.5.orig/fs/jfs/namei.c  2005-03-18 22:35:07.0 -0800
+++ linux-2.6.11.5/fs/jfs/namei.c   2005-03-19 22:26:52.156692285 -0800
@@ -1420,7 +1420,7 @@
free_UCSname(&key);
if (rc == -ENOENT) {
d_add(dentry, NULL);
-   return ERR_PTR(0);
+   return ERR_PTR(-ENOENT);
} else if (rc) {
jfs_err("jfs_lookup: dtSearch returned %d", rc);
return ERR_PTR(rc);
diff -Nur linux-2.6.11.5.orig/fs/reiserfs/xattr.c
linux-2.6.11.5/fs/reiserfs/xattr.c
--- linux-2.6.11.5.orig/fs/reiserfs/xattr.c 2005-03-18 22:35:04.0 
-0800
+++ linux-2.6.11.5/fs/reiserfs/xattr.c  2005-03-19 22:26:13.997480188 -0800
@@ -200,7 +200,7 @@
 
 xadir = open_xa_dir (inode, flags);
 if (IS_ERR (xadir)) {
-return ERR_PTR (PTR_ERR (xadir));
+return xadir;
 } else if (xadir && !xadir->d_inode) {
 dput (xadir);
 return ERR_PTR (-ENODATA);
@@ -209,7 +209,7 @@
 xafile = lookup_one_len (name, xadir, strlen (name));
 if (IS_ERR (xafile)) {
 dput (xadir);
-return ERR_PTR (PTR_ERR (xafile));
+return xafile;
 }
 
 if (xafile->d_inode) { /* file exists */
@@ -251,7 +251,7 @@
 
 xafile = get_xa_file_dentry (inode, name, flags);
 if (IS_ERR (xafile))
-return ERR_PTR (PTR_ERR (xafile));
+return xafile;
 else if (!xafile->d_inode) {
 dput (xafile);
 return ERR_PTR (-ENODATA);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Nasty ReiserFS bug in 2.6.12-rc1, 2.6.12-rc1-bk1

[Andrew Morton]

Bob Gill <[EMAIL PROTECTED]> wrote:
>
> Hi.  I have built 2.6.12-rc1 and 2.6.12-rc1-bk1.  There seems to be a
> nasty bug in ReiserFS (things are fine in 2.6.11.4).

Looks like the problem lies elsewhere.

>  The system wants
> to un-configure my SCSI Adaptec devices, and stall at "starting Hal
> daemon".

What does this mean?  Please provide (much) more detail.

> Mar 19 12:25:13 localhost kernel: EIP is at as_find_arq_hash+0x38/0x7d

At a guess I'd say that scsi did something horrid and tripped up the
anticipatory scheduler code.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dmesg verbosity [was Re: AGP bogosities]

[David Lang]

On Mon, 14 Mar 2005, Lee Revell wrote:
On Mon, 2005-03-14 at 19:12 +0100, Diego Calleja wrote:
Why should people look at all that "horrid" debug info everytime
they boot, except when they have a problem?
I'm really not trolling, but I suspect if we made the boot process less
verbose, people would start to wonder more about why Linux takes so much
longer than XP to boot.
two things
1. linux shouldn't take longer to boot then windows (and if properly 
configured it doesn't)

2. there's a _long_ way between the current situation where a driver can 
spew 500+ lines of logging and there being so little logging that people 
don't know what's going on.

if you are on a slow console (say a serial console) just letting the boot 
messages scroll by can take quite a while today.

David Lang
--
There are two ways of constructing a software design. One way is to make it so 
simple that there are obviously no deficiencies. And the other way is to make 
it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: race between __sync_single_inode() and iput()/bdev_clear_inode()

[Andrew Morton]

OGAWA Hirofumi <[EMAIL PROTECTED]> wrote:
>
> ...
> I got the above Oops while doing fs stress test.
> 
> The cause of this was race condition between __sync_single_inode() and
> iput()/bdev_clear_inode().
> 
> This race seems following condition.
> 
>   cpu0 (fs's inode) cpu1 (bdev's inode)
> 
>close("/dev/hda2")
>[...]
> __sync_single_inode()
>/* copy the bdev's ->i_mapping */
>mapping = inode->i_mapping;
> 
>generic_forget_inode()
>   bdev_clear_inode()
>/* restre the fs's ->i_mapping */
>inode->i_mapping = &inode->i_data;
> /* bdev's inode was freed */
>   destroy_inode(inode);
> 
>if (wait) {
>   /* dereference a freed bdev's mapping->host */
>   filemap_fdatawait(mapping);  /* Oops */
> 

The __sync_single_inode() caller takes a ref on the inode to prevent things
like this from happening.

What was the call path on the other process?  The one running
destroy_inode()?  unmount?

> I wrote the attached patch for making sure fs's inode is not in
> __sync_single_inode().

It would be nicer to honour the extra inode ref in the unmount path, if
poss.  Only swizzle i_mapping when the inode is really not in use.

> +/* Called under inode_lock. */
> +void wait_inode_ilock(struct inode *inode)
> +{
> + wait_queue_head_t *wqh;
> + DEFINE_WAIT_BIT(wq, &inode->i_state, __I_LOCK);
> +
> + if (!(inode->i_state & I_LOCK))
> + return;
> +
> + wqh = bit_waitqueue(&inode->i_state, __I_LOCK);
> + do {
> + __iget(inode);
> + spin_unlock(&inode_lock);
> + __wait_on_bit(wqh, &wq, inode_wait, TASK_UNINTERRUPTIBLE);
> + iput(inode);
> + spin_lock(&inode_lock);
> + } while (inode->i_state & I_LOCK);
> +}

Does this differ from wait_on_inode()?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Real-Time Preemption and RCU

[Manfred Spraul]

Ingo Molnar wrote:
which precise locking situation do you mean?
 

cpu 1:
acquire random networking spin_lock_bh()
cpu 2:
read_lock(&tasklist_lock) from process context
interrupt. softirq. within softirq: try to acquire the networking lock.
* spins.
cpu 1:
hardware interrupt
within hw interrupt: signal delivery. tries to acquire tasklist_lock.
--> deadlock.
--
   Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Build issue current MIPS - RaQ2

[Andrew Morton]

Jim Gifford <[EMAIL PROTECTED]> wrote:
>
>  I have not been able to build kernels since 2.6.9 on my RaQ2 for some 
>  time. I have tried the linux-mips.org port and the current 2.6.11.5 
>  release. I keep getting the same error.
> 
>Building modules, stage 2.
>MODPOST
>  *** Warning: "pci_iounmap" [drivers/net/tulip/tulip.ko] undefined!
>  *** Warning: "pci_iomap" [drivers/net/tulip/tulip.ko] undefined!

Does this fix it?

--- 25/arch/mips/lib/Makefile~mips-linkage-fix  2005-03-19 22:29:34.0 
-0800
+++ 25-akpm/arch/mips/lib/Makefile  2005-03-19 22:30:07.0 -0800
@@ -2,7 +2,9 @@
 # Makefile for MIPS-specific library files..
 #
 
-lib-y  += csum_partial_copy.o dec_and_lock.o iomap.o memcpy.o promlib.o \
+lib-y  += csum_partial_copy.o dec_and_lock.o memcpy.o promlib.o \
   strlen_user.o strncpy_user.o strnlen_user.o
 
+obj-y  += iomap.o
+
 EXTRA_AFLAGS := $(CFLAGS)
_

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Patch for iomap on MIPS was Re: Build issue current MIPS - RaQ2

[Jim Gifford]

Jim Gifford wrote:
I have not been able to build kernels since 2.6.9 on my RaQ2 for some 
time. I have tried the linux-mips.org port and the current 2.6.11.5 
release. I keep getting the same error.

 Building modules, stage 2.
 MODPOST
*** Warning: "pci_iounmap" [drivers/net/tulip/tulip.ko] undefined!
*** Warning: "pci_iomap" [drivers/net/tulip/tulip.ko] undefined!

I Finally figured it out, Here is a patch
diff -Naur linux-2.6.11/arch/mips/lib/Makefile 
linux-mips-2.6.11/arch/mips/lib/Makefile
--- linux-2.6.11/arch/mips/lib/Makefile 2005-03-01 23:37:48 -0800
+++ linux-mips-2.6.11/arch/mips/lib/Makefile2005-03-19 21:49:03 -0800
@@ -2,7 +2,10 @@
# Makefile for MIPS-specific library files..
#

-lib-y  += csum_partial_copy.o dec_and_lock.o iomap.o memcpy.o promlib.o \
+lib-y  += csum_partial_copy.o dec_and_lock.o memcpy.o promlib.o \
  strlen_user.o strncpy_user.o strnlen_user.o
+
+obj-y   += iomap.o
+
EXTRA_AFLAGS := $(CFLAGS)
--

Jim Gifford
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][0/6] Change proc file permissions with sysctls

[Albert Cahalan]

On Sun, 2005-03-20 at 01:22 +0100, Rene Scharfe wrote:

> The permissions of files in /proc/1 (usually belonging to init) are
> kept as they are.  The idea is to let system processes be freely
> visible by anyone, just as before.  Especially interesting in this
> regard would be instances of login.  I don't know how to easily
> discriminate between system processes and "normal" processes inside
> the kernel (apart from pid == 1 and uid == 0 (which is too broad)).
> Any ideas?

The ideal would be to allow viewing:

1. killable processes (that is, YOU can kill them)
2. processes sharing a tty with a killable process

Optionally, add:

3. processes controlling a tty master of a killable process
4. ancestors of all of the above
5. children of killable processes

This is of course expensive, but maybe you can get some of
it cheaply. For example, allow viewing a process if the session
leader, group leader, parent, or tpgid process is killable.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ppc64 build broke between 2.6.11-bk6 and 2.6.11-bk7

[Martin J. Bligh]

--Andrew Morton <[EMAIL PROTECTED]> wrote (on Thursday, March 17, 2005 22:44:09 
-0800):

> "Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
>> 
>> drivers/built-in.o(.text+0x182bc): In function `.matroxfb_probe':
>> : undefined reference to `.mac_vmode_to_var'
>> make: *** [.tmp_vmlinux1] Error 1
>> 
>> Anyone know what that is?
>> 
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm4/broken-out/fbdev-kconfig-fix-for-macmodes-and-ppc.patch
> 
> should fix it.

Great - tested, that fixed it up for me.

Thanks,

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Unreliable TCP?

[Valdis . Kletnieks]

On Sat, 19 Mar 2005 21:59:16 EST, Ioan Ionita said:

> applications which use the UDP protocol.  However, certain firewalls
> don't allow UDP traffic, therefore I tried UDP over TCP as a
> workaround.

That's the firewall's problem, not yours.  There's very few firewalls
that prohibit *all* UDP traffic (for starters, DNS becomes interesting).
Usually a firewall stops *most* UDP traffic only because the firewall admin
has decided that there's few UDP-based applications that they want to allow
through...

Explain why you think that your application will be let through the firewall
if it's TCP-based?  If the firewall admin thinks enough of your application to
open a port, it's equally likely to get you an open UDP port.

(For bonus points, work out the ethics of trying to circumvent a firewall that's
there for presumably good reasons - the people who installed the firewall did so
because they only want to allow certain traffic through.  Having the user
ask "Can I have port 99343 opened so application XYZ works?" is much more likely
to be useful *LONG-TERM* than getting into a long-term pissing match with the
firewall admin, who gets upset at your attempts to bypass his firewall and
starts playing whack-a-mole.  If you *do* get UDP-over-TCP working, you're
looking at having to move the port around all the time because it will get
blocked...)

> So I was wondering if
> there's any way to disable the whole reliability checking of TCP in
> the linux kernel. Maybe configure the kernel to never request the
> retransmission of a packet, even if it detects packet loss/bad order?

Yes, it's called UDP. :)



pgphopEXr8FV3.pgp
Description: PGP signature

Re: [PATCH 2.6.11.2][RFC] printk with anti-cluttering-feature

[Trond Myklebust]

su den 20.03.2005 Klokka 05:37 (+0100) skreiv Bodo Eggert:
> (I hope I avoided all spam-keywords this time, my previous mails didn't 
>  seem to make it)
> (please CC me on reply)
> 
> Issue:
> 
> On some conditions, the dmesg is spammed with repeated warnings about the
> same issue which is neither critical nor going to be fixed. This may
> result in losing the boot messages or missing other important messages.
> 
> Examples are:
> 
> nfs warning: mount version older than kernel
>  (my mount is newer than documented to be required)

Throw that one out, please. We have a more complete fix already queued
up on

http://client.linux-nfs.org/Linux-2.6.x/2.6.12-rc1/linux-2.6.12-02-kill_bad_mount_options.dif

Cheers,
  Trond

-- 
Trond Myklebust <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00

[Lee Revell]

On Sat, 2005-03-19 at 19:50 -0600, K.R. Foley wrote:
> Lee Revell wrote:
> > On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote:
> > 
> >>the biggest change in this patch is the merge of Paul E. McKenney's
> >>preemptable RCU code. The new RCU code is active on PREEMPT_RT. While it
> >>is still quite experimental at this stage, it allowed the removal of
> >>locking cruft (mainly in the networking code), so it could solve some of
> >>the longstanding netfilter/networking deadlocks/crashes reported by a
> >>number of people. Be careful nevertheless.
> > 
> > 
> > With PREEMPT_RT my machine deadlocked within 20 minutes of boot.
> > "apt-get dist-upgrade" seemed to trigger the crash.  I did not see any
> > Oops unfortunately.
> > 
> > Lee
> > 
> 
> Lee,
> 
> Just curious. Is this with UP or SMP? I currently have my UP box running 
>   PREEMPT_RT, with no problems thus far. However, my SMP box dies while 
> booting (with an oops). I am working on trying to get setup to capture 
> the oops, although it might be tomorrow before I get that done.
> 

UP.  It's 100% reproducible, this machine locks up over and over.  Seems
to be associated with network activity by multiple processes.

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2.6.11.2][RFC] printk with anti-cluttering-feature

[Bodo Eggert]

(I hope I avoided all spam-keywords this time, my previous mails didn't 
 seem to make it)
(please CC me on reply)

Issue:

On some conditions, the dmesg is spammed with repeated warnings about the
same issue which is neither critical nor going to be fixed. This may
result in losing the boot messages or missing other important messages.

Examples are:

nfs warning: mount version older than kernel
 (my mount is newer than documented to be required)

atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed.
 (I'm using a keyboard switch and a IBM PS/2 keyboard)

program smartd is using a deprecated SCSI ioctl, please convert it to SG_IO
 (I'll use the latest version as soon as I need to)



Rate-limiting these messages is won't help, since it would still allow
these messages to (slowly or in a burst) spam the log.

Printing these messages only once after booting might result in missing
important messages, especially on long-running systems (e.g. if my
keyboard really breaks after I have used the keyboard switch).


Suggested solution:

Instead, I decided to use a global flag with a semi-random magic number,
which will indicate the last printk being supposed to be limited, and to
reset this flag on each normal printk. By doing this, dmesg will not be
spammed, but the latest issue is displayed last.

(I suggest using the first value from "cksum file.c" as the magic number
unless there are thousands of printks to convert.)

The magic number depends on the CPU being able to read and write a
complete int at once *or* being lucky not to have a magic value that can
be constructed by combining some other magic numbers and printking with
exactly that magic number while the update happens. I can convert the
variable to an atomic type if it is a concern, but that would increase the
chances of a clash due to the 24 bit limit.

The patch increases the size of vmlinux by 141 bytes.
-- 
The programmer's National Anthem is '' diff -uprN linux-2.6.11/drivers/block/scsi_ioctl.c 
linux-2.6.11.new/drivers/block/scsi_ioctl.c
--- linux-2.6.11/drivers/block/scsi_ioctl.c 2005-03-03 15:41:28.0 
+0100
+++ linux-2.6.11.new/drivers/block/scsi_ioctl.c 2005-03-18 22:08:35.0 
+0100
@@ -547,7 +547,7 @@ int scsi_cmd_ioctl(struct file *file, st
 * old junk scsi send command ioctl
 */
case SCSI_IOCTL_SEND_COMMAND:
-   printk(KERN_WARNING "program %s is using a deprecated 
SCSI ioctl, please convert it to SG_IO\n", current->comm);
+   printk_nospam(2296159591, KERN_WARNING "program %s is 
using a deprecated SCSI ioctl, please convert it to SG_IO\n", current->comm);
err = -EINVAL;
if (!arg)
break;
diff -uprN linux-2.6.11/drivers/input/keyboard/atkbd.c 
linux-2.6.11.new/drivers/input/keyboard/atkbd.c
--- linux-2.6.11/drivers/input/keyboard/atkbd.c 2005-03-03 15:41:33.0 
+0100
+++ linux-2.6.11.new/drivers/input/keyboard/atkbd.c 2005-03-18 
22:45:42.0 +0100
@@ -320,7 +320,7 @@ static irqreturn_t atkbd_interrupt(struc
atkbd_report_key(&atkbd->dev, regs, KEY_HANJA, 3);
goto out;
case ATKBD_RET_ERR:
-   printk(KERN_DEBUG "atkbd.c: Keyboard on %s reports too 
many keys pressed.\n", serio->phys);
+   printk_nospam(2260620158, KERN_DEBUG "atkbd.c: Keyboard 
on %s reports too many keys pressed.\n", serio->phys);
goto out;
}
 
diff -uprN linux-2.6.11/fs/nfs/inode.c linux-2.6.11.new/fs/nfs/inode.c
--- linux-2.6.11/fs/nfs/inode.c 2005-03-03 15:41:59.0 +0100
+++ linux-2.6.11.new/fs/nfs/inode.c 2005-03-18 22:48:09.0 +0100
@@ -1386,7 +1386,7 @@ static struct super_block *nfs_get_sb(st
init_nfsv4_state(server);
 
if (data->version != NFS_MOUNT_VERSION) {
-   printk("nfs warning: mount version %s than kernel\n",
+   printk_nospam(1377481036, "nfs warning: mount version %s than 
kernel\n",
data->version < NFS_MOUNT_VERSION ? "older" : "newer");
if (data->version < 2)
data->namlen = 0;
diff -uprN linux-2.6.11/include/linux/kernel.h 
linux-2.6.11.new/include/linux/kernel.h
--- linux-2.6.11/include/linux/kernel.h 2005-03-03 15:42:13.0 +0100
+++ linux-2.6.11.new/include/linux/kernel.h 2005-03-18 22:06:42.0 
+0100
@@ -104,6 +104,10 @@ extern int session_of_pgrp(int pgrp);
 asmlinkage int vprintk(const char *fmt, va_list args);
 asmlinkage int printk(const char * fmt, ...)
__attribute__ ((format (printf, 1, 2)));
+asmlinkage int printk_nospam(int magic, const char * fmt, ...)
+   __attribute__ ((format (printf, 2, 3)));
+/* use a random value for the magic, e.g. the first value from
+   cksum on the file you're editing */
 
 unsigned long int_sqrt(unsign

Re: [PATCH][0/6] Change proc file permissions with sysctls

[Bodo Eggert]

On Sun, 20 Mar 2005, Rene Scharfe wrote:

> The permissions of files in /proc/1 (usually belonging to init) are
> kept as they are.  The idea is to let system processes be freely
> visible by anyone, just as before.  Especially interesting in this
> regard would be instances of login.

I think you mean login shells, the login process is just the thing asking
for the password agter the (m)ingetty got the username. These processes
are usurally created with the '-' sign in argv[0][0], but the users may
replace that string at will. I think it's still OK to depend on that if
you want a semi-secure system.

>  I don't know how to easily
> discriminate between system processes and "normal" processes inside
> the kernel (apart from pid

Do you mean ppid?

> == 1 and uid == 0 (which is too broad)).
> Any ideas?

This feature seems to be frequently requested. I don't remember the 
outcome, though.

>From a quick view, it seems the symlinks in /proc are empty for kernel 
threads and non-empty for user processes. Since you're messing with the 
proc entries, this could be a cheap way to find the kernel threads.
Another possibility is by looking at the blocked signals, signal 9 may not 
be blocked by mortals.

For the system daemons, you could additionally check for the absence of a 
controlling tty, but that's still no safe distinction from a process run 
by nohup. Checking for sid=pid will filter additional processes, but it 
the shell in midnight commander and screen are still false positives.
Checking for */sbin*/ in $PID/command will fail as soon as the daemon 
overwrites argv[0].

I don't think there is a relaible way to tell the system service daemons
from screen except for the name, and you'll want to detect screen-alike
programs, too.

-- 
Top 100 things you don't want the sysadmin to say:
40. The sprinkler system isn't supposed to leak is it?

Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

proposal

[julliets fish]

Dear friend,
I am lady of the Anglican communion Knight Hood.Am lady
julliet fish.I am the PRO and in charge of a trust fund
 put
together by a group of very wealthy christian business
 men
who over the years have donnated bountifully to
 orphanages,
less privilledged and victims of war.This group of
 friends
who operates as gospel philanthropic fund, wants thier
names to remain behind the scene, i am the public
 relation
officer.this organisation has been able to dinstinguish
itselves as remakable philanthropist in Africa, Asia
,america,and European countries.This is why am
 contacting
you, because i believe you  will understand and 
 be
interested in  the business.
I am going to add your name to the list as one of the
selected owners of private orphanage homes  so that you
shall from hence forth receive fund on monthly basis
 from
the Gospel philanthropic fund.from hence forth you shall
receive $10,000 on monthly basis,you shall take $2,000
 and
credit my a/c with $8,000.you must keep this between
 us.You
know you are going to be the ownner of a non existing
orphanage home. And am a respected lady internationally.
 I
must protect my good name. On your agreement to involve
 in
this monthly benefit,get back to me so that i add your
 name
to the selected owners of orphanage home,which will
 benefit
 from this monthly charity.And our new office in canada
 is
charge with the responsibility of disseminating cashier
checks to the selected owners of orphanage homes will
 make
sure you receive one to the tone of $10,000 monthly to
 run
your supposed orphanage homes. $2,000 for you and you
credit my a/c with $8,000.IS IT A DEAL?
Get back to me
lady julliet fish P.R.O
GOSPEL PHILANTHROPIC
FUND
LONDON, ENGLAND
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

proposal

[julliets fish]

Dear friend,
I am lady of the Anglican communion Knight Hood.Am lady
julliet fish.I am the PRO and in charge of a trust fund
 put
together by a group of very wealthy christian business
 men
who over the years have donnated bountifully to
 orphanages,
less privilledged and victims of war.This group of
 friends
who operates as gospel philanthropic fund, wants thier
names to remain behind the scene, i am the public
 relation
officer.this organisation has been able to dinstinguish
itselves as remakable philanthropist in Africa, Asia
,america,and European countries.This is why am
 contacting
you, because i believe you  will understand and 
 be
interested in  the business.
I am going to add your name to the list as one of the
selected owners of private orphanage homes  so that you
shall from hence forth receive fund on monthly basis
 from
the Gospel philanthropic fund.from hence forth you shall
receive $10,000 on monthly basis,you shall take $2,000
 and
credit my a/c with $8,000.you must keep this between
 us.You
know you are going to be the ownner of a non existing
orphanage home. And am a respected lady internationally.
 I
must protect my good name. On your agreement to involve
 in
this monthly benefit,get back to me so that i add your
 name
to the selected owners of orphanage home,which will
 benefit
 from this monthly charity.And our new office in canada
 is
charge with the responsibility of disseminating cashier
checks to the selected owners of orphanage homes will
 make
sure you receive one to the tone of $10,000 monthly to
 run
your supposed orphanage homes. $2,000 for you and you
credit my a/c with $8,000.IS IT A DEAL?
Get back to me
lady julliet fish P.R.O
GOSPEL PHILANTHROPIC
FUND
LONDON, ENGLAND
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Relayfs question

[Karim Yaghmour]

Jan Engelhardt wrote:
> Well, what about things like urandom? It also moves "a lot" of data and does
> nothing else.

Forgive my slowness today, but I don't get the angle here:
- Relayfs is not a replacement for char devices, we've never claimed it
  to be.
- Urandom generates a lot of data, and uses copy_to_user() to get it to
  user-space, but it isn't a generalized buffering mechanism for
  transfering large amounts of data to user-space.

If what you're inquiring about is a comparison between relayfs'
mechanisms and the underlying mechanisms that urandom is using, then
I don't think there can be a comparison: the goals are different.

For example, urandom relies on a global spin lock and uses copy_to_user()
for its transfers. This is just fine for this type of application. If
you wanted to transfer a huge amount of data from the kernel to user-
space (the kind of data generated by tracing facilities, for example),
however, these mechanisms would be simply inadequate. If we're generating
the amount of data LTT can gather, for example, (say 2MB/s as was
described in the earlier thread regarding relayfs), then you need per-cpu
buffering and you need to not write anything back to user-space, but
dump it to disk ASAP, etc. This is where relayfs comes in handy.

On the other hand, using relayfs to replace what urandom currently uses
is just the wrong thing to do. If nothing else, /dev/urandom would
behave entirely differently (API, dynamics, etc.). There would also be
no clear added benefit for using relayfs.

What character drivers do (mainly copy_to_user()) and what relayfs is
used for are entirely different. To use a slightly exagerated example
to illustrate the difference: replacing the standard mechanisms drivers
use to transfer data to user-space with relayfs would be like renting
a supersonic jet to get your package to a foreign country instead of
just using Fedex. It works ... but it's clearly the wrong approach.

Please read relayfs.txt.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] rename FPU_*verify_area to FPU_*access_ok

[Jesper Juhl]

Since verify_area is going the way of the Dodo soon it seems resonable to 
no longer refer to it in wrapper functions/macros.
FPU_verify_area and FPU_code_verify_area have already been converted to 
call access_ok so now seems a good time to rename them.
This patch makes no functional changes at all.


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>

diff -uprN linux-2.6.11-mm4-orig/arch/i386/math-emu/fpu_entry.c 
linux-2.6.11-mm4/arch/i386/math-emu/fpu_entry.c
--- linux-2.6.11-mm4-orig/arch/i386/math-emu/fpu_entry.c2005-03-02 
08:38:25.0 +0100
+++ linux-2.6.11-mm4/arch/i386/math-emu/fpu_entry.c 2005-03-20 
03:57:21.0 +0100
@@ -257,7 +257,7 @@ do_another_FPU_instruction:
 }
 
   RE_ENTRANT_CHECK_OFF;
-  FPU_code_verify_area(1);
+  FPU_code_access_ok(1);
   FPU_get_user(FPU_modrm, (u_char __user *) FPU_EIP);
   RE_ENTRANT_CHECK_ON;
   FPU_EIP++;
@@ -589,7 +589,7 @@ static int valid_prefix(u_char *Byte, u_
   *override = (overrides) { 0, 0, PREFIX_DEFAULT };   /* defaults */
 
   RE_ENTRANT_CHECK_OFF;
-  FPU_code_verify_area(1);
+  FPU_code_access_ok(1);
   FPU_get_user(byte, ip);
   RE_ENTRANT_CHECK_ON;
 
@@ -635,7 +635,7 @@ static int valid_prefix(u_char *Byte, u_
do_next_byte:
  ip++;
  RE_ENTRANT_CHECK_OFF;
- FPU_code_verify_area(1);
+ FPU_code_access_ok(1);
  FPU_get_user(byte, ip);
  RE_ENTRANT_CHECK_ON;
  break;
@@ -686,7 +686,7 @@ int restore_i387_soft(void *s387, struct
   int offset, other, i, tags, regnr, tag, newtop;
 
   RE_ENTRANT_CHECK_OFF;
-  FPU_verify_area(VERIFY_READ, d, 7*4 + 8*10);
+  FPU_access_ok(VERIFY_READ, d, 7*4 + 8*10);
   if (__copy_from_user(&S387->cwd, d, 7*4))
 return -1;
   RE_ENTRANT_CHECK_ON;
@@ -732,7 +732,7 @@ int save_i387_soft(void *s387, struct _f
   int offset = (S387->ftop & 7) * 10, other = 80 - offset;
 
   RE_ENTRANT_CHECK_OFF;
-  FPU_verify_area(VERIFY_WRITE, d, 7*4 + 8*10);
+  FPU_access_ok(VERIFY_WRITE, d, 7*4 + 8*10);
 #ifdef PECULIAR_486
   S387->cwd &= ~0xe080;
   /* An 80486 sets nearly all of the reserved bits to 1. */
diff -uprN linux-2.6.11-mm4-orig/arch/i386/math-emu/fpu_system.h 
linux-2.6.11-mm4/arch/i386/math-emu/fpu_system.h
--- linux-2.6.11-mm4-orig/arch/i386/math-emu/fpu_system.h   2005-03-16 
15:45:03.0 +0100
+++ linux-2.6.11-mm4/arch/i386/math-emu/fpu_system.h2005-03-20 
03:56:09.0 +0100
@@ -66,7 +66,7 @@
 #define instruction_address(*(struct address *)&I387.soft.fip)
 #define operand_address(*(struct address *)&I387.soft.foo)
 
-#define FPU_verify_area(x,y,z) if ( !access_ok(x,y,z) ) \
+#define FPU_access_ok(x,y,z)   if ( !access_ok(x,y,z) ) \
math_abort(FPU_info,SIGSEGV)
 
 #undef FPU_IGNORE_CODE_SEGV
@@ -75,12 +75,12 @@
about 20% slower if applied to the code. Anyway, errors due to bad
code addresses should be much rarer than errors due to bad data
addresses. */
-#defineFPU_code_verify_area(z)
+#defineFPU_code_access_ok(z)
 #else
 /* A simpler test than access_ok() can probably be done for
-   FPU_code_verify_area() because the only possible error is to step
+   FPU_code_access_ok() because the only possible error is to step
past the upper boundary of a legal code area. */
-#defineFPU_code_verify_area(z) FPU_verify_area(VERIFY_READ,(void 
__user *)FPU_EIP,z)
+#defineFPU_code_access_ok(z) FPU_access_ok(VERIFY_READ,(void __user 
*)FPU_EIP,z)
 #endif
 
 #define FPU_get_user(x,y)   get_user((x),(y))
diff -uprN linux-2.6.11-mm4-orig/arch/i386/math-emu/get_address.c 
linux-2.6.11-mm4/arch/i386/math-emu/get_address.c
--- linux-2.6.11-mm4-orig/arch/i386/math-emu/get_address.c  2005-03-02 
08:38:32.0 +0100
+++ linux-2.6.11-mm4/arch/i386/math-emu/get_address.c   2005-03-20 
03:58:29.0 +0100
@@ -81,7 +81,7 @@ static int sib(int mod, unsigned long *f
   long offset;
 
   RE_ENTRANT_CHECK_OFF;
-  FPU_code_verify_area(1);
+  FPU_code_access_ok(1);
   FPU_get_user(base, (u_char __user *) (*fpu_eip));   /* The SIB byte */
   RE_ENTRANT_CHECK_ON;
   (*fpu_eip)++;
@@ -111,7 +111,7 @@ static int sib(int mod, unsigned long *f
   /* 8 bit signed displacement */
   long displacement;
   RE_ENTRANT_CHECK_OFF;
-  FPU_code_verify_area(1);
+  FPU_code_access_ok(1);
   FPU_get_user(displacement, (signed char __user *) (*fpu_eip));
   offset += displacement;
   RE_ENTRANT_CHECK_ON;
@@ -122,7 +122,7 @@ static int sib(int mod, unsigned long *f
   /* 32 bit displacement */
   long displacement;
   RE_ENTRANT_CHECK_OFF;
-  FPU_code_verify_area(4);
+  FPU_code_access_ok(4);
   FPU_get_user(displacement, (long __user *) (*fpu_eip));
   offset += displacement;
   RE_ENTRANT_CHECK_ON;
@@ -276,7 +276,7 @@ void __user *FPU_get_address(u_char FPU_
{
  /* Special case: disp32 */
  RE_ENTRANT_CHECK_OFF;
- FPU_code_verify_area

Re: 2.6.12-rc1 breaks dosemu

[Gene Heskett]

On Saturday 19 March 2005 21:11, Adrian Bunk wrote:
>xdosemu 1.2.2 runs fine under 2.6.11.5, but fails under 2.6.12-rc1
> with the following error:
>
I just tried it here, and its ok while running 2.6.12-rc1

><--  snip  -->
>
>$ xdosemu
>ERROR: cpu exception in dosemu code outside of VM86()!
>trapno: 0x0e  errorcode: 0x0005  cr2: 0xff8e
>eip: 0x69ee  esp: 0xbfdbffcc  eflags: 0x00010246
>cs: 0x0073  ds: 0x007b  es: 0x007b  ss: 0x007b
>Page fault: read instruction to linear address: 0xff8e
>CPU was in user mode
>Exception was caused by insufficient privilege
>
><--  snip  -->
>
>cu
>Adrian

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Unreliable TCP?

[Ioan Ionita]

Hello.  I apologize if this may sound stupid/unknowledgeable.  I'm
currently fooling around with real time voice conferencing
applications which use the UDP protocol.  However, certain firewalls
don't allow UDP traffic, therefore I tried UDP over TCP as a
workaround.  This failed miserably, as the ACK aspect of TCP, which
delays everything when a packet is lost or received out of order makes
voice conferencing anything but real time.  So I was wondering if
there's any way to disable the whole reliability checking of TCP in
the linux kernel. Maybe configure the kernel to never request the
retransmission of a packet, even if it detects packet loss/bad order?
Thanks :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] _raw_read_trylock for alpha

[Richard Henderson]

On Sat, Mar 19, 2005 at 03:39:33PM -0500, Jeff Garzik wrote:
> Don't send this patch upstream until its been verified to actually work.

It certainly won't.  I'll gen up something soon.


r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

SMP boot failure, Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00

[Cal]

Not subscribed, so please forgive the unthreaded post.
As per K.R. Foley's report, booting on SMP fails. I tried & failed to 
capture the boot messages via serial, so the best I can offer is a pic 
of what remained visible on screen at the death.

I suspect there was more prior to that, but so far that's the best I can 
offer.

Booting with maxcpus=1 didn't fail completely, but also suffered dramas. 
Loss of usb mouse was the most noticable. If that scenario might be 
interesting or helpful, I'll pursue it further.

cheers, Cal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] remove redundant NULL checks before kfree() in sound/ and avoid casting pointers about to be kfree()'ed

[Jesper Juhl]

Checking a pointer for NULL before calling kfree() on it is redundant,
kfree() deals with NULL pointers just fine.
This patch removes such checks from sound/

This patch also makes another, but closely related, change.
It avoids casting pointers about to be kfree()'ed
 like this for example :
   static void snd_ymfpci_pcm_free_substream(snd_pcm_runtime_t *runtime)
   {
  ymfpci_pcm_t *ypcm = runtime->private_data;
   
  kfree(ypcm);
  kfree(runtime->private_data);
   }
There's no reason for this, we can just as well simply 
kfree(runtime->private_data); and save the creation of a local variable 
and an assignment/cast. Where such code was found that change was made.

Since these are fairly trivial changes (and the same changes are made
everywhere) I've just made a single patch for all modified files and CC
all authors/maintainers of those files I could find.
If spliting this into one patch pr file is prefered, then I can easily do 
that as well.

I don't have access to all these soundcards, so the patch is only compile 
tested, but it should be simple enough to verify by visual inspection that 
these changes are correct.

These files are modified by this patch : 
sound/core/seq/oss/seq_oss_synth.c
sound/core/seq/seq_dummy.c
sound/core/timer.c
sound/drivers/vx/vx_pcm.c
sound/i2c/tea6330t.c
sound/isa/gus/gus_pcm.c
sound/oss/ad1848.c
sound/oss/ad1889.c
sound/oss/dmasound/dmasound_awacs.c
sound/oss/emu10k1/midi.c
sound/oss/emu10k1/passthrough.c
sound/oss/maestro.c
sound/oss/mpu401.c
sound/oss/sb_common.c
sound/pci/ca0106/ca0106_main.c
sound/pci/cs46xx/cs46xx_lib.c
sound/pci/emu10k1/emu10k1x.c
sound/pci/emu10k1/emupcm.c
sound/pci/via82xx.c
sound/pci/via82xx_modem.c
sound/pci/ymfpci/ymfpci_main.c
sound/pcmcia/vx/vx_entry.c
sound/synth/emux/emux_effect.c
sound/usb/usbaudio.c
sound/usb/usbmixer.c
sound/usb/usx2y/usbusx2yaudio.c

(Please keep me on CC if you reply since I'm not subscribed to all the 
lists being CC'ed)


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>

--- linux-2.6.11-mm4-orig/sound/core/seq/oss/seq_oss_synth.c2005-03-16 
15:45:42.0 +0100
+++ linux-2.6.11-mm4/sound/core/seq/oss/seq_oss_synth.c 2005-03-20 
01:23:26.0 +0100
@@ -325,14 +325,10 @@ snd_seq_oss_synth_cleanup(seq_oss_devinf
}
snd_use_lock_free(&rec->use_lock);
}
-   if (info->sysex) {
-   kfree(info->sysex);
-   info->sysex = NULL;
-   }
-   if (info->ch) {
-   kfree(info->ch);
-   info->ch = NULL;
-   }
+   kfree(info->sysex);
+   info->sysex = NULL;
+   kfree(info->ch);
+   info->ch = NULL;
}
dp->synth_opened = 0;
dp->max_synthdev = 0;
@@ -418,14 +414,10 @@ snd_seq_oss_synth_reset(seq_oss_devinfo_
  dp->file_mode) < 0) {
midi_synth_dev.opened--;
info->opened = 0;
-   if (info->sysex) {
-   kfree(info->sysex);
-   info->sysex = NULL;
-   }
-   if (info->ch) {
-   kfree(info->ch);
-   info->ch = NULL;
-   }
+   kfree(info->sysex);
+   info->sysex = NULL;
+   kfree(info->ch);
+   info->ch = NULL;
}
return;
}
--- linux-2.6.11-mm4-orig/sound/core/seq/seq_dummy.c2005-03-16 
15:45:42.0 +0100
+++ linux-2.6.11-mm4/sound/core/seq/seq_dummy.c 2005-03-20 01:37:35.0 
+0100
@@ -140,10 +140,7 @@ dummy_input(snd_seq_event_t *ev, int dir
 static void
 dummy_free(void *private_data)
 {
-   snd_seq_dummy_port_t *p;
-
-   p = private_data;
-   kfree(p);
+   kfree(private_data);
 }
 
 /*
--- linux-2.6.11-mm4-orig/sound/core/timer.c2005-03-16 15:45:42.0 
+0100
+++ linux-2.6.11-mm4/sound/core/timer.c 2005-03-20 01:30:43.0 +0100
@@ -1456,14 +1456,10 @@ static int snd_timer_user_tselect(struct
if ((err = snd_timer_open(&tu->timeri, str, &tselect.id, current->pid)) 
< 0)
return err;
 
-   if (tu->queue) {
-   kfree(tu->queue);
-   tu->queue = NULL;
-   }
-   if (tu->tqueue) {
-   kfree(tu->tqueue);
-   tu->tqueue = NULL;
-   }
+   kfree(tu->queue);
+   tu->queue = NULL;
+   kfree(tu->tqueue);
+   tu->tqueue = NULL;
if (tu->tread) {
tu->tqueue = (snd_timer_tread_t *)kmalloc(tu->queue

2.6.12-rc1 breaks dosemu

[Adrian Bunk]

xdosemu 1.2.2 runs fine under 2.6.11.5, but fails under 2.6.12-rc1 with 
the following error:

<--  snip  -->

$ xdosemu 
ERROR: cpu exception in dosemu code outside of VM86()!
trapno: 0x0e  errorcode: 0x0005  cr2: 0xff8e
eip: 0x69ee  esp: 0xbfdbffcc  eflags: 0x00010246
cs: 0x0073  ds: 0x007b  es: 0x007b  ss: 0x007b
Page fault: read instruction to linear address: 0xff8e
CPU was in user mode
Exception was caused by insufficient privilege

<--  snip  -->

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [CHECKER] crash after fsync causing serious FS corruptions (ext2, 2.6.11)

[Bernd Eckenfels]

Hello Ted,

In article <[EMAIL PROTECTED]> you wrote:
> Should we fix it today?  Given that we have ext3, I'd probably answer
> no.  It's a known property of ext2; we've lived with it for over ten
> years, and to add this would just slow down ext2 (which gets used
> often as benchmark standard to aspire to), and make the ext2 codebase
> more complicated.

I am not too deep into FS design, however I have heared from some admins of
a pretty busy server, that the allocation method of placinf file content
close to the directories cause a lot of fragmentation there. So I wonder if
an simple change in allocation policy could lower the problems with the
fragmentation and (especially) lower the chance of blocks beeing reused too
often.

I might be able to get  the patch, however I am not sure if it will solves
or lowers the problem the checker group found.

The performance impact of such a changed allocation policy is, however on
the given system positive (due to decreased fragmentation).

BTW: I was not directly involved here in the decision process which FS to
use, however I am sure it is both related to performance and recoverability.
Because all recent (journalling) filesystems XFS, Reiser and ext3 very often
failed with big data loss in that environment, whereas ext2 could most often
be recovered very well. So from my point of you ext2 should not be
desupported.
 
Greetings
Bernd

PS: i have a before/after screenshot of the filesystem in this german
article. It is a pop3 server:
http://itblog.eckenfels.net/archives/8-Fragmentierung.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Patch] cpusets policy kill no swap

[Paul Jackson]

Question:

Should I call oom_kill_process(), oom_kill_task(),
or __oom_kill_task(), when the current task decides
that it is better to die than to swap, so calls the
routine mm/oom_kill.c:oom_attempt_suicide() that this
patch adds, below?

My best guess is either one of oom_kill_task() or
__oom_kill_task() is fine, depending on whether I
want to take down the rest of the tasks sharing the
offending tasks mm.

Andrew will probably not want to pick up this patch, at least
until this question is answered.

Review and feedback is welcome.

===

This patch adds a boolean flag 'policy_kill_no_swap' to each
cpuset.  If this flag is set in some cpuset, and if a task
attached to that cpuset tries to allocate a page of memory and
gets far enough in the __alloc_pages() code that the _next_
step would be to wake the swapper (call wakeup_kswapd) then
instead of that, the task is killed immediately.

For normal desktop usage, this makes almost no sense, and so
of course the default setting of 'policy_kill_no_swap' is false
(zero).

For certain HPC apps on big iron numa, this policy has been found
to be essential.  In these cases, the app has been carefully
sized to fit, tightly, on the CPUs and Memory Nodes allowed
to it.  The app may consume dozens or hundreds of nodes, using
up almost all the main memory on each node, running for hours
or days in very tight coupling.  Such an app as would use
policy_kill_no_swap must not swap, for two reasons:

 1) If it starts to swap, then the required performance is
hopelessly and totally lost.  The customer requires the
application to come down at that point.

 2) If it starts to swap, it starts to impact the performance
of other apps elsewhere on the system.  This was much worse
on Linux 2.4 kernels, where the swapper was not well behaved.
But even on Linux 2.6 kernels, additional i/o and kernel
work is invoked, which has unpredictable impact on the
remaining system performance.

The implementation is simple enough.  Each cpuset directory has
one more special file, 'policy_kill_no_swap', containing a zero
(false) or one (true).  The default is false.  The value is
inherited by newly created sub-cpusets.

A hook is added to mm/page_alloc.c:__alloc_pages(), just before
the wakeup_kswapd() logic, which checks this flag in the current
tasks cpuset, and kills the process if the flag is set, with
an explanatory printk.  A new routine, oom_attempt_suicide(),
is added to mm/oom_kill.c, to handle the killing.  If this
happens, the task never gets to the point of invoking the
swapper.

This mechanisms differs from a general purpose out-of-memory
killer in various ways, including:

 * An oom-killer tries to score the bad buy, to avoid shooting
   the innocent little task that just happened to ask for one
   page too many.
 * The policy_kill_no_swap hook kills the current requester.
 * It takes severe memory pressure to wake up an oom-killer.
 * The policy_kill_no_swap hook triggers on the slightest
   pressure that exceeds readily free memory.
 * The oom-killer can be useful on a general purpose system.
 * The policy_kill_no_swap hook is only useful for carefully
   tuned apps running on dedicated nodes on large systems.

In short - simple enough, but quite specialized.

This patch has been built, booted and tested for function on
an ia64 SN2 platform.  It has been built with and without
CONFIG_CPUSETS enabled on an i386 platform.

It would not surprise me if a few more such cpuset policy flags
showed up over the next year, to affect scheduling or allocation
for all tasks in a cpuset.  However I have no more such flags
queued up, or even with an agreed design, at this time.

Signed-off-by: Paul Jackson <[EMAIL PROTECTED]>

Index: 2.6.12-pj/Documentation/cpusets.txt
===
--- 2.6.12-pj.orig/Documentation/cpusets.txt2005-03-19 01:10:46.0 
-0800
+++ 2.6.12-pj/Documentation/cpusets.txt 2005-03-19 14:41:21.0 -0800
@@ -166,6 +166,7 @@ containing the following files describin
  - mems: list of Memory Nodes in that cpuset
  - cpu_exclusive flag: is cpu placement exclusive?
  - mem_exclusive flag: is memory placement exclusive?
+ - policy_kill_no_swap: kill task if its memory use would wake swapper
  - tasks: list of tasks (by pid) attached to that cpuset
 
 New cpusets are created using the mkdir system call or shell
@@ -333,7 +334,7 @@ Now you want to do something with this c
 
 In this directory you can find several files:
 # ls
-cpus  cpu_exclusive  mems  mem_exclusive  tasks
+cpu_exclusive  cpus  mem_exclusive  mems  policy_kill_no_swap  tasks
 
 Reading them will give you information about the state of this cpuset:
 the CPUs and Memory Nodes it can use, the processes that are using
Index: 2.6.12-pj/include/linux/cpuset.h
===
--- 2.6.12-pj.orig/include/

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00

[K.R. Foley]

Lee Revell wrote:
On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote:
the biggest change in this patch is the merge of Paul E. McKenney's
preemptable RCU code. The new RCU code is active on PREEMPT_RT. While it
is still quite experimental at this stage, it allowed the removal of
locking cruft (mainly in the networking code), so it could solve some of
the longstanding netfilter/networking deadlocks/crashes reported by a
number of people. Be careful nevertheless.

With PREEMPT_RT my machine deadlocked within 20 minutes of boot.
"apt-get dist-upgrade" seemed to trigger the crash.  I did not see any
Oops unfortunately.
Lee
Lee,
Just curious. Is this with UP or SMP? I currently have my UP box running 
 PREEMPT_RT, with no problems thus far. However, my SMP box dies while 
booting (with an oops). I am working on trying to get setup to capture 
the oops, although it might be tomorrow before I get that done.

--
   kr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00

[Lee Revell]

On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote:
> the biggest change in this patch is the merge of Paul E. McKenney's
> preemptable RCU code. The new RCU code is active on PREEMPT_RT. While it
> is still quite experimental at this stage, it allowed the removal of
> locking cruft (mainly in the networking code), so it could solve some of
> the longstanding netfilter/networking deadlocks/crashes reported by a
> number of people. Be careful nevertheless.

With PREEMPT_RT my machine deadlocked within 20 minutes of boot.
"apt-get dist-upgrade" seemed to trigger the crash.  I did not see any
Oops unfortunately.

Lee



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 1/4] security/selinux/ss/policydb.c: fix sparse warnings

[James Morris]

On Sat, 19 Mar 2005 [EMAIL PROTECTED] wrote:

>  kj-domen/security/selinux/ss/policydb.c |   35 
> ++--
>  1 files changed, 20 insertions(+), 15 deletions(-)

Have you tested these changes?


- James
-- 
James Morris
<[EMAIL PROTECTED]>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

SATA VIA8237 Problems (Install)

[Jay Roplekar]

I have a KT600 based motherboard & I am planning to set up my new system using 
that.  It has onboard via 8237 sata {raid, cough cough} controller. I am 
planning to use a single sata disk (I am not interested in raid).   The 
various distro installers are having tough time noticing a brand new western 
digital disk.  Following is the dmesg from the installer :

##
libata version 1.10 loaded.
sata_via version 1.1
ACPI: PCI interrupt :00:0f.0[B] -> GSI 11 (level, low) -> IRQ 11
sata_via(:00:0f.0): routed to hard irq line 11
ata1: SATA max UDMA/133 cmd 0xB000 ctl 0xB402 bmdma 0xC000 irq 11
ata2: SATA max UDMA/133 cmd 0xB800 ctl 0xBC02 bmdma 0xC008 irq 11
ata1: dev 0 cfg 49:3030 82:0078 83:0078 84: 85: 86:3fff 87:0010 
88:000f
ata1: no dma/lba
ata1: dev 0 not supported, ignoring
scsi0 : sata_via
ata2: no device found (phy stat )
scsi1 : sata_via
###

Is the line  "ata1: dev 0 not supported, ignoring" expected?Is there 
something basic I am missing. I would appreciate any help.  
I have tried to digest info on Jeff Garzik's linux.yyz.us/sata/  and also 
www.linuxmafia.com/faq/Hardware/sata.html  but its quite possible I might 
have misinterpreted it.  FWIW,  the installer is 2.6.11-1 based  and  
following modules are present in the system. Thanks,

Jay 


odule  Size  Used byNot tainted
parport_pc 28805 0 - Live 0xd0a1c000
parport 39689 1 parport_pc, Live 0xd09d5000
dm_snapshot 17797 0 - Live 0xd097a000
dm_mirror 25389 0 - Live 0xd0998000
dm_zero 2497 0 - Live 0xd081b000
dm_mod 61013 3 dm_snapshot,dm_mirror,dm_zero, Live 0xd0a25000
xfs 586897 0 - Live 0xd0c0f000
exportfs 8513 1 xfs, Live 0xd0902000
jfs 203897 0 - Live 0xd0ae9000
reiserfs 267317 0 - Live 0xd0aa6000
ext3 133065 0 - Live 0xd0a39000
jbd 79065 1 ext3, Live 0xd09fc000
msdos 8641 0 - Live 0xd0906000
raid6 107345 0 - Live 0xd09e
raid5 28737 0 - Live 0xd098f000
xor 15305 2 raid6,raid5, Live 0xd0939000
raid1 21441 0 - Live 0xd08ab000
raid0 8513 0 - Live 0xd08fe000
sata_via 8389 0 - Live 0xd08d
libata 47429 1 sata_via, Live 0xd0982000
via_rhine 27209 0 - Live 0xd0931000
mii 4929 1 via_rhine, Live 0xd0894000
uhci_hcd 33497 0 - Live 0xd090a000
ehci_hcd 39245 0 - Live 0xd0926000
sr_mod 19173 0 - Live 0xd08ca000
sd_mod 19137 0 - Live 0xd08b2000
scsi_mod 138665 3 libata,sr_mod,sd_mod, Live 0xd09a
edd 9889 0 - Live 0xd089
floppy 63729 0 - Live 0xd0915000
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Mail from batman

[batman cole]

Attn sir,

I am Mr. Batman cole the manager of ITT bank, Mr Haryanto Tomo from 
indonesia deposited the sum of U$10million in our bank, right now he is 
one of the viticms of the tsunami in asia that kill thousands.

Sir, if you are willing to receive this money in your account as his 
next of kin call me on +23480 33127410 or email me on: 
[EMAIL PROTECTED] the sharing of the money between you and I 
will not be the problem.

Thanks
Batman Cole



__
Try Yopolis Mail for free!
Sign up for your free Web-Based or POP3 email account with 50MB of space.
No Ads, No Pop-Ups, No Banners, More Space
Go to http://www.yopolis.com then click on the Webmail link!
Enjoy other features such as Auto Responders, Mail Forwarding, Aliases plus 
more.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] arch hook for notifying changes in PTE protections bits

[David S. Miller]

On Sat, 19 Mar 2005 12:30:05 -0800
David Mosberger <[EMAIL PROTECTED]> wrote:

> I agree about your concern about cost.  Accessing the page_map is
> expensive (integer division + memory access) and we have to do that in
> order to find out if the page is i-cache clean.

First, it's a multiply by reciprocol.  At least on sparc64 I get
this emitted by the compiler.

Secondly, if you're willing to sacrifice 8 bytes per page struct
simply define WANT_PAGE_VIRTUAL and page struct will be exactly
64 bytes and thus the divide a will turn into a simple shift.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: swsusp: Remove arch-specific references from generic code

[Rafael J. Wysocki]

Hi,

On Saturday, 19 of March 2005 23:07, Pavel Machek wrote:
> Hi!
> 
> Do you think you could just send me diff between 2.6.12-rc1 and your
> tree? I'll merge it here.

Sure, no problem, the diff follows. :-)  It contains the following changes:

- remove swsusp_restore() (with the fix to return 0 from swsusp_arch_resume() 
on x86*)
- drop SUSPEND_PD_PAGES and pagedir_order
- fix possible memory leaks in swsusp_suspend()

The original patches are also attached in case you need them (they all apply to
2.6.12-rc1).

Please let me know if that's ok.

Greets,
Rafael


diff -Nrup linux-2.6.12-rc1/arch/i386/power/swsusp.S 
linux-2.6.12-rc1-new/arch/i386/power/swsusp.S
--- linux-2.6.12-rc1/arch/i386/power/swsusp.S   2005-03-20 00:36:44.0 
+0100
+++ linux-2.6.12-rc1-new/arch/i386/power/swsusp.S   2005-03-20 
00:38:13.0 +0100
@@ -51,6 +51,15 @@ copy_loop:
.p2align 4,,7
 
 done:
+   /* Flush TLB, including "global" things (vmalloc) */
+   movlmmu_cr4_features, %eax
+   movl%eax, %edx
+   andl$~(1<<7), %edx;  # PGE
+   movl%edx, %cr4;  # turn off PGE
+   movl%cr3, %ecx;  # flush TLB
+   movl%ecx, %cr3
+   movl%eax, %cr4;  # turn PGE back on
+
movl saved_context_esp, %esp
movl saved_context_ebp, %ebp
movl saved_context_ebx, %ebx
@@ -58,5 +67,7 @@ done:
movl saved_context_edi, %edi
 
pushl saved_context_eflags ; popfl
-   call swsusp_restore
+
+   xorl%eax, %eax
+
ret
diff -Nrup linux-2.6.12-rc1/arch/x86_64/kernel/suspend_asm.S 
linux-2.6.12-rc1-new/arch/x86_64/kernel/suspend_asm.S
--- linux-2.6.12-rc1/arch/x86_64/kernel/suspend_asm.S   2005-03-20 
00:36:45.0 +0100
+++ linux-2.6.12-rc1-new/arch/x86_64/kernel/suspend_asm.S   2005-03-20 
00:38:14.0 +0100
@@ -69,12 +69,21 @@ loop:
movqpbe_next(%rdx), %rdx
jmp loop
 done:
+   /* Flush TLB, including "global" things (vmalloc) */
+   movqmmu_cr4_features(%rip), %rax
+   movq%rax, %rdx
+   andq$~(1<<7), %rdx;  # PGE
+   movq%rdx, %cr4;  # turn off PGE
+   movq%cr3, %rcx;  # flush TLB
+   movq%rcx, %cr3
+   movq%rax, %cr4;  # turn PGE back on
+
movl$24, %eax
movl%eax, %ds
 
movq saved_context_esp(%rip), %rsp
movq saved_context_ebp(%rip), %rbp
-   movq saved_context_eax(%rip), %rax
+   /* Don't restore %rax, it must be 0 anyway */
movq saved_context_ebx(%rip), %rbx
movq saved_context_ecx(%rip), %rcx
movq saved_context_edx(%rip), %rdx
@@ -89,5 +98,7 @@ done:
movq saved_context_r14(%rip), %r14
movq saved_context_r15(%rip), %r15
pushq saved_context_eflags(%rip) ; popfq
-   callswsusp_restore
+
+   xorq%rax, %rax
+
ret
diff -Nrup linux-2.6.12-rc1/include/linux/suspend.h 
linux-2.6.12-rc1-new/include/linux/suspend.h
--- linux-2.6.12-rc1/include/linux/suspend.h2005-03-20 00:36:55.0 
+0100
+++ linux-2.6.12-rc1-new/include/linux/suspend.h2005-03-20 
00:38:53.0 +0100
@@ -34,8 +34,6 @@ typedef struct pbe {
 #define SWAP_FILENAME_MAXLENGTH32
 
 
-#define SUSPEND_PD_PAGES(x) (((x)*sizeof(struct pbe))/PAGE_SIZE+1)
-
 extern dev_t swsusp_resume_device;

 /* mm/vmscan.c */
diff -Nrup linux-2.6.12-rc1/kernel/power/swsusp.c 
linux-2.6.12-rc1-new/kernel/power/swsusp.c
--- linux-2.6.12-rc1/kernel/power/swsusp.c  2005-03-20 00:37:04.0 
+0100
+++ linux-2.6.12-rc1-new/kernel/power/swsusp.c  2005-03-20 00:38:53.0 
+0100
@@ -98,7 +98,6 @@ unsigned int nr_copy_pages __nosavedata 
  */
 suspend_pagedir_t *pagedir_nosave __nosavedata = NULL;
 static suspend_pagedir_t *pagedir_save;
-static int pagedir_order __nosavedata = 0;
 
 #define SWSUSP_SIG "S1SUSPEND"
 
@@ -894,28 +893,21 @@ int swsusp_suspend(void)
 */
if ((error = device_power_down(PMSG_FREEZE))) {
local_irq_enable();
+   swsusp_free();
return error;
}
save_processor_state();
-   error = swsusp_arch_suspend();
+   if ((error = swsusp_arch_suspend()))
+   swsusp_free();
/* Restore control flow magically appears here */
restore_processor_state();
+   BUG_ON (nr_copy_pages_check != nr_copy_pages);
restore_highmem();
device_power_up();
local_irq_enable();
return error;
 }
 
-
-asmlinkage int swsusp_restore(void)
-{
-   BUG_ON (nr_copy_pages_check != nr_copy_pages);
-   
-   /* Even mappings of "global" things (vmalloc) need to be fixed */
-   __flush_tlb_global();
-   return 0;
-}
-
 int swsusp_resume(void)
 {
int error;
@@ -1219,7 +1211,6 @@ static int check_header(void)
return -EPERM;
}
nr_copy_pages = swsusp_info.image_pages;
-   pagedir_order = get_bitmask_order(SUSPEND_PD_PAGES(nr_copy_pages));
r

Re: [KBUILD] Bug in make deb-pkg when using seperate source and object directories

[Ryan Anderson]

On Mon, Mar 14, 2005 at 11:59:26AM -0800, Ajay Patel wrote:
> I had a similar problem building binrpm-pkg.
> Try following patch. It worked for me.

My problem wasn't actually resolved by this - the make in builddeb still
caused issues.

So, a normal, unified diff form of the patch, fixed up, is attached.

Signed-off-By: Ryan Anderson <[EMAIL PROTECTED]>

Index: local-quilt/scripts/package/Makefile
===
--- local-quilt.orig/scripts/package/Makefile   2005-03-19 19:25:03.0 
-0500
+++ local-quilt/scripts/package/Makefile2005-03-19 19:25:06.0 
-0500
@@ -59,7 +59,7 @@ $(objtree)/binkernel.spec: $(MKSPEC) $(s
$(CONFIG_SHELL) $(MKSPEC) prebuilt > $@

 binrpm-pkg: $(objtree)/binkernel.spec
-   $(MAKE)
+   $(MAKE) KBUILD_SRC=
set -e; \
$(CONFIG_SHELL) $(srctree)/scripts/mkversion > $(objtree)/.tmp_version
set -e; \
@@ -74,7 +74,7 @@ clean-files += $(objtree)/binkernel.spec
 #
 .PHONY: deb-pkg
 deb-pkg:
-   $(MAKE)
+   $(MAKE) KBUILD_SRC=
$(CONFIG_SHELL) $(srctree)/scripts/package/builddeb
 
 clean-dirs += $(objtree)/debian/
Index: local-quilt/scripts/package/builddeb
===
--- local-quilt.orig/scripts/package/builddeb   2005-03-19 19:25:03.0 
-0500
+++ local-quilt/scripts/package/builddeb2005-03-19 19:25:27.0 
-0500
@@ -25,7 +25,7 @@ cp .config "$tmpdir/boot/config-$version
 cp $KBUILD_IMAGE "$tmpdir/boot/vmlinuz-$version"
 
 if grep -q '^CONFIG_MODULES=y' .config ; then
-   INSTALL_MOD_PATH="$tmpdir" make modules_install
+   INSTALL_MOD_PATH="$tmpdir" make KBUILD_SRC= modules_install
 fi
 
 # Install the maintainer scripts

-- 

Ryan Anderson
  sometimes Pug Majere
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00

[Lee Revell]

On Sat, 2005-03-19 at 20:16 +0100, Ingo Molnar wrote:
> i have released the -V0.7.41-00 Real-Time Preemption patch (merged to
> 2.6.12-rc1), which can be downloaded from the usual place:
> 
>   http://redhat.com/~mingo/realtime-preempt/
> 

3ms latency in the NFS client code.  Workload was a kernel compile over
NFS.

preemption latency trace v1.1.4 on 2.6.12-rc1-RT-V0.7.41-00

 latency: 3178 ïs, #4095/14224, CPU#0 | (M:preempt VP:0, KP:1, SP:1 HP:1 #P:1)
-
| task: ksoftirqd/0-2 (uid:0 nice:-10 policy:0 rt_prio:0)
-

 _--=> CPU#
/ _-=> irqs-off
   | / _=> need-resched
   || / _---=> hardirq/softirq 
   ||| / _--=> preempt-depth   
    /  
   | delay 
   cmd pid | time  |   caller  
  \   /|   \   |   /   
(T1/#0)<...> 32105 0 3 0004  [0011939614227867] 0.000ms 
(+4137027.445ms): <6500646c> (<6100>)
(T1/#2)<...> 32105 0 3 0004 0002 [0011939614228097] 0.000ms 
(+0.000ms): __trace_start_sched_wakeup+0x9a/0xd0  
(try_to_wake_up+0x94/0x140 )
(T1/#3)<...> 32105 0 3 0003 0003 [0011939614228436] 0.000ms 
(+0.000ms): preempt_schedule+0x11/0x80  (try_to_wake_up+0x94/0x140 
)
(T3/#4)<...>-32105 0dn.30ïs : try_to_wake_up+0x11e/0x140  
<<...>-2> (69 76): 
(T1/#5)<...> 32105 0 3 0002 0005 [0011939614228942] 0.000ms 
(+0.000ms): preempt_schedule+0x11/0x80  (try_to_wake_up+0xf8/0x140 
)
(T1/#6)<...> 32105 0 3 0002 0006 [0011939614229130] 0.000ms 
(+0.000ms): wake_up_process+0x35/0x40  (do_softirq+0x3f/0x50 
)
(T6/#7)<...>-32105 0dn.11ïs < (1)
(T1/#8)<...> 32105 0 2 0001 0008 [0011939614229782] 0.001ms 
(+0.000ms): radix_tree_gang_lookup+0xe/0x70  
(nfs_wait_on_requests+0x6d/0x110 )
(T1/#9)<...> 32105 0 2 0001 0009 [0011939614229985] 0.001ms 
(+0.000ms): __lookup+0xe/0xd0  (radix_tree_gang_lookup+0x52/0x70 
)
(T1/#10)<...> 32105 0 2 0001 000a [0011939614230480] 
0.001ms (+0.000ms): radix_tree_gang_lookup+0xe/0x70  
(nfs_wait_on_requests+0x6d/0x110 )
(T1/#11)<...> 32105 0 2 0001 000b [0011939614230634] 
0.002ms (+0.000ms): __lookup+0xe/0xd0  
(radix_tree_gang_lookup+0x52/0x70 )
(T1/#12)<...> 32105 0 2 0001 000c [0011939614230889] 
0.002ms (+0.000ms): radix_tree_gang_lookup+0xe/0x70  
(nfs_wait_on_requests+0x6d/0x110 )
(T1/#13)<...> 32105 0 2 0001 000d [0011939614231034] 
0.002ms (+0.000ms): __lookup+0xe/0xd0  
(radix_tree_gang_lookup+0x52/0x70 )
(T1/#14)<...> 32105 0 2 0001 000e [0011939614231302] 
0.002ms (+0.000ms): radix_tree_gang_lookup+0xe/0x70  
(nfs_wait_on_requests+0x6d/0x110 )
(T1/#15)<...> 32105 0 2 0001 000f [0011939614231419] 
0.002ms (+0.000ms): __lookup+0xe/0xd0  
(radix_tree_gang_lookup+0x52/0x70 )

(last two lines just repeat)

This is probably not be a regression; I had never tested this with NFS
before.

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH][0/6] Change proc file permissions with sysctls

[Rene Scharfe]

The following patches implement another interface that allows an admin
to restrict permissions inside /proc/ to enhance the privacy of
users.  Following a suggestion by Albert Calahan this set of patches
introduces five sysctls, each one changes the permissions of a certain
file in /proc/.

It works by implementing getattr and permission methods that update the
files' permissions (btw. Al Viro suggested doing it this way right from
the start..).

To "cloak" as much as currently possible:

   # sysctl -q proc.cmdline=0400
   # sysctl -q proc.maps=0400
   # sysctl -q proc.stat=0400
   # sysctl -q proc.statm=0400
   # sysctl -q proc.status=0400

This will set the permissions of /proc/*/cmdline etc. to the given
value.

The permissions of files in /proc/1 (usually belonging to init) are
kept as they are.  The idea is to let system processes be freely
visible by anyone, just as before.  Especially interesting in this
regard would be instances of login.  I don't know how to easily
discriminate between system processes and "normal" processes inside
the kernel (apart from pid == 1 and uid == 0 (which is too broad)).
Any ideas?

It's easy to make more files' permissions configurable, if the need
arises.

This implementation is a lot bigger than the quick hacks I sent earlier.
Is this feature growing too fat?  Also I'm unsure about the #ifdef'ery
in fs/proc/base.c, I just wanted to be consistent with the surrounding
code. :-P

Rene

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] get rid of redundant NULL checks before kfree() in arch/i386/

[Jesper Juhl]

Checking a pointer for NULL before calling kfree() on it is redundant,
kfree() deals with NULL pointers just fine.
This patch removes such checks from files in arch/i386/

Since this is a fairly trivial change (and the same change made
everywhere) I've just made a single patch for all four files and CC all
authors/maintainers of those files I could find for comments. If spliting
this into one patch pr file is prefered, then I can easily do that as
well.

These are the files being modified :
arch/i386/kernel/cpu/cpufreq/powernow-k7.c
arch/i386/kernel/cpu/intel_cacheinfo.c
arch/i386/kernel/cpu/mtrr/generic.c
arch/i386/kernel/io_apic.c

(please CC me on replies to lists other than linux-kernel)


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>

--- linux-2.6.11-mm4-orig/arch/i386/kernel/cpu/cpufreq/powernow-k7.c
2005-03-16 15:45:02.0 +0100
+++ linux-2.6.11-mm4/arch/i386/kernel/cpu/cpufreq/powernow-k7.c 2005-03-20 
00:41:27.0 +0100
@@ -643,9 +643,7 @@ static int powernow_cpu_exit (struct cpu
}
 #endif
 
-   if (powernow_table)
-   kfree(powernow_table);
-
+   kfree(powernow_table);
return 0;
 }
 
--- linux-2.6.11-mm4-orig/arch/i386/kernel/cpu/intel_cacheinfo.c
2005-03-16 15:45:02.0 +0100
+++ linux-2.6.11-mm4/arch/i386/kernel/cpu/intel_cacheinfo.c 2005-03-20 
00:43:21.0 +0100
@@ -491,12 +491,9 @@ static int cpuid4_cache_sysfs_init(unsig
 
 err_out:
for (i = 0; i < NR_CPUS; i++) {
-   if(cpuid4_info[i])
-   kfree(cpuid4_info[i]);
-   if(cache_kobject[i])
-   kfree(cache_kobject[i]);
-   if(index_kobject[i])
-   kfree(index_kobject[i]);
+   kfree(cpuid4_info[i]);
+   kfree(cache_kobject[i]);
+   kfree(index_kobject[i]);
 
cpuid4_info[i] = NULL;
cache_kobject[i] = NULL;
@@ -508,12 +505,9 @@ err_out:
 
 static int cpuid4_cache_sysfs_exit(unsigned int i)
 {
-   if(cpuid4_info[i])
-   kfree(cpuid4_info[i]);
-   if(cache_kobject[i])
-   kfree(cache_kobject[i]);
-   if(index_kobject[i])
-   kfree(index_kobject[i]);
+   kfree(cpuid4_info[i]);
+   kfree(cache_kobject[i]);
+   kfree(index_kobject[i]);
 
cpuid4_info[i] = NULL;
cache_kobject[i] = NULL;
--- linux-2.6.11-mm4-orig/arch/i386/kernel/cpu/mtrr/generic.c   2005-03-16 
15:45:02.0 +0100
+++ linux-2.6.11-mm4/arch/i386/kernel/cpu/mtrr/generic.c2005-03-20 
00:43:39.0 +0100
@@ -70,8 +70,7 @@ void __init get_mtrr_state(void)
 /*  Free resources associated with a struct mtrr_state  */
 void __init finalize_mtrr_state(void)
 {
-   if (mtrr_state.var_ranges)
-   kfree(mtrr_state.var_ranges);
+   kfree(mtrr_state.var_ranges);
mtrr_state.var_ranges = NULL;
 }
 
--- linux-2.6.11-mm4-orig/arch/i386/kernel/io_apic.c2005-03-16 
15:45:02.0 +0100
+++ linux-2.6.11-mm4/arch/i386/kernel/io_apic.c 2005-03-20 00:44:47.0 
+0100
@@ -632,10 +632,8 @@ static int __init balanced_irq_init(void
printk(KERN_ERR "balanced_irq_init: failed to spawn 
balanced_irq");
 failed:
for (i = 0; i < NR_CPUS; i++) {
-   if(irq_cpu_data[i].irq_delta)
-   kfree(irq_cpu_data[i].irq_delta);
-   if(irq_cpu_data[i].last_irq)
-   kfree(irq_cpu_data[i].last_irq);
+   kfree(irq_cpu_data[i].irq_delta);
+   kfree(irq_cpu_data[i].last_irq);
}
return 0;
 }


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] disable builtin modules

[Magnus Damm]

This patch makes it possible to disable built in code from the kernel
command line. The patch is rather simple - it extends the compiled-in case 
of module_init() to include __setup() with a name based on KBUILD_MODNAME.

Problem: Say that your Firewire PHY breaks and you find yourself unable to 
boot any installation cd that includes built in Firewire support because 
the ohci1394 code together with your broken hardware makes the kernel crash 
during bootup.

Solution: Boot a kernel that includes this patch and pass ohci1394=off.

Signed-off-by: Magnus Damm <[EMAIL PROTECTED]>

diff -urNp linux-2.6.11.4/include/linux/init.h 
linux-2.6.11.4-disable_builtin/include/linux/init.h
--- linux-2.6.11.4/include/linux/init.h 2005-03-16 10:56:20.0 +0100
+++ linux-2.6.11.4-disable_builtin/include/linux/init.h 2005-03-19 
23:42:29.417496240 +0100
@@ -143,6 +143,16 @@ struct obs_kernel_param {
 
 /* Relies on saved_command_line being set */
 void __init parse_early_param(void);
+
+void __init disable_initcall(void *fn);
+#define __module_init_disable(x)   \
+static int __init x##_disable_module(char *str)\
+{  \
+   disable_initcall(x);\
+   return 1;   \
+}  \
+__setup(__stringify(KBUILD_MODNAME) "=off", x##_disable_module)
+
 #endif /* __ASSEMBLY__ */
 
 /**
@@ -153,7 +163,7 @@ void __init parse_early_param(void);
  * builtin) or at module insertion time (if a module).  There can only
  * be one per module.
  */
-#define module_init(x) __initcall(x);
+#define module_init(x) __initcall(x); __module_init_disable(x);  
 
 /**
  * module_exit() - driver exit entry point
diff -urNp linux-2.6.11.4/init/main.c linux-2.6.11.4-disable_builtin/init/main.c
--- linux-2.6.11.4/init/main.c  2005-03-16 10:56:20.0 +0100
+++ linux-2.6.11.4-disable_builtin/init/main.c  2005-03-19 23:31:52.676295616 
+0100
@@ -527,6 +527,17 @@ struct task_struct *child_reaper = &init
 
 extern initcall_t __initcall_start[], __initcall_end[];
 
+void __init disable_initcall(void *fn)
+{
+   initcall_t *call;
+
+   for (call = __initcall_start; call < __initcall_end; call++) {
+
+   if (*call == fn)
+   *call = NULL;
+   }
+}
+
 static void __init do_initcalls(void)
 {
initcall_t *call;
@@ -541,7 +552,8 @@ static void __init do_initcalls(void)
printk("\n");
}
 
-   (*call)();
+   if (*call)
+   (*call)();
 
msg = NULL;
if (preempt_count() != count) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] gcc-4.0 compatibility fixes for i386, m68k, ppc64, x86_64

[Dan Kegel]

gcc-4.0 fails with
"error: array type has incomplete element type"
(see http://gcc.gnu.org/ml/gcc/2005-02/msg00053.html)
on several files in linux-2.6.11.3.
Who knows, maybe all this is fixed in the -mm tree already,
but what the heck, here are a few fixes I haven't seen anyone
else post yet.  These fix build problems for me, and
are all trivial.  I haven't tested the resulting binaries.
See also related sets of fixes at
http://user.it.uu.se/~mikpe/linux/patches/2.6/patch-gcc4-fixes-v2-2.6.11
and
http://archives.andrew.net.au/lm-sensors/msg29809.html
I don't duplicate any of those here, I think.
--- part 1 ---
Fixes
In file included from include/asm/thread_info.h:16,
 from include/linux/thread_info.h:21,
 from include/linux/spinlock.h:12,
 from include/linux/capability.h:45,
 from include/linux/sched.h:7,
 from arch/i386/kernel/asm-offsets.c:7:
include/asm/processor.h:87: error: array type has incomplete element type
make[1]: *** [arch/i386/kernel/asm-offsets.asm] Error 1
--- linux-2.6.11.3/include/asm-i386/processor.h.old Tue Mar 15 06:45:26 2005
+++ linux-2.6.11.3/include/asm-i386/processor.h Tue Mar 15 06:46:45 2005
@@ -81,6 +81,64 @@
 #define X86_VENDOR_UNKNOWN 0xff
 /*
+ * Size of io_bitmap.
+ */
+#define IO_BITMAP_BITS  65536
+#define IO_BITMAP_BYTES (IO_BITMAP_BITS/8)
+#define IO_BITMAP_LONGS (IO_BITMAP_BYTES/sizeof(long))
+#define INVALID_IO_BITMAP_OFFSET 0x8000
+#define INVALID_IO_BITMAP_OFFSET_LAZY 0x9000
+
+struct tss_struct {
+   unsigned short  back_link,__blh;
+   unsigned long   esp0;
+   unsigned short  ss0,__ss0h;
+   unsigned long   esp1;
+   unsigned short  ss1,__ss1h; /* ss1 is used to cache 
MSR_IA32_SYSENTER_CS */
+   unsigned long   esp2;
+   unsigned short  ss2,__ss2h;
+   unsigned long   __cr3;
+   unsigned long   eip;
+   unsigned long   eflags;
+   unsigned long   eax,ecx,edx,ebx;
+   unsigned long   esp;
+   unsigned long   ebp;
+   unsigned long   esi;
+   unsigned long   edi;
+   unsigned short  es, __esh;
+   unsigned short  cs, __csh;
+   unsigned short  ss, __ssh;
+   unsigned short  ds, __dsh;
+   unsigned short  fs, __fsh;
+   unsigned short  gs, __gsh;
+   unsigned short  ldt, __ldth;
+   unsigned short  trace, io_bitmap_base;
+   /*
+* The extra 1 is there because the CPU will access an
+* additional byte beyond the end of the IO permission
+* bitmap. The extra byte must be all 1 bits, and must
+* be within the limit.
+*/
+   unsigned long   io_bitmap[IO_BITMAP_LONGS + 1];
+   /*
+* Cache the current maximum and the last task that used the bitmap:
+*/
+   unsigned long io_bitmap_max;
+   struct thread_struct *io_bitmap_owner;
+   /*
+* pads the TSS to be cacheline-aligned (size is 0x100)
+*/
+   unsigned long __cacheline_filler[35];
+   /*
+* .. and then another 0x100 bytes for emergency kernel stack
+*/
+   unsigned long stack[64];
+} __attribute__((packed));
+
+#define IO_BITMAP_OFFSET offsetof(struct tss_struct,io_bitmap)
+#define ARCH_MIN_TASKALIGN 16
+
+/*
  * capabilities of CPUs
  */
@@ -308,16 +366,6 @@
 #define HAVE_ARCH_PICK_MMAP_LAYOUT
-/*
- * Size of io_bitmap.
- */
-#define IO_BITMAP_BITS  65536
-#define IO_BITMAP_BYTES (IO_BITMAP_BITS/8)
-#define IO_BITMAP_LONGS (IO_BITMAP_BYTES/sizeof(long))
-#define IO_BITMAP_OFFSET offsetof(struct tss_struct,io_bitmap)
-#define INVALID_IO_BITMAP_OFFSET 0x8000
-#define INVALID_IO_BITMAP_OFFSET_LAZY 0x9000
-
 struct i387_fsave_struct {
longcwd;
longswd;
@@ -371,54 +419,6 @@
 } mm_segment_t;
 struct thread_struct;
-
-struct tss_struct {
-   unsigned short  back_link,__blh;
-   unsigned long   esp0;
-   unsigned short  ss0,__ss0h;
-   unsigned long   esp1;
-   unsigned short  ss1,__ss1h; /* ss1 is used to cache 
MSR_IA32_SYSENTER_CS */
-   unsigned long   esp2;
-   unsigned short  ss2,__ss2h;
-   unsigned long   __cr3;
-   unsigned long   eip;
-   unsigned long   eflags;
-   unsigned long   eax,ecx,edx,ebx;
-   unsigned long   esp;
-   unsigned long   ebp;
-   unsigned long   esi;
-   unsigned long   edi;
-   unsigned short  es, __esh;
-   unsigned short  cs, __csh;
-   unsigned short  ss, __ssh;
-   unsigned short  ds, __dsh;
-   unsigned short  fs, __fsh;
-   unsigned short  gs, __gsh;
-   unsigned short  ldt, __ldth;
-   unsigned short  trace, io_bitmap_base;
-   /*
-* The extra 1 is there because the CPU will access an
-* additional byte beyond the end of the IO permission
-* bitmap. The extra byte must be all 1 bits, and must
-* be within the limit.
-*/
-   unsigned long   io_bitmap[IO_BITMAP_LONGS + 1];
-   /*
-* Cache the current maximum 

Re: [PATCH] alpha build fixes

[Jeff Garzik]

On Sat, Mar 19, 2005 at 03:11:16PM -0800, Richard Henderson wrote:
> On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
> > +/* TODO: integrate with include/asm-generic/pci.h ? */
> > +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> > +{
> > +   return channel ? 15 : 14;
> > +}
> 
> Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
> Why in the world would we have this much infrastructure for one driver?  And
> why not just not compile that one for Alpha, since it'll never be used.

My presumption is that it will be used in other IDE drivers in the
future.  Bart?

If it will only be used in that one driver, then I agree.

Jeff



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] alpha build fixes

[Richard Henderson]

On Fri, Mar 18, 2005 at 11:34:07PM -0500, Jeff Garzik wrote:
> +/* TODO: integrate with include/asm-generic/pci.h ? */
> +static inline int pci_get_legacy_ide_irq(struct pci_dev *dev, int channel)
> +{
> + return channel ? 15 : 14;
> +}

Am I missing something, or is this *only* used by drivers/ide/pci/amd74xx.c?
Why in the world would we have this much infrastructure for one driver?  And
why not just not compile that one for Alpha, since it'll never be used.


r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] fix bridge <-> ATM compile error

[Adrian Bunk]

On Thu, Mar 17, 2005 at 03:36:40PM -0500, chas williams - CONTRACTOR wrote:
> In message <[EMAIL PROTECTED]>,Adrian Bunk writes:
> >Letting CONFIG_BRIDGE depend on CONFIG_ATM doesn't sound like a good 
> >idea, since I doubt all people using the Bridge code require ATM 
> >support.
> 
> how about the following?
>...

Looks good.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] remove redundant NULL checks before kfree() in drivers/video/

[Jesper Juhl]

Checking a pointer for NULL before calling kfree() on it is redundant, 
kfree() deals with NULL pointers just fine.
This patch removes such checks from files in drivers/video/

Since this is a fairly trivial change (and the same change made 
everywhere) I've just made a single patch for all the files and CC all 
authors/maintainers of those files I could find for comments. If spliting 
this into one patch pr file is prefered, then I can easily do that as 
well.

These are the files being modified : 
drivers/video/aty/atyfb_base.c
drivers/video/aty/radeon_base.c
drivers/video/aty/radeon_monitor.c
drivers/video/console/bitblit.c
drivers/video/console/sticore.c
drivers/video/fbmem.c
drivers/video/fbmon.c
drivers/video/igafb.c
drivers/video/pxafb.c
drivers/video/riva/fbdev.c
drivers/video/sa1100fb.c


(please CC me on replies to lists other than linux-kernel)


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>

--- linux-2.6.11-mm4-orig/drivers/video/aty/atyfb_base.c2005-03-16 
15:45:26.0 +0100
+++ linux-2.6.11-mm4/drivers/video/aty/atyfb_base.c 2005-03-19 
22:23:47.0 +0100
@@ -3435,8 +3435,7 @@ static int __devinit atyfb_pci_probe(str
 
 err_release_io:
 #ifdef __sparc__
-   if (par->mmap_map)
-   kfree(par->mmap_map);
+   kfree(par->mmap_map);
 #else
if (par->ati_regbase)
iounmap(par->ati_regbase);
@@ -3444,7 +3443,7 @@ err_release_io:
iounmap(info->screen_base);
 #endif
 err_release_mem:
-   if(par->aux_start)
+   if (par->aux_start)
release_mem_region(par->aux_start, par->aux_size);
 
release_mem_region(par->res_start, par->res_size);
@@ -3551,8 +3550,7 @@ static void __devexit atyfb_remove(struc
 #endif
 #endif
 #ifdef __sparc__
-   if (par->mmap_map)
-   kfree(par->mmap_map);
+   kfree(par->mmap_map);
 #endif
if (par->aux_start)
release_mem_region(par->aux_start, par->aux_size);
--- linux-2.6.11-mm4-orig/drivers/video/aty/radeon_base.c   2005-03-16 
15:45:26.0 +0100
+++ linux-2.6.11-mm4/drivers/video/aty/radeon_base.c2005-03-19 
22:24:39.0 +0100
@@ -2420,10 +2420,8 @@ static int radeonfb_pci_register (struct
 err_unmap_fb:
iounmap(rinfo->fb_base);
 err_unmap_rom:
-   if (rinfo->mon1_EDID)
-   kfree(rinfo->mon1_EDID);
-   if (rinfo->mon2_EDID)
-   kfree(rinfo->mon2_EDID);
+   kfree(rinfo->mon1_EDID);
+   kfree(rinfo->mon2_EDID);
if (rinfo->mon1_modedb)
fb_destroy_modedb(rinfo->mon1_modedb);
fb_dealloc_cmap(&info->cmap);
@@ -2479,10 +2477,8 @@ static void __devexit radeonfb_pci_unreg
  
pci_release_regions(pdev);
 
-   if (rinfo->mon1_EDID)
-   kfree(rinfo->mon1_EDID);
-   if (rinfo->mon2_EDID)
-   kfree(rinfo->mon2_EDID);
+   kfree(rinfo->mon1_EDID);
+   kfree(rinfo->mon2_EDID);
if (rinfo->mon1_modedb)
fb_destroy_modedb(rinfo->mon1_modedb);
 #ifdef CONFIG_FB_RADEON_I2C
--- linux-2.6.11-mm4-orig/drivers/video/aty/radeon_monitor.c2005-03-16 
15:45:26.0 +0100
+++ linux-2.6.11-mm4/drivers/video/aty/radeon_monitor.c 2005-03-19 
22:25:11.0 +0100
@@ -618,11 +618,9 @@ void __devinit radeon_probe_screens(stru
}
}
if (ignore_edid) {
-   if (rinfo->mon1_EDID)
-   kfree(rinfo->mon1_EDID);
+   kfree(rinfo->mon1_EDID);
rinfo->mon1_EDID = NULL;
-   if (rinfo->mon2_EDID)
-   kfree(rinfo->mon2_EDID);
+   kfree(rinfo->mon2_EDID);
rinfo->mon2_EDID = NULL;
}
 
--- linux-2.6.11-mm4-orig/drivers/video/console/bitblit.c   2005-03-16 
15:45:26.0 +0100
+++ linux-2.6.11-mm4/drivers/video/console/bitblit.c2005-03-19 
22:27:39.0 +0100
@@ -199,8 +199,7 @@ static void bit_putcs(struct vc_data *vc
count -= cnt;
}
 
-   if (buf)
-   kfree(buf);
+   kfree(buf);
 }
 
 static void bit_clear_margins(struct vc_data *vc, struct fb_info *info,
@@ -273,8 +272,7 @@ static void bit_cursor(struct vc_data *v
dst = kmalloc(w * vc->vc_font.height, GFP_ATOMIC);
if (!dst)
return;
-   if (ops->cursor_data)
-   kfree(ops->cursor_data);
+   kfree(ops->cursor_data);
ops->cursor_data = dst;
update_attr(dst, src, attribute, vc);
src = dst;
@@ -321,8 +319,7 @@ static void bit_cursor(struct vc_data *v
if (!mask)
return;
 
-   if (ops->cursor_state.mask)
-   kfree(ops->cursor_state.mask);
+   kfree(ops->cursor_state.mask);
ops->cursor_state.mask = mask;
 
 

Re: [MC] [CHECKER] Do ext2, jfs and reiserfs respect mount -o sync/dirsync option?

[Florian Weimer]

* Bernd Eckenfels:

> In article <[EMAIL PROTECTED]> you wrote:
>> 3. I open a file w/o O_SYNC, issue a bunch of writes, then call
>> ioctl(FIOASYNC) to set the fd sync, then issure a second set of writes.
>> Only the second set of writes are synchronous?
>
> I also am curious if one can open a file, write to it, close it, open it and
> do fsync()/fdatasync() on it?

Hopefully the fsync/fdatasync call will flush all previous writes
(even from other processes).  Berkeley DB relies on this behavior for
correct operation.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.11.5

[Panagiotis Issaris]

Hi Greg,

The changelog states that the patches for the AMD8111e and VIA-Rhine
originated from dilingerdebian.org although I was the one who they
originated from.

http://article.gmane.org/gmane.linux.kernel/282245
http://article.gmane.org/gmane.linux.kernel/282263

:
  o Possible AMD8111e free irq issue
  o Possible VIA-Rhine free irq issue

With friendly regards,
Takis

-- 
OpenPGP key: http://lumumba.luc.ac.be/takis/takis_public_key.txt
fingerprint: 6571 13A3 33D9 3726 F728  AA98 F643 B12E ECF3 E029
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] partitions/msdos.c

[Grzegorz Kulewski]

On Sat, 19 Mar 2005, Werner Almesberger wrote:
Andries Brouwer wrote:
The two variants are: (i) partition tells the kernel
to do the partition table reading, and (ii) partition uses partx
to read the partition table and tells the kernel one-by-one
about the partitions found this way.
I guess, once you've reached the point where the kernel is
unable to find partitions without user-space help, you may
as well do everything in user space.
I agree. This is userspace job. This can be done very easily using 
device-mapper. I think EVMS does something similar.

I even asked on LKML some time ago about option for disabling kernel 
partition driver (maybe for some devices) from kernel command line to 
allow other tools do the job (because now I have unusable /dev/sda1 and 
usable /dev/evms/sda1 and this leads to stupid mistakes). But there were 
no replies.

Grzegorz Kulewski
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clean up FIXME in do_timer_interrupt-lock fix

[George Anzinger]

Andrew Morton wrote:
George Anzinger  wrote:
Did you pick this up?  First sent on 3-11.

I did, although now looking at it I have issues.

I was not happy with the locking on this.  Two changes:
1) Turn off irq while setting the clock.
2) Call the timer code only through the timer interface 
   (set a short timer to do it from the ntp call).

I wanted the calls to sync_cmos_clock() to be made in a consistent environment. 
 This was not true when calling it directly from the NTP call code.  The change 
means that sync_cmos_clock() is ALWAYS called from run_timers(), i.e. as a timer 
call back function.
I would consider this to be an inadequate description :(

Signed-off-by: George Anzinger 
 time.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6.12-rc/arch/i386/kernel/time.c
===
--- linux-2.6.12-rc.orig/arch/i386/kernel/time.c
+++ linux-2.6.12-rc/arch/i386/kernel/time.c
@@ -176,12 +176,12 @@ static int set_rtc_mmss(unsigned long no
 	int retval;
 
 	/* gets recalled with irq locally disabled */
-	spin_lock(&rtc_lock);
+	spin_lock_irq(&rtc_lock);
 	if (efi_enabled)
 		retval = efi_set_rtc_mmss(nowtime);
 	else
 		retval = mach_set_rtc_mmss(nowtime);
-	spin_unlock(&rtc_lock);
+	spin_unlock_irq(&rtc_lock);
 
 	return retval;
 }

If the comment is correct, and this code is called with local irq's
disabled then this patch should be using spin_lock_irqsave()
With the change below, it is always called from the timer call back code which, 
I believe, is always called with irq on.  Looks like I missed the comment :(

@@ -338,7 +338,7 @@ static void sync_cmos_clock(unsigned lon
 }
 void notify_arch_cmos_timer(void)
 {
-	sync_cmos_clock(0);
+	mod_timer(&sync_cmos_timer, jiffies + 1);
 }
 static long clock_cmos_diff, sleep_start;
 

Your description says what this does, but it doesn't way why it was done?
--
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation

[Matt Domsch]

On Sat, Mar 19, 2005 at 08:26:45PM +0100, Andi Kleen wrote:
> On Fri, Mar 18, 2005 at 03:23:44PM -0600, Matt Domsch wrote:
> > For review and comment.
> > 
> > On x86_64 systems with no IOMMU and with >4GB RAM (in fact, whenever
> > there are any pages mapped above 4GB), pci_alloc_consistent() falls
> > back to using ZONE_DMA for all allocations, even if the device's
> > dma_mask could have supported using memory from other zones.  Problems
> > can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume
> > all of ZONE_DMA, leaving none left for pci_alloc_consistent() use.
> > 
> > Patch below makes pci_alloc_consistent() for the nommu case (EM64T
> > processors) match the 2.6 implementation of dma_alloc_coherent(), with
> > the exception that this continues to use GFP_ATOMIC.
> 
> You fixed the wrong code. The pci-nommu code is only used
> when IOMMU is disabled in the Kconfig. But most kernels have
> it enabled. You would need to change it in pci-gart.c too.

OK, then how's this for review?  Compiles clean, can't test it myself
for a few days.

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

= arch/x86_64/kernel/pci-gart.c 1.12 vs edited =
--- 1.12/arch/x86_64/kernel/pci-gart.c  2004-06-03 05:29:36 -05:00
+++ edited/arch/x86_64/kernel/pci-gart.c2005-03-19 15:56:34 -06:00
@@ -154,27 +154,37 @@ void *pci_alloc_consistent(struct pci_de
int gfp = GFP_ATOMIC;
int i;
unsigned long iommu_page;
+   dma_addr_t dma_mask;
 
-   if (hwdev == NULL || hwdev->dma_mask < 0x || no_iommu)
+   if (hwdev == NULL || hwdev->dma_mask < 0x)
gfp |= GFP_DMA;
 
+   dma_mask = hwdev ? hwdev->dma_mask : 0xULL;
+   if (dma_mask == 0)
+   dma_mask = 0xULL;
+
/* 
-* First try to allocate continuous and use directly if already 
-* in lowmem. 
+* First try to allocate continuous and use directly if
+* our device supports it
 */ 
size = round_up(size, PAGE_SIZE); 
+ again:
memory = (void *)__get_free_pages(gfp, get_order(size));
if (memory == NULL) {
return NULL; 
} else {
-   int high = 0, mmu;
-   if (((unsigned long)virt_to_bus(memory) + size) > 0xUL)
-   high = 1;
-   mmu = high;
+   int high = (((unsigned long)virt_to_bus(memory) + size) & 
~dma_mask) != 0;
+   int mmu = high;
if (force_mmu && !(gfp & GFP_DMA)) 
mmu = 1;
if (no_iommu) { 
-   if (high) goto error;
+   if (high && (gfp & GFP_DMA))
+   goto error;
+   if (high) {
+   free_pages((unsigned long)memory, 
get_order(size));
+   gfp |= GFP_DMA;
+   goto again;
+   }
mmu = 0; 
}   
memset(memory, 0, size); 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Bitrotting serial drivers

[Andrew Morton]

Russell King <[EMAIL PROTECTED]> wrote:
>
> Hi,
> 
> m32r_sio
> 
> 
> Maintainer: Hirokazu Takata
> 
> Please clean up the m32r_sio driver, removing whatever bits of code
> aren't absolutely necessary.
> 
> Specifically, I'd like to see the following addressed:
> 
> - the usage of SERIAL_IO_HUB6
>   (this driver doesn't support hub6 cards)
> - SERIAL_IO_* should be UPIO_*
> - __register_m32r_sio, register_m32r_sio, unregister_m32r_sio,
>   m32r_sio_get_irq_map
>   (this driver doesn't support PCMCIA cards, all of which are based on
>8250-compatible devices.)
> - early_serial_setup
>   (should we really have the function name duplicated across different
>hardware drivers?)
> 
> au1x00_uart
> ---
> 
> Maintainer: unknown (akpm - any ideas?)

Ralf.

> This is a complete clone of 8250.c, which includes all the 8250-specific
> structure names.
> 
> Specifically, I'd like to see the following addressed:
> 
> - Please clean this up to use au1x00-specific names.
> - this driver is lagging behind with fixes that the other drivers are
>   getting.  Is au1x00_uart actually maintained?
> - the usage of UPIO_HUB6
>   (this driver doesn't support hub6 cards)
> - __register_serial, register_serial, unregister_serial
>   (this driver doesn't support PCMCIA cards, all of which are based on
>8250-compatible devices.)
> - early_serial_setup
>   (should we really have the function name duplicated across different
>hardware drivers?)
> 
> The main reason is I wish to kill off uart_register_port and
> uart_unregister_port, but these drivers are using it.
> 
> Thanks.
> 
> -- 
> Russell King
>  Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
>  maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] Trivial patch to update a comment in drivers/video/s1d13xxxfb.c

[Jesper Juhl]

Trivial patch to update a comment in drivers/video/s1d13xxxfb.c

Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>

--- linux-2.6.11-mm4-orig/drivers/video/s1d13xxxfb.c2005-03-16 
15:45:26.0 +0100
+++ linux-2.6.11-mm4/drivers/video/s1d13xxxfb.c 2005-03-19 22:45:10.0 
+0100
@@ -720,7 +720,7 @@ static int s1d13xxxfb_resume(struct devi
if (s1dfb->disp_save) {
memcpy_toio(info->screen_base, s1dfb->disp_save,
info->fix.smem_len);
-   kfree(s1dfb->disp_save);/* XXX kmalloc()'d when? */
+   kfree(s1dfb->disp_save);/* kmalloc()'d in 
s1d13xxxfb_suspend */
}
 
if ((s1dfb->display & 0x01) != 0)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Scheduling changes in -mm tree

[Andrew Morton]

"Martin J. Bligh" <[EMAIL PROTECTED]> wrote:
>
> I don't think these are doing much for performance. Or at least 
> *something* in your tree isn't ...
> 
> Kernbench: 
>  ElapsedSystem  User   CPU
>  elm3b67  2.6.11   50.24146.60   1117.61   2516.67
>  elm3b67  2.6.11-mm1   52.27141.14   1099.91   2374.33
>  elm3b67  2.6.11-mm2   51.88142.41   1104.85   2403.67
>  elm3b67  2.6.11-mm4   51.23145.04   1100.70   2431.00
> 
> (elm3b67 is a 16x x440 ia32 NUMA system + HT)

Sounds like the CPU scheduler, yes

> Is there an easy way to just test those sched changes alone?

Nick has tossed out and redone all the scheduler patches from -mm4, but I
assume it's all pretty much the same.

At http://www.zip.com.au/~akpm/linux/patches/stuff/mbligh.gz is a rollup
(against 2.6.12-rc1) of

sched2-fix-schedstats-warning.patch
sched2-cleanup-wake_idle.patch
sched2-improve-load-balancing-pinned-tasks.patch
sched2-reduce-active-load-balancing.patch
sched2-fix-smt-scheduling-problems.patch
sched2-add-debugging.patch
sched2-less-aggressive-idle-balancing.patch
sched2-balance-timers.patch
sched2-tweak-affine-wakeups.patch
sched2-no-aggressive-idle-balancing.patch
sched2-balance-on-fork.patch
sched2-schedstats-update-for-balance-on-fork.patch
sched2-sched-tuning.patch
sched2-sched-domain-sysctl.patch
add-do_proc_doulonglongvec_minmax-to-sysctl-functions.patch

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: swsusp: Remove arch-specific references from generic code

[Pavel Machek]

Hi!

Do you think you could just send me diff between 2.6.12-rc1 and your
tree? I'll merge it here.
Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] partitions/msdos.c

[Werner Almesberger]

Andries Brouwer wrote:
> In other words, we need the user space command `partition',
> where "partition -t dos /dev/sda" reads a DOS-type partition
> table.

So if you e.g. hotplug a new device, its partitions won't be
accessible before you (or some hotplug manager, etc.) run
"partition" ?

> The two variants are: (i) partition tells the kernel
> to do the partition table reading, and (ii) partition uses partx
> to read the partition table and tells the kernel one-by-one
> about the partitions found this way.

I guess, once you've reached the point where the kernel is
unable to find partitions without user-space help, you may
as well do everything in user space.

> Since this is a fundamental change,

Pretty much, yes. Except for a few embedded systems (*), this
would mark the end of kernels that can do anything useful
without initrd or initramfs.

(*) Oh, regarding the other exception, ceterum censeo nfsroot
esse delendam.

> a long transition period
> is needed, and that period could start with a kernel boot parameter
> telling the kernel not to do partition table parsing on a particular
> disk, or a particular type of disks, or all disks.

... and allow "partition" to override partitions previously
auto-detected by the kernel. That way, you can phase in
"partition" without needing to change your kernel setup.

Besides, the ability to correct past mistakes would also be
useful if auto-detection from user space yields garbage.

- Werner

-- 
  _
 / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] /
/_http://www.almesberger.net//
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Latency tests with 2.6.12-rc1

[Lee Revell]

On Sat, 2005-03-19 at 02:51 -0500, Lee Revell wrote:
> On Sat, 2005-03-19 at 08:08 +0100, Ingo Molnar wrote:
> > great! The change in question is most likely the copy_page_range() fix
> > that Hugh resurrected:
> > 
> > ChangeSet 1.2037, 2005/03/08 09:26:46-08:00, [EMAIL PROTECTED]
> > 
> > [PATCH] copy_pte_range latency fix
> > 
> > Ingo's patch to reduce scheduling latencies, by checking for lockbreak 
> > in
> > copy_page_range, was in the -VP and -mm patchsets some months ago; but 
> > got
> > preempted by the 4level rework, and not reinstated since. Restore it now
> > in copy_pte_range - which mercifully makes it easier.
> > 
> > are the ext3 related latencies are gone as well - or are you working it
> > around by not using data=ordered?
> 
> As a matter of fact the ext3 latencies do not appear to be causing
> problems, at least not at those settings, even with data=ordered.
> 
> It's impossible to tell much more because the mainline kernel lacks the
> instrumentation that the realtime patchset provides.

Ingo,

I think I have nailed this down to a bug in the latency tracer.

I ran 2.6.12-rc1 all night with JACK at 64 frames.  Anything longer than
1.3 ms will cause xruns at this setting.  I did not get a single xrun
all night, despite running "dbench 64".

(The workload for all of the following tests was "dbench 16")

Then I tried 2.6.12-rc1-RT-V0.7.41-00 with PREEMPT_DESKTOP which should
be similar to mainline, with the addition of IRQ threading and the
latency instrumentation.  As soon as I ran "updatedb", the latency
tracer reported 3 and 4ms bumps in that same ext3 code path.  But, JACK
was not running at the time.

Next I tried the same test but with JACK running.  The longest latency
reported was only 200 usecs, and I did not get xruns.

Then, right after I stopped JACK, the latency tracer shot up to 1645
usecs.

So there seems to be a bug in the latency tracer where the timer is not
being reset on reschedule.  If an RT task like JACK is running,  the
task does wakeup properly and the counter is reset.  But if JACK is not
running then long latencies will be reported.

Lee

preemption latency trace v1.1.4 on 2.6.12-rc1-RT-V0.7.41-00

 latency: 3402 ïs, #4095/20285, CPU#0 | (M:preempt VP:0, KP:1, SP:1 HP:1 #P:1)
-
| task: ksoftirqd/0-2 (uid:0 nice:-10 policy:0 rt_prio:0)
-

 _--=> CPU#
/ _-=> irqs-off
   | / _=> need-resched
   || / _---=> hardirq/softirq 
   ||| / _--=> preempt-depth   
    /  
   | delay 
   cmd pid | time  |   caller  
  \   /|   \   |   /   
(T1/#0)<...>  2576 0 3 0004  [0002512920677720] 0.000ms 
(+3971052.610ms): <756f6a6b> (<6c616e72>)
(T1/#2)<...>  2576 0 3 0004 0002 [0002512920677953] 0.000ms 
(+0.000ms): __trace_start_sched_wakeup+0x9a/0xd0  
(try_to_wake_up+0x94/0x140 )
(T1/#3)<...>  2576 0 3 0003 0003 [0002512920678126] 0.000ms 
(+0.000ms): preempt_schedule+0x11/0x80  (try_to_wake_up+0x94/0x140 
)
(T3/#4)<...>-2576  0dn.30ïs : try_to_wake_up+0x11e/0x140  
<<...>-2> (69 73): 
(T1/#5)<...>  2576 0 3 0002 0005 [0002512920678609] 0.000ms 
(+0.000ms): preempt_schedule+0x11/0x80  (try_to_wake_up+0xf8/0x140 
)
(T1/#6)<...>  2576 0 3 0002 0006 [0002512920678807] 0.000ms 
(+0.000ms): wake_up_process+0x35/0x40  (do_softirq+0x3f/0x50 
)
(T6/#7)<...>-2576  0dn.11ïs < (1)
(T1/#8)<...>  2576 0 2 0001 0008 [0002512920679575] 0.001ms 
(+0.000ms): __journal_unfile_buffer+0xe/0x1c0  
(journal_commit_transaction+0xda2/0x1170 )
(T1/#9)<...>  2576 0 2 0001 0009 [0002512920680035] 0.001ms 
(+0.000ms): journal_remove_journal_head+0xc/0x60  
(journal_commit_transaction+0xdb7/0x1170 )
(T1/#10)<...>  2576 0 2 0001 000a [0002512920680231] 
0.001ms (+0.000ms): __journal_remove_journal_head+0x11/0x180  
(journal_remove_journal_head+0x3c/0x60 )
(T1/#11)<...>  2576 0 2 0001 000b [0002512920680454] 
0.002ms (+0.000ms): __brelse+0xb/0x70  
(__journal_remove_journal_head+0xb5/0x180 )
(T1/#12)<...>  2576 0 2 0001 000c [0002512920680599] 
0.002ms (+0.000ms): journal_free_journal_head+0xb/0x30  
(journal_remove_journal_head+0x3c/0x60 )
(T1/#13)<...>  2576 0 2 0001 000d [0002512920680736] 
0.002ms (+0.000ms): kmem_cache_free+0x14/0x60  
(journal_free_journal_head+0x1f/0x30 )
(T1/#14)<...>  2576 0 2 0001 000e [0002512920681179] 
0.002ms (+0.000ms): inverted_lock+0xb/0x50  
(journal_commit_transaction+0x333/0x1170 )
(T1/#15)<...>  2576 0 2 0001 000f [0002512920681438] 
0.002ms (+0.000ms): __journal_u

Re: Suspend-to-disk woes

[Russell Miller]

On Saturday 19 March 2005 13:29, Pavel Machek wrote:
> On So 19-03-05 12:20:35, Russell Miller wrote:
> > On Saturday 19 March 2005 05:26, Pavel Machek wrote:
> > > Checking that would be hard, but you might want to provide patch to
> > > check last-mounted dates of filesystems and panic if they changed.
> > >   Pavel
> >
> > Then how would you fix it?  There'd also have to be a way to reset it,
>
> boot with "noresume", then mkswap.
>   Pavel
Ah, makes sense.

I've never used the resume functionality, so my ignorance on that subject is 
understandable... :-)

--Russell

-- 

Russell Miller - [EMAIL PROTECTED] - Agoura, CA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: swsusp: Remove arch-specific references from generic code

[Pavel Machek]

Hi!


> swsusp-suspend_pd_pages-fix.patch

Could you drop this one? It is "fixing" unused macro, we don't want it
going anywhere.

> suspend-to-ram-update-videotxt-with-more-systems.patch
> 
> I've been ducking all the "swsusp_restore crap" patches.  Pavel, could you
> please aggregate, test and resend everything when the dust has settled?

Ok.


Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Suspend-to-disk woes

[Pavel Machek]

On So 19-03-05 12:20:35, Russell Miller wrote:
> On Saturday 19 March 2005 05:26, Pavel Machek wrote:
> 
> > Checking that would be hard, but you might want to provide patch to check
> > last-mounted dates of filesystems and panic if they changed.
> > Pavel
> 
> Then how would you fix it?  There'd also have to be a way to reset it, 

boot with "noresume", then mkswap.
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: swsusp: Remove arch-specific references from generic code

[Andrew Morton]

"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
>
> On Wednesday, 16 of March 2005 01:12, Pavel Machek wrote:
>  > Hi!
>  > 
>  > This is fix for "swsusp_restore crap"-: we had some i386-specific code
>  > referenced from generic code. This fixes it by inlining tlb_flush_all
>  > into assembly.
>  > 
>  > Please apply,
> 
>  Unfortunately, this patch requires the following fix.  Without it, swsusp 
> will
>  leak lots of memory on every resume.  Sorry for this bug, it was really dumb.

Just fyi, the only swsusp patches I currently have queued are

swsusp-add-missing-refrigerator-calls.patch
swsusp-suspend_pd_pages-fix.patch
suspend-to-ram-update-videotxt-with-more-systems.patch

I've been ducking all the "swsusp_restore crap" patches.  Pavel, could you
please aggregate, test and resend everything when the dust has settled?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clean up FIXME in do_timer_interrupt-lock fix

[Andrew Morton]

George Anzinger  wrote:
>
> Did you pick this up?  First sent on 3-11.

I did, although now looking at it I have issues.

>  I was not happy with the locking on this.  Two changes:
>  1) Turn off irq while setting the clock.
>  2) Call the timer code only through the timer interface 
> (set a short timer to do it from the ntp call).

I would consider this to be an inadequate description :(

>  Signed-off-by: George Anzinger 
> 
>   time.c |6 +++---
>   1 files changed, 3 insertions(+), 3 deletions(-)
> 
>  Index: linux-2.6.12-rc/arch/i386/kernel/time.c
>  ===
>  --- linux-2.6.12-rc.orig/arch/i386/kernel/time.c
>  +++ linux-2.6.12-rc/arch/i386/kernel/time.c
>  @@ -176,12 +176,12 @@ static int set_rtc_mmss(unsigned long no
>   int retval;
>   
>   /* gets recalled with irq locally disabled */
>  -spin_lock(&rtc_lock);
>  +spin_lock_irq(&rtc_lock);
>   if (efi_enabled)
>   retval = efi_set_rtc_mmss(nowtime);
>   else
>   retval = mach_set_rtc_mmss(nowtime);
>  -spin_unlock(&rtc_lock);
>  +spin_unlock_irq(&rtc_lock);
>   
>   return retval;
>   }

If the comment is correct, and this code is called with local irq's
disabled then this patch should be using spin_lock_irqsave()

>  @@ -338,7 +338,7 @@ static void sync_cmos_clock(unsigned lon
>   }
>   void notify_arch_cmos_timer(void)
>   {
>  -sync_cmos_clock(0);
>  +mod_timer(&sync_cmos_timer, jiffies + 1);
>   }
>   static long clock_cmos_diff, sleep_start;
>   

Your description says what this does, but it doesn't way why it was done?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: yenta_socket "nobody cared - Disabling IRQ #4" - WORKING!!

[Daniel Ritz]

On Saturday 19 March 2005 09:05, Jonas Oreland wrote:
> Hi again and thx again,
> 
> SUMMARY: It's working with new hook (wo/ trying second part)
>  I'll post again if error comes up again.

that's good news!

> 
> Daniel Ritz wrote:
> > On Saturday 19 March 2005 00:00, Jonas Oreland wrote:
> >>
> >>>it's the second time now i see this problem with an atheros chipset in
> >>>combination with a TI bridge. last time it was the 1225...
> >>>attached a patch that could help...
> >>>
> >>
> >>Report:
> >>1) It works somewhat better. irq doesn't get disabled.
> >>2) however wlan card get disfunctional. I haven't been able to contact my 
> >>wap
> >>   even if i'm standing on it...
> > 
> > 
> > i was afraid that it could have some side effects. it's probably because 
> > just
> > writing a 0 to the MFUNC register is stupid...can you try to replace 
> > ti12xx_hook()
> > in ti113x.h with this one?
> > 
> 
> yes, now it works!!! (limited testing)
> I tried rebooting plugging/unplugging/swsuspending maybe 6 times.
> All of them working, that a new record :-)
> 
> Should I try "second step" anyway?

not neccessarily..

> 
> >>3) unplug has resulted in kernel panic (twice)
> >>   (btw: how do I do to capture and report those)
> > 
> > 
> > at a first guess i would blame the atheros driver which taints the kernel.
> > so try _not_ loading the atheros driver and see if it still happens. if
> > so the messages please. to capture them you can use a serial console
> > (null modem cable to second pc). check out the "remote serial console"
> > howto on www.tldp.org
> 
> might be...the driver...haven't tried wo/ it.
> 
> note: I never got this after new hook,
> 
> > 
> > 
> >>4) when unlug don't produce kernel panic, then there is no way of 
> >>power-oning that card again.
> >>5) booting with the card inserted makes it not power on when yenta_socket 
> >>is loaded (module)
> > 
> > 
> > anything in dmesg then?
> 
> zero
> 
> >>comment: the card being disfunction could have something to with the driver.
> >>but before it worked sometimes...
> >>
> >>
> >>>--
> >>>
> >>>for TI bridges: turn off interrupts during card power-on. this seems
> >>>to be neccessary for some combination of TI bridges with at least CB cards
> >>>with atheros chipset...problem is that they produce an interrupt storm
> >>>during power-on so the kernel happens to disable the IRQ which is a bad
> >>>thing (tm).
> >>>adds a generic hook function so that a socket driver can hook into
> >>>almost anywhere (by adding more hook points of course). this is the
> >>>cleanest way i can think of. and it allows adding more workarounds
> >>>for more problems...
> >>>for the TI specific interrupt on-off stuff just save the MFUNC register
> >>>and set it to 0 to disable all interrupts, restore it afterwards.
> >>>
> >>>Signed-off-by: Daniel Ritz <[EMAIL PROTECTED]>
> >>
> >>Some thoughts: (not I'm neither pcmcia nor linux expert).
> >>
> >>The "irq storm", shouldn't that be "acked" in someway.
> >>I.e. the card produced a lot of irq's (that get ignored)
> >>isn't the "real" solution to capture them, and "do something clever"?
> >>
> >>Instead of just "shutting the card down".
> >>
> >>hmmm...wonder if that made sence
> > 
> > 
> > it's the CB device that is making the interrupt storm and the TI
> > bridge is stupid enough to let the interrupts thru during power
> > on. thing is you can't ack them at this time because the cardbus
> > resources are not set up at this time and ack'ing an IRQ is
> > device specifc.
> 
> ok
> 
> >>Question: Why do you think that it worked sometimes before?
> > 
> > 
> > pure luck?
> 
> How about 2.4? can you compare cs code with 2.6?
> It always worked in 2.4...

the problem is there also, it just doesn't show up. 2.6 checks for
every interrupt if one of the handlers took care of it. if not the
dump is printed and a counter is increased. if this counter reaches
a limit the interrupt line is disabled. 2.4 doesn't do it so the interrupt
storm is there too, it just recovers...you can try with 2.4...after you
have the card up do a "cat /proc/interrupts" and you'll see a high
number for yenta's interrupt line...

> 
> /Jonas
> 
> > can you also give me a dump of /proc/iomem?
> 
[snip /proc/iomem]

it was just to be sure nothing is mapped over existing physical RAM
which is not the case...

i'll cook up a more flexible patch which handles other TI bridges
as well (the current one will fail on some older controllers and
on 2-slot controllers)

rgds
-daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Nasty ReiserFS bug in 2.6.12-rc1, 2.6.12-rc1-bk1

[Bob Gill]

Hi.  I have built 2.6.12-rc1 and 2.6.12-rc1-bk1.  There seems to be a
nasty bug in ReiserFS (things are fine in 2.6.11.4).  The system wants
to un-configure my SCSI Adaptec devices, and stall at "starting Hal
daemon".  I also get the following error message (applied variously at
different times to different drives):
Mar 19 12:17:35 localhost kernel: ReiserFS: sdb1: using ordered data
mode
Mar 19 12:17:35 localhost kernel: ReiserFS: sdb1: journal params: device
sdb1, s ize 8192, journal first block 18, max trans len 1024, max batch
900, max commit age 30, max trans age 30
Mar 19 12:17:35 localhost kernel: ReiserFS: sdb1: checking transaction
log (sdb1 )
Mar 19 12:17:36 localhost kernel: ReiserFS: sdb1: Using r5 hash to sort
names
Mar 19 12:20:25 localhost su(pam_unix)[6809]: session opened for user
root by bo b(uid=500)
Mar 19 12:25:13 localhost kernel: Unable to handle kernel NULL pointer
dereferen ce at virtual address 000e
Mar 19 12:25:13 localhost kernel:  printing eip:
Mar 19 12:25:13 localhost kernel: c021c4af
Mar 19 12:25:13 localhost kernel: *pde = 
Mar 19 12:25:13 localhost kernel: Oops:  [#1]
Mar 19 12:25:13 localhost kernel: PREEMPT
Mar 19 12:25:13 localhost kernel: Modules linked in: nvidia agpgart imm
snd_emu1 0k1_synth snd_emux_synth snd_seq_oss raw1394
snd_seq_virmidi snd_seq_midi_emul snd_seq_midi snd_seq_midi_event
snd_seq_dummy snd_seq ipt_REJECT ipt_state ip_conntrack iptable_filter
ip_tables binfmt_misc s d_mod video thermal processor fan button battery
ac usblp ohci1394 ohci_hcd usbc
ore tuner
bttv video_buf i2c_algo_bit v4l2_common btcx_risc tveeprom videodev
i2c_sis96x i 2c_core snd_emu10k1 snd_rawmidi snd_seq_device
snd_ac97_codec snd_pcm_oss snd_mi xer_oss snd_pcm snd_timer
snd_page_alloc snd_util_mem snd_hwdep snd soundcore si s900 sbp2
scsi_mod ieee1394
Mar 19 12:25:13 localhost kernel: CPU:0
Mar 19 12:25:13 localhost kernel: EIP:0060:[]Tainted:
P  V LI
Mar 19 12:25:13 localhost kernel: EFLAGS: 00010086   (2.6.12-rc1)
Mar 19 12:25:13 localhost kernel: EIP is at as_find_arq_hash+0x38/0x7d
Mar 19 12:25:13 localhost kernel: eax: f751d000   ebx:    ecx:
0006   edx: f7b60a64
Mar 19 12:25:13 localhost kernel: esi: f7489e00   edi: f7b60d80   ebp:
0de8e63f   esp: d0373bd4
Mar 19 12:25:13 localhost kernel: ds: 007b   es: 007b   ss: 0068
Mar 19 12:25:13 localhost kernel: Process cc1 (pid: 6878,
threadinfo=d0372000 ta sk=e08c8a00)
Mar 19 12:25:13 localhost kernel: Stack: c1bf00ac d0473894 0de8e647
f7d26b4c d02 43a80  c021de95 f7b60d80
Mar 19 12:25:13 localhost kernel:0de8e63f 0020 c1bfc5d0
f7b60d80 000 0 f7d26b4c c1bf00ac 
Mar 19 12:25:13 localhost kernel:c02188f5 c1bf00ac d0373c34
d0243a80 000 0 0de8e63f 0008 0008
Mar 19 12:25:13 localhost kernel: Call Trace:
Mar 19 12:25:13 localhost kernel:  [] as_merge+0x64/0x1ad
Mar 19 12:25:13 localhost kernel:  [] __make_request
+0xac/0x4ed
Mar 19 12:25:13 localhost kernel:  [] generic_make_request
+0x90/0x1ff
Mar 19 12:25:13 localhost kernel:  [] bio_alloc_bioset
+0x10f/0x1bf
Mar 19 12:25:13 localhost kernel:  [] autoremove_wake_function
+0x0/0x4 b
Mar 19 12:25:13 localhost kernel:  [] autoremove_wake_function
+0x0/0x4 b
Mar 19 12:25:13 localhost kernel:  [] do_mpage_readpage
+0x28e/0x3c7
Mar 19 12:25:13 localhost kernel:  [] submit_bio+0x4d/0xdc
Mar 19 12:25:13 localhost kernel:  [] radix_tree_insert
+0x83/0x12a
Mar 19 12:25:13 localhost kernel:  [] __pagevec_lru_add
+0xde/0x107
Mar 19 12:25:13 localhost kernel:  [] mpage_bio_submit
+0x2b/0x32
Mar 19 12:25:13 localhost kernel:  [] mpage_readpages
+0xd3/0x173
Mar 19 12:25:13 localhost kernel:  [] reiserfs_get_block
+0x0/0x1530
Mar 19 12:25:13 localhost kernel:  [] read_pages+0x13f/0x14f
Mar 19 12:25:13 localhost kernel:  [] reiserfs_get_block
+0x0/0x1530
Mar 19 12:25:13 localhost kernel:  [] __alloc_pages
+0x173/0x3e1
Mar 19 12:25:13 localhost kernel:  []
__do_page_cache_readahead+0x14c/ 0x183
Mar 19 12:25:13 localhost kernel:  [] filemap_nopage
+0x29a/0x3d9
Mar 19 12:25:13 localhost kernel:  [] filemap_nopage+0x0/0x3d9
Mar 19 12:25:13 localhost kernel:  [] do_no_page+0xaf/0x3a5
Mar 19 12:25:13 localhost kernel:  [] pte_alloc_map+0x99/0xbe
Mar 19 12:25:13 localhost kernel:  [] handle_mm_fault
+0x16e/0x1b0
Mar 19 12:25:13 localhost kernel:  [] do_page_fault
+0x1c5/0x5c7
Mar 19 12:25:13 localhost kernel:  [] do_mmap_pgoff
+0x4a7/0x78e
Mar 19 12:25:13 localhost kernel:  [] sys_mmap2+0x7a/0xa9
Mar 19 12:25:13 localhost kernel:  [] do_page_fault+0x0/0x5c7
Mar 19 12:25:13 localhost kernel:  [] error_code+0x2b/0x30
Mar 19 12:25:13 localhost kernel: Code: 24 1c 89 e8 8b 57 30 c1 e8 03 69
c0 01 0 0 37 9e c1 e8 1a 8d 34 c2 8b 1e 39 f3 74 2c 8d 53 e4 8b 1b 8b 42
24 8b 4a 14 85 c0 74 3b <8b> 41 08 a8 6c 75 04 a8 10 75 1c 89 54 24 04
8b 07 89 04 24 e8
Mar 19 12:25:13 localhost kernel:  <6>note: cc1[6878] exited with
preempt_count
1
Mar 19 12:25:13 localhost kernel: scheduling while atomic:
cc1/0x1001/6878
Mar 19 12

Re: Relayfs question

[Jan Engelhardt]

>> Ok, urandom was a bad example. I have my tty logger (ttyrpld.sf.net) which 
>> moves a lot of data (depends) to userspace. It uses a ring buffer [...]
>[...]
>Basically, all the transport code you are doing in the kernel side of
>your logger would be taken care of by relayfs. And given that there are
>a lot of people doing similar ad-hoc buffering code, it just makes
>sense to have one well-tested yet generic mechanism. Have a look at
>Documentation/filesystems/relayfs.txt for the API details.

Well, what about things like urandom? It also moves "a lot" of data and does
nothing else.

>[...]
>Just to avoid any confusion, note that I'm referring mainly to rpldev.c,
>which is the kernel-side driver for the logger, I haven't looked at any
>of the user tools.

The userspace daemon just read()s the device and analyzes it. Nothing to
optimize there, with respect to relayfs, I think.



Jan Engelhardt
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: pwc driver in -mm kernels

[Greg KH]

On Sat, Mar 19, 2005 at 02:04:24PM +0100, Norbert Preining wrote:
> Hi Andrew, hi Luc!
> 
> I just realized that there is now the pwc driver back in -mm kernels,
> but interestingly not the one from Luc, or at least not the last
> published one (10.0.6). and wanted to ask if there is a specific reason
> for this?

Because that is the version that was submitted for inclusion.  Patches
are gladly accepted to bring the driver up to date.

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Relayfs question

[Karim Yaghmour]

Karim Yaghmour wrote:
> What relayfs does, and does very well, is move very large amounts of
> data out of the kernel and make them available to user-space with very
> little overhead. In the actual case of your tty logger, I've browsed
> through the code briefly, and I think that with relayfs you should be
> able to:

Just to avoid any confusion, note that I'm referring mainly to rpldev.c,
which is the kernel-side driver for the logger, I haven't looked at any
of the user tools.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

NULL pointer bug in netpoll.c

[Jan Kiszka]

Hi,
it seems that there is a gremlin sleeping in 
net/core/netpoll.c:find_skb(). Even if no more buffers are available 
through "skbs", "skb" is dereferenced anyway. The tiny patch should fix it.

Jan
--- linux-2.6.11.4/net/core/netpoll.c.orig  2005-03-16 01:09:19.0 
+0100
+++ linux-2.6.11.4/net/core/netpoll.c   2005-03-19 21:42:41.573018776 +0100
@@ -165,10 +165,11 @@ repeat:
if (!skb) {
spin_lock_irqsave(&skb_list_lock, flags);
skb = skbs;
-   if (skb)
+   if (skb) {
skbs = skb->next;
-   skb->next = NULL;
-   nr_skbs--;
+   skb->next = NULL;
+   nr_skbs--;
+   }
spin_unlock_irqrestore(&skb_list_lock, flags);
}
 

Re: Relayfs question

[Karim Yaghmour]

Jan Engelhardt wrote:
> Ok, urandom was a bad example. I have my tty logger (ttyrpld.sf.net) which 
> moves a lot of data (depends) to userspace. It uses a ring buffer of "fixed" 
> size (set at module load time). Apart from that relayfs could use a dynamic 
> sized ring buffer, I would not see any need to move it to relayfs, would you?

First, please note that the info on Opersys' site is out-of-date. While
it was relevant while we were still maintaining relayfs separately, it
has somewhat lost its relevance since we started posting the most up-to-
date code directly to LKML. For one thing, the dynamic resizing was
dropped very early in relayfs' inclusion review.

What relayfs does, and does very well, is move very large amounts of
data out of the kernel and make them available to user-space with very
little overhead. In the actual case of your tty logger, I've browsed
through the code briefly, and I think that with relayfs you should be
able to:
- Get rid of half the code:
  - No need to manage your own user/kernel-buffer boundary (Most of the
code in uio_*()).
  - No need to do any buffer management at all.
- Get better performance out of your logging functions.
- Get per-cpu buffers for free.

Basically, all the transport code you are doing in the kernel side of
your logger would be taken care of by relayfs. And given that there are
a lot of people doing similar ad-hoc buffering code, it just makes
sense to have one well-tested yet generic mechanism. Have a look at
Documentation/filesystems/relayfs.txt for the API details.

On a separate yet related topic:
Looking closer at rpldev.c, I believe that you'll be able to get rid of
it entirely (or very close to) once I actually get the time to refactor
the tracing code in LTT to make it generic. What I intend to do is to
obsolete the need for functions like your kio_*, and make it all
automatically generated at build time (you'll still to add the
instrumentation, but won't need to hand-code the callbacks). This is
still on the top of my to-do list and I should be able to get to this
shortly.

Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || [EMAIL PROTECTED] || 1-866-677-4546
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] _raw_read_trylock for alpha

[Jeff Garzik]

alpha SMP doesn't build, due to lack of _raw_read_trylock().

Patch below completely untested...  needs review and testing.

One could also use the arch-neutral generic_raw_read_trylock(),
but that implementation is rather lame (it spins).  I'm amazed at the
number of arches that use the generic implementation, since the generic
version isn't really a "trylock".

Don't send this patch upstream until its been verified to actually work.

Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>


diff -ur ../kernel-2.6.11.orig/linux-2.6.11/include/asm-alpha/spinlock.h 
linux-2.6.11/include/asm-alpha/spinlock.h
--- ../kernel-2.6.11.orig/linux-2.6.11/include/asm-alpha/spinlock.h 
2005-03-02 02:38:12.0 -0500
+++ linux-2.6.11/include/asm-alpha/spinlock.h   2005-03-19 03:26:11.0 
-0500
@@ -153,6 +153,29 @@
 }
 #endif /* CONFIG_DEBUG_RWLOCK */
 
+static inline int _raw_read_trylock(rwlock_t * lock)
+{
+   long regx;
+   int success;
+
+   __asm__ __volatile__(
+   "1: ldl_l   %1,%0\n"
+   "   lda %2,0\n"
+   "   blbs%1,6f\n"
+   "   subl%1,2,%1\n"
+   "   stl_c   %1,%0\n"
+   "   beq %1,6f\n"
+   "   lda %2,1\n"
+   "4: mb\n"
+   ".subsection 2\n"
+   "6: br  1b\n"
+   ".previous"
+   : "=m" (*lock), "=&r" (regx), "=&r" (success)
+   : "m" (*lock) : "memory");
+
+   return success;
+}
+
 static inline int _raw_write_trylock(rwlock_t * lock)
 {
long regx;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [patch] arch hook for notifying changes in PTE protections bits

[David Mosberger]

> On Sat, 19 Mar 2005 12:22:20 -0800, "Seth, Rohit" <[EMAIL PROTECTED]> 
> said:

  Rohit> David S. Miller  wrote on Friday,
  Rohit> March 18, 2005 8:06 PM:

  >>  Take a look at set_pte_at().  You get the "mm", the virtual
  >> address, the pte pointer, and the new pte value.


  Rohit> Thanks for pointing out the updated interface in 2.6.12-*
  Rohit> kernel.  I think I can overload the arch specific part of
  Rohit> set_pte_at(or for that matter set_pte, as what I need is only
  Rohit> pte_t) to always check if we need to do lazy I/D coherency
  Rohit> for IA-64.but this incurs extra cost for making a check
  Rohit> every time set_pte_at is called.  This new hook,
  Rohit> lazy_mmu_prot_update, though needs to be used only when the
  Rohit> permissions on a valid PTE is changing. For example, at the
  Rohit> time of remap or swap, this API is not called.

Careful though: not every PTE has an associated page_map entry.

I agree about your concern about cost.  Accessing the page_map is
expensive (integer division + memory access) and we have to do that in
order to find out if the page is i-cache clean.

--david
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [patch] arch hook for notifying changes in PTE protections bits

[Seth, Rohit]

David S. Miller  wrote on Friday, March 18,
2005 8:06 PM:

> 
> Take a look at set_pte_at().  You get the "mm", the
> virtual address, the pte pointer, and the new pte value.
> 

Thanks for pointing out the updated interface in 2.6.12-* kernel.  I
think I can overload the arch specific part of set_pte_at(or for that
matter set_pte, as what I need is only pte_t) to always check if we need
to do lazy I/D coherency for IA-64.but this incurs extra cost for
making a check every time set_pte_at is called.  This new hook,
lazy_mmu_prot_update, though needs to be used only when the permissions
on a valid PTE is changing. For example, at the time of remap or swap,
this API is not called.
  
> What else could you possibly need to track stuff like this
> and react appropriately? :-)
> 

Stuff is there, though the call needs to be made to ensure we are
reacting to it most optimally and correctly.I guess something
similar to why update_mmu_cache API is still existing in generic part
and not overloading arch specific set_pte_at definition.


-rohit
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Suspend-to-disk woes

[Russell Miller]

On Saturday 19 March 2005 05:26, Pavel Machek wrote:

> Checking that would be hard, but you might want to provide patch to check
> last-mounted dates of filesystems and panic if they changed.
>   Pavel

Then how would you fix it?  There'd also have to be a way to reset it, 
otherwise the kernel will never boot again.  Perhaps an argument to the 
kernel that allows for resetting of the mechanism?

--Russell

-- 

Russell Miller - [EMAIL PROTECTED] - Agoura, CA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] net/bluetooth/rfcomm/core.: make a variable static

[Marcel Holtmann]

Hi Adrian,

> This patch makes a needlessly global variable static.

the patch is in my tree now. Thanks.

Regards

Marcel


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.12-rc1 report

[Gene Heskett]

Greetings;

Usually I come looking for a bone when I post here, but today its with 
verbal flowers in hand.

I just built 2.6.12-rc1 and I'm pleased to report that the ieee1394 
problems that required the bk-ieee1394.patch previously are 
apparently alleviated.  Kino worked as expected, including the audio 
from the cameras microphones.

tvtime, with my pcHDTV-3000 card, had a miss-cue due to the wrong 
modprobe statement in my rc.local, so I cleaned out those modules 
that it had loaded, and reloaded them with the 'modprobe cx88_dvb' 
statement, which brought that up with working video but raw noise for 
audio at about +40db!  Going into its menu's for tv standards I chose 
to 'restart with new values' without changing anything which restored 
the audio to normal.  Thats happened before, and Jack tells me there 
will be another coding session this weekend so there will no doubt be 
more patches for that.  This FWIW, was without actually installing 
either version of his drivers, so this is nice progress.

My scanner works normally. As does the spca5xx stuffs that I did 
install again after the boot.

This just plain feels good under my fngertips, even kmails curser 
motions are as expected, but that lag comes and goes according to the 
number of bees around the crocus's in the front yard, or some such 
mysticly quasi random control.  I don't have any idea about how much 
faster the machine is in fact, but it sure feels snappier, a lot 
snappier.

So, a smart tip of the hat to all the patchers, this is seeable, 
feelable, progress.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

race between __sync_single_inode() and iput()/bdev_clear_inode()

[OGAWA Hirofumi]

Hi,

EIP is at filemap_fdatawait+0xe/0x80
eax: e7461ad8   ebx:    ecx: 0001   edx: 
esi: e5334c40   edi: 6b6b6b6b   ebp: de239e88   esp: de239e70
ds: 007b   es: 007b   ss: 0068
Process fsstress (pid: 31048, threadinfo=de239000 task=e60cd020)
Stack: e7d34358 de239e88 c01834f7  e5334c40 e7461ad8 de239eb0 c01836bf 
   e7461ad8 0001  0001 e7f0eac8 e5334c40 e7f0eac8 e7d2ddf4 
   de239f0c c0183777 e5334c40 de239f4c e5334c40 e7f0eac8 e7d2ddf4 de239f0c 
Call Trace:
 [show_stack+127/160] show_stack+0x7f/0xa0
 [show_registers+351/464] show_registers+0x15f/0x1d0
 [die+244/384] die+0xf4/0x180
 [do_page_fault+886/1749] do_page_fault+0x376/0x6d5
 [error_code+43/48] error_code+0x2b/0x30
 [__sync_single_inode+447/512] __sync_single_inode+0x1bf/0x200
 [__writeback_single_inode+119/352] __writeback_single_inode+0x77/0x160
 [sync_sb_inodes+452/736] sync_sb_inodes+0x1c4/0x2e0
 [sync_inodes_sb+126/144] sync_inodes_sb+0x7e/0x90
 [sync_inodes+140/176] sync_inodes+0x8c/0xb0
 [do_sync+90/144] do_sync+0x5a/0x90
 [sys_sync+18/32] sys_sync+0x12/0x20
 [syscall_call+7/11] syscall_call+0x7/0xb
Code: ab 89 1c 24 8b 75 e4 8b 45 ec 89 74 24 08 89 44 24 04 e8 16 fd ff ff eb 
93 8d 74 26 00 55 89 e5 57 56 53 83 ec 0c 8b 45 08 8b 38 <8b> 97 5c 01 00 00 8d 
b6 00 00 00 00 8d bf 00 00 00 00 89 d0 f0

Dump of assembler code for function filemap_fdatawait:
0xc013e290 :  push   %ebp
0xc013e291 :  mov%esp,%ebp
0xc013e293 :  push   %edi
0xc013e294 :  push   %esi
0xc013e295 :  push   %ebx
0xc013e296 :  sub$0xc,%esp
0xc013e299 :  mov0x8(%ebp),%eax <- %eax is mapping
0xc013e29c : mov(%eax),%edi<- %edi is 
mapping->host
0xc013e29e : mov0x15c(%edi),%edx   <- Oops here
0xc013e2a4 : lea0x0(%esi),%esi


I got the above Oops while doing fs stress test.

The cause of this was race condition between __sync_single_inode() and
iput()/bdev_clear_inode().

This race seems following condition.

  cpu0 (fs's inode) cpu1 (bdev's inode)

   close("/dev/hda2")
   [...]
__sync_single_inode()
   /* copy the bdev's ->i_mapping */
   mapping = inode->i_mapping;

   generic_forget_inode()
  bdev_clear_inode()
 /* restre the fs's ->i_mapping */
 inode->i_mapping = &inode->i_data;
  /* bdev's inode was freed */
  destroy_inode(inode);

   if (wait) {
  /* dereference a freed bdev's mapping->host */
  filemap_fdatawait(mapping);  /* Oops */


I wrote the attached patch for making sure fs's inode is not in
__sync_single_inode().

What do you think of this?

Thanks.
-- 
OGAWA Hirofumi <[EMAIL PROTECTED]>


Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---

 fs/block_dev.c|   27 ++-
 fs/fs-writeback.c |   34 --
 2 files changed, 46 insertions(+), 15 deletions(-)

diff -puN fs/block_dev.c~bdev-inode-sync fs/block_dev.c
--- linux-2.6.12-rc1/fs/block_dev.c~bdev-inode-sync 2005-03-20 
02:59:24.0 +0900
+++ linux-2.6.12-rc1-hirofumi/fs/block_dev.c2005-03-20 03:59:54.0 
+0900
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 struct bdev_inode {
@@ -282,11 +283,35 @@ static inline void __bd_forget(struct in
 
 static void bdev_clear_inode(struct inode *inode)
 {
+   extern void wait_inode_ilock(struct inode *inode);
struct block_device *bdev = &BDEV_I(inode)->bdev;
struct list_head *p;
+   struct inode *i;
+
spin_lock(&bdev_lock);
while ( (p = bdev->bd_inodes.next) != &bdev->bd_inodes ) {
-   __bd_forget(list_entry(p, struct inode, i_devices));
+   inode = list_entry(p, struct inode, i_devices);
+   i = igrab(inode);
+   spin_unlock(&bdev_lock);
+   /*
+* Preparation for changeing the ->i_mapping.  Make
+* sure this inode is not in __sync_single_inode().
+*/
+   if (i) {
+   spin_lock(&inode_lock);
+   wait_inode_ilock(i);
+   inode->i_state |= I_LOCK;
+   spin_unlock(&inode_lock);
+   }
+   spin_lock(&bdev_lock);
+   spin_lock(&inode_lock);
+   if (i) {
+   inode->i_state &= ~I_LOCK;
+   wake_up_inode(i);
+   iput(i);
+   }
+   __bd_forget(inode);
+   spin_unlock(&inode_lock);
}
list_del_init(&bdev->bd_list);
spin_unlock(&bdev_lock);
diff -puN fs/fs-writeback.c~bdev-in

Re: [patch 01/10] char/ds1620: use msleep() instead of schedule_timeout()

[Russell King]

On Sat, Mar 19, 2005 at 02:17:15PM +0100, [EMAIL PROTECTED] wrote:
> Not sure why any driver needs to sleep for *two* ticks, so let's fix it.
> 
> Use msleep() instead of schedule_timeout() to guarantee the
> task delays as expected. Signals are never checked for by the callers or
> in the function itself, so use TASK_UNINTERRUPTIBLE instead of
> TASK_INTERRUPTIBLE. The delay is presumed to have been written when HZ==100,
> and thus has been multiplied by 10 to pass to msleep().
> 
> Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>

Acked-by: Russell King <[EMAIL PROTECTED]>

> ---
> 
> 
>  kj-domen/drivers/char/ds1620.c |3 +--
>  1 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff -puN drivers/char/ds1620.c~msleep-drivers_char_ds1620 
> drivers/char/ds1620.c
> --- kj/drivers/char/ds1620.c~msleep-drivers_char_ds1620   2005-03-18 
> 20:05:09.0 +0100
> +++ kj-domen/drivers/char/ds1620.c2005-03-18 20:05:09.0 +0100
> @@ -163,8 +163,7 @@ static void ds1620_out(int cmd, int bits
>   netwinder_ds1620_reset();
>   netwinder_unlock(&flags);
>  
> - set_current_state(TASK_INTERRUPTIBLE);
> - schedule_timeout(2);
> + msleep(20);
>  }
>  
>  static unsigned int ds1620_in(int cmd, int bits)
> _
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2.4.30-pre3] x86_64: pci_alloc_consistent() match 2.6 implementation

[Andi Kleen]

On Fri, Mar 18, 2005 at 03:23:44PM -0600, Matt Domsch wrote:
> For review and comment.
> 
> On x86_64 systems with no IOMMU and with >4GB RAM (in fact, whenever
> there are any pages mapped above 4GB), pci_alloc_consistent() falls
> back to using ZONE_DMA for all allocations, even if the device's
> dma_mask could have supported using memory from other zones.  Problems
> can be seen when other ZONE_DMA users (SWIOTLB, scsi_malloc()) consume
> all of ZONE_DMA, leaving none left for pci_alloc_consistent() use.
> 
> Patch below makes pci_alloc_consistent() for the nommu case (EM64T
> processors) match the 2.6 implementation of dma_alloc_coherent(), with
> the exception that this continues to use GFP_ATOMIC.

You fixed the wrong code. The pci-nommu code is only used
when IOMMU is disabled in the Kconfig. But most kernels have
it enabled. You would need to change it in pci-gart.c too.
 
The reason it is like this that nommu was always intended as a hackish kludge
that would be only used for debugging - little did we know that
it would become standard later.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Suspend-to-disk woes

[Pavel Machek]

Hi!

> Hello, I experienced a pretty nasty problem a couple of days back:
> 
> I ran 2.6.11-ck1 and built 2.6.11-ck2. The last thing I did before 
> booting the new kernel was to suspend-to-disk the old kernel 
> (something I usually do as I'm working on this laptop).
> I ran the new kernel a couple of days and decided to boot the old 
> kernel to do some performance tests. Imagine my dread as the old 
> kernel instead of detecting that the system has booted another kernel 
> just reloads the old suspend-to-disk image. The result is that after 
> succesfully resuming, my harddrive goes bonkers and starts to work. 
> After a couple of minutes the whole kernel hangs. I reboot and try to 
> boot the -ck2 kernel again only to find that the system complains as 
> it finds missing nodes. The reisertools try to rebuild the system 
> unsucessully. The --rebuild-tree parameter worked but a lot of files 
> were still missing. In the end I had to reinstall the whole system as 
> it went so unstable.
> 
> My question is: Why isn't there a check before resuming a 
> suspend-to-disk image if the system has booted another kernel since 
> the suspend to prevent this kind of hassle?

Checking that would be hard, but you might want to provide patch to check
last-mounted dates of filesystems and panic if they changed.
Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Build issue current MIPS - RaQ2

[Jim Gifford]

I have not been able to build kernels since 2.6.9 on my RaQ2 for some 
time. I have tried the linux-mips.org port and the current 2.6.11.5 
release. I keep getting the same error.

 Building modules, stage 2.
 MODPOST
*** Warning: "pci_iounmap" [drivers/net/tulip/tulip.ko] undefined!
*** Warning: "pci_iomap" [drivers/net/tulip/tulip.ko] undefined!
with Make V=1
 Building modules, stage 2.
make -rR -f /usr/src/linux-2.6.11.5/scripts/Makefile.modpost
 scripts/mod/modpost   -o /usr/src/linux-2.6.11.5/Module.symvers 
vmlinux drivers/block/loop.o drivers/block/rd.o drivers/cdrom/cdrom.o 
drivers/char/rtc.o drivers/net/tulip/tulip.o drivers/scsi/scsi_mod.o 
drivers/scsi/scsi_transport_spi.o drivers/scsi/sd_mod.o 
drivers/scsi/sr_mod.o drivers/scsi/st.o 
drivers/scsi/sym53c8xx_2/sym53c8xx.o fs/exportfs/exportfs.o 
fs/isofs/isofs.o fs/lockd/lockd.o fs/nfs/nfs.o fs/nfsd/nfsd.o 
fs/nls/nls_ascii.o fs/nls/nls_base.o fs/nls/nls_cp437.o 
fs/nls/nls_iso8859-1.o fs/nls/nls_utf8.o fs/smbfs/smbfs.o lib/crc32.o 
lib/zlib_inflate/zlib_inflate.o net/key/af_key.o 
net/netlink/netlink_dev.o net/packet/af_packet.o net/sunrpc/sunrpc.o 
net/unix/unix.o
*** Warning: "pci_iounmap" [drivers/net/tulip/tulip.ko] undefined!
*** Warning: "pci_iomap" [drivers/net/tulip/tulip.ko] undefined!

Now it seems to me that the Makefile.modpost would need to include 
arch/mips/lib/iomap.o file to correct this issue, but that doesn't seem 
like the correct thing to do, and I have no clue on how to do that.

--

Jim Gifford
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Relayfs question

[Jan Engelhardt]

Hi,

>[...]
> The current method is to just manage buffers and enable applications to mmap
> the buffers to read them with some signalling on when a buffer is to be read
> and when the kernel can overwrite it.
>
> A character device is unlikely to need such interface since you do want 16
> bytes of random data and not several pages of mapped random numbers. If you
> really need a lot of random numbers you need something in user-space anyway
> since you'll deplete the kernel entropy pool pretty fast anyway.
>
> If you have a device that needs to transfer lots of data doesn't mind it being
> batched and doesn't really need the character device interface then relayfs
> could be useful.

Ok, urandom was a bad example. I have my tty logger (ttyrpld.sf.net) which 
moves a lot of data (depends) to userspace. It uses a ring buffer of "fixed" 
size (set at module load time). Apart from that relayfs could use a dynamic 
sized ring buffer, I would not see any need to move it to relayfs, would you?



Jan Engelhardt
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-00

[Ingo Molnar]

i have released the -V0.7.41-00 Real-Time Preemption patch (merged to
2.6.12-rc1), which can be downloaded from the usual place:

  http://redhat.com/~mingo/realtime-preempt/

the biggest change in this patch is the merge of Paul E. McKenney's
preemptable RCU code. The new RCU code is active on PREEMPT_RT. While it
is still quite experimental at this stage, it allowed the removal of
locking cruft (mainly in the networking code), so it could solve some of
the longstanding netfilter/networking deadlocks/crashes reported by a
number of people. Be careful nevertheless.

there are a couple of minor changes relative to Paul's latest
preemptable-RCU code drop:

 - made the two variants two #ifdef blocks - this is sufficient for now
   and we'll see what the best way is in the longer run.

 - moved rcu_check_callbacks() from the timer IRQ to ksoftirqd. (the
   timer IRQ still runs in hardirq context on PREEMPT_RT.)

 - changed the irq-flags method to a preempt_disable()-based method, and
   moved the lock taking outside of the critical sections. (due to locks
   potentially sleeping on PREEMPT_RT).

to create a -V0.7.41-00 tree from scratch, the patching order is:

  http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2
  http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc1.bz2
  
http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc1-V0.7.41-00

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.11-rc3: APM resume problems with USB

[Matt Mackall]

On Sat, Mar 19, 2005 at 01:44:24AM -0800, Jeremy Fitzhardinge wrote:
> On my IBM ThinkPad X31, I can only do one successful APM resume.  After 
> the resume, there's a stream of messages on the console:
> 
> uhci_hcd :00:1d.0: host controller process error, something bad 
> happened!
> uhci_hcd :00:1d.0: host system error, PCI problems?
> uhci_hcd :00:1d.0: host controller process error, something bad 
> happened!
> uhci_hcd :00:1d.0: host system error, PCI problems?
> uhci_hcd :00:1d.0: host controller process error, something bad 
> happened!
> uhci_hcd :00:1d.0: host system error, PCI problems?
> uhci_hcd :00:1d.0: host controller process error, something bad 
> happened!
> uhci_hcd :00:1d.0: host system error, PCI problems?
> uhci_hcd :00:1d.0: host controller process error, something bad 
> happened!
> uhci_hcd :00:1d.0: host system error, PCI problems?
> uhci_hcd :00:1d.0: host controller process error, something bad 
> happened!
> uhci_hcd :00:1d.0: host system error, PCI problems?
> 
> 
> The second resume, the machine panics.  I haven't managed to get the 
> panic message yet.
> 
> This happens with both -rc3 and -rc4.

I think you mean -mm[34]. I've seen the problem with -mm3, 2.6.11{,.3}
seem to be fine. Also ACPI rather than APM is fine as well though the
suspend life is pathetic.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Relayfs question

[Baruch Even]

Jan Engelhardt wrote:
according to the relayfs description on opersys.com,
|As the Linux kernel matures, there is an ever increasing number of facilities
|and tools that need to relay large amounts of data from kernel space to user
|space. Up to this point, each of these has had its own mechanism for relaying
|data. To supersede the individual mechanisms, we introduce the "high-speed
|data relay filesystem" (relayfs). As such, things like LTT, printk, EVLog,
|etc.
This sounds to me like it would obsolete most character-based devices, e.g.
random and urandom.
What do the relayfs developers say to this?
I'm not a relayfs developer, just a happy user...
The latest relayfs versions are slimmed down of the original and are 
unlikely to be useful as a character-based device, but are much better 
as a data-transport facility.

There is no longer any interface for character based reading so it can't 
be used for the device replace purposes.

The current method is to just manage buffers and enable applications to 
mmap the buffers to read them with some signalling on when a buffer is 
to be read and when the kernel can overwrite it.

A character device is unlikely to need such interface since you do want 
16 bytes of random data and not several pages of mapped random numbers. 
If you really need a lot of random numbers you need something in 
user-space anyway since you'll deplete the kernel entropy pool pretty 
fast anyway.

If you have a device that needs to transfer lots of data doesn't mind it 
being batched and doesn't really need the character device interface 
then relayfs could be useful.

Baruch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops in 2.6.10 (EIP is at hid_init_reports+0x151/0x1d0 [usbhid])

[Ralf Hildebrandt]

* Andrew Morton <[EMAIL PROTECTED]>:
> 
> Could you please test 2.6.11 or, even better, 2.6.12-rc1?

I will do that, once Debian has such a kernel :|

-- 
Ralf Hildebrandt (i.A. des IT-Zentrum)  [EMAIL PROTECTED]
Charite - Universitätsmedizin BerlinTel.  +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-BerlinFax.  +49 (0)30-450 570-962
IT-Zentrum Standort CBF send no mail to [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] remove redundant NULL check before before kfree() in kernel/sysctl.c

[Jesper Juhl]

Tiny patch to remove a redundant check for NULL pointer before calling kfree().

Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>

diff -up linux-2.6.11-mm4-orig/kernel/sysctl.c linux-2.6.11-mm4/kernel/sysctl.c
--- linux-2.6.11-mm4-orig/kernel/sysctl.c   2005-03-16 15:45:40.0 
+0100
+++ linux-2.6.11-mm4/kernel/sysctl.c2005-03-19 19:52:18.0 +0100
@@ -991,8 +991,7 @@ int do_sysctl(int __user *name, int nlen
int error = parse_table(name, nlen, oldval, oldlenp, 
newval, newlen, head->ctl_table,
&context);
-   if (context)
-   kfree(context);
+   kfree(context);
if (error != -ENOTDIR)
return error;
tmp = tmp->next;


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Building Areca arcmsr driver outside kernel source tree

[Matt Dainty]

To get the arcmsr driver working with CentOS/RHEL 4 and using the
facility to build kernel modules outside of the kernel source tree, I
found the attached patch was necessary to remove the dependencies on the
internal drivers/scsi/scsi*.h header files and to instead use the public
ones found under include/scsi/ which are provided by the kernel-*-devel
packages.

It builds, loads and appears to work with my limited testing on an
ARC1120. I was just wanting to know if this was the right way to fix it?
Once the driver is in the main kernel tree it's largely irrelevant, but
while CentOS/RHEL 4 use the older kernel without the driver it's a PITA
to maintain kernel packages with this one driver added, when a separate
package containing just the driver is much easier.

The patch is based on the 1.20.00.06 driver that was added to
2.6.11-mm4.

Thanks

Matt
--- linux-2.6.9/drivers/scsi/arcmsr/arcmsr.c.orig	2005-03-19 17:50:52.623490488 +
+++ linux-2.6.9/drivers/scsi/arcmsr/arcmsr.c	2005-03-19 18:03:11.484166592 +
@@ -108,7 +108,9 @@
 #include 
 #include 
 #include 
-#include "../scsi.h"
+#include 
+#include 
+#include 
 #include "arcmsr.h"
 #endif
 /*
@@ -138,10 +140,11 @@
 			 struct block_device *bdev, sector_t capacity,
 			 int *info);
 static int arcmsr_release(struct Scsi_Host *);
-static int arcmsr_queue_command(Scsi_Cmnd * cmd, void (*done) (Scsi_Cmnd *));
-static int arcmsr_cmd_abort(Scsi_Cmnd *);
-static int arcmsr_bus_reset(Scsi_Cmnd *);
-static int arcmsr_ioctl(Scsi_Device * dev, int ioctl_cmd, void *arg);
+static int arcmsr_queue_command(struct scsi_cmnd * cmd,
+void (*done) (struct scsi_cmnd *));
+static int arcmsr_cmd_abort(struct scsi_cmnd *);
+static int arcmsr_bus_reset(struct scsi_cmnd *);
+static int arcmsr_ioctl(struct scsi_device * dev, int ioctl_cmd, void *arg);
 static int __devinit arcmsr_device_probe(struct pci_dev *pPCI_DEV,
 	 const struct pci_device_id *id);
 static void arcmsr_device_remove(struct pci_dev *pPCI_DEV);
@@ -152,7 +155,7 @@
 static u_int8_t arcmsr_wait_msgint_ready(PACB pACB);
 static const char *arcmsr_info(struct Scsi_Host *);
 
-static Scsi_Host_Template arcmsr_scsi_host_template = {
+static struct scsi_host_template arcmsr_scsi_host_template = {
 	.module = THIS_MODULE,
 	.proc_name = "arcmsr",
 	.proc_info = arcmsr_proc_info,
@@ -417,7 +420,7 @@
 
 
 */
-static int arcmsr_scsi_host_template_init(Scsi_Host_Template * psht)
+static int arcmsr_scsi_host_template_init(struct scsi_host_template * psht)
 {
 	psht->proc_name = "arcmsr";
 	memset(pHCBARC, 0, sizeof(struct _HCBARC));
@@ -459,19 +462,19 @@
 static void arcmsr_pci_unmap_dma(PCCB pCCB)
 {
 	PACB pACB = pCCB->pACB;
-	Scsi_Cmnd *pcmd = pCCB->pcmd;
+	struct scsi_cmnd *pcmd = pCCB->pcmd;
 
 	if (pcmd->use_sg != 0) {
 		struct scatterlist *sl;
 
 		sl = (struct scatterlist *)pcmd->request_buffer;
 		pci_unmap_sg(pACB->pPCI_DEV, sl, pcmd->use_sg,
-			 scsi_to_pci_dma_dir(pcmd->sc_data_direction));
+			 pcmd->sc_data_direction);
 	} else if (pcmd->request_bufflen != 0) {
 		pci_unmap_single(pACB->pPCI_DEV,
  (dma_addr_t) (unsigned long)pcmd->SCp.ptr,
  pcmd->request_bufflen,
- scsi_to_pci_dma_dir(pcmd->sc_data_direction));
+ pcmd->sc_data_direction);
 	}
 	return;
 }
@@ -575,7 +578,7 @@
 **
 **
 */
-static void arcmsr_cmd_done(Scsi_Cmnd * pcmd)
+static void arcmsr_cmd_done(struct scsi_cmnd * pcmd)
 {
 	pcmd->scsi_done(pcmd);
 	return;
@@ -608,7 +611,7 @@
 {
 	unsigned long flag;
 	PACB pACB = pCCB->pACB;
-	Scsi_Cmnd *pcmd = pCCB->pcmd;
+	struct scsi_cmnd *pcmd = pCCB->pcmd;
 
 #if ARCMSR_DEBUG0
 	printk
@@ -635,7 +638,7 @@
 */
 static void arcmsr_report_SenseInfoBuffer(PCCB pCCB)
 {
-	Scsi_Cmnd *pcmd = pCCB->pcmd;
+	struct scsi_cmnd *pcmd = pCCB->pcmd;
 	PSENSE_DATA psenseBuffer = (PSENSE_DATA) pcmd->sense_buffer;
 #if ARCMSR_DEBUG0
 	printk("arcmsr_report_SenseInfoBuffer...\n");
@@ -804,7 +807,7 @@
 ** PAGE_SIZE=4096 or 8192,PAGE_SHIFT=12
 **
 */
-static void arcmsr_build_ccb(PACB pACB, PCCB pCCB, Scsi_Cmnd * pcmd)
+static void arcmsr_build_ccb(PACB pACB, PCCB pCCB, struct scsi_cmnd * pcmd)
 {
 	PARCMSR_CDB pARCMSR_CDB = (PARCMSR_CDB) & pCCB->arcmsr_cdb;
 	int8_t *psge = (int8_t *) & pARCMSR_CDB->u;
@@ -831,7 +834,7 @@
 		sl = (struct scatterlist *)pcmd->request_buffer;
 		sgcount =
 		pci_map_sg(pACB->pPCI_DEV, sl, pcmd->use_sg,
-			   scsi_to_pci_dma_dir(pcmd->sc_data_direction));
+			   pcmd->sc_data_direction);
 		/* map stor port SG list to our iop SG List. */
 		for (i = 0; i < sgcount; i++) {
 			/* Get the physical address of the current data pointer */
@@ -902,8 +905,7 @@
 		dma_addr =
 		pci_map_single(pACB->pPCI_DEV, pcmd->request_buffer,
    pcmd->request_bu

Re: bcm203x broadcom dongle firmware upload fails...

[Marcel Holtmann]

Hi Soeren,

> I don't see why, it used to work reliably at some point but now it does
> not. It even won't work without hotplug and then manually typing:
> 
> echo 1 > /sys/class/firmware/2-1/loading
> cat /lib/firmware/BCM2033-FW.bin >/sys/class/firmware/2-1/data
> echo 0 > /sys/class/firmware/2-1/loading
> 
> usb 2-1: new full speed USB device using ohci_hcd and address 2
> Bluetooth: Broadcom Blutonium firmware driver ver 1.0
> bcm203x_probe: Mini driver request failed
> bcm203x: probe of 2-1:1.0 failed with error -5
> usbcore: registered new driver bcm203x
> 
> It does not work with kernel 2.6.10/11 any ideas ?

I think this is a general request_firmware() problem. Check the Hotplug
mailing list archive. Hannes, Kay and Greg discussed problems with the
firmware_class and udev. I haven't found the time to look at it.

Regards

Marcel


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] sealevel 8 port RS-232/RS-422/RS-485 board

[Russell King]

On Thu, Mar 10, 2005 at 11:38:58PM -0600, DHollenbeck wrote:
> Vendor Sealevel suggested these changes for its new board.  Tried them, 
> they work with the card.  Please apply the patch below, which was made 
> from 2.6.10 but can be applied to 2.6.11.2 without errors.

Whitespace fixed and applied, thanks.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Need break driver<-->pci-device automatic association

[Jacques Goldberg]

   Stuart,
   Many thanks for this interesting approach.
   A huge advantage is that it can be implemented as a script.
   But:
   -it still requires the Linux newcomer who wants his modem to work, to
recompile her/his kernel - something which frightens beginners.
   -it implies that when adding a serial device such as an other modem, or
a  serial scanner, the kernel ought again to be recompiled according to
the new hardware configuration.
   -and at each kernel upgrade, often automatic in large organizations,
the kernel must again be tailored to the configuration.

 Thanks again - Jacques

On Fri, 18 Mar 2005, Stuart MacDonald wrote:

> From: Jacques Goldberg
> > To be ugly or to never be up to date, that's the question.
> > We did patch 8250_pci.c but there is no way to build a
> > stable list of
> > the devices to be handled that way.
> > We will thus spend some time on the hot unplug solution.
>
> I think what you want might be accomplished if the serial driver was
> compiled as a module. Then have your driver grab all the PCI devices
> it wants, and they shouldn't be grabbed by the serial driver when it
> loads. If you can't get your driver to load before the serial driver
> for whatever reason, unloading the serial driver should give up the
> devices it had claimed.
>
> ..Stu
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Relayfs question

[Jan Engelhardt]

Hello,


according to the relayfs description on opersys.com,

|As the Linux kernel matures, there is an ever increasing number of facilities
|and tools that need to relay large amounts of data from kernel space to user
|space. Up to this point, each of these has had its own mechanism for relaying
|data. To supersede the individual mechanisms, we introduce the "high-speed
|data relay filesystem" (relayfs). As such, things like LTT, printk, EVLog,
|etc.

This sounds to me like it would obsolete most character-based devices, e.g.
random and urandom.

What do the relayfs developers say to this?


Jan Engelhardt
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/5] timers: remove memory barriers

[Oleg Nesterov]

del_timer() and __run_timers() use smp_wmb() before
clearing timer's pending flag. It was needed because
__mod_timer() did not locked old_base if the timer is
not pending, so __mod_timer()->internal_add_timer()
can race with del_timer()->list_del().

With the previous patch these functions are serialized
through base->lock, so the barrier can be killed.

Still needed in del_timer_sync(), because it clears ->_base.

Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>

--- 2.6.12-rc1/kernel/timer.c~4_BARR2005-03-19 22:26:50.0 +0300
+++ 2.6.12-rc1/kernel/timer.c   2005-03-19 22:28:34.0 +0300
@@ -337,8 +337,6 @@ repeat:
goto repeat;
}
list_del(&timer->entry);
-   /* Need to make sure that anybody who sees a NULL base also sees the 
list ops */
-   smp_wmb();
__set_base(timer, base, 0);
spin_unlock_irqrestore(&base->lock, flags);
 
@@ -496,7 +494,6 @@ repeat:
 
list_del(&timer->entry);
set_running_timer(base, timer);
-   smp_wmb();
__set_base(timer, base, 0);
spin_unlock_irq(&base->lock);
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/5] timers: serialize timers

[Oleg Nesterov]

I think it is supposed that timers are serialized wrt to itself,
but I can't find any documentation about it.

If CPU_0 does mod_timer(jiffies+1) while the timer is currently
running on CPU 1, it is quite possible that local interrupt on
CPU_0 will start that timer before it finished on CPU_1.

With this patch __mod_timer() locks old_base even if timer is not
pending, like del_timer_sync() does. If the timer is still running,
and old_base != new_base, __mod_timer() retries.

Now we have:
1. the timer's handler can't run on different cpus at
   the same time.
2. the timer's base can't be changed during execution
   of the timer's handler.

Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>

--- 2.6.12-rc1/kernel/timer.c~3_MOD 2005-03-19 17:19:44.0 +0300
+++ 2.6.12-rc1/kernel/timer.c   2005-03-19 20:16:47.0 +0300
@@ -193,7 +193,7 @@ int __mod_timer(struct timer_list *timer
spin_lock_irqsave(&timer->lock, flags);
new_base = &__get_cpu_var(tvec_bases);
 repeat:
-   old_base = __get_base(timer);
+   old_base = timer_base(timer);
 
/*
 * Prevent deadlocks via ordering by old_base < new_base.
@@ -208,29 +208,32 @@ repeat:
}
/*
 * The timer base might have been cancelled while we were
-* trying to take the lock(s):
+* trying to take the lock(s), or can still be running on
+* old_base's CPU.
 */
-   if (__get_base(timer) != old_base) {
+   if (timer_base(timer) != old_base
+   || old_base->running_timer == timer) {
spin_unlock(&new_base->lock);
spin_unlock(&old_base->lock);
goto repeat;
}
} else {
spin_lock(&new_base->lock);
-   if (__get_base(timer) != old_base) {
+   if (timer_base(timer) != old_base) {
spin_unlock(&new_base->lock);
goto repeat;
}
}
 
/*
-* Delete the previous timeout (if there was any), and install
-* the new one:
+* Delete the previous timeout (if there was any).
+* We hold timer->lock, no need to check old_base != 0.
 */
-   if (old_base) {
+   if (timer_pending(timer)) {
list_del(&timer->entry);
ret = 1;
}
+
timer->expires = expires;
internal_add_timer(new_base, timer);
__set_base(timer, new_base, 1);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] timers: rework del_timer_sync()

[Oleg Nesterov]

New rules:
->_base &  1: is timer pending
->_base & ~1: where the timer was last scheduled

->_base == NULL means that this timer is not running on any cpu.

del_timer_sync() clears ->_base, it is merely an optimization, so
that subsequent del_timer calls do not need locking.

del_timer_sync() assumes that the timer's base == (->_base & ~1)
can't be changed during execution of timer->function. It is achieved
by the next patch.

Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>

--- 2.6.12-rc1/include/linux/timer.h~2_SYNC 2005-03-19 15:05:46.0 
+0300
+++ 2.6.12-rc1/include/linux/timer.h2005-03-19 15:28:13.0 +0300
@@ -21,9 +21,26 @@ struct timer_list {
struct tvec_t_base_s *_base;
 };
 
+/*
+ * To save space, we play games with the least significant bit
+ * of timer_list->_base.
+ *
+ * If (_base & __TIMER_PENDING), the timer is pending. Implies
+ * (_base & ~__TIMER_PENDING) != NULL.
+ *
+ * (_base & ~__TIMER_PENDING), if != NULL, is the address of the
+ * timer's per-cpu tvec_t_base_s where it was last scheduled and
+ * where it may still be running.
+ *
+ * If (_base == NULL), the timer was not scheduled yet or it was
+ * cancelled by del_timer_sync(), so it is not running on any CPU.
+ */
+
+#define__TIMER_PENDING 1
+
 static inline int __timer_pending(struct tvec_t_base_s *base)
 {
-   return base != NULL;
+   return ((unsigned long)base & __TIMER_PENDING) != 0;
 }
 
 #define TIMER_MAGIC0x4b87ad6e
--- 2.6.12-rc1/kernel/timer.c~2_SYNC2005-03-19 15:05:46.0 +0300
+++ 2.6.12-rc1/kernel/timer.c   2005-03-19 17:19:44.0 +0300
@@ -88,16 +88,26 @@ static inline void set_running_timer(tve
 
 static inline tvec_base_t *__get_base(struct timer_list *timer)
 {
-   return timer->_base;
+   tvec_base_t *base = timer->_base;
+
+   if (__timer_pending(base))
+   return (void*)base - __TIMER_PENDING;
+   else
+   return NULL;
 }
 
 static inline void __set_base(struct timer_list *timer,
tvec_base_t *base, int pending)
 {
if (pending)
-   timer->_base = base;
+   timer->_base = (void*)base + __TIMER_PENDING;
else
-   timer->_base = NULL;
+   timer->_base = base;
+}
+
+static inline tvec_base_t *timer_base(struct timer_list *timer)
+{
+   return (tvec_base_t*)((unsigned long)timer->_base & ~__TIMER_PENDING);
 }
 
 /* Fake initialization */
@@ -346,41 +356,46 @@ EXPORT_SYMBOL(del_timer);
  * Synchronization rules: callers must prevent restarting of the timer,
  * otherwise this function is meaningless. It must not be called from
  * interrupt contexts. The caller must not hold locks which would prevent
- * completion of the timer's handler.  Upon exit the timer is not queued and
- * the handler is not running on any CPU.
+ * completion of the timer's handler. The timer's handler must not call
+ * add_timer_on(). Upon exit the timer is not queued and the handler is
+ * not running on any CPU.
  *
  * The function returns whether it has deactivated a pending timer or not.
- *
- * del_timer_sync() is slow and complicated because it copes with timer
- * handlers which re-arm the timer (periodic timers).  If the timer handler
- * is known to not do this (a single shot timer) then use
- * del_singleshot_timer_sync() instead.
  */
 int del_timer_sync(struct timer_list *timer)
 {
-   tvec_base_t *base;
-   int i, ret = 0;
+   int ret;
 
check_timer(timer);
 
-del_again:
-   ret += del_timer(timer);
+   ret = 0;
+   for (;;) {
+   unsigned long flags;
+   tvec_base_t *base;
 
-   for_each_online_cpu(i) {
-   base = &per_cpu(tvec_bases, i);
-   if (base->running_timer == timer) {
-   while (base->running_timer == timer) {
-   cpu_relax();
-   preempt_check_resched();
-   }
-   break;
+   base = timer_base(timer);
+   if (!base)
+   return ret;
+
+   spin_lock_irqsave(&base->lock, flags);
+
+   if (base->running_timer == timer)
+   goto unlock;
+
+   if (timer_base(timer) != base)
+   goto unlock;
+
+   if (timer_pending(timer)) {
+   list_del(&timer->entry);
+   ret = 1;
}
+   /* Need to make sure that anybody who sees a NULL base
+* also sees the list ops */
+   smp_wmb();
+   timer->_base = NULL;
+unlock:
+   spin_unlock_irqrestore(&base->lock, flags);
}
-   smp_rmb();
-   if (timer_pending(timer))
-   goto del_again;
-
-   return ret;
 }
 EXPORT_SYMBOL(del_timer_sync);
-
To unsubscribe from this list: send the line "unsubscri

[PATCH 5/5] timers: cleanup, kill __get_base()

[Oleg Nesterov]

__get_base() was added to reduce the changes in
previous patches. This patch removes it.

Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>

--- 2.6.12-rc1/kernel/timer.c~5_CLEAN   2005-03-19 22:28:34.0 +0300
+++ 2.6.12-rc1/kernel/timer.c   2005-03-19 23:34:23.0 +0300
@@ -86,16 +86,6 @@ static inline void set_running_timer(tve
 #endif
 }
 
-static inline tvec_base_t *__get_base(struct timer_list *timer)
-{
-   tvec_base_t *base = timer->_base;
-
-   if (__timer_pending(base))
-   return (void*)base - __TIMER_PENDING;
-   else
-   return NULL;
-}
-
 static inline void __set_base(struct timer_list *timer,
tvec_base_t *base, int pending)
 {
@@ -323,16 +313,18 @@ EXPORT_SYMBOL(mod_timer);
 int del_timer(struct timer_list *timer)
 {
unsigned long flags;
-   tvec_base_t *base;
+   tvec_base_t *_base, *base;
 
check_timer(timer);
 
 repeat:
-   base = __get_base(timer);
-   if (!base)
+   _base = timer->_base;
+   if (!__timer_pending(_base))
return 0;
+
+   base = (void*)_base - __TIMER_PENDING;
spin_lock_irqsave(&base->lock, flags);
-   if (base != __get_base(timer)) {
+   if (_base != timer->_base) {
spin_unlock_irqrestore(&base->lock, flags);
goto repeat;
}
@@ -445,7 +437,7 @@ static int cascade(tvec_base_t *base, tv
struct timer_list *tmp;
 
tmp = list_entry(curr, struct timer_list, entry);
-   BUG_ON(__get_base(tmp) != base);
+   BUG_ON(tmp->_base != ((void*)base + __TIMER_PENDING));
curr = curr->next;
internal_add_timer(base, tmp);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/5] timers: prepare for del_timer_sync() changes

[Oleg Nesterov]

There are problems with del_timer_sync().

1. Scalability. All cpus are scanned to determine if the timer is
running on that cpu.

2. It is racy. The timer can be fired again after del_timer_sync
have checked all cpus and before it will recheck timer_pending().

This patch adds 'pending flag' to timer_list. This flag is encoded
in the least significant bit of timer->base. This way we do not
waste the space and can read/write base+pending atomically.

__run_timers(), del_timer() do not set ->base = NULL anymore, they
only clear pending flag, so that del_timer_sync can wait while
timer->base->running_timer == timer.

It works only if recurring timer do not use add_timer_on().

The following patch  renames ->base to ->_base. Now this field is
used directly only in __get_base/__set_base helpers.

No changes in kernel/timer.o.

Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>

--- 2.6.12-rc1/include/linux/timer.h~1_BASE 2005-03-19 14:54:58.0 
+0300
+++ 2.6.12-rc1/include/linux/timer.h2005-03-19 15:05:46.0 +0300
@@ -18,16 +18,21 @@ struct timer_list {
void (*function)(unsigned long);
unsigned long data;
 
-   struct tvec_t_base_s *base;
+   struct tvec_t_base_s *_base;
 };
 
+static inline int __timer_pending(struct tvec_t_base_s *base)
+{
+   return base != NULL;
+}
+
 #define TIMER_MAGIC0x4b87ad6e
 
 #define TIMER_INITIALIZER(_function, _expires, _data) {\
.function = (_function),\
.expires = (_expires),  \
.data = (_data),\
-   .base = NULL,   \
+   ._base = NULL,  \
.magic = TIMER_MAGIC,   \
.lock = SPIN_LOCK_UNLOCKED, \
}
@@ -41,7 +46,7 @@ struct timer_list {
  */
 static inline void init_timer(struct timer_list * timer)
 {
-   timer->base = NULL;
+   timer->_base = NULL;
timer->magic = TIMER_MAGIC;
spin_lock_init(&timer->lock);
 }
@@ -58,7 +63,7 @@ static inline void init_timer(struct tim
  */
 static inline int timer_pending(const struct timer_list * timer)
 {
-   return timer->base != NULL;
+   return __timer_pending(timer->_base);
 }
 
 extern void add_timer_on(struct timer_list *timer, int cpu);
--- 2.6.12-rc1/kernel/timer.c~1_BASE2005-03-19 14:55:17.0 +0300
+++ 2.6.12-rc1/kernel/timer.c   2005-03-19 15:05:46.0 +0300
@@ -86,6 +86,20 @@ static inline void set_running_timer(tve
 #endif
 }
 
+static inline tvec_base_t *__get_base(struct timer_list *timer)
+{
+   return timer->_base;
+}
+
+static inline void __set_base(struct timer_list *timer,
+   tvec_base_t *base, int pending)
+{
+   if (pending)
+   timer->_base = base;
+   else
+   timer->_base = NULL;
+}
+
 /* Fake initialization */
 static DEFINE_PER_CPU(tvec_base_t, tvec_bases) = { SPIN_LOCK_UNLOCKED };
 
@@ -169,7 +183,7 @@ int __mod_timer(struct timer_list *timer
spin_lock_irqsave(&timer->lock, flags);
new_base = &__get_cpu_var(tvec_bases);
 repeat:
-   old_base = timer->base;
+   old_base = __get_base(timer);
 
/*
 * Prevent deadlocks via ordering by old_base < new_base.
@@ -186,14 +200,14 @@ repeat:
 * The timer base might have been cancelled while we were
 * trying to take the lock(s):
 */
-   if (timer->base != old_base) {
+   if (__get_base(timer) != old_base) {
spin_unlock(&new_base->lock);
spin_unlock(&old_base->lock);
goto repeat;
}
} else {
spin_lock(&new_base->lock);
-   if (timer->base != old_base) {
+   if (__get_base(timer) != old_base) {
spin_unlock(&new_base->lock);
goto repeat;
}
@@ -209,7 +223,7 @@ repeat:
}
timer->expires = expires;
internal_add_timer(new_base, timer);
-   timer->base = new_base;
+   __set_base(timer, new_base, 1);
 
if (old_base && (new_base != old_base))
spin_unlock(&old_base->lock);
@@ -239,7 +253,7 @@ void add_timer_on(struct timer_list *tim
 
spin_lock_irqsave(&base->lock, flags);
internal_add_timer(base, timer);
-   timer->base = base;
+   __set_base(timer, base, 1);
spin_unlock_irqrestore(&base->lock, flags);
 }
 
@@ -301,18 +315,18 @@ int del_timer(struct timer_list *timer)
check_timer(timer);
 
 repeat:
-   base = timer->base;
+   base = __get_base(timer);
if (!base)
return 0;
spin_lock_irqsave(&base->lock, flags);
-   if (base != timer->base) {
+   if (base != __get_base(timer

[PATCH 0/5] timers: description

[Oleg Nesterov]

Hello.

These patches are updated version of 'del_timer_sync: proof of concept'
2 patches.

1/5:
unchanded.

2/5:
del_timer_sync() simplified. It is not neccessary to unlock and
retry if __TIMER_PENDING has changed, it is only neccessary if
timer's base == (timer->_base & ~1) has changed. Also, comments
are updated.

3/5:
The reworked del_timer_sync() can't work unless timers are
serialized wrt to itself. They are not.
I missed the fact that __mod_timer() can change timer's base
while the timer is running.

4/5:
remove memory barrier in __run_timers() and del_timer().

5/5:
kill ugly __get_base(), it was temporal.


The del_singleshot_timer_sync function now unneeded, but it looks like
additional test for del_timer_sync(), so it will be removed later.

Btw, add_timer_on() is racy against __mod_timer(), is it worth fixing?

Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Bitrotting serial drivers

[Russell King]

Hi,

m32r_sio


Maintainer: Hirokazu Takata

Please clean up the m32r_sio driver, removing whatever bits of code
aren't absolutely necessary.

Specifically, I'd like to see the following addressed:

- the usage of SERIAL_IO_HUB6
  (this driver doesn't support hub6 cards)
- SERIAL_IO_* should be UPIO_*
- __register_m32r_sio, register_m32r_sio, unregister_m32r_sio,
  m32r_sio_get_irq_map
  (this driver doesn't support PCMCIA cards, all of which are based on
   8250-compatible devices.)
- early_serial_setup
  (should we really have the function name duplicated across different
   hardware drivers?)

au1x00_uart
---

Maintainer: unknown (akpm - any ideas?)

This is a complete clone of 8250.c, which includes all the 8250-specific
structure names.

Specifically, I'd like to see the following addressed:

- Please clean this up to use au1x00-specific names.
- this driver is lagging behind with fixes that the other drivers are
  getting.  Is au1x00_uart actually maintained?
- the usage of UPIO_HUB6
  (this driver doesn't support hub6 cards)
- __register_serial, register_serial, unregister_serial
  (this driver doesn't support PCMCIA cards, all of which are based on
   8250-compatible devices.)
- early_serial_setup
  (should we really have the function name duplicated across different
   hardware drivers?)

The main reason is I wish to kill off uart_register_port and
uart_unregister_port, but these drivers are using it.

Thanks.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/