[PATCH 1/3] slab: introduce krealloc

[Pekka J Enberg]

From: Pekka Enberg <[EMAIL PROTECTED]>

Introduce krealloc() for reallocating memory while preserving contents.

Cc: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
 include/linux/slab.h |1 +
 mm/util.c|   34 ++
 2 files changed, 35 insertions(+)

Index: 2.6/include/linux/slab.h
===
--- 2.6.orig/include/linux/slab.h   2007-02-21 09:05:08.0 +0200
+++ 2.6/include/linux/slab.h2007-02-21 09:05:47.0 +0200
@@ -72,6 +72,7 @@
  */
 void *__kmalloc(size_t, gfp_t);
 void *__kzalloc(size_t, gfp_t);
+void *krealloc(const void *, size_t, gfp_t);
 void kfree(const void *);
 unsigned int ksize(const void *);
 
Index: 2.6/mm/util.c
===
--- 2.6.orig/mm/util.c  2007-02-21 09:05:49.0 +0200
+++ 2.6/mm/util.c   2007-02-21 09:34:32.0 +0200
@@ -18,6 +18,40 @@
 }
 EXPORT_SYMBOL(__kzalloc);
 
+/**
+ * krealloc - reallocate memory. The contents will remain unchanged.
+ *
+ * @p: object to reallocate memory for.
+ * @new_size: how many bytes of memory are required.
+ * @flags: the type of memory to allocate.
+ *
+ * The contents of the object pointed to are preserved up to the
+ * lesser of the new and old sizes.  If @p is %NULL, krealloc()
+ * behaves exactly like kmalloc().  If @size is 0 and @p is not a
+ * %NULL pointer, the object pointed to is freed.
+ */
+void *krealloc(const void *p, size_t new_size, gfp_t flags)
+{
+   void *ret;
+
+   if (unlikely(!p))
+   return kmalloc_track_caller(new_size, flags);
+
+   if (unlikely(!new_size)) {
+   kfree(p);
+   return NULL;
+   }
+
+   ret = kmalloc_track_caller(new_size, flags);
+   if (!ret)
+   return NULL;
+
+   memcpy(ret, p, min(new_size, ksize(p)));
+   kfree(p);
+   return ret;
+}
+EXPORT_SYMBOL(krealloc);
+
 /*
  * kstrdup - allocate space for and copy an existing string
  *
-
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/3] slab: export ksize to modules

[Pekka J Enberg]

From: Pekka Enberg <[EMAIL PROTECTED]>

This exports ksize in slab and slob allocators to modules.

Cc: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
 mm/slab.c |1 +
 mm/slob.c |2 ++
 2 files changed, 3 insertions(+)

Index: 2.6/mm/slab.c
===
--- 2.6.orig/mm/slab.c  2007-02-21 09:46:16.0 +0200
+++ 2.6/mm/slab.c   2007-02-21 09:46:25.0 +0200
@@ -4485,3 +4485,4 @@
 
return obj_size(virt_to_cache(objp));
 }
+EXPORT_SYMBOL(ksize);
Index: 2.6/mm/slob.c
===
--- 2.6.orig/mm/slob.c  2007-02-21 09:46:28.0 +0200
+++ 2.6/mm/slob.c   2007-02-21 09:46:42.0 +0200
@@ -240,6 +240,8 @@
return ((slob_t *)block - 1)->units * SLOB_UNIT;
 }
 
+EXPORT_SYMBOL(ksize);
+
 struct kmem_cache {
unsigned int size, align;
const char *name;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] unionfs: fix up slab abuses

[Pekka J Enberg]

From: Pekka Enberg <[EMAIL PROTECTED]>

This changes unionfs to query the actual buffer size with ksize()
instead of playing tricks with malloc_sizes.  Also converts an
open-coded reallocation to use the new krealloc API.

Cc: Josef Sipek <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
 fs/unionfs/copyup.c |   26 +-
 fs/unionfs/lookup.c |   37 +
 2 files changed, 22 insertions(+), 41 deletions(-)

Index: 2.6/fs/unionfs/copyup.c
===
--- 2.6.orig/fs/unionfs/copyup.c2007-02-21 09:47:02.0 +0200
+++ 2.6/fs/unionfs/copyup.c 2007-02-21 09:47:51.0 +0200
@@ -603,7 +603,6 @@
const char *childname;
unsigned int childnamelen;
 
-   int old_kmalloc_size;
int kmalloc_size;
int num_dentry;
int count;
@@ -611,15 +610,10 @@
int old_bstart;
int old_bend;
struct dentry **path = NULL;
-   struct dentry **tmp_path;
struct super_block *sb;
 
verify_locked(dentry);
 
-   /* There is no sense allocating any less than the minimum. */
-   kmalloc_size = malloc_sizes[0].cs_size;
-   num_dentry = kmalloc_size / sizeof(struct dentry *);
-
if ((err = is_robranch_super(dir->i_sb, bindex))) {
hidden_dentry = ERR_PTR(err);
goto out;
@@ -629,10 +623,14 @@
old_bend = dbend(dentry);
 
hidden_dentry = ERR_PTR(-ENOMEM);
-   path = kzalloc(kmalloc_size, GFP_KERNEL);
+   /* There is no sense allocating any less than the minimum. */
+   path = kzalloc(sizeof(struct dentry *), GFP_KERNEL);
if (!path)
goto out;
 
+   kmalloc_size = ksize(path);
+   num_dentry = kmalloc_size / sizeof(struct dentry *);
+
/* assume the negative dentry of unionfs as the parent dentry */
parent_dentry = dentry;
 
@@ -660,19 +658,13 @@
 
/* grow path table */
if (count == num_dentry) {
-   old_kmalloc_size = kmalloc_size;
-   kmalloc_size *= 2;
-   num_dentry = kmalloc_size / sizeof(struct dentry *);
-
-   tmp_path = kzalloc(kmalloc_size, GFP_KERNEL);
-   if (!tmp_path) {
+   path = krealloc(path, kmalloc_size * 2, GFP_KERNEL);
+   if (!path) {
hidden_dentry = ERR_PTR(-ENOMEM);
goto out;
}
-   memcpy(tmp_path, path, old_kmalloc_size);
-   kfree(path);
-   path = tmp_path;
-   tmp_path = NULL;
+   kmalloc_size = ksize(path);
+   num_dentry = kmalloc_size / sizeof(struct dentry *);
}
 
} while (!hidden_parent_dentry);
Index: 2.6/fs/unionfs/lookup.c
===
--- 2.6.orig/fs/unionfs/lookup.c2007-02-21 09:48:09.0 +0200
+++ 2.6/fs/unionfs/lookup.c 2007-02-21 09:51:11.0 +0200
@@ -428,9 +428,9 @@
 /* allocate new dentry private data, free old one if necessary */
 int new_dentry_private_data(struct dentry *dentry)
 {
-   int newsize;
-   int oldsize = 0;
struct unionfs_dentry_info *info = UNIONFS_D(dentry);
+   int new_size;
+   int size;
 
spin_lock(&dentry->d_lock);
if (!info) {
@@ -445,8 +445,7 @@
mutex_lock(&info->lock);
 
info->lower_paths = NULL;
-   } else
-   oldsize = sizeof(struct path) * info->bcount;
+   }
 
info->bstart = -1;
info->bend = -1;
@@ -454,35 +453,25 @@
info->bcount = sbmax(dentry->d_sb);
atomic_set(&info->generation,
   atomic_read(&UNIONFS_SB(dentry->d_sb)->generation));
-   newsize = sizeof(struct path) * sbmax(dentry->d_sb);
+
+   new_size = sizeof(struct path) * sbmax(dentry->d_sb);
+   size = ksize(info->lower_paths);
 
/* Don't reallocate when we already have enough space. */
-   /* It would be ideal if we could actually use the slab macros to
-* determine what our object sizes is, but those are not exported.
-*/
-   if (oldsize) {
-   int minsize = malloc_sizes[0].cs_size;
-
-   if (!newsize || ((oldsize < newsize) && (newsize > minsize))) {
-   kfree(info->lower_paths);
-   info->lower_paths = NULL;
-   }
-   }
+   if (new_size > size) {
+   kfree(info->lower_paths);
 
-   if (!info->lower_paths && newsize) {
-   info->lower_paths = kmalloc(newsize, GFP_ATOMIC);
+   info->lower_paths = kmalloc(new_size, GFP_ATOMIC);
if (!info->lower_paths)
-   

Re: [PATCH 2/3] slab: export ksize to modules

[Muli Ben-Yehuda]

On Wed, Feb 21, 2007 at 10:06:52AM +0200, Pekka J Enberg wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
> 
> This exports ksize in slab and slob allocators to modules.

That's a pretty generic name... if it's going to be part of the module
API, it should be renamed to something a bit more obvious.

Cheers,
Muli
-
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] Fix trivial help text typos in Kconfig* files

[David Sterba]

(patch against 2.6.21-rc1)

Fix several typos in help text in Kconfig* files.

Signed-off-by: David Sterba <[EMAIL PROTECTED]>
---
 arch/cris/arch-v32/drivers/Kconfig |2 +-
 arch/h8300/Kconfig.debug   |4 ++--
 arch/i386/Kconfig.cpu  |4 ++--
 arch/ia64/Kconfig  |2 +-
 arch/m68knommu/Kconfig.debug   |2 +-
 arch/mips/Kconfig  |6 +++---
 arch/powerpc/Kconfig.debug |2 +-
 arch/s390/crypto/Kconfig   |2 +-
 crypto/Kconfig |2 +-
 drivers/ata/Kconfig|2 +-
 drivers/char/tpm/Kconfig   |2 +-
 drivers/crypto/Kconfig |2 +-
 drivers/macintosh/Kconfig  |2 +-
 drivers/rtc/Kconfig|2 +-
 drivers/usb/serial/Kconfig |2 +-
 init/Kconfig   |2 +-
 kernel/Kconfig.preempt |4 ++--
 net/ipv4/Kconfig   |4 ++--
 net/ipv6/netfilter/Kconfig |2 +-
 net/netfilter/Kconfig  |2 +-
 security/selinux/Kconfig   |2 +-
 21 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/arch/cris/arch-v32/drivers/Kconfig 
b/arch/cris/arch-v32/drivers/Kconfig
index f64624f..1d859c1 100644
--- a/arch/cris/arch-v32/drivers/Kconfig
+++ b/arch/cris/arch-v32/drivers/Kconfig
@@ -603,7 +603,7 @@ config ETRAX_CARDBUS
 select HOTPLUG
 select PCCARD_NONSTATIC
 help
-Enabled the ETRAX Carbus driver.
+Enabled the ETRAX Cardbus driver.
 
 config PCI
bool
diff --git a/arch/h8300/Kconfig.debug b/arch/h8300/Kconfig.debug
index e0e9bcb..554efe6 100644
--- a/arch/h8300/Kconfig.debug
+++ b/arch/h8300/Kconfig.debug
@@ -21,12 +21,12 @@ config GDB_MAGICPRINT
bool "Message Output for GDB MagicPrint service"
depends on (H8300H_SIM || H8S_SIM)
help
- kernel messages output useing MagicPrint service from GDB
+ kernel messages output using MagicPrint service from GDB
 
 config SYSCALL_PRINT
bool "SystemCall trace print"
help
- outout history of systemcall
+ output history of systemcall
 
 config GDB_DEBUG
bool "Use gdb stub"
diff --git a/arch/i386/Kconfig.cpu b/arch/i386/Kconfig.cpu
index b99c0e2..3e32fe5 100644
--- a/arch/i386/Kconfig.cpu
+++ b/arch/i386/Kconfig.cpu
@@ -107,7 +107,7 @@ config MCORE2
bool "Core 2/newer Xeon"
help
  Select this for Intel Core 2 and newer Core 2 Xeons (Xeon 51xx and 
53xx)
- CPUs. You can distingush newer from older Xeons by the CPU family
+ CPUs. You can distinguish newer from older Xeons by the CPU family
  in /proc/cpuinfo. Newer ones have 6.
 
 config MPENTIUM4
@@ -171,7 +171,7 @@ config MWINCHIP3D
help
  Select this for an IDT Winchip-2A or 3.  Linux and GCC
  treat this chip as a 586TSC with some extended instructions
- and alignment reqirements.  Also enable out of order memory
+ and alignment requirements.  Also enable out of order memory
  stores for this CPU, which can increase performance of some
  operations.
 
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index d51f0f1..7e24e7d 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -456,7 +456,7 @@ config KEXEC
help
  kexec is a system call that implements the ability to shutdown your
  current kernel, and to start another kernel.  It is like a reboot
- but it is indepedent of the system firmware.   And like a reboot
+ but it is independent of the system firmware.   And like a reboot
  you can start any kernel with it, not just Linux.
 
  The name comes from the similiarity to the exec system call.
diff --git a/arch/m68knommu/Kconfig.debug b/arch/m68knommu/Kconfig.debug
index 763c9aa..9ff47bd 100644
--- a/arch/m68knommu/Kconfig.debug
+++ b/arch/m68knommu/Kconfig.debug
@@ -5,7 +5,7 @@ source "lib/Kconfig.debug"
 config FULLDEBUG
bool "Full Symbolic/Source Debugging support"
help
- Enable debuging symbols on kernel build.
+ Enable debugging symbols on kernel build.
 
 config HIGHPROFILE
bool "Use fast second timer for profiling"
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index c6f74f1..5320767 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -934,7 +934,7 @@ choice
  byte order. These modes require different kernels and a different
  Linux distribution.  In general there is one preferred byteorder for a
  particular system but some systems are just as commonly used in the
- one or the other endianess.
+ one or the other endianness.
 
 config CPU_BIG_ENDIAN
bool "Big endian"
@@ -1712,7 +1712,7 @@ config ARCH_DISCONTIGMEM_ENABLE
bool
default y if SGI_IP27
help
- Say Y to upport efficient handling of discontiguous physical memory,
+ Say Y to

Re: [PATCH 2/3] slab: export ksize to modules

[Pekka J Enberg]

Hi Muli,

On Wed, Feb 21, 2007 at 10:06:52AM +0200, Pekka J Enberg wrote:
> > This exports ksize in slab and slob allocators to modules.

On Wed, 21 Feb 2007, Muli Ben-Yehuda wrote:
> That's a pretty generic name... if it's going to be part of the module
> API, it should be renamed to something a bit more obvious.

Well, it is the established slab API so I am bit relucant to change it. 
But if someone comes up with a better name, why not...

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

Need a little help with Software Raid 1

[Marc Perkel]

I have a partition that used to be part of a software
raid 1 array. It is now loaded as /dev/sda3 but I'd
like to mirror it to /dev/sdb3 without losing the data
on the drive. I'm a little nervous about how to set it
up as I don't want to wipe out the data.

How do I do this? Using FC6 and up 2 date software.

Thanks in advance.



 

Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367
-
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] slab: ensure cache_alloc_refill terminates

[Pekka J Enberg]

From: Pekka Enberg <[EMAIL PROTECTED]>

If slab->inuse is corrupted, cache_alloc_refill can enter an infinite
loop as detailed by Michael Richardson in the following post:
. This adds a BUG_ON to catch
those cases.

Cc: Michael Richardson <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
 mm/slab.c |8 
 1 file changed, 8 insertions(+)

Index: 2.6/mm/slab.c
===
--- 2.6.orig/mm/slab.c  2007-02-19 15:15:17.0 +0200
+++ 2.6/mm/slab.c   2007-02-20 08:39:26.0 +0200
@@ -2987,6 +2987,14 @@
slabp = list_entry(entry, struct slab, list);
check_slabp(cachep, slabp);
check_spinlock_acquired(cachep);
+
+   /*
+* The slab was either on partial or free list so
+* there must be at least one object available for
+* allocation.
+*/
+   BUG_ON(slabp->inuse < 0 || slabp->inuse >= cachep->num);
+
while (slabp->inuse < cachep->num && batchcount--) {
STATS_INC_ALLOCED(cachep);
STATS_INC_ACTIVE(cachep);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] aio: propogate post-EIOCBQUEUED errors to completion event

[Ken Chen]

On 2/20/07, Ananiev, Leonid <[EMAIL PROTECTED]> wrote:

1) mem=1G in kernel boot param if you have more
2) unmount; mk2fs; mount
3) dd if=/dev/zero of= bs=1M count=1200
4) aiostress -s 1200m -O -o 2 -i 1 -r 16k 
5) if i++<50 goto 2).


Would you please instrument the call chain of
invalidate_complete_page2() and tell us exactly where it returns zero
value in your failure case?

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

RE: [PATCH 2/2] aio: propogate post-EIOCBQUEUED errors to completion event

[Ananiev, Leonid I]

> where it returns zero 
I've wrote in the mail http://lkml.org/lkml/2007/2/8/337
invalidate_inode_pages2_range() reports BUG:
warning at mm/truncate.c:398  occurs becouse of
invalidate_complete_page2()returns 0; it returns 0 because of
try_to_release_page()  returns 0; it returns 0 because of
ext3_releasepage() returns 0; it returns 0 because of
journal_try_to_free_buffers()  returns 0; it returns 0 because of
try_to_free_buffers()  returns 0; it returns 0 because of
drop_buffers() returns 0; it returns 0 because of
buffer_busy(bh)returns 1; it returns 0 because of
buffer_head count is 1 (bh->b_count==1) as additional printk reports.

Leonid
-Original Message-
From: Ken Chen [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 21, 2007 11:36 AM
To: Ananiev, Leonid I
Cc: Chris Mason; Zach Brown; [EMAIL PROTECTED];
linux-kernel@vger.kernel.org; Benjamin LaHaise; Suparna bhattacharya;
Andrew Morton
Subject: Re: [PATCH 2/2] aio: propogate post-EIOCBQUEUED errors to
completion event

On 2/20/07, Ananiev, Leonid <[EMAIL PROTECTED]> wrote:
> 1) mem=1G in kernel boot param if you have more
> 2) unmount; mk2fs; mount
> 3) dd if=/dev/zero of= bs=1M count=1200
> 4) aiostress -s 1200m -O -o 2 -i 1 -r 16k 
> 5) if i++<50 goto 2).

Would you please instrument the call chain of
invalidate_complete_page2() and tell us exactly where it returns zero
value in your failure case?

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

Re: [PATCH 2/3] slab: export ksize to modules

[Arjan van de Ven]

On Wed, 2007-02-21 at 10:06 +0200, Pekka J Enberg wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
> 
> This exports ksize in slab and slob allocators to modules.


what's the user of this? If none, don't export it please since every
useless export does take up space.
Please specify the use in the description of the 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: [PATCH 2/3] slab: export ksize to modules

[Pekka J Enberg]

On Wed, 21 Feb 2007, Arjan van de Ven wrote:
> Please specify the use in the description of the patch!

See [PATCH 3/3] unionfs: fix up slab abuses.

Pekka
-
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: PCI riser cards and PCI irq routing, etc

[Udo van den Heuvel]

Udo van den Heuvel wrote:
> Any ideas about how to proceed?
> What to test?

I found some info on the VIA dual PCI extender card at
http://www.itx-warehouse.co.uk/Product.aspx?ProductID=410.
The text says:

The EXT-PCI is a PCI riser card which expands a PCI slot into two PCI slots.

EXT-PCI slot 1 (lower slot) uses the system resources (Device ID, INT)
of the PCI slot of the motherboard.

EXT-PCI slot 2 (Upper slot) uses device 19 and INT_A.



So if my non-VIA riser card can use DN 19 and also INT_A things should work?
(assuming that VIA Epia EN BIOS 1.07 is enough to use this card)

So, if not (as in my situation) how can I find out what is wrong?
Or find out if the BIOS works OK with the card?
How can I verify that the correct routing for the IRQ is in place?
The DN is the only variable so INT lines are hardwired on the riser card?
Then same for the motherboard.


I.o.w.: how can I find the root cause?

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

Re: [PATCH 1/3] slab: introduce krealloc

[Arjan van de Ven]

On Wed, 2007-02-21 at 10:06 +0200, Pekka J Enberg wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
> 
> Introduce krealloc() for reallocating memory while preserving contents.


please mark this one __must_check.. not storing realloc() return values
is one of the more nasty types of bugs... but gcc can help us greatly
here ;)


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

Re: [PATCH 1/3] slab: introduce krealloc

[Pekka Enberg]

On 2/21/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:

please mark this one __must_check.. not storing realloc() return values
is one of the more nasty types of bugs... but gcc can help us greatly
here ;)


So I guess we want the same thing for the other allocator functions
(__kmalloc et al) as well?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] slab: introduce krealloc

[Arjan van de Ven]

On Wed, 2007-02-21 at 11:33 +0200, Pekka Enberg wrote:
> On 2/21/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > please mark this one __must_check.. not storing realloc() return values
> > is one of the more nasty types of bugs... but gcc can help us greatly
> > here ;)
> 
> So I guess we want the same thing for the other allocator functions
> (__kmalloc et al) as well?

kmalloc doesn't normally get forgotten. realloc() otoh is a very classic
and far more frequent mistake

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.org

-
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: [-mm patch] include/linux/ptrace.h must #include

[Roland McGrath]

Thanks for the fix.
-
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/

[S390] update default configuration

[Martin Schwidefsky]

From: Martin Schwidefsky <[EMAIL PROTECTED]>

[S390] update default configuration

Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/defconfig |   21 +++--
 1 files changed, 15 insertions(+), 6 deletions(-)

diff -urpN linux-2.6/arch/s390/defconfig linux-2.6-patched/arch/s390/defconfig
--- linux-2.6/arch/s390/defconfig   2007-02-21 10:47:06.0 +0100
+++ linux-2.6-patched/arch/s390/defconfig   2007-02-21 10:47:21.0 
+0100
@@ -1,9 +1,10 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.20-rc1
-# Fri Dec 15 16:52:28 2006
+# Linux kernel version: 2.6.21-rc1
+# Wed Feb 21 10:44:30 2007
 #
 CONFIG_MMU=y
+CONFIG_ZONE_DMA=y
 CONFIG_LOCKDEP_SUPPORT=y
 CONFIG_STACKTRACE_SUPPORT=y
 CONFIG_RWSEM_XCHGADD_ALGORITHM=y
@@ -11,6 +12,7 @@ CONFIG_RWSEM_XCHGADD_ALGORITHM=y
 # CONFIG_ARCH_HAS_ILOG2_U64 is not set
 CONFIG_GENERIC_HWEIGHT=y
 CONFIG_GENERIC_TIME=y
+CONFIG_NO_IOMEM=y
 CONFIG_S390=y
 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
 
@@ -29,6 +31,7 @@ CONFIG_LOCALVERSION_AUTO=y
 CONFIG_SWAP=y
 CONFIG_SYSVIPC=y
 # CONFIG_IPC_NS is not set
+CONFIG_SYSVIPC_SYSCTL=y
 CONFIG_POSIX_MQUEUE=y
 # CONFIG_BSD_PROCESS_ACCT is not set
 # CONFIG_TASKSTATS is not set
@@ -133,6 +136,7 @@ CONFIG_FLAT_NODE_MEM_MAP=y
 # CONFIG_SPARSEMEM_STATIC is not set
 CONFIG_SPLIT_PTLOCK_CPUS=4
 CONFIG_RESOURCES_64BIT=y
+CONFIG_ZONE_DMA_FLAG=1
 CONFIG_HOLES_IN_ZONE=y
 
 #
@@ -178,7 +182,9 @@ CONFIG_UNIX=y
 CONFIG_XFRM=y
 # CONFIG_XFRM_USER is not set
 # CONFIG_XFRM_SUB_POLICY is not set
+# CONFIG_XFRM_MIGRATE is not set
 CONFIG_NET_KEY=y
+# CONFIG_NET_KEY_MIGRATE is not set
 CONFIG_IUCV=m
 CONFIG_AFIUCV=m
 CONFIG_INET=y
@@ -195,7 +201,7 @@ CONFIG_IP_FIB_HASH=y
 # CONFIG_INET_ESP is not set
 # CONFIG_INET_IPCOMP is not set
 # CONFIG_INET_XFRM_TUNNEL is not set
-# CONFIG_INET_TUNNEL is not set
+CONFIG_INET_TUNNEL=y
 CONFIG_INET_XFRM_MODE_TRANSPORT=y
 CONFIG_INET_XFRM_MODE_TUNNEL=y
 CONFIG_INET_XFRM_MODE_BEET=y
@@ -313,6 +319,7 @@ CONFIG_STANDALONE=y
 CONFIG_PREVENT_FIRMWARE_BUILD=y
 # CONFIG_FW_LOADER is not set
 # CONFIG_DEBUG_DRIVER is not set
+# CONFIG_DEBUG_DEVRES is not set
 CONFIG_SYS_HYPERVISOR=y
 
 #
@@ -686,13 +693,13 @@ CONFIG_HEADERS_CHECK=y
 CONFIG_DEBUG_KERNEL=y
 CONFIG_LOG_BUF_SHIFT=17
 # CONFIG_SCHEDSTATS is not set
+# CONFIG_TIMER_STATS is not set
 # CONFIG_DEBUG_SLAB is not set
 CONFIG_DEBUG_PREEMPT=y
 # CONFIG_DEBUG_RT_MUTEXES is not set
 # CONFIG_RT_MUTEX_TESTER is not set
 CONFIG_DEBUG_SPINLOCK=y
 CONFIG_DEBUG_MUTEXES=y
-# CONFIG_DEBUG_RWSEMS is not set
 # CONFIG_DEBUG_LOCK_ALLOC is not set
 # CONFIG_PROVE_LOCKING is not set
 CONFIG_DEBUG_SPINLOCK_SLEEP=y
@@ -702,10 +709,10 @@ CONFIG_DEBUG_SPINLOCK_SLEEP=y
 # CONFIG_DEBUG_VM is not set
 # CONFIG_DEBUG_LIST is not set
 # CONFIG_FRAME_POINTER is not set
-# CONFIG_UNWIND_INFO is not set
 CONFIG_FORCED_INLINING=y
 # CONFIG_RCU_TORTURE_TEST is not set
 # CONFIG_LKDTM is not set
+# CONFIG_FAULT_INJECTION is not set
 
 #
 # Security options
@@ -733,8 +740,10 @@ CONFIG_CRYPTO_MANAGER=y
 # CONFIG_CRYPTO_GF128MUL is not set
 CONFIG_CRYPTO_ECB=m
 CONFIG_CRYPTO_CBC=y
+CONFIG_CRYPTO_PCBC=m
 # CONFIG_CRYPTO_LRW is not set
 # CONFIG_CRYPTO_DES is not set
+CONFIG_CRYPTO_FCRYPT=m
 # CONFIG_CRYPTO_BLOWFISH is not set
 # CONFIG_CRYPTO_TWOFISH is not set
 # CONFIG_CRYPTO_SERPENT is not set
@@ -748,6 +757,7 @@ CONFIG_CRYPTO_CBC=y
 # CONFIG_CRYPTO_DEFLATE is not set
 # CONFIG_CRYPTO_MICHAEL_MIC is not set
 # CONFIG_CRYPTO_CRC32C is not set
+CONFIG_CRYPTO_CAMELLIA=m
 # CONFIG_CRYPTO_TEST is not set
 
 #
@@ -768,4 +778,3 @@ CONFIG_BITREVERSE=m
 CONFIG_CRC32=m
 # CONFIG_LIBCRC32C is not set
 CONFIG_PLIST=y
-CONFIG_IOMAP_COPY=y
-- 
blue skies,  IBM Deutschland Entwicklung GmbH
   MartinVorsitzender des Aufsichtsrats: Johann Weihen
 Geschäftsführung: Herbert Kircher 
Martin Schwidefsky   Sitz der Gesellschaft: Böblingen
Linux on zSeries Registergericht: Amtsgericht Stuttgart,
   Development   HRB 243294
   
"Reality continues to ruin my life." - Calvin.

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

[S390] prevent softirqs if delay is called disabled

[Martin Schwidefsky]

From: Martin Schwidefsky <[EMAIL PROTECTED]>

[S390] prevent softirqs if delay is called disabled

The new delay implementation uses the clock comparator and an external
interrupt even if it is called disabled for interrupts. To do this
all external interrupt source except clock comparator are switched of
before enabling external interrupts. The external interrupt at the
end of the delay period may not execute softirqs or we can end up in a
dead-lock.

Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/lib/delay.c |7 +++
 1 files changed, 7 insertions(+)

diff -urpN linux-2.6/arch/s390/lib/delay.c 
linux-2.6-patched/arch/s390/lib/delay.c
--- linux-2.6/arch/s390/lib/delay.c 2007-02-21 10:47:06.0 +0100
+++ linux-2.6-patched/arch/s390/lib/delay.c 2007-02-21 10:47:23.0 
+0100
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 void __delay(unsigned long loops)
 {
@@ -35,7 +36,11 @@ void __udelay(unsigned long usecs)
 {
u64 end, time, jiffy_timer = 0;
unsigned long flags, cr0, mask, dummy;
+   int irq_context;
 
+   irq_context = in_interrupt();
+   if (!irq_context)
+   local_bh_disable();
local_irq_save(flags);
if (raw_irqs_disabled_flags(flags)) {
jiffy_timer = S390_lowcore.jiffy_timer;
@@ -62,6 +67,8 @@ void __udelay(unsigned long usecs)
__ctl_load(cr0, 0, 0);
S390_lowcore.jiffy_timer = jiffy_timer;
}
+   if (!irq_context)
+   _local_bh_enable();
set_clock_comparator(S390_lowcore.jiffy_timer);
local_irq_restore(flags);
 }
-- 
blue skies,  IBM Deutschland Entwicklung GmbH
   MartinVorsitzender des Aufsichtsrats: Johann Weihen
 Geschäftsführung: Herbert Kircher 
Martin Schwidefsky   Sitz der Gesellschaft: Böblingen
Linux on zSeries Registergericht: Amtsgericht Stuttgart,
   Development   HRB 243294
   
"Reality continues to ruin my life." - Calvin.

-
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 03/18] Dont leak NT bit into next task

[Giuseppe Bilotta]

On Wednesday 21 February 2007 02:49, Greg KH wrote:

>  /* frame pointer must be last for get_wchan */
> -#define SAVE_CONTEXT"pushq %%rbp ; movq %%rsi,%%rbp\n\t"
> -#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp\n\t"
> +#define SAVE_CONTEXT"pushf ; pushq %%rbp ; movq %%rsi,%%rbp\n\t"
> +#define RESTORE_CONTEXT "movq %%rbp,%%rsi ; popq %%rbp ; popf\t"

No idea if this is a problem or not, but you forgot a \n after popf.

-- 
Giuseppe "Oblomov" Bilotta

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

[S390] fix non-smp compile.

[Martin Schwidefsky]

From: Jan Glauber <[EMAIL PROTECTED]>

[S390] fix non-smp compile.

Fix compile of sclp_quiesce for CONFIG_SMP=n.

Signed-off-by: Jan Glauber <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>

---

 drivers/s390/char/sclp_quiesce.c |1 +
 1 files changed, 1 insertion(+)

diff -urpN linux-2.6/drivers/s390/char/sclp_quiesce.c 
linux-2.6-patched/drivers/s390/char/sclp_quiesce.c
--- linux-2.6/drivers/s390/char/sclp_quiesce.c  2007-02-04 19:44:54.0 
+0100
+++ linux-2.6-patched/drivers/s390/char/sclp_quiesce.c  2007-02-21 
10:47:24.0 +0100
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sclp.h"
 
-- 
blue skies,  IBM Deutschland Entwicklung GmbH
   MartinVorsitzender des Aufsichtsrats: Johann Weihen
 Geschäftsführung: Herbert Kircher 
Martin Schwidefsky   Sitz der Gesellschaft: Böblingen
Linux on zSeries Registergericht: Amtsgericht Stuttgart,
   Development   HRB 243294
   
"Reality continues to ruin my life." - Calvin.

-
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 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory

[Kawai, Hidehiro]

Hi,

Thank you for your reply.

David Howells wrote:

>>I think that locking makes codes complex and generates overhead.
>>So I wouldn't like to use lock as far as possible.  I think passing
>>the flag as an extra argument is the simplest implementation to
>>avoid the core file corruption.
> 
> Actually, I don't think the locking is that hard or that complex.
> 
>   int do_coredump(long signr, int exit_code, struct pt_regs * regs)
>   {
>   
> 
>   down_read(&coredump_settings_sem);
> 
>   ...
> 
>   fail:
>   up_read(&coredump_settings_sem);
>   return retval;
>   }
> 
> And:
> 
>   static ssize_t proc_coredump_omit_anon_shared_write(struct file *file,
>   const char __user *buf,
>   size_t count,
>   loff_t *ppos)
>   {
>   
> 
>   down_write(&coredump_settings_sem);
> 
>   ...
> 
>   out_no_task:
>   up_write(&coredump_settings_sem);
>   return ret;
>   }

Is coredump_setting_sem a global semaphore?  If so, it prevents concurrent
core dumping.  Additionally, while some process is dumped, writing to
coredump_omit_anon_shared of unrelated process will be blocked.

So we should use per process or per mm locking.  But where should we
place the variable for locking?  Because we don't want to increase the
struct size, we might want to add another bit field in mm_struct:

struct mm_struct {
...
unsigned char dumpable:2;
unsigned char coredump_in_progress:1;  /* this */
unsigned char coredump_omit_anon_shared:1;
...

And we use it to determine whether core dumping is in progress or not:

int do_coredump(long signr, int exit_code, struct pt_regs * regs)
{

 
spin_lock(&dump_bits_lock);
current->mm->coredump_in_progress = 1;
spin_unlock(&dump_bits_lock);
...

Additionally:

static ssize_t proc_coredump_omit_anon_shared_write(struct file *file,
const char __user *buf,
size_t count,
loff_t *ppos)
{


ret = -EBUSY; 
spin_lock(&dump_bits_lock);
if (mm->coredump_in_progress) {
spin_unlock(&dump_bits_lock);
goto out;
}
mm->coredump_omit_anon_shared = (val != 0);
spin_unlock(&dump_bits_lock);
...

Do you think which is better this method or passing argument method
used by my patchset?
Or, are there even better way else?

-- 
Hidehiro Kawai
Hitachi, Ltd., Systems Development Laboratory

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

[S390] smp_call_function cleanup

[Martin Schwidefsky]

From: Jan Glauber <[EMAIL PROTECTED]>

[S390] smp_call_function cleanup

Introduce __smp_call_function_map which calls a function on all cpus
given with a cpumask_t. Use it to implement smp_call_function and
smp_call_function_on. Replace smp_ext_bitcall_others with smp_ext_bitcall
and a for_each_cpu_mask loop. Use a cpumask_t instead of an atomic_t for
cpu counting and print a warning if preempt is on in
__smp_call_function_map().

Signed-off-by: Jan Glauber <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/kernel/smp.c |  181 -
 1 files changed, 77 insertions(+), 104 deletions(-)

diff -urpN linux-2.6/arch/s390/kernel/smp.c 
linux-2.6-patched/arch/s390/kernel/smp.c
--- linux-2.6/arch/s390/kernel/smp.c2007-02-21 10:47:06.0 +0100
+++ linux-2.6-patched/arch/s390/kernel/smp.c2007-02-21 10:47:26.0 
+0100
@@ -54,19 +54,18 @@ cpumask_t cpu_possible_map = CPU_MASK_NO
 static struct task_struct *current_set[NR_CPUS];
 
 static void smp_ext_bitcall(int, ec_bit_sig);
-static void smp_ext_bitcall_others(ec_bit_sig);
 
 /*
- * Structure and data for smp_call_function(). This is designed to minimise
- * static memory requirements. It also looks cleaner.
+ * Structure and data for __smp_call_function_map(). This is designed to
+ * minimise static memory requirements. It also looks cleaner.
  */
 static DEFINE_SPINLOCK(call_lock);
 
 struct call_data_struct {
void (*func) (void *info);
void *info;
-   atomic_t started;
-   atomic_t finished;
+   cpumask_t started;
+   cpumask_t finished;
int wait;
 };
 
@@ -81,118 +80,113 @@ static void do_call_function(void)
void *info = call_data->info;
int wait = call_data->wait;
 
-   atomic_inc(&call_data->started);
+   cpu_set(smp_processor_id(), call_data->started);
(*func)(info);
if (wait)
-   atomic_inc(&call_data->finished);
+   cpu_set(smp_processor_id(), call_data->finished);;
 }
 
-/*
- * this function sends a 'generic call function' IPI to all other CPUs
- * in the system.
- */
-
-int smp_call_function (void (*func) (void *info), void *info, int nonatomic,
-   int wait)
-/*
- * [SUMMARY] Run a function on all other CPUs.
- *  The function to run. This must be fast and non-blocking.
- *  An arbitrary pointer to pass to the function.
- *  currently unused.
- *  If true, wait (atomically) until function has completed on other 
CPUs.
- * [RETURNS] 0 on success, else a negative status code. Does not return until
- * remote CPUs are nearly ready to execute <> or are or have executed.
- *
- * You must not call this function with disabled interrupts or from a
- * hardware interrupt handler.
- */
+static void __smp_call_function_map(void (*func) (void *info), void *info,
+   int nonatomic, int wait, cpumask_t map)
 {
struct call_data_struct data;
-   int cpus = num_online_cpus()-1;
+   int cpu, local = 0;
 
-   if (cpus <= 0)
-   return 0;
+   /*
+* Can deadlock when interrupts are disabled or if in wrong context,
+* caller must disable preemption
+*/
+   WARN_ON(irqs_disabled() || in_irq() || preemptible());
 
-   /* Can deadlock when interrupts are disabled or if in wrong context */
-   WARN_ON(irqs_disabled() || in_irq());
+   /*
+* Check for local function call. We have to have the same call order
+* as in on_each_cpu() because of machine_restart_smp().
+*/
+   if (cpu_isset(smp_processor_id(), map)) {
+   local = 1;
+   cpu_clear(smp_processor_id(), map);
+   }
+
+   cpus_and(map, map, cpu_online_map);
+   if (cpus_empty(map))
+   goto out;
 
data.func = func;
data.info = info;
-   atomic_set(&data.started, 0);
+   data.started = CPU_MASK_NONE;
data.wait = wait;
if (wait)
-   atomic_set(&data.finished, 0);
+   data.finished = CPU_MASK_NONE;
 
spin_lock_bh(&call_lock);
call_data = &data;
-   /* Send a message to all other CPUs and wait for them to respond */
-smp_ext_bitcall_others(ec_call_function);
+
+   for_each_cpu_mask(cpu, map)
+   smp_ext_bitcall(cpu, ec_call_function);
 
/* Wait for response */
-   while (atomic_read(&data.started) != cpus)
+   while (!cpus_equal(map, data.started))
cpu_relax();
 
if (wait)
-   while (atomic_read(&data.finished) != cpus)
+   while (!cpus_equal(map, data.finished))
cpu_relax();
+
spin_unlock_bh(&call_lock);
 
-   return 0;
+out:
+   local_irq_disable();
+   if (local)
+   func(info);
+   local_irq_enable();
 }
 
 /*
- * Call a function on one CPU
- * cpu : the CPU the function should be executed on

[S390] Optional ZONE_DMA for s390.

[Martin Schwidefsky]

From: Heiko Carstens <[EMAIL PROTECTED]>

[S390] Optional ZONE_DMA for s390.

Disable ZONE_DMA on 31-bit. All memory is addressable by all
devices and we do not need any special memory pool.

Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/Kconfig   |4 ++--
 arch/s390/mm/init.c |2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff -urpN linux-2.6/arch/s390/Kconfig linux-2.6-patched/arch/s390/Kconfig
--- linux-2.6/arch/s390/Kconfig 2007-02-21 10:47:06.0 +0100
+++ linux-2.6-patched/arch/s390/Kconfig 2007-02-21 10:47:27.0 +0100
@@ -8,8 +8,8 @@ config MMU
default y
 
 config ZONE_DMA
-   bool
-   default y
+   def_bool y
+   depends on 64BIT
 
 config LOCKDEP_SUPPORT
bool
diff -urpN linux-2.6/arch/s390/mm/init.c linux-2.6-patched/arch/s390/mm/init.c
--- linux-2.6/arch/s390/mm/init.c   2007-02-21 10:47:06.0 +0100
+++ linux-2.6-patched/arch/s390/mm/init.c   2007-02-21 10:47:27.0 
+0100
@@ -141,7 +141,9 @@ void __init paging_init(void)
__raw_local_irq_ssm(ssm_mask);
 
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
+#ifdef CONFIG_ZONE_DMA
max_zone_pfns[ZONE_DMA] = PFN_DOWN(MAX_DMA_ADDRESS);
+#endif
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
free_area_init_nodes(max_zone_pfns);
 }
-- 
blue skies,  IBM Deutschland Entwicklung GmbH
   MartinVorsitzender des Aufsichtsrats: Johann Weihen
 Geschäftsführung: Herbert Kircher 
Martin Schwidefsky   Sitz der Gesellschaft: Böblingen
Linux on zSeries Registergericht: Amtsgericht Stuttgart,
   Development   HRB 243294
   
"Reality continues to ruin my life." - Calvin.

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

[S390] etr: Add barrier() to etr_sync_cpu_start().

[Martin Schwidefsky]

From: Heiko Carstens <[EMAIL PROTECTED]>

[S390] etr: Add barrier() to etr_sync_cpu_start().

Force reading of *in_sync in while loop. Loops where the content that
is checked for is changed by a different cpu always should have some
sort of barrier() semantics.
Otherwise this might lead to very subtle bugs.

Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/kernel/time.c |   10 +-
 1 files changed, 9 insertions(+), 1 deletion(-)

diff -urpN linux-2.6/arch/s390/kernel/time.c 
linux-2.6-patched/arch/s390/kernel/time.c
--- linux-2.6/arch/s390/kernel/time.c   2007-02-21 10:47:06.0 +0100
+++ linux-2.6-patched/arch/s390/kernel/time.c   2007-02-21 10:47:28.0 
+0100
@@ -747,6 +747,7 @@ static void etr_adjust_time(unsigned lon
}
 }
 
+#ifdef CONFIG_SMP
 static void etr_sync_cpu_start(void *dummy)
 {
int *in_sync = dummy;
@@ -758,8 +759,14 @@ static void etr_sync_cpu_start(void *dum
 * __udelay will stop the cpu on an enabled wait psw until the
 * TOD is running again.
 */
-   while (*in_sync == 0)
+   while (*in_sync == 0) {
__udelay(1);
+   /*
+* A different cpu changes *in_sync. Therefore use
+* barrier() to force memory access.
+*/
+   barrier();
+   }
if (*in_sync != 1)
/* Didn't work. Clear per-cpu in sync bit again. */
etr_disable_sync_clock(NULL);
@@ -773,6 +780,7 @@ static void etr_sync_cpu_start(void *dum
 static void etr_sync_cpu_end(void *dummy)
 {
 }
+#endif /* CONFIG_SMP */
 
 /*
  * Sync the TOD clock using the port refered to by aibp. This port
-- 
blue skies,  IBM Deutschland Entwicklung GmbH
   MartinVorsitzender des Aufsichtsrats: Johann Weihen
 Geschäftsführung: Herbert Kircher 
Martin Schwidefsky   Sitz der Gesellschaft: Böblingen
Linux on zSeries Registergericht: Amtsgericht Stuttgart,
   Development   HRB 243294
   
"Reality continues to ruin my life." - Calvin.

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

[S390] New header file ipl.h

[Martin Schwidefsky]

From: Michael Holzheu <[EMAIL PROTECTED]>

[S390] New header file ipl.h

Setup.h has been misused for ipl related stuff in the past. We now move
everything, which has to do with ipl and reipl to a new header file named
"ipl.h".

Signed-off-by: Michael Holzheu <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/kernel/early.c |1 
 arch/s390/kernel/ipl.c   |   24 -
 arch/s390/kernel/setup.c |1 
 arch/s390/kernel/smp.c   |1 
 drivers/s390/cio/cio.c   |1 
 include/asm-s390/ipl.h   |  113 +++
 include/asm-s390/setup.h |   74 --
 7 files changed, 119 insertions(+), 96 deletions(-)

diff -urpN linux-2.6/arch/s390/kernel/early.c 
linux-2.6-patched/arch/s390/kernel/early.c
--- linux-2.6/arch/s390/kernel/early.c  2007-02-21 10:47:30.0 +0100
+++ linux-2.6-patched/arch/s390/kernel/early.c  2007-02-21 10:47:30.0 
+0100
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff -urpN linux-2.6/arch/s390/kernel/ipl.c 
linux-2.6-patched/arch/s390/kernel/ipl.c
--- linux-2.6/arch/s390/kernel/ipl.c2007-02-21 10:47:06.0 +0100
+++ linux-2.6-patched/arch/s390/kernel/ipl.c2007-02-21 10:47:30.0 
+0100
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -94,27 +95,6 @@ static char *shutdown_action_str(enum sh
}
 }
 
-enum diag308_subcode  {
-   DIAG308_IPL   = 3,
-   DIAG308_DUMP  = 4,
-   DIAG308_SET   = 5,
-   DIAG308_STORE = 6,
-};
-
-enum diag308_ipl_type {
-   DIAG308_IPL_TYPE_FCP = 0,
-   DIAG308_IPL_TYPE_CCW = 2,
-};
-
-enum diag308_opt {
-   DIAG308_IPL_OPT_IPL  = 0x10,
-   DIAG308_IPL_OPT_DUMP = 0x20,
-};
-
-enum diag308_rc {
-   DIAG308_RC_OK = 1,
-};
-
 static int diag308_set_works = 0;
 
 static int reipl_capabilities = IPL_TYPE_UNKNOWN;
@@ -134,7 +114,7 @@ static struct ipl_parameter_block *dump_
 
 static enum shutdown_action on_panic_action = SHUTDOWN_STOP;
 
-static int diag308(unsigned long subcode, void *addr)
+int diag308(unsigned long subcode, void *addr)
 {
register unsigned long _addr asm("0") = (unsigned long) addr;
register unsigned long _rc asm("1") = 0;
diff -urpN linux-2.6/arch/s390/kernel/setup.c 
linux-2.6-patched/arch/s390/kernel/setup.c
--- linux-2.6/arch/s390/kernel/setup.c  2007-02-21 10:47:30.0 +0100
+++ linux-2.6-patched/arch/s390/kernel/setup.c  2007-02-21 10:47:30.0 
+0100
@@ -41,6 +41,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
diff -urpN linux-2.6/arch/s390/kernel/smp.c 
linux-2.6-patched/arch/s390/kernel/smp.c
--- linux-2.6/arch/s390/kernel/smp.c2007-02-21 10:47:27.0 +0100
+++ linux-2.6-patched/arch/s390/kernel/smp.c2007-02-21 10:47:31.0 
+0100
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff -urpN linux-2.6/drivers/s390/cio/cio.c 
linux-2.6-patched/drivers/s390/cio/cio.c
--- linux-2.6/drivers/s390/cio/cio.c2007-02-21 10:47:11.0 +0100
+++ linux-2.6-patched/drivers/s390/cio/cio.c2007-02-21 10:47:31.0 
+0100
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "airq.h"
 #include "cio.h"
 #include "css.h"
diff -urpN linux-2.6/include/asm-s390/ipl.h 
linux-2.6-patched/include/asm-s390/ipl.h
--- linux-2.6/include/asm-s390/ipl.h1970-01-01 01:00:00.0 +0100
+++ linux-2.6-patched/include/asm-s390/ipl.h2007-02-21 10:47:31.0 
+0100
@@ -0,0 +1,113 @@
+/*
+ * s390 (re)ipl support
+ *
+ * Copyright IBM Corp. 2007
+ */
+
+#ifndef _ASM_S390_IPL_H
+#define _ASM_S390_IPL_H
+
+#include 
+
+#define IPL_PARMBLOCK_ORIGIN   0x2000
+
+#define IPL_PARM_BLK_FCP_LEN (sizeof(struct ipl_list_hdr) + \
+ sizeof(struct ipl_block_fcp))
+
+#define IPL_PARM_BLK_CCW_LEN (sizeof(struct ipl_list_hdr) + \
+ sizeof(struct ipl_block_ccw))
+
+#define IPL_MAX_SUPPORTED_VERSION (0)
+
+#define IPL_PARMBLOCK_START((struct ipl_parameter_block *) \
+IPL_PARMBLOCK_ORIGIN)
+#define IPL_PARMBLOCK_SIZE (IPL_PARMBLOCK_START->hdr.len)
+
+struct ipl_list_hdr {
+   u32 len;
+   u8  reserved1[3];
+   u8  version;
+   u32 blk0_len;
+   u8  pbt;
+   u8  flags;
+   u16 reserved2;
+} __attribute__((packed));
+
+struct ipl_block_fcp {
+   u8  reserved1[313-1];
+   u8  opt;
+   u8  reserved2[3];
+   u16 reserved3;
+   u16 devno;
+   u8  reserved4[4];
+   u64 wwpn;
+   u64 lun;
+   u32 bootprog;
+   u8  reserved5[12];
+   u64 br_lba;
+   u32 scp_data_len;
+   u8  reserved6[260];
+   u8  scp_data[];
+} __attribute__((packed));
+
+struct ipl_block_ccw {
+   u8  load_param[8];
+   u8  reserved1[84];
+   u8  reserved2[2];
+   u16 devno;
+   u8  vm_flags;
+   u

[S390] New get_cpu_id() inline assembly

[Martin Schwidefsky]

From: Michael Holzheu <[EMAIL PROTECTED]>

[S390] New get_cpu_id() inline assembly

Replace two stidp inline assemblies with one global implementation.

Signed-off-by: Michael Holzheu <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/kernel/early.c |2 +-
 arch/s390/kernel/setup.c |2 +-
 include/asm-s390/processor.h |5 +
 3 files changed, 7 insertions(+), 2 deletions(-)

diff -urpN linux-2.6/arch/s390/kernel/early.c 
linux-2.6-patched/arch/s390/kernel/early.c
--- linux-2.6/arch/s390/kernel/early.c  2007-02-21 10:47:06.0 +0100
+++ linux-2.6-patched/arch/s390/kernel/early.c  2007-02-21 10:47:29.0 
+0100
@@ -129,7 +129,7 @@ static noinline __init void detect_machi
 {
struct cpuinfo_S390 *cpuinfo = &S390_lowcore.cpu_data;
 
-   asm volatile("stidp %0" : "=m" (S390_lowcore.cpu_data.cpu_id));
+   get_cpu_id(&S390_lowcore.cpu_data.cpu_id);
 
/* Running under z/VM ? */
if (cpuinfo->cpu_id.version == 0xff)
diff -urpN linux-2.6/arch/s390/kernel/setup.c 
linux-2.6-patched/arch/s390/kernel/setup.c
--- linux-2.6/arch/s390/kernel/setup.c  2007-02-21 10:47:06.0 +0100
+++ linux-2.6-patched/arch/s390/kernel/setup.c  2007-02-21 10:47:29.0 
+0100
@@ -106,7 +106,7 @@ void __devinit cpu_init (void)
 /*
  * Store processor id in lowcore (used e.g. in timer_interrupt)
  */
-   asm volatile("stidp %0": "=m" (S390_lowcore.cpu_data.cpu_id));
+   get_cpu_id(&S390_lowcore.cpu_data.cpu_id);
 S390_lowcore.cpu_data.cpu_addr = addr;
 
 /*
diff -urpN linux-2.6/include/asm-s390/processor.h 
linux-2.6-patched/include/asm-s390/processor.h
--- linux-2.6/include/asm-s390/processor.h  2007-02-21 10:47:14.0 
+0100
+++ linux-2.6-patched/include/asm-s390/processor.h  2007-02-21 
10:47:29.0 +0100
@@ -36,6 +36,11 @@ typedef struct
 unsigned int unused  : 16;
 } __attribute__ ((packed)) cpuid_t;
 
+static inline void get_cpu_id(cpuid_t *ptr)
+{
+   asm volatile("stidp 0(%1)" : "=m" (*ptr) : "a" (ptr));
+}
+
 struct cpuinfo_S390
 {
 cpuid_t  cpu_id;
-- 
blue skies,  IBM Deutschland Entwicklung GmbH
   MartinVorsitzender des Aufsichtsrats: Johann Weihen
 Geschäftsführung: Herbert Kircher 
Martin Schwidefsky   Sitz der Gesellschaft: Böblingen
Linux on zSeries Registergericht: Amtsgericht Stuttgart,
   Development   HRB 243294
   
"Reality continues to ruin my life." - Calvin.

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

[S390] bss section clearing.

[Martin Schwidefsky]

From: Heiko Carstens <[EMAIL PROTECTED]>

[S390] bss section clearing.

Clear only memory from __bss_start to __bss_stop when clearing the bss
section. Not until _end, which currently happens to be the same.

Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/kernel/early.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -urpN linux-2.6/arch/s390/kernel/early.c 
linux-2.6-patched/arch/s390/kernel/early.c
--- linux-2.6/arch/s390/kernel/early.c  2007-02-21 10:47:32.0 +0100
+++ linux-2.6-patched/arch/s390/kernel/early.c  2007-02-21 10:47:33.0 
+0100
@@ -110,7 +110,7 @@ static inline void create_kernel_nss(voi
  */
 static noinline __init void clear_bss_section(void)
 {
-   memset(__bss_start, 0, _end - __bss_start);
+   memset(__bss_start, 0, __bss_stop - __bss_start);
 }
 
 /*
-- 
blue skies,  IBM Deutschland Entwicklung GmbH
   MartinVorsitzender des Aufsichtsrats: Johann Weihen
 Geschäftsführung: Herbert Kircher 
Martin Schwidefsky   Sitz der Gesellschaft: Böblingen
Linux on zSeries Registergericht: Amtsgericht Stuttgart,
   Development   HRB 243294
   
"Reality continues to ruin my life." - Calvin.

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

[S390] Remove BUG() statement

[Martin Schwidefsky]

From: Michael Holzheu <[EMAIL PROTECTED]>

[S390] Remove BUG() statement

To avoid ugly warings for older gccs, we replace
BUG() with "return NULL", which is just as well.

Signed-off-by: Michael Holzheu <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/kernel/ipl.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -urpN linux-2.6/arch/s390/kernel/ipl.c 
linux-2.6-patched/arch/s390/kernel/ipl.c
--- linux-2.6/arch/s390/kernel/ipl.c2007-02-21 10:47:32.0 +0100
+++ linux-2.6-patched/arch/s390/kernel/ipl.c2007-02-21 10:47:32.0 
+0100
@@ -91,7 +91,7 @@ static char *shutdown_action_str(enum sh
case SHUTDOWN_STOP:
return SHUTDOWN_STOP_STR;
default:
-   BUG();
+   return NULL;
}
 }
 
-- 
blue skies,  IBM Deutschland Entwicklung GmbH
   MartinVorsitzender des Aufsichtsrats: Johann Weihen
 Geschäftsführung: Herbert Kircher 
Martin Schwidefsky   Sitz der Gesellschaft: Böblingen
Linux on zSeries Registergericht: Amtsgericht Stuttgart,
   Development   HRB 243294
   
"Reality continues to ruin my life." - Calvin.

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

[S390] Replace $(ARCH) macros in Makefile

[Martin Schwidefsky]

From: Michael Holzheu <[EMAIL PROTECTED]>

[S390] Replace $(ARCH) macros in Makefile

Since $(ARCH) is always "s390" we can replace it with "s390".

Signed-off-by: Michael Holzheu <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/Makefile |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff -urpN linux-2.6/arch/s390/Makefile linux-2.6-patched/arch/s390/Makefile
--- linux-2.6/arch/s390/Makefile2007-02-04 19:44:54.0 +0100
+++ linux-2.6-patched/arch/s390/Makefile2007-02-21 10:47:36.0 
+0100
@@ -82,18 +82,18 @@ AFLAGS  += $(aflags-y)
 OBJCOPYFLAGS   := -O binary
 LDFLAGS_vmlinux := -e start
 
-head-y := arch/$(ARCH)/kernel/head.o arch/$(ARCH)/kernel/init_task.o
+head-y := arch/s390/kernel/head.o arch/s390/kernel/init_task.o
 
-core-y += arch/$(ARCH)/mm/ arch/$(ARCH)/kernel/ arch/$(ARCH)/crypto/ \
-  arch/$(ARCH)/appldata/ arch/$(ARCH)/hypfs/
-libs-y += arch/$(ARCH)/lib/
+core-y += arch/s390/mm/ arch/s390/kernel/ arch/s390/crypto/ \
+  arch/s390/appldata/ arch/s390/hypfs/
+libs-y += arch/s390/lib/
 drivers-y  += drivers/s390/
-drivers-$(CONFIG_MATHEMU) += arch/$(ARCH)/math-emu/
+drivers-$(CONFIG_MATHEMU) += arch/s390/math-emu/
 
 # must be linked after kernel
 drivers-$(CONFIG_OPROFILE) += arch/s390/oprofile/
 
-boot   := arch/$(ARCH)/boot
+boot   := arch/s390/boot
 
 all: image
 
-- 
blue skies,  IBM Deutschland Entwicklung GmbH
   MartinVorsitzender des Aufsichtsrats: Johann Weihen
 Geschäftsführung: Herbert Kircher 
Martin Schwidefsky   Sitz der Gesellschaft: Böblingen
Linux on zSeries Registergericht: Amtsgericht Stuttgart,
   Development   HRB 243294
   
"Reality continues to ruin my life." - Calvin.

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

[S390] nss: Free unused memory in kernel image.

[Martin Schwidefsky]

From: Heiko Carstens <[EMAIL PROTECTED]>

[S390] nss: Free unused memory in kernel image.

With CONFIG_SHARED_KERNEL the kernel text segment that might be in a
read only memory sections starts at 1MB. Memory between 0x12000 and
0x10 is unused then. Free this, so we have appr. an extra MB
of memory available.

Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Martin Schwidefsky <[EMAIL PROTECTED]>
---

 arch/s390/kernel/head31.S   |   15 ++-
 arch/s390/kernel/head64.S   |   16 ++--
 arch/s390/kernel/ipl.c  |7 +++
 arch/s390/kernel/setup.c|7 ++-
 drivers/s390/cio/cio.c  |2 +-
 include/asm-s390/sections.h |2 +-
 6 files changed, 19 insertions(+), 30 deletions(-)

diff -urpN linux-2.6/arch/s390/kernel/head31.S 
linux-2.6-patched/arch/s390/kernel/head31.S
--- linux-2.6/arch/s390/kernel/head31.S 2007-02-21 10:47:06.0 +0100
+++ linux-2.6-patched/arch/s390/kernel/head31.S 2007-02-21 10:47:34.0 
+0100
@@ -148,20 +148,9 @@ startup_continue:
 .Lstartup_init:
.long startup_init
 
-   .globl ipl_schib
-ipl_schib:
-   .rept 13
-   .long 0
-   .endr
-
-   .globl ipl_flags
-ipl_flags:
-   .long 0
-   .globl ipl_devno
-ipl_devno:
-   .word 0
-
.org0x12000
+   .globl  _ehead
+_ehead:
 #ifdef CONFIG_SHARED_KERNEL
.org0x10
 #endif
diff -urpN linux-2.6/arch/s390/kernel/head64.S 
linux-2.6-patched/arch/s390/kernel/head64.S
--- linux-2.6/arch/s390/kernel/head64.S 2007-02-21 10:47:06.0 +0100
+++ linux-2.6-patched/arch/s390/kernel/head64.S 2007-02-21 10:47:34.0 
+0100
@@ -154,21 +154,9 @@ startup_continue:
 .Lparmaddr:
.quad   PARMAREA
 
-   .globl  ipl_schib
-ipl_schib:
-   .rept 13
-   .long 0
-   .endr
-
-   .globl  ipl_flags
-ipl_flags:
-   .long   0
-   .globl  ipl_devno
-ipl_devno:
-   .word 0
-
.org0x12000
-
+   .globl  _ehead
+_ehead:
 #ifdef CONFIG_SHARED_KERNEL
.org0x10
 #endif
diff -urpN linux-2.6/arch/s390/kernel/ipl.c 
linux-2.6-patched/arch/s390/kernel/ipl.c
--- linux-2.6/arch/s390/kernel/ipl.c2007-02-21 10:47:33.0 +0100
+++ linux-2.6-patched/arch/s390/kernel/ipl.c2007-02-21 10:47:34.0 
+0100
@@ -43,6 +43,13 @@ enum ipl_type {
 #define IPL_FCP_STR "fcp"
 #define IPL_NSS_STR "nss"
 
+/*
+ * Must be in data section since the bss section
+ * is not cleared when these are accessed.
+ */
+u16 ipl_devno __attribute__((__section__(".data"))) = 0;
+u32 ipl_flags __attribute__((__section__(".data"))) = 0;
+
 static char *ipl_type_str(enum ipl_type type)
 {
switch (type) {
diff -urpN linux-2.6/arch/s390/kernel/setup.c 
linux-2.6-patched/arch/s390/kernel/setup.c
--- linux-2.6/arch/s390/kernel/setup.c  2007-02-21 10:47:32.0 +0100
+++ linux-2.6-patched/arch/s390/kernel/setup.c  2007-02-21 10:47:34.0 
+0100
@@ -690,9 +690,14 @@ setup_memory(void)
psw_set_key(PAGE_DEFAULT_KEY);
 
free_bootmem_with_active_regions(0, max_pfn);
-   reserve_bootmem(0, PFN_PHYS(start_pfn));
 
/*
+* Reserve memory used for lowcore/command line/kernel image.
+*/
+   reserve_bootmem(0, (unsigned long)_ehead);
+   reserve_bootmem((unsigned long)_stext,
+   PFN_PHYS(start_pfn) - (unsigned long)_stext);
+   /*
 * Reserve the bootmem bitmap itself as well. We do this in two
 * steps (first step was init_bootmem()) because this catches
 * the (very unlikely) case of us accidentally initializing the
diff -urpN linux-2.6/drivers/s390/cio/cio.c 
linux-2.6-patched/drivers/s390/cio/cio.c
--- linux-2.6/drivers/s390/cio/cio.c2007-02-21 10:47:32.0 +0100
+++ linux-2.6-patched/drivers/s390/cio/cio.c2007-02-21 10:47:34.0 
+0100
@@ -1048,7 +1048,7 @@ void reipl_ccw_dev(struct ccw_dev_id *de
do_reipl_asm(*((__u32*)&schid));
 }
 
-extern struct schib ipl_schib;
+static struct schib __initdata ipl_schib;
 
 /*
  * ipl_save_parameters gets called very early. It is not allowed to access
diff -urpN linux-2.6/include/asm-s390/sections.h 
linux-2.6-patched/include/asm-s390/sections.h
--- linux-2.6/include/asm-s390/sections.h   2007-02-21 10:47:14.0 
+0100
+++ linux-2.6-patched/include/asm-s390/sections.h   2007-02-21 
10:47:34.0 +0100
@@ -3,6 +3,6 @@
 
 #include 
 
-extern char _eshared[];
+extern char _eshared[], _ehead[];
 
 #endif
-- 
blue skies,  IBM Deutschland Entwicklung GmbH
   MartinVorsitzender des Aufsichtsrats: Johann Weihen
 Geschäftsführung: Herbert Kircher 
Martin Schwidefsky   Sitz der Gesellschaft: Böblingen
Linux on zSeries Registergericht: Amtsgericht Stuttgart,
   Development   HRB 243294
   
"Reality continues to ruin my life." - Calvin.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a

Please pull git390 'for-linus' branch

[Martin Schwidefsky]

Please pull from 'for-linus' branch of

git://git390.osdl.marist.edu/pub/scm/linux-2.6.git for-linus

to receive the following updates:

 arch/s390/Kconfig|4 +-
 arch/s390/Makefile   |   12 ++--
 arch/s390/defconfig  |   21 +++--
 arch/s390/kernel/early.c |5 +-
 arch/s390/kernel/head31.S|   15 +---
 arch/s390/kernel/head64.S|   16 +---
 arch/s390/kernel/ipl.c   |   33 ++-
 arch/s390/kernel/setup.c |   10 ++-
 arch/s390/kernel/smp.c   |  182 --
 arch/s390/kernel/time.c  |   10 ++-
 arch/s390/lib/delay.c|7 ++
 arch/s390/mm/init.c  |2 +
 drivers/s390/char/sclp_quiesce.c |1 +
 drivers/s390/cio/cio.c   |3 +-
 include/asm-s390/atomic.h|2 +
 include/asm-s390/ipl.h   |  113 +++
 include/asm-s390/local.h |   59 +
 include/asm-s390/processor.h |5 +
 include/asm-s390/sections.h  |2 +-
 include/asm-s390/setup.h |   74 ---
 20 files changed, 269 insertions(+), 307 deletions(-)
 create mode 100644 include/asm-s390/ipl.h

Heiko Carstens (4):
  [S390] Optional ZONE_DMA for s390.
  [S390] etr: Add barrier() to etr_sync_cpu_start().
  [S390] bss section clearing.
  [S390] nss: Free unused memory in kernel image.

Jan Glauber (2):
  [S390] fix non-smp compile.
  [S390] smp_call_function cleanup

Martin Schwidefsky (2):
  [S390] update default configuration
  [S390] prevent softirqs if delay is called disabled

Mathieu Desnoyers (2):
  [S390] local_t cleanup : use asm-generic/local.h.
  [S390] add atomic64_xchg to s390

Michael Holzheu (4):
  [S390] New get_cpu_id() inline assembly
  [S390] New header file ipl.h
  [S390] Remove BUG() statement
  [S390] Replace $(ARCH) macros in Makefile

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index eaaac37..d9425f5 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -8,8 +8,8 @@ config MMU
default y
 
 config ZONE_DMA
-   bool
-   default y
+   def_bool y
+   depends on 64BIT
 
 config LOCKDEP_SUPPORT
bool
diff --git a/arch/s390/Makefile b/arch/s390/Makefile
index 6598e52..b1e5584 100644
--- a/arch/s390/Makefile
+++ b/arch/s390/Makefile
@@ -82,18 +82,18 @@ AFLAGS  += $(aflags-y)
 OBJCOPYFLAGS   := -O binary
 LDFLAGS_vmlinux := -e start
 
-head-y := arch/$(ARCH)/kernel/head.o arch/$(ARCH)/kernel/init_task.o
+head-y := arch/s390/kernel/head.o arch/s390/kernel/init_task.o
 
-core-y += arch/$(ARCH)/mm/ arch/$(ARCH)/kernel/ arch/$(ARCH)/crypto/ \
-  arch/$(ARCH)/appldata/ arch/$(ARCH)/hypfs/
-libs-y += arch/$(ARCH)/lib/
+core-y += arch/s390/mm/ arch/s390/kernel/ arch/s390/crypto/ \
+  arch/s390/appldata/ arch/s390/hypfs/
+libs-y += arch/s390/lib/
 drivers-y  += drivers/s390/
-drivers-$(CONFIG_MATHEMU) += arch/$(ARCH)/math-emu/
+drivers-$(CONFIG_MATHEMU) += arch/s390/math-emu/
 
 # must be linked after kernel
 drivers-$(CONFIG_OPROFILE) += arch/s390/oprofile/
 
-boot   := arch/$(ARCH)/boot
+boot   := arch/s390/boot
 
 all: image
 
diff --git a/arch/s390/defconfig b/arch/s390/defconfig
index 1406400..741d2bb 100644
--- a/arch/s390/defconfig
+++ b/arch/s390/defconfig
@@ -1,9 +1,10 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.20-rc1
-# Fri Dec 15 16:52:28 2006
+# Linux kernel version: 2.6.21-rc1
+# Wed Feb 21 10:44:30 2007
 #
 CONFIG_MMU=y
+CONFIG_ZONE_DMA=y
 CONFIG_LOCKDEP_SUPPORT=y
 CONFIG_STACKTRACE_SUPPORT=y
 CONFIG_RWSEM_XCHGADD_ALGORITHM=y
@@ -11,6 +12,7 @@ CONFIG_RWSEM_XCHGADD_ALGORITHM=y
 # CONFIG_ARCH_HAS_ILOG2_U64 is not set
 CONFIG_GENERIC_HWEIGHT=y
 CONFIG_GENERIC_TIME=y
+CONFIG_NO_IOMEM=y
 CONFIG_S390=y
 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
 
@@ -29,6 +31,7 @@ CONFIG_LOCALVERSION_AUTO=y
 CONFIG_SWAP=y
 CONFIG_SYSVIPC=y
 # CONFIG_IPC_NS is not set
+CONFIG_SYSVIPC_SYSCTL=y
 CONFIG_POSIX_MQUEUE=y
 # CONFIG_BSD_PROCESS_ACCT is not set
 # CONFIG_TASKSTATS is not set
@@ -133,6 +136,7 @@ CONFIG_FLAT_NODE_MEM_MAP=y
 # CONFIG_SPARSEMEM_STATIC is not set
 CONFIG_SPLIT_PTLOCK_CPUS=4
 CONFIG_RESOURCES_64BIT=y
+CONFIG_ZONE_DMA_FLAG=1
 CONFIG_HOLES_IN_ZONE=y
 
 #
@@ -178,7 +182,9 @@ CONFIG_UNIX=y
 CONFIG_XFRM=y
 # CONFIG_XFRM_USER is not set
 # CONFIG_XFRM_SUB_POLICY is not set
+# CONFIG_XFRM_MIGRATE is not set
 CONFIG_NET_KEY=y
+# CONFIG_NET_KEY_MIGRATE is not set
 CONFIG_IUCV=m
 CONFIG_AFIUCV=m
 CONFIG_INET=y
@@ -195,7 +201,7 @@ CONFIG_IP_FIB_HASH=y
 # CONFIG_INET_ESP is not set
 # CONFIG_INET_IPCOMP is not set
 # CONFIG_INET_XFRM_TUNNEL is not set
-# CONFIG_INET_TUNNEL is not set
+CONFIG_INET_TUNNEL=y
 CONFIG_INET_XFRM_MODE_TRANSPORT=y
 CONFIG_INET_XFRM_MODE_TUNNEL=y
 CONFIG_INET_XFRM_MODE_BEET=y
@@ -313,6 +319,7 @@ CONFIG_STAND

Re: 2.6.20-mm1: PTRACE=y, PROC_FS=n compile error

[Roland McGrath]

> This causes the following compile error with CONFIG_PTRACE=y, 
> CONFIG_PROC_FS=n:

Bah.  I moved ptrace_may_attach to fs/proc/base.c so that CONFIG_PTRACE=n
could just omit kernel/ptrace.c entirely and still get the function for
fs/proc/base.c to use (and because that uses it many more times than ptrace
does).  I'd forgotten that procfs could be disabled, since noone ever does.

What do people suggest?  It's not a very big function.


Thanks,
Roland
-
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: kernel oops 2.6.20 (ubuntu feisty) when inserting compact flash card

[Stef Epardaud]

Hello,

I got an oops when inserting my compact flash card in my laptop.
The laptop is a Dell X1, using the builtin compact flash reader, which I
understand works through PCMCIA.

My kernel is stock ubuntu latest unstable: Linux version 2.6.20-8-386
([EMAIL PROTECTED]) (gcc version 4.1.2 20070129 (prerelease) (Ubuntu
4.1.1-31ubuntu2)) #2 Tue Feb 13 05:15:43 UTC 2007

The oops:
[ 3902.16] pccard: PCMCIA card inserted into slot 0
[ 3902.16] cs: memory probe 0xdfc0-0xdfcf: excluding
0xdfc0-0xdfc0 0xdfcf-0xdfcf
[ 3902.168000] pcmcia: registering new device pcmcia0.0
[ 3902.344000] ata1: PATA max PIO0 cmd 0x100 ctl 0x10E bmdma 0x0 irq 3
[ 3902.344000] scsi1 : pata_pcmcia
[ 3902.516000] BUG: unable to handle kernel NULL pointer dereference at
virtual address 004d
[ 3902.516000]  printing eip:
[ 3902.516000] f8a2178c
[ 3902.516000] *pde = 
[ 3902.516000] Oops:  [#1]
[ 3902.516000] Modules linked in: pata_pcmcia binfmt_misc rfcomm l2cap
ppdev ipv6 nfs lockd sunrpc acpi_cpufreq cpufreq_userspace cpufreq_stats
cpufreq_powersave cpufreq_ondemand freq_table cpufreq_conservative video
sbs i2c_ec i2c_core dock button battery container ac asus_acpi backlight
aes ieee80211_crypt_ccmp sbp2 parport_pc lp parport joydev tsdev pcmcia
sg snd_intel8x0 snd_ac97_codec sr_mod cdrom ac97_bus snd_pcm_oss
snd_mixer_oss pcspkr serio_raw snd_pcm ipw2200 rtc snd_seq_dummy
snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event hci_usb
ieee80211 ieee80211_crypt bluetooth psmouse iTCO_wdt snd_seq snd_timer
snd_seq_device iTCO_vendor_support intel_agp snd soundcore yenta_socket
rsrc_nonstatic pcmcia_core snd_page_alloc agpgart shpchp pci_hotplug
evdev ext3 jbd mbcache usb_storage ide_disk ata_piix ata_generic libata
scsi_mod libusual piix ohci1394 ieee1394 generic ehci_hcd tg3 uhci_hcd
usbcore raid10 raid456 xor raid1 raid0 multipath linear md_mod thermal
processor fan dm_mod fbcon tileblit font bitblit softcursor vesafb
capability commoncap af_packet
[ 3902.516000] CPU:0
[ 3902.516000] EIP:0060:[]Not tainted VLI
[ 3902.516000] EFLAGS: 00010293   (2.6.20-8-386 #2)
[ 3902.516000] EIP is at ata_acpi_exec_tfs+0xfc/0x9e0 [libata]
[ 3902.516000] eax: 0001   ebx:    ecx: e7068444   edx: ec0e223c
[ 3902.516000] esi: e70682bc   edi: ec0e2284   ebp: 0003000c   esp: e7b47d10
[ 3902.516000] ds: 007b   es: 007b   ss: 0068
[ 3902.516000] Process scsi_eh_1 (pid: 6336, ti=e7b46000 task=e8686550 
task.ti=e7b46000)
[ 3902.516000] Stack: c012a8e9 e70682bc 0202 00200200 0286 e7b47d5c 
1d4a 0246 
[ 3902.516000]c0385420 e8686550  e7068444  e7068444 
e70682bc ecff 
[ 3902.516000]fafbfcfd e7068444     
  
[ 3902.516000] Call Trace:
[ 3902.516000]  [] flush_workqueue+0x29/0x40
[ 3902.516000]  [] ata_exec_internal+0x88/0xd0 [libata]
[ 3902.516000]  [] __delay+0x6/0x10
[ 3902.516000]  [] ata_dev_configure+0x51/0x830 [libata]
[ 3902.516000]  [] ata_dev_read_id+0xf3/0x310 [libata]
[ 3902.516000]  [] ata_do_eh+0x100d/0x1960 [libata]
[ 3902.516000]  [] autoremove_wake_function+0x0/0x50
[ 3902.516000]  [] __activate_task+0x21/0x40
[ 3902.516000]  [] ata_std_softreset+0x0/0xe0 [libata]
[ 3902.516000]  [] ata_std_prereset+0x0/0x180 [libata]
[ 3902.516000]  [] flush_cpu_workqueue+0x88/0xb0
[ 3902.516000]  [] autoremove_wake_function+0x0/0x50
[ 3902.516000]  [] ata_std_postreset+0x0/0xd0 [libata]
[ 3902.516000]  [] ata_std_softreset+0x0/0xe0 [libata]
[ 3902.516000]  [] ata_bmdma_error_handler+0x33/0x40 [libata]
[ 3902.516000]  [] ata_std_postreset+0x0/0xd0 [libata]
[ 3902.516000]  [] ata_scsi_error+0x1f1/0x580 [libata]
[ 3902.516000]  [] scsi_error_handler+0x0/0xb50 [scsi_mod]
[ 3902.516000]  [] scsi_error_handler+0xb2/0xb50 [scsi_mod]
[ 3902.516000]  [] __wake_up_common+0x39/0x60
[ 3902.516000]  [] scsi_error_handler+0x0/0xb50 [scsi_mod]
[ 3902.516000]  [] kthread+0xa8/0xe0
[ 3902.516000]  [] kthread+0x0/0xe0
[ 3902.516000]  [] kernel_thread_helper+0x7/0x10
[ 3902.516000]  ===
[ 3902.516000] Code: 00 f6 46 0e 80 0f 85 13 07 00 00 83 7e 78 05 0f 84 52 03 
00 00 8d 57 b8 c7 44 24 54 ff ff ff ff c7 44 24 58 00 00 00 00 8b 42 10 <0f> b6 
40 4c 88 44 24 3f 8b 47 64 8b 5a 20 8d 54 24 54 8b af 28 
[ 3902.516000] EIP: [] ata_acpi_exec_tfs+0xfc/0x9e0 [libata] SS:ESP 
0068:e7b47d10
[ 3902.516000]  <5>pccard: card ejected from slot 0

$ ./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 fangorn 2.6.20-8-386 #2 Tue Feb 13 05:15:43 UTC 2007 i686
 GNU/Linux
  
  Gnu C  4.1.2
  Gnu make   3.81
  binutils   2.17.50
  util-linux 2.12r
  mount  2.12r
  module-init-tools  3.3-pre2
  e2fsprogs  1.40-WIP
  jfsutils   1.1.11
  reiserfsprogs  3.6.19
  reiser4progs   1.0.5
  xfsprogs  

2.6.13.4 - "lockd: weird return 1 for CANCEL call"

[Jesper Juhl]

Greetings,

I just got a unusual message from lockd on a webserver running a
custom compiled 2.6.13.4 (yes it is ancient, I know).

# uname -a
Linux webserv.somedomain.example 2.6.13.4 #1 SMP Wed Nov 16 10:03:05
CET 2005 i686 unknown

# dmesg | tail -n 3
do_vfs_lock: VFS is out of sync with lock manager!
lockd: weird return 1 for CANCEL call
lockd: weird return 1 for CANCEL call

The server seems to be running fine, so I'm not really worried, but I
thought maybe someone would like to know. :-)


--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.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: libata FUA revisited

[Tejun Heo]

[cc'ing Ric, Hannes and Dongjun, Hello.  Feel free to drag other people in.]

Robert Hancock wrote:
> Jens Axboe wrote:
>> But we can't really change that, since you need the cache flushed before
>> issuing the FUA write. I've been advocating for an ordered bit for
>> years, so that we could just do:
>>
>> 3. w/FUA+ORDERED
>>
>> normal operation -> barrier issued -> write barrier FUA+ORDERED
>>  -> normal operation resumes
>>
>> So we don't have to serialize everything both at the block and device
>> level. I would have made FUA imply this already, but apparently it's not
>> what MS wanted FUA for, so... The current implementations take the FUA
>> bit (or WRITE FUA) as a hint to boost it to head of queue, so you are
>> almost certainly going to jump ahead of already queued writes. Which we
>> of course really do not.

Yeah, I think if we have tagged write command and flush tagged (or
barrier tagged) things can be pretty efficient.  Again, I'm much more
comfortable with separate opcodes for those rather than bits changing
the behavior.

Another idea Dongjun talked about while drinking in LSF was ranged
flush.  Not as flexible/efficient as the previous option but much less
intrusive and should help quite a bit, I think.

> I think that FUA was designed for a different use case than what Linux
> is using barriers for currently. The advantage with FUA is when you have
> "before barrier", "after barrier" and "don't care" sets, where only the
> specific things you care about ordering are in the before/after barrier
> sets. Then you can do this:
> 
> Issue all before barrier requests with FUA bit set
> Wait for all those to complete
> Issue all after barrier requests with FUA bit set
> Wait for all those to complete
> 
> Meanwhile a bunch of "don't care" requests could be going through on the
> device in the background. If we could do this, then I think there would
> be an advantage. Right now, it just saves a command to the drive when
> we're flushing on the post-barrier writes.
> 
> This would only be efficient with NCQ FUA, because regular FUA forces
> the requests to complete serially, whereas in this case we don't really
> care what order the individual requests finish, we just care about the
> ordering of the pre vs. post barrier requests.

Yeap, that makes sense too but that possibly requires intrusive changes
in fs layer and limited NCQ queue depth might become a bottleneck too.

>> I'm not too nervous about the FUA write commands, I hope we can safely
>> assume that if you set the FUA supported bit in the id AND the write fua
>> command doesn't get aborted, that FUA must work. Anything else would
>> just be an immensely stupid implementation. NCQ+FUA is more tricky, I
>> agree that it being just a command bit does make it more likely that it
>> could be ignored. And that is indeed a danger. Given state of NCQ in
>> early firmware drives, I would not at all be surprised if the drive
>> vendors screwed that up too.

Yeap, I bet someone did.  :-)

>> But, since we don't have the ordered bit for NCQ/FUA anyway, we do need
>> to drain the drive queue before issuing the WRITE/FUA. And at that point
>> we may as well not use the NCQ command, just go for the regular non-NCQ
>> FUA write. I think that should be safe.

Yeap.

> Aside from the issue above, as I mentioned elsewhere, lots of NCQ drives
> don't support non-NCQ FUA writes..

To me, using the NCQ FUA bit on such drives doesn't seem to be a good
idea.  Maybe I'm just too chicken but it's not like we can gain a lot
from doing FUA at this point.  Are there a lot of drives which support
NCQ but not FUA opcodes?

Thanks.

-- 
tejun
-
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: libata FUA revisited

[Jens Axboe]

On Wed, Feb 21 2007, Tejun Heo wrote:
> [cc'ing Ric, Hannes and Dongjun, Hello.  Feel free to drag other people in.]
> 
> Robert Hancock wrote:
> > Jens Axboe wrote:
> >> But we can't really change that, since you need the cache flushed before
> >> issuing the FUA write. I've been advocating for an ordered bit for
> >> years, so that we could just do:
> >>
> >> 3. w/FUA+ORDERED
> >>
> >> normal operation -> barrier issued -> write barrier FUA+ORDERED
> >>  -> normal operation resumes
> >>
> >> So we don't have to serialize everything both at the block and device
> >> level. I would have made FUA imply this already, but apparently it's not
> >> what MS wanted FUA for, so... The current implementations take the FUA
> >> bit (or WRITE FUA) as a hint to boost it to head of queue, so you are
> >> almost certainly going to jump ahead of already queued writes. Which we
> >> of course really do not.
> 
> Yeah, I think if we have tagged write command and flush tagged (or
> barrier tagged) things can be pretty efficient.  Again, I'm much more
> comfortable with separate opcodes for those rather than bits changing
> the behavior.

ORDERED+FUA NCQ would still be preferable to an NCQ enabled flush
command, though.

> Another idea Dongjun talked about while drinking in LSF was ranged
> flush.  Not as flexible/efficient as the previous option but much less
> intrusive and should help quite a bit, I think.

But that requires extensive tracking, I'm not so sure the implementation
of that for barriers would be very clean. It'd probably be good for
fsync, though.

-- 
Jens Axboe

-
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: libata FUA revisited

[Jens Axboe]

On Mon, Feb 19 2007, Robert Hancock wrote:
> Jens Axboe wrote:
> >But we can't really change that, since you need the cache flushed before
> >issuing the FUA write. I've been advocating for an ordered bit for
> >years, so that we could just do:
> >
> >3. w/FUA+ORDERED
> >
> >normal operation -> barrier issued -> write barrier FUA+ORDERED
> > -> normal operation resumes
> >
> >So we don't have to serialize everything both at the block and device
> >level. I would have made FUA imply this already, but apparently it's not
> >what MS wanted FUA for, so... The current implementations take the FUA
> >bit (or WRITE FUA) as a hint to boost it to head of queue, so you are
> >almost certainly going to jump ahead of already queued writes. Which we
> >of course really do not.
> 
> I think that FUA was designed for a different use case than what Linux 
> is using barriers for currently. The advantage with FUA is when you have 

[snip]

Yes that's pretty obvious, my point is just that FUA+ORDERED would be a
nice thing to have for us.

> >I'm not too nervous about the FUA write commands, I hope we can safely
> >assume that if you set the FUA supported bit in the id AND the write fua
> >command doesn't get aborted, that FUA must work. Anything else would
> >just be an immensely stupid implementation. NCQ+FUA is more tricky, I
> >agree that it being just a command bit does make it more likely that it
> >could be ignored. And that is indeed a danger. Given state of NCQ in
> >early firmware drives, I would not at all be surprised if the drive
> >vendors screwed that up too.
> >
> >But, since we don't have the ordered bit for NCQ/FUA anyway, we do need
> >to drain the drive queue before issuing the WRITE/FUA. And at that point
> >we may as well not use the NCQ command, just go for the regular non-NCQ
> >FUA write. I think that should be safe.
> 
> Aside from the issue above, as I mentioned elsewhere, lots of NCQ drives 
> don't support non-NCQ FUA writes..

"Lots" meaning how many? All the ones I have here support FUA.

-- 
Jens Axboe

-
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: libata FUA revisited

[Tejun Heo]

Jens Axboe wrote:
> On Wed, Feb 21 2007, Tejun Heo wrote:
>> [cc'ing Ric, Hannes and Dongjun, Hello.  Feel free to drag other people in.]
>>
>> Robert Hancock wrote:
>>> Jens Axboe wrote:
 But we can't really change that, since you need the cache flushed before
 issuing the FUA write. I've been advocating for an ordered bit for
 years, so that we could just do:

 3. w/FUA+ORDERED

 normal operation -> barrier issued -> write barrier FUA+ORDERED
  -> normal operation resumes

 So we don't have to serialize everything both at the block and device
 level. I would have made FUA imply this already, but apparently it's not
 what MS wanted FUA for, so... The current implementations take the FUA
 bit (or WRITE FUA) as a hint to boost it to head of queue, so you are
 almost certainly going to jump ahead of already queued writes. Which we
 of course really do not.
>> Yeah, I think if we have tagged write command and flush tagged (or
>> barrier tagged) things can be pretty efficient.  Again, I'm much more
>> comfortable with separate opcodes for those rather than bits changing
>> the behavior.
> 
> ORDERED+FUA NCQ would still be preferable to an NCQ enabled flush
> command, though.

I think we're talking about two different things here.

1. The barrier write (FUA write) combined with flush.  I think it would
help improving the performance but I think issuing two commands
shouldn't be too slower than issuing one combined command unless it
causes extra physical activity (moving head, etc...).

2. FLUSH currently flushes all writes.  If we can mark certain commands
requiring ordering, we can selectively flush or order necessary writes.
 (No need to flush 16M buffer all over the disk when only journal needs
barriering)

>> Another idea Dongjun talked about while drinking in LSF was ranged
>> flush.  Not as flexible/efficient as the previous option but much less
>> intrusive and should help quite a bit, I think.
> 
> But that requires extensive tracking, I'm not so sure the implementation
> of that for barriers would be very clean. It'd probably be good for
> fsync, though.

I was mostly thinking about journal area.  Using it for other purposes
would incur a lot of complexity.  :-(

-- 
tejun
-
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: libata FUA revisited

[Jens Axboe]

On Wed, Feb 21 2007, Tejun Heo wrote:
> Jens Axboe wrote:
> > On Wed, Feb 21 2007, Tejun Heo wrote:
> >> [cc'ing Ric, Hannes and Dongjun, Hello.  Feel free to drag other people 
> >> in.]
> >>
> >> Robert Hancock wrote:
> >>> Jens Axboe wrote:
>  But we can't really change that, since you need the cache flushed before
>  issuing the FUA write. I've been advocating for an ordered bit for
>  years, so that we could just do:
> 
>  3. w/FUA+ORDERED
> 
>  normal operation -> barrier issued -> write barrier FUA+ORDERED
>   -> normal operation resumes
> 
>  So we don't have to serialize everything both at the block and device
>  level. I would have made FUA imply this already, but apparently it's not
>  what MS wanted FUA for, so... The current implementations take the FUA
>  bit (or WRITE FUA) as a hint to boost it to head of queue, so you are
>  almost certainly going to jump ahead of already queued writes. Which we
>  of course really do not.
> >> Yeah, I think if we have tagged write command and flush tagged (or
> >> barrier tagged) things can be pretty efficient.  Again, I'm much more
> >> comfortable with separate opcodes for those rather than bits changing
> >> the behavior.
> > 
> > ORDERED+FUA NCQ would still be preferable to an NCQ enabled flush
> > command, though.
> 
> I think we're talking about two different things here.
> 
> 1. The barrier write (FUA write) combined with flush.  I think it would
> help improving the performance but I think issuing two commands
> shouldn't be too slower than issuing one combined command unless it
> causes extra physical activity (moving head, etc...).

The command overhead is dwarfed by other factors, agree.

> 2. FLUSH currently flushes all writes.  If we can mark certain commands
> requiring ordering, we can selectively flush or order necessary writes.
>  (No need to flush 16M buffer all over the disk when only journal needs
> barriering)

Sure, anything is better than the sledge hammer flush. But my claim is
that an ORDERED+FUA enabled write for critical data would be a good
approach, and simple in software.

> >> Another idea Dongjun talked about while drinking in LSF was ranged
> >> flush.  Not as flexible/efficient as the previous option but much less
> >> intrusive and should help quite a bit, I think.
> > 
> > But that requires extensive tracking, I'm not so sure the implementation
> > of that for barriers would be very clean. It'd probably be good for
> > fsync, though.
> 
> I was mostly thinking about journal area.  Using it for other purposes
> would incur a lot of complexity.  :-(

Yep if it's just for the journal, the range is known and fixed, so the
flush range would work nicely there.

-- 
Jens Axboe

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

[-mm patch] MTD_UBI_DEBUG must depend on SYSFS

[Adrian Bunk]

On Sat, Feb 17, 2007 at 09:51:46PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-mm1:
>...
>  git-ubi.patch
>...
>  git trees
>...


If you select an option, you have to ensure that the dependencies of all 
options you are select'ing are fulfilled.

This patch fixes the following compile error:

<--  snip  -->

...
  LD  .tmp_vmlinux1
fs/built-in.o: In function `debugfs_init':
inode.c:(.init.text+0x3621): undefined reference to `kernel_subsys'
make[1]: *** [.tmp_vmlinux1] Error 1

<--  snip  -->

I've also removed the superfluous "default n".

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
--- linux-2.6.20-mm2/drivers/mtd/ubi/Kconfig.debug.old  2007-02-20 
19:57:23.0 +0100
+++ linux-2.6.20-mm2/drivers/mtd/ubi/Kconfig.debug  2007-02-20 
19:57:51.0 +0100
@@ -5,7 +5,7 @@
 
 config MTD_UBI_DEBUG
bool "UBI debugging"
-   default n
+   depends on SYSFS
depends on MTD_UBI
select DEBUG_FS
select KALLSYMS_ALL

-
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 a little help with Software Raid 1

[Sander]

Marc Perkel wrote (ao):
> I have a partition that used to be part of a software
> raid 1 array. It is now loaded as /dev/sda3 but I'd
> like to mirror it to /dev/sdb3 without losing the data
> on the drive. I'm a little nervous about how to set it
> up as I don't want to wipe out the data.
> 
> How do I do this? Using FC6 and up 2 date software.

Create a degraded raid1 on /dev/sdb3, mount the degraded raid1, copy the
data over from /dev/sda3 to the degraded raid1, umount /dev/sda3 and add
it to the degraded raid1 to make it non-degraded.

With kind regards, Sander

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

[PATCH] slab: add __must_check to krealloc

[Pekka J Enberg]

From: Pekka Enberg <[EMAIL PROTECTED]>

As suggested by Arjan, make GCC warn about classic misuse of the realloc API.

Cc: Arjan van de Ven <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
 include/linux/slab.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: 2.6/include/linux/slab.h
===
--- 2.6.orig/include/linux/slab.h   2007-02-21 13:06:47.0 +0200
+++ 2.6/include/linux/slab.h2007-02-21 13:07:06.0 +0200
@@ -72,7 +72,7 @@
  */
 void *__kmalloc(size_t, gfp_t);
 void *__kzalloc(size_t, gfp_t);
-void *krealloc(const void *, size_t, gfp_t);
+void * __must_check krealloc(const void *, size_t, gfp_t);
 void kfree(const void *);
 unsigned int ksize(const void *);
 
-
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 to use more symbolic constants in asm

[Arjan van de Ven]

From: Arjan van de Ven <[EMAIL PROTECTED]>
Subject: Use symbolic constants in inline assembly

This patch replaces several of the %0/%1 uses in x86-64 inline assembly
with symbolic names (this is a new gcc 3.x feature, but that's ok now).
This tends to, imo, make the inline assembly a lot more readable, and
for sure it's less error prone in terms of finding which %
corresponds with which variable.

objdump -d of the vmlinux before and after the patch is the same; also
boot tested.

Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>


---
 include/asm-x86_64/bitops.h  |   89 +++
 include/asm-x86_64/local.h   |   24 +-
 include/asm-x86_64/mmu_context.h |2 
 include/asm-x86_64/processor.h   |   22 -
 include/asm-x86_64/semaphore.h   |   22 +
 include/asm-x86_64/signal.h  |   21 +++--
 include/asm-x86_64/spinlock.h|   36 +++
 include/asm-x86_64/system.h  |   10 ++--
 include/asm-x86_64/tlbflush.h|   10 ++--
 9 files changed, 134 insertions(+), 102 deletions(-)

Index: linux-2.6.21-rc1/include/asm-x86_64/bitops.h
===
--- linux-2.6.21-rc1.orig/include/asm-x86_64/bitops.h
+++ linux-2.6.21-rc1/include/asm-x86_64/bitops.h
@@ -10,9 +10,9 @@
 #if __GNUC__ < 4 || (__GNUC__ == 4 && __GNUC_MINOR__ < 1)
 /* Technically wrong, but this avoids compilation errors on some gcc
versions. */
-#define ADDR "=m" (*(volatile long *) addr)
+#define ADDR [addr] "=m" (*(volatile long *) addr)
 #else
-#define ADDR "+m" (*(volatile long *) addr)
+#define ADDR [addr] "+m" (*(volatile long *) addr)
 #endif
 
 /**
@@ -28,9 +28,9 @@
 static __inline__ void set_bit(int nr, volatile void * addr)
 {
__asm__ __volatile__( LOCK_PREFIX
-   "btsl %1,%0"
+   "btsl %[nr],%[addr]"
:ADDR
-   :"dIr" (nr) : "memory");
+   : [nr] "dIr" (nr) : "memory");
 }
 
 /**
@@ -45,9 +45,9 @@ static __inline__ void set_bit(int nr, v
 static __inline__ void __set_bit(int nr, volatile void * addr)
 {
__asm__ volatile(
-   "btsl %1,%0"
+   "btsl %[nr],%[addr]"
:ADDR
-   :"dIr" (nr) : "memory");
+   : [nr] "dIr" (nr) : "memory");
 }
 
 /**
@@ -63,17 +63,17 @@ static __inline__ void __set_bit(int nr,
 static __inline__ void clear_bit(int nr, volatile void * addr)
 {
__asm__ __volatile__( LOCK_PREFIX
-   "btrl %1,%0"
+   "btrl %[nr],%[addr]"
:ADDR
-   :"dIr" (nr));
+   : [nr] "dIr" (nr));
 }
 
 static __inline__ void __clear_bit(int nr, volatile void * addr)
 {
__asm__ __volatile__(
-   "btrl %1,%0"
+   "btrl %[nr],%[addr]"
:ADDR
-   :"dIr" (nr));
+   : [nr] "dIr" (nr));
 }
 
 #define smp_mb__before_clear_bit() barrier()
@@ -91,9 +91,9 @@ static __inline__ void __clear_bit(int n
 static __inline__ void __change_bit(int nr, volatile void * addr)
 {
__asm__ __volatile__(
-   "btcl %1,%0"
+   "btcl %[nr],%[addr]"
:ADDR
-   :"dIr" (nr));
+   : [nr] "dIr" (nr));
 }
 
 /**
@@ -108,9 +108,9 @@ static __inline__ void __change_bit(int 
 static __inline__ void change_bit(int nr, volatile void * addr)
 {
__asm__ __volatile__( LOCK_PREFIX
-   "btcl %1,%0"
+   "btcl %[nr],%[addr]"
:ADDR
-   :"dIr" (nr));
+   :[nr] "dIr" (nr));
 }
 
 /**
@@ -126,9 +126,12 @@ static __inline__ int test_and_set_bit(i
int oldbit;
 
__asm__ __volatile__( LOCK_PREFIX
-   "btsl %2,%1\n\tsbbl %0,%0"
-   :"=r" (oldbit),ADDR
-   :"dIr" (nr) : "memory");
+   "btsl %[nr],%[addr]\n\t"
+   "sbbl %[oldbit],%[oldbit]"
+   : [oldbit] "=r" (oldbit),
+ADDR
+   : [nr] "dIr" (nr)
+   : "memory");
return oldbit;
 }
 
@@ -146,9 +149,11 @@ static __inline__ int __test_and_set_bit
int oldbit;
 
__asm__(
-   "btsl %2,%1\n\tsbbl %0,%0"
-   :"=r" (oldbit),ADDR
-   :"dIr" (nr));
+   "btsl %[nr],%[addr]\n\t"
+   "sbbl %[oldbit],%[oldbit]"
+   : [oldbit] "=r" (oldbit),
+ ADDR
+   : [nr] "dIr" (nr));
return oldbit;
 }
 
@@ -165,9 +170,11 @@ static __inline__ int test_and_clear_bit
int oldbit;
 
__asm__ __volatile__( LOCK_PREFIX
-   "btrl %2,%1\n\tsbbl %0,%0"
-   :"=r" (oldbit),ADDR
-   :"dIr" (nr) : "memory");
+   "btrl %[nr],%[addr]\n\t"
+   "sbbl %[oldbit],%[oldbit]"
+   : [oldbit] "=r" (oldbit),
+ ADDR
+   : [nr] "dIr" (nr) : "memory");
return oldbit;
 }

2.6.20-rc1 build error on ARM with modular IPV6

[M.L. Jones]

NB: I'm not subscribed so please CC me in any reply! Thanks...

Hi there,

Just attempted a build of vanilla 2.6.20-rc1 and got a failure with our 
usual defconfig. Notably, we build IPV6 support as modular - this seems to 
be the source of the problem.


If any other info is required, please ask.

Thanks for your help,

Michael-Luke Jones
NSLU2-Linux Core Team

==Error==
 GEN .version
 CHK include/linux/compile.h
 UPD include/linux/compile.h
 CC  init/version.o
 LD  init/built-in.o
 LD  .tmp_vmlinux1
net/built-in.o: In function `svc_udp_recvfrom':
sysctl_net.c:(.text+0x79fb4): undefined reference to `__ipv6_addr_type'
make[1]: *** [.tmp_vmlinux1] Error 1

==Config==
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.21-rc1
# Wed Feb 21 02:32:29 2007
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_TIME=y
CONFIG_MMU=y
# CONFIG_NO_IOPORT is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ZONE_DMA=y
CONFIG_VECTORS_BASE=0x
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
# CONFIG_VM_EVENT_COUNTERS is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
CONFIG_DEFAULT_DEADLINE=y
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="deadline"

#
# System Type
#
# CONFIG_ARCH_AAEC2000 is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS7500 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CO285 is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IMX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IOP13XX is not set
CONFIG_ARCH_IXP4XX=y
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_L7200 is not set
# CONFIG_ARCH_NS9XXX is not set
# CONFIG_ARCH_PNX4008 is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_LH7A40X is not set
# CONFIG_ARCH_OMAP is not set
CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y

#
# Intel IXP4xx Implementation Options
#

#
# IXP4xx Platforms
#
CONFIG_MACH_NSLU2=y
CONFIG_MACH_AVILA=y
CONFIG_MACH_LOFT=y
# CONFIG_ARCH_ADI_COYOTE is not set
CONFIG_ARCH_IXDP425=y
# CONFIG_MACH_IXDPG425 is not set
# CONFIG_MACH_IXDP465 is not set
CONFIG_ARCH_IXCDP1100=y
# CONFIG_ARCH_PRPMC1100 is not set
CONFIG_MACH_NAS100D=y
CONFIG_ARCH_IXDP4XX=y
# CONFIG_MACH_GTWX5715 is not set

#
# IXP4xx Options
#
CONFIG_DMABOUNCE=y
# CONFIG_IXP4XX_INDIRECT_PCI is not set

#
# Processor Type
#
CONFIG_CPU_32=y
CONFIG_CPU_XSCALE=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5T=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_TLB_V4WBI=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
CONFIG_ARM_THUMB=y
# CONFIG_CPU_BIG_ENDIAN is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_OUTER_CACHE is not set
# CONFIG_IWMMXT is not set
CONFIG_XSCALE_PMU=y

#
# Bus support
#
CONFIG_PCI=y

#
# PCCARD (PCMCIA/CardBus) support
#
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_PREEMPT=y
# CONFIG_NO_IDLE_HZ is not set
CONFIG_HZ=100
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
# CONFIG_ARCH_DISCONTIGME

Re: 2.6.13.4 - "lockd: weird return 1 for CANCEL call"

[Neil Brown]

On Wednesday February 21, [EMAIL PROTECTED] wrote:
> Greetings,
> 
> I just got a unusual message from lockd on a webserver running a
> custom compiled 2.6.13.4 (yes it is ancient, I know).
> 
> # uname -a
> Linux webserv.somedomain.example 2.6.13.4 #1 SMP Wed Nov 16 10:03:05
> CET 2005 i686 unknown
> 
> # dmesg | tail -n 3
> do_vfs_lock: VFS is out of sync with lock manager!
> lockd: weird return 1 for CANCEL call
> lockd: weird return 1 for CANCEL call
> 
> The server seems to be running fine, so I'm not really worried, but I
> thought maybe someone would like to know. :-)

Thanks.
Don't be worried.  They are both warning about perfectly acceptable
(though uncommon) behaviour.  These warnings have since been removed.

A process was interrupted while trying to get a lock, so the NFS
client didn't know if it actually had the lock or not.
When the process exited, the tried to cancel the lock just to be on
the safe side and was told that it didn't own any such lock.

NeilBrown
-
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 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory

[David Howells]

Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:

> Is coredump_setting_sem a global semaphore?  If so, it prevents concurrent
> core dumping.

No, it doesn't.  Look again:

int do_coredump(long signr, int exit_code, struct pt_regs * regs)
{


    down_read(&coredump_settings_sem);

> Additionally, while some process is dumped, writing to
> coredump_omit_anon_shared of unrelated process will be blocked.

Yes, but that's probably reasonable.  How likely (a) is a process to coredump,
and (b) is a coredump to occur simultaneously with someone altering their
settings?

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

Re: current git crashes on bootup with pci_iounmap()

[Tejun Heo]

Kay Sievers wrote:
> On 2/13/07, Kay Sievers <[EMAIL PROTECTED]> wrote:
>> On Tue, 2007-02-13 at 17:04 +0100, Marcel Holtmann wrote:
>> > > kernel BUG at lib/iomap.c:254!
>> > > invalid opcode:  [#1]
>> > > ...
>> > >
>> > > The screen picture is here:
>> > >   http://vrfy.org/pci_iounmap.jpg
>> > >
>> > > It's a Thinkpad T43p.
>> > >
>> > > 2.6.20 was working fine.
>> > >
>> > > Commenting out:
>> > >   IO_COND(addr, /* nothing */, iounmap(addr));
>> > > in:
>> > >   lib/iomap.c:254
>> > > makes at least booting up possible.
>> >
>> > I saw a similar one on my X41. Disabling the AHCI driver made the
>> > machine booting again.
>>
>> Hey Marcel,
>> yeah, that works fine here too.
> 
> Tejun, Jeff, any ideas what's going wrong with the iomap change and
> the AHCI driver?

The following commit should have fixed the problem, at least the oops.
Care to give the current git head a shot?

commit fb4d64e78ceab77cf20f7796f74aa10ebe862032
Author: Frederik Deweerdt <[EMAIL PROTECTED]>
Date:   Fri Feb 16 01:27:15 2007 -0800

[PATCH] pci_iomap_regions() error handling fix

It appears that the pcim_iomap_regions() function doesn't get the error
handling right. It BUGs early at boot with a backtrace along the
lines of:

ahci_init
pci_register_driver
driver_register
[...]
ahci_init_one
pcim_iomap_region
pcim_iounmap

The following patch allows me to boot. Only the if(mask..) continue;
part fixes the problem actually, the gotos where changed so that we
don't try to unmap something we couldn't map anyway.

Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
Cc: Al Viro <[EMAIL PROTECTED]>
Cc: Tejun Heo <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>

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

Re: [PATCH 0/2] use symbolic constants in generic lseek code

[David Howells]

Chris Snook <[EMAIL PROTECTED]> wrote:

> Patch 1 fixes the case statements to use the symbolic constants in
> include/linux/fs.h, and should not be at all controversial.
>
> Patch 2 adds a SEEK_MAX and uses it to validate user arguments.  This makes
> the code a little cleaner and also enables future extensions (such as
> SEEK_DATA and SEEK_HOLE).  If anyone has a problem with this, please speak up.

Seems reasonable.

Acked-By: David Howells <[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: 2.6.13.4 - "lockd: weird return 1 for CANCEL call"

[Jesper Juhl]

On 21/02/07, Neil Brown <[EMAIL PROTECTED]> wrote:

On Wednesday February 21, [EMAIL PROTECTED] wrote:
> Greetings,
>
> I just got a unusual message from lockd on a webserver running a
> custom compiled 2.6.13.4 (yes it is ancient, I know).
>
> # uname -a
> Linux webserv.somedomain.example 2.6.13.4 #1 SMP Wed Nov 16 10:03:05
> CET 2005 i686 unknown
>
> # dmesg | tail -n 3
> do_vfs_lock: VFS is out of sync with lock manager!
> lockd: weird return 1 for CANCEL call
> lockd: weird return 1 for CANCEL call
>
> The server seems to be running fine, so I'm not really worried, but I
> thought maybe someone would like to know. :-)

Thanks.
Don't be worried.  They are both warning about perfectly acceptable
(though uncommon) behaviour.  These warnings have since been removed.


I know the "VFS is out of sync with lock manager" warning has been
removed (I pushed quite a bit to get that done myself ;) I was just
providing context.  The one I had not seen before was the "weird
return ..." one.


A process was interrupted while trying to get a lock, so the NFS
client didn't know if it actually had the lock or not.
When the process exited, the tried to cancel the lock just to be on
the safe side and was told that it didn't own any such lock.


Thanks a lot for that very nice explanation.

--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.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 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory

[Robin Holt]

On Wed, Feb 21, 2007 at 11:33:31AM +, David Howells wrote:
> Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
> 
> > Is coredump_setting_sem a global semaphore?  If so, it prevents concurrent
> > core dumping.
> 
> No, it doesn't.  Look again:
> 
>   int do_coredump(long signr, int exit_code, struct pt_regs * regs)
>   {
>   
> 
>   down_read(&coredump_settings_sem);
> 
> > Additionally, while some process is dumped, writing to
> > coredump_omit_anon_shared of unrelated process will be blocked.
> 
> Yes, but that's probably reasonable.  How likely (a) is a process to coredump,
> and (b) is a coredump to occur simultaneously with someone altering their
> settings?

And (c) altering the setting during a core dump going to produce an
unusable core dump.  I don't think the locking is that difficult to add
and it just makes sense.  I would venture a guess that it will take less
time to actually do the locking than to continue arguing it is not needed
when it clearly appears it is needed for even a small number of cases.

Thanks,
Robin
-
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: SATA ahci Bug in 2.6.19.x

[Tejun Heo]

Does it work if you give 'irqpoll' kernel parameter?

-- 
tejun
-
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 00/18] 2.6.18-stable review

[S.Çağlar Onur]

21 Şub 2007 Çar tarihinde, Greg KH şunları yazmıştı: 
> Responses should be made by Friday February 23 00:00 UTC.  Anything
> received after that time might be too late.

We have still some CVEish patches in our package which maybe you want to 
consider adding into -stable.

* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006

Cheers
-- 
S.Çağlar Onur <[EMAIL PROTECTED]>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!


pgpeWPz6bwE2v.pgp
Description: PGP signature

Re: patch to use more symbolic constants in asm

[Andi Kleen]

On Wednesday 21 February 2007 12:10, Arjan van de Ven wrote:
> From: Arjan van de Ven <[EMAIL PROTECTED]>
> Subject: Use symbolic constants in inline assembly
> 
> This patch replaces several of the %0/%1 uses in x86-64 inline assembly
> with symbolic names (this is a new gcc 3.x feature, but that's ok now).
> This tends to, imo, make the inline assembly a lot more readable, and
> for sure it's less error prone in terms of finding which %
> corresponds with which variable.

At least for two arguments i don't really see the value, but ok.

> objdump -d of the vmlinux before and after the patch is the same; also
> boot tested.

You should do i386 too then; one reason I didn't touch bitops 
for example was to keep the code more similar.


>  static inline void set_cr4(unsigned long cr4)
>  {
> - asm volatile("mov %0,%%cr4" :: "r" (cr4) : "memory");
> + asm volatile("mov %[cr4],%%cr4" :: [cr4] "r" (cr4) : "memory");

I'm not sure that's really an improvement for example.

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

[2.6 patch] i386 asm-offsets.c: workaround for a -Wmissing-prototypes warning

[Adrian Bunk]

This patch works around a warning with -Wmissing-prototypes in 
arch/i386/kernel/asm-offsets.c

The warning isn't gcc's fault - asm-offsets.c is simply a special file.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
--- linux-2.6.20-mm2/arch/i386/kernel/asm-offsets.c.old 2007-02-20 
23:28:45.0 +0100
+++ linux-2.6.20-mm2/arch/i386/kernel/asm-offsets.c 2007-02-20 
23:29:42.0 +0100
@@ -29,6 +29,9 @@
 #define OFFSET(sym, str, mem) \
DEFINE(sym, offsetof(struct str, mem));
 
+/* workaround for a warning with -Wmissing-prototypes */
+void foo(void);
+
 void foo(void)
 {
OFFSET(SIGCONTEXT_eax, sigcontext, eax);

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

[-mm patch] i386 mpparse.c: remove an unused variable

[Adrian Bunk]

On Sat, Feb 17, 2007 at 09:51:46PM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.20-mm1:
>...
> +i386-irq-kill-irq-compression.patch
>...
>  x86 updates
>...

This patch removes a no longer used variable.

Spotted by the GNU C compiler.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
--- linux-2.6.20-mm2/arch/i386/kernel/mpparse.c.old 2007-02-20 
23:41:11.0 +0100
+++ linux-2.6.20-mm2/arch/i386/kernel/mpparse.c 2007-02-20 23:41:25.0 
+0100
@@ -1046,7 +1046,6 @@
int ioapic = -1;
int ioapic_pin = 0;
int idx, bit = 0;
-   static int pci_irq = 16;
 
/* Don't set up the ACPI SCI because it's already set up */
if (acpi_gbl_FADT.sci_interrupt == gsi)

-
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] videobuf_qbuf: fix? possible videobuf_queue->stream corruption and lockup

[Adrian Bunk]

On Tue, Jan 23, 2007 at 09:10:08PM -0200, Mauro Carvalho Chehab wrote:
> Em Ter, 2007-01-23 às 20:57 +0300, Oleg Nesterov escreveu:
> > I am pretty sure the bug is real, but the patch may be wrong, please review.
> > 
> > We are doing ->buf_prepare(buf) before adding buf to q->stream list. This
> > means that videobuf_qbuf() should not try to re-add a STATE_PREPARED buffer.
> > 
> > Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
> Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
> 
> Chris/Adrian,
> 
> IMO, this should also be applied at -stable trees.
>...

Thanks, applied to 2.6.16 (a trivial backport was required since the 
dprintk() was added after 2.6.16).

cu
Adrian

-- 

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

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

Re: [PATCH 1/1] LinuxPPS: Pulse per Second support for Linux

[Rodolfo Giometti]

On Mon, Feb 19, 2007 at 06:56:20PM -0800, H. Peter Anvin wrote:

> It's not a precondition for a file descriptor, either.  There are plenty 
> of ioctl-only device drivers in existence.
> 
> Furthermore, a file descriptor doesn't imply a device entry.  Consider 
> pipe(2), for example.
> 
> As far as the kernel is concerned, a file handle is a nice, uniform 
> system for providing communication between the kernel and user space. 
> It doesn't matter if one can read() or write() on it; it's perfectly 
> normal to support only a subset of the normal operations.

The problem is that sometimes you cannot have a filedescriptor at
all. Think about a PPS source connected with a CPU's GPIO pin. You
have no filedes to use and defining one just for a PPS source or for a
class of PPS sources, I think, is a non sense.

RFC simply doesn't consider the fact that you can have a PPS source
__without__ a filedes connected with, and a single filedes is
considered __always__ connected with a single PPS source.

Ciao,

Rodolfo

-- 

GNU/Linux Solutions  e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded Systems[EMAIL PROTECTED]
UNIX programming phone: +39 349 2432127
-
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.20-git13 kernel BUG at /mnt/md0/devel/linux-git/kernel/time/tick-sched.c:168

[Michal Piotrowski]

Michal Piotrowski napisał(a):
> On 17/02/07, Alex Riesen <[EMAIL PROTECTED]> wrote:
>> Thomas Gleixner, Sat, Feb 17, 2007 16:14:17 +0100:
>> > On Sat, 2007-02-17 at 15:47 +0100, Alex Riesen wrote:
>> > > > > 164 if (need_resched())
>> > > > > 165 goto end;
>> > > > > 166
>> > > > > 167 cpu = smp_processor_id();
>> > > > > 168 BUG_ON(local_softirq_pending());
>> > > >
>> > > > Hmm, the BUG_ON is inside of an interrupt disabled region, so we
>> should
>> > > > have bailed out early in the need_resched() check above (because
>> we are
>> > > > in the idle task context according to the stack trace).
>> > > >
>> > > > Is this reproducible ?
>> > >
>> > > Seen this too (Ubuntu, P4/ht-SMT, SATA, typed from screen):
>> >
>> > Can you please apply the patch below, so we can at least see, which
>> > softirq is pending. This should trigger independently of hrtimers and
>> > dynticks. You can keep it compiled in and disable it at the kernel
>> > commandline with "nohz=off" and / or "highres=off"
>>
>> It did, only one time:
>>
>> Idle: local softirq pending: 0020<6>USB Universal Host Controller
>> Interface driver v3.0
>>
> 
> sudo cat /var/log/messages | grep Idle
> Feb 17 17:35:34 bitis-gabonica kernel: Idle: local softirq pending:
> 0020<6>hdd: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache,
> UDMA(33)
> Feb 17 19:20:01 bitis-gabonica kernel: Idle: local softirq pending:
> 0020<3>Idle: local softirq pending: 0020<3>Idle: local softirq
> pending: 0020<7>PM: Removing info for No Bus:vcs7
> 
> cat /proc/interrupts
>   CPU0   CPU1
>  0: 232838  0   IO-APIC-edge  timer
>  1:401  0   IO-APIC-edge  i8042
>  7:  0  0   IO-APIC-edge  parport0
>  8:  1  0   IO-APIC-edge  rtc
>  9:  1  0   IO-APIC-fasteoi   acpi
>  12:  4  0   IO-APIC-edge  i8042
>  14:319  0   IO-APIC-edge  ide0
>  15:   1612  0   IO-APIC-edge  ide1
>  16:  16494  0   IO-APIC-fasteoi   uhci_hcd:usb3, libata
>  17:   4670  0   IO-APIC-fasteoi   uhci_hcd:usb1, uhci_hcd:usb4
>  18:  0  0   IO-APIC-fasteoi   uhci_hcd:usb2
>  19:  2  0   IO-APIC-fasteoi   ehci_hcd:usb5
>  20:   2822  0   IO-APIC-fasteoi   Intel ICH5
>  21:   2881  0   IO-APIC-fasteoi   eth1
>  22: 58  0   IO-APIC-fasteoi   eth0
> NMI:  0  0
> LOC: 232562 232846
> ERR:  0
> MIS:  0
> 
> I can confirm that this is ICH5 SATA controller problem.

Here is something interesting

cat /var/log/messages | tail -n 300 | grep NOHZ
Feb 20 20:09:39 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 20 20:09:39 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 20 21:10:01 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 20 23:20:01 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 21 05:10:28 bitis-gabonica kernel: NOHZ: local_softirq_pending 02
Feb 21 05:10:46 bitis-gabonica kernel: NOHZ: local_softirq_pending 02
^

Feb 21 05:10:57 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 21 05:11:48 bitis-gabonica kernel: NOHZ: local_softirq_pending 02
Feb 21 05:12:02 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 21 05:12:02 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 21 05:12:23 bitis-gabonica kernel: NOHZ: local_softirq_pending 02
Feb 21 05:12:29 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 21 05:13:27 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 21 05:13:49 bitis-gabonica kernel: NOHZ: local_softirq_pending 02
Feb 21 05:13:54 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 21 05:14:48 bitis-gabonica kernel: NOHZ: local_softirq_pending 02
Feb 21 05:15:11 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 21 05:15:13 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 21 05:15:16 bitis-gabonica kernel: NOHZ: local_softirq_pending 02
Feb 21 05:16:18 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 21 05:16:31 bitis-gabonica kernel: NOHZ: local_softirq_pending 02
Feb 21 05:17:03 bitis-gabonica kernel: NOHZ: local_softirq_pending 02
Feb 21 05:17:06 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 21 05:17:09 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 21 05:17:12 bitis-gabonica kernel: NOHZ: local_softirq_pending 02
Feb 21 05:17:17 bitis-gabonica kernel: NOHZ: local_softirq_pending 20
Feb 21 05:17:18 bitis-gabonica kernel: NOHZ: local_softirq_pending 02
   
23 times in 7 minutes.


Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
To unsubscribe from this list: send the line "unsubscribe l

[PATCH] unionfs: fix memory leak when calling krealloc

[Pekka J Enberg]

From: Pekka Enberg <[EMAIL PROTECTED]>

We must not overwrite the same pointer that is passed to krealloc() 
because it can return NULL without freeing the buffer.  Fixes a memory 
leak introduced by me.

Cc: Josef Sipek <[EMAIL PROTECTED]>
Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]>
---
 fs/unionfs/copyup.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

Index: 2.6/fs/unionfs/copyup.c
===
--- 2.6.orig/fs/unionfs/copyup.c2007-02-21 14:15:30.0 +0200
+++ 2.6/fs/unionfs/copyup.c 2007-02-21 14:16:19.0 +0200
@@ -658,11 +658,14 @@
 
/* grow path table */
if (count == num_dentry) {
-   path = krealloc(path, kmalloc_size * 2, GFP_KERNEL);
-   if (!path) {
+   void *p;
+
+   p = krealloc(path, kmalloc_size * 2, GFP_KERNEL);
+   if (!p) {
hidden_dentry = ERR_PTR(-ENOMEM);
goto out;
}
+   path = p;
kmalloc_size = ksize(path);
num_dentry = kmalloc_size / sizeof(struct dentry *);
}
-
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: PCI riser cards and PCI irq routing, etc

[Krzysztof Halasa]

Udo van den Heuvel <[EMAIL PROTECTED]> writes:

> So if my non-VIA riser card can use DN 19 and also INT_A things should work?

That INT_A may be INT_A from their (motherboard) point of view, but
the riser card doesn't know about that, it only knows INTs as seen
at its PCI edge connector (so this INT_A here is meaningless).

Device numbers aren't rotated but rather derived from address lines
(address/data). AD0-31 lines are the same across the whole PCI bus.
That means device numbers are independent of POV.

> (assuming that VIA Epia EN BIOS 1.07 is enough to use this card)

My VIA EPIA-M 600 is probably older than your one, so I'd assume
it should work as well.
When you configure 0x13 and 0x14, both devices get IRQs - that means
the BIOS can see both of them.

> The DN is the only variable so INT lines are hardwired on the riser card?

Yep. You just need a bit of soldering.
-- 
Krzysztof Halasa
-
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: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

[Jörn Engel]

On Wed, 21 February 2007 05:36:22 +0100, Juan Piernas Canovas wrote:
> >
> >I don't see how you can guarantee 50% free segments.  Can you explain
> >that bit?
> It is quite simple. If 50% of your segments are busy, and the other 50% 
> are free, and the file system needs a new segment, the cleaner starts 
> freeing some of busy ones. If the cleaner is unable to free one segment at 
> least, your file system gets "full" (and it returns a nice ENOSPC error). 
> This solution wastes the half of your storage device, but it is 
> deadlock-free. Obviously, there are better approaches.

Ah, ok.  It is deadlock free, if the maximal height of your tree is 2.
It is not 100% deadlock free if the height is 3 or more.

Also, I strongly suspect that your tree is higher than 2.  A medium
sized directory will have data blocks, indirect blocks and the inode
proper, which gives you a height of 3.  Your inodes need to get accessed
somehow and unless they have fixed positions like in ext2, you need a
further tree structure of some sorts, so you're more likely looking at a
height of 5.

With a height of 5, you would need to keep 80% of you metadata free.
That is starting to get wasteful.

So I suspect that my proposed alternate cleaner mechanism or the even
better "hole plugging" mechanism proposed in the paper a few posts above
would be a better path to follow.

> >A fine principle to work with.  Surprisingly, what is the worst case for
> >you is the common case for LogFS, so maybe I'm more interested in it
> >than most people.  Or maybe I'm just more paranoid.
> 
> No, you are right. It is the common case for LogFS because it has data and 
> meta-data blocks in the same address space, but that is not the case of 
> DualFS. Anyway, I'm very interested in your work because any solution to 
> the problem of the GC will be also applicable to DualFS. So, keep up with 
> it. ;-)

Actually, no.  It is the common case for LogFS because it is designed
for flash media.  Unlike hard disks, flash lifetime is limited by the
amount of data written to it.  Therefore, having a cleaner run when the
filesystem is idle would cause unnecessary writes and reduce lifetime.

As a result, the LogFS cleaner runs as lazily as possible and the
filesystem tries hard not to mix data with different lifetimes in one
segment.  LogFS tries to avoid the cleaner like the plague.  But if it
ever needs to run it, the deadlock scenario is very close and I need to
be very aware of it. :)

In a way, the DualFS approach does not change rules for the
log-structured filesystem at all.  If you had designed your filesystem
in such a way that you simply used two existent filesystems and wrote
Actual Data (AD) to one, Metadata (MD) to another, what is MD to DualFS
is plain data to one of your underlying filesystems.  It can cause a bit
of confusion, because I tend to call MD "data" and you tend to call AD
"data", but that is about all.

Jörn

-- 
But this is not to say that the main benefit of Linux and other GPL
software is lower-cost. Control is the main benefit--cost is secondary.
-- Bruce Perens
-
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 x86_64-fix-2.6.18-regression-ptrace_oldsetoptions-should-be-accepted.patch queued to -stable tree

[Blaisorblade]

On Wednesday 21 February 2007 00:41, [EMAIL PROTECTED] wrote:
> This is a note to let you know that we have just queued up the patch titled
>
>  Subject: x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should
> be accepted
>
> to the 2.6.18-stable tree.  Its filename is

Since you are still maintaining 2.6.18, I've just sent another patch for that, 
i.e. the backport of commit 14679eb3c50897889ba62f9a37e3bcd8a205b5e7.
Could you still merge it in this release, especially since this is the last 
2.6.18-stable you are doing?
Also, this patch should also be merged in 2.6.20, but I saw no mail about 
this, so I wanted to make sure it's heading there too.

> x86_64-fix-2.6.18-regression-ptrace_oldsetoptions-should-be-accepted.patch
>
> A git repo of this tree can be found at
>
> http://www.kernel.org/git/?p=linux/kernel/git/gregkh/stable-queue.git;a=sum
>mary

Hmm, this should be (note the missing gregkh in the path):
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
-- 
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.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: GPL vs non-GPL device drivers

[Helge Hafting]

Jan-Benedict Glaw wrote:

On Tue, 2007-02-20 15:36:56 +0100, Helge Hafting <[EMAIL PROTECTED]> wrote:
  

If you have a need for "secret" source code, stuff most of it
in userspace.  Make the drivers truly minimal; perhaps their
open/closed status won't matter that much when the bulk
of the code and the cleverness is kept safe in userspace.

Note that keeping drivers small this way is the recommended
way of working anyway. It isn't merely a way to keep your
code away from the GPL - you always want a small kernel.



Keeping the legal stuff out of sight for a second, this'll solve the
"problem" for the embedded developer, but surely not for the Linux
community. Would you ever expect that eg. the thin GPL layer used by
ATI/NVidia would be merged iff the rest would run in userland?
  

A thin layer - no.  To get merged, a driver would have to
be of good quality.  I didn't think like that - I was thinking of
embedded developers that sometimes implement the
entire embedded application inside their device driver.

Which is crazy from a linux design standpoint, but sometimes
reasonable for an embedded developer when the sole purpose of
the embedded computer is to control the single "device" and
perhaps a little display with a couple of buttons.
The "app" part might not be that much
bigger than the device driver itself - it is then tempting to
cut some corners and put all in one place.

Of course this kind of "driver" ends up containing everything,
and nobody wants to GPL that.  Separating driver and app(s)
properly lets them keep a proprietary app, and a driver or two
that might be small and simple enough to be released.

It's just a workaround for the
linking-the-object-file-into-the-kernel-image problem, but after all,
it doesn't lead to a working driver being freely available.

MfG, JBG


Good point.  Fortunately, most devices are much simpler than
a card with accelerated 3D-graphichs.

Helge Hafting




-
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] EXPORT_SYMBOL() time functions

[Rolf Eike Beer]

These functions were inlines before 8b9365d753d9870bb6451504c13570b81923228f.
Now EXPORT_SYMBOL() them to allow them to be used in modules again.

Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>

---
commit 0a543599f4a9ea02b587bda26e0e11ae94774f61
tree aa815eab413d2575925b0964a1fa01d41439b26b
parent 6b8afc66b9d6893d3fa292b75769b58539836ff3
author Rolf Eike Beer <[EMAIL PROTECTED]> Wed, 21 Feb 2007 14:10:12 +0100
committer Rolf Eike Beer <[EMAIL PROTECTED]> Wed, 21 Feb 2007 14:10:12 +0100

 kernel/time.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/kernel/time.c b/kernel/time.c
index c6c80ea..0b351b2 100644
--- a/kernel/time.c
+++ b/kernel/time.c
@@ -635,6 +635,7 @@ timeval_to_jiffies(const struct timeval *value)
(((u64)usec * USEC_CONVERSION + USEC_ROUND) >>
 (USEC_JIFFIE_SC - SEC_JIFFIE_SC))) >> SEC_JIFFIE_SC;
 }
+EXPORT_SYMBOL(timeval_to_jiffies);
 
 void jiffies_to_timeval(const unsigned long jiffies, struct timeval *value)
 {
@@ -649,6 +650,7 @@ void jiffies_to_timeval(const unsigned long jiffies, struct 
timeval *value)
tv_usec /= NSEC_PER_USEC;
value->tv_usec = tv_usec;
 }
+EXPORT_SYMBOL(jiffies_to_timeval);
 
 /*
  * Convert jiffies/jiffies_64 to clock_t and back.
@@ -723,6 +725,7 @@ u64 nsec_to_clock_t(u64 x)
 #endif
return x;
 }
+EXPORT_SYMBOL(nsec_to_clock_t);
 
 #if (BITS_PER_LONG < 64)
 u64 get_jiffies_64(void)


pgptlQoaEVqET.pgp
Description: PGP signature

[PATCH] EXPORT_SYMBOL() time functions

[Rolf Eike Beer]

These functions were inlines before 8b9365d753d9870bb6451504c13570b81923228f.
Now EXPORT_SYMBOL() them to allow them to be used in modules again.

Signed-off-by: Rolf Eike Beer <[EMAIL PROTECTED]>

---

Sent once again, this time without PGP signature so importing into git is 
easier.

commit 0a543599f4a9ea02b587bda26e0e11ae94774f61
tree aa815eab413d2575925b0964a1fa01d41439b26b
parent 6b8afc66b9d6893d3fa292b75769b58539836ff3
author Rolf Eike Beer <[EMAIL PROTECTED]> Wed, 21 Feb 2007 14:10:12 +0100
committer Rolf Eike Beer <[EMAIL PROTECTED]> Wed, 21 Feb 2007 14:10:12 +0100

 kernel/time.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/kernel/time.c b/kernel/time.c
index c6c80ea..0b351b2 100644
--- a/kernel/time.c
+++ b/kernel/time.c
@@ -635,6 +635,7 @@ timeval_to_jiffies(const struct timeval *value)
(((u64)usec * USEC_CONVERSION + USEC_ROUND) >>
 (USEC_JIFFIE_SC - SEC_JIFFIE_SC))) >> SEC_JIFFIE_SC;
 }
+EXPORT_SYMBOL(timeval_to_jiffies);
 
 void jiffies_to_timeval(const unsigned long jiffies, struct timeval *value)
 {
@@ -649,6 +650,7 @@ void jiffies_to_timeval(const unsigned long jiffies, struct 
timeval *value)
tv_usec /= NSEC_PER_USEC;
value->tv_usec = tv_usec;
 }
+EXPORT_SYMBOL(jiffies_to_timeval);
 
 /*
  * Convert jiffies/jiffies_64 to clock_t and back.
@@ -723,6 +725,7 @@ u64 nsec_to_clock_t(u64 x)
 #endif
return x;
 }
+EXPORT_SYMBOL(nsec_to_clock_t);
 
 #if (BITS_PER_LONG < 64)
 u64 get_jiffies_64(void)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 2.6.21-rc1

[Faik Uygur]

Hi,

21 Şub 2007 Çar 06:53 tarihinde, Linus Torvalds şunları yazmıştı: 
> Ok, the merge window for 2.6.21 has closed, and -rc1 is out there.

  CHK include/linux/version.h
  CHK include/linux/utsrelease.h
  CHK include/linux/compile.h
  CC [M]  drivers/char/ip2/ip2main.o
In file included from drivers/char/ip2/ip2main.c:285:
drivers/char/ip2/i2lib.c: In function `iiSendPendingMail_t':
drivers/char/ip2/i2lib.c:83: sorry, unimplemented: inlining failed in call 
to 'iiSendPendingMail': function body not available
drivers/char/ip2/i2lib.c:157: sorry, unimplemented: called from here
make[3]: *** [drivers/char/ip2/ip2main.o] Error 1
make[2]: *** [drivers/char/ip2] Error 2
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2

With cleanup changes in commit 40565f1962c5be9b9e285e05af01ab7771534868 
compilation fails.

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

Re: Linux 2.6.21-rc1

[Thomas Gleixner]

On Tue, 2007-02-20 at 20:53 -0800, Linus Torvalds wrote:
> But there's a ton of architecture updates (arm, mips, powerpc, x86, you 
> name it), ACPI updates, and lots of driver work. And just a lot of 
> cleanups.
> 
> Have fun,

Yup. Fun starts in drivers/net/e1000

e1000 is not working anymore. ifup fails permanentely.
 ADDRCONF(NETDEV_UP): eth0: link is not ready
nothing else

bisect identifies:

d2ed16356ff4fb9de23fbc5e5d582ce580390106 is first bad commit
commit d2ed16356ff4fb9de23fbc5e5d582ce580390106
Author: Kok, Auke <[EMAIL PROTECTED]>
Date:   Fri Feb 16 14:39:26 2007 -0800

e1000: fix shared interrupt warning message

Signed-off-by: Jesse Brandeburg <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>

Reverting this patch on top of -rc1 helps as well.

tglx


lspci output:

04:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet 
Controller
Subsystem: Intel Corporation Unknown device 30a5
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] EXPORT_SYMBOL() time functions

[Arjan van de Ven]

On Wed, 2007-02-21 at 14:12 +0100, Rolf Eike Beer wrote:
> These functions were inlines before 8b9365d753d9870bb6451504c13570b81923228f.
> Now EXPORT_SYMBOL() them to allow them to be used in modules again.


please do not add random exports without users; exports eat up kernel
size and memory. At minimum specify which mainline modules use the
exports..


-
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] allow oom_adj of saintly processes

[Joshua N Pritikin]

If the badness of a process is zero then oom_adj>0 has no effect. This 
patch makes sure that the oom_adj shift actually increases badness 
points appropriately.

I am not subscribed. Please CC me with any comments. Thanks.

Signed-off-by: Joshua N. Pritikin <[EMAIL PROTECTED]>

--- linux/mm/oom_kill.c.orig2007-02-18 14:58:35.0 +0530
+++ linux/mm/oom_kill.c 2007-02-18 14:57:52.0 +0530
@@ -147,9 +147,11 @@ unsigned long badness(struct task_struct
 * Adjust the score by oomkilladj.
 */
if (p->oomkilladj) {
-   if (p->oomkilladj > 0)
+   if (p->oomkilladj > 0) {
+   if (!points)
+   points = 1;
points <<= p->oomkilladj;
-   else
+   } else
points >>= -(p->oomkilladj);
}
 
-
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 00/21] 2.6.19-stable review

[Stefan Richter]

Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.19.5 release.
> 
> This will probably be the last release of the 2.6.19-stable series, so
> if there are patches that you feel should be applied to that tree,
> please let me know.

There is one here: "Missing critical phys_to_virt in lib/swiotlb.c".
http://lkml.org/lkml/2007/2/4/116
It fixes a DMA related bug which was seen with a variety of drivers
especially on EM64T machines with more than 3GB RAM. I hope you can
extract the patch from this MIME attachment.

Adrian, AFAICS it applies as-is to 2.6.16.y too. I don't have a machine
to test personally, but it is quite obvious.

The mentioned bigger patch has been merged by Linus between 2.6.20 and
2.6.21-rc1.
-- 
Stefan Richter
-=-=-=== --=- =-=-=
http://arcgraph.de/sr/
-
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 00/21] 2.6.19-stable review

[Stefan Richter]

I wrote:
> I hope you can extract the patch from this MIME attachment.

Probably not unless I attach it for real.
-- 
Stefan Richter
-=-=-=== --=- =-=-=
http://arcgraph.de/sr/
Subject: [PATCH] Missing critical phys_to_virt in lib/swiotlb.c
From: David Moore <[EMAIL PROTECTED]>
Date: Sun, 04 Feb 2007 13:39:40 -0500

From: David Moore <[EMAIL PROTECTED]>

Adds missing call to phys_to_virt() in the
lib/swiotlb.c:swiotlb_sync_sg() function.  Without this change, a kernel
panic will always occur whenever a SWIOTLB bounce buffer from a
scatter-gather list gets synced.

Signed-off-by: David Moore <[EMAIL PROTECTED]>
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---

This is a fraction of patch "[IA64] swiotlb bug fixes" in 2.6.20-git#,
commit cde14bbfb3aa79b479db35bd29e6c083513d8614. Unlike its heading
suggests, it is also important for EM64T.

Example crashes caused by swiotlb_sync_sg:
http://lists.opensuse.org/opensuse-bugs/2006-12/msg02943.html
http://qa.mandriva.com/show_bug.cgi?id=28224
http://www.pchdtv.com/forum/viewtopic.php?t=2063&sid=a959a14a4c2db0eebaab7b0df56103ce

--- linux-2.6.19.x86_64/lib/swiotlb.c.orig  2007-02-04 13:18:41.0 
-0500
+++ linux-2.6.19.x86_64/lib/swiotlb.c   2007-02-04 13:19:43.0 -0500
@@ -750,7 +750,7 @@ swiotlb_sync_sg(struct device *hwdev, st
 
for (i = 0; i < nelems; i++, sg++)
if (sg->dma_address != SG_ENT_PHYS_ADDRESS(sg))
-   sync_single(hwdev, (void *) sg->dma_address,
+   sync_single(hwdev, phys_to_virt(sg->dma_address),
sg->dma_length, dir, target);
 }
 

[RFC] [PATCH 0/2] s390: SCSI dump kernel and userspace application

[Michael Holzheu]

s390 machines (z900 or higher) provide hardware support for creating Linux
dumps on SCSI disks. Our current implementation consists of a userspace
application running on an special Linux dump kernel, which exploits the
s390 hardware support. Since both parts (kernel and userspace) belong
together, we would like to put the application code in the Linux source tree
under "arch/s390". Currently we have a dependency on the libc of the
target system. Klibc would be a nice solution for that. Are there currently
any plans for upstream klibc?

* Patch 2 implements the kernel support (zcore character device)
* Patch 3 implements the userspace part, which resides in arch/s390

For more information please refer to Documentation/s390/zfcpdump.txt,
which is contained in patch 2.
-
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/

[RFC] [PATCH 1/2] s390: SCSI dump kernel and userspace application

[Michael Holzheu]

Kernel part of the s390 SCSI dumper: zcore character device driver.

Acked-by: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Michael Holzheu <[EMAIL PROTECTED]>

---
 Documentation/s390/zfcpdump.txt |   41 +
 arch/s390/Kconfig   |7 
 arch/s390/kernel/early.c|3 
 arch/s390/kernel/head64.S   |   43 +
 arch/s390/kernel/ipl.c  |   24 -
 arch/s390/kernel/setup.c|3 
 arch/s390/kernel/smp.c  |1 
 drivers/s390/char/Makefile  |2 
 drivers/s390/char/sclp.h|2 
 drivers/s390/char/sclp_sdias.c  |  248 +++
 drivers/s390/char/zcore.c   |  885 
 drivers/s390/cio/cio.c  |1 
 include/asm-s390/ipl.h  |  116 +
 include/asm-s390/processor.h|5 
 include/asm-s390/sclp.h |2 
 include/asm-s390/setup.h|   75 ---
 16 files changed, 1360 insertions(+), 98 deletions(-)

Index: git-linux-2.6/Documentation/s390/zfcpdump.txt
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ git-linux-2.6/Documentation/s390/zfcpdump.txt   2007-02-21 
11:00:15.0 +0100
@@ -0,0 +1,41 @@
+s390 SCSI dump tool (zfcpdump)
+
+System z machines (z900 or higher) provide hardware support for creating system
+dumps on SCSI disks. The dump process is initiated by booting a dump tool, 
which
+has to create a dump of the current (probably crashed) Linux image. In order to
+not overwrite memory of the crashed Linux with data of the dump tool, the
+hardware saves some memory plus the register sets of the boot cpu before the
+dump tool is loaded. There exists an SCLP hardware interface to obtain the 
saved
+memory afterwards. Currently 32 MB are saved.
+
+This zfcpdump implementation consists of a small Linux dump kernel together 
with
+a userspace dump tool, which are loaded together into the saved memory region
+below 32 MB. zfcpdump is installed on a SCSI disk using zipl (as contained in 
the
+s390-tools package) to make the device bootable. The operator of a Linux system
+can then trigger a scsi dump by booting the SCSI disk, where zfcpdump resides 
on.
+
+The kernel part of zfcpdump is implemented as a character device driver named
+"zcore", which exports memory and registers of the crashed Linux in an s390
+standalone dump format. It can be used in the same way as e.g. /dev/mem. The
+dump format defines a 4K header followed by plain uncompressed memory. The
+register sets are stored in the prefix pages of the different cpus. To build an
+dump enabled kernel with the zcore driver, the kernel config option
+"S390_ZFCPDUMP" has to be set. When reading from /dev/zcore, the first part of
+memory, which has been saved by the hardware is read by the driver via the SCLP
+hardware interface. The second part is just copied from the non overwritten 
real
+memory.
+
+The userspace application of zfcpdump resides in an intitramfs. It reads from
+/dev/zcore and writes the system dump to a file on a SCSI disk.
+
+To build zfcpdump you have to do the following:
+- Use /arch/s390/zfcpdump/defconfig.zfcpdump as kernel configuration file, 
which
+  enables the S390_ZFCPDUMP option and sets all other required kernel options.
+- Issue "make zfcpdump" from the toplevel directory of the linux tree to
+  build the userspace application. Note, that the zfcpdump application has a
+  dependency on glibc and libz.
+- Issue "make image" to build the zfcpdump image with initramfs.
+
+The zfcpdump enabled kernel image must be copied to
+/usr/share/zfcpdump/zfcpdump.image, where the zipl tool is looking for the dump
+kernel, when preparing a SCSI dump disk.
Index: git-linux-2.6/arch/s390/Kconfig
===
--- git-linux-2.6.orig/arch/s390/Kconfig2007-02-21 10:22:03.0 
+0100
+++ git-linux-2.6/arch/s390/Kconfig 2007-02-21 11:00:15.0 +0100
@@ -512,6 +512,13 @@ config KEXEC
  current kernel, and to start another kernel.  It is like a reboot
  but is independent of hardware/microcode support.
 
+config S390_ZFCPDUMP
+   bool "zfcp dump kernel"
+   default n
+   help
+ Select this option if you want to build an zfcp dump enabled kernel.
+ Do NOT select this option for normal kernels!
+
 endmenu
 
 source "net/Kconfig"
Index: git-linux-2.6/arch/s390/kernel/early.c
===
--- git-linux-2.6.orig/arch/s390/kernel/early.c 2007-02-21 10:22:04.0 
+0100
+++ git-linux-2.6/arch/s390/kernel/early.c  2007-02-21 10:56:03.0 
+0100
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -129,7 +130,7 @@ static noinline __init void detect_machi
 {
struct cpuinfo_S390 *cpuinfo = &S390_lowcore.cpu_data;
 
-   asm volatile("stidp %0" : "=m" (S390_lowcore.cpu_data.cpu_id));
+   get_cp

[RFC] [PATCH 2/2] s390: SCSI dump kernel and userspace application

[Michael Holzheu]

Userspace part of the s390 SCSI dumper.

Acked-by: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Michael Holzheu <[EMAIL PROTECTED]>

---
 arch/s390/Makefile|4 
 arch/s390/zfcpdump/Makefile   |5 
 arch/s390/zfcpdump/defconfig.zfcpdump |  467 
 arch/s390/zfcpdump/initramfs.txt  |6 
 arch/s390/zfcpdump/zfcpdump.c |  953 ++
 arch/s390/zfcpdump/zfcpdump.h |  214 +++
 6 files changed, 1649 insertions(+)

Index: git-linux-2.6/arch/s390/Makefile
===
--- git-linux-2.6.orig/arch/s390/Makefile   2007-02-21 13:09:01.0 
+0100
+++ git-linux-2.6/arch/s390/Makefile2007-02-21 13:09:06.0 +0100
@@ -94,6 +94,7 @@ drivers-$(CONFIG_MATHEMU) += arch/$(ARCH
 drivers-$(CONFIG_OPROFILE) += arch/s390/oprofile/
 
 boot   := arch/$(ARCH)/boot
+zfcpdump   := arch/s390/zfcpdump
 
 all: image
 
@@ -103,6 +104,9 @@ install: vmlinux
 image: vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
 
+zfcpdump:
+   $(Q)$(MAKE) $(build)=$(zfcpdump) $(zfcpdump)/$@
+
 archclean:
$(Q)$(MAKE) $(clean)=$(boot)
 
Index: git-linux-2.6/arch/s390/zfcpdump/Makefile
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ git-linux-2.6/arch/s390/zfcpdump/Makefile   2007-02-21 13:09:06.0 
+0100
@@ -0,0 +1,5 @@
+targets := zfcpdump
+
+$(obj)/zfcpdump: arch/s390/zfcpdump/zfcpdump.c arch/s390/zfcpdump/zfcpdump.h
+   $(CC) -Wall -o $(obj)/zfcpdump $(obj)/zfcpdump.c -static
+
Index: git-linux-2.6/arch/s390/zfcpdump/defconfig.zfcpdump
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ git-linux-2.6/arch/s390/zfcpdump/defconfig.zfcpdump 2007-02-21 
13:09:06.0 +0100
@@ -0,0 +1,467 @@
+#
+# Automatically generated make config: don't edit
+# Linux kernel version: 2.6.20
+# Tue Feb 20 12:54:03 2007
+#
+CONFIG_MMU=y
+CONFIG_LOCKDEP_SUPPORT=y
+CONFIG_STACKTRACE_SUPPORT=y
+CONFIG_RWSEM_XCHGADD_ALGORITHM=y
+# CONFIG_ARCH_HAS_ILOG2_U32 is not set
+# CONFIG_ARCH_HAS_ILOG2_U64 is not set
+CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_TIME=y
+CONFIG_S390=y
+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
+
+#
+# Code maturity level options
+#
+# CONFIG_EXPERIMENTAL is not set
+CONFIG_LOCK_KERNEL=y
+CONFIG_INIT_ENV_ARG_LIMIT=32
+
+#
+# General setup
+#
+CONFIG_LOCALVERSION=""
+CONFIG_LOCALVERSION_AUTO=y
+CONFIG_SWAP=y
+# CONFIG_SYSVIPC is not set
+# CONFIG_BSD_PROCESS_ACCT is not set
+# CONFIG_TASKSTATS is not set
+# CONFIG_UTS_NS is not set
+# CONFIG_AUDIT is not set
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+# CONFIG_CPUSETS is not set
+# CONFIG_SYSFS_DEPRECATED is not set
+# CONFIG_RELAY is not set
+CONFIG_INITRAMFS_SOURCE="arch/s390/zfcpdump/initramfs.txt"
+CONFIG_INITRAMFS_ROOT_UID=0
+CONFIG_INITRAMFS_ROOT_GID=0
+CONFIG_SYSCTL=y
+# CONFIG_EMBEDDED is not set
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_KALLSYMS=y
+# CONFIG_KALLSYMS_ALL is not set
+# CONFIG_KALLSYMS_EXTRA_PASS is not set
+CONFIG_HOTPLUG=y
+CONFIG_PRINTK=y
+CONFIG_BUG=y
+CONFIG_ELF_CORE=y
+CONFIG_BASE_FULL=y
+CONFIG_FUTEX=y
+CONFIG_EPOLL=y
+CONFIG_SHMEM=y
+CONFIG_SLAB=y
+CONFIG_VM_EVENT_COUNTERS=y
+CONFIG_RT_MUTEXES=y
+# CONFIG_TINY_SHMEM is not set
+CONFIG_BASE_SMALL=0
+# CONFIG_SLOB is not set
+
+#
+# Loadable module support
+#
+# CONFIG_MODULES is not set
+
+#
+# Block layer
+#
+CONFIG_BLOCK=y
+# CONFIG_BLK_DEV_IO_TRACE is not set
+
+#
+# IO Schedulers
+#
+CONFIG_IOSCHED_NOOP=y
+CONFIG_IOSCHED_AS=y
+CONFIG_IOSCHED_DEADLINE=y
+CONFIG_IOSCHED_CFQ=y
+# CONFIG_DEFAULT_AS is not set
+CONFIG_DEFAULT_DEADLINE=y
+# CONFIG_DEFAULT_CFQ is not set
+# CONFIG_DEFAULT_NOOP is not set
+CONFIG_DEFAULT_IOSCHED="deadline"
+
+#
+# Base setup
+#
+
+#
+# Processor type and features
+#
+CONFIG_64BIT=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=32
+# CONFIG_HOTPLUG_CPU is not set
+CONFIG_DEFAULT_MIGRATION_COST=100
+# CONFIG_COMPAT is not set
+CONFIG_AUDIT_ARCH=y
+CONFIG_S390_SWITCH_AMODE=y
+CONFIG_S390_EXEC_PROTECT=y
+
+#
+# Code generation options
+#
+# CONFIG_MARCH_G5 is not set
+CONFIG_MARCH_Z900=y
+# CONFIG_MARCH_Z990 is not set
+# CONFIG_MARCH_Z9_109 is not set
+CONFIG_PACK_STACK=y
+# CONFIG_SMALL_STACK is not set
+CONFIG_CHECK_STACK=y
+CONFIG_STACK_GUARD=256
+# CONFIG_WARN_STACK is not set
+CONFIG_ARCH_POPULATES_NODE_MAP=y
+CONFIG_FLATMEM=y
+CONFIG_FLAT_NODE_MEM_MAP=y
+# CONFIG_SPARSEMEM_STATIC is not set
+CONFIG_SPLIT_PTLOCK_CPUS=4
+CONFIG_RESOURCES_64BIT=y
+CONFIG_HOLES_IN_ZONE=y
+
+#
+# I/O subsystem configuration
+#
+CONFIG_MACHCHK_WARNING=y
+CONFIG_QDIO=y
+# CONFIG_QDIO_DEBUG is not set
+
+#
+# Misc
+#
+CONFIG_PREEMPT=y
+CONFIG_IPL=y
+# CONFIG_IPL_TAPE is not set
+CONFIG_IPL_VM=y
+CONFIG_BINFMT_ELF=y
+# CONFIG_BINFMT_MISC is not set
+# CONFIG_PROCESS_DEBUG is not set
+CONFIG_PFAULT=y
+# CONFIG_SHARED_KERNEL is not set
+# CONFIG_CMM is no

2.6.20-git and 2.6.21-rc1, failed to boot on sata_via

[Jean-Luc Coulon (f5ibh)]

Hi,

I've an ASUS A8V motherboard with a via chipset:

[EMAIL PROTECTED] % lspci
00:00.0 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:00.1 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:00.2 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:00.3 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:00.4 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:00.7 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge  
[K8T800/K8T890 South]


2 SATA drives are on this chipset, using lvm over a raid1.

I've a X86-64 architecture on an amd64.

Since 2.6.20-git, the system refuses to boot, I've  
the same problem with 2.6.21-rc1.


I've opened a bug, see: http://bugzilla.kernel.org/show_bug.cgi?id=8025
but I'm not sure it was the appropriate way.

At boot time, I've the following messages:

ACPI: PCI Interrupt :00:0f.0[B] GSI 20(level, low) -> IRQ 20
sata_via :00:0f.0: failed on iomap PCI BAR 0
sata_via :00:0f.0: out of memory
ACPI: PCI interrupt for device :00:0f.0 is disabled
sata_via: probe of :00:0f.0 failed with error -12

Then the raid is not assembled and the system wont boot.

These are the options (parts of] enabled in my config file:

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=m
CONFIG_BLK_DEV_IDE=m

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=m
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=m
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
...
#
# IDE chipset support/bugfixes
#
# CONFIG_IDE_GENERIC is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_IDEPCI_SHARE_IRQ is not set
# CONFIG_BLK_DEV_OFFBOARD is not set
# CONFIG_BLK_DEV_GENERIC is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_IDEDMA_FORCED is not set
CONFIG_IDEDMA_PCI_AUTO=y
# CONFIG_IDEDMA_ONLYDISK is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
CONFIG_BLK_DEV_VIA82CXXX=m
# CONFIG_BLK_DEV_TC86C001 is not set
# CONFIG_IDE_ARM is not set
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_IVB=y
CONFIG_IDEDMA_AUTO=y



#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
CONFIG_ATA=m
# CONFIG_ATA_NONSTANDARD is not set
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_SVW is not set
# CONFIG_ATA_PIIX is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
CONFIG_SATA_PROMISE=m
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
CONFIG_SATA_VIA=m
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
CONFIG_SATA_ACPI=y
...


I've found a quite similar problem in the archive but which seems to  
have been fixed in the meantime, in this thread:

http://www.ussg.iu.edu/hypermail/linux/kernel/0702.1/1580.html

[I'm not subscribed to the list]


Regards

Jean-Luc


pgpdu2oscxZQl.pgp
Description: PGP signature

[PATCH 2/4] NOMMU: Add support for direct mapping through mtdconcat if possible

[David Howells]

From: David Howells <[EMAIL PROTECTED]>

Add support for direct mapping through mtdconcat, if possible, by attaching the
samebacking_dev_info structure to the master.

It has some restrictions:

 (1) It won't permit direct mapping of concatenated devices that have differing
 BDIs.

 (2) It doesn't support maps that span the 'gap' between devices, although it
 possibly could if the devices spanned across return compatible
 (ie. contiguous) addresses from their get_unmapped_area() ops.

Signed-off-by: Gavin Lambert <[EMAIL PROTECTED]>
Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---

 drivers/mtd/mtdconcat.c |   47 +++
 1 files changed, 47 insertions(+), 0 deletions(-)

diff --git a/drivers/mtd/mtdconcat.c b/drivers/mtd/mtdconcat.c
index 880580c..730689b 100644
--- a/drivers/mtd/mtdconcat.c
+++ b/drivers/mtd/mtdconcat.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -686,6 +687,40 @@ static int concat_block_markbad(struct mtd_info *mtd, 
loff_t ofs)
 }
 
 /*
+ * try to support NOMMU mmaps on concatenated devices
+ * - we don't support subdev spanning as we can't guarantee it'll work
+ */
+static unsigned long concat_get_unmapped_area(struct mtd_info *mtd,
+ unsigned long len,
+ unsigned long offset,
+ unsigned long flags)
+{
+   struct mtd_concat *concat = CONCAT(mtd);
+   int i;
+
+   for (i = 0; i < concat->num_subdev; i++) {
+   struct mtd_info *subdev = concat->subdev[i];
+
+   if (offset >= subdev->size) {
+   offset -= subdev->size;
+   continue;
+   }
+
+   /* we've found the subdev over which the mapping will reside */
+   if (offset + len > subdev->size)
+   return (unsigned long) -EINVAL;
+
+   if (subdev->get_unmapped_area)
+   return subdev->get_unmapped_area(subdev, len, offset,
+flags);
+
+   break;
+   }
+
+   return (unsigned long) -ENOSYS;
+}
+
+/*
  * This function constructs a virtual MTD device by concatenating
  * num_devs MTD devices. A pointer to the new device object is
  * stored to *new_dev upon success. This function does _not_
@@ -740,6 +775,8 @@ struct mtd_info *mtd_concat_create(struct mtd_info 
*subdev[],   /* subdevices to c
 
concat->mtd.ecc_stats.badblocks = subdev[0]->ecc_stats.badblocks;
 
+   concat->mtd.backing_dev_info = subdev[0]->backing_dev_info;
+
concat->subdev[0] = subdev[0];
 
for (i = 1; i < num_devs; i++) {
@@ -766,6 +803,15 @@ struct mtd_info *mtd_concat_create(struct mtd_info 
*subdev[],  /* subdevices to c
concat->mtd.flags |=
subdev[i]->flags & MTD_WRITEABLE;
}
+
+   /* only permit direct mapping if the BDIs are all the same
+* - copy-mapping is still permitted
+*/
+   if (concat->mtd.backing_dev_info !=
+   subdev[i]->backing_dev_info)
+   concat->mtd.backing_dev_info =
+   &default_backing_dev_info;
+
concat->mtd.size += subdev[i]->size;
concat->mtd.ecc_stats.badblocks +=
subdev[i]->ecc_stats.badblocks;
@@ -796,6 +842,7 @@ struct mtd_info *mtd_concat_create(struct mtd_info 
*subdev[],   /* subdevices to c
concat->mtd.unlock = concat_unlock;
concat->mtd.suspend = concat_suspend;
concat->mtd.resume = concat_resume;
+   concat->mtd.get_unmapped_area = concat_get_unmapped_area;
 
/*
 * Combine the erase block size info of the subdevices:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] NOMMU: Present backing device capabilities for MTD chardevs

[David Howells]

From: David Howells <[EMAIL PROTECTED]>

Present backing device capabilities for MTD character device files to allow
NOMMU mmap to do direct mapping where possible.

Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---

 drivers/mtd/Makefile |2 +
 drivers/mtd/chips/map_ram.c  |   17 +++
 drivers/mtd/chips/map_rom.c  |   17 +++
 drivers/mtd/devices/mtdram.c |   14 +
 drivers/mtd/internal.h   |   17 +++
 drivers/mtd/mtdbdi.c |   43 +
 drivers/mtd/mtdchar.c|   63 +-
 drivers/mtd/mtdcore.c|   15 ++
 drivers/mtd/mtdpart.c|   15 ++
 include/linux/mtd/mtd.h  |   14 +
 10 files changed, 215 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index c130e62..a75b82a 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -4,7 +4,7 @@
 # $Id: Makefile.common,v 1.7 2005/07/11 10:39:27 gleixner Exp $
 
 # Core functionality.
-mtd-y  := mtdcore.o
+mtd-y  := mtdcore.o mtdbdi.o
 mtd-$(CONFIG_MTD_PARTITIONS)   += mtdpart.o
 obj-$(CONFIG_MTD)  += $(mtd-y)
 
diff --git a/drivers/mtd/chips/map_ram.c b/drivers/mtd/chips/map_ram.c
index 5cb6d52..611b035 100644
--- a/drivers/mtd/chips/map_ram.c
+++ b/drivers/mtd/chips/map_ram.c
@@ -22,6 +22,8 @@ static int mapram_write (struct mtd_info *, loff_t, size_t, 
size_t *, const u_ch
 static int mapram_erase (struct mtd_info *, struct erase_info *);
 static void mapram_nop (struct mtd_info *);
 static struct mtd_info *map_ram_probe(struct map_info *map);
+static unsigned long mapram_unmapped_area(struct mtd_info *, unsigned long,
+ unsigned long, unsigned long);
 
 
 static struct mtd_chip_driver mapram_chipdrv = {
@@ -65,6 +67,7 @@ static struct mtd_info *map_ram_probe(struct map_info *map)
mtd->type = MTD_RAM;
mtd->size = map->size;
mtd->erase = mapram_erase;
+   mtd->get_unmapped_area = mapram_unmapped_area;
mtd->read = mapram_read;
mtd->write = mapram_write;
mtd->sync = mapram_nop;
@@ -80,6 +83,20 @@ static struct mtd_info *map_ram_probe(struct map_info *map)
 }
 
 
+/*
+ * Allow NOMMU mmap() to directly map the device (if not NULL)
+ * - return the address to which the offset maps
+ * - return -ENOSYS to indicate refusal to do the mapping
+ */
+static unsigned long mapram_unmapped_area(struct mtd_info *mtd,
+ unsigned long len,
+ unsigned long offset,
+ unsigned long flags)
+{
+   struct map_info *map = mtd->priv;
+   return (unsigned long) map->virt + offset;
+}
+
 static int mapram_read (struct mtd_info *mtd, loff_t from, size_t len, size_t 
*retlen, u_char *buf)
 {
struct map_info *map = mtd->priv;
diff --git a/drivers/mtd/chips/map_rom.c b/drivers/mtd/chips/map_rom.c
index cb27f85..359f61e 100644
--- a/drivers/mtd/chips/map_rom.c
+++ b/drivers/mtd/chips/map_rom.c
@@ -20,6 +20,8 @@ static int maprom_read (struct mtd_info *, loff_t, size_t, 
size_t *, u_char *);
 static int maprom_write (struct mtd_info *, loff_t, size_t, size_t *, const 
u_char *);
 static void maprom_nop (struct mtd_info *);
 static struct mtd_info *map_rom_probe(struct map_info *map);
+static unsigned long maprom_unmapped_area(struct mtd_info *, unsigned long,
+ unsigned long, unsigned long);
 
 static struct mtd_chip_driver maprom_chipdrv = {
.probe  = map_rom_probe,
@@ -40,6 +42,7 @@ static struct mtd_info *map_rom_probe(struct map_info *map)
mtd->name = map->name;
mtd->type = MTD_ROM;
mtd->size = map->size;
+   mtd->get_unmapped_area = maprom_unmapped_area;
mtd->read = maprom_read;
mtd->write = maprom_write;
mtd->sync = maprom_nop;
@@ -52,6 +55,20 @@ static struct mtd_info *map_rom_probe(struct map_info *map)
 }
 
 
+/*
+ * Allow NOMMU mmap() to directly map the device (if not NULL)
+ * - return the address to which the offset maps
+ * - return -ENOSYS to indicate refusal to do the mapping
+ */
+static unsigned long maprom_unmapped_area(struct mtd_info *mtd,
+ unsigned long len,
+ unsigned long offset,
+ unsigned long flags)
+{
+   struct map_info *map = mtd->priv;
+   return (unsigned long) map->virt + offset;
+}
+
 static int maprom_read (struct mtd_info *mtd, loff_t from, size_t len, size_t 
*retlen, u_char *buf)
 {
struct map_info *map = mtd->priv;
diff --git a/drivers/mtd/devices/mtdram.c b/drivers/mtd/devices/mtdram.c
index e427c82..438cdb9 100644
--- a/drivers/mtd/devices/mtdram.c
+++ b/drivers/mtd/devices/mtdram.c
@@ -62,6 +62,19 @@ static void ram_unpoint(struct mtd_in

[PATCH 4/4] NOMMU: Make it possible for RomFS to use MTD devices directly

[David Howells]

From: David Howells <[EMAIL PROTECTED]>

Change RomFS so that it can use MTD devices directly - without the intercession
of the block layer - as well as using block devices.

This permits RomFS:

 (1) to use the MTD direct mapping facility available under NOMMU conditions if
 the underlying device is directly accessible by the CPU;

 (2) and thus to be used when the block layer is disabled.

RomFS can be configured with support just for MTD devices, just for Block
devices or for both.  If RomFS is configured for both, then it will treat
mtdblock device files as MTD backing stores, not block layer backing stores.

Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---

 fs/Kconfig|   24 ++
 fs/romfs/Makefile |9 +
 fs/romfs/inode.c  |  649 -
 fs/romfs/internal.h   |   47 
 fs/romfs/mmap-nommu.c |   75 ++
 fs/romfs/storage.c|  261 
 fs/romfs/super.c  |  647 +
 7 files changed, 1060 insertions(+), 652 deletions(-)

diff --git a/fs/Kconfig b/fs/Kconfig
index 3c4886b..adaec7b 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -478,6 +478,8 @@ config MINIX_FS
  partition (the one containing the directory /) cannot be compiled as
  a module.
 
+endif
+
 config ROMFS_FS
tristate "ROM file system support"
---help---
@@ -494,7 +496,27 @@ config ROMFS_FS
  If you don't know whether you need it, then you don't need it:
  answer N.
 
-endif
+config ROMFS_ON_BLOCK
+   bool "Block device-backed ROM file system support"
+   depends on ROMFS_FS && BLOCK
+   help
+ This permits ROMFS to use block devices buffered through the page
+ cache as the medium from which to retrieve data.  It does not allow
+ direct mapping of the medium.
+
+ If unsure, answer Y.
+
+config ROMFS_ON_MTD
+   bool "MTD-backed ROM file system support"
+   depends on ROMFS_FS && MTD
+   help
+ This permits ROMFS to use MTD based devices directly, without the
+ intercession of the block layer (which may have been disabled).  It
+ also allows direct mapping of MTD devices through romfs files under
+ NOMMU conditions if the underlying device is directly addressable by
+ the CPU.
+
+ If unsure, answer Y.
 
 config INOTIFY
bool "Inotify file change notification support"
diff --git a/fs/romfs/Makefile b/fs/romfs/Makefile
index c95b21c..420beb7 100644
--- a/fs/romfs/Makefile
+++ b/fs/romfs/Makefile
@@ -1,7 +1,12 @@
 #
-# Makefile for the linux romfs filesystem routines.
+# Makefile for the linux RomFS filesystem routines.
 #
 
 obj-$(CONFIG_ROMFS_FS) += romfs.o
 
-romfs-objs := inode.o
+romfs-y := storage.o super.o
+
+ifneq ($(CONFIG_MMU),y)
+romfs-$(CONFIG_ROMFS_ON_MTD) += mmap-nommu.o
+endif
+
diff --git a/fs/romfs/inode.c b/fs/romfs/inode.c
deleted file mode 100644
index fd60101..000
--- a/fs/romfs/inode.c
+++ /dev/null
@@ -1,649 +0,0 @@
-/*
- * ROMFS file system, Linux implementation
- *
- * Copyright (C) 1997-1999  Janos Farkas <[EMAIL PROTECTED]>
- *
- * Using parts of the minix filesystem
- * Copyright (C) 1991, 1992  Linus Torvalds
- *
- * and parts of the affs filesystem additionally
- * Copyright (C) 1993  Ray Burr
- * Copyright (C) 1996  Hans-Joachim Widmaier
- *
- * 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.
- *
- * Changes
- * Changed for 2.1.19 modules
- * Jan 1997Initial release
- * Jun 19972.1.43+ changes
- * Proper page locking in readpage
- * Changed to work with 2.1.45+ fs
- * Jul 1997Fixed follow_link
- * 2.1.47
- * lookup shouldn't return -ENOENT
- * from Horst von Brand:
- *   fail on wrong checksum
- *   double unlock_super was possible
- *   correct namelen for statfs
- * spotted by Bill Hawes:
- *   readlink shouldn't iput()
- * Jun 19982.1.106 from Avery Pennarun: glibc scandir()
- *   exposed a problem in readdir
- * 2.1.107 code-freeze spellchecker run
- * Aug 19982.1.118+ VFS changes
- * Sep 19982.1.122 another VFS change (follow_link)
- * Apr 19992.2.7   no more EBADF checking in
- *

[PATCH 3/4] NOMMU: Generalise the handling of MTD-specific superblocks

[David Howells]

From: David Howells <[EMAIL PROTECTED]>

Generalise the handling of MTD-specific superblocks so that JFFS2 and ROMFS can
both share it.

Signed-Off-By: David Howells <[EMAIL PROTECTED]>
---

 drivers/mtd/Makefile  |2 
 drivers/mtd/mtdsuper.c|  231 +
 fs/jffs2/super.c  |  194 --
 include/linux/fs.h|1 
 include/linux/mtd/super.h |   30 ++
 5 files changed, 282 insertions(+), 176 deletions(-)

diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index a75b82a..f9f0ffd 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -4,7 +4,7 @@
 # $Id: Makefile.common,v 1.7 2005/07/11 10:39:27 gleixner Exp $
 
 # Core functionality.
-mtd-y  := mtdcore.o mtdbdi.o
+mtd-y  := mtdcore.o mtdbdi.o mtdsuper.o
 mtd-$(CONFIG_MTD_PARTITIONS)   += mtdpart.o
 obj-$(CONFIG_MTD)  += $(mtd-y)
 
diff --git a/drivers/mtd/mtdsuper.c b/drivers/mtd/mtdsuper.c
new file mode 100644
index 000..7ffab96
--- /dev/null
+++ b/drivers/mtd/mtdsuper.c
@@ -0,0 +1,231 @@
+/* MTD-based superblock management
+ *
+ * Copyright (C) 2006 Red Hat, Inc. All Rights Reserved.
+ * Written by David Howells ([EMAIL PROTECTED])
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+
+/*
+ * compare superblocks to see if they're equivalent
+ * - they are if the underlying MTD device is the same
+ */
+static int get_sb_mtd_compare(struct super_block *sb, void *_mtd)
+{
+   struct mtd_info *mtd = _mtd;
+
+   if (sb->s_mtd == mtd) {
+   DEBUG(2, "MTDSB: Match on device %d (\"%s\")\n",
+ mtd->index, mtd->name);
+   return 1;
+   }
+
+   DEBUG(2, "MTDSB: No match, device %d (\"%s\"), device %d (\"%s\")\n",
+ sb->s_mtd->index, sb->s_mtd->name, mtd->index, mtd->name);
+   return 0;
+}
+
+/*
+ * mark the superblock by the MTD device it is using
+ * - set the device number to be the correct MTD block device for pesuperstence
+ *   of NFS exports
+ */
+static int get_sb_mtd_set(struct super_block *sb, void *_mtd)
+{
+   struct mtd_info *mtd = _mtd;
+
+   sb->s_mtd = mtd;
+   sb->s_dev = MKDEV(MTD_BLOCK_MAJOR, mtd->index);
+   return 0;
+}
+
+/*
+ * get a superblock on an MTD-backed filesystem
+ */
+static int get_sb_mtd_aux(struct file_system_type *fs_type, int flags,
+ const char *dev_name, void *data,
+ struct mtd_info *mtd,
+ int (*fill_super)(struct super_block *, void *, int),
+ struct vfsmount *mnt)
+{
+   struct super_block *sb;
+   int ret;
+
+   sb = sget(fs_type, get_sb_mtd_compare, get_sb_mtd_set, mtd);
+   if (IS_ERR(sb))
+   goto out_error;
+
+   if (sb->s_root)
+   goto already_mounted;
+
+   /* fresh new superblock */
+   DEBUG(1, "MTDSB: New superblock for device %d (\"%s\")\n",
+ mtd->index, mtd->name);
+
+   ret = fill_super(sb, data, flags & MS_SILENT ? 1 : 0);
+   if (ret < 0) {
+   up_write(&sb->s_umount);
+   deactivate_super(sb);
+   return ret;
+   }
+
+   /* go */
+   sb->s_flags |= MS_ACTIVE;
+   return simple_set_mnt(mnt, sb);
+
+   /* new mountpoint for an already mounted superblock */
+already_mounted:
+   DEBUG(1, "MTDSB: Device %d (\"%s\") is already mounted\n",
+ mtd->index, mtd->name);
+   ret = simple_set_mnt(mnt, sb);
+   goto out_put;
+
+out_error:
+   ret = PTR_ERR(sb);
+out_put:
+   put_mtd_device(mtd);
+   return ret;
+}
+
+/*
+ * get a superblock on an MTD-backed filesystem by MTD device number
+ */
+static int get_sb_mtd_nr(struct file_system_type *fs_type, int flags,
+const char *dev_name, void *data, int mtdnr,
+int (*fill_super)(struct super_block *, void *, int),
+struct vfsmount *mnt)
+{
+   struct mtd_info *mtd;
+
+   mtd = get_mtd_device(NULL, mtdnr);
+   if (!mtd) {
+   DEBUG(0, "MTDSB: Device #%u doesn't appear to exist\n", mtdnr);
+   return -EINVAL;
+   }
+
+   return get_sb_mtd_aux(fs_type, flags, dev_name, data, mtd, fill_super,
+ mnt);
+}
+
+/*
+ * set up an MTD-based superblock
+ */
+int get_sb_mtd(struct file_system_type *fs_type, int flags,
+  const char *dev_name, void *data,
+  int (*fill_super)(struct super_block *, void *, int),
+  struct vfsmount *mnt)
+{
+   struct nameidata nd;
+   int mtdnr, ret;
+
+   if (!dev_name)
+   return -EINVA

[PATCH] ecryptfs lower_file largefile issue

[Dmitriy Monakhov]

Where is largefile issue in ecryptfs.
Even if we want open file on ia32 with explicit O_LARGEFILE, lower_file will
be opened without O_LARGEFILE flag  this result in various errors in dmesg
and data corruption.
Testcase:
   write 'a' chars beyond 2Gb
  # strace ./writer_test root/file
  open("root/file", O_WRONLY|O_CREAT|O_LARGEFILE, 0666) = 3
  lseek(3, 2147483640, SEEK_SET)  = 2147483640
  write(3, ""..., 10240) = 10240
  ##check content
  # hexdump root/file4 
  000        
  *
  7ff0     6161 6161 6161 6161
  8000 6161 6161 6161 6161 6161 6161 6161 6161
  *
  800027f0 6161 6161 6161 6161
  800027f8
  
  #umount root 
  # mount -tecryptfs pr/dir/ root/  -ocipher=aes
  ## check content after remount
  # hexdump root/file4 
  000        
  *
  7ff0     6161 6161 6161 6161
  8000 6161 6161 6161 6161 6161 6161 6161 6161
  *
  800027f0 6161 6161 6161 6161    
  80002800        
  *
  80003000 ee3d e793 c410 3bd4 c642 5774 ad71 7932
  80003010 17a6 443c 4621 9e4a cf15 babd 19d0 f5e7
  *
  80004000 ce32 49ed 217c f87d 5539 3e96 517c 961c
  80004010 17a6 443c 4621 9e4a cf15 babd 19d0 f5e7
  *
  80005000  
  ### Wow content was changed, kernel complain with folowing messages:
  Error opening lower file for lower_dentry [0xf73a111c], lower_mnt 
[0xf7d8b1c0], and flags [0x0]
  Error opening lower_file to read header region
  Error attempting to read the [user.ecryptfs] xattr from the lower file; 
return value = [4294967201]
  Valid metadata not found in header region or xattr region; treating file as 
unencrypted
  
Lets explicitly add O_LARGEFILE to opened lower file flags as it done in unionfs
and nfsd. Also remove unnecessery #define from ecryptfs_initialize_file().
Signed-off-by: Dmitriy Monakhov <[EMAIL PROTECTED]>

diff --git a/fs/ecryptfs/file.c b/fs/ecryptfs/file.c
index bd969ad..7a7d25d 100644
--- a/fs/ecryptfs/file.c
+++ b/fs/ecryptfs/file.c
@@ -205,6 +205,7 @@ int ecryptfs_open_lower_file(struct file **lower_file,
 {
int rc = 0;
 
+   flags |= O_LARGEFILE;
dget(lower_dentry);
mntget(lower_mnt);
*lower_file = dentry_open(lower_dentry, lower_mnt, flags);
diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
index 27fd14a..a1fe8b4 100644
--- a/fs/ecryptfs/inode.c
+++ b/fs/ecryptfs/inode.c
@@ -200,9 +200,6 @@ static int ecryptfs_initialize_file(struct dentry 
*ecryptfs_dentry)
inode = ecryptfs_dentry->d_inode;
crypt_stat = &ecryptfs_inode_to_private(inode)->crypt_stat;
lower_flags = ((O_CREAT | O_TRUNC) & O_ACCMODE) | O_RDWR;
-#if BITS_PER_LONG != 32
-   lower_flags |= O_LARGEFILE;
-#endif
lower_mnt = ecryptfs_dentry_to_lower_mnt(ecryptfs_dentry);
/* Corresponding fput() at end of this function */
if ((rc = ecryptfs_open_lower_file(&lower_file, lower_dentry, lower_mnt,

Re: [Ecryptfs-devel] [PATCH] ecryptfs lower_file largefile issue

[Michael Halcrow]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On Wed, Feb 21, 2007 at 01:07:22PM +0300, Dmitriy Monakhov wrote:
> Where is largefile issue in ecryptfs.

Thanks for your thorough work on resolving such issues. We will
integrate your patches and testcases into the next release as soon as
we get a chance to review and test.

Mike
.___.
 Michael A. Halcrow  
   Security Software Engineer, IBM Linux Technology Center   
GnuPG Fingerprint: 419C 5B1E 948A FA73 A54C  20F5 DB40 8531 6DCA 8769

"To prohibit sharing software is to cut the bonds of society."   
 - Richard Stallman

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iQEVAwUBRdxDsdtAhTFtyodpAQPT0wf/amu/FboyQXHXwnn7pUEdPqqkxXpbZGrR
L8hknVilgVA8pvgK/RrUNuakrHRWZTBokbSbiUA/xgpHlUTHa6T3VE/JOe5pLzG+
vDEo8+Ya+yjRAMJ/970oLz1T4sUXvalgJlYRaKKqKEsZmFIQwMKoK7lmc+Th+p2J
R/ZfJ3olWmskPMlLHhN4j9EEVoAGQLUqiH+bBkx4AqLJNVq9S69fFBwGFVk4t+/y
Z6KJNhJsjHnOj6ADjSlObXmB5JFIWsUl4P0fouELB4lxTYh1C42S0hy5Pl60Sq1o
MrmXIvkAdm1klYwbhaF174zu2XDzDJICXq4475v3WWVxT65HYkanMQ==
=3zMo
-END PGP SIGNATURE-
-
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: utrace regressions (was: -mm merge plans for 2.6.21)

[Alexey Dobriyan]

On Sat, Feb 17, 2007 at 06:35:31PM -0800, Roland McGrath wrote:
> > Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4]
> > and [5] is also needed.
>
> It's not.  The utrace_regset for the debugregs already has that behavior
> for those two words, so mapping all 8 uarea words to the regset is fine.

Sorry, I don't get it. Choosing segment from x86_64_uarea is done before
calling regset->set and regset->get as well as before zero-filling. No
segment for u_debugreg[4] and [5] means -EIO before segment handlers
will have a chance to be called.

Do you want to consolidate these two?

{offsetof(struct user, u_debugreg[0]), offsetof(struct user, 
u_debugreg[4]), 3, 0},
{offsetof(struct user, u_debugreg[6]), offsetof(struct user, 
u_debugreg[8]), 3, 6 * sizeof(long)},

-
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: [Ecryptfs-devel] [PATCH] ecryptfs lower_file largefile issue

[Dmitriy Monakhov]

Michael Halcrow <[EMAIL PROTECTED]> writes:

> On Wed, Feb 21, 2007 at 01:07:22PM +0300, Dmitriy Monakhov wrote:
>> Where is largefile issue in ecryptfs.
>
> Thanks for your thorough work on resolving such issues. We will
> integrate your patches and testcases into the next release as soon as
> we get a chance to review and test.
BTW previously i've sent some patches for ecryptfs to lkml but forgot add
[EMAIL PROTECTED] to CC:.
links to patches:
"ecryptfs lower_file handling issues" http://lkml.org/lkml/2007/2/19/147
"ecryptfs_read_super path_lookup" errh fix http://lkml.org/lkml/2007/2/19/171

>
> Mike
> .___.
>  Michael A. Halcrow  
>Security Software Engineer, IBM Linux Technology Center   
> GnuPG Fingerprint: 419C 5B1E 948A FA73 A54C  20F5 DB40 8531 6DCA 8769
>
> "To prohibit sharing software is to cut the bonds of society."   
>  - Richard Stallman

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

Re: [PATCH 2/2] aio: propogate post-EIOCBQUEUED errors to completion event

[Suparna Bhattacharya]

On Mon, Feb 19, 2007 at 01:38:35PM -0800, Zach Brown wrote:
> aio: propogate post-EIOCBQUEUED errors to completion event
> 
> This addresses an oops reported by Leonid Ananiev <[EMAIL PROTECTED]>
> as archived at http://lkml.org/lkml/2007/2/8/337.
> 
> O_DIRECT kicks off bios and returns -EIOCBQUEUED to indicate its intention to
> call aio_complete() once the bios complete.   As we return from submission we
> must preserve the -EIOCBQUEUED return code so that fs/aio.c knows to let the
> bio completion call aio_complete().  This stops us from returning errors after
> O_DIRECT submission.
> 
> But we have a few places that are very interested in generating errors after
> bio submission.
> 
> The most critical of these is invalidating the page cache after a write.  This
> avoids exposing stale data to buffered operations that are performed after the
> O_DIRECT write succeeds.  We must do this after submission because the user
> buffer might have been an mmap()ed buffer of the region being written to.  The
> get_user_pages() in the O_DIRECT completion path could have faulted in stale
> data.
> 
> So this patch introduces a helper, aio_propogate_error(), which queues
> post-submission errors in the iocb so that they are given to the user
> completion event when aio_complete() is finally called.
> 
> To get this working we change the aio_complete() path so that the ring
> insertion is performed as the final iocb reference is dropped.  This gives the
> submission path time to queue its pending error before it drops its reference.
> This increases the space in the iocb as it has to record the two result codes
> from aio_complete() and the pending error from the submission path.

This is an interesting trick, but I'd like to consider hard whether the added
complexity is worth it. Could you list the various other cases you have in mind
which would want to use it ?

For the invalidate_inode_pages2_range() case, I wonder if the right
place to issue this is after the direct IO write has completed and before
aio_complete() is issued (somewhat like the way we do bio_check_pages_dirty
for DIO reads), rather than after submission when the IO may still not have
hit the disk. This would also make the behaviour uniform for synchronous and
async cases.

BTW, am I right in interpreting that with your change aio_complete() may
trigger an io_getevents() wakeup, before the corresponding event is placed
on the ring buffer ?

Regards
Suparna

> 
> This was tested by running O_DIRECT aio-stress concurrently with buffered 
> reads
> while triggering EIO in invalidate_inode_pages2_range() with the help of a
> debugfs bool hack.  Previously the kernel would oops as fs/aio.c and bio
> completion both called aio_complete().  With this patch aio-stress sees -EIO.
> 
> Signed-off-by: Zach Brown <[EMAIL PROTECTED]>
> ---
> 
>  fs/aio.c|   49 +-
>  include/linux/aio.h |   30 +
>  mm/filemap.c|4 +--
>  3 files changed, 57 insertions(+), 26 deletions(-)
> 
> --- a/fs/aio.cMon Feb 19 13:12:20 2007 -0800
> +++ b/fs/aio.cMon Feb 19 13:16:00 2007 -0800
> @@ -193,8 +193,7 @@ static int aio_setup_ring(struct kioctx 
>   kunmap_atomic((void *)((unsigned long)__event & PAGE_MASK), km); \
>  } while(0)
> 
> -static void aio_ring_insert_entry(struct kioctx *ctx, struct kiocb *iocb,
> -   long res, long res2)
> +static void aio_ring_insert_entry(struct kioctx *ctx, struct kiocb *iocb)
>  {
>   struct aio_ring_info*info;
>   struct aio_ring *ring;
> @@ -213,12 +212,12 @@ static void aio_ring_insert_entry(struct
> 
>   event->obj = (u64)(unsigned long)iocb->ki_obj.user;
>   event->data = iocb->ki_user_data;
> - event->res = res;
> - event->res2 = res2;
> -
> - dprintk("aio_complete: %p[%lu]: %p: %p %Lx %lx %lx\n",
> + event->res = iocb->ki_pending_err ? iocb->ki_pending_err : iocb->ki_res;
> + event->res2 = iocb->ki_res2;
> +
> + dprintk("aio_complete: %p[%lu]: %p: %p %Lx %d %lx %lx\n",
>   ctx, tail, iocb, iocb->ki_obj.user, iocb->ki_user_data,
> - res, res2);
> + iocb->ki_pending_err, iocb->ki_res, iocb->ki_res2);
> 
>   /* after flagging the request as done, we
>* must never even look at it again
> @@ -459,6 +458,7 @@ static struct kiocb fastcall *__aio_get_
>   req->ki_cancel = NULL;
>   req->ki_retry = NULL;
>   req->ki_dtor = NULL;
> + req->ki_pending_err = 0;
>   req->private = NULL;
>   req->ki_iovec = NULL;
>   INIT_LIST_HEAD(&req->ki_run_list);
> @@ -548,10 +548,14 @@ static int __aio_put_req(struct kioctx *
> 
>   assert_spin_locked(&ctx->ctx_lock);
> 
> - req->ki_users --;
> + req->ki_users--;
>   BUG_ON(req->ki_users < 0);
>   if (likely(req->ki_users))
>   return 0;
> +
> + if (kiocbIsInserted(req))
> + aio_ring_insert_entry(ctx, req);
>

Re: Serial related oops

[Jose Goncalves]

New devolpments.
I have upgraded to 2.6.16.41, applied a patch sent by Frederik that
removed the changed made in http://lkml.org/lkml/2005/6/23/266 and
activated some more kernel debug, i.e., CONFIG_KALLSYMS_ALL,
CONFIG_DEBUG_KERNEL, CONFIG_DETECT_SOFTLOCKUP, CONFIG_DEBUG_SLAB,
CONFIG_DEBUG_MUTEXES, CONFIG_FRAME_POINTER and CONFIG_FORCED_INLINING
(thanks to vda for pointing me to the right doc.).
At first it seemed to work fine, but after some days of continuous
running I've got another kernel Oops!
I attach the dmesg output and the assembly dump of serial8250_startup()
and serial8250_shutdown().

Regards,
José Gonçalves

<1>[18840.304048] Unable to handle kernel NULL pointer dereference at virtual address 0012
<1>[18840.313046]  printing eip:
<4>[18840.321687] c01bfa7a
<1>[18840.321714] *pde = 
<0>[18840.331287] Oops:  [#1]
<4>[18840.340687] Modules linked in:
<0>[18840.349749] CPU:0
<4>[18840.349767] EIP:0060:[]Not tainted VLI
<4>[18840.349782] EFLAGS: 00010202   (2.6.16.41-mtm5-debug1 #1) 
<0>[18840.377277] EIP is at serial_in+0xa/0x4a
<0>[18840.387221] eax: 0060   ebx:    ecx:    edx: 
<0>[18840.397805] esi:    edi: 0040   ebp: c728fe1c   esp: c728fe18
<0>[18840.408579] ds: 007b   es: 007b   ss: 0068
<0>[18840.419624] Process gp_position (pid: 11629, threadinfo=c728e000 task=c7443a90)
<0>[18840.420509] Stack: <0>  c01c0f88   c031fef0 0005 0202 
<0>[18840.445655]c7161a1c c031fef0 c124b510 c728fe60 c01bd97d c031fef0 c124b510 c124b510 
<0>[18840.460540] c773dbcc c728fe7c c01befe7 c124b510  ffed c773dbcc 
<0>[18840.475892] Call Trace:
<0>[18840.490039]  [] show_stack_log_lvl+0xa5/0xad
<0>[18840.504944]  [] show_registers+0x106/0x16f
<0>[18840.520104]  [] die+0xb6/0x127
<0>[18840.535497]  [] do_page_fault+0x380/0x4b3
<0>[18840.550828]  [] error_code+0x4f/0x60
<0>[18840.566645]  [] serial8250_startup+0x28f/0x2a9
<0>[18840.582471] Code: 38 43 78 75 02 b2 01 89 d0 eb 10 8b 41 70 39 43 70 0f 94 c0 0f b6 c0 eb 02 31 c0 5b 5d c3 90 90 90 55 89 e5 53 8b 5d 08 8b 55 0c <0f> b6 4b 12 0f b6 43 13 d3 e2 83 f8 02 74 1a 7f 05 48 74 09 eb 
<4>[18840.680471]  BUG: gp_position/11629, lock held at task exit time!
<4>[18840.702808]  [c124b528] {uart_register_driver}
<4>[18840.722346] .. held by:   gp_position:11629 [c7443a90, 117]
<4>[18840.742113] ... acquired at:   uart_get+0x28/0xde

vmlinux-2.6.16.41-mtm5-debug1: file format elf32-i386

Disassembly of section .text:

c01c0cf9 :
c01c0cf9:   55  push   %ebp
c01c0cfa:   89 e5   mov%esp,%ebp
c01c0cfc:   57  push   %edi
c01c0cfd:   56  push   %esi
c01c0cfe:   53  push   %ebx
c01c0cff:   53  push   %ebx
c01c0d00:   8b 5d 08mov0x8(%ebp),%ebx
c01c0d03:   8b 43 60mov0x60(%ebx),%eax
c01c0d06:   c6 83 a7 00 00 00 00movb   $0x0,0xa7(%ebx)
c01c0d0d:   89 c2   mov%eax,%edx
c01c0d0f:   c1 e2 04shl$0x4,%edx
c01c0d12:   83 f8 0acmp$0xa,%eax
c01c0d15:   8b 92 ac 37 25 c0   mov0xc02537ac(%edx),%edx
c01c0d1b:   66 89 93 9c 00 00 00mov%dx,0x9c(%ebx)
c01c0d22:   75 66   jnec01c0d8a 

c01c0d24:   c6 83 a4 00 00 00 00movb   $0x0,0xa4(%ebx)
c01c0d2b:   68 bf 00 00 00  push   $0xbf
c01c0d30:   6a 03   push   $0x3
c01c0d32:   53  push   %ebx
c01c0d33:   e8 82 ed ff ff  call   c01bfaba 
c01c0d38:   6a 10   push   $0x10
c01c0d3a:   6a 02   push   $0x2
c01c0d3c:   53  push   %ebx
c01c0d3d:   e8 78 ed ff ff  call   c01bfaba 
c01c0d42:   6a 00   push   $0x0
c01c0d44:   6a 01   push   $0x1
c01c0d46:   53  push   %ebx
c01c0d47:   e8 6e ed ff ff  call   c01bfaba 
c01c0d4c:   83 c4 24add$0x24,%esp
c01c0d4f:   6a 00   push   $0x0
c01c0d51:   6a 03   push   $0x3
c01c0d53:   53  push   %ebx
c01c0d54:   e8 61 ed ff ff  call   c01bfaba 
c01c0d59:   6a 00   push   $0x0
c01c0d5b:   6a 0c   push   $0xc
c01c0d5d:   53  push   %ebx
c01c0d5e:   e8 a7 ed ff ff  call   c01bfb0a 
c01c0d63:   68 bf 00 00 00  push   $0xbf
c01c0d68:   6a 03   push   $0x3
c01c0d6a:   53  push   %ebx
c01c0d6b:   e8 4a ed ff ff  call   c01bfaba 
c01c0d70:   83 c4 24add$0x24,%esp
c01c0d73:   6a 10   push   $0x10
c01c0d75:   6a 02   push   $0x2

Re: [PATCH] EXPORT_SYMBOL() time functions

[Rolf Eike Beer]

Arjan van de Ven wrote:
> On Wed, 2007-02-21 at 14:12 +0100, Rolf Eike Beer wrote:
> > These functions were inlines before
> > 8b9365d753d9870bb6451504c13570b81923228f. Now EXPORT_SYMBOL() them to
> > allow them to be used in modules again.
>
> please do not add random exports without users; exports eat up kernel
> size and memory. At minimum specify which mainline modules use the
> exports..

Nothing in mainline now. I just found out that the module I'm writing doesn't 
work anymore as timeval_to_jiffies() disappeared. If this is planned to go 
away from modules I should consider switching to timespec.

Eike


pgpk4J9C51SGQ.pgp
Description: PGP signature

Re: [RFC PATCH(Experimental) 2/4] Revert changes to workqueue.c

[Oleg Nesterov]

On 02/21, Srivatsa Vaddagiri wrote:
>
> On Tue, Feb 20, 2007 at 11:09:36PM +0300, Oleg Nesterov wrote:
> > > Which caller are you referring to here? Maybe we can decide on the
> > > option after we see the users of flush_workqueue() in DOWN_PREPARE.
> > 
> > mm/slab.c:cpuup_callback()
> 
> The cancel_rearming_delayed_work, if used as it is in cpuup_callback,
> will require that we send DOWN_PREPARE before freeze_processes().
> 
> But ..I am wondering if we can avoid doing cancel_rearming_delayed_work
> (and thus flush_workqueue) in CPU_DOWN_PREPARE of slab.c. Basically,
> 
> mm/slab.c:
> 
>   CPU_DOWN_PREPARE:   /* All processes frozen now */
>   cancel_delayed_work(&per_cpu(reap_work, cpu).timer);
>   del_work(&per_cpu(reap_work, cpu).work);
>   break;
> 
> 
> At the point of CPU_DOWN_PREPARE, keventd should be frozen and hence
> del_work() is a matter of just deleting the work from cwq->worklist.

Agreed. Note that we don't need the new "del_work". It is always safe to
use cancel_work_sync() if we know that the workqueue is frozen, it won't
block. We can also do

if (!cancel_delayed_work())
cancel_work_sync();

but it is ok to do cancel_work_sync() unconditionally.

Oleg.

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

Re: [BUG] PATA_PCMCIA does not work

[Alan]

Does this fix the oops ?

Alan


diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.20-mm2/drivers/ata/pata_pcmcia.c 
linux-2.6.20-mm2/drivers/ata/pata_pcmcia.c
--- linux.vanilla-2.6.20-mm2/drivers/ata/pata_pcmcia.c  2007-02-20 
13:37:58.0 +
+++ linux-2.6.20-mm2/drivers/ata/pata_pcmcia.c  2007-02-21 14:06:58.792707976 
+
@@ -308,7 +342,6 @@
if (info->ndev) {
struct ata_host *host = dev_get_drvdata(dev);
ata_host_detach(host);
-   dev_set_drvdata(dev, NULL);
}
info->ndev = 0;
pdev->priv = NULL;



-
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: [RFC PATCH(Experimental) 2/4] Revert changes to workqueue.c

[Gautham R Shenoy]

On Wed, Feb 21, 2007 at 05:30:10PM +0300, Oleg Nesterov wrote:
> On 02/21, Srivatsa Vaddagiri wrote:
> >
> > On Tue, Feb 20, 2007 at 11:09:36PM +0300, Oleg Nesterov wrote:
> > > > Which caller are you referring to here? Maybe we can decide on the
> > > > option after we see the users of flush_workqueue() in DOWN_PREPARE.
> > > 
> > > mm/slab.c:cpuup_callback()
> > 
> > The cancel_rearming_delayed_work, if used as it is in cpuup_callback,
> > will require that we send DOWN_PREPARE before freeze_processes().
> > 
> > But ..I am wondering if we can avoid doing cancel_rearming_delayed_work
> > (and thus flush_workqueue) in CPU_DOWN_PREPARE of slab.c. Basically,
> > 
> > mm/slab.c:
> > 
> > CPU_DOWN_PREPARE:   /* All processes frozen now */
> > cancel_delayed_work(&per_cpu(reap_work, cpu).timer);
> > del_work(&per_cpu(reap_work, cpu).work);
> > break;
> > 
> > 
> > At the point of CPU_DOWN_PREPARE, keventd should be frozen and hence
> > del_work() is a matter of just deleting the work from cwq->worklist.
> 
> Agreed. Note that we don't need the new "del_work". It is always safe to
> use cancel_work_sync() if we know that the workqueue is frozen, it won't
> block. We can also do
> 
>   if (!cancel_delayed_work())
>   cancel_work_sync();
> 
> but it is ok to do cancel_work_sync() unconditionally.

True. But this might be a one off solution for slab. However, if someone
in the future might require to do a flush_workqueue from
CPU_DOWN_PREPARE context, we would need to find a new workaround.

So, I'll try running CPU_DOWN_PREPARE and CPU_UP_PREPARE from
a non frozen context to check if there are any potential problems.
Hopfully there shouldn't be (m)any!
> 
> Oleg.
> 
thanks and regards
gautham.

-- 
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
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] siimage: DRAC4 note

[Alan]

Revised DRAC4 warning as Jeff suggested, this one includes more info
about why the problem occurs

Signed-off-by: Alan Cox <[EMAIL PROTECTED]>

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.20-mm2/drivers/ide/pci/siimage.c 
linux-2.6.20-mm2/drivers/ide/pci/siimage.c
--- linux.vanilla-2.6.20-mm2/drivers/ide/pci/siimage.c  2007-02-20 
13:38:01.0 +
+++ linux-2.6.20-mm2/drivers/ide/pci/siimage.c  2007-02-21 14:30:08.187487864 
+
@@ -26,6 +26,11 @@
  * If you have strange problems with nVidia chipset systems please
  * see the SI support documentation and update your system BIOS
  * if neccessary
+ *
+ *  The Dell DRAC4 has some interesting features including effectively hot
+ *  unplugging/replugging the virtual CD interface when the DRAC is reset.
+ *  This often causes drivers/ide/siimage to panic but is ok with the rather
+ *  smarter code in libata.
  */
 
 #include 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] PXAFB: Support for backlight control

[Rodolfo Giometti]

Backlight control support for the PXA fram buffer.

Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>

---

Each platform should define the backlight properties in its own setup
file in "linux/arch/arm/mach-pxa/" as follow:

   static int pxafb_bl_get_brightness(struct backlight_device *bl_dev)
   {
return read_the_backlight_brightness();
   }

   static int pxafb_bl_update_status(struct backlight_device *bl_dev)
   {
   int perc, ret;

   if (bl_dev->props->power != FB_BLANK_UNBLANK ||
   bl_dev->props->fb_blank != FB_BLANK_UNBLANK)
   perc = 0;
   else
   perc = bl_dev->props->brightness;

write_the_backlight_brightness(perc);

   return 0;
   }

   static struct backlight_properties wwpc1100_backlight_props = {
   .get_brightness = pxafb_bl_get_brightness,
   .update_status  = pxafb_bl_update_status,
   .max_brightness = 100,
   };
  
and then seting up the fb info as follow:

   wwpc1100_pxafb_info.modes = &special_modes;
   wwpc1100_pxafb_info.bl_props = &wwpc1100_backlight_props;
   set_pxa_fb_info(&wwpc1100_pxafb_info);
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index c1536d7..1ee589e 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -1514,6 +1514,14 @@ config FB_PXA_PARAMETERS
 
   describes the available parameters.
 
+config FB_PXA_BACKLIGHT
+   bool "Support for backlight control"
+   default y
+   depends on FB_PXA
+   select FB_BACKLIGHT
+   help
+ Say Y here if you want to control the backlight of your display.
+
 config FB_MBX
tristate "2700G LCD framebuffer support"
depends on FB && ARCH_PXA
diff --git a/drivers/video/pxafb.c b/drivers/video/pxafb.c
index b4947c8..489174a 100644
--- a/drivers/video/pxafb.c
+++ b/drivers/video/pxafb.c
@@ -9,6 +9,8 @@
  *  which in turn is
  *   Based on acornfb.c Copyright (C) Russell King.
  *
+ * Backlight support by Rodolfo Giometti <[EMAIL PROTECTED]>
+ *
  * This file is subject to the terms and conditions of the GNU General Public
  * License.  See the file COPYING in the main directory of this archive for
  * more details.
@@ -37,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -58,7 +61,6 @@
 #define LCCR0_INVALID_CONFIG_MASK 
(LCCR0_OUM|LCCR0_BM|LCCR0_QDM|LCCR0_DIS|LCCR0_EFM|LCCR0_IUM|LCCR0_SFM|LCCR0_LDM|LCCR0_ENB)
 #define LCCR3_INVALID_CONFIG_MASK (LCCR3_HSP|LCCR3_VSP|LCCR3_PCD|LCCR3_BPP)
 
-static void (*pxafb_backlight_power)(int);
 static void (*pxafb_lcd_power)(int, struct fb_var_screeninfo *);
 
 static int pxafb_activate_var(struct fb_var_screeninfo *var, struct pxafb_info 
*);
@@ -69,6 +71,71 @@ static void set_ctrlr_state(struct pxafb_info *fbi, u_int 
state);
 static char g_options[PXAFB_OPTIONS_SIZE] __initdata = "";
 #endif
 
+
+/*
+ * Backlight control
+ */
+#ifdef CONFIG_FB_BACKLIGHT
+static void pxafb_bl_suspend(struct pxafb_info *fbi)
+{
+   struct backlight_device *bl_dev = fbi->fb.bl_dev;
+
+   if (bl_dev) {
+   down(&bl_dev->sem);
+   bl_dev->props->fb_blank = FB_BLANK_POWERDOWN;
+   bl_dev->props->update_status(bl_dev);
+   up(&bl_dev->sem);
+   }
+}
+
+static void pxafb_bl_resume(struct pxafb_info *fbi)
+{
+   struct backlight_device *bl_dev = fbi->fb.bl_dev;
+
+   if (bl_dev) {
+   down(&bl_dev->sem);
+   bl_dev->props->fb_blank = FB_BLANK_UNBLANK;
+   bl_dev->props->update_status(bl_dev);
+   up(&bl_dev->sem);
+   }
+}
+
+static void pxafb_bl_init(struct fb_info *info, struct backlight_properties 
*bl_props)
+{
+   struct backlight_device *bl_dev;
+   char name[16];
+
+   snprintf(name, sizeof(name), "pxabl%d", info->node);
+
+   bl_dev = backlight_device_register(name, info->dev, info, bl_props);
+   if (IS_ERR(bl_dev)) {
+   info->bl_dev = NULL;
+   printk(KERN_WARNING "pxafb: backlight registration failed\n");
+   return;
+   }
+
+   mutex_lock(&info->bl_mutex);
+   info->bl_dev = bl_dev;
+   fb_bl_default_curve(info, 0, 0, 100);   /* level: 0 - 100 */
+   mutex_unlock(&info->bl_mutex);
+
+   down(&bl_dev->sem);
+   bl_dev->props->brightness = bl_props->max_brightness;
+   bl_dev->props->power = FB_BLANK_UNBLANK;
+   bl_dev->props->update_status(bl_dev);
+   up(&bl_dev->sem);
+
+   printk("pxafb: backlight initialized (%s)\n", name);
+}
+#else
+static inline void pxafb_bl_init(struct fb_info *info, struct 
backlight_properties *bl_props) {}
+static inline void pxafb_bl_suspend(struct pxafb_info *fbi) {}
+static inline void pxafb_bl_resume(struct pxafb_info *fbi) {}
+#endif /* CONFIG_FB_BACKLIGHT */
+
+/*
+ *
+ */
 static inline void pxafb_schedule_work(struct pxafb_info *fbi, u_int state)
 {
unsigned long flags;
@@ -736,14 +803,6 @@ static i

Re: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug

[Gautham R Shenoy]

Rafael,
On Sat, Feb 17, 2007 at 12:24:45PM +0100, Rafael J. Wysocki wrote:
> 
> Pavel, do you think we can remove the PF_NOFREEZE from bluetooth, BTW?

The create_workqueue by default marks the worker_threads to be
non_freezable. For cpu hotplug, all workqueues can be frozen 
except the "kthread" workqueue (which is single threaded, so won't 
be frozen anyway).

And a quick cscope scan shows that only the "xfslogd" and "xfsdatad"
are the only freezable workqueues. Any particular reason
for not marking rest of the non-single_threaded workqueues freezeable ??

thanks and regards
gautham
-- 
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
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: Serial related oops

[Jose Goncalves]

Jose Goncalves wrote:
> New devolpments.
> I have upgraded to 2.6.16.41, applied a patch sent by Frederik that
> removed the changed made in http://lkml.org/lkml/2005/6/23/266 and
> activated some more kernel debug, i.e., CONFIG_KALLSYMS_ALL,
> CONFIG_DEBUG_KERNEL, CONFIG_DETECT_SOFTLOCKUP, CONFIG_DEBUG_SLAB,
> CONFIG_DEBUG_MUTEXES, CONFIG_FRAME_POINTER and CONFIG_FORCED_INLINING
> (thanks to vda for pointing me to the right doc.).
> At first it seemed to work fine, but after some days of continuous
> running I've got another kernel Oops!
> I attach the dmesg output and the assembly dump of serial8250_startup()
> and serial8250_shutdown().
>   

And also the assembly dump of serial_in() were the NULL pointer
dereference happens.

José Gonçalves


vmlinux-2.6.16.41-mtm5-debug1: file format elf32-i386

Disassembly of section .text:

c01bfa70 :
c01bfa70:   55  push   %ebp
c01bfa71:   89 e5   mov%esp,%ebp
c01bfa73:   53  push   %ebx
c01bfa74:   8b 5d 08mov0x8(%ebp),%ebx
c01bfa77:   8b 55 0cmov0xc(%ebp),%edx
c01bfa7a:   0f b6 4b 12 movzbl 0x12(%ebx),%ecx
c01bfa7e:   0f b6 43 13 movzbl 0x13(%ebx),%eax
c01bfa82:   d3 e2   shl%cl,%edx
c01bfa84:   83 f8 02cmp$0x2,%eax
c01bfa87:   74 1a   je c01bfaa3 
c01bfa89:   7f 05   jg c01bfa90 
c01bfa8b:   48  dec%eax
c01bfa8c:   74 09   je c01bfa97 
c01bfa8e:   eb 21   jmpc01bfab1 
c01bfa90:   83 f8 03cmp$0x3,%eax
c01bfa93:   74 15   je c01bfaaa 
c01bfa95:   eb 1a   jmpc01bfab1 
c01bfa97:   8a 43 78mov0x78(%ebx),%al
c01bfa9a:   01 d0   add%edx,%eax
c01bfa9c:   8b 13   mov(%ebx),%edx
c01bfa9e:   48  dec%eax
c01bfa9f:   ee  out%al,(%dx)
c01bfaa0:   42  inc%edx
c01bfaa1:   eb 10   jmpc01bfab3 
c01bfaa3:   03 53 04add0x4(%ebx),%edx
c01bfaa6:   8a 02   mov(%edx),%al
c01bfaa8:   eb 0a   jmpc01bfab4 
c01bfaaa:   03 53 04add0x4(%ebx),%edx
c01bfaad:   8b 02   mov(%edx),%eax
c01bfaaf:   eb 06   jmpc01bfab7 
c01bfab1:   03 13   add(%ebx),%edx
c01bfab3:   ec  in (%dx),%al
c01bfab4:   0f b6 c0movzbl %al,%eax
c01bfab7:   5b  pop%ebx
c01bfab8:   5d  pop%ebp
c01bfab9:   c3  ret
Disassembly of section .init.text:
Disassembly of section .altinstr_replacement:
Disassembly of section .exit.text:

Re: [PATCH] [MTD] CHIPS: oops in cfi_amdstd_sync

[Jörn Engel]

On Tue, 20 February 2007 17:46:13 -0800, Vijay Sampath wrote:
> 
> The files cfi_cmdset_0002.c and cfi_cmdset_0020.c do not initialize
> their wait queues like is done in cfi_cmdset_0001.c. This causes an
> oops when the wait queue is accessed. I have copied the code from
> cfi_cmdset_0001.c that is pertinent to initialization of the wait
> queue.

Patch looks good, but I can no longer test it.  Josh may still have
access to some commandset 20 chips.  Josh, any objections?

Jörn

-- 
The only real mistake is the one from which we learn nothing.
-- John Powell


signature.asc
Description: Digital signature

Re: 2.6.21-rc1 build error on ARM with modular IPV6

[Michael-Luke Jones]

Apologies for brain failure, below should read 2.6.21-rc1.

Everything else should be correct.

Michael-Luke Jones

On 21 Feb 2007, at 10:50, M.L. Jones wrote:


NB: I'm not subscribed so please CC me in any reply! Thanks...

Hi there,

Just attempted a build of vanilla 2.6.20-rc1 and got a failure with  
our usual defconfig. Notably, we build IPV6 support as modular -  
this seems to be the source of the problem.


If any other info is required, please ask.

Thanks for your help,

Michael-Luke Jones
NSLU2-Linux Core Team

==Error==
 GEN .version
 CHK include/linux/compile.h
 UPD include/linux/compile.h
 CC  init/version.o
 LD  init/built-in.o
 LD  .tmp_vmlinux1
net/built-in.o: In function `svc_udp_recvfrom':
sysctl_net.c:(.text+0x79fb4): undefined reference to  
`__ipv6_addr_type'

make[1]: *** [.tmp_vmlinux1] Error 1

==Config==
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.21-rc1
# Wed Feb 21 02:32:29 2007
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_TIME=y
CONFIG_MMU=y
# CONFIG_NO_IOPORT is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ZONE_DMA=y
CONFIG_VECTORS_BASE=0x
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
# CONFIG_VM_EVENT_COUNTERS is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y

#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
CONFIG_IOSCHED_DEADLINE=y
# CONFIG_IOSCHED_CFQ is not set
# CONFIG_DEFAULT_AS is not set
CONFIG_DEFAULT_DEADLINE=y
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="deadline"

#
# System Type
#
# CONFIG_ARCH_AAEC2000 is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS7500 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CO285 is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IMX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IOP13XX is not set
CONFIG_ARCH_IXP4XX=y
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_L7200 is not set
# CONFIG_ARCH_NS9XXX is not set
# CONFIG_ARCH_PNX4008 is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_LH7A40X is not set
# CONFIG_ARCH_OMAP is not set
CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y

#
# Intel IXP4xx Implementation Options
#

#
# IXP4xx Platforms
#
CONFIG_MACH_NSLU2=y
CONFIG_MACH_AVILA=y
CONFIG_MACH_LOFT=y
# CONFIG_ARCH_ADI_COYOTE is not set
CONFIG_ARCH_IXDP425=y
# CONFIG_MACH_IXDPG425 is not set
# CONFIG_MACH_IXDP465 is not set
CONFIG_ARCH_IXCDP1100=y
# CONFIG_ARCH_PRPMC1100 is not set
CONFIG_MACH_NAS100D=y
CONFIG_ARCH_IXDP4XX=y
# CONFIG_MACH_GTWX5715 is not set

#
# IXP4xx Options
#
CONFIG_DMABOUNCE=y
# CONFIG_IXP4XX_INDIRECT_PCI is not set

#
# Processor Type
#
CONFIG_CPU_32=y
CONFIG_CPU_XSCALE=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5T=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_TLB_V4WBI=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y

#
# Processor Features
#
CONFIG_ARM_THUMB=y
# CONFIG_CPU_BIG_ENDIAN is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_OUTER_CACHE is not set
# CONFIG_IWMMXT is not set
CONFIG_XSCALE_PMU=y

#
# Bus support
#
CONFIG_PCI=y

#
# PCCARD (PCMCIA/CardBus) support
#
# CONF

Re: PCI riser cards and PCI irq routing, etc

[Udo van den Heuvel]

Krzysztof Halasa wrote:
> Udo van den Heuvel <[EMAIL PROTECTED]> writes:
> 
>> So if my non-VIA riser card can use DN 19 and also INT_A things should work?
> 
> That INT_A may be INT_A from their (motherboard) point of view, but
> the riser card doesn't know about that, it only knows INTs as seen
> at its PCI edge connector (so this INT_A here is meaningless).
> 
> Device numbers aren't rotated but rather derived from address lines
> (address/data). AD0-31 lines are the same across the whole PCI bus.
> That means device numbers are independent of POV.
> 
>> (assuming that VIA Epia EN BIOS 1.07 is enough to use this card)
> 
> My VIA EPIA-M 600 is probably older than your one, so I'd assume
> it should work as well.
> When you configure 0x13 and 0x14, both devices get IRQs - that means
> the BIOS can see both of them.

But the IRQ for the DVB-T card doesn't work.
I would need to test the DVB-T card alone to be sure it has working IRQ.
If so, what would be the conclusion?

>> The DN is the only variable so INT lines are hardwired on the riser card?
> 
> Yep. You just need a bit of soldering.

What IRQ rerouting would I need to try? 1 of 3 choices?
Or one best bet?

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

cat problem in tiny_tty driver (the source included)

[Mockern]

I tried to check cat operations for tiny_tty driver from LDD book. 

What is wrong with cat operation here?

Here is the output from strace cat hello > /dev/my_tty1

[EMAIL PROTECTED]:/home# strace cat hello > /dev/my_tty1
execve("/bin/cat", ["cat", "hello"], [/* 12 vars */]) = 0
brk(0)  = 0x7d000
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)  = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=5664, ...}) = 0
old_mmap(NULL, 5664, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
close(3)= 0
open("/lib/libm.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\250B\0\000"..., 512) = 51
2
fstat64(3, {st_mode=S_IFREG|0755, st_size=480324, ...}) = 0
old_mmap(NULL, 506412, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002
mprotect(0x40093000, 35372, PROT_NONE)  = 0
old_mmap(0x40098000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x70
000) = 0x40098000
close(3)= 0
open("/lib/libcrypt.so.1", O_RDONLY)= 3
read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\260\10\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=19940, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0
x40019000
old_mmap(NULL, 211220, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4009c000
mprotect(0x400a1000, 190740, PROT_NONE) = 0
old_mmap(0x400a4000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) =
 0x400a4000
old_mmap(0x400a9000, 157972, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANO
NYMOUS, -1, 0) = 0x400a9000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\330p\1\000"..., 512) = 51
2
fstat64(3, {st_mode=S_IFREG|0755, st_size=1240024, ...}) = 0
old_mmap(NULL, 1257088, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x400d
mprotect(0x401f5000, 56960, PROT_NONE)  = 0
old_mmap(0x401f8000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12
) = 0x401f8000
old_mmap(0x40201000, 7808, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONY
MOUS, -1, 0) = 0x40201000
close(3)= 0
munmap(0x40017000, 5664)= 0
getuid32()  = 0
getgid32()  = 0
setgid32(0) = 0
setuid32(0) = 0
brk(0)  = 0x7d000
brk(0x9e000)= 0x9e000
brk(0)  = 0x9e000
open("hello", O_RDONLY) = 3
read(3, "123456789", 8192)  = 9
write(1, "123456789", 9)= -1 EINVAL (Invalid 
argument)//??
write(2, "cat: ", 5cat: )= 5
write(2, "Write Error", 11Write Error) = 11
write(2, ": Invalid argument\n", 19: Invalid argument
)= 19
close(3)= 0
io_submit(0, 0x40200164, 0 
Process 1432 detached
[EMAIL PROTECTED]:/home#



/*
 * Tiny TTY driver
 *
 * Copyright (C) 2002-2004 Greg Kroah-Hartman ([EMAIL PROTECTED])
 *
 *  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, version 2 of the License.
 *
 * This driver shows how to create a minimal tty driver.  It does not rely on
 * any backing hardware, but creates a timer that emulates data being received
 * from some kind of hardware.
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


#define DRIVER_VERSION "v2.0"
#define DRIVER_AUTHOR "Greg Kroah-Hartman <[EMAIL PROTECTED]>"
#define DRIVER_DESC "Tiny TTY driver"

/* Module information */
MODULE_AUTHOR( DRIVER_AUTHOR );
MODULE_DESCRIPTION( DRIVER_DESC );
MODULE_LICENSE("GPL");

#define DELAY_TIME  HZ * 2  /* 2 seconds per character */
#define TINY_DATA_CHARACTER 't'

#define TINY_TTY_MAJOR  240 /* experimental range */
#define TINY_TTY_MINORS 4   /* only have 4 devices */

struct tiny_serial {
struct tty_struct   *tty;   /* pointer to the tty for this 
device */
int open_count; /* number of times this port 
has been opened */
struct semaphoresem;/* locks this structure */
struct timer_list   *timer;

/* for tiocmget and tiocmset functions */
int msr;/* MSR shadow */
int mcr;/* MCR shadow */

/* for ioctl fun */
struct serial_structserial;
wait_queue_head_t   wait;
struct async_icount icount;
};

static struct tiny_serial *tiny_table[T

Re: how to limit flip buffer size in tty driver?

[Alan]

On Tue, 20 Feb 2007 15:50:27 +0300 (MSK)
"Mockern" <[EMAIL PROTECTED]> wrote:

> Thank you Alan for your respond,
> 
> Could you help me with a problem which I have with my tty driver, please?
> 
> It does not work with Linux cat operation (but there are no problems to 
> write, read with select from user space application!). 

Looking at the trace I am confused as to what does not work ? Can you
explain the way in which it doesn't work ?
-
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] free swap space when (re)activating page

[Al Boldi]

Rik van Riel wrote:
> Rik van Riel wrote:
> > ... because I think this is what my patch does :)
>
> Never mind, I see it now.
>
> The attached patch should be correct.

Your patch seems to improve the situation a little bit, but the numbers still 
look weird, especially for swap-in, which gets progressively slower.

RAM 512mb , SWAP 1G
#mount -t tmpfs -o size=1G none /dev/shm
#time cat /dev/full > /dev/shm/x.dmp
15sec
#time cat /dev/shm/x.dmp > /dev/null
58sec
#time cat /dev/shm/x.dmp > /dev/null
72sec
#time cat /dev/shm/x.dmp > /dev/null
85sec
#time cat /dev/shm/x.dmp > /dev/null
93sec
#time cat /dev/shm/x.dmp > /dev/null
99sec


Thanks!

--
Al

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