Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build failure on RHEL 9.4 kernel 5.14.0-427.16.1.el9_4.x86_64 #90

Open
AdiPircalabu opened this issue May 19, 2024 · 10 comments
Open

Build failure on RHEL 9.4 kernel 5.14.0-427.16.1.el9_4.x86_64 #90

AdiPircalabu opened this issue May 19, 2024 · 10 comments

Comments

@AdiPircalabu
Copy link

Appears to be the same failure as reported here: #89

$ git clone https://github.com/cisco/exanic-software
Cloning into 'exanic-software'...
remote: Enumerating objects: 3633, done.
remote: Counting objects: 100% (522/522), done.
remote: Compressing objects: 100% (240/240), done.
remote: Total 3633 (delta 283), reused 481 (delta 273), pack-reused 3111
Receiving objects: 100% (3633/3633), 1.85 MiB | 22.29 MiB/s, done.
Resolving deltas: 100% (2382/2382), done.
$ cd exanic-software/
$ make
make -C modules/exanic
make[1]: Entering directory '/data/psonic/adi/work/git/exanic-software/modules/exanic'
make -C /lib/modules/`uname -r`/build M=$PWD modules
make[2]: Entering directory '/usr/src/kernels/5.14.0-427.16.1.el9_4.x86_64'
  CC [M]  /data/psonic/adi/work/git/exanic-software/modules/exanic/exanic-main.o
/data/psonic/adi/work/git/exanic-software/modules/exanic/exanic-main.c: In function ‘exanic_probe’:
/data/psonic/adi/work/git/exanic-software/modules/exanic/exanic-main.c:1062:5: error: implicit declaration of function ‘pci_enable_pcie_error_reporting’ [-Werror=implicit-function-declaration]
 1062 |     pci_enable_pcie_error_reporting(pdev);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/data/psonic/adi/work/git/exanic-software/modules/exanic/exanic-main.c:1887:5: error: implicit declaration of function ‘pci_disable_pcie_error_reporting’ [-Werror=implicit-function-declaration]
 1887 |     pci_disable_pcie_error_reporting(pdev);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
make[3]: *** [scripts/Makefile.build:299: /data/psonic/adi/work/git/exanic-software/modules/exanic/exanic-main.o] Error 1
make[2]: *** [Makefile:1934: /data/psonic/adi/work/git/exanic-software/modules/exanic] Error 2
make[2]: Leaving directory '/usr/src/kernels/5.14.0-427.16.1.el9_4.x86_64'
make[1]: *** [Makefile:20: default] Error 2
make[1]: Leaving directory '/data/psonic/adi/work/git/exanic-software/modules/exanic'
make: *** [Makefile:9: modules] Error 2
$ uname -r
5.14.0-427.16.1.el9_4.x86_64
$
@danfruehauf
Copy link

Please see #91

Disclosure: I'm not an official maintainer or a Cisco employee.

@AdiPircalabu
Copy link
Author

Please see #91

Disclosure: I'm not an official maintainer or a Cisco employee.

Thanks @danfruehauf, that's very close to our patch. Changes from #85 and #87
exanic-software_el9_4.patch.gz

@danfruehauf
Copy link

@AdiPircalabu I can see that - must have missed your patch before I did that work.

It is very unfortunate that this is not fixed upstream by Cisco/Exablaze. As a client, I would expect a major distro like RHEL9 to have full support.

@tklinchik
Copy link

tklinchik commented Jul 31, 2024

The fix looks good on RHEL 9.4 but no longer compiles on RHEL 9.3:

exasock-bonding-sysfs.c:143:22: error: initialization of ‘ssize_t (*)(struct class *, struct class_attribute *, char *)’ {aka ‘long int (*)(struct class *, struct class_attribute *, char *)’} from incompatible pointer type ‘ssize_t (*)(const struct class *, const struct class_attribute *, char *)’ {aka ‘long int (*)(const struct class *, const struct class_attribute *, char *)’} [-Werror=incompatible-pointer-types]
143 | static CLASS_ATTR_RW(exabond_masters);
    |                      ^~~~~~~~~~~~~~~
include/linux/sysfs.h:104:19: note: in definition of macro ‘__ATTR’
104 |         .show   = _show,                                                \
    |                   ^~~~~
include/linux/device/class.h:200:53: note: in expansion of macro ‘__ATTR_RW’
200 |         struct class_attribute class_attr_##_name = __ATTR_RW(_name)
    |                                                     ^~~~~~~~~
modules/exasock/exasock-bonding-sysfs.c:143:8: note: in expansion of macro ‘CLASS_ATTR_RW’
143 | static CLASS_ATTR_RW(exabond_masters);
    |        ^~~~~~~~~~~~~
modules/exasock/exasock-bonding-sysfs.c:143:22: note: (near initialization for ‘class_attr_exabond_masters.show’)
143 | static CLASS_ATTR_RW(exabond_masters);
    |                      ^~~~~~~~~~~~~~~
include/linux/sysfs.h:104:19: note: in definition of macro ‘__ATTR’
104 |         .show   = _show,                                                \
    |                   ^~~~~
include/linux/device/class.h:200:53: note: in expansion of macro ‘__ATTR_RW’
200 |         struct class_attribute class_attr_##_name = __ATTR_RW(_name)
    |                                                     ^~~~~~~~~
modules/exasock/exasock-bonding-sysfs.c:143:8: note: in expansion of macro ‘CLASS_ATTR_RW’
143 | static CLASS_ATTR_RW(exabond_masters);
    |        ^~~~~~~~~~~~~
modules/exasock/exasock-bonding-sysfs.c:143:22: error: initialization of ‘ssize_t (*)(struct class *, struct class_attribute *, const char *, size_t)’ {aka ‘long int (*)(struct class *, struct class_attribute *, const char *, long unsigned int)’} from incompatible pointer type ‘ssize_t (*)(const struct class *, const struct class_attribute *, const char *, size_t)’ {aka ‘long int (*)(const struct class *, const struct class_attribute *, const char *, long unsigned int)’} [-Werror=incompatible-pointer-types]
143 | static CLASS_ATTR_RW(exabond_masters);
    |                      ^~~~~~~~~~~~~~~
include/linux/sysfs.h:105:19: note: in definition of macro ‘__ATTR’
105 |         .store  = _store,                                               \
    |                   ^~~~~~
include/linux/device/class.h:200:53: note: in expansion of macro ‘__ATTR_RW’
200 |         struct class_attribute class_attr_##_name = __ATTR_RW(_name)
    |                                                     ^~~~~~~~~
modules/exasock/exasock-bonding-sysfs.c:143:8: note: in expansion of macro ‘CLASS_ATTR_RW’
143 | static CLASS_ATTR_RW(exabond_masters);
    |        ^~~~~~~~~~~~~
modules/exasock/exasock-bonding-sysfs.c:143:22: note: (near initialization for ‘class_attr_exabond_masters.store’)
143 | static CLASS_ATTR_RW(exabond_masters);
    |                      ^~~~~~~~~~~~~~~
include/linux/sysfs.h:105:19: note: in definition of macro ‘__ATTR’
105 |         .store  = _store,                                               \
    |                   ^~~~~~
include/linux/device/class.h:200:53: note: in expansion of macro ‘__ATTR_RW’
200 |         struct class_attribute class_attr_##_name = __ATTR_RW(_name)
    |                                                     ^~~~~~~~~
modules/exasock/exasock-bonding-sysfs.c:143:8: note: in expansion of macro ‘CLASS_ATTR_RW’
143 | static CLASS_ATTR_RW(exabond_masters);

Something like this could work:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 14, 0) && ( defined(RHEL_RELEASE_CODE) && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9, 4) )
                     const struct class *c,
                     const struct class_attribute *cattr,
#elif LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 34)
                     struct class *c,
                     struct class_attribute *cattr,
#else
                     struct class *c,
#endif

@Alexxstud
Copy link

@danfruehauf @AdiPircalabu, hello, do you know by any chance if this repository is the only official source for libexanic? Maybe Cisco have some other sources for exanic-software, which they maintain properly, and GitHub has low priority.

@AlexeySaff
Copy link

with 9.5 release more and more problems are coming.

@AlexeySaff
Copy link

@danfruehauf @AdiPircalabu, hello, do you know by any chance if this repository is the only official source for libexanic? Maybe Cisco have some other sources for exanic-software, which they maintain properly, and GitHub has low priority.

I've received a reply from CISCO TAC that 9.4/9.5 not supported. Burn in hell CISCO. you always broke all good products :(

@Alexxstud
Copy link

@AlexeySaff, sad news, thanks for the information.

@AlexeySaff
Copy link

Please see #91

Disclosure: I'm not an official maintainer or a Cisco employee.

thank you for el94/95 fix!

@AlexeySaff
Copy link

"I regret to inform you that we have received an update from the engineering team, and unfortunately, it is not favourable news. The kernel upgrade required to support REL9.4 is currently targeted to be available in May 2025." - official CISCO reply :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants