🚀 go-pugleaf

Hallo.

In de.comp.os.unix.linux.misc Helmut Zeisel <zei2003a@liwest.at> wrote:
> Bei mir friert der Rechner reproduzierbar ein,
> wenn ich eine verschl�sselte ext2 Partiton einer externen IEEE 1394
> Firewire Disk verwende:

Passiert das auch bei einer unverschl�sselten Partiton?

> Nach einiger Zeit friert das System dann ein.
> Das passiert bei zwei unterschiedlichen externen Firewire Disks,
> mit USB 1 auf den selben Disks funktioniert es.

> Mein System ist SuSE 8.2 (Kernel 2.4.20-4GB).

> Kennt wer das Problem?
> Ist es anderswo reproduzierbar?

Ich hatte sowas "fr�her" mit Firewire auch.
2.4.20 m�sste eigentlich ok sein, aber einen neueren oder gar den neusten zu
versuchen sollte nicht schaden.
Vielleicht versuchst Du auch mal einen originalen, d.h nicht SuSE-gepatchten
Kernel.

Helmut Zeisel wrote:
> 
> Bei mir friert der Rechner reproduzierbar ein,
> wenn ich eine verschl�sselte ext2 Partiton einer externen IEEE 1394
> Firewire Disk verwende:
> 
> insmod loop_fish2
> losetup -e twofish /dev/loop0 /dev/sdb2
> Password: xxxxxxxx
> 
> mount /dev/loop0 /mnt/bck
> 
> nice -10 rsync -auv /home        /mnt/bck/bck
> 
> Nach einiger Zeit friert das System dann ein.
> Das passiert bei zwei unterschiedlichen externen Firewire Disks,
> mit USB 1 auf den selben Disks funktioniert es.
> 
> Mein System ist SuSE 8.2 (Kernel 2.4.20-4GB).
> 
> Kennt wer das Problem?
> Ist es anderswo reproduzierbar?

Ich kann's hier halbwegs nachvollziehen. Statt der verschl�sselten
ext2-Partition habe ich ein verschl�sseltes Image-File (ext2) auf
einer xfs-Partition auf der Firewire-Platte genommen (hatte keinen
unpartitionierten Bereich dort frei). Als Verschl�sselung habe ich
loop_fish mit 256 Bit genommen. 

Ein rsync von einer (mit AES 256 Bit verschl�sselten) IDE-Partition
auf eben dieses Image-File auf der Firewire-Platte lief zwar durch,
erzeugt mir jedoch eine recht hohe Systemlast von 5-7 und dauert
sehr lange. Dabei wird immer nur sto�weise geschrieben und im 
Syslog kommen fortlaufend Fehlermeldungen:

sputnik kernel: Write (10) 00 08 11 e3 d4 00 00 f8 00
sputnik kernel: ieee1394: sbp2: sbp2util_allocate_request_packet - no packets available!
sputnik kernel: ieee1394: sbp2: sbp2util_allocate_write_request_packet failed
sputnik kernel: ieee1394: sbp2: aborting sbp2 command

Die Daten wurden aber korrekt geschrieben (mit diff -r verglichen).
Der gleiche rsync ohne Verschl�sselung l�uft v�llig normal durch. 
Kernel bei mir ist Vanilla-2.4.20 (SMP) mit Crypto-API- und xfs-Patch.

> Gibt es dafuer schon einen Bugfix?

Mir ist keiner bekannt.

> Wo melde ich andernfalls den Bug?

Zuerst bei SuSE versuchen. Alternativ bei den User-Mailing-Listen auf 
http://www.linux1394.org bzw. http://www.kerneli.org. H�ngt davon ab, 
was im Syslog bei Dir als Letztes vor dem Einfrieren steht. Detailierte 
Angabe der Kernel- bzw. HW-Config (lspci -v) kann dabei nicht schaden.

Gru� Ralf

Patrick Rother <krd@easy.mcbone.net> wrote in message news:<3f2e97c2$0$30108$9b622d9e@news.freenet.de>...
> Hallo.
> 
> In de.comp.os.unix.linux.misc Helmut Zeisel <zei2003a@liwest.at> wrote:
> > Bei mir friert der Rechner reproduzierbar ein,
> > wenn ich eine verschl�sselte ext2 Partiton einer externen IEEE 1394
> > Firewire Disk verwende:
> 
> Passiert das auch bei einer unverschl�sselten Partiton?

Siehe meine Antwort an Ralf Beyerl

Ralf Beyer <beyer@uni-bremen.de> wrote in message news:<3F2EF120.A5A880DD@uni-bremen.de>...

> Ich kann's hier halbwegs nachvollziehen. Statt der verschl�sselten
> ext2-Partition habe ich ein verschl�sseltes Image-File (ext2) auf
> einer xfs-Partition auf der Firewire-Platte genommen (hatte keinen
> unpartitionierten Bereich dort frei). Als Verschl�sselung habe ich
> loop_fish mit 256 Bit genommen. 

OK, ist also anscheinend zumindest kein Hardwareproblem.

> Ein rsync von einer (mit AES 256 Bit verschl�sselten) IDE-Partition
> auf eben dieses Image-File auf der Firewire-Platte lief zwar durch,
> erzeugt mir jedoch eine recht hohe Systemlast von 5-7 und dauert
> sehr lange. Dabei wird immer nur sto�weise geschrieben und im 
> Syslog kommen fortlaufend Fehlermeldungen:
> 
> sputnik kernel: Write (10) 00 08 11 e3 d4 00 00 f8 00
> sputnik kernel: ieee1394: sbp2: sbp2util_allocate_request_packet - no packets available!
> sputnik kernel: ieee1394: sbp2: sbp2util_allocate_write_request_packet failed
> sputnik kernel: ieee1394: sbp2: aborting sbp2 command

Bei mir kommt nichts mehr: /var/log/messages

Aug  4 18:01:49 cm44-20 kernel: loop: registered Twofish encryption 
Aug  4 18:02:12 cm44-20 kernel: EXT2-fs warning: mounting unchecked
fs, running e2fsck is recommended
Aug  4 18:10:09 cm44-20 syslogd 1.4.1: restart.

Nachdem das System um 18:02 eingefroren ist, tut sich nichts mehr.

> Die Daten wurden aber korrekt geschrieben (mit diff -r verglichen).
> Der gleiche rsync ohne Verschl�sselung l�uft v�llig normal durch. 
> Kernel bei mir ist Vanilla-2.4.20 (SMP) mit Crypto-API- und xfs-Patch.

> > Gibt es dafuer schon einen Bugfix?

Ich habe inzwischen weiter experimentiert:
bei einer der beiden Disks
(Die Markendisk Maxtor External Storage 5000XT 250GB)
funktioniert tatsaechlich auch eine unverschluesselte Partition nicht;
bei der noname Disk allerdings schon - es liegt also anscheinend
am Firewire Treiber.

Mit Knoppix 3.2 (auch ein 2.4.20 Kernel) funktionieren beide Disks
unverschluesselt und zumindest die Maxtor auch mit AES128
verschluesselter Partition. Twofish ist bei Knoppix nicht dabei;
AES128 nicht im SuSE Kernel.


> > Wo melde ich andernfalls den Bug?
> 
> Zuerst bei SuSE versuchen.

Habe es bei 

http://www.suse.de/cgi-bin/feedback.cgi

mitgeteilt.

Helmut

> Siehe meine Antwort an Ralf Beyerl

Keine da?!

-- 

   Christian
   You should be part of #geekcluster.

Christian Hofstaedtler <christian@hofstaedtler.com> wrote in message news:<%S2Ya.123170$2j1.1621822@news.chello.at>...
> > Siehe meine Antwort an Ralf Beyerl
> 
> Keine da?!

Sollte inzwischen da sein; wenn nicht, kann ich sie gerne
aber nochmals senden.

Helmut