On Mon, Oct 29, 2012, Jonathan Nieder wrote:
> In June, adam radford wrote:
>> On Thu, Jun 28, 2012 at 1:27 PM, Jonathan Nieder wrote:
>>> If someone makes a backport of the patches marked [3] as well, would
>>> you be able to look over or test the combination? That would be much
>>> appreciated
In iscsi_free_task, NULL is assigned to task->sc twice: before and
after kfifo_in invocatoin. Allocating and freeing iscsi_task are guarded
with session->lock, so multiple NULL assignments cause no trouble. But
people reading the source code may be confused.
The second NULL assignment comes from c
The commits
3c6bdaeab4fd "[SCSI] Add a report opcode helper"
5db44863b6eb "[SCSI] sd: Implement support for WRITE SAME"
introduced in-kernel uses of the mentioned commands but cautiously
blacklisted for any IEEE 1394 (SBP-2/3) targets and some other
transports.
I looked through a range of
On Monday, November 19, 2012 03:06:51 PM James Bottomley wrote:
> On Mon, 2012-11-19 at 06:56 -0800, Tejun Heo wrote:
> > Hey, Aaron.
> >
> > On Mon, Nov 19, 2012 at 11:09:40AM +0800, Aaron Lu wrote:
> > > > What I'm confused about is what autopm does for devices w/o zpodd.
> > > > What happens th
On 11/26/2012 08:33 AM, Rafael J. Wysocki wrote:
> On Monday, November 19, 2012 03:06:51 PM James Bottomley wrote:
>> On Mon, 2012-11-19 at 06:56 -0800, Tejun Heo wrote:
>>> Hey, Aaron.
>>>
>>> On Mon, Nov 19, 2012 at 11:09:40AM +0800, Aaron Lu wrote:
> What I'm confused about is what autopm do
On Tuesday, November 20, 2012 04:59:57 PM Aaron Lu wrote:
> On 11/20/2012 02:00 PM, Aaron Lu wrote:
> > On 11/19/2012 10:56 PM, Tejun Heo wrote:
> >> I really think we need a way for (auto)pm and event polling to talk to
> >> each other so that autopm can tell event poll to sod off while pm is
> >>
On 11/26/2012 08:50 AM, Rafael J. Wysocki wrote:
> On Tuesday, November 20, 2012 04:59:57 PM Aaron Lu wrote:
>> On 11/20/2012 02:00 PM, Aaron Lu wrote:
>>> On 11/19/2012 10:56 PM, Tejun Heo wrote:
I really think we need a way for (auto)pm and event polling to talk to
each other so that au
On Monday, November 26, 2012 08:48:51 AM Aaron Lu wrote:
> On 11/26/2012 08:50 AM, Rafael J. Wysocki wrote:
> > On Tuesday, November 20, 2012 04:59:57 PM Aaron Lu wrote:
> >> On 11/20/2012 02:00 PM, Aaron Lu wrote:
> >>> On 11/19/2012 10:56 PM, Tejun Heo wrote:
> I really think we need a way f
On 11/26/2012 09:03 AM, Rafael J. Wysocki wrote:
> On Monday, November 26, 2012 08:48:51 AM Aaron Lu wrote:
>> On 11/26/2012 08:50 AM, Rafael J. Wysocki wrote:
>>> On Tuesday, November 20, 2012 04:59:57 PM Aaron Lu wrote:
On 11/20/2012 02:00 PM, Aaron Lu wrote:
> On 11/19/2012 10:56 PM, Te
On Monday, November 26, 2012 09:05:58 AM Aaron Lu wrote:
> On 11/26/2012 09:03 AM, Rafael J. Wysocki wrote:
> > On Monday, November 26, 2012 08:48:51 AM Aaron Lu wrote:
> >> On 11/26/2012 08:50 AM, Rafael J. Wysocki wrote:
> >>> On Tuesday, November 20, 2012 04:59:57 PM Aaron Lu wrote:
> On 11
On 11/26/2012 09:11 AM, Rafael J. Wysocki wrote:
> On Monday, November 26, 2012 09:05:58 AM Aaron Lu wrote:
>> On 11/26/2012 09:03 AM, Rafael J. Wysocki wrote:
>>> On Monday, November 26, 2012 08:48:51 AM Aaron Lu wrote:
On 11/26/2012 08:50 AM, Rafael J. Wysocki wrote:
> On Tuesday, Novemb
On 11/26/2012 09:11 AM, Rafael J. Wysocki wrote:
> On Monday, November 26, 2012 09:05:58 AM Aaron Lu wrote:
>> On 11/26/2012 09:03 AM, Rafael J. Wysocki wrote:
>>> On Monday, November 26, 2012 08:48:51 AM Aaron Lu wrote:
On 11/26/2012 08:50 AM, Rafael J. Wysocki wrote:
> On Tuesday, Novemb
On Monday, November 26, 2012 09:09:36 AM Aaron Lu wrote:
> On 11/26/2012 09:11 AM, Rafael J. Wysocki wrote:
> > On Monday, November 26, 2012 09:05:58 AM Aaron Lu wrote:
> >> On 11/26/2012 09:03 AM, Rafael J. Wysocki wrote:
> >>> On Monday, November 26, 2012 08:48:51 AM Aaron Lu wrote:
> On 11/
On 11/26/2012 09:22 AM, Rafael J. Wysocki wrote:
> On Monday, November 26, 2012 09:09:36 AM Aaron Lu wrote:
>> On 11/26/2012 09:11 AM, Rafael J. Wysocki wrote:
>>> On Monday, November 26, 2012 09:05:58 AM Aaron Lu wrote:
On 11/26/2012 09:03 AM, Rafael J. Wysocki wrote:
> On Monday, Novembe
On Fri, 2012-11-23 at 16:07 +0100, Bart Van Assche wrote:
> On 09/27/12 02:31, David Dillow wrote:
> > On Tue, 2012-09-25 at 17:05 +0200, Bart Van Assche wrote:
> >> On 08/09/12 17:41, Bart Van Assche wrote:
> >>> [ ... ]
> >>
> >> Hello Dave,
> >>
> >> More than six weeks have elapsed since I post
From: Bart Van Assche
Some SCSI upper layer drivers, e.g. sd, issue SCSI commands from
inside scsi_remove_host() (see also the sd_shutdown() call in
sd_remove()). Make sure that these commands have a chance to reach
the SCSI device.
Signed-off-by: Bart Van Assche
[ adapted to new state tracking
From: Vu Pham
From: Vu Pham
Now that SRP recreates the CM id, QP, and CQ for each connection,
there is no need to wait for the timewait state to complete.
Signed-off-by: Vu Pham
Signed-off-by: David Dillow
---
drivers/infiniband/ulp/srp/ib_srp.c |3 ---
1 files changed, 0 insertions(+),
Once we know we have an issue with the QP, there is no point trying to
send anything else down the pipe. This also allows us to consolidate
code in the SCSI EH path.
Needs-to-be-signed-off-by: Bart Van Assche
[ adapted to new state tracking code ]
Signed-off-by: David Dillow
---
drivers/infinib
From: Ishai Rabinovitz
HW QP FATAL errors persist over a reset operation, but we can recover
from that by recreating the QP and associated CQs for each connection.
Creating a new QP/CQ also completely forecloses any possibility of
getting stale completions or packets on the new connection.
Signe
Here is a first, UNTESTED, pass at preparing a merge of Bart's SRP HA
work to upstream. It is not complete, as I have not yet added the
transport layer error handling and related patches. It is also currently
missing the patch to maintain a single connection for an I_T nexus.
I swapped Ishai's cod
From: David Dillow
Eliminate the private_rport_attrs[] array and the SETUP_*() macros
used to set up that array since the information in that array
duplicates the information in the static device attributes. Also,
verify whether SRP_RPORT_ATTRS is large enough since it is easy
to forget to update
From: Bart Van Assche
Make it possible to disconnect the IB RC connection used by the
SRP protocol to communicate with a target.
Let the SRP transport layer create a sysfs "delete" attribute for
initiator drivers that support this functionality.
Cc: FUJITA Tomonori
Cc: Robert Jennings
Signed-
From: Bart Van Assche
Enlarge the block layer timeout for disks such that it is above
the InfiniBand transport layer timeout.
Signed-off-by: Bart Van Assche
Signed-off-by: David Dillow
---
drivers/infiniband/ulp/srp/ib_srp.c | 45 +++
drivers/infiniband/ulp/s
From: Bart Van Assche
Register transport attributes after the attribute array has been
set up instead of before. The current code can trigger a race
condition because the code reading the attribute array can run
on another thread than the code that initialized that array.
Make sure that any code
From: Bart Van Assche
Document the sysfs attributes of the SRP initiator according
to the rules specified in Documentation/ABI/README.
Signed-off-by: Bart Van Assche
Signed-off-by: David Dillow
---
Documentation/ABI/stable/sysfs-driver-ib_srp | 156 ++
1 files changed
The state of the target has several conditions that overlap, making it
easier to model as a bit-field of exceptional conditions rather than an
enum of all possible states.
Bart Van Assche did the hard work of identifying the states that can be
removed, and did a first patch that consolidated the s
From: Bart Van Assche
Cc: FUJITA Tomonori
Cc: Robert Jennings
Signed-off-by: Bart Van Assche
Signed-off-by: David Dillow
---
Documentation/ABI/stable/sysfs-transport-srp | 12
1 files changed, 12 insertions(+), 0 deletions(-)
create mode 100644 Documentation/ABI/stable/sysfs-
On Sun, 2012-11-25 at 23:44 -0500, David Dillow wrote:
> From: David Dillow
> From: Bart Van Assche
>
> Eliminate the private_rport_attrs[] array and the SETUP_*() macros
> used to set up that array since the information in that array
> duplicates the information in the static device attributes
On Mon, 2012-11-26 at 01:33 +0100, Rafael J. Wysocki wrote:
> On Monday, November 19, 2012 03:06:51 PM James Bottomley wrote:
> > > I really think we need a way for (auto)pm and event polling to talk to
> > > each other so that autopm can tell event poll to sod off while pm is
> > > in effect. Try
On 11/26/2012 01:03 PM, James Bottomley wrote:
> On Mon, 2012-11-26 at 01:33 +0100, Rafael J. Wysocki wrote:
>> On Monday, November 19, 2012 03:06:51 PM James Bottomley wrote:
I really think we need a way for (auto)pm and event polling to talk to
each other so that autopm can tell event p
On Mon, 2012-11-26 at 13:09 +0800, Aaron Lu wrote:
> On 11/26/2012 01:03 PM, James Bottomley wrote:
> > On Mon, 2012-11-26 at 01:33 +0100, Rafael J. Wysocki wrote:
> >> On Monday, November 19, 2012 03:06:51 PM James Bottomley wrote:
> I really think we need a way for (auto)pm and event polling
On Mon, Nov 26, 2012 at 6:44 AM, David Dillow wrote:
> One may also pull this series from github:
> git pull git://github.com/dillow/srp-initiator.git ha-merge-v1
Hi Dave,
The kernel maintainers file specifies the following tree
git://git.kernel.org/pub/scm/linux/kernel/git/dad/srp-initi
32 matches
Mail list logo
