On Fri, Sep 03, 1999 at 08:47:54AM +0200, Soren Schmidt ([EMAIL PROTECTED]) wrote:
> > wst_done: wst0: nonrecovered data error
>
> I've seen this problem LOTS of times when using the old wd based
> atapi subsystem. I've never been able to find out why this is
> happening exactly. This was part of the reason I started out
> on the new ATA driver (only in -current now). I've never had
> this problem using the ATA driver, so I'm pretty sure its the
> old driver thats at fault, probably some delicate timing prob.
> Using the new driver I do routine backups every night on
> a couble of servers, not seen a signle problem yet...
Thanks for the help, but I'm afraid I may have to burst your bubble. :-/
Upon your advice I cvsupped to today's -current and built an
appropriate kernel with the new ATA driver. I now get one of the two
following error scenarios (which one is unpredictable, though usually
the former):
Sep 3 22:25:17 bantha /kernel: atapi_error: TAPE_WRITE - MEDIUM ERROR skey=3 asc=31
ascq=00 error=00
Sep 3 22:25:17 bantha /kernel: atapi_error: REZERO_UNIT/TAPE_REWIND - MEDIUM ERROR
skey=3 asc=31 ascq=00 error=00
or
Sep 3 22:34:15 bantha /kernel: atapi_error: TAPE_WRITE - timeout error = 00
Sep 3 22:34:15 bantha /kernel: atapi_transfer: bad command phase
Sep 3 22:34:15 bantha /kernel: ad0: status=51 error=04
Sep 3 22:34:15 bantha /kernel: ad_interrupt: hard error
Sep 3 22:34:32 bantha /kernel: atapi_interrupt: unknown transfer phase 11
Sep 3 22:34:45 bantha /kernel: atapi_error: TAPE_WEOF - timeout error = 00
Sep 3 22:35:15 bantha /kernel: atapi_error: TAPE_WEOF - timeout error = 00
The former simply returns EIO; the latter appears to sleep
uninterruptibly on atprq.
The apparent inconsistency in which happens when supports the
notion that this is, as you say, a subtle timing issue.
In an effort to figure out what was going on, I tried compiling
atapi-all.c and atapi-tape.c with ATAPI_DEBUG set, but this only
caused the kernel to eventually page fault and panic. :-/
Any ideas? I'm quite happy to help debug this one, if you have any
thoughts on where to go with it--I need to get backups working, and
I'd much rather not have to buy a new tape drive or switch OSes...
Dave.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
