On Fri, 2015-04-10 at 16:42 +0800, 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 with these faults:
But, in the gene
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, Bao
Hi Baoquan, ZhenHua,
On Mon, May 04, 2015 at 11:17:49AM +0800, Baoquan He wrote:
> On 05/04/15 at 11:06am, Li, ZhenHua wrote:
> > Hi baoquan,
> > Could you paste the kernel log of the first kernel ?
Please let me know when you have worked this issue out.
Thanks,
Joerg
--
To unsubscrib
On Wed, May 06, 2015 at 09:51:35AM +0800, Dave Young wrote:
> DMA write will modify system ram, if the old data is corrupted it is possible
> that DMA operation modify wrong ram regions because of wrong mapping.
> Am I missing something and is it not possible?
This might have happened already bef
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, Ma
On 05/05/15 at 05:31pm, Joerg Roedel wrote:
> On Tue, May 05, 2015 at 02:14:23PM +0800, Dave Young wrote:
> > The failure is nothing different, but as I said in another reply the
> > difference is we could use corrupted data to possiblly cause more failure.
>
> I still fail to see how things can g
On Tue, May 05, 2015 at 02:14:23PM +0800, Dave Young wrote:
> The failure is nothing different, but as I said in another reply the
> difference is we could use corrupted data to possiblly cause more failure.
I still fail to see how things can get more worse than they already are
by reusing the old
On 05/04/15 at 06:23pm, Joerg Roedel wrote:
> On Fri, Apr 24, 2015 at 04:49:57PM +0800, Dave Young wrote:
> > I'm more than happy to see this issue can be fixed in the patchset, I
> > do not agree to add the code there with such problems. OTOH, for now
> > seems there's no way to fix it.
>
> And t
On Fri, Apr 24, 2015 at 04:49:57PM +0800, Dave Young wrote:
> I'm more than happy to see this issue can be fixed in the patchset, I
> do not agree to add the code there with such problems. OTOH, for now
> seems there's no way to fix it.
And that's the point. We discuss this issue and possible solu
On 05/04/15 at 11:06am, Li, ZhenHua wrote:
> Hi baoquan,
> Could you paste the kernel log of the first kernel ?
Please check the attachment.
[0.00] microcode: CPU0 microcode updated early to revision 0x710, date
= 2013-06-17
[0.00] Initializing cgroup subsys cpuset
[0.00]
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
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 kdump log are attached, please check:
I found the lspci log previously attached is emtyp, resend it again.
00:00.0
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 kdump log are attached, please check:
[ ~]$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.0.0+ root=/dev/mapper/fedora_dhcp--128--28-root ro
rd.lvm.lv=fedora_dhcp-128-28/sw
Hi Baoquan,
If old tables are corrupted, we will see the DMAR faults or INTR faults
(which we have seen), or some other error messages. Most of these
messages are from hardware. This means, hardware will do some check when
running. But I don't think hardware will completely check the
tables.
T
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 patchset.
> > > >
> > > > We should not fear oldmem since reserved crashkernel region is similar.
> > > > No one can g
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 patchset.
> > >
> > > We should not fear oldmem since reserved crashkernel region is similar.
> > > No one can guarantee that any crazy code won't step into crashkernel
>
On 04/24/15 at 04:25pm, Dave Young wrote:
> Hi, Baoquan
>
> > I support this patchset.
> >
> > We should not fear oldmem since reserved crashkernel region is similar.
> > No one can guarantee that any crazy code won't step into crashkernel
> > region just because 1st kernel says it's reversed for
Hi, Baoquan
> I support this patchset.
>
> We should not fear oldmem since reserved crashkernel region is similar.
> No one can guarantee that any crazy code won't step into crashkernel
> region just because 1st kernel says it's reversed for kdump kernel. Here
> the root table and context tables
On 04/15/15 at 02:48pm, 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 think it is bad to use old page table, below issues need consider:
> > >1) make sure old page table are reliable across crash
> > >2) do not allow writi
Hi,
On 04/21/15 at 09:39am, Li, ZhenHua wrote:
> Hi Dave,
> I found the old mail:
> http://lkml.iu.edu/hypermail/linux/kernel/1410.2/03584.html
I know and I have read it before.
== quote ===
> > > So with this in mind I would prefer initially taking over the
> >
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,
On 04/15/15 at 01:47pm, Li, ZhenHua wrote:
> On 04/15/2015 08:57 AM, Dave Young wrote:
> >Again, I think it is bad to use old page table, below issues need consider:
> >1) make sure old page table are reliable across crash
> >2) do not allow writing oldmem after crash
> >
> >Please correct me if I'
On 04/15/2015 08:57 AM, Dave Young wrote:
Again, I think it is bad to use old page table, below issues need consider:
1) make sure old page table are reliable across crash
2) do not allow writing oldmem after crash
Please correct me if I'm wrong, or if above is not doable I think I will vote
fo
On 04/10/15 at 04:42pm, 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 with these faults:
>
> dmar: DRHD: handlin
24 matches
Mail list logo
