gcc and kernel build trouble report

gcc and kernel build trouble report

[Keith Mannthey]

Hello, 

  At the start of the week I moved kernels forwarded.  I tried
2.6.34-rc1 and 2.6.33-git15.  The lpfc fiber channel driver was failing
to load and generating a hardware level pci bus fault that was resetting
the server.  There is a small thread on linux-scsi from when I started. 

  Tried forward porting know working versions of the driver to the new
kernels but it did not fix the problem. I have to reason to suspect the
actual code in the driver is not really involved with the issue. 

  I booted whole older kernels until I sorted out that somewhere post
2.6.33 stock that issue started. I am not 100% sure where in the kernel
commits the problem starts I just know if is after 2.6.33. 

  It was identified that an alternate .config file worked and I decided
to dig on the config options. 

  I narrowed the config change down to:

CONFIG_CC_OPTIMIZE_FOR_SIZE

  I have to set CONFIG_CC_OPTIMIZE_FOR_SIZE=y else I get a pci fault
while failing to load the lpfc driver. As I understand this passes a
different -O flag to the build. 


Relevant details:

Hardware:  IBM x3550m2 server. Current Intel based 2 socket system,
nothing fancy. 

GCC:  gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) 

Kernels: For sure, 2.6.34-rc1, 2.6.33-git15 have the problem.  If the 10
or so 2.6.33 and before kernels trees I have booted I did not encounter
the issue. 

Config: CONFIG_CC_OPTIMIZE_FOR_SIZE=y or bad things happen. I booted a
ton of .config changes, 100% sure this is it, it has been triple
checked. 

  All in all not a fun experience and I don't really have the skills to
fix this issue.  I am going to try a different gcc version when I get a
few cycles. 

 Any suggestions on what to do with this gcc / kernel build issue? I
found it a little unsettling. 

Thanks,
 Keith Mannthey
 LTC FS-Dev 

Re: gcc and kernel build trouble report

[Mikael Pettersson]

Keith Mannthey writes:
 > Hello, 
 > 
 >   At the start of the week I moved kernels forwarded.  I tried
 > 2.6.34-rc1 and 2.6.33-git15.  The lpfc fiber channel driver was failing
 > to load and generating a hardware level pci bus fault that was resetting
 > the server.  There is a small thread on linux-scsi from when I started. 
 > 
 >   Tried forward porting know working versions of the driver to the new
 > kernels but it did not fix the problem. I have to reason to suspect the
 > actual code in the driver is not really involved with the issue. 
 > 
 >   I booted whole older kernels until I sorted out that somewhere post
 > 2.6.33 stock that issue started. I am not 100% sure where in the kernel
 > commits the problem starts I just know if is after 2.6.33. 
 > 
 >   It was identified that an alternate .config file worked and I decided
 > to dig on the config options. 
 > 
 >   I narrowed the config change down to:
 > 
 > CONFIG_CC_OPTIMIZE_FOR_SIZE
 > 
 >   I have to set CONFIG_CC_OPTIMIZE_FOR_SIZE=y else I get a pci fault
 > while failing to load the lpfc driver. As I understand this passes a
 > different -O flag to the build. 
 > 
 > 
 > Relevant details:
 > 
 > Hardware:  IBM x3550m2 server. Current Intel based 2 socket system,
 > nothing fancy. 
 > 
 > GCC:  gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) 
 > 
 > Kernels: For sure, 2.6.34-rc1, 2.6.33-git15 have the problem.  If the 10
 > or so 2.6.33 and before kernels trees I have booted I did not encounter
 > the issue. 
 > 
 > Config: CONFIG_CC_OPTIMIZE_FOR_SIZE=y or bad things happen. I booted a
 > ton of .config changes, 100% sure this is it, it has been triple
 > checked. 
 > 
 >   All in all not a fun experience and I don't really have the skills to
 > fix this issue.  I am going to try a different gcc version when I get a
 > few cycles. 
 > 
 >  Any suggestions on what to do with this gcc / kernel build issue? I
 > found it a little unsettling. 

Report it to SuSE, who apparently supplied the gcc-4.3.4 you're having
issues with.

You can also try using self-compiled vanilla gcc-4.3.4 or better 4.4.3.

And you can analyze the miscompilation and construct a user-mode test
case, although doing that can be difficult and time-consuming.