Red Hat Bugzilla – Bug 97529
gcc miscompiles O_DIRECT code in kernel 2.4.*
Last modified: 2007-04-18 12:54:52 EDT
From Bugzilla Helper:
User-Agent: Opera/7.11 (Linux 2.4.20-18.9 i686; U) [en]
Description of problem:
After many experiments I've come to te conclusion that the RH9
gcc does not correctly compile the O_DIRECT functionality in
the 2.4 kernel.
I have an application that uses O_DIRECT on a partition without
a filesystem. The application runs on a Geode GX1 (= i586
compatible) target system. It runs from a CompactFlash with
only a kernel and some statically linked binaries.
Things have worked without problems when using RH 7.3 as the
development platform. But after upgrading to RH 9 a mysterious
O_DIRECT problem appeared: any read() will only return zeroes
(no errors, just all zeroes as data). Reading the same data
area without O_DIRECT will give the correct data.
I found out that the O_DIRECT functionality is completely disabled
in RH's own modern RH9 kernels (by a patch in the kernel SRPM).
I don't know if this was done because the SRPM maintainer knows
about RH9-gcc-O_DIRECT problems (he did not answer my question
why this was changed).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. compile a 2.4 kernel on RH9 (tested several version including
latest 2.4.21-ac1 and various RH kernel trees)
2. read data from partition with read & O_DIRECT enabled
Actual Results: read() only gives 0x00 0x00 ... data back
Expected Results: The actual data that *is* in the partition
I compiled a 2.4.21-ac1 kernel on a RH7.3 system and that
made the problem go away.
Both my RH9 & RH7.3 systems are up-to-date and well-maintained
with all RH errata-patches applied.
RH9 system: PIII, 600MHz
RH7.3 system: Pentium, 133 MHz
Target system: Geode GX1 board, kernel compiled for i586
running only statically compiled applications.
Concerning O_DIRECT usage: yes I know about the data alignment
requirements: they are fulfilled ! (can produce demo program
As suggested on the Linux kernel mailing list I tried to
compile with gcc-3.3. This makes the problem go away.
I used the Rawhide gcc-3.3-7 packages.
Rob van Nieuwkerk
Fixed in 3.3 you say? Excellent.