From: Bjorn Helgaas <bhelgaas@google.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Alan Stern <stern@rowland.harvard.edu>,
Igor Bezukh <Igor@galilsoft.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Linux PM list <linux-pm@vger.kernel.org>
Subject: Re: A question about PCI suspend-resume functionallity
Date: Thu, 10 Jul 2014 16:12:14 -0600 [thread overview]
Message-ID: <CAErSpo5hT6e1vevY+fCake6axEGQCSajtm02Faf_GBg9U652Xg@mail.gmail.com> (raw)
In-Reply-To: <3238200.k7ZdWYUy1n@vostro.rjw.lan>
On Thu, Jul 10, 2014 at 5:39 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Wednesday, July 09, 2014 01:24:20 PM Bjorn Helgaas wrote:
>> On Wed, Jul 9, 2014 at 10:35 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>> > On Wednesday, July 09, 2014 09:55:24 AM Bjorn Helgaas wrote:
>> >> On Wed, Jul 9, 2014 at 8:18 AM, Alan Stern <stern@rowland.harvard.edu> wrote:
>> >> > On Wed, 9 Jul 2014, Rafael J. Wysocki wrote:
>> >> >
>> >> >> On Tuesday, July 08, 2014 02:47:03 PM Bjorn Helgaas wrote:
>> >> >> > [+cc linux-pm]
>> >> >> >
>> >> >> > On Tue, Jul 8, 2014 at 9:39 AM, Igor Bezukh <Igor@galilsoft.com> wrote:
>> >> >> > > Hi,
>> >> >> > >
>> >> >> > >
>> >> >> > > We are testing Intel Gigabit adapter driver (igb) under Fedora 20, kernel 3.14.4 for the following use-case:
>> >> >> > >
>> >> >> > > (*) Adapter is connected to the PCIE slot
>> >> >> > > (*) We put the system under suspend by running pm-suspend from user-space
>> >> >> > > (*) Remove the adapter from the PCIE slot
>> >> >> > > (*) Wake up the system
>> >> >> > >
>> >> >> > > Currenlty, we got kernel panics and the system got stuck.
>> >> >> > >
>> >> >> > > My question is - does the PCI subsystem logic calls the driver remove function when driver resume function returns with error code?
>> >> >> > >
>> >> >> > > Or should I implement the call to igb_remove from igb_resume in the Intel driver?
>> >>
>> >> >> ...
>> >> >> The driver's system resume callbacks need to be able to cope with
>> >> >> missing devices.
>> >>
>> >> Based on this, it sounds like igb_resume() should call igb_remove()
>> >> when it figures out the device is missing.
>> >
>> > I wouldn't say so. igb_resume() should not crash when the device is missing
>> > and should just handle that situation cleanly. Obviously it is not its role
>> > to remove the device from the hierarchy.
>>
>> OK, that makes sense.
>>
>> However, I don't know of anything in the PCI core that will notice
>> that the device has disappeared, so I doubt it will be removed from
>> the hierarchy.
>
> If we don't get a notification via ACPI or PCIe hotplug or anything,
> then no, it won't be removed automatically.
>
> However, it still can be removed manually via sysfs, can't it?
Yes, I would think so. So I guess there's a workaround at least.
Igor, can you test this scenario (after fixing igb_resume() so it
doesn't crash when the device is missing)? I.e., suspend the system,
remove the adapter, resume the system, then do an "lspci" to see if
the kernel thinks the adapter is still there, then put an adapter in
the slot again (either hot-add if the the slot supports it, or
suspend/add/resume)?
Bjorn
next prev parent reply other threads:[~2014-07-10 22:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1404833913010.27399@galilsoft.com>
2014-07-08 20:47 ` A question about PCI suspend-resume functionallity Bjorn Helgaas
2014-07-08 22:05 ` Rafael J. Wysocki
2014-07-09 14:18 ` Alan Stern
2014-07-09 15:55 ` Bjorn Helgaas
2014-07-09 16:26 ` Alan Stern
2014-07-09 16:35 ` Rafael J. Wysocki
2014-07-09 19:24 ` Bjorn Helgaas
2014-07-10 11:39 ` Rafael J. Wysocki
2014-07-10 22:12 ` Bjorn Helgaas [this message]
2014-07-11 7:53 ` Igor Bezukh
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=CAErSpo5hT6e1vevY+fCake6axEGQCSajtm02Faf_GBg9U652Xg@mail.gmail.com \
--to=bhelgaas@google.com \
--cc=Igor@galilsoft.com \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=stern@rowland.harvard.edu \
/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;
as well as URLs for NNTP newsgroup(s).