On Sat, 7 Nov 1998, Hans-Frieder Vogt wrote:
> Richard Gooch writes:
> ...
> > > > CONFIG_SCSI_NCR53C8XX=y
> > > > CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=8
> > > > CONFIG_SCSI_NCR53C8XX_MAX_TAGS=4
> > >
> > > A default value of 8 for a max value of 4 for the same thing is
> > > bogus.
> >
> I also had an old .config file and the same values.
> After I changed CONFIG_SCSI_NCR53C8XX_MAX_TAGS to 32 (as proposed) the driver
> 3.1a worked FINE :) (tested with pre-patch 2.1.127-7)
> I think, the reason why the previous driver 3.0i worked and 3.1a did not (with
> the mentioned configuration parameters), is because 3.1a uses a field cb_tags
> of exactly the size of MAX_TAGS, while 3.0i used a size of at least 32! So data
> was corrupted, and I wonder why only timeouts were the result of this
> corruption.
Good spotting!
Using DEFAULT_TAGS=33 and MAX_TAGS <= 32 will probably defeat driver 3.0i.
I just omitted to fix such bogus config using #ifXXX stuff. Giving the
weird breakage in such a situation that may ever be triggered by upper
layer changes, I will probably also handle this situation from the C code.
The following patch works for me using the bogus config.
(I have been able to get the breakage by not using the set-up from NVRAM)
--- linux/drivers/scsi/ncr53c8xx.c.ORIG Sun Nov 8 15:56:56 1998
+++ linux/drivers/scsi/ncr53c8xx.c Sun Nov 8 17:02:41 1998
@@ -73,7 +73,7 @@
*/
/*
-** October 21 1998, version 3.1a
+** November 8 1998, version pre-3.1b
**
** Supported SCSI-II features:
** Synchronous negotiation
@@ -8207,6 +8207,12 @@
*/
if (lp) {
XPT_QUEHEAD *qp;
+ /*
+ ** Keep from using more tags than we can handle.
+ */
+ if (lp->usetags && lp->busyccbs >= lp->maxnxs)
+ return (ccb_p) 0;
+
/*
** Allocate a new CCB if needed.
*/
Thanks very much for your problem report and its explanation.
You ask why only timeouts?
When something goes wrong in the SCSI code, we usally get timeouts. As a
result, reporting SCSI timeouts under Linux only means that something
went wrong. Note that on my system, the breakage starts with a timeout,
then some wrong memory frees and finishes in a kernel panic.
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/