Date: Tue, 13 Jun 2000 19:07:18 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr> To: "Bradley T. Hughes" <bhughes@trolltech.com> Cc: freebsd-stable@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Problem with newer sym driver on a Tekram DC-390U2W controller Message-ID: <Pine.LNX.4.10.10006131828280.360-100000@linux.local> In-Reply-To: <Pine.BSF.4.21.0006131803220.202-100000@reticent.troll.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 13 Jun 2000, Bradley T. Hughes wrote:
> On Tue, 13 Jun 2000, Gérard Roudier wrote:
>
> > Hello,
> >
> > Thanks for the report and sorry for the breakage. Unfortunately I haven't
> > any Tekram board and so, risk of device setup breakage is more likely to
> > happen for these boards due to their proprietary NVRAM layout. Tekram use
> > to speak highly of their success under notably Linux and seem to want to
> > provide their own drivers. May-be, for this reason, they never sent me any
> > of their SYM53C8XX based SCSI boards for driver testing.
>
> i tried tekram's drivers, but my machine would reboot itself randomly for
> some odd reason... the sym driver has proven much more stable
Tekram ncr drivers that are available in source form are driving the
SYMBIOS chips in a very sub-optimal way. I don't know about binary-only
drivers from Tekram, but my guess is that they may not be far better. I
donnot want to know why some are highly broken, but even when they seem to
work, using them when an alternate driver is available is probably not a
good idea, in my opinion.
For people using proprietary O/Ses and having Ultra-2 capable Tekram
SYMBIOS based controllers, reflashing the BIOS with the SYMBIOS one can be
tried, given that these boards seem to use SYMBIOS compatible
implementation for NVRAM and FLASH memory. I cannot be 100% sure of this
to work, but if it does, then drivers from SYMBIOS will probably accept to
attach these boards. By the way, if I ever get a Tekram U2[B/W]
controller, I will first try to SYMBIOSIFY it :-) prior to using it.
You may try the above at your own risk (of making the board unusable if
bad luck) or try to get a confirmation from Tekram prior to reflashing the
board. ;-)
> > Well. I have an explanation of the breakage. The table used by the driver
> > to translate the NVRAM sync. tag to sync. factor is probably wrong. The
> > values seem to be rather ((sync. period)/4 in nano-seconds) than true SCSI
> > sync. factors.
> >
> > Here it the offending table:
> >
> > static u_char Tekram_sync[16] =
> > {25,31,37,43, 50,62,75,125, 12,15,18,21, 6,7,9,10};
> >
> > The below preliminar patch should work-around the problem:
> >
> > --- sym_hipd.c.0613 Tue Jun 13 14:58:18 2000
> > +++ sym_hipd.c Tue Jun 13 15:17:54 2000
> > @@ -2960,11 +2960,15 @@
> > sym_nvram_setup_target (np, i, nvram);
> >
> > /*
> > - * For now, guess PPR support from the period.
> > + * For now, guess PPR/DT support from the period
> > + * and BUS width.
> > */
> > - if (tp->tinfo.user.period <= 9) {
> > - tp->tinfo.user.options |= PPR_OPT_DT;
> > - tp->tinfo.user.offset = np->maxoffs_dt;
> > + if (np->features & FE_ULTRA3) {
> > + if (tp->tinfo.user.period <= 9 &&
> > + tp->tinfo.user.width == BUS_16_BIT) {
> > + tp->tinfo.user.options |= PPR_OPT_DT;
> > + tp->tinfo.user.offset = np->maxoffs_dt;
> > + }
> > }
> >
> > if (!tp->usrtags)
> > ----------------------- Cut there ----------------------
>
> after applying this to the 1.6.1 driver from -CURRENT, everything works
> great
Thanks for the quick reply.
I have looked into their driver for FreeBSD-4.0. The sync. table hasn't
changed since the time I stole it :) and their driver actually returns the
values from the table as user settings to CAM. This is obviously wrong.
I intend to commit the patch above for now and let `sym' be as wrong as
Tekram driver on this point, but not more. :-)
Regards,
Gerard.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10006131828280.360-100000>