Re: CVS commit: src/sys/arch/evbmips/evbmips
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: > Remove #ifdef DIAGNOSTIC by using __diagused. NFCI. > > > To generate a diff of this commit: > cvs rdiff -u -r1.26 -r1.27 src/sys/arch/evbmips/evbmips/interrupt.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src/sys/arch/macppc/conf
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 the size impact should be trivial (though I didn't measure). The option basically guards just a couple dozens of "bit test plus bswap call" snippets. > USB is just one common way, but i can also modify or create my own > images anyway, and maybe copy them over the network to my machine > with USB...or maybe i'll setup the disk on this machine's scsi for > that machine ;) Yeah. I just didn't want to open that can of yaks to shave... :) -uwe
re: CVS commit: src/sys/arch/macppc/conf
> 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 maybe copy them over the network to my machine with USB...or maybe i'll setup the disk on this machine's scsi for that machine ;)
Re: CVS commit: src/sys/arch
> 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. --- Izumi Tsutsui
Re: CVS commit: src/sys/arch
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 intentional! I've just reverted that. Does that need a pullup for netbsd-10 ? Cheers, Simon.
Re: CVS commit: src/sys/arch
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 > file can use 128MB of RAM or more. > - Remove experimental tag from UFS_DIRHASH; it's been with RUMP kernel > and by a number of NetBSD developers for years. > - Add LFS_DIRHASH if LFS was enabled. > - Be somewhat consistent with FS options order. : > 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!? --- Izumi Tsutsui
Re: CVS commit: src/sys/arch/sparc64
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: > > src/sys/arch/sparc64/dev: vnet.c > > src/sys/arch/sparc64/sparc64: netbsd32_machdep_13.c > > > > Log Message: > > Add #ifdef DDB blocks around Debugger(); calls to make kernel build without > > DDB. > > May be use console_debugger() that from a quick look seems to do the > right thing already (including db_fromconsole guard)? > > -uwe >
Re: CVS commit: src/sys/arch/sparc64
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: > Add #ifdef DDB blocks around Debugger(); calls to make kernel build without > DDB. May be use console_debugger() that from a quick look seems to do the right thing already (including db_fromconsole guard)? -uwe
Re: CVS commit: src/sys/arch/mips/mips
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 generate a diff of this commit: > cvs rdiff -u -r1.21 -r1.22 src/sys/arch/mips/mips/kgdb_machdep.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. >
Re: CVS commit: src/sys/arch/news68k/conf
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 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 it might appear news68k specific, ideally most of it > would end up in arch/m68k instead. > > it would really be far better for that merge, than to worry > about obscure compile options -- there's a real cost when we > have platform changes to make, and 10 m68k copies are needed > instead of 1. we've done some of this over time (for not > just m68k) but there's quite a lot of left here.. > > thanks. > > > .mrg.
re: CVS commit: src/sys/arch/news68k/conf
> 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 it might appear news68k specific, ideally most of it would end up in arch/m68k instead. it would really be far better for that merge, than to worry about obscure compile options -- there's a real cost when we have platform changes to make, and 10 m68k copies are needed instead of 1. we've done some of this over time (for not just m68k) but there's quite a lot of left here.. thanks. .mrg.
Re: CVS commit: src/sys/arch/news68k/conf
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 and maintainabilities.
>
> - options FPSP in a config file is not necessary for users on news68k
> (unless some users build own 040/060 upgrade mod like x68k)
Yes, that's understandable and true. However, if someone would have a
mod, he would need to understand why FPSP build fails in the first
place.
I just wanted to avoid confusion, that code has ifdef blocks, but
there's no way to build it.
> - #ifdef FPSP (and other m68k specific options) blocks in common
> sources might help to check diffs from other m68k ports
I was changing news68k specific code, thus wasn't treating them as
common. But I understand the point.
I can return FPSP block in vectors.s, if that helps with readability
and maintainability.
However, those copy pasted common files usually diverge between ports
(from what I've seen),
makes it difficult to understand what is still common and what is the
"latest" code at times (likely not in this case).
> - In the perfect world, we should have a common m68k/locore.s etc.
>and move port specific blocks into locore_machdep.s like mips,
>but m68k CPUs are too flexible and all m68k ports have too many
>historical difficulties to refactor them
I admit I went a bit impatient this time without waiting for the
proper answer. I am OK to settle with the best option in the context,
either revert everything to original state, keep partial changes or
leave current state. Sorry for this.
>
> I don't mind your changes in this case, but it's appreciated
> to ask design considerations before changes, as you did for mmeye.
>
> Thanks,
> ---
> Izumi Tsutsui
Re: CVS commit: src/sys/arch/news68k/conf
> 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 necessary for users on news68k
(unless some users build own 040/060 upgrade mod like x68k)
- #ifdef FPSP (and other m68k specific options) blocks in common
sources might help to check diffs from other m68k ports
- In the perfect world, we should have a common m68k/locore.s etc.
and move port specific blocks into locore_machdep.s like mips,
but m68k CPUs are too flexible and all m68k ports have too many
historical difficulties to refactor them
I don't mind your changes in this case, but it's appreciated
to ask design considerations before changes, as you did for mmeye.
Thanks,
---
Izumi Tsutsui
Re: CVS commit: src/sys/arch/news68k/conf
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:
> > 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, otherwise FPSP specific vectors are
> > undefined.
>
> FPSP is neccesary only for 68040 (and 68060) and
> there is no 040 NEWS machines. That's the reason
> why news68k doesn't include fpsp.
>
> ---
> Izumi Tsutsui
Re: CVS commit: src/sys/arch/news68k/conf
> 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, otherwise FPSP specific vectors are > undefined. FPSP is neccesary only for 68040 (and 68060) and there is no 040 NEWS machines. That's the reason why news68k doesn't include fpsp. --- Izumi Tsutsui
Re: CVS commit: src/sys/arch/amiga/conf
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 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 generated one though, if there's a need for that. I guess RAMDISK > has somewhat similar purpose. > > > On Mon, Sep 4, 2023 at 12:17 PM Rin Okuyama wrote: > > > > 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 arch/foo/conf/*.in to generate > > kernel config files. Please fix *.in and regen them. > > > > Thanks, > > rin
Re: CVS commit: src/sys/arch/amiga/conf
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 generated one though, if there's a need for that. I guess RAMDISK has somewhat similar purpose. On Mon, Sep 4, 2023 at 12:17 PM Rin Okuyama wrote: > > 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 arch/foo/conf/*.in to generate > kernel config files. Please fix *.in and regen them. > > Thanks, > rin
Re: CVS commit: src/sys/arch/amiga/conf
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 arch/foo/conf/*.in to generate kernel config files. Please fix *.in and regen them. Thanks, rin
Re: CVS commit: src/sys/arch
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: > > > src/sys/arch/evbarm/gumstix: gumstix_machdep.c > > > src/sys/arch/evbarm/ixm1200: ixm1200_machdep.c > > > src/sys/arch/hpcarm/hpcarm: pxa2x0_hpc_machdep.c sa11x0_hpc_machdep.c > > > src/sys/arch/hppa/stand: Makefile.buildboot > > > src/sys/arch/m68k/m68k: regdump.c > > > src/sys/arch/macppc/macppc: cpu.c > > > > > > Log Message: > > > ignore "-Warray-bounds" for various low level platform code that knows > > > how something is setup but technically is undefined behaviour. the > > > most common here is "extern int end;" and then using offsets of "" > > > that are outside the bounds of this 4-byte integer. > > > > > > these uses are almost certainly all OK in reality. > > > > Are you sure that GCC's optimizer is not going to break any of those > > assumptions? We had to go through quite some trouble in crtbegin.c for > > similar patterns? > > nope, infact i'm not. i'll revert these. > > do you have good ways to fix these from that crt issue? Not really, I just remember that we needed a few iterations. The last round was especially mysterious as weak references suddenly couldn't alias extern symbol. Joerg
re: CVS commit: src/sys/arch
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 > > src/sys/arch/evbarm/ixm1200: ixm1200_machdep.c > > src/sys/arch/hpcarm/hpcarm: pxa2x0_hpc_machdep.c sa11x0_hpc_machdep.c > > src/sys/arch/hppa/stand: Makefile.buildboot > > src/sys/arch/m68k/m68k: regdump.c > > src/sys/arch/macppc/macppc: cpu.c > > > > Log Message: > > ignore "-Warray-bounds" for various low level platform code that knows > > how something is setup but technically is undefined behaviour. the > > most common here is "extern int end;" and then using offsets of "" > > that are outside the bounds of this 4-byte integer. > > > > these uses are almost certainly all OK in reality. > > Are you sure that GCC's optimizer is not going to break any of those > assumptions? We had to go through quite some trouble in crtbegin.c for > similar patterns? nope, infact i'm not. i'll revert these. do you have good ways to fix these from that crt issue? thanks. .mrg.
Re: CVS commit: src/sys/arch/sun2/dev
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 sc->sc_dma_handles[] to zero-initialize flags. XXX Will soon apply to sun3. Correction: sun3 is not affected. "sc(4) at vme(4)" has been fixed.
Re: CVS commit: src/sys/arch
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 > src/sys/arch/hpcarm/hpcarm: pxa2x0_hpc_machdep.c sa11x0_hpc_machdep.c > src/sys/arch/hppa/stand: Makefile.buildboot > src/sys/arch/m68k/m68k: regdump.c > src/sys/arch/macppc/macppc: cpu.c > > Log Message: > ignore "-Warray-bounds" for various low level platform code that knows > how something is setup but technically is undefined behaviour. the > most common here is "extern int end;" and then using offsets of "" > that are outside the bounds of this 4-byte integer. > > these uses are almost certainly all OK in reality. Are you sure that GCC's optimizer is not going to break any of those assumptions? We had to go through quite some trouble in crtbegin.c for similar patterns? Joerg
Re: CVS commit: src/sys/arch/i386/stand/efiboot
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: eficpufunc.c eficpufunc.h Log Message: efiboot/x86: Add serial console support via raw I/O port access thanks! this makes efiboot capable of replacing bios on many of my test systems that can use serial console (and often do.) Thank you too for your feedback! I'm glad to hear that :) rin
re: CVS commit: 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: > efiboot/x86: Add serial console support via raw I/O port access thanks! this makes efiboot capable of replacing bios on many of my test systems that can use serial console (and often do.) .mrg.
Re: CVS commit: src/sys/arch/i386/stand/bootxx
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 with no detail about primary > and secondary bootstrap distinct roles. > > The change makes primary bootstrap behavior in line with secondary > bootstrap and with what is already documented in x86/boot(8). Hence > there is no documentation update, we could consider it as a bug fix, > since the previosu behavior did not match x86/boot(8) documentation. Thank you for explaining. That sounds fine then.
Re: CVS commit: src/sys/arch/i386/stand/bootxx
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 secondary bootstrap distinct roles. The change makes primary bootstrap behavior in line with secondary bootstrap and with what is already documented in x86/boot(8). Hence there is no documentation update, we could consider it as a bug fix, since the previosu behavior did not match x86/boot(8) documentation. -- Emmanuel Dreyfus m...@netbsd.org
Re: CVS commit: src/sys/arch/i386/stand/bootxx
"Emmanuel Dreyfus" writes: > Log Message: > Primary bootstrap is now able to read a GPT inside RAIDframe. did you also update documentation?
Re: CVS commit: src/sys/arch/sparc64/sparc64
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 splattered all over the target branches too. > > Yes - I try to manually remove them (which is easy if they are at the > end of the last commit log in the batch) durint the pullup. Data point: $ hg log -b netbsd-9 | grep 'XXX.*pullup.*9' | wc -l 74 -uwe
Re: CVS commit: src/sys/arch/sparc64/sparc64
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 information a few > | months down the line... > > I think they're useful (if only I remembered to add them all the > times I should) - it allows someone looking at the commit log to > easily determine that the change is also intended for another branch. > Then one can check and see if it happened or not, and if not, send > a reminder if it is important/needed. > > If the pullup annotation is missing, I tend to assume that the change > is not intended to be pulled up - either it isn't applicable, or is > something new that isn't appropriate for older releases. > > That's why I will sometimes even include pullup annotations for ancient > versions of NetBSD, even though I know they will never happen (never get > submitted, much less acted upon) - just as an indication that the problem > being fixed exists from long ago. In that case they have no business being "XXX" :) -uwe
Re: CVS commit: src/sys/arch/sparc64/sparc64
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 I remembered to add them all the times I should) - it allows someone looking at the commit log to easily determine that the change is also intended for another branch. Then one can check and see if it happened or not, and if not, send a reminder if it is important/needed. If the pullup annotation is missing, I tend to assume that the change is not intended to be pulled up - either it isn't applicable, or is something new that isn't appropriate for older releases. That's why I will sometimes even include pullup annotations for ancient versions of NetBSD, even though I know they will never happen (never get submitted, much less acted upon) - just as an indication that the problem being fixed exists from long ago. kre
Re: CVS commit: src/sys/arch/sparc64/sparc64
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 them (which is easy if they are at the end of the last commit log in the batch) durint the pullup. Martin
Re: CVS commit: src/sys/arch/sparc64/sparc64
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... > > Happy to try a better mechanism if you have suggestions, but this is > the best one I've found so far! If I don't mark commits this way, I'm > almost guaranteed not to pull them up. I'm not sure any exists even with modern VCS. May be something like a branch that is not closed until it is merged (pulled-up) to all the intended destination (but then the very notion of the closed branch requires something more modern than CVS). The problem with the XXX in the commit message is that you don't easily know if you _did_ pull 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. -uwe
Re: CVS commit: src/sys/arch/sparc64/sparc64
> 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: > > src/sys/arch/sparc64/sparc64: lock_stubs.s > > > > Log Message: > > sparc64: Add missing LoadStore ordering for mutex_enter stub. > > > > 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... Happy to try a better mechanism if you have suggestions, but this is the best one I've found so far! If I don't mark commits this way, I'm almost guaranteed not to pull them up.
Re: CVS commit: src/sys/arch/sparc64/sparc64
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 mutex_enter stub. > > 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... -uwe
Re: CVS commit: src/sys/arch
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 constty. thank you. Welcome! can someone please find all the "extern ;" in .c files, and move them all into .h files. Well, it should be a tough work ;) % cd /usr/src/sys && find . -name '*.c' | grep -v /external/ | xargs grep 'extern[ ]' | wc -l 4170 Thanks, rin
re: CVS commit: src/sys/arch
"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 please find all the "extern ;" in .c files, and move them all into .h files. please. .mrg.
Re: CVS commit: src/sys/arch/arm/ti
> 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 rockchip,display-subsystem node in > the device tree. The fb child is a purely software abstraction used > by drm. This was supposed to read: The drm device is represented by a ti,am33xx-tilcdc node in the device tree. The fb child is a purely software abstraction used by drm.
Re: CVS commit: src/sys/arch/arm/sunxi
> 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 rockchip,display-subsystem node in > the device tree. The fb child is a purely software abstraction used > by drm. This was supposed to read: The drm device is represented by an allwinner,sun*i-*-display-engine node in the device tree. The fb child is a purely software abstraction used by drm.
Re: CVS commit: src/sys/arch/m68k/m68k
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
Re: CVS commit: src/sys/arch/m68k/m68k
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: db_trace.c > > > > Log Message: > > use the pcb of the thread we are tracing rather than always curlwp. > > > > > > To generate a diff of this commit: > > cvs rdiff -u -r1.59 -r1.60 src/sys/arch/m68k/m68k/db_trace.c > > 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. -Chuck
Re: CVS commit: 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. > > > To generate a diff of this commit: > cvs rdiff -u -r1.59 -r1.60 src/sys/arch/m68k/m68k/db_trace.c 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? Thanks, --- Tetsuya Isaki
re: CVS commit: src/sys/arch/aarch64/include
"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 aarch64-specific file have #ifdef __aarch64__? there're __aarch32__ / __arm32__ environments that supported on arm64 hosts. (clang better than gcc.) .mrg.
Re: CVS commit: src/sys/arch/atari/dev
> 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
Re: CVS commit: src/sys/arch/x68k/dev
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 also include other misc cleanup that should be in a separate commit: - make local functions static - use C99 designated initializer for readability - use proper integer types - avoid reusing temporary variables for other purpose - misc KNF There is no functional change in them so I'll leave themas is (sorry for noise). --- Izumi Tsutsui
Re: CVS commit: src/sys/arch
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: locore.S src/sys/arch/powerpc/include: spr.h Log Message: Instead of hard-coding SPR# for CCR0, define SPR_CCR0 in and use it. Idea from uwe@, thanks! (and sorry for delayed response!) Note that we already have it defined (along with bunch of others) in sys/arch/powerpc/include/ibm4xx/spr.h:74 -uwe
Re: CVS commit: src/sys/arch
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 SPR# for CCR0, define SPR_CCR0 in > and use it. > > Idea from uwe@, thanks! > (and sorry for delayed response!) Note that we already have it defined (along with bunch of others) in sys/arch/powerpc/include/ibm4xx/spr.h:74 -uwe
Re: CVS commit: src/sys/arch/x68k/stand
> 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. Provide > missing functions. Only for bootloaders that load a kernel? FS_xxx ops in libsa is also used to load secondary bootloaders (not a kernel that might require module info) on several ports, including x86, and I guess in that case ioctl or the "fsmod" variable is not necessary as before. (I'm afraid "const char *fsmod" might require some ifdefs) --- Izumi Tsutsui
Re: CVS commit: src/sys/arch/amiga/stand/bootblock/elf2bb
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 binary changes both for little and big endian machines.
Oops, "be{16,32}toh(3) instead of htobe{16,32}(3)", apparently...
Thanks,
rin
Re: CVS commit: src/sys/arch/i386/stand/efiboot
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 = NULL;
>
> part_name is NULL, *part_name crashes. How do you avoid that?
Aha, I have this elsewhere in my zfs tree:
*partition = 0;
- *part_name = NULL;
+ if (part_name)
+ *part_name = NULL;
I'll commit that now (as well as the same check for the
NO_DISKLABEL && NO_GPT case. Thanks for the digging!
Cheers,
Simon.
Re: CVS commit: src/sys/arch/i386/stand/efiboot
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 crash because > of this. Please revert my change, I will get back to it when > I find some time. Thanks. I'll revert that now. If you have a way of preproducing this, I'm happy to have a look. Cheers, Simon.
Re: CVS commit: src/sys/arch/i386/stand/efiboot
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 revert my change, I will get back to it when I find some time. -- Emmanuel Dreyfus m...@netbsd.org
Re: CVS commit: src/sys/arch/i386/stand/efiboot
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 the use of part_name by the called functions should check if it is NULL before trying to assign anything to *part_name. This change has broken loading boot.cfg via the EFI path "esp:/EFI/NetBSD/boot.cfg" since the call to bios_boot() at https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/efiboot/devopen.c#292 with a non-NULL last argument means devname gets updated and now points to the partition with a root filesystem rather than the EFI system partition. Cheers, Simon.
Re: CVS commit: src/sys/arch/arm/sa11x0
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 this function by C. There seems no particular reason to use assembler, and no major performance regression is expected. No reason to use assembler, if converted to use arm/arm32/irq_dispatch.S. Thanks, rin
Re: CVS commit: src/sys/arch
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 db_machdep_init(...) should move to the ifdef _KERNEL block? compile crash/db_autoconf.o In file included from /usr/src/../obj/usr.sbin/crash/machine/db_machdep.h:4, from /usr/src/usr.sbin/crash/../../sys/ddb/ddb.h:35, from /usr/src/usr.sbin/crash/../../sys/ddb/db_autoconf.c:39: /usr/src/../obj/usr.sbin/crash/aarch64/db_machdep.h:231:29: error: 'struct cpu_info' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] 231 | void db_machdep_init(struct cpu_info * const); -Tobias
Re: CVS commit: src/sys/arch/x86/x86
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: src/sys/arch/x86/x86: tsc.c Log Message: Fix typo in comment: "porniters" -> "pointers" To generate a diff of this commit: cvs rdiff -u -r1.56 -r1.57 src/sys/arch/x86/x86/tsc.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files. -- thorpej !DSPAM:6169cf82254421105921466! ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: CVS commit: src/sys/arch/x86/x86
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: "porniters" -> "pointers" > > > To generate a diff of this commit: > cvs rdiff -u -r1.56 -r1.57 src/sys/arch/x86/x86/tsc.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > -- thorpej
Re: CVS commit: src/sys/arch
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 cache information in similar formats and arm and aarch64, e.g. For classic ARM CPUs, info->[id]cache_sets are not set. This results in cpu0 at mainbus0 core 0: SA-1110 step B-5 (SA-1 V4 core) cpu0: DC enabled IC enabled WB enabled LABT cpu0: L1 16KB/32B 32-way (0 set) VIVT Instruction cache cpu0: L1 8KB/32B 32-way (0 set) write-back VIVT Data cache or cpu0 at mainbus0 core 0: ARM926EJ-S r0p0 (ARM9EJ-S V5TEJ core) cpu0: DC enabled IC enabled WB enabled LABT cpu0: L1 32KB/32B 1-way (0 set) VIVT Instruction cache cpu0: L1 32KB/32B 1-way (0 set) write-back-locking-C VIVT Data cache Can I commit the attached patch? Or initialize these variables somewhere else? I think your patch is fine. Thanks for fixing this. Nick
Re: CVS commit: src/sys/arch
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: 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. For classic ARM CPUs, info->[id]cache_sets are not set. This results in cpu0 at mainbus0 core 0: SA-1110 step B-5 (SA-1 V4 core) cpu0: DC enabled IC enabled WB enabled LABT cpu0: L1 16KB/32B 32-way (0 set) VIVT Instruction cache cpu0: L1 8KB/32B 32-way (0 set) write-back VIVT Data cache or cpu0 at mainbus0 core 0: ARM926EJ-S r0p0 (ARM9EJ-S V5TEJ core) cpu0: DC enabled IC enabled WB enabled LABT cpu0: L1 32KB/32B 1-way (0 set) VIVT Instruction cache cpu0: L1 32KB/32B 1-way (0 set) write-back-locking-C VIVT Data cache Can I commit the attached patch? Or initialize these variables somewhere else? I think your patch is fine. Thanks for fixing this. Nick
Re: CVS commit: src/sys/arch
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 and arm and aarch64, e.g. For classic ARM CPUs, info->[id]cache_sets are not set. This results in cpu0 at mainbus0 core 0: SA-1110 step B-5 (SA-1 V4 core) cpu0: DC enabled IC enabled WB enabled LABT cpu0: L1 16KB/32B 32-way (0 set) VIVT Instruction cache cpu0: L1 8KB/32B 32-way (0 set) write-back VIVT Data cache or cpu0 at mainbus0 core 0: ARM926EJ-S r0p0 (ARM9EJ-S V5TEJ core) cpu0: DC enabled IC enabled WB enabled LABT cpu0: L1 32KB/32B 1-way (0 set) VIVT Instruction cache cpu0: L1 32KB/32B 1-way (0 set) write-back-locking-C VIVT Data cache Can I commit the attached patch? Or initialize these variables somewhere else? Thanks, rin Index: sys/arch/arm/arm32/cpu.c === RCS file: /home/netbsd/src/sys/arch/arm/arm32/cpu.c,v retrieving revision 1.149 diff -p -u -r1.149 cpu.c --- sys/arch/arm/arm32/cpu.c23 Sep 2021 06:34:00 - 1.149 +++ sys/arch/arm/arm32/cpu.c8 Oct 2021 00:11:34 - @@ -612,7 +612,9 @@ print_cache_info(device_t dv, struct arm level + 1, info->dcache_size / 1024, info->dcache_line_size, info->dcache_ways, - info->dcache_sets, + info->dcache_sets ? info->dcache_sets : + info->dcache_size / + (info->dcache_line_size * info->dcache_ways), wtnames[info->cache_type], info->dcache_type & CACHE_TYPE_PIxx ? 'P' : 'V', info->dcache_type & CACHE_TYPE_xxPT ? 'P' : 'V'); @@ -621,14 +623,18 @@ print_cache_info(device_t dv, struct arm level + 1, info->icache_size / 1024, info->icache_line_size, info->icache_ways, - info->icache_sets, + info->icache_sets ? info->icache_sets : + info->icache_size / + (info->icache_line_size * info->icache_ways), info->icache_type & CACHE_TYPE_PIxx ? 'P' : 'V', info->icache_type & CACHE_TYPE_xxPT ? 'P' : 'V'); aprint_normal_dev(dv, "L%u %dKB/%dB %d-way (%u set) %s %cI%cT Data cache\n", level + 1, info->dcache_size / 1024, info->dcache_line_size, info->dcache_ways, - info->dcache_sets, + info->dcache_sets ? info->dcache_sets : + info->dcache_size / + (info->dcache_line_size * info->dcache_ways), wtnames[info->cache_type], info->dcache_type & CACHE_TYPE_PIxx ? 'P' : 'V', info->dcache_type & CACHE_TYPE_xxPT ? 'P' : 'V');
Re: CVS commit: src/sys/arch/arm/arm
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 which this file was derived. To generate a diff of this commit: cvs rdiff -u -r1.6 -r1.7 src/sys/arch/arm/arm/cpufunc_asm_armv5_ec.S Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/arch
> 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. : > aarch64 before > [ 1.030] cpu1: L1 48KB/64B*256L*3W PIPT Instruction cache > [ 1.030] cpu1: L1 32KB/64B*256L*2W PIPT Data cache > [ 1.030] cpu1: L2 2048KB/64B*2048L*16W PIPT Unified cache > > aarch64 after > [ 1.030] cpu1: L1 48KB/64B 3-way (256 set) PIPT Instruction cache > [ 1.030] cpu1: L1 32KB/64B 2-way (256 set) PIPT Data cache > [ 1.030] cpu1: L2 2048KB/64B 16-way (2048 set) PIPT Unified cache I prefer "line(s)" as before rather than "set(s)" since the latter implies "N-way set associative cache". --- Izumi Tsutsui
Re: CVS commit: src/sys/arch/sh3/sh3
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 changes confirmed this time.
---
- if (kva) {
+ if (kva)
entry |= PG_V | PG_SH |
((prot & VM_PROT_WRITE) ?
(PG_PR_KRW | PG_D) : PG_PR_KRO);
- } else {
+ else
entry |= PG_V |
((prot & VM_PROT_WRITE) ?
(PG_PR_URW | PG_D) : PG_PR_URO);
- }
}
---
This part doesn't match KNF:
http://cvsweb.netbsd.org/bsdweb.cgi/src/share/misc/style#rev1.58
Update style around single-line braces according to discussion.
https://mail-index.netbsd.org/tech-userlevel/2020/07/12/msg012536.html
https://mail-index.netbsd.org/tech-kern/2020/07/12/msg026594.html
Retain some examples of technically unnecessary braces that likely
aid legibility from the previous commit.
So I don't think removing existing ones per "redundant" is a valid reason.
Oops, I misread style. These and one more similar braces have been restored.
Thanks for pointing it out!
rin
Re: CVS commit: src/sys/arch/sh3/sh3
> 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 time.
---
- if (kva) {
+ if (kva)
entry |= PG_V | PG_SH |
((prot & VM_PROT_WRITE) ?
(PG_PR_KRW | PG_D) : PG_PR_KRO);
- } else {
+ else
entry |= PG_V |
((prot & VM_PROT_WRITE) ?
(PG_PR_URW | PG_D) : PG_PR_URO);
- }
}
---
This part doesn't match KNF:
http://cvsweb.netbsd.org/bsdweb.cgi/src/share/misc/style#rev1.58
> Update style around single-line braces according to discussion.
>
> https://mail-index.netbsd.org/tech-userlevel/2020/07/12/msg012536.html
> https://mail-index.netbsd.org/tech-kern/2020/07/12/msg026594.html
>
> Retain some examples of technically unnecessary braces that likely
> aid legibility from the previous commit.
So I don't think removing existing ones per "redundant" is a valid reason.
---
Izumi Tsutsui
Re: CVS commit: src/sys/arch/evbarm/conf
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 DISKLABEL_EI as this SoC supports both endians now. personally, i think we should do these everywhere that isn't size constrained. they're useful for accessing other platform disks quite often on all netbsd systems. Yeah, I agree. Probably, we can have these options in sys/conf/filesystems.config. Most powerful platforms have already used that file: $ cd /usr/src/sys/arch && grep filesystems.conf */conf/* amd64/conf/GENERIC:include "conf/filesystems.config" amd64/conf/XEN3_DOM0:include "conf/filesystems.config" amd64/conf/XEN3_DOMU:include "conf/filesystems.config" evbarm/conf/GENERIC.common:include "conf/filesystems.config" i386/conf/GENERIC:include "conf/filesystems.config" macppc/conf/GENERIC:include "conf/filesystems.config" riscv/conf/GENERIC:include "conf/filesystems.config" sgimips/conf/GENERIC32_IP2x:include "conf/filesystems.config" sgimips/conf/GENERIC32_IP3x:include "conf/filesystems.config" sgimips/conf/GENERIC32_IP12:include "conf/filesystems.config" sparc64/conf/GENERIC:include "conf/filesystems.config" And we can switch other machines to use it. Thanks, rin
re: CVS commit: src/sys/arch/evbarm/conf
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. personally, i think we should do these everywhere that isn't size constrained. they're useful for accessing other platform disks quite often on all netbsd systems. .mrg.
Re: CVS commit: src/sys/arch/arm/xscale
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 kernel on evbarm/HDL_G, including one worked around by if_wm.c rev 1.706: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/if_wm.c#rev1.706 if_wm.c:r1.706 also fixes a potential bug which causes infinite loop when do "sysctl -w hw.wmX.txrx_workqueue=1" on single processor system. So, I leave the code. Thanks, -- // Internet Initiative Japan Inc. Device Engineering Section, Product Division, Technology Unit Kengo NAKAHARA
Re: CVS commit: src/sys/arch/arm/include/arm32
"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 ways MSGBUFSIZE was pulled in. Cheers, Simon.
Re: CVS commit: src/sys/arch/powerpc/include/booke
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 with oea: MAXTSIZ: 512MB -> 128MB MAXDSIZ: 3.25GB -> 1GB There should be no particular reasons for having different values. Is there an architectural reason for MAXTSIZ to be 128MB? Because we have seen binaries larger than that. Ah, I just forgot recent discussion on MAXTSIZ. There's no limitation due to architecture. I've confirmed binary just works fine, whose text is larger than 256MB segment on oea. It works on booke and ibm4xx also. Maybe we can leave MAXTSIZ undefined for powerpc. Thanks, rin
Re: CVS commit: src/sys/arch/powerpc/include/booke
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 -> 128MB > MAXDSIZ: 3.25GB -> 1GB > > There should be no particular reasons for having different values. Is there an architectural reason for MAXTSIZ to be 128MB? Because we have seen binaries larger than that. Joerg
Re: CVS commit: src/sys/arch
"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.
Re: CVS commit: src/sys/arch/powerpc/oea
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 > Date: Thu Apr 1 22:02:20 UTC 2021 > > Modified Files: > src/sys/arch/powerpc/oea: ofwoea_machdep.c > > Log Message: > avoid mapping 0xf000 - my beige G3 DSIs on it > with this my the machine boots again > tested on a variety of G4 and G5 models with no problems > > > To generate a diff of this commit: > cvs rdiff -u -r1.59 -r1.60 src/sys/arch/powerpc/oea/ofwoea_machdep.c > > Please note that diffs are not public domain; they are subject to the > copyright notices on the relevant files. > -- thorpej
Re: CVS commit: src/sys/arch/evbmips/stand/sbmips
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: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 soft-float to kill linker warnings
>
> this doesn't make sense to me. it should be compiled
> as if for 64 bit CPU (it is.) it even has this:
>
> CFLAGS+= -mips64
> CFLAGS+= -Werror ${CWARNFLAGS}
> -CPUFLAGS+= -mabi=n32
>
> two lines above the removed -mabi=n32.
>
> what was the real problem here? (the soft-float part
> seems reasonable.)
>
>
> .mrg.
signature.asc
Description: Message signed with OpenPGP
re: CVS commit: src/sys/arch/evbmips/stand/sbmips
"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 soft-float to kill linker warnings
this doesn't make sense to me. it should be compiled
as if for 64 bit CPU (it is.) it even has this:
CFLAGS+= -mips64
CFLAGS+= -Werror ${CWARNFLAGS}
-CPUFLAGS+= -mabi=n32
two lines above the removed -mabi=n32.
what was the real problem here? (the soft-float part
seems reasonable.)
.mrg.
Re: CVS commit: src/sys/arch/amd64/conf
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 do that via an intermediate step of a config with small differences. Also I think we should also consider extracting lots of things into includable files, similar to how include "dev/usb/usbdevices.config" is used now in GENERIC. That will raise interesting cross-arch issues about value vs kernel memory usage probably. These include files would allow a simplification of XEN3_DOMU which as I see it should have ~no drivers but all the rest of the options. signature.asc Description: PGP signature
re: CVS commit: src/sys/arch/amd64/conf
"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 sort/uniq (one line was previously duplicated), this file is > identical to the previous version. It has been reorganized to reduce > diffs to GENERIC, and many missing lines from GENERIC have been added > but commented out. could this be done with include and "no foo" statement? eg, like sys/arch/sparc/conf/INSTALL does. .mrg.
Re: CVS commit: src/sys/arch/aarch64/aarch64
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
> 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 explaining why! -- thorpej
Re: CVS commit: src/sys/arch/aarch64/aarch64
>> 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 the >idlelwp helps here too? 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. Thanks -- ryo shimizu
Re: CVS commit: src/sys/arch/aarch64/aarch64
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 generate a diff of this commit: cvs rdiff -u -r1.7 -r1.8 src/sys/arch/aarch64/aarch64/idle_machdep.S 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. After thinking about it, I realized that there is no need to even increment intr_depth. curcpu()->ci_ntr_depth = 1; ARM_IRQ_HANDLER(); curcpu()->ci_ntr_depth = 0; 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 the idlelwp helps here too? Nick
Re: CVS commit: src/sys/arch/aarch64/aarch64
>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 rdiff -u -r1.7 -r1.8 src/sys/arch/aarch64/aarch64/idle_machdep.S 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. After thinking about it, I realized that there is no need to even increment intr_depth. curcpu()->ci_ntr_depth = 1; ARM_IRQ_HANDLER(); curcpu()->ci_ntr_depth = 0; 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. cvs -q diff -aU10 -a -p idle_machdep.S Index: idle_machdep.S === RCS file: /src/cvs/cvsroot-netbsd/src/sys/arch/aarch64/aarch64/idle_machdep.S,v retrieving revision 1.8 diff -a -U 10 -a -p -r1.8 idle_machdep.S --- idle_machdep.S 21 Feb 2021 23:37:09 - 1.8 +++ idle_machdep.S 22 Feb 2021 10:16:25 - @@ -67,40 +67,36 @@ ENTRY(cpu_idle) stp x29, x30, [sp, #TF_X29] /* save x29,x30 */ #ifdef DDB add x29, sp, #TF_X29/* link frame for backtrace */ #endif /* fill the minimum required trapframe */ mov x2, #SPSR_M_EL1H/* what our spsr should be */ str x2, [sp, #TF_SPSR] adr x0, 1f str x0, [sp, #TF_PC]/* CLKF_PC refer to tf_pc */ - - mrs x1, tpidr_el1 /* get curlwp */ - ldr x1, [x1, #L_CPU]/* get curcpu */ - ldr w28, [x1, #CI_INTR_DEPTH] /* w28 = ci->ci_intr_depth */ - add w2, w28, #1 /* w2 = intr_depth + 1 */ - mov x0, sp /* get pointer to trapframe */ + mrs x1, tpidr_el1 /* get curlwp */ DISABLE_INTERRUPT - wfi + ldr x1, [x1, #L_CPU]/* get curcpu */ + mov w2, #1 + str w2, [x1, #CI_INTR_DEPTH]/* ci->ci_intr_depth = 1 */ - str w2, [x1, #CI_INTR_DEPTH]/* ci->ci_intr_depth++ */ + wfi bl ARM_IRQ_HANDLER /* irqhandler(trapframe) */ 1: mrs x1, tpidr_el1 /* get curlwp */ ldr x1, [x1, #L_CPU]/* get curcpu */ - str w28, [x1, #CI_INTR_DEPTH] /* ci->ci_intr_depth = old */ + str wzr, [x1, #CI_INTR_DEPTH] /* ci->ci_intr_depth = 0 */ #if defined(__HAVE_FAST_SOFTINTS) && !defined(__HAVE_PIC_FAST_SOFTINTS) - cbnzw28, 1f /* Skip if intr_depth > 0 */ ldr w3, [x1, #CI_SOFTINTS] /* Get pending softint mask */ /* CPL should be 0 */ ldr w2, [x1, #CI_CPL] /* Get current priority level */ lsr w3, w3, w2 /* shift mask by cpl */ cbz w3, 1f bl _C_LABEL(dosoftints)/* dosoftints() */ 1: #endif /* __HAVE_FAST_SOFTINTS && !__HAVE_PIC_FAST_SOFTINTS */ ldr x28, [sp, #TF_X28] /* restore x28 */ Is this ok? -- ryo shimizu
Re: CVS commit: src/sys/arch/hppa/gsc
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: > > > Fix locking against myself. > > > trigger_output will be called with sc_intr_lock held. > > > From source code review, not tested. > > > > I just tested this on my C200 - playback works. > > Thank you for quick response! > > > The sample rate seems off - everything plays too slow, but that's > > probably completely unrelated. > > Oops, this was my mistake. > I hope that harmony.c,v 1.9 will fix this problem. Works perfectly now, thank you! have fun Michael
Re: CVS commit: src/sys/arch/hppa/gsc
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 with sc_intr_lock held. > > From source code review, not tested. > > I just tested this on my C200 - playback works. Thank you for quick response! > The sample rate seems off - everything plays too slow, but that's > probably completely unrelated. Oops, this was my mistake. I hope that harmony.c,v 1.9 will fix this problem. Sorry for breaking it. --- Tetsuya Isaki
Re: CVS commit: src/sys/arch/hppa/gsc
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 with sc_intr_lock held. > From source code review, not tested. I just tested this on my C200 - playback works. The sample rate seems off - everything plays too slow, but that's probably completely unrelated. have fun Michael
Re: CVS commit: src/sys/arch
> 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 right, but you could explicitly init a named field, most likely
> the one that is tested to determine that this is the sentinel, eg: from
> one of the recent updates ...
>
> static const struct device_compatible_entry compat_data[] = {
>{ .compat = "pnpPNP,401" },
> - { 0 }
> + { }
> };
>
> that could instead be changed to
> { .compat = NULL }
>
> (or something similar to that).
I noticed this because of a different local change in my tree that makes the
first field another anonymous union.
Anyhow, I'll go ahead and define a standard sentinel macro that can be used for
the common { .compat = XXX } case, and fire up sed to fix up the tree.
-- thorpej
Re: CVS commit: src/sys/arch
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 structure which
> is not guaranteed to remain true.
>
Both versions should work in the same way, except that {0} is the
standard variation and {} an extension.
I have got no preference for either.
> -- thorpej
>
signature.asc
Description: OpenPGP digital signature
Re: CVS commit: src/sys/arch
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 extension and C++ syntax.
> >
> > Using { 0 } makes an assumption about the first member of the
> > structure which is not guaranteed to remain true.
>
> The commit message says:
>
> | Since we're using designated initialisers for compat data, we should
> | use a completely empty initializer for the sentinel.
>
> but that "should" is not true. The code that checks that sentinel
> uses some particular member to access it, so, pedantically speaking,
> the initialization must designate that member in the sentinel
> initialization. Yes, this is verbose and doesn't look as pretty, but
> that is what "should" happen here. Using non-standard {} extension
> makes it look nicer, but is not a "should" kind of necessity.
PS: Forgot to add that C++ doesn't have designated initializers (or at
least it didn't last time I looked), so they are in a different
situation here and need an empty initializer list. In C the only
difference it makes is, as far as I can tell, exactly this kind of an
array with a sentinel at the end and the difference is cosmetic.
-uwe
Re: CVS commit: src/sys/arch
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 that is tested to determine that this is the sentinel, eg: from
one of the recent updates ...
static const struct device_compatible_entry compat_data[] = {
{ .compat = "pnpPNP,401" },
- { 0 }
+ { }
};
that could instead be changed to
{ .compat = NULL }
(or something similar to that).
kre
Re: CVS commit: src/sys/arch
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 first member of the
> structure which is not guaranteed to remain true.
The commit message says:
| Since we're using designated initialisers for compat data, we should
| use a completely empty initializer for the sentinel.
but that "should" is not true. The code that checks that sentinel
uses some particular member to access it, so, pedantically speaking,
the initialization must designate that member in the sentinel
initialization. Yes, this is verbose and doesn't look as pretty, but
that is what "should" happen here. Using non-standard {} extension
makes it look nicer, but is not a "should" kind of necessity.
-uwe
Re: CVS commit: src/sys/arch
> 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.
-- thorpej
Re: CVS commit: src/sys/arch
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
> meson_usbctrl.c meson_usbphy.c mesong12_clkc.c mesongx_mmc.c
> mesongxbb_clkc.c
> src/sys/arch/arm/broadcom: bcm2835_emmc.c bcm2835_intr.c
> src/sys/arch/arm/fdt: gicv3_fdt.c pcihost_fdt.c
> src/sys/arch/arm/nvidia: tegra_ahcisata.c tegra_nouveau.c tegra_pcie.c
> tegra_pinmux.c tegra_soctherm.c tegra_xusb.c
> src/sys/arch/arm/nxp: if_enet_imx.c imx6_pcie.c imx6_spi.c
> imx8mq_usbphy.c imx_sdhc.c
> src/sys/arch/arm/rockchip: rk3328_iomux.c rk3399_iomux.c rk_gmac.c
> rk_i2s.c rk_pwm.c rk_tsadc.c rk_usb.c rk_v1crypto.c rk_vop.c
> src/sys/arch/arm/samsung: exynos_dwcmmc.c exynos_pinctrl.c
> exynos_platform.c exynos_usbdrdphy.c exynos_usbphy.c
> src/sys/arch/arm/sociox: if_ave.c
> src/sys/arch/arm/sunxi: sun4i_a10_ccu.c sun4i_dma.c sun6i_dma.c
> sun8i_crypto.c sunxi_can.c sunxi_codec.c sunxi_de2_ccu.c
> sunxi_dep.c sunxi_gpio.c sunxi_hdmi.c sunxi_hdmiphy.c sunxi_i2s.c
> sunxi_lcdc.c sunxi_lradc.c sunxi_mixer.c sunxi_mmc.c sunxi_musb.c
> sunxi_nmi.c sunxi_pwm.c sunxi_rsb.c sunxi_rtc.c sunxi_sid.c
> sunxi_sramc.c sunxi_tcon.c sunxi_thermal.c sunxi_ts.c sunxi_twi.c
> sunxi_usb3phy.c sunxi_usbphy.c sunxi_wdt.c
> src/sys/arch/arm/ti: ti_dpll_clock.c ti_gpio.c ti_iic.c ti_omapintc.c
> ti_omaptimer.c ti_sdhc.c
> src/sys/arch/macppc/dev: deq.c lmu.c psoc.c smusat.c
> src/sys/arch/mips/cavium/dev: octeon_cib.c octeon_intc.c
> src/sys/arch/sparc64/dev: pcf8591_envctrl.c
>
> Log Message:
> Since we're using designated initialisers for compat data, we should
> use a completely empty initializer for the sentinel.
>
> static const struct device_compatible_entry compat_data[] = {
> { .compat = "ecadc" },
> -
> - { 0 }
> + { }
> };
>
> static int
>
I have no problem with this change but I am curious why should we use "{
}"? It's a C GNU extension and C++ syntax.
signature.asc
Description: OpenPGP digital signature
Re: CVS commit: src/sys/arch/evbarm/conf
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 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_subregion(9). Take care, Jared On Thu, 21 Jan 2021, Nia Alarie wrote: Module Name:src Committed By: nia Date: Thu Jan 21 17:46:28 UTC 2021 Modified Files: src/sys/arch/evbarm/conf: GENERIC64 Log Message: add vcaudio (intentionally this time) gives working audio output on rpi3 without needing to run a 32-bit image. To generate a diff of this commit: cvs rdiff -u -r1.173 -r1.174 src/sys/arch/evbarm/conf/GENERIC64 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/arch/evbarm/conf
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_subregion(9). Take care, Jared On Thu, 21 Jan 2021, Nia Alarie wrote: Module Name:src Committed By: nia Date: Thu Jan 21 17:46:28 UTC 2021 Modified Files: src/sys/arch/evbarm/conf: GENERIC64 Log Message: add vcaudio (intentionally this time) gives working audio output on rpi3 without needing to run a 32-bit image. To generate a diff of this commit: cvs rdiff -u -r1.173 -r1.174 src/sys/arch/evbarm/conf/GENERIC64 Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
re: CVS commit: src/sys/arch
"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_DOM0 XEN3PAE_DOMU > src/sys/arch/landisk/conf: GENERIC > src/sys/arch/usermode/conf: GENERIC.common > src/sys/arch/zaurus/conf: GENERIC > > Log Message: > remove compat_ossaudio from kernel modules > > this is only useful with compat_linux and gets autoloaded when > compat_linux is loaded, so there's no reason to bake it into kernels > any more. not everyone uses COMPAT_LINUX as a module. this seems reasonable to have as a comment anywhere COMAPT_LINUX is commented. at least the GENERIC*s should have it, IMO. additionally, there are a few issues remaining. eg, the evbarm/conf/POGO kernel now has a useless "no options" for COMPAT_OSSAUDIO, and there are at least a handful of commented versions remaining. .mrg.
Re: CVS commit: src/sys/arch/arm/sunxi
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: sunxi_sramc.c > > > > Log Message: > > Use device_compatible_entry / of_search_compatible() rather than matching > > against multiple sets of compatibility strings. > > > > > > To generate a diff of this commit: > > cvs rdiff -u -r1.5 -r1.6 src/sys/arch/arm/sunxi/sunxi_sramc.c > > This breaks cubietruck (fdt is: sun7i-a20-cubietruck.dtb): And it was fixed with $NetBSD: sunxi_sramc.c,v 1.7 2021/01/20 00:48:49 jmcneill Exp $ Martin
Re: CVS commit: 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 than matching
> against multiple sets of compatibility strings.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.5 -r1.6 src/sys/arch/arm/sunxi/sunxi_sramc.c
This breaks cubietruck (fdt is: sun7i-a20-cubietruck.dtb):
[ 1.000] fclock0 at simplebus2: 2500 Hz fixed clock (mii_phy_tx)
[ 1.000] fclock1 at simplebus2: 12500 Hz fixed clock (gmac_int_tx)
[ 1.000] fclock2 at simplebus2: 2400 Hz fixed clock (osc24M)
[ 1.000] fclock3 at simplebus2: 32768 Hz fixed clock (osc32k)
[ 1.000] gtmr0 at simplebus0: Generic Timer
[ 1.000] gtmr0: interrupting on GIC irq 27
[ 1.000] armgtmr0 at gtmr0: Generic Timer (24000 kHz, virtual)
[ 1.030] sun4ia10ccu0 at simplebus1: A20 CCU
[ 1.030] sunxinmi0 at simplebus1: NMI
[ 1.030] sunxigmacclk0 at simplebus2: GMAC MII/RGMII clock mux
[ 1.030] sunxigpio0 at simplebus1: PIO
[ 1.030] gpio0 at sunxigpio0: 175 pins
[ 1.030] sunxigpio0: interrupting on GIC irq 60
[ 1.030] sun4idma0 at simplebus1: DMA controller
[ 1.030] sun4idma0: interrupting on GIC irq 59
[ 1.030] sunxisramc0 at simplebus1: SRAM Controller
[ 1.030] uvm_fault(0x80b92d68, 0, 1) -> e
[ 1.030] Fatal kernel mode data abort: 'Translation Fault (S)'
[ 1.030] trapframe: 0x80bc8cf0
[ 1.030] FSR=0005, FAR=, spsr=6353
[ 1.030] r0 =92cfd200, r1 =806b0910, r2 =, r3 =
[ 1.030] r4 =92a0cd00, r5 =10c4, r6 =92cfd200, r7 =0dd0
[ 1.030] r8 =806b0910, r9 =114c, r10=80634a80, r11=80bc8d94
[ 1.030] r12=92cf3988, ssp=80bc8d40, slr=804bc688, pc =80061fac
Stopped in pid 0.0 (system) at netbsd:sunxi_sramc_attach+0x16c:ldr
r2, [r2]
(gdb) list *(sunxi_sramc_attach+0x16c)
0x80061fac is in sunxi_sramc_attach
(../../../../arch/arm/sunxi/sunxi_sramc.c:135).
130 if (dce != NULL) {
131 node = kmem_alloc(sizeof(*node), KM_SLEEP);
132 node->phandle = child;
133 node->area = dce->data;
134 TAILQ_INSERT_TAIL(>sc_nodes, node, nodes);
135 aprint_verbose_dev(sc->sc_dev, "area: %s\n",
136 node->area->desc);
137 }
138 }
139 }
With the change backed out it boots fine (dmesg below).
Martin
--8<--
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,
2018, 2019, 2020, 2021 The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
NetBSD 9.99.78 (GENERIC) #117: Tue Jan 19 19:14:10 CET 2021
mar...@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/evbarm/compile/GENERIC
total memory = 2045 MB
avail memory = 1989 MB
entropy: no seed from bootloader
timecounter: Timecounters tick every 10.000 msec
Kernelized RAIDframe activated
armfdt0 (root)
simplebus0 at armfdt0: Cubietech Cubietruck
simplebus1 at simplebus0
cpus0 at simplebus0
simplebus2 at simplebus0
simplebus3 at simplebus0
cpu0 at cpus0: Cortex-A7 r0p4 (Cortex V7A core)
cpu0: DC enabled IC enabled WB enabled LABT branch prediction enabled
cpu0: 32KB/32B 2-way L1 VIPT Instruction cache
cpu0: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache
cpu0: 256KB/64B 8-way write-through L2 PIPT Unified cache
vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals
cpufreqdt0 at cpu0
cpu1 at cpus0
cpufreqdt1 at cpu1
gic0 at simplebus1: GIC
armgic0 at gic0: Generic Interrupt Controller, 160 sources (150 valid)
armgic0: 16 Priorities, 128 SPIs, 7 PPIs, 15 SGIs
fclock0 at simplebus2: 2500 Hz fixed clock (mii_phy_tx)
fclock1 at simplebus2: 12500 Hz fixed clock (gmac_int_tx)
fclock2 at simplebus2: 2400 Hz fixed clock (osc24M)
fclock3 at simplebus2: 32768 Hz fixed clock (osc32k)
gtmr0 at simplebus0: Generic Timer
gtmr0: interrupting on GIC irq 27
armgtmr0 at gtmr0: Generic Timer (24000 kHz, virtual)
timecounter: Timecounter "armgtmr0" frequency 2400 Hz quality 500
sun4ia10ccu0 at simplebus1: A20 CCU
sunxinmi0 at simplebus1: NMI
sunxigmacclk0 at simplebus2: GMAC MII/RGMII clock mux
sunxigpio0 at simplebus1: PIO
gpio0 at sunxigpio0: 175 pins
sunxigpio0: interrupting on GIC irq 60
sun4idma0 at simplebus1: DMA controller
sun4idma0: interrupting on GIC irq 59
sunxisramc0 at simplebus1: SRAM Controller
sunxisramc0: area: SRAM A3/A4
sunxisramc0: area: SRAM D
sunxidebe0 at simplebus1: Display Engine Backend (display-backend@1e6)
re: CVS commit: src/sys/arch/aarch64/aarch64
> 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
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 interrupt context.
1.31 --> 1.30
Sorry for bothering you many times...
rin
Re: CVS commit: src/sys/arch/powerpc/ibm4xx
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 instead of entropy_enter_intr() in
statclock(), which results in KASSERT() failure.
To generate a diff of this commit:
cvs rdiff -u -r1.30 -r1.31 src/sys/arch/powerpc/ibm4xx/clock.c
This message is somewhat misleading. I meant:
(1) Callers are interrupt handlers, therefore, {hard,stat}clock() are
apparently invoked in the interrupt context.
(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 interrupt context.
I have to improve my English writing skills ;-).
Thanks,
rin
Re: CVS commit: src/sys/arch/arm/rockchip
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 UTC 2021 Modified Files: src/sys/arch/arm/rockchip: rk_i2s.c Log Message: rk_i2s.c To generate a diff of this commit: cvs rdiff -u -r1.5 -r1.6 src/sys/arch/arm/rockchip/rk_i2s.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src/sys/arch/arm/arm32
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 wrote: Module Name:src Committed By: skrll Date: Sat Nov 21 19:44:52 UTC 2020 Modified Files: src/sys/arch/arm/arm32: cpuswitch.S Log Message: Ensure that r5 contains curlwp before DO_AST_AND_RESTORE_ALIGNMENT_FAULTS in lwp_trampoline as required by the move to make ASTs operate per-LWP rather than per-CPU. Thanks to martin@ for bisecting the amap corruption he was seeing and testing this fix. To generate a diff of this commit: cvs rdiff -u -r1.103 -r1.104 src/sys/arch/arm/arm32/cpuswitch.S Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
