Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Jun 2000 16:21:31 +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.10006131529260.213-100000@linux.local>
In-Reply-To: <Pine.BSF.4.21.0006101956070.89051-300000@reticent.troll.no>

next in thread | previous in thread | raw e-mail | index | archive | help

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.

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 ----------------------

Note that the driver was probably trusting too much the NVRAM content. :)
The code should have been more careful.
I will prepare and commit a complete fix very soon.

On Sat, 10 Jun 2000, Bradley T. Hughes wrote:

> My system at work has on of the mentioned controllers, which uses a
> Symbios 53C895 chip.
> 
> I installed FreeBSD 4.0-RELEASE on the machine when I got the box, and was
> happy to see that da0 reported 40mb/s transfer rates.
> 
> Soon after I cvsup'ed to -STABLE, which had an updated sym driver (1.5.3
> from May 06), and my disk performance dropped dramatically.  Upon
> investigation, I noticed that da0 was reporting only 6.6mb/s transfer
> rates.
> 
> I began looking through mailing list archives and have found no posts even
> resembling the problem that I have... so I decided to try something.  I
> found sym driver 1.3.2, dropped it into /usr/src/sys/dev/sym and
> recompiled my kernel.  Upon reboot, da0 reported 40mb/s xfer rates and my
> disk performance came back to "normal" (read: what i was getting after
> setting upthe machine)
> 
> I repeated this process for sym driver versions 1.4.1 and 1.5.0, both of
> which work beautifully.  But driver 1.5.3 does not, and driver 1.6.1 from
> -CURRENT does not.
> 
> Is there something I could add to my kernel config to get the original
> performance out of the current driver in -STABLE?
> 
> I have attached a few dmesg logs, and will gladly provide other
> information if necessary.

If you have time for doing the following tests, this would allow me to fix
correctly the Tekram NVRAM sync. table:

1) Use latest sym-1.6.1 driver (for 4.0 just steal driver files from
   -current)
   (You may patch it prior to do the tests, but it is not required)

2) Edit sym_hipd.c and add the following 'define' at the beginning of
   the source: 
   #define	SYM_CONF_DEBUG_NVRAM
   (Or add -DSYM_CONF_DEBUG_NVRAM to the compilation options)

3) Starting with 20 Mega-transfers per second until maximum possible, try
   successivelly several sync. speeds (all values if only the 4 possible
   discrete values are allowed) from the NVRAM and send me the driver boot
   messages. If you have several SCSI devices, using different values for
   each device can cover the sync. value range in a fiew runs.

Thanks in advance,

Regards,
   Gerard.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" 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.10006131529260.213-100000>