public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Anderson <mike.anderson@us.ibm.com>
To: Eddie Williams <Eddie.Williams@steeleye.com>
Cc: Douglas Gilbert <dougg@torque.net>,
	"Cress, Andrew R" <andrew.r.cress@intel.com>,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH-2.4.3] scsi logging
Date: Tue, 10 Jul 2001 09:17:15 -0700	[thread overview]
Message-ID: <20010710091715.B24861@us.ibm.com> (raw)
In-Reply-To: <dougg@torque.net> <200107101335.f6ADZ4f01436@localhost.localdomain>
In-Reply-To: <200107101335.f6ADZ4f01436@localhost.localdomain>; from Eddie.Williams@steeleye.com on Tue, Jul 10, 2001 at 09:35:04AM -0400

	
While I would like to see scsi scan pick up / print  serial numbers or a
form of device UUID  I have to agree with Eddie that this patch would only
provide data for devices that decided to fill in the vendor specific area
of the standard inquiry page.

A more generic solution would involve two more inquiry commands to the
device using the EVPD bit. The first would be to request page 0 and then
working from highest to lowest use page 0x83, 0x80, stanard inquiry page
(vendor, product, serial). In some cases though with really old devices
this still might not generate useful information.

-Mike

Eddie Williams [Eddie.Williams@steeleye.com] wrote:
> 
>  .. Snip ...
> Getting back to your first comment (sorry I have already deleted your initial 
> mail) did you provide the patch for getting the serial number?  Note that 
> getting the serial number is not a required SCSI feature so you wont get 100% 
> of the devices.
> 
> Eddie Williams
> 
> > Andrew wrote:
> > > I'd like to propose the following patch to 3 SCSI mid-layer 
> > > files from kernel 2.4.3.  I have tested this with 2.4.3, 
> > > but it should be relevant to other 2.4.x kernels also.
> > > 
> > > It has the following changes/enhancements:
> > > 1) Log the disk serial number during scsi_scan() 
> > >    - scsi_scan.c.
> > >    Why: This is a requirement in some environments to 
> > >    ensure unambiguous identification of a particular 
> > >    problem disk.
> > > 2) Interpret additional values in print_sense_internal()
> > >    - constants.c.  Why: The detail wrt Illegal Requests 
> > >    is very useful, since it can indicate either an 
> > >    application bug or an incompatible feature of the device.
> > > 3) Don't skip logging sense errors for sg functions - sg.c.
> > >    Why: All sense errors should be logged so that a 
> > >    potential scsi device hardware problem doesn't go
> > >    unrecognized.
> > 
> > Andrew,
> > I would object to point 3). SANE, and to a lesser extent
> > cdrecord, execute lots of commands that give SCSI check
> > conditions and would bloat the log and the console with
> > many serious looking messages. Those error 
> > indications are conveyed back to the app via the sg 
> > interface so the information is not lost. There is an 
> > ioctl in the sg driver [SG_SET_DEBUG] to turn on that 
> > output to the log/console [the default is off (to
> > stop the curious querying the maintainer about the
> > strange messages in their logs)].
> > 
> > Doug Gilbert
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> > the body of a message to majordomo@vger.kernel.org
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Michael Anderson
mike.anderson@us.ibm.com


  reply	other threads:[~2001-07-10 16:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-10  4:34 [PATCH-2.4.3] scsi logging Douglas Gilbert
2001-07-10 13:35 ` Eddie Williams
2001-07-10 16:17   ` Mike Anderson [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-07-10 12:40 Cress, Andrew R
2001-07-09 18:24 Cress, Andrew R

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=20010710091715.B24861@us.ibm.com \
    --to=mike.anderson@us.ibm.com \
    --cc=Eddie.Williams@steeleye.com \
    --cc=andrew.r.cress@intel.com \
    --cc=dougg@torque.net \
    --cc=linux-kernel@vger.kernel.org \
    --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