On Thu, May 28, 2020 at 07:06:04PM +0200, Maxime Villard wrote:
> Le 27/05/2020 ? 21:58, Maxime Villard a ?crit?:
> > Le 27/05/2020 ? 21:33, Andrew Doran a ?crit?:
> > > Module Name:??? src
> > > Committed By:??? ad
> > > Date:??? Wed May 27 19:33:40 UTC 2020
> > >
> > > Modified Files:
> > >
Le 28/05/2020 à 19:06, Maxime Villard a écrit :
Le 27/05/2020 à 21:58, Maxime Villard a écrit :
Le 27/05/2020 à 21:33, Andrew Doran a écrit :
Module Name: src
Committed By: ad
Date: Wed May 27 19:33:40 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S locore.S
s
Le 27/05/2020 à 21:58, Maxime Villard a écrit :
Le 27/05/2020 à 21:33, Andrew Doran a écrit :
Module Name: src
Committed By: ad
Date: Wed May 27 19:33:40 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S locore.S
src/sys/arch/i386/i386: cpufunc.S locore.S
src
Le 27/05/2020 à 21:33, Andrew Doran a écrit :
Module Name:src
Committed By: ad
Date: Wed May 27 19:33:40 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S locore.S
src/sys/arch/i386/i386: cpufunc.S locore.S
src/sys/arch/x86/include: pmap.h
On Wed, 27 May 2020, Taylor R Campbell wrote:
Not really, because we just need to know whether usb_once_init has
been run.
OK, great!
Now, should we use something other than RUN_ONCE, which can both set
up and tear down? Sure, that might be better in principle, but there
probably aren't tha
> Date: Wed, 27 May 2020 05:28:41 -0700 (PDT)
> From: Paul Goyette
>
> Do you also need to decrement the number of busses when one is
> detached?
Not really, because we just need to know whether usb_once_init has
been run.
Now, should we use something other than RUN_ONCE, which can both set
up
On Wed, May 27, 2020 at 09:46:04PM +0900, Tetsuya Isaki wrote:
> Why are playback and recording asymmetric?
>
> Thanks,
I think this is because audio_rmixer_start is used unguarded
in audio_open (it doesn't check for the sc_rbusy flag).
This isn't the case for pmixer.
So, if the audio device is
nia,
At Tue, 26 May 2020 15:20:16 +,
Nia Alarie wrote:
> Module Name: src
> Committed By: nia
> Date: Tue May 26 15:20:16 UTC 2020
>
> Modified Files:
> src/sys/dev/audio: audio.c
>
> Log Message:
> audio: Only restart recording mixer on resume if it's already been started
>
Do you also need to decrement the number of busses when one is
detached?
On Wed, 27 May 2020, Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Wed May 27 07:17:45 UTC 2020
Modified Files:
src/sys/dev/usb: usb.c
Log Message:
Don't allow open of /dev/usb if t
Hi,
On Wed, May 27, 2020 at 2:20 AM Maxime Villard wrote:
>
> Hi,
> I don't know if this is related to your changes, but kMSan detected one uninit
> variable in virtio 3h ago:
>
> https://syzkaller.appspot.com/text?tag=CrashReport&x=12084ef610
>
> [ 153.4370851] panic: MSan: U
Hi,
I don't know if this is related to your changes, but kMSan detected one uninit
variable in virtio 3h ago:
https://syzkaller.appspot.com/text?tag=CrashReport&x=12084ef610
[ 153.4370851] panic: MSan: Uninitialized Kmem Memory From
virtio_pci_setup_interrupts()
[ 15
>> Has any consideration be given to perhaps creating a new MACHINE_ARCH for
>> this, or somehow otherwise decorating the ELF files to indicate their
>> exec-ability?
>
>I am under the impression that PAC was designed to be forewards
>compatible, so older CPUs can execute code with this annotat
On Sat, May 23, 2020 at 02:13:46PM -0700, Jason Thorpe wrote:
>
> > On May 23, 2020, at 11:08 AM, Ryo Shimizu wrote:
> >
> > Module Name:src
> > Committed By: ryo
> > Date: Sat May 23 18:08:59 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/aarch64/aarch64: cpu
> On May 23, 2020, at 11:08 AM, Ryo Shimizu wrote:
>
> Module Name: src
> Committed By: ryo
> Date: Sat May 23 18:08:59 UTC 2020
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: cpufunc.c cpuswitch.S exec_machdep.c
> genassym.cf netbsd32_machdep.c vectors.S vm_machd
On Thu, May 21, 2020 at 11:19:49PM +0200, Joerg Sonnenberger wrote:
> On Thu, May 21, 2020 at 09:12:31PM +, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Thu May 21 21:12:31 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/x86/acpi: acp
On Thu, May 21, 2020 at 09:12:31PM +, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Thu May 21 21:12:31 UTC 2020
>
> Modified Files:
> src/sys/arch/x86/acpi: acpi_wakeup.c
> src/sys/arch/x86/include: i82489var.h
> src/sys/arch/x86/x86: cpu.c lapic
On 20/05/2020 21:18, Sevan Janiyan wrote:
> Bump rcs tag which was missed in r1.9
That should've been r1.10
Sevan
Module Name:src
Committed By: ad
Date: Tue May 19 21:40:55 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S
src/sys/arch/i386/i386: cpufunc.S i386func.S
Log Message:
Make cpu_counter(), cpu_counter32() and tsc_get_timecount() into a single
preemption-s
On Tue, May 19, 2020 at 11:09:07PM +, Andrew Doran wrote:
> vnode locks are not held during getpages/putpages.
^ for fault handling, anyway. for read/write they are held by the caller to
ubc_uiomove().
Andrew
On Sun, May 17, 2020 at 11:49:52PM +, m...@netbsd.org wrote:
> On Sun, May 17, 2020 at 09:47:50PM +, m...@netbsd.org wrote:
> > On Sun, May 17, 2020 at 07:39:15PM +, Andrew Doran wrote:
> > > Module Name: src
> > > Committed By: ad
> > > Date: Sun May 17 19:39:15 U
On Sun, May 17, 2020 at 09:47:50PM +, m...@netbsd.org wrote:
> On Sun, May 17, 2020 at 07:39:15PM +, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Sun May 17 19:39:15 UTC 2020
> >
> > Modified Files:
> > src/sys/fs/tmpfs: tmpfs.h tmp
On Sun, May 17, 2020 at 07:39:15PM +, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Sun May 17 19:39:15 UTC 2020
>
> Modified Files:
> src/sys/fs/tmpfs: tmpfs.h tmpfs_subr.c tmpfs_vnops.c
>
> Log Message:
> PR kern/55268: tmpfs is slow
>
> tmpfs_getpages():
On Sat, May 16, 2020 at 02:51:43PM +1000, matthew green wrote:
> "Jaromir Dolecek" writes:
> > Module Name:src
> > Committed By: jdolecek
> > Date: Fri May 15 07:42:58 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/xen/include: intr.h
> > src/sys/arch/xen/x86
"Jaromir Dolecek" writes:
> Module Name: src
> Committed By: jdolecek
> Date: Fri May 15 07:42:58 UTC 2020
>
> Modified Files:
> src/sys/arch/xen/include: intr.h
> src/sys/arch/xen/x86: pintr.c
>
> Log Message:
> use short for irq2port[] to save memory (4KB), it only needs to
On Sun, May 10, 2020 at 03:15:22PM -, Christos Zoulas wrote:
> 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/s
On Sun, May 10, 2020 at 11:53:00PM +0100, Alexander Nasonov wrote:
> 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
Taylor R Campbell wrote:
> This sounds entirely reasonable. Would you like to draft an
> implementation of that?
Sure, I can look into this on the weekend.
> Presumably it would require writing a sysctl callback function for
> vm.swap_encrypt, and would somehow involve kauth, but I'm not sure
>
On Sat, 9 May 2020 at 14:50, Taylor R Campbell wrote:
> Module Name:src
> Committed By: riastradh
> Date: Sat May 9 21:50:39 UTC 2020
>
> Modified Files:
> src/sys/uvm: uvm_swap.c
>
> Log Message:
> Implement swap encryption.
>
> Enabled by sysctl -w vm.swap_encrypt=1. K
> 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 impr
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 w
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
> src/sys/
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 faile
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 r
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 tracer_
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 becau
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 disc
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 nyf
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 lik
> 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 m
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 "tune
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 c
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 t
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, hppa,
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 sou
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 m
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: C
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 architec
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 al
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 1
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 loo
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 varia
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 th
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.
--
Man
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: Makefile
> 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 pres
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
> k
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 != ND6_LLINF
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
However,
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 b
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: <20
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 kee
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 underst
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
> > >Messag
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 revision
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 NetBSD
> 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. Thus,
> 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 o
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: batt
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
> > > > Dat
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 Mes
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 Messag
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 co
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 a
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
[ 2
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 write
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 sm
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 def
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 Message
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
601 - 700 of 6422 matches
Mail list logo
