Re: [Fastboot] kexec supported on bookE?
kc nainwal kcnain...@gmail.com writes: Hi, Is kexec support available on ppc bookE architecture? I am interested in seeing how exactly identity mapping is implemented there as MMU translation can't be turned off. Please copy me, as I'm not part of the mailing list. I don't know about ppc bookE but on x86_64 where mmu cannot be turned off we setup an identity mapped page table with the larges pages available. I don't see why that would not work in general. Eric ___ fastboot mailing list fastboot@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/fastboot
Re: [Fastboot] kexec - 2.6.14 - loads BIOS again
Prabhakar K. krishka...@yahoo.com writes: Sending again as it is not posted yet !! I have back ported to multiple versions of different kexec-tools. Also I disabled watchdogs so that the first kernel reboot is not kicked in. Now, with all those kexec-tools I see that it hangs after post_verification_setup_arch( ). And I had to hard reboot the router box. Is there a specific kexec tools that is known to work with 2.6.14 ? Or any additional changes needed ? Almost certainly if you are getting as far as kexec-tools you are dying someplace early in your target kernel. Any inputs welcome , thanks in advance !! Please CC me in reply. Eric ___ fastboot mailing list fastboot@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/fastboot
Re: [Fastboot] vmcore file 0 size in x86_64
Chandan12 K chandan1...@tcs.com writes:
Hi,
I checked.. through and fond out that one of the following check condition is
failing
516 if (memcmp(ehdr.e_ident, ELFMAG, SELFMAG) != 0 ||
517 (ehdr.e_type != ET_CORE) ||
518 !vmcore_elf_check_arch(ehdr) ||
519 ehdr.e_ident[EI_CLASS] != ELFCLASS64 ||
520 ehdr.e_ident[EI_VERSION] != EV_CURRENT ||
521 ehdr.e_version != EV_CURRENT ||
522 ehdr.e_ehsize != sizeof(Elf64_Ehdr) ||
523 ehdr.e_phentsize != sizeof(Elf64_Phdr) ||
524 ehdr.e_phnum == 0) {
525 printk(KERN_WARNING Warning: Core image elf header is
not
526 sane:%ld\n,elfcorehdr_addr);
527 return -EINVAL
528 }
If I comment this return at line 527, then the code flows through and the
vmcore is getting generated.
However, I am facing a new issue, my user space is 32 bit and the kernel is 64
bit. And I want to access the high memory (high_memory - BACK_UP_SIZE) area of
the previous/primary kernel. Where some log data I had saved. The toral RAM is
8GB.
As the 32 bit pointers could not reach there... means simple file operations
lseek() , read etc are not working.. to access some region around 8GB.
Can you please suggest me some way to reach that memory and read my raw data
from the user space.
I am able to read the data from kernel space( a simple kernel module via /proc
interface to transfer the data from kernel to user space using physical
address
of the primary kernel).
Typically in user space that can be solved in a 32bit userspace
with FILE_OFFSET=64 or something like that.
There are 32bit syscalls that accept 64bit offsets to files.
Eric
___
fastboot mailing list
fastboot@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/fastboot
Re: [Fastboot] /var/log/messages doesn't have crash info when kernel gets panic/oops/crash
Dharmosoth Seetharam dseetha...@inbox.com writes: Hi, I have experimented few things and results are below. Case 1) echo 0 /proc/sys/kernel/panic_on_oops When BUG/oops occurred it is able to log the diagnostics to /var/log/messages and then continue(not switching to dump-saving kernel). What I am looking is - I want both the things to be happen. that is - it should log the appropriate messages in /var/log/messsages and should be able to take kernel dump. You can't have it. Sorry. Keeping user space alive is something that simply can not be done reliably. Please advice me, What we can do to achieve those things. The only scenario I see possible is to take the dump. Use makedumpfile or the crash log command to extract the kernel messages and put them in the /var/log/messages. Eric ___ fastboot mailing list fastboot@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/fastboot
Re: [Fastboot] /var/log/messages doesn't have crash info when kernel gets panic/oops/crash
Dharmosoth Seetharam dseetha...@inbox.com writes: Hi, I have experimented few things and results are below. Case 1) echo 0 /proc/sys/kernel/panic_on_oops When BUG/oops occurred it is able to log the diagnostics to /var/log/messages and then continue(not switching to dump-saving kernel). What I am looking is - I want both the things to be happen. that is - it should log the appropriate messages in /var/log/messsages and should be able to take kernel dump. You can't have it. Sorry. Keeping user space alive is something that simply can not be done reliably. Please advice me, What we can do to achieve those things. The only scenario I see possible is to take the dump. Use makedumpfile or the crash log command to extract the kernel messages and put them in the /var/log/messages. Eric ___ fastboot mailing list fastboot@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/fastboot
Re: [Fastboot] /var/log/messages doesn't have crash info when kernel gets panic/oops/crash
Dharmosoth Seetharam dseetha...@inbox.com writes: Basic questions. 1) Do you have panic on oops set? I think that setting more than anything else will be the difference in what shows up in /var/log/messages. Yes, in my case panic_on_oops was set with 1 That is the reason thing don't show up in /var/log/messages because you panic before syslog has a chance to write the messages. Thanks. So, if panic_on_oops set with 0(default), we will get all the needed info like stack traces, bug info etc. in /var/log/messages then reboots. Or do we need to apply any specific patches to get info in /var/log/messages? 2) Have you tried a dry run and confirmed you can get a crash dump? No, I haven't tried this. It sounds like you have not been getting the coredumps when problems happen. Running a simple test run to Alt-sysrq-c to confirm that things are basically setup ok is a good idea. Sorry, I misunderstood your question. I have gave dry run and confirmed that the dumps are getting saved in particular dir and able to analyze. I did in both the ways like 1 - echo c /proc/sysrq-trigger 2 -Alt -sysrq -c Then unless you are having problems capturing core dumps in real failure situations it sounds like all is well with the world. A kernel oops is normally not fatal and the kernel tries to limp along allowing for better diagnostics etc. This allows klogd to read the kernels message buffer and pass the kernel messages to syslog which writes the messages to /var/log/messages. After a kernel panic nothing is allowed to happen which prevents user space from writing to /var/log/messages in the usual way. If you want data in /var/log/messages it appears you have two choices. 1) Post process a core dump as Neil suggested and feed the kernel log buffer to syslog. 2) disable panic on oops. The system will continue to limp along allowing user space to write to /var/log/messages. Eric ___ fastboot mailing list fastboot@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/fastboot
Re: [Fastboot] correction to compat_sys_kexec_load
Sharyathi Nagesh [EMAIL PROTECTED] writes: Hi While testing with kexec tool, I observed some problems. When application (kexec) is 32 bit and kernel is 64 bit I observed that loading crash kernel works without any issues but unloading crash kernel fails. running strace over 'kexec -u -p' show the problem to be with sys_kexec_load() call sys_kexec_load(0, 0, 0, 0x1, 0) = -1 EINVAL (Invalid argument) write(2, kexec_load (0 segments) failed: ..., 49 kexec_load (0 segments) failed: Invalid argument ) = 4 Yes. This is a bug. Although not in the kernel implementation. This is patch to fix the problem, I think kernel code had a typo where in: if((flags KEXEC_ARCH_MASK) == KEXEC_ARCH) was used instead of if((flags KEXEC_ARCH_MASK) != KEXEC_ARCH) Nope. We do the latter check after we have fixed up the arguments and call sys_kexec_load. The check really is meant to filter out KEXEC_ARCH_DEFAULT. This patch takes care of that, I have tested the patch it worked fine for me. Please review the patch and let me know of your views. This patch is based on linux-2.6.26-rc3. That patch as it exists is actively bad. It removes the check for a really nasty gotcha if someone passes in KEXEC_ARCH_DEFAULT in 32bit mode. Code expecting a 32bit handoff and getting a 64bit handoff will explode in fun ways. You happened to test the one corner case where this does not matter. What we need to do is fix /sbin/kexec to pass in the correct architecture of the kernel for unload as it does for load. Eric ___ fastboot mailing list fastboot@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/fastboot
Re: [Fastboot] correction to compat_sys_kexec_load
Bernhard Walle [EMAIL PROTECTED] writes: * [EMAIL PROTECTED] (Eric W. Biederman) [2008-05-23 13:14]: What we need to do is fix /sbin/kexec to pass in the correct architecture of the kernel for unload as it does for load. How should it know that it unloads a 32 bit kernel on a 64 bit system? It doesn't have access to the kernel any more once it has been loaded. The architecture parameter is the architecture of the running kernel that implements sys_kexec_load. Because it is a pain for testing and in general impossible we don't change cpu modes during a kexec. So a 32bit caller of sys_kexec_load will need to passing in different code if it is running on a 32bit or a 64bit kernel. The trampoline code in /sbin/kexec does change modes on x86 when appropriate. Caring if you know the architecture in the unload case is a bit silly. As there is no real justification for it. At this point getting user space fixed so that it works on older kernels seems important. Eric ___ fastboot mailing list fastboot@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/fastboot
[Fastboot] Re: [PATCH 2/2] x86_64: Remove CONFIG_PHYSICAL_START and CONFIG_RELOCATABLE
Vivek Goyal [EMAIL PROTECTED] writes: On Sun, Apr 22, 2007 at 11:15:48PM -0600, Eric W. Biederman wrote: +++ b/arch/x86_64/Kconfig @@ -565,62 +565,9 @@ config CRASH_DUMP which are loaded in the main kernel with kexec-tools into a specially reserved region and then later executed after a crash by kdump/kexec. The crash dump kernel must be compiled - to a memory address not used by the main kernel or BIOS using - PHYSICAL_START. + to a memory address not used by the main kernel or BIOS For more details see Documentation/kdump/kdump.txt Hi Eric, I think must be compiled should be replaced with must be loaded now. Yes, that sounds right. Ugh. I didn't look at enough context to read the whole sentence. I just killed the part about PHYSICAL_START. Otherwise both the patches look fine. I am planning to test these. This change will also require modifications to Documentation/kdump/kdump.txt file. Do you think you can generate the patch fix up the CONFIG_CRASH_DUMP and kdump.txt documentation. I was just interested enough to spend the 15 minutes needed to generate this patch. I don't think I care enough to dot the i's and cross the t's in the documentation. Eric ___ fastboot mailing list fastboot@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/fastboot
[Fastboot] [PATCH 1/2] x86_64: Reflect the relocatability of the kernel in the ELF header.
Currently because vmlinux does not reflect that the kernel is relocatable
we still have to support CONFIG_PHYSICAL_START. So this patch adds a small
c program to do what we cannot do with a linker script, set the elf header
type to ET_DYN.
This should remove the last obstacle to removing CONFIG_PHYSICAL_START
on x86_64.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
arch/x86_64/Kconfig |4 +++
arch/x86_64/Makefile | 10 +++
scripts/Makefile | 11 ---
scripts/mketrel.c| 70 ++
4 files changed, 90 insertions(+), 5 deletions(-)
create mode 100644 scripts/mketrel.c
diff --git a/arch/x86_64/Kconfig b/arch/x86_64/Kconfig
index 16d9bf3..773b487 100644
--- a/arch/x86_64/Kconfig
+++ b/arch/x86_64/Kconfig
@@ -121,6 +121,10 @@ config ARCH_HAS_ILOG2_U64
bool
default n
+config ELF_RELOCATABLE
+ bool
+ default y
+
source init/Kconfig
diff --git a/arch/x86_64/Makefile b/arch/x86_64/Makefile
index 9dd91b2..5ae79ab 100644
--- a/arch/x86_64/Makefile
+++ b/arch/x86_64/Makefile
@@ -124,6 +124,16 @@ define archhelp
echo ' isoimage - Create a boot CD-ROM image'
endef
+ifeq ($(CONFIG_RELOCATABLE),y)
+define cmd_vmlinux__
+ $(LD) $(LDFLAGS) $(LDFLAGS_vmlinux) -o $@ \
+ -T $(vmlinux-lds) $(vmlinux-init)\
+ --start-group $(vmlinux-main) --end-group\
+ $(filter-out $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) FORCE ,$^) \
+ scripts/mketrel $@
+endef
+endif
+
CLEAN_FILES += arch/$(ARCH)/boot/fdimage \
arch/$(ARCH)/boot/image.iso \
arch/$(ARCH)/boot/mtools.conf
diff --git a/scripts/Makefile b/scripts/Makefile
index 1c73c5a..ddba550 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -7,11 +7,12 @@
# conmakehash: Create chartable
# conmakehash: Create arrays for initializing the kernel console tables
-hostprogs-$(CONFIG_KALLSYMS) += kallsyms
-hostprogs-$(CONFIG_LOGO) += pnmtologo
-hostprogs-$(CONFIG_VT) += conmakehash
-hostprogs-$(CONFIG_PROM_CONSOLE) += conmakehash
-hostprogs-$(CONFIG_IKCONFIG) += bin2c
+hostprogs-$(CONFIG_KALLSYMS)+= kallsyms
+hostprogs-$(CONFIG_LOGO)+= pnmtologo
+hostprogs-$(CONFIG_VT) += conmakehash
+hostprogs-$(CONFIG_PROM_CONSOLE)+= conmakehash
+hostprogs-$(CONFIG_IKCONFIG)+= bin2c
+hostprogs-$(CONFIG_ELF_RELOCATABLE) += mketrel
always := $(hostprogs-y) $(hostprogs-m)
diff --git a/scripts/mketrel.c b/scripts/mketrel.c
new file mode 100644
index 000..effa312
--- /dev/null
+++ b/scripts/mketrel.c
@@ -0,0 +1,70 @@
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include unistd.h
+#include elf.h
+#include stdio.h
+#include errno.h
+#include string.h
+#include stdarg.h
+#include stdlib.h
+
+static int fd;
+unsigned char e_ident[EI_NIDENT];
+
+void die(const char * str, ...)
+{
+ va_list args;
+ va_start(args, str);
+ vfprintf(stderr, str, args);
+ fputc('\n', stderr);
+ exit(1);
+}
+
+void file_open(const char *name)
+{
+ if ((fd = open(name, O_RDWR, 0)) 0)
+ die(Unable to open `%s': %m, name);
+}
+
+static void mketrel(void)
+{
+ unsigned char e_type[2];
+ if (read(fd, e_ident, sizeof(e_ident)) != sizeof(e_ident))
+ die(Cannot read ELF header: %s\n, strerror(errno));
+
+ if (memcmp(e_ident, ELFMAG, 4) != 0)
+ die(No ELF magic\n);
+
+ if ((e_ident[EI_CLASS] != ELFCLASS64)
+ (e_ident[EI_CLASS] != ELFCLASS32))
+ die(Unrecognized ELF class: %x\n, e_ident[EI_CLASS]);
+
+ if ((e_ident[EI_DATA] != ELFDATA2LSB)
+ (e_ident[EI_DATA] != ELFDATA2MSB))
+ die(Unrecognized ELF data encoding: %x\n, e_ident[EI_DATA]);
+
+ if (e_ident[EI_VERSION] != EV_CURRENT)
+ die(Unknown ELF version: %d\n, e_ident[EI_VERSION]);
+
+ if (e_ident[EI_DATA] == ELFDATA2LSB) {
+ e_type[0] = ET_REL 0xff;
+ e_type[1] = ET_REL 8;
+ } else {
+ e_type[1] = ET_REL 0xff;
+ e_type[0] = ET_REL 8;
+ }
+
+ if (write(fd, e_type, sizeof(e_type)) != sizeof(e_type))
+ die(Cannot write ELF type: %s\n, strerror(errno));
+}
+
+int main(int argc, char **argv)
+{
+ if (argc != 2)
+ die(Usage: mketrel: vmlinux);
+ file_open(argv[1]);
+ mketrel();
+ close(fd);
+ return 0;
+}
--
1.5.1.1.181.g2de0
___
fastboot mailing list
fastboot@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/fastboot
Re: [Fastboot] kexec cant load OpenBSD
Vivek Goyal [EMAIL PROTECTED] writes: On Thu, Apr 19, 2007 at 03:49:46PM -0400, Jon Steel wrote: Hi Im running Gentoo and Im trying to use kexec to start up OpenBSD. I've got it set up correct because I can do a boot into Gentoo. Here is what happens: base ~ # kexec -l /boot/bsd --type=elf-x86 Base address: d0200120 is not page aligned Above address indicates that some loadable program segment is not page size(4K) aligned hence kexec is cribbing. A, readelf -l /boot/bsd should display the various program headers. I think you shall have to modify linker script of OpenBSD kernel to generate page size aligned loadable segments. This does raise a question in my mind, why all the program headers should be loaded at page size boundaries? Just because ease of handling or there is some other reason too? Eric, you want to shed some light on this requirement? A) The first problem is that we don't currently have support for OpenBSD and it does some weird things, and doesn't quite use the ELF fields generically. So specific support will have to be written for at least part of it. B) In the kernel side of the interface the page alignment restriction is important because of how our intermediate buffers work. For user space ELF the page alignment of program segments is an important consideration to allow page sharing but for standalone executables we really shouldn't care and the restriction probably only exists because we have a simple translation from ELF segment to the kernel segments. Eric ___ fastboot mailing list fastboot@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/fastboot
