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 have the
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 admin policy to
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. Debugging
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 in order...
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
(http://standards.ieee.org/regauth/oui/oui.txt). However, it does look
like
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 error recovery
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 -0700
@@ -443,6 +443,7
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:
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 between a host and target (names
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 which
receives DID_RESET
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 -0600
+++ rg61/include
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 block
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_STATUS_BUSY
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 i/o test
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
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 [EMAIL
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 to
20 matches
Mail list logo
