> Date: Sun, 10 May 2020 23:53:00 +0100
> From: Alexander Nasonov
>
> Taylor R Campbell wrote:
> > Log Message:
> > Implement swap encryption.
> >
> > Enabled by sysctl -w vm.swap_encrypt=1.
>
> If secmodel_securelevel(9) is still a thing, locking down this sysctl
> at high securelevel may
Taylor R Campbell wrote:
> Log Message:
> Implement swap encryption.
>
> Enabled by sysctl -w vm.swap_encrypt=1.
If secmodel_securelevel(9) is still a thing, locking down this sysctl
at high securelevel may improve our security. Prior to this change,
swap devices were readable (even if enrypted
In article <20200508220155.446eef...@cvs.netbsd.org>,
Andrew Doran wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: ad
>Date: Fri May 8 22:01:55 UTC 2020
>
>Modified Files:
> src/sys/arch/x86/include: cpu_counter.h
> src/sys/arch/x86/x86: cpu.c tsc.c
>
On 07.05.2020 07:46, Michael van Elst wrote:
> On Wed, May 06, 2020 at 12:39:21PM +0200, Kamil Rytarowski wrote:
>
> Hi Kamil,
>
>> If I revert the pipe(2) changes on top of NetBSD-current, the test is no
>> longer racy again.
>
> I tried 9.99.60 with and without my bugfix. The test always
On Wed, May 06, 2020 at 12:39:21PM +0200, Kamil Rytarowski wrote:
Hi Kamil,
> If I revert the pipe(2) changes on top of NetBSD-current, the test is no
> longer racy again.
I tried 9.99.60 with and without my bugfix. The test always failed
after some time with exactly that error.
If the change
This caused regressions in t_ptrace_wait* tests and random
hangs/timeouts/failures.
If I revert the pipe(2) changes on top of NetBSD-current, the test is no
longer racy again.
http://netbsd.org/~kamil/patch-00249-pipe-revert.txt
Reproducer:
cd /usr/tests/lib/libc/sys
./t_ptrace_waitpid
On Sat, 2 May 2020, 20:10 Jason Thorpe, wrote:
>
> > On May 1, 2020, at 1:07 PM, Ryo ONODERA wrote:
> >
> > Hi,
> >
> > Have you missed this thread?
> >
> > If the problem requires more time to investigate,
> > could you consider to revert ata change for a while?
> >
> > Thank you.
>
> I backed
> On May 1, 2020, at 1:07 PM, Ryo ONODERA wrote:
>
> Hi,
>
> Have you missed this thread?
>
> If the problem requires more time to investigate,
> could you consider to revert ata change for a while?
>
> Thank you.
I backed it out, but would appreciate some help tracking down the issue
On Fri, May 01, 2020 at 04:46:36PM +, m...@netbsd.org wrote:
> We can setup an equivalence: put as much effort into the SCTP removal
> proposal as there was for the SCTP introduction proposal.
>
> Since SCTP was just dropped in src without any prior discussion, I don't
> think we need any
Hi,
Have you missed this thread?
If the problem requires more time to investigate,
could you consider to revert ata change for a while?
Thank you.
Alexander Nasonov writes:
> David Brownlee wrote:
>> Just another data point - seeing this same panic on a T480 with the
>> latest kernel from
Plus to confirm reverting just this commit from today's github copy of
current (d5b32e03eac8b05d38a143ee0ec615efb2233201) boots fine on the
T480
Thanks
On Thu, 30 Apr 2020 at 00:12, Alexander Nasonov wrote:
>
> David Brownlee wrote:
> > Just another data point - seeing this same panic on a T480
We can setup an equivalence: put as much effort into the SCTP removal
proposal as there was for the SCTP introduction proposal.
Since SCTP was just dropped in src without any prior discussion, I don't
think we need any discussion for removing it.
At Fri, 01 May 2020 15:41:14 +1000,
matthew green wrote:
> > > .. I mean, if it's a "tuneable" value like this rather than a constant
> > > like
> > > __HAVE_SLOW_COMPUTER. :-)
> >
> > I see. I like this feeling. (not strong opinion too though)
> > How about you, mrg@?
>
> works for me. i
> At Wed, 29 Apr 2020 21:59:59 +,
> Andrew Doran wrote:
> > > > How about this diff?
> > > > The old platforms are the same as before, hppa, m68k, sh3, sparc(!64)
> > > > and vax.
> > >
> > > machine/param.h seems more natural to me. I don't have a strong opinion
> > > though.
> >
> > .. I
At Wed, 29 Apr 2020 21:59:59 +,
Andrew Doran wrote:
> > > How about this diff?
> > > The old platforms are the same as before, hppa, m68k, sh3, sparc(!64)
> > > and vax.
> >
> > machine/param.h seems more natural to me. I don't have a strong opinion
> > though.
>
> .. I mean, if it's a
David Brownlee wrote:
> Just another data point - seeing this same panic on a T480 with the
> latest kernel from nyftp
Same problem on T470.
--
Alex
On Wed, Apr 29, 2020 at 09:58:55PM +, Andrew Doran wrote:
> On Wed, Apr 29, 2020 at 02:32:39PM +0900, Tetsuya Isaki wrote:
> > At Wed, 29 Apr 2020 12:22:01 +0900,
>
> > Tetsuya Isaki wrote:
> > > > i would just put it in types.h called __AUDIO_BLK_MS,
> > > > and leave a default used in the
On Wed, Apr 29, 2020 at 02:32:39PM +0900, Tetsuya Isaki wrote:
> At Wed, 29 Apr 2020 12:22:01 +0900,
> Tetsuya Isaki wrote:
> > > i would just put it in types.h called __AUDIO_BLK_MS,
> > > and leave a default used in the code if unset.
> > It sounds nice.
> > I commit once here, and then I will
Just another data point - seeing this same panic on a T480 with the
latest kernel from nyftp
At Wed, 29 Apr 2020 12:22:01 +0900,
Tetsuya Isaki wrote:
> > i would just put it in types.h called __AUDIO_BLK_MS,
> > and leave a default used in the code if unset.
> It sounds nice.
> I commit once here, and then I will try it.
How about this diff?
The old platforms are the same as before,
At Tue, 28 Apr 2020 05:33:45 +1000,
matthew green wrote:
> i would just put it in types.h called __AUDIO_BLK_MS,
> and leave a default used in the code if unset.
It sounds nice.
I commit once here, and then I will try it.
Thanks,
---
Tetsuya Isaki
At Mon, 27 Apr 2020 15:58:01 +0200,
Joerg Sonnenberger wrote:
> > Then how about this?
> > (thanks tsutsui@ for comment about choosing archs)
> > This #ifdefs may not look elegance, but I think it's simple and
> > realistic.
>
> I'd just move it the whole block into audio.c, but otherwise this
On 20-04-26 18:15, Maxime Villard wrote:
| - There was no demonstrated use-case justifying importing it. In addition,
|major OSes like Windows and macOS do not implement SCTP. There just is no
|demand for SCTP on the market; and on NetBSD, proportionally even less.
SCTP is used in
Ryo ONODERA writes:
> Hi,
>
> After this commit, NetBSD/amd64-current on my HP Spectre x360
> freezes after acpiacad0 detection (before ld0 detection).
> Reverting this commit in latest tree fixes my freeze problem.
>
> Could you take a look at my problem?
>
> Thank you.
>
> === === ===
> cpu7:
On Tue, Apr 28, 2020 at 05:33:45AM +1000, matthew green wrote:
> i would just put it in types.h called __AUDIO_BLK_MS,
> and leave a default used in the code if unset.
Adding: please consider making the default assume a fast machine.
This is the value that will also be used by newly added
i would just put it in types.h called __AUDIO_BLK_MS,
and leave a default used in the code if unset.
.mrg.
> Module Name: src
> Committed By: tsutsui
> Date: Mon Apr 27 16:57:31 UTC 2020
>
> Modified Files:
> src/sys/external/bsd/drm2/dist/drm/radeon: radeon_ttm.c
>
> Log Message:
> Fix possible bus_dmamap_load(9) leak. PR/55127
>
> "Looks good to me" from riastradh@.
> Note it was
Hi,
After this commit, NetBSD/amd64-current on my HP Spectre x360
freezes after acpiacad0 detection (before ld0 detection).
Reverting this commit in latest tree fixes my freeze problem.
Could you take a look at my problem?
Thank you.
=== === ===
cpu7: CPU max freq 40 Hz
cpu7: TSC freq
On Mon, Apr 27, 2020 at 06:19:18PM +0900, Tetsuya Isaki wrote:
> As a result of some discussion here, adding 60+ one-line header
> files like is troublesome or annoying.
> And I have no good idea to generate a suitable border line from
> existing parameters or something.
>
> Then how about this?
As a result of some discussion here, adding 60+ one-line header
files like is troublesome or annoying.
And I have no good idea to generate a suitable border line from
existing parameters or something.
Then how about this?
(thanks tsutsui@ for comment about choosing archs)
This #ifdefs may not
On Fri, Apr 24, 2020 at 05:36:55PM +, Jonathan A. Kollasch wrote:
> Module Name: src
> Committed By: jakllsch
> Date: Fri Apr 24 17:36:55 UTC 2020
>
> Modified Files:
> src/sys/netinet6: in6_proto.c
>
> Log Message:
> Fill in .pr_usrreqs for SOCK_SEQPACKET and SOCK_STREAM
On 2020/04/27 11:47, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon Apr 27 02:47:26 UTC 2020
Modified Files:
src/sys/uvm: uvm_extern.h
Log Message:
Add missing \ to fix build for PMAP_CACHE_VIVT, i.e., ARMv4 and prior.
s/v4/v5/
> On Apr 26, 2020, at 2:04 PM, Michael van Elst wrote:
>
> Log Message:
> fix DIAGNOSTIC build
non-DIAGNOSTIC you mean?
-- thorpej
Le 26/04/2020 à 16:21, Jonathan A. Kollasch a écrit :
> Module Name: src
> Committed By: jakllsch
> Date: Sun Apr 26 14:21:14 UTC 2020
>
> Modified Files:
> src/sys/kern: uipc_socket.c
>
> Log Message:
> Implement SCTP bug fixes found by maxv@.
>
> Adding these seems to improve
On Sat, Apr 25, 2020 at 08:49:14AM -0700, Jason Thorpe wrote:
> Why were any of these files touched by Xen changes?
listsrcdirs is expected, we need to add xen here (because we now need
xen/intrdefs.h
For others I don't know. Actually a cvs diff shows that only the $NetBSD: $
did change.
--
Why were any of these files touched by Xen changes?
> On Apr 25, 2020, at 8:42 AM, Manuel Bouyer wrote:
>
> Module Name: src
> Committed By: bouyer
> Date: Sat Apr 25 15:42:15 UTC 2020
>
> Modified Files:
> src/sys/rump: listsrcdirs
> src/sys/rump/dev/lib/libumass:
> On Apr 24, 2020, at 3:39 AM, Kamil Rytarowski wrote:
>
> This is a good idea (and preexisting in other kernels), unfortunately we
> had locking issues in rust. If a multithreaded process is forked, we
> shall create a replica of a calling thread and keep mutexes functional.
> We tried to
On 24.04.2020 05:22, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Fri Apr 24 03:22:06 UTC 2020
>
> Modified Files:
> src/sys/compat/linux/common: linux_exec.c linux_sched.c
> src/sys/kern: kern_exec.c kern_exit.c kern_fork.c kern_lwp.c
>
On 22/04/2020 20:32, Roy Marples wrote:
Module Name:src
Committed By: roy
Date: Wed Apr 22 19:32:11 UTC 2020
Modified Files:
src/sys/netinet6: nd6_nbr.c
Log Message:
inet6: nd6_na_input() now considers ln_state <= ND6_LLINFO_INCOMPLETE
Otherwise if ln_state !=
In addition to these files in this mail:
Modified Files:
src/lib/libc/arch/m68k/gen: Makefile.inc
src/lib/libc/compiler_rt: Makefile.inc
src/sys/arch/sun68k/stand/libsa: Makefile.inc
Removed Files:
src/common/lib/libc/arch/m68k/gen: divsi3.S modsi3.S udivsi3.S umodsi3.S
I almost got a heart attack between your first email and your second one,
wondering how this code got re-enabled. Thanks for clarifying.
Relevant example, by the way.
Committed on August 20th 2019 at 09:32
https://mail-index.netbsd.org/source-changes/2019/08/20/msg108321.html
Disabled
Good news everyone. Does not affect any release at all.
Also might not have been a security issue, because christos did a weird
thing where it is compiled but somehow still disabled.
On Sun, Apr 19, 2020 at 05:40:50PM +, Maya Rashish wrote:
> Module Name: src
> Committed By: maya
> Date:
On Fri, Apr 17, 2020 at 9:02 AM Manuel Bouyer
wrote:
> On Fri, Apr 17, 2020 at 07:52:53AM -0700, Jason Thorpe wrote:
> >
> > > On Apr 17, 2020, at 7:46 AM, Robert Elz wrote:
> > >
> > >Date:Fri, 17 Apr 2020 15:37:33 +0200
> > >From:Manuel Bouyer
> > >Message-ID:
Date:Sat, 18 Apr 2020 10:29:33 +
From:m...@netbsd.org
Message-ID: <20200418102933.ga24...@homeworld.netbsd.org>
| I feel like it's difficult to decide which is objectively better.
It all depends upon usage patterns, and objectives.
| CVS encourages you to
On Fri, Apr 17, 2020 at 11:39:01PM +0700, Robert Elz wrote:
> Date:Fri, 17 Apr 2020 07:52:53 -0700
> From:Jason Thorpe
> Message-ID: <7e54033f-9f14-4db3-a11a-01d63cd92...@me.com>
>
> | The New Hotness (which isn't particularly new, at this point)
> | is to create
Date:Fri, 17 Apr 2020 07:52:53 -0700
From:Jason Thorpe
Message-ID: <7e54033f-9f14-4db3-a11a-01d63cd92...@me.com>
| The New Hotness (which isn't particularly new, at this point)
| is to create branches and merge what you want into that branch.
What I don't
On Fri, Apr 17, 2020 at 05:01:15PM +0200, Manuel Bouyer wrote:
> On Fri, Apr 17, 2020 at 07:52:53AM -0700, Jason Thorpe wrote:
> >
> > > On Apr 17, 2020, at 7:46 AM, Robert Elz wrote:
> > >
> > >Date:Fri, 17 Apr 2020 15:37:33 +0200
> > >From:Manuel Bouyer
> > >
On Fri, Apr 17, 2020 at 07:52:53AM -0700, Jason Thorpe wrote:
>
> > On Apr 17, 2020, at 7:46 AM, Robert Elz wrote:
> >
> >Date:Fri, 17 Apr 2020 15:37:33 +0200
> >From:Manuel Bouyer
> >Message-ID: <20200417133733.ga5...@antioche.eu.org>
> >
> > | And that would be
> On Apr 17, 2020, at 7:46 AM, Robert Elz wrote:
>
>Date:Fri, 17 Apr 2020 15:37:33 +0200
>From:Manuel Bouyer
>Message-ID: <20200417133733.ga5...@antioche.eu.org>
>
> | And that would be a problem for me. I regulary update a single file to a
> | specific
Date:Fri, 17 Apr 2020 15:37:33 +0200
From:Manuel Bouyer
Message-ID: <20200417133733.ga5...@antioche.eu.org>
| And that would be a problem for me. I regulary update a single file to a
| specific revision in a source tree.
Me too - I pull the current sh into
> On Apr 17, 2020, at 6:28 AM, Rin Okuyama wrote:
>
> On 2020/04/17 22:14, Jason Thorpe wrote:
>>> On Apr 17, 2020, at 12:24 AM, Robert Elz wrote:
>>>
>>> For this, RCS and RCS semantics are irrelevant aren't they?
>> No, not really. With the modern systems, the "commit ID" identifies the
On Fri, Apr 17, 2020 at 06:14:26AM -0700, Jason Thorpe wrote:
>
> > On Apr 17, 2020, at 12:24 AM, Robert Elz wrote:
> >
> > For this, RCS and RCS semantics are irrelevant aren't they?
>
> No, not really. With the modern systems, the "commit ID" identifies the
> state of the entire collection
On 2020/04/17 22:14, Jason Thorpe wrote:
On Apr 17, 2020, at 12:24 AM, Robert Elz wrote:
For this, RCS and RCS semantics are irrelevant aren't they?
No, not really. With the modern systems, the "commit ID" identifies the state
of the entire collection of files, not individual ones.
> On Apr 17, 2020, at 12:24 AM, Robert Elz wrote:
>
> For this, RCS and RCS semantics are irrelevant aren't they?
No, not really. With the modern systems, the "commit ID" identifies the state
of the entire collection of files, not individual ones. Thus, you only need
exactly one instance
Date:Thu, 16 Apr 2020 18:04:04 -0700
From:Jason Thorpe
Message-ID: <432f538a-b863-441b-b4d0-0cd2e9d38...@me.com>
| The sooner we get off of "things that use RCS semantics" the better.
For this, RCS and RCS semantics are irrelevant aren't they? The only
relevance
> On Apr 16, 2020, at 5:51 PM, Joerg Sonnenberger wrote:
>
>
> That can be fixed generically? .ident needs the SHF_MERGE|SHF_STRINGS as
> section flags and then the linker should do the rest by itself.
Does it matter? The sooner we get off of "things that use RCS semantics" the
better.
--
On Fri, Apr 17, 2020 at 07:31:51AM +0900, Rin Okuyama wrote:
> On 2020/04/17 6:56, Rin Okuyama wrote:
> > Module Name:src
> > Committed By: rin
> > Date: Thu Apr 16 21:56:43 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/arm/omap: omap3_sdmareg.h omap3_sdmavar.h
On 2020/04/17 6:56, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Thu Apr 16 21:56:43 UTC 2020
Modified Files:
src/sys/arch/arm/omap: omap3_sdmareg.h omap3_sdmavar.h omapfbreg.h
src/sys/arch/arm/ti: omap3_dssreg.h
src/sys/arch/macppc/dev:
On Mon, Apr 13, 2020 at 08:09:13PM +, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Mon Apr 13 20:09:13 UTC 2020
>
> Modified Files:
> src/sys/arch/xen/xen: xbd_xenbus.c
>
> Log Message:
> KASSERT() that requested I/O size is <= XBD_MAX_XFER - this
On Mon, Apr 13, 2020 at 04:34:48PM +0100, Roy Marples wrote:
> On 13/04/2020 16:31, Andrew Doran wrote:
> > Hi Roy.
> >
> > On Sat, Apr 11, 2020 at 02:13:06AM +0100, Roy Marples wrote:
> > > On 10/04/2020 23:34, Andrew Doran wrote:
> > > > Module Name:src
> > > > Committed By: ad
> > > >
On 13/04/2020 16:31, Andrew Doran wrote:
Hi Roy.
On Sat, Apr 11, 2020 at 02:13:06AM +0100, Roy Marples wrote:
On 10/04/2020 23:34, Andrew Doran wrote:
Module Name:src
Committed By: ad
Date: Fri Apr 10 22:34:36 UTC 2020
Modified Files:
src/sys/kern: vfs_mount.c
Log
Hi Roy.
On Sat, Apr 11, 2020 at 02:13:06AM +0100, Roy Marples wrote:
> On 10/04/2020 23:34, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Fri Apr 10 22:34:36 UTC 2020
> >
> > Modified Files:
> > src/sys/kern: vfs_mount.c
> >
> > Log
Now that's a simpler fix than I imagined it would be...
kre
At Thu, 9 Apr 2020 16:54:12 +0200,
Joerg Sonnenberger wrote:
> There are two possible reasons for a lower limit for the buffer size:
> (1) The device requires a certain amount.
> (2) The system wants to ensure the interrupt rate doesn't go over a
> certain rate.
>
> The real value shouldn't be a
On 10/04/2020 23:34, Andrew Doran wrote:
Module Name:src
Committed By: ad
Date: Fri Apr 10 22:34:36 UTC 2020
Modified Files:
src/sys/kern: vfs_mount.c
Log Message:
vfs_mountroot(): don't needlessly grab a second reference to the root vnode
(the kernel never chdirs) nor
On Thu, Apr 09, 2020 at 09:52:37PM +0900, Tetsuya Isaki wrote:
> At Fri, 3 Apr 2020 17:51:21 +0200,
> Joerg Sonnenberger wrote:
> > It seems perfectly
> > sensible to me that the final output device can provide a lower limit as
> > well as having one derived from HZ and using whatever is higher.
>
HI,
I am not sur whether it is the commit below, but 2 out 4 times my
xen-DOMU from today (20200409/9.99.55)
panics with following locking botch:
[ 29.9301379] panic: kernel diagnostic assertion "IFNET_LOCKED(ifp)"
failed: file "/usr/src/sys/arch/xen/xen/if_xennet_xenbus.c", line 1120
[
At Fri, 3 Apr 2020 17:51:21 +0200,
Joerg Sonnenberger wrote:
> It seems perfectly
> sensible to me that the final output device can provide a lower limit as
> well as having one derived from HZ and using whatever is higher.
Sorry, I could not translate well and I didn't understand.
Could you
On Tue, Apr 07, 2020 at 02:50:25PM +0900, Tetsuya Isaki wrote:
> In this case, yds(4) is attached at 5msec automatically.
> When attaching, audio layer calculates the blocksize from
> AUDI_BLK_MS etc and query it to MD driver (this is round_blocksize
> in audio(9)). If the requested size is too
At Fri, 3 Apr 2020 17:48:54 +0200,
Martin Husemann wrote:
> > I don't think so. Each driver/hardware may have their specific
> > restrictions. Some driver/hardware may be able to set at 1msec
> > but others may not. It's nature. And this is also why we
> > should not be eager to reduce
On Sun, Mar 29, 2020 at 11:41:23AM +0200, Maxime Villard wrote:
> Le 23/03/2020 ? 21:02, Andrew Doran a ?crit?:
> > Module Name:src
> > Committed By: ad
> > Date: Mon Mar 23 20:02:14 UTC 2020
> >
> > Modified Files:
> > src/sys/kern: vfs_cache.c
> >
> > Log
On Sun, Apr 05, 2020 at 05:26:47PM +, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Sun Apr 5 17:26:47 UTC 2020
>
> Modified Files:
> src/sys/arch/xen/xen: if_xennet_xenbus.c xennetback_xenbus.c
>
> Log Message:
> remove support for legacy rx-flip
On Fri, Apr 03, 2020 at 09:45:20PM +0900, Tetsuya Isaki wrote:
> [*] On my alpha (500MHz), wss(4)/ISA works even on blk_ms=1.
> But I was not able to set 1msec on yds(4) PCI sound card on
> the same machine. Its lower limit was 5msec (due to driver's
> or hardware's restriction, I don't know
On Fri, Apr 03, 2020 at 11:40:08PM +0900, Tetsuya Isaki wrote:
> I don't think so. Each driver/hardware may have their specific
> restrictions. Some driver/hardware may be able to set at 1msec
> but others may not. It's nature. And this is also why we
> should not be eager to reduce default
At Fri, 3 Apr 2020 15:15:36 +0200,
Martin Husemann wrote:
> > [*] On my alpha (500MHz), wss(4)/ISA works even on blk_ms=1.
> > But I was not able to set 1msec on yds(4) PCI sound card on
> > the same machine. Its lower limit was 5msec (due to driver's
> > or hardware's restriction, I don't
At Fri, 3 Apr 2020 06:15:04 -0700,
Jason Thorpe wrote:
> > By the way, I am planning the following. How about this?
>
> I very much dislike creating an additional header file for this.
Me too :) (this is why I haven't done it before)
> I would prefer if the default were tuned for modern
On Fri, Apr 03, 2020 at 09:45:20PM +0900, Tetsuya Isaki wrote:
> [*] On my alpha (500MHz), wss(4)/ISA works even on blk_ms=1.
> But I was not able to set 1msec on yds(4) PCI sound card on
> the same machine. Its lower limit was 5msec (due to driver's
> or hardware's restriction, I don't know
> On Apr 3, 2020, at 5:45 AM, Tetsuya Isaki wrote:
>
> By the way, I am planning the following. How about this?
I very much dislike creating an additional header file for this.
I would prefer if the default were tuned for modern systems and overridable by
a value exported (in a
At Sun, 29 Mar 2020 15:11:39 +0200,
Joerg Sonnenberger wrote:
> > CPU load or performance is not subject. I know that my
> > implementation will work on the most modern real hardware.
> > But I feel that at least 4msec is too rush to be default.
> > A default should not be for one game
Hi,
Hmm, but TSC drift is still observed on recent (high clock) CPUs.
I will have researched and fix later.
On 2020/04/03 12:05, Kengo NAKAHARA wrote:
Module Name:src
Committed By: knakahara
Date: Fri Apr 3 03:05:39 UTC 2020
Modified Files:
src/sys/arch/x86/x86: tsc.c
On Thu, Apr 2, 2020 at 8:37 PM Nick Hudson wrote:
>
> Module Name:src
> Committed By: skrll
> Date: Thu Apr 2 11:37:23 UTC 2020
>
> Modified Files:
> src/sys/dev/usb: xhci.c xhcivar.h
>
> Log Message:
> Reduce the memory footprint by allocating a ring per endpoint/pipe on
> Date: Wed, 1 Apr 2020 07:42:53 -0700
> From: Jason Thorpe
>
> If PAGE_SIZE is ostensibly a vsize_t / size_t, why not define it as (1U <<
> PAGE_SHIFT)?
Without running the following program, can you tell me what it will
print?
It might work to define PAGE_SIZE to be ((size_t)1 <<
I think that PAGESIZE is not always a constant in our code.
christos
signature.asc
Description: Message signed with OpenPGP
Date:Wed, 1 Apr 2020 16:31:01 +0200
From:Kamil Rytarowski
Message-ID:
| Does it look better?
|
| http://netbsd.org/~kamil/patch-00244-fopsmapper-PAGE_SIZE.txt
Apart from it needing to be (expressed in the relevant
make syntax, whatever that is)
if
> If PAGE_SIZE is ostensibly a vsize_t / size_t, why not define it as (1U <<
> PAGE_SHIFT)?
It will *probably* work unless we have 'if (negative_int > PAGESIZE)'
somewhere. I guess if you make the change and the kernel boots... :-)
christos
signature.asc
Description: Message signed with
> On Apr 1, 2020, at 7:17 AM, Christos Zoulas wrote:
>
> Which we have been slowly fixing. I think in this case the sign-compare
> warnings are annoying, but putting casts on each warning is cluttering
> the code needlessly. Unfortunately the alternative (to make the PAGESIZE
> constant
On 01.04.2020 16:17, Christos Zoulas wrote:
> In article ,
> Paul Goyette wrote:
>> On Wed, 1 Apr 2020, Kamil Rytarowski wrote:
>>
>>> On 01.04.2020 15:47, Robert Elz wrote:
Date:Wed, 1 Apr 2020 11:45:53 +
From:"Kamil Rytarowski"
Message-ID:
In article ,
Paul Goyette wrote:
>On Wed, 1 Apr 2020, Kamil Rytarowski wrote:
>
>> On 01.04.2020 15:47, Robert Elz wrote:
>>> Date:Wed, 1 Apr 2020 11:45:53 +
>>> From:"Kamil Rytarowski"
>>> Message-ID: <20200401114554.05167f...@cvs.netbsd.org>
>>>
>>> | Log
On 01.04.2020 16:10, Paul Goyette wrote:
> On Wed, 1 Apr 2020, Kamil Rytarowski wrote:
>
>> On 01.04.2020 15:47, Robert Elz wrote:
>>> Date: Wed, 1 Apr 2020 11:45:53 +
>>> From: "Kamil Rytarowski"
>>> Message-ID: <20200401114554.05167f...@cvs.netbsd.org>
>>>
>>> |
On Wed, 1 Apr 2020, Kamil Rytarowski wrote:
On 01.04.2020 15:47, Robert Elz wrote:
Date:Wed, 1 Apr 2020 11:45:53 +
From:"Kamil Rytarowski"
Message-ID: <20200401114554.05167f...@cvs.netbsd.org>
| Log Message:
| Avoid comparison between signed and unsigned
On 01.04.2020 15:47, Robert Elz wrote:
> Date:Wed, 1 Apr 2020 11:45:53 +
> From:"Kamil Rytarowski"
> Message-ID: <20200401114554.05167f...@cvs.netbsd.org>
>
> | Log Message:
> | Avoid comparison between signed and unsigned integer
> |
> | Cast PAGE_SIZE to
Date:Wed, 1 Apr 2020 11:45:53 +
From:"Kamil Rytarowski"
Message-ID: <20200401114554.05167f...@cvs.netbsd.org>
| Log Message:
| Avoid comparison between signed and unsigned integer
|
| Cast PAGE_SIZE to size_t.
This kind of pedantry is going way too far,
> On Mar 29, 2020, at 8:03 AM, Joerg Sonnenberger wrote:
>
> Yes and I see no fundamental reason for not allowing buffering with 1ms
> frames in that case. I expect Alpha to be fast enough to do that with
> little overhead.
That's fine, I just wanted to point it out.
-- thorpej
On Sun, Mar 29, 2020 at 07:26:26AM -0700, Jason Thorpe wrote:
>
> > On Mar 29, 2020, at 6:11 AM, Joerg Sonnenberger wrote:
> >
> > I would allow at least 1/HZ as baseline.
>
> Be careful, some platforms have a relatively high HZ (e.g. Alpha HZ=1024).
Yes and I see no fundamental reason for
> On Mar 29, 2020, at 6:11 AM, Joerg Sonnenberger wrote:
>
> I would allow at least 1/HZ as baseline.
Be careful, some platforms have a relatively high HZ (e.g. Alpha HZ=1024).
-- thorpej
On Sun, Mar 29, 2020 at 01:11:47PM +0900, Tetsuya Isaki wrote:
> > I would prefer if blk_ms were kept below 5ms on amd64 and aarch64.
> > We don't have to worry about the CPU load of playing audio on these
> > platforms.
>
> CPU load or performance is not subject. I know that my
>
Le 23/03/2020 à 21:02, Andrew Doran a écrit :
> Module Name: src
> Committed By: ad
> Date: Mon Mar 23 20:02:14 UTC 2020
>
> Modified Files:
> src/sys/kern: vfs_cache.c
>
> Log Message:
> cache_remove(): remove from the vnode list first, so cache_revlookup()
> doesn't try to
At Sat, 28 Mar 2020 10:40:26 +0100,
Martin Husemann wrote:
> It would be good to have a file somewhere in the audio code where the
> default is selected based on some ifdefs - if we don't have anything
> better something like:
>
> #if defined(__m68k__) || defined(__vax__) || \
>
At Sat, 28 Mar 2020 09:34:11 +,
nia 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 Sat, Mar 28, 2020 at 09:34:11AM +, nia wrote:
> > - It's not good idea to set such parameter in individual GENERICs.
>
> It's not a good idea to punish the majority of NetBSD users because m68k
> is incredibly slow.
Both statements are true, and the latter is based on a misunderstanding.
601 - 700 of 5582 matches
Mail list logo
