Re: CVS commit: src/sys/arch/aarch64/aarch64

2021-02-23 Thread Jared McNeill
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.

Re: CVS commit: src/sys/arch/aarch64/aarch64

2021-02-22 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/arch/aarch64/aarch64

2021-02-22 Thread Ryo Shimizu
>> 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

Re: CVS commit: src/sys/arch/aarch64/aarch64

2021-02-22 Thread Nick Hudson
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

Re: CVS commit: src/sys/arch/aarch64/aarch64

2021-02-22 Thread Ryo Shimizu
>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

Re: CVS commit: src/sys/arch/hppa/gsc

2021-02-04 Thread Michael
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:

Re: CVS commit: src/sys/arch/hppa/gsc

2021-02-04 Thread Tetsuya Isaki
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

Re: CVS commit: src/sys/arch/hppa/gsc

2021-02-03 Thread Michael
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

Re: CVS commit: src/sys/arch

2021-01-25 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/arch

2021-01-25 Thread Kamil Rytarowski
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

Re: CVS commit: src/sys/arch

2021-01-25 Thread Valery Ushakov
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

Re: CVS commit: src/sys/arch

2021-01-25 Thread Robert Elz
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

Re: CVS commit: src/sys/arch

2021-01-25 Thread Valery Ushakov
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

Re: CVS commit: src/sys/arch

2021-01-25 Thread Jason Thorpe
> 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. --

Re: CVS commit: src/sys/arch

2021-01-25 Thread Kamil Rytarowski
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 >

Re: CVS commit: src/sys/arch/evbarm/conf

2021-01-22 Thread Jared McNeill
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

Re: CVS commit: src/sys/arch/evbarm/conf

2021-01-21 Thread Jared McNeill
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

re: CVS commit: src/sys/arch

2021-01-20 Thread matthew green
"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

Re: CVS commit: src/sys/arch/arm/sunxi

2021-01-20 Thread Martin Husemann
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: > >

Re: CVS commit: src/sys/arch/arm/sunxi

2021-01-19 Thread Martin Husemann
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()

re: CVS commit: src/sys/arch/aarch64/aarch64

2021-01-17 Thread matthew green
> 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.

Re: CVS commit: src/sys/arch/powerpc/ibm4xx

2021-01-17 Thread Rin Okuyama
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

Re: CVS commit: src/sys/arch/powerpc/ibm4xx

2021-01-17 Thread Rin Okuyama
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

Re: CVS commit: src/sys/arch/arm/rockchip

2021-01-01 Thread Jared McNeill
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

Re: CVS commit: src/sys/arch/arm/arm32

2020-11-21 Thread Rin Okuyama
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

Re: CVS commit: src/sys/arch/arm/arm

2020-11-11 Thread Rin Okuyama
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

re: CVS commit: src/sys/arch/arm/arm

2020-11-11 Thread matthew green
"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

Re: CVS commit: src/sys/arch/sparc64/dev

2020-10-24 Thread Julian Coleman
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] >

Re: CVS commit: src/sys/arch/sparc64/dev

2020-10-24 Thread Tobias Nygren
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

Re: CVS commit: src/sys/arch/aarch64/aarch64

2020-10-13 Thread Martin Husemann
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

Re: CVS commit: src/sys/arch/aarch64/aarch64

2020-10-13 Thread Rin Okuyama
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

Re: CVS commit: src/sys/arch/aarch64/aarch64

2020-10-13 Thread Kamil Rytarowski
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

Re: CVS commit: src/sys/arch

2020-10-06 Thread Thomas Klausner
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 >

Re: CVS commit: src/sys/arch/aarch64/aarch64

2020-10-06 Thread Rin Okuyama
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:

Re: CVS commit: src/sys/arch/aarch64/aarch64

2020-10-06 Thread Nick Hudson
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

Re: CVS commit: src/sys/arch/aarch64/aarch64

2020-10-05 Thread Rin Okuyama
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

Re: CVS commit: src/sys/arch/aarch64

2020-10-01 Thread Ryo Shimizu
>> 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

Re: CVS commit: src/sys/arch/aarch64

2020-10-01 Thread Nick Hudson
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:

Re: CVS commit: src/sys/arch/aarch64/aarch64

2020-09-24 Thread Ryo Shimizu
>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

Re: CVS commit: src/sys/arch/aarch64/aarch64

2020-09-24 Thread Nick Hudson
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

Re: CVS commit: src/sys/arch/alpha/include

2020-09-03 Thread Jason Thorpe
> 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

re: CVS commit: src/sys/arch/alpha/include

2020-09-03 Thread matthew green
"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

Re: CVS commit: src/sys/arch

2020-08-16 Thread Rin Okuyama
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

re: CVS commit: src/sys/arch

2020-08-10 Thread matthew green
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 :-)

Re: CVS commit: src/sys/arch/amiga/amiga

2020-08-08 Thread Rin Okuyama
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:

Re: CVS commit: src/sys/arch/x86

2020-08-01 Thread Taylor R Campbell
> 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

re: CVS commit: src/sys/arch/amiga/amiga

2020-07-21 Thread matthew green
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. > >

Re: CVS commit: src/sys/arch/powerpc/booke

2020-07-06 Thread Rin Okuyama
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

Re: CVS commit: src/sys/arch/powerpc/booke

2020-07-06 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/arch/aarch64/aarch64

2020-07-02 Thread Jared McNeill
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.

Re: CVS commit: src/sys/arch/ia64/stand/ia64/efi

2020-07-02 Thread scole_mail
Martin Husemann writes: > > That build pre-dates Luke's fix. > Ahh, you are correct and it built fine for me, apologies. Thanks

Re: CVS commit: src/sys/arch/ia64/stand/ia64/efi

2020-07-02 Thread Martin Husemann
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

Re: CVS commit: src/sys/arch/ia64/stand/ia64/efi

2020-07-02 Thread scole_mail
"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

Re: CVS commit: src/sys/arch/powerpc/include

2020-06-27 Thread Rin Okuyama
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

Re: CVS commit: src/sys/arch/powerpc/include

2020-06-27 Thread Jaromír Doleček
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 > >

Re: CVS commit: src/sys/arch/mips/cavium/dev

2020-06-26 Thread Simon Burge
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

Re: CVS commit: src/sys/arch/mips/cavium/dev

2020-06-26 Thread Rin Okuyama
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.

re: CVS commit: src/sys/arch/x86/x86

2020-06-24 Thread matthew green
"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

Re: CVS commit: src/sys/arch/x86/x86

2020-06-24 Thread Joerg Sonnenberger
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 > >

Re: CVS commit: src/sys/arch/xen/xen

2020-06-24 Thread Taylor R Campbell
> 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 > [...] > +

Re: CVS commit: src/sys/arch/powerpc

2020-06-22 Thread Joerg Sonnenberger
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: >

Re: CVS commit: src/sys/arch/powerpc

2020-06-21 Thread Rin Okuyama
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

Re: CVS commit: src/sys/arch/powerpc

2020-06-21 Thread Joerg Sonnenberger
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 >

Re: CVS commit: src/sys/arch/mips/mips

2020-06-09 Thread Simon Burge
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

Re: CVS commit: src/sys/arch/mips/mips

2020-06-09 Thread Simon Burge
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

Re: CVS commit: src/sys/arch/mips/mips

2020-06-09 Thread Izumi Tsutsui
> 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. >

Re: CVS commit: src/sys/arch/x86/x86

2020-06-06 Thread Christos Zoulas
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:

Re: CVS commit: src/sys/arch/x86/x86

2020-06-06 Thread Valery Ushakov
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: > >> > >>

Re: CVS commit: src/sys/arch/x86/x86

2020-06-06 Thread Kamil Rytarowski
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

Re: CVS commit: src/sys/arch/x86/x86

2020-06-06 Thread Simon Burge
"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.

Re: [stos, again] Re: CVS commit: src/sys/arch/amd64

2020-06-04 Thread Kamil Rytarowski
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

Re: [stos, again] Re: CVS commit: src/sys/arch/amd64

2020-06-04 Thread Andrew Doran
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

Re: [stos, again] Re: CVS commit: src/sys/arch/amd64

2020-06-03 Thread Kamil Rytarowski
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

Re: [stos, again] Re: CVS commit: src/sys/arch/amd64

2020-06-03 Thread Andrew Doran
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

Re: [stos, again] Re: CVS commit: src/sys/arch/amd64

2020-06-03 Thread Andrew Doran
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

Re: [stos, again] Re: CVS commit: src/sys/arch/amd64

2020-06-03 Thread Maxime Villard
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

Re: [stos, again] Re: CVS commit: src/sys/arch/amd64

2020-06-03 Thread Maxime Villard
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:

Re: [stos, again] Re: CVS commit: src/sys/arch/amd64

2020-06-02 Thread Kamil Rytarowski
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: > >

Re: [stos, again] Re: CVS commit: src/sys/arch/amd64

2020-06-02 Thread Andrew Doran
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 > >

[stos, again] Re: CVS commit: src/sys/arch/amd64

2020-06-02 Thread Maxime Villard
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:

Re: [stos] Re: CVS commit: src/sys/arch

2020-05-28 Thread Maxime Villard
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

Re: [stos] Re: CVS commit: src/sys/arch

2020-05-28 Thread Andrew Doran
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: > > >

Re: [stos] Re: CVS commit: src/sys/arch

2020-05-28 Thread Maxime Villard
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

Re: [stos] Re: CVS commit: src/sys/arch

2020-05-28 Thread Maxime Villard
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

[stos] Re: CVS commit: src/sys/arch

2020-05-27 Thread Maxime Villard
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

Re: CVS commit: src/sys/arch/aarch64

2020-05-23 Thread Ryo Shimizu
>> 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

Re: CVS commit: src/sys/arch/aarch64

2020-05-23 Thread maya
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:

Re: CVS commit: src/sys/arch/aarch64

2020-05-23 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/arch

2020-05-21 Thread Andrew Doran
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:

Re: CVS commit: src/sys/arch

2020-05-21 Thread Joerg Sonnenberger
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

[cpufunc] Re: CVS commit: src/sys/arch

2020-05-20 Thread Maxime Villard
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

Re: CVS commit: src/sys/arch/xen

2020-05-16 Thread Manuel Bouyer
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 > >

re: CVS commit: src/sys/arch/xen

2020-05-15 Thread matthew green
"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

Re: CVS commit: src/sys/arch/xen/xen

2020-04-13 Thread Manuel Bouyer
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

Re: CVS commit: src/sys/arch/xen/xen

2020-04-09 Thread Frank Kardel
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 [

Re: CVS commit: src/sys/arch/xen/xen

2020-04-05 Thread Manuel Bouyer
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

Re: CVS commit: src/sys/arch/x86/x86

2020-04-02 Thread Kengo NAKAHARA
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

Re: CVS commit: src/sys/arch/arm/sociox

2020-03-20 Thread Jared McNeill
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 +

Re: CVS commit: src/sys/arch/x86/acpi

2020-03-18 Thread Martin Husemann
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 > >

Re: CVS commit: src/sys/arch/x86/acpi

2020-03-18 Thread Yorick Hardy
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   2   3   4   5   6   7   8   9   10   >