fix command retries in spi_transport class

PATCH In review James Bottomley 2 participants 7 messages May 1, 2005 – May 5, 2005 SCSI

Share & tools

James Bottomley

author

2005-05-01 23:58 UTC #0 lore raw

PATCH 1/1 fix command retries in spi_transport class

This will likely fix the adaptec domain validation problem. However, it's not a true fix if the mid-layer is losing commands, it just makes it far less likely to get into that situation.

The premise is that domain validation is likely to trigger errors which it wants to know about, so the only time it should be retrying them is when it gets a unit attention (likely as the result of a previous bus or device reset). Ironically, the previous coding retried three times in all cases except those of unit attention. The attached fixes this to do the right thing.

James

drivers/scsi/scsi_transport_spi.c (mode:100644) +34 ~~-15~~

@@ -22,6 +22,7 @@
 #include <linux/init.h>
 #include <linux/module.h>
 #include <linux/workqueue.h>
+#include <linux/blkdev.h>
 #include <asm/semaphore.h>
 #include <scsi/scsi.h>
 #include "scsi_priv.h"

@@ -41,6 +42,11 @@
 
 #define SPI_MAX_ECHO_BUFFER_SIZE	4096
 
+#define DV_LOOPS	3
+#define DV_TIMEOUT	(10*HZ)
+#define DV_RETRIES	3	/* should only need at most 
+				 * two cc/ua clears */
+
 /* Private data accessors (keep these out of the header file) */
 #define spi_dv_pending(x) (((struct spi_transport_attrs *)&(x)->starget_data)->dv_pending)
 #define spi_dv_sem(x) (((struct spi_transport_attrs *)&(x)->starget_data)->dv_sem)

@@ -100,6 +106,29 @@ static int sprint_frac(char *dest, int v
 	return result;
 }
 
+/* Modification of scsi_wait_req that will clear UNIT ATTENTION conditions
+ * resulting from (likely) bus and device resets */
+static void spi_wait_req(struct scsi_request *sreq, const void *cmd,
+			 void *buffer, unsigned bufflen)
+{
+	int i;
+
+	for(i = 0; i < DV_RETRIES; i++) {
+		sreq->sr_request->flags |= REQ_FAILFAST;
+
+		scsi_wait_req(sreq, cmd, buffer, bufflen,
+			      DV_TIMEOUT, /* retries */ 1);
+		if (sreq->sr_result & DRIVER_SENSE) {
+			struct scsi_sense_hdr sshdr;
+
+			if (scsi_request_normalize_sense(sreq, &sshdr)
+			    && sshdr.sense_key == UNIT_ATTENTION)
+				continue;
+		}
+		break;
+	}
+}
+
 static struct {
 	enum spi_signal_type	value;
 	char			*name;

@@ -378,11 +407,6 @@ static CLASS_DEVICE_ATTR(signalling, S_I
 	if(i->f->set_##x)		\
 		i->f->set_##x(sdev->sdev_target, y)
 
-#define DV_LOOPS	3
-#define DV_TIMEOUT	(10*HZ)
-#define DV_RETRIES	3	/* should only need at most 
-				 * two cc/ua clears */
-
 enum spi_compare_returns {
 	SPI_COMPARE_SUCCESS,
 	SPI_COMPARE_FAILURE,

@@ -446,8 +470,7 @@ spi_dv_device_echo_buffer(struct scsi_re
 	for (r = 0; r < retries; r++) {
 		sreq->sr_cmd_len = 0;	/* wait_req to fill in */
 		sreq->sr_data_direction = DMA_TO_DEVICE;
-		scsi_wait_req(sreq, spi_write_buffer, buffer, len,
-			      DV_TIMEOUT, DV_RETRIES);
+		spi_wait_req(sreq, spi_write_buffer, buffer, len);
 		if(sreq->sr_result || !scsi_device_online(sdev)) {
 			struct scsi_sense_hdr sshdr;

@@ -471,8 +494,7 @@ spi_dv_device_echo_buffer(struct scsi_re
 		memset(ptr, 0, len);
 		sreq->sr_cmd_len = 0;	/* wait_req to fill in */
 		sreq->sr_data_direction = DMA_FROM_DEVICE;
-		scsi_wait_req(sreq, spi_read_buffer, ptr, len,
-			      DV_TIMEOUT, DV_RETRIES);
+		spi_wait_req(sreq, spi_read_buffer, ptr, len);
 		scsi_device_set_state(sdev, SDEV_QUIESCE);
 
 		if (memcmp(buffer, ptr, len) != 0)

@@ -500,8 +522,7 @@ spi_dv_device_compare_inquiry(struct scs
 
 		memset(ptr, 0, len);
 
-		scsi_wait_req(sreq, spi_inquiry, ptr, len,
-			      DV_TIMEOUT, DV_RETRIES);
+		spi_wait_req(sreq, spi_inquiry, ptr, len);
 		
 		if(sreq->sr_result || !scsi_device_online(sdev)) {
 			scsi_device_set_state(sdev, SDEV_QUIESCE);

@@ -593,8 +614,7 @@ spi_dv_device_get_echo_buffer(struct scs
 	 * (reservation conflict, device not ready, etc) just
 	 * skip the write tests */
 	for (l = 0; ; l++) {
-		scsi_wait_req(sreq, spi_test_unit_ready, NULL, 0,
-			      DV_TIMEOUT, DV_RETRIES);
+		spi_wait_req(sreq, spi_test_unit_ready, NULL, 0);
 
 		if(sreq->sr_result) {
 			if(l >= 3)

@@ -608,8 +628,7 @@ spi_dv_device_get_echo_buffer(struct scs
 	sreq->sr_cmd_len = 0;
 	sreq->sr_data_direction = DMA_FROM_DEVICE;
 
-	scsi_wait_req(sreq, spi_read_buffer_descriptor, buffer, 4,
-		      DV_TIMEOUT, DV_RETRIES);
+	spi_wait_req(sreq, spi_read_buffer_descriptor, buffer, 4);
 
 	if (sreq->sr_result)
 		/* Device has no echo buffer */

K.R. Foley

2005-05-02 14:12 UTC #1 lore raw

Quoted 4 lines · James Bottomley

This will likely fix the adaptec domain validation problem. However, it's not a true fix if the mid-layer is losing commands, it just makes it far less likely to get into that situation.

Quoted 9 lines

The premise is that domain validation is likely to trigger errors which it wants to know about, so the only time it should be retrying them is when it gets a unit attention (likely as the result of a previous bus or device reset). Ironically, the previous coding retried three times in all cases except those of unit attention. The attached fixes this to do the right thing.
James

Hi James,

The patch that I snipped below doesn't visibly change anything except a couple of lines at the end (or beginning) of the stack trace. I didn't even notice a difference in the verbosity in the log and I did have logging turned on. I am attaching the log of the oops as well as the kernel command line from /etc/grub.conf. Unfortunately, right now I really don't have the time to just jump in and start debugging this myself. Please don't take that as a lack of interest, just a lack of time. I will be glad to provide any further info or testing that I can.

kernel /vmlinuz-2.6.12-rc3 ro root=LABEL=/ console=ttyS0,38400 console=tty0 nmi_watchdog=1 scsi_logging_level=0xffff

Thanks again,

Signature · 1 line

kr

Linux version 2.6.12-rc3 ([email protected]) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)) #7 SMP Sun May 1 20:37:19 CDT 2005 BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001ff9e000 (usable)
BIOS-e820: 000000001ff9e000 - 0000000020000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
511MB LOWMEM available.
found SMP MP-table at 000fe710
DMI 2.3 present.
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 6:8 APIC version 17
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 6:8 APIC version 17
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
Using ACPI for processor (LAPIC) configuration information
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: DELL Product ID: WS 620 APIC at: 0xFEE00000
I/O APIC #2 Version 32 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 2
Allocating PCI resources starting at 20000000 (gap: 20000000:dec00000)
Built 1 zonelists
Kernel command line: ro root=LABEL=/ console=ttyS0,38400 console=tty0 nmi_watchdog=1 scsi_logging_level=0xffff Initializing CPU#0
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 931.186 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 514224k/523896k available (2074k kernel code, 9116k reserved, 1124k data, 228k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel Pentium III (Coppermine) stepping 06
Booting processor 1/1 eip 2000
Initializing CPU#1
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel Pentium III (Coppermine) stepping 06
Total of 2 processors activated (3698.68 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=0
testing NMI watchdog ... CPU#1: NMI appears to be stuck!
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
checking if image is initramfs... it is
Freeing initrd memory: 304k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfc03e, last bus=4
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Transparent bridge - 0000:00:1e.0
PCI: Using IRQ router PIIX/ICH [8086/2410] at 0000:00:1f.0
PCI->APIC IRQ transform: 0000:00:1f.2[D] -> IRQ 19
PCI->APIC IRQ transform: 0000:00:1f.3[B] -> IRQ 17
PCI->APIC IRQ transform: 0000:01:00.0[A] -> IRQ 16
PCI->APIC IRQ transform: 0000:04:04.0[A] -> IRQ 16
PCI->APIC IRQ transform: 0000:04:05.0[A] -> IRQ 17
PCI->APIC IRQ transform: 0000:04:05.1[B] -> IRQ 18
PCI->APIC IRQ transform: 0000:04:0a.0[A] -> IRQ 18
PCI: Failed to allocate mem resource #0:1000@0 for 0000:03:00.0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
nvidiafb: nVidia device/chipset 10DE0103
nvidiafb: nVidia Corporation NV10GL [Quadro]
nvidiafb: HW is currently programmed for CRT
nvidiafb: Using CRT on CRTC 0
nvidiafb: MTRR set to ON
nvidiafb: PCI nVidia NV10 framebuffer (64MB @ 0xE8000000)
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH: IDE controller at PCI slot 0000:00:1f.1
ICH: chipset revision 2
ICH: not 100% native mode: will probe irqs later

    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio

hda: SAMSUNG CD-R/RW SW-248F, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: Lite-On LTN483S 48x Max, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

Vendor: QUANTUM Model: ATLAS10K2-TY092L Rev: DA40
Type: Direct-Access ANSI SCSI revision: 03
scsi0:A:0:0: Tagged Queuing enabled. Depth 32
target0:0:0: Beginning Domain Validation
(scsi0:A:0): 6.600MB/s transfers (16bit)
(scsi0:A:0): 80.000MB/s transfers (40.000MHz, offset 127, 16bit)
target0:0:0: Ending Domain Validation
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
<Adaptec aic7899 Ultra160 SCSI adapter>
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs

Unable to handle kernel NULL pointer dereference at virtual address 00000104
 printing eip:
c02786f6
*pde = 00000000
Oops: 0000 [#1]
PREEMPT SMP 
Modules linked in:
CPU:    1
EIP:    0060:[<c02786f6>]    Not tainted VLI
EFLAGS: 00010006   (2.6.12-rc3)

EIP is at ahc_send_async+0xf6/0x2d0
eax: 00000100 ebx: ffffff00 ecx: 00000000 edx: 00000000
esi: 00000000 edi: c15f0400 ebp: dff03d84 esp: dff03cfc
ds: 007b es: 007b ss: 0068
Process swapper (pid: 0, threadinfo=dff02000 task=c150f540)

Stack: 00000000 00000000 000505f9 00000000 00000000 c15f0400 00000100 dff03d28 
       00000050 00000000 00000000 ffffffff dff03dbc c027866b c1665c00 ffffffbf 
       00000000 c15f0498 00000000 c15f0400 dff03d68 c0262b6f c15f0400 c15f0490 
Call Trace:
 [<c0103e4f>] show_stack+0x7f/0xa0
 [<c0103ff3>] show_registers+0x163/0x1e0
 [<c0104231>] die+0x101/0x190
 [<c0113142>] do_page_fault+0x472/0x6b9
 [<c0103a7b>] error_code+0x4f/0x54
 [<c0266489>] ahc_set_width+0x109/0x1a0
 [<c026e661>] ahc_reset_channel+0x301/0x530
 [<c02646b0>] ahc_handle_scsiint+0x180/0xf80
 [<c0278208>] ahc_linux_isr+0x218/0x2e0
 [<c013c80e>] handle_IRQ_event+0x3e/0x90
 [<c013c937>] __do_IRQ+0xd7/0x160
 [<c0105666>] do_IRQ+0x26/0x40
 [<c0103946>] common_interrupt+0x1a/0x20
 [<c0100c8e>] cpu_idle+0x4e/0x90
 [<00000000>] 0x0
 [<dff03fbc>] 0xdff03fbc
Code: 14 01 00 00 0f b6 97 3b 01 00 00 80 f9 42 8d 42 08 0f 44 d0 8b 8c 97 c0 00 00 00 8d 04 f6 8d 04 46 01 c8 05 00 01 00 00 89 45 90 <0f> b6 48 04 3a 48 0a 0f 84 ec 00 00 00 a1 0c c5 47 c0 85 c0 74 
 <0>Kernel panic - not syncing: Fatal exception in interrupt

James Bottomley

author

2005-05-02 14:18 UTC #2 lore raw

Quoted 11 lines · K.R. Foley

 [<c0266489>] ahc_set_width+0x109/0x1a0
 [<c026e661>] ahc_reset_channel+0x301/0x530
 [<c02646b0>] ahc_handle_scsiint+0x180/0xf80
 [<c0278208>] ahc_linux_isr+0x218/0x2e0
 [<c013c80e>] handle_IRQ_event+0x3e/0x90
 [<c013c937>] __do_IRQ+0xd7/0x160
 [<c0105666>] do_IRQ+0x26/0x40
 [<c0103946>] common_interrupt+0x1a/0x20
 [<c0100c8e>] cpu_idle+0x4e/0x90
 [<00000000>] 0x0
 [<dff03fbc>] 0xdff03fbc

Actually, you need to reverse the bogus patch to aic7xxx_core.c as well ... that's what's causing the oops.

James

K.R. Foley

2005-05-02 14:20 UTC #3 lore raw

Quoted 15 lines · James Bottomley

Quoted 11 lines · K.R. Foley

[<c0266489>] ahc_set_width+0x109/0x1a0
[<c026e661>] ahc_reset_channel+0x301/0x530
[<c02646b0>] ahc_handle_scsiint+0x180/0xf80
[<c0278208>] ahc_linux_isr+0x218/0x2e0
[<c013c80e>] handle_IRQ_event+0x3e/0x90
[<c013c937>] __do_IRQ+0xd7/0x160
[<c0105666>] do_IRQ+0x26/0x40
[<c0103946>] common_interrupt+0x1a/0x20
[<c0100c8e>] cpu_idle+0x4e/0x90

[<00000000>] 0x0
[<dff03fbc>] 0xdff03fbc

Quoted 7 lines

Actually, you need to reverse the bogus patch to aic7xxx_core.c as well ... that's what's causing the oops.
James

Arggg :-) I will try that and report back.

Signature · 1 line

kr

K.R. Foley

2005-05-02 14:44 UTC #4 lore raw

In reply to James Bottomley

Quoted 15 lines · James Bottomley

Quoted 11 lines · K.R. Foley

[<c0266489>] ahc_set_width+0x109/0x1a0
[<c026e661>] ahc_reset_channel+0x301/0x530
[<c02646b0>] ahc_handle_scsiint+0x180/0xf80
[<c0278208>] ahc_linux_isr+0x218/0x2e0
[<c013c80e>] handle_IRQ_event+0x3e/0x90
[<c013c937>] __do_IRQ+0xd7/0x160
[<c0105666>] do_IRQ+0x26/0x40
[<c0103946>] common_interrupt+0x1a/0x20
[<c0100c8e>] cpu_idle+0x4e/0x90

[<00000000>] 0x0
[<dff03fbc>] 0xdff03fbc

Quoted 4 lines

Actually, you need to reverse the bogus patch to aic7xxx_core.c as well ... that's what's causing the oops.
James

James,

All I can tell you for sure is that it didn't boot. I will have to look at this evening when I get home.

Thanks,

Signature · 1 line

kr

K.R. Foley

2005-05-03 02:04 UTC #5 lore raw

In reply to James Bottomley

Quoted 4 lines · James Bottomley

This will likely fix the adaptec domain validation problem. However, it's not a true fix if the mid-layer is losing commands, it just makes it far less likely to get into that situation.

Quoted 9 lines

The premise is that domain validation is likely to trigger errors which it wants to know about, so the only time it should be retrying them is when it gets a unit attention (likely as the result of a previous bus or device reset). Ironically, the previous coding retried three times in all cases except those of unit attention. The attached fixes this to do the right thing.
James

James,

I captured the attached boot log with the scsi transport patch you sent me. Changes a little but still hangs.

Signature · 1 line

kr

Linux version 2.6.12-rc3 ([email protected]) (gcc version 3.4.3 20050227 (Red Hat 3.4.3-22.fc3)) #8 SMP Mon May 2 09:22:59 CDT 2005 BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001ff9e000 (usable)
BIOS-e820: 000000001ff9e000 - 0000000020000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
511MB LOWMEM available.
found SMP MP-table at 000fe710
DMI 2.3 present.
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 6:8 APIC version 17
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 6:8 APIC version 17
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
Using ACPI for processor (LAPIC) configuration information
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: DELL Product ID: WS 620 APIC at: 0xFEE00000
I/O APIC #2 Version 32 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 2
Allocating PCI resources starting at 20000000 (gap: 20000000:dec00000)
Built 1 zonelists
Kernel command line: ro root=LABEL=/ console=ttyS0,38400 console=tty0 nmi_watchdog=1 scsi_logging_level=0xffff Initializing CPU#0
PID hash table entries: 2048 (order: 11, 32768 bytes)
Detected 931.119 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 514224k/523896k available (2074k kernel code, 9116k reserved, 1124k data, 228k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel Pentium III (Coppermine) stepping 06
Booting processor 1/1 eip 2000
Initializing CPU#1
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel Pentium III (Coppermine) stepping 06
Total of 2 processors activated (3698.68 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=2 pin2=0
testing NMI watchdog ... CPU#1: NMI appears to be stuck!
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
checking if image is initramfs... it is
Freeing initrd memory: 304k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfc03e, last bus=4
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Transparent bridge - 0000:00:1e.0
PCI: Using IRQ router PIIX/ICH [8086/2410] at 0000:00:1f.0
PCI->APIC IRQ transform: 0000:00:1f.2[D] -> IRQ 19
PCI->APIC IRQ transform: 0000:00:1f.3[B] -> IRQ 17
PCI->APIC IRQ transform: 0000:01:00.0[A] -> IRQ 16
PCI->APIC IRQ transform: 0000:04:04.0[A] -> IRQ 16
PCI->APIC IRQ transform: 0000:04:05.0[A] -> IRQ 17
PCI->APIC IRQ transform: 0000:04:05.1[B] -> IRQ 18
PCI->APIC IRQ transform: 0000:04:0a.0[A] -> IRQ 18
PCI: Failed to allocate mem resource #0:1000@0 for 0000:03:00.0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
nvidiafb: nVidia device/chipset 10DE0103
nvidiafb: nVidia Corporation NV10GL [Quadro]
nvidiafb: HW is currently programmed for CRT
nvidiafb: Using CRT on CRTC 0
nvidiafb: MTRR set to ON
nvidiafb: PCI nVidia NV10 framebuffer (64MB @ 0xE8000000)
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH: IDE controller at PCI slot 0000:00:1f.1
ICH: chipset revision 2
ICH: not 100% native mode: will probe irqs later

    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio

Vendor: SEAGATE Model: SX118273LC Rev: 6679
Type: Direct-Access ANSI SCSI revision: 02
scsi1:A:0:0: Tagged Queuing enabled. Depth 32
target1:0:0: Beginning Domain Validation
(scsi1:A:0): 6.600MB/s transfers (16bit)
(scsi1:A:0:0): parity error detected in Data-in phase. SEQADDR(0x6a) SCSIRATE(0x80) (scsi1:A:0:0): parity error detected in Data-in phase. SEQADDR(0x83) SCSIRATE(0x80) (scsi1:A:0:0): parity error detected in Data-in phase. SEQADDR(0x83) SCSIRATE(0x80) (scsi1:A:0:0): parity error detected in Data-in phase. SEQADDR(0x1a6) SCSIRATE(0x80) (scsi1:A:0:0): parity error detected in Command phase. SEQADDR(0x1a6) SCSIRATE(0x80)
target1:0:0: Wide Transfers Fail
(scsi1:A:0): 3.300MB/s transfers

James Bottomley

author

2005-05-05 14:57 UTC #6 lore raw

Quoted 11 lines · K.R. Foley

Vendor: SEAGATE Model: SX118273LC Rev: 6679
Type: Direct-Access ANSI SCSI revision: 02
scsi1:A:0:0: Tagged Queuing enabled. Depth 32
target1:0:0: Beginning Domain Validation
(scsi1:A:0): 6.600MB/s transfers (16bit)
(scsi1:A:0:0): parity error detected in Data-in phase. SEQADDR(0x6a) SCSIRATE(0x80) (scsi1:A:0:0): parity error detected in Data-in phase. SEQADDR(0x83) SCSIRATE(0x80) (scsi1:A:0:0): parity error detected in Data-in phase. SEQADDR(0x83) SCSIRATE(0x80) (scsi1:A:0:0): parity error detected in Data-in phase. SEQADDR(0x1a6) SCSIRATE(0x80) (scsi1:A:0:0): parity error detected in Command phase. SEQADDR(0x1a6) SCSIRATE(0x80)
target1:0:0: Wide Transfers Fail

This means that the driver is now correctly returning an error.

Quoted 1 line

(scsi1:A:0): 3.300MB/s transfers

Here we set the correct transfer parameters (narrow), which means all the parity errors should go away.

I'm at a loss to either duplicate this or figure out from the code what might be going on, so I really need a trace to help out.

If you can't set the kernel boot line options, you can just edit scsi.c to set the variable scsi_logging_level to 0xffff (and remove the module_param lines for it, just in case). Remember that CONFIG_SCSI_LOGGING must be set as well.

Thanks,

James