ata0 problems
Michael
I have problems in FreeBSD 4.2-STABLE
Nov 23 09:49:53 lucky /kernel: ata0: resetting devices .. done
Nov 23 09:50:44 lucky /kernel: ad0: WRITE command timeout tag=0 serv=0 -
resetting
regards, Michael
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Corey G.
FreeBSD 4.2
AMD K62-450
ATA-66 - Maxtor Drive
ad0: WRITE command timeout tag=0 serv=0 - resetting
ata0: resetting devices .. done
ad0: WRITE command timeout tag=0 serv=0 - resetting
ata0: resetting devices .. done
---end quoted text---
--
Best Regards,
Corey
Grigoriy Strokin
this problem in 4.0 and 4.1, and described
it in http://www.FreeBSD.org/cgi/query-pr.cgi?pr=17643.
The problem report has been recently closed
with the reason:
Problems with the VIA 586 chipset should be fixed in 4.2 and later
So it seems it should be re-opened?
--
=== Grigoriy Strokin, Lomonosov University (MGU), Moscow ===
=== contact info: http://isabase.philol.msu.ru/~grg/ ===
Michael
Cyrix-166
ATA-66- WD 7200 2Mb cache
Thierry....@alcatel.fr
Hello,
I also have seen it with 4.1-R and 4.1.1-R with a BX motherboard : in my case, it's most likely
due to bad hard disks (which the ata(4) driver is using with all performance options "ON")
TfH
Grigoriy Strokin <g...@philol.msu.ru> on 24/11/2000 08:37:08
To: "Corey G." <cg...@flashcom.net>
cc: Michael <mic...@abaddon.ntu-kpi.kiev.ua>,
freebsd...@FreeBSD.ORG(bcc: Thierry
HERBELOT/FR/ALCATEL)
Subject: Re: ata0 problems
I haven't tried FreeBSD 4.2 yet, but I had
this problem in 4.0 and 4.1, and described
it in http://www.FreeBSD.org/cgi/query-pr.cgi?pr=17643.
The problem report has been recently closed
with the reason:
Problems with the VIA 586 chipset should be fixed in 4.2 and later
So it seems it should be re-opened?
--
=== Grigoriy Strokin, Lomonosov University (MGU), Moscow ===
=== contact info: http://isabase.philol.msu.ru/~grg/ ===
Janet Sullivan
I was getting ad0: WRITE command timeout errors on a Quantum drive &
ASUS TX97 mobo regularly. I switched the drive to pio mode, which
stopped the error messages, but a couple weeks later the drive died
completely (won't even spin up). I'd say that if anyone is seeing WRITE
command timeout errors it might be a good time to stick the drive in pio
mode and make a backup "just in case". ;-)
Mars Attack
> ASUS TX97 mobo regularly. I switched the drive to pio mode, which
> stopped the error messages, but a couple weeks later the drive died
> completely (won't even spin up). I'd say that if anyone is seeing WRITE
> command timeout errors it might be a good time to stick the drive in pio
> mode and make a backup "just in case". ;-)
>
Try upgrading to 4.2-Stable. If you already have, you might want to address
your concerns to Soren, the ATA guru s...@freebsd.dk. There were some
problems with the code for ATA-UDMA 66 drives. There was even a problem that
went on for 2 months about UDMA-66 set as slave; but it's fixed in 4.2R as
far as I can tell on my machines. see
http://www.freebsd.org/cgi/query-pr.cgi?pr=22634
Cheers
.marz
Adrian Penisoara
Just to be sure: please post the dmesg part refering to ATA probes.
Also please post the result of "sysctl hw.atamodes'; if it has a "dma" in
the list then try a "sysctl -w hw.atamodes=pio,---,---,---" under root and
check if the error appear again.
I seem to remember I had this kind of problems myself too and I believe
this is because of some issues when operating in DMA mode (either hardware
configuration issues, like bad cable, eiher a driver problem). I solved my
problem by forcing the controller into PIO mode ("hw=pio,---,---,---" in
/etc/sysctl.conf).
Ady (@warpnet.ro)
On Fri, 24 Nov 2000, Michael wrote:
> FreeBSD 4.2
> Cyrix-166
> ATA-66- WD 7200 2Mb cache
>
Kal Torak
I have this exact same problem as well, it goes away in PIO mode,
but what if we want to use DMA or UDMA?
I think the ata driver needs some fixing because DMA mode worked
fine in previouse version of FreeBSD...
4.1R I use UDMA33 without any errors, yet once upgraded to 4.2S
I have to use PIO mode or I cant access the drive.
It would seem to be that a controler and a drive that support DMA
transfers are not the problem but the driver that cant use them
properly is...
I dont see how you can blame it on faulty hardware or cables when
the EXACT same system using 4.0R and 4.1R was able to use DMA mode
with no problems...
People have said that after getting this error there drives have
been totaly hosed, unable to even boot, I find it hard to put this
down to the driver, but somehow I doubt every haivng this problem
is using dodgey equipment...
So while its possible to get around the problems using PIO mode it
seems silly to not fix a bug just because you can get around it...
We have the workaround... now lets have the fix?!
Cheers everyone,
Kal.