Potential DOS in load_elf_library?

2005-03-18 Thread Yichen Xie
Hi guys, I was looking at the load_elf_library function (fs/binfmt_elf.c) 
in 2.6.10, and noticed the following:

elf_phdata = (struct elf_phdr *) kmalloc(j, GFP_KERNEL);
...
while (elf_phdata-p_type != PT_LOAD) elf_phdata++;
...
kfree(elf_phdata);
Could this be problematic since the pointer being freed might be different 
from that returned from kmalloc?
-
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 mems generation deadlock fix

2005-03-18 Thread Paul Jackson

Linus - please apply.

The cpuset code to update mems_generation could (in theory)
deadlock on cpuset_sem if it needed to allocate some memory
while creating (mkdir) or removing (rmdir) a cpuset, so already
held cpuset_sem.  Some other process would have to mess with
this tasks cpuset memory placement at the same time.

We avoid this possible deadlock by always updating mems_generation
after we grab cpuset_sem on such operations, before we risk any
operations that might require memory allocation.

Applies to top of Linus's bk tree (post 2.6.11)

Thanks to Jack Steiner [EMAIL PROTECTED] for noticing this.

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

===
--- 2.6.12-pj.orig/kernel/cpuset.c  2005-03-16 01:05:33.0 -0800
+++ 2.6.12-pj/kernel/cpuset.c   2005-03-16 01:14:51.0 -0800
@@ -505,6 +505,35 @@ static void guarantee_online_mems(const 
 }
 
 /*
+ * Refresh current tasks mems_allowed and mems_generation from
+ * current tasks cpuset.  Call with cpuset_sem held.
+ *
+ * Be sure to call refresh_mems() on any cpuset operation which
+ * (1) holds cpuset_sem, and (2) might possibly alloc memory.
+ * Call after obtaining cpuset_sem lock, before any possible
+ * allocation.  Otherwise one risks trying to allocate memory
+ * while the task cpuset_mems_generation is not the same as
+ * the mems_generation in its cpuset, which would deadlock on
+ * cpuset_sem in cpuset_update_current_mems_allowed().
+ *
+ * Since we hold cpuset_sem, once refresh_mems() is called, the
+ * test (current-cpuset_mems_generation != cs-mems_generation)
+ * in cpuset_update_current_mems_allowed() will remain false,
+ * until we drop cpuset_sem.  Anyone else who would change our
+ * cpusets mems_generation needs to lock cpuset_sem first.
+ */
+
+static void refresh_mems(void)
+{
+   struct cpuset *cs = current-cpuset;
+
+   if (current-cpuset_mems_generation != cs-mems_generation) {
+   guarantee_online_mems(cs, current-mems_allowed);
+   current-cpuset_mems_generation = cs-mems_generation;
+   }
+}
+
+/*
  * is_cpuset_subset(p, q) - Is cpuset p a subset of cpuset q?
  *
  * One cpuset is a subset of another if all its allowed CPUs and
@@ -1224,6 +1253,7 @@ static long cpuset_create(struct cpuset 
return -ENOMEM;
 
down(cpuset_sem);
+   refresh_mems();
cs-flags = 0;
if (notify_on_release(parent))
set_bit(CS_NOTIFY_ON_RELEASE, cs-flags);
@@ -1277,6 +1307,7 @@ static int cpuset_rmdir(struct inode *un
/* the vfs holds both inode-i_sem already */
 
down(cpuset_sem);
+   refresh_mems();
if (atomic_read(cs-count)  0) {
up(cpuset_sem);
return -EBUSY;
@@ -1433,8 +1464,7 @@ void cpuset_update_current_mems_allowed(
return; /* task is exiting */
if (current-cpuset_mems_generation != cs-mems_generation) {
down(cpuset_sem);
-   guarantee_online_mems(cs, current-mems_allowed);
-   current-cpuset_mems_generation = cs-mems_generation;
+   refresh_mems();
up(cpuset_sem);
}
 }

-- 
  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/


[Patch] cpusets alloc GFP_WAIT sleep fix

2005-03-18 Thread Paul Jackson

Linus - please apply.

The cpuset mems_allowed update code in alloc_pages_current could
(in theory) put a task to sleep that didn't allow sleeping (did
not have __GFP_WAIT flag set).  In the rare circumstance that
the current tasks mems_generation is outofdate compared to the
tasks cpuset mems_generation, this mems_allowed update code
needs to grap cpuset_sem, which can sleep.

We avoid this by not trying to update mems_allowed here if we
can't sleep (__GFP_WAIT not set).

Applies to top of Linus's bk tree (post 2.6.11)

Thanks to Ray Bryant [EMAIL PROTECTED] for noticing this.

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

===
--- 2.6.12-pj.orig/mm/mempolicy.c   2005-03-16 01:16:58.0 -0800
+++ 2.6.12-pj/mm/mempolicy.c2005-03-16 01:32:05.0 -0800
@@ -788,12 +788,16 @@ alloc_page_vma(unsigned gfp, struct vm_a
  * Allocate a page from the kernel page pool.  When not in
  * interrupt context and apply the current process NUMA policy.
  * Returns NULL when no page can be allocated.
+ *
+ * Don't call cpuset_update_current_mems_allowed() unless
+ * 1) it's ok to take cpuset_sem (can WAIT), and
+ * 2) allocating for current task (not interrupt).
  */
 struct page *alloc_pages_current(unsigned gfp, unsigned order)
 {
struct mempolicy *pol = current-mempolicy;
 
-   if (!in_interrupt())
+   if ((gfp  __GFP_WAIT)  !in_interrupt())
cpuset_update_current_mems_allowed();
if (!pol || in_interrupt())
pol = default_policy;

-- 
  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: 2.6.11 vs 2.6.10 slowdown on i686

2005-03-18 Thread Kurt Garloff
Hi Nick,

On Thu, Mar 17, 2005 at 11:37:24PM +1100, Nick Piggin wrote:
 Ian Pratt wrote:
 fork: 166 - 235  (40% slowdown)
 exec: 857 - 1003 (17% slowdown)
 
 I'm guessing this is down to the 4 level pagetables. This is rather a
 surprise as I thought the compiler would optimise most of these
 changes away. Apparently not. 
 
 There are some changes in the current -bk tree (which are a
 bit in-flux at the moment) which introduce some optimisations.
 
 They should bring 2-level performance close to par with 2.6.10.
 If not, complain again :)

Is there a clean patchset that we should look at to test?

Regards,
-- 
Kurt Garloff, Director SUSE Labs, Novell Inc.


pgp77K575xjBf.pgp
Description: PGP signature


Re: Potential DOS in load_elf_library?

2005-03-18 Thread Andrew Morton
Yichen Xie [EMAIL PROTECTED] wrote:

 Hi guys, I was looking at the load_elf_library function (fs/binfmt_elf.c) 
  in 2.6.10, and noticed the following:
 
   elf_phdata = (struct elf_phdr *) kmalloc(j, GFP_KERNEL);
   ...
   while (elf_phdata-p_type != PT_LOAD) elf_phdata++;
   ...
   kfree(elf_phdata);
 
  Could this be problematic since the pointer being freed might be different 
  from that returned from kmalloc?

Current kernels seem to be OK.
-
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

2005-03-18 Thread Ingo Molnar

* Paul E. McKenney [EMAIL PROTECTED] wrote:

   [I believe that the real-time preemption patch moves code
   from softirq/interrupt to process context, but could easily be
   missing something.  If need be, there are ways of handling cases
   were realtime RCU is called from softirq and interrupt contexts,
   for an example approach, see the Quick Quiz answers.]

correct, on PREEMPT_RT, IRQ processing is (and must be) in process
context.

(it's pretty much a must-have thing to enable the preemption of irq
handlers and softirq processing: if irq/softirq contexts nested on the
kernel stack then irq contexts would 'pin down' the process context that
was interrupted, so even if irq preemption was possible, the underlying
process context couldnt be freely scheduled.)

still, it's nice that your #5 design does not rely on it - it's a sign
of fundamental robustness, plus we could (in theory) offer preemptable
RCU on PREEMPT_DESKTOP (== current PREEMPT) as well - just like there is
PREEMPT_BKL.

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 vs 2.6.10 slowdown on i686

2005-03-18 Thread Nick Piggin
Kurt Garloff wrote:
Hi Nick,
Hi Kurt!
On Thu, Mar 17, 2005 at 11:37:24PM +1100, Nick Piggin wrote:
Ian Pratt wrote:
fork: 166 - 235  (40% slowdown)
exec: 857 - 1003 (17% slowdown)
I'm guessing this is down to the 4 level pagetables. This is rather a
surprise as I thought the compiler would optimise most of these
changes away. Apparently not. 
There are some changes in the current -bk tree (which are a
bit in-flux at the moment) which introduce some optimisations.
They should bring 2-level performance close to par with 2.6.10.
If not, complain again :)

Is there a clean patchset that we should look at to test?
Probably the best thing would be to wait and see what happens
with the ptwalk patches. There is a fix in there for ia64 now,
but I think that may be a temporary one.
Andi is probably keeping an eye on that, but if not then I
could put a patchset together when things finalise in 2.6.
From the profiles I have seen, the ptwalk patches bring page
table walking performance pretty well back to 2.6.10 levels,
however the aggressive page table freeing (clear_page_range)
changes that went in at the same time as the 4level stuff
seem to be what is slowing down exit() and unmapping performance.
Not by a huge amount, mind you, and it is not completely wasted
performance, because it provides better page table freeing.
But it is enough to be annoying! I haven't had much time to look
at it lately, but I hope to get onto it soon.
Nick
-
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-mm4] perfctr cleanups 1/3: common

2005-03-18 Thread Mikael Pettersson
Andrew,

Here's a collection of cleanups for perfctr.

Common-code cleanups for perfctr:
- init.c: remove unused asm/uaccess.h, don't
  initialise perfctr_info, don't show dummy cpu_type,
  show driver version directly from VERSION.
- linux/perfctr.h: remove types  constants not used
  in the kernel any more, make perfctr_info kernel-only
  and remove unused fields, use explicitly-sized integers
  in user-visible types.

Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]

 drivers/perfctr/init.c|   22 ---
 drivers/perfctr/version.h |2 -
 include/linux/perfctr.h   |   51 ++
 3 files changed, 18 insertions(+), 57 deletions(-)

diff -rupN linux-2.6.11-mm4/drivers/perfctr/init.c 
linux-2.6.11-mm4.perfctr-2.7.12/drivers/perfctr/init.c
--- linux-2.6.11-mm4/drivers/perfctr/init.c 2005-03-17 19:39:42.0 
+0100
+++ linux-2.6.11-mm4.perfctr-2.7.12/drivers/perfctr/init.c  2005-03-18 
00:49:07.0 +0100
@@ -1,8 +1,8 @@
-/* $Id: init.c,v 1.76 2004/05/31 18:18:55 mikpe Exp $
+/* $Id: init.c,v 1.81 2005/03/17 23:49:07 mikpe Exp $
  * Performance-monitoring counters driver.
  * Top-level initialisation code.
  *
- * Copyright (C) 1999-2004  Mikael Pettersson
+ * Copyright (C) 1999-2005  Mikael Pettersson
  */
 #include linux/config.h
 #include linux/fs.h
@@ -11,27 +11,16 @@
 #include linux/device.h
 #include linux/perfctr.h
 
-#include asm/uaccess.h
-
 #include cpumask.h
 #include virtual.h
 #include version.h
 
-struct perfctr_info perfctr_info = {
-   .abi_version = PERFCTR_ABI_VERSION,
-   .driver_version = VERSION,
-};
+struct perfctr_info perfctr_info;
 
 static ssize_t
 driver_version_show(struct class *class, char *buf)
 {
-   return sprintf(buf, %s\n, perfctr_info.driver_version);
-}
-
-static ssize_t
-cpu_type_show(struct class *class, char *buf)
-{
-   return sprintf(buf, %#x\n, perfctr_info.cpu_type);
+   return sprintf(buf, %s\n, VERSION);
 }
 
 static ssize_t
@@ -70,7 +59,6 @@ cpus_forbidden_show(struct class *class,
 
 static struct class_attribute perfctr_class_attrs[] = {
__ATTR_RO(driver_version),
-   __ATTR_RO(cpu_type),
__ATTR_RO(cpu_features),
__ATTR_RO(cpu_khz),
__ATTR_RO(tsc_to_cpu_mult),
@@ -104,7 +92,7 @@ static int __init perfctr_init(void)
return err;
}
printk(KERN_INFO perfctr: driver %s, cpu type %s at %u kHz\n,
-  perfctr_info.driver_version,
+  VERSION,
   perfctr_cpu_name,
   perfctr_info.cpu_khz);
return 0;
diff -rupN linux-2.6.11-mm4/drivers/perfctr/version.h 
linux-2.6.11-mm4.perfctr-2.7.12/drivers/perfctr/version.h
--- linux-2.6.11-mm4/drivers/perfctr/version.h  2005-03-17 19:39:42.0 
+0100
+++ linux-2.6.11-mm4.perfctr-2.7.12/drivers/perfctr/version.h   2005-03-18 
01:11:49.0 +0100
@@ -1 +1 @@
-#define VERSION 2.7.10
+#define VERSION 2.7.12
diff -rupN linux-2.6.11-mm4/include/linux/perfctr.h 
linux-2.6.11-mm4.perfctr-2.7.12/include/linux/perfctr.h
--- linux-2.6.11-mm4/include/linux/perfctr.h2005-03-17 19:39:45.0 
+0100
+++ linux-2.6.11-mm4.perfctr-2.7.12/include/linux/perfctr.h 2005-03-18 
01:10:53.0 +0100
@@ -1,4 +1,4 @@
-/* $Id: perfctr.h,v 1.88 2005/02/20 12:03:08 mikpe Exp $
+/* $Id: perfctr.h,v 1.91 2005/03/18 00:10:53 mikpe Exp $
  * Performance-Monitoring Counters driver
  *
  * Copyright (C) 1999-2005  Mikael Pettersson
@@ -10,43 +10,15 @@
 
 #include asm/perfctr.h
 
-struct perfctr_info {
-   unsigned int abi_version;
-   char driver_version[32];
-   unsigned int cpu_type;
-   unsigned int cpu_features;
-   unsigned int cpu_khz;
-   unsigned int tsc_to_cpu_mult;
-   unsigned int _reserved2;
-   unsigned int _reserved3;
-   unsigned int _reserved4;
-};
-
-struct perfctr_cpu_mask {
-   unsigned int nrwords;
-   unsigned int mask[1];   /* actually 'nrwords' */
-};
-
-/* abi_version values: Lower 16 bits contain the CPU data version, upper
-   16 bits contain the API version. Each half has a major version in its
-   upper 8 bits, and a minor version in its lower 8 bits. */
-#define PERFCTR_API_VERSION0x0600  /* 6.0 */
-#define PERFCTR_ABI_VERSION((PERFCTR_API_VERSION16)|PERFCTR_CPU_VERSION)
-
 /* cpu_features flag bits */
 #define PERFCTR_FEATURE_RDPMC  0x01
 #define PERFCTR_FEATURE_RDTSC  0x02
 #define PERFCTR_FEATURE_PCINT  0x04
 
-/* user's view of mmap:ed virtual perfctr */
-struct vperfctr_state {
-   struct perfctr_cpu_state cpu_state;
-};
-
 /* virtual perfctr control object */
 struct vperfctr_control {
-   int si_signo;
-   unsigned int preserve;
+   __s32 si_signo;
+   __u32 preserve;
 };
 
 /* commands for sys_vperfctr_control() */
@@ -57,8 +29,8 @@ struct vperfctr_control {
 
 /* common description of an arch-specific 32-bit control register */
 struct perfctr_cpu_reg {
-   unsigned int nr;
-   unsigned int value;
+   

[PATCH][2.6.11-mm4] perfctr cleanups 2/3: ppc32

2005-03-18 Thread Mikael Pettersson
ppc32-specific cleanups for perfctr:
- ppc.c: don't initialise obsolete perfctr_info.cpu_type,
  use DEFINE_SPINLOCK().
- asm-ppc/perfctr.h: remove cpu_type constants and
  PERFCTR_CPU_VERSION unused in the kernel, use
  explicitly-sized integers in user-visible types, make
  perfctr_cpu_control kernel-private.

Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]

 drivers/perfctr/ppc.c |8 +++-
 include/asm-ppc/perfctr.h |   43 ++-
 2 files changed, 21 insertions(+), 30 deletions(-)

diff -rupN linux-2.6.11-mm4/drivers/perfctr/ppc.c 
linux-2.6.11-mm4.perfctr-2.7.12/drivers/perfctr/ppc.c
--- linux-2.6.11-mm4/drivers/perfctr/ppc.c  2005-03-17 19:39:42.0 
+0100
+++ linux-2.6.11-mm4.perfctr-2.7.12/drivers/perfctr/ppc.c   2005-03-18 
00:50:05.0 +0100
@@ -1,7 +1,7 @@
-/* $Id: ppc.c,v 1.30 2004/11/24 00:23:27 mikpe Exp $
+/* $Id: ppc.c,v 1.35 2005/03/17 23:50:05 mikpe Exp $
  * PPC32 performance-monitoring counters driver.
  *
- * Copyright (C) 2004  Mikael Pettersson
+ * Copyright (C) 2004-2005  Mikael Pettersson
  */
 #include linux/config.h
 #include linux/init.h
@@ -43,7 +43,7 @@ static enum pm_type pm_type;
 
 static unsigned int new_id(void)
 {
-   static spinlock_t lock = SPIN_LOCK_UNLOCKED;
+   static DEFINE_SPINLOCK(lock);
static unsigned int counter;
int id;
 
@@ -1005,7 +1005,6 @@ static int __init known_init(void)
return -ENODEV;
}
perfctr_info.cpu_features = features;
-   perfctr_info.cpu_type = 0; /* user-space should inspect PVR */
perfctr_cpu_name = known_name;
perfctr_info.cpu_khz = detect_cpu_khz(pll_type);
perfctr_ppc_init_tests(have_mmcr1);
@@ -1021,7 +1020,6 @@ static int __init unknown_init(void)
if (!khz)
return -ENODEV;
perfctr_info.cpu_features = PERFCTR_FEATURE_RDTSC;
-   perfctr_info.cpu_type = 0;
perfctr_cpu_name = unknown_name;
perfctr_info.cpu_khz = khz;
pm_type = PM_NONE;
diff -rupN linux-2.6.11-mm4/include/asm-ppc/perfctr.h 
linux-2.6.11-mm4.perfctr-2.7.12/include/asm-ppc/perfctr.h
--- linux-2.6.11-mm4/include/asm-ppc/perfctr.h  2005-03-17 19:39:43.0 
+0100
+++ linux-2.6.11-mm4.perfctr-2.7.12/include/asm-ppc/perfctr.h   2005-03-18 
00:58:54.0 +0100
@@ -1,30 +1,25 @@
-/* $Id: perfctr.h,v 1.12 2004/11/24 00:20:57 mikpe Exp $
+/* $Id: perfctr.h,v 1.16 2005/03/17 23:58:54 mikpe Exp $
  * PPC32 Performance-Monitoring Counters driver
  *
- * Copyright (C) 2004  Mikael Pettersson
+ * Copyright (C) 2004-2005  Mikael Pettersson
  */
 #ifndef _ASM_PPC_PERFCTR_H
 #define _ASM_PPC_PERFCTR_H
 
-/* perfctr_info.cpu_type values */
-#define PERFCTR_PPC_GENERIC0
-#define PERFCTR_PPC_6041
-#define PERFCTR_PPC_604e   2
-#define PERFCTR_PPC_7503
-#define PERFCTR_PPC_7400   4
-#define PERFCTR_PPC_7450   5
+#include asm/types.h
 
 struct perfctr_sum_ctrs {
-   unsigned long long tsc;
-   unsigned long long pmc[8];
+   __u64 tsc;
+   __u64 pmc[8];   /* the size is not part of the user ABI */
 };
 
 struct perfctr_cpu_control_header {
-   unsigned int tsc_on;
-   unsigned int nractrs;   /* # of a-mode counters */
-   unsigned int nrictrs;   /* # of i-mode counters */
+   __u32 tsc_on;
+   __u32 nractrs;  /* number of accumulation-mode counters */
+   __u32 nrictrs;  /* number of interrupt-mode counters */
 };
 
+#ifdef __KERNEL__
 struct perfctr_cpu_control {
struct perfctr_cpu_control_header header;
unsigned int mmcr0;
@@ -34,21 +29,22 @@ struct perfctr_cpu_control {
unsigned int ireset[8]; /* [0,0x7fff], for i-mode counters, 
physical indices */
unsigned int pmc_map[8];/* virtual to physical index map */
 };
+#endif
 
 struct perfctr_cpu_state {
-   unsigned int cstatus;
+   __u32 cstatus;
struct {/* k1 is opaque in the user ABI */
-   unsigned int id;
-   int isuspend_cpu;
+   __u32 id;
+   __s32 isuspend_cpu;
} k1;
/* The two tsc fields must be inlined. Placing them in a
   sub-struct causes unwanted internal padding on x86-64. */
-   unsigned int tsc_start;
-   unsigned long long tsc_sum;
+   __u32 tsc_start;
+   __u64 tsc_sum;
struct {
-   unsigned int map;
-   unsigned int start;
-   unsigned long long sum;
+   __u32 map;
+   __u32 start;
+   __u64 sum;
} pmc[8];   /* the size is not part of the user ABI */
 #ifdef __KERNEL__
struct perfctr_cpu_control control;
@@ -109,9 +105,6 @@ static inline unsigned int perfctr_cstat
 #endif
 #define si_pmc_ovf_mask_sifields._pad[0] /* XXX: use an unsigned field 
later */
 
-/* version number for user-visible CPU-specific data */
-#define PERFCTR_CPU_VERSION

Re: Potential DOS in load_elf_library?

2005-03-18 Thread Herbert Xu
Yichen Xie [EMAIL PROTECTED] wrote:
 Hi guys, I was looking at the load_elf_library function (fs/binfmt_elf.c) 
 in 2.6.10, and noticed the following:
 
elf_phdata = (struct elf_phdr *) kmalloc(j, GFP_KERNEL);
...
while (elf_phdata-p_type != PT_LOAD) elf_phdata++;
...
kfree(elf_phdata);
 
 Could this be problematic since the pointer being freed might be different 
 from that returned from kmalloc?

Indeed.  This bug has been around since last century.  How does this
look?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
= fs/binfmt_elf.c 1.106 vs edited =
--- 1.106/fs/binfmt_elf.c   2005-03-14 10:29:43 +11:00
+++ edited/fs/binfmt_elf.c  2005-03-18 19:46:37 +11:00
@@ -1026,6 +1026,7 @@
 static int load_elf_library(struct file *file)
 {
struct elf_phdr *elf_phdata;
+   struct elf_phdr *eppnt;
unsigned long elf_bss, bss, len;
int retval, error, i, j;
struct elfhdr elf_ex;
@@ -1063,30 +1064,32 @@
if (j != 1)
goto out_free_ph;
 
-   while (elf_phdata-p_type != PT_LOAD) elf_phdata++;
+   eppnt = elf_phdata;
+   while (eppnt-p_type != PT_LOAD)
+   eppnt++;
 
/* Now use mmap to map the library into memory. */
down_write(current-mm-mmap_sem);
error = do_mmap(file,
-   ELF_PAGESTART(elf_phdata-p_vaddr),
-   (elf_phdata-p_filesz +
-ELF_PAGEOFFSET(elf_phdata-p_vaddr)),
+   ELF_PAGESTART(eppnt-p_vaddr),
+   (eppnt-p_filesz +
+ELF_PAGEOFFSET(eppnt-p_vaddr)),
PROT_READ | PROT_WRITE | PROT_EXEC,
MAP_FIXED | MAP_PRIVATE | MAP_DENYWRITE,
-   (elf_phdata-p_offset -
-ELF_PAGEOFFSET(elf_phdata-p_vaddr)));
+   (eppnt-p_offset -
+ELF_PAGEOFFSET(eppnt-p_vaddr)));
up_write(current-mm-mmap_sem);
-   if (error != ELF_PAGESTART(elf_phdata-p_vaddr))
+   if (error != ELF_PAGESTART(eppnt-p_vaddr))
goto out_free_ph;
 
-   elf_bss = elf_phdata-p_vaddr + elf_phdata-p_filesz;
+   elf_bss = eppnt-p_vaddr + eppnt-p_filesz;
if (padzero(elf_bss)) {
error = -EFAULT;
goto out_free_ph;
}
 
-   len = ELF_PAGESTART(elf_phdata-p_filesz + elf_phdata-p_vaddr + 
ELF_MIN_ALIGN - 1);
-   bss = elf_phdata-p_memsz + elf_phdata-p_vaddr;
+   len = ELF_PAGESTART(eppnt-p_filesz + eppnt-p_vaddr + ELF_MIN_ALIGN - 
1);
+   bss = eppnt-p_memsz + eppnt-p_vaddr;
if (bss  len) {
down_write(current-mm-mmap_sem);
do_brk(len, bss - len);
-
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-mm4] perfctr cleanups 3/3: x86

2005-03-18 Thread Mikael Pettersson
x86-specific cleanups for perfctr:
- x86.c: use DEFINE_SPINLOCK().
- asm-i386/perfctr.h: remove cpu_type constants and
  PERFCTR_CPU_VERSION unused in the kernel, use
  explicitly-sized integers in user-visible types, make
  perfctr_cpu_control kernel-private.

Signed-off-by: Mikael Pettersson [EMAIL PROTECTED]

 drivers/perfctr/x86.c  |6 ++---
 include/asm-i386/perfctr.h |   54 +++--
 2 files changed, 21 insertions(+), 39 deletions(-)

diff -rupN linux-2.6.11-mm4/drivers/perfctr/x86.c 
linux-2.6.11-mm4.perfctr-2.7.12/drivers/perfctr/x86.c
--- linux-2.6.11-mm4/drivers/perfctr/x86.c  2005-03-17 19:39:42.0 
+0100
+++ linux-2.6.11-mm4.perfctr-2.7.12/drivers/perfctr/x86.c   2005-03-13 
14:55:58.0 +0100
@@ -1,7 +1,7 @@
-/* $Id: x86.c,v 1.151 2004/11/24 00:28:23 mikpe Exp $
+/* $Id: x86.c,v 1.155 2005/03/13 13:55:58 mikpe Exp $
  * x86/x86_64 performance-monitoring counters driver.
  *
- * Copyright (C) 1999-2004  Mikael Pettersson
+ * Copyright (C) 1999-2005  Mikael Pettersson
  */
 #include linux/config.h
 #include linux/init.h
@@ -135,7 +135,7 @@ static inline void clear_in_cr4_local(un
 
 static unsigned int new_id(void)
 {
-   static spinlock_t lock = SPIN_LOCK_UNLOCKED;
+   static DEFINE_SPINLOCK(lock);
static unsigned int counter;
int id;
 
diff -rupN linux-2.6.11-mm4/include/asm-i386/perfctr.h 
linux-2.6.11-mm4.perfctr-2.7.12/include/asm-i386/perfctr.h
--- linux-2.6.11-mm4/include/asm-i386/perfctr.h 2005-03-17 19:39:43.0 
+0100
+++ linux-2.6.11-mm4.perfctr-2.7.12/include/asm-i386/perfctr.h  2005-03-18 
00:57:10.0 +0100
@@ -1,41 +1,25 @@
-/* $Id: perfctr.h,v 1.57 2004/11/24 00:21:20 mikpe Exp $
+/* $Id: perfctr.h,v 1.61 2005/03/17 23:57:10 mikpe Exp $
  * x86/x86_64 Performance-Monitoring Counters driver
  *
- * Copyright (C) 1999-2004  Mikael Pettersson
+ * Copyright (C) 1999-2005  Mikael Pettersson
  */
 #ifndef _ASM_I386_PERFCTR_H
 #define _ASM_I386_PERFCTR_H
 
-/* cpu_type values */
-#define PERFCTR_X86_GENERIC0   /* any x86 with rdtsc */
-#define PERFCTR_X86_INTEL_P5   1   /* no rdpmc */
-#define PERFCTR_X86_INTEL_P5MMX2
-#define PERFCTR_X86_INTEL_P6   3
-#define PERFCTR_X86_INTEL_PII  4
-#define PERFCTR_X86_INTEL_PIII 5
-#define PERFCTR_X86_CYRIX_MII  6
-#define PERFCTR_X86_WINCHIP_C6 7   /* no rdtsc */
-#define PERFCTR_X86_WINCHIP_2  8   /* no rdtsc */
-#define PERFCTR_X86_AMD_K7 9
-#define PERFCTR_X86_VIA_C3 10  /* no pmc0 */
-#define PERFCTR_X86_INTEL_P4   11  /* model 0 and 1 */
-#define PERFCTR_X86_INTEL_P4M2 12  /* model 2 */
-#define PERFCTR_X86_AMD_K8 13
-#define PERFCTR_X86_INTEL_PENTM14  /* Pentium M */
-#define PERFCTR_X86_AMD_K8C15  /* Revision C */
-#define PERFCTR_X86_INTEL_P4M3 16  /* model 3 and above */
+#include asm/types.h
 
 struct perfctr_sum_ctrs {
-   unsigned long long tsc;
-   unsigned long long pmc[18];
+   __u64 tsc;
+   __u64 pmc[18];  /* the size is not part of the user ABI */
 };
 
 struct perfctr_cpu_control_header {
-   unsigned int tsc_on;
-   unsigned int nractrs;   /* # of a-mode counters */
-   unsigned int nrictrs;   /* # of i-mode counters */
+   __u32 tsc_on;
+   __u32 nractrs;  /* number of accumulation-mode counters */
+   __u32 nrictrs;  /* number of interrupt-mode counters */
 };
 
+#ifdef __KERNEL__
 struct perfctr_cpu_control {
struct perfctr_cpu_control_header header;
unsigned int evntsel[18];   /* primary control registers, physical 
indices */
@@ -47,21 +31,22 @@ struct perfctr_cpu_control {
} p4;
unsigned int pmc_map[18];   /* virtual to physical (rdpmc) index 
map */
 };
+#endif
 
 struct perfctr_cpu_state {
-   unsigned int cstatus;
+   __u32 cstatus;
struct {/* k1 is opaque in the user ABI */
-   unsigned int id;
-   int isuspend_cpu;
+   __u32 id;
+   __s32 isuspend_cpu;
} k1;
/* The two tsc fields must be inlined. Placing them in a
   sub-struct causes unwanted internal padding on x86-64. */
-   unsigned int tsc_start;
-   unsigned long long tsc_sum;
+   __u32 tsc_start;
+   __u64 tsc_sum;
struct {
-   unsigned int map;
-   unsigned int start;
-   unsigned long long sum;
+   __u32 map;
+   __u32 start;
+   __u64 sum;
} pmc[18];  /* the size is not part of the user ABI */
 #ifdef __KERNEL__
struct perfctr_cpu_control control;
@@ -132,9 +117,6 @@ static inline unsigned int perfctr_cstat
 #endif
 #define si_pmc_ovf_mask_sifields._pad[0] /* XXX: use an unsigned field 
later */
 
-/* version number for user-visible CPU-specific data */
-#define PERFCTR_CPU_VERSION0x0500  /* 5.0 */
-
 #ifdef __KERNEL__
 
 #if defined(CONFIG_PERFCTR)
-
To unsubscribe 

Need break driver--pci-device automatic association

2005-03-18 Thread Jacques Goldberg

 Not subscribing because this is a one time question.
 Please Cc: to the reply address above , [EMAIL PROTECTED]

 Several winmodem devices come with a hardware burnt-in identification
misleading the system to load the serial driver.
 As a result, it is not possible to load the special driver because the
PCI device is grabbed by the serial driver.

 Question: is there a way, as of kernels 2.6.10 and above, to release the
device from the serial driver, without having to recompile the kernel?

 We know how to attain the goal by patching 8250_pci.c but doing this will
quickly generate chaos. We know to detect the condition in the custom
driver. The fix would be trivial if we could  break the tie with the
serial driver.

Thanks - Jacques
-
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/


USB pen drive connect/disconnect oops

2005-03-18 Thread Simon Geard
When I connect and disconnect my new USB Pen drive (BAR 512MB) I get 
stack dump messages from the kernel. The drive does seem to be usable at 
the end of this sequence albeit very slowly. Disconnection gives a 
kernel oops and the device isn't usable until the next reboot. Does 
anyone know if there is a patch to fix this problem?

Please cc any replies to me. Thanks
Simon Geard
Linux localhost 2.6.8.1-12mdk #1 Fri Oct 1 12:53:41 CEST 2004 i686 
Unknown CPU Type unknown GNU/Linux

Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
 Vendor: USB   Model: BAR   Rev: 2.00
 Type:   Direct-Access  ANSI SCSI revision: 02
USB Mass Storage device found at 3
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
sda: Unit Not Ready, sense:
Current : sense key Unit Attention
Additional sense: Not ready to ready change, medium may have changed
sda : READ CAPACITY failed.
sda : status=1, message=00, host=0, driver=08
Current sd: sense key Unit Attention
Additional sense: Not ready to ready change, medium may have changed
sda: test WP failed, assume Write Enabled
sda: assuming drive cache: write through
sda: Unit Not Ready, sense:
Current : sense key Unit Attention
Additional sense: Not ready to ready change, medium may have changed
sda : READ CAPACITY failed.
sda : status=1, message=00, host=0, driver=08
Current sd: sense key Unit Attention
Additional sense: Not ready to ready change, medium may have changed
sda: test WP failed, assume Write Enabled
sda: assuming drive cache: write through
SCSI device sda: 1023744 512-byte hdwr sectors (524 MB)
sda: Write Protect is off
sda: Mode Sense: 03 00 00 00
sda: assuming drive cache: write through
/dev/scsi/host0/bus0/target0/lun0:3Buffer I/O error on device sda, 
logical block 262143
Buffer I/O error on device sda, logical block 262143
p1
/dev/scsi/host0/bus0/target0/lun0:3Buffer I/O error on device sda, 
logical block 262143
p1
devfs_mk_dev: could not append to parent for 
scsi/host0/bus0/target0/lun0/part1
kobject_register failed for sda1 (-17)
[c0107bfe] dump_stack+0x1e/0x20
[c01c179b] kobject_register+0x5b/0x70
[c018c433] add_partition+0x103/0x140
[c018c61e] register_disk+0x14e/0x1d0
[c021909b] add_disk+0x4b/0x60
[e0b3f21d] sd_probe+0x21d/0x380 [sd_mod]
[c021067d] bus_match+0x3d/0x80
[c02107b2] driver_attach+0x52/0xa0
[c0210cbf] bus_add_driver+0x8f/0xc0
[c02112a1] driver_register+0x31/0x40
[e0a2105a] init_sd+0x5a/0x6f [sd_mod]
[c01337a2] sys_init_module+0xd2/0x1c0
[c0106dcd] sysenter_past_esp+0x52/0x71
Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0

When I disconnect the device I get
usb 4-2.1: USB disconnect, address 3
Unable to handle kernel NULL pointer dereference at virtual address 0050
printing eip:
c0192d61
*pde = 
Oops:  [#1]
Modules linked in: sd_mod usb-storage fglrx md5 ipv6 rfcomm l2cap 
bluetooth es1371 soundcore gameport ac97_codec lp parport_pc parport 
af_packet floppy 8139too mii ide-cd cdrom loop ext3 jbd nls_iso8859-15 
ntfs xfs supermount amd-k7-agp agpgart dc395x scsi_mod tsdev joydev 
evdev usbmouse ehci-hcd usbhid ohci-hcd uhci-hcd usbcore reiserfs
CPU:0
EIP:0060:[c0192d61]Tainted: P   VLI
EFLAGS: 00010246   (2.6.8.1-12mdk)
EIP is at sysfs_remove_dir+0x21/0x110
eax: d0a79cf0   ebx: d0a79cf0   ecx:    edx: dffef360
esi: d04d6520   edi:    ebp: dedf9d90   esp: dedf9d74
ds: 007b   es: 007b   ss: 0068
Process khubd (pid: 815, threadinfo=dedf8000 task=df732c70)
Stack: d04d6520 0001 dedf9d90 c01c1586 d0a79cf0 d04d6520 0001 
dedf9da4
  c01c18f2 d0a79cf0 d0a79cf0 d0a79cf0 dedf9db4 c01c1912 d0a79cf0 
c1572800
  dedf9dd0 c018c929 d0a79cf0 0001 d0569984 d04d6520 c1572200 
dedf9de4
Call Trace:
[c0107bbf] show_stack+0x7f/0xa0
[c0107d56] show_registers+0x156/0x1d0
[c0107ef6] die+0x66/0xd0
[c0119b26] do_page_fault+0x3c6/0x5b0
[c0107849] error_code+0x2d/0x38
[c01c18f2] kobject_del+0x22/0x30
[c01c1912] kobject_unregister+0x12/0x20
[c018c929] del_gendisk+0x29/0xf0
[e0b3f39d] sd_remove+0x1d/0x60 [sd_mod]
[c0210866] device_release_driver+0x66/0x70
[c0210ad2] bus_remove_device+0x62/0xa0
[c020f8d9] device_del+0x59/0xc0
[e0ad6196] scsi_remove_device+0x56/0xb0 [scsi_mod]
[e0ad54aa] scsi_forget_host+0x2a/0x50 [scsi_mod]
[e0ace228] scsi_remove_host+0x28/0x60 [scsi_mod]
[e0b9109d] storage_disconnect+0x5d/0x70 [usb-storage]
[e0a420fd] usb_unbind_interface+0x6d/0x70 [usbcore]
[c0210866] device_release_driver+0x66/0x70
[c0210ad2] bus_remove_device+0x62/0xa0
[c020f8d9] device_del+0x59/0xc0
[e0a496b8] usb_disable_device+0x88/0x100 [usbcore]
[e0a44433] usb_disconnect+0xb3/0x150 [usbcore]
[e0a45c0f] hub_port_connect_change+0x23f/0x3d0 [usbcore]
[e0a45f43] hub_events+0x1a3/0x3a0 [usbcore]
[e0a46175] hub_thread+0x35/0x100 [usbcore]
[c01052c5] kernel_thread_helper+0x5/0x10
Code: ff ff ff 8d b4 26 00 00 00 00 55 89 e5 57 56 53 83 ec 10 8b 45 08 
8b 78 30 85 ff 74 0c 8b 07 85 c0 0f 84 dc 00 00 00 ff 07 85 

Re: BKCVS broken ?

2005-03-18 Thread Stelian Pop
On Thu, Mar 17, 2005 at 10:38:53PM -0800, Larry McVoy wrote:

 Hey, it's open source, I'm hoping that people will take that code and
 evolve it do whatever they need.  We're willing to do what we can on
 this end if people need protocol changes to support new features, 
 time permitting.  Think of that code as a prototype.  It's really
 simple, you can hack it trivially.


if (strncmp(bk://, p, 5)) return (1);


Any chance this could be made to work over http ?

Stelian.
-- 
Stelian Pop [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] Xen/i386 cleanups - AGP bus/phys cleanups

2005-03-18 Thread Keir Fraser
On 18 Mar 2005, at 00:16, Paul Mackerras wrote:
That sounds like a good way to make AGP accesses slower. :)
Seriously, given that AGP is a technology that is being superseded by
PCI Express, I think it's reasonable to look at the range of current
implementations to see what we have to cope with.  So I don't think
it's worth worrying too much about the possibility of GARTs that go
through the IOMMU.  However, the idea of having phys_to_agp/agp_to_phys
(or virt_to_agp/agp_to_virt) sounds like it wouldn't be too much
effort, if it would help Xen.
I'll post a patch for this next week. Thanks for your patience so far!
 -- Keir
-
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

2005-03-18 Thread Ingo Molnar

* Paul E. McKenney [EMAIL PROTECTED] wrote:

 4. Preemptible read side.
 
   RCU read-side critical sections can (in theory, anyway) be quite
   large, degrading realtime scheduling response.  Preemptible RCU
   read-side critical sections avoid such degradation.  Manual
   insertion of preemption points might be an alternative as well.
   But I have no intention of trying to settle the long-running
   argument between proponents of preemption and of preemption
   points.  Not today, anyway!  ;-)

i'm cleverly sidestepping that argument by offering 4 preemption models
in the -RT tree :-) We dont have to pick a winner, users will. The way
low latencies are achieved depends on the preemption model:

   ( ) No Forced Preemption (Server)
   ( ) Voluntary Kernel Preemption (Desktop)
   ( ) Preemptible Kernel (Low-Latency Desktop)
   (X) Complete Preemption (Real-Time)

Server is the current default !PREEMPT model. Best throughput, bad
worst-case latencies.

Low-Latency Desktop is the current PREEMPT model. Has some runtime
overhead relative to Server, offers fair worst-case latencies.

Desktop is a new mode that is somewhere between Server and Low-Latency
Desktop: it's what was initially called 'voluntary preemption'. It
doesnt make the kernel forcibly preemptible anywhere, but inserts a fair
number of preemption points to decrease latencies statistically, while
keeping the runtime overhead close to the Server. (a variant of this
model is utilized by Fedora and RHEL4 currently, so if this gets
upstream i expect distros to pick it up - it can be a migration helper
towards the Low-Latency Desktop model.)

Real-Time is the no-compromises hard-RT model: almost everything but
the scheduler itself is fully preemptible. Phenomenal worst-case
latencies in every workload scenario, but also has the highest runtime
overhead.

preemptable RCU makes sense for the Low-Latency Desktop and
Real-Time preemption models - these are the ones that do forced
preemption.

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: Potential DOS in load_elf_library?

2005-03-18 Thread Andrew Morton
Herbert Xu [EMAIL PROTECTED] wrote:

 Yichen Xie [EMAIL PROTECTED] wrote:
   Hi guys, I was looking at the load_elf_library function (fs/binfmt_elf.c) 
   in 2.6.10, and noticed the following:
   
  elf_phdata = (struct elf_phdr *) kmalloc(j, GFP_KERNEL);
  ...
  while (elf_phdata-p_type != PT_LOAD) elf_phdata++;
  ...
  kfree(elf_phdata);
   
   Could this be problematic since the pointer being freed might be different 
   from that returned from kmalloc?
 
  Indeed.  This bug has been around since last century.

Duh, I was looking at the wrong function.  Thanks.

  How does this look?

I think it'd be better to use epptr everywhere, so we can see that it only
gets assigned, tested then freed.

--- 25/fs/binfmt_elf.c~load_elf_binary-kfree-fix2005-03-18 
01:00:49.0 -0800
+++ 25-akpm/fs/binfmt_elf.c 2005-03-18 01:03:14.0 -0800
@@ -1028,6 +1028,7 @@ out_free_ph:
 static int load_elf_library(struct file *file)
 {
struct elf_phdr *elf_phdata;
+   struct elf_phdr *eppnt;
unsigned long elf_bss, bss, len;
int retval, error, i, j;
struct elfhdr elf_ex;
@@ -1051,44 +1052,47 @@ static int load_elf_library(struct file 
/* j  ELF_MIN_ALIGN because elf_ex.e_phnum = 2 */
 
error = -ENOMEM;
-   elf_phdata = (struct elf_phdr *) kmalloc(j, GFP_KERNEL);
+   elf_phdata = kmalloc(j, GFP_KERNEL);
if (!elf_phdata)
goto out;
 
+   eppnt = elf_phdata;
error = -ENOEXEC;
-   retval = kernel_read(file, elf_ex.e_phoff, (char *) elf_phdata, j);
+   retval = kernel_read(file, elf_ex.e_phoff, (char *)eppnt, j);
if (retval != j)
goto out_free_ph;
 
for (j = 0, i = 0; ielf_ex.e_phnum; i++)
-   if ((elf_phdata + i)-p_type == PT_LOAD) j++;
+   if ((eppnt + i)-p_type == PT_LOAD)
+   j++;
if (j != 1)
goto out_free_ph;
 
-   while (elf_phdata-p_type != PT_LOAD) elf_phdata++;
+   while (eppnt-p_type != PT_LOAD)
+   eppnt++;
 
/* Now use mmap to map the library into memory. */
down_write(current-mm-mmap_sem);
error = do_mmap(file,
-   ELF_PAGESTART(elf_phdata-p_vaddr),
-   (elf_phdata-p_filesz +
-ELF_PAGEOFFSET(elf_phdata-p_vaddr)),
+   ELF_PAGESTART(eppnt-p_vaddr),
+   (eppnt-p_filesz +
+ELF_PAGEOFFSET(eppnt-p_vaddr)),
PROT_READ | PROT_WRITE | PROT_EXEC,
MAP_FIXED | MAP_PRIVATE | MAP_DENYWRITE,
-   (elf_phdata-p_offset -
-ELF_PAGEOFFSET(elf_phdata-p_vaddr)));
+   (eppnt-p_offset -
+ELF_PAGEOFFSET(eppnt-p_vaddr)));
up_write(current-mm-mmap_sem);
-   if (error != ELF_PAGESTART(elf_phdata-p_vaddr))
+   if (error != ELF_PAGESTART(eppnt-p_vaddr))
goto out_free_ph;
 
-   elf_bss = elf_phdata-p_vaddr + elf_phdata-p_filesz;
+   elf_bss = eppnt-p_vaddr + eppnt-p_filesz;
if (padzero(elf_bss)) {
error = -EFAULT;
goto out_free_ph;
}
 
-   len = ELF_PAGESTART(elf_phdata-p_filesz + elf_phdata-p_vaddr + 
ELF_MIN_ALIGN - 1);
-   bss = elf_phdata-p_memsz + elf_phdata-p_vaddr;
+   len = ELF_PAGESTART(eppnt-p_filesz + eppnt-p_vaddr + ELF_MIN_ALIGN - 
1);
+   bss = eppnt-p_memsz + eppnt-p_vaddr;
if (bss  len) {
down_write(current-mm-mmap_sem);
do_brk(len, bss - len);
_

-
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: Potential DOS in load_elf_library?

2005-03-18 Thread Herbert Xu
On Fri, Mar 18, 2005 at 01:05:01AM -0800, Andrew Morton wrote:
 
 I think it'd be better to use epptr everywhere, so we can see that it only
 gets assigned, tested then freed.

Looks good to me.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [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/


insmod segfault in pci_find_subsys()

2005-03-18 Thread Toralf Lund
Hi.
I'm having some major issues with a custom module I'm hacking on 
(actually maintained by someone else, but I've done odd bits of 
development.) I simply get a segfault at module install time, and the 
problem seems to occur while the module is scanning the PCI bus. The 
error log from one instance is included below. The actual error message 
varies - I have seen at least 3 different variants:

  1. Unable to handle kernel paging request
  2. Unable to handle kernel NULL pointer dereference
  3. general protection fault
As far as I can tell, the problem always occurs at the same point, 
however - or at list in the same function, namely pci_find_subsys(). 
Actually, I have a very simple module based on the original one, which 
I'm using to reproduce the problem - this is the itifg8tst mentioned 
in the log. Source code is included below. Try to build as module 
itifg8tst.ko, then do insmod itifg8tst.ko and see what happens.

This originally happened on a Red Hat Linux EL system with Linux 2.6.9, 
but I've later reproduced it with 2.6.11.4 from kernel.org. I've seen it 
on two hosts with completely different hardware setup. lspci output 
from one of them is also included.

Am I seeing an issue with the PCI functions here, or is it just that I 
fail to spot an obvious mistake in the module itself?

- Toralf

Mar 18 09:17:49 localhost kernel: itifg Scanning all devices...
Mar 18 09:17:49 localhost kernel: general protection fault:  [#1]
Mar 18 09:17:49 localhost kernel: Modules linked in: itifg8tst video button battery ac uhci_hcd ehci_hcd snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc tg3 floppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod ata_piix libata sd_mod scsi_mod
Mar 18 09:17:49 localhost kernel: CPU:0
Mar 18 09:17:49 localhost kernel: EIP:0060:[c021481a]Not tainted VLI
Mar 18 09:17:49 localhost kernel: EFLAGS: 00010286   (2.6.11.4-0.EL.toralf2) 
Mar 18 09:17:49 localhost kernel: EIP is at pci_find_subsys+0xaa/0x280
Mar 18 09:17:49 localhost kernel: eax:    ebx:    ecx:    edx: 
Mar 18 09:17:49 localhost kernel: esi: 00ac   edi: 0021   ebp:    esp: c23c1f30
Mar 18 09:17:49 localhost kernel: ds: 007b   es: 007b   ss: 0068
Mar 18 09:17:49 localhost kernel: Process insmod (pid: 2235, threadinfo=c23c task=f7cc39f0)
Mar 18 09:17:49 localhost kernel: Stack: c03ae458 65636976 2e2e2e73 f7ef1000     
Mar 18 09:17:49 localhost kernel:  0021 c23c c0214a2a    
Mar 18 09:17:49 localhost kernel:06e9 47c12378 f892c053    0804a018 f88f1580 
Mar 18 09:17:49 localhost kernel: Call Trace:
Mar 18 09:17:49 localhost kernel:  [c0214a2a] pci_find_device+0x3a/0x50
Mar 18 09:17:49 localhost kernel:  [f892c053] iti_os_attach+0x53/0x60 [itifg8tst]
Mar 18 09:17:49 localhost kernel:  [c0144a42] sys_init_module+0x1f2/0x330
Mar 18 09:17:49 localhost kernel:  [c01799c8] filp_close+0x48/0x90
Mar 18 09:17:49 localhost kernel:  [c010397d] sysenter_past_esp+0x52/0x75
Mar 18 09:17:49 localhost kernel: Code: 00 00 be ac 00 00 00 a3 00 56 3e c0 b8 50 34 3a c0 a3 0c 56 3e c0 a1 e8 52 3e c0 89 35 10 56 3e c0 89 44 24 0c 31 c0 85 db 74 02 8b 03 89 44 24 08 89 5c 24 04 c7 04 24 7c e4 3a c0 e8 40 cf f0 


% /sbin/lspci
00:00.0 Host bridge: Intel Corp. 82875P/E7210 Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corp. 82875P Processor to AGP Controller (rev 02)
00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI Controller
#1 (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI Controller
#2 (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 
02)00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI 
Controller (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2)
00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge 
(rev 02)
00:1f.2 IDE interface: Intel Corp. 82801EB (ICH5) SATA Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) AC'97 
Audio Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV18GL [Quadro4 380 XGL] 
(rev a2)
05:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5782 Gigabit 
Ethernet (rev 03)

#include linux/version.h/* LINUX_VERSION_CODE */
#include linux/pci.h/* pci specific stuff */
#ifdef MODULE
#include linux/module.h /* init_/cleanup_ module */
MODULE_DESCRIPTION(CorecoImaging device driver test);
MODULE_AUTHOR(Matthias Stein);
#if LINUX_VERSION_CODE = 0x02040a /* 2.4.10 */
MODULE_LICENSE(GPL);
#endif
#define ITI_LOG_STRING itifg 
int

Re: Real-Time Preemption and RCU

2005-03-18 Thread Ingo Molnar

* Paul E. McKenney [EMAIL PROTECTED] wrote:

 I have tested this approach, but in user-level scaffolding.  All of
 these implementations should therefore be regarded with great
 suspicion: untested, probably don't even compile.  Besides which, I
 certainly can't claim to fully understand the real-time preempt patch,
 so I am bound to have gotten something wrong somewhere. [...]

you dont even have to consider the -RT patchset: if the scheme allows
forced preemption of read-side RCU sections on current upstream
CONFIG_PREEMPT, then it's perfect for PREEMPT_RT too.

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/


[PATCH] reduce inlined x86 memcpy by 2 bytes

2005-03-18 Thread Denis Vlasenko
This memcpy() is 2 bytes shorter than one currently in mainline
and it have one branch less. It is also 3-4% faster in microbenchmarks
on small blocks if block size is multiple of 4. Mainline is slower
because it has to branch twice per memcpy, both mispredicted
(but branch prediction hides that in microbenchmark).

Last remaining branch can be dropped too, but then we execute second
'rep movsb' always, even if blocksize%4==0. This is slower than mainline
because 'rep movsb' is microcoded. I wonder, tho, whether 'branchlessness'
wins over this in real world use (not in bench).

I think blocksize%4==0 happens more than 25% of the time.

This is how many 'allyesconfig' vmlinux gains on branchless memcpy():

# size vmlinux.org vmlinux.memcpy
   textdata bss dec hex filename
181789506293427 1808916 26281293191054d vmlinux.org
181651606293427 1808916 26267503190cf6f vmlinux.memcpy

# echo $(( (18178950-18165160) ))
13790 = bytes saved on allyesconfig

# echo $(( (18178950-18165160)/4 ))
3447 = memcpy() callsites optimized

Attached patch (with one branch) would save 6.5k instead of 13k.

Patch is run tested.
--
vda
--- linux-2.6.11.src/include/asm-i386/string.h.orig	Thu Mar  3 09:31:08 2005
+++ linux-2.6.11.src/include/asm-i386/string.h	Fri Mar 18 10:55:51 2005
@@ -198,15 +198,13 @@ static inline void * __memcpy(void * to,
 int d0, d1, d2;
 __asm__ __volatile__(
 	rep ; movsl\n\t
-	testb $2,%b4\n\t
-	je 1f\n\t
-	movsw\n
-	1:\ttestb $1,%b4\n\t
-	je 2f\n\t
-	movsb\n
-	2:
+	movl %4,%%ecx\n\t
+	andl $3,%%ecx\n\t
+	jz 1f\n\t	/* pay 2 byte penalty for a chance to skip microcoded rep */
+	rep ; movsb\n\t
+	1:
 	: =c (d0), =D (d1), =S (d2)
-	:0 (n/4), q (n),1 ((long) to),2 ((long) from)
+	: 0 (n/4), g (n), 1 ((long) to), 2 ((long) from)
 	: memory);
 return (to);
 }


Re: [PATCH 2.6.11.4 1/1] fs: new filesystem implementation VXEXT1.0

2005-03-18 Thread Jens Langner
Chris Wedgwood wrote:
The VXEXT filesystem is more or less a FAT16 based filesystem which
was slightly modified by Wind River to allow the storage of more
than 2GB data on a partition, as well as storing filenames with a
maximum of 40 characters length.
Can this not then be folded into the existing vfat filesystem?
Sure it can. But I thought that as the VXEXT1.0 filesystem is per 
definition not a vfat filesystem it might be better to have it separated 
and not drill it into the IMHO anyway overly mixed up vfat/fat code 
already in the linux kernel tree. Even if that means that some parts in 
the code of the vxext filesystem are probably equal to the msdos 
implementation, please note that large parts which were not needed by 
the vxext implementation was dropped by me for clarifications.

So I still hope that my implementation is going to be considered for a 
future kernel tree integration as it may be quite usefull for embeeded 
systems wanting to access VxWorks partitions.

cheers,
jens
--
Jens Langner Ph: +49-351-4716545
Lannerstrasse 1
01219 Dresden[EMAIL PROTECTED]
Germany  http://www.jens-langner.de/
-
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 lame schedule in journal inverted_lock (was: Re: [patch 0/3] j_state_lock, j_list_lock, remove-bitlocks)

2005-03-18 Thread Steven Rostedt

Andrew,

Since I haven't gotten a response from you, I'd figure that you may have
missed this, since the subject didn't change.  So I changed the subject to
get your attention, and I've resent this. Here's the patch to get rid of
the the lame schedule that was in fs/jbd/commit.c.   Let me know if this
patch is appropriate.

Thanks,

-- Steve


On Thu, 17 Mar 2005, Steven Rostedt wrote:



 On Wed, 16 Mar 2005, Andrew Morton wrote:

I guess one way to solve this is to add a wait queue here (before
schedule()), and have the one holding the lock to wake up all on the
waitqueue when they release it.
 
  yup.  A patch against mainline would be appropriate, please.
 

 Hi Andrew,

 Here's the patch against 2.6.11.  I tested it, by adding (after making the
 patch) global spinlocks for jbd_lock_bh_state and jbd_lock_bh_journalhead.
 That way I have same scenerio as with Ingo's kernel, and I turned on
 NEED_JOURNAL_STATE_WAIT.  I'm still running that kernel so it looks like
 it works.  Making those two locks global causes this deadlock on kjournal
 much quicker, and I don't need to run on an SMP machine (since my SMP
 machines are currently being used for other tasks).

 Some comments on my patch.  I only implement the wait queue when
 bit_spin_trylock is an actual lock (thus creating the problem). I didn't
 want to add this code if it was needed (ie. !(CONFIG_SMP 
 CONFIG_DEBUG_SPINLOCKS)).  So in bit_spin_trylock, I define
 NEED_JOURNAL_STATE_WAIT if bit_spin_trylock is really a lock.  When
 NEED_JOURNAL_STATE_WAIT is set, then the wait queue is set up in the
 journal code.

 Now the question is, should we make those two locks global? It would help
 Ingo's cause (and mine as well). But I don't know the impact on a large
 SMP configuration.  Andrew, since you have a 16xSMP machine, could you (if
 you have time) try out the effect of that. If you do have time, then I'll
 send you a patch that goes on top of this one to change the two locks into
 global spin locks.

 Ingo, where do you want to go from here? I guess we need to wait on what
 Andrew decides.

 -- Steve



diff -ur linux-2.6.11.orig/fs/jbd/commit.c linux-2.6.11/fs/jbd/commit.c
--- linux-2.6.11.orig/fs/jbd/commit.c   2005-03-02 02:38:25.0 -0500
+++ linux-2.6.11/fs/jbd/commit.c2005-03-17 03:40:06.0 -0500
@@ -80,15 +80,33 @@

 /*
  * Try to acquire jbd_lock_bh_state() against the buffer, when j_list_lock is
- * held.  For ranking reasons we must trylock.  If we lose, schedule away and
- * return 0.  j_list_lock is dropped in this case.
+ * held.  For ranking reasons we must trylock.  If we lose put ourselves on a
+ * state wait queue and we'll be woken up when it is unlocked. Then we return
+ * 0 to try this again.  j_list_lock is dropped in this case.
  */
 static int inverted_lock(journal_t *journal, struct buffer_head *bh)
 {
if (!jbd_trylock_bh_state(bh)) {
+   /*
+* jbd_trylock_bh_state always returns true unless CONFIG_SMP or
+* CONFIG_DEBUG_SPINLOCK, so the wait queue is not needed there.
+* The bit_spin_locks in jbd_lock_bh_state need to be removed 
anyway.
+*/
+#ifdef NEED_JOURNAL_STATE_WAIT
+   DECLARE_WAITQUEUE(wait, current);
spin_unlock(journal-j_list_lock);
-   schedule();
+   add_wait_queue_exclusive(journal_state_wait,wait);
+   set_current_state(TASK_UNINTERRUPTIBLE);
+   /* Check to see if the lock has been unlocked in this short 
time */
+   if (jbd_is_locked_bh_state(bh))
+   schedule();
+   set_current_state(TASK_RUNNING);
+   remove_wait_queue(journal_state_wait,wait);
return 0;
+#else
+   /* This should never be hit */
+   BUG();
+#endif
}
return 1;
 }
diff -ur linux-2.6.11.orig/fs/jbd/journal.c linux-2.6.11/fs/jbd/journal.c
--- linux-2.6.11.orig/fs/jbd/journal.c  2005-03-02 02:37:49.0 -0500
+++ linux-2.6.11/fs/jbd/journal.c   2005-03-17 03:47:40.0 -0500
@@ -80,6 +80,11 @@
 EXPORT_SYMBOL(journal_try_to_free_buffers);
 EXPORT_SYMBOL(journal_force_commit);

+#ifdef NEED_JOURNAL_STATE_WAIT
+EXPORT_SYMBOL(journal_state_wait);
+DECLARE_WAIT_QUEUE_HEAD(journal_state_wait);
+#endif
+
 static int journal_convert_superblock_v1(journal_t *, journal_superblock_t *);

 /*
diff -ur linux-2.6.11.orig/include/linux/jbd.h linux-2.6.11/include/linux/jbd.h
--- linux-2.6.11.orig/include/linux/jbd.h   2005-03-02 02:38:19.0 
-0500
+++ linux-2.6.11/include/linux/jbd.h2005-03-17 03:48:18.0 -0500
@@ -324,6 +324,20 @@
return bh-b_private;
 }

+#ifdef NEED_JOURNAL_STATE_WAIT
+/*
+ * The journal_state_wait is a wait queue that tasks will wait on
+ * if they fail to get the jbd_lock_bh_state while holding the j_list_lock.
+ * Instead of spinning on schedule, the task now adds itself to this wait queue
+ * 

Re: Real-Time Preemption and RCU

2005-03-18 Thread Ingo Molnar

* Ingo Molnar [EMAIL PROTECTED] wrote:

 
 * Paul E. McKenney [EMAIL PROTECTED] wrote:
 
  I have tested this approach, but in user-level scaffolding.  All of
  these implementations should therefore be regarded with great
  suspicion: untested, probably don't even compile.  Besides which, I
  certainly can't claim to fully understand the real-time preempt patch,
  so I am bound to have gotten something wrong somewhere. [...]
 
 you dont even have to consider the -RT patchset: if the scheme allows
 forced preemption of read-side RCU sections on current upstream
 CONFIG_PREEMPT, then it's perfect for PREEMPT_RT too.

there's one detail on PREEMPT_RT though (which i think you noticed too). 

Priority inheritance handling can be done in a pretty straightforward
way as long as no true read-side nesting is allowed for rwsems and
rwlocks - i.e. there's only one owner of a lock at a time. So PREEMPT_RT
restricts rwsem and rwlock concurrency: readers are writers, with the
only exception that they are allowed to 'self-nest'. I.e. things like:

read_lock(rwlock);
...
read_lock(rwlock);

are still legal. (it's also done quite often.)

(it is virtually impossible to implement priority inheritance for true
multi-reader locks in any sane way: i've done it initially and it sucks
very much. It also fundamentally increases the 'lock-dependent'
worst-case latencies - imagine 4 readers having to finish first if a
higher-prio writer comes along. It's insane.)

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: ppc64 build broke between 2.6.11-bk6 and 2.6.11-bk7

2005-03-18 Thread Mikael Pettersson
Andrew Morton writes:
  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.

It seems the culprit is matroxfb-compile-error.patch which unconditionally 
adds
macmodes.o to the Makefile line for CONFIG_FB_MATROX. This obviously breaks on 
!ppc.
The patch Andrew mentions above converts the Kconfig entry for FB_MATROX to do a
select FB_MACMODES if PPC_PMAC, so dropping matroxfb-compile-error.patch 
should suffice.

/Mikael
-
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: [UART] 8250:RTS/CTS flow control issue.

2005-03-18 Thread moreau francis

--- Russell King [EMAIL PROTECTED] wrote:
 If you want it to be immediate, then I'm afraid
 you're going to have a
 relatively hard time, with compatibility problems
 with various systems.
 You can't really dictate to people that they must
 turn off the FIFOs on
 their UARTs for your product to work.  (Well, you
 can, but _you_ would
 have to support them.)
 

well, I don't specially wan't to be immediate.
My hardware has auto flow control and a 8 bytes
fifo...So *whatever* the trigger level is for RTS
(actually I can't tune it), I will overrun because 
the end *driver*, which should be aware of the lack of
its hw auto flow control, decides to fill up its tx
fifo to 8 bytes when transmiting...

One other solution may be to give the possibility of
the user to tune the size of tx fifo ?

thanks

  Francis






Découvrez nos promotions exclusives destination de la Tunisie, du Maroc, des 
Baléares et la Rép. Dominicaine sur Yahoo! Voyages :
http://fr.travel.yahoo.com/promotions/mar14.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/


Re: [PATCH] remove lame schedule in journal inverted_lock (was: Re: [patch 0/3] j_state_lock, j_list_lock, remove-bitlocks)

2005-03-18 Thread Andrew Morton
Steven Rostedt [EMAIL PROTECTED] wrote:

 
 Andrew,
 
 Since I haven't gotten a response from you,

It sometimes takes me half a day to get onto looking at patches.  And if I
take them I usually don't reply (sorry).  But I don't drop stuff, so if you
don't hear, please assume the patch stuck.  If others raise objections
to the patch I'll usually duck it as well, but it's pretty obvious when that
happens.

I really should knock up a script to send out an email when I add a patch
to -mm.

 I'd figure that you may have
 missed this, since the subject didn't change.  So I changed the subject to
 get your attention, and I've resent this. Here's the patch to get rid of
 the the lame schedule that was in fs/jbd/commit.c.   Let me know if this
 patch is appropriate.

I'm rather aghast at all the ifdeffery and complexity in this one.  But I
haven't looked at it closely yet.

-
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

2005-03-18 Thread Mikael Pettersson
Mikael Pettersson writes:
  Andrew Morton writes:
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.
  
  It seems the culprit is matroxfb-compile-error.patch which unconditionally 
  adds
  macmodes.o to the Makefile line for CONFIG_FB_MATROX. This obviously breaks 
  on !ppc.

!pmac of course; I assume Martin configured for some kind of POWER box and not 
a G5.

  The patch Andrew mentions above converts the Kconfig entry for FB_MATROX to 
  do a
  select FB_MACMODES if PPC_PMAC, so dropping matroxfb-compile-error.patch 
  should suffice.
-
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

2005-03-18 Thread Ingo Molnar

* Ingo Molnar [EMAIL PROTECTED] wrote:

 * Paul E. McKenney [EMAIL PROTECTED] wrote:
 
  4. Preemptible read side.
  
  RCU read-side critical sections can (in theory, anyway) be quite
  large, degrading realtime scheduling response.  Preemptible RCU
  read-side critical sections avoid such degradation.  Manual
  insertion of preemption points might be an alternative as well.
  But I have no intention of trying to settle the long-running
  argument between proponents of preemption and of preemption
  points.  Not today, anyway!  ;-)
 
 i'm cleverly sidestepping that argument by offering 4 preemption
 models in the -RT tree :-) We dont have to pick a winner, users will.
 [...]

also, it turned out that preemption points vs. forced preemption are
not exclusive concepts: PREEMPT_RT relies on _both_ of them.

when a highprio task tries to acquire a lock that another, lower-prio
task already holds, then 'the time it takes for the lowprio task to drop
the lock' directly depends on the frequency of explicit preemption
points within the critical section. So to get good 'lock dependent'
latencies on PREEMPT_RT we need both a good distribution of preemption
points (within locked sections).

(obviously, 'lock independent' preemption latencies purely depends on
the quality of forced preemption and the size of non-preempt critical
sections, not on any explicit preemption point.)

dont we love seemingly conflicting concepts that end up helping each
other? It's a nice flamewar-killer ;-)

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: Real-Time Preemption and RCU

2005-03-18 Thread Ingo Molnar

* Ingo Molnar [EMAIL PROTECTED] wrote:

 there's one detail on PREEMPT_RT though (which i think you noticed too). 
 
 Priority inheritance handling can be done in a pretty straightforward
 way as long as no true read-side nesting is allowed for rwsems and
 rwlocks - i.e. there's only one owner of a lock at a time. So
 PREEMPT_RT restricts rwsem and rwlock concurrency: readers are
 writers, with the only exception that they are allowed to 'self-nest'.
 [...]

this does not affect read-side RCU, because read-side RCU can never
block a higher-prio thread. (as long as callback processing is pushed
into a separate kernel thread.)

so RCU will be pretty much the only mechanism (besides lock-free code)
that allows reader concurrency on PREEMPT_RT.

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: [PATCH] add a clear_pages function to clear pages of higher order

2005-03-18 Thread Denis Vlasenko
On Thursday 17 March 2005 03:33, Christoph Lameter wrote:
 On Fri, 11 Mar 2005, Denis Vlasenko wrote:
 
  Andi Kleen (iirc) says that non-temporal stores seem to be
  big win in microbenchmarks (and I second that), but they are
  a net loss when we are going to use zeroed page just after
  zeroing. He recommends avoid using non-temporal stores
 
  With this new page prezeroing infrastructure, that argument
  most likely is not right anymore. Especially clearing of
  high-order pages definitely will benefit from NT stores
  because they do not kill L1 data cache in the process.
 
  I don't have K8 and therefore cannot be 100% sure, but
  I really doubt that K8 optimize rep stosq into _NT_ stores.
 
 Hmm. That would be interesting to know and may be necessary to justify
 the continued existence of this patch. I tried to get some numbers on
 the performance wins for zeroing larger pages with the patch as is (no
 NT stores) and came up with:
 
 Processor Performance Increase
 
 Itanium 2 1.3Ghz M1/R51.5%
 AMD Athlon 64 3200+ i386 mode 3%
 AMD Athlon 64 3200+ x86_64 mode   3.3%
 
 (this is if the zeroing engine is the cpu of course. Prezeroing
 may be done through some DMA gizmo independent of the cpu)
 
 Itanium has more extensive optimization capabilities and
 seems to be able to better cope with the loop logic for regular
 clear_page. Thus the improvement is even less on Itanium.
 
 Numbers obtained with the following patch that allows to get performance
 data from /proc/meminfo on zeroing performance (just divide Cycles by
 Pages for clear_page and clear_pages):

Here is a patch which allows to try different page zeroing
optimizations to be tested at runtime via sysctl.
Was run tested in 2.6.8 time. Rediffed to 2.6.11.
Feel free to adapt to your patch and test.

Also attached is a tarball for microbenchmarking routines. There are two
result files. Duron:

   normal_clear_page - took  8644 max, 8400 min cycles per page
 repstosl_clear_page - took  8626 max, 8418 min cycles per page
 movq_clear_page - took  8647 max, 8300 min cycles per page
   movntq_clear_page - took  2777 max, 2720 min cycles per page

And amd64:
   normal_clear_page - took  9427 max, 5781 min cycles per page
 repstosl_clear_page - took  9305 max, 5680 min cycles per page
 movq_clear_page - took  6167 max, 5576 min cycles per page
   movntq_clear_page - took  5456 max, 2354 min cycles per page

NT stores are not about 5% increase. 200%-300%. Provided you are ok with
the fact that zeroed page ends up evicted from cache. Luckily, this is exactly
what you want with prezeroing.
--
vda
diff -urpN linux-2.6.11.src/arch/i386/lib/Makefile linux-2.6.11-nt.src/arch/i386/lib/Makefile
--- linux-2.6.11.src/arch/i386/lib/Makefile	Tue Oct 19 00:53:10 2004
+++ linux-2.6.11-nt.src/arch/i386/lib/Makefile	Fri Mar 18 11:30:51 2005
@@ -4,7 +4,7 @@
 
 
 lib-y = checksum.o delay.o usercopy.o getuser.o memcpy.o strstr.o \
-	bitops.o
+	bitops.o page_ops.o mmx_page.o sse_page.o
 
 lib-$(CONFIG_X86_USE_3DNOW) += mmx.o
 lib-$(CONFIG_HAVE_DEC_LOCK) += dec_and_lock.o
diff -urpN linux-2.6.11.src/arch/i386/lib/mmx.c linux-2.6.11-nt.src/arch/i386/lib/mmx.c
--- linux-2.6.11.src/arch/i386/lib/mmx.c	Tue Oct 19 00:54:23 2004
+++ linux-2.6.11-nt.src/arch/i386/lib/mmx.c	Fri Mar 18 11:30:51 2005
@@ -120,280 +120,3 @@ void *_mmx_memcpy(void *to, const void *
 	kernel_fpu_end();
 	return p;
 }
-
-#ifdef CONFIG_MK7
-
-/*
- *	The K7 has streaming cache bypass load/store. The Cyrix III, K6 and
- *	other MMX using processors do not.
- */
-
-static void fast_clear_page(void *page)
-{
-	int i;
-
-	kernel_fpu_begin();
-	
-	__asm__ __volatile__ (
-		  pxor %%mm0, %%mm0\n : :
-	);
-
-	for(i=0;i4096/64;i++)
-	{
-		__asm__ __volatile__ (
-		  movntq %%mm0, (%0)\n
-		  movntq %%mm0, 8(%0)\n
-		  movntq %%mm0, 16(%0)\n
-		  movntq %%mm0, 24(%0)\n
-		  movntq %%mm0, 32(%0)\n
-		  movntq %%mm0, 40(%0)\n
-		  movntq %%mm0, 48(%0)\n
-		  movntq %%mm0, 56(%0)\n
-		: : r (page) : memory);
-		page+=64;
-	}
-	/* since movntq is weakly-ordered, a sfence is needed to become
-	 * ordered again.
-	 */
-	__asm__ __volatile__ (
-		  sfence \n : :
-	);
-	kernel_fpu_end();
-}
-
-static void fast_copy_page(void *to, void *from)
-{
-	int i;
-
-	kernel_fpu_begin();
-
-	/* maybe the prefetch stuff can go before the expensive fnsave...
-	 * but that is for later. -AV
-	 */
-	__asm__ __volatile__ (
-		1: prefetch (%0)\n
-		   prefetch 64(%0)\n
-		   prefetch 128(%0)\n
-		   prefetch 192(%0)\n
-		   prefetch 256(%0)\n
-		2:  \n
-		.section .fixup, \ax\\n
-		3: movw $0x1AEB, 1b\n	/* jmp on 26 bytes */
-		   jmp 2b\n
-		.previous\n
-		.section __ex_table,\a\\n
-			.align 4\n
-			.long 1b, 3b\n
-		.previous
-		: : r (from) );
-
-	for(i=0; i(4096-320)/64; i++)
-	{
-		__asm__ 

Re: Real-Time Preemption and RCU

2005-03-18 Thread Ingo Molnar

there's a problem in #5's rcu_read_lock():

void
rcu_read_lock(void)
{
preempt_disable();
if (current-rcu_read_lock_nesting++ == 0) {
current-rcu_read_lock_ptr =
__get_cpu_var(rcu_data).lock;
read_lock(current-rcu_read_lock_ptr);
}
preempt_enable();
}

not only are read_lock()-ed sections preemptible, read_lock() itself may
block, so it cannot be called from within preempt_disable(). How about
something like:

void
rcu_read_lock(void)
{
preempt_disable();
if (current-rcu_read_lock_nesting++ == 0) {
current-rcu_read_lock_ptr =
__get_cpu_var(rcu_data).lock;
preempt_enable();
read_lock(current-rcu_read_lock_ptr);
} else
preempt_enable();
}

this would still make it 'statistically scalable' - but is it correct?

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: [PATCH] reduce inlined x86 memcpy by 2 bytes

2005-03-18 Thread Denis Vlasenko
On Friday 18 March 2005 11:21, Denis Vlasenko wrote:
 This memcpy() is 2 bytes shorter than one currently in mainline
 and it have one branch less. It is also 3-4% faster in microbenchmarks
 on small blocks if block size is multiple of 4. Mainline is slower
 because it has to branch twice per memcpy, both mispredicted
 (but branch prediction hides that in microbenchmark).
 
 Last remaining branch can be dropped too, but then we execute second
 'rep movsb' always, even if blocksize%4==0. This is slower than mainline
 because 'rep movsb' is microcoded. I wonder, tho, whether 'branchlessness'
 wins over this in real world use (not in bench).
 
 I think blocksize%4==0 happens more than 25% of the time.

s/%4/3 of course.
--
vda

-
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] add a clear_pages function to clear pages of higher order

2005-03-18 Thread Andi Kleen
 Andi Kleen (iirc) says that non-temporal stores seem to be
 big win in microbenchmarks (and I second that), but they are
 a net loss when we are going to use zeroed page just after
 zeroing. He recommends avoid using non-temporal stores

The rule of thumb is to only use non temporal stores when your
data set is bigger than the L2/L3 caches of the CPU. This means 1MB.
The kernel normally never works on data sets that big.

For Christophers new background cleaner daemon it may be worth it 
when the queue is a LILO. This means it is likely there is a relatively
long time between the clearing operation and a workload using it.
But even then it is a very close call and would need clear benchmark 
numbers in macrobenchmarks.

-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/


$B6XCG$N0!!$D$$$K!!(B

2005-03-18 Thread info
$BEl5~%i%V%9%H!%j!(B
$BCK=w$H$b40A4L5NA$N7F$$$Nl$rDs6!$$$?$7$^$9(B
$B=U$OJL$l$N5(@a!AGE($J(B4$B7n$r7^$($k0Y$K:#$+$iM'C#:n$j$I$$G$9$+!)(B
$B$-$C$H8+$D$+$kAGE($J?M!z(B
http://loves.qsv20.com/
$B$=$NB$b$m$b$mFCE5IU!*!*(B
$B:#2s$N%P!%8%g%s%%C%W$G!El5~8BDj$+$iA49qBP1~$K$J$j!$$J$?$r3Z$7$^$;$^$9(B

T-L-S$B;vL36I(B


-
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/


3c59x concerns on 2.4-2.6 update?

2005-03-18 Thread Matthias Andree
Hi,

I've recently upgraded a router which has three 3Com900C Tornado cards
revisions 74 and 78 from Linux 2.4 to 2.6.

IIRC, Linux 2.4 allowed to report if the link beat was sensed to be 10
or 100 mbps, Linux 2.6 does not. One of these cards is attached to
peculiar network gear and needs to be forced to 100baseTx-FD.
I configured options=0x204 for that interface, which sorta worked;
vortex-diag and mii-diag still report autonegotiation were enabled.
Strange.

ethtool (I tried v2 and v3) does not appear to work at all for 3C900C
cards, No data available if run without options.

Any insight into these would be appreciated,

-- 
Matthias Andree
-
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] remove lame schedule in journal inverted_lock (was: Re: [patch 0/3] j_state_lock, j_list_lock, remove-bitlocks)

2005-03-18 Thread Steven Rostedt

On Fri, 18 Mar 2005, Andrew Morton wrote:
 Steven Rostedt [EMAIL PROTECTED] wrote:
 
 
  Andrew,
 
  Since I haven't gotten a response from you,

 It sometimes takes me half a day to get onto looking at patches.  And if I
 take them I usually don't reply (sorry).  But I don't drop stuff, so if you
 don't hear, please assume the patch stuck.  If others raise objections
 to the patch I'll usually duck it as well, but it's pretty obvious when that
 happens.

Sorry, I didn't mean to be pushy. I understand that you have a lot on your
plate, and I'm sure you don't drop stuff. I just wasn't sure that you
noticed that that was a patch and not just a reply on this thread, since I
didn't flag it as such in the subject. I just didn't want it to slip under
the radar.



 I really should knock up a script to send out an email when I add a patch
 to -mm.


I thought you might have had something like that already, which was
another reason I thought you might have skipped this.


  I'd figure that you may have
  missed this, since the subject didn't change.  So I changed the subject to
  get your attention, and I've resent this. Here's the patch to get rid of
  the the lame schedule that was in fs/jbd/commit.c.   Let me know if this
  patch is appropriate.

 I'm rather aghast at all the ifdeffery and complexity in this one.  But I
 haven't looked at it closely yet.


I wanted to keep the wait logic out when it wasn't a problem. Basically,
the problem only occurs when bit_spin_trylock is defined as an actual
trylock. So I put in a define there to enable the wait queues.  I didn't
want to waste cycles checking the wait queue in jbd_unlock_bh_state when
there would never be anything on it.  Heck, I figured why even have the
wait queue wasting memory if it wasn't needed.  So that added the
ifdeffery complexity.

Thanks,

-- Steve

-
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/


problem with process and threads

2005-03-18 Thread sounak chakraborty
  
dear sir
The number of processes that are being created in
fork.c() in function do_fork are less than the  number
of processes are being terminated in exit.c in
function do_exit().
I am placing a printk() in both the above
functions do_fork() and do_exit() and thus after
compiling and then restarting i am getting exit
messages of many process ids that have not yet been
formed.


Another question is that while we are using an AND
operation to distinguish between a process and a
thread (
if(p-flags  CLONE_VM)
 in fork.c in function do_fork() in linux kernel 2.6.8
).

But if i use the above check in do_exit() , will
it be able to distinguish between a thread and a
process in the same manner as do_fork().
If this is not the case , then plz tell where i am
wrong and rectify my mistake.

One more problem is while p-active_mm is equal to
NULL in case of kernel threads and not NULL in case of
user level threads ; through this check we can
identify kernel and user level threads in fork.c but
in exit.c the same p-active_mm value is not NULL for
kernel and user level threads.
   Hence i want to know how can i make a distinction
between kernel and user threads . Is there any other
way?

 Eagerly waiting for a reply,
 Thanks in advance,
 Sounak



Yahoo! India Matrimony: Find your partner online. 
http://yahoo.shaadi.com/india-matrimony/
-
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: Unresolved symbols in /lib/modules/2.4.28-pre2/xfree-drm/via_drv.o

2005-03-18 Thread Martin MOKREJ
Marcelo Tosatti wrote:
On Wed, Mar 16, 2005 at 04:21:12PM +0100, Martin MOKREJ? wrote:
Arjan van de Ven wrote:
On Wed, 2005-03-16 at 16:03 +0100, Martin MOKREJ?? wrote:

Hi,
does anyone still use 2.4 series kernel? ;)

# make dep; make bzImage; make modules
[cut]
# make modules_install
[cut]
cd /lib/modules/2.4.30-pre3-bk2; \
mkdir -p pcmcia; \
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} 
pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map  
2.4.30-pre3-bk2; fi
depmod: *** Unresolved symbols in 
/lib/modules/2.4.28-pre2/xfree-drm/via_drv.o

this is not the module shipped by the kernel.org kernel...
Right. Sorry that I didn't say it more clearly, but I'm installing 
2.4.30-pre3-bk2 kernel.
cd /usr/src/linux-2.4.30-pre3-bk2
make dep
make bzImage
make modules
make modules_install

and then I hit the error about some totally unrelated kernel version in 
/lib/modules? :(

Martin,
Can you find out why is depmod trying to open /lib/modules/2.4.28-pre2/ ?
I've got no clue.
Hi all,
 unfortunately I was too fast deleting the problematic /lib/modules/2.4.28-pre2
directory. Here's the log of what I've done at about the time I hit the problem:
 427  cd /usr/src
 428  ls
 429  uname -a
 430  bzip2 -dc linux-2.4.29.tar.bz2 | tar xf -
 431  cd linux-2.4.29
 432  bzip2 -dc ~mmokrejs/tmp/patch-2.4.30-pre3.bz2 | patch -p1
 433  bzip2 -dc ~mmokrejs/tmp/patch-2.4.30-pre3-bk2.bz2 | patch -p1
 434  cp ../linux-2.4.30-pre1-bk5/.config .
 435  cd ..
 436  mv linux-2.4.29 linux-2.4.30-pre3-bk2
 437  pwd
 438  cd linux-2.4.30-pre3-bk2
 439  make oldconfig
 440  make dep; make bzIMage; make modules
 441  make modules_install
 442  make modules_install
 443  ls
 444  make bzImage
 445  make modules
 446  make modules_install
 447  make bzImage
 448  make modules
 449  make modules_install
 450  gzip .config
 451  gzip -d .config.
 452  gzip -d .config.gz 
 453  cp .config .config-ok
 454  make menuconfig
 455  make dep; make bzImage; make modules
 456  make modules_install
 457  make menuconfig
 458  make dep; make bzImage; make modules
 459  make modules_install
 460  make menuconfig
 461  make dep; make bzImage; make modules
 462  make modules_install
 463  make menuconfig
 464  make dep; make bzImage; make modules
 465  make modules_install
 466  rm -rf /lib/modules/2.4.28-pre2
 467  make modules_install

The step 466 fixed my problem. I have repeated all the steps as show in 
the history log,
but no luck to hit the problem again. I just guess the 
/lib/modules/2.4.28-pre2/xfree-drm/via_drv.o
file came from gentoo's xfree-drm package as at that time /usr/src/linux 
pointed to that kernel version.
The System.map (/usr/src/linux-2.4.28-pre2/System.map) maybe wasn't updated, as 
I think the modules
just get compiled against configured kernel src tree.
I did in the /usr/src/linux-2.4.30-pre3-bk2 tree (while rm -rf 
/lib/modules/2.4.28-pre2 already happened):
strace make modules_install 21 | grep '2.4.28'
and go nothing interresting.
Also, 
find . -type f | xargs grep 2.4.28
doesn't show anything of interrest.

# depmod --version
module-init-tools 3.1
--
Martin Mokrejs
Email: 'bW9rcmVqc21Acmlib3NvbWUubmF0dXIuY3VuaS5jeg==\n'.decode('base64')
GPG key is at http://www.natur.cuni.cz/~mmokrejs
-
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] remove lame schedule in journal inverted_lock (was: Re: [patch 0/3] j_state_lock, j_list_lock, remove-bitlocks)

2005-03-18 Thread Andrew Morton
Steven Rostedt [EMAIL PROTECTED] wrote:

 
   I really should knock up a script to send out an email when I add a patch
   to -mm.
  
 
  I thought you might have had something like that already, which was
  another reason I thought you might have skipped this.


I do now..

 
I'd figure that you may have
missed this, since the subject didn't change.  So I changed the subject 
 to
get your attention, and I've resent this. Here's the patch to get rid of
the the lame schedule that was in fs/jbd/commit.c.   Let me know if this
patch is appropriate.
  
   I'm rather aghast at all the ifdeffery and complexity in this one.  But I
   haven't looked at it closely yet.
  
 
  I wanted to keep the wait logic out when it wasn't a problem. Basically,
  the problem only occurs when bit_spin_trylock is defined as an actual
  trylock. So I put in a define there to enable the wait queues.  I didn't
  want to waste cycles checking the wait queue in jbd_unlock_bh_state when
  there would never be anything on it.  Heck, I figured why even have the
  wait queue wasting memory if it wasn't needed.  So that added the
  ifdeffery complexity.

No, that code's just a problem.  For ranking reasons it's essentially doing
this:

repeat:
cond_resched();
spin_lock(j_list_lock);

if (!bit_spin_trylock(bh)) {
spin_unlock(j_list_lock);
schedule();
goto repeat;
}

Now imagine that some other CPU holds the bit_spin_lock and is spinning,
trying to get the spin_lock().  The above code assumes that the schedule()
and cond_resched() will take long enough for the other CPU to get the
spinlock, do its business then release the locks.

So all the schedule() is really doing is blow a few cycles so the other
CPU can get in and grab the spinlock.  That'll work OK on normal SMP but I
suspect that on NUMA setups with really big latencies we could end up
starving the other CPU: this CPU would keep on grabbing the lock.  It
depends on how the interconnect cache and all that goop works.

So what to do?

One approach would be to spin on the bit_spin_trylock after having dropped
j_list_lock.  That'll tell us when the other CPU has moved on.

Another approach would be to sleep on a waitqueue somewhere.  But that
means that jbd_unlock_bh_state() needs to do wakeups all the time - costly.

Another approach would be to simply whack an msleep(1) in there.  That
might be OK - it should be very rare.

Probably the first approach would be the one to use.  That's for mainline. 
I don't know what the super-duper-RT fix would be.  Why did we start
discussing this anyway?

Oh, SCHED_FIFO.  kjournald doesn't run SCHED_FIFO, but someone may decide
to make it do so.  But even then I don't see a problem for the mainline
kernel, because this CPU's SCHED_FIFO doesn't stop the other CPU from
running.


-
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] docbook: fix escaping of kernel-doc

2005-03-18 Thread Martin Waitz
hoi :)

the following patch fixes a bug I introduced with the last patches
of the DocBook generation.

Signed-off-by: Martin Waitz [EMAIL PROTECTED]

---
Please apply.

... and I really have to redo my bitkeeper repository as it
is full of merge artifacts as BK did not note the fact that
the patches were applied using normal patches.

I guess I have to use one complete tree per patch and recreate
the public repo as a combination of the individual ones.
Alternatives?

diff -Nru a/scripts/kernel-doc b/scripts/kernel-doc
--- a/scripts/kernel-doc2005-03-18 11:51:17 +01:00
+++ b/scripts/kernel-doc2005-03-18 11:51:17 +01:00
@@ -1626,11 +1655,11 @@
 
 # replace , , and 
 sub xml_escape($) {
-   shift;
-   s/\/\\amp;/g;
-   s/\/\\lt;/g;
-   s/\/\\gt;/g;
-   return $_;
+   my $text = shift;
+   $text =~ s/\/\\amp;/g;
+   $text =~ s/\/\\lt;/g;
+   $text =~ s/\/\\gt;/g;
+   return $text;
 }
 
 sub process_file($) {


-- 
Martin Waitz


signature.asc
Description: Digital signature


Re: [PATCH] docbook: fix escaping of kernel-doc

2005-03-18 Thread Andrew Morton
Martin Waitz [EMAIL PROTECTED] wrote:

  ... and I really have to redo my bitkeeper repository as it
  is full of merge artifacts as BK did not note the fact that
  the patches were applied using normal patches.

Normally bk would handle that, but I have an irritating habit of stripping
off all the trailing whitespace which people keep trying to add to the
kernel.

  I guess I have to use one complete tree per patch and recreate
  the public repo as a combination of the individual ones.
  Alternatives?

Export all the csets as unified diffs, reapply them.
-
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

2005-03-18 Thread Ingo Molnar

* Ingo Molnar [EMAIL PROTECTED] wrote:

 [...] How about something like:
 
 void
 rcu_read_lock(void)
 {
 preempt_disable();
 if (current-rcu_read_lock_nesting++ == 0) {
 current-rcu_read_lock_ptr =
 __get_cpu_var(rcu_data).lock;
 preempt_enable();
 read_lock(current-rcu_read_lock_ptr);
 } else
 preempt_enable();
 }
 
 this would still make it 'statistically scalable' - but is it correct?

thinking some more about it, i believe it's correct, because it picks
one particular CPU's lock and correctly releases that lock.

(read_unlock() is atomic even on PREEMPT_RT, so rcu_read_unlock() is
fine.)

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: Real-Time Preemption and RCU

2005-03-18 Thread Ingo Molnar

* Paul E. McKenney [EMAIL PROTECTED] wrote:

 5. Scalability -and- Realtime Response.
 
 The trick here is to keep track of the CPU that did the
 rcu_read_lock() in the task structure.  If there is a preemption,
 there will be some slight inefficiency, but the correct lock will be
 released, preserving correctness.

the inefficiency will be larger, because (as explained in a previous
mail) multiple concurrent owners of the read-lock are not allowed. This
adds to the overhead of PREEMPT_RT on SMP, but is an intentional
tradeoff. I dont expect PREEMPT_RT to be used on an Altix :-|

#5 is still the best option, because in the normal 'infrequent
preemption' case it will behave in a cache-friendly way. A positive
effect of the lock serializing is that the callback backlog will stay
relatively small and that the RCU backlog processing can be made
deterministic as well (if needed), by making the backlog processing
thread(s) SCHED_FIFO.

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: [patch] SUSPEND_PD_PAGES-fix

2005-03-18 Thread Pavel Machek
Hi!


 This fixes SUSPEND_PD_PAGES, which wastes one page under most cases.

Ok, applied to my tree, will eventually propagate it. (I hope it looks
okay to you, rafael).

 Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED]
 diff -pruN 2.6.11-mm4/include/linux/suspend.h 
 2.6.11-mm4-cy/include/linux/suspend.h
 --- 2.6.11-mm4/include/linux/suspend.h2005-03-17 01:22:16.0 
 +0800
 +++ 2.6.11-mm4-cy/include/linux/suspend.h 2005-03-17 04:14:16.0 
 +0800
 @@ -34,7 +34,7 @@ typedef struct pbe {
  #define SWAP_FILENAME_MAXLENGTH  32
  
  
 -#define SUSPEND_PD_PAGES(x) (((x)*sizeof(struct pbe))/PAGE_SIZE+1)
 +#define SUSPEND_PD_PAGES(x) (((x)*sizeof(struct 
 pbe)+PAGE_SIZE-1)/PAGE_SIZE)
  
  extern dev_t swsusp_resume_device;
 

-- 
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: CPU hotplug on i386

2005-03-18 Thread Pavel Machek
Hi!

 I tried to solve long-standing uglyness in swsusp cmp code by calling
 cpu hotplug... only to find out that CONFIG_CPU_HOTPLUG is not
 available on i386. Is there way to enable CPU_HOTPLUG on i386?

BTW Li Shaohua has prototype smp/S3 implementation. I'll take detailed
look at that one.
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/


[PATCH UML 2.6] Fix compilation due to mismerge.

2005-03-18 Thread Anton Altaparmakov
Hi Linus/Andrew/Jeff,

The recent slew of UML updates that appeared in BK seems to have gone 
wrong somewhere.  The file arch/um/kernel/syscall_user.c contains 
identical content twice over, thus breaking compilation.

Below is a patch to fix this.  Please apply.

Signed-off-by: Anton Altaparmakov [EMAIL PROTECTED]

Best regards,

Anton
-- 
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/  http://www-stu.christs.cam.ac.uk/~aia21/

--- ntfs-2.6-devel/arch/um/kernel/syscall_user.c.old2005-03-18 
11:40:12.544681735 +
+++ ntfs-2.6-devel/arch/um/kernel/syscall_user.c2005-03-18 
11:37:42.732441897 +
@@ -46,51 +46,3 @@ void record_syscall_end(int index, long 
  * c-file-style: linux
  * End:
  */
-/*
- * Copyright (C) 2002 Jeff Dike ([EMAIL PROTECTED])
- * Licensed under the GPL
- */
-
-#include stdlib.h
-#include sys/time.h
-#include kern_util.h
-#include syscall_user.h
-
-struct {
-   int syscall;
-   int pid;
-   long result;
-   struct timeval start;
-   struct timeval end;
-} syscall_record[1024];
-
-int record_syscall_start(int syscall)
-{
-   int max, index;
-
-   max = sizeof(syscall_record)/sizeof(syscall_record[0]);
-   index = next_syscall_index(max);
-
-   syscall_record[index].syscall = syscall;
-   syscall_record[index].pid = current_pid();
-   syscall_record[index].result = 0xdeadbeef;
-   gettimeofday(syscall_record[index].start, NULL);
-   return(index);
-}
-
-void record_syscall_end(int index, long result)
-{
-   syscall_record[index].result = result;
-   gettimeofday(syscall_record[index].end, NULL);
-}
-
-/*
- * Overrides for Emacs so that we follow Linus's tabbing style.
- * Emacs will notice this stuff at the end of the file and automatically
- * adjust the settings for this buffer only.  This must remain at the end
- * of the file.
- * ---
- * Local variables:
- * c-file-style: linux
- * End:
- */
-
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] remove lame schedule in journal inverted_lock (was: Re: [patch 0/3] j_state_lock, j_list_lock, remove-bitlocks)

2005-03-18 Thread Steven Rostedt

On Fri, 18 Mar 2005, Andrew Morton wrote:
 Steven Rostedt [EMAIL PROTECTED] wrote:
 
   I wanted to keep the wait logic out when it wasn't a problem. Basically,
   the problem only occurs when bit_spin_trylock is defined as an actual
   trylock. So I put in a define there to enable the wait queues.  I didn't
   want to waste cycles checking the wait queue in jbd_unlock_bh_state when
   there would never be anything on it.  Heck, I figured why even have the
   wait queue wasting memory if it wasn't needed.  So that added the
   ifdeffery complexity.

 No, that code's just a problem.  For ranking reasons it's essentially doing
 this:

 repeat:
   cond_resched();
   spin_lock(j_list_lock);
   
   if (!bit_spin_trylock(bh)) {
   spin_unlock(j_list_lock);
   schedule();
   goto repeat;
   }


Yep, that I understand.

 Now imagine that some other CPU holds the bit_spin_lock and is spinning,
 trying to get the spin_lock().  The above code assumes that the schedule()
 and cond_resched() will take long enough for the other CPU to get the
 spinlock, do its business then release the locks.

 So all the schedule() is really doing is blow a few cycles so the other
 CPU can get in and grab the spinlock.  That'll work OK on normal SMP but I
 suspect that on NUMA setups with really big latencies we could end up
 starving the other CPU: this CPU would keep on grabbing the lock.  It
 depends on how the interconnect cache and all that goop works.

 So what to do?

 One approach would be to spin on the bit_spin_trylock after having dropped
 j_list_lock.  That'll tell us when the other CPU has moved on.


This is probably the best for mainline, since, as you mentioned, the
abover code is just bad.

 Another approach would be to sleep on a waitqueue somewhere.  But that
 means that jbd_unlock_bh_state() needs to do wakeups all the time - costly.


That's the approach that my patch made.

 Another approach would be to simply whack an msleep(1) in there.  That
 might be OK - it should be very rare.


This approach is not much better than the current implementation.

 Probably the first approach would be the one to use.  That's for mainline.
 I don't know what the super-duper-RT fix would be.  Why did we start
 discussing this anyway?

 Oh, SCHED_FIFO.  kjournald doesn't run SCHED_FIFO, but someone may decide
 to make it do so.  But even then I don't see a problem for the mainline
 kernel, because this CPU's SCHED_FIFO doesn't stop the other CPU from
 running.


So this comes down to just a problem with Ingo's PREEPMT_RT.  This means
that the latency of kjournald, even without SCHED_FIFO will be large. If
it preempts a process that has one of these bit spinlocks, (Ingo's RT
kernel takes out the preempt_disable in them), then the kjournal thread
will spin till its quota is free, causing problems for other processes.
Even a process with a higher priority than kjournal if it blocks on one of
the other locks that kjournal can have while attempting to get the bit
locks.

I know Ingo wants to get his patch eventually into the mainline without
too much drag. But this problem needs to be solved in the mainline to
accomplish this.

What do you recommend?

-- Steve

-
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: vm_dirty_ratio seems a bit large.

2005-03-18 Thread Robin Holt
On Fri, Mar 18, 2005 at 09:27:31AM +1100, Peter Chubb wrote:
  Andrew == Andrew Morton [EMAIL PROTECTED] writes:
 
 Andrew Robin Holt [EMAIL PROTECTED] wrote:
 
   One other issue we have is the vm_dirty_ratio and background_ratio
  adjustments are a little coarse with these memory sizes.  Since our
  minimum adjustment is 1%, we are adjusting by 40GB on the largest
  configuration from above.  The hardware we are shipping today is
  capable of going to far greater amounts of memory, but we don't
  have customers demanding that yet.  I would like to plan ahead for
  that and change vm_dirty_ratio from a straight percent into a
  millipercent (thousandth of a percent).  Would that type of change
  be acceptable?
 
 Andrew Oh drat.  I think such a change would require a new set of
 Andrew /proc entries.  
 
 No, you could just extend them to understand fixed point.  Keep
 printing integers as integers, print non-integers with one (or two:
 will we ever need 0.01% increments?) decimal places.

Right now, it is possible to build our largest Altix configuration with
64TB of memory (unfortunatetly, we can't get any customers to pay that
large of bill ;).  We are currently shipping a few 4TB systems and hope
to be selling 20TB systems by the end of the year (at least engineering
hopes to).

Given that, two decimal places are really not enough.  We probably need
at least 3.

Is there any reason to not do 3 places?  Is this the right direction to
head or does anybody know of problems this would cause?

Thanks,
Robin Holt
-
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

2005-03-18 Thread hui
On Thu, Mar 17, 2005 at 04:20:26PM -0800, Paul E. McKenney wrote:
 5. Scalability -and- Realtime Response.
...

   void
   rcu_read_lock(void)
   {
   preempt_disable();
   if (current-rcu_read_lock_nesting++ == 0) {
   current-rcu_read_lock_ptr =
   __get_cpu_var(rcu_data).lock;
   read_lock(current-rcu_read_lock_ptr);
   }
   preempt_enable();
   }

Ok, here's a rather unsure question...

Uh, is that a sleep violation if that is exclusively held since it
can block within an atomic critical section (deadlock) ?

bill


-
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

2005-03-18 Thread Alan Cox
On Gwe, 2005-03-18 at 08:57, Jacques Goldberg wrote:
  Question: is there a way, as of kernels 2.6.10 and above, to release the
 device from the serial driver, without having to recompile the kernel?

There is an ugly way (fake a hot unplug 8)) but if you want to do it
properly you need to get the relevant pci check into the serial driver
proper by submitting it to Russell King. That way the serial driver can
skip the PCI devices that turn out to be modems

-
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

2005-03-18 Thread hui
On Fri, Mar 18, 2005 at 04:56:41AM -0800, Bill Huey wrote:
 On Thu, Mar 17, 2005 at 04:20:26PM -0800, Paul E. McKenney wrote:
  5. Scalability -and- Realtime Response.
 ...
 
  void
  rcu_read_lock(void)
  {
  preempt_disable();
  if (current-rcu_read_lock_nesting++ == 0) {
  current-rcu_read_lock_ptr =
  __get_cpu_var(rcu_data).lock;
  read_lock(current-rcu_read_lock_ptr);
  }
  preempt_enable();
  }
 
 Ok, here's a rather unsure question...
 
 Uh, is that a sleep violation if that is exclusively held since it
 can block within an atomic critical section (deadlock) ?

I'd like to note another problem. Mingo's current implementation of rt_mutex
(super mutex for all blocking synchronization) is still missing reader counts
and something like that would have to be implemented if you want to do priority
inheritance over blocks.

This is going to throw a wrench into your implementation if you assume that.

bill


-
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] DM9000 network driver

2005-03-18 Thread Sascha Hauer

Hello all,

This patch adds support for the davicom dm9000 network driver. The
dm9000 is found on some embedded arm boards such as the pimx1 or the
scb9328.

Sascha Hauer

Signed-off-by: Sascha Hauer [EMAIL PROTECTED]

diff -urN linux-2.6.11/drivers/net/Kconfig linux-2.6.11-work/drivers/net/Kconfig
--- linux-2.6.11/drivers/net/Kconfig2005-03-02 08:38:25.0 +0100
+++ linux-2.6.11-work/drivers/net/Kconfig   2005-03-17 12:33:26.0 
+0100
@@ -849,6 +849,18 @@
  file:Documentation/networking/net-modules.txt. The module
  will be called smc9194.
 
+config DM9000
+   tristate DM9000 support
+   depends on ARM  NET_ETHERNET
+   select CRC32
+   select MII
+   ---help---
+ Support for DM9000 chipset.
+
+ To compile this driver as a module, choose M here and read
+ file:Documentation/networking/net-modules.txt.  The module will be
+ called dm9000.
+
 config NET_VENDOR_RACAL
bool Racal-Interlan (Micom) NI cards
depends on NET_ETHERNET  ISA
diff -urN linux-2.6.11/drivers/net/Makefile 
linux-2.6.11-work/drivers/net/Makefile
--- linux-2.6.11/drivers/net/Makefile   2005-03-02 08:37:52.0 +0100
+++ linux-2.6.11-work/drivers/net/Makefile  2005-03-17 12:32:16.0 
+0100
@@ -181,6 +181,7 @@
 obj-$(CONFIG_IBMVETH) += ibmveth.o
 obj-$(CONFIG_S2IO) += s2io.o
 obj-$(CONFIG_SMC91X) += smc91x.o
+obj-$(CONFIG_DM9000) += dm9000.o
 obj-$(CONFIG_FEC_8XX) += fec_8xx/
 
 obj-$(CONFIG_ARM) += arm/
diff -urN linux-2.6.11/drivers/net/dm9000.c 
linux-2.6.11-work/drivers/net/dm9000.c
--- linux-2.6.11/drivers/net/dm9000.c   1970-01-01 01:00:00.0 +0100
+++ linux-2.6.11-work/drivers/net/dm9000.c  2005-03-17 16:04:49.0 
+0100
@@ -0,0 +1,1219 @@
+/*
+ *   dm9000.c: Version 1.2 03/18/2003
+ *   
+ * A Davicom DM9000 ISA NIC fast Ethernet driver for Linux.
+ * Copyright (C) 1997  Sten Wang
+ * 
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * 
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ * 
+ *   (C)Copyright 1997-1998 DAVICOM Semiconductor,Inc. All Rights Reserved.
+ * 
+ * V0.11   06/20/2001  REG_0A bit3=1, default enable BP with DA match
+ * 06/22/2001  Support DM9801 progrmming   
+ * E3: R25 = ((R24 + NF)  0x00ff) | 0xf000
+ * E4: R25 = ((R24 + NF)  0x00ff) | 0xc200
+ * R17 = (R17  0xfff0) | NF + 3
+ * E5: R25 = ((R24 + NF - 3)  0x00ff) | 0xc200
+ * R17 = (R17  0xfff0) | NF
+ * 
+ * v1.00   modify by simon 2001.9.5
+ * change for kernel 2.4.x
+ * 
+ * v1.1   11/09/2001   fix force mode bug 
+ * 
+ * v1.2   03/18/2003   Weilun Huang [EMAIL PROTECTED]: 
+ * Fixed phy reset.
+ * Added tx/rx 32 bit mode.
+ * Cleaned up for kernel merge.
+ *
+ *03/03/2004Sascha Hauer [EMAIL PROTECTED]
+ *  Port to 2.6 kernel
+ *  
+ *   24-Sep-2004   Ben Dooks [EMAIL PROTECTED]
+ * Cleanup of code to remove ifdefs
+ * Allowed platform device data to influence access width
+ * Reformatting areas of code
+ *
+ *17-Mar-2005   Sascha Hauer [EMAIL PROTECTED]
+ *  * removed 2.4 style module parameters
+ *  * removed removed unused stat counter and fixed
+ *net_device_stats
+ *  * introduced tx_timeout function
+ *  * reworked locking 
+ */
+
+#include linux/module.h
+#include linux/ioport.h
+#include linux/netdevice.h
+#include linux/etherdevice.h
+#include linux/init.h
+#include linux/skbuff.h
+#include linux/version.h
+#include linux/spinlock.h
+#include linux/crc32.h
+#include linux/mii.h
+#include linux/dm9000.h
+#include linux/delay.h
+
+#include asm/delay.h
+#include asm/irq.h
+#include asm/io.h
+
+#include dm9000.h
+
+/* Board/System/Debug information/definition  */
+
+#define DM9000_PHY 0x40/* PHY address 0x01 */
+
+#define TRUE   1
+#define FALSE  0
+
+#define CARDNAME dm9000
+#define PFX CARDNAME : 
+
+#define DM9000_TIMER_WUT  jiffies+(HZ*2)   /* timer wakeup time : 2 second 
*/
+
+#define DM9000_DEBUG 0
+
+#if DM9000_DEBUG  2
+#define PRINTK3(args...)  

Re: [patch] SUSPEND_PD_PAGES-fix

2005-03-18 Thread Rafael J. Wysocki
Hi,

On Friday, 18 of March 2005 12:39, Pavel Machek wrote:
 Hi!
 
 
  This fixes SUSPEND_PD_PAGES, which wastes one page under most cases.
 
 Ok, applied to my tree, will eventually propagate it. (I hope it looks
 okay to you, rafael).

SUSPEND_PD_PAGES is not necessary in swsusp any more. :-)  We can just
drop it, together with the pagedir_order variable, which is not used.  I'll
send a patch later today.

BTW, I'm going to post some clean ups for swsusp.c, but I'd like the last
changes to settle down in mainline before, if you don't mind.

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll Alice's Adventures in Wonderland
-
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/


yenta_socket nobody cared - Disabling IRQ #4

2005-03-18 Thread Jonas Oreland
Hi,
I have a IBM thinkpad G40 and have just upgraded from 2.4.28 to 2.6.11.2
And I fail to get my netgear wg511t wireless pccard to function.
(worked fine with 2.4.28)
I've tried (wo really knowing what i'm doing) using
*) pci=routeirq
*) compiling kernel wo/ acpi
*) modprobe yenta_socket disable_clkrun=1
NOTE: It works sometimes!
When I insert the card (or modprobe yenta_socket), it will either work 
and then I can use the wlan card wo/ problem, or it will fail directly.

The failures are unfortunatly is majority :-(
NOTE2: I have also tried wo/ the madwifi driver, and it can still lock up.
Please let me know I you need more/less info
/Jonas
-- output from uname -a
Linux eel 2.6.11.2 #2 Fri Mar 18 14:47:09 CET 2005 i686 Intel(R)
Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux
-- output from dump_cis
eel ~ # dump_cis 
Socket 0:
 manfid 0x0271, 0x0012
 config_cb base 0x last_index 0x01
 cftable_entry_cb 0x01 [default]
   [master] [parity] [serr] [fast back]
   Vcc Vnom 3300mV Istatic 25mA Iavg 450mA Ipeak 500mA
   irq mask 0x [level]
   mem_base 1
 BAR 1 size 64kb [mem]
 vers_1 7.1, Atheros Communications, Inc., AR5001--,
   Wireless LAN Reference Card, 00
 funcid network_adapter [post]
 lan_speed 6 mb/sec
 lan_speed 9 mb/sec
 lan_speed 12 mb/sec
 lan_speed 18 mb/sec
 lan_speed 24 mb/sec
 lan_speed 36 mb/sec
 lan_speed 48 mb/sec
 lan_speed 54 mb/sec
 lan_speed 72 mb/sec
 lan_media 5.4_GHz
 lan_node_id 00 09 5b ec 43 cd
 lan_connector Closed connector standard

-- output from dmesg
Linux version 2.6.11.2 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Gentoo Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1)) #2 Fri Mar 18 14:47:09 CET 2005
BIOS-provided physical RAM map:
BIOS-e820:  - 0009f000 (usable)
BIOS-e820: 0009f000 - 000a (reserved)
BIOS-e820: 000ce000 - 000d (reserved)
BIOS-e820: 000dc000 - 0010 (reserved)
BIOS-e820: 0010 - 0f6f (usable)
BIOS-e820: 0f6f - 0f70 (reserved)
BIOS-e820: 0f70 - 3f6f (usable)
BIOS-e820: 3f6f - 3f6f8000 (ACPI data)
BIOS-e820: 3f6f8000 - 3f6fa000 (ACPI NVS)
BIOS-e820: 3f70 - 4000 (reserved)
BIOS-e820: ff80 - 0001 (reserved)
Warning only 896MB will be used.
Use a HIGHMEM enabled kernel.
896MB LOWMEM available.
On node 0 totalpages: 229376
 DMA zone: 4096 pages, LIFO batch:1
 Normal zone: 225280 pages, LIFO batch:16
 HighMem zone: 0 pages, LIFO batch:1
DMI present.
ACPI: RSDP (v002 IBM   ) @ 0x000f7330
ACPI: XSDT (v001 IBMTP-1T0x1081  LTP 0x) @ 0x3f6f2435
ACPI: FADT (v002 IBMTP-1T0x1081 IBM  0x0001) @ 0x3f6f2479
ACPI: SSDT (v001 IBMTP-1T0x1081 MSFT 0x010d) @ 0x3f6f252d
ACPI: ECDT (v001 IBMTP-1T0x1081 IBM  0x0001) @ 0x3f6f7f87
ACPI: BOOT (v001 IBMTP-1T0x1081  LTP 0x0001) @ 0x3f6f7fd8
ACPI: DSDT (v001 IBMTP-1T0x1081 MSFT 0x010d) @ 0x
Allocating PCI resources starting at 4000 (gap: 4000:bf80)
Built 1 zonelists
Kernel command line: root=/dev/hda4 resume=/dev/hda3
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 2988.029 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 904280k/917504k available (3129k kernel code, 12640k reserved, 1103k data, 160k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 5898.24 BogoMIPS (lpj=2949120)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: bfebf9ff    4400  
CPU: After vendor identify, caps: bfebf9ff    4400  
CPU: Trace cache: 12K uops, L1 D cache: 8K
CPU: L2 cache: 512K
CPU: After all inits, caps: bfebf9ff   0080 4400  
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (12) available
CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz stepping 09
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0298)
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfd966, last bus=5
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050211
ACPI: Found ECDT
ACPI: Could not use ECDT
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 6 7 9 10 11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 *4 5 6 7 9 10 11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 *7 9 10 

Kernel space sockets

2005-03-18 Thread Josef E. Galea
Hi,
I'm trying to implement a UDP server in a kernel module. So far I have 
created the struct socket using sock_create_kern(), and used 
sock-ops-bind() on it. Now how do I send UDP datagrams? I looked at 
some code and found the function sock-ops-sendmsg() but I can't figure 
out where to put the destination address. I would appreciate it if 
someone could point me to some tutorial or sample code.

Thanks,
Josef
-
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

2005-03-18 Thread Jacques Goldberg
On Fri, 18 Mar 2005, Alan Cox wrote:

 On Gwe, 2005-03-18 at 08:57, Jacques Goldberg wrote:
 Question: is there a way, as of kernels 2.6.10 and above, to release the
  device from the serial driver, without having to recompile the kernel?

 There is an ugly way (fake a hot unplug 8)) butif you want to do it
 properly you need to get the relevant pci check into the serial driver
 proper by submitting it to Russell King. That way the serial driver can
 skip the PCI devices that turn out to be modems

  Thank you very much.
  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.
  This is my very last question: is there a script able to do that? Google
quotes their existence but no link found. Or a doc showing how to code
that in a program?

  Many many thanks - Jacques
-
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: Kernel space sockets

2005-03-18 Thread Juergen Quade
On Fri, Mar 18, 2005 at 02:53:31PM +0100, Josef E. Galea wrote:
 Hi,
 
 I'm trying to implement a UDP server in a kernel module. So far I have 
 created the struct socket using sock_create_kern(), and used 
 sock-ops-bind() on it. Now how do I send UDP datagrams? I looked at 
 some code and found the function sock-ops-sendmsg() but I can't figure 
 out where to put the destination address. I would appreciate it if 
 someone could point me to some tutorial or sample code.

Maybe the sample code on this (german) site helps:

http://ezs.kr.hsnr.de/TreiberBuch/Artikel/index.html

Look at Folge 16.

  Juergen.
-
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/


Question on Scheduler activations

2005-03-18 Thread Imanpreet Arora
Hello,

I came across 

http://people.redhat.com/drepper/glibcthreads.html

It seems to arouse a bit of confusion. _FIRST_ it says that scheduler
activations are BAD. Then it delves on the possible implementation of
Scheduler activations in Linux. Though I know that scheduler
activations are not part of the present kernel. Could anyone provide
BOTH the short and long answer to

a)  If they were ever implemented?
b)  Reasons for rejection?


TIA

-- 

Imanpreet Singh Arora
-
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: Kernel space sockets

2005-03-18 Thread Josef E. Galea
Juergen Quade wrote:
On Fri, Mar 18, 2005 at 02:53:31PM +0100, Josef E. Galea wrote:
 

Hi,
I'm trying to implement a UDP server in a kernel module. So far I have 
created the struct socket using sock_create_kern(), and used 
sock-ops-bind() on it. Now how do I send UDP datagrams? I looked at 
some code and found the function sock-ops-sendmsg() but I can't figure 
out where to put the destination address. I would appreciate it if 
someone could point me to some tutorial or sample code.
   

Maybe the sample code on this (german) site helps:
http://ezs.kr.hsnr.de/TreiberBuch/Artikel/index.html
Look at Folge 16.
 Juergen.
 

Thanks :)
Josef
-
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: BKCVS broken ?

2005-03-18 Thread Larry McVoy
On Fri, Mar 18, 2005 at 10:00:49AM +0100, Stelian Pop wrote:
 On Thu, Mar 17, 2005 at 10:38:53PM -0800, Larry McVoy wrote:
 
  Hey, it's open source, I'm hoping that people will take that code and
  evolve it do whatever they need.  We're willing to do what we can on
  this end if people need protocol changes to support new features, 
  time permitting.  Think of that code as a prototype.  It's really
  simple, you can hack it trivially.
 
   
   if (strncmp(bk://, p, 5)) return (1);
   
 
 Any chance this could be made to work over http ?

I don't see why not.  It will take some hacking though.  Can you live 
without it for a bit or is it urgent?
-- 
---
Larry McVoylm at bitmover.com   http://www.bitkeeper.com
-
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: BKCVS broken ?

2005-03-18 Thread Stelian Pop
On Fri, Mar 18, 2005 at 06:13:45AM -0800, Larry McVoy wrote:

 On Fri, Mar 18, 2005 at 10:00:49AM +0100, Stelian Pop wrote:
  On Thu, Mar 17, 2005 at 10:38:53PM -0800, Larry McVoy wrote:
  
   Hey, it's open source, I'm hoping that people will take that code and
   evolve it do whatever they need.  We're willing to do what we can on
   this end if people need protocol changes to support new features, 
   time permitting.  Think of that code as a prototype.  It's really
   simple, you can hack it trivially.
  
  
  if (strncmp(bk://, p, 5)) return (1);
  
  
  Any chance this could be made to work over http ?
 
 I don't see why not.  It will take some hacking though.  Can you live 
 without it for a bit or is it urgent?

It's not urgent at all...

Thanks.

Stelian.
-- 
Stelian Pop [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: Need break driver--pci-device automatic association

2005-03-18 Thread Stuart MacDonald
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/


2.6.11: CDROM_SEND_PACKET as non-root?

2005-03-18 Thread Martin Zwickel
Hi all!

I have a small question:
What do I have to do, to let the ioctl CDROM_SEND_PACKET work as a
non-root user under 2.6.11?

I try to burn a DVD with growisofs as a non-root user without success.

I know that there were some changes about access restriction (since
2.6.8), but I haven't found anything to get a clue about the current
status.

So is it just impossible to send a packet to the DVD burner without root
access? Do I have to use a wrapper that sets the effective user id to
root and then runs growisofs?


It's friday, so sorry for that stupid question, but a comment on that
would be fine :)

Regards,
Martin

-- 
MyExcuse:
Recursive traversal of loopback mount points

Martin Zwickel [EMAIL PROTECTED]
Research  Development

TechnoTrend AG http://www.technotrend.de


pgptJw5kToB9j.pgp
Description: PGP signature


Re: Call for help: list of machines with working S3

2005-03-18 Thread Romano Giannetti
On Thu, Mar 17, 2005 at 09:05:12PM +0100, Maximilian Engelhardt wrote:
 On Mon, 2005-02-14 at 22:20 +0100, Pavel Machek wrote:

  Video issues with S3 resume
  ~~~
2003-2005, Pavel Machek
  

 Tried all this on my Laptop but nothing seems to work for me. 
 I do echo 3  /proc/acpi/sleep and the systems seems to go into S3.
 When I press some key to wake it up again it powers up but I get nothing
 than a black screen. It's not only the video card that's not working,
 because the only thing it reacts to is Sysrq (without screen of course).
 One additional thing I found is that in this state the HDD led keeps
 lighting all the time untill I reboot my system. After rebooting I
 couldn't find anything interesting in my logs.
 
 Is there any way I could get S3 working on my laptop?
 
 some data:
 Acer Travel Mate 661lci
 Gentoo Base System version 1.6.10
 kernel 2.6.11
 
 I did all this testing with a minimal kernel that only had the
 absolutely necessary drivers.

It happens exactly the same on my laptop, sony vaio whose configuration is 

http://www.dea.icai.upco.es/romano/linux/vaio-conf/laptop-config.html

Next week is Easter holyday here, I will try to connect my Psion casio as
serial terminal and see if I can catch something. 

   Romano 
   
   
-- 
Romano Giannetti -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 596 569
-
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/


Where is a reference for ioctl32() usage?

2005-03-18 Thread Alan Kilian


Thanks for all the help in the past, and I'm once again knocking
at your door for more help.

I am trying to get my PCI bus device driver running on an Xeon 
64-bit FC-3 distribution for the first time. It works fine on a
32-bit FC-3 distribution.

I got the compiler warnings all cleaned up, the driver compiles and 
loads, but the test executable which was compiled on a 32-bit FC-3 
distribution is causing these messages in /var/log/messages:

Mar 17 15:42:55 noble kernel: ioctl32(boardtest:3730): 
Unknown cmd fd(3) cmd(8004440e){00} arg(d824) on /dev/sse0
Mar 17 15:42:55 noble kernel: ioctl32(boardtest:3730): 
Unknown cmd fd(3) cmd(8004440e){00} arg(d8c4) on /dev/sse0
Mar 17 15:42:55 noble kernel: ioctl32(boardtest:3730): 
Unknown cmd fd(3) cmd(40044414){00} arg() on /dev/sse0
Mar 17 15:42:55 noble kernel: ioctl32(boardtest:3730): 
Unknown cmd fd(3) cmd(80044403){00} arg(0804f780) on /dev/sse0

It's probably a simple thing to change my ioctl() interface in the
driver, but I googled myself blue in the face, and I didn't find it,
so I come to you, hat-in-hand for help.

Where can I find out how to change my driver so I can have a 32-bit
executable talk to it using ioctl()?

I did change the type argument in _IOR and _IOW to uint32_t from
int, but that didn't change things.

-Alan

-- 
- Alan Kilian kilian(at)bobodyne.com


-
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: [BKPATCH] ACPI for 2.6.12-rc1

2005-03-18 Thread Romano Giannetti
On Fri, Mar 18, 2005 at 01:23:44AM -0500, Len Brown wrote:

   This includes the ACPI part of memory hotplug,
   plus various fixes, BIOS workarounds and a fix for
   an interpreter regressions we had in 2.6.11 vs 2.6.10.

Thank you for the grat work. Could I humble advocating pushing the patch 
http://bugme.osdl.org/attachment.cgi?id=4516action=view ,please? It fixed a
very bad regression in hotkey event from 2.6.9...

Thanks!




-- 
Romano Giannetti -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 596 569
-
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: Question on Scheduler activations

2005-03-18 Thread Hong Kong Phoey
RTFM


On Fri, 18 Mar 2005 19:38:45 +0530, Imanpreet Arora [EMAIL PROTECTED] wrote:
 Hello,
 
I came across
 
http://people.redhat.com/drepper/glibcthreads.html
 
It seems to arouse a bit of confusion. _FIRST_ it says that scheduler
 activations are BAD. Then it delves on the possible implementation of
 Scheduler activations in Linux. Though I know that scheduler
 activations are not part of the present kernel. Could anyone provide
 BOTH the short and long answer to
 
 a)  If they were ever implemented?
 b)  Reasons for rejection?
 
 TIA
 
 --
 
 Imanpreet Singh Arora
 -
 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/

-
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] add a clear_pages function to clear pages of higher order

2005-03-18 Thread Christoph Lameter
On Fri, 18 Mar 2005, Denis Vlasenko wrote:

 NT stores are not about 5% increase. 200%-300%. Provided you are ok with
 the fact that zeroed page ends up evicted from cache. Luckily, this is exactly
 what you want with prezeroing.

These are pretty significant results. Maybe its best to use non-temporal
stores in general for clearing pages? I checked and Itanium has always
used non-temporal stores. So there will be no benefit for us from this
approach (we have 16k and 64k page sizes which may make the situation a
bit different). Try to update the i386 architectures to do the same?

Or for prezeroing, you could register a zeroing driver that would use the
non-temporal stores with V8 of the prezeroing patches. In any case the
clear_pages patch is not useful the way it was intended for us and I am
have dropped this from the prezeroing 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: BKCVS broken ?

2005-03-18 Thread Hong Kong Phoey
On Fri, 18 Mar 2005 15:21:25 +0100, Stelian Pop [EMAIL PROTECTED] wrote:
 On Fri, Mar 18, 2005 at 06:13:45AM -0800, Larry McVoy wrote:
 
  On Fri, Mar 18, 2005 at 10:00:49AM +0100, Stelian Pop wrote:
   On Thu, Mar 17, 2005 at 10:38:53PM -0800, Larry McVoy wrote:
  
Hey, it's open source, I'm hoping that people will take that code and
evolve it do whatever they need.  We're willing to do what we can on
this end if people need protocol changes to support new features,
time permitting.  Think of that code as a prototype.  It's really
simple, you can hack it trivially.
  
   
   if (strncmp(bk://, p, 5)) return (1);
   
  
   Any chance this could be made to work over http ?
 
  I don't see why not.  It will take some hacking though.  Can you live
  without it for a bit or is it urgent?
 
 It's not urgent at all...
 

IMHO, BKCVS is just fine, what's broken is your head.

 Thanks.
 
 Stelian.
 --
 Stelian Pop [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/

-
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] DM9000 network driver

2005-03-18 Thread Hong Kong Phoey
Sacrificing readibility a little bit, you could do something useful.
Instead of those ugly switch statements you could define function
pointer arrays and call appropriate function

switch(foo) {

  case 1:
 f1();
  case2 :
 f2();
};

could well become

void (*func)[] = { f1, f2 };

func(i);


On Fri, 18 Mar 2005 14:31:44 +0100, Sascha Hauer [EMAIL PROTECTED] wrote:
 
 Hello all,
 
 This patch adds support for the davicom dm9000 network driver. The
 dm9000 is found on some embedded arm boards such as the pimx1 or the
 scb9328.
 
 Sascha Hauer
 
 Signed-off-by: Sascha Hauer [EMAIL PROTECTED]
 
 diff -urN linux-2.6.11/drivers/net/Kconfig 
 linux-2.6.11-work/drivers/net/Kconfig
 --- linux-2.6.11/drivers/net/Kconfig2005-03-02 08:38:25.0 +0100
 +++ linux-2.6.11-work/drivers/net/Kconfig   2005-03-17 12:33:26.0 
 +0100
 @@ -849,6 +849,18 @@
  file:Documentation/networking/net-modules.txt. The module
  will be called smc9194.
 
 +config DM9000
 +   tristate DM9000 support
 +   depends on ARM  NET_ETHERNET
 +   select CRC32
 +   select MII
 +   ---help---
 + Support for DM9000 chipset.
 +
 + To compile this driver as a module, choose M here and read
 + file:Documentation/networking/net-modules.txt.  The module will be
 + called dm9000.
 +
 config NET_VENDOR_RACAL
bool Racal-Interlan (Micom) NI cards
depends on NET_ETHERNET  ISA
 diff -urN linux-2.6.11/drivers/net/Makefile 
 linux-2.6.11-work/drivers/net/Makefile
 --- linux-2.6.11/drivers/net/Makefile   2005-03-02 08:37:52.0 +0100
 +++ linux-2.6.11-work/drivers/net/Makefile  2005-03-17 12:32:16.0 
 +0100
 @@ -181,6 +181,7 @@
 obj-$(CONFIG_IBMVETH) += ibmveth.o
 obj-$(CONFIG_S2IO) += s2io.o
 obj-$(CONFIG_SMC91X) += smc91x.o
 +obj-$(CONFIG_DM9000) += dm9000.o
 obj-$(CONFIG_FEC_8XX) += fec_8xx/
 
 obj-$(CONFIG_ARM) += arm/
 diff -urN linux-2.6.11/drivers/net/dm9000.c 
 linux-2.6.11-work/drivers/net/dm9000.c
 --- linux-2.6.11/drivers/net/dm9000.c   1970-01-01 01:00:00.0 +0100
 +++ linux-2.6.11-work/drivers/net/dm9000.c  2005-03-17 16:04:49.0 
 +0100
 @@ -0,0 +1,1219 @@
 +/*
 + *   dm9000.c: Version 1.2 03/18/2003
 + *
 + * A Davicom DM9000 ISA NIC fast Ethernet driver for Linux.
 + * Copyright (C) 1997  Sten Wang
 + *
 + * This program is free software; you can redistribute it and/or
 + * modify it under the terms of the GNU General Public License
 + * as published by the Free Software Foundation; either version 2
 + * of the License, or (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + *   (C)Copyright 1997-1998 DAVICOM Semiconductor,Inc. All Rights Reserved.
 + *
 + * V0.11   06/20/2001  REG_0A bit3=1, default enable BP with DA match
 + * 06/22/2001  Support DM9801 progrmming
 + * E3: R25 = ((R24 + NF)  0x00ff) | 0xf000
 + * E4: R25 = ((R24 + NF)  0x00ff) | 0xc200
 + * R17 = (R17  0xfff0) | NF + 3
 + * E5: R25 = ((R24 + NF - 3)  0x00ff) | 0xc200
 + * R17 = (R17  0xfff0) | NF
 + *
 + * v1.00   modify by simon 2001.9.5
 + * change for kernel 2.4.x
 + *
 + * v1.1   11/09/2001   fix force mode bug
 + *
 + * v1.2   03/18/2003   Weilun Huang [EMAIL PROTECTED]:
 + * Fixed phy reset.
 + * Added tx/rx 32 bit mode.
 + * Cleaned up for kernel merge.
 + *
 + *03/03/2004Sascha Hauer [EMAIL PROTECTED]
 + *  Port to 2.6 kernel
 + *
 + *   24-Sep-2004   Ben Dooks [EMAIL PROTECTED]
 + * Cleanup of code to remove ifdefs
 + * Allowed platform device data to influence access width
 + * Reformatting areas of code
 + *
 + *17-Mar-2005   Sascha Hauer [EMAIL PROTECTED]
 + *  * removed 2.4 style module parameters
 + *  * removed removed unused stat counter and fixed
 + *net_device_stats
 + *  * introduced tx_timeout function
 + *  * reworked locking
 + */
 +
 +#include linux/module.h
 +#include linux/ioport.h
 +#include linux/netdevice.h
 +#include linux/etherdevice.h
 +#include linux/init.h
 +#include linux/skbuff.h
 +#include linux/version.h
 +#include linux/spinlock.h
 +#include linux/crc32.h
 +#include linux/mii.h
 +#include linux/dm9000.h
 +#include linux/delay.h
 +
 +#include asm/delay.h
 +#include asm/irq.h
 +#include asm/io.h
 +
 +#include dm9000.h
 +
 +/* Board/System/Debug 

Re: Question on Scheduler activations

2005-03-18 Thread Imanpreet Arora
On Fri, 18 Mar 2005 20:36:58 +0530, Hong Kong Phoey
[EMAIL PROTECTED] wrote:
 RTFM




On Fri, 18 Mar 2005 20:36:58 +0530, Hong Kong Phoey
[EMAIL PROTECTED] wrote:
 RTFM

I don't mind RTFM but do you care to provide the M.  That is if you have any.

-- 

Imanpreet Singh Arora
-
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

2005-03-18 Thread Martin J. Bligh


--Mikael Pettersson [EMAIL PROTECTED] wrote (on Friday, March 18, 2005 
10:35:13 +0100):

 Mikael Pettersson writes:
   Andrew Morton writes:
 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.
   
   It seems the culprit is matroxfb-compile-error.patch which 
 unconditionally adds
   macmodes.o to the Makefile line for CONFIG_FB_MATROX. This obviously 
 breaks on !ppc.
 
 !pmac of course; I assume Martin configured for some kind of POWER box and 
 not a G5.
 
   The patch Andrew mentions above converts the Kconfig entry for FB_MATROX 
 to do a
   select FB_MACMODES if PPC_PMAC, so dropping matroxfb-compile-error.patch 
 should suffice.
 
 

Yeah, it's a 4x LPAR on PPC690 Power 4 server.

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/


Floppy drive LED

2005-03-18 Thread Alan Jenkins
I compiled my kernel (2.6.11) with the floppy driver as a module - so it
is not loaded on boot.  When the floppy driver is laoded, the LED
behaves as expected.  When I unload it, the LED stays in its current
state.  So if I do this...

# modprobe floppy; sleep 5; dd if=/dev/fd0 count=1 of=/dev/null; rmmod
floppy

...then the LED will be on when the driver is unloaded, so it will stay
that way until the driver is loaded again.

Its not at all important, and its probably known, but it doesn't look
very professional :).  Any thoughts?  Would it be possible to tell
whether the LED is on or not, and wait until its off?

Alan

-
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] pci_ids.h correction for Intel ICH7R - 2.6.11

2005-03-18 Thread Bartlomiej Zolnierkiewicz
applied
-
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] ide: hdio.txt update

2005-03-18 Thread Bartlomiej Zolnierkiewicz
Hi,

On Fri, 11 Mar 2005 15:29:08 +0900, Tejun Heo [EMAIL PROTECTED] wrote:
  Greetings Bartlomiej,
 
  I've updated the following
 
  * in_flags modification when out_flags != 0  in_flags == 0
  * more than one - one or more than one
  * tf_{in|out}_flags - {in|out}_flags as tf_* are in-kernel names
 
  I'll update the taskfile patch series after receiving your comments
 about the patches.  Also, if you have a big picture for the IDE
 driver, do you care to spill?  What I have in mind now are
 
  1. Completion-based taskfile (no direct ending/error handling of
 requests), so that we can use it for specials/rw_disk/eh/etc...
  2. Make specials (set_geometry, set_multmode...) more regular.
  3. Do error-handling/resetting in a exception handler thread.
 Maybe this and #2 should happen together.

Yep, this is the way to go.

  So, please let me know what you think.  Updated patch for hdio.txt
 follows.

thanks, applied
-
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: CDROM_SEND_PACKET as non-root?

2005-03-18 Thread ismail dönmez
growisofs works as a non-root user here.


On Fri, 18 Mar 2005 15:45:46 +0100, Martin Zwickel
[EMAIL PROTECTED] wrote:
 Hi all!
 
 I have a small question:
 What do I have to do, to let the ioctl CDROM_SEND_PACKET work as a
 non-root user under 2.6.11?
 
 I try to burn a DVD with growisofs as a non-root user without success.
 
 I know that there were some changes about access restriction (since
 2.6.8), but I haven't found anything to get a clue about the current
 status.
 
 So is it just impossible to send a packet to the DVD burner without root
 access? Do I have to use a wrapper that sets the effective user id to
 root and then runs growisofs?
 
 
 It's friday, so sorry for that stupid question, but a comment on that
 would be fine :)
 
 Regards,
 Martin
 
 -- 
 MyExcuse:
 Recursive traversal of loopback mount points
 
 Martin Zwickel [EMAIL PROTECTED]
 Research  Development
 
 TechnoTrend AG http://www.technotrend.de
 
 

-- 
Time is what you make of it
-
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] DM9000 network driver

2005-03-18 Thread Lennart Sorensen
On Fri, Mar 18, 2005 at 08:41:52PM +0530, Hong Kong Phoey wrote:
 Sacrificing readibility a little bit, you could do something useful.
 Instead of those ugly switch statements you could define function
 pointer arrays and call appropriate function
 
 switch(foo) {
 
   case 1:
  f1();
   case2 :
  f2();
 };
 
 could well become
 
 void (*func)[] = { f1, f2 };
 
 func(i);

Ewww!

How about sticking with obvious readable code rather than trying to save
a couple of conditional branches.  If it is an obvious good
optimization, let the compiler do it.  of course if you ever needed to
pass different parameters to f1 and/or f2 it would have to be rewritten
back to the original again.

Len Sorensen
-
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/


PROBLEM: Buffer I/O error on device hdg1, system freeze.

2005-03-18 Thread lkml


One line summary of the problem:
Buffer I/O error on device hdg1, system freeze.


Full description of the problem/report:
 the following error showed up in dmesg today:

 hdg: dma_intr: status=0x51 { DriveReady SeekComplete Error }
 hdg: dma_intr: error=0x40 { UncorrectableError }, LBAsect=262311, high=0, 
low=262311, sector=262311
 ide: failed opcode was: unknown
 end_request: I/O error, dev hdg, sector 262311
 Buffer I/O error on device hdg1, logical block 131124

  fscking this disk freezes the entire system.

 The disk was remounted ro afterwards.
 Disk itself is ok. Is a new one.

 Remark: average temperature of the system raised during the last 5 day
 from 21 deg C to 23 deg C as spring is approaching.

 Last summer there have been a lot of problems with the pdc at even
 higher temperatures using kernel 2.4.26 to 2.4.xx. 


Keywords (i.e., modules, networking, kernel):
PDC20269: IDE controller, CONFIG_BLK_DEV_PDC202XX_OLD=y, 
CONFIG_BLK_DEV_PDC202XX_NEW=y



/proc/version:
--

Linux version 2.6.11serviceservice ([EMAIL PROTECTED]) (gcc version 2.95.4 
20011002 (Debian prerelease)) #1 Sat Mar 5 16:31:18 CET 2005


Output of Oops.. message:
see above.


A small shell script or example program which triggers the problem:


/usr/src/linux/scripts/ver_linux:
-

If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
 
Linux service 2.6.11serviceservice #1 Sat Mar 5 16:31:18 CET 2005 i686 GNU/Linux
 
Gnu C  2.95.4
Gnu make   3.79.1
binutils   2.12.90.0.1
util-linux 2.11n
mount  2.12a
module-init-tools  3.1
e2fsprogs  1.35
reiserfsprogs  reiserfsck:
reiser4progs   fsck.reiser4:
quota-tools3.04.
PPP2.4.1
isdn4k-utils   3.5
Linux C Library2.3.2
Dynamic linker (ldd)   2.3.2
Procps 3.2.4
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.2.1
Modules Loaded usbcore 8250 serial_core parport_pc lp parport bridge 
dm_mod hisax_isac hisax isdn 8139too 3c59x mii


/proc/cpuinfo:
--

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 7
model name  : Pentium III (Katmai)
stepping: 3
cpu MHz : 551.398
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat 
pse36 mmx fxsr sse
bogomips: 1089.53



/proc/modules:
--

usbcore 114504 0 - Live 0xd098f000
8250 23200 2 - Live 0xd0933000
serial_core 21664 1 8250, Live 0xd092c000
parport_pc 39072 1 - Live 0xd08cd000
lp 12032 0 - Live 0xd0899000
parport 35776 2 parport_pc,lp, Live 0xd08fc000
bridge 50900 0 - Live 0xd091e000
dm_mod 57728 0 - Live 0xd090e000
hisax_isac 12372 0 - Live 0xd08c8000
hisax 198272 1 hisax_isac, Live 0xd093a000
isdn 135872 1 hisax, Live 0xd08d9000
8139too 25376 0 - Live 0xd08a8000
3c59x 40392 0 - Live 0xd089d000
mii 4992 2 8139too,3c59x, Live 0xd088c000


/proc/ioports:
--

-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0290-0297 : pnp 00:0f
02f8-02ff : serial
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial
0778-077a : parport0
0cf8-0cff : PCI conf1
9400-9403 : :00:0e.0
9800-987f : :00:0e.0
a000-a0ff : :00:0b.0
  a000-a0ff : 8139too
a400-a40f : :00:0a.0
  a400-a407 : ide2
  a408-a40f : ide3
a800-a803 : :00:0a.0
  a802-a802 : ide3
b000-b007 : :00:0a.0
  b000-b007 : ide3
b400-b403 : :00:0a.0
b800-b807 : :00:0a.0
d000-d0ff : :00:09.0
  d000-d0ff : 8139too
d400-d41f : :00:04.2
d800-d80f : :00:04.1
  d800-d807 : ide0
  d808-d80f : ide1
e400-e43f : :00:04.3
  e400-e43f : motherboard
e400-e403 : PM1a_EVT_BLK
e404-e405 : PM1a_CNT_BLK
e408-e40b : PM_TMR
e40c-e40f : GPE0_BLK
e800-e81f : :00:04.3
  e800-e80f : motherboard


/proc/iomem:


-0009e7ff : System RAM
0009e800-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000cc000-000ce7ff : Adapter ROM
000f-000f : System ROM
0010-0fffbfff : System RAM
  0010-0035ecd9 : Kernel code
  0035ecda-004df71f : Kernel data
0fffc000-0fffefff : ACPI Tables
0000-0fff : ACPI Non-volatile Storage
e280-e280007f : :00:0e.0
e300-e3ff : :00:0c.0
e400-e4ff : :00:0b.0
  e400-e4ff : 8139too
e480-e4803fff : :00:0a.0
e500-e5ff : :00:09.0
  e500-e5ff : 

Re: 2.6.11: CDROM_SEND_PACKET as non-root?

2005-03-18 Thread Martin Zwickel
On Fri, 18 Mar 2005 17:25:35 +0200
ismail dönmez [EMAIL PROTECTED] bubbled:

 growisofs works as a non-root user here.

which version?
I have:
growisofs 5.5, front-ending to mkisofs 2.01-unofficial-iconv
(i686-pc-linux-gnu)

Maybe it's that stupid debian distro my college is using...

-- 
MyExcuse:
Stubborn processes

Martin Zwickel [EMAIL PROTECTED]
Research  Development

TechnoTrend AG http://www.technotrend.de


pgpaAUIuWsTpu.pgp
Description: PGP signature


2.6.11 breaks modules gratuitously

2005-03-18 Thread Greg Stark

When you guys go on these make needlessly global code static kicks you
should maybe consider that even functions that aren't currently used by any
other area of the tree might be useful for module writers.

Instead of just checking which functions are currently used by other parts of
the kernel perhaps you should think about what makes a logical API and stick
to that, even if not all of the functions are currently used.

In the case of net/core/datagram.c, why make skb_copy_datagram private but
leave skb_copy_datagram_iovec global? If the latter is a useful public
function why not the former?

In particular vmware used skb_copy_datagram. So 2.6.11 broke vmware for no
good reason.



[EMAIL PROTECTED]
[NET]: misc cleanups

The patch below contains the following cleanups:
- make needlessly global code static
- remove the following unused global functions:
  - datagram.c: skb_copy_datagram
  - iovec.c: memcpy_tokerneliovec
- remove the following unneeded EXPORT_SYMBOL's:
  - datagram.c: skb_copy_datagram
  - dev.c: ing_filter
  - iovec.c: memcpy_tokerneliovec
  - netpoll.c: netpoll_send_skb
  - rtnetlink.c: rtnetlink_dump_ifinfo
  - sock.c: sock_alloc_send_pskb

Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]


-- 
greg

-
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: PROBLEM: 2.6.11.4 vaio z1xmp mouse click

2005-03-18 Thread Dmitry Torokhov
On Mon, 14 Mar 2005 19:16:29 +0100, dave [EMAIL PROTECTED] wrote:
 
 hy,
 
 Upgrading kernel from Linux 2.6.10 (full) to 2.6.11.4(full) the left mouse
 click get losed (I can not clik).

Is your touchpad being detected as an ALPS touchpad? There are some
issues with tapping that should be fixed in 2.6.12. In the meantime
you could try 2.6.11-mm or force PS/2 compatinbility mode by bootintg
with psmouse.proto=exps on kernel command line.
-- 
Dmitry
-
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/


CONFIANCE

2005-03-18 Thread jacob_amos
Bonjour,


je suis le M. Jacob Amos Cadre à la BANQUE
INTERNATIONALE DE LAFRIQUE DE LOUEST(BIAO)Abidjan Cote
D'ivoire
Permettez moi de vous dire que je ne crois pas au
hasard et que toute chose arrive parce que le TOUT
PUISSANT le permet.
J'ai découvert des fonds abandonnés d'un montant de
11.5millions de dollars que notre banque est sur le
point de reconvertir dans son trésor propre car selon
le reglèment interieur et les statuts,tout somme
d'argent non réclamée au dela d'un certain nombre
d'années est systématiquement reconverti dans le
trésor de la banque.

C'est argent appartenait à l'un de nos clients
ALLEMAND d'origine qui trouva la mort avec toute sa
famille dans un accident d'avion et jusqu'à ce jour
aucune personne ne s'est presenté comme bénéficiaire
ou ayant droit.
Je vous ai donc contacté pour qu'ensemble nous
fassions sortir ces fonds de ce pays la cote d'ivoire
pour votre compte et qu'au terme de cette transaction
nous partagions ces fonds selon les pourcentages
convenus à savoir 30% pour vous et le reste à moi.

Sachez que j'ai pris tous les dispositions utiles pour
la reussite de cette affaire autrement je ne perdrais
pas mon temps ni le votre.
Lorsque vous me donnerez votre accord de principe je
vous enverrai le formulaire de réclamation que vous
remplirez et faxerez à la banque en vous presentant
comme associé du defunt donc bénéficiaire des fonds et
moi à la banque appuierai votre réclamation de sorte
que la baqnue transfère les fonds dans votre compte
indiqué.

Toutes les dispositions seront prises pour que cette
transaction soit légale avec documents authentiques à
l'appui
Un détail important gardez la discretion autour de
cette affaire et ne permettez pas que la banque sache
que c'est qui vous fournit toutes ces informations au
risque de compromettre la transaction dans laquelle
j'ai investi beaucoup d'aregnt d'efforts et de temps.

Dans l'attente d'une réponse favorable je vous adresse
mes fraternelles salutations


Jacob Amos.



___
Con Terra MAIL obtienes 6MB de espacio además de bloqueo ANTISPAM
http://terramail.terra.com.mx/TerraMail/
Acceso a Internet 3 x 1, desde ¡$179 pesos al mes! 
http://www.terra.com.mx/acceso/suscribete/
Encuentra los mejores productos y precios increibles!!
Aprovecha nuestra promoción a 12 pagos sin intereses con Banamex y Bancomer
http://www.decompras.com/



-
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

2005-03-18 Thread Paul E. McKenney
On Fri, Mar 18, 2005 at 10:53:27AM +0100, Ingo Molnar wrote:
 
 * Ingo Molnar [EMAIL PROTECTED] wrote:
 
  there's one detail on PREEMPT_RT though (which i think you noticed too). 
  
  Priority inheritance handling can be done in a pretty straightforward
  way as long as no true read-side nesting is allowed for rwsems and
  rwlocks - i.e. there's only one owner of a lock at a time. So
  PREEMPT_RT restricts rwsem and rwlock concurrency: readers are
  writers, with the only exception that they are allowed to 'self-nest'.
  [...]
 
 this does not affect read-side RCU, because read-side RCU can never
 block a higher-prio thread. (as long as callback processing is pushed
 into a separate kernel thread.)
 
 so RCU will be pretty much the only mechanism (besides lock-free code)
 that allows reader concurrency on PREEMPT_RT.

This is a relief!  I was wondering how on earth I was going to solve
the multi-task priority-inheritance problem!

But...  How do we handle the following scenario?

0.  A bunch of low-priority threads are preempted in the
middle of various RCU read-side critical sections.

1.  High-priority thread does kmalloc(), but there is no
memory, so it blocks.

2.  OOM handling notices, and decides to clean up the outstanding
RCU callbacks.  It therefore invokes _synchronize_kernel()
(in implementation #5).

3.  The _synchronize_kernel() function tries to acquire all of
the read-side locks, which are held by numerous preempted
low-priority threads.

4.  What now???

Or does the current patch do priority inheritance across the memory
allocator?  In other words, can we get away with ignoring this one?  ;-)

Thanx, Paul
-
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

2005-03-18 Thread Paul E. McKenney
On Fri, Mar 18, 2005 at 11:03:39AM +0100, Ingo Molnar wrote:
 
 there's a problem in #5's rcu_read_lock():
 
 void
 rcu_read_lock(void)
 {
 preempt_disable();
 if (current-rcu_read_lock_nesting++ == 0) {
 current-rcu_read_lock_ptr =
 __get_cpu_var(rcu_data).lock;
 read_lock(current-rcu_read_lock_ptr);
 }
 preempt_enable();
 }
 
 not only are read_lock()-ed sections preemptible, read_lock() itself may
 block, so it cannot be called from within preempt_disable(). How about
 something like:
 
 void
 rcu_read_lock(void)
 {
 preempt_disable();
 if (current-rcu_read_lock_nesting++ == 0) {
 current-rcu_read_lock_ptr =
 __get_cpu_var(rcu_data).lock;
 preempt_enable();
 read_lock(current-rcu_read_lock_ptr);
 } else
 preempt_enable();
 }
 
 this would still make it 'statistically scalable' - but is it correct?

Good catch!

Also good question...

Strictly speaking, it is not necessary to block callback invocation until
just after rcu_read_lock() returns.

It is correct as long as there is no sort of upcall or callback that
can masquerade as this task.  I know of no such thing in the Linux kernel.
In fact such a thing would break a lot of code, right?

Any tool that relied on the -rcu_read_lock_nesting counter to deduce
RCU state would be confused by this change, but there might be other
ways of handling this.  Also, we are currently making do without such
a tool.

It should be possible to move the preempt_enable() further forward
ahead of the assignment to -rcu_read_lock_ptr, since the assignment
to -rcu_read_lock_ptr is strictly local.  Not sure that this is
worthwhile, thoughts?

void
rcu_read_lock(void)
{
preempt_disable();
if (current-rcu_read_lock_nesting++ == 0) {
preempt_enable();
current-rcu_read_lock_ptr =
__get_cpu_var(rcu_data).lock;
read_lock(current-rcu_read_lock_ptr);
} else
preempt_enable();
}

The other question is whether preempt_disable() is needed in the first
place.  The two task-structure fields are not accessed except by the
task itself.  I bet that the following is just fine:

void
rcu_read_lock(void)
{
if (current-rcu_read_lock_nesting++ == 0) {
current-rcu_read_lock_ptr =
__get_cpu_var(rcu_data).lock;
read_lock(current-rcu_read_lock_ptr);
}
}

Thoughts?

Thanx, Paul
-
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

2005-03-18 Thread Paul E. McKenney
On Fri, Mar 18, 2005 at 04:56:41AM -0800, Bill Huey wrote:
 On Thu, Mar 17, 2005 at 04:20:26PM -0800, Paul E. McKenney wrote:
  5. Scalability -and- Realtime Response.
 ...
 
  void
  rcu_read_lock(void)
  {
  preempt_disable();
  if (current-rcu_read_lock_nesting++ == 0) {
  current-rcu_read_lock_ptr =
  __get_cpu_var(rcu_data).lock;
  read_lock(current-rcu_read_lock_ptr);
  }
  preempt_enable();
  }
 
 Ok, here's a rather unsure question...
 
 Uh, is that a sleep violation if that is exclusively held since it
 can block within an atomic critical section (deadlock) ?

Hey, I wasn't joking when I said that I probably got something wrong!  ;-)

My current thought is that the preempt_disable()/preempt_enable() can
be dropped entirely.  Messes up any tool that browses through
-rcu_read_lock_nesting, but don't see any other problem.  Yet, anyway!

Thanx, Paul
-
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] DM9000 network driver

2005-03-18 Thread John W. Linville
On Fri, Mar 18, 2005 at 10:25:54AM -0500, Lennart Sorensen wrote:
 On Fri, Mar 18, 2005 at 08:41:52PM +0530, Hong Kong Phoey wrote:

  switch(foo) {
  
case 1:
   f1();
case2 :
   f2();
  };
  
  could well become
  
  void (*func)[] = { f1, f2 };
  
  func(i);
 
 Ewww!

My thoughts exactly...there might be a place for something like that,
but I don't think this is it...

John
-- 
John W. Linville
[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] SUSPEND_PD_PAGES-fix

2005-03-18 Thread Coywolf Qi Hunt
Pavel Machek wrote:
Hi!

This fixes SUSPEND_PD_PAGES, which wastes one page under most cases.
-This fixes SUSPEND_PD_PAGES, which wastes one page under most cases.
+This fixes SUSPEND_PD_PAGES, which, in rare instances, would waste a signle 
page.
I see rafael is going to drop it. Anyway, my description was wrong.
Coywolf

Ok, applied to my tree, will eventually propagate it. (I hope it looks
okay to you, rafael).

Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED]
diff -pruN 2.6.11-mm4/include/linux/suspend.h 
2.6.11-mm4-cy/include/linux/suspend.h
--- 2.6.11-mm4/include/linux/suspend.h  2005-03-17 01:22:16.0 +0800
+++ 2.6.11-mm4-cy/include/linux/suspend.h   2005-03-17 04:14:16.0 
+0800
@@ -34,7 +34,7 @@ typedef struct pbe {
#define SWAP_FILENAME_MAXLENGTH 32
-#define SUSPEND_PD_PAGES(x) (((x)*sizeof(struct pbe))/PAGE_SIZE+1)
+#define SUSPEND_PD_PAGES(x) (((x)*sizeof(struct 
pbe)+PAGE_SIZE-1)/PAGE_SIZE)
extern dev_t swsusp_resume_device;
   

-
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

2005-03-18 Thread Paul E. McKenney
On Fri, Mar 18, 2005 at 05:17:29AM -0800, Bill Huey wrote:
 On Fri, Mar 18, 2005 at 04:56:41AM -0800, Bill Huey wrote:
  On Thu, Mar 17, 2005 at 04:20:26PM -0800, Paul E. McKenney wrote:
   5. Scalability -and- Realtime Response.
  ...
  
 void
 rcu_read_lock(void)
 {
 preempt_disable();
 if (current-rcu_read_lock_nesting++ == 0) {
 current-rcu_read_lock_ptr =
 __get_cpu_var(rcu_data).lock;
 read_lock(current-rcu_read_lock_ptr);
 }
 preempt_enable();
 }
  
  Ok, here's a rather unsure question...
  
  Uh, is that a sleep violation if that is exclusively held since it
  can block within an atomic critical section (deadlock) ?
 
 I'd like to note another problem. Mingo's current implementation of rt_mutex
 (super mutex for all blocking synchronization) is still missing reader counts
 and something like that would have to be implemented if you want to do 
 priority
 inheritance over blocks.
 
 This is going to throw a wrench into your implementation if you assume that.

If we need to do priority inheritance across the memory allocator, so
that high-priority tasks blocked waiting for memory pass their priority
on to RCU readers, agreed.  But I don't see any sign that real-time
preempt does this.

In absence of this, as Ingo noted, the fact that readers don't block
each other should make things be safe.  I think...

Thanx, Paul
-
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

2005-03-18 Thread Ingo Molnar

* Paul E. McKenney [EMAIL PROTECTED] wrote:

 preempt_disable();
 if (current-rcu_read_lock_nesting++ == 0) {
 current-rcu_read_lock_ptr =
 __get_cpu_var(rcu_data).lock;
 read_lock(current-rcu_read_lock_ptr);
 }
 preempt_enable();

 My current thought is that the preempt_disable()/preempt_enable() can
 be dropped entirely.  Messes up any tool that browses through
 -rcu_read_lock_nesting, but don't see any other problem.  Yet,
 anyway!

yeah - this sounds good. (We are not aiming for irq-safe RCU anyway, on
PREEMPT_RT.)

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: Real-Time Preemption and RCU

2005-03-18 Thread Ingo Molnar

* Bill Huey [EMAIL PROTECTED] wrote:

 I'd like to note another problem. Mingo's current implementation of
 rt_mutex (super mutex for all blocking synchronization) is still
 missing reader counts and something like that would have to be
 implemented if you want to do priority inheritance over blocks.

i really have no intention to allow multiple readers for rt-mutexes. We
got away with that so far, and i'd like to keep it so. Imagine 100
threads all blocked in the same critical section (holding the read-lock)
when a highprio writer thread comes around: instant 100x latency to let
all of them roll forward. The only sane solution is to not allow
excessive concurrency. (That limits SMP scalability, but there's no
other choice i can see.)

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 breaks modules gratuitously

2005-03-18 Thread Ian Campbell
On Fri, 2005-03-18 at 10:33 -0500, Greg Stark wrote:

 In particular vmware used skb_copy_datagram. So 2.6.11 broke vmware for no
 good reason.

I don't know about the validity or otherwise of (un)exporting
skb_copy_datagram but for what it's worth
http://ftp.cvut.cz/vmware/vmware-any-any-update89.tar.gz has been
updated to work with 2.6.11.

Ian.

-- 
Ian Campbell
Current Noise: Entombed - Out of Heaven

Santa Claus is watching!

-
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: Question on Scheduler activations

2005-03-18 Thread Diego Calleja
El Fri, 18 Mar 2005 20:46:42 +0530,
Imanpreet Arora [EMAIL PROTECTED] escribió:

 I don't mind RTFM but do you care to provide the M.  That is if you have any.

What Update: this document is obsolete means is that the document is 
obsolete. 

Probably it should include a link to 
http://people.redhat.com/drepper/nptl-design.pdf
-
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] DM9000 network driver

2005-03-18 Thread Dmitry Torokhov
On Fri, 18 Mar 2005 10:25:54 -0500, Lennart Sorensen
[EMAIL PROTECTED] wrote:
 On Fri, Mar 18, 2005 at 08:41:52PM +0530, Hong Kong Phoey wrote:
  Sacrificing readibility a little bit, you could do something useful.
  Instead of those ugly switch statements you could define function
  pointer arrays and call appropriate function
 
  switch(foo) {
 
case 1:
   f1();
case2 :
   f2();
  };
 
  could well become
 
  void (*func)[] = { f1, f2 };
 
  func(i);
 
 Ewww!
 
 How about sticking with obvious readable code rather than trying to save
 a couple of conditional branches.

On top of that I highly doibt that setting up stack frame for an
indirect function call is less expensive than a conditional branch.

-- 
Dmitry
-
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] DM9000 network driver

2005-03-18 Thread linux-os
On Fri, 18 Mar 2005 [EMAIL PROTECTED] wrote:
On Fri, Mar 18, 2005 at 08:41:52PM +0530, Hong Kong Phoey wrote:
Sacrificing readibility a little bit, you could do something useful.
Instead of those ugly switch statements you could define function
pointer arrays and call appropriate function
switch(foo) {
  case 1:
 f1();
  case2 :
 f2();
};
could well become
void (*func)[] = { f1, f2 };
func(i);
Ewww!
How about sticking with obvious readable code rather than trying to save
a couple of conditional branches.  If it is an obvious good
optimization, let the compiler do it.  of course if you ever needed to
pass different parameters to f1 and/or f2 it would have to be rewritten
back to the original again.
Len Sorensen
Also, those ugly switch-statements are not ugly and are
most efficient if the case(s) are enumerated types in
automatically-generated incrementing order. I see a lot
of values assigned to enumerated types which destroys their
usefulness. They might just as well be #defined values
if you do this.
Code that does:
enum {
   one,
   two,
   three };
   switch(val)
   {
   case one:
   case two:
   case three:
   
   }
... calculates the offset of each of those case(s) and branches
directly.
movl(val), %ebx
shll$2, %ebx# Size of table entries
jmp *table(%ebx)# Table contains a list of switch offsets
If somebody does:
enum {
   one = 1234,
   two = 4321,
   three = 8765
   };
.. no such calculation is possible and the compiler output must
devolve to:
movl(val), %eax
cmpl$1235, %eax
jz  one
cmpl$4321, %eax
jz  two
cmpl$8765, %eax
jz  three
jmp none
one:
 a bunch of comparisons. So, you make switches efficient
by using enumerated types without fixed values. Of course
some switches, such as found in ioctl() function numbers
must be hard-coded because they must correspond to whatever
the 'C' runtime library and its headers expect. In this
case, you can make them efficient by having no holes
in the allocated numbers and putting the cases in sorted
order. This gives the 'C' compiler a chance to optimize.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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/


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

2005-03-18 Thread Ralf Hildebrandt
Mar 18 14:56:35 newserver kernel: usb 2-2: new low speed USB device using 
uhci_hcd and address 7
Mar 18 14:56:36 newserver usb.agent[17991]:  usbhid: already loaded
Mar 18 14:56:37 newserver kernel: hiddev96: USB HID v1.00 Device [American 
Power Conversion Back-UPS 500 FW: 6.4.I USB FW: c1 ] on usb-:00:1d.1-2
Mar 18 14:56:37 newserver udev[18027]: configured rule in 
'/etc/udev/rules.d/udev.rules[38]' applied, 'hiddev0' becomes 'usb/%k'
Mar 18 14:56:37 newserver udev[18027]: creating device node '/dev/usb/hiddev0'
Mar 18 14:57:18 newserver hidups[18038]: Startup successful
Mar 18 14:57:19 newserver kernel: drivers/usb/input/hid-core.c: ctrl urb status 
-84 received
Mar 18 14:57:19 newserver kernel: drivers/usb/input/hid-core.c: ctrl urb status 
-71 received
Mar 18 14:57:19 newserver kernel: usb 2-2: USB disconnect, address 7
Mar 18 14:57:19 newserver kernel: drivers/usb/input/hid-core.c: input irq 
status -84 received
Mar 18 14:57:19 newserver kernel: drivers/usb/input/hid-core.c: can't resubmit 
intr, :00:1d.1-2/input0, status -19
Mar 18 14:57:19 newserver kernel: Unable to handle kernel NULL pointer 
dereference at virtual address 0008
Mar 18 14:57:19 newserver kernel:  printing eip:
Mar 18 14:57:19 newserver kernel: d0a361b1
Mar 18 14:57:19 newserver kernel: *pde = 
Mar 18 14:57:19 newserver kernel: Oops:  [#1]
Mar 18 14:57:19 newserver kernel: PREEMPT
Mar 18 14:57:19 newserver kernel: Modules linked in: usbhid pppoe pppox 
ppp_generic slhc af_packet lp autofs4 ipt_TCPMSS ipt_MASQUERADE ipt_state 
iptable_filter iptable_nat ipv6 ip_conntrack ip_tables ide_cd cdrom parport_pc 
parport tsdev mousedev psmouse floppy evdev rtc pcspkr 3c59x snd_intel8x0 
snd_ac97_codec snd_pcm snd_timer snd snd_page_alloc i810_audio ac97_codec 
soundcore i2c_i801 i2c_core pci_hotplug usblp uhci_hcd intel_agp agpgart dm_mod 
capability commoncap usbkbd usbcore ext3 jbd mbcache ide_generic atiixp 
pdc202xx_old cmd64x hpt366 ide_disk generic amd74xx serverworks cs5530 ns87415 
sc1200 sis5513 piix alim15x3 hpt34x cs5520 opti621 slc90e66 cy82c693 trm290 
pdc202xx_new rz1000 via82cxxx siimage aec62xx triflex ide_core unix fbcon font 
bitblit vesafb cfbcopyarea cfbimgblt cfbfillrect
Mar 18 14:57:19 newserver kernel: CPU:0
Mar 18 14:57:19 newserver kernel: EIP:0060:[pg0+275272113/1069863936]
Not tainted VLI
Mar 18 14:57:19 newserver kernel: EFLAGS: 00010286   (2.6.10-1-686)
Mar 18 14:57:19 newserver kernel: EIP is at hid_init_reports+0x151/0x1d0 
[usbhid]
Mar 18 14:57:19 newserver kernel: eax:    ebx:    ecx: cb15e000 
  edx: be333c00
Mar 18 14:57:19 newserver kernel: esi: c4f3e024   edi: c4f3e000   ebp:  
  esp: c8679eb0
Mar 18 14:57:19 newserver kernel: ds: 007b   es: 007b   ss: 0068
Mar 18 14:57:19 newserver kernel: Process hidups (pid: 18038, 
threadinfo=c8678000 task=ce837590)
Mar 18 14:57:19 newserver kernel: Stack: c4f3e000 cb15e200 0080 0021 
0100   
Mar 18 14:57:19 newserver kernel:1388 c4f3e020 4805 cb15e000 
c4f3e000  d0a3785f c4f3e000
Mar 18 14:57:19 newserver kernel:0005 c8678000 c01253b4 ce837590 
 00040004 c8678000 c8679f20
Mar 18 14:57:19 newserver kernel: Call Trace:
Mar 18 14:57:19 newserver kernel:  [pg0+275277919/1069863936] 
hiddev_ioctl+0x1cf/0x9d0 [usbhid]
Mar 18 14:57:19 newserver kernel:  [ptrace_stop+132/192] ptrace_stop+0x84/0xc0
Mar 18 14:57:19 newserver kernel:  [ptrace_notify+103/144] 
ptrace_notify+0x67/0x90
Mar 18 14:57:19 newserver kernel:  [sys_ioctl+234/592] sys_ioctl+0xea/0x250
Mar 18 14:57:19 newserver kernel:  [do_syscall_trace+71/144] 
do_syscall_trace+0x47/0x90
Mar 18 14:57:19 newserver kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
Mar 18 14:57:19 newserver kernel: Code: b8 88 13 00 00 31 ed 8b 11 89 44 24 20 
31 c0 c1 e2 08 89 44 24 1c 81 ca 00 00 00 80 89 6c 24 18 0f b7 87 4c 0c 00 00 
89 44 24 14 0f b7 43 08 89 54 24 04 89 0c 24 89 44 24 10 b8 21 00 00 00 89
Mar 18 14:57:19 newserver udev[18047]: removing device node '/dev/usb/hiddev0'

-- 
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/


Re: [PATCH] Add a non-blocking interface to the I2C code, part 1

2005-03-18 Thread Corey Minyard
Greg KH wrote:
On Wed, Mar 02, 2005 at 01:58:51PM -0600, Corey Minyard wrote:
 

This patch reorganizes the I2C SMBus formatting code to make it more
suitable for the upcoming non-blocking changes.
   

You are changing too much stuff here to claim it's just a
reorganization:
	- variable name changes for no reason
 

Well, yes.  Both adap and adapter are used to refer to the same 
thing in the file; adap seemed to be the most common usage so I chose 
that for the new functions I added. In one place I changed adapter to 
adap.  I also changed res to result.  I can fix those.  Or I can 
submit a patch first that renames the adap and adapter to make the usage 
consistent (I would prefer adapter).

	- coding style changes (improper ones at that)
 

I don't see that.  The ugliest thing about this is the functions that 
take the massive numbers of parameters, but that goes away in the next 
patch which puts all the data into a single data structure and passes it 
around.  The code here was also very inconsistent about use of spaces, 
like x(a,b,c) vs x(a, b, c), struct a *b vs struct a * b, a=b vs 
a = b.  It's hard to know what was right.  The changes I made in these 
respects was to try to make it use the usage most common in the file.

If you like, I can do a pass and make everything consistent in the file 
as part of the previous patch I talked about.

	- logic changes.
 

I tried very hard not to make logic changes.  Now I see there were two 
places where the function checked client-adapter-algo-master_xfer 
then called i2c_transfer(), which did the same check and returned the 
same error if it was NULL.  I removed the redundant check.  That belongs 
in a separate patch.  I couldn't find any others.

What exactly are you doing with this patch, and why?
 

The i2c main functions do the following:
 Format the data for transmission
 Send the data to the next layer down for handling
 Clean up the results
The original code did all this in single big functions.  This patch 
breaks the formatting and cleanup operations into separate functions.  
Beyond one big function being ugly, the non-blocking code needs this 
because it needs to perform these separately.  When you start the 
operation, the non-blocking code needs to do the format then return.  
Later on, when the operation is complete, the thread of execution 
handling the completion will do the cleanup.

-Corey
-
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: OOM problems with 2.6.11-rc4

2005-03-18 Thread Noah Meyerhans
Hi Andrew, Andrea, et al.  Sorry for taking a while to get back to you
on this.  Thanks a lot for the work you've already put in to this.  We
built a 2.6.11.4 kernel with Andrea's first patch for this problem (the
patch is included at the end of this mail, just to make sure you know
which one I'm referring to).  We had also switched back to overcommit
mode 0.  More comments follow inline...

On Tue, Mar 15, 2005 at 03:46:08PM -0800, Andrew Morton wrote:
  Active:12382 inactive:280459 dirty:214 writeback:0 unstable:0 free:2299 
  slab:220221 mapped:12256 pagetables:122
 
 Vast amounts of slab - presumably inode and dentries.
 
 What sort of local filesystems are in use?

Well, that's certainly an interesting question.  The filesystem is IBM's
JFS.  If you tell me that's part of the problem, I'm not likely to
disagree.  8^)

 Can you take a copy of /proc/slabinfo when the backup has run for a while,
 send it?

We triggerred a backup process, and I watched slabtop and /proc/meminfo
while it was running, right up until the time the OOM killer was
triggered.  Unfortunately I didn't get a copy of slabinfo.  Hopefully
the slabtop and meminfo output help a bit, though.  Here are the last
three seconds worth of /proc/meminfo:

Fri Mar 18 10:41:08 EST 2005
MemTotal:  2074660 kB
MemFree:  8492 kB
Buffers: 19552 kB
Cached:1132916 kB
SwapCached:   3672 kB
Active:  55040 kB
Inactive:  1136024 kB
HighTotal: 1179072 kB
HighFree:  576 kB
LowTotal:   895588 kB
LowFree:  7916 kB
SwapTotal: 3615236 kB
SwapFree:  3609168 kB
Dirty:  68 kB
Writeback:   0 kB
Mapped:  43744 kB
Slab:   861952 kB
CommitLimit:   4652564 kB
Committed_AS:53272 kB
PageTables:572 kB
VmallocTotal:   114680 kB
VmallocUsed:  6700 kB
VmallocChunk:   107964 kB
Fri Mar 18 10:41:10 EST 2005
MemTotal:  2074660 kB
MemFree:  8236 kB
Buffers: 19512 kB
Cached:1132884 kB
SwapCached:   3672 kB
Active:  54708 kB
Inactive:  1136288 kB
HighTotal: 1179072 kB
HighFree:  576 kB
LowTotal:   895588 kB
LowFree:  7660 kB
SwapTotal: 3615236 kB
SwapFree:  3609168 kB
Dirty:  68 kB
Writeback:   0 kB
Mapped:  43744 kB
Slab:   862216 kB
CommitLimit:   4652564 kB
Committed_AS:53272 kB
PageTables:572 kB
VmallocTotal:   114680 kB
VmallocUsed:  6700 kB
VmallocChunk:   107964 kB
date wasn't inserted here because OOM killer killed it
MemTotal:  2074660 kB
MemFree:  8620 kB
Buffers: 19388 kB
Cached:1132552 kB
SwapCached:   3780 kB
Active:  56200 kB
Inactive:  1134388 kB
HighTotal: 1179072 kB
HighFree:  960 kB
LowTotal:   895588 kB
LowFree:  7660 kB
SwapTotal: 3615236 kB
SwapFree:  3609204 kB
Dirty: 104 kB
Writeback:   0 kB
Mapped:  43572 kB
Slab:   862484 kB
CommitLimit:   4652564 kB
Committed_AS:53100 kB
PageTables:564 kB
VmallocTotal:   114680 kB
VmallocUsed:  6700 kB
VmallocChunk:   107964 kB

Here are the top few entries from the last page of slabtop:
830696 830639  99%0.80K 2076744830696K jfs_ip
129675   4841   3%0.05K   1729   75  6916K buffer_head
 39186  35588  90%0.27K   2799   14 11196K radix_tree_node
  5983   2619  43%0.12K193   31   772K size-128
  4860   4728  97%0.05K 60   81   240K journal_head
  4403   4403 100%0.03K 37  119   148K size-32
  4164   4161  99%1.00K   10414  4164K size-1024
  3857   1552  40%0.13K133   29   532K dentry_cache
  3355   1781  53%0.06K 55   61   220K size-64
  3103   3026  97%0.04K 29  107   116K sysfs_dir_cache
  2712   2412  88%0.02K 12  22648K dm_io
  2712   2412  88%0.02K 12  22648K dm_tio



 Does increasing /proc/sys/vm/vfs_cache_pressure help?  If you're watching
 /proc/meminfo you should be able to observe the effect of that upon the
 Slab: figure.

It doesn't have any noticable effect on the stability of the machine.  I
set it to 1 but within a few hours the machine had crashed again.

We weren't able to capture all of the console messages prior to the
crash.  Here are some of them.  Note that, again, the last memory dump
is was manually triggered via SysRq:

nactive:132kB present:16384kB pages_scanned:1589 all_unreclaimable? yes
lowmem_reserve[]: 0 880 2031
Normal free:3752kB min:3756kB low:4692kB high:5632kB active:9948kB 
inactive:9648kB present:901120kB pages_scanned:20640 all_unreclaimable? yes
lowmem_reserve[]: 0 0 9212
HighMem free:960kB min:512kB low:640kB high:768kB active:45132kB 
inactive:1125920kB present:1179136kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 1*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 1*1024kB 

Re: [PATCH] DM9000 network driver

2005-03-18 Thread Alan Cox
On Gwe, 2005-03-18 at 13:31, Sascha Hauer wrote:
 Hello all,
 
 This patch adds support for the davicom dm9000 network driver. The
 dm9000 is found on some embedded arm boards such as the pimx1 or the
 scb9328.

Unless I'm missing something its just yet another NE2000 (ie 8390) clone
and can used the 8390 core or maybe even ne2k-pci  ?

-
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

2005-03-18 Thread Joel Schopp
Mikael Pettersson wrote:
Andrew Morton writes:
  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.

It seems the culprit is matroxfb-compile-error.patch which unconditionally 
adds
macmodes.o to the Makefile line for CONFIG_FB_MATROX. This obviously breaks on 
!ppc.
The patch Andrew mentions above converts the Kconfig entry for FB_MATROX to do a
select FB_MACMODES if PPC_PMAC, so dropping matroxfb-compile-error.patch 
should suffice.

matroxfb-compile-error.patch was a valid fix for a compile problem. It 
was against 2.6.11-bk10, therefore wasn't in the 2.6.11-bk6 or 2.6.11bk7 
you had problems with and didn't cause this mess to begin with.

It appears the problem was more systemic than what I saw during my 
compile, thus the fbdev-kconfig-fix-for-macmodes-and-ppc.patch probably 
fixes the problem I fixed and a host of others.  Of course it conflicts 
with my patch.

Please drop the matroxfb-compile-error.patch and if the problem isn't 
truly fixed by fbdev-kconfig-fix-for-macmodes-and-ppc.patch I will 
resend it.
-
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/


  1   2   3   >