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 genera
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
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-i
> 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.
>
> 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, c
> 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
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
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
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:
> >
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 kernel
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 UT
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 wrot
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 usefu
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
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.
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 w
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
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 #if
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
> - mt
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) fo
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 b
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
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_p
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
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 att
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 complet
> Should be simple for you to copy across the optimisation then :)
Sorry, I have no motivation for current mips ports.
---
Izumi Tsutsui
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 optimiz
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 T
macallan@ wrote:
> 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.
I also wonder if sokvaalloc() (which is enabled by nfsd_use_loan and
depends on UVM_KMF_COLORMATCH) i
Hello,
On Thu, 1 May 2014 01:14:37 +0900
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_d
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
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
Hello,
On Wed, 30 Apr 2014 14:35:46 +0100
Nick Hudson wrote:
> On 04/30/14 11:01, Michael wrote:
> > Hello,
> >
> > On Wed, 23 Apr 2014 20:57:15 +
> > "Nick Hudson" wrote:
> >
> >> Module Name: src
> >> Committed By: skrll
> >> Date: Wed Apr 23 20:57:15 UTC 2014
> >>
> they should also switch to the common mips bus space/dma files.
- does it handle MIPS1?
- BUS_DMASYNC_PREREAD seems incomplete
---
Izumi Tsutsui
Hello,
On Wed, 30 Apr 2014 14:35:46 +0100
Nick Hudson wrote:
> On 04/30/14 11:01, Michael wrote:
> > On Wed, 23 Apr 2014 20:57:15 +
> > "Nick Hudson" wrote:
> >
> >> Module Name: src
> >> Committed By: skrll
> >> Date: Wed Apr 23 20:57:15 UTC 2014
> >>
> >> Modified
On Apr 30, 2014, at 9:14 AM, 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
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 T
On 04/30/14 11:01, Michael wrote:
Hello,
On Wed, 23 Apr 2014 20:57:15 +
"Nick Hudson" 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 insta
Hello,
On Wed, 23 Apr 2014 20:57:15 +
"Nick Hudson" 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
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
dhol
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 r
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,
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
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 fro
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 save
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 definit
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:
> > > >
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 giv
On 11/08/2010 15:19, Antti Kantee wrote:
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 do
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 en
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 Al
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
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/Makefil
On Dec 14, 2009, at 8:13 AM, Masao Uebayashi wrote:
>>> Log Message:
>>> We don't declare variables in for () statement.
>>
>> The kernel is a C99 environment which makes that legal. Limiting the scope
>> of variables is always a good thing.
>
> I agree that it's a good thing. Its build faile
> > Log Message:
> > We don't declare variables in for () statement.
>
> The kernel is a C99 environment which makes that legal. Limiting the scope
> of variables is always a good thing.
I agree that it's a good thing. Its build failed in modules.
Masao
--
Masao Uebayashi / Tombi Inc. / Tel:
On Mon, Dec 14, 2009 at 06:55:19AM -0800, Matt Thomas wrote:
> The kernel is a C99 environment which makes that legal. Limiting the scope
> of variables is always a good thing.
I agree, but we need to fix /usr/share/misc/style for this.
Martin
On Dec 14, 2009, at 4:53 AM, Masao Uebayashi wrote:
> Module Name: src
> Committed By: uebayasi
> Date: Mon Dec 14 12:53:18 UTC 2009
>
> Modified Files:
> src/sys/arch/mips/mips: compat_13_machdep.c compat_16_machdep.c
>
> Log Message:
> We don't declare variables in for () state
On Tue, Aug 18, 2009 at 09:28:07PM +, Matt Thomas wrote:
> Modified Files:
> src/sys/arch/mips/mips: fp.S
>
> Log Message:
> Fix a errant sw (should be lw) that ovewrites the saved [trap]frame
> pointer with a possibly bogus value.
Judging by the dates, this should be pulled up to
59 matches
Mail list logo
