Having the checker check for this change isn't a solution...it
shouldn't prevent any data corruption. Even if you check prior to
every IO, you still have an obvious race between the check and the
subsequent IO. You gain the ability to recognise the problem and
somehow magically warn the user (eg:
Patrick Mansfield wrote:
On Sat, Jan 29, 2005 at 10:44:41AM -0600, James Bottomley wrote:
On Fri, 2005-01-28 at 21:46 -0800, Andrew Vasquez wrote:
Returning back DID_IMM_RETRY for these 'transport' related conditions
would of course help in this issue -- but at the same time bring with it
several s
On Wed, 2005-01-26 at 15:59 -0800, Mike Christie wrote:
> It appears there is a missing class_device_del.
> The comments for transport_remove_device indicate
> that transport_remove_classdev should call it
> (which the attached patch does), but the comment in
> attribute_container_remove_device:
O
On Sat, 2005-01-29 at 11:34 -0800, Patrick Mansfield wrote:
> But the transport hit a failure, not the storage device.
>
> I thought Andrew hit this sequence:
>
> - pull / replace cable
>
> - IO resumes but gets NOT_READY (the device could be logging back
> into the fibre or
All of the transport class patches contain a thinko in device matching
(and, unfortunately, one I exhorted everyone not to make in the generic
transport class comments): The match matches every container in the
class instead of the specific container belonging to the HBA. This
causes a oops when t
On Sat, Jan 29, 2005 at 10:44:41AM -0600, James Bottomley wrote:
> On Fri, 2005-01-28 at 21:46 -0800, Andrew Vasquez wrote:
> > Returning back DID_IMM_RETRY for these 'transport' related conditions
> > would of course help in this issue -- but at the same time bring with it
> > several side-effects
Am Samstag, 29. Januar 2005 15:46 schrieb James Bottomley:
> I wouldn't have noticed this at all since you didn't send it to the scsi
> list, but fortunately, Al Viro drew it politely to my attention as
> another example of SCSI refcounting problems.
Sorry, it happening in cdrom_release fooled me
On Fri, 2005-01-28 at 21:46 -0800, Andrew Vasquez wrote:
> Returning back DID_IMM_RETRY for these 'transport' related conditions
> would of course help in this issue -- but at the same time bring with it
> several side-effects which may not be desirable.
>
> So, beyond this particular circumstance
On Fri, Jan 28, 2005 at 09:46:06PM -0800, Andrew Vasquez wrote:
> On Fri, 2005-01-28 at 15:24 -0800, Andrew Vasquez wrote:
> > When the qla2xxx driver managed command queuing internally, a NOT_READY
> > status would cause the lun-queue to be frozen for some period time while
> > the storage settled
I wouldn't have noticed this at all since you didn't send it to the scsi
list, but fortunately, Al Viro drew it politely to my attention as
another example of SCSI refcounting problems.
The issue seems to be that we have a spurious scsi_cd_put() on the error
path of sr_open(). The sr_block_..() f
Patch 3:
This patch extends scsi_target support:
- Allows for driver-specific data to be allocated along with the
target structure and accessible via the starget->hostdata pointer.
- Adds scsi target alloc/configure/destory callbacks to the
scsi host template.
- Rearranges the cal
Patch 2:
Adds io statistics (requests, completions, error count) as generic
attributes for scsi devices.
-- James S
p2_iostats.patch
Description: p2_iostats.patch
Patch 1:
Updates the recent transport container patch for :
- allow device driver-specific attributes to be added to class objects
- exposes classdev to transport via setup function
-- James S
p1_xpt.patch
Description: p1_xpt.patch
The following 3 patches extend the scsi midlayer. Changes were prompted
by recent discussions with Christoph as part of the Emulex driver thread.
Patch 1:
Updates the recent transport container patch for :
- allow device driver-specific attributes to be added to class objects
- exposes cla
14 matches
Mail list logo