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
'm thinking 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 is
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 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
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
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
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
e from 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
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
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
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
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
ocess 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
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 s
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 buffer. Inte
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
tel 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):
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
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
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
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
ht this 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
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/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 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 kdump, and
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
tel 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
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
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/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, doe
nfiremd your commit 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,
> whe
et, userbuf);
+
+ 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, Taka
thank you.
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+,
> + shift = aw_shift[aw];
> +
> + pgt_old_phys = (struct dma_pte *)
> + (context_address_root(ce) << VTD_PAGE_SHIFT);
> +
> + ret = copy_page_table(&pgt_new_phys, pgt_old_phys,
> +
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
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
>> As in
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
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,
Taka
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
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
if (ftrace_disabled || start == 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
(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:
>>>>
>>
s_locs() is called from the notifier,
and it tries to change its text like this.
load_module
blocking_notifier_call_chain
ftrace_module_notify_enter
ftrace_init_module
ftrace_process_locs
sort
ftrace_swap_ips
But the text is already RO, so it causes panic. We
his warning message is avoided. Module B is changed to RO in the
do_init_module() after comes back from notifier.
Signed-off-by: Takao Indoh
Signed-off-by: Steven Rostedt
Reviewed-by: Masami Hiramatsu
---
include/linux/module.h | 9 +
kernel/module.c| 13 -
2 files
ping, any comments?
(2014/04/02 16:54), Takao Indoh wrote:
> This patch adds new module state MODULE_STATE_COMING_FINAL to avoid
> ftrace waring message when loading two modules simultaneously.
>
> The original patch was written by Steven Rostedt, see below.
> https://lkml.org/lkm
es back from notifier.
Signed-off-by: Takao Indoh
---
include/linux/module.h | 9 +
kernel/module.c| 13 -
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index eaf60ff..32f4481 100644
--- a/include/linux/mo
hich is
>> MODULE_STATE_COMING)
>>
>
> Does this patch fix it?
Yep, I tested using my reproducer and confirmed that this patch fixed
this issue, thanks!
Thanks,
Takao Indoh
>
> In-review-off-by: Steven Rostedt
>
> diff --git a/include/linux/module.h b/include/
at (3)
o Module B wakes up and tries to rewrite its text at (5), but it fails
because it is already changed to RO at (2) by modules A. The ftrace
waring message is outputted.
I'm not familiar with ftrace/kprobe, so any comments/suggestions would
be appreciatd to fix this.
Thanks,
Takao In
You asked: " Do you have a plan to post new version?"
> Yes. I am in the process of dividing the code into a set of 6 or 7 patches,
> and completing the due-diligence on these patches before submitting them.
Ok, I'll wait for new patches!
Thanks,
Takao Indoh
>
last kdump fails. This patch fixes this problem.
Changelog:
v2:
- Add CONTEXT_ENTRY_NR
v1:
https://lkml.org/lkml/2013/8/21/71
Signed-off-by: Takao Indoh
---
drivers/iommu/intel-iommu.c | 56 ++-
1 files changed, 55 insertions(+), 1 deletions(-)
diff --git
(2013/09/09 18:07), David Woodhouse wrote:
> On Wed, 2013-08-21 at 16:15 +0900, Takao Indoh wrote:
>>
>> This causes problem on kdump. Devices are working in first kernel, and
>> after switching to second kernel and initializing IOMMU, many DMAR faults
>> occur and it
(2013/09/09 13:28), Takao Indoh wrote:
>> BTW, what's the status of Alex's PCI patchset which this patch depends
>> on?
>
> It is merged to Bjorn's tree, will be in v3.12.
This was wrong. Alex's patchset is already in Linus tree, v3.11.
Thanks,
Takao In
(2013/09/08 20:47), Baoquan He wrote:
> Hi,
> Patch is great and works on my HP-z420.
Thank you for your test!
> There are several small concerns, please see inline comments.
>
> On 08/21/13 at 04:15pm, Takao Indoh wrote:
>> This patch quiesces devices before disabling
last
kdump fails. This patch fixes this problem.
Signed-off-by: Takao Indoh
NOTE:
To reset devices this patch uses bus reset interface introduced by
following commits in PCI "next" branch.
64e8674fbe6bc848333a9b7e19f8cc019dde9eab
5c32b35b004f5ef70dcf62bbc42b8b
(2013/08/01 6:23), Rafael J. Wysocki wrote:
> On Wednesday, July 31, 2013 03:08:03 PM Bjorn Helgaas wrote:
>> [+cc Rafael, linux-acpi]
>>
>> On Tue, Jul 30, 2013 at 6:35 PM, Takao Indoh
>> wrote:
>>
>>> On x86, currently IOMMU initialization run *af
(2013/07/31 12:11), Alex Williamson wrote:
> On Wed, 2013-07-31 at 09:35 +0900, Takao Indoh wrote:
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index e37fea6..c595997 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -3392,6 +3392,59
(2013/07/31 0:59), Bjorn Helgaas wrote:
> On Tue, Jul 30, 2013 at 12:09 AM, Takao Indoh
> wrote:
>> (2013/07/29 23:17), Bjorn Helgaas wrote:
>>> On Sun, Jul 28, 2013 at 6:37 PM, Takao Indoh
>>> wrote:
>>>> (2013/07/26 2:00), Bjorn Helgaas wr
(2013/07/29 23:17), Bjorn Helgaas wrote:
> On Sun, Jul 28, 2013 at 6:37 PM, Takao Indoh
> wrote:
>> (2013/07/26 2:00), Bjorn Helgaas wrote:
>>> On Wed, Jul 24, 2013 at 12:29 AM, Takao Indoh
>>> wrote:
>>>> Sorry for letting this discussion slide, I w
(2013/07/26 2:00), Bjorn Helgaas wrote:
> On Wed, Jul 24, 2013 at 12:29 AM, Takao Indoh
> wrote:
>> Sorry for letting this discussion slide, I was busy on other works:-(
>> Anyway, the summary of previous discussion is:
>> - My patch adds new initcall(fs_initcall) to res
(2013/07/25 23:24), Vivek Goyal wrote:
> On Wed, Jul 24, 2013 at 03:29:58PM +0900, Takao Indoh wrote:
>> Sorry for letting this discussion slide, I was busy on other works:-(
>> Anyway, the summary of previous discussion is:
>> - My patch adds new initcall(fs_initcall) to res
of it. Introducing new boot
parameter seems to be unpopular for maintainers. Any ideas?
Thanks,
Takao Indoh
(2013/06/14 11:11), Takao Indoh wrote:
> (2013/06/13 12:41), Bjorn Helgaas wrote:
>> On Wed, Jun 12, 2013 at 8:44 PM, Takao Indoh
>> wrote:
>>> (2013/06/12 13:45), B
ague said that we need to run BIOS code to get back legacy
VGA mode after reset. It seems not to be easy:-(
Maybe this document is helpful to do this.
http://www.coreboot.org/images/2/2b/Vgabios.pdf
Thanks,
Takao Indoh
>
> We have problems, if 1st kernel is in kms mode kdump kernel will h
(2013/06/13 12:41), Bjorn Helgaas wrote:
> On Wed, Jun 12, 2013 at 8:44 PM, Takao Indoh
> wrote:
>> (2013/06/12 13:45), Bjorn Helgaas wrote:
>>> [+cc Vivek, Haren; sorry I didn't think to add you earlier]
>>>
>>> On Tue, Jun 11, 2013 at 12:08 AM, Ta
(2013/06/12 22:19), Don Dutile wrote:
> On 06/11/2013 07:19 PM, Sumner, William wrote:
>>
>>> (2013/06/11 11:20), Bjorn Helgaas wrote:
>>>> On Fri, Jun 7, 2013 at 2:46 AM, Takao Indoh
>>>> wrote:
>>>>> (2013/06/07 13:14), Bjorn Helgaas wr
(2013/06/12 13:45), Bjorn Helgaas wrote:
> [+cc Vivek, Haren; sorry I didn't think to add you earlier]
>
> On Tue, Jun 11, 2013 at 12:08 AM, Takao Indoh
> wrote:
>> (2013/06/11 11:20), Bjorn Helgaas wrote:
>
>>> I'm not sure you need to reset legacy devic
(2013/06/11 11:20), Bjorn Helgaas wrote:
> On Fri, Jun 7, 2013 at 2:46 AM, Takao Indoh
> wrote:
>> (2013/06/07 13:14), Bjorn Helgaas wrote:
>
>>> One thing I'm not sure about is that you are only resetting PCIe
>>> devices, but I don't think the prob
I'm naive about both
> IOMMUs and kexec/kdump, so please pardon (and help me with) any silly
> questions or assumptions below.
>
> On Mon, May 13, 2013 at 11:29 PM, Takao Indoh
> wrote:
>> This patch resets PCIe devices on boot to stop ongoing DMA. When
>> "p
make.
Thanks,
Takao Indoh
(2013/05/14 14:29), Takao Indoh wrote:
> This patch resets PCIe devices on boot to stop ongoing DMA. When
> "pci=pcie_reset_endpoint_devices" is specified, a hot reset is triggered
> on each PCIe root port and downstream port to reset its downstream
Hi Bjorn,
Any comments, ack/nack?
Thanks,
Takao Indoh
(2013/05/15 7:04), Eric W. Biederman wrote:
> Takao Indoh writes:
>
>> This patch resets PCIe devices on boot to stop ongoing DMA. When
>> "pci=pcie_reset_endpoint_devices" is specified, a hot reset is trigger
rred after its driver was loaded.
One of ideas is adding boot parameter so user can choose appropriate
method: just clearing bus master, FLR, hot-reset, etc.
Thanks,
Takao Indoh
>
> Bill Sumner
>
>
>
> -Original Message-
> From: Takao Indoh [mailto:indou.ta...@jp.fu
is skipped because
the monitor blacks out if VGA controller is reset.
Changelog:
v2:
- Read pci config before de-assert secondary bus reset to flush previous
write
- Change function/variable name
- Make a list of devices to be reset
v1:
https://patchwork.kernel.org/patch/2482291/
Signed-off
(2013/04/26 3:01), Don Dutile wrote:
> On 04/25/2013 01:11 AM, Takao Indoh wrote:
>> (2013/04/25 4:59), Don Dutile wrote:
>>> On 04/24/2013 12:58 AM, Takao Indoh wrote:
>>>> This patch resets PCIe devices on boot to stop ongoing DMA. When
>>>> "pci=p
(2013/05/08 7:04), Alex Williamson wrote:
> On Tue, 2013-05-07 at 16:10 -0400, Don Dutile wrote:
>> On 05/07/2013 12:39 PM, Alex Williamson wrote:
>>> On Wed, 2013-04-24 at 13:58 +0900, Takao Indoh wrote:
>>>> This patch resets PCIe devices on boot to st
(2013/05/07 21:50), Don Dutile wrote:
> On 05/07/2013 03:09 AM, Takao Indoh wrote:
>> Sorry for the delayed response.
>>
>> (2013/04/30 23:54), Sumner, William wrote:
>>> I have installed your original patch set (from last November) and tested
>>> with th
still hangs up or not.
subordinate = dev->subordinate;
list_for_each_entry(child, &subordinate->devices, bus_list) {
dev_info(&child->dev, "save state\n");
pci_save_state(child);
+ pci_write_config_word(c
(2013/04/26 3:01), Don Dutile wrote:
> On 04/25/2013 01:11 AM, Takao Indoh wrote:
>> (2013/04/25 4:59), Don Dutile wrote:
>>> On 04/24/2013 12:58 AM, Takao Indoh wrote:
>>>> This patch resets PCIe devices on boot to stop ongoing DMA. When
>>>> "pci=p
(2013/04/25 4:59), Don Dutile wrote:
> On 04/24/2013 12:58 AM, Takao Indoh wrote:
>> This patch resets PCIe devices on boot to stop ongoing DMA. When
>> "pci=pcie_reset_devices" is specified, a hot reset is triggered on each
>> PCIe root port and downstream port t
814
Signed-off-by: Takao Indoh
---
Documentation/kernel-parameters.txt |2 +
drivers/pci/pci.c | 103 +++
2 files changed, 105 insertions(+), 0 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.tx
igned-off-by: Takao Indoh
---
drivers/iommu/dmar.c| 11 ++-
drivers/iommu/intel-iommu.c | 15 +++
2 files changed, 25 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index e5cdaf8..9f69352 100644
--- a/drivers/iommu/dma
(2013/04/22 15:50), Wei Hu wrote:
> On Sun, Apr 21, 2013 at 10:31 PM, Takao Indoh
> wrote:
>> (2013/04/20 15:58), Wei Hu wrote:
>>> On a VT-d capable machine Linux will enable IOMMU by default. If it
>>> then kexec's a second kernel with intel_iommu=off, this s
n(iommu);
}
Note, if you agree above code and fix your patch like this, you need
additinal fix to set iommu->gcmd flag sinse gcmd is always zero here.
See first hunk of this patch.
https://lkml.org/lkml/2013/3/20/707
Thanks,
Takao Indoh
>
> Signed-off-by: Wei Hu
&g
(2013/04/15 19:18), Joerg Roedel wrote:
> On Mon, Apr 15, 2013 at 06:00:13PM +0900, Takao Indoh wrote:
>> On DMAR initialization during kdump boot, do you guys agree to change
>> order like this?
>>
>> Current order:
>> (1) Disable translation
>> (2) PCI
(2013/04/10 13:47), Takao Indoh wrote:
> (2013/04/05 20:06), Joerg Roedel wrote:
>> On Wed, Apr 03, 2013 at 09:24:39AM +0100, David Woodhouse wrote:
>>> On Wed, 2013-04-03 at 16:11 +0900, Takao Indoh wrote:
>>>> Yeah, you are right. I forgot such a case.
>>
(2013/04/05 20:06), Joerg Roedel wrote:
> On Wed, Apr 03, 2013 at 09:24:39AM +0100, David Woodhouse wrote:
>> On Wed, 2013-04-03 at 16:11 +0900, Takao Indoh wrote:
>>> Yeah, you are right. I forgot such a case.
>>
>> If you disable translation and there's some de
(2013/04/04 23:24), David Woodhouse wrote:
> On Thu, 2013-04-04 at 14:48 +0900, Takao Indoh wrote:
>>
>> - DMAR fault messages floods and second kernel does not boot. Recently I
>>saw similar report. https://lkml.org/lkml/2013/3/8/120
>
> Right. So the fix for tha
(2013/04/03 17:24), David Woodhouse wrote:
> On Wed, 2013-04-03 at 16:11 +0900, Takao Indoh wrote:
>> (2013/04/02 23:05), Joerg Roedel wrote:
>>> On Mon, Apr 01, 2013 at 02:45:18PM +0900, Takao Indoh wrote:
>>>>
>>>> ena
(2013/04/02 23:05), Joerg Roedel wrote:
> On Mon, Apr 01, 2013 at 02:45:18PM +0900, Takao Indoh wrote:
>>
>> enable_IR
>>intel_enable_irq_remapping
>> iommu_disable_irq_remapping <== IRES/QIES/TES disabled here
>> dmar_disable_qi &
(2013/03/27 19:31), Joerg Roedel wrote:
> On Wed, Mar 27, 2013 at 02:02:44PM +0900, Takao Indoh wrote:
>> The root cause of this problem is mismatch between iommu->gcmd and
>> global command register in the case of kdump. At boot time, initial
>> value of iommu->gcmd is
(2013/03/26 23:46), Joerg Roedel wrote:
> On Thu, Mar 21, 2013 at 10:32:36AM +0900, Takao Indoh wrote:
>> In this function, clearing IRE bit in iommu->gcmd and writing it to
>> global command register. But initial value of iommu->gcmd is zero, so
>> this writel means
1 - 100 of 158 matches
Mail list logo
