Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Jan 1999 16:40:01 -0800 (PST)
From:      "Kenneth D. Merry" <ken@plutotech.com>
To:        freebsd-bugs@FreeBSD.ORG
Subject:   Re: kern/9354: [PATCH] CAM driver spews debug messages
Message-ID:  <199901070040.QAA19072@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/9354; it has been noted by GNATS.

From: "Kenneth D. Merry" <ken@plutotech.com>
To: naddy@bigeye.rhein-neckar.de
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/9354: [PATCH] CAM driver spews debug messages
Date: Wed, 6 Jan 1999 17:38:04 -0700 (MST)

 Christian Weisgerber wrote...
 > 
 > >Number:         9354
 > >Category:       kern
 > >Synopsis:       [PATCH] CAM driver spews debug messages
 > >Confidential:   no
 > >Severity:       non-critical
 > >Priority:       medium
 > >Responsible:    freebsd-bugs
 > >State:          open
 > >Quarter:        
 > >Keywords:       
 > >Date-Required:
 > >Class:          change-request
 > >Submitter-Id:   current-users
 > >Arrival-Date:   Wed Jan  6 15:20:01 PST 1999
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Christian Weisgerber
 > >Release:        FreeBSD 3.0-CURRENT i386
 > >Organization:
 > >Environment:
 > 
 > Asus SC200 (NCR53C810) SCSI adapter, Quantum XP32275S LXY4 disk.
 > 
 > >Description:
 > 
 > The kernel keeps spewing annoying debugging messages along the lines of
 > 
 > (da0:ncr0:0:0:0): tagged openings now 31
 > (da0:ncr0:0:0:0): tagged openings now 29
 > (da0:ncr0:0:0:0): tagged openings now 28
 > 
 > Apparently there is a snippet of debugging code left in
 > /sys/cam/cam_xpt.c.
 > 
 > >How-To-Repeat:
 > 
 > Heavy disk activity, e.g. cvsup'ing /usr/src, make world,
 > rm -r /usr/obj, etc.
 
 This is a feature, not a bug.  We left the messages in there because they
 often expose drive firmware bugs, and sometimes expose CAM bugs.  As a side
 effect, it also tells you how many concurrent transactions your drive can
 handle.
 
 Your particular drive (Quantum Atlas II with LXY4 firmware) is known to
 have buggy firmware.  It will work okay, but under high load, it will "go
 out to lunch" and not come back on the bus.  Generally, the Adaptec driver
 sends a BDR to the device to wake it up, I'm not sure what the NCR driver
 does.
 
 If you can, I suggest you upgrade to the LYK8 firmware revision for your
 drive.  It will not prevent the drive from interminably returning queue
 full, but it will solve the "drive goes out to lunch" problem that you may
 see under high load.
 
 Ken
 -- 
 Kenneth Merry
 ken@plutotech.com

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



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