Gruesse!
* Christoph Klein <[EMAIL PROTECTED]> schrieb am [16.09.04 17:38]:
> > Ich bin nicht der Hardware-Experte, aber IRQ-Sharing ist reine Sache
> > des BIOSes bzw. des PCI-Busses. Unabh�ngig von A*PI*C
>
> hmm w�rde das dann bedeuten, dass, wenn das bios/pcibus die irqs nicht
> shared, das betriebssystem es auch nicht machen kann ?
> au�er es kann mit APIC die interrupts neu verteilen und ggf. auch sharen,
> wenn es die hardware unterst�tzt ?
Ja, so ungef�hr. Ich habe hier z.B. einen Dual-PentiumPro Server, der
ein "IRq-Sharing" (oder besser "Neuverteilung") machen kann weil das
sowohl die Hardware-APIC wie auch das OS nutzen, also IRQs > 15.
Oftmals trifft man das auch bei Uni-Prozessor-Systemen v.a. mit Windows
2K/XP, wenn nach der Installation *alle* PCI-Hardware auf einem IRQ
liegen, obwohl der Rest auch frei ist.
Dazu hat Bj�rn dir ja auch schon was geschrieben.
Da du bei dem PC ja auch eine etwas betagtere Hardware einsetzt (ich
werkele hier z.B. auch noch mit meinem K62/350 rum, gl�cklich und
zufrieden!) w�re es auch noch mal eine �berlegung, �ber ein BIOS-Update
nachzudenken. Evtl. behebt ein Update eine mangelhafte
BIOS-Implementation im Bereich PCI-Bus.
> > Trotzdem geh�rt f�r mich die System.map zum jeweiligen Kernel.
>
> nun, das dachte ich mir auch des �fteren beim bf2.4 kernel, bei dem ja auch
> eine dabei ist.
> bei den selbstkompilierten wei� ich nicht, wo man die jeweilige datei
> herbekommt bzw. zu was sie �berhaupt gut ist;
> der kernel und die module funktionieren ja auch so ;-)
Die System.map liegt nach dem Kompilieren in /usr/src/linux. Per Hand
nach boot kopieren (make-kpkg nimmt dir das ab ;-).
Genutzt und wichtig ist die IMHO beim Debuggen. Negativ im normlen
Betrieb? Hm, ich hatte noch nie Kernel ohne die System.map. M��te ich
noch mal in die Doku schauen.
> nun, die netzwerkkarten gehen ja, nur die isdn karten funktionieren nicht -
> was aber auch an mISDN oder der pbx liegen kann,
> also in /proc/interrupts sind sie zu finden; module (zwar auch mit irq
> routing conflict) sind geladen.....
> die pbx bringt w�hrend sie versucht zu starten nur folgende meldungen:
>
> server:~# pbx state
> ** PBX4Linux ** Version 2.5 (August 2004)
> debug_init: using stdout for debug log
> debug_init: using stderr for warning log
> debug_init: using stderr for error log
> debug_init: debug_mask = 1000
> cannot request MGR_NEWENTITY from mISDN. Exitting due to software bug.
>
> wie gesagt, entweder in mISDN oder der pbx ist ein bug, oder die karten
> funktionieren tats�chlich nicht (obwohl sich die module laden lassen)
> falls es an mISDN/der pbx liegt, werde ich evtl. auch mal auf deren
> mailinglisten vorbeischauen ;-)
Gut, da kann ich garnichts zu sagen. Aber das sich die Module laden
lassen und die IRQ/IO-Verteilung funktioniert macht eigentlich
Hoffunng.
Ich kenne halt auch weder die HFSs noch mISDN. Um sicherzugehen, ob die
Karten wegen einen IRQ/IO-Konflikts *nicht* funktionieren, w�rde ich
ggf. mal den umgekehrten Weg gehen und zeitweise die beiden NICs
ausbauen. Dann die ISDN-Karten und mISDN so einrichten, das sich sagen
wir mal ein Wahlvorgang ausl�sen l��t. Oder es gibt bei mISDN ein Tool
wie z.B. capiinfo bzw isdnctrl bei Hisax zum �berpr�fung des Status.
pbx setzt ja scheinbar ein funktionierendes mISDN voraus, f�llt als
Test deshalb IMHO flach.
Bei Nicht-Funktionieren w�rde ich einen eigenen Thread zu mISDN
aufmachen. Wenn es funktioniert, w�rde ich eine oder beide NICs wieder
einbauen und dann schauen, ob es immer noch geht.
> > Und: siehst du mittlerweile mit modconf deine Module deines Kernels?
>
> leider nicht, das h�ngt mit der modprobe.conf von kernel 2.6 zusammen, das
> "alte" modconf kommt damit nicht zurecht - is ja auch nicht soo wichtig das
> modconf ;-)
Hm, auch da kann ich dir nichts sicheres sagen. Aber ich meine, ich
konnte mit einem Versuchs-Kernel-2.6 und den neuen modultils trotzdem
mit modconf Module laden und entladen. Ist aber schon l�nger her.
Vielleicht kann dazu jemand der Woody+modutils+Kernel-2.6 einsetzt was
genaues sagen?
> mfg & vielen dank
> christoph
Gru�
Gerhard
