* Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Scott Wood @ 2012-05-31 21:43 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, Dan Malek, Bob Cochran, Support
In-Reply-To: <OF3AA5925F.E17EF6A4-ONC1257A0F.0076C23F-C1257A0F.0076D836@transmode.se>
On 05/31/2012 04:38 PM, Joakim Tjernlund wrote:
> Scott Wood <scottwood@freescale.com> wrote on 2012/05/31 19:47:53:
>>
>> On 05/31/2012 04:56 AM, Joakim Tjernlund wrote:
>>> Abatron Support <support@abatron.ch> wrote on 2012/05/31 11:30:57:
>>>>
>>>>
>>>>> Abatron Support <support@abatron.ch> wrote on 2012/05/30 14:08:26:
>>>>>>
>>>>>>>> I have tested this briefly with BDI2000 on P2010(e500) and
>>>>>>>> it works for me. I don't know if there are any bad side effects,
>>>>>>>> therfore
>>>>>>>> this RFC.
>>>>>>
>>>>>>> We used to have MSR_DE surrounded by CONFIG_something
>>>>>>> to ensure it wasn't set under normal operation. IIRC, if MSR_DE
>>>>>>> is set, you will have problems with software debuggers that
>>>>>>> utilize the the debugging registers in the chip itself. You only want
>>>>>>> to force this to be set when using the BDI, not at other times.
>>>>>>
>>>>>> This MSR_DE is also of interest and used for software debuggers that
>>>>>> make use of the debug registers. Only if MSR_DE is set then debug
>>>>>> interrupts are generated. If a debug event leads to a debug interrupt
>>>>>> handled by a software debugger or if it leads to a debug halt handled
>>>>>> by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
>>>>>>
>>>>>> The "e500 Core Family Reference Manual" chapter "Chapter 8
>>>>>> Debug Support" explains in detail the effect of MSR_DE.
>>>>
>>>>> So what is the verdict on this? I don't buy into Dan argument without some
>>>>> hard data.
>>>>
>>>> What I tried to mention is that handling the MSR_DE correct is not only
>>>> an emulator (JTAG debugger) requirement. Also a software debugger may
>>>> depend on a correct handled MSR_DE bit.
>>>
>>> Yes, that made sense to me too. How would SW debuggers work if the kernel keeps
>>> turning off MSR_DE first chance it gets?
>>
>> The kernel selectively enables MSR_DE when it wants to debug. I'm not
>> sure if anything will be bothered by leaving it on all the time. This
>> is something we need for virtualization as well, so a hypervisor can
>> debug the guest.
>
> hmm, I read that as you as in favour of the patch?
I'd want some confirmation that it doesn't break anything, and that
there aren't any other places that need MSR_DE that this doesn't cover,
but in general yes.
-Scott
^ permalink raw reply
* Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Joakim Tjernlund @ 2012-05-31 22:14 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Dan Malek, Bob Cochran, Support
In-Reply-To: <4FC7E606.1070205@freescale.com>
Scott Wood <scottwood@freescale.com> wrote on 2012/05/31 23:43:34:
>
> On 05/31/2012 04:38 PM, Joakim Tjernlund wrote:
> > Scott Wood <scottwood@freescale.com> wrote on 2012/05/31 19:47:53:
> >>
> >> On 05/31/2012 04:56 AM, Joakim Tjernlund wrote:
> >>> Abatron Support <support@abatron.ch> wrote on 2012/05/31 11:30:57:
> >>>>
> >>>>
> >>>>> Abatron Support <support@abatron.ch> wrote on 2012/05/30 14:08:26:
> >>>>>>
> >>>>>>>> I have tested this briefly with BDI2000 on P2010(e500) and
> >>>>>>>> it works for me. I don't know if there are any bad side effects,
> >>>>>>>> therfore
> >>>>>>>> this RFC.
> >>>>>>
> >>>>>>> We used to have MSR_DE surrounded by CONFIG_something
> >>>>>>> to ensure it wasn't set under normal operation. IIRC, if MSR_DE
> >>>>>>> is set, you will have problems with software debuggers that
> >>>>>>> utilize the the debugging registers in the chip itself. You only want
> >>>>>>> to force this to be set when using the BDI, not at other times.
> >>>>>>
> >>>>>> This MSR_DE is also of interest and used for software debuggers that
> >>>>>> make use of the debug registers. Only if MSR_DE is set then debug
> >>>>>> interrupts are generated. If a debug event leads to a debug interrupt
> >>>>>> handled by a software debugger or if it leads to a debug halt handled
> >>>>>> by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
> >>>>>>
> >>>>>> The "e500 Core Family Reference Manual" chapter "Chapter 8
> >>>>>> Debug Support" explains in detail the effect of MSR_DE.
> >>>>
> >>>>> So what is the verdict on this? I don't buy into Dan argument without some
> >>>>> hard data.
> >>>>
> >>>> What I tried to mention is that handling the MSR_DE correct is not only
> >>>> an emulator (JTAG debugger) requirement. Also a software debugger may
> >>>> depend on a correct handled MSR_DE bit.
> >>>
> >>> Yes, that made sense to me too. How would SW debuggers work if the kernel keeps
> >>> turning off MSR_DE first chance it gets?
> >>
> >> The kernel selectively enables MSR_DE when it wants to debug. I'm not
> >> sure if anything will be bothered by leaving it on all the time. This
> >> is something we need for virtualization as well, so a hypervisor can
> >> debug the guest.
> >
> > hmm, I read that as you as in favour of the patch?
>
> I'd want some confirmation that it doesn't break anything, and that
> there aren't any other places that need MSR_DE that this doesn't cover,
> but in general yes.
Then you need to test drive the patch :)
Jocke
^ permalink raw reply
* Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Scott Wood @ 2012-05-31 22:16 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, Dan Malek, Bob Cochran, Support
In-Reply-To: <OF43D61D1E.31CC8410-ONC1257A0F.0079F3A4-C1257A0F.007A237A@transmode.se>
On 05/31/2012 05:14 PM, Joakim Tjernlund wrote:
> Scott Wood <scottwood@freescale.com> wrote on 2012/05/31 23:43:34:
>>
>> On 05/31/2012 04:38 PM, Joakim Tjernlund wrote:
>>> Scott Wood <scottwood@freescale.com> wrote on 2012/05/31 19:47:53:
>>>>
>>>> On 05/31/2012 04:56 AM, Joakim Tjernlund wrote:
>>>>> Abatron Support <support@abatron.ch> wrote on 2012/05/31 11:30:57:
>>>>>>
>>>>>>
>>>>>>> Abatron Support <support@abatron.ch> wrote on 2012/05/30 14:08:26:
>>>>>>>>
>>>>>>>>>> I have tested this briefly with BDI2000 on P2010(e500) and
>>>>>>>>>> it works for me. I don't know if there are any bad side effects,
>>>>>>>>>> therfore
>>>>>>>>>> this RFC.
>>>>>>>>
>>>>>>>>> We used to have MSR_DE surrounded by CONFIG_something
>>>>>>>>> to ensure it wasn't set under normal operation. IIRC, if MSR_DE
>>>>>>>>> is set, you will have problems with software debuggers that
>>>>>>>>> utilize the the debugging registers in the chip itself. You only want
>>>>>>>>> to force this to be set when using the BDI, not at other times.
>>>>>>>>
>>>>>>>> This MSR_DE is also of interest and used for software debuggers that
>>>>>>>> make use of the debug registers. Only if MSR_DE is set then debug
>>>>>>>> interrupts are generated. If a debug event leads to a debug interrupt
>>>>>>>> handled by a software debugger or if it leads to a debug halt handled
>>>>>>>> by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
>>>>>>>>
>>>>>>>> The "e500 Core Family Reference Manual" chapter "Chapter 8
>>>>>>>> Debug Support" explains in detail the effect of MSR_DE.
>>>>>>
>>>>>>> So what is the verdict on this? I don't buy into Dan argument without some
>>>>>>> hard data.
>>>>>>
>>>>>> What I tried to mention is that handling the MSR_DE correct is not only
>>>>>> an emulator (JTAG debugger) requirement. Also a software debugger may
>>>>>> depend on a correct handled MSR_DE bit.
>>>>>
>>>>> Yes, that made sense to me too. How would SW debuggers work if the kernel keeps
>>>>> turning off MSR_DE first chance it gets?
>>>>
>>>> The kernel selectively enables MSR_DE when it wants to debug. I'm not
>>>> sure if anything will be bothered by leaving it on all the time. This
>>>> is something we need for virtualization as well, so a hypervisor can
>>>> debug the guest.
>>>
>>> hmm, I read that as you as in favour of the patch?
>>
>> I'd want some confirmation that it doesn't break anything, and that
>> there aren't any other places that need MSR_DE that this doesn't cover,
>> but in general yes.
>
> Then you need to test drive the patch :)
I was thinking more along the lines of someone who's more familiar with
the relevant parts of the code confirming that it's really OK, not just
testing that it doesn't blow up in my face.
-Scott
^ permalink raw reply
* Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Joakim Tjernlund @ 2012-05-31 22:33 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Dan Malek, Bob Cochran, Support
In-Reply-To: <4FC7EDD5.8090302@freescale.com>
Scott Wood <scottwood@freescale.com> wrote on 2012/06/01 00:16:53:
>
> On 05/31/2012 05:14 PM, Joakim Tjernlund wrote:
> > Scott Wood <scottwood@freescale.com> wrote on 2012/05/31 23:43:34:
> >>
> >> On 05/31/2012 04:38 PM, Joakim Tjernlund wrote:
> >>> Scott Wood <scottwood@freescale.com> wrote on 2012/05/31 19:47:53:
> >>>>
> >>>> On 05/31/2012 04:56 AM, Joakim Tjernlund wrote:
> >>>>> Abatron Support <support@abatron.ch> wrote on 2012/05/31 11:30:57:
> >>>>>>
> >>>>>>
> >>>>>>> Abatron Support <support@abatron.ch> wrote on 2012/05/30 14:08:26:
> >>>>>>>>
> >>>>>>>>>> I have tested this briefly with BDI2000 on P2010(e500) and
> >>>>>>>>>> it works for me. I don't know if there are any bad side effects,
> >>>>>>>>>> therfore
> >>>>>>>>>> this RFC.
> >>>>>>>>
> >>>>>>>>> We used to have MSR_DE surrounded by CONFIG_something
> >>>>>>>>> to ensure it wasn't set under normal operation. IIRC, if MSR_DE
> >>>>>>>>> is set, you will have problems with software debuggers that
> >>>>>>>>> utilize the the debugging registers in the chip itself. You only want
> >>>>>>>>> to force this to be set when using the BDI, not at other times.
> >>>>>>>>
> >>>>>>>> This MSR_DE is also of interest and used for software debuggers that
> >>>>>>>> make use of the debug registers. Only if MSR_DE is set then debug
> >>>>>>>> interrupts are generated. If a debug event leads to a debug interrupt
> >>>>>>>> handled by a software debugger or if it leads to a debug halt handled
> >>>>>>>> by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
> >>>>>>>>
> >>>>>>>> The "e500 Core Family Reference Manual" chapter "Chapter 8
> >>>>>>>> Debug Support" explains in detail the effect of MSR_DE.
> >>>>>>
> >>>>>>> So what is the verdict on this? I don't buy into Dan argument without some
> >>>>>>> hard data.
> >>>>>>
> >>>>>> What I tried to mention is that handling the MSR_DE correct is not only
> >>>>>> an emulator (JTAG debugger) requirement. Also a software debugger may
> >>>>>> depend on a correct handled MSR_DE bit.
> >>>>>
> >>>>> Yes, that made sense to me too. How would SW debuggers work if the kernel keeps
> >>>>> turning off MSR_DE first chance it gets?
> >>>>
> >>>> The kernel selectively enables MSR_DE when it wants to debug. I'm not
> >>>> sure if anything will be bothered by leaving it on all the time. This
> >>>> is something we need for virtualization as well, so a hypervisor can
> >>>> debug the guest.
> >>>
> >>> hmm, I read that as you as in favour of the patch?
> >>
> >> I'd want some confirmation that it doesn't break anything, and that
> >> there aren't any other places that need MSR_DE that this doesn't cover,
> >> but in general yes.
> >
> > Then you need to test drive the patch :)
>
> I was thinking more along the lines of someone who's more familiar with
> the relevant parts of the code confirming that it's really OK, not just
> testing that it doesn't blow up in my face.
Still needs a test run, just throw it in :)
^ permalink raw reply
* Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Joakim Tjernlund @ 2012-05-31 22:35 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Dan Malek, Bob Cochran, Support
In-Reply-To: <4FC7EDD5.8090302@freescale.com>
Scott Wood <scottwood@freescale.com> wrote on 2012/06/01 00:16:53:
>
> On 05/31/2012 05:14 PM, Joakim Tjernlund wrote:
> > Scott Wood <scottwood@freescale.com> wrote on 2012/05/31 23:43:34:
> >>
> >> On 05/31/2012 04:38 PM, Joakim Tjernlund wrote:
> >>> Scott Wood <scottwood@freescale.com> wrote on 2012/05/31 19:47:53:
> >>>>
> >>>> On 05/31/2012 04:56 AM, Joakim Tjernlund wrote:
> >>>>> Abatron Support <support@abatron.ch> wrote on 2012/05/31 11:30:57:
> >>>>>>
> >>>>>>
> >>>>>>> Abatron Support <support@abatron.ch> wrote on 2012/05/30 14:08:26:
> >>>>>>>>
> >>>>>>>>>> I have tested this briefly with BDI2000 on P2010(e500) and
> >>>>>>>>>> it works for me. I don't know if there are any bad side effects,
> >>>>>>>>>> therfore
> >>>>>>>>>> this RFC.
> >>>>>>>>
> >>>>>>>>> We used to have MSR_DE surrounded by CONFIG_something
> >>>>>>>>> to ensure it wasn't set under normal operation. IIRC, if MSR_DE
> >>>>>>>>> is set, you will have problems with software debuggers that
> >>>>>>>>> utilize the the debugging registers in the chip itself. You only want
> >>>>>>>>> to force this to be set when using the BDI, not at other times.
> >>>>>>>>
> >>>>>>>> This MSR_DE is also of interest and used for software debuggers that
> >>>>>>>> make use of the debug registers. Only if MSR_DE is set then debug
> >>>>>>>> interrupts are generated. If a debug event leads to a debug interrupt
> >>>>>>>> handled by a software debugger or if it leads to a debug halt handled
> >>>>>>>> by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
> >>>>>>>>
> >>>>>>>> The "e500 Core Family Reference Manual" chapter "Chapter 8
> >>>>>>>> Debug Support" explains in detail the effect of MSR_DE.
> >>>>>>
> >>>>>>> So what is the verdict on this? I don't buy into Dan argument without some
> >>>>>>> hard data.
> >>>>>>
> >>>>>> What I tried to mention is that handling the MSR_DE correct is not only
> >>>>>> an emulator (JTAG debugger) requirement. Also a software debugger may
> >>>>>> depend on a correct handled MSR_DE bit.
> >>>>>
> >>>>> Yes, that made sense to me too. How would SW debuggers work if the kernel keeps
> >>>>> turning off MSR_DE first chance it gets?
> >>>>
> >>>> The kernel selectively enables MSR_DE when it wants to debug. I'm not
> >>>> sure if anything will be bothered by leaving it on all the time. This
> >>>> is something we need for virtualization as well, so a hypervisor can
> >>>> debug the guest.
> >>>
> >>> hmm, I read that as you as in favour of the patch?
> >>
> >> I'd want some confirmation that it doesn't break anything, and that
> >> there aren't any other places that need MSR_DE that this doesn't cover,
> >> but in general yes.
> >
> > Then you need to test drive the patch :)
>
> I was thinking more along the lines of someone who's more familiar with
> the relevant parts of the code confirming that it's really OK, not just
> testing that it doesn't blow up in my face.
It just occurred to me that you guys have this already in your Linux SDK so it can't be that bad.
Jocke
^ permalink raw reply
* Re: [PATCH] powerpc/pci: cleanup on duplicate assignment
From: Richard Yang @ 2012-06-01 1:25 UTC (permalink / raw)
To: Gavin Shan; +Cc: michael, linuxppc-dev
In-Reply-To: <1338445049-20520-1-git-send-email-shangw@linux.vnet.ibm.com>
Agree, this is a duplication.
On Thu, May 31, 2012 at 02:17:29PM +0800, Gavin Shan wrote:
>While creating the PCI root bus through function pci_create_root_bus()
>of PCI core, it should have assigned the secondary bus number for the
>newly created PCI root bus. Thus we needn't do the explicit assignment
>for the secondary bus number again in pcibios_scan_phb().
>
>Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
>---
> arch/powerpc/kernel/pci-common.c | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
>index 8e78e93..0f75bd5 100644
>--- a/arch/powerpc/kernel/pci-common.c
>+++ b/arch/powerpc/kernel/pci-common.c
>@@ -1646,7 +1646,6 @@ void __devinit pcibios_scan_phb(struct pci_controller *hose)
> pci_free_resource_list(&resources);
> return;
> }
>- bus->secondary = hose->first_busno;
> hose->bus = bus;
>
> /* Get probe mode and perform scan */
>--
>1.7.9.5
>
>_______________________________________________
>Linuxppc-dev mailing list
>Linuxppc-dev@lists.ozlabs.org
>https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Richard Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH 5/9] blackfin: A couple of task->mm handling fixes
From: Mike Frysinger @ 2012-06-01 4:36 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linaro-kernel, Russell King, Peter Zijlstra,
user-mode-linux-devel, linux-sh, patches, Oleg Nesterov,
linux-kernel, linux-mm, Paul Mundt, John Stultz, KOSAKI Motohiro,
Richard Weinberger, uclinux-dist-devel, Andrew Morton,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20120423070901.GE30752@lizard>
[-- Attachment #1: Type: Text/Plain, Size: 1106 bytes --]
On Monday 23 April 2012 03:09:01 Anton Vorontsov wrote:
> 1. Working with task->mm w/o getting mm or grabing the task lock is
> dangerous as ->mm might disappear (exit_mm() assigns NULL under
> task_lock(), so tasklist lock is not enough).
that isn't a problem for this code as it specifically checks if it's in an
atomic section. if it is, then task->mm can't go away on us.
> We can't use get_task_mm()/mmput() pair as mmput() might sleep,
> so we have to take the task lock while handle its mm.
if we're not in an atomic section, then sleeping is fine.
> 2. Checking for process->mm is not enough because process' main
> thread may exit or detach its mm via use_mm(), but other threads
> may still have a valid mm.
i don't think it matters for this code (per the reasons above).
> To catch this we use find_lock_task_mm(), which walks up all
> threads and returns an appropriate task (with task lock held).
certainly fine for the non-atomic code path. i guess we'll notice in crashes
if it causes a problem in atomic code paths as well.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: boot failuresfor next-20120601
From: Stephen Rothwell @ 2012-06-01 6:59 UTC (permalink / raw)
To: linux-next; +Cc: ppc-dev, LKML
[-- Attachment #1: Type: text/plain, Size: 3296 bytes --]
Hi all,
Today's linux-next fails to boot on my PowerPC boxes like this (one
example):
calling .ipr_init+0x0/0x68 @ 1
ipr: IBM Power RAID SCSI Device Driver version: 2.5.3 (March 10, 2012)
ipr 0000:01:01.0: Found IOA with IRQ: 26
ipr 0000:01:01.0: Starting IOA initialization sequence.
ipr 0000:01:01.0: Adapter firmware version: 06160039
ipr 0000:01:01.0: IOA initialized.
scsi0 : IBM 572E Storage Adapter
async_waiting @ 1
async_continuing @ 1 after 0 usec
scsi 0:0:1:0: Direct-Access IBM-ESXS MAY2036RC T106 PQ: 0 ANSI: 5
async_waiting @ 1
async_continuing @ 1 after 0 usec
async_waiting @ 1
async_continuing @ 1 after 0 usec
.
. (lots and lots of these)
.
async_waiting @ 1
async_continuing @ 1 after 0 usec
scsi: unknown device type 31
scsi 0:255:255:255: No Device IBM 572E001 0150 PQ: 0 ANSI: 0
initcall .ipr_init+0x0/0x68 returned 0 after 967815 usecs
.
.
.
initcall 1_.sd_probe_async+0x0/0x1d0 returned 0 after 220331 usecs
INFO: rcu_sched self-detected stall on CPU { 2} (t=6001 jiffies)
Call Trace:
[c00000007897b2a0] [c000000000013b40] .show_stack+0x70/0x1c0 (unreliable)
[c00000007897b350] [c00000000012937c] .__rcu_pending+0x20c/0x580
[c00000007897b410] [c000000000129844] .rcu_check_callbacks+0x154/0x250
[c00000007897b4b0] [c0000000000b1e64] .update_process_times+0x44/0xa0
[c00000007897b540] [c0000000000fbc6c] .tick_sched_timer+0x7c/0x100
[c00000007897b5e0] [c0000000000cee88] .__run_hrtimer+0xb8/0x270
[c00000007897b690] [c0000000000cf3a8] .hrtimer_interrupt+0x128/0x2c0
[c00000007897b7a0] [c00000000001cc98] .timer_interrupt+0x108/0x290
[c00000007897b850] [c000000000003b80] decrementer_common+0x180/0x200
--- Exception: 901 at .arch_local_irq_restore+0x74/0x90
LR = .arch_local_irq_restore+0x74/0x90
[c00000007897bb40] [c000000000010108] .arch_local_irq_restore+0x38/0x90 (unreliable)
[c00000007897bbb0] [c00000000009de30] .console_unlock+0x370/0x460
[c00000007897bca0] [c00000000041c1ec] .fb_flashcursor+0x7c/0x180
[c00000007897bd50] [c0000000000c30ec] .process_one_work+0x19c/0x590
[c00000007897be10] [c0000000000c3a48] .worker_thread+0x188/0x4b0
[c00000007897bed0] [c0000000000c9cdc] .kthread+0xbc/0xd0
[c00000007897bf90] [c000000000020eb8] .kernel_thread+0x54/0x70
.
.
.
calling .initialize_hashrnd+0x0/0x40 @ 1
initcall .initialize_hashrnd+0x0/0x40 returned 0 after 1 usecs
async_waiting @ 1
async_continuing @ 1 after 0 usec
Freeing unused kernel memory: 468k freed
/init: 71: mknod: Permission denied
/init: 88: mknod: Permission denied
/init: 88: mknod: Permission denied
/init: 88: mknod: Permission denied
/init: 88: mknod: Permission denied
/init: 99: cannot open /proc/cmdline: No such file
/init: 103: mkdir: Permission denied
/init: 104: mkdir: Permission denied
/init: 108: udevadm: Permission denied
dracut: FATAL: No or empty root= argument
dracut: Refusing to continue
Signal caught!
Boot has failed, sleeping forever.
/init: 1: sleep: Permission denied
/init: 1: sleep: Permission denied
/init: 1: sleep: Permission denied
.
.
.
Another machine did not use the ipr device and only got the init problems
at the end.
Anyone got any ideas?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Re[2]: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Benjamin Herrenschmidt @ 2012-06-01 9:12 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, Dan Malek, Bob Cochran, Support
In-Reply-To: <OF53CDE18C.59DD377E-ONC1257A0F.0031C7A0-C1257A0F.0031EA81@transmode.se>
On Thu, 2012-05-31 at 11:05 +0200, Joakim Tjernlund wrote:
> Abatron Support <support@abatron.ch> wrote on 2012/05/30 14:08:26:
> >
> > >> I have tested this briefly with BDI2000 on P2010(e500) and
> > >> it works for me. I don't know if there are any bad side effects,
> > >> therfore
> > >> this RFC.
> >
> > > We used to have MSR_DE surrounded by CONFIG_something
> > > to ensure it wasn't set under normal operation. IIRC, if MSR_DE
> > > is set, you will have problems with software debuggers that
> > > utilize the the debugging registers in the chip itself. You only want
> > > to force this to be set when using the BDI, not at other times.
> >
> > This MSR_DE is also of interest and used for software debuggers that
> > make use of the debug registers. Only if MSR_DE is set then debug
> > interrupts are generated. If a debug event leads to a debug interrupt
> > handled by a software debugger or if it leads to a debug halt handled
> > by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
> >
> > The "e500 Core Family Reference Manual" chapter "Chapter 8
> > Debug Support" explains in detail the effect of MSR_DE.
>
> So what is the verdict on this? I don't buy into Dan argument without some
> hard data.
The kernel normally controls when to set or not set MSR:DE, at least
when using SW breakpoints. Setting it globally should remain some kind
of specific debug option.
In fact on some CPUs, we even leave user set dbcr settings and rely on
DE being off in kernel space to avoid user->kernel attacks via the debug
registers (I think we still do that on 64-bit BookE though it should
eventually change).
Cheers,
Ben.
> Jocke
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Benjamin Herrenschmidt @ 2012-06-01 9:14 UTC (permalink / raw)
To: Bob Cochran; +Cc: linuxppc-dev, support
In-Reply-To: <4FC62018.3040404@mindchasers.com>
On Wed, 2012-05-30 at 09:26 -0400, Bob Cochran wrote:
> I believe that additional patches are required for CodeWarrior to
> work
> properly (e.g., assembly start up). I think the patches should come
> from Freescale. For whatever reason, they include them in their SDK,
> but haven't submitted them for inclusion in the mainline.
>
> As a developer on Freescale Power products, I would like to see
> Freescale offer up a CodeWarrior patch set, so I don't have to manage
> the patches myself when working outside the SDK (i.e., on a more
> recent
> kernel).
Such patches would have a hard time getting upstream considering that
codewarrior is a commercial product.
Ben.
^ permalink raw reply
* Re: kernel panic during kernel module load (powerpc specific part)
From: Benjamin Herrenschmidt @ 2012-06-01 9:18 UTC (permalink / raw)
To: Gabriel Paubert
Cc: Wrobel Heinz-R39252, Michael Ellerman, Steffen Rumler,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20120531110439.GA17373@visitor2.iram.es>
On Thu, 2012-05-31 at 13:04 +0200, Gabriel Paubert wrote:
> I believe that the basic premise is that you should provide a directly reachable copy
> of the save/rstore functions, even if this means that you need several copies of the functions.
I just fixed a very similar problem with grub2 in fact. It was using r0
and trashing the saved LR that way.
The real fix is indeed to statically link those gcc "helpers", we
shouldn't generate things like cross-module calls inside function
prologs and epilogues, when stackframes aren't even guaranteed to be
reliable.
However, in the grub2 case, it was easier to just use r12 :-)
Cheers,
Ben.
> >
> > Unfortunately the same doc and predecessors show r11 in all basic examples for PLT/trampoline code AFAICS, which is likely why all trampoline code uses r11 in any known case.
> >
> > I would guess that it was never envisioned that compiler generated code would be in a different section than save/restore functions, i.e., the Linux module "__init" assumptions for Power break the ABI. Or does the ABI break the __init concept?!
> >
> > Using r12 in the trampoline seems to be the obvious solution for module loading.
> >
> > But what about other code loading done? If, e.g., a user runs any app from bash it gets loaded and relocated and trampolines might get set up somehow.
>
> I don't think so. The linker/whatever should generate a copy of the save/restore functions for every
> executable code area (shared library), and probably more than one copy if the text becomes too large.
>
> For 64 bit code, these functions are actually inserted by the linker.
>
> [Ok, I just recompiled my 64 bit kernel with -Os and I see that vmlinux gets one copy
> of the save/restore functions and every module also gets its copy.]
>
> This makes sense, really these functions are there for a compromise between locality
> and performance, there should be one per code section, otherwise the cache line
> used by the trampoline negates a large part of their advantage.
>
> >
> > Wouldn't we have to find fix ANY trampoline code generator remotely related to a basic Power Architecture Linux?
> > Or is it a basic assumption for anything but modules that compiler generated code may never ever be outside the .text section? I am not sure that would be a safe assumption.
> >
> > Isn't this problem going beyond just module loading for Power Architecture Linux?
>
> I don't think so. It really seems to be a 32 bit kernel problem.
>
> Regards,
> Gabriel
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH 18/27] powerpc, smpboot: Use generic SMP booting infrastructure
From: Srivatsa S. Bhat @ 2012-06-01 9:14 UTC (permalink / raw)
To: tglx, peterz, paulmck
Cc: linux-arch, Thomas Gleixner, Nikunj A. Dadhania, Paul Gortmaker,
rusty, vatsa, linux-kernel, rjw, Yong Zhang, Paul Mackerras,
srivatsa.bhat, akpm, linuxppc-dev, mingo
In-Reply-To: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
From: Nikunj A. Dadhania <nikunj@linux.vnet.ibm.com>
Convert powerpc to use the generic framework to boot secondary CPUs.
Signed-off-by: Nikunj A. Dadhania <nikunj@linux.vnet.ibm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yong Zhang <yong.zhang0@gmail.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
arch/powerpc/kernel/smp.c | 26 +++++++++++++++-----------
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 1928058a..96c3718 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -544,16 +544,18 @@ static struct device_node *cpu_to_l2cache(int cpu)
/* Activate a secondary processor. */
void __devinit start_secondary(void *unused)
{
+ smpboot_start_secondary(unused);
+}
+
+void __cpuinit __cpu_pre_starting(void *unused)
+{
unsigned int cpu = smp_processor_id();
- struct device_node *l2_cache;
- int i, base;
atomic_inc(&init_mm.mm_count);
current->active_mm = &init_mm;
smp_store_cpu_info(cpu);
set_dec(tb_ticks_per_jiffy);
- preempt_disable();
cpu_callin_map[cpu] = 1;
if (smp_ops->setup_cpu)
@@ -567,8 +569,16 @@ void __devinit start_secondary(void *unused)
if (system_state == SYSTEM_RUNNING)
vdso_data->processorCount++;
#endif
- notify_cpu_starting(cpu);
- set_cpu_online(cpu, true);
+}
+
+void __cpuinit __cpu_post_online(void *unused)
+{
+ unsigned int cpu;
+ struct device_node *l2_cache;
+ int i, base;
+
+ cpu = smp_processor_id();
+
/* Update sibling maps */
base = cpu_first_thread_sibling(cpu);
for (i = 0; i < threads_per_core; i++) {
@@ -596,12 +606,6 @@ void __devinit start_secondary(void *unused)
of_node_put(np);
}
of_node_put(l2_cache);
-
- local_irq_enable();
-
- cpu_idle();
-
- BUG();
}
int setup_profiling_timer(unsigned int multiplier)
^ permalink raw reply related
* [PATCH] powerpc/time: Sanity check of decrementer expiration is necessary
From: Paul Mackerras @ 2012-06-01 10:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Anton Blanchard
This reverts 68568add2c ("powerpc/time: Remove unnecessary sanity check
of decrementer expiration"). We do need to check whether we have reached
the expiration time of the next event, because we sometimes get an early
decrementer interrupt, most notably when we set the decrementer to 1 in
arch_irq_work_raise(). The effect of not having the sanity check is that
if timer_interrupt() gets called early, we leave the decrementer set to
its maximum value, which means we then don't get any more decrementer
interrupts for about 4 seconds (or longer, depending on timebase
frequency). I saw these pauses as a consequence of getting a stray
hypervisor decrementer interrupt left over from exiting a KVM guest.
This isn't quite a straight revert because of changes to the surrounding
code, but it restores the same algorithm as was previously used.
Cc: stable@kernel.org
Cc: Anton Blanchard <anton@samba.org>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
If there are no objections, I'll send this to Linus shortly. This
regression is present in 3.3 and 3.4 as well as current upstream.
arch/powerpc/kernel/time.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 99a995c..be171ee 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -475,6 +475,7 @@ void timer_interrupt(struct pt_regs * regs)
struct pt_regs *old_regs;
u64 *next_tb = &__get_cpu_var(decrementers_next_tb);
struct clock_event_device *evt = &__get_cpu_var(decrementers);
+ u64 now;
/* Ensure a positive value is written to the decrementer, or else
* some CPUs will continue to take decrementer exceptions.
@@ -509,9 +510,16 @@ void timer_interrupt(struct pt_regs * regs)
irq_work_run();
}
- *next_tb = ~(u64)0;
- if (evt->event_handler)
- evt->event_handler(evt);
+ now = get_tb_or_rtc();
+ if (now >= *next_tb) {
+ *next_tb = ~(u64)0;
+ if (evt->event_handler)
+ evt->event_handler(evt);
+ } else {
+ now = *next_tb - now;
+ if (now <= DECREMENTER_MAX)
+ set_dec((int)now);
+ }
#ifdef CONFIG_PPC64
/* collect purr register values often, for accurate calculations */
--
1.7.10
^ permalink raw reply related
* power management patch set for mpc85xx
From: Zhao Chenhui-B35336 @ 2012-06-01 10:29 UTC (permalink / raw)
To: benh@kernel.crashing.org, paulus@samba.org
Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
Hi Ben and Paul,
I am sorry to trouble you. It seems that Kumar is busy recently.
Could you have a review on the following patches? These patches
implement the power management support on MPC85xx platform.
http://patchwork.ozlabs.org/patch/158484/
http://patchwork.ozlabs.org/patch/158485/
http://patchwork.ozlabs.org/patch/158487/
http://patchwork.ozlabs.org/patch/158486/
http://patchwork.ozlabs.org/patch/158488/
Thanks.
Best Regards,
Chenhui
^ permalink raw reply
* Re: Re[2]: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Joakim Tjernlund @ 2012-06-01 10:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Dan Malek, Bob Cochran, Support
In-Reply-To: <1338541971.16119.47.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 2012/06/01 11:12:51:
>
> On Thu, 2012-05-31 at 11:05 +0200, Joakim Tjernlund wrote:
> > Abatron Support <support@abatron.ch> wrote on 2012/05/30 14:08:26:
> > >
> > > >> I have tested this briefly with BDI2000 on P2010(e500) and
> > > >> it works for me. I don't know if there are any bad side effects,
> > > >> therfore
> > > >> this RFC.
> > >
> > > > We used to have MSR_DE surrounded by CONFIG_something
> > > > to ensure it wasn't set under normal operation. IIRC, if MSR_DE
> > > > is set, you will have problems with software debuggers that
> > > > utilize the the debugging registers in the chip itself. You only want
> > > > to force this to be set when using the BDI, not at other times.
> > >
> > > This MSR_DE is also of interest and used for software debuggers that
> > > make use of the debug registers. Only if MSR_DE is set then debug
> > > interrupts are generated. If a debug event leads to a debug interrupt
> > > handled by a software debugger or if it leads to a debug halt handled
> > > by a JTAG tool is selected with DBCR0_EDM / DBCR0_IDM.
> > >
> > > The "e500 Core Family Reference Manual" chapter "Chapter 8
> > > Debug Support" explains in detail the effect of MSR_DE.
> >
> > So what is the verdict on this? I don't buy into Dan argument without some
> > hard data.
>
> The kernel normally controls when to set or not set MSR:DE, at least
> when using SW breakpoints. Setting it globally should remain some kind
> of specific debug option.
>
> In fact on some CPUs, we even leave user set dbcr settings and rely on
> DE being off in kernel space to avoid user->kernel attacks via the debug
> registers (I think we still do that on 64-bit BookE though it should
> eventually change).
hmm, would it not be better to always clear out/control dbcr settings and always have MSR:DE
on? It would be much easier to control dbcr, even dynamically, than MSR:DE
Jocke
^ permalink raw reply
* [PATCH 03/27] smpboot: Define and use cpu_state per-cpu variable in generic code
From: Srivatsa S. Bhat @ 2012-06-01 9:10 UTC (permalink / raw)
To: tglx, peterz, paulmck
Cc: Venkatesh Pallipadi, Jeremy Fitzhardinge, linux-ia64, linux-mips,
linux-kernel, H. Peter Anvin, mingo, linux-arch, xen-devel,
Suresh Siddha, linux-sh, x86, Ingo Molnar, Fenghua Yu,
Mike Frysinger, Peter Zijlstra, nikunj, Konrad Rzeszutek Wilk,
rusty, Chris Metcalf, rjw, Yong Zhang, Thomas Gleixner,
virtualization, Tony Luck, vatsa, Ralf Baechle, Paul Mundt,
srivatsa.bhat, Andrew Morton, linuxppc-dev
In-Reply-To: <20120601090952.31979.24799.stgit@srivatsabhat.in.ibm.com>
The per-cpu variable cpu_state is used in x86 and also used in other
architectures, to track the state of the cpu during bringup and hotplug.
Pull it out into generic code.
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Yong Zhang <yong.zhang0@gmail.com>
Cc: Venkatesh Pallipadi <venki@google.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: linux-ia64@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-sh@vger.kernel.org
Cc: xen-devel@lists.xensource.com
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
---
arch/ia64/include/asm/cpu.h | 2 --
arch/ia64/kernel/process.c | 1 +
arch/ia64/kernel/smpboot.c | 6 +-----
arch/mips/cavium-octeon/smp.c | 4 +---
arch/powerpc/kernel/smp.c | 6 +-----
arch/sh/include/asm/smp.h | 2 --
arch/sh/kernel/smp.c | 4 +---
arch/tile/kernel/smpboot.c | 4 +---
arch/x86/include/asm/cpu.h | 2 --
arch/x86/kernel/smpboot.c | 4 +---
arch/x86/xen/smp.c | 1 +
include/linux/smpboot.h | 1 +
kernel/smpboot.c | 4 ++++
13 files changed, 13 insertions(+), 28 deletions(-)
diff --git a/arch/ia64/include/asm/cpu.h b/arch/ia64/include/asm/cpu.h
index fcca30b..1c3acac 100644
--- a/arch/ia64/include/asm/cpu.h
+++ b/arch/ia64/include/asm/cpu.h
@@ -12,8 +12,6 @@ struct ia64_cpu {
DECLARE_PER_CPU(struct ia64_cpu, cpu_devices);
-DECLARE_PER_CPU(int, cpu_state);
-
#ifdef CONFIG_HOTPLUG_CPU
extern int arch_register_cpu(int num);
extern void arch_unregister_cpu(int);
diff --git a/arch/ia64/kernel/process.c b/arch/ia64/kernel/process.c
index 5e0e86d..32566c7 100644
--- a/arch/ia64/kernel/process.c
+++ b/arch/ia64/kernel/process.c
@@ -29,6 +29,7 @@
#include <linux/kdebug.h>
#include <linux/utsname.h>
#include <linux/tracehook.h>
+#include <linux/smpboot.h>
#include <asm/cpu.h>
#include <asm/delay.h>
diff --git a/arch/ia64/kernel/smpboot.c b/arch/ia64/kernel/smpboot.c
index 963d2db..df00a3c 100644
--- a/arch/ia64/kernel/smpboot.c
+++ b/arch/ia64/kernel/smpboot.c
@@ -39,6 +39,7 @@
#include <linux/efi.h>
#include <linux/percpu.h>
#include <linux/bitops.h>
+#include <linux/smpboot.h>
#include <linux/atomic.h>
#include <asm/cache.h>
@@ -111,11 +112,6 @@ extern unsigned long ia64_iobase;
struct task_struct *task_for_booting_cpu;
-/*
- * State for each CPU
- */
-DEFINE_PER_CPU(int, cpu_state);
-
cpumask_t cpu_core_map[NR_CPUS] __cacheline_aligned;
EXPORT_SYMBOL(cpu_core_map);
DEFINE_PER_CPU_SHARED_ALIGNED(cpumask_t, cpu_sibling_map);
diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c
index 97e7ce9..93cd4b0 100644
--- a/arch/mips/cavium-octeon/smp.c
+++ b/arch/mips/cavium-octeon/smp.c
@@ -13,6 +13,7 @@
#include <linux/kernel_stat.h>
#include <linux/sched.h>
#include <linux/module.h>
+#include <linux/smpboot.h>
#include <asm/mmu_context.h>
#include <asm/time.h>
@@ -252,9 +253,6 @@ static void octeon_cpus_done(void)
#ifdef CONFIG_HOTPLUG_CPU
-/* State of each CPU. */
-DEFINE_PER_CPU(int, cpu_state);
-
extern void fixup_irqs(void);
static DEFINE_SPINLOCK(smp_reserve_lock);
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index e1417c4..1928058a 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -31,6 +31,7 @@
#include <linux/cpu.h>
#include <linux/notifier.h>
#include <linux/topology.h>
+#include <linux/smpboot.h>
#include <asm/ptrace.h>
#include <linux/atomic.h>
@@ -57,11 +58,6 @@
#define DBG(fmt...)
#endif
-#ifdef CONFIG_HOTPLUG_CPU
-/* State of each CPU during hotplug phases */
-static DEFINE_PER_CPU(int, cpu_state) = { 0 };
-#endif
-
struct thread_info *secondary_ti;
DEFINE_PER_CPU(cpumask_var_t, cpu_sibling_map);
diff --git a/arch/sh/include/asm/smp.h b/arch/sh/include/asm/smp.h
index 78b0d0f4..bda041e 100644
--- a/arch/sh/include/asm/smp.h
+++ b/arch/sh/include/asm/smp.h
@@ -31,8 +31,6 @@ enum {
SMP_MSG_NR, /* must be last */
};
-DECLARE_PER_CPU(int, cpu_state);
-
void smp_message_recv(unsigned int msg);
void smp_timer_broadcast(const struct cpumask *mask);
diff --git a/arch/sh/kernel/smp.c b/arch/sh/kernel/smp.c
index b86e9ca..8e0fde0 100644
--- a/arch/sh/kernel/smp.c
+++ b/arch/sh/kernel/smp.c
@@ -22,6 +22,7 @@
#include <linux/interrupt.h>
#include <linux/sched.h>
#include <linux/atomic.h>
+#include <linux/smpboot.h>
#include <asm/processor.h>
#include <asm/mmu_context.h>
#include <asm/smp.h>
@@ -34,9 +35,6 @@ int __cpu_logical_map[NR_CPUS]; /* Map logical to physical */
struct plat_smp_ops *mp_ops = NULL;
-/* State of each CPU */
-DEFINE_PER_CPU(int, cpu_state) = { 0 };
-
void __cpuinit register_smp_ops(struct plat_smp_ops *ops)
{
if (mp_ops)
diff --git a/arch/tile/kernel/smpboot.c b/arch/tile/kernel/smpboot.c
index e686c5a..24a9c06 100644
--- a/arch/tile/kernel/smpboot.c
+++ b/arch/tile/kernel/smpboot.c
@@ -25,13 +25,11 @@
#include <linux/delay.h>
#include <linux/err.h>
#include <linux/irq.h>
+#include <linux/smpboot.h>
#include <asm/mmu_context.h>
#include <asm/tlbflush.h>
#include <asm/sections.h>
-/* State of each CPU. */
-static DEFINE_PER_CPU(int, cpu_state) = { 0 };
-
/* The messaging code jumps to this pointer during boot-up */
unsigned long start_cpu_function_addr;
diff --git a/arch/x86/include/asm/cpu.h b/arch/x86/include/asm/cpu.h
index 4564c8e..2d0b239 100644
--- a/arch/x86/include/asm/cpu.h
+++ b/arch/x86/include/asm/cpu.h
@@ -30,8 +30,6 @@ extern int arch_register_cpu(int num);
extern void arch_unregister_cpu(int);
#endif
-DECLARE_PER_CPU(int, cpu_state);
-
int mwait_usable(const struct cpuinfo_x86 *);
#endif /* _ASM_X86_CPU_H */
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index bfbe30e..269bc1f 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -51,6 +51,7 @@
#include <linux/stackprotector.h>
#include <linux/gfp.h>
#include <linux/cpuidle.h>
+#include <linux/smpboot.h>
#include <asm/acpi.h>
#include <asm/desc.h>
@@ -73,9 +74,6 @@
#include <asm/smpboot_hooks.h>
#include <asm/i8259.h>
-/* State of each CPU */
-DEFINE_PER_CPU(int, cpu_state) = { 0 };
-
#ifdef CONFIG_HOTPLUG_CPU
/*
* We need this for trampoline_base protection from concurrent accesses when
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 2ef5948..09a7199 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -16,6 +16,7 @@
#include <linux/err.h>
#include <linux/slab.h>
#include <linux/smp.h>
+#include <linux/smpboot.h>
#include <asm/paravirt.h>
#include <asm/desc.h>
diff --git a/include/linux/smpboot.h b/include/linux/smpboot.h
index 63bbedd..834d90c 100644
--- a/include/linux/smpboot.h
+++ b/include/linux/smpboot.h
@@ -5,6 +5,7 @@
#ifndef SMPBOOT_H
#define SMPBOOT_H
+DECLARE_PER_CPU(int, cpu_state);
extern void smpboot_start_secondary(void *arg);
#endif
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index 5ae1805..0df43b0 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -67,6 +67,8 @@ void __init idle_threads_init(void)
}
#endif
+/* State of each CPU during bringup/teardown */
+DEFINE_PER_CPU(int, cpu_state) = { 0 };
/* Implement the following functions in your architecture, as appropriate. */
@@ -141,6 +143,8 @@ void __cpuinit smpboot_start_secondary(void *arg)
set_cpu_online(cpu, true);
arch_vector_unlock();
+ per_cpu(cpu_state, cpu) = CPU_ONLINE;
+
__cpu_post_online(arg);
/* Enable local interrupts now */
^ permalink raw reply related
* Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Joakim Tjernlund @ 2012-06-01 10:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Bob Cochran, support
In-Reply-To: <1338542089.16119.48.camel@pasglop>
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 2012/06/01 11:14:49:
>
> On Wed, 2012-05-30 at 09:26 -0400, Bob Cochran wrote:
> > I believe that additional patches are required for CodeWarrior to
> > work
> > properly (e.g., assembly start up). I think the patches should come
> > from Freescale. For whatever reason, they include them in their SDK,
> > but haven't submitted them for inclusion in the mainline.
> >
> > As a developer on Freescale Power products, I would like to see
> > Freescale offer up a CodeWarrior patch set, so I don't have to manage
> > the patches myself when working outside the SDK (i.e., on a more
> > recent
> > kernel).
>
> Such patches would have a hard time getting upstream considering that
> codewarrior is a commercial product.
Naa, Abatron BDI is also a commercial product and that is in the kernel. CW
changes pretty much just add the same settings for CONFIG_CW. I think Freescale
should just rename CONFIG_BDI_SWITCH to something generic and just use the same code.
Jocke
^ permalink raw reply
* RE: kernel panic during kernel module load (powerpc specific part)
From: Wrobel Heinz-R39252 @ 2012-06-01 11:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Gabriel Paubert
Cc: Michael Ellerman, Steffen Rumler, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1338542315.16119.50.camel@pasglop>
PiA+IEkgYmVsaWV2ZSB0aGF0IHRoZSBiYXNpYyBwcmVtaXNlIGlzIHRoYXQgeW91IHNob3VsZCBw
cm92aWRlIGEgZGlyZWN0bHkNCj4gPiByZWFjaGFibGUgY29weSBvZiB0aGUgc2F2ZS9yc3RvcmUg
ZnVuY3Rpb25zLCBldmVuIGlmIHRoaXMgbWVhbnMgdGhhdA0KPiB5b3UgbmVlZCBzZXZlcmFsIGNv
cGllcyBvZiB0aGUgZnVuY3Rpb25zLg0KPiANCj4gSSBqdXN0IGZpeGVkIGEgdmVyeSBzaW1pbGFy
IHByb2JsZW0gd2l0aCBncnViMiBpbiBmYWN0LiBJdCB3YXMgdXNpbmcgcjANCj4gYW5kIHRyYXNo
aW5nIHRoZSBzYXZlZCBMUiB0aGF0IHdheS4NCj4gDQo+IFRoZSByZWFsIGZpeCBpcyBpbmRlZWQg
dG8gc3RhdGljYWxseSBsaW5rIHRob3NlIGdjYyAiaGVscGVycyIsIHdlDQo+IHNob3VsZG4ndCBn
ZW5lcmF0ZSB0aGluZ3MgbGlrZSBjcm9zcy1tb2R1bGUgY2FsbHMgaW5zaWRlIGZ1bmN0aW9uIHBy
b2xvZ3MNCj4gYW5kIGVwaWxvZ3Vlcywgd2hlbiBzdGFja2ZyYW1lcyBhcmVuJ3QgZXZlbiBndWFy
YW50ZWVkIHRvIGJlIHJlbGlhYmxlLg0KPiANCj4gSG93ZXZlciwgaW4gdGhlIGdydWIyIGNhc2Us
IGl0IHdhcyBlYXNpZXIgdG8ganVzdCB1c2UgcjEyIDotKQ0KDQpGb3Igbm90IGp1c3QgdGhlIG1v
ZHVsZSBsb2FkaW5nIGNhc2UsIEkgYmVsaWV2ZSByMTIgaXMgdGhlIG9ubHkgcmVhbCBzb2x1dGlv
biBub3cuIEkgY2hlY2tlZCBvbmUgZGVidWdnZXIgY2FwYWJsZSBvZiBkb2luZyBFTEYgZG93bmxv
YWQuIEl0IGFsc28gdXNlcyByMTIgZm9yIHRyYW1wb2xpbmUgY29kZS4gSSBhbSBndWVzc2luZyBm
b3IgdGhlIHJlYXNvbiB0aGF0IHByb21wdGVkIHRoaXMgZGlzY3Vzc2lvbi4NCg0KV2l0aG91dCBy
MTIgd2UnZCBoYXZlIHRvIGNoYW5nZSBzdGFuZGFyZCBsaWJyYXJpZXMgdG8gYXV0b21hZ2ljYWxs
eSBsaW5rIGluIGdjYyBoZWxwZXJzIGZvciBhbnkgY29uY2VpdmFibGUgbm9uLS50ZXh0IHNlY3Rp
b24sIHdoaWNoIEkgYW0gbm90IHN1cmUgaXMgZmVhc2libGUuIEhvdyB3b3VsZCB5b3Ugd3JpdGUg
c2VjdGlvbiBpbmRlcGVuZGVudCBoZWxwZXIgZnVuY3Rpb25zIHdoaWNoIGxpbmsgdG8gYW55IHNl
Y3Rpb24gbmVlZGluZyB0aGVtPyENCkFza2luZyB1c2VycyB0byBjcmVhdGUgdGhlaXIgb3duIHNl
Y3Rpb24gc3BlY2lmaWMgY29weSBvZiBoZWxwZXIgZnVuY3Rpb25zIGlzIGRlZmluaXRlbHkgbm90
IHBvcnRhYmxlIGlmIHRoZSBtb2R1bGUgb3Igb3RoZXIgY29kZSBpcyBub3QgYXJjaGl0ZWN0dXJl
IGRlcGVuZGVudC4NCkl0IGlzIGEgbm9ybWFsIGdjYyBmZWF0dXJlIHRoYXQgeW91IGNhbiBhc3Np
Z24gc3BlY2lmaWMgY29kZSB0byBub24tLnRleHQgc2VjdGlvbnMgYW5kIGl0IGlzIG5vdCBkb2N1
bWVudGVkIHRoYXQgaXQgbWF5IGNyYXNoIGRlcGVuZGluZyBvbiB0aGUgT1MgYXJjaCB0aGUgRUxG
IGlzIGJ1aWx0IGZvciwgc28gYXNraW5nIGZvciBhIFBvd2VyIEFyY2hpdGVjdHVyZSBzcGVjaWZp
YyBjaGFuZ2Ugb24gdG9vbCBsaWJzIHRvIG1ha2UgUG93ZXIgQXJjaGl0ZWN0dXJlIExpbnV4IGhh
cHB5IHNlZW1zIGEgYml0IG11Y2ggdG8gYXNrLg0KDQpVc2luZyByMTIgaW4gYW55IExpbnV4IHJl
bGF0ZWQgdHJhbXBvbGluZSBjb2RlIHNlZW1zIGEgcmVhY2hhYmxlIGdvYWwsIGFuZCBpdCB3b3Vs
ZCBlbGltaW5hdGUgdGhlIGNvbmZsaWN0IHRvIHRoZSBBQkkuDQoNClJlZ2FyZHMsDQoNCkhlaW56
DQo=
^ permalink raw reply
* Re: power management patch set for mpc85xx
From: Kumar Gala @ 2012-06-01 14:01 UTC (permalink / raw)
To: Zhao Chenhui-B35336
Cc: Scott Wood, Paul Mackerras, linuxppc-dev@lists.ozlabs.org list,
Li Yang-R58472
In-Reply-To: <7AA2FF042C086D469F577FA6723434DA058123@039-SN1MPN1-002.039d.mgd.msft.net>
On Jun 1, 2012, at 5:29 AM, Zhao Chenhui-B35336 wrote:
> Hi Ben and Paul,
>
> I am sorry to trouble you. It seems that Kumar is busy recently.
>
> Could you have a review on the following patches? These patches
> implement the power management support on MPC85xx platform.
>
> http://patchwork.ozlabs.org/patch/158484/
> http://patchwork.ozlabs.org/patch/158485/
> http://patchwork.ozlabs.org/patch/158487/
> http://patchwork.ozlabs.org/patch/158486/
> http://patchwork.ozlabs.org/patch/158488/
I have been, but was looking for Scott's Ack on these.
- k
^ permalink raw reply
* Re: [PATCH v5 1/5] powerpc/85xx: implement hardware timebase sync
From: Scott Wood @ 2012-06-01 15:40 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1336737235-15370-1-git-send-email-chenhui.zhao@freescale.com>
On 05/11/2012 06:53 AM, Zhao Chenhui wrote:
> #ifdef CONFIG_KEXEC
> +static struct ccsr_guts __iomem *guts;
> +static u64 timebase;
> +static int tb_req;
> +static int tb_valid;
> +
> +static void mpc85xx_timebase_freeze(int freeze)
Why is this under CONFIG_KEXEC? It'll also be needed for CPU hotplug.
> +{
> + unsigned int mask;
> +
> + if (!guts)
> + return;
> +
> + mask = CCSR_GUTS_DEVDISR_TB0 | CCSR_GUTS_DEVDISR_TB1;
> + if (freeze)
> + setbits32(&guts->devdisr, mask);
> + else
> + clrbits32(&guts->devdisr, mask);
> +
> + in_be32(&guts->devdisr);
> +}
> +
> +static void mpc85xx_give_timebase(void)
> +{
> + unsigned long flags;
> +
> + local_irq_save(flags);
> +
> + while (!tb_req)
> + barrier();
> + tb_req = 0;
> +
> + mpc85xx_timebase_freeze(1);
> + timebase = get_tb();
> + mb();
> + tb_valid = 1;
> +
> + while (tb_valid)
> + barrier();
> +
> + mpc85xx_timebase_freeze(0);
> +
> + local_irq_restore(flags);
> +}
> +
> +static void mpc85xx_take_timebase(void)
> +{
> + unsigned long flags;
> +
> + local_irq_save(flags);
> +
> + tb_req = 1;
> + while (!tb_valid)
> + barrier();
> +
> + set_tb(timebase >> 32, timebase & 0xffffffff);
> + mb();
> + tb_valid = 0;
> +
> + local_irq_restore(flags);
> +}
I know you say this is for dual-core chips only, but it would be nice if
you'd write this in a way that doesn't assume that (even if the
corenet-specific timebase freezing comes later).
Do we need an isync after setting the timebase, to ensure it's happened
before we enable the timebase? Likewise, do we need a readback after
disabling the timebase to ensure it's disabled before we read the
timebase in give_timebase?
> atomic_t kexec_down_cpus = ATOMIC_INIT(0);
>
> void mpc85xx_smp_kexec_cpu_down(int crash_shutdown, int secondary)
> @@ -228,6 +286,20 @@ smp_85xx_setup_cpu(int cpu_nr)
> doorbell_setup_this_cpu();
> }
>
> +#ifdef CONFIG_KEXEC
> +static const struct of_device_id guts_ids[] = {
> + { .compatible = "fsl,mpc8572-guts", },
> + { .compatible = "fsl,mpc8560-guts", },
> + { .compatible = "fsl,mpc8536-guts", },
> + { .compatible = "fsl,p1020-guts", },
> + { .compatible = "fsl,p1021-guts", },
> + { .compatible = "fsl,p1022-guts", },
> + { .compatible = "fsl,p1023-guts", },
> + { .compatible = "fsl,p2020-guts", },
> + {},
> +};
> +#endif
MPC8560 and MPC8536 are single-core...
Also please use a more specific name, such as e500v2_smp_guts_ids or
mpc85xx_smp_guts_ids -- when corenet support is added it will likely be
in the same file.
> void __init mpc85xx_smp_init(void)
> {
> struct device_node *np;
> @@ -249,6 +321,19 @@ void __init mpc85xx_smp_init(void)
> smp_85xx_ops.cause_ipi = doorbell_cause_ipi;
> }
>
> +#ifdef CONFIG_KEXEC
> + np = of_find_matching_node(NULL, guts_ids);
> + if (np) {
> + guts = of_iomap(np, 0);
> + smp_85xx_ops.give_timebase = mpc85xx_give_timebase;
> + smp_85xx_ops.take_timebase = mpc85xx_take_timebase;
> + of_node_put(np);
> + } else {
> + smp_85xx_ops.give_timebase = smp_generic_give_timebase;
> + smp_85xx_ops.take_timebase = smp_generic_take_timebase;
> + }
Do not use smp_generic_give/take_timebase, ever. If you don't have the
guts node, then just assume the timebase is already synced.
-Scott
^ permalink raw reply
* Re: [RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
From: Scott Wood @ 2012-06-01 16:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Bob Cochran, support
In-Reply-To: <1338542089.16119.48.camel@pasglop>
On 06/01/2012 04:14 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2012-05-30 at 09:26 -0400, Bob Cochran wrote:
>> I believe that additional patches are required for CodeWarrior to
>> work
>> properly (e.g., assembly start up). I think the patches should come
>> from Freescale. For whatever reason, they include them in their SDK,
>> but haven't submitted them for inclusion in the mainline.
>>
>> As a developer on Freescale Power products, I would like to see
>> Freescale offer up a CodeWarrior patch set, so I don't have to manage
>> the patches myself when working outside the SDK (i.e., on a more
>> recent
>> kernel).
>
> Such patches would have a hard time getting upstream considering that
> codewarrior is a commercial product.
It's not really about CodeWarrior -- it's needed for any external debug
on these chips.
Those chips are commercial products too, BTW. :-)
-Scott
^ permalink raw reply
* Re: [PATCH 03/27] smpboot: Define and use cpu_state per-cpu variable in generic code
From: David Daney @ 2012-06-01 16:59 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: Venkatesh Pallipadi, Jeremy Fitzhardinge, linux-ia64, linux-mips,
peterz, linux-kernel, H. Peter Anvin, mingo, linux-arch,
xen-devel, Suresh Siddha, linux-sh, x86, Ingo Molnar, paulmck,
Fenghua Yu, Mike Frysinger, Peter Zijlstra, nikunj,
Konrad Rzeszutek Wilk, rusty, Chris Metcalf, rjw, yong.zhang0,
tglx, virtualization, Tony Luck, vatsa, Ralf Baechle, Paul Mundt,
akpm, linuxppc-dev
In-Reply-To: <20120601091038.31979.67878.stgit@srivatsabhat.in.ibm.com>
On 06/01/2012 02:10 AM, Srivatsa S. Bhat wrote:
> The per-cpu variable cpu_state is used in x86 and also used in other
> architectures, to track the state of the cpu during bringup and hotplug.
> Pull it out into generic code.
>
> Cc: Tony Luck<tony.luck@intel.com>
> Cc: Fenghua Yu<fenghua.yu@intel.com>
> Cc: Ralf Baechle<ralf@linux-mips.org>
> Cc: Benjamin Herrenschmidt<benh@kernel.crashing.org>
> Cc: Paul Mundt<lethal@linux-sh.org>
> Cc: Chris Metcalf<cmetcalf@tilera.com>
> Cc: Thomas Gleixner<tglx@linutronix.de>
> Cc: Ingo Molnar<mingo@redhat.com>
> Cc: "H. Peter Anvin"<hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: Konrad Rzeszutek Wilk<konrad.wilk@oracle.com>
> Cc: Jeremy Fitzhardinge<jeremy@goop.org>
> Cc: Peter Zijlstra<a.p.zijlstra@chello.nl>
> Cc: Andrew Morton<akpm@linux-foundation.org>
> Cc: Mike Frysinger<vapier@gentoo.org>
> Cc: Yong Zhang<yong.zhang0@gmail.com>
> Cc: Venkatesh Pallipadi<venki@google.com>
> Cc: Suresh Siddha<suresh.b.siddha@intel.com>
> Cc: linux-ia64@vger.kernel.org
> Cc: linux-mips@linux-mips.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-sh@vger.kernel.org
> Cc: xen-devel@lists.xensource.com
> Cc: virtualization@lists.linux-foundation.org
> Signed-off-by: Srivatsa S. Bhat<srivatsa.bhat@linux.vnet.ibm.com>
> ---
>
> arch/ia64/include/asm/cpu.h | 2 --
> arch/ia64/kernel/process.c | 1 +
> arch/ia64/kernel/smpboot.c | 6 +-----
> arch/mips/cavium-octeon/smp.c | 4 +---
> arch/powerpc/kernel/smp.c | 6 +-----
> arch/sh/include/asm/smp.h | 2 --
> arch/sh/kernel/smp.c | 4 +---
> arch/tile/kernel/smpboot.c | 4 +---
> arch/x86/include/asm/cpu.h | 2 --
> arch/x86/kernel/smpboot.c | 4 +---
> arch/x86/xen/smp.c | 1 +
> include/linux/smpboot.h | 1 +
> kernel/smpboot.c | 4 ++++
> 13 files changed, 13 insertions(+), 28 deletions(-)
>
[...]
> diff --git a/arch/mips/cavium-octeon/smp.c b/arch/mips/cavium-octeon/smp.c
> index 97e7ce9..93cd4b0 100644
> --- a/arch/mips/cavium-octeon/smp.c
> +++ b/arch/mips/cavium-octeon/smp.c
> @@ -13,6 +13,7 @@
> #include<linux/kernel_stat.h>
> #include<linux/sched.h>
> #include<linux/module.h>
> +#include<linux/smpboot.h>
>
> #include<asm/mmu_context.h>
> #include<asm/time.h>
> @@ -252,9 +253,6 @@ static void octeon_cpus_done(void)
>
> #ifdef CONFIG_HOTPLUG_CPU
>
> -/* State of each CPU. */
> -DEFINE_PER_CPU(int, cpu_state);
> -
> extern void fixup_irqs(void);
>
> static DEFINE_SPINLOCK(smp_reserve_lock);
The Octeon bit:
Acked-by: David Daney <david.daney@cavium.com>
FWIW, the rest looks good too.
^ permalink raw reply
* Serial RAPID IO kernel hang on maintenance read transaction
From: Proicou, Mike @ 2012-06-01 20:40 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 9198 bytes --]
I've been struggling with a kernel hang during bootup + enumeration of a Rapid IO system.
My current system contains a N.A.T MCH (using the IDT/Tundra Tsi 578 switch) and a Vadatech AMC719 card using the Freescale P4080 processor. There will be other cards added to the system, but I'm testing with just this for now.
I'm using a Linux kernel version 2.6.34.6. I've set riohdid=0 on the kernel command line, and I'm expecting Linux to fully enumerate and configure the Rapid IO fabric. (This may be a bad assumption on my part.)
After lots of tracing, I've determined that the kernel is hanging on the first maintenance transaction to the switch. The hang will often be followed by a "machine check in kernel mode" exception and panic.
This is very similar to the behavior reported in this mailing list thread from 2010: http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-October/086235.html I've read that thread several times and tries most of the suggestions, but they don't appear to apply in my hardware configuration.linu
Is it possible that something in the switch isn't completely initialized at the time that Linux tries to do the maintenance transaction? If so, how do I find it?
Here's the console log for a bootup using the supplied kernel:
Freescale XGMAC MDIO Bus: probed
Setting up RapidIO peer-to-peer network /rapidio@ffe0c0000
fsl-of-rio ffe0c0000.rapidio: Of-device full name /rapidio@ffe0c0000
fsl-of-rio ffe0c0000.rapidio: Regs: [mem 0xffe0c0000-0xffe0dffff]
fsl-of-rio ffe0c0000.rapidio: LAW start 0x0000000c20000000, size 0x0000000001000000.
fsl-of-rio ffe0c0000.rapidio: errirq: 16, bellirq: 57, txirq: 60, rxirq 61
fsl-of-rio ffe0c0000.rapidio: RapidIO PHY type: serial
SRIO Port 1 Status: Lane0Sync Lane1Sync Lane2Sync Lane3Sync Aligned
SRIO Port 2 Status: (Note: Freescale driver only supports Port 1)
fsl-of-rio ffe0c0000.rapidio: Hardware port width: 4
fsl-of-rio ffe0c0000.rapidio: Training connection status: Four-lane
fsl-of-rio ffe0c0000.rapidio: RapidIO Common Transport System size: 256
RIO: enumerate master port 0, RIO0 mport
Machine check in kernel mode.
RIO: port1 error
Caused by (from MCSR=a000): Load Error Report
Guarded Load Error Report
Oops: Machine check, sig: 7 [#1]
SMP NR_CPUS=8 amc718_based
last sysfs file:
Modules linked in:
NIP: c001a460 LR: c01ee41c CTR: c001a420
REGS: effc9f10 TRAP: 0204 Not tainted (2.6.34.6-vt3-svn36835)
MSR: 00021002 <ME,CE> CR: 24022024 XER: 00000000
TASK = ebc68000[1] 'swapper' THREAD: ebc62000 CPU: 6
GPR00: f1200000 ebc63d10 ebc68000 00000000 00000000 3fc00000 3fc00000 f1200068
GPR08: 00000004 ebc63d18 f1190c20 eb530000 24022022 d811c00a 00000000 00000000
GPR16: 00000000 7ffe2a00 00000000 00000000 7fff0df0 00000000 00000000 00000000
GPR24: 00000081 000000ff 00000000 ebd89400 00000068 00029002 c05e8914 ebc63d58
NIP [c001a460] fsl_rio_config_read+0x40/0x78
LR [c01ee41c] rio_mport_read_config_32+0x7c/0xac
Call Trace:
[ebc63d50] [c01eed64] rio_get_host_deviceid_lock+0x3c/0x50
[ebc63d70] [c045acd4] rio_enum_peer+0x28/0x3e4
[ebc63dd0] [c045b178] rio_enum_mport+0xe8/0x244
[ebc63e10] [c045a59c] rio_init_mports+0x90/0xe4
[ebc63e30] [c0457a5c] fsl_of_rio_rpn_probe+0x3c/0x50
[ebc63e40] [c034abe4] of_platform_device_probe+0x58/0x98
[ebc63e60] [c02274d8] driver_probe_device+0xa4/0x1b4
[ebc63e80] [c02260cc] bus_for_each_drv+0x6c/0xa8
[ebc63eb0] [c022735c] device_attach+0xa4/0xc8
[ebc63ed0] [c0226afc] bus_probe_device+0x2c/0x44
[ebc63ee0] [c02245f8] device_add+0x460/0x5a8
[ebc63f30] [c034a750] of_device_register+0x34/0x48
[ebc63f40] [c0008d64] of_platform_device_create+0x44/0x74
[ebc63f50] [c0008f90] of_platform_bus_probe+0x130/0x15c
[ebc63f70] [c0565480] declare_of_platform_devices+0x24/0x140
[ebc63f90] [c05651cc] __machine_initcall_amc718_based_declare_of_platform_devices+0x2c/0x3c
[ebc63fa0] [c0001cb8] do_one_initcall+0x3c/0x1d0
[ebc63fd0] [c055e9b0] kernel_init+0x190/0x230
[ebc63ff0] [c000f284] kernel_thread+0x4c/0x68
Instruction dump:
814b000c 54e0ba7e 7cc60378 7c0004ac 90ca0000 2f880001 800b0018 7ce03a14
419e0020 2f880002 419e002c 38600000 <80e70000> 7c2006ac 90e90000 4e800020
---[ end trace 561bb236c800851f ]---
Kernel panic - not syncing: Attempted to kill init!
Call Trace:
Rebooting in 180 seconds..
Here's a partial log with some additional output and a dump of the error registers at the time of failure:
fsl-elo-dma ffe101300.dma: request channel 0 IRQ
fsl-elo-dma ffe101300.dma: request channel 1 IRQ
fsl-elo-dma ffe101300.dma: request channel 2 IRQ
fsl-elo-dma ffe101300.dma: request channel 3 IRQ
Freescale PowerQUICC MII Bus: probed
Freescale XGMAC MDIO Bus: probed
fsl-of-rio ffe0c0000.rapidio: Setting up RapidIO peer-to-peer network /rapidio@ffe0c0000
fsl-of-rio ffe0c0000.rapidio: Of-device full name /rapidio@ffe0c0000
fsl-of-rio ffe0c0000.rapidio: Regs: [mem 0xffe0c0000-0xffe0dffff]
fsl-of-rio ffe0c0000.rapidio: LAW start 0x0000000c20000000, size 0x0000000001000000
fsl-of-rio ffe0c0000.rapidio: get_immrbase() ffe000000
fsl-of-rio ffe0c0000.rapidio: IO c20000000 c20ffffff
alloc irq_desc for 57 on node 0
alloc kstat_irqs on node 0
irq: irq 57 on host /soc@ffe000000/pic@40000 mapped to virtual irq 57
alloc irq_desc for 60 on node 0
alloc kstat_irqs on node 0
irq: irq 60 on host /soc@ffe000000/pic@40000 mapped to virtual irq 60
alloc irq_desc for 61 on node 0
alloc kstat_irqs on node 0
irq: irq 61 on host /soc@ffe000000/pic@40000 mapped to virtual irq 61
fsl-of-rio ffe0c0000.rapidio: errirq: 16, bellirq: 57, txirq: 60, rxirq 61
fsl-of-rio ffe0c0000.rapidio: Host deviceid 0
fsl-of-rio ffe0c0000.rapidio: RapidIO PHY type: serial
fsl-of-rio ffe0c0000.rapidio: SRIO Port 1 Status: Lane0Sync Lane1Sync Lane2Sync Lane3Sync Aligned
fsl-of-rio ffe0c0000.rapidio: SRIO Port 2 Status: (Note: Freescale driver only supports Port 1)
fsl-of-rio ffe0c0000.rapidio: Hardware port width: 4
fsl-of-rio ffe0c0000.rapidio: Training connection status: Four-lane
fsl-of-rio ffe0c0000.rapidio: RapidIO Common Transport System size: 256
RIO: enumerate master port 0, RIO0 mport
fsl_local_config_write: index 0 offset 00000068 data 00000000
fsl_local_config_read: index 0 offset 00000068 (ebc63da8) = 00000000
fsl_local_config_write: index 0 offset 00000060 data 00000000
fsl_local_config_read: index 0 offset 0000013c (ebc63da8) = e0000000
RIO0 mport PGCCSR e0000000
fsl_local_config_read: index 0 offset 0000000c (ebc63d58) = 00000100
fsl_local_config_read: index 0 offset 00000100 (ebc63d58) = 06000001
fsl_local_config_read: index 0 offset 00000158 (ebc63d88) = 00020302
fsl_local_config_read: index 0 offset 0000013c (ebc63da8) = e0000000
RIO0 mport is active PGCCSR e0000000
rio_enum_peer 1Machine check in kernel mode.
RIO: port1 error
P1 error regs EDCSR 00000005 IECSR 00000000 ESCSR 00020302
LTLEDCSR 00000000
Caused by (from MCSR=a000): Load Error Report
Guarded Load Error Report
Oops: Machine check, sig: 7 [#1]
SMP NR_CPUS=8 amc718_based
last sysfs file:
Modules linked in:
NIP: c001a838 LR: c01f201c CTR: c001a748
REGS: effc9f10 TRAP: 0204 Not tainted (2.6.34.6-MCP-svn1717)
MSR: 00021002 <ME,CE> CR: 24022022 XER: 00000000
TASK = ebc68000[1] 'swapper' THREAD: ebc62000 CPU: 6
GPR00: 00000068 ebc63cf0 ebc68000 ffffffea 00000000 000000ff 00000000 00000068
GPR08: 00000004 ebd80000 3fc00000 f1190c20 24022022 d814c00a 00000000 00000000
GPR16: 00000000 7ffe2a00 00000000 00000000 7fff0df0 00000000 00000000 00000000
GPR24: 00000081 000000ff f1200068 00000000 ebc63d18 00000000 000000ff 00000068
NIP [c001a838] fsl_rio_config_read+0xf0/0x11c
LR [c01f201c] rio_mport_read_config_32+0x7c/0xac
Call Trace:
[ebc63cf0] [7ffe2a00] 0x7ffe2a00 (unreliable)
[ebc63d10] [c01f201c] rio_mport_read_config_32+0x7c/0xac
[ebc63d50] [c01f28d0] rio_get_host_deviceid_lock+0x3c/0x60
[ebc63d70] [c045ec8c] rio_enum_peer+0x34/0x4c0
[ebc63dd0] [c045f228] rio_enum_mport+0x110/0x290
[ebc63e10] [c045e484] rio_init_mports+0x90/0xe4
[ebc63e30] [c045b944] fsl_of_rio_rpn_probe+0x4c/0x60
[ebc63e40] [c034ea48] of_platform_device_probe+0x58/0x98
[ebc63e60] [c022b334] driver_probe_device+0xa4/0x1b4
[ebc63e80] [c0229f28] bus_for_each_drv+0x6c/0xa8
[ebc63eb0] [c022b1b8] device_attach+0xa4/0xc8
[ebc63ed0] [c022a958] bus_probe_device+0x2c/0x44
[ebc63ee0] [c0228454] device_add+0x460/0x5a8
[ebc63f30] [c034e5b4] of_device_register+0x34/0x48
[ebc63f40] [c0008d64] of_platform_device_create+0x44/0x74
[ebc63f50] [c0008f90] of_platform_bus_probe+0x130/0x15c
[ebc63f70] [c056b534] declare_of_platform_devices+0x24/0x140
[ebc63f90] [c056b280] __machine_initcall_amc718_based_declare_of_platform_devices+0x2c/0x3c
[ebc63fa0] [c0001cb8] do_one_initcall+0x3c/0x1d0
[ebc63fd0] [c05649b0] kernel_init+0x190/0x230
[ebc63ff0] [c000f284] kernel_thread+0x4c/0x68
Instruction dump:
7fa6eb78 7fe7fb78 7f49d378 4843d975 2f9b0000 409e0028 935c0000 7f63db78
4bffff58 a35a0000 7c2006ac 4bffffc8 <835a0000> 7c2006ac 4bffffbc 3c60c04e
---[ end trace 561bb236c800851f ]---
Kernel panic - not syncing: Attempted to kill init!
Call Trace:
Rebooting in 180 seconds..
Thanks for any help ...
Mike Proicou
[-- Attachment #2: Type: text/html, Size: 10686 bytes --]
^ permalink raw reply
* Re: [PATCH v5 2/5] powerpc/85xx: add HOTPLUG_CPU support
From: Scott Wood @ 2012-06-01 21:27 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1336737235-15370-2-git-send-email-chenhui.zhao@freescale.com>
On 05/11/2012 06:53 AM, Zhao Chenhui wrote:
\> +#if defined(CONFIG_FSL_BOOKE) || defined(CONFIG_6xx)
> +extern void __flush_disable_L1(void);
> +#endif
Prototypes aren't normally guarded by ifdefs.
> +static void __cpuinit smp_85xx_mach_cpu_die(void)
> +{
> + unsigned int cpu = smp_processor_id();
> + u32 tmp;
> +
> + local_irq_disable();
> + idle_task_exit();
> + generic_set_cpu_dead(cpu);
> + mb();
> +
> + mtspr(SPRN_TCR, 0);
> +
> + __flush_disable_L1();
> + tmp = (mfspr(SPRN_HID0) & ~(HID0_DOZE|HID0_SLEEP)) | HID0_NAP;
> + mtspr(SPRN_HID0, tmp);
> +
> + /* Enter NAP mode. */
> + tmp = mfmsr();
> + tmp |= MSR_WE;
> + mb();
> + mtmsr(tmp);
> + isync();
Need isync after writing to HID0.
> + /*
> + * We don't set the BPTR register here upon it points
> + * to the boot page properly.
> + */
> + mpic_reset_core(hw_cpu);
That comment's wording is hard to follow -- maybe s/upon it points/since
it already points/
> + /* wait until core is ready... */
> + if (!spin_event_timeout(in_be32(&spin_table->addr_l) == 1,
> + 10000, 100)) {
> + pr_err("%s: timeout waiting for core %d to reset\n",
> + __func__, hw_cpu);
> + ret = -ENOENT;
> + goto out;
> + }
We need to fix U-Boot to write addr_l last (with an msync beforehand).
> -#ifdef CONFIG_KEXEC
> +#if defined(CONFIG_KEXEC) || defined(CONFIG_HOTPLUG_CPU)
Let's not grow lists like this. Is there any harm in building it
unconditionally?
-Scott
^ permalink raw reply
* Re: [PATCH v5 3/5] powerpc/85xx: add sleep and deep sleep support
From: Scott Wood @ 2012-06-01 21:54 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1336737235-15370-3-git-send-email-chenhui.zhao@freescale.com>
On 05/11/2012 06:53 AM, Zhao Chenhui wrote:
> From: Li Yang <leoli@freescale.com>
>
> In sleep PM mode, the clocks of e500 core and unused IP blocks is
> turned off. IP blocks which are allowed to wake up the processor
> are still running.
>
> Some Freescale chips like MPC8536 and P1022 has deep sleep PM mode
> in addtion to the sleep PM mode.
>
> While in deep sleep PM mode, additionally, the power supply is
> removed from e500 core and most IP blocks. Only the blocks needed
> to wake up the chip out of deep sleep are ON.
>
> This patch supports 32-bit and 36-bit address space.
>
> The sleep mode is equal to the Standby state in Linux. The deep sleep
> mode is equal to the Suspend-to-RAM state of Linux Power Management.
>
> Command to enter sleep mode.
> echo standby > /sys/power/state
> Command to enter deep sleep mode.
> echo mem > /sys/power/state
>
> Signed-off-by: Dave Liu <daveliu@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Jin Qing <b24347@freescale.com>
> Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com>
> Cc: Scott Wood <scottwood@freescale.com>
> Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> ---
> Changes for v5:
> * Rename flush_disable_L1 to __flush_disable_L1.
>
> arch/powerpc/Kconfig | 2 +-
> arch/powerpc/include/asm/cacheflush.h | 5 +
> arch/powerpc/kernel/Makefile | 3 +
> arch/powerpc/kernel/l2cache_85xx.S | 53 +++
> arch/powerpc/platforms/85xx/Makefile | 3 +
> arch/powerpc/platforms/85xx/sleep.S | 609 +++++++++++++++++++++++++++++++++
> arch/powerpc/sysdev/fsl_pmc.c | 91 ++++-
> arch/powerpc/sysdev/fsl_soc.h | 5 +
> 8 files changed, 752 insertions(+), 19 deletions(-)
> create mode 100644 arch/powerpc/kernel/l2cache_85xx.S
> create mode 100644 arch/powerpc/platforms/85xx/sleep.S
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index d65ae35..039f0a6 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -673,7 +673,7 @@ config FSL_PCI
> config FSL_PMC
> bool
> default y
> - depends on SUSPEND && (PPC_85xx || PPC_86xx)
> + depends on SUSPEND && (PPC_85xx || PPC_86xx) && !PPC_E500MC
> help
> Freescale MPC85xx/MPC86xx power management controller support
> (suspend/resume). For MPC83xx see platforms/83xx/suspend.c
> diff --git a/arch/powerpc/include/asm/cacheflush.h b/arch/powerpc/include/asm/cacheflush.h
> index 94ec20a..baa000c 100644
> --- a/arch/powerpc/include/asm/cacheflush.h
> +++ b/arch/powerpc/include/asm/cacheflush.h
> @@ -33,6 +33,11 @@ extern void flush_dcache_page(struct page *page);
> #if defined(CONFIG_FSL_BOOKE) || defined(CONFIG_6xx)
> extern void __flush_disable_L1(void);
> #endif
> +#if defined(CONFIG_FSL_BOOKE)
> +extern void flush_dcache_L1(void);
> +#else
> +#define flush_dcache_L1() do { } while (0)
> +#endif
It doesn't seem right to no-op this on other platforms.
> extern void __flush_icache_range(unsigned long, unsigned long);
> static inline void flush_icache_range(unsigned long start, unsigned long stop)
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index f5808a3..cb70dba 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -64,6 +64,9 @@ obj-$(CONFIG_FA_DUMP) += fadump.o
> ifeq ($(CONFIG_PPC32),y)
> obj-$(CONFIG_E500) += idle_e500.o
> endif
> +ifneq ($(CONFIG_PPC_E500MC),y)
> +obj-$(CONFIG_PPC_85xx) += l2cache_85xx.o
> +endif
Can we introduce a symbol that specifically means pre-e500mc e500,
rather than using negative logic?
I think something like CONFIG_PPC_E500_V1_V2 has been proposed before.
> -static int pmc_probe(struct platform_device *ofdev)
> +static int pmc_probe(struct platform_device *pdev)
> {
> - pmc_regs = of_iomap(ofdev->dev.of_node, 0);
> + struct device_node *np = pdev->dev.of_node;
> +
> + pmc_regs = of_iomap(np, 0);
> if (!pmc_regs)
> return -ENOMEM;
>
> - pmc_dev = &ofdev->dev;
> + pmc_flag = PMC_SLEEP;
> + if (of_device_is_compatible(np, "fsl,mpc8536-pmc"))
> + pmc_flag |= PMC_DEEP_SLEEP;
> +
> + if (of_device_is_compatible(np, "fsl,p1022-pmc"))
> + pmc_flag |= PMC_DEEP_SLEEP;
> +
> suspend_set_ops(&pmc_suspend_ops);
> +
> + pr_info("Freescale PMC driver\n");
If you're going to be noisy on probe, at least provide some useful info
like whether deep sleep or jog are supported.
> return 0;
> }
>
> diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h
> index c6d0073..949377d 100644
> --- a/arch/powerpc/sysdev/fsl_soc.h
> +++ b/arch/powerpc/sysdev/fsl_soc.h
> @@ -48,5 +48,10 @@ extern struct platform_diu_data_ops diu_ops;
> void fsl_hv_restart(char *cmd);
> void fsl_hv_halt(void);
>
> +/*
> + * Cast the ccsrbar to 64-bit parameter so that the assembly
> + * code can be compatible with both 32-bit & 36-bit.
> + */
> +extern void mpc85xx_enter_deep_sleep(u64 ccsrbar, u32 powmgtreq);
s/Cast the ccsrbar to 64-bit parameter/ccsrbar is u64 rather than
phys_addr_t/
-Scott
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox