Re: preparing 2.6.10
On Wed, 05 Jan 2005 00:15:51 -0500, Andres Salomon wrote: > Alright, enough people are bothering me for 2.6.10 that we should probably > get it into sid. I've committed a bunch of bk backports to the svn 2.6.10 > k-s directory (small, obvious fixes for the most part); I'm going to aim > for uploading 2.6.10 into NEW either Wed. or Thurs. unless anyone has > objections. Alright, here's the source packages: http://www.acm.rpi.edu/~dilinger/kernel-source-2.6.10/ I will upload this and the i386 packages when I wake up tomorrow (yeesh, 5:30am..).
Re: preparing 2.6.10
On Fri, Jan 07, 2005 at 12:19:10AM -0500, Andres Salomon wrote: > On Wed, 05 Jan 2005 22:42:48 +0100, Christoph Hellwig wrote: > > > On Wed, Jan 05, 2005 at 10:18:04PM +0100, Eduard Bloch wrote: > [...] > >> The IRQ-after-swsusp-awakening patch (attached). Needed to make > >> some hardware drivers work after resuming from swsusp (Source: > >> Message-ID: <[EMAIL PROTECTED]>) > >> > >> The swsusp-speedup-patch (attached) - makes the swsusp in kernel a lot > >> faster on suspending (source: > >> Message-ID: <[EMAIL PROTECTED]>) > > > > We don't ship with swsusp enabled so this is just a waste of time. > > I think enough people have been asking for swsusp that it may be worth > trying to enable it again, and seeing how/if it breaks for people. I > wouldn't want to do it for 2.6.10-1, though; rather, let's get 2.6.10-1 > out there, and if that proves stable, we can start doing some more > experimental stuff w/ 2.6.10-2. > > Ditto for the misrouted-irq patch. I personally have been using swsup to good effect with 2.6.10-rc1 and rc2. -- Horms -> 2c worth
Re: preparing 2.6.10
On Wed, 05 Jan 2005 22:42:48 +0100, Christoph Hellwig wrote: > On Wed, Jan 05, 2005 at 10:18:04PM +0100, Eduard Bloch wrote: [...] >> The IRQ-after-swsusp-awakening patch (attached). Needed to make >> some hardware drivers work after resuming from swsusp (Source: >> Message-ID: <[EMAIL PROTECTED]>) >> >> The swsusp-speedup-patch (attached) - makes the swsusp in kernel a lot >> faster on suspending (source: >> Message-ID: <[EMAIL PROTECTED]>) > > We don't ship with swsusp enabled so this is just a waste of time. I think enough people have been asking for swsusp that it may be worth trying to enable it again, and seeing how/if it breaks for people. I wouldn't want to do it for 2.6.10-1, though; rather, let's get 2.6.10-1 out there, and if that proves stable, we can start doing some more experimental stuff w/ 2.6.10-2. Ditto for the misrouted-irq patch.
Re: preparing 2.6.10
On Fri, 07 Jan 2005 12:06:38 +0900, Horms wrote: > On Wed, Jan 05, 2005 at 12:15:51AM -0500, Andres Salomon wrote: >> Alright, enough people are bothering me for 2.6.10 that we should probably >> get it into sid. I've committed a bunch of bk backports to the svn 2.6.10 >> k-s directory (small, obvious fixes for the most part); I'm going to aim >> for uploading 2.6.10 into NEW either Wed. or Thurs. unless anyone has >> objections. > > I'd like to advocate that we remove 2.6.9 when 2.6.10 is added. Assuming 2.6.10 doesn't blow up horribly on people's systems; sure. :)
Re: preparing 2.6.10
On Wed, Jan 05, 2005 at 12:15:51AM -0500, Andres Salomon wrote: > Alright, enough people are bothering me for 2.6.10 that we should probably > get it into sid. I've committed a bunch of bk backports to the svn 2.6.10 > k-s directory (small, obvious fixes for the most part); I'm going to aim > for uploading 2.6.10 into NEW either Wed. or Thurs. unless anyone has > objections. I'd like to advocate that we remove 2.6.9 when 2.6.10 is added. -- Horms
Re: preparing 2.6.10
On Wed, Jan 05, 2005 at 10:18:04PM +0100, Eduard Bloch wrote: > #include > * Andres Salomon [Wed, Jan 05 2005, 12:15:51AM]: > > Alright, enough people are bothering me for 2.6.10 that we should probably > > get it into sid. I've committed a bunch of bk backports to the svn 2.6.10 > > k-s directory (small, obvious fixes for the most part); I'm going to aim > > for uploading 2.6.10 into NEW either Wed. or Thurs. unless anyone has > > objections. > > Wishlist on patches (laptop/power management related): > > http://people.ubuntu.com/~fabbione/misrouted-irq.dpatch (not enabled by > default, needs kernel options, solves the extremely nasty hard kernel > crash on resume from APM/ACPI suspend, thanks fabionne) Probably makes sense, but I'd personally wait for some more testing or at least until it's in -mm. > The IRQ-after-swsusp-awakening patch (attached). Needed to make > some hardware drivers work after resuming from swsusp (Source: > Message-ID: <[EMAIL PROTECTED]>) > > The swsusp-speedup-patch (attached) - makes the swsusp in kernel a lot > faster on suspending (source: > Message-ID: <[EMAIL PROTECTED]>) We don't ship with swsusp enabled so this is just a waste of time.
Re: preparing 2.6.10
#include
* Andres Salomon [Wed, Jan 05 2005, 12:15:51AM]:
> Alright, enough people are bothering me for 2.6.10 that we should probably
> get it into sid. I've committed a bunch of bk backports to the svn 2.6.10
> k-s directory (small, obvious fixes for the most part); I'm going to aim
> for uploading 2.6.10 into NEW either Wed. or Thurs. unless anyone has
> objections.
Wishlist on patches (laptop/power management related):
http://people.ubuntu.com/~fabbione/misrouted-irq.dpatch (not enabled by
default, needs kernel options, solves the extremely nasty hard kernel
crash on resume from APM/ACPI suspend, thanks fabionne)
The IRQ-after-swsusp-awakening patch (attached). Needed to make
some hardware drivers work after resuming from swsusp (Source:
Message-ID: <[EMAIL PROTECTED]>)
The swsusp-speedup-patch (attached) - makes the swsusp in kernel a lot
faster on suspending (source:
Message-ID: <[EMAIL PROTECTED]>)
Regards,
Eduard.
--
The past tempts us, the present confuses us, the future frightens us.
And our lives slip away, moment by moment, lost in the terrible
in-between.-- Centauri Emperor, "Babylon 5 - The Coming Of Shadows"
swsusp does not suspend and resume *all* devices, including system
devices. This has been the case since at least 2.6.9, if not earlier.
One effect of this is that resuming fails to properly reconfigure
interrupt routers. In 2.6.9 this was obscured by other kernel code,
but in 2.6.10 this often causes post-resume APIC errors and near-total
failure of some PCI devices (e.g. network, sound and USB controllers).
On at least one of my systems, without this patch I also have to "ifdown
eth0;ifup eth0" to get networking to function after resuming, even after
working around the interrupt routing problem mentioned above. With this
patch, networking simply works after a resume, and the ifdown/ifup is
no longer needed.
This patch is against 2.6.10-mm1, although it applies with an offset to
2.6.10-bk4 as well. I have tested it against 2.6.10-mm1 and 2.6.10-bk4,
with and without "noapic", with and without "acpi=off". However, I have
not tested it on a highmem system.
I believe this patch fixes a severe problem in swsusp; I would like to
see this patch (or at least *some* kind of fix for this problem) tested
more widely and committed to mainline before the 2.6.11 release.
Signed-off-by: Barry K. Nathan <[EMAIL PROTECTED]>
--- linux-2.6.10-mm1/kernel/power/swsusp.c 2005-01-03 02:16:15.175265255
-0800
+++ linux-2.6.10-mm1-bkn3/kernel/power/swsusp.c 2005-01-03 06:27:07.753344731
-0800
@@ -843,11 +843,22 @@
if ((error = arch_prepare_suspend()))
return error;
local_irq_disable();
+ /* At this point, device_suspend() has been called, but *not*
+* device_power_down(). We *must* device_power_down() now.
+* Otherwise, drivers for some devices (e.g. interrupt controllers)
+* become desynchronized with the actual state of the hardware
+* at resume time, and evil weirdness ensues.
+*/
+ if ((error = device_power_down(PM_SUSPEND_DISK))) {
+ local_irq_enable();
+ return error;
+ }
save_processor_state();
error = swsusp_arch_suspend();
/* Restore control flow magically appears here */
restore_processor_state();
restore_highmem();
+ device_power_up();
local_irq_enable();
return error;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi!
Some machines are spending minutes of CPU time during suspend in
stupid O(n^2) algorithm. This patch replaces it with O(n) algorithm,
making swsusp usable to some people.
I'd like people to test this. It should probably spend few weeks
in -mm tree to get some beating. OTOH SUSE has variant of this patch
in its kernel.
Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Pavel
--- clean-cvs/include/linux/page-flags.h2004-08-24 20:26:54.0
+0200
+++ linux-cvs/include/linux/page-flags.h2004-12-10 22:35:58.0
+0100
@@ -74,7 +74,7 @@
#define PG_swapcache 16 /* Swap page: swp_entry_t in private */
#define PG_mappedtodisk17 /* Has blocks allocated on-disk
*/
#define PG_reclaim 18 /* To be reclaimed asap */
-
+#define PG_nosave_free 19 /* Page is free and should not be
written */
/*
* Global page accounting. One instance per CPU. Only unsigned longs are
@@ -277,6 +277,10 @@
#define ClearPageNosave(page) clear_bit(PG_nosave, &(page)->flags)
#define TestClearPageNosave(page) test_and_clear_bit(PG_nosave,
&(page)->flags)
+#define PageNosaveFree(page) test_bit(PG_nosave_free, &(page)->flags)
+#define SetPageNosaveF
Re: preparing 2.6.10
On Wed, 2005-01-05 at 10:18 +0100, Christoph Hellwig wrote: [...] > > ia64-generic-no-smp.dpatch still needs a forward-port. > drivers-scsi-generic_proc_info.dpatch should be dropped, but we need to > make sure the kernelk-image packages depend on the latest initrd-tools > Alright, I'll look into that. > btw, any reason your newly commited patches have leading numbersi n > their patch names, unliked all the older patches? > To keep track of them outside of SVN. I'm working w/ arch people to track down some sort of resource leak that makes tla/baz explode when dealing w/ kernel source trees; until then, I'm forced to work w/out an RCS (svn isn't useful for my purposes; quilt may be, but the last time I tried it, I wasn't happy w/ it). So, the numerals are just used for keeping chronological order within my own 2.6.10+fixes_only tree, for now. There's no reason they can't be renamed in SVN; I just didn't have the desire to do so. -- Andres Salomon <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: preparing 2.6.10
On Wed, Jan 05, 2005 at 12:15:51AM -0500, Andres Salomon wrote: > Alright, enough people are bothering me for 2.6.10 that we should probably > get it into sid. I've committed a bunch of bk backports to the svn 2.6.10 > k-s directory (small, obvious fixes for the most part); I'm going to aim > for uploading 2.6.10 into NEW either Wed. or Thurs. unless anyone has > objections. ia64-generic-no-smp.dpatch still needs a forward-port. drivers-scsi-generic_proc_info.dpatch should be dropped, but we need to make sure the kernelk-image packages depend on the latest initrd-tools btw, any reason your newly commited patches have leading numbersi n their patch names, unliked all the older patches?
