linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jon Bendtsen <jonbendtsen@jbit.dk>
To: James Bottomley <James.Bottomley@suse.de>
Cc: linux-scsi@vger.kernel.org
Subject: Re: understanding the sg_ses --raw output? so I can turn on the faulty light
Date: Tue, 08 Feb 2011 15:22:59 +0100	[thread overview]
Message-ID: <4D5151C3.5090806@jbit.dk> (raw)
In-Reply-To: <1297174684.3088.11.camel@mulgrave.site>

On 08/02/11 15.18, James Bottomley wrote:
> On Tue, 2011-02-08 at 13:55 +0100, Jon Bendtsen wrote:
>> On 07/02/11 16.40, James Bottomley wrote:
>>> On Mon, 2011-02-07 at 16:25 +0100, Jon Bendtsen wrote:
>>>> Hi
>>>>
>>>> There has earlier been 2 threads on sg_ses 21 may 2007 and 10 june 2010,
>>>> but unfortunately neither seemed to include information about how to
>>>> understand the --raw output from sg_ses.
>>>
>>> It's a hex dump of the diagnostic mode page.
>>
>> I know that. What I meant was which segments in the hex dump correlate
>> to which segments in the text version of the dianostic mode page?
> 
> It's what the man page says:  the byte for byte output of the diagnostic
> mode page minus the first four bytes.
> 
>> How long are the segments? 8 bytes? The way it is formatted something
>> could hint that? Or is it just 4 bytes which another formatting suggests?
> 
> Well the descriptor format is variable, it's documented in the SES
> standard.

Which I have not been able to find in a available standard. The
organisation wants money to show me.

I managed to find a PDF though, see my other post. Thank you for taking
your time to answer my questions.


> [...]
>>> I'd firstly validate that your lights can be flashed with the ses
>>> driver ... if they can, then look for a mistake in the hex dump.
>>
>> How can I validate that my lights can be flashed with the SES driver?
> 
> well, it depends what the enclosure calls it's slots, but it would be
> something like
> 
> echo 1 > /sys/class/enclosure/<dev>/<slot>/fault

I do not have those


> After making sure the ses driver is loaded and bound, of course.  Quite
> a few fault lights are hard wired, and not amenable to software
> interference (others aren't hard wired at all and only work with
> software).

ok.

  reply	other threads:[~2011-02-08 14:23 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-07 15:25 understanding the sg_ses --raw output? so I can turn on the faulty light Jon Bendtsen
2011-02-07 15:40 ` James Bottomley
2011-02-08 12:55   ` Jon Bendtsen
2011-02-08 14:18     ` James Bottomley
2011-02-08 14:22       ` Jon Bendtsen [this message]
2011-02-08 14:15 ` Jon Bendtsen

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=4D5151C3.5090806@jbit.dk \
    --to=jonbendtsen@jbit.dk \
    --cc=James.Bottomley@suse.de \
    --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;
as well as URLs for NNTP newsgroup(s).