Re: Suse 8.2 scheint bald zu kommen :)
Was ich nicht mache und wovon ich abrate, ist die -X Option von hdparm. Wenn das IDE-Device und der Chipsatz sich mit "-d1" nicht auf einen Modus einigen kann es sein, das du -X verwenden musst. Nach meiner Erfahrung fangen aber ab UDMA66 viele Geraete an rumzuzicken. Mir reicht auch der Multiword-DMA Modus.
Hallo Peter ich muss leider die -X option von hdparm benutzen, sonst läuft es
bei mir nicht. Ich werde mal die Lösung von Patrick ausprobieren
DMA ONLY FOR HDD: Y/N
das scheint mir doch der Fehler zu sein, da ich sonst mit früheren Suse
Versionen (7.2, 7.0) keine Probleme hatte, 2.2 Kernel.
Deswegen habe ich auch Knoppix zur Sprache gebracht, da es sich wirklich nur
um eine Kerneloption handeln kann, und das probiere ich mal aus. Sonst hatte
ich nie Probleme.
Rafael wrote:
Was ich nicht mache und wovon ich abrate, ist die -X Option von hdparm. Wenn das IDE-Device und der Chipsatz sich mit "-d1" nicht auf einen Modus einigen kann es sein, das du -X verwenden musst. Nach meiner Erfahrung fangen aber ab UDMA66 viele Geraete an rumzuzicken. Mir reicht auch der Multiword-DMA Modus.
ich muss leider die -X option von hdparm benutzen, sonst läuft es bei mir nicht. Ich werde mal die Lösung von Patrick ausprobieren DMA ONLY FOR HDD: Y/N das scheint mir doch der Fehler zu sein, da ich sonst mit früheren Suse Versionen (7.2, 7.0) keine Probleme hatte, 2.2 Kernel. Deswegen habe ich auch Knoppix zur Sprache gebracht, da es sich wirklich nur um eine Kerneloption handeln kann, und das probiere ich mal aus. Sonst hatte ich nie Probleme.
$ zgrep DMA /proc/config.gz CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_IDEDMA_ONLYDISK=y $ hdparm -d /dev/hdc /dev/hdc: using_dma = 1 (on) $ grep hdc /var/log/boot.msg <4> ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio <4>hdc: Pioneer CD-ROM ATAPI Model DR-A04S 0105, ATAPI CD/DVD-ROM drive <4>hdc: no flushcache support <4>hdc: ATAPI 32X CD-ROM drive, 128kB Cache $ mount /cdrom; find /media/cdrom -type f -exec md5sum {} \; (...) Ich hab auch schon den genauen Kernel-Code gelesen, der von CONFIG_IDEDMA_ONLYDISK abhaengt und kann dir versichern, das ein Abschalten dieser Kernel-Option nur entscheidet, ob der Kernel das CD-ROM in den DMA-Modus bringt oder nicht. Ob du nachtraeglich mit hdparm oder per 'echo "using_dma:1" > /proc/ide/ide1/hdc/settings' den DMA-Modus aktivieren kannst, haengt von dieser Variablen nicht ab.
Ich war nie überfordert mit der Aktivierung des DMA- Modus eines CDroms bei Suse 8.0 und 8.1 Schon in Dezember habe ich hierzu eine Lösung gepostet mit hdparm. ;)
Ja, ich hatte von deinem Post nur den oberen Teil gelesen und nicht bemerkt, das du hdparm benutzt. War auch etwas scharf geschossen. Peter
Peter Wiersig schrieb:
Rafael wrote:
Ich hab auch schon den genauen Kernel-Code gelesen, der von CONFIG_IDEDMA_ONLYDISK abhaengt und kann dir versichern, das ein Abschalten dieser Kernel-Option nur entscheidet, ob der Kernel das CD-ROM in den DMA-Modus bringt oder nicht. Ob du nachtraeglich mit hdparm oder per 'echo "using_dma:1" > /proc/ide/ide1/hdc/settings' den DMA-Modus aktivieren kannst, haengt von dieser Variablen nicht ab.
Würde dir das gern in der Praxis zeigen, bootete ich den normalen Kernel mit der Aktivierten Option, lies sich DMA auch einschalten, nur wenn ich dann das betreffende CDROM benutzen wollte ging das nicht richtig, nach etwa 15 Sekunden kam dann ein Kernel Panic mit blinkenden LEDs ! ;-) Ich weiss aber von meinem Cousin das er DMA aktivieren konnte mit der Option ohne Probleme Scheint also ein Zusammenspiel mit der Hardware und bestimmten Geräten zu sein. Siehe auch mein Thread damals in dieser Liste http://lists.suse.com/archive/suse-linux/2002-May/1985.html Gruss Patrick
Patrick Klaus wrote:
Würde dir das gern in der Praxis zeigen, bootete ich den normalen Kernel mit der Aktivierten Option, lies sich DMA auch einschalten, nur wenn ich dann das betreffende CDROM benutzen wollte ging das nicht richtig, nach etwa 15 Sekunden kam dann ein Kernel Panic mit blinkenden LEDs ! ;-)
Und ich glaube immer noch, das mehr als die Option CONFIG_IDEDMA_ONLYDISK bei den beiden Kernel-Versionen unterschiedlich sind. Nachweis: $ find -name '*.[ch]' | xargs grep IDEDMA_ONLYDISK ./drivers/ide/ide.c:#ifdef CONFIG_IDEDMA_ONLYDISK ./include/linux/autoconf.h:#define CONFIG_IDEDMA_ONLYDISK 1 ./include/config/idedma/onlydisk.h:#define CONFIG_IDEDMA_ONLYDISK 1 Die Include-Dateien spiegeln den Inhalt nach "make config; make dep" wieder. Die einzige Stelle, an der die Option einen Unterschied macht ist in ide.c. der Code aus ide.c: ~~~~~ 3670,3678 int ide_register_subdriver (ide_drive_t *drive, ide_driver_t *driver, int version) { unsigned long flags; int enable_dma = 1; #ifdef CONFIG_IDEDMA_ONLYDISK if (drive->media != ide_disk) enable_dma = 0; #endif ~~~~~ Du hast leider ueberhaupt keinen Kernel-Oops gepostet, der hier recht interessant waere. In dem zitierten Thread wird behauptet, das der SuSE-SMP Kernel nicht mit CDROM-Laufwerken im DMA-Modus funktionieren will. Ist es moeglich, das du den SMP-Kernel installiert hast, und der uebersetzte Kernel ein Uniprozessor Kernel ist? Jeder Kernel-Entwickler wird dir bei der geschilderten Problem-Stellung ohne den ksymoops Output den Oopses nicht weiterhelfen, weil es nicht moeglich ist, deinen Fehler auf einem anderen System mit deinen Angaben zu wiederholen. Allerdings kann es sein, das du den Oops von Hand abschreiben musst, da der Kernel je nach Fehler alle Schreibzugriffe auf die Festplatten, die ja bei dir wahrscheinlich auch IDE-Laufwerke sind sperrt. Peter
Peter Wiersig schrieb:
Patrick Klaus wrote:
Und ich glaube immer noch, das mehr als die Option CONFIG_IDEDMA_ONLYDISK bei den beiden Kernel-Versionen unterschiedlich sind. Nachweis:
Versteh ich jetzt nicht. Damals behob ich das Problem indem ich die Kernel-Quellen installierte und die vorgegeben Config nur durch den einzigen Eintrag änderte. Okay vielleicht waren die Kernelquellen oder die Config anders eingestellt wie der SuSE-Kernel der fertigkompiliert dabeiwar.
$ find -name '*.[ch]' | xargs grep IDEDMA_ONLYDISK ./drivers/ide/ide.c:#ifdef CONFIG_IDEDMA_ONLYDISK ./include/linux/autoconf.h:#define CONFIG_IDEDMA_ONLYDISK 1 ./include/config/idedma/onlydisk.h:#define CONFIG_IDEDMA_ONLYDISK 1
Die Include-Dateien spiegeln den Inhalt nach "make config; make dep" wieder. Die einzige Stelle, an der die Option einen Unterschied macht ist in ide.c.
der Code aus ide.c: ~~~~~ 3670,3678 int ide_register_subdriver (ide_drive_t *drive, ide_driver_t *driver, int version) { unsigned long flags; int enable_dma = 1;
#ifdef CONFIG_IDEDMA_ONLYDISK if (drive->media != ide_disk) enable_dma = 0; #endif ~~~~~
Du hast leider ueberhaupt keinen Kernel-Oops gepostet, der hier recht interessant waere. In dem zitierten Thread wird behauptet, das der SuSE-SMP Kernel nicht mit CDROM-Laufwerken im DMA-Modus funktionieren will. Ist es moeglich, das du den SMP-Kernel installiert hast, und der uebersetzte Kernel ein Uniprozessor Kernel ist?
Nein ich hab das Problem gerade nochmal nachgestellt hatte den alten Kernel noch drauf, benutze mittlerweile erfolgreich den 2.4.20 Mantel-Kernel. Der BTTV-Treiber verursachte bei laufendem TV wenn Daten kopiert wurden (auch updatedb cron.daily) sehr heftige Abstürze.
Allerdings kann es sein, das du den Oops von Hand abschreiben musst, da der Kernel je nach Fehler alle Schreibzugriffe auf die Festplatten, die ja bei dir wahrscheinlich auch IDE-Laufwerke sind sperrt.
Ja so ist es leider. Wenn dich das wirklich brennend interessiert dann schreib ich mir das auch ab und tippe es wieder ein und schick es dir. Er versucht eine CD zu mounten, hängt sich dann aber nach ca. 10-15 Sekunden auf, zuerst Interrupt-Fehlermeldungen dann Kernel Panic. meiner meinung nach ist aber das Problem behoben und 2.4.18-4GB ist auch nicht mehr der neueste Kernel ! Nichts für ungut. Gruss Patrick
Patrick Klaus wrote:
Nein ich hab das Problem gerade nochmal nachgestellt hatte den alten Kernel noch drauf, benutze mittlerweile erfolgreich den 2.4.20 Mantel-Kernel. Der BTTV-Treiber verursachte bei laufendem TV wenn Daten kopiert wurden (auch updatedb cron.daily) sehr heftige Abstürze.
Lass mich raten. VIA Chipsatz auf dem Mainboard? Der Southbridge-Chip VT82C686A/B hat Probleme wenn hohe Last auf dem PCI-Bus herrscht. Eine TV-Wiedergabe sorgt dafuer. Es kann dann alles passieren. Beliebtes Beispiel ist die Sound-Ausgabe mit einer SB-Live und gleichzeitigem Datentransfer auf eine UDMA-Festplatte. Die uebertragenen Daten werden teilweise zerstoert. Kann gut sein, das ein neuerer Kernel einen Bugfix enthaelt, so das der PCI-Bus anders belastet wird. Peter
Peter Wiersig wrote:
[...] Lass mich raten. VIA Chipsatz auf dem Mainboard? Der Southbridge-Chip VT82C686A/B hat Probleme wenn hohe Last auf dem PCI-Bus herrscht. Eine TV-Wiedergabe sorgt dafuer. [...] Kann gut sein, das ein neuerer Kernel einen Bugfix enthaelt, so das der PCI-Bus anders belastet wird.
Fuer den Bug gibt es schon laenger einen Work- around im Kernel... CU, Th. -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH)
Peter Wiersig schrieb:
Patrick Klaus wrote:
Nein ich hab das Problem gerade nochmal nachgestellt hatte den alten Kernel noch drauf, benutze mittlerweile erfolgreich den 2.4.20 Mantel-Kernel. Der BTTV-Treiber verursachte bei laufendem TV wenn Daten kopiert wurden (auch updatedb cron.daily) sehr heftige Abstürze.
Lass mich raten. VIA Chipsatz auf dem Mainboard? Der Southbridge-Chip VT82C686A/B hat Probleme wenn hohe Last auf dem PCI-Bus herrscht. Eine TV-Wiedergabe sorgt dafuer.
Ich glaube die Probleme gab es damals bei VIA KT133 und KT133A oder ? Nicht ganz ! Ich hab KT266 und KT266A bridge VIA VT8367 [KT266 AGP] bridge VIA VT8233 PCI to ISA Bridge Gruss Patrick
Patrick Klaus wrote:
Peter Wiersig schrieb:
Lass mich raten. VIA Chipsatz auf dem Mainboard?
Ich glaube die Probleme gab es damals bei VIA KT133 und KT133A oder ?
Ja, die hatte ich im Hinterkopf. Haben mich selbst erwischt und staendig das FAT32-Root-Verzeichnis bytemaessig vermischt. Die zweite FAT war meist ok, manchmal aber auch nicht mal die. Dann hiess es immer aus "DIR0000" bis "DIR00015" wieder "Programme", "Windows", etc. zu machen. Viel Arbeit, die nicht sein muss.
Ich hab KT266 und KT266A
Tja, George Breese ist der Ansicht, das der Chipsatz auch betroffen sein koennte: http://www.georgebreese.com/net/software/readmes/faqvl019.htm Ich hab jedenfalls nach dem Einspielen des "VIA PCI Latency" Patch unter Windows keine Probleme mehr. Moeglicherweise ist der Bug auf neueren Boards nicht so gravierend, aber die Ursache deiner Abstuerze koennte durchaus im Chipsatz begruendet sein. Peter
participants (4)
-
Patrick Klaus -
Peter Wiersig -
Rafael -
Thomas Hertweck