Re: CVS commit: src/sys/arch/mips/mips

2023-10-25 Thread Andrius V
Thank you, I should pay attention to that.

On Wed, Oct 25, 2023 at 9:02 AM Nick Hudson  wrote:
>
> Module Name:src
> Committed By:   skrll
> Date:   Wed Oct 25 06:02:14 UTC 2023
>
> Modified Files:
> src/sys/arch/mips/mips: kgdb_machdep.c
>
> Log Message:
>  -> 
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.21 -r1.22 src/sys/arch/mips/mips/kgdb_machdep.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>


Re: CVS commit: src/sys/arch/mips/mips

2020-06-09 Thread Simon Burge
Simon Burge wrote:

> > > Module Name:  src
> > > Committed By: simonb
> > > Date: Tue Jun  9 06:18:01 UTC 2020
> > > 
> > > Modified Files:
> > >   src/sys/arch/mips/mips: mips_machdep.c
> > > 
> > > Log Message:
> > > If we are on a SiByte or Cavium CPU with an FPU, report as "built-in FPU"
> > > instead of saying it's an unknown FPU type.
> > > 
> > > XXX - add any other CPUs to this list?
> >
> > This seems to cause build errors for non mipsNN:
>
> Oops, will fix.  Thanks for reporting.

Fixed, thanks!

Cheers,
Simon.


Re: CVS commit: src/sys/arch/mips/mips

2020-06-09 Thread Simon Burge
Izumi Tsutsui wrote:

> > Module Name:src
> > Committed By:   simonb
> > Date:   Tue Jun  9 06:18:01 UTC 2020
> > 
> > Modified Files:
> > src/sys/arch/mips/mips: mips_machdep.c
> > 
> > Log Message:
> > If we are on a SiByte or Cavium CPU with an FPU, report as "built-in FPU"
> > instead of saying it's an unknown FPU type.
> > 
> > XXX - add any other CPUs to this list?
>
> This seems to cause build errors for non mipsNN:

Oops, will fix.  Thanks for reporting.

Cheers,
Simon.


Re: CVS commit: src/sys/arch/mips/mips

2020-06-09 Thread Izumi Tsutsui
> Module Name:  src
> Committed By: simonb
> Date: Tue Jun  9 06:18:01 UTC 2020
> 
> Modified Files:
>   src/sys/arch/mips/mips: mips_machdep.c
> 
> Log Message:
> If we are on a SiByte or Cavium CPU with an FPU, report as "built-in FPU"
> instead of saying it's an unknown FPU type.
> 
> XXX - add any other CPUs to this list?

This seems to cause build errors for non mipsNN:

---
#   compile  RAMDISK/mips_machdep.o
/s/cvs/src/obj.ews4800mips/tooldir.NetBSD-9.0-i386/bin/mipseb--netbsd-gcc -G 0 
-mno-abicalls -msoft-float -ffixed-24 -ffreestanding 
-fno-zero-initialized-in-bss -fno-delete-null-pointer-checks -Os -mmemcpy 
-fno-strict-aliasing -fno-common -std=gnu99 -Werror -Wall -Wno-main 
-Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes 
-Wstrict-prototypes -Wold-style-definition -Wswitch -Wshadow -Wcast-qual 
-Wwrite-strings -Wno-unreachable-code -Wno-pointer-sign -Wno-attributes 
-Wno-sign-compare -march=r4400 -mabi=32 
--sysroot=/s/cvs/src/obj.ews4800mips/destdir.ews4800mips -Dews4800mips -I. 
-I/s/cvs/src/sys/external/bsd/libnv/dist 
-I/s/cvs/src/sys/../common/lib/libx86emu 
-I/s/cvs/src/sys/../common/lib/libc/misc -I/s/cvs/src/sys/../common/include 
-I/s/cvs/src/sys/arch -I/s/cvs/src/sys -nostdinc -DCOMPAT_UTILS -DMIPS3 
-DMIPS3_ENABLE_CLOCK_INTR -DCOMPAT_44 -D_KERNEL -D_KERNEL_OPT -std=gnu99 
-I/s/cvs/src/sys/lib/libkern/../../../common/lib/libc/quad 
-I/s/cvs/src/sys/lib/libkern/../!
 ../../common/lib/libc/string 
-I/s/cvs/src/sys/lib/libkern/../../../common/lib/libc/arch/mips/string 
-I/s/cvs/src/sys/lib/libkern/../../../common/lib/libc/hash/sha3 
-I/s/cvs/src/sys/external/bsd/libnv/dist -c 
/s/cvs/src/sys/arch/mips/mips/mips_machdep.c -o mips_machdep.o
/s/cvs/src/sys/arch/mips/mips/mips_machdep.c: In function 'cpu_identify':
/s/cvs/src/sys/arch/mips/mips/mips_machdep.c:1508:11: error: implicit 
declaration of function 'mipsNN_cp0_config1_read'; did you mean 
'mips3_cp0_config_read'? [-Werror=implicit-function-declaration]
cfg1 = mipsNN_cp0_config1_read();
   ^~~
   mips3_cp0_config_read
/s/cvs/src/sys/arch/mips/mips/mips_machdep.c:1509:15: error: 'MIPSNN_CFG1_FP' 
undeclared (first use in this function); did you mean 'MIPS_CR_IP'?
if (cfg1 & MIPSNN_CFG1_FP)
   ^~
   MIPS_CR_IP
/s/cvs/src/sys/arch/mips/mips/mips_machdep.c:1509:15: note: each undeclared 
identifier is reported only once for each function it appears in
cc1: all warnings being treated as errors

*** Failed target:  mips_machdep.o
*** Failed command: echo '# ' "compile RAMDISK/mips_machdep.o" && echo 
/s/cvs/src/obj.ews4800mips/tooldir.NetBSD-9.0-i386/bin/mipseb--netbsd-gcc -G 0 
-mno-abicalls -msoft-float -ffixed-24 -ffreestanding 
-fno-zero-initialized-in-bss -fno-delete-null-pointer-checks -Os -mmemcpy 
-fno-strict-aliasing -fno-common -std=gnu99 -Werror -Wall -Wno-main 
-Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes 
-Wstrict-prototypes -Wold-style-definition -Wswitch -Wshadow -Wcast-qual 
-Wwrite-strings -Wno-unreachable-code -Wno-pointer-sign -Wno-attributes 
-Wno-sign-compare -march=r4400 -mabi=32 
--sysroot=/s/cvs/src/obj.ews4800mips/destdir.ews4800mips -Dews4800mips -I. 
-I/s/cvs/src/sys/external/bsd/libnv/dist 
-I/s/cvs/src/sys/../common/lib/libx86emu 
-I/s/cvs/src/sys/../common/lib/libc/misc -I/s/cvs/src/sys/../common/include 
-I/s/cvs/src/sys/arch -I/s/cvs/src/sys -nostdinc -DCOMPAT_UTILS -DMIPS3 
-DMIPS3_ENABLE_CLOCK_INTR -DCOMPAT_44 -D_KERNEL -D_KERNEL_OPT -std=gnu99 
-I/s/cvs/src/sys/lib!
 /libkern/../../../common/lib/libc/quad 
-I/s/cvs/src/sys/lib/libkern/../../../common/lib/libc/string 
-I/s/cvs/src/sys/lib/libkern/../../../common/lib/libc/arch/mips/string 
-I/s/cvs/src/sys/lib/libkern/../../../common/lib/libc/hash/sha3 
-I/s/cvs/src/sys/external/bsd/libnv/dist -c 
/s/cvs/src/sys/arch/mips/mips/mips_machdep.c -o mips_machdep.o && 
/s/cvs/src/obj.ews4800mips/tooldir.NetBSD-9.0-i386/bin/mipseb--netbsd-gcc -G 0 
-mno-abicalls -msoft-float -ffixed-24 -ffreestanding 
-fno-zero-initialized-in-bss -fno-delete-null-pointer-checks -Os -mmemcpy 
-fno-strict-aliasing -fno-common -std=gnu99 -Werror -Wall -Wno-main 
-Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes 
-Wstrict-prototypes -Wold-style-definition -Wswitch -Wshadow -Wcast-qual 
-Wwrite-strings -Wno-unreachable-code -Wno-pointer-sign -Wno-attributes 
-Wno-sign-compare -march=r4400 -mabi=32 
--sysroot=/s/cvs/src/obj.ews4800mips/destdir.ews4800mips -Dews4800mips -I. 
-I/s/cvs/src/sys/external/bsd/libnv/dist -I/s/cv!
 s/src/sys/../common/lib/libx86emu -I/s/cvs/src/sys/../common/l!
 ib/libc/misc -I/s/cvs/src/sys/../common/include -I/s/cvs/src/sys/arch 
-I/s/cvs/src/sys -nostdinc -DCOMPAT_UTILS -DMIPS3 -DMIPS3_ENABLE_CLOCK_INTR 
-DCOMPAT_44 -D_KERNEL -D_KERNEL_OPT -std=gnu99 
-I/s/cvs/src/sys/lib/libkern/../../../common/lib/libc/quad 
-I/s/cvs/src/sys/lib/libkern/../../../common/lib/libc/string 

Re: CVS commit: src/sys/arch/mips/mips

2020-03-13 Thread Christos Zoulas

> On Mar 13, 2020, at 12:25 PM, Jason Thorpe  wrote:
> 
> 
>> On Mar 13, 2020, at 9:11 AM, Christos Zoulas  wrote:
>> 
>> I think this is better done in the driver, as other ports
>> do the same check and it catches bugs.
> 
> x86 *explcitly* checks for 0 to skip work.  If you want to find bugs, change 
> the most-often-used implementation maybe?
> 
> -- thorpej

I remembered wrong then.

christos



signature.asc
Description: Message signed with OpenPGP


Re: CVS commit: src/sys/arch/mips/mips

2020-03-13 Thread Jason Thorpe


> On Mar 13, 2020, at 9:11 AM, Christos Zoulas  wrote:
> 
> I think this is better done in the driver, as other ports
> do the same check and it catches bugs.

x86 *explcitly* checks for 0 to skip work.  If you want to find bugs, change 
the most-often-used implementation maybe?

-- thorpej



Re: CVS commit: src/sys/arch/mips/mips

2020-03-13 Thread Christos Zoulas
In article <20200313034939.553d5f...@cvs.netbsd.org>,
Jason R Thorpe  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  thorpej
>Date:  Fri Mar 13 03:49:39 UTC 2020
>
>Modified Files:
>   src/sys/arch/mips/mips: bus_dma.c
>
>Log Message:
>Allow len == 0 in bus_dmamap_sync().

I think this is better done in the driver, as other ports
do the same check and it catches bugs.

christos



Re: CVS commit: src/sys/arch/mips/mips

2020-03-13 Thread Nick Hudson

On 13/03/2020 03:49, Jason R Thorpe wrote:

Module Name:src
Committed By:   thorpej
Date:   Fri Mar 13 03:49:39 UTC 2020

Modified Files:
src/sys/arch/mips/mips: bus_dma.c

Log Message:
Allow len == 0 in bus_dmamap_sync().

XXX pullup-9


The assertion that len is not 0 in arm bus_dma.c has found several bugs
over the years.

Just saying.

Nick


Re: CVS commit: src/sys/arch/mips/mips

2018-09-07 Thread maya
On Fri, Sep 07, 2018 at 09:29:27PM +, Christos Zoulas wrote:
> In article <20180907211445.dbf47f...@cvs.netbsd.org>,
> Michael Lorenz  wrote:
> >-=-=-=-=-=-
> >
> >Module Name: src
> >Committed By:macallan
> >Date:Fri Sep  7 21:14:45 UTC 2018
> >
> >Modified Files:
> > src/sys/arch/mips/mips: locore.S
> >
> >Log Message:
> >re-enable 64bit addressing in n32 kernels
> >Now these work again, at least on my Indy.
> 
> Isn't there only one line different?
> 
> christos
> 

yeah, but I find it more readable this way, too.
sorry for the breakage btw.


Re: CVS commit: src/sys/arch/mips/mips

2018-09-07 Thread Christos Zoulas
In article <20180907211445.dbf47f...@cvs.netbsd.org>,
Michael Lorenz  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  macallan
>Date:  Fri Sep  7 21:14:45 UTC 2018
>
>Modified Files:
>   src/sys/arch/mips/mips: locore.S
>
>Log Message:
>re-enable 64bit addressing in n32 kernels
>Now these work again, at least on my Indy.

Isn't there only one line different?

christos



re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread matthew green
m...@netbsd.org writes:
> Can we use aprint_debug instead?

it's not an autoconf message, so, please don't use aprint*().


.mrg.

> On Wed, Aug 08, 2018 at 07:50:13AM +, Simon Burge wrote:
> > Module Name:src
> > Committed By:   simonb
> > Date:   Wed Aug  8 07:50:12 UTC 2018
> > 
> > Modified Files:
> > src/sys/arch/mips/mips: cpu_exec.c
> > 
> > Log Message:
> > Make change of ABI printf()s #ifdef DEBUG_EXEC.


Re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread maya
On Wed, Aug 08, 2018 at 10:22:33PM +1000, Simon Burge wrote:
> Martin Husemann wrote:
> 
> > On Wed, Aug 08, 2018 at 12:11:39PM +, m...@netbsd.org wrote:
> > > On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote:
> > > > On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote:
> > > > > Can we use aprint_debug instead?
> > > > 
> > > > It is not even usefull for general debugging IMHO.
> > > > 
> > > > Martin
> > > 
> > > I like the idea of removing the messages entirely. The code was hard to
> > > read when I had to do it, and I didn't find those messages helpful.
> >
> > I meant: I like the way Simon changed it - it will not show up unless
> > you are explicitly debugging exec stuff.
> 
> On top of what Martin said, there's a DEBUG_EXEC already in
> sys/kern/kern_exec.c .  Do these messages still serve a purpose
> now that the compat stuff is working?  I can't answer that!

I can, because I fixed the compat stuff.


Re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread Paul Goyette

On Wed, 8 Aug 2018, Martin Husemann wrote:


On Wed, Aug 08, 2018 at 12:11:39PM +, m...@netbsd.org wrote:

On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote:

On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote:

Can we use aprint_debug instead?


It is not even usefull for general debugging IMHO.

Martin


I like the idea of removing the messages entirely. The code was hard to
read when I had to do it, and I didn't find those messages helpful.


I meant: I like the way Simon changed it - it will not show up unless
you are explicitly debugging exec stuff.


Well, it could remain conditional, and in addition use aprint_debug() 
instead of printf().  So even if you've compiled it in, you don't see 
anything unless you also boot with debug (ie, boot -x).




+--+--++
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:  |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+--+--++


Re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread Simon Burge
Martin Husemann wrote:

> On Wed, Aug 08, 2018 at 12:11:39PM +, m...@netbsd.org wrote:
> > On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote:
> > > On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote:
> > > > Can we use aprint_debug instead?
> > > 
> > > It is not even usefull for general debugging IMHO.
> > > 
> > > Martin
> > 
> > I like the idea of removing the messages entirely. The code was hard to
> > read when I had to do it, and I didn't find those messages helpful.
>
> I meant: I like the way Simon changed it - it will not show up unless
> you are explicitly debugging exec stuff.

On top of what Martin said, there's a DEBUG_EXEC already in
sys/kern/kern_exec.c .  Do these messages still serve a purpose
now that the compat stuff is working?  I can't answer that!

Cheers,
Simon.


Re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread Martin Husemann
On Wed, Aug 08, 2018 at 12:11:39PM +, m...@netbsd.org wrote:
> On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote:
> > On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote:
> > > Can we use aprint_debug instead?
> > 
> > It is not even usefull for general debugging IMHO.
> > 
> > Martin
> 
> I like the idea of removing the messages entirely. The code was hard to
> read when I had to do it, and I didn't find those messages helpful.

I meant: I like the way Simon changed it - it will not show up unless
you are explicitly debugging exec stuff.

Martin


Re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread maya
On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote:
> On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote:
> > Can we use aprint_debug instead?
> 
> It is not even usefull for general debugging IMHO.
> 
> Martin

I like the idea of removing the messages entirely. The code was hard to
read when I had to do it, and I didn't find those messages helpful.


Re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread Martin Husemann
On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote:
> Can we use aprint_debug instead?

It is not even usefull for general debugging IMHO.

Martin


Re: CVS commit: src/sys/arch/mips/mips

2018-08-08 Thread maya
Can we use aprint_debug instead?

On Wed, Aug 08, 2018 at 07:50:13AM +, Simon Burge wrote:
> Module Name:  src
> Committed By: simonb
> Date: Wed Aug  8 07:50:12 UTC 2018
> 
> Modified Files:
>   src/sys/arch/mips/mips: cpu_exec.c
> 
> Log Message:
> Make change of ABI printf()s #ifdef DEBUG_EXEC.
> 
> 
> To generate a diff of this commit:
> cvs rdiff -u -r1.65 -r1.66 src/sys/arch/mips/mips/cpu_exec.c
> 
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
> 

> Modified files:
> 
> Index: src/sys/arch/mips/mips/cpu_exec.c
> diff -u src/sys/arch/mips/mips/cpu_exec.c:1.65 
> src/sys/arch/mips/mips/cpu_exec.c:1.66
> --- src/sys/arch/mips/mips/cpu_exec.c:1.65Sun Oct 16 10:57:58 2016
> +++ src/sys/arch/mips/mips/cpu_exec.c Wed Aug  8 07:50:12 2018
> @@ -1,4 +1,4 @@
> -/*   $NetBSD: cpu_exec.c,v 1.65 2016/10/16 10:57:58 maxv Exp $   */
> +/*   $NetBSD: cpu_exec.c,v 1.66 2018/08/08 07:50:12 simonb Exp $ */
>  
>  /*
>   * Copyright (c) 1992, 1993
> @@ -35,7 +35,7 @@
>   */
>  
>  #include 
> -__KERNEL_RCSID(0, "$NetBSD: cpu_exec.c,v 1.65 2016/10/16 10:57:58 maxv Exp 
> $");
> +__KERNEL_RCSID(0, "$NetBSD: cpu_exec.c,v 1.66 2018/08/08 07:50:12 simonb Exp 
> $");
>  
>  #include "opt_compat_netbsd.h"
>  #include "opt_compat_ultrix.h"
> @@ -96,7 +96,9 @@ mips_netbsd_elf32_probe(struct lwp *l, s
>  {
>   struct proc * const p = l->l_proc;
>   const Elf32_Ehdr * const eh = eh0;
> +#ifdef DEBUG_EXEC
>   int old_abi = p->p_md.md_abi;
> +#endif /* DEBUG_EXEC */
>   const char *itp_suffix = NULL;
>  
>   /*
> @@ -138,8 +140,10 @@ mips_netbsd_elf32_probe(struct lwp *l, s
>   case EF_MIPS_ABI2:
>   itp_suffix = "n32";
>   p->p_md.md_abi = _MIPS_BSD_API_N32;
> +#ifdef DEBUG_EXEC
>   if (old_abi != p->p_md.md_abi)
>   printf("pid %d(%s): ABI set to N32 (e_flags=%#x)\n", 
> p->p_pid, p->p_comm, eh->e_flags);
> +#endif /* DEBUG_EXEC */
>   break;
>  #endif
>  #ifdef COMPAT_16
> @@ -150,9 +154,11 @@ mips_netbsd_elf32_probe(struct lwp *l, s
>   case EF_MIPS_ABI_O32:
>   itp_suffix = "o32";
>   p->p_md.md_abi = _MIPS_BSD_API_O32;
> +#ifdef DEBUG_EXEC
>   if (old_abi != p->p_md.md_abi)
>   printf("pid %d(%s): ABI set to O32 (e_flags=%#x)\n", 
> p->p_pid, p->p_comm, eh->e_flags);
>   break;
> +#endif /* DEBUG_EXEC */
>   default:
>   return ENOEXEC;
>   }
> @@ -208,7 +214,9 @@ mips_netbsd_elf64_probe(struct lwp *l, s
>  {
>   struct proc * const p = l->l_proc;
>   const Elf64_Ehdr * const eh = eh0;
> +#ifdef DEBUG_EXEC
>   int old_abi = p->p_md.md_abi;
> +#endif /* DEBUG_EXEC */
>   const char *itp_suffix = NULL;
>  
>   switch (eh->e_flags & EF_MIPS_ARCH) {
> @@ -247,14 +255,18 @@ mips_netbsd_elf64_probe(struct lwp *l, s
>   case 0:
>   itp_suffix = "64";
>   p->p_md.md_abi = _MIPS_BSD_API_N64;
> +#ifdef DEBUG_EXEC
>   if (old_abi != p->p_md.md_abi)
>   printf("pid %d(%s): ABI set to N64 (e_flags=%#x)\n", 
> p->p_pid, p->p_comm, eh->e_flags);
> +#endif /* DEBUG_EXEC */
>   break;
>   case EF_MIPS_ABI_O64:
>   itp_suffix = "o64";
>   p->p_md.md_abi = _MIPS_BSD_API_O64;
> +#ifdef DEBUG_EXEC
>   if (old_abi != p->p_md.md_abi)
>   printf("pid %d(%s): ABI set to O64 (e_flags=%#x)\n", 
> p->p_pid, p->p_comm, eh->e_flags);
> +#endif /* DEBUG_EXEC */
>   break;
>   default:
>   return ENOEXEC;
> 



Re: CVS commit: src/sys/arch/mips/mips

2017-08-20 Thread coypu
spoiler alert: we can dedup a lot more

> @@ -1288,10 +1295,7 @@ NESTED_NOPROFILE(MIPSX(user_reserved_ins
>   /*
>* Save a minimum of registers to see if this is rdhwr $3,$29
>*/
> -#ifdef MIPS3_LOONGSON2
> - li  k0, MIPS_DIAG_BTB_CLEAR | MIPS_DIAG_RAS_DISABLE
> - mtc0k0, MIPS_COP_0_DIAG
> -#endif
> + KERN_ENTRY_ERRATA
>   /* K1 already has CURLWP */
>   PTR_L   k0, L_PCB(k1)   # XXXuvm_lwp_getuarea
>   PTR_ADDU k0, USPACE - TF_SIZ - CALLFRAME_SIZ
> @@ -1353,10 +1357,7 @@ NESTED_NOPROFILE(MIPSX(user_gen_exceptio
>   /*
>* Save all the registers except the kernel temporaries onto the stack.
>*/
> -#ifdef MIPS3_LOONGSON2
> - li  k0, MIPS_DIAG_BTB_CLEAR | MIPS_DIAG_RAS_DISABLE
> - mtc0k0, MIPS_COP_0_DIAG
> -#endif
> + KERN_ENTRY_ERRATA
>   /* K1 already has CURLWP */
>   PTR_L   k0, L_PCB(k1)   # XXXuvm_lwp_getuarea
>   PTR_ADDU k0, USPACE - TF_SIZ - CALLFRAME_SIZ
> @@ -1468,10 +1469,7 @@ NESTED_NOPROFILE(MIPSX(user_intr), CALLF
>   * Save the relevant user registers onto the kernel stack.
>   * We don't need to save s0 - s8 because the compiler does it for us.
>   */
> -#ifdef MIPS3_LOONGSON2
> - li  k0, MIPS_DIAG_BTB_CLEAR | MIPS_DIAG_RAS_DISABLE
> - mtc0k0, MIPS_COP_0_DIAG
> -#endif
> + KERN_ENTRY_ERRATA
>   /* k1 contains curlwp */
>   PTR_L   k0, L_PCB(k1)   # XXXuvm_lwp_getuarea
>   PTR_ADDU k0, USPACE - TF_SIZ - CALLFRAME_SIZ
> @@ -1660,10 +1658,7 @@ NESTED_NOPROFILE(MIPSX(systemcall), CALL
>   /*
>* Save all the registers but kernel temporaries onto the stack.
>*/
> -#ifdef MIPS3_LOONGSON2
> - li  k0, MIPS_DIAG_BTB_CLEAR | MIPS_DIAG_RAS_DISABLE
> - mtc0k0, MIPS_COP_0_DIAG
> -#endif
> + KERN_ENTRY_ERRATA
>   /* k1 already contains cpulwp */
>   PTR_L   k0, L_PCB(k1)   # XXXuvm_lwp_getuarea
>   PTR_ADDU k0, USPACE - TF_SIZ - CALLFRAME_SIZ
> 



Re: CVS commit: src/sys/arch/mips/mips

2016-06-30 Thread Izumi Tsutsui
skrll@ wrote:

> > (i.e. reverting removed lines is not "fix" but workaround).
> 
> Not sure what you mean here, but as bad cache aliases can happen my 
> change is valid.

Well, I have been waitng proper description about the new UVM design
for VIPT cache systems (i.e. what's the "right" thing) for >5 years,
as mentioned in the PR...

If it doesn't work as expected, I think it would be better to remove
all useless COLORMATCH code.

---
Izumi Tsutsui


Re: CVS commit: src/sys/arch/mips/mips

2016-06-30 Thread Nick Hudson

On 06/30/16 15:59, Izumi Tsutsui wrote:

skrll@ wrote:


Module Name:src
Committed By:   skrll
Date:   Thu Jun 30 12:57:35 UTC 2016

Modified Files:
src/sys/arch/mips/mips: pmap.c

Log Message:
Fix MIPS3_NO_PV_UNCACHED alias handling by looping through the pv_list
looking for bad aliases and removing the bad entries.  That is, revert
to the code before the matt-mips64 merge.

  :

Fixes the following two PRs

  :

Hmm.

This means current implementation of UVM_KMF_COLORMATCH
and UVM_FLAG_COLORMATCH is completely broken


Probably :)


(i.e. reverting removed lines is not "fix" but workaround).


Not sure what you mean here, but as bad cache aliases can happen my 
change is valid.




See PR/45746

---
Izumi Tsutsui


Nick


Re: CVS commit: src/sys/arch/mips/mips

2016-06-27 Thread Nick Hudson

On 06/27/16 08:12, Nick Hudson wrote:

Module Name:src
Committed By:   skrll
Date:   Mon Jun 27 07:12:18 UTC 2016

Modified Files:
src/sys/arch/mips/mips: pmap.c

Log Message:
Fix a bug introduced by me in 1.214 where unmanaged mappings would be
affected by calls to pmap_page_protect which is wrong.  Now PV_KENTER
mappings are left intact.

Thanks to chuq for spotting my mistake and reviewing this diff.


mrg@ was a big help as well... hi phone!

Nick


Re: CVS commit: src/sys/arch/mips/mips

2014-05-07 Thread Izumi Tsutsui
skrll@ wrote:

 How about the attached?

If it's tested on the target CPUs using mips/bus_dma.c,
I have no objection.
(the orignal code was tested only on R4400/R5000/Rm5200)

---
Izumi Tsutsui


Re: CVS commit: src/sys/arch/mips/mips

2014-05-06 Thread Nick Hudson

On 05/02/14 15:39, Izumi Tsutsui wrote:

skrll@ wrote:

[snip]

- BUS_DMASYNC_PREREAD seems incomplete

I think it's complete, but not as well optimized as, for example, the
cobalt one.

Probably depends on the definition of complete.
(as a person who modified the cobalt one)


How about the attached?


---
Izumi Tsutsui


Index: sys/arch/mips/mips/bus_dma.c
===
RCS file: /cvsroot/src/sys/arch/mips/mips/bus_dma.c,v
retrieving revision 1.30
diff -u -p -r1.30 bus_dma.c
--- sys/arch/mips/mips/bus_dma.c5 Feb 2014 19:09:06 -   1.30
+++ sys/arch/mips/mips/bus_dma.c6 May 2014 07:28:13 -
@@ -856,13 +856,27 @@ _bus_dmamap_sync(bus_dma_tag_t t, bus_dm
mips_dcache_wbinv_range(vaddr, minlen);
break;
 
-   case BUS_DMASYNC_PREREAD:
-#if 1
-   mips_dcache_wbinv_range(vaddr, minlen);
-#else
-   mips_dcache_inv_range(vaddr, minlen);
-#endif
+   case BUS_DMASYNC_PREREAD: {
+   struct mips_cache_info * const mci = mips_cache_info;
+   vaddr_t start = vaddr;
+   vaddr_t end = vaddr + minlen;
+   vaddr_t preboundary, firstboundary, lastboundary;
+
+   preboundary = start  ~mci-mci_dcache_align_mask;
+   firstboundary = (start + mci-mci_dcache_align_mask)
+~mci-mci_dcache_align_mask;
+   lastboundary = end  ~mci-mci_dcache_align_mask;
+   if (preboundary  start  preboundary  lastboundary)
+   mips_dcache_wbinv_range(preboundary,
+   mci-mci_dcache_align);
+   if (firstboundary  lastboundary)
+   mips_dcache_inv_range(firstboundary,
+   lastboundary - firstboundary);
+   if (lastboundary  end)
+   mips_dcache_wbinv_range(lastboundary,
+   mci-mci_dcache_align);
break;
+   }
 
case BUS_DMASYNC_PREWRITE:
mips_dcache_wb_range(vaddr, minlen);


Re: CVS commit: src/sys/arch/mips/mips

2014-05-02 Thread Nick Hudson

On 04/30/14 17:35, Izumi Tsutsui wrote:

they should also switch to the common mips bus space/dma files.

- does it handle MIPS1?

don't know about this one.

- BUS_DMASYNC_PREREAD seems incomplete


I think it's complete, but not as well optimized as, for example, the 
cobalt one.




---
Izumi Tsutsui




Nick


Re: CVS commit: src/sys/arch/mips/mips

2014-05-02 Thread Izumi Tsutsui
 Should be simple for you to copy across the optimisation then :)

Sorry, I have no motivation for current mips ports.

---
Izumi Tsutsui


Re: CVS commit: src/sys/arch/mips/mips

2014-05-02 Thread Nick Hudson

On 05/02/14 15:39, Izumi Tsutsui wrote:

skrll@ wrote:


On 04/30/14 17:35, Izumi Tsutsui wrote:

they should also switch to the common mips bus space/dma files.

- does it handle MIPS1?

don't know about this one.

See pmax/bus_dma.c.


- BUS_DMASYNC_PREREAD seems incomplete

I think it's complete, but not as well optimized as, for example, the
cobalt one.

Probably depends on the definition of complete.
(as a person who modified the cobalt one)


Should be simple for you to copy across the optimisation then :)


---
Izumi Tsutsui



Nick


Re: CVS commit: src/sys/arch/mips/mips

2014-05-01 Thread Michael
Hello,

On Thu, 1 May 2014 01:14:37 +0900
Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:

 skrll@ wrote:
 
  I'm still seeing issues with my cobalt, but I'll keep hunting.
 
 Probably all mips port MD bus_dma.c
 (in arc, cobalt, emips, ews4800mips, hpcmips, mipsco, pmax, sgimips)
 need the similar fix as mips/bus_dma.c rev 1.28.
 (only algor, evbmips and sbmips use mips/bus_dma.c)

Hmm, the data corruption when piping stuff between processes seems to
be gone, but I still see occasional corruption when accessing files, so
bus_dma is definitely a reasonable suspect.
On Loongson ( which uses mips/bus_dma.c IIRC ) I see corruption only
when writing via nfs, on sgimips it's apparently any file access, but
it takes a lot longer to trigger.

have fun
Michael


Re: CVS commit: src/sys/arch/mips/mips

2014-04-30 Thread Michael
Hello,

On Wed, 23 Apr 2014 20:57:15 +
Nick Hudson sk...@netbsd.org wrote:

 Module Name:  src
 Committed By: skrll
 Date: Wed Apr 23 20:57:15 UTC 2014
 
 Modified Files:
   src/sys/arch/mips/mips: pmap.c vm_machdep.c
...
 Hopefully this addresses the instability reported in the following PRs:
 
 PR/44900 - R5000/Rm5200 mips ports are broken
 PR/46170 - NetBSD/cobalt 6.0_BETA does not boot
 PR/46890 - upcoming NetBSD 6.0 release is very unstable / unusable on cobalt 
 qube 2
 PR/48628 - cobalt and hpcmips ports are dead

I can no longer reproduce the data corruption issues I've seen on sgimips in 
the last few years.
Should we ever meet in real life, I owe you a beer or ten.

have fun
Michael


Re: CVS commit: src/sys/arch/mips/mips

2014-04-30 Thread Nick Hudson

On 04/30/14 11:01, Michael wrote:

Hello,

On Wed, 23 Apr 2014 20:57:15 +
Nick Hudsonsk...@netbsd.org  wrote:


Module Name:src
Committed By:   skrll
Date:   Wed Apr 23 20:57:15 UTC 2014

Modified Files:
src/sys/arch/mips/mips: pmap.c vm_machdep.c

...

Hopefully this addresses the instability reported in the following PRs:

PR/44900 - R5000/Rm5200 mips ports are broken
PR/46170 - NetBSD/cobalt 6.0_BETA does not boot
PR/46890 - upcoming NetBSD 6.0 release is very unstable / unusable on cobalt 
qube 2
PR/48628 - cobalt and hpcmips ports are dead

I can no longer reproduce the data corruption issues I've seen on sgimips in 
the last few years.


Can you post your dmesg | grep ^cpu

I'm still seeing issues with my cobalt, but I'll keep hunting.


Should we ever meet in real life, I owe you a beer or ten.


Great, I'll remember :)


have fun
Michael


Nick


Re: CVS commit: src/sys/arch/mips/mips

2014-04-30 Thread Izumi Tsutsui
skrll@ wrote:

 I'm still seeing issues with my cobalt, but I'll keep hunting.

Probably all mips port MD bus_dma.c
(in arc, cobalt, emips, ews4800mips, hpcmips, mipsco, pmax, sgimips)
need the similar fix as mips/bus_dma.c rev 1.28.
(only algor, evbmips and sbmips use mips/bus_dma.c)

---
Izumi Tsutsui


Re: CVS commit: src/sys/arch/mips/mips

2014-04-30 Thread Matt Thomas

On Apr 30, 2014, at 9:14 AM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote:

 skrll@ wrote:
 
 I'm still seeing issues with my cobalt, but I'll keep hunting.
 
 Probably all mips port MD bus_dma.c
 (in arc, cobalt, emips, ews4800mips, hpcmips, mipsco, pmax, sgimips)
 need the similar fix as mips/bus_dma.c rev 1.28.
 (only algor, evbmips and sbmips use mips/bus_dma.c)

they should also switch to the common mips bus space/dma files.


Re: CVS commit: src/sys/arch/mips/mips

2014-04-30 Thread Izumi Tsutsui
 they should also switch to the common mips bus space/dma files.

- does it handle MIPS1?
- BUS_DMASYNC_PREREAD seems incomplete

---
Izumi Tsutsui


Re: CVS commit: src/sys/arch/mips/mips

2014-04-30 Thread Michael
Hello,

On Wed, 30 Apr 2014 14:35:46 +0100
Nick Hudson sk...@netbsd.org wrote:

 On 04/30/14 11:01, Michael wrote:
  Hello,
 
  On Wed, 23 Apr 2014 20:57:15 +
  Nick Hudsonsk...@netbsd.org  wrote:
 
  Module Name:   src
  Committed By:  skrll
  Date:  Wed Apr 23 20:57:15 UTC 2014
 
  Modified Files:
 src/sys/arch/mips/mips: pmap.c vm_machdep.c
  ...
  Hopefully this addresses the instability reported in the following PRs:
 
  PR/44900 - R5000/Rm5200 mips ports are broken
  PR/46170 - NetBSD/cobalt 6.0_BETA does not boot
  PR/46890 - upcoming NetBSD 6.0 release is very unstable / unusable on 
  cobalt qube 2
  PR/48628 - cobalt and hpcmips ports are dead
  I can no longer reproduce the data corruption issues I've seen on sgimips 
  in the last few years.
 
 Can you post your dmesg | grep ^cpu
 
 I'm still seeing issues with my cobalt, but I'll keep hunting.

... and just after sending the previous mail the data corruption issues
popped up again. So they're not quite gone yet, just a whole lot less
frequent.

have fun
Michael


Re: CVS commit: src/sys/arch/mips/mips

2014-04-30 Thread Izumi Tsutsui
skrll@ wrote:

 yeah, they'll need that fix, but there are still cache aliasing bugs in 
 the pmap, I think.

PR/45746 is still open, btw.

---
Izumi Tsutsui


Re: CVS commit: src/sys/arch/mips/mips

2014-04-30 Thread Nick Hudson

On 04/30/14 17:14, Izumi Tsutsui wrote:

skrll@ wrote:


I'm still seeing issues with my cobalt, but I'll keep hunting.

Probably all mips port MD bus_dma.c
(in arc, cobalt, emips, ews4800mips, hpcmips, mipsco, pmax, sgimips)
need the similar fix as mips/bus_dma.c rev 1.28.
yeah, they'll need that fix, but there are still cache aliasing bugs in 
the pmap, I think.

(only algor, evbmips and sbmips use mips/bus_dma.c)

---
Izumi Tsutsui




Re: CVS commit: src/sys/arch/mips/mips

2011-11-13 Thread David Holland
On Sun, Nov 13, 2011 at 03:57:58PM +, Izumi Tsutsui wrote:
  Modified Files:
   src/sys/arch/mips/mips: locore.S
  
  Log Message:
  Read-modify-write instead of read-modify-read.  (not sure if this was fatal)

Probably not, but it's good to fix regardless...

-- 
David A. Holland
dholl...@netbsd.org


Re: CVS commit: src/sys/arch/mips/mips

2010-11-09 Thread Simon Burge
Antti Kantee wrote:

 On Tue Nov 09 2010 at 13:10:02 +1100, Simon Burge wrote:
  David Holland wrote:
  
   On Mon, Nov 08, 2010 at 06:09:39PM +, Antti Kantee wrote:
 Modified Files:
src/sys/arch/mips/mips: locore_mips1.S
 
 Log Message:
 In TLBRead, restore PID before doing the saves so that the caller's
 TLB entries are used instead of the PID given as the argument.
 
 from Alessandro Forin
   
   [ ... ]
   
   Do you have any further explanations or reports of symptoms? I don't
   see anything on any of the mips lists.
  
  I'm curious about this too.  That code hasn't changed for at least
  14 years...
 
 Given that it's only called from ddb, i'm not too surprised nobody has
 noticed.  Now, unless someone argues that the stores should definitely
 happen with the arbitrary PID set up by tlbr, let's flag the change as
 obvious, get on with something useful, and leave noppy philosophy to
 some other book club.

Thanks for the extra details.  It may be obvious with the background
info you've now provided, but wasn't from your initial commit message.

Cheers,
Simon.


Re: CVS commit: src/sys/arch/mips/mips

2010-11-09 Thread Antti Kantee
On Tue Nov 09 2010 at 22:43:53 +1100, Simon Burge wrote:
   I'm curious about this too.  That code hasn't changed for at least
   14 years...
  
  Given that it's only called from ddb, i'm not too surprised nobody has
  noticed.  Now, unless someone argues that the stores should definitely
  happen with the arbitrary PID set up by tlbr, let's flag the change as
  obvious, get on with something useful, and leave noppy philosophy to
  some other book club.
 
 Thanks for the extra details.  It may be obvious with the background
 info you've now provided, but wasn't from your initial commit message.

Gotta love source-changes-full and nxr.netbsd.org ;)


Re: CVS commit: src/sys/arch/mips/mips

2010-11-09 Thread Antti Kantee
On Tue Nov 09 2010 at 13:10:02 +1100, Simon Burge wrote:
 David Holland wrote:
 
  On Mon, Nov 08, 2010 at 06:09:39PM +, Antti Kantee wrote:
Modified Files:
 src/sys/arch/mips/mips: locore_mips1.S

Log Message:
In TLBRead, restore PID before doing the saves so that the caller's
TLB entries are used instead of the PID given as the argument.

from Alessandro Forin
  
  [ ... ]
  
  Do you have any further explanations or reports of symptoms? I don't
  see anything on any of the mips lists.
 
 I'm curious about this too.  That code hasn't changed for at least
 14 years...

Given that it's only called from ddb, i'm not too surprised nobody has
noticed.  Now, unless someone argues that the stores should definitely
happen with the arbitrary PID set up by tlbr, let's flag the change as
obvious, get on with something useful, and leave noppy philosophy to
some other book club.


Re: CVS commit: src/sys/arch/mips/mips

2010-11-09 Thread David Holland
On Tue, Nov 09, 2010 at 01:46:46PM +0200, Antti Kantee wrote:
   Thanks for the extra details.  It may be obvious with the background
   info you've now provided, but wasn't from your initial commit message.
  
  Gotta love source-changes-full and nxr.netbsd.org ;)

No, it's not obvious from those either, and I'm even familiar with the
architecture. This whole thing could have been avoided if you'd
written a clear commit message; can you revise the text in CVS to have
fewer dangling referents?

-- 
David A. Holland
dholl...@netbsd.org


Re: CVS commit: src/sys/arch/mips/mips

2010-11-09 Thread Warner Losh

 On 11/09/2010 13:54, David Holland wrote:

On Tue, Nov 09, 2010 at 01:46:46PM +0200, Antti Kantee wrote:
  Thanks for the extra details.  It may be obvious with the background
  info you've now provided, but wasn't from your initial commit message.
  
Gotta love source-changes-full and nxr.netbsd.org ;)

No, it's not obvious from those either, and I'm even familiar with the
architecture. This whole thing could have been avoided if you'd
written a clear commit message; can you revise the text in CVS to have
fewer dangling referents?
Or better yet, improve the comments so people looking at the code know 
what the considerations are?  Seems like an area where a sentence or two 
would save a lot of grief in the future...


Warner


Re: CVS commit: src/sys/arch/mips/mips

2010-11-09 Thread David Holland
On Mon, Nov 08, 2010 at 03:49:09PM -0700, Warner Losh wrote:
  I don't have a mips1-specific reference on hand, but my recollection
  is that you need *three* nops when messing with cop0 registers for all
  effects to flush through.
  locore_mips1.S doesn't agree with your recollection, e.g. mips1_TLBUpdate
  right above mips1_TLBRead.

What about it? It has some nops scattered in it, but they're neither
documented nor particularly systematic.

  mips1 had a 2 stage pipeline, so at most you'd need 1 nop.  3 nops
  is for the R4000's and similar.

I'm not sure about that. The only docs I still have do not describe
the 3-cycle wait for interrupt switching as r4000-specific, although
these docs do describe other pipeline hazards as r4000-specific. That
doesn't prove much for certain, but it's at least suggestive.

(I used to have the Hennessey  Patterson textbook that described the
original r2000 in gory detail, but I got rid of it because it was
outdated...)

Anyway, the exactly one nop that you do see in some mips1 contexts
(e.g. branch delays, and using values after fetching them) is the
offset between certain pipeline stages, not the total pipeline depth.

  Then it got weird with multi-issue, threads, and sometimes silicon
  bugs that required more before MIPS32r2 and MIPS64r2 codified a
  single, special kind of nop that did the trick.

You still need more than one of those in some cases, to the best of my
knowledge.

-- 
David A. Holland
dholl...@netbsd.org


Re: CVS commit: src/sys/arch/mips/mips

2010-11-09 Thread David Holland
On Tue, Nov 09, 2010 at 02:20:11PM -0700, Warner Losh wrote:
  No, it's not obvious from those either, and I'm even familiar with the
  architecture. This whole thing could have been avoided if you'd
  written a clear commit message; can you revise the text in CVS to have
  fewer dangling referents?
 
  Or better yet, improve the comments so people looking at the code
  know what the considerations are?  Seems like an area where a
  sentence or two would save a lot of grief in the future...

*slaps self*

done - anyone else who wants to put an oar in please edit accordingly.

-- 
David A. Holland
dholl...@netbsd.org


Re: CVS commit: src/sys/arch/mips/mips

2010-11-08 Thread David Holland
On Mon, Nov 08, 2010 at 06:09:39PM +, Antti Kantee wrote:
  Modified Files:
   src/sys/arch/mips/mips: locore_mips1.S
  
  Log Message:
  In TLBRead, restore PID before doing the saves so that the caller's
  TLB entries are used instead of the PID given as the argument.
  
  from Alessandro Forin

This doesn't make any sense.

As far as I can tell, the real problem is that the code is not
attending to pipeline hazards properly; moving things around until it
experimentally seems to work is just going to create other odd
behavior sometime down the line under different timing circumstances.

I don't have a mips1-specific reference on hand, but my recollection
is that you need *three* nops when messing with cop0 registers for all
effects to flush through.

Do you have any further explanations or reports of symptoms? I don't
see anything on any of the mips lists.

-- 
David A. Holland
dholl...@netbsd.org


Re: CVS commit: src/sys/arch/mips/mips

2010-11-08 Thread Antti Kantee
On Mon Nov 08 2010 at 21:40:49 +, David Holland wrote:
 On Mon, Nov 08, 2010 at 06:09:39PM +, Antti Kantee wrote:
   Modified Files:
  src/sys/arch/mips/mips: locore_mips1.S
   
   Log Message:
   In TLBRead, restore PID before doing the saves so that the caller's
   TLB entries are used instead of the PID given as the argument.
   
   from Alessandro Forin
 
 This doesn't make any sense.
 
 As far as I can tell, the real problem is that the code is not
 attending to pipeline hazards properly; moving things around until it
 experimentally seems to work is just going to create other odd
 behavior sometime down the line under different timing circumstances.
 
 I don't have a mips1-specific reference on hand, but my recollection
 is that you need *three* nops when messing with cop0 registers for all
 effects to flush through.

locore_mips1.S doesn't agree with your recollection, e.g. mips1_TLBUpdate
right above mips1_TLBRead.


Re: CVS commit: src/sys/arch/mips/mips

2010-11-08 Thread Simon Burge
David Holland wrote:

 On Mon, Nov 08, 2010 at 06:09:39PM +, Antti Kantee wrote:
   Modified Files:
  src/sys/arch/mips/mips: locore_mips1.S
   
   Log Message:
   In TLBRead, restore PID before doing the saves so that the caller's
   TLB entries are used instead of the PID given as the argument.
   
   from Alessandro Forin
 
 [ ... ]
 
 Do you have any further explanations or reports of symptoms? I don't
 see anything on any of the mips lists.

I'm curious about this too.  That code hasn't changed for at least
14 years...

Cheers,
Simon.


Re: CVS commit: src/sys/arch/mips/mips

2009-12-14 Thread Masao Uebayashi
This solves.  I'm not sure how to deal with other warning options.

Masao

Index: sys/modules/Makefile.inc
===
RCS file: /cvsroot/src/sys/modules/Makefile.inc,v
retrieving revision 1.1
diff -u -r1.1 Makefile.inc
--- sys/modules/Makefile.inc16 Jan 2008 12:34:56 -  1.1
+++ sys/modules/Makefile.inc14 Dec 2009 18:42:52 -
@@ -2,6 +2,7 @@
 
 S!=cd ${.CURDIR}/../..;pwd
 CPPFLAGS+= -I${NETBSDSRCDIR}/common/include
+COPTS+=-std=gnu99
 USE_FORT=  no
 WARNS?=1
 
-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635


Re: CVS commit: src/sys/arch/mips/mips

2009-12-14 Thread Matt Thomas

On Dec 14, 2009, at 10:44 AM, Masao Uebayashi wrote:

 This solves.  I'm not sure how to deal with other warning options.
 
 Masao

I suppose you should sync that with conf/Makefile.kern.inc

And now you can back out those changes to mips/compat*.c