Date: Thu, 18 Mar 2010 09:55:37 -0500 From: <Tom_Chard@Dell.com> To: <freebsd-scsi@freebsd.org> Subject: RE: freebsd-scsi Digest, Vol 360, Issue 2 Message-ID: <2F96965A484FC042AA2B4C174D18876B012F2BE4@ausx3mpc127.aus.amer.dell.com> In-Reply-To: <20100318120021.975DD1065717@hub.freebsd.org> References: <20100318120021.975DD1065717@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Un fucking subscribe Unsubscribe Fucking unsubscribe -----Original Message----- From: owner-freebsd-scsi@freebsd.org [mailto:owner-freebsd-scsi@freebsd.org] On Behalf Of freebsd-scsi-request@freebsd.org Sent: Thursday, March 18, 2010 5:00 AM To: freebsd-scsi@freebsd.org Subject: freebsd-scsi Digest, Vol 360, Issue 2 Send freebsd-scsi mailing list submissions to freebsd-scsi@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-scsi or, via email, send a message with subject or body 'help' to freebsd-scsi-request@freebsd.org You can reach the person managing the list at freebsd-scsi-owner@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-scsi digest..." Today's Topics: 1. Re: pass(4): always retry CAM_REQUEUE_REQ ccbs (Kenneth D. Merry) 2. Re: pass(4): always retry CAM_REQUEUE_REQ ccbs (Andriy Gapon) 3. problems with mfi/DELL Perc6? (Daniel Braniss) ---------------------------------------------------------------------- Message: 1 Date: Wed, 17 Mar 2010 11:28:47 -0600 From: "Kenneth D. Merry" <ken@kdm.org> Subject: Re: pass(4): always retry CAM_REQUEUE_REQ ccbs To: Andriy Gapon <avg@icyb.net.ua> Cc: freebsd-scsi@freebsd.org Message-ID: <20100317172847.GA15531@nargothrond.kdm.org> Content-Type: text/plain; charset=3Dus-ascii On Wed, Mar 10, 2010 at 13:24:37 +0200, Andriy Gapon wrote: >=20 > At present pass(4) never retries a request (or performs any other kind of error > recovery) unless the request has CAM_PASS_ERR_RECOVER flag set. > This gives applications a control over error checking and handling. > But I think that in the case of CAM_REQUEUE_REQ status error recovery, > specifically a request retry, should always be performed. >=20 > Rationale: > CAM_REQUEUE_REQ is really an internal flag/state in CAM subsystem. > It doesn't convey any information about state of medium, device, bus, controller > or the ccb itself. Application can not make any meaningful differentiation > based on this status. It either should always retry a ccb with this status or > face truly random failures. As such, I haven't encountered so far any > application that expects to get CAM_REQUEUE_REQ status. > So I think that CAM_REQUEUE_REQ should be contained within the CAM and never be > leaked to applications unless retry count is exhausted (to prevent endless loops > in case of programming errors, primarily). >=20 > What do you think? > Do you see any reason not to do it? Is there a particular case you're running into where CAM_REQUEUE_REQ is getting returned? I think it's better to keep the model as-is, to avoid confusion. Either the application is handling errors, and it can get any CAM status value, or it is asking the pass(4) driver to do error recovery and it doesn't have to handle things until error recovery is done and retries are exhausted. If we've got a SIM driver that is returning CAM_REQUEUE_REQ when it shouldn't, we should probably look at that. Retries can get used up for various target-related reasons, like unit attention conditions, and we don't want to use CAM_REQUEUE_REQ when it isn't really needed. Ken --=20 Kenneth Merry ken@kdm.org ------------------------------ Message: 2 Date: Wed, 17 Mar 2010 20:00:13 +0200 From: Andriy Gapon <avg@icyb.net.ua> Subject: Re: pass(4): always retry CAM_REQUEUE_REQ ccbs To: "Kenneth D. Merry" <ken@kdm.org> Cc: freebsd-scsi@freebsd.org Message-ID: <4BA118AD.6050102@icyb.net.ua> Content-Type: text/plain; charset=3DISO-8859-1 on 17/03/2010 19:28 Kenneth D. Merry said the following: > On Wed, Mar 10, 2010 at 13:24:37 +0200, Andriy Gapon wrote: >> At present pass(4) never retries a request (or performs any other kind of error >> recovery) unless the request has CAM_PASS_ERR_RECOVER flag set. >> This gives applications a control over error checking and handling. >> But I think that in the case of CAM_REQUEUE_REQ status error recovery, >> specifically a request retry, should always be performed. >> >> Rationale: >> CAM_REQUEUE_REQ is really an internal flag/state in CAM subsystem. >> It doesn't convey any information about state of medium, device, bus, controller >> or the ccb itself. Application can not make any meaningful differentiation >> based on this status. It either should always retry a ccb with this status or >> face truly random failures. As such, I haven't encountered so far any >> application that expects to get CAM_REQUEUE_REQ status. >> So I think that CAM_REQUEUE_REQ should be contained within the CAM and never be >> leaked to applications unless retry count is exhausted (to prevent endless loops >> in case of programming errors, primarily). >> >> What do you think? >> Do you see any reason not to do it? >=20 > Is there a particular case you're running into where CAM_REQUEUE_REQ is > getting returned? Yes, access to ATAPI devices with ahci(4). > I think it's better to keep the model as-is, to avoid confusion. Either > the application is handling errors, and it can get any CAM status value, or > it is asking the pass(4) driver to do error recovery and it doesn't have to > handle things until error recovery is done and retries are exhausted. I've had a chat with Justin Gibbs and he is of the same opinion. His explanation makes sense to me. I didn't look beyond 'for home use' applications when I came up with the suggestion. So, I think that we'd better teach affected applications about CAM_REQUEUE_REQ. > If we've got a SIM driver that is returning CAM_REQUEUE_REQ when it > shouldn't, we should probably look at that. Retries can get used up for > various target-related reasons, like unit attention conditions, and we > don't want to use CAM_REQUEUE_REQ when it isn't really needed. I guess that this would be ideal. I think that it is an implementation detail in ahci(4) that some commands may get CAM_REQUEUE_REQ status. But I am not sure if there is an easy way to fix that given the general logic in that driver. --=20 Andriy Gapon ------------------------------ Message: 3 Date: Thu, 18 Mar 2010 10:59:43 +0200 From: Daniel Braniss <danny@cs.huji.ac.il> Subject: problems with mfi/DELL Perc6? To: freebsd-scsi@freebsd.org Message-ID: <E1NsBZv-000PH9-MK@kabab.cs.huji.ac.il> Content-Type: text/plain; charset=3Dus-ascii hi, we keep seeing these timeouts when there is heavy writes to the mfi: ... mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6564 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6594 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6624 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6654 SECONDS mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6684 SECONDS mfi1: COMMAND 0xffffff80009ce498 TIMEOUT AFTER 35 SECONDS mfi1: COMMAND 0xffffff80009ce9e8 TIMEOUT AFTER 37 SECONDS mfi1: COMMAND 0xffffff80009cec08 TIMEOUT AFTER 38 SECONDS mfi1: COMMAND 0xffffff80009cc3a8 TIMEOUT AFTER 47 SECONDS mfi1: COMMAND 0xffffff80009ceda0 TIMEOUT AFTER 31 SECONDS mfi1: COMMAND 0xffffff80009ce9e8 TIMEOUT AFTER 46 SECONDS mfi1: COMMAND 0xffffff80009cda80 TIMEOUT AFTER 55 SECONDS ... mfi1: COMMAND 0xffffff80009cd0f0 TIMEOUT AFTER 6624 SECONDS the card is: mfi1: <Dell PERC 6> port 0xec00-0xecff mem 0xdf280000-0xdf2bffff,0xdf2c0000-0xd f2fffff irq 38 at device 0.0 on pci6 mfi1: Megaraid SAS driver Ver 3.00=20 any idea what the message means? thanks, danny ------------------------------ _______________________________________________ freebsd-scsi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-scsi To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" End of freebsd-scsi Digest, Vol 360, Issue 2 ********************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2F96965A484FC042AA2B4C174D18876B012F2BE4>