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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
