[beej@dell ~]$ cat /etc/redhat-release CentOS release 4.3 (Final) [beej@dell ~]$ rpm -qf `which gcc` gcc-3.4.5-2 [beej@dell linux-2.6.27.1]$ diff .config .config.old 4c4 < # Tue Oct 21 14:07:00 2008 --- > # Thu Oct 16 17:54:42 2008 1006c1006 < # CONFIG_SCSI_ENCLOSURE is not set --- > CONFIG_SCSI_ENCLOSURE=m using .config.old, [beej@dell linux-2.6.27.1]$ make <snip> Kernel: arch/x86/boot/bzImage is ready (#2) Building modules, stage 2. MODPOST 668 modules ERROR: "__you_cannot_kmalloc_that_much" [drivers/scsi/ses.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2
Reply-To: akpm@linux-foundation.org (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Tue, 21 Oct 2008 11:36:12 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=11800 > > Summary: building SES support fails w/ gcc-3.4.5 > Product: SCSI Drivers > Version: 2.5 > KernelVersion: 2.6.27.1 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: scsi_drivers-other@kernel-bugs.osdl.org > ReportedBy: bugzilla.kernel.org@beej.org > > > [beej@dell ~]$ cat /etc/redhat-release > CentOS release 4.3 (Final) > [beej@dell ~]$ rpm -qf `which gcc` > gcc-3.4.5-2 > [beej@dell linux-2.6.27.1]$ diff .config .config.old > 4c4 > < # Tue Oct 21 14:07:00 2008 > --- > > # Thu Oct 16 17:54:42 2008 > 1006c1006 > < # CONFIG_SCSI_ENCLOSURE is not set > --- > > CONFIG_SCSI_ENCLOSURE=m > > using .config.old, > [beej@dell linux-2.6.27.1]$ make > <snip> > Kernel: arch/x86/boot/bzImage is ready (#2) > Building modules, stage 2. > MODPOST 668 modules > ERROR: "__you_cannot_kmalloc_that_much" [drivers/scsi/ses.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > That's weird. It means that we did a kmalloc(N, ...) where the value of N is known at compile time, and N is too large. But I can find no such kmalloc/kzalloc calls in ses.c. It might be gcc bustage - we've seen that before. Please do make drivers/scsi/ses.s then have a look in drivers/scsi/ses.s and see which function is emitting a call to __you_cannot_kmalloc_that_much. Or email me drivers/scsi/ses.s and I'll take a look. Thanks.
Reply-To: beej@alum.mit.edu At 18:52 10/21/2008, Andrew Morton wrote: >On Tue, 21 Oct 2008 11:36:12 -0700 (PDT) >bugme-daemon@bugzilla.kernel.org wrote: > >> http://bugzilla.kernel.org/show_bug.cgi?id=11800 >> >> Summary: building SES support fails w/ gcc-3.4.5 >> Product: SCSI Drivers >> Version: 2.5 >> KernelVersion: 2.6.27.1 >> Platform: All >> OS/Version: Linux >> Tree: Mainline >> Status: NEW >> Severity: normal >> Priority: P1 >> Component: Other >> AssignedTo: scsi_drivers-other@kernel-bugs.osdl.org >> ReportedBy: bugzilla.kernel.org@beej.org >> >> >> [beej@dell ~]$ cat /etc/redhat-release >> CentOS release 4.3 (Final) >> [beej@dell ~]$ rpm -qf `which gcc` >> gcc-3.4.5-2 >> [beej@dell linux-2.6.27.1]$ diff .config .config.old >> 4c4 >> < # Tue Oct 21 14:07:00 2008 >> --- >> > # Thu Oct 16 17:54:42 2008 >> 1006c1006 >> < # CONFIG_SCSI_ENCLOSURE is not set >> --- >> > CONFIG_SCSI_ENCLOSURE=m >> >> using .config.old, >> [beej@dell linux-2.6.27.1]$ make >> <snip> >> Kernel: arch/x86/boot/bzImage is ready (#2) >> Building modules, stage 2. >> MODPOST 668 modules >> ERROR: "__you_cannot_kmalloc_that_much" [drivers/scsi/ses.ko] undefined! >> make[1]: *** [__modpost] Error 1 >> make: *** [modules] Error 2 >> > >That's weird. It means that we did a kmalloc(N, ...) where the value >of N is known at compile time, and N is too large. > >But I can find no such kmalloc/kzalloc calls in ses.c. It might be gcc >bustage - we've seen that before. > >Please do > > make drivers/scsi/ses.s > >then have a look in drivers/scsi/ses.s and see which function is >emitting a call to __you_cannot_kmalloc_that_much. Or email me >drivers/scsi/ses.s and I'll take a look. attached marc
Reply-To: akpm@linux-foundation.org On Wed, 22 Oct 2008 15:43:05 -0400 Marc Bejarano <beej@alum.mit.edu> wrote: > At 18:52 10/21/2008, Andrew Morton wrote: > >On Tue, 21 Oct 2008 11:36:12 -0700 (PDT) > >bugme-daemon@bugzilla.kernel.org wrote: > > > >> http://bugzilla.kernel.org/show_bug.cgi?id=11800 > >> > >> Summary: building SES support fails w/ gcc-3.4.5 > >> Product: SCSI Drivers > >> Version: 2.5 > >> KernelVersion: 2.6.27.1 > >> Platform: All > >> OS/Version: Linux > >> Tree: Mainline > >> Status: NEW > >> Severity: normal > >> Priority: P1 > >> Component: Other > >> AssignedTo: scsi_drivers-other@kernel-bugs.osdl.org > >> ReportedBy: bugzilla.kernel.org@beej.org > >> > >> > >> [beej@dell ~]$ cat /etc/redhat-release > >> CentOS release 4.3 (Final) > >> [beej@dell ~]$ rpm -qf `which gcc` > >> gcc-3.4.5-2 > >> [beej@dell linux-2.6.27.1]$ diff .config .config.old > >> 4c4 > >> < # Tue Oct 21 14:07:00 2008 > >> --- > >> > # Thu Oct 16 17:54:42 2008 > >> 1006c1006 > >> < # CONFIG_SCSI_ENCLOSURE is not set > >> --- > >> > CONFIG_SCSI_ENCLOSURE=m > >> > >> using .config.old, > >> [beej@dell linux-2.6.27.1]$ make > >> <snip> > >> Kernel: arch/x86/boot/bzImage is ready (#2) > >> Building modules, stage 2. > >> MODPOST 668 modules > >> ERROR: "__you_cannot_kmalloc_that_much" [drivers/scsi/ses.ko] undefined! > >> make[1]: *** [__modpost] Error 1 > >> make: *** [modules] Error 2 > >> > > > >That's weird. It means that we did a kmalloc(N, ...) where the value > >of N is known at compile time, and N is too large. > > > >But I can find no such kmalloc/kzalloc calls in ses.c. It might be gcc > >bustage - we've seen that before. > > > >Please do > > > > make drivers/scsi/ses.s > > > >then have a look in drivers/scsi/ses.s and see which function is > >emitting a call to __you_cannot_kmalloc_that_much. Or email me > >drivers/scsi/ses.s and I'll take a look. > > attached > OK, it's here: buf = kmalloc(vpd_len, GFP_KERNEL); it's a gcc bug. Please see if you can find some way to make it go away - perhaps change vpd_len's type to `int', things like that. Or use a different compiler version :(
Reply-To: James.Bottomley@HansenPartnership.com On Wed, 2008-10-22 at 13:30 -0700, Andrew Morton wrote: > OK, it's here: > > buf = kmalloc(vpd_len, GFP_KERNEL); > > it's a gcc bug. > > Please see if you can find some way to make it go away - perhaps change > vpd_len's type to `int', things like that. > > Or use a different compiler version :( Could it be an optimisation issue? The static oversize test relies on the compiler optimising away a leg that can never be reached if the size is under the max. If you do a make V=1 you'll see what optimisation flags the compiler is using ... if it's -O2 then yes, the compiler should be optimising stuff away and it's a clear compiler problem. If it's anything else, we might have a mis setting of the optimisation level in the kernel build. James
Reply-To: beej@alum.mit.edu At 17:17 10/22/2008, James Bottomley wrote: >On Wed, 2008-10-22 at 13:30 -0700, Andrew Morton wrote: >> OK, it's here: >> >> buf = kmalloc(vpd_len, GFP_KERNEL); >> >> it's a gcc bug. >> >> Please see if you can find some way to make it go away - perhaps change >> vpd_len's type to `int', things like that. >> >> Or use a different compiler version :( i'm not worried about compiling this. i already did a compilation without it and i'll be fine without SES. i just selected it on the off chance i'd find time to play with it. i was just doing my duty of reporting this to save others the trouble. >Could it be an optimisation issue? The static oversize test relies on >the compiler optimising away a leg that can never be reached if the size >is under the max. If you do a make V=1 you'll see what optimisation >flags the compiler is using ... if it's -O2 then yes, the compiler >should be optimising stuff away and it's a clear compiler problem. If >it's anything else, we might have a mis setting of the optimisation >level in the kernel build. looks to me like -Os: --- beej@dell linux-2.6.27.1]$ make V=1 drivers/scsi/ses.s rm -f include/config/kernel.release echo 2.6.27.1 > include/config/kernel.release set -e; :; mkdir -p include/linux/; (echo \#define LINUX_VERSION_CODE 132635; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';) < /usr/local/src/kernel/linux-2.6.27.1/Makefile > include/linux/version.h.tmp; if [ -r include/linux/version.h ] && cmp -s include/linux/version.h include/linux/version.h.tmp; then rm -f include/linux/version.h.tmp; else :; mv -f include/linux/version.h.tmp include/linux/version.h; fi set -e; :; mkdir -p include/linux/; if [ `echo -n "2.6.27.1" | wc -c ` -gt 64 ]; then echo '"2.6.27.1" exceeds 64 characters' >&2; exit 1; fi; (echo \#define UTS_RELEASE \"2.6.27.1\";) < include/config/kernel.release > include/linux/utsrelease.h.tmp; if [ -r include/linux/utsrelease.h ] && cmp -s include/linux/utsrelease.h include/linux/utsrelease.h.tmp; then rm -f include/linux/utsrelease.h.tmp; else :; mv -f include/linux/utsrelease.h.tmp include/linux/utsrelease.h; fi set -e; if [ -L include/asm ]; then asmlink=`readlink include/asm | cut -d '-' -f 2`; if [ "$asmlink" != "x86" ]; then echo "ERROR: the symlink include/asm points to asm-$asmlink but asm-x86 was expected"; echo " set ARCH or save .config and run 'make mrproper' to fix it"; exit 1; fi; fi if [ ! -L include/asm ]; then echo ' SYMLINK include/asm -> include/asm-x86'; if [ ! -d include/asm-x86 ]; then mkdir -p include/asm-x86; fi; ln -fsn asm-x86 include/asm; fi mkdir -p .tmp_versions make -f scripts/Makefile.build obj=scripts/basic make -f scripts/Makefile.build obj=. mkdir -p kernel/ mkdir -p arch/x86/kernel/ make -f scripts/Makefile.build obj=. missing-syscalls /bin/sh scripts/checksyscalls.sh gcc -Wp,-MD,./.missing-syscalls.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/3.4.5/include -D__KERNEL__ -Iinclude -I/usr/local/src/kernel/linux-2.6.27.1/arch/x86/include -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -m64 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Iinclude/asm-x86/mach-default -fomit-frame-pointer -g -Wdeclaration-after-statement -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(missing_syscalls)" -D"KBUILD_MODNAME=KBUILD_STR(missing_syscalls)" make -f scripts/Makefile.build obj=scripts make -f scripts/Makefile.build obj=scripts/genksyms make -f scripts/Makefile.build obj=scripts/mod make -f scripts/Makefile.build obj=drivers/scsi drivers/scsi/ses.s gcc -Wp,-MD,drivers/scsi/.ses.s.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/3.4.5/include -D__KERNEL__ -Iinclude -I/usr/local/src/kernel/linux-2.6.27.1/arch/x86/include -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -m64 -mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Iinclude/asm-x86/mach-default -fomit-frame-pointer -g -Wdeclaration-after-statement -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(ses)" -D"KBUILD_MODNAME=KBUILD_STR(ses)" -fverbose-asm -S -o drivers/scsi/ses.s drivers/scsi/ses.c --- i'm happy to run any other easy-to-do tests in case you don't have access to a CentOS 4 box, but it should be easy to repro for anybody else that does. cheers, marc
Reply-To: James.Bottomley@HansenPartnership.com On Thu, 2008-10-23 at 12:14 -0400, Marc Bejarano wrote: > At 17:17 10/22/2008, James Bottomley wrote: > >On Wed, 2008-10-22 at 13:30 -0700, Andrew Morton wrote: > >> OK, it's here: > >> > >> buf = kmalloc(vpd_len, GFP_KERNEL); > >> > >> it's a gcc bug. > >> > >> Please see if you can find some way to make it go away - perhaps change > >> vpd_len's type to `int', things like that. > >> > >> Or use a different compiler version :( > > i'm not worried about compiling this. i already did a compilation > without it and i'll be fine without SES. i just selected it on the > off chance i'd find time to play with it. i was just doing my duty > of reporting this to save others the trouble. > > >Could it be an optimisation issue? The static oversize test relies on > >the compiler optimising away a leg that can never be reached if the size > >is under the max. If you do a make V=1 you'll see what optimisation > >flags the compiler is using ... if it's -O2 then yes, the compiler > >should be optimising stuff away and it's a clear compiler problem. If > >it's anything else, we might have a mis setting of the optimisation > >level in the kernel build. > > looks to me like -Os: I think we have a winner: -Os is rather less well implemented in older versions of gcc. Could you retry with -O2? You do this by setting the config option CONFIG_CC_OPTIMIZE_FOR_SIZE to N (it defaults to Y). If we verify this to be the root cause, we might consider making the default for that option N if gcc version is < 4. James
Reply-To: beej@alum.mit.edu At 12:35 10/23/2008, James Bottomley wrote: >On Thu, 2008-10-23 at 12:14 -0400, Marc Bejarano wrote: >> At 17:17 10/22/2008, James Bottomley wrote: >> >On Wed, 2008-10-22 at 13:30 -0700, Andrew Morton wrote: >> >> OK, it's here: >> >> >> >> buf = kmalloc(vpd_len, GFP_KERNEL); >> >> >> >> it's a gcc bug. >> >> >> >> Please see if you can find some way to make it go away - perhaps change >> >> vpd_len's type to `int', things like that. >> >> >> >> Or use a different compiler version :( >> >> i'm not worried about compiling this. i already did a compilation >> without it and i'll be fine without SES. i just selected it on the >> off chance i'd find time to play with it. i was just doing my duty >> of reporting this to save others the trouble. >> >> >Could it be an optimisation issue? The static oversize test relies on >> >the compiler optimising away a leg that can never be reached if the size >> >is under the max. If you do a make V=1 you'll see what optimisation >> >flags the compiler is using ... if it's -O2 then yes, the compiler >> >should be optimising stuff away and it's a clear compiler problem. If >> >it's anything else, we might have a mis setting of the optimisation >> >level in the kernel build. >> >> looks to me like -Os: > >I think we have a winner: -Os is rather less well implemented in older >versions of gcc. Could you retry with -O2? > >You do this by setting the config option > >CONFIG_CC_OPTIMIZE_FOR_SIZE verified. setting CONFIG_CC_OPTIMIZE_FOR_SIZE=n in .config does allow ses.c to be compiled by gcc 3.4.5 from the CentOS 4 gcc-3.4.5-2 RPM. >If we verify this to be the root cause, we >might consider making the default for that option N if gcc version is < >4. marc