The ncr/sym53c8xx driver may use udelay() for the calculation of the SCSI
clock in order not to be wrong for asynchronous transfer and to decide to
use the clock multiplier or not, when a clock multiplier is present.
For now, the udelay() problem seems to let the driver think that the SCSI
clock is too high. The system will not boot, but the hardware will not be
affected.
A bad case will be, for example, the following:
- 875 rev > 1 with exotic 80 MHz SCSI clock detected 40 MHz by the driver.
- the driver will deduce wrongly that the clock doubler is usable.
- the driver enables the doubler and may damage the chip.
Most ncr/sym53c8xx boards are based on a 40 MHz clock, so there is no risk
of hard breakage for them, but a 40 MHz clock is not required and it is
not possible to me to know of all implementations of such boards.
The drivers needs +/-10% precision for udelay() in order to make always
things right and will not risk to damage anything in situation of a 80 MHz
clock, clock doubler present, and udelay() being less than twice faster
than expected. No risk of hardware breakage for now, as I wrote above.
It will be a good thing, in my opinion, to un-inline the small loop used
in all arch delay stuff, or at least to make this a kernel option.
I donnot have alpha. So I invite people who have such machine to
investigate the problem and let us know.
Thanks in advance.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/