From: Len Brown <len.brown@intel.com>
To: Shaohua Li <shaohua.li@intel.com>
Cc: Nathan Bryant <nbryant@optonline.net>,
ACPI Developers <acpi-devel@lists.sourceforge.net>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Stefan D?singer <stefandoesinger@gmx.at>
Subject: RE: [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
Date: 03 Aug 2004 22:55:55 -0400 [thread overview]
Message-ID: <1091588154.2297.43.camel@dhcppc4> (raw)
In-Reply-To: <B44D37711ED29844BEA67908EAF36F037BB9C6@pdsmsx401.ccr.corp.intel.com>
Shaohua,
pci=noacpi and acpi=noirq are boot workarounds --
not full-featured supported configurations -- YMMV!
We don't even guarantee that the ACPI SCI
will work with these configurations.
So I think we should spend 0 effort to support ACPI suspend/resume
in configurations where ACPI is partially disabled.
Sorry if this contradicts what I said yesterday,
I think I wasn't thinking clearly then.
thanks,
-Len
On Tue, 2004-08-03 at 22:36, Li, Shaohua wrote:
> Nathan,
> I agree your patch should be ok for the special case, but it's not
> sufficient. Please note a Link device is just an abstraction of PCI
> router, which possibly is in ICH. If we use pci=noacpi or acpi=noirq, we
> don't use link device but still use the router and may also change the
> sets of the router (look at i386/pci/irq.c) and so still fail after S3.
> Your patch can't handle this situation. This indicates adding
> suspend/resume code in pci_link.c is not a good idea. Generic solution
> should be to provide LPC driver.
>
> Thanks,
> Shaohua
>
> >-----Original Message-----
> >From: Nathan Bryant [mailto:nbryant@optonline.net]
> >Sent: Wednesday, August 04, 2004 9:43 AM
> >To: Brown, Len
> >Cc: acpi-devel@lists.sourceforge.net; Linux Kernel list; Li, Shaohua;
> >Stefan D?singer
> >Subject: [PATCH][RFC] fix ACPI IRQ routing after S3 suspend
> >
> >
> >This patch should fix multiple user-visible problems with the ACPI IRQ
> >routing after S3 resume:
> >
> >"irq x: nobody cared"
> >"my interrupts are gone"
> >
> >It probably applies to multiple bugzilla entries and mailing list
> posts.
> >
> >Tested on my machine, which is experiencing similar problems. Seems to
> >work - although I get some non-fatal "nobody cared" messages that might
> >be caused by the i8042 driver.
> >
> >Comments?
> >Stefan, can you test this?
next prev parent reply other threads:[~2004-08-04 2:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-04 2:36 [PATCH][RFC] fix ACPI IRQ routing after S3 suspend Li, Shaohua
2004-08-04 2:55 ` Len Brown [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-08-04 1:42 Nathan Bryant
2004-08-04 2:59 ` Len Brown
2004-08-04 15:57 ` Nathan Bryant
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=1091588154.2297.43.camel@dhcppc4 \
--to=len.brown@intel.com \
--cc=acpi-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=nbryant@optonline.net \
--cc=shaohua.li@intel.com \
--cc=stefandoesinger@gmx.at \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox