("fs/proc: Add boot loader arguments as comment to
/proc/bootconfig")
Signed-off-by: Zhenhua Huang
---
fs/proc/bootconfig.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/fs/proc/bootconfig.c b/fs/proc/bootconfig.c
index 902b326..e5635a6 100644
--- a/f
On Fri, Nov 20, 2020 at 01:04:23PM +0800, Minchan Kim wrote:
> On Thu, Nov 19, 2020 at 11:34:32AM +0800, Zhenhua Huang wrote:
> > On Wed, Nov 04, 2020 at 07:27:03AM +0800, Minchan Kim wrote:
> > > Sorry if this mail corrupts the mail thread or had heavy mangling
> > >
On Wed, Nov 04, 2020 at 07:27:03AM +0800, Minchan Kim wrote:
> Sorry if this mail corrupts the mail thread or had heavy mangling
> since I lost this mail from my mailbox so I am sending this mail by
> web gmail.
>
> On Thu, Oct 22, 2020 at 10:18 AM wrote:
> >
> > From: Yogesh Lal
> >
> > Use STA
On Mon, Oct 26, 2020 at 05:39:34PM +0800, Mike Rapoport wrote:
> On Mon, Oct 26, 2020 at 03:12:55PM +0800, Zhenhua Huang wrote:
> > Hi Mike,
> >
> > On Sun, Oct 25, 2020 at 11:42:53PM +0800, Mike Rapoport wrote:
> > > On Fri, Oct 16, 2020 at 05:14:00PM +0800, Zhe
Hi Mike,
On Sun, Oct 25, 2020 at 11:42:53PM +0800, Mike Rapoport wrote:
> On Fri, Oct 16, 2020 at 05:14:00PM +0800, Zhenhua Huang wrote:
> > Page owner of pages used by page owner itself used is missing on arm32
> targets.
> > The reason is dummy_handle and failure_handle
Hi Mike,
On Sun, Oct 25, 2020 at 11:42:53PM +0800, Mike Rapoport wrote:
> On Fri, Oct 16, 2020 at 05:14:00PM +0800, Zhenhua Huang wrote:
> > Page owner of pages used by page owner itself used is missing on arm32
> targets.
> > The reason is dummy_handle and failure_handle
: Zhenhua Huang
---
include/linux/page_ext.h | 8
init/main.c | 2 ++
mm/page_ext.c| 10 --
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h
index cfce186..aff81ba 100644
--- a/include/linux
allocated via order 2, mask 0x6202c0(GFP_USER|__GFP_NOWARN), pid 1006, ts
67278156558 ns
PFN 543776 type Unmovable Block 531 type Unmovable Flags 0x0()
init_page_owner+0x28/0x2f8
invoke_init_callbacks_flatmem+0x24/0x34
start_kernel+0x33c/0x5d8
(null)
Signed-off-by: Zhenhua Huang
---
include/linux
Fri, Oct 16, 2020 at 06:41:04PM +0800, Vlastimil Babka wrote:
> On 10/16/20 11:14 AM, Zhenhua Huang wrote:
> >Page owner of pages used by page owner itself used is missing on arm32
> >targets.
> >The reason is dummy_handle and failure_handle is not initialized
> >corre
allocated via order 2, mask 0x6202c0(GFP_USER|__GFP_NOWARN), pid 1006, ts
67278156558 ns
PFN 543776 type Unmovable Block 531 type Unmovable Flags 0x0()
init_page_owner+0x28/0x2f8
invoke_init_callbacks_flatmem+0x24/0x34
start_kernel+0x33c/0x5d8
(null)
Signed-off-by: Zhenhua Huang
---
include/linux
The parameter "handler" is not checked, which may cause system
crash on some broken devices.
Signed-off-by: Zhenhua
---
drivers/tty/vt/keyboard.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/tty/vt/keyboard.c b/drivers/tty/vt/keyboard.c
index f4166263bb3a..f8
These two pointers should be checked, for some broken devices they may
cause system crash.
Signed-off-by: Zhenhua
---
drivers/acpi/acpica/nsaccess.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/acpica/nsaccess.c b/drivers/acpi/acpica/nsaccess.c
index
Hi all,
I see Joerg has backported it to sles12 in the commoent of novel
bugzilla 856382, so I will only backport it to redhat el.
Thanks
Zhenhua
On 06/13/2015 02:47 PM, Joerg Roedel wrote:
Hi,
as David Woodhouse pointed out, my fixes and cleanups for
the original patch-set turned out to be a
, I believe there are. Also not
all HP systems have such problem.
I agree with a blacklist for devices.
Thanks
Zhenhua
--
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/
his and tell the device to not try further.
Joerg
Is PASID part of new specs? Is there any plan to upgrade the driver to
support the latest vt-d specs?
Zhenhua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger
My pleasure, thanks.
Zhenhua
On 06/08/2015 04:23 PM, Joerg Roedel wrote:
On Mon, Jun 08, 2015 at 04:06:45PM +0800, Li, ZhenHua wrote:
Finished testing on my HP huge system, SuperDome X.
It works well.
Thanks for testing this, Zhen-Hua. Might I add your Tested-by to the
patches
Finished testing on my HP huge system, SuperDome X.
It works well.
Thanks
Zhenhua
On 06/05/2015 10:10 PM, Joerg Roedel wrote:
Hey,
here are a couple of patches to fix the fall-out from the
patch set fixing the kdump faults with VT-d enabled. A few
important issues have been fixed
= intel_free_coherent,
.map_sg = intel_map_sg,
.unmap_sg = intel_unmap_sg,
.map_page = intel_map_page,
.unmap_page = intel_unmap_page,
.mapping_error = intel_mapping_error,
};
You can also add dump_stack() in __get_valid_domain_for_dev to debug.
Thanks
Zhenhua
Hi Baoquan,
In the early version of this patchset, old page tables are used by new
kernel. But as discussed, we need to make kernel use new pages when
there is a new dma request , so we need to unmap the pages which were
mapped in old kernel, and this is what this patch does.
Thanks
Zhenhua
Hi Dave,
Don't worry :).
Of cause I have read your comments, but most of them contains no actual
code change request, so I did not reply them one by one.
When we are sure there is no actual code change needed, I will update
the comments and other format problems if necessary.
Regards
Zh
.
Thanks
Zhenhua
On 05/13/2015 09:54 AM, Li, ZhenHua wrote:
One thing must be pointed out:
There is a known issue that hpsa driver cannot work well in kdump
kernel. And this patchset is not intended to fix this problem.
So this patchset cannot work with HP smart array devices which need hpsa
Hi Baoquan,
I am using a list here to store all the mapped addresses, and unmap them
out of iounmap.
About the reason, please check the old mails. I cannot remember the
detailed reasons.
Thanks
Zhenhua
On 05/13/2015 05:00 PM, Baoquan He wrote:
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote
Hi Dave,
iommu->root_entry_old_virt is used to store the mapped old rta.
iommu->root_entry_old_phys is used to store the physical address stored
in registers.
So we must not free/unmap iommu->root_entry_old_phys .
Zhenhua
On 05/13/2015 04:56 PM, Baoquan He wrote:
+
+
+static u8 g_translation_pre_enabled;
Hi Zhenhua,
I haven't checked patch one by one, am going through the code flow.
About g_translation_pre_enabled, I don't think it's necessary to define
it as a global variable. Both its assignment and judgement are in
init_dmars(). In t
One thing must be pointed out:
There is a known issue that hpsa driver cannot work well in kdump
kernel. And this patchset is not intended to fix this problem.
So this patchset cannot work with HP smart array devices which need hpsa
driver.
On 05/11/2015 05:52 PM, Li, Zhen-Hua wrote:
This p
On 05/12/2015 04:37 PM, Dave Young wrote:
Seems the subject was truncated? Maybe "re" means root entry? Then please fix it
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Add functions to load root entry table from old kernel, and to save updated
root entry table.
Add two member in struct intel_iom
On 05/12/2015 04:17 PM, Dave Young wrote:
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Add context entry functions needed for kdump.
+/*
+ * Fix Crashdump failure caused by leftover DMA through a hardware IOMMU
+ *
+ * Fixes the crashdump kernel to deal with an active iommu and legacy
+ * DMA fro
Hi Joerg,
This problem is caused by the latest updates in iommu module, and we are
trying to fix it.
When it is fixed, we will send out a new version of the patchset.
Thanks
Zhenhua
On 05/08/2015 01:32 AM, Joerg Roedel wrote:
Hi Baoquan, ZhenHua,
On Mon, May 04, 2015 at 11:17:49AM +0800
It is called in
static int copy_root_entry_table(struct intel_iommu *iommu);
On 05/07/2015 03:49 PM, Baoquan He wrote:
On 04/10/15 at 04:42pm, Li, Zhen-Hua wrote:
Add some functions to copy the data from old kernel.
These functions are used to copy context tables and page tables.
To avoid cal
Dave,
This patchset will only write root tables in old kernel, if it is
corrupted, faults will also happen in old kernel, and hardware would
mark it. So things will not go worse..
Thanks
Zhenhua
On 05/06/2015 09:51 AM, Dave Young wrote:
On 05/05/15 at 05:31pm, Joerg Roedel wrote:
On Tue
Hi baoquan,
Could you paste the kernel log of the first kernel ?
Thanks
Zhenhua
On 05/03/2015 04:55 PM, Baoquan He wrote:
On 04/29/15 at 07:20pm, Baoquan He wrote:
Bad news, I rebuilt a kernel with your patchset on 4.0.0+ (this commit
f614c81). Now dmar fault is seen again.
The lspci log and
ables.
Till now, I do not have a good idea to do the check in kdump kernel.
Thanks
Zhenhua
On 04/28/2015 04:54 PM, Baoquan He wrote:
On 04/24/15 at 04:49pm, Dave Young wrote:
On 04/24/15 at 04:35pm, Baoquan He wrote:
On 04/24/15 at 04:25pm, Dave Young wrote:
Hi, Baoquan
I support this pat
Hi Dave,
I found the old mail:
http://lkml.iu.edu/hypermail/linux/kernel/1410.2/03584.html
Please check this and you will find the discussion.
Regards
Zhenhua
On 04/15/2015 02:48 PM, Dave Young wrote:
On 04/15/15 at 01:47pm, Li, ZhenHua wrote:
On 04/15/2015 08:57 AM, Dave Young wrote:
Again
.html
https://lkml.org/lkml/2014/10/21/890
Thanks
Zhenhua
--
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 04/07/2015 05:08 PM, Dave Young wrote:
On 04/07/15 at 11:46am, Dave Young wrote:
On 04/05/15 at 09:54am, Baoquan He wrote:
On 04/03/15 at 05:21pm, Dave Young wrote:
On 04/03/15 at 05:01pm, Li, ZhenHua wrote:
Hi Dave,
There may be some possibilities that the old iommu data is corrupted by
kernel, the
queue used by the qi_* functions was written again by another module.
The fix was in that module, not in iommu module.
Thanks
Zhenhua
On 04/03/2015 04:40 PM, Dave Young wrote:
To fix this problem, we modifies the behaviors of the intel vt-d in the
crashdump kernel:
For DMA
with these faults:
Zhenhua,
I will review the patchset recently, sorry for jumping in late.
Thanks
Dave
Hi Dave,
Thanks for your review. And please also take a look at the plan I sent
in another mail:
Change use of
if (is_kdump_kernel()) { }
To:
if (iommu_enabled_in_last_kernel) { }
ir_table->base to iommu->ir_table->base_old_phys. Because in
kdump kernel, the vt-d is using ir_table->base_old_phys, not
ir_table->base, so we need to copy the updated ir_table->base to
ir_table->base_old_phys .
Thanks
Zhenhua
On 04/02/2015 07:28 PM, Joerg Roedel wrote:
-iommu.c using "checkpatch.pl -f", found too many
warnings and errors. Maybe we need a new patch to fix them.
Thanks
Zhenhua
On 04/02/2015 07:11 PM, Joerg Roedel wrote:
Hi Zhen-Hua,
On Thu, Mar 19, 2015 at 01:36:18PM +0800, Li, Zhen-Hua wrote:
This patchset is an update of Bill Sumner&
these tables.
3. Replace all
#ifdef CONFIG_CRASH_DUMP
if (is_kdump_kernel()) {
// Do some thing
}
#endif
To:
if (iommu_enabled_in_last_kernel) {
// Do some thing
}
Do you agree with these?
Thanks
Zhenhua
On 04/02/2015 07:06 PM, Joerg Roedel wrote:
On Thu, Mar
Hi Baoquan,
Thank you very much for your review. But according to the latest
discussion, the page tables will not be copied from old kernel. We keep
using the old page tables before driver is loaded. So there are many
changes in next version;
See my comments.
On 01/15/2015 11:28 AM, Baoquan He w
ables, the patchset will use less code.
Functions copy_page_addr, copy_page_table are no longer needed, and
functions copy_context_entry and copy_context_entry_table will be
reduced to several lines. The patchset will be much simpler.
Zhenhua
--
To unsubscribe from this list: send the line "un
iommu_attach_domain():
iommu_attach_domai(...)
{
return iommu_attach_domain_with_id(..., -1);
}
This way you don't have to update all the callers of
iommu_attach_domain() and the interface is more readable.
Joerg
That's a good way. I will do this in
On 01/12/2015 05:07 PM, Baoquan He wrote:
On 01/12/15 at 04:00pm, Li, ZhenHua wrote:
Comparing to v7, this version adds only a few lines code:
In function copy_page_table,
+ __iommu_flush_cache(iommu, phys_to_virt(dma_pte_next),
+ VTD_PAGE_SIZE
Comparing to v7, this version adds only a few lines code:
In function copy_page_table,
+ __iommu_flush_cache(iommu, phys_to_virt(dma_pte_next),
+ VTD_PAGE_SIZE);
On 01/12/2015 03:06 PM, Li, Zhen-Hua wrote:
This patchset is an update of Bill Sumner's
Well, that's quite good news.
Looking forward Takao's testing on his system.
Regards
Zhenhua
On 01/07/2015 04:28 PM, Baoquan He wrote:
On 01/07/15 at 01:25pm, Li, ZhenHua wrote:
It is same as the last one I send to you yesterday.
The continuous memory that needed for data in this pa
.
Regards
Zhenhua
On 01/07/2015 01:02 PM, Baoquan He wrote:
On 01/07/15 at 12:11pm, Li, ZhenHua wrote:
Many thanks to Takao Indoh and Baoquan He, for your testing on more
different systems.
The calling of flush functions are added to this version.
The usage of __iommu_flush_cache function :
1
Many thanks to Takao Indoh and Baoquan He, for your testing on more
different systems.
The calling of flush functions are added to this version.
The usage of __iommu_flush_cache function :
1. Fixes a dump on Takao's system.
2. Reduces the count of faults on Baoquan's system.
Regar
2015 02:37 PM, Baoquan He wrote:
Hi Zhenhua,
I just tested your patchset based on 3.19.0-rc2+, and found several dmar
fault and intr-remap fault, it seems not the same as Takao's, please
check the attachment.
Thanks
Baoquan
--
To unsubscribe from this list: send the line "unsubscribe
Thank you very much for your help.
I have found there are several places need flush, and I will send a new
version
of this patchset with the flush functions.
Regards
Zhenhua
On 01/06/2015 08:18 AM, Takao Indoh wrote:
> On 2014/12/29 12:15, Li, ZhenHua wrote:
>> Hi Takao Indoh,
>&g
7/10, so please *unpatch* it from the kernel (others and the attached one
should be patched), and then test the kernel.
Regards
Zhenhua
On 12/26/2014 03:27 PM, Takao Indoh wrote:
> On 2014/12/26 15:46, Li, ZhenHua wrote:
>> Hi Takao Indoh,
>>
>> Thank you very much for you
as an
attachment?
Regards and Merry Christmas.
Zhenhua
On 12/26/2014 01:13 PM, Takao Indoh wrote:
> Hi Zhen-Hua,
>
> I tested your patch and found two problems.
>
> [1]
> Kenel panic occurs during 2nd kernel boot.
>
> ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
>
This version works for 3.19.0-rc1.
Zhenhua
On 12/22/2014 05:15 PM, 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 kdump kernel will boot
Sorry I have no plan yet.
Could you send me your logs on your AMD system?
Thanks
Zhenhua
On 12/10/2014 04:46 PM, Baoquan He wrote:
Hi Joerg, ZhenHua,
This issue happens on AMD iommu too, do you have any plans or
thoughts on that?
Thanks
Baoquan
On 11/17/14 at 02:38pm, Joerg Roedel wrote:
On
ock field,
is there any fix for this WARNING?
Thanks
Zhenhua
--
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/
reason, so I will fix it like fixing the DMAR
faults: Do NOT disable and re-enable the interrupt remapping, try to
use data from old kernel.
Thanks
Zhenhua
On 11/17/2014 09:38 PM, Joerg Roedel wrote:
On Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote:
I am working following your
1st step shows we should NOT disable the iommu when it is already
enabled. But current code does disable-enable. So there is still works
to do.
The original kernel does a disable and re-enable , Bill's patchset
removed the disable operation.
I think step 2 is necessary, because when the d
dma_map command for a
device, we assign a new and empty page-table, thus removing all
mappings from the old kernel for the device.
Please let me know if I get something wrong.
Thanks
Zhenhua
On 11/06/2014 04:06 PM, Li, ZhenHua wrote:
> Thank you very much for your testing and fix. I will also t
On 11/13/2014 09:37 PM, Baoquan He wrote:
On 11/13/14 at 05:06pm, Li, ZhenHua wrote:
Minfei,
Thanks for your testing.
On my system, I got error messages:
[8.019096] usb usb2: New USB device strings: Mfr=3, Product=2,
SerialNumber=1
[8.019617] dmar: DRHD: handling fault status reg 102
addr
fff6a000
[8.019651] DMAR:[fault reason 06] PTE Read access is not set
And this patch can fix this.
The reason you do not get error messages may be there is no ongoing DMA
request on your PCI devices when kdump kernel boots, I am not sure of
this.
Zhenhua
On 11/12/2014 07:28 PM, Minfei
Thank you very much for your testing and fix. I will also test it on my
system.
I will let you know when I get a result.
Regards
Zhenhua
On 11/06/2014 03:51 PM, Takao Indoh wrote:
> (2014/11/06 11:11), Li, ZhenHua wrote:
>> This patch does the same thing as you said in your mail.
>
This patch does the same thing as you said in your mail.
It should work, I have tested on my HP huge system.
On 11/06/2014 09:48 AM, Takao Indoh wrote:
> (2014/11/06 10:35), Li, ZhenHua wrote:
>> Yes, that's it. The function context_set_address_root does not set the
>> ad
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
Thanks
Zhenhua
On 11/06/2014 09:31 AM, Takao Indoh wrote:
> Hi Zhenhua, Baoquan,
>
> (2014/10/22 19:0
Hi Joerg,
While debugging Bill's patches, I found this problem:
When copying iommu data from old kernel to the kdump kernel, the
original function context_set_address_root() may cause kdump kernel
using incorrect address root value.
So I created this patch to fix it.
Zhenhua
On 11/05
Hi Baoquan,
I failed in testing this patchset for 3.18.0-rc1, this upstream
3.18.0-rc1 kernel cannot boot on my system, have not found out the
reason.
Could you please test this patchset on 3.17.0 to see whether it has
these faults?
Thanks
Zhenhua
On 10/22/2014 06:05 PM, Baoquan He wrote
On 10/22/2014 10:47 AM, Bjorn Helgaas wrote:
[+cc Joerg, Eric, Tom, David, iommu list]
On Wed, Oct 15, 2014 at 2:14 AM, Takao Indoh wrote:
(2014/10/14 18:34), Li, ZhenHua wrote:
I tested on the latest stable version 3.17, it works well.
On 10/10/2014 03:13 PM, Li, Zhen-Hua wrote:
On a HP
Need more time to read and think about these mails. I just want to
clarify one thing: Bill has left HP, and now I inherited his works.
That's why I sent an update of his patch
https://lkml.org/lkml/2014/10/21/134
On 10/22/2014 10:47 AM, Eric W. Biederman wrote:
Bjorn Helgaas writes:
On 10/22/2014 10:47 AM, Bjorn Helgaas wrote:
[+cc Joerg, Eric, Tom, David, iommu list]
On Wed, Oct 15, 2014 at 2:14 AM, Takao Indoh wrote:
(2014/10/14 18:34), Li, ZhenHua wrote:
I tested on the latest stable version 3.17, it works well.
On 10/10/2014 03:13 PM, Li, Zhen-Hua wrote:
On a HP
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.
Thanks
Zhenhua
On 10/15/2014 04:14 PM, Takao Indoh wrote:
> (2014/10/14 18:34), Li, Zhen
On 10/20/2014 09:46 AM, Li, ZhenHua wrote:
On 10/20/2014 07:20 AM, Gavin Shan wrote:
On Fri, Oct 17, 2014 at 02:44:43AM -0700, Eric W. Biederman wrote:
"Li, Zhen-Hua" writes:
This is an update of the patch
https://lkml.org/lkml/2014/10/10/37
This patch is doing the reset wo
y
as to make it easy or straight forward to do this my sympathies you are
going to have do fix that linux port to be able to do things during
boot.
But things called from crash_kexec should be absolute necessities and I
do not see this as coming anywhere close to being something that is
impossibl
ute necessities and I
do not see this as coming anywhere close to being something that is
impossible to do in the target kernel.
Eric
So now do the resetting during the kdump kernel boots is the only
choice. I will try to figure out how to fix this.
Thank you very much.
Zhenhua
On a Linux
Add Tom to CC list.
On 10/15/2014 04:10 PM, Li, ZhenHua wrote:
David, Joerg,
I plan to merge this patch set with 3.17 stable kernel, and split this
patch set into two :
1. The core part, including the changed functions, like [Patch 4/8],
[Patch 8/8].
2. For the formatting issues, like [Patch 1/8
rsion for latest stable kernel 3.17.
Thanks
Zhenhua
On 10/15/2014 04:14 PM, Takao Indoh wrote:
> (2014/10/14 18:34), Li, ZhenHua wrote:
>> I tested on the latest stable version 3.17, it works well.
>>
>> On 10/10/2014 03:13 PM, Li, Zhen-Hua wrote:
>>> On a HP system
, creation of new files
intel-iommu-kdump.c, intel-iommu-private.h.
I believe this will make the patch set more clear to read and understand.
What are your suggestions?
Thanks
Zhenhua
On 07/12/2014 12:27 AM, Jerry Hoemann wrote:
On Wed, Jul 02, 2014 at 03:32:59PM +0200, Joerg Roedel wrote:
Hi
I tested on the latest stable version 3.17, it works well.
On 10/10/2014 03:13 PM, Li, Zhen-Hua wrote:
On a HP system with Intel vt-d supported and many PCI devices on it,
when kernel crashed and the kdump kernel boots with intel_iommu=on,
there may be some unexpected DMA requests on this adapte
well, then I will create a patch for ALL pcie devices.
On 10/03/2014 10:28 PM, Alexander Duyck wrote:
On 10/02/2014 08:09 AM, Bjorn Helgaas wrote:
On Tue, Sep 30, 2014 at 12:15 AM, Li, ZhenHua wrote:
Add Joerg to CC list. For it is also related to iommu module.
Joerg,
There was a try for
Add Joerg to CC list. For it is also related to iommu module.
Joerg,
There was a try for this dmar fault,
https://lkml.org/lkml/2014/8/18/118
This patch is trying to fix the same thing.
Zhenhua
On 09/30/2014 02:09 PM, Li, Zhen-Hua wrote:
On a HP system with Intel Corporation 82599
cause the errors
disappear.
-- Zhenhua
On 08/19/2014 07:02 PM, Joerg Roedel wrote:
On Mon, Aug 18, 2014 at 11:27:01PM +, Li, Zhen-Hua wrote:
: [fault reason 01] Present bit in root entry is clear
It appears when iommu initializing in the kdump kernel.
Hmm, do you have an explanation how
I found there are more data need to be cleared for the dump kernel.
So please ignore this patch, I will send out another one.
Thanks
Zhenhua
On 08/19/2014 07:59 AM, Li, Zhen-Hua wrote:
My debugging result is this:
1. Clear the old root entry table, dump kernel will choose another
memory
Hi Jiri,
You are right, I tested the latest kernel, did not see this bug.
So I will only submit this patch to Redhat.
Thanks
Zhenhua
On 07/15/2014 05:16 PM, Jiri Slaby wrote:
Hi,
On 07/15/2014 11:08 AM, Li, ZhenHua wrote:
This bug was founded in RHEL 6, kernel version 2.6.32.
But I also
ded by tty_lock(tty).
So I think the new lock is necessary.
Thanks
Zhenhua
On 07/14/2014 08:25 PM, Peter Hurley wrote:
Hi Zhen-Hua,
On 07/14/2014 01:54 AM, Li, Zhen-Hua wrote:
When there are to many open/close on a tty device in the same time,
there may be a warning like:
Warning: dev (ttyS
Heinrich,
Thank you very much for reviewing. But seems the maintainer will not
accept it.
Zhenhua
On 07/15/2014 12:30 AM, Heinrich Schuchardt wrote:
On 01.07.2014 01:10, Li, Zhen-Hua wrote:
When malloc for jump,
if (head && location) {
jump = xmalloc(sizeof(struct
Any update?
On 07/01/2014 01:02 AM, Heinrich Schuchardt wrote:
On 30.06.2014 05:16, Li, Zhen-Hua wrote:
There is a warning when run "make menuconfig".
scripts/kconfig/menu.c: In function ‘get_symbol_str’:
scripts/kconfig/menu.c:591:18: warning: ‘jump’ may be used
uninitialized in
this functi
The comment is trying to explain why add a lock here.
On 04/19/2014 03:01 AM, Sergei Shtylyov wrote:
Hello.
On 04/16/2014 11:08 AM, Li, Zhen-Hua wrote:
From: "Li, Zhen-Hua"
As netif_running is called in netif_device_attach/detach. There
should be
rtnl_lock/unlock called, to avoid dev stat
each net device?
Regards
Zhenhua
On 04/16/2014 03:38 PM, Veaceslav Falico wrote:
On Wed, Apr 16, 2014 at 03:08:02PM +0800, Li, Zhen-Hua wrote:
From: "Li, Zhen-Hua"
As netif_running is called in netif_device_attach/detach. There should be
rtnl_lock/unlock called, to avoid dev sta
Hi David,
I have sent out another patch for the fix.
Thanks
ZhenHua
On 04/16/2014 02:30 PM, Li, ZhenHua wrote:
Hi David,
I think you are right. I checked other NIC drivers, found some of them
call rtnl_lock and rtnl_unlock around netif_device_detach and attach
functions, while some drivers did
Hi David,
I think you are right. I checked other NIC drivers, found some of them
call rtnl_lock and rtnl_unlock around netif_device_detach and attach
functions, while some drivers did not.
I will create a new patch in generic way to fix this.
Regards
ZhenHua
On 04/16/2014 03:09 AM, David
Because netif_running() is called in netif_device_detach and
netif_device_attach. To avoid dev status changed while
netif_device_detach/attach is not finished, I think a rtnl_lock and
unlock should be called to avoid this.
Thanks
Zhenhua
On 04/15/2014 04:07 PM, Sathya Perla wrote
Thanks for your correction. I will send again with proper reason.
On 04/15/2014 01:31 AM, David Miller wrote:
From: "Li, Zhen-Hua"
Date: Mon, 14 Apr 2014 18:08:36 +0800
For the cosa module, CONFIG_COSA can only be checked as 'm',
and cosa module can only be compiled as a module.
That's not t
This patch is sent again because a ';' was missed in my last mail.
> + context->asr = value >> VTD_PAGE_SHIFT
I corrected it and created a new one. And it is tested .
Please use the latest one.
Sorry for that.
ZhenHua
On 01/10/2014 04:27 PM, Li, Zhen-Hua wrote:
Ther
I have not seen such a bug yet . but obviously a '=' should be used when
you want to set a value.
for example, if x != 0,
x=10
and
x|=10
will cause different result.
ZhenHua
On 01/07/2014 10:41 PM, Joerg Roedel wrote:
On Fri, Dec 20, 2013 at 04:45:01PM +0800, Li
Yes, that's the problem. And some other structures like this, see "union
irte".
On 12/26/2013 01:12 PM, Wu, Feng wrote:
I think if using |= operation, it should use &= operation to clear those
bits first.
Thanks,
Feng
*From:*iommu-boun...@lists.linux-foundation.org
[mailto:iommu-boun...@list
Hi,
I found it was incorrect. So please IGNORE this patch.
Sorry for that.
On 12/09/2013 11:20 AM, Li, Zhen-Hua wrote:
In function tty_release, there are two unlock not called while
breaking from a while. This may cause problems.
This patch fixed this problem , adding the two unlocks before
br
Hi Guys,
Though DMAR_ICS_REG is not used yet, I think this patch is
necessary. So please take a look at it.
Thanks
ZhenHua
On 09/13/2013 02:27 PM, Li, Zhen-Hua wrote:
According to Intel Vt-D specs, the offset of Invalidation complete
status register should be 0x9C, not 0x98.
See
Hi Bjorn,
Thanks for your suggestions. I will try to find more information.
ZhenHua
On 07/11/2013 12:12 AM, Bjorn Helgaas wrote:
On Wed, Jul 10, 2013 at 12:23 AM, ZhenHua wrote:
Hi Bjorn,
On the system that this bug happens, an MCA event is generated while kernel
crashed
+ EgressCtrl- DirectTrans-
ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir-
UpstreamFwd- EgressCtrl- DirectTrans-
Capabilities: [160] Vendor Specific Information
Kernel driver in use: pcieport
Kernel modules: shpchp
Thanks
ZhenHua
On 07/10/2013 12:49 AM, Bjorn Helgaas wr
Hi Bjorn,
I tested on an X86 system with the same chipset, and this bug does not
happen.
I am not sure why , but if it is needed, I will try to find out why.
Thanks
ZhenHua
On 07/09/2013 01:42 PM, Li, Zhen-Hua wrote:
On some IA64 platforms with intel PCI bridge, for example, HP BL890c i2
Hi Bjorn,
Thank you for reviewing this patch. I have created a new one and sent it
out.
And your questions are answered in that new wmail.
Regards
ZhenHua
On 07/09/2013 04:35 AM, Bjorn Helgaas wrote:
On Sun, Jul 7, 2013 at 6:16 PM, Li, Zhen-Hua wrote:
On some IA64 platforms with intel PCI
On 06/28/2013 10:22 PM, Alan Stern wrote:
On Fri, 28 Jun 2013, Li, Zhen-Hua (USL-China) wrote:
There was a problem, the warning "Controller not stopped yet".
And your last patch for this problem does a wrong thing:
It prevents all HP uhci devices from auto-stop, which make HP uhci
devices waste
1 - 100 of 112 matches
Mail list logo
