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
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,
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
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
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 get
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,
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 that's
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
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
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 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]
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
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 guarantee that any crazy
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.
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
region just
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 writing oldmem
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 kdump
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:
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'm wrong,
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: handling
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
23 matches
Mail list logo
