Description of problem: The patch linux-2.6.9-ehea-Fixes-to-make-LRO-compile-in-RHEL-4.7.patch (-ehea: Fixes to make LRO compile in RHEL 4.7 (Ed Pollard) [300201]) adds new types in include/linux/types. These broke SANGOMA wanpipe driver build under x86_64 platforms (i386 not tested). Version-Release number of selected component (if applicable): 2.6.9-89.EL (since 2.6.9-68.26 in fact) How reproducible: build sangoma wanpipe modules&tools Steps to Reproduce: 1. download wanpipe Linux tools (drivers and userland tools) for Sangoma X.25 cards. 2. build again kernel-devel sources 3. process failed with following errors : Actual results: ../.. make[1]: Entering directory `/home/buildsys/wanpipe/wanpipe-3.1.0-b1/util/wanec_client' yacc -d wan_ec_arg.y lex -owan_ec_argl.c wan_ec_arg.l gcc -Wall -O2 -D__LINUX__ -DCONFIG_PRODUCT_WANPIPE_TDMV_EC -D_DEBUG_=2 -D_GNUC_ -I/usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include -I../../patches/kdrivers/wanec -I../../patches/kdrivers/include -I../../patches/kdrivers/wanec/oct6100_api/include -I../wanec_apilib -o wan_ec_client wan_ecmain.c y.tab.c wan_ec_argl.c ../wanec_apilib/wanec_api.c ../wanec_apilib/wanec_api_lib.c In file included from /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/if.h:22, from wan_ecmain.c:35: /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: error: syntax error before "__sum16" /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: warning: type defaults to `int' in declaration of `__sum16' /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: warning: data definition has no type or storage class /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: error: syntax error before "__wsum" /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: warning: type defaults to `int' in declaration of `__wsum' /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: warning: data definition has no type or storage class wan_ec_argl.c:1093: warning: 'yyunput' defined but not used In file included from /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/if.h:22, from ../wanec_apilib/wanec_api.c:35: /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: error: syntax error before "__sum16" /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: warning: type defaults to `int' in declaration of `__sum16' /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: warning: data definition has no type or storage class /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: error: syntax error before "__wsum" /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: warning: type defaults to `int' in declaration of `__wsum' /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: warning: data definition has no type or storage class In file included from /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/if.h:22, from ../wanec_apilib/wanec_api_lib.c:35: /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: error: syntax error before "__sum16" /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: warning: type defaults to `int' in declaration of `__sum16' /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:158: warning: data definition has no type or storage class /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: error: syntax error before "__wsum" /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: warning: type defaults to `int' in declaration of `__wsum' /usr/src/kernels/2.6.9-89.ellopac2-smp-x86_64/include/linux/types.h:159: warning: data definition has no type or storage class make[1]: *** [wan_ec_client] Error 1 make[1]: Leaving directory `/home/buildsys/wanpipe/wanpipe-3.1.0-b1/util/wanec_client' make: *** [all] Error 2 ../.. Expected results: compile w/o errors (we used w/o problem 2.6.9-57.EL before). Additional info: Problem seems to be the following addon: diff -uNr /usr/src/kernels/2.6.9-57.EL-smp-x86_64/include/linux/types.h /usr/src/kernels/2.6.9-89.EL-smp-x86_64/include/linux/types.h --- /usr/src/kernels/2.6.9-57.EL-smp-x86_64/include/linux/types.h 2004-10-18 23:55:06.000000000 +0200 +++ /usr/src/kernels/2.6.9-89.EL-smp-x86_64/include/linux/types.h 2009-06-08 14:23:31.000000000 +0200 @@ -155,6 +155,9 @@ #endif /* __KERNEL_STRICT_NAMES */ +typedef __u16 __bitwise __sum16; +typedef __u32 __bitwise __wsum; + /* * Below are truly Linux-specific types that should never collide with * any application/library that wants linux/types.h. This typedefs came with LRO patches in 68.26 release. It seems the typedefs should be added just 3 lines before, before the "#endif /* __KERNEL_STRICT_NAMES */". Actually, this solution corrects the problem but should it applicable for everyone ?
Created attachment 350084 [details] patch to properly define __bitwise Yep, looks like we don't define __bitwise in the right place. Please test with this patch. You can either apply it to the kernel sources, build it and install the new kernel and kernel-headers package, or you should be able to manually apply it to the in-place include file that you have now. Let me know how it goes and I'll post it for inclusion. Thanks!
Hi, According to me, it would be better to move the 2 new defines some line ealier than move the __bitwise block at the beginning of file, as it is close at the same place than in last 2.6.30/31. The problem is set by linux-2.6.9-ehea-Fixes-to-make-LRO-compile-in-RHEL-4.7.patch : @@ -155,6 +155,9 @@ typedef __u64 __bitwise __be64; #endif /* __KERNEL_STRICT_NAMES */ +typedef __u16 __bitwise __sum16; +typedef __u32 __bitwise __wsum; + /* * Below are truly Linux-specific types that should never collide with * any application/library that wants linux/types.h. Just modifying it (typedef before the __KERNEL_STRICT_NAMES endif corrects the problem and keeps the 'littlely modified by 1970 patchfiles' 2.6.9 sources more closed to vanilla's ones. ;-) As we used a patched kernel for sangoma drivers that satisfy ours internal tests, i can not take time now to rebuild one with your patch version (no time before holidays). I could done this in 3 weeks, with updated vgoyal's kernel srpms (if the RH team don't take some holidays too ;-)). Regards
Thats not in line with upstream, and my way is safer. __sum16 and __wsum are defined regardless of weather or not __KERNEL_STRICT_NAMES is undefined. If someone builds a kernel with the state of that define toggled, we loose those definitions, and the kernel can break. Upstream has removed the __KERNEL_STRICT_NAMES define from types.h entirely, but I can't safely do that in RHEL, so instead we move the CHECKER definition tobe global in scope rather than only defined for the strict names Please test the patch as is.
Humm __KERNEL_STRICT_NAMES should be keep for libc5 compatibility, no ? Btw do as you want. Also, I couldn't test it for 3 weeks but your patch should correct the problem.
yes, thats exactly what I'm saying. We can't remove the STRICT_NAMES define in RHEL since we need to preserve compatibility. You can't test this for three weeks? Fine, I'll find some tie to do it.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Committed in 89.44.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0263.html