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
>> 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
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
>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
Hello,
On Fri, 05 Feb 2021 00:12:35 +0900
Tetsuya Isaki wrote:
> At Wed, 3 Feb 2021 13:37:24 -0500,
> Michael wrote:
> > > Committed By: isaki
> > > Date: Wed Feb 3 15:13:49 UTC 2021
> > >
> > > Modified Files:
> > > src/sys/arch/hppa/gsc: harmony.c
> > >
> > > Log Message:
Hello,
At Wed, 3 Feb 2021 13:37:24 -0500,
Michael wrote:
> > Committed By: isaki
> > Date: Wed Feb 3 15:13:49 UTC 2021
> >
> > Modified Files:
> > src/sys/arch/hppa/gsc: harmony.c
> >
> > Log Message:
> > Fix locking against myself.
> > trigger_output will be called
Hello,
On Wed, 3 Feb 2021 15:13:49 +
"Tetsuya Isaki" wrote:
> Module Name: src
> Committed By: isaki
> Date: Wed Feb 3 15:13:49 UTC 2021
>
> Modified Files:
> src/sys/arch/hppa/gsc: harmony.c
>
> Log Message:
> Fix locking against myself.
> trigger_output will be called
> On Jan 25, 2021, at 9:45 AM, Robert Elz wrote:
>
>Date:Mon, 25 Jan 2021 08:19:44 -0800
>From:Jason Thorpe
>Message-ID:
>
> | Using { 0 } makes an assumption about the first member of the
> | structure which is not guaranteed to remain true.
>
> That's
On 25.01.2021 17:19, Jason Thorpe wrote:
>
>> On Jan 25, 2021, at 6:22 AM, Kamil Rytarowski wrote:
>>
>> I have no problem with this change but I am curious why should we use "{
>> }"? It's a C GNU extension and C++ syntax.
>
> Using { 0 } makes an assumption about the first member of the
On Mon, Jan 25, 2021 at 20:28:52 +0300, Valery Ushakov wrote:
> On Mon, Jan 25, 2021 at 08:19:44 -0800, Jason Thorpe wrote:
>
> > > On Jan 25, 2021, at 6:22 AM, Kamil Rytarowski wrote:
> > >
> > > I have no problem with this change but I am curious why should we use "{
> > > }"? It's a C GNU
Date:Mon, 25 Jan 2021 08:19:44 -0800
From:Jason Thorpe
Message-ID:
| Using { 0 } makes an assumption about the first member of the
| structure which is not guaranteed to remain true.
That's right, but you could explicitly init a named field, most likely
the one
On Mon, Jan 25, 2021 at 08:19:44 -0800, Jason Thorpe wrote:
> > On Jan 25, 2021, at 6:22 AM, Kamil Rytarowski wrote:
> >
> > I have no problem with this change but I am curious why should we use "{
> > }"? It's a C GNU extension and C++ syntax.
>
> Using { 0 } makes an assumption about the
> On Jan 25, 2021, at 6:22 AM, Kamil Rytarowski wrote:
>
> I have no problem with this change but I am curious why should we use "{
> }"? It's a C GNU extension and C++ syntax.
Using { 0 } makes an assumption about the first member of the structure which
is not guaranteed to remain true.
--
On 25.01.2021 15:20, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Mon Jan 25 14:20:39 UTC 2021
>
> Modified Files:
> src/sys/arch/arm/altera: cycv_clkmgr.c
> src/sys/arch/arm/amlogic: meson_pinctrl.c meson_pwm.c meson_thermal.c
>
I forgot that I added dma-ranges support back in Feb last year. All good,
please ignore me :)
On Thu, 21 Jan 2021, Jared McNeill wrote:
This driver is not 64-bit safe and should not be enabled on aarch64 as-is. I
think before turning it on we should restrict it to the lower 1GB of memory
This driver is not 64-bit safe and should not be enabled on aarch64 as-is.
I think before turning it on we should restrict it to the lower 1GB of
memory like the Pi3 models where we know it at least has a chance of
working. You can do this easily by creating a restrictive tag using
"Nia Alarie" writes:
> Module Name: src
> Committed By: nia
> Date: Wed Jan 20 13:22:08 UTC 2021
>
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC MODULAR XEN3_DOM0 XEN3_DOMU
> src/sys/arch/evbarm/conf: OPENBLOCKS_AX3
> src/sys/arch/i386/conf: GENERIC MODULAR
On Tue, Jan 19, 2021 at 07:19:51PM +0100, Martin Husemann wrote:
> On Tue, Jan 19, 2021 at 12:35:10AM +, Jason R Thorpe wrote:
> > Module Name:src
> > Committed By: thorpej
> > Date: Tue Jan 19 00:35:10 UTC 2021
> >
> > Modified Files:
> >
On Tue, Jan 19, 2021 at 12:35:10AM +, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Tue Jan 19 00:35:10 UTC 2021
>
> Modified Files:
> src/sys/arch/arm/sunxi: sunxi_sramc.c
>
> Log Message:
> Use device_compatible_entry / of_search_compatible()
> 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 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
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
Oops. The change was to make sure that a devicetree node with a
"rockchip,grf" property on a device type that doesn't provide a config
struct doesn't deref a NULL ptr.
On Fri, 1 Jan 2021, Jared D. McNeill wrote:
Module Name:src
Committed By: jmcneill
Date: Fri Jan 1 11:44:41
Excellent! Thank you so much for finding out and fixing this!
Full ATF successfully completed for Raspberry Pi 2b, which formerly
crashed due to "anon != NULL && anon->an_ref != 0" panic.
Now, ATF is running on Cubietruck and Raspberry Pi Zero W.
Thanks,
rin
On 2020/11/22 4:44, Nick Hudson
On 2020/11/12 6:52, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Tue Nov 10 21:40:07 UTC 2020
Modified Files:
src/sys/arch/arm/arm: cpu_exec.c
Log Message:
Test (epp->ep_esch->es_emul != _netbsd) instead of
nice, this is a step
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Tue Nov 10 21:40:07 UTC 2020
>
> Modified Files:
> src/sys/arch/arm/arm: cpu_exec.c
>
> Log Message:
> Test (epp->ep_esch->es_emul != _netbsd) instead of
nice, this is a step forward.
an optimisation on it could
Hi Tobias,
> If you're interested there is an older version[1] of envctrl in the
> Attic that might be relevant to use for reference. It supported fan
> speed controls on E450. IIRC I got some of the magic constants from
> OpenSolaris. Sadly I don't own an E450 any more.
>
> [1]
>
On Sat, 24 Oct 2020 15:16:39 +
Julian Coleman wrote:
> Module Name: src
> Committed By: jdc
> Date: Sat Oct 24 15:16:39 UTC 2020
>
> Modified Files:
> src/sys/arch/sparc64/dev: pcf8591_envctrl.c
>
> Log Message:
> Add support for automatically changing the CPU fan speed on
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
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
Thank you very much!
Thomas
> On 06.10.2020, at 15:42, Christos Zoulas wrote:
>
> Module Name: src
> Committed By: christos
> Date: Tue Oct 6 13:42:03 UTC 2020
>
> Modified Files:
> src/sys/arch/aarch64/include: vmparam.h
> src/sys/arch/amd64/include: vmparam.h
>
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:
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
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
>> Index: src/sys/arch/aarch64/include/cpu.h
>> diff -u src/sys/arch/aarch64/include/cpu.h:1.27 src/sys/arch/aarch64/inc=
>lude/cpu.h:1.28
>> --- src/sys/arch/aarch64/include/cpu.h:1.27 Mon Sep 14 10:06:35 2020
>> +++ src/sys/arch/aarch64/include/cpu.h Thu Oct 1 06:40:16 2020
>> @@ -1,4
On 01/10/2020 07:40, Ryo Shimizu wrote:
Module Name:src
Committed By: ryo
Date: Thu Oct 1 06:40:16 UTC 2020
Modified Files:
src/sys/arch/aarch64/aarch64: procfs_machdep.c
src/sys/arch/aarch64/include: cpu.h
Log Message:
fix build error with LLVM
[...]
Index:
>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
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
> On Sep 3, 2020, at 1:14 PM, matthew green wrote:
>
> "Jason R Thorpe" writes:
>> Module Name: src
>> Committed By:thorpej
>> Date:Thu Sep 3 04:20:54 UTC 2020
>>
>> Modified Files:
>> src/sys/arch/alpha/include: cpu.h
>>
>> Log Message:
>> Garabage-collect
"Jason R Thorpe" writes:
> Module Name: src
> Committed By: thorpej
> Date: Thu Sep 3 04:20:54 UTC 2020
>
> Modified Files:
> src/sys/arch/alpha/include: cpu.h
>
> Log Message:
> Garabage-collect curpcb / cpu_info::ci_curpcb.
does alpha have modules? this may be a ABI change
On 2020/08/11 10:24, matthew green wrote:
XXX
Apply similar fixes to other m68k ports.
yes...but also, a long-term project to consolidate all the
almost-identical m68k code copied into each port would
avoid this probably :-)
Agreed. Also, I've found many dead codes in amiga/locore.s.
I'd
thanks!
> XXX
> Apply similar fixes to other m68k ports.
yes...but also, a long-term project to consolidate all the
almost-identical m68k code copied into each port would
avoid this probably :-)
Hi,
Sorry for the serious delay in my response.
On 2020/07/22 13:37, matthew green wrote:
thanks for getting more m68k working!
Thanks!
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Tue Jul 21 06:39:31 UTC 2020
Modified Files:
> Module Name:src
> Committed By: jdolecek
> Date: Sat Aug 1 12:36:36 UTC 2020
>
> Modified Files:
> src/sys/arch/x86/pci: pci_intr_machdep.c
> src/sys/arch/x86/x86: mainbus.c
>
> Log Message:
> reorder includes to pull __HAVE_PCI_MSI_MSIX properly via
>
If
thanks for getting more m68k working!
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Tue Jul 21 06:39:31 UTC 2020
>
> Modified Files:
> src/sys/arch/amiga/amiga: locore.s
>
> Log Message:
> Align tmpstk to 4-byte boundary in the same manner as mac68k.
>
>
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
> 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
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.
Martin Husemann writes:
>
> That build pre-dates Luke's fix.
>
Ahh, you are correct and it built fine for me, apologies.
Thanks
On Thu, Jul 02, 2020 at 08:03:09AM -0700, scole_mail wrote:
> That change didn't work:
>
> http://releng.netbsd.org/builds/HEAD/202007020210Z/ia64.build.failed
> ...
> nbmake[10]: nbmake[10]: don't know how to make loader.efi.c. Stop
That build pre-dates Luke's fix.
Martin
"Luke Mewburn" writes:
> Module Name: src
> Committed By: lukem
> Date: Thu Jul 2 09:07:25 UTC 2020
>
> Modified Files:
> src/sys/arch/ia64/stand/ia64/efi: Makefile
>
> Log Message:
> loader.efi doesn't have source
>
> (Untested fix)
>
>
> To generate a diff of this commit:
> cvs
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
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
>
>
Hi Rin,
Rin Okuyama wrote:
> Hi,
>
> On 2020/06/23 14:18, Simon Burge wrote:
> > Module Name:src
> > Committed By: simonb
> > Date: Tue Jun 23 05:18:43 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/mips/cavium/dev: octeon_uart.c
> >
> > Log Message:
> > Add
Hi,
On 2020/06/23 14:18, Simon Burge wrote:
Module Name:src
Committed By: simonb
Date: Tue Jun 23 05:18:43 UTC 2020
Modified Files:
src/sys/arch/mips/cavium/dev: octeon_uart.c
Log Message:
Add support for a very simple output-only console so early printf() can work.
"Jaromir Dolecek" writes:
> Module Name: src
> Committed By: jdolecek
> Date: Wed Jun 24 22:28:08 UTC 2020
>
> Modified Files:
> src/sys/arch/x86/x86: multiboot2.c
>
> Log Message:
> don't try allocating 16KB of scratch space on stack
>
> it's too early for kmem_alloc(), so use
On Wed, Jun 24, 2020 at 10:28:08PM +, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Wed Jun 24 22:28:08 UTC 2020
>
> Modified Files:
> src/sys/arch/x86/x86: multiboot2.c
>
> Log Message:
> don't try allocating 16KB of scratch space on stack
>
>
> Module Name:src
> Committed By: jdolecek
> Date: Fri Apr 10 18:03:06 UTC 2020
>
> Modified Files:
> src/sys/arch/xen/xen: if_xennet_xenbus.c
>
> Log Message:
> convert to bus_dma(9), remove now not necessary XENPVHVM redefines
> [...]
> +
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:
>
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
>
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
> 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.
>
In article <20200606135850.ge14...@pony.stderr.spb.ru>,
Valery Ushakov wrote:
>On Sat, Jun 06, 2020 at 11:25:19 +0200, Kamil Rytarowski wrote:
>
>> On 06.06.2020 09:42, Simon Burge wrote:
>> > "Kamil Rytarowski" wrote:
>> >
>> >> Module Name: src
>> >> Committed By: kamil
>> >> Date:
On Sat, Jun 06, 2020 at 11:25:19 +0200, Kamil Rytarowski wrote:
> On 06.06.2020 09:42, Simon Burge wrote:
> > "Kamil Rytarowski" wrote:
> >
> >> Module Name: src
> >> Committed By: kamil
> >> Date: Fri Jun 5 21:48:04 UTC 2020
> >>
> >> Modified Files:
> >>
> >>
On 06.06.2020 09:42, Simon Burge wrote:
> "Kamil Rytarowski" wrote:
>
>> Module Name: src
>> Committed By:kamil
>> Date:Fri Jun 5 21:48:04 UTC 2020
>>
>> Modified Files:
>>
>> src/sys/arch/x86/x86: cpu_rng.c
>>
>> Log Message:
>>
>> Change const unsigned to
"Kamil Rytarowski" wrote:
> Module Name: src
> Committed By: kamil
> Date: Fri Jun 5 21:48:04 UTC 2020
>
> Modified Files:
>
> src/sys/arch/x86/x86: cpu_rng.c
>
> Log Message:
>
> Change const unsigned to preprocessor define
>
> Fixes GCC -O0 build with the stack protector.
On 04.06.2020 23:41, Andrew Doran wrote:
> On Thu, Jun 04, 2020 at 02:35:17AM +0200, Kamil Rytarowski wrote:
>
>> On 04.06.2020 00:42, Andrew Doran wrote:
>>> On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
>>>
On 03.06.2020 01:49, Andrew Doran wrote:
> On the assembly
On Thu, Jun 04, 2020 at 02:35:17AM +0200, Kamil Rytarowski wrote:
> On 04.06.2020 00:42, Andrew Doran wrote:
> > On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
> >
> >> On 03.06.2020 01:49, Andrew Doran wrote:
> >>> On the assembly thing recall that recently you expressed a
On 04.06.2020 00:42, Andrew Doran wrote:
> On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
>
>> On 03.06.2020 01:49, Andrew Doran wrote:
>>> On the assembly thing recall that recently you expressed a desire to remove
>>> all of the amd64 assembly string functions from libc
Maxime,
I read your e-mail carefully and conclude that the best way forward here is
put this one to core@ for a technical decision.
Cheers,
Andrew
On Wed, Jun 03, 2020 at 08:25:32AM +0200, Maxime Villard wrote:
> Le 03/06/2020 ? 01:49, Andrew Doran a ?crit?:
> > On Tue, Jun 02, 2020 at
On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
> On 03.06.2020 01:49, Andrew Doran wrote:
> > On the assembly thing recall that recently you expressed a desire to remove
> > all of the amd64 assembly string functions from libc because of sanitizers -
> > I invested my time to
Le 03/06/2020 à 02:03, Kamil Rytarowski a écrit :
On 03.06.2020 01:49, Andrew Doran wrote:
On the assembly thing recall that recently you expressed a desire to remove
all of the amd64 assembly string functions from libc because of sanitizers -
I invested my time to do up a little demo to try
Le 03/06/2020 à 01:49, Andrew Doran a écrit :
On Tue, Jun 02, 2020 at 08:41:53AM +0200, Maxime Villard wrote:
Le 02/06/2020 ? 00:58, Andrew Doran a ?crit?:
Module Name:src
Committed By: ad
Date: Mon Jun 1 22:58:06 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64:
On 03.06.2020 01:49, Andrew Doran wrote:
> On the assembly thing recall that recently you expressed a desire to remove
> all of the amd64 assembly string functions from libc because of sanitizers -
> I invested my time to do up a little demo to try and show you why that's not
> a good idea:
>
>
On Tue, Jun 02, 2020 at 08:41:53AM +0200, Maxime Villard wrote:
> Le 02/06/2020 ? 00:58, Andrew Doran a ?crit?:
> > Module Name:src
> > Committed By: ad
> > Date: Mon Jun 1 22:58:06 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/amd64/amd64: cpufunc.S
> >
Le 02/06/2020 à 00:58, Andrew Doran a écrit :
Module Name:src
Committed By: ad
Date: Mon Jun 1 22:58:06 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S
src/sys/arch/amd64/include: frameasm.h
Log Message:
Reported-by:
Le 28/05/2020 à 23:58, Andrew Doran a écrit :
On Thu, May 28, 2020 at 07:06:04PM +0200, Maxime Villard wrote:
Le 27/05/2020 ? 21:58, Maxime Villard a ?crit?:
Le 27/05/2020 ? 21:33, Andrew Doran a ?crit?:
Module Name:??? src
Committed By:??? ad
Date:??? Wed May 27 19:33:40 UTC 2020
On Thu, May 28, 2020 at 07:06:04PM +0200, Maxime Villard wrote:
> Le 27/05/2020 ? 21:58, Maxime Villard a ?crit?:
> > Le 27/05/2020 ? 21:33, Andrew Doran a ?crit?:
> > > Module Name:??? src
> > > Committed By:??? ad
> > > Date:??? Wed May 27 19:33:40 UTC 2020
> > >
> > > Modified Files:
> > >
Le 28/05/2020 à 19:06, Maxime Villard a écrit :
Le 27/05/2020 à 21:58, Maxime Villard a écrit :
Le 27/05/2020 à 21:33, Andrew Doran a écrit :
Module Name: src
Committed By: ad
Date: Wed May 27 19:33:40 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S locore.S
Le 27/05/2020 à 21:58, Maxime Villard a écrit :
Le 27/05/2020 à 21:33, Andrew Doran a écrit :
Module Name: src
Committed By: ad
Date: Wed May 27 19:33:40 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S locore.S
src/sys/arch/i386/i386: cpufunc.S locore.S
Le 27/05/2020 à 21:33, Andrew Doran a écrit :
Module Name:src
Committed By: ad
Date: Wed May 27 19:33:40 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S locore.S
src/sys/arch/i386/i386: cpufunc.S locore.S
src/sys/arch/x86/include: pmap.h
>> Has any consideration be given to perhaps creating a new MACHINE_ARCH for
>> this, or somehow otherwise decorating the ELF files to indicate their
>> exec-ability?
>
>I am under the impression that PAC was designed to be forewards
>compatible, so older CPUs can execute code with this
On Sat, May 23, 2020 at 02:13:46PM -0700, Jason Thorpe wrote:
>
> > On May 23, 2020, at 11:08 AM, Ryo Shimizu wrote:
> >
> > Module Name:src
> > Committed By: ryo
> > Date: Sat May 23 18:08:59 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/aarch64/aarch64:
> On May 23, 2020, at 11:08 AM, Ryo Shimizu wrote:
>
> Module Name: src
> Committed By: ryo
> Date: Sat May 23 18:08:59 UTC 2020
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: cpufunc.c cpuswitch.S exec_machdep.c
> genassym.cf netbsd32_machdep.c vectors.S
On Thu, May 21, 2020 at 11:19:49PM +0200, Joerg Sonnenberger wrote:
> On Thu, May 21, 2020 at 09:12:31PM +, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Thu May 21 21:12:31 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/x86/acpi:
On Thu, May 21, 2020 at 09:12:31PM +, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Thu May 21 21:12:31 UTC 2020
>
> Modified Files:
> src/sys/arch/x86/acpi: acpi_wakeup.c
> src/sys/arch/x86/include: i82489var.h
> src/sys/arch/x86/x86: cpu.c
Module Name:src
Committed By: ad
Date: Tue May 19 21:40:55 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S
src/sys/arch/i386/i386: cpufunc.S i386func.S
Log Message:
Make cpu_counter(), cpu_counter32() and tsc_get_timecount() into a single
On Sat, May 16, 2020 at 02:51:43PM +1000, matthew green wrote:
> "Jaromir Dolecek" writes:
> > Module Name:src
> > Committed By: jdolecek
> > Date: Fri May 15 07:42:58 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/xen/include: intr.h
> >
"Jaromir Dolecek" writes:
> Module Name: src
> Committed By: jdolecek
> Date: Fri May 15 07:42:58 UTC 2020
>
> Modified Files:
> src/sys/arch/xen/include: intr.h
> src/sys/arch/xen/x86: pintr.c
>
> Log Message:
> use short for irq2port[] to save memory (4KB), it only needs
On Mon, Apr 13, 2020 at 08:09:13PM +, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Mon Apr 13 20:09:13 UTC 2020
>
> Modified Files:
> src/sys/arch/xen/xen: xbd_xenbus.c
>
> Log Message:
> KASSERT() that requested I/O size is <= XBD_MAX_XFER - this
HI,
I am not sur whether it is the commit below, but 2 out 4 times my
xen-DOMU from today (20200409/9.99.55)
panics with following locking botch:
[ 29.9301379] panic: kernel diagnostic assertion "IFNET_LOCKED(ifp)"
failed: file "/usr/src/sys/arch/xen/xen/if_xennet_xenbus.c", line 1120
[
On Sun, Apr 05, 2020 at 05:26:47PM +, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Sun Apr 5 17:26:47 UTC 2020
>
> Modified Files:
> src/sys/arch/xen/xen: if_xennet_xenbus.c xennetback_xenbus.c
>
> Log Message:
> remove support for legacy rx-flip
Hi,
Hmm, but TSC drift is still observed on recent (high clock) CPUs.
I will have researched and fix later.
On 2020/04/03 12:05, Kengo NAKAHARA wrote:
Module Name:src
Committed By: knakahara
Date: Fri Apr 3 03:05:39 UTC 2020
Modified Files:
src/sys/arch/x86/x86: tsc.c
Great work! One small remark:
+static int
+ave_fdt_match(device_t parent, cfdata_t cf, void *aux)
+{
+ static const char * compatible[] = {
+#ifdef _LP64
+ "socionext,unifier-ld20-ave4",
+#else
+
On Wed, Mar 18, 2020 at 09:44:03PM +0200, Yorick Hardy wrote:
> Dear Andrew,
>
> On 2020-03-14, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Sat Mar 14 13:50:46 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/x86/acpi: acpi_cpu_md.c
> >
Dear Andrew,
On 2020-03-14, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Sat Mar 14 13:50:46 UTC 2020
>
> Modified Files:
> src/sys/arch/x86/acpi: acpi_cpu_md.c
>
> Log Message:
> Put ACPI idle under ACPICPU_ENABLE_C3 until the wrinkles are ironed out.
> This
1 - 100 of 3665 matches
Mail list logo
