From owner-freebsd-scsi Mon Aug 12 16:30:27 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC94E37B400 for ; Mon, 12 Aug 2002 16:30:24 -0700 (PDT) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 9736743E3B for ; Mon, 12 Aug 2002 16:30:24 -0700 (PDT) (envelope-from nate@rootlabs.com) Received: (qmail 33540 invoked by uid 1000); 12 Aug 2002 23:30:26 -0000 Date: Mon, 12 Aug 2002 16:30:26 -0700 (PDT) From: Nate Lawson To: Joerg Wunsch Cc: freebsd-scsi@freebsd.org Subject: Re: Tekram DC-395 driver maintenance In-Reply-To: <20020811103649.G39683@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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