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
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
> 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
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
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:
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
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
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
>>
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
"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
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
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
>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
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
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
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
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
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
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
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
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
> 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
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
> 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
>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
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" -
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
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
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
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
>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]
>
>
>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
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
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
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
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
>>
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:
>>
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
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
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:
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
>
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
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
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:
>> >
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[]
>
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:
>
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
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
"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()?
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
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
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.
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
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
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
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.
>
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
> 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
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
>
>
> 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
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
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
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
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
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
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
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
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:
> >
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.
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
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
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
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
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
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
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
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
>
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,
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 +,
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
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
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
>
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:
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
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
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
> 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.
> 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
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.
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
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
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
> 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)
>
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
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
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
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
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
>
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
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:
401 - 500 of 1704 matches
Mail list logo