headers
Martin K. Petersen | 1 Oct 2008 01:24
Picon
Favicon

Re: [PATCH 1/3] SCSI: rearrange code in scsi_io_completion

>>>>> "Alan" == Alan Stern <stern <at> rowland.harvard.edu> writes:

Alan> Are there types of failure for which we really don't want to
Alan> print anything?  For example, what about UNIT ATTENTION for
Alan> media changes or the DIX/DIF failures (should those both be
Alan> DIF?)?

ILLEGAL REQUEST + 10/[123] indicates that the HBA rejected the request
(DIX).

ABORTED COMMAND + 10/[123] indicates that the device found a
corruption error (DIF).

--

-- 
Martin K. Petersen	Oracle Linux Engineering

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Martin K. Petersen | 1 Oct 2008 07:37
Picon
Favicon

[PATCH] sd: Switch kernel printing level for DIF messages


For some reason these messages ended up being printed with KERN_INFO
rendering them invisible to pretty much everyone.  Switch to
KERN_NOTICE.

Signed-off-by: Martin K. Petersen <martin.petersen <at> oracle.com>

---

diff --git a/drivers/scsi/sd_dif.c b/drivers/scsi/sd_dif.c
--- a/drivers/scsi/sd_dif.c
+++ b/drivers/scsi/sd_dif.c
 <at>  <at>  -322,10 +322,10  <at>  <at>  void sd_dif_config_host(struct scsi_disk

 	if (type) {
 		if (dif)
-			sd_printk(KERN_INFO, sdkp,
+			sd_printk(KERN_NOTICE, sdkp,
 				  "Enabling DIF Type %d protection\n", type);
 		else
-			sd_printk(KERN_INFO, sdkp,
+			sd_printk(KERN_NOTICE, sdkp,
 				  "Disabling DIF Type %d protection\n", type);
 	}

 <at>  <at>  -344,7 +344,7  <at>  <at>  void sd_dif_config_host(struct scsi_disk
 		else
 			blk_integrity_register(disk, &dif_type1_integrity_crc);

-	sd_printk(KERN_INFO, sdkp,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin K. Petersen | 1 Oct 2008 07:38
Picon
Favicon

sd: Make revalidate less chatty


sd_revalidate ends up being called several times during device setup.
With this patch we print everything during the first scan.  Subsequent
invocations will only print a message if the parameter in question has
actually changed (LUN capacity has increased, etc.).

Signed-off-by: Martin K. Petersen <martin.petersen <at> oracle.com>

---

diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
 <at>  <at>  -1356,6 +1356,7  <at>  <at>  sd_read_capacity(struct scsi_disk *sdkp,
 	struct scsi_sense_hdr sshdr;
 	int sense_valid = 0;
 	struct scsi_device *sdp = sdkp->device;
+	sector_t old_capacity = sdkp->capacity;

 repeat:
 	retries = 3;
 <at>  <at>  -1512,10 +1513,12  <at>  <at>  got_data:
 		mb -= sz - 974;
 		sector_div(mb, 1950);

-		sd_printk(KERN_NOTICE, sdkp,
-			  "%llu %d-byte hardware sectors (%llu MB)\n",
-			  (unsigned long long)sdkp->capacity,
-			  hard_sector, (unsigned long long)mb);
+		/* Only print first time and if capacity changes */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Finn Thain | 1 Oct 2008 09:19
Picon
Favicon

Re: mac scsi, ncr5380


On Sun, 28 Sep 2008, Boaz Harrosh wrote:

> From what I understand, (And again I do not), the ESP sounds a lot like 
> the NCR5380. I would craft a very similar copy of the new ESP stack, 
> with it's central library and function-vector registration, The 
> scsi-generic part is all there, in full glory. Then one concentrated 
> effort should go into the basic/general chip programing, which lots of 
> it could be ripped from current code, and the different platform 
> implementation becomes one liners, if the new ESP stack is any 
> indication.

I still do not understand the whole ESP driver but when I wrote mac_esp.c 
I learned the value of the layered structure it provided.

I still have a lot to learn about the SCSI layers and the APIs too. I'm 
reading Documentation/scsi at the moment. If you know of any other 
introductory reading material, that would be a help.

> From my passed experience, there becomes a source code state when a 
> rewrite is less effort then any cleanup or enhancements. From the small 
> changes I had to do to the xxx_NCR5380 family of drivers, my guts 
> feeling scream "rewrite", so here I voice them. In the mid/long-term you 
> will work much less. And be much more satisfied from the results.

This makes sense. Thanks for your feedback.

Finn

>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Geert Uytterhoeven | 1 Oct 2008 09:51

http://bugzilla.kernel.org/show_bug.cgi?id=10974)

On Tue, 30 Sep 2008, Monty Montgomery wrote:
> > It happens on anything after 2.6.24 (cfr.
> > http://bugzilla.kernel.org/show_bug.cgi?id=10974).
> > E.g. mainline 2.6.27-rc8.
> 
> Ah.
> 
> Geert, I'm sorry this has come up and thanks for bringing it to my attention.

The bugzilla link has been in the subjects of the emails all the time ;-)

> > In this case, sg means scatter/gather, and it's a purely internal
> > interface.  It does not start/stop the drive, nor the scsi interface.
> 
> Ah, I confused it with a much older utility that would up/down an SG
> device entirely.

It is the command line utility.
James suggested to use it to load the CD.

Before that, my test sequence was less deterministic and not fully automated
(insert CD, wait until the blue LED is lit, launch cdparanoia).

With kind regards,

Geert Uytterhoeven
Software Architect

Sony Techsoft Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
(Continue reading)

Permalink | Reply | 0 comments |
headers
Finn Thain | 1 Oct 2008 10:04
Picon
Favicon

Re: mac scsi, ncr5380


On Tue, 30 Sep 2008, Christoph Hellwig wrote:

> On Sun, Sep 28, 2008 at 04:16:08PM +0300, Boaz Harrosh wrote:
> > From a SCSI generic point of view. The current xxx_NCR5380 remind me 
> > allot of the old ESP drivers stack. At-least at the surface level of 
> > the patches I sent for both these drivers. I was lucky, at the end, to 
> > only send the xxx_NCR5380 patches, because, as strongly recommended by 
> > Christoph Hellwig (CCed), the old ESP stack was brilliantly replaced 
> > by a new one. That is 1/10 the size of the old one, and currently 
> > supports most of the interesting devices out there. My unsent patches 
> > was a catalyst, for the now broken old-driver-stack, to be removed 
> > quickly. And it seems every one is happy.
> > 
> > My point being, If you are looking to do a major cleanup work, on all 
> > these 1/2 forks. Maybe give a hard thought on just trashing the all 
> > thing and crafting a completely new stack, 1/10 the size and much 
> > simpler, modern, and maintainable.
> 
> That would we very nice.  All 5380 drivers are in a really sorry state, 
> and a new one even if only working for sun3 and atari for now would be a 
> great change.  I'm not even sure if we have any users left for the PC 
> and arm 5380 drivers.

Me neither. And I'd prefer not to worry about the PC and arm drivers. I've 
bitten off more than enough already.

If I follow the ESP model, we'd get something like this:

-atari_NCR5380.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christof Schmitt | 1 Oct 2008 12:42
Picon
Favicon

[patch 01/13] zfcp: add queue_full sysfs attribute

From: Stefan Raspl <raspl <at> linux.vnet.ibm.com>

Adds a new sysfs attribute queue_full for adapters that records the number
of incidents where a requests could not be submitted due to insufficient
free space on the request queue.

Signed-off-by: Stefan Raspl <raspl <at> linux.vnet.ibm.com>
Signed-off-by: Martin Peschke <mp3 <at> de.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt <at> de.ibm.com>
---
 drivers/s390/scsi/zfcp_def.h   |    1 +
 drivers/s390/scsi/zfcp_fsf.c   |   24 +++++++++++++++++-------
 drivers/s390/scsi/zfcp_qdio.c  |    1 +
 drivers/s390/scsi/zfcp_sysfs.c |   13 +++++++++++++
 4 files changed, 32 insertions(+), 7 deletions(-)

--- a/drivers/s390/scsi/zfcp_def.h	2008-09-12 13:16:25.000000000 +0200
+++ b/drivers/s390/scsi/zfcp_def.h	2008-09-12 13:16:59.000000000 +0200
 <at>  <at>  -568,6 +568,7  <at>  <at>  struct zfcp_adapter {
 	struct fsf_qtcb_bottom_port *stats_reset_data;
 	unsigned long		stats_reset;
 	struct work_struct	scan_work;
+	atomic_t		qdio_outb_full;	   /* queue full incidents */
 };

 struct zfcp_port {
--- a/drivers/s390/scsi/zfcp_qdio.c	2008-09-12 13:16:25.000000000 +0200
+++ b/drivers/s390/scsi/zfcp_qdio.c	2008-09-12 13:16:59.000000000 +0200
 <at>  <at>  -282,6 +282,7  <at>  <at>  static int zfcp_qdio_fill_sbals(struct z
 	     addr += length, remaining -= length) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christof Schmitt | 1 Oct 2008 12:42
Picon
Favicon

[patch 02/13] zfcp: Update message with input from review

From: Christof Schmitt <christof.schmitt <at> de.ibm.com>

Update the kernel messages in zfcp with input from the message review
and remove some messages that have been identified as redundant.

Signed-off-by: Christof Schmitt <christof.schmitt <at> de.ibm.com>
Signed-off-by: Swen Schillig <swen <at> vnet.ibm.com>
--- a/drivers/s390/scsi/zfcp_aux.c	2008-09-19 08:40:51.000000000 +0200
+++ b/drivers/s390/scsi/zfcp_aux.c	2008-09-19 09:51:59.000000000 +0200
 <at>  <at>  -100,8 +100,7  <at>  <at>  static int __init zfcp_device_setup(char

  err_out:
 	kfree(str);
-	pr_err("zfcp: Parse error for device parameter string %s, "
-	       "device not attached.\n", devstr);
+	pr_err("zfcp: %s is not a valid SCSI device\n", devstr);
 	return 0;
 }

 <at>  <at>  -193,13 +192,14  <at>  <at>  static int __init zfcp_module_init(void)

 	retval = misc_register(&zfcp_cfdc_misc);
 	if (retval) {
-		pr_err("zfcp: registration of misc device zfcp_cfdc failed\n");
+		pr_err("zfcp: Registering the misc device zfcp_cfdc failed\n");
 		goto out_misc;
 	}

 	retval = zfcp_ccw_register();
 	if (retval) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christof Schmitt | 1 Oct 2008 12:42
Picon
Favicon

[patch 03/13] zfcp: remove unused references, declarations and flags

From: Swen Schillig <swen <at> vnet.ibm.com>

 - Remove unused references and declarations, including one instance
   of the FC ls_adisc struct that has been defined twice.
 - Also remove the flags COMMON_OPENING, COMMON_CLOSING,
   ADAPTER_REGISTERED and XPORT_OK that are only set and cleared, but
   not checked anywhere.
 - Remove the zfcp specific atomic_test_mask makro. Simply use
   atomic_read directly instead.
 - Remove the zfcp internal sg helper functions and switch the places
   where it is still used to call sg_virt directly.
 - With the update of the QDIO code, the QDIO data structures no
   longer use the volatile type qualifier. Now we can also remove the
   volatile qualifiers from the zfcp code.

Signed-off-by: Swen Schillig <swen <at> vnet.ibm.com>
Signed-off-by: Christof Schmitt <christof.schmitt <at> de.ibm.com>
--- a/drivers/s390/scsi/zfcp_ccw.c	2008-09-30 13:11:23.000000000 +0200
+++ b/drivers/s390/scsi/zfcp_ccw.c	2008-09-30 13:11:23.000000000 +0200
 <at>  <at>  -67,14 +67,14  <at>  <at>  static void zfcp_ccw_remove(struct ccw_d

 	list_for_each_entry_safe(port, p, &adapter->port_remove_lh, list) {
 		list_for_each_entry_safe(unit, u, &port->unit_remove_lh, list) {
-			if (atomic_test_mask(ZFCP_STATUS_UNIT_REGISTERED,
-				&unit->status))
+			if (atomic_read(&unit->status) &
+			    ZFCP_STATUS_UNIT_REGISTERED)
 				scsi_remove_device(unit->device);
 			zfcp_unit_dequeue(unit);
 		}
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christof Schmitt | 1 Oct 2008 12:42
Picon
Favicon

[patch 07/13] zfcp: Simplify zfcp data structures

From: Christof Schmitt <christof.schmitt <at> de.ibm.com>

Reduce the size of zfcp data structures by removing unused and
redundant members. scsi_lun is only the mangled version of the
fcp_lun. So, remove the redundant field and use the fcp_lun instead.

Since the queue lock and the pci_batch indicator are only used in the
request queue, move them from the common queue struct to the adapter
struct.

Signed-off-by: Christof Schmitt <christof.schmitt <at> de.ibm.com>
Signed-off-by: Swen Schillig <swen <at> vnet.ibm.com>
---
 drivers/s390/scsi/zfcp_aux.c   |   34 ---------------
 drivers/s390/scsi/zfcp_ccw.c   |   10 ++--
 drivers/s390/scsi/zfcp_def.h   |   26 ++---------
 drivers/s390/scsi/zfcp_erp.c   |    2 
 drivers/s390/scsi/zfcp_fc.c    |    3 -
 drivers/s390/scsi/zfcp_fsf.c   |   89 ++++++++++++++++++++---------------------
 drivers/s390/scsi/zfcp_qdio.c  |   12 ++---
 drivers/s390/scsi/zfcp_scsi.c  |    8 ++-
 drivers/s390/scsi/zfcp_sysfs.c |    6 +-
 9 files changed, 77 insertions(+), 113 deletions(-)

--- a/drivers/s390/scsi/zfcp_aux.c	2008-10-01 11:08:47.000000000 +0200
+++ b/drivers/s390/scsi/zfcp_aux.c	2008-10-01 11:09:06.000000000 +0200
 <at>  <at>  -169,8 +169,6  <at>  <at>  static int __init zfcp_module_init(void)
 		goto out_gid_cache;

 	INIT_LIST_HEAD(&zfcp_data.adapter_list_head);
(Continue reading)

Permalink | Reply | 0 comments |

Gmane