On Sat, Aug 18 2007, FUJITA Tomonori wrote:
This fixes 'trailing data' bug in the sglist libata patch in Jens'
block git tree.
Aug 18 16:03:03 tulip kernel: ata1.00: 36 bytes trailing data
Aug 18 16:03:03 tulip kernel: scsi scan: INQUIRY result too short (5), using
36
With the patch,
On Sat, Aug 18 2007, FUJITA Tomonori wrote:
On Fri, 17 Aug 2007 01:47:59 +0900
FUJITA Tomonori [EMAIL PROTECTED] wrote:
This is for Jens' sglist branch in the block git tree.
It enables sg chaining support for the LLDs that use scsi_for_each_sg
accessor properly.
---
From
On Fri, Aug 17 2007, FUJITA Tomonori wrote:
This is for Jens' sglist branch in the block git tree.
It enables sg chaining support for the LLDs that use scsi_for_each_sg
accessor properly.
---
From a6e50a3b476bc193de103e8c1d95877ced38918e Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori
On Sun, Aug 19, 2007 at 11:09:46PM -0700, Matthew Dharm wrote:
Off the cuff, this really looks like something for the SCSI layer. I'll
bet there are SCSI devices that do something similar...
And, I'm generally reluctant to modify the data to/from a device unless
usb-storage *really* has to
On Mon, 20 Aug 2007 09:10:31 +0200
Jens Axboe [EMAIL PROTECTED] wrote:
On Sat, Aug 18 2007, FUJITA Tomonori wrote:
On Fri, 17 Aug 2007 01:47:59 +0900
FUJITA Tomonori [EMAIL PROTECTED] wrote:
This is for Jens' sglist branch in the block git tree.
It enables sg chaining support
The FC transport class calls scsi_scan_target with the SCAN_WILD_CARD
flag to automatically scan for logical units. zfcp, on the other hand,
only uses the units that are configured via the zfcp sysfs interface.
The main reason for this, is that the adapter behind zfcp supports
adapter sharing
On Mon, 2007-08-20 at 10:37 +0200, Rogier Wolff wrote:
On Sun, Aug 19, 2007 at 11:09:46PM -0700, Matthew Dharm wrote:
Off the cuff, this really looks like something for the SCSI layer. I'll
bet there are SCSI devices that do something similar...
And, I'm generally reluctant to modify
On Mon, Aug 20 2007, FUJITA Tomonori wrote:
On Mon, 20 Aug 2007 09:10:31 +0200
Jens Axboe [EMAIL PROTECTED] wrote:
On Sat, Aug 18 2007, FUJITA Tomonori wrote:
On Fri, 17 Aug 2007 01:47:59 +0900
FUJITA Tomonori [EMAIL PROTECTED] wrote:
This is for Jens' sglist branch in the
In testing 2.6.23-rc3, there is a small window where the async-per-target
scan of the transport can beat the call from the LLDD to scsi_scan_host().
If so, the target scan starts, and can add the sdev (and the sysfslinks) before
the flags for async scan can prevent it. Thus, when async scan
On Mon, Aug 20, 2007 at 09:10:35AM -0400, James Smart wrote:
In testing 2.6.23-rc3, there is a small window where the async-per-target
scan of the transport can beat the call from the LLDD to scsi_scan_host().
I'd assumed that events wouldn't come in until -scan_start was called.
I see lpfc
Well - depends on what the semantics of scan_start are to date, there
really are none and what does requiring it mean ?
What's implied is that you want bring up link to be enabled in scan_start().
Doable, but the code paths weren't put together expecting this, so it may be
a bit of
On Mon, 20 Aug 2007 15:05:22 +0200
Jens Axboe [EMAIL PROTECTED] wrote:
On Mon, Aug 20 2007, FUJITA Tomonori wrote:
On Mon, 20 Aug 2007 09:10:31 +0200
Jens Axboe [EMAIL PROTECTED] wrote:
On Sat, Aug 18 2007, FUJITA Tomonori wrote:
On Fri, 17 Aug 2007 01:47:59 +0900
FUJITA
On Mon, Aug 20, 2007 at 10:02:45AM -0400, James Smart wrote:
Well - depends on what the semantics of scan_start are to date, there
really are none and what does requiring it mean ?
OK, and to make this discussion exceptionally useful, all comments are
to be made in the context of
If kthread_run failed, we would fail to scan the host, and leak the
allocated async_scan_data. Since using a separate thread is just an
optimisation, do the scan synchronously if we fail to spawn a thread.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
diff --git a/drivers/scsi/scsi_scan.c
Oops. I fail to drive git-send-email properly again.
James, when you're committing this, please use the
Subject: [PATCH] scsi_scan: Cope with kthread_run failing
On Mon, Aug 20, 2007 at 09:18:48AM -0600, Matthew Wilcox wrote:
If kthread_run failed, we would fail to scan the host, and leak the
Where should other (undocumented) SCSI API docs be added?
I'll be glad to send updates/patches/
E.g.:
scsi_bufflen(cmnd)
scsi_sg_count(cmnd)
scsi_sglist(cmnd)
scsi_get_resid(cmnd)
scsi_set_resid(cmnd, int)
and all kernel-doc blocks from scsi_lib.c
Thanks,
---
~Randy
*** Remember to use
I'd prefer a flag/bit in the fc template to indicate no scanning by the
transport. Thus, it's up to the driver to call __scsi_add_device, or
perform the appropriate scans...
Note: this doesn't stop the problem in absolute. as long as there's scan
interfaces via sysfs, any tool/admin could
17 matches
Mail list logo
