Date: Sat, 3 Jul 1999 12:57:00 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: hibma@skylink.it (Nick Hibma) Cc: current@FreeBSD.ORG (FreeBSD CURRENT Mailing list), gibbs@FreeBSD.ORG Subject: Re: panic in dadone, PR 12041 Message-ID: <199907031857.MAA66065@panzer.kdm.org> In-Reply-To: <Pine.BSF.3.96.990703091751.7798A-200000@heidi.plazza.it> from Nick Hibma at "Jul 3, 1999 09:24:39 am"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907031857.MAA66065>