Re: Linux 2.6.21-rc6
On Sunday, 15 April 2007 20:50, Tobias Diedrich wrote:
> Rafael J. Wysocki wrote:
> > On Sunday, 15 April 2007 16:19, Dmitry Torokhov wrote:
> > > On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote:
> > > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
> > > >
> > > > > > With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see
> > > > > > that the second suspend hangs at "i8042 i8042: EARLY resume".
> > > > > > This is kinda interesting because I'm normally using a USB keyboard
> > > > > > and sure enough, if I hook up a normal keyboard and disable USB
> > > > > > legacy support in the BIOS, then suspend to disk works multiple
> > > > > > times. I'd still rather like to use my USB keyboard though. ;)
> > > >
> > > > Well, I think that when you're using the USB keyboard and the USB legacy
> > > > support, the i8042 driver thinks it has a keyboard to handle and tries
> > > > to
> > > > handle it during the suspend, which fails. I don't know why it fails
> > > > during
> > > > the second suspend, though.
> > > >
> > > > Dmitry, could you please have a look?
> > > >
> > >
> > > This is wierd as i8042 does not use suspend_late/resume_early hooks and
> > > so it is impossible for it to hang there. None of input drivers use these
> > > hooks. Could it be that some other driver _after_ i8042 hangs?
> >
> > Yes.
> >
> > Tobias, can you please post the dmesg output from after a successful
> > suspend/resume cycle with CONFIG_PM_DEBUG=y in the 'platform' mode?
>
> Here you go:
Thanks.
[--snip--]
> [10233.239209] swsusp: critical section:
> [10233.253579] swsusp: Need to copy 125818 pages
> [10233.253688] swsusp: Normal pages needed: 125818 + 1024 + 22, available
> pages: 135940
> [ 43.795445] Extended CMOS year: 2000
> [ 43.798813] svm_cpu_init: svm_data is NULL on 0
> [ 43.800886] pci :00:00.0: EARLY resume
> [ 43.800994] pci :00:01.0: EARLY resume
> [ 43.801102] nForce2_smbus :00:01.1: EARLY resume
> [ 43.801210] pci :00:01.2: EARLY resume
> [ 43.801317] ohci_hcd :00:02.0: EARLY resume
> [ 43.801425] ehci_hcd :00:02.1: EARLY resume
> [ 43.801532] pata_amd :00:04.0: EARLY resume
> [ 43.801640] pci :00:06.0: EARLY resume
> [ 43.801747] pci :00:06.1: EARLY resume
> [ 43.801854] forcedeth :00:08.0: EARLY resume
> [ 43.801962] forcedeth :00:09.0: EARLY resume
> [ 43.802070] pcieport-driver :00:0a.0: EARLY resume
> [ 43.802177] pcieport-driver :00:0b.0: EARLY resume
> [ 43.802289] pcieport-driver :00:0c.0: EARLY resume
> [ 43.802398] pcieport-driver :00:0d.0: EARLY resume
> [ 43.802506] pcieport-driver :00:0e.0: EARLY resume
> [ 43.802613] pcieport-driver :00:0f.0: EARLY resume
> [ 43.802721] pci :00:18.0: EARLY resume
> [ 43.802828] pci :00:18.1: EARLY resume
> [ 43.802935] pci :00:18.2: EARLY resume
> [ 43.803043] k8temp :00:18.3: EARLY resume
> [ 43.803150] e100 :01:07.0: EARLY resume
> [ 43.803257] EMU10K1_Audigy :01:08.0: EARLY resume
> [ 43.803365] Emu10k1_gameport :01:08.1: EARLY resume
> [ 43.803473] pci :01:0b.0: EARLY resume
> [ 43.803580] ahci :06:00.0: EARLY resume
> [ 43.803695] pci :06:00.1: EARLY resume
> [ 43.803802] pci :07:00.0: EARLY resume
> [ 43.803910] pci :07:00.1: EARLY resume
> [ 43.804018] platform bluetooth: EARLY resume
> [ 43.804126] platform pcspkr: EARLY resume
> [ 43.804233] platform vesafb.0: EARLY resume
> [ 43.804348] i8042 i8042: EARLY resume
> [ 43.804460] PM: Image restored successfully.
> [ 43.924837] acpi acpi_system:00: resuming
> [ 43.924946] button button_power:00: resuming
> [ 43.925054] processor ACPI0007:00: resuming
> [ 43.925161] processor ACPI0007:01: resuming
> [ 43.925268] acpi device:00: resuming
[--snip--]
Hmm, it looks like i8042 is the last thing on the dpm_off_irq list. Still,
if the ACPI resume fails, the next messages may not make it to the console
(it's not very probable, though).
I've tried to reproduce your problem on another box on which I have no PS/2
keyboard (USB keyboard/mouse only) and the USB legacy support set, but I can't.
There must be something very special in your configuration.
Have you tried the patch that I posted some time ago (appended again for
convenience)?
Rafael
drivers/input/serio/i8042.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
===
--- linux-2.6.21-rc6.orig/drivers/input/serio/i8042.c 2007-04-07
12:15:19.0 +0200
+++ linux-2.6.21-rc6/drivers/input/serio/i8042.c2007-04-15
18:30:01.0 +0200
@@ -846,7 +846,8 @@ static long i8042_panic_blink(long count
static int i8042_suspend(struct platform_device *dev, pm_message_t state)
{
if (dev->dev.power.power_state.event != state.event) {
- if (state.event == PM_EVENT_SUSPEND)
+
Re: Linux 2.6.21-rc6
On Sunday, 15 April 2007 16:19, Dmitry Torokhov wrote: > On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote: > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: > > > > > > With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see > > > > that the second suspend hangs at "i8042 i8042: EARLY resume". > > > > This is kinda interesting because I'm normally using a USB keyboard > > > > and sure enough, if I hook up a normal keyboard and disable USB > > > > legacy support in the BIOS, then suspend to disk works multiple > > > > times. I'd still rather like to use my USB keyboard though. ;) > > > > Well, I think that when you're using the USB keyboard and the USB legacy > > support, the i8042 driver thinks it has a keyboard to handle and tries to > > handle it during the suspend, which fails. I don't know why it fails during > > the second suspend, though. > > > > Dmitry, could you please have a look? > > > > This is wierd as i8042 does not use suspend_late/resume_early hooks and > so it is impossible for it to hang there. None of input drivers use these > hooks. Could it be that some other driver _after_ i8042 hangs? Yes. Tobias, can you please post the dmesg output from after a successful suspend/resume cycle with CONFIG_PM_DEBUG=y in the 'platform' mode? > > > And I can now confirm that unpatched 2.6.21-rc6 works fine as long > > > as USB legacy support is disabled (however without legacy support I > > > can't use the USB keyboard to control grub). > > > > I think using the 'shutdown' mode of suspend would be better. There's a > > little > > point in using 'platform' on desktop systems anyway. > > > > Frankly, I don't know what to do about it. If we move platform_finish() > > after > > device_resume(), some systems may be broken and I think there are more such > > systems than there are systems that set USB legacy support in the BIOS and > > have no PS/2 keyboards attached. > > I would say that every box that does not use PS/2 keyboard does this. Quite some people I know use USB keyboards with notebooks, but in these cases the PS/2 keyboard is still attached (except for notebooks in which the built-in keyboard is a USB one, that is). > IOW every box with USB keyboard has legacy emulation turned on so quite > few of them... I have such a machine nearby, so I'll see if I can reproduce the problem. Greetings, Rafael - 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/
Re: Linux 2.6.21-rc6
On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote: > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: > > > > With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see > > > that the second suspend hangs at "i8042 i8042: EARLY resume". > > > This is kinda interesting because I'm normally using a USB keyboard > > > and sure enough, if I hook up a normal keyboard and disable USB > > > legacy support in the BIOS, then suspend to disk works multiple > > > times. I'd still rather like to use my USB keyboard though. ;) > > Well, I think that when you're using the USB keyboard and the USB legacy > support, the i8042 driver thinks it has a keyboard to handle and tries to > handle it during the suspend, which fails. I don't know why it fails during > the second suspend, though. > > Dmitry, could you please have a look? > This is wierd as i8042 does not use suspend_late/resume_early hooks and so it is impossible for it to hang there. None of input drivers use these hooks. Could it be that some other driver _after_ i8042 hangs? > > And I can now confirm that unpatched 2.6.21-rc6 works fine as long > > as USB legacy support is disabled (however without legacy support I > > can't use the USB keyboard to control grub). > > I think using the 'shutdown' mode of suspend would be better. There's a > little > point in using 'platform' on desktop systems anyway. > > Frankly, I don't know what to do about it. If we move platform_finish() after > device_resume(), some systems may be broken and I think there are more such > systems than there are systems that set USB legacy support in the BIOS and > have no PS/2 keyboards attached. I would say that every box that does not use PS/2 keyboard does this. IOW every box with USB keyboard has legacy emulation turned on so quite few of them... -- Dmitry - 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/
Re: Linux 2.6.21-rc6
On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: > Tobias Diedrich wrote: > > Rafael J. Wysocki wrote: > > > On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: > > > > Rafael J. Wysocki wrote: > > > > > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: > > > > > > Rafael J. Wysocki wrote: > > > > > > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > > > > > > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > > > > > > > > Tobias Diedrich wrote: > > > > > > > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad > > > > > > > > > > > commit > > > > > > > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > > > > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > > > > > > > > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > > > > > > > > > > > > > > > Change the ordering of code in kernel/power/disk.c so > > > > > > > > > > > that device_suspend() is > > > > > > > > > > > called before disable_nonboot_cpus() and > > > > > > > > > > > platform_finish() is called after > > > > > > > > > > > enable_nonboot_cpus() and before device_resume(), as > > > > > > > > > > > indicated by the recent > > > > > > > > > > > discussion on Linux-PM (cf. > > > > > > > > > > > > > > > > > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > > > > > > > > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > > > > > > > > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > > > > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > > > > > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > > > > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > > > > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > > > > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > > > > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > > > > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > > > > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, the remaining test is to try reverting this commit > > > > > > > > > > > from -rc6. :) > > > > > > > > > > > > > > > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem > > > > > > > > > > when > > > > > > > > > > reverted from -rc1. > > > > > > > > > > > > > > > > > > Now, this was already reported in > > > > > > > > > http://lkml.org/lkml/2007/3/16/126 > > > > > > > > > and I even flagged that message in my local folder, but > > > > > > > > > apparently forgot > > > > > > > > > to follow up on it... *sigh* > > > > > > > > > > > > > > > > Unless I misunderstood something, all of the problems Maxim > > > > > > > > described in > > > > > > > > this email are fixed for him in -rc6. > > > > > > > > > > > > > > > > But it's quite possible that you are running into a different > > > > > > > > issue > > > > > > > > exposed by this commit. > > > > > > > > > > > > > > Yes, it's likely. > > > > > > > > > > > > > > Tobias, I'm unable to reproduce the problem with your .config, > > > > > > > but my hardware > > > > > > > is certainly different. Which suspend mode do you use? If > > > > > > > that's "platform", > > > > > > > can you try to use "shutdown" or "reboot" and see if that helps? > > > > > > > > > > > > Sure. > > > > > > shutdown/reboot works fine, only platform is broken. > > > > > > > > > > Thanks. > > > > > > > > > > Now, I suspect the problem is somehow related to the hardware, so it > > > > > would help > > > > > a lot if we could identify the piece of hardware (or driver) involved. > > > > > > > > > > AFAICT, your system is a non-SMP one, so we can rule out > > > > > disable/enable_nonboot_cpus(). To confirm that the problem is > > > > > related to > > > > > platform_finish(), can you please apply the appended debug patch and > > > > > see if the suspend in the 'platform' mode works with it? > > > > > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ > > > > single core CPU. > > > > > > > > > Also, would that be feasible for you to use 'shutdown' as a > > > > > workaround in case > > > > > the source of the problem is difficult to find and/or fix? > > > > > > > > I guess so, but the below patch fixes the problem. :) > > > > > > Well, I thought it would, but it also would break some other people's > > > systems. > > > That's the _real_ problem. Let's see if we can learn more. > > > > > > Can you please revert it for now, apply the appended one and try to > > > suspend/resume twice in the
Re: Linux 2.6.21-rc6
Tobias Diedrich wrote: > Rafael J. Wysocki wrote: > > On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: > > > Rafael J. Wysocki wrote: > > > > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: > > > > > Rafael J. Wysocki wrote: > > > > > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > > > > > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > > > > > > > Tobias Diedrich wrote: > > > > > > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > > > > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > > > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > > > > > > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > > > > > > > > > > > > > Change the ordering of code in kernel/power/disk.c so > > > > > > > > > > that device_suspend() is > > > > > > > > > > called before disable_nonboot_cpus() and > > > > > > > > > > platform_finish() is called after > > > > > > > > > > enable_nonboot_cpus() and before device_resume(), as > > > > > > > > > > indicated by the recent > > > > > > > > > > discussion on Linux-PM (cf. > > > > > > > > > > > > > > > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > > > > > > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > > > > > > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > > > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > > > > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > > > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > > > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > > > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > > > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > > > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > > > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, the remaining test is to try reverting this commit > > > > > > > > > > from -rc6. :) > > > > > > > > > > > > > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > > > > > > > > reverted from -rc1. > > > > > > > > > > > > > > > > Now, this was already reported in > > > > > > > > http://lkml.org/lkml/2007/3/16/126 > > > > > > > > and I even flagged that message in my local folder, but > > > > > > > > apparently forgot > > > > > > > > to follow up on it... *sigh* > > > > > > > > > > > > > > Unless I misunderstood something, all of the problems Maxim > > > > > > > described in > > > > > > > this email are fixed for him in -rc6. > > > > > > > > > > > > > > But it's quite possible that you are running into a different > > > > > > > issue > > > > > > > exposed by this commit. > > > > > > > > > > > > Yes, it's likely. > > > > > > > > > > > > Tobias, I'm unable to reproduce the problem with your .config, but > > > > > > my hardware > > > > > > is certainly different. Which suspend mode do you use? If that's > > > > > > "platform", > > > > > > can you try to use "shutdown" or "reboot" and see if that helps? > > > > > > > > > > Sure. > > > > > shutdown/reboot works fine, only platform is broken. > > > > > > > > Thanks. > > > > > > > > Now, I suspect the problem is somehow related to the hardware, so it > > > > would help > > > > a lot if we could identify the piece of hardware (or driver) involved. > > > > > > > > AFAICT, your system is a non-SMP one, so we can rule out > > > > disable/enable_nonboot_cpus(). To confirm that the problem is related > > > > to > > > > platform_finish(), can you please apply the appended debug patch and > > > > see if the suspend in the 'platform' mode works with it? > > > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ > > > single core CPU. > > > > > > > Also, would that be feasible for you to use 'shutdown' as a workaround > > > > in case > > > > the source of the problem is difficult to find and/or fix? > > > > > > I guess so, but the below patch fixes the problem. :) > > > > Well, I thought it would, but it also would break some other people's > > systems. > > That's the _real_ problem. Let's see if we can learn more. > > > > Can you please revert it for now, apply the appended one and try to > > suspend/resume twice in the 'platform' mode (it may or may not work)? > > Ok. The patch doesn't apply cleanly to 2.6.21-rc6: > |patching file kernel/power/disk.c > |Hunk #1 FAILED at 267. > |Hunk #2 succeeded at 265 (offset -23 lines). > |1 out of 2 hunks FAILED -- saving rejects to file > |kernel/power/disk.c.rej > >
Re: Linux 2.6.21-rc6
Rafael J. Wysocki wrote: > On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: > > Rafael J. Wysocki wrote: > > > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: > > > > Rafael J. Wysocki wrote: > > > > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > > > > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > > > > > > Tobias Diedrich wrote: > > > > > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > > > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > > > > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > > > > > > > > > > > Change the ordering of code in kernel/power/disk.c so > > > > > > > > > that device_suspend() is > > > > > > > > > called before disable_nonboot_cpus() and > > > > > > > > > platform_finish() is called after > > > > > > > > > enable_nonboot_cpus() and before device_resume(), as > > > > > > > > > indicated by the recent > > > > > > > > > discussion on Linux-PM (cf. > > > > > > > > > > > > > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > > > > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > > > > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > > > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, the remaining test is to try reverting this commit from > > > > > > > > > -rc6. :) > > > > > > > > > > > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > > > > > > > reverted from -rc1. > > > > > > > > > > > > > > Now, this was already reported in > > > > > > > http://lkml.org/lkml/2007/3/16/126 > > > > > > > and I even flagged that message in my local folder, but > > > > > > > apparently forgot > > > > > > > to follow up on it... *sigh* > > > > > > > > > > > > Unless I misunderstood something, all of the problems Maxim > > > > > > described in > > > > > > this email are fixed for him in -rc6. > > > > > > > > > > > > But it's quite possible that you are running into a different issue > > > > > > exposed by this commit. > > > > > > > > > > Yes, it's likely. > > > > > > > > > > Tobias, I'm unable to reproduce the problem with your .config, but my > > > > > hardware > > > > > is certainly different. Which suspend mode do you use? If that's > > > > > "platform", > > > > > can you try to use "shutdown" or "reboot" and see if that helps? > > > > > > > > Sure. > > > > shutdown/reboot works fine, only platform is broken. > > > > > > Thanks. > > > > > > Now, I suspect the problem is somehow related to the hardware, so it > > > would help > > > a lot if we could identify the piece of hardware (or driver) involved. > > > > > > AFAICT, your system is a non-SMP one, so we can rule out > > > disable/enable_nonboot_cpus(). To confirm that the problem is related to > > > platform_finish(), can you please apply the appended debug patch and > > > see if the suspend in the 'platform' mode works with it? > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ > > single core CPU. > > > > > Also, would that be feasible for you to use 'shutdown' as a workaround in > > > case > > > the source of the problem is difficult to find and/or fix? > > > > I guess so, but the below patch fixes the problem. :) > > Well, I thought it would, but it also would break some other people's systems. > That's the _real_ problem. Let's see if we can learn more. > > Can you please revert it for now, apply the appended one and try to > suspend/resume twice in the 'platform' mode (it may or may not work)? Ok. The patch doesn't apply cleanly to 2.6.21-rc6: |patching file kernel/power/disk.c |Hunk #1 FAILED at 267. |Hunk #2 succeeded at 265 (offset -23 lines). |1 out of 2 hunks FAILED -- saving rejects to file |kernel/power/disk.c.rej wiggle helps, seems the first part of Hunk #1 is already applied in 2.6.21-rc6. With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see that the second suspend hangs at "i8042 i8042: EARLY resume". This is kinda interesting because I'm normally using a USB
Re: Linux 2.6.21-rc6
Rafael J. Wysocki wrote: On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: Tobias Diedrich wrote: ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) Doesn't apply cleanly against -rc6, but fixes the problem when reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* Unless I misunderstood something, all of the problems Maxim described in this email are fixed for him in -rc6. But it's quite possible that you are running into a different issue exposed by this commit. Yes, it's likely. Tobias, I'm unable to reproduce the problem with your .config, but my hardware is certainly different. Which suspend mode do you use? If that's platform, can you try to use shutdown or reboot and see if that helps? Sure. shutdown/reboot works fine, only platform is broken. Thanks. Now, I suspect the problem is somehow related to the hardware, so it would help a lot if we could identify the piece of hardware (or driver) involved. AFAICT, your system is a non-SMP one, so we can rule out disable/enable_nonboot_cpus(). To confirm that the problem is related to platform_finish(), can you please apply the appended debug patch and see if the suspend in the 'platform' mode works with it? Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ single core CPU. Also, would that be feasible for you to use 'shutdown' as a workaround in case the source of the problem is difficult to find and/or fix? I guess so, but the below patch fixes the problem. :) Well, I thought it would, but it also would break some other people's systems. That's the _real_ problem. Let's see if we can learn more. Can you please revert it for now, apply the appended one and try to suspend/resume twice in the 'platform' mode (it may or may not work)? Ok. The patch doesn't apply cleanly to 2.6.21-rc6: |patching file kernel/power/disk.c |Hunk #1 FAILED at 267. |Hunk #2 succeeded at 265 (offset -23 lines). |1 out of 2 hunks FAILED -- saving rejects to file |kernel/power/disk.c.rej wiggle helps, seems the first part of Hunk #1 is already applied in 2.6.21-rc6. With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see that the second suspend hangs at i8042 i8042: EARLY resume. This is kinda interesting because I'm normally using a USB keyboard and sure enough, if I hook up a normal keyboard and disable USB legacy support in the BIOS, then suspend to disk works multiple times. I'd still rather like to use my USB keyboard though. ;) -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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/
Re: Linux 2.6.21-rc6
Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: Tobias Diedrich wrote: ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) Doesn't apply cleanly against -rc6, but fixes the problem when reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* Unless I misunderstood something, all of the problems Maxim described in this email are fixed for him in -rc6. But it's quite possible that you are running into a different issue exposed by this commit. Yes, it's likely. Tobias, I'm unable to reproduce the problem with your .config, but my hardware is certainly different. Which suspend mode do you use? If that's platform, can you try to use shutdown or reboot and see if that helps? Sure. shutdown/reboot works fine, only platform is broken. Thanks. Now, I suspect the problem is somehow related to the hardware, so it would help a lot if we could identify the piece of hardware (or driver) involved. AFAICT, your system is a non-SMP one, so we can rule out disable/enable_nonboot_cpus(). To confirm that the problem is related to platform_finish(), can you please apply the appended debug patch and see if the suspend in the 'platform' mode works with it? Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ single core CPU. Also, would that be feasible for you to use 'shutdown' as a workaround in case the source of the problem is difficult to find and/or fix? I guess so, but the below patch fixes the problem. :) Well, I thought it would, but it also would break some other people's systems. That's the _real_ problem. Let's see if we can learn more. Can you please revert it for now, apply the appended one and try to suspend/resume twice in the 'platform' mode (it may or may not work)? Ok. The patch doesn't apply cleanly to 2.6.21-rc6: |patching file kernel/power/disk.c |Hunk #1 FAILED at 267. |Hunk #2 succeeded at 265 (offset -23 lines). |1 out of 2 hunks FAILED -- saving rejects to file |kernel/power/disk.c.rej wiggle helps, seems the first part of Hunk #1 is already applied in 2.6.21-rc6. With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see that the second suspend hangs at i8042 i8042: EARLY resume. This is kinda interesting because I'm normally using a USB keyboard and sure enough, if I hook up a normal keyboard and disable USB legacy support in the BIOS, then suspend to disk works multiple times. I'd still rather like to use my USB keyboard though. ;) And I can now confirm that unpatched 2.6.21-rc6 works fine as long as USB legacy support is disabled (however without legacy support I can't use the USB keyboard to control grub). -- Tobias
Re: Linux 2.6.21-rc6
On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: Tobias Diedrich wrote: ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) Doesn't apply cleanly against -rc6, but fixes the problem when reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* Unless I misunderstood something, all of the problems Maxim described in this email are fixed for him in -rc6. But it's quite possible that you are running into a different issue exposed by this commit. Yes, it's likely. Tobias, I'm unable to reproduce the problem with your .config, but my hardware is certainly different. Which suspend mode do you use? If that's platform, can you try to use shutdown or reboot and see if that helps? Sure. shutdown/reboot works fine, only platform is broken. Thanks. Now, I suspect the problem is somehow related to the hardware, so it would help a lot if we could identify the piece of hardware (or driver) involved. AFAICT, your system is a non-SMP one, so we can rule out disable/enable_nonboot_cpus(). To confirm that the problem is related to platform_finish(), can you please apply the appended debug patch and see if the suspend in the 'platform' mode works with it? Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ single core CPU. Also, would that be feasible for you to use 'shutdown' as a workaround in case the source of the problem is difficult to find and/or fix? I guess so, but the below patch fixes the problem. :) Well, I thought it would, but it also would break some other people's systems. That's the _real_ problem. Let's see if we can learn more. Can you please revert it for now, apply the appended one and try to suspend/resume twice in the 'platform' mode (it may or may not work)? Ok. The patch doesn't apply cleanly to 2.6.21-rc6: |patching file kernel/power/disk.c |Hunk #1 FAILED at 267. |Hunk #2 succeeded at 265 (offset -23 lines). |1 out of 2 hunks FAILED -- saving rejects to file |kernel/power/disk.c.rej wiggle helps, seems the first part of Hunk #1 is already applied in 2.6.21-rc6. Ah, sorry. I used a wrong tree to generate the patch. With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see that the second suspend hangs at i8042 i8042: EARLY resume. This is kinda interesting because I'm normally using a USB keyboard and sure enough, if I hook up a normal keyboard and disable USB legacy support in the BIOS, then suspend to disk works multiple times. I'd still rather like to use my USB
Re: Linux 2.6.21-rc6
On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote: On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see that the second suspend hangs at i8042 i8042: EARLY resume. This is kinda interesting because I'm normally using a USB keyboard and sure enough, if I hook up a normal keyboard and disable USB legacy support in the BIOS, then suspend to disk works multiple times. I'd still rather like to use my USB keyboard though. ;) Well, I think that when you're using the USB keyboard and the USB legacy support, the i8042 driver thinks it has a keyboard to handle and tries to handle it during the suspend, which fails. I don't know why it fails during the second suspend, though. Dmitry, could you please have a look? This is wierd as i8042 does not use suspend_late/resume_early hooks and so it is impossible for it to hang there. None of input drivers use these hooks. Could it be that some other driver _after_ i8042 hangs? And I can now confirm that unpatched 2.6.21-rc6 works fine as long as USB legacy support is disabled (however without legacy support I can't use the USB keyboard to control grub). I think using the 'shutdown' mode of suspend would be better. There's a little point in using 'platform' on desktop systems anyway. Frankly, I don't know what to do about it. If we move platform_finish() after device_resume(), some systems may be broken and I think there are more such systems than there are systems that set USB legacy support in the BIOS and have no PS/2 keyboards attached. I would say that every box that does not use PS/2 keyboard does this. IOW every box with USB keyboard has legacy emulation turned on so quite few of them... -- Dmitry - 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/
Re: Linux 2.6.21-rc6
On Sunday, 15 April 2007 16:19, Dmitry Torokhov wrote: On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote: On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see that the second suspend hangs at i8042 i8042: EARLY resume. This is kinda interesting because I'm normally using a USB keyboard and sure enough, if I hook up a normal keyboard and disable USB legacy support in the BIOS, then suspend to disk works multiple times. I'd still rather like to use my USB keyboard though. ;) Well, I think that when you're using the USB keyboard and the USB legacy support, the i8042 driver thinks it has a keyboard to handle and tries to handle it during the suspend, which fails. I don't know why it fails during the second suspend, though. Dmitry, could you please have a look? This is wierd as i8042 does not use suspend_late/resume_early hooks and so it is impossible for it to hang there. None of input drivers use these hooks. Could it be that some other driver _after_ i8042 hangs? Yes. Tobias, can you please post the dmesg output from after a successful suspend/resume cycle with CONFIG_PM_DEBUG=y in the 'platform' mode? And I can now confirm that unpatched 2.6.21-rc6 works fine as long as USB legacy support is disabled (however without legacy support I can't use the USB keyboard to control grub). I think using the 'shutdown' mode of suspend would be better. There's a little point in using 'platform' on desktop systems anyway. Frankly, I don't know what to do about it. If we move platform_finish() after device_resume(), some systems may be broken and I think there are more such systems than there are systems that set USB legacy support in the BIOS and have no PS/2 keyboards attached. I would say that every box that does not use PS/2 keyboard does this. Quite some people I know use USB keyboards with notebooks, but in these cases the PS/2 keyboard is still attached (except for notebooks in which the built-in keyboard is a USB one, that is). IOW every box with USB keyboard has legacy emulation turned on so quite few of them... I have such a machine nearby, so I'll see if I can reproduce the problem. Greetings, Rafael - 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/
Re: Linux 2.6.21-rc6
On Sunday, 15 April 2007 20:50, Tobias Diedrich wrote:
Rafael J. Wysocki wrote:
On Sunday, 15 April 2007 16:19, Dmitry Torokhov wrote:
On Sunday 15 April 2007 07:16, Rafael J. Wysocki wrote:
On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see
that the second suspend hangs at i8042 i8042: EARLY resume.
This is kinda interesting because I'm normally using a USB keyboard
and sure enough, if I hook up a normal keyboard and disable USB
legacy support in the BIOS, then suspend to disk works multiple
times. I'd still rather like to use my USB keyboard though. ;)
Well, I think that when you're using the USB keyboard and the USB legacy
support, the i8042 driver thinks it has a keyboard to handle and tries
to
handle it during the suspend, which fails. I don't know why it fails
during
the second suspend, though.
Dmitry, could you please have a look?
This is wierd as i8042 does not use suspend_late/resume_early hooks and
so it is impossible for it to hang there. None of input drivers use these
hooks. Could it be that some other driver _after_ i8042 hangs?
Yes.
Tobias, can you please post the dmesg output from after a successful
suspend/resume cycle with CONFIG_PM_DEBUG=y in the 'platform' mode?
Here you go:
Thanks.
[--snip--]
[10233.239209] swsusp: critical section:
[10233.253579] swsusp: Need to copy 125818 pages
[10233.253688] swsusp: Normal pages needed: 125818 + 1024 + 22, available
pages: 135940
[ 43.795445] Extended CMOS year: 2000
[ 43.798813] svm_cpu_init: svm_data is NULL on 0
[ 43.800886] pci :00:00.0: EARLY resume
[ 43.800994] pci :00:01.0: EARLY resume
[ 43.801102] nForce2_smbus :00:01.1: EARLY resume
[ 43.801210] pci :00:01.2: EARLY resume
[ 43.801317] ohci_hcd :00:02.0: EARLY resume
[ 43.801425] ehci_hcd :00:02.1: EARLY resume
[ 43.801532] pata_amd :00:04.0: EARLY resume
[ 43.801640] pci :00:06.0: EARLY resume
[ 43.801747] pci :00:06.1: EARLY resume
[ 43.801854] forcedeth :00:08.0: EARLY resume
[ 43.801962] forcedeth :00:09.0: EARLY resume
[ 43.802070] pcieport-driver :00:0a.0: EARLY resume
[ 43.802177] pcieport-driver :00:0b.0: EARLY resume
[ 43.802289] pcieport-driver :00:0c.0: EARLY resume
[ 43.802398] pcieport-driver :00:0d.0: EARLY resume
[ 43.802506] pcieport-driver :00:0e.0: EARLY resume
[ 43.802613] pcieport-driver :00:0f.0: EARLY resume
[ 43.802721] pci :00:18.0: EARLY resume
[ 43.802828] pci :00:18.1: EARLY resume
[ 43.802935] pci :00:18.2: EARLY resume
[ 43.803043] k8temp :00:18.3: EARLY resume
[ 43.803150] e100 :01:07.0: EARLY resume
[ 43.803257] EMU10K1_Audigy :01:08.0: EARLY resume
[ 43.803365] Emu10k1_gameport :01:08.1: EARLY resume
[ 43.803473] pci :01:0b.0: EARLY resume
[ 43.803580] ahci :06:00.0: EARLY resume
[ 43.803695] pci :06:00.1: EARLY resume
[ 43.803802] pci :07:00.0: EARLY resume
[ 43.803910] pci :07:00.1: EARLY resume
[ 43.804018] platform bluetooth: EARLY resume
[ 43.804126] platform pcspkr: EARLY resume
[ 43.804233] platform vesafb.0: EARLY resume
[ 43.804348] i8042 i8042: EARLY resume
[ 43.804460] PM: Image restored successfully.
[ 43.924837] acpi acpi_system:00: resuming
[ 43.924946] button button_power:00: resuming
[ 43.925054] processor ACPI0007:00: resuming
[ 43.925161] processor ACPI0007:01: resuming
[ 43.925268] acpi device:00: resuming
[--snip--]
Hmm, it looks like i8042 is the last thing on the dpm_off_irq list. Still,
if the ACPI resume fails, the next messages may not make it to the console
(it's not very probable, though).
I've tried to reproduce your problem on another box on which I have no PS/2
keyboard (USB keyboard/mouse only) and the USB legacy support set, but I can't.
There must be something very special in your configuration.
Have you tried the patch that I posted some time ago (appended again for
convenience)?
Rafael
drivers/input/serio/i8042.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
===
--- linux-2.6.21-rc6.orig/drivers/input/serio/i8042.c 2007-04-07
12:15:19.0 +0200
+++ linux-2.6.21-rc6/drivers/input/serio/i8042.c2007-04-15
18:30:01.0 +0200
@@ -846,7 +846,8 @@ static long i8042_panic_blink(long count
static int i8042_suspend(struct platform_device *dev, pm_message_t state)
{
if (dev-dev.power.power_state.event != state.event) {
- if (state.event == PM_EVENT_SUSPEND)
+ if (state.event == PM_EVENT_SUSPEND
+ || state.event == PM_EVENT_PRETHAW)
i8042_controller_reset();
Re: Linux 2.6.21-rc6
On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote:
> Rafael J. Wysocki wrote:
> > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
> > > Rafael J. Wysocki wrote:
> > > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
> > > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
> > > > > > Tobias Diedrich wrote:
> > > > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
> > > > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5
> > > > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > > > > > > Date: Sat Feb 10 01:43:32 2007 -0800
> > > > > > > >
> > > > > > > > [PATCH] swsusp: Change code ordering in disk.c
> > > > > > > >
> > > > > > > > Change the ordering of code in kernel/power/disk.c so that
> > > > > > > > device_suspend() is
> > > > > > > > called before disable_nonboot_cpus() and platform_finish()
> > > > > > > > is called after
> > > > > > > > enable_nonboot_cpus() and before device_resume(), as
> > > > > > > > indicated by the recent
> > > > > > > > discussion on Linux-PM (cf.
> > > > > > > >
> > > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html).
> > > > > > > >
> > > > > > > > The changes here only affect the built-in swsusp.
> > > > > > > >
> > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load]
> > > > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]>
> > > > > > > > Cc: Greg KH <[EMAIL PROTECTED]>
> > > > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]>
> > > > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]>
> > > > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]>
> > > > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> > > > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
> > > > > > > >
> > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18
> > > > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel
> > > > > > > >
> > > > > > > >
> > > > > > > > Now, the remaining test is to try reverting this commit from
> > > > > > > > -rc6. :)
> > > > > > >
> > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when
> > > > > > > reverted from -rc1.
> > > > > >
> > > > > > Now, this was already reported in
> > > > > > http://lkml.org/lkml/2007/3/16/126
> > > > > > and I even flagged that message in my local folder, but apparently
> > > > > > forgot
> > > > > > to follow up on it... *sigh*
> > > > >
> > > > > Unless I misunderstood something, all of the problems Maxim described
> > > > > in
> > > > > this email are fixed for him in -rc6.
> > > > >
> > > > > But it's quite possible that you are running into a different issue
> > > > > exposed by this commit.
> > > >
> > > > Yes, it's likely.
> > > >
> > > > Tobias, I'm unable to reproduce the problem with your .config, but my
> > > > hardware
> > > > is certainly different. Which suspend mode do you use? If that's
> > > > "platform",
> > > > can you try to use "shutdown" or "reboot" and see if that helps?
> > >
> > > Sure.
> > > shutdown/reboot works fine, only platform is broken.
> >
> > Thanks.
> >
> > Now, I suspect the problem is somehow related to the hardware, so it would
> > help
> > a lot if we could identify the piece of hardware (or driver) involved.
> >
> > AFAICT, your system is a non-SMP one, so we can rule out
> > disable/enable_nonboot_cpus(). To confirm that the problem is related to
> > platform_finish(), can you please apply the appended debug patch and
> > see if the suspend in the 'platform' mode works with it?
>
> Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
> single core CPU.
>
> > Also, would that be feasible for you to use 'shutdown' as a workaround in
> > case
> > the source of the problem is difficult to find and/or fix?
>
> I guess so, but the below patch fixes the problem. :)
Well, I thought it would, but it also would break some other people's systems.
That's the _real_ problem. Let's see if we can learn more.
Can you please revert it for now, apply the appended one and try to
suspend/resume twice in the 'platform' mode (it may or may not work)?
Rafael
---
kernel/power/disk.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6.21-rc6/kernel/power/disk.c
===
--- linux-2.6.21-rc6.orig/kernel/power/disk.c
+++ linux-2.6.21-rc6/kernel/power/disk.c
@@ -267,12 +267,15 @@ static int software_resume(void)
error = swsusp_read();
if (error) {
swsusp_free();
- platform_finish();
goto Thaw;
}
pr_debug("PM: Preparing devices for restore.\n");
+ error = platform_prepare();
+ if (error)
+ goto Thaw;
+
suspend_console();
error =
Re: Linux 2.6.21-rc6
Rafael J. Wysocki wrote:
> On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
> > Rafael J. Wysocki wrote:
> > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
> > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
> > > > > Tobias Diedrich wrote:
> > > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
> > > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5
> > > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > > > > > Date: Sat Feb 10 01:43:32 2007 -0800
> > > > > > >
> > > > > > > [PATCH] swsusp: Change code ordering in disk.c
> > > > > > >
> > > > > > > Change the ordering of code in kernel/power/disk.c so that
> > > > > > > device_suspend() is
> > > > > > > called before disable_nonboot_cpus() and platform_finish() is
> > > > > > > called after
> > > > > > > enable_nonboot_cpus() and before device_resume(), as
> > > > > > > indicated by the recent
> > > > > > > discussion on Linux-PM (cf.
> > > > > > >
> > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html).
> > > > > > >
> > > > > > > The changes here only affect the built-in swsusp.
> > > > > > >
> > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load]
> > > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]>
> > > > > > > Cc: Greg KH <[EMAIL PROTECTED]>
> > > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]>
> > > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]>
> > > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]>
> > > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> > > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
> > > > > > >
> > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18
> > > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel
> > > > > > >
> > > > > > >
> > > > > > > Now, the remaining test is to try reverting this commit from
> > > > > > > -rc6. :)
> > > > > >
> > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when
> > > > > > reverted from -rc1.
> > > > >
> > > > > Now, this was already reported in
> > > > > http://lkml.org/lkml/2007/3/16/126
> > > > > and I even flagged that message in my local folder, but apparently
> > > > > forgot
> > > > > to follow up on it... *sigh*
> > > >
> > > > Unless I misunderstood something, all of the problems Maxim described
> > > > in
> > > > this email are fixed for him in -rc6.
> > > >
> > > > But it's quite possible that you are running into a different issue
> > > > exposed by this commit.
> > >
> > > Yes, it's likely.
> > >
> > > Tobias, I'm unable to reproduce the problem with your .config, but my
> > > hardware
> > > is certainly different. Which suspend mode do you use? If that's
> > > "platform",
> > > can you try to use "shutdown" or "reboot" and see if that helps?
> >
> > Sure.
> > shutdown/reboot works fine, only platform is broken.
>
> Thanks.
>
> Now, I suspect the problem is somehow related to the hardware, so it would
> help
> a lot if we could identify the piece of hardware (or driver) involved.
>
> AFAICT, your system is a non-SMP one, so we can rule out
> disable/enable_nonboot_cpus(). To confirm that the problem is related to
> platform_finish(), can you please apply the appended debug patch and
> see if the suspend in the 'platform' mode works with it?
Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
single core CPU.
> Also, would that be feasible for you to use 'shutdown' as a workaround in case
> the source of the problem is difficult to find and/or fix?
I guess so, but the below patch fixes the problem. :)
> ---
> kernel/power/disk.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Index: linux-2.6.21-rc6/kernel/power/disk.c
> ===
> --- linux-2.6.21-rc6.orig/kernel/power/disk.c
> +++ linux-2.6.21-rc6/kernel/power/disk.c
> @@ -170,8 +170,8 @@ int pm_suspend_disk(void)
>
> if (in_suspend) {
> enable_nonboot_cpus();
> - platform_finish();
> device_resume();
> + platform_finish();
> resume_console();
> pr_debug("PM: writing image.\n");
> error = swsusp_write();
> @@ -189,8 +189,8 @@ int pm_suspend_disk(void)
> Enable_cpus:
> enable_nonboot_cpus();
> Resume_devices:
> - platform_finish();
> device_resume();
> + platform_finish();
> resume_console();
> Thaw:
> unprepare_processes();
>
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
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
Re: Linux 2.6.21-rc6
On Saturday, 14 April 2007 22:25, Adrian Bunk wrote: > On Sat, Apr 14, 2007 at 10:23:31PM +0200, Rafael J. Wysocki wrote: > >... > > Also, would that be feasible for you to use 'shutdown' as a workaround in > > case > > the source of the problem is difficult to find and/or fix? > > One person reporting a regression against a -rc kernel can mean > houndreds or thousands of people who will run into the same issue after > 2.6.21 got released if a manual workaround is required... Well, in this particular case it is not very likely to happen. I have three x86_64 machines here with totally different chipsets/devices on which I'm not seeing anything like that and I believe we'd have more reports before if that were a common issue. That said, I'm not going to ignore it. I'll do my best to debug and fix it, if Tobias helps me. :-) Greetings, Rafael - 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/
Re: Linux 2.6.21-rc6
On Sat, Apr 14, 2007 at 10:23:31PM +0200, Rafael J. Wysocki wrote: >... > Also, would that be feasible for you to use 'shutdown' as a workaround in case > the source of the problem is difficult to find and/or fix? One person reporting a regression against a -rc kernel can mean houndreds or thousands of people who will run into the same issue after 2.6.21 got released if a manual workaround is required... > Rafael cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: Linux 2.6.21-rc6
On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
> Rafael J. Wysocki wrote:
> > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
> > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
> > > > Tobias Diedrich wrote:
> > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
> > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5
> > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > > > > Date: Sat Feb 10 01:43:32 2007 -0800
> > > > > >
> > > > > > [PATCH] swsusp: Change code ordering in disk.c
> > > > > >
> > > > > > Change the ordering of code in kernel/power/disk.c so that
> > > > > > device_suspend() is
> > > > > > called before disable_nonboot_cpus() and platform_finish() is
> > > > > > called after
> > > > > > enable_nonboot_cpus() and before device_resume(), as indicated
> > > > > > by the recent
> > > > > > discussion on Linux-PM (cf.
> > > > > >
> > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html).
> > > > > >
> > > > > > The changes here only affect the built-in swsusp.
> > > > > >
> > > > > > [EMAIL PROTECTED]: fix LED blinking during image load]
> > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]>
> > > > > > Cc: Greg KH <[EMAIL PROTECTED]>
> > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]>
> > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]>
> > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]>
> > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
> > > > > >
> > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18
> > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel
> > > > > >
> > > > > >
> > > > > > Now, the remaining test is to try reverting this commit from -rc6.
> > > > > > :)
> > > > >
> > > > > Doesn't apply cleanly against -rc6, but fixes the problem when
> > > > > reverted from -rc1.
> > > >
> > > > Now, this was already reported in
> > > > http://lkml.org/lkml/2007/3/16/126
> > > > and I even flagged that message in my local folder, but apparently
> > > > forgot
> > > > to follow up on it... *sigh*
> > >
> > > Unless I misunderstood something, all of the problems Maxim described in
> > > this email are fixed for him in -rc6.
> > >
> > > But it's quite possible that you are running into a different issue
> > > exposed by this commit.
> >
> > Yes, it's likely.
> >
> > Tobias, I'm unable to reproduce the problem with your .config, but my
> > hardware
> > is certainly different. Which suspend mode do you use? If that's
> > "platform",
> > can you try to use "shutdown" or "reboot" and see if that helps?
>
> Sure.
> shutdown/reboot works fine, only platform is broken.
Thanks.
Now, I suspect the problem is somehow related to the hardware, so it would help
a lot if we could identify the piece of hardware (or driver) involved.
AFAICT, your system is a non-SMP one, so we can rule out
disable/enable_nonboot_cpus(). To confirm that the problem is related to
platform_finish(), can you please apply the appended debug patch and
see if the suspend in the 'platform' mode works with it?
Also, would that be feasible for you to use 'shutdown' as a workaround in case
the source of the problem is difficult to find and/or fix?
Rafael
---
kernel/power/disk.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.21-rc6/kernel/power/disk.c
===
--- linux-2.6.21-rc6.orig/kernel/power/disk.c
+++ linux-2.6.21-rc6/kernel/power/disk.c
@@ -170,8 +170,8 @@ int pm_suspend_disk(void)
if (in_suspend) {
enable_nonboot_cpus();
- platform_finish();
device_resume();
+ platform_finish();
resume_console();
pr_debug("PM: writing image.\n");
error = swsusp_write();
@@ -189,8 +189,8 @@ int pm_suspend_disk(void)
Enable_cpus:
enable_nonboot_cpus();
Resume_devices:
- platform_finish();
device_resume();
+ platform_finish();
resume_console();
Thaw:
unprepare_processes();
-
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/
Re: Linux 2.6.21-rc6
Rafael J. Wysocki wrote: > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > > Tobias Diedrich wrote: > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > > > Change the ordering of code in kernel/power/disk.c so that > > > > > device_suspend() is > > > > > called before disable_nonboot_cpus() and platform_finish() is > > > > > called after > > > > > enable_nonboot_cpus() and before device_resume(), as indicated by > > > > > the recent > > > > > discussion on Linux-PM (cf. > > > > > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > > > > Now, the remaining test is to try reverting this commit from -rc6. :) > > > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > > > reverted from -rc1. > > > > > > Now, this was already reported in > > > http://lkml.org/lkml/2007/3/16/126 > > > and I even flagged that message in my local folder, but apparently forgot > > > to follow up on it... *sigh* > > > > Unless I misunderstood something, all of the problems Maxim described in > > this email are fixed for him in -rc6. > > > > But it's quite possible that you are running into a different issue > > exposed by this commit. > > Yes, it's likely. > > Tobias, I'm unable to reproduce the problem with your .config, but my hardware > is certainly different. Which suspend mode do you use? If that's "platform", > can you try to use "shutdown" or "reboot" and see if that helps? Sure. shutdown/reboot works fine, only platform is broken. -- Tobias PGP: http://9ac7e0bc.uguu.de - 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/
Re: Linux 2.6.21-rc6
On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > Tobias Diedrich wrote: > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > Change the ordering of code in kernel/power/disk.c so that > > > > device_suspend() is > > > > called before disable_nonboot_cpus() and platform_finish() is > > > > called after > > > > enable_nonboot_cpus() and before device_resume(), as indicated by > > > > the recent > > > > discussion on Linux-PM (cf. > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > Now, the remaining test is to try reverting this commit from -rc6. :) > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > > reverted from -rc1. > > > > Now, this was already reported in > > http://lkml.org/lkml/2007/3/16/126 > > and I even flagged that message in my local folder, but apparently forgot > > to follow up on it... *sigh* > > Unless I misunderstood something, all of the problems Maxim described in > this email are fixed for him in -rc6. > > But it's quite possible that you are running into a different issue > exposed by this commit. Yes, it's likely. Tobias, I'm unable to reproduce the problem with your .config, but my hardware is certainly different. Which suspend mode do you use? If that's "platform", can you try to use "shutdown" or "reboot" and see if that helps? Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - 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/
Re: Linux 2.6.21-rc6
On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > Tobias Diedrich wrote: > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > Change the ordering of code in kernel/power/disk.c so that > > > device_suspend() is > > > called before disable_nonboot_cpus() and platform_finish() is called > > > after > > > enable_nonboot_cpus() and before device_resume(), as indicated by the > > > recent > > > discussion on Linux-PM (cf. > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > The changes here only affect the built-in swsusp. > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > Now, the remaining test is to try reverting this commit from -rc6. :) > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > reverted from -rc1. > > Now, this was already reported in > http://lkml.org/lkml/2007/3/16/126 > and I even flagged that message in my local folder, but apparently forgot > to follow up on it... *sigh* Unless I misunderstood something, all of the problems Maxim described in this email are fixed for him in -rc6. But it's quite possible that you are running into a different issue exposed by this commit. > Tobias cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: Linux 2.6.21-rc6
Tobias Diedrich wrote: > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > Change the ordering of code in kernel/power/disk.c so that > > device_suspend() is > > called before disable_nonboot_cpus() and platform_finish() is called > > after > > enable_nonboot_cpus() and before device_resume(), as indicated by the > > recent > > discussion on Linux-PM (cf. > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > The changes here only affect the built-in swsusp. > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > Cc: Greg KH <[EMAIL PROTECTED]> > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > Now, the remaining test is to try reverting this commit from -rc6. :) > > Doesn't apply cleanly against -rc6, but fixes the problem when > reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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/
Re: Linux 2.6.21-rc6
On Sat, Apr 14, 2007 at 10:16:19AM +0200, Tobias Diedrich wrote: > Adrian Bunk wrote: > > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: > > > Linus Torvalds wrote: > > > > > > > We should be getting close to a 2.6.21 release, so please update any > > > > regression reports you've done, > > > > > > For me, suspend to disk works only once (has been the case for all > > > .21-rcs IIRC, but I didn't get around to report it so far). > > > There are some threads about an issue like this, which is supposed > > > to be fixed by disabling CONFIG_PCI_MSI, but on my system the > > > problem persists nonetheless. > > > > > > On the second suspend attempt, the last message I see is > > > "Suspending console(s)" > > > > > > If I find the time, I'll try to bisect it this weekend. > > >... > > > > Does the latest -git work? > > Still no luck with > Linux melchior 2.6.21-rc6-gd791d413-dirty #4 PREEMPT Sat Apr 14 09:34:21 CEST > 2007 x86_64 GNU/Linux > Why -dirty? Maybe because I modified the Makefile to use ccache? > > > Does CONFIG_HPET_TIMER=n make any difference? > > Hmm, I just noticed that CONFIG_HPET_TIMER was forced back on after > make oldconfig... Is that expected on amd64? >... Yes it is (on i386 you can disable it). Sorry that I missed this. > TobiasPGP: > http://9ac7e0bc.uguu.de cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: Linux 2.6.21-rc6
Tobias Diedrich wrote:
> Adrian Bunk wrote:
> > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
> > > Linus Torvalds wrote:
> > >
> > > > We should be getting close to a 2.6.21 release, so please update any
> > > > regression reports you've done,
> > >
> > > For me, suspend to disk works only once (has been the case for all
> > > .21-rcs IIRC, but I didn't get around to report it so far).
> > > There are some threads about an issue like this, which is supposed
> > > to be fixed by disabling CONFIG_PCI_MSI, but on my system the
> > > problem persists nonetheless.
> > >
> > > On the second suspend attempt, the last message I see is
> > > "Suspending console(s)"
> > >
> > > If I find the time, I'll try to bisect it this weekend.
> > >...
> >
> > Does CONFIG_HPET_TIMER=n make any difference?
> > Does the latest -git work?
>
> bisect results:
>
> git-bisect start
> # good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20
> git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7
> # bad: [2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba] Linux 2.6.21-rc1
> git-bisect bad 2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba
> # bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of
> git://ftp.linux-mips.org/pub/scm/upstream-linus
> git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8
> # good: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge
> master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6
> git-bisect good 43187902cbfafe73ede0144166b741fb0f7d04e1
> # good: [beda9f3a13bbb22cde92a45f230a02ef2afef6a9] kbuild: more Makefile
> cleanups
> git-bisect good beda9f3a13bbb22cde92a45f230a02ef2afef6a9
> # bad: [7edc136ab688f751037a86e8a051151d7962d33f] Char: isicom, support
> higher rates
> git-bisect bad 7edc136ab688f751037a86e8a051151d7962d33f
> # good: [6267276f3fdda9ad0d5ca451bdcbdf42b802d64b] optional ZONE_DMA: deal
> with cases of ZONE_DMA meaning the first zone
> git-bisect good 6267276f3fdda9ad0d5ca451bdcbdf42b802d64b
> # bad: [b4ac91a0eac36f347a509afda07e4305e931de61] uml: chan_user.h formatting
> fixes
> git-bisect bad b4ac91a0eac36f347a509afda07e4305e931de61
> # bad: [bf0059b23fd2f0b304f647d87fad0aa626ecf0c0] M68KNOMMU: user ARRAY_SIZE
> macro when appropriate
> git-bisect bad bf0059b23fd2f0b304f647d87fad0aa626ecf0c0
> # good: [c1725f2af89f1eda3cb9007290971b55084569a4] ARM26: Use ARRAY_SIZE
> macro when appropriate
> git-bisect good c1725f2af89f1eda3cb9007290971b55084569a4
> # bad: [9b87ed790714bd3a8d492feb24f6c48f8bb59c3a] m32r: fix do_page_fault and
> update_mmu_cache
> git-bisect bad 9b87ed790714bd3a8d492feb24f6c48f8bb59c3a
> # bad: [d12c610e08022a1b84d6bd4412c189214d32e713]
> swsusp-change-code-ordering-in-userc-sanity
> git-bisect bad d12c610e08022a1b84d6bd4412c189214d32e713
> # bad: [ed746e3b18f4df18afa3763155972c5835f284c5] swsusp: Change code
> ordering in disk.c
> git-bisect bad ed746e3b18f4df18afa3763155972c5835f284c5
> # good: [e3c7db621bed4afb8e231cb005057f2feb5db557] PM: Change code ordering
> in main.c
> git-bisect good e3c7db621bed4afb8e231cb005057f2feb5db557
>
>
> ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
> commit ed746e3b18f4df18afa3763155972c5835f284c5
> Author: Rafael J. Wysocki <[EMAIL PROTECTED]>
> Date: Sat Feb 10 01:43:32 2007 -0800
>
> [PATCH] swsusp: Change code ordering in disk.c
>
> Change the ordering of code in kernel/power/disk.c so that
> device_suspend() is
> called before disable_nonboot_cpus() and platform_finish() is called after
> enable_nonboot_cpus() and before device_resume(), as indicated by the
> recent
> discussion on Linux-PM (cf.
> http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html).
>
> The changes here only affect the built-in swsusp.
>
> [EMAIL PROTECTED]: fix LED blinking during image load]
> Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
> Acked-by: Pavel Machek <[EMAIL PROTECTED]>
> Cc: Greg KH <[EMAIL PROTECTED]>
> Cc: Nigel Cunningham <[EMAIL PROTECTED]>
> Cc: Patrick Mochel <[EMAIL PROTECTED]>
> Cc: Alexey Starikovskiy <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
>
> :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18
> 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel
>
>
> Now, the remaining test is to try reverting this commit from -rc6. :)
Doesn't apply cleanly against -rc6, but fixes the problem when
reverted from -rc1.
Index: linux-2.6.21-rc1/kernel/power/disk.c
===
--- linux-2.6.21-rc1.orig/kernel/power/disk.c 2007-04-14 14:16:59.0
+0200
+++ linux-2.6.21-rc1/kernel/power/disk.c2007-04-14 14:17:03.0
+0200
@@ -87,24 +87,52 @@
}
}
-static void unprepare_processes(void)
-{
- thaw_processes();
- pm_restore_console();
-}
-
static int prepare_processes(void)
{
Re: Linux 2.6.21-rc6
Adrian Bunk wrote: > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: > > Linus Torvalds wrote: > > > > > We should be getting close to a 2.6.21 release, so please update any > > > regression reports you've done, > > > > For me, suspend to disk works only once (has been the case for all > > .21-rcs IIRC, but I didn't get around to report it so far). > > There are some threads about an issue like this, which is supposed > > to be fixed by disabling CONFIG_PCI_MSI, but on my system the > > problem persists nonetheless. > > > > On the second suspend attempt, the last message I see is > > "Suspending console(s)" > > > > If I find the time, I'll try to bisect it this weekend. > >... > > Does CONFIG_HPET_TIMER=n make any difference? > Does the latest -git work? bisect results: git-bisect start # good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20 git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7 # bad: [2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba] Linux 2.6.21-rc1 git-bisect bad 2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba # bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8 # good: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6 git-bisect good 43187902cbfafe73ede0144166b741fb0f7d04e1 # good: [beda9f3a13bbb22cde92a45f230a02ef2afef6a9] kbuild: more Makefile cleanups git-bisect good beda9f3a13bbb22cde92a45f230a02ef2afef6a9 # bad: [7edc136ab688f751037a86e8a051151d7962d33f] Char: isicom, support higher rates git-bisect bad 7edc136ab688f751037a86e8a051151d7962d33f # good: [6267276f3fdda9ad0d5ca451bdcbdf42b802d64b] optional ZONE_DMA: deal with cases of ZONE_DMA meaning the first zone git-bisect good 6267276f3fdda9ad0d5ca451bdcbdf42b802d64b # bad: [b4ac91a0eac36f347a509afda07e4305e931de61] uml: chan_user.h formatting fixes git-bisect bad b4ac91a0eac36f347a509afda07e4305e931de61 # bad: [bf0059b23fd2f0b304f647d87fad0aa626ecf0c0] M68KNOMMU: user ARRAY_SIZE macro when appropriate git-bisect bad bf0059b23fd2f0b304f647d87fad0aa626ecf0c0 # good: [c1725f2af89f1eda3cb9007290971b55084569a4] ARM26: Use ARRAY_SIZE macro when appropriate git-bisect good c1725f2af89f1eda3cb9007290971b55084569a4 # bad: [9b87ed790714bd3a8d492feb24f6c48f8bb59c3a] m32r: fix do_page_fault and update_mmu_cache git-bisect bad 9b87ed790714bd3a8d492feb24f6c48f8bb59c3a # bad: [d12c610e08022a1b84d6bd4412c189214d32e713] swsusp-change-code-ordering-in-userc-sanity git-bisect bad d12c610e08022a1b84d6bd4412c189214d32e713 # bad: [ed746e3b18f4df18afa3763155972c5835f284c5] swsusp: Change code ordering in disk.c git-bisect bad ed746e3b18f4df18afa3763155972c5835f284c5 # good: [e3c7db621bed4afb8e231cb005057f2feb5db557] PM: Change code ordering in main.c git-bisect good e3c7db621bed4afb8e231cb005057f2feb5db557 ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki <[EMAIL PROTECTED]> Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> Acked-by: Pavel Machek <[EMAIL PROTECTED]> Cc: Greg KH <[EMAIL PROTECTED]> Cc: Nigel Cunningham <[EMAIL PROTECTED]> Cc: Patrick Mochel <[EMAIL PROTECTED]> Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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/
Re: Linux 2.6.21-rc6
Rafael J. Wysocki wrote: > On Saturday, 14 April 2007 10:16, Tobias Diedrich wrote: > > Adrian Bunk wrote: > > > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: > > > > Linus Torvalds wrote: > > > > > > > > > We should be getting close to a 2.6.21 release, so please update any > > > > > regression reports you've done, > > > > > > > > For me, suspend to disk works only once (has been the case for all > > > > .21-rcs IIRC, but I didn't get around to report it so far). > > > > There are some threads about an issue like this, which is supposed > > > > to be fixed by disabling CONFIG_PCI_MSI, but on my system the > > > > problem persists nonetheless. > > > > > > > > On the second suspend attempt, the last message I see is > > > > "Suspending console(s)" > > > > > > > > If I find the time, I'll try to bisect it this weekend. > > > >... > > > > > > Does the latest -git work? > > > > Still no luck with > > Linux melchior 2.6.21-rc6-gd791d413-dirty #4 PREEMPT Sat Apr 14 09:34:21 > > CEST 2007 x86_64 GNU/Linux > > Can you boot with init=/bin/bash and see if the problem is present in this > configuration? Doesn't help. Maybe interesting: In the init=/bin/bash run, the first suspend try was without swap and thus bailed out. After swapon, the second try already hung, despite not having 'really' suspended at all on the first try. I tried it once more, with swap on the first try and got the same 'second try doesn't work' result. git-bisect so far: git-bisect start # good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20 git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7 # bad: [2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba] Linux 2.6.21-rc1 git-bisect bad 2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba # bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8 # good: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6 git-bisect good 43187902cbfafe73ede0144166b741fb0f7d04e1 # good: [beda9f3a13bbb22cde92a45f230a02ef2afef6a9] kbuild: more Makefile cleanups git-bisect good beda9f3a13bbb22cde92a45f230a02ef2afef6a9 # bad: [7edc136ab688f751037a86e8a051151d7962d33f] Char: isicom, support higher rates git-bisect bad 7edc136ab688f751037a86e8a051151d7962d33f -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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/
Re: Linux 2.6.21-rc6
On Saturday, 14 April 2007 10:16, Tobias Diedrich wrote: > Adrian Bunk wrote: > > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: > > > Linus Torvalds wrote: > > > > > > > We should be getting close to a 2.6.21 release, so please update any > > > > regression reports you've done, > > > > > > For me, suspend to disk works only once (has been the case for all > > > .21-rcs IIRC, but I didn't get around to report it so far). > > > There are some threads about an issue like this, which is supposed > > > to be fixed by disabling CONFIG_PCI_MSI, but on my system the > > > problem persists nonetheless. > > > > > > On the second suspend attempt, the last message I see is > > > "Suspending console(s)" > > > > > > If I find the time, I'll try to bisect it this weekend. > > >... > > > > Does the latest -git work? > > Still no luck with > Linux melchior 2.6.21-rc6-gd791d413-dirty #4 PREEMPT Sat Apr 14 09:34:21 CEST > 2007 x86_64 GNU/Linux Can you boot with init=/bin/bash and see if the problem is present in this configuration? Rafael - 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/
Re: Linux 2.6.21-rc6
Adrian Bunk wrote: > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: > > Linus Torvalds wrote: > > > > > We should be getting close to a 2.6.21 release, so please update any > > > regression reports you've done, > > > > For me, suspend to disk works only once (has been the case for all > > .21-rcs IIRC, but I didn't get around to report it so far). > > There are some threads about an issue like this, which is supposed > > to be fixed by disabling CONFIG_PCI_MSI, but on my system the > > problem persists nonetheless. > > > > On the second suspend attempt, the last message I see is > > "Suspending console(s)" > > > > If I find the time, I'll try to bisect it this weekend. > >... > > Does the latest -git work? Still no luck with Linux melchior 2.6.21-rc6-gd791d413-dirty #4 PREEMPT Sat Apr 14 09:34:21 CEST 2007 x86_64 GNU/Linux Why -dirty? Maybe because I modified the Makefile to use ccache? > Does CONFIG_HPET_TIMER=n make any difference? Hmm, I just noticed that CONFIG_HPET_TIMER was forced back on after make oldconfig... Is that expected on amd64? # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc6 # Sat Apr 14 09:33:36 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_X86_MCE_AMD=y CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x20 # CONFIG_SECCOMP is not set # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300 CONFIG_REORDER=y CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y # # Power
Re: Linux 2.6.21-rc6
Adrian Bunk wrote: > Does CONFIG_HPET_TIMER=n make any difference? Unfortunately not. > Does the latest -git work? Coming up next :) -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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/
Re: Linux 2.6.21-rc6
Adrian Bunk wrote: Does CONFIG_HPET_TIMER=n make any difference? Unfortunately not. Does the latest -git work? Coming up next :) -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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/
Re: Linux 2.6.21-rc6
Adrian Bunk wrote: On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: Linus Torvalds wrote: We should be getting close to a 2.6.21 release, so please update any regression reports you've done, For me, suspend to disk works only once (has been the case for all .21-rcs IIRC, but I didn't get around to report it so far). There are some threads about an issue like this, which is supposed to be fixed by disabling CONFIG_PCI_MSI, but on my system the problem persists nonetheless. On the second suspend attempt, the last message I see is Suspending console(s) If I find the time, I'll try to bisect it this weekend. ... Does the latest -git work? Still no luck with Linux melchior 2.6.21-rc6-gd791d413-dirty #4 PREEMPT Sat Apr 14 09:34:21 CEST 2007 x86_64 GNU/Linux Why -dirty? Maybe because I modified the Makefile to use ccache? Does CONFIG_HPET_TIMER=n make any difference? Hmm, I just noticed that CONFIG_HPET_TIMER was forced back on after make oldconfig... Is that expected on amd64? # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc6 # Sat Apr 14 09:33:36 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_X86_MCE_AMD=y CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x20 # CONFIG_SECCOMP is not set # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300 CONFIG_REORDER=y CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y # # Power management options # CONFIG_PM=y #
Re: Linux 2.6.21-rc6
On Saturday, 14 April 2007 10:16, Tobias Diedrich wrote: Adrian Bunk wrote: On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: Linus Torvalds wrote: We should be getting close to a 2.6.21 release, so please update any regression reports you've done, For me, suspend to disk works only once (has been the case for all .21-rcs IIRC, but I didn't get around to report it so far). There are some threads about an issue like this, which is supposed to be fixed by disabling CONFIG_PCI_MSI, but on my system the problem persists nonetheless. On the second suspend attempt, the last message I see is Suspending console(s) If I find the time, I'll try to bisect it this weekend. ... Does the latest -git work? Still no luck with Linux melchior 2.6.21-rc6-gd791d413-dirty #4 PREEMPT Sat Apr 14 09:34:21 CEST 2007 x86_64 GNU/Linux Can you boot with init=/bin/bash and see if the problem is present in this configuration? Rafael - 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/
Re: Linux 2.6.21-rc6
Rafael J. Wysocki wrote: On Saturday, 14 April 2007 10:16, Tobias Diedrich wrote: Adrian Bunk wrote: On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: Linus Torvalds wrote: We should be getting close to a 2.6.21 release, so please update any regression reports you've done, For me, suspend to disk works only once (has been the case for all .21-rcs IIRC, but I didn't get around to report it so far). There are some threads about an issue like this, which is supposed to be fixed by disabling CONFIG_PCI_MSI, but on my system the problem persists nonetheless. On the second suspend attempt, the last message I see is Suspending console(s) If I find the time, I'll try to bisect it this weekend. ... Does the latest -git work? Still no luck with Linux melchior 2.6.21-rc6-gd791d413-dirty #4 PREEMPT Sat Apr 14 09:34:21 CEST 2007 x86_64 GNU/Linux Can you boot with init=/bin/bash and see if the problem is present in this configuration? Doesn't help. Maybe interesting: In the init=/bin/bash run, the first suspend try was without swap and thus bailed out. After swapon, the second try already hung, despite not having 'really' suspended at all on the first try. I tried it once more, with swap on the first try and got the same 'second try doesn't work' result. git-bisect so far: git-bisect start # good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20 git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7 # bad: [2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba] Linux 2.6.21-rc1 git-bisect bad 2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba # bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8 # good: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6 git-bisect good 43187902cbfafe73ede0144166b741fb0f7d04e1 # good: [beda9f3a13bbb22cde92a45f230a02ef2afef6a9] kbuild: more Makefile cleanups git-bisect good beda9f3a13bbb22cde92a45f230a02ef2afef6a9 # bad: [7edc136ab688f751037a86e8a051151d7962d33f] Char: isicom, support higher rates git-bisect bad 7edc136ab688f751037a86e8a051151d7962d33f -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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/
Re: Linux 2.6.21-rc6
Adrian Bunk wrote: On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: Linus Torvalds wrote: We should be getting close to a 2.6.21 release, so please update any regression reports you've done, For me, suspend to disk works only once (has been the case for all .21-rcs IIRC, but I didn't get around to report it so far). There are some threads about an issue like this, which is supposed to be fixed by disabling CONFIG_PCI_MSI, but on my system the problem persists nonetheless. On the second suspend attempt, the last message I see is Suspending console(s) If I find the time, I'll try to bisect it this weekend. ... Does CONFIG_HPET_TIMER=n make any difference? Does the latest -git work? bisect results: git-bisect start # good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20 git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7 # bad: [2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba] Linux 2.6.21-rc1 git-bisect bad 2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba # bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8 # good: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6 git-bisect good 43187902cbfafe73ede0144166b741fb0f7d04e1 # good: [beda9f3a13bbb22cde92a45f230a02ef2afef6a9] kbuild: more Makefile cleanups git-bisect good beda9f3a13bbb22cde92a45f230a02ef2afef6a9 # bad: [7edc136ab688f751037a86e8a051151d7962d33f] Char: isicom, support higher rates git-bisect bad 7edc136ab688f751037a86e8a051151d7962d33f # good: [6267276f3fdda9ad0d5ca451bdcbdf42b802d64b] optional ZONE_DMA: deal with cases of ZONE_DMA meaning the first zone git-bisect good 6267276f3fdda9ad0d5ca451bdcbdf42b802d64b # bad: [b4ac91a0eac36f347a509afda07e4305e931de61] uml: chan_user.h formatting fixes git-bisect bad b4ac91a0eac36f347a509afda07e4305e931de61 # bad: [bf0059b23fd2f0b304f647d87fad0aa626ecf0c0] M68KNOMMU: user ARRAY_SIZE macro when appropriate git-bisect bad bf0059b23fd2f0b304f647d87fad0aa626ecf0c0 # good: [c1725f2af89f1eda3cb9007290971b55084569a4] ARM26: Use ARRAY_SIZE macro when appropriate git-bisect good c1725f2af89f1eda3cb9007290971b55084569a4 # bad: [9b87ed790714bd3a8d492feb24f6c48f8bb59c3a] m32r: fix do_page_fault and update_mmu_cache git-bisect bad 9b87ed790714bd3a8d492feb24f6c48f8bb59c3a # bad: [d12c610e08022a1b84d6bd4412c189214d32e713] swsusp-change-code-ordering-in-userc-sanity git-bisect bad d12c610e08022a1b84d6bd4412c189214d32e713 # bad: [ed746e3b18f4df18afa3763155972c5835f284c5] swsusp: Change code ordering in disk.c git-bisect bad ed746e3b18f4df18afa3763155972c5835f284c5 # good: [e3c7db621bed4afb8e231cb005057f2feb5db557] PM: Change code ordering in main.c git-bisect good e3c7db621bed4afb8e231cb005057f2feb5db557 ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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/
Re: Linux 2.6.21-rc6
Tobias Diedrich wrote:
Adrian Bunk wrote:
On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
Linus Torvalds wrote:
We should be getting close to a 2.6.21 release, so please update any
regression reports you've done,
For me, suspend to disk works only once (has been the case for all
.21-rcs IIRC, but I didn't get around to report it so far).
There are some threads about an issue like this, which is supposed
to be fixed by disabling CONFIG_PCI_MSI, but on my system the
problem persists nonetheless.
On the second suspend attempt, the last message I see is
Suspending console(s)
If I find the time, I'll try to bisect it this weekend.
...
Does CONFIG_HPET_TIMER=n make any difference?
Does the latest -git work?
bisect results:
git-bisect start
# good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20
git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7
# bad: [2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba] Linux 2.6.21-rc1
git-bisect bad 2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba
# bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of
git://ftp.linux-mips.org/pub/scm/upstream-linus
git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8
# good: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6
git-bisect good 43187902cbfafe73ede0144166b741fb0f7d04e1
# good: [beda9f3a13bbb22cde92a45f230a02ef2afef6a9] kbuild: more Makefile
cleanups
git-bisect good beda9f3a13bbb22cde92a45f230a02ef2afef6a9
# bad: [7edc136ab688f751037a86e8a051151d7962d33f] Char: isicom, support
higher rates
git-bisect bad 7edc136ab688f751037a86e8a051151d7962d33f
# good: [6267276f3fdda9ad0d5ca451bdcbdf42b802d64b] optional ZONE_DMA: deal
with cases of ZONE_DMA meaning the first zone
git-bisect good 6267276f3fdda9ad0d5ca451bdcbdf42b802d64b
# bad: [b4ac91a0eac36f347a509afda07e4305e931de61] uml: chan_user.h formatting
fixes
git-bisect bad b4ac91a0eac36f347a509afda07e4305e931de61
# bad: [bf0059b23fd2f0b304f647d87fad0aa626ecf0c0] M68KNOMMU: user ARRAY_SIZE
macro when appropriate
git-bisect bad bf0059b23fd2f0b304f647d87fad0aa626ecf0c0
# good: [c1725f2af89f1eda3cb9007290971b55084569a4] ARM26: Use ARRAY_SIZE
macro when appropriate
git-bisect good c1725f2af89f1eda3cb9007290971b55084569a4
# bad: [9b87ed790714bd3a8d492feb24f6c48f8bb59c3a] m32r: fix do_page_fault and
update_mmu_cache
git-bisect bad 9b87ed790714bd3a8d492feb24f6c48f8bb59c3a
# bad: [d12c610e08022a1b84d6bd4412c189214d32e713]
swsusp-change-code-ordering-in-userc-sanity
git-bisect bad d12c610e08022a1b84d6bd4412c189214d32e713
# bad: [ed746e3b18f4df18afa3763155972c5835f284c5] swsusp: Change code
ordering in disk.c
git-bisect bad ed746e3b18f4df18afa3763155972c5835f284c5
# good: [e3c7db621bed4afb8e231cb005057f2feb5db557] PM: Change code ordering
in main.c
git-bisect good e3c7db621bed4afb8e231cb005057f2feb5db557
ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
commit ed746e3b18f4df18afa3763155972c5835f284c5
Author: Rafael J. Wysocki [EMAIL PROTECTED]
Date: Sat Feb 10 01:43:32 2007 -0800
[PATCH] swsusp: Change code ordering in disk.c
Change the ordering of code in kernel/power/disk.c so that
device_suspend() is
called before disable_nonboot_cpus() and platform_finish() is called after
enable_nonboot_cpus() and before device_resume(), as indicated by the
recent
discussion on Linux-PM (cf.
http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html).
The changes here only affect the built-in swsusp.
[EMAIL PROTECTED]: fix LED blinking during image load]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
Cc: Greg KH [EMAIL PROTECTED]
Cc: Nigel Cunningham [EMAIL PROTECTED]
Cc: Patrick Mochel [EMAIL PROTECTED]
Cc: Alexey Starikovskiy [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
:04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18
8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel
Now, the remaining test is to try reverting this commit from -rc6. :)
Doesn't apply cleanly against -rc6, but fixes the problem when
reverted from -rc1.
Index: linux-2.6.21-rc1/kernel/power/disk.c
===
--- linux-2.6.21-rc1.orig/kernel/power/disk.c 2007-04-14 14:16:59.0
+0200
+++ linux-2.6.21-rc1/kernel/power/disk.c2007-04-14 14:17:03.0
+0200
@@ -87,24 +87,52 @@
}
}
-static void unprepare_processes(void)
-{
- thaw_processes();
- pm_restore_console();
-}
-
static int prepare_processes(void)
{
int error = 0;
pm_prepare_console();
+
+ error = disable_nonboot_cpus();
+ if (error)
+ goto enable_cpus;
+
if
Re: Linux 2.6.21-rc6
On Sat, Apr 14, 2007 at 10:16:19AM +0200, Tobias Diedrich wrote: Adrian Bunk wrote: On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: Linus Torvalds wrote: We should be getting close to a 2.6.21 release, so please update any regression reports you've done, For me, suspend to disk works only once (has been the case for all .21-rcs IIRC, but I didn't get around to report it so far). There are some threads about an issue like this, which is supposed to be fixed by disabling CONFIG_PCI_MSI, but on my system the problem persists nonetheless. On the second suspend attempt, the last message I see is Suspending console(s) If I find the time, I'll try to bisect it this weekend. ... Does the latest -git work? Still no luck with Linux melchior 2.6.21-rc6-gd791d413-dirty #4 PREEMPT Sat Apr 14 09:34:21 CEST 2007 x86_64 GNU/Linux Why -dirty? Maybe because I modified the Makefile to use ccache? Does CONFIG_HPET_TIMER=n make any difference? Hmm, I just noticed that CONFIG_HPET_TIMER was forced back on after make oldconfig... Is that expected on amd64? ... Yes it is (on i386 you can disable it). Sorry that I missed this. TobiasPGP: http://9ac7e0bc.uguu.de cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: Linux 2.6.21-rc6
Tobias Diedrich wrote: ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) Doesn't apply cleanly against -rc6, but fixes the problem when reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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/
Re: Linux 2.6.21-rc6
On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: Tobias Diedrich wrote: ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) Doesn't apply cleanly against -rc6, but fixes the problem when reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* Unless I misunderstood something, all of the problems Maxim described in this email are fixed for him in -rc6. But it's quite possible that you are running into a different issue exposed by this commit. Tobias cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: Linux 2.6.21-rc6
On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: Tobias Diedrich wrote: ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) Doesn't apply cleanly against -rc6, but fixes the problem when reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* Unless I misunderstood something, all of the problems Maxim described in this email are fixed for him in -rc6. But it's quite possible that you are running into a different issue exposed by this commit. Yes, it's likely. Tobias, I'm unable to reproduce the problem with your .config, but my hardware is certainly different. Which suspend mode do you use? If that's platform, can you try to use shutdown or reboot and see if that helps? Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - 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/
Re: Linux 2.6.21-rc6
Rafael J. Wysocki wrote: On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: Tobias Diedrich wrote: ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) Doesn't apply cleanly against -rc6, but fixes the problem when reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* Unless I misunderstood something, all of the problems Maxim described in this email are fixed for him in -rc6. But it's quite possible that you are running into a different issue exposed by this commit. Yes, it's likely. Tobias, I'm unable to reproduce the problem with your .config, but my hardware is certainly different. Which suspend mode do you use? If that's platform, can you try to use shutdown or reboot and see if that helps? Sure. shutdown/reboot works fine, only platform is broken. -- Tobias PGP: http://9ac7e0bc.uguu.de - 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/
Re: Linux 2.6.21-rc6
On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
Rafael J. Wysocki wrote:
On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
Tobias Diedrich wrote:
ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
commit ed746e3b18f4df18afa3763155972c5835f284c5
Author: Rafael J. Wysocki [EMAIL PROTECTED]
Date: Sat Feb 10 01:43:32 2007 -0800
[PATCH] swsusp: Change code ordering in disk.c
Change the ordering of code in kernel/power/disk.c so that
device_suspend() is
called before disable_nonboot_cpus() and platform_finish() is
called after
enable_nonboot_cpus() and before device_resume(), as indicated
by the recent
discussion on Linux-PM (cf.
http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html).
The changes here only affect the built-in swsusp.
[EMAIL PROTECTED]: fix LED blinking during image load]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
Cc: Greg KH [EMAIL PROTECTED]
Cc: Nigel Cunningham [EMAIL PROTECTED]
Cc: Patrick Mochel [EMAIL PROTECTED]
Cc: Alexey Starikovskiy [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
:04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18
8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel
Now, the remaining test is to try reverting this commit from -rc6.
:)
Doesn't apply cleanly against -rc6, but fixes the problem when
reverted from -rc1.
Now, this was already reported in
http://lkml.org/lkml/2007/3/16/126
and I even flagged that message in my local folder, but apparently
forgot
to follow up on it... *sigh*
Unless I misunderstood something, all of the problems Maxim described in
this email are fixed for him in -rc6.
But it's quite possible that you are running into a different issue
exposed by this commit.
Yes, it's likely.
Tobias, I'm unable to reproduce the problem with your .config, but my
hardware
is certainly different. Which suspend mode do you use? If that's
platform,
can you try to use shutdown or reboot and see if that helps?
Sure.
shutdown/reboot works fine, only platform is broken.
Thanks.
Now, I suspect the problem is somehow related to the hardware, so it would help
a lot if we could identify the piece of hardware (or driver) involved.
AFAICT, your system is a non-SMP one, so we can rule out
disable/enable_nonboot_cpus(). To confirm that the problem is related to
platform_finish(), can you please apply the appended debug patch and
see if the suspend in the 'platform' mode works with it?
Also, would that be feasible for you to use 'shutdown' as a workaround in case
the source of the problem is difficult to find and/or fix?
Rafael
---
kernel/power/disk.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.21-rc6/kernel/power/disk.c
===
--- linux-2.6.21-rc6.orig/kernel/power/disk.c
+++ linux-2.6.21-rc6/kernel/power/disk.c
@@ -170,8 +170,8 @@ int pm_suspend_disk(void)
if (in_suspend) {
enable_nonboot_cpus();
- platform_finish();
device_resume();
+ platform_finish();
resume_console();
pr_debug(PM: writing image.\n);
error = swsusp_write();
@@ -189,8 +189,8 @@ int pm_suspend_disk(void)
Enable_cpus:
enable_nonboot_cpus();
Resume_devices:
- platform_finish();
device_resume();
+ platform_finish();
resume_console();
Thaw:
unprepare_processes();
-
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/
Re: Linux 2.6.21-rc6
On Sat, Apr 14, 2007 at 10:23:31PM +0200, Rafael J. Wysocki wrote: ... Also, would that be feasible for you to use 'shutdown' as a workaround in case the source of the problem is difficult to find and/or fix? One person reporting a regression against a -rc kernel can mean houndreds or thousands of people who will run into the same issue after 2.6.21 got released if a manual workaround is required... Rafael cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: Linux 2.6.21-rc6
On Saturday, 14 April 2007 22:25, Adrian Bunk wrote: On Sat, Apr 14, 2007 at 10:23:31PM +0200, Rafael J. Wysocki wrote: ... Also, would that be feasible for you to use 'shutdown' as a workaround in case the source of the problem is difficult to find and/or fix? One person reporting a regression against a -rc kernel can mean houndreds or thousands of people who will run into the same issue after 2.6.21 got released if a manual workaround is required... Well, in this particular case it is not very likely to happen. I have three x86_64 machines here with totally different chipsets/devices on which I'm not seeing anything like that and I believe we'd have more reports before if that were a common issue. That said, I'm not going to ignore it. I'll do my best to debug and fix it, if Tobias helps me. :-) Greetings, Rafael - 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/
Re: Linux 2.6.21-rc6
Rafael J. Wysocki wrote:
On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
Rafael J. Wysocki wrote:
On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
Tobias Diedrich wrote:
ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
commit ed746e3b18f4df18afa3763155972c5835f284c5
Author: Rafael J. Wysocki [EMAIL PROTECTED]
Date: Sat Feb 10 01:43:32 2007 -0800
[PATCH] swsusp: Change code ordering in disk.c
Change the ordering of code in kernel/power/disk.c so that
device_suspend() is
called before disable_nonboot_cpus() and platform_finish() is
called after
enable_nonboot_cpus() and before device_resume(), as
indicated by the recent
discussion on Linux-PM (cf.
http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html).
The changes here only affect the built-in swsusp.
[EMAIL PROTECTED]: fix LED blinking during image load]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
Cc: Greg KH [EMAIL PROTECTED]
Cc: Nigel Cunningham [EMAIL PROTECTED]
Cc: Patrick Mochel [EMAIL PROTECTED]
Cc: Alexey Starikovskiy [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
:04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18
8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel
Now, the remaining test is to try reverting this commit from
-rc6. :)
Doesn't apply cleanly against -rc6, but fixes the problem when
reverted from -rc1.
Now, this was already reported in
http://lkml.org/lkml/2007/3/16/126
and I even flagged that message in my local folder, but apparently
forgot
to follow up on it... *sigh*
Unless I misunderstood something, all of the problems Maxim described
in
this email are fixed for him in -rc6.
But it's quite possible that you are running into a different issue
exposed by this commit.
Yes, it's likely.
Tobias, I'm unable to reproduce the problem with your .config, but my
hardware
is certainly different. Which suspend mode do you use? If that's
platform,
can you try to use shutdown or reboot and see if that helps?
Sure.
shutdown/reboot works fine, only platform is broken.
Thanks.
Now, I suspect the problem is somehow related to the hardware, so it would
help
a lot if we could identify the piece of hardware (or driver) involved.
AFAICT, your system is a non-SMP one, so we can rule out
disable/enable_nonboot_cpus(). To confirm that the problem is related to
platform_finish(), can you please apply the appended debug patch and
see if the suspend in the 'platform' mode works with it?
Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
single core CPU.
Also, would that be feasible for you to use 'shutdown' as a workaround in case
the source of the problem is difficult to find and/or fix?
I guess so, but the below patch fixes the problem. :)
---
kernel/power/disk.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.21-rc6/kernel/power/disk.c
===
--- linux-2.6.21-rc6.orig/kernel/power/disk.c
+++ linux-2.6.21-rc6/kernel/power/disk.c
@@ -170,8 +170,8 @@ int pm_suspend_disk(void)
if (in_suspend) {
enable_nonboot_cpus();
- platform_finish();
device_resume();
+ platform_finish();
resume_console();
pr_debug(PM: writing image.\n);
error = swsusp_write();
@@ -189,8 +189,8 @@ int pm_suspend_disk(void)
Enable_cpus:
enable_nonboot_cpus();
Resume_devices:
- platform_finish();
device_resume();
+ platform_finish();
resume_console();
Thaw:
unprepare_processes();
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
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/
Re: Linux 2.6.21-rc6
On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote:
Rafael J. Wysocki wrote:
On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
Rafael J. Wysocki wrote:
On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
Tobias Diedrich wrote:
ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
commit ed746e3b18f4df18afa3763155972c5835f284c5
Author: Rafael J. Wysocki [EMAIL PROTECTED]
Date: Sat Feb 10 01:43:32 2007 -0800
[PATCH] swsusp: Change code ordering in disk.c
Change the ordering of code in kernel/power/disk.c so that
device_suspend() is
called before disable_nonboot_cpus() and platform_finish()
is called after
enable_nonboot_cpus() and before device_resume(), as
indicated by the recent
discussion on Linux-PM (cf.
http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html).
The changes here only affect the built-in swsusp.
[EMAIL PROTECTED]: fix LED blinking during image load]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
Cc: Greg KH [EMAIL PROTECTED]
Cc: Nigel Cunningham [EMAIL PROTECTED]
Cc: Patrick Mochel [EMAIL PROTECTED]
Cc: Alexey Starikovskiy [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
:04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18
8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel
Now, the remaining test is to try reverting this commit from
-rc6. :)
Doesn't apply cleanly against -rc6, but fixes the problem when
reverted from -rc1.
Now, this was already reported in
http://lkml.org/lkml/2007/3/16/126
and I even flagged that message in my local folder, but apparently
forgot
to follow up on it... *sigh*
Unless I misunderstood something, all of the problems Maxim described
in
this email are fixed for him in -rc6.
But it's quite possible that you are running into a different issue
exposed by this commit.
Yes, it's likely.
Tobias, I'm unable to reproduce the problem with your .config, but my
hardware
is certainly different. Which suspend mode do you use? If that's
platform,
can you try to use shutdown or reboot and see if that helps?
Sure.
shutdown/reboot works fine, only platform is broken.
Thanks.
Now, I suspect the problem is somehow related to the hardware, so it would
help
a lot if we could identify the piece of hardware (or driver) involved.
AFAICT, your system is a non-SMP one, so we can rule out
disable/enable_nonboot_cpus(). To confirm that the problem is related to
platform_finish(), can you please apply the appended debug patch and
see if the suspend in the 'platform' mode works with it?
Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
single core CPU.
Also, would that be feasible for you to use 'shutdown' as a workaround in
case
the source of the problem is difficult to find and/or fix?
I guess so, but the below patch fixes the problem. :)
Well, I thought it would, but it also would break some other people's systems.
That's the _real_ problem. Let's see if we can learn more.
Can you please revert it for now, apply the appended one and try to
suspend/resume twice in the 'platform' mode (it may or may not work)?
Rafael
---
kernel/power/disk.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6.21-rc6/kernel/power/disk.c
===
--- linux-2.6.21-rc6.orig/kernel/power/disk.c
+++ linux-2.6.21-rc6/kernel/power/disk.c
@@ -267,12 +267,15 @@ static int software_resume(void)
error = swsusp_read();
if (error) {
swsusp_free();
- platform_finish();
goto Thaw;
}
pr_debug(PM: Preparing devices for restore.\n);
+ error = platform_prepare();
+ if (error)
+ goto Thaw;
+
suspend_console();
error = device_suspend(PMSG_PRETHAW);
if (error)
@@ -285,6 +288,7 @@ static int software_resume(void)
enable_nonboot_cpus();
Free:
swsusp_free();
+ platform_finish();
device_resume();
resume_console();
Thaw:
-
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/
Re: Linux 2.6.21-rc6
On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: > Linus Torvalds wrote: > > > We should be getting close to a 2.6.21 release, so please update any > > regression reports you've done, > > For me, suspend to disk works only once (has been the case for all > .21-rcs IIRC, but I didn't get around to report it so far). > There are some threads about an issue like this, which is supposed > to be fixed by disabling CONFIG_PCI_MSI, but on my system the > problem persists nonetheless. > > On the second suspend attempt, the last message I see is > "Suspending console(s)" > > If I find the time, I'll try to bisect it this weekend. >... Does CONFIG_HPET_TIMER=n make any difference? Does the latest -git work? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: Linux 2.6.21-rc6
Linus Torvalds wrote: > We should be getting close to a 2.6.21 release, so please update any > regression reports you've done, For me, suspend to disk works only once (has been the case for all .21-rcs IIRC, but I didn't get around to report it so far). There are some threads about an issue like this, which is supposed to be fixed by disabling CONFIG_PCI_MSI, but on my system the problem persists nonetheless. On the second suspend attempt, the last message I see is "Suspending console(s)" If I find the time, I'll try to bisect it this weekend. .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc6 # Fri Apr 13 23:08:52 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_X86_MCE_AMD=y CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x20 # CONFIG_SECCOMP is not set # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300 CONFIG_REORDER=y CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y # # Power management options # CONFIG_PM=y # CONFIG_PM_LEGACY is not set # CONFIG_PM_DEBUG is not set # CONFIG_PM_SYSFS_DEPRECATED is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION="" # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_SLEEP_PROC_SLEEP is not set CONFIG_ACPI_PROCFS=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_VIDEO is not set CONFIG_ACPI_FAN=y # CONFIG_ACPI_DOCK is
Re: Linux 2.6.21-rc6
On Thu, Apr 12, 2007 at 09:26:44PM +0300, Maxim Levitsky wrote: > On Thursday 12 April 2007 18:14:02 Mattia Dongili wrote: > > On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote: > > ... > > > Maxim Levitsky (1): > > > Add suspend/resume for HPET > > > > This one breaks resume for me (from STR) on a vaio SZ. Reverting this > > commit allows resuming again but leaves me with some periodic and > > unpleasant: > > > > [ 155.232000] BUG: soft lockup detected on CPU#1! > > [ 155.232000] [] show_trace_log_lvl+0x1a/0x2f > > [ 155.232000] [] show_trace+0x12/0x14 > > [ 155.232000] [] dump_stack+0x16/0x18 > > [ 155.232000] [] softlockup_tick+0xa7/0xb6 > > [ 155.232000] [] run_local_timers+0x12/0x14 > > [ 155.232000] [] update_process_times+0x3e/0x63 > > [ 155.232000] [] tick_sched_timer+0x50/0x95 > > [ 155.232000] [] hrtimer_interrupt+0x10b/0x18b > > [ 155.232000] [] smp_apic_timer_interrupt+0x6c/0x7e > > [ 155.232000] [] apic_timer_interrupt+0x28/0x30 > > [ 155.232000] [] cpu_idle+0x1b/0xc7 > > [ 155.232000] [] start_secondary+0x32b/0x333 > > [ 155.232000] [<>] run_init_process+0x3fefed10/0x19 > > [ 155.232000] === > > > > FWIW: I hit the same BUG() in -rc5. > > full boot+suspend+resume log: > > http://oioio.altervista.org/linux/kern-2.6.21-rc6.log > > .config: http://oioio.altervista.org/linux/config-2.6.21-rc6-1 > > > > I'm available to test more patches or to provide other info. > > Strange,strange... Yes... strange. I can't reproduce the resume breakage anymore, with or without your patch. I still have the soft lockup anyway after resuming. I'll still keep trying, for now just disregard my previous mail. -- mattia :wq! - 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/
Re: Linux 2.6.21-rc6
On Thu, Apr 12, 2007 at 09:26:44PM +0300, Maxim Levitsky wrote: On Thursday 12 April 2007 18:14:02 Mattia Dongili wrote: On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote: ... Maxim Levitsky (1): Add suspend/resume for HPET This one breaks resume for me (from STR) on a vaio SZ. Reverting this commit allows resuming again but leaves me with some periodic and unpleasant: [ 155.232000] BUG: soft lockup detected on CPU#1! [ 155.232000] [c0104cf2] show_trace_log_lvl+0x1a/0x2f [ 155.232000] [c0105344] show_trace+0x12/0x14 [ 155.232000] [c01053c8] dump_stack+0x16/0x18 [ 155.232000] [c0147240] softlockup_tick+0xa7/0xb6 [ 155.232000] [c01284d3] run_local_timers+0x12/0x14 [ 155.232000] [c012887a] update_process_times+0x3e/0x63 [ 155.232000] [c0137656] tick_sched_timer+0x50/0x95 [ 155.232000] [c01340e0] hrtimer_interrupt+0x10b/0x18b [ 155.232000] [c01137b7] smp_apic_timer_interrupt+0x6c/0x7e [ 155.232000] [c0104840] apic_timer_interrupt+0x28/0x30 [ 155.232000] [c0102318] cpu_idle+0x1b/0xc7 [ 155.232000] [c011297a] start_secondary+0x32b/0x333 [ 155.232000] [] run_init_process+0x3fefed10/0x19 [ 155.232000] === FWIW: I hit the same BUG() in -rc5. full boot+suspend+resume log: http://oioio.altervista.org/linux/kern-2.6.21-rc6.log .config: http://oioio.altervista.org/linux/config-2.6.21-rc6-1 I'm available to test more patches or to provide other info. Strange,strange... Yes... strange. I can't reproduce the resume breakage anymore, with or without your patch. I still have the soft lockup anyway after resuming. I'll still keep trying, for now just disregard my previous mail. -- mattia :wq! - 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/
Re: Linux 2.6.21-rc6
Linus Torvalds wrote: We should be getting close to a 2.6.21 release, so please update any regression reports you've done, For me, suspend to disk works only once (has been the case for all .21-rcs IIRC, but I didn't get around to report it so far). There are some threads about an issue like this, which is supposed to be fixed by disabling CONFIG_PCI_MSI, but on my system the problem persists nonetheless. On the second suspend attempt, the last message I see is Suspending console(s) If I find the time, I'll try to bisect it this weekend. .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc6 # Fri Apr 13 23:08:52 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_X86_MCE_AMD=y CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x20 # CONFIG_SECCOMP is not set # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300 CONFIG_REORDER=y CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y # # Power management options # CONFIG_PM=y # CONFIG_PM_LEGACY is not set # CONFIG_PM_DEBUG is not set # CONFIG_PM_SYSFS_DEPRECATED is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION= # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_SLEEP_PROC_SLEEP is not set CONFIG_ACPI_PROCFS=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_VIDEO is not set CONFIG_ACPI_FAN=y # CONFIG_ACPI_DOCK is not set
Re: Linux 2.6.21-rc6
On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: Linus Torvalds wrote: We should be getting close to a 2.6.21 release, so please update any regression reports you've done, For me, suspend to disk works only once (has been the case for all .21-rcs IIRC, but I didn't get around to report it so far). There are some threads about an issue like this, which is supposed to be fixed by disabling CONFIG_PCI_MSI, but on my system the problem persists nonetheless. On the second suspend attempt, the last message I see is Suspending console(s) If I find the time, I'll try to bisect it this weekend. ... Does CONFIG_HPET_TIMER=n make any difference? Does the latest -git work? cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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/
Re: Linux 2.6.21-rc6
On Thursday 12 April 2007 18:14:02 Mattia Dongili wrote: > On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote: > ... > > Maxim Levitsky (1): > > Add suspend/resume for HPET > > This one breaks resume for me (from STR) on a vaio SZ. Reverting this > commit allows resuming again but leaves me with some periodic and unpleasant: > > [ 155.232000] BUG: soft lockup detected on CPU#1! > [ 155.232000] [] show_trace_log_lvl+0x1a/0x2f > [ 155.232000] [] show_trace+0x12/0x14 > [ 155.232000] [] dump_stack+0x16/0x18 > [ 155.232000] [] softlockup_tick+0xa7/0xb6 > [ 155.232000] [] run_local_timers+0x12/0x14 > [ 155.232000] [] update_process_times+0x3e/0x63 > [ 155.232000] [] tick_sched_timer+0x50/0x95 > [ 155.232000] [] hrtimer_interrupt+0x10b/0x18b > [ 155.232000] [] smp_apic_timer_interrupt+0x6c/0x7e > [ 155.232000] [] apic_timer_interrupt+0x28/0x30 > [ 155.232000] [] cpu_idle+0x1b/0xc7 > [ 155.232000] [] start_secondary+0x32b/0x333 > [ 155.232000] [<>] run_init_process+0x3fefed10/0x19 > [ 155.232000] === > > FWIW: I hit the same BUG() in -rc5. > full boot+suspend+resume log: > http://oioio.altervista.org/linux/kern-2.6.21-rc6.log > .config: http://oioio.altervista.org/linux/config-2.6.21-rc6-1 > > I'm available to test more patches or to provide other info. Strange,strange... First of all try to boot with clocksource=acpi_pm (I want to test whenever HPET working as clocksource is a problem) Then try to boot with hpet=disable or unset CONFIG_HPET_TIMER (This will disable hpet both as clock source and clockevent) Please send also contents of /proc/timer_list (I want to know whenever APIC timer is enabled there or not) Best regards, Maxim Levitsky - 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/
Re: Linux 2.6.21-rc6
On Thu, Apr 12, 2007 at 05:14:02PM +0200, Mattia Dongili wrote: > On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote: > ... > > Maxim Levitsky (1): > > Add suspend/resume for HPET > > This one breaks resume for me (from STR) on a vaio SZ. Reverting this > commit allows resuming again but leaves me with some periodic and unpleasant: > > [ 155.232000] BUG: soft lockup detected on CPU#1! A couple more info (probably useless but...): - I noticed the resume problem in -rc6-mm1 but reverting the same patch there doesn't make the laptop resume again - last known succesful resuming kernel: 2.6.21-rc5-mm3 (and without hitting the BUG() above after resume) -- mattia :wq! - 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/
Re: Linux 2.6.21-rc6
On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote: ... > Maxim Levitsky (1): > Add suspend/resume for HPET This one breaks resume for me (from STR) on a vaio SZ. Reverting this commit allows resuming again but leaves me with some periodic and unpleasant: [ 155.232000] BUG: soft lockup detected on CPU#1! [ 155.232000] [] show_trace_log_lvl+0x1a/0x2f [ 155.232000] [] show_trace+0x12/0x14 [ 155.232000] [] dump_stack+0x16/0x18 [ 155.232000] [] softlockup_tick+0xa7/0xb6 [ 155.232000] [] run_local_timers+0x12/0x14 [ 155.232000] [] update_process_times+0x3e/0x63 [ 155.232000] [] tick_sched_timer+0x50/0x95 [ 155.232000] [] hrtimer_interrupt+0x10b/0x18b [ 155.232000] [] smp_apic_timer_interrupt+0x6c/0x7e [ 155.232000] [] apic_timer_interrupt+0x28/0x30 [ 155.232000] [] cpu_idle+0x1b/0xc7 [ 155.232000] [] start_secondary+0x32b/0x333 [ 155.232000] [<>] run_init_process+0x3fefed10/0x19 [ 155.232000] === FWIW: I hit the same BUG() in -rc5. full boot+suspend+resume log: http://oioio.altervista.org/linux/kern-2.6.21-rc6.log .config: http://oioio.altervista.org/linux/config-2.6.21-rc6-1 I'm available to test more patches or to provide other info. -- mattia :wq! - 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/
Re: Linux 2.6.21-rc6
On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote: ... Maxim Levitsky (1): Add suspend/resume for HPET This one breaks resume for me (from STR) on a vaio SZ. Reverting this commit allows resuming again but leaves me with some periodic and unpleasant: [ 155.232000] BUG: soft lockup detected on CPU#1! [ 155.232000] [c0104cf2] show_trace_log_lvl+0x1a/0x2f [ 155.232000] [c0105344] show_trace+0x12/0x14 [ 155.232000] [c01053c8] dump_stack+0x16/0x18 [ 155.232000] [c0147240] softlockup_tick+0xa7/0xb6 [ 155.232000] [c01284d3] run_local_timers+0x12/0x14 [ 155.232000] [c012887a] update_process_times+0x3e/0x63 [ 155.232000] [c0137656] tick_sched_timer+0x50/0x95 [ 155.232000] [c01340e0] hrtimer_interrupt+0x10b/0x18b [ 155.232000] [c01137b7] smp_apic_timer_interrupt+0x6c/0x7e [ 155.232000] [c0104840] apic_timer_interrupt+0x28/0x30 [ 155.232000] [c0102318] cpu_idle+0x1b/0xc7 [ 155.232000] [c011297a] start_secondary+0x32b/0x333 [ 155.232000] [] run_init_process+0x3fefed10/0x19 [ 155.232000] === FWIW: I hit the same BUG() in -rc5. full boot+suspend+resume log: http://oioio.altervista.org/linux/kern-2.6.21-rc6.log .config: http://oioio.altervista.org/linux/config-2.6.21-rc6-1 I'm available to test more patches or to provide other info. -- mattia :wq! - 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/
Re: Linux 2.6.21-rc6
On Thu, Apr 12, 2007 at 05:14:02PM +0200, Mattia Dongili wrote: On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote: ... Maxim Levitsky (1): Add suspend/resume for HPET This one breaks resume for me (from STR) on a vaio SZ. Reverting this commit allows resuming again but leaves me with some periodic and unpleasant: [ 155.232000] BUG: soft lockup detected on CPU#1! A couple more info (probably useless but...): - I noticed the resume problem in -rc6-mm1 but reverting the same patch there doesn't make the laptop resume again - last known succesful resuming kernel: 2.6.21-rc5-mm3 (and without hitting the BUG() above after resume) -- mattia :wq! - 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/
Re: Linux 2.6.21-rc6
On Thursday 12 April 2007 18:14:02 Mattia Dongili wrote: On Thu, Apr 05, 2007 at 07:50:11PM -0700, Linus Torvalds wrote: ... Maxim Levitsky (1): Add suspend/resume for HPET This one breaks resume for me (from STR) on a vaio SZ. Reverting this commit allows resuming again but leaves me with some periodic and unpleasant: [ 155.232000] BUG: soft lockup detected on CPU#1! [ 155.232000] [c0104cf2] show_trace_log_lvl+0x1a/0x2f [ 155.232000] [c0105344] show_trace+0x12/0x14 [ 155.232000] [c01053c8] dump_stack+0x16/0x18 [ 155.232000] [c0147240] softlockup_tick+0xa7/0xb6 [ 155.232000] [c01284d3] run_local_timers+0x12/0x14 [ 155.232000] [c012887a] update_process_times+0x3e/0x63 [ 155.232000] [c0137656] tick_sched_timer+0x50/0x95 [ 155.232000] [c01340e0] hrtimer_interrupt+0x10b/0x18b [ 155.232000] [c01137b7] smp_apic_timer_interrupt+0x6c/0x7e [ 155.232000] [c0104840] apic_timer_interrupt+0x28/0x30 [ 155.232000] [c0102318] cpu_idle+0x1b/0xc7 [ 155.232000] [c011297a] start_secondary+0x32b/0x333 [ 155.232000] [] run_init_process+0x3fefed10/0x19 [ 155.232000] === FWIW: I hit the same BUG() in -rc5. full boot+suspend+resume log: http://oioio.altervista.org/linux/kern-2.6.21-rc6.log .config: http://oioio.altervista.org/linux/config-2.6.21-rc6-1 I'm available to test more patches or to provide other info. Strange,strange... First of all try to boot with clocksource=acpi_pm (I want to test whenever HPET working as clocksource is a problem) Then try to boot with hpet=disable or unset CONFIG_HPET_TIMER (This will disable hpet both as clock source and clockevent) Please send also contents of /proc/timer_list (I want to know whenever APIC timer is enabled there or not) Best regards, Maxim Levitsky - 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/
Re: Linux 2.6.21-rc6
On 4/10/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: On Tue, 10 Apr 2007, Jeff Chua wrote: > I couldn't get suspend-to-disk to work with 2.6.21-rc6. I've tried > set/unset CONFIG_NO_HZ/CONFIG_HPET_TIMER, but nothing worked. Do you think you could busect it? You'd have to apply maxim's patch by hand at each bisection step (up until the point where it's already applied in the git tree, of course), so it's not a totally mindless bisection, but it should still be fairly painless, since there is only 277 commits between -rc5 and -rc6 (so bisection should rather quickly narrow it down) Linus, I did that last night and realize that I could suspend to disk/ram with 2.6.21-rc6 CONFIG_NO_HZ unset. I must have done something wrong before. Thank you, Jeff. - 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/
Re: Linux 2.6.21-rc6
* Chris Wedgwood <[EMAIL PROTECTED]> wrote: > > >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch > > > > It sounded this was specific to Ingo. > > I'm not sure, it sounds a bit like something I saw a while ago. I > would have to check for sure, I made a quick debugging patch (sent to > netdev) and it went away so I think my last though was a > miscompilation. the bug has turned into an 'interface hang under high load' (i.e. the hack patch above is not necessary, but the problem is still there). It still affects the latest forcedeth.c in -rc6. I.e. it's still an unresolved regression. The last state i'm aware of is that I have sent Ayaz ethtool output as well of the hang, as requested. Ingo - 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/
Re: Linux 2.6.21-rc6
* Chris Wedgwood [EMAIL PROTECTED] wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch It sounded this was specific to Ingo. I'm not sure, it sounds a bit like something I saw a while ago. I would have to check for sure, I made a quick debugging patch (sent to netdev) and it went away so I think my last though was a miscompilation. the bug has turned into an 'interface hang under high load' (i.e. the hack patch above is not necessary, but the problem is still there). It still affects the latest forcedeth.c in -rc6. I.e. it's still an unresolved regression. The last state i'm aware of is that I have sent Ayaz ethtool output as well of the hang, as requested. Ingo - 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/
Re: Linux 2.6.21-rc6
On 4/10/07, Linus Torvalds [EMAIL PROTECTED] wrote: On Tue, 10 Apr 2007, Jeff Chua wrote: I couldn't get suspend-to-disk to work with 2.6.21-rc6. I've tried set/unset CONFIG_NO_HZ/CONFIG_HPET_TIMER, but nothing worked. Do you think you could busect it? You'd have to apply maxim's patch by hand at each bisection step (up until the point where it's already applied in the git tree, of course), so it's not a totally mindless bisection, but it should still be fairly painless, since there is only 277 commits between -rc5 and -rc6 (so bisection should rather quickly narrow it down) Linus, I did that last night and realize that I could suspend to disk/ram with 2.6.21-rc6 CONFIG_NO_HZ unset. I must have done something wrong before. Thank you, Jeff. - 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/
Re: Linux 2.6.21-rc6
On Tue, 10 Apr 2007, Jeff Chua wrote: > On 4/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > > We should be getting close to a 2.6.21 release, so please update any > > regression reports you've done, > > I couldn't get suspend-to-disk to work with 2.6.21-rc6. I've tried > set/unset CONFIG_NO_HZ/CONFIG_HPET_TIMER, but nothing worked. > > With rc5 and Maxim's patch, it worked with CONFIG_NO_HZ unset. > > This is on ThinkPad X60s. Do you think you could busect it? You'd have to apply maxim's patch by hand at each bisection step (up until the point where it's already applied in the git tree, of course), so it's not a totally mindless bisection, but it should still be fairly painless, since there is only 277 commits between -rc5 and -rc6 (so bisection should rather quickly narrow it down) Linus - 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/
Re: Linux 2.6.21-rc6
On 4/6/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: We should be getting close to a 2.6.21 release, so please update any regression reports you've done, I couldn't get suspend-to-disk to work with 2.6.21-rc6. I've tried set/unset CONFIG_NO_HZ/CONFIG_HPET_TIMER, but nothing worked. With rc5 and Maxim's patch, it worked with CONFIG_NO_HZ unset. This is on ThinkPad X60s. Jeff. - 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/
Re: Linux 2.6.21-rc6
On Sun, Apr 08, 2007 at 08:59:03PM -0400, Jeff Garzik wrote: > >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch > > It sounded this was specific to Ingo. I'm not sure, it sounds a bit like something I saw a while ago. I would have to check for sure, I made a quick debugging patch (sent to netdev) and it went away so I think my last though was a miscompilation. - 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/
Re: Linux 2.6.21-rc6
On Sun, Apr 08, 2007 at 08:59:03PM -0400, Jeff Garzik wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch It sounded this was specific to Ingo. I'm not sure, it sounds a bit like something I saw a while ago. I would have to check for sure, I made a quick debugging patch (sent to netdev) and it went away so I think my last though was a miscompilation. - 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/
Re: Linux 2.6.21-rc6
On 4/6/07, Linus Torvalds [EMAIL PROTECTED] wrote: We should be getting close to a 2.6.21 release, so please update any regression reports you've done, I couldn't get suspend-to-disk to work with 2.6.21-rc6. I've tried set/unset CONFIG_NO_HZ/CONFIG_HPET_TIMER, but nothing worked. With rc5 and Maxim's patch, it worked with CONFIG_NO_HZ unset. This is on ThinkPad X60s. Jeff. - 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/
Re: Linux 2.6.21-rc6
On Tue, 10 Apr 2007, Jeff Chua wrote: On 4/6/07, Linus Torvalds [EMAIL PROTECTED] wrote: We should be getting close to a 2.6.21 release, so please update any regression reports you've done, I couldn't get suspend-to-disk to work with 2.6.21-rc6. I've tried set/unset CONFIG_NO_HZ/CONFIG_HPET_TIMER, but nothing worked. With rc5 and Maxim's patch, it worked with CONFIG_NO_HZ unset. This is on ThinkPad X60s. Do you think you could busect it? You'd have to apply maxim's patch by hand at each bisection step (up until the point where it's already applied in the git tree, of course), so it's not a totally mindless bisection, but it should still be fairly painless, since there is only 277 commits between -rc5 and -rc6 (so bisection should rather quickly narrow it down) Linus - 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/
Re: Linux 2.6.21-rc6
On Sunday 08 April 2007 19:09, Andrew Morton wrote: > driver core: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/update-documentation-driver-model-platformtxt.patch > We should not encourage using platform_device_register_simple as we want to obsolete this function. -- Dmitry - 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/
Re: Linux 2.6.21-rc6
On Sunday 08 April 2007 19:09, Andrew Morton wrote: driver core: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/update-documentation-driver-model-platformtxt.patch We should not encourage using platform_device_register_simple as we want to obsolete this function. -- Dmitry - 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/
Re: Linux 2.6.21-rc6
Andrew Morton wrote: netdev: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch It sounded this was specific to Ingo. I haven't heard anybody else complain, and AFAIK Ayaz and Ingo were still going back and forth. ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/depcac-fix-handling-of-platorm_device_add-failure.patch ACK this one. Need to send this up, but I'm intentionally avoiding work as we are having a big Easter bash here in Raleigh. Silly bunny-related traditions that have nothing to do with Jesus take priority ;-) I have a couple other bug fixes to push, but that will wait until Tuesday. Jeff - 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/
Re: Linux 2.6.21-rc6
On Sun, Apr 08, 2007 at 04:09:54PM -0700, Andrew Morton wrote: > > I'm sitting on five patches which look like 2.6.21 material, but which > would normally go through subsystem maintainers: > > driver core: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/update-documentation-driver-model-platformtxt.patch Feel free to forward it on with: Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> As it was just a documentation update, I figured it was safe to wait for 2.6.22, but I have no objection to it going in now. thanks, greg k-h - 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/
Re: Linux 2.6.21-rc6
On Thu, 5 Apr 2007 19:50:11 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > > Ok, > I don't think there really is anything very interesting here, but we're > hopefully whittling down the list of regressions, and fixing various > random other small issues while at it. > > Some smallish MIPS updates, networking (and network driver) fixes, removal > of a long obsolete framebuffer driver, etc etc. The shortlog really tells > the story. > > We should be getting close to a 2.6.21 release, so please update any > regression reports you've done, > I'm sitting on five patches which look like 2.6.21 material, but which would normally go through subsystem maintainers: pcmcia: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/fix-hotplug-for-legacy-platform-drivers.patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/fix-hotplug-for-legacy-platform-drivers-update.patch driver core: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/update-documentation-driver-model-platformtxt.patch netdev: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/depcac-fix-handling-of-platorm_device_add-failure.patch net: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/pktgen-add-try_to_freeze.patch please send acks, nacks or smacks asap, thanks. - 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/
Re: Linux 2.6.21-rc6 - regressions update
On Fri, 2007-04-06 at 16:04 -0700, Linus Torvalds wrote: [HPET issues resolved] > > 3) Subject: SATA breakage on resume > > References : http://lkml.org/lkml/2007/3/7/233 > > Submitter : Thomas Gleixner <[EMAIL PROTECTED]> > > Soeren Sonnenburg <[EMAIL PROTECTED]> > > Status : unknown > > > > I am still seeing these messages after a suspend/resume cycle (though > > all devices work even after multiple suspend/resume cycles) > > > > ATA: abnormal status 0x80 on port 0x000140df > > This seems to be normal, and related to some unknown timing issue. If the > thing works for you apart from the message, I'd just ignore it.. Argh! Now after intensive use over the last 2 days, I realized that the internal harddisk works OK, but the dvd-drive did not after the 7th suspend/resume cycle - the device was suddenly gone (I could not even eject the disc I just inserted), more verbose dmesg follows: ata1: port is slow to respond, please be patient (Status 0x80) ata1: port failed to respond (30 secs, Status 0x80) ATA: abnormal status 0x80 on port 0x000101f7 ATA: abnormal status 0x80 on port 0x000101f7 ATA: abnormal status 0x80 on port 0x000101f7 ATA: abnormal status 0x80 on port 0x000101f7 ata1.00: qc timeout (cmd 0xa1) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.00: revalidation failed (errno=-5) ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0x80) ata1: port failed to respond (30 secs, Status 0x80) ATA: abnormal status 0x80 on port 0x000101f7 ATA: abnormal status 0x80 on port 0x000101f7 ATA: abnormal status 0x80 on port 0x000101f7 ATA: abnormal status 0x80 on port 0x000101f7 ata1.00: qc timeout (cmd 0xa1) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.00: revalidation failed (errno=-5) ata1.00: limiting speed to UDMA/33:PIO3 ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0x80) ata1: port failed to respond (30 secs, Status 0x80) ATA: abnormal status 0x80 on port 0x000101f7 sage repeated 4 times ata1.00: qc timeout (cmd 0xa1) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.00: revalidation failed (errno=-5) ata1.00: disabled Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 - 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/
Re: Linux 2.6.21-rc6 - regressions update
On Fri, 2007-04-06 at 16:04 -0700, Linus Torvalds wrote: [HPET issues resolved] 3) Subject: SATA breakage on resume References : http://lkml.org/lkml/2007/3/7/233 Submitter : Thomas Gleixner [EMAIL PROTECTED] Soeren Sonnenburg [EMAIL PROTECTED] Status : unknown I am still seeing these messages after a suspend/resume cycle (though all devices work even after multiple suspend/resume cycles) ATA: abnormal status 0x80 on port 0x000140df This seems to be normal, and related to some unknown timing issue. If the thing works for you apart from the message, I'd just ignore it.. Argh! Now after intensive use over the last 2 days, I realized that the internal harddisk works OK, but the dvd-drive did not after the 7th suspend/resume cycle - the device was suddenly gone (I could not even eject the disc I just inserted), more verbose dmesg follows: ata1: port is slow to respond, please be patient (Status 0x80) ata1: port failed to respond (30 secs, Status 0x80) ATA: abnormal status 0x80 on port 0x000101f7 ATA: abnormal status 0x80 on port 0x000101f7 ATA: abnormal status 0x80 on port 0x000101f7 ATA: abnormal status 0x80 on port 0x000101f7 ata1.00: qc timeout (cmd 0xa1) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.00: revalidation failed (errno=-5) ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0x80) ata1: port failed to respond (30 secs, Status 0x80) ATA: abnormal status 0x80 on port 0x000101f7 ATA: abnormal status 0x80 on port 0x000101f7 ATA: abnormal status 0x80 on port 0x000101f7 ATA: abnormal status 0x80 on port 0x000101f7 ata1.00: qc timeout (cmd 0xa1) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.00: revalidation failed (errno=-5) ata1.00: limiting speed to UDMA/33:PIO3 ata1: failed to recover some devices, retrying in 5 secs ata1: port is slow to respond, please be patient (Status 0x80) ata1: port failed to respond (30 secs, Status 0x80) ATA: abnormal status 0x80 on port 0x000101f7 sage repeated 4 times ata1.00: qc timeout (cmd 0xa1) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.00: revalidation failed (errno=-5) ata1.00: disabled Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 - 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/
Re: Linux 2.6.21-rc6
On Thu, 5 Apr 2007 19:50:11 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] wrote: Ok, I don't think there really is anything very interesting here, but we're hopefully whittling down the list of regressions, and fixing various random other small issues while at it. Some smallish MIPS updates, networking (and network driver) fixes, removal of a long obsolete framebuffer driver, etc etc. The shortlog really tells the story. We should be getting close to a 2.6.21 release, so please update any regression reports you've done, I'm sitting on five patches which look like 2.6.21 material, but which would normally go through subsystem maintainers: pcmcia: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/fix-hotplug-for-legacy-platform-drivers.patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/fix-hotplug-for-legacy-platform-drivers-update.patch driver core: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/update-documentation-driver-model-platformtxt.patch netdev: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/depcac-fix-handling-of-platorm_device_add-failure.patch net: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/pktgen-add-try_to_freeze.patch please send acks, nacks or smacks asap, thanks. - 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/
Re: Linux 2.6.21-rc6
On Sun, Apr 08, 2007 at 04:09:54PM -0700, Andrew Morton wrote: I'm sitting on five patches which look like 2.6.21 material, but which would normally go through subsystem maintainers: driver core: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/update-documentation-driver-model-platformtxt.patch Feel free to forward it on with: Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] As it was just a documentation update, I figured it was safe to wait for 2.6.22, but I have no objection to it going in now. thanks, greg k-h - 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/
Re: Linux 2.6.21-rc6
Andrew Morton wrote: netdev: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/forcedeth-work-around-null-skb-dereference-crash.patch It sounded this was specific to Ingo. I haven't heard anybody else complain, and AFAIK Ayaz and Ingo were still going back and forth. ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc6/2.6.21-rc6-mm1/broken-out/depcac-fix-handling-of-platorm_device_add-failure.patch ACK this one. Need to send this up, but I'm intentionally avoiding work as we are having a big Easter bash here in Raleigh. Silly bunny-related traditions that have nothing to do with Jesus take priority ;-) I have a couple other bug fixes to push, but that will wait until Tuesday. Jeff - 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/
Re: Linux 2.6.21-rc6
On Thursday 05 April 2007, Linus Torvalds wrote: >Ok, > I don't think there really is anything very interesting here, but we're >hopefully whittling down the list of regressions, and fixing various >random other small issues while at it. > >Some smallish MIPS updates, networking (and network driver) fixes, > removal of a long obsolete framebuffer driver, etc etc. The shortlog > really tells the story. > >We should be getting close to a 2.6.21 release, so please update any >regression reports you've done, > > Linus [...] > > >Andrew Morton (4): > proc: fix linkage with CONFIG_SYSCTL=y, CONFIG_PROC_SYSCTL=n > revert "retries in ext3_prepare_write() violate ordering > requirements" revert "retries in ext4_prepare_write() violate ordering > requirements" remove protection of LANANA-reserved majors > FWIW, this last reversion didn't do it quite right, the device-mapper was at 253 prior to this patches parent patch, and now its at 252, which is still a 'dump it all' change for both tar & dump. Until things settle, I'm going to test and probably use the instructions that Dave Dillow just sent me, which should put it at 238 regardless. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) "Looks clean and obviously correct to me, but then _everything_ I write always looks obviously correct yo me." - Linus - 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/
Re: Linux 2.6.21-rc6
On Sat, 7 Apr 2007, Linus Torvalds wrote: > > > On Sat, 7 Apr 2007, Randy Dunlap wrote: > > > > Is it too late to get a v2.6.21-rc6 tag ? > > It's definitely there, I can see it in gitweb.. > > Do you have some really ancient git that didn't fetch the tags > automatically? Oh, my bad. I'd tagged it, but I didn't *sign* the tag, so it was just a tag-reference (and git fetch won't fetch them by default). I replaced the v2.6.21-rc6 tag with a signed one. Do git fetch --tags to get the thing. Linus - 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/
Re: Linux 2.6.21-rc6
On Sat, 7 Apr 2007 11:46:13 -0700 (PDT) Linus Torvalds wrote: > > > On Sat, 7 Apr 2007, Randy Dunlap wrote: > > > > Is it too late to get a v2.6.21-rc6 tag ? > > It's definitely there, I can see it in gitweb.. > > Do you have some really ancient git that didn't fetch the tags > automatically? Could be. I'll check that. Thanks. --- ~Randy - 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/
Re: Linux 2.6.21-rc6
On Sat, 7 Apr 2007, Randy Dunlap wrote: > > Is it too late to get a v2.6.21-rc6 tag ? It's definitely there, I can see it in gitweb.. Do you have some really ancient git that didn't fetch the tags automatically? Linus - 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/
Re: Linux 2.6.21-rc6
On Thu, 5 Apr 2007 19:50:11 -0700 (PDT) Linus Torvalds wrote: > > Ok, > I don't think there really is anything very interesting here, but we're > hopefully whittling down the list of regressions, and fixing various > random other small issues while at it. > > Some smallish MIPS updates, networking (and network driver) fixes, removal > of a long obsolete framebuffer driver, etc etc. The shortlog really tells > the story. > > We should be getting close to a 2.6.21 release, so please update any > regression reports you've done, Is it too late to get a v2.6.21-rc6 tag ? --- ~Randy - 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/
Re: Linux 2.6.21-rc6
Hi all, This looks like a lockdep problem. 2.6.21-rc6 + hrtimers_debug.patch (from Ingo) - skge_wol_support (commit a504e64ab42bcc27074ea37405d06833ed6e0820) dropped due to swsusp problems [14016.726946] BUG: at /mnt/md0/devel/linux-git/kernel/lockdep.c:2427 check_flags() [14016.734331] [] show_trace_log_lvl+0x1a/0x2f [14016.739507] [] show_trace+0x12/0x14 [14016.743982] [] dump_stack+0x16/0x18 [14016.748460] [] check_flags+0x95/0x143 [14016.753106] [] lock_acquire+0x29/0x82 [14016.757741] [] down_write+0x3a/0x54 [14016.762203] [] sys_munmap+0x23/0x3f [14016.71] [] syscall_call+0x7/0xb [14016.771134] === [14016.774712] irq event stamp: 43076 [14016.778111] hardirqs last enabled at (43075): [] syscall_exit_work+0x11/0x26 [14016.786166] hardirqs last disabled at (43076): [] ret_from_exception+0x9/0xc [14016.794118] softirqs last enabled at (42608): [] __do_softirq+0xe4/0xea [14016.801706] softirqs last disabled at (42599): [] do_softirq+0x64/0xd1 http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc6/git-console.log http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc6/git-config BTW. I noticed some strange fio (1.15) behavior Starting 16 processes file:io_u.c:65, assert idx < f->num_maps failed[ 1605/ 36442 kb/s] [eta 00m:32s] fio: pid=13734, got signal=11 file:io_u.c:65, assert idx < f->num_maps failed[ 10452/ 0 kb/s] [eta 00m:23s] fio: pid=13731, got signal=11 Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - 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/
Re: Linux 2.6.21-rc6
Hi all, This looks like a lockdep problem. 2.6.21-rc6 + hrtimers_debug.patch (from Ingo) - skge_wol_support (commit a504e64ab42bcc27074ea37405d06833ed6e0820) dropped due to swsusp problems [14016.726946] BUG: at /mnt/md0/devel/linux-git/kernel/lockdep.c:2427 check_flags() [14016.734331] [c0105039] show_trace_log_lvl+0x1a/0x2f [14016.739507] [c0105720] show_trace+0x12/0x14 [14016.743982] [c01057d2] dump_stack+0x16/0x18 [14016.748460] [c013b57f] check_flags+0x95/0x143 [14016.753106] [c013e334] lock_acquire+0x29/0x82 [14016.757741] [c01369dc] down_write+0x3a/0x54 [14016.762203] [c0163be2] sys_munmap+0x23/0x3f [14016.71] [c0104060] syscall_call+0x7/0xb [14016.771134] === [14016.774712] irq event stamp: 43076 [14016.778111] hardirqs last enabled at (43075): [c0104189] syscall_exit_work+0x11/0x26 [14016.786166] hardirqs last disabled at (43076): [c0103f09] ret_from_exception+0x9/0xc [14016.794118] softirqs last enabled at (42608): [c012653b] __do_softirq+0xe4/0xea [14016.801706] softirqs last disabled at (42599): [c01069b5] do_softirq+0x64/0xd1 http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc6/git-console.log http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc6/git-config BTW. I noticed some strange fio (1.15) behavior Starting 16 processes file:io_u.c:65, assert idx f-num_maps failed[ 1605/ 36442 kb/s] [eta 00m:32s] fio: pid=13734, got signal=11 file:io_u.c:65, assert idx f-num_maps failed[ 10452/ 0 kb/s] [eta 00m:23s] fio: pid=13731, got signal=11 Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/) - 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/
Re: Linux 2.6.21-rc6
On Thu, 5 Apr 2007 19:50:11 -0700 (PDT) Linus Torvalds wrote: Ok, I don't think there really is anything very interesting here, but we're hopefully whittling down the list of regressions, and fixing various random other small issues while at it. Some smallish MIPS updates, networking (and network driver) fixes, removal of a long obsolete framebuffer driver, etc etc. The shortlog really tells the story. We should be getting close to a 2.6.21 release, so please update any regression reports you've done, Is it too late to get a v2.6.21-rc6 tag ? --- ~Randy - 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/
Re: Linux 2.6.21-rc6
On Sat, 7 Apr 2007, Randy Dunlap wrote: Is it too late to get a v2.6.21-rc6 tag ? It's definitely there, I can see it in gitweb.. Do you have some really ancient git that didn't fetch the tags automatically? Linus - 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/
Re: Linux 2.6.21-rc6
On Sat, 7 Apr 2007 11:46:13 -0700 (PDT) Linus Torvalds wrote: On Sat, 7 Apr 2007, Randy Dunlap wrote: Is it too late to get a v2.6.21-rc6 tag ? It's definitely there, I can see it in gitweb.. Do you have some really ancient git that didn't fetch the tags automatically? Could be. I'll check that. Thanks. --- ~Randy - 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/
Re: Linux 2.6.21-rc6
On Sat, 7 Apr 2007, Linus Torvalds wrote: On Sat, 7 Apr 2007, Randy Dunlap wrote: Is it too late to get a v2.6.21-rc6 tag ? It's definitely there, I can see it in gitweb.. Do you have some really ancient git that didn't fetch the tags automatically? Oh, my bad. I'd tagged it, but I didn't *sign* the tag, so it was just a tag-reference (and git fetch won't fetch them by default). I replaced the v2.6.21-rc6 tag with a signed one. Do git fetch --tags to get the thing. Linus - 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/
Re: Linux 2.6.21-rc6
On Thursday 05 April 2007, Linus Torvalds wrote: Ok, I don't think there really is anything very interesting here, but we're hopefully whittling down the list of regressions, and fixing various random other small issues while at it. Some smallish MIPS updates, networking (and network driver) fixes, removal of a long obsolete framebuffer driver, etc etc. The shortlog really tells the story. We should be getting close to a 2.6.21 release, so please update any regression reports you've done, Linus [...] Andrew Morton (4): proc: fix linkage with CONFIG_SYSCTL=y, CONFIG_PROC_SYSCTL=n revert retries in ext3_prepare_write() violate ordering requirements revert retries in ext4_prepare_write() violate ordering requirements remove protection of LANANA-reserved majors FWIW, this last reversion didn't do it quite right, the device-mapper was at 253 prior to this patches parent patch, and now its at 252, which is still a 'dump it all' change for both tar dump. Until things settle, I'm going to test and probably use the instructions that Dave Dillow just sent me, which should put it at 238 regardless. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Looks clean and obviously correct to me, but then _everything_ I write always looks obviously correct yo me. - Linus - 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/
Re: Linux 2.6.21-rc6 - regressions update
[ Added some people to the cc.. Len, Thomas, Ingo - look for the exact report on linux-kernel, but basically it's a "irq 9: nobody cared" issue with acpi_irq on irq9 ] On Sat, 7 Apr 2007, Soeren Sonnenburg wrote: > > regression update for 21-rc6: > > 1) all s2ram and NO_HZ related things seem to be resolved on my macbook > pro, also > CONFIG_HPET_TIMER=y > CONFIG_HPET_EMULATE_RTC=y > > don't break resume anymore. Goodie. I think we fixed most stuff.. > 2) However I am still having problems with > +CONFIG_HIGH_RES_TIMERS=y > +CONFIG_HPET=y > +CONFIG_HPET_MMAP=y > although the machine resumes, I've managed to get the attached oops. Ok, interesting. I'd have blamed ACPI for this one (stuck IRQ9 is almost always some ACPI event that got stuck or the SCI got mis-routed and/or marked with the wrong polarity), although from your message I take it you don't get it without high-res timers? In fact, I have a theory.. Your backtrace is: [] smp_apic_timer_interrupt+0x57/0x90 [] retrigger_next_event+0x0/0xb0 [] apic_timer_interrupt+0x28/0x30 [] retrigger_next_event+0x0/0xb0 [] __kfifo_put+0x8/0x90 [] on_each_cpu+0x35/0x60 [] clock_was_set+0x18/0x20 [] timekeeping_resume+0x7c/0xa0 [] __sysdev_resume+0x11/0x80 [] sysdev_resume+0x47/0x80 [] device_power_up+0x5/0x10 and the thing is, I don't think we should have interrupt enabled at this point in time! I susect that the timer resume enables interrupts too early! We should be doing the whole "device_power_up()" sequence with irq's off, I think.. > 3) Subject: SATA breakage on resume > References : http://lkml.org/lkml/2007/3/7/233 > Submitter : Thomas Gleixner <[EMAIL PROTECTED]> > Soeren Sonnenburg <[EMAIL PROTECTED]> > Status : unknown > > I am still seeing these messages after a suspend/resume cycle (though > all devices work even after multiple suspend/resume cycles) > > ATA: abnormal status 0x80 on port 0x000140df This seems to be normal, and related to some unknown timing issue. If the thing works for you apart from the message, I'd just ignore it.. Linus - 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/
Re: Linux 2.6.21-rc6 - regressions update
On Thu, 2007-04-05 at 19:50 -0700, Linus Torvalds wrote: > Ok, > I don't think there really is anything very interesting here, but we're > hopefully whittling down the list of regressions, and fixing various > random other small issues while at it. > > Some smallish MIPS updates, networking (and network driver) fixes, removal > of a long obsolete framebuffer driver, etc etc. The shortlog really tells > the story. > > We should be getting close to a 2.6.21 release, so please update any > regression reports you've done, regression update for 21-rc6: 1) all s2ram and NO_HZ related things seem to be resolved on my macbook pro, also CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y don't break resume anymore. 2) However I am still having problems with +CONFIG_HIGH_RES_TIMERS=y +CONFIG_HPET=y +CONFIG_HPET_MMAP=y although the machine resumes, I've managed to get the attached oops. 3) Subject: SATA breakage on resume References : http://lkml.org/lkml/2007/3/7/233 Submitter : Thomas Gleixner <[EMAIL PROTECTED]> Soeren Sonnenburg <[EMAIL PROTECTED]> Status : unknown I am still seeing these messages after a suspend/resume cycle (though all devices work even after multiple suspend/resume cycles) ATA: abnormal status 0x80 on port 0x000140df ata3.01: revalidation failed (errno=-2) ata3: failed to recover some devices, retrying in 5 secs ata1.00: configured for UDMA/33 ATA: abnormal status 0x7F on port 0x000140df ATA: abnormal status 0x7F on port 0x000140df ata3.01: configured for UDMA/133 So that's been a big step forward... Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 CPU1 is down Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Back to C! irq 9: nobody cared (try booting with the "irqpoll" option) [] __report_bad_irq+0x24/0x90 [] note_interrupt+0x22f/0x260 [] acpi_irq+0xb/0x14 [] handle_IRQ_event+0x25/0x60 [] handle_level_irq+0xe0/0x110 [] do_IRQ+0x3b/0x80 [] smp_apic_timer_interrupt+0x57/0x90 [] common_interrupt+0x23/0x28 [] __kfifo_put+0x78/0x90 [] __do_softirq+0x6d/0xf0 [] do_softirq+0x37/0x40 [] irq_exit+0x7a/0x90 [] smp_apic_timer_interrupt+0x57/0x90 [] retrigger_next_event+0x0/0xb0 [] apic_timer_interrupt+0x28/0x30 [] retrigger_next_event+0x0/0xb0 [] __kfifo_put+0x8/0x90 [] on_each_cpu+0x35/0x60 [] clock_was_set+0x18/0x20 [] timekeeping_resume+0x7c/0xa0 [] __sysdev_resume+0x11/0x80 [] sysdev_resume+0x47/0x80 [] device_power_up+0x5/0x10 [] suspend_enter+0x56/0x60 [] enter_state+0x11a/0x1c0 [] state_store+0xbd/0xd0 [] state_store+0x0/0xd0 [] subsys_attr_store+0x29/0x40 [] sysfs_write_file+0xb2/0x110 [] vfs_write+0xa6/0x140 [] sysfs_write_file+0x0/0x110 [] sys_write+0x41/0x70 [] sysenter_past_esp+0x5f/0x85 === handlers: [] (acpi_irq+0x0/0x14) Disabling IRQ #9 Enabling non-boot CPUs ... SMP alternatives: switching to SMP code
Re: tg3: unable to handle null pointer dereference [Re: Linux 2.6.21-rc6]
On Fri, 2007-04-06 at 14:40 -0700, Nishanth Aravamudan wrote:
> 2.6.21-rc5 is ok. 2.6.21-rc6 results in
>
> [ 14.241665] Unable to handle kernel NULL pointer dereference (address
> )
Sorry, I think this should fix it:
[TG3]: Fix crash during tg3_init_one().
The driver will crash when the chip has been initialized by EFI before
tg3_init_one(). In this case, the driver will call tg3_chip_reset()
before allocating consistent memory.
The bug is fixed by checking for tp->hw_status before accessing it
during tg3_chip_reset().
Signed-off-by: Michael Chan <[EMAIL PROTECTED]>
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0acee9f..256969e 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -4834,8 +4834,10 @@ static int tg3_chip_reset(struct tg3 *tp)
* sharing or irqpoll.
*/
tp->tg3_flags |= TG3_FLAG_CHIP_RESETTING;
- tp->hw_status->status = 0;
- tp->hw_status->status_tag = 0;
+ if (tp->hw_status) {
+ tp->hw_status->status = 0;
+ tp->hw_status->status_tag = 0;
+ }
tp->last_tag = 0;
smp_mb();
synchronize_irq(tp->pdev->irq);
-
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/
tg3: unable to handle null pointer dereference [Re: Linux 2.6.21-rc6]
On 05.04.2007 [19:50:11 -0700], Linus Torvalds wrote: > > Ok, > I don't think there really is anything very interesting here, but we're > hopefully whittling down the list of regressions, and fixing various > random other small issues while at it. > > Some smallish MIPS updates, networking (and network driver) fixes, removal > of a long obsolete framebuffer driver, etc etc. The shortlog really tells > the story. > > We should be getting close to a 2.6.21 release, so please update any > regression reports you've done, 2.6.21-rc5 is ok. 2.6.21-rc6 results in [ 14.241665] Unable to handle kernel NULL pointer dereference (address ) [ 14.250025] swapper[1]: Oops 11003706212352 [1] [ 14.254753] Modules linked in: [ 14.258046] [ 14.258047] Pid: 1, CPU 7, comm: swapper [ 14.264962] psr : 1210084a6010 ifs : 8610 ip : []Not tainted [ 14.274399] ip is at tg3_chip_reset+0xf1/0x12c0 [ 14.279124] unat: pfs : 0610 rsc : 0003 [ 14.286862] rnat: e01005bc7d40 bsps: e01005bc pr : 68105a9195655599 [ 14.294598] ldrs: ccv : fpsr: 0009804c8a70433f [ 14.302338] csd : ssd : [ 14.307946] b0 : a001004952c0 b6 : a0010038b2e0 b7 : a00100486580 [ 14.315688] f6 : 1003e00054e304351 f7 : 1003e0640 [ 14.322164] f8 : 1003e00054e2dd251 f9 : 1003e0064 [ 14.328643] f10 : 10015e7d113fff182eec0 f11 : 1003e0073e88a [ 14.335116] r1 : a00100d4be30 r2 : a00100b68fc0 r3 : a00100b68eb0 [ 14.342851] r8 : r9 : 0200 r10 : a0010089d1a8 [ 14.350597] r11 : a00100486580 r12 : e01005bc7d70 r13 : e01005bc [ 14.358332] r14 : 0002 r15 : e01005d08f10 r16 : e01005d08ee0 [ 14.366072] r17 : e01005d08748 r18 : e01005d08758 r19 : [ 14.373815] r20 : e01005d08748 r21 : r22 : 40027401 [ 14.381557] r23 : 00027401 r24 : 4000 r25 : a0010089d2f0 [ 14.389293] r26 : a00100b5b5c0 r27 : r28 : [ 14.397035] r29 : r30 : r31 : e01005d08708 [ 14.404847] [ 14.404848] Call Trace: [ 14.409160] [] show_stack+0x80/0xa0 [ 14.409162] sp=e01005bc7900 bsp=e01005bc1120 [ 14.422595] [] show_regs+0x870/0x8a0 [ 14.422597] sp=e01005bc7ad0 bsp=e01005bc10c8 [ 14.436128] [] die+0x1b0/0x320 [ 14.436131] sp=e01005bc7ad0 bsp=e01005bc1080 [ 14.449182] [] ia64_do_page_fault+0xa00/0xba0 [ 14.449185] sp=e01005bc7af0 bsp=e01005bc1028 [ 14.463498] [] ia64_leave_kernel+0x0/0x280 [ 14.463501] sp=e01005bc7ba0 bsp=e01005bc1028 [ 14.477553] [] tg3_chip_reset+0xf0/0x12c0 [ 14.477555] sp=e01005bc7d70 bsp=e01005bc0fa0 [ 14.491516] [] tg3_halt+0x50/0xa0 [ 14.491518] sp=e01005bc7d80 bsp=e01005bc0f68 [ 14.504796] [] tg3_init_one+0x1c80/0x3080 [ 14.504799] sp=e01005bc7d80 bsp=e01005bc0eb8 [ 14.518796] [] pci_device_probe+0x1f0/0x2c0 [ 14.518799] sp=e01005bc7dd0 bsp=e01005bc0e70 [ 14.532961] [] really_probe+0x100/0x3a0 [ 14.532963] sp=e01005bc7dd0 bsp=e01005bc0e20 [ 14.546745] [] driver_probe_device+0x1c0/0x1e0 [ 14.546747] sp=e01005bc7dd0 bsp=e01005bc0de8 [ 14.561148] [] __driver_attach+0xc0/0x160 [ 14.561150] sp=e01005bc7dd0 bsp=e01005bc0db0 [ 14.575108] [] bus_for_each_dev+0xb0/0x120 [ 14.575111] sp=e01005bc7dd0 bsp=e01005bc0d78 [ 14.589157] [] driver_attach+0x40/0x60 [ 14.589160] sp=e01005bc7df0 bsp=e01005bc0d58 [ 14.602862] [] bus_add_driver+0xf0/0x3c0 [ 14.602864] sp=e01005bc7df0 bsp=e01005bc0d18 [ 14.616736] [] driver_register+0xe0/0x1a0 [ 14.616738] sp=e01005bc7df0 bsp=e01005bc0cf8 [ 14.630696] [] __pci_register_driver+0x120/0x1a0 [ 14.630699] sp=e01005bc7df0 bsp=e01005bc0cc0 [ 14.645280] [] tg3_init+0x30/0x60 [ 14.645283] sp=e01005bc7e00 bsp=e01005bc0ca8 [ 14.658540] [] init+0x390/0x740 [ 14.658542] sp=e01005bc7e00 bsp=e01005bc0c58 [ 14.671627] [] kernel_thread_helper+0xd0/0x100 [ 14.671629]
tg3: unable to handle null pointer dereference [Re: Linux 2.6.21-rc6]
On 05.04.2007 [19:50:11 -0700], Linus Torvalds wrote: Ok, I don't think there really is anything very interesting here, but we're hopefully whittling down the list of regressions, and fixing various random other small issues while at it. Some smallish MIPS updates, networking (and network driver) fixes, removal of a long obsolete framebuffer driver, etc etc. The shortlog really tells the story. We should be getting close to a 2.6.21 release, so please update any regression reports you've done, 2.6.21-rc5 is ok. 2.6.21-rc6 results in [ 14.241665] Unable to handle kernel NULL pointer dereference (address ) [ 14.250025] swapper[1]: Oops 11003706212352 [1] [ 14.254753] Modules linked in: [ 14.258046] [ 14.258047] Pid: 1, CPU 7, comm: swapper [ 14.264962] psr : 1210084a6010 ifs : 8610 ip : [a00100495371]Not tainted [ 14.274399] ip is at tg3_chip_reset+0xf1/0x12c0 [ 14.279124] unat: pfs : 0610 rsc : 0003 [ 14.286862] rnat: e01005bc7d40 bsps: e01005bc pr : 68105a9195655599 [ 14.294598] ldrs: ccv : fpsr: 0009804c8a70433f [ 14.302338] csd : ssd : [ 14.307946] b0 : a001004952c0 b6 : a0010038b2e0 b7 : a00100486580 [ 14.315688] f6 : 1003e00054e304351 f7 : 1003e0640 [ 14.322164] f8 : 1003e00054e2dd251 f9 : 1003e0064 [ 14.328643] f10 : 10015e7d113fff182eec0 f11 : 1003e0073e88a [ 14.335116] r1 : a00100d4be30 r2 : a00100b68fc0 r3 : a00100b68eb0 [ 14.342851] r8 : r9 : 0200 r10 : a0010089d1a8 [ 14.350597] r11 : a00100486580 r12 : e01005bc7d70 r13 : e01005bc [ 14.358332] r14 : 0002 r15 : e01005d08f10 r16 : e01005d08ee0 [ 14.366072] r17 : e01005d08748 r18 : e01005d08758 r19 : [ 14.373815] r20 : e01005d08748 r21 : r22 : 40027401 [ 14.381557] r23 : 00027401 r24 : 4000 r25 : a0010089d2f0 [ 14.389293] r26 : a00100b5b5c0 r27 : r28 : [ 14.397035] r29 : r30 : r31 : e01005d08708 [ 14.404847] [ 14.404848] Call Trace: [ 14.409160] [a00100013900] show_stack+0x80/0xa0 [ 14.409162] sp=e01005bc7900 bsp=e01005bc1120 [ 14.422595] [a001000141f0] show_regs+0x870/0x8a0 [ 14.422597] sp=e01005bc7ad0 bsp=e01005bc10c8 [ 14.436128] [a001000390f0] die+0x1b0/0x320 [ 14.436131] sp=e01005bc7ad0 bsp=e01005bc1080 [ 14.449182] [a00100730980] ia64_do_page_fault+0xa00/0xba0 [ 14.449185] sp=e01005bc7af0 bsp=e01005bc1028 [ 14.463498] [a001b760] ia64_leave_kernel+0x0/0x280 [ 14.463501] sp=e01005bc7ba0 bsp=e01005bc1028 [ 14.477553] [a00100495370] tg3_chip_reset+0xf0/0x12c0 [ 14.477555] sp=e01005bc7d70 bsp=e01005bc0fa0 [ 14.491516] [a00100496590] tg3_halt+0x50/0xa0 [ 14.491518] sp=e01005bc7d80 bsp=e01005bc0f68 [ 14.504796] [a001004a86a0] tg3_init_one+0x1c80/0x3080 [ 14.504799] sp=e01005bc7d80 bsp=e01005bc0eb8 [ 14.518796] [a00100399c70] pci_device_probe+0x1f0/0x2c0 [ 14.518799] sp=e01005bc7dd0 bsp=e01005bc0e70 [ 14.532961] [a00100466560] really_probe+0x100/0x3a0 [ 14.532963] sp=e01005bc7dd0 bsp=e01005bc0e20 [ 14.546745] [a001004669c0] driver_probe_device+0x1c0/0x1e0 [ 14.546747] sp=e01005bc7dd0 bsp=e01005bc0de8 [ 14.561148] [a00100466c80] __driver_attach+0xc0/0x160 [ 14.561150] sp=e01005bc7dd0 bsp=e01005bc0db0 [ 14.575108] [a00100464bb0] bus_for_each_dev+0xb0/0x120 [ 14.575111] sp=e01005bc7dd0 bsp=e01005bc0d78 [ 14.589157] [a00100466240] driver_attach+0x40/0x60 [ 14.589160] sp=e01005bc7df0 bsp=e01005bc0d58 [ 14.602862] [a00100465330] bus_add_driver+0xf0/0x3c0 [ 14.602864] sp=e01005bc7df0 bsp=e01005bc0d18 [ 14.616736] [a00100467180] driver_register+0xe0/0x1a0 [ 14.616738] sp=e01005bc7df0 bsp=e01005bc0cf8 [ 14.630696] [a0010039a1a0] __pci_register_driver+0x120/0x1a0 [ 14.630699] sp=e01005bc7df0 bsp=e01005bc0cc0 [ 14.645280] [a001008e8270] tg3_init+0x30/0x60 [
Re: tg3: unable to handle null pointer dereference [Re: Linux 2.6.21-rc6]
On Fri, 2007-04-06 at 14:40 -0700, Nishanth Aravamudan wrote:
2.6.21-rc5 is ok. 2.6.21-rc6 results in
[ 14.241665] Unable to handle kernel NULL pointer dereference (address
)
Sorry, I think this should fix it:
[TG3]: Fix crash during tg3_init_one().
The driver will crash when the chip has been initialized by EFI before
tg3_init_one(). In this case, the driver will call tg3_chip_reset()
before allocating consistent memory.
The bug is fixed by checking for tp-hw_status before accessing it
during tg3_chip_reset().
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 0acee9f..256969e 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -4834,8 +4834,10 @@ static int tg3_chip_reset(struct tg3 *tp)
* sharing or irqpoll.
*/
tp-tg3_flags |= TG3_FLAG_CHIP_RESETTING;
- tp-hw_status-status = 0;
- tp-hw_status-status_tag = 0;
+ if (tp-hw_status) {
+ tp-hw_status-status = 0;
+ tp-hw_status-status_tag = 0;
+ }
tp-last_tag = 0;
smp_mb();
synchronize_irq(tp-pdev-irq);
-
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/
Re: Linux 2.6.21-rc6 - regressions update
On Thu, 2007-04-05 at 19:50 -0700, Linus Torvalds wrote: Ok, I don't think there really is anything very interesting here, but we're hopefully whittling down the list of regressions, and fixing various random other small issues while at it. Some smallish MIPS updates, networking (and network driver) fixes, removal of a long obsolete framebuffer driver, etc etc. The shortlog really tells the story. We should be getting close to a 2.6.21 release, so please update any regression reports you've done, regression update for 21-rc6: 1) all s2ram and NO_HZ related things seem to be resolved on my macbook pro, also CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y don't break resume anymore. 2) However I am still having problems with +CONFIG_HIGH_RES_TIMERS=y +CONFIG_HPET=y +CONFIG_HPET_MMAP=y although the machine resumes, I've managed to get the attached oops. 3) Subject: SATA breakage on resume References : http://lkml.org/lkml/2007/3/7/233 Submitter : Thomas Gleixner [EMAIL PROTECTED] Soeren Sonnenburg [EMAIL PROTECTED] Status : unknown I am still seeing these messages after a suspend/resume cycle (though all devices work even after multiple suspend/resume cycles) ATA: abnormal status 0x80 on port 0x000140df ata3.01: revalidation failed (errno=-2) ata3: failed to recover some devices, retrying in 5 secs ata1.00: configured for UDMA/33 ATA: abnormal status 0x7F on port 0x000140df ATA: abnormal status 0x7F on port 0x000140df ata3.01: configured for UDMA/133 So that's been a big step forward... Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 CPU1 is down Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Back to C! irq 9: nobody cared (try booting with the irqpoll option) [c015] __report_bad_irq+0x24/0x90 [c01546df] note_interrupt+0x22f/0x260 [c026952d] acpi_irq+0xb/0x14 [c0153905] handle_IRQ_event+0x25/0x60 [c0155300] handle_level_irq+0xe0/0x110 [c0106e8b] do_IRQ+0x3b/0x80 [c0119637] smp_apic_timer_interrupt+0x57/0x90 [c0104c73] common_interrupt+0x23/0x28 [c01400d8] __kfifo_put+0x78/0x90 [c0130d6d] __do_softirq+0x6d/0xf0 [c0130e27] do_softirq+0x37/0x40 [c013108a] irq_exit+0x7a/0x90 [c0119637] smp_apic_timer_interrupt+0x57/0x90 [c0142d30] retrigger_next_event+0x0/0xb0 [c0104d30] apic_timer_interrupt+0x28/0x30 [c0142d30] retrigger_next_event+0x0/0xb0 [c0140068] __kfifo_put+0x8/0x90 [c0130fe5] on_each_cpu+0x35/0x60 [c0143538] clock_was_set+0x18/0x20 [c0135cdc] timekeeping_resume+0x7c/0xa0 [c02aabe1] __sysdev_resume+0x11/0x80 [c02ab0c7] sysdev_resume+0x47/0x80 [c02b0b05] device_power_up+0x5/0x10 [c014f136] suspend_enter+0x56/0x60 [c014f25a] enter_state+0x11a/0x1c0 [c014f3bd] state_store+0xbd/0xd0 [c014f300] state_store+0x0/0xd0 [c01b52c9] subsys_attr_store+0x29/0x40 [c01b5432] sysfs_write_file+0xb2/0x110 [c0175a66] vfs_write+0xa6/0x140 [c01b5380] sysfs_write_file+0x0/0x110 [c0176131] sys_write+0x41/0x70 [c0104262] sysenter_past_esp+0x5f/0x85 === handlers: [c0269522] (acpi_irq+0x0/0x14) Disabling IRQ #9 Enabling non-boot CPUs ... SMP alternatives: switching to SMP code
Re: Linux 2.6.21-rc6 - regressions update
[ Added some people to the cc.. Len, Thomas, Ingo - look for the exact report on linux-kernel, but basically it's a irq 9: nobody cared issue with acpi_irq on irq9 ] On Sat, 7 Apr 2007, Soeren Sonnenburg wrote: regression update for 21-rc6: 1) all s2ram and NO_HZ related things seem to be resolved on my macbook pro, also CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y don't break resume anymore. Goodie. I think we fixed most stuff.. 2) However I am still having problems with +CONFIG_HIGH_RES_TIMERS=y +CONFIG_HPET=y +CONFIG_HPET_MMAP=y although the machine resumes, I've managed to get the attached oops. Ok, interesting. I'd have blamed ACPI for this one (stuck IRQ9 is almost always some ACPI event that got stuck or the SCI got mis-routed and/or marked with the wrong polarity), although from your message I take it you don't get it without high-res timers? In fact, I have a theory.. Your backtrace is: [c0119637] smp_apic_timer_interrupt+0x57/0x90 [c0142d30] retrigger_next_event+0x0/0xb0 [c0104d30] apic_timer_interrupt+0x28/0x30 [c0142d30] retrigger_next_event+0x0/0xb0 [c0140068] __kfifo_put+0x8/0x90 [c0130fe5] on_each_cpu+0x35/0x60 [c0143538] clock_was_set+0x18/0x20 [c0135cdc] timekeeping_resume+0x7c/0xa0 [c02aabe1] __sysdev_resume+0x11/0x80 [c02ab0c7] sysdev_resume+0x47/0x80 [c02b0b05] device_power_up+0x5/0x10 and the thing is, I don't think we should have interrupt enabled at this point in time! I susect that the timer resume enables interrupts too early! We should be doing the whole device_power_up() sequence with irq's off, I think.. 3) Subject: SATA breakage on resume References : http://lkml.org/lkml/2007/3/7/233 Submitter : Thomas Gleixner [EMAIL PROTECTED] Soeren Sonnenburg [EMAIL PROTECTED] Status : unknown I am still seeing these messages after a suspend/resume cycle (though all devices work even after multiple suspend/resume cycles) ATA: abnormal status 0x80 on port 0x000140df This seems to be normal, and related to some unknown timing issue. If the thing works for you apart from the message, I'd just ignore it.. Linus - 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/
