> Gerard Roudier wrote:
> > - The _whole_ kernel config used
>
> 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
This was a general remark, not against you at all. On the other hand, you
can send me any info by personnal email. Even the kernel image that does
not work for you may help, since for now I am unable to reproduce problems
that have been reported to me.
> The *_NCR53C8XX_* change frequently, without obvious influence.
What about changing SMP and the linux kernel version ?
> >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.
I missed it, sorry.
Depending on driver set-up and device set-up in the SDMS BIOS, this REJECT
may be normal. But, if it is not, then driver 2.5f seems to be affected by
the problem too and knowing the latest kernel that worked for you with
2.5f (and the earliest that did'nt at the same time) would be a _great_
help). Dichotomy is your friend for bug hunting.
> > 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!
Thanks for the time working on this problem. These dummy u_long seem to
proove it is a memory corruption. If I could reproduce the problem, I
would try to track down the problem the way you do it. For now, I have
looked into the driver source and did'nt find anything that explain a
memory corruption from the driver. Will try to find some clue from your
results about dummies change effects on kernel-2.1.107 + driver3.0g
behaviour on your system. Thanks.
> > > 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).
I was joking, but, as you know, active termination is a _requirement_ for
SCSI BUSes using FAST-20 data transfers.
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