* Re: [PATCH] powerpc/mm: Fix 40x and 8xx vs. _PAGE_SPECIAL
From: Rex Feany @ 2009-09-24 0:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, Weirich, Bernhard
In-Reply-To: <1253679146.7103.270.camel@pasglop>
Thus spake Benjamin Herrenschmidt (benh@kernel.crashing.org):
> Bernhard, Rex, please let me know if that works for you.
it doesn't work for me, it crashes differently then before though!
This patch worked for me:
>
> Signed-off-by: Bernhard Weirich <bernhard.weirich@riedel.net>
> --- linux/arch/powerpc/include/asm/pte-common.h 2009-09-16 11:23:44.000000000 +0200
> +++ linux/arch/powerpc/include/asm/pte-common.h 2009-09-22 11:13:08.000000000 +0200
> @@ -176,7 +176,7 @@
> #define HAVE_PAGE_AGP
>
> /* Advertise support for _PAGE_SPECIAL */
> -#ifdef _PAGE_SPECIAL
> +#if _PAGE_SPECIAL != 0
> #define __HAVE_ARCH_PTE_SPECIAL
> #endif
>
without either patch:
boots into userspace, starts running my code
which uses mmap to access an fpga:
BUG: Bad page map in process loadfpga pte:ff1008d3 pmd:02103001
addr:30028000 vm_flags:400844fb anon_vma:(null) mapping:c30000e8 index:ff100
vma->vm_ops->fault: 0x0
vma->vm_file->f_op->mmap: mmap_mem+0x0/0xa8
Call Trace:
[c2107db0] [c00067d0] show_stack+0x44/0x14c (unreliable)
[c2107df0] [c0056854] print_bad_pte+0x1b4/0x1d0
[c2107e20] [c0056898] vm_normal_page+0x28/0x50
[c2107e30] [c0056c30] unmap_vmas+0x1b8/0x510
[c2107eb0] [c005b17c] unmap_region+0x94/0x124
[c2107ef0] [c005c110] do_munmap+0x264/0x2dc
[c2107f20] [c005c1c0] sys_munmap+0x38/0x5c
[c2107f40] [c000d0dc] ret_from_syscall+0x0/0x38
trunk+benh complicated patch:
crashes earlier:
BUG: Bad page map in process swapper pte:001f88e9 pmd:020d8001
addr:7ffffff6 vm_flags:00100177 anon_vma:c20d95e0 mapping:(null) index:7ffff
Call Trace:
[c341fd20] [c00067d0] show_stack+0x44/0x14c (unreliable)
[c341fd60] [c0056860] print_bad_pte+0x1b4/0x1d0
[c341fd90] [c00568c8] vm_normal_page+0x4c/0x78
[c341fda0] [c0056988] follow_page+0x94/0x1b8
[c341fdc0] [c005854c] __get_user_pages+0x324/0x3c4
[c341fe20] [c006c12c] get_arg_page+0x40/0xac
[c341fe40] [c006c374] copy_strings+0xec/0x1d4
[c341fe80] [c006c47c] copy_strings_kernel+0x20/0x38
[c341fea0] [c006d3cc] do_execve+0x110/0x240
[c341fee0] [c00070c4] sys_execve+0x50/0x7c
[c341ff00] [c000d0dc] ret_from_syscall+0x0/0x38
[c341ffc0] [c00023ac] init_post+0x5c/0x168
[c341ffe0] [c01df22c] kernel_init+0x10c/0x124
[c341fff0] [c000cf3c] kernel_thread+0x4c/0x68
this is running on a MPC 875, and I'm happy to test any patches or
add any debugging code if it helps.
thanks!
/rex
^ permalink raw reply
* Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
From: Benjamin Herrenschmidt @ 2009-09-24 0:51 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Gautham R Shenoy, linux-kernel, Venkatesh Pallipadi,
Arun R Bharadwaj, linuxppc-dev, Darrick J. Wong
In-Reply-To: <1253016701.5506.73.camel@laptop>
On Tue, 2009-09-15 at 14:11 +0200, Peter Zijlstra wrote:
> I still think its a layering violation... its the hypervisor manager
> that should be bothered in what state an off-lined cpu is in.
>
That's not how our hypervisor works.
If you ask through the management interface, to remove a CPU from a
partition, the HV will communicate with a daemon inside the partition
that will then unplug the CPU via the right call.
I don't really understand your objections to be honest. And I fail to
see why it would be a layering violation to have the ability for the OS
to indicate in what state it wishes to relinguish a CPU to the
hypervisor, which more or less defines what is the expected latency for
getting it back later on.
Ben.
^ permalink raw reply
* Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
From: Benjamin Herrenschmidt @ 2009-09-24 0:52 UTC (permalink / raw)
To: Heiko Carstens
Cc: Darrick J. Wong, Peter Zijlstra, Gautham R Shenoy,
Venkatesh Pallipadi, linux-kernel, Arun R Bharadwaj, linuxppc-dev,
Balbir Singh
In-Reply-To: <20090916074848.GB4870@osiris.boeblingen.de.ibm.com>
On Wed, 2009-09-16 at 09:48 +0200, Heiko Carstens wrote:
> FWIW, this sounds exactly like the same we have already on s390.
> But back then I didn't consider adding a common code infrastructure
> would make sense :)
>
> Besides the "online" attribute we have an additional "configure"
> attribute to which can only be written if the cpu is offline.
> Writing a "0" to it would mean that you currently won't need the cpu
> anymore and the hypervisor is free to reassign the cpu to a different
> LPAR.
> Writing a "1" to it means you want to use it. If there are enough
> resources you will get it. If not.. bad luck.
>
Maybe we should use a common API for that then. And the right way to do
so is via a generically located attribute.
Ben.
^ permalink raw reply
* Re: [PATCH v3 0/3] cpu: pseries: Cpu offline states framework
From: Benjamin Herrenschmidt @ 2009-09-24 0:55 UTC (permalink / raw)
To: dipankar
Cc: Peter Zijlstra, Gautham R Shenoy, linux-kernel,
Venkatesh Pallipadi, Arun R Bharadwaj, linuxppc-dev,
Darrick J. Wong
In-Reply-To: <20090916162459.GB12571@in.ibm.com>
On Wed, 2009-09-16 at 21:54 +0530, Dipankar Sarma wrote:
> You aren't, I did :)
>
> No, for this specific case, latency isn't an issue. The issue is -
> how do we cede unused vcpus to hypervisor for better energy
> management ?
> Yes, it can be done by a hypervisor manager telling the kernel to
> offline and make a bunch of vcpus "inactive". It does have to choose
> offline (release vcpu) vs. inactive (cede but guranteed if needed).
> The problem is that long ago we exported a lot of hotplug stuff to
> userspace through the sysfs interface and we cannot do something
> inside the kernel without keeping the sysfs stuff consistent.
> This seems like a sane way to do that without undoing all the
> virtual cpu hotplug infrastructure in different supporting archs.
>
Well, I did bring the latency into the picture. To some extent it -is- a
latency issue. Though we aren't talking milliseconds here... if the
CPU's been reallocated to another partition we are talking seconds or
minutes or more until we can get it back :-)
In any case, this sounds to me like a perfectly valid feature to have,
which s390 already does via arch specific hooks, so I fail to see why it
wouldn't be legitimate to have a common attribute for it.
I don't buy into the layering violation. It's too often a straw man and
an excuse for a lack of a proper reason.
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Rex Feany @ 2009-09-24 0:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
After upgrading to the latest kernel on my mpc875 userspace started
running incredibly slow (hours to get to a shell, even!).
I tracked it down to commit 8d30c14cab30d405a05f2aaceda1e9ad57800f36,
that patch removed a work-around for the 8xx. Adding it
back makes my problem go away.
Signed-off-by: Rex Feany <rfeany@mrv.com>
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index 627767d..d8e6725 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -30,6 +30,8 @@
#include <asm/tlbflush.h>
#include <asm/tlb.h>
+#include "mmu_decl.h"
+
static DEFINE_PER_CPU(struct pte_freelist_batch *, pte_freelist_cur);
static unsigned long pte_freelist_forced_free;
@@ -119,7 +121,7 @@ void pte_free_finish(void)
/*
* Handle i/d cache flushing, called from set_pte_at() or ptep_set_access_flags()
*/
-static pte_t do_dcache_icache_coherency(pte_t pte)
+static pte_t do_dcache_icache_coherency(pte_t pte, unsigned long addr)
{
unsigned long pfn = pte_pfn(pte);
struct page *page;
@@ -128,6 +130,17 @@ static pte_t do_dcache_icache_coherency(pte_t pte)
return pte;
page = pfn_to_page(pfn);
+#ifdef CONFIG_8xx
+ /* On 8xx, cache control instructions (particularly
+ * "dcbst" from flush_dcache_icache) fault as write
+ * operation if there is an unpopulated TLB entry
+ * for the address in question. To workaround that,
+ * we invalidate the TLB here, thus avoiding dcbst
+ * misbehaviour.
+ */
+ _tlbil_va(addr, 0 /* 8xx doesn't care about PID */);
+#endif
+
if (!PageReserved(page) && !test_bit(PG_arch_1, &page->flags)) {
pr_devel("do_dcache_icache_coherency... flushing\n");
flush_dcache_icache_page(page);
@@ -198,7 +211,7 @@ void set_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep, pte_t pte
*/
pte = __pte(pte_val(pte) & ~_PAGE_HPTEFLAGS);
if (pte_need_exec_flush(pte, 1))
- pte = do_dcache_icache_coherency(pte);
+ pte = do_dcache_icache_coherency(pte, addr);
/* Perform the setting of the PTE */
__set_pte_at(mm, addr, ptep, pte, 0);
@@ -216,7 +229,7 @@ int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long address,
{
int changed;
if (!dirty && pte_need_exec_flush(entry, 0))
- entry = do_dcache_icache_coherency(entry);
+ entry = do_dcache_icache_coherency(entry, address);
changed = !pte_same(*(ptep), entry);
if (changed) {
if (!(vma->vm_flags & VM_HUGETLB))
^ permalink raw reply related
* Re: [PATCH] powerpc/mm: Fix 40x and 8xx vs. _PAGE_SPECIAL
From: Benjamin Herrenschmidt @ 2009-09-24 1:13 UTC (permalink / raw)
To: Rex Feany; +Cc: linuxppc-dev list, Weirich, Bernhard
In-Reply-To: <20090924005300.GB11737@compile2.chatsunix.int.mrv.com>
On Wed, 2009-09-23 at 17:53 -0700, Rex Feany wrote:
> this is running on a MPC 875, and I'm happy to test any patches or
> add any debugging code if it helps.
Hrm... smells like something screwy in the 8xx PTE handling.
Let me have another look.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Fix 40x and 8xx vs. _PAGE_SPECIAL
From: Benjamin Herrenschmidt @ 2009-09-24 1:40 UTC (permalink / raw)
To: Rex Feany; +Cc: Scott Wood, linuxppc-dev list, Weirich, Bernhard
In-Reply-To: <20090924005300.GB11737@compile2.chatsunix.int.mrv.com>
On Wed, 2009-09-23 at 17:53 -0700, Rex Feany wrote:
> Thus spake Benjamin Herrenschmidt (benh@kernel.crashing.org):
>
> > Bernhard, Rex, please let me know if that works for you.
>
> it doesn't work for me, it crashes differently then before though!
Hrm. This is really strange...
> trunk+benh complicated patch:
>
> crashes earlier:
>
> BUG: Bad page map in process swapper pte:001f88e9 pmd:020d8001
It's complaining because for some reason a PTE ends up with
_PAGE_SPECIAL set which indeed shouldn't be the case for a stack
page which is what is being accessed in our case. However, I have
no idea how that bit ended up being set. The generic code shouldn't
be setting it, and I looked several times at the TLB miss handling
on 8xx and can't find how in hell it would inadvertently set that
bit in the PTE...
Scott, I don't have any 8xx HW, any chance you can have a look at
what's going on here ?
The other bits in there look fine. So something must be whacking
_PAGE_SPECIAL in somewhere or at least whacking 0x8 in there.
Also, _PAGE_HWWRITE isn't set, but the DataTLBError code will
set it when setting dirty, so the page must have been created
pre-dirtied or something... all very weird I must say.
> addr:7ffffff6 vm_flags:00100177 anon_vma:c20d95e0 mapping:(null) index:7ffff
> Call Trace:
> [c341fd20] [c00067d0] show_stack+0x44/0x14c (unreliable)
> [c341fd60] [c0056860] print_bad_pte+0x1b4/0x1d0
> [c341fd90] [c00568c8] vm_normal_page+0x4c/0x78
> [c341fda0] [c0056988] follow_page+0x94/0x1b8
> [c341fdc0] [c005854c] __get_user_pages+0x324/0x3c4
> [c341fe20] [c006c12c] get_arg_page+0x40/0xac
> [c341fe40] [c006c374] copy_strings+0xec/0x1d4
> [c341fe80] [c006c47c] copy_strings_kernel+0x20/0x38
> [c341fea0] [c006d3cc] do_execve+0x110/0x240
> [c341fee0] [c00070c4] sys_execve+0x50/0x7c
> [c341ff00] [c000d0dc] ret_from_syscall+0x0/0x38
> [c341ffc0] [c00023ac] init_post+0x5c/0x168
> [c341ffe0] [c01df22c] kernel_init+0x10c/0x124
> [c341fff0] [c000cf3c] kernel_thread+0x4c/0x68
>
> this is running on a MPC 875, and I'm happy to test any patches or
> add any debugging code if it helps.
>
> thanks!
> /rex
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Fix 40x and 8xx vs. _PAGE_SPECIAL
From: Rex Feany @ 2009-09-24 2:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Scott Wood, linuxppc-dev list, Weirich, Bernhard
In-Reply-To: <1253756434.7103.377.camel@pasglop>
Thus spake Benjamin Herrenschmidt (benh@kernel.crashing.org):
> Hrm. This is really strange...
Is this a problem? in pte-8xx.h you added:
+#define _PAGE_SPECIAL 0x0008 /* SW entry, forced to 0 by the TLB miss */
but there is already this:
#define _PAGE_EXEC 0x0008 /* software: i-cache coherency required */
take care!
/rex.
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Fix 40x and 8xx vs. _PAGE_SPECIAL
From: Benjamin Herrenschmidt @ 2009-09-24 2:53 UTC (permalink / raw)
To: Rex Feany; +Cc: Scott Wood, linuxppc-dev list, Weirich, Bernhard
In-Reply-To: <20090924023840.GA16381@compile2.chatsunix.int.mrv.com>
On Wed, 2009-09-23 at 19:38 -0700, Rex Feany wrote:
> Thus spake Benjamin Herrenschmidt (benh@kernel.crashing.org):
>
> > Hrm. This is really strange...
>
> Is this a problem? in pte-8xx.h you added:
>
> +#define _PAGE_SPECIAL 0x0008 /* SW entry, forced to 0 by the TLB miss */
>
> but there is already this:
>
> #define _PAGE_EXEC 0x0008 /* software: i-cache coherency required */
Ohhh... you aren't using upstream ! That explains :-)
I removed _PAGE_EXEC from 8xx (since it doesn't use it for anything)
recently.
I think the best option is to go for Bernhard's patch for "stable" and
my patch for upstream, so that "stable" gets the bug fix without the
feature of _PAGE_SPECIAL and upstream gets it both.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 00/10] Add support for GCC's __builtin_unreachable() and use it in BUG.
From: Benjamin Herrenschmidt @ 2009-09-24 3:37 UTC (permalink / raw)
To: David Daney
Cc: linux-mips, Heiko Carstens, linuxppc-dev, Paul Mackerras,
H. Peter Anvin, linux-s390, linux-am33-list, Helge Deller, x86,
Ingo Molnar, Mike Frysinger, Ivan Kokshaysky, uclinux-dist-devel,
Thomas Gleixner, Richard Henderson, Haavard Skinnemoen,
linux-parisc, ralf, Kyle McMartin, linux-alpha,
Martin Schwidefsky, linux390, Andrew Morton, Koichi Yasutake,
Linus Torvalds
In-Reply-To: <4AA991C1.1050800@caviumnetworks.com>
On Thu, 2009-09-10 at 16:54 -0700, David Daney wrote:
> Starting with version 4.5, GCC has a new built-in function called
> __builtin_unreachable(). The function tells the compiler that control
> flow will never reach that point. Currently we trick the compiler by
> putting in for(;;); but this has the disadvantage that extra code is
> emitted for an endless loop. For an i386 kernel using
> __builtin_unreachable() results in an allyesconfig that is nearly 4000
> bytes smaller.
For the powerpc part:
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Re: [v6 PATCH 0/7]: cpuidle/x86/POWER: Cleanup idle power management code in x86, cleanup drivers/cpuidle/cpuidle.c and introduce cpuidle to POWER.
From: Arun R Bharadwaj @ 2009-09-24 5:12 UTC (permalink / raw)
To: Len Brown, Peter Zijlstra, Joel Schopp, Benjamin Herrenschmidt,
Paul Mackerras, Ingo Molnar, Vaidyanathan Srinivasan,
Dipankar Sarma, Balbir Singh, Gautham R Shenoy, Shaohua Li,
Venkatesh Pallipadi, Arun Bharadwaj
Cc: linux-acpi, linuxppc-dev, linux-kernel
In-Reply-To: <20090922112526.GA7788@linux.vnet.ibm.com>
* Arun R Bharadwaj <arun@linux.vnet.ibm.com> [2009-09-22 16:55:27]:
Hi Len, (or other acpi folks),
I had a question regarding ACPI-cpuidle interaction in the current
implementation.
Currently, every cpu (i.e. acpi_processor) registers to cpuidle as
a cpuidle_device. So every cpu has to go through the process of
setting up the idle states and then registering as a cpuidle device.
What exactly is the reason behind this?
Is this really necessary or can we have a system-wide one-time registering
to cpuidle by ACPI?
I'm currently in the process of enabling cpuidle for POWER systems and
find that having a system-wide registering mechanism to be a cleaner
design.
--arun
^ permalink raw reply
* linux-next: tree build failure
From: Stephen Rothwell @ 2009-09-24 5:21 UTC (permalink / raw)
To: ppc-dev
Cc: Hollis Blanchard, linux-kernel, kvm-ppc, linux-next, Jan Beulich,
Andrew Morton
Hi all,
Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
In file included from arch/powerpc/kvm/booke.c:31:
arch/powerpc/kvm/timing.h: In function 'kvmppc_account_exit_stat':
arch/powerpc/kvm/timing.h:51: error: bit-field '<anonymous>' width not an integer constant
In file included from arch/powerpc/kvm/booke.h:26,
from arch/powerpc/kvm/booke_emulate.c:23:
arch/powerpc/kvm/timing.h: In function 'kvmppc_account_exit_stat':
arch/powerpc/kvm/timing.h:51: error: bit-field '<anonymous>' width not an integer constant
Presumably caused by commit 8c87df457cb58fe75b9b893007917cf8095660a0
("BUILD_BUG_ON(): fix it and a couple of bogus uses of it").
I applied the following patch for today. This inline function is
only called from one place in one file ...
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 24 Sep 2009 15:13:20 +1000
Subject: [PATCH] powerpc/kvm: build fix for new BUILD_BUG_ON
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kvm/timing.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kvm/timing.h b/arch/powerpc/kvm/timing.h
index bb13b1f..4c34099 100644
--- a/arch/powerpc/kvm/timing.h
+++ b/arch/powerpc/kvm/timing.h
@@ -48,7 +48,7 @@ static inline void kvmppc_set_exit_type(struct kvm_vcpu *vcpu, int type) {}
static inline void kvmppc_account_exit_stat(struct kvm_vcpu *vcpu, int type)
{
/* type has to be known at build time for optimization */
- BUILD_BUG_ON(__builtin_constant_p(type));
+ //BUILD_BUG_ON(__builtin_constant_p(type));
switch (type) {
case EXT_INTR_EXITS:
vcpu->stat.ext_intr_exits++;
--
1.6.4.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
^ permalink raw reply related
* [PATCH] Fix build of cpm_uart due to core changes
From: Benjamin Herrenschmidt @ 2009-09-24 6:09 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: alan
Commit ebd2c8f6d2ec4012c267ecb95e72a57b8355a705
"serial: kill off uart_info"
broke the build of this driver, possibly because the driver isn't
in drivers/serial and thus was missed by Alan. This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Vitaly: Care to send a patch to move the whole driver to drivers/serial where
it belongs or there's too many nasty dependencies to headers inside of
arch/powerpc/ ?
In the meantime, I'll put that in my merge branch which I'll ask Linus to
pull hopefully tomorrow (waiting for a test result from Rex to see if the
8xx problems are all gone)
Cheers,
Ben.
---
diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c b/drivers/serial/cpm_uart/cpm_uart_core.c
index 8d349b2..300cea7 100644
--- a/drivers/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/serial/cpm_uart/cpm_uart_core.c
@@ -649,7 +649,7 @@ static int cpm_uart_tx_pump(struct uart_port *port)
u8 *p;
int count;
struct uart_cpm_port *pinfo = (struct uart_cpm_port *)port;
- struct circ_buf *xmit = &port->info->xmit;
+ struct circ_buf *xmit = &port->state->xmit;
/* Handle xon/xoff */
if (port->x_char) {
^ permalink raw reply related
* Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite
From: Benjamin Herrenschmidt @ 2009-09-24 6:44 UTC (permalink / raw)
To: Rex Feany; +Cc: linuxppc-dev
In-Reply-To: <20090924004552.GA11737@compile2.chatsunix.int.mrv.com>
On Wed, 2009-09-23 at 17:45 -0700, Rex Feany wrote:
> After upgrading to the latest kernel on my mpc875 userspace started
> running incredibly slow (hours to get to a shell, even!).
> I tracked it down to commit 8d30c14cab30d405a05f2aaceda1e9ad57800f36,
> that patch removed a work-around for the 8xx. Adding it
> back makes my problem go away.
>
> Signed-off-by: Rex Feany <rfeany@mrv.com>
Note that while your patch applies to earlier kernels such as 2.6.31, it
doesn't apply with current Linus tree due to changes in that file. I've
updated the powerpc "merge" branch of my tree with a hand-modified
version, please test and let me know. That should also contain the
_PAGE_SPECIAL fix.
You can get my tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
(To get the "merge" branch, just add "merge" after the clone if you
are cloning it, or just create a local branch and manually pull
into it)
Note that i just pushed out so it may take a little while for
the kernel.org mirrors to get it, the commit ID is:
ae48e383e3299c2f87723d21df2db97927774b1e
Cheers,
Ben.
> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
> index 627767d..d8e6725 100644
> --- a/arch/powerpc/mm/pgtable.c
> +++ b/arch/powerpc/mm/pgtable.c
> @@ -30,6 +30,8 @@
> #include <asm/tlbflush.h>
> #include <asm/tlb.h>
>
> +#include "mmu_decl.h"
> +
> static DEFINE_PER_CPU(struct pte_freelist_batch *, pte_freelist_cur);
> static unsigned long pte_freelist_forced_free;
>
> @@ -119,7 +121,7 @@ void pte_free_finish(void)
> /*
> * Handle i/d cache flushing, called from set_pte_at() or ptep_set_access_flags()
> */
> -static pte_t do_dcache_icache_coherency(pte_t pte)
> +static pte_t do_dcache_icache_coherency(pte_t pte, unsigned long addr)
> {
> unsigned long pfn = pte_pfn(pte);
> struct page *page;
> @@ -128,6 +130,17 @@ static pte_t do_dcache_icache_coherency(pte_t pte)
> return pte;
> page = pfn_to_page(pfn);
>
> +#ifdef CONFIG_8xx
> + /* On 8xx, cache control instructions (particularly
> + * "dcbst" from flush_dcache_icache) fault as write
> + * operation if there is an unpopulated TLB entry
> + * for the address in question. To workaround that,
> + * we invalidate the TLB here, thus avoiding dcbst
> + * misbehaviour.
> + */
> + _tlbil_va(addr, 0 /* 8xx doesn't care about PID */);
> +#endif
> +
> if (!PageReserved(page) && !test_bit(PG_arch_1, &page->flags)) {
> pr_devel("do_dcache_icache_coherency... flushing\n");
> flush_dcache_icache_page(page);
> @@ -198,7 +211,7 @@ void set_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep, pte_t pte
> */
> pte = __pte(pte_val(pte) & ~_PAGE_HPTEFLAGS);
> if (pte_need_exec_flush(pte, 1))
> - pte = do_dcache_icache_coherency(pte);
> + pte = do_dcache_icache_coherency(pte, addr);
>
> /* Perform the setting of the PTE */
> __set_pte_at(mm, addr, ptep, pte, 0);
> @@ -216,7 +229,7 @@ int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long address,
> {
> int changed;
> if (!dirty && pte_need_exec_flush(entry, 0))
> - entry = do_dcache_icache_coherency(entry);
> + entry = do_dcache_icache_coherency(entry, address);
> changed = !pte_same(*(ptep), entry);
> if (changed) {
> if (!(vma->vm_flags & VM_HUGETLB))
^ permalink raw reply
* Re: [PATCH] Fix build of cpm_uart due to core changes
From: Benjamin Herrenschmidt @ 2009-09-24 7:01 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: alan
In-Reply-To: <1253772553.7103.402.camel@pasglop>
On Thu, 2009-09-24 at 16:09 +1000, Benjamin Herrenschmidt wrote:
> Commit ebd2c8f6d2ec4012c267ecb95e72a57b8355a705
> "serial: kill off uart_info"
>
> broke the build of this driver, possibly because the driver isn't
> in drivers/serial and thus was missed by Alan. This fixes it.
I must have a serious amount of shit in my eyes :-) For some reason
I was persuaded the driver was in arch/powerpc .. well, it -is- in
drivers/serial, so yes, Alan did miss it somewhat but not because
it was in the wrong place :-)
Patch is still good tho, I'll fix up the comment in my tree.
Sorry,
Ben.
^ permalink raw reply
* Bunch of fixes for upstream
From: Benjamin Herrenschmidt @ 2009-09-24 7:05 UTC (permalink / raw)
To: linuxppc-dev list
Here's what I'll ask Linus to pull tomorrow, currently sitting in
powerpc merge branch:
Anton Blanchard (4):
powerpc: Move 64bit heap above 1TB on machines with 1TB segments
powerpc/perf_counter: Fix vdso detection
powerpc: Increase NODES_SHIFT on 64bit from 4 to 8
powerpc: Fix ibm,client-architecture-support printout
Becky Bruce (2):
powerpc: Rename get_dma_direct_offset get_dma_offset
powerpc: Change archdata dma_data to a union
Benjamin Herrenschmidt (3):
powerpc/pmc: Don't access lppaca on Book3E
powerpc/mm: Fix 40x and 8xx vs. _PAGE_SPECIAL
Fix build of cpm_uart due to core changes
Hendrik Brueckner (1):
hvc_console: Provide (un)locked version for hvc_resize()
Huang Weiyi (2):
powerpc/book3e-64: Remove duplicated #include
powerpc/mm: Remove duplicated #include
Josh Boyer (1):
powerpc/4xx: Fix erroneous xmon warning on PowerPC 4xx
Rex Feany (1):
powerpc/8xx: Fix regression introduced by cache coherency rewrite
Tim Abbott (1):
powerpc: Cleanup linker script using new linker script macros.
Tony Breeds (1):
powerpc: Check for unsupported relocs when using CONFIG_RELOCATABLE
roel kluin (1):
powerpc: kmalloc failure ignored in vio_build_iommu_table()
arch/powerpc/Kconfig | 6 +++
arch/powerpc/Makefile | 11 +++++
arch/powerpc/include/asm/device.h | 11 ++++-
arch/powerpc/include/asm/dma-mapping.h | 27 ++++++++++-
arch/powerpc/include/asm/iommu.h | 10 ++++
arch/powerpc/include/asm/pmc.h | 2 +-
arch/powerpc/include/asm/pte-40x.h | 1 +
arch/powerpc/include/asm/pte-8xx.h | 1 +
arch/powerpc/include/asm/pte-common.h | 5 --
arch/powerpc/kernel/dma-iommu.c | 16 +++---
arch/powerpc/kernel/dma.c | 15 ++-----
arch/powerpc/kernel/exceptions-64e.S | 1 -
arch/powerpc/kernel/pci-common.c | 2 +-
arch/powerpc/kernel/process.c | 17 +++++++-
arch/powerpc/kernel/prom_init.c | 3 +-
arch/powerpc/kernel/vdso.c | 14 ++++--
arch/powerpc/kernel/vio.c | 4 +-
arch/powerpc/kernel/vmlinux.lds.S | 69 ++++++-----------------------
arch/powerpc/mm/pgtable.c | 19 +++++++-
arch/powerpc/mm/tlb_low_64e.S | 1 -
arch/powerpc/platforms/cell/beat_iommu.c | 2 +-
arch/powerpc/platforms/cell/iommu.c | 9 +---
arch/powerpc/platforms/iseries/iommu.c | 2 +-
arch/powerpc/platforms/pasemi/iommu.c | 2 +-
arch/powerpc/platforms/pseries/iommu.c | 8 ++--
arch/powerpc/relocs_check.pl | 56 ++++++++++++++++++++++++
arch/powerpc/sysdev/dart_iommu.c | 2 +-
arch/powerpc/xmon/xmon.c | 16 ++++++-
drivers/char/hvc_console.c | 6 +-
drivers/char/hvc_console.h | 12 +++++-
drivers/char/hvc_iucv.c | 4 +-
drivers/serial/cpm_uart/cpm_uart_core.c | 2 +-
32 files changed, 237 insertions(+), 119 deletions(-)
create mode 100755 arch/powerpc/relocs_check.pl
^ permalink raw reply
* [PATCH-stable] powerpc/8xx: Fix regression introduced by cache coherency rewrite
From: Benjamin Herrenschmidt @ 2009-09-24 7:16 UTC (permalink / raw)
To: stable; +Cc: linuxppc-dev list, RFeany
From: Rex Feany <RFeany@mrv.com>
After upgrading to the latest kernel on my mpc875 userspace started
running incredibly slow (hours to get to a shell, even!).
I tracked it down to commit 8d30c14cab30d405a05f2aaceda1e9ad57800f36,
that patch removed a work-around for the 8xx. Adding it
back makes my problem go away.
Signed-off-by: Rex Feany <rfeany@mrv.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/mm/pgtable.c | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
I'm going to push an upstream variant of this patch upstream tomorrow,
it will be a bit different due to significant changes in that file
and the affected functions.
This should apply to v2.6.30 (with fuzz) and v2.6.31
diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
index 627767d..d8e6725 100644
--- a/arch/powerpc/mm/pgtable.c
+++ b/arch/powerpc/mm/pgtable.c
@@ -30,6 +30,8 @@
#include <asm/tlbflush.h>
#include <asm/tlb.h>
+#include "mmu_decl.h"
+
static DEFINE_PER_CPU(struct pte_freelist_batch *, pte_freelist_cur);
static unsigned long pte_freelist_forced_free;
@@ -119,7 +121,7 @@ void pte_free_finish(void)
/*
* Handle i/d cache flushing, called from set_pte_at() or ptep_set_access_flags()
*/
-static pte_t do_dcache_icache_coherency(pte_t pte)
+static pte_t do_dcache_icache_coherency(pte_t pte, unsigned long addr)
{
unsigned long pfn = pte_pfn(pte);
struct page *page;
@@ -128,6 +130,17 @@ static pte_t do_dcache_icache_coherency(pte_t pte)
return pte;
page = pfn_to_page(pfn);
+#ifdef CONFIG_8xx
+ /* On 8xx, cache control instructions (particularly
+ * "dcbst" from flush_dcache_icache) fault as write
+ * operation if there is an unpopulated TLB entry
+ * for the address in question. To workaround that,
+ * we invalidate the TLB here, thus avoiding dcbst
+ * misbehaviour.
+ */
+ _tlbil_va(addr, 0 /* 8xx doesn't care about PID */);
+#endif
+
if (!PageReserved(page) && !test_bit(PG_arch_1, &page->flags)) {
pr_devel("do_dcache_icache_coherency... flushing\n");
flush_dcache_icache_page(page);
@@ -198,7 +211,7 @@ void set_pte_at(struct mm_struct *mm, unsigned long addr, pte_t *ptep, pte_t pte
*/
pte = __pte(pte_val(pte) & ~_PAGE_HPTEFLAGS);
if (pte_need_exec_flush(pte, 1))
- pte = do_dcache_icache_coherency(pte);
+ pte = do_dcache_icache_coherency(pte, addr);
/* Perform the setting of the PTE */
__set_pte_at(mm, addr, ptep, pte, 0);
@@ -216,7 +229,7 @@ int ptep_set_access_flags(struct vm_area_struct *vma, unsigned long address,
{
int changed;
if (!dirty && pte_need_exec_flush(entry, 0))
- entry = do_dcache_icache_coherency(entry);
+ entry = do_dcache_icache_coherency(entry, address);
changed = !pte_same(*(ptep), entry);
if (changed) {
if (!(vma->vm_flags & VM_HUGETLB))
^ permalink raw reply related
* [PATCH-stable] powerpc: Fix incorrect setting of __HAVE_ARCH_PTE_SPECIAL
From: Benjamin Herrenschmidt @ 2009-09-24 7:16 UTC (permalink / raw)
To: stable; +Cc: linuxppc-dev list, bernhard.weirich, RFeany
From: Weirich, Bernhard <Bernhard.Weirich@riedel.net>
The test that decides whether to define __HAVE_ARCH_PTE_SPECIAL on
powerpc is bogus and will end up always defining it, even when
_PAGE_SPECIAL is not supported (in which case it's 0) such as on
8xx or 40x processors.
Signed-off-by: Bernhard Weirich <bernhard.weirich@riedel.net>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/pte-common.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Greg: I'm going to fix upstream differently, by having all CPU types
actually support _PAGE_SPECIAL, but I prefer the simple and obvious
fix for -stable.
This should apply to v2.6.30 and v2.6.31
diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h
index a7e210b..0cd2e34 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -176,7 +176,7 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
#define HAVE_PAGE_AGP
/* Advertise support for _PAGE_SPECIAL */
-#ifdef _PAGE_SPECIAL
+#if _PAGE_SPECIAL != 0
#define __HAVE_ARCH_PTE_SPECIAL
#endif
^ permalink raw reply related
* Re: [PATCH v3] xilinx_spi: Splitted into generic, of and platform driver, added support for DS570
From: Richard Röjfors @ 2009-09-24 7:36 UTC (permalink / raw)
To: John Linn; +Cc: spi-devel-general, Andrew Morton, dbrownell, linuxppc-dev
In-Reply-To: <20090923224452.EAAFEB48046@mail109-sin.bigfish.com>
Hi again,
John Linn wrote:
>> -----Original Message-----
>> From: Richard Röjfors [mailto:richard.rojfors@mocean-labs.com]
>> Sent: Tuesday, September 22, 2009 3:59 PM
>> To: John Linn
>> Cc: spi-devel-general@lists.sourceforge.net; linuxppc-dev@ozlabs.org; Andrew Morton;
>> dbrownell@users.sourceforge.net
>> Subject: Re: [PATCH v3] xilinx_spi: Splitted into generic, of and platform driver, added support for
>> DS570
>>
>> John Linn wrote:
>>>> -----Original Message-----
>>>> From: linuxppc-dev-bounces+john.linn=xilinx.com@lists.ozlabs.org [mailto:linuxppc-dev-
>>>> bounces+john.linn=xilinx.com@lists.ozlabs.org] On Behalf Of Richard Röjfors
>>>> Sent: Tuesday, September 22, 2009 6:55 AM
>>>> To: spi-devel-general@lists.sourceforge.net
>>>> Cc: linuxppc-dev@ozlabs.org; Andrew Morton; dbrownell@users.sourceforge.net
>>>> Subject: [PATCH v3] xilinx_spi: Splitted into generic, of and platform driver, added support for
>>>> DS570
>>>>
>>>> This patch splits xilinx_spi into three parts, an OF and a platform
>>>> driver and generic part.
>>>>
>>>> The generic part now also works on X86 and also supports the Xilinx
>>>> SPI IP DS570
>>> Hi Richard,
>> Hi John,
>>
>>> The current driver (without this change) works for the newer XPS SPI device already as I run tests
>> on it each day using an SPI EEPROM.
>>
>> I'm not an expert of the Xilinx SPI blocks, I have only used one, the DS570.
>>
>> I don't think you use the DS570. I don't have the datasheet of the older one, but the register
>> offsets of the DS570 don't match the driver you are using. All the registers of the DS570 are at 4
>> bytes boundries.
>>
>
> I just verified that I am using the same IP block as you are, the DS570. But I'm not testing on the other IP you mention, the DS464.
Hi,
I have now verified the differences. Actually the blocks are register offset compatible. Since the
DS464 is 8 bit only, the driver is made to do only 8 bit accesses to some registers, for instance
TXD. On the 570 we have to do 32 bit (or at least 16) as the driver now support more than 8bit SPI.
We test against some SPI devices that are 16 bit.
The offsets in the code differs from the datasheet because since the device is big endian -> an 8
bit access to must happen 3 bytes up from the register base.
For instance the TXD register is defined at 0x6b, while the spec says 0x68. 0x68 + 0x3 = 0x6b. To
support more than 8 bit, we must do 16 bit access at 0x6a or 32 bit at 0x68.
To summarize;
You are completely right you can use the "old" driver on the DS570 as well, but _only_ for 8bit SPI.
My patch allows to run on X86 and with 16 or 32bit SPI.
Thanks to the observation from you, I got aware of the differences. I can simplify the code by
automatically increase registers offsets when doing 8 or 16 bits accesses.
I will come back with an updated patch.
Hope I made the situation clearer.
--Richard
^ permalink raw reply
* Re: [PATCH v2 0/2] cpu: pseries: Offline state framework.
From: Peter Zijlstra @ 2009-09-24 7:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Gautham R Shenoy, Venkatesh Pallipadi, linux-kernel, linuxppc-dev,
Darrick J. Wong
In-Reply-To: <1253753307.7103.356.camel@pasglop>
On Thu, 2009-09-24 at 10:48 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2009-09-02 at 07:33 +0200, Peter Zijlstra wrote:
> >
> > I'm still thinking this is a bad idea.
> >
> > The OS should only know about online/offline.
> >
> > Use the hypervisor interface to deal with the cpu once its offline.
> >
> > That is, I think this interface you propose is a layering violation.
> >
> I don't quite follow your logic here. This is useful for more than just
> hypervisors. For example, take the HV out of the picture for a moment
> and imagine that the HW has the ability to offline CPU in various power
> levels, with varying latencies to bring them back.
cpu-hotplug is an utter slow path, anybody saying latency and hotplug in
the same sentence doesn't seem to grasp either or both concepts.
^ permalink raw reply
* Re: 2.6.31-git5 kernel boot hangs on powerpc
From: Sachin Sant @ 2009-09-24 7:58 UTC (permalink / raw)
To: Tejun Heo; +Cc: Linux/PPC Development, David Miller
In-Reply-To: <4ABA2DE2.6000601@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 470 bytes --]
Tejun Heo wrote:
> Can you please apply the attached patch and see whether anything
> interesting shows up in the kernel log?
>
Thanks Tejun for the debug patch. Attached here are the relevant logs.
The only messages related to percpu in the logs are
<6>PERCPU: Embedded 2 pages/cpu @c000000001200000 s100232 r0 d30840 u524288
<7>pcpu-alloc: s100232 r0 d30840 u524288 alloc=1*1048576
<7>pcpu-alloc: [0] 0 1
The captured logs are with latest git.
Thanks
-Sachin
[-- Attachment #2: dmesg-log --]
[-- Type: text/plain, Size: 9259 bytes --]
<4>Crash kernel location must be 0x2000000
<6>Reserving 256MB of memory at 32MB for crashkernel (System RAM: 4096MB)
<6>Phyp-dump disabled at boot time
<6>Using pSeries machine description
<7>Page orders: linear mapping = 16, virtual = 16, io = 12
<6>Using 1TB segments
<4>Found initrd at 0xc000000003500000:0xc000000003ccdf60
<6>bootconsole [udbg0] enabled
<6>Partition configured for 2 cpus.
<6>CPU maps initialized for 2 threads per core
<7> (thread shift is 1)
<4>Starting Linux PPC64 #2 SMP Thu Sep 24 12:59:21 IST 2009
<4>-----------------------------------------------------
<4>ppc64_pft_size = 0x1a
<4>physicalMemorySize = 0x100000000
<4>htab_hash_mask = 0x7ffff
<4>-----------------------------------------------------
<6>Initializing cgroup subsys cpuset
<6>Initializing cgroup subsys cpu
<5>Linux version 2.6.31-git13-autotest (root@mpower6lp5) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #2 SMP Thu Sep 24 12:59:21 IST 2009
<4>[boot]0012 Setup Arch
<7>Node 0 Memory:
<7>Node 2 Memory: 0x0-0xe0000000
<7>Node 3 Memory: 0xe0000000-0x100000000
<4>EEH: No capable adapters found
<6>PPC64 nvram contains 15360 bytes
<7>Using shared processor idle loop
<4>Zone PFN ranges:
<4> DMA 0x00000000 -> 0x00010000
<4> Normal 0x00010000 -> 0x00010000
<4>Movable zone start PFN for each node
<4>early_node_map[2] active PFN ranges
<4> 2: 0x00000000 -> 0x0000e000
<4> 3: 0x0000e000 -> 0x00010000
<4>Could not find start_pfn for node 0
<7>On node 0 totalpages: 0
<7>On node 2 totalpages: 57344
<7> DMA zone: 56 pages used for memmap
<7> DMA zone: 0 pages reserved
<7> DMA zone: 57288 pages, LIFO batch:1
<7>On node 3 totalpages: 8192
<7> DMA zone: 8 pages used for memmap
<7> DMA zone: 0 pages reserved
<7> DMA zone: 8184 pages, LIFO batch:0
<4>[boot]0015 Setup Done
<6>PERCPU: Embedded 2 pages/cpu @c000000001200000 s100232 r0 d30840 u524288
<7>pcpu-alloc: s100232 r0 d30840 u524288 alloc=1*1048576
<7>pcpu-alloc: [0] 0 1
<4>Built 3 zonelists in Node order, mobility grouping on. Total pages: 65472
<4>Policy zone: DMA
<5>Kernel command line: root=/dev/sda3 sysrq=8 insmod=sym53c8xx insmod=ipr crashkernel=512M-:256M xmon=early
<6>PID hash table entries: 4096 (order: -1, 32768 bytes)
<4>freeing bootmem node 2
<4>freeing bootmem node 3
<6>Memory: 3896832k/4194304k available (9728k kernel code, 297472k reserved, 3072k data, 4291k bss, 576k init)
<6>SLUB: Genslabs=18, HWalign=128, Order=0-3, MinObjects=0, CPUs=2, Nodes=16
<6>Hierarchical RCU implementation.
<6>RCU-based detection of stalled CPUs is enabled.
<6>NR_IRQS:512
<4>[boot]0020 XICS Init
<4>[boot]0021 XICS Done
<7>pic: no ISA interrupt controller
<7>time_init: decrementer frequency = 512.000000 MHz
<7>time_init: processor frequency = 4704.000000 MHz
<6>clocksource: timebase mult[7d0000] shift[22] registered
<7>clockevent: decrementer mult[83126e97] shift[32] cpu[0]
<4>Console: colour dummy device 80x25
<6>console [hvc0] enabled, bootconsole disabled
<6>allocated 2621440 bytes of page_cgroup
<6>please try 'cgroup_disable=memory' option if you don't want memory cgroups
<6>Security Framework initialized
<6>SELinux: Disabled at boot.
<6>Dentry cache hash table entries: 524288 (order: 6, 4194304 bytes)
<6>Inode-cache hash table entries: 262144 (order: 5, 2097152 bytes)
<4>Mount-cache hash table entries: 4096
<6>Initializing cgroup subsys ns
<6>Initializing cgroup subsys cpuacct
<6>Initializing cgroup subsys memory
<6>Initializing cgroup subsys devices
<6>Initializing cgroup subsys freezer
<7>irq: irq 2 on host null mapped to virtual irq 16
<7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
<4>Processor 1 found.
<6>Brought up 2 CPUs
<7>Node 0 CPUs: 0-1
<7>Node 2 CPUs:
<7>Node 3 CPUs:
<7>CPU0 attaching sched-domain:
<7> domain 0: span 0-1 level SIBLING
<7> groups: 0 (cpu_power = 589) 1 (cpu_power = 589)
<7> domain 1: span 0-1 level CPU
<7> groups: 0-1 (cpu_power = 1178)
<7>CPU1 attaching sched-domain:
<7> domain 0: span 0-1 level SIBLING
<7> groups: 1 (cpu_power = 589) 0 (cpu_power = 589)
<7> domain 1: span 0-1 level CPU
<7> groups: 0-1 (cpu_power = 1178)
<6>NET: Registered protocol family 16
<6>IBM eBus Device Driver
<6>POWER6 performance monitor hardware support registered
<6>PCI: Probing PCI hardware
<7>PCI: Probing PCI hardware done
<4>bio: create slab <bio-0> at 0
<6>vgaarb: loaded
<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>Switching to clocksource timebase
<6>NET: Registered protocol family 2
<6>IP route cache hash table entries: 32768 (order: 2, 262144 bytes)
<6>TCP established hash table entries: 131072 (order: 5, 2097152 bytes)
<6>TCP bind hash table entries: 65536 (order: 5, 2097152 bytes)
<6>TCP: Hash tables configured (established 131072 bind 65536)
<6>TCP reno registered
<6>NET: Registered protocol family 1
<6>Unpacking initramfs...
<7>Switched to high resolution mode on CPU 0
<7>Switched to high resolution mode on CPU 1
<7>irq: irq 655360 on host null mapped to virtual irq 17
<7>irq: irq 655367 on host null mapped to virtual irq 18
<6>IOMMU table initialized, virtual merging enabled
<7>irq: irq 589825 on host null mapped to virtual irq 19
<7>RTAS daemon started
<6>audit: initializing netlink socket (disabled)
<5>type=2000 audit(1253778214.210:1): initialized
<6>Kprobe smoke test started
<6>Kprobe smoke test passed successfully
<6>HugeTLB registered 16 MB page size, pre-allocated 0 pages
<6>HugeTLB registered 16 GB page size, pre-allocated 0 pages
<5>VFS: Disk quotas dquot_6.5.2
<4>Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
<6>Btrfs loaded
<6>msgmni has been set to 7608
<6>alg: No test for stdrng (krng)
<6>Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
<6>io scheduler noop registered
<6>io scheduler anticipatory registered
<6>io scheduler deadline registered
<6>io scheduler cfq registered (default)
<6>pci_hotplug: PCI Hot Plug PCI Core version: 0.5
<6>rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
<7>vio_register_driver: driver hvc_console registering
<7>HVSI: registered 0 devices
<6>Generic RTC Driver v1.07
<6>Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
<6>pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
<6>input: Macintosh mouse button emulation as /devices/virtual/input/input0
<6>Uniform Multi-Platform E-IDE driver
<6>ide-gd driver 1.18
<6>IBM eHEA ethernet device driver (Release EHEA_0102)
<7>irq: irq 590088 on host null mapped to virtual irq 264
<6>ehea: eth0: Jumbo frames are disabled
<6>ehea: eth0 -> logical port id #2
<6>ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
<6>ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
<6>mice: PS/2 mouse device common for all mice
<6>EDAC MC: Ver: 2.1.0 Sep 24 2009
<6>usbcore: registered new interface driver hiddev
<6>usbcore: registered new interface driver usbhid
<6>usbhid: v2.6:USB HID core driver
<6>TCP cubic registered
<6>NET: Registered protocol family 15
<4>registered taskstats version 1
<4>Freeing unused kernel memory: 576k freed
<6>SysRq : Changing Loglevel
<4>Loglevel set to 8
<5>SCSI subsystem initialized
<7>vio_register_driver: driver ibmvscsi registering
<6>ibmvscsi 30000007: SRP_VERSION: 16.a
<6>scsi0 : IBM POWER Virtual SCSI Adapter 1.5.8
<6>ibmvscsi 30000007: partner initialization complete
<6>ibmvscsi 30000007: host srp version: 16.a, host partition VIO Server (1), OS 3, max io 1048576
<6>ibmvscsi 30000007: Client reserve enabled
<6>ibmvscsi 30000007: sent SRP login
<6>ibmvscsi 30000007: SRP_LOGIN succeeded
<5>scsi 0:0:1:0: Direct-Access AIX VDASD 0001 PQ: 0 ANSI: 3
<5>scsi 0:0:2:0: CD-ROM AIX VOPTA PQ: 0 ANSI: 4
<6>udevd version 128 started
<5>sd 0:0:1:0: [sda] 146800640 512-byte logical blocks: (75.1 GB/70.0 GiB)
<5>sd 0:0:1:0: [sda] Write Protect is off
<7>sd 0:0:1:0: [sda] Mode Sense: 17 00 00 08
<5>sd 0:0:1:0: [sda] Cache data unavailable
<3>sd 0:0:1:0: [sda] Assuming drive cache: write through
<5>sd 0:0:1:0: [sda] Cache data unavailable
<3>sd 0:0:1:0: [sda] Assuming drive cache: write through
<6> sda: sda1 sda2 sda3
<5>sd 0:0:1:0: [sda] Cache data unavailable
<3>sd 0:0:1:0: [sda] Assuming drive cache: write through
<5>sd 0:0:1:0: [sda] Attached SCSI disk
<6>kjournald starting. Commit interval 5 seconds
<6>EXT3 FS on sda3, internal journal
<6>EXT3-fs: mounted filesystem with writeback data mode.
<6>udevd version 128 started
<5>sd 0:0:1:0: Attached scsi generic sg0 type 0
<5>scsi 0:0:2:0: Attached scsi generic sg1 type 5
<4>sr0: scsi-1 drive
<6>Uniform CD-ROM driver Revision: 3.20
<7>sr 0:0:2:0: Attached scsi CD-ROM sr0
<6>Adding 2096320k swap on /dev/sda2. Priority:-1 extents:1 across:2096320k
<6>device-mapper: uevent: version 1.0.3
<6>device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com
<6>loop: module loaded
<6>fuse init (API version 7.13)
<7>irq: irq 33539 on host null mapped to virtual irq 259
<6>ehea: eth0: Physical port up
<6>ehea: External switch port is backup port
<7>irq: irq 33540 on host null mapped to virtual irq 260
<6>NET: Registered protocol family 10
<3>INFO: RCU detected CPU 0 stall (t=1000 jiffies)
^ permalink raw reply
* RE: [PATCH 6/6] P2020DS: Remove sdhci-dma-broken and sdhci-ahb2mag-irq-bypass properties
From: Gao Guanhua-B22826 @ 2009-09-24 8:22 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, sdhci-devel
In-Reply-To: <20090923115954.GC6425@oksana.dev.rtsoft.ru>
=20
> -----Original Message-----
> From: Anton Vorontsov [mailto:avorontsov@ru.mvista.com]=20
> Sent: Wednesday, September 23, 2009 8:00 PM
> To: Gao Guanhua-B22826
> Cc: sdhci-devel@lists.ossman.eu; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 6/6] P2020DS: Remove sdhci-dma-broken and=20
> sdhci-ahb2mag-irq-bypass properties
>=20
> On Wed, Sep 23, 2009 at 05:08:12PM +0800, Gao Guanhua wrote:
> > The SDHC on P2020DS board use DMA mode by default.
> > This patch remove the properties used in PIO mode.
>=20
> You just added the properties in 3/6 and 4/6, and now you=20
> instantly remove them?
Add them to support the PIO mode, the board has a hardware bug, sdhc can
only work in PIO mode.
Then the bug has been fixed. So remove those properties.
Yes, maybe I shouldnot add the property in the dts, and only support PIO
in driver.
Thanks.
>=20
> > ---
> > arch/powerpc/boot/dts/p2020ds.dts | 2 --
> > 1 files changed, 0 insertions(+), 2 deletions(-)
> >=20
> > diff --git a/arch/powerpc/boot/dts/p2020ds.dts=20
> > b/arch/powerpc/boot/dts/p2020ds.dts
> > index 29989fb..3263397 100644
> > --- a/arch/powerpc/boot/dts/p2020ds.dts
> > +++ b/arch/powerpc/boot/dts/p2020ds.dts
> > @@ -459,8 +459,6 @@
> > reg =3D <0x2e000 0x1000>;
> > interrupts =3D <72 0x2>;
> > interrupt-parent =3D <&mpic>;
> > - fsl,sdhci-dma-broken;
> > - fsl,sdhci-ahb2mag-irq-bypass;
> > fsl,sdhci-adjust-timeout;
> > clock-frequency =3D <0>;
> > };
> > --
> > 1.6.4
>=20
> --
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
>=20
>=20
^ permalink raw reply
* RE: [PATCH 3/6] P2020DS: Fixup sdhc to use PIO mode
From: Gao Guanhua-B22826 @ 2009-09-24 8:28 UTC (permalink / raw)
To: avorontsov; +Cc: linuxppc-dev, sdhci-devel
In-Reply-To: <20090923115518.GB6425@oksana.dev.rtsoft.ru>
Thanks, I will add them.=20
> -----Original Message-----
> From: Anton Vorontsov [mailto:avorontsov@ru.mvista.com]=20
> Sent: Wednesday, September 23, 2009 7:55 PM
> To: Gao Guanhua-B22826
> Cc: sdhci-devel@lists.ossman.eu; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH 3/6] P2020DS: Fixup sdhc to use PIO mode
>=20
> On Wed, Sep 23, 2009 at 05:08:09PM +0800, Gao Guanhua wrote:
> > The SDHC can not work on DMA mode because of the hardware=20
> bug, so we=20
> > set a broken dma flag and use PIO mode. This patch applies=20
> to Rev1.0.
>=20
> Signed-off-by line is missing (in all patches).
>=20
> > ---
> > arch/powerpc/boot/dts/p2020ds.dts | 1 +
> > drivers/mmc/host/sdhci-of.c | 3 +++
> > 2 files changed, 4 insertions(+), 0 deletions(-)
> >=20
> > diff --git a/arch/powerpc/boot/dts/p2020ds.dts=20
> > b/arch/powerpc/boot/dts/p2020ds.dts
> > index be449ba..574ad4f 100644
> > --- a/arch/powerpc/boot/dts/p2020ds.dts
> > +++ b/arch/powerpc/boot/dts/p2020ds.dts
> > @@ -459,6 +459,7 @@
> > reg =3D <0x2e000 0x1000>;
> > interrupts =3D <72 0x2>;
> > interrupt-parent =3D <&mpic>;
> > + fsl,sdhci-dma-broken;
>=20
> You might want to update
> Documentation/powerpc/dts-bindings/fsl/esdhc.txt
>=20
> > clock-frequency =3D <0>;
> > };
> > =20
> > diff --git a/drivers/mmc/host/sdhci-of.c=20
> b/drivers/mmc/host/sdhci-of.c=20
> > index 01ab916..5879483 100644
> > --- a/drivers/mmc/host/sdhci-of.c
> > +++ b/drivers/mmc/host/sdhci-of.c
> > @@ -270,6 +270,9 @@ static int __devinit=20
> sdhci_of_probe(struct of_device *ofdev,
> > if (sdhci_of_wp_inverted(np))
> > host->quirks |=3D SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
> > =20
> > + if (of_get_property(np, "fsl,sdhci-dma-broken", NULL))
> > + host->quirks |=3D SDHCI_QUIRK_BROKEN_DMA;
> > +
> > clk =3D of_get_property(np, "clock-frequency", &size);
> > if (clk && size =3D=3D sizeof(*clk) && *clk)
> > of_host->clock =3D *clk;
> > --
> > 1.6.4
>=20
> Thanks,
>=20
> --
> Anton Vorontsov
> email: cbouatmailru@gmail.com
> irc://irc.freenode.net/bd2
>=20
>=20
^ permalink raw reply
* Re: [PATCH v2 0/2] cpu: pseries: Offline state framework.
From: Benjamin Herrenschmidt @ 2009-09-24 8:38 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Gautham R Shenoy, Venkatesh Pallipadi, linux-kernel, linuxppc-dev,
Darrick J. Wong
In-Reply-To: <1253778667.7695.130.camel@twins>
On Thu, 2009-09-24 at 09:51 +0200, Peter Zijlstra wrote:
> > I don't quite follow your logic here. This is useful for more than just
> > hypervisors. For example, take the HV out of the picture for a moment
> > and imagine that the HW has the ability to offline CPU in various power
> > levels, with varying latencies to bring them back.
>
> cpu-hotplug is an utter slow path, anybody saying latency and hotplug in
> the same sentence doesn't seem to grasp either or both concepts.
Let's forget about latency then. Let's imagine I want to set a CPU
offline to save power, vs. setting it offline -and- opening the back
door of the machine to actually physically replace it :-)
In any case, I don't see the added feature as being problematic, and
not such a "layering violation" as you seem to imply it is. It's a
convenient way to atomically take the CPU out -and- convey some
information about the "intent" to the hypervisor, and I really fail
to see why you have so strong objections about it.
Ben.
^ permalink raw reply
* [PATCH 1/4] powerpc/fsl: 85xx: document cache-sram size as a kernel parametric option
From: Vivek Mahajan @ 2009-09-24 9:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kumar.gala, Vivek Mahajan
Adds documentation for the size parameter of Freescale's QorIQ
based cache-sram
Signed-off-by: Vivek Mahajan <vivek.mahajan@freescale.com>
---
Resending it to linuxppc-dev@ozlabs.org
Documentation/kernel-parameters.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 0f17d16..3213844 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -412,6 +412,9 @@ and is between 256 and 4096 characters. It is defined in the file
c101= [NET] Moxa C101 synchronous serial card
+ cache-sram-size= [PPC] Size of Freescale's QorIQ Cache SRAM
+ See Documentation/powerpc/fsl_85xx_cache_sram.txt.
+
cachesize= [BUGS=X86-32] Override level 2 CPU cache size detection.
Sometimes CPU hardware bugs make them report the cache
size incorrectly. The kernel will attempt work arounds
--
1.5.6.5
^ permalink raw reply related
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