Re: CVS commit: src/sys/arch/mips/mips
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
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
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
> 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
> 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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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