From: brem belguebli <brem.belguebli@gmail.com>
To: James Smart <james.smart@emulex.com>
Cc: linux-scsi@vger.kernel.org
Subject: Re: lpfc SAN/SCSI issue
Date: Tue, 27 Apr 2010 19:37:54 +0200 [thread overview]
Message-ID: <1272389874.4245.2.camel@localhost> (raw)
In-Reply-To: <1272318721.16254.7.camel@localhost>
Hi James,
I could set lpfc_log_verbose on both HBA's to 4115, I hope it'll be high
enough to get interesting traces.
On Mon, 2010-04-26 at 23:52 +0200, brem belguebli wrote:
> Hi James,
>
> On Mon, 2010-04-26 at 13:50 -0400, James Smart wrote:
> > Brem,
> >
> > I'm not understanding you.
> >
> >
> > brem belguebli wrote:
> > > We have sg3_utils installed , and I think we ran sg_verify on one or
> > > 2
> > > unresponsive /dev/sd and it didn't give the hand back.
> > >
> > what do you mean "give the hand back" ? was the operation
> > successful or not ?
> >
> When I say it didn't give the hand back, I mean the one or 2 processes
> got stuck in D state, thus not returning success .
> > > It was exactly
> > > cd /sys/block
> > > for DEV in `ls -1d dev*`; do
> > > echo ${DEV}
> > > dd if =/dev/${DEV} of=/dev/null bs=1024 count=1 &
> > > echo
> > > done
> > >
> > > And yes it really works, never seen any kind of preemption of DM-MP over
> > > direct sd access. I've cc'ed dm-devel may be some DM guru could give his
> > > opinion on this.
> > >
> > > Next time, I'll use a sg_dd instead of dd, to bypass any cache effect
> > > (by the way, does VFS cache anything when addressing /dev/X devices ?)
> > >
> > ok - by "works" means "dd successfully read 1 block from the device" -
> > right ?
> >
> Yes, the devices on which dd was successful were the ones from FABRIC1,
> dd completed successfully by reading the first 1024 bytes to copy them
> to /dev/null
>
> > > > The most interesting for the lpfc driver would be the lpfc module
> > > > parameter "lpfc_log_verbose=4115"
> > > > which turns on discovery log messages, els messages, link events, and
> > > > FCP i/o error messages.
> > > >
> > >
> > > As our DWDM ring switch is on the less optimal path, there will be a
> > > switch back to nominal soon.
> > >
> > > I'll activate this log level on the HBA's and check the firmware
> > > versions you gave me .
> > >
> > ok. I believe that the shost for the adapters in question, have a
> > sysfs variable for lpfc_log_verbose, that sets the log level on the
> > individual adapter. This would not require you to unload/reload the
> > driver to set the option.
> >
> I'll tell you tomorrow (was off today) if the parameter exists for these
> HBA's.
> > > Hopefully, we will be able to provide you something deeper to
> > > investigate.
> > >
> > > Brem
> > >
> >
> > ok.
> >
> > -- james
> >
> >
> Thanks
>
>
next prev parent reply other threads:[~2010-04-27 15:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-22 16:47 [PATCH] mpt2sas: DIF Type 2 Protection Support Eric Moore
2010-04-22 19:24 ` lpfc SAN/SCSI issue brem belguebli
2010-04-23 13:28 ` James Smart
[not found] ` <j2o29ae894c1004230922le8baf635y563e50e3edc53bc3@mail.gmail.com>
[not found] ` <4BD226F4.6070908@emulex.com>
[not found] ` <1272109999.2983.30.camel@localhost>
[not found] ` <4BD5D258.8030309@emulex.com>
2010-04-26 21:52 ` brem belguebli
2010-04-27 17:37 ` brem belguebli [this message]
2010-05-03 16:39 ` brem belguebli
2010-05-05 14:01 ` James Smart
2010-05-06 11:06 ` brem belguebli
2010-05-06 13:39 ` James Smart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1272389874.4245.2.camel@localhost \
--to=brem.belguebli@gmail.com \
--cc=james.smart@emulex.com \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox