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

On 2018/08/19 0:06, Jason Thorpe wrote: On 2018/08/18 20:08, Rin Okuyama wrote: Ah, then it should be "if ARM32". It was "if arm32" in rev. 1.31. Sorry, not 1.31 but 1.30. That's because all options are normalized to lower-case. Oops, not "if" but "ifdef". "ifdef" statements refer

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

On 2018/08/18 22:41, Jared McNeill wrote: Not sure I understand this change. arm32 should be defined on 32-bit evbarm platforms via std.evbarm. If arm32 is not defined, I wouldn't expect a kernel to link as there are dependencies on it in arch/arm/conf/files.arm as well. No "arm32" is not

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

> On Aug 18, 2018, at 7:59 AM, Rin Okuyama wrote: > > On 2018/08/18 20:08, Rin Okuyama wrote: >> Ah, then it should be "if ARM32". It was "if arm32" in rev. 1.31. > > Sorry, not 1.31 but 1.30. That's because all options are normalized to lower-case. -- thorpej

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

On 2018/08/18 20:08, Rin Okuyama wrote: Ah, then it should be "if ARM32". It was "if arm32" in rev. 1.31. Sorry, not 1.31 but 1.30. On 2018/08/18 18:51, Nick Hudson wrote: On 18/08/2018 10:29, Rin Okuyama wrote: Module Name:    src Committed By:    rin Date:    Sat Aug 18 09:29:45 UTC

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

Not sure I understand this change. arm32 should be defined on 32-bit evbarm platforms via std.evbarm. If arm32 is not defined, I wouldn't expect a kernel to link as there are dependencies on it in arch/arm/conf/files.arm as well. On Sat, 18 Aug 2018, Rin Okuyama wrote: Module Name:

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

Ah, then it should be "if ARM32". It was "if arm32" in rev. 1.31. On 2018/08/18 18:51, Nick Hudson wrote: On 18/08/2018 10:29, Rin Okuyama wrote: Module Name:    src Committed By:    rin Date:    Sat Aug 18 09:29:45 UTC 2018 Modified Files: src/sys/arch/evbarm/conf: files.evbarm Log

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

On 18/08/2018 10:29, Rin Okuyama wrote: Module Name:src Committed By: rin Date: Sat Aug 18 09:29:45 UTC 2018 Modified Files: src/sys/arch/evbarm/conf: files.evbarm Log Message: Fix a bug introduced in the previous revision; We don't define arm32 anywhere, and

Re: CVS commit: src/sys/arch

In article <20180810182215.1494684...@mail.netbsd.org>, Leonardo Taccari wrote: >Hello Sevan, > >"Sevan Janiyan" writes: >> Module Name: src >> Committed By:sevan >> Date:Fri Aug 10 17:54:46 UTC 2018 >> >> Modified Files: >> src/sys/arch/amd64/conf: GENERIC >>

Re: CVS commit: src/sys/arch

Hello Sevan, "Sevan Janiyan" writes: > Module Name: src > Committed By: sevan > Date: Fri Aug 10 17:54:46 UTC 2018 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC > src/sys/arch/i386/conf: GENERIC > > Log Message: > Add snippet for bpfjit(4) as both i386 and amd64 are

re: CVS commit: src/sys/arch/x86

"Maxime Villard" writes: > Module Name: src > Committed By: maxv > Date: Tue Aug 7 10:50:12 UTC 2018 > > Modified Files: > src/sys/arch/x86/include: specialreg.h > src/sys/arch/x86/x86: errata.c > > Log Message: > Add five errata for AMD Family 17h (Ryzen etc), tested by

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

Le 08/08/2018 à 20:13, Ryo Shimizu a écrit : It would be nice to set SCTLR_EL1.WXN, by the way. Yes, It is easy. But should this be synchronized with security.pax.mprotect.enabled? If so, we need a md-hook in the sysctl helper of pax.mprotect.enable. Ah, I misunderstood the meaning of

re: CVS commit: src/sys/arch/mips/mips

m...@netbsd.org writes: > Can we use aprint_debug instead? it's not an autoconf message, so, please don't use aprint*(). .mrg. > On Wed, Aug 08, 2018 at 07:50:13AM +, Simon Burge wrote: > > Module Name:src > > Committed By: simonb > > Date: Wed Aug 8 07:50:12

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

>Also, why don't we tag each userland page with LX_BLKPAG_PXN? Oh... I overlooked that. Certainly, no userland page should not be set executable for kernel. I'll fix. >It would be nice to set SCTLR_EL1.WXN, by the way. Yes, It is easy. But should this be synchronized with

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

Le 04/08/2018 à 17:24, Ryo Shimizu a écrit : Maybe we should just pass the protection bits in l2_setblocks, and map the kernel text/rodata as RO right away. It would also make it possible to map rodata/data as non executable, with PXN|UXN. (Looking at the code it seems to me rodata/data are

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

On Wed, Aug 08, 2018 at 10:22:33PM +1000, Simon Burge wrote: > Martin Husemann wrote: > > > On Wed, Aug 08, 2018 at 12:11:39PM +, m...@netbsd.org wrote: > > > On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote: > > > > On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org

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

On Wed, 8 Aug 2018, Martin Husemann wrote: On Wed, Aug 08, 2018 at 12:11:39PM +, m...@netbsd.org wrote: On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote: On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote: Can we use aprint_debug instead? It is not even

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

Martin Husemann wrote: > On Wed, Aug 08, 2018 at 12:11:39PM +, m...@netbsd.org wrote: > > On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote: > > > On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote: > > > > Can we use aprint_debug instead? > > > > > > It is not

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

On Wed, Aug 08, 2018 at 12:11:39PM +, m...@netbsd.org wrote: > On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote: > > On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote: > > > Can we use aprint_debug instead? > > > > It is not even usefull for general debugging

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

On Wed, Aug 08, 2018 at 01:59:46PM +0200, Martin Husemann wrote: > On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote: > > Can we use aprint_debug instead? > > It is not even usefull for general debugging IMHO. > > Martin I like the idea of removing the messages entirely. The code

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

On Wed, Aug 08, 2018 at 11:49:21AM +, m...@netbsd.org wrote: > Can we use aprint_debug instead? It is not even usefull for general debugging IMHO. Martin

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

Can we use aprint_debug instead? On Wed, Aug 08, 2018 at 07:50:13AM +, Simon Burge wrote: > Module Name: src > Committed By: simonb > Date: Wed Aug 8 07:50:12 UTC 2018 > > Modified Files: > src/sys/arch/mips/mips: cpu_exec.c > > Log Message: > Make change of ABI printf()s

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

> On Aug 5, 2018, at 1:55 AM, Martin Husemann wrote: > > On Sat, Aug 04, 2018 at 06:33:20AM -0700, Jason Thorpe wrote: >> It only matters when setting / removing breakpoints, so it seems like >> you want to defer changing page protection right until then. > > Can't we do the breakpoint

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

On Sat, Aug 04, 2018 at 06:33:20AM -0700, Jason Thorpe wrote: > It only matters when setting / removing breakpoints, so it seems like > you want to defer changing page protection right until then. Can't we do the breakpoint changes via the direct map instead? Martin

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

> On Aug 4, 2018, at 2:09 AM, Maxime Villard wrote: > > Regarding the DDB ifndef, probably there must be > a bit in ARM64 saying "disable page protection", so it could be set when > we enter DDB, and we could remove the ifndef. It only matters when setting / removing breakpoints, so it seems

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

>Maybe we should just pass the protection bits in l2_setblocks, and map the >kernel text/rodata as RO right away. It would also make it possible to map >rodata/data as non executable, with PXN|UXN. (Looking at the code it seems >to me rodata/data are executable currently.) > >We would make three

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

Date:Sat, 4 Aug 2018 14:33:13 +0100 From:Nick Hudson Message-ID: | I'll take a look Great, thanks. http://releng.netbsd.org/builds/HEAD/201808040510Z/ provides links to the error logs of the failing builds (ignore the one that fails building "file" -

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

On 04/08/2018 14:27, Robert Elz wrote: Module Name:src Committed By: kre Date: Sat Aug 4 13:27:03 UTC 2018 Modified Files: src/sys/arch/evbarm/bcm53xx: bcm53xx_machdep.c Log Message: Hack workaround to deal with KERN_VTOPHYS and KERN_PHYSTOV now being defined in

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

Module Name:src Committed By: ryo Date: Fri Aug 3 16:32:55 UTC 2018 Modified Files: src/sys/arch/aarch64/aarch64: genassym.cf locore.S src/sys/arch/aarch64/conf: kern.ldscript Log Message: set kernel text/rodata readonly when not defined DDB. set readonly

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

On Jul 18, 12:04am, r...@nerv.org (Ryo Shimizu) wrote: -- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64 | kern_vtopdiff has already been fixed. (thanks christos@) | u_int uboot_args[4] (in various file :-P) has same problem. | Should I fix it? [Y/y] I just did. christos

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

On Jul 18, 12:57am, r...@nerv.org (Ryo Shimizu) wrote: -- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64 | | >On Jul 18, 12:04am, r...@nerv.org (Ryo Shimizu) wrote: | >-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64 | > | >| kern_vtopdiff has already been fixed. (tha

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

>On Jul 18, 12:04am, r...@nerv.org (Ryo Shimizu) wrote: >-- Subject: Re: CVS commit: src/sys/arch/aarch64/aarch64 > >| kern_vtopdiff has already been fixed. (thanks christos@) >| u_int uboot_args[4] (in various file :-P) has same problem. >| Should I fix it? [Y/y] > >

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

>On Tue, Jul 17, 2018 at 11:12:41AM +, Ryo Shimizu wrote: >> Module Name: src >> Committed By:ryo >> Date:Tue Jul 17 11:12:41 UTC 2018 >> >> Modified Files: >> src/sys/arch/aarch64/aarch64: aarch64_machdep.c >> >> Log Message: >> kern_vtopdiff is stored in

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

In article <2018071711.5b119f...@cvs.netbsd.org>, Joerg Sonnenberger wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: joerg >Date: Tue Jul 17 11:55:55 UTC 2018 > >Modified Files: > src/sys/arch/aarch64/include: types.h > >Log Message: >Be consistent and explicitly size

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

On Tue, Jul 17, 2018 at 11:12:41AM +, Ryo Shimizu wrote: > Module Name: src > Committed By: ryo > Date: Tue Jul 17 11:12:41 UTC 2018 > > Modified Files: > src/sys/arch/aarch64/aarch64: aarch64_machdep.c > > Log Message: > kern_vtopdiff is stored in fdt_start.S. that is before

Re: CVS commit: src/sys/arch/arm/arm32

On Tue, Jul 17, 2018 at 05:29:07AM +, Martin Husemann wrote: > Module Name: src > Committed By: martin > Date: Tue Jul 17 05:29:07 UTC 2018 > > Modified Files: > src/sys/arch/arm/arm32: bus_dma.c > > Log Message: > Revert previous and cast to u_quad_t instead (t is for

Re: CVS commit: src/sys/arch

On 14.07.2018 18:29, m...@netbsd.org wrote: > On Sat, Jul 14, 2018 at 03:09:41PM +, Maxime Villard wrote: >> Module Name: src >> Committed By:maxv >> Date:Sat Jul 14 15:09:41 UTC 2018 >> >> Modified Files: >> src/sys/arch/bebox/conf: INSTALL >>

Re: CVS commit: src/sys/arch/arm/include

In article <20180715143050.ga28...@britannica.bec.de>, Joerg Sonnenberger wrote: >On Sat, Jul 14, 2018 at 08:36:13PM -0400, Christos Zoulas wrote: >> Module Name: src >> Committed By:christos >> Date:Sun Jul 15 00:36:13 UTC 2018 >> >> Modified Files: >>

Re: CVS commit: src/sys/arch/arm/include

On Sat, Jul 14, 2018 at 08:36:13PM -0400, Christos Zoulas wrote: > Module Name: src > Committed By: christos > Date: Sun Jul 15 00:36:13 UTC 2018 > > Modified Files: > src/sys/arch/arm/include: int_fmtio.h > > Log Message: > Fix formats for gcc where int64 is long not long long

Re: CVS commit: src/sys/arch/x86/include

On Sun, 15 Jul 2018, Paul Goyette wrote: Any chance that this will fix kern/52919? If not, can we do some additional re-arrangement of struct cpu_info to address the problem? And in any case, shouldn't this cause a bump in kernel version, since you've changed a structure that is shared

Re: CVS commit: src/sys/arch/x86/include

Any chance that this will fix kern/52919? If not, can we do some additional re-arrangement of struct cpu_info to address the problem? On Sun, 15 Jul 2018, Maxime Villard wrote: Module Name:src Committed By: maxv Date: Sun Jul 15 08:47:43 UTC 2018 Modified Files:

Re: CVS commit: src/sys/arch

On Sat, Jul 14, 2018 at 03:09:41PM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Sat Jul 14 15:09:41 UTC 2018 > > Modified Files: > src/sys/arch/bebox/conf: INSTALL > src/sys/arch/evbarm/conf: ARMADAXP ARMADILLO-IOT-G3 BCM5301X BCM56340 >

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

On 08.07.2018 15:56, Christos Zoulas wrote: > In article <20180708092413.gb8...@mail.duskware.de>, > Martin Husemann wrote: >> On Sun, Jul 08, 2018 at 10:49:53AM +0200, Jaromír Dole?ek wrote: Module Name:src Committed By: kamil Date: Sat Jul 7 23:05:50 UTC 2018

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

On 08.07.2018 10:49, Jaromír Doleček wrote: > Shouldn't this: > > memtop |= (uint16_t)mpbios_page[0x414] << 8; > > be actually << 16 to keep the same semantics? > No. This is a 2-byte (x86 word) variable. One byte has to be stored with the 8 bits shift. If it would be differently it would

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

In article <20180708092413.gb8...@mail.duskware.de>, Martin Husemann wrote: >On Sun, Jul 08, 2018 at 10:49:53AM +0200, Jaromír Dole?ek wrote: >> > Module Name:src >> > Committed By: kamil >> > Date: Sat Jul 7 23:05:50 UTC 2018 >> > >> > Modified Files: >> >

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

On Sun, Jul 08, 2018 at 10:49:53AM +0200, Jaromír Dole?ek wrote: > > Module Name:src > > Committed By: kamil > > Date: Sat Jul 7 23:05:50 UTC 2018 > > > > Modified Files: > > src/sys/arch/x86/x86: mpbios.c > > > > Log Message: > > Remove unaligned access to mpbios_page[] >

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

Shouldn't this: memtop |= (uint16_t)mpbios_page[0x414] << 8; be actually << 16 to keep the same semantics? Jaromir Le dim. 8 juil. 2018 à 01:05, Kamil Rytarowski a écrit : > > Module Name:src > Committed By: kamil > Date: Sat Jul 7 23:05:50 UTC 2018 > > Modified Files: >

Re: CVS commit: src/sys/arch

Le 20/06/2018 à 21:26, Jaromír Doleček a écrit : 2018-06-20 18:03 GMT+02:00 Maxime Villard : I haven't tested but looking at the code it seems to me that this part of your change breaks DAZ on native, and I don't see how it can help xsave on xen by the way Thanks, I'll change the conditional

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

Le 22/06/2018 à 03:40, matthew green a écrit : "Maxime Villard" writes: Module Name:src Committed By: maxv Date: Tue Jun 19 09:25:13 UTC 2018 Modified Files: src/sys/arch/x86/x86: fpu.c Log Message: When using EagerFPU, create the fpu state in execve at IPL_HIGH. why

re: CVS commit: src/sys/arch/x86/x86

"Maxime Villard" writes: > Module Name: src > Committed By: maxv > Date: Tue Jun 19 09:25:13 UTC 2018 > > Modified Files: > src/sys/arch/x86/x86: fpu.c > > Log Message: > When using EagerFPU, create the fpu state in execve at IPL_HIGH. why splhigh instead of kpreempt_disable()?

Re: CVS commit: src/sys/arch/i386/include

On Sun, Jun 17, 2018 at 03:46:39PM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Sun Jun 17 15:46:39 UTC 2018 > > Modified Files: > src/sys/arch/i386/include: frameasm.h > > Log Message: > i586 and below don't have this 3-byte nop, so use three

Re: CVS commit: src/sys/arch

2018-06-20 18:03 GMT+02:00 Maxime Villard : > I haven't tested but looking at the code it seems to me that this part of > your > change breaks DAZ on native, and I don't see how it can help xsave on xen by > the way Thanks, I'll change the conditional to avoid any potential change of behaviour

Re: CVS commit: src/sys/arch

Le 20/06/2018 à 16:31, Jaromír Doleček a écrit : The function is ever called only with x86_fpu_save >= FPU_SAVE_FXSAVE, so there should be no change in functionality AFAICS. There is a change in functionality, you added an xsave check in a function that is fxsave-specific. xsave != fxsave.

Re: CVS commit: src/sys/arch

The function is ever called only with x86_fpu_save >= FPU_SAVE_FXSAVE, so there should be no change in functionality AFAICS. 2018-06-20 10:34 GMT+02:00 Maxime Villard : > Le 19/06/2018 à 21:50, Jaromir Dolecek a écrit : >> >> Module Name:src >> Committed By: jdolecek >> Date: Tue

Re: CVS commit: src/sys/arch

Le 19/06/2018 à 21:50, Jaromir Dolecek a écrit : Module Name:src Committed By: jdolecek Date: Tue Jun 19 19:50:19 UTC 2018 Modified Files: src/sys/arch/x86/include: fpu.h src/sys/arch/x86/x86: cpu.c fpu.c identcpu.c src/sys/arch/xen/x86: cpu.c Log

Re: CVS commit: src/sys/arch/i386/stand/lib

In article <20180612032531.ga1...@homeworld.netbsd.org>, wrote: >Hi christos! > >Could you explain what makes this necessary in the commit messages in >the future? It isn't very obvious that it fixes a build failure with >MKREPRO for future netbsd'ers, in case it isn't restructured. >Ideally in

Re: CVS commit: src/sys/arch/i386/stand/lib

On Tue, Jun 12, 2018 at 03:25:31AM +, m...@netbsd.org wrote: > Hi christos! > > Could you explain what makes this necessary in the commit messages in > the future? It isn't very obvious that it fixes a build failure with > MKREPRO for future netbsd'ers, in case it isn't restructured. >

Re: CVS commit: src/sys/arch/i386/stand/lib

Hi christos! Could you explain what makes this necessary in the commit messages in the future? It isn't very obvious that it fixes a build failure with MKREPRO for future netbsd'ers, in case it isn't restructured. Ideally in every commit, so it appears in a 'cvs annotate'. Thanks. On Mon, Jun

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

> On Jun 7, 2018, at 7:59 AM, m...@netbsd.org wrote: > > You've changed a default and selectively fixed the one driver that > people noticed breaks from it. How do you know the rest aren't broken? As you know, there is very little certainty in this world. For example, how can I be certain

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

You've changed a default and selectively fixed the one driver that people noticed breaks from it. How do you know the rest aren't broken? On Thu, Jun 07, 2018 at 01:35:31PM +, Jason R Thorpe wrote: > Module Name: src > Committed By: thorpej > Date: Thu Jun 7 13:35:31 UTC 2018 > >

Re: CVS commit: src/sys/arch/arm/broadcom

> On Jun 7, 2018, at 5:14 AM, Jonathan A. Kollasch > wrote: > > I don't disagree. That said, making use of this hardware design did not > seem the most straightforward to me. If you can find a better way to do > it, that'd be great. Yah, it’s definitely awkward to use, although one

Re: CVS commit: src/sys/arch/arm/broadcom

On Thu, Jun 07, 2018 at 05:07:28AM +, Jason R Thorpe wrote: > Module Name: src > Committed By: thorpej > Date: Thu Jun 7 05:07:28 UTC 2018 > > Modified Files: > src/sys/arch/arm/broadcom: bcm2835_bsc.c > > Log Message: > A minimal change to prevent the Raspberry Pi i2c driver

Re: CVS commit: src/sys/arch/usermode/dev

In article <20180601072615.462e4f...@cvs.netbsd.org>, Reinoud Zandijk wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: reinoud >Date: Fri Jun 1 07:26:15 UTC 2018 > >Modified Files: > src/sys/arch/usermode/dev: cpu.c > >Log Message: >Pass the address of the array, this

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

In article <20180601072234.060dcf...@cvs.netbsd.org>, Reinoud Zandijk wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: reinoud >Date: Fri Jun 1 07:22:33 UTC 2018 > >Modified Files: > src/sys/arch/usermode/conf: Makefile.usermode > >Log Message: >Compile NetBSD/userland

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

Can you send me dmesg from this machine? We should be using direct-config if we can. -- thorpej Sent from my iPhone. > On May 15, 2018, at 11:25 AM, Julian Coleman wrote: > > Hi, > >> Oh, but to be clear, the iic instances themselves would not be in conflict, >> because

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

Hi, > Oh, but to be clear, the iic instances themselves would not be in conflict, > because they are direct-configured by THEIR parents, and alipm and tsc wont > both exist on a given machine. Just for info, as it's fixed now. The DS20L has both: alipm0 at pci0 dev 17 function 0: 74KHz

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

Oh, but to be clear, the iic instances themselves would not be in conflict, because they are direct-configured by THEIR parents, and alipm and tsc wont both exist on a given machine. It’s the i2c devices themselves I was referring to in my previous message. The autoconfig system used to be

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

They would have conflicted already in the old stuff. This would be a great application for using direct configuration of i2c on this platform. -- thorpej Sent from my iPhone. > On May 14, 2018, at 6:11 PM, Jonathan A. Kollasch wrote: > > Module Name:src > Committed

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

On Sun, Apr 22, 2018 at 09:09:40PM +0200, Maxime Villard wrote: > I recently told membership-exec that I would be less outspoken, and more > convivial, so here's a try: > > Le 22/04/2018 à 20:51, Joerg Sonnenberger a écrit : > > On Sun, Apr 22, 2018 at 12:36:36PM +0200, Maxime Villard wrote: > >

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

I recently told membership-exec that I would be less outspoken, and more convivial, so here's a try: Le 22/04/2018 à 20:51, Joerg Sonnenberger a écrit : On Sun, Apr 22, 2018 at 12:36:36PM +0200, Maxime Villard wrote: Where are they? I haven't been made aware of any issue related to SVS+clang.

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

On Sun, Apr 22, 2018 at 12:36:36PM +0200, Maxime Villard wrote: > Where are they? I haven't been made aware of any issue related to SVS+clang. Yes, I did make you aware that SVS killed VirtualBox. Joerg

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

On 22.04.2018 12:36, Maxime Villard wrote: > Le 22/04/2018 à 12:32, Kamil Rytarowski a écrit : >> On 22.04.2018 07:46, Maxime Villard wrote: >>> Le 22/04/2018 à 01:25, Joerg Sonnenberger a écrit : Module Name:    src Committed By:    joerg Date:    Sat Apr 21 23:25:01 UTC 2018

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

Le 22/04/2018 à 12:32, Kamil Rytarowski a écrit : On 22.04.2018 07:46, Maxime Villard wrote: Le 22/04/2018 à 01:25, Joerg Sonnenberger a écrit : Module Name:src Committed By:joerg Date:Sat Apr 21 23:25:01 UTC 2018 Modified Files: src/sys/arch/amd64/amd64: locore.S Log

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

Le 22/04/2018 à 01:25, Joerg Sonnenberger a écrit : Module Name:src Committed By: joerg Date: Sat Apr 21 23:25:01 UTC 2018 Modified Files: src/sys/arch/amd64/amd64: locore.S Log Message: Do not use movq for loading arbitrary 64bit immediates. The ISA restricts it to

Re: CVS commit: src/sys/arch/arm/sunxi

On Tue, Apr 03, 2018 at 11:49:51AM -0300, Jared McNeill wrote: > There was mention of using pinctrl entries for it here: > http://linux-sunxi.org/External_interrupts#Device_Tree_Entries > > I was thinking it would be handy to define the functions this way if we ever > wanted to use an interrupt

Re: CVS commit: src/sys/arch/arm/sunxi

On Tue, Apr 03, 2018 at 09:55:40AM -0300, Jared McNeill wrote: > Hi Manuel -- > > On Tue, 3 Apr 2018, Manuel Bouyer wrote: > > > Log Message: > > external interrupt functions are named "eint" in the sunxi_gpio_pins[] > > arrays, while sunxi_gpio_establish() looks for "eint". > > Rename eint to

Re: CVS commit: src/sys/arch/arm/sunxi

Hi Manuel -- On Tue, 3 Apr 2018, Manuel Bouyer wrote: Log Message: external interrupt functions are named "eint" in the sunxi_gpio_pins[] arrays, while sunxi_gpio_establish() looks for "eint". Rename eint to eint in sunxi_gpio_pins[]. Tested with an external interrupt on PH0 on an A20. I

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

On Tue, Mar 13, 2018 at 06:02:54PM +0100, Maxime Villard wrote: > Le 11/03/2018 à 22:30, Joerg Sonnenberger a écrit : > > Haswell, using VTx. It seems to hit a triple fault in db_panic according > > to the vbox.log. > > At which stage of the boot procedure does it happen? Does it happen right >

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

Le 11/03/2018 à 22:30, Joerg Sonnenberger a écrit : On Sat, Mar 10, 2018 at 06:58:39PM +0100, Maxime Villard wrote: Le 09/03/2018 à 20:33, Joerg Sonnenberger a écrit : On Fri, Mar 09, 2018 at 06:36:45PM +0100, Maxime Villard wrote: Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit : On Mon,

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

On Sat, Mar 10, 2018 at 06:58:39PM +0100, Maxime Villard wrote: > Le 09/03/2018 à 20:33, Joerg Sonnenberger a écrit : > > On Fri, Mar 09, 2018 at 06:36:45PM +0100, Maxime Villard wrote: > > > Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit : > > > > On Mon, Feb 26, 2018 at 05:52:50AM +,

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

On Sat, Mar 10, 2018 at 06:58:39PM +0100, Maxime Villard wrote: > hardware-assisted or not? I use hardware-assisted, 4.x and 5.x. I guess also the host CPU will matter (at least in virtualbox). Martin

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

Le 09/03/2018 à 20:33, Joerg Sonnenberger a écrit : On Fri, Mar 09, 2018 at 06:36:45PM +0100, Maxime Villard wrote: Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit : On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote: Module Name:src Committed By: maxv Date: Mon

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

On Fri, Mar 09, 2018 at 06:36:45PM +0100, Maxime Villard wrote: > Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit : > > On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote: > > > Module Name: src > > > Committed By: maxv > > > Date: Mon Feb 26 05:52:50 UTC 2018 >

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

Le 09/03/2018 à 18:36, Maxime Villard a écrit : Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit : On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote: Module Name:src Committed By:maxv Date:Mon Feb 26 05:52:50 UTC 2018 Modified Files: src/sys/arch/amd64/conf:

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

Le 09/03/2018 à 18:14, Joerg Sonnenberger a écrit : On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote: Module Name:src Committed By: maxv Date: Mon Feb 26 05:52:50 UTC 2018 Modified Files: src/sys/arch/amd64/conf: GENERIC Log Message: Enable SVS by

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

On Mon, Feb 26, 2018 at 05:52:50AM +, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Mon Feb 26 05:52:50 UTC 2018 > > Modified Files: > src/sys/arch/amd64/conf: GENERIC > > Log Message: > Enable SVS by default. This broke using VirtualBox and I wouldn't

Re: CVS commit: src/sys/arch/macppc/stand/bootxx

On 03/03/18 22:06, matthew green wrote: > we occasionally have to deal with this and either link against > libgcc or provide them in libkern/libsa. there can be new > things from newer compilers, etc., when it starts emitting > new calls it expects in libgcc or other. kernels should not > be

re: CVS commit: src/sys/arch/macppc/stand/bootxx

> BTW, we already have HAVE_LIBGCC and LIBGCC -that defaults exactly to > ${DESTDIR}/usr/lib/libgcc.a (NB: you need to grep enough too to find > it (LIB\$ in bsd.prog.mk). ah good point. (the original code used the bad way, so this was an old problem already.) .mrg.

re: CVS commit: src/sys/arch/macppc/stand/bootxx

> On 03/03/18 02:06, matthew green wrote: > > you didn't grep enough :-) eg: > > > > dist/gcc/config/rs6000/rs6000.c:prefix = (sel & SAVRES_SAVE) ? > > "_savegpr_" : "_restgpr_"; > > > > is the part that matters. > > Just so I understand, where does this come into play from the bootxx

Re: CVS commit: src/sys/arch/macppc/stand/bootxx

On 03/03/18 09:23, Valery Ushakov wrote: > Please, don't duplicate that line like that, variables were invented > for a reason... LDADD is probably the right one to use here. Sorry, uwe :) I took mrg's recommendation to "putting the old code back for ${HAVE_GCC:U0} > 0 builds" quite literally.

Re: CVS commit: src/sys/arch/macppc/stand/bootxx

On Sat, Mar 03, 2018 at 03:44:57 +, Sevan Janiyan wrote: > Like so? > > > Index: sys/arch/macppc/stand/bootxx/Makefile > === > RCS file: /cvsroot/src/sys/arch/macppc/stand/bootxx/Makefile,v > retrieving revision 1.18 > diff -u

Re: CVS commit: src/sys/arch/macppc/stand/bootxx

On 03/03/18 02:06, matthew green wrote: > you didn't grep enough :-) eg: > > dist/gcc/config/rs6000/rs6000.c:prefix = (sel & SAVRES_SAVE) ? > "_savegpr_" : "_restgpr_"; > > is the part that matters. Just so I understand, where does this come into play from the bootxx side, reason I

Re: CVS commit: src/sys/arch/macppc/stand/bootxx

On 03/03/18 02:06, matthew green wrote: > you didn't grep enough :-) eg: Bah! :) > dist/gcc/config/rs6000/rs6000.c:prefix = (sel & SAVRES_SAVE) ? > "_savegpr_" : "_restgpr_"; > > is the part that matters. > > i don't know you can easily test it. i would recommend > putting the old

re: CVS commit: src/sys/arch/macppc/stand/bootxx

> I did see that but thought that we'd had a toolchain update since then. > grepping the source, the only place I see a reference to it is in > external/gpl3/gcc/dist/libgcc/config/rs6000/crtresxgpr.S:HIDDEN_FUNC(_restgpr_30_x) > lwz 30,-8(11) >

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

Hello, On Sat, 3 Mar 2018 00:27:51 + "Sevan Janiyan" wrote: > Module Name: src > Committed By: sevan > Date: Sat Mar 3 00:27:51 UTC 2018 > > Modified Files: > src/sys/arch/macppc/conf: POWERMAC_G5 > > Log Message: > Return recent changes to configuration

Re: CVS commit: src/sys/arch/macppc/stand/bootxx

On 03/02/18 23:22, Valery Ushakov wrote: > I wonder if this might be dependendent on compiler options (e.g. on > sh4 gcc will emit calls to some libgcc functions only for some > optimization settings). hmm, do you have some optimisation settings in mind that I should test?? Sevan

Re: CVS commit: src/sys/arch/macppc/stand/bootxx

On 03/02/18 23:22, Valery Ushakov wrote: > That was introduced rather recently: > > revision 1.17 > date: 2017-07-16 02:26:46 +0300; author: christos; > branches: 1.17.2; > Avoid missing _restgpr_30_x I did see that but thought that we'd had a toolchain update since then. grepping

Re: CVS commit: src/sys/arch/macppc/stand/bootxx

On Fri, Mar 02, 2018 at 23:15:25 +, Sevan Janiyan wrote: > Module Name: src > Committed By: sevan > Date: Fri Mar 2 23:15:25 UTC 2018 > > Modified Files: > src/sys/arch/macppc/stand/bootxx: Makefile > > Log Message: > Do not pass libgcc.a to linker as it breaks build with

Re: CVS commit: src/sys/arch

On 23.02.2018 16:27, Maxime Villard wrote: > Le 23/02/2018 à 15:37, Joerg Sonnenberger a écrit : >> On Fri, Feb 23, 2018 at 03:35:02PM +0100, Maxime Villard wrote: >>> Le 23/02/2018 à 15:07, Maxime Villard a écrit : > Then figure out why not. Placing random pessimisation options all over >

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

Le 24/02/2018 à 17:30, Christos Zoulas a écrit : In article <18bc2a5a-f82d-91ba-5e52-b262c907b...@m00nbsd.net>, Maxime Villard wrote: Le 24/02/2018 à 11:54, Martin Husemann a écrit : On Sat, Feb 24, 2018 at 11:37:11AM +0100, Maxime Villard wrote: If the macro was defined

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

In article <18bc2a5a-f82d-91ba-5e52-b262c907b...@m00nbsd.net>, Maxime Villard wrote: >Le 24/02/2018 à 11:54, Martin Husemann a écrit : >> On Sat, Feb 24, 2018 at 11:37:11AM +0100, Maxime Villard wrote: >>> If the macro was defined as #if, you would need to do something like:

<    1   2   3   4   5   6   7   8   9   10   >