* Re: [PATCH][v2] powerpc/mm: using two zones for freescale 64 bit kernel
From: Kumar Gala @ 2012-09-27 12:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Hu Mingkai-B21284, linuxppc-dev@lists.ozlabs.org list,
Chen Yuanquan-B41889, Xie Shaohui-B21989
In-Reply-To: <2C0EEF03-166D-4D34-90DF-0C4B6AAEA053@kernel.crashing.org>
On Sep 24, 2012, at 7:31 AM, Kumar Gala wrote:
>=20
> On Sep 20, 2012, at 8:36 AM, Kumar Gala wrote:
>=20
>>=20
>> On Sep 20, 2012, at 5:14 AM, Xie Shaohui-B21989 wrote:
>>=20
>>>>> On Thu, 2012-08-30 at 15:49 -0500, Kumar Gala wrote:
>>>>>> On Aug 24, 2012, at 5:50 AM, Shaohui Xie wrote:
>>>>>>=20
>>>>>>> PowerPC platform only supports ZONE_DMA zone for 64bit kernel, =
so
>>>>>>> all the memory will be put into this zone. If the memory size is
>>>>>>> greater than the device's DMA capability and device uses
>>>>>>> dma_alloc_coherent to allocate memory, it will get an address
>>>>>>> which is over the device's DMA addressing, the device will fail.
>>>>>>>=20
>>>>>>> So we split the memory to two zones: zone ZONE_DMA32 &
>>>>>>> ZONE_NORMAL, since we already allocate PCICSRBAR/PEXCSRBAR right
>>>>>>> below the 4G boundary (if the lowest PCI address is above 4G), =
so
>>>>>>> we constrain the DMA zone ZONE_DMA32 to 2GB, also, we clear flag
>>>>>>> __GFP_DMA &
>>>>>>> __GFP_DMA32 and set __GFP_DMA32 only if the device's dma_mask <
>>>>>>> total memory size. By doing this, devices which cannot DMA all =
the
>>>>>>> memory will be limited to ZONE_DMA32, but devices which can DMA
>>>>>>> all
>>>>> the memory will not be affected by this limitation.
>>>>>>>=20
>>>>>>> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
>>>>>>> Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
>>>>>>> Signed-off-by: Chen Yuanquan <B41889@freescale.com>
>>>>>>> ---
>>>>>>> changes for v2:
>>>>>>> 1. use a config option for using two zones (ZONE_DMA32 &
>>>>>>> ZONE_NORMAL) in freescale 64 bit kernel.
>>>>>>>=20
>>>>>=20
>>>>> There must have been a misunderstanding. I think this should be a
>>>>> runtime choice, possibly by the platform code. Any reason that =
can't be
>>>> done ?
>>>>>=20
>>>> [S.H] Do you mean this:
>>>>=20
>>>> phys_addr_t platform_dma_size (maybe a default value should be =
used, then
>>>> platform code will change it)
>>>>=20
>>>> if (top_of_ram > platform_dma_size)
>>>> max_zone_pfns[ZONE_DMA] =3D platform_dma_size >> PAGE_SHIFT; =
else
>>>> max_zone_pfns[ZONE_DMA] =3D top_of_ram >> PAGE_SHIFT;
>>>>=20
>>>> max_zone_pfns[ZONE_NORMAL] =3D top_of_ram >> PAGE_SHIFT;
>>>>=20
>>>>> Also how does Intel do it ?
>>>> [S.H] below are codes in Intel:
>>>>=20
>>>> 403 void __init zone_sizes_init(void)
>>>> 404 {
>>>> 405 unsigned long max_zone_pfns[MAX_NR_ZONES];
>>>> 406
>>>> 407 memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
>>>> 408
>>>> 409 #ifdef CONFIG_ZONE_DMA
>>>> 410 max_zone_pfns[ZONE_DMA] =3D MAX_DMA_PFN;
>>>> 411 #endif
>>>> 412 #ifdef CONFIG_ZONE_DMA32
>>>> 413 max_zone_pfns[ZONE_DMA32] =3D MAX_DMA32_PFN;
>>>> 414 #endif
>>>> 415 max_zone_pfns[ZONE_NORMAL] =3D max_low_pfn;
>>>> 416 #ifdef CONFIG_HIGHMEM
>>>> 417 max_zone_pfns[ZONE_HIGHMEM] =3D max_pfn;
>>>> 418 #endif
>>>> 419
>>>>=20
>>>> For x86_64, there is no CONFIG_HIGHMEM, so there will be three =
zones:
>>>> ZONE_DMA/ZONE_DMA32/ZONE_NORMAL.
>>>>=20
>>> [S.H] Hello, Ben,
>>>=20
>>> I have some questions, though I'm still expecting your comments.
>>> PPC does not have ZONE_DMA32 by default, if we want to use it, we =
need to add "config ZONE_DMA32" in Kconfig first.
>>> If setting multiple zones without ZONE_DMA, kmalloc in =
"include/linux/slab_def.h" will fail if it uses flag GFP_DMA.
>>> For the runtime choice in 64-bit kernel, what exactly multiple zones =
should be used?
>>> "ZONE_DMA & ZONE_NORMAL" or "ZONE_DMA & ZONE_DMA32 & ZONE_NORMAL"?
>>> Then what the size should be set for them respectively?
>>>=20
>>> Please comment, Thanks!
>>=20
>> I think Ben is saying that Kconfig would enable ZONE_DMA32 for all =
PPC64, but make it runtime/per platform how we setup the zone's such =
that either ZONE_DMA32 is set to MAX_DMA32_PFN or it set to same value =
as ZONE_DMA.
>>=20
>> However that's just a guess.
>=20
> Ben,
>=20
> Can you help clarify your thoughts here.
>=20
> thanks
Ben?
- k=
^ permalink raw reply
* R: Re: PCI device not working
From: Davide Viti @ 2012-09-27 13:14 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev
Hi Kumar,
>----Messaggio originale----
>Da: galak@kernel.crashing.org
>Data:=20
27/09/2012 14.27
>A: "Davide Viti"<zinosat@tiscali.it>
>Cc: <linuxppc-dev@lists.
ozlabs.org>
>Ogg: Re: PCI device not working
>
...
>Can you see what bus_no=20
actually gets set to in the case we scan 0001:03 ?
>
>If its set to 03, can you=20
try hack it to 1.
is this what you mean?
---=20
a/arch/powerpc/sysdev/indirect_pci.c
+++ b/arch/powerpc/sysdev/indirect_pci.c
bus_no =3D (bus->number =3D=3D hose->first_busno) ?
=20
hose->self_busno : bus->number;
+ if (bus_no =3D=3D 3) {
+ printk
("*** force bus_no 3 -> 1 ***\n");
+ bus_no =3D 1;
+ }
+
I've=20
tested a kernel with the above patch and this is what is printed on the log=
:
pci_bus 0001:03: scanning bus
-> ind_r_config - [/pcie@ffe0a000] devfn=3D0x0=20
offset=3D0x0 len=3D0x4 hose->indirect_type=3D0x16 hose->first_busno=3D0x2 b=
us-
>number=3D0x3
*** force bus_no 3 -> 1 ***
-> ind_r_config [/pcie@ffe0a000] -=20
(bus_no=3D0x1 reg=3D0x0 cfg_data=3D0xff7eb004 len=3D0x4 hose->cfg_addr=3D0x=
ff7eb000)=20
val=3D0xffffffff PCIBIOS_SUCCESSFUL
the entire log (132Kb) is available in [1]=20
and [2]
thanx for your help,
Davide
[1] http://pastebin.com/3mcbDzwY
[2] http:
//paste2.org/p/2274032
Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale pi=
=C3=B9 di uno spot in TV. Per ogni nuovo abbonato 30 =E2=82=AC di premio pe=
r te e per lui! Un amico al mese e parli e navighi sempre gratis: http://fr=
eelosophy.tiscali.it/
^ permalink raw reply
* Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
From: Li Yang @ 2012-09-27 13:24 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472,
Jia Hongtao-B38951
In-Reply-To: <30C76F52-4022-459D-8B84-876B1A572ABE@kernel.crashing.org>
On Thu, Sep 27, 2012 at 8:05 PM, Kumar Gala <galak@kernel.crashing.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Power supply for PCI inbound/outbound window registers is off
>>>>>>>>>>>> when system go to deep-sleep state. We save the values of
>>>>>>>>>>>> registers
>>>>>>>> before
>>>>>>>>>>>> suspend and restore to registers after resume.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
>>>>>>>>>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
>>>>>>>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>> Changes for V4:
>>>>>>>>>>>> We just rebase the patch upon following patch:
>>>>>>>>>>>> powerpc/fsl-pci: Unify pci/pcie initialization code
>>>>>>>>>>>>
>>>>>>>>>>>> arch/powerpc/include/asm/pci-bridge.h | 2 +-
>>>>>>>>>>>> arch/powerpc/sysdev/fsl_pci.c | 121
>>>>>>>>>>> +++++++++++++++++++++++++++++++++
>>>>>>>>>>>> 2 files changed, 122 insertions(+), 1 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>> Did you ever compare this to just re-parsing device tree method?
>>>>>>>>>>>
>>>>>>>>>>> - k
>>>>>>>>>>
>>>>>>>>>> I tested the re-parsing way by using setup_pci_atmu() when
>>> resume.
>>>>>>>>>> And I found out that re-parsing will *change* outbound IO
>>>>>>>>>> translation address regitster.
>>>>>>>>>>
>>>>>>>>>> It seems that in the first bootup, after setup_atmu()
>>>>>>>>>> pcibios_setup_phb_resources() may update hose->io_resource, but
>>>>>>>>>> atmu is not updated according to the new hose->io_resource value.
>>>>>>>>>> In resume from sleep setup_atmu() will reset atmu according to
>>>>>>>>>> the new hose->io_resource value. So the setup_atmu() will cause
>>>>>>>>>> different result on outbound IO register between first bootup
>>>>>>>>>> and resume from sleep.
>>>>>>>>>>
>>>>>>>>>> So... There's a possibility that in the first bootup atmu is
>>>>>>>>>> not setup properly.
>>>>>>>>>
>>>>>>>>> [Are you seeing this happen in your testing? If so its a bug we
>>>>>>>>> need
>>>>>>>> to look at fixing.]
>>>>>>>>>
>>>>>>>>> Yes, I see this in my testing.
>>>>>>>>> Also PCIe ethernet card works well after resuming from sleep in
>>>>>>>>> both
>>>>>>>> save/restore
>>>>>>>>> and re-parsing way. (Maybe PCIe ethernet card don't need
>>>>>>>>> outbound IO
>>>>>>>> resource)
>>>>>>>>> So, I guess the result of re-parsing (actually it's re-setup) is
>>>>>>>>> right
>>>>>>>> and ATMU is not setup
>>>>>>>>> properly at the first bootup.
>>>>>>>>
>>>>>>>> Are you seeing the following message - "PCI: I/O resource not set
>>>>>>>> for host bridge" ?
>>>>>>>
>>>>>>> No.
>>>>>>>
>>>>>>>>
>>>>>>>> Trying to understand why you'd hit the reassignment of io_resource.
>>>>>>>>
>>>>>>>> - k
>>>>>>>>
>>>>>>>
>>>>>>> I did some investigations and the conclusion is:
>>>>>>>
>>>>>>> io_resource.flags & IORESOURCE_IO are both positive but
>>>>>>> io_resource.start is 0 before pcibios_setup_phb_io_space() is done.
>>>>>>>
>>>>>>> The sequence of related process listed below:
>>>>>>> fsl_add_bridge() -> setup_pci_atmu()
>>>>>>> pcibios_init() -> pcibios_scan_phb() ->
>>>>>>> pcibios_setup_phb_io_space()
>>>>>>>
>>>>>>> Because fsl_add_bridge() must be finished before pcibios_init() so
>>>>>>> ATMU is set when io_resource.start is 0. That means outbound IO
>>>>>>> regs are not set.
>>>>>>>
>>>>>>> If system re-setup ATMU the io_resource.start has already updated
>>>>>>> so outbound IO regs are set.
>>>>>>>
>>>>>>> My question is:
>>>>>>> Is there any problem if outbound IO regs are not set in first
>>> bootup?
>>>>
>>>> Yes, it means that IO transactions would not work.
>>>
>>> I agree.
>>>
>>>>
>>>>>> Please also provide the IO resource address range before and after
>>>>>> the pci scan. Then we can evaluate if the range is needed to be
>>>>>> mapped
>>>> via
>>>>>> ATMU.
>>>>>>
>>>>>> Leo
>>>>>
>>>>> Since potar is set by out_be32(&pci->pow[j].potar, (hose-
>>>>> io_resource.start >> 12); I provide the result of
>>>>> hose->io_resource.start >> 12 as follows:
>>>>>
>>>>> pcie@ffe09000:
>>>>> before pci scan: io_resource.start >> 12: 0 after pci scan :
>>>>> io_resource.start >> 12: ff7ed
>>>>>
>>>>> pcie@ffe0a000:
>>>>> before pci scan: io_resource.start >> 12: 0 after pci scan :
>>>>> io_resource.start >> 12: ff7db
>>>>>
>>>>> pcie@ffe0b000:
>>>>> before pci scan: io_resource.start >> 12: 0 after pci scan :
>>>>> io_resource.start >> 12: ff7c9
>>>>>
>>>>> Note that I tested on P1022DS.
>>>>>
>>>>> - Hongtao.
>>>>
>>>> 1. What's the device tree nodes for PCIe look like?
>>>> 2. Can you get the pr_debug() in setup_pci_atmu() to print and report
>>>> results (as well as full boot log)
>>>
>>> Please refer to the attached file.
>>> In the log file I also print the device tree.
>>>
>>> - Hongtao.
>>>
>>>>
>>>> However, I think the change of the io_resource.start is normal and
>>>> correct behavior.
>>>>
>>>> - k
>>>>
>>>
>>
>> Hi Kumar,
>> I have already sent the log.
>> Do you have any comment on it?
>>
>> Thanks.
>> - Hongtao.
>>
>
> Hongtao,
>
> You mentioned:
>
>> I tested the re-parsing way by using setup_pci_atmu() when resume.
>> And I found out that re-parsing will *change* outbound IO
>> translation address regitster.
>
> What do the values look like in both ATMU registers and io_resource if you reparse?
I think Hongtao mentioned in previous email as follows, the ATMU
registers are inline with the io_resource address.
> > Since potar is set by out_be32(&pci->pow[j].potar, (hose-
> >io_resource.start >> 12);
> > I provide the result of hose->io_resource.start >> 12 as follows:
> >
> > pcie@ffe09000:
> > before pci scan: io_resource.start >> 12: 0
> > after pci scan : io_resource.start >> 12: ff7ed
> >
> > pcie@ffe0a000:
> > before pci scan: io_resource.start >> 12: 0
> > after pci scan : io_resource.start >> 12: ff7db
> >
> > pcie@ffe0b000:
> > before pci scan: io_resource.start >> 12: 0
> > after pci scan : io_resource.start >> 12: ff7c9
> >
> > Note that I tested on P1022DS.
^ permalink raw reply
* Re: [PATCH 1/1] drivers/char/tpm: remove tasklet and cleanup
From: Ashley Lai @ 2012-09-27 14:46 UTC (permalink / raw)
To: key
Cc: James Morris, linux-kernel, linux-security-module, tpmdd-devel,
adlai, rcj, linuxppc-dev
In-Reply-To: <20120926135513.GA8251@ennui.austin.ibm.com>
On Wed, 2012-09-26 at 08:55 -0500, key@linux.vnet.ibm.com wrote:
> On Mon, Sep 24, 2012 at 10:48:21AM -0500, key@linux.vnet.ibm.com wrote:
> > On Mon, Sep 24, 2012 at 09:10:41AM -0500, key@linux.vnet.ibm.com wrote:
> > > On Mon, Sep 24, 2012 at 12:26:05PM +1000, James Morris wrote:
> > > > On Wed, 12 Sep 2012, Ashley Lai wrote:
> > > >
> > > > > This patch removed the tasklet and moved the wait queue into the
> > > > > private structure. It also cleaned up the response CRQ path.
> > > > >
> > > > > Signed-off-by: Ashley Lai <adlai@us.ibm.com>
> > > >
> > > >
> > > > Kent: any comment on this? You should probably push this to me via your
> > > > tree.
> > >
> > > Oh, I thought we were waiting on Ben. This looks good to me, I'll get
> > > this to you today.
> >
> > Ashley tells me Ben's review is in the works, so I'll send once we
> > have it.
>
> Ben - any status here?
>
> Kent
Hi Ben,
Would you review the patch before the weekend? If you are busy and not
able to review the patch this week, we will pull the patch into James's
tree next week. I can resolve any additional comments you may have in a
different patch.
Thanks,
--Ashley Lai
>
> >
> > Kent
> >
> > >
> > > Kent
> > >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
^ permalink raw reply
* Re: powerpc/perf: hw breakpoints return ENOSPC
From: Frederic Weisbecker @ 2012-09-27 15:23 UTC (permalink / raw)
To: Michael Neuling
Cc: Ingo Molnar, linuxppc-dev, K Prasad, linux-kernel, Peter Zijlstra
In-Reply-To: <29084.1348557014@neuling.org>
2012/9/25 Michael Neuling <mikey@neuling.org>:
> Michael Neuling <mikey@neuling.org> wrote:
>
>> Frederic Weisbecker <fweisbec@gmail.com> wrote:
>>
>> > On Thu, Aug 16, 2012 at 02:23:54PM +1000, Michael Neuling wrote:
>> > > Hi,
>> > >
>> > > I've been trying to get hardware breakpoints with perf to work on POWER7
>> > > but I'm getting the following:
>> > >
>> > > % perf record -e mem:0x10000000 true
>> > >
>> > > Error: sys_perf_event_open() syscall returned with 28 (No space left on device). /bin/dmesg may provide additional information.
>> > >
>> > > Fatal: No CONFIG_PERF_EVENTS=y kernel support configured?
>> > >
>> > > true: Terminated
>> > >
>> > > (FWIW adding -a and it works fine)
>> > >
>> > > Debugging it seems that __reserve_bp_slot() is returning ENOSPC because
>> > > it thinks there are no free breakpoint slots on this CPU.
>> > >
>> > > I have a 2 CPUs, so perf userspace is doing two perf_event_open syscalls
>> > > to add a counter to each CPU [1]. The first syscall succeeds but the
>> > > second is failing.
>> > >
>> > > On this second syscall, fetch_bp_busy_slots() sets slots.pinned to be 1,
>> > > despite there being no breakpoint on this CPU. This is because the call
>> > > the task_bp_pinned, checks all CPUs, rather than just the current CPU.
>> > > POWER7 only has one hardware breakpoint per CPU (ie. HBP_NUM=1), so we
>> > > return ENOSPC.
>> > >
>> > > The following patch fixes this by checking the associated CPU for each
>> > > breakpoint in task_bp_pinned. I'm not familiar with this code, so it's
>> > > provided as a reference to the above issue.
>> > >
>> > > Mikey
>> > >
>> > > 1. not sure why it doesn't just do one syscall and specify all CPUs, but
>> > > that's another issue. Using two syscalls should work.
>> >
>> > This patch seems to make sense. I'll try it and run some tests.
>> > Can I have your Signed-off-by ?
>
> Frederic,
>
> Did you ever get to testing or integrating this patch?
>
> Mikey
Sorry, I forgot this in my mailbox. I'm going to look at this in the
next few days.
Feel free to harass me by email or IRC if I don't give news on this soon.
^ permalink raw reply
* Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
From: Kumar Gala @ 2012-09-27 16:04 UTC (permalink / raw)
To: Li Yang
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472,
Jia Hongtao-B38951
In-Reply-To: <CADRPPNQga4J26oDacT-fGMZiecE2KLsLh2DBEErtQ9_gJSwgpA@mail.gmail.com>
>>> Hi Kumar,
>>> I have already sent the log.
>>> Do you have any comment on it?
>>>=20
>>> Thanks.
>>> - Hongtao.
>>>=20
>>=20
>> Hongtao,
>>=20
>> You mentioned:
>>=20
>>> I tested the re-parsing way by using setup_pci_atmu() when resume.
>>> And I found out that re-parsing will *change* outbound IO
>>> translation address regitster.
>>=20
>> What do the values look like in both ATMU registers and io_resource =
if you reparse?
>=20
> I think Hongtao mentioned in previous email as follows, the ATMU
> registers are inline with the io_resource address.
I was under that the impression that was the normal boot case, not the =
values from after wakeup.
- k
>>> Since potar is set by out_be32(&pci->pow[j].potar, (hose-
>>> io_resource.start >> 12);
>>> I provide the result of hose->io_resource.start >> 12 as follows:
>>>=20
>>> pcie@ffe09000:
>>> before pci scan: io_resource.start >> 12: 0
>>> after pci scan : io_resource.start >> 12: ff7ed
>>>=20
>>> pcie@ffe0a000:
>>> before pci scan: io_resource.start >> 12: 0
>>> after pci scan : io_resource.start >> 12: ff7db
>>>=20
>>> pcie@ffe0b000:
>>> before pci scan: io_resource.start >> 12: 0
>>> after pci scan : io_resource.start >> 12: ff7c9
>>>=20
>>> Note that I tested on P1022DS.
^ permalink raw reply
* Re: PCI device not working
From: Kumar Gala @ 2012-09-27 16:06 UTC (permalink / raw)
To: Davide Viti; +Cc: linuxppc-dev
In-Reply-To: <1566557.89621348751677116.JavaMail.defaultUser@defaultHost>
On Sep 27, 2012, at 8:14 AM, Davide Viti wrote:
> Hi Kumar,
>=20
>> ----Messaggio originale----
>> Da: galak@kernel.crashing.org
>> Data:=20
> 27/09/2012 14.27
>> A: "Davide Viti"<zinosat@tiscali.it>
>> Cc: <linuxppc-dev@lists.
> ozlabs.org>
>> Ogg: Re: PCI device not working
>>=20
> ...
>> Can you see what bus_no=20
> actually gets set to in the case we scan 0001:03 ?
>>=20
>> If its set to 03, can you=20
> try hack it to 1.
>=20
> is this what you mean?
It was, can you figure out in u-boot what exact config read on the bus =
would return the correct thing.
The fact that when we probe the device at 0001:03 we should get back =
something like cfg_data=3D0xabba1b65
- k
>=20
> ---=20
> a/arch/powerpc/sysdev/indirect_pci.c
> +++ b/arch/powerpc/sysdev/indirect_pci.c
>=20
>=20
> bus_no =3D (bus->number =3D=3D hose->first_busno) ?
>=20
> hose->self_busno : bus->number;
>=20
> + if (bus_no =3D=3D 3) {
> + printk
> ("*** force bus_no 3 -> 1 ***\n");
> + bus_no =3D 1;
> + }
> +
>=20
>=20
> I've=20
> tested a kernel with the above patch and this is what is printed on =
the log:
>=20
>=20
> pci_bus 0001:03: scanning bus
> -> ind_r_config - [/pcie@ffe0a000] devfn=3D0x0=20
> offset=3D0x0 len=3D0x4 hose->indirect_type=3D0x16 =
hose->first_busno=3D0x2 bus-
>> number=3D0x3
> *** force bus_no 3 -> 1 ***
> -> ind_r_config [/pcie@ffe0a000] -=20
> (bus_no=3D0x1 reg=3D0x0 cfg_data=3D0xff7eb004 len=3D0x4 =
hose->cfg_addr=3D0xff7eb000)=20
> val=3D0xffffffff PCIBIOS_SUCCESSFUL
>=20
> the entire log (132Kb) is available in [1]=20
> and [2]
>=20
> thanx for your help,
> Davide
>=20
> [1] http://pastebin.com/3mcbDzwY
> [2] http:
> //paste2.org/p/2274032
>=20
>=20
>=20
> Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale =
pi=F9 di uno spot in TV. Per ogni nuovo abbonato 30 =80 di premio per te =
e per lui! Un amico al mese e parli e navighi sempre gratis: =
http://freelosophy.tiscali.it/
^ permalink raw reply
* Re: [PATCH 3/3] edac/85xx: Enable the EDAC PCI err driver by device_initcall
From: Scott Wood @ 2012-09-27 16:09 UTC (permalink / raw)
To: Chunhe Lan; +Cc: kumar.gala, linuxppc-dev, Chunhe Lan
In-Reply-To: <1348772523-17587-3-git-send-email-Chunhe.Lan@freescale.com>
On 09/27/2012 02:02:03 PM, Chunhe Lan wrote:
> Original process of call:
> The mpc85xx_pci_err_probe function completes to been registered
> and enabled of EDAC PCI err driver at the latter time stage of
> kernel boot in the mpc85xx_edac.c.
> Current process of call:
> The mpc85xx_pci_err_probe function completes to been registered
> and enabled of EDAC PCI err driver at the first time stage of
> kernel boot in the fsl_pci.c.
>=20
> So in this case the following error messages appear in the boot log:
>=20
> PCI: Probing PCI hardware
> pci 0000:00:00.0: ignoring class b20 (doesn't match header type =20
> 01)
> PCIE error(s) detected
> PCIE ERR_DR register: 0x00020000
> PCIE ERR_CAP_STAT register: 0x80000001
> PCIE ERR_CAP_R0 register: 0x00000800
> PCIE ERR_CAP_R1 register: 0x00000000
> PCIE ERR_CAP_R2 register: 0x00000000
> PCIE ERR_CAP_R3 register: 0x00000000
>=20
> Because the EDAC PCI err driver is registered and enabled earlier than
> original point of call. But at this point of time, PCI hardware is not
> probed and initialized, and it is in unknowable state.
>=20
> So, move enable function into mpc85xx_pci_err_en which is called at =20
> the
> middle time stage of kernel boot and after PCI hardware is probed and
> initialized by device_initcall in the fsl_pci.c.
>=20
> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_pci.c | 12 ++++++++++
> arch/powerpc/sysdev/fsl_pci.h | 5 ++++
> drivers/edac/mpc85xx_edac.c | 47 =20
> ++++++++++++++++++++++++++++------------
> 3 files changed, 50 insertions(+), 14 deletions(-)
>=20
> diff --git a/arch/powerpc/sysdev/fsl_pci.c =20
> b/arch/powerpc/sysdev/fsl_pci.c
> index 3d6f4d8..a591965 100644
> --- a/arch/powerpc/sysdev/fsl_pci.c
> +++ b/arch/powerpc/sysdev/fsl_pci.c
> @@ -904,4 +904,16 @@ static int __init fsl_pci_init(void)
> return platform_driver_register(&fsl_pci_driver);
> }
> arch_initcall(fsl_pci_init);
> +
> +static int __init fsl_pci_err_en(void)
> +{
> + struct device_node *np;
> +
> + for_each_node_by_type(np, "pci")
> + if (of_match_node(pci_ids, np))
> + mpc85xx_pci_err_en(np);
> +
> + return 0;
> +}
> +device_initcall(fsl_pci_err_en);
Why can't you call this from the normal PCIe controller init, instead =20
of searching for the node independently?
-Scott=
^ permalink raw reply
* Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
From: Li Yang-R58472 @ 2012-09-27 16:27 UTC (permalink / raw)
To: Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Jia Hongtao-B38951
In-Reply-To: <587B44DE-F710-4AF0-AB0B-A48FEEE29509@kernel.crashing.org>
DQrU2iBTZXAgMjgsIDIwMTKjrDA6MDejrCJLdW1hciBHYWxhIiA8Z2FsYWtAa2VybmVsLmNyYXNo
aW5nLm9yZz4g0LS1wKO6DQoNCj4+Pj4gSGkgS3VtYXIsDQo+Pj4+IEkgaGF2ZSBhbHJlYWR5IHNl
bnQgdGhlIGxvZy4NCj4+Pj4gRG8geW91IGhhdmUgYW55IGNvbW1lbnQgb24gaXQ/DQo+Pj4+IA0K
Pj4+PiBUaGFua3MuDQo+Pj4+IC0gSG9uZ3Rhby4NCj4+Pj4gDQo+Pj4gDQo+Pj4gSG9uZ3RhbywN
Cj4+PiANCj4+PiBZb3UgbWVudGlvbmVkOg0KPj4+IA0KPj4+PiBJIHRlc3RlZCB0aGUgcmUtcGFy
c2luZyB3YXkgYnkgdXNpbmcgc2V0dXBfcGNpX2F0bXUoKSB3aGVuIHJlc3VtZS4NCj4+Pj4gQW5k
IEkgZm91bmQgb3V0IHRoYXQgcmUtcGFyc2luZyB3aWxsICpjaGFuZ2UqIG91dGJvdW5kIElPDQo+
Pj4+IHRyYW5zbGF0aW9uIGFkZHJlc3MgcmVnaXRzdGVyLg0KPj4+IA0KPj4+IFdoYXQgZG8gdGhl
IHZhbHVlcyBsb29rIGxpa2UgaW4gYm90aCBBVE1VIHJlZ2lzdGVycyBhbmQgaW9fcmVzb3VyY2Ug
aWYgeW91IHJlcGFyc2U/DQo+PiANCj4+IEkgdGhpbmsgSG9uZ3RhbyBtZW50aW9uZWQgaW4gcHJl
dmlvdXMgZW1haWwgYXMgZm9sbG93cywgdGhlIEFUTVUNCj4+IHJlZ2lzdGVycyBhcmUgaW5saW5l
IHdpdGggdGhlIGlvX3Jlc291cmNlIGFkZHJlc3MuDQo+IA0KPiBJIHdhcyB1bmRlciB0aGF0IHRo
ZSBpbXByZXNzaW9uIHRoYXQgd2FzIHRoZSBub3JtYWwgYm9vdCBjYXNlLCBub3QgdGhlIHZhbHVl
cyBmcm9tIGFmdGVyIHdha2V1cC4NCg0KSXQgaXMgZm9yIHRoZSBub3JtYWwgYm9vdC4gIEJ1dCBy
ZS1wYXJzZSB3aWxsIHVzZSB0aGUgaW8gcmVzb3VyY2UgYWZ0ZXIgcGljIHNjYW4gdG8gaW5pdGlh
bGl6ZSBhdG11LiAgSW5zdGVhZCwgdGhlIG9yaWdpbmFsIGF0bXUgaXMgaW5pdGlhbGl6ZWQgdXNl
IHRoZSBpbyByZXNvdXJjZSBiZWZvcmUgdGhlIHNjYW4uDQoNCkxlbw0KPiANCj4gLSBrDQo+IA0K
Pj4+PiBTaW5jZSBwb3RhciBpcyBzZXQgYnkgb3V0X2JlMzIoJnBjaS0+cG93W2pdLnBvdGFyLCAo
aG9zZS0NCj4+Pj4gaW9fcmVzb3VyY2Uuc3RhcnQgPj4gMTIpOw0KPj4+PiBJIHByb3ZpZGUgdGhl
IHJlc3VsdCBvZiBob3NlLT5pb19yZXNvdXJjZS5zdGFydCA+PiAxMiBhcyBmb2xsb3dzOg0KPj4+
PiANCj4+Pj4gcGNpZUBmZmUwOTAwMDoNCj4+Pj4gYmVmb3JlIHBjaSBzY2FuOiBpb19yZXNvdXJj
ZS5zdGFydCA+PiAxMjogMA0KPj4+PiBhZnRlciBwY2kgc2NhbiA6IGlvX3Jlc291cmNlLnN0YXJ0
ID4+IDEyOiBmZjdlZA0KPj4+PiANCj4+Pj4gcGNpZUBmZmUwYTAwMDoNCj4+Pj4gYmVmb3JlIHBj
aSBzY2FuOiBpb19yZXNvdXJjZS5zdGFydCA+PiAxMjogMA0KPj4+PiBhZnRlciBwY2kgc2NhbiA6
IGlvX3Jlc291cmNlLnN0YXJ0ID4+IDEyOiBmZjdkYg0KPj4+PiANCj4+Pj4gcGNpZUBmZmUwYjAw
MDoNCj4+Pj4gYmVmb3JlIHBjaSBzY2FuOiBpb19yZXNvdXJjZS5zdGFydCA+PiAxMjogMA0KPj4+
PiBhZnRlciBwY2kgc2NhbiA6IGlvX3Jlc291cmNlLnN0YXJ0ID4+IDEyOiBmZjdjOQ0KPj4+PiAN
Cj4+Pj4gTm90ZSB0aGF0IEkgdGVzdGVkIG9uIFAxMDIyRFMuDQo+IA0KPiANCg==
^ permalink raw reply
* Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
From: Kumar Gala @ 2012-09-27 21:38 UTC (permalink / raw)
To: Li Yang-R58472
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
Jia Hongtao-B38951
In-Reply-To: <867C679D-6CA3-4F02-9864-E7E8A62BD6BF@freescale.com>
On Sep 27, 2012, at 11:27 AM, Li Yang-R58472 wrote:
>=20
> =D4=DA Sep 28, 2012=A3=AC0:07=A3=AC"Kumar Gala" =
<galak@kernel.crashing.org> =D0=B4=B5=C0=A3=BA
>=20
>>>>> Hi Kumar,
>>>>> I have already sent the log.
>>>>> Do you have any comment on it?
>>>>>=20
>>>>> Thanks.
>>>>> - Hongtao.
>>>>>=20
>>>>=20
>>>> Hongtao,
>>>>=20
>>>> You mentioned:
>>>>=20
>>>>> I tested the re-parsing way by using setup_pci_atmu() when resume.
>>>>> And I found out that re-parsing will *change* outbound IO
>>>>> translation address regitster.
>>>>=20
>>>> What do the values look like in both ATMU registers and io_resource =
if you reparse?
>>>=20
>>> I think Hongtao mentioned in previous email as follows, the ATMU
>>> registers are inline with the io_resource address.
>>=20
>> I was under that the impression that was the normal boot case, not =
the values from after wakeup.
>=20
> It is for the normal boot. But re-parse will use the io resource =
after pic scan to initialize atmu. Instead, the original atmu is =
initialized use the io resource before the scan.
>=20
> Leo
I think I see, so isn't the mem resources also wrong?
Can we dump the following:
1. enable pr_debug() in pcibios_setup_phb_resources so we get "PHB: " =
prints
2. Can we dump hose->io_resource & hose->mem_resources[] right after =
wakeup?
I think I see what direction but would be useful to get a few more =
answers.
- k=
^ permalink raw reply
* Re: [PATCH 3/3] edac/85xx: Enable the EDAC PCI err driver by device_initcall
From: Gala Kumar-B11780 @ 2012-09-27 21:45 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Lan Chunhe-B25806, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1348762151.18375.6@snotra>
On Sep 27, 2012, at 11:09 AM, Scott Wood wrote:
> On 09/27/2012 02:02:03 PM, Chunhe Lan wrote:
>> Original process of call:
>> The mpc85xx_pci_err_probe function completes to been registered
>> and enabled of EDAC PCI err driver at the latter time stage of
>> kernel boot in the mpc85xx_edac.c.
>> Current process of call:
>> The mpc85xx_pci_err_probe function completes to been registered
>> and enabled of EDAC PCI err driver at the first time stage of
>> kernel boot in the fsl_pci.c.
>> So in this case the following error messages appear in the boot log:
>> PCI: Probing PCI hardware
>> pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
>> PCIE error(s) detected
>> PCIE ERR_DR register: 0x00020000
>> PCIE ERR_CAP_STAT register: 0x80000001
>> PCIE ERR_CAP_R0 register: 0x00000800
>> PCIE ERR_CAP_R1 register: 0x00000000
>> PCIE ERR_CAP_R2 register: 0x00000000
>> PCIE ERR_CAP_R3 register: 0x00000000
>> Because the EDAC PCI err driver is registered and enabled earlier than
>> original point of call. But at this point of time, PCI hardware is not
>> probed and initialized, and it is in unknowable state.
>> So, move enable function into mpc85xx_pci_err_en which is called at the
>> middle time stage of kernel boot and after PCI hardware is probed and
>> initialized by device_initcall in the fsl_pci.c.
>> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
>> ---
>> arch/powerpc/sysdev/fsl_pci.c | 12 ++++++++++
>> arch/powerpc/sysdev/fsl_pci.h | 5 ++++
>> drivers/edac/mpc85xx_edac.c | 47 ++++++++++++++++++++++++++++-------=
-----
>> 3 files changed, 50 insertions(+), 14 deletions(-)
>> diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci=
.c
>> index 3d6f4d8..a591965 100644
>> --- a/arch/powerpc/sysdev/fsl_pci.c
>> +++ b/arch/powerpc/sysdev/fsl_pci.c
>> @@ -904,4 +904,16 @@ static int __init fsl_pci_init(void)
>> return platform_driver_register(&fsl_pci_driver);
>> }
>> arch_initcall(fsl_pci_init);
>> +
>> +static int __init fsl_pci_err_en(void)
>> +{
>> + struct device_node *np;
>> +
>> + for_each_node_by_type(np, "pci")
>> + if (of_match_node(pci_ids, np))
>> + mpc85xx_pci_err_en(np);
>> +
>> + return 0;
>> +}
>> +device_initcall(fsl_pci_err_en);
>=20
> Why can't you call this from the normal PCIe controller init, instead of =
searching for the node independently?
Don't we have this now with mpc85xx_pci_err_probe() ??
- k=
^ permalink raw reply
* Re: [PATCH 3/3] edac/85xx: Enable the EDAC PCI err driver by device_initcall
From: Scott Wood @ 2012-09-27 21:51 UTC (permalink / raw)
To: Gala Kumar-B11780
Cc: Lan Chunhe-B25806, Wood Scott-B07421,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CF1EE7AED478CD48A05574C8E2DA142D5E2C18@039-SN1MPN1-006.039d.mgd.msft.net>
On 09/27/2012 04:45:08 PM, Gala Kumar-B11780 wrote:
>=20
> On Sep 27, 2012, at 11:09 AM, Scott Wood wrote:
>=20
> > On 09/27/2012 02:02:03 PM, Chunhe Lan wrote:
> >> Original process of call:
> >> The mpc85xx_pci_err_probe function completes to been registered
> >> and enabled of EDAC PCI err driver at the latter time stage of
> >> kernel boot in the mpc85xx_edac.c.
> >> Current process of call:
> >> The mpc85xx_pci_err_probe function completes to been registered
> >> and enabled of EDAC PCI err driver at the first time stage of
> >> kernel boot in the fsl_pci.c.
> >> So in this case the following error messages appear in the boot =20
> log:
> >> PCI: Probing PCI hardware
> >> pci 0000:00:00.0: ignoring class b20 (doesn't match header type =20
> 01)
> >> PCIE error(s) detected
> >> PCIE ERR_DR register: 0x00020000
> >> PCIE ERR_CAP_STAT register: 0x80000001
> >> PCIE ERR_CAP_R0 register: 0x00000800
> >> PCIE ERR_CAP_R1 register: 0x00000000
> >> PCIE ERR_CAP_R2 register: 0x00000000
> >> PCIE ERR_CAP_R3 register: 0x00000000
> >> Because the EDAC PCI err driver is registered and enabled earlier =20
> than
> >> original point of call. But at this point of time, PCI hardware is =20
> not
> >> probed and initialized, and it is in unknowable state.
> >> So, move enable function into mpc85xx_pci_err_en which is called =20
> at the
> >> middle time stage of kernel boot and after PCI hardware is probed =20
> and
> >> initialized by device_initcall in the fsl_pci.c.
> >> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
> >> ---
> >> arch/powerpc/sysdev/fsl_pci.c | 12 ++++++++++
> >> arch/powerpc/sysdev/fsl_pci.h | 5 ++++
> >> drivers/edac/mpc85xx_edac.c | 47 =20
> ++++++++++++++++++++++++++++------------
> >> 3 files changed, 50 insertions(+), 14 deletions(-)
> >> diff --git a/arch/powerpc/sysdev/fsl_pci.c =20
> b/arch/powerpc/sysdev/fsl_pci.c
> >> index 3d6f4d8..a591965 100644
> >> --- a/arch/powerpc/sysdev/fsl_pci.c
> >> +++ b/arch/powerpc/sysdev/fsl_pci.c
> >> @@ -904,4 +904,16 @@ static int __init fsl_pci_init(void)
> >> return platform_driver_register(&fsl_pci_driver);
> >> }
> >> arch_initcall(fsl_pci_init);
> >> +
> >> +static int __init fsl_pci_err_en(void)
> >> +{
> >> + struct device_node *np;
> >> +
> >> + for_each_node_by_type(np, "pci")
> >> + if (of_match_node(pci_ids, np))
> >> + mpc85xx_pci_err_en(np);
> >> +
> >> + return 0;
> >> +}
> >> +device_initcall(fsl_pci_err_en);
> >
> > Why can't you call this from the normal PCIe controller init, =20
> instead of searching for the node independently?
>=20
> Don't we have this now with mpc85xx_pci_err_probe() ??
What do you mean by "this"?
-Scott=
^ permalink raw reply
* [REGRESSION] nfsd crashing with 3.6.0-rc7 on PowerPC
From: Alexander Graf @ 2012-09-28 1:55 UTC (permalink / raw)
To: LKML List
Cc: linux-nfs, Jan Kara, linuxppc-dev, skinsbursky, bfields,
Linus Torvalds
Howdy,
While running 3.6.0-rcX I am having a few issues with nfsd on my PPC970 =
based system. For some reason every time I actually end up accessing an =
NFS share on it, it crashes away at random points. It looks a lot like =
corrupted pointers in all logs. I also can't reproduce the oopses =
without nfsd in the game. Doing the same workload that crashes over NFS =
locally on the box (git clone -ls) works just fine.
The mount was done simply without parameters:
lychee:/home/agraf/release on /abuild/agraf/autotest_e500/lychee type =
nfs (rw,addr=3D10.10.1.189)
My exports on the host is also quite simple:
/home/agraf/release *(async,rw)
Below are OOPS excerpts from different rc's I tried. All of them crashed =
- all the way up to current Linus' master branch. I haven't =
cross-checked, but I don't remember any such behavior from pre-3.6 =
releases.
Alex
=
##########################################################################=
##
# 3.6.0-rc1 =
#
=
##########################################################################=
##
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT SMP NR_CPUS=3D32 Maple
Modules linked in: nfsd autofs4 exportfs binfmt_misc tg3 uninorth_agp =
agpgart hwmon
NIP: c00000000016a330 LR: c000000000608794 CTR: c00000000063fe78
REGS: c000000071b832f0 TRAP: 0300 Not tainted =
(3.6.0-rc1-00220-gb645f8b)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 22002044 XER: =
20000000
SOFTE: 1
DAR: 4e375f30f9fae38f, DSISR: 40000000
TASK =3D c00000007b3a0000[6061] 'nfsd' THREAD: c000000071b80000 CPU: 3
GPR00: 0000000000000000 c000000071b83570 c000000000b8e2a8 =
0000000000000280=20
GPR04: 00000000000102d0 c000000000609844 c00000000065418c =
c000000000ec55e0=20
GPR08: 000000000036ac63 0000000000477000 c000000000a91758 =
c000000000a4e5e0=20
GPR12: 0000000022000048 c00000000fff2680 0000000000010000 =
0000000000000010=20
GPR16: 0000000000000000 0000000000000001 00000000000005a8 =
0000000000000d10=20
GPR20: 0000000000008000 c000000071d39608 0000000000000d10 =
00000000000002f0=20
GPR24: c000000000609844 00000000000102d0 0000000000000280 =
0000000000000280=20
GPR28: c000000000609844 4e375f30f9fae38f c000000000adb9c8 =
c00000007b002b00=20
NIP [c00000000016a330] .__kmalloc_track_caller+0x120/0x2ac
LR [c000000000608794] .__kmalloc_reserve+0x44/0xbc
Call Trace:
[c000000071b83570] [c00000000016a370] =
.__kmalloc_track_caller+0x160/0x2ac (unreliable)
[c000000071b83620] [c000000000608794] .__kmalloc_reserve+0x44/0xbc
[c000000071b836c0] [c000000000609844] .__alloc_skb+0xb8/0x1d0
[c000000071b83780] [c00000000065418c] .sk_stream_alloc_skb+0x48/0x154
[c000000071b83810] [c000000000655308] .tcp_sendpage+0x1d0/0x7a0
[c000000071b83920] [c00000000067b864] .inet_sendpage+0x100/0x158
[c000000071b839d0] [c0000000005fb294] .kernel_sendpage+0x7c/0xc8
[c000000071b83a70] [c0000000006b72b4] .svc_send_common+0xc8/0x1a8
[c000000071b83b40] [c0000000006b74c8] .svc_sendto+0x134/0x15c
[c000000071b83c40] [c0000000006b7590] .svc_tcp_sendto+0x3c/0xc0
[c000000071b83cd0] [c0000000006c46dc] .svc_send+0xb0/0x118
[c000000071b83d70] [c0000000006b41a0] .svc_process+0x784/0x7c0
[c000000071b83e40] [d000000003032e34] .nfsd+0x138/0x1ec [nfsd]
[c000000071b83ed0] [c00000000009d050] .kthread+0xb0/0xbc
[c000000071b83f90] [c00000000001e9b0] .kernel_thread+0x54/0x70
Instruction dump:
2bbf0010 41fd000c 7fe3fb78 48000180 e92d0040 e97f0000 7ceb4a14 e9070008=20=
7fab482a 2fbd0000 419e0034 e81f0022 <7f7d002a> 38000000 886d01f2 =
980d01f2=20
---[ end trace 9af22fc4dfe9499b ]---
Unable to handle kernel paging request for data at address =
0x4e375f30f9fae38f
Faulting instruction address: 0xc00000000016a330
Oops: Kernel access of bad area, sig: 11 [#2]
PREEMPT SMP NR_CPUS=3D32 Maple
Modules linked in: nfsd autofs4 exportfs binfmt_misc tg3 uninorth_agp =
agpgart hwmon
NIP: c00000000016a330 LR: c000000000608794 CTR: c0000000006a1b7c
REGS: c000000079e1b300 TRAP: 0300 Tainted: G D =
(3.6.0-rc1-00220-gb645f8b)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 24082444 XER: =
20000000
SOFTE: 1
DAR: 4e375f30f9fae38f, DSISR: 40000000
TASK =3D c000000073d80000[10885] 'dhcpcd' THREAD: c000000079e18000 CPU: =
3
GPR00: 0000000000000000 c000000079e1b580 c000000000b8e2a8 =
0000000000000300=20
GPR04: 00000000000106d0 c000000000609844 c000000000601c60 =
c000000000ec55e0=20
GPR08: 000000000036ac63 0000000000477000 c000000000a91758 =
c000000000a4e5e0=20
GPR12: 0000000000000000 c00000000fff2680 00000000201e6ad8 =
c000000079e1b930=20
GPR16: 0000000000000158 0000000000000000 0000000000000001 =
0000000000000004=20
GPR20: c000000079e1b818 c0000000711350f8 c0000000711350c0 =
0000000000000000=20
GPR24: c000000000609844 00000000000106d0 0000000000000300 =
0000000000000300=20
GPR28: c000000000609844 4e375f30f9fae38f c000000000adb9c8 =
c00000007b002b00=20
NIP [c00000000016a330] .__kmalloc_track_caller+0x120/0x2ac
LR [c000000000608794] .__kmalloc_reserve+0x44/0xbc
Call Trace:
[c000000079e1b630] [c000000000608794] .__kmalloc_reserve+0x44/0xbc
[c000000079e1b6d0] [c000000000609844] .__alloc_skb+0xb8/0x1d0
[c000000079e1b790] [c000000000601c60] .sock_alloc_send_pskb+0x124/0x410
[c000000079e1b8c0] [c0000000006a246c] .packet_sendmsg+0x8f0/0xc48
[c000000079e1ba10] [c0000000005fc024] .sock_sendmsg+0xbc/0x100
[c000000079e1bc10] [c0000000005fca54] .SyS_sendto+0xf4/0x13c
[c000000079e1bd90] [c00000000063321c] .compat_sys_socketcall+0x16c/0x288
[c000000079e1be30] [c0000000000098e0] syscall_exit+0x0/0x94
Instruction dump:
2bbf0010 41fd000c 7fe3fb78 48000180 e92d0040 e97f0000 7ceb4a14 e9070008=20=
7fab482a 2fbd0000 419e0034 e81f0022 <7f7d002a> 38000000 886d01f2 =
980d01f2=20
---[ end trace 9af22fc4dfe9499c ]---
Unable to handle kernel paging request for data at address =
0x4e375f30f9fae38f
Faulting instruction address: 0xc00000000016a330
Oops: Kernel access of bad area, sig: 11 [#3]
PREEMPT SMP NR_CPUS=3D32 Maple
Modules linked in: nfsd autofs4 exportfs binfmt_misc tg3 uninorth_agp =
agpgart hwmon
NIP: c00000000016a330 LR: c000000000608794 CTR: 0000000000000000
REGS: c000000079e5b290 TRAP: 0300 Tainted: G D =
(3.6.0-rc1-00220-gb645f8b)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 24024244 XER: =
20000000
SOFTE: 1
DAR: 4e375f30f9fae38f, DSISR: 40000000
TASK =3D c000000079bc1a30[4552] 'console-kit-dae' THREAD: =
c000000079e58000 CPU: 3
GPR00: 0000000000000000 c000000079e5b510 c000000000b8e2a8 =
0000000000000280=20
GPR04: 00000000000106d0 c000000000609844 c000000000601c60 =
c000000000ec55e0=20
GPR08: 000000000036ac63 0000000000477000 c000000000a91758 =
c000000000a4e5e0=20
GPR12: 100000000000d032 c00000000fff2680 0000000010146d80 =
c000000079e5b8c0=20
GPR16: 0000000000000094 0000000000000000 0000000000000001 =
0000000000000004=20
GPR20: c000000079e5b7a8 c000000077e02af8 c000000077e02ac0 =
0000000000000000=20
GPR24: c000000000609844 00000000000106d0 0000000000000280 =
0000000000000280=20
GPR28: c000000000609844 4e375f30f9fae38f c000000000adb9c8 =
c00000007b002b00=20
NIP [c00000000016a330] .__kmalloc_track_caller+0x120/0x2ac
LR [c000000000608794] .__kmalloc_reserve+0x44/0xbc
Call Trace:
[c000000079e5b510] [c000000079e58080] 0xc000000079e58080 (unreliable)
[c000000079e5b5c0] [c000000000608794] .__kmalloc_reserve+0x44/0xbc
[c000000079e5b660] [c000000000609844] .__alloc_skb+0xb8/0x1d0
[c000000079e5b720] [c000000000601c60] .sock_alloc_send_pskb+0x124/0x410
[c000000079e5b850] [c00000000069e284] .unix_stream_sendmsg+0x190/0x4e0
[c000000079e5b970] [c0000000005fb130] .sock_aio_write+0x16c/0x1a4
[c000000079e5baa0] [c000000000172bcc] .do_sync_readv_writev+0xb4/0x124
[c000000079e5bc40] [c0000000001c9070] .compat_do_readv_writev+0xf4/0x21c
[c000000079e5bd80] [c0000000001c932c] .compat_sys_writev+0x8c/0xe0
[c000000079e5be30] [c0000000000098e0] syscall_exit+0x0/0x94
Instruction dump:
2bbf0010 41fd000c 7fe3fb78 48000180 e92d0040 e97f0000 7ceb4a14 e9070008=20=
7fab482a 2fbd0000 419e0034 e81f0022 <7f7d002a> 38000000 886d01f2 =
980d01f2=20
---[ end trace 9af22fc4dfe9499d ]---
Unable to handle kernel paging request for data at address =
0x4e375f30f9fae38f
Faulting instruction address: 0xc00000000016a330
Oops: Kernel access of bad area, sig: 11 [#4]
PREEMPT SMP NR_CPUS=3D32 Maple
Modules linked in: nfsd autofs4 exportfs binfmt_misc tg3 uninorth_agp =
agpgart hwmon
NIP: c00000000016a330 LR: c000000000608794 CTR: c00000000063fe78
REGS: c000000077e2b470 TRAP: 0300 Tainted: G D =
(3.6.0-rc1-00220-gb645f8b)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 24000084 XER: =
20000000
SOFTE: 1
DAR: 4e375f30f9fae38f, DSISR: 40000000
TASK =3D c000000072df1a30[24367] 'kworker/3:2' THREAD: c000000077e28000 =
CPU: 3
GPR00: 0000000000000000 c000000077e2b6f0 c000000000b8e2a8 =
0000000000000280=20
GPR04: 0000000000010220 c000000000609844 c000000000665550 =
c000000000ec55e0=20
GPR08: 000000000036ac63 0000000000477000 c000000000a91758 =
c000000000a4e5e0=20
GPR12: c00000007b0c7c70 c00000000fff2680 0000000000051b63 =
0000000000051a41=20
GPR16: 0000000000051b5b 0000000000d00000 c00000000090f038 =
c00000000092eca7=20
GPR20: 0000000000000001 c000000077e2be58 c000000000ec6c05 =
0000000000000000=20
GPR24: c000000000609844 0000000000010220 0000000000000280 =
0000000000000280=20
GPR28: c000000000609844 4e375f30f9fae38f c000000000adb9c8 =
c00000007b002b00=20
NIP [c00000000016a330] .__kmalloc_track_caller+0x120/0x2ac
LR [c000000000608794] .__kmalloc_reserve+0x44/0xbc
Call Trace:
[c000000077e2b6f0] [c000000077e2b770] 0xc000000077e2b770 (unreliable)
[c000000077e2b7a0] [c000000000608794] .__kmalloc_reserve+0x44/0xbc
[c000000077e2b840] [c000000000609844] .__alloc_skb+0xb8/0x1d0
[c000000077e2b900] [c000000000665550] .tcp_send_fin+0x90/0x210
[c000000077e2b990] [c000000000652f84] .tcp_close+0x260/0x4f4
[c000000077e2ba30] [c00000000067c1fc] .inet_release+0xd0/0xf4
[c000000077e2bac0] [c0000000005ff0d0] .sock_release+0x4c/0xf0
[c000000077e2bb50] [c0000000006ac94c] .xs_reset_transport+0x9c/0xc4
[c000000077e2bbf0] [c0000000006ac98c] .xs_close+0x18/0x88
[c000000077e2bc80] [c0000000006a9500] .xprt_autoclose+0x40/0xbc
[c000000077e2bd10] [c000000000094360] .process_one_work+0x34c/0x56c
[c000000077e2bdd0] [c000000000094b88] .worker_thread+0x32c/0x4b8
[c000000077e2bed0] [c00000000009d050] .kthread+0xb0/0xbc
[c000000077e2bf90] [c00000000001e9b0] .kernel_thread+0x54/0x70
Instruction dump:
2bbf0010 41fd000c 7fe3fb78 48000180 e92d0040 e97f0000 7ceb4a14 e9070008=20=
7fab482a 2fbd0000 419e0034 e81f0022 <7f7d002a> 38000000 886d01f2 =
980d01f2=20
---[ end trace 9af22fc4dfe9499e ]---
Unable to handle kernel paging request for data at address =
0xfffffffffffffff8
Faulting instruction address: 0xc00000000009c9e8
Oops: Kernel access of bad area, sig: 11 [#5]
PREEMPT SMP NR_CPUS=3D32 Maple
Modules linked in: nfsd autofs4 exportfs binfmt_misc tg3 uninorth_agp =
agpgart hwmon
NIP: c00000000009c9e8 LR: c000000000097cf0 CTR: c0000000000b4ea0
REGS: c000000077e2ac70 TRAP: 0300 Tainted: G D =
(3.6.0-rc1-00220-gb645f8b)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 44000042 XER: =
00000000
SOFTE: 0
DAR: fffffffffffffff8, DSISR: 40010000
TASK =3D c000000072df1a30[24367] 'kworker/3:2' THREAD: c000000077e28000 =
CPU: 3
GPR00: c0000000006d1c3c c000000077e2aef0 c000000000b8e2a8 =
c000000072df1a30=20
GPR04: 0000000000000003 0000000000000001 0000000000000000 =
c000000000a50370=20
GPR08: 000000898953db8d 0000000000000000 0000000000000000 =
0000000000000001=20
GPR12: c00000007b0c7c70 c00000000fff2680 0000000000051b63 =
0000000000051a41=20
GPR16: 0000000000051b5b 0000000000000001 0000000000000004 =
c000000077e2aff0=20
GPR20: c00000000007b7a0 c000000077e28080 0000000000000000 =
c000000077e28000=20
GPR24: 0000000000000003 c000000000ec4800 c000000072df1cd0 =
c000000072df1db8=20
GPR28: 0000000000000003 c000000000ec4800 c000000000ad6338 =
c000000072df1a30=20
NIP [c00000000009c9e8] .kthread_data+0x4/0xc
LR [c000000000097cf0] .wq_worker_sleeping+0x20/0xd0
Call Trace:
[c000000077e2aef0] [c0000000000afac4] .dequeue_task+0xd0/0xf4 =
(unreliable)
[c000000077e2af80] [c0000000006d1c3c] .__schedule+0x1c4/0x888
[c000000077e2b1d0] [c00000000007b7a0] .do_exit+0x8b4/0x8c0
[c000000077e2b2d0] [c00000000001c310] .die+0x3b4/0x3e4
[c000000077e2b380] [c000000000033014] .bad_page_fault+0xf0/0x10c
[c000000077e2b400] [c000000000005c04] handle_page_fault+0x2c/0x30
--- Exception: 300 at .__kmalloc_track_caller+0x120/0x2ac
LR =3D .__kmalloc_reserve+0x44/0xbc
[c000000077e2b6f0] [c000000077e2b770] 0xc000000077e2b770 (unreliable)
[c000000077e2b7a0] [c000000000608794] .__kmalloc_reserve+0x44/0xbc
[c000000077e2b840] [c000000000609844] .__alloc_skb+0xb8/0x1d0
[c000000077e2b900] [c000000000665550] .tcp_send_fin+0x90/0x210
[c000000077e2b990] [c000000000652f84] .tcp_close+0x260/0x4f4
[c000000077e2ba30] [c00000000067c1fc] .inet_release+0xd0/0xf4
[c000000077e2bac0] [c0000000005ff0d0] .sock_release+0x4c/0xf0
[c000000077e2bb50] [c0000000006ac94c] .xs_reset_transport+0x9c/0xc4
[c000000077e2bbf0] [c0000000006ac98c] .xs_close+0x18/0x88
[c000000077e2bc80] [c0000000006a9500] .xprt_autoclose+0x40/0xbc
[c000000077e2bd10] [c000000000094360] .process_one_work+0x34c/0x56c
[c000000077e2bdd0] [c000000000094b88] .worker_thread+0x32c/0x4b8
[c000000077e2bed0] [c00000000009d050] .kthread+0xb0/0xbc
[c000000077e2bf90] [c00000000001e9b0] .kernel_thread+0x54/0x70
Instruction dump:
e8010010 eb61ffd8 eb81ffe0 eba1ffe8 ebe1fff8 7c0803a6 4e800020 e92d01c8=20=
e9290340 e869fff2 4e800020 e9230340 <e869fff8> 4e800020 38600000 =
4e800020=20
---[ end trace 9af22fc4dfe9499f ]---
Fixing recursive fault but reboot is needed!
=
##########################################################################=
##
# 3.6.0-rc3 =
#
=
##########################################################################=
##
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT SMP NR_CPUS=3D32 Maple
Modules linked in: nfsd autofs4 exportfs binfmt_misc tg3 uninorth_agp =
agpgart hwmon
NIP: c00000000016a570 LR: c000000000608fe4 CTR: c000000000640bc4
REGS: c0000000787e7170 TRAP: 0300 Not tainted =
(3.6.0-rc3-00363-g7d3c5fb-dirty)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 22002044 XER: =
20000000
SOFTE: 1
DAR: 4146dc88b8105444, DSISR: 40000000
TASK =3D c000000078613460[6321] 'nfsd' THREAD: c0000000787e4000 CPU: 2
GPR00: 0000000000000000 c0000000787e73f0 c000000000b90428 =
0000000000000280=20
GPR04: 0000000000010220 c00000000060a094 c000000000654f74 =
c000000000e855e0=20
GPR08: 000000000016e882 0000000000435000 c000000000a93758 =
c000000000a505e0=20
GPR12: 0000000042002042 c00000000fff1f00 0000000000000000 =
0000000000000000=20
GPR16: fffffffffffffff6 0000000000000000 0000000000000001 =
0000000000010000=20
GPR20: 00000000000005a8 0000000000000003 c00000007b755bf8 =
c00000007b755c08=20
GPR24: c00000000060a094 0000000000010220 0000000000000280 =
0000000000000280=20
GPR28: c00000000060a094 4146dc88b8105444 c000000000add9f8 =
c00000007b002b00=20
NIP [c00000000016a570] .__kmalloc_track_caller+0x120/0x2ac
LR [c000000000608fe4] .__kmalloc_reserve+0x44/0xbc
Call Trace:
[c0000000787e74a0] [c000000000608fe4] .__kmalloc_reserve+0x44/0xbc
[c0000000787e7540] [c00000000060a094] .__alloc_skb+0xb8/0x1d0
[c0000000787e7600] [c000000000654f74] .sk_stream_alloc_skb+0x48/0x154
[c0000000787e7690] [c0000000006660a4] .tcp_write_xmit+0x89c/0xb8c
[c0000000787e7790] [c000000000666408] =
.__tcp_push_pending_frames+0x40/0xb0
[c0000000787e7810] [c000000000656624] .tcp_sendpage+0x704/0x7a0
[c0000000787e7920] [c00000000067c744] .inet_sendpage+0x100/0x158
[c0000000787e79d0] [c0000000005fbad0] .kernel_sendpage+0x7c/0xc8
[c0000000787e7a70] [c0000000006b81f0] .svc_send_common+0xc8/0x1a8
[c0000000787e7b40] [c0000000006b8404] .svc_sendto+0x134/0x15c
[c0000000787e7c40] [c0000000006b84cc] .svc_tcp_sendto+0x3c/0xc0
[c0000000787e7cd0] [c0000000006c55f8] .svc_send+0xb8/0x128
[c0000000787e7d70] [c0000000006b50e4] .svc_process+0x784/0x7c0
[c0000000787e7e40] [d000000003033e34] .nfsd+0x138/0x1ec [nfsd]
[c0000000787e7ed0] [c00000000009d090] .kthread+0xb0/0xbc
[c0000000787e7f90] [c00000000001e9b0] .kernel_thread+0x54/0x70
Instruction dump:
2bbf0010 41fd000c 7fe3fb78 48000180 e92d0040 e97f0000 7ceb4a14 e9070008=20=
7fab482a 2fbd0000 419e0034 e81f0022 <7f7d002a> 38000000 886d01f2 =
980d01f2=20
---[ end trace 64544462a57c5991 ]---
Unable to handle kernel paging request for data at address =
0x4146dc88b8105444
Faulting instruction address: 0xc00000000016acc8
Oops: Kernel access of bad area, sig: 11 [#2]
PREEMPT SMP NR_CPUS=3D32 Maple
Modules linked in: nfsd autofs4 exportfs binfmt_misc tg3 uninorth_agp =
agpgart hwmon
NIP: c00000000016acc8 LR: c0000000001afe14 CTR: 0000000000000000
REGS: c00000007836eb50 TRAP: 0300 Tainted: G D =
(3.6.0-rc3-00363-g7d3c5fb-dirty)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 24000084 XER: =
20000000
SOFTE: 1
DAR: 4146dc88b8105444, DSISR: 40000000
TASK =3D c000000078eace90[6322] 'nfsd' THREAD: c00000007836c000 CPU: 2
GPR00: 0000000000000000 c00000007836edd0 c000000000b90428 =
c00000007b002b00=20
GPR04: 0000000000011280 c00000007836ef80 c00000007b004860 =
c000000000e855e0=20
GPR08: 000000000016e882 0000000000435000 c000000000a93758 =
c000000000a505e0=20
GPR12: 0000000024000084 c00000000fff1f00 c00000007836f298 =
c000000000b2d0d8=20
GPR16: 0000000000000000 c00000007836f150 000000000000000c =
c00000007a2980e0=20
GPR20: c00000007a550000 00000000008473f0 0000000000001000 =
000000000000000c=20
GPR24: c0000000001afe14 0000000000011280 00000000000000d0 =
c00000007b002b00=20
GPR28: c00000007b004860 4146dc88b8105444 c000000000add9f8 =
c00000007836ef80=20
NIP [c00000000016acc8] .kmem_cache_alloc+0x5c/0x1ec
LR [c0000000001afe14] .bvec_alloc_bs+0xe0/0x124
Call Trace:
[c00000007836edd0] [c00000007836ee60] 0xc00000007836ee60 (unreliable)
[c00000007836ee80] [c0000000001afe14] .bvec_alloc_bs+0xe0/0x124
[c00000007836ef10] [c0000000001afef4] .bio_alloc_bioset+0x9c/0x114
[c00000007836efc0] [c0000000001afffc] .bio_alloc+0x24/0x48
[c00000007836f040] [c0000000001b6260] .mpage_alloc+0x3c/0xbc
[c00000007836f0e0] [c0000000001b70e0] .do_mpage_readpage+0x508/0x668
[c00000007836f220] [c0000000001b73bc] .mpage_readpages+0xfc/0x198
[c00000007836f380] [c0000000002260dc] .ext3_readpages+0x28/0x40
[c00000007836f400] [c00000000012e544] =
.__do_page_cache_readahead+0x1b8/0x2c4
[c00000007836f520] [c00000000012e678] .ra_submit+0x28/0x38
[c00000007836f590] [c0000000001a62c0] =
.__generic_file_splice_read+0x260/0x4d4
[c00000007836f840] [c0000000001a6590] =
.generic_file_splice_read+0x5c/0xac
[c00000007836f8d0] [c0000000001a4544] .do_splice_to+0xb0/0xdc
[c00000007836f970] [c0000000001a4e68] .splice_direct_to_actor+0xd0/0x230
[c00000007836fa50] [d000000003038f0c] .nfsd_vfs_read+0xa4/0x1b0 [nfsd]
[c00000007836fb30] [d000000003039a7c] .nfsd_read+0x290/0x35c [nfsd]
[c00000007836fc30] [d000000003041f38] .nfsd3_proc_read+0xd4/0x12c [nfsd]
[c00000007836fcd0] [d000000003033528] .nfsd_dispatch+0xd4/0x1fc [nfsd]
[c00000007836fd70] [c0000000006b4e54] .svc_process+0x4f4/0x7c0
[c00000007836fe40] [d000000003033e34] .nfsd+0x138/0x1ec [nfsd]
[c00000007836fed0] [c00000000009d090] .kthread+0xb0/0xbc
[c00000007836ff90] [c00000000001e9b0] .kernel_thread+0x54/0x70
Instruction dump:
f821ff51 ebc2b608 7c7b1b78 7c992378 e92d0040 e97b0000 7ceb4a14 e9070008=20=
7fab482a 2fbd0000 419e0034 e81b0022 <7f9d002a> 38000000 886d01f2 =
980d01f2=20
---[ end trace 64544462a57c5992 ]---
Unable to handle kernel paging request for data at address =
0x4146dc88b8105444
Faulting instruction address: 0xc00000000016a570
Oops: Kernel access of bad area, sig: 11 [#3]
PREEMPT SMP NR_CPUS=3D32 Maple
Modules linked in: nfsd autofs4 exportfs binfmt_misc tg3 uninorth_agp =
agpgart hwmon
NIP: c00000000016a570 LR: c000000000608fe4 CTR: c0000000006a2ab8
REGS: c000000077fe3300 TRAP: 0300 Tainted: G D =
(3.6.0-rc3-00363-g7d3c5fb-dirty)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 24082444 XER: =
20000000
SOFTE: 1
DAR: 4146dc88b8105444, DSISR: 40000000
TASK =3D c000000077ccb460[7508] 'dhcpcd' THREAD: c000000077fe0000 CPU: 2
GPR00: 0000000000000000 c000000077fe3580 c000000000b90428 =
0000000000000300=20
GPR04: 00000000000106d0 c00000000060a094 c0000000006024a4 =
c000000000e855e0=20
GPR08: 000000000016e882 0000000000435000 c000000000a93758 =
c000000000a505e0=20
GPR12: 0000000000000000 c00000000fff1f00 0000000020107ad8 =
c000000077fe3930=20
GPR16: 0000000000000158 0000000000000000 0000000000000001 =
0000000000000004=20
GPR20: c000000077fe3818 c00000007869e0f8 c00000007869e0c0 =
0000000000000000=20
GPR24: c00000000060a094 00000000000106d0 0000000000000300 =
0000000000000300=20
GPR28: c00000000060a094 4146dc88b8105444 c000000000add9f8 =
c00000007b002b00=20
NIP [c00000000016a570] .__kmalloc_track_caller+0x120/0x2ac
LR [c000000000608fe4] .__kmalloc_reserve+0x44/0xbc
Call Trace:
[c000000077fe3630] [c000000000608fe4] .__kmalloc_reserve+0x44/0xbc
[c000000077fe36d0] [c00000000060a094] .__alloc_skb+0xb8/0x1d0
[c000000077fe3790] [c0000000006024a4] .sock_alloc_send_pskb+0x124/0x410
[c000000077fe38c0] [c0000000006a33a8] .packet_sendmsg+0x8f0/0xc48
[c000000077fe3a10] [c0000000005fc860] .sock_sendmsg+0xbc/0x100
[c000000077fe3c10] [c0000000005fd290] .SyS_sendto+0xf4/0x13c
[c000000077fe3d90] [c000000000633f08] .compat_sys_socketcall+0x16c/0x288
[c000000077fe3e30] [c0000000000098e0] syscall_exit+0x0/0x94
Instruction dump:
2bbf0010 41fd000c 7fe3fb78 48000180 e92d0040 e97f0000 7ceb4a14 e9070008=20=
7fab482a 2fbd0000 419e0034 e81f0022 <7f7d002a> 38000000 886d01f2 =
980d01f2=20
---[ end trace 64544462a57c5993 ]---
Unable to handle kernel paging request for data at address =
0x4146dc88b8105444
Faulting instruction address: 0xc00000000016a570
Oops: Kernel access of bad area, sig: 11 [#4]
PREEMPT SMP NR_CPUS=3D32 Maple
Modules linked in: nfsd autofs4 exportfs binfmt_misc tg3 uninorth_agp =
agpgart hwmon
NIP: c00000000016a570 LR: c000000000608fe4 CTR: 0000000000000000
REGS: c000000077f4b290 TRAP: 0300 Tainted: G D =
(3.6.0-rc3-00363-g7d3c5fb-dirty)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 24024244 XER: =
20000000
SOFTE: 1
DAR: 4146dc88b8105444, DSISR: 40000000
TASK =3D c00000007b348000[4536] 'console-kit-dae' THREAD: =
c000000077f48000 CPU: 2
GPR00: 0000000000000000 c000000077f4b510 c000000000b90428 =
0000000000000280=20
GPR04: 00000000000106d0 c00000000060a094 c0000000006024a4 =
c000000000e855e0=20
GPR08: 000000000016e882 0000000000435000 c000000000a93758 =
c000000000a505e0=20
GPR12: 100000000000d032 c00000000fff1f00 00000000102f4db0 =
c000000077f4b8c0=20
GPR16: 0000000000000094 0000000000000000 0000000000000001 =
0000000000000004=20
GPR20: c000000077f4b7a8 c0000000782a0ef8 c0000000782a0ec0 =
0000000000000000=20
GPR24: c00000000060a094 00000000000106d0 0000000000000280 =
0000000000000280=20
GPR28: c00000000060a094 4146dc88b8105444 c000000000add9f8 =
c00000007b002b00=20
NIP [c00000000016a570] .__kmalloc_track_caller+0x120/0x2ac
LR [c000000000608fe4] .__kmalloc_reserve+0x44/0xbc
Call Trace:
[c000000077f4b510] [c000000077f48080] 0xc000000077f48080 (unreliable)
[c000000077f4b5c0] [c000000000608fe4] .__kmalloc_reserve+0x44/0xbc
[c000000077f4b660] [c00000000060a094] .__alloc_skb+0xb8/0x1d0
[c000000077f4b720] [c0000000006024a4] .sock_alloc_send_pskb+0x124/0x410
[c000000077f4b850] [c00000000069f1e8] .unix_stream_sendmsg+0x190/0x4e0
[c000000077f4b970] [c0000000005fb96c] .sock_aio_write+0x16c/0x1a4
[c000000077f4baa0] [c000000000172e40] .do_sync_readv_writev+0xb4/0x124
[c000000077f4bc40] [c0000000001c9354] .compat_do_readv_writev+0xf4/0x21c
[c000000077f4bd80] [c0000000001c9618] .compat_sys_writev+0x94/0xf0
[c000000077f4be30] [c0000000000098e0] syscall_exit+0x0/0x94
Instruction dump:
2bbf0010 41fd000c 7fe3fb78 48000180 e92d0040 e97f0000 7ceb4a14 e9070008=20=
7fab482a 2fbd0000 419e0034 e81f0022 <7f7d002a> 38000000 886d01f2 =
980d01f2=20
---[ end trace 64544462a57c5994 ]---
Unable to handle kernel paging request for data at address =
0x4146dc88b8105444
Faulting instruction address: 0xc00000000016acc8
Oops: Kernel access of bad area, sig: 11 [#5]
PREEMPT SMP NR_CPUS=3D32 Maple
Modules linked in: nfsd autofs4 exportfs binfmt_misc tg3 uninorth_agp =
agpgart hwmon
NIP: c00000000016acc8 LR: c000000000072738 CTR: 0000000000000000
REGS: c00000007b0ab3a0 TRAP: 0300 Tainted: G D =
(3.6.0-rc3-00363-g7d3c5fb-dirty)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 24002024 XER: =
00000000
SOFTE: 1
DAR: 4146dc88b8105444, DSISR: 40000000
TASK =3D c00000007b099a30[6] 'kworker/u:0' THREAD: c00000007b0a8000 CPU: =
2
GPR00: 0000000000000000 c00000007b0ab620 c000000000b90428 =
c00000007b002b00=20
GPR04: 00000000000080d0 0000000000000000 0000000000000000 =
c000000000e855e0=20
GPR08: 000000000016e882 0000000000435000 c000000000a93758 =
c000000000a505e0=20
GPR12: 0000000084002022 c00000000fff1f00 0000000000051b63 =
0000000000051a41=20
GPR16: 0000000000000000 0000000000000000 c00000007b0ab990 =
c00000007b0abc10=20
GPR20: 0000000000000000 c0000000000134f4 c0000000780bd140 =
0000000000000000=20
GPR24: c000000000072738 00000000000080d0 c000000000cb7b80 =
c00000007b002b00=20
GPR28: c0000000780bce90 4146dc88b8105444 c000000000add9f8 =
c000000000a61468=20
NIP [c00000000016acc8] .kmem_cache_alloc+0x5c/0x1ec
LR [c000000000072738] .copy_process+0x634/0x1114
Call Trace:
[c00000007b0ab620] [c00000000016ad48] .kmem_cache_alloc+0xdc/0x1ec =
(unreliable)
[c00000007b0ab6d0] [c000000000072738] .copy_process+0x634/0x1114
[c00000007b0ab7d0] [c000000000073510] .do_fork+0x118/0x400
[c00000007b0ab8b0] [c000000000012d14] .sys_clone+0x58/0x70
[c00000007b0ab920] [c000000000009b08] .ppc_clone+0x8/0xc
--- Exception: c00 at .kernel_thread+0x28/0x70
LR =3D .__call_usermodehelper+0x50/0x11c
[c00000007b0abc10] [c00000007b0abc90] 0xc00000007b0abc90 (unreliable)
[c00000007b0abc80] [c00000007b0abd10] 0xc00000007b0abd10
[c00000007b0abd10] [c000000000094370] .process_one_work+0x34c/0x56c
[c00000007b0abdd0] [c000000000094b98] .worker_thread+0x32c/0x4b8
[c00000007b0abed0] [c00000000009d090] .kthread+0xb0/0xbc
[c00000007b0abf90] [c00000000001e9b0] .kernel_thread+0x54/0x70
Instruction dump:
f821ff51 ebc2b608 7c7b1b78 7c992378 e92d0040 e97b0000 7ceb4a14 e9070008=20=
7fab482a 2fbd0000 419e0034 e81b0022 <7f9d002a> 38000000 886d01f2 =
980d01f2=20
---[ end trace 64544462a57c5995 ]---
Unable to handle kernel paging request for data at address =
0xfffffffffffffff8
=
##########################################################################=
##
# 3.6.0-rc5 =
#
=
##########################################################################=
##
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT SMP NR_CPUS=3D32 Maple
Modules linked in: nfsd autofs4 exportfs binfmt_misc tg3 hwmon =
uninorth_agp agpgart
NIP: c0000000001b6a40 LR: c0000000001ade18 CTR: c0000000001b69b0
REGS: c00000000ffdf600 TRAP: 0300 Not tainted =
(3.6.0-rc5-00153-g518cd6a)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 28ff4f48 XER: =
00000000
SOFTE: 1
DAR: e0d668aeabc0e0eb, DSISR: 40000000
TASK =3D c00000007b0bb460[0] 'swapper/3' THREAD: c00000007b0c4000 CPU: 3
GPR00: 0000000000000000 c00000000ffdf880 c000000000b90460 =
e0d668aeabc0e0eb=20
GPR04: 0000000000000000 0000000000040000 0000000000040000 =
000000000000ba41=20
GPR08: 0000000000000200 0000000000000000 0000000000000001 =
c0000000786d3800=20
GPR12: 0000000048ffff48 c00000000fff2680 c00000007b0c7f90 =
0000000000000000=20
GPR16: 0000000000000000 0000000000000000 0000000000000000 =
0000000000200040=20
GPR20: c000000000a4f680 0000000000000003 c00000007872b170 =
0000000000000000=20
GPR24: 0000000000000000 0000000000040000 0000000002000000 =
0000000000000002=20
GPR28: 0000000000000008 c00000007929ce00 c000000000ae86f0 =
c0000000786d3be0=20
NIP [c0000000001b6a40] .mpage_end_io+0x90/0x150
LR [c0000000001ade18] .bio_endio+0x64/0x78
Call Trace:
[c00000000ffdf880] [c00000007872b170] 0xc00000007872b170 (unreliable)
[c00000000ffdf920] [c0000000001ade18] .bio_endio+0x64/0x78
[c00000000ffdf990] [c0000000003617b4] .req_bio_endio+0xe0/0x104
[c00000000ffdfa20] [c000000000361a64] .blk_update_request+0x28c/0x568
[c00000000ffdfae0] [c000000000361d68] .blk_update_bidi_request+0x28/0x98
[c00000000ffdfb70] [c00000000036396c] .blk_end_bidi_request+0x2c/0x8c
[c00000000ffdfc10] [c0000000004944e8] .scsi_io_completion+0x22c/0x5b8
[c00000000ffdfce0] [c00000000048c258] .scsi_finish_command+0xfc/0x120
[c00000000ffdfd80] [c0000000004949b4] .scsi_softirq_done+0x138/0x15c
[c00000000ffdfe10] [c00000000036a3ac] .blk_done_softirq+0xc4/0xf8
[c00000000ffdfeb0] [c00000000007ed50] .__do_softirq+0x1c8/0x398
[c00000000ffdff90] [c00000000001e6c8] .call_do_softirq+0x14/0x24
[c00000007b0c78f0] [c00000000000f51c] .do_softirq+0xac/0x154
[c00000007b0c7990] [c00000000007e7e4] .irq_exit+0x94/0x14c
[c00000007b0c7a20] [c00000000000f0b8] .do_IRQ+0x278/0x340
[c00000007b0c7ae0] [c000000000003b78] =
hardware_interrupt_common+0x178/0x180
--- Exception: 501 at .arch_local_irq_restore+0x74/0x98
LR =3D .arch_local_irq_restore+0x74/0x98
[c00000007b0c7dd0] [c00000000000f438] .arch_local_irq_restore+0x60/0x98 =
(unreliable)
[c00000007b0c7e40] [c000000000015144] .cpu_idle+0x18c/0x2bc
[c00000007b0c7ee0] [c0000000006da7ac] .start_secondary+0x378/0x384
[c00000007b0c7f90] [c0000000000093f0] .start_secondary_prolog+0x10/0x14
Instruction dump:
3bfffff0 7fbf0040 419c0014 e81f0000 2fa00000 419e0008 7c0001ec e81d0020=20=
780907e1 4082004c 4192001c 7c2004ac <7c0018a8> 7c00e378 7c0019ad =
40c2fff4=20
---[ end trace 21d19d3ed703ad1c ]---
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 9 seconds..
=
##########################################################################=
##
# 3.6.0-rc7 =
#
=
##########################################################################=
##
Oops: Kernel access of bad area, sig: 11 [#1]
PREEMPT SMP NR_CPUS=3D32 Maple
Modules linked in: nfsd autofs4 exportfs binfmt_misc uninorth_agp tg3 =
agpgart hwmon
NIP: c00000000016a5bc LR: c00000000060910c CTR: c000000000640ca8
REGS: c00000007918b170 TRAP: 0300 Not tainted =
(3.6.0-rc7-00128-ge333037)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 22002048 XER: =
20000000
SOFTE: 1
DAR: ce66ff186f457e7b, DSISR: 40010000
TASK =3D c000000079f18000[5953] 'nfsd' THREAD: c000000079188000 CPU: 3
GPR00: 0000000000000000 c00000007918b3f0 c000000000b914b0 =
0000000000000280=20
GPR04: 0000000000010220 c00000000060a1bc c000000000654f30 =
c000000000ec55e0=20
GPR08: 0000000000035f23 0000000000474000 c000000000a94758 =
c000000000a515e0=20
GPR12: 0000000042002048 c00000000fff2680 0000000000000000 =
0000000000000000=20
GPR16: fffffffffffffff6 0000000000000000 0000000000000001 =
0000000000010000=20
GPR20: 00000000000005a8 0000000000000003 c00000007b5962f8 =
c00000007b596308=20
GPR24: c00000000060a1bc 0000000000010220 0000000000000280 =
0000000000000280=20
GPR28: c00000000060a1bc ce66ff186f457e7b c000000000ade9d0 =
c00000007b002b00=20
NIP [c00000000016a5bc] .__kmalloc_track_caller+0x120/0x2ac
LR [c00000000060910c] .__kmalloc_reserve+0x44/0xbc
Call Trace:
[c00000007918b3f0] [c00000000016a63c] =
.__kmalloc_track_caller+0x1a0/0x2ac (unreliable)
[c00000007918b4a0] [c00000000060910c] .__kmalloc_reserve+0x44/0xbc
[c00000007918b540] [c00000000060a1bc] .__alloc_skb+0xb8/0x1d0
[c00000007918b600] [c000000000654f30] .sk_stream_alloc_skb+0x48/0x154
[c00000007918b690] [c000000000666070] .tcp_write_xmit+0x89c/0xb8c
[c00000007918b790] [c0000000006663d4] =
.__tcp_push_pending_frames+0x40/0xb0
[c00000007918b810] [c0000000006565e0] .tcp_sendpage+0x704/0x7a0
[c00000007918b920] [c00000000067c788] .inet_sendpage+0x100/0x158
[c00000007918b9d0] [c0000000005fbbac] .kernel_sendpage+0x7c/0xc8
[c00000007918ba70] [c0000000006b8328] .svc_send_common+0xc8/0x1a8
[c00000007918bb40] [c0000000006b853c] .svc_sendto+0x134/0x15c
[c00000007918bc40] [c0000000006b8604] .svc_tcp_sendto+0x3c/0xc0
[c00000007918bcd0] [c0000000006c5730] .svc_send+0xb8/0x128
[c00000007918bd70] [c0000000006b521c] .svc_process+0x784/0x7c0
[c00000007918be40] [d000000003033e34] .nfsd+0x138/0x1ec [nfsd]
[c00000007918bed0] [c00000000009d040] .kthread+0xb0/0xbc
[c00000007918bf90] [c00000000001e9d0] .kernel_thread+0x54/0x70
Instruction dump:
2bbf0010 41fd000c 7fe3fb78 48000180 e92d0040 e97f0000 7ceb4a14 e9070008=20=
7fab482a 2fbd0000 419e0034 e81f0022 <7f7d002a> 38000000 886d01f2 =
980d01f2=20
---[ end trace fe59661bbe31413f ]---
Unable to handle kernel paging request for data at address =
0xce66ff186f457e7b
Faulting instruction address: 0xc00000000016a5bc
Oops: Kernel access of bad area, sig: 11 [#2]
PREEMPT SMP NR_CPUS=3D32 Maple
Modules linked in: nfsd autofs4 exportfs binfmt_misc uninorth_agp tg3 =
agpgart hwmon
NIP: c00000000016a5bc LR: c00000000060910c CTR: c0000000006a2b68
REGS: c00000007b6c3300 TRAP: 0300 Tainted: G D =
(3.6.0-rc7-00128-ge333037)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 24082448 XER: =
20000000
SOFTE: 1
DAR: ce66ff186f457e7b, DSISR: 40010000
TASK =3D c0000000797a3460[5195] 'dhcpcd' THREAD: c00000007b6c0000 CPU: 3
GPR00: 0000000000000000 c00000007b6c3580 c000000000b914b0 =
0000000000000300=20
GPR04: 00000000000106d0 c00000000060a1bc c000000000602580 =
c000000000ec55e0=20
GPR08: 0000000000035f63 0000000000474000 c000000000a94758 =
c000000000a515e0=20
GPR12: 0000000000000000 c00000000fff2680 0000000020170ad8 =
c00000007b6c3930=20
GPR16: 0000000000000158 0000000000000000 0000000000000001 =
0000000000000004=20
GPR20: c00000007b6c3818 c0000000782c88f8 c0000000782c88c0 =
0000000000000000=20
GPR24: c00000000060a1bc 00000000000106d0 0000000000000300 =
0000000000000300=20
GPR28: c00000000060a1bc ce66ff186f457e7b c000000000ade9d0 =
c00000007b002b00=20
NIP [c00000000016a5bc] .__kmalloc_track_caller+0x120/0x2ac
LR [c00000000060910c] .__kmalloc_reserve+0x44/0xbc
Call Trace:
[c00000007b6c3630] [c00000000060910c] .__kmalloc_reserve+0x44/0xbc
[c00000007b6c36d0] [c00000000060a1bc] .__alloc_skb+0xb8/0x1d0
[c00000007b6c3790] [c000000000602580] .sock_alloc_send_pskb+0x124/0x410
[c00000007b6c38c0] [c0000000006a3458] .packet_sendmsg+0x8f0/0xc48
[c00000007b6c3a10] [c0000000005fc93c] .sock_sendmsg+0xbc/0x100
[c00000007b6c3c10] [c0000000005fd36c] .SyS_sendto+0xf4/0x13c
[c00000007b6c3d90] [c000000000633fc4] .compat_sys_socketcall+0x16c/0x288
[c00000007b6c3e30] [c0000000000098e0] syscall_exit+0x0/0x94
Instruction dump:
2bbf0010 41fd000c 7fe3fb78 48000180 e92d0040 e97f0000 7ceb4a14 e9070008=20=
7fab482a 2fbd0000 419e0034 e81f0022 <7f7d002a> 38000000 886d01f2 =
980d01f2=20
---[ end trace fe59661bbe314140 ]---
^ permalink raw reply
* Re: [RFC v9 PATCH 00/21] memory-hotplug: hot-remove physical memory
From: Wen Congyang @ 2012-09-28 1:41 UTC (permalink / raw)
To: Vasilis Liaskovitis
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, isimatu.yasuaki, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, cl,
linuxppc-dev, akpm, liuj97
In-Reply-To: <20120927103557.GA30772@dhcp-192-168-178-175.profitbricks.localdomain>
At 09/27/2012 06:35 PM, Vasilis Liaskovitis Wrote:
> On Thu, Sep 27, 2012 at 02:37:14PM +0800, Wen Congyang wrote:
>> Hi Vasilis Liaskovitis
>>
>> At 09/27/2012 12:46 AM, Vasilis Liaskovitis Wrote:
>>> Hi,
>>>
>>> I am testing 3.6.0-rc7 with this v9 patchset plus more recent fixes [1],[2],[3]
>>> Running in a guest (qemu+seabios from [4]).
>>> CONFIG_SLAB=y
>>> CONFIG_DEBUG_SLAB=y
>>>
>>> After succesfull hot-add and online, I am doing a hot-remove with "echo 1 > /sys/bus/acpi/devices/PNP/eject"
>>> When I do the OSPM-eject, I often get slab corruption in "acpi-state" cache, or in other caches
>>
>> I can't reproduce this problem. Can you provide the following information:
>> 1. config file
>> 2. qemu's command line
>>
>> You said you did OSPM-eject. Do you mean write 1 to /sys/bus/acpi/devices/PNP0C80:XX/eject?
> yes.
>
> example qemu command line with one dimm:
>
> "/opt/qemu-kvm-memhp/bin/qemu-system-x86_64 -bios
> /opt/extra/vliaskov/devel/seabios-upstream/out/bios.bin -enable-kvm -M pc -smp
> 4,maxcpus=8 -cpu host -m 2048 -drive file=/opt/extra/debian-template.raw,if=none,id=drive-virtio-disk0,format=raw
> -device virtio-blk-pci,bus=pci.0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
> -vga cirrus -netdev type=tap,id=guest0,vhost=on -device virtio-net-pci,netdev=guest0
> -monitor unix:/tmp/qemu.monitor11,server,nowait -chardev stdio,id=seabios -device
> isa-debugcon,iobase=0x402,chardev=seabios
> -dimm id=n0,size=512M,node=0"
>
> or last line with 2 numa nodes:
> "-dimm id=n0,size=512M,node=0 -dimm id=n1,size=512M,node=1 -numa node,nodeid=0 -numa node,nodeid=1"
I have reproduced this problem. It only can be reproduced when the dimm's memory is on node 0.
I investigate it now.
Thanks
Wen Congyang
>
> attached config. Tree is at:
> https://github.com/vliaskov/linux/commits/memhp-fujitsu
>
> thanks,
> - Vasilis
^ permalink raw reply
* Re: [REGRESSION] nfsd crashing with 3.6.0-rc7 on PowerPC
From: Linus Torvalds @ 2012-09-28 2:04 UTC (permalink / raw)
To: Alexander Graf
Cc: linux-nfs, skinsbursky, LKML List, Jan Kara, bfields,
linuxppc-dev
In-Reply-To: <3BDA9E62-7031-42D6-8CA9-5327B61700F5@suse.de>
On Thu, Sep 27, 2012 at 6:55 PM, Alexander Graf <agraf@suse.de> wrote:
>
> Below are OOPS excerpts from different rc's I tried. All of them crashed - all the way up to current Linus' master branch. I haven't cross-checked, but I don't remember any such behavior from pre-3.6 releases.
Since you seem to be able to reproduce it easily (and apparently
reliably), any chance you could just bisect it?
Since I assume v3.5 is fine, and apparently -rc1 is already busted, a simple
git bisect start
git bisect good v3.5
git bisect bad v3.6-rc1
will get you started on your adventure..
Linus
^ permalink raw reply
* Re: [REGRESSION] nfsd crashing with 3.6.0-rc7 on PowerPC
From: Alexander Graf @ 2012-09-28 2:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-nfs, skinsbursky, LKML List, Jan Kara, bfields,
linuxppc-dev
In-Reply-To: <CA+55aFyXwB1QcXE4Z_FAGnXROSgvP2x2+wjnX9OWPa4Dfaaf0A@mail.gmail.com>
On 28.09.2012, at 04:04, Linus Torvalds wrote:
> On Thu, Sep 27, 2012 at 6:55 PM, Alexander Graf <agraf@suse.de> wrote:
>>=20
>> Below are OOPS excerpts from different rc's I tried. All of them =
crashed - all the way up to current Linus' master branch. I haven't =
cross-checked, but I don't remember any such behavior from pre-3.6 =
releases.
>=20
> Since you seem to be able to reproduce it easily (and apparently
> reliably), any chance you could just bisect it?
>=20
> Since I assume v3.5 is fine, and apparently -rc1 is already busted, a =
simple
>=20
> git bisect start
> git bisect good v3.5
> git bisect bad v3.6-rc1
>=20
> will get you started on your adventure..
Heh, will give it a try :). The thing really does look quite bisectable.
It might take a few hours though - the machine isn't exactly fast by =
today's standards and it's getting late here. But I'll keep you updated.
Alex
^ permalink raw reply
* Re: [RFC v9 PATCH 01/21] memory-hotplug: rename remove_memory() to offline_memory()/offline_pages()
From: Ni zhan Chen @ 2012-09-28 2:22 UTC (permalink / raw)
To: wency
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, isimatu.yasuaki, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, cl,
linuxppc-dev, akpm, liuj97
In-Reply-To: <1346837155-534-2-git-send-email-wency@cn.fujitsu.com>
On 09/05/2012 05:25 PM, wency@cn.fujitsu.com wrote:
> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>
> remove_memory() only try to offline pages. It is called in two cases:
> 1. hot remove a memory device
> 2. echo offline >/sys/devices/system/memory/memoryXX/state
>
> In the 1st case, we should also change memory block's state, and notify
> the userspace that the memory block's state is changed after offlining
> pages.
>
> So rename remove_memory() to offline_memory()/offline_pages(). And in
> the 1st case, offline_memory() will be used. The function offline_memory()
> is not implemented. In the 2nd case, offline_pages() will be used.
But this time there is not a function associated with add_memory.
>
> CC: David Rientjes <rientjes@google.com>
> CC: Jiang Liu <liuj97@gmail.com>
> CC: Len Brown <len.brown@intel.com>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Paul Mackerras <paulus@samba.org>
> CC: Christoph Lameter <cl@linux.com>
> Cc: Minchan Kim <minchan.kim@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> ---
> drivers/acpi/acpi_memhotplug.c | 2 +-
> drivers/base/memory.c | 9 +++------
> include/linux/memory_hotplug.h | 3 ++-
> mm/memory_hotplug.c | 22 ++++++++++++++--------
> 4 files changed, 20 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index 24c807f..2a7beac 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -318,7 +318,7 @@ static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
> */
> list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
> if (info->enabled) {
> - result = remove_memory(info->start_addr, info->length);
> + result = offline_memory(info->start_addr, info->length);
> if (result)
> return result;
> }
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 7dda4f7..44e7de6 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -248,26 +248,23 @@ static bool pages_correctly_reserved(unsigned long start_pfn,
> static int
> memory_block_action(unsigned long phys_index, unsigned long action)
> {
> - unsigned long start_pfn, start_paddr;
> + unsigned long start_pfn;
> unsigned long nr_pages = PAGES_PER_SECTION * sections_per_block;
> struct page *first_page;
> int ret;
>
> first_page = pfn_to_page(phys_index << PFN_SECTION_SHIFT);
> + start_pfn = page_to_pfn(first_page);
>
> switch (action) {
> case MEM_ONLINE:
> - start_pfn = page_to_pfn(first_page);
> -
> if (!pages_correctly_reserved(start_pfn, nr_pages))
> return -EBUSY;
>
> ret = online_pages(start_pfn, nr_pages);
> break;
> case MEM_OFFLINE:
> - start_paddr = page_to_pfn(first_page) << PAGE_SHIFT;
> - ret = remove_memory(start_paddr,
> - nr_pages << PAGE_SHIFT);
> + ret = offline_pages(start_pfn, nr_pages);
> break;
> default:
> WARN(1, KERN_WARNING "%s(%ld, %ld) unknown action: "
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 910550f..c183f39 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -233,7 +233,8 @@ static inline int is_mem_section_removable(unsigned long pfn,
> extern int mem_online_node(int nid);
> extern int add_memory(int nid, u64 start, u64 size);
> extern int arch_add_memory(int nid, u64 start, u64 size);
> -extern int remove_memory(u64 start, u64 size);
> +extern int offline_pages(unsigned long start_pfn, unsigned long nr_pages);
> +extern int offline_memory(u64 start, u64 size);
> extern int sparse_add_one_section(struct zone *zone, unsigned long start_pfn,
> int nr_pages);
> extern void sparse_remove_one_section(struct zone *zone, struct mem_section *ms);
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 3ad25f9..bb42316 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -866,7 +866,7 @@ check_pages_isolated(unsigned long start_pfn, unsigned long end_pfn)
> return offlined;
> }
>
> -static int __ref offline_pages(unsigned long start_pfn,
> +static int __ref __offline_pages(unsigned long start_pfn,
> unsigned long end_pfn, unsigned long timeout)
> {
> unsigned long pfn, nr_pages, expire;
> @@ -994,18 +994,24 @@ out:
> return ret;
> }
>
> -int remove_memory(u64 start, u64 size)
> +int offline_pages(unsigned long start_pfn, unsigned long nr_pages)
> {
> - unsigned long start_pfn, end_pfn;
> + return __offline_pages(start_pfn, start_pfn + nr_pages, 120 * HZ);
> +}
>
> - start_pfn = PFN_DOWN(start);
> - end_pfn = start_pfn + PFN_DOWN(size);
> - return offline_pages(start_pfn, end_pfn, 120 * HZ);
> +int offline_memory(u64 start, u64 size)
> +{
> + return -EINVAL;
> }
> #else
> -int remove_memory(u64 start, u64 size)
> +int offline_pages(unsigned long start, unsigned long size)
> +{
> + return -EINVAL;
> +}
> +
> +int offline_memory(u64 start, u64 size)
> {
> return -EINVAL;
> }
> #endif /* CONFIG_MEMORY_HOTREMOVE */
> -EXPORT_SYMBOL_GPL(remove_memory);
> +EXPORT_SYMBOL_GPL(offline_memory);
^ permalink raw reply
* Re: [PATCH 3/3] edac/85xx: Enable the EDAC PCI err driver by device_initcall
From: Chunhe Lan @ 2012-09-28 14:29 UTC (permalink / raw)
To: Scott Wood; +Cc: kumar.gala, linuxppc-dev, Chunhe Lan
In-Reply-To: <1348762151.18375.6@snotra>
On 09/27/2012 12:09 PM, Scott Wood wrote:
> On 09/27/2012 02:02:03 PM, Chunhe Lan wrote:
>> Original process of call:
>> The mpc85xx_pci_err_probe function completes to been registered
>> and enabled of EDAC PCI err driver at the latter time stage of
>> kernel boot in the mpc85xx_edac.c.
>> Current process of call:
>> The mpc85xx_pci_err_probe function completes to been registered
>> and enabled of EDAC PCI err driver at the first time stage of
>> kernel boot in the fsl_pci.c.
>>
>> So in this case the following error messages appear in the boot log:
>>
>> PCI: Probing PCI hardware
>> pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
>> PCIE error(s) detected
>> PCIE ERR_DR register: 0x00020000
>> PCIE ERR_CAP_STAT register: 0x80000001
>> PCIE ERR_CAP_R0 register: 0x00000800
>> PCIE ERR_CAP_R1 register: 0x00000000
>> PCIE ERR_CAP_R2 register: 0x00000000
>> PCIE ERR_CAP_R3 register: 0x00000000
>>
>> Because the EDAC PCI err driver is registered and enabled earlier than
>> original point of call. But at this point of time, PCI hardware is not
>> probed and initialized, and it is in unknowable state.
>>
>> So, move enable function into mpc85xx_pci_err_en which is called at the
>> middle time stage of kernel boot and after PCI hardware is probed and
>> initialized by device_initcall in the fsl_pci.c.
>>
>> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
>> ---
>> arch/powerpc/sysdev/fsl_pci.c | 12 ++++++++++
>> arch/powerpc/sysdev/fsl_pci.h | 5 ++++
>> drivers/edac/mpc85xx_edac.c | 47
>> ++++++++++++++++++++++++++++------------
>> 3 files changed, 50 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/powerpc/sysdev/fsl_pci.c
>> b/arch/powerpc/sysdev/fsl_pci.c
>> index 3d6f4d8..a591965 100644
>> --- a/arch/powerpc/sysdev/fsl_pci.c
>> +++ b/arch/powerpc/sysdev/fsl_pci.c
>> @@ -904,4 +904,16 @@ static int __init fsl_pci_init(void)
>> return platform_driver_register(&fsl_pci_driver);
>> }
>> arch_initcall(fsl_pci_init);
>> +
>> +static int __init fsl_pci_err_en(void)
>> +{
>> + struct device_node *np;
>> +
>> + for_each_node_by_type(np, "pci")
>> + if (of_match_node(pci_ids, np))
>> + mpc85xx_pci_err_en(np);
>> +
>> + return 0;
>> +}
>> +device_initcall(fsl_pci_err_en);
>
> Why can't you call this from the normal PCIe controller init, instead
> of searching for the node independently?
Because PCIe controller init is earlier than device_initcall, and
it does not fix this issue.
Do you indicate that which function calls fsl_pci_err_en in the
which file ?
Thanks,
Chunhe
>
> -Scott
^ permalink raw reply
* RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
From: Jia Hongtao-B38951 @ 2012-09-28 2:57 UTC (permalink / raw)
To: Kumar Gala, Li Yang-R58472
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <AC1B086A-98FD-4C86-ACA7-2C59DDF5F68E@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Friday, September 28, 2012 5:38 AM
> To: Li Yang-R58472
> Cc: Jia Hongtao-B38951; Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
> support
>
>
> On Sep 27, 2012, at 11:27 AM, Li Yang-R58472 wrote:
>
> >
> > 在 Sep 28, 2012，0:07，"Kumar Gala" <galak@kernel.crashing.org> 写道：
> >
> >>>>> Hi Kumar,
> >>>>> I have already sent the log.
> >>>>> Do you have any comment on it?
> >>>>>
> >>>>> Thanks.
> >>>>> - Hongtao.
> >>>>>
> >>>>
> >>>> Hongtao,
> >>>>
> >>>> You mentioned:
> >>>>
> >>>>> I tested the re-parsing way by using setup_pci_atmu() when resume.
> >>>>> And I found out that re-parsing will *change* outbound IO
> >>>>> translation address regitster.
> >>>>
> >>>> What do the values look like in both ATMU registers and io_resource
> if you reparse?
> >>>
> >>> I think Hongtao mentioned in previous email as follows, the ATMU
> >>> registers are inline with the io_resource address.
> >>
> >> I was under that the impression that was the normal boot case, not the
> values from after wakeup.
> >
> > It is for the normal boot. But re-parse will use the io resource after
> pic scan to initialize atmu. Instead, the original atmu is initialized
> use the io resource before the scan.
> >
> > Leo
>
> I think I see, so isn't the mem resources also wrong?
>
> Can we dump the following:
>
> 1. enable pr_debug() in pcibios_setup_phb_resources so we get "PHB: "
> prints 2. Can we dump hose->io_resource & hose->mem_resources[] right
> after wakeup?
>
> I think I see what direction but would be useful to get a few more
> answers.
>
> - k
I enable pr_debug() on these three files:
arch/powerpc/sysdev/fsl_pci.c
arch/powerpc/kernel/pci-common.c
arch/powerpc/kernel/pci_32.c
Also I print the io_resource and mem_resources after wakeup.
(actually pr_debug already done this)
You can see that io resource is changed after pci scan in normal boot.
To see the log please refer to the attachment.
- Hongtao.
[-- Attachment #2: pci_pm_setup_pci_atmu_debug_2.log --]
[-- Type: application/octet-stream, Size: 31608 bytes --]
U-Boot 2009.11-00132-gd404dfa (Sep 26 2010 - 14:57:28)
CPU0: P1022E, Version: 1.0, (0x80ee0010)
Core: E500, Version: 5.0, (0x80211050)
Clock Configuration:
CPU0:1199.988 MHz, CPU1:1199.988 MHz,
CCB:599.994 MHz,
DDR:399.996 MHz (799.992 MT/s data rate) (Asynchronous), LBC:37.500 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: P1022DS Sys ID: 0x19, Sys Ver: 0x03, FPGA Ver: 0x09, vBank: 0
I2C: ready
SPI: ready
DRAM: Initializing.... DDR: 2 GB (DDR3, 64-bit, CL=6, ECC off)
Now running in RAM - U-Boot at: 7ff30000
FLASH: 128 MB
L2: 256 KB enabled
NAND: 1024 MiB
MMC: FSL_ESDHC: 0
EEPROM: NXID v0
PCIE1 connected to Slot 1 as Root Complex (base addr ffe0a000)
PCIE1 on bus 00 - 00
PCIE2 connected to Slot 3 as Root Complex (base addr ffe09000)
PCIE2 on bus 01 - 01
PCIE3 connected to Slot 2 as Root Complex (base addr ffe0b000)
PCIE3 on bus 02 - 02
In: serial
Out: serial
Err: serial
Net: eTSEC1, eTSEC2
Hit any key to stop autoboot: 0
=> run ramboot
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.106; our IP address is 10.193.20.176
Filename 'jiaht/ramdisk.small'.
Load address: 0x2000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##############################################################
done
Bytes transferred = 4306189 (41b50d hex)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.106; our IP address is 10.193.20.176
Filename 'jiaht/uImage_1022_reparse_debug'.
Load address: 0x1000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
########
done
Bytes transferred = 3696937 (386929 hex)
Speed: 1000, full duplex
Using eTSEC1 device
TFTP from server 10.193.20.106; our IP address is 10.193.20.176
Filename 'jiaht/p1022ds_32b.dtb'.
Load address: 0xc00000
Loading: ###
done
Bytes transferred = 14645 (3935 hex)
WARNING: adjusting available memory to 30000000
## Booting kernel from Legacy Image at 01000000 ...
Image Name: Linux-3.0.43-rt64-01350-g826673b
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 3696873 Bytes = 3.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 02000000 ...
Image Name: uboot ext2 ramdisk rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 4306125 Bytes = 4.1 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 00c00000
Booting using the fdt blob at 0xc00000
Uncompressing Kernel Image ... OK
Loading Ramdisk to 2fbe4000, end 2ffff4cd ... OK
debug: ignoring loglevel setting.
Using P1022 DS machine description
Memory CAM mapping: 256/256/256 Mb, residual: 1280Mb
Linux version 3.0.43-rt64-01350-g826673b-dirty (jiaht@rock) (gcc version 4.5.2 (Sourcery G++ Lite 2011.03-38) ) #69 SMP Fri Sep 28 10:06:47 CST 2012
Found initrd at 0xefbe4000:0xeffff4cd
Found legacy serial port 0 for /soc@ffe00000/serial@4500
mem=ffe04500, taddr=ffe04500, irq=0, clk=599994006, speed=0
Found legacy serial port 1 for /soc@ffe00000/serial@4600
mem=ffe04600, taddr=ffe04600, irq=0, clk=599994006, speed=0
CPU maps initialized for 1 thread per core
(thread shift is 0)
bootconsole [udbg0] enabled
setup_arch: bootmem
p1022_ds_setup_arch()
Adding PCI host bridge /pcie@ffe09000
Found FSL PCI host bridge at 0x00000000ffe09000. Firmware bus number: 0->0
->Hose at 0xc0765000, cfg_addr=0xff7fd000,cfg_data=0xff7fd004
PCI host bridge /pcie@ffe09000 ranges:
MEM 0x00000000a0000000..0x00000000bfffffff -> 0x00000000e0000000
IO 0x00000000ffc10000..0x00000000ffc1ffff -> 0x0000000000000000
PCI memory map start 0x00000000ffe09000, size 0x0000000000001000
PCI MEM resource start 0x00000000a0000000, size 0x0000000020000000.
PCI IO resource start 0x0000000000000000, size 0x0000000000010000, phy base 0x00000000ffc10000.
/pcie@ffe09000: PCICSRBAR @ 0xfff00000
Adding PCI host bridge /pcie@ffe0a000
Found FSL PCI host bridge at 0x00000000ffe0a000. Firmware bus number: 0->0
->Hose at 0xc07650e0, cfg_addr=0xff7eb000,cfg_data=0xff7eb004
PCI host bridge /pcie@ffe0a000 ranges:
MEM 0x00000000c0000000..0x00000000dfffffff -> 0x00000000e0000000
IO 0x00000000ffc20000..0x00000000ffc2ffff -> 0x0000000000000000
PCI memory map start 0x00000000ffe0a000, size 0x0000000000001000
PCI MEM resource start 0x00000000c0000000, size 0x0000000020000000.
PCI IO resource start 0x0000000000000000, size 0x0000000000010000, phy base 0x00000000ffc20000.
/pcie@ffe0a000: PCICSRBAR @ 0xfff00000
Adding PCI host bridge /pcie@ffe0b000
Found FSL PCI host bridge at 0x00000000ffe0b000. Firmware bus number: 0->0
->Hose at 0xc07651c0, cfg_addr=0xff7d9000,cfg_data=0xff7d9004
PCI host bridge /pcie@ffe0b000 ranges:
MEM 0x0000000080000000..0x000000009fffffff -> 0x00000000e0000000
IO 0x00000000ffc00000..0x00000000ffc0ffff -> 0x0000000000000000
PCI memory map start 0x00000000ffe0b000, size 0x0000000000001000
PCI MEM resource start 0x0000000080000000, size 0x0000000020000000.
PCI IO resource start 0x0000000000000000, size 0x0000000000010000, phy base 0x00000000ffc00000.
/pcie@ffe0b000: PCICSRBAR @ 0xfff00000
Freescale P1022 DS reference board
arch: exit
Top of RAM: 0x80000000, Total RAM: 0x80000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0x00000000 -> 0x00030000
Normal empty
HighMem 0x00030000 -> 0x00080000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0x00000000 -> 0x00080000
On node 0 totalpages: 524288
free_area_init_node: node 0, pgdat c072e380, node_mem_map c0c04000
DMA zone: 1536 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 195072 pages, LIFO batch:31
HighMem zone: 2560 pages used for memmap
HighMem zone: 325120 pages, LIFO batch:31
MMU: Allocated 1088 bytes of context maps for 255 contexts
PERCPU: Embedded 7 pages/cpu @c1c10000 s4768 r8192 d15712 u32768
pcpu-alloc: s4768 r8192 d15712 u32768 alloc=8*4096
pcpu-alloc: [0] 0 [0] 1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 520192
Kernel command line: root=/dev/ram rw console=ttyS0,115200 ramdisk_size=400000 cache-sram-size=0x8000 cache-sram-offset=0xfff00000 no_console_suspend ignore_loglevel
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
High memory: 1310716k
Memory: 2067952k/2097152k available (7160k kernel code, 29200k reserved, 236k data, 174k bss, 268k init)
Kernel virtual memory layout:
* 0xfff5f000..0xfffff000 : fixmap
* 0xff800000..0xffc00000 : highmem PTEs
* 0xff7c7000..0xff800000 : early ioremap
* 0xf1000000..0xff7c7000 : vmalloc & ioremap
SLUB: Genslabs=15, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
Hierarchical RCU implementation.
NR_IRQS:512 nr_irqs:512 16
mpic: Resetting
mpic: Setting up MPIC " OpenPIC " version 1.2 at ffe40000, max 2 CPUs
mpic: ISU size: 256, shift: 8, mask: ff
mpic: Initializing for 256 sources
time_init: decrementer frequency = 74.999251 MHz
time_init: processor frequency = 1199.988012 MHz
clocksource: timebase mult[3555784] shift[22] registered
clockevent: decrementer mult[133326a2] shift[32] cpu[0]
Console: colour dummy device 80x25
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
mpic: requesting IPIs...
Brought up 2 CPUs
NET: Registered protocol family 16
PCI: Probing PCI hardware
PCI: Scanning PHB /pcie@ffe09000
PCI: PHB IO resource = 00000000ff7ed000-00000000ff7fcfff [100]
PCI: PHB MEM resource 0 = 00000000a0000000-00000000bfffffff [200]
PCI: PHB MEM offset = 00000000c0000000
PCI: PHB IO offset = ff7ed000
probe mode: 0
pci 0000:00:00.0: [1957:0110] type 1 class 0x000b20
pci 0000:00:00.0: ignoring class b20 (doesn't match header type 01)
pci 0000:00:00.0: supports D1 D2
pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:00.0: PME# disabled
PCI: Fixup bus devices 0 (PHB)
pci_busdev_to_OF_node(0,0x0)
parent is /pcie@ffe09000
result is /pcie@ffe09000/pcie@0
PCI: Try to map irq for 0000:00:00.0...
pci_busdev_to_OF_node(0,0x0)
parent is /pcie@ffe09000
result is /pcie@ffe09000/pcie@0
Got one, spec 4 cells (0x00000010 0x00000002...) on /soc@ffe00000/pic@40000
Mapped to linux irq 16
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pci 0000:00:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff pref] (disabled)
PCI: Fixup bus devices 1 (0000:00:00.0)
PCI: Scanning PHB /pcie@ffe0a000
PCI: PHB IO resource = 00000000ff7db000-00000000ff7eafff [100]
PCI: PHB MEM resource 0 = 00000000c0000000-00000000dfffffff [200]
PCI: PHB MEM offset = 00000000e0000000
PCI: PHB IO offset = ff7db000
probe mode: 0
pci 0001:02:00.0: [1957:0110] type 1 class 0x000b20
pci 0001:02:00.0: ignoring class b20 (doesn't match header type 01)
pci 0001:02:00.0: supports D1 D2
pci 0001:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0001:02:00.0: PME# disabled
PCI: Fixup bus devices 2 (PHB)
pci_busdev_to_OF_node(2,0x0)
parent is /pcie@ffe0a000
result is /pcie@ffe0a000/pcie@0
PCI: Try to map irq for 0001:02:00.0...
pci_busdev_to_OF_node(2,0x0)
parent is /pcie@ffe0a000
result is /pcie@ffe0a000/pcie@0
Got one, spec 4 cells (0x00000010 0x00000002...) on /soc@ffe00000/pic@40000
Mapped to linux irq 16
pci 0001:02:00.0: PCI bridge to [bus 03-ff]
pci 0001:02:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0001:02:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0001:02:00.0: bridge window [mem 0x00000000-0x000fffff pref] (disabled)
PCI: Fixup bus devices 3 (0001:02:00.0)
PCI: Scanning PHB /pcie@ffe0b000
PCI: PHB IO resource = 00000000ff7c9000-00000000ff7d8fff [100]
PCI: PHB MEM resource 0 = 0000000080000000-000000009fffffff [200]
PCI: PHB MEM offset = 00000000a0000000
PCI: PHB IO offset = ff7c9000
probe mode: 0
pci 0002:04:00.0: [1957:0110] type 1 class 0x000b20
pci 0002:04:00.0: ignoring class b20 (doesn't match header type 01)
pci 0002:04:00.0: supports D1 D2
pci 0002:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0002:04:00.0: PME# disabled
PCI: Fixup bus devices 4 (PHB)
pci_busdev_to_OF_node(4,0x0)
parent is /pcie@ffe0b000
result is /pcie@ffe0b000/pcie@0
PCI: Try to map irq for 0002:04:00.0...
pci_busdev_to_OF_node(4,0x0)
parent is /pcie@ffe0b000
result is /pcie@ffe0b000/pcie@0
Got one, spec 4 cells (0x00000010 0x00000002...) on /soc@ffe00000/pic@40000
Mapped to linux irq 16
pci 0002:04:00.0: PCI bridge to [bus 05-ff]
pci 0002:04:00.0: bridge window [io 0x0000-0x0000] (disabled)
pci 0002:04:00.0: bridge window [mem 0x00000000-0x000fffff] (disabled)
pci 0002:04:00.0: bridge window [mem 0x00000000-0x000fffff pref] (disabled)
PCI: Fixup bus devices 5 (0002:04:00.0)
PCI->OF bus map:
0 -> 0
2 -> 0
4 -> 0
PCI: Allocating bus resources for 0000:00...
PCI: PHB (bus 0) bridge rsrc 0: 00000000ff7ed000-00000000ff7fcfff [0x100], parent c07043c8 (PCI IO)
PCI: PHB (bus 0) bridge rsrc 1: 00000000a0000000-00000000bfffffff [0x200], parent c07043ac (PCI mem)
PCI: Allocating bus resources for 0000:01...
PCI: 0000:00:00.0 (bus 1) bridge rsrc 0: 00000000ff7ed000-00000000ff7fcfff [0x100], parent c076504c (/pcie@ffe09000)
PCI: 0000:00:00.0 (bus 1) bridge rsrc 1: 00000000a0000000-00000000bfffffff [0x200], parent c0765068 (/pcie@ffe09000)
PCI: Allocating bus resources for 0001:02...
PCI: PHB (bus 2) bridge rsrc 0: 00000000ff7db000-00000000ff7eafff [0x100], parent c07043c8 (PCI IO)
PCI: PHB (bus 2) bridge rsrc 1: 00000000c0000000-00000000dfffffff [0x200], parent c07043ac (PCI mem)
PCI: Allocating bus resources for 0001:03...
PCI: 0001:02:00.0 (bus 3) bridge rsrc 0: 00000000ff7db000-00000000ff7eafff [0x100], parent c076512c (/pcie@ffe0a000)
PCI: 0001:02:00.0 (bus 3) bridge rsrc 1: 00000000c0000000-00000000dfffffff [0x200], parent c0765148 (/pcie@ffe0a000)
PCI: Allocating bus resources for 0002:04...
PCI: PHB (bus 4) bridge rsrc 0: 00000000ff7c9000-00000000ff7d8fff [0x100], parent c07043c8 (PCI IO)
PCI: PHB (bus 4) bridge rsrc 1: 0000000080000000-000000009fffffff [0x200], parent c07043ac (PCI mem)
PCI: Allocating bus resources for 0002:05...
PCI: 0002:04:00.0 (bus 5) bridge rsrc 0: 00000000ff7c9000-00000000ff7d8fff [0x100], parent c076520c (/pcie@ffe0b000)
PCI: 0002:04:00.0 (bus 5) bridge rsrc 1: 0000000080000000-000000009fffffff [0x200], parent c0765228 (/pcie@ffe0b000)
Reserving legacy ranges for domain 0000
Candidate legacy IO: [io 0xff7ed000-0xff7edfff]
PCI 0000:00 Cannot reserve Legacy IO [io 0xff7ed000-0xff7edfff]
hose mem offset: 00000000c0000000
hose mem res: [mem 0xa0000000-0xbfffffff]
Reserving legacy ranges for domain 0001
Candidate legacy IO: [io 0xff7db000-0xff7dbfff]
PCI 0001:02 Cannot reserve Legacy IO [io 0xff7db000-0xff7dbfff]
hose mem offset: 00000000e0000000
hose mem res: [mem 0xc0000000-0xdfffffff]
Reserving legacy ranges for domain 0002
Candidate legacy IO: [io 0xff7c9000-0xff7c9fff]
PCI 0002:04 Cannot reserve Legacy IO [io 0xff7c9000-0xff7c9fff]
hose mem offset: 00000000a0000000
hose mem res: [mem 0x80000000-0x9fffffff]
PCI: Assigning unassigned resources...
PCI: max bus depth: 1 pci_try_num: 2
pci 0000:00:00.0: PCI bridge to [bus 01-01]
pci 0000:00:00.0: bridge window [io 0xff7ed000-0xff7fcfff]
pci 0000:00:00.0: bridge window [mem 0xa0000000-0xbfffffff]
pci 0000:00:00.0: bridge window [mem pref disabled]
pci 0001:02:00.0: PCI bridge to [bus 03-03]
pci 0001:02:00.0: bridge window [io 0xff7db000-0xff7eafff]
pci 0001:02:00.0: bridge window [mem 0xc0000000-0xdfffffff]
pci 0001:02:00.0: bridge window [mem pref disabled]
pci 0002:04:00.0: PCI bridge to [bus 05-05]
pci 0002:04:00.0: bridge window [io 0xff7c9000-0xff7d8fff]
pci 0002:04:00.0: bridge window [mem 0x80000000-0x9fffffff]
pci 0002:04:00.0: bridge window [mem pref disabled]
pci 0000:00:00.0: enabling device (0106 -> 0107)
pci 0001:02:00.0: enabling device (0106 -> 0107)
pci 0002:04:00.0: enabling device (0106 -> 0107)
pci_bus 0000:00: resource 0 [io 0xff7ed000-0xff7fcfff]
pci_bus 0000:00: resource 1 [mem 0xa0000000-0xbfffffff]
pci_bus 0000:01: resource 0 [io 0xff7ed000-0xff7fcfff]
pci_bus 0000:01: resource 1 [mem 0xa0000000-0xbfffffff]
pci_bus 0001:02: resource 0 [io 0xff7db000-0xff7eafff]
pci_bus 0001:02: resource 1 [mem 0xc0000000-0xdfffffff]
pci_bus 0001:03: resource 0 [io 0xff7db000-0xff7eafff]
pci_bus 0001:03: resource 1 [mem 0xc0000000-0xdfffffff]
pci_bus 0002:04: resource 0 [io 0xff7c9000-0xff7d8fff]
pci_bus 0002:04: resource 1 [mem 0x80000000-0x9fffffff]
pci_bus 0002:05: resource 0 [io 0xff7c9000-0xff7d8fff]
pci_bus 0002:05: resource 1 [mem 0x80000000-0x9fffffff]
Registering qe_ic with sysfs...
bio: create slab <bio-0> at 0
raid6: int32x1 172 MB/s
raid6: int32x2 301 MB/s
raid6: int32x4 427 MB/s
raid6: int32x8 358 MB/s
raid6: using algorithm int32x4 (427 MB/s)
Freescale Elo / Elo Plus DMA driver
vgaarb: loaded
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Advanced Linux Sound Architecture Driver Version 1.0.24.
Switching to clocksource timebase
Switched to NOHz mode on CPU #0
Switched to NOHz mode on CPU #1
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 524288 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
PCI: CLS 0 bytes, default 32
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 4208k freed
fsl-elo-dma ffe0c300.dma: #2 (fsl,eloplus-dma-channel), irq 78
fsl-elo-dma ffe0c300.dma: #3 (fsl,eloplus-dma-channel), irq 79
fsl-l2ctlr ffe20000.l2-cache-controller: Entire L2 as cache, provide valid sram address and size
fsl-l2ctlr: probe of ffe20000.l2-cache-controller failed with error -22
fsl-elo-dma ffe21300.dma: #0 (fsl,eloplus-dma-channel), irq 20
fsl-elo-dma ffe21300.dma: #1 (fsl,eloplus-dma-channel), irq 21
fsl-elo-dma ffe21300.dma: #2 (fsl,eloplus-dma-channel), irq 22
fsl-elo-dma ffe21300.dma: #3 (fsl,eloplus-dma-channel), irq 23
Setting up Freescale MSI support
Freescale PowerQUICC MII Bus: probed
fsl-pq_mdio: probe of ffe25000.mdio failed with error -16
Freescale PMC driver
audit: initializing netlink socket (disabled)
type=2000 audit(0.888:1): initialized
highmem bounce pool size: 64 pages
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver 2.1.30 [Flags: R/O].
JFFS2 version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
Allocated 267980 bytes for deflate workspace
Allocated 42284 bytes for inflate workspace
Registering JFFS2 compressor "zlib"
Registering JFFS2 compressor "rtime"
JFFS2: default compression mode: priority
msgmni has been set to 1487
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Freescale DIU driver
Console: switching to colour frame buffer device 128x48
fb0: Panel0 fb device registered successfully.
fb1: fb device registered successfully.
fb2: fb device registered successfully.
fb3: fb device registered successfully.
fb4: fb device registered successfully.
Serial: 8250/16550 driver, 2 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0xffe04500 (irq = 42) is a 16550A
console [ttyS0] enabled, bootconsole disabled
console [ttyS0] enabled, bootconsole disabled
serial8250.0: ttyS1 at MMIO 0xffe04600 (irq = 42) is a 16550A
Generic non-volatile memory driver v1.1
brd: module loaded
loop: module loaded
nbd: registered device at major 43
st: Version 20101219, fixed bufsize 32768, s/g segs 256
fsl-sata ffe18000.sata: Sata FSL Platform/CSB Driver init
scsi0 : sata_fsl
ata1: SATA max UDMA/133 irq 74
fsl-sata ffe19000.sata: Sata FSL Platform/CSB Driver init
scsi1 : sata_fsl
ata2: SATA max UDMA/133 irq 41
e8000000.nor: Found 1 x16 devices at 0x0 in 16-bit bank. Manufacturer ID 0x000001 Chip ID 0x002801
Amd/Fujitsu Extended Query Table at 0x0040
Amd/Fujitsu Extended Query version 1.3.
number of CFI chips: 1
Creating 7 MTD partitions on "e8000000.nor":
0x000000000000-0x000003000000 : "ramdisk-nor"
ftl_cs: FTL header not found.
0x000003000000-0x000003e00000 : "diagnostic-nor"
ftl_cs: FTL header not found.
0x000003e00000-0x000004000000 : "dink-nor"
ftl_cs: FTL header not found.
0x000004000000-0x000004400000 : "kernel-nor"
ftl_cs: FTL header not found.
0x000004400000-0x000007f00000 : "jffs2-nor"
ftl_cs: FTL header not found.
0x000007f00000-0x000007f80000 : "dtb-nor"
ftl_cs: FTL header not found.
0x000007f80000-0x000008000000 : "u-boot-nor"
ftl_cs: FTL header not found.
fsl-lbc ffe05000.localbus: address did not match any chip selects
m25p80 spi32766.0: s25sl12801 (16384 Kbytes)
Creating 4 MTD partitions on "spi32766.0":
0x000000000000-0x000000100000 : "u-boot-spi"
ftl_cs: FTL header not found.
0x000000100000-0x000000600000 : "kernel-spi"
ftl_cs: FTL header not found.
0x000000600000-0x000000700000 : "dtb-spi"
ftl_cs: FTL header not found.
0x000000700000-0x000001000000 : "file system-spi"
ftl_cs: FTL header not found.
fsl_espi ffe07000.spi: at 0xf1064000 (irq = 59)
Fixed MDIO Bus: probed
e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2
e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
fsl-gianfar ethernet.4: eth0: mac: 00:e0:0c:02:00:fd
fsl-gianfar ethernet.4: eth0: Running with NAPI enabled
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[0]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[1]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[2]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[3]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[4]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[5]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[6]: 256
fsl-gianfar ethernet.4: eth0: RX BD ring size for Q[7]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[0]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[1]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[2]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[3]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[4]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[5]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[6]: 256
fsl-gianfar ethernet.4: eth0: TX BD ring size for Q[7]: 256
fsl-gianfar ethernet.5: eth1: mac: 00:e0:0c:02:01:fd
fsl-gianfar ethernet.5: eth1: Running with NAPI enabled
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[0]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[1]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[2]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[3]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[4]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[5]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[6]: 256
fsl-gianfar ethernet.5: eth1: RX BD ring size for Q[7]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[0]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[1]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[2]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[3]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[4]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[5]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[6]: 256
fsl-gianfar ethernet.5: eth1: TX BD ring size for Q[7]: 256
ucc_geth: QE UCC Gigabit Ethernet Controller
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
/soc@ffe00000/usb@22000: Invalid 'dr_mode' property, fallback to host mode
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 28, io mem 0xffe22000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mpc-i2c ffe03000.i2c: timeout 1000000 us
mpc-i2c ffe03100.i2c: timeout 1000000 us
EDAC MC: Ver: 2.1.0
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
talitos ffe30000.crypto: hwrng
talitos ffe30000.crypto: fsl,sec3.3 algorithms registered in /proc/crypto
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
Freescale Synchronous Serial Interface (SSI) ASoC Driver
snd-soc-p1022ds snd-soc-p1022ds.0: codec bus-frequency property is missing or invalid
snd-soc-p1022ds: probe of snd-soc-p1022ds.0 failed with error -22
ata1: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata1: SATA link down (SStatus 0 SControl 300)
ata2: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata2: SATA link down (SStatus 0 SControl 300)
Freescale Elo DMA ASoC PCM Driver
ALSA device list:
No soundcards found.
IPv4 over IPv4 tunneling driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
Registering the dns_resolver key type
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
RAMDISK: gzip image found at block 0
VFS: Mounted root (ext2 filesystem) on device 1:0.
Freeing unused kernel memory: 268k freed
Mounting /proc and /sys
Setting the hostname to mpc8572ds
Running depmod
WARNING: Couldn't open directory /lib/modules/3.0.43-rt64-01350-g826673b-dirty: No such file or directory
FATAL: Could not open /lib/modules/3.0.43-rt64-01350-g826673b-dirty/modules.dep.temp for writing: No such file or directory
Mounting filesystems
Starting syslogd and klogd
Running sysctl
Setting up networking on loopback device:
Setting up networking on eth0:
ADDRCONF(NETDEV_UP): eth0: link is not ready
Adding static route for default gateway to 192.168.1.1:
Setting nameserver to 192.168.1.1 in /etc/resolv.conf:
Setting up networking on eth1:
ADDRCONF(NETDEV_UP): eth1: link is not ready
Adding static route for default gateway to 192.168.1.1:
Setting nameserver to 192.168.1.1 in /etc/resolv.conf:
Starting inetd:
Please set the system time using
date <mmddhhmnyyyy>
/sbin/hwclock -w
Welcome to Freescale Semiconductor Embedded Linux Environment
!!!!! WARNING !!!!!!!
The default password for the root account is: root
please change this password using the 'passwd' command
and then edit this message (/etc/issue) to remove this message
mpc8572ds login: root
Password:
~ #
~ #
~ #
~ # PHY: mdio@ffe24000:01 - Link is Up - 1000/Full
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
PHY: mdio@ffe24000:01 - Link is Down
~ #
~ #
~ #
~ # PHY: mdio@ffe24000:01 - Link is Up - 1000/Full
~ #
~ #
~ #
~ # echo 5 > /sys/devices/platform/fsl-wakeup.0/fsl_wakeup;echo mem > /sys/power
/state
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
PM: suspend of devices complete after 2.032 msecs
PM: late suspend of devices complete after 0.434 msecs
Disabling non-boot CPUs ...
Cannot set affinity for irq 502
PM: resume of devices complete after 27.379 msecs
Restarting tasks ... done.
~ # ata2: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata2: SATA link down (SStatus 0 SControl 300)
ata1: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata1: SATA link down (SStatus 0 SControl 300)
PHY: mdio@ffe24000:01 - Link is Down
PHY: mdio@ffe24000:01 - Link is Up - 1000/Full
eth0: no IPv6 routers present
~ #
~ #
~ #
~ # dmesg | tail -n 60
pcieport 0000:00:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100106)
pcieport 0001:02:00.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
pcieport 0001:02:00.0: restoring config space at offset 0x8 (was 0x0, writing 0xfff0e000)
pcieport 0001:02:00.0: restoring config space at offset 0x6 (was 0x0, writing 0x30300)
pcieport 0001:02:00.0: restoring config space at offset 0x4 (was 0x0, writing 0xfff00000)
pcieport 0001:02:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100106)
pcieport 0002:04:00.0: restoring config space at offset 0x9 (was 0x10001, writing 0x1fff1)
pcieport 0002:04:00.0: restoring config space at offset 0x8 (was 0x0, writing 0xfff0e000)
pcieport 0002:04:00.0: restoring config space at offset 0x6 (was 0x0, writing 0x50500)
pcieport 0002:04:00.0: restoring config space at offset 0x4 (was 0x0, writing 0xfff00000)
Switched to NOHz mode on CPU #1
pcieport 0002:04:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100106)
PM: early resume of devices complete after 1.503 msecs
***** PCI/ffe09000 : In resume *****
io_resource.start : ff7ed000
io_resource.start >> 12: ff7ed
mem_resources[0].start : a0000000
mem_resources[0].end : bfffffff
mem_resources[1].start : 0
mem_resources[1].end : 0
PCI memory map start 0x00000000ffe09000, size 0x0000000000001000
PCI MEM resource start 0x00000000a0000000, size 0x0000000020000000.
PCI IO resource start 0x00000000ff7ed000, size 0x0000000000010000, phy base 0x00000000ffc10000.
/pcie@ffe09000: PCICSRBAR @ 0xfff00000
pci atmu resume time last: 29561
***** PCI/ffe0a000 : In resume *****
io_resource.start : ff7db000
io_resource.start >> 12: ff7db
mem_resources[0].start : c0000000
mem_resources[0].end : dfffffff
mem_resources[1].start : 0
mem_resources[1].end : 0
PCI memory map start 0x00000000ffe0a000, size 0x0000000000001000
PCI MEM resource start 0x00000000c0000000, size 0x0000000020000000.
PCI IO resource start 0x00000000ff7db000, size 0x0000000000010000, phy base 0x00000000ffc20000.
/pcie@ffe0a000: PCICSRBAR @ 0x0
/pcie@ffe0a000: DMA window size is 0x0
pci atmu resume time last: 29717
***** PCI/ffe0b000 : In resume *****
io_resource.start : ff7c9000
io_resource.start >> 12: ff7c9
mem_resources[0].start : 80000000
mem_resources[0].end : 9fffffff
mem_resources[1].start : 0
mem_resources[1].end : 0
PCI memory map start 0x00000000ffe0b000, size 0x0000000000001000
PCI MEM resource start 0x0000000080000000, size 0x0000000020000000.
PCI IO resource start 0x00000000ff7c9000, size 0x0000000000010000, phy base 0x00000000ffc00000.
/pcie@ffe0b000: PCICSRBAR @ 0x0
/pcie@ffe0b000: DMA window size is 0x0
pci atmu resume time last: 29735
PM: resume of devices complete after 27.379 msecs
Restarting tasks ... done.
ata2: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata2: SATA link down (SStatus 0 SControl 300)
ata1: No Device OR PHYRDY change,Hstatus = 0xa0000000
ata1: SATA link down (SStatus 0 SControl 300)
PHY: mdio@ffe24000:01 - Link is Down
PHY: mdio@ffe24000:01 - Link is Up - 1000/Full
eth0: no IPv6 routers present
^ permalink raw reply
* Re: [RFC v9 PATCH 03/21] memory-hotplug: store the node id in acpi_memory_device
From: Ni zhan Chen @ 2012-09-28 3:21 UTC (permalink / raw)
To: wency
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, isimatu.yasuaki, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, cl,
linuxppc-dev, akpm, liuj97
In-Reply-To: <1346837155-534-4-git-send-email-wency@cn.fujitsu.com>
On 09/05/2012 05:25 PM, wency@cn.fujitsu.com wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
>
> The memory device has only one node id. Store the node id when
> enable the memory device, and we can reuse it when removing the
> memory device.
one question:
if use numa emulation, memory device will associated to one node or ...?
>
> CC: David Rientjes <rientjes@google.com>
> CC: Jiang Liu <liuj97@gmail.com>
> CC: Len Brown <len.brown@intel.com>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Paul Mackerras <paulus@samba.org>
> CC: Christoph Lameter <cl@linux.com>
> Cc: Minchan Kim <minchan.kim@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> CC: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> ---
> drivers/acpi/acpi_memhotplug.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index 2a7beac..7873832 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -83,6 +83,7 @@ struct acpi_memory_info {
> struct acpi_memory_device {
> struct acpi_device * device;
> unsigned int state; /* State of the memory device */
> + int nid;
> struct list_head res_list;
> };
>
> @@ -256,6 +257,9 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
> info->enabled = 1;
> num_enabled++;
> }
> +
> + mem_device->nid = node;
> +
> if (!num_enabled) {
> printk(KERN_ERR PREFIX "add_memory failed\n");
> mem_device->state = MEMORY_INVALID_STATE;
^ permalink raw reply
* Re: [RFC v9 PATCH 05/21] memory-hotplug: check whether memory is present or not
From: Ni zhan Chen @ 2012-09-28 3:37 UTC (permalink / raw)
To: Yasuaki Ishimatsu
Cc: linux-s390, linux-ia64, Wen Congyang, linux-acpi, linux-sh,
len.brown, x86, linux-kernel, cmetcalf, linux-mm, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, cl,
linuxppc-dev, akpm, liuj97
In-Reply-To: <504EA0F7.5090805@jp.fujitsu.com>
On 09/11/2012 10:24 AM, Yasuaki Ishimatsu wrote:
> Hi Wen,
>
> 2012/09/11 11:15, Wen Congyang wrote:
>> Hi, ishimatsu
>>
>> At 09/05/2012 05:25 PM, wency@cn.fujitsu.com Wrote:
>>> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>>
>>> If system supports memory hot-remove, online_pages() may online
>>> removed pages.
>>> So online_pages() need to check whether onlining pages are present
>>> or not.
>>
>> Because we use memory_block_change_state() to hotremoving memory, I
>> think
>> this patch can be removed. What do you think?
>
> Pleae teach me detals a little more. If we use
> memory_block_change_state(),
> does the conflict never occur? Why?
since memory hot-add or hot-remove is based on memblock, if check in
memory_block_change_state()
can guarantee conflict never occur?
>
> Thansk,
> Yasuaki Ishimatsu
>
>> Thanks
>> Wen Congyang
>>
>>>
>>> CC: David Rientjes <rientjes@google.com>
>>> CC: Jiang Liu <liuj97@gmail.com>
>>> CC: Len Brown <len.brown@intel.com>
>>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> CC: Paul Mackerras <paulus@samba.org>
>>> CC: Christoph Lameter <cl@linux.com>
>>> Cc: Minchan Kim <minchan.kim@gmail.com>
>>> CC: Andrew Morton <akpm@linux-foundation.org>
>>> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>>> CC: Wen Congyang <wency@cn.fujitsu.com>
>>> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>> ---
>>> include/linux/mmzone.h | 19 +++++++++++++++++++
>>> mm/memory_hotplug.c | 13 +++++++++++++
>>> 2 files changed, 32 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>>> index 2daa54f..ac3ae30 100644
>>> --- a/include/linux/mmzone.h
>>> +++ b/include/linux/mmzone.h
>>> @@ -1180,6 +1180,25 @@ void sparse_init(void);
>>> #define sparse_index_init(_sec, _nid) do {} while (0)
>>> #endif /* CONFIG_SPARSEMEM */
>>>
>>> +#ifdef CONFIG_SPARSEMEM
>>> +static inline int pfns_present(unsigned long pfn, unsigned long
>>> nr_pages)
>>> +{
>>> + int i;
>>> + for (i = 0; i < nr_pages; i++) {
>>> + if (pfn_present(pfn + i))
>>> + continue;
>>> + else
>>> + return -EINVAL;
>>> + }
>>> + return 0;
>>> +}
>>> +#else
>>> +static inline int pfns_present(unsigned long pfn, unsigned long
>>> nr_pages)
>>> +{
>>> + return 0;
>>> +}
>>> +#endif /* CONFIG_SPARSEMEM*/
>>> +
>>> #ifdef CONFIG_NODES_SPAN_OTHER_NODES
>>> bool early_pfn_in_nid(unsigned long pfn, int nid);
>>> #else
>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>>> index 49f7747..299747d 100644
>>> --- a/mm/memory_hotplug.c
>>> +++ b/mm/memory_hotplug.c
>>> @@ -467,6 +467,19 @@ int __ref online_pages(unsigned long pfn,
>>> unsigned long nr_pages)
>>> struct memory_notify arg;
>>>
>>> lock_memory_hotplug();
>>> + /*
>>> + * If system supports memory hot-remove, the memory may have been
>>> + * removed. So we check whether the memory has been removed or
>>> not.
>>> + *
>>> + * Note: When CONFIG_SPARSEMEM is defined, pfns_present() become
>>> + * effective. If CONFIG_SPARSEMEM is not defined,
>>> pfns_present()
>>> + * always returns 0.
>>> + */
>>> + ret = pfns_present(pfn, nr_pages);
>>> + if (ret) {
>>> + unlock_memory_hotplug();
>>> + return ret;
>>> + }
>>> arg.start_pfn = pfn;
>>> arg.nr_pages = nr_pages;
>>> arg.status_change_nid = -1;
>>
>
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply
* Re: [RFC v9 PATCH 01/21] memory-hotplug: rename remove_memory() to offline_memory()/offline_pages()
From: Yasuaki Ishimatsu @ 2012-09-28 3:50 UTC (permalink / raw)
To: Ni zhan Chen
Cc: linux-s390, linux-ia64, wency, linux-acpi, linux-sh, len.brown,
x86, linux-kernel, cmetcalf, linux-mm, paulus, minchan.kim,
kosaki.motohiro, rientjes, sparclinux, cl, linuxppc-dev, akpm,
liuj97
In-Reply-To: <506509E4.1090000@gmail.com>
Hi Chen,
2012/09/28 11:22, Ni zhan Chen wrote:
> On 09/05/2012 05:25 PM, wency@cn.fujitsu.com wrote:
>> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>>
>> remove_memory() only try to offline pages. It is called in two cases:
>> 1. hot remove a memory device
>> 2. echo offline >/sys/devices/system/memory/memoryXX/state
>>
>> In the 1st case, we should also change memory block's state, and notify
>> the userspace that the memory block's state is changed after offlining
>> pages.
>>
>> So rename remove_memory() to offline_memory()/offline_pages(). And in
>> the 1st case, offline_memory() will be used. The function offline_memory()
>> is not implemented. In the 2nd case, offline_pages() will be used.
>
> But this time there is not a function associated with add_memory.
To associate with add_memory() later, we renamed it.
Thanks,
Yasuaki Ishimatsu
>
>>
>> CC: David Rientjes <rientjes@google.com>
>> CC: Jiang Liu <liuj97@gmail.com>
>> CC: Len Brown <len.brown@intel.com>
>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> CC: Paul Mackerras <paulus@samba.org>
>> CC: Christoph Lameter <cl@linux.com>
>> Cc: Minchan Kim <minchan.kim@gmail.com>
>> CC: Andrew Morton <akpm@linux-foundation.org>
>> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
>> ---
>> drivers/acpi/acpi_memhotplug.c | 2 +-
>> drivers/base/memory.c | 9 +++------
>> include/linux/memory_hotplug.h | 3 ++-
>> mm/memory_hotplug.c | 22 ++++++++++++++--------
>> 4 files changed, 20 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
>> index 24c807f..2a7beac 100644
>> --- a/drivers/acpi/acpi_memhotplug.c
>> +++ b/drivers/acpi/acpi_memhotplug.c
>> @@ -318,7 +318,7 @@ static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
>> */
>> list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
>> if (info->enabled) {
>> - result = remove_memory(info->start_addr, info->length);
>> + result = offline_memory(info->start_addr, info->length);
>> if (result)
>> return result;
>> }
>> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
>> index 7dda4f7..44e7de6 100644
>> --- a/drivers/base/memory.c
>> +++ b/drivers/base/memory.c
>> @@ -248,26 +248,23 @@ static bool pages_correctly_reserved(unsigned long start_pfn,
>> static int
>> memory_block_action(unsigned long phys_index, unsigned long action)
>> {
>> - unsigned long start_pfn, start_paddr;
>> + unsigned long start_pfn;
>> unsigned long nr_pages = PAGES_PER_SECTION * sections_per_block;
>> struct page *first_page;
>> int ret;
>> first_page = pfn_to_page(phys_index << PFN_SECTION_SHIFT);
>> + start_pfn = page_to_pfn(first_page);
>> switch (action) {
>> case MEM_ONLINE:
>> - start_pfn = page_to_pfn(first_page);
>> -
>> if (!pages_correctly_reserved(start_pfn, nr_pages))
>> return -EBUSY;
>> ret = online_pages(start_pfn, nr_pages);
>> break;
>> case MEM_OFFLINE:
>> - start_paddr = page_to_pfn(first_page) << PAGE_SHIFT;
>> - ret = remove_memory(start_paddr,
>> - nr_pages << PAGE_SHIFT);
>> + ret = offline_pages(start_pfn, nr_pages);
>> break;
>> default:
>> WARN(1, KERN_WARNING "%s(%ld, %ld) unknown action: "
>> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
>> index 910550f..c183f39 100644
>> --- a/include/linux/memory_hotplug.h
>> +++ b/include/linux/memory_hotplug.h
>> @@ -233,7 +233,8 @@ static inline int is_mem_section_removable(unsigned long pfn,
>> extern int mem_online_node(int nid);
>> extern int add_memory(int nid, u64 start, u64 size);
>> extern int arch_add_memory(int nid, u64 start, u64 size);
>> -extern int remove_memory(u64 start, u64 size);
>> +extern int offline_pages(unsigned long start_pfn, unsigned long nr_pages);
>> +extern int offline_memory(u64 start, u64 size);
>> extern int sparse_add_one_section(struct zone *zone, unsigned long start_pfn,
>> int nr_pages);
>> extern void sparse_remove_one_section(struct zone *zone, struct mem_section *ms);
>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
>> index 3ad25f9..bb42316 100644
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -866,7 +866,7 @@ check_pages_isolated(unsigned long start_pfn, unsigned long end_pfn)
>> return offlined;
>> }
>> -static int __ref offline_pages(unsigned long start_pfn,
>> +static int __ref __offline_pages(unsigned long start_pfn,
>> unsigned long end_pfn, unsigned long timeout)
>> {
>> unsigned long pfn, nr_pages, expire;
>> @@ -994,18 +994,24 @@ out:
>> return ret;
>> }
>> -int remove_memory(u64 start, u64 size)
>> +int offline_pages(unsigned long start_pfn, unsigned long nr_pages)
>> {
>> - unsigned long start_pfn, end_pfn;
>> + return __offline_pages(start_pfn, start_pfn + nr_pages, 120 * HZ);
>> +}
>> - start_pfn = PFN_DOWN(start);
>> - end_pfn = start_pfn + PFN_DOWN(size);
>> - return offline_pages(start_pfn, end_pfn, 120 * HZ);
>> +int offline_memory(u64 start, u64 size)
>> +{
>> + return -EINVAL;
>> }
>> #else
>> -int remove_memory(u64 start, u64 size)
>> +int offline_pages(unsigned long start, unsigned long size)
>> +{
>> + return -EINVAL;
>> +}
>> +
>> +int offline_memory(u64 start, u64 size)
>> {
>> return -EINVAL;
>> }
>> #endif /* CONFIG_MEMORY_HOTREMOVE */
>> -EXPORT_SYMBOL_GPL(remove_memory);
>> +EXPORT_SYMBOL_GPL(offline_memory);
>
^ permalink raw reply
* Re: [RFC v9 PATCH 04/21] memory-hotplug: offline and remove memory when removing the memory device
From: Ni zhan Chen @ 2012-09-28 4:48 UTC (permalink / raw)
To: wency
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, isimatu.yasuaki, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, cl,
linuxppc-dev, akpm, liuj97
In-Reply-To: <1346837155-534-5-git-send-email-wency@cn.fujitsu.com>
On 09/05/2012 05:25 PM, wency@cn.fujitsu.com wrote:
> From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
>
> We should offline and remove memory when removing the memory device.
> The memory device can be removed by 2 ways:
> 1. send eject request by SCI
> 2. echo 1 >/sys/bus/pci/devices/PNP0C80:XX/eject
>
> In the 1st case, acpi_memory_disable_device() will be called. In the 2nd
> case, acpi_memory_device_remove() will be called. acpi_memory_device_remove()
> will also be called when we unbind the memory device from the driver
> acpi_memhotplug. If the type is ACPI_BUS_REMOVAL_EJECT, it means
> that the user wants to eject the memory device, and we should offline
> and remove memory in acpi_memory_device_remove().
>
> The function remove_memory() is not implemeted now. It only check whether
> all memory has been offllined now.
>
> CC: David Rientjes <rientjes@google.com>
> CC: Jiang Liu <liuj97@gmail.com>
> CC: Len Brown <len.brown@intel.com>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Paul Mackerras <paulus@samba.org>
> CC: Christoph Lameter <cl@linux.com>
> Cc: Minchan Kim <minchan.kim@gmail.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
> Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> ---
> drivers/acpi/acpi_memhotplug.c | 45 +++++++++++++++++++++++++++++++++------
> drivers/base/memory.c | 39 ++++++++++++++++++++++++++++++++++
> include/linux/memory.h | 5 ++++
> include/linux/memory_hotplug.h | 5 ++++
> mm/memory_hotplug.c | 22 +++++++++++++++++++
> 5 files changed, 109 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
> index 7873832..9d47458 100644
> --- a/drivers/acpi/acpi_memhotplug.c
> +++ b/drivers/acpi/acpi_memhotplug.c
> @@ -29,6 +29,7 @@
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/types.h>
> +#include <linux/memory.h>
> #include <linux/memory_hotplug.h>
> #include <linux/slab.h>
> #include <acpi/acpi_drivers.h>
> @@ -310,25 +311,44 @@ static int acpi_memory_powerdown_device(struct acpi_memory_device *mem_device)
> return 0;
> }
>
> -static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
> +static int
> +acpi_memory_device_remove_memory(struct acpi_memory_device *mem_device)
> {
> int result;
> struct acpi_memory_info *info, *n;
> + int node = mem_device->nid;
>
> -
> - /*
> - * Ask the VM to offline this memory range.
> - * Note: Assume that this function returns zero on success
> - */
> list_for_each_entry_safe(info, n, &mem_device->res_list, list) {
> if (info->enabled) {
> result = offline_memory(info->start_addr, info->length);
> if (result)
> return result;
> +
> + result = remove_memory(node, info->start_addr,
> + info->length);
> + if (result)
> + return result;
> }
> +
> + list_del(&info->list);
> kfree(info);
> }
>
> + return 0;
> +}
> +
> +static int acpi_memory_disable_device(struct acpi_memory_device *mem_device)
> +{
> + int result;
> +
> + /*
> + * Ask the VM to offline this memory range.
> + * Note: Assume that this function returns zero on success
> + */
> + result = acpi_memory_device_remove_memory(mem_device);
> + if (result)
> + return result;
> +
> /* Power-off and eject the device */
> result = acpi_memory_powerdown_device(mem_device);
> if (result) {
> @@ -477,12 +497,23 @@ static int acpi_memory_device_add(struct acpi_device *device)
> static int acpi_memory_device_remove(struct acpi_device *device, int type)
> {
> struct acpi_memory_device *mem_device = NULL;
> -
> + int result;
>
> if (!device || !acpi_driver_data(device))
> return -EINVAL;
>
> mem_device = acpi_driver_data(device);
> +
> + if (type == ACPI_BUS_REMOVAL_EJECT) {
> + /*
> + * offline and remove memory only when the memory device is
> + * ejected.
> + */
> + result = acpi_memory_device_remove_memory(mem_device);
> + if (result)
> + return result;
> + }
> +
> kfree(mem_device);
>
> return 0;
> diff --git a/drivers/base/memory.c b/drivers/base/memory.c
> index 86c8821..038be73 100644
> --- a/drivers/base/memory.c
> +++ b/drivers/base/memory.c
> @@ -70,6 +70,45 @@ void unregister_memory_isolate_notifier(struct notifier_block *nb)
> }
> EXPORT_SYMBOL(unregister_memory_isolate_notifier);
>
> +bool is_memblk_offline(unsigned long start, unsigned long size)
> +{
> + struct memory_block *mem = NULL;
> + struct mem_section *section;
> + unsigned long start_pfn, end_pfn;
> + unsigned long pfn, section_nr;
> +
> + start_pfn = PFN_DOWN(start);
> + end_pfn = PFN_UP(start + size);
> +
> + for (pfn = start_pfn; pfn < end_pfn; pfn += PAGES_PER_SECTION) {
> + section_nr = pfn_to_section_nr(pfn);
> + if (!present_section_nr(section_nr))
> + continue;
> +
> + section = __nr_to_section(section_nr);
> + /* same memblock? */
> + if (mem)
> + if ((section_nr >= mem->start_section_nr) &&
> + (section_nr <= mem->end_section_nr))
> + continue;
> +
> + mem = find_memory_block_hinted(section, mem);
> + if (!mem)
> + continue;
> + if (mem->state == MEM_OFFLINE)
> + continue;
> +
> + kobject_put(&mem->dev.kobj);
> + return false;
> + }
> +
> + if (mem)
> + kobject_put(&mem->dev.kobj);
> +
> + return true;
> +}
> +EXPORT_SYMBOL(is_memblk_offline);
> +
> /*
> * register_memory - Setup a sysfs device for a memory block
> */
> diff --git a/include/linux/memory.h b/include/linux/memory.h
> index 1ac7f6e..7c66126 100644
> --- a/include/linux/memory.h
> +++ b/include/linux/memory.h
> @@ -106,6 +106,10 @@ static inline int memory_isolate_notify(unsigned long val, void *v)
> {
> return 0;
> }
> +static inline bool is_memblk_offline(unsigned long start, unsigned long size)
> +{
> + return false;
> +}
> #else
> extern int register_memory_notifier(struct notifier_block *nb);
> extern void unregister_memory_notifier(struct notifier_block *nb);
> @@ -120,6 +124,7 @@ extern int memory_isolate_notify(unsigned long val, void *v);
> extern struct memory_block *find_memory_block_hinted(struct mem_section *,
> struct memory_block *);
> extern struct memory_block *find_memory_block(struct mem_section *);
> +extern bool is_memblk_offline(unsigned long start, unsigned long size);
> #define CONFIG_MEM_BLOCK_SIZE (PAGES_PER_SECTION<<PAGE_SHIFT)
> enum mem_add_context { BOOT, HOTPLUG };
> #endif /* CONFIG_MEMORY_HOTPLUG_SPARSE */
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 0b040bb..fd84ea9 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -222,6 +222,7 @@ static inline void unlock_memory_hotplug(void) {}
> #ifdef CONFIG_MEMORY_HOTREMOVE
>
> extern int is_mem_section_removable(unsigned long pfn, unsigned long nr_pages);
> +extern int remove_memory(int nid, u64 start, u64 size);
>
> #else
> static inline int is_mem_section_removable(unsigned long pfn,
> @@ -229,6 +230,10 @@ static inline int is_mem_section_removable(unsigned long pfn,
> {
> return 0;
> }
> +static inline int remove_memory(int nid, u64 start, u64 size)
> +{
> + return -EBUSY;
> +}
> #endif /* CONFIG_MEMORY_HOTREMOVE */
>
> extern int mem_online_node(int nid);
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 6fc1908..49f7747 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1038,6 +1038,28 @@ int offline_memory(u64 start, u64 size)
>
> return 0;
> }
> +
> +int remove_memory(int nid, u64 start, u64 size)
> +{
> + int ret = -EBUSY;
> + lock_memory_hotplug();
> + /*
> + * The memory might become online by other task, even if you offine it.
s/offine/offline
> + * So we check whether the memory has been onlined or not.
> + */
> + if (!is_memblk_offline(start, size)) {
> + pr_warn("memory removing [mem %#010llx-%#010llx] failed, "
> + "because the memmory range is online\n",
> + start, start + size);
> + ret = -EAGAIN;
> + }
> +
> + unlock_memory_hotplug();
> + return ret;
> +
> +}
> +EXPORT_SYMBOL_GPL(remove_memory);
> +
> #else
> int offline_pages(unsigned long start, unsigned long size)
> {
^ permalink raw reply
* [PPC] relocation truncated to fit: R_PPC64_REL24 against symbol `.eeh_check_failure' defined in .text section in arch/powerpc/platforms/built-in.o
From: Fengguang Wu @ 2012-09-28 11:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: kernel-janitors
Hi,
I got such build errors in powerpc allyesconfig and other configs.
How can they be eliminated? I'm running the cross compile tools from
kernel.org.
drivers/built-in.o: In function `.yenta_interrupt':
yenta_socket.c:(.text+0x1ffba78): relocation truncated to fit: R_PPC64_REL24 against symbol `.eeh_check_failure' defined in .text section in arch/powerpc/platforms/built-in.o
yenta_socket.c:(.text+0x1ffbb40): relocation truncated to fit: R_PPC64_REL24 against symbol `.eeh_check_failure' defined in .text section in arch/powerpc/platforms/built-in.o
yenta_socket.c:(.text+0x1ffbcd0): relocation truncated to fit: R_PPC64_REL24 against symbol `.eeh_check_failure' defined in .text section in arch/powerpc/platforms/built-in.o
drivers/built-in.o: In function `.yenta_interrupt_wrapper':
yenta_socket.c:(.text+0x1ffbe3c): relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_29' defined in .text.save.restore section in arch/powerpc/lib/built-in.o
yenta_socket.c:(.text+0x1ffbea8): relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_29' defined in .text.save.restore section in arch/powerpc/lib/built-in.o
drivers/built-in.o: In function `.yenta_probe_irq.isra.1':
yenta_socket.c:(.text+0x1ffc044): relocation truncated to fit: R_PPC64_REL24 against symbol `.eeh_check_failure' defined in .text section in arch/powerpc/platforms/built-in.o
yenta_socket.c:(.text+0x1ffc1d0): relocation truncated to fit: R_PPC64_REL24 against symbol `.eeh_check_failure' defined in .text section in arch/powerpc/platforms/built-in.o
yenta_socket.c:(.text+0x1ffc298): relocation truncated to fit: R_PPC64_REL24 against symbol `.eeh_check_failure' defined in .text section in arch/powerpc/platforms/built-in.o
yenta_socket.c:(.text+0x1ffc478): relocation truncated to fit: R_PPC64_REL24 against symbol `.eeh_check_failure' defined in .text section in arch/powerpc/platforms/built-in.o
yenta_socket.c:(.text+0x1ffc608): relocation truncated to fit: R_PPC64_REL24 against symbol `.eeh_check_failure' defined in .text section in arch/powerpc/platforms/built-in.o
yenta_socket.c:(.text+0x1ffc7a0): additional relocation overflows omitted from the output
Thanks,
Fengguang
^ permalink raw reply
* Re: [PATCH 3/3] edac/85xx: Enable the EDAC PCI err driver by device_initcall
From: Kumar Gala @ 2012-09-27 22:33 UTC (permalink / raw)
To: Scott Wood
Cc: Lan Chunhe-B25806, Wood Scott-B07421, Gala Kumar-B11780,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1348782713.18375.22@snotra>
On Sep 27, 2012, at 4:51 PM, Scott Wood wrote:
> On 09/27/2012 04:45:08 PM, Gala Kumar-B11780 wrote:
>> On Sep 27, 2012, at 11:09 AM, Scott Wood wrote:
>>> On 09/27/2012 02:02:03 PM, Chunhe Lan wrote:
>>>> Original process of call:
>>>> The mpc85xx_pci_err_probe function completes to been registered
>>>> and enabled of EDAC PCI err driver at the latter time stage of
>>>> kernel boot in the mpc85xx_edac.c.
>>>> Current process of call:
>>>> The mpc85xx_pci_err_probe function completes to been registered
>>>> and enabled of EDAC PCI err driver at the first time stage of
>>>> kernel boot in the fsl_pci.c.
>>>> So in this case the following error messages appear in the boot =
log:
>>>> PCI: Probing PCI hardware
>>>> pci 0000:00:00.0: ignoring class b20 (doesn't match header type =
01)
>>>> PCIE error(s) detected
>>>> PCIE ERR_DR register: 0x00020000
>>>> PCIE ERR_CAP_STAT register: 0x80000001
>>>> PCIE ERR_CAP_R0 register: 0x00000800
>>>> PCIE ERR_CAP_R1 register: 0x00000000
>>>> PCIE ERR_CAP_R2 register: 0x00000000
>>>> PCIE ERR_CAP_R3 register: 0x00000000
>>>> Because the EDAC PCI err driver is registered and enabled earlier =
than
>>>> original point of call. But at this point of time, PCI hardware is =
not
>>>> probed and initialized, and it is in unknowable state.
>>>> So, move enable function into mpc85xx_pci_err_en which is called at =
the
>>>> middle time stage of kernel boot and after PCI hardware is probed =
and
>>>> initialized by device_initcall in the fsl_pci.c.
>>>> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
>>>> ---
>>>> arch/powerpc/sysdev/fsl_pci.c | 12 ++++++++++
>>>> arch/powerpc/sysdev/fsl_pci.h | 5 ++++
>>>> drivers/edac/mpc85xx_edac.c | 47 =
++++++++++++++++++++++++++++------------
>>>> 3 files changed, 50 insertions(+), 14 deletions(-)
>>>> diff --git a/arch/powerpc/sysdev/fsl_pci.c =
b/arch/powerpc/sysdev/fsl_pci.c
>>>> index 3d6f4d8..a591965 100644
>>>> --- a/arch/powerpc/sysdev/fsl_pci.c
>>>> +++ b/arch/powerpc/sysdev/fsl_pci.c
>>>> @@ -904,4 +904,16 @@ static int __init fsl_pci_init(void)
>>>> return platform_driver_register(&fsl_pci_driver);
>>>> }
>>>> arch_initcall(fsl_pci_init);
>>>> +
>>>> +static int __init fsl_pci_err_en(void)
>>>> +{
>>>> + struct device_node *np;
>>>> +
>>>> + for_each_node_by_type(np, "pci")
>>>> + if (of_match_node(pci_ids, np))
>>>> + mpc85xx_pci_err_en(np);
>>>> +
>>>> + return 0;
>>>> +}
>>>> +device_initcall(fsl_pci_err_en);
>>>=20
>>> Why can't you call this from the normal PCIe controller init, =
instead of searching for the node independently?
>> Don't we have this now with mpc85xx_pci_err_probe() ??
>=20
> What do you mean by "this"?
I'm saying don't we replace fsl_pci_err_en() with =
mpc85xx_pci_err_probe()...
I need to look at this more, but not clear why mpc85xx_pci_err_en() can =
just be part of mpc85xx_pci_err_probe()
- k=
^ 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