Re: CVS commit: src/sys/arch/powerpc/include/booke

2021-04-17 Thread Joerg Sonnenberger
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 ->

Re: CVS commit: src/sys/conf

2021-04-05 Thread Simon Burge
"Christos Zoulas" wrote: > Module Name: src > Committed By: christos > Date: Mon Apr 5 22:52:03 UTC 2021 > > Modified Files: > > src/sys/conf: Makefile.kern.inc > > Log Message: > > Don't use /usr/bin/time (it is not portable) Oops, that bit wasn't meant to sneak in. Thanks for

Re: CVS commit: src/sys/arch

2021-04-02 Thread Simon Burge
"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

2021-04-01 Thread Jason Thorpe
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 >

Re: CVS commit: src/sys/arch/evbmips/stand/sbmips

2021-03-16 Thread Christos Zoulas
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:

re: CVS commit: src/sys/arch/evbmips/stand/sbmips

2021-03-15 Thread matthew green
"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

Re: CVS commit: src/sys/arch/amd64/conf

2021-03-05 Thread Greg Troxel
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

re: CVS commit: src/sys/arch/amd64/conf

2021-03-05 Thread matthew green
"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

Re: CVS commit: src/sys/arch/aarch64/aarch64

2021-02-23 Thread Jared McNeill
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

2021-02-22 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/arch/aarch64/aarch64

2021-02-22 Thread Ryo Shimizu
>> 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

Re: CVS commit: src/sys/arch/aarch64/aarch64

2021-02-22 Thread Nick Hudson
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

Re: CVS commit: src/sys/arch/aarch64/aarch64

2021-02-22 Thread Ryo Shimizu
>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

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-17 Thread Christos Zoulas
In article <5912ca9e-b4e7-423d-a45d-f4693d1c9...@zoulas.com>, Christos Zoulas wrote: >-=-=-=-=-=- Here's the final changes - Make ALIGNED_POINTER use __alignof(t) instead of sizeof(t). This is more correct because it works with non-primitive types and provides the ABI alignment for the

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-17 Thread Christos Zoulas
> On Feb 17, 2021, at 4:20 PM, Valery Ushakov wrote: > > On Wed, Feb 17, 2021 at 17:49:15 -, Christos Zoulas wrote: > > This incrementally improves wrong things b/c you still have the "is > aligned" and "ought to be aligned" conflated in one. The incremental patch improves things and

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-17 Thread Valery Ushakov
On Wed, Feb 17, 2021 at 17:49:15 -, Christos Zoulas wrote: > In article , > Valery Ushakov wrote: > > >But to get back to my main point, PLEASE, can we stop making random > >aimless changes without prior discussion? > > Here's the change I'd like to make: > - pass the alignment instead of

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-17 Thread Christos Zoulas
In article , Valery Ushakov wrote: >But to get back to my main point, PLEASE, can we stop making random >aimless changes without prior discussion? Here's the change I'd like to make: - pass the alignment instead of the mask (as Roy asked and to match the other macro) - use alignof to

Re: CVS commit: src/sys

2021-02-17 Thread J. Hannken-Illjes
Jared, please test if the attached diff is sufficient. -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig uvm_swap.c.diff Description: Binary data > On 17. Feb 2021, at 13:07, Jared McNeill wrote: > > I noticed this on reboot since this change: > > [ 3636.2891122] turning

Re: CVS commit: src/sys

2021-02-17 Thread Jared McNeill
I noticed this on reboot since this change: [ 3636.2891122] turning off swap...stopping swap on /swap failed with error 16 [ 3636.2991109] stopping swap on /swap2 failed with error 16 Can you have a look? Thanks! Jared On Tue, 16 Feb 2021, Juergen Hannken-Illjes wrote: Module Name:

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-16 Thread Valery Ushakov
On Tue, Feb 16, 2021 at 18:51:43 -0500, Christos Zoulas wrote: > On Feb 17, 2:20am, u...@stderr.spb.ru (Valery Ushakov) wrote: > -- Subject: Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys) > > | Well, it was you who did the definion of ALIGNED_POINTER centralized > |

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-16 Thread Valery Ushakov
On Wed, Feb 17, 2021 at 00:51:03 +0100, Roland Illig wrote: > 17.02.2021 00:25:10 Valery Ushakov : > > On Tue, Feb 16, 2021 at 23:54:46 +0100, Roland Illig wrote: > >> Yes, it does. That's what the "#undef __NO_STRICT_ALIGNMENT" in the > >> test is for. > >> > >> I intentionally placed it

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-16 Thread Christos Zoulas
On Feb 17, 2:20am, u...@stderr.spb.ru (Valery Ushakov) wrote: -- Subject: Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys) | Well, it was you who did the definion of ALIGNED_POINTER centralized | and overridable :) | | revision 1.400 | date: 2012-01-25 00:03:36 +0400; author: christos

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-16 Thread Roland Illig
17.02.2021 00:25:10 Valery Ushakov : > On Tue, Feb 16, 2021 at 23:54:46 +0100, Roland Illig wrote: >> Yes, it does.  That's what the "#undef __NO_STRICT_ALIGNMENT" in the >> test is for. >> >> I intentionally placed it between (which defines that >> macro on x86 and some other platforms) and

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-16 Thread Roland Illig
On 16.02.2021 23:32, Jason Thorpe wrote: On Feb 16, 2021, at 1:56 PM, Roland Illig wrote: A downside of this test is that the macro from gets only evaluated at compile time of the test. The test therefore cannot cover future updates to without being reinstalled itself. But at least for

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-16 Thread Valery Ushakov
On Tue, Feb 16, 2021 at 17:53:09 -0500, Christos Zoulas wrote: > In this case "type" is a struct and we have __alignof() to handle > it, but does this give the right answer? > > Also ALIGNED_POINTER is not conditional to __NO_STRICT_ALIGNMENT and > can be overriden (the opposite goes for

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-16 Thread Valery Ushakov
On Tue, Feb 16, 2021 at 23:54:46 +0100, Roland Illig wrote: > On 16.02.2021 23:40, Valery Ushakov wrote: > > On Tue, Feb 16, 2021 at 22:56:19 +0100, Roland Illig wrote: > > > > > On 16.02.2021 19:46, Roy Marples wrote: > > > > I suggest we change POINTER_ALIGNED_P to accept the alignment value

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-16 Thread Roland Illig
On 16.02.2021 23:40, Valery Ushakov wrote: On Tue, Feb 16, 2021 at 22:56:19 +0100, Roland Illig wrote: On 16.02.2021 19:46, Roy Marples wrote: I suggest we change POINTER_ALIGNED_P to accept the alignment value we want rather than the bitwise test we supply, like so: #define

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-16 Thread Christos Zoulas
In this case "type" is a struct and we have __alignof() to handle it, but does this give the right answer? Also ALIGNED_POINTER is not conditional to __NO_STRICT_ALIGNMENT and can be overriden (the opposite goes for POINTER_ALIGNED_P) I am all for having one macro, but how can we satisfy all

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-16 Thread Valery Ushakov
On Tue, Feb 16, 2021 at 22:56:19 +0100, Roland Illig wrote: > On 16.02.2021 19:46, Roy Marples wrote: > > I suggest we change POINTER_ALIGNED_P to accept the alignment value we > > want rather than the bitwise test we supply, like so: > > > > #define POINTER_ALIGNED_P(p, a) (((uintptr_t)(p) &

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-16 Thread Jason Thorpe
> On Feb 16, 2021, at 1:56 PM, Roland Illig wrote: > > A downside of this test is that the macro from gets only > evaluated at compile time of the test. The test therefore cannot cover > future updates to without being reinstalled itself. But > at least for the release builds, it ensures a

Re: POINTER_ALIGNED_P (was: Re: CVS commit: src/sys)

2021-02-16 Thread Roland Illig
On 16.02.2021 19:46, Roy Marples wrote: I suggest we change POINTER_ALIGNED_P to accept the alignment value we want rather than the bitwise test we supply, like so: #define    POINTER_ALIGNED_P(p, a)    (((uintptr_t)(p) & ((a) - 1)) That's a good definition, clear, simple, obvious,

Re: CVS commit: src/sys

2021-02-16 Thread Christos Zoulas
Yes, I agree. I am going to change that. christos > On Feb 16, 2021, at 1:46 PM, Roy Marples wrote: > > Hi Christos > > On 14/02/2021 20:58, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Sun Feb 14 20:58:35 UTC 2021 >> Modified Files: >>

Re: CVS commit: src/sys

2021-02-16 Thread Roy Marples
Hi Christos On 14/02/2021 20:58, Christos Zoulas wrote: Module Name:src Committed By: christos Date: Sun Feb 14 20:58:35 UTC 2021 Modified Files: src/sys/net: if_arp.h if_bridge.c src/sys/netinet: icmp_private.h if_arp.c igmp_var.h in_l2tp.c ip_flow.c

Re: CVS commit: src/sys/netinet

2021-02-16 Thread Martin Husemann
On Tue, Feb 16, 2021 at 09:29:15AM +, Roy Marples wrote: > In my testing on aarch64 and octeon (both of which I think are strict > alignment) neither need pullups nor copyups as the mbuf already has enough > and arphrd is aligned correctly already. Ah, we asserted too much alignment - indeed,

Re: CVS commit: src/sys/netinet

2021-02-16 Thread Roy Marples
On 16/02/2021 09:20, Martin Husemann wrote: On Tue, Feb 16, 2021 at 08:26:40AM +, Roy Marples wrote: Is that because ARP_HDR_ALIGNMENT is forcing 4 byte alignment? The KASSERT a few lines below triggerd, we need to be consistent. For the purposes of using just the header we define I'm

Re: CVS commit: src/sys/netinet

2021-02-16 Thread Martin Husemann
On Tue, Feb 16, 2021 at 08:26:40AM +, Roy Marples wrote: > Is that because ARP_HDR_ALIGNMENT is forcing 4 byte alignment? The KASSERT a few lines below triggerd, we need to be consistent. > For the purposes of using just the header we define I'm pretty sure we can > use 2 byte alignment and

Re: CVS commit: src/sys/netinet

2021-02-16 Thread Roy Marples
On 16/02/2021 05:44, Martin Husemann wrote: Module Name:src Committed By: martin Date: Tue Feb 16 05:44:14 UTC 2021 Modified Files: src/sys/netinet: if_arp.c Log Message: Undo previous backout: alignment is needed here. The reason for the previous backout was a

Re: CVS commit: src/sys

2021-02-15 Thread David Young
On Sun, Feb 14, 2021 at 07:46:38PM +, Roy Marples wrote: > On 13/02/2021 21:34, David Young wrote: > > On Tue, Feb 09, 2021 at 07:02:32AM +, Roy Marples wrote: > > > Hi David > > > > > > On 03/02/2021 21:45, David Young wrote: > > > > > > > > This change looks a little hasty to me. > > >

Re: CVS commit: src/sys

2021-02-14 Thread Roy Marples
On 13/02/2021 21:34, David Young wrote: On Tue, Feb 09, 2021 at 07:02:32AM +, Roy Marples wrote: Hi David On 03/02/2021 21:45, David Young wrote: This change looks a little hasty to me. It looks to me like some of these structs were __packed so that they could be read/written directly

Re: CVS commit: src/sys/net

2021-02-14 Thread Roy Marples
On 13/02/2021 14:19, Jonathan A. Kollasch wrote: On Sat, Feb 13, 2021 at 07:28:05AM +, Roy Marples wrote: Module Name:src Committed By: roy Date: Sat Feb 13 07:28:05 UTC 2021 Modified Files: src/sys/net: if_ether.h if_ethersubr.c Log Message: if_ether: Ensure that

Re: CVS commit: src/sys

2021-02-13 Thread David Young
On Tue, Feb 09, 2021 at 07:02:32AM +, Roy Marples wrote: > Hi David > > On 03/02/2021 21:45, David Young wrote: > > > > This change looks a little hasty to me. > > > > It looks to me like some of these structs were __packed so that > > they could be read/written directly from/to any offset in

Re: CVS commit: src/sys/net

2021-02-13 Thread Jonathan A. Kollasch
On Sat, Feb 13, 2021 at 07:28:05AM +, Roy Marples wrote: > Module Name: src > Committed By: roy > Date: Sat Feb 13 07:28:05 UTC 2021 > > Modified Files: > src/sys/net: if_ether.h if_ethersubr.c > > Log Message: > if_ether: Ensure that ether_header is aligned > > > To

Re: CVS commit: src/sys

2021-02-08 Thread Roy Marples
Hi David On 03/02/2021 21:45, David Young wrote: > > This change looks a little hasty to me. > > It looks to me like some of these structs were __packed so that > they could be read/written directly from/to any offset in a packet > chain using mtod(), which does not pay any mind to the alignment

Re: CVS commit: src/sys

2021-02-07 Thread Roy Marples
On 04/02/2021 20:18, matthew green wrote: Roy Marples writes: On 03/02/2021 21:45, David Young wrote: On Wed, Feb 03, 2021 at 05:51:40AM +, Roy Marples wrote: Module Name:src Committed By: roy Date: Wed Feb 3 05:51:40 UTC 2021 Modified Files: src/sys/net:

Re: CVS commit: src/sys

2021-02-04 Thread Joerg Sonnenberger
On Thu, Feb 04, 2021 at 09:07:06PM +, Jaromir Dolecek wrote: > Module Name: src > Committed By: jdolecek > Date: Thu Feb 4 21:07:06 UTC 2021 > > Modified Files: > src/sys/kern: vfs_init.c vfs_subr.c > src/sys/sys: mount.h > > Log Message: > introduce

re: CVS commit: src/sys

2021-02-04 Thread matthew green
Roy Marples writes: > On 03/02/2021 21:45, David Young wrote: > > On Wed, Feb 03, 2021 at 05:51:40AM +, Roy Marples wrote: > >> Module Name: src > >> Committed By: roy > >> Date: Wed Feb 3 05:51:40 UTC 2021 > >> > >> Modified Files: > >>src/sys/net: if_arp.h

Re: CVS commit: src/sys/arch/hppa/gsc

2021-02-04 Thread Michael
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:

Re: CVS commit: src/sys

2021-02-04 Thread Roy Marples
On 03/02/2021 21:45, David Young wrote: On Wed, Feb 03, 2021 at 05:51:40AM +, Roy Marples wrote: Module Name:src Committed By: roy Date: Wed Feb 3 05:51:40 UTC 2021 Modified Files: src/sys/net: if_arp.h if_ether.h if_gre.h src/sys/netinet: if_ether.h igmp.h

Re: CVS commit: src/sys/arch/hppa/gsc

2021-02-04 Thread Tetsuya Isaki
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

Re: CVS commit: src/sys

2021-02-03 Thread David Young
On Wed, Feb 03, 2021 at 05:51:40AM +, Roy Marples wrote: > Module Name: src > Committed By: roy > Date: Wed Feb 3 05:51:40 UTC 2021 > > Modified Files: > src/sys/net: if_arp.h if_ether.h if_gre.h > src/sys/netinet: if_ether.h igmp.h in.h ip.h ip6.h ip_carp.h ip_icmp.h >

Re: CVS commit: src/sys

2021-02-03 Thread Kamil Rytarowski
On 03.02.2021 16:52, Roy Marples wrote: > But you *have* to interogate the headers in order to work this out. I noted how this could break. I'm right now not affected by this myself. Please monitor gnats for reports. I defer any decisions and discussions (if any) now to others.

Re: CVS commit: src/sys/arch/hppa/gsc

2021-02-03 Thread Michael
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

Re: CVS commit: src/sys

2021-02-03 Thread Roy Marples
On 03/02/2021 12:54, Kamil Rytarowski wrote: This is still a valid usage and ABI breakage for userland. You cannot blame a user for using system structures and headers that stop working after an upgrade, at least before at least libc version bump. For the record, I broke ABI here (it was the

Re: CVS commit: src/sys

2021-02-03 Thread Joerg Sonnenberger
On Wed, Feb 03, 2021 at 11:03:25AM +0100, Kamil Rytarowski wrote: > On 03.02.2021 06:51, Roy Marples wrote: > > Module Name:src > > Committed By: roy > > Date: Wed Feb 3 05:51:40 UTC 2021 > > > > Modified Files: > > src/sys/net: if_arp.h if_ether.h if_gre.h > >

Re: CVS commit: src/sys

2021-02-03 Thread Kamil Rytarowski
On 03.02.2021 13:39, Roy Marples wrote: > On 03/02/2021 10:03, Kamil Rytarowski wrote: >> On 03.02.2021 06:51, Roy Marples wrote: >>> Module Name:    src >>> Committed By:    roy >>> Date:    Wed Feb  3 05:51:40 UTC 2021 >>> >>> Modified Files: >>> src/sys/net: if_arp.h if_ether.h if_gre.h

Re: CVS commit: src/sys

2021-02-03 Thread Roy Marples
On 03/02/2021 10:03, Kamil Rytarowski wrote: On 03.02.2021 06:51, Roy Marples wrote: Module Name:src Committed By: roy Date: Wed Feb 3 05:51:40 UTC 2021 Modified Files: src/sys/net: if_arp.h if_ether.h if_gre.h src/sys/netinet: if_ether.h igmp.h in.h ip.h ip6.h

Re: CVS commit: src/sys

2021-02-03 Thread Roy Marples
On 03/02/2021 08:34, Joerg Sonnenberger wrote: On Wed, Feb 03, 2021 at 05:51:40AM +, Roy Marples wrote: Module Name:src Committed By: roy Date: Wed Feb 3 05:51:40 UTC 2021 Modified Files: src/sys/net: if_arp.h if_ether.h if_gre.h src/sys/netinet: if_ether.h

Re: CVS commit: src/sys

2021-02-03 Thread Kamil Rytarowski
On 03.02.2021 06:51, Roy Marples wrote: > Module Name: src > Committed By: roy > Date: Wed Feb 3 05:51:40 UTC 2021 > > Modified Files: > src/sys/net: if_arp.h if_ether.h if_gre.h > src/sys/netinet: if_ether.h igmp.h in.h ip.h ip6.h ip_carp.h ip_icmp.h > ip_mroute.h

Re: CVS commit: src/sys

2021-02-03 Thread Joerg Sonnenberger
On Wed, Feb 03, 2021 at 05:51:40AM +, Roy Marples wrote: > Module Name: src > Committed By: roy > Date: Wed Feb 3 05:51:40 UTC 2021 > > Modified Files: > src/sys/net: if_arp.h if_ether.h if_gre.h > src/sys/netinet: if_ether.h igmp.h in.h ip.h ip6.h ip_carp.h ip_icmp.h >

Re: CVS commit: src/sys/dev/pci

2021-02-01 Thread J. Hannken-Illjes
> On 12. Jul 2020, at 21:05, Jaromir Dolecek wrote: > > Module Name: src > Committed By: jdolecek > Date: Sun Jul 12 19:05:32 UTC 2020 > > Modified Files: > src/sys/dev/pci: if_bnx.c if_bnxvar.h > > Log Message: > enable MSI/MSI-X if supported by adapter > > tested MSI-X with

Re: CVS commit: src/sys/net

2021-01-31 Thread Kengo NAKAHARA
Hi, I have one question about the following commit. Why stoeplitz_hash_ip4() and stoeplitz_hash_ip4port() argument types are different between toeplitz.c and toeplitz.h? They have in_addr_t and in_port_t argument types in toeplitz.c, howerver uint32_t and uint16_t in toeplitz.h. On 2021/01/31

Re: CVS commit: src/sys/sys

2021-01-26 Thread Jason Thorpe
> On Jan 26, 2021, at 6:49 PM, Valery Ushakov wrote: > > It's hardly fair to characterize three people politely inquiring about > that choice and pointing out a more standard way to spell what you > want to express (that is perfectly in rhyme with the preceding table > and is only one

Re: CVS commit: src/sys/sys

2021-01-26 Thread Valery Ushakov
On Wed, Jan 27, 2021 at 01:00:05 +, Jason R Thorpe wrote: > Module Name: src > Committed By: thorpej > Date: Wed Jan 27 01:00:05 UTC 2021 > > Modified Files: > src/sys/sys: device.h > > Log Message: > Define a macro to terminate the common usage of device_compatible_entry >

Re: CVS commit: src/sys/dev/pci

2021-01-26 Thread Reinoud Zandijk
On Tue, Jan 26, 2021 at 05:51:42PM +0900, Rin Okuyama wrote: > Hi, > This seems not correct for me. Is the attached patch OK with you? Well you spotted a bug indeed int he freeing section. I'll fix and commit it. Thanks for reporting. Reinoud signature.asc Description: PGP signature

Re: CVS commit: src/sys/dev/pci

2021-01-26 Thread Rin Okuyama
Hi, On 2021/01/25 0:33, Reinoud Zandijk wrote: Module Name:src Committed By: reinoud Date: Sun Jan 24 15:33:02 UTC 2021 Modified Files: src/sys/dev/pci: virtio_pci.c Log Message: On error unmap the pci_mapreg_map()d regions using bus_space_unmap() as suggested by jak@

Re: CVS commit: src/sys/arch

2021-01-25 Thread Jason Thorpe
> 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

Re: CVS commit: src/sys/arch

2021-01-25 Thread Kamil Rytarowski
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

Re: CVS commit: src/sys/arch

2021-01-25 Thread Valery Ushakov
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

Re: CVS commit: src/sys/arch

2021-01-25 Thread Robert Elz
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

Re: CVS commit: src/sys/arch

2021-01-25 Thread Valery Ushakov
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

Re: CVS commit: src/sys/arch

2021-01-25 Thread Jason Thorpe
> 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. --

Re: CVS commit: src/sys/arch

2021-01-25 Thread Kamil Rytarowski
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 >

Re: CVS commit: src/sys/dev/pci

2021-01-25 Thread Jason Thorpe
> On Jan 24, 2021, at 10:20 PM, Martin Husemann wrote: > >> I kept getting a ?static after non-static declaration? error when building >> for aarch64. > > I guess that was with outdated arm/include/bus_funcs.h and > sys/bus_proto.h (or where was the previous declaration)? I did a “cvs

Re: CVS commit: src/sys/dev/pci

2021-01-24 Thread Martin Husemann
On Sun, Jan 24, 2021 at 09:45:14PM -0800, Jason Thorpe wrote: > > > On Jan 24, 2021, at 9:37 PM, Martin Husemann wrote: > > > > While I don't care for names, I would like to understand fallout in > > details before hiding it - what exactly did not compile correctly? > > At least the affected

Re: CVS commit: src/sys/dev/pci

2021-01-24 Thread Jason Thorpe
> On Jan 24, 2021, at 9:37 PM, Martin Husemann wrote: > > While I don't care for names, I would like to understand fallout in > details before hiding it - what exactly did not compile correctly? > At least the affected arm kernels worked for me in the state directly > before your commit. I

Re: CVS commit: src/sys/dev/pci

2021-01-24 Thread Martin Husemann
On Sun, Jan 24, 2021 at 03:34:08PM +, Jason R Thorpe wrote: > Module Name: src > Committed By: thorpej > Date: Sun Jan 24 15:34:08 UTC 2021 > > Modified Files: > src/sys/dev/pci: virtio_pci.c > > Log Message: > Redefining bus_space functions in drivers is a bad idea, and we

Re: CVS commit: src/sys/dev/pci

2021-01-23 Thread Jason Thorpe
> On Jan 23, 2021, at 5:40 PM, Christos Zoulas wrote: > >> it's a bad example. someone might copy it into another >> driver that _doesn't_ work with this version, but may seem >> to fix a build error. >> >> that's why i wanted to wrap the usage to make it clear if >> someone were to copy it

Re: CVS commit: src/sys/dev/pci

2021-01-23 Thread Christos Zoulas
In article <17141.1611452...@splode.eterna.com.au>, matthew green wrote: >Christos Zoulas writes: >> In article <20210123230600.52be160...@jupiter.mumble.net>, >> Taylor R Campbell wrote: >> > >> >Conversely, how do you know whether this hacked-up implementation >> >which tears the write into

re: CVS commit: src/sys/dev/pci

2021-01-23 Thread matthew green
Christos Zoulas writes: > In article <20210123230600.52be160...@jupiter.mumble.net>, > Taylor R Campbell wrote: > > > >Conversely, how do you know whether this hacked-up implementation > >which tears the write into two will actually work? Maybe it works for > >virtio but there are likely other

Re: CVS commit: src/sys/dev/pci

2021-01-23 Thread Christos Zoulas
In article <20210123230600.52be160...@jupiter.mumble.net>, Taylor R Campbell wrote: > >Conversely, how do you know whether this hacked-up implementation >which tears the write into two will actually work? Maybe it works for >virtio but there are likely other devices out there for which it will

Re: CVS commit: src/sys/dev/pci

2021-01-23 Thread Taylor R Campbell
> Date: Sat, 23 Jan 2021 22:59:22 - (UTC) > From: chris...@astron.com (Christos Zoulas) > > In article <23974.1611441...@splode.eterna.com.au>, > matthew green wrote: > >this seems dangerous to me. we don't define it on > >some platforms because we can't, so having it faked > >out here

Re: CVS commit: src/sys/dev/pci

2021-01-23 Thread Christos Zoulas
In article <23974.1611441...@splode.eterna.com.au>, matthew green wrote: >"Christos Zoulas" writes: >> Module Name: src >> Committed By:christos >> Date:Sat Jan 23 20:00:19 UTC 2021 >> >> Modified Files: >> src/sys/dev/pci: virtio_pci.c >> >> Log Message: >> Provide

re: CVS commit: src/sys/dev/pci

2021-01-23 Thread matthew green
"Christos Zoulas" writes: > Module Name: src > Committed By: christos > Date: Sat Jan 23 20:00:19 UTC 2021 > > Modified Files: > src/sys/dev/pci: virtio_pci.c > > Log Message: > Provide a generic bus_space_write_8 function that is bi-endian. this seems dangerous to me. we don't

Re: CVS commit: src/sys/dev/pci

2021-01-23 Thread Christos Zoulas
In article , Reinoud Zandijk wrote: >On Fri, Jan 22, 2021 at 04:54:51PM +1100, matthew green wrote: >> > +#ifndef _LP64 >> >> _LP64 is a terrible way to make this choice. >> >> heaps of our 32 bit platforms implement the _8 variants. > >Can't we then just make sure they have the 8 bit variant?

Re: CVS commit: src/sys/dev/pci

2021-01-23 Thread Christos Zoulas
In article , Nick Hudson wrote: >On 22/01/2021 04:48, Christos Zoulas wrote: >> +#if _QUAD_HIGHWORD >> +bus_space_write_4(iot, ioh, offset, (uint32_t)(value & 0x)); >> +bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value >> 32)); >> +#else >> +bus_space_write_4(iot, ioh,

Re: CVS commit: src/sys/kern (kern_event.c)

2021-01-22 Thread Paul Goyette
On Fri, 22 Jan 2021, Paul Goyette wrote: On Thu, 21 Jan 2021, Paul Goyette wrote: Ooopppsss ignore me - looks like this was already fixed and my update missed it. I'll retry. OK, I built and installed a new kernel+userland. Most everything works, and syslogd seems to work fine (at least,

Re: CVS commit: src/sys/kern (kern_event.c)

2021-01-22 Thread Paul Goyette
On Thu, 21 Jan 2021, Paul Goyette wrote: Ooopppsss ignore me - looks like this was already fixed and my update missed it. I'll retry. OK, I built and installed a new kernel+userland. Most everything works, and syslogd seems to work fine (at least, it no longer panics during startup).

Re: CVS commit: src/sys/dev/pci

2021-01-22 Thread Reinoud Zandijk
On Fri, Jan 22, 2021 at 04:54:51PM +1100, matthew green wrote: > > +#ifndef _LP64 > > _LP64 is a terrible way to make this choice. > > heaps of our 32 bit platforms implement the _8 variants. Can't we then just make sure they have the 8 bit variant? and set a define if its atomic or not? This

Re: CVS commit: src/sys/arch/evbarm/conf

2021-01-22 Thread Jared McNeill
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

Re: CVS commit: src/sys/dev/pci

2021-01-22 Thread Nick Hudson
On 22/01/2021 04:48, Christos Zoulas wrote: +#if _QUAD_HIGHWORD + bus_space_write_4(iot, ioh, offset, (uint32_t)(value & 0x)); + bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value >> 32)); +#else + bus_space_write_4(iot, ioh, offset, (uint32_t)(value >> 32)); +

Re: CVS commit: src/sys/dev/pci

2021-01-21 Thread Christos Zoulas
In article <27744.1611294...@splode.eterna.com.au>, matthew green wrote: >> +#ifndef _LP64 > >_LP64 is a terrible way to make this choice. > >heaps of our 32 bit platforms implement the _8 variants. Let's add a _HAVE_ variable then? christos

re: CVS commit: src/sys/dev/pci

2021-01-21 Thread matthew green
> +#ifndef _LP64 _LP64 is a terrible way to make this choice. heaps of our 32 bit platforms implement the _8 variants. .mrg.

Re: CVS commit: src/sys/dev/pci

2021-01-21 Thread Christos Zoulas
In article <20210121204833.9ebcff...@cvs.netbsd.org>, Reinoud Zandijk wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: reinoud >Date: Thu Jan 21 20:48:33 UTC 2021 > >Modified Files: > src/sys/dev/pci: virtio_pci.c > >Log Message: >Remove dependency on bus_space_write_8()

Re: CVS commit: src/sys/kern (kern_event.c)

2021-01-21 Thread Paul Goyette
Ooopppsss ignore me - looks like this was already fixed and my update missed it. I'll retry. On Thu, 21 Jan 2021, Paul Goyette wrote: This change seems to break everything! As soon as I try to start syslogd I hit the panic() that you added [ 28.0253983] panic: kqueue_scan,1491:

Re: CVS commit: src/sys/kern (kern_event.c)

2021-01-21 Thread Paul Goyette
This change seems to break everything! As soon as I try to start syslogd I hit the panic() that you added [ 28.0253983] panic: kqueue_scan,1491: kq=0xdc13890bc4c0 kq->kq_count(1) != count(0), nmarker=1 [ 28.0253983] cpu0: Begin traceback... [ 28.0253983] vpanic() at

Re: CVS commit: src/sys/arch/evbarm/conf

2021-01-21 Thread Jared McNeill
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

Re: CVS commit: src/sys/kern

2021-01-21 Thread Tom Spindler (moof)
I believe it's this change that's made my vbox image panic at the drop of a hat; while it occasionally panics before it even hits single user, it also consistently panics when starting syslogd (even from single-user): panic: kqueue_scan,1491: kq=0xc779aeff6dc0 kq->kq_count(1) != count(0),

Re: CVS commit: src/sys/dev

2021-01-21 Thread Jason Thorpe
> On Jan 21, 2021, at 12:00 AM, Martin Husemann > wrote: > > On Wed, Jan 20, 2021 at 07:46:48PM +, Reinoud Zandijk wrote: >> Module Name: src >> Committed By:reinoud >> Date:Wed Jan 20 19:46:48 UTC 2021 >> > [..] >> Log Message: >> Add VirtIO PCI v1.0 attachments

Re: CVS commit: src/sys/dev

2021-01-21 Thread Martin Husemann
On Wed, Jan 20, 2021 at 07:46:48PM +, Reinoud Zandijk wrote: > Module Name: src > Committed By: reinoud > Date: Wed Jan 20 19:46:48 UTC 2021 > [..] > Log Message: > Add VirtIO PCI v1.0 attachments and fix the drivers affected. > > * virtio on sparc64 attaches but is it not

re: CVS commit: src/sys/arch

2021-01-20 Thread matthew green
"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

  1   2   3   4   5   6   7   8   9   10   >