Re: patch so cciss stats are collected in /proc/stat

On Wed, Sep 29, 2004 at 06:58:55PM +0200, Andreas Haumer wrote:
> The majority of _our_ customers are using 2.4.x kernels
> (x beeing in the range from 19 to 28pre3) and it looks like
> it will stay that for quite a while...

I second this. The only one of our customers who tried 2.6 went back to
2.4 because of poor network performance, scheduling problems and stability
issues.

> PS: I know this is somewhat off topic, but I just want to raise
> my voice if I get the impression kernel developers forget about
> the "real world outside". I will shut up in a moment! Thank you!

Very true. You just have to read any 2.6 changelog to understand that
it *is* a development kernel ! The difference between 2.5 and 2.6 is
that the test platform now is larger and includes production systems.

Willy

-
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

Re: patch so cciss stats are collected in /proc/stat

On Wed, Sep 29, 2004 at 06:43:06PM +0200, Arjan van de Ven wrote:
> I doubt you have many customers using 2.4.28.... I suspect that by now
> the majority of people is either using an (ancient) 2.4 vendor kernel or
> a 2.6 kernel. The very low number of reports on lkml about 2.4 seems to
> confirm that ...

You must be kidding, aren't you ? I would better say that the very high
number of reports on lkml about 2.6 seems to confirm that 2.6 still is
a toy !

Marcelo has done a great job at getting 2.4 stable, and now people are
installing it in remote locations or embedded system with no planned
updated at all. And it works. Just like people did with 2.0 recently.
This may be why there are so few reports.

Willy

-
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

Re: [Patch] Fix oops on rmmod usb-storage

Alan Stern wrote:
> On Thu, 30 Sep 2004, Hannes Reinecke wrote:
> 
> 
>>Ok, since this is essential the same thread then on linux-scsi
>>(cf. "Bug: CD driver sends commands during host removal") the same 
>>solution applies here also.
>>
>>Alan, I did a different patch which omit the special case handling in
>>scsiglue.c and rather reorders usb_stor_control_thread. I'd prefer mine 
>>(naturally), but any of those will do.
>>And yes, both patches fix the problem.
>>
>>Back to the maintainer for patch inclusion.
>>
>>Cheers,
>>
>>Hannes
> 
> 
> No, your patch is incorrect.  In fact, it resembles the way the driver 
> used to work -- which caused an occasional oops.  The problem is that by 
> the time the usb_stor_control_thread() wakes up and sees that it has a new 
> command to process, the SCSI core may already have deallocated the 
> scsi_cmnd structure.  So the line where you assign to us->srb->result is 
> liable to raise an addressing exception.
> 
> Alan Stern
> 
Ok. (I knew there was something subtle going on).

RE: [PATCH] [Update #2] suspending I/Os to a device

Well, I wasn't going to clean up the fc sdev attributes yet. But - what the heck...

Here's an update the addresses James's comments:
- fc_transport class now contains target devices. The node_name, port_name, port_id attributes have
been moved to the scsi target.
- The fc transport functions for block/unblock by sdev has been removed.
- starget->shost has been reverted, using dev_to_shost() instead.
- the fc transport target block functions converted to use device_for_each_child().

-- James S

diff -uNr scsi-target-2.6/drivers/s390/scsi/zfcp_scsi.c scsi-target-2.6.patch/drivers/s390/scsi/zfcp_scsi.c
--- scsi-target-2.6/drivers/s390/scsi/zfcp_scsi.c	2004-09-12 19:36:58.000000000 -0400
+++ scsi-target-2.6.patch/drivers/s390/scsi/zfcp_scsi.c	2004-10-01 07:02:12.000000000 -0400
 <at>  <at>  -48,6 +48,8  <at>  <at> 

 static struct zfcp_unit *zfcp_unit_lookup(struct zfcp_adapter *, int, scsi_id_t,
 					  scsi_lun_t);
+static struct zfcp_port * zfcp_port_lookup(struct zfcp_adapter *, int,
+					 scsi_id_t);

 static struct device_attribute *zfcp_sysfs_sdev_attrs[];

 <at>  <at>  -398,6 +400,26  <at>  <at> 
  out:
 	return retval;
 }
+/*
+ * function:    zfcp_unit_tgt_lookup
+ *

[PATCH] sym53c8xx module parameter passing not working (2.5.6)

Hello, 

attached there is a patch that fixes the module parameter passing with
sym53c8xx_2. This is for SLES9 SuSE kernel, but it is so small that it
should apply for other kernels too.

Regards, 

Robert Heinzmann

------------------------------------------------------------------------
COMPUTER CONCEPT 
CC Computersysteme und Kommunikationstechnik GmbH 
Robert Heinzmann
Wiener Str. 114 - 116		Email:	heinzmann <at> cc-dresden.de
01219 Dresden			Telefon:	+49 (0)351/8 76 92-0
					Telefax:	+49 (0)351/8 76
92-99
					Internet:
http://www.cc-dresden.de
------------------------------------------------------------------------

The 2.6 version of sym53c8xx_2 did not read the module command line parameter properly. 
This was due to a missing call to sym53c8xx_setup().

This fix includes: 
- added missing call to sym53c8xx_setup()

Re: [PATCH] sym53c8xx module parameter passing not working (2.5.6)

On Fri, Oct 01, 2004 at 05:26:21PM +0200, Heinzmann, Robert wrote:
> Hello, 
> 
> attached there is a patch that fixes the module parameter passing with
> sym53c8xx_2. This is for SLES9 SuSE kernel, but it is so small that it
> should apply for other kernels too.

Given that no one except you noticed the lack of options so far what
about moving it to normal parameters instead, aka one option per setting
like all non-scsi and resent scsi drivers do?

-
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

RE: [PATCH] sym53c8xx module parameter passing not working (2.5.6)

Hello Christoph, 

> Given that no one except you noticed the lack of options so 
> far what about moving it to normal parameters instead, aka 
> one option per setting like all non-scsi and resent scsi drivers do?

The options are usually required for multi initiator configurations with
sym53c8xx only, which is not so common. Thus I just wrote this litte
(dirty ?) fix. Moving to normal parameters is something that should be
done, but I'm currently not able to do this :) If everything is beeing
moved to normal parameters, the documentation needs to be fixed too.

I think the current fix is sufficient, considering the installation base
of multi initiator sym53c8xx clusters.

Robert Heinzmann
-
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

Re: [PATCH] [Update #2] suspending I/Os to a device

On Fri, Oct 01, 2004 at 09:54:53AM -0400, James.Smart <at> Emulex.Com wrote:

> +/**
> + * fc_host_block - block all scsi devices managed by the calling host temporarily 
> + *		by putting each device in the SDEV_BLOCK state.
> + *  <at> shost:	scsi host pointer that contains all scsi device siblings.
> + *
> + * scsi lld's with a FC transport call this routine to temporarily stop all
> + * scsi commands to all devices managed by this host.  Called 
> + * from interrupt or normal process context.
> + *
> + * Returns zero if successful or error if not
> + *
> + * Notes:
> + *	The timeout and timer types are extracted from the fc transport 
> + *	attributes from the caller's host pointer.  This routine assumes no
> + *	locks are held on entry.
> + **/
> +int
> +fc_host_block(struct Scsi_Host *shost)

What is the difference between these new fc_host_block/unblock and
the current scsi_block/unblock_requests?

-- Patrick Mansfield
-
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

Re: [Patch] Fix oops on rmmod usb-storage

On Fri, 1 Oct 2004, Hannes Reinecke wrote:

> Ok. (I knew there was something subtle going on).
> What about the check for disconnecting later in 
> usb.c:usb_stor_control_thread?
> It will only trigger if usb_stor_control_thread has been awakened by 
> some other command and the device has been disconnected between 
> awakening and executing this check.

If by "awakened" you mean the call to up(&us->sema), then that's right.  
Remember that there will be some time between the call to up() and when 
the thread starts running.

> (This may well be impossible to trigger,

No, it isn't.  Uncommon yes, but not impossible.

>  but the set_bit() in 
> storage_disconnect() appears not to be protected by any lock).

set_bit, test_bit, test_and_clear_bit, etc. don't need to be protected by
locks because they execute atomically with appropriate memory barriers.  
That's one of the reasons they are useful.

> And I doubt it will work properly in that case as no scsi_done is not 
> called nor a proper status is set.

It's impossible for the control thread to set a status or call scsi_done
because us->srb will point to storage that probably has been deallocated.  
It works correctly nevertheless, because the SCSI core terminates the

RE: [PATCH] [Update #2] suspending I/Os to a device

The difference is, the fc functions:
- Changes the actual sdev state to indicate a "blocked" state  (you can see it in sysfs, etc)
- Starts a timer that will automatically unblock the sdev w/o lld intervention

-- james

> What is the difference between these new fc_host_block/unblock and
> the current scsi_block/unblock_requests?
-
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