* [PATCH 2/5] media: dt: bindings: Update binding documentation for sunxi IR controller
From: Maxime Ripard @ 2017-12-18 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217224547.21481-3-embed3d@gmail.com>
Hi,
On Sun, Dec 17, 2017 at 11:45:44PM +0100, Philipp Rossak wrote:
> This patch updates documentation for Device-Tree bindings for sunxi IR
> controller and adds the new optional property for the base clock
> frequency.
>
> Signed-off-by: Philipp Rossak <embed3d@gmail.com>
> ---
> Documentation/devicetree/bindings/media/sunxi-ir.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt
> index 91648c569b1e..9f45bab07d6e 100644
> --- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
> +++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
> @@ -11,6 +11,7 @@ Required properties:
> Optional properties:
> - linux,rc-map-name: see rc.txt file in the same directory.
> - resets : phandle + reset specifier pair
> +- clock-frequency : overrides the default base clock frequency (8 MHz)
You're at least missing the unit one needs to use, but something like:
IR Receiver clock frequency, in Hertz. Defaults to 8MHz if missing.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171218/b30f0dbc/attachment.sig>
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Michal Simek @ 2017-12-18 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215072734.6180613b@vento.lan>
Hi guys,
On 15.12.2017 10:27, Mauro Carvalho Chehab wrote:
> Em Fri, 15 Dec 2017 10:55:26 +0530
> Dhaval Shah <dhaval23031987@gmail.com> escreveu:
>
>> Hi Laurent/Mauro/Greg,
>>
>> On Fri, Dec 15, 2017 at 3:32 AM, Laurent Pinchart
>> <laurent.pinchart@ideasonboard.com> wrote:
>>> Hi Mauro,
>>>
>>> On Thursday, 14 December 2017 23:50:03 EET Mauro Carvalho Chehab wrote:
>>>> Em Thu, 14 Dec 2017 21:57:06 +0100 Greg KH escreveu:
>>>>> On Thu, Dec 14, 2017 at 10:44:16PM +0200, Laurent Pinchart wrote:
>>>>>> On Thursday, 14 December 2017 22:08:51 EET Greg KH wrote:
>>>>>>> On Thu, Dec 14, 2017 at 09:05:27PM +0200, Laurent Pinchart wrote:
>>>>>>>> On Thursday, 14 December 2017 20:54:39 EET Joe Perches wrote:
>>>>>>>>> On Thu, 2017-12-14 at 20:37 +0200, Laurent Pinchart wrote:
>>>>>>>>>> On Thursday, 14 December 2017 20:32:20 EET Joe Perches wrote:
>>>>>>>>>>> On Thu, 2017-12-14 at 20:28 +0200, Laurent Pinchart wrote:
>>>>>>>>>>>> On Thursday, 14 December 2017 19:05:27 EET Mauro Carvalho Chehab
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Em Fri, 8 Dec 2017 18:05:37 +0530 Dhaval Shah escreveu:
>>>>>>>>>>>>>> SPDX-License-Identifier is used for the Xilinx Video IP and
>>>>>>>>>>>>>> related drivers.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Dhaval,
>>>>>>>>>>>>>
>>>>>>>>>>>>> You're not listed as one of the Xilinx driver maintainers. I'm
>>>>>>>>>>>>> afraid that, without their explicit acks, sent to the ML, I
>>>>>>>>>>>>> can't accept a patch touching at the driver's license tags.
>>>>>>>>>>>>
>>>>>>>>>>>> The patch doesn't change the license, I don't see why it would
>>>>>>>>>>>> cause any issue. Greg isn't listed as the maintainer or copyright
>>>>>>>>>>>> holder of any of the 10k+ files to which he added an SPDX license
>>>>>>>>>>>> header in the last kernel release.
>>>>>>>>>>>
>>>>>>>>>>> Adding a comment line that describes an implicit or
>>>>>>>>>>> explicit license is different than removing the license
>>>>>>>>>>> text itself.
>>>>>>>>>>
>>>>>>>>>> The SPDX license header is meant to be equivalent to the license
>>>>>>>>>> text.
>>>>>>>>>
>>>>>>>>> I understand that.
>>>>>>>>> At a minimum, removing BSD license text is undesirable
>>>>>>>>>
>>>>>>>>> as that license states:
>>>>>>>>> * * Redistributions of source code must retain the above copyright
>>>>>>>>> * notice, this list of conditions and the following disclaimer.
>>>>>>>>>
>>>>>>>>> etc...
>>>>>>>>
>>>>>>>> But this patch only removes the following text:
>>>>>>>>
>>>>>>>> - * This program is free software; you can redistribute it and/or
>>>>>>>> modify
>>>>>>>> - * it under the terms of the GNU General Public License version 2 as
>>>>>>>> - * published by the Free Software Foundation.
>>>>>>>>
>>>>>>>> and replaces it by the corresponding SPDX header.
>>>>>>>>
>>>>>>>>>> The only reason why the large SPDX patch didn't touch the whole
>>>>>>>>>> kernel in one go was that it was easier to split in in multiple
>>>>>>>>>> chunks.
>>>>>>>>>
>>>>>>>>> Not really, it was scripted.
>>>>>>>>
>>>>>>>> But still manually reviewed as far as I know.
>>>>>>>>
>>>>>>>>>> This is no different than not including the full GPL license in
>>>>>>>>>> every header file but only pointing to it through its name and
>>>>>>>>>> reference, as every kernel source file does.
>>>>>>>>>
>>>>>>>>> Not every kernel source file had a license text
>>>>>>>>> or a reference to another license file.
>>>>>>>>
>>>>>>>> Correct, but the files touched by this patch do.
>>>>>>>>
>>>>>>>> This issue is in no way specific to linux-media and should be
>>>>>>>> decided upon at the top level, not on a per-subsystem basis. Greg,
>>>>>>>> could you comment on this ?
>>>>>>>
>>>>>>> Comment on what exactly? I don't understand the problem here, care to
>>>>>>> summarize it?
>>>>>>
>>>>>> In a nutshell (if I understand it correctly), Dhaval Shah submitted
>>>>>> https:// patchwork.kernel.org/patch/10102451/ which replaces
>>>>>>
>>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>>> [...]
>>>>>> - *
>>>>>> - * This program is free software; you can redistribute it and/or modify
>>>>>> - * it under the terms of the GNU General Public License version 2 as
>>>>>> - * published by the Free Software Foundation.
>>>>>>
>>>>>> in all .c and .h files of the Xilinx V4L2 driver
>>>>>> (drivers/media/platform/
>>>>>> xilinx). I have reviewed the patch and acked it. Mauro then rejected it,
>>>>>> stating that he can't accept a change to license text without an
>>>>>> explicit ack from the official driver's maintainers. My position is
>>>>>> that such a change doesn't change the license and thus doesn't need to
>>>>>> track all copyright holders, and can be merged without an explicit ack
>>>>>> from the respective maintainers.
>>>>>
>>>>> Yes, I agree with you, no license is being changed here, and no
>>>>> copyright is either.
>>>>>
>>>>> BUT, I know that most major companies are reviewing this process right
>>>>> now. We have gotten approval from almost all of the major kernel
>>>>> developer companies to do this, which is great, and supports this work
>>>>> as being acceptable.
>>>>>
>>>>> So it's nice to ask Xilinx if they object to this happening, which I
>>>>> guess Mauro is trying to say here (in not so many words...) To at least
>>>>> give them the heads-up that this is what is going to be going on
>>>>> throughout the kernel tree soon, and if they object, it would be good to
>>>>> speak up as to why (and if they do, I can put their lawyers in contact
>>>>> with some lawyers to explain it all to them.)
>>>>
>>>> Yes, that's basically what I'm saying.
>>>>
>>>> I don't feel comfortable on signing a patch changing the license text
>>>> without giving the copyright owners an opportunity and enough time
>>>> to review it and approve, or otherwise comment about such changes.
>>>
>>> If I understand you and Greg correctly, you would like to get a general
>>> approval from Xilinx for SPDX-related changes, but that would be a blanket
>>> approval that would cover this and all subsequent similar patches. Is that
>>> correct ? That is reasonable for me.
>>>
>>> In that case, could the fact that commit
>>>
>>> commit 5fd54ace4721fc5ce2bb5aef6318fcf17f421460
>>> Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> Date: Fri Nov 3 11:28:30 2017 +0100
>>>
>>> USB: add SPDX identifiers to all remaining files in drivers/usb/
>>>
>>> add SPDX headers to several Xilinx-authored source files constitute such a
>>> blanket approval ?
>>>
>> I have to do anything here or Once, we get approval from the Michal
>> Simek(michal.simek at xilinx.com) and Hyun.kwon at xilinx.com ACK this patch
>> then it will go into mainline?
>
> I would wait for their feedback.
Please do not apply this patch till I get approval from legal. I have
already discussed things about SPDX some weeks ago.
Thanks,
Michal
^ permalink raw reply
* [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Robert Jarzmik @ 2017-12-18 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214070930.0b885f6d@bbrezillon>
Boris Brezillon <boris.brezillon@free-electrons.com> writes:
>> Robert, it would be great if you could also do more testing on PXA and
>> validate this driver. If needed, a branch ready to be tested is
>> available at [3]. It is based on nand/next and has all the changes
>> brought by the previously mentionned series as well as this one.
>
> Robert, do you think you'll have some time to test Miquel's branch on
> your PXA boards? Miquel already tested on one of these boards (CM-X300),
> but we'd like to have other testers. Also feel free to review the
> driver if have the time.
>
> Thanks,
>
> Boris
Hi Boris and Miquel,
I have applied the whole serie to linux-next yesterday.
A boot attempt on my zylonite with my old defconfig (with the new Marvell NAND
config activated) yields to :
- this message
[ 3.136818] marvell-nfc pxa3xx-nand: could not identify the nand chip
[ 3.143874] marvell-nfc: probe of pxa3xx-nand failed with error -22
- then my board hangs
Is there something to be done to improve the trace level so that you can guess
what's happening ?
Cheers.
--
Robert
^ permalink raw reply
* pxa3xx_nand times out in 4.14 with JFFS2
From: Willy Tarreau @ 2017-12-18 7:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218063715.GA20461@1wt.eu>
On Mon, Dec 18, 2017 at 07:37:15AM +0100, Willy Tarreau wrote:
> > As Boris said, we would really welcome a test of this branch, because
> > you almost have the same setup as Sean in the thread "pxa3xx: wait time
> > out when scanning for bb" and I am running out of explanation for his
> > problem unless it is related to U-Boot. So if you could try booting
> > with and without the on-flash-bbt property and report whether it fails
> > or not it would be of great help!
>
> Yes, I noticed your work mentionned in some of the threads I've read
> during my troubleshooting session and considered giving it a try. I'll
> probably do this next week-end.
Finally I figured the test was quick enough and could help you, so I
built and booted it, I'm getting this at boot :
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error while writing BBT block -110
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error -110 while marking block 1023 bad
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error while writing BBT block -110
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error -110 while marking block 1022 bad
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error while writing BBT block -110
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error -110 while marking block 1021 bad
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error while writing BBT block -110
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error -110 while marking block 1020 bad
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error while writing BBT block -110
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error -110 while marking block 1019 bad
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error while writing BBT block -110
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error -110 while marking block 1018 bad
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error while writing BBT block -110
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error -110 while marking block 1017 bad
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error while writing BBT block -110
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
marvell-nfc f10d0000.nand-controller: Timeout waiting for RB signal
nand_bbt: error -110 while marking block 1016 bad
No space left to write bad block table
nand_bbt: error while writing bad block table -28
marvell-nfc f10d0000.nand-controller: nand_scan_tail failed: -28
marvell-nfc: probe of f10d0000.nand-controller failed with error -28
Then no MTD appears in /proc/mtd.
Hoping this helps,
Willy
^ permalink raw reply
* [RFC PATCH 2/7] gpio: gpiolib: split the gpiod_configure_flags function
From: Ludovic Desroches @ 2017-12-18 7:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9194f01a-d6af-5399-c43b-64117f743379@arm.com>
On Fri, Dec 15, 2017 at 09:26:27AM +0000, Julien Thierry wrote:
> Hi Ludovic,
>
> On 14/12/17 14:21, Ludovic Desroches wrote:
> > The gpiod_configure_flags function doesn't only configure flags, it
> > also performs some processing. It implies that it should be called
> > after having requested the GPIO. Split configuration and processing
> > to allow flags configuration before requesting the GPIO. It is
> > needed if we want to set the pin configuration.
> >
> > Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
> > ---
> > drivers/gpio/gpiolib.c | 49 +++++++++++++++++++++++++++++++------------------
> > drivers/gpio/gpiolib.h | 7 ++++++-
> > 2 files changed, 37 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > index 0621baddfddc..c887602ca0ff 100644
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -3564,23 +3564,9 @@ struct gpio_desc *__must_check gpiod_get_optional(struct device *dev,
> > EXPORT_SYMBOL_GPL(gpiod_get_optional);
> > -/**
> > - * gpiod_configure_flags - helper function to configure a given GPIO
> > - * @desc: gpio whose value will be assigned
> > - * @con_id: function within the GPIO consumer
> > - * @lflags: gpio_lookup_flags - returned from of_find_gpio() or
> > - * of_get_gpio_hog()
> > - * @dflags: gpiod_flags - optional GPIO initialization flags
> > - *
> > - * Return 0 on success, -ENOENT if no GPIO has been assigned to the
> > - * requested function and/or index, or another IS_ERR() code if an error
> > - * occurred while trying to acquire the GPIO.
> > - */
> > -int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
> > +void gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
> > unsigned long lflags, enum gpiod_flags dflags)
> > {
> > - int status;
> > -
> > if (lflags & GPIO_ACTIVE_LOW)
> > set_bit(FLAG_ACTIVE_LOW, &desc->flags);
> > @@ -3601,6 +3587,11 @@ int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
> > if (lflags & GPIO_OPEN_SOURCE)
> > set_bit(FLAG_OPEN_SOURCE, &desc->flags);
>
> Small issue, I believe the patch is missing a '}' here to properly split the
> function.
Thanks, I'll fix it, this ligne was unstaged.
Regards
Ludovic
>
> Otherwise:
>
> Reviewed-by: Julien Thierry <julien.thierry@arm.com>
>
> Cheers,
>
> --
> Julien Thierry
^ permalink raw reply
* [PATCH v7 1/6] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Appana Durga Kedareswara Rao @ 2017-12-18 6:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218041711.GN18649@localhost>
Hi,
Thanks for the review...
<Snip>
>
>On Thu, Dec 07, 2017 at 10:51:02AM +0530, Kedareswara rao Appana wrote:
>
>> @@ -2029,6 +2006,7 @@ static int xilinx_dma_terminate_all(struct
>> dma_chan *dchan)
>>
>> /* Remove and free all of the descriptors in the lists */
>> xilinx_dma_free_descriptors(chan);
>> + chan->idle = true;
>>
>> if (chan->cyclic) {
>> reg = dma_ctrl_read(chan, XILINX_DMA_REG_DMACR); @@ -
>2344,6
>> +2322,12 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device
>*xdev,
>> chan->has_sg = xdev->has_sg;
>> chan->desc_pendingcount = 0x0;
>> chan->ext_addr = xdev->ext_addr;
>> + /* This variable enusres that descripotrs are not
> ^^^^^^^^^^
>
>typo
Since this patch got applied
Will take care of this next time on wards...
Thanks for the review...
Regards,
Kedar.
>
>--
>~Vinod
^ permalink raw reply
* [PATCH v7 0/6] dmaengine: xilinx_dma: Bug fixes
From: Appana Durga Kedareswara Rao @ 2017-12-18 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218051931.GO18649@localhost>
Hi Vinod,
>
>On Thu, Dec 07, 2017 at 10:51:01AM +0530, Kedareswara rao Appana wrote:
>> This patch series fixes below bugs in DMA and VDMA IP's
>> ---> Added channel idle checks in the driver before submitting the buffer
>descriptor to h/w.
>> ---> Fixes bug in Multi frame sotres handling in VDMA Fixes issues
>> ---> w.r.to multi frame descriptors submit with AXI DMA S2MM(recv) Side.
>> ---> Fixed kernel doc warnings in the driver.
>> ---> Fixed checkpatch errors in the driver.
>
>Applied after applying this to fix typo. You seriously need a decent spell checker in
>your editor
Thanks Vinod
Sorry for the noise around spell checks.
Will take care of it next time onwards thanks for pointing it out.
Regards,
Kedar.
>
>- /* This variable enusres that descripotrs are not
>- * Submited when dma engine is in progress. This variable is
>- * Added to avoid pollling for a bit in the status register to
>+ /* This variable ensures that descriptors are not
>+ * Submitted when dma engine is in progress. This variable is
>+ * Added to avoid polling for a bit in the status register to
>
>--
>~Vinod
>--
>To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body
>of a message to majordomo at vger.kernel.org More majordomo info at
>http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] ARM: dts: sun8i: h3: nanopi-m1-plus: fix missing ethernet 0 in aliases
From: Maxime Ripard @ 2017-12-18 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215223901.14500-2-embed3d@gmail.com>
Hi,
On Fri, Dec 15, 2017 at 11:39:00PM +0100, Philipp Rossak wrote:
> Signed-off-by: Philipp Rossak <embed3d@gmail.com>
Please add a commit log here.
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* pxa3xx_nand times out in 4.14 with JFFS2
From: Willy Tarreau @ 2017-12-18 6:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217224617.1f9b8b84@xps13>
Hi guys,
On Sun, Dec 17, 2017 at 10:46:17PM +0100, Miquel RAYNAL wrote:
> > Actually, if things go well it will only be applied to stable
> > releases (I really hope we'll be able to switch to Miquel's driver in
> > 4.16). BTW, if you have some time, maybe you can test Miquel's [1]
> > branch and let us know if it still works properly.
>
> As Boris said, we would really welcome a test of this branch, because
> you almost have the same setup as Sean in the thread "pxa3xx: wait time
> out when scanning for bb" and I am running out of explanation for his
> problem unless it is related to U-Boot. So if you could try booting
> with and without the on-flash-bbt property and report whether it fails
> or not it would be of great help!
Yes, I noticed your work mentionned in some of the threads I've read
during my troubleshooting session and considered giving it a try. I'll
probably do this next week-end.
Thanks!
Willy
^ permalink raw reply
* [PATCH 1/1] arm: sunxi: Add alternative pins for spi0
From: Stefan Mavrodiev @ 2017-12-18 6:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215150823.jplgknururmkvp2t@flea.lan>
On 12/15/2017 05:08 PM, Maxime Ripard wrote:
> Hi,
>
> On Thu, Dec 14, 2017 at 08:24:54AM +0200, Stefan Mavrodiev wrote:
>> On 12/13/2017 05:40 PM, Maxime Ripard wrote:
>>> Hi,
>>>
>>> On Wed, Dec 13, 2017 at 09:44:34AM +0200, Stefan Mavrodiev wrote:
>>>> Allwinner A10/A13/A20 SoCs have pinmux for spi0
>>>> on port C. The patch adds these pins in the respective
>>>> dts includes.
>>>>
>>>> Signed-off-by: Stefan Mavrodiev <stefan@olimex.com>
>>> Do you have any boards that are using these?
>>>
>>> We won't merge that patch if there's no users for it.
>> A20-OLinuXino-Lime/Lime2 and A10-OLinuXino-Lime with spi flash.
>> For A13 we still doesn't have that option.
> If this bus is exposed on the headers, you can add those to the DT but
> leave them disabled if you want. Buf if there's no users of those
> nodes, our policy is not to merge them.
So basically I should resend the patch, enabling the those pins only for
sun4i and sun7i platform?
>
> Thanks!
> Maxime
>
Regards,
Stefan Mavrodiev
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: AKASHI Takahiro @ 2017-12-18 5:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218051657.GA5998@dhcp-128-65.nay.redhat.com>
On Mon, Dec 18, 2017 at 01:16:57PM +0800, Dave Young wrote:
> kexec at fedoraproject... is for Fedora kexec scripts discussion, changed it
> to kexec at lists.infradead.org
>
> Also add linux-acpi list
Thank you.
> On 12/18/17 at 02:31am, Bhupesh Sharma wrote:
> > On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel
> > <ard.biesheuvel@linaro.org> wrote:
> > > On 15 December 2017 at 09:59, AKASHI Takahiro
> > > <takahiro.akashi@linaro.org> wrote:
> > >> On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
> > >>> On 13 December 2017 at 12:16, AKASHI Takahiro
> > >>> <takahiro.akashi@linaro.org> wrote:
> > >>> > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
> > >>> >> On 13 December 2017 at 10:26, AKASHI Takahiro
> > >>> >> <takahiro.akashi@linaro.org> wrote:
> > >>> >> > Bhupesh, Ard,
> > >>> >> >
> > >>> >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> > >>> >> >> Hi Ard, Akashi
> > >>> >> >>
> > >>> >> > (snip)
> > >>> >> >
> > >>> >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
> > >>> >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> > >>> >> >> identify its own usable memory and exclude, at its boot time, any
> > >>> >> >> other memory areas that are part of the panicked kernel's memory.
> > >>> >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> > >>> >> >> , for details)
> > >>> >> >
> > >>> >> > Right.
> > >>> >> >
> > >>> >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
> > >>> >> >> with the crashkernel memory range:
> > >>> >> >>
> > >>> >> >> /* add linux,usable-memory-range */
> > >>> >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> > >>> >> >> result = fdt_setprop_range(new_buf, nodeoffset,
> > >>> >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> > >>> >> >> address_cells, size_cells);
> > >>> >> >>
> > >>> >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
> > >>> >> >> , for details)
> > >>> >> >>
> > >>> >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
> > >>> >> >> they are marked as System RAM or as RESERVED. As,
> > >>> >> >> 'linux,usable-memory-range' dt node is patched up only with
> > >>> >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
> > >>> >> >>
> > >>> >> >> 3). As a result when the crashkernel boots up it doesn't find this
> > >>> >> >> ACPI memory and crashes while trying to access the same:
> > >>> >> >>
> > >>> >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > >>> >> >> -r`.img --reuse-cmdline -d
> > >>> >> >>
> > >>> >> >> [snip..]
> > >>> >> >>
> > >>> >> >> Reserved memory range
> > >>> >> >> 000000000e800000-000000002e7fffff (0)
> > >>> >> >>
> > >>> >> >> Coredump memory ranges
> > >>> >> >> 0000000000000000-000000000e7fffff (0)
> > >>> >> >> 000000002e800000-000000003961ffff (0)
> > >>> >> >> 0000000039d40000-000000003ed2ffff (0)
> > >>> >> >> 000000003ed60000-000000003fbfffff (0)
> > >>> >> >> 0000001040000000-0000001ffbffffff (0)
> > >>> >> >> 0000002000000000-0000002ffbffffff (0)
> > >>> >> >> 0000009000000000-0000009ffbffffff (0)
> > >>> >> >> 000000a000000000-000000affbffffff (0)
> > >>> >> >>
> > >>> >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
> > >>> >> >> memory cap'ing passed to the crash kernel inside
> > >>> >> >> 'arch/arm64/mm/init.c' (see below):
> > >>> >> >>
> > >>> >> >> static void __init fdt_enforce_memory_region(void)
> > >>> >> >> {
> > >>> >> >> struct memblock_region reg = {
> > >>> >> >> .size = 0,
> > >>> >> >> };
> > >>> >> >>
> > >>> >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> > >>> >> >>
> > >>> >> >> if (reg.size)
> > >>> >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
> > >>> >> >> comment this out */
> > >>> >> >> }
> > >>> >> >
> > >>> >> > Please just don't do that. It can cause a fatal damage on
> > >>> >> > memory contents of the *crashed* kernel.
> > >>> >> >
> > >>> >> >> 5). Both the above temporary solutions fix the problem.
> > >>> >> >>
> > >>> >> >> 6). However exposing all System RAM regions to the crashkernel is not
> > >>> >> >> advisable and may cause the crashkernel or some crashkernel drivers to
> > >>> >> >> fail.
> > >>> >> >>
> > >>> >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
> > >>> >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
> > >>> >> >> kernel code and on the other hand the user-space 'kexec-tools' will
> > >>> >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> > >>> >> >> dt node 'linux,usable-memory-range'
> > >>> >> >
> > >>> >> > I still don't understand why we need to carry over the information
> > >>> >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
> > >>> >> > such regions are free to be reused by the kernel after some point of
> > >>> >> > initialization. Why does crash dump kernel need to know about them?
> > >>> >> >
> > >>> >>
> > >>> >> Not really. According to the UEFI spec, they can be reclaimed after
> > >>> >> the OS has initialized, i.e., when it has consumed the ACPI tables and
> > >>> >> no longer needs them. Of course, in order to be able to boot a kexec
> > >>> >> kernel, those regions needs to be preserved, which is why they are
> > >>> >> memblock_reserve()'d now.
> > >>> >
> > >>> > For my better understandings, who is actually accessing such regions
> > >>> > during boot time, uefi itself or efistub?
> > >>> >
> > >>>
> > >>> No, only the kernel. This is where the ACPI tables are stored. For
> > >>> instance, on QEMU we have
> > >>>
> > >>> ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
> > >>> ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
> > >>> 01000013)
> > >>> ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
> > >>> BXPC 00000001)
> > >>> ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
> > >>> BXPC 00000001)
> > >>> ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
> > >>> BXPC 00000001)
> > >>> ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
> > >>> BXPC 00000001)
> > >>> ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
> > >>> BXPC 00000001)
> > >>> ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
> > >>> BXPC 00000001)
> > >>> ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
> > >>> BXPC 00000001)
> > >>>
> > >>> covered by
> > >>>
> > >>> efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
> > >>> ...
> > >>> efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
> > >>
> > >> OK. I mistakenly understood those regions could be freed after exiting
> > >> UEFI boot services.
> > >>
> > >>>
> > >>> >> So it seems that kexec does not honour the memblock_reserve() table
> > >>> >> when booting the next kernel.
> > >>> >
> > >>> > not really.
> > >>> >
> > >>> >> > (In other words, can or should we skip some part of ACPI-related init code
> > >>> >> > on crash dump kernel?)
> > >>> >> >
> > >>> >>
> > >>> >> I don't think so. And the change to the handling of ACPI reclaim
> > >>> >> regions only revealed the bug, not created it (given that other
> > >>> >> memblock_reserve regions may be affected as well)
> > >>> >
> > >>> > As whether we should honor such reserved regions over kexec'ing
> > >>> > depends on each one's specific nature, we will have to take care one-by-one.
> > >>> > As a matter of fact, no information about "reserved" memblocks is
> > >>> > exposed to user space (via proc/iomem).
> > >>> >
> > >>>
> > >>> That is why I suggested (somewhere in this thread?) to not expose them
> > >>> as 'System RAM'. Do you think that could solve this?
> > >>
> > >> Memblock-reserv'ing them is necessary to prevent their corruption and
> > >> marking them under another name in /proc/iomem would also be good in order
> > >> not to allocate them as part of crash kernel's memory.
> > >>
> > >
> > > I agree. However, this may not be entirely trivial, since iterating
> > > over the memblock_reserved table and creating iomem entries may result
> > > in collisions.
> >
> > I found a method (using the patch I shared earlier in this thread) to mark these
> > entries as 'ACPI reclaim memory' ranges rather than System RAM or
> > reserved regions.
> >
> > >> But I'm not still convinced that we should export them in useable-
> > >> memory-range to crash dump kernel. They will be accessed through
> > >> acpi_os_map_memory() and so won't be required to be part of system ram
> > >> (or memblocks), I guess.
> > >
> > > Agreed. They will be covered by the linear mapping in the boot kernel,
> > > and be mapped explicitly via ioremap_cache() in the kexec kernel,
> > > which is exactly what we want in this case.
> >
> > Now this is what is confusing me. I don't see the above happening.
> >
> > I see that the primary kernel boots up and adds the ACPI regions via:
> > acpi_os_ioremap
> > -> ioremap_cache
> >
> > But during the crashkernel boot, ''acpi_os_ioremap' calls
> > 'ioremap' for the ACPI Reclaim Memory regions and not the _cache
> > variant.
It is natural if that region is out of memblocks.
> > And it fails while accessing the ACPI tables:
> >
> > [ 0.039205] ACPI: Core revision 20170728
> > pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
> > [ 0.095098] Internal error: Oops: 96000021 [#1] SMP
this (ESR = 0x96000021) means that Data Abort and Alignment fault happened.
As ioremap() makes the mapping as "Device memory", unaligned memory
access won't be allowed.
> > [ 0.100022] Modules linked in:
> > [ 0.103102] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
> > [ 0.109432] task: ffff000008d05180 task.stack: ffff000008cc0000
> > [ 0.115414] PC is at acpi_ns_lookup+0x25c/0x3c0
> > [ 0.119987] LR is at acpi_ds_load1_begin_op+0xa4/0x294
> > [ 0.125175] pc : [<ffff0000084a6764>] lr : [<ffff00000849b4f8>]
> > pstate: 60000045
> > [ 0.132647] sp : ffff000008ccfb40
> > [ 0.135989] x29: ffff000008ccfb40 x28: ffff000008a9f2a4
> > [ 0.141354] x27: ffff0000088be820 x26: 0000000000000000
> > [ 0.146718] x25: 000000000000001b x24: 0000000000000001
> > [ 0.152083] x23: 0000000000000001 x22: ffff000009710027
> > [ 0.157447] x21: ffff000008ccfc50 x20: 0000000000000001
> > [ 0.162812] x19: 000000000000001b x18: 0000000000000005
> > [ 0.168176] x17: 0000000000000000 x16: 0000000000000000
> > [ 0.173541] x15: 0000000000000000 x14: 000000000000038e
> > [ 0.178905] x13: ffffffff00000000 x12: ffffffffffffffff
> > [ 0.184270] x11: 0000000000000006 x10: 00000000ffffff76
> > [ 0.189634] x9 : 000000000000005f x8 : ffff8000126d0140
> > [ 0.194998] x7 : 0000000000000000 x6 : ffff000008ccfc50
> > [ 0.200362] x5 : ffff80000fe62c00 x4 : 0000000000000001
> > [ 0.205727] x3 : ffff000008ccfbe0 x2 : ffff0000095e3980
> > [ 0.211091] x1 : ffff000009710027 x0 : 0000000000000000
> > [ 0.216456] Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
> > [ 0.223224] Call trace:
> > [ 0.225688] Exception stack(0xffff000008ccfa00 to 0xffff000008ccfb40)
> > [ 0.232194] fa00: 0000000000000000 ffff000009710027
> > ffff0000095e3980 ffff000008ccfbe0
> > [ 0.240106] fa20: 0000000000000001 ffff80000fe62c00
> > ffff000008ccfc50 0000000000000000
> > [ 0.248018] fa40: ffff8000126d0140 000000000000005f
> > 00000000ffffff76 0000000000000006
> > [ 0.255931] fa60: ffffffffffffffff ffffffff00000000
> > 000000000000038e 0000000000000000
> > [ 0.263843] fa80: 0000000000000000 0000000000000000
> > 0000000000000005 000000000000001b
> > [ 0.271754] faa0: 0000000000000001 ffff000008ccfc50
> > ffff000009710027 0000000000000001
> > [ 0.279667] fac0: 0000000000000001 000000000000001b
> > 0000000000000000 ffff0000088be820
> > [ 0.287579] fae0: ffff000008a9f2a4 ffff000008ccfb40
> > ffff00000849b4f8 ffff000008ccfb40
> > [ 0.295491] fb00: ffff0000084a6764 0000000060000045
> > ffff000008ccfb40 ffff000008260a18
> > [ 0.303403] fb20: ffffffffffffffff ffff0000087f3fb0
> > ffff000008ccfb40 ffff0000084a6764
> > [ 0.311316] [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
> > [ 0.316943] [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
> > [ 0.323186] [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
> > [ 0.329428] [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
> > [ 0.335319] [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
> > [ 0.341298] [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
> > [ 0.347101] [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
> > [ 0.353783] [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
> > [ 0.359675] [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
> > [ 0.365479] [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
> > [ 0.371723] [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
> > [ 0.377350] [<ffff000008badc20>] acpi_early_init+0x9c/0xd0
> > [ 0.382891] [<ffff000008b70d50>] start_kernel+0x3b4/0x43c
> > [ 0.388343] Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
> > [ 0.394500] ---[ end trace c46ed37f9651c58e ]---
> > [ 0.399160] Kernel panic - not syncing: Fatal exception
> > [ 0.404437] Rebooting in 10 seconds.
> >
> > So, I think the linear mapping done by the primary kernel does not
> > make these accessible in the crash kernel directly.
> >
> > Any pointers?
>
> Can you get the code line number for acpi_ns_lookup+0x25c?
So should we always avoid ioremap() in acpi_os_ioremap() entirely, or
modify acpi_ns_lookup() (or any acpi functions') to prevent unaligned
accesses?
(I didn't find out how unaligned accesses could happen there.)
Thanks,
-Takahiro AKASHI
> >
> > Regards,
> > Bhupesh
> >
> > >> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> > >> via a kernel command line parameter, "memmap=".
> > >>
> > _______________________________________________
> > kexec mailing list -- kexec at lists.fedoraproject.org
> > To unsubscribe send an email to kexec-leave at lists.fedoraproject.org
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Dave Young @ 2017-12-18 5:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218054009.GA6392@dhcp-128-65.nay.redhat.com>
Fix the kexec list address.
On 12/18/17 at 01:40pm, Dave Young wrote:
> On 12/15/17 at 05:59pm, AKASHI Takahiro wrote:
> > On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
> > > On 13 December 2017 at 12:16, AKASHI Takahiro
> > > <takahiro.akashi@linaro.org> wrote:
> > > > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
> > > >> On 13 December 2017 at 10:26, AKASHI Takahiro
> > > >> <takahiro.akashi@linaro.org> wrote:
> > > >> > Bhupesh, Ard,
> > > >> >
> > > >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> > > >> >> Hi Ard, Akashi
> > > >> >>
> > > >> > (snip)
> > > >> >
> > > >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
> > > >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> > > >> >> identify its own usable memory and exclude, at its boot time, any
> > > >> >> other memory areas that are part of the panicked kernel's memory.
> > > >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> > > >> >> , for details)
> > > >> >
> > > >> > Right.
> > > >> >
> > > >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
> > > >> >> with the crashkernel memory range:
> > > >> >>
> > > >> >> /* add linux,usable-memory-range */
> > > >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> > > >> >> result = fdt_setprop_range(new_buf, nodeoffset,
> > > >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> > > >> >> address_cells, size_cells);
> > > >> >>
> > > >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
> > > >> >> , for details)
> > > >> >>
> > > >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
> > > >> >> they are marked as System RAM or as RESERVED. As,
> > > >> >> 'linux,usable-memory-range' dt node is patched up only with
> > > >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
> > > >> >>
> > > >> >> 3). As a result when the crashkernel boots up it doesn't find this
> > > >> >> ACPI memory and crashes while trying to access the same:
> > > >> >>
> > > >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > > >> >> -r`.img --reuse-cmdline -d
> > > >> >>
> > > >> >> [snip..]
> > > >> >>
> > > >> >> Reserved memory range
> > > >> >> 000000000e800000-000000002e7fffff (0)
> > > >> >>
> > > >> >> Coredump memory ranges
> > > >> >> 0000000000000000-000000000e7fffff (0)
> > > >> >> 000000002e800000-000000003961ffff (0)
> > > >> >> 0000000039d40000-000000003ed2ffff (0)
> > > >> >> 000000003ed60000-000000003fbfffff (0)
> > > >> >> 0000001040000000-0000001ffbffffff (0)
> > > >> >> 0000002000000000-0000002ffbffffff (0)
> > > >> >> 0000009000000000-0000009ffbffffff (0)
> > > >> >> 000000a000000000-000000affbffffff (0)
> > > >> >>
> > > >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
> > > >> >> memory cap'ing passed to the crash kernel inside
> > > >> >> 'arch/arm64/mm/init.c' (see below):
> > > >> >>
> > > >> >> static void __init fdt_enforce_memory_region(void)
> > > >> >> {
> > > >> >> struct memblock_region reg = {
> > > >> >> .size = 0,
> > > >> >> };
> > > >> >>
> > > >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> > > >> >>
> > > >> >> if (reg.size)
> > > >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
> > > >> >> comment this out */
> > > >> >> }
> > > >> >
> > > >> > Please just don't do that. It can cause a fatal damage on
> > > >> > memory contents of the *crashed* kernel.
> > > >> >
> > > >> >> 5). Both the above temporary solutions fix the problem.
> > > >> >>
> > > >> >> 6). However exposing all System RAM regions to the crashkernel is not
> > > >> >> advisable and may cause the crashkernel or some crashkernel drivers to
> > > >> >> fail.
> > > >> >>
> > > >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
> > > >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
> > > >> >> kernel code and on the other hand the user-space 'kexec-tools' will
> > > >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> > > >> >> dt node 'linux,usable-memory-range'
> > > >> >
> > > >> > I still don't understand why we need to carry over the information
> > > >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
> > > >> > such regions are free to be reused by the kernel after some point of
> > > >> > initialization. Why does crash dump kernel need to know about them?
> > > >> >
> > > >>
> > > >> Not really. According to the UEFI spec, they can be reclaimed after
> > > >> the OS has initialized, i.e., when it has consumed the ACPI tables and
> > > >> no longer needs them. Of course, in order to be able to boot a kexec
> > > >> kernel, those regions needs to be preserved, which is why they are
> > > >> memblock_reserve()'d now.
> > > >
> > > > For my better understandings, who is actually accessing such regions
> > > > during boot time, uefi itself or efistub?
> > > >
> > >
> > > No, only the kernel. This is where the ACPI tables are stored. For
> > > instance, on QEMU we have
> > >
> > > ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
> > > ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
> > > 01000013)
> > > ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
> > > BXPC 00000001)
> > > ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
> > > BXPC 00000001)
> > > ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
> > > BXPC 00000001)
> > > ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
> > > BXPC 00000001)
> > > ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
> > > BXPC 00000001)
> > > ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
> > > BXPC 00000001)
> > > ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
> > > BXPC 00000001)
> > >
> > > covered by
> > >
> > > efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
> > > ...
> > > efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
> >
> > OK. I mistakenly understood those regions could be freed after exiting
> > UEFI boot services.
> >
> > >
> > > >> So it seems that kexec does not honour the memblock_reserve() table
> > > >> when booting the next kernel.
> > > >
> > > > not really.
> > > >
> > > >> > (In other words, can or should we skip some part of ACPI-related init code
> > > >> > on crash dump kernel?)
> > > >> >
> > > >>
> > > >> I don't think so. And the change to the handling of ACPI reclaim
> > > >> regions only revealed the bug, not created it (given that other
> > > >> memblock_reserve regions may be affected as well)
> > > >
> > > > As whether we should honor such reserved regions over kexec'ing
> > > > depends on each one's specific nature, we will have to take care one-by-one.
> > > > As a matter of fact, no information about "reserved" memblocks is
> > > > exposed to user space (via proc/iomem).
> > > >
> > >
> > > That is why I suggested (somewhere in this thread?) to not expose them
> > > as 'System RAM'. Do you think that could solve this?
> >
> > Memblock-reserv'ing them is necessary to prevent their corruption and
> > marking them under another name in /proc/iomem would also be good in order
> > not to allocate them as part of crash kernel's memory.
> >
> > But I'm not still convinced that we should export them in useable-
> > memory-range to crash dump kernel. They will be accessed through
> > acpi_os_map_memory() and so won't be required to be part of system ram
> > (or memblocks), I guess.
> > -> Bhupesh?
>
> I forgot how arm64 kernel retrieve the memory ranges and initialize
> them. If no "e820" like interfaces shouldn't kernel reinitialize all
> the memory according to the efi memmap? For kdump kernel anything other
> than usable memory (which is from the dt node instead) should be
> reinitialized according to efi passed info, no?
>
> >
> > Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> > via a kernel command line parameter, "memmap=".
>
> memmap= is only used in old kexec-tools, now we are passing them via
> e820 table.
>
> [snip]
>
> Thanks
> Dave
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Dave Young @ 2017-12-18 5:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215085924.sqlcwm4copzba5ag@fireball>
On 12/15/17 at 05:59pm, AKASHI Takahiro wrote:
> On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
> > On 13 December 2017 at 12:16, AKASHI Takahiro
> > <takahiro.akashi@linaro.org> wrote:
> > > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
> > >> On 13 December 2017 at 10:26, AKASHI Takahiro
> > >> <takahiro.akashi@linaro.org> wrote:
> > >> > Bhupesh, Ard,
> > >> >
> > >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> > >> >> Hi Ard, Akashi
> > >> >>
> > >> > (snip)
> > >> >
> > >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
> > >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> > >> >> identify its own usable memory and exclude, at its boot time, any
> > >> >> other memory areas that are part of the panicked kernel's memory.
> > >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> > >> >> , for details)
> > >> >
> > >> > Right.
> > >> >
> > >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
> > >> >> with the crashkernel memory range:
> > >> >>
> > >> >> /* add linux,usable-memory-range */
> > >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> > >> >> result = fdt_setprop_range(new_buf, nodeoffset,
> > >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> > >> >> address_cells, size_cells);
> > >> >>
> > >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
> > >> >> , for details)
> > >> >>
> > >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
> > >> >> they are marked as System RAM or as RESERVED. As,
> > >> >> 'linux,usable-memory-range' dt node is patched up only with
> > >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
> > >> >>
> > >> >> 3). As a result when the crashkernel boots up it doesn't find this
> > >> >> ACPI memory and crashes while trying to access the same:
> > >> >>
> > >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> > >> >> -r`.img --reuse-cmdline -d
> > >> >>
> > >> >> [snip..]
> > >> >>
> > >> >> Reserved memory range
> > >> >> 000000000e800000-000000002e7fffff (0)
> > >> >>
> > >> >> Coredump memory ranges
> > >> >> 0000000000000000-000000000e7fffff (0)
> > >> >> 000000002e800000-000000003961ffff (0)
> > >> >> 0000000039d40000-000000003ed2ffff (0)
> > >> >> 000000003ed60000-000000003fbfffff (0)
> > >> >> 0000001040000000-0000001ffbffffff (0)
> > >> >> 0000002000000000-0000002ffbffffff (0)
> > >> >> 0000009000000000-0000009ffbffffff (0)
> > >> >> 000000a000000000-000000affbffffff (0)
> > >> >>
> > >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
> > >> >> memory cap'ing passed to the crash kernel inside
> > >> >> 'arch/arm64/mm/init.c' (see below):
> > >> >>
> > >> >> static void __init fdt_enforce_memory_region(void)
> > >> >> {
> > >> >> struct memblock_region reg = {
> > >> >> .size = 0,
> > >> >> };
> > >> >>
> > >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> > >> >>
> > >> >> if (reg.size)
> > >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
> > >> >> comment this out */
> > >> >> }
> > >> >
> > >> > Please just don't do that. It can cause a fatal damage on
> > >> > memory contents of the *crashed* kernel.
> > >> >
> > >> >> 5). Both the above temporary solutions fix the problem.
> > >> >>
> > >> >> 6). However exposing all System RAM regions to the crashkernel is not
> > >> >> advisable and may cause the crashkernel or some crashkernel drivers to
> > >> >> fail.
> > >> >>
> > >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
> > >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
> > >> >> kernel code and on the other hand the user-space 'kexec-tools' will
> > >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> > >> >> dt node 'linux,usable-memory-range'
> > >> >
> > >> > I still don't understand why we need to carry over the information
> > >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
> > >> > such regions are free to be reused by the kernel after some point of
> > >> > initialization. Why does crash dump kernel need to know about them?
> > >> >
> > >>
> > >> Not really. According to the UEFI spec, they can be reclaimed after
> > >> the OS has initialized, i.e., when it has consumed the ACPI tables and
> > >> no longer needs them. Of course, in order to be able to boot a kexec
> > >> kernel, those regions needs to be preserved, which is why they are
> > >> memblock_reserve()'d now.
> > >
> > > For my better understandings, who is actually accessing such regions
> > > during boot time, uefi itself or efistub?
> > >
> >
> > No, only the kernel. This is where the ACPI tables are stored. For
> > instance, on QEMU we have
> >
> > ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
> > ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
> > 01000013)
> > ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
> > BXPC 00000001)
> > ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
> > BXPC 00000001)
> > ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
> > BXPC 00000001)
> > ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
> > BXPC 00000001)
> > ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
> > BXPC 00000001)
> > ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
> > BXPC 00000001)
> > ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
> > BXPC 00000001)
> >
> > covered by
> >
> > efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
> > ...
> > efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
>
> OK. I mistakenly understood those regions could be freed after exiting
> UEFI boot services.
>
> >
> > >> So it seems that kexec does not honour the memblock_reserve() table
> > >> when booting the next kernel.
> > >
> > > not really.
> > >
> > >> > (In other words, can or should we skip some part of ACPI-related init code
> > >> > on crash dump kernel?)
> > >> >
> > >>
> > >> I don't think so. And the change to the handling of ACPI reclaim
> > >> regions only revealed the bug, not created it (given that other
> > >> memblock_reserve regions may be affected as well)
> > >
> > > As whether we should honor such reserved regions over kexec'ing
> > > depends on each one's specific nature, we will have to take care one-by-one.
> > > As a matter of fact, no information about "reserved" memblocks is
> > > exposed to user space (via proc/iomem).
> > >
> >
> > That is why I suggested (somewhere in this thread?) to not expose them
> > as 'System RAM'. Do you think that could solve this?
>
> Memblock-reserv'ing them is necessary to prevent their corruption and
> marking them under another name in /proc/iomem would also be good in order
> not to allocate them as part of crash kernel's memory.
>
> But I'm not still convinced that we should export them in useable-
> memory-range to crash dump kernel. They will be accessed through
> acpi_os_map_memory() and so won't be required to be part of system ram
> (or memblocks), I guess.
> -> Bhupesh?
I forgot how arm64 kernel retrieve the memory ranges and initialize
them. If no "e820" like interfaces shouldn't kernel reinitialize all
the memory according to the efi memmap? For kdump kernel anything other
than usable memory (which is from the dt node instead) should be
reinitialized according to efi passed info, no?
>
> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> via a kernel command line parameter, "memmap=".
memmap= is only used in old kexec-tools, now we are passing them via
e820 table.
[snip]
Thanks
Dave
^ permalink raw reply
* [PATCH] arch/arm64: elfcorehdr should be the first allocation
From: AKASHI Takahiro @ 2017-12-18 5:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB5PR0401MB173388B553457AA08431C361860B0@DB5PR0401MB1733.eurprd04.prod.outlook.com>
On Fri, Dec 15, 2017 at 02:20:15PM +0000, Poonam Aggrwal wrote:
> Thanks Takahiro and Will,
>
> Please find responses below.
>
> Regards
> Poonam
> > -----Original Message-----
> > From: AKASHI Takahiro [mailto:takahiro.akashi at linaro.org]
> > Sent: Wednesday, December 13, 2017 4:17 PM
> > To: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> > Cc: Will Deacon <will.deacon@arm.com>; Prabhakar Kushwaha
> > <prabhakar.kushwaha@nxp.com>; linux-arm-kernel at lists.infradead.org;
> > Poonam Aggrwal <poonam.aggrwal@nxp.com>; G.h. Gao
> > <guanhua.gao@nxp.com>; james.morse at arm.com
> > Subject: Re: [PATCH] arch/arm64: elfcorehdr should be the first allocation
> >
> > On Mon, Dec 11, 2017 at 02:07:14PM +0000, Will Deacon wrote:
> > > On Mon, Dec 11, 2017 at 11:03:32AM +0530, Prabhakar Kushwaha wrote:
> > > > From: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> > > >
> > > > elfcorehdr_addr is assigned by kexec-utils and device tree of dump
> > > > kernel is fixed in chosen node with parameter "linux,elfcorehdr".
> > > > So, memory should be first reserved for elfcorehdr, otherwise
> > > > overlaps may happen with other memory allocations which were done
> > > > before the allocation of elcorehdr in the crash kernel
> > >
> > > What happens in that case? Do you have a crash log we can include in
> > > the commit message?
> >
> > In private discussions with Poonam, he said:
> > | The overlap here I observed was for the reserved-mem areas in the dtb.
> > | And they were specific to NXP device.
> Thanks Takahiro for providing this information.
> Yes the memory overlap happens because when the dump-capture kernel tries to reserve elfcoreheader at the specific address, it finds that the address has already been reserved for some other use by early_init_fdt_scan_reserved_mem().
> Based on the "reserved-memory" node entries in the dts file , the overlap is seen to happen with one of the below alocations:
So the point is that reserve_elfcorehdr() should be placed before
early_init_fdt_scan_reserved_mem() which may allocate memory dynamically,
isn't it. I think it makes sense.
Lisewise, reserve_crashkernel(), which can also allocate memory statically
in case of "crashkernel=SIZE at ADDRESS", should be.
(Even if an overrap might happen, this wouldn't prevent the system from
booting though. We just can't use kdump in this case.)
Thanks,
-Takahiro AKASHI
> [ 0.000000] Reserved memory: created DMA memory pool at 0x00000000fb800000, size 4 MiB
> [ 0.000000] Reserved memory: initialized node qman-fqd, compatible id shared-dma-pool
> [ 0.000000] Reserved memory: created DMA memory pool at 0x00000000f8000000, size 32 MiB
> [ 0.000000] Reserved memory: initialized node qman-pfdr, compatible id shared-dma-pool
> >
> > Since I have not got any details since then, I'm not sure whether your patch is
> > the way to go.
> > (I suspect that we might better fix the issue on kexec-tools side.)
> >
> I may not have full understanding of kexec-tools, but I am not sure how will kexec tools be able to know what addresses will get assigned for the reserved-memory regions in the device tree.
> > Thanks,
> > -Takahiro AKASHI
> >
> > > > Signed-off-by: Guanhua <guanhua.gao@nxp.com>
> > > > Signed-off-by: Poonam Aggrwal <poonam.aggrwal@nxp.com>
> > > > Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> > > > ---
> > >
> > > Really? How on Earth did you get three people co-developing this patch?
> : )Contribution was from all in terms of reproducing, testing on various platforms including the debug experiments. Just wanted to acknowledge the effort.
> > >
> > > > arch/arm64/mm/init.c | 6 ++++--
> > > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index
> > > > 5960bef0170d..551048cfcfff 100644
> > > > --- a/arch/arm64/mm/init.c
> > > > +++ b/arch/arm64/mm/init.c
> > > > @@ -453,6 +453,10 @@ void __init arm64_memblock_init(void)
> > > > * Register the kernel text, kernel data, initrd, and initial
> > > > * pagetables with memblock.
> > > > */
> > > > +
> > > > + /* make this the first reservation so that there are no chances of
> > > > + * overlap */
> > > > + reserve_elfcorehdr();
> > > > memblock_reserve(__pa_symbol(_text), _end - _text); #ifdef
> > > > CONFIG_BLK_DEV_INITRD
> > > > if (initrd_start) {
> > > > @@ -474,8 +478,6 @@ void __init arm64_memblock_init(void)
> > > >
> > > > reserve_crashkernel();
> > > >
> > > > - reserve_elfcorehdr();
> > >
> > > Why isn't this also a problem for reserve_crashkernel() or any other
> > > static reservations?
> Thanks, for raising this. Yes looking at the code flow this may also cause a problem, definitely when the start address of the crash kernel is specified in the bootargs. We mostly tested with just the size, so it was an allocation without a specific address.
>
> > >
> > > Will
^ permalink raw reply
* [PATCH v8] arm64: dts: meson-axg: switch uart_ao clock to CLK81
From: kbuild test robot @ 2017-12-18 5:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215141741.175985-1-yixun.lan@amlogic.com>
Hi Yixun,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.15-rc4 next-20171215]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Yixun-Lan/arm64-dts-meson-axg-switch-uart_ao-clock-to-CLK81/20171218-100949
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
In file included from arch/arm64/boot/dts/amlogic/meson-axg-s400.dts:9:0:
>> arch/arm64/boot/dts/amlogic/meson-axg.dtsi:10:10: fatal error: dt-bindings/clock/axg-clkc.h: No such file or directory
#include <dt-bindings/clock/axg-clkc.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
vim +10 arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> 10 #include <dt-bindings/clock/axg-clkc.h>
11
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 37473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171218/2b7bfe2a/attachment-0001.gz>
^ permalink raw reply
* [PATCH v7 0/6] dmaengine: xilinx_dma: Bug fixes
From: Vinod Koul @ 2017-12-18 5:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512624067-13554-1-git-send-email-appanad@xilinx.com>
On Thu, Dec 07, 2017 at 10:51:01AM +0530, Kedareswara rao Appana wrote:
> This patch series fixes below bugs in DMA and VDMA IP's
> ---> Added channel idle checks in the driver before submitting the buffer descriptor to h/w.
> ---> Fixes bug in Multi frame sotres handling in VDMA
> ---> Fixes issues w.r.to multi frame descriptors submit with AXI DMA S2MM(recv) Side.
> ---> Fixed kernel doc warnings in the driver.
> ---> Fixed checkpatch errors in the driver.
Applied after applying this to fix typo. You seriously need a decent spell
checker in your editor
- /* This variable enusres that descripotrs are not
- * Submited when dma engine is in progress. This variable is
- * Added to avoid pollling for a bit in the status register to
+ /* This variable ensures that descriptors are not
+ * Submitted when dma engine is in progress. This variable is
+ * Added to avoid polling for a bit in the status register to
--
~Vinod
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Dave Young @ 2017-12-18 5:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpPDL0j4o3MuOZ3jRv3UOqM48yTgKtdm-hY+OWL8h-ETzQ@mail.gmail.com>
kexec at fedoraproject... is for Fedora kexec scripts discussion, changed it
to kexec at lists.infradead.org
Also add linux-acpi list
On 12/18/17 at 02:31am, Bhupesh Sharma wrote:
> On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel
> <ard.biesheuvel@linaro.org> wrote:
> > On 15 December 2017 at 09:59, AKASHI Takahiro
> > <takahiro.akashi@linaro.org> wrote:
> >> On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
> >>> On 13 December 2017 at 12:16, AKASHI Takahiro
> >>> <takahiro.akashi@linaro.org> wrote:
> >>> > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
> >>> >> On 13 December 2017 at 10:26, AKASHI Takahiro
> >>> >> <takahiro.akashi@linaro.org> wrote:
> >>> >> > Bhupesh, Ard,
> >>> >> >
> >>> >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> >>> >> >> Hi Ard, Akashi
> >>> >> >>
> >>> >> > (snip)
> >>> >> >
> >>> >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
> >>> >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> >>> >> >> identify its own usable memory and exclude, at its boot time, any
> >>> >> >> other memory areas that are part of the panicked kernel's memory.
> >>> >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> >>> >> >> , for details)
> >>> >> >
> >>> >> > Right.
> >>> >> >
> >>> >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
> >>> >> >> with the crashkernel memory range:
> >>> >> >>
> >>> >> >> /* add linux,usable-memory-range */
> >>> >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> >>> >> >> result = fdt_setprop_range(new_buf, nodeoffset,
> >>> >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> >>> >> >> address_cells, size_cells);
> >>> >> >>
> >>> >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
> >>> >> >> , for details)
> >>> >> >>
> >>> >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
> >>> >> >> they are marked as System RAM or as RESERVED. As,
> >>> >> >> 'linux,usable-memory-range' dt node is patched up only with
> >>> >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
> >>> >> >>
> >>> >> >> 3). As a result when the crashkernel boots up it doesn't find this
> >>> >> >> ACPI memory and crashes while trying to access the same:
> >>> >> >>
> >>> >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> >>> >> >> -r`.img --reuse-cmdline -d
> >>> >> >>
> >>> >> >> [snip..]
> >>> >> >>
> >>> >> >> Reserved memory range
> >>> >> >> 000000000e800000-000000002e7fffff (0)
> >>> >> >>
> >>> >> >> Coredump memory ranges
> >>> >> >> 0000000000000000-000000000e7fffff (0)
> >>> >> >> 000000002e800000-000000003961ffff (0)
> >>> >> >> 0000000039d40000-000000003ed2ffff (0)
> >>> >> >> 000000003ed60000-000000003fbfffff (0)
> >>> >> >> 0000001040000000-0000001ffbffffff (0)
> >>> >> >> 0000002000000000-0000002ffbffffff (0)
> >>> >> >> 0000009000000000-0000009ffbffffff (0)
> >>> >> >> 000000a000000000-000000affbffffff (0)
> >>> >> >>
> >>> >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
> >>> >> >> memory cap'ing passed to the crash kernel inside
> >>> >> >> 'arch/arm64/mm/init.c' (see below):
> >>> >> >>
> >>> >> >> static void __init fdt_enforce_memory_region(void)
> >>> >> >> {
> >>> >> >> struct memblock_region reg = {
> >>> >> >> .size = 0,
> >>> >> >> };
> >>> >> >>
> >>> >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> >>> >> >>
> >>> >> >> if (reg.size)
> >>> >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
> >>> >> >> comment this out */
> >>> >> >> }
> >>> >> >
> >>> >> > Please just don't do that. It can cause a fatal damage on
> >>> >> > memory contents of the *crashed* kernel.
> >>> >> >
> >>> >> >> 5). Both the above temporary solutions fix the problem.
> >>> >> >>
> >>> >> >> 6). However exposing all System RAM regions to the crashkernel is not
> >>> >> >> advisable and may cause the crashkernel or some crashkernel drivers to
> >>> >> >> fail.
> >>> >> >>
> >>> >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
> >>> >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
> >>> >> >> kernel code and on the other hand the user-space 'kexec-tools' will
> >>> >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> >>> >> >> dt node 'linux,usable-memory-range'
> >>> >> >
> >>> >> > I still don't understand why we need to carry over the information
> >>> >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
> >>> >> > such regions are free to be reused by the kernel after some point of
> >>> >> > initialization. Why does crash dump kernel need to know about them?
> >>> >> >
> >>> >>
> >>> >> Not really. According to the UEFI spec, they can be reclaimed after
> >>> >> the OS has initialized, i.e., when it has consumed the ACPI tables and
> >>> >> no longer needs them. Of course, in order to be able to boot a kexec
> >>> >> kernel, those regions needs to be preserved, which is why they are
> >>> >> memblock_reserve()'d now.
> >>> >
> >>> > For my better understandings, who is actually accessing such regions
> >>> > during boot time, uefi itself or efistub?
> >>> >
> >>>
> >>> No, only the kernel. This is where the ACPI tables are stored. For
> >>> instance, on QEMU we have
> >>>
> >>> ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
> >>> ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
> >>> 01000013)
> >>> ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
> >>> BXPC 00000001)
> >>> ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
> >>> BXPC 00000001)
> >>> ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
> >>> BXPC 00000001)
> >>> ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
> >>> BXPC 00000001)
> >>> ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
> >>> BXPC 00000001)
> >>> ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
> >>> BXPC 00000001)
> >>> ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
> >>> BXPC 00000001)
> >>>
> >>> covered by
> >>>
> >>> efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
> >>> ...
> >>> efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
> >>
> >> OK. I mistakenly understood those regions could be freed after exiting
> >> UEFI boot services.
> >>
> >>>
> >>> >> So it seems that kexec does not honour the memblock_reserve() table
> >>> >> when booting the next kernel.
> >>> >
> >>> > not really.
> >>> >
> >>> >> > (In other words, can or should we skip some part of ACPI-related init code
> >>> >> > on crash dump kernel?)
> >>> >> >
> >>> >>
> >>> >> I don't think so. And the change to the handling of ACPI reclaim
> >>> >> regions only revealed the bug, not created it (given that other
> >>> >> memblock_reserve regions may be affected as well)
> >>> >
> >>> > As whether we should honor such reserved regions over kexec'ing
> >>> > depends on each one's specific nature, we will have to take care one-by-one.
> >>> > As a matter of fact, no information about "reserved" memblocks is
> >>> > exposed to user space (via proc/iomem).
> >>> >
> >>>
> >>> That is why I suggested (somewhere in this thread?) to not expose them
> >>> as 'System RAM'. Do you think that could solve this?
> >>
> >> Memblock-reserv'ing them is necessary to prevent their corruption and
> >> marking them under another name in /proc/iomem would also be good in order
> >> not to allocate them as part of crash kernel's memory.
> >>
> >
> > I agree. However, this may not be entirely trivial, since iterating
> > over the memblock_reserved table and creating iomem entries may result
> > in collisions.
>
> I found a method (using the patch I shared earlier in this thread) to mark these
> entries as 'ACPI reclaim memory' ranges rather than System RAM or
> reserved regions.
>
> >> But I'm not still convinced that we should export them in useable-
> >> memory-range to crash dump kernel. They will be accessed through
> >> acpi_os_map_memory() and so won't be required to be part of system ram
> >> (or memblocks), I guess.
> >
> > Agreed. They will be covered by the linear mapping in the boot kernel,
> > and be mapped explicitly via ioremap_cache() in the kexec kernel,
> > which is exactly what we want in this case.
>
> Now this is what is confusing me. I don't see the above happening.
>
> I see that the primary kernel boots up and adds the ACPI regions via:
> acpi_os_ioremap
> -> ioremap_cache
>
> But during the crashkernel boot, ''acpi_os_ioremap' calls
> 'ioremap' for the ACPI Reclaim Memory regions and not the _cache
> variant.
>
> And it fails while accessing the ACPI tables:
>
> [ 0.039205] ACPI: Core revision 20170728
> pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
> [ 0.095098] Internal error: Oops: 96000021 [#1] SMP
> [ 0.100022] Modules linked in:
> [ 0.103102] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
> [ 0.109432] task: ffff000008d05180 task.stack: ffff000008cc0000
> [ 0.115414] PC is at acpi_ns_lookup+0x25c/0x3c0
> [ 0.119987] LR is at acpi_ds_load1_begin_op+0xa4/0x294
> [ 0.125175] pc : [<ffff0000084a6764>] lr : [<ffff00000849b4f8>]
> pstate: 60000045
> [ 0.132647] sp : ffff000008ccfb40
> [ 0.135989] x29: ffff000008ccfb40 x28: ffff000008a9f2a4
> [ 0.141354] x27: ffff0000088be820 x26: 0000000000000000
> [ 0.146718] x25: 000000000000001b x24: 0000000000000001
> [ 0.152083] x23: 0000000000000001 x22: ffff000009710027
> [ 0.157447] x21: ffff000008ccfc50 x20: 0000000000000001
> [ 0.162812] x19: 000000000000001b x18: 0000000000000005
> [ 0.168176] x17: 0000000000000000 x16: 0000000000000000
> [ 0.173541] x15: 0000000000000000 x14: 000000000000038e
> [ 0.178905] x13: ffffffff00000000 x12: ffffffffffffffff
> [ 0.184270] x11: 0000000000000006 x10: 00000000ffffff76
> [ 0.189634] x9 : 000000000000005f x8 : ffff8000126d0140
> [ 0.194998] x7 : 0000000000000000 x6 : ffff000008ccfc50
> [ 0.200362] x5 : ffff80000fe62c00 x4 : 0000000000000001
> [ 0.205727] x3 : ffff000008ccfbe0 x2 : ffff0000095e3980
> [ 0.211091] x1 : ffff000009710027 x0 : 0000000000000000
> [ 0.216456] Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
> [ 0.223224] Call trace:
> [ 0.225688] Exception stack(0xffff000008ccfa00 to 0xffff000008ccfb40)
> [ 0.232194] fa00: 0000000000000000 ffff000009710027
> ffff0000095e3980 ffff000008ccfbe0
> [ 0.240106] fa20: 0000000000000001 ffff80000fe62c00
> ffff000008ccfc50 0000000000000000
> [ 0.248018] fa40: ffff8000126d0140 000000000000005f
> 00000000ffffff76 0000000000000006
> [ 0.255931] fa60: ffffffffffffffff ffffffff00000000
> 000000000000038e 0000000000000000
> [ 0.263843] fa80: 0000000000000000 0000000000000000
> 0000000000000005 000000000000001b
> [ 0.271754] faa0: 0000000000000001 ffff000008ccfc50
> ffff000009710027 0000000000000001
> [ 0.279667] fac0: 0000000000000001 000000000000001b
> 0000000000000000 ffff0000088be820
> [ 0.287579] fae0: ffff000008a9f2a4 ffff000008ccfb40
> ffff00000849b4f8 ffff000008ccfb40
> [ 0.295491] fb00: ffff0000084a6764 0000000060000045
> ffff000008ccfb40 ffff000008260a18
> [ 0.303403] fb20: ffffffffffffffff ffff0000087f3fb0
> ffff000008ccfb40 ffff0000084a6764
> [ 0.311316] [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
> [ 0.316943] [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
> [ 0.323186] [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
> [ 0.329428] [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
> [ 0.335319] [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
> [ 0.341298] [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
> [ 0.347101] [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
> [ 0.353783] [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
> [ 0.359675] [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
> [ 0.365479] [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
> [ 0.371723] [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
> [ 0.377350] [<ffff000008badc20>] acpi_early_init+0x9c/0xd0
> [ 0.382891] [<ffff000008b70d50>] start_kernel+0x3b4/0x43c
> [ 0.388343] Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
> [ 0.394500] ---[ end trace c46ed37f9651c58e ]---
> [ 0.399160] Kernel panic - not syncing: Fatal exception
> [ 0.404437] Rebooting in 10 seconds.
>
> So, I think the linear mapping done by the primary kernel does not
> make these accessible in the crash kernel directly.
>
> Any pointers?
Can you get the code line number for acpi_ns_lookup+0x25c?
>
> Regards,
> Bhupesh
>
> >> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> >> via a kernel command line parameter, "memmap=".
> >>
> _______________________________________________
> kexec mailing list -- kexec at lists.fedoraproject.org
> To unsubscribe send an email to kexec-leave at lists.fedoraproject.org
^ permalink raw reply
* [PATCH] arm64: defconfig: Select schedutil as default cpufreq governor
From: Viresh Kumar @ 2017-12-18 4:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215155040.mlvd56i2rfgd2e2t@armageddon.cambridge.arm.com>
On 15-12-17, 15:50, Catalin Marinas wrote:
> On Thu, Nov 16, 2017 at 11:51:36AM +0530, Viresh Kumar wrote:
> > Currently performance governor is getting selected by default, which is
> > surely not a very good choice as its pretty much power hungry.
> >
> > Select schedutil instead.
>
> And why do we care about this in defconfig? People deploying their own
> kernels in mobile may opt for this config, others may prefer the default
> governor.
>
> Also it seems it would be the only architecture make this governor the
> default, so NAK.
This is a bit dangerous configuration IMHO.
Other architectures have some *real* governor selected by default, like Ondemand
or Conservative. Running your CPUs at max (because of the default performance
governor in arm64 config) may end up burning some SoCs accidentally just because
their thermal stuff doesn't kick in to cool SoC down properly.
So, we should have one of ondemand, conservative and schedutil selected by
default for arm64 as well IMO and schedutil is the one which every one is
falling back to now a days, even android.
--
viresh
^ permalink raw reply
* [PATCH 13/25] arm: spear: dts: Remove leading 0x and 0s from bindings notation
From: Viresh Kumar @ 2017-12-18 4:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215124645.30535-1-malat@debian.org>
On 15-12-17, 13:46, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
>
> Warning (unit_address_format): Node /XXX unit name should not have leading "0x"
>
> and
>
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
>
> Converted using the following command:
>
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e "s/@0+\(.*\) {/@\1 {/g" {} +^C
>
> For simplicity, two sed expressions were used to solve each warnings separately.
>
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
>
> https://elinux.org/Device_Tree_Linux#Linux_conventions
>
> This will solve as a side effect warning:
>
> Warning (simple_bus_reg): Node /XXX@<UPPER> simple-bus unit address format error, expected "<lower>"
>
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x from bindings notation")
>
> Reported-by: David Daney <ddaney@caviumnetworks.com>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Mathieu Malaterre <malat@debian.org>
> ---
> arch/arm/boot/dts/spear1310-evb.dts | 4 ++--
> arch/arm/boot/dts/spear300.dtsi | 2 +-
> arch/arm/boot/dts/spear310.dtsi | 2 +-
> arch/arm/boot/dts/spear320-hmi.dts | 4 ++--
> arch/arm/boot/dts/spear320.dtsi | 2 +-
> 5 files changed, 7 insertions(+), 7 deletions(-)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH v7 1/6] dmaengine: xilinx_dma: Check for channel idle state before submitting dma descriptor
From: Vinod Koul @ 2017-12-18 4:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512624067-13554-2-git-send-email-appanad@xilinx.com>
On Thu, Dec 07, 2017 at 10:51:02AM +0530, Kedareswara rao Appana wrote:
> @@ -2029,6 +2006,7 @@ static int xilinx_dma_terminate_all(struct dma_chan *dchan)
>
> /* Remove and free all of the descriptors in the lists */
> xilinx_dma_free_descriptors(chan);
> + chan->idle = true;
>
> if (chan->cyclic) {
> reg = dma_ctrl_read(chan, XILINX_DMA_REG_DMACR);
> @@ -2344,6 +2322,12 @@ static int xilinx_dma_chan_probe(struct xilinx_dma_device *xdev,
> chan->has_sg = xdev->has_sg;
> chan->desc_pendingcount = 0x0;
> chan->ext_addr = xdev->ext_addr;
> + /* This variable enusres that descripotrs are not
^^^^^^^^^^
typo
--
~Vinod
^ permalink raw reply
* [PATCH v2 0/4] dmaengine: zynqmp_dma: Bug fixes
From: Vinod Koul @ 2017-12-18 4:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512624268-13944-1-git-send-email-appanad@xilinx.com>
On Thu, Dec 07, 2017 at 10:54:24AM +0530, Kedareswara rao Appana wrote:
> This patch series does the below
> --> Fixes kernel doc format style issues.
> --> Fixes warings in the driver.
> --> Fixes issues with overflow interrupt.
> --> Fixes race condition in the probe.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [RESEND PATCH v2] dmaengine: zynqmp_dma: Add runtime pm support
From: Vinod Koul @ 2017-12-18 3:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512624597-14502-1-git-send-email-appanad@xilinx.com>
On Thu, Dec 07, 2017 at 10:59:57AM +0530, Kedareswara rao Appana wrote:
> This patch adds runtime pm support in the driver.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH] clk: sunxi: sun9i-mmc: Implement reset callback for reset controls
From: Chen-Yu Tsai @ 2017-12-18 3:57 UTC (permalink / raw)
To: linux-arm-kernel
Our MMC host driver now issues a reset, instead of just deasserting
the reset control, since commit c34eda69ad4c ("mmc: sunxi: Reset the
device at probe time"). The sun9i-mmc clock driver does not support
this, and will fail, which results in MMC not probing.
This patch implements the reset callback by asserting the reset control,
then deasserting it after a small delay.
Fixes: 7a6fca879f59 ("clk: sunxi: Add driver for A80 MMC config clocks/resets")
Cc: <stable@vger.kernel.org> # 4.14.x
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
drivers/clk/sunxi/clk-sun9i-mmc.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/clk/sunxi/clk-sun9i-mmc.c b/drivers/clk/sunxi/clk-sun9i-mmc.c
index a1a634253d6f..f00d8758ba24 100644
--- a/drivers/clk/sunxi/clk-sun9i-mmc.c
+++ b/drivers/clk/sunxi/clk-sun9i-mmc.c
@@ -16,6 +16,7 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
+#include <linux/delay.h>
#include <linux/init.h>
#include <linux/of.h>
#include <linux/of_device.h>
@@ -83,9 +84,20 @@ static int sun9i_mmc_reset_deassert(struct reset_controller_dev *rcdev,
return 0;
}
+static int sun9i_mmc_reset_reset(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ sun9i_mmc_reset_assert(rcdev, id);
+ udelay(10);
+ sun9i_mmc_reset_deassert(rcdev, id);
+
+ return 0;
+}
+
static const struct reset_control_ops sun9i_mmc_reset_ops = {
.assert = sun9i_mmc_reset_assert,
.deassert = sun9i_mmc_reset_deassert,
+ .reset = sun9i_mmc_reset_reset,
};
static int sun9i_a80_mmc_config_clk_probe(struct platform_device *pdev)
--
2.15.0
^ permalink raw reply related
* [PATCH net-next v6 2/2] net: ethernet: socionext: add AVE ethernet driver
From: Kunihiko Hayashi @ 2017-12-18 3:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215.125749.1752831437819486183.davem@davemloft.net>
Hello David,
On Fri, 15 Dec 2017 12:57:49 -0500 David Miller <davem@davemloft.net> wrote:
> From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
> Date: Thu, 14 Dec 2017 19:05:10 +0900
>
> > +static void ave_desc_write(struct net_device *ndev, enum desc_id id,
> > + int entry, int offset, u32 val)
> > +{
> > + struct ave_private *priv = netdev_priv(ndev);
> > + u32 addr = (id == AVE_DESCID_TX) ? priv->tx.daddr : priv->rx.daddr;
>
> Please always order local variables from longest to shortest line.
>
> Audit your entire submission for this issue, thank you.
I see. I'll fix the order of local variables.
> > + ret = register_netdev(ndev);
> > + if (ret) {
> > + dev_err(dev, "failed to register netdevice\n");
> > + goto out_del_napi;
> > + }
> > +
> > + platform_set_drvdata(pdev, ndev);
>
> You must make all software state settings before reigster_netdev() is
> invoked.
>
> At the exact moment you call register_netdev(), your device can be
> brought up, interrupts processed, PHY state changes made, etc.
>
> So you must put this platform_set_drvdata() before the
> register_netdev() call.
>
> Generally speaking, register_netdev() must always be the last state
> modification done by your probe routine.
Indeed. It's not good to invoke register_netdev() with all software
initialization not completed. I'll move register_netdev() after
all initialization.
Thank you,
---
Best Regards,
Kunihiko Hayashi
^ permalink raw reply
* [PATCH 5/5] arm: dts: sun8i: a83t: bananapi-m3: Enable IR controller
From: Chen-Yu Tsai @ 2017-12-18 3:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217224547.21481-6-embed3d@gmail.com>
On Mon, Dec 18, 2017 at 6:45 AM, Philipp Rossak <embed3d@gmail.com> wrote:
> The Bananapi M3 has an onboard IR receiver.
> This enables the onboard IR receiver subnode.
> Other than the other IR receivers this one needs a base clock frequency
Unlike the other...
> of 3000000 Hz (3 MHz), to be able to work.
>
> Signed-off-by: Philipp Rossak <embed3d@gmail.com>
> ---
> arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> index 6550bf0e594b..2bf25ca64133 100644
> --- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> +++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
> @@ -100,6 +100,13 @@
> status = "okay";
> };
>
> +&ir {
See my other reply about the name.
Otherwise,
Acked-by: Chen-Yu Tsai <wens@csie.org>
> + pinctrl-names = "default";
> + pinctrl-0 = <&ir_pins_a>;
> + clock-frequency = <3000000>;
> + status = "okay";
> +};
> +
> &mdio {
> rgmii_phy: ethernet-phy at 1 {
> compatible = "ethernet-phy-ieee802.3-c22";
> --
> 2.11.0
>
^ 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