# [Gelöst] Kopieren über USB >> Rechner friert ein ;(

## Martux

Hallo. Folgendes kurioses Problem:

Wenn ich über USB eine Wechselfestplatte einhänge und sagen wir mal 100Gb darauf kopieren möchte (Konqueror oder Konsole), kopiert die Kiste erst fröhlich los, bleibt aber irgendwann hängen und zwar so, daß nur noch ein Kaltstart hilft...

Dies passiert:

- an verschiedenen USB-Ports

- mit verschiedenen Festplatten

- mit unterschiedlichen Kerneln

- mit unterschiedlichen Wechselrahmen

- sowohl mit 32 als auch mit 64bit-Architektur

Wenn ich die Platten an den IDE-Kanal hänge geht alles reibungslos, genauso wenn ich nur 10-20Gb kopiere.

Ich möchte das Problem gerne eingrenzen, was könnte das sein? Fehlerhaftes BIOS? Defekte an Festplatten und Rahmen kann ich ja ausschließen.

Im Kernel habe ich folgendes zu USB aktiviert:

```

CONFIG_USB_SUPPORT=y

CONFIG_USB_ARCH_HAS_HCD=y

CONFIG_USB_ARCH_HAS_OHCI=y

CONFIG_USB_ARCH_HAS_EHCI=y

CONFIG_USB=y

# CONFIG_USB_DEBUG is not set

# Miscellaneous USB options

CONFIG_USB_DEVICEFS=y

CONFIG_USB_EHCI_HCD=y

CONFIG_USB_EHCI_ROOT_HUB_TT=y

CONFIG_USB_OHCI_HCD=y

CONFIG_USB_OHCI_LITTLE_ENDIAN=y

CONFIG_USB_UHCI_HCD=y

CONFIG_USB_STORAGE=y

CONFIG_USB_MON=y

```

Müßte doch reichen, oder? Bin mal auf Eure Antworten gespannt.

----------

## tuam

Wie wird das USB-System in lspci und dmesg erkannt? Da gibt es manchmal Probleme mit einzelnen Chipsätzen.

FF,

Daniel

----------

## schachti

Ist der Fehler unabhängig vom verwendeten Dateisystem? Hängt da evtl. ein Loop-Device zwischen?

----------

## Martux

Hallo!

Zum Dateisystem muß ich sagen, daß ich es nur mit reiserfs (3.6) probiert habe, da dieses seit Jahren überall stabil zum Einsatz kommt. Leider kann ich die Platten auch nicht eben umformatieren, da es sich um meine Backups handelt.

```

lspci | grep USB

00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev a0)

00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev a0)

00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev a0)

00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev a0)

00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)

cat /var/log/dmesg | grep USB

ehci_hcd 0000:00:10.4: new USB bus registered, assigned bus number 1

ehci_hcd 0000:00:10.4: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004

hub 1-0:1.0: USB hub found

ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver

USB Universal Host Controller Interface driver v3.0

uhci_hcd 0000:00:10.0: new USB bus registered, assigned bus number 2

hub 2-0:1.0: USB hub found

uhci_hcd 0000:00:10.1: new USB bus registered, assigned bus number 3

hub 3-0:1.0: USB hub found

uhci_hcd 0000:00:10.2: new USB bus registered, assigned bus number 4

hub 4-0:1.0: USB hub found

uhci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 5

hub 5-0:1.0: USB hub found

usb 3-1: new full speed USB device using uhci_hcd and address 2

usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x03F0 pid 0x6104

Initializing USB Mass Storage driver...

USB Mass Storage support registered.

drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver

```

EDIT: Ne, keine loop devices, ganz ordinär als primäre Partition formatiert.

----------

## Inte

Was sagt das System Log? Kernel Oops vielleicht?

Mir ist das auch mal passiert, als ich aufgrund von Platznot 'ne UDF formatierte Platte via USB zum auslagern von aktiven Bittorrent shares verwendet habe.

----------

## Martux

Ach ja, das wollte ich ja noch im OT schreiben: Keine logs o.ä., geht anscheinend zu schnell...

----------

## Martux

Soo, auch ein BIOS-Update hat leider nichts gebracht, nach wie vor der Selbe Fehler ;(

----------

## Martux

ARGHH, verzweifel!

Auch mein letzter Strohhalm, ein microcode-update vermittels microcode_ctl hat nichts gebracht... Scheint also wirklich ein Chipsatz-Problem zu sein. Was kann ich da machen? Mainboard wechseln???

Ach ja, zu microcode_ctl habe ich noch eine Frage:

Wenn ich das init script im runlevel boot laufen habe und es ok ausgibt, wurde dann das default-file /etc/microcode.dat geladen? Irgendwie kann ich nirgends verifizieren daß das passiert ist.

Gruß, Marcus

----------

## schachti

Muss nicht der Chipsatz auf dem Mainboard sein, kann doch genauso gut ein Problem mit dem Controller-Chip des Wechselrahmens sein.

----------

## Martux

Glaub ich net, passiert doch schon mit dem 2. Rahmen (unterschiedliche Hersteller) sowie mit unterschiedlichen Platten...

----------

## schachti

Naja, wenn in beiden Rahmen die gleichen Controller (oder Controller des gleichen Herstellers) verbaut sind... Prüf das doch mal nach. Ich hatte auch mal so einen Adapter, um IDE-Festplatten an den USB-Bus anzuschließen. Damit gab es auch regelmäßig Probleme, bis ich auf einen anderen Adapter mit anderem Controller umgestiegen bin. Seitdem habe ich keine Probleme mehr.

----------

## Martux

Hoho! Habe das Problem gelöst. Seit ich gestern auf libata im Kernel umgestiegen bin, ist das Ganze kein Problem mehr!

----------

