On 12/12/14 at 10:25am, Li, ZhenHua wrote:
> Sorry I have no plan yet.
> Could you send me your logs on your AMD system?
Sure, please check the attachment. AMD iommu seems a little different on
action. On the machine I reserved for testing, it always hang the system
bootup. As Joerg said, we can
On 12/12/14 at 05:11pm, Joerg Roedel wrote:
> On Fri, Dec 12, 2014 at 10:25:31AM +0800, Li, ZhenHua wrote:
> > Sorry I have no plan yet.
> > Could you send me your logs on your AMD system?
>
> > On 12/10/2014 04:46 PM, Baoquan He wrote:
> > >This issue happens on AMD iommu too, do you have any
On 12/12/14 at 05:11pm, Joerg Roedel wrote:
On Fri, Dec 12, 2014 at 10:25:31AM +0800, Li, ZhenHua wrote:
Sorry I have no plan yet.
Could you send me your logs on your AMD system?
On 12/10/2014 04:46 PM, Baoquan He wrote:
This issue happens on AMD iommu too, do you have any plans or
On 12/12/14 at 10:25am, Li, ZhenHua wrote:
Sorry I have no plan yet.
Could you send me your logs on your AMD system?
Sure, please check the attachment. AMD iommu seems a little different on
action. On the machine I reserved for testing, it always hang the system
bootup. As Joerg said, we can
On Fri, Dec 12, 2014 at 10:25:31AM +0800, Li, ZhenHua wrote:
> Sorry I have no plan yet.
> Could you send me your logs on your AMD system?
> On 12/10/2014 04:46 PM, Baoquan He wrote:
> >This issue happens on AMD iommu too, do you have any plans or
> >thoughts on that?
I think the best approach
On Fri, Dec 12, 2014 at 10:25:31AM +0800, Li, ZhenHua wrote:
Sorry I have no plan yet.
Could you send me your logs on your AMD system?
On 12/10/2014 04:46 PM, Baoquan He wrote:
This issue happens on AMD iommu too, do you have any plans or
thoughts on that?
I think the best approach for now
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
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
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 Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote:
> > I am working following your directions:
> >
> > 1. If the VT-d
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 Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote:
I am working following your directions:
1. If the VT-d driver
On Mon, Dec 01, 2014 at 02:31:38PM +0800, Li, ZhenHua wrote:
> After I implement these two steps, there comes a new fault:
>
> [1.594890] dmar: DRHD: handling fault status reg 2
> [1.594894] dmar: INTR-REMAP: Request device [[41:00.0] fault index 4d
> [1.594894] INTR-REMAP:[fault reason 34]
On Mon, Dec 01, 2014 at 02:31:38PM +0800, Li, ZhenHua wrote:
After I implement these two steps, there comes a new fault:
[1.594890] dmar: DRHD: handling fault status reg 2
[1.594894] dmar: INTR-REMAP: Request device [[41:00.0] fault index 4d
[1.594894] INTR-REMAP:[fault reason 34] Present
Joerg,
After I implement these two steps, there comes a new fault:
[1.594890] dmar: DRHD: handling fault status reg 2
[1.594894] dmar: INTR-REMAP: Request device [[41:00.0] fault index 4d
[1.594894] INTR-REMAP:[fault reason 34] Present field in the IRTE entry
is clear
It is caused by similar
Joerg,
After I implement these two steps, there comes a new fault:
[1.594890] dmar: DRHD: handling fault status reg 2
[1.594894] dmar: INTR-REMAP: Request device [[41:00.0] fault index 4d
[1.594894] INTR-REMAP:[fault reason 34] Present field in the IRTE entry
is clear
It is caused by similar
On Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote:
> I am working following your directions:
>
> 1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry
> table, and do NOT disable-enable iommu. Other data will be copied.
>
> 2. When a device driver issues the first
On Fri, Nov 14, 2014 at 02:27:44PM +0800, Li, ZhenHua wrote:
I am working following your directions:
1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry
table, and do NOT disable-enable iommu. Other data will be copied.
2. When a device driver issues the first dma_map
Hi Takao Indoh,
Your update for the patchset works fine. Thanks.
Joerg,
I am working following your directions:
1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry
table, and do NOT disable-enable iommu. Other data will be copied.
2. When a device driver issues the first
Hi Takao Indoh,
Your update for the patchset works fine. Thanks.
Joerg,
I am working following your directions:
1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry
table, and do NOT disable-enable iommu. Other data will be copied.
2. When a device driver issues the first
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.
>> It should
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.
It should work, I
(2014/11/06 11:11), Li, ZhenHua wrote:
> This patch does the same thing as you said in your mail.
> It should work, I have tested on my HP huge system.
Yep, I also confirmed it worked.
BTW, I found another problem. When I tested your patches with 3.17
kernel, iommu initialization failed with the
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
>> address root correctly.
>>
(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
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 still some dmar
> errors. I remember it worked well with Bill's original patchset.
This should be a problem in copy_context_entry().
> +static int
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:05), Baoquan He
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:05), Baoquan He
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 still some dmar
errors. I remember it worked well with Bill's original patchset.
This should be a problem in copy_context_entry().
+static int
(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
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
address root correctly.
I have
(2014/11/06 11:11), Li, ZhenHua wrote:
This patch does the same thing as you said in your mail.
It should work, I have tested on my HP huge system.
Yep, I also confirmed it worked.
BTW, I found another problem. When I tested your patches with 3.17
kernel, iommu initialization failed with the
On 10/27/14 at 03:29pm, Li, ZhenHua wrote:
> 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?
>
>
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:
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/27/14 at 03:29pm, Li, ZhenHua wrote:
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
On 10/22/14 at 10:22am, Li, Zhen-Hua wrote:
>
> Hi Baoquan,
> I tested it on 3.17, it does not have these faults. There are little
> differences between this version and Bill's last version.
>
> I will test it on 3.18.0-rc1+ on my system and let you know the result.
>
> And could you send me
Hi Baoquan,
I tested it on 3.17, it does not have these faults. There are little
differences between this version and Bill's last version.
I will test it on 3.18.0-rc1+ on my system and let you know the result.
And could you send me the result of "lspci -vvv " on your system?
Thanks
Zhenhua
Hi Zhenhua,
I tested your latest patch on 3.18.0-rc1+, there are still some dmar
errors. I remember it worked well with Bill's original patchset.
0console [earlya[0.00] allocate tes of page_cg 'a ong[
0.00] tsc: Fast TSC calibration using PIT
0031] Calibrating delay loop (skipped),
Hi Zhenhua,
I tested your latest patch on 3.18.0-rc1+, there are still some dmar
errors. I remember it worked well with Bill's original patchset.
0console [earlya[0.00] allocate tes of page_cg 'a ong[
0.00] tsc: Fast TSC calibration using PIT
0031] Calibrating delay loop (skipped),
Hi Baoquan,
I tested it on 3.17, it does not have these faults. There are little
differences between this version and Bill's last version.
I will test it on 3.18.0-rc1+ on my system and let you know the result.
And could you send me the result of lspci -vvv on your system?
Thanks
Zhenhua
在
On 10/22/14 at 10:22am, Li, Zhen-Hua wrote:
Hi Baoquan,
I tested it on 3.17, it does not have these faults. There are little
differences between this version and Bill's last version.
I will test it on 3.18.0-rc1+ on my system and let you know the result.
And could you send me the
The following series implements a fix for:
A kdump problem about DMA that has been discussed for a long time.
That is, when a kernel panics and boots into the kdump kernel, DMA that was
started by the panicked kernel is not stopped before the kdump kernel is booted;
and the kdump kernel disables
The following series implements a fix for:
A kdump problem about DMA that has been discussed for a long time.
That is, when a kernel panics and boots into the kdump kernel, DMA that was
started by the panicked kernel is not stopped before the kdump kernel is booted;
and the kdump kernel disables
42 matches
Mail list logo
