Re: [PATCH] BUILD_BUG_ON: make it handle more cases
On Tue, Oct 20, 2009 at 10:43 PM, Alan Jenkins
wrote:
> On 10/20/09, Américo Wang wrote:
>> On Tue, Oct 20, 2009 at 02:15:33PM +1030, Rusty Russell wrote:
>>>BUILD_BUG_ON used to use the optimizer to do code elimination or fail
>>>at link time; it was changed to first the size of a negative array (a
>>>nicer compile time error), then (in
>>>8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield.
>>>
>>>bitfields: needs a literal constant at parse time, and can't be put under
>>> "if (__builtin_constant_p(x))" for example.
>>>negative array: can handle anything, but if the compiler can't tell it's
>>> a constant, silently has no effect.
>>>link time: breaks link if the compiler can't determine the value, but the
>>> linker output is not usually as informative as a compiler error.
>>>
>>>If we use the negative-array-size method *and* the link time trick,
>>>we get the ability to use BUILD_BUG_ON() under __builtin_constant_p()
>>>branches, and maximal ability for the compiler to detect errors at
>>>build time.
>>>
>>>Signed-off-by: Rusty Russell
>>>
>>>diff --git a/include/linux/kernel.h b/include/linux/kernel.h
>>>--- a/include/linux/kernel.h
>>>+++ b/include/linux/kernel.h
>>>@@ -683,12 +683,6 @@ struct sysinfo {
>>> char _f[20-2*sizeof(long)-sizeof(int)]; /* Padding: libc5 uses this..
>>> */
>>> };
>>>
>>>-/* Force a compilation error if condition is true */
>>>-#define BUILD_BUG_ON(condition) ((void)BUILD_BUG_ON_ZERO(condition))
>>>-
>>>-/* Force a compilation error if condition is constant and true */
>>>-#define MAYBE_BUILD_BUG_ON(cond) ((void)sizeof(char[1 - 2 * !!(cond)]))
>>>-
>>> /* Force a compilation error if condition is true, but also produce a
>>> result (of value 0 and type size_t), so the expression can be used
>>> e.g. in a structure initializer (or where-ever else comma expressions
>>>@@ -696,6 +690,33 @@ struct sysinfo {
>>> #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
>>> #define BUILD_BUG_ON_NULL(e) ((void *)sizeof(struct { int:-!!(e); }))
>>>
>>>+/**
>>>+ * BUILD_BUG_ON - break compile if a condition is true.
>>>+ * @cond: the condition which the compiler should know is false.
>>>+ *
>>>+ * If you have some code which relies on certain constants being equal, or
>>>+ * other compile-time-evaluated condition, you should use BUILD_BUG_ON to
>>>+ * detect if someone changes it.
>>>+ *
>>>+ * The implementation uses gcc's reluctance to create a negative array,
>>> but
>>>+ * gcc (as of 4.4) only emits that error for obvious cases (eg. not
>>> arguments
>>>+ * to inline functions). So as a fallback we use the optimizer; if it
>>> can't
>>>+ * prove the condition is false, it will cause a link error on the
>>> undefined
>>>+ * "__build_bug_on_failed". This error message can be harder to track
>>> down
>>>+ * though, hence the two different methods.
>>>+ */
>>>+#ifndef __OPTIMIZE__
>>>+#define BUILD_BUG_ON(condition) ((void)sizeof(char[1 - 2*!!(condition)]))
>>>+#else
>>>+extern int __build_bug_on_failed;
>>
>> Hmm, what exactly is __build_bug_on_failed?
>
> Well, we haven't added a definition for it in this patch. I'm sure
> grep will tell you it wasn't defined before hand either. So any
> reference to it is an error - which will be reported at link time.
>
>>>+#define BUILD_BUG_ON(condition) \
>>>+ do { \
>>>+ ((void)sizeof(char[1 - 2*!!(condition)])); \
>>>+ if (condition) __build_bug_on_failed = 1; \
>
> If "condition" is known false at compile time, gcc -O will eliminate
> the code which refers to __build_bug_on_failed. If it's not proved to
> be false - it will break the build, which is exactly what we want
> BUILD_BUG_ON to do.
Ah, clever trick! Got it.
Thanks!
Reviewed-by: WANG Cong
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Page map BUG on program exit
Here ya go Jonathan, http://patchwork.ozlabs.org/patch/34047/ http://patchwork.ozlabs.org/patch/34113/ Both patches work for my situation, but I went with the second set as a final patch(34113). - Jake Magee On Thu, Oct 22, 2009 at 3:57 PM, Jonathan Haws wrote: > All, > > I am using a 405EX CPU on a custom board. The layout and hardware is very > similar to the AMCC Kilauea board. Here is the output of uname -a: > > Linux (none) 2.6.30.3-wolverine-dirty #3 PREEMPT Thu Sep 10 11:41:37 MDT > 2009 ppc unknown > > I am getting the following BUG output when my program exits: > > BUG: Bad page map in process main pte:980005d7 pmd:0d840400 > addr:4800 vm_flags:400844fb anon_vma:(null) mapping:cd8454f8 > index:98000 > vma->vm_file->f_op->mmap: fpga_mmap+0x0/0x178 [fpgaDriver] > Call Trace: > [cd84dc40] [c0006f0c] show_stack+0x44/0x16c (unreliable) > [cd84dc80] [c00ba314] print_bad_pte+0x140/0x1d0 > [cd84dcb0] [c00ba3ec] vm_normal_page+0x48/0x50 > [cd84dcc0] [c00bb2ec] unmap_vmas+0x214/0x614 > [cd84dd40] [c00bffe0] exit_mmap+0xd0/0x1b4 > [cd84dd70] [c0031e40] mmput+0x50/0x134 > [cd84dd80] [c0036470] exit_mm+0x114/0x13c > [cd84ddb0] [c0037d80] do_exit+0xc0/0x68c > [cd84de00] [c0038390] do_group_exit+0x44/0xd8 > [cd84de10] [c0044468] get_signal_to_deliver+0x1f8/0x430 > [cd84de70] [c0008224] do_signal+0x54/0x29c > [cd84df40] [c0010d5c] do_user_signal+0x74/0xc4 > > I have an FPGA on the PCIe bus that I am mapping BAR0 to user space with a > call to mmap(). The mapping works just fine and I can access all the > registers in the BAR without a problem. However, on exit this comes up. > > A Google search showed tons of people with similar problems in standard > distributions (Ubuntu primarily), but no resolutions. > > Has anyone seen this crop up before and know what the issue is? I include > any source code, if that is required. > > Thanks! > > Jonathan > > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] i2c/ibm-iic: drop NO_IRQ
Drop NO_IRQ as 0 is the preferred way to describe 'no irq'
(http://lkml.org/lkml/2005/11/21/221). This change is safe, as the driver is
only used on powerpc, where NO_IRQ is 0 anyhow.
Signed-off-by: Wolfram Sang
Cc: Sean MacLennan
Cc: Ben Dooks
---
drivers/i2c/busses/i2c-ibm_iic.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index b1bc6e2..2bef534 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -668,12 +668,12 @@ static int __devinit iic_request_irq(struct of_device
*ofdev,
int irq;
if (iic_force_poll)
- return NO_IRQ;
+ return 0;
irq = irq_of_parse_and_map(np, 0);
- if (irq == NO_IRQ) {
+ if (!irq) {
dev_err(&ofdev->dev, "irq_of_parse_and_map failed\n");
- return NO_IRQ;
+ return 0;
}
/* Disable interrupts until we finish initialization, assumes
@@ -683,7 +683,7 @@ static int __devinit iic_request_irq(struct of_device
*ofdev,
if (request_irq(irq, iic_handler, 0, "IBM IIC", dev)) {
dev_err(&ofdev->dev, "request_irq %d failed\n", irq);
/* Fallback to the polling mode */
- return NO_IRQ;
+ return 0;
}
return irq;
@@ -719,7 +719,7 @@ static int __devinit iic_probe(struct of_device *ofdev,
init_waitqueue_head(&dev->wq);
dev->irq = iic_request_irq(ofdev, dev);
- if (dev->irq == NO_IRQ)
+ if (!dev->irq)
dev_warn(&ofdev->dev, "using polling mode\n");
/* Board specific settings */
@@ -766,7 +766,7 @@ static int __devinit iic_probe(struct of_device *ofdev,
return 0;
error_cleanup:
- if (dev->irq != NO_IRQ) {
+ if (dev->irq) {
iic_interrupt_mode(dev, 0);
free_irq(dev->irq, dev);
}
@@ -790,7 +790,7 @@ static int __devexit iic_remove(struct of_device *ofdev)
i2c_del_adapter(&dev->adap);
- if (dev->irq != NO_IRQ) {
+ if (dev->irq) {
iic_interrupt_mode(dev, 0);
free_irq(dev->irq, dev);
}
--
1.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] i2c/cpm: drop NO_IRQ
Drop NO_IRQ as 0 is the preferred way to describe 'no irq' (http://lkml.org/lkml/2005/11/21/221). This change is safe, as the driver is only used on powerpc, where NO_IRQ is 0 anyhow. Signed-off-by: Wolfram Sang Cc: Jochen Friedrich Cc: Ben Dooks --- drivers/i2c/busses/i2c-cpm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/busses/i2c-cpm.c b/drivers/i2c/busses/i2c-cpm.c index 9c2e100..16948db 100644 --- a/drivers/i2c/busses/i2c-cpm.c +++ b/drivers/i2c/busses/i2c-cpm.c @@ -441,7 +441,7 @@ static int __devinit cpm_i2c_setup(struct cpm_i2c *cpm) init_waitqueue_head(&cpm->i2c_wait); cpm->irq = of_irq_to_resource(ofdev->node, 0, NULL); - if (cpm->irq == NO_IRQ) + if (!cpm->irq) return -EINVAL; /* Install interrupt handler. */ -- 1.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] i2c/mpc: drop NO_IRQ
Drop NO_IRQ as 0 is the preferred way to describe 'no irq'
(http://lkml.org/lkml/2005/11/21/221). This change is safe, as the driver is
only used on powerpc, where NO_IRQ is 0 anyhow.
Signed-off-by: Wolfram Sang
Cc: Grant Likely
Cc: Ben Dooks
---
drivers/i2c/busses/i2c-mpc.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index d325e86..7e58443 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -115,7 +115,7 @@ static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout,
int writing)
u32 x;
int result = 0;
- if (i2c->irq == NO_IRQ) {
+ if (!i2c->irq) {
while (!(readb(i2c->base + MPC_I2C_SR) & CSR_MIF)) {
schedule();
if (time_after(jiffies, orig_jiffies + timeout)) {
@@ -520,7 +520,7 @@ static int __devinit fsl_i2c_probe(struct of_device *op,
}
i2c->irq = irq_of_parse_and_map(op->node, 0);
- if (i2c->irq != NO_IRQ) { /* i2c->irq = NO_IRQ implies polling */
+ if (i2c->irq) { /* no i2c->irq implies polling */
result = request_irq(i2c->irq, mpc_i2c_isr,
IRQF_SHARED, "i2c-mpc", i2c);
if (result < 0) {
@@ -579,7 +579,7 @@ static int __devexit fsl_i2c_remove(struct of_device *op)
i2c_del_adapter(&i2c->adap);
dev_set_drvdata(&op->dev, NULL);
- if (i2c->irq != NO_IRQ)
+ if (i2c->irq)
free_irq(i2c->irq, i2c);
irq_dispose_mapping(i2c->irq);
--
1.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
i2c/janitoral: drop NO_IRQ from the subsystem
Hello, after having to deal with NO_IRQ confusion more than once, I decided to start a bit of janitorial work and remove it from the i2c-subsystem. Detail for better using 0 as "no irq" can be found here: http://lkml.org/lkml/2005/11/21/221 Regards, Wolfram ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Guarded load and bus error
Hi, I'm working on a MPC8548 processor, using its RapidIO bus. I have two kernel trees ported for a board, a linux 2.6.24-ppc, and a linux-2.6.31 (powerpc) kernel. I don't think this bus behaviour is RapidIO specific though, as also the PCI bus and local bus must handle malfunctioning devices. The HID1[RFXE] bit is enabled. To test bus error behaviour, I'm doing reads from mapped (RapidIO) I/O memory (mapped cache-inhibited, guarded). 32 bit aligned accesses are working fine, so the setup is good. A RapidIO error handler is installed (error/port-write interrupt) which printks some error bits from the RapidIO error registers and resets them. Now I'm provoking bus errors by: 1) reading from a RapidIO device that does not exist: a timeout is asserted 2) reading from an unaligned address The MPC8548ERM mentions that interrupt latency is indeterminate for guarded loads. From this I conclude that the processor stalls until it receives data from the bus: it is not interruptable (machine check, interrupts or critical interrupts). However the following behaviour is seen: Linux 2.6.24 ppc: For 1) my application gets a SIGBUS, after this, the error interrupt is run reporting a packet timeout: good. For 2) the kernel OOPSes while running do_IRQ, getting irq number. The kernel is not interrupt mode though: my application is killed and I may continue. Linux 2.6.31 powerpc: For 1) first some interrupt runs (apparantly), the machine check handler prints a stack trace showing do_IRQ and retrieving the irq number. The kernel in this instance detects it's running an interrupt and panic's and resets immediately. For 2) things are even worse ;-). The case 1) may be "solved" by disabling my own RapidIO error interrupt handling (I think that's the IRQ about to be executed, but the kernel hasn't gotten far enough to read the proper registers to tell me). If the error interrupt is disabled, then the application is killed. Behaviour seems proper; except I can't print my (diagnostic) errors. With this "fix" though, the case 2) proceeds as follows: the kernel OOPSes in the machine check handler with the stack trace showing it's executing instructions in the softirq handler. The softirq process is killed (I assume). After this my application may continue, and I think it retries the I/O read because (after timeout) the machine check OOPSes again, this time showing a timer interrupt in progress (which is trying to wake the softirq process), thereby panic'ing and resetting the board. If I "mangle" the machine check handler to print RapidIO error registers and return immediately always, then the behaviour is that I keep getting machine checks printing 'packet timeout' and/or 'illegal field in packet' ... apparantly the I/O operation is retried again and again. Not particularly nice for a so called "guarded load". To verify the "guarded load" being really guarded, I set the timeout to maximum (~5 seconds), and tried to read from a non-existing device. Under these circumstances, the board is not pingable anymore, and telnet sessions to it are dead. These come back to life when the timeout has passed and a SIGBUS has killed the test application. So, the guarded load does really seem to block external interrupts (at least timer and ethernet), but on the other hand I'm seeing inconsistent stack traces during the machine check handling (as the last instruction was in user space, I shouldn't be seeing stack traces down the kernel, softirq or where else). The HID0 and HID1 registers are equal in the two kernels (except the 2.6.31 sets DOZE mode, but disabling that had no effect). How is it possible that behaviour differs between these two kernels? How can I get my desired behaviour that my application is killed with a SIGBUS, and the rest of the kernel keeps running properly? Thanks in advance for any insight, Micha Nelissen ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] BUILD_BUG_ON: make it handle more cases
On Tue, 2009-10-20 at 14:15 +1030, Rusty Russell wrote: > BUILD_BUG_ON used to use the optimizer to do code elimination or fail > at link time; it was changed to first the size of a negative array (a > nicer compile time error), then (in > 8c87df457cb58fe75b9b893007917cf8095660a0) to a bitfield. > > bitfields: needs a literal constant at parse time, and can't be put under > "if (__builtin_constant_p(x))" for example. > negative array: can handle anything, but if the compiler can't tell it's > a constant, silently has no effect. > link time: breaks link if the compiler can't determine the value, but the > linker output is not usually as informative as a compiler error. > > If we use the negative-array-size method *and* the link time trick, > we get the ability to use BUILD_BUG_ON() under __builtin_constant_p() > branches, and maximal ability for the compiler to detect errors at > build time. > > Signed-off-by: Rusty Russell Thanks Rusty, this indeed fixes the problem. Acked-by: Hollis Blanchard -- Hollis Blanchard IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Page map BUG on program exit
All, I am using a 405EX CPU on a custom board. The layout and hardware is very similar to the AMCC Kilauea board. Here is the output of uname -a: Linux (none) 2.6.30.3-wolverine-dirty #3 PREEMPT Thu Sep 10 11:41:37 MDT 2009 ppc unknown I am getting the following BUG output when my program exits: BUG: Bad page map in process main pte:980005d7 pmd:0d840400 addr:4800 vm_flags:400844fb anon_vma:(null) mapping:cd8454f8 index:98000 vma->vm_file->f_op->mmap: fpga_mmap+0x0/0x178 [fpgaDriver] Call Trace: [cd84dc40] [c0006f0c] show_stack+0x44/0x16c (unreliable) [cd84dc80] [c00ba314] print_bad_pte+0x140/0x1d0 [cd84dcb0] [c00ba3ec] vm_normal_page+0x48/0x50 [cd84dcc0] [c00bb2ec] unmap_vmas+0x214/0x614 [cd84dd40] [c00bffe0] exit_mmap+0xd0/0x1b4 [cd84dd70] [c0031e40] mmput+0x50/0x134 [cd84dd80] [c0036470] exit_mm+0x114/0x13c [cd84ddb0] [c0037d80] do_exit+0xc0/0x68c [cd84de00] [c0038390] do_group_exit+0x44/0xd8 [cd84de10] [c0044468] get_signal_to_deliver+0x1f8/0x430 [cd84de70] [c0008224] do_signal+0x54/0x29c [cd84df40] [c0010d5c] do_user_signal+0x74/0xc4 I have an FPGA on the PCIe bus that I am mapping BAR0 to user space with a call to mmap(). The mapping works just fine and I can access all the registers in the BAR without a problem. However, on exit this comes up. A Google search showed tons of people with similar problems in standard distributions (Ubuntu primarily), but no resolutions. Has anyone seen this crop up before and know what the issue is? I include any source code, if that is required. Thanks! Jonathan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2][v5] powerpc: Make the CMM memory hotplug aware
The Collaborative Memory Manager (CMM) module allocates individual pages
over time that are not migratable. On a long running system this can
severely impact the ability to find enough pages to support a hotplug
memory remove operation.
This patch adds a memory isolation notifier and a memory hotplug notifier.
The memory isolation notifier will return the number of pages found
in the range specified. This is used to determine if all of the used
pages in a pageblock are owned by the balloon (or other entities in
the notifier chain). The hotplug notifier will free pages in the range
which is to be removed. The priority of this hotplug notifier is low
so that it will be called near last, this helps avoids removing loaned
pages in operations that fail due to other handlers.
CMM activity will be halted when hotplug remove operations are active
and resume activity after a delay period to allow the hypervisor time
to adjust.
Signed-off-by: Robert Jennings
---
Changes since v4:
* The structures for recording loaned pages are not allocated as MOVABLE
* The structures for recording loaned pages are removed from sections
being taken offline by moving their contents to a newly allocated page.
Changes since v3:
* Changed from atomic to mutex for hotplug state tracking.
* Clarified documentation for the new module parameter description.
Changes since v2:
* None, resent with parent patch to keep them together.
arch/powerpc/platforms/pseries/cmm.c | 254 ++-
1 file changed, 248 insertions(+), 6 deletions(-)
Index: b/arch/powerpc/platforms/pseries/cmm.c
===
--- a/arch/powerpc/platforms/pseries/cmm.c
+++ b/arch/powerpc/platforms/pseries/cmm.c
@@ -38,19 +38,28 @@
#include
#include
#include
+#include
#include "plpar_wrappers.h"
#define CMM_DRIVER_VERSION "1.0.0"
#define CMM_DEFAULT_DELAY 1
+#define CMM_HOTPLUG_DELAY 5
#define CMM_DEBUG 0
#define CMM_DISABLE0
#define CMM_OOM_KB 1024
#define CMM_MIN_MEM_MB 256
#define KB2PAGES(_p) ((_p)>>(PAGE_SHIFT-10))
#define PAGES2KB(_p) ((_p)<<(PAGE_SHIFT-10))
+/*
+ * The priority level tries to ensure that this notifier is called as
+ * late as possible to reduce thrashing in the shared memory pool.
+ */
+#define CMM_MEM_HOTPLUG_PRI1
+#define CMM_MEM_ISOLATE_PRI15
static unsigned int delay = CMM_DEFAULT_DELAY;
+static unsigned int hotplug_delay = CMM_HOTPLUG_DELAY;
static unsigned int oom_kb = CMM_OOM_KB;
static unsigned int cmm_debug = CMM_DEBUG;
static unsigned int cmm_disabled = CMM_DISABLE;
@@ -65,6 +74,10 @@ MODULE_VERSION(CMM_DRIVER_VERSION);
module_param_named(delay, delay, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(delay, "Delay (in seconds) between polls to query hypervisor
paging requests. "
"[Default=" __stringify(CMM_DEFAULT_DELAY) "]");
+module_param_named(hotplug_delay, hotplug_delay, uint, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(delay, "Delay (in seconds) after memory hotplug remove "
+"before loaning resumes. "
+"[Default=" __stringify(CMM_HOTPLUG_DELAY) "]");
module_param_named(oom_kb, oom_kb, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(oom_kb, "Amount of memory in kb to free on OOM. "
"[Default=" __stringify(CMM_OOM_KB) "]");
@@ -92,6 +105,9 @@ static unsigned long oom_freed_pages;
static struct cmm_page_array *cmm_page_list;
static DEFINE_SPINLOCK(cmm_lock);
+static DEFINE_MUTEX(hotplug_mutex);
+static int hotplug_occurred; /* protected by the hotplug mutex */
+
static struct task_struct *cmm_thread_ptr;
/**
@@ -110,6 +126,17 @@ static long cmm_alloc_pages(long nr)
cmm_dbg("Begin request for %ld pages\n", nr);
while (nr) {
+ /* Exit if a hotplug operation is in progress or occurred */
+ if (mutex_trylock(&hotplug_mutex)) {
+ if (hotplug_occurred) {
+ mutex_unlock(&hotplug_mutex);
+ break;
+ }
+ mutex_unlock(&hotplug_mutex);
+ } else {
+ break;
+ }
+
addr = __get_free_page(GFP_NOIO | __GFP_NOWARN |
__GFP_NORETRY | __GFP_NOMEMALLOC);
if (!addr)
@@ -119,8 +146,9 @@ static long cmm_alloc_pages(long nr)
if (!pa || pa->index >= CMM_NR_PAGES) {
/* Need a new page for the page list. */
spin_unlock(&cmm_lock);
- npa = (struct cmm_page_array *)__get_free_page(GFP_NOIO
| __GFP_NOWARN |
-
__GFP_NORETRY | __GFP_NOMEMALLOC);
+ npa = (struct cmm_page_array *)__get_free_page(
+
RE: Device Tree Corrupted after unflatten_device_tree()
Hi, David/Michael, Great great finding! I added halting FEC (the Ethernet controller in MPC866) in platforms_fixups() and the problem disappears. Thank you very much! Lixin -Original Message- From: David Gibson [mailto:da...@gibson.dropbear.id.au] Sent: Wednesday, October 21, 2009 6:11 PM To: Lixin Yao Cc: mich...@ellerman.id.au; linuxppc-dev@lists.ozlabs.org Subject: Re: Device Tree Corrupted after unflatten_device_tree() On Wed, Oct 21, 2009 at 10:43:55AM -0700, Lixin Yao wrote: > When corrupted, curtain blocks of 64 bytes are messed up. > This is a screen dump of a good unflattened device at beginning: [snip] > When corrupted, it becomes following, note the 64 bock at 0x03ffdf00 > is messed up. And this kind of corruptions occur several times [snip] > 03ffdf00 : 000c db055be0 08060001 ..[. > 03ffdf10 : 08000604 0001000c db055be0 ac141001 ..[. > 03ffdf20 : ac14 1053 1053 .S...S.. > 03ffdf30 : 08000604 0001000c 36681bfe f874c01e 6h...t.. Uh, oh. That looks like a broadcast ethernet packet (ARP, specifically). Looks like a network device used by the firmware hasn't been quiesced properly before booting the kernel and is DMAing stuff straight on top of kernel memory. You'll probably need a hook in the bootwrapper to shut down the ethernet. There are some examples of this in arch/powerpc/boot already - look for ibm4xx_quiesce_eth(). -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UBIFS problem on MPC8536DS
Felix Radensky wrote: Are you aware of Freescale plans to fix the problem in new silicon revisions ? I don't know anything yet -- still trying to get in touch with the relevant hardware people. Also, can you please tell what CPUs are affected by this, except 8536 and 8572. I suppose anything with an eLBC could be affected. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/5 v4] Export memory_sysdev_class
On Thu, 2009-10-22 at 10:31 -0500, Nathan Fontenot wrote: > Dave Hansen wrote: > > On Wed, 2009-10-21 at 09:44 -0500, Nathan Fontenot wrote: > >> Export the memory_sysdev_class structure. This is needed so we can create > >> a 'release' file in sysfs in addition to the existing 'probe' file in > >> order to support DLPAR removal of memory on the powerpc/pseries platform. > >> The new 'release' file will be powerpc/pseries only. > > > > Please do it in generic code. You may only need it on ppc today, but > > somebody else is going to want the same thing tomorrow on another arch. > > I thought about this but wasn't sure if having the probe/release sysfs files > for memory and cpu be in generic code would be accepted. Although we don't want to pollute the generic code with lots of per-arch cruft, this still looks pretty generic to me. It is also really nice to have all of the sysfs files for one directory be in a single place in the source. > Would it be acceptable to put the new release file for memory under the > ARCH_MEMORY_PROBE config option? That sounds fine to me. It may need a slightly tuned name if you can think of anything better. I can't off the top of my head. x86's is really only there for testing reasons. I would use mem= to shrink a machine's memory at boot then use the probe file to re-add it later. I did that before I had hardware that could do real hotplug. > This would reduce the number of arch'es > that would require stubs as it appears only powerpc and x86 define this. Yeah, that'd be a nice side-effect I guess. -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/5 v4] Export memory_sysdev_class
Dave Hansen wrote: On Wed, 2009-10-21 at 09:44 -0500, Nathan Fontenot wrote: Export the memory_sysdev_class structure. This is needed so we can create a 'release' file in sysfs in addition to the existing 'probe' file in order to support DLPAR removal of memory on the powerpc/pseries platform. The new 'release' file will be powerpc/pseries only. Please do it in generic code. You may only need it on ppc today, but somebody else is going to want the same thing tomorrow on another arch. I thought about this but wasn't sure if having the probe/release sysfs files for memory and cpu be in generic code would be accepted. Would it be acceptable to put the new release file for memory under the ARCH_MEMORY_PROBE config option? This would reduce the number of arch'es that would require stubs as it appears only powerpc and x86 define this. I could do the same thing for the cpu probe/release files and a new ARCH_CPU_PROBE config option which would eliminate the required stubs in arch'es other than powerpc right now. -Nathan Fontenot It's also nice to keep all of the stuff doing the actual sysfs munging in one place. I know it'll cost a few stubs for calling in and out of arch code, but it should save some work down the road for somebody else. -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: How to mount rootfs though harddisk when booting?
On Oct 22, 2009, at 9:08 AM, wilbur.chan wrote: mpc85xx with sata harddisk,which has a rootfs on sda3. I ' ve tried to use freescale's kernel image , which is togehther with the mpc85xx board, to successfully mount the sda3 filesystem when booting, But when I used my own kernle, it failed: I am using kernel 2.6.21.7 to mount the harddisk as the rootfs. However, it failed in booting and print: VFS: Cannot open root device "sda3" or unknown-block(0,0) My kernel's bootargs are as followed: root=/dev/sda3 rw console=ttyS0,115200 console=tty0 I guess there were some incorrect configs when doing kernel menuconfig, I' ve set "ext2,ext3", and some "sata" ,"scsi" configs, but that might be not enough. May anyone please give me some suggestions? THX in advance. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev Post the full kernel boot log. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
How to mount rootfs though harddisk when booting?
mpc85xx with sata harddisk,which has a rootfs on sda3. I ' ve tried to use freescale's kernel image , which is togehther with the mpc85xx board, to successfully mount the sda3 filesystem when booting, But when I used my own kernle, it failed: I am using kernel 2.6.21.7 to mount the harddisk as the rootfs. However, it failed in booting and print: VFS: Cannot open root device "sda3" or unknown-block(0,0) My kernel's bootargs are as followed: root=/dev/sda3 rw console=ttyS0,115200 console=tty0 I guess there were some incorrect configs when doing kernel menuconfig, I' ve set "ext2,ext3", and some "sata" ,"scsi" configs, but that might be not enough. May anyone please give me some suggestions? THX in advance. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Query: Does Linux kernel 2.6.31 support read/write/erase on ST make M29W128GH Flash memory chip?
Hi All, I am searching for M29W128GH support in Linux kernel 2.6.31. On internet I am seeing that there is some patch work for fixup on write buffer coomand on M29W128GH. This shows that Linux kernel 2.6.31 supports the M29W128GH. But I am not seeing any memory mapping for M29W128GH. Can anyone please tell me that whether Linux kernel 2.6.31 support the read/write/erase on M29W128GH? If yes how I can check that? Which of below files I should use for communicating with ST M29W128GH flash chip? cfi_cmdset_0001.c cfi_cmdset_0002.c cfi_cmdset_0020.c -- Looks like I shall use this but not confirm. cfi_probe.c I am novice to flash driver in kernel so might be not getting the exact details on M29W128GH. Expecting a help from seniors in this field. Thanks in advance. Thanks & Regards, Aakash ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Execute In Place (XIP) support for PPC440x5
Hi List, I am trying to port a board with PPC440x5 on linux-2.6.31. My board has 64MB of flash and 256KB of RAM. Since with this much RAM it is not possible to copy the kernel image to RAM and boot it from there. I was trying to figure-out option in the kernel which will allow me to execute it from flash itself. I refered to http://www.denx.de/wiki/publish/DULG/to-delete/ConfigureLinuxForXIP.html; but the flags mentioned here are not present for PPC architecture. I found these flag only for ARM architecture. So can anyone please tell me whether it is possible to have kernel executing from flash for PPC? If yes, then please let me know about any patch or something that will allow me to do this? -- Thanks and Regards, Mohit Mewada ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Move ehea hcall definitions into hvcall.h
Anton Blanchard wrote: > Move ehea hcall definitions into hvcall.h. > > Signed-off-by: Anton Blanchard Acked-by: Thomas Klein > --- > > Index: linux.trees.git/arch/powerpc/include/asm/hvcall.h > === > --- linux.trees.git.orig/arch/powerpc/include/asm/hvcall.h2009-10-19 > 17:59:42.0 +1100 > +++ linux.trees.git/arch/powerpc/include/asm/hvcall.h 2009-10-19 > 18:03:18.0 +1100 > @@ -212,6 +212,19 @@ > #define H_QUERY_INT_STATE 0x1E4 > #define H_POLL_PENDING 0x1D8 > #define H_ILLAN_ATTRIBUTES 0x244 > +#define H_MODIFY_HEA_QP 0x250 > +#define H_QUERY_HEA_QP 0x254 > +#define H_QUERY_HEA 0x258 > +#define H_QUERY_HEA_PORT 0x25C > +#define H_MODIFY_HEA_PORT0x260 > +#define H_REG_BCMC 0x264 > +#define H_DEREG_BCMC 0x268 > +#define H_REGISTER_HEA_RPAGES0x26C > +#define H_DISABLE_AND_GET_HEA0x270 > +#define H_GET_HEA_INFO 0x274 > +#define H_ALLOC_HEA_RESOURCE 0x278 > +#define H_ADD_CONN 0x284 > +#define H_DEL_CONN 0x288 > #define H_JOIN 0x298 > #define H_VASI_STATE0x2A4 > #define H_ENABLE_CRQ 0x2B0 > Index: linux.trees.git/drivers/net/ehea/ehea_phyp.h > === > --- linux.trees.git.orig/drivers/net/ehea/ehea_phyp.h 2009-10-19 > 18:03:48.0 +1100 > +++ linux.trees.git/drivers/net/ehea/ehea_phyp.h 2009-10-19 > 18:03:56.0 +1100 > @@ -33,7 +33,6 @@ > #include > #include "ehea.h" > #include "ehea_hw.h" > -#include "ehea_hcall.h" > > /* Some abbreviations used here: > * > Index: linux.trees.git/drivers/net/ehea/ehea_hcall.h > === > --- linux.trees.git.orig/drivers/net/ehea/ehea_hcall.h2009-10-19 > 17:59:31.0 +1100 > +++ /dev/null 1970-01-01 00:00:00.0 + > @@ -1,51 +0,0 @@ > -/* > - * linux/drivers/net/ehea/ehea_hcall.h > - * > - * eHEA ethernet device driver for IBM eServer System p > - * > - * (C) Copyright IBM Corp. 2006 > - * > - * Authors: > - * Christoph Raisch > - * Jan-Bernd Themann > - * Thomas Klein > - * > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License as published by > - * the Free Software Foundation; either version 2, or (at your option) > - * any later version. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > - * > - * You should have received a copy of the GNU General Public License > - * along with this program; if not, write to the Free Software > - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. > - */ > - > -#ifndef __EHEA_HCALL_H__ > -#define __EHEA_HCALL_H__ > - > -/** > - * This file contains HCALL defines that are to be included in the > appropriate > - * kernel files later > - */ > - > -#define H_ALLOC_HEA_RESOURCE 0x278 > -#define H_MODIFY_HEA_QP0x250 > -#define H_QUERY_HEA_QP 0x254 > -#define H_QUERY_HEA0x258 > -#define H_QUERY_HEA_PORT 0x25C > -#define H_MODIFY_HEA_PORT 0x260 > -#define H_REG_BCMC 0x264 > -#define H_DEREG_BCMC 0x268 > -#define H_REGISTER_HEA_RPAGES 0x26C > -#define H_DISABLE_AND_GET_HEA 0x270 > -#define H_GET_HEA_INFO 0x274 > -#define H_ADD_CONN 0x284 > -#define H_DEL_CONN 0x288 > - > -#endif /* __EHEA_HCALL_H__ */ > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: UBIFS problem on MPC8536DS
Hi, Scott Scott Wood wrote: On Fri, Oct 16, 2009 at 07:01:43AM +0200, Felix Radensky wrote: Thanks for confirmation. So the real problem is eLBC ? What happens if I access other devices on eLBC (e.g. FPGA) simultaneously with NAND or NOR ? AFAICT, the problem is NAND being accessed simultaneously with anything else on the eLBC (at least GPCM -- not sure about UPM). Instead of delaying the memory-like transaction until the NAND special operation has completed, it seems to just abort the NAND operation. eLBC can't really tell the difference whether you've got NOR or FPGA hooked up to a GPCM chip select, so the problem should still apply. Are you aware of Freescale plans to fix the problem in new silicon revisions ? Also, can you please tell what CPUs are affected by this, except 8536 and 8572. Thanks a lot. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
