> Hi, > > > Beronet's manual is stating that the LEDs turn red when the driver is > > loaded but the card is not physically connected to the NTBA. When > > connected properly they should turn green. Here it seems different: The > > LEDs indicate green no matter whether connected or not. Please > > understand I was about to make my first ISDN-call with a computer, so I > > wouldn't spend too much interest in that matter. But if anyone > > (Daniele?) could explain the correct status indications to me, I'd > > appreciate it. > > The led color is the opposite you are used to: > > Off for disabled port > Green for enabled port with deactivated layer 1 > Red for enabled port with active layer 1 > Fast flashing green/red for transitioning layer 1 > Flashing off for traffic on the D channel > > I've already received some request to swap red and green colors and I'll > probably do it.
Since I assumed it's the way you explained above, at least /me could stick with your definitions. Though people might get confused with the meaning of a red indication. I couldn't help thinking of an error... > > Back to the prob. As soon as I start to dial a number on my SIP-phone > > that'd be routed via vISDN the FC4-system freezes immediately. > > Ok, before going into deep debugging make sure you are using the latest > modules (today's snapshot) and, more important, that you don't have > multiple > copies of them. Then I'll get the latest snapshot. I simply thought debugging with the existing one would at least give more compareable results in terms of a possible bug track-down. > Look into /lib/modules/`uname -r`/extra, you should see a directory for > each > module, if you see other modules or strange directories containing vISDN > modules please delete them and rerun depmod -a. Ok, everything seems fine here. At least from the file-structure > I've changed the way modules are compiled and installed and as a result > you > may have multiple copies of the modules in the modules dir. Seems that changes happened before my snapshot from Feb 10th. Nothing multiple in there. > Then, if you still experience freezes, the most straightforward debugging > technique is to connect your machine to another box via a null-modem > cable. > > Run minicom on both machines to test the connection. > > Boot the * machine appending "console=ttyS0,9600" to the kernel > parameters. > > On the other machine run minicom at 9600,8,N,1 and you should see some > boot > messages. Change 9600 to 115200 if you prefer. > > Finally make the * box hang, if you're not completely out of luck, the > OOPS > leading to the freeze should appear on the serial console. OK, all I need is a second linux machine then ;-) >Post it here > and > I'll try to "decode" it. I'll do my best! > Anyway, IRQ 58 is not wrong, some APIC is able to handle more than the > usual > number of IRQ lines, I just found out that booting the system with noapic has no effect on the behaviour at all. Only the assigned IRQ changes. The problems persist. "NUM CHANS: 0" is an old debugging message I've > forgot > in, you may ignore it. And ignored it is then. THX TOM > Bye, > _______________________________________________ > Visdn-hackers mailing list > [email protected] > https://mailman.uli.it/mailman/listinfo/visdn-hackers _______________________________________________ Visdn-hackers mailing list [email protected] https://mailman.uli.it/mailman/listinfo/visdn-hackers
