An UNTESTED patch for kexec for 2.5.74 is now available. I get a BUG at mm/slab.c:1537 when I "init 1", so I haven't been able to test this patch (more info here: LKML).
This patch set is based upon the stable 2.5.{67,68,69,7*} versions. A unstable set of kexec patches for 2.5.69 from Eric Biederman is available here.
Did I mention that it was untested? I'll be away at pdxlan.com for a few days and not responding to email.
The individual patch (I didn't split it this time) is available here: kexec-2.5.74-full.patch
The matching user-mode utility required to invoke kexec: kexec-tools-1.8-2.5.74.tgz
Patches for previous versions of many 2.5.x kernels are available here: kexec archives.
A PDF-format whitepaper on kexec is available: Reducing System Reboot Time With kexec. A badly-mangled HTML version is also available.
If you are interested in trying out kexec, please feel free to report your successes and failures to fastboot@osdl.org.
If you've tried kexec, and had problems that seem to be related to your e100 driver (hangs, card won't initialize, etc.), you might check your config and see if CONFIG_PM=y. If so, try turning off CONFIG_PM, or try the old eepro100 driver.
There's a bit more info in this thread: LKML Archive.
Here's another bug fix for kexec for 2.5.73 that you may want to apply. The problem was seen on a 4-way P4-1.5GHz Xeon system (8x with hyperthreading) and with 4GB of memory.
The symptom was an oops in kimage_alloc_reboot_code_pages(). The cause (at least for the machine in question) is that the memory being allocated for the special reboot code buffer was being allocated from high memory.
That didn't work too well. The fix is small: Download: kexec2-2.5.73-fix2.patch
The full kexec patch for 2.5.73 with both recent bug fixes applied is also available. Download: kexec2-2.5.73-full-rev2.patch
Okay, that should do it. I have found and repaired all of the misdirected relative links, restored the modified times of the data files used by my script to generate HTML, and re-run the generator.
This content is in the process of being moved from http://www.osdl.org/archive/andyp/bloom/ to http://developer.osdl.org/~andyp/bloom/
Until I update the relative links in all of my old articles to reflect the change from /archive/andyp/ to ~andyp/, I am certain that there will be broken links.
Maybe I can write a script that will capture the current modified times of the files in question, allow me to edit them, and then set the modified times back to what they were... I'll explain later...
There is a tiny bugfix patch for kexec for 2.5.73 you might want to apply. Thanks Pat.
Download: kexec2-2.5.73-bugfix.patch
A patch set for kexec for 2.5.73 is now available. This patch set is based upon the stable 2.5.{67,68,69,70,71,72} versions. A unstable set of kexec patches for 2.5.69 from Eric Biederman is available here.
This patch was tested to work on a dual P4-1.7GHz Xeon system, a uniprocessor P3-800 system, and a dual P3-866 system. I continue to observe strangeness with the re-initialization of the VESA framebuffer (character-based console TTY worked correctly), a kernel oops on a 4-way in the 2.5.72 version while preparing the reboot memory buffer, and a hang when using the serial console (RS232).
The stable patches for 2.5.73 are available for download from OSDL's patch life-cycle manager (PLM) in pieces, or as a single unified patch.
The individual patches:
| URL | Comments |
|---|---|
| kexec-2.5.73-common | generic kexec code |
| kexec-2.5.73-x86 | x86 (PC) architecture implementation |
| kexec-2.5.73-syscall | syscall number changes |
| kexec-2.5.73-defconfig | enable CONFIG_KEXEC by default |
Or, kexec is available as a single unified patch: kexec-2.5.73-full. You do not need the full patch if you intend to use the patch pieces listed above.
The matching user-mode utility required to invoke kexec: kexec-tools-1.8-2.5.73.tgz
Patches for previous versions of many 2.5.x kernels are available here: kexec archives.
A PDF-format whitepaper on kexec is available: Reducing System Reboot Time With kexec. A badly-mangled HTML version is also available.
If you are interested in trying out kexec, please feel free to report your successes and failures to fastboot@osdl.org.
It's still happening in 2.5.73 on one of my systems. The workaround that worked for me is to add "clock=pit" to the kernel command line. A patch that I will be trying out that may also work: bug #827. [ LKML thread ].
I've got a strange thing happening on one of my 2.5.72 machines. Wall-clock time is advancing too rapidly. Roughly, 26 seconds every 60 seconds:
# ntpdate ntp ; sleep 60 ; ntpdate ntp 19 Jun 11:06:22 ntpdate[3978]: step time server 172.20.1.28 offset -4874.776850 sec 19 Jun 11:06:55 ntpdate[3980]: step time server 172.20.1.28 offset -26.742307 sec #
"ntp" is our local NTP server. Strange.
A lightly tested patch for kexec for 2.5.72-mm1 is now available. This patch set is based upon the stable 2.5.72 version.
This patch was tested to work on a dual-processor P4-1.7GHz Xeon system. As in the 2.5.72 release, I observed that my VESA framebuffer driver did not reinitialize correctly after kexec-ing a new kernel.
The kexec patch for 2.5.72-mm1 is available here: kexec-2.5.72-mm1-full.patch
The source for the matching user-mode utility is available here: kexec-tools-1.8-2.5.72-mm1.tgz
Patches for previous versions of many 2.5.x kernels are available here: kexec archives.
A PDF-format whitepaper on kexec is available: Reducing System Reboot Time With kexec. A badly-mangled HTML version is also available.
If you are interested in trying out kexec, please feel free to report your successes and failures to fastboot@osdl.org.
I'm still not sure I agree with the fix from A. Morton:
Date: Fri, 13 Jun 2003 01:01:49 -0700
From: Andrew Morton <akpm@digeo.com>
To: Andy Pfiffer <andyp@osdl.org>
Cc: christophe@saout.de, adam@yggdrasil.com, linux-kernel@vger.kernel.org, ...
Subject: Re: ext[23]/lilo/2.5.{68,69,70} -- blkdev_put() problem?
This should fix it.
Once the blockdev inode for /dev/ram0 is dirtied we have a memory-backed
inode on the blockdev superblock's s_dirty list.
sync_sb_inodes() sees the memory-backed inode on the superblock and assumes
that all the other inodes on the superblock are also memory-backed. This is
not true for the blockdev superblock! We forget to write out dirty pages
against the following blockdevs.
Fix this by just leaving the inode dirty and moving on to inspect the other
blockdev inodes on sb->s_io.
(This is a little inefficient: an alternative is to leave dirtied
memory-backed inodes on inode_in_use, so nobody ever even considers them for
writeout. But that introduces an inconsistency and is a bit kludgey).
fs/fs-writeback.c | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletion(-)
diff -puN fs/fs-writeback.c~writeback-memory-backed-fix fs/fs-writeback.c
--- 25/fs/fs-writeback.c~writeback-memory-backed-fix 2003-06-12 23:12:28.000000000 -0700
+++ 25-akpm/fs/fs-writeback.c 2003-06-12 23:14:07.000000000 -0700
@@ -260,8 +260,21 @@ sync_sb_inodes(struct super_block *sb, s
struct address_space *mapping = inode->i_mapping;
struct backing_dev_info *bdi = mapping->backing_dev_info;
- if (bdi->memory_backed)
+ if (bdi->memory_backed) {
+ if (sb == blockdev_superblock) {
+ /*
+ * Dirty memory-backed blockdev: the ramdisk
+ * driver does this.
+ */
+ list_move(&inode->i_list, &sb->s_dirty);
+ continue;
+ }
+ /*
+ * Assume that all inodes on this superblock are memory
+ * backed. Skip the superblock.
+ */
break;
+ }
if (wbc->nonblocking && bdi_write_congested(bdi)) {
wbc->encountered_congestion = 1;
But it does seem to work. Call me crazy, but it would seem to me that when something up above calls blkdev_put(), the dirty block really ought to be written out, rather than assuming that just because the count of opens on the block device is non-zero, the last close will flush it...
The somewhat long-winded thread is here: LKML thread.
In case you haven't heard, OSDL has a new fellow. Welcome aboard!
A patch set for kexec for 2.5.72 is now available. This patch set is based upon the stable 2.5.{67,68,69,70,71} versions. A unstable set of kexec patches for 2.5.69 from Eric Biederman is available here.
This patch was tested to work on a dual-processor P4-1.7GHz Xeon system. The only known strangeness I have observed (YMMV) is that my VESA framebuffer driver did not reinitialize correctly after kexec-ing a new kernel.
The stable patches for 2.5.72 are available for download from OSDL's patch life-cycle manager (PLM) in pieces, or as a single unified patch.
As of this release, the patch stack has been repackaged into a common patch, an x86 architecture patch, and the defconfig patch required for testing purposes by (PLM.
The individual patches:
| URL | Comments |
|---|---|
| kexec-2.5.72-common | generic kexec code |
| kexec-2.5.72-x86 | x86 (PC) architecture implementation |
| kexec-2.5.72-defconfig | enable CONFIG_KEXEC by default |
Or, kexec is available as a single unified patch: kexec-2.5.72-full. You do not need the full patch if you intend to use the patch pieces listed above.
The matching user-mode utility required to invoke kexec: kexec-tools-1.8-2.5.72.tgz
Patches for previous versions of many 2.5.x kernels are available here: kexec archives.
A PDF-format whitepaper on kexec is available: Reducing System Reboot Time With kexec. A badly-mangled HTML version is also available.
If you are interested in trying out kexec, please feel free to report your successes and failures to fastboot@osdl.org.
This is my public blog at work.
I'm still working a few kinks out of my homebrew blogging tool, so don't be surprised if you hit a dead link.
The opinions expressed here are not necessarily those of my employer.
An RSS feed of this site is not yet available.