From: Matthew Wilcox <matthew@wil.cx>
To: Brian King <brking@us.ibm.com>
Cc: linux-pci@atrey.karlin.mff.cuni.cz, linux-pm@lists.osdl.org,
linux-kernel@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Greg KH <greg@kroah.com>, Adam Belay <abelay@MIT.EDU>
Subject: Re: [PATCH] Block on access to temporarily unavailable pci device
Date: Wed, 18 Oct 2006 08:57:22 -0600 [thread overview]
Message-ID: <20061018145722.GP22289@parisc-linux.org> (raw)
In-Reply-To: <20061018145104.GN22289@parisc-linux.org>
On Wed, Oct 18, 2006 at 08:51:04AM -0600, Matthew Wilcox wrote:
> This reimplementation uses a global wait queue and a bit per device.
> I've open-coded prepare_to_wait() / finish_wait() as I could optimise
> it significantly by knowing that the pci_lock protected us at all points.
I forgot to report how I've tested it. Using the 'test' patch from
yesterday, I have two processes running lspci in an infinite loop. When
I write a 1 to /sys/bus/pci/devices/0000\:00\:01.0/block, they both
halt. When I write a 0, they both resume.
Then I tried doing echo 0 >/sys/bus/pci/devices/0000\:00\:01.0/block a
second time, and I got the WARNing I expected.
animal:~# echo 1 >/sys/bus/pci/devices/0000\:00\:01.0/block
animal:~# echo 1 >/sys/bus/pci/devices/0000\:00\:01.0/block
animal:~# echo 0 >/sys/bus/pci/devices/0000\:00\:01.0/block
They both resumed (as expected; we don't support nesting).
animal:~# echo 1 >/sys/bus/pci/devices/0000\:00\:01.0/block
animal:~# echo 1 >/sys/bus/pci/devices/0000\:00\:01.1/block
animal:~# echo 0 >/sys/bus/pci/devices/0000\:00\:01.0/block
animal:~# echo 0 >/sys/bus/pci/devices/0000\:00\:01.1/block
Both resumed only after the second echo 0 (as lspci reads all devices
before printing anything).
It's not exactly rigorous testing, but I couldn't think of any other
cases to try.
next prev parent reply other threads:[~2006-10-18 14:57 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-17 14:51 [PATCH] Block on access to temporarily unavailable pci device Matthew Wilcox
2006-10-17 14:54 ` Matthew Wilcox
2006-10-17 21:25 ` Brian King
2006-10-18 14:38 ` [linux-pm] " Alan Stern
2006-10-18 14:51 ` Matthew Wilcox
2006-10-18 15:52 ` Alan Stern
2006-10-18 16:05 ` Alan Cox
2006-10-18 16:09 ` Matthew Wilcox
2006-10-18 16:42 ` Alan Cox
2006-10-18 14:51 ` Matthew Wilcox
2006-10-18 14:57 ` Matthew Wilcox [this message]
2006-10-18 15:12 ` Nick Piggin
2006-10-18 15:16 ` Matthew Wilcox
2006-10-18 15:27 ` Nick Piggin
2006-10-18 15:50 ` Alan Cox
2006-10-18 16:20 ` Matthew Wilcox
2006-10-18 16:39 ` Alan Cox
2006-10-18 17:14 ` Matthew Wilcox
2006-10-19 15:41 ` [PATCH] Block on access to temporarily unavailable pci device [version 3] Matthew Wilcox
2006-10-19 16:32 ` Alan Cox
2006-10-19 23:13 ` Adam Belay
2006-10-19 23:51 ` Greg KH
2006-10-20 21:50 ` Brian King
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=20061018145722.GP22289@parisc-linux.org \
--to=matthew@wil.cx \
--cc=abelay@MIT.EDU \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=brking@us.ibm.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=linux-pm@lists.osdl.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