From owner-freebsd-questions@FreeBSD.ORG Mon Jul 20 02:15:13 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFE2610656B4 for ; Mon, 20 Jul 2009 02:15:13 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) by mx1.freebsd.org (Postfix) with ESMTP id 8C4A28FC26 for ; Mon, 20 Jul 2009 02:15:13 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r55.edvax.de (port-92-195-64-14.dynamic.qsc.de [92.195.64.14]) by mx01.qsc.de (Postfix) with ESMTP id 04D083CBD3; Mon, 20 Jul 2009 04:15:11 +0200 (CEST) Received: from r55.edvax.de (localhost [127.0.0.1]) by r55.edvax.de (8.14.2/8.14.2) with SMTP id n6K2F6F8001557; Mon, 20 Jul 2009 04:15:06 +0200 (CEST) (envelope-from freebsd@edvax.de) Date: Mon, 20 Jul 2009 04:15:06 +0200 From: Polytropon To: jw Message-Id: <20090720041506.042b0520.freebsd@edvax.de> In-Reply-To: References: <20090719082502.92d8b144.freebsd@edvax.de> Organization: EDVAX X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: Strange (repeatable) hang when ripping a CD X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 02:15:14 -0000 On Sun, 19 Jul 2009 12:05:19 -0700, jw wrote: > Wow, thanks for the 'bad cable' idea. I've seen this error on systems where the manufacturer / composer had chosen a 40 pin cable because of "economy reasons". Hard diks and optical disc drives that could run as UMDA66 or even UDMA100 would show up as UDMA33 and run slowly and / or buggy. Putting in the recommended 80 pin cable usually solved the problem. In fact, even the so called "80 pin cable" has only 40 pins on the plugs, but 80 wires connecting them. :-) > I replaced the (brand new) cable > and it's working, now. Previously, it was the right kind, it must have > just been flakey. Judging from today's "quality hardware"... that's quite possible. > The device still shows as UDMA33 though. Don't know > if that represents a different problem. Maybe the drive isn't faster, so it's no problem. You can always check the drive's capabilities with these commands: # atacontrol cap acd0 If you've loaded the atapicam facility (via kldload or compiled into your kernel), you can as well use this: # camcontrol devlist # camcontrol inquiry 1:0:0 If you're already using cdrtools from the ports, there's another means of diagnostics: # cdrecord -scanbus # cdrecord dev=1,0,0 -inq # cdrecord dev=1,0,0 -prcap > Odd that it would have read a mounted CD just fine through the bad cable... Maybe this is due to the error correction that is included in the data CD format (ISO-9660) which has a different block size than the audio CD format (2048 vs. 2352). -- Polytropon >From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...