The help info of `make -C=1` is little confusing, make it clear.
Signed-off-by: Cao jin
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index efa267a..b34a34d 100644
--- a/Makefile
+++ b/Makefile
@@ -1417,7 +1417,7 @@ help:
@echo
host-cmulti means the composite host program that is compiled/linked
from several .c file, not .o file, because .o file could also be
compiled from .cpp file.
Bonus: update the stale comment.
Signed-off-by: Cao jin
---
scripts/Makefile.host | 6 +++---
1 file changed, 3 insertions(+), 3
On 11/01/2017 09:31 AM, Cao jin wrote:
> host-cmulti means the composite host program that is compiled/linked
> from several .c file, not .o file, because .o file could also be
> compiled from .cpp file.
>
> Bonus: update the stale comment.
> Signed-off-by: Cao jin
host-cmulti means the composite host program that is compiled/linked
from several .c file, not .o file, because .o file could also be
compiled from .cpp file.
Bonus: update the stale comment.
Signed-off-by: Cao jin
---
scripts/Makefile.host | 6 +++---
1 file changed, 3 insertions(+), 3
ion 'foreach':
> missing ')'. Stop.
>
>
> Please test your patch before submitting.
>
Sorry for my mistake，I missed to test the patch this time incredibly:(
> Assuming the build error will be fixed, this change is correct.
>
>
>
>
> Also, modname-multi should be fixed.
>
> modname-multi = $(sort $(foreach m,$(multi-used),\
> $(if $(filter $(subst $(obj)/,,$*.o), $($(m:.o=-objs))
> $($(m:.o=-y)) $($(m:.o=-m))),$(m:.o=
>
Yes, I also noticed here, but fail to remember it:(
Thanks very much, Masahiro-san!
--
Sincerely,
Cao jin
Commit cf4f21938e13 ("kbuild: Allow to specify composite modules
with modname-m") added modname-m support, but missed to update the
corresponding multi-objs-m & modname-multi definition.
Signed-off-by: Cao jin
---
Addressed the all comments of Masahiro-san from RFC version,
I guess maybe this trivial one is forgot:)
So, a friendly ping.
On 11/01/2017 09:43 AM, Cao jin wrote:
> host-cmulti means the composite host program that is compiled/linked
> from several .c file, not .o file, because .o file could also be
> compiled from .cpp file.
>
> Bonus: u
Masahiro-san,
On 11/14/2017 06:31 PM, Masahiro Yamada wrote:
> Hi Cao,
>
> 2017-11-01 10:43 GMT+09:00 Cao jin :
>>
>> # C code
>> -# Executables compiled from a single .c file
>> +# C Executables compiled from a single .c file
>
>
> Is anything w
It does several fixes:
1. move the displaced ld example to its reasonale place.
2. add new example for command gzip.
3. fix 2 number errors.
4. fix format of chapter 7.x, make it looks the same as other chapters.
Signed-off-by: Cao jin
---
Documentation/kbuild/makefiles.txt | 31
randomize_layout_hash.h is not used in plugin compilation, but locates in
include/generated/
Signed-off-by: Cao jin
---
scripts/gcc-plugins/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/gcc-plugins/Makefile b/scripts/gcc-plugins/Makefile
index e2ff425f4c7e
aling --> aligned
Signed-off-by: Cao jin
---
include/asm-generic/vmlinux.lds.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index ee8b707d9fa9..470c41d2e272 100644
--- a/include/asm-gene
gcc maintainer[*] that it is a problem of the plugin,
not gcc
[*]https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84052
So, could you confirm it is plugin bug or not?
--
Sincerely,
Cao jin
Signed-off-by: Cao jin
---
Documentation/x86/x86_64/mm.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index ea91cb61a602..8d09b6e5eb3f 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86
Finally know why I have this wrong understanding according to private
discussion.
Sorry for the noise
--
Sincerely,
Cao jin
On 01/15/2018 11:36 AM, Cao jin wrote:
> Signed-off-by: Cao jin
> ---
> Documentation/x86/x86_64/mm.txt | 2 +-
> 1 file changed, 1 insertion(+)
Dear Maintainers,
Could you help to give a hint?
Thanks in advance.
--
Sincerely,
Cao jin
On 03/17/2018 06:01 PM, Cao jin wrote:
> Hi,
>
> I find two small questions which confuse me a little.
>
> 1.
> # Check signature at end of setup
>cmpl$
Thanks very much for you hint!
On 03/21/2018 05:57 PM, Thomas Gleixner wrote:
> On Wed, 21 Mar 2018, Cao jin wrote:
>> On 03/17/2018 06:01 PM, Cao jin wrote:
>>> I find two small questions which confuse me a little.
>>>
>>> 1.
>>> # Check signature a
eed to be modified above this code hunk:
Note: Files that end up in two or more modules are compiled without the
KBUILD_MODNAME definition. The reason is that any made-up name
would differ in different configs.
--
Sincerely,
Cao jin
dependency of composite objects
> # Usage:
>
A subtle catch! And in my test, a debug line
$(info $@ = $*)
in rule:
$(obj)/%.o: $(src)/%.c xxx
does tell me it is correct. So,
Reviewed-by: Cao jin
--
Sincerely,
Cao jin
Masahiro-san
On 03/08/2018 06:21 PM, Masahiro Yamada wrote:
> 2018-03-08 19:11 GMT+09:00 Cao jin :
>>
>>
>> On 03/08/2018 09:05 AM, Masahiro Yamada wrote:
>>> Currently, KBUILD_MODNAME is defined only when $(modname) contains
>>> just one word. If an
$(multi-objs-y))
> -multi-objs-m := $(addprefix $(obj)/,$(multi-objs-m))
> subdir-ym:= $(addprefix $(obj)/,$(subdir-ym))
>
> # These flags are needed for modversions and compiling, so we define them
> here
>
multi-objs-y/m seems only exist for rules above with target-specific
variable assignment. A great simplification, So
Reviewed-by: Cao jin
--
Sincerely,
Cao jin
On 03/08/2018 09:05 AM, Masahiro Yamada wrote:
> Just a cosmetic change to put related code close together.
>
> Signed-off-by: Masahiro Yamada
Reviewed-by: Cao jin
--
Sincerely,
Cao jin
The series build successfully on upstream in my: make allyesconfig and
allmodconfig, so,
Tested-by: Cao jin
--
Sincerely,
Cao jin
On 03/08/2018 09:04 AM, Masahiro Yamada wrote:
>
> 3/5 takes into account '-m' case for multi-used-m.
>
> 2/5 is necessary beforehand bec
gzip file has 4-byte little-endian file size encoded at the end of file,
while all the other compressed kernel file has size_append operation in
the Makefile which also append the 4-byte little-endian file size. There
is no need to do endianness transforming by mkpiggy.
Signed-off-by: Cao jin
On 11/9/18 9:00 PM, Thomas Gleixner wrote:
> Cao,
>
> On Fri, 9 Nov 2018, Cao jin wrote:
>
>> gzip file has 4-byte little-endian file size encoded at the end of file,
>> while all the other compressed kernel file has size_append operation in
>> the Makefile which
On 07/08/2018 10:15 AM, Masahiro Yamada wrote:
> 2018-07-06 17:49 GMT+09:00 Cao jin :
>> Masahiro-san,
>>
>> I am writing some utility for internal kdump test with latest kernel,
>> my purpose is to test the new introduced kernel feature. For automatical
>>
be used in olddefconfig.
All these things let me have 2 questions:
1. What would you suggest for my purpose?
2. allyesconfig, allmodconfig, randconfig seems useful for test kbuild,
but what's the purpose of allnoconfig, alldefconfig? In others words,
when people would need allnoconfig, alldefconfig?
--
Sincerely,
Cao jin
e in kbuild, so,
Acked-by: Cao jin
--
Sincerely,
Cao jin
> ---
> Documentation/kbuild/kbuild.txt |5 +
> 1 file changed, 5 insertions(+)
>
> --- lnx-418-rc3.orig/Documentation/kbuild/kbuild.txt
> +++ lnx-418-rc3/Documentation/kbuild/kbuild.txt
&g
According to objdump output of setup, function memset is not used in
setup code. Currently, all usage of memset in setup come from macro
definition of string.h.
Signed-off-by: Cao jin
---
Compiled and booted under x86_64; compiled under i386.
Questions: now there is 2 definition of memcpy, one
Hi,
On 1/7/19 3:59 PM, h...@zytor.com wrote:
> On January 6, 2019 11:40:56 PM PST, Cao jin wrote:
>> According to objdump output of setup, function memset is not used in
>> setup code. Currently, all usage of memset in setup come from macro
>> definition of string.h.
>>
ciate it someone can
leave a hint.
--
Sincerely,
Cao jin
On 1/7/19 3:40 PM, Cao jin wrote:
> According to objdump output of setup, function memset is not used in
> setup code. Currently, all usage of memset in setup come from macro
> definition of string.h.
>
> Signed-off-by: Cao j
21216a8: ("x86/boot: Reorganize and clean
up the BIOS area reservation code"), still no clue.
--
Sincerely,
Cao jin
indentation fix in linker script: spaces -> tab
Signed-off-by: Cao jin
---
arch/x86/boot/compressed/head_64.S | 13 +
arch/x86/boot/compressed/vmlinux.lds.S | 4 ++--
2 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/arch/x86/boot/compressed/head_64.S
b/arch/
ping?
On 03/16/2018 04:49 PM, Cao jin wrote:
> Some ..cmd files under arch/x86 report -D__KERNEL__ appears two
> times in the command line, like arch/x86/boot, arch/x86/realmode/rm.
> It is already defined in KBUILD_CPPFLAGS from top Makefile. so it can be
> dropped saftely from the
drop it from VALID_OPEN_FLAGS.
Signed-off-by: Cao jin
---
include/linux/fcntl.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
index d019df946cb2..8a2ca434be6d 100644
--- a/include/linux/fcntl.h
+++ b/include/linux/fcntl.h
Direct page mapping in bottom-up way will allocate memory from low
address for page structures in a range, which is the *bottom*,
not the *end*.
Signed-off-by: Cao jin
---
arch/x86/mm/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm
Since a13f2ef168cb ("x86/xen: remove 32-bit Xen PV guest support"),
RESERVE_BRK_ARRAY() has no user anymore, let's drop it.
Update related comments too.
Signed-off-by: Cao jin
---
arch/x86/include/asm/setup.h | 5 -
arch/x86/kernel/setup.c | 6 +++---
2 files change
Parameter "cmdline" has no use, drop it.
Signed-off-by: Cao jin
---
init/main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/init/main.c b/init/main.c
index c68d784376ca..621a11ed18fb 100644
--- a/init/main.c
+++ b/init/main.c
@@ -404,7 +404,7 @@ static
struct setup_data.len is the length of data field. In case of
SETUP_INDIRECT, it should be sizeof(setup_indirect).
Signed-off-by: Cao jin
---
Documentation/x86/boot.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
pi_register_gsi(&dev->dev, gsi, triggering, polarity);
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
--
Yours Sincerely,
Cao jin
It has:
a tense correction(led->leads);
a typo(unevitably->inevitably);
a logic error correction(unacceptable->acceptable)
Signed-off-by: Cao jin
---
Documentation/timers/hrtimers.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/timers/hrtime
Hi jon
Thanks for your quick respond for my 1st patch here.
On 04/21/2016 05:56 PM, Jonathan Corbet wrote:
On Thu, 21 Apr 2016 17:09:54 +0800
Cao jin wrote:
- wheel concept, it cannot be 'designed out' without unevitably
- degrading other portions of the timers.c
On 04/21/2016 09:23 PM, Jonathan Corbet wrote:
On Thu, 21 Apr 2016 18:25:41 +0800
Cao jin wrote:
This change is incorrect - "unacceptable" is exactly what the writer
wanted to say here.
*it cannot be 'designed out' without inevitably degrading other portions
of the
It has:
a tense correction(led->leads);
a typo(unevitably->inevitably);
Signed-off-by: Cao jin
---
Documentation/timers/hrtimers.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/timers/hrtimers.txt
b/Documentation/timers/hrtimers.txt
index c
From: Chen Fan
when the device encounters a falal error, the host aer driver may
do secondary bus reset to recovery the devices under the bus, and
for guest driver also do the same way to recovery the device under
the virtual bus. in order to avoid guest and host do the bus reset
simultaneously,
On 1/4/19 8:04 PM, Cao jin wrote:
> No real code modification, just cleanup:
> 1. remove redundant comments which have already appeared above
> 2. comments improvement:
> "aligned to a 2M boundary"
> -->
> "aligned up to CONFIG_PHYSICAL_ALIGN
Hi,
Wish to know whether the patch make sense.
On 8/9/19 7:46 PM, Cao jin wrote:
> Signed-off-by: Cao jin
> ---
> arch/x86/include/asm/fixmap.h | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/as
They are wrappers of BUILD_BUG_ON_ZERO(NCAPINTS != n), which is already
present in corresponding *_MASK_BIT_SET. And fill the missing period in
head comments by the way.
Signed-off-by: Cao jin
---
arch/x86/include/asm/cpufeature.h| 2 --
arch/x86/include/asm/disabled-features.h | 1
bugs from missing a case.
> So, Cao, I wouldn't mind having the gist of that above somewhere around
> there in a comment explicitly.
>
A subtle issue hard to detect by eyes. Sure, on the way.
--
Sincerely,
Cao jin
Help people to understand the author's intent of apparent duplication of
BUILD_BUG_ON_ZERO(NCAPINTS != n), which is hard to detect by eyes.
CC: Dave Hansen
Suggested-by: Borislav Petkov
Signed-off-by: Cao jin
---
Tried my best to describe it accurately, in case of any inaccuracy, feel
fr
On 8/28/19 2:42 PM, Borislav Petkov wrote:
> On Wed, Aug 28, 2019 at 02:11:00PM +0800, Cao jin wrote:
>
> For the future:
>
>> Subject: Re: [PATCH] x86/cpufeature: explicit comments for duplicate macro
>
> your subject needs to have a verb and start with a capital lett
elaboarte -> elaborate
architecure -> architecture
compltes -> completes
Signed-off-by: Cao jin
---
mm/memblock.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/memblock.c b/mm/memblock.c
index 7d4f61ae666a..0d0f92003d18 100644
--- a/mm/memblock.c
On 9/11/19 10:42 PM, Mike Rapoport wrote:
> On Wed, Sep 11, 2019 at 11:08:56AM +0800, Cao jin wrote:
>> elaboarte -> elaborate
>> architecure -> architecture
>> compltes -> completes
>>
>> Signed-off-by: Cao jin
>> ---
>> mm/memblock.c | 6 +
On 9/12/19 6:35 PM, Mike Rapoport wrote:
> On Thu, Sep 12, 2019 at 10:54:09AM +0800, Cao jin wrote:
>> On 9/11/19 10:42 PM, Mike Rapoport wrote:
>>
>> Sure. BTW, do you want convert all the markups too?
>>
>> :c:type:`foo` -> struct foo
>> %FOO
fix typos for:
elaboarte -> elaborate
architecure -> architecture
compltes -> completes
And, convert the markup :c:func:`foo` to foo() as kernel documentation
toolchain can recognize foo() as a function.
Suggested-by: Mike Rapoport
Signed-off-by: Cao jin
---
mm/memblo
On 9/26/19 2:01 PM, Ingo Molnar wrote:
> * Cao jin wrote:
>
>> The fields marked with (reloc) actually are not dedicated for writing,
>> but communicating info for relocatable kernel with boot loaders. For
>> example:
>>
>>
x27;, but argument 4 has type 'long int' [-Werror=format=]
pr_err("failed to compress %zd bytes: %s\n",
^
Fix them by pairing "%zd" to size_t.
Signed-off-by: Cao jin
---
tools/perf/util/session.c | 2 +-
tools/perf/util/zstd.c| 6 +++---
2 files ch
Sorry, the commit message isn't accurate. v2 coming.
--
Sincerely,
Cao jin
On 5/1/20 4:15 PM, Cao jin wrote:
> Compilation on i386 complains as following:
>
> util/session.c: In function 'perf_session__process_compressed_event':
> util/session.c:91:11: error: forma
aka unsigned int}' [-Werror=format=]
pr_err("failed to decompress (B): %ld -> %ld, dst_size %ld : %s\n",
^
Fix them by pairing "%zd" to size_t.
Also revert an unnecessary conversion: "(long)src_size" to plain "src_size"
with conversion spec
Hi, Kirll,
On 1/15/19 7:45 PM, Cao jin wrote:
> Hi,
> I have been digging into this file for a while, and I still have 2
> questions unclear, hope to get your help.
>
>
> 2.
> Why gdt64 has following definition?:
>
> gdt64:
> .word gdt_end - gdt
>
On 1/22/19 9:08 PM, Kirill A. Shutemov wrote:
> On Tue, Jan 22, 2019 at 03:31:25PM +0800, Cao jin wrote:
>> Hi, Kirll,
>>
>>> 2.
>>> Why gdt64 has following definition?:
>>>
>>> gdt64:
>>> .word gdt_end - gdt
>>> .
to make target 'include/config/auto.conf', needed by
'include/config/kernel.release'. Stop.
Any idea on this problem? Or anyone has ever tried ld 2.20 successfully?
--
Sincerely,
Cao jin
gdt64 represents the content of GDTR under x86-64, which actually needs
10 bytes only, ".long" & ".word" is superfluous.
Signed-off-by: Cao jin
---
arch/x86/boot/compressed/head_64.S | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/boot/compressed/he
Hi,
Is the patch not right?
--
Sincerely,
Cao jin
On 1/4/19 8:04 PM, Cao jin wrote:
> No real code modification, just cleanup:
> 1. remove redundant comments which have already appeared above
> 2. comments improvement:
> "aligned to a 2M boundary"
> -
On 1/15/19 11:55 PM, Thomas Gleixner wrote:
> On Tue, 15 Jan 2019, Cao jin wrote:
>
>> Hi,
>> I have been digging into this file for a while, and I still have 2
>> questions unclear, hope to get your help.
>>
>> 1.
>> At the entry of startup_64,
.word gdt_end - gdt
.quad 0
With above modification, it can boot.
--
Sincerely,
Cao jin
On 2/1/19 4:20 PM, Kees Cook wrote:
> On Fri, Feb 1, 2019 at 6:51 PM Cao jin wrote:
>>
>> comments fix: input_size is ZO image size which just don't count .bss
>> in, but has .text, .data, etc;
>> drop unecessary alignment: minimum is either 512M or output, b
Signed-off-by: Cao jin
---
arch/x86/include/asm/fixmap.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 9da8cccdf3fb..0c47aa82e2e2 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm
Commit e6401c130931 ("x86/irq/64: Split the IRQ stack into its own pages")
missed to update one piece of comment as it did to its peer in Xen, which
will confuse people who still need to read comment.
A bonus fix to identation in ZO's linker script: spaces -> tab.
Sign
On 7/22/19 4:53 PM, Thomas Gleixner wrote:
> Cao,
>
> On Fri, 19 Jul 2019, Cao jin wrote:
>
>> Commit e6401c130931 ("x86/irq/64: Split the IRQ stack into its own pages")
>> missed to update one piece of comment as it did to its peer in Xen, which
>> wi
Hello HPA,
On 1/8/19 4:38 PM, h...@zytor.com wrote:
> On January 7, 2019 12:52:57 AM PST, Cao jin wrote:
>> Hi,
>>
>> On 1/7/19 3:59 PM, h...@zytor.com wrote:
>>> On January 6, 2019 11:40:56 PM PST, Cao jin
>> wrote:
>>>> According to objdump
On 2/1/19 4:20 PM, Kees Cook wrote:
> On Fri, Feb 1, 2019 at 6:51 PM Cao jin wrote:
>>
>> comments fix: input_size is ZO image size which just don't count .bss
>> in, but has .text, .data, etc;
>> drop unecessary alignment: minimum is either 512M or output, b
On 1/8/19 4:46 PM, Cao jin wrote:
> One more question: in compressed/, for mem*(), it seems we both use the
> macros of boot/string.h, and the functions of compressed/string.c. Is
> that what we want?
>
> compressed/ is compiled with -O2, so it cannot be told by objdump -d,
>
1. typo fix: there -> their
2. remove superfluous "by"
Signed-off-by: Cao jin
---
arch/x86/tools/relocs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index 5d73c443e778..fcf3fad01b08 100644
--- a/a
n my test, replace the 2nd line with:
movw$_end, %cx
or:
movw$__bss_end+3, %cx
are both fine.
--
Sincerely,
Cao jin
ping?
On 03/05/2018 03:15 PM, Cao jin wrote:
> 1. typo fix: there -> their
> 2. remove superfluous "by"
>
> Signed-off-by: Cao jin
> ---
> arch/x86/tools/relocs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/
Some ..cmd files under arch/x86 report -D__KERNEL__ appears two
times in the command line, like arch/x86/boot, arch/x86/realmode/rm.
It is already defined in KBUILD_CPPFLAGS from top Makefile. so it can be
dropped saftely from these Makefiles.
Signed-off-by: Cao jin
---
arch/x86/Makefile
On 12/06/2016 12:17 AM, Alex Williamson wrote:
> On Mon, 5 Dec 2016 13:52:03 +0800
> Cao jin wrote:
>
>> On 12/04/2016 11:30 PM, Alex Williamson wrote:
>>> On Sun, 4 Dec 2016 20:16:42 +0800
>>> Cao jin wrote:
>>>
>>>> On 12/01/2016
On 12/06/2016 11:46 AM, Michael S. Tsirkin wrote:
> On Thu, Dec 01, 2016 at 09:40:23PM +0800, Cao jin wrote:
>>
>>
>> On 12/01/2016 12:51 PM, Michael S. Tsirkin wrote:
>>> On Wed, Nov 30, 2016 at 09:04:13PM -0700, Alex Williamson wrote:
>>>> On Sun, 27 N
some of these issues if you're not going to
>>> read the previous discussions or consult with your colleagues to
>>> understand how we got to this point. If you want to challenge some of
>>> the design points, that's great, it could use some new eyes, but please
>
On 12/06/2016 11:35 PM, Alex Williamson wrote:
> On Tue, 6 Dec 2016 18:46:04 +0800
> Cao jin wrote:
>
>> On 12/06/2016 12:59 PM, Alex Williamson wrote:
>>> On Tue, 6 Dec 2016 05:55:28 +0200
>>> "Michael S. Tsirkin" wrote:
>>>
>>&g
On 12/06/2016 11:25 PM, Alex Williamson wrote:
> On Tue, 6 Dec 2016 14:11:03 +0800
> Cao jin wrote:
>
>> On 12/06/2016 12:17 AM, Alex Williamson wrote:
>>> On Mon, 5 Dec 2016 13:52:03 +0800
>>> Cao jin wrote:
>>>
>>>> On 12/04/2016
Include typo fix; white space shooting; mistake correction.
Signed-off-by: Cao jin
---
Documentation/PCI/pci-error-recovery.txt | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/PCI/pci-error-recovery.txt
b/Documentation/PCI/pci-error-recovery.txt
On 12/08/2016 10:05 PM, Jonathan Corbet wrote:
> On Thu, 8 Dec 2016 16:16:14 +0800
> Cao jin wrote:
>
>> The platform resets the link, and then calls the link_reset() callback
>> on all affected device drivers. This is a PCI-Express specific state
>> -and is done
On 12/06/2016 11:35 PM, Alex Williamson wrote:
> On Tue, 6 Dec 2016 18:46:04 +0800
> Cao jin wrote:
>
>> On 12/06/2016 12:59 PM, Alex Williamson wrote:
>>> On Tue, 6 Dec 2016 05:55:28 +0200
>>> "Michael S. Tsirkin" wrote:
>>>
>>&g
Alex,
Do you have any comments on this version & and the qemu parts?
--
Sincerely,
Cao jin
On 12/31/2016 05:15 PM, Cao jin wrote:
> Support serious device error recovery
>
> Signed-off-by: Cao jin
> ---
> drivers/vfio/pci/vfio
On 01/19/2017 05:32 AM, Alex Williamson wrote:
> On Tue, 10 Jan 2017 17:11:01 +0200
> "Michael S. Tsirkin" wrote:
>
>> On Tue, Jan 10, 2017 at 07:46:17PM +0800, Cao jin wrote:
>>>
>>>
>>> On 01/10/2017 07:04 AM, Michael S. Tsirkin wrote:
&g
On 01/21/2017 01:01 AM, Michael S. Tsirkin wrote:
> On Fri, Jan 20, 2017 at 06:13:22PM +0800, Cao jin wrote:
>>
>>
>> On 01/20/2017 04:16 AM, Michael S. Tsirkin wrote:
>>> This is a design and an initial patch for kernel side for AER
>>> support in VFIO
On 01/10/2017 07:04 AM, Michael S. Tsirkin wrote:
> On Sat, Dec 31, 2016 at 05:15:36PM +0800, Cao jin wrote:
>> Support serious device error recovery
>
> serious?
>
Sorry for my poor vocabulary if it confuses people. I wanted to express
the meaning that: vfio-pci actuall
t;
> Aside: we currently return PCI_ERS_RESULT_DISCONNECT when device
> is not attached. This seems bogus, likely based on the confusing name.
> We probably should return PCI_ERS_RESULT_CAN_RECOVER.
>
> The following patch does not change that.
>
> Signed-off-by: Michael S. Tsirkin
>
> -
On 11/08/2016 02:49 AM, Alexander Duyck wrote:
On Mon, Nov 7, 2016 at 4:44 AM, Cao jin wrote:
Under certain condition, I find guest will oops on writel() in
igb_configure_tx_ring(), because hw->hw_address is NULL. While other
register access won't oops kernel because they use wr32/rd
On 11/08/2016 12:12 PM, Alexander Duyck wrote:
On Monday, November 7, 2016, Cao jin mailto:caoj.f...@cn.fujitsu.com>> wrote:
We removed head because it isn't really accessed very often, it is only
really used for when the ring is configured. Tail is accessed every
ti
003818
[ 145.361275] IP: []
igb_configure_tx_ring+0x14d/0x280 [igb]
[ 145.400048] PGD 0
[ 145.438007] Oops: 0002 [#1] SMP
A similiar issue & solution could be found at:
http://patchwork.ozlabs.org/patch/689592/
Signed-off-by: Cao jin
---
drivers/net/ethernet/intel/igb/igb_
Thanks Corrina for your info.
I tested my patch, it works for me on kernel 4.9-rc4.
"surprise removal" maybe another issue to solve. This one is enough to
solve my issue and other one's, could it be accept first?
Cao jin
On 11/09/2016 03:33 AM, Alexander Duyck wrote:
On Tue,
pci_user_read/write_config_() already does the translation.
Signed-off-by: Cao jin
---
drivers/vfio/pci/vfio_pci_config.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_config.c
b/drivers/vfio/pci/vfio_pci_config.c
index 65d4a30
trouble for a
successful recovery, so, disable the vfio-pci's link-reset in aer driver
in host, this is a keypoint for guest to do error recovery successfully.
CC: alex.william...@redhat.com
CC: m...@redhat.com
Signed-off-by: Cao jin
---
This is actually a RFC version(has debug lines left), and h
On 11/28/2016 11:00 AM, Michael S. Tsirkin wrote:
On Sun, Nov 27, 2016 at 07:34:17PM +0800, Cao jin wrote:
It is user space driver's or device-specific driver's(in guest) responsbility
to do a serious recovery when error happened. Link-reset is one part of
recovery, when pci
Signed-off-by: Cao jin
---
drivers/net/ethernet/intel/igb/e1000_regs.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_regs.h
b/drivers/net/ethernet/intel/igb/e1000_regs.h
index d84afdd..58adbf2 100644
--- a/drivers/net/ethernet/intel/igb
Support serious device error recovery
Signed-off-by: Cao jin
---
drivers/vfio/pci/vfio_pci.c | 70 +++--
drivers/vfio/pci/vfio_pci_private.h | 2 ++
2 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers
Sorry for late.
after reading all your comments, I think I will try the solution 1.
On 12/13/2016 03:12 AM, Alex Williamson wrote:
> On Mon, 12 Dec 2016 21:49:01 +0800
> Cao jin wrote:
>
>> Hi,
>> I have 2 solutions(high level design) came to me, please see if they are
&g
gh we told user "Please
collect any data possible and then kill the guest", I still don't know
how to save any possible data. For example, if user is editing document,
vm_stop caused by a device fatal error will destroy user's effort.
--
Sincerely,
Cao jin
>
> Results:
> The adv
1 - 100 of 208 matches
Mail list logo
