welcomed and much appreciated!
Baoquan He (2):
Revert "bnx2: Reset device during driver initialization"
bnx2: Hard reset bnx2 chip at probe stage
drivers/net/ethernet/broadcom/bnx2.c | 70 +---
1 file changed, 65 insertions(+), 5 deletions(-)
--
2.5.5
d in kdump kernel.
Signed-off-by: Baoquan He
---
drivers/net/ethernet/broadcom/bnx2.c | 62
1 file changed, 62 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bnx2.c
b/drivers/net/ethernet/broadcom/bnx2.c
index c557972..84e3f12 100644
--- a/d
Yes, Paul has reported this. Sorry about this!
Will work on it right away.
Thanks
Baoquan
On 11/08/16 at 11:50pm, Frank Reppin wrote:
> Hellos,
>
> ... firmware loading seems to be somewhat broken now with/since
>
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/dr
VMCOREINFO_NUMBER to export value of variable so that we
can use the existing number_table mechanism of Makedumpfile to fetch
it. So revert it now. If needed, can add it later.
http://lists.infradead.org/pipermail/kexec/2016-October/017540.html
Signed-off-by: Baoquan He
---
arch/x86/kernel/machine_kexec_64.c
virtual address.
And people also complained that KERNEL_IMAGE_SIZE exporting is x86_64 only,
should
be moved into arch dependent function arch_crash_save_vmcoreinfo. Do the moving
in this patch.
Signed-off-by: Baoquan He
---
arch/x86/kernel/machine_kexec_64.c | 3 ++-
kernel/kexec_core.c
On 11/04/16 at 01:14pm, Baoquan He wrote:
> Hi Joerg,
>
> Ping!
>
> About the v6 post, do you have any suggestions?
>
> Because of GCR3 special handling in patch 9/9, I spent several days to
> study the knowledge and change code. Then when I tried to post, the
>
hat's your opinion?
Thanks
Baoquan
On 10/20/16 at 07:37pm, Baoquan He wrote:
> This is v6 post.
>
> The principle of the fix is similar to intel iommu. Just defer the assignment
> of device to domain to device driver init. But there's difference than
> intel iommu. AMD iomm
On 11/02/16 at 09:29am, Dave Anderson wrote:
>
>
> - Original Message -
> > Hi Dave,
> >
> > On 11/01/16 at 10:13am, Dave Anderson wrote:
> > >
> > >
> > > > > But we have this in mainline which also introduced the VMCOREINFO
> > > > > numbers, can you send a patch to revert them?
> >
Hi Dave,
On 11/01/16 at 10:13am, Dave Anderson wrote:
>
>
> > > But we have this in mainline which also introduced the VMCOREINFO
> > > numbers, can you send a patch to revert them?
> >
> > OK, will do.
> >
> > However for find_vmemmap_x86_64() in makedumpfile, vmemmap_start is
> > still neede
On 11/01/16 at 01:10pm, Dave Young wrote:
> On 10/06/16 at 04:46pm, Baoquan He wrote:
> > KASLR memory randomization can randomize the base of the physical memory
> > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
> > (VMEMMAP_START). These need be exported to VM
In amd-vi spec several bits of IO PTE fields and DTE fields are similar
so that both of them can share the same MACRO definition. However
defining their respecitve bit fields can make code more read-able. So
do it in this patch.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 8
;t be updated to dte entry. We should wait until device driver init
stage.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index d5aef72..aa78506 100644
--- a/drivers/
es to.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index aa78506..3b95904 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2396,6 +23
reg.
- Flush all caches
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 51 --
1 file changed, 44 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index d4200e8..bc214fa 100644
--- a
d not allow the device to change old-kernels data when we
don't have to.
And clear the old GV flag when update domain information into dte entry
if the domain doesn't support IOMMUv2.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 45 ++-
Firstly split the dev table entry copy into address translation part and
irq remapping part. Because these two parts could be configured to
be available indepentently.
Secondly check if IntCtl and IntTabLen are 10b and 1000b if they are
set.
Signed-off-by: Baoquan He
---
drivers/iommu
.
And define MACRO DEV_DOMID_MASK to replace magic number 0xULL because
it need be reused in copy_dev_tables.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 2 +-
drivers/iommu/amd_iommu_init.c | 55 +
drivers/iommu/amd_iommu_types.h
ced Micro Devices, Inc. [AMD] FCH USB OHCI
Controller (rev 11)
- About GCR3 root pointer copying issue, I don't know how to setup the
test environment and haven't tested yet. Hope Joerg or Zongshun can
tell what steps should be taken to test it, or help take a test in y
Add functions to check whether translation is already enabled in IOMMU.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 25 +
drivers/iommu/amd_iommu_proto.h | 1 +
drivers/iommu/amd_iommu_types.h | 4
3 files changed, 30 insertions(+)
diff --git
Move per iommu enabling code into a wrapper function early_enable_iommu().
This can make later kdump change easier.
And also add iommu_disable_command_buffer and iommu_disable_event_buffer
for later usage.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 42
On 10/17/16 at 04:37pm, Michel Dänzer wrote:
> On 17/10/16 04:17 PM, Baoquan He wrote:
> > In fact this could happen in radeon_pci_shutdown. I tried reboot and
> > poweroff, kernel panic happened in both cases. Attachments are console
> > log and kernel config of 4.9-rc1 on li
Hi Pratyush,
On 10/12/16 at 02:39pm, Pratyush Anand wrote:
>
>
> On Wednesday 12 October 2016 05:56 AM, Baoquan He wrote:
> > > PAGE_OFFSET can be get via vaddr - paddr from elf pt_loads so only
> > > > VMALLOC_BASE and VMEMMAP_BASE is necessary..
> > Well,
On 10/11/16 at 04:19pm, Dave Young wrote:
> On 10/11/16 at 03:41pm, Baoquan He wrote:
> > Hi Eric,
> >
> > Thanks a lot for your reviewing! Sorry for late reply.
> >
> > On 10/06/16 at 03:07pm, Eric W. Biederman wrote:
> > > Baoquan He writes:
>
Hi Eric,
Thanks a lot for your reviewing! Sorry for late reply.
On 10/06/16 at 03:07pm, Eric W. Biederman wrote:
> Baoquan He writes:
>
> > KASLR memory randomization can randomize the base of the physical memory
> > mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
using VMCOREINFO_NUMBER we can reuse the existing
struct number_table in makedumpfile to import data easily.
Since they are related to x86_64 only, put them into
arch_crash_save_vmcoreinfo. And move the exportion of KERNEL_IMAGE_SIZE
together since it's also for x86_64 only.
Signed-off-by: Ba
On 09/28/16 at 09:37am, Baoquan He wrote:
> Hi Joerg,
>
> On 09/20/16 at 02:40pm, Joerg Roedel wrote:
> > > + if ( !is_pre_enabled) {
> > > + for_each_iommu(iommu)
> > > + early_enable_iommu(iommu);
> > > +
Hi Joerg,
On 09/20/16 at 02:40pm, Joerg Roedel wrote:
> > + if ( !is_pre_enabled) {
> > + for_each_iommu(iommu)
> > + early_enable_iommu(iommu);
> > + } else {
> > + if (copy_dev_tables()) {
> > + pr_err("Failed to copy DEV table from pre
s the original method, or use set_dma_mask method and add set_dma_mask
calling in those driver which missed calling it?
>From 1ca66f886a46839cb937fd1e6a1d84b6719f23c4 Mon Sep 17 00:00:00 2001
From: Baoquan He
Date: Mon, 12 Sep 2016 08:05:15 +0800
Subject: [PATCH] iommu/amd: Update domain into to
On 09/21/16 at 06:26pm, Baoquan He wrote:
> On 09/20/16 at 02:50pm, Joerg Roedel wrote:
> > On Thu, Sep 15, 2016 at 11:03:25PM +0800, Baoquan He wrote:
> > > AMD iommu creates protection domain and assign each device to it during
> > > iommu driver initialization stag
On 09/20/16 at 02:53pm, Joerg Roedel wrote:
> On Thu, Sep 15, 2016 at 11:03:26PM +0800, Baoquan He wrote:
> > All devices are supposed to reset themselves at device driver initialization
> > stage. At this time if in kdump kernel those on-flight DMA will be stopped
> > be
On 09/20/16 at 02:50pm, Joerg Roedel wrote:
> On Thu, Sep 15, 2016 at 11:03:25PM +0800, Baoquan He wrote:
> > AMD iommu creates protection domain and assign each device to it during
> > iommu driver initialization stage. This happened just after system pci
> > bus scanning st
On 09/20/16 at 02:42pm, Joerg Roedel wrote:
> On Thu, Sep 15, 2016 at 11:03:24PM +0800, Baoquan He wrote:
> > This enabling should have been done in normal kernel. It's unnecessary
> > to enable it again in kdump kernel.
> >
> > And clean up the function c
On 09/20/16 at 02:40pm, Joerg Roedel wrote:
> On Thu, Sep 15, 2016 at 11:03:23PM +0800, Baoquan He wrote:
> > Here several things need be done:
> > 1) If iommu is pre-enabled in a normal kernel, just disable it and print
> >warning.
> > 2) If failed to copy dev table
Hi Joerg,
Thanks for your reviewing and great suggestion!
On 09/20/16 at 01:58pm, Joerg Roedel wrote:
> Hi Baoquan,
>
> On Thu, Sep 15, 2016 at 11:03:22PM +0800, Baoquan He wrote:
> > +static int copy_dev_tables(void)
> > +{
> > + u64 entry;
> > + u32 l
On 09/20/16 at 06:03pm, Jonathan Corbet wrote:
> On Mon, 19 Sep 2016 13:59:46 +0800
> Baoquan He wrote:
>
> > This is v10 post. In this patchset patch 1/3 is added to give more details
> > about nr_cpus and maxcpus in kernel-parameters.txt. This is suggested by
> > Jon
On 09/20/16 at 11:56am, Joerg Roedel wrote:
> On Tue, Sep 20, 2016 at 09:05:34AM +0800, Baoquan He wrote:
> > This is a clean up. In get_irq_table() only if DTE entry is changed
> > iommu_completion_wait() need be called. Otherwise no need to do it.
> >
> >
On 09/19/16 at 04:20pm, Joerg Roedel wrote:
> Hi Baoquan,
>
> On Thu, Sep 15, 2016 at 04:50:49PM +0800, Baoquan He wrote:
> > These were found out when I tried to fix the kdump failure on system
> > with AMD iommu. Pack them into this patchset since they are not related
>
This is a clean up. In get_irq_table() only if DTE entry is changed
iommu_completion_wait() need be called. Otherwise no need to do it.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b
From: Zhou Wenjian
nr_cpus can help to save memory. So we should remind user of it.
Signed-off-by: Zhou Wenjian
Acked-by: Baoquan He
Acked-by: Xunlei Pang
---
Documentation/kdump/kdump.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/kdump/kdump.txt b/Documentation
From: Zhou Wenjian
Multi-cpu support is useful to improve the performance of kdump in
some cases. So add the description of enable multi-cpu support in
dump-capture kernel.
Signed-off-by: Zhou Wenjian
Acked-by: Baoquan He
Acked-by: Xunlei Pang
---
Documentation/kdump/kdump.txt | 7
her change
for 2/3 and 3/3 which comprise the old post.
Please access below link to check the previous changelog.
https://lkml.org/lkml/2016/8/17/646
Baoquan He (1):
docs: kernel-parameter : Improve the description of nr_cpus and
maxcpus
Zhou Wenjian (2):
Documentation: kdump: remind user
of already plugged cpus and hot plug cpus can't exceed its
value. However maxcpus is used to limit how many cpus are allowed to
be brought up during bootup.
Signed-off-by: Baoquan He
---
Documentation/kernel-parameters.txt | 20 +---
1 file changed, 13 insertions(+), 7 del
On 09/19/16 at 12:01pm, Baoquan He wrote:
> From: Zhou Wenjian
>
> Multi-cpu support is useful to improve the performance of kdump in
> some cases. So add the description of enable multi-cpu support in
> dump-capture kernel.
>
> Signed-off-by: Zhou Wenjian
> Acked-by
of already plugged cpus and hot plug cpus can't exceed its
value. However maxcpus is used to limit how many cpus are allowed to
be brought up during bootup.
Signed-off-by: Baoquan He
---
Documentation/kernel-parameters.txt | 20 +---
1 file changed, 13 insertions(+), 7 del
her change
for 2/3 and 3/3 which comprise the old post.
Please access below link to check the previous changelog.
https://lkml.org/lkml/2016/8/17/646
Baoquan He (1):
docs: kernel-parameter : Improve the description of nr_cpus and
maxcpus
Zhou Wenjian (2):
Documentation: kdump: remind user
From: Zhou Wenjian
nr_cpus can help to save memory. So we should remind user of it.
Signed-off-by: Zhou Wenjian
Acked-by: Baoquan He
Acked-by: Xunlei Pang
Signed-off-by: Baoquan He
---
Documentation/kdump/kdump.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/kdump
From: Zhou Wenjian
Multi-cpu support is useful to improve the performance of kdump in
some cases. So add the description of enable multi-cpu support in
dump-capture kernel.
Signed-off-by: Zhou Wenjian
Acked-by: Baoquan He
Acked-by: Xunlei Pang
Signed-off-by: Baoquan He
---
Documentation
Add functions to check whether translation is already enabled in IOMMU.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 25 +
drivers/iommu/amd_iommu_proto.h | 1 +
drivers/iommu/amd_iommu_types.h | 4
3 files changed, 30 insertions(+)
diff --git
Move per iommu enabling code into a wrapper function early_enable_iommu().
This can make later kdump change easier.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu
es to.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 6c37300..00b64ee 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2310,6 +23
In amd-vi spec several bits of IO PTE fields and DTE fields are similar
so that both of them can share the same MACRO definition. However
defining their respecitve bit fields can make code more read-able. So
do it in this patch.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 8
the pte_root to dev table entry to device driver
init stage.
Baoquan He (8):
iommu/amd: Detect pre enabled translation
iommu/amd: add early_enable_iommu() wrapper function
iommu/amd: Define bit fields for DTE particularly
iommu/amd: Add function copy_dev_tables
iommu/amd: copy old trans
occupied in 1st kernel
need be reserved to avoid touching the old io-page tables so that on-flight DMA
can continue looking up.
And define MACRO DEV_DOMID_MASK to replace magic number 0xULL because
it need be reused in copy_dev_tables.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c
;t be updated to dte entry. We should wait until device driver init
stage.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index fcb69ff..6c37300 100644
--- a/drivers/
This enabling should have been done in normal kernel. It's unnecessary
to enable it again in kdump kernel.
And clean up the function comments of init_device_table_dma.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 10 +++---
1 file changed, 7 insertions(+), 3 dele
caches
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 44 +++---
1 file changed, 41 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index ce49641..47a8fc9 100644
--- a/drivers/iommu
These were found out when I tried to fix the kdump failure on system
with AMD iommu. Pack them into this patchset since they are not related
to the kdump issue and each other.
Baoquan He (4):
iommu/amd: clean up the cmpxchg64 invocation
iommu/amd: Use standard bitmap operation to set bitmap
Change it as it's designed for and keep it consistent with other
places.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 96de97a..160fc6a 100644
This is a clean up. In get_irq_table() only if DTE entry is changed
iommu_completion_wait() need be called. Otherwise no need to do it.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b
It will be more readable and safer than the old setting.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu_init.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 59741ea..3e810c6 100644
--- a/drivers
The current code missed freeing domain id when free a domain of
struct dma_ops_domain.
Signed-off-by: Baoquan He
---
drivers/iommu/amd_iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 160fc6a..a9f78c2 100644
--- a/drivers
On 09/13/16 at 11:25am, David Miller wrote:
>
> Just to be clear, I did actually apply this v2 of the patch
> rather than the initial version.:)
Thanks a lot!
Hi Thomas,
I used below code and it works. Since using VMCOREINFO_NUMBER can reuse
the existing struct number_table to import the data. It makes change
easier. But the place could be next to KERNEL_IMAGE_SIZE, or as your
patch did, both is fine.
---
kernel/kexec_core.c | 3 +++
1 file changed, 3
net device up stage. This will cause
hardware iommu handling failure on bnx2 device. And its resetting relies
on firmware. So in this patch move the firmware requesting code to earlier
bnx2_init_one(), then next call bnx2_reset_chip to reset device.
Signed-off-by: Baoquan He
---
v1->
On 09/09/16 at 04:11pm, Baoquan He wrote:
> When system enters into kdump kernel because of kernel panic, it won't
> shutdown devices. On-flight DMA will continue transferring data until
> device driver initializes. All devices are supposed to reset during
> driver initial
Hi Joerg,
On 09/09/16 at 10:41am, Joerg Roedel wrote:
>
> Hi Baoquan,
>
> On Fri, Sep 09, 2016 at 04:22:25PM +0800, Baoquan He wrote:
> > Recently I tried to fix the kdump failure in amd iommu system again, and
> > now the latest code works, IO_PAGE_FAULT can&#x
On 09/09/16 at 10:41am, Joerg Roedel wrote:
>
> Hi Baoquan,
>
> On Fri, Sep 09, 2016 at 04:22:25PM +0800, Baoquan He wrote:
> > Recently I tried to fix the kdump failure in amd iommu system again, and
> > now the latest code works, IO_PAGE_FAULT can't be seen any
On 09/09/16 at 10:30am, Joerg Roedel wrote:
> On Fri, Sep 09, 2016 at 04:05:50PM +0800, Baoquan He wrote:
> > On 09/06/16 at 11:13am, Joerg Roedel wrote:
> > > Hmm, on the other hand, the AMD-Vi driver in 4.8 uses the generic IOVA
> > > allocator, so the addresses it ha
ntry calling to __map_single calling, the principal should be
similar.
Thanks
Baoquan
On 09/09/16 at 04:11pm, Baoquan He wrote:
> When system enters into kdump kernel because of kernel panic, it won't
> shutdown devices. On-flight DMA will continue transferring data until
> device driver
red to net device up stage. This will cause
hardware iommu handling failure on bnx2 device. And its resetting relies
on firmware. So in this patch move the firmware requesting code to earlier
bnx2_init_one(), then next call bnx2_reset_chip to reset device.
Signed-off-by: Baoquan He
---
drivers/net/et
On 09/06/16 at 11:13am, Joerg Roedel wrote:
> On Mon, Sep 05, 2016 at 06:11:58PM +0800, Baoquan He wrote:
> > On 09/05/16 at 11:59am, Joerg Roedel wrote:
> > > > This happened on 4.8.0-rc5
> > > >
> > > > [ +0.006771] AMD-Vi: Event logged [IO_PAG
On 09/07/16 at 03:09pm, AKASHI Takahiro wrote:
> On Mon, Aug 29, 2016 at 06:11:37PM +0800, Baoquan He wrote:
> > Hi Thomas,
> >
> > I used below code and it works. Since using VMCOREINFO_NUMBER can reuse
> > the existing struct number_table to import the data. It makes
On 09/05/16 at 11:59am, Joerg Roedel wrote:
> Hi Baoquan
>
> On Mon, Sep 05, 2016 at 01:38:05PM +0800, Baoquan He wrote:
> > This happened on 4.8.0-rc5
> >
> > [ +0.006771] AMD-Vi: Event logged [IO_PAGE_FAULT device=00:14.4
> > domain=0x0009 addres
Hi Thomas,
I used below code and it works. Since using VMCOREINFO_NUMBER can reuse
the existing struct number_table to import the data. It makes change
easier. But the place could be next to KERNEL_IMAGE_SIZE, or as your
patch did, both is fine.
---
kernel/kexec_core.c | 3 +++
1 file changed, 3
think it's OK. Let's wait for Jon's feekback.
>
> --
> Thanks
> Zhou
>
> On 08/24/2016 01:06 PM, Baoquan He wrote:
> >On 08/22/16 at 09:14am, "Zhou, Wenjian/周文剑" wrote:
> >>On 08/19/2016 11:57 PM, Jonathan Corbet wrote:
> >>
On 08/25/16 at 01:10pm, Jonathan Corbet wrote:
> On Wed, 24 Aug 2016 13:06:45 +0800
> Baoquan He wrote:
>
> > Hi Jon, do you think change as below is OK to you?
>
> So nr_cpus is the maximum value, and maxcpus is the current number.
> Figures. No wonder the documentat
On 08/26/16 at 04:47pm, Himanshu Madhani wrote:
>
>
> On 8/25/16, 10:39 PM, "Baoquan He" wrote:
>
> >On 08/25/16 at 05:45pm, Himanshu Madhani wrote:
> >>
> >
> >crashkernel has been reserved successfully.
> >Aug 25 10:36:44
On 08/25/16 at 05:45pm, Himanshu Madhani wrote:
>
crashkernel has been reserved successfully.
Aug 25 10:36:44 dut4062 kernel: Reserving 512MB of memory at 368MB for
crashkernel (System RAM: 130847MB)
So what's the result of executing "grep Crash /porc/iomem" on your
system?
>
> On 8/25/16, 1
It's reasonable. Ack.
Acked-by: Baoquan He
On 08/24/16 at 09:05pm, Thiago Jung Bauermann wrote:
> If kexec_apply_relocations fails, kexec_load_purgatory frees pi->sechdrs
> and pi->purgatory_buf. This is redundant, because in case of error
> kimage_file_pr
ified, smp is disabled.
I am not very sure why this is introduced, number of possible cpu is
decided by the min value of nr_cpus= and possible_cpus=.
nr_cpus and maxcpus might not be very clear to people which are
described in Documentation/kernel-parameters.txt.
Hi Jon, do you think change as below
This makes sense. Makedumpfile need this to parse memory sections.
Ack.
Acked-by: Baoquan He
On 08/18/16 at 07:47am, Thomas Garnier wrote:
> KASLR memory randomization can randomize the base of the physical memory
> mapping (PAGE_OFFSET), vmalloc (VMALLOC_START) and vmemmap
> (VMEM
On 08/16/16 at 02:26am, Zheng, Lv wrote:
> Hi,
>
> > From: linux-acpi-ow...@vger.kernel.org
> > [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Baoquan
> > diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> > index 9f0ad6e..34d45bb 100644
> > --- a/drivers/acpi/tables.c
> > +++ b
Commit-ID: 31b02dd718712f4c45afbeea7fbd187ecb1b202c
Gitweb: http://git.kernel.org/tip/31b02dd718712f4c45afbeea7fbd187ecb1b202c
Author: Baoquan He
AuthorDate: Fri, 12 Aug 2016 15:21:47 +0800
Committer: Ingo Molnar
CommitDate: Mon, 15 Aug 2016 08:53:44 +0200
x86/apic, ACPI: Fix
Commit-ID: 6de421198c75d95088331e6a480e952292b0e121
Gitweb: http://git.kernel.org/tip/6de421198c75d95088331e6a480e952292b0e121
Author: Baoquan He
AuthorDate: Fri, 12 Aug 2016 14:57:13 +0800
Committer: Ingo Molnar
CommitDate: Mon, 15 Aug 2016 08:53:37 +0200
x86/apic, ACPI: Remove the
Commit-ID: a91bf718dbc993ea582cd53c0cb711a0839b4603
Gitweb: http://git.kernel.org/tip/a91bf718dbc993ea582cd53c0cb711a0839b4603
Author: Baoquan He
AuthorDate: Fri, 12 Aug 2016 14:57:12 +0800
Committer: Ingo Molnar
CommitDate: Mon, 15 Aug 2016 08:51:54 +0200
x86/mm/numa: Open code
On 08/14/16 at 12:25am, Brian Gerst wrote:
> On Fri, Jul 8, 2016 at 4:35 PM, tip-bot for Thomas Garnier
> wrote:
> > Commit-ID: 021182e52fe01c1f7b126f97fd6ba048dc4234fd
> > Gitweb:
> > http://git.kernel.org/tip/021182e52fe01c1f7b126f97fd6ba048dc4234fd
> > Author: Thomas Garnier
> > Auth
By pure accident the bug makes no functional difference, because the only
expression where we are using these values is (!count && !x2count), in which
the variables are interchangeable, but it makes sense to fix the bug
nevertheless.
Signed-off-by: Baoquan He
[Ingo rewrote changelog]
-
patch is not supposed to change any runtime behavior, other than
improving kernel messages.
Signed-off-by: Baoquan He
---
v1->v2:
-Remove the incorrect code comment above early_acpi_boot_init()
as Rafael suggested.
v2->v4:
-Spell out that this patch is not supposed to change any r
ned-off-by: Baoquan He
---
v1->v3:
-No change.
v3->v4:
1)Move smp_found_config check into default_get_smp_config.
2)Remove the redundent #ifdef check of CONFIG_X86_MPPARSE when call
early_get_smp_config.
-These are suggested by Ingo.
arch/x86/kernel/mpparse.c | 3 +++
arch/x8
On 08/11/16 at 10:46am, Ingo Molnar wrote:
> > > > - count = madt_proc[1].count;
> > > > + count = madt_proc[0].count;
> > > > + x2count = madt_proc[1].count;
> > > > }
> > > > if (!count && !x2count) {
> > ~
>
On 08/11/16 at 10:37am, Ingo Molnar wrote:
>
> * Baoquan He wrote:
>
> > On 08/10/16 at 04:02pm, Ingo Molnar wrote:
> > >
> > > * Baoquan He wrote:
> > >
> > > > ACPI MADT has a 32-bit field providing lapic address at which
> > &g
On 08/10/16 at 04:01pm, Ingo Molnar wrote:
>
> * Baoquan He wrote:
>
> > Previously early_acpi_boot_init is called in early_get_boot_cpu_id()
> > to get value for boot_cpu_physical_apicid. Now early_acpi_boot_init()
> > has been taken out and moved t
On 08/10/16 at 04:02pm, Ingo Molnar wrote:
>
> * Baoquan He wrote:
>
> > ACPI MADT has a 32-bit field providing lapic address at which
> > each processor can access its lapic information. MADT also contains
> > an optional entry to provide a 64-bit address to
On 08/10/16 at 02:53pm, Ingo Molnar wrote:
>
> * Baoquan He wrote:
>
> > It won't impact the result, we still should fix the code bug.
> >
> > Signed-off-by: Baoquan He
> > Cc: "Rafael J. Wysocki"
> > Cc: Len Brown
> > Cc: Pavel
The current code always increases the count in the 1st element of
array proc[].
Signed-off-by: Baoquan He
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: linux-a...@vger.kernel.org
---
v1->v2:
V1 is a wrong post because I didn't update the tested code to my
local laptop. Repost with a
Sorry, I tested in another system, but forget updating code on my
laptop.
Will reply with a v2 post.
Sorry again about this mistake.
The current code always increases the count in the 1st element of
array proc[].
Signed-off-by: Baoquan He
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: linux-a...@vger.kernel.org
---
drivers/acpi/tables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/tables.c b
It won't impact the result, we still should fix the code bug.
Signed-off-by: Baoquan He
Cc: "Rafael J. Wysocki"
Cc: Len Brown
Cc: Pavel Machek
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: linux...@vger.kernel.org
---
arch/x
Hi Ingo,
Ping,
Do you have another comment to this two patches?
Thanks
Baoquan
On 07/30/16 at 07:10pm, Baoquan He wrote:
> Previously early_acpi_boot_init is called in early_get_boot_cpu_id()
> to get value for boot_cpu_physical_apicid. Now early_acpi_boot_init()
> has been taken out
c related
patches.
Except for this, I am fine with this patchset. Ack it again.
Acked-by: Baoquan He
Thanks
Baoquan
> ---
> Documentation/kdump/kdump.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdum
1201 - 1300 of 1772 matches
Mail list logo
