From: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: How does Linux handle PCI-E Surprise unplug?
Date: Mon, 08 Mar 2010 08:24:27 +0000 [thread overview]
Message-ID: <4B94B43B.7060202@jp.fujitsu.com> (raw)
In-Reply-To: <8506939B503B404A84BBB12293FC45F606B883BA@emailbng3.jnpr.net>
Rajat Jain wrote:
> Hello Greg / All,
>
> Replying on this thread as I have a small query left regarding this...
>
>> -----Original Message-----
>> From: Greg KH [mailto:greg@kroah.com]
>> Sent: Thursday, February 18, 2010 8:23 PM
>> To: Rajat Jain
>> Cc: linux-hotplug@vger.kernel.org; linux-pci@vger.kernel.org
>> Subject: Re: How does Linux handle PCI-E Surprise unplug?
>>
>> On Thu, Feb 18, 2010 at 11:35:33AM +0530, Rajat Jain wrote:
>>> Hi,
>>>
>>> I'm keen to understand how the Linux kernel handles surprise removal
> of
>>> a device, from a PCI-e slot that supports "Hot-plug Surprise"
> removal
>>> (in slot capabilities).
>>>
>>> Consider that the device in the slot is working normally, with its
>>> driver attached to the device, and is doing all sorts of read /
> write
>>> operations on the device registers that have been mapped into the
> PCI
>>> memory space. Now when that device is suddenly plugged out (and thus
> its
>>> registers suddenly disappear from the PCI memory space), the device
>>> driver is still unaware as it is doing the register reads / writes
> on
>>> the device. At this point, IMHO any attempt to access the device
>>> registers will result in an exception (BUS error?) as the device is
>>> gone. Correct?
>> The driver will suddenly start reading all 0xff and will then need to
>> abort whatever it was doing. Usually all drivers handle this just
> fine
>> today, as this is what they needed to do when they were pccard
> devices.
>> Nothing new here at all.
>>
>
> Does that mean accessing PCI memory mapped registers for a non-existent
> device has effects that are localized ONLY to the driver of that device?
> In other words, kernel does not notice or does not even become AWARE
> that a driver is trying to access non-existent memory mapped registers?
>
> So trying to access a HW that does not exist is totally legal in that
> sense? Is HW NOT supposed to generate an error in this case - as far as
> I had read, any access to non existent physical addresses should result
> in a bus error ... no?
This will cause Unsupported Request Error. But how it is handled
depends on platform, I think.
Thanks,
Kenji Kaneshige
next prev parent reply other threads:[~2010-03-08 8:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-18 6:17 How does Linux handle PCI-E Surprise unplug? Rajat Jain
2010-02-18 14:52 ` Greg KH
2010-02-19 4:13 ` Rajat Jain
2010-02-19 4:27 ` Greg KH
2010-02-19 6:41 ` Hidetoshi Seto
2010-03-08 7:23 ` Rajat Jain
2010-03-08 8:24 ` Kenji Kaneshige [this message]
2010-03-08 22:49 ` Grant Grundler
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=4B94B43B.7060202@jp.fujitsu.com \
--to=kaneshige.kenji@jp.fujitsu.com \
--cc=linux-hotplug@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;
as well as URLs for NNTP newsgroup(s).