> at 10 Sep 1998 01:47:27 +0200, Krzysztof Halasa <khc@intrepid.pm.waw.pl> wrote:
>
> > There were no such problems with 2.1.105 and before.
>
> Did you test 2.1.107 and 2.1.108 or 109?
>
> Around that, ncr driver version 3.0 was introduced. It is this version
> only that caused trubble for me.
I have received 4 breakage reports with 3.0x drivers. I am currently
working on the problem. It is quite fine to send problem reports but
there are important basic informations that are often missing as:
- The _whole_ kernel config used (driver config is not enough).
- Patches applied to the official kernel versions, if any.
- C Compiler version.
> Gerard Roudier suggested to use sym53c8xx-0.4 from
>
> ftp://ftp.tux.org/pub/roudier/896/
>
> which now works fine for me with 2.1.107 and 2.1.117.
The development driver available at this URL has simpler C and SCRIPTS
code than previous versions due to the use of LOAD/STORE SCRIPTS
instructions but just drops support for old 810, 815 and 825 that donnot
implement LOAD/STORE instructions.
It supports 810A, 860, 825A, 875, 876, 895, and 896 (896 in theory for the
moment).
Reverting the driver to 2.5f version (linux-2.1.106(7?) driver files) may
also fix the problem, but obviously will not help debugging 3.0x and
the pre-sym-896 driver. People decide as they want.
For now driver 3.0x is part of linux-2.1 which is in feature freeze in
order to fix remaining bugs.
By the way, 3.0x drivers work fine for lots of users of 53c8xx controllers,
otherwise I probably received far more problem reports.
> We also introduced some dummy u_long variables at various places in
> driver 3.0g (from kernel 2.1.117). This made the M_REJECT´s go away
> but caused some random 1-2second lockups, indicating memory corruption.
A memory corruption is very probable. Now, we have to find where/when
memory is corrupted. It seems to occur during the device scan at start-up.
I will compile informations I have and inspect the source code this
week-end.
> Of course, i really tried hard to avoid any violation of scsi standards
> before!
Do you mean you now do the opposite ? :-)
> > Using default SCSI controller settings.
>
> Now i´m happily using:
>
> CONFIG_SCSI_NCR53C8XX=y
> CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8
> CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
> CONFIG_SCSI_NCR53C8XX_SYNC=20
My personnal system is very stable using: (linux-2.0.35 +
pre-sym53c8xx-0.4/0.5)
CONFIG_SCSI_NCR53C8XX=y
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=64
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=64
CONFIG_SCSI_NCR53C8XX_SYNC=40
And my usual config is:
CONFIG_SCSI_NCR53C8XX=y
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=32
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=40
Regards,
Gerard.
-
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/faq.html