From owner-freebsd-hackers  Mon Apr 14 20:50:43 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id UAA11686
          for hackers-outgoing; Mon, 14 Apr 1997 20:50:43 -0700 (PDT)
Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id UAA11679
          for <hackers@freebsd.org>; Mon, 14 Apr 1997 20:50:40 -0700 (PDT)
Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02)
	id AA01548; Mon, 14 Apr 1997 23:50:06 -0400
Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Mon, 14 Apr 1997 23:50 EDT
Received: from lakes.water.net (lakes [10.0.0.3]) by ponds.water.net (8.8.3/8.7.3) with ESMTP id UAA28554; Mon, 14 Apr 1997 20:41:19 -0400 (EDT)
Received: (from rivers@localhost) by lakes.water.net (8.8.3/8.6.9) id UAA28404; Mon, 14 Apr 1997 20:47:47 -0400 (EDT)
Date: Mon, 14 Apr 1997 20:47:47 -0400 (EDT)
From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com>
Message-Id: <199704150047.UAA28404@lakes.water.net>
To: ponds!erlenstar.demon.co.uk!andrew, ponds!freebsd.org!hackers
Subject: Re: ahc problems w/ xcdplayer?
Cc: ponds!ss1000.ms.mff.cuni.cz!vmen3237
Content-Type: text
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Andrew Gierth writes:
> >>>>> "Vladimir" == Vladimir Mencl, MK, susSED <vmen3237@ss1000.ms.mff.cuni.cz> 
> writes:
> 
>  > On 14 Apr 1997, Andrew Gierth wrote:
>  >> Selecting "play" on xcdplayer for the *second* time locks the machine 
>  >> dead. Before it dies, though, it emits these messages:
> 
>  Vladimir> I've the exactly same problem. I thought that it could be
>  Vladimir> because of an too weak power supply (I've 3 harddisks, 2
>  Vladimir> floppy drives, a tapedrive and a SCSI cd), but it seems
>  Vladimir> that it's something in the drivers...
> 
> I think I've sorted it.
> 
> The core problem seems to be timeouts in scsi/cd.c that are too short. The
> msfplay command was being issued, but timing out; the ahc driver in 2.2.1R
> then ties itself in knots and dies....
> 
> (As near as I can tell, on my hardware the command is taking very close to
> 2s to complete, and the timeout is 2s. This seems to confuse the heck out
> of the driver....)
> 
> The problem doesn't happen with "play" because the timeout for that is 
> longer (20s).
> 
> My solution for now is to change "2000" to "20000" in the call to
> scsi_scsi_cmd in cd_play_msf (sys/scsi/cd.c). Seems ok now.
> 
> -- 
> Andrew.

 I'm glad to hear that worked for you.

 When I made the same supposition about my tape drive (which presents
the same symptoms) I was wrong... in testing it (changing timeouts
in st.c to *very* large numbers) it continued to demonstrate the
"tieing itself in knots" syndrome.

	- Dave Rivers -