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
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
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
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
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-wra
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
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_COMPI
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
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:
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:
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:
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:
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 fu
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: ***
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: ***
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
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
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
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
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
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
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
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 +-
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 +-
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
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
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
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
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:
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]>
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
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:
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
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
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
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
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-B
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
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
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
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
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
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
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
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
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
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
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
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
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
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 cr
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
>&g
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
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
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
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
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 Blac
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:
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
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
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
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 does
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
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]:
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]:
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
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
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:
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
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
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.
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
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
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)
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"
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 =
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"
>>
>>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
cut
#
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
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
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
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,
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
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
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
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 toolcha
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/bi
1 - 100 of 145 matches
Mail list logo