From owner-freebsd-current Sat Jul 3 11:57:14 1999 Delivered-To: freebsd-current@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id AA0B714F41; Sat, 3 Jul 1999 11:57:04 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id MAA66065; Sat, 3 Jul 1999 12:57:00 -0600 (MDT) (envelope-from ken) Message-Id: <199907031857.MAA66065@panzer.kdm.org> Subject: Re: panic in dadone, PR 12041 In-Reply-To: from Nick Hibma at "Jul 3, 1999 09:24:39 am" To: hibma@skylink.it (Nick Hibma) Date: Sat, 3 Jul 1999 12:57:00 -0600 (MDT) Cc: current@FreeBSD.ORG (FreeBSD CURRENT Mailing list), gibbs@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nick Hibma wrote... > > PR 12041 complains about the fact that the system panics with a divide > by zero if a zip drive is connected with a medium in it. I've not been > able to reproduce the problem, but remember having similar problems > when implementing the umass driver for USB. The problem is caused by the > following line in scsi_da.c:1326 (3.2-STABLE but applies to CURRENT as > well): > > snprintf(announce_buf, sizeof(announce_buf), > "%ldMB (%d %d byte sectors: %dH %dS/T%dC)", > dp->sectors / ((1024L * 1024L) / dp->secsize), > dp->sectors, dp->secsize, dp->heads, > dp->secs_per_track, dp->cylinders); > > secsize is 0 in some cases (I think it happens when an INQUIRY fails > without being detected as having failed). > > In any case a/(b/c) = a*c/b, but without any divl (with b sometimes 0 > and c == 2^20). This is a good idea, but will probably just delay the appearance of the problem. It also shows that the Zip drive has buggy firmware, since it shouldn't return a sector size of 0 without an error. > Index: scsi_da.c > =================================================================== > RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v > retrieving revision 1.19.2.5 > diff -u -r1.19.2.5 scsi_da.c > --- scsi_da.c 1999/05/22 22:58:27 1.19.2.5 > +++ scsi_da.c 1999/07/03 07:24:35 > @@ -1326,7 +1326,7 @@ > dp = &softc->params; > snprintf(announce_buf, sizeof(announce_buf), > "%ldMB (%d %d byte sectors: %dH %dS/T %dC)", > - dp->sectors / ((1024L * 1024L) / dp->secsize), > + dp->secsize * dp->sectors / (1024L * 1024L), > dp->sectors, dp->secsize, dp->heads, > dp->secs_per_track, dp->cylinders); > } else { > What will happen if the drive is reporting a sector size of zero without returning an error is that you'll get into daopen(), and then panic in the slice code. There has been a similar discussion, with the subject "FreeBSD panics with Mylex DAC960SX" on the -scsi list for the past few days. Bruce posted a patch to the slice code to keep it from panicing. In that case, there are some bugs in the CAM error handling code that keep it from returning an error status in cases where the drive returns a sense key, but no ASC/ASCQ. So we'd end up attaching to the drive, but skipping the standard announcement (above), which would have caused a panic. We would get all the way into daopen(), and then panic in the slice code when it attempted to mod by the sector size. In looking at dopen(), I see there are also some (probably minor) problems that will crop up if dsopen() returns an error. Mainly some flags, etc., that don't get cleaned up. You're welcome to check the patch in, but things won't work correctly in that case at least until Bruce checks in his slice fix, or until we start checking for a sector size of 0 in dasetgeom(). Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message