...
>Later though, the bus speed is shown as 80MHz:
>
>(scsi1:A:0): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
>SCSI device sdc: 71687370 512-byte hdwr sectors (36704 MB)
...
>There is a mismatch here. I believe the first report is false.
Actually, both are correct. The driver will not negotiate 160 unless
it has seen sufficient inquiry data to verify that the target is capable
of such speeds. This bit of protection avoids problems with broken
devices that mess up in rejecting the new message type required
to negotiate 160. I have not gone looking through the scanning code
recently to verify, but my guess is that Linux now does a "minimal"
inquiry (36 bytes of data) first, determines the amount of inquiry data
the target really has and then issues another inquiry to fetch the rest.
After the first inquiry is sent, we have enough information to safely
negotiate to 40MHz, so we do. After the second inquiry, we see that
double transition clocking is supported by the target and we re-negotiate
to 80MHz-DT.
>Further,
>the reporting of the tag queue depth is conflicting. At boot time, I see
>this:
>
>scsi1:0:0:0: Tagged Queuing enabled. Depth 8
>scsi1:0:1:0: Tagged Queuing enabled. Depth 8
>scsi1:0:2:0: Tagged Queuing enabled. Depth 8
>scsi1:0:3:0: Tagged Queuing enabled. Depth 8
>
>But /proc/scsi/aic7xxx/1 shows this:
>
>Channel A Target 0 Negotiation Settings
> User: 160.000MB/s transfers (80.000MHz DT, offset 255, 16bit)
> Goal: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
> Curr: 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
> Channel A Target 0 Lun 0 Settings
> Commands Queued 320416
> Commands Active 0
> Command Openings 253
> Max Tagged Openings 253
> Device Queue Frozen Count 0
>
>So it looks like the depth is 253.
The SCSI layer has the depth set to 8. Internally, the driver will accept
up to 253, but only 8 are ever queued concurrently. Its just a cosmetic
bug, but I'll fix it in the next drop.
-- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/