Ok, the merge window for 2.6.21 has closed, and -rc1 is out there. There's a lot of changes, as is usual for an -rc1 thing, but at least so far it would seem that 2.6.20 has been a good base, and I don't think we have anything *really* scary here. The most interesting core change may be the dyntick/nohz one, where timer ticks will only happen when needed. It's been brewing for a _loong_ time, but it's in the standard kernel now as an option. But there's a ton of architecture updates (arm, mips, powerpc, x86, you name it), ACPI updates, and lots of driver work. And just a lot of cleanups. Have fun, Linus -
I'm getting an undefined symbol with CONFIG_AGP=m: WARNING: "compat_agp_ioctl" [drivers/char/agp/agpgart.ko] undefined! Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -
On Wed, Feb 21, 2007 at 07:34:01PM +0100, Andreas Schwab wrote: > I'm getting an undefined symbol with CONFIG_AGP=m: > > WARNING: "compat_agp_ioctl" [drivers/char/agp/agpgart.ko] undefined! Fix went to Linus an hour ago. It's been in -mm for a week, and agpgart.git for a day or so. Dave -- http://www.codemonkey.org.uk -
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : forcedeth no longer works References : http://bugzilla.kernel.org/show_bug.cgi?id=8090 Submitter : David P. Reed <dpreed@reed.com> Caused-By : Ayaz Abdulla <aabdulla@nvidia.com> Status : unknown Subject : forcedeth: skb_over_panic References : http://bugzilla.kernel.org/show_bug.cgi?id=8058 Submitter : Albert Hopkins <kernel@marduk.letterboxes.org> Status : unknown Subject : natsemi ethernet card not detected correctly References : http://lkml.org/lkml/2007/2/23/4 http://lkml.org/lkml/2007/2/23/7 Submitter : Bob Tracy <rct@gherkin.frus.com> Caused-By : Mark Brown <broonie@sirena.org.uk> Handled-By : Mark Brown <broonie@sirena.org.uk> Patch : http://lkml.org/lkml/2007/2/23/142 Status : patch available Subject : ThinkPad T60: system doesn't come out of suspend to RAM (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin <mst@mellanox.co.il> Handled-By : Thomas Gleixner <tglx@linutronix.de> Ingo Molnar <mingo@elte.hu> Status : unknown Subject : kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/16/346 Submitter : Michal Piotrowski <michal.k.k.piotrowski@gmail.com> Handled-By : Thomas Gleixner <tglx@linutronix.de> Status : problem is being debugged Subject : BUG: soft lockup detected on CPU#0 NOHZ: local_softirq_pending 20 (SMT scheduler) References : h...
Adrian, The BUG_ON() was replaced by a warning printk(). The BUG_ON() exposed a Patch available, not confirmed yet. tglx -
I can confirm that the bug is fixed (over 20 hours of testing should be enough). Huge thanks! 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/) -
^^^^ almost ;) 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/) -
thanks alot! I think this thing was a long-term performance/latency regression in HT scheduling as well. Ingo -
Agreed. I was recently looking at that spot because I found that niced tasks were taking latency hits, and disabled it, which helped a bunch. I also can't understand why it would be OK to interleave a normal task with an RT task sometimes, but not others.. that's meaningless to the RT task. IMHO, SMT scheduling should be a buyer beware thing. Maximizing your core utilization comes at a price, but so does disabling it, so I think letting the user decide what he wants is the right thing to do. -Mike -
Apologies for the resend, lkml address got mangled... Ingo I'm going to have to partially disagree with you on this. This has only become a problem because of what happens with dynticks now when rq->curr == rq->idle. Prior to this, that particular SMT code only leads to relative delays in scheduling for lower priority tasks. Whether or not that task is ksoftirqd should not matter because it is not like they are starved indefinitely, it is only that nice 19 tasks are relatively delayed, which by definition is implied with the usage of nice as a scheduler hint wouldn't you say? I know it has been discussed many times before as to whether 'nice' means less cpu and/or more latency, but in our current implementation, nice means both less cpu and more latency. So to me, the kernels without dynticks do not have a regression. This seems to only be a problem in the setting of the new dynticks code IMHO. That's not to say it isn't a bug! Nor am I saying that dynticks is a problem! Please don't misinterpret that. The second issue is that this is a problem because of the fuzzy definition of what idle is for a runqueue in the setting of this SMT code. Normally, rq->curr==rq->idle means the runqueue is idle, but not with this code since there are still rq->nr_running on that runqueue. What dynticks in this implementation is doing is trying to idle a hyperthread sibling on a cpu whose logical partner is busy. I did not find that added any power saving on my earlier dynticks implementation, and found it easier to keep that sibling ticking at the same rate as its partner. Of course you may have found something different, and I definitely agree with what you are likely to say in response to this- we shouldn't have to special case logical siblings as having a different definition of idle than any other smp case. Ultimately, that leaves us with your simple patch as a reasonable solution for the dynticks case even though it does change the behaviour dramatically...
(hrmph. having to copy/paste/try again. evolution seems to be broken..
RCPT TO <linux-kernel@vg.kolivas.org> failed: Cannot resolve your domain {mp049}
..caused me to be unable to send despite receipts being disabled)
No I'm not, but let's go further in that direction just for the sake of
argument. You're then saying that you prefer realtime priorities to not
work in the HT setting, given that realtime tasks don't participate in
the 'single stream me' program.
I'm saying only that we're defeating the purpose of HT, and overriding a
So? User asked for HT. That's hardware multiplexing. It ain't free.
I don't think it does actually. Let your RT task sleep regularly, and
ever so briefly. We don't evict lower priority tasks from siblings upon
To me, the reason for interleaving is solely about keeping the core
Re-read this paragraph with realtime task priorities in mind, or for
that matter, dynamic priorities. If you carry your priority/throughput
argument to it's logical conclusion, only instruction streams of
absolutely equal priority should be able to share the core at any given
time. You may as well just disable HT and be done with it.
To me, siblings are logically separate units, and should be treated as
such (as they mostly are). They share an important resource, but so do
physically discrete units.
-Mike
-Where do I say that? I do not presume to manage realtime priorities in any way. You're turning my argument about nice levels around and somehow saying that because hyperthreading breaks the single stream me semantics by parallelising them that I would want to stop that happening. Nowhere have I argued that realtime semantics should be changed to somehow work around hyperthreading. SMT nice is about managing nice only, and not realtime But the buyer is not aware. You are aware because you tinker, but the vast majority of users who enable hyperthreading in their shiny pcs are not aware. The only thing they know is that if they enable hyperthreading their programs run slower in multitasking environments no matter how much they nice the other processes. Buyers do not buy hardware knowing that the internal design breaks something as fundamental as 'nice'. You seem to presume that most people who get hyperthreading are happy to compromise 'nice' in order to get their second core working and I put it to you that they do not make that Well you know as well as I do that you're selecting out the exception rather Well that's certainly taking my logic for a ride. This is about managing _nice_ and _only_ nice. Nice specifies fixed interval static priorities where (in the risk of repeating myself) you are specifying that higher nice values tasks you wish to receive less cpu and more latency. Dynamic priorities have absolutely no effect on what the discrepancies are between the static priorities of differing nice values. As for realtime priorities, again, I do not presume to be managing them with SMT nice. They are unique entities unrelated to nice values. The only thing they have in common with nice levels is that if something is running without a realtime priority, it should be preempted by the realtime task as you have specified that the realtime task should receive all the cpu over the non-realtime task. I don't pretend that there is some cpu percentage relations...
I see no real difference between the two assertions. Nice is just a mechanism to set priority, so I applied your assertion to a different range of priorities than nice covers, and returned it to show that the code contradicts itself. It can't be bad for a nice 1 task to run with a nice 0 task, but OK for a minimum RT task to run with a maximum RT task. Iff HT without corrective measures breaks nice, then it breaks To me it's pretty much black and white. Either you want to split your cpu into logical units, which means each has less to offer than the I don't agree that it's the exception, and if you look at this HT thing from the split cpu perspective, I'm not sure there's even a problem. Scrolling down, I see that this is getting too long, and we aren't The above will have to do. -Mike -
i'm starting to lean towards your view that we should not artificially keep tasks from running, when there's a free CPU available. We should still keep the 'other half' of SMT scheduling: the immediate pushing of tasks to a related core, but this bit of 'do not run tasks on this CPU' dependent-sleeper logic is i think a bit fragile. Plus these days SMT siblings do not tend to influence each other in such a negative way as older P4 ones where a HT sibling would slow down the other sibling significantly. plus with an increasing number of siblings (which seems like an inevitable thing on the hardware side), the dependent-sleeper logic becomes less and less scalable. We'd have to cross-check every other 'related' CPU's current priority to decide what to run. if then there should be a mechanism /in the hardware/ to set the priority of a CPU - and then the hardware could decide how to prioritize between siblings. Doing this in software is really hard. Ingo -
Well it is meant to be tuned to the cpu type in per_cpu_gain. So it should be easy to be set to the appropriate scaling. It was never meant to be a one Yes even I've commented before that this current system is unworkable come multiple shared power threads. This I do see as a real problem with it - in And that's the depressing part because of course I was interested in that as the original approach to the problem (and it was a big problem). When I spoke to Intel and AMD (of course to date no SMT AMD chip exists) at kernel summit they said it was too hard to implement hardware priorities well. Which is real odd since IBM have already done it with Power... Still I think it has been working fine in software till now, but now it has to deal with the added confusion of dynticks, so I already know what will happen to it. Hrm it's been a good time for my code all round... I think I'll just swap prefetch myself up the staircase to some pluggable scheduler that would hyperthread me to sleep as an idle priority task. -- -ck -
Well, it's not a dyntick problem in the first place. Even w/o dynticks we go idle with local_softirq_pending(). Dynticks contains an explicit check for that, which makes it visible. tglx -
Oops I'm sorry if I made it sound like there's a dynticks problem. That was not my intent and I said as much in an earlier email. Even though I'm finding myself defending code that has already been softly tagged for redundancy, let's be clear here; we're talking about at most a further 70ms delay in scheduling a niced task in the presence of a nice 0 task, which is a reasonable delay for ksoftirqd which we nice the eyeballs out of in mainline. Considering under load our scheduler has been known to cause scheduling delays of 10 seconds I still don't see this as a bug. Dynticks just "points it out to us". -- -ck -
well, not running softirqs when we could is a bug. It's not a big bug, but it's a bug nevertheless. It doesnt matter that softirqs could be delayed even worse under high load - there was no 'high load' here. Ingo -
Gotcha. I'll prepare a smt-nice removal patch shortly. -- -ck -
Remove the SMT-nice feature which idles sibling cpus on SMT cpus to
facilitiate nice working properly where cpu power is shared. The idling
of cpus in the presence of runnable tasks is considered too fragile, easy
to break with outside code, and the complexity of managing this system if an
architecture comes along with many logical cores sharing cpu power will be
unworkable.
Remove the associated per_cpu_gain variable in sched_domains used only by
this code.
Signed-off-by: Con Kolivas <kernel@kolivas.org>
---
include/asm-i386/topology.h | 1
include/asm-ia64/topology.h | 2
include/asm-mips/mach-ip27/topology.h | 1
include/asm-powerpc/topology.h | 1
include/asm-x86_64/topology.h | 1
include/linux/sched.h | 1
include/linux/topology.h | 4
kernel/sched.c | 155 ----------------------------------
8 files changed, 1 insertion(+), 165 deletions(-)
Index: linux-2.6.21-rc2/kernel/sched.c
===================================================================
--- linux-2.6.21-rc2.orig/kernel/sched.c 2007-03-02 08:56:45.000000000 +1100
+++ linux-2.6.21-rc2/kernel/sched.c 2007-03-02 08:58:40.000000000 +1100
@@ -3006,23 +3006,6 @@ static inline void idle_balance(int cpu,
}
#endif
-static inline void wake_priority_sleeper(struct rq *rq)
-{
-#ifdef CONFIG_SCHED_SMT
- if (!rq->nr_running)
- return;
-
- spin_lock(&rq->lock);
- /*
- * If an SMT sibling task has been put to sleep for priority
- * reasons reschedule the idle task to see if it can now run.
- */
- if (rq->nr_running)
- resched_task(rq->idle);
- spin_unlock(&rq->lock);
-#endif
-}
-
DEFINE_PER_CPU(struct kernel_stat, kstat);
EXPORT_PER_CPU_SYMBOL(kstat);
@@ -3239,10 +3222,7 @@ void scheduler_tick(void)
update_cpu_clock(p, rq, now);
- if (p == rq->idle)
- /* Task on the idle queue */
- wake_priority_sleeper(rq);
- else
+ if (p != rq->idl...Well, dyntick might end up to delay it for X seconds as well, which _is_ observable and that's why the check was put there in the first place. tglx -
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : resume: slab error in verify_redzone_free(): cache `size-512':
memory outside object was overwritten
References : http://lkml.org/lkml/2007/2/24/41
Submitter : Pavel Machek <pavel@ucw.cz>
Handled-By : Marcel Holtmann <marcel@holtmann.org>
Status : unknown
Subject : ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin <mst@mellanox.co.il>
Handled-By : Ingo Molnar <mingo@elte.hu>
Status : unknown
Subject : HP nx6325 notebook: usb mouse stops working after suspend to ram
References : http://lkml.org/lkml/2007/2/21/413
Submitter : Arkadiusz Miskiewicz <arekm@maven.pl>
Caused-By : Konstantin Karasyov <konstantin.a.karasyov@intel.com>
commit 0a6139027f3986162233adc17285151e78b39cac
Status : unknown
Subject : ACPI update breaks kpowersave
References : http://lkml.org/lkml/2007/2/10/7
Submitter : Ismail Dönmez <ismail@pardus.org.tr>
Fabio Comolli <fabio.comolli@gmail.com>
Status : unknown
Subject : MacBook: AE_NOT_FOUND ACPI messages
References : http://bugzilla.kernel.org/show_bug.cgi?id=8066
Submitter : Thomas Meyer <thomas.mey@web.de>
Status : unknown
Subject : Asus A8N-VM motherboard:
framebuffer/console boot failure boot failure (ACPI related)
References : http://lkml.org/lkml/2007/2/23/132
Submitter : Andrew Nelless <andrew@nelless.net>
Handled-By : Antonino A. Daplas <...Still appears, but this does not seem to be 40/80 pin cable problem to be but rather ata-piix calling some acpi methods and this rulsts in acpi errors. -- Meelis Roos (mroos@linux.ee) -
On Tue, 27 Feb 2007 15:00:29 +0200 (EET) There are two separate problems showing up in the one trace - broken ACPI spew and wrong cable detect. I don't think they are related -
Just reproduced this in -rc2. Another thing I noticed: with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM. On 2.6.21-rc2, after resume (when the box is accessible from network), pressing Fn/F4 again does not seem to have any effect. -- MST -
I have the same problem on my IBM X60s on rc1 and rc2. Can't resume from RAM, can't suspend to disk. It is possible to revert all the changes to ACPI and test it? Jeff. -
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
-Yes. -
I've tried with CONFIG_KVM=n and CONFIG_KVM=y and both does not suspend. -
Do you mean that they "do not resume after suspend"? -- MST -
I can't even suspend to disk/ram. It just hangs and the lights just blink and everything else hangs. With 2.6.20, it works fine. Jeff. -
Turn up console loglevel, and see where it hangs... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
I think CONFIG_DISABLE_CONSOLE_SUSPEND would have to be set for this purpose too. Greetings, Rafael -
As I said elsewhere in the thread, suspend/resume to RAM works ok on my thinkpad x60. I posted my .config there, perhaps difference is in it? Ingo identified KVM as possible culprit. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
I'll try your .config for kicks, the problem that Ingo pin pointed is not what is affecting me. -- Jens Axboe -
Can you please get the dmesg output after resume via the network ? tglx -
The link above has it. -- MST -
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20 that are not yet fixed in Linus' tree. If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues. Due to the huge amount of recipients, please trim the Cc when answering. Subject : forcedeth: skb_over_panic References : http://bugzilla.kernel.org/show_bug.cgi?id=8058 Submitter : Albert Hopkins <kernel@marduk.letterboxes.org> Status : unknown Subject : natsemi ethernet card not detected correctly References : http://lkml.org/lkml/2007/2/23/4 http://lkml.org/lkml/2007/2/23/7 Submitter : Bob Tracy <rct@gherkin.frus.com> Caused-By : Mark Brown <broonie@sirena.org.uk> Handled-By : Mark Brown <broonie@sirena.org.uk> Patch : http://lkml.org/lkml/2007/2/23/142 Status : patch available Subject : request_module: runaway loop modprobe net-pf-1 References : http://lkml.org/lkml/2007/2/21/206 Submitter : YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> Caused-By : Kay Sievers <kay.sievers@vrfy.org> commit c353c3fb0700a3c17ea2b0237710a184232ccd7f Handled-By : Greg KH <greg@kroah.com> Status : problem is being discussed Subject : IPV6=m, SUNRPC=y compile error References : http://bugzilla.kernel.org/show_bug.cgi?id=8050 http://lkml.org/lkml/2007/2/12/442 http://lkml.org/lkml/2007/2/20/384 Submitter : Michael-Luke Jones <mlj28@cam.ac.uk> Pete Clements <clem@clem.clem-digital.net> Sid Boyce <g3vbv@blueyonder.co.uk> Caused-By : Chuck Lever <chuck.lever@oracle.com> Handled-By : YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@linux-ipv6.org> Status : patch available Subject : WARNING: "compat_agp_ioctl" undefin...
Patch has been reverted and submitted to Linus to pull, but he's out of town right now... thanks, greg k-h -
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : ThinkPad T60: system doesn't come out of suspend to RAM
(CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin <mst@mellanox.co.il>
Thomas Gleixner <tglx@linutronix.de>
Handled-By : Ingo Molnar <mingo@elte.hu>
Status : unknown
Subject : kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/16/346
Submitter : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status : problem is being debugged
Subject : BUG: soft lockup detected on CPU#0
NOHZ: local_softirq_pending 20
References : http://lkml.org/lkml/2007/2/20/257
Submitter : Michal Piotrowski <michal.k.k.piotrowski@gmail.com>
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Ingo Molnar <mingo@elte.hu>
Status : problem is being debugged
Subject : i386: no boot with nmi_watchdog=1 (clockevents)
References : http://lkml.org/lkml/2007/2/21/208
Submitter : Daniel Walker <dwalker@mvista.com>
Caused-By : Thomas Gleixner <tglx@linutronix.de>
commit e9e2cdb412412326c4827fc78ba27f410d837e6e
Handled-By : Thomas Gleixner <tglx@linutronix.de>
Status : problem is being debugged
-x60 doesn't resume from S2R either, it doesn't matter if CONFIG_NO_HZ is set or not though. 2.6.20 worked fine. -- Jens Axboe -
Is this Subject : ThinkPad T60: no screen after suspend to RAM References : http://lkml.org/lkml/2007/2/22/391 Submitter : Michael S. Tsirkin <mst@mellanox.co.il> Ingo Molnar <mingo@elte.hu> Handled-By : Ingo Molnar <mingo@elte.hu> Status : unknown 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 -
It doesn't resume at all. -- Jens Axboe -
It somehow works for me. As long as I do not play with bluetooth and suspend to disk... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
It locks solid here on resume, going back to 2.6.20 makes it work perfectly again. In between 2.6.20 and 2.6.21-rc1 some ACPI change broke resume, but that got fixed. Some other change later snuck in that broke it AGAIN for me, sigh. I don't use bluetooth nor suspend to disk. -- Jens Axboe -
resume is stock on my T60 too. So you mean v2.6.21-rc1 vanilla works fine? Do you know a commit ID that works for sure? I'd like to bisect this, but this way i might just find that ACPI change that got already fixed later on (and then got re-broken). Ingo -
Nope, 2.6.21-rc1 vanilla does not work. 2.6.20 works. 2.6.20-gitX worked until some acpi change broke it, the below patch fixed that for me. That got merged in a later 2.6.20-gitY, but then some other patch broke it again so that 2.6.21-rc1 is broken. Not much luck there :-) So it looks like: - c5a7156959e89b32260ad6072bbf5077bcdfbeee broke 2.6.20-git - f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 should fix that. - Something later than f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 broke it Yeah, it gets trickier. I'll try f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 now and see if that works, then bisect to 2.6.21-rc1 to find the other offender. I hope the other offender didn't get added before f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38, we'll see :-) -- Jens Axboe -
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, starting bisect. -- Jens Axboe -
update: f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me too, and 01363220f5d23ef68276db8974e46a502e43d01d is broken. I too will attempt to bisect this. Ingo -
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, too. -- MST -
Strange; on my x60, suspend to ram works okay.
(Resume is very slow, because disks are not spinned up properly; and
there's something wrong with timers; console beeps take way too long).
dmesg attached.
That's with
commit 7b965e0884cee430ffe5dc81cdb117b9316b0549
tree 754dce6432258e0a8c3a758e13a34eb3a1d22ee1
parent 5a39e8c6d655b4fe8305ef8cc2d9bbe782bfee5f
author Trond Myklebust <Trond.Myklebust@netapp.com> Wed, 28 Feb 2007
20:13:55 -0800
committer Linus Torvalds <torvalds@woody.linux-foundation.org> Thu, 01
Mar 2007 14:53:39 -0800
[PATCH] VM: invalidate_inode_pages2_range() should not exit early
Fix invalidate_inode_pages2_range() so that it does not
immediately exit
just because a single page in the specified range could not be
removed.
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.htmlPavel, I tried with your .config, and indeed the system came back to life after 2-3 minutes after I press Fn/F4, indeed the issue seems to be with the disk. It could be that the same takes place with my original .config - maybe I just wasn't patient enough. I'll need to re-test that. However, I noticed that, after resume, when the system is presumably functional, if I try to suspend to ram again, this second suspend hangs, displaying the following on screen: [ 17.170000] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 17.170000] PCI: Setting latency timer of device 0000:02:00.0 to 64 [ 17.250000] e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:41:5 4:6c:47 [ 17.330000] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection the crescent LED starts blinking and does not seem to stop for at lest 10 min, I've run out of patience after that. It could be that it's just very slow again. Pavel, did you try suspend to RAM after a successfull resume from RAM? Under 2.6.20, the system suspends/resumes to memory within about 20 sec any number of times. -- MST -
Seems to work ok in -rc3... as long as I do not mix s2ram with s2disk. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -
the spin-up takes a few seconds here under suspend/resume simulation: | ata1: waiting for device to spin up (7 secs) | Restarting tasks ... done. [5-10 seconds pass] | ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) | ata1.00: configured for UDMA/100 | SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) | sda: Write Protect is off | sda: Mode Sense: 00 3a 00 00 | SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA with real resume it takes even longer time - but i dont see where the delays come from in that case - i suspect it's SATA. i'm also getting this WARN_ON() from e1000: BUG: at drivers/pci/msi.c:611 pci_enable_msi() [<c01061bd>] show_trace_log_lvl+0x19/0x2e [<c01062b6>] show_trace+0x12/0x14 [<c01062cc>] dump_stack+0x14/0x16 [<c024fcc4>] pci_enable_msi+0x6d/0x203 [<c02b709e>] e1000_request_irq+0x2e/0xe2 [<c02bb742>] e1000_resume+0x7f/0xef [<c0249a68>] pci_device_resume+0x1a/0x44 [<c02b39ec>] resume_device+0xf7/0x16f [<c02b3adb>] dpm_resume+0x77/0xcb [<c02b3b69>] device_resume+0x3a/0x51 [<c014e669>] enter_state+0x193/0x1bb [<c014e712>] state_store+0x81/0x97 [<c01b68bc>] subsys_attr_store+0x20/0x25 [<c01b6feb>] sysfs_write_file+0xce/0xf6 [<c017e16b>] vfs_write+0xb1/0x13a [<c017e899>] sys_write+0x3d/0x61 [<c0105220>] syscall_call+0x7/0xb seems harmless because it seems to work fine. Ingo -
SATA has another nice feature. Somehow there is an interrupt pending on the SATA controller, which comes in somewhere in the middle of resume. If it happens before the SATA code resumed, the SATA code ignores the interrupt and the interrupt is disabled due to "nobody cared", which in turn prevents SATA to ever become functional again. Any idea on that one ? tglx -
Jeff - that sounds like a SATA bug. If you have an interrupt handler registered, you'd better handle the interrupt regardless of whether you think the hardware might be gone or not. It's generally *not* ok to do if (device_offline()) return IRQ_NONE; at the top of an interrupt handler. Of course, if you think the hardware is supposed to be quiescent, then the only thing you should do is generally just do the "shut up" operation (ie read status, write it back or whatever). You must generally *not* try to pass any data upwards (ie if the higher layers have told you to shut up, you may need to handle the hardware, but you must not involve the higher layers themselves any more, because they expect you to be quiet). And if you cannot do that because you need to resume in order to have the status register mapped, then you need to have an "early_resume()" function which gets called *before* interrupts are enabled. That's what early-resume (and late-suspend) are designed for: doing things that happen very early in the resume sequence before everything is up. And if you don't want to do any of these things (or are unable to, because of some ordering constraint or bad design), then you simply need to Jeff, Auke, does this ring any bells? Linus -
For the e1000 issue, the problem is solved with Eric Biederman's 3-patch msi cleanups. You should have another message in your mailbox confirming that I tested his patches and the MSI warning for e1000 suspend-resume is gone with them. Cheers, Auke -
update: Thomas' PIT/HPET resume-fix patch fixed the delay for me. Ingo -
I would poke Eric Biederman(sp?) about this one. Maybe its even solved by the MSI-enable-related patch he posted in the past 24-48 hours. Jeff -
Eric, Linus, I tried the 3-patch series "[PATCH 0/3] Basic msi bug fixes.." and they fix this problem for me. Were you expecting the OOPS in the first place? In any case, it survived several suspend/resume cycles on both enabled (irq alloc'd and enabled) and disabled devices (only initialized). Jens Axboe was seeing the same problem, perhaps he can confirm the fix as well. In any case, the patches have my blessing :) Please add my: Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com> Cheers, Auke -
the bug was the warning message (a WARN_ON()) above - not an oops. So that warning message is gone in your testing? Ingo -