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