Date: Tue, 18 Jul 1995 12:24:43 -0700 From: "& freefall.cdrom.com" <root@freefall.cdrom.com> To: mikebo@tellabs.com (Mike Borowiec) Cc: bugs@freebsd.org Subject: Re: FBSD v2.0.5R: AHA2742AT + Exabyte scrogged my root disk! Message-ID: <199507181924.MAA08369@freefall.cdrom.com> In-Reply-To: Your message of "Tue, 18 Jul 95 11:48:59 CDT." <m0sYFpQ-000jBcC@tellab5.lisle.tellabs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Greetings -
>I'm truly amazed with the work done by the FreeBSD team, but today I'm
>an unhappy camper...
>
>After putting the finishing touches on my 2.0.5 configuration, I tried
>to load the 2.0.5 distribution tree from an Exabyte 8200 tape to disk.
>During the tar extract, I got the following messages repeatedly:
>
> st1: oops not queued
> biodone: buffer already done
> tar: read error on /dev/rst1: Input/output error
> ahc0: target 0, lun 0 (sd0) timed out
>
>Whenever I access the Exabyte, the root drive seems to be completely
>inaccessible. The tar extract finally failed, but I subsequently found
>that my root disk was completely trashed, chock full of corruption! To
>recover I had to run fsck several times and allow it to remove several
>dozen critical programs and configuration files. ARGH!
This was fixed recently in -current. If you have kernel source, the
patch is simple. I've appended it to this message.
>Ever since moving to this Adaptec 2742AT, I've had nothing but trouble
>with FreeBSD. I'm seriously considering dumping the card and going back
>to my reliable old 1542B... EISA system board or no, I need stability and
>the use of both my tape drives (Exabyte 8200 and Archive Viper QIC150),
>both of which worked flawlessly with the 1542, both of which are utterly
>useless with the 2742AT and FreeBSD 2.0.5R.
It was actually a SCSI system bug that hit the 2742 particuallarly hard
because of the way it allocates per command resources.
>I've written to this list before and most of the time I get tremendous
>support - but this AIC7xxx driver/tape drive problem is another matter.
>This is just the latest catastrophy in the AIC7xxx vs. st() problems.
>I don't want to start a AIC7xxx vs. st() finger-pointing war - I just
>want this to work without trashing my system.
Try the patch and get back to me. As the author of the driver and the
proud new owner of a tape drive, you should see rapid progress on these
problems.
>I humbly suggest that more priority be placed on debugging this before
>2.1R is released... I'm more than happy to spend hours to provide all
>the information regarding my machine/OS configuration, provided someone
>is willing to take a serious look into it...
Already being done. Between the aic7xxx driver and the SCSI system as a
whole, all of my free time is already allocated.
>
>Regards,
>- Mike
--
Justin T. Gibbs
===========================================
Software Developer - Walnut Creek CDROM
FreeBSD: Turning PCs into workstations
===========================================
Index: st.c
===================================================================
RCS file: /home/ncvs/src/sys/scsi/st.c,v
retrieving revision 1.37
diff -c -r1.37 st.c
*** 1.37 1995/07/09 08:14:24
--- st.c 1995/07/16 09:13:14
***************
*** 12,18 ****
* on the understanding that TFS is not responsible for the correct
* functioning of this software in any circumstances.
*
! * $Id: st.c,v 1.37 1995/07/09 08:14:24 joerg Exp $
*/
/*
--- 12,18 ----
* on the understanding that TFS is not responsible for the correct
* functioning of this software in any circumstances.
*
! * $Id: st.c,v 1.38 1995/07/16 09:13:14 gibbs Exp $
*/
/*
***************
*** 1102,1108 ****
0, /* can't retry a read on a tape really */
100000,
bp,
! flags | SCSI_NOSLEEP) == SUCCESSFULLY_QUEUED) {
stqueues++;
} else {
badnews:
--- 1102,1108 ----
0, /* can't retry a read on a tape really */
100000,
bp,
! flags) == SUCCESSFULLY_QUEUED) {
stqueues++;
} else {
badnews:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507181924.MAA08369>