[Bug 8004] a likely bug in "scsi/arm/cumana_2.c"
http://bugzilla.kernel.org/show_bug.cgi?id=8004 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |linux-scsi@vger.kernel.org |bugs.osdl.org | --- Comment #4 from [EMAIL PROTECTED] 2008-02-14 22:44 --- Well, the offending line is still there. Lingxiao, would you like to submit a patch to [EMAIL PROTECTED] -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ips.c broken since 2.6.23 on x86_64?
On Fri 15 Feb at 09:13:16 +0900 [EMAIL PROTECTED] said: > > Thanks. So we surely have a bug in the non-breakup part. > > I've just found one bug. Can you try this patch against 2.6.24? Tested and unfortunately no change. Behaves same as the breakup-revert patch. -- Tim Pepper <[EMAIL PROTECTED]> IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ips.c broken since 2.6.23 on x86_64?
On Thu, 14 Feb 2008 15:55:49 -0800
Tim Pepper <[EMAIL PROTECTED]> wrote:
> On Thu 14 Feb at 20:48:38 +0900 [EMAIL PROTECTED] said:
> >
> > I have a slight doubt on the breakup code though I'm not sure you hit
> > the code. Reverting only the breakup part works? The patch is against
> > 2.6.24.
>
> I've tested this revert you posted. Essentially the same trace is logged
> (see below). The machine doesn't die though. But /proc/scsi/scsi doesn't
> show the hardware and I am getting an additional trace dumped now (see
> futher below).
Thanks. So we surely have a bug in the non-breakup part.
I've just found one bug. Can you try this patch against 2.6.24?
Thanks,
diff --git a/drivers/scsi/ips.c b/drivers/scsi/ips.c
index 5c5a9b2..d8f5eb5 100644
--- a/drivers/scsi/ips.c
+++ b/drivers/scsi/ips.c
@@ -1575,12 +1575,12 @@ ips_make_passthru(ips_ha_t *ha, struct scsi_cmnd *SC,
ips_scb_t *scb, int intr)
ips_passthru_t *pt;
int length = 0;
int i, ret;
-struct scatterlist *sg = scsi_sglist(SC);
+struct scatterlist *sg;
METHOD_TRACE("ips_make_passthru", 1);
scsi_for_each_sg(SC, sg, scsi_sg_count(SC), i)
-length += sg[i].length;
+length += sg->length;
if (length < sizeof (ips_passthru_t)) {
/* wrong size */
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ips.c broken since 2.6.23 on x86_64?
On Thu 14 Feb at 20:48:38 +0900 [EMAIL PROTECTED] said: > > I have a slight doubt on the breakup code though I'm not sure you hit > the code. Reverting only the breakup part works? The patch is against > 2.6.24. I've tested this revert you posted. Essentially the same trace is logged (see below). The machine doesn't die though. But /proc/scsi/scsi doesn't show the hardware and I am getting an additional trace dumped now (see futher below). Feb 14 16:04:13 ipstest kernel: [ 1046.531180] ACPI: PCI Interrupt :02:01.0[A] -> GSI 18 (level, low) -> IRQ 18 Feb 14 16:04:13 ipstest kernel: [ 1046.553420] scsi3 : IBM PCI ServeRAID 7.12.05 Build 761 Feb 14 16:04:13 ipstest kernel: [ 1046.554103] PGD 7cc1f067 PUD 7c4f6067 PMD 0 Feb 14 16:04:13 ipstest kernel: [ 1046.554348] CPU 0 Feb 14 16:04:13 ipstest kernel: [ 1046.554460] Modules linked in: ips aic94xx Feb 14 16:04:13 ipstest kernel: [ 1046.554587] Pid: 4476, comm: scsi_scan_3 Not tainted 2.6.24-fujita-revert-breakup #1 Feb 14 16:04:13 ipstest kernel: [ 1046.554827] RIP: 0010:[check_addr+16/80] [check_addr+16/80] check_addr+0x10/0x50 Feb 14 16:04:13 ipstest kernel: [ 1046.555079] RSP: 0018:81007b0f78f0 EFLAGS: 00010082 Feb 14 16:04:13 ipstest kernel: [ 1046.555208] RAX: RBX: 81007b92a300 RCX: 0024 Feb 14 16:04:13 ipstest kernel: [ 1046.555350] RDX: 7b92a600 RSI: 807a7340 RDI: 806e7f43 Feb 14 16:04:13 ipstest kernel: [ 1046.555494] RBP: 81007b0f78f0 R08: 0500 R09: Feb 14 16:04:13 ipstest kernel: [ 1046.555632] R10: 81007c463b38 R11: 0060 R12: Feb 14 16:04:13 ipstest kernel: [ 1046.555784] R13: 0001 R14: 807a7340 R15: 81007c463a80 Feb 14 16:04:13 ipstest kernel: [ 1046.555924] FS: () GS:807d6000() knlGS: Feb 14 16:04:13 ipstest kernel: [ 1046.556173] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b Feb 14 16:04:13 ipstest kernel: [ 1046.556306] CR2: CR3: 7cd02000 CR4: 06e0 Feb 14 16:04:13 ipstest kernel: [ 1046.556443] DR0: DR1: DR2: Feb 14 16:04:13 ipstest kernel: [ 1046.556582] DR3: DR6: 0ff0 DR7: 0400 Feb 14 16:04:13 ipstest kernel: [ 1046.556731] Process scsi_scan_3 (pid: 4476, threadinfo 81007b0f6000, task 81007b9295c0) Feb 14 16:04:13 ipstest kernel: [ 1046.556972] Stack: 81007b0f7920 80213118 81007c463a80 81007b0fcf50 Feb 14 16:04:13 ipstest kernel: [ 1046.557221] 81007cd14450 81007b0f7930 8047a4c2 Feb 14 16:04:13 ipstest kernel: [ 1046.557463] 81007b0f79b0 8801c28e 81007c463ae8 00017c463ae8 Feb 14 16:04:13 ipstest kernel: [ 1046.557603] Call Trace: Feb 14 16:04:13 ipstest kernel: [ 1046.557830] [nommu_map_sg+104/176] nommu_map_sg+0x68/0xb0 Feb 14 16:04:13 ipstest kernel: [ 1046.557949] [scsi_dma_map+66/96] scsi_dma_map+0x42/0x60 Feb 14 16:04:13 ipstest kernel: [ 1046.558083] [_end+124740294/2127405112] :ips:ips_next+0x33e/0xc10 Feb 14 16:04:13 ipstest kernel: [ 1046.558205] [scsi_done+0/48] scsi_done+0x0/0x30 Feb 14 16:04:13 ipstest kernel: [ 1046.558332] [_end+124752974/2127405112] :ips:ips_queue+0x106/0x1f0 Feb 14 16:04:13 ipstest kernel: [ 1046.558459] [scsi_dispatch_cmd+453/736] scsi_dispatch_cmd+0x1c5/0x2e0 Feb 14 16:04:13 ipstest kernel: [ 1046.558589] [scsi_request_fn+491/976] scsi_request_fn+0x1eb/0x3d0 Feb 14 16:04:13 ipstest kernel: [ 1046.558725] [__generic_unplug_device+37/48] __generic_unplug_device+0x25/0x30 Feb 14 16:04:13 ipstest kernel: [ 1046.558851] [blk_execute_rq_nowait+99/176] blk_execute_rq_nowait+0x63/0xb0 Feb 14 16:04:13 ipstest kernel: [ 1046.558982] [blk_execute_rq+122/224] blk_execute_rq+0x7a/0xe0 Feb 14 16:04:13 ipstest kernel: [ 1046.559110] [scsi_execute+240/288] scsi_execute+0xf0/0x120 Feb 14 16:04:13 ipstest kernel: [ 1046.559237] [scsi_execute_req+134/240] scsi_execute_req+0x86/0xf0 Feb 14 16:04:13 ipstest kernel: [ 1046.559366] [scsi_probe_and_add_lun+594/3472] scsi_probe_and_add_lun+0x252/0xd90 Feb 14 16:04:13 ipstest kernel: [ 1046.559501] [sas_expander_match+27/160] sas_expander_match+0x1b/0xa0 Feb 14 16:04:13 ipstest kernel: [ 1046.559633] [get_device+23/32] get_device+0x17/0x20 Feb 14 16:04:13 ipstest kernel: [ 1046.559755] [__scsi_scan_target+220/1680] __scsi_scan_target+0xdc/0x690 Feb 14 16:04:13 ipstest kernel: [ 1046.559887] [enqueue_task_fair+32/64] enqueue_task_fair+0x20/0x40 Feb 14 16:04:13 ipstest kernel: [ 1046.560019] [enqueue_task+19/48] enqueue_task+0x13/0x30 Feb 14 16:04:13 ipstest kernel: [ 1046.560141] [update_curr+101/192] update_curr+0x65/0xc0 Feb 14 16:04:13 ipstest kernel: [ 1046.560268] [scsi_scan_channel+139/160] scsi_scan_channel+0x8b/0xa0 Feb 14 16:04:13 ipstest kernel: [ 1046.560397] [scsi_scan_host_selected+158/352
Re: [PATCH] gdth: convert to PCI hotplug API
Comments noted for my next round of revisions (its a low priority, so definitely not this week). Good spotting, thanks! Jeff - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gdth: convert to PCI hotplug API
Boaz Harrosh wrote: do you intend this to be pushed into 2.6.25-rcx or this is already for 2.6.26? Should we put this in -mm tree for testing? Not intended for 2.6.25. I just wanted to get this "in process" somewhere, and keep this issue moving. I would definitely prefer to have this tested before it goes to Linus. Its a long term goal to kill pci_find_device(), and this conversion was a side effect of that. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch 07/13] Dell CERC support for megaraid_mbox
As Sumant mentioned earlier we will check if it is possible to
allow random delete and still allow the devices to be seen.
With this patch we will be blocking a feature that is possibly
used with the legacy driver. The applications may still allow random
delete and that could create more issue if we just block it/change the
required behavior from the driver.
So, for now I don't want this patch to be added. Will check &
submit a separate patch to address the issue.
Bo Yang
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, February 04, 2008 11:53 PM
To: [EMAIL PROTECTED]
Cc: linux-scsi@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Patro, Sumant
Subject: [patch 07/13] Dell CERC support for megaraid_mbox
From: Hannes Reinecke <[EMAIL PROTECTED]>
Newer Dell CERC firmware (>= 6.62) implement a random deletion handling
compatible with the legacy megaraid driver. The legacy handling shifted
the target ID by 0x80 only for I/O commands (READ/WRITE/etc), whereas
megaraid_mbox shifts the target ID always if random deletion is
supported.
The resulted in megaraid_mbox sending an INQUIRY to the wrong channel,
and not finding any devices, obviously.
So we disable the random deletion support if the offending firmware is
found.
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=6695
Signed-off-by: Hannes Reinecke <[EMAIL PROTECTED]>
Cc: "Patro, Sumant" <[EMAIL PROTECTED]>
Cc: James Bottomley <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_mbox.c | 17 +
drivers/scsi/megaraid/megaraid_mbox.h |1 +
2 files changed, 18 insertions(+)
diff -puN
drivers/scsi/megaraid/megaraid_mbox.c~dell-cerc-support-for-megaraid_mbo
x drivers/scsi/megaraid/megaraid_mbox.c
---
a/drivers/scsi/megaraid/megaraid_mbox.c~dell-cerc-support-for-megaraid_m
box
+++ a/drivers/scsi/megaraid/megaraid_mbox.c
@@ -3168,6 +3168,23 @@ megaraid_mbox_support_random_del(adapter
uint8_t raw_mbox[sizeof(mbox_t)];
int rval;
+ /*
+* Newer firmware on Dell CERC expect a different
+* random deletion handling, so disable it.
+*/
+ if (adapter->pdev->vendor == PCI_VENDOR_ID_AMI &&
+ adapter->pdev->device == PCI_DEVICE_ID_AMI_MEGARAID3 &&
+ adapter->pdev->subsystem_vendor == PCI_VENDOR_ID_DELL &&
+ adapter->pdev->subsystem_device ==
PCI_SUBSYS_ID_CERC_ATA100_4CH &&
+ (adapter->fw_version[0] > '6' ||
+(adapter->fw_version[0] == '6' &&
+ adapter->fw_version[2] > '6') ||
+(adapter->fw_version[0] == '6'
+ && adapter->fw_version[2] == '6'
+ && adapter->fw_version[3] > '1'))) {
+ con_log(CL_DLEVEL1, ("megaraid: disable random
deletion\n"));
+ return 0;
+ }
mbox = (mbox_t *)raw_mbox;
diff -puN
drivers/scsi/megaraid/megaraid_mbox.h~dell-cerc-support-for-megaraid_mbo
x drivers/scsi/megaraid/megaraid_mbox.h
---
a/drivers/scsi/megaraid/megaraid_mbox.h~dell-cerc-support-for-megaraid_m
box
+++ a/drivers/scsi/megaraid/megaraid_mbox.h
@@ -88,6 +88,7 @@
#define PCI_SUBSYS_ID_PERC3_QC 0x0471
#define PCI_SUBSYS_ID_PERC3_DC 0x0493
#define PCI_SUBSYS_ID_PERC3_SC 0x0475
+#define PCI_SUBSYS_ID_CERC_ATA100_4CH 0x0511
#define MBOX_MAX_SCSI_CMDS 128 // number of cmds reserved for
kernel
_
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] make lpfc_disable_node() static
Adrian Bunk wrote: This patch makes theneedlessly global lpfc_disable_node() static. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- ACK -- james s - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gdth: convert to PCI hotplug API
On Tue, 2008-02-12 at 18:49 -0500, Jeff Garzik wrote: > Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> Nice work, thanks. This is PCI only I take it. ISA and EISA look like they'll be a tad more troublesome, so PCI only is fine. > --- > drivers/scsi/gdth.c | 143 > +++- > 1 file changed, 86 insertions(+), 57 deletions(-) > > 06196f50915da97bb897495863f9f084d785c1e4 > diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c > index c825239..1b53e92 100644 > --- a/drivers/scsi/gdth.c > +++ b/drivers/scsi/gdth.c > @@ -595,85 +595,107 @@ static int __init gdth_search_isa(ulong32 bios_adr) > #endif /* CONFIG_ISA */ > > #ifdef CONFIG_PCI > -static void gdth_search_dev(gdth_pci_str *pcistr, ushort *cnt, > -ushort vendor, ushort dev); > +static gdth_pci_str gdth_pcistr[MAXHA]; > +static int gdth_pci_cnt; > +static bool gdth_pci_registered; Could we get rid of these static arrays and MAXHA entirely? It should be possible just to bung the parameters in pci_str into gdth_ha_str and dump the arrays. Thanks, James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] make lpfc_disable_node() static
This patch makes theneedlessly global lpfc_disable_node() static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/scsi/lpfc/lpfc_crtn.h|1 -
drivers/scsi/lpfc/lpfc_hbadisc.c |2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
c3ed441728e0116d0e545837d84cbe337740a3de diff --git
a/drivers/scsi/lpfc/lpfc_crtn.h b/drivers/scsi/lpfc/lpfc_crtn.h
index 848d977..0819f5f 100644
--- a/drivers/scsi/lpfc/lpfc_crtn.h
+++ b/drivers/scsi/lpfc/lpfc_crtn.h
@@ -55,7 +55,6 @@ void lpfc_mbx_cmpl_ns_reg_login(struct lpfc_hba *,
LPFC_MBOXQ_t *);
void lpfc_mbx_cmpl_fdmi_reg_login(struct lpfc_hba *, LPFC_MBOXQ_t *);
void lpfc_enqueue_node(struct lpfc_vport *, struct lpfc_nodelist *);
void lpfc_dequeue_node(struct lpfc_vport *, struct lpfc_nodelist *);
-void lpfc_disable_node(struct lpfc_vport *, struct lpfc_nodelist *);
struct lpfc_nodelist *lpfc_enable_node(struct lpfc_vport *,
struct lpfc_nodelist *, int);
void lpfc_nlp_set_state(struct lpfc_vport *, struct lpfc_nodelist *, int);
diff --git a/drivers/scsi/lpfc/lpfc_hbadisc.c b/drivers/scsi/lpfc/lpfc_hbadisc.c
index bd572d6..9766534 100644
--- a/drivers/scsi/lpfc/lpfc_hbadisc.c
+++ b/drivers/scsi/lpfc/lpfc_hbadisc.c
@@ -1694,7 +1694,7 @@ lpfc_dequeue_node(struct lpfc_vport *vport, struct
lpfc_nodelist *ndlp)
NLP_STE_UNUSED_NODE);
}
-void
+static void
lpfc_disable_node(struct lpfc_vport *vport, struct lpfc_nodelist *ndlp)
{
if ((ndlp->nlp_flag & NLP_DELAY_TMO) != 0)
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3 v2] iscsi iser: remove DMA alignment restriction
Thanks to James pointing out the problems with the BLK_BOUNCE_ANY
for IB devices, this revised patch contains only the DMA alignment
fix for iSER.
Mike, can you take care of this and the other two patches in the
series:
[PATCH 2/3] iscsi iser: increase max_sectors
[PATCH 3/3] iscsi iser: increase sg_tablesize
-- Pete
>From 255e73b67ec1458af18395981fddebdc958e8fe9 Mon Sep 17 00:00:00 2001
From: Pete Wyckoff <[EMAIL PROTECTED]>
Date: Thu, 14 Feb 2008 16:09:27 -0500
Subject: [PATCH] iscsi iser: remove DMA alignment restriction
iscsi_iser does not require any particular DMA aligement
requirement. Add a slave_configure function to set the alignment
to zero, allowing the use of direct IO from arbitrary offsets
within a page.
Signed-off-by: Pete Wyckoff <[EMAIL PROTECTED]>
---
drivers/infiniband/ulp/iser/iscsi_iser.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c
b/drivers/infiniband/ulp/iser/iscsi_iser.c
index be1b9fb..313f102 100644
--- a/drivers/infiniband/ulp/iser/iscsi_iser.c
+++ b/drivers/infiniband/ulp/iser/iscsi_iser.c
@@ -543,6 +543,12 @@ iscsi_iser_ep_disconnect(__u64 ep_handle)
iser_conn_terminate(ib_conn);
}
+static int iscsi_iser_slave_configure(struct scsi_device *sdev)
+{
+ blk_queue_dma_alignment(sdev->request_queue, 0);
+ return 0;
+}
+
static struct scsi_host_template iscsi_iser_sht = {
.module = THIS_MODULE,
.name = "iSCSI Initiator over iSER, v." DRV_VER,
@@ -556,6 +562,7 @@ static struct scsi_host_template iscsi_iser_sht = {
.eh_device_reset_handler= iscsi_eh_device_reset,
.eh_host_reset_handler = iscsi_eh_host_reset,
.use_clustering = DISABLE_CLUSTERING,
+ .slave_configure= iscsi_iser_slave_configure,
.proc_name = "iscsi_iser",
.this_id= -1,
};
--
1.5.3.8
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] gdth: update deprecated pci_find_device
James Bottomley wrote: On Thu, 2008-02-14 at 15:13 -0500, Jeff Garzik wrote: Boaz Harrosh wrote: From: Sergio Luis <[EMAIL PROTECTED]> Fix compilation warning in gdth.c, which was using the deprecated pci_find_device. [...] This patch is already upstream... (unfortunately) I think, in spite of the cover name (patches for stable), these are for the set of testers who're based on 2.6.24. Oops! My mistake, then. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] gdth: update deprecated pci_find_device
On Thu, 2008-02-14 at 15:13 -0500, Jeff Garzik wrote: > Boaz Harrosh wrote: > > From: Sergio Luis <[EMAIL PROTECTED]> > > > > Fix compilation warning in gdth.c, which was using the deprecated > > pci_find_device. [...] > This patch is already upstream... (unfortunately) I think, in spite of the cover name (patches for stable), these are for the set of testers who're based on 2.6.24. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] gdth: update deprecated pci_find_device
Boaz Harrosh wrote:
From: Sergio Luis <[EMAIL PROTECTED]>
Fix compilation warning in gdth.c, which was using the deprecated
pci_find_device.
drivers/scsi/gdth.c:645: warning: 'pci_find_device' is deprecated (declared at
include/linux/pci.h:495)
Changing it to use pci_get_device, instead.
Signed-off-by: Sergio Luis <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
---
drivers/scsi/Kconfig |2 +-
drivers/scsi/gdth.c |7 +--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 184c7ae..46fcb82 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -725,7 +725,7 @@ config SCSI_FD_MCS
config SCSI_GDTH
tristate "Intel/ICP (former GDT SCSI Disk Array) RAID Controller
support"
- depends on (ISA || EISA || PCI) && SCSI && ISA_DMA_API && PCI_LEGACY
+ depends on (ISA || EISA || PCI) && SCSI && ISA_DMA_API
---help---
Formerly called GDT SCSI Disk Array Controller Support.
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index b253b8c..5f0e054 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -643,12 +643,15 @@ static void __init gdth_search_dev(gdth_pci_str *pcistr,
ushort *cnt,
*cnt, vendor, device));
pdev = NULL;
-while ((pdev = pci_find_device(vendor, device, pdev))
+while ((pdev = pci_get_device(vendor, device, pdev))
!= NULL) {
if (pci_enable_device(pdev))
continue;
-if (*cnt >= MAXHA)
+if (*cnt >= MAXHA) {
+pci_dev_put(pdev);
return;
+}
This patch is already upstream... (unfortunately)
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
FW: [Bug 9859] hp smart array E200i kernel panic upon boot
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 14, 2008 8:16 AM > To: Miller, Mike (OS Dev) > Subject: [Bug 9859] hp smart array E200i kernel panic upon boot > > http://bugzilla.kernel.org/show_bug.cgi?id=9859 > > > [EMAIL PROTECTED] changed: > >What|Removed |Added > -- > -- > CC||[EMAIL PROTECTED] > > > > > --- Comment #14 from [EMAIL PROTECTED] 2008-02-14 06:16 > --- I'm facing a problem that seems related also using > gentoo on a x86_64 configuration (Dual Opteron 270 on Tyan > K8SE) I'm booting from a 3ware 9500s controller. > Everything went find with 2.6.23 but stating from 2.6.24 i > get the same kernel panic message: Unable to mount root fs on > unknown-block(0,0) The sd messages for sda and sdb that > appear under 2.6.23 do no longer appear with 2.6.24 though > the 3ware driver reports it's loaded > Andrew, The latest reports being added to the bug point to something other than cciss. This user is reporting the same problem on a white box with a 3ware SAS card. I've recreated the problem in my lab with a DL385 Opteron server. I've confirmed the 2.6.24.x kernels do not fail on Intel based platforms. The question is what changed in the kernel to to break AMD platforms. I'll keep looking and post any updates. -- mikem > > -- > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > --- You are receiving this mail because: --- You are > the assignee for the bug, or are watching the assignee. > - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] iscsi iser: remove DMA restrictions
Mike Christie wrote: Mike Christie wrote: James Bottomley wrote: On Thu, 2008-02-14 at 11:56 -0600, Mike Christie wrote: You really don't want to do this. That signals to the block layer that we have an iommu, although it's practically the same thing as a 64 bit DMA mask ... but I'd just leave it to the DMA mask to set this up correctly. Anything else is asking for a subtle bug to turn up years from now when something causes the mask and the limit to be mismatched. I thought BLK_BOUNCE_ANY just meant "don't bounce anything" (that was from the blkdev.h comments). It does ... that's why it's used in the IOMMU case ... and why it's practically the same as a 64 bit mask. We used it for iscsi_tcp because the network layer can take any type of page and will do the right thing for the hardware it eventually gets sent to. Right, to you it means never bounce because net wants to do it instead. However, I don't think that's the case for iSER, is it? ... as in, if I will leave that to Roland and them :) Ooops, I misread your mail. I think you are right and for iser we need to use the ib devices dma values. For some reason I was thinking you were asking if there was a different interface which abstracted all that away for us like with iscsi_tcp. My only concern with a simple patch to use the ib interface's dma values would be, if there is some event that causes us to start using inteface ib0 then switch to ib1 (maybe like some sort of route table change if that is possible), then we will have to loop over all the scsi devices's queues and update the dma values. And if there is IO already queued then would we have to possible rebuild those commands if something like the dma_mask changed? I guess we can just handle this like how FC handles the case when the dev loss tmo expires, but then the rport comes back later. Yuck, I guess we would have to do something like this if ib0 and ib1 had different dma restrictions. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] gdth: remove gdth cooked up command accessors
Last patch rendered these, to stupid status. So bye bye
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/gdth.c | 73 ++-
1 files changed, 14 insertions(+), 59 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 077f972..cfce0fe 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -85,10 +85,10 @@
/* The meaning of the Scsi_Pointer members in this driver is as follows:
* ptr: Chaining
- * this_residual: gdth_bufflen
- * buffer: gdth_sglist
+ * this_residual: unused
+ * buffer: unused
* dma_handle: unused
- * buffers_residual:gdth_sg_count
+ * buffers_residual:unused
* Status: unused
* Message: unused
* have_data_in:unused
@@ -373,47 +373,6 @@ static const struct file_operations gdth_fops = {
.release = gdth_close,
};
-/*
- * gdth scsi_command access wrappers.
- * below 6 functions are used throughout the driver to access scsi_command's
- * io parameters. The reason we do not use the regular accessors from
- * scsi_cmnd.h is because of gdth_execute(). Since it is unrecommended for
- * llds to directly set scsi_cmnd's IO members. This driver will use SCp
- * members for IO parameters, and will copy scsi_cmnd's members to Scp
- * members in queuecommand. For internal commands through gdth_execute()
- * SCp's members will be set directly.
- */
-static inline unsigned gdth_bufflen(struct scsi_cmnd *cmd)
-{
- return (unsigned)cmd->SCp.this_residual;
-}
-
-static inline void gdth_set_bufflen(struct scsi_cmnd *cmd, unsigned bufflen)
-{
- cmd->SCp.this_residual = bufflen;
-}
-
-static inline unsigned gdth_sg_count(struct scsi_cmnd *cmd)
-{
- return (unsigned)cmd->SCp.buffers_residual;
-}
-
-static inline void gdth_set_sg_count(struct scsi_cmnd *cmd, unsigned sg_count)
-{
- cmd->SCp.buffers_residual = sg_count;
-}
-
-static inline struct scatterlist *gdth_sglist(struct scsi_cmnd *cmd)
-{
- return cmd->SCp.buffer;
-}
-
-static inline void gdth_set_sglist(struct scsi_cmnd *cmd,
- struct scatterlist *sglist)
-{
- cmd->SCp.buffer = sglist;
-}
-
#include "gdth_proc.h"
#include "gdth_proc.c"
@@ -2349,12 +2308,12 @@ static void gdth_next(gdth_ha_str *ha)
static void gdth_copy_internal_data(gdth_ha_str *ha, Scsi_Cmnd *scp,
char *buffer, ushort count)
{
-ushort cpcount,i, max_sg = gdth_sg_count(scp);
+ushort cpcount,i, max_sg = scsi_sg_count(scp);
ushort cpsum,cpnow;
struct scatterlist *sl;
char *address;
-cpcount = min_t(ushort, count, gdth_bufflen(scp));
+cpcount = min_t(ushort, count, scsi_bufflen(scp));
if (cpcount) {
cpsum=0;
@@ -2362,7 +2321,7 @@ static void gdth_copy_internal_data(gdth_ha_str *ha,
Scsi_Cmnd *scp,
unsigned long flags;
cpnow = (ushort)sl->length;
TRACE(("copy_internal() now %d sum %d count %d %d\n",
- cpnow, cpsum, cpcount, gdth_bufflen(scp)));
+ cpnow, cpsum, cpcount, scsi_bufflen(scp)));
if (cpsum+cpnow > cpcount)
cpnow = cpcount - cpsum;
cpsum += cpnow;
@@ -2585,10 +2544,10 @@ static int gdth_fill_cache_cmd(gdth_ha_str *ha,
Scsi_Cmnd *scp, ushort hdrive)
cmdp->u.cache.BlockCnt = blockcnt;
}
-if (gdth_bufflen(scp)) {
+if (scsi_bufflen(scp)) {
cmndinfo->dma_dir = (read_write == 1 ?
PCI_DMA_TODEVICE : PCI_DMA_FROMDEVICE);
-sgcnt = pci_map_sg(ha->pdev, gdth_sglist(scp), gdth_sg_count(scp),
+sgcnt = pci_map_sg(ha->pdev, scsi_sglist(scp), scsi_sg_count(scp),
cmndinfo->dma_dir);
if (mode64) {
struct scatterlist *sl;
@@ -2735,7 +2694,7 @@ static int gdth_fill_raw_cmd(gdth_ha_str *ha, Scsi_Cmnd
*scp, unchar b)
cmdp->u.raw64.lun= l;
cmdp->u.raw64.bus= b;
cmdp->u.raw64.priority = 0;
-cmdp->u.raw64.sdlen = gdth_bufflen(scp);
+cmdp->u.raw64.sdlen = scsi_bufflen(scp);
cmdp->u.raw64.sense_len = 16;
cmdp->u.raw64.sense_data = sense_paddr;
cmdp->u.raw64.direction =
@@ -2752,7 +2711,7 @@ static int gdth_fill_raw_cmd(gdth_ha_str *ha, Scsi_Cmnd
*scp, unchar b)
cmdp->u.raw.bus= b;
cmdp->u.raw.priority = 0;
cmdp->u.raw.link_p = 0;
-cmdp->u.raw.sdlen = gdth_bufflen(scp);
+cmdp->u.raw.sdlen = scsi_bufflen(scp);
cmdp->u.raw.sense_len = 16;
cmdp->u.raw.sense_data = sense_paddr;
cmdp->u.raw.direction =
@@ -2761,9 +2720,9 @@ static int gdth_fi
[PATCH 1/5] gdth: update deprecated pci_find_device
From: Sergio Luis <[EMAIL PROTECTED]>
Fix compilation warning in gdth.c, which was using the deprecated
pci_find_device.
drivers/scsi/gdth.c:645: warning: 'pci_find_device' is deprecated (declared at
include/linux/pci.h:495)
Changing it to use pci_get_device, instead.
Signed-off-by: Sergio Luis <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
---
drivers/scsi/Kconfig |2 +-
drivers/scsi/gdth.c |7 +--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 184c7ae..46fcb82 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -725,7 +725,7 @@ config SCSI_FD_MCS
config SCSI_GDTH
tristate "Intel/ICP (former GDT SCSI Disk Array) RAID Controller
support"
- depends on (ISA || EISA || PCI) && SCSI && ISA_DMA_API && PCI_LEGACY
+ depends on (ISA || EISA || PCI) && SCSI && ISA_DMA_API
---help---
Formerly called GDT SCSI Disk Array Controller Support.
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index b253b8c..5f0e054 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -643,12 +643,15 @@ static void __init gdth_search_dev(gdth_pci_str *pcistr,
ushort *cnt,
*cnt, vendor, device));
pdev = NULL;
-while ((pdev = pci_find_device(vendor, device, pdev))
+while ((pdev = pci_get_device(vendor, device, pdev))
!= NULL) {
if (pci_enable_device(pdev))
continue;
-if (*cnt >= MAXHA)
+if (*cnt >= MAXHA) {
+pci_dev_put(pdev);
return;
+}
+
/* GDT PCI controller found, resources are already in pdev */
pcistr[*cnt].pdev = pdev;
pcistr[*cnt].irq = pdev->irq;
--
1.5.3.3
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] gdth: fix to internal commands execution
The recent patch named:
[SCSI] gdth: !use_sg cleanup and use of scsi accessors
has done a bad job in handling internal commands issued by gdth_execute().
Internal commands are issued with device gdth_cmd_str ready made directly
to the card, without any mapping or translations of scsi commands. So here
I added a gdth_cmd_str pointer to the gdth_cmndinfo private structure which
is then copied directly to host.
following this patch is a cleanup that removes the home cooked accessors
and reverts them to regular scsi_cmnd accessors. Since they are not used
anymore. After review maybe the 2 patches should be squashed together.
FIXME: There is still a problem with gdth_get_info(). as reported there
is a WARN_ON trigerd in dma_free_coherent() when doing:
$ cat /proc/sys/gdth/0
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/gdth.c | 30 --
drivers/scsi/gdth.h |1 +
2 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 0979553..077f972 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -160,7 +160,7 @@ static void gdth_readapp_event(gdth_ha_str *ha, unchar
application,
static void gdth_clear_events(void);
static void gdth_copy_internal_data(gdth_ha_str *ha, Scsi_Cmnd *scp,
-char *buffer, ushort count, int to_buffer);
+char *buffer, ushort count);
static int gdth_internal_cache_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp);
static int gdth_fill_cache_cmd(gdth_ha_str *ha, Scsi_Cmnd *scp, ushort hdrive);
@@ -439,8 +439,8 @@ static struct gdth_cmndinfo *gdth_get_cmndinfo(gdth_ha_str
*ha)
for (i=0; icmndinfo[i].index == 0) {
priv = &ha->cmndinfo[i];
- priv->index = i+1;
memset(priv, 0, sizeof(*priv));
+ priv->index = i+1;
break;
}
}
@@ -487,7 +487,6 @@ int __gdth_execute(struct scsi_device *sdev, gdth_cmd_str
*gdtcmd, char *cmnd,
gdth_ha_str *ha = shost_priv(sdev->host);
Scsi_Cmnd *scp;
struct gdth_cmndinfo cmndinfo;
-struct scatterlist one_sg;
DECLARE_COMPLETION_ONSTACK(wait);
int rval;
@@ -501,13 +500,10 @@ int __gdth_execute(struct scsi_device *sdev, gdth_cmd_str
*gdtcmd, char *cmnd,
/* use request field to save the ptr. to completion struct. */
scp->request = (struct request *)&wait;
scp->timeout_per_command = timeout*HZ;
-sg_init_one(&one_sg, gdtcmd, sizeof(*gdtcmd));
-gdth_set_sglist(scp, &one_sg);
-gdth_set_sg_count(scp, 1);
-gdth_set_bufflen(scp, sizeof(*gdtcmd));
scp->cmd_len = 12;
memcpy(scp->cmnd, cmnd, 12);
cmndinfo.priority = IOCTL_PRI;
+cmndinfo.internal_cmd_str = gdtcmd;
cmndinfo.internal_command = 1;
TRACE(("__gdth_execute() cmd 0x%x\n", scp->cmnd[0]));
@@ -2351,7 +2347,7 @@ static void gdth_next(gdth_ha_str *ha)
* buffers, kmap_atomic() as needed.
*/
static void gdth_copy_internal_data(gdth_ha_str *ha, Scsi_Cmnd *scp,
-char *buffer, ushort count, int to_buffer)
+char *buffer, ushort count)
{
ushort cpcount,i, max_sg = gdth_sg_count(scp);
ushort cpsum,cpnow;
@@ -2377,10 +2373,7 @@ static void gdth_copy_internal_data(gdth_ha_str *ha,
Scsi_Cmnd *scp,
}
local_irq_save(flags);
address = kmap_atomic(sg_page(sl), KM_BIO_SRC_IRQ) + sl->offset;
-if (to_buffer)
-memcpy(buffer, address, cpnow);
-else
-memcpy(address, buffer, cpnow);
+memcpy(address, buffer, cpnow);
flush_dcache_page(sg_page(sl));
kunmap_atomic(address, KM_BIO_SRC_IRQ);
local_irq_restore(flags);
@@ -2434,7 +2427,7 @@ static int gdth_internal_cache_cmd(gdth_ha_str *ha,
Scsi_Cmnd *scp)
strcpy(inq.vendor,ha->oem_name);
sprintf(inq.product,"Host Drive #%02d",t);
strcpy(inq.revision," ");
-gdth_copy_internal_data(ha, scp, (char*)&inq, sizeof(gdth_inq_data),
0);
+gdth_copy_internal_data(ha, scp, (char*)&inq, sizeof(gdth_inq_data));
break;
case REQUEST_SENSE:
@@ -2444,7 +2437,7 @@ static int gdth_internal_cache_cmd(gdth_ha_str *ha,
Scsi_Cmnd *scp)
sd.key = NO_SENSE;
sd.info = 0;
sd.add_length= 0;
-gdth_copy_internal_data(ha, scp, (char*)&sd, sizeof(gdth_sense_data),
0);
+gdth_copy_internal_data(ha, scp, (char*)&sd, sizeof(gdth_sense_data));
break;
case MODE_SENSE:
@@ -2456,7 +2449,7 @@ static int gdth_internal_cache_cmd(gdth_ha_str *ha,
Scsi_Cmnd *scp)
mpd.bd.block_length[0] = (SECTOR_SIZE & 0x00ff) >> 16;
mpd.bd.block_length[1] = (SECTOR_SIZE & 0xff00) >> 8;
mpd.bd.block_length[2] = (SECTOR_SIZE & 0x00ff
[PATCH 3/5] gdth: bugfix for the at-exit problems
This is a bugfix for the 2.6.24.x stable releases.
gdth_exit would first remove all cards then stop the timer
and would not sync with the timer function. This caused a crash
in gdth_timer() when module was unloaded.
So del_timer_sync the timer before we delete the cards.
also the reboot notifier function would crash. So clean
that up and fix the crashes.
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/gdth.c | 82 +-
1 files changed, 28 insertions(+), 54 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 4959037..0979553 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -183,7 +183,6 @@ static int gdth_ioctl(struct inode *inode, struct file
*filep,
unsigned int cmd, unsigned long arg);
static void gdth_flush(gdth_ha_str *ha);
-static int gdth_halt(struct notifier_block *nb, ulong event, void *buf);
static int gdth_queuecommand(Scsi_Cmnd *scp,void (*done)(Scsi_Cmnd *));
static int __gdth_queuecommand(gdth_ha_str *ha, struct scsi_cmnd *scp,
struct gdth_cmndinfo *cmndinfo);
@@ -418,12 +417,6 @@ static inline void gdth_set_sglist(struct scsi_cmnd *cmd,
#include "gdth_proc.h"
#include "gdth_proc.c"
-/* notifier block to get a notify on system shutdown/halt/reboot */
-static struct notifier_block gdth_notifier = {
-gdth_halt, NULL, 0
-};
-static int notifier_disabled = 0;
-
static gdth_ha_str *gdth_find_ha(int hanum)
{
gdth_ha_str *ha;
@@ -3796,6 +3789,8 @@ static void gdth_timeout(ulong data)
gdth_ha_str *ha;
ulong flags;
+BUG_ON(list_empty(&gdth_instances));
+
ha = list_first_entry(&gdth_instances, gdth_ha_str, list);
spin_lock_irqsave(&ha->smp_lock, flags);
@@ -4671,45 +4666,6 @@ static void gdth_flush(gdth_ha_str *ha)
}
}
-/* shutdown routine */
-static int gdth_halt(struct notifier_block *nb, ulong event, void *buf)
-{
-gdth_ha_str *ha;
-#ifndef __alpha__
-gdth_cmd_strgdtcmd;
-charcmnd[MAX_COMMAND_SIZE];
-#endif
-
-if (notifier_disabled)
-return NOTIFY_OK;
-
-TRACE2(("gdth_halt() event %d\n",(int)event));
-if (event != SYS_RESTART && event != SYS_HALT && event != SYS_POWER_OFF)
-return NOTIFY_DONE;
-
-notifier_disabled = 1;
-printk("GDT-HA: Flushing all host drives .. ");
-list_for_each_entry(ha, &gdth_instances, list) {
-gdth_flush(ha);
-
-#ifndef __alpha__
-/* controller reset */
-memset(cmnd, 0xff, MAX_COMMAND_SIZE);
-gdtcmd.BoardNode = LOCALBOARD;
-gdtcmd.Service = CACHESERVICE;
-gdtcmd.OpCode = GDT_RESET;
-TRACE2(("gdth_halt(): reset controller %d\n", ha->hanum));
-gdth_execute(ha->shost, &gdtcmd, cmnd, 10, NULL);
-#endif
-}
-printk("Done.\n");
-
-#ifdef GDTH_STATISTICS
-del_timer(&gdth_timer);
-#endif
-return NOTIFY_OK;
-}
-
/* configure lun */
static int gdth_slave_configure(struct scsi_device *sdev)
{
@@ -5144,13 +5100,13 @@ static void gdth_remove_one(gdth_ha_str *ha)
scsi_remove_host(shp);
+ gdth_flush(ha);
+
if (ha->sdev) {
scsi_free_host_dev(ha->sdev);
ha->sdev = NULL;
}
- gdth_flush(ha);
-
if (shp->irq)
free_irq(shp->irq,ha);
@@ -5176,6 +5132,24 @@ static void gdth_remove_one(gdth_ha_str *ha)
scsi_host_put(shp);
}
+static int gdth_halt(struct notifier_block *nb, ulong event, void *buf)
+{
+ gdth_ha_str *ha;
+
+ TRACE2(("gdth_halt() event %d\n", (int)event));
+ if (event != SYS_RESTART && event != SYS_HALT && event != SYS_POWER_OFF)
+ return NOTIFY_DONE;
+
+ list_for_each_entry(ha, &gdth_instances, list)
+ gdth_flush(ha);
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block gdth_notifier = {
+gdth_halt, NULL, 0
+};
+
static int __init gdth_init(void)
{
if (disable) {
@@ -5238,7 +5212,6 @@ static int __init gdth_init(void)
add_timer(&gdth_timer);
#endif
major = register_chrdev(0,"gdth", &gdth_fops);
- notifier_disabled = 0;
register_reboot_notifier(&gdth_notifier);
gdth_polling = FALSE;
return 0;
@@ -5248,14 +5221,15 @@ static void __exit gdth_exit(void)
{
gdth_ha_str *ha;
- list_for_each_entry(ha, &gdth_instances, list)
- gdth_remove_one(ha);
+ unregister_chrdev(major, "gdth");
+ unregister_reboot_notifier(&gdth_notifier);
#ifdef GDTH_STATISTICS
- del_timer(&gdth_timer);
+ del_timer_sync(&gdth_timer);
#endif
- unregister_chrdev(major,"gdth");
- unregister_reboot_notifier(&gdth_notifier);
+
+ list_for_each_entry(ha, &gdth_instances, list)
+ gdth_remove_one(ha);
}
module_init(gdth_init);
--
1.5.3.3
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAI
[PATCH 2/5] gdth: scan for scsi devices
The patch: "gdth: switch to modern scsi host registration" missed one simple fact when moving a way from scsi_module.c. That is to call scsi_scan_host() on the probed host. With this the gdth driver from 2.6.24 is again able to see drives and boot. Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]> Tested-by: Joerg Dorchain: <[EMAIL PROTECTED]> Tested-by: Stefan Priebe <[EMAIL PROTECTED]> Tested-by: Jon Chelton <[EMAIL PROTECTED]> --- drivers/scsi/gdth.c |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c index 5f0e054..4959037 100644 --- a/drivers/scsi/gdth.c +++ b/drivers/scsi/gdth.c @@ -4841,6 +4841,9 @@ static int __init gdth_isa_probe_one(ulong32 isa_bios) if (error) goto out_free_coal_stat; list_add_tail(&ha->list, &gdth_instances); + + scsi_scan_host(shp); + return 0; out_free_coal_stat: @@ -4968,6 +4971,9 @@ static int __init gdth_eisa_probe_one(ushort eisa_slot) if (error) goto out_free_coal_stat; list_add_tail(&ha->list, &gdth_instances); + + scsi_scan_host(shp); + return 0; out_free_ccb_phys: @@ -5105,6 +5111,9 @@ static int __init gdth_pci_probe_one(gdth_pci_str *pcistr, int ctr) if (error) goto out_free_coal_stat; list_add_tail(&ha->list, &gdth_instances); + + scsi_scan_host(shp); + return 0; out_free_coal_stat: -- 1.5.3.3 - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
gdth new set of patches for 2.6.24 stable
Submitted are a new set of patches, that fix lots of problems with the gdth driver. It fixes the following problems: - scan for drives on hosts. (Already in mainline) - truly fixes the exit/reboot problems but does call flush() before reboot. - fix crash when accessing array with icpcon management application. - fix crash when doing $ cat /proc/sys/gdth/0. This one still has the below WARN_ON in messages (see below) So there is one more thing hiding in there. - use pci_get_device One of the testers requested if we can also put the move to pci_get_device patch with removal of dependency on PCI_LEGACY, to the stable release. The patches are for and based on Linux-2.6.24. here is the list of patches: [PATCH 1/5] gdth: update deprecated pci_find_device [PATCH 2/5] gdth: scan for scsi devices [PATCH 3/5] gdth: bugfix for the at-exit problems [PATCH 4/5] gdth: fix to internal commands execution [PATCH 5/5] gdth: remove gdth cooked up command accessors Please all test and report your findings. Thanks in advance Boaz --- WARNING: at arch/x86/kernel/pci-dma_32.c:66 dma_free_coherent() Pid: 5501, comm: cat Not tainted 2.6.24 #43 [] dma_free_coherent+0x93/0x95 [] gdth_ioctl_free+0x4c/0x69 [] gdth_proc_info+0x165f/0x182c [] update_curr+0xeb/0xf2 [] task_rq_lock+0x29/0x50 [] try_to_wake_up+0x42/0x342 [] try_to_wake_up+0x42/0x342 [] __wake_up_common+0x46/0x6d [] __wake_up+0x32/0x42 [] n_tty_receive_buf+0x2e8/0xe97 [] n_tty_receive_buf+0x2e8/0xe97 [] update_curr+0x7b/0xf2 [] enqueue_task_fair+0x27/0x30 [] enqueue_task+0xa/0x14 [] proc_scsi_read+0x29/0x3d [] proc_scsi_read+0x0/0x3d [] proc_file_read+0x1c6/0x279 [] proc_file_read+0x0/0x279 [] proc_reg_read+0x53/0x71 [] proc_reg_read+0x0/0x71 [] vfs_read+0x85/0x11b [] sys_read+0x41/0x6a [] sysenter_past_esp+0x5f/0x85 - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] iscsi iser: remove DMA restrictions
Mike Christie wrote: James Bottomley wrote: On Thu, 2008-02-14 at 11:56 -0600, Mike Christie wrote: You really don't want to do this. That signals to the block layer that we have an iommu, although it's practically the same thing as a 64 bit DMA mask ... but I'd just leave it to the DMA mask to set this up correctly. Anything else is asking for a subtle bug to turn up years from now when something causes the mask and the limit to be mismatched. I thought BLK_BOUNCE_ANY just meant "don't bounce anything" (that was from the blkdev.h comments). It does ... that's why it's used in the IOMMU case ... and why it's practically the same as a 64 bit mask. We used it for iscsi_tcp because the network layer can take any type of page and will do the right thing for the hardware it eventually gets sent to. Right, to you it means never bounce because net wants to do it instead. However, I don't think that's the case for iSER, is it? ... as in, if I will leave that to Roland and them :) My only concern with a simple patch to use the ib interface's dma values would be, if there is some event that causes us to start using inteface ib0 then switch to ib1 (maybe like some sort of route table change if that is possible), then we will have to loop over all the scsi devices's queues and update the dma values. And if there is IO already queued then would we have to possible rebuild those commands if something like the dma_mask changed? I guess we can just handle this like how FC handles the case when the dev loss tmo expires, but then the rport comes back later. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] scsi_transport_iscsi.c: make 2 functions static
Adrian Bunk wrote: This patch makes the following needlessly global functions static: - __iscsi_unblock_session() - iscsi_session_state_name() Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Looks good. Thanks. Acked-by: Mike Christie <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] iscsi iser: remove DMA restrictions
James Bottomley wrote: On Thu, 2008-02-14 at 11:56 -0600, Mike Christie wrote: You really don't want to do this. That signals to the block layer that we have an iommu, although it's practically the same thing as a 64 bit DMA mask ... but I'd just leave it to the DMA mask to set this up correctly. Anything else is asking for a subtle bug to turn up years from now when something causes the mask and the limit to be mismatched. I thought BLK_BOUNCE_ANY just meant "don't bounce anything" (that was from the blkdev.h comments). It does ... that's why it's used in the IOMMU case ... and why it's practically the same as a 64 bit mask. We used it for iscsi_tcp because the network layer can take any type of page and will do the right thing for the hardware it eventually gets sent to. Right, to you it means never bounce because net wants to do it instead. However, I don't think that's the case for iSER, is it? ... as in, if I will leave that to Roland and them :) My only concern with a simple patch to use the ib interface's dma values would be, if there is some event that causes us to start using inteface ib0 then switch to ib1 (maybe like some sort of route table change if that is possible), then we will have to loop over all the scsi devices's queues and update the dma values. And if there is IO already queued then would we have to possible rebuild those commands if something like the dma_mask changed? I've got the pathway tracing correct, it just goes to the infiniband device and gets mapped there. If there's a mask mismatch (very unlikely, I know) we get a very subtle and hard to trace error. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] iscsi iser: remove DMA restrictions
On Thu, 2008-02-14 at 11:56 -0600, Mike Christie wrote: > > You really don't want to do this. That signals to the block layer that > > we have an iommu, although it's practically the same thing as a 64 bit > > DMA mask ... but I'd just leave it to the DMA mask to set this up > > correctly. Anything else is asking for a subtle bug to turn up years > > from now when something causes the mask and the limit to be mismatched. > > > > I thought BLK_BOUNCE_ANY just meant "don't bounce anything" (that was > from the blkdev.h comments). It does ... that's why it's used in the IOMMU case ... and why it's practically the same as a 64 bit mask. > We used it for iscsi_tcp because the network layer can take any type > of page and will do the right thing for the hardware it eventually > gets sent to. Right, to you it means never bounce because net wants to do it instead. However, I don't think that's the case for iSER, is it? ... as in, if I've got the pathway tracing correct, it just goes to the infiniband device and gets mapped there. If there's a mask mismatch (very unlikely, I know) we get a very subtle and hard to trace error. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] iscsi iser: remove DMA restrictions
James Bottomley wrote:
On Tue, 2008-02-12 at 15:54 -0500, Pete Wyckoff wrote:
iscsi_iser does not have any hardware DMA restrictions. Add a
slave_configure function to remove any DMA alignment restriction,
allowing the use of direct IO from arbitrary offsets within a page.
Also disable page bouncing; iser has no restrictions on which pages it
can address.
Signed-off-by: Pete Wyckoff <[EMAIL PROTECTED]>
---
drivers/infiniband/ulp/iser/iscsi_iser.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/ulp/iser/iscsi_iser.c
b/drivers/infiniband/ulp/iser/iscsi_iser.c
index be1b9fb..1b272a6 100644
--- a/drivers/infiniband/ulp/iser/iscsi_iser.c
+++ b/drivers/infiniband/ulp/iser/iscsi_iser.c
@@ -543,6 +543,13 @@ iscsi_iser_ep_disconnect(__u64 ep_handle)
iser_conn_terminate(ib_conn);
}
+static int iscsi_iser_slave_configure(struct scsi_device *sdev)
+{
+ blk_queue_bounce_limit(sdev->request_queue, BLK_BOUNCE_ANY);
You really don't want to do this. That signals to the block layer that
we have an iommu, although it's practically the same thing as a 64 bit
DMA mask ... but I'd just leave it to the DMA mask to set this up
correctly. Anything else is asking for a subtle bug to turn up years
from now when something causes the mask and the limit to be mismatched.
I thought BLK_BOUNCE_ANY just meant "don't bounce anything" (that was
from the blkdev.h comments). We used it for iscsi_tcp because the
network layer can take any type of page and will do the right thing for
the hardware it eventually gets sent to.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gdth: bugfix for the at-exit problems
On Thu, Feb 14 2008 at 18:10 +0200, James Bottomley <[EMAIL PROTECTED]> wrote: > On Thu, 2008-02-14 at 13:58 +0200, Boaz Harrosh wrote: >> This is a bugfix for the 2.6.24.x stable releases. >> >> gdth_exit would first remove all cards then stop the timer >> and would not sync with the timer function. This caused a crash >> in gdth_timer() when module was unloaded. >> So del_timer_sync the timer before we delete the cards. >> >> also the reboot notifier function would crash. So unify >> the exit and halt functions with a gdth_shutdown() that's >> called by both. > > The patch looks fine now, thanks. Can we actually get a tester just to > make sure there's nothing I missed. > > James > > Yes, and the tester reported, a breakage. We are on it. Apparently, you cannot do a full deallocation of resources at reboot notifier, nor would you want to I guess. But you can do the flush. The exit call is never called on a reboot and the card access is valid to the end. Please comment? So I pretty much reverted that patch, but did leave some cleanups. Also we found the other problems reported with user-mode tools and cat /proc/sys/gdth/0 so 2 patches on the way above reverted. Give us a few ours to test every thing. Thanks Boaz - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gdth: bugfix for the at-exit problems
On Thu, 2008-02-14 at 13:58 +0200, Boaz Harrosh wrote: > This is a bugfix for the 2.6.24.x stable releases. > > gdth_exit would first remove all cards then stop the timer > and would not sync with the timer function. This caused a crash > in gdth_timer() when module was unloaded. > So del_timer_sync the timer before we delete the cards. > > also the reboot notifier function would crash. So unify > the exit and halt functions with a gdth_shutdown() that's > called by both. The patch looks fine now, thanks. Can we actually get a tester just to make sure there's nothing I missed. James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: aic94xx: failing on high load (another data point)
On 01/31/2008 03:29 AM, Darrick J. Wong wrote: > On Wed, Jan 30, 2008 at 06:59:34PM +0800, Keith Hopkins wrote: >> V28. My controller functions well with a single drive (low-medium load). >> Unfortunately, all attempts to get the mirrors in sync fail and usually hang >> the whole box. > > Adaptec posted a V30 sequencer on their website; does that fix the > problems? > > http://www.adaptec.com/en-US/speed/scsi/linux/aic94xx-seq-30-1_tar_gz.htm > I lost connectivity to the drive again, and had to reboot to recover the drive, so it seemed a good time to try out the V30 firmware. Unfortunately, it didn't work any better. Details are in the attachment. --Keith Running V28 Firmware Feb 14 21:45:55 titan syslog-ng[28369]: STATS: dropped 60 Feb 14 21:47:59 titan kernel: sd 0:0:1:0: rejecting I/O to offline device Feb 14 21:47:59 titan kernel: raid1: sdb2: rescheduling sector 0 Feb 14 21:47:59 titan kernel: sd 0:0:1:0: rejecting I/O to offline device Feb 14 21:47:59 titan kernel: sd 0:0:1:0: rejecting I/O to offline device Feb 14 21:47:59 titan kernel: raid1: Disk failure on sdb2, disabling device. Feb 14 21:47:59 titan kernel: Operation continuing on 1 devices Feb 14 21:47:59 titan kernel: raid1: sda2: redirecting sector 0 to another mirror Feb 14 21:47:59 titan kernel: RAID1 conf printout: Feb 14 21:47:59 titan kernel: --- wd:1 rd:2 Feb 14 21:47:59 titan kernel: disk 0, wo:1, o:0, dev:sdb2 Feb 14 21:47:59 titan kernel: disk 1, wo:0, o:1, dev:sda2 Feb 14 21:47:59 titan kernel: RAID1 conf printout: Feb 14 21:47:59 titan kernel: --- wd:1 rd:2 Feb 14 21:47:59 titan kernel: disk 1, wo:0, o:1, dev:sda2 Feb 14 21:50:08 titan smartd[28072]: Device: /dev/sdb, No such device or address, open() failed V30 Firmware was installed in OS via rpm. Ran mkinitrd and... == manually reboot to get drive back online == (lots of kruft removed) Linux version 2.6.22.16-0.1-default ([EMAIL PROTECTED]) (gcc version 4.2.1 (SUSE Linux)) #1 SMP 2008/01/23 14:28:52 UTC Command line: root=/dev/vgtitan/lvroot vga=0x346 noresume splash=silent PROFILE=default profile=default [EMAIL PROTECTED] splash=off nosplash SMP: Allowing 8 CPUs, 0 hotplug CPUs Kernel command line: root=/dev/vgtitan/lvroot vga=0x346 noresume splash=silent PROFILE=default profile=default [EMAIL PROTECTED] splash=off nosplash bootsplash: silent mode. Initializing CPU#0 time.c: Detected 2327.500 MHz processor. Memory: 14256200k/15728640k available (2053k kernel code, 422808k reserved, 1017k data, 316k init) CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 4096K CPU 0/0 -> Node 0 using mwait in idle threads. CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 CPU0: Thermal monitoring handled by SMI SMP alternatives: switching to UP code Unpacking initramfs... done Freeing initrd memory: 4931k freed ACPI: Core revision 20070126 Brought up 8 CPUs io scheduler cfq registered (default) Boot video device is :08:00.0 Freeing unused kernel memory: 316k freed ACPI Error (dsopcode-0250): No pointer back to NS node in buffer obj 8103b0131c60 [20070126] ACPI Error (psparse-0537): Method parse/execution failed [\_PR_.CPU0._PDC] (Node 8103b0ae0770), AE_AML_INTERNAL ACPI: Processor [CPU0] (supports 8 throttling states) md: raid1 personality registered for level 1 device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: [EMAIL PROTECTED] BIOS EDD facility v0.16 2004-Jun-25, 4 devices found SCSI subsystem initialized aic94xx: Adaptec aic94xx SAS/SATA driver version 1.0.3 loaded ACPI: PCI Interrupt :05:02.0[A] -> GSI 16 (level, low) -> IRQ 16 aic94xx: found Adaptec AIC-9410W SAS/SATA Host Adapter, device :05:02.0 scsi0 : aic94xx aic94xx: BIOS present (1,1), 1918 aic94xx: ue num:2, ue size:88 aic94xx: manuf sect SAS_ADDR 5d10002d9380 aic94xx: manuf sect PCBA SN 0BB0C54904VA aic94xx: ms: num_phy_desc: 8 aic94xx: ms: phy0: ENABLED aic94xx: ms: phy1: ENABLED aic94xx: ms: phy2: ENABLED aic94xx: ms: phy3: ENABLED aic94xx: ms: phy4: ENABLED aic94xx: ms: phy5: ENABLED aic94xx: ms: phy6: ENABLED aic94xx: ms: phy7: ENABLED aic94xx: ms: max_phys:0x8, num_phys:0x8 aic94xx: ms: enabled_phys:0xff aic94xx: ctrla: phy0: sas_addr: 5d10002d9380, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0 aic94xx: ctrla: phy1: sas_addr: 5d10002d9380, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0 aic94xx: ctrla: phy2: sas_addr: 5d10002d9380, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0 aic94xx: ctrla: phy3: sas_addr: 5d10002d9380, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0 aic94xx: ctrla: phy4: sas_addr: 5d10002d9380, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0 aic94xx: ctrla: phy5: sas_addr: 5d10002d9380, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0 aic94xx: ctrla: phy6: sas_addr: 5d10002d9380, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0 aic94xx: ctrla: phy7: sas_addr: 5d10002d9380, sas rate:0x9-0x8, sata rate:0x0-0x0, flags:0x0 aic94xx: max_scbs:512, max_ddbs:128 aic94xx: setting phy0 addr to 5d1
Re: [BUGFIX 2/2] gdth: bugfix for the Timer at exit crash
On Wed, Feb 13 2008 at 21:38 +0200, Jan Engelhardt <[EMAIL PROTECTED]> wrote: > On Feb 13 2008 11:03, Boaz Harrosh wrote: >>> I've tested this patch now - and it works fine. Now rmmod, halt and >>> reboot also works. >>> >>> Stefan Priebe >>> >> This is grate news Stefan. Thank you very much for all your time >> and effort, with out we could not have fixed all this. > > Do you have a git tree with the latest pieces? No, scsi-misc I guess ;) I could put it here: git://git.bhalevy.com/open-osd gdth branch give me an hours Boaz - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Advansys regression between 2.6.23.8 and 2.6.24.2
On Thu, 2008-02-14 at 16:10 +0100, Thomas Petazzoni wrote: > I just upgraded my system from 2.6.23.8 to 2.6.24.2, and when loading > the advansys module, it paniced, with "Kernel BUG at advansys.c:6335". > The issue is that the overrun buffer is not aligned on 8 bytes. > > The patch 7d5d408c77cee95d1380511de46b7a4c8dc2211d [1], by FUJITA > Tomonori, which has been committed a few days ago, fixes the issue. The > commit log says that the structure should be 8-byte aligned on 2.6.23 > and 2.6.24, but it doesn't seem to be the case in 2.6.24. I have not > identified which commit broke the driver, but I confirm that Tomonori's > patch fixes the problem. > > I've added Greg and Chris as Cc: because such a patch should probably > be included in the next -stable of 2.6.24, but of course Tomonori and > Matthew are best placed to say what should be done. Yes, it's already on its way to stable. The process requires the fix to be committed upstream first. There's an automated script that sends these commits back to stable once they're upstream (provided they're tagged correctly). James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "mount: could not find filesystem" - aacraid? (was: Re: 2.6.26-git0: IDE oops during boot)
On Thu, 2008-02-14 at 13:07 +0100, Bartlomiej Zolnierkiewicz wrote: > > I worry that another git-bisect session will be needed unless SCSI > > developers are already aware of the problem source. > > Yinghai Lu noticed that it may be actually a SES problem: > > http://lkml.org/lkml/2008/2/14/88 > > [ I overlooked the above mail, sorry ] Only if SES is enabled, is it (CONFIG_SCSI_ENCLOSURE)? ... is there actually a dmesg of the failing system somewhere, I couldn't find it in the (somewhat long) thread? James - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Advansys regression between 2.6.23.8 and 2.6.24.2
Le Thu, 14 Feb 2008 16:10:24 +0100, Thomas Petazzoni <[EMAIL PROTECTED]> a écrit : > I have not identified which commit broke the driver, but I confirm > that Tomonori's patch fixes the problem. I suspect that the issue has been introduced by d10fb2c7b5ce1b475df50cde9262d2c3fe3d296e, added in 2.6.24 by Matthew. Sincerly, Thomas -- Thomas Petazzoni, Free Electrons Free Embedded Linux Training Materials on http://free-electrons.com/training (More than 1500 pages!) signature.asc Description: PGP signature
Advansys regression between 2.6.23.8 and 2.6.24.2
Hi, I just upgraded my system from 2.6.23.8 to 2.6.24.2, and when loading the advansys module, it paniced, with "Kernel BUG at advansys.c:6335". The issue is that the overrun buffer is not aligned on 8 bytes. The patch 7d5d408c77cee95d1380511de46b7a4c8dc2211d [1], by FUJITA Tomonori, which has been committed a few days ago, fixes the issue. The commit log says that the structure should be 8-byte aligned on 2.6.23 and 2.6.24, but it doesn't seem to be the case in 2.6.24. I have not identified which commit broke the driver, but I confirm that Tomonori's patch fixes the problem. I've added Greg and Chris as Cc: because such a patch should probably be included in the next -stable of 2.6.24, but of course Tomonori and Matthew are best placed to say what should be done. Thanks, Thomas [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7d5d408c77cee95d1380511de46b7a4c8dc2211d -- Thomas Petazzoni, Free Electrons Free Embedded Linux Training Materials on http://free-electrons.com/training (More than 1500 pages!) signature.asc Description: PGP signature
Re: [SCSI] gdth: update deprecated pci_find_device
On 02/14/2008 03:50 PM, James Bottomley wrote:
On Wed, 2008-02-13 at 23:43 -0500, Jeff Garzik wrote:
Linux Kernel Mailing List wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99109301d103fbf0de43fc5a580a406c12a501e0
Commit: 99109301d103fbf0de43fc5a580a406c12a501e0
Parent: 61c92814dc324b541391757062ff02fbf3b08086
Author: Sergio Luis <[EMAIL PROTECTED]>
AuthorDate: Tue Feb 12 20:48:03 2008 -0300
Committer: James Bottomley <[EMAIL PROTECTED]>
CommitDate: Wed Feb 13 09:33:10 2008 -0600
[SCSI] gdth: update deprecated pci_find_device
Fix compilation warning in gdth.c, which was using the deprecated
pci_find_device.
drivers/scsi/gdth.c:645: warning: 'pci_find_device' is deprecated (declared at include/linux/pci.h:495)
Changing it to use pci_get_device, instead.
Signed-off-by: Sergio Luis <[EMAIL PROTECTED]>
Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
---
drivers/scsi/Kconfig |2 +-
drivers/scsi/gdth.c |7 +--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index a5f0aaa..a7a0813 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -722,7 +722,7 @@ config SCSI_FD_MCS
config SCSI_GDTH
tristate "Intel/ICP (former GDT SCSI Disk Array) RAID Controller
support"
- depends on (ISA || EISA || PCI) && SCSI && ISA_DMA_API && PCI_LEGACY
+ depends on (ISA || EISA || PCI) && SCSI && ISA_DMA_API
---help---
Formerly called GDT SCSI Disk Array Controller Support.
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 7079fef..6d67f5c 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -642,12 +642,15 @@ static void __init gdth_search_dev(gdth_pci_str *pcistr,
ushort *cnt,
*cnt, vendor, device));
pdev = NULL;
-while ((pdev = pci_find_device(vendor, device, pdev))
+while ((pdev = pci_get_device(vendor, device, pdev))
!= NULL) {
if (pci_enable_device(pdev))
continue;
-if (*cnt >= MAXHA)
+if (*cnt >= MAXHA) {
+pci_dev_put(pdev);
return;
+}
+
Why no pci_dev_put() in the module cleanup path?
Because the pci dev is never got ... nasty I know, but it's the way this
driver works.
Then the change fixes nothing from my point of view. The core might drop the
device from the system at any time after pci_get_device()'s next call.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "gdth: update deprecated pci_find_device" is incorrect
On 02/14/2008 03:47 PM, Jiri Slaby wrote: On 02/14/2008 03:44 PM, Jiri Slaby wrote: commit 99109301d103fbf0de43fc5a580a406c12a501e0 in jejb/scsi-rc-fixes-2.6.git is incorrect. You don't decrement pci [...] BTW if you have more than one card, you protected the driver from no race, since you don't pci_dev_get of successfully grabbed cards. (this still holds) - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "gdth: update deprecated pci_find_device" is incorrect
On 02/14/2008 03:47 PM, Jiri Slaby wrote: On 02/14/2008 03:44 PM, Jiri Slaby wrote: Hi, commit 99109301d103fbf0de43fc5a580a406c12a501e0 in jejb/scsi-rc-fixes-2.6.git is incorrect. You don't decrement pci refcount on exit. Also you do not so on fail paths... I wonder why these mistakes happen every second time somebody tries to do such change. It leaked into mainline yet after "whole" two days, but what exactly drives me crazy is, that Jeff commented it in similar way and nobody reflected it! Yeah, you did (I read the thread on wrong server obviusly), sorry... - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [SCSI] gdth: update deprecated pci_find_device
On Wed, 2008-02-13 at 23:43 -0500, Jeff Garzik wrote:
> Linux Kernel Mailing List wrote:
> > Gitweb:
> > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=99109301d103fbf0de43fc5a580a406c12a501e0
> > Commit: 99109301d103fbf0de43fc5a580a406c12a501e0
> > Parent: 61c92814dc324b541391757062ff02fbf3b08086
> > Author: Sergio Luis <[EMAIL PROTECTED]>
> > AuthorDate: Tue Feb 12 20:48:03 2008 -0300
> > Committer: James Bottomley <[EMAIL PROTECTED]>
> > CommitDate: Wed Feb 13 09:33:10 2008 -0600
> >
> > [SCSI] gdth: update deprecated pci_find_device
> >
> > Fix compilation warning in gdth.c, which was using the deprecated
> > pci_find_device.
> >
> > drivers/scsi/gdth.c:645: warning: 'pci_find_device' is deprecated
> > (declared at include/linux/pci.h:495)
> >
> > Changing it to use pci_get_device, instead.
> >
> > Signed-off-by: Sergio Luis <[EMAIL PROTECTED]>
> > Signed-off-by: James Bottomley <[EMAIL PROTECTED]>
> > ---
> > drivers/scsi/Kconfig |2 +-
> > drivers/scsi/gdth.c |7 +--
> > 2 files changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> > index a5f0aaa..a7a0813 100644
> > --- a/drivers/scsi/Kconfig
> > +++ b/drivers/scsi/Kconfig
> > @@ -722,7 +722,7 @@ config SCSI_FD_MCS
> >
> > config SCSI_GDTH
> > tristate "Intel/ICP (former GDT SCSI Disk Array) RAID Controller
> > support"
> > - depends on (ISA || EISA || PCI) && SCSI && ISA_DMA_API && PCI_LEGACY
> > + depends on (ISA || EISA || PCI) && SCSI && ISA_DMA_API
> > ---help---
> > Formerly called GDT SCSI Disk Array Controller Support.
> >
> > diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
> > index 7079fef..6d67f5c 100644
> > --- a/drivers/scsi/gdth.c
> > +++ b/drivers/scsi/gdth.c
> > @@ -642,12 +642,15 @@ static void __init gdth_search_dev(gdth_pci_str
> > *pcistr, ushort *cnt,
> >*cnt, vendor, device));
> >
> > pdev = NULL;
> > -while ((pdev = pci_find_device(vendor, device, pdev))
> > +while ((pdev = pci_get_device(vendor, device, pdev))
> > != NULL) {
> > if (pci_enable_device(pdev))
> > continue;
> > -if (*cnt >= MAXHA)
> > +if (*cnt >= MAXHA) {
> > +pci_dev_put(pdev);
> > return;
> > +}
> > +
>
> Why no pci_dev_put() in the module cleanup path?
Because the pci dev is never got ... nasty I know, but it's the way this
driver works.
the while (pci_get_device()) runs until the device returned is NULL. At
that point, every PCI device it ever returned has been put. The only
problem is premature exit from the while loop, which is why I made the
original author do a put along that path.
James
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "gdth: update deprecated pci_find_device" is incorrect
On 02/14/2008 03:44 PM, Jiri Slaby wrote: Hi, commit 99109301d103fbf0de43fc5a580a406c12a501e0 in jejb/scsi-rc-fixes-2.6.git is incorrect. You don't decrement pci refcount on exit. Also you do not so on fail paths... I wonder why these mistakes happen every second time somebody tries to do such change. It leaked into mainline yet after "whole" two days, but what exactly drives me crazy is, that Jeff commented it in similar way and nobody reflected it! BTW if you have more than one card, you protected the driver from no race, since you don't pci_dev_get of successfully grabbed cards. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
"gdth: update deprecated pci_find_device" is incorrect
Hi, commit 99109301d103fbf0de43fc5a580a406c12a501e0 in jejb/scsi-rc-fixes-2.6.git is incorrect. You don't decrement pci refcount on exit. Also you do not so on fail paths... I wonder why these mistakes happen every second time somebody tries to do such change. It leaked into mainline yet after "whole" two days, but what exactly drives me crazy is, that Jeff commented it in similar way and nobody reflected it! - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gdth: bugfix for the at-exit problems
This is a bugfix for the 2.6.24.x stable releases.
gdth_exit would first remove all cards then stop the timer
and would not sync with the timer function. This caused a crash
in gdth_timer() when module was unloaded.
So del_timer_sync the timer before we delete the cards.
also the reboot notifier function would crash. So unify
the exit and halt functions with a gdth_shutdown() that's
called by both.
Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
---
drivers/scsi/gdth.c | 90 --
1 files changed, 36 insertions(+), 54 deletions(-)
diff --git a/drivers/scsi/gdth.c b/drivers/scsi/gdth.c
index 8eb78be..3828b23 100644
--- a/drivers/scsi/gdth.c
+++ b/drivers/scsi/gdth.c
@@ -183,7 +183,6 @@ static int gdth_ioctl(struct inode *inode, struct file
*filep,
unsigned int cmd, unsigned long arg);
static void gdth_flush(gdth_ha_str *ha);
-static int gdth_halt(struct notifier_block *nb, ulong event, void *buf);
static int gdth_queuecommand(Scsi_Cmnd *scp,void (*done)(Scsi_Cmnd *));
static int __gdth_queuecommand(gdth_ha_str *ha, struct scsi_cmnd *scp,
struct gdth_cmndinfo *cmndinfo);
@@ -418,12 +417,6 @@ static inline void gdth_set_sglist(struct scsi_cmnd *cmd,
#include "gdth_proc.h"
#include "gdth_proc.c"
-/* notifier block to get a notify on system shutdown/halt/reboot */
-static struct notifier_block gdth_notifier = {
-gdth_halt, NULL, 0
-};
-static int notifier_disabled = 0;
-
static gdth_ha_str *gdth_find_ha(int hanum)
{
gdth_ha_str *ha;
@@ -3793,6 +3786,8 @@ static void gdth_timeout(ulong data)
gdth_ha_str *ha;
ulong flags;
+BUG_ON(list_empty(&gdth_instances));
+
ha = list_first_entry(&gdth_instances, gdth_ha_str, list);
spin_lock_irqsave(&ha->smp_lock, flags);
@@ -4668,45 +4663,6 @@ static void gdth_flush(gdth_ha_str *ha)
}
}
-/* shutdown routine */
-static int gdth_halt(struct notifier_block *nb, ulong event, void *buf)
-{
-gdth_ha_str *ha;
-#ifndef __alpha__
-gdth_cmd_strgdtcmd;
-charcmnd[MAX_COMMAND_SIZE];
-#endif
-
-if (notifier_disabled)
-return NOTIFY_OK;
-
-TRACE2(("gdth_halt() event %d\n",(int)event));
-if (event != SYS_RESTART && event != SYS_HALT && event != SYS_POWER_OFF)
-return NOTIFY_DONE;
-
-notifier_disabled = 1;
-printk("GDT-HA: Flushing all host drives .. ");
-list_for_each_entry(ha, &gdth_instances, list) {
-gdth_flush(ha);
-
-#ifndef __alpha__
-/* controller reset */
-memset(cmnd, 0xff, MAX_COMMAND_SIZE);
-gdtcmd.BoardNode = LOCALBOARD;
-gdtcmd.Service = CACHESERVICE;
-gdtcmd.OpCode = GDT_RESET;
-TRACE2(("gdth_halt(): reset controller %d\n", ha->hanum));
-gdth_execute(ha->shost, &gdtcmd, cmnd, 10, NULL);
-#endif
-}
-printk("Done.\n");
-
-#ifdef GDTH_STATISTICS
-del_timer(&gdth_timer);
-#endif
-return NOTIFY_OK;
-}
-
/* configure lun */
static int gdth_slave_configure(struct scsi_device *sdev)
{
@@ -5141,13 +5097,13 @@ static void gdth_remove_one(gdth_ha_str *ha)
scsi_remove_host(shp);
+ gdth_flush(ha);
+
if (ha->sdev) {
scsi_free_host_dev(ha->sdev);
ha->sdev = NULL;
}
- gdth_flush(ha);
-
if (shp->irq)
free_irq(shp->irq,ha);
@@ -5173,6 +5129,22 @@ static void gdth_remove_one(gdth_ha_str *ha)
scsi_host_put(shp);
}
+static void gdth_shutdown(void);
+static int gdth_halt(struct notifier_block *nb, ulong event, void *buf)
+{
+ TRACE2(("gdth_halt() event %d\n", (int)event));
+ if (event != SYS_RESTART && event != SYS_HALT && event != SYS_POWER_OFF)
+ return NOTIFY_DONE;
+
+ gdth_shutdown();
+ return NOTIFY_OK;
+}
+
+static struct notifier_block gdth_notifier = {
+gdth_halt, NULL, 0
+};
+static bool gdth_shutdown_done;
+
static int __init gdth_init(void)
{
if (disable) {
@@ -5185,6 +5157,7 @@ static int __init gdth_init(void)
GDTH_VERSION_STR);
/* initializations */
+ gdth_shutdown_done = false;
gdth_polling = TRUE;
gdth_clear_events();
@@ -5235,23 +5208,32 @@ static int __init gdth_init(void)
add_timer(&gdth_timer);
#endif
major = register_chrdev(0,"gdth", &gdth_fops);
- notifier_disabled = 0;
register_reboot_notifier(&gdth_notifier);
gdth_polling = FALSE;
return 0;
}
-static void __exit gdth_exit(void)
+static void gdth_shutdown()
{
gdth_ha_str *ha;
- list_for_each_entry(ha, &gdth_instances, list)
- gdth_remove_one(ha);
+ if (gdth_shutdown_done)
+ return;
+
+ gdth_shutdown_done = true;
+ unregister_chrdev(major, "gdth");
#ifdef GDTH_STATISTICS
- del_timer(&gdth_timer);
+ del_timer_sync(&gdth_timer);
#endif
- unregister_chrdev(major,"gdth");
+
Re: [PATCH] bsg: bidi bio map failure fix
On Tue, 12 Feb 2008 15:40:24 -0500
Pete Wyckoff <[EMAIL PROTECTED]> wrote:
> If blk_rq_map_user requires more than one bio, and fails mapping
> somewhere after the first bio, it will return with rq->bio set to
> non-NULL, but it will have already unmapped the partial bio. The
> "out:" error exit section will see the non-null bio and try to unmap
> it again, triggering a mapcount bug via bad_page().
>
> Signed-off-by: Pete Wyckoff <[EMAIL PROTECTED]>
> ---
> block/bsg.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/block/bsg.c b/block/bsg.c
> index 3337125..bba7154 100644
> --- a/block/bsg.c
> +++ b/block/bsg.c
> @@ -295,8 +295,10 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr)
>
> dxferp = (void*)(unsigned long)hdr->din_xferp;
> ret = blk_rq_map_user(q, next_rq, dxferp, hdr->din_xfer_len);
> - if (ret)
> + if (ret) {
> + next_rq->bio = NULL; /* do not unmap twice */
> goto out;
> + }
> }
>
> if (hdr->dout_xfer_len) {
Thanks!
Acked-by: FUJITA Tomonori <[EMAIL PROTECTED]>
James, please put this to the scsi-fixes tree.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "mount: could not find filesystem" - aacraid? (was: Re: 2.6.26-git0: IDE oops during boot)
On Thursday 14 February 2008, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Thursday 14 February 2008, Kamalesh Babulal wrote:
> > Bartlomiej Zolnierkiewicz wrote:
> > > Hi,
> > >
> > > On Tuesday 12 February 2008, Kamalesh Babulal wrote:
> > >> Bartlomiej Zolnierkiewicz wrote:
> > >>> Hi,
> > >>>
> > >>> On Monday 11 February 2008, Kamalesh Babulal wrote:
> > Nish Aravamudan wrote:
> > > On 2/7/08, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> > >> On Thursday 07 February 2008, Kamalesh Babulal wrote:
> > >>> Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > On Wednesday 06 February 2008, Pavel Machek wrote:
> > > On Wed 2008-02-06 11:53:34, Pavel Machek wrote:
> > >> Hi!
> > >>
> > >> Trying to boot 2.6.25-git0 (few days old), I get
> > >>
> > >> BUG: unable to handle kernel paging request at ..ffb0
> > >> IP at init_irq+0x42e
> > init_irq? hmm...
> >
> > >> Call trace:
> > >> ide_device_add_all
> > this comes from ide-generic
> > (Generic IDE host driver)
> >
> > >> ide_generic_init
> > >> kernel_init
> > >> child_rip
> > >> vgacon_cursor
> > >> kernel_init
> > >> child_rip
> > >>
> > >> Excerpt from config:
> > >>
> > >> CONFIG_IDE=y
> > >> CONFIG_BLK_DEV_IDE=y
> > > Disabling CONFIG_IDE made my machine boot, as it was using libata
> > > anyway.
> > Kamalesh/Pavel:
> >
> > Could you try latest git and see if the OOPS is still there?
> >
> > [ Yeah, I'm unable to reproduce it. :( ]
> >
> > Thanks,
> > Bart
> > >>> Hi Bart,
> > >>>
> > >>> The panic is reproducible with the 2.6.24-git16 kernel, the call
> > >>> trace is
> > >>> similar to the previous one
> > >> Thanks, I again reviewed ide-probe.c changes but nothing seems
> > >> wrong...
> > >>
> > >> Could you please bisect it down to the guilty commit?
> > > Kamalesh, were you able to bisect this down? I just got hit by the
> > > same panic on a 4-way x86_64, with 2.6.24-git22.
> > >
> > > Thanks,
> > > Nish
> > Hi Nish,
> >
> > I tried bisecting and the guilty patch seems to be
> >
> > 36501650ec45b1db308c3b51886044863be2d762 is first bad commit
> > commit 36501650ec45b1db308c3b51886044863be2d762
> > Author: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> > Date: Fri Feb 1 23:09:31 2008 +0100
> >
> > ide: keep pointer to struct device instead of struct pci_dev in
> > ide_hwif_t
> >
> >
> > the gdb output, also points to the changes made by the guilty patch
> >
> > (gdb) p ide_device_add_all
> > $1 = {int (u8 *, const struct ide_port_info *)} 0x804176ac
> >
> > (gdb) p/x 0x804176ac+0xb60
> > $2 = 0x8041820c
> > (gdb) l *0x8041820c
> > 0x8041820c is in ide_device_add_all
> > (drivers/ide/ide-probe.c:1249).
> > 1244goto out;
> > 1245}
> > 1246
> > 1247sg_init_table(hwif->sg_table, hwif->sg_max_nents);
> > 1248
> > 1249if (init_irq(hwif) == 0)
> > 1250goto done;
> > 1251
> > 1252old_irq = hwif->irq;
> > 1253/*
> > (gdb)
> >
> >
> > (gdb) p init_irq
> > $1 = {int (ide_hwif_t *)} 0x8041721f
> > (gdb) p/x 0x8041721f+0x1a4
> > $2 = 0x804173c3
> > (gdb) l *0x804173c3
> > 0x804173c3 is in init_irq (include/asm/pci.h:101).
> > 96 /* Returns the node based on pci bus */
> > 97 static inline int __pcibus_to_node(struct pci_bus *bus)
> > 98 {
> > 99 struct pci_sysdata *sd = bus->sysdata;
> > 100
> > 101 return sd->node;
> > 102 }
> > 103
> > 104 static inline cpumask_t __pcibus_to_cpumask(struct pci_bus
> > *bus)
> > 105 {
> > (gdb)
> > >>> Thanks for the detailed analysis and sorry for the bug.
> > >>>
> > >>> I think that this may has been just fixed by Andi's recent
> > >>> hwif_to_node()
> > >>> fix (patch below, it is in Linus' tree already), could please verify
> > >>> this?
> > >>>
> > >>> commit 1f07e988290fc45932f5028c9e2a862c37a57336
> > >>> Author: Andi Kleen <[EMAIL PROTECTED]>
> > >>> Date: Mon Feb 11 01:35:20 2008 +0100
> > >>>
> > >>> Prevent IDE boot ops on NUMA system
> > >>>
> > >>> Without this patch a Opteron test system here oopses at boot with
> > >>> current git.
> > >>>
> > >>> Calling to_pci_dev() on a NULL pointer gives a negative value so the
> > >>> following NULL pointer check never trigger
Re: ips.c broken since 2.6.23 on x86_64?
On Wed, 13 Feb 2008 13:43:24 -0800 Tim Pepper <[EMAIL PROTECTED]> wrote: > We recently upgraded a production x86_64 machine with serveraid > cards to 2.6.24 and noted that /proc/scsi/scsi showed garbage for our > serveraid service processors. sg_inq also returned garbage from the > service processors' sg devices. After a few iterations I started seeing > meaninful stuff in the garbage. Not sure if it was returning live memory > or just unzero'd. Either way not good so we went back to a known good, > older kernel and tried to repro on a similar machine. We got different, > but still bad results in terms of pointing at memory badness. > > FWIW, the original machine had the following hardware: > scsi0 : IBM PCI ServeRAID 7.12.05 Build 761 > scsi1 : IBM PCI ServeRAID 7.12.05 Build 761 > and the repro's have been on a machine with just: > scsi0 : IBM PCI ServeRAID 7.12.05 Build 761 > > On the repro machine I'm getting a hang on ips driver load with the following > logged: > > Feb 13 13:16:08 ipstest kernel: [ 915.236563] scsi3 : IBM PCI ServeRAID > 7.12.05 Build 761 > Feb 13 13:16:08 ipstest kernel: [ 915.236839] Unable to handle kernel NULL > pointer dereference at RIP: > Feb 13 13:16:08 ipstest kernel: [ 915.236863] [check_addr+16/80] > check_addr+0x10/0x50 > Feb 13 13:16:08 ipstest kernel: [ 915.237209] PGD 79fff067 PUD 7a898067 PMD 0 > Feb 13 13:16:08 ipstest kernel: [ 915.237341] Oops: [1] SMP > Feb 13 13:16:08 ipstest kernel: [ 915.237463] CPU 1 > Feb 13 13:16:08 ipstest kernel: [ 915.239436] Modules linked in: ips aic94xx > Feb 13 13:16:08 ipstest kernel: [ 915.239559] Pid: 5213, comm: scsi_scan_3 > Not tainted 2.6.23-ips_as_module #3 > Feb 13 13:16:08 ipstest kernel: [ 915.239692] RIP: 0010:[check_addr+16/80] > [check_addr+16/80] check_addr+0x10/0x50 > Feb 13 13:16:08 ipstest kernel: [ 915.239932] RSP: 0018:810076d87900 > EFLAGS: 00010082 > Feb 13 13:16:08 ipstest kernel: [ 915.240059] RAX: RBX: > 81007b636300 RCX: 0024 > Feb 13 13:16:08 ipstest kernel: [ 915.240196] RDX: 7b636b00 RSI: > 8077cde0 RDI: 806c4ed5 > Feb 13 13:16:08 ipstest kernel: [ 915.240332] RBP: 810076d87900 R08: > 0500 R09: > Feb 13 13:16:08 ipstest kernel: [ 915.240468] R10: 81007aa33b40 R11: > 0060 R12: > Feb 13 13:16:08 ipstest kernel: [ 915.240605] R13: 0001 R14: > 8077cde0 R15: 81007aa33a80 > Feb 13 13:16:08 ipstest kernel: [ 915.240741] FS: () > GS:810001039300() knlGS: > Feb 13 13:16:08 ipstest kernel: [ 915.240981] CS: 0010 DS: 0018 ES: 0018 > CR0: 8005003b > Feb 13 13:16:08 ipstest kernel: [ 915.24] CR2: CR3: > 78a98000 CR4: 06e0 > Feb 13 13:16:08 ipstest kernel: [ 915.241248] DR0: DR1: > DR2: > Feb 13 13:16:08 ipstest kernel: [ 915.241384] DR3: DR6: > 0ff0 DR7: 0400 > Feb 13 13:16:08 ipstest kernel: [ 915.241520] Process scsi_scan_3 (pid: > 5213, threadinfo 810076d86000, task 81007be26720) > Feb 13 13:16:08 ipstest kernel: [ 915.241761] Stack: 810076d87930 > 802125c3 81007aa33a80 81007480cf50 > Feb 13 13:16:08 ipstest kernel: [ 915.242006] > 81007ba38ca8 810076d87940 8046fb42 > Feb 13 13:16:08 ipstest kernel: [ 915.242248] 810076d879c0 > 8801c2ee 81007aa33af0 00017aa33af0 > Feb 13 13:16:08 ipstest kernel: [ 915.242389] Call Trace: > Feb 13 13:16:08 ipstest kernel: [ 915.242606] [nommu_map_sg+115/144] > nommu_map_sg+0x73/0x90 > Feb 13 13:16:08 ipstest kernel: [ 915.242736] [scsi_dma_map+66/96] > scsi_dma_map+0x42/0x60 > Feb 13 13:16:08 ipstest kernel: [ 915.242867] [_end+124884230/2127548952] > :ips:ips_next+0x33e/0xc00 > Feb 13 13:16:08 ipstest kernel: [ 915.242986] [scsi_done+0/48] > scsi_done+0x0/0x30 > Feb 13 13:16:08 ipstest kernel: [ 915.243114] [_end+124896894/2127548952] > :ips:ips_queue+0x106/0x1f0 > Feb 13 13:16:08 ipstest kernel: [ 915.243240] [scsi_dispatch_cmd+498/784] > scsi_dispatch_cmd+0x1f2/0x310 > Feb 13 13:16:08 ipstest kernel: [ 915.243370] [scsi_request_fn+491/976] > scsi_request_fn+0x1eb/0x3d0 > Feb 13 13:16:08 ipstest kernel: [ 915.243500] > [__generic_unplug_device+37/48] __generic_unplug_device+0x25/0x30 > Feb 13 13:16:08 ipstest kernel: [ 915.243630] > [blk_execute_rq_nowait+99/176] blk_execute_rq_nowait+0x63/0xb0 > Feb 13 13:16:08 ipstest kernel: [ 915.243761] [blk_execute_rq+122/224] > blk_execute_rq+0x7a/0xe0 > Feb 13 13:16:08 ipstest kernel: [ 915.243889] [scsi_execute+240/288] > scsi_execute+0xf0/0x120 > Feb 13 13:16:08 ipstest kernel: [ 915.244016] [scsi_execute_req+134/240] > scsi_execute_req+0x86/0xf0 > Feb 13 13:16:08 ipstest kernel: [ 915.24414
"mount: could not find filesystem" - aacraid? (was: Re: 2.6.26-git0: IDE oops during boot)
Hi,
On Thursday 14 February 2008, Kamalesh Babulal wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > Hi,
> >
> > On Tuesday 12 February 2008, Kamalesh Babulal wrote:
> >> Bartlomiej Zolnierkiewicz wrote:
> >>> Hi,
> >>>
> >>> On Monday 11 February 2008, Kamalesh Babulal wrote:
> Nish Aravamudan wrote:
> > On 2/7/08, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
> >> On Thursday 07 February 2008, Kamalesh Babulal wrote:
> >>> Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> On Wednesday 06 February 2008, Pavel Machek wrote:
> > On Wed 2008-02-06 11:53:34, Pavel Machek wrote:
> >> Hi!
> >>
> >> Trying to boot 2.6.25-git0 (few days old), I get
> >>
> >> BUG: unable to handle kernel paging request at ..ffb0
> >> IP at init_irq+0x42e
> init_irq? hmm...
>
> >> Call trace:
> >> ide_device_add_all
> this comes from ide-generic
> (Generic IDE host driver)
>
> >> ide_generic_init
> >> kernel_init
> >> child_rip
> >> vgacon_cursor
> >> kernel_init
> >> child_rip
> >>
> >> Excerpt from config:
> >>
> >> CONFIG_IDE=y
> >> CONFIG_BLK_DEV_IDE=y
> > Disabling CONFIG_IDE made my machine boot, as it was using libata
> > anyway.
> Kamalesh/Pavel:
>
> Could you try latest git and see if the OOPS is still there?
>
> [ Yeah, I'm unable to reproduce it. :( ]
>
> Thanks,
> Bart
> >>> Hi Bart,
> >>>
> >>> The panic is reproducible with the 2.6.24-git16 kernel, the call
> >>> trace is
> >>> similar to the previous one
> >> Thanks, I again reviewed ide-probe.c changes but nothing seems wrong...
> >>
> >> Could you please bisect it down to the guilty commit?
> > Kamalesh, were you able to bisect this down? I just got hit by the
> > same panic on a 4-way x86_64, with 2.6.24-git22.
> >
> > Thanks,
> > Nish
> Hi Nish,
>
> I tried bisecting and the guilty patch seems to be
>
> 36501650ec45b1db308c3b51886044863be2d762 is first bad commit
> commit 36501650ec45b1db308c3b51886044863be2d762
> Author: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> Date: Fri Feb 1 23:09:31 2008 +0100
>
> ide: keep pointer to struct device instead of struct pci_dev in
> ide_hwif_t
>
>
> the gdb output, also points to the changes made by the guilty patch
>
> (gdb) p ide_device_add_all
> $1 = {int (u8 *, const struct ide_port_info *)} 0x804176ac
>
> (gdb) p/x 0x804176ac+0xb60
> $2 = 0x8041820c
> (gdb) l *0x8041820c
> 0x8041820c is in ide_device_add_all
> (drivers/ide/ide-probe.c:1249).
> 1244goto out;
> 1245}
> 1246
> 1247sg_init_table(hwif->sg_table, hwif->sg_max_nents);
> 1248
> 1249if (init_irq(hwif) == 0)
> 1250goto done;
> 1251
> 1252old_irq = hwif->irq;
> 1253/*
> (gdb)
>
>
> (gdb) p init_irq
> $1 = {int (ide_hwif_t *)} 0x8041721f
> (gdb) p/x 0x8041721f+0x1a4
> $2 = 0x804173c3
> (gdb) l *0x804173c3
> 0x804173c3 is in init_irq (include/asm/pci.h:101).
> 96 /* Returns the node based on pci bus */
> 97 static inline int __pcibus_to_node(struct pci_bus *bus)
> 98 {
> 99 struct pci_sysdata *sd = bus->sysdata;
> 100
> 101 return sd->node;
> 102 }
> 103
> 104 static inline cpumask_t __pcibus_to_cpumask(struct pci_bus *bus)
> 105 {
> (gdb)
> >>> Thanks for the detailed analysis and sorry for the bug.
> >>>
> >>> I think that this may has been just fixed by Andi's recent hwif_to_node()
> >>> fix (patch below, it is in Linus' tree already), could please verify this?
> >>>
> >>> commit 1f07e988290fc45932f5028c9e2a862c37a57336
> >>> Author: Andi Kleen <[EMAIL PROTECTED]>
> >>> Date: Mon Feb 11 01:35:20 2008 +0100
> >>>
> >>> Prevent IDE boot ops on NUMA system
> >>>
> >>> Without this patch a Opteron test system here oopses at boot with
> >>> current git.
> >>>
> >>> Calling to_pci_dev() on a NULL pointer gives a negative value so the
> >>> following NULL pointer check never triggers and then an illegal
> >>> address
> >>> is referenced. Check the unadjusted original device pointer for NULL
> >>> instead.
> >>>
> >>> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
> >>> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
> >>>
> >>> diff --git a/include/linux/ide.h b/include/linux/ide.h
> >>> index 23fad89..a3b69c1 100644
> >>> ---
Re: [BUGFIX 2/2] gdth: bugfix for the Timer at exit crash
On Wed, Feb 13 2008 at 19:36 +0200, James Bottomley <[EMAIL PROTECTED]> wrote:
>> ---
>> From: Boaz Harrosh <[EMAIL PROTECTED]>
>> Subject: [PATCH] gdth: bugfix for the at-exit problems
>>
>> gdth_exit would first remove all cards then stop the timer
>> and would not sync with the timer function. This caused a crash
>> in gdth_timer() when module was unloaded.
>> So del_timer_sync the timer before we delete the cards.
>>
>> also the reboot notifier function would crash. So unify
>> the exit and halt functions with a gdth_shutdown() that's
>> called by both.
>>
>> Signed-off-by: Boaz Harrosh <[EMAIL PROTECTED]>
>> ---
>> +static struct notifier_block gdth_notifier = {
>> +gdth_halt, NULL, 0
>> +};
>> +
>> +bool gdth_shutdown_done;
>
right forgot the static. But I use it in gdth_init(), so it
must be external. Unless you promise me that gdth_init() will
never ever be called after a call to shutdown.
Any way the hot-plug patch changes all that. This is only
for 2.6.24 bugfixs.
> Static police alert! Just make it static and move it into
> gdth_shutdown()
>
>> +static void gdth_shutdown()
>> +{
>> +gdth_ha_str *ha;
>> +if (gdth_shutdown_done)
>> +return;
>> +
>> +gdth_shutdown_done = true;
>> +unregister_chrdev(major,"gdth");
>> +unregister_reboot_notifier(&gdth_notifier);
>
> I'm not sure you can do this, aren't reboot notifiers called with the
> rwsem held? In which case the unregister which also takes the rwsem
> will hang the system.
>
humm, can't remove a notifier from within the notifier. Thanks James for
the catch, it's what happens when you don't test your own patches.
I have moved unregister_reboot_notifier to gdth_exit.
> James
>
Will send a new version for review. Please note that this is a bugfix patch
on top of 2.6.24. It is not needed for Jeff's hot-plug path.
There will be one more bugfix patch for a crash at the user-mode ioctl code.
Boaz
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
