Date: Thu, 11 Apr 2002 15:44:24 +0200 From: "Nick Hibma" <n_hibma@van-laarhoven.org> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: "Thomas Quinot" <thomas@cuivre.fr.eu.org>, "freebsd-scsi@freebsd.org" <freebsd-scsi@FreeBSD.ORG> Subject: Re: xpt_bus_deregister Message-ID: <004501c1e15e$fdbbc000$7800420a@vanlaarhoven.org> References: <200204111316.g3BDG8939967@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> This depends on how the device is lost. Layers above the SIM > can decide when a device is considered lost based on the types > of status your SIM reports. For example, in parallel SCSI, > a single selection timeout may not indicate that the device is > lost, but several in a row may. The SIM cannot just assume the > device is lost after a single selection timeout. > > Many drivers use this event to reset their negotiation table so > that they will renegotiate the next time the system attempts to > talk to the "lost device". This can happen in hot-plug situations. I presume that with this you are trying to say that AC_LOST_DEVICE could come from different sources, outside the SIM and the SIM might want to reset is internal state on the device. I understand that. But in the case of the ATAPI/CAM layer he wants to use it to detach the SIM. That sounds a bit odd to me because the only sources of a SIM disconnect I can think of are: - hardware, e.g. disconnection of PCMCIA card - unloading of the driver And in both cases the driver that created the SIM initiates the removal of the SIM. Nick 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?004501c1e15e$fdbbc000$7800420a>