On 26/11/2021 13:24, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Fri Nov 26 13:24:28 UTC 2021
Modified Files:
src/sys/dev/tprof: tprof_armv7.c tprof_armv8.c
Log Message:
declare xc
Thanks!
Nick
On 2021/11/20 8:46, Rin Okuyama wrote:
Enable this quirk for "C600/X79 AHCI". Also add commented out quirk
entries for "Bay Trail SATA (AHCI)" and "Mobile AHCI SATA Controller",
for which non-reproducible failures worked around by extra delays have
been reported.
Oops, I meant:
"Mobile AHCI
On 2021/11/09 8:57, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon Nov 8 23:57:23 UTC 2021
Modified Files:
src/sys/arch/arm/sa11x0: sa11x0_irq.S
Log Message:
irq_entry(): Do not clobber fp (= r11), in order not to confuse DDB.
(snip)
XXX
Rewrite
On Sun, 31 Oct 2021 16:23:48 +
Nick Hudson wrote:
> Modified Files:
> src/sys/arch/aarch64/include: cpu.h cpufunc.h db_machdep.h
...
> Log Message:
> Rework Arm (32bit and 64bit) AP startup so that cpu_hatch doesn't sleep.
Hi,
I'm afraid this broke the userland build.
I think
>Module Name: src
>Committed By: macallan
>Date: Sat Oct 30 05:37:39 UTC 2021
>
>Modified Files:
> src/sys/dev/sbus: mgx.c mgxreg.h
>
>Log Message:
>actually mmap() the blitter registers when asked to, while there do some
>magic number reduction
>
>
>To generate a diff of this
On Thu, Oct 21, 2021 at 05:32:28AM +, Shoichi YAMAGUCHI wrote:
> Module Name: src
> Committed By: yamaguchi
> Date: Thu Oct 21 05:32:27 UTC 2021
>
> Modified Files:
> src/sys/dev/pci: virtio.c virtio_pci.c virtiovar.h
>
> Log Message:
> divide setup routine of virtio
Hi,
Thank you for your quick commit!
Thanks,
On 2021/10/18 17:15, Juergen Hannken-Illjes wrote:
Module Name:src
Committed By: hannken
Date: Mon Oct 18 08:15:00 UTC 2021
Modified Files:
src/sys/dev/pci: xmm7360.c
Log Message:
Use a local static variable to hold
hehehe - porn iterators - love it!
On Fri, 15 Oct 2021, Jason Thorpe wrote:
I demand this change be reverted.
(/s)
On Oct 15, 2021, at 11:12 AM, Jared D. McNeill wrote:
Module Name:src
Committed By: jmcneill
Date: Fri Oct 15 18:12:48 UTC 2021
Modified Files:
I demand this change be reverted.
(/s)
> On Oct 15, 2021, at 11:12 AM, Jared D. McNeill wrote:
>
> Module Name: src
> Committed By: jmcneill
> Date: Fri Oct 15 18:12:48 UTC 2021
>
> Modified Files:
> src/sys/arch/x86/x86: tsc.c
>
> Log Message:
> Fix typo in comment:
On Sun, Oct 10, 2021 at 10:44:03PM +0900, Izumi Tsutsui wrote:
> > Module Name:src
> > Committed By: nia
> > Date: Tue Sep 28 06:14:28 UTC 2021
> >
> > Modified Files:
> > src/sys/dev/wscons: wsconsio.h wsmouse.c wsmousevar.h
> >
> > Log Message:
> > wsmouse: add
On 11/10/2021 08:14, Rin Okuyama wrote:
Hi,
On 2021/09/23 15:34, Nick Hudson wrote:
Module Name: src
Committed By: skrll
Date: Thu Sep 23 06:34:00 UTC 2021
Modified Files:
src/sys/arch/aarch64/aarch64: cpufunc.c
src/sys/arch/arm/arm32: cpu.c
Log Message:
Print the
Thanks for quick response. Committed :)
rin
On 2021/10/11 16:27, Nick Hudson wrote:
On 11/10/2021 08:14, Rin Okuyama wrote:
Hi,
On 2021/09/23 15:34, Nick Hudson wrote:
Module Name: src
Committed By: skrll
Date: Thu Sep 23 06:34:00 UTC 2021
Modified Files:
Hi,
On 2021/09/23 15:34, Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Thu Sep 23 06:34:00 UTC 2021
Modified Files:
src/sys/arch/aarch64/aarch64: cpufunc.c
src/sys/arch/arm/arm32: cpu.c
Log Message:
Print the cache information in similar formats
> Module Name: src
> Committed By: nia
> Date: Tue Sep 28 06:14:28 UTC 2021
>
> Modified Files:
> src/sys/dev/wscons: wsconsio.h wsmouse.c wsmousevar.h
>
> Log Message:
> wsmouse: add support for "precision scrolling" events and (GET|SET)PARAMS
Could you please also update
Oops, forgot to mention: No binary changes.
On 2021/10/07 18:58, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Thu Oct 7 09:58:27 UTC 2021
Modified Files:
src/sys/arch/arm/arm: cpufunc_asm_armv5_ec.S
Log Message:
Reduce diff with cpufunc_asm_armv5.S, from
> Date: Wed, 6 Oct 2021 17:44:22 +0200
> From: Reinoud Zandijk
>
> Sorry for my ignorance but I thought that the ksyms list was static? ie
> read-only? Or is this change to support kernel modules symbols too and thus
> need rw access control?
The main kernel's symbols don't change, but the
On Wed, Sep 15, 2021 at 07:58:20PM +0900, Rin Okuyama wrote:
> On 2021/09/11 19:09, Taylor R Campbell wrote:
> > Module Name:src
> > Committed By: riastradh
> > Date: Sat Sep 11 10:09:55 UTC 2021
> >
> > Modified Files:
> > src/sys/arch/sparc64/sparc64: machdep.c
>
Date:Wed, 29 Sep 2021 08:42:12 -0700
From:Jason Thorpe
Message-ID:
| Anything that depends on the new return value would have simply been
| doing what the socket / fifo code was doing (groveling around in
| selinfo internals), so it's not like they're broken
> On Sep 29, 2021, at 8:15 AM, Robert Elz wrote:
>
>Date:Wed, 29 Sep 2021 05:37:44 -0700
>From:Jason Thorpe
>Message-ID: <39db6c46-94bf-4126-811b-466e5293b...@me.com>
>
> | Not needed in this case.
> | No callers that need the return value are in a module.
>
>
Date:Wed, 29 Sep 2021 05:37:44 -0700
From:Jason Thorpe
Message-ID: <39db6c46-94bf-4126-811b-466e5293b...@me.com>
| Not needed in this case.
| No callers that need the return value are in a module.
The problem with this argument is that it assumes that you know
"Jason R Thorpe" writes:
> Module Name: src
> Committed By: thorpej
> Date: Wed Sep 29 02:47:22 UTC 2021
>
> Modified Files:
> src/sys/kern: sys_select.c uipc_socket.c
> src/sys/miscfs/fifofs: fifo_vnops.c
> src/sys/sys: select.h
>
> Log Message:
> - Change
> Module Name: src
> Committed By: skrll
> Date: Thu Sep 23 06:34:00 UTC 2021
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: cpufunc.c
> src/sys/arch/arm/arm32: cpu.c
>
> Log Message:
> Print the cache information in similar formats and arm and aarch64, e.g.
:
>
On 2021/09/22 14:42, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Wed Sep 22 05:42:19 UTC 2021
Modified Files:
src/sys/kern: kern_ksyms.c
Log Message:
ksymsmmap: Add missing uao_reference(9) call for ks->ks_uobj.
Fix failure for savecore(8) and subsequent
Hi,
For alpha, I've observed similar failure with rev 1.104; savecore fails and
panic occurs in pagedaemon after that.
Thanks,
rin
# /etc/rc.d/savecore onestart
Checking for core dump...
savecore: (null): kvm_nlist: bad namelist
savecore: (null): _dumpdev not in namelist
# dd if=/dev/zero
On 2021/09/15 21:55, Taylor R Campbell wrote:
Date: Wed, 15 Sep 2021 19:58:20 +0900
From: Rin Okuyama
login: [ 95.5000696] panic: kernel diagnostic assertion "slock != NULL" failed: file
"../../../../uvm/uvm_pdaemon.c", line 398 pg 0x8c66bd88 uobj 0x8fa7e400, NULL lock
[...]
It seems that I
> Date: Wed, 15 Sep 2021 19:58:20 +0900
> From: Rin Okuyama
>
> login: [ 95.5000696] panic: kernel diagnostic assertion "slock != NULL"
> failed: file "../../../../uvm/uvm_pdaemon.c", line 398 pg 0x8c66bd88 uobj
> 0x8fa7e400, NULL lock
> [...]
>
> It seems that I can avoid this panic if
>
>
Hi,
On 2021/09/11 19:09, Taylor R Campbell wrote:
Module Name:src
Committed By: riastradh
Date: Sat Sep 11 10:09:55 UTC 2021
Modified Files:
src/sys/arch/sparc64/sparc64: machdep.c
src/sys/kern: kern_ksyms.c subr_csan.c subr_msan.c
src/sys/sys: ksyms.h
On 2021/09/08 20:47, Izumi Tsutsui wrote:
Module Name:src
Committed By: rin
Date: Wed Sep 8 07:22:56 UTC 2021
Modified Files:
src/sys/arch/sh3/sh3: pmap.c
Log Message:
Redo a part of rev 1.89:
- Remove redundant parentheses/braces/comments.
- Fix indents.
No binary
> Module Name: src
> Committed By: rin
> Date: Wed Sep 8 07:22:56 UTC 2021
>
> Modified Files:
> src/sys/arch/sh3/sh3: pmap.c
>
> Log Message:
> Redo a part of rev 1.89:
>
> - Remove redundant parentheses/braces/comments.
> - Fix indents.
>
> No binary changes confirmed this
Hi,
On 2021/08/30 18:20, matthew green wrote:
hi.
nice work on BE marvell :)
Thanks!
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Mon Aug 30 00:12:15 UTC 2021
Modified Files:
src/sys/arch/evbarm/conf: MARVELL_NAS
Log Message:
Enable FFS_EI and
hi.
nice work on BE marvell :)
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Mon Aug 30 00:12:15 UTC 2021
>
> Modified Files:
> src/sys/arch/evbarm/conf: MARVELL_NAS
>
> Log Message:
> Enable FFS_EI and DISKLABEL_EI as this SoC supports both endians now.
> On Aug 24, 2021, at 10:21 PM, matthew green wrote:
>
>> - For alpha and sparc64, don't define MUTEX_CAS() in terms of their own
>> _lock_cas(), which has its own memory barriers; the call sites in
>> kern_mutex.c already have the appropriate memory barrier calls. Thus,
>> alpha and
> - For alpha and sparc64, don't define MUTEX_CAS() in terms of their own
> _lock_cas(), which has its own memory barriers; the call sites in
> kern_mutex.c already have the appropriate memory barrier calls. Thus,
> alpha and sparc64 can use default definition.
this seems to leave
On Tue, Aug 17, 2021 at 11:39:26PM +, Taylor R Campbell wrote:
> >
> > Log Message:
> > skip symbol tables that were unloaded again to avoid EFAULT when reading
> > ksyms.
> >
> > also restore TAILQ_FOREACH idiom.
>
> This change isn't quite right: Reading past st = ksyms_last_snapshot
> in
> Module Name:src
> Committed By: mlelstv
> Date: Sun Jul 18 06:57:28 UTC 2021
>
> Modified Files:
> src/sys/kern: kern_ksyms.c
>
> Log Message:
> skip symbol tables that were unloaded again to avoid EFAULT when reading
> ksyms.
>
> also restore TAILQ_FOREACH idiom.
On 2021/08/09 7:26, Rin Okuyama wrote:
- Initialize LIST_HEAD.
Hmm, since HEADs are static, this is not necessary. But, it should be
a good practice to initialize HEADs always, IMO...
Thanks,
rin
Hi,
On 2021/08/06 17:58, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Fri Aug 6 08:58:42 UTC 2021
Modified Files:
src/sys/arch/arm/xscale: i80321_intr.h
Log Message:
Do *NOT* lower IPL in i80321_splraise().
Fix various strange crashes for DIAGNOSTIC
The H6 BSP provides some clues:
#if defined(CONFIG_ARCH_SUN8IW12) \
|| defined(CONFIG_ARCH_SUN8IW15) \
|| defined(CONFIG_ARCH_SUN50IW3) \
|| defined(CONFIG_ARCH_SUN50IW6)
#define SUNXI_UART_FIFO_SIZE256
#elif defined(CONFIG_ARCH_SUN3IW1)
#define
> On Jul 31, 2021, at 3:17 AM, Tobias Nygren wrote:
>
> It's not possible to deduce from the manual what DesignWare revision
> is used but I guess I can go over the data sheets of currently
> released SoCs and build a matrix of the proper values regardless
> of DesignWare revision.
Have the
On Fri, 30 Jul 2021 22:36:45 +0200
Tobias Nygren wrote:
> On Fri, 30 Jul 2021 17:25:46 -0300 (ADT)
> Jared McNeill wrote:
>
> > Why only A20?
>
> It is the hardware I have on hand. If you know specifically which
> SoCs need this, the compat_data array can be extended.
> I guess maybe these
On Fri, 30 Jul 2021 17:25:46 -0300 (ADT)
Jared McNeill wrote:
> Why only A20?
It is the hardware I have on hand. If you know specifically which
SoCs need this, the compat_data array can be extended.
I guess maybe these also?
allwinner,sun4i-a10
allwinner,sun6i-a31
Why only A20?
On Fri, 30 Jul 2021, Tobias Nygren wrote:
Module Name:src
Committed By: tnn
Date: Fri Jul 30 12:46:46 UTC 2021
Modified Files:
src/sys/arch/arm/sunxi: sunxi_platform.c
src/sys/dev/ic: com.c
Log Message:
com(4): fix FIFO for DW_APB on Allwinner
On Mon, Jul 19, 2021 at 01:33:53AM +, David A. Holland wrote:
> Part 3; cvs randomly didn't commit all the files the first time, still
> hunting down the files it skipped.
ok, I'm pretty sure that's the lot.
--
David A. Holland
dholl...@netbsd.org
On 15/07/2021 04:25, Tohru Nishimura wrote:
Module Name:src
Committed By: nisimura
Date: Thu Jul 15 03:25:50 UTC 2021
Modified Files:
src/sys/dev/usb: if_mue.c uchcom.c
Log Message:
explanation typo
To generate a diff of this commit:
cvs rdiff -u -r1.60 -r1.61
On Thu, Jul 01, 2021 at 12:25:51AM -0400, Christos Zoulas wrote:
> Modified Files:
> src/sys/kern: vfs_vnops.c
>
> Log Message:
> don't clear the error before we use it to determine if we are moving or
> duping.
oh ffs...
*goes to soak head*
--
David A. Holland
dholl...@netbsd.org
On 30/06/2021 15:13, Joerg Sonnenberger wrote:
On Tue, Jun 29, 2021 at 11:26:00PM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Tue Jun 29 23:26:00 UTC 2021
Modified Files:
src/sys/external/bsd/compiler_rt/dist/lib/builtins/arm: aeabi_cfcmp.S
On Tue, Jun 29, 2021 at 11:26:00PM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Tue Jun 29 23:26:00 UTC 2021
>
> Modified Files:
> src/sys/external/bsd/compiler_rt/dist/lib/builtins/arm: aeabi_cfcmp.S
> divmodsi4.S divsi3.S modsi3.S
>
> Log
On Tue, 29 Jun 2021, David A. Holland wrote:
Module Name:src
Committed By: dholland
Date: Tue Jun 29 22:39:21 UTC 2021
Modified Files:
src/sys/fs/puffs: puffs_vnops.c
src/sys/fs/union: union_vnops.c
src/sys/fs/unionfs: unionfs_subr.c
On 2021/06/16 19:23, Rin Okuyama wrote:
On 2021/06/16 18:15, Taylor R Campbell wrote:
Date: Wed, 16 Jun 2021 17:38:26 +0900
From: Rin Okuyama
KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
[...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed:
On 2021/06/16 18:15, Taylor R Campbell wrote:
Date: Wed, 16 Jun 2021 17:38:26 +0900
From: Rin Okuyama
KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
[...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file
"/usr/src/sys/dev/pad/pad.c", line 214
> Date: Wed, 16 Jun 2021 17:38:26 +0900
> From: Rin Okuyama
>
> KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
> [...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file
> "/usr/src/sys/dev/pad/pad.c", line 214
Can you share `ident netbsd | grep
Hi,
KASSERT added to pad_attach() by this commit fires on macppc with mixerctl(1):
# cd /usr/tests/usr.bin/mixerctl && atf-run
...
tc-start: ..., nflag
[...] panic: kernel diagnostic assertion "KERNEL_LOCKED_P()" failed: file
"/usr/src/sys/dev/pad/pad.c", line 214
[...] cpu0: Begin
On Wed, 9 Jun 2021, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Wed Jun 9 23:22:51 UTC 2021
Modified Files:
src/sys/dev: dev_verbose.h
Log Message:
Use the localcount(9)-based module_hook mechanism to prevent the verbose
modules' code and data
On 2021/06/08 16:09, nia wrote:
On Tue, Jun 01, 2021 at 09:12:24PM +, Taylor R Campbell wrote:
audio(4): Set AUMODE_PLAY/RECORD only if asked _and_ supported.
If one is requested and _not_ supported, fail; otherwise we might
enter audio_write with a null play track and crash on KASSERT.
On Tue, Jun 01, 2021 at 09:12:24PM +, Taylor R Campbell wrote:
> audio(4): Set AUMODE_PLAY/RECORD only if asked _and_ supported.
>
> If one is requested and _not_ supported, fail; otherwise we might
> enter audio_write with a null play track and crash on KASSERT.
It looks like this is an
Hmm, misleading commit log (code itself is correct). More precisely:
s/the last element of ksyms_symtabs/ksyms_last_snapshot/
Anyway, does this help you to reintroduce
"ksyms(4): Don't skip symbol tables that are soon to be freed."?
That KASSERT does not fire anymore for aarch64, as far as I
> Date: Wed, 2 Jun 2021 17:33:39 +0900
> From: Rin Okuyama
>
> On 2021/06/02 6:11, Taylor R Campbell wrote:
> > - KASSERT(filepos <= sizeof(struct ksyms_hdr) +
> > + KASSERT(filepos == sizeof(struct ksyms_hdr) +
> > ksyms_hdr.kh_shdr[SYMTAB].sh_size);
> ...
>
> This KASSERT fires at
Hi,
On 2021/06/02 6:11, Taylor R Campbell wrote:
Module Name:src
Committed By: riastradh
Date: Tue Jun 1 21:11:52 UTC 2021
Modified Files:
src/sys/kern: kern_ksyms.c
Log Message:
ksyms(4): Don't skip symbol tables that are soon to be freed.
They will not actually be
Correction:
On 2021/06/01 7:10, Rin Okuyama wrote:
On 2021/05/31 23:35, Joerg Sonnenberger wrote:
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
Bump LAST_REGISTER and LAST_RESTORE_REG to REGNO_ARM32_S31 for arm.
This is not desirable as it significantly increases the memory
On 2021/05/31 23:35, Joerg Sonnenberger wrote:
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
Bump LAST_REGISTER and LAST_RESTORE_REG to REGNO_ARM32_S31 for arm.
This is not desirable as it significantly increases the memory use.
The goal here is to actually alias the single and
On 2021/05/31 23:32, Joerg Sonnenberger wrote:
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
There are two numbering schemes for VFPv2 registers: s0-s31 and d0-d15.
The former is used by GCC, and the latter is by LLVM. Since libunwind was
derived from LLVM, it has never supported
On 2021/05/31 23:30, Joerg Sonnenberger wrote:
On Mon, May 31, 2021 at 11:41:22AM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon May 31 11:41:22 UTC 2021
Modified Files:
src/sys/lib/libunwind: Registers.hpp unwind_registers.S
Log Message:
...
-
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
> Bump LAST_REGISTER and LAST_RESTORE_REG to REGNO_ARM32_S31 for arm.
This is not desirable as it significantly increases the memory use.
The goal here is to actually alias the single and double register in the
space. That's what the
On Mon, May 31, 2021 at 12:12:24PM +, Rin Okuyama wrote:
> There are two numbering schemes for VFPv2 registers: s0-s31 and d0-d15.
> The former is used by GCC, and the latter is by LLVM. Since libunwind was
> derived from LLVM, it has never supported the former. This results in
> crashes for
On Mon, May 31, 2021 at 11:41:22AM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Mon May 31 11:41:22 UTC 2021
>
> Modified Files:
> src/sys/lib/libunwind: Registers.hpp unwind_registers.S
>
> Log Message:
> ...
>
> - Introduce enum for flags.
Please
"Rin Okuyama" wrote:
> Module Name: src
> Committed By: rin
> Date: Sun May 30 07:20:00 UTC 2021
>
> Modified Files:
>
> src/sys/arch/arm/include/arm32: param.h
>
> Log Message:
>
> Include opt_param.h for MSGBUFSIZE ifdef _KERNEL_OPT.
Thanks Rin! I thought I had checked all the
In article <20210506061816.94bb1f...@cvs.netbsd.org>,
Shoichi YAMAGUCHI wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: yamaguchi
>Date: Thu May 6 06:18:16 UTC 2021
>
>Modified Files:
> src/sys/net: if_spppsubr.c
>
>Log Message:
>do not clear destination address if there
> Module Name:src
> Committed By: thorpej
> Date: Sat Apr 24 23:37:01 UTC 2021
>
> Log Message:
> Merge thorpej-cfargs branch:
>
> Simplify and make extensible the config_search() / config_found() /
> config_attach() interfaces: rather than having different variants for
> which
> (I haven't investigated exactly what's going on leading to ~5 KB-byte
> stack frames, but this shuts gcc up, at least, and the hypotheses
> sound plausible to me!)
this matches what i saw when looking at it. i was going to
test the exact same idea (noinline).
.mrg.
On Sat, 24 Apr 2021, Robert Elz wrote:
Date:Sat, 24 Apr 2021 00:15:37 +
From:"Michael Lorenz"
Message-ID: <20210424001537.c5c83f...@cvs.netbsd.org>
| add an ioctl() to get a list of fonts currently available via wsfont
It seems to me it would be useful for that
Oh, I see from your code change to wsfontload.c that you intended
for the fi_numentries field to get copied out, it just doesn't seem
to happen.
I also see that the addr==NULL case happens if malloc() (in wsfontload.c)
failed - going ahead with the ioctl() in that case seems like a mistake,
Date:Sat, 24 Apr 2021 00:15:37 +
From:"Michael Lorenz"
Message-ID: <20210424001537.c5c83f...@cvs.netbsd.org>
| add an ioctl() to get a list of fonts currently available via wsfont
It seems to me it would be useful for that ioctl to copyout()
the fi_numentries
On 2021/04/18 0:38, Joerg Sonnenberger wrote:
On Sat, Apr 17, 2021 at 01:25:57PM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sat Apr 17 13:25:57 UTC 2021
Modified Files:
src/sys/arch/powerpc/include/booke: vmparam.h
Log Message:
Sync MAXfoo params
On Sat, Apr 17, 2021 at 01:25:57PM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sat Apr 17 13:25:57 UTC 2021
>
> Modified Files:
> src/sys/arch/powerpc/include/booke: vmparam.h
>
> Log Message:
> Sync MAXfoo params with oea:
>
> MAXTSIZ: 512MB ->
"Christos Zoulas" wrote:
> Module Name: src
> Committed By: christos
> Date: Mon Apr 5 22:52:03 UTC 2021
>
> Modified Files:
>
> src/sys/conf: Makefile.kern.inc
>
> Log Message:
>
> Don't use /usr/bin/time (it is not portable)
Oops, that bit wasn't meant to sneak in. Thanks for
"Rin Okuyama" wrote:
> Module Name: src
> Committed By: rin
> Date: Fri Apr 2 12:11:42 UTC 2021
>
> Log Message:
>
> For ports with __HAVE_LEGACY_INTRCNT, turn intrcnt[] and derived
> variables into u_int, to match with kern/subr_evcnt.c.
Thanks Rin!
Cheers,
Simon.
Ugh. Can we please stop making these hacky one-offs in "shared by all PowerPC
platforms" code? This actually points to a deeper problem in the pmap code
that needs to be addressed correctly.
> On Apr 1, 2021, at 3:02 PM, Michael Lorenz wrote:
>
> Module Name: src
> Committed By: macallan
>
Yes, the binary is mips64-n32. There is no n32 for mips32.
I moved the CPUFLAGS=-n32 assignment to the 64 bit
portion of the Makefile.
christos
> On Mar 16, 2021, at 12:14 AM, matthew green wrote:
>
> "Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Mon Mar 15 18:13:54 UTC 2021
>
> Modified Files:
> src/sys/arch/evbmips/stand/sbmips: Makefile.bootprogs
>
> Log Message:
> - 32 bit mips uses oabi, don't force it to n32.
> - compile assembly code with
matthew green writes:
> could this be done with include and "no foo" statement?
> eg, like sys/arch/sparc/conf/INSTALL does.
Maybe, but I'm not sure it will end up working. Right now we don't know
if any of the missing things will be trouble, and even if we do move to
include/no I'd like to
"Greg Troxel" writes:
> Module Name: src
> Committed By: gdt
> Date: Fri Mar 5 20:30:56 UTC 2021
>
> Modified Files:
> src/sys/arch/amd64/conf: XEN3_DOM0
>
> Log Message:
> XEN3_DOM0: Approach GENERIC
>
> When processed to remove comments, blank lines, normalize whitespace,
> and
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
In article <5912ca9e-b4e7-423d-a45d-f4693d1c9...@zoulas.com>,
Christos Zoulas wrote:
>-=-=-=-=-=-
Here's the final changes
- Make ALIGNED_POINTER use __alignof(t) instead of sizeof(t). This is more
correct because it works with non-primitive types and provides the ABI
alignment for the
> On Feb 17, 2021, at 4:20 PM, Valery Ushakov wrote:
>
> On Wed, Feb 17, 2021 at 17:49:15 -, Christos Zoulas wrote:
>
> This incrementally improves wrong things b/c you still have the "is
> aligned" and "ought to be aligned" conflated in one.
The incremental patch improves things and
On Wed, Feb 17, 2021 at 17:49:15 -, Christos Zoulas wrote:
> In article ,
> Valery Ushakov wrote:
>
> >But to get back to my main point, PLEASE, can we stop making random
> >aimless changes without prior discussion?
>
> Here's the change I'd like to make:
> - pass the alignment instead of
In article ,
Valery Ushakov wrote:
>But to get back to my main point, PLEASE, can we stop making random
>aimless changes without prior discussion?
Here's the change I'd like to make:
- pass the alignment instead of the mask (as Roy asked and to match the
other macro)
- use alignof to
Jared,
please test if the attached diff is sufficient.
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig
uvm_swap.c.diff
Description: Binary data
> On 17. Feb 2021, at 13:07, Jared McNeill wrote:
>
> I noticed this on reboot since this change:
>
> [ 3636.2891122] turning
I noticed this on reboot since this change:
[ 3636.2891122] turning off swap...stopping swap on /swap failed with error 16
[ 3636.2991109] stopping swap on /swap2 failed with error 16
Can you have a look?
Thanks!
Jared
On Tue, 16 Feb 2021, Juergen Hannken-Illjes wrote:
Module Name:
On Tue, Feb 16, 2021 at 18:51:43 -0500, Christos Zoulas wrote:
> On Feb 17, 2:20am, u...@stderr.spb.ru (Valery Ushakov) wrote:
> -- Subject: Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)
>
> | Well, it was you who did the definion of ALIGNED_POINTER centralized
> |
On Wed, Feb 17, 2021 at 00:51:03 +0100, Roland Illig wrote:
> 17.02.2021 00:25:10 Valery Ushakov :
> > On Tue, Feb 16, 2021 at 23:54:46 +0100, Roland Illig wrote:
> >> Yes, it does. That's what the "#undef __NO_STRICT_ALIGNMENT" in the
> >> test is for.
> >>
> >> I intentionally placed it
On Feb 17, 2:20am, u...@stderr.spb.ru (Valery Ushakov) wrote:
-- Subject: Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)
| Well, it was you who did the definion of ALIGNED_POINTER centralized
| and overridable :)
|
| revision 1.400
| date: 2012-01-25 00:03:36 +0400; author: christos
17.02.2021 00:25:10 Valery Ushakov :
> On Tue, Feb 16, 2021 at 23:54:46 +0100, Roland Illig wrote:
>> Yes, it does. That's what the "#undef __NO_STRICT_ALIGNMENT" in the
>> test is for.
>>
>> I intentionally placed it between (which defines that
>> macro on x86 and some other platforms) and
On 16.02.2021 23:32, Jason Thorpe wrote:
On Feb 16, 2021, at 1:56 PM, Roland Illig wrote:
A downside of this test is that the macro from gets only
evaluated at compile time of the test. The test therefore cannot cover
future updates to without being reinstalled itself. But
at least for
On Tue, Feb 16, 2021 at 17:53:09 -0500, Christos Zoulas wrote:
> In this case "type" is a struct and we have __alignof() to handle
> it, but does this give the right answer?
>
> Also ALIGNED_POINTER is not conditional to __NO_STRICT_ALIGNMENT and
> can be overriden (the opposite goes for
On Tue, Feb 16, 2021 at 23:54:46 +0100, Roland Illig wrote:
> On 16.02.2021 23:40, Valery Ushakov wrote:
> > On Tue, Feb 16, 2021 at 22:56:19 +0100, Roland Illig wrote:
> >
> > > On 16.02.2021 19:46, Roy Marples wrote:
> > > > I suggest we change POINTER_ALIGNED_P to accept the alignment value
On 16.02.2021 23:40, Valery Ushakov wrote:
On Tue, Feb 16, 2021 at 22:56:19 +0100, Roland Illig wrote:
On 16.02.2021 19:46, Roy Marples wrote:
I suggest we change POINTER_ALIGNED_P to accept the alignment value we
want rather than the bitwise test we supply, like so:
#define
201 - 300 of 5582 matches
Mail list logo
