On Mon, 20 Sep 1999, Gregory P. Smith wrote:
> After applying 2.3.18ac7 patches, the sym53c8xx driver appears to have
> been updated to a new version (1.5e). This driver checks the speed of
> the PCI bus using the SCSI card and aborts with an error if it is
> above 37Mhz.
This 10% tolerance is a guessing from me of the kernel utime() calibration
precision.
> This is what I see:
>
> sym53c8xx: at PCI bus 0, device 10, function 0
> sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
> sym53c8xx: 53c875 detected with Symbios NVRAM
> sym53c875-0: rev=0x03, base=0xe3000000, io_port=0xb400, irq=12
> sym53c875-0: Symbios format NVRAM, ID 7, Fast-20, Parity Checking
> sym53c875-0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 05/0e/a0/01/00/24
> sym53c875-0: final SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 05/46/80/00/08/24
> sym53c875-0: on-chip RAM at 0xe2800000
> sym53c875-0: Delay (GEN=11): 225 msec, 39503 KHz
> sym53c875-0: Delay (GEN=11): 212 msec, 41926 KHz
> sym53c875-0: Delay (GEN=11): 213 msec, 41729 KHz
> sym53c875-0: PCI clock seems too high (41729 KHz).
Indeed it seems so.
> [I removed the 'goto abort' in the code so that I could get past here...]
If the driver is more than 20 % wrong on the estimation of the SCSI clock,
then it may wrongly enable the SCSI clock doubler of a 875 chip rev >= 2
using a 80 MHz, and in the worst case, the controller may be damaged. In
less bad situations, the driver may base it synchronous data settings on a
wrong SCSI clock value and fail synchronous data transfers.
The PCI clock calculation by the driver is a _reality_ test that is
intended to ensure that the driver algorithm for clock measurement is safe
enough for a breakage of a 875 chip rev >= 2 using a 80 Mhz never to
happen due to driver fault, even if some bug in the kernel or the driver
ever breaks the algorithm.
In fact, the risk is very low since 875s rev >= 2 generally use a 40 MHz
SCSI clock and 875 rev < 2 donnot have clock doubler (the driver code is
aware of that). But I cannot decide by myself that there is no risk at
all.
On the other hand, overclocking a PCI BUS by more than 10% seems unserious
to me, and the code I provided before implicitely didn't support so much
overclocked PCI BUS. Driver 1.5e is now enforcing explicitely this point.
All that means that I am NOT going to remove the 'goto attach_failed' that
you decided to remove.
> sym53c875-0: resetting, command processing suspended for 2 seconds
> sym53c875-0: restart (scsi reset).
> sym53c875-0: enabling clock multiplier
> sym53c875-0: Downloading SCSI SCRIPTS.
> scsi0 : sym53c8xx - version 1.5e
> scsi : 1 host.
>
> This is the first time I've actually "measured" the speed of my PCI bus.
> My motherboard is an Asus SP97V (SiS 5598 chipset) with a Cyrix M-II
> CPU running at 3x 83.3Mhz. The jumper on the motherboard to run the PCI
> bus asynchronously -is- set (FS3 on pins 2-3) so I was surprised to see
> it running at half my memory bus speed.
>
> I haven't had any problems with the system that I haven't been able to
> narrow down to other hardware. Has anyone else had experience with
> motherboards running the PCI bus too fast or know anything about my
> particular board?
>
> Ultimately I care more about stability than bus speed.
Then, let me know if it is the driver that is wrong ou your hardware. If
the driver is right and you really care about stability, then you must fix
your hardware configuration. Otherwise you may want to send me information
for me to fix the bug. Thanks.
G�rard.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
