On Mon, 22 Feb 2021, Ryo Shimizu wrote:
I think this condition is not necessary since cpu_idle() is just called from
idle_loop(),
and ci_intr_depth is always zero at this time.
Ah yes, my mistake! Please feel free to revert this commit as part of
your proposed change.
> On Feb 22, 2021, at 11:49 AM, Ryo Shimizu wrote:
>
> Ah, You are quite right!
> idle/# lwp is provided and assigned for each CPU, so curcpu() obtained from
> idle lwp was always the same.
> So, there's no need to move curcpu() to after DISABLE_INTERRUPT.
Please make sure to add a comment exp
>> In addition, because of the possibility of kpreemption (but aarch64 has =
>no KPREEMPT yet),
>> the acquisition of curcpu() is moved to after DISABLE_INTERRUPT and got =
>the following.
>>
>[snip]
>
>
>>
>> Is this ok?
>>
>
>Looks good - I wonder if the fact that curcpu is an invariant for the
On 22/02/2021 10:40, Ryo Shimizu wrote:
Module Name:src
Committed By: jmcneill
Date: Sun Feb 21 23:37:10 UTC 2021
Modified Files:
src/sys/arch/aarch64/aarch64: idle_machdep.S
Log Message:
When waking from cpu_idle(), only call dosoftints if ci_intr_depth == 0
To gene
>Module Name: src
>Committed By: jmcneill
>Date: Sun Feb 21 23:37:10 UTC 2021
>
>Modified Files:
> src/sys/arch/aarch64/aarch64: idle_machdep.S
>
>Log Message:
>When waking from cpu_idle(), only call dosoftints if ci_intr_depth == 0
>
>
>To generate a diff of this commit:
>cvs r
> Log Message:
> Fix build as crash(8); Protect db_md_meminfo_cmd() by defined(_KERNEL).
thanks. surprised i never saw this as the change was in a
tree for a few weeks, but i guess i was mostly doing kernels
in that tree not full builds..
.mrg.
On Tue, Oct 13, 2020 at 12:57:44PM +0200, Kamil Rytarowski wrote:
> > Log Message:
> > BE32 binaries are no longer supported for ARMv7 and later, and
> > therefore for aarch64eb.
> >
> > Reject them with ENOEXEC, rather than causing illegal instruction
> > exceptions due to unexpected binary forma
On 2020/10/13 19:57, Kamil Rytarowski wrote:
On 13.10.2020 09:04, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Tue Oct 13 07:04:49 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: exec_machdep.c
Log Message:
BE32 binaries are no longer supported for
On 13.10.2020 09:04, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Tue Oct 13 07:04:49 UTC 2020
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: exec_machdep.c
>
> Log Message:
> BE32 binaries are no longer supported for ARMv7 and later, and
> therefore for a
It works fine now. Thank you for quick fix!!
rin
On 2020/10/06 15:28, Nick Hudson wrote:
On 06/10/2020 01:54, Rin Okuyama wrote:
Hi,
On 2020/10/01 1:35, Nick Hudson wrote:
Module Name: src
Committed By: skrll
Date: Wed Sep 30 16:35:49 UTC 2020
Modified Files:
src/sys/arch/
On 06/10/2020 01:54, Rin Okuyama wrote:
Hi,
On 2020/10/01 1:35, Nick Hudson wrote:
Module Name: src
Committed By: skrll
Date: Wed Sep 30 16:35:49 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: cpuswitch.S vectors.S
Log Message:
Move el[01]_trap_exit into vectors.S w
Hi,
On 2020/10/01 1:35, Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Wed Sep 30 16:35:49 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: cpuswitch.S vectors.S
Log Message:
Move el[01]_trap_exit into vectors.S where the callers exist
To generate
>On 24/09/2020 10:04, Ryo Shimizu wrote:
>> Module Name: src
>> Committed By:ryo
>> Date:Thu Sep 24 09:04:38 UTC 2020
>>
>> Modified Files:
>> src/sys/arch/aarch64/aarch64: bus_space_asm_generic.S
>>
>> Log Message:
>> fix bugs in *_bs_rm_8_swap(). it was only reading
On 24/09/2020 10:04, Ryo Shimizu wrote:
Module Name:src
Committed By: ryo
Date: Thu Sep 24 09:04:38 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: bus_space_asm_generic.S
Log Message:
fix bugs in *_bs_rm_8_swap(). it was only reading 4 bytes, not 8 bytes.
I thi
I think this will have issues on some big.LITTLE configurations
like Rockchip RK3399.
In the RK3399 case cpu[0-3] is VIPT I$ and cpu[4-5] is PIPT I$. Boot
order of secondaries is not guaranteed so it is possible to get different
values of aarch64_cache_vindexsize from one boot to the next.
J
"Ryo Shimizu" writes:
> Module Name: src
> Committed By: ryo
> Date: Wed Oct 31 06:36:19 UTC 2018
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: pmap.c
>
> Log Message:
> invalidate icache correctly.
> l3pte_executable() should be used for only valid pte.
thanks! this makes
>> Module Name: src
>> Committed By:ryo
>> Date:Mon Sep 17 00:15:55 UTC 2018
>>
>> Modified Files:
>> src/sys/arch/aarch64/aarch64: pmap.c
>>
>> Log Message:
>> delete debug printf and KASSERT.
>
>i'm confused by this (moved) comment:
>
>/* pte is readable and writ
"Ryo Shimizu" writes:
> Module Name: src
> Committed By: ryo
> Date: Mon Sep 17 00:15:55 UTC 2018
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: pmap.c
>
> Log Message:
> delete debug printf and KASSERT.
i'm confused by this (moved) comment:
/* pte is readable and writable,
On 2018/09/10 16:49, Nick Hudson wrote:
For the record this should be fixed now with
sys/arch/aarch64/aarch64/locore.S:1.24
sys/arch/evbarm/fdt/fdt_start.S:1.4
The problem is gone. Thank you for quick fix!
rin
On 10/09/18 04:41, Rin Okuyama wrote:
Hi,
Hi,
After this commit, GENERIC64 does not boot anymore on RPI3B and 3B+.
It successfully boots if locore.S is reverted to rev. 1.21.
Strangely enough, after boot with old locore.S, it can reboot with new
locore.S. However, for initial boot after power-
Hi,
Hi,
After this commit, GENERIC64 does not boot anymore on RPI3B and 3B+.
It successfully boots if locore.S is reverted to rev. 1.21.
Strangely enough, after boot with old locore.S, it can reboot with new
locore.S. However, for initial boot after power-on, only kernel with
old locore.S works
On Jul 18, 12:04am, r...@nerv.org (Ryo Shimizu) wrote:
-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64
| kern_vtopdiff has already been fixed. (thanks christos@)
| u_int uboot_args[4] (in various file :-P) has same problem.
| Should I fix it? [Y/y]
I just did.
christos
On Jul 18, 12:57am, r...@nerv.org (Ryo Shimizu) wrote:
-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64
|
| >On Jul 18, 12:04am, r...@nerv.org (Ryo Shimizu) wrote:
| >-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64
| >
| >| kern_vtopdiff has already been fixed. (tha
>On Jul 18, 12:04am, r...@nerv.org (Ryo Shimizu) wrote:
>-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64
>
>| kern_vtopdiff has already been fixed. (thanks christos@)
>| u_int uboot_args[4] (in various file :-P) has same problem.
>| Should I fix it? [Y/y]
>
>
On Jul 18, 12:04am, r...@nerv.org (Ryo Shimizu) wrote:
-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64
| kern_vtopdiff has already been fixed. (thanks christos@)
| u_int uboot_args[4] (in various file :-P) has same problem.
| Should I fix it? [Y/y]
Please do! Does the gcc kernel boot
>On Tue, Jul 17, 2018 at 11:12:41AM +, Ryo Shimizu wrote:
>> Module Name: src
>> Committed By:ryo
>> Date:Tue Jul 17 11:12:41 UTC 2018
>>
>> Modified Files:
>> src/sys/arch/aarch64/aarch64: aarch64_machdep.c
>>
>> Log Message:
>> kern_vtopdiff is stored in fdt_s
On Tue, Jul 17, 2018 at 11:12:41AM +, Ryo Shimizu wrote:
> Module Name: src
> Committed By: ryo
> Date: Tue Jul 17 11:12:41 UTC 2018
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: aarch64_machdep.c
>
> Log Message:
> kern_vtopdiff is stored in fdt_start.S. that is before c
27 matches
Mail list logo