DCCP module insertion issues

DCCP module insertion issues

[Julien.HUEBER]

Hello, 
I am currently working on DCCP in a research purpose but I am experiencing
new issues that I don't understand.
 
We already have a Test-Bed with a couple of machines working with the latest
version of the Linux Kernel (2.6.31-rc1) modified for DCCP, but when we
tried to install this kernel on another computer the DCCP module isn't
loading.
 
When we try to insert it manually we get the following error :
# sudo insmod dccp.ko
> insmod: error inserting 'dccp.ko' : -1 Socket type not supported
 
We saw on the mailing list that this error can be caused by the timer
resolution (on the post "dccp ccid3 : Runtime verification of timer
resolution"). Our clocksource was "tsc", but even when changing it to
"acpi_pm" (which is working just fine with DCCP on another machine) we are
still getting this error.
Moreover, DCCP used to work on this machine when an older version
(2.6.26-rc8) of the modified Kernel was installed.
 
So I am running out of idea about this problem, if anyone could explain me
what is the matter, or how can I get rid of it, it would be very helpful.
Thanks,
--
Julien Hueber
 
MSc student in internship at Thales Communications

Re: DCCP module insertion issues

[Arnaldo Carvalho de Melo]

Em Fri, Aug 21, 2009 at 10:22:45AM +0200, Julien.HUEBER@fr.thalesgroup.com escreveu:
> Hello, 
> I am currently working on DCCP in a research purpose but I am experiencing
> new issues that I don't understand.
>  
> We already have a Test-Bed with a couple of machines working with the latest
> version of the Linux Kernel (2.6.31-rc1) modified for DCCP, but when we
> tried to install this kernel on another computer the DCCP module isn't
> loading.
>  
> When we try to insert it manually we get the following error :
> # sudo insmod dccp.ko
> > insmod: error inserting 'dccp.ko' : -1 Socket type not supported

Lets try to see where in the insmod initiated sequence we can get such
an error:

We start by looking at the net/dccp/Makefile to see what are the object
files that are combined to generate dccp.ko:

obj-$(CONFIG_IP_DCCP) += dccp.o dccp_ipv4.o

dccp-y := ccid.o feat.o input.o minisocks.o options.o output.o proto.o timer.o

#
# CCID algorithms to be used by dccp.ko
#
# CCID-2 is default (RFC 4340, p. 77) and has Ack Vectors as dependency
dccp-y += ccids/ccid2.o ackvec.o

Ok, so if we set CONFIG_IP_DCCP to M, as is in most linux distros:

[acme@doppio linux-2.6-tip]$ grep ^CONFIG_IP_DCCP= /boot/config-2.6.29.6-217.2.7.fc11.x86_64 
CONFIG_IP_DCCP=m
[acme@doppio linux-2.6-tip]$ rpm -qf /boot/config-2.6.29.6-217.2.7.fc11.x86_64
kernel-2.6.29.6-217.2.7.fc11.x86_64
[acme@doppio linux-2.6-tip]$

We see we have to look at:

net/dccp/{dccp_ipv4,ccid,feat,input,minisocks,options,output,proto,timer,ackvec,ccids/ccid2}.c

for a module_init marked routine:

grep module_init net/dccp/{ipv4,ccid,feat,input,minisocks,options,output,proto,timer,ackvec,ccids/ccid2}.c

[acme@doppio linux-2.6-tip]$ grep module_init net/dccp/{ipv4,ccid,feat,input,minisocks,options,output,proto,timer,ackvec,ccids/ccid2}.c
net/dccp/ipv4.c:module_init(dccp_v4_init);
net/dccp/proto.c:module_init(dccp_init);
[acme@doppio linux-2.6-tip]$

The first one is a leftover from when dccp_ipv4.ko existed, now it is always
linked with dccp.ko, put that aside and lets look at dccp_init:

There is no return -ESOCKTNOSUPPORT...

The only place where I can think this could happen is if you tried to create an
AF_INET, SOCK_DCCP, then inet_create would try to autoload this module and then
for some reason the module wouldn't be found or SELinux wouldn't allow the user
to load it (recent development).

Is this with the test tree from Gerrit or using just what is in Linus's tree?

> We saw on the mailing list that this error can be caused by the timer
> resolution (on the post "dccp ccid3 : Runtime verification of timer
> resolution"). Our clocksource was "tsc", but even when changing it to
> "acpi_pm" (which is working just fine with DCCP on another machine) we are
> still getting this error.
> Moreover, DCCP used to work on this machine when an older version
> (2.6.26-rc8) of the modified Kernel was installed.
>  
> So I am running out of idea about this problem, if anyone could explain me
> what is the matter, or how can I get rid of it, it would be very helpful.
> Thanks,
> --
> Julien Hueber
>  
> MSc student in internship at Thales Communications
> --
> To unsubscribe from this list: send the line "unsubscribe dccp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: DCCP module insertion issues

[Gerrit Renker]

| > insmod: error inserting 'dccp.ko' : -1 Socket type not supported
|  
| We saw on the mailing list that this error can be caused by the timer
| resolution (on the post "dccp ccid3 : Runtime verification of timer
| resolution"). Our clocksource was "tsc", but even when changing it to
| "acpi_pm" (which is working just fine with DCCP on another machine) we are
| still getting this error.
There is an easy way to see whether the problem is caused by the timer: can
you check the syslog (/var/log/messages) for a message like

 kernel: Timer too coarse \d+ usec, need 10-usec resolution - check your clocksource

If yes, then it can be resolved via the timer resolution, if not, then the cause
is a different problem - such as explained by Arnaldo.

Should it be a timer problem, you should still be able to load dccp_ccid2
since the high-resolution timers are only needed by CCID-3.

Can you please verify if you see such a message in your logs?

| Moreover, DCCP used to work on this machine when an older version
| (2.6.26-rc8) of the modified Kernel was installed.
That is over a year ago, quite a few things have changed.

RE: DCCP module insertion issues

[Julien.HUEBER]

Thank you both for your answers.

We are using latest version of Gerrit DCCP test tree pulled from http://eden-feed.erg.abdn.ac.uk/.

We found out that -ESOCKTNOSUPPORT is returned by routine ccid_initialize_builtins in net/dccp/ccid.c if the timer resolution is too low.
Our problem is that whatever the available clocksource used (tsc, acpi_pm, pit or jiffies) we always have an error and the following message in the syslog :

Timer too coarse (999 usec), need 10-usec resolution - check your clocksource

We now have to find out whether it is possible to modify the timer resolution.

Thanks,
Julien.

Re: DCCP module insertion issues

[Gerrit Renker]

| Our problem is that whatever the available clocksource used (tsc, acpi_pm, pit or jiffies) 
| we always have an error and the following message in the syslog :
| 
| Timer too coarse (999 usec), need 10-usec resolution - check your clocksource
| 
It is not necessarily only a kernel configuration problem. There are a number of boot command options which also
influence the timer. I have found a useful test to do a "cat /proc/timer_list", on my laptop a ".resolution" of
1 nsecs is reported for both clocks on each core; as 'Clock Event Device', "hpet" and "lapic" are reported.

In my .conf, I have such things as
CONFIG_HIGH_RES_TIMERS=y
CONFIG_HPET_TIMER=y
(both are available via 'Processor type and features').

A number of people have stumbled over this, but all have been able to get it working with just minor
configuration changes. 

Eventually it is planned to get rid of the high-resolution timer support altogether, but it is a big
change, so it may not be in the immediate future. It is not a good idea to disable the warning, it
has been put in after experiencing very strange bugs such as negative RTT values, see
http://archive.netbsd.se/?ml=linux-netdev&a 08-07&m€81317

RE: DCCP module insertion issues

[Julien.HUEBER]

You were right, the timer_list indicates that I have a .resolution of 999484 nsecs, which can explain why I had a value of 999 usec in the error message of the log.

I set my .config file fields as yours and recompiled but the value of .resolution is still the same. Despite that I can at least identify where the problem is now. 

Thank you.