Date: Sat, 28 Apr 2001 23:12:27 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Another problem with the new CAM error handling Message-ID: <20010428231227.A37369@panzer.kdm.org> In-Reply-To: <20010426190714.E50185@uriah.heep.sax.de>; from j@uriah.heep.sax.de on Thu, Apr 26, 2001 at 07:07:14PM %2B0200 References: <20010426110542.A50185@uriah.heep.sax.de> <200104261435.f3QEZLs23573@aslan.scsiguy.com> <20010426190714.E50185@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 26, 2001 at 19:07:14 +0200, J Wunsch wrote: > As Justin T. Gibbs wrote: > > >I thought a UA condition would always be retried? In particular, > > >it should never end up in an `invalidating device' message. > > > > The peripheral driver must specify that the UA condition should > > be retried in its call to cam_periph_error(). The pt driver must > > not do that. The new error recovery code isn't responsible for > > this error. > > Hmm, but it used to work with the old CAM error handling code. ;-) > > Anyway, looking at the pt driver, it seems to go length to handle > SF_RETRY_UA, differentiating various cases. I think it would already > properly ignore it after a bus reset or bus device reset. In my case > however, it's a UA after a device power-on. IMHO that's the only > possibility for an UA that has been left out, so why bother and not > always ignore them? It looks like the semantics of unit attention handling have changed with the new error recovery code, and that has exposed the way the pt(4) driver handles unit attentions. The old code retried unit attentions unconditionally without decrementing the retry count if SF_RETRY_UA was set. If SF_RETRY_UA wasn't set, it would still retry unit attentions, but would decrement the retry count. The pt(4) driver would have been hitting the second case in the old code. The new code only retries unit attentions if SF_RETRY_UA is set, and it decrements the retry count. I think that's probably the right thing to do, so peripheral drivers can control whether unit attentions are fatal or not. Decrementing the retry count insures that we won't get stuck in an infinite loop with a broken device that continually returns unit attention. Since SF_RETRY_UA isn't set on normal I/O for the pt(4) driver unless a bus reset or BDR has been sent, unit attentions are not being retried. The attached patch should fix your problem. > The other thing that is annoying is that, after the `invalidating > device', it takes another power-off, camcontrol rescan, power-on, and > camcontrol rescan cycle in order to revive the device, since even a > simple rescan leaves the device invalidated. IMHO, there should at > least be a `camcontrol forget' option to completely abandon a device > without the need to power it off, and rescan the bus. A better name might be 'camcontrol detach'. You're right, such an option might help with reviving dead peripherals. Hopefully we can make things robust enough so that a peripheral isn't declared "dead" unless it really is dead. Ken -- Kenneth Merry ken@kdm.org --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="scsi_pt.c.20010428" ==== //depot/FreeBSD-ken/src/sys/cam/scsi/scsi_pt.c#11 - /usr/home/ken/perforce/FreeBSD-ken/src/sys/cam/scsi/scsi_pt.c ==== *** /tmp/tmp.50926.0 Sat Apr 28 22:48:07 2001 --- /usr/home/ken/perforce/FreeBSD-ken/src/sys/cam/scsi/scsi_pt.c Sat Apr 28 22:47:34 2001 *************** *** 544,550 **** /*sense_len*/SSD_FULL_SIZE, /*timeout*/softc->io_timeout); ! start_ccb->ccb_h.ccb_state = PT_CCB_BUFFER_IO; /* * Block out any asyncronous callbacks --- 544,550 ---- /*sense_len*/SSD_FULL_SIZE, /*timeout*/softc->io_timeout); ! start_ccb->ccb_h.ccb_state = PT_CCB_BUFFER_IO_UA; /* * Block out any asyncronous callbacks --0F1p//8PRICkK4MW-- 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?20010428231227.A37369>