* Re: Configure RAM size on iMX53 board
From: Jose Luis Zabalza @ 2016-11-09 4:23 UTC (permalink / raw)
To: barebox
In-Reply-To: <20161108212434.gvlq5fy6vrbn2en5@pengutronix.de>
There is no form of detection. UBoot (a very old version) don't use
any CS1 address, except with the memtest command.
If memtest command is executed with 512MB version, UBoot hangs, as expected.
I set the mem kernel parameter using a environment variable and kernel
can reach CS1 memory.
2016-11-08 22:24 GMT+01:00 Sascha Hauer <s.hauer@pengutronix.de>:
> On Tue, Nov 08, 2016 at 09:51:36PM +0100, Jose Luis Zabalza wrote:
>> > So you have 512MiB on each chip select, so I assume that on the 512MiB
>> > board variants CS1 is not equipped.
>>
>> Yes, it is.
>>
>> >In that case you can in lowlevel.c
>> > test if you find SDRAM on CS1 and if not, disable the chip select
>> > completely in the SDRAM controller.
>>
>> OK. But how ? I enable CS0 and CS1 on DCD table. Is there any way to
>> tell barebox not to use CS1 ?
>>
>> > I am not sure how you can detect if there's SDRAM on CS1. I've seen
>> > situations in which the board just hangs if you access non existent RAM
>> > areas.
>>
>> I have tried it, but I have not be able to implement a code for
>> autodetect. If the code write or read a value on a position without
>> physical chip, the microcontroller hangs. ????
>>
>> But it's not a problem. A solution is configure both CS and MMU. If
>> bootloader don't access to high positions, there is not problem. After
>> I set a environment variable with memory size and the mem kernel
>> parameter (or ATAG) does the rest.
>
> You said that both board variants work with the same U-Boot binary, how
> does it work there? Is there some detection mechanism or is it only some
> environment variable that you have to set manually?
>
> Sascha
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
jlz.3008 a t gmail.com
Linux Counter 172551
https://linuxcounter.net/cert/172551.png
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* linux-next: manual merge of the akpm tree with the jc_docs tree
From: Stephen Rothwell @ 2016-11-09 4:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-next, linux-kernel, Jani Nikula, Mimi Zohar
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in:
Documentation/admin-guide/kernel-parameters.rst
between commit:
e52347bd66f6 ("Documentation/admin-guide: split the kernel parameter list to a separate file")
from the jc_docs tree and patch:
"ima: define a canonical binary_runtime_measurements list format"
from the akpm tree.
I fixed it up (I moved the change to
Documentation/admin-guide/kernel-parameters.txt) and can carry the fix
as necessary. This is now fixed as far as linux-next is concerned, but
any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging. You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [PATCH 3.12 00/72] 3.12.67-stable review
From: Guenter Roeck @ 2016-11-09 4:14 UTC (permalink / raw)
To: Jiri Slaby, stable; +Cc: shuah.kh, linux-kernel, Manfred Spraul, Andrew Morton
In-Reply-To: <8e82115d-6238-f52e-cfb9-e28a08daa647@suse.cz>
On 11/08/2016 07:40 AM, Jiri Slaby wrote:
> On 11/07/2016, 06:16 PM, Guenter Roeck wrote:
>> On 11/07/2016 05:04 AM, Jiri Slaby wrote:
>>> This is the start of the stable review cycle for the 3.12.67 release.
>>> There are 72 patches in this series, all will be posted as a response
>>> to this one. If anyone has any issues with these being applied, please
>>> let me know.
>>>
>>> Responses should be made by Wed Nov 9 14:03:48 CET 2016.
>>> Anything received after that time might be too late.
>>>
>>
>> Build results:
>> total: 128 pass: 127 fail: 1
>> Failed builds:
>> um:defconfig
>>
>> Qemu test results:
>> total: 85 pass: 85 fail: 0
>>
>> Details are available at http://kerneltests.org/builders.
>>
>> Build error log for um:defconfig:
>>
>> ipc/sem.c: In function 'complexmode_tryleave':
>> ipc/sem.c:317:2: error: implicit declaration of function
>> 'smp_store_release'
>> ipc/sem.c: In function 'sem_lock':
>> ipc/sem.c:370:3: error: implicit declaration of function 'smp_load_acquire'
>>
>> Culprit is commit a198951bf258 ("ipc/sem.c: fix complex_count vs. simple
>> op race"),
>> and reverting it fixes the problem. Copying the patch author for feedback.
>
> Oh, thanks!
>
> I backported this to fix the problem:
> commit 577f183acc88645eae116326cc2203dc88ea730c
> Author: Michael S. Tsirkin <mst@redhat.com>
> Date: Mon Dec 21 09:22:18 2015 +0200
>
> x86/um: reuse asm-generic/barrier.h
>
> Everything should be fine now, let's see the results :).
>
Yes, all ok now.
Guenter
^ permalink raw reply
* linux-next: build warning after merge of the akpm-current tree
From: Stephen Rothwell @ 2016-11-09 4:10 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-next, linux-kernel, Huang Shijie
Hi Andrew,
After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
mm/hugetlb.c:1166:21: warning: 'alloc_gigantic_page' defined but not used [-Wunused-function]
static struct page *alloc_gigantic_page(int nid, unsigned int order)
^
Introduced by commit
4acc8ccc3c57 ("mm/hugetlb.c: rename some allocation functions")
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [PATCH v4 0/3] Make core_pattern support namespace
From: Cao Shufeng/曹树烽 @ 2016-11-09 4:06 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
mashimiao.fnst-BthXqXjhjHXQFUHtdCDX3A,
ebiederm-aS9lmoZGLiVWk0Htik3J/w
In-Reply-To: <1477380536-3307-1-git-send-email-caosf.fnst-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
ping
在 2016-10-25二的 15:28 +0800，Cao Shufeng写道：
> This patchset includes following function points:
> 1: Let usermodehelper function possible to set pid namespace
> done by: [PATCH v4 1/3] Make call_usermodehelper_exec possible
> to set pid namespace.
> 2: Let pipe_type core_pattern write dump into container's rootfs
> done by: [PATCH v4 2/3] Limit dump_pipe program's permission to
> init for container.
> 2: Make separate core_pattern setting for each container
> done by: [PATCH v4 3/3] Make core_pattern support namespace
> 3: Compatibility with current system
> also included in: [PATCH v4 3/3] Make core_pattern support namespace
> If container hadn't change core_pattern setting, it will keep
> same setting with host.
>
> Test:
> 1: Pass a test script for each function of this patchset
> ## TEST IN HOST ##
> [root@kerneldev dumptest]# ./test_host
> Set file core_pattern: OK
> ./test_host: line 41: 2366 Segmentation fault (core dumped) "$SCRI=
> PT_BASE_DIR"/make_dump
> Checking dumpfile: OK
> Set file core_pattern: OK
> ./test_host: line 41: 2369 Segmentation fault (core dumped) "$SCRI=
> PT_BASE_DIR"/make_dump
> Checking dump_pipe triggered: OK
> Checking rootfs: OK
> Checking dumpfile: OK
> Checking namespace: OK
> Checking process list: OK
> Checking capabilities: OK
>
> ## TEST IN GUEST ##
> # ./test
> Segmentation fault (core dumped)
> Checking dump_pipe triggered: OK
> Checking rootfs: OK
> Checking dumpfile: OK
> Checking namespace: OK
> Checking process list: OK
> Checking cg pids: OK
> Checking capabilities: OK
> [ 64.940734] make_dump[2432]: segfault at 0 ip 000000000040049d sp 000=
> 07ffc4af025f0 error 6 in make_dump[400000+a6000]
> #
> 2: Pass other test(which is not easy to do in script) by hand.
>
> Changelog v3.1-v4:
> 1. remove extra fork pointed out by:
> Andrei Vagin <avagin@gmail.com>
>
> Changelog v3-v3.1:
> 1. Switch "pwd" of pipe program to container's root fs.
> 2. Rebase on top of v4.9-rc1
>
> Changelog v2->v3:
> 1: Fix problem of setting pid namespace, pointed out by:
> Andrei Vagin <avagin@gmail.com>
>
> Changelog v1(RFC)->v2:
> 1: Add [PATCH 2/2] which was todo in [RFC v1].
> 2: Pass a test script for each function.
> 3: Rebase on top of v4.7.
>
> Suggested-by: Eric W. Biederman <ebiederm@xmission.com>
> Suggested-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
> Signed-off-by: Cao Shufeng <caosf.fnst@cn.fujitsu.com>
>
> Cao Shufeng (2):
> Make call_usermodehelper_exec possible to set namespaces
> Limit dump_pipe program's permission to init for container
>
> Zhao Lei (1):
> Make core_pattern support namespace
>
> fs/coredump.c | 150 +++++++++++++++++++++++++++++++++++++++---
> include/linux/binfmts.h | 2 +
> include/linux/kmod.h | 4 ++
> include/linux/pid_namespace.h | 3 +
> init/do_mounts_initrd.c | 3 +-
> kernel/kmod.c | 43 +++++++++---
> kernel/pid.c | 2 +
> kernel/pid_namespace.c | 2 +
> kernel/sysctl.c | 50 ++++++++++++--
> lib/kobject_uevent.c | 3 +-
> security/keys/request_key.c | 4 +-
> 11 files changed, 241 insertions(+), 25 deletions(-)
>
--
Best Regards,
Cao Shufeng
--------------------------------------------------
Cao Shufeng
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No.6 Wenzhu Road, Nanjing, 210012, China
TEL: +86+25-86630566-8552
FUJITSU INTERNAL: 7998-8552
EMail: caosf.fnst@cn.fujitsu.com
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
^ permalink raw reply
* Re: [PATCH v4 0/3] Make core_pattern support namespace
From: Cao Shufeng/曹树烽 @ 2016-11-09 4:06 UTC (permalink / raw)
To: linux-kernel
Cc: containers, ebiederm, mguzik, kamezawa.hiroyu, stgraber, avagin,
zhaolei, mashimiao.fnst
In-Reply-To: <1477380536-3307-1-git-send-email-caosf.fnst@cn.fujitsu.com>
ping
在 2016-10-25二的 15:28 +0800，Cao Shufeng写道：
> This patchset includes following function points:
> 1: Let usermodehelper function possible to set pid namespace
> done by: [PATCH v4 1/3] Make call_usermodehelper_exec possible
> to set pid namespace.
> 2: Let pipe_type core_pattern write dump into container's rootfs
> done by: [PATCH v4 2/3] Limit dump_pipe program's permission to
> init for container.
> 2: Make separate core_pattern setting for each container
> done by: [PATCH v4 3/3] Make core_pattern support namespace
> 3: Compatibility with current system
> also included in: [PATCH v4 3/3] Make core_pattern support namespace
> If container hadn't change core_pattern setting, it will keep
> same setting with host.
>
> Test:
> 1: Pass a test script for each function of this patchset
> ## TEST IN HOST ##
> [root@kerneldev dumptest]# ./test_host
> Set file core_pattern: OK
> ./test_host: line 41: 2366 Segmentation fault (core dumped) "$SCRI=
> PT_BASE_DIR"/make_dump
> Checking dumpfile: OK
> Set file core_pattern: OK
> ./test_host: line 41: 2369 Segmentation fault (core dumped) "$SCRI=
> PT_BASE_DIR"/make_dump
> Checking dump_pipe triggered: OK
> Checking rootfs: OK
> Checking dumpfile: OK
> Checking namespace: OK
> Checking process list: OK
> Checking capabilities: OK
>
> ## TEST IN GUEST ##
> # ./test
> Segmentation fault (core dumped)
> Checking dump_pipe triggered: OK
> Checking rootfs: OK
> Checking dumpfile: OK
> Checking namespace: OK
> Checking process list: OK
> Checking cg pids: OK
> Checking capabilities: OK
> [ 64.940734] make_dump[2432]: segfault at 0 ip 000000000040049d sp 000=
> 07ffc4af025f0 error 6 in make_dump[400000+a6000]
> #
> 2: Pass other test(which is not easy to do in script) by hand.
>
> Changelog v3.1-v4:
> 1. remove extra fork pointed out by:
> Andrei Vagin <avagin@gmail.com>
>
> Changelog v3-v3.1:
> 1. Switch "pwd" of pipe program to container's root fs.
> 2. Rebase on top of v4.9-rc1
>
> Changelog v2->v3:
> 1: Fix problem of setting pid namespace, pointed out by:
> Andrei Vagin <avagin@gmail.com>
>
> Changelog v1(RFC)->v2:
> 1: Add [PATCH 2/2] which was todo in [RFC v1].
> 2: Pass a test script for each function.
> 3: Rebase on top of v4.7.
>
> Suggested-by: Eric W. Biederman <ebiederm@xmission.com>
> Suggested-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
> Signed-off-by: Cao Shufeng <caosf.fnst@cn.fujitsu.com>
>
> Cao Shufeng (2):
> Make call_usermodehelper_exec possible to set namespaces
> Limit dump_pipe program's permission to init for container
>
> Zhao Lei (1):
> Make core_pattern support namespace
>
> fs/coredump.c | 150 +++++++++++++++++++++++++++++++++++++++---
> include/linux/binfmts.h | 2 +
> include/linux/kmod.h | 4 ++
> include/linux/pid_namespace.h | 3 +
> init/do_mounts_initrd.c | 3 +-
> kernel/kmod.c | 43 +++++++++---
> kernel/pid.c | 2 +
> kernel/pid_namespace.c | 2 +
> kernel/sysctl.c | 50 ++++++++++++--
> lib/kobject_uevent.c | 3 +-
> security/keys/request_key.c | 4 +-
> 11 files changed, 241 insertions(+), 25 deletions(-)
>
--
Best Regards,
Cao Shufeng
--------------------------------------------------
Cao Shufeng
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No.6 Wenzhu Road, Nanjing, 210012, China
TEL: +86+25-86630566-8552
FUJITSU INTERNAL: 7998-8552
EMail: caosf.fnst@cn.fujitsu.com
^ permalink raw reply
* Re: [RFC 2/4] Alsa: control: increment index field for duplicated control.
From: Takashi Sakamoto @ 2016-11-09 4:04 UTC (permalink / raw)
To: Arnaud Pouliquen, alsa-devel, Charles Keepax, Vinod Koul
Cc: Takashi Iwai, broonie, lgirdwood
In-Reply-To: <1478592675-23092-3-git-send-email-arnaud.pouliquen@st.com>
Hi,
On Nov 8 2016 17:11, Arnaud Pouliquen wrote:
> Instead of returning an error when a control is already present, the
> index field is incremented and a warning message is printed.
> This allows drivers to instanciate same control without
> device and sub device number management ( MIXER type controls).
>
> Change-Id: Ifcc60dca9d1cf4c3a424bb9653296678aa7953cb
> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> ---
> sound/core/control.c | 28 ++++++++++++++++++----------
> 1 file changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/sound/core/control.c b/sound/core/control.c
> index fb096cb..014e3f4 100644
> --- a/sound/core/control.c
> +++ b/sound/core/control.c
> @@ -365,6 +365,7 @@ int snd_ctl_add(struct snd_card *card, struct snd_kcontrol *kcontrol)
> struct snd_ctl_elem_id id;
> unsigned int idx;
> unsigned int count;
> + struct snd_kcontrol *elem_set;
> int err = -EINVAL;
>
> if (! kcontrol)
> @@ -376,17 +377,24 @@ int snd_ctl_add(struct snd_card *card, struct snd_kcontrol *kcontrol)
> goto error;
>
> down_write(&card->controls_rwsem);
> - if (snd_ctl_find_id(card, &id)) {
> - up_write(&card->controls_rwsem);
> - dev_err(card->dev, "control %i:%i:%i:%s:%i is already present\n",
> - id.iface,
> - id.device,
> - id.subdevice,
> - id.name,
> - id.index);
> - err = -EBUSY;
> - goto error;
> + while (elem_set = snd_ctl_find_id(card, &id)) {
> + id.index++;
> + if (id.index > UINT_MAX - kcontrol->count) {
> + up_write(&card->controls_rwsem);
> + dev_err(card->dev, "no more free index for control %i:%i:%i:%s\n",
> + id.iface, id.device, id.subdevice, id.name);
> + err = -ENOSPC;
> + goto error;
> + }
> + }
> + if (kcontrol->id.index != id.index) {
> + dev_warn(card->dev, "control %i:%i:%i:%s:%i is already present\n",
> + id.iface, id.device, id.subdevice, id.name, id.index);
> + dev_warn(card->dev, "control index updated from %i to %i\n",
> + kcontrol->id.index, id.index);
> + kcontrol->id.index = id.index;
> }
> +
> if (snd_ctl_find_hole(card, kcontrol->count) < 0) {
> up_write(&card->controls_rwsem);
> err = -ENOMEM;
As Iwai-san explained below, this integration is a bit
over-specification in control core, because your issue is specific in
ALSA SoC part.
On Nov 8 2016 23:30, Takashi Iwai wrote:
> Right, this behavior must be optional. For the normal drivers, the
> duplicated controls *are* errors, and we catch it instead. For
> drivers that are aware of confliction and want the automatic
> workaround (e.g. HD-audio driver does it already), this kind of code
> would be useful to be in the common place.
(http://mailman.alsa-project.org/pipermail/alsa-devel/2016-November/114430.html)
For drivers outside of ALSA SoC part, developers can and should program
control element sets with unique identification information, because
design of sound card is fixed at development time. Therefore, these
codes should be in ALSA SoC core, as I introduced once.
When we have the same requirement for drivers outside of ALSA SoC part,
then we're going to move these codes from ALSA SoC core to ALSA control
core, I think.
Regards
Takashi Sakamoto
^ permalink raw reply
* [U-Boot] [PATCH v2] armv8: fsl-layerscape: Add Readme for deploy QSPI image
From: Yao Yuan @ 2016-11-09 4:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <AM4PR0401MB17329617826C1B50F7892A979AA60@AM4PR0401MB1732.eurprd04.prod.outlook.com>
On 11/09/2016 02:10 AM, York Sun wrote:
> On 11/07/2016 09:44 PM, Yao Yuan wrote:
> > On 11/08/2016 12:46 PM, York Sun wrote:
> >> On 11/07/2016 07:52 PM, Yuan Yao wrote:
> >>> From: Yuan Yao <yao.yuan@nxp.com>
> >>>
> >>> Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
> >>> ---
> >>> Changed in v2:
> >>> Move the readme for QSPI deploy out of only for ls2080aqds.
> >>> ---
> >>> .../arm/cpu/armv8/fsl-layerscape/doc/README.deploy | 44
> >>> ++++++++++++++++++++++
> >>> 1 file changed, 44 insertions(+)
> >>> create mode 100644
> >>> arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
> >>>
> >>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
> >>> b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
> >>> new file mode 100644
> >>> index 0000000..25813b3
> >>> --- /dev/null
> >>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.deploy
> >>> @@ -0,0 +1,44 @@
> >>> +Boot source support Overview
> >>> +-------------------
> >>> + 1. LS1043A
> >>> + LS1043AQDS:QSPI, SD, NOR, NAND
> >>> + LS1043ARDB:SD, NOR, NAND
> >>> + 2. LS2080A
> >>> + LS2080AQDS:QSPI, SD, NOR, NAND
> >>> + LS2080ARDB:NOR, NAND
> >>> + 3. LS1012A
> >>> + LS1012AQDS:QSPI
> >>> + LS1012ARDB:QSPI
> >>> + 4. LS1046A
> >>> + LS1046AQDS:QSPI, SD, NOR, NAND
> >>> + LS1046ARDB:QSPI, SD
> >>> +
> >>
> >> If you plan to add all SD/NAND/QSPI into this document, it is OK to
> >> call it README.deploy. Otherwise it may be better to name as README.qspi.
> >>
> > I'm not be familiar with SD/NAND boot. So should I rename as README.qspi?
> > Or just keep it but waiting for some others to add SD/NAND boot in another
> patch?
> >
>
> We already have NAND boot explained in other document. Stick with the
> procedure you are trying to explain. Keep it simple and we can expand it when
> necessary.
> York
Get it.
I will send v3 soon.
Thanks.
Yao.
^ permalink raw reply
* Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
From: Wen Congyang @ 2016-11-09 3:58 UTC (permalink / raw)
To: Dave Young; +Cc: lersek, anderson, qemu-devel, bhe
In-Reply-To: <20161109031729.GA3675@dhcp-128-65.nay.redhat.com>
On 11/09/2016 11:17 AM, Dave Young wrote:
> Drop qiaonuohan, seems the mail address is wrong..
>
> On 11/09/16 at 11:01am, Dave Young wrote:
>> Hi,
>>
>> Latest linux kernel enabled kaslr to randomiz phys/virt memory
>> addresses, we had some effort to support kexec/kdump so that crash
>> utility can still works in case crashed kernel has kaslr enabled.
>>
>> But according to Dave Anderson virsh dump does not work, quoted messages
>> from Dave below:
>>
>> """
>> with virsh dump, there's no way of even knowing that KASLR
>> has randomized the kernel __START_KERNEL_map region, because there is no
>> virtual address information -- e.g., like "SYMBOL(_stext)" in the kdump
>> vmcoreinfo data to compare against the vmlinux file symbol value.
>> Unless virsh dump can export some basic virtual memory data, which
>> they say it can't, I don't see how KASLR can ever be supported.
>> """
>>
>> I assume virsh dump is using qemu guest memory dump facility so it
>> should be first addressed in qemu. Thus post this query to qemu devel
>> list. If this is not correct please let me know.
IIRC, 'virsh dump --memory-only' uses dump-guest-memory, and 'virsh dump'
uses migration to dump.
I think I should study kaslr first...
Thanks
Wen Congyang
>>
>> Could you qemu dump people make it work? Or we can not support virt dump
>> as long as KASLR being enabled. Latest Fedora kernel has enabled it in x86_64.
>>
>> Thanks
>> Dave
>
>
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] docs: fix COLO architecture diagram
From: Zhang Chen @ 2016-11-09 4:01 UTC (permalink / raw)
To: Hailiang Zhang, qemu devel, Amit Shah
Cc: Jason Wang, eddie . dong, Li Zhijian
In-Reply-To: <acb91fec-6034-c035-ff05-c3397f5f36d5@cn.fujitsu.com>
Does anyone have any comments?
Ping....
Thanks
Zhang Chen
On 11/01/2016 03:06 PM, Zhang Chen wrote:
>
>
> On 11/01/2016 02:25 PM, Hailiang Zhang wrote:
>> Hmm, there are other contents in this file need to be updated,
>> for example, we support blockdev-add command for nbd now,
>> so we can convert the related hmp command to qmp command way.
>> But since we didn't integrate COLO frame with block replication
>> and proxy, It is OK to fix them later.
>>
>> For COLO, the basic capability is still incomplete,
>> but now we got into 'Soft feature freeze' stage,
>> I'm wondering if it is possible at this point to combine
>> COLO frame with proxy and block replication which only needs
>> three or four patches that only touch colo related files ...
>> Or uses still can't test COLO feature in qemu 2.8.
>>
>> Any ideas ? Thanks.
>
> I will send some patch about COLO-Proxy combine with COLO-frame in the
> future.
>
>>
>> On 2016/11/1 11:38, Zhang Chen wrote:
>>> Fix COLO-Proxy part of COLO architecture diagram
>>>
>>> Signed-off-by: Zhang Chen <zhangchen.fnst@cn.fujitsu.com>
>>
>> Reviewed-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
>>
>> All such patches can go through trivial branch.
>>
>> Cc: qemu-trivial@nongnu.org
>
> I think this patch about COLO architecture,
> So, I didn't cc qemu-trivial.
>
>
> Thanks
> Zhang Chen
>
>>
>>> ---
>>> docs/COLO-FT.txt | 72
>>> +++++++++++++++++++++++++++++---------------------------
>>> 1 file changed, 37 insertions(+), 35 deletions(-)
>>>
>>> diff --git a/docs/COLO-FT.txt b/docs/COLO-FT.txt
>>> index 6282938..e289be2 100644
>>> --- a/docs/COLO-FT.txt
>>> +++ b/docs/COLO-FT.txt
>>> @@ -41,41 +41,43 @@ identical responses to all client requests. Once
>>> the differences in the outputs
>>> are detected between the PVM and SVM, COLO withholds transmission
>>> of the
>>> outbound packets until it has successfully synchronized the PVM
>>> state to the SVM.
>>>
>>> - Primary Node Secondary Node
>>> - +------------+ +-----------------------+
>>> +------------------------+ +------------+
>>> - | | | HeartBeat |<----->| HeartBeat
>>> | | |
>>> - | Primary VM | +-----------|-----------+
>>> +-----------|------------+ |Secondary VM|
>>> - | | | | | |
>>> - | | +-----------|-----------+
>>> +-----------|------------+ | |
>>> - | | |QEMU +---v----+ | |QEMU
>>> +----v---+ | | |
>>> - | | | |Failover| | |
>>> |Failover| | | |
>>> - | | | +--------+ | |
>>> +--------+ | | |
>>> - | | | +---------------+ | |
>>> +---------------+ | | |
>>> - | | | | VM Checkpoint |-------------->| VM
>>> Checkpoint | | | |
>>> - | | | +---------------+ | |
>>> +---------------+ | | |
>>> - | | | | |
>>> | | |
>>> -
>>> |Requests<---------------------------^------------------------------------------>Requests|
>>> - |Responses----------------------\ /--|--------------\
>>> /------------------------Responses|
>>> - | | | | | | | | |
>>> | | | |
>>> - | | | +-----------+ | | | | | | |
>>> +------------+ | | |
>>> - | | | | COLO disk | | | | | | | | | COLO
>>> disk | | | |
>>> - | | | | Manager |-|-|--|--------------|--|->|
>>> Manager | | | |
>>> - | | | +|----------+ | | | | | | |
>>> +-----------|+ | | |
>>> - | | | | | | | | | |
>>> | | | | |
>>> - +------------+ +--|------------|-|--|--+
>>> +---|--|--------------|--+ +------------+
>>> - | | | | |
>>> | |
>>> - +-------------+ | +----------v-v--|--+ +---|--v-----------+
>>> | +-------------+
>>> - | VM Monitor | | | COLO Proxy | | COLO Proxy
>>> | | | VM Monitor |
>>> - | | | |(compare packet) | | (adjust
>>> sequence)| | | |
>>> - +-------------+ | +----------|----^--+ +------------------+
>>> | +-------------+
>>> - | | | |
>>> - +------------------|------------|----|--+
>>> +---------------------|------------------+
>>> - | Kernel | | | | |
>>> Kernel | |
>>> - +------------------|------------|----|--+
>>> +---------------------|------------------+
>>> - | | | |
>>> - +--------------v+ +--------v----|--+ +------------------+
>>> +v-------------+
>>> - | Storage | |External Network| | External Network
>>> | | Storage |
>>> - +---------------+ +----------------+ +------------------+
>>> +--------------+
>>> + Primary Node Secondary Node
>>> ++------------+ +-----------------------+
>>> +------------------------+ +------------+
>>> +| | | HeartBeat +<----->+ HeartBeat
>>> | | |
>>> +| Primary VM | +-----------+-----------+
>>> +-----------+------------+ |Secondary VM|
>>> +| | | | | |
>>> +| | +-----------|-----------+
>>> +-----------|------------+ | |
>>> +| | |QEMU +---v----+ | |QEMU
>>> +----v---+ | | |
>>> +| | | |Failover| | | |Failover|
>>> | | |
>>> +| | | +--------+ | | +--------+
>>> | | |
>>> +| | | +---------------+ | |
>>> +---------------+ | | |
>>> +| | | | VM Checkpoint +-------------->+ VM Checkpoint
>>> | | | |
>>> +| | | +---------------+ | |
>>> +---------------+ | | |
>>> +|Requests<--------------------------\ /-----------------\
>>> /--------------------->Requests|
>>> +| | | ^ ^ | | |
>>> | | | |
>>> +|Responses+---------------------\ /-|-|------------\
>>> /-------------------------+Responses|
>>> +| | | | | | | | | | | |
>>> | | | |
>>> +| | | +-----------+ | | | | | | | | | |
>>> +----------+ | | |
>>> +| | | | COLO disk | | | | | | | | | | | | COLO
>>> disk| | | |
>>> +| | | | Manager +---------------------------->|
>>> Manager | | | |
>>> +| | | ++----------+ v v | | | | | v v |
>>> +---------++ | | |
>>> +| | | |+-----------+-+-+-++| |
>>> ++-+--+-+---------+ | | | |
>>> +| | | || COLO Proxy || | | COLO Proxy
>>> | | | | |
>>> +| | | || (compare packet || | |(adjust sequence
>>> | | | | |
>>> +| | | ||and mirror packet)|| | | and ACK)
>>> | | | | |
>>> +| | | |+------------+---+-+| |
>>> +-----------------+ | | | |
>>> ++------------+ +-----------------------+
>>> +------------------------+ +------------+
>>> ++------------+ | | |
>>> | +------------+
>>> +| VM Monitor | | | |
>>> | | VM Monitor |
>>> ++------------+ | | |
>>> | +------------+
>>> ++---------------------------------------+
>>> +----------------------------------------+
>>> +| Kernel | | | | | Kernel
>>> | |
>>> ++---------------------------------------+
>>> +----------------------------------------+
>>> + | | | |
>>> + +--------------v+ +---------v---+--+ +------------------+
>>> +v-------------+
>>> + | Storage | |External Network| | External Network
>>> | | Storage |
>>> + +---------------+ +----------------+ +------------------+
>>> +--------------+
>>> +
>>>
>>> == Components introduction ==
>>>
>>>
>>
>>
>>
>> .
>>
>
--
Thanks
zhangchen
^ permalink raw reply
* When I clone the kernel source, I encounter a fatal error.
From: Hao Lee @ 2016-11-09 4:01 UTC (permalink / raw)
To: kernelnewbies
In-Reply-To: <20161108160750.GA6384@battlestar.xayto.local>
I have tried packedGitWindowSize, packedGitLimit, windowMemory,
packSizeLimit and other options, but it seems that cloning the whole
history still need a lot of memory and Git will be killed by OOM.
Finally, I find that I can clone the latest commit of all branches
with 'git clone --depth=1 --no-single-branch'. Although my local
repository doesn't have any history commits, I can still track remote
updates.
I hope my approach can help someone who want to have a lightweight repository.
Thanks for everyone's help !
Thanks,
Hao Lee.
^ permalink raw reply
* [PATCH] sequencer: silence -Wtautological-constant-out-of-range-compare
From: Jeff King @ 2016-11-09 3:57 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Lars Schneider
When clang compiles sequencer.c, it complains:
sequencer.c:632:14: warning: comparison of constant 2 with
expression of type 'const enum todo_command' is always
true [-Wtautological-constant-out-of-range-compare]
if (command < ARRAY_SIZE(todo_command_strings))
This is because "command" is an enum that may only have two
values (0 and 1) and the array in question has two elements.
As it turns out, clang is actually wrong here, at least
according to its own bug tracker:
https://llvm.org/bugs/show_bug.cgi?id=16154
But it's still worth working around this, as the warning is
present with -Wall, meaning we fail compilation with "make
DEVELOPER=1".
Casting the enum to size_t sufficiently unconfuses clang. As
a bonus, it also catches any possible out-of-bounds access
if the enum takes on a negative value (which shouldn't
happen either, but again, this is a defensive check).
Signed-off-by: Jeff King <peff@peff.net>
---
I know that a different fix is coming in a follow-on series, but I think
it's worth doing this to un-break clang on master (and v2.11) in the
meantime.
sequencer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index 5fd75f30d..6f0ff9e41 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -629,7 +629,7 @@ static const char *todo_command_strings[] = {
static const char *command_to_string(const enum todo_command command)
{
- if (command < ARRAY_SIZE(todo_command_strings))
+ if ((size_t)command < ARRAY_SIZE(todo_command_strings))
return todo_command_strings[command];
die("Unknown command: %d", command);
}
--
2.11.0.rc0.263.g6f44bc3
^ permalink raw reply related
* Re: [B.A.T.M.A.N.] i have a question ? How many relay nodes can be supported at NetworkCoding ( mtu 1546 ) .
From: johnzeng @ 2016-11-09 3:56 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: b.a.t.m.a.n, Sven Eckelmann, Martin Hundebøll
In-Reply-To: <58229D06.8030207@yahoo.com>
>
> Hello Dear Simon:
Sorry , *there is a clerical error ,
i updated for it ( layer2 --> layer3 **second line)
*
>
> How will i do via batctl ? Do you mean
> that batman-adv can support it by default at layer 2 ?
>
> if Relay mode is based on Layer 3 (
> route or Nat ) , it will be very complex and Infeasible at large wifi
> network
>
> let's assume the environment , node A
> can communicate with node B directly via wifi and node B can
> communicate with node C directly via wifi.
>
> but node A can't communicate with node C
> directly via wifi ( master reason : Weak signal) ,
>
> Maybe Batman-adv can forward full
> Broadcast packet to next nodeC via nodeB , but if node A will build
> tcp connection between node A and nodeC ,
>
> I can understand network coding , it will
> be same as proxy or Intermediator at Layer 2 ,
>
>
> Your meaning : Batman-adv can build
> Similar mechanism ( Intermediator ) via intermediator , it wil be
> relay based real application packet ( not relay based Broadcast packet)
>
>
> Thanks
>
> Best Regards
>
> TIger
>> On Tuesday, November 8, 2016 11:55:14 AM CET johnzeng via B.A.T.M.A.N
>> wrote:
>>> Hello Dear Sven and Martin:
>>>
>>> Thanks for your
>>> advisement
>>>
>>> I hope to aviod
>>> Excavation
>>> of underground pipeline in the smart community or Park .
>>>
>>> if Batman-adv can
>>> support
>>> smart relay ( networking code ) at mesh network really , and it will be
>>> very valuable for us .
>> Hi Johnzeng,
>>
>> why are you insisting on using network coding? Batman-adv can do
>> relay without
>> network coding enabled, this is part of the basic mesh technology.
>> Network
>> Coding (or CATWOMAN) was research project/proof of concept
>> implementation
>> which isn't actively maintained right now. But from what I
>> understood, your
>> setups can be supported with "standard" batman-adv mesh.
>>
>> Thanks,
>> Simon
>>
>>> i think one of core
>>> valuable point is relay mode and Client roaming
>>>
>>> i prepare to build
>>> more ap
>>> evironment and test for the part later
>>>
>>>
>>>
>>>
>>> As market competition intensifies,
>>>
>>> the gap between similar
>>> productsis getting smaller and smaller,
>>>
>>> likewise the
>>> evolution of
>>> growing homogenization trends within the industry.
>>>
>>>
>>>
>>> i hope we can find
>>> valuable point for Blue Ocean each other .
>>>
>>> if you have some
>>> different
>>> point , and I would be happy to be the first and build win-win mode
>>> each
>>> other .
>>>
>>>
>>> Best Regards
>>>
>>> Tiger
>>>
>>>> Hi,
>>>>
>>>>> When i compile the part , whether i need make
>>>>> CONFIG_BATMAN_ADV_BATMAN_V=y at batman-adv-2016.2
>>>> 2016.2 is "old". And BATMAN_V has nothing to do with network coding.
>>>>
>>>>> i read some detail about NetworkCoding , my understanding :
>>>>>
>>>>> every relay node will detects neighbors packet at promisc mode and
>>>>> combine these packet into a single transmission ,
>>>> I think Martin can help here. He also provided some documentation:
>>>>
>>>> * https://www.open-mesh.org/projects/batman-adv/wiki/NetworkCoding
>>>> *
>>>> https://www.open-mesh.org/projects/batman-adv/wiki/NetworkCoding-technica
>>>>
>>>> l *
>>>> https://downloads.open-mesh.org/batman/papers/batman-adv_network_coding.p
>>>>
>>>> df *
>>>> https://vbn.aau.dk/da/publications/catwoman(214ee21a-e786-495d-85c9-3efac
>>>>
>>>> 4718ead).html *
>>>> https://downloads.open-mesh.org/batman/misc/wbmv4-network_coding.avi
>>>>
>>>> And it will not try to forward each packet is overheard. Instead it
>>>> will try to find coding opportunities which it then uses to forward
>>>> its own packets in less transmissions (by using packets which the
>>>> other nodes should already know).
>>>>
>>>>> batctl nc 1
>>>>> echo 1 > /sys/class/net/bat0/mesh/network_coding
>>>>> ip link set dev wlan0 promisc on
>>>>> ip link set dev wlan0 mtu 1546
>>>> Your cards/drivers will most likely not even support promiscuous mode.
>>>> Some of them require to have an monitor mode interface at the same
>>>> time
>>>> and
>>>> some of them will simply not work.
>>>>
>>>> You can test it by simply checking what tcpdump is showing you on the
>>>> underlying interface (wlan0). If it doesn't show you the packets
>>>> between
>>>> two other nodes then promiscuous mode is not working for you.
>>>>
>>>> The feature itself is not used very often (Martin, please correct me
>>>> here).
>>>> It is not enabled by default because it is not making things
>>>> "better" all
>>>> the time [1]. So it is also not tested as much as other components in
>>>> batman-adv and you should think first if it is really useful for your
>>>> scenario/HW. I knew at least from some Freifunk communities played
>>>> around
>>>> when it was enabled by default but had to revert when they experienced
>>>> "non
>>>> functional mesh links" (nothing more about it is known to me - sorry
>>>> Martin).>
>>>>> if i send a packet from host A to hostC via hostB, whether hostB will
>>>>> open relay mode at layer2 .
>>>> I completely failed to parse this.
>>>>
>>>> batman-adv will send your data from hostA to hostC via hostB when
>>>> the TQ
>>>> value for the link "from hostA to hostC via hostB" is higher than
>>>> the TQ
>>>> value for the link "hostA to hostC directly". This has nothing to
>>>> do with
>>>> network coding and is a standard feature of batman-adv (this is
>>>> actually
>>>> what it is about).
>>>>
>>>> network coding can only (when lucky) try to combine some packets - but
>>>> this will only work when promiscuous mode is actually working and the
>>>> nodes can overhear packets. Otherwise it will (in theory - Martin
>>>> please
>>>> correct me if I overlooked a safety mechanism) just create a lot of
>>>> coded
>>>> packets which cannot be decoded anymore. This seems to be especially
>>>> problematic when some nodes are for example 2x2 MIMO devices and
>>>> others
>>>> are 3x3. At least this would be a good way to let the 2x2 miss
>>>> important
>>>> packets when the 3x3 devices talk between each other.
>>>>
>>>> I would even guess that things like dynamic transmission power
>>>> would make
>>>> overhearing packets also more problematic.
>>>>
>>>>> but i have a question ? How many relay nodes can be supported at
>>>>> NetworkCoding ( mtu 1546 ) .
>>>> I am not sure what you are asking here. The implementation in
>>>> batman-adv
>>>> can combine two packets into one. And this combining of these two
>>>> packets
>>>> is done by exact one relay node. The decoding is done by the two
>>>> receiving
>>>> nodes. What you can build with it is been shown in the
>>>> documentation from
>>>> Martin. The network coding used here is therefore done by a relay
>>>> node and
>>>> its neighbors. But there can be multiple relay nodes in the mesh doing
>>>> network coding at the same time.
>>>>
>>>>
>>>> I personally haven't used network coding with batman-adv. But since
>>>> you've
>>>> created multiple new threads on the mailing list [1,2,3,4] (beside the
>>>> private mail *grml*) - here is at least a pseudo-answer.
>>>>
>>>> Kind regards,
>>>> Sven
>>>>
>>>> [1]
>>>> https://www.open-mesh.org/projects/batman-adv/wiki/NetworkCoding#Drawback
>>>>
>>>> s [2]
>>>> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-November/016586.ht
>>>>
>>>> ml [3]
>>>> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-November/016587.ht
>>>>
>>>> ml [4]
>>>> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-November/016588.ht
>>>>
>>>> ml [5]
>>>> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-November/016592.ht
>>>>
>>>> ml
>>> End of encapsulated message
>
^ permalink raw reply
* Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")]
From: Feng Tang @ 2016-11-09 3:54 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Thomas Gleixner, Feng Tang, Rafael J. Wysocki, Wysocki, Rafael J,
Steven Rostedt, Sebastian Andrzej Siewior,
linux-arch@vger.kernel.org, Rik van Riel, Srivatsa S. Bhat,
Peter Zijlstra, Arjan van de Ven, Rusty Russell, Oleg Nesterov,
Tejun Heo, Andrew Morton, Paul McKenney, Linus Torvalds,
Paul Turner
In-Reply-To: <20161101204737.GB4617@intel.com>
On Wed, Nov 02, 2016 at 04:47:37AM +0800, Ville Syrjälä wrote:
> On Fri, Oct 28, 2016 at 08:58:41PM +0200, Thomas Gleixner wrote:
> > On Fri, 28 Oct 2016, Ville Syrjälä wrote:
> > > On Thu, Oct 27, 2016 at 10:41:18PM +0200, Thomas Gleixner wrote:
> > > > On Thu, 27 Oct 2016, Ville Syrjälä wrote:
> > > > > On Thu, Oct 27, 2016 at 09:25:05PM +0200, Thomas Gleixner wrote:
> > > > > > So it would be interesting whether that hunk in resume_broadcast() is
> > > > > > sufficient.
> > > > >
> > > > > So far it looks like the answer is yes.
> > > > >
> > > > > Looks to be about 5 seconds slower than acpi-idle in resuming, but
> > > > > I suppose that's not all that surprising ;)
> > > >
> > > > Well, set it to 1msec then. If that works reliably then we really can do
> > > > that unconditionally. There is no harm in firing a useless timer during
> > > > resume once.
> > >
> > > I narrowed down the required timeout, and looks like 25ms is the
> > > minimum that works. With 24ms I already started to have failures. So
> > > maybe just bump it up by an order of magnitude to 250ms for some
> > > safety margin?
>
> I left the thing running for the weekend and it failed 26 out of 16057
> times with the 25ms timeout. Looks like it takes ~5 minutes to resume
> when it fails, but eventually it does come back.
>
Just came back from a travel. Yes, the 5 minutes delay may be due to the
expiration of the HPET timer, counting from 0 to 0xffffffff for a 13M
frequencey HPET takes about 300 seconds. After resume, it seems nobody
arms it so my old patch forces to arm one event.
Thanks,
Feng
^ permalink raw reply
* drm/bridge: analogix_dp: clear psr_support when disable_bridge
From: Caesar Wang @ 2016-11-09 3:53 UTC (permalink / raw)
To: seanpaul
Cc: dri-devel, linux-kernel, tomeu.vizoso, linux-rockchip, marcheu,
zain wang, Caesar Wang
From: zain wang <wzz@rock-chips.com>
Don't run psr work during enabling bridge when you restart ui, it may make
link training fail since there is a race between them in AUX CH resource.
Signed-off-by: zain wang <wzz@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: dri-devel@lists.freedesktop.org
Cc: Sean Paul <seanpaul@chromium.org>
---
BTW:
- The training issue is gone with this patch,
there are four machines have passed the 10000 cycles with S2R tests.
- Verified on ChromeOS kernelv4.4.
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6e0447f..4431f62 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1117,6 +1117,7 @@ static void analogix_dp_bridge_disable(struct drm_bridge *bridge)
if (ret)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
+ dp->psr_support = false;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
--
2.7.4
^ permalink raw reply related
* drm/bridge: analogix_dp: clear psr_support when disable_bridge
From: Caesar Wang @ 2016-11-09 3:53 UTC (permalink / raw)
To: seanpaul
Cc: zain wang, tomeu.vizoso, linux-kernel, dri-devel, linux-rockchip,
marcheu, Caesar Wang
From: zain wang <wzz@rock-chips.com>
Don't run psr work during enabling bridge when you restart ui, it may make
link training fail since there is a race between them in AUX CH resource.
Signed-off-by: zain wang <wzz@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: dri-devel@lists.freedesktop.org
Cc: Sean Paul <seanpaul@chromium.org>
---
BTW:
- The training issue is gone with this patch,
there are four machines have passed the 10000 cycles with S2R tests.
- Verified on ChromeOS kernelv4.4.
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6e0447f..4431f62 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1117,6 +1117,7 @@ static void analogix_dp_bridge_disable(struct drm_bridge *bridge)
if (ret)
DRM_ERROR("failed to setup the panel ret = %d\n", ret);
+ dp->psr_support = false;
dp->dpms_mode = DRM_MODE_DPMS_OFF;
}
--
2.7.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [U-Boot] [PATCH v3] armv8: fsl-layerscape: Add Readme for deploy QSPI image
From: Yuan Yao @ 2016-11-09 3:50 UTC (permalink / raw)
To: u-boot
From: Yuan Yao <yao.yuan@nxp.com>
Signed-off-by: Yuan Yao <yao.yuan@nxp.com>
---
Changed in v3:
Rename README.deploy to README.qspi
Changed in v2:
Move the readme for QSPI deploy out of only for ls2080aqds.
---
arch/arm/cpu/armv8/fsl-layerscape/doc/README.qspi | 42 +++++++++++++++++++++++
1 file changed, 42 insertions(+)
create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/doc/README.qspi
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.qspi b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.qspi
new file mode 100644
index 0000000..de86f4b
--- /dev/null
+++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.qspi
@@ -0,0 +1,42 @@
+QSPI Boot source support Overview
+-------------------
+ 1. LS1043A
+ LS1043AQDS
+ 2. LS2080A
+ LS2080AQDS
+ 3. LS1012A
+ LS1012AQDS
+ LS1012ARDB
+ 4. LS1046A
+ LS1046AQDS
+ LS1046ARDB
+
+Booting from QSPI
+-------------------
+Booting from QSPI requires two images, RCW and u-boot-dtb.bin.
+The difference between QSPI boot RCW image and NOR boot image is the PBI
+command sequence for setting the boot location pointer. It's should point
+to the address for u-boot in QSPI flash.
+
+RCW image should be written to the beginning of QSPI flash device.
+Example of using u-boot command
+
+=> sf probe 0:0
+SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+=> sf erase 0 +<size of rcw image>
+SF: 65536 bytes @ 0x0 Erased: OK
+=> sf write <rcw image in memory> 0 <size of rcw image>
+SF: 164 bytes @ 0x0 Written: OK
+
+To get the QSPI image, build u-boot with QSPI config, for example,
+<board_name>_qspi_defconfig. The image needed is u-boot-dtb.bin.
+The u-boot image should be written to 0x10000(but 0x1000 for LS1043A, LS2080A).
+
+=> sf probe 0:0
+SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB
+=> sf erase 10000 +<size of u-boot image>
+SF: 589824 bytes @ 0x10000 Erased: OK
+=> sf write <u-boot image in memory> 10000 <size of u-boot image>
+SF: 580966 bytes @ 0x10000 Written: OK
+
+With these two images in QSPI flash device, the board can boot from QSPI.
--
2.1.0.27.g96db324
^ permalink raw reply related
* Re: [lustre-devel] [PATCH] staging: lustre: ldlm: pl_recalc time handling is wrong
From: Dilger, Andreas @ 2016-11-09 3:50 UTC (permalink / raw)
To: James Simmons, Arnd Bergmann
Cc: Greg Kroah-Hartman, devel@driverdev.osuosl.org, Drokin, Oleg,
Linux Kernel Mailing List, Lustre Development List
In-Reply-To: <1478573240-12850-1-git-send-email-jsimmons@infradead.org>
On Nov 7, 2016, at 19:47, James Simmons <jsimmons@infradead.org> wrote:
>
> The ldlm_pool field pl_recalc_time is set to the current
> monotonic clock value but the interval period is calculated
> with the wall clock. This means the interval period will
> always be far larger than the pl_recalc_period, which is
> just a small interval time period. The correct thing to
> do is to use monotomic clock current value instead of the
> wall clocks value when calculating recalc_interval_sec.
It looks like this was introduced by commit 8f83409cf
"staging/lustre: use 64-bit time for pl_recalc" but that patch changed
get_seconds() to a mix of ktime_get_seconds() and ktime_get_real_seconds()
for an unknown reason. It doesn't appear that there is any difference
in overhead between the two (on 64-bit at least).
Since the ldlm pool recalculation interval is actually driven in response to
load on the server, it makes sense to use the "real" time instead of the
monotonic time (if I understand correctly) if the client is in a VM that
may periodically be blocked and "miss time" compared to the outside world.
Using the "real" clock, the recalc_interval_sec will correctly reflect the
actual elapsed time rather than just the number of ticks inside the VM.
Is my understanding of these different clocks correct?
Cheers, Andreas
>
> Signed-off-by: James Simmons <jsimmons@infradead.org>
> ---
> drivers/staging/lustre/lustre/ldlm/ldlm_pool.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c b/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c
> index 19831c5..30d4f80 100644
> --- a/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c
> +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c
> @@ -256,7 +256,7 @@ static int ldlm_cli_pool_recalc(struct ldlm_pool *pl)
> time64_t recalc_interval_sec;
> int ret;
>
> - recalc_interval_sec = ktime_get_real_seconds() - pl->pl_recalc_time;
> + recalc_interval_sec = ktime_get_seconds() - pl->pl_recalc_time;
> if (recalc_interval_sec < pl->pl_recalc_period)
> return 0;
>
> @@ -264,7 +264,7 @@ static int ldlm_cli_pool_recalc(struct ldlm_pool *pl)
> /*
> * Check if we need to recalc lists now.
> */
> - recalc_interval_sec = ktime_get_real_seconds() - pl->pl_recalc_time;
> + recalc_interval_sec = ktime_get_seconds() - pl->pl_recalc_time;
> if (recalc_interval_sec < pl->pl_recalc_period) {
> spin_unlock(&pl->pl_lock);
> return 0;
> @@ -301,7 +301,7 @@ static int ldlm_cli_pool_recalc(struct ldlm_pool *pl)
> * Time of LRU resizing might be longer than period,
> * so update after LRU resizing rather than before it.
> */
> - pl->pl_recalc_time = ktime_get_real_seconds();
> + pl->pl_recalc_time = ktime_get_seconds();
> lprocfs_counter_add(pl->pl_stats, LDLM_POOL_TIMING_STAT,
> recalc_interval_sec);
> spin_unlock(&pl->pl_lock);
> --
> 1.7.1
>
> _______________________________________________
> lustre-devel mailing list
> lustre-devel@lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
^ permalink raw reply
* Re: [B.A.T.M.A.N.] i have a question ? How many relay nodes can be supported at NetworkCoding ( mtu 1546 ) .
From: johnzeng @ 2016-11-09 3:50 UTC (permalink / raw)
To: Simon Wunderlich; +Cc: b.a.t.m.a.n, Sven Eckelmann, Martin Hundebøll
In-Reply-To: <23104849.8bNq0ZtGq3@prime>
Hello Dear Simon:
How will i do via batctl ? Do you mean
that batman-adv can support it by default at layer 2 ?
if Relay mode is based on Layer 2 ( route
or Nat ) , it will be very complex and Infeasible at large wifi network
let's assume the environment , node A
can communicate with node B directly via wifi and node B can
communicate with node C directly via wifi.
but node A can't communicate with node C
directly via wifi ( master reason : Weak signal) ,
Maybe Batman-adv can forward full
Broadcast packet to next nodeC via nodeB , but if node A will build tcp
connection between node A and nodeC ,
I can understand network coding , it will
be same as proxy or Intermediator at Layer 2 ,
Your meaning : Batman-adv can build
Similar mechanism ( Intermediator ) via intermediator , it wil be
relay based real application packet ( not relay based Broadcast packet)
Thanks
Best Regards
TIger
> On Tuesday, November 8, 2016 11:55:14 AM CET johnzeng via B.A.T.M.A.N wrote:
>> Hello Dear Sven and Martin:
>>
>> Thanks for your advisement
>>
>> I hope to aviod Excavation
>> of underground pipeline in the smart community or Park .
>>
>> if Batman-adv can support
>> smart relay ( networking code ) at mesh network really , and it will be
>> very valuable for us .
> Hi Johnzeng,
>
> why are you insisting on using network coding? Batman-adv can do relay without
> network coding enabled, this is part of the basic mesh technology. Network
> Coding (or CATWOMAN) was research project/proof of concept implementation
> which isn't actively maintained right now. But from what I understood, your
> setups can be supported with "standard" batman-adv mesh.
>
> Thanks,
> Simon
>
>> i think one of core
>> valuable point is relay mode and Client roaming
>>
>> i prepare to build more ap
>> evironment and test for the part later
>>
>>
>>
>>
>> As market competition intensifies,
>>
>> the gap between similar
>> productsis getting smaller and smaller,
>>
>> likewise the evolution of
>> growing homogenization trends within the industry.
>>
>>
>>
>> i hope we can find
>> valuable point for Blue Ocean each other .
>>
>> if you have some different
>> point , and I would be happy to be the first and build win-win mode each
>> other .
>>
>>
>> Best Regards
>>
>> Tiger
>>
>>> Hi,
>>>
>>>> When i compile the part , whether i need make
>>>> CONFIG_BATMAN_ADV_BATMAN_V=y at batman-adv-2016.2
>>> 2016.2 is "old". And BATMAN_V has nothing to do with network coding.
>>>
>>>> i read some detail about NetworkCoding , my understanding :
>>>>
>>>> every relay node will detects neighbors packet at promisc mode and
>>>> combine these packet into a single transmission ,
>>> I think Martin can help here. He also provided some documentation:
>>>
>>> * https://www.open-mesh.org/projects/batman-adv/wiki/NetworkCoding
>>> *
>>> https://www.open-mesh.org/projects/batman-adv/wiki/NetworkCoding-technica
>>> l *
>>> https://downloads.open-mesh.org/batman/papers/batman-adv_network_coding.p
>>> df *
>>> https://vbn.aau.dk/da/publications/catwoman(214ee21a-e786-495d-85c9-3efac
>>> 4718ead).html *
>>> https://downloads.open-mesh.org/batman/misc/wbmv4-network_coding.avi
>>>
>>> And it will not try to forward each packet is overheard. Instead it
>>> will try to find coding opportunities which it then uses to forward
>>> its own packets in less transmissions (by using packets which the
>>> other nodes should already know).
>>>
>>>> batctl nc 1
>>>> echo 1 > /sys/class/net/bat0/mesh/network_coding
>>>> ip link set dev wlan0 promisc on
>>>> ip link set dev wlan0 mtu 1546
>>> Your cards/drivers will most likely not even support promiscuous mode.
>>> Some of them require to have an monitor mode interface at the same time
>>> and
>>> some of them will simply not work.
>>>
>>> You can test it by simply checking what tcpdump is showing you on the
>>> underlying interface (wlan0). If it doesn't show you the packets between
>>> two other nodes then promiscuous mode is not working for you.
>>>
>>> The feature itself is not used very often (Martin, please correct me
>>> here).
>>> It is not enabled by default because it is not making things "better" all
>>> the time [1]. So it is also not tested as much as other components in
>>> batman-adv and you should think first if it is really useful for your
>>> scenario/HW. I knew at least from some Freifunk communities played around
>>> when it was enabled by default but had to revert when they experienced
>>> "non
>>> functional mesh links" (nothing more about it is known to me - sorry
>>> Martin).>
>>>> if i send a packet from host A to hostC via hostB, whether hostB will
>>>> open relay mode at layer2 .
>>> I completely failed to parse this.
>>>
>>> batman-adv will send your data from hostA to hostC via hostB when the TQ
>>> value for the link "from hostA to hostC via hostB" is higher than the TQ
>>> value for the link "hostA to hostC directly". This has nothing to do with
>>> network coding and is a standard feature of batman-adv (this is actually
>>> what it is about).
>>>
>>> network coding can only (when lucky) try to combine some packets - but
>>> this will only work when promiscuous mode is actually working and the
>>> nodes can overhear packets. Otherwise it will (in theory - Martin please
>>> correct me if I overlooked a safety mechanism) just create a lot of coded
>>> packets which cannot be decoded anymore. This seems to be especially
>>> problematic when some nodes are for example 2x2 MIMO devices and others
>>> are 3x3. At least this would be a good way to let the 2x2 miss important
>>> packets when the 3x3 devices talk between each other.
>>>
>>> I would even guess that things like dynamic transmission power would make
>>> overhearing packets also more problematic.
>>>
>>>> but i have a question ? How many relay nodes can be supported at
>>>> NetworkCoding ( mtu 1546 ) .
>>> I am not sure what you are asking here. The implementation in batman-adv
>>> can combine two packets into one. And this combining of these two packets
>>> is done by exact one relay node. The decoding is done by the two receiving
>>> nodes. What you can build with it is been shown in the documentation from
>>> Martin. The network coding used here is therefore done by a relay node and
>>> its neighbors. But there can be multiple relay nodes in the mesh doing
>>> network coding at the same time.
>>>
>>>
>>> I personally haven't used network coding with batman-adv. But since you've
>>> created multiple new threads on the mailing list [1,2,3,4] (beside the
>>> private mail *grml*) - here is at least a pseudo-answer.
>>>
>>> Kind regards,
>>> Sven
>>>
>>> [1]
>>> https://www.open-mesh.org/projects/batman-adv/wiki/NetworkCoding#Drawback
>>> s [2]
>>> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-November/016586.ht
>>> ml [3]
>>> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-November/016587.ht
>>> ml [4]
>>> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-November/016588.ht
>>> ml [5]
>>> https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-November/016592.ht
>>> ml
>> End of encapsulated message
^ permalink raw reply
* [lustre-devel] [PATCH] staging: lustre: ldlm: pl_recalc time handling is wrong
From: Dilger, Andreas @ 2016-11-09 3:50 UTC (permalink / raw)
To: James Simmons, Arnd Bergmann
Cc: Greg Kroah-Hartman, devel@driverdev.osuosl.org, Drokin, Oleg,
Linux Kernel Mailing List, Lustre Development List
In-Reply-To: <1478573240-12850-1-git-send-email-jsimmons@infradead.org>
On Nov 7, 2016, at 19:47, James Simmons <jsimmons@infradead.org> wrote:
>
> The ldlm_pool field pl_recalc_time is set to the current
> monotonic clock value but the interval period is calculated
> with the wall clock. This means the interval period will
> always be far larger than the pl_recalc_period, which is
> just a small interval time period. The correct thing to
> do is to use monotomic clock current value instead of the
> wall clocks value when calculating recalc_interval_sec.
It looks like this was introduced by commit 8f83409cf
"staging/lustre: use 64-bit time for pl_recalc" but that patch changed
get_seconds() to a mix of ktime_get_seconds() and ktime_get_real_seconds()
for an unknown reason. It doesn't appear that there is any difference
in overhead between the two (on 64-bit at least).
Since the ldlm pool recalculation interval is actually driven in response to
load on the server, it makes sense to use the "real" time instead of the
monotonic time (if I understand correctly) if the client is in a VM that
may periodically be blocked and "miss time" compared to the outside world.
Using the "real" clock, the recalc_interval_sec will correctly reflect the
actual elapsed time rather than just the number of ticks inside the VM.
Is my understanding of these different clocks correct?
Cheers, Andreas
>
> Signed-off-by: James Simmons <jsimmons@infradead.org>
> ---
> drivers/staging/lustre/lustre/ldlm/ldlm_pool.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c b/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c
> index 19831c5..30d4f80 100644
> --- a/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c
> +++ b/drivers/staging/lustre/lustre/ldlm/ldlm_pool.c
> @@ -256,7 +256,7 @@ static int ldlm_cli_pool_recalc(struct ldlm_pool *pl)
> time64_t recalc_interval_sec;
> int ret;
>
> - recalc_interval_sec = ktime_get_real_seconds() - pl->pl_recalc_time;
> + recalc_interval_sec = ktime_get_seconds() - pl->pl_recalc_time;
> if (recalc_interval_sec < pl->pl_recalc_period)
> return 0;
>
> @@ -264,7 +264,7 @@ static int ldlm_cli_pool_recalc(struct ldlm_pool *pl)
> /*
> * Check if we need to recalc lists now.
> */
> - recalc_interval_sec = ktime_get_real_seconds() - pl->pl_recalc_time;
> + recalc_interval_sec = ktime_get_seconds() - pl->pl_recalc_time;
> if (recalc_interval_sec < pl->pl_recalc_period) {
> spin_unlock(&pl->pl_lock);
> return 0;
> @@ -301,7 +301,7 @@ static int ldlm_cli_pool_recalc(struct ldlm_pool *pl)
> * Time of LRU resizing might be longer than period,
> * so update after LRU resizing rather than before it.
> */
> - pl->pl_recalc_time = ktime_get_real_seconds();
> + pl->pl_recalc_time = ktime_get_seconds();
> lprocfs_counter_add(pl->pl_stats, LDLM_POOL_TIMING_STAT,
> recalc_interval_sec);
> spin_unlock(&pl->pl_lock);
> --
> 1.7.1
>
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org
^ permalink raw reply
* Re: S3 resume regression [1cf4f629d9d2 ("cpu/hotplug: Move online calls to hotplugged cpu")]
From: Feng Tang @ 2016-11-09 3:54 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Thomas Gleixner, Feng Tang, Rafael J. Wysocki, Wysocki, Rafael J,
Steven Rostedt, Sebastian Andrzej Siewior,
linux-arch@vger.kernel.org, Rik van Riel, Srivatsa S. Bhat,
Peter Zijlstra, Arjan van de Ven, Rusty Russell, Oleg Nesterov,
Tejun Heo, Andrew Morton, Paul McKenney, Linus Torvalds,
Paul Turner, Linux Kernel Mailing List, Zhang, Rui, Brown, Len,
Linux PM, Linux ACPI
In-Reply-To: <20161101204737.GB4617@intel.com>
On Wed, Nov 02, 2016 at 04:47:37AM +0800, Ville Syrjälä wrote:
> On Fri, Oct 28, 2016 at 08:58:41PM +0200, Thomas Gleixner wrote:
> > On Fri, 28 Oct 2016, Ville Syrjälä wrote:
> > > On Thu, Oct 27, 2016 at 10:41:18PM +0200, Thomas Gleixner wrote:
> > > > On Thu, 27 Oct 2016, Ville Syrjälä wrote:
> > > > > On Thu, Oct 27, 2016 at 09:25:05PM +0200, Thomas Gleixner wrote:
> > > > > > So it would be interesting whether that hunk in resume_broadcast() is
> > > > > > sufficient.
> > > > >
> > > > > So far it looks like the answer is yes.
> > > > >
> > > > > Looks to be about 5 seconds slower than acpi-idle in resuming, but
> > > > > I suppose that's not all that surprising ;)
> > > >
> > > > Well, set it to 1msec then. If that works reliably then we really can do
> > > > that unconditionally. There is no harm in firing a useless timer during
> > > > resume once.
> > >
> > > I narrowed down the required timeout, and looks like 25ms is the
> > > minimum that works. With 24ms I already started to have failures. So
> > > maybe just bump it up by an order of magnitude to 250ms for some
> > > safety margin?
>
> I left the thing running for the weekend and it failed 26 out of 16057
> times with the 25ms timeout. Looks like it takes ~5 minutes to resume
> when it fails, but eventually it does come back.
>
Just came back from a travel. Yes, the 5 minutes delay may be due to the
expiration of the HPET timer, counting from 0 to 0xffffffff for a 13M
frequencey HPET takes about 300 seconds. After resume, it seems nobody
arms it so my old patch forces to arm one event.
Thanks,
Feng
^ permalink raw reply
* Question about nfsdcltrack --storagedir
From: NeilBrown @ 2016-11-09 3:46 UTC (permalink / raw)
To: Jeff Layton; +Cc: Linux NFS Mailing List
[-- Attachment #1: Type: text/plain, Size: 725 bytes --]
Hi,
I notice that nfsdcltrack has a "--storagedir" option.
I wonder how this can be used, given the nfsdcltrack is only(?) called
from the kernel and there is no(?) mechanism to pass extra options.
In a clustered-server context it would make sense(?) to share the
database between cluster nodes and it is easiest to do this if the
file in a separate filesystem (mounted as part of fail-over) rather
than in /var.
This can(?) be achieved using a symlink, but rpm likes to remove
symlinks to non-existent locations.
With NFSv3 the equivalent is the state files maintained by statd, and
these can be relocated by passing the -P option to rpc.statd.
How does one do a similar thing for NFSv4???
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
* [Qemu-devel] [PATCH] spapr: Fix migration of PCI host bridges from qemu-2.7
From: David Gibson @ 2016-11-09 3:45 UTC (permalink / raw)
To: aik, mdroth; +Cc: agraf, thuth, lvivier, qemu-ppc, qemu-devel, David Gibson
daa2369 "spapr_pci: Add a 64-bit MMIO window" subtly broke migration from
qemu-2.7 to the current version. It split the device's MMIO window into
two pieces for 32-bit and 64-bit MMIO.
The patch included backwards compatibility code to convert the old property
into the new format. However, the property value was also transferred in
the migration stream and compared with a (probably unwise) VMSTATE_EQUAL.
So, the "raw" value from 2.7 is compared to the new style converted value
from (pre-)2.8 giving a mismatch and migration failure.
Although it would be technically possible to fix this in a way allowing
backwards migration, that would leave an ugly legacy around indefinitely.
This patch takes the simpler approach of bumping the migration version,
dropping the unwise VMSTATE_EQUAL (and some equally unwise ones around it)
and ignoring them on an incoming migration.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
hw/ppc/spapr_pci.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
index 7cde30e..7f1cc29 100644
--- a/hw/ppc/spapr_pci.c
+++ b/hw/ppc/spapr_pci.c
@@ -1658,19 +1658,24 @@ static int spapr_pci_post_load(void *opaque, int version_id)
return 0;
}
+static bool version_before_3(void *opaque, int version_id)
+{
+ return version_id < 3;
+}
+
static const VMStateDescription vmstate_spapr_pci = {
.name = "spapr_pci",
- .version_id = 2,
+ .version_id = 3,
.minimum_version_id = 2,
.pre_save = spapr_pci_pre_save,
.post_load = spapr_pci_post_load,
.fields = (VMStateField[]) {
VMSTATE_UINT64_EQUAL(buid, sPAPRPHBState),
- VMSTATE_UINT32_EQUAL(dma_liobn[0], sPAPRPHBState),
- VMSTATE_UINT64_EQUAL(mem_win_addr, sPAPRPHBState),
- VMSTATE_UINT64_EQUAL(mem_win_size, sPAPRPHBState),
- VMSTATE_UINT64_EQUAL(io_win_addr, sPAPRPHBState),
- VMSTATE_UINT64_EQUAL(io_win_size, sPAPRPHBState),
+ VMSTATE_UNUSED_TEST(version_before_3, sizeof(uint32_t) /* dma_liobn[0] */
+ + sizeof(uint64_t) /* mem_win_addr */
+ + sizeof(uint64_t) /* mem_win_size */
+ + sizeof(uint64_t) /* io_win_addr */
+ + sizeof(uint64_t) /* io_win_size */),
VMSTATE_STRUCT_ARRAY(lsi_table, sPAPRPHBState, PCI_NUM_PINS, 0,
vmstate_spapr_pci_lsi, struct spapr_pci_lsi),
VMSTATE_INT32(msi_devs_num, sPAPRPHBState),
--
2.7.4
^ permalink raw reply related
* Re: [Qemu-devel] [PULL 15/16] spapr_pci: Add a 64-bit MMIO window
From: David Gibson @ 2016-11-09 3:42 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: peter.maydell, agraf, qemu-ppc, qemu-devel
In-Reply-To: <4424b1f9-669e-9d6b-022d-e9c3c86c117e@ozlabs.ru>
[-- Attachment #1: Type: text/plain, Size: 4024 bytes --]
On Tue, Nov 08, 2016 at 02:59:30PM +1100, Alexey Kardashevskiy wrote:
> On 08/11/16 12:16, David Gibson wrote:
> > On Fri, Nov 04, 2016 at 04:03:31PM +1100, Alexey Kardashevskiy wrote:
> >> On 17/10/16 13:43, David Gibson wrote:
> >>> On real hardware, and under pHyp, the PCI host bridges on Power machines
> >>> typically advertise two outbound MMIO windows from the guest's physical
> >>> memory space to PCI memory space:
> >>> - A 32-bit window which maps onto 2GiB..4GiB in the PCI address space
> >>> - A 64-bit window which maps onto a large region somewhere high in PCI
> >>> address space (traditionally this used an identity mapping from guest
> >>> physical address to PCI address, but that's not always the case)
> >>>
> >>> The qemu implementation in spapr-pci-host-bridge, however, only supports a
> >>> single outbound MMIO window, however. At least some Linux versions expect
> >>> the two windows however, so we arranged this window to map onto the PCI
> >>> memory space from 2 GiB..~64 GiB, then advertised it as two contiguous
> >>> windows, the "32-bit" window from 2G..4G and the "64-bit" window from
> >>> 4G..~64G.
> >>>
> >>> This approach means, however, that the 64G window is not naturally aligned.
> >>> In turn this limits the size of the largest BAR we can map (which does have
> >>> to be naturally aligned) to roughly half of the total window. With some
> >>> large nVidia GPGPU cards which have huge memory BARs, this is starting to
> >>> be a problem.
> >>>
> >>> This patch adds true support for separate 32-bit and 64-bit outbound MMIO
> >>> windows to the spapr-pci-host-bridge implementation, each of which can
> >>> be independently configured. The 32-bit window always maps to 2G.. in PCI
> >>> space, but the PCI address of the 64-bit window can be configured (it
> >>> defaults to the same as the guest physical address).
> >>>
> >>> So as not to break possible existing configurations, as long as a 64-bit
> >>> window is not specified, a large single window can be specified. This
> >>> will appear the same way to the guest as the old approach, although it's
> >>> now implemented by two contiguous memory regions rather than a single one.
> >>>
> >>> For now, this only adds the possibility of 64-bit windows. The default
> >>> configuration still uses the legacy mode.
> >>
> >>
> >> This breaks migration to QEMU v2.7, the destination reports:
> >>
> >> 22901@1478235261.799031:vmstate_load spapr_pci, spapr_pci
> >> 22901@1478235261.799040:vmstate_load_field_error field "mem_win_size" load
> >> failed, ret = -22
> >> qemu-hostos1: error while loading state for instance 0x0 of device 'spapr_pci'
> >> 22901@1478235261.801324:migrate_set_state new state 7
> >> qemu-hostos1: load of migration failed: Invalid argument
> >>
> >>
> >> mem_win_size decreased from 0xf80000000 to 0x80000000.
> >>
> >> I'd think it should be allowed to migrate like this.
> >
> > AIUI, we don't generally care (upstream) about migration from newer to
> > older qemu, only from older to newer.
>
> Older (v2.7.0) to newer (current upstream with -machine pseries-2.7) does
> not work either with the exact same symptom.
Drat. Ok.. I see why. I was converting the old style property into
new-style meaning during property parsing, but the "raw" property
value was still being sent and compared in the migration stream.
It would be possible to fix it both ways, by keeping around the "raw"
mem_window_size parameter and having some pre_save / post_load logic
to shuffle the various possibilities. But that's going to leave ugly
cruft around indefinitely. I think it's preferable to just bump the
version number and drop those more-trouble-than-they're-worth
VMSTATE_EQUAL fields.
Patch coming shortly.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [U-Boot] [PATCH RESEND 0/9] sunxi: chip: Enable the DIP auto-detection
From: Tom Rini @ 2016-11-09 3:44 UTC (permalink / raw)
To: u-boot
In-Reply-To: <cover.e445aa83aac1de200cdbb59f8a5572c43341f03d.1478600213.git-series.maxime.ripard@free-electrons.com>
On Tue, Nov 08, 2016 at 11:19:20AM +0100, Maxime Ripard wrote:
[snip]
> I think the biggest drawback at the moment is that we maintain a list of
> DIPs and the actions needed directly into the C code, which will make it
> quite hard to customise for end users and tedious to maintain in the long
> term. I couldn't really get my head around a better solution, so feel free
> to suggest alternative approaches.
A thought I had after reading over 8/9 in the series was, could we try
something like:
- In C, loop over everything in w1 and set environment variables based
on each thing we find.
- In a CONFIG_PREBOOT load a U-Boot shell script in that will look for
the right env variables to be set for a given DIP and then do whatever
is needed to load in the overlay.
Does that make sense?
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161108/7afd37da/attachment.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.