On 06/14/2010 08:11 AM, Toralf Förster wrote:
>
> Geert Uytterhoeven wrote at 16:39:00
>> I assume you did a `make clean' in between?
> ...
>> BTW, I'm also using ccache. Always. Ever. All my (cross)compilers are
> Well, I'm unsure - might be I made that mistake, especially b/c I use ccache
> too
Geert Uytterhoeven wrote at 16:39:00
> I assume you did a `make clean' in between?
...
> BTW, I'm also using ccache. Always. Ever. All my (cross)compilers are
Well, I'm unsure - might be I made that mistake, especially b/c I use ccache
too since years and didn't experienced any fault so far.
--
2010/6/14 Toralf Förster :
> Borislav Petkov wrote at 15:00:39
>
>> Linus' tree doesn't contain the fix yet - rather it is in -tip:
>> http://git.kernel.org/tip/055c47272b8f5679d08ccc57efea3cb4aaeb5fc6
>>
>> You can easily cherry-pick it from there and retest.
> Issue solved works with that patch.
From: Toralf Förster
Date: Mon, Jun 14, 2010 at 11:49:24AM +0200
> Borislav Petkov wrote at 16:10:58
> > Did you do 'make mrproper' before rebuilding UML with it?
>
> Today I started with a clean git tree (cloned Linus tree) and got this :
Right, I kinda missed that line, now it makes sense.
L
Borislav Petkov wrote at 15:00:39
> Linus' tree doesn't contain the fix yet - rather it is in -tip:
> http://git.kernel.org/tip/055c47272b8f5679d08ccc57efea3cb4aaeb5fc6
>
> You can easily cherry-pick it from there and retest.
Issue solved works with that patch.
FWIW : This command sequence prod
Paolo Giarrusso wrote at 12:26:11
> Can you enable frame pointers to get an accurate stack trace? x86 can
Attached the .config with that function enabled, here's the output :
...
Initializing software serial port version 1
console [mc-1] enabled
ubda:
EIP: 0073:[<081bfec3>] CPU: 0 Not tainted ESP
2010/6/14 Toralf Förster :
>
> Borislav Petkov wrote at 16:10:58
>> Did you do 'make mrproper' before rebuilding UML with it?
>
> Today I started with a clean git tree (cloned Linus tree) and got this :
>
> foer...@n22 ~ $ start_uml.sh
Can you enable frame pointers to get an accurate stack trace?
Borislav Petkov wrote at 16:10:58
> Did you do 'make mrproper' before rebuilding UML with it?
Today I started with a clean git tree (cloned Linus tree) and got this :
foer...@n22 ~ $ start_uml.sh
Locating the bottom of the address space ... 0x1000
Locating the top of the address space ... 0xc00
From: Geert Uytterhoeven
Date: Sat, Jun 12, 2010 at 08:37:39PM +0200
> > Cool :). However, according to Geert, this doesn't fix it:
> >
> > http://marc.info/?l=linux-kernel&m=127522065202435&w=2
> >
> > It could be related to the -mregparm being broken on 32-bit UML since
> > Geert's UML "guest"
On Sat, Jun 12, 2010 at 18:34, Borislav Petkov wrote:
> From: Paolo Giarrusso
> Date: Sat, Jun 12, 2010 at 06:01:44PM +0200
>
>> >> First, ARCH_HWEIGHT_CFLAGS should IMHO be shared with UML. I.e., moved
>> >> to arch/x86/Kconfig.cpu (which was born as Kconfig code shared with
>> >> UML), or copie
From: Paolo Giarrusso
Date: Sat, Jun 12, 2010 at 06:01:44PM +0200
> >> First, ARCH_HWEIGHT_CFLAGS should IMHO be shared with UML. I.e., moved
> >> to arch/x86/Kconfig.cpu (which was born as Kconfig code shared with
> >> UML), or copied in UML (it's not defined, as far as I can see).
> >> Otherwis
On Sat, Jun 12, 2010 at 16:18, Borislav Petkov wrote:
> From: Paolo Giarrusso
> Date: Sat, Jun 12, 2010 at 03:34:38PM +0200
>
> Hi,
>
>> > That looks better to me, although I'm still wondering why UML can't
>> > stomach the register-saving tricks... it is not at all "obvious" why
>> > that can't
From: Paolo Giarrusso
Date: Sat, Jun 12, 2010 at 03:34:38PM +0200
Hi,
> > That looks better to me, although I'm still wondering why UML can't
> > stomach the register-saving tricks... it is not at all "obvious" why
> > that can't be done.
> Hi all, and sorry for the delay, I hope you still care
On Sun, May 30, 2010 at 23:09, H. Peter Anvin wrote:
> On 05/30/2010 01:17 PM, Borislav Petkov wrote:
This bothers me, because it really feels like something is fundamentally
broken in UML tryingto track the upstream architecture, and this is just
a bandage.
>>>
>>> First of all, sc
From: Jeff Dike
Date: Mon, May 31, 2010 at 11:56:19AM -0400
> On Mon, May 31, 2010 at 03:51:32PM +0200, Borislav Petkov wrote:
> > includes which are
> > the optimized variants.
>
> But how does UML get to arch/x86/include/asm/bitops.h in the first place?
>
> It must go through an arch/um/inc
From: Toralf Förster
Date: Mon, May 31, 2010 at 09:55:53AM -0400
> Borislav Petkov wrote at 22:17:38
> > LKML-Reference: <201005271944.09541.toralf.foers...@gmx.de>
> > Signed-off-by: Borislav Petkov
> > ---
> > arch/um/include/asm/arch_hweight.h |6 ++
> > 1 files changed, 6 insertions
From: Jeff Dike
Date: Sun, May 30, 2010 at 10:32:12PM -0400
> On Sun, May 30, 2010 at 09:39:56PM +0200, Borislav Petkov wrote:
> > Which begs the question why _is_ UML sucking in x86 stuff and can anyone
> > provide us with some sensible reasons? Because if there aren't any, it
> > is their inclu
On Mon, May 31, 2010 at 03:51:32PM +0200, Borislav Petkov wrote:
> includes which are
> the optimized variants.
But how does UML get to arch/x86/include/asm/bitops.h in the first place?
It must go through an arch/um/include/asm/something.h (where something
might be bitops) first, right?
On 05/31/2010 04:55 PM, Toralf Förster wrote:
>
> Borislav Petkov wrote at 22:17:38
>> LKML-Reference: <201005271944.09541.toralf.foers...@gmx.de>
>> Signed-off-by: Borislav Petkov
>> ---
>> arch/um/include/asm/arch_hweight.h |6 ++
>> 1 files changed, 6 insertions(+), 0 deletions(-)
>>
Borislav Petkov wrote at 16:10:58
> Did you do 'make mrproper' before rebuilding UML with it?
Yes, I did "make mrproper ARC H= um" and "make mrproper"
> Also, can you do
>
> grep -EriIn 'x86.*hweight\.h' arch/um/
tfoer...@n22 ~/devel/linux-2.6 $ grep -EriIn 'x86.*hweight\.h' arch/um/
tfoer...@n
On Sun, May 30, 2010 at 09:39:56PM +0200, Borislav Petkov wrote:
> Which begs the question why _is_ UML sucking in x86 stuff and can anyone
> provide us with some sensible reasons? Because if there aren't any, it
> is their includes that should be fixed. Let me see what I can do to
> redirect hweig
Borislav Petkov wrote at 22:17:38
> LKML-Reference: <201005271944.09541.toralf.foers...@gmx.de>
> Signed-off-by: Borislav Petkov
> ---
> arch/um/include/asm/arch_hweight.h |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
> create mode 100644 arch/um/include/asm/arch_hweight.h
>
On 05/30/2010 01:17 PM, Borislav Petkov wrote:
>>> This bothers me, because it really feels like something is fundamentally
>>> broken in UML tryingto track the upstream architecture, and this is just
>>> a bandage.
>>
>> First of all, scratch that patch. It is indeed dumb idea to sprinkle UML
>> s
> > This bothers me, because it really feels like something is fundamentally
> > broken in UML tryingto track the upstream architecture, and this is just
> > a bandage.
>
> First of all, scratch that patch. It is indeed dumb idea to sprinkle UML
> special cases in x86 just because they include it.
From: "H. Peter Anvin"
Date: Sun, May 30, 2010 at 11:36:16AM -0700
> On 05/30/2010 10:03 AM, Borislav Petkov wrote:
> > Obviously UML cannot stomach callee reg-saving trickery
> > introduced with d61931d89be506372d01a90d1755f6d0a9fafe2d (x86:
> > Add optimized popcnt variants) and oopses during b
On 05/30/2010 10:03 AM, Borislav Petkov wrote:
> Obviously UML cannot stomach callee reg-saving trickery
> introduced with d61931d89be506372d01a90d1755f6d0a9fafe2d (x86:
> Add optimized popcnt variants) and oopses during boot:
> http://marc.info/?l=linux-kernel&m=127522065202435&w=2
>
> Go ahead a
26 matches
Mail list logo
