If you really want it, i may send as personal email only. For short:
SMP=y, (Tyan tomcat IIID);
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=m
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
CONFIG_SCSI_NCR53C8XX=y
CONFIG_SCSI_NCR53C8XX_NVRAM_DETECT=y
CONFIG_SCSI_NCR53C8XX_TAGGED_QUEUE=y
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=12
CONFIG_SCSI_NCR53C8XX_SYNC=10
CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT=y
The *_NCR53C8XX_* change frequently, without obvious influence.
>Reverting the driver to 2.5f version (linux-2.1.106(7?) driver files)
>may also fix the problem
Its in stock 107. But my last message was missleading. With 2.1.117+2.5f,
i got those
> ncr53c875-0-<0,0>: M_REJECT sent for 1-3-1-19-1e.
i mentioned at 1998.09.05.
> A memory corruption is very probable.
Last night, i did some recompilations for 2.1.107+3.0g+u_long dummies,
excluding some of thoe u_long temp*. With 1. temp0 through temp2,
2. temp2, 3. temp0 through temp4, 4. temp0 through temp6, 5. temp7,
i allways got M_REJECT´s 8-<
With 1. i was happy for not seeing a M_REJECT at boot time. But at shutdown
(to reboot 2.) i got one!
> > Of course, i really tried hard to avoid any violation of scsi
> > standards before!
> Do you mean you now do the opposite ? :-)
Both. 1. I did not want to litter the kernel list with scsi cabeling &
termination problems, so i _tested_before_mailing_ .
2. Due to some physical restrictions, the mo drive must be the last in
the scsi II chain during normal operation. I have no active termination
for it. (And no spare slot for another scsi adapter).
gerhard.
-
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