On Sat, May 11, 2019 at 10:49 AM Greg Troxel wrote:
>
> Kamil Rytarowski writes:
>
> > On 08.05.2019 11:34, Ryota Ozaki wrote:
> >> On Sat, Apr 20, 2019 at 6:45 PM Ryota Ozaki wrote:
> >>>
> >>> On Fri, Apr 19, 2019 at 6:49 PM Kamil Rytarowski wrote:
>
> On 19.04.2019 11:41, J.
Kamil Rytarowski writes:
> On 08.05.2019 11:34, Ryota Ozaki wrote:
>> On Sat, Apr 20, 2019 at 6:45 PM Ryota Ozaki wrote:
>>>
>>> On Fri, Apr 19, 2019 at 6:49 PM Kamil Rytarowski wrote:
On 19.04.2019 11:41, J. Hannken-Illjes wrote:
>> On 19. Apr 2019, at 03:52, Ryota Ozaki wrote:
On 08.05.2019 11:34, Ryota Ozaki wrote:
> On Sat, Apr 20, 2019 at 6:45 PM Ryota Ozaki wrote:
>>
>> On Fri, Apr 19, 2019 at 6:49 PM Kamil Rytarowski wrote:
>>>
>>> On 19.04.2019 11:41, J. Hannken-Illjes wrote:
> On 19. Apr 2019, at 03:52, Ryota Ozaki wrote:
>
> Module Name: src
>
On Thu, May 09, 2019 at 16:48:31 +, Ryo Shimizu wrote:
> Module Name: src
> Committed By: ryo
> Date: Thu May 9 16:48:31 UTC 2019
>
> Modified Files:
> src/sys/arch/sh3/sh3: db_trace.c
>
> Log Message:
> fix backtrace. it was broken.
> - use db_read_bytes() to avoid faults.
Hi,
Has there been any progress on this since 2017-12-03?
I've noticed that ips(4) is missing the man-page, only has
a single revision on ips.c, and is not connected to the build
(neither to ALL nor GENERIC).
Is it intentional for this driver to remain in tree?
(Does it even still
I hope the slop makes everyone happy :-)
christos
Date:Wed, 08 May 2019 06:54:04 +1000
From:matthew green
Message-ID: <7543.1557262...@splode.eterna.com.au>
| > Log Message:
| > Use the max limit (aka maxfiles or the moral equivalent of OPEN_MAX) which
| > makes poll(2) align with the Posix documentation
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Tue May 7 20:10:21 UTC 2019
>
> Modified Files:
> src/sys/kern: sys_select.c
>
> Log Message:
> Use the max limit (aka maxfiles or the moral equivalent of OPEN_MAX) which
> makes poll(2) align with the
On 07.05.2019 03:22, Paul Goyette wrote:
> Just a thought
>
> Currently we have the global sysctl variable, but I wonder if it should
> be made local to a particular emulation and/or to an individual process?
>
I think it would be too much.
We already warn a user with ttyprintf(9) once
Just a thought
Currently we have the global sysctl variable, but I wonder if it should
be made local to a particular emulation and/or to an individual process?
On Tue, 7 May 2019, Kamil Rytarowski wrote:
On 07.05.2019 02:49, matthew green wrote:
I see. I will document in the man page
On 07.05.2019 02:49, matthew green wrote:
>> I see. I will document in the man page that (void *)0 and (void *)1 are
>> special cases and they have to be set with PTRACE_REG_SET_PC()
>> explicitly if really intended.
>>
>> Keeping allowed 0x0 in PT_CONTINUE/PT_DETACH/.. makes it harder to
>>
> I see. I will document in the man page that (void *)0 and (void *)1 are
> special cases and they have to be set with PTRACE_REG_SET_PC()
> explicitly if really intended.
>
> Keeping allowed 0x0 in PT_CONTINUE/PT_DETACH/.. makes it harder to
> distinguish between broken kernel and broken
On 06.05.2019 22:59, Joerg Sonnenberger wrote:
> On Thu, May 02, 2019 at 03:01:31AM +0200, Kamil Rytarowski wrote:
>> We forbid NULL pointer dereference on modern ports. It was certainly
>> used by PDP-11 as there was a special zeroed mask in 0x0 and
>> dereferencing NULL pointer was returning
On Thu, May 02, 2019 at 03:01:31AM +0200, Kamil Rytarowski wrote:
> We forbid NULL pointer dereference on modern ports. It was certainly
> used by PDP-11 as there was a special zeroed mask in 0x0 and
> dereferencing NULL pointer was returning zero.
No, we forbid NULL pointer dereferences on
On 04/05/2019 06:04, Tetsuya Isaki wrote:
> amiga/GENERIC is generated from GENERIC.in .
I realised after, now trying to ditch the m4 with the intent that there
is a GENERIC.common that is built upon by the different configs.
> What is the difference in m68k family?
> Enabled: amiga, cesfic,
That's a good point. Should I revert to something similar like before,
or do you have a better idea?
Thanks,
christos
> On May 5, 2019, at 9:09 PM, Robert Elz wrote:
>
>Date:Sun, 5 May 2019 16:38:04 -0400
>From:Christos Zoulas
>Message-ID:
On 05.05.2019 22:22, matthew green wrote:
> "Kamil Rytarowski" writes:
>> Module Name: src
>> Committed By:kamil
>> Date:Fri May 3 22:34:21 UTC 2019
>>
>> Modified Files:
>> src/sys/kern: kern_exec.c kern_fork.c kern_lwp.c kern_sig.c sys_lwp.c
>> src/sys/sys:
Date:Sun, 5 May 2019 16:38:04 -0400
From:Christos Zoulas
Message-ID: <41fb59a5-c9e0-4392-bd5c-508e5b80e...@zoulas.com>
| I did not want to make it smaller, but yes,
| you are right I will remove the slop.
|
| > On May 5, 2019, at 4:30 PM, matthew green
I did not want to make it smaller, but yes, you are right I will remove the
slop.
christos
> On May 5, 2019, at 4:30 PM, matthew green wrote:
>
> "Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Sat May 4 15:46:58 UTC 2019
>>
>> Modified
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sat May 4 15:46:58 UTC 2019
>
> Modified Files:
> src/sys/kern: sys_select.c
>
> Log Message:
> PR/54158: Anthony Mallet: poll(2) does not allow polling all possible fds
> (hardcoded limit to 1000 + #).
"Kamil Rytarowski" writes:
> Module Name: src
> Committed By: kamil
> Date: Fri May 3 22:34:21 UTC 2019
>
> Modified Files:
> src/sys/kern: kern_exec.c kern_fork.c kern_lwp.c kern_sig.c sys_lwp.c
> src/sys/sys: signalvar.h
>
> Log Message:
> Register KTR events for debugger
At Fri, 26 Apr 2019 21:40:33 +,
Sevan Janiyan wrote:
> Module Name: src
> Committed By: sevan
> Date: Fri Apr 26 21:40:33 UTC 2019
>
> Modified Files:
> src/sys/arch/acorn32/conf: GENERIC
> src/sys/arch/alpha/conf: GENERIC
> src/sys/arch/amd64/conf: GENERIC
>
On 02.05.2019 02:48, matthew green wrote:
> "Kamil Rytarowski" writes:
>> Module Name: src
>> Committed By:kamil
>> Date:Wed May 1 17:02:40 UTC 2019
>>
>> Modified Files:
>> src/sys/kern: sys_ptrace_common.c
>>
>> Log Message:
>> Disallow resuming program with PC=0x0
"Kamil Rytarowski" writes:
> Module Name: src
> Committed By: kamil
> Date: Wed May 1 17:02:40 UTC 2019
>
> Modified Files:
> src/sys/kern: sys_ptrace_common.c
>
> Log Message:
> Disallow resuming program with PC=0x0 in ptrace(2)
>
> If the address parameter is 0, report error.
In article <20190429231212.b1b55f...@cvs.netbsd.org>,
Valeriy E. Ushakov wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: uwe
>Date: Mon Apr 29 23:12:12 UTC 2019
>
>Modified Files:
> src/sys/sys: mman.h
>
>Log Message:
>Format MAP_FMT so that it's more humanly readable.
On 2019/04/24 20:18, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Wed Apr 24 11:18:21 UTC 2019
>
> Modified Files:
> src/sys/arch/arm/imx: if_enet.c
> src/sys/dev/pci: if_wm.c
>
> Log Message:
> SIOCS is 'S'et function and the ioctl argument is
On Fri, Apr 19, 2019 at 6:49 PM Kamil Rytarowski wrote:
>
> On 19.04.2019 11:41, J. Hannken-Illjes wrote:
> >> On 19. Apr 2019, at 03:52, Ryota Ozaki wrote:
> >>
> >> Module Name: src
> >> Committed By:ozaki-r
> >> Date:Fri Apr 19 01:52:56 UTC 2019
> >>
> >> Modified
On 19.04.2019 11:41, J. Hannken-Illjes wrote:
>> On 19. Apr 2019, at 03:52, Ryota Ozaki wrote:
>>
>> Module Name: src
>> Committed By:ozaki-r
>> Date:Fri Apr 19 01:52:56 UTC 2019
>>
>> Modified Files:
>> src/sys/kern: kern_lwp.c kern_softint.c subr_psref.c
>>
> On 19. Apr 2019, at 03:52, Ryota Ozaki wrote:
>
> Module Name: src
> Committed By: ozaki-r
> Date: Fri Apr 19 01:52:56 UTC 2019
>
> Modified Files:
> src/sys/kern: kern_lwp.c kern_softint.c subr_psref.c
> src/sys/rump/kern/lib/libsysproxy: sysproxy.c
> src/sys/sys:
In article ,
Ryota Ozaki wrote:
>On Tue, Apr 16, 2019 at 5:51 AM Christos Zoulas wrote:
>>
>> Module Name:src
>> Committed By: christos
>> Date: Mon Apr 15 20:51:46 UTC 2019
>>
>> Modified Files:
>> src/sys/net: if.c
>>
>> Log Message:
>> Zero out the ifreq struct for
On Tue, Apr 16, 2019 at 5:51 AM Christos Zoulas wrote:
>
> Module Name:src
> Committed By: christos
> Date: Mon Apr 15 20:51:46 UTC 2019
>
> Modified Files:
> src/sys/net: if.c
>
> Log Message:
> Zero out the ifreq struct for SIOCGIFCONF to avoid up to 127 bytes of stack
>
On Sat, Apr 06, 2019 at 09:40:15PM +, Takeshi Nakayama wrote:
> Module Name: src
> Committed By: nakayama
> Date: Sat Apr 6 21:40:15 UTC 2019
>
> Modified Files:
> src/sys/arch/sparc64/include: psl.h
>
> Log Message:
> The real cause for removing asm inline code on clang is
Le 08/04/2019 à 09:57, Paul Goyette a écrit :
On Mon, 8 Apr 2019, Maxime Villard wrote:
The reason I use MODULE_CLASS_ANY in both NVMM and KCOV is because this
class is invoked late in the boot process (init_main.c). Eg NVMM will use
allocators/xcalls which are not yet initialized in
On Mon, 8 Apr 2019, Maxime Villard wrote:
The reason I use MODULE_CLASS_ANY in both NVMM and KCOV is because this
class is invoked late in the boot process (init_main.c). Eg NVMM will use
allocators/xcalls which are not yet initialized in MODULE_CLASS_DRIVER,
but are in MODULE_CLASS_ANY.
No,
Le 07/04/2019 à 22:58, Paul Goyette a écrit :
On Sun, 7 Apr 2019, Maxime Villard wrote:
Module Name: src
Committed By: maxv
Date: Sun Apr 7 14:05:15 UTC 2019
Modified Files:
src/sys/dev/nvmm: nvmm.c
Log Message:
Don't allow unloading when there are still VMs registered, and
On Sun, 7 Apr 2019, Maxime Villard wrote:
Module Name:src
Committed By: maxv
Date: Sun Apr 7 14:05:15 UTC 2019
Modified Files:
src/sys/dev/nvmm: nvmm.c
Log Message:
Don't allow unloading when there are still VMs registered, and don't allow
auto-unloading at all. Not a
Date:Sat, 6 Apr 2019 10:48:32 -0700
From:Jason Thorpe
Message-ID:
| The only situation I know of where it's wacky is sparc64-built-as-ILP32
| and mips64-built-as-ILP32, where register_t is 64-bit and long is 32-bit.
But that is kind of the point - from qhat I
> On Apr 6, 2019, at 10:45 AM, Robert Elz wrote:
>
> Actually, fetching & storing registers (register_t) is a common enough
> thing that it might be worth having ufetch_reg (and ustore_reg), probably
> as MD #defines that map into one of the other calls.
The only situation I know of where
Actually, fetching & storing registers (register_t) is a common enough
thing that it might be worth having ufetch_reg (and ustore_reg), probably
as MD #defines that map into one of the other calls.
kre
Date:Sat, 6 Apr 2019 10:30:39 -0700
From:Jason Thorpe
Message-ID: <047ba730-614e-46fd-85e2-f501d18f4...@me.com>
| This is wrong -- register_t is 64-bit on amd64 ... so u_long
| is the better choice of cast.
It was wrong anyway, it needs to be an unsigned type
Thanks!
christos
> On Apr 6, 2019, at 8:28 AM, Kamil Rytarowski wrote:
>
>
> Done. I'm still working on adding more test scenarios for fork-related
> events. I've just covered basic clone(2) scenarios and undisclosed
> another bug in the code sitting since 2012.
On 04.04.2019 21:32, Christos Zoulas wrote:
> In article <86734bad-b0e6-57dc-3e0f-5d7c124fa...@gmx.com>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>> -=-=-=-=-=-
>>
>> On 04.04.2019 02:42, Christos Zoulas wrote:
>>> Intermediate or not quality counts It would have been simple
>> enough to
On Sat, Apr 06, 2019 at 07:05:22AM +0900, Takeshi Nakayama wrote:
> >>> Joerg Sonnenberger wrote
>
> > On Fri, Apr 05, 2019 at 12:15:41PM +, Takeshi Nakayama wrote:
> > > Module Name: src
> > > Committed By: nakayama
> > > Date: Fri Apr 5 12:15:41 UTC 2019
> > >
> > >
>>> Joerg Sonnenberger wrote
> On Fri, Apr 05, 2019 at 12:16:13PM +, Takeshi Nakayama wrote:
> > Module Name:src
> > Committed By: nakayama
> > Date: Fri Apr 5 12:16:13 UTC 2019
> >
> > Modified Files:
> > src/sys/arch/sparc64/include: ctlreg.h
> >
> > Log
>>> Joerg Sonnenberger wrote
> On Fri, Apr 05, 2019 at 12:15:41PM +, Takeshi Nakayama wrote:
> > Module Name:src
> > Committed By: nakayama
> > Date: Fri Apr 5 12:15:41 UTC 2019
> >
> > Modified Files:
> > src/sys/arch/sparc64/include: psl.h
> >
> > Log
On Fri, Apr 05, 2019 at 12:15:41PM +, Takeshi Nakayama wrote:
> Module Name: src
> Committed By: nakayama
> Date: Fri Apr 5 12:15:41 UTC 2019
>
> Modified Files:
> src/sys/arch/sparc64/include: psl.h
>
> Log Message:
> Put "memory" to asm inline reading privilege registers
On Fri, Apr 05, 2019 at 12:16:13PM +, Takeshi Nakayama wrote:
> Module Name: src
> Committed By: nakayama
> Date: Fri Apr 5 12:16:13 UTC 2019
>
> Modified Files:
> src/sys/arch/sparc64/include: ctlreg.h
>
> Log Message:
> Add dummy constraints to avoid excessive optimization
In article <86734bad-b0e6-57dc-3e0f-5d7c124fa...@gmx.com>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 04.04.2019 02:42, Christos Zoulas wrote:
>> Intermediate or not quality counts It would have been simple
>enough to write the function once and call it from 13 places, perhaps
On 04.04.2019 02:42, Christos Zoulas wrote:
> Intermediate or not quality counts It would have been simple enough to
> write the function once and call it from 13 places, perhaps even less work!
>
It does. I'm waiting now on releng test results (the service seems to be
returning 503) and I
Intermediate or not quality counts It would have been simple enough to
write the function once and call it from 13 places, perhaps even less work!
christos
> On Apr 3, 2019, at 11:11 AM, Kamil Rytarowski wrote:
>
> On 03.04.2019 14:04, Christos Zoulas wrote:
>
>> Yes, but this md
On 03.04.2019 14:04, Christos Zoulas wrote:
> Yes, but this md copy-pasted code should be handled with an MI function.
> If it is all the same don't copy it 13 times!
>
Nothing to add. This is an intermediate step.
Next planned steps in this domain:
- assert expected behavior in posix_spawn
In article <20190403080801.170d2f...@cvs.netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Wed Apr 3 08:08:00 UTC 2019
>
>Modified Files:
> src/sys/arch/alpha/alpha: syscall.c
> src/sys/arch/arm/arm: syscall.c
>
Date:Thu, 28 Mar 2019 18:12:24 +
From:"Maxime Villard"
Message-ID: <20190328181224.bd6b4f...@cvs.netbsd.org>
| Log Message:
| Move pnbuf_cache into vfs_init.c, where it belongs.
That causes:
Date:Tue, 26 Mar 2019 00:23:32 +
From:"Paul Goyette"
Message-ID: <20190326002332.c0241f...@cvs.netbsd.org>
| XXX Someone(tm) needs to update MAKEDEV to create the /dev/srtN device
| nodes (with device-major 179)!
Yes, I know ...
That's easy - but as I
Hello,
On Fri, 22 Mar 2019 17:07:10 +
m...@netbsd.org wrote:
> On Fri, Mar 22, 2019 at 07:41:41AM +, Martin Husemann wrote:
> > @@ -1402,6 +1402,9 @@ radeonfb_loadbios(struct radeonfb_softc
> > pci_find_rom(pa, romt, romh, romsz, PCI_ROM_CODE_TYPE_X86, ,
> > >sc_biossz);
> >
On Fri, Mar 22, 2019 at 07:41:41AM +, Martin Husemann wrote:
> @@ -1402,6 +1402,9 @@ radeonfb_loadbios(struct radeonfb_softc
> pci_find_rom(pa, romt, romh, romsz, PCI_ROM_CODE_TYPE_X86, ,
> >sc_biossz);
>
> + if (sc->sc_biossz == 0 || sc->sc_bios == NULL)
> +
"Michael Lorenz" writes:
> Module Name: src
> Committed By: macallan
> Date: Wed Mar 20 23:05:19 UTC 2019
>
> Modified Files:
> src/sys/dev/pci: radeonfb.c
>
> Log Message:
> add code to read disabled ROMs, adapted from xf86-video-radeon
> With this radeonfb does The Right
The point was that Max wants to remove compat_osf1 and this is the first step.
The second step would be to remove all the unneeded files and fix
syscalls.master to instantiate the syscall array.
christos
> On Mar 17, 2019, at 5:34 PM, Paul Goyette wrote:
>
> On Sun, 17 Mar 2019, Christos
On Sun, 17 Mar 2019, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Sun Mar 17 14:11:49 UTC 2019
Modified Files:
src/sys/compat/osf1: files.osf1
Log Message:
fix the build: include the needed osf1 files for compat_linux on alpha
This will handle
Hi,
Running Linux binaries on amd64 hits this KASSERT:
sys/kern/vfs_lookup.c
https://nxr.netbsd.org/xref/src/sys/kern/vfs_lookup.c#592
585 /*
586 * Get a reference to the start dir so we can safely unlock
cwdi.
587 *
588 * Must hold references
In article <20190314195150.27756f...@cvs.netbsd.org>,
Palle Lyckegaard wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: palle
>Date: Thu Mar 14 19:51:50 UTC 2019
>
>Modified Files:
> src/sys/kern: kern_scdebug.c
>
>Log Message:
>syscall debug - fix build when SYSCALL_DEBUG
Because we are using image type "kernel_noload" instead of "kernel" for
GENERIC. The header on "kernel" type images contains a load address, and
U-Boot will uncompress the kernel there. For "kernel_noload" type images
there is no load address specified, with the expectation that the kernel
On Thu, Mar 14, 2019 at 10:22:43AM +, Jared D. McNeill wrote:
> Module Name: src
> Committed By: jmcneill
> Date: Thu Mar 14 10:22:43 UTC 2019
>
> Modified Files:
> src/sys/arch/evbarm/conf: mk.generic
>
> Log Message:
> U-Boot fails to boot a compressed kernel_noload image,
On 2019/03/13 19:02, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Wed Mar 13 10:02:13 UTC 2019
Modified Files:
src/sys/dev/pci/ixgbe: ixgbe.c
Log Message:
- Fix a bug that the VLAN HW filter function is not correctly disabled
s/VLAN HW
In article <97bd8b44-7b65-f08e-f118-e5e34d750...@m00nbsd.net>,
Maxime Villard wrote:
>Le 10/03/2019 à 11:58, Valery Ushakov a écrit :
>
>The PTE bits are standard and have the same meaning on all x86 CPUs.
Something must have been wrong on my side. I rebuilt and it worked.
christos
Le 10/03/2019 à 11:58, Valery Ushakov a écrit :
On Sun, Mar 10, 2019 at 08:30:51 +0100, Maxime Villard wrote:
Date: Sun, 10 Mar 2019 08:30:51 +0100
From: Maxime Villard
Subject: Re: CVS commit: src/sys/arch
To: Christos Zoulas , source-changes-d@NetBSD.org
Le 10/03/2019 ? 04:25, Christos
I'll investigate. But it seems clear it's not related to my changes.
Le 10/03/2019 à 16:05, Christos Zoulas a écrit :
I tried a kernel from HEAD yesterday and it did not boot (it gave a guru
meditation in virtualbox).
Then I did cvs update -D yesterday in x86 and and amd64, rebuilt and it
Ok, I will try to figure it out too.
Thanks,
christos
> On Mar 10, 2019, at 12:32 PM, Maxime Villard wrote:
>
> I'll investigate. But it seems clear it's not related to my changes.
>
> Le 10/03/2019 à 16:05, Christos Zoulas a écrit :
>> I tried a kernel from HEAD yesterday and it did not
[ 1.03] cpu0 at mainbus0 apid 0
[ 1.03] cpu0: Intel(R) Core(TM) i7-7Y75 CPU @ 1.30GHz, id 0x806e9
[ 1.03] cpu0: package 0, core 0, smt 0
[ 1.03] cpu1 at mainbus0 apid 1
[ 1.03] cpu1: Intel(R) Core(TM) i7-7Y75 CPU @ 1.30GHz, id 0x806e9
[ 1.03] cpu1:
On Sun, Mar 10, 2019 at 11:05:24AM -0400, Christos Zoulas wrote:
> I tried a kernel from HEAD yesterday and it did not boot (it gave a guru
> meditation in virtualbox).
> Then I did cvs update -D yesterday in x86 and and amd64, rebuilt and it
> booted.
Can you show cpuinfo from a working boot?
I tried a kernel from HEAD yesterday and it did not boot (it gave a guru
meditation in virtualbox).
Then I did cvs update -D yesterday in x86 and and amd64, rebuilt and it booted.
christos
> On Mar 10, 2019, at 3:30 AM, Maxime Villard wrote:
>
> Le 10/03/2019 à 04:25, Christos Zoulas a écrit
On Sun, Mar 10, 2019 at 08:30:51 +0100, Maxime Villard wrote:
> Date: Sun, 10 Mar 2019 08:30:51 +0100
> From: Maxime Villard
> Subject: Re: CVS commit: src/sys/arch
> To: Christos Zoulas , source-changes-d@NetBSD.org
>
> Le 10/03/2019 ? 04:25, Christos Zoulas a ?cri
Le 10/03/2019 à 04:25, Christos Zoulas a écrit :
In article <20190309090956.ef19cf...@cvs.netbsd.org>,
Maxime Villard wrote:
-=-=-=-=-=-
Module Name:src
Committed By: maxv
Date: Sat Mar 9 09:09:56 UTC 2019
Modified Files:
src/sys/arch/amd64/include: pmap.h
In article <20190309090956.ef19cf...@cvs.netbsd.org>,
Maxime Villard wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: maxv
>Date: Sat Mar 9 09:09:56 UTC 2019
>
>Modified Files:
> src/sys/arch/amd64/include: pmap.h
> src/sys/arch/i386/include: pmap.h
>
>Log Message:
> On Mar 3, 2019, at 10:31 AM, m...@netbsd.org wrote:
>
> Maybe we can use the longer name to avoid the confusion? PG_WIRED
>
> (PG_W as writable exists in other archs, and there's precedence for
> PG_WIRED too)
Agreed, PG_WIRED is a better name for this.
-- thorpej
On Sun, Mar 03, 2019 at 05:33:33PM +, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Sun Mar 3 17:33:33 UTC 2019
>
> Modified Files:
> src/sys/arch/x86/acpi: acpi_machdep.c
>
> Log Message:
> Fix bug, PG_W is 'wired', not 'writable'.
Maybe we can use
Rin Okuyama wrote:
>I tested StarTech USB21000S2 with Pine A64+. It works well
>with multiple outstanding transfers. If I understand correctly,
>Pine A64+ and Pinebook have (almost?) same SoC. If so, there
>should be the problem elsewhere than host controller itself.
>
>Robert, could you please
Hi,
I tested StarTech USB21000S2 with Pine A64+. It works well
with multiple outstanding transfers. If I understand correctly,
Pine A64+ and Pinebook have (almost?) same SoC. If so, there
should be the problem elsewhere than host controller itself.
Robert, could you please test it with powered
On Mon, Feb 25, 2019 at 11:35:35AM +0100, Kamil Rytarowski wrote:
> This is right, SCTP build wasn't tested and I got it enabled locally.
> I propose to build ALL by default as we now depend on external services
> to have functional 24/7 build with sanitizers (syzkaller).
Yes, it needs to be part
On 25.02.2019 11:23, Martin Husemann wrote:
> On Mon, Feb 25, 2019 at 01:19:02PM +0300, Valery Ushakov wrote:
>> On Mon, Feb 25, 2019 at 06:23:33 +0100, Martin Husemann wrote:
>>
>>> On Sun, Feb 24, 2019 at 09:43:52PM +0100, Kamil Rytarowski wrote:
I consider that this is just GCC specific
On Mon, Feb 25, 2019 at 01:19:02PM +0300, Valery Ushakov wrote:
> On Mon, Feb 25, 2019 at 06:23:33 +0100, Martin Husemann wrote:
>
> > On Sun, Feb 24, 2019 at 09:43:52PM +0100, Kamil Rytarowski wrote:
> > > I consider that this is just GCC specific behavior to make some warnings
> > > fatal
On Mon, Feb 25, 2019 at 06:23:33 +0100, Martin Husemann wrote:
> On Sun, Feb 24, 2019 at 09:43:52PM +0100, Kamil Rytarowski wrote:
> > I consider that this is just GCC specific behavior to make some warnings
> > fatal depending on driver configuration. This is typical behavior of GCC
> > that we
On Sun, Feb 24, 2019 at 10:13:40PM +0100, Tobias Nygren wrote:
> On Sun, 24 Feb 2019 19:06:40 +
> Michael van Elst wrote:
>
> > To generate a diff of this commit:
> > cvs rdiff -u -r1.242 -r1.243 src/sys/ufs/ufs/ufs_vnops.c
>
> > + rawbuf -= dropend;
>
> I guess this should be
> If you think that this is better and it works, please go for it.
please, no.
don't duplicate prototypes in a way that changes won't be detected.
ie, if the real sctp code changes, today the compat caller will
fail to build until updated. with this change, it will build and
be entirely wrong.
On Mon, Feb 25, 2019 at 06:07:23AM +, David Holland wrote:
> that one doesn't set dropend correctly for small buffers, outsmarted
> myself while writing it.
Better change (still against 1.242) that makes the logic much
simpler. Will test this overnight...
Index: ufs_vnops.c
On 24.02.2019 23:55, Robert Swindells wrote:
>
> Kamil Rytarowski wrote:
>> Module Name:src
>> Committed By: kamil
>> Date: Sun Feb 24 17:01:52 UTC 2019
>>
>> Modified Files:
>>src/sys/netinet: sctp_asconf.h
>>
>> Log Message:
>> Appease GCC7 in sctp_asconf.h
>>
>> Do not
On Mon, Feb 25, 2019 at 05:50:08AM +, David Holland wrote:
> Furthermore, this:
>
> > + rawbuf -= dropend;
>
> is entirely wrong (it needs to be "rawbufmax") and without that bound
> on rawbufmax the code is unsafe...
I repaired this bit just now, so it's not an overt hazard
On Sun, Feb 24, 2019 at 07:51:24PM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By:christos
> Date:Mon Feb 25 00:51:24 UTC 2019
>
> Modified Files:
> src/sys/ufs/ufs: ufs_vnops.c
>
> Log Message:
> drop unused
dropping this logic is wrong...
Kamil Rytarowski wrote:
>Module Name:src
>Committed By: kamil
>Date: Sun Feb 24 17:01:52 UTC 2019
>
>Modified Files:
>src/sys/netinet: sctp_asconf.h
>
>Log Message:
>Appease GCC7 in sctp_asconf.h
>
>Do not declare types inside function parameter list.
>Add decklarations
On Sun, 24 Feb 2019 19:06:40 +
Michael van Elst wrote:
> To generate a diff of this commit:
> cvs rdiff -u -r1.242 -r1.243 src/sys/ufs/ufs/ufs_vnops.c
> + rawbuf -= dropend;
I guess this should be rawbufmax, not rawbuf.
On Sun, Feb 24, 2019 at 09:43:52PM +0100, Kamil Rytarowski wrote:
> I consider that this is just GCC specific behavior to make some warnings
> fatal depending on driver configuration. This is typical behavior of GCC
> that we keep observing all over again.
No, this is very different to optimizer
On 24.02.2019 21:38, Martin Husemann wrote:
> On Sun, Feb 24, 2019 at 09:36:55PM +0100, Kamil Rytarowski wrote:
>> My only specific change was NetBSD/i386 kernel=GENERIC with kUBSan and
>> KCOV enabled.
>
> This does not answer the question. What does enabling kUBSan/KCOV break
> to make this
On 24.02.2019 21:43, Kamil Rytarowski wrote:
> On 24.02.2019 21:38, Martin Husemann wrote:
>> On Sun, Feb 24, 2019 at 09:36:55PM +0100, Kamil Rytarowski wrote:
>>> My only specific change was NetBSD/i386 kernel=GENERIC with kUBSan and
>>> KCOV enabled.
>>
>> This does not answer the question. What
On Sun, Feb 24, 2019 at 09:36:55PM +0100, Kamil Rytarowski wrote:
> My only specific change was NetBSD/i386 kernel=GENERIC with kUBSan and
> KCOV enabled.
This does not answer the question. What does enabling kUBSan/KCOV break
to make this error show up in your compilation, but not in our default
On 24.02.2019 20:39, Martin Husemann wrote:
> On Sun, Feb 24, 2019 at 07:20:10PM +0100, Kamil Rytarowski wrote:
>> On 24.02.2019 19:15, David Holland wrote:
>>> On Sun, Feb 24, 2019 at 05:01:52PM +, Kamil Rytarowski wrote:
>>> > Modified Files:
>>> > src/sys/netinet: sctp_asconf.h
>>> >
On Sun, Feb 24, 2019 at 07:41:59PM +, m...@netbsd.org wrote:
> something like the overflow is undefined behaviour, so it cannot
> happen, so the branch checking that it happened is eliminated.
*Signed* integer overflow is undefined behavior. *Unsigned* integer
overflow is well defined.
Joerg
On Sun, Feb 24, 2019 at 07:41:59PM +, m...@netbsd.org wrote:
> something like the overflow is undefined behaviour, so it cannot
> happen, so the branch checking that it happened is eliminated.
Integer overflow is not undefined, but implemenation defined behaviour.
Martin
On Sun, Feb 24, 2019 at 07:06:40PM +, Michael van Elst wrote:
> While here, also check for arithmetic overflow.
> + /* how much to actually read */
> + rawbufmax = callerbytes + skipstart;
> + if (rawbufmax < callerbytes)
> + return EINVAL;
hmm, I"m under the
On Sun, Feb 24, 2019 at 07:20:10PM +0100, Kamil Rytarowski wrote:
> On 24.02.2019 19:15, David Holland wrote:
> > On Sun, Feb 24, 2019 at 05:01:52PM +, Kamil Rytarowski wrote:
> > > Modified Files:
> > > src/sys/netinet: sctp_asconf.h
> > >
> > > Log Message:
> > > Appease GCC7 in
On 24.02.2019 19:15, David Holland wrote:
> On Sun, Feb 24, 2019 at 05:01:52PM +, Kamil Rytarowski wrote:
> > Modified Files:
> >src/sys/netinet: sctp_asconf.h
> >
> > Log Message:
> > Appease GCC7 in sctp_asconf.h
> >
> > Do not declare types inside function parameter list.
> >
1201 - 1300 of 5583 matches
Mail list logo
