Am 30.04.2024 um 11:55 schrieb Izumi Tsutsui:
> Module Name: src
> Committed By: tsutsui
> Date: Tue Apr 30 09:55:46 UTC 2024
>
> Modified Files:
> src/sys/arch/hp300/dev: dma.c
>
> Log Message:
> Fix another fatal typo that prevents dma(4) interrupts.
The buggy code was:
>
Thanks, should take remember this for the future reference.
On Wed, Mar 13, 2024 at 8:59 AM Nick Hudson wrote:
>
> Module Name:src
> Committed By: skrll
> Date: Wed Mar 13 06:59:01 UTC 2024
>
> Modified Files:
> src/sys/arch/evbmips/evbmips: interrupt.c
>
> Log Message:
>
On Thu, Jan 18, 2024 at 06:43:21 +1100, matthew green wrote:
> > Log Message:
> > macppc: enable FFS_EI in GENERIC
> >
> > I'd say it should be enabled for anything with USB.
> >
> > ok macallan
>
> yay. i think we should enable it basically everywhere that it
> is not a space issue.
I think
> Log Message:
> macppc: enable FFS_EI in GENERIC
>
> I'd say it should be enabled for anything with USB.
>
> ok macallan
yay. i think we should enable it basically everywhere that it
is not a space issue. USB is just one common way, but i can
also modify or create my own images anyway, and
> No, that definitely wasn't intentional! I've just reverted
> that. Does that need a pullup for netbsd-10 ?
Thanks for your confirmation.
I have another fix to make GENERIC boot on my 3/60
(disable more several pseudo-devices to shrink binary)
so I'll handle a pullup request with your fix.
Hi Tsutsui,
Izumi Tsutsui wrote:
> simonb@ wrote:
>
> > cvs rdiff -u -r1.187 -r1.188 src/sys/arch/sun3/conf/GENERIC
>
> >> # Veriexec
> >> # include "dev/veriexec.config"
> >> +
> >> +no obmem0 at mainbus? # XX
>
> Is this intentional!?
No, that definitely wasn't
simonb@ wrote:
> Module Name: src
> Committed By: simonb
> Date: Sun Aug 7 02:52:30 UTC 2022
>
> Modified Files:
:
> src/sys/arch/sun3/conf: DISKLESS GENERIC GENERIC3X
:
> Log Message:
> UFS/LFS dirhash:
> - Enable UFS_DIRHASH if the architecture or kernel model specific config
Hi,
Will check and adjust. Thanks for the tip.
On Thu, Dec 14, 2023 at 2:12 AM Valery Ushakov wrote:
>
> On Wed, Dec 13, 2023 at 23:11:35 +, Andrius Varanavicius wrote:
>
> > Module Name: src
> > Committed By: andvar
> > Date: Wed Dec 13 23:11:35 UTC 2023
> >
> > Modified Files:
>
On Wed, Dec 13, 2023 at 23:11:35 +, Andrius Varanavicius wrote:
> Module Name: src
> Committed By: andvar
> Date: Wed Dec 13 23:11:35 UTC 2023
>
> Modified Files:
> src/sys/arch/sparc64/dev: vnet.c
> src/sys/arch/sparc64/sparc64: netbsd32_machdep_13.c
>
> Log Message:
>
Thank you, I should pay attention to that.
On Wed, Oct 25, 2023 at 9:02 AM Nick Hudson wrote:
>
> Module Name:src
> Committed By: skrll
> Date: Wed Oct 25 06:02:14 UTC 2023
>
> Modified Files:
> src/sys/arch/mips/mips: kgdb_machdep.c
>
> Log Message:
> ->
>
>
> To
OK, it makes sense. I will revert the changes. Thanks for your explanations.
On Sun, Oct 8, 2023 at 12:49 PM matthew green wrote:
>
> > I was changing news68k specific code, thus wasn't treating them as
> > common. But I understand the point.
>
> there's a *LOT* of m68k code that is copied
> I was changing news68k specific code, thus wasn't treating them as
> common. But I understand the point.
there's a *LOT* of m68k code that is copied into all the ports
that is almost identical, and should really be shared, but it
not, and changes like can make this harder to share.
ie, while
On Sun, Oct 8, 2023 at 6:56 AM Izumi Tsutsui wrote:
>
> > In this case maybe I should remove all FPSP references (vectors.S,
> > locore.S, Makefile.news68k (MD_LIBS={FPSP})?
>
> IMO we don't have to keep strict consistencies or buildabilities of
> options but rather should consider readabilities
> In this case maybe I should remove all FPSP references (vectors.S,
> locore.S, Makefile.news68k (MD_LIBS={FPSP})?
IMO we don't have to keep strict consistencies or buildabilities of
options but rather should consider readabilities and maintainabilities.
- options FPSP in a config file is not
In this case maybe I should remove all FPSP references (vectors.S,
locore.S, Makefile.news68k (MD_LIBS={FPSP})?
On Sun, Oct 1, 2023 at 10:08 PM Izumi Tsutsui wrote:
>
> > Module Name: src
> > Committed By: andvar
> > Date: Sun Oct 1 18:50:53 UTC 2023
> >
> > Modified Files:
> >
> Module Name: src
> Committed By: andvar
> Date: Sun Oct 1 18:50:53 UTC 2023
>
> Modified Files:
> src/sys/arch/news68k/conf: Makefile.news68k
>
> Log Message:
> include fpsp Makefile.inc in Makefile.news68k, same as other m68k ports.
>
> needed for FPSP option to build,
Hi,
Oops, I didn't notice it is not generated. Sorry for bothering you!
Thanks,
rin
On Mon, Sep 4, 2023 at 10:46 PM Andrius V wrote:
>
> Hi,
>
> Thanks for the note. I honestly wasn't aware that we have generated
> configs and will be more careful in changing them in the future to
> account
Hi,
Thanks for the note. I honestly wasn't aware that we have generated
configs and will be more careful in changing them in the future to
account that.
However, MDINSTALL config seems to be some older/legacy config, which
was not generated from GENERIC.in, I believe. I may try to transform
into
Hi,
On 2023/08/31 5:17, Andrius Varanavicius wrote:
Module Name:src
Committed By: andvar
Date: Wed Aug 30 20:17:06 UTC 2023
Modified Files:
src/sys/arch/amiga/conf: MDINSTALL
Log Message:
s/Piccalo/Piccolo/ in device description.
Some ports including amiga use
On Tue, Aug 08, 2023 at 04:01:19PM +1000, matthew green wrote:
> Joerg Sonnenberger writes:
> > On Thu, Aug 03, 2023 at 08:16:31AM +, matthew green wrote:
> > > Module Name: src
> > > Committed By: mrg
> > > Date: Thu Aug 3 08:16:31 UTC 2023
> > >
> > > Modified Files:
>
Joerg Sonnenberger writes:
> On Thu, Aug 03, 2023 at 08:16:31AM +, matthew green wrote:
> > Module Name:src
> > Committed By: mrg
> > Date: Thu Aug 3 08:16:31 UTC 2023
> >
> > Modified Files:
> > src/sys/arch/evbarm/gumstix: gumstix_machdep.c
> >
On 2023/08/04 20:18, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Fri Aug 4 11:18:18 UTC 2023
Modified Files:
src/sys/arch/sun2/dev: sc_mbmem.c
Log Message:
sun2/sc(4): Fix panic due to wrong ENOMEM for DMA buffer
Use kmem_zalloc(9) for
On Thu, Aug 03, 2023 at 08:16:31AM +, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Thu Aug 3 08:16:31 UTC 2023
>
> Modified Files:
> src/sys/arch/evbarm/gumstix: gumstix_machdep.c
> src/sys/arch/evbarm/ixm1200: ixm1200_machdep.c
>
On 2023/07/24 16:14, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Mon Jul 24 01:56:59 UTC 2023
Modified Files:
src/sys/arch/i386/stand/efiboot: Makefile.efiboot eficons.c
Added Files:
src/sys/arch/i386/stand/efiboot:
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Mon Jul 24 01:56:59 UTC 2023
>
> Modified Files:
> src/sys/arch/i386/stand/efiboot: Makefile.efiboot eficons.c
> Added Files:
> src/sys/arch/i386/stand/efiboot: eficpufunc.c eficpufunc.h
>
> Log Message:
>
Emmanuel Dreyfus writes:
> On Thu, Jun 29, 2023 at 08:43:36PM -0400, Greg Troxel wrote:
>> > Primary bootstrap is now able to read a GPT inside RAIDframe.
>> did you also update documentation?
>
> We do not have any documentation specific to primary bootstrap.
> x86/boot(8) domuent the behavior
On Thu, Jun 29, 2023 at 08:43:36PM -0400, Greg Troxel wrote:
> > Primary bootstrap is now able to read a GPT inside RAIDframe.
> did you also update documentation?
We do not have any documentation specific to primary bootstrap.
x86/boot(8) domuent the behavior with no detail about primary
and
"Emmanuel Dreyfus" writes:
> Log Message:
> Primary bootstrap is now able to read a GPT inside RAIDframe.
did you also update documentation?
On Mon, Feb 20, 2023 at 15:41:04 +0100, Martin Husemann wrote:
> On Mon, Feb 20, 2023 at 05:15:33PM +0300, Valery Ushakov wrote:
> > them up, b/c you cannot amend that comment. To add to the fun, I
> > think releng scripts just clone the commit message on pull ups, so
> > that comment gets
On Mon, Feb 20, 2023 at 22:35:40 +0700, Robert Elz wrote:
> Date:Mon, 20 Feb 2023 16:47:01 +0300
> From:Valery Ushakov
> Message-ID:
>
> | I wonder if we should stop abusing commit messages as pull-up
> | reminders. These XXX will not convey any useful
Date:Mon, 20 Feb 2023 16:47:01 +0300
From:Valery Ushakov
Message-ID:
| I wonder if we should stop abusing commit messages as pull-up
| reminders. These XXX will not convey any useful information a few
| months down the line...
I think they're useful (if only
On Mon, Feb 20, 2023 at 05:15:33PM +0300, Valery Ushakov wrote:
> them up, b/c you cannot amend that comment. To add to the fun, I
> think releng scripts just clone the commit message on pull ups, so
> that comment gets splattered all over the target branches too.
Yes - I try to manually remove
On Mon, Feb 20, 2023 at 13:57:32 +, Taylor R Campbell wrote:
> > > XXX pullup-8
> > > XXX pullup-9
> > > XXX pullup-10
> >
> > I wonder if we should stop abusing commit messages as pull-up
> > reminders. These XXX will not convey any useful information a few
> > months down the line...
>
>
> Date: Mon, 20 Feb 2023 16:47:01 +0300
> From: Valery Ushakov
>
> On Mon, Feb 20, 2023 at 13:30:23 +, Taylor R Campbell wrote:
>
> > Module Name:src
> > Committed By: riastradh
> > Date: Mon Feb 20 13:30:23 UTC 2023
> >
> > Modified Files:
> >
On Mon, Feb 20, 2023 at 13:30:23 +, Taylor R Campbell wrote:
> Module Name: src
> Committed By: riastradh
> Date: Mon Feb 20 13:30:23 UTC 2023
>
> Modified Files:
> src/sys/arch/sparc64/sparc64: lock_stubs.s
>
> Log Message:
> sparc64: Add missing LoadStore ordering for
On 2022/10/04 16:38, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Tue Oct 4 07:24:32 UTC 2022
Modified Files:
src/sys/arch/amiga/dev: ser.c
src/sys/arch/sgimips/dev: scn.c
Log Message:
Remove unused extern declaration of
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Tue Oct 4 07:24:32 UTC 2022
>
> Modified Files:
> src/sys/arch/amiga/dev: ser.c
> src/sys/arch/sgimips/dev: scn.c
>
> Log Message:
> Remove unused extern declaration of constty.
thank you.
can someone
> Module Name:src
> Committed By: riastradh
> Date: Sun Sep 25 07:50:32 UTC 2022
>
> Modified Files:
> src/sys/arch/arm/ti: ti_fb.c ti_lcdc.c
>
> Log Message:
> tilcdc(4): Set is_console on the drm device, not the fb child.
>
> The drm device is represented by a
> Module Name:src
> Committed By: riastradh
> Date: Sun Sep 25 07:50:23 UTC 2022
>
> Modified Files:
> src/sys/arch/arm/sunxi: sunxi_drm.c sunxi_fb.c
>
> Log Message:
> sunxidrm: Set is_console on the drm device, not the fb child.
>
> The drm device is represented by a
At Tue, 26 Jul 2022 09:52:40 -0700,
Chuck Silvers wrote:
> > This commit breaks usr.sbin/crash on m68k.
> > curlwp is defined only in _KERNEL. usr.sbin/crash defines _KMEMUSER
> > but not _KERNEL.
> >
> > Would you look into?
>
> I fixed it now, sorry about that.
Thank you!
---
Tetsuya Isaki
On Tue, Jul 26, 2022 at 05:25:01PM +0900, Tetsuya Isaki wrote:
> At Mon, 25 Jul 2022 01:59:26 +,
> Chuck Silvers wrote:
> > Module Name:src
> > Committed By: chs
> > Date: Mon Jul 25 01:59:26 UTC 2022
> >
> > Modified Files:
> > src/sys/arch/m68k/m68k:
At Mon, 25 Jul 2022 01:59:26 +,
Chuck Silvers wrote:
> Module Name: src
> Committed By: chs
> Date: Mon Jul 25 01:59:26 UTC 2022
>
> Modified Files:
> src/sys/arch/m68k/m68k: db_trace.c
>
> Log Message:
> use the pcb of the thread we are tracing rather than always curlwp.
>
>
"Taylor R Campbell" writes:
> Module Name: src
> Committed By: riastradh
> Date: Sun Jul 24 20:28:32 UTC 2022
>
> Modified Files:
> src/sys/arch/aarch64/include: lock.h
>
> Log Message:
> aarch64/lock.h: Need for _HARDKERNEL.
>
> Add include guard while here.
>
> XXX Why does this
> Modified Files:
> src/sys/arch/atari/dev: kbd.c
>
> Log Message:
> gcc is not smart enough to track the equivalence of conditions used
> here and warns about an unused value - initialize "code" always.
Umm, complains only with -Os ...
Anyway thanks for fixing.
---
Izumi Tsutsui
I wrote:
> Module Name: src
> Committed By: tsutsui
> Date: Sat Jun 25 03:18:38 UTC 2022
>
> Modified Files:
> src/sys/arch/x68k/dev: ite.c ite_tv.c itevar.h
>
> Log Message:
> Add a minimum box drawing character support for x68k ite(4).
Ah, I committed a wrong branch so these
Oops, I missed it. I will fix soon.
Thanks again,
rin
On 2022/05/07 17:24, Valery Ushakov wrote:
On Sat, May 07, 2022 at 04:12:55 +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sat May 7 04:12:55 UTC 2022
Modified Files:
src/sys/arch/evbppc/dht:
On Sat, May 07, 2022 at 04:12:55 +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sat May 7 04:12:55 UTC 2022
>
> Modified Files:
> src/sys/arch/evbppc/dht: locore.S
> src/sys/arch/powerpc/include: spr.h
>
> Log Message:
> Instead of hard-coding
> Module Name: src
> Committed By: mlelstv
> Date: Mon Apr 25 15:12:07 UTC 2022
>
> Modified Files:
> src/sys/arch/x68k/stand/boot: conf.c
> src/sys/arch/x68k/stand/xxboot: Makefile.xxboot xx.c
>
> Log Message:
> libsa now needs ioctl to support media with large sectors.
On 2022/04/25 23:03, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon Apr 25 14:03:15 UTC 2022
Modified Files:
src/sys/arch/amiga/stand/bootblock/elf2bb: chksum.c elf2bb.c
Log Message:
Use htobe{16,32}(9) instead of be{16,32}toh(9) where appropriate.
No
Emmanuel Dreyfus wrote:
> In src/sys/arch/i386/stand/lib/biosdisk.c
> int
> biosdisk_findpartition(int biosdev, daddr_t sector,
>int *partition, const char **part_name)
> {
> (...)
> /* default ot first partition */
> *partition = 0;
> *part_name =
Emmanuel Dreyfus wrote:
> On Mon, Dec 27, 2021 at 01:08:15PM +1100, Simon Burge wrote:
> > What crash did this fix? All the use of part_name by the
> > called functions should check if it is NULL before trying
> > to assign anything to *part_name.
>
> I do not recall the details now, but I had a
On Mon, Dec 27, 2021 at 01:08:15PM +1100, Simon Burge wrote:
> What crash did this fix? All the use of part_name by the
> called functions should check if it is NULL before trying
> to assign anything to *part_name.
I do not recall the details now, but I had a crash because
of this. Please
Hi Emmanuel,
"Emmanuel Dreyfus" wrote:
> Module Name: src
> Committed By: manu
> Date: Thu Nov 18 16:18:13 UTC 2021
>
> Modified Files:
>
> src/sys/arch/i386/stand/efiboot: devopen.c
>
> Log Message:
>
> Fix crash because of NULL pointer reference
What crash did this fix? All
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
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 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
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
> 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/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.
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
"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
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 ->
"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
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
1 - 100 of 1705 matches
Mail list logo
