On Sat, Mar 28, 2020 at 08:35:37AM +, Tetsuya Isaki wrote:
> - 4msec is (probably no problem for most modern real hardware but)
> too aggressive to be default.
> - 10msec is too severe for antique machines but it's hard to draw a line.
<5ms blk_ms is required by real world applications; see
On 2020/03/24 12:45, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Tue Mar 24 03:45:26 UTC 2020
>
> Modified Files:
> src/sys/dev/ic: spdmem.c spdmemvar.h
>
> Log Message:
> - Define some new parameters of DDR3 SPD ROM.
> - Use fine timebase parameters
Le 23/03/2020 à 04:07, Roy Marples a écrit :
> On 22/03/2020 08:30, Maxime Villard wrote:
>> Overall "From OpenBSD" is a redflag for buggy and vulnerable code..
>
> We should be above this, no software is perfect, not even ours.
>
> Roy
You seem to be confusing one-off defects and structural
On 22/03/2020 08:30, Maxime Villard wrote:
Overall "From OpenBSD" is a redflag for buggy and vulnerable code..
We should be above this, no software is perfect, not even ours.
Roy
Le 19/03/2020 à 08:49, Pierre Pronchery a écrit :
> Module Name: src
> Committed By: khorben
> Date: Thu Mar 19 07:49:29 UTC 2020
>
> Modified Files:
> src/sys/dev/usb: if_umb.c
>
> Log Message:
> When there is no network around the state timeout fires over and over again.
>
Great work! One small remark:
+static int
+ave_fdt_match(device_t parent, cfdata_t cf, void *aux)
+{
+ static const char * compatible[] = {
+#ifdef _LP64
+ "socionext,unifier-ld20-ave4",
+#else
+
On Wed, Mar 18, 2020 at 09:44:03PM +0200, Yorick Hardy wrote:
> Dear Andrew,
>
> On 2020-03-14, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Sat Mar 14 13:50:46 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/x86/acpi: acpi_cpu_md.c
> >
Dear Andrew,
On 2020-03-14, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Sat Mar 14 13:50:46 UTC 2020
>
> Modified Files:
> src/sys/arch/x86/acpi: acpi_cpu_md.c
>
> Log Message:
> Put ACPI idle under ACPICPU_ENABLE_C3 until the wrinkles are ironed out.
> This
On 18/03/2020 11:33, Robert Elz wrote:
> Module Name: src
> Committed By: kre
> Date: Wed Mar 18 11:33:32 UTC 2020
>
> Modified Files:
> src/sys/dev/usb: if_aue.c
>
> Log Message:
> This was still not correct,. USB_DEBUG is what mattered, not AUE_DEBUG,
> the two are orthogonal.
Hi --
Is there really a need for all of this fdt stuff for SCA2A11? I would
expect that the board can be fully supported in ACPI mode.
Thanks,
Jared
On Wed, 18 Mar 2020, Tohru Nishimura wrote:
Module Name:src
Committed By: nisimura
Date: Wed Mar 18 08:49:51 UTC 2020
Date:Tue, 17 Mar 2020 22:58:24 -0400
From:"Christos Zoulas"
Message-ID: <20200318025824.93b28f...@cvs.netbsd.org>
| Log Message:
| define un (pointed out by kre@)
The reason I didn't suggest that change, is that now un is unused
when USB_DEBUG is not defined.
On Tue, Mar 17, 2020 at 10:38:14PM +, Andrew Doran wrote:
> Log Message:
> - Change some expensive checks DEBUG -> DIAGNOSTIC.
That was meant to be the other way around, oops.
Andrew
On Mon, Mar 16, 2020 at 08:17:58AM +, Tohru Nishimura wrote:
> Module Name: src
> Committed By: nisimura
> Date: Mon Mar 16 08:17:58 UTC 2020
>
> Modified Files:
> src/sys/arch/evbarm/conf: GENERIC64 files.generic64
>
> Log Message:
> include files.sociox for generic64
>
>
>
On Sun, Mar 15, 2020 at 11:38:03AM +1100, matthew green wrote:
> "Andrew Doran" writes:
> > Module Name:src
> > Committed By: ad
> > Date: Sat Mar 14 13:34:44 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/sparc/sparc: intr.c
> >
> > Log Message:
> > sparc
> On Mar 14, 2020, at 8:10 PM, Jason Thorpe wrote:
>
> redundant things (e.g. extent vs vmem)
In case this wasn't obvious, I favor ejecting extent in favor of vmem.
-- thorpej
> On Mar 14, 2020, at 7:57 PM, Rin Okuyama wrote:
>
> I think that we can no longer support 4MB system because of (2); hangs
> due to (2) are much more serious for 4MB system than it is in 7MB system.
> Modern kernel allocates too much things on demand rather than statically
> allocating them
(added port-sun2 and thorpej)
On 2020/03/08 17:40, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Sun Mar 8 06:25:10 UTC 2020
Modified Files:
src/sys/arch/sun2/conf: GENERIC
Log Message:
Retire md(4) in favor of tmpfs provided by
"Andrew Doran" writes:
> Module Name: src
> Committed By: ad
> Date: Sat Mar 14 13:34:44 UTC 2020
>
> Modified Files:
> src/sys/arch/sparc/sparc: intr.c
>
> Log Message:
> sparc cpu_intr_p(): try to work around l_cpu not being set early on by
> using curcpu().
ah, good idea.
In article <20200314143238.gr5...@pony.stderr.spb.ru>,
Valery Ushakov wrote:
>How is is affected by the decision to change (or not) 0x%x to %#x?
>
This was in response to the statement:
... with a bit of patience might have been less drastic and as effective.
christos
On Sat, Mar 14, 2020 at 10:27:27 -0400, Christos Zoulas wrote:
> > I don't belive that "if". It's like claiming you got rid of a stain
> > on a wallpaper after you demolish a wall (not load-bearing,
> > fortunately) and have to put it back and put new wallpaper. :) Get rid
> > of the stain,
> I don't belive that "if". It's like claiming you got rid of a stain
> on a wallpaper after you demolish a wall (not load-bearing,
> fortunately) and have to put it back and put new wallpaper. :) Get rid
> of the stain, sure; but may be looking closely with a bit of patience
> might have been
On Sat, Mar 14, 2020 at 09:57:36 -0400, Christos Zoulas wrote:
> > Even for the ones without the widths specified. E.g. I personally
> > prefer zero printed as 0x0, not as 0, so I assume that when people
> > choose either one that reflects their preference. Why mess with it?
> > It's all so
> Even for the ones without the widths specified. E.g. I personally
> prefer zero printed as 0x0, not as 0, so I assume that when people
> choose either one that reflects their preference. Why mess with it?
> It's all so unnecessary.
Yes, now we are discussing cosmetics (if 0 should be printed
> As I wrote in a follow up email, it changes formatting b/c you didn't
> change field widths and IMO using %# with a field width is mostly
> trouble to begin with. It's not the first time someone tries to do
> this without actually understanding the consequences of the change.
> Please, can we
On Fri, Mar 13, 2020 at 22:26:05 -0400, Christos Zoulas wrote:
> > On Mar 13, 2020, at 10:25 PM, Valery Ushakov wrote:
> >
> > As I wrote in a follow up email, it changes formatting b/c you didn't
> > change field widths and IMO using %# with a field width is mostly
> > trouble to begin with.
> On Mar 13, 2020, at 10:25 PM, Valery Ushakov wrote:
>
> As I wrote in a follow up email, it changes formatting b/c you didn't
> change field widths and IMO using %# with a field width is mostly
> trouble to begin with. It's not the first time someone tries to do
> this without actually
On Fri, Mar 13, 2020 at 22:15:31 -0400, Christos Zoulas wrote:
> > This was not a part of the PR and is completely cosmetic (surely it
> > supports plain %x if it does support %#x). Why was this necessary?
> > (I know I would be quite miffed if someone made a change like that to
> > my code).
>
> This was not a part of the PR and is completely cosmetic (surely it
> supports plain %x if it does support %#x). Why was this necessary?
> (I know I would be quite miffed if someone made a change like that to
> my code).
Yes, that %x formatting change was not part of the PR, but I only
On Fri, Mar 13, 2020 at 17:09:14 -0700, Paul Goyette wrote:
> On Sat, 14 Mar 2020, Valery Ushakov wrote:
>
> > On Fri, Mar 13, 2020 at 14:17:42 -0400, Christos Zoulas wrote:
> >
> > > Log Message:
> > > PR/55068: sc.dying: Fix printf formats:
> > [...]
> > > - 0x% -> %#
> >
> > This was not a
On Sat, 14 Mar 2020, Valery Ushakov wrote:
On Fri, Mar 13, 2020 at 14:17:42 -0400, Christos Zoulas wrote:
Log Message:
PR/55068: sc.dying: Fix printf formats:
[...]
- 0x% -> %#
This was not a part of the PR and is completely cosmetic (surely it
supports plain %x if it does support %#x).
On Fri, Mar 13, 2020 at 14:17:42 -0400, Christos Zoulas wrote:
> Log Message:
> PR/55068: sc.dying: Fix printf formats:
[...]
> - 0x% -> %#
This was not a part of the PR and is completely cosmetic (surely it
supports plain %x if it does support %#x). Why was this necessary?
(I know I would be
> On Mar 13, 2020, at 12:25 PM, Jason Thorpe wrote:
>
>
>> On Mar 13, 2020, at 9:11 AM, Christos Zoulas wrote:
>>
>> I think this is better done in the driver, as other ports
>> do the same check and it catches bugs.
>
> x86 *explcitly* checks for 0 to skip work. If you want to find bugs,
> On Mar 13, 2020, at 9:11 AM, Christos Zoulas wrote:
>
> I think this is better done in the driver, as other ports
> do the same check and it catches bugs.
x86 *explcitly* checks for 0 to skip work. If you want to find bugs, change
the most-often-used implementation maybe?
-- thorpej
In article <20200313034939.553d5f...@cvs.netbsd.org>,
Jason R Thorpe wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: thorpej
>Date: Fri Mar 13 03:49:39 UTC 2020
>
>Modified Files:
> src/sys/arch/mips/mips: bus_dma.c
>
>Log Message:
>Allow len == 0 in bus_dmamap_sync().
I
On 13/03/2020 03:49, Jason R Thorpe wrote:
Module Name:src
Committed By: thorpej
Date: Fri Mar 13 03:49:39 UTC 2020
Modified Files:
src/sys/arch/mips/mips: bus_dma.c
Log Message:
Allow len == 0 in bus_dmamap_sync().
XXX pullup-9
The assertion that len is not 0 in arm
Le 27/02/2020 à 01:36, Simon Burge a écrit :
> "Maxime Villard" wrote:
>
>> Module Name: src
>> Committed By:maxv
>> Date:Wed Feb 26 18:00:12 UTC 2020
>>
>> Modified Files:
>>
>> src/sys/ufs/ufs: ufs_vnops.c
>>
>> Log Message:
>>
>> Zero out the padding in 'd_namlen',
On 09.03.2020 15:31, Taylor R Campbell wrote:
>> Module Name:src
>> Committed By: kamil
>> Date: Mon Mar 9 00:03:00 UTC 2020
>>
>> Modified Files:
>> src/sys/rump: Makefile.rump
>>
>> Log Message:
>> Build RUMP with -fno-delete-null-pointer-checks on all compilers
>
> I
> Module Name:src
> Committed By: kamil
> Date: Mon Mar 9 00:03:00 UTC 2020
>
> Modified Files:
> src/sys/rump: Makefile.rump
>
> Log Message:
> Build RUMP with -fno-delete-null-pointer-checks on all compilers
I asked you to hold off on making this change, ten hours
Le 08/03/2020 à 21:41, Andrew Doran a écrit :
> On Sun, Mar 08, 2020 at 08:34:29AM +0100, Maxime Villard wrote:
>> Le 08/03/2020 ? 01:31, Andrew Doran a ?crit?:
>>> Module Name:src
>>> Committed By: ad
>>> Date: Sun Mar 8 00:31:19 UTC 2020
>>>
>>> Modified Files:
>>>
On Mon, 9 Mar 2020, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Mon Mar 9 01:06:34 UTC 2020
Modified Files:
src/sys/compat/netbsd32: netbsd32_mod.c
Log Message:
If a syscall requires a module to be autoloaded, the initial invocation
of that
On Sun, Mar 08, 2020 at 08:34:29AM +0100, Maxime Villard wrote:
> Le 08/03/2020 ? 01:31, Andrew Doran a ?crit?:
> > Module Name:src
> > Committed By: ad
> > Date: Sun Mar 8 00:31:19 UTC 2020
> >
> > Modified Files:
> > src/sys/kern: subr_kmem.c
> >
> > Log
On Sun, Mar 08, 2020 at 02:16:00PM -, Christos Zoulas wrote:
> >Log Message:
> >Use unsigned to avoid undefined behavior. Found by kUBSan.
>
> I think it is better to add U to all the HUP_ constants for consistency.
> It looks funny this way.
Yes, please keep it consistent.
Martin
In article <20200308140933.1b842f...@cvs.netbsd.org>,
SAITOH Masanobu wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: msaitoh
>Date: Sun Mar 8 14:09:33 UTC 2020
>
>Modified Files:
> src/sys/dev/hid: hid.h
>
>Log Message:
>Use unsigned to avoid undefined behavior. Found
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Sun Mar 8 06:25:10 UTC 2020
>
> Modified Files:
> src/sys/arch/sun2/conf: GENERIC
>
> Log Message:
> Retire md(4) in favor of tmpfs provided by module,
> though both are not useful for 8MB RAM system...
hi Rin.
Le 08/03/2020 à 01:31, Andrew Doran a écrit :
> Module Name: src
> Committed By: ad
> Date: Sun Mar 8 00:31:19 UTC 2020
>
> Modified Files:
> src/sys/kern: subr_kmem.c
>
> Log Message:
> KMEM_SIZE: append the size_t to the allocated buffer, rather than
> prepending, so it doesn't
On Sat, Mar 07, 2020 at 19:18:41 -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sun Mar 8 00:18:41 UTC 2020
>
> Modified Files:
> src/sys/conf: files
>
> Log Message:
> undo previous since config has been fixed
It's still not. Nested ifdefs
>OK, I reproduced it, and have commited a fix for aarch64. I will also
>include this in the pullup requests for -9 and -8
with sys/conf/files r1.1259, build successfully and it works fine.
thanks!
--
ryo shimizu
On Fri, 6 Mar 2020, matthew green wrote:
Paul Goyette writes:
On Thu, 5 Mar 2020, Paul Goyette wrote:
also aarch64 has no EXEC_AOUT.
Does aarch64 have COMPAT_NETBSD32? If so, I will adjust my fix. (I
built 67 different architectures, including all of the ones that the
releng build
Paul Goyette writes:
> On Thu, 5 Mar 2020, Paul Goyette wrote:
>
> >> also aarch64 has no EXEC_AOUT.
> >
> > Does aarch64 have COMPAT_NETBSD32? If so, I will adjust my fix. (I
> > built 67 different architectures, including all of the ones that the
> > releng build cluster is building, and did
OK, I reproduced it, and have commited a fix for aarch64. I will also
include this in the pullup requests for -9 and -8
On Thu, 5 Mar 2020, Paul Goyette wrote:
On Fri, 6 Mar 2020, Ryo Shimizu wrote:
also aarch64 has no EXEC_AOUT.
Does aarch64 have COMPAT_NETBSD32? If so, I will adjust
On Fri, 6 Mar 2020, Ryo Shimizu wrote:
also aarch64 has no EXEC_AOUT.
Does aarch64 have COMPAT_NETBSD32? If so, I will adjust my fix. (I
built 67 different architectures, including all of the ones that the
releng build cluster is building, and did not have any problems with
aarch64 or any
>> also aarch64 has no EXEC_AOUT.
>
>Does aarch64 have COMPAT_NETBSD32? If so, I will adjust my fix. (I
>built 67 different architectures, including all of the ones that the
>releng build cluster is building, and did not have any problems with
>aarch64 or any other.)
it seems that releng
On Thu, 5 Mar 2020, Paul Goyette wrote:
also aarch64 has no EXEC_AOUT.
Does aarch64 have COMPAT_NETBSD32? If so, I will adjust my fix. (I
built 67 different architectures, including all of the ones that the
releng build cluster is building, and did not have any problems with
aarch64 or any
On Thu, 5 Mar 2020, Ryo Shimizu wrote:
Module Name:src
Committed By: pgoyette
Date: Wed Mar 4 02:20:57 UTC 2020
Modified Files:
src/sys/conf: files
Log Message:
mips64 has compat_netbsd32 but cannot have exec_aout; all other users
of compat_netbsd32 need exec_aout
Ryo Shimizu writes:
> also aarch64 has no EXEC_AOUT.
that's a pity -- we do have 32 bit a.out binaries from the past ;-)
.mrg.
>Module Name: src
>Committed By: pgoyette
>Date: Wed Mar 4 02:20:57 UTC 2020
>
>Modified Files:
> src/sys/conf: files
>
>Log Message:
>mips64 has compat_netbsd32 but cannot have exec_aout; all other users
>of compat_netbsd32 need exec_aout
>
>Addresses PR kern/55037.
>
>XXX
On Wed, 4 Mar 2020, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Wed Mar 4 02:20:57 UTC 2020
Modified Files:
src/sys/conf: files
Log Message:
mips64 has compat_netbsd32 but cannot have exec_aout; all other users
of compat_netbsd32 need exec_aout
On Tue, Mar 03, 2020 at 02:55:16PM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Tue Mar 3 19:55:16 UTC 2020
>
> Modified Files:
> src/sys/kern: vfs_syscalls.c
>
> Log Message:
> don't skip the rdir check for the lazy case; breaks chroot df(1)
Yes, I thought about providing an ioctl to do this, but it would mean that
everything
that talks to those devices would need to be modified to issue the ioctl. Raw
mode
means to call the underlying uhidev write which is the raw usb writes instead of
using the report mechanism. My devices did not
Martin Husemann writes:
> On Tue, Mar 03, 2020 at 03:26:47PM +1100, matthew green wrote:
> > without really understanding, it seems that there should be
> > a uhid ioctl to enable this mode, and then your userland code
> > sets it, instead of this hack.
>
> Or make uhid not attach at all on FIDO
On Tue, Mar 03, 2020 at 03:26:47PM +1100, matthew green wrote:
> without really understanding, it seems that there should be
> a uhid ioctl to enable this mode, and then your userland code
> sets it, instead of this hack.
Or make uhid not attach at all on FIDO devices and instead use ugen from
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Mon Mar 2 18:15:29 UTC 2020
>
> Modified Files:
> src/sys/dev/hid: hid.h
> src/sys/dev/usb: uhid.c
>
> Log Message:
> Add fido constants, and turn hid "raw" mode for fido devices.
this is gross.
> Date: Tue, 3 Mar 2020 12:41:32 +0900
> From: Rin Okuyama
>
> On 2020/03/03 1:00, Taylor R Campbell wrote:
> > Include kern_crashme.c in non-DEBUG kernels.
> >
> > This is useful for simulating crashes in production to test failover.
>
> I like this.
>
> Could you please send pullup request
Hi,
On 2020/03/03 1:00, Taylor R Campbell wrote:
Module Name:src
Committed By: riastradh
Date: Mon Mar 2 16:00:54 UTC 2020
Modified Files:
src/sys/kern: files.kern
Log Message:
Include kern_crashme.c in non-DEBUG kernels.
This is useful for simulating crashes in
On 2020/02/27 15:17, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Thu Feb 27 06:17:28 UTC 2020
>
> Modified Files:
> src/sys/dev/mii: miidevs
>
> Log Message:
> Use xxVIA instead of VIA.
>
> 0x004063 is VIA's official OUI but VT6103 use 0x0002c6.
>
"Maxime Villard" wrote:
> Module Name: src
> Committed By: maxv
> Date: Wed Feb 26 18:00:12 UTC 2020
>
> Modified Files:
>
> src/sys/ufs/ufs: ufs_vnops.c
>
> Log Message:
>
> Zero out the padding in 'd_namlen', to prevent info leaks. Same logic as
> ufs_makedirentry().
Is it
> Modified Files:
> src/sys/dev/pckbport: synaptics.c
>
> Log Message:
> Messages in pms_synaptics_input() should not start with "pms_input"
>
> Use "pms_synaptics_input" instead.
Maybe it's better to use ("%s", __func__) C99 predefined identifier.
---
Izumi Tsutsui
On 24.02.2020 21:47, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Mon Feb 24 20:47:47 UTC 2020
>
> Modified Files:
> src/sys/kern: init_main.c
>
> Log Message:
> move config_init_mi() call before vfsinit(), which can trigger loading
> of VFS modules
>
"Andrew Doran" writes:
> Module Name: src
> Committed By: ad
> Date: Sun Feb 23 20:08:35 UTC 2020
>
> Modified Files:
> src/sys/kern: kern_pmf.c
>
> Log Message:
> shutdown_all: take kernel_lock now that kern_reboot() doesn't.
ah, i am now guessing that having the kernel lock
"Andrew Doran" writes:
> Module Name: src
> Committed By: ad
> Date: Sun Feb 23 20:06:30 UTC 2020
>
> Modified Files:
> src/sys/kern: kern_reboot.c
>
> Log Message:
> - If concurrent calls to kern_reboot(), only let the first do the deed.
> - Don't need kernel_lock for this
On 21/02/2020 23:27, Maya Rashish wrote:
[...]
Index: src/sys/arch/arm/arm32/bus_dma.c
diff -u src/sys/arch/arm/arm32/bus_dma.c:1.118
src/sys/arch/arm/arm32/bus_dma.c:1.119
--- src/sys/arch/arm/arm32/bus_dma.c:1.118 Tue Nov 5 10:21:31 2019
+++ src/sys/arch/arm/arm32/bus_dma.cFri Feb
On 20.02.2020 22:14, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Thu Feb 20 21:14:23 UTC 2020
>
> Modified Files:
> src/sys/kern: subr_autoconf.c
>
> Log Message:
> protect deferred lists' manipulation by config_misc_lock, same as
> config_pending
On 2020/02/18 6:55, Andrew Doran wrote:
I corrected the cpu_ast() case. Yes it's curious why ibm4xx calls
mi_userret() directly; that seems wrong (I have not changed it though). I
think it definitely makes more sense to deal with OWEUPC before userret().
Thank you!
Now, I'm working on
> On Feb 17, 2020, at 11:19 PM, Andrew Doran wrote:
>
> Hi,
>
> On Thu, Feb 06, 2020 at 06:33:55PM +0100, J. Hannken-Illjes wrote:
>
>>> On 12. Jan 2020, at 18:49, Andrew Doran wrote:
>>>
>>> Module Name:src
>>> Committed By: ad
>>> Date: Sun Jan 12 17:49:17 UTC
Hi,
On Thu, Feb 06, 2020 at 06:33:55PM +0100, J. Hannken-Illjes wrote:
> > On 12. Jan 2020, at 18:49, Andrew Doran wrote:
> >
> > Module Name:src
> > Committed By: ad
> > Date: Sun Jan 12 17:49:17 UTC 2020
> >
> > Modified Files:
> > src/sys/kern: vfs_vnode.c
>
On Wed, Feb 05, 2020 at 12:46:57PM +0900, Rin Okuyama wrote:
> Hi,
>
> On 2019/12/06 5:55, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Thu Dec 5 20:55:24 UTC 2019
> >
> > Modified Files:
> > src/sys/arch/powerpc/powerpc:
The static variable was in #ifdef __NetBSD__ part, so I assumed it
doesn't influence the merge.
Christos already reverted the fallthrough warning fix.
Jaromir
Le jeu. 13 févr. 2020 à 09:18, matthew green a écrit :
>
> "Jaromir Dolecek" writes:
> > Module Name: src
> > Committed By: jdolecek
>
"Jaromir Dolecek" writes:
> Module Name: src
> Committed By: jdolecek
> Date: Wed Feb 12 20:31:46 UTC 2020
>
> Modified Files:
> src/sys/external/bsd/drm2/dist/drm/nouveau: nouveau_fbcon.c
>
> Log Message:
> remove superfluous static variable used only to zero attach args
is this
Hi,
Hyper-V Gen.2 VM has only 1024x768 GOP entry.
https://twitter.com/nonakap/status/1227076603470942208
kernel will be booted in text mode. no output to the console.
If execute "gop 0" command before booting a kernel, it works fine.
On Sat, Feb 8, 2020 at 11:35 PM Jared D. McNeill wrote:
>
>
> On Feb 8, 2020, at 12:45 PM, Andrew Doran wrote:
>
> Bit concerning that we're growing a ton of kthreads in the network stack (my
> test system now has something like 700 kthreads total) but I'm less worried
> about that and moreso that a lot of these seem to be in the kernel RT range
> and
On Thu, Feb 06, 2020 at 11:30:20PM +, Jason R Thorpe wrote:
> Modified Files:
> src/sys/net: if.c if.h
> src/sys/netinet: ip_carp.c
>
> Log Message:
> Perform link state change processing on a work queue, rather than in a
> softint.
Thinking out loud more than anything else:
> On 12. Jan 2020, at 18:49, Andrew Doran wrote:
>
> Module Name: src
> Committed By: ad
> Date: Sun Jan 12 17:49:17 UTC 2020
>
> Modified Files:
> src/sys/kern: vfs_vnode.c
>
> Log Message:
> vput(): don't drop the vnode lock, carry the hold over into vrelel() which
> might
On 05/02/2020 07:37, Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Wed Feb 5 07:37:36 UTC 2020
Modified Files:
src/sys/arch/arm/arm: cpufunc.c
src/sys/arch/arm/arm32: armv7_generic_space.c pmap.c
src/sys/arch/arm/conf: Makefile.arm
Hi,
On 2019/12/06 5:55, Andrew Doran wrote:
Module Name:src
Committed By: ad
Date: Thu Dec 5 20:55:24 UTC 2019
Modified Files:
src/sys/arch/powerpc/powerpc: powerpc_machdep.c
Log Message:
Need to call userret() from cpu_ast().
To generate a diff of this commit:
cvs
On Sat, Feb 01, 2020 at 02:23:24AM +, Taylor R Campbell wrote:
> Module Name: src
> Committed By: riastradh
> Date: Sat Feb 1 02:23:23 UTC 2020
>
> Modified Files:
> src/sys/ddb: db_xxx.c
> src/sys/kern: kern_descrip.c kern_sig.c subr_exec_fd.c uipc_socket2.c
>
Le 28/01/2020 à 19:39, Nick Hudson a écrit :
> On 28/01/2020 17:47, Maxime Villard wrote:
>> @@ -460,8 +460,7 @@ cpu_setup_id(struct cpu_info *ci)
>>
>> id->ac_aa64mmfr0 = reg_id_aa64mmfr0_el1_read();
>> id->ac_aa64mmfr1 = reg_id_aa64mmfr1_el1_read();
>> - /* Only in ARMv8.2. */
>>
On 30/01/2020 10:04, Maxime Villard wrote:
Le 28/01/2020 à 19:39, Nick Hudson a écrit :
On 28/01/2020 17:47, Maxime Villard wrote:
@@ -460,8 +460,7 @@ cpu_setup_id(struct cpu_info *ci)
id->ac_aa64mmfr0 = reg_id_aa64mmfr0_el1_read();
id->ac_aa64mmfr1 =
On Wed, 29 Jan 2020, Andrew Doran wrote:
| Log Message:
| Put pri_t back to an int. It looks like there might be a sign extension
| issue somewhere but it's not worth the hassle trying to find it.
This changes the kernel internal ABI doesn't it? It would have needed
a kernel version
On Wed, Jan 29, 2020 at 12:58:52AM +0700, Robert Elz wrote:
> Date:Tue, 28 Jan 2020 16:40:27 +
> From:"Andrew Doran"
> Message-ID: <20200128164027.8558bf...@cvs.netbsd.org>
>
> | Log Message:
> | Put pri_t back to an int. It looks like there might be a sign
On 29.01.2020 07:40, Jason Thorpe wrote:
>
>> On Jan 28, 2020, at 10:25 PM, Kamil Rytarowski wrote:
>>
>> The distribution build breaks for me with:
>
> Should be fixed with:
>
> /cvsroot/src/sys/rump/net/lib/libnet/Makefile,v <-- Makefile
> new revision: 1.33; previous revision: 1.32
>
> On Jan 28, 2020, at 10:25 PM, Kamil Rytarowski wrote:
>
> The distribution build breaks for me with:
Should be fixed with:
/cvsroot/src/sys/rump/net/lib/libnet/Makefile,v <-- Makefile
new revision: 1.33; previous revision: 1.32
>
On 29.01.2020 04:16, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Wed Jan 29 03:16:28 UTC 2020
>
> Modified Files:
> src/sys/net: Makefile files.net if.c if.h
> Added Files:
> src/sys/net: if_stats.c if_stats.h
>
> Log Message:
> Add support for
In article ,
Christos Zoulas wrote:
>In article <4251.1580234...@jinx.noi.kre.to>,
>Robert Elz wrote:
>>Date:Tue, 28 Jan 2020 16:40:27 +
>>From:"Andrew Doran"
>>Message-ID: <20200128164027.8558bf...@cvs.netbsd.org>
>>
>> | Log Message:
>> | Put pri_t back to
In article <4251.1580234...@jinx.noi.kre.to>,
Robert Elz wrote:
>Date:Tue, 28 Jan 2020 16:40:27 +
>From:"Andrew Doran"
>Message-ID: <20200128164027.8558bf...@cvs.netbsd.org>
>
> | Log Message:
> | Put pri_t back to an int. It looks like there might be a sign
On 28/01/2020 17:47, Maxime Villard wrote:
@@ -460,8 +460,7 @@ cpu_setup_id(struct cpu_info *ci)
id->ac_aa64mmfr0 = reg_id_aa64mmfr0_el1_read();
id->ac_aa64mmfr1 = reg_id_aa64mmfr1_el1_read();
- /* Only in ARMv8.2. */
- id->ac_aa64mmfr2 = 0 /*
Date:Tue, 28 Jan 2020 16:40:27 +
From:"Andrew Doran"
Message-ID: <20200128164027.8558bf...@cvs.netbsd.org>
| Log Message:
| Put pri_t back to an int. It looks like there might be a sign extension
| issue somewhere but it's not worth the hassle trying to
> On Jan 25, 2020, at 6:31 AM, Christos Zoulas wrote:
>
>> This seems a little silly to have in the kernel configuration file. I
>> think there's an argument to be made that there should be a header that
>> sets these defaults that can be tuned per-platform (or even some
>> functionality to
In article ,
Jason Thorpe wrote:
>
>> On Jan 25, 2020, at 4:26 AM, Jared D. McNeill wrote:
>>
>> Module Name: src
>> Committed By:jmcneill
>> Date:Sat Jan 25 12:26:58 UTC 2020
>>
>> Modified Files:
>> src/sys/arch/evbarm/conf: GENERIC GENERIC64
>>
>> Log Message:
> On Jan 25, 2020, at 4:26 AM, Jared D. McNeill wrote:
>
> Module Name: src
> Committed By: jmcneill
> Date: Sat Jan 25 12:26:58 UTC 2020
>
> Modified Files:
> src/sys/arch/evbarm/conf: GENERIC GENERIC64
>
> Log Message:
> Follow amd64 and set AUDIO_BLK_MS=4 by default
This
Andrew Doran writes:
> On Wed, Jan 22, 2020 at 10:08:16AM +1100, matthew green wrote:
>
> > Andrew Doran writes:
> > > I also recommend disabling ACPI idle, at least until it can be made less
> > > aggressive by default. It causes a significant slowdown. It can be done
> > > with detaching all
701 - 800 of 5582 matches
Mail list logo
