RE: [PATCH 1/1] scsi: hpsa, add all PCI ID's that HP has in svn
-Original Message-
From: Tomas Henzl [mailto:the...@redhat.com]
Sent: Friday, January 17, 2014 9:14 AM
To: Miller, Mike (OS Dev); Andrew Morton; James E. J. Bottomley
Cc: LKML; LKML-scsi; h...@suse.de; Stephen M. Cameron
Subject: Re: [PATCH 1/1] scsi: hpsa, add all PCI ID's that HP has in svn
On 01/16/2014 08:51 PM, Mike Miller wrote:
From: Mike Miller mike.mil...@hp.com
This patch has every ID we have in our svn repository. Some
controllers were cancelled, others added, now the cancelled ones are
back. Apparently the debate rages on about which controllers are
cancelled, which are not, whatever. Please accept this patch. It is
dependent upon the patches I sent yesterday.
This patch made/tested against kernel-3.13.0-rc8
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/scsi/hpsa.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index
348b207..3affec5 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -100,6 +100,7 @@ static const struct pci_device_id
hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C,
0x3354},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C,
0x3355},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C,
0x3356},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x1920},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x1921},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x1922},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x1923},
@@ -108,15 +109,19 @@ static const struct pci_device_id
hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x1926},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x1928},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x1929},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x192A},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21BD},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21BE},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21BF},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C0},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C2},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C3},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C4},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C5},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C6},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C7},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C8},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C9},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21CA},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21CB},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21CC},
@@ -149,22 +154,29 @@ static struct board_type products[] = {
{0x3354103C, Smart Array P420i, SA5_access},
{0x3355103C, Smart Array P220i, SA5_access},
{0x3356103C, Smart Array P721m, SA5_access},
+ {0x1920103C, Smart Array P430i, SA5_access},
{0x1921103C, Smart Array P830i, SA5_access},
{0x1922103C, Smart Array P430, SA5_access},
{0x1923103C, Smart Array P431, SA5_access},
{0x1924103C, Smart Array P830, SA5_access},
+ {0x1925103C, Smart Array P831, SA5_access},
{0x1926103C, Smart Array P731m, SA5_access},
{0x1928103C, Smart Array P230i, SA5_access},
{0x1929103C, Smart Array P530, SA5_access},
+ {0x192A103C, Smart Array P531, SA5_access},
{0x21BD103C, Smart Array, SA5_access},
{0x21BE103C, Smart Array, SA5_access},
{0x21BF103C, Smart Array, SA5_access},
{0x21C0103C, Smart Array, SA5_access},
+ {0x21C1103C, Smart Array, SA5_access},
I think that both tables should be in sync - but there is no 0x21c1 in
hpsa_pci_device_id (and the 0x1925), could you clarify that?
Thanks, Tomas
Crap. It seems like these menial tasks get the better of me. I'll correct and
resubmit.
-- mikem
{0x21C2103C, Smart Array, SA5_access},
{0x21C3103C, Smart Array, SA5_access},
+ {0x21C4103C, Smart Array, SA5_access},
{0x21C5103C, Smart Array, SA5_access},
+ {0x21C6103C, Smart Array, SA5_access},
{0x21C7103C, Smart Array, SA5_access},
{0x21C8103C, Smart Array, SA5_access},
+ {0x21C9103C, Smart Array, SA5_access},
{0x21CA103C, Smart Array, SA5_access},
{0x21CB103C, Smart Array, SA5_access},
{0x21CC103C, Smart Array, SA5_access},
--
To unsubscribe from this list: send the line unsubscribe linux-scsi
in the body of a message to majord
RE: [PATCH 1/1] scsi: hpsa, add all PCI ID's that HP has in svn
-Original Message-
From: Hannes Reinecke [mailto:h...@suse.de]
Sent: Friday, January 17, 2014 9:31 AM
To: Miller, Mike (OS Dev)
Cc: Tomas Henzl; Andrew Morton; James E. J. Bottomley; LKML; LKML-scsi;
Stephen M. Cameron
Subject: Re: [PATCH 1/1] scsi: hpsa, add all PCI ID's that HP has in svn
On 01/17/2014 04:17 PM, Miller, Mike (OS Dev) wrote:
-Original Message-
From: Tomas Henzl [mailto:the...@redhat.com]
Sent: Friday, January 17, 2014 9:14 AM
To: Miller, Mike (OS Dev); Andrew Morton; James E. J. Bottomley
Cc: LKML; LKML-scsi; h...@suse.de; Stephen M. Cameron
Subject: Re: [PATCH 1/1] scsi: hpsa, add all PCI ID's that HP has in
svn
On 01/16/2014 08:51 PM, Mike Miller wrote:
From: Mike Miller mike.mil...@hp.com
This patch has every ID we have in our svn repository. Some
controllers were cancelled, others added, now the cancelled ones are
back. Apparently the debate rages on about which controllers are
cancelled, which are not, whatever. Please accept this patch. It is
dependent upon the patches I sent yesterday.
This patch made/tested against kernel-3.13.0-rc8
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/scsi/hpsa.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index
348b207..3affec5 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -100,6 +100,7 @@ static const struct pci_device_id
hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C,
0x3354},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C,
0x3355},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C,
0x3356},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x1920},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x1921},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x1922},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x1923},
@@ -108,15 +109,19 @@ static const struct pci_device_id
hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x1926},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x1928},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x1929},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C,
0x192A},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21BD},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21BE},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21BF},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C0},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C2},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C3},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C4},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C5},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C6},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C7},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C8},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21C9},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21CA},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21CB},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C,
0x21CC},
@@ -149,22 +154,29 @@ static struct board_type products[] = {
{0x3354103C, Smart Array P420i, SA5_access},
{0x3355103C, Smart Array P220i, SA5_access},
{0x3356103C, Smart Array P721m, SA5_access},
+ {0x1920103C, Smart Array P430i, SA5_access},
{0x1921103C, Smart Array P830i, SA5_access},
{0x1922103C, Smart Array P430, SA5_access},
{0x1923103C, Smart Array P431, SA5_access},
{0x1924103C, Smart Array P830, SA5_access},
+ {0x1925103C, Smart Array P831, SA5_access},
{0x1926103C, Smart Array P731m, SA5_access},
{0x1928103C, Smart Array P230i, SA5_access},
{0x1929103C, Smart Array P530, SA5_access},
+ {0x192A103C, Smart Array P531, SA5_access},
{0x21BD103C, Smart Array, SA5_access},
{0x21BE103C, Smart Array, SA5_access},
{0x21BF103C, Smart Array, SA5_access},
{0x21C0103C, Smart Array, SA5_access},
+ {0x21C1103C, Smart Array, SA5_access},
I think that both tables should be in sync - but there is no 0x21c1
in hpsa_pci_device_id (and the 0x1925), could you clarify that?
Thanks, Tomas
Crap. It seems like these menial tasks get the better of me. I'll correct
and
resubmit.
Hmm. Seeing that hpsa is now well capable of supporting even older
SmartArray controllers, is there really a point in updating the PCI-ID list
every
time?
Wouldn't you be better off by just using the catch-all phrase and remove all
Umm, if we did that but kept the PCI ID repository updated
RE: [PATCH 03/11] hpsa: add 5 second delay after doorbell reset
-Original Message-
From: James Bottomley [mailto:james.bottom...@hansenpartnership.com]
Sent: Monday, December 02, 2013 11:23 AM
To: Miller, Mike (OS Dev)
Cc: scame...@beardog.cce.hp.com; Tomas Henzl;
stephenmcame...@gmail.com; linux-scsi@vger.kernel.org; Teel, Scott Stacy
Subject: Re: [PATCH 03/11] hpsa: add 5 second delay after doorbell reset
On Mon, 2013-12-02 at 11:15 -0600, Mike Miller wrote:
On Sat, Nov 30, 2013 at 04:42:02PM -0800, James Bottomley wrote:
On Fri, 2013-11-08 at 09:31 -0600, scame...@beardog.cce.hp.com wrote:
On Fri, Nov 08, 2013 at 04:02:20PM +0100, Tomas Henzl wrote:
On 11/08/2013 03:44 PM, scame...@beardog.cce.hp.com wrote:
On Fri, Nov 08, 2013 at 02:51:37PM +0100, Tomas Henzl wrote:
On 11/07/2013 05:45 PM, Stephen M. Cameron wrote:
From: Stephen M. Cameron scame...@beardog.cce.hp.com
The hardware guys tell us that after initiating a software
reset via the doorbell register we need to wait 5 seconds
before attempting to talk to the board *at all*. This means
that we cannot watch the board to verify it transitions from
ready to to not ready then back ready, since this
transition will most likely happen during those 5 seconds
(though we can still verify the reset happens by watching
the driver version field get cleared.)
Signed-off-by: Stephen M. Cameron
scame...@beardog.cce.hp.com
---
drivers/scsi/hpsa.c | 32 +++-
1 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index
20fc598..fff5fd3 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -3781,6 +3781,13 @@ static int
hpsa_controller_hard_reset(struct pci_dev *pdev,
*/
dev_info(pdev-dev, using doorbell to reset
controller\n);
writel(use_doorbell, vaddr + SA5_DOORBELL);
+
+ /* PMC hardware guys tell us we need a 5 second
delay after
+ * doorbell reset and before any attempt to talk to
the board
+ * at all to ensure that this actually works and doesn't
fall
+ * over in some weird corner cases.
+ */
+ msleep(5000);
} else { /* Try to do it the PCI power state way */
/* Quoting from the Open CISS Specification: The
Power
@@ -3977,15 +3984,22 @@ static int
hpsa_kdump_hard_reset_controller(struct pci_dev *pdev)
need a little pause here */
msleep(HPSA_POST_RESET_PAUSE_MSECS);
I know it's complicated with a lot of different devices and
fw versions, but here^ we wait for 3sec - isn't the method -
wait for 3s then wait for board not ready a bit fragile, what if a
board comes up faster?
When the method watching the driver version works why
don't you want to use it regardless of the reset method used?
The watching the driver version thing is only there to catch
if the firmware guys break things and turn the reset into a
no-op (which happened with the PCI power manaegment based
reset and we didn't catch it for a year or so because we
didn't have that check)
We aren't supposed to look at the driver version field (or
anything) until we first verify the scratch pad register says
the firmware is ready. In the case of those boards that use
the doorbell reset, we aren't supposed to look at *anything* for
the first five seconds.
I have been bugging the firmware/hardware guys for a sane
reset procedure that actually works reliably for years with no luck.
For the SCSI over PCIe driver, being tired of this crap, I
simply unconditionally reset the device on driver load every
single time, and did this from the beginning. This kind of
forced the firmware and hardware guys to make the reset on
that thing work reliably and quickly, and since I did that
from the earliest days, they didn't have a chance to screw it up
without it being caught immediately.
For Smart Array, obviously it's too late for that approach.
OK, my question was more or less if this:
msleep(HPSA_POST_RESET_PAUSE_MSECS);
just before waiting for the board to enter BOARD_NOT_READY state
isn't dangerous - when the board enters a ready state in the
first 3sec it will wait indefinitely for the not_ready state
thus whether the test for not ready state shouldn't be removed.
The mechanism now works somehow and maybe it's better not to
touch it, I just wanted to draw your attention to that potential
problem.
Oh ok, I see. Thanks, yes that does look questionable. So you
are suggesting to skip the check for transition from NOT READY to
READY in the scratch pad register in all cases, since we have all
RE: [PATCH 1/1] remove cpqarray from mainline kernel
-Original Message- From: Jens Axboe [mailto:ax...@kernel.dk] Sent: Thursday, October 17, 2013 5:36 PM To: Andrew Morton Cc: Miller, Mike (OS Dev); LKML-scsi; LKML Subject: Re: [PATCH 1/1] remove cpqarray from mainline kernel On Thu, Oct 17 2013, Andrew Morton wrote: On Thu, 17 Oct 2013 12:52:26 -0500 Mike Miller mike.mil...@hp.com wrote: cpqarray hasn't been used in over 12 years. It's doubtful that anyone still uses the board. It's time the driver was removed from the mainline kernel. The only updates these days are minor and mostly done by people outside of HP. It's amazing the weird stuff people get up to. Perhaps we should disable it in config for a cycle or two, see if that flushes anyone out? I think that would be prudent, you never know what people run... -- Jens Axboe I agree with Andrew's suggestion. Should I submit a patch that only removes cpqarray from config? -- mikem -- 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/1] remove cpqarray from mainline kernel
-Original Message- From: Jens Axboe [mailto:ax...@kernel.dk] Sent: Friday, October 18, 2013 11:55 AM To: Miller, Mike (OS Dev); Andrew Morton Cc: LKML-scsi; LKML Subject: Re: [PATCH 1/1] remove cpqarray from mainline kernel On 10/18/2013 10:22 AM, Miller, Mike (OS Dev) wrote: -Original Message- From: Jens Axboe [mailto:ax...@kernel.dk] Sent: Thursday, October 17, 2013 5:36 PM To: Andrew Morton Cc: Miller, Mike (OS Dev); LKML-scsi; LKML Subject: Re: [PATCH 1/1] remove cpqarray from mainline kernel On Thu, Oct 17 2013, Andrew Morton wrote: On Thu, 17 Oct 2013 12:52:26 -0500 Mike Miller mike.mil...@hp.com wrote: cpqarray hasn't been used in over 12 years. It's doubtful that anyone still uses the board. It's time the driver was removed from the mainline kernel. The only updates these days are minor and mostly done by people outside of HP. It's amazing the weird stuff people get up to. Perhaps we should disable it in config for a cycle or two, see if that flushes anyone out? I think that would be prudent, you never know what people run... -- Jens Axboe I agree with Andrew's suggestion. Should I submit a patch that only removes cpqarray from config? I put one in yesterday: http://git.kernel.dk/?p=linux- block.git;a=commit;h=f504954db0ecccaded5397e3432cdaf7175602fb -- Jens Axboe Thanks, Jens. -- 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/4] hpsa: add HP Smart Array Gen9 PCI ID's
-Original Message- From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] Sent: Tuesday, September 10, 2013 5:02 PM To: Miller, Mike (OS Dev) Cc: Andrew Morton; LKML; LKML-scsi Subject: Re: [PATCH 1/4] hpsa: add HP Smart Array Gen9 PCI ID's On Wed, 2013-09-04 at 15:05 -0500, Mike Miller wrote: Patch 1 of 4 From: Mike Miller mike.mil...@hp.com Just for future reference, doing it this way means I have to edit the patch. The way git am works when applying patches is that if the first body line is a keyword it recognises (like From: or Subject: or Date:) it will fold that into the commit metadata, otherwise everything becomes the commit message. So by putting the redundant patch 1 of 4 first, git thinks the entire body is the commit message. James Sorry about that. I didn't realize git worked that way. So let me ask a dumb question, just having [PATCH x/y] in the subject line is enough? Would you like me to resubmit the patchset? -- mikem This patch adds the PCI ID's for HP Smart Array Gen9 controllers. Please consider this patch for inclusion. Signed-off-by: Mike Miller mike.mil...@hp.com --- -- 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/1] cciss: set max scatter gather entries to 32 on P600
-Original Message- From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] Sent: Wednesday, August 14, 2013 4:27 PM To: Miller, Mike (OS Dev); mi...@thumper.usa.hp.com Cc: Andrew Morton; Jens Axboe; LKML-scsi; LKML; the...@redhat.com; bubr...@redhat.com; scame...@beardog.cce.hp.com Subject: Re: [PATCH 1/1] cciss: set max scatter gather entries to 32 on P600 On Wed, 2013-08-14 at 15:52 -0500, Mike Miller wrote: Patch 1/1 From: Mike Miller mike.mil...@hp.com At one time we used to set the maximum number of scatter gather elements on all Smart Array controllers to 32. At some point in time the firmware began to write the appropriate value for each controller into the config table. The cciss driver would then read that and set h-maxsgentries. h-maxsgentries = readl((h-cfgtable-MaxSGElements); On the P600 that value is 544. Under some workloads a significant performance reduction may result. This patch forces the P600 to use only 32 scatter gather elements. Other controllers are not affected. Signed-off-by: Mike Miller mike.mil...@hp.com Signed-off-by: Dwight (Bud) Brown bubr...@redhat.com Signed-off-by: Tomas Henzl the...@redhat.com Acked-by: Stephen M. Cameron steve.came...@hp.com I don't quite understand the signoff chain on this patch. For a one line patch, are you saying it has three authors? James The patch origin is unknown. I got it from Tomas and Bud who think it may have originated from HP. I cleaned it up, compile tested it, and sent it on. I'll review my procedures for future patches. -- mikem -- 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/1] cciss: procfs updates to display info about many volumes
-Original Message- From: Andrew Morton [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 19, 2008 6:00 AM To: Jens Axboe Cc: Miller, Mike (OS Dev); LKML; LKML-scsi Subject: Re: [PATCH 1/1] cciss: procfs updates to display info about many volumes On Tue, 19 Feb 2008 11:48:18 +0100 Jens Axboe [EMAIL PROTECTED] wrote: On Mon, Feb 11 2008, Mike Miller wrote: Patch 1 of 1 This patch allows us to display information about all of the logical volumes configured on a particular without stepping on memory even when there are many volumes (128 or more) configured. This patch replaces the one submitted on 20071214. See http://groups.google.com/group/linux.kernel/browse_thread/thread/49a 50244b19f8855/ba3dc95b23391521?hl=enlnk=gstq=cciss#ba3dc95b2339152 1 which has not been merged. That patch displayed information about only the first logical volume on each controller and had negative side effects for some installers. Please consider this for inclusion. It looks ok, but has some flaws. Try to disable cciss scsi and tape support: In file included from drivers/block/cciss.c:231: drivers/block/cciss_scsi.c:1498:38: error: macro parameters must be comma-separated drivers/block/cciss.c: In function 'cciss_seq_show_header': drivers/block/cciss.c:272: error: implicit declaration of function 'cciss_seq_tape_report' drivers/block/cciss.c: In function 'cciss_proc_write': drivers/block/cciss.c:393: error: implicit declaration of function 'cciss_engage_scsi' You macro definition of cciss_seq_tape_report() is totally busted. Either write is as a macro OR as a function. Fix these up and resubmit, then I'll take it. It also need to be updated to use the non-racy proc_create(), please, as per Alexey's comments. Thanks all, I'll fix and resubmit. -- mikem - 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
FW: [Bug 9859] hp smart array E200i kernel panic upon boot
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 8:16 AM To: Miller, Mike (OS Dev) Subject: [Bug 9859] hp smart array E200i kernel panic upon boot http://bugzilla.kernel.org/show_bug.cgi?id=9859 [EMAIL PROTECTED] changed: What|Removed |Added -- -- CC||[EMAIL PROTECTED] --- Comment #14 from [EMAIL PROTECTED] 2008-02-14 06:16 --- I'm facing a problem that seems related also using gentoo on a x86_64 configuration (Dual Opteron 270 on Tyan K8SE) I'm booting from a 3ware 9500s controller. Everything went find with 2.6.23 but stating from 2.6.24 i get the same kernel panic message: Unable to mount root fs on unknown-block(0,0) The sd messages for sda and sdb that appear under 2.6.23 do no longer appear with 2.6.24 though the 3ware driver reports it's loaded Andrew, The latest reports being added to the bug point to something other than cciss. This user is reporting the same problem on a white box with a 3ware SAS card. I've recreated the problem in my lab with a DL385 Opteron server. I've confirmed the 2.6.24.x kernels do not fail on Intel based platforms. The question is what changed in the kernel to to break AMD platforms. I'll keep looking and post any updates. -- mikem -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - 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] cciss: section mismatch
--- linux-2.6.24-rc7-git1.orig/drivers/block/cciss.c
+++ linux-2.6.24-rc7-git1/drivers/block/cciss.c
@@ -2927,7 +2927,7 @@ default_int_mode:
return;
}
-static int cciss_pci_init(ctlr_info_t *c, struct pci_dev *pdev)
+static int __devinit cciss_pci_init(ctlr_info_t *c, struct pci_dev
+*pdev)
{
ushort subsystem_vendor_id, subsystem_device_id, command;
__u32 board_id, scratchpad = 0;
Thanks, Randy.
-
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 1/3] cciss: export more attributes to sysfs (repost)
Mike, what's going on? I definitely told you last time I looked at this patch that it is a bug to call sysfs_remove_group() under spinlock, because sysfs_remove_group() takes sleeping locks. Yet here it is again. Maybe you lost my email. It is here: http://lkml.org/lkml/2007/11/20/77 Also please see http://lkml.org/lkml/2007/11/20/79 Andrew, My apologies. Obviously I did not read your email closely. When I return from vacation I will address these issues. -- mikem - 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 22/30] blk_end_request: changing cpqarray (take 4)
-Original Message-
From: Kiyoshi Ueda [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 11, 2007 4:50 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org;
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; Miller, Mike (OS Dev)
Subject: [PATCH 22/30] blk_end_request: changing cpqarray (take 4)
This patch converts cpqarray to use blk_end_request interfaces.
Related 'ok' arguments are converted to 'error'.
cpqarray is a little bit different from normal drivers.
cpqarray directly calls bio_endio() and disk_stat_add() when
completing request. But those can be replaced with
__end_that_request_first().
After the replacement, request completion procedures of those
drivers become like the following:
o end_that_request_first()
o add_disk_randomness()
o end_that_request_last()
This can be converted to __blk_end_request() by following the
rule (b) mentioned in the patch subject [PATCH 01/30]
blk_end_request: add new request completion interface.
Cc: Mike Miller [EMAIL PROTECTED]
Signed-off-by: Kiyoshi Ueda [EMAIL PROTECTED]
Signed-off-by: Jun'ichi Nomura [EMAIL PROTECTED]
Acked-by: Mike Miller [EMAIL PROTECTED]
---
drivers/block/cpqarray.c | 36 +++-
1 files changed, 7 insertions(+), 29 deletions(-)
Index: 2.6.24-rc4/drivers/block/cpqarray.c
===
--- 2.6.24-rc4.orig/drivers/block/cpqarray.c
+++ 2.6.24-rc4/drivers/block/cpqarray.c
@@ -167,7 +167,6 @@ static void start_io(ctlr_info_t *h);
static inline void addQ(cmdlist_t **Qptr, cmdlist_t *c);
static inline cmdlist_t *removeQ(cmdlist_t **Qptr, cmdlist_t
*c); -static inline void complete_buffers(struct bio *bio,
int ok); static inline void complete_command(cmdlist_t *cmd,
int timeout);
static irqreturn_t do_ida_intr(int irq, void *dev_id); @@
-980,26 +979,13 @@ static void start_io(ctlr_info_t *h)
}
}
-static inline void complete_buffers(struct bio *bio, int ok) -{
- struct bio *xbh;
-
- while (bio) {
- xbh = bio-bi_next;
- bio-bi_next = NULL;
-
- bio_endio(bio, ok ? 0 : -EIO);
-
- bio = xbh;
- }
-}
/*
* Mark all buffers that cmd was responsible for
*/
static inline void complete_command(cmdlist_t *cmd, int timeout) {
struct request *rq = cmd-rq;
- int ok=1;
+ int error = 0;
int i, ddir;
if (cmd-req.hdr.rcode RCODE_NONFATAL @@
-1011,16 +997,17 @@ static inline void complete_command(cmdl
if (cmd-req.hdr.rcode RCODE_FATAL) {
printk(KERN_WARNING Fatal error on ida/c%dd%d\n,
cmd-ctlr, cmd-hdr.unit);
- ok = 0;
+ error = -EIO;
}
if (cmd-req.hdr.rcode RCODE_INVREQ) {
printk(KERN_WARNING Invalid
request on ida/c%dd%d = (cmd=%x sect=%d cnt=%d sg=%d ret=%x)\n,
cmd-ctlr, cmd-hdr.unit,
cmd-req.hdr.cmd,
cmd-req.hdr.blk,
cmd-req.hdr.blk_cnt,
cmd-req.hdr.sg_cnt,
cmd-req.hdr.rcode);
- ok = 0;
+ error = -EIO;
}
- if (timeout) ok = 0;
+ if (timeout)
+ error = -EIO;
/* unmap the DMA mapping for all the scatter gather
elements */
if (cmd-req.hdr.cmd == IDA_READ)
ddir = PCI_DMA_FROMDEVICE; @@ -1030,18
+1017,9 @@ static inline void complete_command(cmdl
pci_unmap_page(hba[cmd-ctlr]-pci_dev,
cmd-req.sg[i].addr,
cmd-req.sg[i].size, ddir);
- complete_buffers(rq-bio, ok);
-
- if (blk_fs_request(rq)) {
- const int rw = rq_data_dir(rq);
-
- disk_stat_add(rq-rq_disk, sectors[rw],
rq-nr_sectors);
- }
-
- add_disk_randomness(rq-rq_disk);
-
DBGPX(printk(Done with %p\n, rq););
- end_that_request_last(rq, ok ? 1 : -EIO);
+ if (__blk_end_request(rq, error, blk_rq_bytes(rq)))
+ BUG();
}
/*
-
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 21/30] blk_end_request: changing cciss (take 4)
This patch converts cciss to use blk_end_request interfaces.
Related 'uptodate' arguments are converted to 'error'.
cciss is a little bit different from normal drivers.
cciss directly calls bio_endio() and disk_stat_add() when
completing request. But those can be replaced with
__end_that_request_first().
After the replacement, request completion procedures of those
drivers become like the following:
o end_that_request_first()
o add_disk_randomness()
o end_that_request_last()
This can be converted to blk_end_request() by following the
rule (a) mentioned in the patch subject [PATCH 01/30]
blk_end_request: add new request completion interface.
Cc: Mike Miller [EMAIL PROTECTED]
Signed-off-by: Kiyoshi Ueda [EMAIL PROTECTED]
Signed-off-by: Jun'ichi Nomura [EMAIL PROTECTED]
---
drivers/block/cciss.c | 25 +++--
1 files changed, 3 insertions(+), 22 deletions(-)
Index: 2.6.24-rc4/drivers/block/cciss.c
===
--- 2.6.24-rc4.orig/drivers/block/cciss.c
+++ 2.6.24-rc4/drivers/block/cciss.c
@@ -1187,17 +1187,6 @@ static int cciss_ioctl(struct inode *ino
}
}
-static inline void complete_buffers(struct bio *bio, int status) -{
- while (bio) {
- struct bio *xbh = bio-bi_next;
-
- bio-bi_next = NULL;
- bio_endio(bio, status ? 0 : -EIO);
- bio = xbh;
- }
-}
-
static void cciss_check_queues(ctlr_info_t *h) {
int start_queue = h-next_to_run; @@ -1263,21
+1252,14 @@ static void cciss_softirq_done(struct re
pci_unmap_page(h-pdev, temp64.val,
cmd-SG[i].Len, ddir);
}
- complete_buffers(rq-bio, (rq-errors == 0));
-
- if (blk_fs_request(rq)) {
- const int rw = rq_data_dir(rq);
-
- disk_stat_add(rq-rq_disk, sectors[rw],
rq-nr_sectors);
- }
-
#ifdef CCISS_DEBUG
printk(Done with %p\n, rq);
#endif /* CCISS_DEBUG */
- add_disk_randomness(rq-rq_disk);
+ if (blk_end_request(rq, (rq-errors == 0) ? 0 : -EIO,
blk_rq_bytes(rq)))
+ BUG();
+
spin_lock_irqsave(h-lock, flags);
- end_that_request_last(rq, (rq-errors == 0));
cmd_free(h, cmd, 1);
cciss_check_queues(h);
spin_unlock_irqrestore(h-lock, flags); @@ -2544,7
+2526,6 @@ after_error_processing:
}
cmd-rq-data_len = 0;
cmd-rq-completion_data = cmd;
- blk_add_trace_rq(cmd-rq-q, cmd-rq, BLK_TA_COMPLETE);
Why is this removed?
-- mikem
blk_complete_request(cmd-rq);
}
-
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 21/30] blk_end_request: changing cciss (take 4)
Why is this removed? Sorry for the less explanation. Because it is done in __end_that_request_first() called from blk_end_request(). I'll add the explanation to the patch description when I update the patch. Thank you. I've Acked the patch. -- mikem - 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 21/30] blk_end_request: changing cciss (take 4)
-Original Message-
From: Kiyoshi Ueda [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 11, 2007 4:50 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; linux-scsi@vger.kernel.org;
[EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; Miller, Mike (OS Dev)
Subject: [PATCH 21/30] blk_end_request: changing cciss (take 4)
This patch converts cciss to use blk_end_request interfaces.
Related 'uptodate' arguments are converted to 'error'.
cciss is a little bit different from normal drivers.
cciss directly calls bio_endio() and disk_stat_add() when
completing request. But those can be replaced with
__end_that_request_first().
After the replacement, request completion procedures of those
drivers become like the following:
o end_that_request_first()
o add_disk_randomness()
o end_that_request_last()
This can be converted to blk_end_request() by following the
rule (a) mentioned in the patch subject [PATCH 01/30]
blk_end_request: add new request completion interface.
Cc: Mike Miller [EMAIL PROTECTED]
Signed-off-by: Kiyoshi Ueda [EMAIL PROTECTED]
Signed-off-by: Jun'ichi Nomura [EMAIL PROTECTED]
Acked-by: Mike Miller [EMAIL PROTECTED]
---
drivers/block/cciss.c | 25 +++--
1 files changed, 3 insertions(+), 22 deletions(-)
Index: 2.6.24-rc4/drivers/block/cciss.c
===
--- 2.6.24-rc4.orig/drivers/block/cciss.c
+++ 2.6.24-rc4/drivers/block/cciss.c
@@ -1187,17 +1187,6 @@ static int cciss_ioctl(struct inode *ino
}
}
-static inline void complete_buffers(struct bio *bio, int status) -{
- while (bio) {
- struct bio *xbh = bio-bi_next;
-
- bio-bi_next = NULL;
- bio_endio(bio, status ? 0 : -EIO);
- bio = xbh;
- }
-}
-
static void cciss_check_queues(ctlr_info_t *h) {
int start_queue = h-next_to_run; @@ -1263,21
+1252,14 @@ static void cciss_softirq_done(struct re
pci_unmap_page(h-pdev, temp64.val,
cmd-SG[i].Len, ddir);
}
- complete_buffers(rq-bio, (rq-errors == 0));
-
- if (blk_fs_request(rq)) {
- const int rw = rq_data_dir(rq);
-
- disk_stat_add(rq-rq_disk, sectors[rw],
rq-nr_sectors);
- }
-
#ifdef CCISS_DEBUG
printk(Done with %p\n, rq);
#endif /* CCISS_DEBUG */
- add_disk_randomness(rq-rq_disk);
+ if (blk_end_request(rq, (rq-errors == 0) ? 0 : -EIO,
blk_rq_bytes(rq)))
+ BUG();
+
spin_lock_irqsave(h-lock, flags);
- end_that_request_last(rq, (rq-errors == 0));
cmd_free(h, cmd, 1);
cciss_check_queues(h);
spin_unlock_irqrestore(h-lock, flags); @@ -2544,7
+2526,6 @@ after_error_processing:
}
cmd-rq-data_len = 0;
cmd-rq-completion_data = cmd;
- blk_add_trace_rq(cmd-rq-q, cmd-rq, BLK_TA_COMPLETE);
blk_complete_request(cmd-rq);
}
-
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] cciss: force ignore of responses to unsent scsi commands after kexec reboot
Vivek wrote: I think this is not the right usage of reset_devices parameter. This parameter instructs the driver to reset the device before going ahead with rest of the initialization before as underlying device might not be in a sane state. kexec/kdump is one of the usages and this can also be useful in the case of BIOS not doing its job. When I had proposed crash_boot parameter for kexec/kdump purposes, that time andrew had suggested that he is afraid that driver authors will use this parameter to solve all kind of problems. I think we should stick to the theme of the parameter and implement the reset routine for cciss driver instead of simply returning back. Consider the case of hypothetical scenario where somebody booted the kernel with reset_device parameter (because of unreliable bios) and if there is a problem on kernel side that after it issues the command it lost track of that (because of kernel bug) then driver will never catch that bug as upon receiving the response it will simply ignore that. Mike, you know most about this device. Can you please help out with implementing a reset routing for it? Vivek I think I finally have an idea that will work. (`bout time!) We actually have 2 different issues. One is that there may outstanding commands on the controller when the kdump kernel initializes. Our SAS controllers support the reset message defined in the open CISS spec which will (hopefully) resolve this issue. The second problem is that I cannot allocate my MSI-X vectors because I couldn't free the vectors then disable MSI. So the cciss driver would most likely panic at that time. My idea for this is to put the card into INTx mode rather than MSI or MSI-X. That should the 2nd issue. I haven't tested the 64xx series to see if they support the reset message. I should to write the code today, maybe test by tomorrow and then send something upstream. mikem - 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: cciss broken with 2.6.22-rc2
-Original Message-
From: Hannes Reinecke [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 29, 2007 7:01 AM
To: Miller, Mike (OS Dev); SCSI Mailing List
Subject: cciss broken with 2.6.22-rc2
Hi Mike,
with the latest git snapshot the cciss driver hangs during
initialisation. Enabling debug output I get:
cciss0: 0x3230 at PCI :06:00.0 IRQ 4338 using DAC
Sending cff - down to controller
cciss: FIFO Empty read
cciss: Read cff0 back from board
Sending cff - down to controller
cciss: FIFO Empty read
cciss: Read cff2 back from board
LUN Data
--
Sending cff - down to controller
cciss: FIFO Empty read
cciss: Read cff0 back from board
blocks= 286677120 block_size= 512
Sending cff - down to controller
cciss: FIFO Empty read
cciss: Read cff2 back from board
heads=255, sectors=32, cylinders=35132
Sending 5103000 - down to controller
and then the machine hangs.
I'll try to investigate, but as I'm no expert in cciss my
results might be limited.
Looks like one of your recent fixes broke it; 2.6.21 worked fine.
Hannes,
Actually, it was someone else who broke the driver by making changes in msi.c.
This patch fixes the hang:
From: Mike Miller (OS Dev) [EMAIL PROTECTED] writes:
Found what seems the problem with our vectors being listed backward. In
drivers/pci/msi.c we should be using list_add_tail rather than list_add to
preserve the ordering across various kernels. Please consider this for
inclusion.
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index 0e67723..d74975d 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -333,7 +333,7 @@ static int msi_capability_init(struct pci_dev *dev)
msi_mask_bits_reg(pos, is_64bit_address(control)),
maskbits);
}
- list_add(entry-list, dev-msi_list);
+ list_add_tail(entry-list, dev-msi_list);
/* Configure MSI capability structure */
ret = arch_setup_msi_irqs(dev, 1, PCI_CAP_ID_MSI); @@ -404,7 +404,7 @@
static int msix_capability_init(struct pci_dev *dev,
entry-dev = dev;
entry-mask_base = base;
- list_add(entry-list, dev-msi_list);
+ list_add_tail(entry-list, dev-msi_list);
}
ret = arch_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSIX);
This patch fixes an Oops during rmmod:
Signed-off-by: Mike Miller [EMAIL PROTECTED]
Signed-off-by: Chase Maupin [EMAIL PROTECTED]
Signed-off-by: Eric W. Biederman [EMAIL PROTECTED]
---
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index e01380b..6632150 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -558,12 +558,12 @@ static int msi_free_irqs(struct pci_dev* dev)
list_for_each_entry_safe(entry, tmp, dev-msi_list, list) {
if (entry-msi_attrib.type == PCI_CAP_ID_MSIX) {
- if (list_is_last(entry-list, dev-msi_list))
- iounmap(entry-mask_base);
-
writel(1, entry-mask_base + entry-msi_attrib.entry_nr
* PCI_MSIX_ENTRY_SIZE
+ PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
+
+ if (list_is_last(entry-list, dev-msi_list))
+ iounmap(entry-mask_base);
}
list_del(entry-list);
kfree(entry);
WARNING: These patches may suffer from wordwrap as they are coming from my
microsucks email client.
We found and fixed these late last week. So I hope they make into Linus' git
tree ASAP.
Thanks,
mikem
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] cciss: Fix pci_driver.shutdown while device is still active
-Original Message-
From: Gerald Britton [mailto:[EMAIL PROTECTED]
Sent: Monday, May 14, 2007 12:53 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
Miller, Mike (OS Dev); ISS StorageDev;
linux-scsi@vger.kernel.org; [EMAIL PROTECTED]
Subject: [PATCH] cciss: Fix pci_driver.shutdown while device
is still active
Fix an Oops in the cciss driver caused by system shutdown
while a filesystem on a cciss device is still active. The
cciss_remove_one function only properly removes the device if
the device has been cleanly released by its users, which is
not the case when the pci_driver.shutdown method is called.
Please send the Oops output.
mikem
This patch adds a new cciss_shutdown function to better match
the pattern used by various SCSI drivers: deactivate device
interrupts and flush caches.
It also alters the cciss_remove_one function to match and
readds the __devexit annotation that was removed when
cciss_remove_one was serving as the pci_driver.shutdown method.
Signed-off-by: Gerald Britton [EMAIL PROTECTED]
---
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 370dfe1..5acc6c4 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -3469,13 +3469,39 @@ static int __devinit
cciss_init_one(struct pci_dev *pdev,
return -1;
}
-static void cciss_remove_one(struct pci_dev *pdev)
+static void cciss_shutdown(struct pci_dev *pdev)
{
ctlr_info_t *tmp_ptr;
- int i, j;
+ int i;
char flush_buf[4];
int return_code;
+ tmp_ptr = pci_get_drvdata(pdev);
+ if (tmp_ptr == NULL)
+ return;
+ i = tmp_ptr-ctlr;
+ if (hba[i] == NULL)
+ return;
+
+ /* Turn board interrupts off and send the flush cache
command */
+ /* sendcmd will turn off interrupt, and send the flush...
+ * To write all data in the battery backed cache to disks */
+ memset(flush_buf, 0, 4);
+ return_code = sendcmd(CCISS_CACHE_FLUSH, i, flush_buf,
4, 0, 0, 0, NULL,
+ TYPE_CMD);
+ if (return_code == IO_OK) {
+ printk(KERN_INFO Completed flushing cache on
controller %d\n, i);
+ } else {
+ printk(KERN_WARNING Error flushing cache on
controller %d\n, i);
+ }
+ free_irq(hba[i]-intr[2], hba[i]);
+}
+
+static void __devexit cciss_remove_one(struct pci_dev *pdev) {
+ ctlr_info_t *tmp_ptr;
+ int i, j;
+
if (pci_get_drvdata(pdev) == NULL) {
printk(KERN_ERR cciss: Unable to remove device \n);
return;
@@ -3506,18 +3532,7 @@ static void cciss_remove_one(struct
pci_dev *pdev)
cciss_unregister_scsi(i); /* unhook from SCSI subsystem */
- /* Turn board interrupts off and send the flush cache
command */
- /* sendcmd will turn off interrupt, and send the flush...
- * To write all data in the battery backed cache to disks */
- memset(flush_buf, 0, 4);
- return_code = sendcmd(CCISS_CACHE_FLUSH, i, flush_buf,
4, 0, 0, 0, NULL,
- TYPE_CMD);
- if (return_code == IO_OK) {
- printk(KERN_INFO Completed flushing cache on
controller %d\n, i);
- } else {
- printk(KERN_WARNING Error flushing cache on
controller %d\n, i);
- }
- free_irq(hba[i]-intr[2], hba[i]);
+ cciss_shutdown(pdev);
#ifdef CONFIG_PCI_MSI
if (hba[i]-msix_vector)
@@ -3550,7 +3565,7 @@ static struct pci_driver cciss_pci_driver = {
.probe = cciss_init_one,
.remove = __devexit_p(cciss_remove_one),
.id_table = cciss_pci_device_id,/* id_table */
- .shutdown = cciss_remove_one,
+ .shutdown = cciss_shutdown,
};
/*
-
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] cciss: Fix warnings during compilation under 32bit environment
-Original Message-
From: Hisashi Hifumi [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 18, 2007 2:03 AM
To: Miller, Mike (OS Dev); [EMAIL PROTECTED]
Subject: [PATCH] cciss: Fix warnings during compilation under
32bit environment
Hi.
I fixed following warnings.
drivers/block/cciss.c: In function `do_cciss_request':
drivers/block/cciss.c:2555: warning: right shift count =
width of type
drivers/block/cciss.c:2556: warning: right shift count =
width of type
drivers/block/cciss.c:2557: warning: right shift count =
width of type
drivers/block/cciss.c:2558: warning: right shift count =
width of type
Signed-off-by :Hisashi Hifumi [EMAIL PROTECTED]
Nak. You still haven't told where you saw these warnings. What compiler
are you using? I do not see these in my 32-bit environment.
mikem
--- linux-2.6.21-rc7.org/drivers/block/cciss.c2007-04-17
16:36:02.0 +0900
+++ linux-2.6.21-rc7/drivers/block/cciss.c2007-04-17
16:25:53.0 +0900
@@ -2552,10 +2552,10 @@ static void do_cciss_request(request_que
} else {
c-Request.CDBLen = 16;
c-Request.CDB[1]= 0;
- c-Request.CDB[2]= (start_blk 56) 0xff;//MSB
- c-Request.CDB[3]= (start_blk 48) 0xff;
- c-Request.CDB[4]= (start_blk 40) 0xff;
- c-Request.CDB[5]= (start_blk 32) 0xff;
+ c-Request.CDB[2]= sizeof(start_blk) 4 ?
(start_blk 56) 0xff : 0; //MSB
+ c-Request.CDB[3]= sizeof(start_blk) 4 ?
(start_blk 48) 0xff : 0;
+ c-Request.CDB[4]= sizeof(start_blk) 4 ?
(start_blk 40) 0xff : 0;
+ c-Request.CDB[5]= sizeof(start_blk) 4 ?
(start_blk 32) 0xff :
+0;
c-Request.CDB[6]= (start_blk 24) 0xff;
c-Request.CDB[7]= (start_blk 16) 0xff;
c-Request.CDB[8]= (start_blk 8) 0xff;
Thanks,
-
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] cciss: Fix warnings during compilation under 32bit environment
-Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Thursday, April 19, 2007 10:19 AM To: Miller, Mike (OS Dev) Cc: Hisashi Hifumi; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; Cameron, Steve Subject: RE: [PATCH] cciss: Fix warnings during compilation under 32bit environment On Thu, 2007-04-19 at 15:09 +, Miller, Mike (OS Dev) wrote: Nak. You still haven't told where you saw these warnings. What compiler are you using? I do not see these in my 32-bit environment. I think it's seen with CONFIG_LBD=n on 32 bits In that configuration, sector_t is a u32 (it's u64 even on 32 bits with CONFIG_LBD=y). The proposed code change is a simple cut and paste from the sd driver. Isn't there a better way than testing each one? mikem 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] cciss: Fix warnings during compilation under 32bitenvironment
-Original Message- From: James Bottomley [mailto:[EMAIL PROTECTED] Sent: Thursday, April 19, 2007 11:22 AM To: Miller, Mike (OS Dev) Cc: Hisashi Hifumi; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; linux-scsi@vger.kernel.org; Cameron, Steve Subject: RE: [PATCH] cciss: Fix warnings during compilation under 32bitenvironment On Thu, 2007-04-19 at 16:12 +, Miller, Mike (OS Dev) wrote: Nak. You still haven't told where you saw these warnings. What compiler are you using? I do not see these in my 32-bit environment. I think it's seen with CONFIG_LBD=n on 32 bits In that configuration, sector_t is a u32 (it's u64 even on 32 bits with CONFIG_LBD=y). The proposed code change is a simple cut and paste from the sd driver. Isn't there a better way than testing each one? It's not such a bad option. The sizeof() test is compile time determinable, so the compiler simply zeros the fields in the CONFIG_LBD=n case and does the shift for CONFIG_LBD=y. It certainly never compiles to four inline condition checks. OKIE-DOKIE then, add the change. Acked-by: Mike Miller [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] Perverting cciss
James wrote: On Thu, 2007-04-05 at 11:03 +0100, Christoph Hellwig wrote: On Thu, Apr 05, 2007 at 11:58:06AM +0200, Hannes Reinecke wrote: Hi All, this patch adds the SG_IO ioctl to the cciss driver. As the driver is capable of sending SCSI CDBs to the controller there is no reason why we shouldn't exploit it. This way we get to use all the nice sg_utils for the cciss driver. And a persistent device name for free. Instead of adding yet another implementation of SG_IO please implement support for REQ_TYPE_BLOCK_PC requests and add all the nice block layer passthrough ioctls to it. Actually, I happen to know that HP is in the process of implementing this correctly (via REQ_TYPE_BLOCK_PC). I can't reveal the details but it has something to do with a well known Linux High Availability company needing SG_IO for sg_persist to work ... James NAK. Please do not add this patch to cciss. We are working SG_IO internally and will post the patch soon. mikem - 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 1/2] cciss: fix for 2TB support
-Original Message-
From: Mike Miller (OS Dev) [mailto:[EMAIL PROTECTED]
Andrew,
Using this test program and changing the type of x to int,
long, long long signed and unsigned the comparison always
worked on x86, x86_64, and ia64. It looks to me like the
comparsion will always do what we expect. Unless you see some
other problem.
#include stdio.h
int main(int argc, char *argv[])
{
unsigned long long x;
x = 0x;
printf(sizeof(x) == 8 ?
x = %lld, sizeof(x) = %d\n :
x = %ld, sizeof(x) = %d\n, x, sizeof(x));
if (x == 0x)
printf(equal\n);
else
printf(not equal\n);
}
-- mikem
BTW: also changed x to be 8 f's, 16 f's, and 8 and 8 as shown.
-
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: can't boot 2.6.13
Thanks, Eric. Anyone have any ideas why my cciss based system won't boot? mikem -Original Message- From: Moore, Eric Dean [mailto:[EMAIL PROTECTED] Sent: Thursday, September 08, 2005 5:52 PM To: Miller, Mike (OS Dev); linux-kernel@vger.kernel.org; linux-scsi@vger.kernel.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: can't boot 2.6.13 On Thursday, September 08, 2005 3:19 PM, Mike Miller(HP) wrote: I am not able to boot the 2.6.13 version of the kernel. I've tried different systems, tried downloading again, still nothing. Here's the last thing I see from the serial port: md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. RAMDISK: Compressed image found at block 0 input: AT Translated Set 2 keyboard on isa0060/serio0 VFS: Mounted root (ext2 filesystem). logips2pp: Detected unknown logitech mouse model 1 input: PS/2 Logitech Mouse on isa0060/serio1 SCSI subsystem initialized Fusion MPT base driver 3.03.02 Copyright (c) 1999-2005 LSI Logic Corporation We introduced split drivers for 2.6.13. There are new layer drivers that sit ontop of mptscsih.ko. These drivers are split along bus protocal, so there is mptspi.ko, mptfc.ko, and mptsas.ko. This is to tie into the scsi transport layers that are split the same. For 1030(a SPI controller) If your using RedHat, you need to change mptscish to mptspi in /etc/modprobe.conf. If your using SuSE, you need to change mptscish to mptspi in /etc/sysconfig/kernel - 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
2.6: how do I this in sysfs?
I've been asked to pass this on for some kind of clarification.
We have management apps requiring specific information from the Smart
Array controller. We're trying to use sysfs to accomplish the task. An
example of what we need to do is below. I'm sure some of you will
recognize this as CSMI.
The basic question is this: how do you pass complex data structures back
and forth between user/kernelspace and still abide by the rules around
sysfs like: one attribute per file, text files only, etc?
Thanks,
mikem
We have a storage controller which has some features which
Work more or less as follows, but are not really regular i/o
In the sense that they are used for configuration or
management Of devices rather than being the primary purpose
of the devices.
The host constructs a somewhat complex data buffer according
to a predefined convention, And fills out certain parts of
the buffer to formulate what could be a query, or perhaps
configuration data.
It then constructs a command which includes scatter gather
elements Which reference this data buffer, and writes the bus
address of the Command to a register on the controller.
The controller reads the command and data buffer from host
memory, And DMAs the results of the query into the same data
buffer, and issues An interrupt to the host. So there's a
bidirectional transfer Of data to/from the data buffer.
For example, one the data buffers the controller understands
looks like what's below:
User applications need to be able to use this interface to
talk To the controller. What's the recommended way to
implement such An interface?
// CC_CSMI_SAS_GET_PHY_INFO
typedef struct _COMMAND_HEADER {
__u32 IOControllerNumber;
__u32 Length;
__u32 ReturnCode;
__u32 Timeout;
__u16 Direction;
} COMMAND_HEADER, *PCOMMAND_HEADER;
typedef struct _CSMI_SAS_IDENTIFY {
__u8 bDeviceType;
__u8 bRestricted;
__u8 bInitiatorPortProtocol;
__u8 bTargetPortProtocol;
__u8 bRestricted2[8];
__u8 bSASAddress[8];
__u8 bPhyIdentifier;
__u8 bSignalClass;
__u8 bReserved[6];
} CSMI_SAS_IDENTIFY,
*PCSMI_SAS_IDENTIFY;
typedef struct _CSMI_SAS_PHY_ENTITY {
CSMI_SAS_IDENTIFY Identify;
__u8 bPortIdentifier;
__u8 bNegotiatedLinkRate;
__u8 bMinimumLinkRate;
__u8 bMaximumLinkRate;
__u8 bPhyChangeCount;
__u8 bAutoDiscover;
__u8 bReserved[2];
CSMI_SAS_IDENTIFY Attached;
} CSMI_SAS_PHY_ENTITY,
*PCSMI_SAS_PHY_ENTITY;
typedef struct _CSMI_SAS_PHY_INFO {
__u8 bNumberOfPhys;
__u8 bReserved[3];
CSMI_SAS_PHY_ENTITY Phy[32];
} CSMI_SAS_PHY_INFO,
*PCSMI_SAS_PHY_INFO;
typedef struct _CSMI_SAS_PHY_INFO_BUFFER {
COMMAND_HEADER IoctlHeader;
CSMI_SAS_PHY_INFO Information;
} CSMI_SAS_PHY_INFO_BUFFER,
*PCSMI_SAS_PHY_INFO_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: [RFC 1 of 9] patches to add diskdump functionality to block layer
From: Christoph Hellwig [mailto:[EMAIL PROTECTED] This looks like a patch for Linux 2.4. Such major changes for the 2.4 tree don't make sense anymore, especially for functionality not even in Linux 2.6. This is for 2.4, I should have specified that in the Subject line. We did this work because of customer demand and a request from a vendor. Marcelo, is this something that you be interested in adding to 2.4? If not, I'll just submit this directly to the vendor. Thanks, mikem - 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
FW: [patch 1/1] block/cciss: replace schedule_timeout() with msleep()
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 05, 2005 4:45 PM
To: Miller, Mike (OS Dev)
Cc: ISS StorageDev; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [patch 1/1] block/cciss: replace schedule_timeout()
with msleep()
I used msleep(10) here under the presumption that the
schedule_timeout(1) was written assuming that HZ=100 (as it
used to be), which is equivalent to 10 milliseconds. If the
desire is actually for 1 ms or the minimal sleep interval,
then the patch can be changed appropriately. A similar
assumption as to the constant delay value was made in the
other replacement, which can also be appropriately adjusted.
Change the delay logic in pollcomplete() to use msleep() and
time_before(). Instead of assuming schedule_timeout() will
sleep exactly as requested, use msleep(10) to guarantee
minimally 10 millisecond increments and
time_before() to guarantee stopping the loop as close to 20
seconds as possible.
Also changes another occurrence of schedule_timeout() to msleep().
TASK_INTERRUPTIBLE is used in this case, but signals are not handled.
Signed-off-by: Nishanth Aravamudan [EMAIL PROTECTED]
Acked-by: Mike Miller [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
Please consider the following patch for inclusion.
Thanks,
mikem
---
kj-domen/drivers/block/cciss.c | 17 +++--
1 files changed, 7 insertions(+), 10 deletions(-)
diff -puN drivers/block/cciss.c~msleep-drivers_block_cciss
drivers/block/cciss.c
--- kj/drivers/block/cciss.c~msleep-drivers_block_cciss
2005-03-05 16:10:44.0 +0100
+++ kj-domen/drivers/block/cciss.c 2005-03-05
16:10:44.0 +0100
@@ -1702,17 +1702,15 @@ static int cciss_revalidate(struct
gendi static unsigned long pollcomplete(int ctlr) {
unsigned long done;
- int i;
+ unsigned long end_jiffies = jiffies + 20 * HZ;
/* Wait (up to 20 seconds) for a command to complete */
-
- for (i = 20 * HZ; i 0; i--) {
+ while (time_before(jiffies,end_jiffies)) {
done = hba[ctlr]-access.command_completed(hba[ctlr]);
- if (done == FIFO_EMPTY) {
- set_current_state(TASK_UNINTERRUPTIBLE);
- schedule_timeout(1);
- } else
- return (done);
+ if (done == FIFO_EMPTY)
+ msleep(10);
+ else
+ return done;
}
/* Invalid address to tell caller we ran out of time */
return 1;
@@ -2486,8 +2484,7 @@ static int cciss_pci_init(ctlr_info_t *c
if (!(readl(c-vaddr + SA5_DOORBELL)
CFGTBL_ChangeReq))
break;
/* delay and try again */
- set_current_state(TASK_INTERRUPTIBLE);
- schedule_timeout(10);
+ msleep(100);
}
#ifdef CCISS_DEBUG
_
-
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
