From owner-freebsd-hackers Mon Apr 14 15:09:26 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id PAA18282 for hackers-outgoing; Mon, 14 Apr 1997 15:09:26 -0700 (PDT) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA18277 for ; Mon, 14 Apr 1997 15:09:22 -0700 (PDT) Received: from relay-11.mail.demon.net (relay-11.mail.demon.net [194.217.242.137]) by who.cdrom.com (8.8.5/8.6.11) with SMTP id PAA01109 for ; Mon, 14 Apr 1997 15:09:21 -0700 (PDT) Received: from erlenstar.demon.co.uk ([194.222.144.22]) by relay-10.mail.demon.net id aa1006212; 14 Apr 97 20:38 BST Received: (from andrew@localhost) by erlenstar.demon.co.uk (8.8.5/8.8.5) id UAA00328; Mon, 14 Apr 1997 20:38:10 +0100 (BST) To: hackers@freebsd.org Cc: vmen3237@ss1000.ms.mff.cuni.cz Subject: Re: ahc problems w/ xcdplayer? References: From: Andrew Gierth In-Reply-To: "Vladimir Mencl, MK, susSED"'s message of Mon, 14 Apr 1997 17:14:13 +0200 (MET DST) X-Mayan-Date: Long count = 12.19.4.1.8; tzolkin = 5 Lamat; haab = 6 Pop X-Attribution: AG Date: 14 Apr 1997 20:38:10 +0100 Message-ID: <87d8rx2y59.fsf@erlenstar.demon.co.uk> Lines: 30 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>>> "Vladimir" == Vladimir Mencl, MK, susSED 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.