Re: [PATCH] [scsi] Remove __GFP_DMA

[Aubrey Li]

On 5/23/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:

On Mon, 21 May 2007, Bernhard Walle wrote:

> [PATCH] [scsi] Remove __GFP_DMA
>
> After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate 
a
> DMA buffer any more in sd.c.
>
> Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>

Great that avoids a DMA kmalloc slab. Any other GFP_DMAs left in the scsi
layer?

Acked-by: Christoph Lameter <[EMAIL PROTECTED]>


Yes, here is another patch

Signed-off-by: Aubrey.Li <[EMAIL PROTECTED]>
---
drivers/scsi/aacraid/commctrl.c |   12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/aacraid/commctrl.c b/drivers/scsi/aacraid/commctrl.c
index 72b0393..405722d 100644
--- a/drivers/scsi/aacraid/commctrl.c
+++ b/drivers/scsi/aacraid/commctrl.c
@@ -580,8 +580,8 @@ static int aac_send_raw_srb(struct aac_dev* dev,
void __user * arg)
for (i = 0; i < upsg->count; i++) {
u64 addr;
void* p;
-   /* Does this really need to be GFP_DMA? */
-   p = 
kmalloc(upsg->sg[i].count,GFP_KERNEL|__GFP_DMA);
+
+   p = kmalloc(upsg->sg[i].count,GFP_KERNEL);
if(p == 0) {
dprintk((KERN_DEBUG"aacraid: Could not 
allocate SG buffer - size
= %d buffer number %d of %d\n",
  upsg->sg[i].count,i,upsg->count));
@@ -624,8 +624,8 @@ static int aac_send_raw_srb(struct aac_dev* dev,
void __user * arg)
for (i = 0; i < usg->count; i++) {
u64 addr;
void* p;
-   /* Does this really need to be GFP_DMA? */
-   p = 
kmalloc(usg->sg[i].count,GFP_KERNEL|__GFP_DMA);
+
+   p = kmalloc(usg->sg[i].count,GFP_KERNEL);
if(p == 0) {
kfree (usg);
dprintk((KERN_DEBUG"aacraid: Could not 
allocate SG buffer - size
= %d buffer number %d of %d\n",
@@ -666,8 +666,8 @@ static int aac_send_raw_srb(struct aac_dev* dev,
void __user * arg)
for (i = 0; i < upsg->count; i++) {
u64 addr;
void* p;
-   /* Does this really need to be GFP_DMA? */
-   p = 
kmalloc(usg->sg[i].count,GFP_KERNEL|__GFP_DMA);
+
+   p = kmalloc(usg->sg[i].count,GFP_KERNEL);
if(p == 0) {
dprintk((KERN_DEBUG"aacraid: Could not 
allocate SG buffer - size
= %d buffer number %d of %d\n",
  usg->sg[i].count,i,usg->count));
--
1.5.1.1
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/19] clean ups on the drivers

[FUJITA Tomonori]

From: FUJITA Tomonori <[EMAIL PROTECTED]>
Subject: Re: [PATCH 0/19] clean ups on the drivers
Date: Mon, 14 May 2007 23:40:03 +0900

> From: Christoph Hellwig <[EMAIL PROTECTED]>
> Subject: Re: [PATCH 0/19] clean ups on the drivers
> Date: Sat, 12 May 2007 16:30:23 +0100
> 
> > On Sat, May 12, 2007 at 07:05:42PM +0900, FUJITA Tomonori wrote:
> > > There are two patches for each driver, removing the non-use-sg code
> > > and converting to use the accessors.
> > 
> > One patch would probably be fine aswell.
> 
> I merged the two. And I finished cleaning up 35 drivers in total.
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-bidi.git cleanups

I rebased the cleanup patchset against the latest scsi-misc
(352e921f0dd42f79652cdb50dd91122d068d7209). It includes the cleanups
for more than 40 drivers.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] [scsi] Remove __GFP_DMA

[Christoph Lameter]

On Mon, 21 May 2007, Bernhard Walle wrote:

> [PATCH] [scsi] Remove __GFP_DMA
> 
> After 821de3a27bf33f11ec878562577c586cd5f83c64, it's not necessary to alloate 
> a
> DMA buffer any more in sd.c.
> 
> Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>

Great that avoids a DMA kmalloc slab. Any other GFP_DMAs left in the scsi 
layer?

Acked-by: Christoph Lameter <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVD drive connected to mptspi driver

[James Bottomley]

On Tue, 2007-05-22 at 14:25 -0600, Doug Chapman wrote:
> Eric,
> 
> Sorry to bother you on this again, I realize you are very busy.
> 
> >From our off-list email and from your comments to Chip Coldwell in
> redhat BZ 225177 it sounded like you were prepared to ACK this.  Any
> chance you could send your official ACK so this can be committed?
> 
> much appreciated,

Actually I'd like a little analysis of why first, please Eric.

It seems to me, with the current wrong ordering in the initialisation
results in a large queue depth being given to the DVD (which are
habitually very low queue depth ... or even untagged beasts).  So does
the slowdown result from the fusion accepting N commands for the DVD and
then rejecting N-1 of them resulting in ping pong between the mid-layer
and driver?

If so, we probably want to fix the command throttling in the driver.

James


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

Re: [patch 5/7] genhd: send async notification on media change

[Andrew Morton]

On Wed, 9 May 2007 16:38:35 -0700
Kristen Carlson Accardi <[EMAIL PROTECTED]> wrote:

> Send an uevent to user space to indicate that a media change event has 
> occurred.
> 
> Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
> 
> Index: 2.6-git/block/genhd.c
> ===
> --- 2.6-git.orig/block/genhd.c
> +++ 2.6-git/block/genhd.c
> @@ -643,6 +643,27 @@ struct seq_operations diskstats_op = {
>   .show   = diskstats_show
>  };
>  
> +static void media_change_notify_thread(struct work_struct *work)
> +{
> + struct gendisk *gd = container_of(work, struct gendisk, async_notify);
> + char event[] = "MEDIA_CHANGE=1";
> + char *envp[] = { event, NULL };
> +
> + /*
> +  * set enviroment vars to indicate which event this is for
> +  * so that user space will know to go check the media status.
> +  */
> + kobject_uevent_env(&gd->kobj, KOBJ_CHANGE, envp);
> + put_device(gd->driverfs_dev);
> +}
> +
> +void genhd_media_change_notify(struct gendisk *disk)
> +{
> + get_device(disk->driverfs_dev);
> + schedule_work(&disk->async_notify);
> +}
> +EXPORT_SYMBOL_GPL(genhd_media_change_notify);
> +
>  struct gendisk *alloc_disk(int minors)
>  {
>   return alloc_disk_node(minors, -1);
> @@ -672,6 +693,8 @@ struct gendisk *alloc_disk_node(int mino
>   kobj_set_kset_s(disk,block_subsys);
>   kobject_init(&disk->kobj);
>   rand_initialize_disk(disk);
> + INIT_WORK(&disk->async_notify,
> + media_change_notify_thread);
>   }
>   return disk;

Why does this do a schedule_work() rather than calling kobject_uevent_env()
directly?
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bug fix: SCSI async scan sysfs -EEXIST problem

[James Smart]

James Bottomley wrote:

On Mon, 2007-05-07 at 14:57 -0400, James Smart wrote:

+   mutex_lock(&shost->scan_mutex);
scsi_sysfs_add_devices(shost);
+   atomic_set(&shost->async_scan, 0);
+   mutex_unlock(&shost->scan_mutex);


It really seems that the only safety here is expanding the scan mutex to
cover more of the code.  I don't really see any value to using the
atomic types ... it's not a simultaneous variable update problem, it's a
scan race which the mutex can be used to mediate.

James


True. First requirement is that scsi_sysfs_add_devices() must be under
the scan_mutex.  Additionally, (ignoring the atomic) shost->async_scan,
based on its use in scsi_add_lun(), should be changed under the mutex
as well, thus the "proper" placement in the snippet above is while
under the scan mutex.

The real headache was the other code paths that read the value of
async_scan and determine whether to enumerate or ignore the sdev.
Reorganizing that code to place it under scan_mutex was very ugly.
Converting to an atomic simply addressed the synchronicity on sampling,
although it essentially makes it independent of the scan_mutex.

Are you suggesting you would rather rework all the other code paths for
scan_mutex encapsulating async_scan ?

-- james




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

Re: Sg_ses question

[Douglas Gilbert]

Haefliger, Juerg wrote:
> Hi,
> 
> Not sure if this is the right list for my question but I couldn't find a
> more suitable place to ask it.
> 
> I'm trying to set the locator light of a disk in a SAS enclosure using
> sg_ses but I'm not getting anywhere. I'm dumping the enclosure status
> diagnostic page using 'sg_ses --page=2 --raw /dev/sgXX > page' and then
> set the SELECT and RQST IDENT bits of the array device element in
> question and write it back doing 'sg_ses --control --page=2 --data=-
> /dev/sgXX < tmp'. The command completes without error but unfortunately,
> nothing happens. When I read the page back, the IDENT bit is still
> cleared and the light on the enclosure remains turned off.
> 
> Am I doing something wrong or am I missing something? Can't I use sg_ses
> to achieve this?

The procedure looks correct. I haven't had any (other)
reports of sg_ses not working lately. The only suggestion
I can make is to ask if you have selected the element
control rather than the overall control.

Doug Gilbert




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

Re: [PATCH] fix for BZ 8426 - massive slowdown on SCSI CD/DVD drive connected to mptspi driver

[Doug Chapman]

Eric,

Sorry to bother you on this again, I realize you are very busy.

>From our off-list email and from your comments to Chip Coldwell in
redhat BZ 225177 it sounded like you were prepared to ACK this.  Any
chance you could send your official ACK so this can be committed?

much appreciated,

- Doug


On Mon, 2007-05-07 at 15:59 -0400, Doug Chapman wrote:
> Patch for: http://bugzilla.kernel.org/show_bug.cgi?id=8426
> 
> A recent code cleanup that moved code from mptscsih to mptspi
> inadvertently change the order some code was called.  This caused
> a massive slowdown (of 150x to 300x) on the CD/DVD drive on the
> high-end HP Integrity servers.
> 
> Signed-off-by: Doug Chapman <[EMAIL PROTECTED]>
> 
> 
> 
> 
> diff --git a/drivers/message/fusion/mptspi.c b/drivers/message/fusion/mptspi.c
> index 85f21b5..2eb5741 100644
> --- a/drivers/message/fusion/mptspi.c
> +++ b/drivers/message/fusion/mptspi.c
> @@ -726,13 +726,15 @@ static int mptspi_slave_configure(struct scsi_device 
> *sdev)
>   struct _MPT_SCSI_HOST *hd =
>   (struct _MPT_SCSI_HOST *)sdev->host->hostdata;
>   VirtTarget *vtarget = scsi_target(sdev)->hostdata;
> - int ret = mptscsih_slave_configure(sdev);
> + int ret;
> +
> + mptspi_initTarget(hd, vtarget, sdev);
> +
> + ret = mptscsih_slave_configure(sdev);
>  
>   if (ret)
>   return ret;
>  
> - mptspi_initTarget(hd, vtarget, sdev);
> -
>   ddvprintk((MYIOC_s_INFO_FMT "id=%d min_period=0x%02x"
>   " max_offset=0x%02x max_width=%d\n", hd->ioc->name,
>   sdev->id, spi_min_period(scsi_target(sdev)),
> 
> 

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

Re: [Stgt-devel] Question for pass-through target design

[Robert Jennings]

Missed a fair bit of this thread when it was first sent, bad mail
filter I think (or pebkac).

* FUJITA Tomonori ([EMAIL PROTECTED]) wrote:
> From: Vladislav Bolkhovitin <[EMAIL PROTECTED]>
> Subject: Re: [Stgt-devel] Question for pass-through target design
> Date: Mon, 07 May 2007 18:24:44 +0400
> 
> > FUJITA Tomonori wrote:
> > It looks like the pass-through target support is currently broken, at
> > least as I've checked for ibmvstgt, but I think it's a general problem.
> > I wanted to check my assumptions and get ideas.
> > >>>
> > >>>Yeah, unfortunately, it works only with the iSCSI target driver (which
> > >>>runs in user space).
> > >>>
> > >>>
> > >>>
> > The code isn't allocating any memory to pass along to the sg code to 
> > store
> > the result of a read or data for a write.  Currently, dxferp for 
> > sg_io_hdr
> > or dout_xferp/din_xferp for sg_io_v4 are assigned to the value of uaddr,
> > which is set to 0 in kern_queue_cmd.  With the pointer set to NULL,
> > the pass-through target isn't going to function.  Even if we had memory
> > allocated, there isn't a means of getting data to be written via sg down
> > this code path.
> > 
> > What ideas are there as to how the data will get to user-space so that
> > we can use sg?
> > >>>
> > >>>For kernel-space drivers, we don't need to go to user-space. We can do
> > >>>the pass-through in kernel space. I talked with James about this last
> > >>>year and he said that if the code is implemented cleanly, he would
> > >>>merges it into mainline.
> > >>
> > >>We already have a pass-through in the kernel space for
> > >>kernel space drivers. It is the scsi_tgt* code.
> > > 
> > > 
> > > Could you elaborate more?
> > > 
> > > What I meant that is that the kernel tgt code (scsi_tgt*) receives
> > > SCSI commands from one lld and send them to another lld instead of
> > > sending them to user space.
> > 
> > Although the approach of passing SCSI commands from a target LLD to an
> > initiator one without any significant interventions from the target
> > software looks to be nice and simple, you should realize how limited,
> > unsafe and illegal it is, since it badly violates SCSI specs.
> 
> I think that 'implemented cleanly' means that one scsi_host is assigned
> to only one initiator.

Vladislav listed a number of issues that are inherent in an implementation
that does not have a 1:1 relationship of initiators to targets.  The vscsi
architecture defines the 1:1 relationship; it's imposible to have more
than one initiator per target.  Are there any barriers that we will need
to address if this were the case?

Regards,
Rob Jennings
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [patch 10/28] Fix |/|| confusion in fusion driver

[Moore, Eric]

On Monday, May 21, 2007 7:00 PM,  Dave Jones wrote:
> 
> Andrew, the last time this was posted, Eric picked up on some other
> flaws in the same area. James asked him to followup with a patch, but
> unless I'm mistaken, that never arrived.
> This diff should replace the one in your tree until Eric has an
> equivalent or better.
> 
> Signed-off-by: Dave Jones <[EMAIL PROTECTED]>
> 

ACK

Thanks Dave, this patch will work.  
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] scsi_error: send the sense buffer down without copying

[James Bottomley]

Now that the block submission path correctly bounces, we can simply
use the command sense_buffer to send to retrieve sense information and
junk the unnecessary page allocation.

James

Index: scsi-misc-2.6/drivers/scsi/scsi_error.c
===
--- scsi-misc-2.6.orig/drivers/scsi/scsi_error.c2007-05-15 
11:08:31.0 -0500
+++ scsi-misc-2.6/drivers/scsi/scsi_error.c 2007-05-22 14:38:49.0 
-0500
@@ -18,12 +18,12 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -640,16 +640,8 @@ static int scsi_send_eh_cmnd(struct scsi
memcpy(scmd->cmnd, cmnd, cmnd_size);
 
if (copy_sense) {
-   gfp_t gfp_mask = GFP_ATOMIC;
-
-   if (shost->hostt->unchecked_isa_dma)
-   gfp_mask |= __GFP_DMA;
-
-   sgl.page = alloc_page(gfp_mask);
-   if (!sgl.page)
-   return FAILED;
-   sgl.offset = 0;
-   sgl.length = 252;
+   sg_init_one(&sgl, scmd->sense_buffer,
+   sizeof(scmd->sense_buffer));
 
scmd->sc_data_direction = DMA_FROM_DEVICE;
scmd->request_bufflen = sgl.length;
@@ -720,18 +712,6 @@ static int scsi_send_eh_cmnd(struct scsi
 
 
/*
-* Last chance to have valid sense data.
-*/
-   if (copy_sense) {
-   if (!SCSI_SENSE_VALID(scmd)) {
-   memcpy(scmd->sense_buffer, page_address(sgl.page),
-  sizeof(scmd->sense_buffer));
-   }
-   __free_page(sgl.page);
-   }
-
-
-   /*
 * Restore original data
 */
scmd->request_buffer = old_buffer;


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

Re: [patch 18/28] scsi/lpfc/lpfc_init.c: remove unused variable

[Andrew Morton]

On Tue, 22 May 2007 14:04:02 -0500
James Bottomley <[EMAIL PROTECTED]> wrote:

> On Thu, 2007-05-10 at 23:01 -0700, [EMAIL PROTECTED] wrote:
> > From: Adrian Bunk <[EMAIL PROTECTED]>
> > 
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
> 
> Actually, not against vanilla linus:
> 
> drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_pci_probe_one':
> drivers/scsi/lpfc/lpfc_init.c:1581: error: 'retval' undeclared (first use in 
> this function)
> drivers/scsi/lpfc/lpfc_init.c:1581: error: (Each undeclared identifier is 
> reported only once
> drivers/scsi/lpfc/lpfc_init.c:1581: error: for each function it appears in.)
> 
> There's probably some global change in -mm that makes pci_set_mwi()
> return void ... in which case, this needs to be swept up into it.
> 

yep, sorry.  I rebadged this patch as being
"after Greg merges add-pci_try_set_mwi.patch"
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 18/28] scsi/lpfc/lpfc_init.c: remove unused variable

[James Bottomley]

On Thu, 2007-05-10 at 23:01 -0700, [EMAIL PROTECTED] wrote:
> From: Adrian Bunk <[EMAIL PROTECTED]>
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>

Actually, not against vanilla linus:

drivers/scsi/lpfc/lpfc_init.c: In function 'lpfc_pci_probe_one':
drivers/scsi/lpfc/lpfc_init.c:1581: error: 'retval' undeclared (first use in 
this function)
drivers/scsi/lpfc/lpfc_init.c:1581: error: (Each undeclared identifier is 
reported only once
drivers/scsi/lpfc/lpfc_init.c:1581: error: for each function it appears in.)

There's probably some global change in -mm that makes pci_set_mwi()
return void ... in which case, this needs to be swept up into it.

James


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

Re: [PATCH] bug fix: SCSI async scan sysfs -EEXIST problem

[James Bottomley]

On Mon, 2007-05-07 at 14:57 -0400, James Smart wrote:
> +   mutex_lock(&shost->scan_mutex);
> scsi_sysfs_add_devices(shost);
> +   atomic_set(&shost->async_scan, 0);
> +   mutex_unlock(&shost->scan_mutex);

It really seems that the only safety here is expanding the scan mutex to
cover more of the code.  I don't really see any value to using the
atomic types ... it's not a simultaneous variable update problem, it's a
scan race which the mutex can be used to mediate.

James


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

Re: [PATCH] fc_transport: fix sysfs deadlock on vport delete

[James Bottomley]

On Fri, 2007-04-27 at 12:52 -0400, James Smart wrote:
> When the vport attribute "delete" is used to delete the vport, sysfs
> deadlocks waiting for the write to complete, which is waiting for the
> sysfs teardown to complete. Moved this effort to a work_q element.
> 
> Took the opportunity to make some other cosmetic changes:
>  - removed tabs in Doc file - replaced with expanded spaces
>  - minor copyright text and author text updates
>  - removed a bunch of trailing whitespace

This one rejects against scsi-misc, could you reroll

(I suspect because the prior vport patch had spacing errors which git
makes me fix before I commit).

James


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

Re: [PATCH] aic7xxx/aicasm build failure w/gcc-3.4.6

[Bob Tracy]

James Bottomley wrote:
> We really don't want gcc making assumptions about prototypes ... even if
> it's getting them right in all likelihood (doubtless unprototyped
> assumed functions will become a warning and then an error in later gcc
> versions ...), so this is a better fix

ACK.  The fix works here.  If you would be so kind, please push it
upstream at your convenience.

gcc-4.X violates the principle of least astonishment over even more
nitnoid matters, but that's another flame for another day.

-- 
---
Bob Tracy   | "Eagles may soar, but weasels don't get
[EMAIL PROTECTED]|  sucked into jet engines."   --Anon
---
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Dell CERC ATA100/4ch support

[Hannes Reinecke]

James Bottomley wrote:
> On Wed, 2007-05-16 at 14:36 +0100, Leigh Blackwell wrote:
>> I have been looking at the issue with theses cerc devices, has this 
>> bug 374792 been closed based on people reverting the firmware to < 6.61. 
>>
>> Unfortunately Dell doesn't support a Firmware version that old on our 
>> Server, is it possible to re-open this bug? I have been unable to get the
>> current etch install to recognize my driver controller with any of the
>> megaraid drivers.
> 
> Umm, but this is a bug in Dell Support isn't it?  I don't think there's
> a kernel fix for that.
> 
> LSIs position is that in current kernels they only support this device
> with the new megaraid driver and only for firmware version >= 6.61.
> Surely you just need to get Dell and LSI on the same page?
> 
Provided they have an interest in doing so.
Dell for one is _not_ interested in supplying an updated firmware.

So we're stuck.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
[EMAIL PROTECTED] +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] aic7xxx/aicasm build failure w/gcc-3.4.6

[James Bottomley]

On Tue, 2007-05-22 at 06:51 -0500, Bob Tracy wrote:
> Second try: originally reported this back on April 17th.  2.6.X
> kernel builds started failing after I upgraded my compiler from
> gcc-3.3.X to gcc-3.4.6:
> 
> make -C drivers/scsi/aic7xxx/aicasm
> (...)
> gcc -I/usr/include -I. aicasm.c aicasm_symbol.c aicasm_gram.c 
> aicasm_macro_gram.c aicasm_scan.c aicasm_macro_scan.c -o aicasm -ldb
> aicasm_gram.y:1948: error: conflicting types for 'yyerror'
> aicasm_gram.tab.c:3004: error: previous implicit declaration of 'yyerror' was 
> here
> aicasm_macro_gram.y:162: error: conflicting types for 'mmerror'
> aicasm_macro_gram.tab.c:1196: error: previous implicit declaration of 
> 'mmerror' was here
> 
> As a workaround, commenting out or deleting the "void" declarations
> for yyerror() and mmerror() in the respective ".y" files fixes the
> problem.

We really don't want gcc making assumptions about prototypes ... even if
it's getting them right in all likelihood (doubtless unprototyped
assumed functions will become a warning and then an error in later gcc
versions ...), so this is a better fix

James

diff --git a/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y 
b/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y
index c328596..6066998 100644
--- a/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y
+++ b/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y
@@ -106,6 +106,7 @@ static void make_expression(expression_t *immed, int value);
 static void add_conditional(symbol_t *symbol);
 static void add_version(const char *verstring);
 static int  is_download_const(expression_t *immed);
+void yyerror(const char *string);
 
 #define SRAM_SYMNAME "SRAM_BASE"
 #define SCB_SYMNAME "SCB_BASE"
diff --git a/drivers/scsi/aic7xxx/aicasm/aicasm_macro_gram.y 
b/drivers/scsi/aic7xxx/aicasm/aicasm_macro_gram.y
index 439f760..ff46aa6 100644
--- a/drivers/scsi/aic7xxx/aicasm/aicasm_macro_gram.y
+++ b/drivers/scsi/aic7xxx/aicasm/aicasm_macro_gram.y
@@ -65,6 +65,7 @@
 static symbol_t *macro_symbol;
 
 static void add_macro_arg(const char *argtext, int position);
+void mmerror(const char *string);
 
 %}
 


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

[PATCH] aacraid: apply commit config for reset_devices flag

[Salyzyn, Mark]

Under some conditions associated with the unclean transition to kdump,
the aacraid adapters will view the array as foreign and not export it to
prevent access and data manipulation. The solution is to submit a commit
configuration to export the devices since this is a expected behavior
when transitioning to a kdump kernel.

This patch adds the aacraid.reset_devices flag and when either this or
the global reset_devices flag is set, ensures that a commit config is
issued and extends the startup_timeout if it is set less than 5 minutes.

This attached patch is against current scsi-misc-2.6 and was unit tested
on RHEL5 and 2.6.22. This is a bugfix, so this patch needs to propagate
quickly.

ObligatoryDisclaimer: Please accept my condolences regarding Outlook's
handling of patch attachments.

Signed-off-by: Mark Salyzyn <[EMAIL PROTECTED]>

Sincerely -- Mark Salyzyn

-Original Message-
From: Salyzyn, Mark 
Sent: Wednesday, May 16, 2007 10:41 AM
To: '[EMAIL PROTECTED]'
Subject: RE: System does not boot if booted with "reset_devices"

Vivek, could you please try the enclosed patch.

This patch adds the aacraid.reset_devices flag and when either this or
the global reset_devices flag is set, ensures that a commit config is
issued and extends the startup_timeout if it is set less than 5 minutes.
IF you are satisfied with this, I will submit it to the scsi list.

Sincerely -- Mark Salyzyn

> -Original Message-
> From: Vivek Goyal [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, May 16, 2007 1:31 AM
> To: Salyzyn, Mark
> Subject: Re: System does not boot if booted with "reset_devices"
> 
> 
> On Tue, May 15, 2007 at 12:51:06PM -0400, Salyzyn, Mark wrote:
> > Been tossing it around here, and it appears I am the only 
> person that
> > considers this a risk to do a forced commit config in this 
> scenario. I
> > will send you a patch later that does this (basically 
> export commit from
> > aachba.c, and set it to a value of one if we had to reset 
> the adapter
> > during the initialization, but I will have to make sure I 
> resolve all
> > symbol name overlaps etc, so not a simple task; and few 
> minutes left in
> > my day to work on this).
> > 
> 
> Thanks Mark. I am waiting for your patch. :-)
> 
> Thanks
> Vivek
> 


aacraid_commit_reset.patch
Description: aacraid_commit_reset.patch

[PATCH] aic7xxx/aicasm build failure w/gcc-3.4.6

[Bob Tracy]

Second try: originally reported this back on April 17th.  2.6.X
kernel builds started failing after I upgraded my compiler from
gcc-3.3.X to gcc-3.4.6:

make -C drivers/scsi/aic7xxx/aicasm
(...)
gcc -I/usr/include -I. aicasm.c aicasm_symbol.c aicasm_gram.c 
aicasm_macro_gram.c aicasm_scan.c aicasm_macro_scan.c -o aicasm -ldb
aicasm_gram.y:1948: error: conflicting types for 'yyerror'
aicasm_gram.tab.c:3004: error: previous implicit declaration of 'yyerror' was 
here
aicasm_macro_gram.y:162: error: conflicting types for 'mmerror'
aicasm_macro_gram.tab.c:1196: error: previous implicit declaration of 'mmerror' 
was here

As a workaround, commenting out or deleting the "void" declarations
for yyerror() and mmerror() in the respective ".y" files fixes the
problem.  A patch to illustrate the offending code is attached, but
there's no "signed-off by" line because I'm certain the final form of
the patch will be different.  The patch applies cleanly to at least
2.6.21 and later kernels.  gcc-3.3 may have been warning about the
type conflicts, but I didn't notice: gcc-3.4 treats the type conflicts
as errors, so I *did* notice :-).

Here's the "gcc -v" output:

Reading specs from /usr/lib/gcc/i486-slackware-linux/3.4.6/specs
Configured with: ../gcc-3.4.6/configure --prefix=/usr --enable-shared 
--enable-threads=posix --enable-__cxa_atexit --disable-checking --with-gnu-ld 
--verbose --target=i486-slackware-linux --host=i486-slackware-linux
Thread model: posix
gcc version 3.4.6

-- 
---
Bob Tracy   WTO + WIPO = DMCA? http://www.anti-dmca.org
[EMAIL PROTECTED]
---
--- linux/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y.orig2006-02-06 
06:00:58.0 -0600
+++ linux/drivers/scsi/aic7xxx/aicasm/aicasm_gram.y 2007-04-16 
12:31:08.0 -0500
@@ -1943,7 +1943,7 @@
versions[newlen + oldlen + 1] = '\0';
 }
 
-void
+/* void */
 yyerror(const char *string)
 {
stop(string, EX_DATAERR);
--- linux/drivers/scsi/aic7xxx/aicasm/aicasm_macro_gram.y.orig  2002-12-24 
07:09:30.0 -0600
+++ linux/drivers/scsi/aic7xxx/aicasm/aicasm_macro_gram.y   2007-04-16 
12:32:48.0 -0500
@@ -157,7 +157,7 @@
}
 }
 
-void
+/* void */
 mmerror(const char *string)
 {
stop(string, EX_DATAERR);

Re: [PATCH] FC Transport support for vports based on NPIV

[Christof Schmitt]

On Mon, May 21, 2007 at 11:45:13AM -0400, James Smart wrote:

> True - so this means that who-ever is setting the subchannel device
> permanent_port_name value needs to take into account this conversation,
> when T11.3 actually makes a choice on what it should be.

I will keep this in mind. Probably this would involve the FCP adapter
and the reporting in zfcp.

Anyway, my main goal was to understand the changes in the FC transport
class and the possible impact to zfcp. Thanks for the clarification
of my questions.

Christof
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4,

[Mikael Pettersson]

[added cc:linux-ide]

Hans A Eide writes:
 > 
 >  > Evan Harris wrote:
 >  >>
 >  >> I have a card that mirrors this one from your list:
 >  >>
 >  >> Retail name: SATA300 TX4
 >  >> Chip label: PDC40718-GP  SATAII300
 >  >> Vendor-Device number: 105a:3d17 (rev 02)
 >  >>
 >  >> Through testing, I've found linux 2.6.16 and 2.6.17 find the  
 > ports in
 >  >> this order (the list is ordered by linux detection):
 >  >>
 >  >> 1. silkscreen port 3
 >  >> 2. silkscreen port 2
 >  >> 3. silkscreen port 4
 >  >> 4. silkscreen port 1
 >  >>> NOTE: the patch I have submitted (
 >  >>> http://marc.theaimsgroup.com/?l=linux- 
 > ide&m=114082978311290&w=2 ) is a
 >  >>> solution that doesn't know about the older Promise SATA  
 > controllers,
 >  >>> which are not affected with the "new wiring" problem, so the older
 >  >>> controllers will appear screwed if you use it.
 >  >>>
 >  >>> Hopefully we will collect enough info about all the SATA Promise
 >  >>> controllers to distinguish the new and the old wiring controllers,
 >  >>> then produce a new patch that will be a correct solution to the  
 > "new
 >  >>> wiring" problem.
 >  >
 >  > Mikael Pettersson has been doing some excellent work recently on
 >  > sata_promise.  If enough data has been collected on this sata_promise
 >  > port enumeration problem, maybe the data could be collated and  
 > proposed
 >  > via Mikael as a patch?
 >  >
 >  >   Jeff
 > 
 > Sorry, any updates on this?

You should have posted this to linux-ide not linux-scsi.

The Promise SATAII TX4 port enumeration issue is fixed in
current 2.6.22-rc kernels. A patch for 2.6.21 can be found
in .

/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[UPDATED PATCH] jazz_esp converted to use esp_core

[Thomas Bogendoerfer]

Here is an updated patch for converting jazz_esp to use esp_scsi.

Thomas.

Use new esp_scsi for JAZZ SCSI host adapter driver

Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]>
---

diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index 51e884f..fc05d90 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -121,7 +121,7 @@ obj-$(CONFIG_BLK_DEV_3W__RAID) += 3w-.o
 obj-$(CONFIG_SCSI_3W_9XXX) += 3w-9xxx.o
 obj-$(CONFIG_SCSI_PPA) += ppa.o
 obj-$(CONFIG_SCSI_IMM) += imm.o
-obj-$(CONFIG_JAZZ_ESP) += NCR53C9x.o   jazz_esp.o
+obj-$(CONFIG_JAZZ_ESP) += esp_scsi.o   jazz_esp.o
 obj-$(CONFIG_SUN3X_ESP)+= NCR53C9x.o   sun3x_esp.o
 obj-$(CONFIG_SCSI_FCAL)+= fcal.o
 obj-$(CONFIG_SCSI_LASI700) += 53c700.o lasi700.o
diff --git a/drivers/scsi/jazz_esp.c b/drivers/scsi/jazz_esp.c
index 19dd4b9..10ceda1 100644
--- a/drivers/scsi/jazz_esp.c
+++ b/drivers/scsi/jazz_esp.c
@@ -1,307 +1,244 @@
-/*
- * jazz_esp.c: Driver for SCSI chip on Mips Magnum Boards (JAZZ architecture)
+/* jazz_esp.c: ESP front-end for MIPS JAZZ systems.
  *
- * Copyright (C) 1997 Thomas Bogendoerfer ([EMAIL PROTECTED])
- *
- * jazz_esp is based on David S. Miller's ESP driver and cyber_esp
+ * Copyright (C) 2007 Thomas Bogendörfer ([EMAIL PROTECTED])
  */
 
-#include 
 #include 
-#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "scsi.h"
-#include 
-#include "NCR53C9x.h"
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #include 
-#include 
-#include 
+#include 
 #include 
 
-#include 
-
-static int  dma_bytes_sent(struct NCR_ESP *esp, int fifo_count);
-static int  dma_can_transfer(struct NCR_ESP *esp, struct scsi_cmnd *sp);
-static void dma_dump_state(struct NCR_ESP *esp);
-static void dma_init_read(struct NCR_ESP *esp, __u32 vaddress, int length);
-static void dma_init_write(struct NCR_ESP *esp, __u32 vaddress, int length);
-static void dma_ints_off(struct NCR_ESP *esp);
-static void dma_ints_on(struct NCR_ESP *esp);
-static int  dma_irq_p(struct NCR_ESP *esp);
-static int  dma_ports_p(struct NCR_ESP *esp);
-static void dma_setup(struct NCR_ESP *esp, __u32 addr, int count, int write);
-static void dma_mmu_get_scsi_one (struct NCR_ESP *esp, struct scsi_cmnd *sp);
-static void dma_mmu_get_scsi_sgl (struct NCR_ESP *esp, struct scsi_cmnd *sp);
-static void dma_mmu_release_scsi_one (struct NCR_ESP *esp, struct scsi_cmnd 
*sp);
-static void dma_mmu_release_scsi_sgl (struct NCR_ESP *esp, struct scsi_cmnd 
*sp);
-static void dma_advance_sg (struct scsi_cmnd *sp);
-static void dma_led_off(struct NCR_ESP *);
-static void dma_led_on(struct NCR_ESP *);
-
-
-static volatile unsigned char cmd_buffer[16];
-   /* This is where all commands are put
-* before they are trasfered to the ESP chip
-* via PIO.
-*/
-
-static int jazz_esp_release(struct Scsi_Host *shost)
-{
-   if (shost->irq)
-   free_irq(shost->irq, NULL);
-   if (shost->dma_channel != 0xff)
-   free_dma(shost->dma_channel);
-   if (shost->io_port && shost->n_io_port)
-   release_region(shost->io_port, shost->n_io_port);
-   scsi_unregister(shost);
-   return 0;
-}
-
-/* Detection */
-static int jazz_esp_detect(struct scsi_host_template *tpnt)
-{
-struct NCR_ESP *esp;
-struct ConfigDev *esp_dev;
-
-/*
- * first assumption it is there:-)
- */
-if (1) {
-   esp_dev = NULL;
-   esp = esp_allocate(tpnt, esp_dev, 0);
-   
-   /* Do command transfer with programmed I/O */
-   esp->do_pio_cmds = 1;
-   
-   /* Required functions */
-   esp->dma_bytes_sent = &dma_bytes_sent;
-   esp->dma_can_transfer = &dma_can_transfer;
-   esp->dma_dump_state = &dma_dump_state;
-   esp->dma_init_read = &dma_init_read;
-   esp->dma_init_write = &dma_init_write;
-   esp->dma_ints_off = &dma_ints_off;
-   esp->dma_ints_on = &dma_ints_on;
-   esp->dma_irq_p = &dma_irq_p;
-   esp->dma_ports_p = &dma_ports_p;
-   esp->dma_setup = &dma_setup;
-
-   /* Optional functions */
-   esp->dma_barrier = NULL;
-   esp->dma_drain = NULL;
-   esp->dma_invalidate = NULL;
-   esp->dma_irq_entry = NULL;
-   esp->dma_irq_exit = NULL;
-   esp->dma_poll = NULL;
-   esp->dma_reset = NULL;
-   esp->dma_led_off = &dma_led_off;
-   esp->dma_led_on = &dma_led_on;
-   
-   /* virtual DMA functions */
-   esp->dma_mmu_get_scsi_one = &dma_mmu_get_scsi_one;
-   esp->dma_mmu_get_scsi_sgl = &dma_mmu_get_scsi_sgl;
-   esp->dma_mmu_release_scsi_one = &dma_mmu_release_scsi_one;
-   esp->dma_mmu_release_scsi_sgl = &dma_mmu_release_scsi_sgl;
-   esp->dma_advance_sg = &dma_advance_sg;
-
-
-   /* SCSI chip speed */
-  

Re: [PATCH] jazz_esp converted to use esp_core

[Thomas Bogendoerfer]

On Tue, May 22, 2007 at 12:00:41AM +0100, Christoph Hellwig wrote:
> On Mon, May 21, 2007 at 11:02:24PM +0200, Thomas Bogendoerfer wrote:
> > after chasing and fixing two jazz platform bugs and one MIPS dma mapping
> > bug, I finally succeeded in using the Dave's new esp_core (great work,
> > thank you Dave). Below is the patch.
> 
> Very nice driver.  The only thing that confused me a little are
> the various helper functions split out of esp_jazz_probe that
> make the code a bit odd to read.  Are these intentional or a carry
> over from the previous driver?

the sparc frontend used them, because most of these helper are
checking for prom properties, which the jazz doesn't have. I've
changed that and folded those little helpers into the probe function.
I'll send a new patch a couple of minutes.

> > --- a/drivers/scsi/Makefile
> > +++ b/drivers/scsi/Makefile
> > @@ -121,7 +121,7 @@ obj-$(CONFIG_BLK_DEV_3W__RAID) += 3w-.o
> >  obj-$(CONFIG_SCSI_3W_9XXX) += 3w-9xxx.o
> >  obj-$(CONFIG_SCSI_PPA) += ppa.o
> >  obj-$(CONFIG_SCSI_IMM) += imm.o
> > -obj-$(CONFIG_JAZZ_ESP) += NCR53C9x.o   jazz_esp.o
> > +obj-$(CONFIG_JAZZ_ESP) += jazz_esp.o
> 
> Note to Dave:  it probably would be nice to just build esp_scsi.o
> from the makefile like the old NCR53C9x drivers did instead of the
> Kconfig hackery, what do you think?

after seeing no objection to using esp_scsi.o like NCR53C9x.o, I also
changed that.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.[ RFC1925, 2.3 ]
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html