28 Sep
2010
28 Sep
'10
10:08 p.m.
Hi Patrick
I solved start up the daemon Asterisk (in CLI mode )with your
recomendation:
.......................................netlink: cluster0: mode FP ARI:
class A: EMC: 1182 FPN: 0fac2
LCE: registered protocol 0 (Link Control)
LCE: registered protocol 3 (Call Control)
LCE: registered protocol 4 (Call Independant Supplementary Services)
LCE: registered protocol 6 (ConnectionLess Message Service)
LCE: registered protocol 5 (Mobility Management)
.......*CLI> . ]
Asterisk Ready.
The oops call trace generated for kerneloops is the next one:
Sep 28 02:26:23 R40 kernel: [ 2030.372490] Pid: 22159, comm:
lt-dect-cell-de Not tainted 2.6.36-rc5+ #1 27232FG/27232FG
Sep 28 02:26:23 R40 kernel: [ 2030.372584] EIP: 0060:[<e0c60b65>] EFLAGS:
00010286 CPU: 0
Sep 28 02:26:23 R40 kernel: [ 2030.372664] EIP is at
dect_cluster_unbind_cell+0x8/0x1c [dect]
Sep 28 02:26:23 R40 kernel: [ 2030.372732] EAX: 00200200 EBX: def95000
ECX: 00100100 EDX: def95020
Sep 28 02:26:23 R40 kernel: [ 2030.372808] ESI: ded21600 EDI: d7a74900
EBP: df2ebc88 ESP: df2ebc88
Sep 28 02:26:23 R40 kernel: [ 2030.372884] DS: 007b ES: 007b FS: 00d8 GS:
0033 SS: 0068
Sep 28 02:26:23 R40 kernel: [ 2030.372951] Process lt-dect-cell-de (pid:
22159, ti=df2ea000 task=de06f510 task.ti=df2ea000)
Sep 28 02:26:23 R40 kernel: [ 2030.373049] Stack:
Sep 28 02:26:23 R40 kernel: [ 2030.373077] df2ebc9c e0c6ad67 def95000
ded21600 d7a74900 df2ebcb0 e0c5fdda ded21600
Sep 28 02:26:23 R40 kernel: [ 2030.373151] <0> e0c5fd80 00000064 df2ebcf4
e0c5f864 df2ebd04 c11cd396 00000000 ded21614
Sep 28 02:26:23 R40 kernel: [ 2030.373151] <0> 00000000 00000000 00000000
df2ebcf4 e0c5f7d2 df2ebcdc d7a74900 df2ebcc0
Sep 28 02:26:23 R40 kernel: [ 2030.373151] Call Trace:
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<e0c6ad67>] ?
dect_cell_shutdown+0x17/0x142 [dect]
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<e0c5fdda>] ?
dect_del_cell+0x5a/0x9b [dect]
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<e0c5fd80>] ?
dect_del_cell+0x0/0x9b [dect]
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<e0c5f864>] ?
dect_netlink_rcv_msg+0xd4/0xdf [dect]
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c11cd396>] ?
__skb_recv_datagram+0xca/0x1c4
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<e0c5f7d2>] ?
dect_netlink_rcv_msg+0x42/0xdf [dect]
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<e0c5f790>] ?
dect_netlink_rcv_msg+0x0/0xdf [dect]
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c11ea03d>] ?
netlink_rcv_skb+0x30/0x76
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<e0c5f455>] ?
dect_netlink_rcv+0x1b/0x22 [dect]
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c11e9dee>] ?
netlink_unicast+0x1a4/0x205
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c11ea4fe>] ?
netlink_sendmsg+0x246/0x294
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c11c4e58>] ?
sock_sendmsg+0xcc/0xe7
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c1022489>] ?
kmap_atomic_prot+0xc4/0xc6
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c11c6370>] ?
move_addr_to_kernel+0x3e/0x43
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c11cc7cf>] ?
verify_iovec+0x3e/0x6b
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c11c5037>] ?
sys_sendmsg+0x149/0x196
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c108df4b>] ?
filemap_fault+0x79/0x32e
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c108dc2d>] ?
unlock_page+0x3e/0x41
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c109efb4>] ?
__do_fault+0x34f/0x37b
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c109fe16>] ?
handle_mm_fault+0x389/0x741
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c11c8c67>] ?
sock_setsockopt+0x549/0x556
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c101e8b5>] ?
do_page_fault+0x0/0x30c
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c101eb93>] ?
do_page_fault+0x2de/0x30c
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c11c66a6>] ?
sys_socketcall+0x15e/0x1a8
Sep 28 02:26:23 R40 kernel: [ 2030.373151] [<c1002f38>] ?
sysenter_do_call+0x12/0x28
Sep 28 02:26:23 R40 kernel: [ 2030.373151] Code: 8b 91 e4 01 00 00 eb 07
39 42 14 74 0e 89 da 8b 1a 0f 18 03 90 39 f2 75 ef eb 04 85 d2 75$
Sep 28 02:26:23 R40 kernel: [ 2030.373151] EIP: [<e0c60b65>]
dect_cluster_unbind_cell+0x8/0x1c [dect] SS:ESP 0068:df2ebc88
Sep 28 02:26:23 R40 kernel: [ 2030.373151] CR2: 0000000000100104
Sep 28 02:26:23 R40 kernel: [ 2030.476778] ---[ end trace 14bfbaf42000bf11
]---
Remember that this process ONLY ocurred when i delete fisrt the object
cluster0 before cell0. At this moment i need restart the computer because
it doesn´t respond, if i delete first the object cell0 and then the
container cluster0 dont do kerneloop.
Thanks Patrick
Oscar Soriano
On Tue, 28 Sep 2010 17:26:19 +0200, Patrick McHardy <kaber(a)trash.net>
wrote:
table
get
table
and
Am 28.09.2010 01:04, schrieb Oscar Soriano Riera:
> I see a curious startup with the new stack of Dect protocol. I have one
> laptop (Debian+Dect DOSCH-AMAND pcmcia radio U2785B) and a computer
> with DOSCH-AMAND PCI with the same kernel and compilation
>
> I do all instructions of http://dect.osmocom.org/README. When finish
all
> configurations and start the daemon Asterix in
debug mode i can see the
> next event on the log:
>
> 1) Start the daemon:
>
> # /etc/init.d/asterisk debug
>
>
> == Registered channel type 'DECT' (Digital Enhanced Cordless
> Telecommunications (DECT))
> == Parsing '/etc/asterisk/dect.conf': == Found
> -- Registered extension context 'dect_register' (0xc548c10) in
table
0xc5b21c0;
registrar: DECT
-- Added extension '601' priority 1 to dect_register (0xc548c10)
-- Added extension '602' priority 1 to dect_register (0xc548c10)
-- Added extension '603' priority 1 to dect_register (0xc548c10)
*dect_netlink_init: Object not found*
This indicates the cluster doesn't exist.
> *[Sep 28 00:31:22] ERROR[20318]: chan_dect.c:1905 dect_load_module:
> Unable to initialize DECT handle*
>
> 2)Here's what I think that first create the cluster, and proceed to
> activate FP mode to realize the call server:
>
> #dect-cluster-add --name cluster0 --emc 0x1182 --fpn 0x0fac2 --mode fp
> #dect-cell-add --name cell0 --cluster cluster0
> #dect-transceiver-bind --transceiver trx0 --cell cell0
>
> 3) Launch another time Asterix in Debug, and failed too:
>
> # /etc/init.d/asterisk debug
>
>
> == Registered channel type 'DECT' (Digital Enhanced Cordless
> Telecommunications (DECT))
> == Parsing '/etc/asterisk/dect.conf': == Found
> -- Registered extension context 'dect_register' (0xbfc4d50) in
0xbebd608;
registrar: DECT
-- Added extension '601' priority 1 to dect_register (0xbfc4d50)
-- Added extension '602' priority 1 to dect_register (0xbfc4d50)
-- Added extension '603' priority 1 to dect_register (0xbfc4d50)
*LCE: dect_lce_init: Permission denied*
Asterisk is dropping permissions at startup, so you're unable to
bind to the cluster. Try starting it as root using "asterisk -pfc".
I'll look into fixing this, AFAIK asterisk retains the CAP_NET_ADMIN
capability, so I'll probably adjust the permission checks to accept
that.
> *[Sep 28 00:33:56] ERROR[20438]: chan_dect.c:1905 dect_load_module:
> Unable to initialize DECT handle*
>
> 4) The posible Workaround (I think that all my config is correct) to up the daemon
Asterix is do this order:
*delete the cluster:*
#dect-cluster-delete --name cluster0
#dect-cell-delete --cell cell0
*Detected broadcast message for all:*
Message from syslogd@WIFI at Sep 28 00:36:12 ...
kernel:[42723.933296] Oops: 0000 [#1] SMP
Message from syslogd@WIFI at Sep 28 00:36:12 ...
kernel:[42723.933318] last sysfs file: /sys/module/nfnetlink/initstate
Message from syslogd@WIFI at Sep 28 00:36:12 ...
kernel:[42723.934154] Process lt-dect-cell-de (pid: 20504, ti=d7a0a000
task=f6b64c70 task.ti=d7a0a000)
Message from syslogd@WIFI at Sep 28 00:36:12 ...
kernel:[42723.934184] Stack:
Message from syslogd@WIFI at Sep 28 00:36:12 ...
kernel:[42723.934361] Call Trace:
Message from syslogd@WIFI at Sep 28 00:36:12 ...
kernel:[42723.934927] Code: 39 83 08 02 00 00 74 07 89 d8 e8 04 da ff
ff 8d 65 f4 5b 5e 5f 5d c3 55 89 e5 57 56 53 89 c3 8b 40 28 85 c0 74 08
8b 08 8d 53 20 <ff> 51 04 0f b7 83 b4 03 00 00 31 f6 85 c0 74 48 83 ca
ff 0f bc
Message from syslogd@WIFI at Sep 28 00:36:12 ...
kernel:[42723.935158] EIP: [<f8452d64>] dect_cell_shutdown+0x14/0x142
[dect] SS:ESP 0068:d7a0bc90
Message from syslogd@WIFI at Sep 28 00:36:12 ...
kernel:[42723.935203] CR2: 0000000000000004
Please send the full oops message.
> 5)Then start daemon on debug
> *#/etc/init.d/asterisk debug*
>
> func_blacklist.so => (Look up Caller*ID name/number from blacklist
> database)
> == Registered channel type 'DECT' (Digital Enhanced Cordless
> Telecommunications (DECT))
> == Parsing '/etc/asterisk/dect.conf': == Found
> -- Registered extension context 'dect_register' (0xd3bcd50) in
0xd2b5608;
registrar: DECT
-- Added extension '601' priority 1 to dect_register (0xd3bcd50)
-- Added extension '602' priority 1 to dect_register (0xd3bcd50)
-- Added extension '603' priority 1 to dect_register (0xd3bcd50)
And then the Daemon start "apparently" correct
Some questions:
1) its posible that need create the cluster,cell and Rtx before launch
Asterix ?
Yes, that's how its supposed to work.
> 2)Its posible that need create all the componets of the cluster with only with user
as asterisk?
3) When i run "*nl-link-list" *i can see all interfaces , but i cant
see "a dect interface" , its is normal ?
# ./nl-link-list
lo loopback <loopback,up,running,lowerup>
eth0 ether 00:06:1b:de:ee:4c <broadcast,multicast>
eth1 ether 00:0c:f1:28:60:f4 <broadcast,multicast,up,running,lowerup>
pan0 ether 6a:08:e2:74:24:db <broadcast,multicast>
There is dect-cluster-list, dect-cell-list and dect-transceiver-list
for listing the respective DECT components.