Hi Hannes,
Sorry for the late reply.
(2014/08/28 21:15), Hannes Reinecke wrote:
On 08/28/2014 08:19 AM, Yoshihiro YUNOMAE wrote:
Hi Hannes,
I tried to remove duplicated decoder of SCSI command, but the
output format of it in constants.c is different from it in traceevents.
I have two
On 09/01/2014 12:18 AM, Christoph Hellwig wrote:
Can you change the subject a bit? There's nothing obsolete in
__scsi_print_command, you're just moving it to a higher level helper.
#if defined(AHA152X_DEBUG)
if (HOSTDATA(shpnt)-debug debug_queue) {
-printk(INFO_LEAD
--
Lieber Freund,
Wie geht es Ihnen heute? Ich hoffe, fein, ich bin Dr. Martin Dustin aus
Harlesden , North West London, hier in England. Ich arbeite für NatWest
Bank London (National Westminster Bank Plc. ) . Ich schreibe Ihnen aus
meinem Büro , die von einer großen immensen Nutzen für
On 08/31/2014 11:43 PM, Christoph Hellwig wrote:
Needs a bit more description in the patch body and preferable also
in a comment next to the macro. What's the benefit of it over simply
using sdev_printk with another argument?
This is particularly useful for ULDs which do not have access to
On 08/31/2014 11:55 PM, Christoph Hellwig wrote:
-scsi_extd_sense_format(unsigned char asc, unsigned char ascq) {
+scsi_extd_sense_format(unsigned char asc, unsigned char ascq,
+ const char **fmt) {
please move the opening brace to a new line per normal Linux style.
Done.
On 09/01/2014 12:00 AM, Christoph Hellwig wrote:
On Thu, Aug 28, 2014 at 07:33:20PM +0200, Hannes Reinecke wrote:
If scsi_normalize_sense() fails we couldn't decode the sense
buffer, so we should not try to interpret the result.
We should rather dump the sense buffer instead and stop decoding.
On 09/01/2014 12:06 AM, Christoph Hellwig wrote:
On Thu, Aug 28, 2014 at 07:33:21PM +0200, Hannes Reinecke wrote:
Currently we're only decoding sense extras for tape devices.
And even there only for fixed format sense formats.
As this is of rather limited use in the general case we should
be
On 09/01/2014 12:09 AM, Christoph Hellwig wrote:
On Thu, Aug 28, 2014 at 07:33:22PM +0200, Hannes Reinecke wrote:
Dumping the entire sense buffer might overwhelm the logging functions,
so suppress it per default.
Call me dumb, but I don't see anything in here that limits the dumps
to debug
On 09/01/2014 12:11 AM, Christoph Hellwig wrote:
Please also remove the now useless sd_print_result wrapper.
Done.
Otherwise looks good,
Reviewed-by: Christoph Hellwig h...@lst.de
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries Storage
h...@suse.de
On 09/01/2014 12:14 AM, Christoph Hellwig wrote:
#if defined(AHA152X_DEBUG)
-if (HOSTDATA(shpnt)-debug debug_status) {
-printk(DEBUG_LEAD inbound status %02x , CMDINFO(CURRENT_SC),
CURRENT_SC-SCp.Status);
-scsi_print_status(CURRENT_SC-SCp.Status);
-
On 09/01/2014 12:19 AM, Christoph Hellwig wrote:
On Thu, Aug 28, 2014 at 07:33:27PM +0200, Hannes Reinecke wrote:
SCSI opcode printing is tricky and needs to take into account
several different corner cases. So instead of trying to come
up with an elaborate printk() statement we should be
For getting driver byte, host byte, msg byte, and status byte, macros are
implemented in scsi/scsi.h, so we use it.
Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Reviewed-by: Ewan D. Milne emi...@redhat.com
Reviewed-by: Hannes Reinecke h...@suse.de
Cc: Hannes Reinecke
There is a decoder of SCSI command in constants.c, so this patch deletes it in
SCSI traveevents.
A decoder in traceevents uses macros, so the command name is output as
XXX_YYY_ZZZ. On the other hand, a decoder in constants uses strings, so
the command name is output as Xxx Yyy Zzz including
Hi All,
This patchset deletes duplicated decoders in scsi_trace.c.
Almost decoders are implemented in constants.c, so we should use them.
This patchset deletes following decoders in scsi_trace.c:
- hostbyte in patch [2/3]
- driverbyte in patch [2/3]
- SCSI command in patch [3/3]
This
There are decoders of hostbyte and driverbyte in constants.c, so this patch
deletes those in SCSI traveevents.
Note:
If CONFIG_SCSI_CONSTANTS is disabled, hostbyte, driverbyte, msgbyte, and
statusbyte are output as raw format from this patch.
Signed-off-by: Yoshihiro YUNOMAE
On 09/01/2014 10:57 AM, Hannes Reinecke wrote:
On 09/01/2014 12:19 AM, Christoph Hellwig wrote:
On Thu, Aug 28, 2014 at 07:33:27PM +0200, Hannes Reinecke wrote:
SCSI opcode printing is tricky and needs to take into account
several different corner cases. So instead of trying to come
up with
On Mon, Sep 01, 2014 at 12:33:28PM +, Yoshihiro YUNOMAE wrote:
For getting driver byte, host byte, msg byte, and status byte, macros are
implemented in scsi/scsi.h, so we use it.
As mentioned about three times in various previous scsi logging discussions
this is entirely wrong and breaks
--- a/drivers/scsi/scsi_debug.c 2014-08-26 13:24:51.646948507 -0400
+++ b/drivers/scsi/scsi_debug.c 2014-08-30 18:04:54.589226679 -0400
@@ -2743,6 +2743,13 @@ static int stop_queued_cmnd(struct scsi_
if (test_bit(k, queued_in_use_bm)) {
sqcp =
Hi,
I have an Adaptec 71605H HBA that's randomly failing to detect any
drives at boot. I have two systems with this HBA, and both are
showing the exact same behavior. I can reproduce this randomly about
3 out of 4 times, where most of the time it comes up where lsscsi
shows no drives attached
On 28/08/14 05:44, Juergen Gross wrote:
This series adds XEN pvSCSI support. With pvSCSI it is possible to use
physical
SCSI devices from a XEN domain.
Applied to devel/for-linus-3.18.
Thanks.
Your lines in your descriptions were too long for the default git log
format. I fixed this up but
I never heard back on this. It still looks like a very serious bug
with security implications etc.
regards,
dan carpenter
On Mon, Jun 24, 2013 at 06:46:31PM +0300, Dan Carpenter wrote:
My static checker complains about a possible array overflow in
__iscsi_conn_send_pdu().
On 14-09-01 11:36 AM, Christoph Hellwig wrote:
--- a/drivers/scsi/scsi_debug.c 2014-08-26 13:24:51.646948507 -0400
+++ b/drivers/scsi/scsi_debug.c 2014-08-30 18:04:54.589226679 -0400
@@ -2743,6 +2743,13 @@ static int stop_queued_cmnd(struct scsi_
if (test_bit(k,
On 9/1/14, 1:06 PM, Dan Carpenter wrote:
I never heard back on this. It still looks like a very serious bug
with security implications etc.
Sorry about that. I must have missed the original. You are right. I
should have a tested patch by tomorrow.
regards,
dan carpenter
On Mon, Jun 24,
Dear all:
The kernel version is 3.16.1-1-ARCH
Today I keep getting this panic when booting up.
http://i.imgur.com/0Rx93Kr.jpg
It might be that the UAS device was in some strange state,
because that after I unplugged and power-cycled the UAS,
everything went normal again.
Does anyone know
24 matches
Mail list logo