From owner-freebsd-bugs  Tue Mar 14 11:50: 7 2000
Delivered-To: freebsd-bugs@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP id 061A937B742
	for <freebsd-bugs@FreeBSD.org>; Tue, 14 Mar 2000 11:50:05 -0800 (PST)
	(envelope-from gnats@FreeBSD.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id LAA71385;
	Tue, 14 Mar 2000 11:50:04 -0800 (PST)
	(envelope-from gnats@FreeBSD.org)
Received: from jvdbosch.icts.tue.nl (jvdbosch.icts.tue.nl [131.155.200.8])
	by hub.freebsd.org (Postfix) with ESMTP id 1B84D37B5C7
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 14 Mar 2000 11:49:28 -0800 (PST)
	(envelope-from jan@jvdbosch.icts.tue.nl)
Received: (from jan@localhost)
	by jvdbosch.icts.tue.nl (8.9.3/8.9.3) id UAA01066;
	Tue, 14 Mar 2000 20:39:37 +0100 (CET)
	(envelope-from jan)
Message-Id: <200003141939.UAA01066@jvdbosch.icts.tue.nl>
Date: Tue, 14 Mar 2000 20:39:37 +0100 (CET)
From: jan@vandenbosch.org
Reply-To: jan@vandenbosch.org
To: FreeBSD-gnats-submit@freebsd.org
X-Send-Pr-Version: 3.2
Subject: i386/17374: Bug with fix - Archive QIC02 tape-unit device randomly halts.
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


>Number:         17374
>Category:       i386
>Synopsis:       Archive QIC02 tape-unit device randomly halts.
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 14 11:50:02 PST 2000
>Closed-Date:
>Last-Modified:
>Originator:     Jan van den Bosch
>Release:        FreeBSD 3.2-RELEASE i386
>Organization:
Jan van den Bosch (The Netherlands)
>Environment:
i486 PC, 8 MB, QIC02 Archive tapedrive
>Description:

The wt QIC02 tapedriver in thwe FreeBSD 3.x has a nice bug (could be
also in NetBSD and other BSD's ???)
The wt driver sometimes comes in a deadlock state (waiting for an 
wake-up event that never occurs). It may happen when you are doing 
longer backups on - I assume - some "slow" PC's like mine. 
The backup does not finish correctly, it "hangs".
The code is in /sys/i386/isa/wt.c.
The solution is simple. After changing it,
the bug never occurred (to me) again. 

Reason:
In the Interrupt routine wtintr() there is no provision for 
stopping the timeout() if all i/o (one block) is completed
(state 'i/o finished'). If an interrupt is generated at this moment,
it comes in an unexpected state ('continue i/o'). In this state,
there is of course no wakeup, so it keeps sleeping ... 

Patch:
*Allways put the timer off* if i/o is finished.
Add this line in the function body of wtintr(sc):
	untimeout(wtimer, (caddr_t)t, t->co_handler);
See context-diff below.
Remark:
In NetBSD ther is no call-out handler, the patch is even
more simple.

>How-To-Repeat:

Problem shows up every time I was making a longer backup, 
on my old 486 PC system.
(May be on a fast system it does not occure, because it is a timing problem)

>Fix:
    	
>Release-Note:
>Audit-Trail:
>Unformatted:


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message