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
bus_dmatag_s
"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 XEN3PAE
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:
> > src/sys/arch/arm/sunxi
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() rather
> 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 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
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 wro
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 != &emul_netbsd) instead of
nice, this is a st
"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 != &emul_netbsd) instead of
nice, this is a step forward.
an optimisation on it co
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]
> cvsweb.netbsd.
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 th
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
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
> sr
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
>> 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 +1,
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 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
> 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 curpc
"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 nee
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 like
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:
src/sys/arch/amiga/ami
> 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 req
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.
>
> Ho
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 ``
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
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 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
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 s
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.
Min
"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 st
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
>
> it'
> 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
> [...]
> + KASSERT(req->rxreq
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
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.
>
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:
> >>
> >>src/sys
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 preprocess
"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.
Surely
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 t
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 des
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 becaus
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 08:41:53A
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 do
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 and
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: cpu
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
> > 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: syzbot+6dd5a230d19f0cbc7...@syzk
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
Modifie
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
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
src
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 annotat
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: cpu
> 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 vm_machd
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: acp
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 lapic
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
preemption-s
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
> > src/sys/arch/xen/x86
"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 to
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
[ 2
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
+ "so
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
Hi --
Is there really a need for all of this fdt stuff for SCA2A11? I would
expect that the board can be fully supported in ACPI mode.
Thanks,
Jared
On Wed, 18 Mar 2020, Tohru Nishimura wrote:
Module Name:src
Committed By: nisimura
Date: Wed Mar 18 08:49:51 UTC 2020
Modifi
On Tue, Mar 17, 2020 at 10:38:14PM +, Andrew Doran wrote:
> Log Message:
> - Change some expensive checks DEBUG -> DIAGNOSTIC.
That was meant to be the other way around, oops.
Andrew
On Mon, Mar 16, 2020 at 08:17:58AM +, Tohru Nishimura wrote:
> Module Name: src
> Committed By: nisimura
> Date: Mon Mar 16 08:17:58 UTC 2020
>
> Modified Files:
> src/sys/arch/evbarm/conf: GENERIC64 files.generic64
>
> Log Message:
> include files.sociox for generic64
>
>
>
At Mon, 16 Mar 2020 19:09:34 +,
Nia Alarie wrote:
> Module Name: src
> Committed By: nia
> Date: Mon Mar 16 19:09:34 UTC 2020
>
> Modified Files:
> src/sys/arch/i386/conf: GENERIC
> src/sys/arch/macppc/conf: GENERIC
> src/sys/arch/sparc64/conf: GENERIC
>
> Log Messa
On Sun, Mar 15, 2020 at 11:38:03AM +1100, matthew green wrote:
> "Andrew Doran" writes:
> > Module Name:src
> > Committed By: ad
> > Date: Sat Mar 14 13:34:44 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/sparc/sparc: intr.c
> >
> > Log Message:
> > sparc cpu_i
> On Mar 14, 2020, at 8:10 PM, Jason Thorpe wrote:
>
> redundant things (e.g. extent vs vmem)
In case this wasn't obvious, I favor ejecting extent in favor of vmem.
-- thorpej
> On Mar 14, 2020, at 7:57 PM, Rin Okuyama wrote:
>
> I think that we can no longer support 4MB system because of (2); hangs
> due to (2) are much more serious for 4MB system than it is in 7MB system.
> Modern kernel allocates too much things on demand rather than statically
> allocating them
(added port-sun2 and thorpej)
On 2020/03/08 17:40, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Sun Mar 8 06:25:10 UTC 2020
Modified Files:
src/sys/arch/sun2/conf: GENERIC
Log Message:
Retire md(4) in favor of tmpfs provided by mo
"Andrew Doran" writes:
> Module Name: src
> Committed By: ad
> Date: Sat Mar 14 13:34:44 UTC 2020
>
> Modified Files:
> src/sys/arch/sparc/sparc: intr.c
>
> Log Message:
> sparc cpu_intr_p(): try to work around l_cpu not being set early on by
> using curcpu().
ah, good idea. this
> 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
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Sun Mar 8 06:25:10 UTC 2020
>
> Modified Files:
> src/sys/arch/sun2/conf: GENERIC
>
> Log Message:
> Retire md(4) in favor of tmpfs provided by module,
> though both are not useful for 8MB RAM system...
hi Rin.
On 21/02/2020 23:27, Maya Rashish wrote:
[...]
Index: src/sys/arch/arm/arm32/bus_dma.c
diff -u src/sys/arch/arm/arm32/bus_dma.c:1.118
src/sys/arch/arm/arm32/bus_dma.c:1.119
--- src/sys/arch/arm/arm32/bus_dma.c:1.118 Tue Nov 5 10:21:31 2019
+++ src/sys/arch/arm/arm32/bus_dma.cFri Feb 2
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
101 - 200 of 1962 matches
Mail list logo
