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
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
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
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_..()
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,
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 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 which
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
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 such)
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:
OK,
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
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
12 matches
Mail list logo
