From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.1-0.1.9 i686) In the 2.4.2 kernel udelay is a macro that checks if you are attempting to pass a delay of >20000 and calls a non-existant a bad_udelay() function. The wavelan_cs module in drivers/net/pcmcia makes multiple calls to udelay but never with a value greater than 100. Yet, the compiler is making the calls to bad_udelay. Reproducible: Always Steps to Reproduce: 1. Compile the 2.4.2 kernel sources with no patches 2. nm -B /usr/src/linux/drivers/net/pcmcia/wavelan_cs.o | grep bad_udelay 3. Actual Results: U __bad_udelay Expected Results: Nothing
I remember fixing similar thing in gcc-2.96-72, are you sure you have say 2.96-75 or later? If yes, can you please attach here wavelan_cs.i (add -save-temps -v options to the gcc command which creates wavelan_cs.o) and also post full gcc command line used? It maybe config related etc., by working on preprocessed output we can be sure we're seeing the same thing. Thanks.
FYI I've just tried it and could not get __bad_udelay unresolved in any of -march=i386, -march=i686, -march=k6 or -march=athlon. So, I really need your feedback on this.
I WAS able to reproduce it consistently. I even tried applying the redhat patches to the wavelan driver to see if changing the function from inline to a macro made it better. It didn't. Today I've redone the compile several times and I can't make bad_udelay occur. Maybe there's an uninitialized variable somewhere and I can't reproduce the circumstances.
We (Red Hat) should really try to resolve this before next release.
If you are able to reproduce this, please reopen this bug.
This is reproducible with gcc 2.96-69. According to the maintainers of wavelan.c and include/asm-i386/delay.h it's a defect in that rev of gcc where __builtin_constant_p() doesn't work. 2.96-69 is what's currently on updates.redhat.com for 7.0. How hard is it to get a newer gcc released as a 7.0 update?