Date: Sat, 28 Apr 2001 21:03:59 +0200 From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-scsi@FreeBSD.ORG Subject: Re: sa(4) jamming Message-ID: <20010428210359.Q50185@uriah.heep.sax.de> In-Reply-To: <200104271700.f3RH01s35435@aslan.scsiguy.com>; from gibbs@scsiguy.com on Fri, Apr 27, 2001 at 11:00:01AM -0600 References: <200104271649.f3RGmts35017@aslan.scsiguy.com> <200104271700.f3RH01s35435@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As Justin T. Gibbs wrote: > >That depends on whether the sa driver relies on any settings (mode > >page or otherwise) that are invalidated by a reset, but aren't > >restored when the bus reset async event occurs. > > Just to be more clear here, it is the peripheral driver's responsibility > to restore any of this state if it needs to. I don't doubt this. It only surprises me how many driver bugs have been unobscured by the CAM error handling reorg. All those things (sa driver ILI handling, pt driver invalidating the device after a power-on UA, sa driver running into obscure problems after a bus reset without reloading the tape) didn't happen with earlier versions of the CAM subsystem. Please get me right, i don't want to grumble about CAM here, but i'd like to see bugs fixed as they become obvious in -current, and the first step is always to make sure where the bug actually is. Also Justin, you still didn't respond whether the patch for the `NO SENSE' handling i posted i what you were referring to. Right now, cam_periph_error() effectively returns ERESTART in that case. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) 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?20010428210359.Q50185>