On 05.09.2019 14:57, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Thu Sep 5 12:57:30 UTC 2019
>
> Modified Files:
> src/sys/arch/amd64/amd64: lock_stubs.S
>
> Log Message:
> Remove unused, and style.
>
>
> To generate a diff of this commit:
> cvs rdiff -
Le 21/08/2019 à 23:47, matthew green a écrit :
"Maxime Villard" writes:
Module Name:src
Committed By: maxv
Date: Wed Aug 21 16:35:10 UTC 2019
Modified Files:
src/sys/arch/amd64/amd64: locore.S
Log Message:
Switch from printf to panic. These messages were notorious for b
"Maxime Villard" writes:
> Module Name: src
> Committed By: maxv
> Date: Wed Aug 21 16:35:10 UTC 2019
>
> Modified Files:
> src/sys/arch/amd64/amd64: locore.S
>
> Log Message:
> Switch from printf to panic. These messages were notorious for being
> unreadable, and at least a clean
In article ,
Maxime Villard wrote:
>
>This isn't correct, with USER_LDT the 32bit LWPs may have non-default segregs,
>besides it is really dumb to mix 32 and 64bit code, part of the reasons why
>I dropped the thing
Yes, it is still missing the check that the compat_netbsd32 function had.
Before
Le 27/06/2019 à 04:00, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Thu Jun 27 02:00:31 UTC 2019
Modified Files:
src/sys/arch/amd64/amd64: machdep.c
Log Message:
Although this is correct, I will let maxv commit it. Still waiting.
To generate a
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 Mes
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 Message:
>> Do not use movq for lo
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 32bi
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 as #if, you would
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:
>>>
>>> SYSCALL
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:
SYSCALL_ENTRY(syscall)
#define SYSCALL_ENTRY_SVS
SYSCALL_ENTRY(syscall_svs)
#und
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:
>
> SYSCALL_ENTRY(syscall)
> #define SYSCALL_ENTRY_SVS
> SYSCALL_ENTRY(syscall_svs)
> #undef SYSCALL_ENTRY_SVS
>
> Where SYSCALL_ENTRY wo
Le 24/02/2018 à 11:14, Martin Husemann a écrit :
On Fri, Feb 23, 2018 at 08:09:09AM +0100, Maxime Villard wrote:
... And? There is only one place where we use .if instead of #if, because there
is a good reason for doing so.
Which reason is that?
Well, look at the code. We want to control wha
On Fri, Feb 23, 2018 at 08:09:09AM +0100, Maxime Villard wrote:
> ... And? There is only one place where we use .if instead of #if, because
> there
> is a good reason for doing so.
Which reason is that?
Martin
Le 22/02/2018 à 17:31, Christos Zoulas a écrit :
In article <7f4de63c-e782-14e6-5554-9b9d23471...@m00nbsd.net>,
Maxime Villard wrote:
Le 22/02/2018 à 15:54, Christos Zoulas a écrit :
In article <20180222140848.70e95f...@cvs.netbsd.org>,
Martin Husemann wrote:
-=-=-=-=-=-
Module Name:
On Feb 23, 8:09am, m...@m00nbsd.net (Maxime Villard) wrote:
-- Subject: Re: CVS commit: src/sys/arch/amd64/amd64
| > The question is do we want to keep using both cpp and assembly macros.
|
| Why wouldn't we? I don't see the problem.
Because it adds complexity.
| ... And? Ther
In article <7f4de63c-e782-14e6-5554-9b9d23471...@m00nbsd.net>,
Maxime Villard wrote:
>Le 22/02/2018 à 15:54, Christos Zoulas a écrit :
>> In article <20180222140848.70e95f...@cvs.netbsd.org>,
>> Martin Husemann wrote:
>>> -=-=-=-=-=-
>>>
>>> Module Name:src
>>> Committed By: mart
Le 22/02/2018 à 15:54, Christos Zoulas a écrit :
In article <20180222140848.70e95f...@cvs.netbsd.org>,
Martin Husemann wrote:
-=-=-=-=-=-
Module Name:src
Committed By: martin
Date: Thu Feb 22 14:08:48 UTC 2018
Modified Files:
src/sys/arch/amd64/amd64: locore.S
Log Mes
In article <20180222140848.70e95f...@cvs.netbsd.org>,
Martin Husemann wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: martin
>Date: Thu Feb 22 14:08:48 UTC 2018
>
>Modified Files:
> src/sys/arch/amd64/amd64: locore.S
>
>Log Message:
>Protect the SVS part of SYSCALL_ENTRY b
e 24/03/2017 à 21:32, co...@sdf.org a écrit :
cool!
I see in arch/i386/i386/locore.S that there is another call gate and
there's:
1246 IDTVEC(osyscall)
1247 #ifndef XEN
1248 /* XXX we are in trouble! interrupts be off here. */
1249 cli /* must be first instru
On Thu, Mar 23, 2017 at 05:25:51PM +, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Thu Mar 23 17:25:51 UTC 2017
>
> Modified Files:
> src/sys/arch/amd64/amd64: locore.S machdep.c trap.c
>
> Log Message:
> Remove this call gate on amd64, it is useless an
Le 29/05/2016 à 11:04, Maxime Villard a écrit :
Module Name:src
Committed By: maxv
Date: Sun May 29 09:04:20 UTC 2016
Modified Files:
src/sys/arch/amd64/amd64: locore.S
Log Message:
Revert rev1.94. It apparently raises a page fault from SMEP. I need to
investigate the wh
Le 07/05/2016 23:13, matthew green a écrit :
Joerg Sonnenberger writes:
On Sat, May 07, 2016 at 11:49:21AM +, Maxime Villard wrote:
Module Name:src
Committed By: maxv
Date: Sat May 7 11:49:21 UTC 2016
Modified Files:
src/sys/arch/amd64/amd64: locore.S
Log Message:
Joerg Sonnenberger writes:
> On Sat, May 07, 2016 at 11:49:21AM +, Maxime Villard wrote:
> > Module Name:src
> > Committed By: maxv
> > Date: Sat May 7 11:49:21 UTC 2016
> >
> > Modified Files:
> > src/sys/arch/amd64/amd64: locore.S
> >
> > Log Message:
> > cl
On Sat, May 07, 2016 at 11:49:21AM +, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Sat May 7 11:49:21 UTC 2016
>
> Modified Files:
> src/sys/arch/amd64/amd64: locore.S
>
> Log Message:
> clarify
WTH. Can you please not mix arbitrary stylistic changes
On Wed, Jul 01, 2015 at 02:04:43AM +, Christos Zoulas wrote:
> In article <20150630233112.ga8...@britannica.bec.de>,
> Joerg Sonnenberger wrote:
> >On Tue, Jun 30, 2015 at 05:08:24PM -0400, Christos Zoulas wrote:
> >> Module Name: src
> >> Committed By: christos
> >> Date:
In article <20150630233112.ga8...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Tue, Jun 30, 2015 at 05:08:24PM -0400, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Tue Jun 30 21:08:24 UTC 2015
>>
>> Modified Files:
>> src/sys/arch/a
On Tue, Jun 30, 2015 at 05:08:24PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Tue Jun 30 21:08:24 UTC 2015
>
> Modified Files:
> src/sys/arch/amd64/amd64: cpu_in_cksum.S
>
> Log Message:
> handle PIC compilation (if we are building a PIE syste
On Tue, May 13, 2014 at 2:28 AM, Jonathan A. Kollasch
wrote:
> On Mon, May 12, 2014 at 07:05:29PM +0200, Joerg Sonnenberger wrote:
>> On Mon, May 12, 2014 at 01:49:24PM +, Masao Uebayashi wrote:
>> > Module Name:src
>> > Committed By: uebayasi
>> > Date: Mon May 12
On Mon, May 12, 2014 at 07:05:29PM +0200, Joerg Sonnenberger wrote:
> On Mon, May 12, 2014 at 01:49:24PM +, Masao Uebayashi wrote:
> > Module Name:src
> > Committed By: uebayasi
> > Date: Mon May 12 13:49:24 UTC 2014
> >
> > Modified Files:
> > src/sys/arch/amd6
On Mon, May 12, 2014 at 01:49:24PM +, Masao Uebayashi wrote:
> Module Name: src
> Committed By: uebayasi
> Date: Mon May 12 13:49:24 UTC 2014
>
> Modified Files:
> src/sys/arch/amd64/amd64: machdep.c
>
> Log Message:
> Don't reserve space (128) on signal stack for unknown reaso
On Sat, Jun 16, 2012 at 08:31:42PM +0100, David Laight wrote:
> On Sat, Jun 16, 2012 at 04:42:27PM +, Joerg Sonnenberger wrote:
> > Module Name:src
> > Committed By: joerg
> > Date: Sat Jun 16 16:42:27 UTC 2012
> >
> > Modified Files:
> > src/sys/arch/amd64/amd6
On Sat, Jun 16, 2012 at 04:42:27PM +, Joerg Sonnenberger wrote:
> Module Name: src
> Committed By: joerg
> Date: Sat Jun 16 16:42:27 UTC 2012
>
> Modified Files:
> src/sys/arch/amd64/amd64: machdep.c
>
> Log Message:
> Annotate tautological if, so that clang doesn't warn about
On 21 April 2012 13:52, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sat Apr 21 18:52:37 UTC 2012
>
> Modified Files:
> src/sys/arch/amd64/amd64: vector.S
>
> Log Message:
> Alignment fault traps push the error code automatically, so don't use ZT
On Apr 22, 12:00am, jeanyves.mig...@free.fr (Jean-Yves Migeon) wrote:
-- Subject: Re: CVS commit: src/sys/arch/amd64/amd64
| It's the other way around; the bug was rather harmless in VMs (kills the
| process with a SIGILL), while it force-reboot the host on a native platform.
I had the
Le 21/04/12 23:25, Christos Zoulas a écrit :
In article<4f930a8c.6040...@free.fr>,
Jean-Yves Migeon wrote:
Le 21/04/12 20:52, Christos Zoulas a écrit :
Module Name:src
Committed By: christos
Date: Sat Apr 21 18:52:37 UTC 2012
Modified Files:
src/sys/arch/amd64/amd64: v
In article <4f930a8c.6040...@free.fr>,
Jean-Yves Migeon wrote:
>Le 21/04/12 20:52, Christos Zoulas a écrit :
> > Module Name:src
> > Committed By: christos
> > Date: Sat Apr 21 18:52:37 UTC 2012
> >
> > Modified Files:
> > src/sys/arch/amd64/amd64: vector.S
> >
> >
I just tested with a new updated kernel.
It no longer crashes. Instead, it reports an expected failure:
x86 architecture does not correctly report the
address where the unaligned access occurred:
/build/netbsd-local/src/tests/lib/libc/gen/t_siginfo.c:427:
info->s
Le 21/04/12 20:52, Christos Zoulas a écrit :
> Module Name: src
> Committed By: christos
> Date: Sat Apr 21 18:52:37 UTC 2012
>
> Modified Files:
>src/sys/arch/amd64/amd64: vector.S
>
> Log Message:
> Alignment fault traps push the error code automatically, so don't use
On Fri, Jul 17, 2009 at 11:35:31AM +, Christos Zoulas wrote:
> >Shouldn't the non-DIAGNOSTIC default case set ksi_signo to something
> >other than 0? I'm not entirely sure what trapsignal will do with
> >signal 0, but I doubt it's the right thing.
>
> Well, if you fall in the default case
In article <20090717053517.ga10...@netbsd.org>,
David Holland wrote:
>On Thu, Jul 16, 2009 at 10:18:09AM -0400, Christos Zoulas wrote:
> > Modified Files:
> > src/sys/arch/amd64/amd64: trap.c
> >
> > Log Message:
> > handle protection fault properly.
>
>Shouldn't the non-DIAGNOSTIC default c
On Thu, Jul 16, 2009 at 10:18:09AM -0400, Christos Zoulas wrote:
> Modified Files:
> src/sys/arch/amd64/amd64: trap.c
>
> Log Message:
> handle protection fault properly.
Shouldn't the non-DIAGNOSTIC default case set ksi_signo to something
other than 0? I'm not entirely sure what trapsi
46 matches
Mail list logo
