Kernel 2.4.21 & redHat 9.0

[matop]

[matop]

hier die fehlermeldungen:

gcc -D__KERNEL__ -I/usr/src/linux-2.4.21/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=athlon -nostdinc -iwithprefix include -DKBUILD_BASENAME=sysctl_net_core -c -o sysctl_net_core.o sysctl_net_core.c
gcc -D__KERNEL__ -I/usr/src/linux-2.4.21/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=athlon -nostdinc -iwithprefix include -DKBUILD_BASENAME=dev -c -o dev.o dev.c
dev.c:605: redefinition of `dev_get_by_flags'
dev.c:561: `dev_get_by_flags' previously defined here
dev.c:627: redefinition of `__dev_get_by_flags'
dev.c:583: `__dev_get_by_flags' previously defined here
make[3]: *** [dev.o] Fehler 1
make[3]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/linux-2.4.21/net/core«
make[2]: *** [first_rule] Fehler 2
make[2]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/linux-2.4.21/net/core«
make[1]: *** [_subdir_core] Fehler 2
make[1]: Verlassen des Verzeichnisses Verzeichnis »/usr/src/linux-2.4.21/net«
make: *** [_dir_net] Fehler 2

[Balumir]

Hallo Matop,
ich mag mich ja täuschen. Aber heute morgen haben die noch bei damit geprahlt, wie schnell RedHat mit den Fixes war. Also muß da auch auf den Servern ein Update-RPM für den Kernel rumfliegen.
Und siehe . ist sogar eins.

Ich würde immer zuerst versuchen mit den Originalupdates weiter zu kommen. Die Distributionskernels sind inzwischen so ekelhaft gepatched, daß das ganze System auseinander fällt, wenn man auf einmal mit einem Original-Kernel anfangen will.

Warum mußt Du denn auf den 2.4.21 updaten?

Frank

[matop]

Weil ich ekelhafte kompilier probs ebenfalls mit den 2.4.20 redhat kernel hab... wobei der fehler beim 2.4.21 statisch zu sein scheint... zumindest bekomm ich beim 2.4.20 kompilieren immer andere fehler... ach alles f**k... wenn wenigstens mein brenner laufen würd... könnte ich mir heute noch ne slackware installieren... zumindest funzt da alles wenn auch nicht gleich auf anhieb wie ichs eigendlich von redhat gewohnt war... naja bis auf dieses prob

[Balumir]

Deswegen sag ich ja: Verwend einen RedHat Standardkernel.
Wenn Du dann noch "hdx=ide-scsi" beim Booten an den Kernel übergibst, sollte auch der Brenner reibungslos laufen.
Wobei mich wundert, daß die 9.0 den nicht sofort erkannt hat. Oder ist das ein DVD-Brenner?

Frank

[bernd]

[Balumir]

[matop]

[Balumir]

[matop]

[arnim]

Tach...


Ich weiss ja nicht was Du nun wieder für ne komische GeForce hast... ich hab:
lspci:
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 440 Go 64M] (rev a3)


less /etc/lilo.conf:
# Start LILO global section
lba32
append="hdc=ide-scsi"
boot = /dev/hda
prompt
# VESA framebuffer console @ 1024x768x256
vga = 773

Mach es doch so. Geht doch wunderprächtig.

Für X dann die NVidia Treiber von nvidia.com. I don´t know where the Problem ist?

Wieso, was willst Du überhaupt mit nem Framebuffer? Haben die Installationsroutienen nicht eh ihre eigenen Einstellungen? Weil, die werden zumeist ja von CD gestartet. Naja, und mehr als die Installatiosroutiene brauchst Du doch eh nicht *duck*
SCNR

Installiert doch Suse... die hat eine hübsche grafische Konsole, schon während der Installation?

Und schnell wech,
Gruss,
Arnim!

[arnim]

Öhm, suchst Du das hier:

make menuconfig:

Console drivers --->

Frame-buffer support --->

[*] Support for frame buffer devices (EXPERIMENTAL) x x
x x < > nVidia Riva support (EXPERIMENTAL) x x
x
[HELP]
x
This driver supports graphics boards with the nVidia Riva/Geforce chips.
Say Y if you have such a graphics board.
The driver is also available as a module ( = code which can be inserted and removed from the running kernel whenever you want). The module will be called rivafb.o. If you want to compile it as a module, say M here and read Documentation/modules.txt.

Isch habe diese Option nicht aktiviert.

Noch was anderes:
Wieso sabbelst Du jetzt von NVidia Framebuffer? Dein erstes Posting beschrieb ein Problem beim Kompilieren, mit irgendwelchen Netzwerk-Komponenten?
Dann war es der Brenner, nun der Framebuffer. Wenn Deine Installationen genau so durcheinander sind wie Deine Postings, ist es kein Wunder wenn nix läuft. Mach doch erstmal eins nach dem anderen.
Erst die einfachen sachen zum Laufen bringen: Den Brenner. Dabei auf Deinen framebuffer verzichten.
Wenn Du dann mal Zeit hast den bisherigen Kernel sichern, lilo/Grub einrichten, so dass mir dem alten Kernel weiterhin gebootet werden kann....
Dann die komplizieren Sachen, wie zB Deinen Framebuffer machen.
Den ollen Kernel hast Du dann ja noch als Fall-Back-Option;-)

Zumal, wenn Du am Netzwewrk und am Brenner und an der Grafik fummelst, dann neu bootest, und nix mehr geht, weisst Du doch gar nicht mehr, was Du alles geändert hast, kannst es nicht mehr rückgängig machen. Und "Peng", da haben wir das Mahlör;-)
Jetzt sach nicht: "Och ist doch alles Scheisse, ich wollte es ja nur zum Laufen haben".
Nee, nee, immer ruhig Blut, und sei nicht so hibbelig (doch bist Du), dann klappts auch mit der Nachbarin so la la:
<Briefmarkensammlungszeig-Mode-on>
Hey, Süsse, komm mal rüber, ich will Dir mein laufendes Linux zeigen *lechtz*.
<Briefmarkensammlungszeig-Mode-off>
Tüss, und viel Spass mit der Nachbarin,
Arnim!

[matop]

hmm irgendwie dreh ich mich im kreis...

also nochmal wenn ich in der lilo.conf vga=733 einstelle dann gibt es toitale grafikfehler... dieses resultiert daraus das der original nvidia treiber von der nvidia hp nicht mit den RIVA-NVIDIA-Framebuffer treiber zusammarbeitet.. (steht übrigens auch in der readhme-datei von nvidia). Da aber der riva-NVidia-treiber fest im redhat kernel einkompiliert ist kann ich ihn nicht deinstallieren.
Die grfikfehler sehen so aus als das unter der normal-konsole zuerst die schrift komplett dunkel-blau ist und nachdem man dann zwischendurch wieder auf x-wechselt und wieder die konsole betritt ist in 70% der fällen garnix mehr zu erkennen. Deswegen muss ich irgendwie diesen behinderten RIVA-NVIDIA-FRamebuffer-treiber deinstallieren.

Also wenn ich das richtig gelesen hab zumindest steht es so in den docs vom kernel. wird wenn in lilo.conf vesa=xxx steht automatisch der dafür vorgesehende frambuffer-treiber geladen. Sollte der Kernel keinen Treiber für die GRafikkarte hat wird der VESA treiber bzw. wenn das nicht klappt der vga16 treiber geladen. Da aber meine GForce 2 MX 400 DDR 64MB eine der Karten ist die den RIVA-NVIDIA treiber benutzt wird dieser geladen. dieser ist direkt im kernel und dieser, genau dieser, funzt NICHT zusammen mit der nvidia-treiber von nvidia.com.

Warum das bei dir Arnim in einer Slackware funzt ist einfach... Der Riva-Treiber steht (zumindest war das so bei meiner slackware installaition) weder als module noch direkt im kernel also gibt damit keiner probleme. wie es bei suse ist weiß ich nicht.

Warum ich framebuffer brauche ist auch einfach ich mag die standart auflösung von 25x80 Zeichen nicht ausserdem kommt es öffters vor das ich mal ein video auf der konsole schaue, da ich nicht jedesmal lust hab x wegen ein video zu starten.

aso ich noch ein paar listings:

[matthias@SG-1 matthias]$ /sbin/lsmod
Module Size Used by Tainted: P
i810_audio 27528 0 (autoclean)
ac97_codec 13544 0 (autoclean) [i810_audio]
soundcore 6276 2 (autoclean) [i810_audio]
agpgart 46752 3 (autoclean)
nvidia 1766848 11 (autoclean)
parport_pc 18756 1 (autoclean)
lp 8868 0 (autoclean)
parport 36480 1 (autoclean) [parport_pc lp]
autofs 12948 0 (autoclean) (unused)
sis900 16524 1
ide-scsi 11984 0
scsi_mod 106200 1 [ide-scsi]
ide-cd 35196 0
cdrom 33472 0 [ide-cd]
nls_iso8859-1 3484 1 (autoclean)
nls_cp437 5116 1 (autoclean)
vfat 12844 1 (autoclean)
fat 38328 0 (autoclean) [vfat]
keybdev 2880 0 (unused)
mousedev 5428 1
hid 21700 0 (unused)
input 5792 0 [keybdev mousedev hid]
usb-ohci 21160 0 (unused)
usbcore 77696 1 [hid usb-ohci]

Hier findet sich nur der normale nvidia treiber von nvidia.com und kein fb treiber. Da aber, ich habs eben mal mit vga=733 gestartet ich fb unterstützung mom auf der konsole habe ist er irgendwo geladen, und wenn nicht als module dann im kernel direkt.

meine lilo.conf:

# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
lba32 # Allow booting past 1024th cylinder with a recent BIOS
append="hdd=ide-scsi"
boot = /dev/hda
prompt
timeout = 1200
vga = 788

# ****************************************************************
# * Windows 200 *
# ****************************************************************

other = /dev/hda1
label = DOS
table = /dev/hda

# ****************************************************************
# * Slackware Default Kernel *
# ****************************************************************

image = /boot/vmlinuz
root = /dev/hda2
label = Linux
read-only

image = /boot/vmlinuz-2.4.20.matop
root = /dev/hda2
label = Linux-2.4.20
read-only
# Linux bootable partition config ends

#***********************
#* Redhat *
#***********************
image = /mnt/redhat/boot/vmlinuz
root = /dev/hda3
label = redhat
read-only

So das wars erstmal...

ich muss nun system neu booten sonst kann ich nicht richtig arbeiten....

[matop]

Na toll nun bin ich komplett überfordert...

Hab gerade meinen standart 2.4.19 Kernel ohne Module unter redhat installiert. diesen Kernel hab ich vor ewigkeiten mal ohne module unterstützung kompiliert und diesen hab ich auch an das nvidia problem damals angepasst.
nachdem ich denn nun endlich gestartet hatte bekam ich wieder die grafikfehler, welche aber, unter slackware und debian damals nicht waren.

Kurz zusammengefasst: Ich bekomme immer grafikfehler wenn ich von X auf die konsole wechsel obwohl der kernel und der nvidia-treiber die gleichen sind wie unter meinen slackware und debian system.

Die boot-messages entsprechen auch denne die ich unter slackware und debian vorher hatte. Keine Fehlermeldungen... Irgendlwie versteh ich die welt nichtmehr... Wie kann es sein das unter redhat total das grafikkauderwälsch zusammenkommt?

[arnim]

Oh mann.... was ein durcheinander;-)

Hier mal ein paar Schnipsel, die ich bei Google gefunden habe, in unterschiedlichen Postings. Keine Option hat mit der anderen was zu tun.
1.###
mit video=riva:1024x768-16@75 setzt du zusaetzlich noch die Farbtiefe
auf 16 Bit.
Also append="video=riva:1024....." in /etc/lilo.conf aufnehmen und
/sbin/lilo aufrufen.
2.###
Bingo! Statt 795 mal 775 (1280x1024x8) ausprobiert, schon läufts.
3.###
append="video=vga16:off"
4.###
In lilo.conf in der append zeile eintragen :
"video=vesafb:800x600-16@85 video=rivafb:800x600-16@85 "
###

Vielleicht erinnert Dich eine Option an irgendwas?
Wenn Deine Grafik an der Konsole verzerrt ist, probier mal ne andere Auflösung/Farbtiefe/... siehe Tip Nr.2
klingt irgendwie passend, eventuell.

Wenn die ganzen fb-Module fest im Kernel sind, dann muss es auch eine Lilo-Option geben (append), um das zu ändern, würde ich sagen.
Blos wie?;-)
Gruss,
Arnim, der sich mit 3 Sonnenschirmen auf der Terasse verkrochen hat.

[matop]

Was mich halt wundert ist das meine lilo.conf und mein all-inclusiv-Kernel so unter slackware funktioniert, dort habe ich keine Grafikprobleme. nur unter RedHat....
Andere GRafikmodis hab ich auch probiert. Das einzige was zu funktionieren scheint ist wenn ich die append-zeile ganz aus der lilo.conf entferne. Das ist aber nicht sinn der Sache da ichs chon etwas mehr Zeichen als 80x25 hätte.....

[arnim]

[matop]

[arnim]

[matop]

[matop]

[arnim]

[matop]