From owner-freebsd-stable Mon Nov 27 14:54:10 2000 Delivered-To: freebsd-stable@freebsd.org Received: from zork.sf-bay.org (zork.sf-bay.org [192.150.103.29]) by hub.freebsd.org (Postfix) with ESMTP id CA41237B4C5 for ; Mon, 27 Nov 2000 14:54:05 -0800 (PST) Received: (from uucp@localhost) by zork.sf-bay.org (8.11.1/8.9.3) with UUCP id eARMs4681029 for freebsd-stable@freebsd.org; Mon, 27 Nov 2000 14:54:04 -0800 (PST) (envelope-from scott@zorch.sf-bay.org) Received: (from scott@localhost) by zorba.sf-bay.org (8.11.1/8.8.8) id eARMqYl57240 for freebsd-stable@freebsd.org; Mon, 27 Nov 2000 14:52:34 -0800 (PST) (envelope-from scott) Date: Mon, 27 Nov 2000 14:52:34 -0800 (PST) From: Scott Hazen Mueller Message-Id: <200011272252.eARMqYl57240@zorba.sf-bay.org> To: freebsd-stable@freebsd.org Subject: atadisk problem? Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've got a new 40GB disk, a Maxtor (yeah, not the best brand...) ST0154000U Ultra ATA-100 unit. My m/b is a couple of years old, with an onboard UDMA33 controller. I've not been using the IDE side of things, preferring to use an Adaptec 2940 and a 9GB Seagate drive. I recently added this Maxtor to the system because of errors on the SCSI drive. When I first installed on the system (running an oldish 4.1-STABLE), I had BIOS problems and only saw 33GB of the disk. I had swapped drives around so I was running off the Maxtor, and then went away for the weekend. Just a few hours after I left, something (!), I don't know what, went awry and both drives acted like they had eaten their partition tables - e.g. '?' from the boot loader told me there was no label or some such. Anyhow, after considerable thrashing about, I found the partition tables and labels again (!!) and reverted to operating on the SCSI drive. In the interim, I flashed the BIOS with a recommended update from the motherboard maker and seem to see all 40GB. That's the background. Once the BIOS was flashed, I started trying to use the disk, and kept getting problems like - Nov 27 14:24:12 zorch /kernel: ad0: HARD WRITE ERROR blk# 29409399ad0: HARD WRITE ERROR blk# 29409399 status=79 error=04 Nov 27 14:24:12 zorch /kernel: ad0: DMA problem fallback to PIO mode Nov 27 14:24:15 zorch /kernel: ad0: HARD READ ERROR blk# 0 status=79 error=04 Nov 27 14:24:15 zorch /kernel: ad0: reading primary partition table: error reading fsbn 0 after which the disk hangs (the access light stays on until power-down) and is unusable. This error occurs during the initial newfs of the drive. I'm using Warner Losh's diskprep script to fdisk/disklabel/newfs the drive. Just before tearing the drive out and trying to take it back (I lost the store receipt :-( ) I decided to try one more thing, so I took my trusty Win9x boot floppy, useful for things like flash upgrades, and, using it conjunction with Maxtor's disk tools re-partitioned and formatted the disk. From the short amount of time that took, I suspect it did some sort of quick format, so I followed that up with a 'format /u c:'. The latter format processed bits for about an hour and then completed successfully. This leads me to suspect there is not a problem with my on-board controller, BIOS, cabling or drive. I realize that DOS/Win9x is comparatively wimpy compared to FreeBSD, but I also expect that if DOS can read/write the drive for over an hour without reporting an error, and FreeBSD can't even do that for 10 minutes, something is wrong with the latter. I have tried setting hw.atamodes to pio manually before starting the newfs, with no luck there. I think I've even got UDMA disabled in the BIOS, for what that's worth. In the interval between my first attempts and my last attempt, I've upgraded from 4.1-STABLE to 4.2-STABLE as of 22 November, since I saw a fair amount of activity in the ata files in the cvsweb. Info from dmesg - Nov 27 13:00:11 zorch /kernel: atapci0: port 0xe400-0xe40f at device 7.1 on pci0 Nov 27 13:00:11 zorch /kernel: ata0: at 0x1f0 irq 14 on atapci0 Nov 27 13:00:11 zorch /kernel: ata1: at 0x170 irq 15 on atapci0 Nov 27 13:00:12 zorch /kernel: ad0: 39082MB [79406/16/63] at ata0-master UDMA33 My question to the list is, should I give up and try to return the drive, or is there a findable/fixable bug here? I'm willing to try patches or even give remote (ssh) access to the system to an appropriate developer. \scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message