Re: panic: USB drive disconnected

From: Polytropon <freebsd(at)edvax.de>
Date: Sat, 20 Oct 2012 17:22:20 +0200

On Sat, 20 Oct 2012 17:01:19 +0200, Marc Santhoff wrote:
> Kurz:
>
> ugen0.2: <Verbatim> at usbus0 (disconnected)
> umass0: .... (disconnected)
> g_vfs_done():da0s1d[WRITE(offset=..., length=2048)]error = 6
> /mnt: got error 6 while accessing filesystem
> ...
>
> Falls mehr von Interesse ist, habe ich ein etwas unscharfes Foto davon.
>
> Verstehe ich das richtig, daß sich die Platte abgemeldet hat?

Ja. Und natürlich hat sich eine ganze "Kette" von Geräten
verabschiedet, also da, umass und ugen, wie's aussieht.

> Also es entweder ein Kontaktproblem am Kabel ist oder die Platte sich
> schlafen gelegt hat? Nee, geht nicht, dann wäre sie ja sofort wieder
> aufgeweckt worden ... vielleicht auch die Spannungsversorgung.

Ich würde hier auf Spannungsversorgung und Kabel an erster Stelle
tippen, Schlafenlegen während Betriebs klingt eher unwahrscheinlich.
Aber vielleicht gibt es ja auch Geräte, die eingebaute Temperatur-
sensoren haben und sich bei Übertemperatur abschalten... man steckt
in der Technik ja nicht drin.

Hasz Du die Möglichkeit, einen Kreuztest (andere Platte am selben
System, diese Platte an anderem System) durchzuführen und unter
gleichartigen Bedingungen zu schauen, wohin der Fehler "wandert"?
Könnte schließlich auch eine gakelige USB-Buchse sein (eher
unwahrscheinlich, aber möglich, hab' ich so z. B. schon gesehen).

> Bisher hat das alles prima funktioniert, keine Änderung an irgendwas.
> Auch dump -0 usw. ist prima durchgelaufen, das cpdup-Skript ebenfalls.

Altersschwäche der Festplatte?

> NAch dem Auftreten des Fehlers hatte ich alle Platten natürlich
> gründlich mit fsck behandelt, die externe wollte gern einmal fsck -p und
> danach nochmal fsck -y, damit das Dateisystem wieder sauber war.

Das ist in Ordnung, dafür sind diese Tools ja da. Viel schlimmer
wäre es, einen unbemerkten Dateisystemschaden mit sich herumzuschleppen
und dann "überraschenderweise" Datenverluste zu haben...

> Ach ja, USB3.0, xhci-Trieber und diese Platte:
>
> ugen0.2: <Portable USB 3.0 Drive Verbatim> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON
>
> Oct 20 16:59:05 puma kernel: da1 at umass-sim1 bus 1 scbus1 target 0 lun 0
> Oct 20 16:59:05 puma kernel: da1: <TOSHIBA MK1059GSM > Fixed Direct Access SCSI-2 device
> Oct 20 16:59:05 puma kernel: da1: 400.000MB/s transfers
> Oct 20 16:59:05 puma kernel: da1: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C)

Obwohl das eigentlich keine Rolle spielen sollte - verhält sich
die Platte denn normal, wenn nicht der xhci-, sondern der "langsamere"
Treiber (USB 2.0) verwendet wird?

Öhm, und daß hier im Log da1, oben im Beispiel aber da0 erscheint,
bezieht sich dennoch auf dieselbe Platte, richtig?

> Genervte Grüße,
> Marc (sich ohne externes Backup unwohl fühlend)

Das ist redundant; Backups sind immer extern, sonst wären's keine.
Ich sag' bloß: "Wir haben aber RAID, das _ist_ unser Backup!" :-)

-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 20 Oct 2012 - 17:22:30 CEST

search this site