On Thu, Feb 14, 2019 at 08:44:48PM +, Elliott, Robert (Persistent Memory)
wrote:
>
>
> > -Original Message-
> > From: Linux-nvme [mailto:linux-nvme-boun...@lists.infradead.org] On Behalf
> > Of Keith Busch
> > Sent: Tuesday, February 5, 2019 8:39
inking that the problem of this patch is adding processor specific
code into NVMe common driver, is this correct? Or another problem? It
would be great if you could give me a hint to improve this patch.
Thanks,
Takao Indoh
On Fri, Feb 01, 2019 at 04:51:20PM +0100, Christoph Hellwig wrote:
> On Fri, Feb 01, 2019 at 09:46:15PM +0900, Takao Indoh wrote:
> > From: Takao Indoh
> >
> > Fujitsu A64FX processor has a feature to accelerate data transfer of
> > internal bus by relaxed ordering. It
On Fri, Feb 01, 2019 at 07:54:14AM -0700, Keith Busch wrote:
> On Fri, Feb 01, 2019 at 09:46:15PM +0900, Takao Indoh wrote:
> > From: Takao Indoh
> >
> > Fujitsu A64FX processor has a feature to accelerate data transfer of
> > internal bus by relaxed ordering. It
From: Takao Indoh
Fujitsu A64FX processor has a feature to accelerate data transfer of
internal bus by relaxed ordering. It is enabled when the bit 56 of dma
address is set to 1.
This patch introduces this acceleration feature to the NVMe driver to
enhance NVMe device performance.
Signed-off
On 2016/11/15 17:48, Ingo Molnar wrote:
* Takao Indoh <indou.ta...@jp.fujitsu.com> wrote:
In rb_alloc_aux_page(), a page order is set to MAX_ORDER when order is
greater than MAX_ORDER, but page order should be less than MAX_ORDER,
therefore alloc_pages_node fails at least once. This
On 2016/11/15 17:48, Ingo Molnar wrote:
* Takao Indoh wrote:
In rb_alloc_aux_page(), a page order is set to MAX_ORDER when order is
greater than MAX_ORDER, but page order should be less than MAX_ORDER,
therefore alloc_pages_node fails at least once. This patch fixes page
order so that it can
In rb_alloc_aux_page(), a page order is set to MAX_ORDER when order is
greater than MAX_ORDER, but page order should be less than MAX_ORDER,
therefore alloc_pages_node fails at least once. This patch fixes page
order so that it can be always less than MAX_ORDER.
Signed-off-by: Takao Indoh
In rb_alloc_aux_page(), a page order is set to MAX_ORDER when order is
greater than MAX_ORDER, but page order should be less than MAX_ORDER,
therefore alloc_pages_node fails at least once. This patch fixes page
order so that it can be always less than MAX_ORDER.
Signed-off-by: Takao Indoh
Commit-ID: da06a43d3f3f3df87416f654fe15d29fecb5e321
Gitweb: http://git.kernel.org/tip/da06a43d3f3f3df87416f654fe15d29fecb5e321
Author: Takao Indoh
AuthorDate: Wed, 4 Nov 2015 14:22:33 +0900
Committer: Ingo Molnar
CommitDate: Mon, 23 Nov 2015 09:58:26 +0100
perf, x86: Stop Intel PT
Commit-ID: 24cc12b17679f8e9046746f92fd377f589efc163
Gitweb: http://git.kernel.org/tip/24cc12b17679f8e9046746f92fd377f589efc163
Author: Takao Indoh
AuthorDate: Wed, 4 Nov 2015 14:22:32 +0900
Committer: Ingo Molnar
CommitDate: Mon, 23 Nov 2015 09:58:26 +0100
perf/x86/intel/pt: Add
Commit-ID: da06a43d3f3f3df87416f654fe15d29fecb5e321
Gitweb: http://git.kernel.org/tip/da06a43d3f3f3df87416f654fe15d29fecb5e321
Author: Takao Indoh <indou.ta...@jp.fujitsu.com>
AuthorDate: Wed, 4 Nov 2015 14:22:33 +0900
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate:
Commit-ID: 24cc12b17679f8e9046746f92fd377f589efc163
Gitweb: http://git.kernel.org/tip/24cc12b17679f8e9046746f92fd377f589efc163
Author: Takao Indoh <indou.ta...@jp.fujitsu.com>
AuthorDate: Wed, 4 Nov 2015 14:22:32 +0900
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate:
On 2015/11/12 21:38, Peter Zijlstra wrote:
> On Thu, Nov 12, 2015 at 09:05:11PM +0900, Takao Indoh wrote:
>> Ping, any comments on these patches?
>>
>
> I've taken them, they should appear in tip sometime after the merge
> window closes.
>
Ok, thanks.
Thanks,
Tak
Ping, any comments on these patches?
Thanks,
Takao Indoh
On 2015/11/04 14:22, Takao Indoh wrote:
> Hi all,
>
> These patch series provide a feature to stop Intel Processor Trace
> (Intel PT) logging and save its registers in the memory on panic.
>
> Intel PT is a new fe
On 2015/11/12 21:38, Peter Zijlstra wrote:
> On Thu, Nov 12, 2015 at 09:05:11PM +0900, Takao Indoh wrote:
>> Ping, any comments on these patches?
>>
>
> I've taken them, they should appear in tip sometime after the merge
> window closes.
>
Ok, thanks.
Thanks,
Tak
Ping, any comments on these patches?
Thanks,
Takao Indoh
On 2015/11/04 14:22, Takao Indoh wrote:
> Hi all,
>
> These patch series provide a feature to stop Intel Processor Trace
> (Intel PT) logging and save its registers in the memory on panic.
>
> Intel PT is a new fe
m original patches.
Takao Indoh (2):
perf/x86/intel/pt: Add interface to stop Intel PT logging
x86: Stop Intel PT before kdump starts
arch/x86/include/asm/intel_pt.h | 10 ++
arch/x86/kernel/cpu/perf_event_intel_pt.c |9 +
arch/x86/kernel/crash.c
on the cpu where it is working, therefore user need to
call it for each cpu to stop all logging.
Signed-off-by: Takao Indoh
---
arch/x86/include/asm/intel_pt.h | 10 ++
arch/x86/kernel/cpu/perf_event_intel_pt.c |9 +
2 files changed, 19 insertions(+), 0 deletions
by kdump, user can retrieve the log buffer from vmcore and use
it to investigate kernel behavior.
Signed-off-by: Takao Indoh
---
arch/x86/kernel/crash.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index
on the cpu where it is working, therefore user need to
call it for each cpu to stop all logging.
Signed-off-by: Takao Indoh <indou.ta...@jp.fujitsu.com>
---
arch/x86/include/asm/intel_pt.h | 10 ++
arch/x86/kernel/cpu/perf_event_intel_pt.c |9 +
2 files chang
by kdump, user can retrieve the log buffer from vmcore and use
it to investigate kernel behavior.
Signed-off-by: Takao Indoh <indou.ta...@jp.fujitsu.com>
---
arch/x86/kernel/crash.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/ar
m original patches.
Takao Indoh (2):
perf/x86/intel/pt: Add interface to stop Intel PT logging
x86: Stop Intel PT before kdump starts
arch/x86/include/asm/intel_pt.h | 10 ++
arch/x86/kernel/cpu/perf_event_intel_pt.c |9 +
arch/x86/kernel/crash.c
on the cpu where it is working, therefore user need to
call it for each cpu to stop all logging.
Signed-off-by: Takao Indoh
---
arch/x86/include/asm/intel_pt.h | 10 ++
arch/x86/kernel/cpu/perf_event_intel_pt.c |9 +
2 files changed, 19 insertions(+), 0 deletions
by kdump, user can retrieve the log buffer from vmcore and use
it to investigate kernel behavior.
Signed-off-by: Takao Indoh
---
arch/x86/kernel/crash.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index
core dump. Apart
from such APIs, the feature to save Intel PT registers on panic is
helpful for normal perf command user as I described above, therefore I
separate the feature from original patches.
Takao Indoh (2):
perf/x86/intel/pt: Add interface to stop Intel PT logging
x86: Stop Intel PT be
core dump. Apart
from such APIs, the feature to save Intel PT registers on panic is
helpful for normal perf command user as I described above, therefore I
separate the feature from original patches.
Takao Indoh (2):
perf/x86/intel/pt: Add interface to stop Intel PT logging
x86: Stop Intel PT be
by kdump, user can retrieve the log buffer from vmcore and use
it to investigate kernel behavior.
Signed-off-by: Takao Indoh <indou.ta...@jp.fujitsu.com>
---
arch/x86/kernel/crash.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/crash.c b/ar
on the cpu where it is working, therefore user need to
call it for each cpu to stop all logging.
Signed-off-by: Takao Indoh <indou.ta...@jp.fujitsu.com>
---
arch/x86/include/asm/intel_pt.h | 10 ++
arch/x86/kernel/cpu/perf_event_intel_pt.c |9 +
2 files chang
On 2015/09/08 18:48, Alexander Shishkin wrote:
> Takao Indoh writes:
>
>> +/* intel_pt */
>> +static struct perf_event_attr pt_attr_pt = {
>> +.config = 0x400, /* bit10: TSCEn */
>
> Doesn't it make sense to make these things configurable via sysfs
On 2015/09/08 18:32, Alexander Shishkin wrote:
> Takao Indoh writes:
>
>> perf_event_create_kernel_counter is used to enable perf events in kernel
>> without buffer for logging its events. This patch add new fucntion which
>> enable perf events with ring buff
On 2015/09/08 18:32, Alexander Shishkin wrote:
> Takao Indoh <indou.ta...@jp.fujitsu.com> writes:
>
>> perf_event_create_kernel_counter is used to enable perf events in kernel
>> without buffer for logging its events. This patch add new fucntion which
>> enable perf
On 2015/09/08 18:48, Alexander Shishkin wrote:
> Takao Indoh <indou.ta...@jp.fujitsu.com> writes:
>
>> +/* intel_pt */
>> +static struct perf_event_attr pt_attr_pt = {
>> +.config = 0x400, /* bit10: TSCEn */
>
> Doesn't it make sense to make
perf_event_create_kernel_counter is used to enable perf events in kernel
without buffer for logging its events. This patch add new fucntion which
enable perf events with ring buffer. Intel PT logger uses this to enable
Intel PT and some associated events with its log buffer.
Signed-off-by: Takao
When panic occurs, Intel PT logging is stopped to prevent it from
overwrite its log buffer. The registers of Intel PT are saved in the
memory on panic, they are needed for debugger to find the last position
where Intel PT wrote data.
Signed-off-by: Takao Indoh
---
arch/x86/kernel/crash.c |9
r Intel PT and enable logging at boot
time. When kernel panic occurs, we can get this log buffer from
crashdump file by kdump, and reconstruct the flow that led to the panic.
changelog:
v2:
- Reimplement using perf_event_create_kernel_counter
v1:
https://lkml.org/lkml/2015/7/29/6
Takao Indoh (4):
te a cause of kernel panic.
The log buffer size is specified by the parameter
"intel_pt_log_buf_len=". This buffer is used as circular buffer,
therefore old events are overwritten by new events.
Signed-off-by: Takao Indoh
---
arch/x86/Kconfig | 16 +++
This patch adds function to find struct trace_event by event name like
"sched_switch" , and return its type so that Intel PT logger can enable
the trace event in kernel. Intel PT logger needs this because it needs
sched_switch tracing to collect side-band data.
Signed-off-by: T
te a cause of kernel panic.
The log buffer size is specified by the parameter
"intel_pt_log_buf_len=". This buffer is used as circular buffer,
therefore old events are overwritten by new events.
Signed-off-by: Takao Indoh <indou.ta...@jp.fujitsu.com>
---
arch/x86/Kconfig
When panic occurs, Intel PT logging is stopped to prevent it from
overwrite its log buffer. The registers of Intel PT are saved in the
memory on panic, they are needed for debugger to find the last position
where Intel PT wrote data.
Signed-off-by: Takao Indoh <indou.ta...@jp.fujitsu.
This patch adds function to find struct trace_event by event name like
"sched_switch" , and return its type so that Intel PT logger can enable
the trace event in kernel. Intel PT logger needs this because it needs
sched_switch tracing to collect side-band data.
Signed-off-by: T
r Intel PT and enable logging at boot
time. When kernel panic occurs, we can get this log buffer from
crashdump file by kdump, and reconstruct the flow that led to the panic.
changelog:
v2:
- Reimplement using perf_event_create_kernel_counter
v1:
https://lkml.org/lkml/2015/7/29/6
Takao Indoh (4):
perf_event_create_kernel_counter is used to enable perf events in kernel
without buffer for logging its events. This patch add new fucntion which
enable perf events with ring buffer. Intel PT logger uses this to enable
Intel PT and some associated events with its log buffer.
Signed-off-by: Takao
On 2015/07/29 15:08, Alexander Shishkin wrote:
> Takao Indoh writes:
>
>> This patch provides Intel PT logging feature. When system boots with a
>> parameter "intel_pt_log", log buffers for Intel PT are allocated and
>> logging starts, then processor flow
On 2015/07/29 15:08, Alexander Shishkin wrote:
Takao Indoh indou.ta...@jp.fujitsu.com writes:
This patch provides Intel PT logging feature. When system boots with a
parameter intel_pt_log, log buffers for Intel PT are allocated and
logging starts, then processor flow information is written
Commit-ID: 709bc871923c12b284424f9d47b99dc975ba8b29
Gitweb: http://git.kernel.org/tip/709bc871923c12b284424f9d47b99dc975ba8b29
Author: Takao Indoh
AuthorDate: Tue, 4 Aug 2015 18:36:55 +0900
Committer: Ingo Molnar
CommitDate: Wed, 12 Aug 2015 11:43:22 +0200
perf/x86/intel/pt: Clean up
Commit-ID: 709bc871923c12b284424f9d47b99dc975ba8b29
Gitweb: http://git.kernel.org/tip/709bc871923c12b284424f9d47b99dc975ba8b29
Author: Takao Indoh indou.ta...@jp.fujitsu.com
AuthorDate: Tue, 4 Aug 2015 18:36:55 +0900
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Wed, 12 Aug 2015 11
This patch just cleans up some files of Intel Processor Trace, does not
change its behavior. This patch removes unused definition and replaces a
constant value with macro.
changelog:
v2:
- Remove unnecessary fix
v1:
https://lkml.org/lkml/2015/8/3/96
Signed-off-by: Takao Indoh
---
arch/x86
This patch just cleans up some files of Intel Processor Trace, does not
change its behavior. This patch removes unused definition and replaces a
constant value with macro.
changelog:
v2:
- Remove unnecessary fix
v1:
https://lkml.org/lkml/2015/8/3/96
Signed-off-by: Takao Indoh indou.ta
is was typo. If it is intentional, I'll keep it intact.
Thanks,
Takao Indoh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 2015/08/03 18:44, Alexander Shishkin wrote:
> On 3 August 2015 at 12:08, Peter Zijlstra wrote:
>> On Mon, Aug 03, 2015 at 12:03:13PM +0300, Alexander Shishkin wrote:
>>> Takao Indoh writes:
>>
>>> Even though TOPA_SHIFT happens to be the same as PAGE_SHIFT, i
This patch just cleans up some files of Intel Processor Trace, does not
change its behavior. Removing unused definition, replace a constant
value with macro, etc.
Signed-off-by: Takao Indoh
---
arch/x86/kernel/cpu/intel_pt.h| 33 +---
arch/x86/kernel/cpu
.
Thanks,
Takao Indoh
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 2015/08/03 18:44, Alexander Shishkin wrote:
On 3 August 2015 at 12:08, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Aug 03, 2015 at 12:03:13PM +0300, Alexander Shishkin wrote:
Takao Indoh indou.ta...@jp.fujitsu.com writes:
Even though TOPA_SHIFT happens to be the same as PAGE_SHIFT
This patch just cleans up some files of Intel Processor Trace, does not
change its behavior. Removing unused definition, replace a constant
value with macro, etc.
Signed-off-by: Takao Indoh indou.ta...@jp.fujitsu.com
---
arch/x86/kernel/cpu/intel_pt.h| 33
On 2015/08/02 19:02, Thomas Gleixner wrote:
> On Wed, 29 Jul 2015, Takao Indoh wrote:
>> +/*
>> + * Table of Physical Addresses bits
>> + */
>> +enum topa_sz {
>> +TOPA_4K = 0,
>> +TOPA_8K,
>> +TOPA_16K,
>> +TOPA_32K,
>
On 2015/08/02 19:02, Thomas Gleixner wrote:
On Wed, 29 Jul 2015, Takao Indoh wrote:
+/*
+ * Table of Physical Addresses bits
+ */
+enum topa_sz {
+TOPA_4K = 0,
+TOPA_8K,
+TOPA_16K,
+TOPA_32K,
+TOPA_64K,
+TOPA_128K,
+TOPA_256K,
+TOPA_512K,
+TOPA_1MB
On 2015/07/29 18:09, Alexander Shishkin wrote:
> Takao Indoh writes:
>
>> On 2015/07/29 15:08, Alexander Shishkin wrote:
>>> Instead, we should be able to do use the existing perf functionality to
>>> enable the system-wide tracing, so that it goes through the
>
On 2015/07/29 15:08, Alexander Shishkin wrote:
> Takao Indoh writes:
>
>> This patch provides Intel PT logging feature. When system boots with a
>> parameter "intel_pt_log", log buffers for Intel PT are allocated and
>> logging starts, then processor flow
On 2015/07/29 18:09, Alexander Shishkin wrote:
Takao Indoh indou.ta...@jp.fujitsu.com writes:
On 2015/07/29 15:08, Alexander Shishkin wrote:
Instead, we should be able to do use the existing perf functionality to
enable the system-wide tracing, so that it goes through the
existing driver
On 2015/07/29 15:08, Alexander Shishkin wrote:
Takao Indoh indou.ta...@jp.fujitsu.com writes:
This patch provides Intel PT logging feature. When system boots with a
parameter intel_pt_log, log buffers for Intel PT are allocated and
logging starts, then processor flow information is written
On 2015/07/29 14:44, Alexander Shishkin wrote:
> Takao Indoh writes:
>
>> Hi all,
>>
>> This patch creates log buffer for Intel PT and enable logging at boot
>> time. When kernel panic occurs, we can get this log buffer from
>> crashdump file by kdum
te a cause of kernel panic.
The log buffer size is specified by the parameter
"intel_pt_log_buf_len=". This buffer is used as circular buffer,
therefore old events are overwritten by new events.
Signed-off-by: Takao Indoh
---
arch/x86/Kconfig | 16 ++
arch/x86
When panic occurs, Intel PT logging is stopped to prevent it from
overwrite its log buffer. The registers of Intel PT are saved in the
memory on panic, they are needed for debugger to find the last position
where Intel PT wrote data.
Signed-off-by: Takao Indoh
---
arch/x86/include/asm
Rename existing intel_pt.h to intel_pt_perf.h as a perf-specific header,
and make a new intel_pt.h as a common header of Intel PT feature. Also
add intel_pt_cap.c for Intel PT capability stuff.
Signed-off-by: Takao Indoh
---
arch/x86/include/asm/intel_pt.h | 82
r Intel PT and enable logging at boot
time. When kernel panic occurs, we can get this log buffer from
crashdump file by kdump, and reconstruct the flow that led to the panic.
Takao Indoh (3):
x86: Add Intel PT common files
x86: Add Intel PT logger
x86: Stop Intel PT and save its registers when pa
and enable logging at boot
time. When kernel panic occurs, we can get this log buffer from
crashdump file by kdump, and reconstruct the flow that led to the panic.
Takao Indoh (3):
x86: Add Intel PT common files
x86: Add Intel PT logger
x86: Stop Intel PT and save its registers when panic occurs
of kernel panic.
The log buffer size is specified by the parameter
intel_pt_log_buf_len=size. This buffer is used as circular buffer,
therefore old events are overwritten by new events.
Signed-off-by: Takao Indoh indou.ta...@jp.fujitsu.com
---
arch/x86/Kconfig | 16 ++
arch/x86
On 2015/07/29 14:44, Alexander Shishkin wrote:
Takao Indoh indou.ta...@jp.fujitsu.com writes:
Hi all,
This patch creates log buffer for Intel PT and enable logging at boot
time. When kernel panic occurs, we can get this log buffer from
crashdump file by kdump, and reconstruct the flow
When panic occurs, Intel PT logging is stopped to prevent it from
overwrite its log buffer. The registers of Intel PT are saved in the
memory on panic, they are needed for debugger to find the last position
where Intel PT wrote data.
Signed-off-by: Takao Indoh indou.ta...@jp.fujitsu.com
---
arch
Rename existing intel_pt.h to intel_pt_perf.h as a perf-specific header,
and make a new intel_pt.h as a common header of Intel PT feature. Also
add intel_pt_cap.c for Intel PT capability stuff.
Signed-off-by: Takao Indoh indou.ta...@jp.fujitsu.com
---
arch/x86/include/asm/intel_pt.h
On 2015/01/07 17:52, Li, ZhenHua wrote:
> Well, that's quite good news.
> Looking forward Takao's testing on his system.
Unfortunately DMAR fault still occurs with this patch...
I attach console log.
Thanks,
Takao Indoh
>
> Regards
> Zhenhua
> On 01/07/2015 04:28 PM, Baoquan
On 2015/01/07 17:52, Li, ZhenHua wrote:
Well, that's quite good news.
Looking forward Takao's testing on his system.
Unfortunately DMAR fault still occurs with this patch...
I attach console log.
Thanks,
Takao Indoh
Regards
Zhenhua
On 01/07/2015 04:28 PM, Baoquan He wrote:
On 01/07/15
On 2014/12/29 12:15, Li, ZhenHua wrote:
> Hi Takao Indoh,
>
> Happy New Year, and thank you very much for you help. The flush is quite
Happy new year!
> a problem, as there are several places the flush function should be called,
> I think the flush should be placed in
On 2014/12/29 12:15, Li, ZhenHua wrote:
Hi Takao Indoh,
Happy New Year, and thank you very much for you help. The flush is quite
Happy new year!
a problem, as there are several places the flush function should be called,
I think the flush should be placed in functions like
On 2014/12/26 15:46, Li, ZhenHua wrote:
> Hi Takao Indoh,
>
> Thank you very much for your testing. I will add your update in next
> version.
> Also I think a flush for __iommu_update_old_root_entry is also necessary.
>
> Currently I have no idea about your fault,
ommit 1a2262 was already applied. Any idea?
Thanks,
Takao Indoh
On 2014/12/22 18:15, Li, Zhen-Hua wrote:
> This patchset is an update of Bill Sumner's patchset, implements a fix for:
> If a kernel boots with intel_iommu=on on a system that supports intel vt-d,
> when a panic happens, the k
boot.
dmar: DRHD: handling fault status reg 2
dmar: DMAR:[DMA Write] Request device [01:00.0] fault addr ffded000
DMAR:[fault reason 01] Present bit in root entry is clear
I confiremd your commit 1a2262 was already applied. Any idea?
Thanks,
Takao Indoh
On 2014/12/22 18:15, Li, Zhen-Hua wrote
On 2014/12/26 15:46, Li, ZhenHua wrote:
Hi Takao Indoh,
Thank you very much for your testing. I will add your update in next
version.
Also I think a flush for __iommu_update_old_root_entry is also necessary.
Currently I have no idea about your fault, does it happen before or
during its
+ if (page_is_ram(pfn)) {
+ memcpy(buf, pfn_to_kaddr(pfn) + offset, csize);
+ ret = size;
+ } else
+ ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
return (int) ret;
}
Thanks,
Takao Indoh
>
> On 11/06/2014 09:48 AM, Takao Indoh wrote:
Thanks,
Takao Indoh
>
> Thanks
> Zhenhua
>
> On 11/06/2014 09:31 AM, Takao Indoh wrote:
>> Hi Zhenhua, Baoquan,
>>
>> (2014/10/22 19:05), Baoquan He wrote:
>>> Hi Zhenhua,
>>>
>>> I tested your latest patch on 3.18.0-rc1+, there are
shift = aw_shift[aw];
> +
> + pgt_old_phys = (struct dma_pte *)
> + (context_address_root(ce) << VTD_PAGE_SHIFT);
> +
> + ret = copy_page_table(_new_phys, pgt_old_phys,
> + shift-9, page_addr, iommu, bus, devfn,
);
+
+ if (ret)/* if (problem) bail out */
+ goto exit;
+
+ context_set_address_root(ce, (unsigned long)(pgt_new_phys));
ditto.
Thanks,
Takao Indoh
0console [earlya[0.00] allocate tes of page_cg 'a ong[
0.00] tsc: Fast TSC
(2014/11/06 10:35), Li, ZhenHua wrote:
Yes, that's it. The function context_set_address_root does not set the
address root correctly.
I have created another patch for it, see
https://lkml.org/lkml/2014/11/5/43
Oh, ok. I'll try again with this patch, thank you.
Thanks,
Takao Indoh
);
+
+ if (page_is_ram(pfn)) {
+ memcpy(buf, pfn_to_kaddr(pfn) + offset, csize);
+ ret = size;
+ } else
+ ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
return (int) ret;
}
Thanks,
Takao Indoh
On 11/06/2014 09:48 AM, Takao Indoh wrote
Hi ZhenHua,
(2014/10/20 11:19), Li, ZhenHua wrote:
> Hi Takao Indoh,
>
> According to this discussion
> https://lkml.org/lkml/2014/10/17/107
>
> It seems that we can not do the resetting on the first kernel. It can
> only be called during kdump kernel boots.
Sou
Hi ZhenHua,
(2014/10/20 11:19), Li, ZhenHua wrote:
Hi Takao Indoh,
According to this discussion
https://lkml.org/lkml/2014/10/17/107
It seems that we can not do the resetting on the first kernel. It can
only be called during kdump kernel boots.
Sounds like that. Do you know any
g errors in the
>> second kernel.
>>
>> To fix this DMAR fault, we need to reset the bus that this device on. Reset
>> the device itself does not work.
>>
>> A patch for this bug that has been sent before:
>> https://lkml.org/lkml/2014/9/30/55
>>
to reset
all
pci devices.
There was an original version(Takao Indoh) that resets the pcie devices:
https://lkml.org/lkml/2013/5/14/9
As far as I can remember, the original patch was nacked by
the following reasons:
1) On sparc, the IOMMU is initialized before PCI devices are enumerated,
so
ch, a pointer to smi_info in drvdata is cleared when hotmod
removing so that it will be not accessed when rmmod.
changelog:
v2:
- Clear drvdata in cleanup_one_si
- Change subject
v1:
https://lkml.org/lkml/2014/9/8/741
Signed-off-by: Takao Indoh
---
drivers/char/ipmi/ipmi_si_intf.c | 3 +++
1 fi
si() instead? I think that would be a cleaner
> and more general.
Ok, agreed.
> if (!info)
> return;
This is already done in the top of cleanup_one_si(), so I'll just
add this:
> if (info->dev)
> dev_set_drvdata(info->dev, NULL);
Thanks,
Takao Ind
and more general.
Ok, agreed.
if (!info)
return;
This is already done in the top of cleanup_one_si(), so I'll just
add this:
if (info-dev)
dev_set_drvdata(info-dev, NULL);
Thanks,
Takao Indoh
-corey
On 09/08/2014 07:19 PM, Takao Indoh wrote:
Add another
to smi_info in drvdata is cleared when hotmod
removing so that it will be not accessed when rmmod.
changelog:
v2:
- Clear drvdata in cleanup_one_si
- Change subject
v1:
https://lkml.org/lkml/2014/9/8/741
Signed-off-by: Takao Indoh indou.ta...@jp.fujitsu.com
---
drivers/char/ipmi/ipmi_si_intf.c
ies to remove it again and fails.
By this patch, a pointer to smi_info in drvdata is cleared when hotmod
removing so that it will be not accessed when rmmod.
Signed-off-by: Takao Indoh
---
drivers/char/ipmi/ipmi_si_intf.c | 27 +--
1 file changed, 21 insertions(+), 6 delet
it again and fails.
By this patch, a pointer to smi_info in drvdata is cleared when hotmod
removing so that it will be not accessed when rmmod.
Signed-off-by: Takao Indoh indou.ta...@jp.fujitsu.com
---
drivers/char/ipmi/ipmi_si_intf.c | 27 +--
1 file changed, 21
ch, a pointer to smi_info in drvdata is cleared when hotmod
removing so that it will be not accessed when rmmod.
Signed-off-by: Takao Indoh
---
drivers/char/ipmi/ipmi_si_intf.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/char/ipmi/ipm
to smi_info in drvdata is cleared when hotmod
removing so that it will be not accessed when rmmod.
Signed-off-by: Takao Indoh indou.ta...@jp.fujitsu.com
---
drivers/char/ipmi/ipmi_si_intf.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/char
rt == end)
return;
/*
* Need ftrace_lock here to prevent someone from changing the module
* text to RO by set_all_modules_text_ro(). Currently ftrace is the
* only user of set_all_modules_text_ro(), so until another user
* appears, ftrace_lock m
(mod, start, end);
set_one_module_text_ro(mod);
mutex_unlock(ftrace_lock);
}
Thanks,
Takao Indoh
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
(2014/04/22 16:28), Masami Hiramatsu wrote:
> (2014/04/22 14:29), Takao Indoh wrote:
>> (2014/04/22 12:51), Rusty Russell wrote:
>>> Steven Rostedt writes:
>>>> On Mon, 24 Mar 2014 20:26:05 +0900
>>>> Masami Hiramatsu wrote:
>>>>
>>
1 - 100 of 310 matches
Mail list logo
