[PATCH 1/1] scsi: hpsa resubmit all PCI IDs
From: Mike Miller
This patch has every ID we have in our svn repository. Some controllers were
cancelled, others added, now the cancelled ones are back. This patch made
against linux-3.13.0-rc8. Now the tables are in sync with one another.
Thanks to Tomas Henzl for pointing out the earlier problem.
Signed-off-by: Mike Miller
---
drivers/scsi/hpsa.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 348b207..614b9cb 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -91,7 +91,6 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3249},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324A},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324B},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3233},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3350},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3351},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3352},
@@ -100,6 +99,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 +108,20 @@ 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, 0x21C1},
{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", _access},
{0x3355103C, "Smart Array P220i", _access},
{0x3356103C, "Smart Array P721m", _access},
+ {0x1920103C, "Smart Array P430i", _access},
{0x1921103C, "Smart Array P830i", _access},
{0x1922103C, "Smart Array P430", _access},
{0x1923103C, "Smart Array P431", _access},
{0x1924103C, "Smart Array P830", _access},
+ {0x1925103C, "Smart Array P831", _access},
{0x1926103C, "Smart Array P731m", _access},
{0x1928103C, "Smart Array P230i", _access},
{0x1929103C, "Smart Array P530", _access},
+ {0x192A103C, "Smart Array P531", _access},
{0x21BD103C, "Smart Array", _access},
{0x21BE103C, "Smart Array", _access},
{0x21BF103C, "Smart Array", _access},
{0x21C0103C, "Smart Array", _access},
+ {0x21C1103C, "Smart Array", _access},
{0x21C2103C, "Smart Array", _access},
{0x21C3103C, "Smart Array", _access},
+ {0x21C4103C, "Smart Array", _access},
{0x21C5103C, "Smart Array", _access},
+ {0x21C6103C, "Smart Array", _access},
{0x21C7103C, "Smart Array", _access},
{0x21C8103C, "Smart Array", _access},
+ {0x21C9103C, "Smart Array", _access},
{0x21CA103C,
[PATCH 1/1] scsi: hpsa resubmit all PCI IDs
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. This patch made
against linux-3.13.0-rc8. Now the tables are in sync with one another.
Thanks to Tomas Henzl for pointing out the earlier problem.
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/scsi/hpsa.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 348b207..614b9cb 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -91,7 +91,6 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3249},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324A},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324B},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3233},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3350},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3351},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3352},
@@ -100,6 +99,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 +108,20 @@ 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, 0x21C1},
{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},
{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-kernel
[PATCH 1/1] scsi: hpsa, add all PCI ID's that HP has in svn
From: Mike Miller
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
---
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", _access},
{0x3355103C, "Smart Array P220i", _access},
{0x3356103C, "Smart Array P721m", _access},
+ {0x1920103C, "Smart Array P430i", _access},
{0x1921103C, "Smart Array P830i", _access},
{0x1922103C, "Smart Array P430", _access},
{0x1923103C, "Smart Array P431", _access},
{0x1924103C, "Smart Array P830", _access},
+ {0x1925103C, "Smart Array P831", _access},
{0x1926103C, "Smart Array P731m", _access},
{0x1928103C, "Smart Array P230i", _access},
{0x1929103C, "Smart Array P530", _access},
+ {0x192A103C, "Smart Array P531", _access},
{0x21BD103C, "Smart Array", _access},
{0x21BE103C, "Smart Array", _access},
{0x21BF103C, "Smart Array", _access},
{0x21C0103C, "Smart Array", _access},
+ {0x21C1103C, "Smart Array", _access},
{0x21C2103C, "Smart Array", _access},
{0x21C3103C, "Smart Array", _access},
+ {0x21C4103C, "Smart Array", _access},
{0x21C5103C, "Smart Array", _access},
+ {0x21C6103C, "Smart Array", _access},
{0x21C7103C, "Smart Array", _access},
{0x21C8103C, "Smart Array", _access},
+ {0x21C9103C, "Smart Array", _access},
{0x21CA103C, "Smart Array", _access},
{0x21CB103C, "Smart Array", _access},
{0x21CC103C, "Smart Array", _access},
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] scsi: hpsa, add all PCI ID's that HP has in svn
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},
{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-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] scsi: hpsa, add new PCI Ids
From: Mike Miller
This patch adds 4 more PCI ID's for HP Gen9 servers. These new ID's were
just made known this week.
Signed-off-by: Mike Miller
---
drivers/scsi/hpsa.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 20a5e6e..8a27d7b 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -120,6 +120,10 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{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, 0x21CC},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CD},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CE},
{PCI_VENDOR_ID_HP, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_RAID << 8, 0x << 8, 0},
{0,}
@@ -166,6 +170,10 @@ static struct board_type products[] = {
{0x21C7103C, "Smart Array", _access},
{0x21C8103C, "Smart Array", _access},
{0x21C9103C, "Smart Array", _access},
+ {0x21CA103C, "Smart Array", _access},
+ {0x21CC103C, "Smart Array", _access},
+ {0x21CD103C, "Smart Array", _access},
+ {0x21CE103C, "Smart Array", _access},
{0x103C, "Unknown Smart Array", _access},
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] scsi: hpsa, remove cancelled ID's and add a new one
From: Mike Miller
3 controllers have been cancelled and one new has been added. Please consider
this for inclusion.
Signed-off-by: Mike Miller
---
drivers/scsi/hpsa.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 8a27d7b..348b207 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -112,15 +112,13 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{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, 0x21C1},
{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, 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},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CD},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CE},
@@ -162,15 +160,13 @@ static struct board_type products[] = {
{0x21BE103C, "Smart Array", _access},
{0x21BF103C, "Smart Array", _access},
{0x21C0103C, "Smart Array", _access},
- {0x21C1103C, "Smart Array", _access},
{0x21C2103C, "Smart Array", _access},
{0x21C3103C, "Smart Array", _access},
- {0x21C4103C, "Smart Array", _access},
{0x21C5103C, "Smart Array", _access},
{0x21C7103C, "Smart Array", _access},
{0x21C8103C, "Smart Array", _access},
- {0x21C9103C, "Smart Array", _access},
{0x21CA103C, "Smart Array", _access},
+ {0x21CB103C, "Smart Array", _access},
{0x21CC103C, "Smart Array", _access},
{0x21CD103C, "Smart Array", _access},
{0x21CE103C, "Smart Array", _access},
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] scsi: hpsa, remove cancelled ID's and add a new one
From: Mike Miller mike.mil...@hp.com
3 controllers have been cancelled and one new has been added. Please consider
this for inclusion.
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/scsi/hpsa.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 8a27d7b..348b207 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -112,15 +112,13 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{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, 0x21C1},
{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, 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},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CD},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CE},
@@ -162,15 +160,13 @@ static struct board_type products[] = {
{0x21BE103C, Smart Array, SA5_access},
{0x21BF103C, Smart Array, SA5_access},
{0x21C0103C, Smart Array, SA5_access},
- {0x21C1103C, Smart Array, SA5_access},
{0x21C2103C, Smart Array, SA5_access},
{0x21C3103C, Smart Array, SA5_access},
- {0x21C4103C, Smart Array, SA5_access},
{0x21C5103C, 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},
{0x21CD103C, Smart Array, SA5_access},
{0x21CE103C, Smart Array, SA5_access},
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] scsi: hpsa, add new PCI Ids
From: Mike Miller mike.mil...@hp.com
This patch adds 4 more PCI ID's for HP Gen9 servers. These new ID's were
just made known this week.
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/scsi/hpsa.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 20a5e6e..8a27d7b 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -120,6 +120,10 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{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, 0x21CC},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CD},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CE},
{PCI_VENDOR_ID_HP, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_RAID 8, 0x 8, 0},
{0,}
@@ -166,6 +170,10 @@ static struct board_type products[] = {
{0x21C7103C, Smart Array, SA5_access},
{0x21C8103C, Smart Array, SA5_access},
{0x21C9103C, Smart Array, SA5_access},
+ {0x21CA103C, Smart Array, SA5_access},
+ {0x21CC103C, Smart Array, SA5_access},
+ {0x21CD103C, Smart Array, SA5_access},
+ {0x21CE103C, Smart Array, SA5_access},
{0x103C, Unknown Smart Array, SA5_access},
};
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] hpsa: bump driver version to 3.4.2-1
From: Mike Miller Bump the driver version so we can tell appoximately where it lines up with our internal svn repository. Signe-off-by: Mike Miller --- drivers/scsi/hpsa.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index 8a27d7b..4f7589d 100644 --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -54,7 +54,7 @@ #include "hpsa.h" /* HPSA_DRIVER_VERSION must be 3 byte values (0-255) separated by '.' */ -#define HPSA_DRIVER_VERSION "3.4.0-1" +#define HPSA_DRIVER_VERSION "3.4.2-5" #define DRIVER_NAME "HP HPSA Driver (v " HPSA_DRIVER_VERSION ")" #define HPSA "hpsa" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] hpsa: add 4 new PCI ID's for HP Gen9 servers
From: Mike Miller
This patch adds 4 more PCI ID's for HP Gen9 servers. These new ID's were
just made known this week.
Signed-off-by: Mike Miller
---
drivers/scsi/hpsa.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 67112a8..4af97d6 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -117,6 +117,10 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{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, 0x21CC},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CD},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CE},
{PCI_VENDOR_ID_HP, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_RAID << 8, 0x << 8, 0},
{0,}
@@ -162,6 +166,10 @@ static struct board_type products[] = {
{0x21C7103C, "Smart Array", _access},
{0x21C8103C, "Smart Array", _access},
{0x21C9103C, "Smart Array", _access},
+ {0x21CA103C, "Smart Array", _access},
+ {0x21CC103C, "Smart Array", _access},
+ {0x21CD103C, "Smart Array", _access},
+ {0x21CE103C, "Smart Array", _access},
{0x103C, "Unknown Smart Array", _access},
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] hpsa: add 4 new PCI ID's for HP Gen9 servers
From: Mike Miller mike.mil...@hp.com
This patch adds 4 more PCI ID's for HP Gen9 servers. These new ID's were
just made known this week.
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/scsi/hpsa.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 67112a8..4af97d6 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -117,6 +117,10 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{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, 0x21CC},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CD},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21CE},
{PCI_VENDOR_ID_HP, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_RAID 8, 0x 8, 0},
{0,}
@@ -162,6 +166,10 @@ static struct board_type products[] = {
{0x21C7103C, Smart Array, SA5_access},
{0x21C8103C, Smart Array, SA5_access},
{0x21C9103C, Smart Array, SA5_access},
+ {0x21CA103C, Smart Array, SA5_access},
+ {0x21CC103C, Smart Array, SA5_access},
+ {0x21CD103C, Smart Array, SA5_access},
+ {0x21CE103C, Smart Array, SA5_access},
{0x103C, Unknown Smart Array, SA5_access},
};
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] hpsa: bump driver version to 3.4.2-1
From: Mike Miller mike.mil...@hp.com Bump the driver version so we can tell appoximately where it lines up with our internal svn repository. Signe-off-by: Mike Miller mike.mil...@hp.com --- drivers/scsi/hpsa.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index 8a27d7b..4f7589d 100644 --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -54,7 +54,7 @@ #include hpsa.h /* HPSA_DRIVER_VERSION must be 3 byte values (0-255) separated by '.' */ -#define HPSA_DRIVER_VERSION 3.4.0-1 +#define HPSA_DRIVER_VERSION 3.4.2-5 #define DRIVER_NAME HP HPSA Driver (v HPSA_DRIVER_VERSION ) #define HPSA hpsa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1]scsi: hpsa remove P822se PCI ID
From: Mike Miller
Remove PCI ID for the never shipped P822se. Please consider this for
inclusion.
Signed-off-by: Mike Miller
---
drivers/scsi/hpsa.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 891c86b..d5b9d58 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -96,7 +96,6 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3351},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3352},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3353},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x334D},
{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},
@@ -144,7 +143,6 @@ static struct board_type products[] = {
{0x3351103C, "Smart Array P420", _access},
{0x3352103C, "Smart Array P421", _access},
{0x3353103C, "Smart Array P822", _access},
- {0x334D103C, "Smart Array P822se", _access},
{0x3354103C, "Smart Array P420i", _access},
{0x3355103C, "Smart Array P220i", _access},
{0x3356103C, "Smart Array P721m", _access},
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1]scsi: hpsa remove P822se PCI ID
From: Mike Miller mike.mil...@hp.com
Remove PCI ID for the never shipped P822se. Please consider this for
inclusion.
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/scsi/hpsa.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 891c86b..d5b9d58 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -96,7 +96,6 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3351},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3352},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3353},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x334D},
{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},
@@ -144,7 +143,6 @@ static struct board_type products[] = {
{0x3351103C, Smart Array P420, SA5_access},
{0x3352103C, Smart Array P421, SA5_access},
{0x3353103C, Smart Array P822, SA5_access},
- {0x334D103C, Smart Array P822se, SA5_access},
{0x3354103C, Smart Array P420i, SA5_access},
{0x3355103C, Smart Array P220i, SA5_access},
{0x3356103C, Smart Array P721m, SA5_access},
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] scsi: hpsa correct gen9 PCI IDs
From: Mike Miller
This patch deletes one ID that never should have in in hpsa. It also the PCI
ID's for two cancelled products.
Please consider this for inclusion.
Signed-off-by: Mike Miller
---
drivers/scsi/hpsa.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 891c86b..5ddf749 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -91,21 +91,18 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3249},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324A},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324B},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3233},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x334D},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3350},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3351},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3352},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3353},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x334D},
{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},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1924},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1925},
{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},
@@ -140,11 +137,11 @@ static struct board_type products[] = {
{0x3249103C, "Smart Array P812", _access},
{0x324A103C, "Smart Array P712m", _access},
{0x324B103C, "Smart Array P711m", _access},
+ {0x334D103C, "Smart Array P822se", _access},
{0x3350103C, "Smart Array P222", _access},
{0x3351103C, "Smart Array P420", _access},
{0x3352103C, "Smart Array P421", _access},
{0x3353103C, "Smart Array P822", _access},
- {0x334D103C, "Smart Array P822se", _access},
{0x3354103C, "Smart Array P420i", _access},
{0x3355103C, "Smart Array P220i", _access},
{0x3356103C, "Smart Array P721m", _access},
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] scsi: hpsa correct gen9 PCI IDs
From: Mike Miller mike.mil...@hp.com
This patch deletes one ID that never should have in in hpsa. It also the PCI
ID's for two cancelled products.
Please consider this for inclusion.
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/scsi/hpsa.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 891c86b..5ddf749 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -91,21 +91,18 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3249},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324A},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324B},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3233},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x334D},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3350},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3351},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3352},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3353},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x334D},
{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},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1924},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1925},
{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},
@@ -140,11 +137,11 @@ static struct board_type products[] = {
{0x3249103C, Smart Array P812, SA5_access},
{0x324A103C, Smart Array P712m, SA5_access},
{0x324B103C, Smart Array P711m, SA5_access},
+ {0x334D103C, Smart Array P822se, SA5_access},
{0x3350103C, Smart Array P222, SA5_access},
{0x3351103C, Smart Array P420, SA5_access},
{0x3352103C, Smart Array P421, SA5_access},
{0x3353103C, Smart Array P822, SA5_access},
- {0x334D103C, Smart Array P822se, SA5_access},
{0x3354103C, Smart Array P420i, SA5_access},
{0x3355103C, Smart Array P220i, SA5_access},
{0x3356103C, Smart Array P721m, SA5_access},
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/4] hpsa: remove unused Smart Array ID
Patch 5 of 4
From: Mike Miller
This patch removes the PCI ID of a cancelled Smart Array. I missed that in my
previous submissions. If preferred I can redo the entire patchset I submitted
last week. Please advise.
---
drivers/scsi/hpsa.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 9bf6304..479a387 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -100,7 +100,6 @@ 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},
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/4] hpsa: remove unused Smart Array ID
Patch 5 of 4
From: Mike Miller mike.mil...@hp.com
This patch removes the PCI ID of a cancelled Smart Array. I missed that in my
previous submissions. If preferred I can redo the entire patchset I submitted
last week. Please advise.
---
drivers/scsi/hpsa.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 9bf6304..479a387 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -100,7 +100,6 @@ 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},
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] hpsa: bump driver version to reflect changes
Patch 4 of 4 From: Mike Miller Changes the version of hpsa so we know something has changed. Please consider this for inclusion. Signed-off-by: Mike Miller --- drivers/scsi/hpsa.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index 5097e0c..9bf6304 100644 --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -54,7 +54,7 @@ #include "hpsa.h" /* HPSA_DRIVER_VERSION must be 3 byte values (0-255) separated by '.' */ -#define HPSA_DRIVER_VERSION "2.0.2-1" +#define HPSA_DRIVER_VERSION "3.4.0-1" #define DRIVER_NAME "HP HPSA Driver (v " HPSA_DRIVER_VERSION ")" #define HPSA "hpsa" -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] hpsa: housekeeping patch for device_id and product arrays
Patch 3 of 4
From: Mike Miller
This patch does a bit of housekeeping for hpsa. Change lowercase alpha hex
digits to uppercase for consistency within the driver. Also moves the P822se
in the tables to keep controllers of each family grouped together.
Signed-off-by: Mike Miller
---
drivers/scsi/hpsa.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index d02bdf0..5097e0c 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -89,13 +89,14 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3245},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3247},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3249},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324a},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324b},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324A},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324B},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3233},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3350},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3351},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3352},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3353},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x334D},
{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},
@@ -107,7 +108,6 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1925},
{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_CISSF, 0x103C, 0x334d},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1929},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21BD},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21BE},
@@ -138,12 +138,13 @@ static struct board_type products[] = {
{0x3245103C, "Smart Array P410i", _access},
{0x3247103C, "Smart Array P411", _access},
{0x3249103C, "Smart Array P812", _access},
- {0x324a103C, "Smart Array P712m", _access},
- {0x324b103C, "Smart Array P711m", _access},
+ {0x324A103C, "Smart Array P712m", _access},
+ {0x324B103C, "Smart Array P711m", _access},
{0x3350103C, "Smart Array P222", _access},
{0x3351103C, "Smart Array P420", _access},
{0x3352103C, "Smart Array P421", _access},
{0x3353103C, "Smart Array P822", _access},
+ {0x334D103C, "Smart Array P822se", _access},
{0x3354103C, "Smart Array P420i", _access},
{0x3355103C, "Smart Array P220i", _access},
{0x3356103C, "Smart Array P721m", _access},
@@ -154,7 +155,6 @@ static struct board_type products[] = {
{0x1926103C, "Smart Array P731m", _access},
{0x1928103C, "Smart Array P230i", _access},
{0x1929103C, "Smart Array P530", _access},
- {0x334d103C, "Smart Array P822se", _access},
{0x21BD103C, "Smart Array", _access},
{0x21BE103C, "Smart Array", _access},
{0x21BF103C, "Smart Array", _access},
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] hpsa: add HP Smart Array Gen8 names
Patch 2 of 4
From: Mike Miller
Add the marketing names for HP Smart Array Gen8 controllers. Also removes an
unused ID. Please consider this for inclusion.
Signed-off-by: Mike Miller
---
drivers/scsi/hpsa.c | 15 +++
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index ee71153..d02bdf0 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -147,14 +147,13 @@ static struct board_type products[] = {
{0x3354103C, "Smart Array P420i", _access},
{0x3355103C, "Smart Array P220i", _access},
{0x3356103C, "Smart Array P721m", _access},
- {0x1920103C, "Smart Array", _access},
- {0x1921103C, "Smart Array", _access},
- {0x1922103C, "Smart Array", _access},
- {0x1923103C, "Smart Array", _access},
- {0x1924103C, "Smart Array", _access},
- {0x1925103C, "Smart Array", _access},
- {0x1926103C, "Smart Array", _access},
- {0x1928103C, "Smart Array", _access},
+ {0x1921103C, "Smart Array P830i", _access},
+ {0x1922103C, "Smart Array P430", _access},
+ {0x1923103C, "Smart Array P431", _access},
+ {0x1924103C, "Smart Array P830", _access},
+ {0x1926103C, "Smart Array P731m", _access},
+ {0x1928103C, "Smart Array P230i", _access},
+ {0x1929103C, "Smart Array P530", _access},
{0x334d103C, "Smart Array P822se", _access},
{0x21BD103C, "Smart Array", _access},
{0x21BE103C, "Smart Array", _access},
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] hpsa: add HP Smart Array Gen9 PCI ID's
Patch 1 of 4
From: Mike Miller
This patch adds the PCI ID's for HP Smart Array Gen9 controllers. Please
consider this patch for inclusion.
Signed-off-by: Mike Miller
---
drivers/scsi/hpsa.c | 25 +
include/linux/pci_ids.h |1 +
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 7f4f790..ee71153 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -108,6 +108,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_CISSF, 0x103C, 0x334d},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1929},
+ {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, 0x21C1},
+ {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, 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_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_RAID << 8, 0x << 8, 0},
{0,}
@@ -143,6 +156,18 @@ static struct board_type products[] = {
{0x1926103C, "Smart Array", _access},
{0x1928103C, "Smart Array", _access},
{0x334d103C, "Smart Array P822se", _access},
+ {0x21BD103C, "Smart Array", _access},
+ {0x21BE103C, "Smart Array", _access},
+ {0x21BF103C, "Smart Array", _access},
+ {0x21C0103C, "Smart Array", _access},
+ {0x21C1103C, "Smart Array", _access},
+ {0x21C2103C, "Smart Array", _access},
+ {0x21C3103C, "Smart Array", _access},
+ {0x21C4103C, "Smart Array", _access},
+ {0x21C5103C, "Smart Array", _access},
+ {0x21C7103C, "Smart Array", _access},
+ {0x21C8103C, "Smart Array", _access},
+ {0x21C9103C, "Smart Array", _access},
{0x103C, "Unknown Smart Array", _access},
};
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 3bed2e8..2ce3926 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -756,6 +756,7 @@
#define PCI_DEVICE_ID_HP_CISSE 0x323a
#define PCI_DEVICE_ID_HP_CISSF 0x323b
#define PCI_DEVICE_ID_HP_CISSH 0x323c
+#define PCI_DEVICE_ID_HP_CISSI 0x3239
#define PCI_DEVICE_ID_HP_ZX2_IOC 0x4031
#define PCI_VENDOR_ID_PCTECH 0x1042
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] hpsa: add HP Smart Array Gen9 PCI ID's
Patch 1 of 4
From: Mike Miller mike.mil...@hp.com
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
---
drivers/scsi/hpsa.c | 25 +
include/linux/pci_ids.h |1 +
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 7f4f790..ee71153 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -108,6 +108,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_CISSF, 0x103C, 0x334d},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1929},
+ {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, 0x21C1},
+ {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, 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_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_RAID 8, 0x 8, 0},
{0,}
@@ -143,6 +156,18 @@ static struct board_type products[] = {
{0x1926103C, Smart Array, SA5_access},
{0x1928103C, Smart Array, SA5_access},
{0x334d103C, Smart Array P822se, 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},
+ {0x21C2103C, Smart Array, SA5_access},
+ {0x21C3103C, Smart Array, SA5_access},
+ {0x21C4103C, Smart Array, SA5_access},
+ {0x21C5103C, Smart Array, SA5_access},
+ {0x21C7103C, Smart Array, SA5_access},
+ {0x21C8103C, Smart Array, SA5_access},
+ {0x21C9103C, Smart Array, SA5_access},
{0x103C, Unknown Smart Array, SA5_access},
};
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 3bed2e8..2ce3926 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -756,6 +756,7 @@
#define PCI_DEVICE_ID_HP_CISSE 0x323a
#define PCI_DEVICE_ID_HP_CISSF 0x323b
#define PCI_DEVICE_ID_HP_CISSH 0x323c
+#define PCI_DEVICE_ID_HP_CISSI 0x3239
#define PCI_DEVICE_ID_HP_ZX2_IOC 0x4031
#define PCI_VENDOR_ID_PCTECH 0x1042
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] hpsa: add HP Smart Array Gen8 names
Patch 2 of 4
From: Mike Miller mike.mil...@hp.com
Add the marketing names for HP Smart Array Gen8 controllers. Also removes an
unused ID. Please consider this for inclusion.
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/scsi/hpsa.c | 15 +++
1 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index ee71153..d02bdf0 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -147,14 +147,13 @@ 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, SA5_access},
- {0x1921103C, Smart Array, SA5_access},
- {0x1922103C, Smart Array, SA5_access},
- {0x1923103C, Smart Array, SA5_access},
- {0x1924103C, Smart Array, SA5_access},
- {0x1925103C, Smart Array, SA5_access},
- {0x1926103C, Smart Array, SA5_access},
- {0x1928103C, Smart Array, 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},
+ {0x1926103C, Smart Array P731m, SA5_access},
+ {0x1928103C, Smart Array P230i, SA5_access},
+ {0x1929103C, Smart Array P530, SA5_access},
{0x334d103C, Smart Array P822se, SA5_access},
{0x21BD103C, Smart Array, SA5_access},
{0x21BE103C, Smart Array, SA5_access},
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] hpsa: bump driver version to reflect changes
Patch 4 of 4 From: Mike Miller mike.mil...@hp.com Changes the version of hpsa so we know something has changed. Please consider this for inclusion. Signed-off-by: Mike Miller mike.mil...@hp.com --- drivers/scsi/hpsa.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c index 5097e0c..9bf6304 100644 --- a/drivers/scsi/hpsa.c +++ b/drivers/scsi/hpsa.c @@ -54,7 +54,7 @@ #include hpsa.h /* HPSA_DRIVER_VERSION must be 3 byte values (0-255) separated by '.' */ -#define HPSA_DRIVER_VERSION 2.0.2-1 +#define HPSA_DRIVER_VERSION 3.4.0-1 #define DRIVER_NAME HP HPSA Driver (v HPSA_DRIVER_VERSION ) #define HPSA hpsa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] hpsa: housekeeping patch for device_id and product arrays
Patch 3 of 4
From: Mike Miller mike.mil...@hp.com
This patch does a bit of housekeeping for hpsa. Change lowercase alpha hex
digits to uppercase for consistency within the driver. Also moves the P822se
in the tables to keep controllers of each family grouped together.
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/scsi/hpsa.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index d02bdf0..5097e0c 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -89,13 +89,14 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3245},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3247},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3249},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324a},
- {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324b},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324A},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x324B},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSE, 0x103C, 0x3233},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3350},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3351},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3352},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x3353},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSF, 0x103C, 0x334D},
{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},
@@ -107,7 +108,6 @@ static const struct pci_device_id hpsa_pci_device_id[] = {
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1925},
{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_CISSF, 0x103C, 0x334d},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1929},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21BD},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSI, 0x103C, 0x21BE},
@@ -138,12 +138,13 @@ static struct board_type products[] = {
{0x3245103C, Smart Array P410i, SA5_access},
{0x3247103C, Smart Array P411, SA5_access},
{0x3249103C, Smart Array P812, SA5_access},
- {0x324a103C, Smart Array P712m, SA5_access},
- {0x324b103C, Smart Array P711m, SA5_access},
+ {0x324A103C, Smart Array P712m, SA5_access},
+ {0x324B103C, Smart Array P711m, SA5_access},
{0x3350103C, Smart Array P222, SA5_access},
{0x3351103C, Smart Array P420, SA5_access},
{0x3352103C, Smart Array P421, SA5_access},
{0x3353103C, Smart Array P822, SA5_access},
+ {0x334D103C, Smart Array P822se, SA5_access},
{0x3354103C, Smart Array P420i, SA5_access},
{0x3355103C, Smart Array P220i, SA5_access},
{0x3356103C, Smart Array P721m, SA5_access},
@@ -154,7 +155,6 @@ static struct board_type products[] = {
{0x1926103C, Smart Array P731m, SA5_access},
{0x1928103C, Smart Array P230i, SA5_access},
{0x1929103C, Smart Array P530, SA5_access},
- {0x334d103C, Smart Array P822se, SA5_access},
{0x21BD103C, Smart Array, SA5_access},
{0x21BE103C, Smart Array, SA5_access},
{0x21BF103C, Smart Array, SA5_access},
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cciss: set max scatter gather entries to 32 on P600
Patch 1/1 From: Mike Miller 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 Signed-off-by: Dwight (Bud) Brown Signed-off-by: Tomas Henzl Acked-by: Stephen M. Cameron --- drivers/block/cciss.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index 62b6c2c..d2d95ff 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -4258,6 +4258,13 @@ static void cciss_find_board_params(ctlr_info_t *h) h->nr_cmds = h->max_commands - 4 - cciss_tape_cmds; h->maxsgentries = readl(&(h->cfgtable->MaxSGElements)); /* +* The P600 may exhibit poor performnace under some workloads +* if we use the value in the configuration table. Limit this +* controller to MAXSGENTRIES (32) instead. +*/ + if (h->board_id == 0x3225103C) + h->maxsgentries = MAXSGENTRIES; + /* * Limit in-command s/g elements to 32 save dma'able memory. * Howvever spec says if 0, use 31 */ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cciss: set max scatter gather entries to 32 on P600
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 --- drivers/block/cciss.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index 62b6c2c..d2d95ff 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -4258,6 +4258,13 @@ static void cciss_find_board_params(ctlr_info_t *h) h-nr_cmds = h-max_commands - 4 - cciss_tape_cmds; h-maxsgentries = readl((h-cfgtable-MaxSGElements)); /* +* The P600 may exhibit poor performnace under some workloads +* if we use the value in the configuration table. Limit this +* controller to MAXSGENTRIES (32) instead. +*/ + if (h-board_id == 0x3225103C) + h-maxsgentries = MAXSGENTRIES; + /* * Limit in-command s/g elements to 32 save dma'able memory. * Howvever spec says if 0, use 31 */ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RESEND] Silence noisy per-device cciss messages
On Fri, 2013-06-07 at 14:16 +0100, Bryn M. Reeves wrote: > Currently cciss logs a message each time cciss_read_capacity_16 is called: > > kernel: cciss :03:00.0: blocks= 5274326576 block_size= 512 > > This generates considerable log noise. An identical message was deleted > from cciss_read_capacity in 2009. > > This patch mirrors the change made to cciss_read_capacity in commit > 98c. Emitting device and block size information at KERN_INFO on > each read_capacity() leads to a lot of log noise. > > Signed-off-by: Bryn M. Reeves Acked-by: Mike Miller -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][RESEND] Silence noisy per-device cciss messages
On Fri, 2013-06-07 at 14:16 +0100, Bryn M. Reeves wrote: Currently cciss logs a message each time cciss_read_capacity_16 is called: kernel: cciss :03:00.0: blocks= 5274326576 block_size= 512 This generates considerable log noise. An identical message was deleted from cciss_read_capacity in 2009. This patch mirrors the change made to cciss_read_capacity in commit 98c. Emitting device and block size information at KERN_INFO on each read_capacity() leads to a lot of log noise. Signed-off-by: Bryn M. Reeves b...@redhat.com Acked-by: Mike Miller mike.mil...@hp.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] cciss: bug fix to prevent cciss from loading in kdump crash kernel
On Fri, 2013-05-03 at 11:02 -0700, James Bottomley wrote:
> On Tue, 2013-04-23 at 12:25 -0500, Mike Miller wrote:
> > PATCH 1/1
> >
> > By default the cciss driver supports all "older" HP Smart Array controllers
> > and hpsa supports all controllers starting with the G6 family. There are
> > module parameters that allow a user to override those defaults and use hpsa
> > for any HP Smart Array controller.
> > If the user does override the default behavior and uses hpsa for older
> > controllers it is possible that cciss may try to load in a kdump crash
> > kernel. This may happen if cciss is loaded first from the kdump initrd
> > image. If cciss does load rather than hpsa and reset_devices is true we
> > immediately call cciss_hard_reset_controller. This will result in a kernel
> > panic and the core file cannot be created.
> > This patch prevents cciss from trying to load in this scenario.
> >
> > Tested with 3.9.0-rc7.
> >
> > From: Mike
> > Signed-off-by: Mike Miller
> >
> > ---
> > drivers/block/cciss.c | 10 ++
> > 1 files changed, 10 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
> > index 1c1b8e5..06c8dba 100644
> > --- a/drivers/block/cciss.c
> > +++ b/drivers/block/cciss.c
> > @@ -4960,6 +4960,16 @@ static int cciss_init_one(struct pci_dev *pdev,
> > const struct pci_device_id *ent)
> > ctlr_info_t *h;
> > unsigned long flags;
> >
> > + /*
> > +* By default the cciss driver is used for all older HP Smart Array
> > +* controllers. There are module paramaters that allow a user to
> > +* override this behavior and instead use the hpsa SCSI driver. If
> > +* this is the case cciss may be loaded first from the kdump initrd
> > +* image and cause a kernel panic. So if reset_devices is true and
> > +* cciss_allow_hpsa is set just bail.
> > +*/
> > + if ((reset_devices) && (cciss_allow_hpsa == 1))
> > + return -ENODEV;
> > rc = cciss_init_reset_devices(pdev);
> > if (rc) {
> > if (rc != -ENOTSUPP)
>
> Sigh, right change log, incomplete bug fix.
>
> Can we all agree that this is the right one?
>
> James
I submitted 2 patches. Below the 2 are combined and make the fix
complete.
-- mikem
>
> ---
> >From 746ba9f715b9037264ae0b8175c6286f5f8f62d4 Mon Sep 17 00:00:00 2001
> From: Mike Miller
> Date: Thu, 18 Apr 2013 13:49:37 -0500
> Subject: [PATCH] [SCSI] cciss: bug fix to prevent cciss from loading in kdump
> crash kernel
>
> By default the cciss driver supports all "older" HP Smart Array controllers
> and hpsa supports all controllers starting with the G6 family. There are
> module parameters that allow a user to override those defaults and use hpsa
> for any HP Smart Array controller.
> If the user does override the default behavior and uses hpsa for older
> controllers it is possible that cciss may try to load in a kdump crash
> kernel. This may happen if cciss is loaded first from the kdump initrd
> image. If cciss does load rather than hpsa and reset_devices is true we
> immediately call cciss_hard_reset_controller. This will result in a kernel
> panic and the core file cannot be created.
> This patch prevents cciss from trying to load in this scenario.
>
> Signed-off-by: Mike Miller
> Cc:
> Signed-off-by: James Bottomley
>
> diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
> index 1c1b8e5..daaab88 100644
> --- a/drivers/block/cciss.c
> +++ b/drivers/block/cciss.c
> @@ -75,6 +75,12 @@ module_param(cciss_simple_mode, int, S_IRUGO|S_IWUSR);
> MODULE_PARM_DESC(cciss_simple_mode,
> "Use 'simple mode' rather than 'performant mode'");
>
> +static int cciss_allow_hpsa;
> +module_param(cciss_allow_hpsa, int, S_IRUGO|S_IWUSR);
> +MODULE_PARM_DESC(cciss_allow_hpsa,
> + "Prevent cciss driver from accessing hardware known to be "
> + " supported by the hpsa driver");
> +
> static DEFINE_MUTEX(cciss_mutex);
> static struct proc_dir_entry *proc_cciss;
>
> @@ -4960,6 +4966,16 @@ static int cciss_init_one(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> ctlr_info_t *h;
> unsigned long flags;
>
> + /*
> + * By default the cciss driver is used for all older HP Smart Array
> + * controllers. There are module paramaters that allow a user to
> + * override this behavior and instead use the hpsa SCSI driver. If
> + * this is the case cciss may be loaded first from the kdump initrd
> + * image
Re: [PATCH 1/1] cciss: bug fix to prevent cciss from loading in kdump crash kernel
On Fri, 2013-05-03 at 11:02 -0700, James Bottomley wrote:
On Tue, 2013-04-23 at 12:25 -0500, Mike Miller wrote:
PATCH 1/1
By default the cciss driver supports all older HP Smart Array controllers
and hpsa supports all controllers starting with the G6 family. There are
module parameters that allow a user to override those defaults and use hpsa
for any HP Smart Array controller.
If the user does override the default behavior and uses hpsa for older
controllers it is possible that cciss may try to load in a kdump crash
kernel. This may happen if cciss is loaded first from the kdump initrd
image. If cciss does load rather than hpsa and reset_devices is true we
immediately call cciss_hard_reset_controller. This will result in a kernel
panic and the core file cannot be created.
This patch prevents cciss from trying to load in this scenario.
Tested with 3.9.0-rc7.
From: Mike mike.mil...@hp.com
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/block/cciss.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 1c1b8e5..06c8dba 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -4960,6 +4960,16 @@ static int cciss_init_one(struct pci_dev *pdev,
const struct pci_device_id *ent)
ctlr_info_t *h;
unsigned long flags;
+ /*
+* By default the cciss driver is used for all older HP Smart Array
+* controllers. There are module paramaters that allow a user to
+* override this behavior and instead use the hpsa SCSI driver. If
+* this is the case cciss may be loaded first from the kdump initrd
+* image and cause a kernel panic. So if reset_devices is true and
+* cciss_allow_hpsa is set just bail.
+*/
+ if ((reset_devices) (cciss_allow_hpsa == 1))
+ return -ENODEV;
rc = cciss_init_reset_devices(pdev);
if (rc) {
if (rc != -ENOTSUPP)
Sigh, right change log, incomplete bug fix.
Can we all agree that this is the right one?
James
I submitted 2 patches. Below the 2 are combined and make the fix
complete.
-- mikem
---
From 746ba9f715b9037264ae0b8175c6286f5f8f62d4 Mon Sep 17 00:00:00 2001
From: Mike Miller mike.mil...@hp.com
Date: Thu, 18 Apr 2013 13:49:37 -0500
Subject: [PATCH] [SCSI] cciss: bug fix to prevent cciss from loading in kdump
crash kernel
By default the cciss driver supports all older HP Smart Array controllers
and hpsa supports all controllers starting with the G6 family. There are
module parameters that allow a user to override those defaults and use hpsa
for any HP Smart Array controller.
If the user does override the default behavior and uses hpsa for older
controllers it is possible that cciss may try to load in a kdump crash
kernel. This may happen if cciss is loaded first from the kdump initrd
image. If cciss does load rather than hpsa and reset_devices is true we
immediately call cciss_hard_reset_controller. This will result in a kernel
panic and the core file cannot be created.
This patch prevents cciss from trying to load in this scenario.
Signed-off-by: Mike Miller mike.mil...@hp.com
Cc: sta...@vger.kernel.org
Signed-off-by: James Bottomley jbottom...@parallels.com
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 1c1b8e5..daaab88 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -75,6 +75,12 @@ module_param(cciss_simple_mode, int, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(cciss_simple_mode,
Use 'simple mode' rather than 'performant mode');
+static int cciss_allow_hpsa;
+module_param(cciss_allow_hpsa, int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(cciss_allow_hpsa,
+ Prevent cciss driver from accessing hardware known to be
+ supported by the hpsa driver);
+
static DEFINE_MUTEX(cciss_mutex);
static struct proc_dir_entry *proc_cciss;
@@ -4960,6 +4966,16 @@ static int cciss_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
ctlr_info_t *h;
unsigned long flags;
+ /*
+ * By default the cciss driver is used for all older HP Smart Array
+ * controllers. There are module paramaters that allow a user to
+ * override this behavior and instead use the hpsa SCSI driver. If
+ * this is the case cciss may be loaded first from the kdump initrd
+ * image and cause a kernel panic. So if reset_devices is true and
+ * cciss_allow_hpsa is set just bail.
+ */
+ if ((reset_devices) (cciss_allow_hpsa == 1))
+ return -ENODEV;
rc = cciss_init_reset_devices(pdev);
if (rc) {
if (rc != -ENOTSUPP)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cciss: bug fix to prevent cciss from loading in kdump crash kernel
PATCH 1/1
By default the cciss driver supports all "older" HP Smart Array controllers
and hpsa supports all controllers starting with the G6 family. There are
module parameters that allow a user to override those defaults and use hpsa
for any HP Smart Array controller.
If the user does override the default behavior and uses hpsa for older
controllers it is possible that cciss may try to load in a kdump crash
kernel. This may happen if cciss is loaded first from the kdump initrd
image. If cciss does load rather than hpsa and reset_devices is true we
immediately call cciss_hard_reset_controller. This will result in a kernel
panic and the core file cannot be created.
This patch prevents cciss from trying to load in this scenario.
Tested with 3.9.0-rc7.
From: Mike
Signed-off-by: Mike Miller
---
drivers/block/cciss.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 1c1b8e5..06c8dba 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -4960,6 +4960,16 @@ static int cciss_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
ctlr_info_t *h;
unsigned long flags;
+ /*
+* By default the cciss driver is used for all older HP Smart Array
+* controllers. There are module paramaters that allow a user to
+* override this behavior and instead use the hpsa SCSI driver. If
+* this is the case cciss may be loaded first from the kdump initrd
+* image and cause a kernel panic. So if reset_devices is true and
+* cciss_allow_hpsa is set just bail.
+*/
+ if ((reset_devices) && (cciss_allow_hpsa == 1))
+ return -ENODEV;
rc = cciss_init_reset_devices(pdev);
if (rc) {
if (rc != -ENOTSUPP)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cciss: bug fix to prevent cciss from loading in kdump crash kernel
PATCH 1/1
By default the cciss driver supports all older HP Smart Array controllers
and hpsa supports all controllers starting with the G6 family. There are
module parameters that allow a user to override those defaults and use hpsa
for any HP Smart Array controller.
If the user does override the default behavior and uses hpsa for older
controllers it is possible that cciss may try to load in a kdump crash
kernel. This may happen if cciss is loaded first from the kdump initrd
image. If cciss does load rather than hpsa and reset_devices is true we
immediately call cciss_hard_reset_controller. This will result in a kernel
panic and the core file cannot be created.
This patch prevents cciss from trying to load in this scenario.
Tested with 3.9.0-rc7.
From: Mike mike.mil...@hp.com
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/block/cciss.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 1c1b8e5..06c8dba 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -4960,6 +4960,16 @@ static int cciss_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
ctlr_info_t *h;
unsigned long flags;
+ /*
+* By default the cciss driver is used for all older HP Smart Array
+* controllers. There are module paramaters that allow a user to
+* override this behavior and instead use the hpsa SCSI driver. If
+* this is the case cciss may be loaded first from the kdump initrd
+* image and cause a kernel panic. So if reset_devices is true and
+* cciss_allow_hpsa is set just bail.
+*/
+ if ((reset_devices) (cciss_allow_hpsa == 1))
+ return -ENODEV;
rc = cciss_init_reset_devices(pdev);
if (rc) {
if (rc != -ENOTSUPP)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cciss: add cciss_allow_hpsa module parameter
Add the cciss_allow_hpsa modules parameter. This allows users to use the hpsa
driver instead of cciss for older controllers.
Tested with 3.9.0-rc7 in combination with the bug fix submitted Tuesday. My
apologies for not testing that patch with the correct kernel.
From: Mike
Signed-off-by: Mike Miller
---
drivers/block/cciss.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index a6c0973..081d1a8 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -75,6 +75,12 @@ module_param(cciss_simple_mode, int, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(cciss_simple_mode,
"Use 'simple mode' rather than 'performant mode'");
+static int cciss_allow_hpsa;
+module_param(cciss_allow_hpsa, int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(cciss_allow_hpsa,
+ "Prevent cciss driver from accessing hardware known to be "
+ " supported by the hpsa driver");
+
static DEFINE_MUTEX(cciss_mutex);
static struct proc_dir_entry *proc_cciss;
@@ -4116,9 +4122,13 @@ static int cciss_lookup_board_id(struct pci_dev *pdev,
u32 *board_id)
*board_id = ((subsystem_device_id << 16) & 0x) |
subsystem_vendor_id;
- for (i = 0; i < ARRAY_SIZE(products); i++)
+ for (i = 0; i < ARRAY_SIZE(products); i++) {
+ /* Stand aside for hpsa driver on request */
+ if (cciss_allow_hpsa)
+ return -ENODEV;
if (*board_id == products[i].board_id)
return i;
+ }
dev_warn(>dev, "unrecognized board ID: 0x%08x, ignoring.\n",
*board_id);
return -ENODEV;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/1] cciss: bug fix, prevent cciss from loading in kdump kernel
On Wed, 2013-04-17 at 15:02 -0700, Andrew Morton wrote: > On Mon, 15 Apr 2013 12:59:06 -0500 Mike Miller wrote: > > > Patch 1/1 > > > > If hpsa is selected as the Smart Array driver cciss may try to load in the > > kdump kernel. When this happens kdump fails and a core file cannot be > > created. > > This patch prevents cciss from trying to load in this scenario. This effects > > primarily older Smart Array controllers. > > > > ... > > > > --- a/drivers/block/cciss.c > > +++ b/drivers/block/cciss.c > > @@ -4960,6 +4960,12 @@ static int cciss_init_one(struct pci_dev *pdev, > > const struct pci_device_id *ent) > > ctlr_info_t *h; > > unsigned long flags; > > > > + /* > > +* if this is the kdump kernel and the user has set the flags to > > +* use hpsa rather than cciss just bail > > +*/ > > + if ((reset_devices) && (cciss_allow_hpsa == 1)) > > + return -ENODEV; > > OK, wazzup. That's the only occurrence of the symbol > "cciss_allow_hpsa" in Linux and needless to say, the compiler laughed > at me. Argh. Sorry about that. I could have sworn I tested that on rc7. I'll have another patch ready in a bit to add the flag. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/1] cciss: bug fix, prevent cciss from loading in kdump kernel
On Tue, 2013-04-16 at 15:00 -0700, Andrew Morton wrote: > On Mon, 15 Apr 2013 12:59:06 -0500 Mike Miller wrote: > > > Patch 1/1 > > > > If hpsa is selected as the Smart Array driver cciss may try to load in the > > kdump kernel. When this happens kdump fails and a core file cannot be > > created. > > This patch prevents cciss from trying to load in this scenario. This effects > > primarily older Smart Array controllers. > > > > OK, this is weird. kdump and scsi drivers are pretty darn remote things > and I've never heard of such an interaction. Can you tell us a bit more > about how and why this happened? Is there something special about > cciss, or can we expect similar kdump interactions with other device drivers? I thought it was weird, too. I've never seen this happen before and it was very hard to duplicate this in the lab. I think the reason it did happen was twofold. The cciss driver was being loaded first from the kdump initramfs image and the driver load sequence is now different than it used to be. We used to call cciss_pci_init as one the first things we did from our probe function, cciss_init_one. Now if reset_devices is true we immediately call into cciss_hard_reset controller and we do not check to see if cciss_allow_hpsa is set. Sorry, that's the best explanation I have. Offhand, I don't know of any of any other hardware devices that have 2 distinctly different drivers, one block and one scsi. So I don't _think_ this would happen with other drivers/devices. -- mikem > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/1] cciss: bug fix, prevent cciss from loading in kdump kernel
On Tue, 2013-04-16 at 15:00 -0700, Andrew Morton wrote: On Mon, 15 Apr 2013 12:59:06 -0500 Mike Miller mike.mil...@hp.com wrote: Patch 1/1 If hpsa is selected as the Smart Array driver cciss may try to load in the kdump kernel. When this happens kdump fails and a core file cannot be created. This patch prevents cciss from trying to load in this scenario. This effects primarily older Smart Array controllers. OK, this is weird. kdump and scsi drivers are pretty darn remote things and I've never heard of such an interaction. Can you tell us a bit more about how and why this happened? Is there something special about cciss, or can we expect similar kdump interactions with other device drivers? I thought it was weird, too. I've never seen this happen before and it was very hard to duplicate this in the lab. I think the reason it did happen was twofold. The cciss driver was being loaded first from the kdump initramfs image and the driver load sequence is now different than it used to be. We used to call cciss_pci_init as one the first things we did from our probe function, cciss_init_one. Now if reset_devices is true we immediately call into cciss_hard_reset controller and we do not check to see if cciss_allow_hpsa is set. Sorry, that's the best explanation I have. Offhand, I don't know of any of any other hardware devices that have 2 distinctly different drivers, one block and one scsi. So I don't _think_ this would happen with other drivers/devices. -- mikem -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/1] cciss: bug fix, prevent cciss from loading in kdump kernel
On Wed, 2013-04-17 at 15:02 -0700, Andrew Morton wrote: On Mon, 15 Apr 2013 12:59:06 -0500 Mike Miller mike.mil...@hp.com wrote: Patch 1/1 If hpsa is selected as the Smart Array driver cciss may try to load in the kdump kernel. When this happens kdump fails and a core file cannot be created. This patch prevents cciss from trying to load in this scenario. This effects primarily older Smart Array controllers. ... --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -4960,6 +4960,12 @@ static int cciss_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) ctlr_info_t *h; unsigned long flags; + /* +* if this is the kdump kernel and the user has set the flags to +* use hpsa rather than cciss just bail +*/ + if ((reset_devices) (cciss_allow_hpsa == 1)) + return -ENODEV; OK, wazzup. That's the only occurrence of the symbol cciss_allow_hpsa in Linux and needless to say, the compiler laughed at me. Argh. Sorry about that. I could have sworn I tested that on rc7. I'll have another patch ready in a bit to add the flag. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cciss: add cciss_allow_hpsa module parameter
Add the cciss_allow_hpsa modules parameter. This allows users to use the hpsa
driver instead of cciss for older controllers.
Tested with 3.9.0-rc7 in combination with the bug fix submitted Tuesday. My
apologies for not testing that patch with the correct kernel.
From: Mike mike.mil...@hp.com
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/block/cciss.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index a6c0973..081d1a8 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -75,6 +75,12 @@ module_param(cciss_simple_mode, int, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(cciss_simple_mode,
Use 'simple mode' rather than 'performant mode');
+static int cciss_allow_hpsa;
+module_param(cciss_allow_hpsa, int, S_IRUGO|S_IWUSR);
+MODULE_PARM_DESC(cciss_allow_hpsa,
+ Prevent cciss driver from accessing hardware known to be
+supported by the hpsa driver);
+
static DEFINE_MUTEX(cciss_mutex);
static struct proc_dir_entry *proc_cciss;
@@ -4116,9 +4122,13 @@ static int cciss_lookup_board_id(struct pci_dev *pdev,
u32 *board_id)
*board_id = ((subsystem_device_id 16) 0x) |
subsystem_vendor_id;
- for (i = 0; i ARRAY_SIZE(products); i++)
+ for (i = 0; i ARRAY_SIZE(products); i++) {
+ /* Stand aside for hpsa driver on request */
+ if (cciss_allow_hpsa)
+ return -ENODEV;
if (*board_id == products[i].board_id)
return i;
+ }
dev_warn(pdev-dev, unrecognized board ID: 0x%08x, ignoring.\n,
*board_id);
return -ENODEV;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch 1/1] cciss: bug fix, prevent cciss from loading in kdump kernel
Patch 1/1
If hpsa is selected as the Smart Array driver cciss may try to load in the
kdump kernel. When this happens kdump fails and a core file cannot be created.
This patch prevents cciss from trying to load in this scenario. This effects
primarily older Smart Array controllers.
From: Mike Miller
Signed-off-by: Mike Miller
---
drivers/block/cciss.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 1c1b8e5..a6c0973 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -4960,6 +4960,12 @@ static int cciss_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
ctlr_info_t *h;
unsigned long flags;
+ /*
+* if this is the kdump kernel and the user has set the flags to
+* use hpsa rather than cciss just bail
+*/
+ if ((reset_devices) && (cciss_allow_hpsa == 1))
+ return -ENODEV;
rc = cciss_init_reset_devices(pdev);
if (rc) {
if (rc != -ENOTSUPP)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch 1/1] cciss: bug fix, prevent cciss from loading in kdump kernel
Patch 1/1
If hpsa is selected as the Smart Array driver cciss may try to load in the
kdump kernel. When this happens kdump fails and a core file cannot be created.
This patch prevents cciss from trying to load in this scenario. This effects
primarily older Smart Array controllers.
From: Mike Miller mike.mil...@hp.com
Signed-off-by: Mike Miller mike.mil...@hp.com
---
drivers/block/cciss.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 1c1b8e5..a6c0973 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -4960,6 +4960,12 @@ static int cciss_init_one(struct pci_dev *pdev, const
struct pci_device_id *ent)
ctlr_info_t *h;
unsigned long flags;
+ /*
+* if this is the kdump kernel and the user has set the flags to
+* use hpsa rather than cciss just bail
+*/
+ if ((reset_devices) (cciss_allow_hpsa == 1))
+ return -ENODEV;
rc = cciss_init_reset_devices(pdev);
if (rc) {
if (rc != -ENOTSUPP)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] hpsa: Smart Array Gen8 marketing names
hpsa: add marketing names for Gen8 controllers
From: Mike Miller
Now that the controllers have announced I can add the marketing names for
the Proliant Gen8 server controllers.
---
drivers/scsi/hpsa.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index edc598b..41fc5b0 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -127,13 +127,13 @@ static struct board_type products[] = {
{0x3249103C, "Smart Array P812", _access},
{0x324a103C, "Smart Array P712m", _access},
{0x324b103C, "Smart Array P711m", _access},
- {0x3350103C, "Smart Array", _access},
- {0x3351103C, "Smart Array", _access},
- {0x3352103C, "Smart Array", _access},
- {0x3353103C, "Smart Array", _access},
- {0x3354103C, "Smart Array", _access},
- {0x3355103C, "Smart Array", _access},
- {0x3356103C, "Smart Array", _access},
+ {0x3350103C, "Smart Array P222", _access},
+ {0x3351103C, "Smart Array P420", _access},
+ {0x3352103C, "Smart Array P421", _access},
+ {0x3353103C, "Smart Array P822", _access},
+ {0x3354103C, "Smart Array P420i", _access},
+ {0x3355103C, "Smart Array P220i", _access},
+ {0x3356103C, "Smart Array P721m", _access},
{0x1920103C, "Smart Array", _access},
{0x1921103C, "Smart Array", _access},
{0x1922103C, "Smart Array", _access},
@@ -142,7 +142,7 @@ static struct board_type products[] = {
{0x1925103C, "Smart Array", _access},
{0x1926103C, "Smart Array", _access},
{0x1928103C, "Smart Array", _access},
- {0x334d103C, "Smart Array", _access},
+ {0x334d103C, "Smart Array P822se", _access},
{0x103C, "Unknown Smart Array", _access},
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] hpsa: gen8plus Smart Array IDs
hpsa: add PCI ID's for next gen Smart Array
From: Mike Miller
No marketing names yet available for the next generation of Smart Array.
---
drivers/scsi/hpsa.c | 18 ++
include/linux/pci_ids.h |1 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 796482b..edc598b 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -99,6 +99,15 @@ 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},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1924},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1925},
+ {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_CISSF, 0x103C, 0x334d},
{PCI_VENDOR_ID_HP, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_RAID << 8, 0x << 8, 0},
{0,}
@@ -125,6 +134,15 @@ static struct board_type products[] = {
{0x3354103C, "Smart Array", _access},
{0x3355103C, "Smart Array", _access},
{0x3356103C, "Smart Array", _access},
+ {0x1920103C, "Smart Array", _access},
+ {0x1921103C, "Smart Array", _access},
+ {0x1922103C, "Smart Array", _access},
+ {0x1923103C, "Smart Array", _access},
+ {0x1924103C, "Smart Array", _access},
+ {0x1925103C, "Smart Array", _access},
+ {0x1926103C, "Smart Array", _access},
+ {0x1928103C, "Smart Array", _access},
+ {0x334d103C, "Smart Array", _access},
{0x103C, "Unknown Smart Array", _access},
};
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6b4565c..416db39 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -753,6 +753,7 @@
#define PCI_DEVICE_ID_HP_CISSD 0x3238
#define PCI_DEVICE_ID_HP_CISSE 0x323a
#define PCI_DEVICE_ID_HP_CISSF 0x323b
+#define PCI_DEVICE_ID_HP_CISSH 0x323c
#define PCI_DEVICE_ID_HP_ZX2_IOC 0x4031
#define PCI_VENDOR_ID_PCTECH 0x1042
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] hpsa: gen8plus Smart Array IDs
hpsa: add PCI ID's for next gen Smart Array
From: Mike Miller mike.mil...@hp.com
No marketing names yet available for the next generation of Smart Array.
---
drivers/scsi/hpsa.c | 18 ++
include/linux/pci_ids.h |1 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 796482b..edc598b 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -99,6 +99,15 @@ 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},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1924},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSH, 0x103C, 0x1925},
+ {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_CISSF, 0x103C, 0x334d},
{PCI_VENDOR_ID_HP, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_RAID 8, 0x 8, 0},
{0,}
@@ -125,6 +134,15 @@ static struct board_type products[] = {
{0x3354103C, Smart Array, SA5_access},
{0x3355103C, Smart Array, SA5_access},
{0x3356103C, Smart Array, SA5_access},
+ {0x1920103C, Smart Array, SA5_access},
+ {0x1921103C, Smart Array, SA5_access},
+ {0x1922103C, Smart Array, SA5_access},
+ {0x1923103C, Smart Array, SA5_access},
+ {0x1924103C, Smart Array, SA5_access},
+ {0x1925103C, Smart Array, SA5_access},
+ {0x1926103C, Smart Array, SA5_access},
+ {0x1928103C, Smart Array, SA5_access},
+ {0x334d103C, Smart Array, SA5_access},
{0x103C, Unknown Smart Array, SA5_access},
};
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 6b4565c..416db39 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -753,6 +753,7 @@
#define PCI_DEVICE_ID_HP_CISSD 0x3238
#define PCI_DEVICE_ID_HP_CISSE 0x323a
#define PCI_DEVICE_ID_HP_CISSF 0x323b
+#define PCI_DEVICE_ID_HP_CISSH 0x323c
#define PCI_DEVICE_ID_HP_ZX2_IOC 0x4031
#define PCI_VENDOR_ID_PCTECH 0x1042
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] hpsa: Smart Array Gen8 marketing names
hpsa: add marketing names for Gen8 controllers
From: Mike Miller mike.mil...@hp.com
Now that the controllers have announced I can add the marketing names for
the Proliant Gen8 server controllers.
---
drivers/scsi/hpsa.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index edc598b..41fc5b0 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -127,13 +127,13 @@ static struct board_type products[] = {
{0x3249103C, Smart Array P812, SA5_access},
{0x324a103C, Smart Array P712m, SA5_access},
{0x324b103C, Smart Array P711m, SA5_access},
- {0x3350103C, Smart Array, SA5_access},
- {0x3351103C, Smart Array, SA5_access},
- {0x3352103C, Smart Array, SA5_access},
- {0x3353103C, Smart Array, SA5_access},
- {0x3354103C, Smart Array, SA5_access},
- {0x3355103C, Smart Array, SA5_access},
- {0x3356103C, Smart Array, SA5_access},
+ {0x3350103C, Smart Array P222, SA5_access},
+ {0x3351103C, Smart Array P420, SA5_access},
+ {0x3352103C, Smart Array P421, SA5_access},
+ {0x3353103C, Smart Array P822, SA5_access},
+ {0x3354103C, Smart Array P420i, SA5_access},
+ {0x3355103C, Smart Array P220i, SA5_access},
+ {0x3356103C, Smart Array P721m, SA5_access},
{0x1920103C, Smart Array, SA5_access},
{0x1921103C, Smart Array, SA5_access},
{0x1922103C, Smart Array, SA5_access},
@@ -142,7 +142,7 @@ static struct board_type products[] = {
{0x1925103C, Smart Array, SA5_access},
{0x1926103C, Smart Array, SA5_access},
{0x1928103C, Smart Array, SA5_access},
- {0x334d103C, Smart Array, SA5_access},
+ {0x334d103C, Smart Array P822se, SA5_access},
{0x103C, Unknown Smart Array, SA5_access},
};
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cciss: remove READ_AHEAD define and use block layer defaults
PATCH 1/1
This patch removes the #define READ_AHEAD 1024 from the driver and uses the
block layer defaults, instead. We have found that under certain workloads
the setting can cause a disk connected to the e200 controller to go offline.
If the disk hiccups the link may try to downshift but the controller is
never notified that the link successfully completed the renegotiation.
We've also found that performance using the block layer default of 32 pages
was on par with the 1024 setting. We tried setting it to zero at one time
based on info from our firmware guys but that killed performance. Turns out
we were talking about 2 different read ahead settings.
Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 9715be3..2f6cc3b 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -131,7 +131,6 @@ static struct board_type products[] = {
/*define how many times we will try a command because of bus resets */
#define MAX_CMD_RETRIES 3
-#define READ_AHEAD 1024
#define MAX_CTLR 32
/* Originally cciss driver only supports 8 major numbers */
@@ -1341,7 +1340,6 @@ geo_inq:
disk->private_data = >drv[drv_index];
/* Set up queue information */
- disk->queue->backing_dev_info.ra_pages = READ_AHEAD;
blk_queue_bounce_limit(disk->queue, hba[ctlr]->pdev->dma_mask);
/* This is a hardware imposed limit. */
@@ -3434,7 +3432,6 @@ static int __devinit cciss_init_one(struct pci_dev *pdev,
}
drv->queue = q;
- q->backing_dev_info.ra_pages = READ_AHEAD;
blk_queue_bounce_limit(q, hba[i]->pdev->dma_mask);
/* This is a hardware imposed limit. */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cciss: remove READ_AHEAD define and use block layer defaults
PATCH 1/1
This patch removes the #define READ_AHEAD 1024 from the driver and uses the
block layer defaults, instead. We have found that under certain workloads
the setting can cause a disk connected to the e200 controller to go offline.
If the disk hiccups the link may try to downshift but the controller is
never notified that the link successfully completed the renegotiation.
We've also found that performance using the block layer default of 32 pages
was on par with the 1024 setting. We tried setting it to zero at one time
based on info from our firmware guys but that killed performance. Turns out
we were talking about 2 different read ahead settings.
Please consider this for inclusion.
Signed-off-by: Mike Miller [EMAIL PROTECTED]
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 9715be3..2f6cc3b 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -131,7 +131,6 @@ static struct board_type products[] = {
/*define how many times we will try a command because of bus resets */
#define MAX_CMD_RETRIES 3
-#define READ_AHEAD 1024
#define MAX_CTLR 32
/* Originally cciss driver only supports 8 major numbers */
@@ -1341,7 +1340,6 @@ geo_inq:
disk-private_data = h-drv[drv_index];
/* Set up queue information */
- disk-queue-backing_dev_info.ra_pages = READ_AHEAD;
blk_queue_bounce_limit(disk-queue, hba[ctlr]-pdev-dma_mask);
/* This is a hardware imposed limit. */
@@ -3434,7 +3432,6 @@ static int __devinit cciss_init_one(struct pci_dev *pdev,
}
drv-queue = q;
- q-backing_dev_info.ra_pages = READ_AHEAD;
blk_queue_bounce_limit(q, hba[i]-pdev-dma_mask);
/* This is a hardware imposed limit. */
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] resubmit: cciss: procfs updates to display info about many volumes
Patch 1 of 1
This patch hopefully fixes all the brokeness in my last submission. It
compiles cleanly with tape support on or off. I added a couple of #ifdef's
and removed the broken macro definition. The #ifdef's made it unneccesary.
It also replaces create_proc_read_entry with proc_create.
This patch allows us to display information about all of the logical volumes
configured on a particular controller without stepping on memory even when
there are many volumes (128 or more) configured.
Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 9715be3..f1e7390 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -174,8 +175,6 @@ static int sendcmd_withirq(__u8 cmd, int ctlr, void *buff,
size_t size,
static void fail_all_cmds(unsigned long ctlr);
#ifdef CONFIG_PROC_FS
-static int cciss_proc_get_info(char *buffer, char **start, off_t offset,
- int length, int *eof, void *data);
static void cciss_procinit(int i);
#else
static void cciss_procinit(int i)
@@ -240,24 +239,46 @@ static inline CommandList_struct
*removeQ(CommandList_struct **Qptr,
*/
#define ENG_GIG 10
#define ENG_GIG_FACTOR (ENG_GIG/512)
+#define ENGAGE_SCSI"engage scsi"
static const char *raid_label[] = { "0", "4", "1(1+0)", "5", "5+1", "ADG",
"UNKNOWN"
};
static struct proc_dir_entry *proc_cciss;
-static int cciss_proc_get_info(char *buffer, char **start, off_t offset,
- int length, int *eof, void *data)
+static void cciss_seq_show_header(struct seq_file *seq)
{
- off_t pos = 0;
- off_t len = 0;
- int size, i, ctlr;
- ctlr_info_t *h = (ctlr_info_t *) data;
- drive_info_struct *drv;
- unsigned long flags;
- sector_t vol_sz, vol_sz_frac;
+ ctlr_info_t *h = seq->private;
+
+ seq_printf(seq, "%s: HP %s Controller\n"
+ "Board ID: 0x%08lx\n"
+ "Firmware Version: %c%c%c%c\n"
+ "IRQ: %d\n"
+ "Logical drives: %d\n"
+ "Current Q depth: %d\n"
+ "Current # commands on controller: %d\n"
+ "Max Q depth since init: %d\n"
+ "Max # commands on controller since init: %d\n"
+ "Max SG entries since init: %d\n",
+ h->devname,
+ h->product_name,
+ (unsigned long)h->board_id,
+ h->firm_ver[0], h->firm_ver[1], h->firm_ver[2],
+ h->firm_ver[3], (unsigned int)h->intr[SIMPLE_MODE_INT],
+ h->num_luns,
+ h->Qdepth, h->commands_outstanding,
+ h->maxQsinceinit, h->max_outstanding, h->maxSG);
- ctlr = h->ctlr;
+#ifdef CONFIG_CISS_SCSI_TAPE
+ cciss_seq_tape_report(seq, h->ctlr);
+#endif /* CONFIG_CISS_SCSI_TAPE */
+}
+
+static void *cciss_seq_start(struct seq_file *seq, loff_t *pos)
+{
+ ctlr_info_t *h = seq->private;
+ unsigned ctlr = h->ctlr;
+ unsigned long flags;
/* prevent displaying bogus info during configuration
* or deconfiguration of a logical volume
@@ -265,115 +286,155 @@ static int cciss_proc_get_info(char *buffer, char
**start, off_t offset,
spin_lock_irqsave(CCISS_LOCK(ctlr), flags);
if (h->busy_configuring) {
spin_unlock_irqrestore(CCISS_LOCK(ctlr), flags);
- return -EBUSY;
+ return ERR_PTR(-EBUSY);
}
h->busy_configuring = 1;
spin_unlock_irqrestore(CCISS_LOCK(ctlr), flags);
- size = sprintf(buffer, "%s: HP %s Controller\n"
- "Board ID: 0x%08lx\n"
- "Firmware Version: %c%c%c%c\n"
- "IRQ: %d\n"
- "Logical drives: %d\n"
- "Max sectors: %d\n"
- "Current Q depth: %d\n"
- "Current # commands on controller: %d\n"
- "Max Q depth since init: %d\n"
- "Max # commands on controller since init: %d\n"
- "Max SG entries since init: %d\n\n",
- h->devname,
- h->product_name,
- (unsigned long)h->board_id,
- h->firm_ver[0], h->firm_ver[1], h->firm_ver[2],
- h->firm_ver[3], (unsigne
[PATCH 1/1] resubmit: cciss: procfs updates to display info about many volumes
Patch 1 of 1
This patch hopefully fixes all the brokeness in my last submission. It
compiles cleanly with tape support on or off. I added a couple of #ifdef's
and removed the broken macro definition. The #ifdef's made it unneccesary.
It also replaces create_proc_read_entry with proc_create.
This patch allows us to display information about all of the logical volumes
configured on a particular controller without stepping on memory even when
there are many volumes (128 or more) configured.
Please consider this for inclusion.
Signed-off-by: Mike Miller [EMAIL PROTECTED]
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 9715be3..f1e7390 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -33,6 +33,7 @@
#include linux/blkpg.h
#include linux/timer.h
#include linux/proc_fs.h
+#include linux/seq_file.h
#include linux/init.h
#include linux/hdreg.h
#include linux/spinlock.h
@@ -174,8 +175,6 @@ static int sendcmd_withirq(__u8 cmd, int ctlr, void *buff,
size_t size,
static void fail_all_cmds(unsigned long ctlr);
#ifdef CONFIG_PROC_FS
-static int cciss_proc_get_info(char *buffer, char **start, off_t offset,
- int length, int *eof, void *data);
static void cciss_procinit(int i);
#else
static void cciss_procinit(int i)
@@ -240,24 +239,46 @@ static inline CommandList_struct
*removeQ(CommandList_struct **Qptr,
*/
#define ENG_GIG 10
#define ENG_GIG_FACTOR (ENG_GIG/512)
+#define ENGAGE_SCSIengage scsi
static const char *raid_label[] = { 0, 4, 1(1+0), 5, 5+1, ADG,
UNKNOWN
};
static struct proc_dir_entry *proc_cciss;
-static int cciss_proc_get_info(char *buffer, char **start, off_t offset,
- int length, int *eof, void *data)
+static void cciss_seq_show_header(struct seq_file *seq)
{
- off_t pos = 0;
- off_t len = 0;
- int size, i, ctlr;
- ctlr_info_t *h = (ctlr_info_t *) data;
- drive_info_struct *drv;
- unsigned long flags;
- sector_t vol_sz, vol_sz_frac;
+ ctlr_info_t *h = seq-private;
+
+ seq_printf(seq, %s: HP %s Controller\n
+ Board ID: 0x%08lx\n
+ Firmware Version: %c%c%c%c\n
+ IRQ: %d\n
+ Logical drives: %d\n
+ Current Q depth: %d\n
+ Current # commands on controller: %d\n
+ Max Q depth since init: %d\n
+ Max # commands on controller since init: %d\n
+ Max SG entries since init: %d\n,
+ h-devname,
+ h-product_name,
+ (unsigned long)h-board_id,
+ h-firm_ver[0], h-firm_ver[1], h-firm_ver[2],
+ h-firm_ver[3], (unsigned int)h-intr[SIMPLE_MODE_INT],
+ h-num_luns,
+ h-Qdepth, h-commands_outstanding,
+ h-maxQsinceinit, h-max_outstanding, h-maxSG);
- ctlr = h-ctlr;
+#ifdef CONFIG_CISS_SCSI_TAPE
+ cciss_seq_tape_report(seq, h-ctlr);
+#endif /* CONFIG_CISS_SCSI_TAPE */
+}
+
+static void *cciss_seq_start(struct seq_file *seq, loff_t *pos)
+{
+ ctlr_info_t *h = seq-private;
+ unsigned ctlr = h-ctlr;
+ unsigned long flags;
/* prevent displaying bogus info during configuration
* or deconfiguration of a logical volume
@@ -265,115 +286,155 @@ static int cciss_proc_get_info(char *buffer, char
**start, off_t offset,
spin_lock_irqsave(CCISS_LOCK(ctlr), flags);
if (h-busy_configuring) {
spin_unlock_irqrestore(CCISS_LOCK(ctlr), flags);
- return -EBUSY;
+ return ERR_PTR(-EBUSY);
}
h-busy_configuring = 1;
spin_unlock_irqrestore(CCISS_LOCK(ctlr), flags);
- size = sprintf(buffer, %s: HP %s Controller\n
- Board ID: 0x%08lx\n
- Firmware Version: %c%c%c%c\n
- IRQ: %d\n
- Logical drives: %d\n
- Max sectors: %d\n
- Current Q depth: %d\n
- Current # commands on controller: %d\n
- Max Q depth since init: %d\n
- Max # commands on controller since init: %d\n
- Max SG entries since init: %d\n\n,
- h-devname,
- h-product_name,
- (unsigned long)h-board_id,
- h-firm_ver[0], h-firm_ver[1], h-firm_ver[2],
- h-firm_ver[3], (unsigned int)h-intr[SIMPLE_MODE_INT],
- h-num_luns,
- h-cciss_max_sectors,
- h-Qdepth, h-commands_outstanding,
- h-maxQsinceinit, h-max_outstanding, h-maxSG);
-
- pos += size;
- len += size;
- cciss_proc_tape_report(ctlr, buffer, pos, len);
- for (i = 0; i = h-highest_lun; i
[PATCH 1/1] cciss: procfs updates to display info about many volumes
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/49a50244b19f8855/ba3dc95b23391521?hl=en=gst=cciss#ba3dc95b23391521
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.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 9715be3..b7cda85 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -174,8 +175,6 @@ static int sendcmd_withirq(__u8 cmd, int ctlr, void *buff,
size_t size,
static void fail_all_cmds(unsigned long ctlr);
#ifdef CONFIG_PROC_FS
-static int cciss_proc_get_info(char *buffer, char **start, off_t offset,
- int length, int *eof, void *data);
static void cciss_procinit(int i);
#else
static void cciss_procinit(int i)
@@ -240,24 +239,44 @@ static inline CommandList_struct
*removeQ(CommandList_struct **Qptr,
*/
#define ENG_GIG 10
#define ENG_GIG_FACTOR (ENG_GIG/512)
+#define ENGAGE_SCSI"engage scsi"
static const char *raid_label[] = { "0", "4", "1(1+0)", "5", "5+1", "ADG",
"UNKNOWN"
};
static struct proc_dir_entry *proc_cciss;
-static int cciss_proc_get_info(char *buffer, char **start, off_t offset,
- int length, int *eof, void *data)
+static void cciss_seq_show_header(struct seq_file *seq)
{
- off_t pos = 0;
- off_t len = 0;
- int size, i, ctlr;
- ctlr_info_t *h = (ctlr_info_t *) data;
- drive_info_struct *drv;
- unsigned long flags;
- sector_t vol_sz, vol_sz_frac;
+ ctlr_info_t *h = seq->private;
+
+ seq_printf(seq, "%s: HP %s Controller\n"
+ "Board ID: 0x%08lx\n"
+ "Firmware Version: %c%c%c%c\n"
+ "IRQ: %d\n"
+ "Logical drives: %d\n"
+ "Current Q depth: %d\n"
+ "Current # commands on controller: %d\n"
+ "Max Q depth since init: %d\n"
+ "Max # commands on controller since init: %d\n"
+ "Max SG entries since init: %d\n",
+ h->devname,
+ h->product_name,
+ (unsigned long)h->board_id,
+ h->firm_ver[0], h->firm_ver[1], h->firm_ver[2],
+ h->firm_ver[3], (unsigned int)h->intr[SIMPLE_MODE_INT],
+ h->num_luns,
+ h->Qdepth, h->commands_outstanding,
+ h->maxQsinceinit, h->max_outstanding, h->maxSG);
+
+ cciss_seq_tape_report(seq, h->ctlr);
+}
- ctlr = h->ctlr;
+static void *cciss_seq_start(struct seq_file *seq, loff_t *pos)
+{
+ ctlr_info_t *h = seq->private;
+ unsigned ctlr = h->ctlr;
+ unsigned long flags;
/* prevent displaying bogus info during configuration
* or deconfiguration of a logical volume
@@ -265,115 +284,150 @@ static int cciss_proc_get_info(char *buffer, char
**start, off_t offset,
spin_lock_irqsave(CCISS_LOCK(ctlr), flags);
if (h->busy_configuring) {
spin_unlock_irqrestore(CCISS_LOCK(ctlr), flags);
- return -EBUSY;
+ return ERR_PTR(-EBUSY);
}
h->busy_configuring = 1;
spin_unlock_irqrestore(CCISS_LOCK(ctlr), flags);
- size = sprintf(buffer, "%s: HP %s Controller\n"
- "Board ID: 0x%08lx\n"
- "Firmware Version: %c%c%c%c\n"
- "IRQ: %d\n"
- "Logical drives: %d\n"
- "Max sectors: %d\n"
- "Current Q depth: %d\n"
- "Current # commands on controller: %d\n"
- "Max Q depth since init: %d\n"
- "Max # commands on controller since init: %d\n"
- "Max SG entries since init: %d\n\n",
- h->devname,
- h->product_name,
- (unsigned long)h->board_id,
- h->firm_ver[0], h->firm_ver[1], h->firm_ver[2],
- h->firm_ver[3], (unsigne
[PATCH 3/3] cciss: version change to 3.6.18
Patch 3 of 3
This patch bumps the driver version to 3.6.18 to reflect support for the
P700m. This matches the HP released driver version for hardware support.
Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
diff --git a/Documentation/cciss.txt b/Documentation/cciss.txt
index e65736c..0467639 100644
--- a/Documentation/cciss.txt
+++ b/Documentation/cciss.txt
@@ -21,6 +21,7 @@ This driver is known to work with the following cards:
* SA E200
* SA E200i
* SA E500
+ * SA P700m
Detecting drive failures:
-
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index cd5ef4a..7a0b28b 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -51,15 +51,15 @@
#include
#define CCISS_DRIVER_VERSION(maj,min,submin) ((maj<<16)|(min<<8)|(submin))
-#define DRIVER_NAME "HP CISS Driver (v 3.6.14)"
-#define DRIVER_VERSION CCISS_DRIVER_VERSION(3,6,14)
+#define DRIVER_NAME "HP CISS Driver (v 3.6.18)"
+#define DRIVER_VERSION CCISS_DRIVER_VERSION(3,6,18)
/* Embedded module documentation macros - see modules.h */
MODULE_AUTHOR("Hewlett-Packard Company");
-MODULE_DESCRIPTION("Driver for HP Controller SA5xxx SA6xxx version 3.6.14");
+MODULE_DESCRIPTION("Driver for HP Controller SA5xxx SA6xxx version 3.6.18");
MODULE_SUPPORTED_DEVICE("HP SA5i SA5i+ SA532 SA5300 SA5312 SA641 SA642 SA6400"
- " SA6i P600 P800 P400 P400i E200 E200i E500");
-MODULE_VERSION("3.6.14");
+ " SA6i P600 P800 P400 P400i E200 E200i E500 P700m");
+MODULE_VERSION("3.6.18");
MODULE_LICENSE("GPL");
#include "cciss_cmd.h"
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] cciss: change information displayed in /proc/drivers/cciss
Patch 2 of 3
This patch modifies our /proc entries to display information about only
the first logical volume on each controller. Primary reason is for hardware
that can support many LUNs (128 or more). In this case we can step on memory
and crash the system trying to display so much information. Users will have
to find information about other LUNs in /sys/block rather than /proc/drivers.
Also took the liberty of making some formatting changes to eliminate a bunch
of white spaces while I was in that part of the code.
Hardware to support this many LUNs should be available in March 2008.
Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 54080e6..cd5ef4a 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -716,7 +716,7 @@ static int cciss_proc_get_info(char *buffer, char **start,
off_t offset,
{
off_t pos = 0;
off_t len = 0;
- int size, i, ctlr;
+ int size, ctlr;
ctlr_info_t *h = (ctlr_info_t *) data;
drive_info_struct *drv;
unsigned long flags;
@@ -736,50 +736,47 @@ static int cciss_proc_get_info(char *buffer, char
**start, off_t offset,
spin_unlock_irqrestore(CCISS_LOCK(ctlr), flags);
size = sprintf(buffer, "%s: HP %s Controller\n"
- "Board ID: 0x%08lx\n"
- "Firmware Version: %c%c%c%c\n"
- "IRQ: %d\n"
- "Logical drives: %d\n"
- "Max sectors: %d\n"
- "Current Q depth: %d\n"
- "Current # commands on controller: %d\n"
- "Max Q depth since init: %d\n"
- "Max # commands on controller since init: %d\n"
- "Max SG entries since init: %d\n\n",
- h->devname,
- h->product_name,
- (unsigned long)h->board_id,
- h->firm_ver[0], h->firm_ver[1], h->firm_ver[2],
- h->firm_ver[3], (unsigned int)h->intr[SIMPLE_MODE_INT],
- h->num_luns,
- h->cciss_max_sectors,
- h->Qdepth, h->commands_outstanding,
- h->maxQsinceinit, h->max_outstanding, h->maxSG);
-
- pos += size;
- len += size;
+ "Board ID: 0x%08lx\n"
+ "Firmware Version: %c%c%c%c\n"
+ "IRQ: %d\n"
+ "Max sectors: %d\n"
+ "Current Q depth: %d\n"
+ "Current # commands on controller: %d\n"
+ "Max Q depth since init: %d\n"
+ "Max # commands on controller since init: %d\n"
+ "Max SG entries since init: %d\n"
+ "Logical drives: %d\n\n",
+ h->devname,
+ h->product_name,
+ (unsigned long)h->board_id,
+ h->firm_ver[0], h->firm_ver[1], h->firm_ver[2],
+ h->firm_ver[3], (unsigned int)h->intr[SIMPLE_MODE_INT],
+ h->cciss_max_sectors,
+ h->Qdepth, h->commands_outstanding,
+ h->maxQsinceinit, h->max_outstanding,
+ h->maxSG, h->num_luns);
+
+ pos += size; len += size;
cciss_proc_tape_report(ctlr, buffer, , );
- for (i = 0; i <= h->highest_lun; i++) {
-
- drv = >drv[i];
- if (drv->heads == 0)
- continue;
-
- vol_sz = drv->nr_blocks;
- vol_sz_frac = sector_div(vol_sz, ENG_GIG_FACTOR);
- vol_sz_frac *= 100;
- sector_div(vol_sz_frac, ENG_GIG_FACTOR);
+ drv = >drv[0];
+ vol_sz = drv->nr_blocks;
+ vol_sz_frac = sector_div(vol_sz, ENG_GIG_FACTOR);
+ vol_sz_frac *= 100;
+ sector_div(vol_sz_frac, ENG_GIG_FACTOR);
- if (drv->raid_level > 5)
- drv->raid_level = RAID_UNKNOWN;
- size = sprintf(buffer + len, "cciss/c%dd%d:"
+ if (drv->raid_level > 5)
+ drv->raid_level = RAID_UNKNOWN;
+ if (drv->heads) {
+ size = sprintf(buffer + len, "cciss/c%dd0:"
"\t%4u.%02uGB\tRAID %s\n",
- ctlr, i, (int)vol_sz, (int)vol_sz_frac,
+ ctlr, (int)vol_sz, (int)vol_sz_frac,
raid_label[drv->
[PATCH 1/3] cciss: export more attributes to sysfs (repost)
Patch 1 of 3
Sorry to take so long to repost.
This patch exports more attributes to /sys so we can work work better with
udev. Some distros use unique_id among other attributes. This patch attempts
to provide that and other attributes to reveal more information about cciss
devices in /sys. It's also an effort to be more sysfs friendly.
Please consider this for inclusion.
Signed-off-by: Mike Miller
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 7d70496..54080e6 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -229,20 +229,485 @@ static inline CommandList_struct
*removeQ(CommandList_struct **Qptr,
return c;
}
+static inline int find_drv_index(int ctlr, drive_info_struct *drv){
+int i;
+for (i=0; i < CISS_MAX_LUN; i++) {
+if (hba[ctlr]->drv[i].LunID == drv->LunID)
+return i;
+}
+return i;
+}
+
#include "cciss_scsi.c"/* For SCSI tape support */
+#define ENG_GIG 10
+#define ENG_GIG_FACTOR (ENG_GIG/512)
#define RAID_UNKNOWN 6
+static const char *raid_label[] = { "0", "4", "1(1+0)", "5", "5+1", "ADG",
+ "UNKNOWN"};
+
+
+static spinlock_t sysfs_lock = SPIN_LOCK_UNLOCKED;
+
+static void cciss_sysfs_stat_inquiry(int ctlr, int logvol,
+ int withirq, drive_info_struct *drv)
+{
+ int return_code;
+ InquiryData_struct *inq_buff;
+
+ /* If there are no heads then this is the controller disk and
+* not a valid logical drive so don't query it.
+*/
+ if (!drv->heads)
+ return;
+
+ inq_buff = kzalloc(sizeof(InquiryData_struct), GFP_KERNEL);
+ if (!inq_buff) {
+ printk(KERN_ERR "cciss: out of memory\n");
+ goto err;
+ }
+
+ if (withirq)
+ return_code = sendcmd_withirq(CISS_INQUIRY, ctlr,
+ inq_buff, sizeof(*inq_buff), 1, logvol ,0, TYPE_CMD);
+ else
+ return_code = sendcmd(CISS_INQUIRY, ctlr, inq_buff,
+ sizeof(*inq_buff), 1, logvol , 0, NULL, TYPE_CMD);
+ if (return_code == IO_OK) {
+ memcpy(drv->vendor, _buff->data_byte[8], 8);
+ drv->vendor[8]='\0';
+ memcpy(drv->model, _buff->data_byte[16], 16);
+ drv->model[16] = '\0';
+ memcpy(drv->rev, _buff->data_byte[32], 4);
+ drv->rev[4] = '\0';
+ } else { /* Get geometry failed */
+ printk(KERN_WARNING "cciss: inquiry for VPD page 0 failed\n");
+ }
+
+ if (withirq)
+ return_code = sendcmd_withirq(CISS_INQUIRY, ctlr,
+ inq_buff, sizeof(*inq_buff), 1, logvol ,0x83, TYPE_CMD);
+ else
+ return_code = sendcmd(CISS_INQUIRY, ctlr, inq_buff,
+ sizeof(*inq_buff), 1, logvol , 0x83, NULL, TYPE_CMD);
+
+ if (return_code == IO_OK) {
+ memcpy(drv->uid, _buff->data_byte[8], 16);
+ } else { /* Get geometry failed */
+ printk(KERN_WARNING "cciss: inquiry for VPD page 83 failed\n");
+ }
+
+ kfree(inq_buff);
+err:
+ drv->vendor[8] = '\0';
+ drv->model[16] = '\0';
+ drv->rev[4] = '\0';
+
+}
+
+static ssize_t cciss_show_raid_level(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct drv_dynamic *d;
+ drive_info_struct *drv;
+ ctlr_info_t *h;
+ unsigned long flags;
+ int raid;
+
+ d = container_of(dev, struct drv_dynamic, dev);
+ spin_lock(_lock);
+ if (!d->disk) {
+ spin_unlock(_lock);
+ return -ENOENT;
+ }
+
+ h = get_host(d->disk);
+
+ spin_lock_irqsave(CCISS_LOCK(h->ctlr), flags);
+ if (h->busy_configuring) {
+ spin_unlock_irqrestore(CCISS_LOCK(h->ctlr), flags);
+ spin_unlock(_lock);
+ return snprintf(buf, 30, "Device busy configuring\n");
+ }
+
+ drv = d->disk->private_data;
+ if ((drv->raid_level < 0) || (drv->raid_level) > 5)
+ raid = RAID_UNKNOWN;
+ else
+ raid = drv->raid_level;
+
+ spin_unlock_irqrestore(CCISS_LOCK(h->ctlr), flags);
+ spin_unlock(_lock);
+ return snprintf(buf, 20, "RAID %s\n", raid_label[raid]);
+}
+
+static ssize_t cciss_show_disk_size(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct drv_dynamic *d;
+ drive_info_struct *drv;
+ ctlr_info_t *h;
+ unsigned long flags;
+ sector_t vol_sz, vol_sz_frac;
+
+ d = container_of(dev, struct drv_dynamic, dev);
+ spin_lock(_lock)
[PATCH 3/3] cciss: version change to 3.6.18
Patch 3 of 3 This patch bumps the driver version to 3.6.18 to reflect support for the P700m. This matches the HP released driver version for hardware support. Please consider this for inclusion. Signed-off-by: Mike Miller [EMAIL PROTECTED] diff --git a/Documentation/cciss.txt b/Documentation/cciss.txt index e65736c..0467639 100644 --- a/Documentation/cciss.txt +++ b/Documentation/cciss.txt @@ -21,6 +21,7 @@ This driver is known to work with the following cards: * SA E200 * SA E200i * SA E500 + * SA P700m Detecting drive failures: - diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index cd5ef4a..7a0b28b 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -51,15 +51,15 @@ #include linux/cdrom.h #define CCISS_DRIVER_VERSION(maj,min,submin) ((maj16)|(min8)|(submin)) -#define DRIVER_NAME HP CISS Driver (v 3.6.14) -#define DRIVER_VERSION CCISS_DRIVER_VERSION(3,6,14) +#define DRIVER_NAME HP CISS Driver (v 3.6.18) +#define DRIVER_VERSION CCISS_DRIVER_VERSION(3,6,18) /* Embedded module documentation macros - see modules.h */ MODULE_AUTHOR(Hewlett-Packard Company); -MODULE_DESCRIPTION(Driver for HP Controller SA5xxx SA6xxx version 3.6.14); +MODULE_DESCRIPTION(Driver for HP Controller SA5xxx SA6xxx version 3.6.18); MODULE_SUPPORTED_DEVICE(HP SA5i SA5i+ SA532 SA5300 SA5312 SA641 SA642 SA6400 -SA6i P600 P800 P400 P400i E200 E200i E500); -MODULE_VERSION(3.6.14); +SA6i P600 P800 P400 P400i E200 E200i E500 P700m); +MODULE_VERSION(3.6.18); MODULE_LICENSE(GPL); #include cciss_cmd.h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] cciss: export more attributes to sysfs (repost)
Patch 1 of 3
Sorry to take so long to repost.
This patch exports more attributes to /sys so we can work work better with
udev. Some distros use unique_id among other attributes. This patch attempts
to provide that and other attributes to reveal more information about cciss
devices in /sys. It's also an effort to be more sysfs friendly.
Please consider this for inclusion.
Signed-off-by: Mike Miller
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 7d70496..54080e6 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -229,20 +229,485 @@ static inline CommandList_struct
*removeQ(CommandList_struct **Qptr,
return c;
}
+static inline int find_drv_index(int ctlr, drive_info_struct *drv){
+int i;
+for (i=0; i CISS_MAX_LUN; i++) {
+if (hba[ctlr]-drv[i].LunID == drv-LunID)
+return i;
+}
+return i;
+}
+
#include cciss_scsi.c/* For SCSI tape support */
+#define ENG_GIG 10
+#define ENG_GIG_FACTOR (ENG_GIG/512)
#define RAID_UNKNOWN 6
+static const char *raid_label[] = { 0, 4, 1(1+0), 5, 5+1, ADG,
+ UNKNOWN};
+
+
+static spinlock_t sysfs_lock = SPIN_LOCK_UNLOCKED;
+
+static void cciss_sysfs_stat_inquiry(int ctlr, int logvol,
+ int withirq, drive_info_struct *drv)
+{
+ int return_code;
+ InquiryData_struct *inq_buff;
+
+ /* If there are no heads then this is the controller disk and
+* not a valid logical drive so don't query it.
+*/
+ if (!drv-heads)
+ return;
+
+ inq_buff = kzalloc(sizeof(InquiryData_struct), GFP_KERNEL);
+ if (!inq_buff) {
+ printk(KERN_ERR cciss: out of memory\n);
+ goto err;
+ }
+
+ if (withirq)
+ return_code = sendcmd_withirq(CISS_INQUIRY, ctlr,
+ inq_buff, sizeof(*inq_buff), 1, logvol ,0, TYPE_CMD);
+ else
+ return_code = sendcmd(CISS_INQUIRY, ctlr, inq_buff,
+ sizeof(*inq_buff), 1, logvol , 0, NULL, TYPE_CMD);
+ if (return_code == IO_OK) {
+ memcpy(drv-vendor, inq_buff-data_byte[8], 8);
+ drv-vendor[8]='\0';
+ memcpy(drv-model, inq_buff-data_byte[16], 16);
+ drv-model[16] = '\0';
+ memcpy(drv-rev, inq_buff-data_byte[32], 4);
+ drv-rev[4] = '\0';
+ } else { /* Get geometry failed */
+ printk(KERN_WARNING cciss: inquiry for VPD page 0 failed\n);
+ }
+
+ if (withirq)
+ return_code = sendcmd_withirq(CISS_INQUIRY, ctlr,
+ inq_buff, sizeof(*inq_buff), 1, logvol ,0x83, TYPE_CMD);
+ else
+ return_code = sendcmd(CISS_INQUIRY, ctlr, inq_buff,
+ sizeof(*inq_buff), 1, logvol , 0x83, NULL, TYPE_CMD);
+
+ if (return_code == IO_OK) {
+ memcpy(drv-uid, inq_buff-data_byte[8], 16);
+ } else { /* Get geometry failed */
+ printk(KERN_WARNING cciss: inquiry for VPD page 83 failed\n);
+ }
+
+ kfree(inq_buff);
+err:
+ drv-vendor[8] = '\0';
+ drv-model[16] = '\0';
+ drv-rev[4] = '\0';
+
+}
+
+static ssize_t cciss_show_raid_level(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct drv_dynamic *d;
+ drive_info_struct *drv;
+ ctlr_info_t *h;
+ unsigned long flags;
+ int raid;
+
+ d = container_of(dev, struct drv_dynamic, dev);
+ spin_lock(sysfs_lock);
+ if (!d-disk) {
+ spin_unlock(sysfs_lock);
+ return -ENOENT;
+ }
+
+ h = get_host(d-disk);
+
+ spin_lock_irqsave(CCISS_LOCK(h-ctlr), flags);
+ if (h-busy_configuring) {
+ spin_unlock_irqrestore(CCISS_LOCK(h-ctlr), flags);
+ spin_unlock(sysfs_lock);
+ return snprintf(buf, 30, Device busy configuring\n);
+ }
+
+ drv = d-disk-private_data;
+ if ((drv-raid_level 0) || (drv-raid_level) 5)
+ raid = RAID_UNKNOWN;
+ else
+ raid = drv-raid_level;
+
+ spin_unlock_irqrestore(CCISS_LOCK(h-ctlr), flags);
+ spin_unlock(sysfs_lock);
+ return snprintf(buf, 20, RAID %s\n, raid_label[raid]);
+}
+
+static ssize_t cciss_show_disk_size(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct drv_dynamic *d;
+ drive_info_struct *drv;
+ ctlr_info_t *h;
+ unsigned long flags;
+ sector_t vol_sz, vol_sz_frac;
+
+ d = container_of(dev, struct drv_dynamic, dev);
+ spin_lock(sysfs_lock);
+ if (!d-disk) {
+ spin_unlock(sysfs_lock);
+ return -ENOENT;
+ }
+ h = get_host(d-disk);
+
+ spin_lock_irqsave(CCISS_LOCK(h-ctlr), flags);
+ if (h-busy_configuring
[PATCH 2/3] cciss: change information displayed in /proc/drivers/cciss
Patch 2 of 3
This patch modifies our /proc entries to display information about only
the first logical volume on each controller. Primary reason is for hardware
that can support many LUNs (128 or more). In this case we can step on memory
and crash the system trying to display so much information. Users will have
to find information about other LUNs in /sys/block rather than /proc/drivers.
Also took the liberty of making some formatting changes to eliminate a bunch
of white spaces while I was in that part of the code.
Hardware to support this many LUNs should be available in March 2008.
Please consider this for inclusion.
Signed-off-by: Mike Miller [EMAIL PROTECTED]
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 54080e6..cd5ef4a 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -716,7 +716,7 @@ static int cciss_proc_get_info(char *buffer, char **start,
off_t offset,
{
off_t pos = 0;
off_t len = 0;
- int size, i, ctlr;
+ int size, ctlr;
ctlr_info_t *h = (ctlr_info_t *) data;
drive_info_struct *drv;
unsigned long flags;
@@ -736,50 +736,47 @@ static int cciss_proc_get_info(char *buffer, char
**start, off_t offset,
spin_unlock_irqrestore(CCISS_LOCK(ctlr), flags);
size = sprintf(buffer, %s: HP %s Controller\n
- Board ID: 0x%08lx\n
- Firmware Version: %c%c%c%c\n
- IRQ: %d\n
- Logical drives: %d\n
- Max sectors: %d\n
- Current Q depth: %d\n
- Current # commands on controller: %d\n
- Max Q depth since init: %d\n
- Max # commands on controller since init: %d\n
- Max SG entries since init: %d\n\n,
- h-devname,
- h-product_name,
- (unsigned long)h-board_id,
- h-firm_ver[0], h-firm_ver[1], h-firm_ver[2],
- h-firm_ver[3], (unsigned int)h-intr[SIMPLE_MODE_INT],
- h-num_luns,
- h-cciss_max_sectors,
- h-Qdepth, h-commands_outstanding,
- h-maxQsinceinit, h-max_outstanding, h-maxSG);
-
- pos += size;
- len += size;
+ Board ID: 0x%08lx\n
+ Firmware Version: %c%c%c%c\n
+ IRQ: %d\n
+ Max sectors: %d\n
+ Current Q depth: %d\n
+ Current # commands on controller: %d\n
+ Max Q depth since init: %d\n
+ Max # commands on controller since init: %d\n
+ Max SG entries since init: %d\n
+ Logical drives: %d\n\n,
+ h-devname,
+ h-product_name,
+ (unsigned long)h-board_id,
+ h-firm_ver[0], h-firm_ver[1], h-firm_ver[2],
+ h-firm_ver[3], (unsigned int)h-intr[SIMPLE_MODE_INT],
+ h-cciss_max_sectors,
+ h-Qdepth, h-commands_outstanding,
+ h-maxQsinceinit, h-max_outstanding,
+ h-maxSG, h-num_luns);
+
+ pos += size; len += size;
cciss_proc_tape_report(ctlr, buffer, pos, len);
- for (i = 0; i = h-highest_lun; i++) {
-
- drv = h-drv[i];
- if (drv-heads == 0)
- continue;
-
- vol_sz = drv-nr_blocks;
- vol_sz_frac = sector_div(vol_sz, ENG_GIG_FACTOR);
- vol_sz_frac *= 100;
- sector_div(vol_sz_frac, ENG_GIG_FACTOR);
+ drv = h-drv[0];
+ vol_sz = drv-nr_blocks;
+ vol_sz_frac = sector_div(vol_sz, ENG_GIG_FACTOR);
+ vol_sz_frac *= 100;
+ sector_div(vol_sz_frac, ENG_GIG_FACTOR);
- if (drv-raid_level 5)
- drv-raid_level = RAID_UNKNOWN;
- size = sprintf(buffer + len, cciss/c%dd%d:
+ if (drv-raid_level 5)
+ drv-raid_level = RAID_UNKNOWN;
+ if (drv-heads) {
+ size = sprintf(buffer + len, cciss/c%dd0:
\t%4u.%02uGB\tRAID %s\n,
- ctlr, i, (int)vol_sz, (int)vol_sz_frac,
+ ctlr, (int)vol_sz, (int)vol_sz_frac,
raid_label[drv-raid_level]);
- pos += size;
- len += size;
+ pos += size; len += size;
}
+ size = sprintf(buffer + len, For information about other logical
+volumes see /sys/block/cciss!c%dd*\n, ctlr);
+ pos += size; len += size;
*eof = 1;
*start = buffer + offset;
len -= offset;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
[PATCH 3/3] cciss: change version to 3.6.18
Patch 3 of 3
This patch bumps the version of the driver from .14 to .18 to more closely
match the driver that HP ships. This driver already supports all the
hardware that the HP 3.6.18 version supports. So the versions should match,
also. Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
diff --git a/Documentation/cciss.txt b/Documentation/cciss.txt
index e65736c..0467639 100644
--- a/Documentation/cciss.txt
+++ b/Documentation/cciss.txt
@@ -21,6 +21,7 @@ This driver is known to work with the following cards:
* SA E200
* SA E200i
* SA E500
+ * SA P700m
Detecting drive failures:
-
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 61bc0f3..6ddf543 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -55,15 +55,15 @@
#include
#define CCISS_DRIVER_VERSION(maj,min,submin) ((maj<<16)|(min<<8)|(submin))
-#define DRIVER_NAME "HP CISS Driver (v 3.6.14)"
-#define DRIVER_VERSION CCISS_DRIVER_VERSION(3,6,14)
+#define DRIVER_NAME "HP CISS Driver (v 3.6.18)"
+#define DRIVER_VERSION CCISS_DRIVER_VERSION(3,6,18)
/* Embedded module documentation macros - see modules.h */
MODULE_AUTHOR("Hewlett-Packard Company");
-MODULE_DESCRIPTION("Driver for HP Controller SA5xxx SA6xxx version 3.6.14");
+MODULE_DESCRIPTION("Driver for HP Controller SA5xxx SA6xxx version 3.6.18");
MODULE_SUPPORTED_DEVICE("HP SA5i SA5i+ SA532 SA5300 SA5312 SA641 SA642 SA6400"
- " SA6i P600 P800 P400 P400i E200 E200i E500");
-MODULE_VERSION("3.6.14");
+ " SA6i P600 P800 P400 P400i E200 E200i E500 P700m");
+MODULE_VERSION("3.6.18");
MODULE_LICENSE("GPL");
#include "cciss_cmd.h"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] cciss: add support for blktrace
Patch 2 of 3 This patch adds support for the blktrace utility. Please consider this for inclusion. Seems there was already a call to blk_add_trace. This patch adds ifdef's and includes the header file. Signed-off-by: Mike Miller <[EMAIL PROTECTED]> diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index 2ba5a89..61bc0f3 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -41,6 +41,10 @@ #include #include +#ifdef CONFIG_BLK_DEV_IO_TRACE +#include +#endif /* CONFIG_BLK_DEV_IO_TRACE */ + #include #include #include @@ -3013,7 +3017,9 @@ after_error_processing: } cmd->rq->data_len = 0; cmd->rq->completion_data = cmd; +#ifdef CONFIG_BLK_DEV_IO_TRACE blk_add_trace_rq(cmd->rq->q, cmd->rq, BLK_TA_COMPLETE); +#endif /* CONFIG_BLK_DEV_IO_TRACE */ blk_complete_request(cmd->rq); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] cciss: export more sysfs attributes
Patch 1 of 3
This patch creates more sysfs attributes to be exported by cciss. Hopefully
we can work better with udev. Please consider this patch for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 7d70496..2ba5a89 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -229,20 +229,483 @@ static inline CommandList_struct
*removeQ(CommandList_struct **Qptr,
return c;
}
+static inline int find_drv_index(int ctlr, drive_info_struct *drv){
+int i;
+for (i=0; i < CISS_MAX_LUN; i++) {
+if (hba[ctlr]->drv[i].LunID == drv->LunID)
+return i;
+}
+return i;
+}
+
#include "cciss_scsi.c"/* For SCSI tape support */
+#define ENG_GIG 10
+#define ENG_GIG_FACTOR (ENG_GIG/512)
#define RAID_UNKNOWN 6
+static const char *raid_label[] = { "0", "4", "1(1+0)", "5", "5+1", "ADG",
+ "UNKNOWN"};
+
+
+static spinlock_t sysfs_lock = SPIN_LOCK_UNLOCKED;
+
+static void cciss_sysfs_stat_inquiry(int ctlr, int logvol,
+ int withirq, drive_info_struct *drv)
+{
+ int return_code;
+ InquiryData_struct *inq_buff;
+
+ /* If there are no heads then this is the controller disk and
+* not a valid logical drive so don't query it.
+*/
+ if (!drv->heads)
+ return;
+
+ inq_buff = kzalloc(sizeof(InquiryData_struct), GFP_KERNEL);
+ if (!inq_buff) {
+ printk(KERN_ERR "cciss: out of memory\n");
+ goto err;
+ }
+
+ if (withirq)
+ return_code = sendcmd_withirq(CISS_INQUIRY, ctlr,
+ inq_buff, sizeof(*inq_buff), 1, logvol ,0, TYPE_CMD);
+ else
+ return_code = sendcmd(CISS_INQUIRY, ctlr, inq_buff,
+ sizeof(*inq_buff), 1, logvol , 0, NULL, TYPE_CMD);
+ if (return_code == IO_OK) {
+ memcpy(drv->vendor, _buff->data_byte[8], 8);
+ drv->vendor[8]='\0';
+ memcpy(drv->model, _buff->data_byte[16], 16);
+ drv->model[16] = '\0';
+ memcpy(drv->rev, _buff->data_byte[32], 4);
+ drv->rev[4] = '\0';
+ } else { /* Get geometry failed */
+ printk(KERN_WARNING "cciss: inquiry for VPD page 0 failed\n");
+ }
+
+ if (withirq)
+ return_code = sendcmd_withirq(CISS_INQUIRY, ctlr,
+ inq_buff, sizeof(*inq_buff), 1, logvol ,0x83, TYPE_CMD);
+ else
+ return_code = sendcmd(CISS_INQUIRY, ctlr, inq_buff,
+ sizeof(*inq_buff), 1, logvol , 0x83, NULL, TYPE_CMD);
+
+ if (return_code == IO_OK) {
+ memcpy(drv->uid, _buff->data_byte[8], 16);
+ } else { /* Get geometry failed */
+ printk(KERN_WARNING "cciss: id logical drive failed\n");
+ }
+
+ kfree(inq_buff);
+err:
+ drv->vendor[8] = '\0';
+ drv->model[16] = '\0';
+ drv->rev[4] = '\0';
+
+}
+
+static ssize_t cciss_show_raid_level(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct drv_dynamic *d;
+ drive_info_struct *drv;
+ ctlr_info_t *h;
+ unsigned long flags;
+ int raid;
+
+ d = container_of(dev, struct drv_dynamic, dev);
+ spin_lock(_lock);
+ if (!d->disk) {
+ spin_unlock(_lock);
+ return -ENOENT;
+ }
+
+ h = get_host(d->disk);
+
+ spin_lock_irqsave(CCISS_LOCK(h->ctlr), flags);
+ if (h->busy_configuring) {
+ spin_unlock_irqrestore(CCISS_LOCK(h->ctlr), flags);
+ spin_unlock(_lock);
+ return snprintf(buf, 30, "Device busy configuring\n");
+ }
+
+ drv = d->disk->private_data;
+ if ((drv->raid_level < 0) || (drv->raid_level) > 5)
+ raid = RAID_UNKNOWN;
+ else
+ raid = drv->raid_level;
+
+ spin_unlock_irqrestore(CCISS_LOCK(h->ctlr), flags);
+ spin_unlock(_lock);
+ return snprintf(buf, 20, "RAID %s\n", raid_label[raid]);
+}
+
+static ssize_t cciss_show_disk_size(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct drv_dynamic *d;
+ drive_info_struct *drv;
+ ctlr_info_t *h;
+ unsigned long flags;
+ sector_t vol_sz, vol_sz_frac;
+
+ d = container_of(dev, struct drv_dynamic, dev);
+ spin_lock(_lock);
+ if (!d->disk) {
+ spin_unlock(_lock);
+ return -ENOENT;
+ }
+ h = get_host(d->disk);
+
+ spin_lock_irqsave(CCISS_LOCK(h->ctlr), fla
[PATCH 1/3] cciss: export more sysfs attributes
Patch 1 of 3
This patch creates more sysfs attributes to be exported by cciss. Hopefully
we can work better with udev. Please consider this patch for inclusion.
Signed-off-by: Mike Miller [EMAIL PROTECTED]
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 7d70496..2ba5a89 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -229,20 +229,483 @@ static inline CommandList_struct
*removeQ(CommandList_struct **Qptr,
return c;
}
+static inline int find_drv_index(int ctlr, drive_info_struct *drv){
+int i;
+for (i=0; i CISS_MAX_LUN; i++) {
+if (hba[ctlr]-drv[i].LunID == drv-LunID)
+return i;
+}
+return i;
+}
+
#include cciss_scsi.c/* For SCSI tape support */
+#define ENG_GIG 10
+#define ENG_GIG_FACTOR (ENG_GIG/512)
#define RAID_UNKNOWN 6
+static const char *raid_label[] = { 0, 4, 1(1+0), 5, 5+1, ADG,
+ UNKNOWN};
+
+
+static spinlock_t sysfs_lock = SPIN_LOCK_UNLOCKED;
+
+static void cciss_sysfs_stat_inquiry(int ctlr, int logvol,
+ int withirq, drive_info_struct *drv)
+{
+ int return_code;
+ InquiryData_struct *inq_buff;
+
+ /* If there are no heads then this is the controller disk and
+* not a valid logical drive so don't query it.
+*/
+ if (!drv-heads)
+ return;
+
+ inq_buff = kzalloc(sizeof(InquiryData_struct), GFP_KERNEL);
+ if (!inq_buff) {
+ printk(KERN_ERR cciss: out of memory\n);
+ goto err;
+ }
+
+ if (withirq)
+ return_code = sendcmd_withirq(CISS_INQUIRY, ctlr,
+ inq_buff, sizeof(*inq_buff), 1, logvol ,0, TYPE_CMD);
+ else
+ return_code = sendcmd(CISS_INQUIRY, ctlr, inq_buff,
+ sizeof(*inq_buff), 1, logvol , 0, NULL, TYPE_CMD);
+ if (return_code == IO_OK) {
+ memcpy(drv-vendor, inq_buff-data_byte[8], 8);
+ drv-vendor[8]='\0';
+ memcpy(drv-model, inq_buff-data_byte[16], 16);
+ drv-model[16] = '\0';
+ memcpy(drv-rev, inq_buff-data_byte[32], 4);
+ drv-rev[4] = '\0';
+ } else { /* Get geometry failed */
+ printk(KERN_WARNING cciss: inquiry for VPD page 0 failed\n);
+ }
+
+ if (withirq)
+ return_code = sendcmd_withirq(CISS_INQUIRY, ctlr,
+ inq_buff, sizeof(*inq_buff), 1, logvol ,0x83, TYPE_CMD);
+ else
+ return_code = sendcmd(CISS_INQUIRY, ctlr, inq_buff,
+ sizeof(*inq_buff), 1, logvol , 0x83, NULL, TYPE_CMD);
+
+ if (return_code == IO_OK) {
+ memcpy(drv-uid, inq_buff-data_byte[8], 16);
+ } else { /* Get geometry failed */
+ printk(KERN_WARNING cciss: id logical drive failed\n);
+ }
+
+ kfree(inq_buff);
+err:
+ drv-vendor[8] = '\0';
+ drv-model[16] = '\0';
+ drv-rev[4] = '\0';
+
+}
+
+static ssize_t cciss_show_raid_level(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct drv_dynamic *d;
+ drive_info_struct *drv;
+ ctlr_info_t *h;
+ unsigned long flags;
+ int raid;
+
+ d = container_of(dev, struct drv_dynamic, dev);
+ spin_lock(sysfs_lock);
+ if (!d-disk) {
+ spin_unlock(sysfs_lock);
+ return -ENOENT;
+ }
+
+ h = get_host(d-disk);
+
+ spin_lock_irqsave(CCISS_LOCK(h-ctlr), flags);
+ if (h-busy_configuring) {
+ spin_unlock_irqrestore(CCISS_LOCK(h-ctlr), flags);
+ spin_unlock(sysfs_lock);
+ return snprintf(buf, 30, Device busy configuring\n);
+ }
+
+ drv = d-disk-private_data;
+ if ((drv-raid_level 0) || (drv-raid_level) 5)
+ raid = RAID_UNKNOWN;
+ else
+ raid = drv-raid_level;
+
+ spin_unlock_irqrestore(CCISS_LOCK(h-ctlr), flags);
+ spin_unlock(sysfs_lock);
+ return snprintf(buf, 20, RAID %s\n, raid_label[raid]);
+}
+
+static ssize_t cciss_show_disk_size(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct drv_dynamic *d;
+ drive_info_struct *drv;
+ ctlr_info_t *h;
+ unsigned long flags;
+ sector_t vol_sz, vol_sz_frac;
+
+ d = container_of(dev, struct drv_dynamic, dev);
+ spin_lock(sysfs_lock);
+ if (!d-disk) {
+ spin_unlock(sysfs_lock);
+ return -ENOENT;
+ }
+ h = get_host(d-disk);
+
+ spin_lock_irqsave(CCISS_LOCK(h-ctlr), flags);
+ if (h-busy_configuring) {
+ spin_unlock_irqrestore(CCISS_LOCK(h-ctlr), flags);
+ spin_unlock(sysfs_lock);
+ return snprintf(buf, 30, Device busy configuring\n);
+ }
+
+ drv = d-disk-private_data
[PATCH 2/3] cciss: add support for blktrace
Patch 2 of 3 This patch adds support for the blktrace utility. Please consider this for inclusion. Seems there was already a call to blk_add_trace. This patch adds ifdef's and includes the header file. Signed-off-by: Mike Miller [EMAIL PROTECTED] diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index 2ba5a89..61bc0f3 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -41,6 +41,10 @@ #include asm/uaccess.h #include asm/io.h +#ifdef CONFIG_BLK_DEV_IO_TRACE +#include linux/blktrace_api.h +#endif /* CONFIG_BLK_DEV_IO_TRACE */ + #include linux/dma-mapping.h #include linux/blkdev.h #include linux/genhd.h @@ -3013,7 +3017,9 @@ after_error_processing: } cmd-rq-data_len = 0; cmd-rq-completion_data = cmd; +#ifdef CONFIG_BLK_DEV_IO_TRACE blk_add_trace_rq(cmd-rq-q, cmd-rq, BLK_TA_COMPLETE); +#endif /* CONFIG_BLK_DEV_IO_TRACE */ blk_complete_request(cmd-rq); } - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] cciss: change version to 3.6.18
Patch 3 of 3 This patch bumps the version of the driver from .14 to .18 to more closely match the driver that HP ships. This driver already supports all the hardware that the HP 3.6.18 version supports. So the versions should match, also. Please consider this for inclusion. Signed-off-by: Mike Miller [EMAIL PROTECTED] diff --git a/Documentation/cciss.txt b/Documentation/cciss.txt index e65736c..0467639 100644 --- a/Documentation/cciss.txt +++ b/Documentation/cciss.txt @@ -21,6 +21,7 @@ This driver is known to work with the following cards: * SA E200 * SA E200i * SA E500 + * SA P700m Detecting drive failures: - diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index 61bc0f3..6ddf543 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -55,15 +55,15 @@ #include linux/cdrom.h #define CCISS_DRIVER_VERSION(maj,min,submin) ((maj16)|(min8)|(submin)) -#define DRIVER_NAME HP CISS Driver (v 3.6.14) -#define DRIVER_VERSION CCISS_DRIVER_VERSION(3,6,14) +#define DRIVER_NAME HP CISS Driver (v 3.6.18) +#define DRIVER_VERSION CCISS_DRIVER_VERSION(3,6,18) /* Embedded module documentation macros - see modules.h */ MODULE_AUTHOR(Hewlett-Packard Company); -MODULE_DESCRIPTION(Driver for HP Controller SA5xxx SA6xxx version 3.6.14); +MODULE_DESCRIPTION(Driver for HP Controller SA5xxx SA6xxx version 3.6.18); MODULE_SUPPORTED_DEVICE(HP SA5i SA5i+ SA532 SA5300 SA5312 SA641 SA642 SA6400 -SA6i P600 P800 P400 P400i E200 E200i E500); -MODULE_VERSION(3.6.14); +SA6i P600 P800 P400 P400i E200 E200i E500 P700m); +MODULE_VERSION(3.6.18); MODULE_LICENSE(GPL); #include cciss_cmd.h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cciss: update copyright notices
PATCH 1 of 1 This patch updates the copyright information for the cciss driver. It includes extending the year to 2007 (how timely) and some minor corrections deemed necessary by HP legal and the Open Source Review Board. Please consider this patch for inclusion. Signed-off-by: Mike Miller <[EMAIL PROTECTED]> diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index e330c26..cd37e92 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -1,20 +1,20 @@ /* - *Disk Array driver for HP SA 5xxx and 6xxx Controllers - *Copyright 2000, 2006 Hewlett-Packard Development Company, L.P. + *Disk Array driver for HP Smart Array controllers. + *(C) Copyright 2000, 2007 Hewlett-Packard Development Company, L.P. * *This program is free software; you can redistribute it and/or modify *it under the terms of the GNU General Public License as published by - *the Free Software Foundation; either version 2 of the License, or - *(at your option) any later version. + *the Free Software Foundation; version 2 of the License. * *This program is distributed in the hope that it will be useful, *but WITHOUT ANY WARRANTY; without even the implied warranty of - *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or - *NON INFRINGEMENT. See the GNU General Public License for more details. + *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. See the GNU + *General Public License for more details. * *You should have received a copy of the GNU General Public License *along with this program; if not, write to the Free Software - *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + *Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + *02111-1307, USA. * *Questions/Comments/Bugfixes to [EMAIL PROTECTED] * diff --git a/drivers/block/cciss_scsi.c b/drivers/block/cciss_scsi.c index 4aca7dd..63ee6c0 100644 --- a/drivers/block/cciss_scsi.c +++ b/drivers/block/cciss_scsi.c @@ -1,20 +1,20 @@ /* - *Disk Array driver for Compaq SA53xx Controllers, SCSI Tape module - *Copyright 2001 Compaq Computer Corporation + *Disk Array driver for HP Smart Array controllers, SCSI Tape module. + *(C) Copyright 2001, 2007 Hewlett-Packard Development Company, L.P. * *This program is free software; you can redistribute it and/or modify *it under the terms of the GNU General Public License as published by - *the Free Software Foundation; either version 2 of the License, or - *(at your option) any later version. + *the Free Software Foundation; version 2 of the License. * *This program is distributed in the hope that it will be useful, *but WITHOUT ANY WARRANTY; without even the implied warranty of - *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or - *NON INFRINGEMENT. See the GNU General Public License for more details. + *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. See the GNU + *General Public License for more details. * *You should have received a copy of the GNU General Public License *along with this program; if not, write to the Free Software - *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + *Foundation, Inc., 59 Temple Place, Suite 300, Boston, MA + *02111-1307, USA. * *Questions/Comments/Bugfixes to [EMAIL PROTECTED] * diff --git a/drivers/block/cciss_scsi.h b/drivers/block/cciss_scsi.h index 5e7e06c..d9c2c58 100644 --- a/drivers/block/cciss_scsi.h +++ b/drivers/block/cciss_scsi.h @@ -1,20 +1,20 @@ /* - *Disk Array driver for Compaq SA53xx Controllers, SCSI Tape module - *Copyright 2001 Compaq Computer Corporation + *Disk Array driver for HP Smart Array controllers, SCSI Tape module. + *(C) Copyright 2001, 2007 Hewlett-Packard Development Company, L.P. * *This program is free software; you can redistribute it and/or modify *it under the terms of the GNU General Public License as published by - *the Free Software Foundation; either version 2 of the License, or - *(at your option) any later version. + *the Free Software Foundation; version 2 of the License. * *This program is distributed in the hope that it will be useful, *but WITHOUT ANY WARRANTY; without even the implied warranty of - *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or - *NON INFRINGEMENT. See the GNU General Public License for more details. + *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. See the GNU + *General Public License for more details. * *You should have received a copy of the GNU General Public License *along with this program; if not, write to the Free Software - *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + *Foundation, Inc., 59 Temple Place, Suite 300, Bost
[PATCH 1/1] cciss: update copyright notices
PATCH 1 of 1 This patch updates the copyright information for the cciss driver. It includes extending the year to 2007 (how timely) and some minor corrections deemed necessary by HP legal and the Open Source Review Board. Please consider this patch for inclusion. Signed-off-by: Mike Miller [EMAIL PROTECTED] diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index e330c26..cd37e92 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -1,20 +1,20 @@ /* - *Disk Array driver for HP SA 5xxx and 6xxx Controllers - *Copyright 2000, 2006 Hewlett-Packard Development Company, L.P. + *Disk Array driver for HP Smart Array controllers. + *(C) Copyright 2000, 2007 Hewlett-Packard Development Company, L.P. * *This program is free software; you can redistribute it and/or modify *it under the terms of the GNU General Public License as published by - *the Free Software Foundation; either version 2 of the License, or - *(at your option) any later version. + *the Free Software Foundation; version 2 of the License. * *This program is distributed in the hope that it will be useful, *but WITHOUT ANY WARRANTY; without even the implied warranty of - *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or - *NON INFRINGEMENT. See the GNU General Public License for more details. + *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. See the GNU + *General Public License for more details. * *You should have received a copy of the GNU General Public License *along with this program; if not, write to the Free Software - *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + *Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + *02111-1307, USA. * *Questions/Comments/Bugfixes to [EMAIL PROTECTED] * diff --git a/drivers/block/cciss_scsi.c b/drivers/block/cciss_scsi.c index 4aca7dd..63ee6c0 100644 --- a/drivers/block/cciss_scsi.c +++ b/drivers/block/cciss_scsi.c @@ -1,20 +1,20 @@ /* - *Disk Array driver for Compaq SA53xx Controllers, SCSI Tape module - *Copyright 2001 Compaq Computer Corporation + *Disk Array driver for HP Smart Array controllers, SCSI Tape module. + *(C) Copyright 2001, 2007 Hewlett-Packard Development Company, L.P. * *This program is free software; you can redistribute it and/or modify *it under the terms of the GNU General Public License as published by - *the Free Software Foundation; either version 2 of the License, or - *(at your option) any later version. + *the Free Software Foundation; version 2 of the License. * *This program is distributed in the hope that it will be useful, *but WITHOUT ANY WARRANTY; without even the implied warranty of - *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or - *NON INFRINGEMENT. See the GNU General Public License for more details. + *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. See the GNU + *General Public License for more details. * *You should have received a copy of the GNU General Public License *along with this program; if not, write to the Free Software - *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + *Foundation, Inc., 59 Temple Place, Suite 300, Boston, MA + *02111-1307, USA. * *Questions/Comments/Bugfixes to [EMAIL PROTECTED] * diff --git a/drivers/block/cciss_scsi.h b/drivers/block/cciss_scsi.h index 5e7e06c..d9c2c58 100644 --- a/drivers/block/cciss_scsi.h +++ b/drivers/block/cciss_scsi.h @@ -1,20 +1,20 @@ /* - *Disk Array driver for Compaq SA53xx Controllers, SCSI Tape module - *Copyright 2001 Compaq Computer Corporation + *Disk Array driver for HP Smart Array controllers, SCSI Tape module. + *(C) Copyright 2001, 2007 Hewlett-Packard Development Company, L.P. * *This program is free software; you can redistribute it and/or modify *it under the terms of the GNU General Public License as published by - *the Free Software Foundation; either version 2 of the License, or - *(at your option) any later version. + *the Free Software Foundation; version 2 of the License. * *This program is distributed in the hope that it will be useful, *but WITHOUT ANY WARRANTY; without even the implied warranty of - *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, GOOD TITLE or - *NON INFRINGEMENT. See the GNU General Public License for more details. + *MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. See the GNU + *General Public License for more details. * *You should have received a copy of the GNU General Public License *along with this program; if not, write to the Free Software - *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + *Foundation, Inc., 59 Temple Place, Suite 300, Boston, MA
Re: [PATCH 1/1] cciss: fix error reporting for SG_IO
On Fri, Aug 24, 2007 at 05:10:47PM -0700, Andrew Morton wrote: > On Fri, 24 Aug 2007 12:53:54 -0500 > "Mike Miller (OS Dev)" <[EMAIL PROTECTED]> wrote: > > > This fixes a problem with the way cciss was filling out the "errors" > > field of the request structure upon completion of requests. > > Previously, it just put a 1 or a 0 in there and used the negation > > of this as the uptodate parameter to one of the functions in the > > block layer, being a block device. For the SG_IO ioctl, this was not > > sufficient, and we noticed that, for example, sg_turs from sg3_utils > > did not correctly detect problems due to cciss having set rq->errors > > incorrectly. > > Do we think this problem is sufficiently serious to merit merging > this (largeish) patch into 2.6.23? > > I'm thinking "no", but that might be wrong... We'd like to see it 2.6.23. It may help insulate me from lots of questions about where it is. :) But it's entirely up to you. mikem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] cciss: fix error reporting for SG_IO
On Fri, Aug 24, 2007 at 05:10:47PM -0700, Andrew Morton wrote: On Fri, 24 Aug 2007 12:53:54 -0500 Mike Miller (OS Dev) [EMAIL PROTECTED] wrote: This fixes a problem with the way cciss was filling out the errors field of the request structure upon completion of requests. Previously, it just put a 1 or a 0 in there and used the negation of this as the uptodate parameter to one of the functions in the block layer, being a block device. For the SG_IO ioctl, this was not sufficient, and we noticed that, for example, sg_turs from sg3_utils did not correctly detect problems due to cciss having set rq-errors incorrectly. Do we think this problem is sufficiently serious to merit merging this (largeish) patch into 2.6.23? I'm thinking no, but that might be wrong... We'd like to see it 2.6.23. It may help insulate me from lots of questions about where it is. :) But it's entirely up to you. mikem - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cciss: fix error reporting for SG_IO
- Forwarded message from Steve Cameron <[EMAIL PROTECTED]> -
Date: Fri, 24 Aug 2007 11:10:44 -0500
From: Steve Cameron <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [PATCH 1/1] cciss: fix error reporting for SG_IO
This fixes a problem with the way cciss was filling out the "errors"
field of the request structure upon completion of requests.
Previously, it just put a 1 or a 0 in there and used the negation
of this as the uptodate parameter to one of the functions in the
block layer, being a block device. For the SG_IO ioctl, this was not
sufficient, and we noticed that, for example, sg_turs from sg3_utils
did not correctly detect problems due to cciss having set rq->errors
incorrectly.
Signed-off-by: Stephen M. Cameron <[EMAIL PROTECTED]>
Acked-by: Mike Miller <[EMAIL PROTECTED]>
drivers/block/cciss.c | 79 ++
1 files changed, 61 insertions(+), 18 deletions(-)
diff -puN drivers/block/cciss.c~sg_io_fix_error_reporting drivers/block/cciss.c
--- linux-2.6.23-rc2/drivers/block/cciss.c~sg_io_fix_error_reporting
2007-08-13 09:44:58.0 -0500
+++ linux-2.6.23-rc2-scameron/drivers/block/cciss.c 2007-08-24
10:56:56.0 -0500
@@ -2366,30 +2366,55 @@ static inline void resend_cciss_cmd(ctlr
start_io(h);
}
+static inline unsigned int make_status_bytes(unsigned int scsi_status_byte,
+ unsigned int msg_byte, unsigned int host_byte,
+ unsigned int driver_byte)
+{
+ /* inverse of macros in scsi.h */
+ return (scsi_status_byte & 0xff) |
+ ((msg_byte & 0xff) << 8) |
+ ((host_byte & 0xff) << 16) |
+ ((driver_byte & 0xff) << 24);
+}
+
static inline int evaluate_target_status(CommandList_struct *cmd)
{
unsigned char sense_key;
- int error_count = 1;
+ unsigned char status_byte, msg_byte, host_byte, driver_byte;
+ int error_value;
+
+ /* If we get in here, it means we got "target status", that is, scsi
status */
+ status_byte = cmd->err_info->ScsiStatus;
+ driver_byte = DRIVER_OK;
+ msg_byte = cmd->err_info->CommandStatus; /* correct? seems too device
specific */
+
+ if (blk_pc_request(cmd->rq))
+ host_byte = DID_PASSTHROUGH;
+ else
+ host_byte = DID_OK;
+
+ error_value = make_status_bytes(status_byte, msg_byte,
+ host_byte, driver_byte);
- if (cmd->err_info->ScsiStatus != 0x02) { /* not check condition? */
+ if (cmd->err_info->ScsiStatus != SAM_STAT_CHECK_CONDITION) {
if (!blk_pc_request(cmd->rq))
printk(KERN_WARNING "cciss: cmd %p "
"has SCSI Status 0x%x\n",
cmd, cmd->err_info->ScsiStatus);
- return error_count;
+ return error_value;
}
/* check the sense key */
sense_key = 0xf & cmd->err_info->SenseInfo[2];
/* no status or recovered error */
- if ((sense_key == 0x0) || (sense_key == 0x1))
- error_count = 0;
+ if (((sense_key == 0x0) || (sense_key == 0x1)) &&
!blk_pc_request(cmd->rq))
+ error_value = 0;
if (!blk_pc_request(cmd->rq)) { /* Not SG_IO or similar? */
- if (error_count != 0)
+ if (error_value != 0)
printk(KERN_WARNING "cciss: cmd %p has CHECK CONDITION"
" sense key = 0x%x\n", cmd, sense_key);
- return error_count;
+ return error_value;
}
/* SG_IO or similar, copy sense data back */
@@ -2401,7 +2426,7 @@ static inline int evaluate_target_status
} else
cmd->rq->sense_len = 0;
- return error_count;
+ return error_value;
}
/* checks the status of the job and calls complete buffers to mark all
@@ -2417,7 +2442,7 @@ static inline void complete_command(ctlr
rq->errors = 0;
if (timeout)
- rq->errors = 1;
+ rq->errors = make_status_bytes(0, 0, 0, DRIVER_TIMEOUT);
if (cmd->err_info->CommandStatus == 0) /* no error has occurred */
goto after_error_processing;
@@ -2443,32 +2468,44 @@ static inline void complete_command(ctlr
case CMD_INVALID:
printk(KERN_WARNING "cciss: cmd %p is "
"reported invalid\n", cmd);
- rq->errors = 1;
+ rq->errors = make_status_bytes(SAM_STAT_GOOD,
+ cmd->err_info->CommandStatus, DRIVER_OK,
+ blk_pc_request(cmd->rq) ? DID_PASSTHROUGH : DID_ERROR);
[PATCH 1/1] cciss: fix error reporting for SG_IO
- Forwarded message from Steve Cameron [EMAIL PROTECTED] -
Date: Fri, 24 Aug 2007 11:10:44 -0500
From: Steve Cameron [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: [PATCH 1/1] cciss: fix error reporting for SG_IO
This fixes a problem with the way cciss was filling out the errors
field of the request structure upon completion of requests.
Previously, it just put a 1 or a 0 in there and used the negation
of this as the uptodate parameter to one of the functions in the
block layer, being a block device. For the SG_IO ioctl, this was not
sufficient, and we noticed that, for example, sg_turs from sg3_utils
did not correctly detect problems due to cciss having set rq-errors
incorrectly.
Signed-off-by: Stephen M. Cameron [EMAIL PROTECTED]
Acked-by: Mike Miller [EMAIL PROTECTED]
drivers/block/cciss.c | 79 ++
1 files changed, 61 insertions(+), 18 deletions(-)
diff -puN drivers/block/cciss.c~sg_io_fix_error_reporting drivers/block/cciss.c
--- linux-2.6.23-rc2/drivers/block/cciss.c~sg_io_fix_error_reporting
2007-08-13 09:44:58.0 -0500
+++ linux-2.6.23-rc2-scameron/drivers/block/cciss.c 2007-08-24
10:56:56.0 -0500
@@ -2366,30 +2366,55 @@ static inline void resend_cciss_cmd(ctlr
start_io(h);
}
+static inline unsigned int make_status_bytes(unsigned int scsi_status_byte,
+ unsigned int msg_byte, unsigned int host_byte,
+ unsigned int driver_byte)
+{
+ /* inverse of macros in scsi.h */
+ return (scsi_status_byte 0xff) |
+ ((msg_byte 0xff) 8) |
+ ((host_byte 0xff) 16) |
+ ((driver_byte 0xff) 24);
+}
+
static inline int evaluate_target_status(CommandList_struct *cmd)
{
unsigned char sense_key;
- int error_count = 1;
+ unsigned char status_byte, msg_byte, host_byte, driver_byte;
+ int error_value;
+
+ /* If we get in here, it means we got target status, that is, scsi
status */
+ status_byte = cmd-err_info-ScsiStatus;
+ driver_byte = DRIVER_OK;
+ msg_byte = cmd-err_info-CommandStatus; /* correct? seems too device
specific */
+
+ if (blk_pc_request(cmd-rq))
+ host_byte = DID_PASSTHROUGH;
+ else
+ host_byte = DID_OK;
+
+ error_value = make_status_bytes(status_byte, msg_byte,
+ host_byte, driver_byte);
- if (cmd-err_info-ScsiStatus != 0x02) { /* not check condition? */
+ if (cmd-err_info-ScsiStatus != SAM_STAT_CHECK_CONDITION) {
if (!blk_pc_request(cmd-rq))
printk(KERN_WARNING cciss: cmd %p
has SCSI Status 0x%x\n,
cmd, cmd-err_info-ScsiStatus);
- return error_count;
+ return error_value;
}
/* check the sense key */
sense_key = 0xf cmd-err_info-SenseInfo[2];
/* no status or recovered error */
- if ((sense_key == 0x0) || (sense_key == 0x1))
- error_count = 0;
+ if (((sense_key == 0x0) || (sense_key == 0x1))
!blk_pc_request(cmd-rq))
+ error_value = 0;
if (!blk_pc_request(cmd-rq)) { /* Not SG_IO or similar? */
- if (error_count != 0)
+ if (error_value != 0)
printk(KERN_WARNING cciss: cmd %p has CHECK CONDITION
sense key = 0x%x\n, cmd, sense_key);
- return error_count;
+ return error_value;
}
/* SG_IO or similar, copy sense data back */
@@ -2401,7 +2426,7 @@ static inline int evaluate_target_status
} else
cmd-rq-sense_len = 0;
- return error_count;
+ return error_value;
}
/* checks the status of the job and calls complete buffers to mark all
@@ -2417,7 +2442,7 @@ static inline void complete_command(ctlr
rq-errors = 0;
if (timeout)
- rq-errors = 1;
+ rq-errors = make_status_bytes(0, 0, 0, DRIVER_TIMEOUT);
if (cmd-err_info-CommandStatus == 0) /* no error has occurred */
goto after_error_processing;
@@ -2443,32 +2468,44 @@ static inline void complete_command(ctlr
case CMD_INVALID:
printk(KERN_WARNING cciss: cmd %p is
reported invalid\n, cmd);
- rq-errors = 1;
+ rq-errors = make_status_bytes(SAM_STAT_GOOD,
+ cmd-err_info-CommandStatus, DRIVER_OK,
+ blk_pc_request(cmd-rq) ? DID_PASSTHROUGH : DID_ERROR);
break;
case CMD_PROTOCOL_ERR:
printk(KERN_WARNING cciss: cmd %p has
protocol error \n, cmd);
- rq-errors = 1;
+ rq-errors = make_status_bytes(SAM_STAT_GOOD,
+ cmd-err_info-CommandStatus, DRIVER_OK
[PATCH 1/1] cciss: fix error reporting for SG_IO
Patch 1/1
Steve has been trying to send this out but it doesn't seem to be getting
anywhere. Please review this patch for accuracy. There's a couple of things
not clear to us.
Thanks,
mikem
We found a problem with the way cciss was filling out rq->errors.
Previously, it just put a 1 or a 0 in there and used the negation
of this as the uptodate parameter to one of the functions in the
block layer, being a block device.
For the SG_IO support, this is not sufficient, and we noticed
that for example, sg_turs from sg3_utils does not correctly
detect problems due to cciss filling out rq->errors incorrectly.
So, below is my attempt at fixing this, but I'm not completely
sure I did it all right. It is better than before, in that
now sg_turs seems to detect when things go wrong (e.g.:
when a disk is inaccessible due to cables being yanked, it
notices.)
There is some stuff in scsi.h:
> /*
> * Use these to separate status msg and our bytes
> *
> * These are set by:
> *
> * status byte = set from target device
> * msg_byte= return status from host adapter itself.
> * host_byte = set by low-level driver to indicate status.
> * driver_byte = set by mid-level.
> */
> #define status_byte(result) (((result) >> 1) & 0x7f)
> #define msg_byte(result)(((result) >> 8) & 0xff)
> #define host_byte(result) (((result) >> 16) & 0xff)
> #define driver_byte(result) (((result) >> 24) & 0xff)
I'm unsure about the msg_byte (sg_turs appears not to
look at it.) I used a device specific code (cciss
notion of CommandStatus) here. Not sure if that's correct,
but not sure what else I would use. Any clarification on
that would be helpful. And of course, let me know if you
notice anything else I might have screwed up.
-- steve
Signed-off-by: Stephen M. Cameron <[EMAIL PROTECTED]>
---
drivers/block/cciss.c | 81 ++
1 files changed, 63 insertions(+), 18 deletions(-)
diff -puN drivers/block/cciss.c~sg_io_fix_error_reporting drivers/block/cciss.c
--- linux-2.6.23-rc2/drivers/block/cciss.c~sg_io_fix_error_reporting
2007-08-13 09:44:58.0 -0500
+++ linux-2.6.23-rc2-scameron/drivers/block/cciss.c 2007-08-13
09:44:58.0 -0500
@@ -2366,30 +2366,57 @@ static inline void resend_cciss_cmd(ctlr
start_io(h);
}
+/* inverse of macros in scsi.h */
+
+#define shift_status_byte(x) ((x) & 0xff)
+#define shift_msg_byte(x) (((x) & 0xff) << 8)
+#define shift_host_byte(x) (((x) & 0xff) << 16)
+#define shift_driver_byte(x) (((x) & 0xff) << 24)
+
+#define make_status_bytes(s, m, h, d) \
+ shift_status_byte((s)) |\
+ shift_msg_byte((m)) |\
+ shift_host_byte((h)) |\
+shift_driver_byte((d))
+
static inline int evaluate_target_status(CommandList_struct *cmd)
{
unsigned char sense_key;
- int error_count = 1;
+ unsigned char status_byte, msg_byte, host_byte, driver_byte;
+ int error_value;
+
+ /* If we get in here, it means we got "target status", that is, scsi
status */
+ status_byte = cmd->err_info->ScsiStatus;
+ driver_byte = DRIVER_OK;
+ msg_byte = cmd->err_info->CommandStatus; /* correct? seems too device
specific */
+
+ if (blk_pc_request(cmd->rq))
+ host_byte = DID_PASSTHROUGH;
+ else
+ host_byte = DID_OK;
+
+ error_value = make_status_bytes(status_byte, msg_byte,
+ host_byte, driver_byte);
- if (cmd->err_info->ScsiStatus != 0x02) { /* not check condition? */
+ if (cmd->err_info->ScsiStatus != SAM_STAT_CHECK_CONDITION) {
if (!blk_pc_request(cmd->rq))
printk(KERN_WARNING "cciss: cmd %p "
"has SCSI Status 0x%x\n",
cmd, cmd->err_info->ScsiStatus);
- return error_count;
+ return error_value;
}
/* check the sense key */
sense_key = 0xf & cmd->err_info->SenseInfo[2];
/* no status or recovered error */
- if ((sense_key == 0x0) || (sense_key == 0x1))
- error_count = 0;
+ if (((sense_key == 0x0) || (sense_key == 0x1)) &&
!blk_pc_request(cmd->rq))
+ error_value = 0;
if (!blk_pc_request(cmd->rq)) { /* Not SG_IO or similar? */
- if (error_count != 0)
+ if (error_value != 0)
printk(KERN_WARNING "cciss: cmd %p has CHECK CONDITION"
" sense key = 0x%x\n", cmd, sense_key);
- return error_count;
+ return error_value;
}
/* SG_IO or similar, copy sense data back */
@@ -2401,7 +2428,7 @@ static inline int evaluate_target_status
} else
cmd->rq->sense_len = 0;
- return error_count;
+ return error_value;
}
/* checks the status of the
[PATCH 1/1] cciss: fix error reporting for SG_IO
Patch 1/1
Steve has been trying to send this out but it doesn't seem to be getting
anywhere. Please review this patch for accuracy. There's a couple of things
not clear to us.
Thanks,
mikem
We found a problem with the way cciss was filling out rq-errors.
Previously, it just put a 1 or a 0 in there and used the negation
of this as the uptodate parameter to one of the functions in the
block layer, being a block device.
For the SG_IO support, this is not sufficient, and we noticed
that for example, sg_turs from sg3_utils does not correctly
detect problems due to cciss filling out rq-errors incorrectly.
So, below is my attempt at fixing this, but I'm not completely
sure I did it all right. It is better than before, in that
now sg_turs seems to detect when things go wrong (e.g.:
when a disk is inaccessible due to cables being yanked, it
notices.)
There is some stuff in scsi.h:
/*
* Use these to separate status msg and our bytes
*
* These are set by:
*
* status byte = set from target device
* msg_byte= return status from host adapter itself.
* host_byte = set by low-level driver to indicate status.
* driver_byte = set by mid-level.
*/
#define status_byte(result) (((result) 1) 0x7f)
#define msg_byte(result)(((result) 8) 0xff)
#define host_byte(result) (((result) 16) 0xff)
#define driver_byte(result) (((result) 24) 0xff)
I'm unsure about the msg_byte (sg_turs appears not to
look at it.) I used a device specific code (cciss
notion of CommandStatus) here. Not sure if that's correct,
but not sure what else I would use. Any clarification on
that would be helpful. And of course, let me know if you
notice anything else I might have screwed up.
-- steve
Signed-off-by: Stephen M. Cameron [EMAIL PROTECTED]
---
drivers/block/cciss.c | 81 ++
1 files changed, 63 insertions(+), 18 deletions(-)
diff -puN drivers/block/cciss.c~sg_io_fix_error_reporting drivers/block/cciss.c
--- linux-2.6.23-rc2/drivers/block/cciss.c~sg_io_fix_error_reporting
2007-08-13 09:44:58.0 -0500
+++ linux-2.6.23-rc2-scameron/drivers/block/cciss.c 2007-08-13
09:44:58.0 -0500
@@ -2366,30 +2366,57 @@ static inline void resend_cciss_cmd(ctlr
start_io(h);
}
+/* inverse of macros in scsi.h */
+
+#define shift_status_byte(x) ((x) 0xff)
+#define shift_msg_byte(x) (((x) 0xff) 8)
+#define shift_host_byte(x) (((x) 0xff) 16)
+#define shift_driver_byte(x) (((x) 0xff) 24)
+
+#define make_status_bytes(s, m, h, d) \
+ shift_status_byte((s)) |\
+ shift_msg_byte((m)) |\
+ shift_host_byte((h)) |\
+shift_driver_byte((d))
+
static inline int evaluate_target_status(CommandList_struct *cmd)
{
unsigned char sense_key;
- int error_count = 1;
+ unsigned char status_byte, msg_byte, host_byte, driver_byte;
+ int error_value;
+
+ /* If we get in here, it means we got target status, that is, scsi
status */
+ status_byte = cmd-err_info-ScsiStatus;
+ driver_byte = DRIVER_OK;
+ msg_byte = cmd-err_info-CommandStatus; /* correct? seems too device
specific */
+
+ if (blk_pc_request(cmd-rq))
+ host_byte = DID_PASSTHROUGH;
+ else
+ host_byte = DID_OK;
+
+ error_value = make_status_bytes(status_byte, msg_byte,
+ host_byte, driver_byte);
- if (cmd-err_info-ScsiStatus != 0x02) { /* not check condition? */
+ if (cmd-err_info-ScsiStatus != SAM_STAT_CHECK_CONDITION) {
if (!blk_pc_request(cmd-rq))
printk(KERN_WARNING cciss: cmd %p
has SCSI Status 0x%x\n,
cmd, cmd-err_info-ScsiStatus);
- return error_count;
+ return error_value;
}
/* check the sense key */
sense_key = 0xf cmd-err_info-SenseInfo[2];
/* no status or recovered error */
- if ((sense_key == 0x0) || (sense_key == 0x1))
- error_count = 0;
+ if (((sense_key == 0x0) || (sense_key == 0x1))
!blk_pc_request(cmd-rq))
+ error_value = 0;
if (!blk_pc_request(cmd-rq)) { /* Not SG_IO or similar? */
- if (error_count != 0)
+ if (error_value != 0)
printk(KERN_WARNING cciss: cmd %p has CHECK CONDITION
sense key = 0x%x\n, cmd, sense_key);
- return error_count;
+ return error_value;
}
/* SG_IO or similar, copy sense data back */
@@ -2401,7 +2428,7 @@ static inline int evaluate_target_status
} else
cmd-rq-sense_len = 0;
- return error_count;
+ return error_value;
}
/* checks the status of the job and calls complete buffers to mark all
@@ -2417,7 +2444,7 @@ static
[PATCH 1/1] cciss: add new controller support for P700m
PATCH 1/1
This patch adds support for the Smart Array P700m SAS controller. This new
controller will ship Fall 2008. Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..0fcad43 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -87,6 +87,7 @@ static const struct pci_device_id cciss_
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSD, 0x103C, 0x3214},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSD, 0x103C, 0x3215},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSC, 0x103C, 0x3237},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSC, 0x103C, 0x323D},
{PCI_VENDOR_ID_HP, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_RAID << 8, 0x << 8, 0},
{0,}
@@ -119,6 +120,7 @@ static struct board_type products[] = {
{0x3214103C, "Smart Array E200i", _access, 120},
{0x3215103C, "Smart Array E200i", _access, 120},
{0x3237103C, "Smart Array E500", _access, 512},
+ {0x323D103C, "Smart Array P700m", _access, 512},
{0x103C, "Unknown Smart Array", _access, 120},
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cciss: add new controller support for P700m
PATCH 1/1
This patch adds support for the Smart Array P700m SAS controller. This new
controller will ship Fall 2008. Please consider this for inclusion.
Signed-off-by: Mike Miller [EMAIL PROTECTED]
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..0fcad43 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -87,6 +87,7 @@ static const struct pci_device_id cciss_
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSD, 0x103C, 0x3214},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSD, 0x103C, 0x3215},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSC, 0x103C, 0x3237},
+ {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSC, 0x103C, 0x323D},
{PCI_VENDOR_ID_HP, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_RAID 8, 0x 8, 0},
{0,}
@@ -119,6 +120,7 @@ static struct board_type products[] = {
{0x3214103C, Smart Array E200i, SA5_access, 120},
{0x3215103C, Smart Array E200i, SA5_access, 120},
{0x3237103C, Smart Array E500, SA5_access, 512},
+ {0x323D103C, Smart Array P700m, SA5_access, 512},
{0x103C, Unknown Smart Array, SA5_access, 120},
};
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2/4] 2.6.22-rc3: known regressions
On Thu, May 31, 2007 at 03:22:07PM -0700, Linus Torvalds wrote:
>
>
> On Thu, 31 May 2007, Mike Miller (OS Dev) wrote:
>
> > On Wed, May 30, 2007 at 07:22:14PM -0700, Linus Torvalds wrote:
> > >
> > >
> > > On Tue, 29 May 2007, Michal Piotrowski wrote:
> > > >
> > > > Subject: Oops on 2.6.22-rc2 when unloading the cciss driver
> > > > References : http://lkml.org/lkml/2007/5/24/172
> > > > Submitter : Mike Miller (OS Dev) <[EMAIL PROTECTED]>
> > > > Status : Unknown
> > >
> > > I thought this one should be fixed by commit e9ca75b53. Not so?
> >
> > I apologize for the slow response. I also apologize that I don't know enough
> > about git to figure out what commit e9ca75b53 does.
>
> Even without git, you can use the kernel.org gitweb install:
>
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e9ca75b53
>
> (where the "h=" is the magic part - pick any commit SHA1 you want,
> including short-hand ones like the one I gave).
>
> With git, you just do
>
> git show e9ca75b53
>
> to see a particular named commit.
>
> > I submitted a fix that was blessed by Eric B. that fixed that Oops.
>
> Ok, I don't think I have anything like that. The one I pointed to is the
> one by Gerald Britton, acked by you ..
>
> But I now realize that that commit was already in -rc2. In fact, it's just
> before the -rc2 release. So while it claims to fix one oops on shutdown,
> it may be the _cause_ of the oops on mudule unload.
>
> Linus
Linus,
The fix from Gerald was a different Oops and is not related to this problem.
This is the patch I submitted for the rmmod Oops:
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, >msi_list, list) {
if (entry->msi_attrib.type == PCI_CAP_ID_MSIX) {
- if (list_is_last(>list, >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(>list, >msi_list))
+ iounmap(entry->mask_base);
}
list_del(>list);
kfree(entry);
Reference:
http://groups.google.com/group/linux.kernel/browse_frm/thread/ed0949e9d42cfdef/5953daaa00ea5bf7?lnk=gst=cciss=3=en#5953daaa00ea5bf7
I'm not sure what the status is right now.
Thanks,
mikem
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2/4] 2.6.22-rc3: known regressions
On Wed, May 30, 2007 at 07:22:14PM -0700, Linus Torvalds wrote: > > > On Tue, 29 May 2007, Michal Piotrowski wrote: > > > > Subject: Oops on 2.6.22-rc2 when unloading the cciss driver > > References : http://lkml.org/lkml/2007/5/24/172 > > Submitter : Mike Miller (OS Dev) <[EMAIL PROTECTED]> > > Status : Unknown > > I thought this one should be fixed by commit e9ca75b53. Not so? > > Mike? > > Linus I apologize for the slow response. I also apologize that I don't know enough about git to figure out what commit e9ca75b53 does. I submitted a fix that was blessed by Eric B. that fixed that Oops. mikem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/4] 2.6.22-rc3: known regressions
On Wed, May 30, 2007 at 07:22:14PM -0700, Linus Torvalds wrote: On Tue, 29 May 2007, Michal Piotrowski wrote: Subject: Oops on 2.6.22-rc2 when unloading the cciss driver References : http://lkml.org/lkml/2007/5/24/172 Submitter : Mike Miller (OS Dev) [EMAIL PROTECTED] Status : Unknown I thought this one should be fixed by commit e9ca75b53. Not so? Mike? Linus I apologize for the slow response. I also apologize that I don't know enough about git to figure out what commit e9ca75b53 does. I submitted a fix that was blessed by Eric B. that fixed that Oops. mikem - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/4] 2.6.22-rc3: known regressions
On Thu, May 31, 2007 at 03:22:07PM -0700, Linus Torvalds wrote:
On Thu, 31 May 2007, Mike Miller (OS Dev) wrote:
On Wed, May 30, 2007 at 07:22:14PM -0700, Linus Torvalds wrote:
On Tue, 29 May 2007, Michal Piotrowski wrote:
Subject: Oops on 2.6.22-rc2 when unloading the cciss driver
References : http://lkml.org/lkml/2007/5/24/172
Submitter : Mike Miller (OS Dev) [EMAIL PROTECTED]
Status : Unknown
I thought this one should be fixed by commit e9ca75b53. Not so?
I apologize for the slow response. I also apologize that I don't know enough
about git to figure out what commit e9ca75b53 does.
Even without git, you can use the kernel.org gitweb install:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e9ca75b53
(where the h= is the magic part - pick any commit SHA1 you want,
including short-hand ones like the one I gave).
With git, you just do
git show e9ca75b53
to see a particular named commit.
I submitted a fix that was blessed by Eric B. that fixed that Oops.
Ok, I don't think I have anything like that. The one I pointed to is the
one by Gerald Britton, acked by you ..
But I now realize that that commit was already in -rc2. In fact, it's just
before the -rc2 release. So while it claims to fix one oops on shutdown,
it may be the _cause_ of the oops on mudule unload.
Linus
Linus,
The fix from Gerald was a different Oops and is not related to this problem.
This is the patch I submitted for the rmmod Oops:
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);
Reference:
http://groups.google.com/group/linux.kernel/browse_frm/thread/ed0949e9d42cfdef/5953daaa00ea5bf7?lnk=gstq=ccissrnum=3hl=en#5953daaa00ea5bf7
I'm not sure what the status is right now.
Thanks,
mikem
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: msi_free_irqs #2
On Thu, May 24, 2007 at 02:53:08PM -0600, Eric W. Biederman wrote:
>
>
> Could you please try the patch below. Unless I have misread something
> this should fix your problem
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 000c9ae..2e1d4af 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -404,7 +404,7 @@ static int msix_capability_init(struct pci_dev *dev,
> entry->dev = dev;
> entry->mask_base = base;
>
> - list_add(>list, >msi_list);
> + list_add_tail(>list, >msi_list);
> }
>
> ret = arch_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSIX);
>
> > Michael or Eric, would you please review this patch and see if it's OK?
> > Adding
> > an else
> > between the the if (list_is) and the writel resolved the Oops. I'm not
> > sure
> > how this
> > is supposed to work but using entry->mask_base after iounmap'ing seems
> > wrong.
>
> I think I would rather just swap those two lines of code.
> We are manually setting the mask bit to make certain the irq doesn't
> fire after we free it, and we clearly want to set the mask bit for
> all the irq entries.
>
> > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> > index d9cbd58..0e67723 100644
> > --- a/drivers/pci/msi.c
> > +++ b/drivers/pci/msi.c
> > @@ -560,10 +560,11 @@ static int msi_free_irqs(struct pci_dev* dev)
> > if (entry->msi_attrib.type == PCI_CAP_ID_MSIX) {
> > if (list_is_last(>list, >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);
> > + else
> > + writel(1, entry->mask_base
> > + + entry->msi_attrib.entry_nr
> > + * PCI_MSIX_ENTRY_SIZE
> > + + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
> > }
> > list_del(>list);
> > kfree(entry);
Here's a patch that just reverses the 2 lines of code as Eric suggests. Please
consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
Signed-off-by: Chase Maupin <[EMAIL PROTECTED]>
Thanks,
mikem
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, >msi_list, list) {
if (entry->msi_attrib.type == PCI_CAP_ID_MSIX) {
- if (list_is_last(>list, >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(>list, >msi_list))
+ iounmap(entry->mask_base);
}
list_del(>list);
kfree(entry);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: msi_free_irqs #2
On Thu, May 24, 2007 at 02:53:08PM -0600, Eric W. Biederman wrote:
>
>
> Could you please try the patch below. Unless I have misread something
> this should fix your problem
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index 000c9ae..2e1d4af 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -404,7 +404,7 @@ static int msix_capability_init(struct pci_dev *dev,
> entry->dev = dev;
> entry->mask_base = base;
>
> - list_add(>list, >msi_list);
> + list_add_tail(>list, >msi_list);
> }
Yes, this is what we found. But we made 2 changes to list_add. Just sent the
patch.
>
> ret = arch_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSIX);
>
> > Michael or Eric, would you please review this patch and see if it's OK?
> > Adding
> > an else
> > between the the if (list_is) and the writel resolved the Oops. I'm not
> > sure
> > how this
> > is supposed to work but using entry->mask_base after iounmap'ing seems
> > wrong.
>
> I think I would rather just swap those two lines of code.
> We are manually setting the mask bit to make certain the irq doesn't
> fire after we free it, and we clearly want to set the mask bit for
> all the irq entries.
OK, new patch on the way.
mikem
>
> > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> > index d9cbd58..0e67723 100644
> > --- a/drivers/pci/msi.c
> > +++ b/drivers/pci/msi.c
> > @@ -560,10 +560,11 @@ static int msi_free_irqs(struct pci_dev* dev)
> > if (entry->msi_attrib.type == PCI_CAP_ID_MSIX) {
> > if (list_is_last(>list, >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);
> > + else
> > + writel(1, entry->mask_base
> > + + entry->msi_attrib.entry_nr
> > + * PCI_MSIX_ENTRY_SIZE
> > + + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
> > }
> > list_del(>list);
> > kfree(entry);
> > -
> >
> > I hope this clears up a little of the fog.
>
> Yes it does thanks.
>
> Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: msi_free_irqs #2
On Thu, May 24, 2007 at 01:42:58PM -0600, Eric W. Biederman wrote: > Andrew Morton <[EMAIL PROTECTED]> writes: > > > On Thu, 24 May 2007 11:07:56 -0500 > > "Mike Miller (OS Dev)" <[EMAIL PROTECTED]> wrote: > > > >> So I guess I found the answer to my own question. msi_free_irqs was > >> apparently > > added > >> in 2.6.22-something. I don't find it in 2.6.21.2 or anywhere else. So > >> somebody > > broke a > >> couple of things. > >> The most noticable is cciss hangs after turning on interrupts. The reason > >> for > > that is > >> the kernel now looks at my array of MSI-X vectors in reverse order. We > >> have 4 > > ways of > >> generating an interrupt on Smart Array hw. They are: > >> > >> # define DOORBELL_INT 0 > >> # define PERF_MODE_INT1 > >> # define SIMPLE_MODE_INT 2 > >> # define MEMQ_MODE_INT3 > >> > >> For INTx these four lines are OR'ed together and run to one interrupt > > pin. MSI-X > >> breaks this hardware OR'ing so we must register either all 4 or at the > >> least > > the > >> correct interrupt. When I first submitted the MSI/X support I was > >> registering > > all 4. > >> Someone changed that to only register a single MSI-X vector. That worked > >> fine > > until > >> 2.6.22-something. > >> Now it appears that the kernel is looking at the array in reverse order. > >> IOW, > > I must > >> register PERF_MODE_INT in order for cciss to work. That's messed up. > >> Anybody > > want to > >> `fess up to making these changes? :) > >> I'll keep working this, but I'm going to undo someones change when I figure > > out where > >> it's broke. > >> > > > > I'd guess that you're referring to Michael's changes. If you can identify > > the offending code in a less vague fashion, more confident answers can > > be given ;) > > > > I canot find any sign of anyone altering the IRQ handling in cciss.c after > > your initial MSI-support merge. But that's perhaps isn't what you meant. > > it's all rather foggy. Please either quote file-n-line, or grab a copy > > of git-blame. > > Or perhaps git-bisect to find the offending patch. > > I don't recall seeing anything that looked to bad but there was a fair > amount of change needed to get the last bit of portability into the msi > code, so it is possible something slipped through. > > Possibly someone changed the default enable or disable state? > > > > Which reminds me. Now that we have a reasonable list, we really need > to reduce pci_enable_msix: > > - int pci_enable_msix(struct pci_dev* dev, struct msix_entry *entries, int > nvec); > + int pci_enable_msix(struct pci_dev* dev, int nvec); > > And just have drivers that use more the one irq walk the list off of pci_dev > of all of the msi irqs. I did a little review a while ago and only > 0-(nvec -1) are allocated and the are always in order in entries so it > shouldn't be to bad to generate a patch for that case, and not having > to worry about out of order or holes in the irq allocator would be > good. > > Eric 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. 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(>list, >msi_list); + list_add_tail(>list, >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(>list, >msi_list); + list_add_tail(>list, >msi_list); } ret = arch_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSIX); This patch undoes my dirty little hack. diff --git a/drivers/block/cciss.h b/drivers/block/cciss.h index 26b5866..b70988d 100644 --- a/drivers/block/cciss.h +++ b/drivers/block/cciss.h @@ -70,8 +70,8 @@ struct ctlr_info int highest_lun; int usage_count; /* number of opens all all minor devices */ # define DOORBELL_INT 0 -# define PERF_MODE_INT2 -# define SIMPLE_MODE_INT 1 +# define PERF_MODE_INT1 +# define SIMPLE_MODE_INT 2 # define MEMQ_MODE_INT3 unsigned int intr[4]; unsigned int msix_vector; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: msi_free_irqs #2
On Thu, May 24, 2007 at 10:27:02AM -0700, Andrew Morton wrote:
> On Thu, 24 May 2007 11:07:56 -0500
> "Mike Miller (OS Dev)" <[EMAIL PROTECTED]> wrote:
>
> > So I guess I found the answer to my own question. msi_free_irqs was
> > apparently added
> > in 2.6.22-something. I don't find it in 2.6.21.2 or anywhere else. So
> > somebody broke a
> > couple of things.
> > The most noticable is cciss hangs after turning on interrupts. The reason
> > for that is
> > the kernel now looks at my array of MSI-X vectors in reverse order. We have
> > 4 ways of
> > generating an interrupt on Smart Array hw. They are:
> >
> > # define DOORBELL_INT 0
> > # define PERF_MODE_INT1
> > # define SIMPLE_MODE_INT 2
> > # define MEMQ_MODE_INT3
> >
I apologize for the vagueness of the message. This dirty hack makes cciss work
in the
.22-rc kernel. I have not yet figured out what broke.
-
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..7383483 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -3494,7 +3494,7 @@ static void cciss_shutdown(struct pci_dev *pdev)
} else {
printk(KERN_WARNING "Error flushing cache on controller %d\n",
i);
}
- free_irq(hba[i]->intr[2], hba[i]);
+ free_irq(hba[i]->intr[SIMPLE_MODE_INT], hba[i]);
}
static void __devexit cciss_remove_one(struct pci_dev *pdev)
diff --git a/drivers/block/cciss.h b/drivers/block/cciss.h
index b70988d..26b5866 100644
--- a/drivers/block/cciss.h
+++ b/drivers/block/cciss.h
@@ -70,8 +70,8 @@ struct ctlr_info
int highest_lun;
int usage_count; /* number of opens all all minor devices */
# define DOORBELL_INT 0
-# define PERF_MODE_INT1
-# define SIMPLE_MODE_INT 2
+# define PERF_MODE_INT2
+# define SIMPLE_MODE_INT 1
# define MEMQ_MODE_INT3
unsigned int intr[4];
unsigned int msix_vector;
-
> > For INTx these four lines are OR'ed together and run to one interrupt pin.
> > MSI-X
> > breaks this hardware OR'ing so we must register either all 4 or at the
> > least the
> > correct interrupt. When I first submitted the MSI/X support I was
> > registering all 4.
> > Someone changed that to only register a single MSI-X vector. That worked
> > fine until
> > 2.6.22-something.
> > Now it appears that the kernel is looking at the array in reverse order.
> > IOW, I must
> > register PERF_MODE_INT in order for cciss to work. That's messed up.
> > Anybody want to
Have not yet found the change that caused this but my nasty little hack gets
around it
for my testing. After I return from the long weekend I'll try to hunt this down.
> > `fess up to making these changes? :)
> > I'll keep working this, but I'm going to undo someones change when I figure
> > out where
> > it's broke.
> >
>
> I'd guess that you're referring to Michael's changes. If you can identify
> the offending code in a less vague fashion, more confident answers can
> be given ;)
>
> I canot find any sign of anyone altering the IRQ handling in cciss.c after
> your initial MSI-support merge. But that's perhaps isn't what you meant.
> it's all rather foggy. Please either quote file-n-line, or grab a copy
> of git-blame.
Now for my original mail where the driver Oops'ed on rmmod. This patch prevents
the
Oops but I'm not 100% sure it's right. Here's the Oops:
Completed flushing cache on controller 2
BUG: unable to handle kernel paging request at virtual address f8b2200c
printing eip:
c01e9cc7
*pdpt = 3001
*pde = 37e48067
*pte =
Oops: 0002 [#1]
SMP
Modules linked in: cciss ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core
sunrpc loop dm_multipath button battery asus_acpi ac tg3 floppy sg dm_snapshot
dm_zero dm_mirror ext3 jbd dm_mod ata_piix libata mptsas scsi_transport_sas
mptspi scsi_transport_spi mptscsih mptbase sd_mod scsi_mod
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286 (2.6.22-rc2-gd2579053 #1)
EIP is at msi_free_irqs+0x81/0xbe
eax: f8b22000 ebx: f71f3180 ecx: f7fff280 edx: c1886eb8
esi: f7c4e800 edi: f7c4ec48 ebp: 0002 esp: f5a0dec8
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process rmmod (pid: 5286, ti=f5a0d000 task=c47d2550 task.ti=f5a0d000)
Stack: 0002 f8b72294 0400 f8b69ca7 f8b6bc6c 0002
f5a997f4 f8b69d61 f7c5a4b0 f7c4e848 f7c4e848
f7c4e800 f7c4e800 f8b72294 f7c4e848 f8b72294 c01e3cdf
msi_free_irqs #2
So I guess I found the answer to my own question. msi_free_irqs was apparently added in 2.6.22-something. I don't find it in 2.6.21.2 or anywhere else. So somebody broke a couple of things. The most noticable is cciss hangs after turning on interrupts. The reason for that is the kernel now looks at my array of MSI-X vectors in reverse order. We have 4 ways of generating an interrupt on Smart Array hw. They are: # define DOORBELL_INT 0 # define PERF_MODE_INT1 # define SIMPLE_MODE_INT 2 # define MEMQ_MODE_INT3 For INTx these four lines are OR'ed together and run to one interrupt pin. MSI-X breaks this hardware OR'ing so we must register either all 4 or at the least the correct interrupt. When I first submitted the MSI/X support I was registering all 4. Someone changed that to only register a single MSI-X vector. That worked fine until 2.6.22-something. Now it appears that the kernel is looking at the array in reverse order. IOW, I must register PERF_MODE_INT in order for cciss to work. That's messed up. Anybody want to `fess up to making these changes? :) I'll keep working this, but I'm going to undo someones change when I figure out where it's broke. mikem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
msi_free_irqs
Hello,
I'm hitting the following Oops on 2.6.22-rc2 when unloading the cciss driver.
Completed flushing cache on controller 2
BUG: unable to handle kernel paging request at virtual address f889a00c
printing eip:
c01e744f
*pdpt = 3001
*pde = 37e09067
*pte =
Oops: 0002 [#1]
SMP
Modules linked in: ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core sunrpc
loop dm_multipath button battery asus_acpi ac uhci_hcd ehci_hcd rng_core tg3
floppy sg dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod ata_piix libata cciss
mptsas scsi_transport_sas mptspi scsi_transport_spi mptscsih mptbase sd_mod
scsi_mod
CPU:2
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286 (2.6.22-rc1plain-gd3a36fb8-dirty #2)
EIP is at msi_free_irqs+0x81/0xbe
eax: f889a000 ebx: f7662ac0 ecx: f7fff280 edx: c18bdeb8
esi: f7c4b800 edi: f7c4bc48 ebp: 0002 esp: f5a53e98
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process rmmod (pid: 5283, ti=f5a53000 task=f7372550 task.ti=f5a53000)
Stack: 0004 f88bb094 f76ecbd8 f88b2d1c f88b4cb8 0002
f88bb094 c03100e1 0001 f7c4b800 f7c4b800
f88bb094 f7c4b848 f88bb094 c01e30ab c01e3093 c01e3093 f7c4b848 c024ab3a
Call Trace:
[] cciss_remove_one+0x145/0x229 [cciss]
[] mutex_lock+0x19/0x29
[] pci_device_remove+0x18/0x39
[] pci_device_remove+0x0/0x39
[] pci_device_remove+0x0/0x39
[] __device_release_driver+0x72/0x91
[] driver_detach+0xa6/0xe7
[] bus_remove_driver+0x29/0x47
[] pci_unregister_driver+0xd/0x17
[] cciss_cleanup+0xf/0x51 [cciss]
[] sys_delete_module+0x115/0x13a
[] remove_vma_list+0x40/0x4a
[] sysenter_past_esp+0x5f/0x85
===
Code: 00 39 c2 74 5d 0f b6 03 24 1f 3c 11 75 24 8d 86 54 04 00 00 39 43 0c 75
08 8b 43 14 e8 1c e1 f2 ff 0f b7 43 02 c1 e0 04 03 43 14 40 0c 01 00 00 00
8d 4b 0c 8b 43 0c 8b 51 04 89 50 04 89 02
EIP: [] msi_free_irqs+0x81/0xbe SS:ESP 0068:f5a53e98
BUG: sleeping function called from invalid context at kernel/rwsem.c:20
in_atomic():0, irqs_disabled():1
[] __might_sleep+0xa7/0xad
[] down_read+0x14/0x29
[] acct_collect+0x35/0x12e
[] do_exit+0x198/0x37e
[] die+0x1c4/0x1cc
[] do_page_fault+0x5b9/0x69c
[] unmap_vm_area+0xad/0xd4
[] flush_tlb_all+0x1b/0x1f
[] do_page_fault+0x0/0x69c
[] error_code+0x72/0x78
[] msi_free_irqs+0x81/0xbe
[] cciss_remove_one+0x145/0x229 [cciss]
[] mutex_lock+0x19/0x29
[] pci_device_remove+0x18/0x39
[] pci_device_remove+0x0/0x39
[] pci_device_remove+0x0/0x39
[] __device_release_driver+0x72/0x91
[] driver_detach+0xa6/0xe7
[] bus_remove_driver+0x29/0x47
[] pci_unregister_driver+0xd/0x17
[] cciss_cleanup+0xf/0x51 [cciss]
[] sys_delete_module+0x115/0x13a
[] remove_vma_list+0x40/0x4a
[] sysenter_past_esp+0x5f/0x85
===
It looks like its going south in drivers/pci/msi.c in msi_free_irqs. When did
this
change appear? I'm Googling and can't find when this was actually added, just
some
activity for Sparc64.
Any help is appreciated.
Thanks,
mikem
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
msi_free_irqs
Hello,
I'm hitting the following Oops on 2.6.22-rc2 when unloading the cciss driver.
Completed flushing cache on controller 2
BUG: unable to handle kernel paging request at virtual address f889a00c
printing eip:
c01e744f
*pdpt = 3001
*pde = 37e09067
*pte =
Oops: 0002 [#1]
SMP
Modules linked in: ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core sunrpc
loop dm_multipath button battery asus_acpi ac uhci_hcd ehci_hcd rng_core tg3
floppy sg dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod ata_piix libata cciss
mptsas scsi_transport_sas mptspi scsi_transport_spi mptscsih mptbase sd_mod
scsi_mod
CPU:2
EIP:0060:[c01e744f]Not tainted VLI
EFLAGS: 00010286 (2.6.22-rc1plain-gd3a36fb8-dirty #2)
EIP is at msi_free_irqs+0x81/0xbe
eax: f889a000 ebx: f7662ac0 ecx: f7fff280 edx: c18bdeb8
esi: f7c4b800 edi: f7c4bc48 ebp: 0002 esp: f5a53e98
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process rmmod (pid: 5283, ti=f5a53000 task=f7372550 task.ti=f5a53000)
Stack: 0004 f88bb094 f76ecbd8 f88b2d1c f88b4cb8 0002
f88bb094 c03100e1 0001 f7c4b800 f7c4b800
f88bb094 f7c4b848 f88bb094 c01e30ab c01e3093 c01e3093 f7c4b848 c024ab3a
Call Trace:
[f88b2d1c] cciss_remove_one+0x145/0x229 [cciss]
[c03100e1] mutex_lock+0x19/0x29
[c01e30ab] pci_device_remove+0x18/0x39
[c01e3093] pci_device_remove+0x0/0x39
[c01e3093] pci_device_remove+0x0/0x39
[c024ab3a] __device_release_driver+0x72/0x91
[c024ac4b] driver_detach+0xa6/0xe7
[c024a2fd] bus_remove_driver+0x29/0x47
[c01e32da] pci_unregister_driver+0xd/0x17
[f88b330f] cciss_cleanup+0xf/0x51 [cciss]
[c0137dab] sys_delete_module+0x115/0x13a
[c01546f4] remove_vma_list+0x40/0x4a
[c01030a2] sysenter_past_esp+0x5f/0x85
===
Code: 00 39 c2 74 5d 0f b6 03 24 1f 3c 11 75 24 8d 86 54 04 00 00 39 43 0c 75
08 8b 43 14 e8 1c e1 f2 ff 0f b7 43 02 c1 e0 04 03 43 14 c7 40 0c 01 00 00 00
8d 4b 0c 8b 43 0c 8b 51 04 89 50 04 89 02
EIP: [c01e744f] msi_free_irqs+0x81/0xbe SS:ESP 0068:f5a53e98
BUG: sleeping function called from invalid context at kernel/rwsem.c:20
in_atomic():0, irqs_disabled():1
[c011ab8b] __might_sleep+0xa7/0xad
[c01302cc] down_read+0x14/0x29
[c013bca7] acct_collect+0x35/0x12e
[c011f903] do_exit+0x198/0x37e
[c010439b] die+0x1c4/0x1cc
[c0312454] do_page_fault+0x5b9/0x69c
[c0156fed] unmap_vm_area+0xad/0xd4
[c01108c3] flush_tlb_all+0x1b/0x1f
[c0311e9b] do_page_fault+0x0/0x69c
[c0310ba2] error_code+0x72/0x78
[c01e744f] msi_free_irqs+0x81/0xbe
[f88b2d1c] cciss_remove_one+0x145/0x229 [cciss]
[c03100e1] mutex_lock+0x19/0x29
[c01e30ab] pci_device_remove+0x18/0x39
[c01e3093] pci_device_remove+0x0/0x39
[c01e3093] pci_device_remove+0x0/0x39
[c024ab3a] __device_release_driver+0x72/0x91
[c024ac4b] driver_detach+0xa6/0xe7
[c024a2fd] bus_remove_driver+0x29/0x47
[c01e32da] pci_unregister_driver+0xd/0x17
[f88b330f] cciss_cleanup+0xf/0x51 [cciss]
[c0137dab] sys_delete_module+0x115/0x13a
[c01546f4] remove_vma_list+0x40/0x4a
[c01030a2] sysenter_past_esp+0x5f/0x85
===
It looks like its going south in drivers/pci/msi.c in msi_free_irqs. When did
this
change appear? I'm Googling and can't find when this was actually added, just
some
activity for Sparc64.
Any help is appreciated.
Thanks,
mikem
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
msi_free_irqs #2
So I guess I found the answer to my own question. msi_free_irqs was apparently added in 2.6.22-something. I don't find it in 2.6.21.2 or anywhere else. So somebody broke a couple of things. The most noticable is cciss hangs after turning on interrupts. The reason for that is the kernel now looks at my array of MSI-X vectors in reverse order. We have 4 ways of generating an interrupt on Smart Array hw. They are: # define DOORBELL_INT 0 # define PERF_MODE_INT1 # define SIMPLE_MODE_INT 2 # define MEMQ_MODE_INT3 For INTx these four lines are OR'ed together and run to one interrupt pin. MSI-X breaks this hardware OR'ing so we must register either all 4 or at the least the correct interrupt. When I first submitted the MSI/X support I was registering all 4. Someone changed that to only register a single MSI-X vector. That worked fine until 2.6.22-something. Now it appears that the kernel is looking at the array in reverse order. IOW, I must register PERF_MODE_INT in order for cciss to work. That's messed up. Anybody want to `fess up to making these changes? :) I'll keep working this, but I'm going to undo someones change when I figure out where it's broke. mikem - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: msi_free_irqs #2
On Thu, May 24, 2007 at 10:27:02AM -0700, Andrew Morton wrote:
On Thu, 24 May 2007 11:07:56 -0500
Mike Miller (OS Dev) [EMAIL PROTECTED] wrote:
So I guess I found the answer to my own question. msi_free_irqs was
apparently added
in 2.6.22-something. I don't find it in 2.6.21.2 or anywhere else. So
somebody broke a
couple of things.
The most noticable is cciss hangs after turning on interrupts. The reason
for that is
the kernel now looks at my array of MSI-X vectors in reverse order. We have
4 ways of
generating an interrupt on Smart Array hw. They are:
# define DOORBELL_INT 0
# define PERF_MODE_INT1
# define SIMPLE_MODE_INT 2
# define MEMQ_MODE_INT3
I apologize for the vagueness of the message. This dirty hack makes cciss work
in the
.22-rc kernel. I have not yet figured out what broke.
-
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..7383483 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -3494,7 +3494,7 @@ static void cciss_shutdown(struct pci_dev *pdev)
} else {
printk(KERN_WARNING Error flushing cache on controller %d\n,
i);
}
- free_irq(hba[i]-intr[2], hba[i]);
+ free_irq(hba[i]-intr[SIMPLE_MODE_INT], hba[i]);
}
static void __devexit cciss_remove_one(struct pci_dev *pdev)
diff --git a/drivers/block/cciss.h b/drivers/block/cciss.h
index b70988d..26b5866 100644
--- a/drivers/block/cciss.h
+++ b/drivers/block/cciss.h
@@ -70,8 +70,8 @@ struct ctlr_info
int highest_lun;
int usage_count; /* number of opens all all minor devices */
# define DOORBELL_INT 0
-# define PERF_MODE_INT1
-# define SIMPLE_MODE_INT 2
+# define PERF_MODE_INT2
+# define SIMPLE_MODE_INT 1
# define MEMQ_MODE_INT3
unsigned int intr[4];
unsigned int msix_vector;
-
For INTx these four lines are OR'ed together and run to one interrupt pin.
MSI-X
breaks this hardware OR'ing so we must register either all 4 or at the
least the
correct interrupt. When I first submitted the MSI/X support I was
registering all 4.
Someone changed that to only register a single MSI-X vector. That worked
fine until
2.6.22-something.
Now it appears that the kernel is looking at the array in reverse order.
IOW, I must
register PERF_MODE_INT in order for cciss to work. That's messed up.
Anybody want to
Have not yet found the change that caused this but my nasty little hack gets
around it
for my testing. After I return from the long weekend I'll try to hunt this down.
`fess up to making these changes? :)
I'll keep working this, but I'm going to undo someones change when I figure
out where
it's broke.
I'd guess that you're referring to Michael's changes. If you can identify
the offending code in a less vague fashion, more confident answers can
be given ;)
I canot find any sign of anyone altering the IRQ handling in cciss.c after
your initial MSI-support merge. But that's perhaps isn't what you meant.
it's all rather foggy. Please either quote file-n-line, or grab a copy
of git-blame.
Now for my original mail where the driver Oops'ed on rmmod. This patch prevents
the
Oops but I'm not 100% sure it's right. Here's the Oops:
Completed flushing cache on controller 2
BUG: unable to handle kernel paging request at virtual address f8b2200c
printing eip:
c01e9cc7
*pdpt = 3001
*pde = 37e48067
*pte =
Oops: 0002 [#1]
SMP
Modules linked in: cciss ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core
sunrpc loop dm_multipath button battery asus_acpi ac tg3 floppy sg dm_snapshot
dm_zero dm_mirror ext3 jbd dm_mod ata_piix libata mptsas scsi_transport_sas
mptspi scsi_transport_spi mptscsih mptbase sd_mod scsi_mod
CPU:1
EIP:0060:[c01e9cc7]Not tainted VLI
EFLAGS: 00010286 (2.6.22-rc2-gd2579053 #1)
EIP is at msi_free_irqs+0x81/0xbe
eax: f8b22000 ebx: f71f3180 ecx: f7fff280 edx: c1886eb8
esi: f7c4e800 edi: f7c4ec48 ebp: 0002 esp: f5a0dec8
ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
Process rmmod (pid: 5286, ti=f5a0d000 task=c47d2550 task.ti=f5a0d000)
Stack: 0002 f8b72294 0400 f8b69ca7 f8b6bc6c 0002
f5a997f4 f8b69d61 f7c5a4b0 f7c4e848 f7c4e848
f7c4e800 f7c4e800 f8b72294 f7c4e848 f8b72294 c01e3cdf f7c4e848 c024c469
Call Trace:
[f8b69ca7] cciss_shutdown+0xae/0xc3 [cciss]
[f8b69d61] cciss_remove_one+0xa5/0x178 [cciss]
[c01e3cdf] pci_device_remove+0x16/0x35
[c024c469] __device_release_driver+0x71/0x8e
[c024c56e] driver_detach+0xa0/0xde
[c024bc5c] bus_remove_driver+0x27/0x41
[c01e3ef3] pci_unregister_driver+0xb/0x13
[f8b6a343] cciss_cleanup+0xf
Re: msi_free_irqs #2
On Thu, May 24, 2007 at 01:42:58PM -0600, Eric W. Biederman wrote: Andrew Morton [EMAIL PROTECTED] writes: On Thu, 24 May 2007 11:07:56 -0500 Mike Miller (OS Dev) [EMAIL PROTECTED] wrote: So I guess I found the answer to my own question. msi_free_irqs was apparently added in 2.6.22-something. I don't find it in 2.6.21.2 or anywhere else. So somebody broke a couple of things. The most noticable is cciss hangs after turning on interrupts. The reason for that is the kernel now looks at my array of MSI-X vectors in reverse order. We have 4 ways of generating an interrupt on Smart Array hw. They are: # define DOORBELL_INT 0 # define PERF_MODE_INT1 # define SIMPLE_MODE_INT 2 # define MEMQ_MODE_INT3 For INTx these four lines are OR'ed together and run to one interrupt pin. MSI-X breaks this hardware OR'ing so we must register either all 4 or at the least the correct interrupt. When I first submitted the MSI/X support I was registering all 4. Someone changed that to only register a single MSI-X vector. That worked fine until 2.6.22-something. Now it appears that the kernel is looking at the array in reverse order. IOW, I must register PERF_MODE_INT in order for cciss to work. That's messed up. Anybody want to `fess up to making these changes? :) I'll keep working this, but I'm going to undo someones change when I figure out where it's broke. I'd guess that you're referring to Michael's changes. If you can identify the offending code in a less vague fashion, more confident answers can be given ;) I canot find any sign of anyone altering the IRQ handling in cciss.c after your initial MSI-support merge. But that's perhaps isn't what you meant. it's all rather foggy. Please either quote file-n-line, or grab a copy of git-blame. Or perhaps git-bisect to find the offending patch. I don't recall seeing anything that looked to bad but there was a fair amount of change needed to get the last bit of portability into the msi code, so it is possible something slipped through. Possibly someone changed the default enable or disable state? Which reminds me. Now that we have a reasonable list, we really need to reduce pci_enable_msix: - int pci_enable_msix(struct pci_dev* dev, struct msix_entry *entries, int nvec); + int pci_enable_msix(struct pci_dev* dev, int nvec); And just have drivers that use more the one irq walk the list off of pci_dev of all of the msi irqs. I did a little review a while ago and only 0-(nvec -1) are allocated and the are always in order in entries so it shouldn't be to bad to generate a patch for that case, and not having to worry about out of order or holes in the irq allocator would be good. Eric 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. 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 undoes my dirty little hack. diff --git a/drivers/block/cciss.h b/drivers/block/cciss.h index 26b5866..b70988d 100644 --- a/drivers/block/cciss.h +++ b/drivers/block/cciss.h @@ -70,8 +70,8 @@ struct ctlr_info int highest_lun; int usage_count; /* number of opens all all minor devices */ # define DOORBELL_INT 0 -# define PERF_MODE_INT2 -# define SIMPLE_MODE_INT 1 +# define PERF_MODE_INT1 +# define SIMPLE_MODE_INT 2 # define MEMQ_MODE_INT3 unsigned int intr[4]; unsigned int msix_vector; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: msi_free_irqs #2
On Thu, May 24, 2007 at 02:53:08PM -0600, Eric W. Biederman wrote:
Could you please try the patch below. Unless I have misread something
this should fix your problem
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 000c9ae..2e1d4af 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -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);
}
Yes, this is what we found. But we made 2 changes to list_add. Just sent the
patch.
ret = arch_setup_msi_irqs(dev, nvec, PCI_CAP_ID_MSIX);
Michael or Eric, would you please review this patch and see if it's OK?
Adding
an else
between the the if (list_is) and the writel resolved the Oops. I'm not
sure
how this
is supposed to work but using entry-mask_base after iounmap'ing seems
wrong.
I think I would rather just swap those two lines of code.
We are manually setting the mask bit to make certain the irq doesn't
fire after we free it, and we clearly want to set the mask bit for
all the irq entries.
OK, new patch on the way.
mikem
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index d9cbd58..0e67723 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -560,10 +560,11 @@ static int msi_free_irqs(struct pci_dev* dev)
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);
+ else
+ writel(1, entry-mask_base
+ + entry-msi_attrib.entry_nr
+ * PCI_MSIX_ENTRY_SIZE
+ + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
}
list_del(entry-list);
kfree(entry);
-
I hope this clears up a little of the fog.
Yes it does thanks.
Eric
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: msi_free_irqs #2
On Thu, May 24, 2007 at 02:53:08PM -0600, Eric W. Biederman wrote:
Could you please try the patch below. Unless I have misread something
this should fix your problem
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 000c9ae..2e1d4af 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -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);
Michael or Eric, would you please review this patch and see if it's OK?
Adding
an else
between the the if (list_is) and the writel resolved the Oops. I'm not
sure
how this
is supposed to work but using entry-mask_base after iounmap'ing seems
wrong.
I think I would rather just swap those two lines of code.
We are manually setting the mask bit to make certain the irq doesn't
fire after we free it, and we clearly want to set the mask bit for
all the irq entries.
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index d9cbd58..0e67723 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -560,10 +560,11 @@ static int msi_free_irqs(struct pci_dev* dev)
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);
+ else
+ writel(1, entry-mask_base
+ + entry-msi_attrib.entry_nr
+ * PCI_MSIX_ENTRY_SIZE
+ + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
}
list_del(entry-list);
kfree(entry);
Here's a patch that just reverses the 2 lines of code as Eric suggests. Please
consider this for inclusion.
Signed-off-by: Mike Miller [EMAIL PROTECTED]
Signed-off-by: Chase Maupin [EMAIL PROTECTED]
Thanks,
mikem
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);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cciss: Fix pci_driver.shutdown while device is still active
On Mon, 2007-05-14 at 17:53 +, Gerald Britton wrote:
> 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.
>
> 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.
Sorry I've taken so long to reply. I've been testing this patch with up
to 512 logical volumes. Looks good. I may make a tweak or 2 after it's
merged, I have other changes that touch the same code.
ACKed-by: Mike Miller <[EMAIL PROTECTED]>
>
> 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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] cciss: Fix pci_driver.shutdown while device is still active
On Mon, 2007-05-14 at 17:53 +, Gerald Britton wrote:
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.
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.
Sorry I've taken so long to reply. I've been testing this patch with up
to 512 logical volumes. Looks good. I may make a tweak or 2 after it's
merged, I have other changes that touch the same code.
ACKed-by: Mike Miller [EMAIL PROTECTED]
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-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cciss: kconfig patch to make cciss dependent on scsi for SG_IO ioctl
PATCH 1/1 This kconfig patch makes cciss dependent on scsi for the new SG_IO ioctl we just added. If cciss is built into the kernel it makes sures that scsi is also statically linked. If scsi is a module then cciss will also be built as a module. Please consider this for inclusion. Signed-off-by: Stephen M. Cameron <[EMAIL PROTECTED]> Signed-off-by: Mike Miller <[EMAIL PROTECTED]> -- block/cciss.c |0 drivers/block/Kconfig |2 +- 2 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/block/cciss.c~cciss_sg_io_kconfig drivers/block/cciss.c diff -puN drivers/block/Kconfig~cciss_sg_io_kconfig drivers/block/Kconfig --- linux-2.6.21-rc6/drivers/block/Kconfig~cciss_sg_io_kconfig 2007-04-12 08:16:45.0 -0500 +++ linux-2.6.21-rc6-scameron/drivers/block/Kconfig 2007-04-12 08:20:41.0 -0500 @@ -152,6 +152,7 @@ config BLK_CPQ_DA config BLK_CPQ_CISS_DA tristate "Compaq Smart Array 5xxx support" depends on PCI + depends on SCSI help This is the driver for Compaq Smart Array 5xxx controllers. Everyone using these boards should say Y here. @@ -162,7 +163,6 @@ config BLK_CPQ_CISS_DA config CISS_SCSI_TAPE bool "SCSI tape drive support for Smart Array 5xxx" depends on BLK_CPQ_CISS_DA && PROC_FS - depends on SCSI=y || SCSI=BLK_CPQ_CISS_DA help When enabled (Y), this option allows SCSI tape drives and SCSI medium changers (tape robots) to be accessed via a Compaq 5xxx array _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] cciss: kconfig patch to make cciss dependent on scsi for SG_IO ioctl
PATCH 1/1 This kconfig patch makes cciss dependent on scsi for the new SG_IO ioctl we just added. If cciss is built into the kernel it makes sures that scsi is also statically linked. If scsi is a module then cciss will also be built as a module. Please consider this for inclusion. Signed-off-by: Stephen M. Cameron [EMAIL PROTECTED] Signed-off-by: Mike Miller [EMAIL PROTECTED] -- block/cciss.c |0 drivers/block/Kconfig |2 +- 2 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/block/cciss.c~cciss_sg_io_kconfig drivers/block/cciss.c diff -puN drivers/block/Kconfig~cciss_sg_io_kconfig drivers/block/Kconfig --- linux-2.6.21-rc6/drivers/block/Kconfig~cciss_sg_io_kconfig 2007-04-12 08:16:45.0 -0500 +++ linux-2.6.21-rc6-scameron/drivers/block/Kconfig 2007-04-12 08:20:41.0 -0500 @@ -152,6 +152,7 @@ config BLK_CPQ_DA config BLK_CPQ_CISS_DA tristate Compaq Smart Array 5xxx support depends on PCI + depends on SCSI help This is the driver for Compaq Smart Array 5xxx controllers. Everyone using these boards should say Y here. @@ -162,7 +163,6 @@ config BLK_CPQ_CISS_DA config CISS_SCSI_TAPE bool SCSI tape drive support for Smart Array 5xxx depends on BLK_CPQ_CISS_DA PROC_FS - depends on SCSI=y || SCSI=BLK_CPQ_CISS_DA help When enabled (Y), this option allows SCSI tape drives and SCSI medium changers (tape robots) to be accessed via a Compaq 5xxx array _ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] cciss: set rq->errors more correctly in driver
PATCH 3/3
Set rq->errors more correctly in cciss driver. Previously
we had set it synonymously with the meaning of the last parameter
of end_that_last_request and complete_buffers (the "uptodate"
parameter) and had gotten away with it for all this time because
nobody ever looked at rq->errors. SCSI_IOCTL_SEND_COMMAND looks
at rq->errors, so now it matters that it be right.
Please consider this for inclusion.
Signed-off-by: Stephen M. Cameron <[EMAIL PROTECTED]>
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
---
linux-2.6.21-rc6/drivers/block/cciss.c | 43 -
1 files changed, 22 insertions(+), 21 deletions(-)
diff -puN linux-2.6.21-rc6/drivers/block/cciss.c~fix_cciss_rq_errors
linux-2.6.21-rc6/drivers/block/cciss.c
--- cciss_sg_io/linux-2.6.21-rc6/drivers/block/cciss.c~fix_cciss_rq_errors
2007-04-10 14:32:28.0 -0500
+++ cciss_sg_io-scameron/linux-2.6.21-rc6/drivers/block/cciss.c 2007-04-10
14:32:28.0 -0500
@@ -1261,7 +1261,7 @@ 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);
+ complete_buffers(rq->bio, (rq->errors == 0));
if (blk_fs_request(rq)) {
const int rw = rq_data_dir(rq);
@@ -1275,7 +1275,7 @@ static void cciss_softirq_done(struct re
add_disk_randomness(rq->rq_disk);
spin_lock_irqsave(>lock, flags);
- end_that_request_last(rq, rq->errors);
+ end_that_request_last(rq, (rq->errors == 0));
cmd_free(h, cmd, 1);
cciss_check_queues(h);
spin_unlock_irqrestore(>lock, flags);
@@ -2366,27 +2366,27 @@ static inline void resend_cciss_cmd(ctlr
static inline int evaluate_target_status(CommandList_struct *cmd)
{
unsigned char sense_key;
- int status = 0; /* 0 means bad, 1 means good. */
+ int error_count = 1;
if (cmd->err_info->ScsiStatus != 0x02) { /* not check condition? */
if (!blk_pc_request(cmd->rq))
printk(KERN_WARNING "cciss: cmd %p "
"has SCSI Status 0x%x\n",
cmd, cmd->err_info->ScsiStatus);
- return status;
+ return error_count;
}
/* check the sense key */
sense_key = 0xf & cmd->err_info->SenseInfo[2];
/* no status or recovered error */
if ((sense_key == 0x0) || (sense_key == 0x1))
- status = 1;
+ error_count = 0;
if (!blk_pc_request(cmd->rq)) { /* Not SG_IO or similar? */
- if (status == 0)
+ if (error_count != 0)
printk(KERN_WARNING "cciss: cmd %p has CHECK CONDITION"
" sense key = 0x%x\n", cmd, sense_key);
- return status;
+ return error_count;
}
/* SG_IO or similar, copy sense data back */
@@ -2398,7 +2398,7 @@ static inline int evaluate_target_status
} else
cmd->rq->sense_len = 0;
- return status;
+ return error_count;
}
/* checks the status of the job and calls complete buffers to mark all
@@ -2408,18 +2408,20 @@ static inline int evaluate_target_status
static inline void complete_command(ctlr_info_t *h, CommandList_struct *cmd,
int timeout)
{
- int status = 1;
int retry_cmd = 0;
+ struct request *rq = cmd->rq;
+
+ rq->errors = 0;
if (timeout)
- status = 0;
+ rq->errors = 1;
if (cmd->err_info->CommandStatus == 0) /* no error has occurred */
goto after_error_processing;
switch (cmd->err_info->CommandStatus) {
case CMD_TARGET_STATUS:
- status = evaluate_target_status(cmd);
+ rq->errors = evaluate_target_status(cmd);
break;
case CMD_DATA_UNDERRUN:
if (blk_fs_request(cmd->rq)) {
@@ -2438,32 +2440,32 @@ static inline void complete_command(ctlr
case CMD_INVALID:
printk(KERN_WARNING "cciss: cmd %p is "
"reported invalid\n", cmd);
- status = 0;
+ rq->errors = 1;
break;
case CMD_PROTOCOL_ERR:
printk(KERN_WARNING "cciss: cmd %p has "
"protocol error \n", cmd);
- status = 0;
+ rq->errors = 1;
break;
case CMD_HARDWARE_ERR:
printk(KERN_WARNING "cciss: cmd %p had "
" hardware error\n", cmd);
- status = 0;
+ rq->errors = 1;
[PATCH 2/3] cciss: add SG_IO ioctl to cciss
PATCH 2/3
For all of you that think cciss should be a scsi driver here is the patch that
you have been waiting for all these years. This patch actually adds the SG_IO
ioctl to cciss. The primary purpose is for clustering and high-availibilty.
But now anyone can exploit this ioctl in any manner they wish.
Note, SCSI_IOCTL_SEND_COMMAND doesn't work with this patch due to rq->errors
being set incorrectly. Subsequent patch fixes that.
Please consider this for inclusion.
Signed-off-by: Stephen M. Cameron <[EMAIL PROTECTED]>
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
---
linux-2.6.21-rc6/drivers/block/cciss.c | 164 ++---
1 files changed, 111 insertions(+), 53 deletions(-)
diff -puN linux-2.6.21-rc6/drivers/block/cciss.c~cciss_sg_io_ioctl
linux-2.6.21-rc6/drivers/block/cciss.c
--- cciss_sg_io/linux-2.6.21-rc6/drivers/block/cciss.c~cciss_sg_io_ioctl
2007-04-10 14:32:26.0 -0500
+++ cciss_sg_io-scameron/linux-2.6.21-rc6/drivers/block/cciss.c 2007-04-10
14:32:26.0 -0500
@@ -45,6 +45,9 @@
#include
#include
#include
+#include
+#include
+#include
#define CCISS_DRIVER_VERSION(maj,min,submin) ((maj<<16)|(min<<8)|(submin))
#define DRIVER_NAME "HP CISS Driver (v 3.6.14)"
@@ -1152,6 +1155,30 @@ static int cciss_ioctl(struct inode *ino
kfree(ioc);
return status;
}
+
+ /* scsi_cmd_ioctl handles these, below, though some are not */
+ /* very meaningful for cciss. SG_IO is the main one people want. */
+
+ case SG_GET_VERSION_NUM:
+ case SG_SET_TIMEOUT:
+ case SG_GET_TIMEOUT:
+ case SG_GET_RESERVED_SIZE:
+ case SG_SET_RESERVED_SIZE:
+ case SG_EMULATED_HOST:
+ case SG_IO:
+ case SCSI_IOCTL_SEND_COMMAND:
+ return scsi_cmd_ioctl(filep, disk, cmd, argp);
+
+ /* scsi_cmd_ioctl would normally handle these, below, but */
+ /* they aren't a good fit for cciss, as CD-ROMs are */
+ /* not supported, and we don't have any bus/target/lun */
+ /* which we present to the kernel. */
+
+ case CDROM_SEND_PACKET:
+ case CDROMCLOSETRAY:
+ case CDROMEJECT:
+ case SCSI_IOCTL_GET_IDLUN:
+ case SCSI_IOCTL_GET_BUS_NUMBER:
default:
return -ENOTTY;
}
@@ -2336,6 +2363,44 @@ static inline void resend_cciss_cmd(ctlr
start_io(h);
}
+static inline int evaluate_target_status(CommandList_struct *cmd)
+{
+ unsigned char sense_key;
+ int status = 0; /* 0 means bad, 1 means good. */
+
+ if (cmd->err_info->ScsiStatus != 0x02) { /* not check condition? */
+ if (!blk_pc_request(cmd->rq))
+ printk(KERN_WARNING "cciss: cmd %p "
+ "has SCSI Status 0x%x\n",
+ cmd, cmd->err_info->ScsiStatus);
+ return status;
+ }
+
+ /* check the sense key */
+ sense_key = 0xf & cmd->err_info->SenseInfo[2];
+ /* no status or recovered error */
+ if ((sense_key == 0x0) || (sense_key == 0x1))
+ status = 1;
+
+ if (!blk_pc_request(cmd->rq)) { /* Not SG_IO or similar? */
+ if (status == 0)
+ printk(KERN_WARNING "cciss: cmd %p has CHECK CONDITION"
+ " sense key = 0x%x\n", cmd, sense_key);
+ return status;
+ }
+
+ /* SG_IO or similar, copy sense data back */
+ if (cmd->rq->sense) {
+ if (cmd->rq->sense_len > cmd->err_info->SenseLen)
+ cmd->rq->sense_len = cmd->err_info->SenseLen;
+ memcpy(cmd->rq->sense, cmd->err_info->SenseInfo,
+ cmd->rq->sense_len);
+ } else
+ cmd->rq->sense_len = 0;
+
+ return status;
+}
+
/* checks the status of the job and calls complete buffers to mark all
* buffers for the completed job. Note that this function does not need
* to hold the hba/queue lock.
@@ -2353,37 +2418,22 @@ static inline void complete_command(ctlr
goto after_error_processing;
switch (cmd->err_info->CommandStatus) {
- unsigned char sense_key;
case CMD_TARGET_STATUS:
- status = 0;
-
- if (cmd->err_info->ScsiStatus == 0x02) {
- printk(KERN_WARNING "cciss: cmd %p "
- "has CHECK CONDITION "
- " byte 2 = 0x%x\n", cmd,
- cmd->err_info->SenseInfo[2]
- );
- /* check the sense key */
- sense_key = 0xf & cmd->err_info->SenseInfo[2];
-
[PATCH 1/3] cciss: reformat error handling
PATCH 1/3
This patch reformats some error handling code to reduce line lengths a bit. It
accompanies the SG_IO patch which is 2/3 of this set.
Please consider this for inclusion.
Signed-off-by: Stephen M. Cameron <[EMAIL PROTECTED]>
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
---
linux-2.6.21-rc6/drivers/block/cciss.c | 176 -
1 files changed, 90 insertions(+), 86 deletions(-)
diff -puN linux-2.6.21-rc6/drivers/block/cciss.c~reformat_error_handling
linux-2.6.21-rc6/drivers/block/cciss.c
--- cciss_sg_io/linux-2.6.21-rc6/drivers/block/cciss.c~reformat_error_handling
2007-04-10 14:22:46.0 -0500
+++ cciss_sg_io-scameron/linux-2.6.21-rc6/drivers/block/cciss.c 2007-04-10
14:31:58.0 -0500
@@ -2349,95 +2349,99 @@ static inline void complete_command(ctlr
if (timeout)
status = 0;
- if (cmd->err_info->CommandStatus != 0) {/* an error has
occurred */
- switch (cmd->err_info->CommandStatus) {
- unsigned char sense_key;
- case CMD_TARGET_STATUS:
- status = 0;
-
- if (cmd->err_info->ScsiStatus == 0x02) {
- printk(KERN_WARNING "cciss: cmd %p "
- "has CHECK CONDITION "
- " byte 2 = 0x%x\n", cmd,
- cmd->err_info->SenseInfo[2]
- );
- /* check the sense key */
- sense_key = 0xf & cmd->err_info->SenseInfo[2];
- /* no status or recovered error */
- if ((sense_key == 0x0) || (sense_key == 0x1)) {
- status = 1;
- }
- } else {
- printk(KERN_WARNING "cciss: cmd %p "
- "has SCSI Status 0x%x\n",
- cmd, cmd->err_info->ScsiStatus);
+ if (cmd->err_info->CommandStatus == 0) /* no error has occurred */
+ goto after_error_processing;
+
+ switch (cmd->err_info->CommandStatus) {
+ unsigned char sense_key;
+ case CMD_TARGET_STATUS:
+ status = 0;
+
+ if (cmd->err_info->ScsiStatus == 0x02) {
+ printk(KERN_WARNING "cciss: cmd %p "
+ "has CHECK CONDITION "
+ " byte 2 = 0x%x\n", cmd,
+ cmd->err_info->SenseInfo[2]
+ );
+ /* check the sense key */
+ sense_key = 0xf & cmd->err_info->SenseInfo[2];
+ /* no status or recovered error */
+ if ((sense_key == 0x0) || (sense_key == 0x1)) {
+ status = 1;
}
- break;
- case CMD_DATA_UNDERRUN:
- printk(KERN_WARNING "cciss: cmd %p has"
- " completed with data underrun "
- "reported\n", cmd);
- break;
- case CMD_DATA_OVERRUN:
- printk(KERN_WARNING "cciss: cmd %p has"
- " completed with data overrun "
- "reported\n", cmd);
- break;
- case CMD_INVALID:
- printk(KERN_WARNING "cciss: cmd %p is "
- "reported invalid\n", cmd);
- status = 0;
- break;
- case CMD_PROTOCOL_ERR:
- printk(KERN_WARNING "cciss: cmd %p has "
- "protocol error \n", cmd);
- status = 0;
- break;
- case CMD_HARDWARE_ERR:
- printk(KERN_WARNING "cciss: cmd %p had "
- " hardware error\n", cmd);
- status = 0;
- break;
- case CMD_CONNECTION_LOST:
- printk(KERN_WARNING "cciss: cmd %p had "
- "connection lost\n", cmd);
- status = 0;
- break;
- case CMD_ABORTED:
- printk(KERN_WARNING "cciss: cmd %p was "
- "aborted\n", cmd);
- status = 0;
-
[PATCH 1/3] cciss: reformat error handling
PATCH 1/3
This patch reformats some error handling code to reduce line lengths a bit. It
accompanies the SG_IO patch which is 2/3 of this set.
Please consider this for inclusion.
Signed-off-by: Stephen M. Cameron [EMAIL PROTECTED]
Signed-off-by: Mike Miller [EMAIL PROTECTED]
---
linux-2.6.21-rc6/drivers/block/cciss.c | 176 -
1 files changed, 90 insertions(+), 86 deletions(-)
diff -puN linux-2.6.21-rc6/drivers/block/cciss.c~reformat_error_handling
linux-2.6.21-rc6/drivers/block/cciss.c
--- cciss_sg_io/linux-2.6.21-rc6/drivers/block/cciss.c~reformat_error_handling
2007-04-10 14:22:46.0 -0500
+++ cciss_sg_io-scameron/linux-2.6.21-rc6/drivers/block/cciss.c 2007-04-10
14:31:58.0 -0500
@@ -2349,95 +2349,99 @@ static inline void complete_command(ctlr
if (timeout)
status = 0;
- if (cmd-err_info-CommandStatus != 0) {/* an error has
occurred */
- switch (cmd-err_info-CommandStatus) {
- unsigned char sense_key;
- case CMD_TARGET_STATUS:
- status = 0;
-
- if (cmd-err_info-ScsiStatus == 0x02) {
- printk(KERN_WARNING cciss: cmd %p
- has CHECK CONDITION
- byte 2 = 0x%x\n, cmd,
- cmd-err_info-SenseInfo[2]
- );
- /* check the sense key */
- sense_key = 0xf cmd-err_info-SenseInfo[2];
- /* no status or recovered error */
- if ((sense_key == 0x0) || (sense_key == 0x1)) {
- status = 1;
- }
- } else {
- printk(KERN_WARNING cciss: cmd %p
- has SCSI Status 0x%x\n,
- cmd, cmd-err_info-ScsiStatus);
+ if (cmd-err_info-CommandStatus == 0) /* no error has occurred */
+ goto after_error_processing;
+
+ switch (cmd-err_info-CommandStatus) {
+ unsigned char sense_key;
+ case CMD_TARGET_STATUS:
+ status = 0;
+
+ if (cmd-err_info-ScsiStatus == 0x02) {
+ printk(KERN_WARNING cciss: cmd %p
+ has CHECK CONDITION
+ byte 2 = 0x%x\n, cmd,
+ cmd-err_info-SenseInfo[2]
+ );
+ /* check the sense key */
+ sense_key = 0xf cmd-err_info-SenseInfo[2];
+ /* no status or recovered error */
+ if ((sense_key == 0x0) || (sense_key == 0x1)) {
+ status = 1;
}
- break;
- case CMD_DATA_UNDERRUN:
- printk(KERN_WARNING cciss: cmd %p has
- completed with data underrun
- reported\n, cmd);
- break;
- case CMD_DATA_OVERRUN:
- printk(KERN_WARNING cciss: cmd %p has
- completed with data overrun
- reported\n, cmd);
- break;
- case CMD_INVALID:
- printk(KERN_WARNING cciss: cmd %p is
- reported invalid\n, cmd);
- status = 0;
- break;
- case CMD_PROTOCOL_ERR:
- printk(KERN_WARNING cciss: cmd %p has
- protocol error \n, cmd);
- status = 0;
- break;
- case CMD_HARDWARE_ERR:
- printk(KERN_WARNING cciss: cmd %p had
- hardware error\n, cmd);
- status = 0;
- break;
- case CMD_CONNECTION_LOST:
- printk(KERN_WARNING cciss: cmd %p had
- connection lost\n, cmd);
- status = 0;
- break;
- case CMD_ABORTED:
- printk(KERN_WARNING cciss: cmd %p was
- aborted\n, cmd);
- status = 0;
- break;
- case CMD_ABORT_FAILED:
- printk(KERN_WARNING cciss: cmd %p reports
- abort failed\n, cmd);
- status = 0;
- break;
- case CMD_UNSOLICITED_ABORT:
- printk(KERN_WARNING cciss%d: unsolicited
- abort %p\n, h-ctlr
[PATCH 2/3] cciss: add SG_IO ioctl to cciss
PATCH 2/3
For all of you that think cciss should be a scsi driver here is the patch that
you have been waiting for all these years. This patch actually adds the SG_IO
ioctl to cciss. The primary purpose is for clustering and high-availibilty.
But now anyone can exploit this ioctl in any manner they wish.
Note, SCSI_IOCTL_SEND_COMMAND doesn't work with this patch due to rq-errors
being set incorrectly. Subsequent patch fixes that.
Please consider this for inclusion.
Signed-off-by: Stephen M. Cameron [EMAIL PROTECTED]
Signed-off-by: Mike Miller [EMAIL PROTECTED]
---
linux-2.6.21-rc6/drivers/block/cciss.c | 164 ++---
1 files changed, 111 insertions(+), 53 deletions(-)
diff -puN linux-2.6.21-rc6/drivers/block/cciss.c~cciss_sg_io_ioctl
linux-2.6.21-rc6/drivers/block/cciss.c
--- cciss_sg_io/linux-2.6.21-rc6/drivers/block/cciss.c~cciss_sg_io_ioctl
2007-04-10 14:32:26.0 -0500
+++ cciss_sg_io-scameron/linux-2.6.21-rc6/drivers/block/cciss.c 2007-04-10
14:32:26.0 -0500
@@ -45,6 +45,9 @@
#include linux/blkdev.h
#include linux/genhd.h
#include linux/completion.h
+#include scsi/sg.h
+#include scsi/scsi_ioctl.h
+#include linux/cdrom.h
#define CCISS_DRIVER_VERSION(maj,min,submin) ((maj16)|(min8)|(submin))
#define DRIVER_NAME HP CISS Driver (v 3.6.14)
@@ -1152,6 +1155,30 @@ static int cciss_ioctl(struct inode *ino
kfree(ioc);
return status;
}
+
+ /* scsi_cmd_ioctl handles these, below, though some are not */
+ /* very meaningful for cciss. SG_IO is the main one people want. */
+
+ case SG_GET_VERSION_NUM:
+ case SG_SET_TIMEOUT:
+ case SG_GET_TIMEOUT:
+ case SG_GET_RESERVED_SIZE:
+ case SG_SET_RESERVED_SIZE:
+ case SG_EMULATED_HOST:
+ case SG_IO:
+ case SCSI_IOCTL_SEND_COMMAND:
+ return scsi_cmd_ioctl(filep, disk, cmd, argp);
+
+ /* scsi_cmd_ioctl would normally handle these, below, but */
+ /* they aren't a good fit for cciss, as CD-ROMs are */
+ /* not supported, and we don't have any bus/target/lun */
+ /* which we present to the kernel. */
+
+ case CDROM_SEND_PACKET:
+ case CDROMCLOSETRAY:
+ case CDROMEJECT:
+ case SCSI_IOCTL_GET_IDLUN:
+ case SCSI_IOCTL_GET_BUS_NUMBER:
default:
return -ENOTTY;
}
@@ -2336,6 +2363,44 @@ static inline void resend_cciss_cmd(ctlr
start_io(h);
}
+static inline int evaluate_target_status(CommandList_struct *cmd)
+{
+ unsigned char sense_key;
+ int status = 0; /* 0 means bad, 1 means good. */
+
+ if (cmd-err_info-ScsiStatus != 0x02) { /* not check condition? */
+ if (!blk_pc_request(cmd-rq))
+ printk(KERN_WARNING cciss: cmd %p
+ has SCSI Status 0x%x\n,
+ cmd, cmd-err_info-ScsiStatus);
+ return status;
+ }
+
+ /* check the sense key */
+ sense_key = 0xf cmd-err_info-SenseInfo[2];
+ /* no status or recovered error */
+ if ((sense_key == 0x0) || (sense_key == 0x1))
+ status = 1;
+
+ if (!blk_pc_request(cmd-rq)) { /* Not SG_IO or similar? */
+ if (status == 0)
+ printk(KERN_WARNING cciss: cmd %p has CHECK CONDITION
+ sense key = 0x%x\n, cmd, sense_key);
+ return status;
+ }
+
+ /* SG_IO or similar, copy sense data back */
+ if (cmd-rq-sense) {
+ if (cmd-rq-sense_len cmd-err_info-SenseLen)
+ cmd-rq-sense_len = cmd-err_info-SenseLen;
+ memcpy(cmd-rq-sense, cmd-err_info-SenseInfo,
+ cmd-rq-sense_len);
+ } else
+ cmd-rq-sense_len = 0;
+
+ return status;
+}
+
/* checks the status of the job and calls complete buffers to mark all
* buffers for the completed job. Note that this function does not need
* to hold the hba/queue lock.
@@ -2353,37 +2418,22 @@ static inline void complete_command(ctlr
goto after_error_processing;
switch (cmd-err_info-CommandStatus) {
- unsigned char sense_key;
case CMD_TARGET_STATUS:
- status = 0;
-
- if (cmd-err_info-ScsiStatus == 0x02) {
- printk(KERN_WARNING cciss: cmd %p
- has CHECK CONDITION
- byte 2 = 0x%x\n, cmd,
- cmd-err_info-SenseInfo[2]
- );
- /* check the sense key */
- sense_key = 0xf cmd-err_info-SenseInfo[2];
- /* no status or recovered error */
- if ((sense_key == 0x0) || (sense_key == 0x1)) {
- status = 1;
- }
- } else
[PATCH 3/3] cciss: set rq-errors more correctly in driver
PATCH 3/3
Set rq-errors more correctly in cciss driver. Previously
we had set it synonymously with the meaning of the last parameter
of end_that_last_request and complete_buffers (the uptodate
parameter) and had gotten away with it for all this time because
nobody ever looked at rq-errors. SCSI_IOCTL_SEND_COMMAND looks
at rq-errors, so now it matters that it be right.
Please consider this for inclusion.
Signed-off-by: Stephen M. Cameron [EMAIL PROTECTED]
Signed-off-by: Mike Miller [EMAIL PROTECTED]
---
linux-2.6.21-rc6/drivers/block/cciss.c | 43 -
1 files changed, 22 insertions(+), 21 deletions(-)
diff -puN linux-2.6.21-rc6/drivers/block/cciss.c~fix_cciss_rq_errors
linux-2.6.21-rc6/drivers/block/cciss.c
--- cciss_sg_io/linux-2.6.21-rc6/drivers/block/cciss.c~fix_cciss_rq_errors
2007-04-10 14:32:28.0 -0500
+++ cciss_sg_io-scameron/linux-2.6.21-rc6/drivers/block/cciss.c 2007-04-10
14:32:28.0 -0500
@@ -1261,7 +1261,7 @@ 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);
+ complete_buffers(rq-bio, (rq-errors == 0));
if (blk_fs_request(rq)) {
const int rw = rq_data_dir(rq);
@@ -1275,7 +1275,7 @@ static void cciss_softirq_done(struct re
add_disk_randomness(rq-rq_disk);
spin_lock_irqsave(h-lock, flags);
- end_that_request_last(rq, rq-errors);
+ end_that_request_last(rq, (rq-errors == 0));
cmd_free(h, cmd, 1);
cciss_check_queues(h);
spin_unlock_irqrestore(h-lock, flags);
@@ -2366,27 +2366,27 @@ static inline void resend_cciss_cmd(ctlr
static inline int evaluate_target_status(CommandList_struct *cmd)
{
unsigned char sense_key;
- int status = 0; /* 0 means bad, 1 means good. */
+ int error_count = 1;
if (cmd-err_info-ScsiStatus != 0x02) { /* not check condition? */
if (!blk_pc_request(cmd-rq))
printk(KERN_WARNING cciss: cmd %p
has SCSI Status 0x%x\n,
cmd, cmd-err_info-ScsiStatus);
- return status;
+ return error_count;
}
/* check the sense key */
sense_key = 0xf cmd-err_info-SenseInfo[2];
/* no status or recovered error */
if ((sense_key == 0x0) || (sense_key == 0x1))
- status = 1;
+ error_count = 0;
if (!blk_pc_request(cmd-rq)) { /* Not SG_IO or similar? */
- if (status == 0)
+ if (error_count != 0)
printk(KERN_WARNING cciss: cmd %p has CHECK CONDITION
sense key = 0x%x\n, cmd, sense_key);
- return status;
+ return error_count;
}
/* SG_IO or similar, copy sense data back */
@@ -2398,7 +2398,7 @@ static inline int evaluate_target_status
} else
cmd-rq-sense_len = 0;
- return status;
+ return error_count;
}
/* checks the status of the job and calls complete buffers to mark all
@@ -2408,18 +2408,20 @@ static inline int evaluate_target_status
static inline void complete_command(ctlr_info_t *h, CommandList_struct *cmd,
int timeout)
{
- int status = 1;
int retry_cmd = 0;
+ struct request *rq = cmd-rq;
+
+ rq-errors = 0;
if (timeout)
- status = 0;
+ rq-errors = 1;
if (cmd-err_info-CommandStatus == 0) /* no error has occurred */
goto after_error_processing;
switch (cmd-err_info-CommandStatus) {
case CMD_TARGET_STATUS:
- status = evaluate_target_status(cmd);
+ rq-errors = evaluate_target_status(cmd);
break;
case CMD_DATA_UNDERRUN:
if (blk_fs_request(cmd-rq)) {
@@ -2438,32 +2440,32 @@ static inline void complete_command(ctlr
case CMD_INVALID:
printk(KERN_WARNING cciss: cmd %p is
reported invalid\n, cmd);
- status = 0;
+ rq-errors = 1;
break;
case CMD_PROTOCOL_ERR:
printk(KERN_WARNING cciss: cmd %p has
protocol error \n, cmd);
- status = 0;
+ rq-errors = 1;
break;
case CMD_HARDWARE_ERR:
printk(KERN_WARNING cciss: cmd %p had
hardware error\n, cmd);
- status = 0;
+ rq-errors = 1;
break;
case CMD_CONNECTION_LOST:
printk(KERN_WARNING cciss: cmd %p had
connection lost\n, cmd);
- status = 0;
+ rq-errors = 1;
break;
case CMD_ABORTED:
printk(KERN_WARNING cciss
[PATCH 1/1] cciss: add init of drv->cylinders back to cciss_geometry_inquiry
PATCH 1/1
This patch adds initialization of drv->cylinders back into the failing case in
cciss_geometry_inquiry. I inadvertently removed it in one my 2TB updates.
Please consider this for inclusion.
Signed-off-by: Mike Miller <[EMAIL PROTECTED]>
--
diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 072e18e..14d7806 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -1915,6 +1915,7 @@ static void cciss_geometry_inquiry(int c
"does not support reading geometry\n");
drv->heads = 255;
drv->sectors = 32; // Sectors per track
+ drv->cylinders = total_size + 1;
drv->raid_level = RAID_UNKNOWN;
} else {
drv->heads = inq_buff->data_byte[6];
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
