Martin J. Bligh [EMAIL PROTECTED] wrote:
If you look on http://test.kernel.org/, you'll see in the rightmost
column there's a yellow box under elm3b70 for 2.6.13-rc4-mm1, but
current mainline kernels are all green (ie no problems). That means
one test failed, in this case making an fs on the
On Thu, Aug 04 2005, Andrew Vasquez wrote:
All,
While adding support for the new change_queue_depth/type() callbacks,
static int
qla2x00_change_queue_depth(struct scsi_device *sdev, int qdepth)
{
scsi_adjust_queue_depth(sdev, scsi_get_tag_type(sdev),
unsubscribe linux-scsi
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, Andrew. Hello, Jens.
On Fri, Aug 05, 2005 at 09:57:52AM +0200, Jens Axboe wrote:
On Thu, Aug 04 2005, Andrew Vasquez wrote:
All,
While adding support for the new change_queue_depth/type() callbacks,
static int
qla2x00_change_queue_depth(struct scsi_device *sdev,
Tejun Heo wrote:
Hello, Andrew. Hello, Jens.
On Fri, Aug 05, 2005 at 09:57:52AM +0200, Jens Axboe wrote:
On Thu, Aug 04 2005, Andrew Vasquez wrote:
All,
While adding support for the new change_queue_depth/type() callbacks,
static int
qla2x00_change_queue_depth(struct
On 08/04/05 18:33, James Bottomley wrote:
This patch upports all relevant code fixes and bumps the driver version
to 7.0 to signify starting a new tree.
Tremendously good work!
Luben
James
diff --git a/Documentation/scsi/aic7xxx.txt b/Documentation/scsi/aic7xxx.txt
---
On Thu, 2005-08-04 at 07:40 -0400, Salyzyn, Mark wrote:
In these cases, the 'addr' is an u64, so is it necessary to perform this
modification?
Arjan,
Do you agree with the above? If so, is the patch OK as is?
Thanks,
Mark.
I will do a critical analysis of the remaining code in the driver
Ok, I've now figured out where the bug appears. 2.6.12-rc4 runs fine
while -rc5 does not.
Rgds
Pierre
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2005-08-05 at 07:24 -0700, Mark Haverkamp wrote:
On Thu, 2005-08-04 at 07:40 -0400, Salyzyn, Mark wrote:
In these cases, the 'addr' is an u64, so is it necessary to perform this
modification?
Arjan,
Do you agree with the above? If so, is the patch OK as is?
Ok you're ok then.
On Thu, 2005-08-04 at 23:39 -0700, Andrew Morton wrote:
James, could some of the scsi core rework have caused this?
Well, I don't think so. The error below:
sdc: Unit Not Ready, sense:
: Current: sense key=0x0
ASC=0x0 ASCQ=0x0
target0:0:10: FAST-40 WIDE SCSI 80.0 MB/s DT (25 ns,
--James Bottomley [EMAIL PROTECTED] wrote (on Friday, August 05, 2005
09:24:52 -0500):
On Thu, 2005-08-04 at 23:39 -0700, Andrew Morton wrote:
James, could some of the scsi core rework have caused this?
Well, I don't think so. The error below:
sdc: Unit Not Ready, sense:
: Current:
On Fri, 2005-08-05 at 07:36 -0700, Martin J. Bligh wrote:
Howcome it works on all mainline kernels, and not -mm then? ;-)
Did we fix an error path to detect failures, maybe?
Well, OK, it might be something to do with your drives trying to
negotiate IU and QAS. Support for this was added to the
On Fri, 05 Aug 2005, Tejun Heo wrote:
Oops, forget about the previous mail. Above patch make it into the
tree and it's the source of the problem. My git HEAD was pointing at
the latest update but I haven't updated my cache, so I was looking at
the old source tree. My apologies for
On Fri, Aug 05 2005, Andrew Vasquez wrote:
On Fri, 05 Aug 2005, Tejun Heo wrote:
Oops, forget about the previous mail. Above patch make it into the
tree and it's the source of the problem. My git HEAD was pointing at
the latest update but I haven't updated my cache, so I was
The size is to match the 64 bit address space command packet to the
adapter. A dma_addr_t is assigned to an u64 which ends up in a pair of
__le32's. We also issue 32 bit address space command packets where the
dma_addr_t is (truncated) into an u32 and placed into a single __le32.
The code style
On Fri, 2005-08-05 at 21:33 +0900, Tejun Heo wrote:
Here's the fix. It basically revives bqt-real_max_depth sans
allocation optimization in init_tag_map. I've also added a comment
explicitly noting that tag map cannot be shrunk to prevent other
morons like me. :-( Please try this one and
ata_host_intr cant be either inline or exported.
Signed-off-by: Olaf Hering [EMAIL PROTECTED]
Index: linux-2.6.12/drivers/scsi/libata-core.c
===
--- linux-2.6.12.orig/drivers/scsi/libata-core.c
+++
Olaf Hering wrote:
ata_host_intr cant be either inline or exported.
Signed-off-by: Olaf Hering [EMAIL PROTECTED]
Index: linux-2.6.12/drivers/scsi/libata-core.c
===
--- linux-2.6.12.orig/drivers/scsi/libata-core.c
+++
On Fri, Aug 05, 2005 at 11:32:07AM -0500, James Bottomley wrote:
On Fri, 2005-08-05 at 21:33 +0900, Tejun Heo wrote:
Here's the fix. It basically revives bqt-real_max_depth sans
allocation optimization in init_tag_map. I've also added a comment
explicitly noting that tag map cannot be
On Fri, Aug 05, 2005 at 05:59:06PM +0200, Jens Axboe wrote:
On Fri, Aug 05 2005, Andrew Vasquez wrote:
On Fri, 05 Aug 2005, Tejun Heo wrote:
Oops, forget about the previous mail. Above patch make it into the
tree and it's the source of the problem. My git HEAD was pointing at
On Fri, Aug 05, Andrew Vasquez wrote:
Confused, you found a reference to ata_host_intr() in qla4xxx
(QLogic's iSCSI driver)? This is in a SLES kernel correct, and not in
mainline?
No, qla4xxx called extern inline function in foo.c from bar.c. gcc4 doesnt like
that because the 'function body
Olaf Hering wrote:
On Fri, Aug 05, Jeff Garzik wrote:
When I wrote this, the compiler did what I expected: it inlined the
local copy, and exported a copy for external modules to call.
so you have the code twice? how clever...
This is one of the key hot paths in the driver.
Considering
On Fri, 2005-08-05 at 09:25 -0400, SCSI Mailing List wrote:
Tremendously good work!
Thanks. There's unfortunately still an outstanding problem I can't fix.
It seems that after a certain number of repetitions of a failing
command, the entire card locks up and the sequencer always returns
Doug Maxey [EMAIL PROTECTED] wrote:
On Fri, 05 Aug 2005 13:10:56 EDT, Jeff Garzik wrote:
Olaf Hering wrote:
ata_host_intr cant be either inline or exported.
Signed-off-by: Olaf Hering [EMAIL PROTECTED]
Index: linux-2.6.12/drivers/scsi/libata-core.c
On Fri, 05 Aug 2005 13:10:51 PDT, Andrew Morton wrote:
Doug Maxey [EMAIL PROTECTED] wrote:
On Fri, 05 Aug 2005 13:10:56 EDT, Jeff Garzik wrote:
Olaf Hering wrote:
ata_host_intr cant be either inline or exported.
Signed-off-by: Olaf Hering [EMAIL PROTECTED]
Index:
The cmd-timeout field has been obsolete for a while now. While looking
to remove it, I came across this use in the aacraid driver. It looks
like you want to initialise the firmware with the current timeout of the
command (in seconds), so the value I think you should be using is cmd-
I'm having communication problems between an sym53c895 host adapter and
an old/slow SCSI-1 device. I'm using FC4 linux with the most recent FC4
-released kernel 2.6.12-1.1398. The sym53c8xx_2 driver version is
sym-2.2.0. The sym53c8xx_2 driver was working for me until the 2.6.10
kernel
On 8/4/05, Jesper Juhl [EMAIL PROTECTED] wrote:
On 8/4/05, Saripalli, Venkata Ramanamurthy (STSD) [EMAIL PROTECTED] wrote:
Patch 1 of 2
This patch fixes the #error this is too much stack in 2.6 kernel.
Using kmalloc to allocate memory to ulFibreFrame.
[snip]
if( fchs-pl[0]
28 matches
Mail list logo
