http://blog.gmane.org/gmane.linux.kernel.kexec hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.linux.kernel.kexec/6139 <pre>Hi, I've been chasing strange problem with kdump kernel. It was crashing on boot without any messages to the console. Finally I found that kdump kernel command line was corrupt. Digging down I found the problem in setup_edd_info() and add_edd_entry(). It doesn't check for array size of real_mode-&gt;eddbuf[] and real_mode-&gt;edd_mbr_sig_buffer[] So when it overruns eddbuf[] it corrupts command_line that follows it. Here is the fix: --- a/kexec-tools/kexec/arch/i386/x86-linux-setup.c +++ b/kexec-tools/kexec/arch/i386/x86-linux-setup.c &lt; at &gt;&lt; at &gt; -275,9 +275,9 &lt; at &gt;&lt; at &gt; static int add_edd_entry(struct x86_linux_param_header *real_mode, "must not be NULL", __FUNCTION__); return -1; } - - edd_info = &amp;real_mode-&gt;eddbuf[*current_edd]; - memset(edd_info, 0, sizeof(struct edd_info)); + if (*current_mbr &gt;= EDD_MBR_SIG_MAX) { + return 0; + } /* extract the device number */ if (sscanf(basename(sysfs_name), "int13_dev%h</pre> Dmitry Trikoz 2012-05-24T17:26:51 http://comments.gmane.org/gmane.linux.kernel.kexec/6132 <pre>While trying to port kexec cleanly to klibc, came across this syscall usage for reboot(2). Calling reboot directly simplifies the code. Signed-off-by: maximilian attems &lt;max-U9r9yeDMy7A&lt; at &gt;public.gmane.org&gt; --- kexec/kexec-syscall.h | 18 ------------------ kexec/kexec.c | 3 ++- 2 files changed, 2 insertions(+), 19 deletions(-) v2: keep LINUX_REBOOT_CMD_KEXEC defines, thus no need of &lt;linux/reboot.h&gt;. (The packagers don't like linux header deps..) The next TODO item is to add proper syscall kexec_load() to glibc. Funnily here klibc has an head start! -maks diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h index f4df45c..b56cb00 100644 --- a/kexec/kexec-syscall.h +++ b/kexec/kexec-syscall.h &lt; at &gt;&lt; at &gt; -5,18 +5,6 &lt; at &gt;&lt; at &gt; #include &lt;sys/syscall.h&gt; #include &lt;unistd.h&gt; -#defineLINUX_REBOOT_MAGIC10xfee1dead -#defineLINUX_REBOOT_MAGIC2672274793 -#defineLINUX_REBOOT_MAGIC2A85072278 -#defineLINUX_REBOOT_MAGIC2B369367448 - -#defineLINUX_REBOOT_CMD_RESTART0x01234567 -#defineLINUX_REBOOT_CM</pre> maximilian attems 2012-05-22T16:59:47 http://comments.gmane.org/gmane.linux.kernel.kexec/6131 <pre>While trying to port kexec cleanly to klibc, came across this syscall usage for reboot(2). Calling reboot directly simplifies the code. Signed-off-by: maximilian attems &lt;max-U9r9yeDMy7A&lt; at &gt;public.gmane.org&gt; --- kexec/kexec-syscall.h | 20 -------------------- kexec/kexec.c | 4 +++- 2 files changed, 3 insertions(+), 21 deletions(-) The next TODO item is to add proper syscall kexec_load() to glibc. Funnily here klibc has an head start! -maks diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h index f4df45c..415fbd7 100644 --- a/kexec/kexec-syscall.h +++ b/kexec/kexec-syscall.h &lt; at &gt;&lt; at &gt; -5,22 +5,6 &lt; at &gt;&lt; at &gt; #include &lt;sys/syscall.h&gt; #include &lt;unistd.h&gt; -#defineLINUX_REBOOT_MAGIC10xfee1dead -#defineLINUX_REBOOT_MAGIC2672274793 -#defineLINUX_REBOOT_MAGIC2A85072278 -#defineLINUX_REBOOT_MAGIC2B369367448 - -#defineLINUX_REBOOT_CMD_RESTART0x01234567 -#defineLINUX_REBOOT_CMD_HALT0xCDEF0123 -#defineLINUX_REBOOT_CMD_CAD_ON0x89ABCDEF -#defineLINUX_REBOOT_CMD_CAD_OFF0x00000000 -#defineLINUX_</pre> maximilian attems 2012-05-22T16:09:58 http://comments.gmane.org/gmane.linux.kernel.kexec/6120 <pre>Subject: [PATCH] Use HOSTCC for build utilities bin-to-hex is used during the build and needs to be compiled with the host compiler to be able to run during the build. Signed-off-by: Baruch Even &lt;baruch-6P1Dz+XQpLLYtjvyW6yDsg&lt; at &gt;public.gmane.org&gt; --- util/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/util/Makefile b/util/Makefile index 948ee63..82c7407 100644 --- a/util/Makefile +++ b/util/Makefile &lt; at &gt;&lt; at &gt; -4,8 +4,8 &lt; at &gt;&lt; at &gt; $(BIN_TO_HEX): $(srcdir)/util/bin-to-hex.c &lt; at &gt;$(MKDIR) -p $(&lt; at &gt;D) $(LINK.o) $(CFLAGS) -o $&lt; at &gt; $^ -$(BIN_TO_HEX): CC=$(BUILD_CC) -$(BIN_TO_HEX): CFLAGS=$(BUILD_CFLAGS) +$(BIN_TO_HEX): CC=$(HOSTCC) +$(BIN_TO_HEX): CFLAGS=$(HOST_CFLAGS) $(BIN_TO_HEX): LDFLAGS= dist += util/Makefile util/bin-to-hex.c </pre> Baruch Even 2012-05-20T00:00:05 http://comments.gmane.org/gmane.linux.kernel.kexec/6119 <pre>Your Mailbox Is Almost Full "CLICK HERE&lt;https://docs.google.com/spreadsheet/viewform?formkey=dE1tZWZNRzVyalFmbG9JOUNERzF5enc6MQ&gt;" Update Your MailBox And Increase Your Account. Thanks System Administrator. </pre> Cerda, Weston 2012-05-18T07:33:42 http://comments.gmane.org/gmane.linux.kernel.kexec/6103 <pre>From: Cong Wang &lt;xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; From: Cong Wang &lt;xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; V2: Fix a compile error Like commit 28d4ab53280853d2aeefdfb7c369331e89ab9ac2 ("Add generic debug option"), this one moves code under #if DEBUG to --debug on ppc arch. Sorry that I still can't find a ppc32 machine to test this. Cc: Simon Horman &lt;horms-/R6kz+dDXgpPR4JQBCEnsQ&lt; at &gt;public.gmane.org&gt; Signed-off-by: Cong Wang &lt;xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; --- kexec/arch/ppc/crashdump-powerpc.c | 18 ++++++++---------- kexec/arch/ppc/fixup_dtb.c | 32 ++++++++++++++------------------ kexec/arch/ppc/fs2dt.c | 6 +++--- kexec/arch/ppc/kexec-ppc.c | 17 ++++++++--------- kexec/arch/ppc/libfdt-wrapper.c | 4 ++-- kexec/arch/ppc64/crashdump-ppc64.c | 16 ++++++---------- kexec/arch/ppc64/kexec-elf-ppc64.c | 23 +++++++++++------------ kexec/arch/ppc64/kexec-ppc64.c | 9 +++------ 8 files changed,</pre> Cong Wang 2012-05-14T06:34:56 http://comments.gmane.org/gmane.linux.kernel.kexec/6093 <pre>Hello, I am trying to run kexec into the RHEL62 kickstart installer from a RHEL62 LiveCD. It works most of the time, but sometimes it fails with a kernel crash stack. The last message before the crash is always: "Trying to unpack rootfs image as initramfs...." Below is a sample stack from the crash. Does any one have any clues on tracking down this issue? Cheers, Ivan BUG: soft lockup - CPU#0 stuck for 67s! [swapper:1] Modules linked in: CPU 0 Modules linked in: Pid: 1, comm: swapper Not tainted 2.6.32-220.el6.x86_64 #1 EMC S2600GZ/S2600GZ RIP: 0010:[&lt;ffffffff81c4c8d8&gt;] [&lt;ffffffff81c4c8d8&gt;] rc_get_bit+0x6/0x79 RSP: 0018:ffff88102ceadce8 EFLAGS: 00000246 RAX: 0000000000000007 RBX: ffff88102ceadcf0 RCX: 0000000000000000 RDX: ffff88102ceaddfc RSI: ffffc90016e47686 RDI: ffff88102ceaddb0 RBP: ffffffff8100bc0e R08: ffffc90016e47678 R09: 0000000000000003 R10: 0000000000000003 R11: 0000000000000000 R12: 0000000004000605 R13: 000000000acff908 R14: ffffc90016e47644 R15: 0000000000000003 FS: 000000000000</pre> Ivan.Novick-mb1K0bWo544< at >public.gmane.org 2012-05-10T20:12:11 http://comments.gmane.org/gmane.linux.kernel.kexec/6092 <pre>I would like to discuss a project with you.Please email me back.via gaddafisaadi-dbdLmdGazhY&lt; at &gt;public.gmane.org if interested </pre> Contact 2012-05-10T09:28:50 http://comments.gmane.org/gmane.linux.kernel.kexec/6081 <pre>Attn, We are grateful to contact you and announce to you that your e-mail was among the listed beneficiary that won our western union on-line award. Contact us upon receipt of this mail with the requested information below to enable us file your information to your location country payment zone: 1*First Name :........... 2*Last Name :.............. 3*Gender :.......... 4*Occupation:......... 5*Home Telephone Number :............... 6*Mobile Telephone Number :.............. 7*State :.......... 8*Country :...................... 9*Age:................... Once again congratulation, and have a nice day. NOTE: Due to poor network service HERE,You may receive this Notification as junk/spam Name: Manager Mr Christopher Roland Tel: +2348071169011 western.union.money.trasfer.westafrica-FmXjaEvEckLQT0dZR+AlfA&lt; at &gt;public.gmane.org ©2012- Western Union Holdings </pre> Western Union Money Transfer 2012-04-28T21:22:06 http://comments.gmane.org/gmane.linux.kernel.kexec/6076 <pre>Hello Kumagai-san, Do you have an idea of the availability of makedumpfile for 3.2 flavor kernels ? Ubuntu 12.04 Precise have just been released today and, since it is based on a 3.2 kernel, makedumpfile no longer works for it. Kind regards, ...Louis </pre> Bouchard Louis 2012-04-26T20:27:31 http://comments.gmane.org/gmane.linux.kernel.kexec/6075 <pre>Eric suggested I disable bus master bit in PCI susbsystem instead and that makes perfect sense. So here is take 2 on this patch. Please review and let me know if I missed anything. Subject: [PATCH] Disable Bus Master bit on the device in pci_device_shutdown() to ensure PCI devices do not 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 &lt;khalid.aziz-VXdhtT5mjnY&lt; at &gt;public.gmane.org&gt; --- drivers/pci/pci-driver.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index 6b54b23..9db5940 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c &lt; at &gt;&lt; at &gt; -420,6 +420,12 &lt; at &gt;&lt; at &gt; static void pci_device_shutdown(struct device *dev) pci_msi_shutdown(pci_dev); pci_msix_shutdown(pci_dev); +/*</pre> Khalid Aziz 2012-04-26T18:30:42 http://comments.gmane.org/gmane.linux.kernel.kexec/6069 <pre>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 &lt;khalid.aziz-VXdhtT5mjnY&lt; at &gt;public.gmane.org&gt; --- kexec/kexec.8 | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/kexec/kexec.8 b/kexec/kexec.8 index da03c40..aff674c 100644 --- a/kexec/kexec.8 +++ b/kexec/kexec.8 &lt; at &gt;&lt; at &gt; -71,7 +71,7 &lt; at &gt;&lt; at &gt; It's also possible to invoke .B kexec without an option parameter. In that case, kexec loads the specified kernel and then invokes -.BR shutdown (1). +.BR shutdown (8). If the shutdown scripts of your Linux distribution support kexec-based rebooting, they then call .B kexec &lt; at &gt;&lt; at &gt; -105,13 +105,13 &lt; at &gt;&lt; at &gt; command: .SH OPTIONS .TP .B \-e\ (\-\-exec) -Run the currently loaded kernel. +Run the currently loaded kernel. Note that it will reboot into the loaded kernel w</pre> Khalid Aziz 2012-04-20T16:39:14 http://comments.gmane.org/gmane.linux.kernel.kexec/6067 <pre>Instead of calulating the CRC on the whole file just calculate the CRC on the actual uImage length as given by the uImage header. This fixes loading padded uImages, for example from a mtd partition. Signed-off-by: Helmut Schaa &lt;helmut.schaa-gM/Ye1E23mwN+BqQ9rBEUg&lt; at &gt;public.gmane.org&gt; --- kexec/kexec-uImage.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/kexec/kexec-uImage.c b/kexec/kexec-uImage.c index 409e516..83e7910 100644 --- a/kexec/kexec-uImage.c +++ b/kexec/kexec-uImage.c &lt; at &gt;&lt; at &gt; -72,7 +72,7 &lt; at &gt;&lt; at &gt; int uImage_probe(const unsigned char *buf, off_t len, unsigned int arch) return -1; } #ifdef HAVE_LIBZ -crc = crc32(0, (void *)buf + sizeof(header), len - sizeof(header)); +crc = crc32(0, (void *)buf + sizeof(header), be32_to_cpu(header.ih_size)); if (crc != be32_to_cpu(header.ih_dcrc)) { printf("The data CRC does not match. Computed: %08x " "expected %08x\n", crc, </pre> Helmut Schaa 2012-04-20T09:58:16 http://comments.gmane.org/gmane.linux.kernel.kexec/6039 <pre> Dear Sir/Madam ---------------------------------------------------------------------------------------- ____________________________AVISO LEGAL_______________________________ Este mensaje es privado y confidencial, y esta dirigido exclusivamente a su(s) destinatario(s). Si usted ha recibido este mensaje por error, debe abstenerse de distribuirlo, copiarlo o usarlo en cualquier sentido. Asi mismo, le agradecemos comunicarlo al remitente y borrar el mensaje y cualquier documento adjunto. Cualquier opinión contenida en este mensaje pertenece unicamente al autor remitente y no representa necesariamente la opinión del Ministerio del Poder Popular del Despacho de la Presidencia, a menos que ello se señale en forma expresa. Eventualmente, los correos electronicos pueden ser interceptados o alterados, llegar con demora o incompletos. Al respecto, el Ministerio del Poder Popular del Despacho de la Presidencia no se hace responsable por los errores, defectos u omisiones que pudieran afectar al mensaje orig</pre> Nasy Merly Ysea 2012-04-14T04:02:37 http://comments.gmane.org/gmane.linux.kernel.kexec/6038 <pre>In the past, we did neglected some usable memory range changing infos. With those deubg code added, we can now catch them. --- kexec/arch/ppc64/crashdump-ppc64.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/kexec/arch/ppc64/crashdump-ppc64.c b/kexec/arch/ppc64/crashdump-ppc64.c index d52b438..b5ec2c8 100644 --- a/kexec/arch/ppc64/crashdump-ppc64.c +++ b/kexec/arch/ppc64/crashdump-ppc64.c &lt; at &gt;&lt; at &gt; -465,12 +465,24 &lt; at &gt;&lt; at &gt; void add_usable_mem_rgns(unsigned long long base, unsigned long long size) if (base &lt; ustart &amp;&amp; end &gt; uend) { usablemem_rgns.ranges[i].start = base; usablemem_rgns.ranges[i].end = end; +#ifdef DEBUG +fprintf(stderr, "usable memory rgn %u: new base:%llx new size:%llx\n", +i, base, size); +#endif return; } else if (base &lt; ustart) { usablemem_rgns.ranges[i].start = base; +#ifdef DEBUG +fprintf(stderr, "usable memory rgn %u: new base:%llx new size:%llx", +i, base, usablemem_rgns.ranges[i].end - base); +#endif return;</pre> Han Pingtian 2012-04-13T09:32:42 http://comments.gmane.org/gmane.linux.kernel.kexec/6014 <pre>Tu email ha ganado £375.000 </pre> ©2012 Microsoft 2012-04-06T20:15:01 http://comments.gmane.org/gmane.linux.kernel.kexec/5994 <pre> RS LOANS is now providing financial services &amp; loans . Are you a business man or woman ? Do you need a loan or funding for any reason such as : Personal Loan,Business Expansion, Business Start-up,Education, Hard Money Loans, Investment Loans, etc. For more information, inquiries and Application, Please Contact our representative via this e-mail: jan737.b-j+4cLNCRU+OzR313v1King&lt; at &gt;public.gmane.org </pre> jan737.b-j+4cLNCRU+OzR313v1King< at >public.gmane.org 2012-03-29T16:48:25 http://comments.gmane.org/gmane.linux.kernel.kexec/5987 <pre>Hello Ken'ichi-san, I was talking to Vivek about kdump memory requirements and he mentioned that they vary based on how much system memory is used. I was interested in knowing why that was and again he mentioned that makedumpfile needed lots of memory if it was running on a large machine (for example 1TB of system memory). Looking through the makedumpfile README and using what Vivek remembered of makedumpfile, we gathered that as the number of pages grows, the more makedumpfile has to temporarily store the information in memory. The possible reason was to calculate the size of the file before it was copied to its final destination? I was curious if that was true and if it was, would it be possible to only process memory in chunks instead of all at once. The idea is that a machine with 4Gigs of memory should consume the same the amount of kdump runtime memory as a 1TB memory system. Just trying to research ways to keep the memory requirements consistent across all memory ranges. Thanks, Don </pre> Don Zickus 2012-03-28T21:22:04 http://comments.gmane.org/gmane.linux.kernel.kexec/5986 <pre>kexec-tools package for debian includes a patch that adds a more descriptive error message when someone tries to laod a crash kernel and didn't remember to boot up with crashkernel= parameter. This patch would be of general interest. This patch was originally written by Alastair McKinstry. Please apply. Signed-off-by: Khalid Aziz &lt;khalid.aziz-VXdhtT5mjnY&lt; at &gt;public.gmane.org&gt; --- 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-x86.c b/kexec/arch/i386/crashdump-x86.c index 590c883..2af090c 100644 --- a/kexec/arch/i386/crashdump-x86.c +++ b/kexec/arch/i386/crashdump-x86.c &lt; at &gt;&lt; at &gt; -776,7 +776,9 &lt; at &gt;&lt; at &gt; int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline, memset(memmap_p, 0, sz); add_memmap(memmap_p, info-&gt;backup_src_start, info-&gt;backup_src_size); sz = crash_reserved_mem.end - crash_reserved_mem.sta</pre> Khalid Aziz 2012-03-28T19:09:02 http://comments.gmane.org/gmane.linux.kernel.kexec/5985 <pre>Thanks Luc. We will let you know if in case we need any info/help. I am also forwarding this mail to kexec mailing list. Regards, Aravinda -------- Original Message -------- Subject: RE: Fwd: Re: makedumpfile security key enhancement using SIAL Date: Wed, 28 Mar 2012 07:07:49 -0400 From: Luc Chouinard &lt;LChouinard-NWkMez96xTsAvxtiuMwx3w&lt; at &gt;public.gmane.org&gt; To: Aravinda Prasad &lt;aravinda-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8&lt; at &gt;public.gmane.org&gt; Libsial is meant to be a pluggable entity and as such should not require other pieces to be there ( crash or gdb). I want to create project and associated git for the library soon. For now you can extract libsial from the crash tar ball and manage any modifications using a simple patch mechanism. When the git is available, we can merge any fixes or enhancements you created for support of makedumpfile. Makedumpfile and crash would then feed off of specific branches/versions of the git repository. If you have any suggestions or want to help in setting up a public git </pre> Aravinda Prasad 2012-03-28T17:00:59 http://comments.gmane.org/gmane.linux.kernel.kexec/5979 <pre>Hello xxxxx, How are you doing over there? My name is Laura, Please let me know if i got the right address so we can open communication, here is my email address I am waiting for your confirmation with care Laura... </pre> laurarey111-PkbjNfxxIARBDgjK7y7TUQ< at >public.gmane.org 2012-03-27T12:57:03 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.kernel.kexec