/hdd im Tiefschlaf

[fullcane]

Hallo,

meine /hdd kommt neuerdings nicht mehr aus dem Tiefschlaf, nachdem die dbox gestartet wurde. Es ist dann ziemlich mühsam, sie wieder mit der dbox bekannt zu machen. Kurzzeitige Unterbrechung der Stromzufuhr führt zwar dazu, dass sich die Platte wieder dreht, aber die dbox erkennt sie deshalb noch lange nicht wieder, wenn man sie danach startet. Bislang habe ich die beiden nach mehrfachem Kaltstart der Platte mit nachfolgendem Neustart der dbox irgendwann dann wieder zur Kooperation gebracht. Das dauert angesichts der Bootzeiten der dbox dann schnell mal 20 Minuten.

Nun habe ich mal das Bootlog inspiziert und dabei festgestellt, dass für die Platte ein Standby-Wert gesetzt ist. Möglicherweise hat der etwas mit dem Problem zu tun. Hier ein Auszug aus den relevanten Abschnitten:

Code: Alles auswählen

Startmode: Bootmenu - HWS: on
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx
dboxide: $Id: main.c,v 1.10 2006/10/04 00:36:41 carjay Exp $
ide: late registration of driver.
dboxide: activating cs2
dboxide: address space of DBox2 IDE CPLD is at: 0xc3ba2000
Probing IDE interface ide0...
hda: ST3200820A, ATA DISK drive
ide0 at 0x010-0x017,0x04e on irq 47
hda: attached ide-disk driver.
hda: host protected area => 1
hda: 390721968 sectors (200050 MB) w/8192KiB Cache, CHS=24321/255/63
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1 p2

Please press Enter to activate this console. SGI XFS with no debug enabled
...
XFS mounting filesystem ide0(3,2)

/dev/ide/host0/bus0/target0/lun0/disc:
 setting standby to 60 (5 minutes)

/dev/ide/host0/bus0/target0/lun0/disc:
 setting drive write-caching to 0 (off)

/dev/ide/host0/bus0/target0/lun0/disc:
 setting acoustic management to 128
hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hda: drive_cmd: error=0x04 { DriveStatusError }
 HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error
 acoustic     =  0 (128=quiet ... 254=fast)
/tmp/currentservices.xml: No such file or directory
$Id: controld.cpp,v 1.125 2006/09/24 09:17:10 barf Exp $

Kann mir jemand einen Tipp geben, wie ich die /hdd verlässlich beim Start der dbox mounten kann?

Meine Konfiguration: Nokia Kabel, Yadi Snapshot 2.2.0.1, Hallenberg IDE-IF 2.

Vielen Dank
fullcane

[Charles Darwin jun.]

Ich würde an deiner Stelle ein "frisches" JtG Komplettimage aufspielen...dann die Einstellungen im HDD-Setup machen...

...wenn du dann noch immer das Problem hast...ist es ein Hardwareproblem

[HorstH]

Ich würde an deiner Stelle ein "frisches" JtG Komplettimage aufspielen...

Das Yadi tut es auch, daran kann es nicht liegen

CU
HorstH

[fullcane]

ich sollte zur Präzisierung vielleicht noch hinzufügen, dass das Problem nicht unmittelbar nach Abschalten der dbox auftritt, sondern nur, wenn sie nach Abschalten für mehr als eine Stunde außer Betrieb war. Deswegen mein Verdacht, dass der Parameter 60 bei der Standby-Option etwas zu bedeuten haben könnte.

Gruß
fullcane

[HorstH]

Hast du mal eine andere Festplatte probiert?

Am Parameter 60 bei der Standby-Option kann es nicht liegen, da hätten meine Boxen das Problem auch

hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hda: drive_cmd: error=0x04 { DriveStatusError }

da liegt das Problem. Vermutlich Platte oder IDE Kabel !? Am Image sollte es nicht liegen.


CU
HorstH

[Gorcon]

Das Problem kenne ich auch. Es scheint mit der Zeit zusammen zuhängen wie lange die Platte zum hochfahren benötigt. ältere Platten mit nidrigeren U/Mib laufen deutlich schneller an und verursachen das Problem nicht. nur einige der 7200/Umin HDDs brauchen zu lange und die Verbindung zur HDD reist ab.

Gruß Gorcon

[fullcane]

Das Problem kenne ich auch. Es scheint mit der Zeit zusammen zuhängen wie lange die Platte zum hochfahren benötigt. ältere Platten mit nidrigeren U/Mib laufen deutlich schneller an und verursachen das Problem nicht. nur einige der 7200/Umin HDDs brauchen zu lange und die Verbindung zur HDD reist ab.

Es handelt sich in der Tat um eine 7200er Platte, aber das erklärt m.E. noch nicht, warum das Problem erst auftritt, nachdem die Platte eine bestimmte Mindestzeit abgeschaltet war. Warum läuft die Platte denn schneller an, wenn sie erst seit 30 Minuten abgeschaltet war? Und wenn das Problem nur daran liegen sollte, dass die Platte zu lange braucht, um anzulaufen, kann man ihr dann nicht mit Hilfe eines Parameters mehr Zeit dafür geben?

Hast du mal eine andere Festplatte probiert?

Hab grad keine zur Hand, werd das aber in den nächsten Tagen mal ausprobieren.
Gruß
fullcane

[Gorcon]

Einen Zusammenhang mit der dauer des Tiefschlafs kann ich nicht feststellen, mal ist es nach 1min mal nach 1h.
Es tritt auch nicht immer auf, nur machmal.

Gruß Gorcon

[fullcane]

@Gorcon: ochst du dann auch wie ich nach dem Zufallsprinzip ewig rum, bis die Platte von der dbox wieder erkannt wird oder hast du wenigstens einen systematischen Tipp, wie man die Platte in überschaubarer Zeit wieder in Gang bringt?

Gruß
fullcane

[Gorcon]

Leider nicht, nur ein reboot hilft. Die HDD klinkt sich regelrecht aus.
Ich habe aber festgestellt das die Warscheinlichkeit die Platte richtig aufzuwecken am größten ist wenn man nur wenige Daten von ihr ließt und nicht versucht gleich einen Film abzuspielen.

Beispiel: Wenn ich den Moviplayer über Blau/grün aufrufe und die Platte wieder hochfährt, dann darf ich nicht versuchen gleich einen Film abzuspielen! (Das Inhaltsverzeichniss wird ja oft noch im cache gehalten und verleitet einen gleich Play zu drücken)

Gruß Gorcon

[fullcane]

ich fürchte, jetzt liegt ein Missverständnis vor. Ich rede nicht von Tiefschlafproblemen, die während des Betriebs der dbox auftreten, sondern von Tiefschlafproblemen, die beim Starten der dbox auftreten. Die Sache entscheidet sich in folgendem Bootlog-Abschnitt

Code: Alles auswählen

Probing IDE interface ide0...

Entweder kommt da

Code: Alles auswählen

hda: ST3200820A, ATA DISK drive
ide0 at 0x010-0x017,0x04e on irq 47
hda: attached ide-disk driver.
hda: host protected area => 1
hda: 390721968 sectors (200050 MB) w/8192KiB Cache, CHS=24321/255/63
Partition check:
 /dev/ide/host0/bus0/target0/lun0: p1 p2

Please press Enter to activate this console. SGI XFS with no debug enabled

oder es kommt nach einer kurzen Pause gleich

Code: Alles auswählen

Please press Enter to activate this console. SGI XFS with no debug enabled

Letzteres bedeutet, dass die Platte nicht gemounted wurde und das kommt bei mir eben regelmäßig vor, wenn die dbox zu lange ausgeschaltet war. Danach muss ich einfach furchtbar lange mit Neustarts der dbox und Kaltstarts der Platte rumprobieren, bis die Platte wieder erkannt wird. Ist sie dann erkannt, habe ich während des Betriebs der dbox keine weiteren Probleme, trotz der Fehlermeldung beim Acoustic Management

Code: Alles auswählen

XFS mounting filesystem ide0(3,2)

/dev/ide/host0/bus0/target0/lun0/disc:
 setting standby to 60 (5 minutes)

/dev/ide/host0/bus0/target0/lun0/disc:
 setting drive write-caching to 0 (off)

/dev/ide/host0/bus0/target0/lun0/disc:
 setting acoustic management to 128
hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hda: drive_cmd: error=0x04 { DriveStatusError }
 HDIO_DRIVE_CMD:ACOUSTIC failed: Input/output error
 acoustic     =  0 (128=quiet ... 254=fast)
/tmp/currentservices.xml: No such file or directory

Einmal erkannt, fährt sich die Platte im laufenden Betrieb der dbox zwar nach 5 Minuten runter, wenn sie nicht in Anspruch genommen wird, läuft aber problemlos an, wenn sie gebraucht wird.

Kann ich den Prozess, der mit "Probing IDE Interface" im Bootlog bezeichnet wird eventuell manuell nochmal starten, falls es beim Start der dbox nicht geklappt hat? Ich suche einfach nach einer zuverlässigen Möglichkeit, beim Start der dbox sicherzustellen, dass die Platte aufgeweckt und erkannt wird.

Das Problem kommt übrigens auch nicht daher, dass die Platte beim Start zu langsam anläuft. Sie läuft einfach gar nicht an, wenn die dbox zu lange ausgeschaltet war.

Gruß
fullcane

[Gorcon]

Dann scheint aber die Platte einen hau (weg) zu haben. Beim hochfahren der Box sollte die Platte immer anlaufen.

Gruß Gorcon

[fullcane]

da mag was dran sein!

Ich habe mich vielleicht davon täuschen lassen, dass das Yadi-Script zum HDD-Check von Dr. Stoned - das ich sicherheitshalber habe durchführen lassen, und das xfs_repair ausführt - problemlos durchläuft. Nun habe mich mal via TELNET auf die dbox eingeloggt und xfs_repair ausführen lassen. Das Ergebnis sieht wie folgt aus:

Code: Alles auswählen

/var # mount
/dev/root on / type squashfs (ro)
none on /dev type devfs (rw)
proc on /proc type proc (rw)
tmpfs on /tmp type ramfs (rw)
/dev/mtdblock/2 on /var type jffs2 (rw)
automount(pid106) on /var/autofs type autofs (rw)
/dev/ide/host0/bus0/target0/lun0/part2 on /hdd type xfs (rw)
/var # umount /hdd
/var # xfs_repair -L /dev/ide/host0/bus0/target0/lun0/part2
        - creating 2 worker thread(s)
Phase 1 - find and verify superblock...
        - reporting progress in intervals of 15 minutes

fatal error -- couldn't allocate block map, size = 3036410

Danach hängt sich die dbox auf. Die Platte fährt sich runter. Immerhin wird sie aber beim anschließenden Neustart der dbox wieder erkannt. Die Dateien auf der Platte sind übrigens nach wie vor vorhanden und lesbar, mit oder ohne xfs_repair. Soll ich die Platte vielleicht mal neu initialisieren?

Gruß
fullcane

[DrStoned]

Schalte mal SWAP ein, vermutlich ist zuwenig RAM-Speicher frei.

Gib mal per Telnet free ein.

Wenn SWAP aktiviert ist, sollte das Ergebnis ungefähr so aussehen.

Code: Alles auswählen

~ > free
              total         used         free       shared      buffers
  Mem:        30820        28936         1884            0         1308
 Swap:       131532          376       131156
Total:       162352        29312       133040

Um festzustellen, wie die Platte partitioniert ist, siehe http://forum.tuxbox-cvs.sourceforge.net ... 819#333819

Greetz von DrStoned

[fullcane]

Hallo Dr. Stoned,

das Ergebnis von free sieht folgendermaßen aus:

Code: Alles auswählen

/var # free
              total         used         free       shared      buffers
  Mem:        30832        26584         4248            0         3168
 Swap:            0            0            0
Total:        30832        26584         4248

Das Ergebnis von cfdisk kommt hier:

Code: Alles auswählen

/var # cfdisk -P s /dev/ide/host0/bus0/target0/lun0/disc
Partition Table for /dev/ide/host0/bus0/target0/lun0/disc

               First       Last
 # Type       Sector      Sector   Offset    Length   Filesystem Type (ID) Flag
-- ------- ----------- ----------- ------ ----------- -------------------- ----
 1 Primary           0     2056319      1#    2056320 Linux swap / So (82) None
 2 Primary     2056320   390716864      0   388660545 Linux (83)           None

Offenbar habe ich keine SWAP-Partition angelegt. Ist das schlimm?

Gruß
fullcane

[DrStoned]

Die SWAP-Partition wurde angelegt, sie wurde aber nicht aktiviert (gemouted). Ist also nicht schlimm. Sie muss nur gemounted werden. Ich bin jedoch überfragt, wie das beim YADI-Image gemacht wird, da ich das JtG-Image verwende. Da muss Dir jemand anders helfen.

Beim JtG-Image geschieht das in /etc/init.d/init_ide. Falls diese Datei bei Dir vorhanden ist, bitte mal den Inhalt posten, dann kann ich Dir eventuell doch weiterhelfen.

Greetz von DrStoned

[fullcane]

Hallo Dr. Stoned,

du wirst dich über den Inhalt von init_ide wahrscheinlich wundern:

Code: Alles auswählen

insmod dboxide
insmod ide-detect
insmod ide-disk
#insmod jbd
#insmod ext3
insmod xfs

#HDD mounten
# SWAP mounten abgeschaltet (geht noch nicht)
if [ -e /var/etc/.swap ] ; then
/sbin/swapon /dev/ide/host0/bus0/target0/lun0/part1
fi
sleep 3
/bin/mount -t xfs /dev/ide/host0/bus0/target0/lun0/part2 /hdd
/sbin/hdparm -S 60 /dev/ide/host0/bus0/target0/lun0/disc
/sbin/hdparm -W0 /dev/ide/host0/bus0/target0/lun0/disc
/sbin/hdparm -M 128 /dev/ide/host0/bus0/target0/lun0/disc

exit 0

Gruß
fullcane

[DrStoned]

Was für ein Image verwendest Du da? Welcher Stand?
Ist das der letzte Update? Wenn dem so ist, sollte das Image auch SWAP können.
Gib mal per Telnet folgende Zeilen ein

Code: Alles auswählen

/sbin/swapon /dev/ide/host0/bus0/target0/lun0/part1

Dann wieder free

Greetz von DrStoned

[MajorK]

if [ -e /var/etc/.swap ] ; then
/sbin/swapon /dev/ide/host0/bus0/target0/lun0/part1

Existiert die Datei /var/etc/.swap denn?

[DrStoned]

Um sie anzulegen mal per Telnet

Code: Alles auswählen

touch /var/etc/.swap

eingeben.
Dann die Box neu starten und wieder free eingeben.

Greetz von DrStoned

[DrStoned]

Versuch mal folgendes:
Kopiere mal /etc/init.d/init_ide nach /var/etc/init_ide

Das geht per Telnet durch

Code: Alles auswählen

cp /etc/init.d/init_ide /var/etc/init_ide

Dann ersetze mit einem UNIX-Editor in /var/etc/init_ide die Zeilen

Code: Alles auswählen

if [ -e /var/etc/.swap ] ; then
/sbin/swapon /dev/ide/host0/bus0/target0/lun0/part1
fi

durch diese

Code: Alles auswählen

if [ -e /var/etc/.swap ] ; then 
  /sbin/swapon /dev/ide/host0/bus0/target0/lun0/part1 && /bin/mount -n -t tmpfs tmpfs /tmp -o size=128M,remount
fi

Dann die Box neu starten.

Und per Telnet wieder free eingeben.

Greetz von DrStoned

[fullcane]

habe getan, wie mir geheißen. Vorab: Ich benutze eine Kabel Nokia, avia500, Yadi Snapshot 2.2.0.1. vom 07.04.2007

Code: Alles auswählen

/hdd # /sbin/swapon /dev/ide/host0/bus0/target0/lun0/part1
/hdd # free
              total         used         free       shared      buffers
  Mem:        30832        22504         8328            0         3096
 Swap:      1028148            0      1028148
Total:      1058980        22504      1036476

Die Datei .swap scheint nicht zu existieren, wie der nächste Abschnitt zeigt. Allerdings scheine ich sie auch nicht anlegen zu können. Oder sehe ich sie mit ls vielleicht einfach nicht?

Code: Alles auswählen

/var/etc # ls
auto.net       group          issue.net      resolv.conf
exports        hosts          network        squashfs.urls
fsck.log       init.d         passwd
/var/etc # touch /var/etc/.swap
/var/etc # ls
auto.net       group          issue.net      resolv.conf
exports        hosts          network        squashfs.urls
fsck.log       init.d         passwd

Hier das Ergebnis von free nach dem Neustart der dbox:

Code: Alles auswählen

/var # free
              total         used         free       shared      buffers
  Mem:        30832        22488         8344            0         3096
 Swap:      1028148            0      1028148
Total:      1058980        22488      1036492

Dann habe ich noch die Datei init_ide in \var\etc kopiert und entsprechend modifiziert. Hier das Ergebnis von free nach dem Neustart der dbox:

Code: Alles auswählen

/var # free
              total         used         free       shared      buffers
  Mem:        30832        22488         8344            0         3096
 Swap:      1028148            0      1028148
Total:      1058980        22488      1036492

Sieht also exakt genauso aus wie vorher.
Was sagt uns das jetzt alles?

Gruß
fullcane

[DrStoned]

Gib mal per Tenet ein:

Code: Alles auswählen

cd /var/etc/

dann

Code: Alles auswählen

ls -a

dann werden auch die versteckten Dateien angezeigt.

Ergo: SWAP ist jetzt aktiviert, jetzt sollte eigentlich auch der HDD-Check durchlaufen.

Jetzt noch mal folgende Zeilen per Telnet eingeben:

Code: Alles auswählen

umount /hdd
xfs_repair -v /dev/ide/host0/bus0/target0/lun0/part2 > /tmp/fsck.log 2>&1;

Danach solltest Du nach dem Beenden des HDD-Checks eine Logdatei in /tmp/fsck.log finden, die Dir das Ergebnis des Festplattenchecks anzeigt.

Greetz von DrStoned

[fullcane]

Hallo Dr. Stoned,

anbei das Resultat von fsck.log:

Code: Alles auswählen

        - creating 2 worker thread(s)
Phase 1 - find and verify superblock...
        - reporting progress in intervals of 15 minutes
Phase 2 - using internal log
        - zero log...
zero_log: head block 172128 tail block 172128
        - scan filesystem freespace and inode maps...
        - 15:40:25: scanning filesystem freespace - 16 of 16 allocation groups done
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - 15:40:25: scanning agi unlinked lists - 16 of 16 allocation groups done
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - 15:40:27: process known inodes and inode discovery - 192 of 192 inodes done
        - process newly discovered inodes...
        - 15:40:27: process newly discovered inodes - 16 of 16 allocation groups done
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - clear lost+found (if it exists) ...
        - clearing existing "lost+found" inode
        - deleting existing "lost+found" entry
        - 15:40:42: setting up duplicate extent list - 16 of 16 allocation groups done
        - check for inodes claiming duplicate blocks...
        - agno = 1
        - agno = 0
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - 15:41:00: check for inodes claiming duplicate blocks - 192 of 192 inodes done
Phase 5 - rebuild AG headers and trees...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - 15:41:49: rebuild AG headers and trees - 16 of 16 allocation groups done
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - ensuring existence of lost+found directory
        - traversing filesystem starting at / ... 
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - 15:41:51: traversing filesystem - 16 of 16 allocation groups done
        - traversal finished ... 
        - traversing all unattached subtrees ... 
        - traversals finished ... 
        - moving disconnected inodes to lost+found ... 
Phase 7 - verify and correct link counts...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - 15:41:53: verify and correct link counts - 192 of 192 inodes done

        XFS_REPAIR Summary    Fri Jun  8 15:41:56 2007

Phase		Start		End		Duration
Phase 1:	06/08 15:39:32	06/08 15:39:32	
Phase 2:	06/08 15:39:32	06/08 15:40:25	53 seconds
Phase 3:	06/08 15:40:25	06/08 15:40:27	2 seconds
Phase 4:	06/08 15:40:27	06/08 15:41:01	34 seconds
Phase 5:	06/08 15:41:01	06/08 15:41:49	48 seconds
Phase 6:	06/08 15:41:49	06/08 15:41:52	3 seconds
Phase 7:	06/08 15:41:52	06/08 15:41:53	1 second

Total run time: 2 minutes, 21 seconds
done

Ich weiß nicht, ob du daran erkennen kannst, ob irgendwas an der Platte defekt war. Ich habe inzwischen einen ganz anderen Verdacht und der geht in Richtung Hardware. Es ist offenkundig so, dass das Nicht-Erkennen der Platte mit fehlender Wärme zusammenhängt. Ist die Platte erstmal 20 Minuten gelaufen, hat sich die dbox soweit aufgeheizt, dass die Platte beim Neustart der dbox erkannt wird. Mein unsystematisches Neustarten hat letztlich zu nichts anderem geführt als dass sich dbox und Platte allmählich aufgewärmt haben. Dadurch scheint irgendein kritischer Kontakt geschlossen zu werden, der zum Funktionieren der ganzen Angelegenheit führt.

Ich werde jetzt mal die Platte aus der dbox ausbauen und in meinen Rechner einbauen und dann mal testen, ob sie im kalten Zustand von ihm erkannt wird. Wenn ja, muss das Problem entweder am IDE-Kabel oder am IF oder an der dbox selbst liegen.

Gruß
fullcane

[fullcane]

also an der Festplatte liegt es offenkundig nicht. Habe sie in kaltem Zustand in meinen Linux-Rechner eingebaut und sie wurde auf Anhieb erkannt. Danach zurück in die dbox und das alte Problem tritt wieder auf. Erst wenn die dbox hinreichend warm geworden ist, funktioniert die Erkennung der /hdd zuverlässig. Das spricht wohl für ein Kontaktproblem. Wie kriege ich denn jetzt raus, ob's an der dbox oder am IF liegt?

Gruß
fullcane