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 splatt
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 informat
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 t
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:
> > src/sys/arch/s
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_
Oh, should've tested that. Survived kernels and distribution:
diff --git a/sys/arch/sparc64/sparc64/db_trace.c
b/sys/arch/sparc64/sparc64/db_trace.c
index f5e35e79dd51..d94e5eb2d2ef 100644
--- a/sys/arch/sparc64/sparc64/db_trace.c
+++ b/sys/arch/sparc64/sparc64/db_trace.c
@@ -36,6 +36,7 @@ __KERN
This breaks the build of usr.sbin/crash:
/work/build/src/usr.sbin/crash/../../sys/arch/sparc64/sparc64/db_trace.c: In
function 'db_stack_trace_print':
/work/build/src/usr.sbin/crash/../../sys/arch/sparc64/sparc64/db_trace.c:166:37:
error: 'VM_MAX_KERNEL_ADDRESS' undeclared (first use in this fun
"Martin Husemann" writes:
> Module Name: src
> Committed By: martin
> Date: Fri Jan 4 16:25:06 UTC 2019
>
> Modified Files:
> src/sys/arch/sparc64/sparc64: autoconf.c
>
> Log Message:
> PR port-sparc64/53830: adapt QEMU workarounds to newer OpenBIOS device
> tree layout.
why this
"Palle Lyckegaard" writes:
> Module Name: src
> Committed By: palle
> Date: Sun Aug 27 19:31:44 UTC 2017
>
> Modified Files:
> src/sys/arch/sparc64/sparc64: cpu.c
>
> Log Message:
> sun4v: Change clk and sclk variables to unsigned type so modern faster
> systems with CPU frequencie
fixed thanks
On Sun, 12 Feb 2017, Takeshi Nakayama wrote:
Date: Sun, 12 Feb 2017 04:28:58
From: Takeshi Nakayama
To: source-changes-d@NetBSD.org, pa...@netbsd.org
Subject: Re: CVS commit: src/sys/arch/sparc64/sparc64
"Palle Lyckegaard" wrote
Module Name:src
Committed B
>>> "Palle Lyckegaard" wrote
> Module Name: src
> Committed By: palle
> Date: Sat Feb 11 23:41:36 UTC 2017
>
> Modified Files:
> src/sys/arch/sparc64/sparc64: trap.c
>
> Log Message:
> sun4v: Fix calculation of mmu data fault address (pointer arithmetic)
paddr_t is "unsigned lon
thanks for fixing these problems. i was espcially amused by the
code that was if (copyout() || copyout() || suword()).
> Modified Files:
> src/sys/arch/sparc64/sparc64: machdep.c netbsd32_machdep.c
> sunos_machdep.c
>
> Log Message:
> remove all MD uses of suword(), replace by co
> Module Name: src
> Committed By: christos
> Date: Mon Nov 9 02:13:41 UTC 2015
>
> Modified Files:
> src/sys/arch/sparc64/sparc64: syscall.c
>
> Log Message:
> fix printf formats.
yuck, can't you just use PRId64 instead of the casts? these are
int64 members. also, using %# vs
> > we don't need the #ifdef's here. CPU_ISSUN4V is 0 for
> > normal kernels, so the above is compiled out anyway.
> > there's a bunch of other places this is done as well that
> > we don't need it.. could you this up at some point?
totally gimplished that up :-) "clean" of course :-)
> sure w
On Mon, 3 Nov 2014, matthew green wrote:
we don't need the #ifdef's here. CPU_ISSUN4V is 0 for
normal kernels, so the above is compiled out anyway.
there's a bunch of other places this is done as well that
we don't need it.. could you this up at some point?
sure will do
+ #ifdef SUN4V
+ if (CPU_ISSUN4V)
+ func = sparc64_ipi_dcache_flush_page_sun4v;
+ else if (CPU_IS_USIII_UP())
+ #else
if (CPU_IS_USIII_UP())
+ #endif
func = sparc64_ipi_dcache_flush_page_usiii;
we don't need the #ifdef's h
On Thu, Sep 12, 2013 at 10:12:23PM +0900, Takeshi Nakayama wrote:
> This change provides a chance to select a prefer timecounter to
> users via sysctl kern.timecounter.hardware.
>
> stick-counter's quality is larger than tick-counter's one. The
> default choice becomes to stick-counter, so it's no
>>> Michael wrote
> Hello,
>
> on Thursday 22 August 2013 06:00:43 Takeshi Nakayama wrote:
> > Module Name:src
> > Committed By: nakayama
> > Date: Thu Aug 22 10:00:43 UTC 2013
> >
> > Modified Files:
> > src/sys/arch/sparc64/sparc64: clock.c
> >
> > Log Message:
Hello,
on Thursday 22 August 2013 06:00:43 Takeshi Nakayama wrote:
> Module Name: src
> Committed By: nakayama
> Date: Thu Aug 22 10:00:43 UTC 2013
>
> Modified Files:
> src/sys/arch/sparc64/sparc64: clock.c
>
> Log Message:
> Make timecounter "tick-counter" mandatory.
This is goin
On Sat, Mar 03, 2012 at 08:50:50AM +, David Laight wrote:
>
> Is that a gcc bug?
No, gcc calls a function with 32bit abi and expects it to ignore the upper bits
in that register.
The patch makes it so. Good catch!
Martin
>>> David Laight wrote
> Is that a gcc bug?
I don't know.
> Or are the high register bits usually undefined for 32bit values,
> and this to do with using 64bit asm in a 32bit kernel?
But I guess it's undefined from looking at the generated codes.
Our kernel code is shared between 32-bit and 64
On Sat, Mar 03, 2012 at 03:17:32AM +, Takeshi Nakayama wrote:
> Module Name: src
> Committed By: nakayama
> Date: Sat Mar 3 03:17:32 UTC 2012
>
> Modified Files:
> src/sys/arch/sparc64/sparc64: locore.s
>
> Log Message:
> Fix the root cause of the hack "disable optimizations f
On Sat, Mar 03, 2012 at 03:17:32AM +, Takeshi Nakayama wrote:
> Module Name: src
> Committed By: nakayama
> Date: Sat Mar 3 03:17:32 UTC 2012
>
> Modified Files:
> src/sys/arch/sparc64/sparc64: locore.s
>
> Log Message:
> Fix the root cause of the hack "disable optimizations f
Salut,
On Tue, Aug 18, 2009 at 12:15:37AM +, Michael Lorenz wrote:
> CV: Enter Log. Lines beginning with `CVS:' are removed automatically
You sure have an odd CV. (SCNR)
Tonnerre
pgpt0ZR5BjKOx.pgp
Description: PGP signature
26 matches
Mail list logo
