From owner-freebsd-current Wed Sep 23 07:35:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA05331 for freebsd-current-outgoing; Wed, 23 Sep 1998 07:35:26 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from tim.xenologics.com (tim.xenologics.com [194.77.5.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA05307 for ; Wed, 23 Sep 1998 07:35:09 -0700 (PDT) (envelope-from seggers@semyam.dinoco.de) Received: (from uucp@localhost) by tim.xenologics.com (8.8.5/8.8.8) with UUCP id QAA23744; Wed, 23 Sep 1998 16:21:29 +0200 (MET DST) Received: from semyam.dinoco.de (semyam.dinoco.de [127.0.0.1]) by semyam.dinoco.de (8.9.1/8.8.8) with ESMTP id KAA06752; Wed, 23 Sep 1998 10:13:40 +0200 (CEST) (envelope-from seggers@semyam.dinoco.de) Message-Id: <199809230813.KAA06752@semyam.dinoco.de> To: Michael Class cc: current@FreeBSD.ORG, seggers@semyam.dinoco.de Subject: Re: CAM and quantum disc In-reply-to: Your message of "Tue, 22 Sep 1998 23:03:53 +0200." Date: Wed, 23 Sep 1998 10:13:40 +0200 From: Stefan Eggers Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > (da1:ncr0:0:1:0): tagged openings now 18 > (da1:ncr0:0:1:0): tagged openings now 17 > (da1:ncr0:0:1:0): tagged openings now 16 > > The disk is a "Quantum XP34300W L915". > > I remember that I read about these things before on this list. > Do we need a quirk entry like for the other quantum disks in cam_xpt.c > to restrict the number of tagged queue entries? It looks strange that it drops down one by one as from reading what the -current list said it sounds like it will notice the limit as soon as it exceeds it, issue just one message and then it's done for the rest of the uptime. Am I (with just EIDE disks for now) right about this for the usual behavior of CAM? Are there any ill effects from the drive doing it one by one? Maybe the drive is just a bit slow in answering back for this problem, gets filled with lots of transfer requests from our CAM subsystem and then for each of the requests it can't handle sends an error message back. CAM interprets this one by one and while doing so issues all these messages. Does such a behavior really warrant an entry in the quirks list? If it works perfect otherwise and once stabilized is silent I don't think it's really necessary. One could change CAM to postpone the reporting a little bit and see if it gets even lower in an attempt to combine them to just one message. Stefan. -- Stefan Eggers Lu4 yao2 zhi1 ma3 li4, Max-Slevogt-Str. 1 ri4 jiu3 jian4 ren2 xin1. 51109 Koeln Federal Republic of Germany To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message