Cross-Compiling mn10300: Assembler messages: junk at end of line: 0
Hi, defconfig build: + make ARCH=mn10300 HOSTCC=gcc-4.0 CROSS_COMPILE=mn10300-elf- CROSS32_COMPILE= O=../2.6.25-rc1-mn10300/ Using /usr/src/xtest/linux-2.6 as source for kernel GEN /usr/src/xtest/2.6.25-rc1-mn10300/Makefile CHK include/linux/version.h CHK include/linux/utsrelease.h CALL/usr/src/xtest/linux-2.6/scripts/checksyscalls.sh CHK include/linux/compile.h AS arch/mn10300/kernel/kernel_execve.o /usr/src/xtest/linux-2.6/arch/mn10300/kernel/kernel_execve.S: Assembler messages: /usr/src/xtest/linux-2.6/arch/mn10300/kernel/kernel_execve.S:33: Error: junk at end of line: `0' /usr/src/xtest/linux-2.6/arch/mn10300/kernel/kernel_execve.S:34: Error: junk at end of line, first unrecognized character is `m' make[2]: *** [arch/mn10300/kernel/kernel_execve.o] Error 1 make[1]: *** [arch/mn10300/kernel] Error 2 make: *** [sub-make] Error 2 Expected? Toolchain problem? Tools from ftp.redhat.com, Version 3.4-am33-04r2-5. Host is x86. Thanks, Jan Dittmer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
emu10k1 and 8139oo with 2.4.0test13pre3
Hello, I'm using the emu10k1 module with my SB Live. This works quite fine, but I cannot switch the recording channel. This worked with 2.2.17. Now volume works, but selecting the input channel not anymore. is anyone else experiencing this problem , or don't i just get the right setting? second, i habe 2 nics in my K6-2 system, both with rtl8139 chip and compiled 8139oo into the kernel. the cards work fine, but dmesg says: eth0: Abnormal interrupt, status 2002 and eth0: Abnormal interrupt, status 0020 endless times. Usually about 2-3 entries per minute. The cards work fine, so how can I get rid of the message, other then uncommenting the line in the source code? This also happens if I compile the driver as module. And happened sind 2.4.0-test12 (the first 2.4.0er I installed). This is my first post on this list. If you need additional information, I'd like to provide it. So far, Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm1
> bk-kbuild.patch Something has broken make O= : $ make mrproper $ mkdir /tmp/42 $ make ARCH=alpha CROSS_COMPILE=alpha-linux- O=/tmp/42 defconfig $ make ARCH=alpha CROSS_COMPILE=alpha-linux- O=/tmp/42 Using /home/jdittmer/src/lk/linus as source for kernel GEN/tmp/42/Makefile CHK include/linux/version.h SYMLINK /tmp/42/include/asm -> include/asm-alpha SPLIT include/linux/autoconf.h -> include/config/* CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/modpost.o HOSTCC scripts/mod/sumversion.o HOSTLD scripts/mod/modpost HOSTCC scripts/kallsyms HOSTCC scripts/conmakehash make[1]: *** No rule to make target `include/asm', needed by `arch/alpha/kernel/asm-offsets.s'. Stop. make: *** [_all] Error 2 Happens for most archs. See http://l4x.org/k/ Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm2
Andrew Morton wrote: > create-a-kstrdup-library-function.patch > create a kstrdup library function > > create-a-kstrdup-library-function-fixes.patch > create-a-kstrdup-library-function-fixes ppc defconfig build is broken due to this make ARCH=ppc CROSS_COMPILE=powerpc-linux- O=/usr/src/ctest/mm/out/ppc CC arch/ppc/boot/openfirmware/dummy.o GEN arch/ppc/boot/openfirmware/image.o AS arch/ppc/boot/openfirmware/coffcrt0.o CC arch/ppc/boot/openfirmware/start.o AS arch/ppc/boot/openfirmware/misc.o CC arch/ppc/boot/openfirmware/common.o CC arch/ppc/boot/openfirmware/coffmain.o COFFarch/ppc/boot/openfirmware/coffboot lib/lib.a(string.o)(.text+0x5cc): In function `kstrdup': : undefined reference to `__kmalloc' COFFarch/ppc/boot/images/vmlinux.coff powerpc-linux-objcopy: 'arch/ppc/boot/openfirmware/coffboot': No such file make[3]: *** [arch/ppc/boot/images/vmlinux.coff] Error 1 make[2]: *** [openfirmware] Error 2 make[1]: *** [zImage] Error 2 make: *** [_all] Error 2 See http://l4x.org/k/?d=3218 Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm2
Andrew Morton wrote: > - The bk-acpi patch here causes my ia64 test box to hang during boot > bk-ia64.patch ia64 defconfig does not even build anymore: CC [M] drivers/char/agp/hp-agp.o In file included from /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:18: include2/asm/acpi-ext.h:15: error: parse error before "hp_acpi_csr_space" include2/asm/acpi-ext.h:15: error: parse error before "u64" include2/asm/acpi-ext.h:15: warning: type defaults to `int' in declaration of `hp_acpi_csr_space' include2/asm/acpi-ext.h:15: warning: function declaration isn't a prototype include2/asm/acpi-ext.h:15: warning: data definition has no type or storage class /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c: In function `hp_zx1_configure': /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:255: warning: large integer implicitly truncated to unsigned type /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c: At top level: /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:477: warning: type defaults to `int' in declaration of `acpi_status' /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:477: error: parse error before "zx1_gart_probe" /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:480: warning: type defaults to `int' in declaration of `status' /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:480: warning: data definition has no type or storage class /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:486: warning: type defaults to `int' in declaration of `status' /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:486: error: `obj' undeclared here (not in a function) /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:486: error: initializer element is not constant /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:486: warning: data definition has no type or storage class /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:487: error: parse error before "if" /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:491: warning: type defaults to `int' in declaration of `handle' /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:491: error: `obj' undeclared here (not in a function) /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:491: warning: data definition has no type or storage class /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:492: error: parse error before "do" /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:494: warning: type defaults to `int' in declaration of `status' /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:494: error: redefinition of `status' /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:486: error: `status' previously defined here /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:494: warning: implicit declaration of function `acpi_get_object_info' /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:494: error: initializer element is not constant /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:494: warning: data definition has no type or storage class /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:495: error: parse error before "if" /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:499: warning: type defaults to `int' in declaration of `match' /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:499: error: dereferencing pointer to incomplete type /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:499: error: initializer element is not constant /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:499: warning: data definition has no type or storage class /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:500: warning: type defaults to `int' in declaration of `ACPI_MEM_FREE' /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:500: warning: parameter names (without types) in function declaration /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:500: warning: data definition has no type or storage class /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:501: error: parse error before "if" /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:513: warning: type defaults to `int' in declaration of `status' /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:513: error: redefinition of `status' /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:494: error: `status' previously defined here /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:513: warning: implicit declaration of function `acpi_get_parent' /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:513: error: `parent' undeclared here (not in a function) /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:513: error: initializer element is not constant /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:513: warning: data definition has no type or storage class /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:514: warning: type defaults to `int' in declaration of `handle' /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:514: error: redefinition of `handle' /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:491: error: `handle' previously defined here /usr/src/ctest/mm/kernel/drivers/char/a
Re: 2.6.12-rc2-mm3
Andrew Morton wrote: bk-cifs.patch This breaks the build on mips, ppc64, sparc, sparc64 with the following error (defconfig, compared to mm2): CC [M] fs/cifs/misc.o fs/cifs/misc.c: In function `cifs_convertUCSpath': fs/cifs/misc.c:546: error: case label does not reduce to an integer constant fs/cifs/misc.c:549: error: case label does not reduce to an integer constant fs/cifs/misc.c:552: error: case label does not reduce to an integer constant fs/cifs/misc.c:561: error: case label does not reduce to an integer constant fs/cifs/misc.c:564: error: case label does not reduce to an integer constant fs/cifs/misc.c:567: error: case label does not reduce to an integer constant make[2]: *** [fs/cifs/misc.o] Error 1 make[1]: *** [fs/cifs] Error 2 make: *** [fs] Error 2 See http://l4x.org/k for details. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
defconfig for v850, please
Miles, while you're at it patching v850 here and there, could you please also provide a resonable defconfig for v850, so that $ make ARCH=v850 CROSS_COMPILE=... defconfig $ make ARCH=v850 CROSS_COMPILE=... works? Then my cross-compile tests at http://l4x.org/k could probably provide somewhat meanigful results for this arch?! Thanks, -- Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: defconfig for v850, please
Miles Bader wrote: > 2005/7/20, Jan Dittmer <[EMAIL PROTECTED]>: > >>while you're at it patching v850 here and there, could you please >>also provide a resonable defconfig for v850, so that > > > I must admit it's because I've never quite understood how the > defconfig stuff works... I'll look into it I guess... I think you just need to provide a file called 'defconfig' in arch/v850/ Thanks, -- Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: defconfig for v850, please
Miles Bader wrote:
> 2005/7/20, Jan Dittmer <[EMAIL PROTECTED]>:
>
>>>I must admit it's because I've never quite understood how the
>>>defconfig stuff works... I'll look into it I guess...
>>
>>I think you just need to provide a file called 'defconfig' in
>>arch/v850/
>
>
> Hmmm...
>
> Some archs seem to provide defconfigs for various different platforms,
> which seems nice, and there seems to be some sort of framework for
> doing this, but ...
dropping them in arch/v850/configs/{yourwildplatform}_defconfig
seems to be the way most archs do this (ia64, arm).
They also provide a common defconfig file in arch/v850/ .
HTH,
--
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: defconfig for v850, please
Paul Mundt wrote: > On Wed, Jul 20, 2005 at 07:02:53PM +0900, Miles Bader wrote: > >>Some archs seem to provide defconfigs for various different platforms, >>which seems nice, and there seems to be some sort of framework for >>doing this, but ... >> > > For most of the architectures aimed at embedded systems, having an > arch/foo/defconfig makes no sense. The basic "framework" is to have Still, for basic compile testing and testing patches on other architectures it would be nice, when the patch writer can test his/her patch with a simple defconfig, without knowing a common platform for this target arch. So please include a defconfig with a reasonable common set of CONFIG_* options. It's about testing the core of the architecure not about random driver failures. > arch/foo/configs and place all of your board-specific defconfigs in there > (as boardname_defconfig -- the reason for this is that you get free make > targets of the same name which copy the defconfig over, see 'make help'). > > If you have a particular board that you can assume will be kept > reasonably up-to-date, you can set KBUILD_DEFCONFIG in your Makefile to > set the default config to use by name, and then you can forego having an > arch/foo/defconfig entirely (you can look at sh and some of the other > architectures to see this being done). arm is another one which uses this style, ia64 for example uses configs/* and defconfig. But on arm and sh `make defconfig` works contrary to v850. Thanks, -- Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Automating Kernel Builds
rbt wrote: > I have a script that automatically builds kernels for testing. Would it > be possible to put the kernel version number (2.6.12.3) into the > 'LATEST-IS-VERSION' file on http://www.kernel.org/pub/linux/kernel/v2.6/ > or, is there some other file that traditionally has stored this info? I > searched the repository but could not find one. > > As of now, my script goes to the site and parses the page searching for > a line that contains 'LATEST-IS' and then breaks that line apart and > attempts to extract the kernel version number from it. If > LATEST-IS-VERSION actually contained the version number (2.6.12.3) > instead of being a 0 byte file as it is now, then it my script could > simply read it and not have to do funky html parsing to get the latest > version number ;) Some things from the top of my mind: a) /\d+\.\d+\.\d+(\.\d+)?/ b) use ftp:// c) http://kernel.org/kdist/rss.xml d) http://www.kernel.org/kdist/finger_banner ps: you know http://l4x.org/k/ and kerncomp.sf.net? -- Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: UML build broken on 2.6.13-rc5-mm1
Miklos Szeredi wrote: > UML is broken again in -mm. > > Maybe UML should be added to one of the automatic build suites. It is, see here: http://l4x.org/k/?d=6080 . But the maintainer (if he cares) will know that it's broken and send a fix in time. -mm is imho designed to be broken from time to time. -- Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.12-rc3
> [EMAIL PROTECTED]: > [PATCH] zfcp: convert to compat_ioctl This does not seem to compile anymore with defconfig: CC drivers/s390/scsi/zfcp_aux.o /usr/src/ctest/rc/kernel/drivers/s390/scsi/zfcp_aux.c:63: warning: initialization from incompatible pointer type /usr/src/ctest/rc/kernel/drivers/s390/scsi/zfcp_aux.c:366: error: conflicting types for `zfcp_cfdc_dev_ioctl' /usr/src/ctest/rc/kernel/drivers/s390/scsi/zfcp_aux.c:55: error: previous declaration of `zfcp_cfdc_dev_ioctl' make[3]: *** [drivers/s390/scsi/zfcp_aux.o] Error 1 make[2]: *** [drivers/s390/scsi] Error 2 make[1]: *** [drivers/s390] Error 2 make: *** [_all] Error 2 Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.12-rc3
Linus Torvalds wrote:
> Geert Uytterhoeven:
> [PATCH] M68k: Update defconfigs for 2.6.11
> [PATCH] M68k: Update defconfigs for 2.6.12-rc2
Why do I still get this error when trying to cross-compile for m68k?
toolchain:
Reading specs from
/usr/local/m68k-uclinux-tools/lib/gcc/m68k-uclinux/3.4.0/specs
Configured with: /usr/local/src/uclinux-tools/gcc-3.4.0/configure
--target=m68k-uclinux --prefix=/usr/local/m68k-uclinux-tools
--enable-languages=c,c++ --enable-multilib --enable-target-optspace
--with-gnu-ld --disable-nls --disable-__cxa_atexit --disable-c99
--disable-clocale
--disable-c-mbchar --disable-long-long --enable-threads=posix
--enable-cxx-flags=-D_ISOC99_SOURCE -D_BSD_SOURCE
Thread model: posix
gcc version 3.4.0
GNU ld version 2.14.90.0.8 20040114
(I tried an alternative toolchain with gcc 3.3.3 as well)
$ make mrproper
$ make ARCH=m68k CROSS_COMPILE=m68k-elf- mrproper
$ make ARCH=m68k CROSS_COMPILE=m68k-elf- defconfig
$ make ARCH=m68k CROSS_COMPILE=m68k-elf-
CHK include/linux/version.h
UPD include/linux/version.h
SYMLINK include/asm -> include/asm-m68k
SPLIT include/linux/autoconf.h -> include/config/*
HOSTCC scripts/kallsyms
HOSTCC scripts/conmakehash
CC arch/m68k/kernel/asm-offsets.s
In file included from include/linux/spinlock.h:12,
from include/linux/capability.h:45,
from include/linux/sched.h:7,
from arch/m68k/kernel/asm-offsets.c:12:
include/linux/thread_info.h:30: error: parse error before '{' token
include/linux/thread_info.h:35: error: parse error before '{' token
include/linux/thread_info.h: In function `test_and_set_thread_flag':
include/linux/thread_info.h:42: error: `current' undeclared (first use in this
function)
include/linux/thread_info.h:42: error: (Each undeclared identifier is reported
only once
include/linux/thread_info.h:42: error: for each function it appears in.)
include/linux/thread_info.h: In function `test_and_clear_thread_flag':
include/linux/thread_info.h:47: error: `current' undeclared (first use in this
function)
include/linux/thread_info.h: At top level:
include/linux/thread_info.h:50: error: parse error before '{' token
include/linux/thread_info.h:50: warning: type defaults to `int' in declaration
of `___res'
include/linux/thread_info.h:50: warning: data definition has no type or storage
class
include/linux/thread_info.h:50: error: parse error before '}' token
include/linux/thread_info.h: In function `set_ti_thread_flag':
include/linux/thread_info.h:57: error: structure has no member named `flags'
include/linux/thread_info.h:57: error: structure has no member named `flags'
include/linux/thread_info.h: In function `clear_ti_thread_flag':
include/linux/thread_info.h:62: error: structure has no member named `flags'
include/linux/thread_info.h:62: error: structure has no member named `flags'
include/linux/thread_info.h: In function `test_and_set_ti_thread_flag':
include/linux/thread_info.h:67: error: structure has no member named `flags'
include/linux/thread_info.h:67: error: structure has no member named `flags'
include/linux/thread_info.h: In function `test_and_clear_ti_thread_flag':
include/linux/thread_info.h:72: error: structure has no member named `flags'
include/linux/thread_info.h:72: error: structure has no member named `flags'
include/linux/thread_info.h: In function `test_ti_thread_flag':
include/linux/thread_info.h:77: error: structure has no member named `flags'
In file included from include/linux/spinlock.h:12,
from include/linux/capability.h:45,
from include/linux/sched.h:7,
from arch/m68k/kernel/asm-offsets.c:12:
include/linux/thread_info.h:80:41: macro "set_need_resched" passed 1 arguments,
but takes just 0
include/linux/thread_info.h: At top level:
include/linux/thread_info.h:81: error: syntax error before '{' token
include/linux/thread_info.h:85:43: macro "clear_need_resched" passed 1
arguments, but takes just 0
include/linux/thread_info.h:86: error: syntax error before '{' token
In file included from arch/m68k/kernel/asm-offsets.c:12:
include/linux/sched.h:1108: error: parse error before '{' token
include/linux/sched.h:1113: error: parse error before '{' token
include/linux/sched.h:1118: error: parse error before '{' token
include/linux/sched.h:1118: warning: type defaults to `int' in declaration of
`___res'
include/linux/sched.h:1118: warning: data definition has no type or storage
class
include/linux/sched.h:1118: error: parse error before '}' token
include/linux/sched.h:1118: warning: type defaults to `int' in declaration of
`__res'
include/linux/sched.h:1118: warning: data definition has no type or storage
class
include/linux/sched.h:1118: error: parse error before '}' token
include/linux/sched.h:1128: error: parse error before '{' token
include/linux/sched.h:1128: warning: type defaults to `int' in declaration of
`___res'
include/linux/sched.h:1128: warning: data definition has no type
Re: Git-commits mailing list feed.
David Woodhouse wrote: > As of some time in the fairly near future, the [EMAIL PROTECTED] mailing > list will be carrying real commits from Linus' live git repository, instead > of just testing patches. Have fun. > What about the daily snapshots? Is there any eta when they'll be back? -- Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Git-commits mailing list feed.
Greg KH wrote: > On Thu, Apr 21, 2005 at 08:24:36AM +0200, Jan Dittmer wrote: > >>David Woodhouse wrote: >> >>>As of some time in the fairly near future, the [EMAIL PROTECTED] mailing >>>list will be carrying real commits from Linus' live git repository, instead >>>of just testing patches. Have fun. >>> >> >>What about the daily snapshots? Is there any eta when they'll be back? > > > The script that generated this was posted previously on lkml. If anyone > wants to hack that up to generate the snapshots, it would be greatly > appreciated. Care to point out the post? I can't seem to find it. Only thing is Jeff Garzik announcing that the snapshots work again in 8/04, but no script attached. Thanks, Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc2
Linus Torvalds wrote: > Ok, > -rc3 is pretty small, with the bulk of the diff being some defconfig ... > Linus Torvalds: > Linux v2.6.13-rc3 Confused?! -- Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.13-rc2
Linus Torvalds wrote: > > On Wed, 6 Jul 2005, Jan Dittmer wrote: > >>Linus Torvalds wrote: >> >>>Ok, >>> -rc3 is pretty small, with the bulk of the diff being some defconfig >> >>... >> >>>Linus Torvalds: >>> Linux v2.6.13-rc3 >> >>Confused?! > > > Constantly. > > Let's hope that commit naming bug was the worst part of the release.. Nah, compared to git7 you (or greg?) managed to break alpha, sparc and x86_64. Jan Comparing 2.6.13-rc1-git7 to 2.6.13-rc2 (defconfig) === - alpha: broke /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:156: error: dereferencing pointer to incomplete type /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:156: error: dereferencing pointer to incomplete type /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:156: warning: type defaults to `int' in declaration of `type name' /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:156: error: request for member `node' in something not a structure or union /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:156: warning: type defaults to `int' in declaration of `type name' /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:157: error: dereferencing pointer to incomplete type /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:159: error: dereferencing pointer to incomplete type make[3]: *** [drivers/pci/pci-driver.o] Error 1 make[2]: *** [drivers/pci] Error 2 make[1]: *** [drivers] Error 2 make: *** [_all] Error 2 Details: http://l4x.org/k/?d=5184 - sparc: broke /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:156: error: dereferencing pointer to incomplete type /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:156: error: dereferencing pointer to incomplete type /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:156: warning: type defaults to `int' in declaration of `type name' /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:156: error: request for member `node' in something not a structure or union /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:156: warning: type defaults to `int' in declaration of `type name' /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:157: error: dereferencing pointer to incomplete type /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:159: error: dereferencing pointer to incomplete type make[3]: *** [drivers/pci/pci-driver.o] Error 1 make[2]: *** [drivers/pci] Error 2 make[1]: *** [drivers] Error 2 make: *** [_all] Error 2 Details: http://l4x.org/k/?d=5204 - x86_64: broke /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:156: error: dereferencing pointer to incomplete type /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:156: error: dereferencing pointer to incomplete type /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:156: warning: type defaults to `int' in declaration of `type name' /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:156: error: request for member `node' in something not a structure or union /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:156: warning: type defaults to `int' in declaration of `type name' /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:157: error: dereferencing pointer to incomplete type /usr/src/ctest/rc/kernel/drivers/pci/pci-driver.c:159: error: dereferencing pointer to incomplete type make[3]: *** [drivers/pci/pci-driver.o] Error 1 make[2]: *** [drivers/pci] Error 2 make[1]: *** [drivers] Error 2 make: *** [_all] Error 2 Details: http://l4x.org/k/?d=5208 - arm26: still broken Details: http://l4x.org/k/?d=5186 - cris: still broken Details: http://l4x.org/k/?d=5187 - frv: still broken Details: http://l4x.org/k/?d=5188 - m68k: still broken Details: http://l4x.org/k/?d=5193 - m68knommu: still broken Details: http://l4x.org/k/?d=5195 - parisc: still broken Details: http://l4x.org/k/?d=5197 - s390: still broken Details: http://l4x.org/k/?d=5201 - sh: still broken Details: http://l4x.org/k/?d=5202 - sh64: still broken Details: http://l4x.org/k/?d=5203 - sparc64: still broken Details: http://l4x.org/k/?d=5205 - v850: still broken Details: http://l4x.org/k/?d=5207 - xtensa: still broken Details: http://l4x.org/k/?d=5209 Summary: 9 ok, 14 failed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch xtensa does not compile
Christian Zankel wrote: > Jan Dittmer wrote: > >>I guess I'm using the wrong binutils version (2.15.94.0.2.2). Which is the >>recommended gcc/binutils pair which is supposed to compile the kernel? > > > Bob Wilson made some changes to binutils last week to address this > problem but he only submitted it to the latest binutils version. > > With the latest gcc+binutils toolchain, the kernel compiles for me. > Note, however, that I just submitted a patch that is not in Linus' tree, > yet. > > gcc version 3.4.5 20050707 (prerelease) > GNU ld version 2.16.91 20050707 Yep, using GNU ld 20050710 and gcc 3.4.4 20050513 I get much further now. CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 arch/xtensa/kernel/built-in.o: In function `__down_interruptible': : dangerous relocation: l32r: literal target out of range: .sched.literal arch/xtensa/kernel/built-in.o: In function `__down_interruptible': : dangerous relocation: l32r: literal target out of range: (.sched.literal+0x4) arch/xtensa/kernel/built-in.o: In function `__down_interruptible': : dangerous relocation: l32r: literal target out of range: (.sched.literal+0x8) arch/xtensa/kernel/built-in.o: In function `__down_interruptible': : dangerous relocation: l32r: literal target out of range: (.sched.literal+0xc) arch/xtensa/kernel/built-in.o: In function `__down_interruptible': : dangerous relocation: l32r: literal target out of range: (.sched.literal+0xc) arch/xtensa/kernel/built-in.o: In function `__down': : dangerous relocation: l32r: literal target out of range: .sched.literal arch/xtensa/kernel/built-in.o: In function `__down': : dangerous relocation: l32r: literal target out of range: (.sched.literal+0x4) arch/xtensa/kernel/built-in.o: In function `__down': : dangerous relocation: l32r: literal target out of range: (.sched.literal+0x8) arch/xtensa/kernel/built-in.o: In function `__down': : dangerous relocation: l32r: literal target out of range: (.sched.literal+0xc) kernel/built-in.o: In function `schedule': ... lots more of these, until ... rwsem.c:(.sched.text+0x290): dangerous relocation: l32r: literal target out of range: (. sched.literal+0x18) rwsem.c:(.sched.text+0x297): dangerous relocation: l32r: literal target out of range: (. sched.literal+0x1c) rwsem.c:(.sched.text+0x29c): dangerous relocation: l32r: literal target out of range: (. sched.literal+0x20) rwsem.c:(.sched.text+0x2bb): dangerous relocation: l32r: literal target out of range: (. sched.literal+0x24) make: *** [.tmp_vmlinux1] Error 1 Is the gcc version still too old? Or do I need some special config option? Reading specs from /usr/cc/xtensa/lib/gcc/xtensa-linux/3.4.4/specs Configured with: ../configure --prefix=/usr/cc --exec-prefix=/usr/cc/xtensa --target=xtensa-linux --disable-shared --disable-werror --disable-nls --disable-threads --disable-werror --disable-libmudflap --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c Thread model: single gcc version 3.4.4 20050513 (prerelease) Thanks, -- Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
v850, which gcc and binutils version?
Miles, my autobuilder picked up the defconfigs in 2.6.13-rc3-mm2 for v850 but my toolchain (binutils I expect) seems to be wrong: AS arch/v850/kernel/intv.o /usr/src/ctest/mm/kernel/arch/v850/kernel/intv.S: Assembler messages: /usr/src/ctest/mm/kernel/arch/v850/kernel/intv.S:36: Error: mov hilo(_start),r1: immediate operand is too large /usr/src/ctest/mm/kernel/arch/v850/kernel/intv.S:43: Error: mov hilo(nmi),sp: immediate operand is too large /usr/src/ctest/mm/kernel/arch/v850/kernel/intv.S:45: Error: mov hilo(nmi),sp: immediate operand is too large /usr/src/ctest/mm/kernel/arch/v850/kernel/intv.S:47: Error: mov hilo(nmi),sp: immediate operand is too large /usr/src/ctest/mm/kernel/arch/v850/kernel/intv.S:50: Error: mov hilo(trap),sp: immediate operand is too large /usr/src/ctest/mm/kernel/arch/v850/kernel/intv.S:52: Error: mov hilo(trap),sp: immediate operand is too large /usr/src/ctest/mm/kernel/arch/v850/kernel/intv.S:55: Error: mov hilo(dbtrap),sp: immediate operand is too large /usr/src/ctest/mm/kernel/arch/v850/kernel/intv.S:85: Error: mov hilo(irq),sp: immediate operand is too large /usr/src/ctest/mm/kernel/arch/v850/kernel/intv.S:85: Error: mov hilo(irq),sp: immediate operand is too large /usr/src/ctest/mm/kernel/arch/v850/kernel/intv.S:85: Error: mov hilo(irq),sp: immediate operand is too large /usr/src/ctest/mm/kernel/arch/v850/kernel/intv.S:85: Error: mov hilo(irq),sp: immediate operand is too large /usr/src/ctest/mm/kernel/arch/v850/kernel/intv.S:85: Error: mov hilo(irq),sp: immediate operand is too large /usr/src/ctest/mm/kernel/arch/v850/kernel/intv.S:85: Error: mov hilo(irq),sp: immediate operand is too large make[2]: *** [arch/v850/kernel/intv.o] Error 1 make[1]: *** [arch/v850/kernel] Error 2 make: *** [_all] Error 2 gcc version 3.4.4 20050513 (prerelease) GNU ld version 2.15.94.0.2.2 20041220 Full log at http://l4x.org/k/?d=5658 Which is the recommended gcc/binutils combination for v850? Thanks, -- Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v850, which gcc and binutils version?
Miles Bader wrote: > Jan Dittmer <[EMAIL PROTECTED]> writes: > >>Which is the recommended gcc/binutils combination for v850? > > > The most crucial thing is that all supported processors are v850e > derivatives (note the "e"), so please configure gcc/binutils for target > "v850e-elf". Thanks, that got me much further, compilation aborts now with CC arch/v850/lib/negdi2.o arch/v850/lib/negdi2.c: In function `__negdi2': arch/v850/lib/negdi2.c:25: warning: control reaches end of non-void function AR arch/v850/lib/lib.a /bin/sh: +@: command not found CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o In file included from include/linux/hardirq.h:7, from include/asm-generic/local.h:6, from include/asm/local.h:4, from include/linux/module.h:21, from init/version.c:10: include/asm/hardirq.h:21:27: warning: "NR_IRQS" is not defined LD init/built-in.o LD vmlinux mm/built-in.o: In function `out_of_memory': /usr/src/ctest/oo/kernel/mm/oom_kill.c:264: undefined reference to `show_mem' /usr/src/ctest/oo/kernel/mm/oom_kill.c:264: relocation truncated to fit: R_V850_22_PCREL against undefined symbol `show_mem' mm/built-in.o: In function `_alloc_pages': /usr/src/ctest/oo/kernel/mm/page_alloc.c:1013: undefined reference to `show_mem' /usr/src/ctest/oo/kernel/mm/page_alloc.c:1013: relocation truncated to fit: R_V850_22_PCREL against undefined symbol `show_mem' fs/built-in.o: In function `smaps_open': /usr/src/ctest/oo/kernel/fs/proc/base.c:600: undefined reference to `proc_pid_smaps_op' make: *** [vmlinux] Error 1 Thanks, -- Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v850, which gcc and binutils version?
Miles Bader wrote: > Jan Dittmer <[EMAIL PROTECTED]> writes: > >>>"v850e-elf". >> >>Thanks, that got me much further, compilation aborts now with > > > Hmmm, what sources are you compiling exactly? -rc3-mm3; but if the error was no toolchain bug I won't try much further. The important thing to me was, that my compile tests now produce somewhat meaningful results for this platform. > I last tested with 2.6.12 + 2.6.12-uc0 (uClinux) patches + the v850 patches > I sent to the LKML recently (from which I presume you got the defconfigs); > the v850 patches should now be merged into Linus's tree, but I dunno about I suppose your patches don't apply cleanly against 2.6.12-uc0 ? Thanks, -- Jan http://l4x.org/k/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: v850, which gcc and binutils version?
Greg Ungerer wrote: >>If you care to try applying the uClinux patches, they should be available >>from (fill in "$ver" with "2.6.12-uc0" and "$maj_ver" with "2.6"): >> >>http://www.uclinux.org/pub/uClinux/uClinux-$maj_ver.x/linux-$ver.patch.gz >> >>Greg, do you have any status on merging the current uClinux patch set? > > > I sent a bunch of the 2.6.12-uc0 changes to Linus earlier this week > (the critical fixes), but according to his GIT log he didn't merge them. > I am going to resend tomorrow. Greg you might consider adding the attached patch to update the defconfig for m68nommu, especially +# +# Console display driver support +# +# CONFIG_VGA_CONSOLE is not set +CONFIG_DUMMY_CONSOLE=y which allows the m68knommu defconfig to be buildable without further invention. Patch is against 2.6.12-uc0 Thanks, -- Jan --- kernel/arch/m68knommu/defconfig.old 2005-03-02 08:38:13.0 +0100 +++ kernel/arch/m68knommu/defconfig 2005-07-28 20:51:51.0 +0200 @@ -1,24 +1,48 @@ # # Automatically generated make config: don't edit +# Linux kernel version: 2.6.12-uc0 +# Thu Jul 28 20:49:44 2005 # +CONFIG_M68KNOMMU=y # CONFIG_MMU is not set # CONFIG_FPU is not set CONFIG_UID16=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set +CONFIG_GENERIC_CALIBRATE_DELAY=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y +CONFIG_CLEAN_COMPILE=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # -# CONFIG_SYSVIPC is not set +CONFIG_LOCALVERSION="" +# CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_SYSCTL is not set -CONFIG_LOG_BUF_SHIFT=14 +# CONFIG_AUDIT is not set +# CONFIG_HOTPLUG is not set +CONFIG_KOBJECT_UEVENT=y +# CONFIG_IKCONFIG is not set +# CONFIG_EMBEDDED is not set +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +CONFIG_CC_ALIGN_FUNCTIONS=0 +CONFIG_CC_ALIGN_LABELS=0 +CONFIG_CC_ALIGN_LOOPS=0 +CONFIG_CC_ALIGN_JUMPS=0 +CONFIG_BASE_SMALL=0 # # Loadable module support @@ -34,9 +58,11 @@ # CONFIG_M68360 is not set # CONFIG_M5206 is not set # CONFIG_M5206e is not set +# CONFIG_M523x is not set # CONFIG_M5249 is not set -# CONFIG_M527x is not set +# CONFIG_M5271 is not set CONFIG_M5272=y +# CONFIG_M5275 is not set # CONFIG_M528x is not set # CONFIG_M5307 is not set # CONFIG_M5407 is not set @@ -54,6 +80,7 @@ # CONFIG_CLOCK_50MHz is not set # CONFIG_CLOCK_54MHz is not set # CONFIG_CLOCK_60MHz is not set +# CONFIG_CLOCK_64MHz is not set CONFIG_CLOCK_66MHz=y # CONFIG_CLOCK_70MHz is not set # CONFIG_CLOCK_100MHz is not set @@ -65,9 +92,14 @@ # Platform # CONFIG_M5272C3=y +# CONFIG_COBRA5272 is not set +# CONFIG_CANCam is not set +# CONFIG_SCALES is not set # CONFIG_NETtel is not set +# CONFIG_CPU16B is not set CONFIG_MOTOROLA=y # CONFIG_LARGE_ALLOCS is not set +CONFIG_4KSTACKS=y # CONFIG_RAMAUTO is not set # CONFIG_RAM4MB is not set # CONFIG_RAM8MB is not set @@ -79,20 +111,28 @@ # CONFIG_RAM32BIT is not set CONFIG_RAMKERNEL=y # CONFIG_ROMKERNEL is not set -# CONFIG_HIMEMKERNEL is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # # CONFIG_PCI is not set -# CONFIG_HOTPLUG is not set + +# +# PCCARD (PCMCIA/CardBus) support +# +# CONFIG_PCCARD is not set + +# +# PCI Hotplug Support +# # # Executable file formats # -CONFIG_KCORE_AOUT=y CONFIG_BINFMT_FLAT=y # CONFIG_BINFMT_ZFLAT is not set +# CONFIG_BINFMT_SHARED_FLAT is not set +# CONFIG_BINFMT_MISC is not set # # Power management options @@ -100,12 +140,23 @@ # CONFIG_PM is not set # +# Device Drivers +# + +# +# Generic Driver Options +# +CONFIG_STANDALONE=y +CONFIG_PREVENT_FIRMWARE_BUILD=y +# CONFIG_FW_LOADER is not set + +# # Memory Technology Devices (MTD) # CONFIG_MTD=y # CONFIG_MTD_DEBUG is not set -CONFIG_MTD_PARTITIONS=y # CONFIG_MTD_CONCAT is not set +CONFIG_MTD_PARTITIONS=y # CONFIG_MTD_REDBOOT_PARTS is not set # CONFIG_MTD_CMDLINE_PARTS is not set @@ -116,35 +167,48 @@ CONFIG_MTD_BLOCK=y # CONFIG_FTL is not set # CONFIG_NFTL is not set +# CONFIG_INFTL is not set # # RAM/ROM/Flash chip drivers # # CONFIG_MTD_CFI is not set # CONFIG_MTD_JEDECPROBE is not set +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +# CONFIG_MTD_CFI_I4 is not set +# CONFIG_MTD_CFI_I8 is not set CONFIG_MTD_RAM=y # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set -# CONFIG_MTD_OBSOLETE_CHIPS is not set # # Mapping drivers for chip access # +# CONFIG_MTD_COMPLEX_MAPPINGS is not set CONFIG_MTD_UCLINUX=y # # Self-contained MTD device drivers # # CONFIG_MTD_SLRAM is not set +# CONFIG_MTD_PHRAM is not set # CONFIG_MTD_MTDRAM is not set # CONFIG_MTD_BLKMTD is not set +# CONFIG_MTD_BLO
Re: empty patch-2.6.13-git? patches on ftp.kernel.org
David Woodhouse wrote: > On Fri, 2005-09-02 at 02:00 -0700, Linus Torvalds wrote: > >>Ahh. Please change that to >> >>rm -rf tmp-empty-tree >>mkdir tmp-empty-tree >>cd tmp-empty-tree >>git-init-db >> >>because otherwise you'll almost certainly hit something else later >>on.. > > > OK, done. > -git4 is again empty patch-2.6.13-git4.bz2 03-Sep-2005 02:03 14 [ ] patch-2.6.13-git4.bz2.sign 03-Sep-2005 02:03 248 [ ] patch-2.6.13-git4.gz 03-Sep-2005 02:03 20 [ ] patch-2.6.13-git4.gz.sign 03-Sep-2005 02:03 248 [ ] patch-2.6.13-git4.id 03-Sep-2005 02:01 41 [ ] patch-2.6.13-git4.log 03-Sep-2005 02:03 526K [ ] patch-2.6.13-git4.sign 03-Sep-2005 02:03 248 -- Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11
Linus Torvalds wrote: > Ok, > there it is. Only small stuff lately - as promised. Shortlog from -rc5 > appended, nothing exciting there, mostly some fixes from various code > checkers (like fixed init sections, and some coverity tool finds). > > So it's now _officially_ all bug-free. At least it builds 14 out of 23 arch defconfigs (http://l4x.org/k/), which is quite an improvement over 10/22 of 2.6.10. Congrats, Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Andrew James Wade wrote: > I've just done a bit of looking for scripts to automate the process of > installing a new kernel, and I haven't come up with much of much. So > right now I'm writing my own. If there are tools to help automate this > they need to be more prominent on www.kernel.org and > www.kernelnewbies.org, to make casual testing even easier. Try ketchup from here: http://www.selenic.com/ketchup/ `ketchup 2.6-mm` for example will download and patch the newest 2.6-mm kernel (also try ketchup 2.6-pre, ketchup 2.6-bk, ...). Jan -- http://l4x.org/k/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFD: Kernel release numbering
Russell King wrote: > On Fri, Mar 04, 2005 at 05:33:33PM -, Richard Purdie wrote: > >>I'm in two minds though as generating >>your own from openembedded isn't difficult. Writing instructions for setting >>up oe to build it may be the best option. > > > Two things - are you sure that openembedded contains the patches to > fix the two biggest binutils issues we have, as documented on > http://www.arm.linux.org.uk/developer/toolchain/ ? > > Secondly, are you seriously suggesting people like Jan Dittmer, who > provide a cross-architecture service should jump through some loops > just to get a working toolchain for the ARM architecture? As long it is documented and it _works_ that's no problem. But it was quite a hassle to get working cross-compilers for all 23 archs to build, because for some there is no real documentation which target is the correct one and upstream gcc and/or binutils sometimes don't compile. For example where can I find information about the arm26 arch? I suppose it can be build with a normal arm toolchain (and the breakage looks like a real compiler failure), but is this documented somewhere? It would be nice to have such documentation in kernel under Documentation/$arch/HOW-TO-BUILD for every arch. How much work is it to set-up an openembedded environment anyways? Jan -- http://l4x.org/k/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc1-mm4
Andrew Morton wrote: > bk-audit.patch This seems to have broken compile for uml: CC arch/um/kernel/ptrace.o arch/um/kernel/ptrace.c:345:74: macro "audit_syscall_entry" requires 7 arguments, but only 6 given arch/um/kernel/ptrace.c: In function `syscall_trace': arch/um/kernel/ptrace.c:340: error: `audit_syscall_entry' undeclared (first use in this function) arch/um/kernel/ptrace.c:340: error: (Each undeclared identifier is reported only once arch/um/kernel/ptrace.c:340: error: for each function it appears in.) arch/um/kernel/ptrace.c:348:72: macro "audit_syscall_exit" requires 3 arguments, but only 2 given arch/um/kernel/ptrace.c:347: error: `audit_syscall_exit' undeclared (first use in this function) make[1]: *** [arch/um/kernel/ptrace.o] Error 1 make: *** [arch/um/kernel] Error 2 Fri, 01 Apr 2005 09:08:16 +0200 in particular I suspect: # include/linux/audit.h # 2005/03/25 13:53:15+00:00 [EMAIL PROTECTED] +44 -4 # Add AUDIT_ARCH and its definitions # Add arch to audit_syscall_entry() # Add success/failure to audit_syscall_exit() # # arch/x86_64/kernel/ptrace.c # 2005/03/25 13:53:15+00:00 [EMAIL PROTECTED] +8 -5 # Reorder audit w.r.t ptrace, provide arch and success. # # arch/s390/kernel/ptrace.c # 2005/03/25 13:53:15+00:00 [EMAIL PROTECTED] +11 -10 # Reorder audit w.r.t ptrace, provide arch and success. # # arch/ppc64/kernel/ptrace.c # 2005/03/25 13:53:15+00:00 [EMAIL PROTECTED] +10 -6 # Reorder audit w.r.t ptrace, provide arch and success. # # arch/mips/kernel/ptrace.c # 2005/03/25 13:53:15+00:00 [EMAIL PROTECTED] +28 -10 # Reorder audit w.r.t ptrace, provide arch and success. # # arch/ia64/kernel/ptrace.c # 2005/03/25 13:53:14+00:00 [EMAIL PROTECTED] +13 -8 # Reorder audit w.r.t ptrace, provide arch and success. # # arch/i386/kernel/ptrace.c # 2005/03/25 13:53:14+00:00 [EMAIL PROTECTED] +9 -10 # Reorder audit w.r.t ptrace, provide arch and success. defconfig, gcc 3.3.5, see http://l4x.org/k/?d=3004 for details. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cris build fixes
Hi, I saw that you merged a lot of cris bug fixes into 2.6.24-rc3. Is the cris arch supposed to build again now? If yes which binutils and gcc version is needed? I'm getting the following error [1]: None -> 2.6.24-rc3-git1 Unpacking linux-2.6.23.tar.bz2 Applying patch-2.6.24-rc3.bz2 Applying patch-2.6.24-rc3-git1.bz2 rm -f timage vmlinux.bin decompress.bin rescue.bin cramfs.img rm -rf .tmp ## make HOSTCC=gcc-4.0 ARCH=cris CROSS_COMPILE=cris-linux- CROSS32_COMPILE= O=/tmp/tmp.XaDaD27156/out/cris defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/basic/docproc GEN /tmp/tmp.XaDaD27156/out/cris/Makefile HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/kxgettext.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/lex.zconf.c SHIPPED scripts/kconfig/zconf.hash.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf -d arch/cris/Kconfig arch/cris/Kconfig:161: can't open file "arch/cris/arch/drivers/Kconfig" make[2]: *** [defconfig] Error 1 make[1]: *** [defconfig] Error 2 make: *** [sub-make] Error 2 ## make HOSTCC=gcc-4.0 ARCH=cris CROSS_COMPILE=cris-linux- CROSS32_COMPILE= O=/tmp/tmp.XaDaD27156/out/cris GEN /tmp/tmp.XaDaD27156/out/cris/Makefile scripts/kconfig/conf -s arch/cris/Kconfig arch/cris/Kconfig:161: can't open file "arch/cris/arch/drivers/Kconfig" make[3]: *** [silentoldconfig] Error 1 make[2]: *** [silentoldconfig] Error 2 Making include/asm-cris/arch -> include/asm-cris/arch-v10 symlink make[1]: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop. make: *** [sub-make] Error 2 Thanks, Jan [1] http://l4x.org/k/?36622 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Working frv toolchain?
With gcc 4.0.0 and binutils 2.15.94 I get: CC arch/frv/mm/dma-alloc.o arch/frv/mm/dma-alloc.c: In function 'consistent_alloc': arch/frv/mm/dma-alloc.c:66: error: impossible constraint in 'asm' make[2]: *** [arch/frv/mm/dma-alloc.o] Error 1 make[1]: *** [arch/frv/mm] Error 2 make: *** [sub-make] Error 2 http://l4x.org/k/?d=35919 for details What is a known working toolchain for fr-v? Is there a mailing list for frv related problems? Thanks, Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Working frv toolchain?
David Howells wrote: Jan Dittmer <[EMAIL PROTECTED]> wrote: With gcc 4.0.0 and binutils 2.15.94 I get: I'm using gcc 4.1.2. 4.1.2 together with 2.17.50 gives me with a i386 cross compiler: CC arch/frv/mm/dma-alloc.o /usr/src/xtest/linux-2.6/arch/frv/mm/dma-alloc.c: In function 'consistent_alloc': /usr/src/xtest/linux-2.6/arch/frv/mm/dma-alloc.c:66: error: impossible constraint in 'asm' make[2]: *** [arch/frv/mm/dma-alloc.o] Error 1 make[1]: *** [arch/frv/mm] Error 2 make: *** [sub-make] Error 2 Known bug or toolchain problem? Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Working frv toolchain?
David Howells wrote: David Howells <[EMAIL PROTECTED]> wrote: Ah... I'd forgotten about that. I'm not sure all the ASM constraint changes are upstream yet, and gcc bz 28583 also gets incurred. Are you particularly interested in building your own compiler, or would one of ours do? Look in: ftp://ftp.redhat.com/pub/redhat/gnupro/FRV Hmm, I'm needing it for my pet project kernel compile tests at http://l4x.org/k/. It would be nice to be as close as possible to the upstream gcc. So patches against gcc upstream would be welcome... If you say that ain't happening, I'll just use the precompiled stuff. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Trivial sh64 updates for 2.6.23-rc1
Paul Mundt wrote: Paul Mundt (5): sh64: Wire up fallocate() syscall. sh64: Update cayman defconfig. sh64: Fix up PCI section mismatch warnings. sh64: Move entry point code to .text.head. sh64: Flag sh64_get_page() as __init_refok. Tangential question. Which is the currently recommended cross toolchain for sh64? With "gcc 3.2 20020529", "binutils 020306 20030206" (some binary toolchain from ~2 years ago somewhere off the web) I get [1] CC fs/seq_file.o CC fs/xattr.o fs/xattr.c: In function `vfs_listxattr': fs/xattr.c:161: unrecognizable insn: (insn 162 159 114 (set (subreg:DI (reg:SI 181) 0) (reg:DI 182)) -1 (nil) (nil)) fs/xattr.c:161: Internal compiler error in get_attr_highpart, at insn-attrtab.c:6211 Please submit a full bug report, with preprocessed source if appropriate. See http://www.gnu.org/software/gcc/bugs.html> for instructions. make[2]: *** [fs/xattr.o] Error 1 make[1]: *** [fs] Error 2 make: *** [_all] Error 2 gcc 3.4.x, 4.0.x, 4.1.x don't build for me from source (target -superh-linux-gnu, binutils 2.15.x or 2.17.x). Thanks, Jan [1] http://l4x.org/k/?d=32100 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Trivial sh64 updates for 2.6.23-rc1
Paul Mundt wrote: > On Fri, Jul 20, 2007 at 04:07:21PM +0200, Jan Dittmer wrote: >> Paul Mundt wrote: >> Tangential question. Which is the currently recommended cross toolchain >> for sh64? With "gcc 3.2 20020529", "binutils 020306 20030206" (some >> binary toolchain from ~2 years ago somewhere off the web) I get [1] >> gcc 3.4.x, 4.0.x, 4.1.x don't build for me from source >> (target -superh-linux-gnu, binutils 2.15.x or 2.17.x). > > I've been using sh64-linux targetted toolchains created from the gentoo > crossdev, which works fine with stock versions. I can send you a tarball > of the toolchain off-list if you like. Binutils, gcc versions would be fine to. Meanwhile I got binutils 2.17.50.0.17.20070615 and gcc 4.1.3 20070704 (prerelease) to compile (supplying it with uclibc- and lk-headers). But compiling 2.6.22-git17 now fails with CC drivers/video/cfbimgblt.o CC drivers/video/fb_defio.o LD drivers/video/built-in.o LD drivers/built-in.o sh64-linux-ld: sh3 architecture of input file `drivers/media/built-in.o' is incompatible with sh5 output sh64-linux-ld: sh3 architecture of input file `drivers/i2c/built-in.o' is incompatible with sh5 output make[2]: *** [drivers/built-in.o] Error 1 make[1]: *** [drivers] Error 2 make: *** [_all] Error 2 Known? Thanks, Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Trivial sh64 updates for 2.6.23-rc1
Paul Mundt wrote: > On Sun, Jul 22, 2007 at 01:18:27PM +0200, Jan Dittmer wrote: >> Paul Mundt wrote: >>> On Fri, Jul 20, 2007 at 04:07:21PM +0200, Jan Dittmer wrote: >>>> Paul Mundt wrote: >>>> Tangential question. Which is the currently recommended cross toolchain >>>> for sh64? With "gcc 3.2 20020529", "binutils 020306 20030206" (some >>>> binary toolchain from ~2 years ago somewhere off the web) I get [1] >> >> >>>> gcc 3.4.x, 4.0.x, 4.1.x don't build for me from source >>>> (target -superh-linux-gnu, binutils 2.15.x or 2.17.x). >>> I've been using sh64-linux targetted toolchains created from the gentoo >>> crossdev, which works fine with stock versions. I can send you a tarball >>> of the toolchain off-list if you like. >> Binutils, gcc versions would be fine to. Meanwhile I got binutils >> 2.17.50.0.17.20070615 and gcc 4.1.3 20070704 (prerelease) to compile >> (supplying it with uclibc- and lk-headers). But compiling 2.6.22-git17 >> now fails with >> >> CC drivers/video/cfbimgblt.o >> CC drivers/video/fb_defio.o >> LD drivers/video/built-in.o >> LD drivers/built-in.o >> sh64-linux-ld: sh3 architecture of input file `drivers/media/built-in.o' >> is incompatible with sh5 output >> sh64-linux-ld: sh3 architecture of input file `drivers/i2c/built-in.o' >> is incompatible with sh5 output >> make[2]: *** [drivers/built-in.o] Error 1 >> make[1]: *** [drivers] Error 2 >> make: *** [_all] Error 2 >> >> Known? >> > It's known that empty objects require explicit tuning for the ABI, > however, this has never been anything that was fatal. If you flip > something on within each of those subsystems, does the error go away? Yes, thanks this fixes it. Would you accept a patch to modify the defconfig so that it builds by default? Would be most useful for my pet project (http://l4x.org/k/). A fixed toolchain would of course also be nice. Thanks, Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Trivial sh64 updates for 2.6.23-rc1
Paul Mundt wrote: On Sun, Jul 22, 2007 at 06:39:08PM +0200, Jan Dittmer wrote: Paul Mundt wrote: It's known that empty objects require explicit tuning for the ABI, however, this has never been anything that was fatal. If you flip something on within each of those subsystems, does the error go away? Yes, thanks this fixes it. Would you accept a patch to modify the defconfig so that it builds by default? Would be most useful for my pet project (http://l4x.org/k/). A fixed toolchain would of course also be nice. I'll certainly apply patches that help getting it building, so feel free to send updates for that. As I also noted, the empty object thing is non-fatal with my toolchain, so I'd also appreciate it if you could put a tarball of yours up somewhere so this is a bit easier to verify. I suspect this is just something we're going to have to change in binutils, however. You can find it here: http://l4x.org/~jdittmer/sh64-linux-binutils-2.17-gcc-4.1.3pre.tar.bz2 binutils 2.17.50.0.17 (from ftp.kernel.org) gcc 4.1.3 prerelease (svn, fixes a build bug for sh64) Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
alpha, i386,mips,powerpc,ppc,xtensa compile brakage (was Re: Linus 2.6.23-rc1)
Linus Torvalds wrote: Ok, right on time, two weeks afetr 2.6.22, there's a 2.6.23-rc1 out there. Compared to 2.6.22> # alpha/defconfig: broke LD .tmp_vmlinux1 arch/alpha/kernel/built-in.o(.text+0xcdf8): In function `module_frob_arch_sections': include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0xcdfc):include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0x190d8): In function `srmcons_get_private_struct': include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0x190dc):include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.init.text+0x948): In function `register_cpus': include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.init.text+0x94c):include/linux/slub_def.h:154: more undefined references to `__kmalloc_size_too_large' follow make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [_all] Error 2 # i386/allmodconfig: broke CC [M] drivers/misc/asus-laptop.o drivers/misc/asus-laptop.c: In function `asus_led_exit': drivers/misc/asus-laptop.c:1076: error: structure has no member named `class_dev' drivers/misc/asus-laptop.c:1076: error: structure has no member named `class_dev' drivers/misc/asus-laptop.c:1077: error: structure has no member named `class_dev' drivers/misc/asus-laptop.c:1077: error: structure has no member named `class_dev' drivers/misc/asus-laptop.c:1078: error: structure has no member named `class_dev' drivers/misc/asus-laptop.c:1078: error: structure has no member named `class_dev' drivers/misc/asus-laptop.c:1079: error: structure has no member named `class_dev' drivers/misc/asus-laptop.c:1079: error: structure has no member named `class_dev' drivers/misc/asus-laptop.c:1080: error: structure has no member named `class_dev' drivers/misc/asus-laptop.c:1080: error: structure has no member named `class_dev' make[3]: *** [drivers/misc/asus-laptop.o] Error 1 make[2]: *** [drivers/misc] Error 2 make[1]: *** [drivers] Error 2 make: *** [_all] Error 2 # mips/defconfig: broke GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o(.text+0x1ce30): In function `store_uevent': drivers/base/core.c: undefined reference to `kobject_actions' drivers/built-in.o(.text+0x1ce34):drivers/base/core.c: undefined reference to `kobject_actions' make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [_all] Error 2 # powerpc/iseries_defconfig: broke CC [M] drivers/scsi/scsi_transport_sas.o CC [M] drivers/scsi/scsi_wait_scan.o LD drivers/scsi/ibmvscsi/built-in.o CC [M] drivers/scsi/ibmvscsi/ibmvscsi.o drivers/scsi/ibmvscsi/ibmvscsi.c: In function 'ibmvscsi_reset_host': drivers/scsi/ibmvscsi/ibmvscsi.c:517: error: implicit declaration of function 'vio_enable_interrupts' make[4]: *** [drivers/scsi/ibmvscsi/ibmvscsi.o] Error 1 make[3]: *** [drivers/scsi/ibmvscsi] Error 2 make[2]: *** [drivers/scsi] Error 2 make[1]: *** [drivers] Error 2 make: *** [_all] Error 2 # ppc/bamboo_defconfig: broke GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 drivers/built-in.o(.text+0x1ebda): In function `store_uevent': drivers/base/core.c:312: undefined reference to `kobject_actions' drivers/built-in.o(.text+0x1ebe6):drivers/base/core.c:312: undefined reference to `kobject_actions' make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [_all] Error 2 # xtensa/defconfig: broke CC kernel/time/clocksource.o In file included from include/linux/clocksource.h:18, from kernel/time/clocksource.c:27: include2/asm/io.h: In function `virt_to_phys': include2/asm/io.h:46: error: implicit declaration of function `__pa' include2/asm/io.h: In function `phys_to_virt': include2/asm/io.h:51: error: implicit declaration of function `__va' include2/asm/io.h:51: warning: return makes pointer from integer without a cast make[3]: *** [kernel/time/clocksource.o] Error 1 make[2]: *** [kernel/time] Error 2 make[1]: *** [kernel] Error 2 make: *** [_all] Error 2 Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/4] 2.6.23-rc4: known regressions
Michal Piotrowski wrote: > Subject : 2.6.23-rc2 cross compile regressions (alpha,xtensa) > References : http://lkml.org/lkml/2007/8/6/43 > Last known good : alpha: 2.6.22-git8 xtensa: 2.6.22-git6 > Submitter : Jan Dittmer <[EMAIL PROTECTED]> > Caused-By : ? > Handled-By : xtensa: Christian Zankel <[EMAIL PROTECTED]> > Status : unknown Status: Unfixed alpha: http://l4x.org/k/?d=33700 CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 arch/alpha/kernel/built-in.o(.text+0xaaa8): In function `pdev_save_srm_config': include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0xaaac):include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0xd0a8): In function `module_frob_arch_sections': include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0xd0ac):include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0x19388): In function `srmcons_get_private_struct': include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0x1938c):include/linux/slub_def.h:154: more undefined references to `__kmalloc_size_too_large' follow make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [_all] Error 2 xtensa: http://l4x.org/k/?d=33728 CC arch/xtensa/kernel/process.o arch/xtensa/kernel/process.c:50: error: `INR_OPEN' undeclared here (not in a function) arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[7].rlim_cur') arch/xtensa/kernel/process.c:50: error: `INR_OPEN' undeclared here (not in a function) arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[7].rlim_max') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[7]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[8]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[9]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[10]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[11]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[12]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[13]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[14]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.') arch/xtensa/kernel/process.c: In function `xtensa_execve': arch/xtensa/kernel/process.c:449: error: implicit declaration of function `getname' arch/xtensa/kernel/process.c:449: warning: assignment makes pointer from integer without a cast arch/xtensa/kernel/process.c:460: error: implicit declaration of function `putname' make[2]: *** [arch/xtensa/kernel/process.o] Error 1 make[1]: *** [arch/xtensa/kernel] Error 2 make: *** [_all] Error 2 Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/4] 2.6.23-rc4: known regressions
Christoph Lameter wrote: On Thu, 30 Aug 2007, Adrian Bunk wrote: Christoph, is your fix in -mm suitable for 2.6.23, or how else should this regression be fixed for 2.6.23? Looks like this is just alpha and a certain particular compiler version? binutils 2.15.95, gcc 3.3.6 and I could update to 4.0.4 or something more recent I guess. And yes, it's only alpha. Of which file do you want the objdump? Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/4] 2.6.23-rc4: known regressions
Christoph Lameter wrote: > On Thu, 30 Aug 2007, Jan Dittmer wrote: > >> Christoph Lameter wrote: >>> On Thu, 30 Aug 2007, Adrian Bunk wrote: >>> >>>> Christoph, is your fix in -mm suitable for 2.6.23, or how else should this >>>> regression be fixed for 2.6.23? >>> Looks like this is just alpha and a certain particular compiler version? >> binutils 2.15.95, gcc 3.3.6 and I could update to 4.0.4 or something >> more recent I guess. And yes, it's only alpha. >> >> Of which file do you want the objdump? > > The one where the link fails. Dump the code around the unresolved symbol. Here is one of them: 19380: 10 00 1f 20 lda v0,16 19384: e6 ff ff c3 br 19320 * Generate a link failure. Would be great if we could * do something to stop the compile here. */ extern void __kmalloc_size_too_large(void); __kmalloc_size_too_large(); 19388: 00 00 7d a7 ldq t12,0(gp) 1938c: 00 40 5b 6b jsr ra,(t12),19390 19390: 00 00 ba 27 ldahgp,0(ra) 19394: 00 00 bd 23 lda gp,0(gp) 19398: d6 ff ff c3 br 192f4 1939c: 00 00 fe 2f unop Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/4] 2.6.23-rc5: known regressions
Michal Piotrowski wrote: Subject : 2.6.23-rc2 cross compile regressions (alpha,xtensa) References : http://lkml.org/lkml/2007/8/6/43 Last known good : alpha: 2.6.22-git8 xtensa: 2.6.22-git6 Submitter : Jan Dittmer <[EMAIL PROTECTED]> Caused-By : ? Handled-By : xtensa: Christian Zankel <[EMAIL PROTECTED]> Status : unknown Both are fixed as of -rc5 Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc5 regression: uml on x86_64 compile error
Adrian Bunk wrote: Commit d1254b12c93e1e586137a2ffef71fd33cf273f35 causes the following compile error (found at [1]): <-- snip --> ... CC fs/binfmt_elf.o In file included from fs/binfmt_elf.c:30: include/linux/elfcore.h: In function ‘elf_core_copy_regs’: include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ include/linux/elfcore.h:103: error: ‘union uml_pt_regs’ has no member named ‘gp’ make[2]: *** [fs/binfmt_elf.o] Error 1 That may actually be a toolchain/build system problem. It's a i486 chroot in which the compile happens. Host is x86_64 though as reported by uname. And I use gcc 4.0 as HOSTCC, while CC is gcc 4.1.2. # gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) # uname -m x86_64 Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc2 cross compile regressions (alpha,sparc,xtensa)
sparc/defconfig: CC init/main.o In file included from include/linux/proc_fs.h:5, from init/main.c:14: include/linux/fs.h:848: warning: `struct flock' declared inside parameter list include/linux/fs.h:848: warning: its scope is only this definition or declaration, which is probably not what you want include/linux/fs.h:850: warning: `struct flock' declared inside parameter list include/linux/fs.h:853: warning: `struct flock64' declared inside parameter list include/linux/fs.h:855: warning: `struct flock64' declared inside parameter list init/main.c: In function `init_post': init/main.c:782: error: `O_RDWR' undeclared (first use in this function) init/main.c:782: error: (Each undeclared identifier is reported only once init/main.c:782: error: for each function it appears in.) make[2]: *** [init/main.o] Error 1 make[1]: *** [init] Error 2 make: *** [_all] Error 2 xtensa/defconfig: CC arch/xtensa/kernel/process.o arch/xtensa/kernel/process.c:50: error: `INR_OPEN' undeclared here (not in a function) arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[7].rlim_cur') arch/xtensa/kernel/process.c:50: error: `INR_OPEN' undeclared here (not in a function) arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[7].rlim_max') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[7]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[8]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[9]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[10]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[11]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[12]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[13]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim[14]') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.rlim') arch/xtensa/kernel/process.c:50: error: initializer element is not constant arch/xtensa/kernel/process.c:50: error: (near initialization for `init_signals.') arch/xtensa/kernel/process.c: In function `xtensa_execve': arch/xtensa/kernel/process.c:449: error: implicit declaration of function `getname' arch/xtensa/kernel/process.c:449: warning: assignment makes pointer from integer without a cast arch/xtensa/kernel/process.c:460: error: implicit declaration of function `putname' make[2]: *** [arch/xtensa/kernel/process.o] Error 1 make[1]: *** [arch/xtensa/kernel] Error 2 make: *** [_all] Error 2 alpha/defconfig: LD .tmp_vmlinux1 arch/alpha/kernel/built-in.o(.text+0xaaa8): In function `pdev_save_srm_config': include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0xaaac):include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0xd0a8): In function `module_frob_arch_sections': include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0xd0ac):include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0x19388): In function `srmcons_get_private_struct': include/linux/slub_def.h:154: undefined reference to `__kmalloc_size_too_large' arch/alpha/kernel/built-in.o(.text+0x1938c):include/linux/slub_def.h:154: more undefined references to `__kmalloc_size_too_large' follow make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [_all] Error 2 With patch: ia64/defconfig. Not compiling: blackfin,cris,frv,h8300,v850 Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/3] 2.6.23-rc2: known regressions v2
Michal Piotrowski wrote: > Unclassified > > Subject : 2.6.23-rc2 cross compile regressions (alpha,xtensa) > References : http://lkml.org/lkml/2007/8/6/43 > Last known good : ? alpha: 2.6.22-git8 xtensa: 2.6.22-git6 > Submitter : Jan Dittmer <[EMAIL PROTECTED]> > Caused-By : ? > Handled-By : ? xtensa: Christian Zankel, has patches alpha: unhandled, I'd blame the (slub,slab,reclaim,...)-mm changes which went in on 2007-07-17. > Status : unknown Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
Len Brown wrote: Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release This seems to break ia64 defconfig: Building modules, stage 2. MODPOST 157 modules FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo of the size of section __mod_acpi_device_table=144. Fix definition of struct acpi_device_id in mod_devicetable.h make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make: *** [_all] Error 2 gcc 3.3.6, binutils 2.15.94 http://l4x.org/k/?d=32569 Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.23-rc1
Andreas Schwab wrote: > Jan Dittmer <[EMAIL PROTECTED]> writes: > >> Len Brown wrote: >>> Hi Linus, >>> >>> please pull from: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git >>> release >> This seems to break ia64 defconfig: >> >> Building modules, stage 2. >> MODPOST 157 modules >> FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo >> of the size of section __mod_acpi_device_table=144. > > Are you cross-compiling? The definition of kernel_ulong_t won't work on > x86. Yes, sorry, should have mentioned that. Build system is x86. Still, it didn't happen before the recent acpi merge. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: libata crash
Jeff Garzik wrote: Building on x86-64, I'm betting? :) I fell victim to the same thing a few days ago, missing some compile breakage that only appeared with make ARCH=i386 allmodconfig && make ARCH=i386 -sj9 Though am I alone in dreaming of a kernel.org service that would permit all-arch build testing of a git URL? I could add that to the service at http://l4x.org/k/ if there is sufficient (>1) interest. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Working frv toolchain?
David Howells wrote: David Howells <[EMAIL PROTECTED]> wrote: Ah... I'd forgotten about that. I'm not sure all the ASM constraint changes are upstream yet, and gcc bz 28583 also gets incurred. Are you particularly interested in building your own compiler, or would one of ours do? Look in: ftp://ftp.redhat.com/pub/redhat/gnupro/FRV Hrm, that gets me further, but one of the final stages fail: CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 kernel/built-in.o(.text+0x2e684): In function `kallsyms_lookup_name': : relocation truncated to fit: R_FRV_GPREL12 kallsyms_num_syms kernel/built-in.o(.text+0x2e6d4): In function `kallsyms_lookup_name': : relocation truncated to fit: R_FRV_GPREL12 kallsyms_num_syms kernel/built-in.o(.text+0x2e750): In function `get_symbol_pos': : relocation truncated to fit: R_FRV_GPREL12 kallsyms_num_syms kernel/built-in.o(.text+0x2ed00): In function `update_iter': : relocation truncated to fit: R_FRV_GPREL12 kallsyms_num_syms make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [sub-make] Error 2 Todays git tree. Is there any known good release I can test this toolchain against? Thanks, Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Working frv toolchain?
David Howells wrote: Jan Dittmer <[EMAIL PROTECTED]> wrote: Hrm, that gets me further, but one of the final stages fail: What's your configuration? I just do: make HOSTCC=gcc-4.0 ARCH=frv CROSS_COMPILE=frv-linux-gnu- O=... \ defconfig make HOSTCC=gcc-4.0 ARCH=frv CROSS_COMPILE=frv-linux-gnu- O=... As I said it is for the automatic compile testing at l4x.org/k/ Thanks, Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Working frv toolchain?
David Howells wrote: Jan Dittmer <[EMAIL PROTECTED]> wrote: Hrm, that gets me further, but one of the final stages fail: Can you try the attached patch? Thanks, that fixes the error in question. Now I have only a couple of scary looking warnings (see below, sorry for the word-wrap). So it's no toolchain problem then, after all? Are there any chances to get a patch for frv support against some upstream gcc 4.x version? Thanks, Jan LD kernel/built-in.o frv-linux-gnu-ld: Warning: size of symbol `sys_set_robust_list' changed from 8 in kernel/sys_ni.o to 32 in kernel/futex.o frv-linux-gnu-ld: Warning: size of symbol `sys_get_robust_list' changed from 8 in kernel/sys_ni.o to 252 in kernel/futex.o frv-linux-gnu-ld: Warning: size of symbol `sys_futex' changed from 8 in kernel/sys_ni.o to 476 in kernel/futex.o frv-linux-gnu-ld: Warning: size of symbol `sys_chown16' changed from 8 in kernel/sys_ni.o to 56 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_lchown16' changed from 8 in kernel/sys_ni.o to 56 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_fchown16' changed from 8 in kernel/sys_ni.o to 56 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_setregid16' changed from 8 in kernel/sys_ni.o to 56 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_setgid16' changed from 8 in kernel/sys_ni.o to 40 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_setreuid16' changed from 8 in kernel/sys_ni.o to 56 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_setuid16' changed from 8 in kernel/sys_ni.o to 40 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_setresuid16' changed from 8 in kernel/sys_ni.o to 156 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_getresuid16' changed from 8 in kernel/sys_ni.o to 312 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_setresgid16' changed from 8 in kernel/sys_ni.o to 156 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_getresgid16' changed from 8 in kernel/sys_ni.o to 312 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_setfsuid16' changed from 8 in kernel/sys_ni.o to 40 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_setfsgid16' changed from 8 in kernel/sys_ni.o to 40 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_getgroups16' changed from 8 in kernel/sys_ni.o to 368 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_setgroups16' changed from 8 in kernel/sys_ni.o to 452 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_getuid16' changed from 8 in kernel/sys_ni.o to 36 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_geteuid16' changed from 8 in kernel/sys_ni.o to 36 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_getgid16' changed from 8 in kernel/sys_ni.o to 36 in kernel/uid16.o frv-linux-gnu-ld: Warning: size of symbol `sys_getegid16' changed from 8 in kernel/sys_ni.o to 36 in kernel/uid16.o GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 KSYM.tmp_kallsyms1.S AS .tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM.tmp_kallsyms2.S AS .tmp_kallsyms2.o LD vmlinux.o frv-linux-gnu-ld: Warning: size of symbol `sys_munlockall' changed from 8 in kernel/built-in.o to 72 in mm/built-in.o frv-linux-gnu-ld: Warning: size of symbol `sys_swapoff' changed from 8 in kernel/built-in.o to 2568 in mm/built-in.o frv-linux-gnu-ld: Warning: size of symbol `sys_remap_file_pages' changed from 8 in kernel/built-in.o to 1008 in mm/built-in.o frv-linux-gnu-ld: Warning: size of symbol `sys_munlock' changed from 8 in kernel/built-in.o to 116 in mm/built-in.o frv-linux-gnu-ld: Warning: size of symbol `sys_mincore' changed from 8 in kernel/built-in.o to 1056 in mm/built-in.o frv-linux-gnu-ld: Warning: size of symbol `sys_msync' changed from 8 in kernel/built-in.o to 448 in mm/built-in.o frv-linux-gnu-ld: Warning: size of symbol `sys_swapon' changed from 8 in kernel/built-in.o to 2428 in mm/built-in.o frv-linux-gnu-ld: Warning: size of symbol `sys_madvise' changed from 8 in kernel/built-in.o to 1400 in mm/built-in.o frv-linux-gnu-ld: Warning: size of symbol `sys_mlockall' changed from 8 in kernel/built-in.o to 196 in mm/built-in.o frv-linux-gnu-ld: Warning: size of symbol `sys_mprotect' changed from 8 in kernel/built-in.o to 576 in mm/built-in.o frv-linux-gnu-ld: Warning: size of symbol `sys_mlock' changed from 8 in kernel/built-in.o to 200 in mm/built-in.o frv-linux-gnu-ld: Warning: size of symbol `sys_mremap' changed from 8 in kernel/built-in.o to 132 in mm/built-in.o frv-linux-gnu-l
Re: [linux-pm] Suspend to RAM, Sony Vaio PCG-SRX51P, lcd stays off
Pavel Machek wrote: > Hi! > >> I own an older Sony Vaio SRX51P, European Model, P3 based. s2ram >> identifies it with >> >> sys_vendor = "Sony Corporation" >> sys_product = "PCG-SRX51P(DE) " >> sys_version = "01 " >> bios_version = "R0232U2" >> >> Suspend to RAM by using "s2ram -v -m -f" actually works and the >> laptop comes back to life, is accessible by network, etc. kudos >> so far. >> The only but serious problem is, that the lcd stays off after >> resume. No matter what kind of options for s2ram I try, if I disable > > Is the _lcd_ off or the _backlight_ off? Use bright flashlight to > tell. The lcd. If you press the lid button you get the same effect (but you cannot use it to turn the lcd on again :-(( ). But I'll doublecheck with a flashlight nevertheless. >> framebuffer or suspend from X, the lcd always stays off. Only >> a reboot fixes this. Note that the X driver also cannot dis-/enable >> the lcd (xset dpms force off). It always stays lit. I also tried >> with i810switch, but that also does not affect the lcd. >> spicctrl -b42 neither. >> Latest kernel I tested is 2.6.20-git11 from today. >> >> So has anyone of you suspend, acpi, sonypi, fb people an idea how to fix >> this? I suspect one has to call some magic ACPI method upon resume? What >> other kind of information would be needed to debug this? Anything more >> to try? Are there some sony people here listening who can fix this? > > sonypi people actually might know how to help... > >> 00:02.0 VGA compatible controller: Intel Corporation 82815 CGC > [Chipset Graphics Controller] (rev 11) > > Wait a moment, did not Intel release nice, commented, GPLed sources > for their graphics cards somewhere? That might help. URL? But I suspect the lcd on/off is controlled by some embedded controller or such (reachable via acpi, at least I've an EC0 in /proc/acpi/). Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Suspend to RAM, Sony Vaio PCG-SRX51P, lcd stays off
Pavel Machek wrote: > Hi! > I own an older Sony Vaio SRX51P, European Model, P3 based. s2ram identifies it with sys_vendor = "Sony Corporation" sys_product = "PCG-SRX51P(DE) " sys_version = "01 " bios_version = "R0232U2" Suspend to RAM by using "s2ram -v -m -f" actually works and the laptop comes back to life, is accessible by network, etc. kudos so far. The only but serious problem is, that the lcd stays off after resume. No matter what kind of options for s2ram I try, if I disable >>> Is the _lcd_ off or the _backlight_ off? Use bright flashlight to >>> tell. >> The lcd. If you press the lid button you get the same effect (but you >> cannot use it to turn the lcd on again :-(( ). But I'll doublecheck with >> a flashlight nevertheless. > > If lid button breaks the lcd, even in grub boot loader... then I'd > call your machine broken hardware, complain to the manufacturer. (Are > you at latest BIOS?) No, you misunderstood me. If I press the lid button, the lcd goes off and when I release it, it goes on again. But after a suspend cycle even that does not revive the lcd. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Suspend to RAM, Sony Vaio PCG-SRX51P, lcd stays off
Hi there, I own an older Sony Vaio SRX51P, European Model, P3 based. s2ram identifies it with sys_vendor = "Sony Corporation" sys_product = "PCG-SRX51P(DE) " sys_version = "01 " bios_version = "R0232U2" Suspend to RAM by using "s2ram -v -m -f" actually works and the laptop comes back to life, is accessible by network, etc. kudos so far. The only but serious problem is, that the lcd stays off after resume. No matter what kind of options for s2ram I try, if I disable framebuffer or suspend from X, the lcd always stays off. Only a reboot fixes this. Note that the X driver also cannot dis-/enable the lcd (xset dpms force off). It always stays lit. I also tried with i810switch, but that also does not affect the lcd. spicctrl -b42 neither. Latest kernel I tested is 2.6.20-git11 from today. So has anyone of you suspend, acpi, sonypi, fb people an idea how to fix this? I suspect one has to call some magic ACPI method upon resume? What other kind of information would be needed to debug this? Anything more to try? Are there some sony people here listening who can fix this? Thanks very much for any help, Jan $ lspci 00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 11) 00:02.0 VGA compatible controller: Intel Corporation 82815 CGC [Chipset Graphics Controller] (rev 11) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 03) 00:1f.0 ISA bridge: Intel Corporation 82801BAM ISA Bridge (LPC) (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801BAM IDE U100 (rev 03) 00:1f.2 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #1) (rev 03) 00:1f.3 SMBus: Intel Corporation 82801BA/BAM SMBus (rev 03) 00:1f.4 USB Controller: Intel Corporation 82801BA/BAM USB (Hub #2) (rev 03) 00:1f.5 Multimedia audio controller: Intel Corporation 82801BA/BAM AC'97 Audio (rev 03) 00:1f.6 Modem: Intel Corporation 82801BA/BAM AC'97 Modem (rev 03) 01:00.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) 01:02.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80) 01:05.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 01) 01:08.0 Ethernet controller: Intel Corporation 82801BA/BAM/CA/CAM Ethernet Controller (rev 03) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Suspend to RAM, Sony Vaio PCG-SRX51P, lcd stays off
Mattia Dongili wrote: > On Thu, February 15, 2007 11:36 am, Pavel Machek said: >>> sys_vendor = "Sony Corporation" >>> sys_product = "PCG-SRX51P(DE) " >>> sys_version = "01 " >>> bios_version = "R0232U2" >>> > (unrelated to your suspend problems) does the sony-laptop (formerly > sony_acpi) module helps controlling brightness? > (should appear soon or you can eventually grab it from the linux-acpi tree) No, I use the sonypi driver. But I can test the sony-laptop one as soon as it is in -mm again if it would be of any help. >>> Latest kernel I tested is 2.6.20-git11 from today. > > I read reports of successful suspends on that laptop, eg: > http://freenet-homepage.de/obauer/index.html Ok, now I feel totally dumb. 's2ram -s -f' actually works iff you disable fb support completely in the kernel. It works even from X. Don't know how many combinations I tried but that one somehow slipped through. Anyway thanks for your help. So could this machine be added to the s2ram database? Thanks, Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] LinuxPPS: Pulse per Second support for Linux
Some non political comments
Rodolfo Giometti wrote:
> +Coding example
> +--
> +
> +To register a PPS source into the kernel you should define a struct
> +linuxpps_source_info_s as follow:
> +
> +static struct linuxpps_source_info_s linuxpps_ktimer_info = {
Drop the linux prefix. It's in the linux kernel after all.
> +PROCFS support
> +--
New features shouldn't introduce new /proc stuff.
> +Resources
> +-
> +
> +Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support and the LinuxPPS
> +ML: http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps.
Add to MAINTAINERS
Your way to hook into lp and 8250 is pretty gross. It should at least be
possible to deactivate it via the kernel command line, but it would be
a lot nicer to have pps_lp and pps_8250 modules which you can load. Also
what happens if you've multiple lp ports? How do you control which to
grab?
- don't implement your own dbg() stuff, use dprintk and friends
- drop the inlines, gcc will do the right thing.
> --- a/drivers/char/lp.c
> +++ b/drivers/char/lp.c
> static struct parport_driver lp_driver = {
> diff --git a/drivers/parport/parport_pc.c b/drivers/parport/parport_pc.c
> index b61c17b..426b0ac 100644
> --- a/drivers/parport/parport_pc.c
> +++ b/drivers/parport/parport_pc.c
> @@ -272,6 +272,14 @@ static int clear_epp_timeout(struct parport *pb)
>
> static irqreturn_t parport_pc_interrupt(int irq, void *dev_id)
> {
> +#ifdef CONFIG_PPS_CLIENT_LP_PARPORT_PC
> + struct parport *p = (struct parport *) dev_id;
> +
> + linuxpps_event(p->pps_source, PPS_CAPTUREASSERT, p);
Perhaps just implement empty defines for the none pps cases and get
rid of the ifdefs? But this should really be controllabe via
sysfs or such.
> --- /dev/null
> +++ b/drivers/pps/clients/Kconfig
> @@ -0,0 +1,56 @@
> +#
> +# LinuxPPS clients configuration
> +#
> +
> +if PPS
> +
> +comment "PPS clients support"
> +
> +config PPS_CLIENT_KTIMER
> + tristate "Kernel timer client (Testing client, use for debug)"
> + help
> + If you say yes here you get support for a PPS debugging client
> + which uses a kernel timer to generate the PPS signal.
> +
> + This driver can also be built as a module. If so, the module
> + will be called ktimer.o.
> +
> +comment "UART serial support (forced off)"
> + depends on SERIAL_CORE && ( PPS = m && SERIAL_CORE = y )
> +
> +config PPS_CLIENT_UART
> + bool "UART serial support"
> + depends on SERIAL_CORE && ! ( PPS = m && SERIAL_CORE = y )
help text
> +
> +comment "8250 serial support (forced off)"
> + depends on PPS_CLIENT_UART && SERIAL_8250 && \
> + ( PPS = m && SERIAL_8250 = y )
> +
> +config PPS_CLIENT_UART_8250
> + bool "8250 serial support"
> + depends on PPS_CLIENT_UART && SERIAL_8250 && \
> + ! ( PPS = m && SERIAL_8250 = y )
> + help
> + If you say yes here you get support for a PPS source connected
> + with the CD (Carrier Detect) pin of your 8250 serial line chip.
> +
> +comment "Parallel printer support (forced off)"
> + depends on PRINTER && ( PPS = m && PRINTER = y )
> +
> +config PPS_CLIENT_LP
> + bool "Parallel printer support"
> + depends on PRINTER && ! ( PPS = m && PRINTER = y )
help text
> +comment "Parport PC support (forced off)"
> + depends on PPS_CLIENT_LP && PARPORT_PC && \
> + ( PPS = m && PARPORT_PC = y )
> +
> +config PPS_CLIENT_LP_PARPORT_PC
> + bool "Parport PC support"
> + depends on PPS_CLIENT_LP && PARPORT_PC && \
> + ! ( PPS = m && PARPORT_PC = y )
> + help
> + If you say yes here you get support for a PPS source connected
> + with the interrupt pin of your PC parallel port.
help text and difference to CLIENT_LP?
> +++ b/drivers/pps/kapi.c
> +/* --- Local functions -
> */
> +
> +#ifndef NSEC_PER_SEC
> +#define NSEC_PER_SEC10
> +#endif
What's that for? Why is(n't) it defined?
> + for (i = 0; i < LINUXPPS_MAX_SOURCES; i++)
> + if (!__linuxpps_is_allocated(i))
> + break;
> + if (i >= LINUXPPS_MAX_SOURCES) {
> + err("no free source ids");
> + return -ENOMEM;
> + }
Why no dynamically allocated array?
> +void linuxpps_event(int source, int event, void *data)
> +{
> + struct timespec ts;
> +
> + /* In this function we shouldn't need locking at all since each PPS
> + * source arrives once per second and due the per-PPS source data
> + * array... */
I wouldn't bet on that.
> +++ b/drivers/pps/pps.c
> @@ -0,0 +1,377 @@
> +/*
> + * main.c -- Main driver file
Doesn't match filename
> +++ b/drivers/pps/procfs.c
I'd drop that completely.
> +++ b/include/linux/netlink.h
> @@ -21,7 +21,7 @@
> #define NETLINK_DNRTMSG 14 /* DECnet routin
Re: [PATCH 1/1] LinuxPPS: Pulse per Second support for Linux
Rodolfo Giometti wrote: >>> +PROCFS support >>> +-- >> New features shouldn't introduce new /proc stuff. > > It's a must? I can leave procfs for backward compatibility with old > utilities? Hmm, as this is a new feature with regard to the mainline kernel, old utilities don't count (if you can install a new kernel you can also be expected to install new user-space tools for the new feature). >> You read the comment above your line? > > No, sorry. I'm going to choose another id number... or can I keep 17? I don't know, ask whoever is responsible for the file. >>> +#define to_class_dev(obj) container_of((obj), struct class_device, kobj) >> pretty generic name. > > I should change it? If it's of general use put it in the appropriate header file. If it's just for the pps subsystem name it as such. >> Have you thought about 32/64bit issues? > > No. I have no 64 bits machine to test the code... Hmm, think about x86_64 with 64-bit kernel and 32-bit userspace, probably having got different padding in the struct. Read LDD3, chapter 11, especially 11.4 . Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ltt-dev] [PATCH 00/09] atomic.h : standardizing atomic primitives
Andrew Morton wrote: > On Sat, 27 Jan 2007 21:09:11 +0100 > Willy Tarreau <[EMAIL PROTECTED]> wrote: > >> On Sat, Jan 27, 2007 at 12:05:12PM -0800, Andrew Morton wrote: >>> On Sat, 27 Jan 2007 13:11:16 -0500 >>> Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: >>> I am currently trying crosstool by Dan Kegel, it looks promising. http://www.kegel.com/crosstool/ >>> Yeah, I spent a frustrating two days with crosstool, managed to eke a >>> number of cross-compilers out of it, but it took a *lot* of experimentation >>> with gcc, glibc and binutils versions to get combinations which actually >>> work. Good luck ;) >>> >>> There used to be someone who had a full suite, and who regularly published >>> cross-compile results, but he stopped 6-12 months ago and I forget who that >>> clever person was? >> Wasn't it buildroot from Erik Andersen ? >> >>http://buildroot.uclibc.org/ >> > > No, it was http://l4x.org/k/ It still appears to be operating, with > scary-looking results. > > Jan, is there any way in which you can help us publish a full suite of > cross-compiler binaries? Probably not. I could publish a qemu i386 image with all cross compilers though. But some are not build from source but are obtained from more or less obscure sources (m32r, sh64). Currently this CHK include/linux/utsrelease.h "2.6.20-rc6cat:include/config/kernel.release:Nosuchfileordirectory" exceeds 64 characters make[1]: *** [include/linux/utsrelease.h] Error 1 make: *** [_all] Error 2 bug, which I reported weeks ago, makes the result invalid for most archs. But as I get nearly zero feedback about the results and I've lots of other obligations currently, my motivation to work on that is pretty much nil. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lirc: remove backwards compatibility macro obfuscation (Was: Free Linux Driver Development!)
Pekka J Enberg wrote: From: Pekka Enberg <[EMAIL PROTECTED]> On 02 Feb 2007 05:54:00 +0100, Christoph Bartelmus <[EMAIL PROTECTED]> wrote: I just made clear that I don't have the time to do the merging of LIRC drivers to the kernel myself. In fact a lot of work still needs to be done before LIRC drivers are ready to be included into the kernel. [snip] On 02 Feb 2007 05:54:00 +0100, Christoph Bartelmus <[EMAIL PROTECTED]> wrote: Any help welcome. Here's a start. You really should run Lindent on the sources too. Pekka, it would be better if you could sort out most of the basic issues with lirc directly with the developers of lirc and then prepare a complete patch series and post that to lkml. Incrementally adding one driver after another. Posting patches to non-existent sources to lkml is pointless. First create a discussion base, please. Signed-off-by: Pekka Enberg <[EMAIL PROTECTED]> --- drivers/lirc_atiusb/lirc_atiusb.c | 102 - drivers/lirc_bt829/lirc_bt829.c |9 - You might want to fix the directory structure first and check which drivers already exist in-tree. Also, as Vincent noted, most drivers have to be converted to use the input layer first. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lirc: remove backwards compatibility macro obfuscation (Was: Free Linux Driver Development!)
Pekka Enberg wrote: On 2/2/07, Jan Dittmer <[EMAIL PROTECTED]> wrote: Pekka, it would be better if you could sort out most of the basic issues with lirc directly with the developers of lirc and then prepare a complete patch series and post that to lkml. Incrementally adding one driver after another. Posting patches to non-existent sources to lkml is pointless. First create a discussion base, please. What discussion base? You need to get rid of the cruft anyway and now you have patch to do that. I am not volunteering to sort out _all_ the issues. I really really welcome your efforts - no doubt. I wanted to express that the patches you posted are simply not suitable for lkml discussion as there was no full patchset for lirc for review posted, prior to your patches. Normal process for new features (and lirc is a new feature so far lkml is concerned) is like (as I understand it): 1. post full patchset 2. duck 3. receive criticism & patches 4. integrate results from 3 5. goto 1 You started at 3. It would be better to start with the whole picture at 1. I hope I made myself clearer now. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
(Cross) compiling fails on first try (was Re: 2.6.20-rc1-mm1)
Any ideas? Happens only on some archs (not affected is alpha, i386, ia64, sparc, sparc64). Happens not with 2.6.19(.1). See http://l4x.org/k/ for more logs. 2.6.20-rc1 is also affected. # make HOSTCC=gcc-3.4 ARCH=um CROSS_COMPILE= CROSS32_COMPILE= O=/tmp/tmp.abUIc11429/out/um defconfig # make HOSTCC=gcc-3.4 ARCH=um CROSS_COMPILE= CROSS32_COMPILE= O=/tmp/tmp.abUIc11429/out/um GEN /tmp/tmp.abUIc11429/out/um/Makefile scripts/kconfig/conf -s arch/um/Kconfig MKDIR /tmp/tmp.abUIc11429/out/um/arch/um/include SYMLINK arch/um/include/kern_constants.h SYMLINK include/asm-um/arch SYMLINK arch/um/include/sysdep SYMLINK arch/um/os SYMLINK include/asm-um/archparam.h SYMLINK include/asm-um/system.h SYMLINK include/asm-um/sigcontext.h SYMLINK include/asm-um/processor.h SYMLINK include/asm-um/ptrace.h SYMLINK include/asm-um/module.h SYMLINK include/asm-um/vm-flags.h SYMLINK include/asm-um/elf.h SYMLINK include/asm-um/host_ldt.h CHK arch/um/include/uml-config.h UPD arch/um/include/uml-config.h CC arch/um/sys-x86_64/user-offsets.s CHK arch/um/include/user_constants.h UPD arch/um/include/user_constants.h Using /tmp/x as source for kernel GEN /tmp/tmp.abUIc11429/out/um/Makefile CHK include/linux/version.h UPD include/linux/version.h CHK include/linux/compile.h UPD include/linux/compile.h CHK include/linux/utsrelease.h "2.6.20-rc1-mm1cat:include/config/kernel.release:Nosuchfileordirectory" exceeds 64 characters make[1]: *** [include/linux/utsrelease.h] Error 1 make: *** [_all] Error 2 # make HOSTCC=gcc-3.4 ARCH=um CROSS_COMPILE= CROSS32_COMPILE= O=/tmp/tmp.abUIc11429/out/um SYMLINK arch/um/include/kern_constants.h SYMLINK arch/um/include/sysdep make[2]: `arch/um/sys-x86_64/user-offsets.s' is up to date. Using /tmp/x as source for kernel GEN /tmp/tmp.abUIc11429/out/um/Makefile CHK include/linux/version.h CHK include/linux/compile.h CHK include/linux/utsrelease.h UPD include/linux/utsrelease.h SYMLINK include/asm -> include/asm-um CC arch/um/kernel/asm-offsets.s GEN include/asm-um/asm-offsets.h CC scripts/mod/empty.o HOSTCC scripts/mod/mk_elfconfig MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/modpost.o HOSTCC scripts/mod/sumversion.o HOSTLD scripts/mod/modpost HOSTCC scripts/kallsyms HOSTCC scripts/bin2c CC init/main.o CC init/version.o CC init/do_mounts.o LD init/mounts.o CC init/noinitramfs.o Thanks, Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Gaming Interface
Dirk wrote: > Alright. I came to discuss an idea I had because I realized that > installing Windows and running Linux in VMware is the only _fun_ way to > play "real" Games and have Linux at the same time. > > And everyone who says I'm a troll doesn't like Games or simple things. That's not true, see wine/cedega for a linux direct-x implementation. Works wonders with most of the current games and copy protections. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mass-storage problems with Archos AV500
David Weinehall wrote: On Wed, Nov 29, 2006 at 10:35:29PM -0600, Robert Hancock wrote: David Weinehall wrote: I've got an Archos AV500 here (running the very latest firmware), pretty much acting as a doorstop, since I cannot get it to be recognized properly by Linux. .. [ 118.144000] SCSI device sdb: 58074975 512-byte hdwr sectors (29734 MB) [ 118.144000] sdb: Write Protect is off [ 118.144000] sdb: Mode Sense: 33 00 00 00 [ 118.144000] sdb: assuming drive cache: write through [ 118.144000] sdb: unknown partition table [ 118.452000] sd 4:0:0:0: Attached scsi removable disk sdb [ 118.452000] usb-storage: device scan complete This is with linux-image-2.6.19-7-generic 2.6.19-7.10 from Ubuntu edgy. I get similar results with a home-brew 2.6.18-rc4. Any mass storage quirk needed that might be missing? That all seems normal, other than the unknown partition table, but the device might be all one unpartitioned disk.. at what point is it failing? Mounting it just claims wrong FS type. And I've tried most file systems I can think of just to be sure. Can you read the whole volume with 'dd'? If yes, you could provide a hex dump of the first few sectors? Probably someone on this list will recognize the format... Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sched: rename idle_type/SCHED_IDLE
Linux Kernel Mailing List wrote:
> Gitweb:
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d15bcfdbe1818478891d714343f037cfe60875f0
> Commit: d15bcfdbe1818478891d714343f037cfe60875f0
> Parent: 7dcca30a32aadb0520417521b0c44f42d09fe05c
> Author: Ingo Molnar <[EMAIL PROTECTED]>
> AuthorDate: Mon Jul 9 18:51:57 2007 +0200
> Committer: Ingo Molnar <[EMAIL PROTECTED]>
> CommitDate: Mon Jul 9 18:51:57 2007 +0200
>
> sched: rename idle_type/SCHED_IDLE
>
> enum idle_type (used by the load-balancer) clashes with the
> SCHED_IDLE name that we want to introduce. 'CPU_IDLE' instead
> of 'SCHED_IDLE' is more descriptive as well.
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -639,12 +639,11 @@ static inline int sched_info_on(void)
> #endif
> }
>
> -enum idle_type
> -{
> - SCHED_IDLE,
> - NOT_IDLE,
> - NEWLY_IDLE,
> - MAX_IDLE_TYPES
> +enum cpu_idle_type {
> + CPU_IDLE,
> + CPU_NOT_IDLE,
> + CPU_NEWLY_IDLE,
> + CPU_MAX_IDLE_TYPES
> };
>
> /*
This broke s390:
GEN /tmp/tmp.qnrRZ13800/out/s390/Makefile
CHK include/linux/version.h
UPD include/linux/version.h
CHK include/linux/utsrelease.h
UPD include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-s390
CC arch/s390/kernel/asm-offsets.s
In file included from
/tmp/tmp.qnrRZ13800/kernel/arch/s390/kernel/asm-offsets.c:7:
/tmp/tmp.qnrRZ13800/kernel/include/linux/sched.h:641: error: syntax
error before numeric constant
make[2]: *** [arch/s390/kernel/asm-offsets.s] Error 1
make[1]: *** [prepare0] Error 2
make: *** [_all] Error 2
CLEAN .tmp_versions
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Blackfin arch fixes (try #2)
Mike Frysinger wrote: > On 7/4/07, Jan Dittmer <[EMAIL PROTECTED]> wrote: >> Mike Frysinger wrote: >>> On 7/3/07, Jan Dittmer <[EMAIL PROTECTED]> wrote: >>>> Bryan Wu wrote: >>>>> Jie's patch is required because we will release our new Blackfin >>>>> toolchain. >>>> So, what is the new toolchain version? >>>> gcc 4.1.1 (adi 07r1) / binutils 2.17 doesn't seem to work anymore: >>> we'll post new toolchain binaries in a bit >> Hrm, somehow I don't understand it. On [1] you're >> talking about gcc 4.1.2 and binutils 2.17 supporting >> the -mcpu switch. But if you download the 2007R1 RC9 >> toolchain from the Files section of the site (tar.gz) >> you actually get 4.1.1 without mcpu support. But the >> version string from gcc indicates 07r1. >> Care to explain? > > the syntax of the -mcpu option was extended With the current -elf toolchain from svn (-uclinux toolchain fails to build) I get the following error: CC fs/binfmt_script.o CC fs/binfmt_elf_fdpic.o CC fs/binfmt_flat.o fs/binfmt_flat.c: In function ‘decompress_exec’: fs/binfmt_flat.c:293: warning: label ‘out’ defined but not used fs/binfmt_flat.c: In function ‘load_flat_file’: fs/binfmt_flat.c:462: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘long int’ fs/binfmt_flat.c:462: warning: format ‘%x’ expects type ‘unsigned int’, but argument 4 has type ‘long int’ fs/binfmt_flat.c:549: warning: passing argument 1 of ‘ksize’ makes pointer from integer without a cast fs/binfmt_flat.c:601: warning: passing argument 1 of ‘ksize’ makes pointer from integer without a cast fs/binfmt_flat.c:760:50: error: macro "flat_get_addr_from_rp" requires 4 arguments, but only 3 given fs/binfmt_flat.c:760: error: ‘flat_get_addr_from_rp’ undeclared (first use in this function) fs/binfmt_flat.c:760: error: (Each undeclared identifier is reported only once fs/binfmt_flat.c:760: error: for each function it appears in.) make[2]: *** [fs/binfmt_flat.o] Error 1 make[1]: *** [fs] Error 2 make: *** [_all] Error 2 Expected? Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [POWERPC] Update defconfigs
Linux Kernel Mailing List wrote: > Gitweb: > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ca74c013441200b162f6a384b23b833d1865a9e8 > Commit: ca74c013441200b162f6a384b23b833d1865a9e8 > Parent: d30d6badd1769a00bc5a800b8af4e8b3f169c633 > Author: Paul Mackerras <[EMAIL PROTECTED]> > AuthorDate: Tue Jun 26 14:19:35 2007 +1000 > Committer: Paul Mackerras <[EMAIL PROTECTED]> > CommitDate: Tue Jun 26 14:38:47 2007 +1000 > > [POWERPC] Update defconfigs > > Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> > --- > arch/powerpc/configs/cell_defconfig| 243 +++- Regression from -rc6, cell_defconfig does not build anymore: Building modules, stage 2. MODPOST 135 modules ERROR: ".pmi_send_message" [arch/powerpc/platforms/cell/cbe_cpufreq.ko] undefined! ERROR: ".pmi_unregister_handler" [arch/powerpc/platforms/cell/cbe_cpufreq.ko] undefined! ERROR: ".pmi_register_handler" [arch/powerpc/platforms/cell/cbe_cpufreq.ko] undefined! make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make: *** [_all] Error 2 I've left the relevant diff attached. Jan > diff --git a/arch/powerpc/configs/cell_defconfig > b/arch/powerpc/configs/cell_defconfig > index 02c428a..74f83f4 100644 > --- a/arch/powerpc/configs/cell_defconfig > +++ b/arch/powerpc/configs/cell_defconfig > @@ -1,7 +1,7 @@ > # > # Automatically generated make config: don't edit > -# Linux kernel version: 2.6.21-rc6 > -# Mon Apr 23 20:46:48 2007 > +# Linux kernel version: 2.6.22-rc6 > +# Tue Jun 26 12:32:34 2007 > # > CONFIG_PPC64=y > CONFIG_64BIT=y > @@ -41,6 +41,7 @@ CONFIG_PPC_DCR=y > CONFIG_PPC_OF_PLATFORM_PCI=y > CONFIG_ALTIVEC=y > CONFIG_PPC_STD_MMU=y > +CONFIG_PPC_MM_SLICES=y > CONFIG_VIRT_CPU_ACCOUNTING=y > CONFIG_SMP=y > CONFIG_NR_CPUS=4 > @@ -69,6 +70,7 @@ CONFIG_SYSVIPC_SYSCTL=y > # CONFIG_AUDIT is not set > CONFIG_IKCONFIG=y > CONFIG_IKCONFIG_PROC=y > +CONFIG_LOG_BUF_SHIFT=15 > CONFIG_CPUSETS=y > CONFIG_SYSFS_DEPRECATED=y > # CONFIG_RELAY is not set > @@ -87,14 +89,19 @@ CONFIG_BUG=y > CONFIG_ELF_CORE=y > CONFIG_BASE_FULL=y > CONFIG_FUTEX=y > +CONFIG_ANON_INODES=y > CONFIG_EPOLL=y > +CONFIG_SIGNALFD=y > +CONFIG_TIMERFD=y > +CONFIG_EVENTFD=y > CONFIG_SHMEM=y > -CONFIG_SLAB=y > CONFIG_VM_EVENT_COUNTERS=y > +CONFIG_SLAB=y > +# CONFIG_SLUB is not set > +# CONFIG_SLOB is not set > CONFIG_RT_MUTEXES=y > # CONFIG_TINY_SHMEM is not set > CONFIG_BASE_SMALL=0 > -# CONFIG_SLOB is not set > > # > # Loadable module support > @@ -163,9 +170,14 @@ CONFIG_SPU_FS=m > CONFIG_SPU_BASE=y > CONFIG_CBE_RAS=y > CONFIG_CBE_THERM=m > +CONFIG_CBE_CPUFREQ=m > +# CONFIG_PQ2ADS is not set > CONFIG_PPC_NATIVE=y > CONFIG_UDBG_RTAS_CONSOLE=y > CONFIG_PPC_UDBG_BEAT=y > +CONFIG_MPIC=y > +# CONFIG_MPIC_WEIRD is not set > +# CONFIG_PPC_I8259 is not set > # CONFIG_U3_DART is not set > CONFIG_PPC_RTAS=y > # CONFIG_RTAS_ERROR_LOGGING is not set > @@ -177,9 +189,23 @@ CONFIG_MMIO_NVRAM=y > # CONFIG_PPC_970_NAP is not set > CONFIG_PPC_INDIRECT_IO=y > CONFIG_GENERIC_IOMAP=y > -# CONFIG_CPU_FREQ_PMAC64 is not set > -# CONFIG_WANT_EARLY_SERIAL is not set > -CONFIG_MPIC=y > +CONFIG_CPU_FREQ=y > +CONFIG_CPU_FREQ_TABLE=y > +# CONFIG_CPU_FREQ_DEBUG is not set > +CONFIG_CPU_FREQ_STAT=y > +# CONFIG_CPU_FREQ_STAT_DETAILS is not set > +CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y > +# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set > +CONFIG_CPU_FREQ_GOV_PERFORMANCE=y > +CONFIG_CPU_FREQ_GOV_POWERSAVE=y > +CONFIG_CPU_FREQ_GOV_USERSPACE=y > +CONFIG_CPU_FREQ_GOV_ONDEMAND=y > +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y > + > +# > +# CPU Frequency drivers > +# > +# CONFIG_CPM2 is not set > > # > # Kernel options > @@ -224,12 +250,14 @@ CONFIG_RESOURCES_64BIT=y > CONFIG_ZONE_DMA_FLAG=1 > CONFIG_ARCH_MEMORY_PROBE=y > CONFIG_NODES_SPAN_OTHER_NODES=y > +CONFIG_PPC_HAS_HASH_64K=y > CONFIG_PPC_64K_PAGES=y > CONFIG_SCHED_SMT=y > CONFIG_PROC_DEVICETREE=y > # CONFIG_CMDLINE_BOOL is not set > # CONFIG_PM is not set > CONFIG_SECCOMP=y > +# CONFIG_WANT_DEVICE_TREE is not set > CONFIG_ISA_DMA_API=y > > # > @@ -237,22 +265,18 @@ CONFIG_ISA_DMA_API=y > # > CONFIG_ZONE_DMA=y > CONFIG_GENERIC_ISA_DMA=y > -# CONFIG_MPIC_WEIRD is not set > -# CONFIG_PPC_I8259 is not set > # CONFIG_PPC_INDIRECT_PCI is not set > CONFIG_PCI=y > CONFIG_PCI_DOMAINS=y > CONFIG_PCIEPORTBUS=y > +CONFIG_ARCH_SUPPORTS_MSI=y > +# CONFIG_PCI_MSI is not set > # CONFIG_PCI_DEBUG is not set > > # > # PCCARD (PCMCIA/CardBus) support > # > # CONFIG_PCCARD is not set > - > -# > -# PCI Hotplug Support > -# > # CONFIG_HOTPLUG_PCI is not set > CONFIG_KERNEL_START=0xc000 > > @@ -264,7 +288,6 @@ CONFIG_NET=y > # > # Networking options > # > -# CONFIG_NETDEBUG is not set > CONFIG_PACKET=y > # CONFIG_PACKET_MMAP is not set > CONFIG_UNIX=y > @@ -300,14 +323,11 @@ CONFIG_INET_TCP_DIAG=y > CONFIG_TCP_CONG_CUBIC=y > CONFIG_DEFAULT_TCP_CONG="cubic" > # CONFIG_TCP_MD5SIG is not set > - > -# > -
Re: Mounting MMC card
Midhun Agnihotram wrote: > Sorry for resending. I dont know if my previous mail has reached the > list with "Fwd" in the subject line. I am pretty sure there must a > filter in Majordomo to discard forwards. Actually I am resending the > mail I had sent to Linux-Arm-Kernel. The mail came already through the first time. It may take a while. There are a _lot_ of subscribers and a _lot_ of mails. > brwxrwxrwx1 00254, 0 Jun 26 2007 mmcblk0 > brwxrwxrwx1 00254, 1 Jun 26 2007 mmcblk0p0 > brwxrwxrwx1 00254, 2 Jun 26 2007 mmcblk0p1 > brwxrwxrwx1 00254, 3 Jun 26 2007 mmcblk0p2 > brwxrwxrwx1 00254, 4 Jun 26 2007 mmcblk0p3 > > How do I access the MMC card data now? If I try to mount it, > busybox doesnot mount it. > > # mount /dev/mmcblk0p0 /mnt/mmc > mount: mounting /dev/mmcblk0p0 on /mnt/mmc failed > > I have tried with /dev/mmcblk0p0, mmcblk0p1,etc. But of no use. How Try to mount mmcblk0 and/or try fdisk and look at the partition table. dmesg output would also be helpful (after the failed mount). Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Blackfin arch fixes (try #2)
Bryan Wu wrote: Hi Linus: Marco's patch will kill the zero file git-pull error. Jie's patch is required because we will release our new Blackfin toolchain. So, what is the new toolchain version? gcc 4.1.1 (adi 07r1) / binutils 2.17 doesn't seem to work anymore: bf533-stamp_defconfig [1]: CC arch/blackfin/kernel/asm-offsets.s cc1: error: unrecognized command line option "-mcpu=bf533-0.3" make[2]: *** [arch/blackfin/kernel/asm-offsets.s] Error 1 make[1]: *** [prepare0] Error 2 make: *** [_all] Error 2 bf561-ezkit_defconfig [2]: CC arch/blackfin/kernel/asm-offsets.s cc1: error: unrecognized command line option "-mcpu=bf561-0.3" make[2]: *** [arch/blackfin/kernel/asm-offsets.s] Error 1 make[1]: *** [prepare0] Error 2 make: *** [_all] Error 2 previously, there was only this error (defconfig) [3]: CC fs/binfmt_flat.o /tmp/tmp.RAuANA4724/kernel/fs/binfmt_flat.c: In function ‘decompress_exec’: /tmp/tmp.RAuANA4724/kernel/fs/binfmt_flat.c:293: warning: label ‘out’ defined but not used /tmp/tmp.RAuANA4724/kernel/fs/binfmt_flat.c: In function ‘load_flat_file’: /tmp/tmp.RAuANA4724/kernel/fs/binfmt_flat.c:462: warning: format ‘%x’ expects type ‘unsigned int’, but argument 3 has type ‘long int’ /tmp/tmp.RAuANA4724/kernel/fs/binfmt_flat.c:462: warning: format ‘%x’ expects type ‘unsigned int’, but argument 4 has type ‘long int’ /tmp/tmp.RAuANA4724/kernel/fs/binfmt_flat.c:549: warning: passing argument 1 of ‘ksize’ makes pointer from integer without a cast /tmp/tmp.RAuANA4724/kernel/fs/binfmt_flat.c:601: warning: passing argument 1 of ‘ksize’ makes pointer from integer without a cast /tmp/tmp.RAuANA4724/kernel/fs/binfmt_flat.c:760:50: error: macro "flat_get_addr_from_rp" requires 4 arguments, but only 3 given /tmp/tmp.RAuANA4724/kernel/fs/binfmt_flat.c:760: error: ‘flat_get_addr_from_rp’ undeclared (first use in this function) /tmp/tmp.RAuANA4724/kernel/fs/binfmt_flat.c:760: error: (Each undeclared identifier is reported only once /tmp/tmp.RAuANA4724/kernel/fs/binfmt_flat.c:760: error: for each function it appears in.) make[2]: *** [fs/binfmt_flat.o] Error 1 make[1]: *** [fs] Error 2 make: *** [_all] Error 2 Thanks, Jan [1] http://l4x.org/k/?d=31517 [2] http://l4x.org/k/?d=31518 [3] http://l4x.org/k/?d=31478 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Blackfin arch fixes (try #2)
Mike Frysinger wrote: > On 7/3/07, Jan Dittmer <[EMAIL PROTECTED]> wrote: >> Bryan Wu wrote: >>> Jie's patch is required because we will release our new Blackfin toolchain. >> So, what is the new toolchain version? >> gcc 4.1.1 (adi 07r1) / binutils 2.17 doesn't seem to work anymore: > > we'll post new toolchain binaries in a bit Hrm, somehow I don't understand it. On [1] you're talking about gcc 4.1.2 and binutils 2.17 supporting the -mcpu switch. But if you download the 2007R1 RC9 toolchain from the Files section of the site (tar.gz) you actually get 4.1.1 without mcpu support. But the version string from gcc indicates 07r1. Care to explain? Thanks, Jan ps: All in all it is a bit unfortunate to put features in the upstream kernel for a toolchain version just available from svn. [1] http://docs.blackfin.uclinux.org/doku.php?id=toolchain_release_notes_2007r1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Blackfin arch fixes (try #2)
Mike Frysinger wrote: On 7/4/07, Jan Dittmer <[EMAIL PROTECTED]> wrote: Mike Frysinger wrote: > On 7/3/07, Jan Dittmer <[EMAIL PROTECTED]> wrote: >> Bryan Wu wrote: >>> Jie's patch is required because we will release our new Blackfin toolchain. >> So, what is the new toolchain version? >> gcc 4.1.1 (adi 07r1) / binutils 2.17 doesn't seem to work anymore: > > we'll post new toolchain binaries in a bit Hrm, somehow I don't understand it. On [1] you're talking about gcc 4.1.2 and binutils 2.17 supporting the -mcpu switch. But if you download the 2007R1 RC9 toolchain from the Files section of the site (tar.gz) you actually get 4.1.1 without mcpu support. But the version string from gcc indicates 07r1. Care to explain? the syntax of the -mcpu option was extended But the tar-ball does _not_ contain 4.1.2 Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc6-git1 i386/allmodconfig broke
Since -rc6: - i386/allmodconfig: broke CC [M] net/bluetooth/hci_core.o CC [M] net/bluetooth/hci_conn.o CC [M] net/bluetooth/hci_event.o CC [M] net/bluetooth/hci_sock.o net/bluetooth/hci_sock.c: In function 'hci_sock_cmsg': net/bluetooth/hci_sock.c:352: error: storage size of 'ctv' isn't known net/bluetooth/hci_sock.c:352: warning: unused variable 'ctv' make[3]: *** [net/bluetooth/hci_sock.o] Error 1 make[2]: *** [net/bluetooth] Error 2 make[1]: *** [net] Error 2 make: *** [_all] Error 2 Nice, that post rc6 patches aren't even tested with one of the most common archs and configs :-( Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Blackfin arch bug fixing for 2.6.23-rc6
Bryan Wu wrote: Hi Linus, Please pull from 'for-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/cooloney/blackfin-2.6.git for-linus to receive the following updates: arch/blackfin/mach-common/pm.c |6 ++ include/asm-blackfin/mach-bf561/cdefBF561.h |4 +- include/asm-blackfin/string.h | 129 +-- btw. what about this error? fs/binfmt_flat.c:760:50: error: macro "flat_get_addr_from_rp" requires 4 arguments, but only 3 given fs/binfmt_flat.c:760: error: ‘flat_get_addr_from_rp’ undeclared (first use in this function) fs/binfmt_flat.c:760: error: (Each undeclared identifier is reported only once fs/binfmt_flat.c:760: error: for each function it appears in.) make[2]: *** [fs/binfmt_flat.o] Error 1 make[1]: *** [fs] Error 2 make: *** [_all] Error 2 any chance to get that fixed prior to .23? (not a regression, but happens approx. since blackfin was merged) Thanks, Jan Full build log: http://l4x.org/k/?d=34032 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Define termios_1 functions for powerpc, s390, avr32 and frv
Paul Mackerras wrote:
Commit f629307c857c030d5a3dd777fee37c8bb395e171 introduced uses of
kernel_termios_to_user_termios_1 and user_termios_to_kernel_termios_1
on all architectures. However, powerpc, s390, avr32 and frv don't
currently define those functions since their termios struct didn't
need to be changed when the arbitrary baud rate stuff was added, and
thus the kernel won't currently build on those architectures.
alpha, parisc, sh, sparc{64,}, xtensa are still broken with this error...
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Blackfin arch bug fixing for 2.6.23-rc6
Bryan Wu wrote: Need I disable CONFIG_BINFMT_FLAT in defconfigs for Blackfin to make the compile pass? That would be a workaround, yes. Better would be of course to fix the bug or the Kconfig dependency. Full build log: http://l4x.org/k/?d=34032 Thanks again, beautiful log and which defconfigs do you using to do the test and what's the toolchain version? All information is on the page: ld-version 2.17 gcc-version 4.1.2 (adi svn) make HOSTCC=gcc-4.0 ARCH=blackfin CROSS_COMPILE=bfin-elf- CROSS32_COMPILE= O=/tmp/tmp.vLOkGP3410/out/blackfin defconfig Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/02] vfs: variant symlinks
Ken Schmidt wrote: > Variant symlinks add the ability to embed variables in to the > contents of symbolic links so their targets can change based on > outside sources (user environment, uts, filesystems, etc.) Could you elaborate why this is needed and what part cannot be solved in userspace (linkfarm on tmpfs or intelligent scripts)? Thanks, Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
