Re: RES: RES: AS2105-based enclosure size issues with 2TB HDDs

[Oliver Neukum]

On Tue, 2014-08-26 at 10:47 -0400, Alan Stern wrote:
 On Mon, 25 Aug 2014, Oliver Neukum wrote:

  Just set US_FL_NEEDS_CAP16. If READ CAPACITY(16) fails in that case,
  it is clear that something is wrong. It must be set or READ CAPACITY(10)
  alone would be taken as giving a valid answer.
 
 You have committed a mental layering violation.  :-)

Indeed.

 US_FL_NEEDS_CAP16 is a usb-storage flag.  But the capacity
 determination is made by the sd driver, which relies on the SCSI
 try_rc_10_first flag.  If that flag isn't set, sd tries READ 
 CAPACITY(16) and then falls back to READ CAPACITY(10) if an error 
 occurs.  That's what happened here.
 
 I don't think we want to add another SCSI flag to say that READ
 CAPACITY(10) is unreliable.

Why not? It would only be friendly to tell the upper layer
of a malfunction if we know about it.

  At that time we are sure that the drive will be unusable unless we
  determine the correct capacity, so we don't make matters worse if we
  crash it.
 
 Given the difficulty of determining the true capacity, I see two
 alternatives.  We could set the capacity to a ridiculously large value
 (like 1 billion TB), or we could leave the capacity set to the low
 value and disable the block within bounds checks.  Neither of these
 is attractive and they both have issues of their own -- although the 
 second is close to what Windows does.

That seems to be the most attractive solution to me.

 (For example, udev often tries to read the last sectors of a new drive, 
 looking for a GPT or RAID signature.  That won't work if the capacity 
 is set to some random value.)

Yes, but clipping has its own dangers. Suppose you use the medium
without a partition table.

Regards
Oliver



--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Buffer I/O error after s2ram with usb storage

[Matthieu CASTET]

Ping

I have got also a problem with a usb sdcard reader (without power cut
during suspend)

[ 1073.606668] PM: Entering mem sleep
[ 1073.606742] Suspending console(s) (use no_console_suspend to debug)
[ 1073.607146] sd 1:0:0:0: [sda] Synchronizing SCSI cache
[ 1073.639076] sd 1:0:0:0: [sda] Stopping disk
[ 1074.186688] PM: suspend of devices complete after 580.127 msecs
[...]
[ 1075.265183] PM: resume of devices complete after 615.990 msecs
[ 1075.265627] PM: Finishing wakeup.
[ 1075.265630] Restarting tasks ... 
[...]
[ 1203.404593] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
6, 29065 clusters in bitmap, 32768 in gd; block bitmap corrupt. 
[ 1203.404628] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
5, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt.
[ 1203.404648] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
4, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt.
[ 1203.404667] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
3, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt.
[ 1203.404686] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
2, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt.
[ 1203.404705] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
1, 1600 clusters in bitmap, 32321 in gd; block bitmap corrupt.
[ 1203.404726] JBD2: Spotted dirty metadata buffer (dev = sdb6, blocknr = 0). 
There's a risk of filesystem corruption in case of system crash.
[ 1204.141482] sd 8:0:0:0: [sdb] Media Changed
[ 1204.141490] sd 8:0:0:0: [sdb]
[ 1204.141494] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 1204.141497] sd 8:0:0:0: [sdb]
[ 1204.141499] Sense Key : Unit Attention [current]
[ 1204.141504] Info fld=0x0
[ 1204.141506] sd 8:0:0:0: [sdb]
[ 1204.141510] Add. Sense: Not ready to ready change, medium may have changed
[ 1204.141514] sd 8:0:0:0: [sdb] CDB:
[ 1204.141516] Read(10): 28 00 00 0a 75 f8 00 00 08 00
[ 1204.141526] end_request: I/O error, dev sdb, sector 685560



Le Mon, 28 Apr 2014 15:01:39 +0200,
Matthieu CASTET matthieu.cas...@parrot.com a écrit :

 Hi,
 
 any news on this.
 
 Matthieu CASTET
 
 Le Tue, 22 Apr 2014 16:01:15 +0200,
 Matthieu CASTET matthieu.cas...@parrot.com a écrit :
 
  Hi,
  
  while playing with suspend to ram I found a strange behavior with usb
  key.
  
  This can be easily reproduced by doing :
  - plug a usb key
  - start to read the usb key : cat /dev/sdx  /dev/null
  - go to suspend : echo mem  /sys/power/state
  - while in suspend, unplug and replug the usb key (simulate usb power
  loss for computer that keep power)
  - exit suspend
  - there is read error on the usb key
  
  
  Because the power was cut during s2ram, the usb stack reset the device
  1.
  When new data transfer are done, we got a UNIT_ATTENTION from the
  device 2 and IO error are returned to user space application.
  
  After some investigation it seems some (all on the 3 I tested) usb key
  report as removable, and scsi layer abort the transfer in case of
  UNIT_ATTENTION 3.
  
  The usb storage driver call scsi_report_bus_reset after device reset,
  but because of commit dfcf7775 4, we don't ignore unit attention if
  sshdr.asc == 0x28  sshdr.ascq == 0x00 (Not-ready to ready).
  
  If dfcf7775 is reverted there is no more Buffer I/O error.
  
  Is that possible to find a way to restore the behavior before dfcf7775
  commit (no Buffer I/O error after device reset) after a suspend to ram ?
  
  
  Matthieu CASTET
  
  PS : the same error happen if sg_reset -b /dev/sdx is used on the
  device.
  
  
  1
  [  117.070255] usb 2-1.4: reset high-speed USB device number 3 using
  ehci-pci [...]
  [  117.543922] Restarting tasks ... done.
  [  117.548390] video LNXVIDEO:01: Restoring backlight state
  2
  [  117.549179] sd 6:0:0:0: [sdb] Media Changed
  [  117.549184] sd 6:0:0:0: [sdb]  
  [  117.549187] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
  [  117.549189] sd 6:0:0:0: [sdb]  
  [  117.549191] Sense Key : Unit Attention [current] 
  [  117.549195] Info fld=0x0
  [  117.549197] sd 6:0:0:0: [sdb]  
  [  117.549201] Add. Sense: Not ready to ready change, medium may have
  changed [  117.549203] sd 6:0:0:0: [sdb] CDB: 
  [  117.549205] Read(10): 28 00 00 02 c9 00 00 00 f0 00
  [  117.549212] end_request: I/O error, dev sdb, sector 182528
  [  117.549218] Buffer I/O error on device sdb1, logical block 22560
  [  117.549225] Buffer I/O error on device sdb1, logical block 22561
  [  117.549228] Buffer I/O error on device sdb1, logical block 22562
  [  117.549231] Buffer I/O error on device sdb1, logical block 22563
  [  117.549233] Buffer I/O error on device sdb1, logical block 22564
  [  117.549235] Buffer I/O error on device sdb1, logical block 22565
  [  117.549238] Buffer I/O error on device sdb1, logical block 22566
  [  117.549240] Buffer I/O error on device sdb1, logical block 22567
  [  117.549243] Buffer I/O error on device sdb1, logical block 22568
  [  

Re: [PATCH v3 13/17] arcmsr: fix ioctl data read/write error for adapter type C

[Ching Huang]

On Tue, 2014-08-26 at 15:20 +0200, Tomas Henzl wrote:
 On 08/26/2014 10:27 PM, Ching Huang wrote:
  On Mon, 2014-08-25 at 12:29 +0200, Tomas Henzl wrote:
  On 08/25/2014 07:59 PM, Ching Huang wrote:
  On Fri, 2014-08-22 at 18:00 +0200, Tomas Henzl wrote:
  On 08/19/2014 09:17 AM, Ching Huang wrote:
  From: Ching Huang ching2...@areca.com.tw
 
  Rewrite ioctl entry and its relate function.
  This patch fix ioctl data read/write error and change data I/O access 
  from byte to Dword.
 
  Signed-off-by: Ching Huang ching2...@areca.com.tw
  ---
 
  diff -uprN a/drivers/scsi/arcmsr/arcmsr_attr.c 
  b/drivers/scsi/arcmsr/arcmsr_attr.c
  --- a/drivers/scsi/arcmsr/arcmsr_attr.c 2014-02-06 17:47:24.0 
  +0800
  +++ b/drivers/scsi/arcmsr/arcmsr_attr.c 2014-04-29 17:10:42.0 
  +0800
  @@ -70,40 +70,75 @@ static ssize_t arcmsr_sysfs_iop_message_
  struct AdapterControlBlock *acb = (struct AdapterControlBlock 
  *) host-hostdata;
  uint8_t *pQbuffer,*ptmpQbuffer;
  int32_t allxfer_len = 0;
  +   unsigned long flags;
   
  if (!capable(CAP_SYS_ADMIN))
  return -EACCES;
   
  /* do message unit read. */
  ptmpQbuffer = (uint8_t *)buf;
  -   while ((acb-rqbuf_firstindex != acb-rqbuf_lastindex)
  -(allxfer_len  1031)) {
  +   spin_lock_irqsave(acb-rqbuffer_lock, flags);
  +   if (acb-rqbuf_firstindex != acb-rqbuf_lastindex) {
  Hi - does this condition (acb-rqbuf_firstindex == acb-rqbuf_lastindex) 
  mean we could just release 
  the spinlock and return ?
   
  NO. We have to check the input buffer that may have message data come
  from IOP.
  pQbuffer = acb-rqbuffer[acb-rqbuf_firstindex];
  -   memcpy(ptmpQbuffer, pQbuffer, 1);
  -   acb-rqbuf_firstindex++;
  -   acb-rqbuf_firstindex %= ARCMSR_MAX_QBUFFER;
  -   ptmpQbuffer++;
  -   allxfer_len++;
  +   if (acb-rqbuf_firstindex  acb-rqbuf_lastindex) {
  +   if ((ARCMSR_MAX_QBUFFER - 
  acb-rqbuf_firstindex) = 1032) {
  +   memcpy(ptmpQbuffer, pQbuffer, 1032);
  +   acb-rqbuf_firstindex += 1032;
  +   acb-rqbuf_firstindex %= 
  ARCMSR_MAX_QBUFFER;
  +   allxfer_len = 1032;
  +   } else {
  +   if (((ARCMSR_MAX_QBUFFER - 
  acb-rqbuf_firstindex)
  +   + acb-rqbuf_lastindex)  1032) 
  {
  +   memcpy(ptmpQbuffer, pQbuffer,
  +   ARCMSR_MAX_QBUFFER
  +   - 
  acb-rqbuf_firstindex);
  +   ptmpQbuffer += 
  ARCMSR_MAX_QBUFFER
  +   - acb-rqbuf_firstindex;
  +   memcpy(ptmpQbuffer, 
  acb-rqbuffer, 1032
  +   - (ARCMSR_MAX_QBUFFER -
  +   acb-rqbuf_firstindex));
  This code looks like you were copying some data from a ring buffer,
  in that case - shouldn't be acb-rqbuf_lastindex used instead of 
  firstindex?
 
  Yes, there copying data from a ring buffer. firstindex and lastindex are
  bad name. For readability, I rename the firstindex to getIndex,
  lastindex to putIndex. 
  My comment is not about names, but in this path '(ARCMSR_MAX_QBUFFER - 
  acb-rqbuf_firstindex)+ acb-rqbuf_lastindex)  1032)'
  you copy something twice and in both cases the 'firstindex' is used and 
  never the 'lastindex'.
  Is this correct?
  The firstindex is a get index and lastindex is a put index of a ring buffer.
  At here, firstindex  lastindex, so the data remain in buffer are 
  (ARCMSR_MAX_QBUFFER - acb-rqbuf_firstindex)+ acb-rqbuf_lastindex
 
 Yes, it's correct, I misinterpreted the from value with the amount of bytes 
 to copy.
 But well it's also still overcomplicated and I believe that a copy like this 
 could be
 rearranged with just few lines of code as a result - have you looked at the 
 code I sent?
 
 Let's go with this patch as it is otherwise we will never end, repost is not 
 needed because 
 of this and also not because of arcmsr_Read_iop_rqbuffer_in_DWORD.
 
 I'll continue with reviewing the remaining patches.
 
 tomas
 
I have test the code you sent. It works.
I will modify the code by your idea, then send the patch.

Thanks,
Ching
 
  What does the 1032 mean is that a hw. limit, actually could you explain 
  the code 
  should do? Maybe I'm just wrong with my assumptions.
  1032 is the API data buffer limitation.
  Thanks,
  Tomas
 
  +   acb-rqbuf_firstindex = 1032 -
  +   (ARCMSR_MAX_QBUFFER -
  +   acb-rqbuf_firstindex);
  

Re: [PATCH v3 13/17] arcmsr: fix ioctl data read/write error for adapter type C

[Tomas Henzl]

On 08/27/2014 10:19 PM, Ching Huang wrote:
 On Tue, 2014-08-26 at 15:20 +0200, Tomas Henzl wrote:
 On 08/26/2014 10:27 PM, Ching Huang wrote:
 On Mon, 2014-08-25 at 12:29 +0200, Tomas Henzl wrote:
 On 08/25/2014 07:59 PM, Ching Huang wrote:
 On Fri, 2014-08-22 at 18:00 +0200, Tomas Henzl wrote:
 On 08/19/2014 09:17 AM, Ching Huang wrote:
 From: Ching Huang ching2...@areca.com.tw

 Rewrite ioctl entry and its relate function.
 This patch fix ioctl data read/write error and change data I/O access 
 from byte to Dword.

 Signed-off-by: Ching Huang ching2...@areca.com.tw
 ---

 diff -uprN a/drivers/scsi/arcmsr/arcmsr_attr.c 
 b/drivers/scsi/arcmsr/arcmsr_attr.c
 --- a/drivers/scsi/arcmsr/arcmsr_attr.c 2014-02-06 17:47:24.0 
 +0800
 +++ b/drivers/scsi/arcmsr/arcmsr_attr.c 2014-04-29 17:10:42.0 
 +0800
 @@ -70,40 +70,75 @@ static ssize_t arcmsr_sysfs_iop_message_
 struct AdapterControlBlock *acb = (struct AdapterControlBlock 
 *) host-hostdata;
 uint8_t *pQbuffer,*ptmpQbuffer;
 int32_t allxfer_len = 0;
 +   unsigned long flags;
  
 if (!capable(CAP_SYS_ADMIN))
 return -EACCES;
  
 /* do message unit read. */
 ptmpQbuffer = (uint8_t *)buf;
 -   while ((acb-rqbuf_firstindex != acb-rqbuf_lastindex)
 -(allxfer_len  1031)) {
 +   spin_lock_irqsave(acb-rqbuffer_lock, flags);
 +   if (acb-rqbuf_firstindex != acb-rqbuf_lastindex) {
 Hi - does this condition (acb-rqbuf_firstindex == acb-rqbuf_lastindex) 
 mean we could just release 
 the spinlock and return ?
  
 NO. We have to check the input buffer that may have message data come
 from IOP.
 pQbuffer = acb-rqbuffer[acb-rqbuf_firstindex];
 -   memcpy(ptmpQbuffer, pQbuffer, 1);
 -   acb-rqbuf_firstindex++;
 -   acb-rqbuf_firstindex %= ARCMSR_MAX_QBUFFER;
 -   ptmpQbuffer++;
 -   allxfer_len++;
 +   if (acb-rqbuf_firstindex  acb-rqbuf_lastindex) {
 +   if ((ARCMSR_MAX_QBUFFER - 
 acb-rqbuf_firstindex) = 1032) {
 +   memcpy(ptmpQbuffer, pQbuffer, 1032);
 +   acb-rqbuf_firstindex += 1032;
 +   acb-rqbuf_firstindex %= 
 ARCMSR_MAX_QBUFFER;
 +   allxfer_len = 1032;
 +   } else {
 +   if (((ARCMSR_MAX_QBUFFER - 
 acb-rqbuf_firstindex)
 +   + acb-rqbuf_lastindex)  1032) 
 {
 +   memcpy(ptmpQbuffer, pQbuffer,
 +   ARCMSR_MAX_QBUFFER
 +   - 
 acb-rqbuf_firstindex);
 +   ptmpQbuffer += 
 ARCMSR_MAX_QBUFFER
 +   - acb-rqbuf_firstindex;
 +   memcpy(ptmpQbuffer, 
 acb-rqbuffer, 1032
 +   - (ARCMSR_MAX_QBUFFER -
 +   acb-rqbuf_firstindex));
 This code looks like you were copying some data from a ring buffer,
 in that case - shouldn't be acb-rqbuf_lastindex used instead of 
 firstindex?

 Yes, there copying data from a ring buffer. firstindex and lastindex are
 bad name. For readability, I rename the firstindex to getIndex,
 lastindex to putIndex. 
 My comment is not about names, but in this path '(ARCMSR_MAX_QBUFFER - 
 acb-rqbuf_firstindex)+ acb-rqbuf_lastindex)  1032)'
 you copy something twice and in both cases the 'firstindex' is used and 
 never the 'lastindex'.
 Is this correct?
 The firstindex is a get index and lastindex is a put index of a ring buffer.
 At here, firstindex  lastindex, so the data remain in buffer are 
 (ARCMSR_MAX_QBUFFER - acb-rqbuf_firstindex)+ acb-rqbuf_lastindex
 Yes, it's correct, I misinterpreted the from value with the amount of bytes 
 to copy.
 But well it's also still overcomplicated and I believe that a copy like this 
 could be
 rearranged with just few lines of code as a result - have you looked at the 
 code I sent?

 Let's go with this patch as it is otherwise we will never end, repost is not 
 needed because 
 of this and also not because of arcmsr_Read_iop_rqbuffer_in_DWORD.

 I'll continue with reviewing the remaining patches.

 tomas

 I have test the code you sent. It works.
 I will modify the code by your idea, then send the patch.

I think that after so many repost, and because it is not a fix, wait till we 
get this series in
and post a new patch later. 
Btw. a similar copying is in arcmsr_iop_message_xfer too, and whet you want 
rename the fields
in your ring buffer, please use the more usual names 'head+tail'.

Conclusion - post nothing right now, let the changes go in in a new patch.

tomash



 Thanks,
 Ching
 What does the 1032 mean is that a hw. limit, actually could you explain 
 the code 
 should 

[PATCH RESEND] bnx2fc: do not add shared skbs to the fcoe_rx_list

[Maurizio Lombardi]

In some cases, the fcoe_rx_list may contains multiple instances
of the same skb (the so called shared skbs).

the bnx2fc_l2_rcv thread is a loop that extracts a skb from the list,
modifies (and destroys) its content and the proceed to the next one.
The problem is that if the skb is shared, the remaining instances will
be corrupted.

The solution is to use skb_share_check() before adding the skb to the
fcoe_rx_list.

[ 6286.808725] [ cut here ]
[ 6286.808729] WARNING: at include/scsi/fc_frame.h:173 
bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc]()
[ 6286.808748] Modules linked in: bnx2x(-) mdio dm_service_time bnx2fc cnic uio 
fcoe libfcoe 8021q garp stp mrp libfc llc scsi_transport_fc scsi_tgt sg 
iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crct10dif_pclmul 
crc32_pclmul crc32c_intel e1000e ghash_clmulni_intel aesni_intel lrw gf128mul 
glue_helper ablk_helper ptp cryptd hpilo serio_raw hpwdt lpc_ich pps_core 
ipmi_si pcspkr mfd_core ipmi_msghandler shpchp pcc_cpufreq mperf nfsd 
auth_rpcgss nfs_acl lockd sunrpc dm_multipath xfs libcrc32c ata_generic 
pata_acpi sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect 
sysimgblt i2c_algo_bit ata_piix drm_kms_helper ttm drm libata i2c_core hpsa 
dm_mirror dm_region_hash dm_log dm_mod [last unloaded: mdio]
[ 6286.808750] CPU: 3 PID: 1304 Comm: bnx2fc_l2_threa Not tainted 
3.10.0-121.el7.x86_64 #1
[ 6286.808750] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013
[ 6286.808752]   0b36e715 8800deba1e00 
815ec0ba
[ 6286.808753]  8800deba1e38 8105dee1 a05618c0 
8801e4c81888
[ 6286.808754]  e8663868 8801f402b180 8801f56bc000 
8800deba1e48
[ 6286.808754] Call Trace:
[ 6286.808759]  [815ec0ba] dump_stack+0x19/0x1b
[ 6286.808762]  [8105dee1] warn_slowpath_common+0x61/0x80
[ 6286.808763]  [8105e00a] warn_slowpath_null+0x1a/0x20
[ 6286.808765]  [a054f415] bnx2fc_l2_rcv_thread+0x425/0x450 [bnx2fc]
[ 6286.808767]  [a054eff0] ? bnx2fc_disable+0x90/0x90 [bnx2fc]
[ 6286.808769]  [81085aef] kthread+0xcf/0xe0
[ 6286.808770]  [81085a20] ? kthread_create_on_node+0x140/0x140
[ 6286.808772]  [815fc76c] ret_from_fork+0x7c/0xb0
[ 6286.808773]  [81085a20] ? kthread_create_on_node+0x140/0x140
[ 6286.808774] ---[ end trace c6cdb939184ccb4e ]---

Signed-off-by: Maurizio Lombardi mlomb...@redhat.com
---
 drivers/scsi/bnx2fc/bnx2fc_fcoe.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c 
b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index 79e5c94..72533c5 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -412,6 +412,7 @@ static int bnx2fc_rcv(struct sk_buff *skb, struct 
net_device *dev,
struct fc_frame_header *fh;
struct fcoe_rcv_info *fr;
struct fcoe_percpu_s *bg;
+   struct sk_buff *tmp_skb;
unsigned short oxid;
 
interface = container_of(ptype, struct bnx2fc_interface,
@@ -424,6 +425,12 @@ static int bnx2fc_rcv(struct sk_buff *skb, struct 
net_device *dev,
goto err;
}
 
+   tmp_skb = skb_share_check(skb, GFP_ATOMIC);
+   if (!tmp_skb)
+   goto err;
+
+   skb = tmp_skb;
+
if (unlikely(eth_hdr(skb)-h_proto != htons(ETH_P_FCOE))) {
printk(KERN_ERR PFX bnx2fc_rcv: Wrong FC type frame\n);
goto err;
-- 
Maurizio Lombardi

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] be2iscsi: Fix the sparse warning introduced in previous submission

[Hannes Reinecke]

On 08/08/2014 06:59 AM, Jay Kallickal wrote:

From: Jayamohan Kallickal jayamohan.kallic...@emulex.com

  commit 73af08e11c6638e2abd6b1fa13cdab58c2bbdbf8
  Author: Jayamohan Kallickal jayamohan.kallic...@emulex.com
  Date:   Mon May 5 21:41:26 2014 -0400

   be2iscsi: Fix interrupt Coalescing mechanism.

Signed-off-by: John Soni Jose sony.joh...@emulex.com
Signed-off-by: Jayamohan Kallickal jayamohan.kallic...@emulex.com
---
  drivers/scsi/be2iscsi/be_cmds.h | 14 +++---
  1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/be2iscsi/be_cmds.h b/drivers/scsi/be2iscsi/be_cmds.h
index cc7405c..4e8cb61 100644
--- a/drivers/scsi/be2iscsi/be_cmds.h
+++ b/drivers/scsi/be2iscsi/be_cmds.h
@@ -26,9 +26,9 @@
   * The commands are serviced by the ARM processor in the OneConnect's MPU.
   */
  struct be_sge {
-   u32 pa_lo;
-   u32 pa_hi;
-   u32 len;
+   __le32 pa_lo;
+   __le32 pa_hi;
+   __le32 len;
  };

  #define MCC_WRB_SGE_CNT_SHIFT 3   /* bits 3 - 7 of dword 0 */
@@ -624,11 +624,11 @@ static inline struct be_sge *nonembedded_sgl(struct 
be_mcc_wrb *wrb)
  / Modify EQ Delay ***/
  struct be_cmd_req_modify_eq_delay {
struct be_cmd_req_hdr hdr;
-   u32 num_eq;
+   __le32 num_eq;
struct {
-   u32 eq_id;
-   u32 phase;
-   u32 delay_multiplier;
+   __le32 eq_id;
+   __le32 phase;
+   __le32 delay_multiplier;
} delay[MAX_CPUS];
  } __packed;



Reviewed-by: Hannes Reinecke h...@suse.de

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] be2iscsi: Fix the copyright year

[Hannes Reinecke]

On 08/08/2014 06:59 AM, Jay Kallickal wrote:

From: Jayamohan Kallickal jayamohan.kallic...@emulex.com

  Change the copyright year to 2014

Signed-off-by: John Soni Jose sony.joh...@emulex.com
Signed-off-by: Jayamohan Kallickal jayamohan.kallic...@emulex.com
---
  drivers/scsi/be2iscsi/be.h   | 2 +-
  drivers/scsi/be2iscsi/be_cmds.c  | 2 +-
  drivers/scsi/be2iscsi/be_cmds.h  | 2 +-
  drivers/scsi/be2iscsi/be_iscsi.c | 2 +-
  drivers/scsi/be2iscsi/be_iscsi.h | 2 +-
  drivers/scsi/be2iscsi/be_main.c  | 2 +-
  drivers/scsi/be2iscsi/be_main.h  | 2 +-
  drivers/scsi/be2iscsi/be_mgmt.c  | 2 +-
  drivers/scsi/be2iscsi/be_mgmt.h  | 2 +-
  9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/be2iscsi/be.h b/drivers/scsi/be2iscsi/be.h
index 860f527..81e83a6 100644
--- a/drivers/scsi/be2iscsi/be.h
+++ b/drivers/scsi/be2iscsi/be.h
@@ -1,5 +1,5 @@
  /**
- * Copyright (C) 2005 - 2013 Emulex
+ * Copyright (C) 2005 - 2014 Emulex
   * All rights reserved.
   *
   * This program is free software; you can redistribute it and/or
diff --git a/drivers/scsi/be2iscsi/be_cmds.c b/drivers/scsi/be2iscsi/be_cmds.c
index 1432ed5..ea4477f 100644
--- a/drivers/scsi/be2iscsi/be_cmds.c
+++ b/drivers/scsi/be2iscsi/be_cmds.c
@@ -1,5 +1,5 @@
  /**
- * Copyright (C) 2005 - 2013 Emulex
+ * Copyright (C) 2005 - 2014 Emulex
   * All rights reserved.
   *
   * This program is free software; you can redistribute it and/or
diff --git a/drivers/scsi/be2iscsi/be_cmds.h b/drivers/scsi/be2iscsi/be_cmds.h
index 4e8cb61..ccda0b6 100644
--- a/drivers/scsi/be2iscsi/be_cmds.h
+++ b/drivers/scsi/be2iscsi/be_cmds.h
@@ -1,5 +1,5 @@
  /**
- * Copyright (C) 2005 - 2013 Emulex
+ * Copyright (C) 2005 - 2014 Emulex
   * All rights reserved.
   *
   * This program is free software; you can redistribute it and/or
diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c
index 8616281..e25203e 100644
--- a/drivers/scsi/be2iscsi/be_iscsi.c
+++ b/drivers/scsi/be2iscsi/be_iscsi.c
@@ -1,5 +1,5 @@
  /**
- * Copyright (C) 2005 - 2013 Emulex
+ * Copyright (C) 2005 - 2014 Emulex
   * All rights reserved.
   *
   * This program is free software; you can redistribute it and/or
diff --git a/drivers/scsi/be2iscsi/be_iscsi.h b/drivers/scsi/be2iscsi/be_iscsi.h
index 31ddc84..e0b3b2d 100644
--- a/drivers/scsi/be2iscsi/be_iscsi.h
+++ b/drivers/scsi/be2iscsi/be_iscsi.h
@@ -1,5 +1,5 @@
  /**
- * Copyright (C) 2005 - 2013 Emulex
+ * Copyright (C) 2005 - 2014 Emulex
   * All rights reserved.
   *
   * This program is free software; you can redistribute it and/or
diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 56467df..d6465ed 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -1,5 +1,5 @@
  /**
- * Copyright (C) 2005 - 2013 Emulex
+ * Copyright (C) 2005 - 2014 Emulex
   * All rights reserved.
   *
   * This program is free software; you can redistribute it and/or
diff --git a/drivers/scsi/be2iscsi/be_main.h b/drivers/scsi/be2iscsi/be_main.h
index 9ceab42..0ca9d2d 100644
--- a/drivers/scsi/be2iscsi/be_main.h
+++ b/drivers/scsi/be2iscsi/be_main.h
@@ -1,5 +1,5 @@
  /**
- * Copyright (C) 2005 - 2013 Emulex
+ * Copyright (C) 2005 - 2014 Emulex
   * All rights reserved.
   *
   * This program is free software; you can redistribute it and/or
diff --git a/drivers/scsi/be2iscsi/be_mgmt.c b/drivers/scsi/be2iscsi/be_mgmt.c
index a3e5648..785deb3 100644
--- a/drivers/scsi/be2iscsi/be_mgmt.c
+++ b/drivers/scsi/be2iscsi/be_mgmt.c
@@ -1,5 +1,5 @@
  /**
- * Copyright (C) 2005 - 2013 Emulex
+ * Copyright (C) 2005 - 2014 Emulex
   * All rights reserved.
   *
   * This program is free software; you can redistribute it and/or
diff --git a/drivers/scsi/be2iscsi/be_mgmt.h b/drivers/scsi/be2iscsi/be_mgmt.h
index 24a8fc5..bd81446 100644
--- a/drivers/scsi/be2iscsi/be_mgmt.h
+++ b/drivers/scsi/be2iscsi/be_mgmt.h
@@ -1,5 +1,5 @@
  /**
- * Copyright (C) 2005 - 2013 Emulex
+ * Copyright (C) 2005 - 2014 Emulex
   * All rights reserved.
   *
   * This program is free software; you can redistribute it and/or


Reviewed-by: Hannes Reinecke h...@suse.de

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/5] be2iscsi: Fix processing CQE before connection resources are freed

[Hannes Reinecke]

On 08/08/2014 07:00 AM, Jay Kallickal wrote:

From: Jayamohan Kallickal jayamohan.kallic...@emulex.com

  Driver should process the completion queue entries before a connection
  resources are freed. While running mixed traffic due to latency, driver
  processes the CQE after the connection resources are freed. This fix
  processes all the completion queue before the connection resources are
  freed.

Signed-off-by: John Soni Jose sony.joh...@emulex.com
Signed-off-by: Jayamohan Kallickal jayamohan.kallic...@emulex.com
---
  drivers/scsi/be2iscsi/be_iscsi.c | 29 +
  drivers/scsi/be2iscsi/be_main.c  | 15 ++-
  drivers/scsi/be2iscsi/be_main.h  |  3 +++
  3 files changed, 46 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/be2iscsi/be_iscsi.c b/drivers/scsi/be2iscsi/be_iscsi.c
index e25203e..b7391a3 100644
--- a/drivers/scsi/be2iscsi/be_iscsi.c
+++ b/drivers/scsi/be2iscsi/be_iscsi.c
@@ -1274,6 +1274,31 @@ int beiscsi_ep_poll(struct iscsi_endpoint *ep, int 
timeout_ms)
  }

  /**
+ * beiscsi_flush_cq()- Flush the CQ created.
+ * @phba: ptr device priv structure.
+ *
+ * Before the connection resource are freed flush
+ * all the CQ enteries
+ **/
+static void beiscsi_flush_cq(struct beiscsi_hba *phba)
+{
+   uint16_t i;
+   struct be_eq_obj *pbe_eq;
+   struct hwi_controller *phwi_ctrlr;
+   struct hwi_context_memory *phwi_context;
+
+   phwi_ctrlr = phba-phwi_ctrlr;
+   phwi_context = phwi_ctrlr-phwi_ctxt;
+
+   for (i = 0; i  phba-num_cpus; i++) {
+   pbe_eq = phwi_context-be_eq[i];
+   blk_iopoll_disable(pbe_eq-iopoll);
+   beiscsi_process_cq(pbe_eq);
+   blk_iopoll_enable(pbe_eq-iopoll);
+   }
+}
+
+/**
   * beiscsi_close_conn - Upload the  connection
   * @ep: The iscsi endpoint
   * @flag: The type of connection closure
@@ -1294,6 +1319,10 @@ static int beiscsi_close_conn(struct  beiscsi_endpoint 
*beiscsi_ep, int flag)
}

ret = beiscsi_mccq_compl(phba, tag, NULL, NULL);
+
+   /* Flush the CQ entries */
+   beiscsi_flush_cq(phba);
+
return ret;
  }

diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index 8f9f625..cbc9fc2 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -2068,7 +2068,7 @@ static void  beiscsi_process_mcc_isr(struct beiscsi_hba 
*phba)
   * return
   * Number of Completion Entries processed.
   **/
-static unsigned int beiscsi_process_cq(struct be_eq_obj *pbe_eq)
+unsigned int beiscsi_process_cq(struct be_eq_obj *pbe_eq)
  {
struct be_queue_info *cq;
struct sol_cqe *sol;
@@ -2110,6 +2110,18 @@ static unsigned int beiscsi_process_cq(struct be_eq_obj 
*pbe_eq)

cri_index = BE_GET_CRI_FROM_CID(cid);
ep = phba-ep_array[cri_index];
+
+   if (ep == NULL) {
+   /* connection has already been freed
+* just move on to next one
+*/
+   beiscsi_log(phba, KERN_WARNING,
+   BEISCSI_LOG_INIT,
+   BM_%d : proc cqe of disconn ep: cid %d\n,
+   cid);
+   goto proc_next_cqe;
+   }
+
beiscsi_ep = ep-dd_data;
beiscsi_conn = beiscsi_ep-conn;

@@ -2219,6 +2231,7 @@ static unsigned int beiscsi_process_cq(struct be_eq_obj 
*pbe_eq)
break;
}

+proc_next_cqe:
AMAP_SET_BITS(struct amap_sol_cqe, valid, sol, 0);
queue_tail_inc(cq);
sol = queue_tail_node(cq);
diff --git a/drivers/scsi/be2iscsi/be_main.h b/drivers/scsi/be2iscsi/be_main.h
index 1e3428a..5f8b0fc 100644
--- a/drivers/scsi/be2iscsi/be_main.h
+++ b/drivers/scsi/be2iscsi/be_main.h
@@ -840,6 +840,9 @@ void beiscsi_free_mgmt_task_handles(struct beiscsi_conn 
*beiscsi_conn,
  void hwi_ring_cq_db(struct beiscsi_hba *phba,
 unsigned int id, unsigned int num_processed,
 unsigned char rearm, unsigned char event);
+
+unsigned int beiscsi_process_cq(struct be_eq_obj *pbe_eq);
+
  static inline bool beiscsi_error(struct beiscsi_hba *phba)
  {
return phba-ue_detected || phba-fw_timeout;


Reviewed-by: Hannes Reinecke h...@suse.de

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] be2iscsi: Fix updating the boot enteries in sysfs

[Hannes Reinecke]

On 08/08/2014 07:00 AM, Jay Kallickal wrote:

From: Jayamohan Kallickal jayamohan.kallic...@emulex.com

  During port async event driver should check if there is any boot target
  configured on the adapter. Update sysfs enteries with the boot target
  parameters.

Signed-off-by: Minh Tran minhduc.t...@emulex.com
Signed-off-by: John Soni Jose sony.joh...@emulex.com
Signed-off-by: Jayamohan Kallickal jayamohan.kallic...@emulex.com
---
  drivers/scsi/be2iscsi/be_cmds.c | 38 --
  drivers/scsi/be2iscsi/be_cmds.h |  8 
  drivers/scsi/be2iscsi/be_main.c | 17 +
  drivers/scsi/be2iscsi/be_main.h |  1 +
  4 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/be2iscsi/be_cmds.c b/drivers/scsi/be2iscsi/be_cmds.c
index ea4477f..80d97f3 100644
--- a/drivers/scsi/be2iscsi/be_cmds.c
+++ b/drivers/scsi/be2iscsi/be_cmds.c
@@ -275,6 +275,19 @@ bool is_link_state_evt(u32 trailer)
  ASYNC_EVENT_CODE_LINK_STATE);
  }

+static bool is_iscsi_evt(u32 trailer)
+{
+   return ((trailer  ASYNC_TRAILER_EVENT_CODE_SHIFT) 
+ ASYNC_TRAILER_EVENT_CODE_MASK) ==
+ ASYNC_EVENT_CODE_ISCSI;
+}
+
+static int iscsi_evt_type(u32 trailer)
+{
+   return (trailer  ASYNC_TRAILER_EVENT_TYPE_SHIFT) 
+ASYNC_TRAILER_EVENT_TYPE_MASK;
+}
+
  static inline bool be_mcc_compl_is_new(struct be_mcc_compl *compl)
  {
if (compl-flags != 0) {
@@ -438,7 +451,7 @@ void beiscsi_async_link_state_process(struct beiscsi_hba 
*phba,
} else if ((evt-port_link_status  ASYNC_EVENT_LINK_UP) ||
((evt-port_link_status  ASYNC_EVENT_LOGICAL) 
 (evt-port_fault == BEISCSI_PHY_LINK_FAULT_NONE))) {
-   phba-state = BE_ADAPTER_LINK_UP;
+   phba-state = BE_ADAPTER_LINK_UP | BE_ADAPTER_CHECK_BOOT;

beiscsi_log(phba, KERN_ERR,
BEISCSI_LOG_CONFIG | BEISCSI_LOG_INIT,
@@ -461,7 +474,28 @@ int beiscsi_process_mcc(struct beiscsi_hba *phba)
/* Interpret compl as a async link evt */
beiscsi_async_link_state_process(phba,
   (struct be_async_event_link_state *) compl);
-   else
+   else if (is_iscsi_evt(compl-flags)) {
+   switch (iscsi_evt_type(compl-flags)) {
+   case ASYNC_EVENT_NEW_ISCSI_TGT_DISC:
+   case ASYNC_EVENT_NEW_ISCSI_CONN:
+   case ASYNC_EVENT_NEW_TCP_CONN:
+   phba-state |= BE_ADAPTER_CHECK_BOOT;
+   beiscsi_log(phba, KERN_ERR,
+   BEISCSI_LOG_CONFIG |
+   BEISCSI_LOG_MBOX,
+   BC_%d : Async iscsi Event,
+flags handled = 0x%08x\n,
+   compl-flags);
+   break;
+   default:
+   beiscsi_log(phba, KERN_ERR,
+   BEISCSI_LOG_CONFIG |
+   BEISCSI_LOG_MBOX,
+   BC_%d : Unsupported Async
+Event, flags = 0x%08x\n,
+   compl-flags);
+   }
+   } else
beiscsi_log(phba, KERN_ERR,
BEISCSI_LOG_CONFIG |
BEISCSI_LOG_MBOX,
diff --git a/drivers/scsi/be2iscsi/be_cmds.h b/drivers/scsi/be2iscsi/be_cmds.h
index ccda0b6..9889743 100644
--- a/drivers/scsi/be2iscsi/be_cmds.h
+++ b/drivers/scsi/be2iscsi/be_cmds.h
@@ -118,6 +118,14 @@ struct be_mcc_compl {
  #define ASYNC_TRAILER_EVENT_CODE_SHIFT8   /* bits 8 - 15 */
  #define ASYNC_TRAILER_EVENT_CODE_MASK 0xFF
  #define ASYNC_EVENT_CODE_LINK_STATE   0x1
+#define ASYNC_EVENT_CODE_ISCSI 0x4
+
+#define ASYNC_TRAILER_EVENT_TYPE_SHIFT 16  /* bits 16 - 23 */
+#define ASYNC_TRAILER_EVENT_TYPE_MASK  0xF
+#define ASYNC_EVENT_NEW_ISCSI_TGT_DISC 0x4
+#define ASYNC_EVENT_NEW_ISCSI_CONN 0x5
+#define ASYNC_EVENT_NEW_TCP_CONN   0x7
+
  struct be_async_event_trailer {
u32 code;
  };
diff --git a/drivers/scsi/be2iscsi/be_main.c b/drivers/scsi/be2iscsi/be_main.c
index d6465ed..8f9f625 100644
--- a/drivers/scsi/be2iscsi/be_main.c
+++ b/drivers/scsi/be2iscsi/be_main.c
@@ -4379,6 +4379,10 @@ static int beiscsi_setup_boot_info(struct beiscsi_hba 
*phba)
  {
struct iscsi_boot_kobj *boot_kobj;

+   

Re: [PATCH 5/5] be2iscsi: Bump the driver version

[Hannes Reinecke]

On 08/08/2014 07:00 AM, Jay Kallickal wrote:

From: Jayamohan Kallickal jayamohan.kallic...@emulex.com

  Bump the driver version

Signed-off-by: John Soni Jose sony.joh...@emulex.com
Signed-off-by: Jayamohan Kallickal jayamohan.kallic...@emulex.com
---
  drivers/scsi/be2iscsi/be_main.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/be2iscsi/be_main.h b/drivers/scsi/be2iscsi/be_main.h
index 5f8b0fc..3605631 100644
--- a/drivers/scsi/be2iscsi/be_main.h
+++ b/drivers/scsi/be2iscsi/be_main.h
@@ -36,7 +36,7 @@
  #include scsi/scsi_transport_iscsi.h

  #define DRV_NAME  be2iscsi
-#define BUILD_STR  10.2.273.0
+#define BUILD_STR  10.4.74.0
  #define BE_NAME   Emulex OneConnect \
Open-iSCSI Driver version BUILD_STR
  #define DRV_DESC  BE_NAME   Driver


Reviewed-by: Hannes Reinecke h...@suse.de

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 01/10] scsi/constants: Cleanup printk message in __scsi_print_sense()

[Hannes Reinecke]

On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:

A device name is output like sda: Sense Key : Medium Error [current]
in __scsi_print_sense(), but it should be [sda] Sense Key : Medium Error
[current] because other printk messages output a device name like [sda] foo.

Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Hannes Reinecke h...@suse.de
Cc: Doug Gilbert dgilb...@interlog.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
  drivers/scsi/constants.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index c6a7a4a..a0e8159 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -1470,7 +1470,7 @@ void __scsi_print_sense(struct scsi_device *sdev, const 
char *name,
return;
}

-   sdev_printk(KERN_INFO, sdev, %s: Sense Key : %s %s%s\n, name,
+   sdev_printk(KERN_INFO, sdev, [%s] Sense Key : %s %s%s\n, name,
   scsi_sense_key_string(sshdr.sense_key),
   scsi_sense_type_string(sshdr),
   scsi_sense_format_string(sshdr));

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

A similar fix is already present in my next version of the scsi 
logging patchset.


Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 02/10] scsi/constants: Cleanup printk message in scsi_decode_sense_extras()

[Hannes Reinecke]

On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:

If sense_flags and fixed_valid are zero, the kernel does not need to
output a printk message. So, if those conditions are met, it just returns.

Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Hannes Reinecke h...@suse.de
Cc: Doug Gilbert dgilb...@interlog.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
  drivers/scsi/constants.c |3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index a0e8159..9c38b8d 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -1438,6 +1438,9 @@ scsi_decode_sense_extras(struct scsi_device *sdev, const 
char *name,
sense_flags |= ucp[3]  0xe0;
}

+   if (!sense_flags  !fixed_valid)
+   return;
+
res = 0;
memset(buff, 0, sizeof(buff));
blen = sizeof(buff) - 1;

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

scsi_decode_sense_extras() is utterly weird, as it only decodes 
tape-specific sense extras. Seeing that 'st' and 'osst' already 
contains code to handle those cases we should remove this function 
altogether, as it doesn't serve any purpose.


Has been removed with my next scsi logging update, so this patch is 
not applicable anymore.


Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 04/10] scsi/constants: Cleanup printk message in scsi_dump_sense_buffer()

[Hannes Reinecke]

On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:

Unrecognized sense data should be output after linebuf is filled because
[%s] Unrecognized sense data (in hex): %s message is output many times in
loop.

Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Hannes Reinecke h...@suse.de
Cc: Doug Gilbert dgilb...@interlog.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
  drivers/scsi/constants.c |   13 +
  1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 5956d4d..6fad6b4 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -1385,16 +1385,13 @@ EXPORT_SYMBOL(scsi_print_sense_hdr);

  static void
  scsi_dump_sense_buffer(struct scsi_device *sdev, const char *prefix,
-  const unsigned char *sense_buffer, int sense_len,
-  struct scsi_sense_hdr *sshdr)
+  const unsigned char *sense_buffer, int sense_len)
  {
char linebuf[128];
int i, linelen, remaining;

if (sense_len  32)
sense_len = 32;
-   sdev_printk(KERN_INFO, sdev,
-   [%s] Unrecognized sense data (in hex):, prefix);

remaining = sense_len;
for (i = 0; i  sense_len; i += 16) {
@@ -1403,9 +1400,10 @@ scsi_dump_sense_buffer(struct scsi_device *sdev, const 
char *prefix,

hex_dump_to_buffer(sense_buffer + i, linelen, 16, 1,
   linebuf, sizeof(linebuf), false);
-   sdev_printk(KERN_INFO, sdev, [%s] Sense: %s\n,
-   prefix, linebuf);
}
+   sdev_printk(KERN_INFO, sdev,
+   [%s] Unrecognized sense data (in hex): %s,
+   prefix, linebuf);
  }

  static void
@@ -1467,8 +1465,7 @@ void __scsi_print_sense(struct scsi_device *sdev, const 
char *name,

if (!scsi_normalize_sense(sense_buffer, sense_len, sshdr)) {
/* this may be SCSI-1 sense data */
-   scsi_dump_sense_buffer(sdev, name, sense_buffer,
-  sense_len, sshdr);
+   scsi_dump_sense_buffer(sdev, name, sense_buffer, sense_len);
return;
}


--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


As discussed this patch is invalid.

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 03/10] scsi/constants: Cleanup printk message in __scsi_print_command()

[Hannes Reinecke]

On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:

All bytes in CDB should be output after linebuf is filled because
[%s] CDB: %s\n message is output many times in loop.

Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Hannes Reinecke h...@suse.de
Cc: Doug Gilbert dgilb...@interlog.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
  drivers/scsi/constants.c |3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 9c38b8d..5956d4d 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -413,9 +413,8 @@ void __scsi_print_command(struct scsi_device *sdev, const 
char *prefix,

hex_dump_to_buffer(cdb + i, linelen, 16, 1,
   linebuf, sizeof(linebuf), false);
-   sdev_printk(KERN_INFO, sdev, [%s] CDB: %s\n,
-   prefix, linebuf);
}
+   sdev_printk(KERN_INFO, sdev, [%s] CDB: %s\n, prefix, linebuf);
  }
  EXPORT_SYMBOL(__scsi_print_command);


--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


As discussed this patch is invalid.

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 16/17] arcmsr: support new adapter ARC12x4 series

[Tomas Henzl]

On 08/19/2014 09:25 AM, Ching Huang wrote:
 From: Ching Huang ching2...@areca.com.tw

 Add code for supporting Areca new Raid adapter ARC12x4 series.

 Signed-off-by: Ching Huang ching2...@areca.com.tw
 ---

Hi Ching,
please look at the comments below -

  }
 @@ -1039,7 +1147,60 @@ static void arcmsr_done4abort_postqueue(
   error = (flag_ccb  ARCMSR_CCBREPLY_FLAG_ERROR_MODE1) ? 
 true : false;
   arcmsr_drain_donequeue(acb, pCCB, error);
   }
 - }
 + }
 + break;
 + case ACB_ADAPTER_TYPE_D: {
 + struct MessageUnit_D  *pmu = acb-pmuD;
 + uint32_t ccb_cdb_phy, outbound_write_pointer;
 + uint32_t doneq_index, index_stripped, addressLow, residual;
 + bool error;
 + struct CommandControlBlock *pCCB;

I have noticed this^ in this driver already before. Sometimes it makes sense
when a variable is declared in a 'case' block but often it is just
a waste of space. In this function this is the third 'bool error' declared.
Is there a reason for this style (this function is not the worst case) ?

 + outbound_write_pointer = pmu-done_qbuffer[0].addressLow + 1;
 + doneq_index = pmu-doneq_index;
 + residual = atomic_read(acb-ccboutstandingcount);
 + for (i = 0; i  residual; i++) {
 + while ((doneq_index  0xFFF) !=
 + (outbound_write_pointer  0xFFF)) {
 + if (doneq_index  0x4000) {
 + index_stripped = doneq_index  0xFFF;
 + index_stripped += 1;
 + index_stripped %=
 + ARCMSR_MAX_ARC1214_DONEQUEUE;
 + pmu-doneq_index = index_stripped ?
 + (index_stripped | 0x4000) :
 + (index_stripped + 1);
 + } else {
 + index_stripped = doneq_index;
 + index_stripped += 1;
 + index_stripped %=
 + ARCMSR_MAX_ARC1214_DONEQUEUE;
 + pmu-doneq_index = index_stripped ?
 + index_stripped :
 + ((index_stripped | 0x4000) + 1);
 + }
 + doneq_index = pmu-doneq_index;
 + addressLow = pmu-done_qbuffer[doneq_index 
 + 0xFFF].addressLow;
 + ccb_cdb_phy = (addressLow  0xFFF0);
 + pARCMSR_CDB = (struct  ARCMSR_CDB *)
 + (acb-vir2phy_offset + ccb_cdb_phy);
 + pCCB = container_of(pARCMSR_CDB,
 + struct CommandControlBlock, arcmsr_cdb);
 + error = (addressLow 
 + ARCMSR_CCBREPLY_FLAG_ERROR_MODE1) ?
 + true : false;
 + arcmsr_drain_donequeue(acb, pCCB, error);
 + writel(doneq_index, 
 pmu-outboundlist_read_pointer);
 + }
 + mdelay(10);
 + outbound_write_pointer =
 + pmu-done_qbuffer[0].addressLow + 1;
 + doneq_index = pmu-doneq_index;
 + }
 + pmu-postq_index = 0;
 + pmu-doneq_index = 0x40FF;
 + }
 + break;
   }
  }
...


  
 @@ -1256,6 +1424,38 @@ static void arcmsr_post_ccb(struct Adapt
   writel(ccb_post_stamp, phbcmu-inbound_queueport_low);
   }
   }
 + break;
 + case ACB_ADAPTER_TYPE_D: {
 + struct MessageUnit_D  *pmu = acb-pmuD;
 + u16 index_stripped;
 + u16 postq_index;
 + unsigned long flags;
 + struct InBound_SRB *pinbound_srb;
 +
 + spin_lock_irqsave(acb-postq_lock, flags);
 + postq_index = pmu-postq_index;
 + pinbound_srb = (struct InBound_SRB 
 *)(pmu-post_qbuffer[postq_index  0xFF]);
 + pinbound_srb-addressHigh = dma_addr_hi32(cdb_phyaddr);
 + pinbound_srb-addressLow = dma_addr_lo32(cdb_phyaddr);
 + pinbound_srb-length = ccb-arc_cdb_size  2;
 + arcmsr_cdb-msgContext = dma_addr_lo32(cdb_phyaddr);
 + if (postq_index  0x4000) {
 + index_stripped = postq_index  0xFF;
 + index_stripped += 1;
 + index_stripped %= ARCMSR_MAX_ARC1214_POSTQUEUE;
 +  

Re: [RFC PATCH 05/10] scsi/trace: Use macros for getting driver byte, host byte, msg byte, and status byte

[Hannes Reinecke]

On 08/08/2014 01:50 PM, 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.

Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Hannes Reinecke h...@suse.de
Cc: Doug Gilbert dgilb...@interlog.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
  include/trace/events/scsi.h |8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/trace/events/scsi.h b/include/trace/events/scsi.h
index db6c935..8aecdc2 100644
--- a/include/trace/events/scsi.h
+++ b/include/trace/events/scsi.h
@@ -328,10 +328,10 @@ DECLARE_EVENT_CLASS(scsi_cmd_done_timeout_template,
  show_opcode_name(__entry-opcode),
  __parse_cdb(__get_dynamic_array(cmnd), __entry-cmd_len),
  __print_hex(__get_dynamic_array(cmnd), __entry-cmd_len),
- show_driverbyte_name(((__entry-result)  24)  0xff),
- show_hostbyte_name(((__entry-result)  16)  0xff),
- show_msgbyte_name(((__entry-result)  8)  0xff),
- show_statusbyte_name(__entry-result  0xff))
+ show_driverbyte_name(driver_byte(__entry-result)),
+ show_hostbyte_name(host_byte(__entry-result)),
+ show_msgbyte_name(msg_byte(__entry-result)),
+ show_statusbyte_name(status_byte(__entry-result)))
  );

  DEFINE_EVENT(scsi_cmd_done_timeout_template, scsi_dispatch_cmd_done,

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Applied to my scsi logging tree.

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Buffer I/O error after s2ram with usb storage

[Douglas Gilbert]

On 14-08-27 04:40 AM, Matthieu CASTET wrote:

Ping

I have got also a problem with a usb sdcard reader (without power cut
during suspend)

[ 1073.606668] PM: Entering mem sleep
[ 1073.606742] Suspending console(s) (use no_console_suspend to debug)
[ 1073.607146] sd 1:0:0:0: [sda] Synchronizing SCSI cache
[ 1073.639076] sd 1:0:0:0: [sda] Stopping disk
[ 1074.186688] PM: suspend of devices complete after 580.127 msecs
[...]
[ 1075.265183] PM: resume of devices complete after 615.990 msecs
[ 1075.265627] PM: Finishing wakeup.
[ 1075.265630] Restarting tasks ...
[...]
[ 1203.404593] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
6, 29065 clusters in bitmap, 32768 in gd; block bitmap corrupt.
[ 1203.404628] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
5, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt.
[ 1203.404648] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
4, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt.
[ 1203.404667] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
3, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt.
[ 1203.404686] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
2, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt.
[ 1203.404705] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group 
1, 1600 clusters in bitmap, 32321 in gd; block bitmap corrupt.
[ 1203.404726] JBD2: Spotted dirty metadata buffer (dev = sdb6, blocknr = 0). 
There's a risk of filesystem corruption in case of system crash.
[ 1204.141482] sd 8:0:0:0: [sdb] Media Changed
[ 1204.141490] sd 8:0:0:0: [sdb]
[ 1204.141494] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 1204.141497] sd 8:0:0:0: [sdb]
[ 1204.141499] Sense Key : Unit Attention [current]
[ 1204.141504] Info fld=0x0
[ 1204.141506] sd 8:0:0:0: [sdb]
[ 1204.141510] Add. Sense: Not ready to ready change, medium may have changed


The unit attention doesn't look like a problem, it
looks correct. If the system is unable to detect
removable media being changed while the system is
suspended, then 

If the media has a unique identifier, then this unit
attention at wakeup should trigger sd to make sure
that unique identifier has not changed.

Not sure why ext4 starts looking at sdb6 _before_ the
sd driver processes that unit attention. Perhaps a
TEST UNIT READY should be done earlier in the wake-up
sequence to flush out (and process) unit attentions.
There is also the case in which the removable media is
no longer present; and that should change EXT4-fs
processing to a surprise removal.

Doug Gilbert


[ 1204.141514] sd 8:0:0:0: [sdb] CDB:
[ 1204.141516] Read(10): 28 00 00 0a 75 f8 00 00 08 00
[ 1204.141526] end_request: I/O error, dev sdb, sector 685560



Le Mon, 28 Apr 2014 15:01:39 +0200,
Matthieu CASTET matthieu.cas...@parrot.com a écrit :


Hi,

any news on this.

Matthieu CASTET

Le Tue, 22 Apr 2014 16:01:15 +0200,
Matthieu CASTET matthieu.cas...@parrot.com a écrit :


Hi,

while playing with suspend to ram I found a strange behavior with usb
key.

This can be easily reproduced by doing :
- plug a usb key
- start to read the usb key : cat /dev/sdx  /dev/null
- go to suspend : echo mem  /sys/power/state
- while in suspend, unplug and replug the usb key (simulate usb power
loss for computer that keep power)
- exit suspend
- there is read error on the usb key


Because the power was cut during s2ram, the usb stack reset the device
1.
When new data transfer are done, we got a UNIT_ATTENTION from the
device 2 and IO error are returned to user space application.

After some investigation it seems some (all on the 3 I tested) usb key
report as removable, and scsi layer abort the transfer in case of
UNIT_ATTENTION 3.

The usb storage driver call scsi_report_bus_reset after device reset,
but because of commit dfcf7775 4, we don't ignore unit attention if
sshdr.asc == 0x28  sshdr.ascq == 0x00 (Not-ready to ready).

If dfcf7775 is reverted there is no more Buffer I/O error.

Is that possible to find a way to restore the behavior before dfcf7775
commit (no Buffer I/O error after device reset) after a suspend to ram ?


Matthieu CASTET

PS : the same error happen if sg_reset -b /dev/sdx is used on the
device.


1
[  117.070255] usb 2-1.4: reset high-speed USB device number 3 using
ehci-pci [...]
[  117.543922] Restarting tasks ... done.
[  117.548390] video LNXVIDEO:01: Restoring backlight state
2
[  117.549179] sd 6:0:0:0: [sdb] Media Changed
[  117.549184] sd 6:0:0:0: [sdb]
[  117.549187] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  117.549189] sd 6:0:0:0: [sdb]
[  117.549191] Sense Key : Unit Attention [current]
[  117.549195] Info fld=0x0
[  117.549197] sd 6:0:0:0: [sdb]
[  117.549201] Add. Sense: Not ready to ready change, medium may have
changed [  117.549203] sd 6:0:0:0: [sdb] CDB:
[  117.549205] Read(10): 28 00 00 02 c9 00 00 00 f0 00
[  117.549212] end_request: I/O error, dev sdb, sector 182528
[  117.549218] Buffer I/O error on 

Re: [RFC PATCH 06/10] scsi/sd: Delete extra scsi_show_extd_sense() in sd_print_sense_hdr()

[Hannes Reinecke]

On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:

sd_print_sense_hdr() calls scsi_show_extd_sense(),
but scsi_print_sense_hdr() also calls scsi_show_extd_sense().
We can get same result, so we delete it.

Note:
Calling scsi_show_extd_sense() is introduced in fdd8b297.

Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Hannes Reinecke h...@suse.de
Cc: Doug Gilbert dgilb...@interlog.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
  drivers/scsi/sd.c |2 --
  1 file changed, 2 deletions(-)

diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 8d7204a..22dd214 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -3286,8 +3286,6 @@ static void sd_print_sense_hdr(struct scsi_disk *sdkp,
   struct scsi_sense_hdr *sshdr)
  {
scsi_print_sense_hdr(sdkp-device, sdkp-disk-disk_name, sshdr);
-   scsi_show_extd_sense(sdkp-device, sdkp-disk-disk_name,
-sshdr-asc, sshdr-ascq);
  }

  static void sd_print_result(struct scsi_disk *sdkp, int result)

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


A similar patch has been applied to my scsi-logging tree.

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 07/10] scsi/trace: Use scsi_show_result trace point instead of printk

[Hannes Reinecke]

On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:

Current SCSI trace has hostbyte table and driverbyte table, so we don't need to
have the same table in scsi/constants.c.

- Result examples

Before (printk)
sd 2:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

After (ftrace)
scsi_show_result: host_no=2 channel=0 id=0 lun=0 [sda] 
result=(driver=DRIVER_SENSE host=DID_OK)

Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Hannes Reinecke h...@suse.de
Cc: Doug Gilbert dgilb...@interlog.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
  drivers/scsi/constants.c|   52 ---
  drivers/scsi/scsi_trace.c   |   16 +
  include/trace/events/scsi.h |   38 +++
  3 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 6fad6b4..f7b7f32 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -1488,55 +1488,3 @@ void scsi_print_sense(struct scsi_cmnd *cmd)
   SCSI_SENSE_BUFFERSIZE);
  }
  EXPORT_SYMBOL(scsi_print_sense);
-
-#ifdef CONFIG_SCSI_CONSTANTS
-
-static const char * const hostbyte_table[]={
-DID_OK, DID_NO_CONNECT, DID_BUS_BUSY, DID_TIME_OUT, DID_BAD_TARGET,
-DID_ABORT, DID_PARITY, DID_ERROR, DID_RESET, DID_BAD_INTR,
-DID_PASSTHROUGH, DID_SOFT_ERROR, DID_IMM_RETRY, DID_REQUEUE,
-DID_TRANSPORT_DISRUPTED, DID_TRANSPORT_FAILFAST, DID_TARGET_FAILURE,
-DID_NEXUS_FAILURE };
-#define NUM_HOSTBYTE_STRS ARRAY_SIZE(hostbyte_table)
-
-static const char * const driverbyte_table[]={
-DRIVER_OK, DRIVER_BUSY, DRIVER_SOFT,  DRIVER_MEDIA, DRIVER_ERROR,
-DRIVER_INVALID, DRIVER_TIMEOUT, DRIVER_HARD, DRIVER_SENSE};
-#define NUM_DRIVERBYTE_STRS ARRAY_SIZE(driverbyte_table)
-
-void scsi_show_result(struct scsi_device *sdev, const char *name, int result)
-{
-   int hb = host_byte(result);
-   int db = driver_byte(result);
-   const char *hb_string;
-   const char *db_string;
-
-   hb_string = (hb  NUM_HOSTBYTE_STRS) ? hostbyte_table[hb] : invalid;
-   db_string = (db  NUM_DRIVERBYTE_STRS) ?
-   driverbyte_table[db] : invalid;
-
-
-   sdev_printk(KERN_INFO, sdev,
-   [%s] Result: hostbyte=%s driverbyte=%s\n,
-   name, hb_string, db_string);
-}
-
-#else
-
-void scsi_show_result(struct scsi_device *sdev, const char *name, int result)
-{
-   sdev_printk(KERN_INFO, sdev,
-   [%s] Result: hostbyte=0x%02x driverbyte=0x%02x\n,
-   name, host_byte(result), driver_byte(result));
-}
-
-#endif
-EXPORT_SYMBOL(scsi_show_result);
-
-void scsi_print_result(struct scsi_cmnd *cmd)
-{
-   const char *devname = cmd-request-rq_disk ?
-   cmd-request-rq_disk-disk_name : scsi;
-   scsi_show_result(cmd-device, devname, cmd-result);
-}
-EXPORT_SYMBOL(scsi_print_result);
diff --git a/drivers/scsi/scsi_trace.c b/drivers/scsi/scsi_trace.c
index 2bea4f0..6ffbc40 100644
--- a/drivers/scsi/scsi_trace.c
+++ b/drivers/scsi/scsi_trace.c
@@ -19,6 +19,8 @@
  #include linux/trace_seq.h
  #include trace/events/scsi.h

+#include scsi/scsi_dbg.h
+
  #define SERVICE_ACTION16(cdb) (cdb[1]  0x1f)
  #define SERVICE_ACTION32(cdb) ((cdb[8]  8) | cdb[9])

@@ -286,3 +288,17 @@ scsi_trace_parse_cdb(struct trace_seq *p, unsigned char 
*cdb, int len)
return scsi_trace_misc(p, cdb, len);
}
  }
+
+void scsi_show_result(struct scsi_device *sdev, const char *name, int result)
+{
+   trace_scsi_show_result(sdev, name, result);
+}
+EXPORT_SYMBOL(scsi_show_result);
+
+void scsi_print_result(struct scsi_cmnd *cmd)
+{
+   const char *devname = cmd-request-rq_disk ?
+   cmd-request-rq_disk-disk_name : scsi;
+   scsi_show_result(cmd-device, devname, cmd-result);
+}
+EXPORT_SYMBOL(scsi_print_result);
diff --git a/include/trace/events/scsi.h b/include/trace/events/scsi.h
index 8aecdc2..0675195 100644
--- a/include/trace/events/scsi.h
+++ b/include/trace/events/scsi.h
@@ -123,7 +123,11 @@
scsi_hostbyte_name(DID_IMM_RETRY),  \
scsi_hostbyte_name(DID_REQUEUE),\
scsi_hostbyte_name(DID_TRANSPORT_DISRUPTED),\
-   scsi_hostbyte_name(DID_TRANSPORT_FAILFAST))
+   scsi_hostbyte_name(DID_TRANSPORT_FAILFAST), \
+   scsi_hostbyte_name(DID_TARGET_FAILURE), \
+   scsi_hostbyte_name(DID_NEXUS_FAILURE),  \
+   scsi_hostbyte_name(DID_ALLOC_FAILURE),  \
+   scsi_hostbyte_name(DID_MEDIUM_ERROR))

  #define scsi_driverbyte_name(result)  { result, #result }
  #define show_driverbyte_name(val) \
@@ -359,6 +363,38 @@ 

Re: [RFC PATCH 08/10] scsi/trace: Use scsi_print_sense trace point instead of printk

[Hannes Reinecke]

On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:

Previous sense messages can be mixed into other sense messages,
because continuous printk (KERN_CONT) was used. To avoid the problem,
patch d87f3a6f51 introduced a local buffer in Hannes's baranch (*1).
But using local buffers can induce stack overflow, so we want to solve the
problem without local buffer if possible.

trace_seq_printf can add log messages without local buffer, so we use it.

(*1) 
http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging

- Result examples

Before (printk)
sd 2:0:0:0: [sda] Sense Key : Medium Error [current]

After (ftrace)
scsi_print_sense: host_no=2 channel=0 id=0 lun=0 [sda] Sense Key (Medium Error 
[current])

Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Hannes Reinecke h...@suse.de
Cc: Doug Gilbert dgilb...@interlog.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
  drivers/scsi/constants.c|  145 ++-
  drivers/scsi/scsi_trace.c   |  140 --
  include/scsi/scsi_eh.h  |7 ++
  include/trace/events/scsi.h |   48 ++
  4 files changed, 195 insertions(+), 145 deletions(-)

diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index f7b7f32..85b75c8 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -19,7 +19,7 @@
  #include scsi/scsi_eh.h
  #include scsi/scsi_dbg.h

-
+#include trace/events/scsi.h

  /* Commands with service actions that change the command name */
  #define SERVICE_ACTION_IN_12 0xab
@@ -1267,58 +1267,8 @@ static const struct error_info2 additional2[] =
{0x70, 0x00, 0xff, Decompression exception short algorithm id of %x},
{0, 0, 0, NULL}
  };
-
-/* description of the sense key values */
-static const char * const snstext[] = {
-   No Sense,   /* 0: There is no sense information */
-   Recovered Error,  /* 1: The last command completed successfully
- but used error correction */
-   Not Ready,  /* 2: The addressed target is not ready */
-   Medium Error,   /* 3: Data error detected on the medium */
-   Hardware Error,   /* 4: Controller or device failure */
-   Illegal Request,  /* 5: Error in request */
-   Unit Attention,   /* 6: Removable medium was changed, or
- the target has been reset, or ... */
-   Data Protect,   /* 7: Access to the data is blocked */
-   Blank Check,/* 8: Reached unexpected written or unwritten
- region of the medium */
-   Vendor Specific(9),
-   Copy Aborted,   /* A: COPY or COMPARE was aborted */
-   Aborted Command,  /* B: The target aborted the command */
-   Equal,  /* C: A SEARCH DATA command found data equal,
- reserved in SPC-4 rev 36 */
-   Volume Overflow,  /* D: Medium full with still data to be written */
-   Miscompare, /* E: Source data and data on the medium
- do not agree */
-   Completed,  /* F: command completed sense data reported,
- may occur for successful command */
-};
-#else
-static const char * const snstext[] = {
-   0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7,
-   0x8, 0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf,
-};
  #endif

-/* Get sense key string or NULL if not available */
-const char *
-scsi_sense_key_string(unsigned char key) {
-   return snstext[key  0xf];
-}
-EXPORT_SYMBOL(scsi_sense_key_string);
-
-const char *
-scsi_sense_type_string(struct scsi_sense_hdr *sshdr)
-{
-   return scsi_sense_is_deferred(sshdr) ? [deferred] : [current];
-}
-
-const char *
-scsi_sense_format_string(struct scsi_sense_hdr *sshdr)
-{
-   return sshdr-response_code = 0x72 ? [descriptor] : ;
-}
-
  /*
   * Get additional sense code string or NULL if not available.
   * This string may contain a %x and should be printed with ascq as arg.
@@ -1375,105 +1325,22 @@ void
  scsi_print_sense_hdr(struct scsi_device *sdev, const char *name,
 struct scsi_sense_hdr *sshdr)
  {
-   sdev_printk(KERN_INFO, sdev, [%s] Sense Key : %s %s%s\n, name,
-   scsi_sense_key_string(sshdr-sense_key),
-   scsi_sense_type_string(sshdr),
-   scsi_sense_format_string(sshdr));
+   trace_scsi_print_sense(sdev, name, sshdr, NULL, 0, 0);
scsi_show_extd_sense(sdev, name, sshdr-asc, sshdr-ascq);
  }
  EXPORT_SYMBOL(scsi_print_sense_hdr);

-static void
-scsi_dump_sense_buffer(struct scsi_device *sdev, const char *prefix,
-  const unsigned char *sense_buffer, int sense_len)
-{
-   char linebuf[128];
-  

Re: [RFC PATCH -logging 00/10] scsi/constants: Output continuous error messages on trace

[Hannes Reinecke]

On 08/08/2014 03:07 PM, Douglas Gilbert wrote:

On 14-08-08 01:50 PM, Yoshihiro YUNOMAE wrote:

Hi All,

This patch set introduces new traceevents in order to output
continuous error
messages. Current SCSI printk messages in upstream kernel can be
divided by and
mixed with other messages. Even if each error message has its
device id,
sometimes we can easily be lost in mixed logs because the
message's device id
is separated from it's body. To avoid it, I'd like to use
traceevents to
store error messages into the ftrace or perf buuffer, because
traceevents
are atomically commited to the buffer.

In this patch set, all printk messages are removed based on a local
discussion with Hannes, but I think printk messages should be kept
because all
users don't enable traceevents and rsyslog can store as files.

However, if printk of logging branch is kept, the messages are
duplicate and
it can induce stack overflow by using local buffer(*1).

  (*1) https://lkml.org/lkml/2014/5/20/742

So, my suggestion is follows:

1) printk
Keeps current implemntation of upstream kernel.
The messages are divided and can be mixed, but all users can check
the error
messages without any settings.

2) traceevents
To get the complete messages, we can use ftrace or perf (or
something on them).
Users can always understand correct messages, but they need to set
up the
tracers.

This patch set is based on Hannes' logging branch:
http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging


[1/10] ~  [6/10]: just cleanup for logging branch
[7/10] ~ [10/10]: introduce new traceevents

Any comments are welcome!


In sg3_utils there are now string yielding equivalents
to the sense buffer print functions. They take a form
like this:
   char * get_sense_str(const unsigned char * sense_buffer,
int sb_len, int blen, char * b);

So this just does the hard work of decoding the sense buffer
(or saying it is invalid) the result of which it places in
buffer 'b'. And 'b' is returned (so this function can be in
the arguments of a driver's printing function).

Adding such string functions would give other parts of the
SCSI subsystem the capability of tailoring their own
messages that include sense data information.


Existing sense buffer print function could be kept and
implemented using the newer _str variants. Would that
be worth the trouble?


Hmm. Probably not.

I would rather go the approach we've been taking with the
VPD pages, and do _not_ decode any sense code data
(except from the usual sense key/ASC/ASCQ values, of course).
Instead we should rather ensure that we can get to the raw
sense code values from userspace so that we can interpret
it later with userspace tools.

My plan for updating scsi logging is:

- move all lone 'printk' statements into dev_printk() variants
  and ensure they are printed in one line to avoid breaking
  logging statements up under high load
- Update scsi_trace to use the functionality from constants.c
- Convert the current scsi_logging mechanism over to tracepoints.

The first bit is mostly done; I'll be sending the patchset for review.
The hard part is the third bit; would be really grand if we can
model this with the existing scsi_logging_level interface intact.
But not sure if that's possible nor if it's desirable.

Btw, _now_ would be a good chance to send an update of constants.c
with latest SPC bits ...

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 10/10] scsi/trace: Use scsi_print_command trace point instead of printk

[Hannes Reinecke]

On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:

Previous printk messages of SCSI command can be mixed into other printk
messages because multiple printk messages are output for it. To avoid the
problem, patch 4e64bb8d6 in Hannes' branch(*1) introduced a local buffer.
But using local buffers can induce stack overflow, so we want to solve the
problem without local buffer if possible.

trace_seq_printf can add log messages without local buffer, so we use it.

Note:
We don't need constans.c any more.

(*1) 
http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging

  - Result examples

Before (printk)
sd 2:0:0:0: [sda] CDB: Read(10)

After
scsi_print_command: host_no=2 channel=0 id=0 lun=0 [sda] CDB (Read(10))

Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Hannes Reinecke h...@suse.de
Cc: Doug Gilbert dgilb...@interlog.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
  drivers/scsi/Makefile   |2
  drivers/scsi/constants.c|  425 ---
  drivers/scsi/scsi_trace.c   |  408 +
  include/scsi/scsi.h |8 +
  include/trace/events/scsi.h |   45 +
  5 files changed, 461 insertions(+), 427 deletions(-)
  delete mode 100644 drivers/scsi/constants.c

diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 5f0d299..c56f692 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -158,7 +158,7 @@ obj-$(CONFIG_SCSI_OSD_INITIATOR) += osd/
  # This goes last, so that real scsi devices probe earlier
  obj-$(CONFIG_SCSI_DEBUG)  += scsi_debug.o

-scsi_mod-y += scsi.o hosts.o scsi_ioctl.o constants.o \
+scsi_mod-y += scsi.o hosts.o scsi_ioctl.o \
   scsicam.o scsi_error.o scsi_lib.o
  scsi_mod-$(CONFIG_SCSI_DMA)   += scsi_lib_dma.o
  scsi_mod-y+= scsi_scan.o scsi_sysfs.o scsi_devinfo.o
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
deleted file mode 100644
index ce9ceb8..000
--- a/drivers/scsi/constants.c
+++ /dev/null
@@ -1,425 +0,0 @@
-/*
- * ASCII values for a number of symbolic constants, printing functions,
- * etc.
- * Additions for SCSI 2 and Linux 2.2.x by D. Gilbert (990422)
- * Additions for SCSI 3+ (SPC-3 T10/1416-D Rev 07 3 May 2002)
- *   by D. Gilbert and aeb (20020609)
- * Updated to SPC-4 T10/1713-D Rev 36g, D. Gilbert 20130701
- */
-
-#include linux/blkdev.h
-#include linux/module.h
-#include linux/kernel.h
-#include asm/unaligned.h
-
-#include scsi/scsi.h
-#include scsi/scsi_cmnd.h
-
-/* Commands with service actions that change the command name */
-#define SERVICE_ACTION_IN_12 0xab
-#define SERVICE_ACTION_OUT_12 0xa9
-#define SERVICE_ACTION_BIDIRECTIONAL 0x9d
-#define SERVICE_ACTION_IN_16 0x9e
-#define SERVICE_ACTION_OUT_16 0x9f
-#define THIRD_PARTY_COPY_OUT 0x83
-#define THIRD_PARTY_COPY_IN 0x84
-
-
-
-#ifdef CONFIG_SCSI_CONSTANTS
-static const char * cdb_byte0_names[] = {
-/* 00-03 */ Test Unit Ready, Rezero Unit/Rewind, NULL, Request Sense,
-/* 04-07 */ Format Unit/Medium, Read Block Limits, NULL,
-   Reassign Blocks,
-/* 08-0d */ Read(6), NULL, Write(6), Seek(6), NULL, NULL,
-/* 0e-12 */ NULL, Read Reverse, Write Filemarks, Space, Inquiry,
-/* 13-16 */ Verify(6), Recover Buffered Data, Mode Select(6),
-   Reserve(6),
-/* 17-1a */ Release(6), Copy, Erase, Mode Sense(6),
-/* 1b-1d */ Start/Stop Unit, Receive Diagnostic, Send Diagnostic,
-/* 1e-1f */ Prevent/Allow Medium Removal, NULL,
-/* 20-22 */  NULL, NULL, NULL,
-/* 23-28 */ Read Format Capacities, Set Window,
-   Read Capacity(10), NULL, NULL, Read(10),
-/* 29-2d */ Read Generation, Write(10), Seek(10), Erase(10),
-Read updated block,
-/* 2e-31 */ Write Verify(10), Verify(10), Search High, Search Equal,
-/* 32-34 */ Search Low, Set Limits, Prefetch/Read Position,
-/* 35-37 */ Synchronize Cache(10), Lock/Unlock Cache(10),
-   Read Defect Data(10),
-/* 38-3c */ Medium Scan, Compare, Copy Verify, Write Buffer,
-   Read Buffer,
-/* 3d-3f */ Update Block, Read Long(10),  Write Long(10),
-/* 40-41 */ Change Definition, Write Same(10),
-/* 42-48 */ Unmap/Read sub-channel, Read TOC/PMA/ATIP,
-   Read density support, Play audio(10), Get configuration,
-   Play audio msf, Sanitize/Play audio track/index,
-/* 49-4f */ Play track relative(10), Get event status notification,
-Pause/resume, Log Select, Log Sense, Stop play/scan,
-NULL,
-/* 50-55 */ Xdwrite, Xpwrite, Read disk info, Xdread, Read track info,
-Reserve track, Send OPC info, Mode Select(10),
-/* 56-5b */ Reserve(10), Release(10), Repair track, Read master cue,
-Mode Sense(10), Close track/session,
-/* 5c-5f */ Read 

Re: [RFC PATCH 09/10] scsi/trace: Add additional sense code and additional sense code qualifier to scsi_print_sense trace point

[Hannes Reinecke]

On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:

There are no mean that additional sense code and additional sense code qualifier
are output as different messages of sense key, so those information are added.

Note:
scsi_show_extd_sense() is changed from export symbol to non-export symbol.

  - Result examples

Before (printk)
sd 2:0:0:0: [sda] Add. Sense: Unrecovered read error

After (ftrace, merged into scsi_print_sense traceevent)
scsi_print_sense: host_no=2 channel=0 id=0 lun=0 [sda] Sense Key (Medium Error 
[current])  Add. Sense (Unrecovered read error)

Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Hannes Reinecke h...@suse.de
Cc: Doug Gilbert dgilb...@interlog.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
  drivers/scsi/constants.c|  932 ---
  drivers/scsi/scsi_trace.c   |  920 ++
  include/scsi/scsi_dbg.h |2
  include/trace/events/scsi.h |   10
  4 files changed, 928 insertions(+), 936 deletions(-)

diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 85b75c8..ce9ceb8 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -14,12 +14,6 @@

  #include scsi/scsi.h
  #include scsi/scsi_cmnd.h
-#include scsi/scsi_device.h
-#include scsi/scsi_host.h
-#include scsi/scsi_eh.h
-#include scsi/scsi_dbg.h
-
-#include trace/events/scsi.h

  /* Commands with service actions that change the command name */
  #define SERVICE_ACTION_IN_12 0xab
@@ -429,929 +423,3 @@ void scsi_print_command(struct scsi_cmnd *cmd)
print_opcode_name(cmd-device, devname, cmd-cmnd, cmd-cmd_len);
  }
  EXPORT_SYMBOL(scsi_print_command);
-
-#ifdef CONFIG_SCSI_CONSTANTS
-
-struct error_info {
-   unsigned short code12;  /* 0x0302 looks better than 0x03,0x02 */
-   const char * text;
-};
-
-/*
- * The canonical list of T10 Additional Sense Codes is available at:
- * http://www.t10.org/lists/asc-num.txt [most recent: 20130605]
- */
-
-static const struct error_info additional[] =
-{
-   {0x, No additional sense information},
-   {0x0001, Filemark detected},
-   {0x0002, End-of-partition/medium detected},
-   {0x0003, Setmark detected},
-   {0x0004, Beginning-of-partition/medium detected},
-   {0x0005, End-of-data detected},
-   {0x0006, I/O process terminated},
-   {0x0007, Programmable early warning detected},
-   {0x0011, Audio play operation in progress},
-   {0x0012, Audio play operation paused},
-   {0x0013, Audio play operation successfully completed},
-   {0x0014, Audio play operation stopped due to error},
-   {0x0015, No current audio status to return},
-   {0x0016, Operation in progress},
-   {0x0017, Cleaning requested},
-   {0x0018, Erase operation in progress},
-   {0x0019, Locate operation in progress},
-   {0x001A, Rewind operation in progress},
-   {0x001B, Set capacity operation in progress},
-   {0x001C, Verify operation in progress},
-   {0x001D, ATA pass through information available},
-   {0x001E, Conflicting SA creation request},
-   {0x001F, Logical unit transitioning to another power condition},
-   {0x0020, Extended copy information available},
-
-   {0x0100, No index/sector signal},
-
-   {0x0200, No seek complete},
-
-   {0x0300, Peripheral device write fault},
-   {0x0301, No write current},
-   {0x0302, Excessive write errors},
-
-   {0x0400, Logical unit not ready, cause not reportable},
-   {0x0401, Logical unit is in process of becoming ready},
-   {0x0402, Logical unit not ready, initializing command required},
-   {0x0403, Logical unit not ready, manual intervention required},
-   {0x0404, Logical unit not ready, format in progress},
-   {0x0405, Logical unit not ready, rebuild in progress},
-   {0x0406, Logical unit not ready, recalculation in progress},
-   {0x0407, Logical unit not ready, operation in progress},
-   {0x0408, Logical unit not ready, long write in progress},
-   {0x0409, Logical unit not ready, self-test in progress},
-   {0x040A, Logical unit not accessible, asymmetric access state 
-transition},
-   {0x040B, Logical unit not accessible, target port in standby state},
-   {0x040C, Logical unit not accessible, target port in unavailable 
-state},
-   {0x040D, Logical unit not ready, structure check required},
-   {0x0410, Logical unit not ready, auxiliary memory not accessible},
-   {0x0411, Logical unit not ready, notify (enable spinup) required},
-   {0x0412, Logical unit not ready, offline},
-   {0x0413, Logical unit not ready, SA creation in progress},
-   {0x0414, Logical unit not ready, space allocation in 

Re: [PATCH 2/2] Drivers: scsi: storvsc: Force discovery of LUNs that may have been removed.

[Hannes Reinecke]

On 08/19/2014 07:54 PM, Christoph Hellwig wrote:

On Sat, Aug 16, 2014 at 08:09:48PM -0700, K. Y. Srinivasan wrote:

The host asks the guest to scan when a LUN is removed or added.
The only way a guest can identify the removed LUN is when an I/O is
attempted on a removed LUN - the SRB status code indicates that the LUN
is invalid. We currently handle this SRB status and remove the device.

Rather than waiting for an I/O to remove the device, force the discovery of
LUNs that may have been removed prior to discovering LUNs that may have
been added.


This looks pretty reasonable to me, but I wonder if we should move this
up to common code so that it happens for any host rescan triggered by
sysfs or other drivers as well.


Not without proper testing.
Currently we cannot rescan existing devices; the inquiry string is 
nailed to the sdev structure. The only way to really refresh the 
information is to delete it and rescan it again.


And I really do _not_ want to do this automatically as the device 
might be busy due to various reasons (think of multipathing).
It tooks us ages to get this working with FC, and we finally settled 
to have a soft-remove implemented in the transport class.
And we still have issues with SAS HBAs, where at least the standard 
defines a mechanism. Trying this in the SCSI midlayer itself

is the road to disaster.

If we were to attempt this we would need to lift the dev_loss_tmo 
mechanism from the FC transport layer and make this a generic

facility for every HBA. But this is quite some work.

Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RES: RES: AS2105-based enclosure size issues with 2TB HDDs

[Alan Stern]

On Wed, 27 Aug 2014, Oliver Neukum wrote:

  I don't think we want to add another SCSI flag to say that READ
  CAPACITY(10) is unreliable.
 
 Why not? It would only be friendly to tell the upper layer
 of a malfunction if we know about it.

To what end?  What will the upper layer do with this information?

  Given the difficulty of determining the true capacity, I see two
  alternatives.  We could set the capacity to a ridiculously large value
  (like 1 billion TB), or we could leave the capacity set to the low
  value and disable the block within bounds checks.  Neither of these
  is attractive and they both have issues of their own -- although the 
  second is close to what Windows does.
 
 That seems to be the most attractive solution to me.

I'm skeptical that you can convince the SCSI and block-layer developers 
about this.  Maybe they'll accept it if it is applied only to USB 
transports...

  (For example, udev often tries to read the last sectors of a new drive, 
  looking for a GPT or RAID signature.  That won't work if the capacity 
  is set to some random value.)
 
 Yes, but clipping has its own dangers. Suppose you use the medium
 without a partition table.

What would Windows do?  In the absence of a partition table, it would 
believe the value from READ CAPACITY, right?  Isn't that the same as 
clipping?

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH -logging 00/10] scsi/constants: Output continuous error messages on trace

[Douglas Gilbert]

On 14-08-27 10:23 AM, Hannes Reinecke wrote:

On 08/08/2014 03:07 PM, Douglas Gilbert wrote:

On 14-08-08 01:50 PM, Yoshihiro YUNOMAE wrote:

Hi All,

This patch set introduces new traceevents in order to output
continuous error
messages. Current SCSI printk messages in upstream kernel can be
divided by and
mixed with other messages. Even if each error message has its
device id,
sometimes we can easily be lost in mixed logs because the
message's device id
is separated from it's body. To avoid it, I'd like to use
traceevents to
store error messages into the ftrace or perf buuffer, because
traceevents
are atomically commited to the buffer.

In this patch set, all printk messages are removed based on a local
discussion with Hannes, but I think printk messages should be kept
because all
users don't enable traceevents and rsyslog can store as files.

However, if printk of logging branch is kept, the messages are
duplicate and
it can induce stack overflow by using local buffer(*1).

  (*1) https://lkml.org/lkml/2014/5/20/742

So, my suggestion is follows:

1) printk
Keeps current implemntation of upstream kernel.
The messages are divided and can be mixed, but all users can check
the error
messages without any settings.

2) traceevents
To get the complete messages, we can use ftrace or perf (or
something on them).
Users can always understand correct messages, but they need to set
up the
tracers.

This patch set is based on Hannes' logging branch:
http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging


[1/10] ~  [6/10]: just cleanup for logging branch
[7/10] ~ [10/10]: introduce new traceevents

Any comments are welcome!


In sg3_utils there are now string yielding equivalents
to the sense buffer print functions. They take a form
like this:
   char * get_sense_str(const unsigned char * sense_buffer,
int sb_len, int blen, char * b);

So this just does the hard work of decoding the sense buffer
(or saying it is invalid) the result of which it places in
buffer 'b'. And 'b' is returned (so this function can be in
the arguments of a driver's printing function).

Adding such string functions would give other parts of the
SCSI subsystem the capability of tailoring their own
messages that include sense data information.


Existing sense buffer print function could be kept and
implemented using the newer _str variants. Would that
be worth the trouble?


Hmm. Probably not.

I would rather go the approach we've been taking with the
VPD pages, and do _not_ decode any sense code data
(except from the usual sense key/ASC/ASCQ values, of course).
Instead we should rather ensure that we can get to the raw
sense code values from userspace so that we can interpret
it later with userspace tools.

My plan for updating scsi logging is:

- move all lone 'printk' statements into dev_printk() variants
   and ensure they are printed in one line to avoid breaking
   logging statements up under high load
- Update scsi_trace to use the functionality from constants.c
- Convert the current scsi_logging mechanism over to tracepoints.

The first bit is mostly done; I'll be sending the patchset for review.
The hard part is the third bit; would be really grand if we can
model this with the existing scsi_logging_level interface intact.
But not sure if that's possible nor if it's desirable.

Btw, _now_ would be a good chance to send an update of constants.c
with latest SPC bits ...


From constants.c:
 * Updated to SPC-4 T10/1713-D Rev 36g, D. Gilbert 20130701

Not much has changed between then and now (37a). There is a
lot pending for SPC-5 plus all the ZBC stuff, little of which
has hit the drafts yet. WRITE ATOMIC and a few new asc/ascq
codes is about all that I have noticed. Even when new asc/ascq
strings are approved, it needs the SPC4/5 technical editor to
allocate numbers for them.

So even if the timing is good from the kernel POV, not much
is available. The next T10 meeting is in a few weeks, lets
see what happens there.

Doug Gilbert


--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Buffer I/O error after s2ram with usb storage

[Alan Stern]

On Wed, 27 Aug 2014, Matthieu CASTET wrote:

 Ping
 
 I have got also a problem with a usb sdcard reader (without power cut
 during suspend)

   The usb storage driver call scsi_report_bus_reset after device reset,
   but because of commit dfcf7775 4, we don't ignore unit attention if
   sshdr.asc == 0x28  sshdr.ascq == 0x00 (Not-ready to ready).
   
   If dfcf7775 is reverted there is no more Buffer I/O error.
   
   Is that possible to find a way to restore the behavior before dfcf7775
   commit (no Buffer I/O error after device reset) after a suspend to ram ?

Since that commit was written to fix a problem with certain cdrom
drives, maybe we would work around the issue by modifying the commit.  
Have it go back to the original behavior if the device isn't a cdrom 
drive.

That's not a complete fix (it won't help when a CD drive is attached 
via USB), but maybe it's better than nothing.

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Buffer I/O error after s2ram with usb storage

[Alan Stern]

On Wed, 27 Aug 2014, Douglas Gilbert wrote:

 The unit attention doesn't look like a problem, it
 looks correct. If the system is unable to detect
 removable media being changed while the system is
 suspended, then 
 
 If the media has a unique identifier, then this unit
 attention at wakeup should trigger sd to make sure
 that unique identifier has not changed.

Does sd have any code to do this?  I'm not aware of any, but there 
ought to be some.  Otherwise there's no way to tell when a so-called 
media change was just the old media being taken out and put back in.

Or maybe this functionality belongs in the block layer rather than in 
sd.

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ibmraid: fix writeable attribute with no store method

[Alan]

https://bugzilla.kernel.org/show_bug.cgi?id=81311

 [ 0.603157] WARNING: at drivers/base/core.c:601
device_create_file+0x8d/0xa0()
 [ 0.603158] Attribute adapter_id: write permission without 'store'
 [ 0.603159] Modules linked in: i915(+) i2c_algo_bit drm_kms_helper drm
mpt2sas(+) pmcraid(+) raid_class scsi_transport_sas i2c_core video

Signed-off-by: Alan Cox a...@linux.intel.com
---
 drivers/scsi/pmcraid.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/pmcraid.c b/drivers/scsi/pmcraid.c
index 6f3275d..e2232c3 100644
--- a/drivers/scsi/pmcraid.c
+++ b/drivers/scsi/pmcraid.c
@@ -4292,7 +4292,7 @@ static ssize_t pmcraid_show_adapter_id(
 static struct device_attribute pmcraid_adapter_id_attr = {
.attr = {
 .name = adapter_id,
-.mode = S_IRUGO | S_IWUSR,
+.mode = S_IRUGO,
 },
.show = pmcraid_show_adapter_id,
 };

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] lpfc: Avoid to disable pci_dev twice

[James Smart]

Mike,

Can you confirm - the nulls this patch correct are because the 
probe_one and error_detect threads are running concurrently, thus battling ?


If so - this fix looks insufficient and we should rework it.

Q: why are they allowed to run concurrently ?  I could see this solved 
at the platform level to let probe_one finish before error_detect is 
called (and therefore stating error_detect only makes sense to call if 
probe_one was successful). It's also a much driver-friendly solution. I 
could see other drivers have much the same issue with concurrency and 
data structure teardown - and if locks aren't allowed in the 
error-detect path... it's not good.


-- james s



On 7/31/2014 10:16 PM, Mike Qiu wrote:

On 07/17/2014 02:32 PM, Mike Qiu wrote:


Hi, all

How about this patch ?

Any idea ?


In IBM Power servers, when hardware error occurs during probe
state, EEH subsystem will call driver's error_detected interface,
which will call pci_disable_device(). But driver's probe function also
call pci_disable_device() in this situation.

So pci_dev will be disabled twice:

Device lpfc disabling already-disabled device
[ cut here ]
WARNING: at drivers/pci/pci.c:1407
CPU: 0 PID: 8744 Comm: kworker/0:0 Tainted: GW 
3.10.42-2002.pkvm2_1_1.6.ppc64 #1

Workqueue: events .work_for_cpu_fn
task: c0274e3f5400 ti: c027d3958000 task.ti: c027d3958000
NIP: c0471b8c LR: c0471b88 CTR: c043ebe0
REGS: c027d395b650 TRAP: 0700   Tainted: GW 
(3.10.42-2002.pkvm2_1_1.6.ppc64)
MSR: 900100029032 SF,HV,EE,ME,IR,DR,RI  CR: 28b52b44  XER: 
2000

CFAR: c0879ab8 SOFTE: 1
...
NIP .pci_disable_device+0xcc/0xe0
LR  .pci_disable_device+0xc8/0xe0
Call Trace:
.pci_disable_device+0xc8/0xe0 (unreliable)
.lpfc_disable_pci_dev+0x50/0x80 [lpfc]
.lpfc_pci_probe_one+0x870/0x21a0 [lpfc]
.local_pci_probe+0x68/0xb0
.work_for_cpu_fn+0x38/0x60
.process_one_work+0x1a4/0x4d0
.worker_thread+0x37c/0x490
.kthread+0xf0/0x100
.ret_from_kernel_thread+0x5c/0x80

Signed-off-by: Mike Qiu qiud...@linux.vnet.ibm.com
---
  drivers/scsi/lpfc/lpfc.h  |  1 +
  drivers/scsi/lpfc/lpfc_init.c | 59 
+++

  2 files changed, 55 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/lpfc/lpfc.h b/drivers/scsi/lpfc/lpfc.h
index 434e903..0c7bad9 100644
--- a/drivers/scsi/lpfc/lpfc.h
+++ b/drivers/scsi/lpfc/lpfc.h
@@ -813,6 +813,7 @@ struct lpfc_hba {
  #define VPD_MASK0xf /* mask for any vpd data */

  uint8_t soft_wwn_enable;
+uint8_t probe_done;

  struct timer_list fcp_poll_timer;
  struct timer_list eratt_poll;
diff --git a/drivers/scsi/lpfc/lpfc_init.c 
b/drivers/scsi/lpfc/lpfc_init.c

index 06f9a5b..c2e67ae 100644
--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -9519,6 +9519,9 @@ lpfc_pci_probe_one_s3(struct pci_dev *pdev, 
const struct pci_device_id *pid)

  }
  }

+/* Set the probe flag */
+phba-probe_done = 1;
+
  /* Perform post initialization setup */
  lpfc_post_init_setup(phba);

@@ -9795,6 +9798,9 @@ lpfc_sli_prep_dev_for_recover(struct lpfc_hba 
*phba)

  static void
  lpfc_sli_prep_dev_for_reset(struct lpfc_hba *phba)
  {
+if (phba)
+return;
+
  lpfc_printf_log(phba, KERN_ERR, LOG_INIT,
  2710 PCI channel disable preparing for reset\n);

@@ -9812,7 +9818,8 @@ lpfc_sli_prep_dev_for_reset(struct lpfc_hba *phba)

  /* Disable interrupt and pci device */
  lpfc_sli_disable_intr(phba);
-pci_disable_device(phba-pcidev);
+if (phba-probe_done  phba-pcidev)
+pci_disable_device(phba-pcidev);
  }

  /**
@@ -10282,6 +10289,9 @@ lpfc_pci_probe_one_s4(struct pci_dev *pdev, 
const struct pci_device_id *pid)

  goto out_disable_intr;
  }

+/* Set probe_done flag */
+phba-probe_done = 1;
+
  /* Log the current active interrupt mode */
  phba-intr_mode = intr_mode;
  lpfc_log_intr_mode(phba, intr_mode);
@@ -10544,6 +10554,9 @@ lpfc_sli4_prep_dev_for_recover(struct 
lpfc_hba *phba)

  static void
  lpfc_sli4_prep_dev_for_reset(struct lpfc_hba *phba)
  {
+if (!phba)
+return;
+
  lpfc_printf_log(phba, KERN_ERR, LOG_INIT,
  2826 PCI channel disable preparing for reset\n);

@@ -10562,7 +10575,9 @@ lpfc_sli4_prep_dev_for_reset(struct lpfc_hba 
*phba)

  /* Disable interrupt and pci device */
  lpfc_sli4_disable_intr(phba);
  lpfc_sli4_queue_destroy(phba);
-pci_disable_device(phba-pcidev);
+
+if (phba-probe_done  phba-pcidev)
+pci_disable_device(phba-pcidev);
  }

  /**
@@ -10893,9 +10908,21 @@ static pci_ers_result_t
  lpfc_io_error_detected(struct pci_dev *pdev, pci_channel_state_t 
state)

  {
  struct Scsi_Host *shost = pci_get_drvdata(pdev);
-struct lpfc_hba *phba = ((struct lpfc_vport 
*)shost-hostdata)-phba;

+struct lpfc_hba *phba;
  pci_ers_result_t rc = PCI_ERS_RESULT_DISCONNECT;

+if 

Re: [PATCH RESEND] libiscsi: Don't retry if xmit_task return a non-transient error code

[Mike Christie]

On 08/17/2014 10:23 AM, Sagi Grimberg wrote:
 Allow transport callback xmit_task to return a non-transient
 error code -EINVAL to inform us not to retry the task. For any
 other error code keep the current retry behavior.
 
 Signed-off-by: Sagi Grimberg sa...@mellanox.com
 ---
  drivers/scsi/libiscsi.c |   13 ++---
  1 files changed, 10 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
 index 3d1bc67..03768a9 100644
 --- a/drivers/scsi/libiscsi.c
 +++ b/drivers/scsi/libiscsi.c
 @@ -1722,10 +1722,17 @@ int iscsi_queuecommand(struct Scsi_Host *host, struct 
 scsi_cmnd *sc)
   goto prepd_fault;
   }
   }
 - if (session-tt-xmit_task(task)) {
 +
 + reason = session-tt-xmit_task(task);
 + if (reason) {
   session-cmdsn--;
 - reason = FAILURE_SESSION_NOT_READY;
 - goto prepd_reject;
 + if (reason == -EINVAL) {
 + sc-result = DID_ABORT  16;
 + goto prepd_fault;
 + } else {
 + reason = FAILURE_SESSION_NOT_READY;
 + goto prepd_reject;
 + }
   }
   } else {
   list_add_tail(task-running, conn-cmdqueue);
 

Looks ok to me.

Acked-by: Mike Christie micha...@cs.wisc.edu
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)

[Dale R. Worley]

 From: James Bottomley james.bottom...@hansenpartnership.com

 Did you try read capacity 16 on it?  What happened?  (the AS2105 rejects
 read capacity 16, so there's no reliable way to deduce the capacity of
 drives over 2TB).

OK, I had to track down which package contains sg_readcap.

The adapter that fails gives this output:

# sg_readcap --16 /dev/sdb
bad field in READ CAPACITY (16) cdb including unsupported service action

The adapter that succeeds gives this output:

# sg_readcap --16 /dev/sdc
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=0, lbprz=0
   Last logical block address=5860533167 (0x15d50a3af), Number of logical 
blocks=5860533168
   Logical block length=512 bytes
   Logical blocks per physical block exponent=0
   Lowest aligned logical block address=0
Hence:
   Device size: 3000592982016 bytes, 2861588.5 MiB, 3000.59 GB

Dale
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)

[Dale R. Worley]

What I find interesting is that Windows (at least, Windows 7
Professional) seems to be able to handle the deficient adapter.  What
I'd like to do is log the disk commands during the mounting sequence,
preferably at both the SCSI and USB layers.  Then at least we'll know
exactly what the driver is doing.  Are there kernel options to do
this?

Unfortunately, I don't know any way to log what Windows is doing with
the drive.

Dale
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)

[James Bottomley]

On Wed, 2014-08-27 at 15:21 -0400, Dale R. Worley wrote:
  From: James Bottomley james.bottom...@hansenpartnership.com
 
  Did you try read capacity 16 on it?  What happened?  (the AS2105 rejects
  read capacity 16, so there's no reliable way to deduce the capacity of
  drives over 2TB).
 
 OK, I had to track down which package contains sg_readcap.
 
 The adapter that fails gives this output:
 
 # sg_readcap --16 /dev/sdb
 bad field in READ CAPACITY (16) cdb including unsupported service action

OK, so that's definitely the tame taxonomy.

James


--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Problem with USB-to-SATA adapters (was: AS2105-based enclosure size issues with 2TB HDDs)

[Alan Stern]

On Wed, 27 Aug 2014, Dale R. Worley wrote:

 What I find interesting is that Windows (at least, Windows 7
 Professional) seems to be able to handle the deficient adapter.

So does Linux.  The difference is that Windows believes the values in
the partition table in preference to what the hardware says, whereas 
Linux believes the hardware in preference to the partition table.

Thus, if the hardware says the disk contains 0.8 TB and the partition 
table says the first partition contains 2.8 TB, Windows will try to 
access all 2.8 TB but Linux will complain that the partition entry is 
invalid (because the partition extends beyond the end of the disk).

If you try to repartition the drive under Windows using the deficient 
adapter, you'll see that the problem still exists.  It just doesn't 
show up during normal use.

  What
 I'd like to do is log the disk commands during the mounting sequence,
 preferably at both the SCSI and USB layers.  Then at least we'll know
 exactly what the driver is doing.  Are there kernel options to do
 this?

You can record the USB transfers by using usbmon (see
Documentation/usb/usbmon.txt).  The trace will include all the
important SCSI data, so you don't need to record anything at the SCSI
layer.

This isn't really necessary, though.  We already know what the driver 
is doing.

 Unfortunately, I don't know any way to log what Windows is doing with
 the drive.

My experiments with Windows show that it does essentially the same
things as Linux does.  The important difference is not what commands
and data get sent, but whether the OS pays attention to the result.

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fusion: fix excess parameter kernel-doc warning

[Randy Dunlap]

On 08/18/14 10:07, Ewan Milne wrote:
 On Sat, 2014-08-16 at 14:15 -0700, Randy Dunlap wrote:
 From: Randy Dunlap rdun...@infradead.org

 Fix kernel-doc excess parameter warning:

 Warning(..//drivers/message/fusion/mptbase.c:1411): Excess function 
 parameter 'prod_name' description in 'mpt_get_product_name'

 Signed-off-by: Randy Dunlap rdun...@infradead.org
 Cc: dl-mptfusionli...@lsi.com
 Cc: mpt-fusionlinux@avagotech.com
 ---
  drivers/message/fusion/mptbase.c |1 -
  1 file changed, 1 deletion(-)

 Index: lnx-317-rc1/drivers/message/fusion/mptbase.c
 ===
 --- lnx-317-rc1.orig/drivers/message/fusion/mptbase.c
 +++ lnx-317-rc1/drivers/message/fusion/mptbase.c
 @@ -1400,7 +1400,6 @@ mpt_verify_adapter(int iocid, MPT_ADAPTE
   *  @vendor: pci vendor id
   *  @device: pci device id
   *  @revision: pci revision id
 - *  @prod_name: string returned
   *
   *  Returns product string displayed when driver loads,
   *  in /proc/mpt/summary and /sysfs/class/scsi_host/hostX/version_product
 --
 
 Goes with commit c9834c70efbaaa1461ec04289d97a842244fb294.
 
 Reviewed-by: Ewan D. Milne emi...@redhat.com

Christoph, did you pick up this patch or should I merge it
with my documentation patches?

Thanks.

-- 
~Randy
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fusion: fix excess parameter kernel-doc warning

[Christoph Hellwig]

On Wed, Aug 27, 2014 at 04:47:24PM -0700, Randy Dunlap wrote:
  Goes with commit c9834c70efbaaa1461ec04289d97a842244fb294.
  
  Reviewed-by: Ewan D. Milne emi...@redhat.com
 
 Christoph, did you pick up this patch or should I merge it
 with my documentation patches?

I did as mentioned in my reply to your other patch.

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: [RFC PATCH 07/10] scsi/trace: Use scsi_show_result trace point instead of printk

[Yoshihiro YUNOMAE]

(2014/08/27 23:12), Hannes Reinecke wrote:

On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:

Current SCSI trace has hostbyte table and driverbyte table, so we
don't need to
have the same table in scsi/constants.c.

- Result examples

Before (printk)
sd 2:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

After (ftrace)
scsi_show_result: host_no=2 channel=0 id=0 lun=0 [sda]
result=(driver=DRIVER_SENSE host=DID_OK)

Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Hannes Reinecke h...@suse.de
Cc: Doug Gilbert dgilb...@interlog.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
  drivers/scsi/constants.c|   52
---
  drivers/scsi/scsi_trace.c   |   16 +
  include/trace/events/scsi.h |   38 +++
  3 files changed, 53 insertions(+), 53 deletions(-)

diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 6fad6b4..f7b7f32 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -1488,55 +1488,3 @@ void scsi_print_sense(struct scsi_cmnd *cmd)
 SCSI_SENSE_BUFFERSIZE);
  }
  EXPORT_SYMBOL(scsi_print_sense);
-
-#ifdef CONFIG_SCSI_CONSTANTS
-
-static const char * const hostbyte_table[]={
-DID_OK, DID_NO_CONNECT, DID_BUS_BUSY, DID_TIME_OUT,
DID_BAD_TARGET,
-DID_ABORT, DID_PARITY, DID_ERROR, DID_RESET, DID_BAD_INTR,
-DID_PASSTHROUGH, DID_SOFT_ERROR, DID_IMM_RETRY, DID_REQUEUE,
-DID_TRANSPORT_DISRUPTED, DID_TRANSPORT_FAILFAST,
DID_TARGET_FAILURE,
-DID_NEXUS_FAILURE };
-#define NUM_HOSTBYTE_STRS ARRAY_SIZE(hostbyte_table)
-
-static const char * const driverbyte_table[]={
-DRIVER_OK, DRIVER_BUSY, DRIVER_SOFT,  DRIVER_MEDIA,
DRIVER_ERROR,
-DRIVER_INVALID, DRIVER_TIMEOUT, DRIVER_HARD, DRIVER_SENSE};
-#define NUM_DRIVERBYTE_STRS ARRAY_SIZE(driverbyte_table)
-
-void scsi_show_result(struct scsi_device *sdev, const char *name, int
result)
-{
-int hb = host_byte(result);
-int db = driver_byte(result);
-const char *hb_string;
-const char *db_string;
-
-hb_string = (hb  NUM_HOSTBYTE_STRS) ? hostbyte_table[hb] :
invalid;
-db_string = (db  NUM_DRIVERBYTE_STRS) ?
-driverbyte_table[db] : invalid;
-
-
-sdev_printk(KERN_INFO, sdev,
-[%s] Result: hostbyte=%s driverbyte=%s\n,
-name, hb_string, db_string);
-}
-
-#else
-
-void scsi_show_result(struct scsi_device *sdev, const char *name, int
result)
-{
-sdev_printk(KERN_INFO, sdev,
-[%s] Result: hostbyte=0x%02x driverbyte=0x%02x\n,
-name, host_byte(result), driver_byte(result));
-}
-
-#endif
-EXPORT_SYMBOL(scsi_show_result);
-
-void scsi_print_result(struct scsi_cmnd *cmd)
-{
-const char *devname = cmd-request-rq_disk ?
-cmd-request-rq_disk-disk_name : scsi;
-scsi_show_result(cmd-device, devname, cmd-result);
-}
-EXPORT_SYMBOL(scsi_print_result);
diff --git a/drivers/scsi/scsi_trace.c b/drivers/scsi/scsi_trace.c
index 2bea4f0..6ffbc40 100644
--- a/drivers/scsi/scsi_trace.c
+++ b/drivers/scsi/scsi_trace.c
@@ -19,6 +19,8 @@
  #include linux/trace_seq.h
  #include trace/events/scsi.h

+#include scsi/scsi_dbg.h
+
  #define SERVICE_ACTION16(cdb) (cdb[1]  0x1f)
  #define SERVICE_ACTION32(cdb) ((cdb[8]  8) | cdb[9])

@@ -286,3 +288,17 @@ scsi_trace_parse_cdb(struct trace_seq *p,
unsigned char *cdb, int len)
  return scsi_trace_misc(p, cdb, len);
  }
  }
+
+void scsi_show_result(struct scsi_device *sdev, const char *name, int
result)
+{
+trace_scsi_show_result(sdev, name, result);
+}
+EXPORT_SYMBOL(scsi_show_result);
+
+void scsi_print_result(struct scsi_cmnd *cmd)
+{
+const char *devname = cmd-request-rq_disk ?
+cmd-request-rq_disk-disk_name : scsi;
+scsi_show_result(cmd-device, devname, cmd-result);
+}
+EXPORT_SYMBOL(scsi_print_result);
diff --git a/include/trace/events/scsi.h b/include/trace/events/scsi.h
index 8aecdc2..0675195 100644
--- a/include/trace/events/scsi.h
+++ b/include/trace/events/scsi.h
@@ -123,7 +123,11 @@
  scsi_hostbyte_name(DID_IMM_RETRY),\
  scsi_hostbyte_name(DID_REQUEUE),\
  scsi_hostbyte_name(DID_TRANSPORT_DISRUPTED),\
-scsi_hostbyte_name(DID_TRANSPORT_FAILFAST))
+scsi_hostbyte_name(DID_TRANSPORT_FAILFAST),\
+scsi_hostbyte_name(DID_TARGET_FAILURE),\
+scsi_hostbyte_name(DID_NEXUS_FAILURE),\
+scsi_hostbyte_name(DID_ALLOC_FAILURE),\
+scsi_hostbyte_name(DID_MEDIUM_ERROR))

  #define scsi_driverbyte_name(result){ result, #result }
  #define show_driverbyte_name(val)\
@@ -359,6 +363,38 @@ TRACE_EVENT(scsi_eh_wakeup,
  TP_printk(host_no=%u, __entry-host_no)
  );

+TRACE_EVENT(scsi_show_result,
+
+TP_PROTO(struct scsi_device *sdev, const char *devname, 

Re: Re: [RFC PATCH 08/10] scsi/trace: Use scsi_print_sense trace point instead of printk

[Yoshihiro YUNOMAE]

(2014/08/27 23:15), Hannes Reinecke wrote:

On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:

Previous sense messages can be mixed into other sense messages,
because continuous printk (KERN_CONT) was used. To avoid the problem,
patch d87f3a6f51 introduced a local buffer in Hannes's baranch (*1).
But using local buffers can induce stack overflow, so we want to solve
the
problem without local buffer if possible.

trace_seq_printf can add log messages without local buffer, so we use it.

(*1)
http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging


- Result examples

Before (printk)
sd 2:0:0:0: [sda] Sense Key : Medium Error [current]

After (ftrace)
scsi_print_sense: host_no=2 channel=0 id=0 lun=0 [sda] Sense Key
(Medium Error [current])

Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Hannes Reinecke h...@suse.de
Cc: Doug Gilbert dgilb...@interlog.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
  drivers/scsi/constants.c|  145
++-
  drivers/scsi/scsi_trace.c   |  140
--
  include/scsi/scsi_eh.h  |7 ++
  include/trace/events/scsi.h |   48 ++
  4 files changed, 195 insertions(+), 145 deletions(-)

diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index f7b7f32..85b75c8 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -19,7 +19,7 @@
  #include scsi/scsi_eh.h
  #include scsi/scsi_dbg.h

-
+#include trace/events/scsi.h

  /* Commands with service actions that change the command name */
  #define SERVICE_ACTION_IN_12 0xab
@@ -1267,58 +1267,8 @@ static const struct error_info2 additional2[] =
  {0x70, 0x00, 0xff, Decompression exception short algorithm id
of %x},
  {0, 0, 0, NULL}
  };
-
-/* description of the sense key values */
-static const char * const snstext[] = {
-No Sense,/* 0: There is no sense information */
-Recovered Error,  /* 1: The last command completed successfully
-  but used error correction */
-Not Ready,/* 2: The addressed target is not ready */
-Medium Error,/* 3: Data error detected on the medium */
-Hardware Error,   /* 4: Controller or device failure */
-Illegal Request,  /* 5: Error in request */
-Unit Attention,   /* 6: Removable medium was changed, or
-  the target has been reset, or ... */
-Data Protect,/* 7: Access to the data is blocked */
-Blank Check,/* 8: Reached unexpected written or unwritten
-  region of the medium */
-Vendor Specific(9),
-Copy Aborted,/* A: COPY or COMPARE was aborted */
-Aborted Command,  /* B: The target aborted the command */
-Equal,/* C: A SEARCH DATA command found data equal,
-  reserved in SPC-4 rev 36 */
-Volume Overflow,  /* D: Medium full with still data to be
written */
-Miscompare,/* E: Source data and data on the medium
-  do not agree */
-Completed,/* F: command completed sense data reported,
-  may occur for successful command */
-};
-#else
-static const char * const snstext[] = {
-0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7,
-0x8, 0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf,
-};
  #endif

-/* Get sense key string or NULL if not available */
-const char *
-scsi_sense_key_string(unsigned char key) {
-return snstext[key  0xf];
-}
-EXPORT_SYMBOL(scsi_sense_key_string);
-
-const char *
-scsi_sense_type_string(struct scsi_sense_hdr *sshdr)
-{
-return scsi_sense_is_deferred(sshdr) ? [deferred] : [current];
-}
-
-const char *
-scsi_sense_format_string(struct scsi_sense_hdr *sshdr)
-{
-return sshdr-response_code = 0x72 ? [descriptor] : ;
-}
-
  /*
   * Get additional sense code string or NULL if not available.
   * This string may contain a %x and should be printed with ascq as
arg.
@@ -1375,105 +1325,22 @@ void
  scsi_print_sense_hdr(struct scsi_device *sdev, const char *name,
   struct scsi_sense_hdr *sshdr)
  {
-sdev_printk(KERN_INFO, sdev, [%s] Sense Key : %s %s%s\n, name,
-scsi_sense_key_string(sshdr-sense_key),
-scsi_sense_type_string(sshdr),
-scsi_sense_format_string(sshdr));
+trace_scsi_print_sense(sdev, name, sshdr, NULL, 0, 0);
  scsi_show_extd_sense(sdev, name, sshdr-asc, sshdr-ascq);
  }
  EXPORT_SYMBOL(scsi_print_sense_hdr);

-static void
-scsi_dump_sense_buffer(struct scsi_device *sdev, const char *prefix,
-   const unsigned char *sense_buffer, int sense_len)
-{
-char linebuf[128];
-int i, linelen, remaining;
-
-if (sense_len  32)
-sense_len = 32;
-
-remaining = sense_len;
-for (i = 0; i  sense_len; i += 16) {
-

Re: Re: [RFC PATCH 09/10] scsi/trace: Add additional sense code and additional sense code qualifier to scsi_print_sense trace point

[Yoshihiro YUNOMAE]

(2014/08/27 23:16), Hannes Reinecke wrote:

On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:

There are no mean that additional sense code and additional sense code
qualifier
are output as different messages of sense key, so those information
are added.

Note:
scsi_show_extd_sense() is changed from export symbol to non-export
symbol.

  - Result examples

Before (printk)
sd 2:0:0:0: [sda] Add. Sense: Unrecovered read error

After (ftrace, merged into scsi_print_sense traceevent)
scsi_print_sense: host_no=2 channel=0 id=0 lun=0 [sda] Sense Key
(Medium Error [current])  Add. Sense (Unrecovered read error)

Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Hannes Reinecke h...@suse.de
Cc: Doug Gilbert dgilb...@interlog.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
  drivers/scsi/constants.c|  932
---
  drivers/scsi/scsi_trace.c   |  920
++
  include/scsi/scsi_dbg.h |2
  include/trace/events/scsi.h |   10
  4 files changed, 928 insertions(+), 936 deletions(-)

diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
index 85b75c8..ce9ceb8 100644
--- a/drivers/scsi/constants.c
+++ b/drivers/scsi/constants.c
@@ -14,12 +14,6 @@

  #include scsi/scsi.h
  #include scsi/scsi_cmnd.h
-#include scsi/scsi_device.h
-#include scsi/scsi_host.h
-#include scsi/scsi_eh.h
-#include scsi/scsi_dbg.h
-
-#include trace/events/scsi.h

  /* Commands with service actions that change the command name */
  #define SERVICE_ACTION_IN_12 0xab
@@ -429,929 +423,3 @@ void scsi_print_command(struct scsi_cmnd *cmd)
  print_opcode_name(cmd-device, devname, cmd-cmnd, cmd-cmd_len);
  }
  EXPORT_SYMBOL(scsi_print_command);
-
-#ifdef CONFIG_SCSI_CONSTANTS
-
-struct error_info {
-unsigned short code12;/* 0x0302 looks better than 0x03,0x02 */
-const char * text;
-};
-
-/*
- * The canonical list of T10 Additional Sense Codes is available at:
- * http://www.t10.org/lists/asc-num.txt [most recent: 20130605]
- */
-
-static const struct error_info additional[] =
-{
-{0x, No additional sense information},
-{0x0001, Filemark detected},
-{0x0002, End-of-partition/medium detected},
-{0x0003, Setmark detected},
-{0x0004, Beginning-of-partition/medium detected},
-{0x0005, End-of-data detected},
-{0x0006, I/O process terminated},
-{0x0007, Programmable early warning detected},
-{0x0011, Audio play operation in progress},
-{0x0012, Audio play operation paused},
-{0x0013, Audio play operation successfully completed},
-{0x0014, Audio play operation stopped due to error},
-{0x0015, No current audio status to return},
-{0x0016, Operation in progress},
-{0x0017, Cleaning requested},
-{0x0018, Erase operation in progress},
-{0x0019, Locate operation in progress},
-{0x001A, Rewind operation in progress},
-{0x001B, Set capacity operation in progress},
-{0x001C, Verify operation in progress},
-{0x001D, ATA pass through information available},
-{0x001E, Conflicting SA creation request},
-{0x001F, Logical unit transitioning to another power condition},
-{0x0020, Extended copy information available},
-
-{0x0100, No index/sector signal},
-
-{0x0200, No seek complete},
-
-{0x0300, Peripheral device write fault},
-{0x0301, No write current},
-{0x0302, Excessive write errors},
-
-{0x0400, Logical unit not ready, cause not reportable},
-{0x0401, Logical unit is in process of becoming ready},
-{0x0402, Logical unit not ready, initializing command required},
-{0x0403, Logical unit not ready, manual intervention required},
-{0x0404, Logical unit not ready, format in progress},
-{0x0405, Logical unit not ready, rebuild in progress},
-{0x0406, Logical unit not ready, recalculation in progress},
-{0x0407, Logical unit not ready, operation in progress},
-{0x0408, Logical unit not ready, long write in progress},
-{0x0409, Logical unit not ready, self-test in progress},
-{0x040A, Logical unit not accessible, asymmetric access state 
- transition},
-{0x040B, Logical unit not accessible, target port in standby
state},
-{0x040C, Logical unit not accessible, target port in unavailable 
- state},
-{0x040D, Logical unit not ready, structure check required},
-{0x0410, Logical unit not ready, auxiliary memory not accessible},
-{0x0411, Logical unit not ready, notify (enable spinup) required},
-{0x0412, Logical unit not ready, offline},
-{0x0413, Logical unit not ready, SA creation in progress},
-{0x0414, Logical unit not ready, space allocation in progress},
-{0x0415, Logical unit not ready, robotics disabled},
-{0x0416, Logical unit not ready, configuration 

Re: Re: [RFC PATCH 10/10] scsi/trace: Use scsi_print_command trace point instead of printk

[Yoshihiro YUNOMAE]

(2014/08/27 23:16), Hannes Reinecke wrote:

On 08/08/2014 01:50 PM, Yoshihiro YUNOMAE wrote:

Previous printk messages of SCSI command can be mixed into other printk
messages because multiple printk messages are output for it. To avoid the
problem, patch 4e64bb8d6 in Hannes' branch(*1) introduced a local buffer.
But using local buffers can induce stack overflow, so we want to solve
the
problem without local buffer if possible.

trace_seq_printf can add log messages without local buffer, so we use it.

Note:
We don't need constans.c any more.

(*1)
http://git.kernel.org/cgit/linux/kernel/git/hare/scsi-devel.git/log/?h=logging


  - Result examples

Before (printk)
sd 2:0:0:0: [sda] CDB: Read(10)

After
scsi_print_command: host_no=2 channel=0 id=0 lun=0 [sda] CDB (Read(10))

Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com
Cc: Hannes Reinecke h...@suse.de
Cc: Doug Gilbert dgilb...@interlog.com
Cc: Martin K. Petersen martin.peter...@oracle.com
Cc: Christoph Hellwig h...@lst.de
Cc: James E.J. Bottomley jbottom...@parallels.com
Cc: Hidehiro Kawai hidehiro.kawai...@hitachi.com
Cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
---
  drivers/scsi/Makefile   |2
  drivers/scsi/constants.c|  425
---
  drivers/scsi/scsi_trace.c   |  408
+
  include/scsi/scsi.h |8 +
  include/trace/events/scsi.h |   45 +
  5 files changed, 461 insertions(+), 427 deletions(-)
  delete mode 100644 drivers/scsi/constants.c

diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 5f0d299..c56f692 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -158,7 +158,7 @@ obj-$(CONFIG_SCSI_OSD_INITIATOR) += osd/
  # This goes last, so that real scsi devices probe earlier
  obj-$(CONFIG_SCSI_DEBUG)+= scsi_debug.o

-scsi_mod-y+= scsi.o hosts.o scsi_ioctl.o constants.o \
+scsi_mod-y+= scsi.o hosts.o scsi_ioctl.o \
 scsicam.o scsi_error.o scsi_lib.o
  scsi_mod-$(CONFIG_SCSI_DMA)+= scsi_lib_dma.o
  scsi_mod-y+= scsi_scan.o scsi_sysfs.o scsi_devinfo.o
diff --git a/drivers/scsi/constants.c b/drivers/scsi/constants.c
deleted file mode 100644
index ce9ceb8..000
--- a/drivers/scsi/constants.c
+++ /dev/null
@@ -1,425 +0,0 @@
-/*
- * ASCII values for a number of symbolic constants, printing functions,
- * etc.
- * Additions for SCSI 2 and Linux 2.2.x by D. Gilbert (990422)
- * Additions for SCSI 3+ (SPC-3 T10/1416-D Rev 07 3 May 2002)
- *   by D. Gilbert and aeb (20020609)
- * Updated to SPC-4 T10/1713-D Rev 36g, D. Gilbert 20130701
- */
-
-#include linux/blkdev.h
-#include linux/module.h
-#include linux/kernel.h
-#include asm/unaligned.h
-
-#include scsi/scsi.h
-#include scsi/scsi_cmnd.h
-
-/* Commands with service actions that change the command name */
-#define SERVICE_ACTION_IN_12 0xab
-#define SERVICE_ACTION_OUT_12 0xa9
-#define SERVICE_ACTION_BIDIRECTIONAL 0x9d
-#define SERVICE_ACTION_IN_16 0x9e
-#define SERVICE_ACTION_OUT_16 0x9f
-#define THIRD_PARTY_COPY_OUT 0x83
-#define THIRD_PARTY_COPY_IN 0x84
-
-
-
-#ifdef CONFIG_SCSI_CONSTANTS
-static const char * cdb_byte0_names[] = {
-/* 00-03 */ Test Unit Ready, Rezero Unit/Rewind, NULL, Request
Sense,
-/* 04-07 */ Format Unit/Medium, Read Block Limits, NULL,
-Reassign Blocks,
-/* 08-0d */ Read(6), NULL, Write(6), Seek(6), NULL, NULL,
-/* 0e-12 */ NULL, Read Reverse, Write Filemarks, Space, Inquiry,
-/* 13-16 */ Verify(6), Recover Buffered Data, Mode Select(6),
-Reserve(6),
-/* 17-1a */ Release(6), Copy, Erase, Mode Sense(6),
-/* 1b-1d */ Start/Stop Unit, Receive Diagnostic, Send Diagnostic,
-/* 1e-1f */ Prevent/Allow Medium Removal, NULL,
-/* 20-22 */  NULL, NULL, NULL,
-/* 23-28 */ Read Format Capacities, Set Window,
-Read Capacity(10), NULL, NULL, Read(10),
-/* 29-2d */ Read Generation, Write(10), Seek(10), Erase(10),
-Read updated block,
-/* 2e-31 */ Write Verify(10), Verify(10), Search High, Search
Equal,
-/* 32-34 */ Search Low, Set Limits, Prefetch/Read Position,
-/* 35-37 */ Synchronize Cache(10), Lock/Unlock Cache(10),
-Read Defect Data(10),
-/* 38-3c */ Medium Scan, Compare, Copy Verify, Write Buffer,
-Read Buffer,
-/* 3d-3f */ Update Block, Read Long(10),  Write Long(10),
-/* 40-41 */ Change Definition, Write Same(10),
-/* 42-48 */ Unmap/Read sub-channel, Read TOC/PMA/ATIP,
-Read density support, Play audio(10), Get configuration,
-Play audio msf, Sanitize/Play audio track/index,
-/* 49-4f */ Play track relative(10), Get event status notification,
-Pause/resume, Log Select, Log Sense, Stop play/scan,
-NULL,
-/* 50-55 */ Xdwrite, Xpwrite, Read disk info, Xdread, Read track
info,
-Reserve track, Send OPC info, Mode Select(10),
-/* 56-5b */ Reserve(10), Release(10), Repair track, Read
master cue,
-Mode Sense(10), Close track/session,
-/* 5c-5f */ Read buffer capacity, 

[Bug 83391] New: Oops on sd_mod

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=83391

Bug ID: 83391
   Summary: Oops  on sd_mod
   Product: SCSI Drivers
   Version: 2.5
Kernel Version: 2.6.32
  Hardware: i386
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Other
  Assignee: scsi_drivers-ot...@kernel-bugs.osdl.org
  Reporter: tomsunc...@gmail.com
Regression: No

Now i met the oops of sd_mod more times, but i don't know the condition that
the oops occured, the info as below.

BUG: unable to handle kernel paging request at 88001488c004
IP: [a019d01c] sd_revalidate_disk+0x107c/0x1900 [sd_mod]
PGD 1a05067 PUD 1a09067 PMD 176067 PTE 0
Oops:  [#1] SMP 
last sysfs file:
/sys/devices/pci:00/:00:1f.2/host0/scsi_host/host0/scan

Pid: 31, comm: ata_aux Tainted: G C   
2.6.32-220.el6.x86_64 #1 LENOVO QiTianM8250/LENOVO
RIP: e030:[a019d01c]  [a019d01c]
sd_revalidate_disk+0x107c/0x1900 [sd_mod]
RSP: e02b:88003eacbc60  EFLAGS: 00010246
RAX: 880039948000 RBX: 880039971000 RCX: 0001
RDX:  RSI:  RDI: 88003819b420
RBP: 88003eacbd40 R08: 0018 R09: 
R10:  R11:  R12: 88001488bfe0
R13: 0200 R14: 88003fc00040 R15: 0200
FS:  7f92c694c700() GS:880004ff7000() knlGS:
CS:  e033 DS:  ES:  CR0: 8005003b
CR2: 88001488c004 CR3: 379b9000 CR4: 2660
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process ata_aux (pid: 31, threadinfo 88003eaca000, task 88003eac6b00)
Stack:
 88007530 0005  8139c890
0 88003eac71a0  88003eacbcf2 
0 88003a21aa00 2542eab0 880039957800 880039948000
Call Trace:
 [8139c890] ? ata_scsi_dev_rescan+0x0/0x110
 [8126ffda] ? kobject_get+0x1a/0x30
 [8126] ? blkiocg_file_read_map+0xe0/0x100
 [811b1428] revalidate_disk+0x38/0x90
 [a01994b7] sd_rescan+0x27/0x40 [sd_mod]
 [8138b07d] scsi_rescan_device+0x8d/0xe0
 [813697c9] ? get_device+0x19/0x20
 [8139c94a] ata_scsi_dev_rescan+0xba/0x110
 [8139c890] ? ata_scsi_dev_rescan+0x0/0x110
 [8108c630] worker_thread+0x170/0x2a0
 [81091fc0] ? autoremove_wake_function+0x0/0x40
 [814daf2c] ? _spin_unlock_irqrestore+0x1c/0x20
 [8108c4c0] ? worker_thread+0x0/0x2a0
 [81091c56] kthread+0x96/0xa0
 [8100d14a] child_rip+0xa/0x20
 [8100c314] ? int_ret_from_sys_call+0x7/0x1b
 [8100ca9d] ? retint_restore_args+0x5/0x6
 [8100d140] ? child_rip+0x0/0x20

crash l* sd_revalidate_disk+0x107c
0xa019d01c is in sd_revalidate_disk
(/usr/src/debug/kernel-2.6.32/linux-2.6.32/arch/x86/include/asm/swab.h:53).
48  : =r (v.s.a), =r (v.s.b)
49  : 0 (v.s.a), 1 (v.s.b));
50  # endif
51  return v.u;
52  #else /* __i386__ */
53  asm(bswapq %0
54  : =r (val)
55  : 0 (val));
56  return val;
57  #endif

Would you give me suggestions for this oops? thank you very much!

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Bug 83391] Oops on sd_mod

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=83391

--- Comment #1 from tomsun tomsunc...@gmail.com ---
Created attachment 148621
  -- https://bugzilla.kernel.org/attachment.cgi?id=148621action=edit
the function disassemble info

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 13/17] arcmsr: fix ioctl data read/write error for adapter type C

[Ching Huang]

On Wed, 2014-08-27 at 14:29 +0200, Tomas Henzl wrote:
 On 08/27/2014 10:19 PM, Ching Huang wrote:
  On Tue, 2014-08-26 at 15:20 +0200, Tomas Henzl wrote:
  On 08/26/2014 10:27 PM, Ching Huang wrote:
  On Mon, 2014-08-25 at 12:29 +0200, Tomas Henzl wrote:
  On 08/25/2014 07:59 PM, Ching Huang wrote:
  On Fri, 2014-08-22 at 18:00 +0200, Tomas Henzl wrote:
  On 08/19/2014 09:17 AM, Ching Huang wrote:
  From: Ching Huang ching2...@areca.com.tw
 
  Rewrite ioctl entry and its relate function.
  This patch fix ioctl data read/write error and change data I/O access 
  from byte to Dword.
 
  Signed-off-by: Ching Huang ching2...@areca.com.tw
  ---
 
  diff -uprN a/drivers/scsi/arcmsr/arcmsr_attr.c 
  b/drivers/scsi/arcmsr/arcmsr_attr.c
  --- a/drivers/scsi/arcmsr/arcmsr_attr.c   2014-02-06 
  17:47:24.0 +0800
  +++ b/drivers/scsi/arcmsr/arcmsr_attr.c   2014-04-29 
  17:10:42.0 +0800
  @@ -70,40 +70,75 @@ static ssize_t arcmsr_sysfs_iop_message_
struct AdapterControlBlock *acb = (struct AdapterControlBlock 
  *) host-hostdata;
uint8_t *pQbuffer,*ptmpQbuffer;
int32_t allxfer_len = 0;
  + unsigned long flags;
   
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
   
/* do message unit read. */
ptmpQbuffer = (uint8_t *)buf;
  - while ((acb-rqbuf_firstindex != acb-rqbuf_lastindex)
  -  (allxfer_len  1031)) {
  + spin_lock_irqsave(acb-rqbuffer_lock, flags);
  + if (acb-rqbuf_firstindex != acb-rqbuf_lastindex) {
  Hi - does this condition (acb-rqbuf_firstindex == 
  acb-rqbuf_lastindex) mean we could just release 
  the spinlock and return ?
   
  NO. We have to check the input buffer that may have message data come
  from IOP.
pQbuffer = acb-rqbuffer[acb-rqbuf_firstindex];
  - memcpy(ptmpQbuffer, pQbuffer, 1);
  - acb-rqbuf_firstindex++;
  - acb-rqbuf_firstindex %= ARCMSR_MAX_QBUFFER;
  - ptmpQbuffer++;
  - allxfer_len++;
  + if (acb-rqbuf_firstindex  acb-rqbuf_lastindex) {
  + if ((ARCMSR_MAX_QBUFFER - 
  acb-rqbuf_firstindex) = 1032) {
  + memcpy(ptmpQbuffer, pQbuffer, 1032);
  + acb-rqbuf_firstindex += 1032;
  + acb-rqbuf_firstindex %= 
  ARCMSR_MAX_QBUFFER;
  + allxfer_len = 1032;
  + } else {
  + if (((ARCMSR_MAX_QBUFFER - 
  acb-rqbuf_firstindex)
  + + acb-rqbuf_lastindex)  1032) 
  {
  + memcpy(ptmpQbuffer, pQbuffer,
  + ARCMSR_MAX_QBUFFER
  + - 
  acb-rqbuf_firstindex);
  + ptmpQbuffer += 
  ARCMSR_MAX_QBUFFER
  + - acb-rqbuf_firstindex;
  + memcpy(ptmpQbuffer, 
  acb-rqbuffer, 1032
  + - (ARCMSR_MAX_QBUFFER -
  + acb-rqbuf_firstindex));
  This code looks like you were copying some data from a ring buffer,
  in that case - shouldn't be acb-rqbuf_lastindex used instead of 
  firstindex?
 
  Yes, there copying data from a ring buffer. firstindex and lastindex are
  bad name. For readability, I rename the firstindex to getIndex,
  lastindex to putIndex. 
  My comment is not about names, but in this path '(ARCMSR_MAX_QBUFFER - 
  acb-rqbuf_firstindex)+ acb-rqbuf_lastindex)  1032)'
  you copy something twice and in both cases the 'firstindex' is used and 
  never the 'lastindex'.
  Is this correct?
  The firstindex is a get index and lastindex is a put index of a ring 
  buffer.
  At here, firstindex  lastindex, so the data remain in buffer are 
  (ARCMSR_MAX_QBUFFER - acb-rqbuf_firstindex)+ acb-rqbuf_lastindex
  Yes, it's correct, I misinterpreted the from value with the amount of 
  bytes to copy.
  But well it's also still overcomplicated and I believe that a copy like 
  this could be
  rearranged with just few lines of code as a result - have you looked at 
  the code I sent?
 
  Let's go with this patch as it is otherwise we will never end, repost is 
  not needed because 
  of this and also not because of arcmsr_Read_iop_rqbuffer_in_DWORD.
 
  I'll continue with reviewing the remaining patches.
 
  tomas
 
  I have test the code you sent. It works.
  I will modify the code by your idea, then send the patch.
 
 I think that after so many repost, and because it is not a fix, wait till we 
 get this series in
 and post a new patch later. 
 Btw. a similar copying is in arcmsr_iop_message_xfer too, and whet you want 
 rename the fields
 in your ring buffer, please use the more usual names 'head+tail'.
 
 Conclusion - post nothing right now, let the changes go in in a new patch.
 
 

[PATCH V6 5/5] add xen pvscsi maintainer

[Juergen Gross]

Add myself as maintainer for the Xen pvSCSI stuff.

Signed-off-by: Juergen Gross jgr...@suse.com
Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1ff06de..0ae6238 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10128,6 +10128,15 @@ S: Supported
 F: drivers/block/xen-blkback/*
 F: drivers/block/xen*
 
+XEN PVSCSI DRIVERS
+M: Juergen Gross jgr...@suse.com
+L: xen-de...@lists.xenproject.org (moderated for non-subscribers)
+L: linux-scsi@vger.kernel.org
+S: Supported
+F: drivers/scsi/xen-scsifront.c
+F: drivers/xen/xen-scsiback.c
+F: include/xen/interface/io/vscsiif.h
+
 XEN SWIOTLB SUBSYSTEM
 M: Konrad Rzeszutek Wilk konrad.w...@oracle.com
 L: xen-de...@lists.xenproject.org (moderated for non-subscribers)
-- 
1.8.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V6 0/5] Add XEN pvSCSI support

[Juergen Gross]

This series adds XEN pvSCSI support. With pvSCSI it is possible to use physical
SCSI devices from a XEN domain.

The support consists of a backend in the privileged Domain-0 doing the real
I/O and a frontend in the unprivileged domU passing I/O-requests to the backend.

The code is taken (and adapted) from the original pvSCSI implementation done
for Linux 2.6 in 2008 by Fujitsu.

Changes in V6:
- changes in scsifront module after comments from Konrad Wilk
- remove double kfree in scsiback
- comments in vscsiif.h adapted after comments from Jan Beulich and
  David Vrabel in xen-devel
- added linux-scsi@vger.kernel.org to MAINTANERS entry

Changes in V5:
- Added patch to support threaded irqs for interdomain event channels
- several changes in xen-scsifront after comments from Christoph Hellwig
- several changes in xen-scsiback after comments from Christoph Hellwig
- several changes in xen-scsiback after comments from James Bottomley
- several changes in xen-scsiback after comments from Nicholas Bellinger

Changes in V4:
- Re-add define for VSCSIIF_ACT_SCSI_SG_PRESET to vscsiif.h to indicate this
  action value should not be used in future enhancements

Changes in V3:
- added some comments to the protocol header file
- removed the CDB emulation from xen-scsiback, handled by core target
  infrastructure
- several changes in xen-scsifront after comments from Christoph Hellwig

Changes in V2:
- use core target infrastructure by backend instead of pure SCSI passthrough
- add support for larger SG lists by putting them in grant page(s)
- add command abort capability


Juergen Gross (5):
  xen/events: support threaded irqs for interdomain event channels
  Add XEN pvSCSI protocol description
  Introduce xen-scsifront module
  Introduce XEN scsiback module
  add xen pvscsi maintainer

 MAINTAINERS|9 +
 drivers/scsi/Kconfig   |9 +
 drivers/scsi/Makefile  |1 +
 drivers/scsi/xen-scsifront.c   | 1024 +
 drivers/xen/Kconfig|9 +
 drivers/xen/Makefile   |1 +
 drivers/xen/events/events_base.c   |5 +-
 drivers/xen/xen-scsiback.c | 2124 
 include/xen/events.h   |2 +
 include/xen/interface/io/vscsiif.h |  229 
 10 files changed, 3411 insertions(+), 2 deletions(-)
 create mode 100644 drivers/scsi/xen-scsifront.c
 create mode 100644 drivers/xen/xen-scsiback.c
 create mode 100644 include/xen/interface/io/vscsiif.h

-- 
1.8.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V6 2/5] Add XEN pvSCSI protocol description

[Juergen Gross]

Add the definition of pvSCSI protocol used between the pvSCSI frontend in a
XEN domU and the pvSCSI backend in a XEN driver domain (usually Dom0).

This header was originally provided by Fujitsu for XEN based on Linux 2.6.18.
Changes are:
- added comment
- adapt to Linux style guide
- add support for larger SG-lists by putting them in an own granted page
- remove stale definitions

Signed-off-by: Juergen Gross jgr...@suse.com
---
 include/xen/interface/io/vscsiif.h | 229 +
 1 file changed, 229 insertions(+)
 create mode 100644 include/xen/interface/io/vscsiif.h

diff --git a/include/xen/interface/io/vscsiif.h 
b/include/xen/interface/io/vscsiif.h
new file mode 100644
index 000..d07d7ac
--- /dev/null
+++ b/include/xen/interface/io/vscsiif.h
@@ -0,0 +1,229 @@
+/**
+ * vscsiif.h
+ *
+ * Based on the blkif.h code.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Copyright(c) FUJITSU Limited 2008.
+ */
+
+#ifndef __XEN__PUBLIC_IO_SCSI_H__
+#define __XEN__PUBLIC_IO_SCSI_H__
+
+#include ring.h
+#include ../grant_table.h
+
+/*
+ * Feature and Parameter Negotiation
+ * =
+ * The two halves of a Xen pvSCSI driver utilize nodes within the XenStore to
+ * communicate capabilities and to negotiate operating parameters.  This
+ * section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * Any specified default value is in effect if the corresponding XenBus node
+ * is not present in the XenStore.
+ *
+ * XenStore nodes in sections marked PRIVATE are solely for use by the
+ * driver side whose XenBus tree contains them.
+ *
+ *
+ *Backend XenBus Nodes
+ *
+ *
+ *-- Backend Device Identification (PRIVATE) --
+ *
+ * p-devname
+ *  Values: string
+ *
+ *  A free string used to identify the physical device (e.g. a disk name).
+ *
+ * p-dev
+ *  Values: string
+ *
+ *  A string specifying the backend device: either a 4-tuple h:c:t:l
+ *  (host, controller, target, lun, all integers), or a WWN (e.g.
+ *  naa.60014054ac780582).
+ *
+ * v-dev
+ *  Values: string
+ *
+ *  A string specifying the frontend device in form of a 4-tuple h:c:t:l
+ *  (host, controller, target, lun, all integers).
+ *
+ *- Features -
+ *
+ * feature-sg-grant
+ *  Values: unsigned [VSCSIIF_SG_TABLESIZE...65535]
+ *  Default Value:  0
+ *
+ *  Specifies the maximum number of scatter/gather elements in grant pages
+ *  supported. If not set, the backend supports up to VSCSIIF_SG_TABLESIZE
+ *  SG elements specified directly in the request.
+ *
+ *
+ *Frontend XenBus Nodes
+ *
+ *
+ *--- Request Transport Parameters ---
+ *
+ * event-channel
+ *  Values: unsigned
+ *
+ *  The identifier of the Xen event channel used to signal activity
+ *  in the ring buffer.
+ *
+ * ring-ref
+ *  Values: unsigned
+ *
+ *  The Xen grant reference granting permission for the backend to map
+ *  the sole page in a single page sized ring buffer.
+ *
+ * protocol
+ *  Values: string (XEN_IO_PROTO_ABI_*)
+ *  Default Value:  XEN_IO_PROTO_ABI_NATIVE
+ *
+ *  The machine ABI rules governing the format of all ring request and
+ *  response structures.
+ */
+
+/* Requests from the 

[PATCH V6 1/5] xen/events: support threaded irqs for interdomain event channels

[Juergen Gross]

Export bind_interdomain_evtchn_to_irq() so drivers can use threaded
interrupt handlers with:

 irq = bind_interdomain_evtchn_to_irq(remote_dom, remote_port);
 if (irq  0)
 /* error */
 ret = request_threaded_irq(...);

Signed-off-by: Juergen Gross jgr...@suse.com
Acked-by: David Vrabel david.vra...@citrix.com
Acked-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
 drivers/xen/events/events_base.c | 5 +++--
 include/xen/events.h | 2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 5b5c5ff..b4bca2d 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -900,8 +900,8 @@ static int bind_ipi_to_irq(unsigned int ipi, unsigned int 
cpu)
return irq;
 }
 
-static int bind_interdomain_evtchn_to_irq(unsigned int remote_domain,
- unsigned int remote_port)
+int bind_interdomain_evtchn_to_irq(unsigned int remote_domain,
+  unsigned int remote_port)
 {
struct evtchn_bind_interdomain bind_interdomain;
int err;
@@ -914,6 +914,7 @@ static int bind_interdomain_evtchn_to_irq(unsigned int 
remote_domain,
 
return err ? : bind_evtchn_to_irq(bind_interdomain.local_port);
 }
+EXPORT_SYMBOL_GPL(bind_interdomain_evtchn_to_irq);
 
 static int find_virq(unsigned int virq, unsigned int cpu)
 {
diff --git a/include/xen/events.h b/include/xen/events.h
index 8bee7a7..5321cd9 100644
--- a/include/xen/events.h
+++ b/include/xen/events.h
@@ -28,6 +28,8 @@ int bind_ipi_to_irqhandler(enum ipi_vector ipi,
   unsigned long irqflags,
   const char *devname,
   void *dev_id);
+int bind_interdomain_evtchn_to_irq(unsigned int remote_domain,
+  unsigned int remote_port);
 int bind_interdomain_evtchn_to_irqhandler(unsigned int remote_domain,
  unsigned int remote_port,
  irq_handler_t handler,
-- 
1.8.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V6 3/5] Introduce xen-scsifront module

[Juergen Gross]

Introduces the XEN pvSCSI frontend. With pvSCSI it is possible for a XEN domU
to issue SCSI commands to a SCSI LUN assigned to that domU. The SCSI commands
are passed to the pvSCSI backend in a driver domain (usually Dom0) which is
owner of the physical device. This allows e.g. to use SCSI tape drives in a
XEN domU.

The code is taken from the pvSCSI implementation in XEN done by Fujitsu based
on Linux kernel 2.6.18.

Changes from the original version are:
- port to upstream kernel
- put all code in just one source file
- move module to appropriate location in kernel tree
- adapt to Linux style guide
- some minor code simplifications
- replace constants with defines
- remove not used defines
- add support for larger SG lists by putting them in a granted page

Signed-off-by: Juergen Gross jgr...@suse.com

Xen related parts
Acked-by: David Vrabel david.vra...@citrix.com
---
 drivers/scsi/Kconfig |9 +
 drivers/scsi/Makefile|1 +
 drivers/scsi/xen-scsifront.c | 1024 ++
 3 files changed, 1034 insertions(+)
 create mode 100644 drivers/scsi/xen-scsifront.c

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 18a3358..9130df1 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -576,6 +576,15 @@ config VMWARE_PVSCSI
  To compile this driver as a module, choose M here: the
  module will be called vmw_pvscsi.
 
+config XEN_SCSI_FRONTEND
+   tristate XEN SCSI frontend driver
+   depends on SCSI  XEN
+   help
+ The XEN SCSI frontend driver allows the kernel to access SCSI Devices
+ within another guest OS (usually Dom0).
+ Only needed if the kernel is running in a XEN guest and generic
+ SCSI access to a device is needed.
+
 config HYPERV_STORAGE
tristate Microsoft Hyper-V virtual storage driver
depends on SCSI  HYPERV
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 5f0d299..59f1ce6 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -141,6 +141,7 @@ obj-$(CONFIG_SCSI_ESAS2R)   += esas2r/
 obj-$(CONFIG_SCSI_PMCRAID) += pmcraid.o
 obj-$(CONFIG_SCSI_VIRTIO)  += virtio_scsi.o
 obj-$(CONFIG_VMWARE_PVSCSI)+= vmw_pvscsi.o
+obj-$(CONFIG_XEN_SCSI_FRONTEND)+= xen-scsifront.o
 obj-$(CONFIG_HYPERV_STORAGE)   += hv_storvsc.o
 
 obj-$(CONFIG_ARM)  += arm/
diff --git a/drivers/scsi/xen-scsifront.c b/drivers/scsi/xen-scsifront.c
new file mode 100644
index 000..0aceb70
--- /dev/null
+++ b/drivers/scsi/xen-scsifront.c
@@ -0,0 +1,1024 @@
+/*
+ * Xen SCSI frontend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/device.h
+#include linux/wait.h
+#include linux/interrupt.h
+#include linux/mutex.h
+#include linux/spinlock.h
+#include linux/sched.h
+#include linux/blkdev.h
+#include linux/pfn.h
+#include linux/slab.h
+#include linux/bitops.h
+
+#include scsi/scsi_cmnd.h
+#include scsi/scsi_device.h
+#include scsi/scsi.h
+#include scsi/scsi_host.h
+
+#include xen/xen.h
+#include xen/xenbus.h
+#include xen/grant_table.h
+#include xen/events.h
+#include xen/page.h
+
+#include xen/interface/grant_table.h
+#include xen/interface/io/vscsiif.h
+#include xen/interface/io/protocols.h
+
+#include asm/xen/hypervisor.h
+
+
+#define GRANT_INVALID_REF  0
+
+#define VSCSIFRONT_OP_ADD_LUN  1
+#define VSCSIFRONT_OP_DEL_LUN  2
+
+/* Tuning point. */
+#define VSCSIIF_DEFAULT_CMD_PER_LUN 10
+#define VSCSIIF_MAX_TARGET  64
+#define VSCSIIF_MAX_LUN 255
+
+#define 

[PATCH V6 4/5] Introduce XEN scsiback module

[Juergen Gross]

Introduces the XEN pvSCSI backend. With pvSCSI it is possible for a XEN domU
to issue SCSI commands to a SCSI LUN assigned to that domU. The SCSI commands
are passed to the pvSCSI backend in a driver domain (usually Dom0) which is
owner of the physical device. This allows e.g. to use SCSI tape drives in a
XEN domU.

The code is taken from the pvSCSI implementation in XEN done by Fujitsu based
on Linux kernel 2.6.18.

Changes from the original version are:
- port to upstream kernel
- put all code in just one source file
- adapt to Linux style guide
- use target core infrastructure instead doing pure pass-through
- enable module unloading
- support SG-list in grant page(s)
- support task abort
- remove redundant struct backend
- allocate resources dynamically
- correct minor error in scsiback_fast_flush_area
- free allocated resources in case of error during I/O preparation
- remove CDB emulation, now handled by target core infrastructure

Signed-off-by: Juergen Gross jgr...@suse.com

Xen related parts
Acked-by: David Vrabel david.vra...@citrix.com
Reviewed-by: Nicholas Bellinger n...@linux-iscsi.org
---
 drivers/xen/Kconfig|9 +
 drivers/xen/Makefile   |1 +
 drivers/xen/xen-scsiback.c | 2124 
 3 files changed, 2134 insertions(+)
 create mode 100644 drivers/xen/xen-scsiback.c

diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 8bc0183..b812462 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -172,6 +172,15 @@ config XEN_PCIDEV_BACKEND
 
  If in doubt, say m.
 
+config XEN_SCSI_BACKEND
+   tristate XEN SCSI backend driver
+   depends on XEN  XEN_BACKEND  TARGET_CORE
+   help
+ The SCSI backend driver allows the kernel to export its SCSI Devices
+ to other guests via a high-performance shared-memory interface.
+ Only needed for systems running as XEN driver domains (e.g. Dom0) and
+ if guests need generic access to SCSI devices.
+
 config XEN_PRIVCMD
tristate
depends on XEN
diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 84044b5..2140398 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_XEN_ACPI_HOTPLUG_MEMORY) += xen-acpi-memhotplug.o
 obj-$(CONFIG_XEN_ACPI_HOTPLUG_CPU) += xen-acpi-cpuhotplug.o
 obj-$(CONFIG_XEN_ACPI_PROCESSOR)   += xen-acpi-processor.o
 obj-$(CONFIG_XEN_EFI)  += efi.o
+obj-$(CONFIG_XEN_SCSI_BACKEND) += xen-scsiback.o
 xen-evtchn-y   := evtchn.o
 xen-gntdev-y   := gntdev.o
 xen-gntalloc-y := gntalloc.o
diff --git a/drivers/xen/xen-scsiback.c b/drivers/xen/xen-scsiback.c
new file mode 100644
index 000..7b565632
--- /dev/null
+++ b/drivers/xen/xen-scsiback.c
@@ -0,0 +1,2124 @@
+/*
+ * Xen SCSI backend driver
+ *
+ * Copyright (c) 2008, FUJITSU Limited
+ *
+ * Based on the blkback driver code.
+ * Adaption to kernel taget core infrastructure taken from vhost/scsi.c
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation; or, when distributed
+ * separately from the Linux kernel or incorporated into other
+ * software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the Software), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include stdarg.h
+
+#include linux/module.h
+#include linux/utsname.h
+#include linux/interrupt.h
+#include linux/slab.h
+#include linux/wait.h
+#include linux/sched.h
+#include linux/list.h
+#include linux/gfp.h
+#include linux/delay.h
+#include linux/spinlock.h
+#include linux/configfs.h
+
+#include generated/utsrelease.h
+
+#include scsi/scsi_dbg.h
+#include scsi/scsi_eh.h
+#include scsi/scsi_tcq.h
+
+#include target/target_core_base.h
+#include target/target_core_fabric.h
+#include target/target_core_configfs.h
+#include