On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
> Modify the operation of the following functions when called during crash dump:
> iommu_context_addr
> free_context_table
> get_domain_for_dev
> init_dmars
> intel_iommu_init
>
> Bill Sumner:
> Original version.
>
> Zhenhua:
>
The patch subject is bad, previous patch you use "Items for kdump", this
patch you use "datatypes and functions used for kdump" then what's the
difference between these two patches?
Please think about a better one for these patches..
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
> Populate it with
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_iommu, to store the RTA in old kernel,
On 05/11/15 at 05:52pm, 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 calling iounmap between spin_lock_irqsave and spin_unlock_irqrestore,
> use a link here, store the pointers , and then
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
> Add context entry functions needed for kdump.
>
> Bill Sumner:
> Original version;
>
> Li, Zhenhua:
> Changed the name of new functions, make them consistent with current
> context get/set functions.
> Remove the structure dve which
On 05/12/15 at 01:57pm, Dave Young wrote:
> On 05/11/15 at 12:11pm, Joerg Roedel wrote:
> > On Thu, May 07, 2015 at 09:56:00PM +0800, Dave Young wrote:
> > > Joreg, I can not find the last reply from you, so just reply here about
> > > my worries here.
> >
On 05/12/15 at 01:57pm, Dave Young wrote:
On 05/11/15 at 12:11pm, Joerg Roedel wrote:
On Thu, May 07, 2015 at 09:56:00PM +0800, Dave Young wrote:
Joreg, I can not find the last reply from you, so just reply here about
my worries here.
I said that the patchset will cause more
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_iommu, to store the RTA in old kernel, and
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Add context entry functions needed for kdump.
Bill Sumner:
Original version;
Li, Zhenhua:
Changed the name of new functions, make them consistent with current
context get/set functions.
Remove the structure dve which is not
On 05/11/15 at 05:52pm, 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 calling iounmap between spin_lock_irqsave and spin_unlock_irqrestore,
use a link here, store the pointers , and then use
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Modify the operation of the following functions when called during crash dump:
iommu_context_addr
free_context_table
get_domain_for_dev
init_dmars
intel_iommu_init
Bill Sumner:
Original version.
Zhenhua:
The name
On 05/11/15 at 05:52pm, 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
The patch subject is bad, previous patch you use Items for kdump, this
patch you use datatypes and functions used for kdump then what's the
difference between these two patches?
Please think about a better one for these patches..
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Populate it with
On 05/11/15 at 05:52pm, Li, Zhen-Hua wrote:
Functions to copy the irte data from the old kernel into the kdump kernel.
Use above line as subject is better, if irte means interrupt remappin table
entry then descripbe it then I like the long format in subject line.
Also it need a better patch
On 05/11/15 at 12:11pm, Joerg Roedel wrote:
> On Thu, May 07, 2015 at 09:56:00PM +0800, Dave Young wrote:
> > Joreg, I can not find the last reply from you, so just reply here about
> > my worries here.
> >
> > I said that the patchset will cause more problems, let m
the system starts on uefi.
> >
> >This sounds very painful. Why is this the case, and how do x86 and/or
> >ia64 get around that?
>
> As Dave (Young) said, x86 uses "memmap=XX" kernel commandline parameters
> to specify usable memory for crash dump kernel.
Originally x86
On 05/11/15 at 04:58pm, AKASHI Takahiro wrote:
> Dave,
>
> On 05/11/2015 04:47 PM, Dave Young wrote:
> >On 05/08/15 at 08:19pm, Dave Young wrote:
> >>Hi,
> >>
> >>On 04/24/15 at 04:53pm, AKASHI Takahiro wrote:
> >>>Please read the following c
On 05/08/15 at 08:19pm, Dave Young wrote:
> Hi,
>
> On 04/24/15 at 04:53pm, AKASHI Takahiro wrote:
> > Please read the following commits for arm64-specific constraints:
> > arm64: kdump: reserve memory for crash dump kernel
> > arm64: kdump: do not go into EL2 b
On 05/08/15 at 08:19pm, Dave Young wrote:
Hi,
On 04/24/15 at 04:53pm, AKASHI Takahiro wrote:
Please read the following commits for arm64-specific constraints:
arm64: kdump: reserve memory for crash dump kernel
arm64: kdump: do not go into EL2 before starting a crash dump kernel
On 05/11/15 at 04:58pm, AKASHI Takahiro wrote:
Dave,
On 05/11/2015 04:47 PM, Dave Young wrote:
On 05/08/15 at 08:19pm, Dave Young wrote:
Hi,
On 04/24/15 at 04:53pm, AKASHI Takahiro wrote:
Please read the following commits for arm64-specific constraints:
arm64: kdump: reserve memory
On 05/11/15 at 12:11pm, Joerg Roedel wrote:
On Thu, May 07, 2015 at 09:56:00PM +0800, Dave Young wrote:
Joreg, I can not find the last reply from you, so just reply here about
my worries here.
I said that the patchset will cause more problems, let me explain about
it more here
of
Geoff's kexec patchset.
In this version, there are some arm64-specific usage/constraints:
1) mem= boot parameter must be specified on crash dump kernel
if the system starts on uefi.
This sounds very painful. Why is this the case, and how do x86 and/or
ia64 get around that?
As Dave
Hi,
On 04/24/15 at 04:53pm, AKASHI Takahiro wrote:
> Please read the following commits for arm64-specific constraints:
> arm64: kdump: reserve memory for crash dump kernel
> arm64: kdump: do not go into EL2 before starting a crash dump kernel
>
> Signed-off-by: AKASHI Takahiro
> ---
>
Hi,
On 04/24/15 at 04:53pm, AKASHI Takahiro wrote:
Please read the following commits for arm64-specific constraints:
arm64: kdump: reserve memory for crash dump kernel
arm64: kdump: do not go into EL2 before starting a crash dump kernel
Signed-off-by: AKASHI Takahiro
On 05/07/15 at 10:25am, Don Dutile wrote:
> On 05/07/2015 10:00 AM, Dave Young wrote:
> >On 04/07/15 at 10:12am, Don Dutile wrote:
> >>On 04/06/2015 11:46 PM, Dave Young wrote:
> >>>On 04/05/15 at 09:54am, Baoquan He wrote:
> >>>>On 04/03/15 at 05:21p
On 04/07/15 at 10:12am, Don Dutile wrote:
> On 04/06/2015 11:46 PM, 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,
> >>
On 05/04/15 at 01:05pm, Joerg Roedel wrote:
> On Fri, Apr 03, 2015 at 04:40:31PM +0800, Dave Young wrote:
> > Have not read all the patches, but I have a question, not sure this
> > has been answered before. Old memory is not reliable, what if the old
> > memory get c
On 05/06/15 at 10:16am, Joerg Roedel wrote:
> On Wed, May 06, 2015 at 09:46:49AM +0800, Dave Young wrote:
> > For the original problem, the key issue is dmar faults cause kdump kernel
> > hang so that vmcore can not be saved. I do not know the reason why it hangs
> > I t
On 05/07/15 at 10:25am, Don Dutile wrote:
On 05/07/2015 10:00 AM, Dave Young wrote:
On 04/07/15 at 10:12am, Don Dutile wrote:
On 04/06/2015 11:46 PM, 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
On 05/06/15 at 10:16am, Joerg Roedel wrote:
On Wed, May 06, 2015 at 09:46:49AM +0800, Dave Young wrote:
For the original problem, the key issue is dmar faults cause kdump kernel
hang so that vmcore can not be saved. I do not know the reason why it hangs
I think it is acceptable if kdump
On 04/07/15 at 10:12am, Don Dutile wrote:
On 04/06/2015 11:46 PM, 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
On 05/04/15 at 01:05pm, Joerg Roedel wrote:
On Fri, Apr 03, 2015 at 04:40:31PM +0800, Dave Young wrote:
Have not read all the patches, but I have a question, not sure this
has been answered before. Old memory is not reliable, what if the old
memory get corrupted before panic? Is it safe
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
On 05/05/15 at 05:23pm, Joerg Roedel wrote:
> On Tue, May 05, 2015 at 02:09:31PM +0800, Dave Young wrote:
> > I agree that we can do nothing with the old corrupted data, but I worry
> > about the future corruption after using the old corrupted data. I wonder
> > if we ca
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
On 05/04/15 at 01:05pm, Joerg Roedel wrote:
> On Fri, Apr 03, 2015 at 04:40:31PM +0800, Dave Young wrote:
> > Have not read all the patches, but I have a question, not sure this
> > has been answered before. Old memory is not reliable, what if the old
> > memory get c
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
On 05/05/15 at 05:23pm, Joerg Roedel wrote:
On Tue, May 05, 2015 at 02:09:31PM +0800, Dave Young wrote:
I agree that we can do nothing with the old corrupted data, but I worry
about the future corruption after using the old corrupted data. I wonder
if we can mark all the oldmem as readonly
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 05/04/15 at 01:05pm, Joerg Roedel wrote:
On Fri, Apr 03, 2015 at 04:40:31PM +0800, Dave Young wrote:
Have not read all the patches, but I have a question, not sure this
has been answered before. Old memory is not reliable, what if the old
memory get corrupted before panic? Is it safe
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 guaran
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/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
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 are
ill 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 think it is bad to use old page table, below issues need
to avoid the problem.
But IMHO we should avoid it or we will have problems in the future, if we
really cannot avoid it I would say switching to pci reset way is better.
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
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
>
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:
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/07/15 at 05:55pm, Li, ZhenHua wrote:
> 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
On 04/08/15 at 10:41am, Xishi Qiu wrote:
> On 2015/4/8 10:18, Baoquan He wrote:
>
> > On 04/08/15 at 09:59am, Xishi Qiu wrote:
> >> On 2015/4/8 9:46, Dave Young wrote:
> >>
> >>>>>
> >>>>> - /* Mark all kernel nod
> >
> > - /* Mark all kernel nodes. */
> > + /*
> > +* Mark all kernel nodes.
> > +*
> > +* In case booting with mem=nn[kMG] or in kdump kernel, numa_meminfo
>
> Hi Dave,
>
> It should both set mem=xx and numa=off, then numa_meminfo may not include all
> the memblock.reserved
Commit-ID: 22ef882e6b5bd2bf668d10b1e2be3dc2fc365b99
Gitweb: http://git.kernel.org/tip/22ef882e6b5bd2bf668d10b1e2be3dc2fc365b99
Author: Dave Young
AuthorDate: Tue, 7 Apr 2015 21:41:32 +0800
Committer: Ingo Molnar
CommitDate: Tue, 7 Apr 2015 16:01:19 +0200
x86/mm/numa: Fix kernel stack
node_set will set bit
MAX_NUMNODES thus stack corruption happen.
This also happens when booting with mem= kernel commandline during my test.
Fixing it by adding a check, do not call node_set in case nid is MAX_NUMNODES.
Signed-off-by: Dave Young
Reviewed-by: Yasuaki Ishimatsu
---
arch/x86/mm
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 s
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
some other modules
MAX_NUMNODES thus stack corruption happen.
This also happens when booting with mem= kernel commandline during my test.
Fixing it by adding a check, do not call node_set in case nid is MAX_NUMNODES.
Signed-off-by: Dave Young dyo...@redhat.com
Reviewed-by: Yasuaki Ishimatsu isimatu.yasu
Commit-ID: 22ef882e6b5bd2bf668d10b1e2be3dc2fc365b99
Gitweb: http://git.kernel.org/tip/22ef882e6b5bd2bf668d10b1e2be3dc2fc365b99
Author: Dave Young dyo...@redhat.com
AuthorDate: Tue, 7 Apr 2015 21:41:32 +0800
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Tue, 7 Apr 2015 16:01:19
- /* Mark all kernel nodes. */
+ /*
+* Mark all kernel nodes.
+*
+* In case booting with mem=nn[kMG] or in kdump kernel, numa_meminfo
Hi Dave,
It should both set mem=xx and numa=off, then numa_meminfo may not include all
the memblock.reserved memory, right?
On 04/08/15 at 10:41am, Xishi Qiu wrote:
On 2015/4/8 10:18, Baoquan He wrote:
On 04/08/15 at 09:59am, Xishi Qiu wrote:
On 2015/4/8 9:46, Dave Young wrote:
- /* Mark all kernel nodes. */
+ /*
+* Mark all kernel nodes.
+*
+* In case booting
On 04/07/15 at 05:55pm, Li, ZhenHua wrote:
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
On 04/03/15 at 02:05pm, Li, Zhen-Hua wrote:
> The hardware will do some verification, but not completely. If people think
> the OS should also do this, then it should be another patchset, I think.
If there is chance to corrupt more memory I think it is not a right way.
We should think about a
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
> > > some oth
On 04/06/15 at 07:26am, Yasuaki Ishimatsu wrote:
> Hi,
>
> On Fri, 3 Apr 2015 15:15:13 +0800
> Dave Young wrote:
>
> > Hi,
> >
> > On 04/02/15 at 12:36pm, Yasuaki Ishimatsu wrote:
> > >
> > > On Wed, 1 Apr 2015 12:53:46 +0800
> > >
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
some other modules. Currently we do not have a better solution
On 04/03/15 at 02:05pm, Li, Zhen-Hua wrote:
The hardware will do some verification, but not completely. If people think
the OS should also do this, then it should be another patchset, I think.
If there is chance to corrupt more memory I think it is not a right way.
We should think about a
On 04/06/15 at 07:26am, Yasuaki Ishimatsu wrote:
Hi,
On Fri, 3 Apr 2015 15:15:13 +0800
Dave Young dyo...@redhat.com wrote:
Hi,
On 04/02/15 at 12:36pm, Yasuaki Ishimatsu wrote:
On Wed, 1 Apr 2015 12:53:46 +0800
Dave Young dyo...@redhat.com wrote:
I got below kernel
s possible to continue corrupt other area of oldmem because
of using old iommu tables then it will cause more problems.
So I think the tables at least need some verifycation before being used.
>
>
> Thanks
> Zhenhua
>
> On 04/03/2015 04:40 PM, Dave Young wrote:
> >>To
> To fix this problem, we modifies the behaviors of the intel vt-d in the
> crashdump kernel:
>
> For DMA Remapping:
> 1. To accept the vt-d hardware in an active state,
> 2. Do not disable and re-enable the translation, keep it enabled.
> 3. Use the old root entry table, do not rewrite the RTA
On 03/19/15 at 01:36pm, 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:
On 04/03/15 at 09:17am, Ingo Molnar wrote:
>
> * Dave Young wrote:
>
> > Hi,
> >
> > On 04/02/15 at 12:36pm, Yasuaki Ishimatsu wrote:
> > >
> > > On Wed, 1 Apr 2015 12:53:46 +0800
> > > Dave Young wrote:
> > >
> > &
Hi,
On 04/02/15 at 12:36pm, Yasuaki Ishimatsu wrote:
>
> On Wed, 1 Apr 2015 12:53:46 +0800
> Dave Young wrote:
>
> > I got below kernel panic during kdump test on Thinkpad T420 laptop:
> >
> > [0.0
> > > >>
> > > >> The above reserved region includes 0x40004000, a page excluded in
> > > >> trim_snb_memory. For this memblock reserved region the nid is not set
> > > >> it is
> > > >> still default value MAX_NUMNODES. later node_set callback will set bit
> > > >> MAX_NUMNODES in nodemask
Hi,
On 04/02/15 at 12:36pm, Yasuaki Ishimatsu wrote:
On Wed, 1 Apr 2015 12:53:46 +0800
Dave Young dyo...@redhat.com wrote:
I got below kernel panic during kdump test on Thinkpad T420 laptop:
[0.00] No NUMA configuration found
On 04/03/15 at 09:17am, Ingo Molnar wrote:
* Dave Young dyo...@redhat.com wrote:
Hi,
On 04/02/15 at 12:36pm, Yasuaki Ishimatsu wrote:
On Wed, 1 Apr 2015 12:53:46 +0800
Dave Young dyo...@redhat.com wrote:
I got below kernel panic during kdump test on Thinkpad T420
To fix this problem, we modifies the behaviors of the intel vt-d in the
crashdump kernel:
For DMA Remapping:
1. To accept the vt-d hardware in an active state,
2. Do not disable and re-enable the translation, keep it enabled.
3. Use the old root entry table, do not rewrite the RTA
The above reserved region includes 0x40004000, a page excluded in
trim_snb_memory. For this memblock reserved region the nid is not set
it is
still default value MAX_NUMNODES. later node_set callback will set bit
MAX_NUMNODES in nodemask bitmap thus stack corruption
On 03/19/15 at 01:36pm, 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
of oldmem because
of using old iommu tables then it will cause more problems.
So I think the tables at least need some verifycation before being used.
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
Hi, Xishi
[snip]
> >> arch/x86/mm/numa.c |3 ++-
> >> 1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> --- linux.orig/arch/x86/mm/numa.c
> >> +++ linux/arch/x86/mm/numa.c
> >> @@ -484,7 +484,8 @@ static void __init numa_clear_kernel_nod
> >>
> >>/* Mark all kernel nodes. */
>
On 04/01/15 at 04:34pm, Xishi Qiu wrote:
> On 2015/4/1 16:21, Xishi Qiu wrote:
>
> > On 2015/4/1 15:41, Dave Young wrote:
> >
> >> On 04/01/15 at 03:27pm, Xishi Qiu wrote:
> >>> On 2015/4/1 13:11, Dave Young wrote:
> >>>
> >>>
On 04/01/15 at 03:27pm, Xishi Qiu wrote:
> On 2015/4/1 13:11, Dave Young wrote:
>
> > Ccing Xishi Qiu who wrote the clear_kernel_node_hotplug code.
> >
> > On 04/01/15 at 12:53pm, Dave Young wrote:
> >> I got below kernel panic during kdump test on Thinkpad T42
On 04/01/15 at 03:27pm, Xishi Qiu wrote:
On 2015/4/1 13:11, Dave Young wrote:
Ccing Xishi Qiu who wrote the clear_kernel_node_hotplug code.
On 04/01/15 at 12:53pm, Dave Young wrote:
I got below kernel panic during kdump test on Thinkpad T420 laptop:
[0.00] No NUMA
On 04/01/15 at 04:34pm, Xishi Qiu wrote:
On 2015/4/1 16:21, Xishi Qiu wrote:
On 2015/4/1 15:41, Dave Young wrote:
On 04/01/15 at 03:27pm, Xishi Qiu wrote:
On 2015/4/1 13:11, Dave Young wrote:
Ccing Xishi Qiu who wrote the clear_kernel_node_hotplug code.
On 04/01/15 at 12:53pm
Hi, Xishi
[snip]
arch/x86/mm/numa.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- linux.orig/arch/x86/mm/numa.c
+++ linux/arch/x86/mm/numa.c
@@ -484,7 +484,8 @@ static void __init numa_clear_kernel_nod
/* Mark all kernel nodes. */
Ccing Xishi Qiu who wrote the clear_kernel_node_hotplug code.
On 04/01/15 at 12:53pm, Dave Young wrote:
> I got below kernel panic during kdump test on Thinkpad T420 laptop:
>
> [0.00] No NUMA configuration found
>
> [0.00
MAX_NUMNODES. later node_set callback will set bit
MAX_NUMNODES in nodemask bitmap thus stack corruption happen.
Fixing this by adding a check, do not call node_set in case nid is MAX_NUMNODES.
Signed-off-by: Dave Young
---
arch/x86/mm/numa.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion
callback will set bit
MAX_NUMNODES in nodemask bitmap thus stack corruption happen.
Fixing this by adding a check, do not call node_set in case nid is MAX_NUMNODES.
Signed-off-by: Dave Young dyo...@redhat.com
---
arch/x86/mm/numa.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion
Ccing Xishi Qiu who wrote the clear_kernel_node_hotplug code.
On 04/01/15 at 12:53pm, Dave Young wrote:
I got below kernel panic during kdump test on Thinkpad T420 laptop:
[0.00] No NUMA configuration found
[0.00] Faking a node at [mem
On 03/09/15 at 10:22am, Alan Stern wrote:
> On Mon, 9 Mar 2015, Dave Young wrote:
>
> > On 03/08/15 at 11:29am, Alan Stern wrote:
> > > On Sun, 8 Mar 2015, Dave Young wrote:
> > >
> > > > I used usb cdrom emulation to play video dvd for my daught
On 03/09/15 at 10:22am, Alan Stern wrote:
On Mon, 9 Mar 2015, Dave Young wrote:
On 03/08/15 at 11:29am, Alan Stern wrote:
On Sun, 8 Mar 2015, Dave Young wrote:
I used usb cdrom emulation to play video dvd for my daughter, but I got
below
error:
[dave@darkstar tmp
On 03/08/15 at 11:29am, Alan Stern wrote:
> On Sun, 8 Mar 2015, Dave Young wrote:
>
> > I used usb cdrom emulation to play video dvd for my daughter, but I got
> > below
> > error:
> >
> > [dave@darkstar tmp]$ cat /mnt/sr1/VIDEO_TS/VTS_01_5.VOB >/dev/null
On 03/08/15 at 11:29am, Alan Stern wrote:
On Sun, 8 Mar 2015, Dave Young wrote:
I used usb cdrom emulation to play video dvd for my daughter, but I got
below
error:
[dave@darkstar tmp]$ cat /mnt/sr1/VIDEO_TS/VTS_01_5.VOB /dev/null
cat: /mnt/sr1/VIDEO_TS/VTS_01_5.VOB: Input/output
996
The assumption of cdrom size is not right, we can create data dvd large then
4G, also mkisofs can create an iso with only one blank directory, the size is
less than 300 sectors. The size limit does not make sense, thus remove them.
Signed-off-by: Dave Young
---
drivers/usb/gadget/funct
The assumption of cdrom size is not right, we can create data dvd large then
4G, also mkisofs can create an iso with only one blank directory, the size is
less than 300 sectors. The size limit does not make sense, thus remove them.
Signed-off-by: Dave Young dyo...@redhat.com
---
drivers/usb
x86/kernel/setup.c
> x86, efi: use early_ioremap in arch/x86/platform/efi/efi-bgrt.c
>
> arch/x86/kernel/devicetree.c | 4 ++--
> arch/x86/kernel/e820.c | 2 +-
> arch/x86/kernel/setup.c | 8
> arch/x86/platform/efi/efi-bgrt.c | 4 ++--
> 4 files
in arch/x86/platform/efi/efi-bgrt.c
arch/x86/kernel/devicetree.c | 4 ++--
arch/x86/kernel/e820.c | 2 +-
arch/x86/kernel/setup.c | 8
arch/x86/platform/efi/efi-bgrt.c | 4 ++--
4 files changed, 9 insertions(+), 9 deletions(-)
Acked-by: Dave Young dyo
On 02/05/15 at 09:11am, Borislav Petkov wrote:
> On Thu, Feb 05, 2015 at 11:18:46AM +0800, Dave Young wrote:
> > > diff --git a/include/linux/efi.h b/include/linux/efi.h
> > > index 0238d612750e..14cec75d7e74 100644
> > > --- a/include/linux/efi.h
> > > ++
On 02/05/15 at 09:11am, Borislav Petkov wrote:
On Thu, Feb 05, 2015 at 11:18:46AM +0800, Dave Young wrote:
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 0238d612750e..14cec75d7e74 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -940,6 +940,7 @@ extern
1101 - 1200 of 2643 matches
Mail list logo
