[PATCH] aic94xx: driver assertion in non-x86 BIOS env

[PATCH] aic94xx: driver assertion in non-x86 BIOS env

[Mike Anderson]

This patch addresses the issue of the aic94xx driver not working on
non-x86 or on systems where the card bios had been disabled.
http://bugzilla.kernel.org/show_bug.cgi?id=6042

Rob Tarte, Jeff Ding, and I coordinated on the fix for the OCM issue.

The patch has been run on a Powermac G5, a PPC64, and IA64 based system.

-andmike
--
Michael Anderson
andmike@us.ibm.com

 This purpose of this patch is to allow the aic94xx driver to load and
 function on archs that do not allow the cards bios to run. This patch
 contains a forward port of code changes made to the adp94xx driver
 that inits the ocm if the bios did not. The patch also provides default
 parameters for flash values if the flash data cannot be read.

 Signed-off-by: Mike Anderson <andmike@us.ibm.com>

 drivers/scsi/aic94xx/aic94xx_hwi.c     |    6 -
 drivers/scsi/aic94xx/aic94xx_reg.h     |   13 ++
 drivers/scsi/aic94xx/aic94xx_reg_def.h |   13 ++
 drivers/scsi/aic94xx/aic94xx_sds.c     |  187 +++++++++++++++++++++++++++++++--
 drivers/scsi/aic94xx/aic94xx_seq.c     |    6 -
 5 files changed, 215 insertions(+), 10 deletions(-)

Index: sas-2.6-patched/drivers/scsi/aic94xx/aic94xx_hwi.c
===================================================================
--- sas-2.6-patched.orig/drivers/scsi/aic94xx/aic94xx_hwi.c	2006-02-11 00:51:10.000000000 -0800
+++ sas-2.6-patched/drivers/scsi/aic94xx/aic94xx_hwi.c	2006-02-16 09:54:38.000000000 -0800
@@ -413,10 +413,14 @@ static int asd_init_escbs(struct asd_ha_
  */
 int asd_chip_hardrst(struct asd_ha_struct *asd_ha)
 {
+	int i;
 	int count = 100;
 	u32 reg;
 
-	asd_write_reg_dword(asd_ha, COMBIST, HARDRST);
+	for (i = 0 ; i < 4 ; i++) {
+		asd_write_reg_dword(asd_ha, COMBIST, HARDRST);
+	}
+
 	do {
 		udelay(1);
 		reg = asd_read_reg_dword(asd_ha, CHIMINT);
Index: sas-2.6-patched/drivers/scsi/aic94xx/aic94xx_reg.h
===================================================================
--- sas-2.6-patched.orig/drivers/scsi/aic94xx/aic94xx_reg.h	2006-02-11 00:51:10.000000000 -0800
+++ sas-2.6-patched/drivers/scsi/aic94xx/aic94xx_reg.h	2006-02-11 00:57:45.000000000 -0800
@@ -89,6 +89,19 @@ ASD_READ_OCM(u8, byte, b);
 ASD_READ_OCM(u16,word, w);
 ASD_READ_OCM(u32,dword,l);
 
+#define ASD_WRITE_OCM(type, ord, S)                                    \
+static inline void asd_write_ocm_##ord (struct asd_ha_struct *asd_ha,  \
+					 u32 offs, type val)          \
+{                                                                     \
+	struct asd_ha_addrspace *io_handle = &asd_ha->io_handle[1];   \
+	write##S (val, io_handle->addr + (unsigned long) offs);       \
+	return;                                                       \
+}
+
+ASD_WRITE_OCM(u8, byte, b);
+ASD_WRITE_OCM(u16,word, w);
+ASD_WRITE_OCM(u32,dword,l);
+
 #define ASD_DDBSITE_READ(type, ord)                                        \
 static inline type asd_ddbsite_read_##ord (struct asd_ha_struct *asd_ha,   \
 					   u16 ddb_site_no,                \
Index: sas-2.6-patched/drivers/scsi/aic94xx/aic94xx_reg_def.h
===================================================================
--- sas-2.6-patched.orig/drivers/scsi/aic94xx/aic94xx_reg_def.h	2006-02-11 00:51:10.000000000 -0800
+++ sas-2.6-patched/drivers/scsi/aic94xx/aic94xx_reg_def.h	2006-02-11 00:57:45.000000000 -0800
@@ -1796,6 +1796,8 @@
 
 #define PCIC_FLASH_MBAR	0xB8
 
+#define PCIC_INTRPT_STAT 0xD4
+
 #define PCIC_TP_CTRL	0xFC
 
 /*
@@ -1805,6 +1807,7 @@
 
 #define	EXSICNFGR	(EXSI_REG_BASE_ADR + 0x00)
 
+#define		OCMINITIALIZED		0x80000000
 #define		ASIEN			0x00400000
 #define		HCMODE			0x00200000
 #define		PCIDEF			0x00100000
@@ -1959,6 +1962,16 @@
 #define XSRAM_SIZE                        0x100000
 
 /*
+ * NVRAM Registers, Address Range: (0x00000 - 0x3FFFF).
+ */
+#define		NVRAM_REG_BASE_ADR	0xBF800000
+#define		NVRAM_MAX_BASE_ADR	0x003FFFFF
+
+/* OCM base address */
+#define		OCM_BASE_ADDR		0xA0000000
+#define		OCM_MAX_SIZE		0x20000
+
+/*
  * Sequencers (Central and Link) Scratch RAM page definitions.
  */
 
Index: sas-2.6-patched/drivers/scsi/aic94xx/aic94xx_sds.c
===================================================================
--- sas-2.6-patched.orig/drivers/scsi/aic94xx/aic94xx_sds.c	2006-02-11 00:21:30.000000000 -0800
+++ sas-2.6-patched/drivers/scsi/aic94xx/aic94xx_sds.c	2006-02-16 10:07:03.000000000 -0800
@@ -51,6 +51,60 @@ struct asd_ocm_dir {
 	struct asd_ocm_dir_ent entry[15];
 } __attribute__ ((packed));
 
+#define	OCM_DE_OCM_DIR			0x00
+#define	OCM_DE_WIN_DRVR			0x01
+#define	OCM_DE_BIOS_CHIM		0x02
+#define	OCM_DE_RAID_ENGN		0x03
+#define	OCM_DE_BIOS_INTL		0x04
+#define	OCM_DE_BIOS_CHIM_OSM		0x05
+#define	OCM_DE_BIOS_CHIM_DYNAMIC	0x06
+#define	OCM_DE_ADDC2C_RES0		0x07
+#define	OCM_DE_ADDC2C_RES1		0x08
+#define	OCM_DE_ADDC2C_RES2		0x09
+#define	OCM_DE_ADDC2C_RES3		0x0A
+
+#define OCM_INIT_DIR_ENTRIES	5
+/***************************************************************************
+*  OCM dircetory default
+***************************************************************************/
+static struct asd_ocm_dir OCMDirInit =
+{
+	.sig = {0x4D, 0x4F},	/* signature */
+	.num_de = OCM_INIT_DIR_ENTRIES,	/* no. of directory entries */
+};
+
+/***************************************************************************
+*  OCM dircetory Entries default
+***************************************************************************/
+static struct asd_ocm_dir_ent OCMDirEntriesInit[OCM_INIT_DIR_ENTRIES] =
+{
+	{
+		.type = (OCM_DE_ADDC2C_RES0),	/* Entry type  */
+		.offs = {128},			/* Offset */
+		.size = {0, 4},			/* size */
+	},
+	{
+		.type = (OCM_DE_ADDC2C_RES1),	/* Entry type  */
+		.offs = {128, 4},		/* Offset */
+		.size = {0, 4},			/* size */
+	},
+	{
+		.type = (OCM_DE_ADDC2C_RES2),	/* Entry type  */
+		.offs = {128, 8},		/* Offset */
+		.size = {0, 4},			/* size */
+	},
+	{
+		.type = (OCM_DE_ADDC2C_RES3),	/* Entry type  */
+		.offs = {128, 12},		/* Offset */
+		.size = {0, 4},			/* size */
+	},
+	{
+		.type = (OCM_DE_WIN_DRVR),	/* Entry type  */
+		.offs = {128, 16},		/* Offset */
+		.size = {128, 235, 1},		/* size */
+	},
+};
+
 struct asd_bios_chim_struct {
 	char sig[4];
 	u8   major;          /* 1 */
@@ -92,11 +146,12 @@ static int asd_read_ocm_seg(struct asd_h
 static int asd_read_ocm_dir(struct asd_ha_struct *asd_ha,
 			    struct asd_ocm_dir *dir, u32 offs)
 {
-	int err = asd_read_ocm_seg(asd_ha, (void *)dir, offs, sizeof(*dir));
+	int err = asd_read_ocm_seg(asd_ha, dir, offs, sizeof(*dir));
 	if (err) {
 		ASD_DPRINTK("couldn't read ocm segment\n");
 		return err;
 	}
+
 	if (dir->sig[0] != 'M' || dir->sig[1] != 'O') {
 		ASD_DPRINTK("no valid dir signature(%c%c) at start of OCM\n",
 			    dir->sig[0], dir->sig[1]);
@@ -111,6 +166,28 @@ static int asd_read_ocm_dir(struct asd_h
 	return 0;
 }
 
+/**
+ * asd_write_ocm_seg - write an on chip memory (OCM) segment
+ * @asd_ha: pointer to the host adapter structure
+ * @buffer: where to read the write data
+ * @offs: offset into OCM to write to
+ * @size: how many bytes to write
+ *
+ * Return the number of bytes not written. Return 0 on success.
+ */
+static void asd_write_ocm_seg(struct asd_ha_struct *asd_ha, void *buffer,
+			    u32 offs, int size)
+{
+	u8 *p = buffer;
+	if (unlikely(asd_ha->iospace))
+		asd_write_reg_string(asd_ha, buffer, offs+OCM_BASE_ADDR, size);
+	else {
+		for ( ; size > 0; size--, offs++, p++)
+			asd_write_ocm_byte(asd_ha, offs, *p);
+	}
+	return;
+}
+
 #define THREE_TO_NUM(X) ((X)[0] | ((X)[1] << 8) | ((X)[2] << 16))
 
 static int asd_find_dir_entry(struct asd_ocm_dir *dir, u8 type,
@@ -208,6 +285,67 @@ out:
 	return err;
 }
 
+static void
+asd_hwi_initialize_ocm_dir (struct asd_ha_struct *asd_ha)
+{
+	int i;
+
+	/* Zero OCM */
+	for (i = 0; i < OCM_MAX_SIZE; i += 4)
+		asd_write_ocm_dword(asd_ha, i, 0);
+
+	/* Write Dir */
+	asd_write_ocm_seg(asd_ha, &OCMDirInit, 0,
+			  sizeof(struct asd_ocm_dir));
+
+	/* Write Dir Entries */
+	for (i = 0; i < OCM_INIT_DIR_ENTRIES; i++)
+		asd_write_ocm_seg(asd_ha, &OCMDirEntriesInit[i],
+				  sizeof(struct asd_ocm_dir) +
+				  (i * sizeof(struct asd_ocm_dir_ent))
+				  , sizeof(struct asd_ocm_dir_ent));
+
+}
+
+static int
+asd_hwi_check_ocm_access (struct asd_ha_struct *asd_ha)
+{
+	struct pci_dev *pcidev = asd_ha->pcidev;
+	u32 reg;
+	int err = 0;
+	u32 v;
+
+	/* check if OCM has been initialized by BIOS */
+	reg = asd_read_reg_dword(asd_ha, EXSICNFGR);
+
+	if (!(reg & OCMINITIALIZED)) {
+		err = pci_read_config_dword(pcidev, PCIC_INTRPT_STAT, &v);
+		if (err) {
+			asd_printk("couldn't access PCIC_INTRPT_STAT of %s\n",
+					pci_name(pcidev));
+			goto out;
+		}
+
+		printk(KERN_INFO "OCM is not initialized by BIOS,"
+		       "reinitialize it and ignore it, current IntrptStatus"
+		       "is 0x%x\n", v);
+
+		if (v)
+			err = pci_write_config_dword(pcidev,
+						     PCIC_INTRPT_STAT, v);
+		if (err) {
+			asd_printk("couldn't write PCIC_INTRPT_STAT of %s\n",
+					pci_name(pcidev));
+			goto out;
+		}
+
+		asd_hwi_initialize_ocm_dir(asd_ha);
+
+	}
+out:
+	return err;
+}
+
 /**
  * asd_read_ocm - read on chip memory (OCM)
  * @asd_ha: pointer to the host adapter structure
@@ -217,6 +355,9 @@ int asd_read_ocm(struct asd_ha_struct *a
 	int err;
 	struct asd_ocm_dir *dir;
 
+	if (asd_hwi_check_ocm_access(asd_ha))
+		return -1;
+
 	dir = kmalloc(sizeof(*dir), GFP_KERNEL);
 	if (!dir) {
 		asd_printk("no memory for ocm dir\n");
@@ -606,9 +747,9 @@ static int asd_validate_ms(struct asd_ma
 	ms->size = le16_to_cpu((__force __le16) ms->size);
 
 	if (asd_calc_flash_chksum((u16 *)ms, ms->size/2)) {
-		ASD_DPRINTK("failed manuf sector checksum\n");
-		return -EINVAL;
+		asd_printk("failed manuf sector checksum\n");
 	}
+
 	return 0;
 }
 
@@ -683,11 +824,29 @@ static int asd_ms_get_phy_params(struct 
 	int en_phys = 0;
 	int rep_phys = 0;
 	struct asd_manuf_phy_param *phy_param;
+	struct asd_manuf_phy_param dflt_phy_param;
 
 	phy_param = asd_find_ll_by_id(manuf_sec, 'P', 'M');
 	if (!phy_param) {
 		ASD_DPRINTK("ms: no phy parameters found\n");
-		return -ENOENT;
+		ASD_DPRINTK("ms: Creating default phy parameters\n");
+		dflt_phy_param.sig[0] = 'P';
+		dflt_phy_param.sig[1] = 'M';
+		dflt_phy_param.maj = 0;
+		dflt_phy_param.min = 2;
+		dflt_phy_param.num_phy_desc = 8;
+		dflt_phy_param.phy_desc_size = sizeof(struct asd_manuf_phy_desc);
+		for (i =0; i < ASD_MAX_PHYS; i++) {
+			dflt_phy_param.phy_desc[i].state = 0;
+			dflt_phy_param.phy_desc[i].phy_id = i;
+			dflt_phy_param.phy_desc[i].phy_control_0 = 0xf6;
+			dflt_phy_param.phy_desc[i].phy_control_1 = 0x10;
+			dflt_phy_param.phy_desc[i].phy_control_2 = 0x43;
+			dflt_phy_param.phy_desc[i].phy_control_3 = 0xeb;
+		}
+
+		phy_param = &dflt_phy_param;
+
 	}
 
 	if (phy_param->maj != 0) {
@@ -736,7 +895,7 @@ static int asd_ms_get_connector_map(stru
 	cm = asd_find_ll_by_id(manuf_sec, 'M', 'C');
 	if (!cm) {
 		ASD_DPRINTK("ms: no connector map found\n");
-		return -ENOENT;
+		return 0;
 	}
 
 	if (cm->maj != 0) {
@@ -872,15 +1031,29 @@ static int asd_process_ctrla_phy_setting
 static int asd_process_ctrl_a_user(struct asd_ha_struct *asd_ha,
 				   struct asd_flash_dir *flash_dir)
 {
-	int err;
+	int err, i;
 	u32 offs, size;
 	struct asd_ll_el *el;
 	struct asd_ctrla_phy_settings *ps;
+	struct asd_ctrla_phy_settings dflt_ps;
 
 	err = asd_find_flash_de(flash_dir, FLASH_DE_CTRL_A_USER, &offs, &size);
 	if (err) {
 		ASD_DPRINTK("couldn't find CTRL-A user settings section\n");
-		goto out;
+		ASD_DPRINTK("Creating default CTRL-A user settings section\n");
+
+		dflt_ps.id0 = 'h';
+		dflt_ps.num_phys = 8;
+		for (i =0; i < ASD_MAX_PHYS; i++) {
+			memcpy(dflt_ps.phy_ent[i].sas_addr,
+			       asd_ha->hw_prof.sas_addr, SAS_ADDR_SIZE);
+			dflt_ps.phy_ent[i].sas_link_rates = 0x98;
+			dflt_ps.phy_ent[i].flags = 0x0;
+			dflt_ps.phy_ent[i].sata_link_rates = 0x0;
+		}
+
+		size = sizeof(struct asd_ctrla_phy_settings);
+		ps = &dflt_ps;
 	}
 
 	if (size == 0)
Index: sas-2.6-patched/drivers/scsi/aic94xx/aic94xx_seq.c
===================================================================
--- sas-2.6-patched.orig/drivers/scsi/aic94xx/aic94xx_seq.c	2006-02-11 00:21:30.000000000 -0800
+++ sas-2.6-patched/drivers/scsi/aic94xx/aic94xx_seq.c	2006-02-16 09:54:38.000000000 -0800
@@ -757,8 +757,10 @@ static void asd_init_lseq_mdp(struct asd
 	asd_write_reg_word(asd_ha, LmSEQ_RESP_LEN(lseq), 0);
 	asd_write_reg_word(asd_ha, LmSEQ_FIRST_INV_SCB_SITE(lseq),
 			   (u16)last_scb_site_no+1);
-	asd_write_reg_dword(asd_ha, LmSEQ_INTEN_SAVE(lseq),
-			    (u32) LmM0INTEN_MASK);
+	asd_write_reg_word(asd_ha, LmSEQ_INTEN_SAVE(lseq),
+			    (u16) LmM0INTEN_MASK & 0xFFFF0000 >> 16);
+	asd_write_reg_word(asd_ha, LmSEQ_INTEN_SAVE(lseq) + 2,
+			    (u16) LmM0INTEN_MASK & 0xFFFF);
 	asd_write_reg_byte(asd_ha, LmSEQ_LINK_RST_FRM_LEN(lseq), 0);
 	asd_write_reg_byte(asd_ha, LmSEQ_LINK_RST_PROTOCOL(lseq), 0);
 	asd_write_reg_byte(asd_ha, LmSEQ_RESP_STATUS(lseq), 0);

Re: [PATCH] aic94xx: driver assertion in non-x86 BIOS env

[Jeff Garzik]

Mike Anderson wrote:
> This patch addresses the issue of the aic94xx driver not working on
> non-x86 or on systems where the card bios had been disabled.
> http://bugzilla.kernel.org/show_bug.cgi?id=6042
> 
> Rob Tarte, Jeff Ding, and I coordinated on the fix for the OCM issue.
> 
> The patch has been run on a Powermac G5, a PPC64, and IA64 based system.
> 
> -andmike
> --
> Michael Anderson
> andmike@us.ibm.com
> 
>  This purpose of this patch is to allow the aic94xx driver to load and
>  function on archs that do not allow the cards bios to run. This patch
>  contains a forward port of code changes made to the adp94xx driver
>  that inits the ocm if the bios did not. The patch also provides default
>  parameters for flash values if the flash data cannot be read.
> 
>  Signed-off-by: Mike Anderson <andmike@us.ibm.com>

applied to sas-2.6.git#upstream (and #ALL, and thus to Andrew's -mm)

	Jeff

Re: [PATCH] aic94xx: driver assertion in non-x86 BIOS env

[James Bottomley]

On Thu, 2006-02-16 at 18:36 -0800, Mike Anderson wrote:
> This patch addresses the issue of the aic94xx driver not working on
> non-x86 or on systems where the card bios had been disabled.
> http://bugzilla.kernel.org/show_bug.cgi?id=6042
> 
> Rob Tarte, Jeff Ding, and I coordinated on the fix for the OCM issue.
> 
> The patch has been run on a Powermac G5, a PPC64, and IA64 based system.

Actually, it's still not quite working for me.  This is what I get from
2.6.16-rc4 with the Jeff Garzik SAS tree (which has this fix applied).
The soft lockup basically means it was hung in asd_read_ocm():

aic94xx: Adaptec aic94xx SAS/SATA driver version 1.0.2 loaded
GSI 49 (level, low) -> CPU 0 (0x0000) vector 62
ACPI: PCI Interrupt 0000:c0:01.0[A] -> GSI 49 (level, low) -> IRQ 62
aic94xx: found Adaptec AIC-9410W SAS/SATA Host Adapter, device 0000:c0:01.0
OCM is not initialized by BIOS,reinitialize it and ignore it, current IntrptStatusis 0x0
BUG: soft lockup detected on CPU#0!
Modules linked in: aic94xx af_packet ide_cd sas_class generic cmd64x ide_core snd_fm801 snd_ac97_codec snd_ac97_bus snd_pcm snd_page_alloc snd_tea575x_tuner videodev snd_opl3_lib snd_timer snd_hwdep snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore e1000 usbhid ohci_hcd usbcore ext3 jbd mbcache sr_mod cdrom st sd_mod sg mptspi mptscsih mptbase aic79xx aic7xxx sym53c8xx scsi_transport_spi scsi_mod

Pid: 3287, CPU 0, comm:             modprobe
psr : 00001010085a6010 ifs : 8000000000000611 ip  : [<a000000200dbf5c0>]    Not tainted
ip is at asd_read_ocm+0x120/0xb40 [aic94xx]
unat: 0000000000000000 pfs : 0000000000000611 rsc : 0000000000000003
rnat: 000000000000003e bsps: a0000001007c60e0 pr  : 00000000005a9659
ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
csd : 0000000000000000 ssd : 0000000000000000
b0  : a000000200dbf560 b6  : a00000010003b6a0 b7  : a00000010026c960
f6  : 1003e0000001da0f9f2d1 f7  : 1003e0000000000000001
f8  : 1003e0000001da0f9ef4d f9  : 1003e0000000000000384
f10 : 10005fffffffff0000000 f11 : 1003e0000000000000080
r1  : a000000200dd5b90 r2  : 0000000000000a18 r3  : fffffffffffffeda
r8  : 000000000000005c r9  : 0000000000007fff r10 : c0000000e00c00a4
r11 : c0000000e00c0000 r12 : e00000407cbdfda0 r13 : e00000407cbd8000
r14 : e00000407cbdfdb0 r15 : 00000000000000a8 r16 : e0000040448083b0
r17 : 0000000000000007 r18 : c0000000ff5e0000 r19 : 0000000000000005
r20 : 0000000090000040 r21 : 0000000000000060 r22 : 0000000090000040
r23 : a000000100821be9 r24 : 0000000000000007 r25 : 0000000000000005
r26 : a0000001007c60e0 r27 : 00000010085a6010 r28 : a0000001007c60e0
r29 : 0000000000ffffff r30 : 0000000000000000 r31 : a0000001007bf098

Call Trace:
 [<a0000001000137c0>] show_stack+0x80/0xa0
                                sp=e00000407cbdf9f0 bsp=e00000407cbd9630
 [<a0000001000140e0>] show_regs+0x900/0x940
                                sp=e00000407cbdfbc0 bsp=e00000407cbd95d0
 [<a0000001000e90c0>] softlockup_tick+0x160/0x1a0
                                sp=e00000407cbdfbd0 bsp=e00000407cbd95a0
 [<a0000001000af050>] do_timer+0x570/0x9c0
                                sp=e00000407cbdfbd0 bsp=e00000407cbd9538
 [<a00000010003b620>] timer_interrupt+0x280/0x300
                                sp=e00000407cbdfbd0 bsp=e00000407cbd94e0
 [<a0000001000e95e0>] handle_IRQ_event+0xa0/0x140
                                sp=e00000407cbdfbd0 bsp=e00000407cbd94a0
 [<a0000001000e97c0>] __do_IRQ+0x140/0x3c0
                                sp=e00000407cbdfbd0 bsp=e00000407cbd9448
 [<a000000100010720>] ia64_handle_irq+0xa0/0x140
                                sp=e00000407cbdfbd0 bsp=e00000407cbd9410
 [<a00000010000bce0>] ia64_leave_kernel+0x0/0x280
                                sp=e00000407cbdfbd0 bsp=e00000407cbd9410
 [<a000000200dbf5c0>] asd_read_ocm+0x120/0xb40 [aic94xx]
                                sp=e00000407cbdfda0 bsp=e00000407cbd9380
 [<a000000200dbad70>] asd_init_hw+0x1a70/0x2800 [aic94xx]
                                sp=e00000407cbdfdb0 bsp=e00000407cbd92c8
 [<a000000200db5e70>] asd_pci_probe+0x870/0x1c40 [aic94xx]
                                sp=e00000407cbdfdd0 bsp=e00000407cbd9240
 [<a00000010026cb60>] pci_device_probe+0x200/0x2c0
                                sp=e00000407cbdfdf0 bsp=e00000407cbd9200
 [<a0000001003ae4a0>] driver_probe_device+0xe0/0x240
                                sp=e00000407cbdfdf0 bsp=e00000407cbd91c0
 [<a0000001003ae840>] __driver_attach+0xc0/0x160
                                sp=e00000407cbdfdf0 bsp=e00000407cbd9188
 [<a0000001003acb30>] bus_for_each_dev+0xb0/0x120
                                sp=e00000407cbdfdf0 bsp=e00000407cbd9150
 [<a0000001003ae140>] driver_attach+0x40/0x60
                                sp=e00000407cbdfe10 bsp=e00000407cbd9130
 [<a0000001003ad240>] bus_add_driver+0xc0/0x2e0
                                sp=e00000407cbdfe10 bsp=e00000407cbd90f8
 [<a0000001003af160>] driver_register+0x120/0x1e0
                                sp=e00000407cbdfe10 bsp=e00000407cbd90d8
 [<a00000010026bd30>] __pci_register_driver+0x110/0x180
                                sp=e00000407cbdfe20 bsp=e00000407cbd90a8
 [<a000000200b340f0>] aic94xx_init+0xf0/0x320 [aic94xx]
                                sp=e00000407cbdfe30 bsp=e00000407cbd9070
 [<a0000001000deb50>] sys_init_module+0x230/0x5a0
                                sp=e00000407cbdfe30 bsp=e00000407cbd8ff0
 [<a00000010000bb40>] ia64_ret_from_syscall+0x0/0x20
                                sp=e00000407cbdfe30 bsp=e00000407cbd8ff0
 [<a000000000010620>] __kernel_syscall_via_break+0x0/0x20
                                sp=e00000407cbe0000 bsp=e00000407cbd8ff0

James

Re: [PATCH] aic94xx: driver assertion in non-x86 BIOS env

[Mike Anderson]

James Bottomley <James.Bottomley@SteelEye.com> wrote:
> Actually, it's still not quite working for me.  This is what I get from
> 2.6.16-rc4 with the Jeff Garzik SAS tree (which has this fix applied).
> The soft lockup basically means it was hung in asd_read_ocm():

ok, looking into this. Is the soft lockup detect in the same
(asd_read_ocm+0x120) function and offset. I did a resync with Jeff's tree
and ran the code on a ppc64 system. This ran ok. I will move my card to an
IA64 tomorrow to see if I can recreate (which may be unlikely as it ran a
number of loads before) and also generate a .lst file.

-andmike
--
Michael Anderson
andmike@us.ibm.com

RE: [PATCH] aic94xx: driver assertion in non-x86 BIOS env

[Tarte, Robert]

What model ia64 are you running James?  I'll see if Adaptec has one to
try to help reproduce this issue.  Jeff, have you tried the fixes to see
if they addressed the issues you were seeing (OCM error when BIOS off
and booted off of SCSI)?

Rob

-----Original Message-----
From: Mike Anderson [mailto:andmike@us.ibm.com] 
Sent: Tuesday, February 21, 2006 10:26 PM
To: James Bottomley
Cc: linux-scsi@vger.kernel.org; Tarte@us.ibm.com; Tarte, Robert; Jeff
Garzik
Subject: Re: [PATCH] aic94xx: driver assertion in non-x86 BIOS env

James Bottomley <James.Bottomley@SteelEye.com> wrote:
> Actually, it's still not quite working for me.  This is what I get
from
> 2.6.16-rc4 with the Jeff Garzik SAS tree (which has this fix applied).
> The soft lockup basically means it was hung in asd_read_ocm():

ok, looking into this. Is the soft lockup detect in the same
(asd_read_ocm+0x120) function and offset. I did a resync with Jeff's
tree
and ran the code on a ppc64 system. This ran ok. I will move my card to
an
IA64 tomorrow to see if I can recreate (which may be unlikely as it ran
a
number of loads before) and also generate a .lst file.

-andmike
--
Michael Anderson
andmike@us.ibm.com

RE: [PATCH] aic94xx: driver assertion in non-x86 BIOS env

[James Bottomley]

On Wed, 2006-02-22 at 13:24 -0800, Tarte, Robert wrote:
> What model ia64 are you running James?  I'll see if Adaptec has one to
> try to help reproduce this issue.  Jeff, have you tried the fixes to see
> if they addressed the issues you were seeing (OCM error when BIOS off
> and booted off of SCSI)?

This is a HP zx2000 ... small desktop single CPU ia64 (itanic) with the
standard HP ZX1 IOMMU system.

James

Re: [PATCH] aic94xx: driver assertion in non-x86 BIOS env

[Jeff Garzik]

Tarte, Robert wrote:
> What model ia64 are you running James?  I'll see if Adaptec has one to
> try to help reproduce this issue.  Jeff, have you tried the fixes to see
> if they addressed the issues you were seeing (OCM error when BIOS off
> and booted off of SCSI)?

Nah, I'm just waiting for James to ACK that things work on his side, 
really...

	Jeff

RE: [PATCH] aic94xx: driver assertion in non-x86 BIOS env

[Tarte, Robert]

I have located an HP machine that is the same flavor as James' (HP
Integrity rx2600: ia64 with zx1 chipset).  It exhibits the same problem.
I believe that the architecture may differ with traditional PC/PCI
architectures in how it deals with non-aligned PCI access.  When I
converted the OCM initialization code to write on qwords instead of
dwords, the code was able to pass OCM initialization.  It is possible
that the machine is doing a qword read/modify/write when accessing OCM
memory, which would explain the hang.  I haven't hooked up a PCI
analyzer.  The code now gets to the point where it is trying to read
NVRAM in order to get the SAS address.  It seems that the machine is
unable to retrieve non-aligned byte accesses correctly.  I will convert
the code to pull the correct byte/word/dword from the aligned qword.
We'll see if that fixes it.  None of these behaviors are exhibited on
x86, x86_64, powerpc, and ia64 without the zx1 chipset.  I understand
that there may be a few ARM implementations that have similar issues.

Mike: any word on getting James a machine?

Rob

> -----Original Message-----
> From: Jeff Garzik [mailto:jgarzik@pobox.com]
> Sent: Wednesday, March 01, 2006 12:23 PM
> To: Tarte, Robert
> Cc: Mike Anderson; James Bottomley; linux-scsi@vger.kernel.org;
> Tarte@us.ibm.com; Jeff Garzik
> Subject: Re: [PATCH] aic94xx: driver assertion in non-x86 BIOS env
> 
> Tarte, Robert wrote:
> > What model ia64 are you running James?  I'll see if Adaptec has one
to
> > try to help reproduce this issue.  Jeff, have you tried the fixes to
see
> > if they addressed the issues you were seeing (OCM error when BIOS
off
> > and booted off of SCSI)?
> 
> Nah, I'm just waiting for James to ACK that things work on his side,
> really...
> 
> 	Jeff

Re: [PATCH] aic94xx: driver assertion in non-x86 BIOS env

[Matthew Wilcox]

On Wed, Mar 01, 2006 at 12:57:12PM -0800, Tarte, Robert wrote:
> I have located an HP machine that is the same flavor as James' (HP
> Integrity rx2600: ia64 with zx1 chipset).  It exhibits the same problem.
> I believe that the architecture may differ with traditional PC/PCI
> architectures in how it deals with non-aligned PCI access.  When I
> converted the OCM initialization code to write on qwords instead of
> dwords, the code was able to pass OCM initialization.  It is possible
> that the machine is doing a qword read/modify/write when accessing OCM
> memory, which would explain the hang.  I haven't hooked up a PCI
> analyzer.  The code now gets to the point where it is trying to read
> NVRAM in order to get the SAS address.  It seems that the machine is
> unable to retrieve non-aligned byte accesses correctly.  I will convert
> the code to pull the correct byte/word/dword from the aligned qword.
> We'll see if that fixes it.  None of these behaviors are exhibited on
> x86, x86_64, powerpc, and ia64 without the zx1 chipset.  I understand
> that there may be a few ARM implementations that have similar issues.

You're saying that you do an 8-byte non-DMA write to an address
that's congruent to 4 mod 8?  Based on briefly skimming the internal
documentation for zx1, I'd say you're invoking undefined behaviour.

> Mike: any word on getting James a machine?
> 
> Rob
> 
> > -----Original Message-----
> > From: Jeff Garzik [mailto:jgarzik@pobox.com]
> > Sent: Wednesday, March 01, 2006 12:23 PM
> > To: Tarte, Robert
> > Cc: Mike Anderson; James Bottomley; linux-scsi@vger.kernel.org;
> > Tarte@us.ibm.com; Jeff Garzik
> > Subject: Re: [PATCH] aic94xx: driver assertion in non-x86 BIOS env
> > 
> > Tarte, Robert wrote:
> > > What model ia64 are you running James?  I'll see if Adaptec has one
> to
> > > try to help reproduce this issue.  Jeff, have you tried the fixes to
> see
> > > if they addressed the issues you were seeing (OCM error when BIOS
> off
> > > and booted off of SCSI)?
> > 
> > Nah, I'm just waiting for James to ACK that things work on his side,
> > really...
> > 
> > 	Jeff
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] aic94xx: driver assertion in non-x86 BIOS env

[James Bottomley]

On Wed, 2006-03-01 at 12:57 -0800, Tarte, Robert wrote:
> Mike: any word on getting James a machine?

I have an x206m ... I'm just converting the driver to attach to the sas
transport class now.

James

RE: [PATCH] aic94xx: driver assertion in non-x86 BIOS env

[James Bottomley]

On Wed, 2006-03-01 at 12:57 -0800, Tarte, Robert wrote:
> I have located an HP machine that is the same flavor as James' (HP
> Integrity rx2600: ia64 with zx1 chipset).  It exhibits the same problem.
> I believe that the architecture may differ with traditional PC/PCI
> architectures in how it deals with non-aligned PCI access.  When I
> converted the OCM initialization code to write on qwords instead of
> dwords, the code was able to pass OCM initialization.  It is possible
> that the machine is doing a qword read/modify/write when accessing OCM
> memory, which would explain the hang.  I haven't hooked up a PCI
> analyzer.  The code now gets to the point where it is trying to read
> NVRAM in order to get the SAS address.  It seems that the machine is
> unable to retrieve non-aligned byte accesses correctly.  I will convert
> the code to pull the correct byte/word/dword from the aligned qword.
> We'll see if that fixes it.  None of these behaviors are exhibited on
> x86, x86_64, powerpc, and ia64 without the zx1 chipset.  I understand
> that there may be a few ARM implementations that have similar issues.

Could you post the patch that gets it working?

I'd like to try on my zx2000, and I'm sure the HP ZX1 people would like
to see it to try and work out what's going on on the ZX1 bus.

Thanks,

James

RE: [PATCH] aic94xx: driver assertion in non-x86 BIOS env

[Tarte, Robert]

> -----Original Message-----
> From: Matthew Wilcox [mailto:matthew@wil.cx]
> Sent: Wednesday, March 01, 2006 1:12 PM
> To: Tarte, Robert
> Cc: Jeff Garzik; Mike Anderson; James Bottomley; linux-
> scsi@vger.kernel.org; Jeff Garzik
> Subject: Re: [PATCH] aic94xx: driver assertion in non-x86 BIOS env
> 
> On Wed, Mar 01, 2006 at 12:57:12PM -0800, Tarte, Robert wrote:
> > I have located an HP machine that is the same flavor as James' (HP
> > Integrity rx2600: ia64 with zx1 chipset).  It exhibits the same
problem.
> > I believe that the architecture may differ with traditional PC/PCI
> > architectures in how it deals with non-aligned PCI access.  When I
> > converted the OCM initialization code to write on qwords instead of
> > dwords, the code was able to pass OCM initialization.  It is
possible
> > that the machine is doing a qword read/modify/write when accessing
OCM
> > memory, which would explain the hang.  I haven't hooked up a PCI
> > analyzer.  The code now gets to the point where it is trying to read
> > NVRAM in order to get the SAS address.  It seems that the machine is
> > unable to retrieve non-aligned byte accesses correctly.  I will
convert
> > the code to pull the correct byte/word/dword from the aligned qword.
> > We'll see if that fixes it.  None of these behaviors are exhibited
on
> > x86, x86_64, powerpc, and ia64 without the zx1 chipset.  I
understand
> > that there may be a few ARM implementations that have similar
issues.
> 
> You're saying that you do an 8-byte non-DMA write to an address
> that's congruent to 4 mod 8?  Based on briefly skimming the internal
> documentation for zx1, I'd say you're invoking undefined behaviour.

Thanks for the confirmation.  Internal documentation for zx1?  Where can
I locate this?  Thanks in advance.

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

Re: [PATCH] aic94xx: driver assertion in non-x86 BIOS env

[Jeff Garzik]

On Wed, Mar 01, 2006 at 01:22:56PM -0800, Tarte, Robert wrote:
> > From: Matthew Wilcox [mailto:matthew@wil.cx]
> > You're saying that you do an 8-byte non-DMA write to an address
> > that's congruent to 4 mod 8?  Based on briefly skimming the internal
> > documentation for zx1, I'd say you're invoking undefined behaviour.

> Thanks for the confirmation.  Internal documentation for zx1?  Where can
> I locate this?  Thanks in advance.

Overall, I would say that -- for any arch, not just zx1 -- you need to
make sure your write[bwlq]() calls are always naturally aligned in the
given register space.  Anything else invites problems.

It sounds like you are already on the right track, though, converting
non-aligned writeq() to write[bwl]...

	Jeff