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
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
+ 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,
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
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 guys,
I think this patch is necessary. Please take a look at it.
Thanks
Zhen-Hua
On 05/24/2013 08:35 AM, Li, Zhen-Hua wrote:
In Intel Vt-D specs, Chapter 9.3 Page-Table Entry,
The size of ADDR(address) field is 12:51, but the function dma_pte_addr
treats it as 12:63.
Signed-off-by: Li
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
On 04/23/2013 10:07 PM, Greg KH wrote:
On Tue, Apr 23, 2013 at 03:15:01PM +0800, Li, Zhen-Hua wrote:
From: "Li, Zhen-Hua"
This patch is trying to fix bug QXCR1001261767.
Sorry for the bug number. Please ignore this line.
What is that bug number? Where can it be referenced? If you are goin
!
Thanks
Zhen-Hua
On 04/24/2013 09:57 AM, Greg KH wrote:
On Wed, Apr 24, 2013 at 07:55:18AM +0800, ZhenHua wrote:
On 04/23/2013 10:07 PM, Greg KH wrote:
On Tue, Apr 23, 2013 at 03:15:01PM +0800, Li, Zhen-Hua wrote:
From: "Li, Zhen-Hua"
This patch is trying to fix bug QXCR1001261767.
On 04/23/2013 11:10 PM, Alan Stern wrote:
On Tue, 23 Apr 2013, Greg KH wrote:
On Tue, Apr 23, 2013 at 03:15:01PM +0800, Li, Zhen-Hua wrote:
From: "Li, Zhen-Hua"
This patch is trying to fix bug QXCR1001261767.
What is that bug number? Where can it be referenced? If you are going
to put it
I send out this patch for the second time.
Changed try to int. And modified the comment.
On 04/25/2013 03:11 PM, Li, Zhen-Hua wrote:
This patch is trying to fix this bug on SLES11 SP2:
https://bugzilla.novell.com/show_bug.cgi?id=817035
On a large HP system with 64T memory and 60 logical cp
On 04/25/2013 10:54 PM, Alan Stern wrote:
On Thu, 25 Apr 2013, ZhenHua wrote:
+#define UHCI_SUSPENDRH_RETRY_MAX 10
+#define UHCI_SUSPENDRH_RETRY_DELAY100
Why is the delay set to 100 us? Isn't that excessively large? How
long does it take for this controller to go into su
There is a function wait_for_HP() in uhci-hub.c. In this
patch, it is used in suspend_rh(), I think this can be a
solution. And I have tested this patch, it can fix the bug.
I think there is another patch needed. As Alan said in another
mail, in the UHCI_RH_RUNNING_NODEVS case, it should not be
On 04/26/2013 03:50 PM, ZhenHua wrote:
I think there is another patch needed. As Alan said in another
mail, in the UHCI_RH_RUNNING_NODEVS case, it should not be stopped
if the uhci device is HP iLo virtual usb.
correct: it should not be auto stopped if the uhci device is HP iLo
virtual usb
On 04/27/2013 12:51 AM, Alan Stern wrote:
On Fri, 26 Apr 2013, ZhenHua wrote:
There is a function wait_for_HP() in uhci-hub.c. In this
patch, it is used in suspend_rh(), I think this can be a
solution. And I have tested this patch, it can fix the bug.
I think there is another patch needed
On 04/27/2013 11:14 PM, Alan Stern wrote:
On Sat, 27 Apr 2013, ZhenHua wrote:
On 04/27/2013 12:51 AM, Alan Stern wrote:
On Fri, 26 Apr 2013, ZhenHua wrote:
There is a function wait_for_HP() in uhci-hub.c. In this
patch, it is used in suspend_rh(), I think this can be a
solution. And I
Use lo and hi for clear, may run faster than memset.
But it is not a big problem. Never mind.
Thanks
ZhenHua
On 05/24/2013 08:36 AM, Joe Perches wrote:
On Fri, 2013-05-24 at 08:22 +0800, Li, Zhen-Hua wrote:
There is a structure named context_entry used by intel iommu, and there
are some bit
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
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
/powerpc/configs/corenet64_smp_defconfig
arch/powerpc/configs/mpc85xx_smp_defconfig
Signed-off-by: Zhenhua Luo
---
arch/powerpc/configs/85xx/p1023rds_defconfig |1 +
arch/powerpc/configs/corenet32_smp_defconfig |1 +
arch/powerpc/configs/corenet64_smp_defconfig |1 +
arch/powerpc
("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
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
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
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/
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
>
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
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
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
.
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
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
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
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
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
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
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
-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&
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:
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) { }
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
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
.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/
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
, 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/
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
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
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
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
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 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
> > >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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.
>
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
, 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
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
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
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
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
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
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
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
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
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
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
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
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
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
= 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
.
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
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
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
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 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
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
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
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
+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
1 - 100 of 112 matches
Mail list logo
