From owner-freebsd-scsi Tue Jun 13 7:45: 9 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from front6m.grolier.fr (front6m.grolier.fr [195.36.216.56]) by hub.freebsd.org (Postfix) with ESMTP id E8FF437B795; Tue, 13 Jun 2000 07:44:59 -0700 (PDT) (envelope-from groudier@club-internet.fr) Received: from ppp-159-197.villette.club-internet.fr (ppp-159-197.villette.club-internet.fr [195.36.159.197]) by front6m.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id QAA11902; Tue, 13 Jun 2000 16:44:11 +0200 (MET DST) Date: Tue, 13 Jun 2000 16:21:31 +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=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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