David, Geert, my Falcon has some variant of this clock patch installed - it may not be precisely the one described but reasonably close. It also has one of the old 030 accelerator tricks (clock doubling of the 030 if the CPU does not do bus cycles - named Skunk) fitted; the clock patch was installed at the same time. The Falcon ran stable with just SCSI disks in use (so no locking races) until a few years ago when I started to use it for kernel hacking. There were the occasional SCSI lockups which I attributed to the SCSI clock problem, for want of a better explanation. IIRC when the clock signal to the 5380 becomes unstable, the chip locks up and needs to be reset. With the old 2.4 kernels, recovery from reset worked OK and I've not seen disk corruption or hard read errors. 2.6 kernels changed a lot of things around SCSI midlevel and error handling. I could never make error recovery from these SCSI lockups work in 2.6 or 3.x until Arnd's locking fixes (and my patch to defer command queueing if the lock had been taken by IDE). The lockups did not stop happening until Finn's patches - and I probably need to emphasize again that they are gone entirely now. It does seem 2.4 suffered from similar race problems, the driver just managed to recover from those. Leaves the current instability - I did some work on the CT60 accelerator (reflashed the firmware so I can use the CTPCI board). This might have caused the system to become more unstable. Needs more investigation. Cheers, Michael On Wed, Nov 5, 2014 at 9:10 PM, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > On Wed, Nov 5, 2014 at 8:56 AM, David Gálvez <dgalvez75@xxxxxxxxx> wrote: >> Do you know about the Falcon's disturbance in the SDMA clock signal >> hardware problem? >> Most Falcons, specially those used in music studios, have a hardware >> patch to fix this, it's normally called SCSI patch. >> >> Some more info: >> >> http://didierm.pagesperso-orange.fr/doc/eng/c_0a.htm > > So this adds additional buffering to the clock. > > Note that input pins 3 and 5 of the 74HC04 are left floating! > I recommend tying them to either GND (pin 7) or VCC (pin 14), to avoid > them picking up high-frequency signals and consuming power. > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds -- To unsubscribe from this list: 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
