On 2021/04/18 0:38, Joerg Sonnenberger wrote:
On Sat, Apr 17, 2021 at 01:25:57PM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sat Apr 17 13:25:57 UTC 2021
Modified Files:
src/sys/arch/powerpc/include/booke: vmparam.h
Log Message:
Sync MAXfoo params
On Sat, Apr 17, 2021 at 01:25:57PM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sat Apr 17 13:25:57 UTC 2021
>
> Modified Files:
> src/sys/arch/powerpc/include/booke: vmparam.h
>
> Log Message:
> Sync MAXfoo params with oea:
>
> MAXTSIZ: 512MB -> 128M
Ugh. Can we please stop making these hacky one-offs in "shared by all PowerPC
platforms" code? This actually points to a deeper problem in the pmap code
that needs to be addressed correctly.
> On Apr 1, 2021, at 3:02 PM, Michael Lorenz wrote:
>
> Module Name: src
> Committed By: macallan
>
On 2021/01/18 14:49, Rin Okuyama wrote:
(2) However, in clock.c rev 1.31 and prior, curcpu->ci_idepth was not
raised before calling {hard,stat}clock(). Therefore, cpu_intr_p()
wrongly returns false. As a result, callee functions misunderstood
that they are not running in the interr
On 2021/01/18 13:35, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon Jan 18 04:35:05 UTC 2021
Modified Files:
src/sys/arch/powerpc/ibm4xx: clock.c
Log Message:
Invoke hardclock() and statclock() in the interrupt context.
Otherwise, entropy_enter() is used
On 2020/07/07 9:51, Jason Thorpe wrote:
On Jul 6, 2020, at 5:28 PM, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Tue Jul 7 00:28:31 UTC 2020
Modified Files:
src/sys/arch/powerpc/booke: e500_tlb.c
Log Message:
Fix kernel panic due to tmpfs.
pmap for book
> On Jul 6, 2020, at 5:28 PM, Rin Okuyama wrote:
>
> Module Name: src
> Committed By: rin
> Date: Tue Jul 7 00:28:31 UTC 2020
>
> Modified Files:
> src/sys/arch/powerpc/booke: e500_tlb.c
>
> Log Message:
> Fix kernel panic due to tmpfs.
>
> pmap for booke assumes that the ``
Perhaps yes, but I'm not sure. How do you mips guys think?
Thanks,
rin
On 2020/06/27 19:08, Jaromír Doleček wrote:
Perhaps we can use a similar technique for mips too? There also the
kernel actually always uses a compile-time fixed page size AFAICS.
Jaromir
Le sam. 27 juin 2020 à 04:51, Rin O
Perhaps we can use a similar technique for mips too? There also the
kernel actually always uses a compile-time fixed page size AFAICS.
Jaromir
Le sam. 27 juin 2020 à 04:51, Rin Okuyama a écrit :
>
> Module Name:src
> Committed By: rin
> Date: Sat Jun 27 02:51:23 UTC 2020
>
> Modi
On Mon, Jun 22, 2020 at 05:34:57AM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Mon Jun 22 05:34:57 UTC 2020
>
> Modified Files:
> src/sys/arch/powerpc/include: mcontext.h types.h
> src/sys/arch/powerpc/powerpc: sig_machdep.c
>
> Log Message:
> Fix
On 2020/06/22 5:10, Joerg Sonnenberger wrote:
On Sun, Jun 21, 2020 at 12:40:00AM +, Rin Okuyama wrote:
- Obsolete __lwp_settcb() in order to let kernel know new TLS address via
_lwp_setprivate(2). Alternatively, we can call _lwp_setprivate(2) within
__lwp_settcb() like mips, but it is
On Sun, Jun 21, 2020 at 12:40:00AM +, Rin Okuyama wrote:
> - Obsolete __lwp_settcb() in order to let kernel know new TLS address via
> _lwp_setprivate(2). Alternatively, we can call _lwp_setprivate(2) within
> __lwp_settcb() like mips, but it is just double handling; we adjust %r2
> appro
On 2020/02/18 6:55, Andrew Doran wrote:
I corrected the cpu_ast() case. Yes it's curious why ibm4xx calls
mi_userret() directly; that seems wrong (I have not changed it though). I
think it definitely makes more sense to deal with OWEUPC before userret().
Thank you!
Now, I'm working on fixing
On Wed, Feb 05, 2020 at 12:46:57PM +0900, Rin Okuyama wrote:
> Hi,
>
> On 2019/12/06 5:55, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Thu Dec 5 20:55:24 UTC 2019
> >
> > Modified Files:
> > src/sys/arch/powerpc/powerpc: powerpc_machdep
Hi,
On 2019/12/06 5:55, Andrew Doran wrote:
Module Name:src
Committed By: ad
Date: Thu Dec 5 20:55:24 UTC 2019
Modified Files:
src/sys/arch/powerpc/powerpc: powerpc_machdep.c
Log Message:
Need to call userret() from cpu_ast().
To generate a diff of this commit:
cvs r
Hello,
On Thu, 26 May 2016 17:38:06 +
"Michael Lorenz" wrote:
> Module Name: src
> Committed By: macallan
> Date: Thu May 26 17:38:06 UTC 2016
>
> Modified Files:
> src/sys/arch/powerpc/pic: intr.c ipi_openpic.c pic_openpic.c
>
> Log Message:
> treat IPIs like regular interr
Hopefully kernel entry (locore.o) is placed using ldscript so that
stupid *.o ordering in makefiles can go away?
On Sat, Apr 19, 2014 at 9:46 PM, Matt Thomas wrote:
> Module Name:src
> Committed By: matt
> Date: Sat Apr 19 12:46:04 UTC 2014
>
> Added Files:
> src/sys/arch/
In article <20140318143431.920a...@cvs.netbsd.org>,
Michael Lorenz wrote:
>-=-=-=-=-=-
>
>+#ifdef PPC_OEA601
>+static struct timecounter powerpc_601_timecounter = {
>+ get_601_timecount, /* get_timecount */
>+ 0, /* no poll_pps */
>+ 0x7fff,
On Mon, 13 May 2013 00:12:01 +
"Michael Lorenz" wrote:
> Module Name: src
> Committed By: macallan
> Date: Mon May 13 00:12:01 UTC 2013
>
> Modified Files:
> src/sys/arch/powerpc/oea: ofwoea_machdep.c
>
> Log Message:
> more G5 stuff:
> - call OF_quiesce()
> - properly map th
On Tue, Feb 21, 2012 at 02:19:01AM +, Matt Thomas wrote:
> Module Name: src
> Committed By: matt
> Date: Tue Feb 21 02:19:01 UTC 2012
>
> Modified Files:
> src/sys/arch/powerpc/include: cdefs.h
>
> Log Message:
> Restore back to double alignment.
For reference: __ALIGNBYTES is
On Mon Feb 07 2011 at 07:02:25 +, Matt Thomas wrote:
> Module Name: src
> Committed By: matt
> Date: Mon Feb 7 07:02:24 UTC 2011
>
> Modified Files:
> src/sys/arch/powerpc/ibm4xx: pmap.c
>
> Log Message:
> Use EVCNT_ATTACH_STATIC
Can't we just:
1) Work toward getting of rid
On Mon, Nov 15, 2010 at 10:41:55PM +, David Laight wrote:
> > Indeed. Properly speaking though, headers that are exported to
> > userland should define only the precise symbols that userland needs;
> > kernel-only material should be kept elsewhere.
>
> One start would be to add a sys/proc
On Mon, Nov 15, 2010 at 08:34:40PM +, David Holland wrote:
> (moving this to tech-kern because it's the right place and per request)
>
> On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote:
> > > Every header file should include the things it requires to compile.
> > > Therefore,
On Tue, Nov 16, 2010 at 05:41:14AM +, David Holland wrote:
> On Tue, Nov 16, 2010 at 10:20:46AM +0900, Masao Uebayashi wrote:
> > Another thing:
> >
> > - We should provide sysconf() for kernel modules (device drivers) too,
> > otherwise we have to expose unnecessary symbols (uvmexp).
>
On Tue, Nov 16, 2010 at 10:20:46AM +0900, Masao Uebayashi wrote:
> Another thing:
>
> - We should provide sysconf() for kernel modules (device drivers) too,
> otherwise we have to expose unnecessary symbols (uvmexp).
Why not the complete sysctl tree?
--
David A. Holland
dholl...@netbsd.or
On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote:
> On Sun, Nov 14, 2010 at 05:52:51AM +, David Holland wrote:
> > On Sun, Nov 14, 2010 at 03:32:44AM +, Masao Uebayashi wrote:
> > > XXX What is the conclusion about direct vs. indirect #include from
> > headers?
> >
> > Eve
Hi,
On Mon, Nov 15, 2010 at 5:41 PM, David Laight wrote:
> On Mon, Nov 15, 2010 at 08:50:34AM +, David Holland wrote:
>> On Mon, Nov 15, 2010 at 02:48:29PM +0900, SODA Noriyuki wrote:
>> > Well, there is another thing which has to be considered. That is
>> > name space pollution.
>> > Hea
On Mon, Nov 15, 2010 at 08:50:34AM +, David Holland wrote:
> On Mon, Nov 15, 2010 at 02:48:29PM +0900, SODA Noriyuki wrote:
> > Well, there is another thing which has to be considered. That is
> > name space pollution.
> > Header files which are exported to userland (for userland visible AP
(moving this to tech-kern because it's the right place and per request)
On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote:
> > Every header file should include the things it requires to compile.
> > Therefore, there should in principle be no cases where a header file
> > (or sourc
On Mon, Nov 15, 2010 at 02:48:29PM +0900, SODA Noriyuki wrote:
> Well, there is another thing which has to be considered. That is
> name space pollution.
> Header files which are exported to userland (for userland visible APIs)
> should not export random symbols. Only symbols which are define
On Nov,Monday 15 2010, at 7:16 AM, Bernd Ernesti wrote:
> On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote:
>> On Sun, Nov 14, 2010 at 05:52:51AM +, David Holland wrote:
>>> On Sun, Nov 14, 2010 at 03:32:44AM +, Masao Uebayashi wrote:
XXX What is the conclusion about d
On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote:
> On Sun, Nov 14, 2010 at 05:52:51AM +, David Holland wrote:
> > On Sun, Nov 14, 2010 at 03:32:44AM +, Masao Uebayashi wrote:
> > > XXX What is the conclusion about direct vs. indirect #include from
> > headers?
> >
> > Eve
> On Sun, 14 Nov 2010 05:52:51 +,
David Holland said:
> On Sun, Nov 14, 2010 at 03:32:44AM +, Masao Uebayashi wrote:
>> XXX What is the conclusion about direct vs. indirect #include from headers?
>
> Every header file should include the things it requires to compile.
> Theref
On Mon, Nov 15, 2010 at 11:24:21AM +0900, Masao Uebayashi wrote:
> On Sun, Nov 14, 2010 at 05:52:51AM +, David Holland wrote:
> > On Sun, Nov 14, 2010 at 03:32:44AM +, Masao Uebayashi wrote:
> > > XXX What is the conclusion about direct vs. indirect #include from
> > headers?
> >
> > Eve
On Sun, Nov 14, 2010 at 05:52:51AM +, David Holland wrote:
> On Sun, Nov 14, 2010 at 03:32:44AM +, Masao Uebayashi wrote:
> > XXX What is the conclusion about direct vs. indirect #include from headers?
>
> Every header file should include the things it requires to compile.
> Therefore, th
On Sun, Nov 14, 2010 at 03:32:44AM +, Masao Uebayashi wrote:
> XXX What is the conclusion about direct vs. indirect #include from headers?
Every header file should include the things it requires to compile.
Therefore, there should in principle be no cases where a header file
(or source file)
On Sun, Nov 07, 2010 at 01:46:06PM +1100, Simon Burge wrote:
> "Masao Uebayashi" wrote:
>
> > Module Name:src
> > Committed By: uebayasi
> > Date: Sat Nov 6 16:36:27 UTC 2010
> >
> > Modified Files:
> >
> > src/sys/arch/powerpc/ibm4xx: pmap.c
> > src/sys/arch
"Masao Uebayashi" wrote:
> Module Name: src
> Committed By: uebayasi
> Date: Sat Nov 6 16:36:27 UTC 2010
>
> Modified Files:
>
> src/sys/arch/powerpc/ibm4xx: pmap.c
> src/sys/arch/powerpc/include/ibm4xx: vmparam.h
>
> Log Message:
>
> Merge from uebayasi-xip:
> --
38 matches
Mail list logo
