
Hallo Karsten, ich hab' nochmal den Default-Kernel ausprobiert, der stirbt auch, nur leiser... also keine Logs auf dem Schirm, Sysrq funzt auch nicht - kompletter Deadlock. Jetzt ist in dem Rechner eine B1 drinne, und was soll ich sagen: das selbe in grün. Sobald am ISDN-Kanal ein Anruf eingeht, steht das System solide... Ich bin jetzt fast soweit, zurück zur Suse 9.1 (da, hab' ich gehört, soll es funktionieren) "downzugraden"... Und das, obwohl Tobit und AVM übereinstimmend beteuern, das alles mit SuSE getestet zu haben. Halt nur bis 9.1... gibbet so was. Und nächste Woche kommt die 9.3... Wie ich das sehe, scheint wohl das x86_64-Tree kaputt zu sein was das ISDN-Zeugs angeht. Ist aber auch nur wilde Spekulation. Kannst Du vielleicht mal im "Hause" schauen, ob noch jemand eine x86_64-Version laufen hat und gerade eine B1 reindrücken (gibt's garantiert zuhauf in der Buchhalten, Datev sei Dank!). Mir gehen nun langsam echt die Alternativen aus und der Kunde will den Server morgen haben... Vielen Dank schon mal im Voraus! Karsten Keil schrieb am 29.03.2005 14:34:
On Tue, Mar 29, 2005 at 01:00:27PM +0200, Patric Bechtel wrote:
Hallo Karsten,
Karsten Keil schrieb am 29.03.2005 10:40:
On Tue, Mar 29, 2005 at 12:25:06AM +0200, Patric Bechtel wrote:
Hallo,
ich habe ein Problem mit einer C2 in einem 2xOpteron-Rechner mit SuSE 9.2. Nach einem rcisdn start brauche ich die Maschine nur anzurufen, dann bleibt die komplett stehen - kein Ping, kein Tastendruck auf dem Terminal mehr möglich, einfach nichts. Entlade ich die Treiber, gehts. Nun ja, zumindest stürzt nichts ab. Ich hab' schon während der Installation das YOU laufen lassen, das hat gleich auf 2.6.8-24.13 upgedated, ich hab' nach ein paar Googles dann mal auf das Kernel 24.10 zurückgedreht. Ja, ein depmod -a und eine
Der funktioniert definitiv nicht mit C2 Karten und SMP, das wurde in den aktuellen Kernel Versionen gefixt, also 2.6.8-24.13 ist soweit OK.
Die hab' ich bereits drauf... :-(
Reinstallierung der non-gpl-Module etc hab' ich auch schon probiert.
Der C2/C4 Treiber ist komplett GPL damit braucht es die non-gpl-Module nicht.
Aha. Ich dachte, die Firmware läge als Binary vor und wäre daher nicht im GPL-Kernel mit drin...
Hat noch jemand eine Idee, wie ich wenigstens eine Log-Meldung oder so etwas bekomme, die mir sagt, WAS genau schief läuft? Oder hat noch jemand die C2 mit einer 9.2 laufen und kann mit die Versionsnummern seiner Pakete nennen?
sysreq aktivieren Vor Anruf auf die LOG console (tty10) umschalten
Danke, *aschestreu*... die Fehlermeldung ist trotzdem recht kryptisch: NMI Watchdog detected LOCKUP on CPU0, registers: Modules linked in [...] Pid: 5037, comm: isdnlog Not tainted (2.6.8-24-13-smp SL92_BRANCH_200503181019420000) RIP: 0010:[<ffffffff803628db>] <ffffffff803628db>{.text.lock.spinlock+34} Process isdnlog (pid: 5037 [...] [...] Call Trace:<ffffffff80137d5c>{add_wait_queue+28} <ffffffffa018687e>{:isdn:isdn_poll+254} [...]
DEADLOCK, war fast zu erwarten.
ohne isdnlog:
Call Trace:<IRQ> {__wake_up_common+67} {__wake_up+67} {__queue_work} {delayed_work_timer_fn+0} {run_timer_softirq+335} {__do_softirq+113} {default_idle+0} {do_softirq+53} {apic_time_interrupt+99} <EOI> {default_idle+32} {cpu_idle+26}
Code: Bad RIP value. [...] Badness in do_unblank_screen at drivers/char/vt.c:2876
Call Trace:<IRQ> {do_unblank_screen+80} {bust_spinlocks+28} {oops_end+21} {do_page_fault+1157} {ip_forward+610} {ip_rcv_finish+574} {ip_rcv_finish+0} {ip_rcv_finish+0} {recalc_task_ptio+635} [...]
Sieht fast so aus als ob da im Locking was schiefgeht - kann da jemand was zu sagen... ich hab' inzwischen auch schon mal die Firmware getauscht, aber der Fehler liegt wohl auf der Hostseite (also im c2-Treiber bzw. dessen Interrupt-Handler).
Ach so: maxcpus=1 hab' ich auch schon probiert, ohne Erfolg... vielleicht probiere ich mal einen nicht-smp-Kernel - der hat ja keine Spinlocks afaik...
Ich wäre für Anregungen etc immer noch sehr dankbar :-)
Also mit default kernel sollte das Ding stabil laufen, eventuell mal den default kernel (nicht SMP!) mit CONFIG_DEBUG_SPINLOCK und CONFIG_DEBUG_SPINLOCK_SLEEP bauen, dann sieht man eventuell wo es problematisch ist.
-- Mit freundlichen Gruessen / Regards Patric Bechtel, IPCON Informationssysteme OHG Kontakt: http://www.ipcon.de/kontakt.php