On Fri, 2005-04-29 at 05:54 -0500, K.R. Foley wrote: > I tried the patch that you sent. It looks like its blowing up now in > ahc_send_async. At least now we have an oops to look at. I started > trying to trace through this, but ran out of time. I am sending it on to > you in hopes that you'll be able to figure this out much quicker than I can. Well ... there's odd news from this. I can simulate this pretty well just by cutting the upper 8 bits from a wide cable (Which I got right on the second attempt; silly me for assuming that the strands in a ribbon cable would be numbered 1,2,3 etc. 1,35,2,36 is much more logical ...) However, when I do this, I get: Vendor: HP 36.4G Model: ST336607LW Rev: HPC3 Type: Direct-Access ANSI SCSI revision: 03 scsi11:A:1:0: Tagged Queuing enabled. Depth 32 target11:0:1: Beginning Domain Validation (scsi11:A:1): 6.600MB/s transfers (16bit) (scsi11:A:1:0): parity error detected in Data-in phase. SEQADDR(0x84) SCSIRATE(0x80) target11:0:1: Wide Transfers Fail (scsi11:A:1): 3.300MB/s transfers (scsi11:A:1): 40.000MB/s transfers (40.000MHz, offset 63) target11:0:1: Ending Domain Validation Which is what I expected, and also shows that it's not as simple as I was thinking: the aic7xxx not propagating the errors and trying to fix up on its own. However, it could be the command is getting lost in error recovery. Could you enable logging and boot with the parameter scsi_logging_level=0xffff to give me a better trace of what's going on? Thanks, James James - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
