On Wed, Dec 15, 1999 at 20:30:13 +0100, Hellmuth Michaelis wrote:
> >From the keyboard of Hellmuth Michaelis:
> >
> > from time to time (i have no idea how to reproduce it or what causes it) i get
> > the following message on the console of one of my current systems:
> >
> > (da1:ncr0:0:1:0): tagged openings now 31
The reason you're getting these messages is because you're either using a
pre-3.2 version of FreeBSD, or you're booting with -v. From the dmesg
output below, it appears you're booting with -v.
It is nothing to worry about for the most part, just an indication that
your drive has returned queue full and CAM has reduced the number of
outstanding transactions for that drive.
> > The drive causing this is a
> >
> > da1 at ncr0 bus 0 target 1 lun 0
> > da1: <CONNER CFP4207W 4.28GB 1524> Fixed Direct Access SCSI-2 device
> > da1: Serial Number DX91RXG
> > da1: 20.000MB/s transfers (10.000MHz, offset 15, 16bit), Tagged Queueing Enabled
> > da1: 4096MB (8388608 512 byte sectors: 255H 63S/T 522C)
> >
> > on a Tekram:
> >
> > ncr0: <ncr 53c875 fast20 wide scsi> irq 15 at device 8.0 on pci0
> > ncr0: minsync=12, maxsync=137, maxoffs=16, 128 dwords burst, large dma fifo
> > ncr0: single-ended, open drain IRQ driver, using on-chip SRAM
> >
> > Should i be concerned about this ?
>
> Just to follow up on this, i just saw on that device:
>
> (da1:ncr0:0:1:0): tagged openings now 31
> (da1:ncr0:0:1:0): tagged openings now 25
> (da1:ncr0:0:1:0): tagged openings now 2
That's not a good sign. This means that the drive kept returning queue
full, until we reduced the number of transactions to the minimum.
> and then scrolling:
>
> ncr0: queue empty.
> ncr0: queue empty.
> ncr0: queue empty.
> ....
And neither is that. You may want to try Gerard Roudier's sym driver
instead of the stock ncr driver. At least if you have problems with the
sym driver, Gerard will fix them.
> over and over the console screen. The only way to get out of this was to
> reboot.
>
> Now i am concerned :-)
>
> What is happening there ? Is the drive going bad ?
My guess is that your drive is broken for tagged queueing. The Conner
CFP2107 is quirked in the transport layer to disable tagged queueing, and
my guess is that your drive may also have the same sort of problem.
Since we've already established that your drive will return queue full
indefinitely, there are several things for you to try:
- use 'camcontrol negotiate' to disable tagged queueing temporarily on the
drive. See if that helps any.
- Put a quirk entry in the transport layer (sys/cam/cam_xpt.c) and try
putting in lower limit of say 8 tags for your drive. If that doesn't
work, and disabling tags in camcontrol did, just quirk it to disable
tagged queueing.
Anyway, let me know what happens. My guess is that the 4207 is just the 4G
version of the 2107, so they probably have the same sorts of problems. I
would like to see what happens if you use Gerard's sym driver (with tagged
queueing enabled for the drive) as well.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message