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 j
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 pla
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 fo
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 drive
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] Presen
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 re
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 dm
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 d
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 wor
(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 Indoh
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 copy_context_entry
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
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?
>
> Tha
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
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 th
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),
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 th
21 matches
Mail list logo
