| > is there any news regarding the CCID/module loading problem on the 64
| > bit computer with 32 bit kernel?
| >
<snip>
| Hello Gerrit,
| yes! I think that we found the commit that inserted the problem (probably).
|
| This is the list of commits, the first time that the problem
| occurs is in "f76fd327a8b32d3ad5b51639faf6f54d18be0981". I'm sending
| to you the tree commits before the BAD that it is working properly.
|
| - BAD - Gerrit Renker f76fd327a8b32d3ad5b51639faf6f54d18be0981 dccp
Ah that would explain it. Did you check the logs - if the not-loading
was due to low timer resolution, then there should be a message like
"Timer to coarse (xxx usec), need 10usec".
If that is the case,
1. does the problem disappear when commenting out
'return -ESOCKTNOSUPPORT' in ccid3_module_init() below or if
2. the kernel is compiled with support for high-resolution timers?
+ if (tp.tv_sec || tp.tv_nsec > DCCP_TIME_RESOLUTION * NSEC_PER_USEC) {
+ printk(KERN_ERR "%s: Timer too coarse (%ld usec), need %u-usec"
+ " resolution - check your clocksource.\n", __func__,
+ tp.tv_nsec/NSEC_PER_USEC, DCCP_TIME_RESOLUTION);
+ return -ESOCKTNOSUPPORT;
+ }
Thanks a lot for following this up, this now looks a much more likely cause.
Gerrit
--
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
