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.
next prev parent 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).