Mark Lord | 1 Sep 01:45 2009
Picon

Re: MD/RAID time out writing superblock

Mark Lord wrote:
> Tejun Heo wrote:
>> Ric Wheeler wrote:
> ..
>>> The drive might take a longer time like this when doing error handling
>>> (sector remapping, etc), but then I would expect to see your remapped
>>> sector count grow.
>>
>> Yes, this is a possibility and according to the spec, libata EH should
>> be retrying flushes a few times before giving up but I'm not sure
>> whether keeping retrying for several minutes is a good idea either.
>> Is it?
> ..
> 
> Libata will retry only when the FLUSH returns an error,
> and the next FLUSH will continue after the point where
> the first attempt failed.
> 
> But if the drive can still auto-relocate sectors, then the
> first FLUSH won't actually fail.. it will simply take longer
> than normal.
> 
> A couple of those, and we're into the tens of seconds range
> for time.
> 
> Still, it would be good to actually produce an error like that
> to examine under controlled circumstances.
> 
> Hmm.. I had a drive here that gave symptoms like that.
> Eventually, I discovered that drive had run out of relocatable
(Continue reading)

Jonathan Nell | 1 Sep 08:13 2009
Picon

scsi traffic sniffing

Is there any way to sniff the traffic of a scsi device? I need to
debug a firmware update and need to see the traffic being passed to
the drive
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jonathan Nell | 1 Sep 09:10 2009
Picon

SCSI reference

I'm new to this scsi stuff. Is there any good online reference where I
can look up CDBs and the format of responses etc.
For e.g. I know that  0x43 is READ_TOC but I have no idea how to
construct the CDB and what format to response is.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

jack wang | 1 Sep 09:59 2009

Re: SCSI reference


I'm new to this scsi stuff. Is there any good online reference where I
can look up CDBs and the format of responses etc.
For e.g. I know that  0x43 is READ_TOC but I have no idea how to
construct the CDB and what format to response is.

You should look into t10.org to get SAM SPC SBC specs first , All SCSI
command
& response format could be found there , or you just look the kernel source
in driver/scsi 

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Steven Whitehouse | 1 Sep 11:06 2009
Picon

Re: [PATCH 2/7] block: use blkdev_issue_discard in blk_ioctl_discard

Hi,

For the GFS2 bits:

Acked-by: Steven Whitehouse <swhiteho <at> redhat.com>

Steve.

On Sat, 2009-08-29 at 19:03 -0400, Christoph Hellwig wrote:
> plain text document attachment (discard-unify-code)
> blk_ioctl_discard duplicates large amounts of code from blkdev_issue_discard,
> the only difference between the two is that blkdev_issue_discard needs to
> send a barrier discard request and blk_ioctl_discard a non-barrier one,
> and blk_ioctl_discard needs to wait on the request.  To facilitates this
> add a flags argument to blkdev_issue_discard to control both aspects of the
> behaviour.  This will be very useful later on for using the waiting
> funcitonality for other callers.
> 
> Based on an earlier patch from Matthew Wilcox <matthew <at> wil.cx>.
> 
> 
> Signed-off-by: Christoph Hellwig <hch <at> lst.de>
> 
> Index: linux-2.6/block/blk-barrier.c
> ===================================================================
> --- linux-2.6.orig/block/blk-barrier.c	2009-08-29 16:49:43.067370900 -0300
> +++ linux-2.6/block/blk-barrier.c	2009-08-29 17:43:30.407344330 -0300
>  <at>  <at>  -348,6 +348,9  <at>  <at>  static void blkdev_discard_end_io(struct
>  		clear_bit(BIO_UPTODATE, &bio->bi_flags);
>  	}
(Continue reading)

谢纲 | 1 Sep 12:40 2009
Picon

Re: scsi traffic sniffing

On Tue, Sep 1, 2009 at 2:13 PM, Jonathan Nell<crtrn13 <at> gmail.com> wrote:
> Is there any way to sniff the traffic of a scsi device? I need to
> debug a firmware update and need to see the traffic being passed to
> the drive
You may hook the queue_command function of the scsi host. It can sniff
all scsi request to scsi host driver.
Thanks,
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--

-- 
Xie Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bart Van Assche | 1 Sep 13:12 2009
Picon

Re: [PATCH] SCSI driver for VMware's virtual HBA.

On Mon, Aug 31, 2009 at 8:00 PM, James Bottomley
<James.Bottomley <at> suse.de> wrote:
>
> On Mon, 2009-08-31 at 10:28 -0700, Alok Kataria wrote:
> > VMware PVSCSI driver - v2.
>
> OK, so the first thing that springs to mind is that we already have one
> of these things: the ibmvscsi ... is there no way we can share code
> between this and the other PV drivers?

Good question. But shouldn't the ibmvscsi driver be refactored before
considering sharing ibmvscsi code with other paravirtualized drivers ?
A quote from the ibmvscsi.c source code:

 * TODO: This is currently pretty tied to the IBM i/pSeries hypervisor
 * interfaces.  It would be really nice to abstract this above an RDMA
 * layer.

Splitting the ibmvscsi.c driver in an SRP initiator and an RDMA driver
would make the following possible:
- Reuse the existing SRP initiator (ib_srp). Currently there are two
SRP initiators present in the Linux kernel -- one that uses the RDMA
verbs API (ib_srp) and one that only works with IBM's i/pSeries
hypervisor (ibmvscsi).
- Reuse the ib_ipoib kernel module to provide an IP stack on top of
the new RDMA driver instead of having to maintain a separate network
driver for this hardware (ibmveth).

More information about the architecture the ibmvscsi and the ibmveth
drivers have been developed for can be found in the following paper:
(Continue reading)

Stefan Richter | 1 Sep 13:19 2009
Picon

Re: scsi traffic sniffing

谢纲 wrote:
> On Tue, Sep 1, 2009 at 2:13 PM, Jonathan Nell<crtrn13 <at> gmail.com> wrote:
>> Is there any way to sniff the traffic of a scsi device? I need to
>> debug a firmware update and need to see the traffic being passed to
>> the drive
> You may hook the queue_command function of the scsi host. It can sniff
> all scsi request to scsi host driver.

Actually you can switch on logging of commands and status (though not of 
data) at runtime by something like
# echo $BITMASK > /sys/module/scsi_mod/parameters/scsi_logging_level
or
# echo $BITMASK > /proc/sys/dev/scsi/logging_level
provided that the kernel's SCSI core was compiled with 
CONFIG_SCSI_LOGGING=y.

Bitmask values can be constructed as in 
linux/drivers/scsi/scsi_logging.h.  Long ago I made a note that 9216 as 
bitmask was useful for my purposes, but don't ask me what that means.

For data logging, you have to modify the SCSI low-level driver or SCSI 
core indeed.

However, all this applies only if the firmware updater actually runs on 
a Linux initiator, not e.g. on an MS Windows initiator.  In the latter 
case, you need a debug driver which hooks into Windows' SCSI stack, or 
some sort of bus analyzer.
--

-- 
Stefan Richter
-=====-==--= =--= ----=
(Continue reading)

Stefan Richter | 1 Sep 13:28 2009
Picon

Re: SCSI reference

jack wang wrote:
[Jonathan Nell wrote]
>> I'm new to this scsi stuff. Is there any good online reference where I
>> can look up CDBs and the format of responses etc.
>> For e.g. I know that  0x43 is READ_TOC but I have no idea how to
>> construct the CDB and what format to response is.
> 
> You should look into t10.org to get SAM SPC SBC specs first , All SCSI
> command & response format could be found there
[...]

To add to that:  If you are not quite satisfied with what you can find 
at http://www.t10.org/ftp/t10/drafts/ nowadays, have a look at 
http://web.archive.org/web/*/http://www.t10.org/ftp/t10/drafts/.
--

-- 
Stefan Richter
-=====-==--= =--= ----=
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Andrei Tanas | 1 Sep 15:07 2009
Picon

Re: MD/RAID time out writing superblock

>>>> The drive might take a longer time like this when doing error handling
>>>> (sector remapping, etc), but then I would expect to see your remapped
>>>> sector count grow.
>>>
>>> Yes, this is a possibility and according to the spec, libata EH should
>>> be retrying flushes a few times before giving up but I'm not sure
>>> whether keeping retrying for several minutes is a good idea either.
>>> Is it?
>> ..
>> 
>> Libata will retry only when the FLUSH returns an error,
>> and the next FLUSH will continue after the point where
>> the first attempt failed.
>> 
>> But if the drive can still auto-relocate sectors, then the
>> first FLUSH won't actually fail.. it will simply take longer
>> than normal.
>> 
>> A couple of those, and we're into the tens of seconds range
>> for time.
>> 
>> Still, it would be good to actually produce an error like that
>> to examine under controlled circumstances.
>> 
>> Hmm.. I had a drive here that gave symptoms like that.
>> Eventually, I discovered that drive had run out of relocatable
>> sectors, too.  Mmm.. I'll see if I can get it back (loaned it out)
>> and perhaps we can recreate this specific scenario on it..
> ..
> 
(Continue reading)


Gmane