HFC Karte in Xen

[divB]

Hallo,

Verwendet das zufällig wer?

Bei mir läuft alles problemlos (Compilation BRIstuff, Laden des Moduls, ...) nur funktioniert das ganze nicht weil:

# cat /proc/interrupts
           CPU0
 18:     224563        Phys-irq  fcpci
 20:          0        Phys-irq  zaphfc
256:     114262     Dynamic-irq  timer0
257:        875     Dynamic-irq  xenbus
258:       1452     Dynamic-irq  xencons
259:       6340     Dynamic-irq  blkif
260:          1     Dynamic-irq  blkif
261:       2819     Dynamic-irq  blkif
262:          0     Dynamic-irq  blkif
263:          0     Dynamic-irq  blkif
264:       2428     Dynamic-irq  blkif
265:          0     Dynamic-irq  blkif
266:       9267     Dynamic-irq  eth0
NMI:          0
ERR:          0

...keine Interrupts generiert werden, wie man sieht.
Es kann aber kein grundsätzliches Problem sein, denn wie man sieht funktioniert die fcpci (Fritz! Karte) darüber problemlos.

Hat wer Tipps? Vor allem, warum die HFC Karte keine Interrupts generiert?

mfg,
divB


/EDIT:


Noch was: Folgendes erscheint in dmesg wenn ich zaphfc lade:

Apr  8 00:16:00 nobaq kernel: zaphfc: hfc busy.

WTF soll das heissen?? Google schweigt sich darüber auch aus und aus den Sourcen werd ich nicht schlau :-(

 

[geistio]

Hallo! Schon eine Lösung des Problems gefunden? Danke!

 

[divB]

Ich leider nicht

Bin vorerst auf Linux VServer umgestiegen...(funktioniert ohne Probleme damit)

Bin aber nach wie vor selbst für alle Tips dankbar!

LG, divB

 

[geistio]

Aaaaalso....
Ich habe jetzt mittlerweile auf der Xen-Users Mailingliste und auf der Bristuff-Users (http://lists.three-dimensional.net/pipermail/bristuff-users) einen Thread bezüglich HFC-s Karten und Xen gestartet. Zudem hab ich einen einen Xen-Bugreport (http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1201 ) ausgefüllt und Tzafrir Cohen von xorcom.com eine E-Mail geschickt... Mal sehen ob das was wird.

 

[geistio]

divB: Hast du denn jemals getestet, ob die Karten in einer Dom0 funktionieren? Wäre interessant zu wissen...

 

[divB]

Ich befürcht das wird hoffnungslos :-( Offenbar is keiner der Xen-Leute an einer Lösung intressiert, was noch erschwerend dazu kommt: Durch die Timings reagieren die ISDN-Karten besonders kritisch auf die Scheduler-Timings.

Wie auch immer: Bitte lass uns hier über Updates wissen

Zu dom0: Nein, leider, hab ich damals leider nicht probiert, hätte ich aber sollen! Falls es in dom0 problemlos gehen würde, würd ich nämlich auch nochmal über Xen nachdenken...wobei meine Konstellation bereits so viele Probleme macht (http://www.ip-phone-forum.de/showthread.php?t=159102, wobei ich noch immer nicht weiss obs an der Hardware allgemein, der Fritz! oder der HFC Karte liegt).

Wie auch immer, ich würd dir einen Versuch mit Linux VServer empfehlen. Anfangs kommt es einen sehr zurückgeblieben und primitiv vor im Gegensatz zu Xen, wenn du jedoch sowieso nur Linuxes virtualisieren willst dann macht es alles in der Praxis viel einfacher: Alles reduziert sich auf einen Kernel und jegliche Hardware bleibt uneingeschränkt nutzbar, der zusätzliche Overhead ist genau 0%.
Fehlereingrenzen ist viel einfacher, da es sich um einen normalen Kern handelt (d.h. liegt der Fehler jetzt am Hypervisor, dom0, domU entfällt, ...) und man ist viel flexibler in der Kernauswahl.

 

[m.goegel]

Also HFC in Dom0 hatte ich hier bis vor kurzem laufen. abgesehen von einigen Instabilitäten von mISDN, lief das System eigentlich. Ich vermute, dass eher mISDN das Problem war, als die Dom0 - der Rechner hatte eine durchschnittliche Uptime von min. 1 Monat (ich weiß, ist nicht viel, ich habe nebenbei in einer DomU chan_capi getestet/programmiert (den QSIG Teil)).

Mario

 

[divB]

Danke für deinen Erfahrungsbericht! Sprichst du hier von zaphfc, chan_capi oder /nur/ von chan_misdn?

Weil mit chan_misdn hatte ich damals einigermaßen Erfolge, wollte es aber nicht verwenden, da mein System bis jetzt gut mit zaphfc und fcpci läuft, das Fax mit CAPI so toll funktioniert und ich das ganze System einfach nicht umändern wollte (zumal misdn noch als unstable markiert ist)

 

[m.goegel]

Also chan_misdn hatte ich nun wieder nicht richtig zum laufen bekommen. Ich hatte mich da auch nicht intensiver dahintergeklemmt, da ich nicht unbedingt soviele verschiedene channel Treiber nutzen wollte, zumal chan_capi 100% fest stand.

Also mISDN mit CAPI bei mir. Die CAPI Geschichte hat ja auf jeden Fall den Vorteil, dass ich sie ohne Probleme in die virtuelle Umgebung bekomme, sei es xen, vmware, etc.
Die Remote-CAPI ist sofern sehr stabil - zumindest unter Linux.

Auf Arbeit nutze ich die mit den Bintec-Netzwerk-CAPI, welches mich nicht besonders überzeugt. Wobei ich hier als Ursache auch meine Anwendung nicht ausschliessen kann.

Also wie gesagt: ISDN per rcapi lässt sich auch in einer virtuellen Maschine prima machen. Nachteil bei mISDN: KEIN NT-Modus (z.Zt jedenfalls).

Mario

 

[geistio]

Hmmm.... mISDN unterstützt doch den NT-Modus der HFC-S Karten, oder? Wo genau liegt denn das Problem? mISDN, dem mISDN-CAPI-Interface oder chan_capi?

 

[m.goegel]

zweiteres - mISDN mit CAPI kann (konnte - weiß nicht ob's aktuell noch so ist) das nicht

Mario

 

[geistio]

Obwohl... chan_capi sollte es können... Zumindest hat die capi.conf einen ntmode=yes parameter...
Ich bekomme übrigens jedes mal wenn ich versuche die mISDN module zu entladen (in der dom0), einen kernel oops der wie folgt aussieht:

mISDN_dsp_element_unregister: kb1ec unregistered
mISDN_dsp_element_unregister: mg2ec unregistered
mISDN_dsp_element_unregister: mec2 unregistered
mISDN_dsp_element_unregister: hwec unregistered
dsp_pipeline_module_exit: dsp pipeline module exited
release_l1 id 100
kcapi: card 1 down.
kcapi: Controller 1: mISDN1 unregistered
BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
d31c5c32
0fb3f000 -> *pde = 00000000:0b37a001
0fb7a000 -> *pme = 00000000:00000000
Oops: 0000 [#1]
SMP 
Modules linked in: hfcpci mISDN_capi l3udss1 mISDN_l2 mISDN_l1 mISDN_core capi kernelcapi bridge netloop ipv6 capifs ext2 loop i2c_viapro via686a tsdev floppy serio_raw rtc i2c_isa shpchp pci_hotplug i2c_core psmouse via_agp agpgart pcspkr parport_pc parport evdev ext3 jbd mbcache dm_mirror dm_snapshot dm_mod ide_generic ide_disk generic uhci_hcd usbcore via82cxxx ide_core 8139cp 8139too mii thermal processor fan
CPU:    0
EIP:    0061:[<d31c5c32>]    Not tainted VLI
EFLAGS: 00010246   (2.6.18-5-xen-vserver-686 #1) 
EIP is at release_stack+0x5c/0xff [mISDN_core]
eax: 63656a62   ebx: d1625800   ecx: 00000000   edx: 00000000
esi: d1625800   edi: d32681ec   ebp: 00000000   esp: cfb87ee0
ds: 007b   es: 007b   ss: 0069
Process modprobe (pid: 3021[#0], ti=cfb86000 task=c0c08870 task.ti=cfb86000)
Stack: d1737000 d1625800 d32681ec d31c451c d1737088 c02922d6 d32681ec d1737000 
       d1737048 d32681ec 00000080 c01cc61f d17370c0 c021193e d32681ec d1737080 
       d1737048 c0211b7f d32681ec 00000000 c02e8400 c021118f d32681ec 00000020 
Call Trace:
 [<d31c451c>] mISDN_ctrl+0x32f/0x59d [mISDN_core]
 [<c02922d6>] klist_release+0x0/0x45
 [<c01cc61f>] pci_device_remove+0x16/0x28
 [<c021193e>] __device_release_driver+0x5a/0x72
 [<c0211b7f>] driver_detach+0x60/0x8d
 [<c021118f>] bus_remove_driver+0x57/0x75
 [<c0211c88>] driver_unregister+0x8/0x13
 [<c01cc769>] pci_unregister_driver+0xc/0x58
 [<c013a251>] sys_delete_module+0x1ad/0x1d4
 [<c015c93d>] kmem_cache_free+0x44/0x7d
 [<c015228b>] remove_vma+0x31/0x36
 [<c0152ac1>] do_munmap+0x1aa/0x1c4
 [<c0104883>] syscall_call+0x7/0xb
Code: ea ff ff ff 68 54 03 00 00 68 aa bb 1c d3 68 f2 c0 1c d3 e8 b3 5e f5 ec e8 42 f7 f3 ec 83 c4 10 e9 a3 00 00 00 8b 93 c4 00 00 00 <8b> 32 eb 15 89 d0 e8 13 fe ff ff 85 c0 89 c7 0f 85 88 00 00 00 
EIP: [<d31c5c32>] release_stack+0x5c/0xff [mISDN_core] SS:ESP 0069:cfb87ee0

 

[divB]

Obwohl... chan_capi sollte es können... Zumindest hat die capi.conf einen ntmode=yes parameter...

Jein, chan_capi setzt auf dem CAPI Interface auf; funktioniert also für Karten deren Treiber eine CAPI zu Verfügung stellen. CAPI an sich kennt im Standard den NT Modus und genau den verwendet chan_capi auch.

Nichtsdestotrotz braucht man dafür eine Karte, die (a) CAPI Treiber hat und (b) den NT Modus nativ unterstützt.

Das gilt AFAIK nur für teure, professionelle Karten und NICHT für die Fritz! Card.

Für HFC Karten ist mir zumindest kein CAPI Treiber bekannt und können somit auch nicht mit chan_capi verwendet werden - weder im NT, noch im TE Modus.

 

[geistio]

Also im TE Modus funktioniert die HFC-S Karte mit den mISDN Modulen über chan_capi...
/etc/mISDN.conf sieht wie folgt aus:

<mISDNconf>
	<module poll="128" debug="0" timer="no">hfcmulti</module>
	<module debug="0" options="0">mISDN_dsp</module>
	<module>mISDN_dsp_mec2</module>
	<module>mISDN_dsp_mg2ec</module>
	<module>mISDN_dsp_kb1ec</module>
	<devnode user="root" group="root" mode="644">mISDN</devnode>
	<card type="hfcpci">
		<port mode="te" link="ptmp" capi="yes">1</port>
	</card>
</mISDNconf>

 

[geistio]

Hmm... Also das Problem mit den HFC-Karten unter Xen dürfte wohl in erster Linie sein, dass diese so extrem "Interrupt-intensiv" sind, oder?
8000 Interrupts/Sekunde so viel ich weiß. Könnte man diese Zahl nicht irgendwie reduzieren? Haben wir hier im Forum eigentlich "HFC-S-Profis"? Also Leute die sich mit diesen Karten so gut auskennen, dass sie direkt am Sourcecode des zaphfc Moduls arbeiten könnten...?
Kennt jemand z.B. den Autor des Florz-Patches? Vielleicht könnten wir uns mit dem zusammentun...?!
Ich meine der Sourcecode von zaphfc.c besteht aus circa 900 Zeilen... Ich würde mich jetzt nicht gerade als Kernelhacker bezeichnen, aber ich denke schon, dass das Modul schon halbwegs überschaubar ist...
Vielleicht könnten wir wirklich was auf die Beine stellen und dieses Modul Xen-tauglich machen... Patches würden doch auch Nicht-Xen-Users zugute kommen, da dieses Ziel wahrscheinlich in erster Linie erreichbar sein wird indem wir das Modul insgesamt resourcenschonender machen. Denke ich zumindest...

 

[foschi]

Die Interrupts die generiert werden dienen als Zeitbasis für ISDN, und sind nicht ohne weiteres reduzierbar.

An eurer Stelle würd ich mich von der Thematik ISDN-Karte etwas lösen, und das ganze mittels Medien-Gateways (z.B. von Patton) realisieren - deutlich flexibler und besser geeignet für virtuelle Umgebungen.

Aus meiner Erfahrung kann ich übrigens berichten, dass ich es nicht für sinnvoll halte, größere Asterisk-Installationen zu virtualisieren; zumindest haben wir bei uns das Problem der zeitweise verlangsamten Sprachübertragung (schön festzustellen an VoiceMails) nie sauber in den Griff bekommen.

 

[geistio]

Hmm... Patton Gateways... Sind bestimmt eine tolle Sache, aber preislich absolut nicht vergleichbar mit 2 HFC-S Karten. Wieviel kostet denn eine ISDN BRI jeweils einem TE und einem NT Port in etwa? Um die 1000 Euro?!
2 HFC Karten gibt es um 40 Euro...

 

[Mona]

Also ich habe mich auch an dem Thema probiert. ALLEs ging bis auf den NT-Modus (der reagierte einfach nicht auf einen Anruf) in der DomU. Da ich den aber brauchte, musste ich wieder alles abbrechen...

 

[divB]

Mit zaphfc oder mit mISDN?

Hat bei dir der Treiber Interrupts generiert? Kannst du mal genauer erläutern?

lg,divB

 

[Mona]

Ich habe es mit mISDN gemacht. Das erste Problem sind die Interrupts. Nach zahlreichen Problemen hat es aber einwandfrei funktioniert, nachdem ich auf der Dom0 ALLES im Bios deaktiviert habe, was ich nicht brauche (insbesondere die unendlichen vielen USB-Controller). Was ich auch machen msuste war die Deaktivierung der internen Netzwertkkarte, da die offensichtlich einen IRQ hardwareseitig zugewiesen bekommt.

Dann habe ich die beiden HFC-Karten direkt an die DomU durchgereicht und auf der DomU mISDN installiert. Während der TE-Modus einwandfrei funktionierte und ich auch völlig problemlos über Wochen telefonieren könnte, lies sich der NT-Modus aber leider nicht in Betrieb nehmen.