[erledigt] bristuff will nach Neuinst nicht mehr

Fux

Mitglied
Mitglied seit
3 Jun 2004
Beiträge
440
Punkte für Reaktionen
1
Punkte
18
Hallo zusammen,

bei mir lief bis vor kurzem * mit bristuff auf einer SuSE 9.1 nahezu einwandfrei.

Leider ist eine HD dieses Rechners gecrasht, weshalb ich ihn neu aufsetzen mußte.

Dabei wurde auch * neu installiert. Die Konfigs wurden übernommen.
Die Installation verlief problemlos und fehlerfrei.
Zaptel und Zaphfc sowie * lassen sich ohne Probleme laden.

Leider geht an dem neu installierten * alles bis auf Zap (SIP, CAPI & IAX2). Die an die HFC-Karte angeschlossenen Telefone geben keinen Mucks von sich. In der * Konsole erscheint auch nix, hebt man den Hörer eines ISDN-Tels ab.

Die Verkabelung sowie die Konfigs kann ich als Fehlerquelle ja eigentlich ausschließen, da sie bis zum HD-Crash funktionierten.

Es muß also irgendwas im System sein. Leider gibt es keine Fehlermeldungen. Wenn man von der Meldung "unsupported module, tainting kernel" im Syslog bei Laden von zaptel & zaphfc mal absieht.
Oder sollte dieses etwa die Ursache sein ?

Ich hatte ein ähnliches Problem schonmal. Auch damals Schweigen im (Zap-)Walde. Ursache war damals der Hisax-Treiber. Sobald dieser geladen war, kam auf dem Zap-Channel nix mehr an.

Er ist natürlich im Moment nicht geladen. Testweise habe ich ihn mal geladen. Man weiß ja nie...
Gebracht hat es aber nix.

Habe zaphfc mal mit debug=1 geladen. Die Ausgabe im Syslog sieht dann so aus:
Code:
ct 13 22:00:34 server kernel: zaphfc: card 0 layer 1 state = G2
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0x8c 0x50 0x6 0xff !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0x5c 0x81 0x6 0x81 !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0x9c 0x9e 0x6 0x83 !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0x58 0xe0 0x6 0x85 !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0xda 0x20 0x6 0x87 !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0xc4 0xfa 0x6 0x89 !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0x20 0x28 0x6 0x8b !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0x3f 0x38 0x6 0x8d !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0x48 0xd6 0x6 0x8f !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0x3c 0x18 0x6 0x91 !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0x7d 0xe5 0x6 0x93 !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0xa1 0xd2 0x6 0x95 !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0x1a 0xa0 0x6 0x97 !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0xeb 0xf1 0x6 0x99 !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0x4c 0xd8 0x6 0x9b !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0x7d 0xcf 0x6 0x9d !]
Oct 13 22:00:37 server kernel: zaphfc: card 0 TX 8 bytes [ 0xfe 0xff 0x3 0xf 0xc 0x4d 0x6 0x9f !]

Wenn ich das richtig interpretiere, werden also nur Daten gesendet aber keine empfangen.

Hat jemand eine Idee ?

Da kommt man doch ins Grübeln. Nachdem ich ewig an diesem Hisax-Problem gesucht habe, dachte ich den Bogen jetzt raus zu haben...
Wenn es doch wenigstens eine Fehlermeldung gäbe.

EDIT (23:00)

Der Vollständigkeit halber noch die Ausgabe der * Konsole (bri debug span 1)
Code:
-- Making new call for cr 130
> Protocol Discriminator: Q.931 (8)  len=20
> Call Ref: len= 1 (reference 2/0x2) (Originator)
> Message type: SETUP (5)
> [04 03 80 90 a3]
> Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
>                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
>                              Ext: 1  User information layer 1: A-Law (35)
> [18 01 89]
> Channel ID (len= 3) [ Ext: 1  IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
>                        ChanSel: B1 channel
                         ]
> [70 05 c1 32 30 30 30]
> Called Number (len= 7) [ Ext: 1  TON: Subscriber Number (4)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '2000' ]
> [a1]*CLI>
> Sending Complete (len= 1)
    -- Called g1/2000
No response to SETUP message
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Call Initiated, peerstate Overlap sending
    -- Channel 0/1, span 1 got hangup
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Call Initiated, peerstate Overlap sending
    -- Hungup 'Zap/1-1'
  == No one is available to answer at this time
 
proc/interrupts sieht so aus:
Code:
           CPU0
  0:  106885525          XT-PIC  timer
  1:       4317          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  3:   22086549          XT-PIC  Ensoniq AudioPCI
  5:  849753618          XT-PIC  zaphfc
  8:          4          XT-PIC  rtc
  9:        358          XT-PIC  acpi, aic7xxx, uhci_hcd
 10:   66136326          XT-PIC  libata, eth0, uhci_hcd, fcpci
 11:          0          XT-PIC  uhci_hcd, uhci_hcd
 12:       3934          XT-PIC  i8042
NMI:          0
LOC:          0
ERR:          1
MIS:          0

Die HFC-Karte hat einen eigenen IRQ (5) und löst ca. 27 bis 29 Mio (wow!) Interrupts pro Stunde aus.
EinVergleich mit einem anderen von mir betriebenen * Server zeigt einen ähnlichen Wert.
Scheint also normal zu sein.
 
Der Anschluß an der Karte war abgerissen.
Habe die Kontakte mit einer Lötnadel wieder mit ihren Kontaktfahnen verbunden.
Nun geht´s.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.