On 1/10/20 4:00 PM, Jerry Hoemann wrote:
> On Fri, Jan 10, 2020 at 03:25:36PM -0700, Khalid Aziz and Shuah Khan wrote:
>> On 1/10/20 2:42 PM, Bjorn Helgaas wrote:
>>> [+cc Deepa (also working in this area)]
>>>
>>> On Thu, Dec 26, 2019 at 03:21:18AM +0800, Kairu
On 1/10/20 5:50 PM, Baoquan He wrote:
> On 01/10/20 at 05:18pm, Khalid Aziz wrote:
>> On 1/10/20 4:00 PM, Jerry Hoemann wrote:
>>> On Fri, Jan 10, 2020 at 03:25:36PM -0700, Khalid Aziz and Shuah Khan wrote:
>>>> On 1/10/20 2:42 PM, Bjorn Helgaas wrote:
>>>&
On 1/13/20 10:07 AM, Kairui Song wrote:
> On Sun, Jan 12, 2020 at 2:33 AM Deepa Dinamani wrote:
>>
>>> Hi, there are some previous works about this issue, reset PCI devices
>>> in kdump kernel to stop ongoing DMA:
>>>
>>> [v7,0/5] Reset PCIe devices to address DMA problem on kdump with iommu
>>> h
On 1/15/20 11:05 AM, Kairui Song wrote:
> On Thu, Jan 16, 2020 at 1:31 AM Khalid Aziz wrote:
>>
>> On 1/13/20 10:07 AM, Kairui Song wrote:
>>> On Sun, Jan 12, 2020 at 2:33 AM Deepa Dinamani
>>> wrote:
>>>>
>>>>> Hi, there are some
On 1/16/20 8:24 PM, Dave Young wrote:
> On 01/15/20 at 02:17pm, Khalid Aziz wrote:
>> On 1/15/20 11:05 AM, Kairui Song wrote:
>>> On Thu, Jan 16, 2020 at 1:31 AM Khalid Aziz wrote:
>>>>
>>>> On 1/13/20 10:07 AM, Kairui Song wrote:
>>>>> On
On Tue, 2012-10-09 at 17:35 -0700, Tony Jones wrote:
> Definitions of BINARIES_ARCH in Makefile.in seems to have been broken since
> commit 0775c60eb.
>
> Signed-off-by: Tony Jones
> ---
>
> diff --git a/Makefile.in b/Makefile.in
> index ba2e638..97405a2 100644
> --- a/Makefile.in
> +++ b/Makef
Please see comments inline:
On Wed, 2012-10-10 at 16:51 +0900, Takao Indoh wrote:
> This patch resets PCIe devices at boot time by hot reset when
> "reset_devices" is specified.
>
>
> Signed-off-by: Takao Indoh
> ---
> arch/x86/include/asm/pci-direct.h |1
> arch/x86/kernel/setup.c
On Thu, 2012-10-11 at 15:16 +0900, Takao Indoh wrote:
> (2012/10/11 5:08), Khalid Aziz wrote:
.
> >> +static void __init do_reset(u8 bus, u8 slot, u8 func)
> >> +{
> >> + u16 ctrl;
> >> +
> >> + printk(KERN_INFO "pci :%02x:%02x.%d
|3
> arch/x86/pci/early.c | 344
> include/linux/pci.h |2
> init/main.c |4
> 5 files changed, 352 insertions(+), 2 deletions(-)
>
Loo
---
> kexec/arch/i386/crashdump-x86.c | 35 +++++++
> 1 file changed, 35 insertions(+)
Looks good.
Reviewed-by: Khalid Aziz
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On Thu, 2012-10-18 at 11:12 +0800, Dave Young wrote:
> On 09/12/2012 10:35 AM, Dave Young wrote:
>
> > On 09/07/2012 04:56 PM, Dave Young wrote:
> >>
> >> I did some digging about the efi boot kdump in slackware with kernel
> >> from latest linus tree. I'm surprise that kdump works even without th
On Wed, 2012-10-17 at 15:23 +0900, Takao Indoh wrote:
> This patch resets PCIe devices at boot time by hot reset when
> "reset_devices" is specified.
>
> Signed-off-by: Takao Indoh
> ---
> arch/x86/include/asm/pci-direct.h |1
> arch/x86/kernel/setup.c |3
> arch/x86/pci/earl
On Thu, 2012-10-18 at 15:11 -0400, Vivek Goyal wrote:
> On Thu, Oct 18, 2012 at 08:56:34AM -0600, Khalid Aziz wrote:
> > On Thu, 2012-10-18 at 11:10 +0800, Dave Young wrote:
> > > In case efi booting, kdump need kernel parameter acpi_rsdp= to retrieve
> > > the acpi
On Fri, 2012-10-19 at 10:53 -0400, Vivek Goyal wrote:
> On Thu, Oct 18, 2012 at 02:20:46PM -0700, Eric W. Biederman wrote:
> >
> > If we are passing the acpi sections is that not enough for the kernel
> > to find the rdsp area? I'm just a bit surprised we need this patch
> > is all.
> >
> > Some
On Mon, 2012-10-22 at 11:43 -0400, Vivek Goyal wrote:
> On Sat, Oct 20, 2012 at 08:06:23PM -0700, Eric W. Biederman wrote:
>
> [..]
> > It is the non-pure UEFI case where non-UEFI table scans work.
> >
> > Of course it puzzles me why we can't find the table via scanning memory
> > when running in
On Thu, 2012-11-01 at 14:57 +, Matthew Garrett wrote:
> On Thu, Nov 01, 2012 at 10:51:49AM -0400, Vivek Goyal wrote:
>
> > And if one wants only /sbin/kexec to call it, then just sign that
> > one so no other executable will be able to call kexec_load(). Though
> > I don't think that's the req
On Thu, 2012-11-01 at 16:23 +, Matthew Garrett wrote:
> On Thu, Nov 01, 2012 at 09:10:56AM -0600, Khalid Aziz wrote:
> > How would a customer go about getting that userspace binary signed and
> > re-signed every time they update their app? There is the option of
> &
issues caused by clearing Bus Master bit on PCI
devices in normal shutdown path. This patch is based on discussion at
http://marc.info/?l=linux-pci&m=138425645204355&w=2
Signed-off-by: Khalid Aziz
Acked-by: Konstantin Khlebnikov
Cc: sta...@vger.kernel.org
---
drivers/pci/pci-driv
On 11/27/2013 12:24 PM, Matthew Garrett wrote:
On Wed, Nov 27, 2013 at 12:18:28PM -0700, Khalid Aziz wrote:
+/* flag to track if kexec reboot is in progress */
+extern unsigned long kexec_in_progress;
Adding this to pci.h seems a little odd. We may want to use it somewhere
else at some point
On 11/27/2013 12:38 PM, ebied...@xmission.com wrote:
Khalid Aziz writes:
Add a flag to tell the PCI subsystem that kernel is shutting down
in prepapration to kexec a kernel. Add code in PCI subsystem to use
this flag to clear Bus Master bit on PCI devices only in case of
kexec reboot. This
On 11/27/2013 03:07 PM, Matthew Garrett wrote:
On Wed, Nov 27, 2013 at 02:01:06PM -0800, Greg KH wrote:
Anyway, I really don't care either way, but this seems like something
that the drivers should be doing. What suddenly changed that caused
this problem to occur that hasn't happened in the yea
issues caused by clearing Bus Master bit on PCI
devices in normal shutdown path. This patch is based on discussion at
http://marc.info/?l=linux-pci&m=138425645204355&w=2
Signed-off-by: Khalid Aziz
Acked-by: Konstantin Khlebnikov
Cc: sta...@vger.kernel.org
---
Changes since v1:
On Mon, 2013-12-09 at 15:38 -0800, Kees Cook wrote:
> For general-purpose (i.e. distro) kernel builds it makes sense to build with
> CONFIG_KEXEC to allow end users to choose what kind of things they want to do
> with kexec. However, in the face of trying to lock down a system with such
> a kernel,
On Tue, 2014-01-28 at 13:40 -0500, Vivek Goyal wrote:
> I am wondering if there is any interest in more frequent releases of
> kexec-tools. Say every 3 months or every 6 months.
Yes, that will be good. I maintain the kexec-tools package for Debian
and I often find myself backporting fixes from git
configure script
generated by autoconf is run. This patch adds the ";" in right places. I
have verified that configure.ac still works fine after these changes
with autoconf 2.63 and 2.61.
Signed-off-by: Khalid Aziz
---
configure.ac | 34 +-
1 files
On Thu, 2010-07-29 at 04:56 +, Simon Horman wrote:
> Hi all,
>
> I am happy to announce the release of kexec-tools 2.0.2.
> There were no changes between 2.0.2-rc2 and 2.0.2.
>
> The release can be downloaded from kernel.org:
>
> http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0
med to happen in device_shootdown(). I will look for any discussion
threads I can find.
--
Khalid
Khalid Aziz Telco Platform Software, ISB
(970)898-9214Hewlett-Packard
khalid.a...@hp.com
isit this, for more than just ia64.
--
Khalid
========
Khalid Aziz Telco Platform Software, ISB
(970)898-9214Hewlett-Packard
khalid.a...@hp.com
nstry.
Please apply.
Signed-off-by: Khalid Aziz
---
kexec/arch/i386/crashdump-x86.c | 10 ++
kexec/kexec.c | 18 ++
kexec/kexec.h |6 ++
3 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/kexec/arch/i386/crashdump-x8
Another patch that I have been carrying in debian kexec-tools package.
It corrects the section number for shutdown in the man page. This
patch also adds little more descriptive note for the -e option to
clarify that this does not do an orderly shutdown.
Please apply.
Signed-off-by: Khalid Aziz
continue
to DMA data after shutdown. This can cause memory
corruption in case of a kexec where the current kernel
shuts down and transfers control to a new kernel while a
PCI device continues to DMA to memory that does not belong
to it any more in the new kernel.
Signed-off-by: Khalid Aziz
On 09/04/2012 11:44 PM, Dave Young wrote:
In case efi booting, kdump need kernel parameter noefi and acpi_rsdp=
to disable efi reinit and retrieve the acpi root table physical address.
Add a function cmdline_add_efi to get the address from /sys/firmware/efi/systab
If there's no such file or read
On 09/05/2012 09:18 PM, Dave Young wrote:
I think running a kexec/kdump kernel with "noefi" is not a good idea.
Today kernel makes very little use of UEFI run time services but this
might change shortly. I have already seen ideas being proposed to use
UEFI variables to store kernel panic inform
On Thu, 2012-09-06 at 16:24 -0400, Vivek Goyal wrote:
> On Wed, Sep 05, 2012 at 05:09:29PM -0600, Khalid Aziz wrote:
> [..]
> > More work will be needed to make this work, for example pass the
> > EFI runtime service memory map from one kernel to the next so we
> > keep
efi_64bit = false;
737 } else if (!strncmp((char
*)&boot_params.efi_info.efi_loader_signatu re,
738 "EL64", 4)) {
739 efi_enabled = 1;
740 efi_64bit = true;
741 }
efi_ena
On Fri, 2012-08-17 at 08:58 +0200, Christian Schaubschläger wrote:
> >> I bistcted that down to this patch:
> >>
> >> commit b566a22c23327f18ce941ffad0ca907e50a53d41
> >> Author: Khalid Aziz
> >> Date: Fri Apr 27 13:00:33 2012 -0600
> >>
&
On 07/24/2012 11:49 AM, Christian Schaubschläger wrote:
Hello list,
I'm not sure if this is the correct place to post this; if it's not,
I'd like to apologize.
Here's a short description of my problem:
I have a tiny protected-/real mode program, which I start using kexec
(kexec-tools 2.0.3
the Bus Master bit as well. Can you access PCI config space in
your program that you kexec? If yes, can you set the Bus Master bit in
your program? You have a pretty standard IDE controller there which does
have Bus Master capability.
Thanks
--
Khalid Aziz
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
On 09/13/2012 07:38 AM, Vivek Goyal wrote:
So what does this mean? Second kernel assumes the regular BIOS and tries
to initialize that way? That sounds broken or is it just fine given
the fact we are anyway not planning to call into any of the efi services.
But what about memory maps, ACPI tables
to rethink that.
One is accessing the hardware clock. On a pure EFI and legacy-free
machine, we will need to access hardware through EFI runtime services.
The other one being access to EFI variables. We can choose to not use
EFI variables but we might be giving up some u
New email address for Khalid Aziz.
Signed-off-by: Khalid Aziz
---
AUTHORS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/AUTHORS b/AUTHORS
index a7ca8c8..f3ab523 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -1,7 +1,7 @@
Eric Biederman
Albert Herranz
Jesse Barnes
-Khalid Aziz
close(kernel_fd);
> return EFAILED;
> }
>
> ret = file_type[i].load(argc, argv, kernel_buf, kernel_size, &info);
> if (ret < 0) {
> fprintf(stderr, "Cannot load %s\n&q
On 1/10/20 2:42 PM, Bjorn Helgaas wrote:
> [+cc Deepa (also working in this area)]
>
> On Thu, Dec 26, 2019 at 03:21:18AM +0800, Kairui Song wrote:
>> There are reports about kdump hang upon reboot on some HPE machines,
>> kernel hanged when trying to shutdown a PCIe port, an uncorrectable
>> erro
As Eric pointed out, not all of these make sense. I have flagged the
ones that makes sense below.
On 8/25/20 2:14 AM, Youling Tang wrote:
> Add missing fclose()/close() call.
>
> Signed-off-by: Youling Tang
> ---
> kexec/kexec.c | 28 ++--
> 1 file changed, 22 insertions
44 matches
Mail list logo
