Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 8 Dec 2002 22:28:38 +0000
From:      Bruce Cran <bruce@cran.org.uk>
To:        "Cliff L. Biffle" <cbiffle@safety.net>
Cc:        current@freebsd.org
Subject:   Re: ATACD issues slowly coming back...
Message-ID:  <20021208222838.GA3422@fourtytwo.gamesoc>
In-Reply-To: <200212061435.45583.cbiffle@safety.net>
References:  <200212061435.45583.cbiffle@safety.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 06, 2002 at 02:35:45PM -0700, Cliff L. Biffle wrote:
> I mentioned earlier on the list that the ATA issues I'd been having with 4.7 
> had disappeared since installing 5.0.  They're still much less frequent -- 
> i.e. I can burn CDs now -- but I just got one of the old messages and wanted 
> to submit it for your perusal.
> 
> cliff50 kernel: acd0: READ_BIG - MEDIUM ERROR asc=0x11 ascq=0x00 error=0x00
> 
> I'm not well versed on the ATA command set, but that looks like a command to 
> the drive failing to execute.  Is this likely to be the drive, the 
> controller, both, or is it impossible to tell from the data set?
> 
> This is on the aforementioned potentially-buggy Apollo KT133 chipset, but it's 
> never reported these errors on my hard disk (knock on wood), only the CD 
> drive.  They -are- on separate channels.
> 
> I'll see what information I can collect here, but suggestions on where to look 
> are appreciated.

I reported a panic under -CURRENT a few days ago (see ATA/ATAPI related
panic).  When I tested out DP1
I never saw any ATAPI problems, but since trying DP2 I have, once more,
seen errors.  I've got a A7V-266E motherboard with a KT266A chipset.  The
solution in my case was to tell the BIOS I didn't have any ATAPI drives.
FreeBSD then found everything properly, without any problems - I think
the BIOS was maybe configuring the master for UDMA33 and the slave for
PIO4, whereas FreeBSD seems to prefer them both as PIO4, but I really
don't know.   I kept seeing READ_CAPACITY and READ_BIG timeouts, along
with data overrun errors.   I think it probably is the controller,
because even with no drives connected, my computer paused for a good few
seconds while trying to probe the io/irq - it found the primary (which
only has a hard drive on it) immediately, but paused far too long trying
to find the secondary.

--
Bruce Cran

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021208222838.GA3422>