Date: Mon, 18 Jan 1999 20:42:29 +0100 From: "Jeroen C. van Gelderen" <gelderen@mediaport.org> To: "Bernd Walter" <ticso@cicely.de>, <freebsd-scsi@FreeBSD.ORG> Cc: "Kenneth D. Merry" <ken@plutotech.com> Subject: Re: Disk dying (Conner CFP and Tagged Queueing Probs) Message-ID: <00d601be431a$af6b2d40$0d79eb0a@deskfix.local>
next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format.
------=_NextPart_000_00D3_01BE4323.10E4D0A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
From: Bernd Walter <ticso@cicely.de>
>> Today I saw these messages scrolling over my screen. The last line
worries
>> me a bit. Is this likely an indicator of a failing disk? Or is there
>> something else wrong?
<snip messages>>
>Looks exactly the same like on my <CONNER CFP1080S 3939> I had
>mentioned in this list earlier.
>You should be very carefully with this problem it damaged me
>sometimes the fs on it.
Yeah. Root and usr were hosed :(
>With a quirk entry disabling tagged command queueing the drive
>is running without any problems for several days.
>
>Sound like there are more than just my drive broken.
>Can someone please check and commit an entry?
>
>I use the following in sys/cam/cam_xpt.c:
> {
> /* Broken tagged queuing drive */
> { T_DIRECT, SIP_MEDIA_FIXED, "CONNER", "CFP*", "*" },
> /*quirks*/0, /*mintags*/0, /*maxtags*/0
> },
>
>Interestingly the following is already there:
> {
> /* Broken tagged queuing drive */
> { T_DIRECT, SIP_MEDIA_REMOVABLE, "CONNER", "CFP2107*",
"*" },
> /*quirks*/0, /*mintags*/0, /*maxtags*/0
> },
Well, I've run -CURRENT with this drive for almost a year now, without any
problems except for one: I had to use the following quirk entry to shut up a
nasty error on shutdown:
==== //depot/cam/sys/cam/scsi/scsi_da.c#89 -
/usr/home/ken/perforce/cam/sys/cam/scsi/scsi_da.c ====
*** /tmp/tmp.29245.0 Thu Nov 5 17:28:11 1998
--- /usr/home/ken/perforce/cam/sys/cam/scsi/scsi_da.c Thu Nov 5 17:27:35
1998
***************
*** 146,151 ****
--- 146,155 ----
*/
{T_DIRECT, SIP_MEDIA_FIXED, "NEC", "D3847*", "*"},
/*quirks*/ DA_Q_NO_SYNC_CACHE
+ },
+ {
+ {T_DIRECT, SIP_MEDIA_FIXED, "CONNER", "CFP4207*", "*"},
+ /*quirks*/ DA_Q_NO_SYNC_CACHE
}
};
I think I might have added a custom maxtags with a value of around 30 to
this patch (to shut up the annoying 'tagged openings now xxx' messages) but
I don't have that kernel source anymore...
Another strange thing can be found in the attached message. Kenneth: you did
never follow up on this one but it might be important anyway.
Cheers,
Jeroen
------=_NextPart_000_00D3_01BE4323.10E4D0A0
Content-Type: message/rfc822;
name="Re .... Illegal request asc20,0 .....eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Re .... Illegal request asc20,0 .....eml"
Received: from mediaport.org ([194.229.42.32])by cal007109.student.utwente.nl with esmtp (Exim 2.05 #1)id 0zbva0-0005dr-00for gelderen@djo.nl; Sat, 7 Nov 1998 00:46:12 +0100
Received: from panzer.plutotech.com (panzer.plutotech.com [206.168.67.125])by mediaport.org (8.8.5/8.8.5/3i-1.0) with ESMTP id AAA12971for <gelderen@mediaport.org>; Sat, 7 Nov 1998 00:44:52 +0100
Received: (from ken@localhost) by panzer.plutotech.com (8.9.1/8.8.5) id QAA03656 for gelderen@mediaport.org; Fri, 6 Nov 1998 16:46:06 -0700 (MST)
From: "Kenneth D. Merry" <ken@plutotech.com>
Message-ID: <199811062346.QAA03656@panzer.plutotech.com>
Subject: Re: .... Illegal request asc:20,0 ....
In-Reply-To: <003a01be0987$eebab140$1400000a@deskfix.local> from "Jeroen C. van Gelderen" at "Nov 6, 98 02:18:23 pm"
To: "Jeroen C. van Gelderen" <gelderen@mediaport.org>
Date: Fri, 6 Nov 1998 16:46:05 -0700 (MST)
X-Mailer: ELM [version 2.4ME+ PL28s (25)]
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Jeroen C. van Gelderen wrote...
> From: Kenneth D. Merry <ken@plutotech.com>
> >*sigh* That is truly perplexing. The attached patch for scsi_da.c should
> >disable the messages.
>
> It fixes them alright. Thanks! Drop me a line if you need more
> testing/patching.
>
> ! if (sense_key != SSD_KEY_ILLEGAL_REQUEST) {
> ! printf("dashutdown: printing error "
> ! "message\n");
> scsi_sense_print(&ccb.csio);
>
> sense_key == 0 in my case...
Are you sure?? That doesn't make any sense... Did you print out the value
or something?
The reason it doesn't make sense is becuase in the subsequent error message,
the sense key is decoded as "ILLEGAL REQUEST", which is 5, not 0.
> >> Another request: my computer keeps complaining about the tagged openings
> >> being adjusted. I know it's a harmless diagnostic, but to have those
> >> messages garble my screen several times a day is very annoying. Those
> >> messages are AFAIK not something important, so at the very least they
> should
> >> not end up on my screen by default...
> >
> >They are important, in a sense. They've helped us find numerous bugs, both
> >in drive firmware, and in the CAM code itself. They also tell you how many
> >transactions your drive can handle at a time.
>
> Ok, but I know how many transactions my drive can handle after the first
> time. I reboot few times a day, so these messages get really annoying. Isn't
> it possible to show them in -v mode only?
Yeah, go to about line 2939 in cam_xpt.c (that's in -current, the line
number in 3.0 release will be different). You'll see an if statement like
this:
if (bootverbose || 1) {
xpt_print_path(crs->ccb_h.path);
printf("tagged openings "
"now %d\n",
crs->openings);
}
Just remove the '|| 1' part and recompile. You'll only see the messages
when you boot with -v.
> >They stop appearing once your drive stops reporting the queue full
> >condition.
>
> I know, but see above... The messages show up on my console (not running X).
Ahh.
Ken
--
Kenneth Merry
ken@plutotech.com
------=_NextPart_000_00D3_01BE4323.10E4D0A0--
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?00d601be431a$af6b2d40$0d79eb0a>