Date: Mon, 12 Aug 2002 16:30:26 -0700 (PDT) From: Nate Lawson <nate@root.org> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: freebsd-scsi@freebsd.org Subject: Re: Tekram DC-395 driver maintenance Message-ID: <Pine.BSF.4.21.0208121621450.33537-100000@root.org> In-Reply-To: <20020811103649.G39683@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 11 Aug 2002, Joerg Wunsch wrote:
> In the course of investigating his problems, i eventually found out
> that there was one serious bug in that driver: upon detecting a CHECK
> CONDITION, they didn't set the appropriate CAM error flag
> (CAM_SCSI_STATUS_ERROR), so the CAM layer never bothered to handle the
> error at all. This was non-fatal as long as the attached devices
> never issued a CHECK CONDITION :), but naturally, even a missing MO
> medium at initialisation time caused the upper layers to assume the
> device were ready, and they started to interpret garbage data as valid
> numbers, which eventually would lead to an integer divide by zero
> fault in the geometry calculation.
I was able to get the fault once also but have not seemed to be able to
duplicate it. Were you able to track down where xpt failed to catch
the zero? These lines in cam_xpt.c are supposed to catch that error:
----
case XPT_CALC_GEOMETRY:
{
struct cam_sim *sim;
/* Filter out garbage */
if (start_ccb->ccg.block_size == 0
|| start_ccb->ccg.volume_size == 0) {
start_ccb->ccg.cylinders = 0;
start_ccb->ccg.heads = 0;
start_ccb->ccg.secs_per_track = 0;
start_ccb->ccb_h.status = CAM_REQ_CMP;
break;
}
----
> I did a few other minor changes, like renaming the driver from the
> overly long "tekram_trm" to just "trm". Still, the code looks a bit
> strange to us (Hungarian notation, 4-position hard tabs) since it's
> just vendor-supplied code. Would anybody have strong objections for
> me to import the code into our tree, under the promise that i could
> keep track of future vendor submissions? I guess there's no room on
> the bootfloppy to include it by default, but maybe we could arrange
> for a third bootfloppy containing loadable modules some day, so that
> would extend the list of supported controllers.
I don't have a problem with importing it but I defer to someone who's been
around longer. I'm guessing it should go in sys/contrib/dev to ease
style(9) and import impact.
-Nate
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?Pine.BSF.4.21.0208121621450.33537-100000>