Jens Axboe wrote:
> On Thu, Jan 04 2007, James Bottomley wrote:
>> On Thu, 2007-01-04 at 12:21 +0100, Jens Axboe wrote:
>>> I guess it's fully up to you how you want to solve it. The scheme seems
>>> a little elaborate, but these error conditions are unlikely to ever been
>>> seen in the wild, so n
-01-04 21:49:33.0
-0500
@@ -51,10 +51,10 @@
#include "scsi_logging.h"
#include "scsi_debug.h"
-#define SCSI_DEBUG_VERSION "1.80"
-static const char * scsi_debug_version_date = "20061018";
+#define SCSI_DEBUG_VERSION "1.81"
This patch makes the mptctl pass through available if
the mptsas driver is selected. Without this patch
if mptsas is the only fusion driver chosen, then
the mptctl is not presented as an option.
smp_utils uses the mptctl driver to pass SAS SMP
functions through a MPT SAS HBA.
I have discussed thi
On Thu, Jan 04, 2007 at 04:59:22PM -0800, Andrew Morton wrote:
> On Thu, 04 Jan 2007 19:06:46 -0500
> Justin Rosander <[EMAIL PROTECTED]> wrote:
>
> > Please forward this to the appropriate maintainer. Thank you.
> >
> > [1.] One line summary of the problem:My fibre channel drives fail to
>
bump version
Signed-off-by: Eric Moore <[EMAIL PROTECTED]>
diff -uarpN b/drivers/message/fusion/mptbase.h
a/drivers/message/fusion/mptbase.h
--- b/drivers/message/fusion/mptbase.h 2006-12-25 01:41:05.0 -0700
+++ a/drivers/message/fusion/mptbase.h 2006-12-25 01:45:41.0 -0700
@@
* Add modinfo driver version support.
* Change copyright year to 2007.
Signed-off-by: Eric Moore <[EMAIL PROTECTED]>
diff -uarpN b/drivers/message/fusion/mptbase.c
a/drivers/message/fusion/mptbase.c
--- b/drivers/message/fusion/mptbase.c 2006-12-23 21:00:32.0 -0700
+++ a/drivers/message
* Endian fix's for warnings found in ppc environment.
* Fix compile time warning when calling scsi_device_reprobe, where
in newer kernels this API expects its return value to be examined.
* Fix compile errors when debug messages are enabled.
Signed-off-by: Eric Moore <[EMAIL PROTECTED]>
diff -ua
Simialar to the previous bug fix, this patch avoids
inifinite retries. This is replicated in Vmware environment
when the guest OS is using the 53c1030 as a emulated storage controller.
This patch will restore original driver behavior for SPI from about
a year ago, though keeping same behavor for FC
A repost of a patch forwarded by Mikael Reed from 2006-12-20.
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
Hello Joe,
The mask value 0x1f is to mask out interrupts. The value in the
current kernel code is appropriate for all controllers that the driver
supports.
Are you seeing any specific issue in driver with this mask
value?
Regards,
Sumant
-Original Message-
Fr
The attached patch for scsi-misc-2.6 updates the 3ware 8000 driver:
- Free irq handler in __tw_shutdown().
- Turn on RCD bit for caching mode page.
- Serialize reset code.
Signed-off-by: Adam Radford <[EMAIL PROTECTED]>
James, Please apply
Thanks!
-Adam
Note: The patch is attached as an atta
On Thu, 04 Jan 2007 19:06:46 -0500
Justin Rosander <[EMAIL PROTECTED]> wrote:
> Please forward this to the appropriate maintainer. Thank you.
>
> [1.] One line summary of the problem:My fibre channel drives fail to
> be recognized by my LSIFC909 card.
Please send the output of `lspci -vn'
The SCSI_AMIGA7XX driver:
- has been marked as BROKEN for more than two years and
- is still marked as BROKEN.
Drivers that had been marked as BROKEN for such a long time seem to be
unlikely to be revived in the forseeable future.
But if anyone wants to ever revive this driver, the code is still
On Thu, Jan 04, 2007 at 06:46:32PM +0100, Adrian Bunk wrote:
> Subject: SPARC64: Can't mount / (CONFIG_SCSI_SCAN_ASYNC=y ?)
> References : http://lkml.org/lkml/2006/12/13/181
> http://lkml.org/lkml/2007/01/04/75
> Submitter : Horst H. von Brand <[EMAIL PROTECTED]>
> Status :
This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19
that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering
On Thu, Jan 04 2007, Mark Lord wrote:
> Jens Axboe wrote:
> >On Wed, Jan 03 2007, James Bottomley wrote:
> >>Er, well, as you know, I've never been a fan of this static list. I
> >>thought Jens was going to put us all out of our misery by making the
> >>list settable per device by root and thus sh
On Thu, Jan 04 2007, James Bottomley wrote:
> On Thu, 2007-01-04 at 12:21 +0100, Jens Axboe wrote:
> > I guess it's fully up to you how you want to solve it. The scheme seems
> > a little elaborate, but these error conditions are unlikely to ever been
> > seen in the wild, so no objections from me.
On Thu, 2007-01-04 at 08:27 -0700, Matthew Wilcox wrote:
> Any returning command, or a returning command from this device?
This device
> We may
> be out of memory from a different device, and this may be the only
> command being sent to the scsi_debug driver. Wouldn't we end up
> halting the d
Jens Axboe wrote:
On Wed, Jan 03 2007, James Bottomley wrote:
Er, well, as you know, I've never been a fan of this static list. I
thought Jens was going to put us all out of our misery by making the
list settable per device by root and thus shovel the problem off onto
the distros?
The code is
On Thu, Jan 04, 2007 at 09:10:01AM -0600, James Bottomley wrote:
> On Thu, 2007-01-04 at 12:21 +0100, Jens Axboe wrote:
> > I guess it's fully up to you how you want to solve it. The scheme seems
> > a little elaborate, but these error conditions are unlikely to ever been
> > seen in the wild, so n
On Thu, 2007-01-04 at 12:21 +0100, Jens Axboe wrote:
> I guess it's fully up to you how you want to solve it. The scheme seems
> a little elaborate, but these error conditions are unlikely to ever been
> seen in the wild, so no objections from me.
Actually, there's already a DID_ code that does wh
On Wed, Jan 03 2007, James Bottomley wrote:
> Er, well, as you know, I've never been a fan of this static list. I
> thought Jens was going to put us all out of our misery by making the
> list settable per device by root and thus shovel the problem off onto
> the distros?
The code is there, just h
On Thu, Jan 04 2007, Douglas Gilbert wrote:
> Jens Axboe wrote:
> > Hi Doug,
> >
> > resp_inquiry() does a GFP_KERNEL memory allocation, but it's not allowed
> > to from the queuecommand context. There's no good way to return this
> > error, so I used DID_ERROR which is used from similar paths. Th
23 matches
Mail list logo