unsubscribe linux-scsi
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
We're seeing an occasional panic in sg_add() when class_device_create()
fails. It's obvious in the code that it uses the pointer to sg_class_member
even though it's invalid. We do see the "class_device_create failed" message.
class_set_devdata(cl_dev, sdp);
error = cdev_add(cdev,
David Miller wrote:
> From: James Bottomley <[EMAIL PROTECTED]>
> Date: Sat, 06 Oct 2007 10:04:55 -0500
>
>> If you remember Rusty's guide to interfaces, this is a level 14 easy to
>> misuse interface: "The obvious use is wrong"; since the obvious use is
>> to put it in module parameters and hav
Jeff Garzik wrote:
> Luben Tuikov wrote:
>> Do you mean:
>> "The admin will have the option to SPECIFY(SET) a WWN, should they
>> sodesire."
>> OR do you mean:
>> "The admin will have the option to HAVE THE KERNEL auto-generate a WWN,
>>should they so desire."
>
> Both. It is up to
Michael Reed wrote:
>
> Matthew Wilcox wrote:
>> On Thu, Sep 27, 2007 at 09:16:13AM -0500, [EMAIL PROTECTED] wrote:
>>>> Unfortunately, it looks like IEEE doesn't have any OID's registered for
>>>> Linux or other reserved areas
>>>> (h
Matthew Wilcox wrote:
> On Thu, Sep 27, 2007 at 09:16:13AM -0500, [EMAIL PROTECTED] wrote:
>> > Unfortunately, it looks like IEEE doesn't have any OID's registered for
>> > Linux or other reserved areas
>> > (http://standards.ieee.org/regauth/oui/oui.txt). However, it does look
>> > like they go
Jeff Garzik wrote:
> James Smart wrote:
>> Uh, although this may work very well for small constrained configs, as one
>> who debugs larger environments (and things always grow or get connected in
>> ways you don't expect), depending on a random number for uniqueness makes
>> me very unsettled. De
Jeff Garzik wrote:
> Is there an accepted way to generate a SAS address, when the adapter
> does not supply one (NVRAM invalid or missing, etc.)?
>
> Unless somebody complains, I was just planning to use
I'm not complaining. I'm circulating this for discussion with our
SAS hardware provider an
Jeff Garzik wrote:
> Moore, Eric wrote:
>> On Tuesday, September 25, 2007 11:32 AM, James Bottomley wrote:
>>
Youve rejected the error recovery patchs, which is fair enough.
>>> Just the separation ... the actual patch looks OK.
>>>
>>
>> I'll will continue working to separate the "erro
s without a BUSY status.
This patch applies to 2.6.23-rc6-git7.
Signed-off-by: Michael Reed <[EMAIL PROTECTED]>
--- linux-2.6.23-rc6-git7.orig/drivers/scsi/scsi_lib.c 2007-09-17 14:02:03.0 -0700
+++ linux-2.6.23-rc6-git7/drivers/scsi/scsi_lib.c 2007-09-17 14:05:51.0
While you didn't explicitly mention which distro you're using, some already
have udev in their initrd. If this applies in your case, you should be able
to change the root= parameter passed to the kernel to specify your root device
via a persistent name. For example:
root=/dev/disk/by-pat
Limit lifetime of scsi commands receiving DID_RESET status.
Signed-off-by: Michael Reed <[EMAIL PROTECTED]>
Limit lifetime of scsi commands receiving DID_RESET status.
Signed-off-by: Michael Reed <[EMAIL PROTECTED]>
--- rg61u/include/scsi/scsi.h 2006-10-31 21:08:47.0 -0
retaining it's original jiffies_at_alloc.
Signed-off-by: Michael Reed <[EMAIL PROTECTED]>
Move scsi_release_buffers() call so that buffers are retained until
after a determination is made about whether the command will be
requeued via scsi_queue_insert(). Doing so allows a command whi
ere tested by modifying a LLDD to return DID_RESET for
every command received.
Patches apply to 2.6.20-rc6-git1.
Signed-off-by: Michael Reed <[EMAIL PROTECTED]>
Christoph Hellwig wrote:
> On Mon, Dec 11, 2006 at 03:42:34PM -0600, Michael Reed wrote:
>> Due to a firmware mismatch
How 'bout a comment in scsh_host.h indicating that the pointer will be NULL
unless
initialized by the driver?
"Protect shared block queue tag" is unique to stex. Perhaps have no comment on
the variable declaration in scsi_host.h and explain why you use it in stex.
Mike
Ed Lin wrote:
> The blo
/O to dead device
(huge numbers of these occur)
I tried the same test using O_FSYNC instead of O_DIRECT and the write error
following the portdisable propagated to the test and it exited with an EIO.
Mike
Michael Reed wrote:
> Testing using 2.6.20-rc3-git4 I observed that my direct
Moore, Eric wrote:
> On Monday, January 08, 2007 3:25 PM, James Bottomley wrote:
>
>> Right, I sort of suspected something like this. BUSY/QUEUE_FULL
>> handling was a bit iffy in 2.4; but it was sorted out in the 2003/4
>> timeframe. Nowadays, I think you want to translate the
>> MPI_SCSI_ST
Testing using 2.6.20-rc3-git4 I observed that my direct i/o test
application no longer receives an EIO when the fc transport deletes
a target following a fibre channel switch port disable.
With 2.6.19 EIO is returned and the application terminates.
With 2.6.20, the requested read length is return
The fibre channel IOC may kill a request for a variety of
reasons, some of which may be recovered by a retry, some of
which are unlikely to be recovered. Return DID_ERROR
instead of DID_RESET to permit retry of the command,
just not an infinite number of them.
Signed-off-by: Michael Reed <[EM
Due to a firmware mismatch between a host and target (names withheld to
protect the innocent?), the LLDD was returning DID_RESET for every
i/o command. This patch modifies the scsi layer to take into account
when the command which received DID_RESET was issued and eventually
give up on it instead
Luben Tuikov wrote:
...snip...
> This statement in scsi_io_completion() causes the infinite retry loop:
>if (scsi_end_request(cmd, 1, good_bytes, !!result) == NULL)
> return;
The code in 2.6.19 is "result==0", not "!!result", which is logically
the same as "result!=0". Did you mean
21 matches
Mail list logo