Re: SiI 0680 UDMA133 controller / TIMEOUT - READ_DMA

From: Benjamin Thelen <bent(at)wheregroup.com>
Date: Thu, 9 Aug 2007 20:31:00 +0200 (CEST)

Hi Olli,

On Thu, August 9, 2007 19:37, Oliver Fromme wrote:
> Benjamin Thelen wrote:
>
>> Habe auch geguckt, ob die SeaTools irgendwas in der Richtung hergeben,
>>
>
> Dem Namen nach sind die eher für Seagate-Platten gedacht.
> Gut möglich, dass die nicht alle Infos einer Maxtor-Platte
> korrekt ausliest.

Das war mal - Maxtor wurd ja aufgekauft.

Zitat Seagate:
SeaTools for DOS has replaced SeaTools Desktop and PowerMax.

>
>> [Idle-Spindown]
>> Gestern hatte ich diese Idee auch ganz kurz, habe sie dann aber
>> verworfen, weil ad4 ja nicht betroffen ist.
>
> OK, ist ein bisschen weit hergeholt, aber theoretisch könn-
> te es halt nur bei der einen Platte enabled sein.
>
>> Ich habe jetzt vor dem rsync-Aufruf noch ein "sleep 20; ls <auf die
>> Platte>" eingebaut,
>>
>
> Wohl eher umgekehrt: ls ; sleep 20

Ups. Ja, klar.

>
>
> Wird aber vermutlich nicht das geringste an den Symptomen
> ändern: Die Warnmeldung wird dann halt durch das ls aus-
> gelöst anstatt durch das rsync. Ist ja letztendlich eigentlich vollkommen
> egal.

Jepp. Da wirst Du sehr wahrscheinlich recht haben. Es ist das spin down zu
vermeiden. Nur wie?

>
>> sodaß ich hoffe, daß, wenn das rsync losgeht, die Platte wach genug ist.
>> Mal sehen.
>>
>
> Man beachte, dass es nur eine Warnmeldung war.

Ist das so? Kann ich so nicht als solche erkennen oder habe ich Tomaten
auf den Augen?

> Nach dem
> Timeout wurde die Operation natürlich wiederholt und war
> dann immer erfolgreich (sonst hättest Du eine entspre- chende Fehlermeldung
> erhalten). Auch ein Grund, warum ich in Richtung Idle-Spindown vermutet
> habe.
>

Ja. Klingt logisch. Bin ich auch für ;-).

>>> # dd if=/dev/ad6 of=/dev/null iseek=12100 count=100
>>>
>>
>> Nein. Alles in Butter.
>>
>
> Dann kann man eigentlich mit recht hoher Wahrscheinlich-
> keit annehmen, dass die Platte keinen defekten Block an der Stelle hat.

Sehr schön.

>
> Dem Tip, mal die Kabel zu checken und ggf. zu entwirren,
> kann ich mich auch anschließen. Sollte auf jeden Fall nicht schaden.

Werde ich in Angriff nehmen.

>
> Es kann auch einfach sein, dass die plötzliche, vom Cron-
> Job herrührende Aktivität (wenn schon kein SPin-Up, dann
> immerhin Kopfbewegungen) einen kleinen Strompuls auf der
> Spannungsversorgung bewirkt. Dies kann unter Umständen
> kurzzeitig das Signal auf dem Datenkabel stören, wenn es zu nah dran ist.
> Oder, wenn das Netzteil schwächelt,
> könnte auch dadurch das Problem verursacht werden.
>
> Besonders wahrscheinlich ist das nicht, aber es soll
> schon vorgekommen sein. Jetzt bitte keine Sprüche von Pferden und
> Apotheken ... ;-)
>
>
> Gruß
> Olli
>
>
> --
> Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
> Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
> secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
> chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
>
>
> FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
>
>
> "We, the unwilling, led by the unknowing,
> are doing the impossible for the ungrateful. We have done so much, for so
> long, with so little, we are now qualified to do anything with nothing."
> -- Mother Teresa
>
>
>
> To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
> with "unsubscribe de-bsd-questions" in the body of the message
>

Jetzt habe ich den "smartctl -t long /dev/ad4" gestartet und bekomme in
die /var/log/messages folgendes reingehauen.

ad4: FAILURE - unknown CMD (0xb0) status=51<READY,DSC,ERROR> error=4<ABORTED>

Naja wird schon werden. Jedenfalls vielen Dank!

Gruß,
Benjamin

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 09 Aug 2007 - 20:33:24 CEST

search this site