ISDN4BSD (HPS version) is going into ports

[Andreas Longwitz]

Hi Hans,

>> 1. example: Default options + SPPP + RBCH, crash on kldload i4b, test PC
>> without isdn hardware:
>>
> I cannot reproduce this crash over here. I think it is not a bug in I4B, but rather
> some hardware generating spurious interrupts when probing! Loading I4B will cause a
> re-probe of existing devices with no driver attached.

OK, the re-probe of the existing devices is done by the kernel because a
DRIVER_MODULE is loaded via kldload, or did you some special programming
for this ?

> The I4B module as a whole cannot be unloaded, it requires a reboot. Some parts of I4B supports unload, but others not.
> A crash at this point is like expected. However it is possible in theory to split I4B into separate modules,
> which can be loaded/unloaded, but not the core itself currently.

So it seems a little bit safer to load i4b - or any other DRIVER_MODULE
- via loader.conf, because the re-probe must not be done.

> I believe the SPPP functionality has not been tested for a while.
In the meantime I found the reason for my troubles with i4b + sppp on
incoming calls:

There was a commit for if_spppsubr.c (Revision 1.222) with the text:
Use monotonic time_uptime instead of 'time_second' as timebase for timeouts.
After changing in i4b_global.h from
     #define SECOND                time_second
to   #define SECOND                time_uptime
the problem was gone.

One bagatelle is left: On every incoming call I see in /var/log/messages
kernel: i4b-L3 dss1_decode_q931_cs0_ie_cd: IEI_BEARERCAP - Unsupported
        B-Sub-Protocol 0x00
kernel: i4b: unit 0, assigned TEI = 253 = 0xfd (example),

but the incoming SETUP frame is ok. Can you give me a hint how to deal
with this ? In /etc/isdn/isdnd.rc I do not have any subaddress specific
parameters.

-- 
Andreas Longwitz