On Mon, 9 Jan 2006, Martin Langhoff wrote:
I think it does. All the tricky stuff that David and Junio have been
discussing is actually done very transparently by
git-rebase upstream
Yes, it's fairly easy to do. That said, I would actually discourage it. I
haven't said anything to
On Mon, 9 Jan 2006, Al Viro wrote:
How do you deal with conflict resolution? That's a genuine question -
I'm not talking about deliberate misuse to hide an attack, just a normal
situation when you have to resolve something like
A:
if (foo)
bar
B:
if (foo
On Mon, 9 Jan 2006, Linus Torvalds wrote:
One thing we could do is to make it easier to apply a patch to a
_non_current_ branch.
[ ... ]
Do you think that kind of workflow would be more palatable to you? It
shouldn't be /that/ hard to make git-apply branch-aware... (It was part of
my
On Mon, 9 Jan 2006, Luben Tuikov wrote:
Yes. Ever since I started used git, I never used branch
switching, but I do have git branches and I do use git branching.
I basically have a branch per directory, whereby the object db
is shared as is remotes/refs/etc, HEAD and index are not
It turns out that the Apple Mac Mini comes back from suspend in legacy
mode.
The simplest and most obvious fix would seem to be the following trivial
one-liner, which just enables ACPI mode after any suspend event.
Comments? Can anybody see any downsides to just doing something this
obvious,
On Sat, 17 Jun 2006, Linus Torvalds wrote:
It turns out that the Apple Mac Mini comes back from suspend in legacy
mode.
Actually, that wasn't it. My debugging patches use the RTC to save off
information, and that causing a test-kernel to not compile the test, or
just normal incompetence
On Sun, 9 Jul 2006, Brown, Len wrote:
Fair enough. Reverted.
I disagree with this decision, and would like to know what
is necessary to reverse it.
Mistakes happen. Fair enough. They happen all the time. This time around,
for the 2.6.18-rc1 thing, I had heard more than the usual nobody
On Sun, 9 Jul 2006, Brown, Len wrote:
So I ask you. If I fix the Kconfig issue today, will you accept
a push that restores this driver to 2.6.18?
Sure.
Linus
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
Hmm.
What's up with this?
2341 ?D 0:00 [kacpid_notify]
2342 ?D 0:00 [kacpid_notify]
2343 ?D 0:00 [kacpid_notify]
2344 ?D 0:00 [kacpid_notify]
2345 ?D 0:00 [kacpid_notify]
2346 ?D 0:00 [kacpid_notify]
2347 ?D
On Wed, 12 Jul 2006, Linus Torvalds wrote:
(apparently about 300 of those processes, at which point the machine just
hangs, because even root cannot start any new processes, and I couldn't
actually get to debug this at all).
With ACPI debugging, I notice that it finally dies due to ACPI
On Wed, 12 Jul 2006, Linus Torvalds wrote:
I've got a hundred-odd commits to go, but the next bisection test happens
to be the parent of my merge (your merge linus into release branch
merge: ae6c859b7dcd708efadf1c76279c33db213e3506), so if I'm right, I'd
expect that to be a bad tree
On Wed, 12 Jul 2006, Brown, Len wrote:
Likely related to bugzilla-5534
b8d35192c55fb055792ff0641408eaaec7c88988
Well, that one certainly looks likely.
Any reason to not just revert it? The fundamental problems that it
introduces are obviously much worse than the fix.
On Wed, 12 Jul 2006, Linus Torvalds wrote:
Any reason to not just revert it? The fundamental problems that it
introduces are obviously much worse than the fix.
Ok, that commit b8d35192c55fb055792ff0641408eaaec7c88988 is definitely
horribly horribly broken.
I'm going to revert it, because
On Thu, 13 Jul 2006, Starikovskiy, Alexey Y wrote:
I'm terribly sorry that my patch broke on your machine.
May I ask you to send me or attach to #5534 output of acpidump from this
machine?
I'll send it in another email, since I already generated it for Len ;)
Do you think that the whole
On Wed, 27 Sep 2006, Linus Torvalds wrote:
On Wed, 27 Sep 2006, Andi Kleen wrote:
I expect this patch to fix it.
Andrew, Kyle, can you verify?
Not that it really matters. Andi sure as hell pinpointed a real problem
with the new and broken inline asm. That's almost certainly the bug
On Wed, 27 Sep 2006, Andi Kleen wrote:
It doesn't matter much because these days this stuff is all out of lined
anyways and in a single function. And the dynamic branch predictor
in all modern CPUs will usually cache the decision (unlocked) there.
Ahh, good point. Once there's only one
On Mon, 30 Oct 2006, Jun'ichi Nomura wrote:
Please revert the patch. I'll fix the wrong error handling.
I'm not sure reverting the patch solves the ACPI problem
because Michael's kernel seems not having any user of
bd_claim_by_kobject.
Yeah, doing a grep does seem to imply that there is
On Wed, 1 Nov 2006, Ernst Herzberg wrote:
still bisecting, will report the result.
Figuring out what caused an apparent change of behaviour is definitely a
good idea - it might give us some clue to what really is going on.
(Or it might not. Sometimes the patch that triggers changes really
On Wed, 1 Nov 2006, Michael S. Tsirkin wrote:
I've been bisecting ACPI/suspend thinkpad issue myself and I seem to get
eea0e11c1f0d6ef89e64182b2f1223a4ca2b74a2 good,
cf4c6a2f27f5db810b69dcb1da7f194489e8ff88 bad.
Very interesting..
That commit cf4c6a2f on the face of it looks like an
feel like they want to
learn more about the IO-APIC? Halloween is over and gone, but if you want
to scare small children _next_ year, telling them about the IO-APIC is
likely a good strategy.
Linus
---
commit f9dadfa71bc594df09044da61d1c72701121d802
Author: Linus Torvalds
On Wed, 1 Nov 2006, Michael S. Tsirkin wrote:
I've pushed out the changes, but here is the part that may or may not
matter for anybody who wants to test it if they don't use git or if it
hasn't mirrored out yet. Michael? Martin?
I pulled the latest git, and seems to work for me,
On Tue, 14 Nov 2006, Stephen Hemminger wrote:
During the pci_restore process, the MSI information and the PCI command
register
are restored properly. But later during resume, inside the ACPI evaluation of
the WAK method, the PCI_COMMAND INTX_DISABLE (0x400) flag is being cleared.
My
On Wed, 15 Nov 2006, Len Brown wrote:
So it looks like we need this sequence:
enable_nonboot_cpus() /* INIT */
finish() /* _WAK */
device_resume()
Can somebody remind me about this immediately after 2.6.19?
No way am I going to make that kind of a major ordering change right now,
On Fri, 17 Nov 2006, Adrian Bunk wrote:
Subject: nasty ACPI regression, AE_TIME errors
References : http://lkml.org/lkml/2006/11/15/12
Submitter : David Brownell [EMAIL PROTECTED]
Handled-By : Len Brown [EMAIL PROTECTED]
Alexey Starikovskiy [EMAIL PROTECTED]
Status
On Fri, 17 Nov 2006, Linus Torvalds wrote:
Total lockup - no sysrq, no messages, no nothing.
Dammit.
It looks like 37605a6900f6b4d886d995751fcfeef88c4e462c, and I should have
realized that immediately.
That commit re-introduces the bug that we already reverted once.
Why the hell did
On Sat, 18 Nov 2006, Starikovskiy, Alexey Y wrote:
May because it does not have a single common line with the previous
patch?
Yeah, I do agree that it _looks_ very different as a patch, but it ends up
having all the same execution profiles..
It's been too long since I debugged the previous
On Sat, 18 Nov 2006, Starikovskiy, Alexey Y wrote:
I've sent you a test patch back in July, but did not get a reply. May be
due to OLS?
Heh. Whenever you send me something like that, and I don't answer within a
few days, you can pretty much depend on me not answering - my mailqueue
just
On Sat, 18 Nov 2006, David Brownell wrote:
Running right now with a patch reverting the update which
made trouble on Linus' machine, but without Alexey's two
tweaks to the EC interrupt handler. So far so good, even
after doing things which had previously caused AE_TIME
errors pretty
On Fri, 1 Dec 2006, Pavel Machek wrote:
So it looks like we need this sequence:
enable_nonboot_cpus() /* INIT */
finish() /* _WAK */
device_resume()
Can somebody remind me about this immediately after 2.6.19?
Remind. But note that freezer is not yet SMP safe... Rafael
On Wed, 20 Dec 2006, Len Brown wrote:
please pull from:
Is this really all obvious bug-fixes? There seems to be a lot of
development there that simply isn't appropriate after an -rc1 any more.
I want 2.6.20 to be stable, and one of the things I'm doing is to be
strict about the merge
On Wed, 7 Mar 2007, Ash Milsted wrote:
So, I tracked this down to 2.6.21-git7, the first snapshot that gives me
this problem.
Hmm. There is no 2.6.21-git7 (that would be the seventh nightly snapshot
after 2.6.21 is released, which hasn't happened yet!).
Do you mean that it happens between
On Wed, 7 Mar 2007, Ash Milsted wrote:
Anyway, here's the bootlog for Dmitry from a boot with broken keyboard
(2.6.21-rc3):
The non-working setup doesn't get any interrupts back, and thus doesn't
see the ACK for the \xd4\xed command.
It really looks interrupt-related (especially
[ Eric, Ingo, can you double-check the timer initialization after resume?
We appear to have several reports of date not advancing, and while this
could be some SATA issue, it could easily be a timer tick issue too ]
On Thu, 8 Mar 2007, Michael S. Tsirkin wrote:
Here's the status with
On Fri, 9 Mar 2007, Ingo Molnar wrote:
disabling the following radeonfb options in the .config made resume work
again:
In general, don't even *try* to use radeonfb for suspend/resume.
I don't think it has ever worked, except on some very rare laptops
(largely PPC Macs) where people had
On Fri, 9 Mar 2007, Ingo Molnar wrote:
Some day we may have modesetting support in the kernel for some
graphics hw, right now it's pretty damn spotty.
having no video is what i'd have expected - but getting a /hang/ is not
what i'd have expected.
I debugged a case exactly like this
On Wed, 28 Mar 2007, Maxim wrote:
Now I don't have a clue how to set those bits if only HPET is used as
clock source because now clocksources
don't have _any_ resume hook.
One thing that drives me wild about that clocksource resume thing is
that it seems to think that
On Thu, 29 Mar 2007, Maxim wrote:
I am sending here a patch that as was discussed here adds hpet to list
of system devices
and adds suspend/resume hooks this way.
I tested it and it works fine.
Ok, it certainly looks better, but it *also* looks like it just assumes
the
On Thu, 29 Mar 2007, Maxim wrote:
On Thursday 29 March 2007 07:08:58 Linus Torvalds wrote:
(Or, better yet, shouldn't we set boot_hpet_disable when we decide not
to use the HPET, and set hpet_virt_address to NULL?)
This is done here
out_nohpet:
iounmap(hpet_virt_address
On Thu, 29 Mar 2007, Maxim Levitsky wrote:
Subject: Add suspend/resume for HPET
This adds support of suspend/resume on i386 for HPET
Signed-off-by: Maxim Levitsky [EMAIL PROTECTED]
---
arch/i386/kernel/hpet.c | 68
+++
Btw, what about
On Thu, 29 Mar 2007, Maxim Levitsky wrote:
I agree, and as you said I did exactly that:
Gaah. I'm blind. Sorry. Your patch did indeed do exactly that, I somehow
overlooked it.
Linus
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a
On Sat, 31 Mar 2007, Thomas Gleixner wrote:
While I agree in principle with the patch, I'm a bit uncomfortable. The
sys device suspend / resume ordering is not guaranteed and relies on the
registering order.
Well, this is why we probably should try to get away from the system
device
On Sat, 31 Mar 2007, Thomas Gleixner wrote:
Right, but clock - sources/events need to be extremly late suspended and
early resumed. How can we ensure this ?
Make them be at the top of the device tree by adding them early. That's
the whole point of the device tree after all - we have an
On Sat, 31 Mar 2007, Maxim Levitsky wrote:
So maybe I was right afrer all,
Maybe it is better to add a suspend/resume hook to each clock source and call
it from timekeeping_resume() ?
Umm.. WHy not make the device tree look like this:
-- clocksource -- +-- HPET
On Thu, 10 May 2007, Linus Torvalds wrote:
Seems to work for me. My evo correctly started the fan, and stopped it
when the temperature went down again.
Looking at things in top, I do end up occasionally seeing spikes where
kacpid takes 17% of CPU time, and kacpi_notify takes a few percent
On Fri, 11 May 2007, Rafael J. Wysocki wrote:
We're working on fixing the breakage, but currently it's difficult, because
none of my testboxes has problems with the 'platform' hibernation and I
cannot reproduce the reported issues.
The rule for anything ACPI-related has been: no
On Fri, 11 May 2007, Rafael J. Wysocki wrote:
Just to clarify, the change in question isn't new. It was introduced by the
commit 9185cfa92507d07ac787bc73d06c4eec7239 before 2.6.20, at Seife's
request and with Pavel's acceptance.
Ok, if it's that old, we migt as leave it in. Clearly
On Sun, 22 Jul 2007, Len Brown wrote:
please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
Pulled.
Btw, on a mostly unrelated note (and to balance the fact that mostly I
only speak up to complain), I'd like to say how much I appreciate that
On Wed, 25 Jul 2007, Len Brown wrote:
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release
Fixes regressions -- a build failure, an oops, some dmesg spam.
Also fixes some D-state issues and adds ACPI module auto-loading.
Yes, I'd hoped to get the last two in
On Thu, 26 Jul 2007, Rafael J. Wysocki wrote:
Hmm, perhaps we should introduce a CONFIG_SUSPEND and change
CONFIG_SOFTWARE_SUSPEND into CONFIG_HIBERNATION, both depending on
CONFIG_PM?
There's quite some code needed only for suspend compiled in when CONFIG_PM is
set ...
Sounds like a
On Thu, 26 Jul 2007, Len Brown wrote:
Feel free to share what you know about the benefits vs. the costs
of maintaining CONFIG_ACPI_SLEEP as a build option.
Why don't you just make CONFIG_ACPI_SLEEP dependent on SOFTWARE_SUSPEND
and STR?
If you feel that your system has been degraded
for the user whether he wants
suspend and/or hibernation support, and ACPI shouldn't care.
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
---
drivers/acpi/Kconfig |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
On Sat, 28 Jul 2007, Len Brown wrote:
That three-liner will crash ACPI+SMP-HOTPLUG_CPU kernels on resume.
Explain that to me.
There should *be* no resume.
ACPI doesn't suspend/resume on its own, I hope.
It is all done by the top-level suspend/resume code, not by ACPI. ACPI is
a pure
On Sat, 28 Jul 2007, Linus Torvalds wrote:
And it's the *top*level* code that selects HOTPLUG_CPU. Through
SUSPEND_SMP (which will select HOTPLUG_CPU) and SOFTWARE_SUSPEND.
In other words, the problem seems to be that
kernel/power/main.c:
suspend_devices_and_enter
On Sat, 28 Jul 2007, Rafael J. Wysocki wrote:
OK, I'll prepare a patch to introduce CONFIG_SUSPEND, but that will require
quite a bit of (compilation) testing on different architectures.
Sure. I'm not too worried, the fallout should be of the trivial kind.
Also, mind basing it on the
Ok, I took this, and modified Len's patch to re-introduce ACPI_SLEEP on
top of it (I took the easy way out, and just made PM_SLEEP imply
ACPI_SLEEP, which should make everything come out right. I could have
dropped ACPI_SLEEP entirely in favour of PM_SLEEP, but that would have
implied
On Thu, 2 Aug 2007, Cal Peake wrote:
Figured I should have sent that right after I hit the send key...
processor : 0
vendor_id : AuthenticAMD
cpu family: 15
model : 72
model name: AMD Turion(tm) 64 X2 Mobile Technology TL-52
Sadly, this doesn't show the
On Thu, 2 Aug 2007, Cal Peake wrote:
On Thu, 2 Aug 2007, Linus Torvalds wrote:
That said, the AMD Turion(tm) 64 X2 Mobile Technology TL-52 _should_ be
a REV-F CPU afaik, and it should have thus fallen through to the
ENABLE_C1E_MASK logic. Afaik that's broken.
Cal - can you
On Wed, 29 Aug 2007, Michal Piotrowski wrote:
Clocks time
Subject : double hpet clocksource hard freeze
References : http://lkml.org/lkml/2007/8/23/257
Last known good : ?
Submitter : Paolo Ornati [EMAIL PROTECTED]
Caused-By : Tony Luck [EMAIL PROTECTED]
On Tue, 25 Sep 2007 08:51:09 +0200 Damien Wyart [EMAIL PROTECTED] wrote:
Hello,
After testing rc8, I noticed that I couldn't power off the computer
directly, it only got halted and I had to press the power button
manually. Just before displaying System halted, the following message
is
On Wed, 17 Oct 2007, Qi Yong wrote:
The key point is fall back to shutdown _only_ if !ops, otherwise
don't touch hibernation_mode. And that solves my problem.
Please, when resurrecting a five-month-old discussion, give more of the
old context.
I don't know about anybody else, but I get
On Tue, 25 Dec 2007, Rafael J. Wysocki wrote:
the ACPI specification between versions 1.0x and 2.0. Namely, while ACPI
2.0 and later wants us to put devices into low power states before calling
_PTS, ACPI 1.0x wants us to do that after calling _PTS. Since we're following
the 2.0 and later
On Thu, 27 Dec 2007, Robert Hancock wrote:
I doubt they would prefer the later ordering in any way that matters, if the
Windows version they were designed for uses the earlier ordering.
Well, I wouldn't say it's abotu preferring one over the other. It's very
possible that the BIOS writers
On Mon, 11 Feb 2008, Carlos Corbacho wrote:
WMI drivers, like their ACPI counterparts, should also check if ACPI is
disabled or not, and bail out if so, otherwise we cause a crash.
Shouldn't wmi_has_guid() just return false if ACPI isn't enabled, and
the drivers should just then always
On Tue, 19 Feb 2008, Jesse Barnes wrote:
I found the same poweroff issue on my T61. It turned out to be related to
the
C state code disabling interrupts when it shouldn't iirc. Booting
with 'idle=poll' seems to work around the problem.
The green screen problem should be fixed (see
On Thu, 21 Feb 2008, Jeff Chua wrote:
After inserting return 0; right at the top of those two functions, suspend
(and power-off properly), and resume (without green screen) works just fine.
I would like to know what they're for.
Try suspend-and-resume without X.
Also, try it on one of
On Thu, 21 Feb 2008, Jeff Chua wrote:
Works without those two functions.
Ahh. You're using the BIOS to re-initialize your video, aren't you?
If STR works without X, then you have something else resuming graphics,
and that may be what then interacts badly with the fact that the kernel
On Thu, 21 Feb 2008, Jeff Chua wrote:
That said, before you do anything else, try if suspend-to-RAM works.
Linus, guess I missed this part ... so before touch anything, I did
tried suspend-to-ram, and it works on console and in X.
Ok, so this is with clean current -git, and nothing
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
I think we should export the target sleep state somehow.
Yeah. By *not* using -suspend() for freezing or hibernate.
Please, Rafael - just make the f*cking suspend-to-disk use other routines
already. 99% of all hardware needs to do exactly
On Wed, 20 Feb 2008, Jesse Barnes wrote:
The current callback system looks like this (according to Rafael and the last
time I looked):
-suspend(PMSG_FREEZE)
-resume()
-suspend(PMSG_SUSPEND)
*enter S3 or power off*
-resume()
Yes, it's very messy.
It's messy for a few
On Wed, 20 Feb 2008, Jesse Barnes wrote:
Really, in the simple s3 case we still need early/late stuff?
Absolutely.
Two big reasons:
- debuggability
I know we don't do this correctly right now, but I want to be able to
at least feel like we can some day actually do printk's etc
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
which may have four entry-points that can be illogically mapped to the
suspend/resume ones like we do now, but they really have nothing to do
with suspending/resuming.
Apart from putting devices into the right low power states, that
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
In fact we have acpi_pci_choose_state() that tells the driver which power
state to put the device into in -suspend(). If that is used, the device ends
up in the state expected by to BIOS for S4.
First off, nobody should *ever* use that
On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
Secondly, the one that people should use (pci_choose_state()) doesn't
actually do what you claim it does. It does all kinds of wrong things, and
doesn't even take the target state into account at all. So look again.
Well, if
On Fri, 22 Feb 2008, Ingo Molnar wrote:
btw., why isnt there an in-kernel whitelist, with perhaps a dynamic,
convenient /debug/s2r/whitelist append-API for distros (and testers) to
add more entries to the whitelist/blacklist? (for cases where the kernel
whitelist has not caught up yet)
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
--- linux-2.6.orig/drivers/char/drm/i915_drv.c
+++ linux-2.6/drivers/char/drm/i915_drv.c
@@ -222,6 +222,7 @@ static void i915_restore_vga(struct drm_
dev_priv-saveGR[0x18]);
/* Attribute controller registers */
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
In the revised patch below I redefined the PM_EVENT_* things as flags so
that I can or them and defined PM_EVENT_SLEEP in analogy with
CONFIG_PM_SLEEP.
Ok, looks fine by me.
Didn't you miss the apci_pci_choose_state() thing that also needs
On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
Thanks for testing. Below is the final version of the patch with a changelog
etc.
Thanks, applied.
With this, I also find that I dislike the use of suspend/resume for
freezing for STD a lot less. It's still too easy to get confused, but at
77 matches
Mail list logo
