From owner-freebsd-stable@FreeBSD.ORG Sun Aug 12 16:29:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF7F7106564A for ; Sun, 12 Aug 2012 16:29:26 +0000 (UTC) (envelope-from wajih.ahmed@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 487A68FC08 for ; Sun, 12 Aug 2012 16:29:25 +0000 (UTC) Received: by bkcje9 with SMTP id je9so1160550bkc.13 for ; Sun, 12 Aug 2012 09:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8FK8XfkFfHTmPk9QUz6r1wL+Bht0m8oZiu1vYL6150g=; b=geKhtq85ONQIM5s1mOl+aOHpOavVsYQPH27Kv5+Sko/no2+akZgPU0birUaCD9aFZi PYvLGerpYKPrpo3omqcvFHhXtdKZtFx9e2juUshrNSWpCp7ZssNcUD+ga9BBhWSrASk0 ILTdO7sXhtEyPC1rH6F8IhWU4582wsY8/A6hdweK3hDVXmGL9mPQxRh6cjQEOVUJAKeR e9Oh5cjNpYhSS5q1imgq7T/ho02vOA9xtOhZ1YyngXwwkNRax0E+9Q/nKvypC+pR5XgP ry8CVY8GuDlhIOLpqBqSzJnM5WW83r05Oz0OohfuKX6ejphJstKGGdRRqxrvFgFIFABq gcxQ== MIME-Version: 1.0 Received: by 10.204.157.6 with SMTP id z6mr3208037bkw.25.1344788964684; Sun, 12 Aug 2012 09:29:24 -0700 (PDT) Received: by 10.204.38.141 with HTTP; Sun, 12 Aug 2012 09:29:24 -0700 (PDT) In-Reply-To: <1344786355.1186.32.camel@revolution.hippie.lan> References: <1344786355.1186.32.camel@revolution.hippie.lan> Date: Sun, 12 Aug 2012 12:29:24 -0400 Message-ID: From: Wajih Ahmed To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.0 and (Kingspec) PATA drive ATA status errors. Drive unusable. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 16:29:26 -0000 Thank you. I'll try it out. One question though. How do i modify the loader.conf on the usb image from which i am booting? Is there somethign i can change in the boot loader? If this is RTFM kindly point me to it. On Sun, Aug 12, 2012 at 11:45 AM, Ian Lepore wrote: > On Sun, 2012-08-12 at 10:57 -0400, Wajih Ahmed wrote: > > I have a Dell D420 laptop with the ZIF interface and uses a 1.8" PATA > > drive. I purchased a Kingspec 16GB SSD and installed it. The BIOS > > recogonizes the drive. I am using the USB image to boot in verbose mode. > > Upon boot the disk is recognized by FreeBSD 9.0 as follows (sorry for any > > typos as i am reading this off the console): > > > > ada0 at ata0 bus 0 scbus0 target 0 lun 0 > > ada0: ATA-7 device > > ada0: Serial number... > > ada0: 100.0000MB/s transfers (UDMA5, PIO 512bytes) > > > > Then i see these errors > > > > (ada0:ata0:0:0:0): ATA status error > > .....READ_DMA. ACB: c8 .... > > .....CAM status: ATA status error > > .....ATA status: 51 (DRDY SERV ERR), error: 84 (ICRC ABRT) > > .....RES: 51 ..... > > > > > > As a result the disk is rendered unusable and i cannot write (partition) > to > > it. I did test the drive with a linux boot disk and i was able to format > > it. > > > > So my question is how can i make this drive work? Do i need to pass > > something to the kernel at boot to lower the speed of the drive. Maybe > to > > UDMA66? Any help will be really appreciated. > > Whenever I've seen ICRC errors, it has been caused by using a 40-wire > cable at speeds faster than UDMA33 [1]. A potential fix is to force the > mode in loader.conf: > > hint.ata.0.mode="UDMA33" > > [1] I've also seen ICRC errors when there was no cable involved at all, > such as with a surface-mount compact flash socket on a circuit board > that has 50 pins spaced even closer together than a standard ata cable. > I have no real proof that such closely-spaced pins cause the same kind > of signal crosstalk as a 40-wire cable (they're close, but the length of > the parallel wires is just a couple millimeters), but forcing the driver > to UDMA33 or less always seems to fix the problem. > > -- Ian > > >