# Kernel ohne APIC

## .:cODerED:.

hi,

ich hab leider ein kleines Problem. Mein System (nforce2) stürzt sehr oft ab und nun hab ich irgend wo gelesen, das ich den kernel mal ohne APIC kompilieren soll. Angeblich soll man CONFIG_X86_LOCAL_APIC und CONFIG_X86_IO_APIC ausschalten. So nun mein Problem.

Ich öffne meine .config und setzt diese zwei Werte von Hand auf "n". Aber irgend wie werden die beim kompilieren per default wieder auf "y" gesetzt. Kann das sein ? Wie mach ich das denn richtig ?

mfg

.:cODerED:.

----------

## cng

hallo .:cODerED:.

hast du das auch im bios deaktiviert? da giebt es irgendwo eine option.

gruss

michael

----------

## .:cODerED:.

Ja ich hab das im BIOS schon deaktiviert. Scheint aber nix zu bewirken  :Sad: 

Wieso wird das denn in der .config automatisch wieder umgestellt wenn ich den kernel kompilieren will und wie verhindere ich das ? Ich weiß ja nicht ob's was bringt, aber ein Versuch ist es wert. Ich muss dazu sagen, dass ich meine CPU 2500+ auf 3200+ übertaktet habe und mein System unter Windows auch ohne Probleme läuft.  Früher lief es auch mit Linux (2.6.x) ohne Probleme so. Ist den irgend was grundlegendes am Kernel verändert worder, ich versteh das irgend wie nicht. Wo finde ich denn eine Übersicht über die Patches die es für den Kernel gibt ?

mfg

.:cODerED:.

----------

## Basti_litho

Achte drauf, dass alle alten .config's weg sind (zb. unter /boot und eben /usr/src/).

Ich hab das schon ein paar mal (war zwar beim suse rechner - aber da es ein "vanilla" Kernel war, spielt es imho keine rolle) erlebt - das der Kernel (falls vorhanden) eine .config aus /boot genommen hat. Warum? Das wüsste ich auch gerne - find die funktion eigentlich nicht besonders brauchbar.

----------

## boris64

falls es aus irgendwelchen gründen auch immer trotzdem noch nicht 

funktionieren sollte, probier mal einfach ein "noapic" am ende deiner 

grubkommandozeile, das sollte apic deaktivieren. dafür brauchste

dann auch nicht deinen kernel neu backen.

## linux standart 2.6

        title gentoo GNU/linux (2.6.5)

        root (hd0,0)

        kernel (hd0,0)/vmlinuz-2.6.5 root=/dev/hda3 vga=0x517 splash=verbose video=vesa:ywrap,mtrr hdc=ide-cd noapic

        initrd (hd0,0)/initrd

ich hatte übrigens mal genau das gleiche problem.

seit mein nforce2-board endgültig abgeraucht und durch ein board

mit viakt400-chipsatz ersetzt wurde, geht alles (auch apic, acpi, usw.) einwandfrei.

nforce und andere tolle nvidia-hardware ist imho einfach nur schrott (leider).

mein leitspruch zu dem thema: wegschmeissen, neukaufen.

----------

## .:cODerED:.

OK, danke.

Ich werd mal alle .config's löschen und sehen ob das was bringt. 

Ansonsten probier ich noch den Tip mit noapic aus, aber wegschmeißen werd ich es bestimmt nicht   :Laughing: 

Weiß denn auch jemand wo ich eine Übersicht über die verfügbaren kernelpatches finde.

Auf www.kernel.org blick ich irgend wie nicht durch.

----------

## piewie

Für funktionierendes APIC und nforce2 soll im Bios "CPU disconnect" deaktiviert werden.

----------

## .:cODerED:.

Hmm, "CPU disconnect" hab ich soweit ich weiß nicht in meinem BIOS.

Hab ein DFI Lanparty NFII ULTRA. Ich hab nur CPU Thermal-Throttling ist es das vielleicht? 

Kann die ganzen Sachen im Moment leider nicht ausprobieren, werde das heute Abend mal alles testen.

----------

## piewie

 *Quote:*   

> Ich hab nur CPU Thermal-Throttling ist es das vielleicht?

 

Nein.

----------

## sarahb523

@borisdigital

 *borisdigital wrote:*   

> 
> 
> ... standart ...
> 
> 

 

ich weiß jetzt nicht ob dein standarT ein "vertipper" war oder nich. Viele die ich kenne wissen(/wußten) nicht das man standard mit D am ende schreibt. Falls du weißt wie man standard schreib, vergiß dieses posting. 

ansonsten schönen sonnigen tag noch  :Smile: 

ciao

sarah

----------

## øxygen

 *.:cODerED:. wrote:*   

> hi,
> 
> Ich öffne meine .config und setzt diese zwei Werte von Hand auf "n". Aber irgend wie werden die beim kompilieren per default wieder auf "y" gesetzt. Kann das sein ? Wie mach ich das denn richtig ?
> 
> mfg
> ...

 

Was glaubst du, warum in der .config als zweite Zeile steht:

 *Quote:*   

> # Automatically generated make config: don't edit

 

Wenn du APIC abschalten willst, solltest du das über make menuconfig oder make xconfig machen

----------

## .:cODerED:.

Schön, so schlau war ich auch schon !!! 

Leider sind diese Einträge nicht zu finden oder nicht änderbar, wenn ich make menuconfig bzw.  make xconfig mache. Deshalb hab ich ja die Frage gestellt.

----------

## øxygen

Processor type and features  --->

[*] Local APIC support on uniprocessors

(v2.6.5-gentoo)

Processor type and features  --->

[*] Local APIC support on uniprocessors

[*] IO-APIC support on uniprocessors

(v2.4.26_pre6-gentoo)

----------

## .:cODerED:.

OK,

ich hätt vielleicht dazu schreiben sollen das ich die development-sources (2.6.4) hab 

und da wird das auf jeden Fall nicht angezeigt wenn ich make menuconfig mache. 

Muss ich eben mal die gentoo-dev-sources probieren. 

Weiß jemand wie das bei den mm-sources aussieht ?

----------

## PrakashP

[OT]

@borisdigital

Hast du mal den Speicherdurchsatz bei deinem KT400 gemessen (etwa 1/3 von single channel nforce2)? Oder den PCI Durchsatz? IMO sind VIA boards reiner Schrott. Hatte zwei Mal die Erfahrung gemacht uns seit dem kommt mir Via nicht mehr ins Gehäuse.

Der nforce2 ist schon sehr nett, nur ist Nvidia Haltung absolut besch...eiden, dh es gibt keinerlei Kommentar/hilfe von denen bzgl der APIC Problematik.

An den thread starter: Such mal in lkml nach nforce2 apic, ross dickson. Da findest du einen guten patch/work-around. Funkt bei mir astrein.

----------

## PrakashP

Naja, ich war mal so frei:

```

--- linux-2.6.0/arch/i386/kernel/apic.c   2003-12-18 12:59:58.000000000 +1000

+++ linux-2.6.0-rd/arch/i386/kernel/apic.c   2003-12-21 12:39:28.000000000 +1000

@@ -1070,10 +1070,17 @@ inline void smp_local_timer_interrupt(st

     * we can take more than 100K local irqs per second on a 100 MHz P5.

     */

 }

 

 /*

+ * Athlon nforce2 R.D.

+ * preset timer ack mode if desired

+ * e.g. static int apic_timerack = 2;

+*/

+static int apic_timerack;

+

+/*

  * Local APIC timer interrupt. This is the most natural way for doing

  * local interrupts, but local timer interrupts can be emulated by

  * broadcast interrupts too. [in case the hw doesn't support APIC timers]

  *

  * [ if a single-CPU system runs an SMP kernel then we call the local

@@ -1088,10 +1095,54 @@ void smp_apic_timer_interrupt(struct pt_

     * the NMI deadlock-detector uses this.

     */

    irq_stat[cpu].apic_timer_irqs++;

 

    /*

+   * Athlon nforce2 timer ack delay.  Ross Dickson.

+   * works around issue of hard lockups in code location

+   * where linux exposes underlying system timing fault?

+   * hopefully manufacturers will fix it soon.

+   * We leave C1 disconnect bit alone as bios/SMM wants?

+   */

+   if(apic_timerack) {

+      if(apic_timerack==1) {

+         /* v1 timer ack delay, inline delay version

+          * on AMDXP & nforce2 chipset we use at least 500ns

+         * try to scale delay time with cpu speed.

+         * safe all cpu cores?

+          */

+         ndelay((cpu_khz >> 12)+200); /* don't ack too soon or hard lockup */

+      } else {

+         static unsigned int passno, safecnt;

+         /* v2 timer ack delay, timeout version, more efficient

+          * on AMDXP & nforce2 chipset we need 800ns?

+          * from timer irq start to apic irq ack, read apic timer,

+         * may be unsafe for thoroughbred cores?

+          */

+         if(!passno) { /* calculate timing */

+            safecnt = apic_read(APIC_TMICT) -

+               ( (800UL * apic_read(APIC_TMICT) ) /

+               (1000000000UL/HZ) );

+            printk("..APIC TIMER ack delay, reload:%lu, safe:%u\n",

+               apic_read(APIC_TMICT), safecnt);

+            passno++;

+         }

+#if APIC_DEBUG

+         if(passno<12) {

+            unsigned int at1 = apic_read(APIC_TMCCT);

+            if( passno > 1 )

+               Dprintk("..APIC TIMER ack delay, predelay count:%u \n", at1 );

+            passno++;

+         }

+# endif

+         /* delay only if required */

+         while( apic_read(APIC_TMCCT) > safecnt )

+            ndelay(100);

+      }

+   }

+

+   /*

     * NOTE! We'd better ACK the irq immediately,

     * because timer handling can be slow.

     */

    ack_APIC_irq();

    /*

@@ -1157,10 +1208,28 @@ asmlinkage void smp_error_interrupt(void

            smp_processor_id(), v , v1);

    irq_exit();

 }

 

 /*

+* Athlon nforce2 timer ack delay. R.D.

+* kernel arg apic_tack=[012]

+* 0 off, 1 always delay, 2 timeout

+*/

+static int __init setup_apic_timerack(char *str)

+{

+   int tack;

+

+   get_option(&str, &tack);

+

+   if ( tack < 0 || tack > 2 )

+      return 0;

+   apic_timerack = tack;

+   return 1;

+}

+__setup("apic_tack=", setup_apic_timerack);

+

+/*

  * This initializes the IO-APIC and APIC hardware if this is

  * a UP kernel.

  */

 int __init APIC_init_uniprocessor (void)

 {

```

Als kernel boot Parameter apic_tack=2 anhängen, bzw apic_tack=1, wenn es immer noch lock_ups gibt.

----------

## boris64

 *sarahb523 wrote:*   

> @borisdigital
> 
>  *Quote:*   borisdigital hat folgendes geschrieben::
> 
> ... standart ... 
> ...

 

 :Embarassed:  au weia, du bist schon der zweite, der mir das mit dem standard/standart sagt.

nun ja, es ist ein vertipper, allerdings einer, der mir dauernd passiert

(da muss was in meiner kindheit gewesen sein)

hehe, *schäm*

 *PrakashKC wrote:*   

> Hast du mal den Speicherdurchsatz bei deinem KT400 gemessen (etwa 1/3 von single channel nforce2)? Oder den PCI Durchsatz?
> 
> 

 

hm, nein. hast du eventuell 'nen tip/link/tool parat, wie/womit ich das machen kann?

wäre für mich auch interessant, mal 'nen unterschied zu erfahren.

aber:

a)bei 3dspielen (wo das eigentlich interessant sein müsste, oder?!), gibts keinen fühlbaren unterschied. 

b) endlich läuft tvtime ohne stottern etc.

...

fazit: also eigentlich müsste ich dir da also widersprechen. der wohlfühlwert bei dem jetzigen viaboard (ein a7v8x-x) ist deutlich höher.

nunja, jedenfalls lasse ich mittlerweile von nvidiasachen die finger (allein 

deren aufkaufpolitik a la 3dfx ähnelt immer mehr der von m$  :Twisted Evil: ).

auch meine achsotolle geforce ti4200 werde ich bald durchbrechen.

früher, ja da war eh alles besser (meine lieben matrox grafikkarten,

allein wenn ich an die bildqualität denke werde ich ganz geil *seufz*)

 *PrakashKC wrote:*   

> IMO sind VIA boards reiner Schrott. Hatte zwei Mal die Erfahrung gemacht uns seit dem kommt mir Via nicht mehr ins Gehäuse.

 

nun ja, dass via nicht immer nur gute sachen produziert hat, will ich ja

gar nicht abstreiten (siehe via kt133a o.ä., da war ja einiges im busch).

----------

## PrakashP

Probier es mal mit memtest86. Liefert bei mir (im dual channel) etwa 1,5GB/s. Bei einem Bekannten (selbes board nur Geil Speicher statt Twinmos) gibt es 1GB/s. RAM wird als DDR400 betrieben.

Habe auch eine gf4 ti4200. Kann aber an deren Bildquali nicht klagen (betrieben an einem TFT). Hatte noch nie eine Matrox, darum wurden meine Augen evtl noch nie verwöhnt.  :Wink:  Nur Nvidia sollte mal deren Treiber fixen...der Treiber support von NVidia ist nicht so das Wahre...

Stottern und ähl hatte ich bis jetzt nur bei Via, Auch beim Bekannten mit KT400 ist der sound nur mit einem bestimmten Promise IDE Treiber unter Windows OK...  :Rolling Eyes:  Der PCI bus ist da immer noch bescheiden implementiert.

----------

## .:cODerED:.

Wie installiere ich den patch ???

----------

## boris64

 *.:cODerED:. wrote:*   

> Wie installiere ich den patch ???

 

so sollte es klappen:

1) sichere den code von PrakashKC in einer datei ab (z.b. $dein_speicherort/nforce2_apic.patch)

2) dann ab ins kernelquellenverzeichnis:

```
cd /usr/scr/linux && patch -p1 < $dein_speicherort/nforce2_apic.patch
```

3) dann wie gewohnt kernel konfigurieren und kompilieren

4) prost. ur abfreuen  :Wink: 

@PrakashKC

 *Quote:*   

> Probier es mal mit memtest86. Liefert bei mir (im dual channel) etwa 1,5GB/s. Bei einem Bekannten (selbes board nur Geil Speicher statt Twinmos) gibt es 1GB/s. RAM wird als DDR400 betrieben.

 

dual-channel? (war das die sache mit den 2 gleichen ram-modulen?)

memtest habe ich ja sogar schon installiert, ergebnis wird bei zeiten nachgeliefert.

(leider habe ich nur DDR333er ram-module, aber ich gebe mich noch nicht geschlagen  :Wink: )

----------

## PrakashP

@.:cODerED:.

Nach dem kernel installieren den kernel Paramter nicht vergessen bei grub/lilo einzutragen!

@borisdigital

Yup, dual channel. Bringt zwar theor wenig, da ein Athlon XP schon durch einen Riegel bandbreitenlimieteirt ist, bzw das interface packt nicht mehr, aber denochzeigen sich ja bei synth. benchmarks bis zu 50% Verbesserung und im Alltagsleben (je nach Anwendung) 5-20%. (letzteres eher so bei Graphik/Video Sachen).

----------

## PrakashP

Evtl wäre ncoh folg patch - frisch von lkml - interessant. Ich brauche den zwar nciht unbedingt, aber ein paar nforce2 Nutzer schon. Der patch stammt von Len Brown, der Mensch, der ACPI (nicht APIC, aber hängt wohl zusammen) maintained.

```

===== Documentation/kernel-parameters.txt 1.44 vs edited =====

--- 1.44/Documentation/kernel-parameters.txt   Mon Mar 22 16:03:22 2004

+++ edited/Documentation/kernel-parameters.txt   Tue Apr 13 17:47:11 2004

@@ -122,6 +122,10 @@

 

    acpi_serialize   [HW,ACPI] force serialization of AML methods

 

+   acpi_skip_timer_override [HW,ACPI]]

+         Recognize IRQ0/pin2 Interrupt Source Override

+         and ignore it -- for broken nForce2 BIOS.

+

    ad1816=      [HW,OSS]

          Format: <io>,<irq>,<dma>,<dma2>

          See also Documentation/sound/oss/AD1816.

===== arch/i386/kernel/setup.c 1.115 vs edited =====

--- 1.115/arch/i386/kernel/setup.c   Fri Apr  2 07:21:43 2004

+++ edited/arch/i386/kernel/setup.c   Tue Apr 13 17:41:31 2004

@@ -614,6 +614,12 @@

       else if (!memcmp(from, "acpi_sci=low", 12))

          acpi_sci_flags.polarity = 3;

 

+      else if (!memcmp(from, "acpi_skip_timer_override", 24)) {

+         extern int acpi_skip_timer_override;

+

+         acpi_skip_timer_override = 1;

+      }

+

 #ifdef CONFIG_X86_LOCAL_APIC

       /* disable IO-APIC */

       else if (!memcmp(from, "noapic", 6))

===== arch/i386/kernel/acpi/boot.c 1.57 vs edited =====

--- 1.57/arch/i386/kernel/acpi/boot.c   Tue Mar 30 17:05:19 2004

+++ edited/arch/i386/kernel/acpi/boot.c   Tue Apr 13 17:50:14 2004

@@ -62,6 +62,7 @@

 

 acpi_interrupt_flags acpi_sci_flags __initdata;

 int acpi_sci_override_gsi __initdata;

+int acpi_skip_timer_override __initdata;

 

 #ifdef CONFIG_X86_LOCAL_APIC

 static u64 acpi_lapic_addr __initdata = APIC_DEFAULT_PHYS_BASE;

@@ -327,6 +328,12 @@

       acpi_sci_ioapic_setup(intsrc->global_irq,

          intsrc->flags.polarity, intsrc->flags.trigger);

       return 0;

+   }

+

+   if (acpi_skip_timer_override &&

+      intsrc->bus_irq == 0 && intsrc->global_irq == 2) {

+         printk(PREFIX "BIOS IRQ0 pin2 override ignored.\n");

+         return 0;

    }

 

    mp_override_legacy_irq (

===== Documentation/kernel-parameters.txt 1.44 vs edited =====

--- 1.44/Documentation/kernel-parameters.txt   Mon Mar 22 16:03:22 2004

+++ edited/Documentation/kernel-parameters.txt   Tue Apr 13 17:47:11 2004

@@ -122,6 +122,10 @@

 

    acpi_serialize   [HW,ACPI] force serialization of AML methods

 

+   acpi_skip_timer_override [HW,ACPI]]

+         Recognize IRQ0/pin2 Interrupt Source Override

+         and ignore it -- for broken nForce2 BIOS.

+

    ad1816=      [HW,OSS]

          Format: <io>,<irq>,<dma>,<dma2>

          See also Documentation/sound/oss/AD1816.

===== arch/i386/kernel/setup.c 1.115 vs edited =====

--- 1.115/arch/i386/kernel/setup.c   Fri Apr  2 07:21:43 2004

+++ edited/arch/i386/kernel/setup.c   Tue Apr 13 17:41:31 2004

@@ -614,6 +614,12 @@

       else if (!memcmp(from, "acpi_sci=low", 12))

          acpi_sci_flags.polarity = 3;

 

+      else if (!memcmp(from, "acpi_skip_timer_override", 24)) {

+         extern int acpi_skip_timer_override;

+

+         acpi_skip_timer_override = 1;

+      }

+

 #ifdef CONFIG_X86_LOCAL_APIC

       /* disable IO-APIC */

       else if (!memcmp(from, "noapic", 6))

===== arch/i386/kernel/acpi/boot.c 1.57 vs edited =====

--- 1.57/arch/i386/kernel/acpi/boot.c   Tue Mar 30 17:05:19 2004

+++ edited/arch/i386/kernel/acpi/boot.c   Tue Apr 13 17:50:14 2004

@@ -62,6 +62,7 @@

 

 acpi_interrupt_flags acpi_sci_flags __initdata;

 int acpi_sci_override_gsi __initdata;

+int acpi_skip_timer_override __initdata;

 

 #ifdef CONFIG_X86_LOCAL_APIC

 static u64 acpi_lapic_addr __initdata = APIC_DEFAULT_PHYS_BASE;

@@ -327,6 +328,12 @@

       acpi_sci_ioapic_setup(intsrc->global_irq,

          intsrc->flags.polarity, intsrc->flags.trigger);

       return 0;

+   }

+

+   if (acpi_skip_timer_override &&

+      intsrc->bus_irq == 0 && intsrc->global_irq == 2) {

+         printk(PREFIX "BIOS IRQ0 pin2 override ignored.\n");

+         return 0;

    }

 

    mp_override_legacy_irq (

```

Zur Aktivierung bedarf es des kernel Parameters: acpi_skip_timer_override

----------

## .:cODerED:.

OK, danke. 

Ich werd die patches mal ausprobieren.

----------

## ohoiza

ich hätte auch noch einen patch anzubieten:

```

 [x86] fix lockups with APIC support on nForce2

Add PCI quirk to disable Halt Disconnect and Stop Grant Disconnect

(based on athcool program by Osamu Kayasono).

Spotted by Prakash K. Cheemplavam <prakashpublic@gmx.de>

and Mathieu <cheuche+lkml@free.fr>.

--- linux-2.6.5-love4/arch/i386/pci/fixup.c~nforce2-disconnect-quirk    2004-04-16 19:07:20.506465216 +0200

+++ linux-2.6.5-love4/arch/i386/pci/fixup.c     2004-04-12 20:49:29.000000000 +0200

@@ -187,6 +187,22 @@ static void __devinit pci_fixup_transpar

                dev->transparent = 1;

 }

+/*

+ * Halt Disconnect and Stop Grant Disconnect (bit 4 at offset 0x6F)

+ * must be disabled when APIC is used (or lockups will happen).

+ */

+static void __devinit pci_fixup_nforce2_disconnect(struct pci_dev *d)

+{

+       u8 t;

+

+       pci_read_config_byte(d, 0x6F, &t);

+       if (t & 0x10) {

+               printk(KERN_INFO "PCI: disabling nForce2 Halt Disconnect"

+                                " and Stop Grant Disconnect\n");

+               pci_write_config_byte(d, 0x6F, (t & 0xef));

+       }

+}

+

 struct pci_fixup pcibios_fixups[] = {

        {

                .pass           = PCI_FIXUP_HEADER,

@@ -290,5 +306,11 @@ struct pci_fixup pcibios_fixups[] = {

                .device         = PCI_ANY_ID,

                .hook           = pci_fixup_transparent_bridge

        },

+       {

+               .pass           = PCI_FIXUP_HEADER,

+                .vendor         = PCI_VENDOR_ID_NVIDIA,

+                .device         = PCI_DEVICE_ID_NVIDIA_NFORCE2,

+                .hook           = pci_fixup_nforce2_disconnect,

+       },

        { .pass = 0 }

 };

```

er behebt den halt disconnect bug - seit ich ihn verwende, läuft mein nforce2-system stabil mit acpi-unterstützung.

ich hoffe, er lässt sich anwenden, ich hab nämlich versucht, ihn ein bisschen "auf den neuesten stand zu bringen", da sich die syntax von fixup.c seit 2.6.0 anscheinend verändert hat...

----------

## PrakashP

@ohoiza

Nein, der patch ist "obsolete". Der behebt den disconnect bug nicht, sondern schaltet disconnect einfach aus, was zu höheren CPU Temps führt. Der patch ist zwar am sichersten, aber auch am wenigsten sinnvoll, darum wurde er aus dem kernel wieder entfernt. Den ersten patch, den ich hier gepostet habe ist am meisten getestet und am sionvollsten. Ansonsten gäbe es ncoh den C1halt patch, ebenfalls von Ross Dickson.

----------

## ohoiza

 *Quote:*   

> (...) was zu höheren CPU Temps führt.

 

 :Shocked:  danke, dass du mich darauf hinweist, in zukunft nehm ich den patch her, den du gepostet hast

----------

## PrakashP

So, der richtige nforce2 fix für APIC+CPU Disconnetc Instabilität wurde vor kurzem auf lkml veröffentlicht. Ich verweise auf

https://forums.gentoo.org/viewtopic.php?t=169004

Nichtdestotortz wird Len's acpi_skip_timer_override patch, den ich auch hier gepostet habe, benötigt, um den bug mit dem timer zu fixen. Dieser fix wird aber in 2.6.6 einfließen und ist bereits in aktuellen mm kernels enthalten.

Man sollte allerdigns ACPI und APIC aktivieren, sonst ist es eh egal.

@borisdigital

Ich warte noch auf die kt Durchsatzwerte.  :Smile: 

----------

## boris64

@PrakashKC

hehe  :Wink: 

du kennst das doch sicherlich: aus den augen, aus dem sinn

also, meine chipdurchsatzwerte laut memtest86 v3.0-r2:

652mb/s

die hardware, die da reinspielen sollte, ist folgende:

asus av78x-x, viakt400

athlonxp2004+

512mb noname speicher (läuft mit 333mhz)

hast du vielleicht vergleichswerte am start (mit hardware am besten?) 

ausserdem ist denn so ein test überhaupt aussagekräftig (ohne geladenen treiber etc.)?

falls ja, so ist dein nforce2-chipsatz 'ne ganze ecke schneller, wenn ich 

allerdings an die ganze patcherei und flickschusterei denke, bin ich froh,

kein nforce2-board mehr zu haben (aber das thema hatten wir ja schon, gelle;))

um mich noch ein wenig zu verteidigen:

ich denke, der kt400- und nforce2-chipsatz sind nicht wirklich vergleichbar.

da sollte man wohl eher schon nen neueren wie kt600 oder kt800 zur rate ziehen  :Smile: 

----------

## PrakashP

 *Quote:*   

> ausserdem ist denn so ein test überhaupt aussagekräftig (ohne geladenen treiber etc.)? 

 

Naja, man könnte ja ein einfaches c Programm schreiben, welche etwa 400MB alloziert und diese beschreibt und ausliest. Zum Vergleich sollten die CPU Geschw. dieselben sein, wie auch der compiler (und flags). Dann ließen sich Praxiswerte ermitteln. Außrdem  - um jetzt mein Sys gegen deines zu vergleichen - müßte ich einen RAM Riegel rausrupfen (wegen DC Anbindung) und auf 333 runtertakten...

Bzgl bugs: Naja, der übelste nforce2 bugs wurde ja endlich soeben gefixt. Der kt hat auch so seine Pappenheimer in der Linuxwelt, nur sind die nicht so auffällig. Geht bei dir APIC+ACPI problemlos?

Vergleichbar ist der nforce2 allerhöchstens zum kt600, weil dei etwa gleich alt sind. Der kt800 ist Vias kläglicher Versuch am nforce2 vorbeizuziehen, der bei den Serienboards gescheitert ist.  :Wink: 

Ich bin jedenfalls bis auf Kleinigkeiten nun mit dem nforce2 vollkommen zufrieden.  :Smile: 

Der andere Vorteil in der Linuxwelt ist zur Zeit auch, daß man mit dem nforce2 am ehesten stabile hohe performance mit Nvidia Karten bekommt. Ati's Treiber sind nicht der hit, besonders was performance angeht. Und die binary Treiber sind mit dem 2.6er recht instabil in Kombination mit agpgart. Mit dem Nvidia eigenen AGP ist es recht (wenn auch noch nicht 100%) stabil, und Nvidias AGP - wenn wunderts - funkt am besten mit dem nforce2. Solange man den AGP aber nicht benutzt hat man 100% Stabilität.

----------

## boris64

 *PrakashKC wrote:*   

> Geht bei dir APIC+ACPI problemlos?

 

ja(!), ohne patches und diverse einstellungen.

 *PrakashKC wrote:*   

> Ich bin jedenfalls bis auf Kleinigkeiten nun mit dem nforce2 vollkommen zufrieden.  

 

hehe, das ist wie mit der geschichte, welche desktopumgebung man bevorzugt,

da kann man sich gegenseitig die köpfe einschlagen, ergebnis ist grundsätzlich gleich null.

sprich-> auch ich bin (oh wunder) mehr als zufrieden  :Wink: 

 *PrakashKC wrote:*   

> ...
> 
> Mit dem Nvidia eigenen AGP ist es recht (wenn auch noch nicht 100%) stabil, und Nvidias AGP - wenn wunderts - funkt am besten mit dem nforce2. Solange man den AGP aber nicht benutzt hat man 100% Stabilität.

 

wo du das erwähnst, ich habe auch eine nvidia-graka und bei mir läuft nvgart 

zusammen mit dem kt-board nicht stabil. ich nutze jetzt den "normalen" 

agpgart, und damit hatte ich bisher kein einziges problem..

mit dem nforceboard war das genau andersherum.

mfg,

----------

## PrakashP

Naja einige fahren mit nem gedrosselten pflegeleichten Roller (->kt400), andere nehmen 'ne richtige Maschine, mit einigen Kinderkrankheiten (->nforce2). SCNR  :Wink: 

Zwar kein wirklicher Vergleich, aber wie ich festgestellt habe mehr von der RAM Geschw. abhängig als CPU (Sprung vom KT133=SDRAM zum nforce2=DC DDRAM, etwa  Faktor 3, obwohl CPU nur etwa 55% schneller war): Aber wie lange dauert bei dir etwas das Überstetzen des 2.6er kernels? Bei mir etwa 4min, wenn ich mich recht entsinne (mit alsa, dvb, sensers und allem was das mobo so kann, außer firewire, usb2.0, parallel port)...Ok ist unfair, weil ich den gcc-3.4 benutze  :Wink: .Last edited by PrakashP on Tue May 04, 2004 3:14 pm; edited 1 time in total

----------

## boris64

 *Quote:*   

> Aber wie lange dauert bei dir etwas das Überstetzen des 2.6er kernels? Bei mir etwa 4min, wenn ich mich recht entsinne (mit alsa, dvb, sensers und allem was das mobo so kann, außer firewire, usb2.0, parallel port)...Ok ist unfair, weil ich den gcc-3.4 benutze .

 

uff, tja, ähm.

naja, ich gucke immer nebenbei dvd oder tv via tvkarte und vergesse die zeit.

ausserdem habe ich quasi jeden müll als modul im kernel dabei,

ich glaube, ein wirklicher vergleich ist da eben schlecht möglich  :Wink: 

----------

