Re: [PATCH] powerpc/mpic: don't reset affinity for secondary MPIC on boot
On Wed, 2008-11-19 at 14:50 +0100, Arnd Bergmann wrote: > This patch implements the first approach, because it can work on > machines that have a secondary controller that needs to deliver > interrupts to a destination other than CPU 0. The disadvantage > is that it requires the system to set up the affinity register > correctly on bootup. > That won't fly with MPICs that get reset. I would rather, for non primary, set it to a cpu provided as either a new argument or an mpic struct member initially set to 1 with an accessor to change it if necessary. Or should we define a flag to have it read it at init time from the chip ? Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Use RCU based pte free mechanism for all powerpc
On Wed, 2008-11-19 at 16:50 -0600, Kumar Gala wrote: > Refactor the RCU based pte free code that was used on ppc64 to be used > on all powerpc. > > Additionally refactor pte_free() & pte_free_kernel() into common code > between ppc32 & ppc64. > > Signed-off-by: Kumar Gala <[EMAIL PROTECTED]> > --- > * Only does RCU if CONFIG_SMP > * Removed hash_page_sync() as its not needed if we do RCU Patch looks good. I'll try to test it a bit tomorrow. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ext4: fix some s64 printing warnings
On Wed, Nov 12, 2008 at 11:10:49AM +1100, Stephen Rothwell wrote: > A powerpc ppc64_defconfig build of Linus' current tree produces these > warnings: Hi Stephen, Thanks for submitting the patch! As it turns out, a patch that was pretty much identical to yours was submitted by Alexander Beregalov and was merged into mainline as of 2.6.28-rc5, as commit ID ba8292e2. Regards, - Ted ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/6 v3] usb/fsl_qe_udc: Fix recursive locking bug in ch9getstatus()
On Tuesday 18 November 2008, Anton Vorontsov wrote:
> The call chain is this:
>
> qe_udc_irq() <- grabs the udc->lock spinlock
> rx_irq()
> qe_ep0_rx()
> ep0_setup_handle()
> setup_received_handle()
> ch9getstatus()
> qe_ep_queue() <- tries to grab the udc->lock again
>
> It seems unsafe to temporarily drop the lock in the ch9getstatus(),
> so to fix that bug the lock-less __qe_ep_queue() function
> implemented and used by the ch9getstatus().
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
Acked-by: David Brownell <[EMAIL PROTECTED]>
... noting that this *also* fixes a locking bug in qe_ep_queue(),
where it modified the queue head without holding the spinlock.
(So for example an IRQ in the middle of that update could end
up updating the incompletely updated list head ... oopsie!)
And I'd have made the __qe_ep_queue() routine take a qe_ep
and qe_req, but that's just a minor issue.
> ---
>
> On Tue, Nov 18, 2008 at 02:13:30PM -0800, David Brownell wrote:
> > On Tuesday 18 November 2008, Anton Vorontsov wrote:
> > > + spin_lock_irqsave(&udc->lock, flags);
> > > + ret = __qe_ep_queue(_ep, _req, gfp_flags);
> > > + spin_unlock_irqrestore(&udc->lock, flags);
> >
> > Why are you passing "gfp_flags"? Especially without
> > checking ... GFP_KERNEL will be illegal, for example.
>
> Ugh, the gfp_flags aren't used at all. How about that
> patch?
>
> drivers/usb/gadget/fsl_qe_udc.c | 26 ++
> 1 files changed, 18 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/gadget/fsl_qe_udc.c b/drivers/usb/gadget/fsl_qe_udc.c
> index 60b9279..3587970 100644
> --- a/drivers/usb/gadget/fsl_qe_udc.c
> +++ b/drivers/usb/gadget/fsl_qe_udc.c
> @@ -1681,14 +1681,11 @@ static void qe_free_request(struct usb_ep *_ep,
> struct usb_request *_req)
> kfree(req);
> }
>
> -/* queues (submits) an I/O request to an endpoint */
> -static int qe_ep_queue(struct usb_ep *_ep, struct usb_request *_req,
> - gfp_t gfp_flags)
> +static int __qe_ep_queue(struct usb_ep *_ep, struct usb_request *_req)
> {
> struct qe_ep *ep = container_of(_ep, struct qe_ep, ep);
> struct qe_req *req = container_of(_req, struct qe_req, req);
> struct qe_udc *udc;
> - unsigned long flags;
> int reval;
>
> udc = ep->udc;
> @@ -1732,7 +1729,7 @@ static int qe_ep_queue(struct usb_ep *_ep, struct
> usb_request *_req,
> list_add_tail(&req->queue, &ep->queue);
> dev_vdbg(udc->dev, "gadget have request in %s! %d\n",
> ep->name, req->req.length);
> - spin_lock_irqsave(&udc->lock, flags);
> +
> /* push the request to device */
> if (ep_is_in(ep))
> reval = ep_req_send(ep, req);
> @@ -1748,11 +1745,24 @@ static int qe_ep_queue(struct usb_ep *_ep, struct
> usb_request *_req,
> if (ep->dir == USB_DIR_OUT)
> reval = ep_req_receive(ep, req);
>
> - spin_unlock_irqrestore(&udc->lock, flags);
> -
> return 0;
> }
>
> +/* queues (submits) an I/O request to an endpoint */
> +static int qe_ep_queue(struct usb_ep *_ep, struct usb_request *_req,
> +gfp_t gfp_flags)
> +{
> + struct qe_ep *ep = container_of(_ep, struct qe_ep, ep);
> + struct qe_udc *udc = ep->udc;
> + unsigned long flags;
> + int ret;
> +
> + spin_lock_irqsave(&udc->lock, flags);
> + ret = __qe_ep_queue(_ep, _req);
> + spin_unlock_irqrestore(&udc->lock, flags);
> + return ret;
> +}
> +
> /* dequeues (cancels, unlinks) an I/O request from an endpoint */
> static int qe_ep_dequeue(struct usb_ep *_ep, struct usb_request *_req)
> {
> @@ -2008,7 +2018,7 @@ static void ch9getstatus(struct qe_udc *udc, u8
> request_type, u16 value,
> udc->ep0_dir = USB_DIR_IN;
>
> /* data phase */
> - status = qe_ep_queue(&ep->ep, &req->req, GFP_ATOMIC);
> + status = __qe_ep_queue(&ep->ep, &req->req);
>
> if (status == 0)
> return;
> --
> 1.5.6.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add a local_flush_tlb_page to handle kmap_atomic invalidates
On Wed, 2008-11-19 at 09:53 -0600, Kumar Gala wrote:
> The tlb invalidates in kmap_atomic/kunmap_atomic can be called from
> IRQ context, however they are only local invalidates (on the processor
> that the kmap was called on). In the future we want to use IPIs to
> do tlb invalidates this causes issue since flush_tlb_page() is considered
> a broadcast invalidate.
>
> Add local_flush_tlb_page() as a non-broadcast invalidate and use it in
> kmap_atomic() since we don't have enough information in the
> flush_tlb_page() call to determine its local.
>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/include/asm/highmem.h |4 ++--
> arch/powerpc/include/asm/tlbflush.h | 14 ++
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/highmem.h
> b/arch/powerpc/include/asm/highmem.h
> index 91c5895..7dc52ec 100644
> --- a/arch/powerpc/include/asm/highmem.h
> +++ b/arch/powerpc/include/asm/highmem.h
> @@ -85,7 +85,7 @@ static inline void *kmap_atomic_prot(struct page *page,
> enum km_type type, pgpro
> BUG_ON(!pte_none(*(kmap_pte-idx)));
> #endif
> __set_pte_at(&init_mm, vaddr, kmap_pte-idx, mk_pte(page, prot));
> - flush_tlb_page(NULL, vaddr);
> + local_flush_tlb_page(vaddr);
>
> return (void*) vaddr;
> }
> @@ -113,7 +113,7 @@ static inline void kunmap_atomic(void *kvaddr, enum
> km_type type)
>* this pte without first remap it
>*/
> pte_clear(&init_mm, vaddr, kmap_pte-idx);
> - flush_tlb_page(NULL, vaddr);
> + local_flush_tlb_page(vaddr);
> #endif
> pagefault_enable();
> }
> diff --git a/arch/powerpc/include/asm/tlbflush.h
> b/arch/powerpc/include/asm/tlbflush.h
> index a2c6bfd..93716a9 100644
> --- a/arch/powerpc/include/asm/tlbflush.h
> +++ b/arch/powerpc/include/asm/tlbflush.h
> @@ -6,6 +6,7 @@
> *
> * - flush_tlb_mm(mm) flushes the specified mm context TLB's
> * - flush_tlb_page(vma, vmaddr) flushes one page
> + * - local_flush_tlb_page(vmaddr) flushes one page on the local processor
> * - flush_tlb_page_nohash(vma, vmaddr) flushes one page if SW loaded TLB
> * - flush_tlb_range(vma, start, end) flushes a range of pages
> * - flush_tlb_kernel_range(start, end) flushes a range of kernel pages
> @@ -44,6 +45,11 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
> _tlbil_pid(mm->context.id);
> }
>
> +static inline void local_flush_tlb_page(unsigned long vmaddr)
> +{
> + _tlbil_va(vmaddr, 0);
> +}
> +
> static inline void flush_tlb_page(struct vm_area_struct *vma,
> unsigned long vmaddr)
> {
> @@ -81,6 +87,10 @@ extern void flush_tlb_page_nohash(struct vm_area_struct
> *vma, unsigned long addr
> extern void flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
> unsigned long end);
> extern void flush_tlb_kernel_range(unsigned long start, unsigned long end);
> +static inline void local_flush_tlb_page(unsigned long vmaddr)
> +{
> + flush_tlb_page(NULL, vmaddr);
> +}
>
> #else
> /*
> @@ -138,6 +148,10 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
> {
> }
>
> +static inline void local_flush_tlb_page(unsigned long vmaddr)
> +{
> +}
> +
> static inline void flush_tlb_page(struct vm_area_struct *vma,
> unsigned long vmaddr)
> {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: hash_page_sync should only be used on SMP & STD_MMU_32
On Wed, 2008-11-19 at 09:53 -0600, Kumar Gala wrote:
> Clean up the ifdefs so we only use hash_page_sync if we are
> CONFIG_SMP && CONFIG_PPC_STD_MMU_32
>
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> ---
> arch/powerpc/mm/pgtable_32.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index c31d6d2..44fbc81 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -48,7 +48,7 @@ EXPORT_SYMBOL(ioremap_bot); /* aka VMALLOC_END */
>
> extern char etext[], _stext[];
>
> -#ifdef CONFIG_SMP
> +#if defined(CONFIG_SMP) && defined(CONFIG_PPC_STD_MMU_32)
> extern void hash_page_sync(void);
> #endif
>
> @@ -127,7 +127,7 @@ pgtable_t pte_alloc_one(struct mm_struct *mm, unsigned
> long address)
>
> void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
> {
> -#ifdef CONFIG_SMP
> +#if defined(CONFIG_SMP) && defined(CONFIG_PPC_STD_MMU_32)
> hash_page_sync();
> #endif
> free_page((unsigned long)pte);
> @@ -135,7 +135,7 @@ void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
>
> void pte_free(struct mm_struct *mm, pgtable_t ptepage)
> {
> -#ifdef CONFIG_SMP
> +#if defined(CONFIG_SMP) && defined(CONFIG_PPC_STD_MMU_32)
> hash_page_sync();
> #endif
> pgtable_page_dtor(ptepage);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add MSR[CE, DE] to the MSR bits we print on show_regs()
On Wed, 2008-11-19 at 08:39 -0600, Kumar Gala wrote:
> Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
> ---
Shouldn't this be protected by some ifdef ?
Ben.
> arch/powerpc/kernel/process.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 957bded..b038323 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -467,6 +467,8 @@ static struct regbit {
> {MSR_VEC, "VEC"},
> {MSR_VSX, "VSX"},
> {MSR_ME,"ME"},
> + {MSR_CE,"CE"},
> + {MSR_DE,"DE"},
> {MSR_IR,"IR"},
> {MSR_DR,"DR"},
> {0, NULL}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] IRQ assign for some PCIe devices
On Wed, 2008-11-19 at 11:55 -0200, Adhemerval Zanella wrote: > > Fallowing a Benjamin Herrenschmidt request, I sending you a fix for IRQ > assign for some PCIe devices. This bug affects multiple PCIe devices > including Cadet-E, Squib-E, CISCO 4X SDR IB, and Knox adapters. Thanks for tracking this down ! We'll pick it up. In the future, it would be nice if you could post the patch inline rather than as an attachment (you may want to train via private email to make sure you get the right settings in your mailer to avoid damaging it since some mailers love to mangle patches) and with the appropriate "Signed-off-by:..." line. The patch is correct, Paul, can you pick it up ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: allow configuring max stack dump depth
Johannes Berg writes: > On my screen, when something crashes, I only have space for maybe > 16 functions of the stack trace before the information above it > scrolls off the screen. It's easy to hack the kernel to print out > only that much, but it's harder to remember to do it. This patch > introduces a config option for it so that I can keep the setting > in my config. > > Signed-off-by: Johannes Berg <[EMAIL PROTECTED]> > --- > Sure, here's an updated version. I used DEBUG_KERNEL since the > ADVANCED_CONFIGURATION help text implies it's for MM and can cause the > kernel to not boot, not something this config is related to. Um, with this I get a compile error when DEBUG_KERNEL=n: CC arch/powerpc/kernel/process.o /home/paulus/kernel/powerpc/arch/powerpc/kernel/process.c:1001: error: 'CONFIG_PRINT_STACK_DEPTH' undeclared here (not in a function) make[2]: *** [arch/powerpc/kernel/process.o] Error 1 I think it needs to look like this: +config PRINT_STACK_DEPTH + int "Stack depth to print" if DEBUG_KERNEL + default 64 + help + This option allows you to set the stack depth that the kernel + prints in stack traces. This can be useful if your display is + too small and stack traces cause important information to + scroll off the screen. + Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix BSR to allow mmap of small BSR on 64k kernel
Sonny Rao writes: > On Wed, Nov 19, 2008 at 03:07:04PM +1100, Paul Mackerras wrote: > > I think we should be checking that dev->bsr_len == 4096 here. > > > > Paul. > > Well, dev->bsr_len could be 4096 or 8192 Isn't the dev->bsr_len == 8192 case the one where we'll only map 4096 bytes and therefore not do what the user expected? Sounds to me like we want to return an error for that case. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: Use RCU based pte free mechanism for all powerpc
Refactor the RCU based pte free code that was used on ppc64 to be used
on all powerpc.
Additionally refactor pte_free() & pte_free_kernel() into common code
between ppc32 & ppc64.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
* Only does RCU if CONFIG_SMP
* Removed hash_page_sync() as its not needed if we do RCU
arch/powerpc/include/asm/pgalloc-32.h | 11 ++-
arch/powerpc/include/asm/pgalloc-64.h | 34 --
arch/powerpc/include/asm/pgalloc.h| 41
arch/powerpc/mm/Makefile |2 +-
arch/powerpc/mm/hash_low_32.S | 30 -
arch/powerpc/mm/pgtable.c | 117 +
arch/powerpc/mm/pgtable_32.c | 21 --
arch/powerpc/mm/tlb_64.c | 86
8 files changed, 167 insertions(+), 175 deletions(-)
create mode 100644 arch/powerpc/mm/pgtable.c
diff --git a/arch/powerpc/include/asm/pgalloc-32.h
b/arch/powerpc/include/asm/pgalloc-32.h
index 58c0714..0815eb4 100644
--- a/arch/powerpc/include/asm/pgalloc-32.h
+++ b/arch/powerpc/include/asm/pgalloc-32.h
@@ -3,6 +3,8 @@
#include
+#define PTE_NONCACHE_NUM 0 /* dummy for now to share code w/ppc64 */
+
extern void __bad_pte(pmd_t *pmd);
extern pgd_t *pgd_alloc(struct mm_struct *mm);
@@ -33,10 +35,13 @@ extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
extern pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long addr);
extern pgtable_t pte_alloc_one(struct mm_struct *mm, unsigned long addr);
-extern void pte_free_kernel(struct mm_struct *mm, pte_t *pte);
-extern void pte_free(struct mm_struct *mm, pgtable_t pte);
-#define __pte_free_tlb(tlb, pte) pte_free((tlb)->mm, (pte))
+static inline void pgtable_free(pgtable_free_t pgf)
+{
+ void *p = (void *)(pgf.val & ~PGF_CACHENUM_MASK);
+
+ free_page((unsigned long)p);
+}
#define check_pgt_cache() do { } while (0)
diff --git a/arch/powerpc/include/asm/pgalloc-64.h
b/arch/powerpc/include/asm/pgalloc-64.h
index 812a1d8..afda2bd 100644
--- a/arch/powerpc/include/asm/pgalloc-64.h
+++ b/arch/powerpc/include/asm/pgalloc-64.h
@@ -7,7 +7,6 @@
* 2 of the License, or (at your option) any later version.
*/
-#include
#include
#include
#include
@@ -108,31 +107,6 @@ static inline pgtable_t pte_alloc_one(struct mm_struct *mm,
return page;
}
-static inline void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
-{
- free_page((unsigned long)pte);
-}
-
-static inline void pte_free(struct mm_struct *mm, pgtable_t ptepage)
-{
- pgtable_page_dtor(ptepage);
- __free_page(ptepage);
-}
-
-#define PGF_CACHENUM_MASK 0x7
-
-typedef struct pgtable_free {
- unsigned long val;
-} pgtable_free_t;
-
-static inline pgtable_free_t pgtable_free_cache(void *p, int cachenum,
- unsigned long mask)
-{
- BUG_ON(cachenum > PGF_CACHENUM_MASK);
-
- return (pgtable_free_t){.val = ((unsigned long) p & ~mask) | cachenum};
-}
-
static inline void pgtable_free(pgtable_free_t pgf)
{
void *p = (void *)(pgf.val & ~PGF_CACHENUM_MASK);
@@ -144,14 +118,6 @@ static inline void pgtable_free(pgtable_free_t pgf)
kmem_cache_free(pgtable_cache[cachenum], p);
}
-extern void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf);
-
-#define __pte_free_tlb(tlb,ptepage)\
-do { \
- pgtable_page_dtor(ptepage); \
- pgtable_free_tlb(tlb, pgtable_free_cache(page_address(ptepage), \
- PTE_NONCACHE_NUM, PTE_TABLE_SIZE-1)); \
-} while (0)
#define __pmd_free_tlb(tlb, pmd) \
pgtable_free_tlb(tlb, pgtable_free_cache(pmd, \
PMD_CACHE_NUM, PMD_TABLE_SIZE-1))
diff --git a/arch/powerpc/include/asm/pgalloc.h
b/arch/powerpc/include/asm/pgalloc.h
index b4505ed..5d84802 100644
--- a/arch/powerpc/include/asm/pgalloc.h
+++ b/arch/powerpc/include/asm/pgalloc.h
@@ -2,11 +2,52 @@
#define _ASM_POWERPC_PGALLOC_H
#ifdef __KERNEL__
+#include
+
+static inline void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
+{
+ free_page((unsigned long)pte);
+}
+
+static inline void pte_free(struct mm_struct *mm, pgtable_t ptepage)
+{
+ pgtable_page_dtor(ptepage);
+ __free_page(ptepage);
+}
+
+typedef struct pgtable_free {
+ unsigned long val;
+} pgtable_free_t;
+
+#define PGF_CACHENUM_MASK 0x7
+
+static inline pgtable_free_t pgtable_free_cache(void *p, int cachenum,
+ unsigned long mask)
+{
+ BUG_ON(cachenum > PGF_CACHENUM_MASK);
+
+ return (pgtable_free_t){.val = ((unsigned long) p & ~mask) | cachenum};
+}
+
#ifdef CONFIG_PPC64
#include
#else
#include
#endif
+extern void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf);
+
+#ifdef CONFIG_SMP
+#define __pte_free_tlb(tlb,ptepage)\
+do { \
+ pgtable_page_dtor(ptepage); \
+ pgtable_free_tlb(tlb, pgtable_free_cache(page_address(ptepage), \
[PATCH] powerpc: Use RCU based pte free mechanism for all powerpc
Refactor the RCU based pte free code that was used on ppc64 to be used
on all powerpc.
Additionally refactor pte_free() & pte_free_kernel() into common code
between ppc32 & ppc64.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/pgalloc-32.h | 11 ++-
arch/powerpc/include/asm/pgalloc-64.h | 34 --
arch/powerpc/include/asm/pgalloc.h| 46 +
arch/powerpc/mm/Makefile |2 +-
arch/powerpc/mm/pgtable.c | 117 +
arch/powerpc/mm/pgtable_32.c | 21 --
arch/powerpc/mm/tlb_64.c | 86
7 files changed, 172 insertions(+), 145 deletions(-)
create mode 100644 arch/powerpc/mm/pgtable.c
diff --git a/arch/powerpc/include/asm/pgalloc-32.h
b/arch/powerpc/include/asm/pgalloc-32.h
index 58c0714..0815eb4 100644
--- a/arch/powerpc/include/asm/pgalloc-32.h
+++ b/arch/powerpc/include/asm/pgalloc-32.h
@@ -3,6 +3,8 @@
#include
+#define PTE_NONCACHE_NUM 0 /* dummy for now to share code w/ppc64 */
+
extern void __bad_pte(pmd_t *pmd);
extern pgd_t *pgd_alloc(struct mm_struct *mm);
@@ -33,10 +35,13 @@ extern void pgd_free(struct mm_struct *mm, pgd_t *pgd);
extern pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long addr);
extern pgtable_t pte_alloc_one(struct mm_struct *mm, unsigned long addr);
-extern void pte_free_kernel(struct mm_struct *mm, pte_t *pte);
-extern void pte_free(struct mm_struct *mm, pgtable_t pte);
-#define __pte_free_tlb(tlb, pte) pte_free((tlb)->mm, (pte))
+static inline void pgtable_free(pgtable_free_t pgf)
+{
+ void *p = (void *)(pgf.val & ~PGF_CACHENUM_MASK);
+
+ free_page((unsigned long)p);
+}
#define check_pgt_cache() do { } while (0)
diff --git a/arch/powerpc/include/asm/pgalloc-64.h
b/arch/powerpc/include/asm/pgalloc-64.h
index 812a1d8..afda2bd 100644
--- a/arch/powerpc/include/asm/pgalloc-64.h
+++ b/arch/powerpc/include/asm/pgalloc-64.h
@@ -7,7 +7,6 @@
* 2 of the License, or (at your option) any later version.
*/
-#include
#include
#include
#include
@@ -108,31 +107,6 @@ static inline pgtable_t pte_alloc_one(struct mm_struct *mm,
return page;
}
-static inline void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
-{
- free_page((unsigned long)pte);
-}
-
-static inline void pte_free(struct mm_struct *mm, pgtable_t ptepage)
-{
- pgtable_page_dtor(ptepage);
- __free_page(ptepage);
-}
-
-#define PGF_CACHENUM_MASK 0x7
-
-typedef struct pgtable_free {
- unsigned long val;
-} pgtable_free_t;
-
-static inline pgtable_free_t pgtable_free_cache(void *p, int cachenum,
- unsigned long mask)
-{
- BUG_ON(cachenum > PGF_CACHENUM_MASK);
-
- return (pgtable_free_t){.val = ((unsigned long) p & ~mask) | cachenum};
-}
-
static inline void pgtable_free(pgtable_free_t pgf)
{
void *p = (void *)(pgf.val & ~PGF_CACHENUM_MASK);
@@ -144,14 +118,6 @@ static inline void pgtable_free(pgtable_free_t pgf)
kmem_cache_free(pgtable_cache[cachenum], p);
}
-extern void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf);
-
-#define __pte_free_tlb(tlb,ptepage)\
-do { \
- pgtable_page_dtor(ptepage); \
- pgtable_free_tlb(tlb, pgtable_free_cache(page_address(ptepage), \
- PTE_NONCACHE_NUM, PTE_TABLE_SIZE-1)); \
-} while (0)
#define __pmd_free_tlb(tlb, pmd) \
pgtable_free_tlb(tlb, pgtable_free_cache(pmd, \
PMD_CACHE_NUM, PMD_TABLE_SIZE-1))
diff --git a/arch/powerpc/include/asm/pgalloc.h
b/arch/powerpc/include/asm/pgalloc.h
index b4505ed..538b606 100644
--- a/arch/powerpc/include/asm/pgalloc.h
+++ b/arch/powerpc/include/asm/pgalloc.h
@@ -2,11 +2,57 @@
#define _ASM_POWERPC_PGALLOC_H
#ifdef __KERNEL__
+#include
+
+#if defined(CONFIG_SMP) && defined(CONFIG_PPC_STD_MMU_32)
+extern void hash_page_sync(void);
+#endif
+
+static inline void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
+{
+#if defined(CONFIG_SMP) && defined(CONFIG_PPC_STD_MMU_32)
+ hash_page_sync();
+#endif
+ free_page((unsigned long)pte);
+}
+
+static inline void pte_free(struct mm_struct *mm, pgtable_t ptepage)
+{
+#if defined(CONFIG_SMP) && defined(CONFIG_PPC_STD_MMU_32)
+ hash_page_sync();
+#endif
+ pgtable_page_dtor(ptepage);
+ __free_page(ptepage);
+}
+
+typedef struct pgtable_free {
+ unsigned long val;
+} pgtable_free_t;
+
+#define PGF_CACHENUM_MASK 0x7
+
+static inline pgtable_free_t pgtable_free_cache(void *p, int cachenum,
+ unsigned long mask)
+{
+ BUG_ON(cachenum > PGF_CACHENUM_MASK);
+
+ return (pgtable_free_t){.val = ((unsigned long) p & ~mask) | cachenum};
+}
+
#ifdef CONFIG_PPC64
#include
#else
#include
#endif
+extern void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf);
+
+#define __pte_free_tlb(tlb,ptepage
Re: [PATCH 1/9] ftrace: align __mcount_loc sections
I need to change my scripts to parse out the first line of all patches, so quilt can send out the proper owner. This patch has the following header: >From 626f82959cd00ca804b12543cad86714e74264da Mon Sep 17 00:00:00 2001 From: Matt Fleming <[EMAIL PROTECTED]> Date: Fri, 7 Nov 2008 13:26:25 + Subject: [PATCH] ftrace: align __mcount_loc sections If you pull from my repo, it will all work out. But still, I do not want to take credit for someone else's work. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 9/9] powerpc/ppc32: ftrace, dynamic ftrace to handle modules
Impact: add ability to trace modules on 32 bit PowerPC
This patch performs the necessary trampoline calls to handle
modules with dynamic ftrace on 32 bit PowerPC.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/module.h |5 ++-
arch/powerpc/kernel/ftrace.c | 101 ++--
arch/powerpc/kernel/module_32.c | 10
3 files changed, 109 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/module.h
b/arch/powerpc/include/asm/module.h
index 340bc69..0845488 100644
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -39,11 +39,14 @@ struct mod_arch_specific {
unsigned long tramp;
#endif
-#else
+#else /* powerpc64 */
/* Indices of PLT sections within module. */
unsigned int core_plt_section;
unsigned int init_plt_section;
+#ifdef CONFIG_DYNAMIC_FTRACE
+ unsigned long tramp;
#endif
+#endif /* powerpc64 */
/* List of BUG addresses, source line numbers and filenames */
struct list_head bug_list;
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 1aec559..3271cd6 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -274,7 +274,63 @@ static int
__ftrace_make_nop(struct module *mod,
struct dyn_ftrace *rec, unsigned long addr)
{
- /* Ignore modules for PPC32 (for now) */
+ unsigned char replaced[MCOUNT_INSN_SIZE];
+ unsigned int *op = (unsigned *)&replaced;
+ unsigned char jmp[8];
+ unsigned int *ptr = (unsigned int *)&jmp;
+ unsigned long ip = rec->ip;
+ unsigned long tramp;
+ int offset;
+
+ if (probe_kernel_read(replaced, (void *)ip, MCOUNT_INSN_SIZE))
+ return -EFAULT;
+
+ /* Make sure that that this is still a 24bit jump */
+ if (!is_bl_op(*op)) {
+ printk(KERN_ERR "Not expected bl: opcode is %x\n", *op);
+ return -EINVAL;
+ }
+
+ /* lets find where the pointer goes */
+ tramp = find_bl_target(ip, *op);
+
+ /*
+* On PPC32 the trampoline looks like:
+* lis r11,[EMAIL PROTECTED]
+* addi r11,r11,[EMAIL PROTECTED]
+* mtctr r11
+* bctr
+*/
+
+ DEBUGP("ip:%lx jumps to %lx", ip, tramp);
+
+ /* Find where the trampoline jumps to */
+ if (probe_kernel_read(jmp, (void *)tramp, 8)) {
+ printk(KERN_ERR "Failed to read %lx\n", tramp);
+ return -EFAULT;
+ }
+
+ DEBUGP(" %08x %08x ", ptr[0], ptr[1]);
+
+ tramp = (ptr[1] & 0x) |
+ ((ptr[0] & 0x) << 16);
+ if (tramp & 0x8000)
+ tramp -= 0x1;
+
+ DEBUGP(" %x ", tramp);
+
+ if (tramp != addr) {
+ printk(KERN_ERR
+ "Trampoline location %08lx does not match addr\n",
+ tramp);
+ return -EINVAL;
+ }
+
+ op[0] = PPC_NOP_INSTR;
+
+ if (probe_kernel_write((void *)ip, replaced, MCOUNT_INSN_SIZE))
+ return -EPERM;
+
return 0;
}
#endif /* PPC64 */
@@ -297,7 +353,6 @@ int ftrace_make_nop(struct module *mod,
return ftrace_modify_code(ip, old, new);
}
-#ifdef CONFIG_PPC64
/*
* Out of range jumps are called from modules.
* We should either already have a pointer to the module
@@ -320,7 +375,6 @@ int ftrace_make_nop(struct module *mod,
/* nothing to do if mod == rec->arch.mod */
} else
mod = rec->arch.mod;
-#endif /* CONFIG_PPC64 */
return __ftrace_make_nop(mod, rec, addr);
@@ -380,7 +434,44 @@ __ftrace_make_call(struct dyn_ftrace *rec, unsigned long
addr)
static int
__ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
{
- /* PPC32 ignores modules for now */
+ unsigned char replaced[MCOUNT_INSN_SIZE];
+ unsigned int *op = (unsigned *)&replaced;
+ unsigned long ip = rec->ip;
+ unsigned long offset;
+
+ /* read where this goes */
+ if (probe_kernel_read(replaced, (void *)ip, MCOUNT_INSN_SIZE))
+ return -EFAULT;
+
+ /* It should be pointing to a nop */
+ if (op[0] != PPC_NOP_INSTR) {
+ printk(KERN_ERR "Expected NOP but have %x\n", op[0]);
+ return -EINVAL;
+ }
+
+ /* If we never set up a trampoline to ftrace_caller, then bail */
+ if (!rec->arch.mod->arch.tramp) {
+ printk(KERN_ERR "No ftrace trampoline\n");
+ return -EINVAL;
+ }
+
+ /* now calculate a jump to the ftrace caller trampoline */
+ offset = rec->arch.mod->arch.tramp - ip;
+
+ if (test_offset(offset)) {
+ printk(KERN_ERR "REL24 %li out of range!\n",
+ (long int)offset);
+ return -EINVAL;
+ }
+
+ /* Set to "bl addr" */
+ op[0] = branch_
[PATCH 8/9] powerpc/ppc32: ftrace, enabled dynamic ftrace
Impact: Port 32 bit PowerPC dynamic ftrace
This patch adds the necessary hooks to get PPC32 dynamic ftrace working.
It does not handle modules. They are ignored by this patch.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig|2 +-
scripts/recordmcount.pl |7 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9675e95..d64b629 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -108,7 +108,7 @@ config ARCH_NO_VIRT_TO_BUS
config PPC
bool
default y
- select HAVE_FTRACE_MCOUNT_RECORD if PPC64
+ select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_DYNAMIC_FTRACE
select HAVE_FUNCTION_TRACER
select ARCH_WANT_OPTIONAL_GPIOLIB
diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index 7acbe17..48609e9 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -178,7 +178,12 @@ if ($arch eq "x86_64") {
$section_regex = "Disassembly of section\\s+(\\S+):";
$function_regex = "^([0-9a-fA-F]+)\\s+<(\\.?.*?)>:";
$mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\s\\.?_mcount\$";
-$type = ".quad";
+if ($bits == 64) {
+ $type = ".quad";
+} else {
+ $type = ".long";
+}
+
} else {
die "Arch $arch is not supported with CONFIG_FTRACE_MCOUNT_RECORD";
}
--
1.5.6.5
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 7/9] powerpc/ppc64: ftrace, handle module trampolines for dyn ftrace
Impact: Allow 64 bit PowerPC to trace modules with dynamic ftrace
This adds code to handle the PPC64 module trampolines, and allows for
PPC64 to use dynamic ftrace.
Thanks to Paul Mackerras for these updates:
- fix the mod and rec->arch.mod NULL checks.
- fix to is_bl_op compare.
Thanks to Milton Miller for:
- finding the nasty race with using two nops, and recommending
instead that I use a branch 8 forward.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/ftrace.h |2 +-
arch/powerpc/include/asm/module.h | 11 ++
arch/powerpc/kernel/ftrace.c | 278 +++--
arch/powerpc/kernel/module_64.c | 13 ++
4 files changed, 293 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/include/asm/ftrace.h
b/arch/powerpc/include/asm/ftrace.h
index 17efecc..e5f2ae8 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -16,7 +16,7 @@ static inline unsigned long ftrace_call_adjust(unsigned long
addr)
}
struct dyn_arch_ftrace {
- /* nothing yet */
+ struct module *mod;
};
#endif /* CONFIG_DYNAMIC_FTRACE */
#endif /* __ASSEMBLY__ */
diff --git a/arch/powerpc/include/asm/module.h
b/arch/powerpc/include/asm/module.h
index e5f14b1..340bc69 100644
--- a/arch/powerpc/include/asm/module.h
+++ b/arch/powerpc/include/asm/module.h
@@ -34,6 +34,11 @@ struct mod_arch_specific {
#ifdef __powerpc64__
unsigned int stubs_section; /* Index of stubs section in module */
unsigned int toc_section; /* What section is the TOC? */
+#ifdef CONFIG_DYNAMIC_FTRACE
+ unsigned long toc;
+ unsigned long tramp;
+#endif
+
#else
/* Indices of PLT sections within module. */
unsigned int core_plt_section;
@@ -68,6 +73,12 @@ struct mod_arch_specific {
#endif /* MODULE */
#endif
+#ifdef CONFIG_DYNAMIC_FTRACE
+#ifdef MODULE
+ asm(".section .ftrace.tramp,\"ax\",@nobits; .align 3; .previous");
+#endif /* MODULE */
+#endif
+
struct exception_table_entry;
void sort_ex_table(struct exception_table_entry *start,
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 1adfbb2..1aec559 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -10,22 +10,29 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
+#if 0
+#define DEBUGP printk
+#else
+#define DEBUGP(fmt , ...) do { } while (0)
+#endif
-static unsigned int ftrace_nop = 0x6000;
+static unsigned int ftrace_nop = PPC_NOP_INSTR;
#ifdef CONFIG_PPC32
# define GET_ADDR(addr) addr
#else
/* PowerPC64's functions are data that points to the functions */
-# define GET_ADDR(addr) *(unsigned long *)addr
+# define GET_ADDR(addr) (*(unsigned long *)addr)
#endif
@@ -102,6 +109,9 @@ ftrace_modify_code(unsigned long ip, unsigned char
*old_code,
return 0;
}
+/*
+ * Helper functions that are the same for both PPC64 and PPC32.
+ */
static int test_24bit_addr(unsigned long ip, unsigned long addr)
{
long diff;
@@ -119,43 +129,292 @@ static int test_24bit_addr(unsigned long ip, unsigned
long addr)
return (diff < (1 << 25)) && (diff > (-1 << 26));
}
+static int is_bl_op(unsigned int op)
+{
+ return (op & 0xfc03) == 0x4801;
+}
+
+static int test_offset(unsigned long offset)
+{
+ return (offset + 0x200 > 0x3ff) || ((offset & 3) != 0);
+}
+
+static unsigned long find_bl_target(unsigned long ip, unsigned int op)
+{
+ static int offset;
+
+ offset = (op & 0x03fc);
+ /* make it signed */
+ if (offset & 0x0200)
+ offset |= 0xfe00;
+
+ return ip + (long)offset;
+}
+
+static unsigned int branch_offset(unsigned long offset)
+{
+ /* return "bl ip+offset" */
+ return 0x4801 | (offset & 0x03fc);
+}
+
+#ifdef CONFIG_PPC64
+static int
+__ftrace_make_nop(struct module *mod,
+ struct dyn_ftrace *rec, unsigned long addr)
+{
+ unsigned char replaced[MCOUNT_INSN_SIZE * 2];
+ unsigned int *op = (unsigned *)&replaced;
+ unsigned char jmp[8];
+ unsigned long *ptr = (unsigned long *)&jmp;
+ unsigned long ip = rec->ip;
+ unsigned long tramp;
+ int offset;
+
+ /* read where this goes */
+ if (probe_kernel_read(replaced, (void *)ip, MCOUNT_INSN_SIZE))
+ return -EFAULT;
+
+ /* Make sure that that this is still a 24bit jump */
+ if (!is_bl_op(*op)) {
+ printk(KERN_ERR "Not expected bl: opcode is %x\n", *op);
+ return -EINVAL;
+ }
+
+ /* lets find where the pointer goes */
+ tramp = find_bl_target(ip, *op);
+
+ /*
+* On PPC64 the trampoline looks like:
+* 0x3d, 0x82, 0x00, 0x00,addis r12,r2,
+* 0x39, 0x8c, 0x00, 0x00,addir12,r12,
+* Where the bytes 2,3,6
[PATCH 4/9] powerpc: ftrace, convert to new dynamic ftrace arch API
Impact: update to PowerPC ftrace arch API
This patch converts PowerPC to use the new dynamic ftrace arch API.
Thanks to Paul Mackennas for pointing out the mistakes of my original
test_24bit_addr function.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/ftrace.h | 14 +++-
arch/powerpc/kernel/ftrace.c | 67 ++---
2 files changed, 75 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/ftrace.h
b/arch/powerpc/include/asm/ftrace.h
index b298f7a..17efecc 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -7,7 +7,19 @@
#ifndef __ASSEMBLY__
extern void _mcount(void);
-#endif
+
+#ifdef CONFIG_DYNAMIC_FTRACE
+static inline unsigned long ftrace_call_adjust(unsigned long addr)
+{
+ /* reloction of mcount call site is the same as the address */
+ return addr;
+}
+
+struct dyn_arch_ftrace {
+ /* nothing yet */
+};
+#endif /* CONFIG_DYNAMIC_FTRACE */
+#endif /* __ASSEMBLY__ */
#endif
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index f4b006e..24c023a 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -33,12 +33,12 @@ static unsigned int ftrace_calc_offset(long ip, long addr)
return (int)(addr - ip);
}
-unsigned char *ftrace_nop_replace(void)
+static unsigned char *ftrace_nop_replace(void)
{
return (char *)&ftrace_nop;
}
-unsigned char *ftrace_call_replace(unsigned long ip, unsigned long addr)
+static unsigned char *ftrace_call_replace(unsigned long ip, unsigned long addr)
{
static unsigned int op;
@@ -68,7 +68,7 @@ unsigned char *ftrace_call_replace(unsigned long ip, unsigned
long addr)
# define _ASM_PTR " .long "
#endif
-int
+static int
ftrace_modify_code(unsigned long ip, unsigned char *old_code,
unsigned char *new_code)
{
@@ -113,6 +113,62 @@ ftrace_modify_code(unsigned long ip, unsigned char
*old_code,
return faulted;
}
+static int test_24bit_addr(unsigned long ip, unsigned long addr)
+{
+ long diff;
+
+ /*
+* Can we get to addr from ip in 24 bits?
+* (26 really, since we mulitply by 4 for 4 byte alignment)
+*/
+ diff = addr - ip;
+
+ /*
+* Return true if diff is less than 1 << 25
+* and greater than -1 << 26.
+*/
+ return (diff < (1 << 25)) && (diff > (-1 << 26));
+}
+
+int ftrace_make_nop(struct module *mod,
+ struct dyn_ftrace *rec, unsigned long addr)
+{
+ unsigned char *old, *new;
+
+ /*
+* If the calling address is more that 24 bits away,
+* then we had to use a trampoline to make the call.
+* Otherwise just update the call site.
+*/
+ if (test_24bit_addr(rec->ip, addr)) {
+ /* within range */
+ old = ftrace_call_replace(rec->ip, addr);
+ new = ftrace_nop_replace();
+ return ftrace_modify_code(rec->ip, old, new);
+ }
+
+ return 0;
+}
+
+int ftrace_make_call(struct dyn_ftrace *rec, unsigned long addr)
+{
+ unsigned char *old, *new;
+
+ /*
+* If the calling address is more that 24 bits away,
+* then we had to use a trampoline to make the call.
+* Otherwise just update the call site.
+*/
+ if (test_24bit_addr(rec->ip, addr)) {
+ /* within range */
+ old = ftrace_nop_replace();
+ new = ftrace_call_replace(rec->ip, addr);
+ return ftrace_modify_code(rec->ip, old, new);
+ }
+
+ return 0;
+}
+
int ftrace_update_ftrace_func(ftrace_func_t func)
{
unsigned long ip = (unsigned long)(&ftrace_call);
@@ -128,9 +184,10 @@ int ftrace_update_ftrace_func(ftrace_func_t func)
int __init ftrace_dyn_arch_init(void *data)
{
- /* This is running in kstop_machine */
+ /* caller expects data to be zero */
+ unsigned long *p = data;
- ftrace_mcount_set(data);
+ *p = 0;
return 0;
}
--
1.5.6.5
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 6/9] powerpc: ftrace, use probe_kernel API to modify code
Impact: use cleaner probe_kernel API over assembly
Using probe_kernel_read/write interface is a much cleaner approach
than the current assembly version.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ftrace.c | 53 -
1 files changed, 21 insertions(+), 32 deletions(-)
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index 24c023a..1adfbb2 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
#include
#include
@@ -72,45 +73,33 @@ static int
ftrace_modify_code(unsigned long ip, unsigned char *old_code,
unsigned char *new_code)
{
- unsigned replaced;
- unsigned old = *(unsigned *)old_code;
- unsigned new = *(unsigned *)new_code;
- int faulted = 0;
+ unsigned char replaced[MCOUNT_INSN_SIZE];
/*
* Note: Due to modules and __init, code can
* disappear and change, we need to protect against faulting
-* as well as code changing.
+* as well as code changing. We do this by using the
+* probe_kernel_* functions.
*
* No real locking needed, this code is run through
-* kstop_machine.
+* kstop_machine, or before SMP starts.
*/
- asm volatile (
- "1: lwz %1, 0(%2)\n"
- " cmpw%1, %5\n"
- " bne 2f\n"
- " stwu%3, 0(%2)\n"
- "2:\n"
- ".section .fixup, \"ax\"\n"
- "3: li %0, 1\n"
- " b 2b\n"
- ".previous\n"
- ".section __ex_table,\"a\"\n"
- _ASM_ALIGN "\n"
- _ASM_PTR "1b, 3b\n"
- ".previous"
- : "=r"(faulted), "=r"(replaced)
- : "r"(ip), "r"(new),
- "0"(faulted), "r"(old)
- : "memory");
-
- if (replaced != old && replaced != new)
- faulted = 2;
-
- if (!faulted)
- flush_icache_range(ip, ip + 8);
-
- return faulted;
+
+ /* read the text we want to modify */
+ if (probe_kernel_read(replaced, (void *)ip, MCOUNT_INSN_SIZE))
+ return -EFAULT;
+
+ /* Make sure it is what we expect it to be */
+ if (memcmp(replaced, old_code, MCOUNT_INSN_SIZE) != 0)
+ return -EINVAL;
+
+ /* replace the text with the new text */
+ if (probe_kernel_write((void *)ip, new_code, MCOUNT_INSN_SIZE))
+ return -EPERM;
+
+ flush_icache_range(ip, ip + 8);
+
+ return 0;
}
static int test_24bit_addr(unsigned long ip, unsigned long addr)
--
1.5.6.5
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/9] ftrace: align __mcount_loc sections
Impact: add alignment option for recordmcount.pl script
Align the __mcount_loc sections so that architectures with strict
alignment requirements need not worry about performing unaligned
accesses.
This fixes an issue where I was seeing unaligned accesses, which are not
supported on our architecture (the results of an unaligned access are
undefined).
Signed-off-by: Matt Fleming <[EMAIL PROTECTED]>
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
scripts/recordmcount.pl |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index 6b9fe3e..eeac71c 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -134,6 +134,7 @@ my $section_regex; # Find the start of a section
my $function_regex;# Find the name of a function
#(return offset and func name)
my $mcount_regex; # Find the call site to mcount (return offset)
+my $alignment; # The .align value to use for $mcount_section
if ($arch eq "x86") {
if ($bits == 64) {
@@ -148,6 +149,7 @@ if ($arch eq "x86_64") {
$function_regex = "^([0-9a-fA-F]+)\\s+<(.*?)>:";
$mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\smcount([+-]0x[0-9a-zA-Z]+)?\$";
$type = ".quad";
+$alignment = 8;
# force flags for this arch
$ld .= " -m elf_x86_64";
@@ -160,6 +162,7 @@ if ($arch eq "x86_64") {
$function_regex = "^([0-9a-fA-F]+)\\s+<(.*?)>:";
$mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\smcount\$";
$type = ".long";
+$alignment = 4;
# force flags for this arch
$ld .= " -m elf_i386";
@@ -288,6 +291,7 @@ sub update_funcs
open(FILE, ">$mcount_s") || die "can't create $mcount_s\n";
$opened = 1;
print FILE "\t.section $mcount_section,\"a\",[EMAIL PROTECTED]";
+ print FILE "\t.align $alignment\n";
}
printf FILE "\t%s %s + %d\n", $type, $ref_func, $offsets[$i] - $offset;
}
--
1.5.6.5
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/9] NOT FOR MAINLINE ftrace: pass module struct to arch dynamic ftrace functions
Impact: allow archs more flexibility on dynamic ftrace implementations
Dynamic ftrace has largly been developed on x86. Since x86 does not
have the same limitations as other architectures, the ftrace interaction
between the generic code and the architecture specific code was not
flexible enough to handle some of the issues that other architectures
have.
Most notably, module trampolines. Due to the limited branch distance
that archs make in calling kernel core code from modules, the module
load code must create a trampoline to jump to what will make the
larger jump into core kernel code.
The problem arises when this happens to a call to mcount. Ftrace checks
all code before modifying it and makes sure the current code is what
it expects. Right now, there is not enough information to handle modifying
module trampolines.
This patch changes the API between generic dynamic ftrace code and
the arch dependent code. There is now two functions for modifying code:
ftrace_make_nop(mod, rec, addr) - convert the code at rec->ip into
a nop, where the original text is calling addr. (mod is the
module struct if called by module init)
ftrace_make_caller(rec, addr) - convert the code rec->ip that should
be a nop into a caller to addr.
The record "rec" now has a new field called "arch" where the architecture
can add any special attributes to each call site record.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
Conflicts:
arch/x86/include/asm/ftrace.h
arch/x86/kernel/ftrace.c
include/linux/ftrace.h
kernel/trace/ftrace.c
ftrace: allow NULL pointers in mcount_loc
Impact: let archs insert NULL pointers in mcount_loc section
Due to the way different architecture linkers combine the data sections
of the mcount_loc (the section that lists all the locations that
call mcount), there may be zeros added in that section. This is usually
due to strange alignments that the linker performs, that pads in zeros.
This patch makes the conversion code to nops skip any pointer in
the mcount_loc section that is NULL.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
arch/x86/include/asm/ftrace.h |9 ++-
arch/x86/kernel/ftrace.c | 168 +++--
include/linux/ftrace.h| 51 ++---
kernel/module.c |2 +-
kernel/trace/ftrace.c | 137 +-
5 files changed, 280 insertions(+), 87 deletions(-)
diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index 9e8bc29..1d8d16f 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -17,8 +17,15 @@ static inline unsigned long ftrace_call_adjust(unsigned long
addr)
*/
return addr - 1;
}
-#endif
+#ifdef CONFIG_DYNAMIC_FTRACE
+
+struct dyn_arch_ftrace {
+ /* No extra data needed for x86 */
+};
+
+#endif /* CONFIG_DYNAMIC_FTRACE */
+#endif /* __ASSEMBLY__ */
#endif /* CONFIG_FUNCTION_TRACER */
#endif /* _ASM_X86_FTRACE_H */
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 50ea0ac..d79e45d 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -37,12 +37,7 @@ static int ftrace_calc_offset(long ip, long addr)
return (int)(addr - ip);
}
-unsigned char *ftrace_nop_replace(void)
-{
- return ftrace_nop;
-}
-
-unsigned char *ftrace_call_replace(unsigned long ip, unsigned long addr)
+static unsigned char *ftrace_call_replace(unsigned long ip, unsigned long addr)
{
static union ftrace_code_union calc;
@@ -56,7 +51,143 @@ unsigned char *ftrace_call_replace(unsigned long ip,
unsigned long addr)
return calc.code;
}
-int
+/*
+ * Modifying code must take extra care. On an SMP machine, if
+ * the code being modified is also being executed on another CPU
+ * that CPU will have undefined results and possibly take a GPF.
+ * We use kstop_machine to stop other CPUS from exectuing code.
+ * But this does not stop NMIs from happening. We still need
+ * to protect against that. We separate out the modification of
+ * the code to take care of this.
+ *
+ * Two buffers are added: An IP buffer and a "code" buffer.
+ *
+ * 1) Put the instruction pointer into the IP buffer
+ *and the new code into the "code" buffer.
+ * 2) Set a flag that says we are modifying code
+ * 3) Wait for any running NMIs to finish.
+ * 4) Write the code
+ * 5) clear the flag.
+ * 6) Wait for any running NMIs to finish.
+ *
+ * If an NMI is executed, the first thing it does is to call
+ * "ftrace_nmi_enter". This will check if the flag is set to write
+ * and if it is, it will write what is in the IP and "code" buffers.
+ *
+ * The trick is, it does not matter if everyone is writing the same
+ * content to the code location. Also, if a CPU is executing code
+ * it is OK to write to that code location if the contents being written
+ * are the same as what exists.
+ */
+
+static atomic_t in_nmi = ATOMIC_INIT(0);
+stat
[PATCH 5/9] powerpc/ppc64: ftrace, mcount record powerpc port
Impact: 64 bit PowerPC port of dynamic ftrace
This patch converts 64 bit PowerPC to use the mcount location section.
Currently, modules will be ignored by the converter.
Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig|2 ++
scripts/recordmcount.pl | 13 +++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 525c13a..9675e95 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -108,6 +108,8 @@ config ARCH_NO_VIRT_TO_BUS
config PPC
bool
default y
+ select HAVE_FTRACE_MCOUNT_RECORD if PPC64
+ select HAVE_DYNAMIC_FTRACE
select HAVE_FUNCTION_TRACER
select ARCH_WANT_OPTIONAL_GPIOLIB
select HAVE_IDE
diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index eeac71c..7acbe17 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -130,6 +130,7 @@ my %weak; # List of weak functions
my %convert; # List of local functions used that needs conversion
my $type;
+my $nm_regex; # Find the local functions (return function)
my $section_regex; # Find the start of a section
my $function_regex;# Find the name of a function
#(return offset and func name)
@@ -145,6 +146,7 @@ if ($arch eq "x86") {
}
if ($arch eq "x86_64") {
+$nm_regex = "^[0-9a-fA-F]+\\s+t\\s+(\\S+)";
$section_regex = "Disassembly of section\\s+(\\S+):";
$function_regex = "^([0-9a-fA-F]+)\\s+<(.*?)>:";
$mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\smcount([+-]0x[0-9a-zA-Z]+)?\$";
@@ -158,6 +160,7 @@ if ($arch eq "x86_64") {
$cc .= " -m64";
} elsif ($arch eq "i386") {
+$nm_regex = "^[0-9a-fA-F]+\\s+t\\s+(\\S+)";
$section_regex = "Disassembly of section\\s+(\\S+):";
$function_regex = "^([0-9a-fA-F]+)\\s+<(.*?)>:";
$mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\smcount\$";
@@ -170,6 +173,12 @@ if ($arch eq "x86_64") {
$objcopy .= " -O elf32-i386";
$cc .= " -m32";
+} elsif ($arch eq "powerpc") {
+$nm_regex = "^[0-9a-fA-F]+\\s+t\\s+(\\.?\\S+)";
+$section_regex = "Disassembly of section\\s+(\\S+):";
+$function_regex = "^([0-9a-fA-F]+)\\s+<(\\.?.*?)>:";
+$mcount_regex = "^\\s*([0-9a-fA-F]+):.*\\s\\.?_mcount\$";
+$type = ".quad";
} else {
die "Arch $arch is not supported with CONFIG_FTRACE_MCOUNT_RECORD";
}
@@ -239,7 +248,7 @@ if (!$found_version) {
#
open (IN, "$nm $inputfile|") || die "error running $nm";
while () {
-if (/^[0-9a-fA-F]+\s+t\s+(\S+)/) {
+if (/$nm_regex/) {
$locals{$1} = 1;
} elsif (/^[0-9a-fA-F]+\s+([wW])\s+(\S+)/) {
$weak{$2} = $1;
@@ -291,7 +300,7 @@ sub update_funcs
open(FILE, ">$mcount_s") || die "can't create $mcount_s\n";
$opened = 1;
print FILE "\t.section $mcount_section,\"a\",[EMAIL PROTECTED]";
- print FILE "\t.align $alignment\n";
+ print FILE "\t.align $alignment\n" if (defined($alignment));
}
printf FILE "\t%s %s + %d\n", $type, $ref_func, $offsets[$i] - $offset;
}
--
1.5.6.5
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/9] powerpc: ftrace, do not latency trace idle
Impact: fix for irq off latency tracer When idle is called, interrupts are disabled, but the idle function will still wake up on an interrupt. The problem is that the interrupt disabled latency tracer will take this call to idle as a latency. This patch disables the latency tracing when going into idle. Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]> --- arch/powerpc/kernel/idle.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c index 31982d0..88d9c1d 100644 --- a/arch/powerpc/kernel/idle.c +++ b/arch/powerpc/kernel/idle.c @@ -69,10 +69,15 @@ void cpu_idle(void) smp_mb(); local_irq_disable(); + /* Don't trace irqs off for idle */ + stop_critical_timings(); + /* check again after disabling irqs */ if (!need_resched() && !cpu_should_die()) ppc_md.power_save(); + start_critical_timings(); + local_irq_enable(); set_thread_flag(TIF_POLLING_NRFLAG); -- 1.5.6.5 -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/9] powerpc: port of dynamic ftrace
Paul, Here are the patches that include the changes suggested by both you and Milton. This series includes the back port of three commits from tip that are needed for the PowerPC port. I also made a git branch called "ppc/ftrace-disable" that does not include two of the three commits. It adds a patch to keep dynamic ftrace from being enabled by PowerPC architectures. As I stated above, both branches include one commit from tip: ftrace: align __mcount_loc sections This is because one of the PowerPC patches will not apply without it. That commit was a clean cherry pick into mainline, so I'm not worried about it. Still, the only commits that should go to mainline from the PowerPC git repo are the ones that start with "powerpc". In the ppc/ftrace-hack branch, I folded the other two commits from tip, that are needed for the port, into a single commit. This commit is called: NOT FOR MAINLINE ftrace: pass module struct to arch dynamic ftrace functions This is only to let you test the rest of the patches. I've booted this branch and ran it on both my PPC64 and my PP32 boxes. Again: The working branch is: ppc/ftrace-hack The disabling dynamic ftrace branch is: ppc/ftrace-disable Only the commits starting with "powerpc" should be pushed to mainline by you. Those patches are the same in both of the above branches. Also, I have not tested that "NOT FOR MAINLINE" patch on x86. It may break that arch. Which is another reason not to push it. The following patches are in: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-2.6-trace.git branch: ppc/ftrace-hack Matt Fleming (1): ftrace: align __mcount_loc sections Steven Rostedt (8): NOT FOR MAINLINE ftrace: pass module struct to arch dynamic ftrace functions powerpc: ftrace, do not latency trace idle powerpc: ftrace, convert to new dynamic ftrace arch API powerpc/ppc64: ftrace, mcount record powerpc port powerpc: ftrace, use probe_kernel API to modify code powerpc/ppc64: ftrace, handle module trampolines for dyn ftrace powerpc/ppc32: ftrace, enabled dynamic ftrace powerpc/ppc32: ftrace, dynamic ftrace to handle modules arch/powerpc/Kconfig |2 + arch/powerpc/include/asm/ftrace.h | 14 +- arch/powerpc/include/asm/module.h | 16 ++- arch/powerpc/kernel/ftrace.c | 473 +--- arch/powerpc/kernel/idle.c|5 + arch/powerpc/kernel/module_32.c | 10 + arch/powerpc/kernel/module_64.c | 13 + arch/x86/include/asm/ftrace.h |9 +- arch/x86/kernel/ftrace.c | 168 +- include/linux/ftrace.h| 51 - kernel/module.c |2 +- kernel/trace/ftrace.c | 137 ++-- scripts/recordmcount.pl | 20 ++- 13 files changed, 790 insertions(+), 130 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'merge' branch (for 2.6.28)
Please pull from 'merge' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge to receive the following updates: arch/powerpc/boot/dts/mpc832x_rdb.dts |4 ++-- arch/powerpc/boot/dts/mpc8572ds.dts|2 +- arch/powerpc/configs/86xx/gef_sbc610_defconfig |2 +- 3 files changed, 4 insertions(+), 4 deletions(-) Martyn Welch (1): powerpc: Use generic PHY driver for Marvell 88E PHY on GE Fanuc SBC610 Michael Barkowski (1): powerpc/mpc832x_rdb: fix swapped ethernet ids Trent Piepho (1): powerpc/85xx: L2 cache size wrong in 8572DS dts ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc832x_rdb: fix swapped ethernet ids
On Nov 13, 2008, at 9:18 AM, Michael Barkowski wrote: ethernet0 (called FSL UEC0 in U-Boot) should be enet1 (UCC3/eth1), and ethernet1 should be enet0 (UCC2/eth0), to be consistent with U-Boot so that the interfaces do not swap addresses when control passes from U-Boot to the kernel. Signed-off-by: Michael Barkowski <[EMAIL PROTECTED]> Acked-by: Kim Phillips <[EMAIL PROTECTED]> --- Cheat sheet: | *Nickname* | WAN port | LAN switch | | *MAC address* | ethaddr | eth1addr | | *U-Boot name* | FSL UEC0 | FSL UEC1 | | *Linux name* | eth1 | eth0 | | *Phy ID* | 4 | 0 | | *QE Device* | [EMAIL PROTECTED] | [EMAIL PROTECTED] | arch/powerpc/boot/dts/mpc832x_rdb.dts |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) applied to merge. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Use generic PHY driver for Marvell 88E1111 PHY on GE Fanuc SBC610
On Nov 18, 2008, at 4:55 AM, Martyn Welch wrote: The Marvell PHY driver is currently being used for the 88E on the SBC610. This driver is causing the link to run in 10/Half mode, the generic PHY driver is correctly configuring the PHY as 1000/Full. Edit default config to use generic PHY driver. Signed-off-by: Martyn Welch <[EMAIL PROTECTED]> --- Agh! My mistake - forgot to add "Signed-off", sorry. arch/powerpc/configs/86xx/gef_sbc610_defconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied to merge. (I still think you should fix it to work with the proper driver). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: L2 cache size wrong in 8572DS dts
On Nov 19, 2008, at 12:40 PM, Trent Piepho wrote: It's 1MB, not 512KB. Newer U-Boots will fix this entry, but that's no reason to have the wrong value in the dts. Signed-off-by: Trent Piepho <[EMAIL PROTECTED]> Acked-by: Kumar Gala <[EMAIL PROTECTED]> --- arch/powerpc/boot/dts/mpc8572ds.dts |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied to merge - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Better setup of boot page TLB entry
On Nov 19, 2008, at 1:14 PM, Trent Piepho wrote: The initial TLB mapping for the kernel boot didn't set the memory coherent attribute, MAS2[M], in SMP mode. If this code supported booting a secondary processor, which it doesn't yet, but suppose it did, then when a secondary processor boots, it would have probably signaled the primary processor by setting a variable called something like __secondary_hold_acknowledge. However, due to the lack of the M bit, the primary processor would not have snooped the transaction (even if a transaction were broadcast). If primary CPU's L1 D-cache had a copy, it would not have been flushed and the CPU would have never seen the ack. Which would have resulted in the primary CPU spinning for a long time, perhaps a full second before it would have given up, while it would have waited for the ack from the secondary CPU that it wouldn't have been able to see because of the stale cache. The value of MAS2 for the boot page TLB1 entry is a compile time constant, so there is no need to calculate it in powerpc assembly language. Also, from the MPC8572 manual section 6.12.5.3, "Bits that represent offsets within a page are ignored and should be cleared." Existing code didn't clear them, this code does. The same when the page of KERNELBASE is found; we don't need to use asm to mask the lower 12 bits off. In the code that computes the address to rfi from, don't hard code the offset to 24 bytes, but have the assembler figure that out for us. Signed-off-by: Trent Piepho <[EMAIL PROTECTED]> Acked-by: Kumar Gala <[EMAIL PROTECTED]> --- arch/powerpc/include/asm/mmu-fsl-booke.h |2 ++ arch/powerpc/kernel/head_fsl_booke.S | 22 +- 2 files changed, 15 insertions(+), 9 deletions(-) applied to next. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Better setup of boot page TLB entry
The initial TLB mapping for the kernel boot didn't set the memory coherent attribute, MAS2[M], in SMP mode. If this code supported booting a secondary processor, which it doesn't yet, but suppose it did, then when a secondary processor boots, it would have probably signaled the primary processor by setting a variable called something like __secondary_hold_acknowledge. However, due to the lack of the M bit, the primary processor would not have snooped the transaction (even if a transaction were broadcast). If primary CPU's L1 D-cache had a copy, it would not have been flushed and the CPU would have never seen the ack. Which would have resulted in the primary CPU spinning for a long time, perhaps a full second before it would have given up, while it would have waited for the ack from the secondary CPU that it wouldn't have been able to see because of the stale cache. The value of MAS2 for the boot page TLB1 entry is a compile time constant, so there is no need to calculate it in powerpc assembly language. Also, from the MPC8572 manual section 6.12.5.3, "Bits that represent offsets within a page are ignored and should be cleared." Existing code didn't clear them, this code does. The same when the page of KERNELBASE is found; we don't need to use asm to mask the lower 12 bits off. In the code that computes the address to rfi from, don't hard code the offset to 24 bytes, but have the assembler figure that out for us. Signed-off-by: Trent Piepho <[EMAIL PROTECTED]> Acked-by: Kumar Gala <[EMAIL PROTECTED]> --- arch/powerpc/include/asm/mmu-fsl-booke.h |2 ++ arch/powerpc/kernel/head_fsl_booke.S | 22 +- 2 files changed, 15 insertions(+), 9 deletions(-) diff --git a/arch/powerpc/include/asm/mmu-fsl-booke.h b/arch/powerpc/include/asm/mmu-fsl-booke.h index 925d93c..5588a41 100644 --- a/arch/powerpc/include/asm/mmu-fsl-booke.h +++ b/arch/powerpc/include/asm/mmu-fsl-booke.h @@ -40,6 +40,8 @@ #define MAS2_M 0x0004 #define MAS2_G 0x0002 #define MAS2_E 0x0001 +#define MAS2_EPN_MASK(size)(~0 << (2*(size) + 10)) +#define MAS2_VAL(addr, size, flags)((addr) & MAS2_EPN_MASK(size) | (flags)) #define MAS3_RPN 0xF000 #define MAS3_U00x0200 diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S index 590304c..e621eac 100644 --- a/arch/powerpc/kernel/head_fsl_booke.S +++ b/arch/powerpc/kernel/head_fsl_booke.S @@ -235,36 +235,40 @@ skpinv: addir6,r6,1 /* Increment */ tlbivax 0,r9 TLBSYNC +/* The mapping only needs to be cache-coherent on SMP */ +#ifdef CONFIG_SMP +#defineM_IF_SMPMAS2_M +#else +#define M_IF_SMP 0 +#endif + /* 6. Setup KERNELBASE mapping in TLB1[0] */ lis r6,0x1000 /* Set MAS0(TLBSEL) = TLB1(1), ESEL = 0 */ mtspr SPRN_MAS0,r6 lis r6,(MAS1_VALID|MAS1_IPROT)@h ori r6,r6,(MAS1_TSIZE(BOOKE_PAGESZ_64M))@l mtspr SPRN_MAS1,r6 - li r7,0 - lis r6,[EMAIL PROTECTED] - ori r6,r6,[EMAIL PROTECTED] - rlwimi r6,r7,0,20,31 + lis r6,MAS2_VAL(PAGE_OFFSET, BOOKE_PAGESZ_64M, M_IF_SMP)@h + ori r6,r6,MAS2_VAL(PAGE_OFFSET, BOOKE_PAGESZ_64M, M_IF_SMP)@l mtspr SPRN_MAS2,r6 mtspr SPRN_MAS3,r8 tlbwe /* 7. Jump to KERNELBASE mapping */ - lis r6,[EMAIL PROTECTED] - ori r6,r6,[EMAIL PROTECTED] - rlwimi r6,r7,0,20,31 + lis r6,(KERNELBASE & ~0xfff)@h + ori r6,r6,(KERNELBASE & ~0xfff)@l lis r7,[EMAIL PROTECTED] ori r7,r7,[EMAIL PROTECTED] bl 1f /* Find our address */ 1: mflrr9 rlwimi r6,r9,0,20,31 - addir6,r6,24 + addir6,r6,(2f - 1b) mtspr SPRN_SRR0,r6 mtspr SPRN_SRR1,r7 rfi /* start execution out of TLB1[0] entry */ /* 8. Clear out the temp mapping */ - lis r7,0x1000 /* Set MAS0(TLBSEL) = 1 */ +2: lis r7,0x1000 /* Set MAS0(TLBSEL) = 1 */ rlwimi r7,r5,16,4,15 /* Setup MAS0 = TLBSEL | ESEL(r5) */ mtspr SPRN_MAS0,r7 tlbre -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: L2 cache size wrong in 8572DS dts
It's 1MB, not 512KB. Newer U-Boots will fix this entry, but that's no reason to have the wrong value in the dts. Signed-off-by: Trent Piepho <[EMAIL PROTECTED]> Acked-by: Kumar Gala <[EMAIL PROTECTED]> --- arch/powerpc/boot/dts/mpc8572ds.dts |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/boot/dts/mpc8572ds.dts b/arch/powerpc/boot/dts/mpc8572ds.dts index cadd465..5c69b2f 100644 --- a/arch/powerpc/boot/dts/mpc8572ds.dts +++ b/arch/powerpc/boot/dts/mpc8572ds.dts @@ -90,7 +90,7 @@ compatible = "fsl,mpc8572-l2-cache-controller"; reg = <0x2 0x1000>; cache-line-size = <32>; // 32 bytes - cache-size = <0x8>; // L2, 512K + cache-size = <0x10>; // L2, 1M interrupt-parent = <&mpic>; interrupts = <16 2>; }; -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 8360E MDS - linux 2.6.20
On 19 Nov 2008 09:08:10 - "nanda" <[EMAIL PROTECTED]> wrote: > I could successfully build the uImage for linux 2.6.20.6 on the mpc8360E > MDS. But I also need the rootfs.ext2.gz.uboot(RAMDisk Image) required for > bringing up the board. Can also get the steps for the building the rootfs? > > Since the reference board mpc8360E MDS which I got from freescale had > default (uImage and rootfs.ext2.gz.uboot) only for linux 2.6.11. Iam finding > difficulty in bringing for linux 2.6.20.6 kernel. What problems are you seeing running the 2.6.20 based kernel image and the rootfs you built with ltib? Kim ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [powerpc] Xilinx: SPI: updated driver for device tree
The driver was updated to use the device tree rather than the platform data.
Signed-off-by: John Linn <[EMAIL PROTECTED]>
---
drivers/spi/xilinx_spi.c | 137 +++---
1 files changed, 81 insertions(+), 56 deletions(-)
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index 68d6f49..fe7e5f3 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -15,12 +15,15 @@
#include
#include
#include
+
+#include
+#include
+#include
+
#include
#include
#include
-#include
-
#define XILINX_SPI_NAME "xilinx_spi"
/* Register definitions as per "OPB Serial Peripheral Interface (SPI) (v1.00e)
@@ -144,23 +147,14 @@ static int xilinx_spi_setup_transfer(struct spi_device
*spi,
struct spi_transfer *t)
{
u8 bits_per_word;
- u32 hz;
- struct xilinx_spi *xspi = spi_master_get_devdata(spi->master);
bits_per_word = (t) ? t->bits_per_word : spi->bits_per_word;
- hz = (t) ? t->speed_hz : spi->max_speed_hz;
if (bits_per_word != 8) {
dev_err(&spi->dev, "%s, unsupported bits_per_word=%d\n",
__func__, bits_per_word);
return -EINVAL;
}
- if (hz && xspi->speed_hz > hz) {
- dev_err(&spi->dev, "%s, unsupported clock rate %uHz\n",
- __func__, hz);
- return -EINVAL;
- }
-
return 0;
}
@@ -304,32 +298,38 @@ static irqreturn_t xilinx_spi_irq(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static int __init xilinx_spi_probe(struct platform_device *dev)
+static int __init xilinx_spi_of_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
{
- int ret = 0;
struct spi_master *master;
struct xilinx_spi *xspi;
- struct xspi_platform_data *pdata;
- struct resource *r;
+ struct resource r_irq_struct;
+ struct resource r_mem_struct;
+
+ struct resource *r_irq = &r_irq_struct;
+ struct resource *r_mem = &r_mem_struct;
+ int rc = 0;
+ const u32 *prop;
+ int len;
/* Get resources(memory, IRQ) associated with the device */
- master = spi_alloc_master(&dev->dev, sizeof(struct xilinx_spi));
+ master = spi_alloc_master(&ofdev->dev, sizeof(struct xilinx_spi));
if (master == NULL) {
return -ENOMEM;
}
- platform_set_drvdata(dev, master);
- pdata = dev->dev.platform_data;
+ dev_set_drvdata(&ofdev->dev, master);
- if (pdata == NULL) {
- ret = -ENODEV;
+ rc = of_address_to_resource(ofdev->node, 0, r_mem);
+ if (rc) {
+ dev_warn(&ofdev->dev, "invalid address\n");
goto put_master;
}
- r = platform_get_resource(dev, IORESOURCE_MEM, 0);
- if (r == NULL) {
- ret = -ENODEV;
+ rc = of_irq_to_resource(ofdev->node, 0, r_irq);
+ if (rc == NO_IRQ) {
+ dev_warn(&ofdev->dev, "no IRQ found\n");
goto put_master;
}
@@ -341,47 +341,57 @@ static int __init xilinx_spi_probe(struct platform_device
*dev)
xspi->bitbang.master->setup = xilinx_spi_setup;
init_completion(&xspi->done);
- if (!request_mem_region(r->start,
- r->end - r->start + 1, XILINX_SPI_NAME)) {
- ret = -ENXIO;
+ xspi->irq = r_irq->start;
+
+ if (!request_mem_region(r_mem->start,
+ r_mem->end - r_mem->start + 1, XILINX_SPI_NAME)) {
+ rc = -ENXIO;
+ dev_warn(&ofdev->dev, "memory request failure\n");
goto put_master;
}
- xspi->regs = ioremap(r->start, r->end - r->start + 1);
+ xspi->regs = ioremap(r_mem->start, r_mem->end - r_mem->start + 1);
if (xspi->regs == NULL) {
- ret = -ENOMEM;
+ rc = -ENOMEM;
+ dev_warn(&ofdev->dev, "ioremap failure\n");
goto put_master;
}
+ xspi->irq = r_irq->start;
- ret = platform_get_irq(dev, 0);
- if (ret < 0) {
- ret = -ENXIO;
- goto unmap_io;
- }
- xspi->irq = ret;
+ /* dynamic bus assignment */
+ master->bus_num = -1;
- master->bus_num = pdata->bus_num;
- master->num_chipselect = pdata->num_chipselect;
- xspi->speed_hz = pdata->speed_hz;
+ /* number of slave select bits is required */
+ prop = of_get_property(ofdev->node, "xlnx,num-ss-bits", &len);
+ if (!prop || len < sizeof(*prop)) {
+ dev_warn(&ofdev->dev, "no 'xlnx,num-ss-bits' property\n");
+ goto put_master;
+ }
+ master->num_chipselect = *prop;
/* SPI controller initializations */
xspi_init_hw(xspi->regs);
/* Register for SPI Interrupt */
- ret = request_irq(xspi->irq, xilinx_spi_
Re: [PATCH] Fix BSR to allow mmap of small BSR on 64k kernel
On Wed, Nov 19, 2008 at 03:07:04PM +1100, Paul Mackerras wrote: > Sonny Rao writes: > > > - if (io_remap_pfn_range(vma, vma->vm_start, dev->bsr_addr >> PAGE_SHIFT, > > - size, vma->vm_page_prot)) > > + /* check for the case of a small BSR device and map one 4k page for it*/ > > + if (dev->bsr_len < PAGE_SIZE && size == PAGE_SIZE) > > + ret = remap_4k_pfn(vma, vma->vm_start, dev->bsr_addr >> 12, > > + vma->vm_page_prot); > > I think we should be checking that dev->bsr_len == 4096 here. > > Paul. Well, dev->bsr_len could be 4096 or 8192 -- Sonny Rao, LTC OzLabs, BML team ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Add a local_flush_tlb_page to handle kmap_atomic invalidates
The tlb invalidates in kmap_atomic/kunmap_atomic can be called from
IRQ context, however they are only local invalidates (on the processor
that the kmap was called on). In the future we want to use IPIs to
do tlb invalidates this causes issue since flush_tlb_page() is considered
a broadcast invalidate.
Add local_flush_tlb_page() as a non-broadcast invalidate and use it in
kmap_atomic() since we don't have enough information in the
flush_tlb_page() call to determine its local.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/highmem.h |4 ++--
arch/powerpc/include/asm/tlbflush.h | 14 ++
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/highmem.h
b/arch/powerpc/include/asm/highmem.h
index 91c5895..7dc52ec 100644
--- a/arch/powerpc/include/asm/highmem.h
+++ b/arch/powerpc/include/asm/highmem.h
@@ -85,7 +85,7 @@ static inline void *kmap_atomic_prot(struct page *page, enum
km_type type, pgpro
BUG_ON(!pte_none(*(kmap_pte-idx)));
#endif
__set_pte_at(&init_mm, vaddr, kmap_pte-idx, mk_pte(page, prot));
- flush_tlb_page(NULL, vaddr);
+ local_flush_tlb_page(vaddr);
return (void*) vaddr;
}
@@ -113,7 +113,7 @@ static inline void kunmap_atomic(void *kvaddr, enum km_type
type)
* this pte without first remap it
*/
pte_clear(&init_mm, vaddr, kmap_pte-idx);
- flush_tlb_page(NULL, vaddr);
+ local_flush_tlb_page(vaddr);
#endif
pagefault_enable();
}
diff --git a/arch/powerpc/include/asm/tlbflush.h
b/arch/powerpc/include/asm/tlbflush.h
index a2c6bfd..93716a9 100644
--- a/arch/powerpc/include/asm/tlbflush.h
+++ b/arch/powerpc/include/asm/tlbflush.h
@@ -6,6 +6,7 @@
*
* - flush_tlb_mm(mm) flushes the specified mm context TLB's
* - flush_tlb_page(vma, vmaddr) flushes one page
+ * - local_flush_tlb_page(vmaddr) flushes one page on the local processor
* - flush_tlb_page_nohash(vma, vmaddr) flushes one page if SW loaded TLB
* - flush_tlb_range(vma, start, end) flushes a range of pages
* - flush_tlb_kernel_range(start, end) flushes a range of kernel pages
@@ -44,6 +45,11 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
_tlbil_pid(mm->context.id);
}
+static inline void local_flush_tlb_page(unsigned long vmaddr)
+{
+ _tlbil_va(vmaddr, 0);
+}
+
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
{
@@ -81,6 +87,10 @@ extern void flush_tlb_page_nohash(struct vm_area_struct
*vma, unsigned long addr
extern void flush_tlb_range(struct vm_area_struct *vma, unsigned long start,
unsigned long end);
extern void flush_tlb_kernel_range(unsigned long start, unsigned long end);
+static inline void local_flush_tlb_page(unsigned long vmaddr)
+{
+ flush_tlb_page(NULL, vmaddr);
+}
#else
/*
@@ -138,6 +148,10 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
{
}
+static inline void local_flush_tlb_page(unsigned long vmaddr)
+{
+}
+
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
{
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: hash_page_sync should only be used on SMP & STD_MMU_32
Clean up the ifdefs so we only use hash_page_sync if we are
CONFIG_SMP && CONFIG_PPC_STD_MMU_32
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/mm/pgtable_32.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index c31d6d2..44fbc81 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -48,7 +48,7 @@ EXPORT_SYMBOL(ioremap_bot); /* aka VMALLOC_END */
extern char etext[], _stext[];
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) && defined(CONFIG_PPC_STD_MMU_32)
extern void hash_page_sync(void);
#endif
@@ -127,7 +127,7 @@ pgtable_t pte_alloc_one(struct mm_struct *mm, unsigned long
address)
void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
{
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) && defined(CONFIG_PPC_STD_MMU_32)
hash_page_sync();
#endif
free_page((unsigned long)pte);
@@ -135,7 +135,7 @@ void pte_free_kernel(struct mm_struct *mm, pte_t *pte)
void pte_free(struct mm_struct *mm, pgtable_t ptepage)
{
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) && defined(CONFIG_PPC_STD_MMU_32)
hash_page_sync();
#endif
pgtable_page_dtor(ptepage);
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc: udbg based backend for hvc_console
David Gibson wrote: > Um.. yeah.. I'm a bit baffled by this.. all the existing backends > are listed after hvc_console, I just added hvc_udbg to the end. I > didn't really understand the rationale in that commit, but then I > haven't had time to look at it very much yet. No, some are before: obj-$(CONFIG_HVC_RTAS) += hvc_rtas.o <--- obj-$(CONFIG_HVC_BEAT) += hvc_beat.o <--- obj-$(CONFIG_HVC_DRIVER)+= hvc_console.o obj-$(CONFIG_HVC_IRQ) += hvc_irq.o obj-$(CONFIG_HVC_XEN) += hvc_xen.o obj-$(CONFIG_HVC_UDBG) += hvc_udbg.o Until your patch, only Xen was wrong. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Add MSR[CE, DE] to the MSR bits we print on show_regs()
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/process.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 957bded..b038323 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -467,6 +467,8 @@ static struct regbit {
{MSR_VEC, "VEC"},
{MSR_VSX, "VSX"},
{MSR_ME,"ME"},
+ {MSR_CE,"CE"},
+ {MSR_DE,"DE"},
{MSR_IR,"IR"},
{MSR_DR,"DR"},
{0, NULL}
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: spinlock lockup with next-20081118 on powerpc
On Thu, Nov 20 2008, Stephen Rothwell wrote: > Hi Jens, > > On Wed, 19 Nov 2008 14:34:09 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > Are you removing devices or modules? We have a bug there it seems, does > > this help? > > This is early in boot (we are waiting for the root device while running > on the initramfs) so there could well be modules being unloaded. > > That patch makes the problem go away. Excellent, since it was an apparent but, I already updated the original patch with this hunk. Thanks a lot for your bisection work, Stephen! -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: spinlock lockup with next-20081118 on powerpc
Hi Jens, On Wed, 19 Nov 2008 14:34:09 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote: > > Are you removing devices or modules? We have a bug there it seems, does > this help? This is early in boot (we are waiting for the root device while running on the initramfs) so there could well be modules being unloaded. That patch makes the problem go away. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpSg9kZJurJM.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] IRQ assign for some PCIe devices
Hello all,
Fallowing a Benjamin Herrenschmidt request, I sending you a fix for IRQ
assign for some PCIe devices. This bug affects multiple PCIe devices
including Cadet-E, Squib-E, CISCO 4X SDR IB, and Knox adapters.
The problem lays in the fact OF does not create an "interrupt" property
for some PCIe device (for instance
"[EMAIL PROTECTED]/pci1014\,[EMAIL PROTECTED]/", an IBM Raid Controller) and
the kernel code fails returning a IRQ 0 (invalid one) if this property
is not present.
This patch changes the way to map interrupts to if the code can not get
"interrupts" property from PCI OF node, it falls back to standard OF
parsing. I verified and it worked fine with a pair of Squib-E SAS
adapter on a P6-570.
diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_parse.c
index bc1fb27..a11d689 100644
--- a/arch/powerpc/kernel/prom_parse.c
+++ b/arch/powerpc/kernel/prom_parse.c
@@ -250,8 +250,11 @@ int of_irq_map_pci(struct pci_dev *pdev, struct of_irq *out_irq)
* parsing
*/
dn = pci_device_to_OF_node(pdev);
- if (dn)
- return of_irq_map_one(dn, 0, out_irq);
+ if (dn) {
+ rc = of_irq_map_one(dn, 0, out_irq);
+ if (!rc)
+ return rc;
+ }
/* Ok, we don't, time to have fun. Let's start by building up an
* interrupt spec. we assume #interrupt-cells is 1, which is standard
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/mpic: don't reset affinity for secondary MPIC on boot
Kexec/kdump currently fails on the IBM QS2x blades when the kexec happens on a CPU other than the initial boot CPU. It turns out that this is the result of mpic_init trying to set affinity of each interrupt vector to the current boot CPU. As far as I can tell, the same problem is likely to exist on any secondary MPIC, because they have to deliver interrupts to the first output all the time. There are two potential solutions for this: either not set up affinity at all for secondary MPICs, or assume that CPU output 0 is connected to the upstream interrupt controller and hardcode affinity to that. This patch implements the first approach, because it can work on machines that have a secondary controller that needs to deliver interrupts to a destination other than CPU 0. The disadvantage is that it requires the system to set up the affinity register correctly on bootup. Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]> --- Index: linux-2.6/arch/powerpc/sysdev/mpic.c === --- linux-2.6.orig/arch/powerpc/sysdev/mpic.c +++ linux-2.6/arch/powerpc/sysdev/mpic.c @@ -1323,8 +1323,9 @@ void __init mpic_init(struct mpic *mpic) continue; /* init hw */ mpic_irq_write(i, MPIC_INFO(IRQ_VECTOR_PRI), vecpri); - mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION), - 1 << hard_smp_processor_id()); + if (mpic->flags & MPIC_PRIMARY) + mpic_irq_write(i, MPIC_INFO(IRQ_DESTINATION), + 1 << hard_smp_processor_id()); } /* Init spurious vector */ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: spinlock lockup with next-20081118 on powerpc
On Thu, Nov 20 2008, Stephen Rothwell wrote:
> Hi Jens,
>
> On Wed, 19 Nov 2008 11:58:33 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote:
> >
> > ;-) I'm aware of that, I meant the 'timer' data argument. But you are
> > right, it's probably q->queue_lock being NULL here or we would have
> > oopsed earlier. There's no code line.
> >
> > > address of the spinlock (though I need to check more to be sure) as it
> > > crashed inside _spin_lock_irqsave.
> >
> > Do you know what device this might be? It still makes no sense, if the
> > timer was added, we went through the normal IO paths and we would have
> > crashed on NULL ->queue_lock much earlier.
>
> I don't know much more, but I may find out tomorrow with Paul's help.
> However it bisects down to commit
> 279430a72bb6e83d335b4219e9af5557e2ff3350 "block: leave the request
> timeout timer running even on an empty list" and reverting that commit on
> next-20081118 makes the spinlock lockup go away.
Are you removing devices or modules? We have a bug there it seems, does
this help?
diff --git a/block/blk-core.c b/block/blk-core.c
index 04267d6..44f547c 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -391,6 +391,7 @@ EXPORT_SYMBOL(blk_stop_queue);
void blk_sync_queue(struct request_queue *q)
{
del_timer_sync(&q->unplug_timer);
+ del_timer_sync(&q->timeout);
kblockd_flush_work(&q->unplug_work);
}
EXPORT_SYMBOL(blk_sync_queue);
--
Jens Axboe
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: spinlock lockup with next-20081118 on powerpc
Hi Jens, On Wed, 19 Nov 2008 11:58:33 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote: > > ;-) I'm aware of that, I meant the 'timer' data argument. But you are > right, it's probably q->queue_lock being NULL here or we would have > oopsed earlier. There's no code line. > > > address of the spinlock (though I need to check more to be sure) as it > > crashed inside _spin_lock_irqsave. > > Do you know what device this might be? It still makes no sense, if the > timer was added, we went through the normal IO paths and we would have > crashed on NULL ->queue_lock much earlier. I don't know much more, but I may find out tomorrow with Paul's help. However it bisects down to commit 279430a72bb6e83d335b4219e9af5557e2ff3350 "block: leave the request timeout timer running even on an empty list" and reverting that commit on next-20081118 makes the spinlock lockup go away. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgplwMg7jlZHr.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Kernel completely crashes after accessing an unmapped area.
Hello All: I am using the paulus tree popwerpc linux kernel for a ppc440 cpu located in a Virtex5 FPGA. While developing some drivers (a simple gpio device) I have notice that if I try to access an unmapped area (an address without any register/device attached), the system completely crashes... I remember that doing the same with a ppc400 cpu the system showed a "Instruction/Data bus error" and continue working. My question: The ppc440 cannot recover from this types of errors or is a kernel missing feature/bug? Thanks and Best regards [ 24.770976] Oops: Machine check, sig: 7 [#1] [ 24.773932] PREEMPT Xilinx Virtex440 [ 24.777473] Modules linked in: spidev xilinx_spi spi_bitbang [ 24.783093] NIP: LR: 1858 CTR: c015ba80 [ 24.788022] REGS: c3ffdf10 TRAP: 0202 Not tainted (2.6.27) [ 24.793716] MSR: <> CR: 22000422 XER: 2000 [ 24.799077] TASK = c38d7000[2109] 'md.l' THREAD: c33ce000 [ 24.804258] GPR00: a5a5a5a5 bf8bcb40 48026480 4801e000 1858 22000424 480 [ 24.812552] GPR08: 0002d000 4801e000 c33ce000 c33ce000 10018ea0 03f [ 24.820846] GPR16: dbfa3fff 100 [ 24.829140] GPR24: 4800e454 bf8bce00 0002 bf8bce14 4802cce0 0ff [ 24.837614] NIP [] 0x0 [ 24.840634] LR [1858] 0x1858 [ 24.844174] Call Trace: [ 24.846594] Instruction dump: [ 24.849532] X [ 24.857220] X [ 24.864915] ---[ end trace 90dba81f5381e59d ]--- [ 24.869505] Oops: Machine check, sig: 7 [#2] [ 24.873722] PREEMPT Xilinx Virtex440 [ 24.877265] Modules linked in: spidev xilinx_spi spi_bitbang [ 24.882883] NIP: LR: c000da24 CTR: 00018486 [ 24.887812] REGS: c3ffdf10 TRAP: 0202 Tainted: G D(2.6.27) [ 24.894199] MSR: <> CR: 44040428 XER: [ 24.899559] TASK = c38d7000[2109] 'md.l' THREAD: c33ce000 [ 24.904740] GPR00: 0800 c3ffdd00 c38d7000 c3ffdd10 0001 000 [ 24.913035] GPR08: 0034 c000da24 00021002 c000a150 c38d7208 10018ea0 03f [ 24.921329] GPR16: dbfa3fff 100 [ 24.929624] GPR24: c3ffc034 0001 c030a798 c030a7a4 c3ffc000 c030a89c c02 [ 24.938093] NIP [] 0x0 [ 24.941133] LR [c000da24] ret_from_except+0x0/0x18 [ 24.945866] Call Trace: [ 24.948286] Instruction dump: [ 24.951223] X [ 24.958913] X [ 24.966604] ---[ end trace 90dba81f5381e59d ]--- [ 24.971183] Fixing recursive fault but reboot is needed! [ 24.976476] Oops: Machine check, sig: 7 [#3] [ 24.980685] PREEMPT Xilinx Virtex440 [ 24.984228] Modules linked in: spidev xilinx_spi spi_bitbang [ 24.989847] NIP: LR: c000da24 CTR: c0029e78 [ 24.994775] REGS: c3ffdf10 TRAP: 0202 Tainted: G D(2.6.27) [ 25.001163] MSR: <> CR: 442f2082 XER: [ 25.006523] TASK = c3822400[3] 'ksoftirqd/0' THREAD: c382c000 [ 25.012049] GPR00: c382de80 c3822400 c382de90 c38d7000 c0302c70 000 [ 25.020344] GPR08: 0098 c000da24 00021002 c0003ee4 c3822608 8fdd0dff c03 [ 25.028638] GPR16: c0302c40 c3822558 c382c034 c02e c0302c40 c030 c03 [ 25.036933] GPR24: c004 c02e506c c3285ba0 c382c000 c02e24b0 0002 c38 [ 25.045401] NIP [] 0x0 [ 25.048430] LR [c000da24] ret_from_except+0x0/0x18 [ 25.053175] Call Trace: [ 25.055599] [c382de80] [c3822400] 0xc3822400 (unreliable) [ 25.060967] [c382df40] [c0006310] __switch_to+0x54/0x78 [ 25.066146] [c382df60] [c02450c0] schedule+0x194/0x3ac [ 25.071243] [c382dfb0] [c0033098] ksoftirqd+0x108/0x194 [ 25.076436] [c382dfd0] [c0045504] kthread+0x48/0x84 [ 25.081264] [c382dff0] [c000d1a0] kernel_thread+0x4c/0x68 [ 25.086612] Instruction dump: [ 25.089549] X [ 25.097239] X [ 25.104931] ---[ end trace 90dba81f5381e59d ]--- [ 25.109512] note: ksoftirqd/0[3] exited with preempt_count 2 [ 25.115136] Oops: Machine check, sig: 7 [#4] [ 25.119357] PREEMPT Xilinx Virtex440 [ 25.122900] Modules linked in: spidev xilinx_spi spi_bitbang [ 25.128519] NIP: LR: c000da24 CTR: 00018486 [ 25.133447] REGS: c3ffdf10 TRAP: 0202 Tainted: G D(2.6.27) [ 25.139835] MSR: <> CR: 44242022 XER: 2000 [ 25.145194] TASK = c3822400[3] 'ksoftirqd/0' THREAD: c382c000 [ 25.150721] GPR00: c003077c c3ffddc0 c3822400 c3ffddd0 000 [ 25.159016] GPR08: 0036 c000da24 00021002 c0003ee4 c3822608 8fdd0dff c03 [ 25.167310] GPR16: c0302c40 c3822558 c382c034 c02e c0302c40 c030 c03 [ 25.175605] GPR24: c38224e0 c38224f4 c3822c00 c3ffdf10 c3ffc000 c38224e0
Re: [PATCH 0/7] Porting dynmaic ftrace to PowerPC
On Wed, 19 Nov 2008, Steven Rostedt wrote: > > On Wed, 19 Nov 2008, Ingo Molnar wrote: > > > > Maybe Steve could do the following trick: create a Linus -git based > > branch that uses the new APIs but marks ppc's ftrace as "depends 0" in > > the powerpc Kconfig. (the new ftrace.c wont build) > > There's only two generic commits that need to be added for the PowerPC > code to work. > > ftrace: pass module struct to arch dynamic ftrace functions > ftrace: allow NULL pointers in mcount_loc > > I've already ported them to mainline to test PowerPC there. > Paul could use these two versions and keep ftrace in a separate branch in > his tree. This way all the PowerPC code will be there, and actually can be > tested. They may still hit the same bugs that we have fixed in tip, but > those should all be minor, since any major bug is already in mainline or > on its way. I just pushed all the PowerPC patches on top of this port it works. I still need to rework the patches for Paul. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7] Porting dynmaic ftrace to PowerPC
On Wed, 19 Nov 2008, Ingo Molnar wrote: > > Maybe Steve could do the following trick: create a Linus -git based > branch that uses the new APIs but marks ppc's ftrace as "depends 0" in > the powerpc Kconfig. (the new ftrace.c wont build) There's only two generic commits that need to be added for the PowerPC code to work. ftrace: pass module struct to arch dynamic ftrace functions ftrace: allow NULL pointers in mcount_loc I've already ported them to mainline to test PowerPC there. Paul could use these two versions and keep ftrace in a separate branch in his tree. This way all the PowerPC code will be there, and actually can be tested. They may still hit the same bugs that we have fixed in tip, but those should all be minor, since any major bug is already in mainline or on its way. > > You could pull that tree into the powerpc tree and everything should > still work fine in PPC - sans ftrace. > > In tip/tracing we'd merge it too (these commits will never be > rebased), and we'd also remove the depends 0 from the powerpc Kconfig. > That sole change wont conflict with anything powerpc. > > It would all play out just fine in linux-next: we'd have both the > latest powerpc bits and the latest ftrace bits on powerpc. You could > test the non-ftrace impact of Steve's changes in the powerpc tree as > well and have it all part of your usual workflow. > > The 2.6.29 merge window would be trouble-free as well: since the > sha1's are the same, any of the trees can be merged upstream without > having to wait for the other one and without creating conflicts or > other trouble for the other one. > > Hm? If Paul uses the ported two generic commits, then he would need to keep that in a separate branch that will never go upstream. He could pull in the other PowerPC patches and do as you said, keep the depend off. I can make two branches that Paul could pull from. One would have this code disabled in the config, and just be the PowerPC port. Although, we would need to figure out the best way to keep it disabled. Disable it after the patches? The patches themselve enable it. And then I could make another branch with the back port of the two commits that Paul would never push upstream. This would allow for the PowerPC guys to test the code in their tree without waiting for it. We just need to trust that Paul will not push those commits ;-) Actually, I can change the subject of those commits to have at the beginning: NOT FOR UPSTREAM ftrace: What do you guys think? -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: allow configuring max stack dump depth
On my screen, when something crashes, I only have space for maybe
16 functions of the stack trace before the information above it
scrolls off the screen. It's easy to hack the kernel to print out
only that much, but it's harder to remember to do it. This patch
introduces a config option for it so that I can keep the setting
in my config.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
---
Sure, here's an updated version. I used DEBUG_KERNEL since the
ADVANCED_CONFIGURATION help text implies it's for MM and can cause the
kernel to not boot, not something this config is related to.
Thanks for your comments.
arch/powerpc/Kconfig.debug| 10 ++
arch/powerpc/kernel/process.c |2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
--- everything.orig/arch/powerpc/Kconfig.debug 2008-11-19 01:13:16.0
+0100
+++ everything/arch/powerpc/Kconfig.debug 2008-11-19 12:47:24.0
+0100
@@ -2,6 +2,16 @@ menu "Kernel hacking"
source "lib/Kconfig.debug"
+config PRINT_STACK_DEPTH
+ int "Stack depth to print"
+ depends on DEBUG_KERNEL
+ default 64
+ help
+ This option allows you to set the stack depth that the kernel
+ prints in stack traces. This can be useful if your display is
+ too small and stack traces cause important information to
+ scroll off the screen.
+
config DEBUG_STACKOVERFLOW
bool "Check for stack overflows"
depends on DEBUG_KERNEL
--- everything.orig/arch/powerpc/kernel/process.c 2008-11-19
01:13:16.0 +0100
+++ everything/arch/powerpc/kernel/process.c2008-11-19 12:45:28.0
+0100
@@ -998,7 +998,7 @@ unsigned long get_wchan(struct task_stru
return 0;
}
-static int kstack_depth_to_print = 64;
+static int kstack_depth_to_print = CONFIG_PRINT_STACK_DEPTH;
void show_stack(struct task_struct *tsk, unsigned long *stack)
{
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7] Porting dynmaic ftrace to PowerPC
Ingo Molnar writes: > and it's all in flux (we are in the middle of the development cycle), > so i dont think it would be a good idea for you to pull those bits > into the powerpc tree. Quite. OK, it does sound like this stuff needs to live in your tree for now, and from the diffstat it doesn't look like there is any conflict with stuff in my tree yet. > Maybe Steve could do the following trick: create a Linus -git based > branch that uses the new APIs but marks ppc's ftrace as "depends 0" in > the powerpc Kconfig. (the new ftrace.c wont build) > > You could pull that tree into the powerpc tree and everything should > still work fine in PPC - sans ftrace. Sounds like a reasonable idea, except that I think I'll delay pulling that branch into my tree until I need to in order to resolve a conflict - at least as far as my exported branches are concerned. > In tip/tracing we'd merge it too (these commits will never be > rebased), I do want to see the patches in their final form and have the opportunity to give an acked-by before you declare the branch frozen. Apart from that, sounds good. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: spinlock lockup with next-20081118 on powerpc
On Wed, Nov 19 2008, Stephen Rothwell wrote: > Hi Jens, > > On Wed, 19 Nov 2008 10:43:00 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > On Wed, Nov 19 2008, Stephen Rothwell wrote: > > > > > > Unable to handle kernel paging request for data at address 0x > > > Faulting instruction address: 0xc0503030 > > > cpu 0x0: Vector: 300 (Data Access) at [ca40] > > > pc: c0503030: ._spin_lock_irqsave+0x40/0x110 > > > lr: c02571f8: .blk_rq_timed_out_timer+0x48/0x190 > > > sp: ccc0 > > >msr: 80009032 > > >dar: 0 > > > dsisr: 4000 > > > current = 0xc00022d31040 > > > paca= 0xc0897300 > > > pid = 3399, comm = ckbcomp > > > enter ? for help > > > [cd50] c02571f8 .blk_rq_timed_out_timer+0x48/0x190 > > > [ce00] c006c2f4 .run_timer_softirq+0x1c4/0x2a0 > > > [ced0] c0065298 .__do_softirq+0xe8/0x1f0 > > > [cf90] c0029224 .call_do_softirq+0x14/0x24 > > > [c00022ad3c80] c000d420 .do_softirq+0xf0/0x140 > > > [c00022ad3d20] c00654a4 .irq_exit+0x74/0x90 > > > [c00022ad3da0] c0025844 .timer_interrupt+0x134/0x150 > > > [c00022ad3e30] c0003700 decrementer_common+0x100/0x180 > > > --- Exception: 901 (Decrementer) at 0ff52440 > > > > That's even more weird, how could 'data' passed in to the timer ever be > > 0? It's setup like this: > > 'data' above is generic, not a variable name. The 0 is probably the ;-) I'm aware of that, I meant the 'timer' data argument. But you are right, it's probably q->queue_lock being NULL here or we would have oopsed earlier. There's no code line. > address of the spinlock (though I need to check more to be sure) as it > crashed inside _spin_lock_irqsave. Do you know what device this might be? It still makes no sense, if the timer was added, we went through the normal IO paths and we would have crashed on NULL ->queue_lock much earlier. -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7] Porting dynmaic ftrace to PowerPC
* Paul Mackerras <[EMAIL PROTECTED]> wrote: > Ingo Molnar writes: > > > * Steven Rostedt <[EMAIL PROTECTED]> wrote: > > > > > On Wed, 19 Nov 2008, Paul Mackerras wrote: > > > > > > > Steven Rostedt writes: > > > > > > > > > Can I add your Acked-by: to all these patches that I submitted? I'm > > > > > going > > > > > to recommit them with a consistent subject (all lower case ppc), but > > > > > I'm > > > > > not going to change the patches themselves. > > > > > > > > > > Would you two be fine with that? Or at least one of you? > > > > > > > > My preference would be for the patches to go through the powerpc tree > > > > unless there is a good reason for them to go via another tree. > > > > > > I have no problem with that. The only thing is that we have a lot of > > > pending work still in the linux-tip tree, which you may need to pull > > > in to get these patches working. Well, there's two or three commits > > > in the generic code that I know the PPC code is dependent on. > > > > > > I could give you a list of commits in tip that need to go mainline > > > first before we can pull in the PPC changes. Then you could wait > > > till those changes make it into 29 and then you could push the PPC > > > modifications in from your tree. > > > > note that this inserts a lot of (unnecessary) serialization and a > > window of non-testing - by all likelyhood this will delay ppc ftrace > > to v2.6.30 or later kernels. > > Well, note that I said "unless there is a good reason". If it does > need to go via your tree, it can, though I don't see that it will > get much testing on powerpc there, and having it there will make it > harder to manage any conflicts with the other stuff I have queued > up. this is the diffstat: arch/powerpc/Kconfig |2 + arch/powerpc/include/asm/ftrace.h | 14 +- arch/powerpc/include/asm/module.h | 16 ++- arch/powerpc/kernel/ftrace.c | 460 +--- arch/powerpc/kernel/idle.c|5 + arch/powerpc/kernel/module_32.c | 10 + arch/powerpc/kernel/module_64.c | 13 + scripts/recordmcount.pl | 18 ++- 8 files changed, 495 insertions(+), 43 deletions(-) 90% of it creates new code that shouldnt be collision-happy. it does not "need" to go via tip/tracing, i just pointed out the effects of the proposed workflow and i'm just trying to find a more efficient workflow for it - while not impacting yours either. I think it can be done - git gives us tons of tools to do this intelligently. > How much generic stuff that's not upstream do the powerpc ftrace > patches depend on? a lot: 66 files changed, 3266 insertions(+), 985 deletions(-) and it's all in flux (we are in the middle of the development cycle), so i dont think it would be a good idea for you to pull those bits into the powerpc tree. Maybe Steve could do the following trick: create a Linus -git based branch that uses the new APIs but marks ppc's ftrace as "depends 0" in the powerpc Kconfig. (the new ftrace.c wont build) You could pull that tree into the powerpc tree and everything should still work fine in PPC - sans ftrace. In tip/tracing we'd merge it too (these commits will never be rebased), and we'd also remove the depends 0 from the powerpc Kconfig. That sole change wont conflict with anything powerpc. It would all play out just fine in linux-next: we'd have both the latest powerpc bits and the latest ftrace bits on powerpc. You could test the non-ftrace impact of Steve's changes in the powerpc tree as well and have it all part of your usual workflow. The 2.6.29 merge window would be trouble-free as well: since the sha1's are the same, any of the trees can be merged upstream without having to wait for the other one and without creating conflicts or other trouble for the other one. Hm? Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
More commits pushed to powerpc.git next branch
I have just pushed the following commits to the "next" branch of my powerpc.git repository, and also merged in Linus' current tree. The "master" branch is at the same point as "next". Paul. Chris J Arges (1): serial/pmac_zilog: Add console polling support David Gibson (1): powerpc: udbg-based backend for hvc_console Geert Uytterhoeven (1): powerpc/ps3: Replace the flip_ctl logic in ps3av and ps3fb by a mutex Hollis Blanchard (1): powerpc: Remove superfluous WARN_ON() from dma-noncoherent.c Mark Nelson (1): powerpc: Update 64bit __copy_tofrom_user() using CPU_FTR_UNALIGNED_LD_STD Michael Ellerman (4): of: Add helpers for finding device nodes which have a given property powerpc: Use for_each_node_with_property() in of_irq_map_init() powerpc: Use of_find_node_with_property() in cell_iommu_fixed_mapping_init() powerpc/pmac: Use of_find_node_with_property() in pmac_setup_arch() Milton Miller (2): powerpc: Provide a separate handler for each IPI action powerpc/mpic: Use new smp_request_message_ipi Nick Piggin (3): powerpc: Optimise smp_wmb powerpc: Optimise smp_rmb powerpc: Optimise mutex Paul Mackerras (1): powerpc: Tell gcc when we clobber the carry in inline asm Robert Jennings (1): powerpc: Correct page-in counter for CMM with 64k pages ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: BSR: support multiple OF-node description of BSR
Sonny Rao writes: > Add support for multiple BSR nodes in the device tree. This didn't apply. Does it depend on the "Fix BSR to allow mmap of small BSR on 64k kernel" patch being applied first perhaps? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7] Porting dynmaic ftrace to PowerPC
Ingo Molnar writes: > * Steven Rostedt <[EMAIL PROTECTED]> wrote: > > > On Wed, 19 Nov 2008, Paul Mackerras wrote: > > > > > Steven Rostedt writes: > > > > > > > Can I add your Acked-by: to all these patches that I submitted? I'm > > > > going > > > > to recommit them with a consistent subject (all lower case ppc), but > > > > I'm > > > > not going to change the patches themselves. > > > > > > > > Would you two be fine with that? Or at least one of you? > > > > > > My preference would be for the patches to go through the powerpc tree > > > unless there is a good reason for them to go via another tree. > > > > I have no problem with that. The only thing is that we have a lot of > > pending work still in the linux-tip tree, which you may need to pull > > in to get these patches working. Well, there's two or three commits > > in the generic code that I know the PPC code is dependent on. > > > > I could give you a list of commits in tip that need to go mainline > > first before we can pull in the PPC changes. Then you could wait > > till those changes make it into 29 and then you could push the PPC > > modifications in from your tree. > > note that this inserts a lot of (unnecessary) serialization and a > window of non-testing - by all likelyhood this will delay ppc ftrace > to v2.6.30 or later kernels. Well, note that I said "unless there is a good reason". If it does need to go via your tree, it can, though I don't see that it will get much testing on powerpc there, and having it there will make it harder to manage any conflicts with the other stuff I have queued up. How much generic stuff that's not upstream do the powerpc ftrace patches depend on? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: spinlock lockup with next-20081118 on powerpc
Hi Jens, On Wed, 19 Nov 2008 10:43:00 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote: > > On Wed, Nov 19 2008, Stephen Rothwell wrote: > > > > Unable to handle kernel paging request for data at address 0x > > Faulting instruction address: 0xc0503030 > > cpu 0x0: Vector: 300 (Data Access) at [ca40] > > pc: c0503030: ._spin_lock_irqsave+0x40/0x110 > > lr: c02571f8: .blk_rq_timed_out_timer+0x48/0x190 > > sp: ccc0 > >msr: 80009032 > >dar: 0 > > dsisr: 4000 > > current = 0xc00022d31040 > > paca= 0xc0897300 > > pid = 3399, comm = ckbcomp > > enter ? for help > > [cd50] c02571f8 .blk_rq_timed_out_timer+0x48/0x190 > > [ce00] c006c2f4 .run_timer_softirq+0x1c4/0x2a0 > > [ced0] c0065298 .__do_softirq+0xe8/0x1f0 > > [cf90] c0029224 .call_do_softirq+0x14/0x24 > > [c00022ad3c80] c000d420 .do_softirq+0xf0/0x140 > > [c00022ad3d20] c00654a4 .irq_exit+0x74/0x90 > > [c00022ad3da0] c0025844 .timer_interrupt+0x134/0x150 > > [c00022ad3e30] c0003700 decrementer_common+0x100/0x180 > > --- Exception: 901 (Decrementer) at 0ff52440 > > That's even more weird, how could 'data' passed in to the timer ever be > 0? It's setup like this: 'data' above is generic, not a variable name. The 0 is probably the address of the spinlock (though I need to check more to be sure) as it crashed inside _spin_lock_irqsave. > setup_timer(&q->timeout, blk_rq_timed_out_timer, (unsigned long) q); > > when we allocate the queue. How did this trigger? Not sure what you mean? -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpuZ3Ic18S4H.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: spinlock lockup with next-20081118 on powerpc
On Wed, Nov 19 2008, Stephen Rothwell wrote: > Hi all, > > I got this in my boot test last night: > > Begin: Waiting for root file system... ... > BUG: spinlock lockup on CPU#1, vol_id/3246, c0b09700 > Call Trace: > [c00040ef7080] [c000fb58] .show_stack+0x70/0x184 (unreliable) > [c00040ef7130] [c027adac] ._raw_spin_lock+0x140/0x17c > [c00040ef71d0] [c04ec648] ._spin_lock_irqsave+0x8c/0xc4 > [c00040ef7270] [c00659dc] .lock_timer_base+0x38/0x90 > [c00040ef7310] [c0065b50] .__mod_timer+0x4c/0x11c > [c00040ef73c0] [c025ae9c] .blk_plug_device+0xc0/0xd8 > [c00040ef7440] [c025bb90] .__make_request+0x498/0x518 > [c00040ef74f0] [c0259dc8] .generic_make_request+0x24c/0x2a4 > [c00040ef75b0] [c025b6d0] .submit_bio+0x108/0x130 > [c00040ef7670] [c01210e4] .submit_bh+0x174/0x1c0 > [c00040ef7700] [c01259a8] .block_read_full_page+0x34c/0x3b4 > [c00040ef7820] [c0129a60] .blkdev_readpage+0x20/0x38 > [c00040ef78a0] [c00c111c] .__do_page_cache_readahead+0x23c/0x2b8 > [c00040ef7980] [c00c1370] .ondemand_readahead+0x1d8/0x210 > [c00040ef7a30] [c00b7f20] .generic_file_aio_read+0x224/0x620 > [c00040ef7b60] [c00f9020] .do_sync_read+0xc4/0x124 > [c00040ef7cf0] [c00f98e0] .vfs_read+0xd8/0x1bc > [c00040ef7d90] [c00f9f0c] .sys_read+0x4c/0x8c > [c00040ef7e30] [c00084d4] syscall_exit+0x0/0x40 > > This was on a Power5 partition. I am attempting to reproduce the problem. > > Any clues? Strange, so it gets stuck on the timer lock, very weird. You don't happen to have output showing that the other CPU is up to at that point? -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: spinlock lockup with next-20081118 on powerpc
On Wed, Nov 19 2008, Stephen Rothwell wrote: > Hi Jens, > > On Wed, 19 Nov 2008 10:16:28 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote: > > > > Strange, so it gets stuck on the timer lock, very weird. You don't > > happen to have output showing that the other CPU is up to at that point? > > Unfortunately, no, but I will see what I can find tomorrow. > > Today's linux-next still has a problem, but it is slightly different: > > Unable to handle kernel paging request for data at address 0x > Faulting instruction address: 0xc0503030 > cpu 0x0: Vector: 300 (Data Access) at [ca40] > pc: c0503030: ._spin_lock_irqsave+0x40/0x110 > lr: c02571f8: .blk_rq_timed_out_timer+0x48/0x190 > sp: ccc0 >msr: 80009032 >dar: 0 > dsisr: 4000 > current = 0xc00022d31040 > paca= 0xc0897300 > pid = 3399, comm = ckbcomp > enter ? for help > [cd50] c02571f8 .blk_rq_timed_out_timer+0x48/0x190 > [ce00] c006c2f4 .run_timer_softirq+0x1c4/0x2a0 > [ced0] c0065298 .__do_softirq+0xe8/0x1f0 > [cf90] c0029224 .call_do_softirq+0x14/0x24 > [c00022ad3c80] c000d420 .do_softirq+0xf0/0x140 > [c00022ad3d20] c00654a4 .irq_exit+0x74/0x90 > [c00022ad3da0] c0025844 .timer_interrupt+0x134/0x150 > [c00022ad3e30] c0003700 decrementer_common+0x100/0x180 > --- Exception: 901 (Decrementer) at 0ff52440 That's even more weird, how could 'data' passed in to the timer ever be 0? It's setup like this: setup_timer(&q->timeout, blk_rq_timed_out_timer, (unsigned long) q); when we allocate the queue. How did this trigger? -- Jens Axboe ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: linux-next: spinlock lockup with next-20081118 on powerpc
Hi Jens, On Wed, 19 Nov 2008 10:16:28 +0100 Jens Axboe <[EMAIL PROTECTED]> wrote: > > Strange, so it gets stuck on the timer lock, very weird. You don't > happen to have output showing that the other CPU is up to at that point? Unfortunately, no, but I will see what I can find tomorrow. Today's linux-next still has a problem, but it is slightly different: Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc0503030 cpu 0x0: Vector: 300 (Data Access) at [ca40] pc: c0503030: ._spin_lock_irqsave+0x40/0x110 lr: c02571f8: .blk_rq_timed_out_timer+0x48/0x190 sp: ccc0 msr: 80009032 dar: 0 dsisr: 4000 current = 0xc00022d31040 paca= 0xc0897300 pid = 3399, comm = ckbcomp enter ? for help [cd50] c02571f8 .blk_rq_timed_out_timer+0x48/0x190 [ce00] c006c2f4 .run_timer_softirq+0x1c4/0x2a0 [ced0] c0065298 .__do_softirq+0xe8/0x1f0 [cf90] c0029224 .call_do_softirq+0x14/0x24 [c00022ad3c80] c000d420 .do_softirq+0xf0/0x140 [c00022ad3d20] c00654a4 .irq_exit+0x74/0x90 [c00022ad3da0] c0025844 .timer_interrupt+0x134/0x150 [c00022ad3e30] c0003700 decrementer_common+0x100/0x180 --- Exception: 901 (Decrementer) at 0ff52440 I am currently bisecting yesterday's linux-next. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpAEgsCi1T70.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7] Porting dynmaic ftrace to PowerPC
* Steven Rostedt <[EMAIL PROTECTED]> wrote: > On Wed, 19 Nov 2008, Paul Mackerras wrote: > > > Steven Rostedt writes: > > > > > Can I add your Acked-by: to all these patches that I submitted? I'm going > > > to recommit them with a consistent subject (all lower case ppc), but I'm > > > not going to change the patches themselves. > > > > > > Would you two be fine with that? Or at least one of you? > > > > My preference would be for the patches to go through the powerpc tree > > unless there is a good reason for them to go via another tree. > > I have no problem with that. The only thing is that we have a lot of > pending work still in the linux-tip tree, which you may need to pull > in to get these patches working. Well, there's two or three commits > in the generic code that I know the PPC code is dependent on. > > I could give you a list of commits in tip that need to go mainline > first before we can pull in the PPC changes. Then you could wait > till those changes make it into 29 and then you could push the PPC > modifications in from your tree. note that this inserts a lot of (unnecessary) serialization and a window of non-testing - by all likelyhood this will delay ppc ftrace to v2.6.30 or later kernels. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
