* Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: Nigel Stephens @ 2007-11-05 15:58 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Thiemo Seufer, Maciej W. Rozycki, Ralf Baechle, linux-mips
In-Reply-To: <472E2955.3000803@gmail.com>
Franck Bui-Huu wrote:
> Thiemo Seufer wrote:
>
>> Latest GCC upstream supports it (in SVN since 2007-07-05).
>>
>>
>
> Good news although gcc 4.3 release is planed for end of January.
>
Franck
A supported toolchain which now includes SmartMIPS support is the
CodeSourcery MIPS Linux toolchain, based on gcc-4.2, see
http://www.codesourcery.com/store/catalogue/c3/p17
> Is SDE gcc going to be obsolete after this release ?
>
A pre-built "bare-iron" SDE configuration of GCC will probably continue
to exist as part of the MIPS cross-development tools, but we are working
to ensure that as many as possible of the SDE changes are available
upstream for use by other Linux or GNU toolchain vendors, and/or those
who wish to roll their own toolchain.
Nigel
--
Nigel Stephens | 7200 Cambridge Research Park | t:[+44|0]1223 203110
MIPS Technologies | Cambridge, England CB25 9TL | f:[+44|0]1223 203181
^ permalink raw reply
* Re: 2.6.24-rc1 does not boot on SGI
From: Giuseppe Sacco @ 2007-11-05 16:54 UTC (permalink / raw)
To: linux-mips
In-Reply-To: <1194268551.4842.3.camel@scarafaggio>
Il giorno lun, 05/11/2007 alle 14.15 +0100, Giuseppe Sacco ha scritto:
[...]
> The latest git update, gave a bootable 2.6.24-rc1 but now, while
> booting, the system start looping and calling function print_irq_desc()
> from kernel/irq/internals.h. I can only read "...count:...unhandled:..."
[...]
Here it is:
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.20
sr 0:0:4:0: Attached scsi CD-ROM sr0
mice: PS/2 mouse device common for all mice
irq 13, desc: ffffffff804486e0, depth: 1, count: 0, unhandled: 0
->handle_irq(): ffffffff800663c0, handle_bad_irq+0x0/0x2c0
->chip(): ffffffff8043e320, 0xffffffff8043e320
->action(): 0000000000000000
IRQ_DISABLED set
unexpected IRQ # 13
irq 13, desc: ffffffff804486e0, depth: 1, count: 0, unhandled: 0
->handle_irq(): ffffffff800663c0, handle_bad_irq+0x0/0x2c0
->chip(): ffffffff8043e320, 0xffffffff8043e320
->action(): 0000000000000000
IRQ_DISABLED set
unexpected IRQ # 13
and keep printing about interrupt #13. The log from the start is
available here
http://eppesuigoccas.homedns.org/~giuseppe/debian/sgi-2.6.24-rc1-unexpted-irq13.log.bz
Bye,
Giuseppe
^ permalink raw reply
* Re: [RFC] Add __initbss section
From: Franck Bui-Huu @ 2007-11-05 20:32 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Ralf Baechle, Geert Uytterhoeven, linux-mips
In-Reply-To: <Pine.LNX.4.64N.0711051234230.857@blysk.ds.pg.gda.pl>
Maciej W. Rozycki wrote:
> On Sun, 4 Nov 2007, Franck Bui-Huu wrote:
>
>>> Hmm, isn't what `info ld' says enough?
>> Hmm, I'm must be blind but I missed that each time I read it. Could
>> you point out the section number please ?
>
> That's section 3.8, I would guess, but if what you are looking for is not
> there, then perhaps the description could be improved.
>
After reading section 3.8 "PHDRS Command", I still fail to find
something interesting.
Franck
^ permalink raw reply
* Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: Franck Bui-Huu @ 2007-11-05 20:43 UTC (permalink / raw)
To: Nigel Stephens; +Cc: Thiemo Seufer, Maciej W. Rozycki, Ralf Baechle, linux-mips
In-Reply-To: <472F3D93.1070400@mips.com>
Nigel Stephens wrote:
>
> A supported toolchain which now includes SmartMIPS support is the
> CodeSourcery MIPS Linux toolchain, based on gcc-4.2, see
> http://www.codesourcery.com/store/catalogue/c3/p17
Interesting.
It seems that MIPS toolchains are not part of the 'lite edition' though.
Thanks,
Franck
^ permalink raw reply
* Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: Franck Bui-Huu @ 2007-11-05 21:34 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Thiemo Seufer, Nigel Stephens, Maciej W. Rozycki, linux-mips
In-Reply-To: <20071105113618.GD27893@linux-mips.org>
Ralf Baechle wrote:
> On Sun, Nov 04, 2007 at 09:19:33PM +0100, Franck Bui-Huu wrote:
>
>>> Latest GCC upstream supports it (in SVN since 2007-07-05).
>>>
>> Good news although gcc 4.3 release is planed for end of January.
>>
>> Is SDE gcc going to be obsolete after this release ?
>
> As for the kernel I don't really care. The policy is that a working kernel
> must be buildable with a stock gcc. Which at times is painful, search for
> all the great use of .word in include/asm-mips/ ... This doesn't say
> anything against taking advantage of other toolchains such SDE; it's just
It's actually hard to know the advantages of using SDE over a stock gcc.
The only difference I'm aware of is the smartmips ASE support in SDE.
But since this support is going to be added in stock gccs, I don't see
any advantages now and I'm wondering if I can give up using SDE...
Franck
^ permalink raw reply
* Re: [PATCH] Kill __bzero()
From: Franck Bui-Huu @ 2007-11-05 21:51 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Franck Bui-Huu, linux-mips
In-Reply-To: <20071105112429.GC27893@linux-mips.org>
Ralf Baechle wrote:
>
> Memset is almost always only ever invoked with a zero argument. So the
> idea was to have something like this:
>
> extern void *__memset(void *__s, int __c, size_t __count);
> extern void *bzero(void *__s, size_t __count);
>
> static inline void *memset(void *s, int c, size_t count)
> {
> if (__builtin_constant_p(c) && c == 0) {
> bzero(s, count);
> return s;
> } else
> return __memset(s, __c, count);
> }
>
> But that was never quite implemented like this as you noticed.
Well I'm not sure we really need this. bzero() is not part of the
Linux string API, so it can only be used by MIPS specific code. And
with the current implementation of bzero(), $a1 needs to be setup to 0
anyway. That's why I simply killed it...
BTW, can memset() be an inlined function ?
>
> As for the differences in the return value, they're because of of
> clear_user and __clear_user which return the number of bytes that could
> _not_ be cleared in $a2. Memset being invoked through the normal C calling
> conventions ignores this value while it's the actual result of interest for
> __clear_user.
>
Yes I noticed this. Actually I'm wondering if we couldn't add a new
function, fill_user() like the following:
extern size_t fill_user(void __user *to, int c, size_t len);
This could be used by both memset() and clear_user():
#define memset(s,c,l) ({ (void)fill(s,c,l); s; })
#define clear_user(t,l) fill_user(t,0,l)
Therefore the definition of clear_user() could be saner.
What do you think ?
Franck
^ permalink raw reply
* Re: [PATCH] Kill __bzero()
From: Ralf Baechle @ 2007-11-05 23:18 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Franck Bui-Huu, linux-mips
In-Reply-To: <472F906F.7080205@gmail.com>
On Mon, Nov 05, 2007 at 10:51:43PM +0100, Franck Bui-Huu wrote:
> > Memset is almost always only ever invoked with a zero argument. So the
> > idea was to have something like this:
> >
> > extern void *__memset(void *__s, int __c, size_t __count);
> > extern void *bzero(void *__s, size_t __count);
> >
> > static inline void *memset(void *s, int c, size_t count)
> > {
> > if (__builtin_constant_p(c) && c == 0) {
> > bzero(s, count);
> > return s;
> > } else
> > return __memset(s, __c, count);
> > }
> >
> > But that was never quite implemented like this as you noticed.
>
> Well I'm not sure we really need this. bzero() is not part of the
> Linux string API, so it can only be used by MIPS specific code. And
> with the current implementation of bzero(), $a1 needs to be setup to 0
> anyway. That's why I simply killed it...
>
> BTW, can memset() be an inlined function ?
It can be anything, macro, inline or outline function. In the kernel
there are fewer restrictions than for a standards compliant library in
userspace.
You may take the i386 implementation in include/asm-x86/string_32.h as
an extreme example.
Older gcc used to generate significantly worse code for inline functions
than for macros so Linux became a fairly excessive user of macros. This
has very much improved since, so these days inlines are prefered over
macros where possible.
> Yes I noticed this. Actually I'm wondering if we couldn't add a new
> function, fill_user() like the following:
>
> extern size_t fill_user(void __user *to, int c, size_t len);
That's much better function name than the old __bzero - except that
__bzero effectivly took a long argument for the 2nd argument so 32-bit
on 32-bit kernels and 64-bit on 64-bit kernels.
> This could be used by both memset() and clear_user():
>
> #define memset(s,c,l) ({ (void)fill(s,c,l); s; })
> #define clear_user(t,l) fill_user(t,0,l)
>
> Therefore the definition of clear_user() could be saner.
Looks alot nicer that way though an inline is probably preferable as
expressed above.
Ralf
^ permalink raw reply
* Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: Ralf Baechle @ 2007-11-05 23:30 UTC (permalink / raw)
To: Franck Bui-Huu
Cc: Thiemo Seufer, Nigel Stephens, Maciej W. Rozycki, linux-mips
In-Reply-To: <472F8C82.4080406@gmail.com>
On Mon, Nov 05, 2007 at 10:34:58PM +0100, Franck Bui-Huu wrote:
> It's actually hard to know the advantages of using SDE over a stock gcc.
> The only difference I'm aware of is the smartmips ASE support in SDE.
> But since this support is going to be added in stock gccs, I don't see
> any advantages now and I'm wondering if I can give up using SDE...
In general terms the toolchain has been more reliable and had better
support for MIPS processors before FSF gcc.
Ralf
^ permalink raw reply
* Re: [PATCH] mm/pg-r4k.c: Dump the generated code
From: Franck Bui-Huu @ 2007-11-06 7:23 UTC (permalink / raw)
To: Ralf Baechle; +Cc: Thiemo Seufer, Nigel Stephens, Maciej W. Rozycki, linux-mips
In-Reply-To: <20071105233025.GB12514@linux-mips.org>
Ralf Baechle wrote:
> On Mon, Nov 05, 2007 at 10:34:58PM +0100, Franck Bui-Huu wrote:
>
>> It's actually hard to know the advantages of using SDE over a stock gcc.
>> The only difference I'm aware of is the smartmips ASE support in SDE.
>> But since this support is going to be added in stock gccs, I don't see
>> any advantages now and I'm wondering if I can give up using SDE...
>
> In general terms the toolchain has been more reliable and had better
> support for MIPS processors before FSF gcc.
>
Good point.
Franck
^ permalink raw reply
* Re: [PATCH] Kill __bzero()
From: Franck Bui-Huu @ 2007-11-06 7:42 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071105231818.GA18820@linux-mips.org>
Ralf Baechle wrote:
> On Mon, Nov 05, 2007 at 10:51:43PM +0100, Franck Bui-Huu wrote:
>
>>> Memset is almost always only ever invoked with a zero argument. So the
>>> idea was to have something like this:
>>>
>>> extern void *__memset(void *__s, int __c, size_t __count);
>>> extern void *bzero(void *__s, size_t __count);
>>>
>>> static inline void *memset(void *s, int c, size_t count)
>>> {
>>> if (__builtin_constant_p(c) && c == 0) {
>>> bzero(s, count);
>>> return s;
>>> } else
>>> return __memset(s, __c, count);
>>> }
>>>
>>> But that was never quite implemented like this as you noticed.
>> Well I'm not sure we really need this. bzero() is not part of the
>> Linux string API, so it can only be used by MIPS specific code. And
>> with the current implementation of bzero(), $a1 needs to be setup to 0
>> anyway. That's why I simply killed it...
>>
>> BTW, can memset() be an inlined function ?
>
> It can be anything, macro, inline or outline function. In the kernel
> there are fewer restrictions than for a standards compliant library in
> userspace.
>
> You may take the i386 implementation in include/asm-x86/string_32.h as
> an extreme example.
>
> Older gcc used to generate significantly worse code for inline functions
> than for macros so Linux became a fairly excessive user of macros. This
> has very much improved since, so these days inlines are prefered over
> macros where possible.
Yes but ISTR that gcc generates some calls to memset and since
builtin functions are disabled the final link failed if memset
is inlined. I'll try to reproduce...
>
>> Yes I noticed this. Actually I'm wondering if we couldn't add a new
>> function, fill_user() like the following:
>>
>> extern size_t fill_user(void __user *to, int c, size_t len);
>
> That's much better function name than the old __bzero - except that
Actually I named it '__fill_user', since it doesn't call access_ok().
> __bzero effectivly took a long argument for the 2nd argument so 32-bit
> on 32-bit kernels and 64-bit on 64-bit kernels.
Isn't size_t meaning ?
Perhaps in this case __kernel_size_t is better...
>
>> This could be used by both memset() and clear_user():
>>
>> #define memset(s,c,l) ({ (void)fill(s,c,l); s; })
>> #define clear_user(t,l) fill_user(t,0,l)
>>
>> Therefore the definition of clear_user() could be saner.
>
> Looks alot nicer that way though an inline is probably preferable as
> expressed above.
>
Yes I have a patchset which clean up a bit uaccess.h and does this but
it's under construction. It actually tries to convert all macros into
inlines and the file is much more readable and as a bonus side we could
easily add __must_check annotations which are currently missing.
I'll try to finish it this week but in the meantime can we just kill
__bzero or do you want me to include it in the future patchset ?
Franck
^ permalink raw reply
* Re: [PATCH] Kill __bzero()
From: Ralf Baechle @ 2007-11-06 10:36 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: linux-mips
In-Reply-To: <47301AF8.2000700@gmail.com>
On Tue, Nov 06, 2007 at 08:42:48AM +0100, Franck Bui-Huu wrote:
> > Older gcc used to generate significantly worse code for inline functions
> > than for macros so Linux became a fairly excessive user of macros. This
> > has very much improved since, so these days inlines are prefered over
> > macros where possible.
>
> Yes but ISTR that gcc generates some calls to memset and since
> builtin functions are disabled the final link failed if memset
> is inlined. I'll try to reproduce...
So both belt and suspenders then that is an inline/macro plus an outline
version?
> >> Yes I noticed this. Actually I'm wondering if we couldn't add a new
> >> function, fill_user() like the following:
> >>
> >> extern size_t fill_user(void __user *to, int c, size_t len);
> >
> > That's much better function name than the old __bzero - except that
>
> Actually I named it '__fill_user', since it doesn't call access_ok().
>
> > __bzero effectivly took a long argument for the 2nd argument so 32-bit
> > on 32-bit kernels and 64-bit on 64-bit kernels.
>
> Isn't size_t meaning ?
>
> Perhaps in this case __kernel_size_t is better...
I wrote about the existing __bzero which takes the size_t length as third
argument and a long sized fill pattern as the second.
> Yes I have a patchset which clean up a bit uaccess.h and does this but
> it's under construction. It actually tries to convert all macros into
> inlines and the file is much more readable and as a bonus side we could
> easily add __must_check annotations which are currently missing.
>
> I'll try to finish it this week but in the meantime can we just kill
> __bzero or do you want me to include it in the future patchset ?
There is enough time until 2.6.25 to complete your cleanups; no more
cleanups for 2.6.24.
Ralf
^ permalink raw reply
* Re: [PATCH 1/4] tlbex.c: Cleanup __init usages.
From: Ralf Baechle @ 2007-11-06 13:47 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: anemo, ths, linux-mips
In-Reply-To: <1192691477-4675-2-git-send-email-fbuihuu@gmail.com>
On Thu, Oct 18, 2007 at 09:11:14AM +0200, Franck Bui-Huu wrote:
Queued for 2.6.25.
Thanks,
Ralf
^ permalink raw reply
* Re: [PATCH 2/4] tlbex.c: cleanup include files
From: Ralf Baechle @ 2007-11-06 14:03 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: anemo, ths, linux-mips
In-Reply-To: <1192691477-4675-3-git-send-email-fbuihuu@gmail.com>
On Thu, Oct 18, 2007 at 09:11:15AM +0200, Franck Bui-Huu wrote:
> Date: Thu, 18 Oct 2007 09:11:15 +0200
> To: ralf@linux-mips.org
> Cc: anemo@mba.ocn.ne.jp, ths@networkno.de, linux-mips@linux-mips.org
> Subject: [PATCH 2/4] tlbex.c: cleanup include files
Queued for 2.6.25.
Thanks,
Ralf
^ permalink raw reply
* Re: [PATCH 3/4] tlbex.c: use __cacheline_aligned instead of __tlb_handler_align attribute
From: Ralf Baechle @ 2007-11-06 14:03 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: anemo, ths, linux-mips
In-Reply-To: <1192691477-4675-4-git-send-email-fbuihuu@gmail.com>
On Thu, Oct 18, 2007 at 09:11:16AM +0200, Franck Bui-Huu wrote:
> To: ralf@linux-mips.org
> Cc: anemo@mba.ocn.ne.jp, ths@networkno.de, linux-mips@linux-mips.org
> Subject: [PATCH 3/4] tlbex.c: use __cacheline_aligned instead of
> __tlb_handler_align attribute
Queued for 2.6.25.
Thanks alot,
Ralf
^ permalink raw reply
* Re: [PATCH 4/4] tlbex.c: cleanup debug code
From: Ralf Baechle @ 2007-11-06 14:31 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: anemo, ths, linux-mips
In-Reply-To: <1192691477-4675-5-git-send-email-fbuihuu@gmail.com>
On Thu, Oct 18, 2007 at 09:11:17AM +0200, Franck Bui-Huu wrote:
And this one also queued for 2.6.25.
Thanks again,
Ralf
^ permalink raw reply
* Re: WAIT vs. tickless kernel
From: Atsushi Nemoto @ 2007-11-06 15:39 UTC (permalink / raw)
To: ralf; +Cc: linux-mips
In-Reply-To: <20071103.014649.122254137.anemo@mba.ocn.ne.jp>
On Sat, 03 Nov 2007 01:46:49 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> > The tickless kernel is very interesting for the low power fraction. And
> > it's especially those users who would suffer most the loss of the ability
> > to use the WAIT instruction. For a system running from two AAA cells the
> > tradeoff is clear ... So I think it's become a must.
>
> Then, something like this? Selecting in build-time is not so good,
> but there are some CPUs which do not need this hack at all.
> Synthesizing the ret_from_irq() at runtime might satisfy everyone?
Revised.
As Ralf said on IRC, the adjustment can be done at beginning of
handler, instead of ret_from_irq. So we can enable this hack at
runtime. I introduced BUILD_ROLLBACK_PROLOGUE macro to build prologue
code for handle_int and except_vec_vi. I'm not sure except_vec4 needs
the prologue or not.
And if the EPC was just after WAIT (i.e. normal wakeup from WAIT) the
rollback is not needed. So I arranged r4k_wait so that the rollback
region exactly fit to 32 byte.
How about this?
------------------------------------------------------------------------
Subject: Fix potential latency problem due to non-atomic cpu_wait.
If an interrupt happened between checking of NEED_RESCHED and WAIT
instruction, adjust EPC to restart from checking of NEED_RESCHED.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
---
arch/mips/kernel/cpu-probe.c | 16 ++--------------
arch/mips/kernel/genex.S | 38 ++++++++++++++++++++++++++++++++++++++
arch/mips/kernel/traps.c | 22 ++++++++++++++++------
3 files changed, 56 insertions(+), 20 deletions(-)
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index c8c47a2..c745b91 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -45,18 +45,7 @@ static void r39xx_wait(void)
local_irq_enable();
}
-/*
- * There is a race when WAIT instruction executed with interrupt
- * enabled.
- * But it is implementation-dependent wheter the pipelie restarts when
- * a non-enabled interrupt is requested.
- */
-static void r4k_wait(void)
-{
- __asm__(" .set mips3 \n"
- " wait \n"
- " .set mips0 \n");
-}
+extern void r4k_wait(void);
/*
* This variant is preferable as it allows testing need_resched and going to
@@ -128,7 +117,7 @@ static int __init wait_disable(char *s)
__setup("nowait", wait_disable);
-static inline void check_wait(void)
+void __init check_wait(void)
{
struct cpuinfo_mips *c = ¤t_cpu_data;
@@ -239,7 +228,6 @@ static inline void check_errata(void)
void __init check_bugs32(void)
{
- check_wait();
check_errata();
}
diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S
index c0f19d6..bb72c3a 100644
--- a/arch/mips/kernel/genex.S
+++ b/arch/mips/kernel/genex.S
@@ -20,6 +20,7 @@
#include <asm/stackframe.h>
#include <asm/war.h>
#include <asm/page.h>
+#include <asm/thread_info.h>
#define PANIC_PIC(msg) \
.set push; \
@@ -126,7 +127,43 @@ handle_vcei:
__FINIT
+ .align 5 /* 32 byte rollback region */
+LEAF(r4k_wait)
+ .set push
+ .set noreorder
+ /* start of rollback region */
+ LONG_L t0, TI_FLAGS($28)
+ nop
+ andi t0, _TIF_NEED_RESCHED
+ bnez t0, 1f
+ nop
+ nop
+ nop
+ .set mips3
+ wait
+ .set mips0
+ /* end of rollback region (the region size must be power of two) */
+ .set pop
+1:
+ jr ra
+ END(r4k_wait)
+
+ .macro BUILD_ROLLBACK_PROLOGUE handler
+ FEXPORT(rollback_\handler)
+ .set push
+ .set noat
+ MFC0 k0, CP0_EPC
+ ori k0, 0x1f /* 32 byte rollback region */
+ xori k0, 0x1f
+ PTR_LA k1, r4k_wait
+ bne k0, k1, 9f
+ MTC0 k0, CP0_EPC
+9:
+ .set pop
+ .endm
+
.align 5
+BUILD_ROLLBACK_PROLOGUE handle_int
NESTED(handle_int, PT_SIZE, sp)
#ifdef CONFIG_TRACE_IRQFLAGS
/*
@@ -201,6 +238,7 @@ NESTED(except_vec_ejtag_debug, 0, sp)
* This prototype is copied to ebase + n*IntCtl.VS and patched
* to invoke the handler
*/
+BUILD_ROLLBACK_PROLOGUE except_vec_vi
NESTED(except_vec_vi, 0, sp)
SAVE_SOME
SAVE_AT
diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
index fa50078..0b2cc58 100644
--- a/arch/mips/kernel/traps.c
+++ b/arch/mips/kernel/traps.c
@@ -43,6 +43,9 @@
#include <asm/types.h>
#include <asm/stacktrace.h>
+extern void check_wait(void);
+extern asmlinkage void r4k_wait(void);
+extern asmlinkage void rollback_handle_int(void);
extern asmlinkage void handle_int(void);
extern asmlinkage void handle_tlbm(void);
extern asmlinkage void handle_tlbl(void);
@@ -1198,6 +1201,9 @@ static void *set_vi_srs_handler(int n, vi_handler_t addr, int srs)
extern char except_vec_vi, except_vec_vi_lui;
extern char except_vec_vi_ori, except_vec_vi_end;
+ extern char rollback_except_vec_vi;
+ char *vec_start = (cpu_wait == r4k_wait) ?
+ &rollback_except_vec_vi : &except_vec_vi;
#ifdef CONFIG_MIPS_MT_SMTC
/*
* We need to provide the SMTC vectored interrupt handler
@@ -1205,11 +1211,11 @@ static void *set_vi_srs_handler(int n, vi_handler_t addr, int srs)
* Status.IM bit to be masked before going there.
*/
extern char except_vec_vi_mori;
- const int mori_offset = &except_vec_vi_mori - &except_vec_vi;
+ const int mori_offset = &except_vec_vi_mori - vec_start;
#endif /* CONFIG_MIPS_MT_SMTC */
- const int handler_len = &except_vec_vi_end - &except_vec_vi;
- const int lui_offset = &except_vec_vi_lui - &except_vec_vi;
- const int ori_offset = &except_vec_vi_ori - &except_vec_vi;
+ const int handler_len = &except_vec_vi_end - vec_start;
+ const int lui_offset = &except_vec_vi_lui - vec_start;
+ const int ori_offset = &except_vec_vi_ori - vec_start;
if (handler_len > VECTORSPACING) {
/*
@@ -1219,7 +1225,7 @@ static void *set_vi_srs_handler(int n, vi_handler_t addr, int srs)
panic("VECTORSPACING too small");
}
- memcpy(b, &except_vec_vi, handler_len);
+ memcpy(b, vec_start, handler_len);
#ifdef CONFIG_MIPS_MT_SMTC
BUG_ON(n > 7); /* Vector index %d exceeds SMTC maximum. */
@@ -1497,6 +1503,10 @@ void __init trap_init(void)
extern char except_vec3_generic, except_vec3_r4000;
extern char except_vec4;
unsigned long i;
+ int rollback;
+
+ check_wait();
+ rollback = (cpu_wait == r4k_wait);
if (cpu_has_veic || cpu_has_vint)
ebase = (unsigned long) alloc_bootmem_low_pages(0x200 + VECTORSPACING*64);
@@ -1558,7 +1568,7 @@ void __init trap_init(void)
if (board_be_init)
board_be_init();
- set_except_vector(0, handle_int);
+ set_except_vector(0, rollback ? rollback_handle_int : handle_int);
set_except_vector(1, handle_tlbm);
set_except_vector(2, handle_tlbl);
set_except_vector(3, handle_tlbs);
^ permalink raw reply related
* Re: WAIT vs. tickless kernel
From: David Daney @ 2007-11-06 15:58 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: ralf, linux-mips
In-Reply-To: <20071107.003925.74752709.anemo@mba.ocn.ne.jp>
Atsushi Nemoto wrote:
> +LEAF(r4k_wait)
> + .set push
> + .set noreorder
> + /* start of rollback region */
> + LONG_L t0, TI_FLAGS($28)
> + nop
> + andi t0, _TIF_NEED_RESCHED
> + bnez t0, 1f
> + nop
> + nop
> + nop
> + .set mips3
> + wait
> + .set mips0
> + /* end of rollback region (the region size must be power of two) */
> + .set pop
>
The .set mips0 is redundant as .set pop immediately follows.
David Daney
^ permalink raw reply
* Re: WAIT vs. tickless kernel
From: Atsushi Nemoto @ 2007-11-06 16:02 UTC (permalink / raw)
To: ddaney; +Cc: ralf, linux-mips
In-Reply-To: <47308F36.2070200@avtrex.com>
On Tue, 06 Nov 2007 07:58:46 -0800, David Daney <ddaney@avtrex.com> wrote:
> > + .set mips0
> > + /* end of rollback region (the region size must be power of two) */
> > + .set pop
> >
>
> The .set mips0 is redundant as .set pop immediately follows.
Oh yes. I'll drop it on next revision. Thanks.
---
Atsushi Nemoto
^ permalink raw reply
* [PATCH] Fix typo in R3000 TRACE_IRQFLAGS code
From: Atsushi Nemoto @ 2007-11-06 16:08 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
---
diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S
index c0f19d6..e76a76b 100644
--- a/arch/mips/kernel/genex.S
+++ b/arch/mips/kernel/genex.S
@@ -146,7 +146,7 @@ NESTED(handle_int, PT_SIZE, sp)
and k0, ST0_IEP
bnez k0, 1f
- mfc0 k0, EP0_EPC
+ mfc0 k0, CP0_EPC
.set noreorder
j k0
rfe
^ permalink raw reply related
* Re: [PATCH] Kill __bzero()
From: Franck Bui-Huu @ 2007-11-06 16:18 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20071106103603.GA24844@linux-mips.org>
Ralf Baechle wrote:
> On Tue, Nov 06, 2007 at 08:42:48AM +0100, Franck Bui-Huu wrote:
>
>>> Older gcc used to generate significantly worse code for inline functions
>>> than for macros so Linux became a fairly excessive user of macros. This
>>> has very much improved since, so these days inlines are prefered over
>>> macros where possible.
>> Yes but ISTR that gcc generates some calls to memset and since
>> builtin functions are disabled the final link failed if memset
>> is inlined. I'll try to reproduce...
>
OK, using Cobalt config and the patch below, I get the following link
failure:
$ make
[snip]
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
kernel/built-in.o: In function `param_sysfs_init':
params.c:(.init.text+0x19ac): undefined reference to `memset'
params.c:(.init.text+0x19ac): relocation truncated to fit: R_MIPS_26 against `memset'
fs/built-in.o: In function `locks_remove_flock':
(.text+0x14518): undefined reference to `memset'
fs/built-in.o: In function `locks_remove_flock':
(.text+0x14518): relocation truncated to fit: R_MIPS_26 against `memset'
fs/built-in.o: In function `__blkdev_get':
block_dev.c:(.text+0x31d40): undefined reference to `memset'
block_dev.c:(.text+0x31d40): relocation truncated to fit: R_MIPS_26 against `memset'
block_dev.c:(.text+0x31d50): undefined reference to `memset'
block_dev.c:(.text+0x31d50): relocation truncated to fit: R_MIPS_26 against `memset'
make: *** [.tmp_vmlinux1] Error 1
> So both belt and suspenders then that is an inline/macro plus an outline
> version?
>
I guess so.
>>>> Yes I noticed this. Actually I'm wondering if we couldn't add a new
>>>> function, fill_user() like the following:
>>>>
>>>> extern size_t fill_user(void __user *to, int c, size_t len);
>>> That's much better function name than the old __bzero - except that
>> Actually I named it '__fill_user', since it doesn't call access_ok().
>>
>>> __bzero effectivly took a long argument for the 2nd argument so 32-bit
>>> on 32-bit kernels and 64-bit on 64-bit kernels.
>> Isn't size_t meaning ?
>>
>> Perhaps in this case __kernel_size_t is better...
>
> I wrote about the existing __bzero which takes the size_t length as third
> argument and a long sized fill pattern as the second.
>
Sorry I was confused (again) because of the invisible second parameter
of __bzero...
>> Yes I have a patchset which clean up a bit uaccess.h and does this but
>> it's under construction. It actually tries to convert all macros into
>> inlines and the file is much more readable and as a bonus side we could
>> easily add __must_check annotations which are currently missing.
>>
>> I'll try to finish it this week but in the meantime can we just kill
>> __bzero or do you want me to include it in the future patchset ?
>
> There is enough time until 2.6.25 to complete your cleanups; no more
> cleanups for 2.6.24.
>
Sure.
Franck
-- 8< --
diff --git a/arch/mips/lib/memset.S b/arch/mips/lib/memset.S
index 3f8b8b3..23f0490 100644
--- a/arch/mips/lib/memset.S
+++ b/arch/mips/lib/memset.S
@@ -54,7 +54,7 @@
*/
.set noreorder
.align 5
-LEAF(memset)
+LEAF(__memset)
beqz a1, 1f
move v0, a0 /* result */
diff --git a/include/asm-mips/string.h b/include/asm-mips/string.h
index 436e3ad..b2ef64c 100644
--- a/include/asm-mips/string.h
+++ b/include/asm-mips/string.h
@@ -132,7 +132,12 @@ strncmp(__const__ char *__cs, __const__ char *__ct, size_t __count)
#endif /* CONFIG_32BIT */
#define __HAVE_ARCH_MEMSET
-extern void *memset(void *__s, int __c, size_t __count);
+static inline void *memset(void *__s, int __c, size_t __count)
+{
+ extern void *__memset(void *s, int c, size_t len);
+
+ return __memset(__s, __c, __count);
+}
#define __HAVE_ARCH_MEMCPY
extern void *memcpy(void *__to, __const__ void *__from, size_t __n);
^ permalink raw reply related
* RE: Deleting read-only environment variable on Sibyte board.
From: Manoj Ekbote @ 2007-11-06 20:18 UTC (permalink / raw)
To: Ralf Baechle, linux-mips
In-Reply-To: <20071105130259.GA31023@linux-mips.org>
Hi Ralf,
Can you try 'Unsetenv [NAME]'?
>-----Original Message-----
>From: linux-mips-bounce@linux-mips.org
>[mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Ralf Baechle
>Sent: Monday, November 05, 2007 5:03 AM
>To: linux-mips@linux-mips.org
>Subject: Deleting read-only environment variable on Sibyte board.
>
>I've got a read-only environment variable on my
>Sibyte/Broadcom Bigsur system. Annoyingly it's the network
>address. Any help on how to delete such an undeletable
>environment variable would be welcome.
>
>Thanks,
>
> Ralf
>
>
>
^ permalink raw reply
* Re: Deleting read-only environment variable on Sibyte board.
From: Ralf Baechle @ 2007-11-06 22:28 UTC (permalink / raw)
To: Manoj Ekbote; +Cc: linux-mips
In-Reply-To: <03235919BBDE634289BB6A0758A20B36025B77EE@NT-SJCA-0751.brcm.ad.broadcom.com>
On Tue, Nov 06, 2007 at 12:18:51PM -0800, Manoj Ekbote wrote:
> Hi Ralf,
>
> Can you try 'Unsetenv [NAME]'?
I'm getting an error message, something about the variable being read-only.
Thanks anyway,
Ralf
^ permalink raw reply
* cross-tool for mips target
From: Reeve Yang @ 2007-11-07 1:08 UTC (permalink / raw)
To: linux-mips
Hi there,
I'm trying to build cross tool chain for mips32 target from my pc
(i686) based on crosstoll-0.43. By running "sh demo-mips.sh" (I chose
eval `cat mips.dat gcc-3.4.5-glibc-2.3.5.dat` sh all.sh --notest), I
got following error from log file. Has anyone ever had similiar
experience and how did you fix it? Thanks!
- Reeve
## ----------- ##
## Core tests. ##
## ----------- ##
configure:1706: checking build system type
configure:1724: result: i686-pc-linux-gnu
configure:1732: checking host system type
configure:1746: result: mips642-unknown-linux-gnu
configure:1998: checking sysdep dirs
configure:2214: result: sysdeps/generic/elf sysdeps/generic
configure:2233: checking for a BSD-compatible install
configure:2288: result: /usr/bin/install -c
configure:2303: checking whether ln -s works
configure:2307: result: yes
configure:2323: checking for mips32-linux-gnu-gcc
configure:2349: result: gcc
configure:2631: checking for C compiler version
configure:2634: gcc --version </dev/null >&5
gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:2637: $? = 0
configure:2639: gcc -v </dev/null >&5
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/
usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable
-shared --enable-__cxa_atexit --with-system-zlib --enable-nls
--without-included-gettext --enable-clocale=
gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib
--enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-13)
configure:2642: $? = 0
configure:2644: gcc -V </dev/null >&5
gcc: `-V' option must have argument
configure:2647: $? = 1
configure:2651: checking for suffix of object files
configure:2672: gcc -c -mabi=n32 conftest.c >&5
cc1: error: invalid option `abi=n32'
configure:2675: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME "GNU C Library"
| #define PACKAGE_TARNAME "c-library"
| #define PACKAGE_VERSION "(see version.h)"
| #define PACKAGE_STRING "GNU C Library (see version.h)"
| #define PACKAGE_BUGREPORT "glibc"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2689: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
^ permalink raw reply
* Re: cross-tool for mips target
From: David Daney @ 2007-11-07 1:13 UTC (permalink / raw)
To: Reeve Yang; +Cc: linux-mips
In-Reply-To: <3b279e3f0711061708r12913a29o62e4bf99a2ee3664@mail.gmail.com>
Reeve Yang wrote:
> Hi there,
>
> I'm trying to build cross tool chain for mips32 target from my pc
> (i686) based on crosstoll-0.43. By running "sh demo-mips.sh" (I chose
> eval `cat mips.dat gcc-3.4.5-glibc-2.3.5.dat` sh all.sh --notest), I
> got following error from log file. Has anyone ever had similiar
> experience and how did you fix it? Thanks!
>
I would ask over on: crossgcc@sourceware.org
That is where crosstool is often discussed.
David Daney
^ permalink raw reply
* Re: [PATCH] Fix typo in R3000 TRACE_IRQFLAGS code
From: Ralf Baechle @ 2007-11-07 9:43 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: linux-mips
In-Reply-To: <20071107.010848.37531337.anemo@mba.ocn.ne.jp>
On Wed, Nov 07, 2007 at 01:08:48AM +0900, Atsushi Nemoto wrote:
> Subject: [PATCH] Fix typo in R3000 TRACE_IRQFLAGS code
I guess that's because the last R3000 is still busy compiling a 2.6.0
kernel ;-)
Applied,
Ralf
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox