Hallo zusammen, Frage: Hat irgend jemand Linux auf einem Motherboard mit KT133A- oder KT266-chipsatz von VIA laufen? Wenn ja, würde mich interessieren, wie es mit der Unterstützung, vor allem des DMA (Festplatte/Brenner) steht. Mich würde dazu der Inhalt von /proc/pci (Chipsatz-Eintrag), die Ausgabe von `hdparm -d /dev/hda' (DMA-Einstellung) und die kernel version (/proc/version) interessieren. Es ist auch möglich, zu versuchen, den DMA erst mal einzuschalten (bringt normalerweise Geschwindigkeitszuwachs): hdparm -d 1 /dev/hda Danke, Wolly -- Some operating systems are called "user friendly". Linux, however, is "expert friendly".
Hallo, es waere schoen, wenn Du Deinen Realnamen angeben wuerdest, das wird in dieser Liste als hoeflich empfunden.... Wolly wrote:
Frage: Hat irgend jemand Linux auf einem Motherboard mit KT133A- oder KT266-chipsatz von VIA laufen?
Ersteres vermutlich relativ viele, letzteres vermutlich (noch) nicht ganz so viele. Ausserdem sollte man auf alle Faelle auf KT266A warten, wenn man demnaechst ein Board mit diesem Chipsatz anschaffen moechte. Der wird in naechster Zeit auf die Motherboards verbaut werden. Er soll deutlich bessere Werte liefern als der KT266.... (laut diversen Hardware-Seiten im INet).
Wenn ja, würde mich interessieren, wie es mit der Unterstützung, vor allem des DMA (Festplatte/Brenner) steht.
Keine Probleme mit Asus A7V133, VIA KT133A. Mal abgesehen vom bekannten VIA Bug in der Southbridge *686A, der sich bei mir aber noch nie gezeigt hat (BIOS Updates etc. sind allerdings auch ein- gespielt). Der Brenner (Plextor) funktioniert einwandfrei (mit ide-scsi).
Mich würde dazu der Inhalt von /proc/pci (Chipsatz-Eintrag), die Ausgabe von `hdparm -d /dev/hda' (DMA-Einstellung) und die kernel version (/proc/version) interessieren.
Ich weiss nicht, was ersteres Dir liefern soll, der Chipsatz wird erkannt. Die Ausgabe von hdparm liefert logischerweise, da ich DMA nutze, ein "using_dma = 1 (on)", mein Kernel ist Version 2.4.4-SuSE12, das ganze auf einer SuSE 7.1. Fuer den CD-Brenner/ DVD Laufwerk steht ebenfalls "using_dma = 1 (on)". Da ich nicht genau weiss, was Dir die o.a. Angaben bringen sollen, hier vielleicht noch eine etwas bedeutendere Ausgabe von hdparm: "hdparm -t /dev/hda" liefert 38.55 MB/sec. Bei mir haengt da eine IBM 60GB Platte, 7200rpm, 1916KB Cache, UDMA100 dran. Relevante Ausgabe von "dmesg": %% VIA Southbridge VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:04.1 %% Promise Controller PDC20265: IDE controller on PCI bus 00 dev 88 PDC20265: chipset revision 2 HTH, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, University of Karlsruhe Hertzstr. 16, D-76187 Karlsruhe, Germany
Hallo zusammen, Am 01/09/10@18:52 schrieb Thomas Hertweck:
Relevante Ausgabe von "dmesg": %% VIA Southbridge VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:04.1 %% Promise Controller PDC20265: IDE controller on PCI bus 00 dev 88 PDC20265: chipset revision 2
Nutzt Du auf der Platte auch reisferfs 3.5.29? Kannst Du darauf Dateien mit Umlauten erstellen und wirst Du die auch wieder los? Falls nicht, was sagt ls -l auf so einem Verzeichnis? -- :wq-y Maik
Hallo Maik, Maik Holtkamp wrote:
Am 01/09/10@18:52 schrieb Thomas Hertweck:
Relevante Ausgabe von "dmesg": %% VIA Southbridge VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:04.1 %% Promise Controller PDC20265: IDE controller on PCI bus 00 dev 88 PDC20265: chipset revision 2
Nutzt Du auf der Platte auch reisferfs 3.5.29?
Also, die erste Platte haengt am VIA Controller, ide0. Das ist eine IBM Platte, mehrere Partitionen, ReiserFS ist Version 3.6.25, einige Partitionen sind allerdings im 3.5.x Disk Format gemountet. Eine andere Platte (aeltere IBM 6GB Platte) haengt am Promise Controller, auch dort ist ReiserFS Version 3.6.25 im Einsatz.....
Kannst Du darauf Dateien mit Umlauten erstellen und wirst Du die auch wieder los?
Also, ich benutze aus Prinzip eigentlich nie Umlaute in Verzeichnis- oder Dateinamen (das waere auch etwas umstaendlich, da ich manchmal eine engl. Tastatur benutze :-). Habe es hier nun trotzdem mal pro- biert (als root auf einer mit ReiserFS formatierten Partition, ge- mountet im 3.5.x Disk Format, Promise Controller): root@einstein:/scratch > mkdir übung root@einstein:/scratch > ls -l drwxr-xr-x 2 root root 35 Sep 10 23:29 übung root@einstein:/scratch > touch übung/übel.txt root@einstein:/scratch > ls -l übung/ -rw-r--r-- 1 root root 0 Sep 10 23:32 übel.txt root@einstein:/scratch > rm übung/übel.txt root@einstein:/scratch > ls -l übung/ insgesamt 0 root@einstein:/scratch > rmdir übung/ und weg ist das Verzeichnis übung.... Bei der Platte, die am VIA Controller haengt, ist das genauso, ich habs getestet. Auf was moechtest Du eigentlich raus? Gibt es Probleme mit der ReiserFS Version 3.5.29? CU, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, University of Karlsruhe Hertzstr. 16, D-76187 Karlsruhe, Germany
Hallo Thomas, Am 01/09/10@23:39 schrieb Thomas Hertweck:
Hallo Maik,
Maik Holtkamp wrote:
Am 01/09/10@18:52 schrieb Thomas Hertweck:
Relevante Ausgabe von "dmesg": %% VIA Southbridge VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:04.1 %% Promise Controller PDC20265: IDE controller on PCI bus 00 dev 88 PDC20265: chipset revision 2
Nutzt Du auf der Platte auch reisferfs 3.5.29?
Auf was moechtest Du eigentlich raus? Gibt es Probleme mit der ReiserFS Version 3.5.29?
Ich habe Probleme damit Dateien mit Umlauten zu löschen in einer sehr ähnlichen Config (am Promise) und dachte es wäre eine allgemeines Problem. Nachdem ich erst dachte meine Platte wäre defekt und ich eine neue beschafft hatte, ist das Problem immer noch geblieben. Aus meiner lokalen lug bekam ich dann einen besonderen Code der das Problem fixen sollte es aber nicht tat. Mit dem Code und dem entsprechenden strace (sowie strace ls) habe ich mich an die reiser Liste gewendet von wo folgende Antwort kam (gestern Abend): ---schnipp---
$ ls ls: LINUX Wegweiser f?r Netzwerker.desktop: No such file or directory ls: Firewall Handbuch f?r LINUX 2.0 und 2.2.desktop: No such file or directory
I guess that you went into known problem. Could you please run the modified version of your delete.c and let me know what does it print out? Thanks, vs ---schnapp--- Leider hat die modifizierte Version die beilag das Problem auch nicht fixen können :(. Da Vladimir aber vom "known problem" schrieb umd Du eine so ähnliche Config benutzt, dachte ich, wenn Dich das auch betroffen hätte, hätte ich das Problem schon mal etwas stärker eingrenzen können (vielleicht nur Promise Controler). Aber so :(. Trotzdem Danke. BTW: Die obigen ? liegen an der mail Zeichensatzkonvertierung. BTW2: Obwohl ich obigen Files selber angelegt habe (Bookmarks), brauchts das gar nicht um "Umlaut-files" auf der Platte zu haben. Das Verzeichnis /usr/share/doc/sdb/de/html ist voll von solchen Dateien (alle das gleiche Problem, obwohl andere Partition) :(. -- :wq-y Maik
Maik Holtkamp wrote:
Am 01/09/10@23:39 schrieb Thomas Hertweck:
[...] Auf was moechtest Du eigentlich raus? Gibt es Probleme mit der ReiserFS Version 3.5.29?
Ich habe Probleme damit Dateien mit Umlauten zu löschen in einer sehr ähnlichen Config (am Promise) und dachte es wäre eine allgemeines Problem.
Wie ich in der anderen Mail schrieb, ist hier ReiserFS Version 3.6.25 am Werkeln, nicht 3.5.29.... - hast Du es mal mit einer anderen ReiserFS Version bei Dir probiert?
[...] Leider hat die modifizierte Version die beilag das Problem auch nicht fixen können :(. Da Vladimir aber vom "known problem" schrieb umd Du eine so ähnliche Config benutzt, dachte ich, wenn Dich das auch betroffen hätte, hätte ich das Problem schon mal etwas stärker eingrenzen können (vielleicht nur Promise Controler). Aber so :(.
Also, das Problem ist bei mir noch nicht aufgetaucht. Du vermutest stark, dass das Problem wirklich von ReiserFS kommt. Kannst Du an- dere Ursachen (was auch immer die sein koennten) ausschliessen? Welchen Kernel setzt Du eigentlich ein? Ich denke, das Ganze koennte sich mit einem Kernel-Patch bzw. Kernel-Update beheben lassen. Auf alle Faelle scheinst Du nicht alleine zu sein, lies mal den folgenden Thread, vielleicht hilft Dir das ja weiter: http://lists.omnipotent.net/reiserfs/200107/msg00254.html Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, Karlsruhe University (TH) Hertzstr. 16, D-76187 Karlsruhe, Germany
Am 01/09/11@09:24 schrieb Thomas Hertweck:
Maik Holtkamp wrote:
Am 01/09/10@23:39 schrieb Thomas Hertweck:
[...] Auf was moechtest Du eigentlich raus? Gibt es Probleme mit der ReiserFS Version 3.5.29?
Ich habe Probleme damit Dateien mit Umlauten zu löschen in einer sehr ähnlichen Config (am Promise) und dachte es wäre eine allgemeines Problem.
Also, das Problem ist bei mir noch nicht aufgetaucht. Du vermutest stark, dass das Problem wirklich von ReiserFS kommt. Kannst Du an- dere Ursachen (was auch immer die sein koennten) ausschliessen? Welchen Kernel setzt Du eigentlich ein? Ich denke, das Ganze koennte sich mit einem Kernel-Patch bzw. Kernel-Update beheben lassen. Auf alle Faelle scheinst Du nicht alleine zu sein, lies mal den folgenden Thread, vielleicht hilft Dir das ja weiter: http://lists.omnipotent.net/reiserfs/200107/msg00254.html
Habe grad die Lösung bekommen: ---schnipp--- I guess that the problem is in your Suse kernel's fs/reiserfs/hashes.c. Do its hash functions have prototype like u32 r5_hash (const unsigned char *msg, int len)? I think if you will change them like this: u32 r5_hash (const signed char *msg, int len) everything will work. Files whose names contain "Umlaut" were created by hash function which accepted signed char *. Suse had a kernel (probably the one which contains ppc port) where they changed signed char * to unsigned char *. So, if you will change hash functions back to accept signed char *- you should be able to access those files. The only problem will be files with umlauts created by "wrong" kernel. I think you should find all those files under "correct" kernel and rename them to names without umlayuts under "wrong" kernel. Then you should boot proper kernel again and rename to original names under proper kernel. ---schnapp--- Ich habe mir grad mal die Quellen Unterschiede zwischen meinem alten 2.2.19 und dem neuen 2.4.6 angeschaut, die hashes.c unterscheiden sich so ähnlich wie oben beschrieben. Dann mit dem 2.2.19 gebootet (ja, hätte ich auch selber mal versuchen können;)) und dann läuft obiges Verfahren (umbenennen & zurück). -- :wq-y Maik
Verwende Abit KT7A (ohne RAID, bisher ohne BIOS-Update, KT133A) + Athlon 1000 C + 40 GB IBM-IDE. Das Zuschalten des Festplatten-DMA-Modus gelang auf Anhieb. In ganz seltenen Fällen [ meist zu häufiger Reboot - nicht lachen, mein fritz!usb krieg ich manuell verdammt schwer in Gang, erst ein Reboot läßt das Ding nach einem init 1 -> init 3 wieder wach werden ] wird DMA beim Booten disabled. Meistens aber läuft DMA offenbar fehlerfrei (seit acht Wochen). UND: der Geschwindigkeitsunterschied ist seeeeehr spürbar!!! Was DMA für ATAPI angeht: Hab' ich noch nicht probiert, sollt' ich vielleicht mal versuchen, aber speziell die SuSE-DVD wird auch ohne Spielereien rasend schnell eingespielt, mein LiteON brennt brav 12-fach mit XCDroast. Kann nicht klagen. BTW: Kann mal jemand erklären, wo ich in /proc/pci etwas zu DMA erfahre, danke! Hier die gewünschten Ausgaben: -------------------------------------------- # hdparm -d /dev/hda /dev/hda: using_dma = 1 (on) -------------------------------------------- # cat /proc/version Linux version 2.4.4-4GB (root@Pentium.suse.de) (gcc version 2.95.3 20010315 (SuSE)) #1 Wed May 16 00:37:55 GMT 2001 -------------------------------------------- # cat /proc/pci PCI devices found: Bus 0, device 0, function 0: Class 0600: PCI device 1106:0305 (rev 3). Master Capable. Latency=8. Prefetchable 32 bit memory at 0xd0000000 [0xd3ffffff]. Bus 0, device 1, function 0: Class 0604: PCI device 1106:8305 (rev 0). Master Capable. No bursts. Min Gnt=12. Bus 0, device 7, function 0: Class 0601: PCI device 1106:0686 (rev 64). Bus 0, device 7, function 1: Class 0101: PCI device 1106:0571 (rev 6). Master Capable. Latency=32. I/O at 0xd000 [0xd00f]. Bus 0, device 7, function 2: Class 0c03: PCI device 1106:3038 (rev 22). IRQ 9. Master Capable. Latency=32. I/O at 0xd400 [0xd41f]. Bus 0, device 7, function 3: Class 0c03: PCI device 1106:3038 (rev 22). IRQ 9. Master Capable. Latency=32. I/O at 0xd800 [0xd81f]. Bus 0, device 7, function 4: Class 0600: PCI device 1106:3057 (rev 64). IRQ 11. Bus 0, device 9, function 0: Class 0200: PCI device 10ec:8139 (rev 16). IRQ 10. Master Capable. Latency=32. Min Gnt=32.Max Lat=64. I/O at 0xdc00 [0xdcff]. Non-prefetchable 32 bit memory at 0xda001000 [0xda0010ff]. Bus 0, device 11, function 0: Class 0401: PCI device 1274:5880 (rev 2). IRQ 9. Master Capable. Latency=32. Min Gnt=12.Max Lat=128. I/O at 0xe000 [0xe03f]. Bus 0, device 13, function 0: Class 0100: PCI device 1de1:0391 (rev 1). IRQ 11. Master Capable. Latency=32. I/O at 0xe400 [0xe4ff]. Non-prefetchable 32 bit memory at 0xda000000 [0xda000fff]. Bus 1, device 0, function 0: Class 0300: PCI device 102b:0525 (rev 130). IRQ 5. Master Capable. Latency=64. Min Gnt=16.Max Lat=32. Prefetchable 32 bit memory at 0xd4000000 [0xd5ffffff]. Non-prefetchable 32 bit memory at 0xd6000000 [0xd6003fff]. Non-prefetchable 32 bit memory at 0xd7000000 [0xd77fffff]. ------------------------------------------------------------------------------- Wolly wrote:
Hallo zusammen,
Frage: Hat irgend jemand Linux auf einem Motherboard mit KT133A- oder KT266-chipsatz von VIA laufen? Wenn ja, würde mich interessieren, wie
From the keyboard of Wolly,
Hallo zusammen,
Frage: Hat irgend jemand Linux auf einem Motherboard mit KT133A- oder KT266-chipsatz von VIA laufen? Wenn ja, würde mich interessieren, wie es mit der Unterstützung, vor allem des DMA (Festplatte/Brenner) steht.
Jo, ist zwar nicht mein System läuft aber Linux drauf: IBM-DTLA-307045 40 GB VIA Technologies, Inc. VT8367 [KT266] von MSI
Mich würde dazu der Inhalt von /proc/pci (Chipsatz-Eintrag), die Ausgabe von `hdparm -d /dev/hda' (DMA-Einstellung) und die kernel version (/proc/version) interessieren. Es ist auch möglich, zu versuchen, den DMA erst mal einzuschalten (bringt normalerweise Geschwindigkeitszuwachs): hdparm -d 1 /dev/hda
Du bist aber neugierig ;) # uname -r 2.4.7 # hdparm -c -d /dev/hda /dev/hda: I/O support = 1 (32-bit) using_dma = 1 (on) # hdparm -t -T /dev/hda /dev/hda: Timing buffer-cache reads: 128 MB in 0.64 seconds =200.00 MB/sec Timing buffered disk reads: 64 MB in 1.77 seconds = 36.16 MB/sec Leider mußte ich gerade feststellen, das ich mit Kernel 2.4.9 folgendes erhalte: hdparm -d 1 /dev/hda /dev/hda: setting using_dma to 1 (on) HDIO_SET_DMA failed: Operation not permitted using_dma = 0 (off) Folgende Kerneloptionen habe ich bei 2.4.7 und 2.4.9 aktiviert: CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_BLK_DEV_ADMA=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_IDEDMA_PCI_WIP=y CONFIG_BLK_DEV_VIA82CXXX=y CONFIG_IDEDMA_AUTO=y CONFIG_BLK_DEV_IDE_MODES=y ?? bye Waldemar
participants (5)
-
Maik Holtkamp -
Thomas Abraham -
Thomas Hertweck -
Waldemar Brodkorb -
Wolly