Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Dec 1998 11:21:47 +0000
From:      Geoff Buckingham <geoffb@gti.noc.demon.net>
To:        Harry Starr <starr3@gccs.com.au>, current <freebsd-current@FreeBSD.ORG>
Subject:   Re: Problems with CAM and ncr
Message-ID:  <19981223112147.B5215@gti.noc.demon.net>
In-Reply-To: <001501be2da8$fb35b830$0a9811cb@gccs.com.au>; from Harry Starr on Tue, Dec 22, 1998 at 10:45:38PM %2B1000
References:  <001501be2da8$fb35b830$0a9811cb@gccs.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 22, 1998 at 10:45:38PM +1000, Harry Starr wrote:
> There seems to be a major problem with the new CAM code and the ncr driver.
> 
> Config:
> 
> Asus SC200 (ncr810) in Asus P2L97 M/B with PII-300 and 128MB mem.
> 
> With "hard" disk access (Make world; or Make release), more than likely, the
> ncr driver will give an error message of ncr:::queue empty, at which point
> the system will lock up (pager errors, etc). This is almost 100%
> reproducible.
> 
> The SCSI drives are "old" Conner Cp3470. I'm not sure if there were problems
> with tagged queueing in this model; but they worked OK in a DG/UX system.
> 
Someone more knowledgable than me will doubtless be along in a bit, but
I have had the NCR driver working with CAM for build world etc without
problems however that machine has a 'modern' drive.

You may be able to eliminate TAG problems by adding a quirk to
/usr/src/sys/cam/cam_xpt.c specifying a lower maxtags, then compiling 
a new kernel. I have one for a hardware RAID which was causing hangs:

        {
                /* Delf Stuff */
                {
                  T_ANY, SIP_MEDIA_REMOVABLE|SIP_MEDIA_FIXED,
                  /*vendor*/"C_Design", /*product*/"DELFRaid", /*revision*/"0131
"
                },
                /*quirks*/0, /*mintags*/24, /*maxtags*/28
        },

This seems to have fixed it (one week uptime, was crashing within 30 mins of
disk load)

If someone from the CAM group happens along: Is there a methed for submision
and review of such quirks? I have raised a non critical kernel PR for the
above, although I must revise it as I have altered min/maxtags since
submiting it.

There is no scientific method for the values chosen above, they just
seem to prevent the hangs and excesivly uneven distribution of TAGs
between logical devices within the RAID.

> The ncr driver previously reports that "tagged openings is now 31".
> 
> Reverting to a kernel dated "8-Aug-1998" alleviates the problem.
> 
> Any thoughts ??
> 
-- 
GeoffB

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981223112147.B5215>