summaryrefslogtreecommitdiff
path: root/kexec/arch/i386/x86-linux-setup.c
AgeCommit message (Collapse)Author
2021-04-02i386: fix build on pre 4.4 kernelsFederico Pellegrin
kexec build will fail on older kernels (pre 4.4) as the define VIDEO_CAPABILITY_64BIT_BASE was not present at that time. This patch adds it, as per linux/include/uapi/linux/screen_info.h, if not present. Signed-off-by: Federico Pellegrin <fede@evolware.org> Reviewed-by: Kairui Song <kasong@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2020-11-16i386: fix string formatting-related warningsAhelenia Ziemiańska
fixed the same way as in 70cca82 "kexec: Fix snprintf related compilation warnings" Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-05-31x86: Always try to fill acpi_rsdp_addr in boot paramsKairui Song
Since kernel commit e6e094e053af75 ("x86/acpi, x86/boot: Take RSDP address from boot params if available"), kernel accept an acpi_rsdp_addr param in boot_params. So fill in this parameter unconditionally, ensure second kernel always get the right RSDP address consistently, and boot well on EFI system even with EFI service disabled. User no longer need to change the kernel cmdline to workaround the missing RSDP issue. For older version of kernels (Before 5.0), there won't be any change of behavior. Signed-off-by: Kairui Song <kasong@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-05-31x86: Introduce helpers for getting RSDP addressKairui Song
On x86 RSDP is fundamental for booting the machine. When second kernel is incapable of parsing the RSDP address (eg. kexec next kernel on an EFI system with EFI service disabled), kexec should prepare the RSDP address for second kernel. Introduce helpers for getting RSDP from multiple sources, including boot params and EFI firmware. For legacy BIOS interface, there is no better way to find the RSDP address rather than scanning the memory region and search for it, and this will always be done by the kernel as a fallback, so this is no need to try to get the RSDP address for that case. Signed-off-by: Kairui Song <kasong@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-05-15x86: Find mounts by FS type, not nameNiklas Hambüchen
The name in mount invocations like mount -t debugfs debugfs /sys/kernel/debug is nothing but convention and cannot be relied upon. For example, https://www.kernel.org/doc/Documentation/filesystems/debugfs.txt recommends making the name "none" instead: mount -t debugfs none /sys/kernel/debug and many existing systems use mounts named "none" or otherwise. Using `mnt_type` instead of `mnt_fsname` allows kexec to work on such systems. This fixes another instance of `poweroff` not working on kexec'ed kernels because the lack of correctly matched mount results in EFI variables not being read and propagated. Signed-off-by: Niklas Hambüchen <mail@nh2.me> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-05-15x86: Check /proc/mounts before mtab for mountsNiklas Hambüchen
In many situations, especially on read-only file systems and initial ramdisks (intramfs/initrd), /etc/mtab does not exist. Before this commit, kexec would fail to read mounts on such systems in `find_mnt_by_fsname()`, such that `get_bootparam()` would not `boot_params/data`, which would then lead to e.g. `setup_efi_data()` not being called in `setup_efi_info()`. As a result, kexec'ed kernels would not obtain EFI data, subsequentially lack an `ACPI RSDP` entry, emitting: ACPI BIOS Error (bug): A valid RSDP was not found (20180810/tbxfroot-210) and thus fail to turn off the machine on poweroff, instead printing only: reboot: System halted This problem had to be worked around by passing `acpi_rsdp=` manually before. This commit obviates this workaround. See also: * https://github.com/coreos/bugs/issues/167#issuecomment-487320879 * http://lists.infradead.org/pipermail/kexec/2012-October/006924.html Signed-off-by: Niklas Hambüchen <mail@nh2.me> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-03-06x86: Introduce a new option --reuse-video-typeKairui Song
After commit 060eee58 "x86: use old screen_info if needed", kexec-tools will force use old screen_info and vga type if failed to determine current vga type. But it is not always a good idea. Currently kernel hanging is inspected on some hyper-v VMs after this commit, because hyperv_fb will mimic EFI (or VESA) VGA on first boot up, but after the real driver is loaded, it will switch to new mode and no longer compatible with EFI/VESA VGA. Keep setting orig_video_isVGA to EFI/VESA VGA flag will get wrong driver loaded and try to manipulate the framebuffer in a wrong way. We can't ensure this won't happen on other framebuffer drivers, But it's a helpful feature if the framebuffer drivers just work. So this patch introduce a --reuse-video-type options to let user decide if the old screen_info hould be used unconditional or not. Signed-off-by: Kairui Song <kasong@redhat.com> Reviewed-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2019-01-28x86: Handle 64bit framebuffer memory address properlyKairui Song
In a EFI system, the frame buffer address is 64bit, so currently if the address is beyound 4G, kexec will set wrong address due to truncate. Linux kernel commit ae2ee627dc87 ('efifb: Add support for 64-bit frame buffer addresses') added support for 64bit frame buffer address, an 'ext_lfb_base' field is added as the upper 32-bits of the frame buffer, and introduced a new capability flag 'VIDEO_TYPE_CAPABILITY_64BIT_BASE' to indicate if the extend field is used. This patch adopts this change, set proper extent address and capability flag when the address is beyound 4G. Signed-off-by: Kairui Song <kasong@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-10-29x86: fix BAD_FREE in get_efi_runtime_map()Pingfan Liu
If the err_out label is reached, address of a stack variable is passed to free(). Fix it. Signed-off-by: Pingfan Liu <piliu@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2018-01-29x86: use old screen_info if neededDave Young
With modern drm/kms graphic driver kexec-tools does not setup screen_info correctly so one will only see screen output after those drm drivers reinitializing after rebooting. Copying the old screen info from original boot_params will help during my test, although it could not work for some potential cases, but it is not worse than before. This has been used in the kernel kexec_file_load. Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2015-09-02Add persistent memory supportBaoquan He
Kernel add E820_PRAM or E820_PMEM type for NVDIMM memory device. Now support them in kexec too. Reported-by: Toshi Kani <toshi.kani@hp.com> Tested-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Baoquan He <bhe@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-05-28kexec-tools: add noefi arch cmdline optionDave Young
For kernel boot with efi=old_map or some quirked machines like SGI UV they use old ioremap instead of 1:1 mapping. But kexec efi support depends on the 1:1 mapping thus we need to switch to use the old way There's a kernel patch for exporting the efi flags so we can check the memory mapping method. But user may want to explictly disable efi boot for unknown reasons. So here add a new arch option '--noefi' for this case. Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-23x86: Pass memory range via E820 for kdumpWANG Chao
command line size is restricted by kernel, sometimes memmap=exactmap has too many memory ranges to pass to cmdline. And also memmap=exactmap and kASLR doesn't work together. A better approach, to pass the memory ranges for crash kernel to boot into, is filling the memory ranges into E820. boot_params only got 128 slots for E820 map to fit in, when the number of memory map exceeds 128, use setup_data to pass the rest as extended E820 memory map. kexec boot could also benefit from setup_data in case E820 memory map exceeds 128. Now this new approach becomes default instead of memmap=exactmap. saved_max_pfn users can specify --pass-memmap-cmdline to use the exactmap approach. Signed-off-by: WANG Chao <chaowang@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Reviewed-by: Linn Crosetto <linn@hp.com> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-23x86, cleanup: kexec memory range .end to be inclusiveWANG Chao
Later kexec and kdump memory range will be mapped to E820entry. But currently kexec memory range .end field is exclusive while crash memory range is inclusive. Given the fact that the exported proc iomem and sysfs memmap are both inclusive, change kexec memory range .end to be inclusive. Later the unified memory range of both kexec and kdump can use the same E820 filling code. Signed-off-by: WANG Chao <chaowang@redhat.com> Acked-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-04-14x86, cleanup: Add a funtion add_setup_data()WANG Chao
add_setup_data() is used to add an instance to the single linked list of setup_data structure. Signed-off-by: WANG Chao <chaowang@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-03-28i386: fix erroneous memory descriptor messageTony Jones
On non-EFI systems, efi_info section of boot_params is zero filled resulting in an erroneous message from kexec regarding "efi memory descriptor" version. Caused by commit: e1ffc9e9a0769e1f54185003102e9bec428b84e8 "Passing efi related data via setup_data" 0000700 0000 0000 0000 0000 0000 0000 0000 0000 0000720 0000 0000 0000 0000 0000 0000 0000 0000 0000740 efi memory descriptor version 0 is not supported! Signed-off-by: Tony Jones <tonyj@suse.de> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-03-25kexec-tools: handle 64bit efi memmap address correctlyDave Young
In case using crashkernel=xM,high crashkernel memory will be allocated from top to down Thus the usable memory for kdump kernel could be bigger than 4G. The efi memmap value is two 32 bit values efi_memmap and efi_memmap_hi, previously I only passed the efi_memmap so for the high memory address there will be below kernel panic: [ 0.000000] efi: EFI v2.31 by American Megatrends [ 0.000000] efi: ACPI 2.0=0xdb752000 SMBIOS=0xdbab4b98 ACPI=0xdb752000 MPS=0xf4bd0 [ 0.000000] efi: mem00: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935) [ 0.000000] efi: mem01: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935) [ 0.000000] efi: mem02: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935) [ 0.000000] efi: mem03: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935) [ 0.000000] efi: mem04: type=4294967295, attr=0xffffffffffffffff, range=[0xffffffffffffffff-0xffffffffffffefff) (72057594037927935) [ 0.000000] SMBIOS 2.7 present. [snip] [ 0.082451] BUG: unable to handle kernel paging request at ffffa3d0f0000000 [ 0.089467] IP: [<ffffffff810513d1>] native_set_pte+0x1/0x10 [ 0.095157] PGD 0 [ 0.097197] Oops: 0002 [#1] SMP [ 0.100466] Modules linked in: [ 0.103554] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc7 #157 [ 0.110001] Hardware name: Hewlett-Packard HP Z420 Workstation/1589, BIOS J61 v03.15 05/09/2013 [ 0.118697] task: ffffffff818e1460 ti: ffffffff818ce000 task.ti: ffffffff818ce000 [ 0.126181] RIP: 0010:[<ffffffff810513d1>] [<ffffffff810513d1>] native_set_pte+0x1/0x10 [ 0.134296] RSP: 0000:ffffffff818cfc80 EFLAGS: 00010287 [ 0.139609] RAX: 0000000000000000 RBX: ffffa3d0f0000000 RCX: 00003ffffffff000 [ 0.146744] RDX: ffff880000000000 RSI: 0000000000000000 RDI: ffffa3d0f0000000 [ 0.153879] RBP: ffffffff818cfcb8 R08: ffffea0010745d20 R09: 0000000000000000 [ 0.161013] R10: ffff88041f731fc0 R11: 000000000000001e R12: 0000000000200000 [ 0.168148] R13: 0000000000000000 R14: 0000000000400000 R15: ffff880000000008 [ 0.175288] FS: 0000000000000000(0000) GS:ffff88041f200000(0000) knlGS:0000000000000000 [ 0.183377] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.189125] CR2: ffffa3d0f0000000 CR3: 000000041e8da000 CR4: 00000000000406b0 [ 0.196264] Stack: [ 0.198283] ffffffff818cfcb8 ffffffff810561d7 ffff880000000008 0000000000400000 [ 0.205746] ffff880000001000 00000000000001ff ffff88041e8de000 ffffffff818cfd00 [ 0.213210] ffffffff8105644e 0000000000200000 0000000040000000 00000000ffffffff [ 0.220676] Call Trace: [ 0.223130] [<ffffffff810561d7>] ? unmap_pte_range+0x77/0x110 [ 0.228966] [<ffffffff8105644e>] unmap_pmd_range+0xde/0x210 [ 0.234630] [<ffffffff81056c6b>] __cpa_process_fault+0x48b/0x5e0 [ 0.240730] [<ffffffff81057276>] __change_page_attr_set_clr+0x4b6/0xb10 [ 0.247437] [<ffffffff810557c7>] ? __ioremap_caller+0x277/0x360 [ 0.253454] [<ffffffff810589f1>] kernel_map_pages_in_pgd+0x71/0xa0 [ 0.259736] [<ffffffff81a53361>] __map_region+0x45/0x63 [ 0.265051] [<ffffffff81a535cc>] efi_map_region_fixed+0xd/0xf [ 0.270886] [<ffffffff81a52f19>] efi_enter_virtual_mode+0x5a/0x3d9 [ 0.277162] [<ffffffff81a77516>] ? acpi_enable_subsystem+0x37/0x90 [ 0.283440] [<ffffffff81a36eb9>] start_kernel+0x386/0x41c [ 0.288931] [<ffffffff81a3693c>] ? repair_env_string+0x5c/0x5c [ 0.294852] [<ffffffff81a36120>] ? early_idt_handlers+0x120/0x120 [ 0.301035] [<ffffffff81a365ee>] x86_64_start_reservations+0x2a/0x2c [ 0.307479] [<ffffffff81a3672e>] x86_64_start_kernel+0x13e/0x14d [ 0.313572] Code: 66 2e 0f 1f 84 00 00 00 00 00 48 8b 46 18 55 48 89 e5 48 89 47 04 5d c3 66 90 55 48 89 e5 0f 01 f8 5d c3 0f 1f 8 [ 0.333545] RIP [<ffffffff810513d1>] native_set_pte+0x1/0x10 [ 0.339312] RSP <ffffffff818cfc80> [ 0.342807] CR2: ffffa3d0f0000000 [ 0.346141] ---[ end trace 86088f739725b8c6 ]--- [ 0.350760] Kernel panic - not syncing: Fatal exception Fix this by passing both efi_memmap and efi_memmap_hi to 2nd kernel. Reported-by: Linn Crosetto <linn@hp.com> Signed-off-by: Dave Young <dyoung@redhat.com> Tested-by: Linn Crosetto <linn@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-01-21Passing efi related data via setup_dataDave Young
For supporting efi runtime, several efi physical addresses fw_vendor, runtime, config tables, smbios and the whole runtime mapping info need to be used in kexec kernel. Thus introduce setup_data struct for passing these data. collect the varialbes from /sys/firmware/efi/systab and /sys/firmware/efi/runtime-map Signed-off-by: Dave Young <dyoung@redhat.com> Tested-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-01-21Add efi_info in x86 setup headerDave Young
For supporting efi runtime on kexec kernel we need to fill the efi_info struct in setup_header. I just get the info in kernel exported boot_params data in debugfs. Signed-off-by: Dave Young <dyoung@redhat.com> Tested-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2014-01-21Add function get_bootparamDave Young
Not only setup_subarch will get data from debugfs file boot_params/data, later code for adding efi_info will also need do same thing. Thus add a common function here for later use. Signed-off-by: Dave Young <dyoung@redhat.com> Tested-by: Toshi Kani <toshi.kani@hp.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-13Correct build failure in init_linux_parameters()Simon Horman
This fixes a build failure introduced by "kexec x86: drop truncation warning for crash kernel". Reported-by: CAI Qian <caiqian@redhat.com> Cc: Cliff Wickman <cpw@sgi.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec x86: drop truncation warning for crash kernelCliff Wickman
On kexec set-up of a crash kernel on a very large memory machine we sometimes see the worrisome warning: Too many memory ranges, truncating... meaning that the total count of e820 ram, reserved and ACPI spaces is over 128. Per the comment in do_bzImage_load(): /* If using bzImage for capture kernel, then we will not be * executing real mode code. setup segment can be loaded * anywhere as we will be just reading command line. */ So if I understand, the e820 table built here and added to the 'real_mode' area is not going to be used. So the warning message can be omitted. Signed-off-by: Cliff Wickman <cpw@sgi.com> [ horms@verge.net.au manually applied due to conflict ] Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec, x86: put ramdisk/cmd_line above 4G for 64bit bzImageYinghai Lu
We could put ramdisk/cmdline above for bzImage on 64bit for protocol 2.12. -v2: change ext_... handling to way that eric like. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-03-05kexec, x86: set booloader id in setup_headerYinghai Lu
set LOADER_TYPE_KEXEC Signed-off-by: Yinghai Lu <yinghai@kernel.org> Signed-off-by: Simon Horman <horms@verge.net.au>
2013-01-30kexec,x86: remove duplicate get_memory_rangesZhang Yanfei
At first, we have already filled the kexec_info.memory_ranges by calling my_load() -> get_memory_ranges(). So if we want to get the memory information, we could just use the existing one instead of calling get_memory_ranges again. Signed-off-by: Zhang Yanfei <zhangyanfei@cn.fujitsu.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2012-03-15Add generic debug optionCong Wang
Currently the debugging code is under #ifdef DEBUG, which means when we want to debug, we have to re-compile the source code with -DDEBUG. This is not convenient, we want to have a generic --debug option so that we can enable debugging code without re-compiling. This patch moves the arch-specific --debug to generic place and moves code under #ifdef DEBUG to --debug on x86. BTW, the size of kexec binary increases very little after this patch. Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2012-03-12i386: Don't print debug message when VESA framebuffer is loadedSimon Horman
This messages seems unnecessarily verbose. Reported-by: Maxim Kammerer <mk@dee.su> Signed-off-by: Simon Horman <horms@verge.net.au>
2011-04-18kexec, x86: fix kexec when boot_params.hardware_subarch != 0Chris Leech
Simon Horman <horms@...> writes: > > On Tue, Mar 29, 2011 at 09:04:53AM +0000, WANG Cong wrote: > > On Mon, 28 Mar 2011 14:50:11 -0700, Chris Leech wrote: > > > > > kexec needs to keep the subarch setting the same as the running kernel > > > in the boot parameters, or the kernel will die in early setup. I ran > > > into this with X86_SUBARCH_MRST, but it should apply to CE4100 and any > > > future subarch that uses non-default early setup code. > > > > > > This patch requires debugfs mounted at /sys/kernel/debug, as that's the > > > only way I know of to get at the running kernels boot_params. Without > > > debugfs mounted it falls back to the current behavior of assuming > > > subarch 0. > > > > > ... > > > > > > +#define BOOT_PARAMS_DBGFS "/sys/kernel/debug/boot_params/data" > > > > A minor issue here is that you are using a hard-coded debugfs path, > > debugfs can be also mounted to /debug too, so it is better that if we can > > search the path dynamically here. > > Do you think it would be better for the code to loop through > a few common alternatives for the path? > Not fully tested, but instead of looping through possible mount points maybe look through mtab in search of debugfs by fs type. Something like this? kexec, x86: search for debugfs mountpoint in /etc/mtab From: Chris Leech <christopher.leech@linux.intel.com> Signed-off-by: Chris Leech <christopher.leech@linux.intel.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2011-03-29kexec, x86: fix kexec when boot_params.hardware_subarch != 0Chris Leech
kexec needs to keep the subarch setting the same as the running kernel in the boot parameters, or the kernel will die in early setup. I ran into this with X86_SUBARCH_MRST, but it should apply to CE4100 and any future subarch that uses non-default early setup code. This patch requires debugfs mounted at /sys/kernel/debug, as that's the only way I know of to get at the running kernels boot_params. Without debugfs mounted it falls back to the current behavior of assuming subarch 0. Signed-off-by: Chris Leech <christopher.leech@linux.intel.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2010-02-02Consistently use signed char buffers throughoutSimon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2010-02-02i386: Remove unused kexec_flags parameter from setup_edd_info()Simon Horman
Signed-off-by: Simon Horman <horms@verge.net.au>
2008-05-28EDD fixBernhard Walle
This patch fixes EDD support where the BIOS reports a length lower than the actual length of raw_data in sysfs. That's no problem -- the check only needs to catch the case where the sysfs file is *smaller* than the BIOS reported length. Also add a newline at the end of the error message. The problem was introduced in 3bf0213789d56054f601c5a06372f78567aacdd9 by myself, the initial EDD implementation. Signed-off-by: Bernhard Walle <bwalle@suse.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2008-05-21Implement EDD support for 32 bit bootBernhard Walle
This patch implements EDD support. The information is read from /sys/firmware/edd (the edd driver must be loaded for this) and is written into the zero page of the 32 bit boot protocol. I successfully tested the patch on a x86_64 machine with the x86_64 kernel. This fixes a hardware detection problem, discovered in https://bugzilla.novell.com/show_bug.cgi?id=383210. The last patch that updates the E820MAX constant is required to use that patch. Signed-off-by: Bernhard Walle <bwalle@suse.de> Signed-off-by: Simon Horman <horms@verge.net.au>
2008-04-24<sys/mman.h> is not needed by any kexec/ source, at least on i386.Jamey Sharp
Other architectures also include sys/mman.h and likely don't need to, but I can't easily test that. Signed-off-by: Jamey Sharp <jamey@thetovacompany.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2008-03-06kexec: fix i386 EFI boot using efifbScott D. Davilla
Problem: kexec fails under i386 EFI boot for hardware that does not have a VGA bios or PC bios present. The EFI bootloader properly set the initial screen_info boot params but kexec assumes an orig_video_isVGA type of 1. This causes the kexec'd kernel assume the presence of both VGA bios and normal PC BIOS and starts probing which then panics somewhere I can't see because I have no console output nor serial ports. Solution: For EFI, efifb is a linear VGA framebuffer and can handle the kexec kernel switch, kexec just has to setup the kernel boot params properly. The below patch fixes this issue and allow a i386 EFI booted kernel with no VGA bios/PC bios to kexec to another kernel. Questions: Why is kexec assuming i386 x86 == VGA bios in the first place. The existing kernel has a perfectly good screen_info stucture that is an exported symbol by the kernel and could be accessed by kexec. Since kexec is just pretending to be a boot loader, why does it ignore information that the real bootloader (which knows a lot more about the hardware) has passed? The below patch just hacks in a trap for efifb and will fail in the future as other x86 hardware without VGA bios/PC bios become available. Signed-off-by: Scott D Davilla <davilla@4pi.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2008-02-20Kexec command line lengthNeil Horman
Fine, New patch attached. This patch does 5 things: 1) moves command line out of the zero page (struct bootparam) 2) extends command line length to support 2K command lines 3) adds a check to ensure that command line length is reasonably sized for new boot protocols 4) adds a check to ensure that command line length is reasonably sized for old boot protocols 5) imports variables from latest struct setup_header in kernel bootparams.h Incorporates simplified version checking for boot protocol and conservatively warns if the kernels boot protocol is below version 2.06 which is guaranteed to have 2K commandlines (even though some arches may have that support in older boot protocols) Neil Signed-off-by: Neil Horman <nhorman@tuxdriver.com> include/x86/x86-linux.h | 20 ++++++++++++++------ kexec/arch/i386/kexec-bzImage.c | 11 +++++++++++ kexec/arch/i386/x86-linux-setup.c | 3 ++- 3 files changed, 27 insertions(+), 7 deletions(-) Signed-off-by: Simon Horman <horms@verge.net.au>
2007-10-17Allow architectures to specify the location of /proc/iomemSimon Horman
On ia64 XEN it is sometimes neccessary to use an alternate location for the information that is usually provided by /proc/iomem. By having the path returned by a function, which can be overriden on a per-architecture basis, it is possible for ia64 XEN to make use of existing generic code. Hopefully other achitectures can use this infastructure as the need arises. If the machine parameter is zero, then iomem file relating to the currently running kernel should be returned. If the machine parameter is non-zero then iomem file, relating to the underlying hypervisor, should be returned. In the simple case, these will be the same file. Signed-off-by: Simon Horman <horms@verge.net.au> kexec/arch/i386/crashdump-x86.c | 4 ++-- kexec/arch/i386/kexec-x86.c | 2 +- kexec/arch/i386/x86-linux-setup.c | 2 +- kexec/arch/ia64/crashdump-ia64.c | 9 +++++---- kexec/arch/ia64/kexec-elf-ia64.c | 2 +- kexec/arch/ia64/kexec-ia64.c | 5 +++-- kexec/arch/ppc/kexec-ppc.c | 2 +- kexec/arch/s390/kexec-s390.c | 5 +++-- kexec/arch/x86_64/crashdump-x86_64.c | 10 +++++----- kexec/arch/x86_64/kexec-x86_64.c | 2 +- kexec/crashdump-xen.c | 6 ++++-- kexec/kexec-iomem.c | 31 +++++++++++++++++++++++-------- kexec/kexec.h | 6 +++--- 13 files changed, 53 insertions(+), 33 deletions(-) 9079040b40f643cfc9eb3d425dffa0ca8fd573e1
2007-05-10kexec rename dprintf to dbgprintfGeoff Levand
The recently introduce kexec debug routine dprintf clashes with an existing libc symbol. Rename dprintf to dbgprintf. Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2007-05-09use dprintfSimon Horman
Use the new fprintf macro where possible Cc: Geoff Levand <geoffrey.levand@am.sony.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2006-11-08kexec-tools: Support loading relocatable bzImageVivek Goyal
o Modify bzImage loader to be able to recognize a relocatable bzImage and load it. Now bzImage loader can identify that bzImage is relocatable and can load the protected mode kernel code at a non 1MB addr. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Simon Horman <horms@verge.net.au>
2006-07-27kexec & vesafbGerd Hoffmann
Hi, Attached is a patch which fills real_mode info correctly in case of vesafb being active, so the new kernel comes up with a working framebuffer console. cheers, Gerd
2006-07-27crashdump backup region handlingVivek Goyal
o This patch adds support for reserving space for backup region. Also adds code in purgatory to copy the first 640K to backup region. o Moved kexec_flags inside kexec_info structure. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Signed-off-by: Maneesh Soni <maneesh@in.ibm.com>
2006-07-27Fix the i386 old bios call compatibility.Eric W. Biederman
2006-07-27kexec-tools-1.101Eric W. Biederman
- Initial import into git - initial nbi image formage support - ppc32 initial register setting fixes. - gzipped multiboot file support
generated by cgit (git 2.34.1) at 2025-07-16 12:12:23 +0000