* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: Michel Dänzer @ 2010-07-13 17:22 UTC (permalink / raw)
To: jjDaNiMoTh; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <AANLkTikR0HRoBawbUJyS_cEkhEu9Sj6q8hR2F0v6CLDK@mail.gmail.com>
On Die, 2010-07-13 at 19:05 +0200, jjDaNiMoTh wrote:=20
>=20
> So, I've now the acceleration. The main problem was radeon.agpmode,
> setting it to -1 (and removing all files in xorg.conf.d related to
> radeon) fixes all issue (also the freeze on glxgears). Now I have
> ~1500 FPS, and I'm fine with it (before I got 100 FPS).
>=20
> I get the acceleration also with a non-KMS capable kernel, so I think
> we got the point. I will add the option to modprobe.conf for archPPC.
Note that e.g. on my PowerBook agpmode=3D1 works (mostly) stable, and if
AGP works it performs significantly better than PCI.
> I tried a program which use a lot opengl, the only thing I see is
> ERROR: GL error 1282
> ERROR: Ignoring 1 openGL errors
Something the app does causes Mesa to raise a GL_INVALID_OPERATION
error. This may be a bug in the app or in Mesa.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: jjDaNiMoTh @ 2010-07-13 17:05 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <1279037396.515.19.camel@thor.local>
2010/7/13 Michel D=C3=A4nzer <michel@daenzer.net>:
[cut]
> Are you looking at the right log file, not the one from the new X server
> after the reboot?
Yes, I looked to .old, when referring to Xorg.0.log.
> Maybe you could post the full dmesg, Xorg.0.log and X server stderr
> output (should be captured in the gdm/kdm log file) from trying with
> modeset=3D1.
>
>> At this time, I think it isn't a kernel problem, am I right?
>
> With modeset=3D1 it most likely is a kernel (configuration) problem.
So, I've now the acceleration. The main problem was radeon.agpmode,
setting it to -1 (and removing all files in xorg.conf.d related to
radeon) fixes all issue (also the freeze on glxgears). Now I have
~1500 FPS, and I'm fine with it (before I got 100 FPS).
I get the acceleration also with a non-KMS capable kernel, so I think
we got the point. I will add the option to modprobe.conf for archPPC.
I tried a program which use a lot opengl, the only thing I see is
ERROR: GL error 1282
ERROR: Ignoring 1 openGL errors
but the topic-error is fixed.
Thank you.
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: Michel Dänzer @ 2010-07-13 16:09 UTC (permalink / raw)
To: jjDaNiMoTh; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <AANLkTik154EFPIzMZy5v-Mj6mhWt-hCaFYvLPi5oLWFD@mail.gmail.com>
On Die, 2010-07-13 at 18:02 +0200, jjDaNiMoTh wrote:=20
> 2010/7/13 Michel D=C3=A4nzer <michel@daenzer.net>:
> > What does the log file contain with modeset=3D1?
>=20
> We have no message, after the X.org freeze.
>=20
> messages.log:
> [...]
> Jul 13 17:11:01 jim kernel: [drm] Num pipes: 1
> Jul 13 17:13:39 jim kernel: Using PowerMac machine description
>=20
> (we have rebooted)
>=20
> In Xorg.0.log there aren't information after the crash, only a right star=
tup.
Are you looking at the right log file, not the one from the new X server
after the reboot?
Maybe you could post the full dmesg, Xorg.0.log and X server stderr
output (should be captured in the gdm/kdm log file) from trying with
modeset=3D1.
> At this time, I think it isn't a kernel problem, am I right?
With modeset=3D1 it most likely is a kernel (configuration) problem.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: jjDaNiMoTh @ 2010-07-13 16:02 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <1279033177.515.16.camel@thor.local>
2010/7/13 Michel D=C3=A4nzer <michel@daenzer.net>:
[cut]
> Could be a GPU lockup again, possibly due to still using AGP 4x with
> modeset=3D0.
[cut]
> What does the log file contain with modeset=3D1?
We have no message, after the X.org freeze.
messages.log:
[...]
Jul 13 17:11:01 jim kernel: [drm] Num pipes: 1
Jul 13 17:13:39 jim kernel: Using PowerMac machine description
(we have rebooted)
In Xorg.0.log there aren't information after the crash, only a right startu=
p.
Maybe I could try to connect via ssh and see if there are some
informations which aren't written to disk...
At this time, I think it isn't a kernel problem, am I right? Also, we
have the same problem (freeze in glxgears or other program using glx)
both from normal user and from root.
Thank you again
^ permalink raw reply
* Re: [PATCH 1/7] Split the memory_block structure
From: Nathan Fontenot @ 2010-07-13 15:59 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4C3C718C.6080402@linux.vnet.ibm.com>
On 07/13/2010 09:00 AM, Brian King wrote:
> On 07/12/2010 10:42 AM, Nathan Fontenot wrote:
>> @@ -123,13 +130,20 @@
>> static ssize_t show_mem_removable(struct sys_device *dev,
>> struct sysdev_attribute *attr, char *buf)
>> {
>> - unsigned long start_pfn;
>> - int ret;
>> - struct memory_block *mem =
>> - container_of(dev, struct memory_block, sysdev);
>> + struct list_head *pos, *tmp;
>> + struct memory_block *mem;
>> + int ret = 1;
>> +
>> + mem = container_of(dev, struct memory_block, sysdev);
>> + list_for_each_safe(pos, tmp, &mem->sections) {
>> + struct memory_block_section *mbs;
>> + unsigned long start_pfn;
>> +
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> + start_pfn = section_nr_to_pfn(mbs->phys_index);
>> + ret &= is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
>> + }
>
> I don't see you deleting anyting from the list in this loop. Why do you need
> to use list_for_each_safe? That won't protect you if someone else is messing
> with the list.
Yes, Kame pointed this out too. I think I'll need to update the patches to
always take the mutex when walking the list and use list_for_each_entry
>
>>
>> - start_pfn = section_nr_to_pfn(mem->phys_index);
>> - ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
>> return sprintf(buf, "%d\n", ret);
>> }
>>
>
>
>> @@ -238,19 +252,40 @@
>> static int memory_block_change_state(struct memory_block *mem,
>> unsigned long to_state, unsigned long from_state_req)
>> {
>> + struct memory_block_section *mbs;
>> + struct list_head *pos;
>> int ret = 0;
>> +
>> mutex_lock(&mem->state_mutex);
>>
>> - if (mem->state != from_state_req) {
>> - ret = -EINVAL;
>> - goto out;
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> +
>> + if (mbs->state != from_state_req)
>> + continue;
>> +
>> + ret = memory_block_action(mbs, to_state);
>> + if (ret)
>> + break;
>> + }
>
> Would it be better here to loop through all the sections and ensure they
> are in the proper state first before starting to change the state of any
> of them? Then you could easily return -EINVAL if one or more is in
> the incorrect state and wouldn't need to the code below.
The code below is needed in cases where the add/remove of one of the
memory_block_sections fails. The code can then return all of the
memory_block_sections in the memory_block to the original state.
>
>> + if (ret) {
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section,
>> + 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);
>> + }
>> }
>>
>> - ret = memory_block_action(mem, to_state);
>> if (!ret)
>> mem->state = to_state;
>>
>> -out:
>> mutex_unlock(&mem->state_mutex);
>> return ret;
>> }
>
>
>> @@ -498,19 +496,97 @@
>>
>> return mem;
>> }
>> +static int add_mem_block_section(struct memory_block *mem,
>> + int section_nr, unsigned long state)
>> +{
>> + struct memory_block_section *mbs;
>> +
>> + mbs = kzalloc(sizeof(*mbs), GFP_KERNEL);
>> + if (!mbs)
>> + return -ENOMEM;
>> +
>> + mbs->phys_index = section_nr;
>> + mbs->state = state;
>> +
>> + list_add(&mbs->next, &mem->sections);
>
> I don't think there is sufficient protection for this list. Don't we
> need to be holding a lock of some sort when adding/deleting/iterating
> through this list?
You're right. we should be holding the mutex.
I think there are a couple other places that I missed with this. I'll fix
it for a v2 of the patches.
>
>> + return 0;
>> +}
>
^ permalink raw reply
* Re: [PATCH 4/7] Allow sysfs memory directories to be split
From: Nathan Fontenot @ 2010-07-13 15:51 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20100713152854.ec1f4d6a.kamezawa.hiroyu@jp.fujitsu.com>
On 07/13/2010 01:28 AM, KAMEZAWA Hiroyuki wrote:
> On Mon, 12 Jul 2010 10:45:25 -0500
> Nathan Fontenot <nfont@austin.ibm.com> wrote:
>
>> This patch introduces the new 'split' file in each memory sysfs
>> directory and the associated routines needed to handle splitting
>> a directory.
>>
>> Signed-off-by; Nathan Fontenot <nfont@austin.ibm.com>
>> ---
>
> pleae check diff option...
>
>
>> drivers/base/memory.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 98 insertions(+), 1 deletion(-)
>>
>> Index: linux-2.6/drivers/base/memory.c
>> ===================================================================
>> --- linux-2.6.orig/drivers/base/memory.c 2010-07-09 14:23:20.000000000 -0500
>> +++ linux-2.6/drivers/base/memory.c 2010-07-09 14:38:09.000000000 -0500
>> @@ -32,6 +32,9 @@
>>
>> static int sections_per_block;
>>
>> +static int register_memory(struct memory_block *, struct mem_section *,
>> + int, enum mem_add_context);
>> +
>> static inline int base_memory_block_id(int section_nr)
>> {
>> return (section_nr / sections_per_block) * sections_per_block;
>> @@ -309,11 +312,100 @@
>> return sprintf(buf, "%d\n", mem->phys_device);
>> }
>>
>> +static void update_memory_block_phys_indexes(struct memory_block *mem)
>> +{
>> + struct list_head *pos;
>> + struct memory_block_section *mbs;
>> + unsigned long min_index = 0xffffffff;
>> + unsigned long max_index = 0;
>> +
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> +
>> + if (mbs->phys_index < min_index)
>> + min_index = mbs->phys_index;
>> +
>> + if (mbs->phys_index > max_index)
>> + max_index = mbs->phys_index;
>> + }
>> +
>> + mem->start_phys_index = min_index;
>> + mem->end_phys_index = max_index;
>> +}
>> +
>> +static ssize_t
>> +store_mem_split_block(struct sys_device *dev, struct sysdev_attribute *attr,
>> + const char *buf, size_t count)
>> +{
>> + struct memory_block *mem, *new_mem_blk;
>> + struct memory_block_section *mbs;
>> + struct list_head *pos, *tmp;
>> + struct mem_section *section;
>> + int min_scn_nr = 0;
>> + int max_scn_nr = 0;
>> + int total_scns = 0;
>> + int new_blk_min, new_blk_total;
>> + int ret = -EINVAL;
>> +
>> + mem = container_of(dev, struct memory_block, sysdev);
>> +
>> + if (list_is_singular(&mem->sections))
>> + return -EINVAL;
>
> What this means ?
list_is_singular() will return true if there is only one item
on the list. In this case we cannot split a memory_block with
only one memory_block_section.
>
>
>> +
>> + mutex_lock(&mem->state_mutex);
>> +
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> +
>> + total_scns++;
>> +
>> + if (min_scn_nr > mbs->phys_index)
>> + min_scn_nr = mbs->phys_index;
>> +
>> + if (max_scn_nr < mbs->phys_index)
>> + max_scn_nr = mbs->phys_index;
>> + }
>> +
>> + new_mem_blk = kzalloc(sizeof(*new_mem_blk), GFP_KERNEL);
>> + if (!new_mem_blk)
>> + return -ENOMEM;
>> +
>> + mutex_init(&new_mem_blk->state_mutex);
>> + INIT_LIST_HEAD(&new_mem_blk->sections);
>> + new_mem_blk->state = mem->state;
>> +
>> + mutex_lock(&new_mem_blk->state_mutex);
>> +
>> + new_blk_total = total_scns / 2;
>> + new_blk_min = max_scn_nr - new_blk_total + 1;
>> +
>> + section = __nr_to_section(new_blk_min);
>> + ret = register_memory(new_mem_blk, section, 0, HOTPLUG);
>> +
> 'nid' is always 0 ?
Ahh.. good catch. it may not be. I'll look into finding the correct nid.
>
> And for what purpose this interface is ? Does this split memory block into 2 pieces
> of the same size ?? sounds __very__ strange interface to me.
Yes, this splits the memory_block into two blocks of the same size. This was
suggested as something we may want to do. From ppc perspective I am not sure we
would use this.
The split functionality is not required. The main goal of the patch set is to
reduce the number of memory sysfs directories created. From a ppc perspective
the split functionality is not really needed.
>
> If this is necessary, I hope move the whole things to configfs rather than
> something tricky.
>
> Bye.
> -Kame
>
^ permalink raw reply
* Re: [PATCH 3/7] Update the [register,unregister]_memory routines
From: Nathan Fontenot @ 2010-07-13 15:46 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20100713152044.7ec8c9ae.kamezawa.hiroyu@jp.fujitsu.com>
On 07/13/2010 01:20 AM, KAMEZAWA Hiroyuki wrote:
> On Mon, 12 Jul 2010 10:44:10 -0500
> Nathan Fontenot <nfont@austin.ibm.com> wrote:
>
>> This patch moves the register/unregister_memory routines to
>> avoid a forward declaration. It also moves the sysfs file
>> creation and deletion for each directory into the register/
>> unregister routines to avoid duplicating it with these updates.
>>
>> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
>> ---
>> drivers/base/memory.c | 93 +++++++++++++++++++++++++-------------------------
>> 1 file changed, 48 insertions(+), 45 deletions(-)
>>
>> Index: linux-2.6/drivers/base/memory.c
>> ===================================================================
>> --- linux-2.6.orig/drivers/base/memory.c 2010-07-09 14:23:17.000000000 -0500
>> +++ linux-2.6/drivers/base/memory.c 2010-07-09 14:23:20.000000000 -0500
>> @@ -87,31 +87,6 @@
>> EXPORT_SYMBOL(unregister_memory_isolate_notifier);
>>
>> /*
>> - * register_memory - Setup a sysfs device for a memory block
>> - */
>> -static
>> -int register_memory(struct memory_block *memory, struct mem_section *section)
>> -{
>> - int error;
>> -
>> - memory->sysdev.cls = &memory_sysdev_class;
>> - memory->sysdev.id = __section_nr(section);
>> -
>> - error = sysdev_register(&memory->sysdev);
>> - return error;
>> -}
>> -
>> -static void
>> -unregister_memory(struct memory_block *memory)
>> -{
>> - BUG_ON(memory->sysdev.cls != &memory_sysdev_class);
>> -
>> - /* drop the ref. we got in remove_memory_block() */
>> - kobject_put(&memory->sysdev.kobj);
>> - sysdev_unregister(&memory->sysdev);
>> -}
>> -
>> -/*
>> * use this as the physical section index that this memsection
>> * uses.
>> */
>> @@ -346,6 +321,53 @@
>> sysdev_remove_file(&mem->sysdev, &attr_##attr_name)
>>
>> /*
>> + * register_memory - Setup a sysfs device for a memory block
>> + */
>> +static
>> +int register_memory(struct memory_block *memory, struct mem_section *section,
>> + int nid, enum mem_add_context context)
>> +{
>> + int ret;
>> +
>> + memory->sysdev.cls = &memory_sysdev_class;
>> + memory->sysdev.id = __section_nr(section);
>> +
> Why not block-ID but section-ID ?
Using the beginning section id as the id here makes the splitting of
memory_block's easier since we can assume that the id is unique.
>
> -Kame
>
^ permalink raw reply
* Re: [PATCH 1/7] Split the memory_block structure
From: Nathan Fontenot @ 2010-07-13 15:44 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20100713151855.3d56242d.kamezawa.hiroyu@jp.fujitsu.com>
Thanks for the review, answers below...
-Nathan
On 07/13/2010 01:18 AM, KAMEZAWA Hiroyuki wrote:
>
> plz cc linux-mm in the next time...
> And please incudes updates for Documentation/memory-hotplug.txt.
>
will do.
>
> On Mon, 12 Jul 2010 10:42:06 -0500
> Nathan Fontenot <nfont@austin.ibm.com> wrote:
>
>> This patch splits 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 also updates the routine handling memory_block creation
>> and manipulation to use these updated structures.
>>
>
> Could you clarify the number of memory_block_section per memory_block ?
The default number of memory_block_sections per memory block is 1. The
memory_block_size() routine (defined as __weak) sets the size of the
memory block, and thus the number of memory_block_sections.
The current view of memory in sysfs where each directory covers a single
memory section should still hold for everyone, unless a arch defines
their own memory_section_size routine to alter the behavior.
>
>
>> Signed -off-by: Nathan Fontenot <nfont@austin.ibm.com>
>> ---
>> drivers/base/memory.c | 228 +++++++++++++++++++++++++++++++++++--------------
>> include/linux/memory.h | 11 +-
>> 2 files changed, 172 insertions(+), 67 deletions(-)
>>
>> Index: linux-2.6/drivers/base/memory.c
>> ===================================================================
>> --- linux-2.6.orig/drivers/base/memory.c 2010-07-08 11:27:21.000000000 -0500
>> +++ linux-2.6/drivers/base/memory.c 2010-07-09 14:23:09.000000000 -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;
>> +
> some default value, plz. Does this can be determined only by .config ?
The default is 1. This is determined in the get_memory_block_size() which
is called from the memory sysfs init routine.
>
>
>> +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)
>> {
>> - unsigned long start_pfn;
>> - int ret;
>> - struct memory_block *mem =
>> - container_of(dev, struct memory_block, sysdev);
>> + struct list_head *pos, *tmp;
>> + struct memory_block *mem;
>> + int ret = 1;
>> +
>> + mem = container_of(dev, struct memory_block, sysdev);
>> + list_for_each_safe(pos, tmp, &mem->sections) {
>> + struct memory_block_section *mbs;
>> + unsigned long start_pfn;
>> +
>> + mbs = list_entry(pos, struct memory_block_section, next);
>
> list_for_each_entry ?
I went with list_for_each_safe() here since I am not holding the mutex
while walking the list. Perhaps this should be changed to take the
mutex and use list_for_each_entry().
>
>
>
>> + start_pfn = section_nr_to_pfn(mbs->phys_index);
>> + ret &= is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
>> + }
>
> Hmm, them, only when the whole memory block is removable, it's shown as
> removable. Right ?
> Does it meets ppc guy's requirements ?
Yes, and yes.
>
>>
>> - start_pfn = section_nr_to_pfn(mem->phys_index);
>> - ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
>> return sprintf(buf, "%d\n", ret);
>> }
>
> Hmm...can't you print removable information as bitmap, here ?
> overkill ?
We could print it as a bitmap, but I think it would be overkill. The
memory add/remove routines work on a memory_block such that all
memory_block_sections in the memory_block are added/removed as a whole.
Given this, I figured we only needed to know if the entire memory_block
is removable.
>
>
>>
>> @@ -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;
>> ot-option-to-disable-memory-hotplug.patch
>> + int old_state = mbs->state;
>
> Where is this noise from ?
Yuck! I'll take a look. That shouldn't be there obviously.
>
>>
>> - 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,40 @@
>> static int memory_block_change_state(struct memory_block *mem,
>> unsigned long to_state, unsigned long from_state_req)
>> {
>> + struct memory_block_section *mbs;
>> + struct list_head *pos;
>> int ret = 0;
>> +
>> mutex_lock(&mem->state_mutex);
>>
>> - if (mem->state != from_state_req) {
>> - ret = -EINVAL;
>> - goto out;
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> +
>
> list_for_each_entry() ?
That could be done here.
>
>> + if (mbs->state != from_state_req)
>> + continue;
>> +
>> + ret = memory_block_action(mbs, to_state);
>> + if (ret)
>> + break;
>> + }
>
> Then, all actions will be affect all memory sections under memory block ?
> (Hmm..maybe have to see following patches ?)
Correct. Add/remove actions will work on a memory_block as a whole.
>
>
>> +
>> + if (ret) {
>> + list_for_each(pos, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section,
>> + next);
>> +
> list_for_each_entry() ?
got it. :)
>
>> + 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);
>> + }
>> }
>>
>> - ret = memory_block_action(mem, to_state);
>> if (!ret)
>> mem->state = to_state;
>>
>> -out:
>> mutex_unlock(&mem->state_mutex);
>> return ret;
>> }
>> @@ -260,20 +295,15 @@
>> struct sysdev_attribute *attr, const char *buf, size_t count)
>> {
>
> Hmm, store_mem_state() ? What diff option are you using ?
Yes, this is store_mem_state.
Patches were generated with quilt.
>
>
>> struct memory_block *mem;
>> - unsigned int phys_section_nr;
>> int ret = -EINVAL;
>>
>> mem = container_of(dev, struct memory_block, sysdev);
>> - phys_section_nr = mem->phys_index;
>> -
>> - if (!present_section_nr(phys_section_nr))
>> - goto out;
>>
>> if (!strncmp(buf, "online", min((int)count, 6)))
>> ret = memory_block_change_state(mem, MEM_ONLINE, MEM_OFFLINE);
>> else if(!strncmp(buf, "offline", min((int)count, 7)))
>> ret = memory_block_change_state(mem, MEM_OFFLINE, MEM_ONLINE);
>> -out:
>> +
>> if (ret)
>> return ret;
>> return count;
>> @@ -435,39 +465,6 @@
>> return 0;
>> }
>>
>> -static int add_memory_block(int nid, struct mem_section *section,
>> - unsigned long state, enum mem_add_context context)
>> -{
>> - struct memory_block *mem = kzalloc(sizeof(*mem), GFP_KERNEL);
>> - unsigned long start_pfn;
>> - int ret = 0;
>> -
>> - if (!mem)
>> - return -ENOMEM;
>> -
>> - mem->phys_index = __section_nr(section);
>> - mem->state = state;
>> - mutex_init(&mem->state_mutex);
>> - start_pfn = section_nr_to_pfn(mem->phys_index);
>> - mem->phys_device = arch_get_memory_phys_device(start_pfn);
>> -
>> - ret = register_memory(mem, section);
>> - if (!ret)
>> - ret = mem_create_simple_file(mem, phys_index);
>> - if (!ret)
>> - ret = mem_create_simple_file(mem, state);
>> - if (!ret)
>> - ret = mem_create_simple_file(mem, phys_device);
>> - if (!ret)
>> - ret = mem_create_simple_file(mem, removable);
>> - if (!ret) {
>> - if (context == HOTPLUG)
>> - ret = register_mem_sect_under_node(mem, nid);
>> - }
>> -
>> - return ret;
>> -}
>> -
>
>
> please divide clean-up and logic-change patches into their own..
ok.
>
>
>> /*
>> * For now, we have a linear search to go find the appropriate
>> * memory_block corresponding to a particular phys_index. If
>> @@ -482,12 +479,13 @@
>> struct sys_device *sysdev;
>> struct memory_block *mem;
>> char name[sizeof(MEMORY_CLASS_NAME) + 9 + 1];
>> + int block_id = base_memory_block_id(__section_nr(section));
>>
>> /*
>> * This only works because we know that section == sysdev->id
>> * slightly redundant with sysdev_register()
>> */
>> - sprintf(&name[0], "%s%d", MEMORY_CLASS_NAME, __section_nr(section));
>> + sprintf(&name[0], "%s%d", MEMORY_CLASS_NAME, block_id);
>
> Hmm. Then, the user has to calculate block-id in addtion to section-id.
> Can't we use memory block name as memory%d-%d(start-end) ?
I am not attached to a particular name for the directories. I think
keeping the memory%d, where %d is the starting id makes the code that splits
the directory cleaner.
In a later patch I add a new file for each directory that has the ending
id in it so users can easily determine the start and end id's of the
memory block.
>
>
>
>>
>> kobj = kset_find_obj(&memory_sysdev_class.kset, name);
>> if (!kobj)
>> @@ -498,19 +496,97 @@
>>
>> return mem;
>> }
>> +static int add_mem_block_section(struct memory_block *mem,
>> + int section_nr, unsigned long state)
>> +{
>> + struct memory_block_section *mbs;
>> +
>> + mbs = kzalloc(sizeof(*mbs), GFP_KERNEL);
>> + if (!mbs)
>> + return -ENOMEM;
>> +
>> + mbs->phys_index = section_nr;
>> + mbs->state = state;
>> +
>> + list_add(&mbs->next, &mem->sections);
>> + return 0;
>> +}
>> +
>> +static int add_memory_block(int nid, struct mem_section *section,
>> + unsigned long state, enum mem_add_context context)
>> +{
>> + struct memory_block *mem;
>> + int ret = 0;
>> +
>> + mem = find_memory_block(section);
>
> I guess you need to add changes to find_memory_block. section-ID != block-ID.
That is above, see the line
>> + int block_id = base_memory_block_id(__section_nr(section));
>
>
>> + if (!mem) {
>> + unsigned long start_pfn;
>> +
>> + mem = kzalloc(sizeof(*mem), GFP_KERNEL);
>> + if (!mem)
>> + return -ENOMEM;
>> +
>> + mem->state = state;
>> + mutex_init(&mem->state_mutex);
>> + start_pfn = section_nr_to_pfn(__section_nr(section));
>> + mem->phys_device = arch_get_memory_phys_device(start_pfn);
>> + INIT_LIST_HEAD(&mem->sections);
>
> I'm not sure this phys_device is properly set in any arch...but this changes in
> granule will not affect ?
I don't think so, hopefully someone will speak up if this causes an issue.
>
>> +
>> + ret = register_memory(mem, section);
>> + if (!ret)
>> + ret = mem_create_simple_file(mem, phys_index);
>> + if (!ret)
>> + ret = mem_create_simple_file(mem, state);
>> + if (!ret)
>> + ret = mem_create_simple_file(mem, phys_device);
>> + if (!ret)
>> + ret = mem_create_simple_file(mem, removable);
>> + if (!ret) {
>> + if (context == HOTPLUG)
>> + ret = register_mem_sect_under_node(mem, nid);
>> + }
>> + } else {
>> + kobject_put(&mem->sysdev.kobj);
>> + }
>> +
>> + if (!ret)
>> + ret = add_mem_block_section(mem, __section_nr(section), state);
>> +
>> + return ret;
>> +}
>
>
>
>
>
>>
>> int remove_memory_block(unsigned long node_id, struct mem_section *section,
>> int phys_device)
>> {
>> struct memory_block *mem;
>> + struct memory_block_section *mbs;
>> + struct list_head *pos, *tmp;
>> + int section_nr = __section_nr(section);
>>
>> mem = find_memory_block(section);
>
> ditto.
>
>> - unregister_mem_sect_under_nodes(mem);
>> - mem_remove_simple_file(mem, phys_index);
>> - mem_remove_simple_file(mem, state);
>> - mem_remove_simple_file(mem, phys_device);
>> - mem_remove_simple_file(mem, removable);
>> - unregister_memory(mem, section);
>> + mutex_lock(&mem->state_mutex);
>> +
>> + /* remove the specified section */
>> + list_for_each_safe(pos, tmp, &mem->sections) {
>> + mbs = list_entry(pos, struct memory_block_section, next);
>> +
> list_for_each_entry_safe ?
yep. :)
>
>> + if (mbs->phys_index == section_nr) {
>> + list_del(&mbs->next);
>> + kfree(mbs);
>> + }
>> + }
>> +
>> + mutex_unlock(&mem->state_mutex);
>> +
>> + if (list_empty(&mem->sections)) {
>> + unregister_mem_sect_under_nodes(mem);
>> + mem_remove_simple_file(mem, phys_index);
>> + mem_remove_simple_file(mem, state);
>> + mem_remove_simple_file(mem, phys_device);
>> + mem_remove_simple_file(mem, removable);
>> + unregister_memory(mem);
>> + kfree(mem);
>> + }
>>
>> return 0;
>> }
>> @@ -532,6 +608,24 @@
>> return remove_memory_block(0, section, 0);
>> }
>>
>> +u32 __weak memory_block_size(void)
>> +{
>> + return MIN_MEMORY_BLOCK_SIZE;
>> +}
>> +
>> +static u32 get_memory_block_size(void)
>> +{
>> + u32 blk_sz;
>> +
>> + blk_sz = memory_block_size();
>> +
>> + /* Validate blk_sz is a power of 2 and not less than section size */
>> + if ((blk_sz & (blk_sz - 1)) || (blk_sz < MIN_MEMORY_BLOCK_SIZE))
>> + blk_sz = MIN_MEMORY_BLOCK_SIZE;
>> +
>> + return blk_sz;
>> +}
>> +
>> /*
>> * Initialize the sysfs support for memory devices...
>> */
>> @@ -540,12 +634,16 @@
>> unsigned int i;
>> int ret;
>> int err;
>> + int block_sz;
>>
>> memory_sysdev_class.kset.uevent_ops = &memory_uevent_ops;
>> ret = sysdev_class_register(&memory_sysdev_class);
>> if (ret)
>> goto out;
>>
>> + block_sz = get_memory_block_size();
>> + sections_per_block = block_sz / MIN_MEMORY_BLOCK_SIZE;
>> +
>> /*
>> * Create entries for memory sections that were found
>> * during boot and have been initialized
>> Index: linux-2.6/include/linux/memory.h
>> ===================================================================
>> --- linux-2.6.orig/include/linux/memory.h 2010-07-08 11:27:21.000000000 -0500
>> +++ linux-2.6/include/linux/memory.h 2010-07-09 14:22:44.000000000 -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;
>> };
>>
>> int arch_get_memory_phys_device(unsigned long start_pfn);
>> @@ -113,7 +120,7 @@
>> extern int remove_memory_block(unsigned long, struct mem_section *, int);
>> extern int memory_notify(unsigned long val, void *v);
>> extern int memory_isolate_notify(unsigned long val, void *v);
>> -extern struct memory_block *find_memory_block(unsigned long);
>> +extern struct memory_block *find_memory_block(struct mem_section *);
>> extern int memory_is_hidden(struct mem_section *);
>> #define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTION<<PAGE_SHIFT)
>> enum mem_add_context { BOOT, HOTPLUG };
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
^ permalink raw reply
* Re: section .data..init_task
From: Sam Ravnborg @ 2010-07-13 15:33 UTC (permalink / raw)
To: Sean MacLennan; +Cc: Denys Vlasenko, linuxppc-dev, Tim Abbott
In-Reply-To: <20100713112610.30b66318@lappy.seanm.ca>
On Tue, Jul 13, 2010 at 11:26:10AM -0400, Sean MacLennan wrote:
> On Tue, 13 Jul 2010 10:54:19 +0200
> Sam Ravnborg <sam@ravnborg.org> wrote:
>
> > It looks like a missing AT() in the output section.
> > The following patch should also fix it.
> >
> > Please test and let us know.
> >
> > Thanks,
> > Sam
>
> Applied the patch and it solves the problem. Thanks.
Thanks for the quick feedback!
Sam
^ permalink raw reply
* Re: section .data..init_task
From: Sean MacLennan @ 2010-07-13 15:26 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Denys Vlasenko, linuxppc-dev, Tim Abbott
In-Reply-To: <20100713085419.GA5826@merkur.ravnborg.org>
On Tue, 13 Jul 2010 10:54:19 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:
> It looks like a missing AT() in the output section.
> The following patch should also fix it.
>
> Please test and let us know.
>
> Thanks,
> Sam
Applied the patch and it solves the problem. Thanks.
Cheers,
Sean
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: Michel Dänzer @ 2010-07-13 14:59 UTC (permalink / raw)
To: jjDaNiMoTh; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <AANLkTilk4-gIiJPQb5aqZ5v4YvgzsddexnsmrFBER5HO@mail.gmail.com>
On Die, 2010-07-13 at 16:51 +0200, jjDaNiMoTh wrote:=20
> 2010/7/13 Michel D=C3=A4nzer <michel@daenzer.net>:
> > Does KMS work better with radeon.agpmode=3D1 (or 2 or -1)?
>=20
> with radeon.agpmode=3D-1, we could start X server (no black screen),
> with both radeon.modeset=3D{0,1}.
Note that radeon.agpmode is only effective with radeon.modeset=3D1,
otherwise you need to use Option "AGPMode" in xorg.conf (and vice
versa).
> In all cases, Xorg works fine, except when we try to load an OpenGL
> application (like glxgears), Xorg freeze, we could move only the
> mouse, we couldn't switch to a backup console.
Could be a GPU lockup again, possibly due to still using AGP 4x with
modeset=3D0.
> Same situations with glxgears in both modeset=3D0 and =3D1. In the log
> (Xorg.0.log) we have found:=20
>=20
> [.. other xorg log, no EE only WW]
> [ 65.238] (II) RADEON(0): Panel infos found from DDC detailed: 1280x85=
4
> [ 65.238] (II) RADEON(0): EDID vendor "APP", prod id 39968
> [ 65.249] (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0
> [ 65.249] Unhandled monitor type 0
> [ 65.249] (II) RADEON(0): Output: S-video, Detected Monitor Type: 0
> [ 137.813] [mi] EQ overflowing. The server is probably stuck in an
> infinite loop.
> [ 137.813]
> Backtrace:
> [ 137.814] 0: /usr/bin/X (xorg_backtrace+0x58) [0x100582cc]
> [ 137.814] 1: /usr/bin/X (mieqEnqueue+0x1c8) [0x1004e5d8]
> [ 137.814] 2: /usr/bin/X (xf86PostButtonEventP+0xf4) [0x10061be8]
> [ 137.814] 3: /usr/bin/X (xf86PostButtonEvent+0xb4) [0x10061d2c]
> [ 137.814] 4: /usr/lib/xorg/modules/input/evdev_drv.so
> (0xf380000+0x3d88) [0xf383d88]
> [ 137.814] 5: /usr/bin/X (0x10000000+0x68784) [0x10068784]
> [ 137.814] 6: /usr/bin/X (0x10000000+0x11a7e4) [0x1011a7e4]
> [ 137.814] 7: (vdso) (__kernel_sigtramp32+0x0) [0x100344]
> [ 137.814] 8: /usr/lib/xorg/modules/dri/r300_dri.so
> (0xf3f5000+0x48534) [0xf43d534]
> [ 137.814] 9: /usr/lib/libdrm.so.2 (drmIoctl+0x40) [0xf8b8f64]
> [ 137.814] 10: /usr/lib/libdrm.so.2 (drmCommandWrite+0x24) [0xf8bbe60]
> [ 137.814] 11: /usr/lib/xorg/modules/dri/r300_dri.so
> (0xf3f5000+0x46944) [0xf43b944]
> [ 137.814] 12: /usr/lib/xorg/modules/dri/r300_dri.so
> (0xf3f5000+0x64d8c) [0xf459d8c]
> [ 137.814] 13: /usr/lib/xorg/modules/extensions/libglx.so
> (0xf930000+0x40f78) [0xf970f78]
> [ 137.814] 14: /usr/lib/xorg/modules/extensions/libglx.so
> (0xf930000+0x44be4) [0xf974be4]
> [ 137.814] 15: /usr/bin/X (0x10000000+0x34a24) [0x10034a24]
> [ 137.815] 16: /usr/bin/X (0x10000000+0x18bc4) [0x10018bc4]
> [ 137.815] 17: /lib/libc.so.6 (0xfb39000+0x1f544) [0xfb58544]
> [ 137.815] 18: /lib/libc.so.6 (0xfb39000+0x1f6d0) [0xfb586d0]
What does the log file contain with modeset=3D1?
> Do we need to compile mesa, ati-dri, x.org and xf86-video-ati from git?
Shouldn't be necessary.
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: jjDaNiMoTh @ 2010-07-13 14:51 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <1279030767.515.15.camel@thor.local>
2010/7/13 Michel D=C3=A4nzer <michel@daenzer.net>:
[cut]
> Which framebuffer device (if any) is it trying to initialize otherwise?
> OFfb? The first paragraph above implies none, but then I'm not sure why
> the video=3D parameters would make any difference.
We tried and with 2.6.35-rc4 we could boot without video=3D. First good new=
s :)
[cut]
> Does KMS work better with radeon.agpmode=3D1 (or 2 or -1)?
with radeon.agpmode=3D-1, we could start X server (no black screen),
with both radeon.modeset=3D{0,1}. In all cases, Xorg works fine, except
when we try to load an OpenGL application (like glxgears), Xorg
freeze, we could move only the mouse, we couldn't switch to a backup
console. Same situations with glxgears in both modeset=3D0 and =3D1. In
the log (Xorg.0.log) we have found:
[.. other xorg log, no EE only WW]
[ 65.238] (II) RADEON(0): Panel infos found from DDC detailed: 1280x854
[ 65.238] (II) RADEON(0): EDID vendor "APP", prod id 39968
[ 65.249] (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0
[ 65.249] Unhandled monitor type 0
[ 65.249] (II) RADEON(0): Output: S-video, Detected Monitor Type: 0
[ 137.813] [mi] EQ overflowing. The server is probably stuck in an
infinite loop.
[ 137.813]
Backtrace:
[ 137.814] 0: /usr/bin/X (xorg_backtrace+0x58) [0x100582cc]
[ 137.814] 1: /usr/bin/X (mieqEnqueue+0x1c8) [0x1004e5d8]
[ 137.814] 2: /usr/bin/X (xf86PostButtonEventP+0xf4) [0x10061be8]
[ 137.814] 3: /usr/bin/X (xf86PostButtonEvent+0xb4) [0x10061d2c]
[ 137.814] 4: /usr/lib/xorg/modules/input/evdev_drv.so
(0xf380000+0x3d88) [0xf383d88]
[ 137.814] 5: /usr/bin/X (0x10000000+0x68784) [0x10068784]
[ 137.814] 6: /usr/bin/X (0x10000000+0x11a7e4) [0x1011a7e4]
[ 137.814] 7: (vdso) (__kernel_sigtramp32+0x0) [0x100344]
[ 137.814] 8: /usr/lib/xorg/modules/dri/r300_dri.so
(0xf3f5000+0x48534) [0xf43d534]
[ 137.814] 9: /usr/lib/libdrm.so.2 (drmIoctl+0x40) [0xf8b8f64]
[ 137.814] 10: /usr/lib/libdrm.so.2 (drmCommandWrite+0x24) [0xf8bbe60]
[ 137.814] 11: /usr/lib/xorg/modules/dri/r300_dri.so
(0xf3f5000+0x46944) [0xf43b944]
[ 137.814] 12: /usr/lib/xorg/modules/dri/r300_dri.so
(0xf3f5000+0x64d8c) [0xf459d8c]
[ 137.814] 13: /usr/lib/xorg/modules/extensions/libglx.so
(0xf930000+0x40f78) [0xf970f78]
[ 137.814] 14: /usr/lib/xorg/modules/extensions/libglx.so
(0xf930000+0x44be4) [0xf974be4]
[ 137.814] 15: /usr/bin/X (0x10000000+0x34a24) [0x10034a24]
[ 137.815] 16: /usr/bin/X (0x10000000+0x18bc4) [0x10018bc4]
[ 137.815] 17: /lib/libc.so.6 (0xfb39000+0x1f544) [0xfb58544]
[ 137.815] 18: /lib/libc.so.6 (0xfb39000+0x1f6d0) [0xfb586d0]
Do we need to compile mesa, ati-dri, x.org and xf86-video-ati from git?
Many thanks
^ permalink raw reply
* [PATCH] powerpc: Add vmcoreinfo symbols to allow makdumpfile to filter core files properly
From: Neil Horman @ 2010-07-13 13:46 UTC (permalink / raw)
To: linux-kernel, kexec, vgoyal, hbabu, benh, paulus, linuxppc-dev; +Cc: nhorman
Hey all-
About 2 years ago now, I sent this patch upstream to allow makedumpfile
to properly filter cores on ppc64:
http://www.mail-archive.com/kexec@lists.infradead.org/msg02426.html
It got acks from the kexec folks so I pulled it into RHEL, but I never checked
back here to make sure it ever made it in, which apparently it didn't. It still
needs to be included, so I'm reposting it here, making sure to copy all the ppc
folks this time. I've retested it on the latest linus kernel and it works fine,
allowing makedumpfile to find all the symbols it needs to properly strip a
vmcore on ppc64.
Neil
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
machine_kexec.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index bb3d893..0df7031 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -45,6 +45,18 @@ void machine_kexec_cleanup(struct kimage *image)
ppc_md.machine_kexec_cleanup(image);
}
+void arch_crash_save_vmcoreinfo(void)
+{
+
+#ifdef CONFIG_NEED_MULTIPLE_NODES
+ VMCOREINFO_SYMBOL(node_data);
+ VMCOREINFO_LENGTH(node_data, MAX_NUMNODES);
+#endif
+#ifndef CONFIG_NEED_MULTIPLE_NODES
+ VMCOREINFO_SYMBOL(contig_page_data);
+#endif
+}
+
/*
* Do not allocate memory (or fail in any way) in machine_kexec().
* We are past the point of no return, committed to rebooting now.
^ permalink raw reply related
* Re: 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: Michel Dänzer @ 2010-07-13 14:19 UTC (permalink / raw)
To: jjDaNiMoTh; +Cc: linuxppc-dev, xorg-driver-ati
In-Reply-To: <AANLkTikdlwl6VxdbkHP0TveQ3SPO0w4RD-onoG3QPyCO@mail.gmail.com>
On Die, 2010-07-13 at 16:03 +0200, jjDaNiMoTh wrote:=20
>=20
> When trying new 2.6.35-rc4, our kernel team (ArchLinuxPPC) has tried
> to setup KMS acceleration for radeon based machine.
> We have removed radeonfb, and all others framebuffer driver, and added
> fbcon and KMS enabled by default for radeon driver.
>=20
> With a clean start, the screen freeze, when the control pass from
> yaboot to kernel.
>=20
> If we start with video=3Dfbcon (or video=3Dradeondrmfb), we could reach
> the loading modules point, [...]
Which framebuffer device (if any) is it trying to initialize otherwise?
OFfb? The first paragraph above implies none, but then I'm not sure why
the video=3D parameters would make any difference.
> Jul 13 15:31:39 jim kernel: [drm] Initialized drm 1.1.0 20060810
> Jul 13 15:31:39 jim kernel: [drm] radeon kernel modesetting enabled.
> Jul 13 15:31:39 jim kernel: [drm] initializing kernel modesetting
> (RV350 0x1002:0x4E50).
> Jul 13 15:31:39 jim kernel: [drm] register mmio base: 0xB0000000
> Jul 13 15:31:39 jim kernel: [drm] register mmio size: 65536
> Jul 13 15:31:39 jim kernel: [drm] Using generic clock info
> Jul 13 15:31:39 jim kernel: agpgart-uninorth 0000:00:0b.0: putting AGP
> V2 device into 4x mode
> Jul 13 15:31:39 jim kernel: radeon 0000:00:10.0: putting AGP V2 device
> into 4x mode
> Jul 13 15:31:39 jim kernel: radeon 0000:00:10.0: GTT: 256M 0x00000000
> - 0x0FFFFFFF
> Jul 13 15:31:39 jim kernel: [drm] Generation 2 PCI interface, using
> max accessible memory
> Jul 13 15:31:39 jim kernel: radeon 0000:00:10.0: VRAM: 64M 0xB8000000
> - 0xBBFFFFFF (64M used)
> Jul 13 15:31:39 jim kernel: [drm] radeon: irq initialized.
> Jul 13 15:31:39 jim kernel: [drm] Detected VRAM RAM=3D64M, BAR=3D128M
> Jul 13 15:31:39 jim kernel: [drm] RAM width 128bits DDR
> Jul 13 15:31:39 jim kernel: [TTM] Zone kernel: Available graphics
> memory: 384990 kiB.
> Jul 13 15:31:39 jim kernel: [TTM] Zone highmem: Available graphics
> memory: 516062 kiB.
> Jul 13 15:31:39 jim kernel: [TTM] Initializing pool allocator.
> Jul 13 15:31:39 jim kernel: [drm] radeon: 64M of VRAM memory ready
> Jul 13 15:31:39 jim kernel: [drm] radeon: 256M of GTT memory ready.
> Jul 13 15:31:39 jim kernel: [drm] radeon: 1 quad pipes, 1 Z pipes initial=
ized.
> Jul 13 15:31:39 jim kernel: [drm] Loading R300 Microcode
> Jul 13 15:31:39 jim kernel: [drm] radeon: ring at 0x0000000000000000
> Jul 13 15:31:39 jim kernel: [drm] ring test succeeded in 3 usecs
> Jul 13 15:31:39 jim kernel: [drm] radeon: ib pool ready.
So far, so good.
> Jul 13 15:31:40 jim kernel: GPU lockup (waiting for 0x00000001 last
> fence id 0x00000000)
The GPU locks up, and things go downhill from there...
Does KMS work better with radeon.agpmode=3D1 (or 2 or -1)?
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* 2.6.35-rc4 ppc crash when loading radeon modeset=1
From: jjDaNiMoTh @ 2010-07-13 14:03 UTC (permalink / raw)
To: xorg-driver-ati; +Cc: linuxppc-dev
Hello to all.
Sorry if these aren't right place, please point me to the right
direction if you can :)
When trying new 2.6.35-rc4, our kernel team (ArchLinuxPPC) has tried
to setup KMS acceleration for radeon based machine.
We have removed radeonfb, and all others framebuffer driver, and added
fbcon and KMS enabled by default for radeon driver.
With a clean start, the screen freeze, when the control pass from
yaboot to kernel.
If we start with video=fbcon (or video=radeondrmfb), we could reach
the loading modules point, but after the loading of radeon, the screen
goes black, without any log information.
Loading kernel with video=fbcon radeon.modeset=0 allow us to reach the
end of init stage, and we could load X.org. In this case, acceleration
is disabled.
If we log out and do the following command:
modprobe -r radeon drm
modprobe drm debug=1
modprobe radeon modeset=1
The screen goes black, but at next boot we have found the logs. Any hint?
System information:
Xorg server: 1.8.1
xf86-video-ati 6.13.0
ati-dri 7.8.1
mesa 7.8.1
linux 2.6.35-rc4-00131-ge467e10
There are logs (most relevant part):
[...]
Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer
error ack signal
Jul 13 15:29:50 jim kernel: Machine check in kernel mode.
Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer
error ack signal
Jul 13 15:29:50 jim kernel: Machine check in kernel mode.
Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer
error ack signal
Jul 13 15:29:50 jim kernel: Machine check in kernel mode.
Jul 13 15:29:50 jim kernel: Caused by (from SRR1=149030): Transfer
error ack signal
[....]
Jul 13 15:31:28 jim kernel: [drm] Module unloaded
Jul 13 15:31:39 jim kernel: [drm] Initialized drm 1.1.0 20060810
Jul 13 15:31:39 jim kernel: [drm] radeon kernel modesetting enabled.
Jul 13 15:31:39 jim kernel: [drm] initializing kernel modesetting
(RV350 0x1002:0x4E50).
Jul 13 15:31:39 jim kernel: [drm] register mmio base: 0xB0000000
Jul 13 15:31:39 jim kernel: [drm] register mmio size: 65536
Jul 13 15:31:39 jim kernel: [drm] Using generic clock info
Jul 13 15:31:39 jim kernel: agpgart-uninorth 0000:00:0b.0: putting AGP
V2 device into 4x mode
Jul 13 15:31:39 jim kernel: radeon 0000:00:10.0: putting AGP V2 device
into 4x mode
Jul 13 15:31:39 jim kernel: radeon 0000:00:10.0: GTT: 256M 0x00000000
- 0x0FFFFFFF
Jul 13 15:31:39 jim kernel: [drm] Generation 2 PCI interface, using
max accessible memory
Jul 13 15:31:39 jim kernel: radeon 0000:00:10.0: VRAM: 64M 0xB8000000
- 0xBBFFFFFF (64M used)
Jul 13 15:31:39 jim kernel: [drm] radeon: irq initialized.
Jul 13 15:31:39 jim kernel: [drm] Detected VRAM RAM=64M, BAR=128M
Jul 13 15:31:39 jim kernel: [drm] RAM width 128bits DDR
Jul 13 15:31:39 jim kernel: [TTM] Zone kernel: Available graphics
memory: 384990 kiB.
Jul 13 15:31:39 jim kernel: [TTM] Zone highmem: Available graphics
memory: 516062 kiB.
Jul 13 15:31:39 jim kernel: [TTM] Initializing pool allocator.
Jul 13 15:31:39 jim kernel: [drm] radeon: 64M of VRAM memory ready
Jul 13 15:31:39 jim kernel: [drm] radeon: 256M of GTT memory ready.
Jul 13 15:31:39 jim kernel: [drm] radeon: 1 quad pipes, 1 Z pipes initialized.
Jul 13 15:31:39 jim kernel: [drm] Loading R300 Microcode
Jul 13 15:31:39 jim kernel: [drm] radeon: ring at 0x0000000000000000
Jul 13 15:31:39 jim kernel: [drm] ring test succeeded in 3 usecs
Jul 13 15:31:39 jim kernel: [drm] radeon: ib pool ready.
Jul 13 15:31:40 jim kernel: GPU lockup (waiting for 0x00000001 last
fence id 0x00000000)
Jul 13 15:31:40 jim kernel: NIP: f260fda4 LR: f260fda4 CTR: 00000001
Jul 13 15:31:40 jim kernel: REGS: ef3a3b90 TRAP: 0700 Not tainted
(2.6.35-rc4-NAT-00131-ge467e10)
Jul 13 15:31:40 jim kernel: MSR: 00029032 <EE,ME,CE,IR,DR> CR:
22822484 XER: 20000000
Jul 13 15:31:40 jim kernel: TASK = eedb9ac0[2066] 'modprobe' THREAD: ef3a2000
Jul 13 15:31:40 jim kernel: GPR00: f260fda4 ef3a3c40 eedb9ac0 00000040
416d5d8c ffffffff c04db984 416d5d09
Jul 13 15:31:40 jim kernel: GPR08: 416d5d8c 00000001 00000000 0000000a
22822482 100238a8 00000000 00000000
Jul 13 15:31:40 jim kernel: GPR16: 00000000 0000007d c04a0000 f26a1d54
00000001 00000000 00000000 ef3a2000
Jul 13 15:31:40 jim kernel: GPR24: c005f328 ef3a3c54 00000000 eed386cc
ef3a3c48 00000000 eed38000 ef085d40
Jul 13 15:31:40 jim kernel: NIP [f260fda4]
radeon_fence_wait+0x28c/0x2f4 [radeon]
Jul 13 15:31:40 jim kernel: LR [f260fda4] radeon_fence_wait+0x28c/0x2f4 [radeon]
Jul 13 15:31:40 jim kernel: Call Trace:
Jul 13 15:31:40 jim kernel: [ef3a3c40] [f260fda4]
radeon_fence_wait+0x28c/0x2f4 [radeon] (unreliable)
Jul 13 15:31:40 jim kernel: [ef3a3cb0] [f2638234]
r100_ib_test+0x158/0x280 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3ce0] [f26383a4]
r100_ib_init+0x28/0xc8 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3cf0] [f263f65c]
r300_startup+0xd4/0x1e4 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3d00] [f263fb3c] r300_init+0x150/0x334 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3d10] [f25fc514]
radeon_device_init+0x2b0/0x418 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3d30] [f25fdc0c]
radeon_driver_load_kms+0xa4/0x1f4 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3d60] [f2444c4c] drm_get_dev+0x284/0x43c [drm]
Jul 13 15:31:40 jim kernel: [ef3a3d90] [f268d75c]
radeon_pci_probe+0x18/0x28 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3da0] [c01f6f20] pci_device_probe+0x80/0xa4
Jul 13 15:31:40 jim kernel: [ef3a3dc0] [c025cf2c] driver_probe_device+0xc0/0x208
Jul 13 15:31:40 jim kernel: [ef3a3de0] [c025d130] __driver_attach+0xbc/0xc0
Jul 13 15:31:40 jim kernel: [ef3a3e00] [c025bd28] bus_for_each_dev+0x64/0xa0
Jul 13 15:31:40 jim kernel: [ef3a3e30] [c025cb58] driver_attach+0x24/0x34
Jul 13 15:31:40 jim kernel: [ef3a3e40] [c025c618] bus_add_driver+0xd8/0x308
Jul 13 15:31:40 jim kernel: [ef3a3e70] [c025d418] driver_register+0x88/0x154
Jul 13 15:31:40 jim kernel: [ef3a3e90] [c01f7200]
__pci_register_driver+0x4c/0xdc
Jul 13 15:31:40 jim kernel: [ef3a3eb0] [f243ee50] drm_init+0x120/0x134 [drm]
Jul 13 15:31:40 jim kernel: [ef3a3ed0] [f26c00e4]
radeon_init+0xe4/0x128 [radeon]
Jul 13 15:31:40 jim kernel: [ef3a3ef0] [c0003ff4] do_one_initcall+0x3c/0x1d8
Jul 13 15:31:40 jim kernel: [ef3a3f20] [c007b434] sys_init_module+0xdc/0x1e0
Jul 13 15:31:40 jim kernel: [ef3a3f40] [c0017f84] ret_from_syscall+0x0/0x40
Jul 13 15:31:40 jim kernel: --- Exception: c01 at 0xff62b58
Jul 13 15:31:40 jim kernel: LR = 0x10002c7c
Jul 13 15:31:40 jim kernel: Instruction dump:
Jul 13 15:31:40 jim kernel: 4bffffc4 813e0a18 7fc3f378 80090014
7c0903a6 4e800421 2f830000 419eff78
Jul 13 15:31:40 jim kernel: 809f0010 7e639b78 7ec5b378 4807dc59
<0fe00000> 9a9e16a8 7fc3f378 4bfecd41
Jul 13 15:31:40 jim kernel: radeon 0000:00:10.0: GPU reset succeed
Jul 13 15:31:40 jim kernel: [drm] radeon: 1 quad pipes, 1 Z pipes initialized.
Jul 13 15:31:40 jim kernel: [drm] radeon: ring at 0x0000000000000000
Jul 13 15:31:41 jim kernel: Oops: Kernel access of bad area, sig: 11 [#1]
Jul 13 15:31:41 jim kernel: PREEMPT PowerMac
Jul 13 15:31:41 jim kernel: Modules linked in: radeon(+) ttm
drm_kms_helper drm i2c_algo_bit hid_apple appletouch usbhid arc4 ecb
b43 mac80211 cfg80211 ohci_hcd snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device therm_adt746x snd_pcm_oss snd_aoa_codec_tas
snd_mixer_oss snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_pcm
snd_timer snd_page_alloc snd ehci_hcd ohci1394 ssb ams input_polldev
yenta_socket soundcore pcmcia usbcore ide_cd_mod pcmcia_rsrc ieee1394
cpufreq_userspace snd_aoa_soundbus i2c_powermac pcmcia_core evdev
cdrom uninorth_agp sungem sungem_phy [last unloaded: i2c_algo_bit]
Jul 13 15:31:41 jim kernel: NIP: f2482248 LR: f25fcb88 CTR: 00000000
Jul 13 15:31:41 jim kernel: REGS: ef3a3b50 TRAP: 0300 Tainted: G
W (2.6.35-rc4-NAT-00131-ge467e10)
Jul 13 15:31:41 jim kernel: MSR: 00009032 <EE,ME,IR,DR> CR: 22822484
XER: 20000000
Jul 13 15:31:41 jim kernel: DAR: 00000000, DSISR: 40000000
Jul 13 15:31:41 jim kernel: TASK = eedb9ac0[2066] 'modprobe' THREAD: ef3a2000
Jul 13 15:31:41 jim kernel: GPR00: f25fcb88 ef3a3c00 eedb9ac0 ef2c8c00
416d67bb ffffffff c04db97e 416d66f1
Jul 13 15:31:41 jim kernel: GPR08: 416d67bb 00000030 f28e002c eed39670
22822482 100238a8 00000000 00000000
Jul 13 15:31:41 jim kernel: GPR16: 00000000 0000007d c04a0000 f26a1d54
00000001 00000000 00000000 ef3a2000
Jul 13 15:31:41 jim kernel: GPR24: c005f328 ef3a3c54 f2484054 f2483878
ef2c8c00 ef2c8ea4 ef2c8e98 fffffffc
Jul 13 15:31:41 jim kernel: NIP [f2482248]
drm_helper_resume_force_mode+0x38/0x16c [drm_kms_helper]
Jul 13 15:31:41 jim kernel: LR [f25fcb88] radeon_gpu_reset+0x98/0x104 [radeon]
Jul 13 15:31:41 jim kernel: Call Trace:
Jul 13 15:31:41 jim kernel: [ef3a3c00] [ffffffea] 0xffffffea (unreliable)
Jul 13 15:31:41 jim kernel: [ef3a3c30] [f25fcb88]
radeon_gpu_reset+0x98/0x104 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3c40] [f260fdb4]
radeon_fence_wait+0x29c/0x2f4 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3cb0] [f2638234]
r100_ib_test+0x158/0x280 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3ce0] [f26383a4]
r100_ib_init+0x28/0xc8 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3cf0] [f263f65c]
r300_startup+0xd4/0x1e4 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3d00] [f263fb3c] r300_init+0x150/0x334 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3d10] [f25fc514]
radeon_device_init+0x2b0/0x418 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3d30] [f25fdc0c]
radeon_driver_load_kms+0xa4/0x1f4 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3d60] [f2444c4c] drm_get_dev+0x284/0x43c [drm]
Jul 13 15:31:41 jim kernel: [ef3a3d90] [f268d75c]
radeon_pci_probe+0x18/0x28 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3da0] [c01f6f20] pci_device_probe+0x80/0xa4
Jul 13 15:31:41 jim kernel: [ef3a3dc0] [c025cf2c] driver_probe_device+0xc0/0x208
Jul 13 15:31:41 jim kernel: [ef3a3de0] [c025d130] __driver_attach+0xbc/0xc0
Jul 13 15:31:41 jim kernel: [ef3a3e00] [c025bd28] bus_for_each_dev+0x64/0xa0
Jul 13 15:31:41 jim kernel: [ef3a3e30] [c025cb58] driver_attach+0x24/0x34
Jul 13 15:31:41 jim kernel: [ef3a3e40] [c025c618] bus_add_driver+0xd8/0x308
Jul 13 15:31:41 jim kernel: [ef3a3e70] [c025d418] driver_register+0x88/0x154
Jul 13 15:31:41 jim kernel: [ef3a3e90] [c01f7200]
__pci_register_driver+0x4c/0xdc
Jul 13 15:31:41 jim kernel: [ef3a3eb0] [f243ee50] drm_init+0x120/0x134 [drm]
Jul 13 15:31:41 jim kernel: [ef3a3ed0] [f26c00e4]
radeon_init+0xe4/0x128 [radeon]
Jul 13 15:31:41 jim kernel: [ef3a3ef0] [c0003ff4] do_one_initcall+0x3c/0x1d8
Jul 13 15:31:41 jim kernel: [ef3a3f20] [c007b434] sys_init_module+0xdc/0x1e0
Jul 13 15:31:41 jim kernel: [ef3a3f40] [c0017f84] ret_from_syscall+0x0/0x40
Jul 13 15:31:41 jim kernel: --- Exception: c01 at 0xff62b58
Jul 13 15:31:41 jim kernel: LR = 0x10002c7c
Jul 13 15:31:41 jim kernel: Instruction dump:
Jul 13 15:31:41 jim kernel: bf010010 7c7d1b78 3f60f248 90010034
3f40f248 3b7b382c 7c7c1b78 3bc30298
Jul 13 15:31:41 jim kernel: 3b5a4054 3b7b004c 87fd02a4 3bfffffc
<813f0004> 2f890000 419e0008 7c004a2c
Jul 13 15:31:41 jim kernel: ---[ end trace 9928f19443a4dfb8 ]---
Jul 13 15:31:48 jim kernel: Oops: Kernel access of bad area, sig: 11 [#2]
Jul 13 15:31:48 jim kernel: PREEMPT PowerMac
Jul 13 15:31:48 jim kernel: Modules linked in: radeon(+) ttm
drm_kms_helper drm i2c_algo_bit hid_apple appletouch usbhid arc4 ecb
b43 mac80211 cfg80211 ohci_hcd snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device therm_adt746x snd_pcm_oss snd_aoa_codec_tas
snd_mixer_oss snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_pcm
snd_timer snd_page_alloc snd ehci_hcd ohci1394 ssb ams input_polldev
yenta_socket soundcore pcmcia usbcore ide_cd_mod pcmcia_rsrc ieee1394
cpufreq_userspace snd_aoa_soundbus i2c_powermac pcmcia_core evdev
cdrom uninorth_agp sungem sungem_phy [last unloaded: i2c_algo_bit]
Jul 13 15:31:48 jim kernel: NIP: c0382df4 LR: c0382de0 CTR: 00000000
Jul 13 15:31:48 jim kernel: REGS: eed7dd80 TRAP: 0300 Tainted: G
D W (2.6.35-rc4-NAT-00131-ge467e10)
Jul 13 15:31:48 jim kernel: MSR: 00001032 <ME,IR,DR> CR: 24000424
XER: 20000000
Jul 13 15:31:48 jim kernel: DAR: 00000000, DSISR: 42000000
Jul 13 15:31:48 jim kernel: TASK = efb46820[2095] 'X' THREAD: eed7c000
Jul 13 15:31:48 jim kernel: GPR00: ffffffff eed7de30 efb46820 ef2c8e3c
eed7de38 eed7c000 eed7de44 0000082f
Jul 13 15:31:48 jim kernel: GPR08: 0000e200 00000000 0000007f c0382fc8
24000422 101d3ea8 101cbed4 00000000
Jul 13 15:31:48 jim kernel: GPR16: 10478758 00000000 00000001 101d3c0c
00000000 101cb8c8 ef2c8c00 00009032
Jul 13 15:31:48 jim kernel: GPR24: ef2c8dc0 ef2c8e40 eed7de38 efb46820
c04d0000 00009032 eed7c000 ef2c8e3c
Jul 13 15:31:48 jim kernel: NIP [c0382df4] __mutex_lock_slowpath+0xa0/0x274
Jul 13 15:31:48 jim kernel: LR [c0382de0] __mutex_lock_slowpath+0x8c/0x274
Jul 13 15:31:48 jim kernel: Call Trace:
Jul 13 15:31:48 jim kernel: [eed7de30] [c0382dd0]
__mutex_lock_slowpath+0x7c/0x274 (unreliable)
Jul 13 15:31:48 jim kernel: [eed7de70] [c0382fe0] mutex_lock+0x18/0x34
Jul 13 15:31:48 jim kernel: [eed7de80] [f244d010] drm_fb_release+0x28/0xac [drm]
Jul 13 15:31:48 jim kernel: [eed7dea0] [f243fab8] drm_release+0x674/0x770 [drm]
Jul 13 15:31:48 jim kernel: [eed7dee0] [c00fc410] fput+0x118/0x264
Jul 13 15:31:48 jim kernel: [eed7df00] [c00f87d0] filp_close+0x6c/0x98
Jul 13 15:31:48 jim kernel: [eed7df20] [c00f88ac] sys_close+0xb0/0x12c
Jul 13 15:31:48 jim kernel: [eed7df40] [c0017f84] ret_from_syscall+0x0/0x40
Jul 13 15:31:48 jim kernel: --- Exception: c01 at 0xfec3730
Jul 13 15:31:48 jim kernel: LR = 0xf8b9340
Jul 13 15:31:48 jim kernel: Instruction dump:
Jul 13 15:31:48 jim kernel: 7f44d378 3b3f0004 4bcee849 80bb0004
7fe3fb78 7f44d378 4bcee9e5 813f0008
Jul 13 15:31:48 jim kernel: 3800ffff 93210008 935f0008 9121000c
<93490000> 93610010 7d20f828 7c00f92d
Jul 13 15:31:48 jim kernel: ---[ end trace 9928f19443a4dfb9 ]---
Jul 13 15:31:48 jim kernel: note: X[2095] exited with preempt_count 2
Jul 13 15:31:48 jim kernel: Modules linked in: radeon(+) ttm
drm_kms_helper drm i2c_algo_bit hid_apple appletouch usbhid arc4 ecb
b43 mac80211 cfg80211 ohci_hcd snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device therm_adt746x snd_pcm_oss snd_aoa_codec_tas
snd_mixer_oss snd_aoa_fabric_layout snd_aoa snd_aoa_i2sbus snd_pcm
snd_timer snd_page_alloc snd ehci_hcd ohci1394 ssb ams input_polldev
yenta_socket soundcore pcmcia usbcore ide_cd_mod pcmcia_rsrc ieee1394
cpufreq_userspace snd_aoa_soundbus i2c_powermac pcmcia_core evdev
cdrom uninorth_agp sungem sungem_phy [last unloaded: i2c_algo_bit]
Jul 13 15:31:48 jim kernel: Call Trace:
Jul 13 15:31:48 jim kernel: [eed7da50] [c000a6e8]
show_stack+0x50/0x158 (unreliable)
Jul 13 15:31:48 jim kernel: [eed7da90] [c00369bc] __schedule_bug+0x64/0x68
Jul 13 15:31:48 jim kernel: [eed7daa0] [c03816a0] schedule+0x360/0x428
Jul 13 15:31:48 jim kernel: [eed7dae0] [c0382068] schedule_timeout+0x1c0/0x304
Jul 13 15:31:48 jim kernel: [eed7db30] [c0381b7c] wait_for_common+0xd4/0x1c8
Jul 13 15:31:48 jim kernel: [eed7db70] [c005a0b8] flush_cpu_workqueue+0xdc/0x110
Jul 13 15:31:48 jim kernel: [eed7dbb0] [c022fc7c] tty_ldisc_release+0x2c/0x84
Jul 13 15:31:48 jim kernel: [eed7dbd0] [c0228374] tty_release+0x428/0x5b0
Jul 13 15:31:48 jim kernel: [eed7dc70] [c00fc410] fput+0x118/0x264
Jul 13 15:31:48 jim kernel: [eed7dc90] [c00f87d0] filp_close+0x6c/0x98
Jul 13 15:31:48 jim kernel: [eed7dcb0] [c0042958] put_files_struct+0x12c/0x158
Jul 13 15:31:48 jim kernel: [eed7dce0] [c0042b7c] do_exit+0x118/0x708
Jul 13 15:31:48 jim kernel: [eed7dd30] [c0015560] die+0x100/0x2c0
Jul 13 15:31:48 jim kernel: [eed7dd60] [c001f350] bad_page_fault+0x90/0xc8
Jul 13 15:31:48 jim kernel: [eed7dd70] [c001843c] handle_page_fault+0x7c/0x80
Jul 13 15:31:48 jim kernel: --- Exception: 300 at
__mutex_lock_slowpath+0xa0/0x274
Jul 13 15:31:48 jim kernel: LR = __mutex_lock_slowpath+0x8c/0x274
Jul 13 15:31:48 jim kernel: [eed7de30] [c0382dd0]
__mutex_lock_slowpath+0x7c/0x274 (unreliable)
Jul 13 15:31:48 jim kernel: [eed7de70] [c0382fe0] mutex_lock+0x18/0x34
Jul 13 15:31:48 jim kernel: [eed7de80] [f244d010] drm_fb_release+0x28/0xac [drm]
Jul 13 15:31:48 jim kernel: [eed7dea0] [f243fab8] drm_release+0x674/0x770 [drm]
Jul 13 15:31:48 jim kernel: [eed7dee0] [c00fc410] fput+0x118/0x264
Jul 13 15:31:48 jim kernel: [eed7df00] [c00f87d0] filp_close+0x6c/0x98
Jul 13 15:31:48 jim kernel: [eed7df20] [c00f88ac] sys_close+0xb0/0x12c
Jul 13 15:31:48 jim kernel: [eed7df40] [c0017f84] ret_from_syscall+0x0/0x40
Jul 13 15:31:48 jim kernel: --- Exception: c01 at 0xfec3730
Jul 13 15:31:48 jim kernel: LR = 0xf8b9340
Jul 13 15:33:09 jim kernel: Using PowerMac machine description
[Next boot..]
Many thanks
^ permalink raw reply
* Re: [PATCH 1/7] Split the memory_block structure
From: Brian King @ 2010-07-13 14:00 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4C3B37CE.50802@austin.ibm.com>
On 07/12/2010 10:42 AM, Nathan Fontenot wrote:
> @@ -123,13 +130,20 @@
> static ssize_t show_mem_removable(struct sys_device *dev,
> struct sysdev_attribute *attr, char *buf)
> {
> - unsigned long start_pfn;
> - int ret;
> - struct memory_block *mem =
> - container_of(dev, struct memory_block, sysdev);
> + struct list_head *pos, *tmp;
> + struct memory_block *mem;
> + int ret = 1;
> +
> + mem = container_of(dev, struct memory_block, sysdev);
> + list_for_each_safe(pos, tmp, &mem->sections) {
> + struct memory_block_section *mbs;
> + unsigned long start_pfn;
> +
> + mbs = list_entry(pos, struct memory_block_section, next);
> + start_pfn = section_nr_to_pfn(mbs->phys_index);
> + ret &= is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
> + }
I don't see you deleting anyting from the list in this loop. Why do you need
to use list_for_each_safe? That won't protect you if someone else is messing
with the list.
>
> - start_pfn = section_nr_to_pfn(mem->phys_index);
> - ret = is_mem_section_removable(start_pfn, PAGES_PER_SECTION);
> return sprintf(buf, "%d\n", ret);
> }
>
> @@ -238,19 +252,40 @@
> static int memory_block_change_state(struct memory_block *mem,
> unsigned long to_state, unsigned long from_state_req)
> {
> + struct memory_block_section *mbs;
> + struct list_head *pos;
> int ret = 0;
> +
> mutex_lock(&mem->state_mutex);
>
> - if (mem->state != from_state_req) {
> - ret = -EINVAL;
> - goto out;
> + list_for_each(pos, &mem->sections) {
> + mbs = list_entry(pos, struct memory_block_section, next);
> +
> + if (mbs->state != from_state_req)
> + continue;
> +
> + ret = memory_block_action(mbs, to_state);
> + if (ret)
> + break;
> + }
Would it be better here to loop through all the sections and ensure they
are in the proper state first before starting to change the state of any
of them? Then you could easily return -EINVAL if one or more is in
the incorrect state and wouldn't need to the code below.
> + if (ret) {
> + list_for_each(pos, &mem->sections) {
> + mbs = list_entry(pos, struct memory_block_section,
> + 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);
> + }
> }
>
> - ret = memory_block_action(mem, to_state);
> if (!ret)
> mem->state = to_state;
>
> -out:
> mutex_unlock(&mem->state_mutex);
> return ret;
> }
> @@ -498,19 +496,97 @@
>
> return mem;
> }
> +static int add_mem_block_section(struct memory_block *mem,
> + int section_nr, unsigned long state)
> +{
> + struct memory_block_section *mbs;
> +
> + mbs = kzalloc(sizeof(*mbs), GFP_KERNEL);
> + if (!mbs)
> + return -ENOMEM;
> +
> + mbs->phys_index = section_nr;
> + mbs->state = state;
> +
> + list_add(&mbs->next, &mem->sections);
I don't think there is sufficient protection for this list. Don't we
need to be holding a lock of some sort when adding/deleting/iterating
through this list?
> + return 0;
> +}
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* High process latencies due to MPC5200 FEC hard- soft-irq processing
From: Wolfgang Grandegger @ 2010-07-13 13:29 UTC (permalink / raw)
To: Netdev; +Cc: linuxppc-dev@ozlabs.org, LKML
Hello,
we realized, that multiple ping floods (ping -f) can cause very large
high-priority process latencies (up to a many seconds) on a MPC5200
PowerPC system with FEC NAPI support. The latencies are measured with
# cyclictest -p 80 -n
The problem is that processing of the ICMP pakets in the Hard-Irq and
Soft-IRQ context can last for a long time without returning to the
scheduler. Reducing MAX_SOFTIRQ_RESTART from 10 to 2 helps - the latency
goes down to 35 ms with 2 "ping -f" - but it's not a configurable
parameter, even if it somehow depends on the CPU power. And using the
-rt patches seems overkill to me. Any other ideas or comments on how to
get rid of such high process latencies?
Wolfgang.
^ permalink raw reply
* Re: [PATCH] powerpc: reduce the size of the defconfigs
From: Martyn Welch @ 2010-07-13 10:35 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Olof Johansson, Stephen Rothwell, Linus, ppc-dev, LKML
In-Reply-To: <20100713073137.GC26442@pengutronix.de>
Uwe Kleine-König wrote:
> On Tue, Jul 13, 2010 at 05:09:45PM +1000, Stephen Rothwell wrote:
>
>> This uses Uwe's script (modified by Olof Johansson to speed it up
>> somewhat) to reduce the size of all the powerpc defconfigs. The resulting
>>
> IMHO we should add the script to the source, too. And if it's only for
> me to see Olof's optimisation. :-)
>
>
As the person who introduced the gef_* PPC defconfigs to the kernel (I
understood this to be best practice), I'm happy to go along with
whatever - as long as I can build a bootable kernel from the mainline
kernel. I think I understand Linus' wish not to see all the defconfig
churn (I get fed up diffing defconfigs, just to read through loads of
additions and removals of undef'ed entires from just the few configs I'm
interested in).
I assume I'm not alone among those attempting to add board support to
the mainline kernel in not being able to keep up with the LKML mailing
list and therefore have missed most of this discussion (think I've
managed to read some of it now). I would very much appreciate some
documentation / guidance on how to use this script - preferably provided
as a comment in the head of the script or/and some pointers in
"Documentation/".
Martyn
>> files have been verified to produce the same .config files by generating
>> them before and after this patch and comparing the results.
>>
>> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
>> ---
>> 100 files changed, 51 insertions(+), 133815 deletions(-)
>>
> Nice.
>
> Best regards
> Uwe
>
>
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748 | Barbirolli Square, Manchester,
E martyn.welch@ge.com | M2 3AB VAT:GB 927559189
^ permalink raw reply
* [
From: Sam Ravnborg @ 2010-07-13 9:50 UTC (permalink / raw)
To: Sean MacLennan, Benjamin Herrenschmidt
Cc: Denys Vlasenko, linuxppc-dev, Michal Marek, Tim Abbott
In-Reply-To: <20100712203435.08a3e90f@lappy.seanm.ca>
>From 851e645a7eee68380caaf026eb6d3be118876370 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <sam@ravnborg.org>
Date: Tue, 13 Jul 2010 11:39:42 +0200
Subject: [PATCH] vmlinux.lds: fix .data..init_task output section (fix popwerpc boot)
The .data..init_task output section was missing
a load offset causing a popwerpc target to fail to boot.
Sean MacLennan tracked it down to the definition of
INIT_TASK_DATA_SECTION().
There are only two users of INIT_TASK_DATA_SECTION()
in the kernel today: cris and popwerpc.
cris do not support relocatable kernels and is thus not
impacted by this change.
Fix INIT_TASK_DATA_SECTION() to specify load offset like
all other output sections.
Reported-by: Sean MacLennan <smaclennan@pikatech.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
---
On the assumption that Sean reports that it fixes
the warnings/boot issue here is a real patch.
Ben - will you take it via the popwerpc tree
or shall I ask Michal to take it via kbuild?
Sam
include/asm-generic/vmlinux.lds.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 48c5299..cdfff74 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -435,7 +435,7 @@
*/
#define INIT_TASK_DATA_SECTION(align) \
. = ALIGN(align); \
- .data..init_task : { \
+ .data..init_task : AT(ADDR(.data..init_task) - LOAD_OFFSET) { \
INIT_TASK_DATA(align) \
}
--
1.6.0.6
^ permalink raw reply related
* Re: section .data..init_task
From: Sam Ravnborg @ 2010-07-13 8:54 UTC (permalink / raw)
To: Sean MacLennan; +Cc: Denys Vlasenko, linuxppc-dev, Tim Abbott
In-Reply-To: <20100712203435.08a3e90f@lappy.seanm.ca>
On Mon, Jul 12, 2010 at 08:34:35PM -0400, Sean MacLennan wrote:
> On Mon, 28 Jun 2010 00:59:00 -0400
> Sean MacLennan <smaclennan@pikatech.com> wrote:
>
> > Anybody else seeing these messages?
> >
> > ppc_4xxFP-ld: .tmp_vmlinux1: section .data..init_task lma 0xc0374000
> > overlaps previous sections ppc_4xxFP-ld: .tmp_vmlinux2:
> > section .data..init_task lma 0xc03a2000 overlaps previous sections
> > ppc_4xxFP-ld: vmlinux: section .data..init_task lma 0xc03a2000
> > overlaps previous sections
> >
> > Or does anybody know what they mean? They started showing up in
> > 2.6.35.
> >
> > Very easy to reproduce, so don't hesitate to ask for more info.
>
> I had a bit of time, so I tracked this down. This patch seems to be
> the culprit: http://lkml.org/lkml/2010/2/19/366
>
> Specifically, this code:
>
> /* The initial task and kernel stack */
> - .data.init_task : AT(ADDR(.data.init_task) - LOAD_OFFSET) {
> - INIT_TASK_DATA(THREAD_SIZE)
> - }
> + INIT_TASK_DATA_SECTION(THREAD_SIZE)
>
> If I change it back to:
>
> /* The initial task and kernel stack */
> .data..init_task : AT(ADDR(.data..init_task) - LOAD_OFFSET) {
> INIT_TASK_DATA(THREAD_SIZE)
> }
>
> not only do the warnings go away, but the kernel now boots again!
It looks like a missing AT() in the output section.
The following patch should also fix it.
Please test and let us know.
Thanks,
Sam
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 48c5299..3c4bf03 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -435,7 +435,7 @@
*/
#define INIT_TASK_DATA_SECTION(align) \
. = ALIGN(align); \
- .data..init_task : { \
+ .data..init_task : AT(ADDR(.data..init_task) - LOAD_OFFSET) { \
INIT_TASK_DATA(align) \
}
^ permalink raw reply related
* optimized script [Was: ARM defconfig files]
From: Uwe Kleine-König @ 2010-07-13 8:07 UTC (permalink / raw)
To: Linus Torvalds
Cc: Stephen Rothwell, Daniel Walker, Russell King - ARM Linux,
Nicolas Pitre, Kevin Hilman, linux-arm-msm,
Linux Kernel Mailing List, Eric Miao, Olof Johansson, linux-omap,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20100713070741.GB26442@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]
Hello,
On Tue, Jul 13, 2010 at 09:07:41AM +0200, Uwe Kleine-König wrote:
> Hi
>
> On Mon, Jul 12, 2010 at 01:50:47PM -0600, Grant Likely wrote:
> > On Mon, Jul 12, 2010 at 1:34 PM, Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > > On Mon, Jul 12, 2010 at 12:17 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > >> I think Uwe could provide his script and add it to the kernel tree.
> > >> Then all architectures could benefit from it. Having the defconfig
> > >> files contain only those options which are different from the defaults
> > >> is certainly more readable, even on x86.
> > >
> > > Quite possible. But maintainers would need to be on the lookout of
> > > people actually using the script, and refusing to apply patches that
> > > re-introduce the whole big thing.
> >
> > I can (partially) speak for powerpc. If ARM uses this approach, then
> > I think we can do the same. After the defconfigs are trimmed, I
> > certainly won't pick up any more full defconfigs.
> I just restarted my script on the powerpc defconfigs basing on rc5, I
> assume they complete in a few days time.
So Stephen was faster than me. I don't know yet how he optimised my
script, meanwhile I put some efforts into it, too by just checking lines
that match "^(# )?CONFIG_".
Find it attached.
I will start to reduce the remaining configs (i.e. all but arm and
powerpc).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: reduce_defconfig --]
[-- Type: text/plain, Size: 1899 bytes --]
#! /usr/bin/env python
# vim: set fileencoding=utf-8 :
# Copyright (C) 2010 by Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
import getopt
import re
import os
import subprocess
import sys
# This prevents including a timestamp in the .config which makes comparing a
# bit easier.
os.environ['KCONFIG_NOTIMESTAMP'] = 'Yes, please'
re_interesting = re.compile(r'^(# )?CONFIG_')
opts, args = getopt.getopt(sys.argv[1:], '', ['arch=', 'src='])
src = ''
arch = 'arm'
for o, a in opts:
if o == '--arch':
arch = a
elif o == '--src':
src = a
configdir = os.path.join(src, 'arch', arch, 'configs')
def all_defconfigs():
lc = len(configdir)
for root, dirs, files in os.walk(configdir):
root = root[lc + 1:]
for f in filter(lambda s: s.endswith('_defconfig'), files):
yield os.path.join(root, f)
if not args:
args = all_defconfigs()
for target in args:
defconfig_src = os.path.join(configdir, target)
subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
origconfig = list(open('.config'))
config = list(origconfig)
config_size = os.stat('.config').st_size
i = 0
while i < len(config):
mo = re_interesting.match(config[i])
if mo:
defconfig = open(defconfig_src, 'w')
defconfig.writelines(config[:i])
defconfig.writelines(config[i + 1:])
defconfig.close()
subprocess.check_call(['make', '-s', 'ARCH=%s' % arch, target])
if os.stat('.config').st_size == config_size and list(open('.config')) == origconfig:
print '-%s' % config[i][:-1]
del config[i]
else:
print ' %s' % config[i][:-1]
i += 1
else:
del config[i]
defconfig = open(defconfig_src, 'w')
defconfig.writelines(config)
defconfig.close()
^ permalink raw reply
* Re: [PATCH] powerpc: reduce the size of the defconfigs
From: Uwe Kleine-König @ 2010-07-13 7:31 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Olof Johansson, ppc-dev, Linus, LKML
In-Reply-To: <20100713170945.26d95641.sfr@canb.auug.org.au>
On Tue, Jul 13, 2010 at 05:09:45PM +1000, Stephen Rothwell wrote:
> This uses Uwe's script (modified by Olof Johansson to speed it up
> somewhat) to reduce the size of all the powerpc defconfigs. The resulting
IMHO we should add the script to the source, too. And if it's only for
me to see Olof's optimisation. :-)
> files have been verified to produce the same .config files by generating
> them before and after this patch and comparing the results.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> 100 files changed, 51 insertions(+), 133815 deletions(-)
Nice.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] powerpc: reduce the size of the defconfigs
From: Stephen Rothwell @ 2010-07-13 7:09 UTC (permalink / raw)
To: Linus; +Cc: Olof Johansson, ppc-dev, LKML, "Uwe Kleine-König"
[-- Attachment #1: Type: text/plain, Size: 7899 bytes --]
This uses Uwe's script (modified by Olof Johansson to speed it up
somewhat) to reduce the size of all the powerpc defconfigs. The resulting
files have been verified to produce the same .config files by generating
them before and after this patch and comparing the results.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/configs/40x/acadia_defconfig | 1002 ----------
arch/powerpc/configs/40x/ep405_defconfig | 1211 ------------
arch/powerpc/configs/40x/hcu4_defconfig | 1064 ----------
arch/powerpc/configs/40x/kilauea_defconfig | 1197 -----------
arch/powerpc/configs/40x/makalu_defconfig | 1005 ----------
arch/powerpc/configs/40x/virtex_defconfig | 1105 -----------
arch/powerpc/configs/40x/walnut_defconfig | 1089 ----------
arch/powerpc/configs/44x/arches_defconfig | 1059 ----------
arch/powerpc/configs/44x/bamboo_defconfig | 1020 ----------
arch/powerpc/configs/44x/canyonlands_defconfig | 1263 ------------
arch/powerpc/configs/44x/ebony_defconfig | 1103 -----------
arch/powerpc/configs/44x/eiger_defconfig | 1177 -----------
arch/powerpc/configs/44x/icon_defconfig | 1335 -------------
arch/powerpc/configs/44x/iss476-smp_defconfig | 938 ---------
arch/powerpc/configs/44x/katmai_defconfig | 1088 ----------
arch/powerpc/configs/44x/rainier_defconfig | 1090 ----------
arch/powerpc/configs/44x/redwood_defconfig | 1168 -----------
arch/powerpc/configs/44x/sam440ep_defconfig | 1319 -------------
arch/powerpc/configs/44x/sequoia_defconfig | 1111 -----------
arch/powerpc/configs/44x/taishan_defconfig | 1097 -----------
arch/powerpc/configs/44x/virtex5_defconfig | 1111 -----------
arch/powerpc/configs/44x/warp_defconfig | 1389 -------------
arch/powerpc/configs/52xx/cm5200_defconfig | 1232 ------------
arch/powerpc/configs/52xx/lite5200b_defconfig | 1257 ------------
arch/powerpc/configs/52xx/motionpro_defconfig | 1265 ------------
arch/powerpc/configs/52xx/pcm030_defconfig | 1219 ------------
arch/powerpc/configs/52xx/tqm5200_defconfig | 1367 -------------
arch/powerpc/configs/83xx/asp8347_defconfig | 1432 --------------
arch/powerpc/configs/83xx/kmeter1_defconfig | 927 ---------
arch/powerpc/configs/83xx/mpc8313_rdb_defconfig | 1729 ----------------
arch/powerpc/configs/83xx/mpc8315_rdb_defconfig | 1798 -----------------
arch/powerpc/configs/83xx/mpc832x_mds_defconfig | 1328 -------------
arch/powerpc/configs/83xx/mpc832x_rdb_defconfig | 1475 --------------
arch/powerpc/configs/83xx/mpc834x_itx_defconfig | 1567 ---------------
arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig | 1453 --------------
arch/powerpc/configs/83xx/mpc834x_mds_defconfig | 1262 ------------
arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 1403 -------------
arch/powerpc/configs/83xx/mpc836x_rdk_defconfig | 1304 ------------
arch/powerpc/configs/83xx/mpc837x_mds_defconfig | 1333 -------------
arch/powerpc/configs/83xx/mpc837x_rdb_defconfig | 1471 --------------
arch/powerpc/configs/83xx/sbc834x_defconfig | 1398 -------------
arch/powerpc/configs/85xx/ksi8560_defconfig | 1119 -----------
arch/powerpc/configs/85xx/mpc8540_ads_defconfig | 992 ----------
arch/powerpc/configs/85xx/mpc8560_ads_defconfig | 1139 -----------
arch/powerpc/configs/85xx/mpc85xx_cds_defconfig | 1155 -----------
arch/powerpc/configs/85xx/sbc8548_defconfig | 1001 ----------
arch/powerpc/configs/85xx/sbc8560_defconfig | 1029 ----------
arch/powerpc/configs/85xx/socrates_defconfig | 1645 ----------------
arch/powerpc/configs/85xx/stx_gp3_defconfig | 1528 --------------
arch/powerpc/configs/85xx/tqm8540_defconfig | 1318 -------------
arch/powerpc/configs/85xx/tqm8541_defconfig | 1364 -------------
arch/powerpc/configs/85xx/tqm8548_defconfig | 1355 +-------------
arch/powerpc/configs/85xx/tqm8555_defconfig | 1364 -------------
arch/powerpc/configs/85xx/tqm8560_defconfig | 1364 -------------
arch/powerpc/configs/85xx/xes_mpc85xx_defconfig | 1786 -----------------
arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 1736 ----------------
arch/powerpc/configs/86xx/gef_sbc310_defconfig | 1625 ---------------
arch/powerpc/configs/86xx/gef_sbc610_defconfig | 1819 -----------------
arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig | 1634 ---------------
arch/powerpc/configs/86xx/mpc8641_hpcn_defconfig | 1640 ----------------
arch/powerpc/configs/86xx/sbc8641d_defconfig | 1432 --------------
arch/powerpc/configs/adder875_defconfig | 913 ---------
arch/powerpc/configs/amigaone_defconfig | 1490 --------------
arch/powerpc/configs/c2k_defconfig | 1608 ---------------
arch/powerpc/configs/cell_defconfig | 1314 +------------
arch/powerpc/configs/celleb_defconfig | 1195 +-----------
arch/powerpc/configs/chrp32_defconfig | 1469 --------------
arch/powerpc/configs/ep8248e_defconfig | 1118 -----------
arch/powerpc/configs/ep88xc_defconfig | 858 --------
arch/powerpc/configs/g5_defconfig | 1549 ---------------
arch/powerpc/configs/gamecube_defconfig | 945 ---------
arch/powerpc/configs/holly_defconfig | 879 ---------
arch/powerpc/configs/iseries_defconfig | 1056 ----------
arch/powerpc/configs/linkstation_defconfig | 1782 -----------------
arch/powerpc/configs/maple_defconfig | 1371 -------------
arch/powerpc/configs/mgcoge_defconfig | 1158 -----------
arch/powerpc/configs/mgsuvd_defconfig | 937 ---------
arch/powerpc/configs/mpc512x_defconfig | 1559 ---------------
arch/powerpc/configs/mpc5200_defconfig | 1849 -----------------
arch/powerpc/configs/mpc7448_hpc2_defconfig | 1194 -----------
arch/powerpc/configs/mpc8272_ads_defconfig | 1185 -----------
arch/powerpc/configs/mpc83xx_defconfig | 1662 ----------------
arch/powerpc/configs/mpc85xx_defconfig | 1704 ----------------
arch/powerpc/configs/mpc85xx_smp_defconfig | 1708 ----------------
arch/powerpc/configs/mpc866_ads_defconfig | 950 ---------
arch/powerpc/configs/mpc86xx_defconfig | 1680 ----------------
arch/powerpc/configs/mpc885_ads_defconfig | 863 --------
arch/powerpc/configs/pasemi_defconfig | 1931 +------------------
arch/powerpc/configs/pmac32_defconfig | 1884 +------------------
arch/powerpc/configs/ppc40x_defconfig | 1332 -------------
arch/powerpc/configs/ppc44x_defconfig | 1471 --------------
arch/powerpc/configs/ppc64_defconfig | 1724 +----------------
arch/powerpc/configs/ppc64e_defconfig | 1803 -----------------
arch/powerpc/configs/ppc6xx_defconfig | 2186 +--------------------
arch/powerpc/configs/pq2fads_defconfig | 1304 ------------
arch/powerpc/configs/prpmc2800_defconfig | 1674 ----------------
arch/powerpc/configs/ps3_defconfig | 1334 -------------
arch/powerpc/configs/pseries_defconfig | 1454 +--------------
arch/powerpc/configs/storcenter_defconfig | 1305 ------------
arch/powerpc/configs/wii_defconfig | 1262 ------------
100 files changed, 51 insertions(+), 133815 deletions(-)
The patch is available at
http://ozlabs.org/~sfr/powerpc-reduce-the-size-of-the-defconfigs.patch.bz2 .
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 4/7] Allow sysfs memory directories to be split
From: KAMEZAWA Hiroyuki @ 2010-07-13 6:28 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4C3B3895.3040209@austin.ibm.com>
On Mon, 12 Jul 2010 10:45:25 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> This patch introduces the new 'split' file in each memory sysfs
> directory and the associated routines needed to handle splitting
> a directory.
>
> Signed-off-by; Nathan Fontenot <nfont@austin.ibm.com>
> ---
pleae check diff option...
> drivers/base/memory.c | 99 +++++++++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 98 insertions(+), 1 deletion(-)
>
> Index: linux-2.6/drivers/base/memory.c
> ===================================================================
> --- linux-2.6.orig/drivers/base/memory.c 2010-07-09 14:23:20.000000000 -0500
> +++ linux-2.6/drivers/base/memory.c 2010-07-09 14:38:09.000000000 -0500
> @@ -32,6 +32,9 @@
>
> static int sections_per_block;
>
> +static int register_memory(struct memory_block *, struct mem_section *,
> + int, enum mem_add_context);
> +
> static inline int base_memory_block_id(int section_nr)
> {
> return (section_nr / sections_per_block) * sections_per_block;
> @@ -309,11 +312,100 @@
> return sprintf(buf, "%d\n", mem->phys_device);
> }
>
> +static void update_memory_block_phys_indexes(struct memory_block *mem)
> +{
> + struct list_head *pos;
> + struct memory_block_section *mbs;
> + unsigned long min_index = 0xffffffff;
> + unsigned long max_index = 0;
> +
> + list_for_each(pos, &mem->sections) {
> + mbs = list_entry(pos, struct memory_block_section, next);
> +
> + if (mbs->phys_index < min_index)
> + min_index = mbs->phys_index;
> +
> + if (mbs->phys_index > max_index)
> + max_index = mbs->phys_index;
> + }
> +
> + mem->start_phys_index = min_index;
> + mem->end_phys_index = max_index;
> +}
> +
> +static ssize_t
> +store_mem_split_block(struct sys_device *dev, struct sysdev_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct memory_block *mem, *new_mem_blk;
> + struct memory_block_section *mbs;
> + struct list_head *pos, *tmp;
> + struct mem_section *section;
> + int min_scn_nr = 0;
> + int max_scn_nr = 0;
> + int total_scns = 0;
> + int new_blk_min, new_blk_total;
> + int ret = -EINVAL;
> +
> + mem = container_of(dev, struct memory_block, sysdev);
> +
> + if (list_is_singular(&mem->sections))
> + return -EINVAL;
What this means ?
> +
> + mutex_lock(&mem->state_mutex);
> +
> + list_for_each(pos, &mem->sections) {
> + mbs = list_entry(pos, struct memory_block_section, next);
> +
> + total_scns++;
> +
> + if (min_scn_nr > mbs->phys_index)
> + min_scn_nr = mbs->phys_index;
> +
> + if (max_scn_nr < mbs->phys_index)
> + max_scn_nr = mbs->phys_index;
> + }
> +
> + new_mem_blk = kzalloc(sizeof(*new_mem_blk), GFP_KERNEL);
> + if (!new_mem_blk)
> + return -ENOMEM;
> +
> + mutex_init(&new_mem_blk->state_mutex);
> + INIT_LIST_HEAD(&new_mem_blk->sections);
> + new_mem_blk->state = mem->state;
> +
> + mutex_lock(&new_mem_blk->state_mutex);
> +
> + new_blk_total = total_scns / 2;
> + new_blk_min = max_scn_nr - new_blk_total + 1;
> +
> + section = __nr_to_section(new_blk_min);
> + ret = register_memory(new_mem_blk, section, 0, HOTPLUG);
> +
'nid' is always 0 ?
And for what purpose this interface is ? Does this split memory block into 2 pieces
of the same size ?? sounds __very__ strange interface to me.
If this is necessary, I hope move the whole things to configfs rather than
something tricky.
Bye.
-Kame
^ permalink raw reply
* Re: [PATCH 3/7] Update the [register,unregister]_memory routines
From: KAMEZAWA Hiroyuki @ 2010-07-13 6:20 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4C3B384A.4000902@austin.ibm.com>
On Mon, 12 Jul 2010 10:44:10 -0500
Nathan Fontenot <nfont@austin.ibm.com> wrote:
> This patch moves the register/unregister_memory routines to
> avoid a forward declaration. It also moves the sysfs file
> creation and deletion for each directory into the register/
> unregister routines to avoid duplicating it with these updates.
>
> Signed-off-by: Nathan Fontenot <nfont@austin.ibm.com>
> ---
> drivers/base/memory.c | 93 +++++++++++++++++++++++++-------------------------
> 1 file changed, 48 insertions(+), 45 deletions(-)
>
> Index: linux-2.6/drivers/base/memory.c
> ===================================================================
> --- linux-2.6.orig/drivers/base/memory.c 2010-07-09 14:23:17.000000000 -0500
> +++ linux-2.6/drivers/base/memory.c 2010-07-09 14:23:20.000000000 -0500
> @@ -87,31 +87,6 @@
> EXPORT_SYMBOL(unregister_memory_isolate_notifier);
>
> /*
> - * register_memory - Setup a sysfs device for a memory block
> - */
> -static
> -int register_memory(struct memory_block *memory, struct mem_section *section)
> -{
> - int error;
> -
> - memory->sysdev.cls = &memory_sysdev_class;
> - memory->sysdev.id = __section_nr(section);
> -
> - error = sysdev_register(&memory->sysdev);
> - return error;
> -}
> -
> -static void
> -unregister_memory(struct memory_block *memory)
> -{
> - BUG_ON(memory->sysdev.cls != &memory_sysdev_class);
> -
> - /* drop the ref. we got in remove_memory_block() */
> - kobject_put(&memory->sysdev.kobj);
> - sysdev_unregister(&memory->sysdev);
> -}
> -
> -/*
> * use this as the physical section index that this memsection
> * uses.
> */
> @@ -346,6 +321,53 @@
> sysdev_remove_file(&mem->sysdev, &attr_##attr_name)
>
> /*
> + * register_memory - Setup a sysfs device for a memory block
> + */
> +static
> +int register_memory(struct memory_block *memory, struct mem_section *section,
> + int nid, enum mem_add_context context)
> +{
> + int ret;
> +
> + memory->sysdev.cls = &memory_sysdev_class;
> + memory->sysdev.id = __section_nr(section);
> +
Why not block-ID but section-ID ?
-Kame
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox