From: [EMAIL PROTECTED]
Subject: bidi bsg is non-blocking
Date: Mon, 7 May 2007 10:21:18 -0500
> I'm attempting to use the bidi variant of bsg to talk to an OSD target
> device. I've run into an undesirable situation.
>
> My application has a free-running receive loop (doing a read() on the bsg
>
From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: Re: bidi bsg is non-blocking
Date: Tue, 08 May 2007 16:23:26 +0900
> From: [EMAIL PROTECTED]
> Subject: bidi bsg is non-blocking
> Date: Mon, 7 May 2007 10:21:18 -0500
>
> > I'm attempting to use the bidi variant of bsg to talk to an OSD target
>
From: Christof Schmitt <[EMAIL PROTECTED]>
S_ID and D_ID are defined in the FCP spec as 3 byte fields.
Change the output in zfcp print statements accordingly to print
them with only 3 bytes.
Signed-off-by: Christof Schmitt <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
From: Christof Schmitt <[EMAIL PROTECTED]>
There is a possible race condition while generating the unique
request ids and sequence numbers. Both might be read at the
same time and have the same value. Fix this by serializing the
access through the queue lock of the adapter: First call
zfcp_fsf_req
From: Christof Schmitt <[EMAIL PROTECTED]>
The SCSI stack requires low level drivers to register and
unregister devices. For zfcp this leads to the situation where
zfcp calls the SCSI stack, the SCSI tries to scan the new device
and the scan SCSI command fails. This would require the zfcp erp,
but
From: Heiko Carstens <[EMAIL PROTECTED]>
Simplify request ID management and make sure that frequently used
functions are inlined. Also fix a memory leak in zfcp_adapter_enqueue()
which only gets hit in error handling.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig
From: Heiko Carstens <[EMAIL PROTECTED]>
Must clear adapter failed flag if an fsf request times out. This is
necessary because on link down situations the failed flags gets set
but the QDIO queues are still up. Since an adapter reopen will be
skipped if the failed flag is set an adapter_reopen tha
From: Heiko Carstens <[EMAIL PROTECTED]>
The boxed flag for units was never cleared. This doesn't hurt, but on
ACL updates the error recovery could reopen more units than needed.
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
Signed-off-by: Swen Schillig <[EMAIL PROTECTED]>
---
drivers/s390/
On Tue, May 08 2007, FUJITA Tomonori wrote:
> > From: [EMAIL PROTECTED]
> > Subject: bidi bsg is non-blocking
> > Date: Mon, 7 May 2007 10:21:18 -0500
> >
> > > I'm attempting to use the bidi variant of bsg to talk to an OSD target
> > > device. I've run into an undesirable situation.
> > >
> > >
From: Jens Axboe <[EMAIL PROTECTED]>
Subject: Re: bidi bsg is non-blocking
Date: Tue, 8 May 2007 14:21:34 +0200
> On Tue, May 08 2007, FUJITA Tomonori wrote:
> > > From: [EMAIL PROTECTED]
> > > Subject: bidi bsg is non-blocking
> > > Date: Mon, 7 May 2007 10:21:18 -0500
> > >
> > > > I'm attempti
On Tue, May 08, 2007 at 01:56:07AM +1000, Julian Calaby wrote:
> >From: Christof Schmitt <[EMAIL PROTECTED]>
> [snip]
> >- ZFCP_LOG_NORMAL("bug: unexpected inbound "
> >- "packet on adapter %s "
> >-
On Tue, May 08 2007, FUJITA Tomonori wrote:
> BTW, any comments on the bidi patch for the block layer?
Yeah it looks much better. I agree with your notion that bidi should be
block layer agnostic at least for now (until a general use comes up),
it's just a way to transport these commands. And I do
This patch fixes a bug that read() returns ENODATA even with a
blocking file descriptor when there are no commands pending.
This also includes some cleanups.
Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
---
block/bsg.c | 84 --
1 fi
On 5/8/07, Christof Schmitt <[EMAIL PROTECTED]> wrote:
On Tue, May 08, 2007 at 01:56:07AM +1000, Julian Calaby wrote:
> >From: Christof Schmitt <[EMAIL PROTECTED]>
> [snip]
> >- ZFCP_LOG_NORMAL("bug: unexpected inbound "
> >-
From: Jens Axboe <[EMAIL PROTECTED]>
Subject: Re: bidi bsg is non-blocking
Date: Tue, 8 May 2007 15:00:32 +0200
> On Tue, May 08 2007, FUJITA Tomonori wrote:
> > BTW, any comments on the bidi patch for the block layer?
>
> Yeah it looks much better. I agree with your notion that bidi should be
>
On Tue, 2007-05-08 at 11:14 +0200, Swen Schillig wrote:
> From: Christof Schmitt <[EMAIL PROTECTED]>
>
> S_ID and D_ID are defined in the FCP spec as 3 byte fields.
> Change the output in zfcp print statements accordingly to print
> them with only 3 bytes.
For future reference, if you send out a
Curious why you are calling scsi_scan_target() or
scsi_target_block()/scsi_target_unblock() directly. I would have
thought the add/remove rport code would have done this for you,
and it deals with all the flush conditions, etc.
-- james
Swen Schillig wrote:
From: Christof Schmitt <[EMAIL PROTEC
On Mon, 2007-05-07 at 14:06 -0700, Andrew Morton wrote:
> On Mon, 07 May 2007 14:50:19 -0500
> James Bottomley <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2007-04-26 at 00:35 -0700, [EMAIL PROTECTED] wrote:
> > > From: Richard Knutsson <[EMAIL PROTECTED]>
> > >
> > > Convert:
> > > FALSE -> false
>
On Tue, May 08, 2007 at 11:00:11AM -0400, James Smart wrote:
> Curious why you are calling scsi_scan_target() or
> scsi_target_block()/scsi_target_unblock() directly. I would have
> thought the add/remove rport code would have done this for you,
> and it deals with all the flush conditions, etc.
f
Thanks! bsg now waits for a response.
Dan
FUJITA Tomonori
To
No Phone Info
The CD-ROM layer doesn't bounce requests for old ISA controllers (and
nor should it). However they get injected into the SCSI layer via
sr_ioctl which also doesn't bounce them and SCSI then passes the buffer
along to a device with unchecked_isa_dma set which either panics or
truncates the buffer to
On Tue, 8 May 2007 17:03:35 +0100
Alan Cox <[EMAIL PROTECTED]> wrote:
> The CD-ROM layer doesn't bounce requests for old ISA controllers (and
> nor should it). However they get injected into the SCSI layer via
> sr_ioctl which also doesn't bounce them and SCSI then passes the buffer
> along to a d
The CD-ROM layer doesn't bounce requests for old ISA controllers (and
nor should it). However they get injected into the SCSI layer via
sr_ioctl which also doesn't bounce them and SCSI then passes the buffer
along to a device with unchecked_isa_dma set which either panics or
truncates the buffer to
On Tue, May 08 2007, Alan Cox wrote:
> The CD-ROM layer doesn't bounce requests for old ISA controllers (and
> nor should it). However they get injected into the SCSI layer via
> sr_ioctl which also doesn't bounce them and SCSI then passes the buffer
> along to a device with unchecked_isa_dma set w
On Tue, 2007-05-08 at 18:14 +0200, Jens Axboe wrote:
> On Tue, May 08 2007, Alan Cox wrote:
> > The CD-ROM layer doesn't bounce requests for old ISA controllers (and
> > nor should it). However they get injected into the SCSI layer via
> > sr_ioctl which also doesn't bounce them and SCSI then passe
On Tue, May 08 2007, James Bottomley wrote:
> On Tue, 2007-05-08 at 18:14 +0200, Jens Axboe wrote:
> > On Tue, May 08 2007, Alan Cox wrote:
> > > The CD-ROM layer doesn't bounce requests for old ISA controllers (and
> > > nor should it). However they get injected into the SCSI layer via
> > > sr_io
James Bottomley wrote:
> On Tue, 2007-05-08 at 18:14 +0200, Jens Axboe wrote:
>> On Tue, May 08 2007, Alan Cox wrote:
>>> The CD-ROM layer doesn't bounce requests for old ISA controllers (and
>>> nor should it). However they get injected into the SCSI layer via
>>> sr_ioctl which also doesn't bounc
On Tue, 2007-05-08 at 18:40 +0200, Jens Axboe wrote:
> On Tue, May 08 2007, James Bottomley wrote:
> > On Tue, 2007-05-08 at 18:14 +0200, Jens Axboe wrote:
> > > On Tue, May 08 2007, Alan Cox wrote:
> > > > The CD-ROM layer doesn't bounce requests for old ISA controllers (and
> > > > nor should it)
On Tue, May 08 2007, Mike Christie wrote:
> James Bottomley wrote:
> > On Tue, 2007-05-08 at 18:14 +0200, Jens Axboe wrote:
> >> On Tue, May 08 2007, Alan Cox wrote:
> >>> The CD-ROM layer doesn't bounce requests for old ISA controllers (and
> >>> nor should it). However they get injected into the
On Thursday, April 26, 2007 1:35 AM, Dirk Mueller wrote:
>
> This patch corrects a |/|| confusion in
> mptscsih_copy_sense_data. Using ||
> means that the data that ends up being written is (almost always) 1,
> instead of being bit-wise or'ed.
>
> Cc: Eric Moore <[EMAIL PROTECTED]>
> Cc: James
On Tue, 2007-05-08 at 11:06 -0600, Moore, Eric wrote:
> On Thursday, April 26, 2007 1:35 AM, Dirk Mueller wrote:
>
> >
> > This patch corrects a |/|| confusion in
> > mptscsih_copy_sense_data. Using ||
> > means that the data that ends up being written is (almost always) 1,
> > instead of being
On Tue, May 08 2007, James Bottomley wrote:
> On Tue, 2007-05-08 at 18:40 +0200, Jens Axboe wrote:
> > On Tue, May 08 2007, James Bottomley wrote:
> > > On Tue, 2007-05-08 at 18:14 +0200, Jens Axboe wrote:
> > > > On Tue, May 08 2007, Alan Cox wrote:
> > > > > The CD-ROM layer doesn't bounce reques
> Mike Christie tells me we're missing bouncing by accident in the
> scsi_execute path (but not the scsi_execute_async path). He says this
> is the fix he proposed:
>
> http://marc.info/?l=linux-scsi&m=115981479822790&w=2
>
> Can we just merge this instead?
Short answer: No
Long answer - it do
On Tue, 2007-05-08 at 18:42 +0100, Alan Cox wrote:
> > Mike Christie tells me we're missing bouncing by accident in the
> > scsi_execute path (but not the scsi_execute_async path). He says this
> > is the fix he proposed:
> >
> > http://marc.info/?l=linux-scsi&m=115981479822790&w=2
> >
> > Can w
> > Long answer - it doesn't take this path.
> >
> > Different bug, both want fixing I suspect.
>
> Actually, it does take this path ... one of the things we've been doing
> in SCSI is slowly eliminating the old direct submission paths in favour
> of sending everything through the correct block l
On Tue, 2007-05-08 at 18:53 +0100, Alan Cox wrote:
> > The ultimate goal is to be able to eliminate the unchecked_isa_dma flag
> > entirely and have the block layer (or device mask allocations) fix all
> > of this in every ULD.
>
> About time ;)
Actually, I should point out (before those who did
Hi All,
This panic is related to the interactions between scsi/sg.c, iscsi
initiator and tcp on the RHEL 2.6.9-42 kernel. But we may also have the
similar problem with open-iscsi initiator. I will explain why we see the
Bad page panic first. I did a patch to the sg driver to workaround the
problem
FUJITA Tomonori wrote:
> Here is an updated version of the patch to add bidi support to block
> pc requests. Bugs spotted by Benny were fixed.
>
> This patch can be applied cleanly to the scsi-misc git tree and is on
> the top of the following patch to add linked request support:
>
> http://marc.
On Tue, 08 May 2007 10:11:00 -0500
James Bottomley <[EMAIL PROTECTED]> wrote:
> > That being said, the patch is moderately wrong (or at least incomplete)
> > because it does things like:
> >
> > -unsigned char done = FALSE;
> > +unsigned char done = false;
> >
> > whereas
On Tue, 2007-05-08 at 12:14 -0700, Andrew Morton wrote:
> On Tue, 08 May 2007 10:11:00 -0500
> James Bottomley <[EMAIL PROTECTED]> wrote:
>
> > > That being said, the patch is moderately wrong (or at least incomplete)
> > > because it does things like:
> > >
> > > -unsigned char done
Qi, Yanling wrote:
> Hi All,
>
> This panic is related to the interactions between scsi/sg.c, iscsi
> initiator and tcp on the RHEL 2.6.9-42 kernel. But we may also have the
> similar problem with open-iscsi initiator. I will explain why we see the
Yeah, this problem should occur in the upstream
On Tue, 2007-05-08 at 21:53 +0300, Boaz Harrosh wrote:
> Before I get to my main concern here I have one comment. in
> scsi_get_cmd_from_req()
> there is a code path in which a scsi_cmnd is taken from special and is not
> newly
> allocated. It is best to move bidi allocation to scsi_get_cmd_from_
On Tue, 08 May 2007 14:24:32 -0500
James Bottomley <[EMAIL PROTECTED]> wrote:
> However, could we compromise and just add TRUE = true, FALSE = false to
> the enum?
That sounds sane. But I don't recall all the details of the discussion
and perhaps I'm missing something.
I think the whole bool/tr
On Tue, 2007-05-08 at 13:11 -0700, Andrew Morton wrote:
> On Tue, 08 May 2007 14:24:32 -0500
> James Bottomley <[EMAIL PROTECTED]> wrote:
>
> > However, could we compromise and just add TRUE = true, FALSE = false to
> > the enum?
>
> That sounds sane. But I don't recall all the details of the di
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 8 May 2007 13:11:52 -0700
> On Tue, 08 May 2007 14:24:32 -0500
> James Bottomley <[EMAIL PROTECTED]> wrote:
>
> > However, could we compromise and just add TRUE = true, FALSE = false to
> > the enum?
>
> That sounds sane. But I don't recall all
On Tue, 2007-05-08 at 14:44 -0700, David Miller wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Tue, 8 May 2007 13:11:52 -0700
>
> > On Tue, 08 May 2007 14:24:32 -0500
> > James Bottomley <[EMAIL PROTECTED]> wrote:
> >
> > > However, could we compromise and just add TRUE = true, FALSE =
This should be the second half of the SCSI tree, mainly assorted driver
updates and fixes. The patch is available from:
master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
The short changelog is:
Adrian Bunk (1):
qla4xxx: possible cleanups
Amol Lad (1):
megaraid: rep
47 matches
Mail list logo
