Re: [git pull] Please pull powerpc.git merge branch
--- On Mon, 7/2/12, Benjamin Herrenschmidt wrote: > From: Benjamin Herrenschmidt > Subject: Re: [git pull] Please pull powerpc.git merge branch > To: "Gerhard Pircher" > Cc: "linuxppc-dev list" > Date: Monday, July 2, 2012, 3:20 PM > On Mon, 2012-07-02 at 23:38 +0200, > Gerhard Pircher wrote: > > > > What about this fix:? > > > > http://patchwork.ozlabs.org/patch/166346/ > > > > At least I can't see it in the log... > > The module fix went in. The ftrace patch, well, it's > untested and we > don't even know if we have a problem with mcount yet, so no, > I haven't > merged it yet. > > Cheers, > Ben. > > I have had a chance to test this patch. Before it is applied I get the following message when loading a module: Not a trampoline [ cut here ] WARNING: at /src/git/linux-powerpc/kernel/trace/ftrace.c:1583 Modules linked in: gpio_w1_transport(O+) NIP: c008129c LR: c0082138 CTR: c021d744 REGS: c532dd80 TRAP: 0700 Tainted: G O (3.4.3-2-g23fc8c3) MSR: 00029032 CR: 22082282 XER: 2000 TASK = c5256900[363] 'insmod' THREAD: c532c000 GPR00: 0001 c532de30 c5256900 ffea c907b008 c046befc 20747261 GPR08: c046be40 c045c862 8000 22082224 10019fdc 100f GPR16: 100f5678 100dc70c eac3ec00 c0011bb0 c046890c GPR24: c907b008 c70d8f80 c0443d0c c5338000 000c c907b008 c049a910 NIP [c008129c] ftrace_bug+0xc0/0x25c LR [c0082138] ftrace_process_locs+0x47c/0x608 Call Trace: [c532de30] [c008fe04] ftrace_now+0x38/0x78 (unreliable) [c532de50] [c0082138] ftrace_process_locs+0x47c/0x608 [c532dea0] [c008232c] ftrace_module_notify+0x68/0x7c [c532deb0] [c004cd80] notifier_call_chain+0x90/0xe0 [c532dee0] [c004d27c] __blocking_notifier_call_chain+0x68/0x94 [c532df10] [c004d2cc] blocking_notifier_call_chain+0x24/0x34 [c532df20] [c0073b38] sys_init_module+0xa0/0x1e0 [c532df40] [c0011254] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xff5d694 LR = 0x1cd4 Instruction dump: 90090008 48294b71 3c60c03c 7fc4f378 7fc5f378 3863874c 48294b5d 48000188 3d20c046 3929c862 88090003 6801 <0f00> 2f80 409e0148 3d20c001 ---[ end trace aaa9b56024f9d2b9 ]--- ftrace failed to modify [] gpio_w1_reset_bus+0x8/0xc0 [gpio_w1_transport] actual: 48:00:04:99 and the trace file dump results in: # tracer: nop # # WARNING: FUNCTION TRACING IS CORRUPTED # MAY BE MISSING FUNCTION EVENTS # entries-in-buffer/entries-written: 0/0 #P:1 # # _-=> irqs-off # / _=> need-resched #| / _---=> hardirq/softirq #|| / _--=> preempt-depth #||| / delay # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | after the patch is applied I get no messages on module loading and ftrace no longer complains, and I can trace my module's functions. So I can add Tested-By: Roger Blofeld -rb ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] kernel panic during kernel module load (powerpc specific part)
--- On Wed, 6/6/12, Steffen Rumler wrote:
> From: Steffen Rumler
> Subject: [PATCH] kernel panic during kernel module load (powerpc specific
> part)
> To: "ext Benjamin Herrenschmidt" , pau...@samba.org
> Cc: "Wrobel Heinz-R39252" , "Michael Ellerman"
> , "linuxppc-dev@lists.ozlabs.org"
>
> Date: Wednesday, June 6, 2012, 7:37 AM
> Hi,
>
> The patch below is intended to fix the following problem.
>
> According to the PowerPC EABI specification, the GPR r11 is
> assigned
> the dedicated function to point to the previous stack
> frame.
> In the powerpc-specific kernel module loader, do_plt_call()
> (in arch/powerpc/kernel/module_32.c), the GPR r11 is also
> used
> to generate trampoline code.
>
> This combination crashes the kernel, in the following case:
>
> + The compiler has been generated the prologue and
> epilogue,
> which is part of the .text section.
> + The compiler has been generated the code for the
> module init entry point,
> part of the .init.text section (in the case it
> is marked with __init).
> + By returning from the module init entry point, the
> epilogue is called by doing
> a branch instruction.
> + If the epilogue is too far away, a relative branch
> instruction cannot be applied.
> Instead trampoline code is generated in
> do_plt_call(), in order to jump via register.
> Unfortunately the code generated by
> do_plt_call() destroys the content of GPR r11.
> + Because GPR r11 does not more keep the right stack
> frame pointer,
> the kernel crashes right after the epilogue.
>
> The fix just uses GPR r12 instead of GPR r11 for generating
> the trampoline code.
> According to the statements from Freescale, this is also
> save from EABI perspective.
>
> I've tested the fix for kernel 2.6.33 on MPC8541.
>
> Signed-off-by: Steffen Rumler
> ---
>
> --- orig/arch/powerpc/kernel/module_32.c
> 2012-06-06 16:04:28.956446788 +0200
> +++ new/arch/powerpc/kernel/module_32.c
> 2012-06-06 16:04:17.746290683 +0200
> @@ -187,8 +187,8 @@
>
> static inline int entry_matches(struct ppc_plt_entry
> *entry, Elf32_Addr val)
> {
> - if (entry->jump[0] == 0x3d60 +
> ((val + 0x8000) >> 16)
> - &&
> entry->jump[1] == 0x396b + (val & 0x))
> + if (entry->jump[0] == 0x3d80 +
> ((val + 0x8000) >> 16)
> + &&
> entry->jump[1] == 0x398c + (val & 0x))
> return 1;
> return 0;
> }
> @@ -215,10 +215,9 @@
> entry++;
> }
>
> - /* Stolen from Paul Mackerras as well...
> */
> - entry->jump[0] =
> 0x3d60+((val+0x8000)>>16); /*
> lis r11,sym@ha */
> - entry->jump[1] = 0x396b +
> (val&0x); /* addi r11,r11,sym@l*/
> - entry->jump[2] =
> 0x7d6903a6;
> /* mtctr r11 */
> + entry->jump[0] =
> 0x3d80+((val+0x8000)>>16); /* lis r12,sym@ha */
> + entry->jump[1] = 0x398c +
> (val&0x); /* addi
> r12,r12,sym@l*/
> + entry->jump[2] = 0x7d8903a6;
>
> /* mtctr r12 */
> entry->jump[3] =
> 0x4e800420;
> /* bctr */
>
> DEBUGP("Initialized plt for 0x%x at
> %p\n", val, entry);
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
Hi,
Shouldn't the corresponding ftrace code be updated to match? Perhaps like the
following (untested) patch:
Signed-off-by: Roger Blofeld
---
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -245,9 +245,9 @@ __ftrace_make_nop(struct module *mod,
/*
* On PPC32 the trampoline looks like:
-* 0x3d, 0x60, 0x00, 0x00 lis r11,sym@ha
-* 0x39, 0x6b, 0x00, 0x00 addi r11,r11,sym@l
-* 0x7d, 0x69, 0x03, 0xa6 mtctr r11
+* 0x3d, 0x80, 0x00, 0x00 lis r12,sym@ha
+* 0x39, 0x8c, 0x00, 0x00 addi r12,r12,sym@l
+* 0x7d, 0x89, 0x03, 0xa6 mtctr r12
* 0x4e, 0x80, 0x04, 0x20 bctr
*/
@@ -262,9 +262,9 @@ __ftrace_make_nop(struct module *mod,
pr_devel(" %08x %08x ", jmp[0], jmp[1]);
/* verify that this is what we expect it to be */
- if (((jmp[0] & 0x) != 0x3d60) ||
- ((jmp[1] & 0x) != 0x396b) ||
- (jmp[2] != 0x7d6903a6) ||
+ if (((jmp[0] & 0x) != 0x3d80) ||
+ ((jmp[1] & 0x) != 0x398c) ||
+ (jmp[2] != 0x7d8903a6) ||
(jmp[3] != 0x4e800420)) {
printk(KERN_ERR "Not a trampoline\n");
return -EINVAL;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Dont require a dma_ops struct to set dma mask
- Original Message
> From: Kumar Gala
> To: linuxppc-...@ozlabs.org
> Sent: Mon, August 2, 2010 12:21:22 PM
> Subject: [PATCH] powerpc: Dont require a dma_ops struct to set dma mask
>
> The only reason to require a dma_ops struct is to see if it has
> implemented set_dma_mask. If not we can fall back to setting the mask
> directly.
>
> This resolves an issue with how to sequence the setting of a DMA mask
> for platform devices. Before we had an issue in that we have no way of
> setting the DMA mask before the various low level bus notifiers get
> called that might check it (swiotlb).
>
> So now we can do:
>
> pdev = platform_device_alloc("foobar", 0);
> dma_set_mask(&pdev->dev, DMA_BIT_MASK(37));
> platform_device_register(pdev);
>
> And expect the right thing to happen with the bus notifiers get called
> via platform_device_register.
>
> Signed-off-by: Kumar Gala
> ---
> arch/powerpc/include/asm/dma-mapping.h |4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/dma-mapping.h
>b/arch/powerpc/include/asm/dma-mapping.h
> index c85ef23..17d5c17 100644
> --- a/arch/powerpc/include/asm/dma-mapping.h
> +++ b/arch/powerpc/include/asm/dma-mapping.h
> @@ -131,9 +131,7 @@ static inline int dma_set_mask(struct device *dev, u64
>dma_mask)
> {
> struct dma_map_ops *dma_ops = get_dma_ops(dev);
>
> -if (unlikely(dma_ops == NULL))
> -return -EIO;
> -if (dma_ops->set_dma_mask != NULL)
> +if (unlikely(dma_ops == NULL) && (dma_ops->set_dma_mask != NULL))
> return dma_ops->set_dma_mask(dev, dma_mask);
> if (!dev->dma_mask || !dma_supported(dev, dma_mask))
> return -EIO;
> --
> 1.6.0.6
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
Isn't that test wrong? Perhaps you meant to test for dma_ops non-null before
dereferencing it?
-roger
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Restore dma ops for powermac cardbus drivers
> To: roger blofeld
> Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org;
> sta...@kernel.org
> Sent: Sun, November 29, 2009 11:49:27 PM
> Subject: Re: [PATCH] powerpc: Restore dma ops for powermac cardbus drivers
>
> On Sun, 2009-11-29 at 20:23 -0800, roger blofeld wrote:
> > Commit 4ae0ff606e848fa4957ebf8f97e5db5fdeec27be broke dma setup for cardbus
> > devices such as sata_sil, rt2500 and ath5k. This patch restores the default
> > dma ops for cardbus devices. Tested with sata_sil on a powerbook G4.
> >
> > bz#537176
> >
> > Signed-off-by: Roger Blofeld
>
> Hi !
>
> That's an interesting way to do it :-)
>
> However, I suppose a better approach would be to fix cardbus to call the
> proper fixup code in the arch, ie, dma isn't the only thing that's going
> to be broken without that (at least maybe on pmac that is, but machines
> with an iommu will suffer etc...)
>
> I will try to have a look as soon as I'm done with porting the pmac IDE
> driver to libata.
>
> Cheers,
> Ben.
>
Thanks. That would be great. I just copied this mostly from what pasemi did for
their cardbus.
-roger
> > ---
> > The inline patch is whitespace damaged by this mailer. The attachment
> > should
> be ok,
> > and passes checkpatch.pl
> >
> >
> > diff -up linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c.orig
> linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c
> > --- linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c.orig
> 2009-06-09 22:05:27.0 -0500
> > +++ linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c2009-11-29
> 21:47:15.0 -0600
> > @@ -514,6 +514,44 @@ static void __init pmac_init_early(void)
> > #endif
> > }
> >
> > +#ifdef CONFIG_CARDBUS
> > +static int pmac_cardbus_notify(struct notifier_block *nb, unsigned long
> action,
> > + void *data)
> > +{
> > +struct device *dev = data;
> > +struct device *parent;
> > +struct pci_dev *pdev = to_pci_dev(dev);
> > +
> > +/* We are only interested in device addition */
> > +if (action != BUS_NOTIFY_ADD_DEVICE)
> > +return 0;
> > +
> > +parent = pdev->dev.parent;
> > +
> > +if (!parent->archdata.of_node)
> > +return 0;
> > +
> > +if (!of_device_is_compatible(parent->archdata.of_node,
> > +"cardbus-bridge"))
> > +return 0;
> > +
> > +/* We use the direct ops for cardbus */
> > +dev->archdata.dma_ops = &dma_direct_ops;
> > +
> > +return 0;
> > +}
> > +
> > +static struct notifier_block cardbus_notifier = {
> > +.notifier_call = pmac_cardbus_notify,
> > +};
> > +
> > +static int __init pmac_cardbus_init(void)
> > +{
> > +return bus_register_notifier(&pci_bus_type, &cardbus_notifier);
> > +}
> > +machine_device_initcall(powermac, pmac_cardbus_init);
> > +#endif
> > +
> > static int __init pmac_declare_of_platform_devices(void)
> > {
> > struct device_node *np;
> >
> >
> >
> From: Benjamin Herrenschmidt
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Restore dma ops for powermac cardbus drivers
Commit 4ae0ff606e848fa4957ebf8f97e5db5fdeec27be broke dma setup for cardbus
devices such as sata_sil, rt2500 and ath5k. This patch restores the default
dma ops for cardbus devices. Tested with sata_sil on a powerbook G4.
bz#537176
Signed-off-by: Roger Blofeld
---
The inline patch is whitespace damaged by this mailer. The attachment should be
ok,
and passes checkpatch.pl
diff -up linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c.orig
linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c
--- linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c.orig2009-06-09
22:05:27.0 -0500
+++ linux-2.6.30.ppc/arch/powerpc/platforms/powermac/setup.c2009-11-29
21:47:15.0 -0600
@@ -514,6 +514,44 @@ static void __init pmac_init_early(void)
#endif
}
+#ifdef CONFIG_CARDBUS
+static int pmac_cardbus_notify(struct notifier_block *nb, unsigned long action,
+ void *data)
+{
+struct device *dev = data;
+struct device *parent;
+struct pci_dev *pdev = to_pci_dev(dev);
+
+/* We are only interested in device addition */
+if (action != BUS_NOTIFY_ADD_DEVICE)
+return 0;
+
+parent = pdev->dev.parent;
+
+if (!parent->archdata.of_node)
+return 0;
+
+if (!of_device_is_compatible(parent->archdata.of_node,
+"cardbus-bridge"))
+return 0;
+
+/* We use the direct ops for cardbus */
+dev->archdata.dma_ops = &dma_direct_ops;
+
+return 0;
+}
+
+static struct notifier_block cardbus_notifier = {
+.notifier_call = pmac_cardbus_notify,
+};
+
+static int __init pmac_cardbus_init(void)
+{
+return bus_register_notifier(&pci_bus_type, &cardbus_notifier);
+}
+machine_device_initcall(powermac, pmac_cardbus_init);
+#endif
+
static int __init pmac_declare_of_platform_devices(void)
{
struct device_node *np;
powermac-cardbus-dma-notifier.patch
Description: Binary data
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Yenta + sata_sil + 2.6.30.8 fails because dma_ops==NULL
Hi I have a powerbook G4 which has drives connected via a cardbus sata_sil. It is running fedora 11. It boots fine with 2.6.27.35-170.2.94.fc10.ppc, but with 2.6.30.8-64.fc11.ppc because of an error in the probe function of sata_sil. I have traced the problem to be the line in sata_sil.c function sil_init_one rc = pci_set_dma_mask(pdev, ATA_DMA_MASK); which returns -5 (-EIO) because get_dma_ops(&pdev->dev); returns NULL. I looked at the diffs to sata_sil.c between these kernel revs and didn't see the problem. Seems to be something at a higher level changed. Any ideas where I should look or how to find the real cause? Thanks -roger P.S., on the working kernel lspci gives: 0001:11:00.0 Mass storage controller: Silicon Image, Inc. SiI 3512 [SATALink/SATARaid] Serial ATA Controller (rev 01) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
