date:20100716

Thanks for taking a look a this Kame, answers below...

-Nathan

On 07/15/2010 07:06 PM, KAMEZAWA Hiroyuki wrote:
 On Thu, 15 Jul 2010 13:37:51 -0500
 Nathan Fontenot nf...@austin.ibm.com wrote:
 
 Split the memory_block struct into a memory_block
 struct to cover each sysfs directory and a new memory_block_section
 struct for each memory section covered by the sysfs directory.
 This change allows for creation of memory sysfs directories that
 can span multiple memory sections.

 This can be beneficial in that it can reduce the number of memory
 sysfs directories created at boot.  This also allows different
 architectures to define how many memory sections are covered by
 a sysfs directory.

 Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
 ---
  drivers/base/memory.c  |  222 
 ++---
  include/linux/memory.h |   11 +-
  2 files changed, 167 insertions(+), 66 deletions(-)

 Index: linux-2.6/drivers/base/memory.c
 ===
 --- linux-2.6.orig/drivers/base/memory.c 2010-07-15 08:48:41.0 
 -0500
 +++ linux-2.6/drivers/base/memory.c  2010-07-15 09:55:54.0 -0500
 @@ -28,6 +28,14 @@
  #include asm/uaccess.h
  
  #define MEMORY_CLASS_NAME   memory
 +#define MIN_MEMORY_BLOCK_SIZE   (1  SECTION_SIZE_BITS)
 +
 +static int sections_per_block;
 +
 +static inline int base_memory_block_id(int section_nr)
 +{
 +return (section_nr / sections_per_block) * sections_per_block;
 +}
  
  static struct sysdev_class memory_sysdev_class = {
  .name = MEMORY_CLASS_NAME,
 @@ -94,10 +102,9 @@
  }
  
  static void
 -unregister_memory(struct memory_block *memory, struct mem_section *section)
 +unregister_memory(struct memory_block *memory)
  {
  BUG_ON(memory-sysdev.cls != memory_sysdev_class);
 -BUG_ON(memory-sysdev.id != __section_nr(section));
  
  /* drop the ref. we got in remove_memory_block() */
  kobject_put(memory-sysdev.kobj);
 @@ -123,13 +130,20 @@
  static ssize_t show_mem_removable(struct sys_device *dev,
  struct sysdev_attribute *attr, char *buf)
  {
 +struct memory_block *mem;
 +struct memory_block_section *mbs;
  unsigned long start_pfn;
 -int ret;
 -struct memory_block *mem =
 -container_of(dev, struct memory_block, sysdev);
 +int ret = 1;
 +
 +mem = container_of(dev, struct memory_block, sysdev);
 +mutex_lock(mem-state_mutex);
  
 -start_pfn = section_nr_to_pfn(mem-phys_index);
 -ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
 +list_for_each_entry(mbs, mem-sections, next) {
 +start_pfn = section_nr_to_pfn(mbs-phys_index);
 +ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
 +}
 +
 +mutex_unlock(mem-state_mutex);
 
 Hmm, this means memory cab be offlined the while memory block section. Right ?
 Please write this fact in patch description...
 And Documentaion/memory_hotplug.txt as From user's perspective, memory 
 section
 is not a unit of memory hotplug anymore.
 And descirbe about a new rule.

You are correct.  A memory block is removable only if all of the memory
sections contained within the memory block are removable.

I will include a documentation patch with v3 of the patches to explain this
and to explain that memory add/remove operations are done on a per memory
block basis.

 
 
  return sprintf(buf, %d\n, ret);
  }
  
 @@ -182,16 +196,16 @@
   * OK to have direct references to sparsemem variables in here.
   */
  static int
 -memory_block_action(struct memory_block *mem, unsigned long action)
 +memory_block_action(struct memory_block_section *mbs, unsigned long action)
  {
  int i;
  unsigned long psection;
  unsigned long start_pfn, start_paddr;
  struct page *first_page;
  int ret;
 -int old_state = mem-state;
 +int old_state = mbs-state;
  
 -psection = mem-phys_index;
 +psection = mbs-phys_index;
  first_page = pfn_to_page(psection  PFN_SECTION_SHIFT);
  
  /*
 @@ -217,18 +231,18 @@
  ret = online_pages(start_pfn, PAGES_PER_SECTION);
  break;
  case MEM_OFFLINE:
 -mem-state = MEM_GOING_OFFLINE;
 +mbs-state = MEM_GOING_OFFLINE;
  start_paddr = page_to_pfn(first_page)  PAGE_SHIFT;
  ret = remove_memory(start_paddr,
  PAGES_PER_SECTION  PAGE_SHIFT);
  if (ret) {
 -mem-state = old_state;
 +mbs-state = old_state;
  break;
  }
  break;
  default:
  WARN(1, KERN_WARNING %s(%p, %ld) unknown action: 
 %ld\n,
 -__func__, mem, action, action);
 +__func__, mbs, action,

Re: [PATCH 2/5] v2 Create new 'end_phys_index' file

On 07/15/2010 07:08 PM, KAMEZAWA Hiroyuki wrote:
 On Thu, 15 Jul 2010 13:38:52 -0500
 Nathan Fontenot nf...@austin.ibm.com wrote:
 
 Add a new 'end_phys_index' file to each memory sysfs directory to
 report the physical index of the last memory section
 covered by the sysfs directory.

 Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
 
 Does memory_block have to be contiguous between [phys_index, end_phys_index] ?
 Should we provide # of sections or amount of memory under a block ?

Good point.  There is nothing that guarantees that a memory block contains
the contiguous memory sections [phys_index, end_phys_index].  Should there be
a 'memory_sections' file that list the memory sections present in a memory 
block?
Something along the lines of;

# cat memory0/memory_sections
0,1,2,3

This could be done instead of the end_phys_index file.

-Nathan
 
 
 No objections to end_phys_index...buf plz fix diff style.
 
 Thanks,
 -Kame
 
 
 ---
  drivers/base/memory.c  |   14 +-
  include/linux/memory.h |3 +++
  2 files changed, 16 insertions(+), 1 deletion(-)

 Index: linux-2.6/drivers/base/memory.c
 ===
 --- linux-2.6.orig/drivers/base/memory.c 2010-07-15 09:55:54.0 
 -0500
 +++ linux-2.6/drivers/base/memory.c  2010-07-15 09:56:05.0 -0500
 @@ -121,7 +121,15 @@
  {
  struct memory_block *mem =
  container_of(dev, struct memory_block, sysdev);
 -return sprintf(buf, %08lx\n, mem-phys_index);
 +return sprintf(buf, %08lx\n, mem-start_phys_index);
 +}
 +
 +static ssize_t show_mem_end_phys_index(struct sys_device *dev,
 +struct sysdev_attribute *attr, char *buf)
 +{
 +struct memory_block *mem =
 +container_of(dev, struct memory_block, sysdev);
 +return sprintf(buf, %08lx\n, mem-end_phys_index);
  }
  
  /*
 @@ -321,6 +329,7 @@
  }
  
  static SYSDEV_ATTR(phys_index, 0444, show_mem_phys_index, NULL);
 +static SYSDEV_ATTR(end_phys_index, 0444, show_mem_end_phys_index, NULL);
  static SYSDEV_ATTR(state, 0644, show_mem_state, store_mem_state);
  static SYSDEV_ATTR(phys_device, 0444, show_phys_device, NULL);
  static SYSDEV_ATTR(removable, 0444, show_mem_removable, NULL);
 @@ -533,6 +542,8 @@
  if (!ret)
  ret = mem_create_simple_file(mem, phys_index);
  if (!ret)
 +ret = mem_create_simple_file(mem, end_phys_index);
 +if (!ret)
  ret = mem_create_simple_file(mem, state);
  if (!ret)
  ret = mem_create_simple_file(mem, phys_device);
 @@ -577,6 +588,7 @@
  if (list_empty(mem-sections)) {
  unregister_mem_sect_under_nodes(mem);
  mem_remove_simple_file(mem, phys_index);
 +mem_remove_simple_file(mem, end_phys_index);
  mem_remove_simple_file(mem, state);
  mem_remove_simple_file(mem, phys_device);
  mem_remove_simple_file(mem, removable);
 Index: linux-2.6/include/linux/memory.h
 ===
 --- linux-2.6.orig/include/linux/memory.h2010-07-15 09:54:06.0 
 -0500
 +++ linux-2.6/include/linux/memory.h 2010-07-15 09:56:05.0 -0500
 @@ -29,6 +29,9 @@
  
  struct memory_block {
  unsigned long state;
 +unsigned long start_phys_index;
 +unsigned long end_phys_index;
 +
  /*
   * This serializes all state change requests.  It isn't
   * held during creation because the control files are

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

 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 4/5] v2 Update sysfs node routines for new sysfs memory directories

On 07/15/2010 07:12 PM, KAMEZAWA Hiroyuki wrote:
 On Thu, 15 Jul 2010 13:40:40 -0500
 Nathan Fontenot nf...@austin.ibm.com wrote:
 
 Update the node sysfs directory routines that create
 links to the memory sysfs directories under each node.
 This update makes the node code aware that a memory sysfs
 directory can cover multiple memory sections.

 Signed-off-by: Nathan Fontenot nf...@austin.ibm.com
 
 Shouldn't static int link_mem_sections(int nid) be update ?
 It does
  for (pfn = start_pfn; pfn  end_pfn; pfn += PAGES_PER_SECTION) {
 register..
 

No, although the name 'link_mem_sections' does imply that it should.  The
range of start_pfn..end_pfn examined in this routine is the range of pfn's
covered by the entire node, not a memory_block.

-Nathan

 Thanks,
 -Kame
 
 
 ---
  drivers/base/node.c |   12 
  1 file changed, 8 insertions(+), 4 deletions(-)

 Index: linux-2.6/drivers/base/node.c
 ===
 --- linux-2.6.orig/drivers/base/node.c   2010-07-15 09:54:06.0 
 -0500
 +++ linux-2.6/drivers/base/node.c2010-07-15 09:56:16.0 -0500
 @@ -346,8 +346,10 @@
  return -EFAULT;
  if (!node_online(nid))
  return 0;
 -sect_start_pfn = section_nr_to_pfn(mem_blk-phys_index);
 -sect_end_pfn = sect_start_pfn + PAGES_PER_SECTION - 1;
 +
 +sect_start_pfn = section_nr_to_pfn(mem_blk-start_phys_index);
 +sect_end_pfn = section_nr_to_pfn(mem_blk-end_phys_index);
 +sect_end_pfn += PAGES_PER_SECTION - 1;
  for (pfn = sect_start_pfn; pfn = sect_end_pfn; pfn++) {
  int page_nid;
  
 @@ -383,8 +385,10 @@
  if (!unlinked_nodes)
  return -ENOMEM;
  nodes_clear(*unlinked_nodes);
 -sect_start_pfn = section_nr_to_pfn(mem_blk-phys_index);
 -sect_end_pfn = sect_start_pfn + PAGES_PER_SECTION - 1;
 +
 +sect_start_pfn = section_nr_to_pfn(mem_blk-start_phys_index);
 +sect_end_pfn = section_nr_to_pfn(mem_blk-end_phys_index);
 +sect_end_pfn += PAGES_PER_SECTION - 1;
  for (pfn = sect_start_pfn; pfn = sect_end_pfn; pfn++) {
  int nid;
  

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

 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/7] De-couple sysfs memory directories from memory sections

On 07/16/2010 02:13 AM, Greg KH wrote:
 On Mon, Jul 12, 2010 at 10:27:02AM -0500, Nathan Fontenot wrote:
 This set of patches de-couples the idea that there is a single
 directory in sysfs for each memory section.
 
 Any reason you didn't cc: the sysfs maintainer on these patches?  If
 not, I'll gladly ignore them...

Ummm I have no good excuse. :)

Will add you to cc for v3 of the patch.

 
 (hint, scripts/get_maintainer.pl is your friend...)
Thanks.

-Nathan
 
 greg k-h

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] Remove REDWOOD_[456] config options and conditional code

2010-07-16 Thread Milton Miller


On Fri, 16 Jul 2010 at about 08:20:55 -0600 Josh Boyer wrote:
 On Fri, Jul 16, 2010 at 02:29:02PM +0200, Christian Dietrich wrote: 
  The config options for REDWOOD_[456] were commented out in the powerpc
  Kconfig. The ifdefs referencing this options therefore are dead and all
  references to this can be removed (Also dependencies in other KConfig
  files).

 This seems fine with me.
 
 The only question is which tree it coms through. I'm happy to take it
 in via mine if the netdev and MTD people are fine with that. Otherwise,
 my ack is below.


 On Fri, 16 Jul 2010 around 14:29:08 +0200 Christian Dietrich wrote:
  diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
  index f22bc9f..6629d09 100644
  --- a/drivers/mtd/maps/Kconfig
  +++ b/drivers/mtd/maps/Kconfig
  @@ -321,7 +321,7 @@ config MTD_CFI_FLAGADM
  
   config MTD_REDWOOD
  tristate CFI Flash devices mapped on IBM Redwood
  -   depends on MTD_CFI  ( REDWOOD_4 || REDWOOD_5 || REDWOOD_6 )
  +   depends on MTD_CFI
  help
This enables access routines for the flash chips on the IBM
Redwood board. If you have one of these boards and would like to
  diff --git a/drivers/mtd/maps/redwood.c b/drivers/mtd/maps/redwood.c
  index 933c0b6..d2c9db0 100644
  --- a/drivers/mtd/maps/redwood.c
  +++ b/drivers/mtd/maps/redwood.c
  @@ -22,8 +22,6 @@

The patches are unnecssarly coupled by removing the REDWOOD_* symbols
in the MTD area before removing the files and Kconfig completely in
the second patch.  This could easily be eliminated by pushing the
two fragments into the second patch.

milton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

2010-07-16 Thread Catalin Marinas

On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote:
 - It still doesn't resolve dependencies.  A solver would help with this.
   For the time being I work around the problem by running the generated
   config through 'oldconfig' and looking for differences.  If the files
   differ (ignoring comments and generateconfig_* options) after oldconfig,
   then the board_defconfig target returns a failure.  (but leaves the
   new .config intact so the user can resolve it with menuconfig).  This
   way at least the user is told when a Kconfig fragment is invalid.

It's not a solver but I'm pushing a patch to warn on selecting symbols
with unmet dependencies so that you can select further symbols (manual
solving). The patch is in linux-next but you also can grab it from:

http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-2.6-cm.git;a=commitdiff_plain;h=5d87db2d2a332784bbf2b1ec3e141486f4d41d6f

-- 
Catalin

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/5] v2 Split the memory_block structure

On Thu, 2010-07-15 at 13:37 -0500, Nathan Fontenot wrote:
 @@ -123,13 +130,20 @@
  static ssize_t show_mem_removable(struct sys_device *dev,
   struct sysdev_attribute *attr, char *buf)
  {
 + struct memory_block *mem;
 + struct memory_block_section *mbs;
   unsigned long start_pfn;
 - int ret;
 - struct memory_block *mem =
 - container_of(dev, struct memory_block, sysdev);
 + int ret = 1;
 +
 + mem = container_of(dev, struct memory_block, sysdev);
 + mutex_lock(mem-state_mutex);
 
 - start_pfn = section_nr_to_pfn(mem-phys_index);
 - ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
 + list_for_each_entry(mbs, mem-sections, next) {
 + start_pfn = section_nr_to_pfn(mbs-phys_index);
 + ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
 + }
 +
 + mutex_unlock(mem-state_mutex);
   return sprintf(buf, %d\n, ret);
  }

Now that the state_mutex is getting used for other stuff, should we
just make it mutex?

 @@ -182,16 +196,16 @@
   * OK to have direct references to sparsemem variables in here.
   */
  static int
 -memory_block_action(struct memory_block *mem, unsigned long action)
 +memory_block_action(struct memory_block_section *mbs, unsigned long action)
  {
   int i;
   unsigned long psection;
   unsigned long start_pfn, start_paddr;
   struct page *first_page;
   int ret;
 - int old_state = mem-state;
 + int old_state = mbs-state;
 
 - psection = mem-phys_index;
 + psection = mbs-phys_index;
   first_page = pfn_to_page(psection  PFN_SECTION_SHIFT);
 
   /*
 @@ -217,18 +231,18 @@
   ret = online_pages(start_pfn, PAGES_PER_SECTION);
   break;
   case MEM_OFFLINE:
 - mem-state = MEM_GOING_OFFLINE;
 + mbs-state = MEM_GOING_OFFLINE;
   start_paddr = page_to_pfn(first_page)  PAGE_SHIFT;
   ret = remove_memory(start_paddr,
   PAGES_PER_SECTION  PAGE_SHIFT);
   if (ret) {
 - mem-state = old_state;
 + mbs-state = old_state;
   break;
   }
   break;
   default:
   WARN(1, KERN_WARNING %s(%p, %ld) unknown action: 
 %ld\n,
 - __func__, mem, action, action);
 + __func__, mbs, action, action);
   ret = -EINVAL;
   }
 
 @@ -238,19 +252,34 @@
  static int memory_block_change_state(struct memory_block *mem,
   unsigned long to_state, unsigned long from_state_req)
  {
 + struct memory_block_section *mbs;
   int ret = 0;
 +
   mutex_lock(mem-state_mutex);
 
 - if (mem-state != from_state_req) {
 - ret = -EINVAL;
 - goto out;
 + list_for_each_entry(mbs, mem-sections, next) {
 + if (mbs-state != from_state_req)
 + continue;
 +
 + ret = memory_block_action(mbs, to_state);
 + if (ret)
 + break;
 + }
 +
 + if (ret) {
 + list_for_each_entry(mbs, mem-sections, next) {
 + if (mbs-state == from_state_req)
 + continue;
 +
 + if (memory_block_action(mbs, to_state))
 + printk(KERN_ERR Could not re-enable memory 
 +section %lx\n, mbs-phys_index);
 + }
   }

Please just use a goto here.  It's nicer looking, and much more in line
with what's there already.

...
 ===
 --- linux-2.6.orig/include/linux/memory.h 2010-07-15 08:48:41.0 
 -0500
 +++ linux-2.6/include/linux/memory.h  2010-07-15 09:54:06.0 -0500
 @@ -19,9 +19,15 @@
  #include linux/node.h
  #include linux/compiler.h
  #include linux/mutex.h
 +#include linux/list.h
 
 -struct memory_block {
 +struct memory_block_section {
 + unsigned long state;
   unsigned long phys_index;
 + struct list_head next;
 +};
 +
 +struct memory_block {
   unsigned long state;
   /*
* This serializes all state change requests.  It isn't
 @@ -34,6 +40,7 @@
   void *hw;   /* optional pointer to fw/hw data */
   int (*phys_callback)(struct memory_block *);
   struct sys_device sysdev;
 + struct list_head sections;
  };

It looks like we have state in both the memory_block and
memory_block_section.  That seems a bit confusing to me.  This also
looks like it would permit non-contiguous memory_block_sections in a
memory_block.  Is that what you intended?

If the memory_block's state was inferred to be the same as each
memory_block_section, couldn't we just

Re: [PATCH 3/5] v2 Change the mutex name in the memory_block struct

On Thu, 2010-07-15 at 13:39 -0500, Nathan Fontenot wrote:
 
 Change the name of the memory_block mutex since it is now used for
 more than just gating changes to the status of the memory sections
 covered by the memory sysfs directory.

Heh, sorry about the previous comments. :)

You should move this up to be the first in the series.

-- Dave

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 5/5] v2 Enable multiple sections per directory for ppc

On Thu, 2010-07-15 at 13:41 -0500, Nathan Fontenot wrote:
  linux-2.6.orig/arch/powerpc/platforms/pseries/hotplug-memory.c  
 2010-07-15 09:54:06.0 -0500
 +++ linux-2.6/arch/powerpc/platforms/pseries/hotplug-memory.c   2010-07-15 
 09:56:19.0 -0500
 @@ -17,6 +17,54 @@
  #include asm/pSeries_reconfig.h
  #include asm/sparsemem.h
 
 +static u32 get_memblock_size(void)
 +{
 +   struct device_node *np;
 +   unsigned int memblock_size = 0;
 + 

Please give this sucker some units.  get_memblock_size_bytes()?
get_memblock_size_in_g0ats()?


-- Dave

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Badness with the kernel version 2.6.35-rc1-git1 running on P6 box

On Fri, 2010-07-16 at 11:56 +0200, Eric Dumazet wrote:
 
  SLUB: Unable to allocate memory on node -1 (gfp=0x20)
 cache: kmalloc-16384, object size: 16384, buffer size: 16384,
 default order: 2, min order: 0
 node 0: slabs: 28, objs: 292, free: 0
  ip: page allocation failure. order:0, mode:0x8020
  Call Trace:
  [c6a0eb40] [c0011c30] .show_stack+0x6c/0x16c (unreliable)
  [c6a0ebf0] [c012129c] .__alloc_pages_nodemask+0x6a0/0x75c
  [c6a0ed70] [c01527cc] .alloc_pages_current+0xc4/0x104
  [c6a0ee10] [c011fca4] .__get_free_pages+0x18/0x90
  [c6a0ee90] [c04f7058] .ehea_get_stats+0x4c/0x1bc
  [c6a0ef30] [c05a0a04] .dev_get_stats+0x38/0x64
  [c6a0efc0] [c05b456c] .rtnl_fill_ifinfo+0x35c/0x85c
  [c6a0f150] [c05b5920] .rtmsg_ifinfo+0x164/0x204
  [c6a0f210] [c05a6d6c] .dev_change_flags+0x4c/0x7c
  [c6a0f2a0] [c05b50b4] .do_setlink+0x31c/0x750
  [c6a0f3b0] [c05b6724] .rtnl_newlink+0x388/0x618
  [c6a0f5f0] [c05b6350] .rtnetlink_rcv_msg+0x268/0x2b4
  [c6a0f6a0] [c05cfdc0] .netlink_rcv_skb+0x74/0x108
  [c6a0f730] [c05b60c4] .rtnetlink_rcv+0x38/0x5c
  [c6a0f7c0] [c05cf8c8] .netlink_unicast+0x318/0x3f4
  [c6a0f890] [c05d05b4] .netlink_sendmsg+0x2d0/0x310
  [c6a0f970] [c058e1e8] .sock_sendmsg+0xd4/0x110
  [c6a0fb50] [c058e514] .SyS_sendmsg+0x1f4/0x288
  [c6a0fd70] [c058c2b8] .SyS_socketcall+0x214/0x280
  [c6a0fe30] [c00085b4] syscall_exit+0x0/0x40
  Mem-Info:
  Node 0 DMA per-cpu:
  CPU0: hi:0, btch:   1 usd:   0
  CPU1: hi:0, btch:   1 usd:   0
  CPU2: hi:0, btch:   1 usd:   0
  CPU3: hi:0, btch:   1 usd:   0
  
  The mainline 2.6.35-rc5 worked fine.
 
 Maybe you were lucky with 2.6.35-rc5
 
 Anyway ehea should not use GFP_ATOMIC in its ehea_get_stats() method,
 called in process context, but GFP_KERNEL.
 
 Another patch is needed for ehea_refill_rq_def() as well.

You're right that this is abusing GFP_ATOMIC.

But is, this is just a normal GFP_ATOMIC allocation failure?  SLUB:
Unable to allocate memory on node -1 seems like a somewhat
inappropriate error message for that.  

It isn't immediately obvious where the -1 is coming from.  Does it truly
mean allocate from any node here, or is that a buglet in and of
itself?

-- Dave

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas
catalin.mari...@arm.com wrote:
 On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote:
 - It still doesn't resolve dependencies.  A solver would help with this.
   For the time being I work around the problem by running the generated
   config through 'oldconfig' and looking for differences.  If the files
   differ (ignoring comments and generateconfig_* options) after oldconfig,
   then the board_defconfig target returns a failure.  (but leaves the
   new .config intact so the user can resolve it with menuconfig).  This
   way at least the user is told when a Kconfig fragment is invalid.

 It's not a solver but I'm pushing a patch to warn on selecting symbols
 with unmet dependencies so that you can select further symbols (manual
 solving). The patch is in linux-next but you also can grab it from:

 http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-2.6-cm.git;a=commitdiff_plain;h=5d87db2d2a332784bbf2b1ec3e141486f4d41d6f

sfr and I were talking about your patch the other day.  Just warning
on incomplete dependencies is enough to make it actually workable for
me (without my ugly post-processing step).  I was very happy to hear
that it is in linux-next.

Last missing piece is being able to do select FOO = n, which Stephen
is currently working on.

g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: cpm_uart_console_write() stuck in waiting for transmitter fifo ready

2010-07-16 Thread Scott Wood

On Fri, 16 Jul 2010 00:12:21 -0700
Shawn Jin shawnx...@gmail.com wrote:

  Why would the TxBD be filled with all 0xF? Would it be possible that
  the bdbase actually points somewhere else other than the TxBD?
 
  The virtual address 0xfddfa000 is mapped to 0xfa202000. I suspect that
  the TxBD of my MPC870 may not start at 0xfa202020.
 
  I notice that for adder875, ep88xc and mpc885ads, the muram data's reg
  = 0 0x1c00 but for mgsuvd, its reg = 0x800 0x1800. How does the
  kernel use muram for 885 family SoCs? How much muram should be
  reserved for data?
 
  My RCCR=0x1, meaning the first 512B is for microcode. So the data and
  the TxBD should really be starting at 0xfa202200? Then my muram data's
  reg should be 0x200 ?? What size shall I specify?
 
 After the muram data's reg is changed to 0x200 0x1a00, the cpm_uart
 driver works properly and the kernel messages are printed on the
 serial port.

The muram node is supposed to show the portions of DPRAM that are
usable by the OS.  If some portion has been taken up by microcode (or
anything else not under the OS's control) before the OS has started,
then it must be excluded from the muram node.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

2010-07-16 Thread Linus Torvalds

On Fri, Jul 16, 2010 at 11:07 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:

 I thought Linus' idea was to use:

 KBUILD_KCONFIG=file make allnoconfig

See an earlier reply - that is indeed what I suggested, and yes, it
avoids the need to be able to unselect things.

However, it turns out that even then you do want to extend the Kconfig
language with the ability to select particular values. Not for boolean
(or even tristate things), but for things that select an integer or
string value etc.

So the select OPTION=xyz syntax ends up being a good thing even for
the -n (allnoconfig) case too.

And while I think the allnoconfig model has some advantages (the
Kconfig input file ends up being independent of the default values),
that very fact ends up being a disadvantage too (the Kconfig input
file likely ends up being larger, since _hopefully_ the defaults are
sane).

So I'm not at all married to the allnoconfig model. It's one way of
doing things, but I think the argument that we should start with the
defaults and modify those instead is not an invalid one.

 Linus
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

On Fri, Jul 16, 2010 at 12:07 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Fri, Jul 16, 2010 at 11:57:55AM -0600, Grant Likely wrote:
 Last missing piece is being able to do select FOO = n, which Stephen
 is currently working on.

 I thought Linus' idea was to use:

 KBUILD_KCONFIG=file make allnoconfig

That was more a prototype of the idea; but it's a pretty cumbersome
user interface.  :-)  By changing the makefile to look for kconfig
fragments in the configs directory, the user interface for choosing a
config remains exactly the same.

As for the allnoconfig bit

 in which case any option which would be presented to the user which hasn't
 been selected by 'file' ends up being set to n.  That means there's no
 need for a special select FOO=n construct.

...Linus chimed in on this that he doesn't actually care much.  I
think defconfig with an empty initial config file makes a lot more
sense than allnoconfig so that we're using the default values from the
normal Kconfig files.

 See one of Linus' replies on June 3:
 Message-ID: alpine.lfd.2.00.1006031317410.8...@i5.linux-foundation.org

See this response:
Message-ID: aanlktik-qcxfnjma3j28b9h27uajocdhthtgz99zk...@mail.gmail.com

http://news.gmane.org/find-root.php?message_id=%3cAANLkTik%2dQCXFnjma3J28B9h27uajOcDhthTGz99zKgVi%40mail.gmail.com%3e

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

On Fri, 16 Jul 2010, Grant Likely wrote:

On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote:
- It still doesn't resolve dependencies. A solver would help with this.
For the time being I work around the problem by running the generated
config through 'oldconfig' and looking for differences. If the files
differ (ignoring comments and generateconfig_* options) after oldconfig,
then the board_defconfig target returns a failure. (but leaves the
new .config intact so the user can resolve it with menuconfig). This
way at least the user is told when a Kconfig fragment is invalid.

It's not a solver but I'm pushing a patch to warn on selecting symbols
with unmet dependencies so that you can select further symbols (manual
solving). The patch is in linux-next but you also can grab it from:

http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-2.6-cm.git;a=commitdiff_plain;h=5d87db2d2a332784bbf2b1ec3e141486f4d41d6f

sfr and I were talking about your patch the other day. Just warning
on incomplete dependencies is enough to make it actually workable for
me (without my ugly post-processing step). I was very happy to hear
that it is in linux-next.

Last missing piece is being able to do select FOO = n, which Stephen
is currently working on.

Instead of (or in addition to) warning for incomplete
dependencies, I'd much prefer if the prerequisites were recursively
selected automatically. This way if some options are moved inside a
submenu at some point with a config symbol for that subcategory
(e.g. CONFIG_NETDEV_1000), or if the subsystem is reorganized into
submodules that are required for some driver to work, then my
config will still be fine.

For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be
smart enough to notice and automatically enable CONFIG_MTD and
CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.

Nicolas
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

On Fri, Jul 16, 2010 at 12:19 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Fri, 16 Jul 2010, Grant Likely wrote:

http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-2.6-cm.git;a=commitdiff_plain;h=5d87db2d2a332784bbf2b1ec3e141486f4d41d6f

Last missing piece is being able to do select FOO = n, which Stephen
is currently working on.

I fully agree. However, the warnings make the system work now while
we wait for a full solver to be implemented.

g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/5] v2 Split the memory_block structure

On 07/16/2010 12:15 PM, Dave Hansen wrote:
 On Thu, 2010-07-15 at 13:37 -0500, Nathan Fontenot wrote:
 @@ -123,13 +130,20 @@
  static ssize_t show_mem_removable(struct sys_device *dev,
  struct sysdev_attribute *attr, char *buf)
  {
 +struct memory_block *mem;
 +struct memory_block_section *mbs;
  unsigned long start_pfn;
 -int ret;
 -struct memory_block *mem =
 -container_of(dev, struct memory_block, sysdev);
 +int ret = 1;
 +
 +mem = container_of(dev, struct memory_block, sysdev);
 +mutex_lock(mem-state_mutex);

 -start_pfn = section_nr_to_pfn(mem-phys_index);
 -ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
 +list_for_each_entry(mbs, mem-sections, next) {
 +start_pfn = section_nr_to_pfn(mbs-phys_index);
 +ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
 +}
 +
 +mutex_unlock(mem-state_mutex);
  return sprintf(buf, %d\n, ret);
  }
 
 Now that the state_mutex is getting used for other stuff, should we
 just make it mutex?
 
 @@ -182,16 +196,16 @@
   * OK to have direct references to sparsemem variables in here.
   */
  static int
 -memory_block_action(struct memory_block *mem, unsigned long action)
 +memory_block_action(struct memory_block_section *mbs, unsigned long action)
  {
  int i;
  unsigned long psection;
  unsigned long start_pfn, start_paddr;
  struct page *first_page;
  int ret;
 -int old_state = mem-state;
 +int old_state = mbs-state;

 -psection = mem-phys_index;
 +psection = mbs-phys_index;
  first_page = pfn_to_page(psection  PFN_SECTION_SHIFT);

  /*
 @@ -217,18 +231,18 @@
  ret = online_pages(start_pfn, PAGES_PER_SECTION);
  break;
  case MEM_OFFLINE:
 -mem-state = MEM_GOING_OFFLINE;
 +mbs-state = MEM_GOING_OFFLINE;
  start_paddr = page_to_pfn(first_page)  PAGE_SHIFT;
  ret = remove_memory(start_paddr,
  PAGES_PER_SECTION  PAGE_SHIFT);
  if (ret) {
 -mem-state = old_state;
 +mbs-state = old_state;
  break;
  }
  break;
  default:
  WARN(1, KERN_WARNING %s(%p, %ld) unknown action: 
 %ld\n,
 -__func__, mem, action, action);
 +__func__, mbs, action, action);
  ret = -EINVAL;
  }

 @@ -238,19 +252,34 @@
  static int memory_block_change_state(struct memory_block *mem,
  unsigned long to_state, unsigned long from_state_req)
  {
 +struct memory_block_section *mbs;
  int ret = 0;
 +
  mutex_lock(mem-state_mutex);

 -if (mem-state != from_state_req) {
 -ret = -EINVAL;
 -goto out;
 +list_for_each_entry(mbs, mem-sections, next) {
 +if (mbs-state != from_state_req)
 +continue;
 +
 +ret = memory_block_action(mbs, to_state);
 +if (ret)
 +break;
 +}
 +
 +if (ret) {
 +list_for_each_entry(mbs, mem-sections, next) {
 +if (mbs-state == from_state_req)
 +continue;
 +
 +if (memory_block_action(mbs, to_state))
 +printk(KERN_ERR Could not re-enable memory 
 +   section %lx\n, mbs-phys_index);
 +}
  }
 
 Please just use a goto here.  It's nicer looking, and much more in line
 with what's there already.

Not sure if I follow on where you want the goto.  If you mean after the
if (memory_block_action())...  I purposely did not have a goto here.
Since this is in the recovery path I wanted to make sure we tried to return
every memory section to the original state.

 
 ...
 ===
 --- linux-2.6.orig/include/linux/memory.h2010-07-15 08:48:41.0 
 -0500
 +++ linux-2.6/include/linux/memory.h 2010-07-15 09:54:06.0 -0500
 @@ -19,9 +19,15 @@
  #include linux/node.h
  #include linux/compiler.h
  #include linux/mutex.h
 +#include linux/list.h

 -struct memory_block {
 +struct memory_block_section {
 +unsigned long state;
  unsigned long phys_index;
 +struct list_head next;
 +};
 +
 +struct memory_block {
  unsigned long state;
  /*
   * This serializes all state change requests.  It isn't
 @@ -34,6 +40,7 @@
  void *hw;   /* optional pointer to fw/hw data */
  int (*phys_callback)(struct memory_block *);
  struct sys_device sysdev;
 +struct list_head sections;
  };
 
 It looks like we have state in both the memory_block and
 memory_block_section.  That seems a bit confusing to me.

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

2010-07-16 Thread Russell King - ARM Linux

On Fri, Jul 16, 2010 at 11:57:55AM -0600, Grant Likely wrote:
 Last missing piece is being able to do select FOO = n, which Stephen
 is currently working on.

I thought Linus' idea was to use:

KBUILD_KCONFIG=file make allnoconfig

in which case any option which would be presented to the user which hasn't
been selected by 'file' ends up being set to n.  That means there's no
need for a special select FOO=n construct.

See one of Linus' replies on June 3:
Message-ID: alpine.lfd.2.00.1006031317410.8...@i5.linux-foundation.org

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

2010-07-16 Thread Russell King - ARM Linux

On Fri, Jul 16, 2010 at 02:19:31PM -0400, Nicolas Pitre wrote:
 For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be 
 smart enough to notice and automatically enable CONFIG_MTD and 
 CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.

How do you sort out something like this:

config FOO
bool Foo
depends on (A  B) || C

Do you enable A and B, A, B and C or just C?

Bear in mind that A could be 'X86', 'M68K' or any other arch specific
symbol.

I prefer the warning method because it prompts you to investigate what's
changed and sort out the problem by ensuring that the appropriate symbols
are also selected.  The automatic selection of dependencies method carries
the risk that it'll do the wrong thing with the above scenario.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

On Fri, 16 Jul 2010, Grant Likely wrote:
 On Fri, Jul 16, 2010 at 12:19 PM, Nicolas Pitre n...@fluxnic.net wrote:
  For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be
  smart enough to notice and automatically enable CONFIG_MTD and
  CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.
 
 I fully agree.  However, the warnings make the system work now while
 we wait for a full solver to be implemented.

Why can't the tool just _select_ the option it is warning about when a 
dependency is not met?  That shouldn't require a full solver.


Nicolas
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/5] v2 Split the memory_block structure

On Fri, 2010-07-16 at 13:23 -0500, Nathan Fontenot wrote:
  If the memory_block's state was inferred to be the same as each
  memory_block_section, couldn't we just keep a start and end phys_index
  in the memory_block, and get away from having memory_block_sections at
  all?
 
 Oooohhh... I like.  Looking at the code it appears this is possible.  I'll
 try this out and include it in the next version of the patch.
 
 Do you think we need to add an additional file to each memory block directory
 to indicate the number of memory sections in the memory block that are 
 actually
 present? 

I think it's easiest to just say that each 'memory_block' can only hold
contiguous 'memory_block_sections', and we give either the start/end or
start/length pairs.  It gets a lot more complicated if we have to deal
with lots of holes.

I can just see the hardware designers reading this thread, with their
Dr. Evil laughs trying to come up with a reason to give us a couple of
terabytes of RAM with only every-other 16MB area populated. :)  

-- Dave

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

On Fri, 16 Jul 2010, Russell King - ARM Linux wrote:

 On Fri, Jul 16, 2010 at 02:19:31PM -0400, Nicolas Pitre wrote:
  For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be 
  smart enough to notice and automatically enable CONFIG_MTD and 
  CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.
 
 How do you sort out something like this:
 
 config FOO
   bool Foo
   depends on (A  B) || C

DOH.


Nicolas
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/5] v2 Split the memory_block structure

On Fri, 2010-07-16 at 13:23 -0500, Nathan Fontenot wrote:
  -if (mem-state != from_state_req) {
  -ret = -EINVAL;
  -goto out;
  +list_for_each_entry(mbs, mem-sections, next) {
  +if (mbs-state != from_state_req)
  +continue;
  +
  +ret = memory_block_action(mbs, to_state);
  +if (ret)
  +break;
  +}
  +
  +if (ret) {
  +list_for_each_entry(mbs, mem-sections, next) {
  +if (mbs-state == from_state_req)
  +continue;
  +
  +if (memory_block_action(mbs, to_state))
  +printk(KERN_ERR Could not re-enable memory 
  +   section %lx\n, mbs-phys_index);
  +}
   }
  
  Please just use a goto here.  It's nicer looking, and much more in line
  with what's there already.
 
 Not sure if I follow on where you want the goto.  If you mean after the
 if (memory_block_action())...  I purposely did not have a goto here.
 Since this is in the recovery path I wanted to make sure we tried to return
 every memory section to the original state. 

Looking at it a little closer, I see what you're doing now.

First of all, should memory_block_action() get a new name since it isn
not taking 'memory_block_section's?

The thing I would have liked to see is to have that error handling block
out of the way a bit.  But, the function is small, and there's not _too_
much code in there, so what you have is probably the best way to do it.

Minor nit: Please pull the memory_block_action() out of the if() and do
the:

  +ret = memory_block_action(mbs, to_state);
  +if (ret)
  +break;

thing like above.  It makes it much more obvious that the loop is
related to the top one.  I was thinking if it made sense to have a
helper function to go through and do that list walk, so you could do:

ret = set_all_states(mem-sections, to_state);
if (ret)
set_all_states(mem-sections, old_state);

But I think you'd need to pass in a bit more information, so it probably
isn't worth doing that, either.

-- Dave

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

2010-07-16 Thread Linus Torvalds

On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre n...@fluxnic.net wrote:

 DOH.

Well, it's possible that the correct approach is a mixture.

Automatically do the trivial cases (recursive selects, dependencies
that are simple or of the form x  y etc), and warn about the cases
that aren't trivial (where not trivial may not necessarily be about
fundamentally ambiguous ones, but just complex enough that I won't
even try).

Maybe a full solver is unnecessary, for example, but just a simple
automatically enable the direct dependencies and scream when it's not
simple any more would take care of 99% of the common cases, and then
warn when it needs some manual help.

So it's not a strict one or the other issue. The solution could be
some of both.

 Linus
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

On Fri, Jul 16, 2010 at 12:30 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
 On Fri, Jul 16, 2010 at 02:19:31PM -0400, Nicolas Pitre wrote:
 For example, if I want CONFIG_MTD_CMDLINE_PARTS=y, the system may be
 smart enough to notice and automatically enable CONFIG_MTD and
 CONFIG_MTD_PARTITIONS without having to carry those in the defconfig.

 How do you sort out something like this:

 config FOO
        bool Foo
        depends on (A  B) || C

 Do you enable A and B, A, B and C or just C?

 Bear in mind that A could be 'X86', 'M68K' or any other arch specific
 symbol.

 I prefer the warning method because it prompts you to investigate what's
 changed and sort out the problem by ensuring that the appropriate symbols
 are also selected.  The automatic selection of dependencies method carries
 the risk that it'll do the wrong thing with the above scenario.

Good point.

g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Badness with the kernel version 2.6.35-rc1-git1 running on P6 box

2010-07-16 Thread David Rientjes

On Fri, 16 Jul 2010, Dave Hansen wrote:

   SLUB: Unable to allocate memory on node -1 (gfp=0x20)
  cache: kmalloc-16384, object size: 16384, buffer size: 16384,
  default order: 2, min order: 0
  node 0: slabs: 28, objs: 292, free: 0
   ip: page allocation failure. order:0, mode:0x8020
   Call Trace:
   [c6a0eb40] [c0011c30] .show_stack+0x6c/0x16c (unreliable)
   [c6a0ebf0] [c012129c] .__alloc_pages_nodemask+0x6a0/0x75c
   [c6a0ed70] [c01527cc] .alloc_pages_current+0xc4/0x104
   [c6a0ee10] [c011fca4] .__get_free_pages+0x18/0x90
   [c6a0ee90] [c04f7058] .ehea_get_stats+0x4c/0x1bc
   [c6a0ef30] [c05a0a04] .dev_get_stats+0x38/0x64
   [c6a0efc0] [c05b456c] .rtnl_fill_ifinfo+0x35c/0x85c
   [c6a0f150] [c05b5920] .rtmsg_ifinfo+0x164/0x204
   [c6a0f210] [c05a6d6c] .dev_change_flags+0x4c/0x7c
   [c6a0f2a0] [c05b50b4] .do_setlink+0x31c/0x750
   [c6a0f3b0] [c05b6724] .rtnl_newlink+0x388/0x618
   [c6a0f5f0] [c05b6350] .rtnetlink_rcv_msg+0x268/0x2b4
   [c6a0f6a0] [c05cfdc0] .netlink_rcv_skb+0x74/0x108
   [c6a0f730] [c05b60c4] .rtnetlink_rcv+0x38/0x5c
   [c6a0f7c0] [c05cf8c8] .netlink_unicast+0x318/0x3f4
   [c6a0f890] [c05d05b4] .netlink_sendmsg+0x2d0/0x310
   [c6a0f970] [c058e1e8] .sock_sendmsg+0xd4/0x110
   [c6a0fb50] [c058e514] .SyS_sendmsg+0x1f4/0x288
   [c6a0fd70] [c058c2b8] .SyS_socketcall+0x214/0x280
   [c6a0fe30] [c00085b4] syscall_exit+0x0/0x40
   Mem-Info:
   Node 0 DMA per-cpu:
   CPU0: hi:0, btch:   1 usd:   0
   CPU1: hi:0, btch:   1 usd:   0
   CPU2: hi:0, btch:   1 usd:   0
   CPU3: hi:0, btch:   1 usd:   0
   
   The mainline 2.6.35-rc5 worked fine.
  
  Maybe you were lucky with 2.6.35-rc5
  
  Anyway ehea should not use GFP_ATOMIC in its ehea_get_stats() method,
  called in process context, but GFP_KERNEL.
  
  Another patch is needed for ehea_refill_rq_def() as well.
 
 You're right that this is abusing GFP_ATOMIC.
 
 But is, this is just a normal GFP_ATOMIC allocation failure?  SLUB:
 Unable to allocate memory on node -1 seems like a somewhat
 inappropriate error message for that.  
 

The slub message is seperate and doesn't generate a call trace, even 
though it is a (minimum) order-0 GFP_ATOMIC allocation as well.  The page 
allocation failure is seperate instance that is calling the page 
allocator, not the slab allocator.

 It isn't immediately obvious where the -1 is coming from.  Does it truly
 mean allocate from any node here, or is that a buglet in and of
 itself?
 

Yes, slub uses -1 to indicate that the allocation need not come from a 
specific node.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

2010-07-16 Thread Arnd Bergmann

On Friday 16 July 2010 19:57:55 Grant Likely wrote:
 On Fri, Jul 16, 2010 at 10:03 AM, Catalin Marinas
 catalin.mari...@arm.com wrote:
  On Wed, 2010-07-14 at 00:04 +0100, Grant Likely wrote:
 
 sfr and I were talking about your patch the other day.  Just warning
 on incomplete dependencies is enough to make it actually workable for
 me (without my ugly post-processing step).  I was very happy to hear
 that it is in linux-next.
 
 Last missing piece is being able to do select FOO = n, which Stephen
 is currently working on.

Are there a lot of symbols for which this is needed? If there is only
a handful, you could work around this by selectively adding

config FOO
bool foo
default !FOO_DISABLE

config FOO_DISABLE
def_bool n


Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

2010-07-16 Thread Catalin Marinas

On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote:
 On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre n...@fluxnic.net wrote:
 
  DOH.
 
 Well, it's possible that the correct approach is a mixture.
 
 Automatically do the trivial cases (recursive selects, dependencies
 that are simple or of the form x  y etc), and warn about the cases
 that aren't trivial (where not trivial may not necessarily be about
 fundamentally ambiguous ones, but just complex enough that I won't
 even try).

There is still a risk with this approach when the Kconfig isn't entirely
correct. For example, on ARM we have (I pushed a patch already):

config CPU_32v6K
depends on CPU_V6

config CPU_V7
select CPU_32v6K

In this simple approach, we end up selecting CPU_V6 when we only need
CPU_V7. There other places like this in the kernel.

Of course, kbuild could still warn but if people rely on this feature to
select options automatically I suspect they would ignore the warnings.

-- 
Catalin

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

2010-07-16 Thread Arnd Bergmann

On Friday 16 July 2010 20:46:17 Linus Torvalds wrote:
 Maybe a full solver is unnecessary, for example, but just a simple
 automatically enable the direct dependencies and scream when it's not
 simple any more would take care of 99% of the common cases, and then
 warn when it needs some manual help.

I think the recursion should also be limited to cases where the
dependency is a valid selectable option, i.e. not for

# this architecture does not support MMIO
config HAS_IOMEM 
def_bool 'n'

config PCI
bool PCI Device drivers
depends on HAS_IOMEM

config FOO
tristate Some device driver
depends on PCI

In this case, it would be straightforward for the solver to enable PCI
for when something selects CONFIG_FOO, but it should print a warning
if this is attempted while HAS_IOMEM is unconditionally disabled,
since that puts it into the not simple category.

Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2] edac: mpc85xx: Add support for new MPCxxx/Pxxxx EDAC controllers

2010-07-16 Thread Scott Wood

On Thu, 15 Jul 2010 22:25:07 +0400
Anton Vorontsov avoront...@mvista.com wrote:

 Simply add proper IDs into the device table.
 
 Signed-off-by: Anton Vorontsov avoront...@mvista.com
 ---
 
 It appears that the driver has two device ID tables. :-)
 So, my previous attempt enabled only half of the functionality.
 
 Andrew,
 
 Can you please replace
 
   edac-mpc85xx-add-support-for-mpc8569-edac-controllers.patch
 
 with this patch? It also adds some more IDs for the newer chips.
 
 Thanks!
 
  drivers/edac/mpc85xx_edac.c |8 
  1 files changed, 8 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
 index 52ca09b..3820879 100644
 --- a/drivers/edac/mpc85xx_edac.c
 +++ b/drivers/edac/mpc85xx_edac.c
 @@ -646,8 +646,12 @@ static struct of_device_id mpc85xx_l2_err_of_match[] = {
   { .compatible = fsl,mpc8555-l2-cache-controller, },
   { .compatible = fsl,mpc8560-l2-cache-controller, },
   { .compatible = fsl,mpc8568-l2-cache-controller, },
 + { .compatible = fsl,mpc8569-l2-cache-controller, },
   { .compatible = fsl,mpc8572-l2-cache-controller, },
 + { .compatible = fsl,p1020-l2-cache-controller, },
 + { .compatible = fsl,p1021-l2-cache-controller, },
   { .compatible = fsl,p2020-l2-cache-controller, },
 + { .compatible = fsl,p4080-l2-cache-controller, },

L2 on the p4080 is quite different from those other chips.  It's part
of the core, controlled by SPRs.

-Scott

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
 On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote:
 On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre n...@fluxnic.net wrote:
 
  DOH.

 Well, it's possible that the correct approach is a mixture.

 Automatically do the trivial cases (recursive selects, dependencies
 that are simple or of the form x  y etc), and warn about the cases
 that aren't trivial (where not trivial may not necessarily be about
 fundamentally ambiguous ones, but just complex enough that I won't
 even try).

 There is still a risk with this approach when the Kconfig isn't entirely
 correct. For example, on ARM we have (I pushed a patch already):

 config CPU_32v6K
        depends on CPU_V6

 config CPU_V7
        select CPU_32v6K

 In this simple approach, we end up selecting CPU_V6 when we only need
 CPU_V7. There other places like this in the kernel.

 Of course, kbuild could still warn but if people rely on this feature to
 select options automatically I suspect they would ignore the warnings.

In my first patch, I made Kconfig problems errors instead of warnings.
 That would prevent people from ignoring them.

g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

On Fri, 16 Jul 2010, Grant Likely wrote:

 On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas
 catalin.mari...@arm.com wrote:
  On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote:
  On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre n...@fluxnic.net wrote:
  
   DOH.
 
  Well, it's possible that the correct approach is a mixture.
 
  Automatically do the trivial cases (recursive selects, dependencies
  that are simple or of the form x  y etc), and warn about the cases
  that aren't trivial (where not trivial may not necessarily be about
  fundamentally ambiguous ones, but just complex enough that I won't
  even try).
 
  There is still a risk with this approach when the Kconfig isn't entirely
  correct. For example, on ARM we have (I pushed a patch already):
 
  config CPU_32v6K
         depends on CPU_V6
 
  config CPU_V7
         select CPU_32v6K
 
  In this simple approach, we end up selecting CPU_V6 when we only need
  CPU_V7. There other places like this in the kernel.
 
  Of course, kbuild could still warn but if people rely on this feature to
  select options automatically I suspect they would ignore the warnings.
 
 In my first patch, I made Kconfig problems errors instead of warnings.
  That would prevent people from ignoring them.

ACK.


Nicolas
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

On Fri, Jul 16, 2010 at 2:29 PM, Nicolas Pitre n...@fluxnic.net wrote:
 On Fri, 16 Jul 2010, Grant Likely wrote:

 On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas
 catalin.mari...@arm.com wrote:
  On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote:
  On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre n...@fluxnic.net wrote:
  
   DOH.
 
  Well, it's possible that the correct approach is a mixture.
 
  Automatically do the trivial cases (recursive selects, dependencies
  that are simple or of the form x  y etc), and warn about the cases
  that aren't trivial (where not trivial may not necessarily be about
  fundamentally ambiguous ones, but just complex enough that I won't
  even try).
 
  There is still a risk with this approach when the Kconfig isn't entirely
  correct. For example, on ARM we have (I pushed a patch already):
 
  config CPU_32v6K
         depends on CPU_V6
 
  config CPU_V7
         select CPU_32v6K
 
  In this simple approach, we end up selecting CPU_V6 when we only need
  CPU_V7. There other places like this in the kernel.
 
  Of course, kbuild could still warn but if people rely on this feature to
  select options automatically I suspect they would ignore the warnings.

 In my first patch, I made Kconfig problems errors instead of warnings.
  That would prevent people from ignoring them.

 ACK.

It would also flush out any current Kconfig dependency issues.

g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [RFC PATCH] Kconfig: Enable Kconfig fragments to be used for defconfig

2010-07-16 Thread Catalin Marinas

On Fri, 2010-07-16 at 21:17 +0100, Grant Likely wrote:
 On Fri, Jul 16, 2010 at 2:09 PM, Catalin Marinas
 catalin.mari...@arm.com wrote:
  On Fri, 2010-07-16 at 19:46 +0100, Linus Torvalds wrote:
  On Fri, Jul 16, 2010 at 11:40 AM, Nicolas Pitre n...@fluxnic.net wrote:
  
   DOH.
 
  Well, it's possible that the correct approach is a mixture.
 
  Automatically do the trivial cases (recursive selects, dependencies
  that are simple or of the form x  y etc), and warn about the cases
  that aren't trivial (where not trivial may not necessarily be about
  fundamentally ambiguous ones, but just complex enough that I won't
  even try).
 
  There is still a risk with this approach when the Kconfig isn't entirely
  correct. For example, on ARM we have (I pushed a patch already):
 
  config CPU_32v6K
 depends on CPU_V6
 
  config CPU_V7
 select CPU_32v6K
 
  In this simple approach, we end up selecting CPU_V6 when we only need
  CPU_V7. There other places like this in the kernel.
 
  Of course, kbuild could still warn but if people rely on this feature to
  select options automatically I suspect they would ignore the warnings.
 
 In my first patch, I made Kconfig problems errors instead of warnings.
  That would prevent people from ignoring them.

My point was that if we allow kbuild to select dependencies
automatically (as per Nico's initial suggestion, followed up by Linus),
in the above situation CPU_V7 would trigger the selection of CPU_V6 and
I don't want this. If we rely on such automatic selection of the
depends on options, we can't make the warnings be errors.

-- 
Catalin

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 1/2] Remove REDWOOD_[456] config options and conditional code

2010-07-16 Thread David Miller

From: Josh Boyer jwbo...@linux.vnet.ibm.com
Date: Fri, 16 Jul 2010 10:20:55 -0400

 On Fri, Jul 16, 2010 at 02:29:02PM +0200, Christian Dietrich wrote:
The config options for REDWOOD_[456] were commented out in the powerpc
Kconfig. The ifdefs referencing this options therefore are dead and all
references to this can be removed (Also dependencies in other KConfig
files).

Signed-off-by: Christian Dietrich qy03f...@stud.informatik.uni-erlangen.de
Signed-off-by: Christoph Egger sicce...@cs.fau.de

 This seems fine with me.

 The only question is which tree it coms through.  I'm happy to take it
 in via mine if the netdev and MTD people are fine with that.  Otherwise,
 my ack is below.

 Acked-by: Josh Boyer jwbo...@linux.vnet.ibm.com

Please take it:

Acked-by: David S. Miller da...@davemloft.net
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: hi, i have two flashs, but my kernel can only find one , how can i write the dts?