From owner-freebsd-stable Tue Jun 13 10:30:53 2000 Delivered-To: freebsd-stable@freebsd.org Received: from front2m.grolier.fr (front2m.grolier.fr [195.36.216.52]) by hub.freebsd.org (Postfix) with ESMTP id D615537B649; Tue, 13 Jun 2000 10:30:34 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from ppp-108-3.villette.club-internet.fr (ppp-108-3.villette.club-internet.fr [194.158.108.3]) by front2m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id TAA10848; Tue, 13 Jun 2000 19:30:27 +0200 (MET DST) Date: Tue, 13 Jun 2000 19:07:18 +0200 (CEST) From: =?ISO-8859-1?Q?G=E9rard_Roudier?= X-Sender: groudier@linux.local To: "Bradley T. Hughes" Cc: freebsd-stable@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Problem with newer sym driver on a Tekram DC-390U2W controller In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Jun 2000, Bradley T. Hughes wrote: > On Tue, 13 Jun 2000, G=E9rard Roudier wrote: >=20 > > Hello, > >=20 > > 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 t= o > > happen for these boards due to their proprietary NVRAM layout. Tekram u= se > > to speak highly of their success under notably Linux and seem to want t= o > > provide their own drivers. May-be, for this reason, they never sent me = any > > of their SYM53C8XX based SCSI boards for driver testing. >=20 > 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 driv= er > > 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 S= CSI > > sync. factors. > >=20 > > Here it the offending table: > >=20 > > static u_char Tekram_sync[16] =3D > > =09{25,31,37,43, 50,62,75,125, 12,15,18,21, 6,7,9,10}; > >=20 > > The below preliminar patch should work-around the problem: > >=20 > > --- sym_hipd.c.0613=09Tue Jun 13 14:58:18 2000 > > +++ sym_hipd.c=09Tue Jun 13 15:17:54 2000 > > @@ -2960,11 +2960,15 @@ > > =09=09sym_nvram_setup_target (np, i, nvram); > > =20 > > =09=09/* > > -=09=09 * For now, guess PPR support from the period. > > +=09=09 * For now, guess PPR/DT support from the period=20 > > +=09=09 * and BUS width. > > =09=09 */ > > -=09=09if (tp->tinfo.user.period <=3D 9) { > > -=09=09=09tp->tinfo.user.options |=3D PPR_OPT_DT; > > -=09=09=09tp->tinfo.user.offset =3D np->maxoffs_dt; > > +=09=09if (np->features & FE_ULTRA3) { > > +=09=09=09if (tp->tinfo.user.period <=3D 9=09&& > > +=09=09=09 tp->tinfo.user.width =3D=3D BUS_16_BIT) { > > +=09=09=09=09tp->tinfo.user.options |=3D PPR_OPT_DT; > > +=09=09=09=09tp->tinfo.user.offset =3D np->maxoffs_dt; > > +=09=09=09} > > =09=09} > > =20 > > =09=09if (!tp->usrtags) > > ----------------------- Cut there ---------------------- >=20 > 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=20 Tekram driver on this point, but not more. :-) Regards, Gerard. =20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message