zip-Laufwerk an Sockel-A-System?

Alle Versuche, ein internes zip-Laufwerk an einem Sockel-A-System stabil in Gang zu kriegen, sind bisher gescheitert

Hardware:

• Hauptplatine AsRock K7Upgrade-600 (Via KT600)
• Hauptplatine Elitegroup K7S5A (SiS 735)
• Laufwerk zip100 Atapi intern (neuere Version, die mdma1 kann)
• Laufwerk zip250 Atapi intern

Software (auf beiden Systemen):

• Linux Kernel 2.6.31.5
• Slackware-13.0

Gestest wurden alle Kombinationen mit einem zip-Laufwerk am Onboard-IDE-Controller als Secondary Master, also /dev/hdc.

Bei allen Kombinationen passiert Folgendes:
Nach dem Systemstart funktioniert mit dem ersten eingesteckten zip-Medium genau einmal mount, rw-Zugriff auf das Medium und umount. Wird dann ein weiteres oder das selbe zip-Medium nochmal eingsteckt, friert die Console nach dem mount-Befehl ein. Auf das Medium kann nicht zugegriffen werden. Auf den anderen Consolen kann weiter gearbeitet werden, ein shutdown lässt sich auslösen. Allerdings fährt das System nicht komplett herunter, sondern friert kurz vor dem Ende ein (K7S5A) oder hängt in einer Endlosschleife (K7Upgrade-600). Die letzten Meldungen vor dem Einfrieren des K7S5A:

/dev/root umounted
Remounting root filesystem read-only.
/dev/hde3 on / type ext3 (ro)
Shutdown: hdc

Beim K7Upgrade-600 kommt zum Ende eine kryptische ACPI-Fehlermeldung, danach "hdc: lost interrupt" mit irgendwelche IDE-reset-Versuchen im Wechsel als Endlosschleife.

Dann hilft nur noch der Ausschalter.
Im Internet findet sich der Hinweis, das zip-Laufwerk im BIOS zu deaktivieren. Allerdings ändert das genau gar nichts, da der Linux-Kernel nach dem Start das BIOS für die Laufwerksverwaltung nicht mehr benutzt. Gibt es für das Problem eine Lösung am Sockel-A-System oder bleibt nur der Einbau der zip-Laufwerke in wesentlich ältere Kisten? Wie alt? Sockel-Super-7 geht, Sockel-370?

Zitat von Dirk

Wie ist es gejumpert, und liegt noch was anderes auf dem kanal?

Master, wird ja auch korrekt als /dev/hdc erkannt. Es hat den secondary IDE für sich allein.

Zitat von Dirk

Hatte auch schon in solchen Kisten auch Atapis am laufen. aber mit windows.

Kann es evtl. sein, dass Windows die Dinger im Pio-Mode laufen lässt? Linux nimmt standardmäßig DMA. Das werde ich nachher mal gewaltsam für secondary IDE abwürgen.

Zitat von freaked

Hab ein zip in meinem i5 und das tut 1a...also liegts an der linuxgrütze

Proprietären Müll aus Redmont/USA wird es auf den erwähnten Systemen nicht geben!

Zitat von adun

Also bei mir läuft sogar ein internes SCSI Zip 100 ohne Probleme unter Scientific Linux 6

Da war es, das entscheidende Wort: SCSI

Das zip100 läuft jetzt am K7S5A, allerdings nur im Pio-Mode 3
Dem Kernel ein "ide_core.nodma=1.0" zu verabreichen, reichte aus. Bei den Sockel-Super-7-Systemen war so etwas nicht nötig, aber ich weiß jetzt nicht mehr, ob das Ding daran nicht auch ohne DMA lief. Die Hauptplatinen konnten auch nur max. udma2 und auch das funktionierte mitunter nicht mit Laufwerken für Wechseldatenträger (z.B: Asus P5A-B mit DVD-ROM udma2 an IDE-Controller udma2: Transfermode max. mdma2 einstellbar).

Zitat von DosAmp

Sofern ich mich erinnern kann, läuft mein internes IDE-Zip-100-Laufwerk am Scenic (Intel i815E + ICH) unter Windows Me auch nur im PIO-Modus – das DMA-Häkchen im Geräte-Manager hatte sich nach einem Neustart zurückgesetzt.

Es scheint wirklich ein DMA-Problem zu sein, denn am AsRock K7Upgrade-600 hat der Kernel-Bootparameter "ide_core.nodma=1.0" das Problem ebenfalls gelöst. Das zip-Laufwerk darf weiterhin mit "hdparm -c1u1" bestiefelt werden.