From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040608
Description of problem:
A kernel built with the "-O2" compiler flag, will lock up completely
when the PCMCIA driver is run at boot time. Put another way, kernel
builds require the compiler "-Os" option to work correctly. The use
of the "-Os" / "-O2" options is controlled by the
CONFIG_CC_OPTIMIZE_FOR_SIZE kernel configuration option. The PCMCIA
device in use is a modem card.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install kernel-2.6.6-1.427.i386.rpm package.
2. Work with a copy of the kernel source: cp -a linux-2.6.6-1.427/
3. Change current directory to /usr/src/linux-2.6.6-1.427custom
4. Copy /boot/config-2.6.6-1.427 to ./.config
5. Rebuild kernel and boot from new binary image. No problems seen.
6. Reboot back into FC2 kernel to rebuild copied kernel source.
7. Go back to the src directory and deselect
CONFIG_CC_OPTIMIZE_FOR_SIZE kernel option (I used menuconfig).
8. Rebuild kernel and boot from new binary image.
Actual Results: At boot time the PCMCIA base code initializes in the
course of the boot process. No errors are displayed. Further in the
boot process the serial_cs driver is loaded, the serial port is
recognized, then the machine freezes.
Expected Results: The kernel, and all its drivers, should initialize
The 8-step Steps-to-Reproduce looks complicated on "paper" but is
actually simple: make a copy of the kernel source, toggle the state of
CONFIG_CC_OPTIMIZE_FOR_SIZE, rebuild and reboot.
After you've locked up the newly built kernel, set
CONFIG_CC_OPTIMIZE_FOR_SIZE back to it's original enabled state,
rebuild and boot again. Now the problem is not seen. Either the
PCMCIA base code (modules pcmcia_core, yenta_socket) or the serial
driver (serial_cs) or both are mis-compiled when the compiler -O2
optimization is used.
This behavior was also seen with the previous FC2 kernel (2.6.5-1.358).
The behavior described above is on a FC2 system, installed with the
" Everything" package selection and all released FC2 updates applied.
are you sure everything got rebuild?
mixing -O2 kernels and -Os modules or vice versa is asking for trouble....
Yes, every modules is rebuilt. I didn't mention this in an effort to
keep the report as simple as possible, but I erased the generated
binaries ("rm -fr /boot/vmlinuz-2.6.6-1.427custom
/lib/modules/2.6.6-1.427custom/") between builds. I also did a "make
clean" in the source directory before each rebuild - yes, I'm anal.
I'm not using any third-party kernel modules, so everything is from
the FC2 sources.
Regarding the mixing of -O2 and -Os binaries, I feel certain that all
kernel code is built in the same manner. Perhaps the user-space
pcmcia-cs tools have a problem with how the modules are built, but I'm
not in a position to say. In prior version of RedHat releases,
through v9, the pcmcia-cs code was always built without -Ox switches
of any kind. If that is still the case, maybe it is the tools that
don't like the -O2 module(s)?
In any case, it is the CONFIG_CC_OPTIMIZE_FOR_SIZE config option that
makes the difference between a working system and a frozen one.
Since I've got the attention of a human (Hi, Arjan!), I will make one
more observation. The problem is not limited to the context of
booting. If I disable the pcmcia service from starting at boot time,
all is well. Manually starting the service ("service pcmcia start")
will again lock up the system as the serial_cs module is loaded.
Fedora Core 2 has now reached end of life, and no further updates will be
provided by Red Hat. The Fedora legacy project will be producing further kernel
updates for security problems only.
If this bug has not been fixed in the latest Fedora Core 2 update kernel, please
try to reproduce it under Fedora Core 3, and reopen if necessary, changing the
product version accordingly.