From: Kevin Fenzi <kevin-linux-kernel@scrye.com>
To: linux-kernel@vger.kernel.org
Subject: Re: FYI: my current bigdiff
Date: Sat, 11 Sep 2004 12:55:12 -0600 [thread overview]
Message-ID: <20040911185514.D4C524E016@voldemort.scrye.com> (raw)
In-Reply-To: <41432AD4.2090003@suse.de>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Stefan" == Stefan Seyfried <seife@suse.de> writes:
Stefan> Bjorn Helgaas wrote:
>> I'm completely ignorant about how swsusp works; I guess this is my
>> chance to learn. "pci=routeirq" just causes us to do all the PCI
>> ACPI IRQ routing at boot-time, before the drivers start up. This
>> happens in pci_acpi_init(), which is a subsys_initcall that is run
>> at initial boot-time, but (I assume) not during a resume.
Stefan> a resume is basically a fresh boot, including hardware
Stefan> initialization by the compiled-in drivers (but not modules)
Stefan> but before starting init / entering initrd, the old system
Stefan> state is read from swap, copied back and somehow we continue
Stefan> where we left off at suspend time. Now the resume methods of
Stefan> all device drivers are called, processes are restarted and we
Stefan> are back in the game. (At least this is how i understood it
Stefan> all :-)
Stefan> I can easily imagine that a driver with a slightly broken
Stefan> suspend / resume method may fail without pci=routeirq if it
Stefan> does not do the irq routing correctly during resume. It may
Stefan> work with pci=routeirq since then everything is prepared for
Stefan> it before the resume actually happens.
Yeah, that seems to be the case... the prism54 and usb-hcd drivers
might expect the irq to already be allocated, and when it's not on
resume they freak out.
Stefan> Kevin may get away with unloading the usb host controller and
Stefan> the prism54 drivers before suspend and reloading them after
Stefan> resume.
alas, no.
Unloading and reloading doesn't help.
It looks like they don't re-allocate their irq resources on reload, so
they freak out.
See the dmesg output I just posted showing the issue.
kevin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFBQ0oS3imCezTjY0ERAsMoAJ0dtIycXmMd82WZNMNlHzbDj8/mDwCbBALz
USBJwZfMKB9W+GA3sVZQHgk=
=j0ZJ
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2004-09-11 18:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-09 13:44 Pavel Machek
2004-09-10 4:13 ` Kevin Fenzi
2004-09-10 9:44 ` Pavel Machek
2004-09-10 17:27 ` Kevin Fenzi
2004-09-10 22:46 ` Bjorn Helgaas
2004-09-11 16:41 ` Stefan Seyfried
2004-09-11 18:55 ` Kevin Fenzi [this message]
2004-09-11 18:50 ` Kevin Fenzi
2004-09-13 22:06 ` Bjorn Helgaas
2004-09-12 8:54 ` Stefan Schweizer
2004-09-12 9:23 ` Stefan Seyfried
2004-09-12 9:32 ` Stefan Schweizer
2004-09-12 11:39 ` Stefan Seyfried
2004-09-12 21:03 ` Pavel Machek
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=20040911185514.D4C524E016@voldemort.scrye.com \
--to=kevin-linux-kernel@scrye.com \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®