From: Pavel Machek <pavel@ucw.cz>
To: "Li, Shaohua" <shaohua.li@intel.com>
Cc: ncunningham@linuxmail.org,
Patrick Mochel <mochel@digitalimplant.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Fixing MTRR smp breakage and suspending sysdevs.
Date: Wed, 27 Oct 2004 12:00:46 +0200 [thread overview]
Message-ID: <20041027100046.GB26265@elf.ucw.cz> (raw)
In-Reply-To: <16A54BF5D6E14E4D916CE26C9AD30575699E58@pdsmsx402.ccr.corp.intel.com>
Hi!
> >One thing I have noticed is that by adding the sysdev suspend/resume
> >calls, I've gained a few seconds delay. I'll see if I can track down
> the
> >cause.
> Is the problem MTRR resume must be with IRQ enabled, right? Could we
> implement a method sysdev resume with IRQ enabled? MTRR driver isn't
> the
MTRR does not deserve to be sysdev. It is not essential for the
system, it only makes it slow.
> only case. The ACPI Link device is another case, it's a sysdev (it must
> resume before any PCI device resumed), but its resume (it uses semaphore
> and non-atomic kmalloc) can't invoked with IRQ enabled. I guess cpufreq
> driver is another case when suspend/resume SMP is supported.
I do not see how enabling interrupts before setting up IRQs is good
idea.
What about this one, instead?
* ACPI Link device should allocate with GFP_ATOMIC
* during suspend, locks can't be taken. (We stop userland, etc). So it
should be okay to down_trylock() and panic if that does not work.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
next prev parent reply other threads:[~2004-10-27 10:21 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-27 2:48 Fixing MTRR smp breakage and suspending sysdevs Li, Shaohua
2004-10-27 2:49 ` Nigel Cunningham
2004-10-27 3:20 ` Dmitry Torokhov
2004-10-27 3:17 ` Nigel Cunningham
2004-10-27 3:50 ` Dmitry Torokhov
2004-10-27 3:55 ` Nigel Cunningham
2004-10-27 10:00 ` Pavel Machek [this message]
2004-10-28 22:38 ` time and suspending sysdevs [was Re: Fixing MTRR smp breakage and suspending sysdevs.] Pavel Machek
2004-10-29 0:18 ` Nigel Cunningham
-- strict thread matches above, loose matches on Subject: below --
2004-10-29 1:41 Fixing MTRR smp breakage and suspending sysdevs Li, Shaohua
2004-10-28 2:40 Li, Shaohua
2004-10-28 1:54 Pallipadi, Venkatesh
2004-10-28 9:00 ` Pavel Machek
2004-10-27 12:23 Li, Shaohua
2004-10-28 10:20 ` Pavel Machek
2004-10-26 2:39 Nigel Cunningham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041027100046.GB26265@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
--cc=ncunningham@linuxmail.org \
--cc=shaohua.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.