> Since this change if_udav.c doesn't work. Simply plugging a USB-to-ethernet
> device triggers a page fault on mutex_enter in udav_attach.
>
> Quickly looking at the code:
>
> 240 usbnet_lock_core(un);
> 241 usbnet_busy(un);
> 242
> 243 ///* reset the adapter */
> 244 //
Hi Michael,
Perhaps your commit missed some changes? The code no longer compiles.
Cheers,
+ Kimmo
/p/netbsd/cvs/src/sys/dev/i2c/dbcool.c: In function 'dbcool_attach':
/p/netbsd/cvs/src/sys/dev/i2c/dbcool.c:778:4: error: 'struct dbcool_softc' has
no member named 'sc_prop'
sc->sc_prop =
On Sun, Jul 12, 2020 at 12:05:37AM +0700, Robert Elz wrote:
> Just to make things clear here, the LUN you're talking about is not
> the scsi unit number (which is what I think Martin was referring to)
> but a sub-device number within a single scsi ID. Right?
Correct. I should have written "SCSI
Date:Sat, 11 Jul 2020 18:24:51 +0300
From:Kimmo Suominen
Message-ID: <20200711152451.ga1...@homeworld.netbsd.org>
| On Sat, Jul 11, 2020 at 05:00:02PM +0200, Martin Husemann wrote:
| > I don't understand the change. When was this broken? This has always
worked
On Sat, Jul 11, 2020 at 06:24:51PM +0300, Kimmo Suominen wrote:
> I think all real SCSI hardware I've had has always just only had LUN 0,
> and each disk has been on its own SCSI ID (target).
Yes, I confused ID and LUN here - just ignore me.
Martin
On Sat, Jul 11, 2020 at 05:00:02PM +0200, Martin Husemann wrote:
> I don't understand the change. When was this broken? This has always worked
> for me e.g. with the sd0 at LUN 3 and the controller at 6 or 7.
I think all real SCSI hardware I've had has always just only had LUN 0,
and each disk
On Sat, Jul 11, 2020 at 05:57:46PM +0300, Kimmo Suominen wrote:
> On Sat, Jul 11, 2020 at 05:47:34PM +0300, Jukka Ruohonen wrote:
> > I'd reckon a pullup to NetBSD 9 would be in order?
>
> Yes, I was just waiting to be able to link to mail-index. I had
> already checked that the patch applies
On Sat, Jul 11, 2020 at 05:47:34PM +0300, Jukka Ruohonen wrote:
> I'd reckon a pullup to NetBSD 9 would be in order?
Yes, I was just waiting to be able to link to mail-index. I had
already checked that the patch applies cleanly to both netbsd-9
and netbsd-8.
On Sat, Jul 11, 2020 at 02:31:46PM +, Kimmo Suominen wrote:
> Use case 2: A Linode boot profile with multiple disks results in
> the first disk ("sda") on LUN 1, while the second disk ("sdb") is
> on LUN 0, each on their own bus.
As Linode is quite popular, and supposedly uses a rather
Module Name:src
Committed By: thorpej
Date: Sun Mar 15 23:04:51 UTC 2020
Modified Files:
src/sys/arch/arm/amlogic: gxlphy.c
src/sys/arch/x86/pci: if_vmx.c
src/sys/dev/mii: acphy.c amhphy.c atphy.c bmtphy.c brgphy.c ciphy.c
dmphy.c etphy.c
"Valeriy E. Ushakov" wrote:
> Module Name: src
> Committed By: uwe
> Date: Wed Jul 8 19:39:22 UTC 2020
>
> Modified Files:
>
> src/sys/conf: assym.mk
>
> Log Message:
>
> Drop -fstack-usage* from CFLAGS passed genassym.
> We don't want it to create a "-.su" file.
Thanks!
Cheers,
> On Jul 8, 2020, at 12:22 AM, Martin Husemann wrote:
>
> On Tue, Jul 07, 2020 at 03:38:49AM +, Jason R Thorpe wrote:
>> Provide a new resource provider API:
>
> This is *extremly* verbose and overflows message buffer, can you move the
> new messages to aprint_debug or ifdef with some
On Tue, Jul 07, 2020 at 03:38:49AM +, Jason R Thorpe wrote:
> Provide a new resource provider API:
This is *extremly* verbose and overflows message buffer, can you move the
new messages to aprint_debug or ifdef with some proper DEBUG_* please?
Martin
On 2020/07/07 9:51, Jason Thorpe wrote:
On Jul 6, 2020, at 5:28 PM, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Tue Jul 7 00:28:31 UTC 2020
Modified Files:
src/sys/arch/powerpc/booke: e500_tlb.c
Log Message:
Fix kernel panic due to tmpfs.
pmap for
> On Jul 6, 2020, at 5:28 PM, Rin Okuyama wrote:
>
> Module Name: src
> Committed By: rin
> Date: Tue Jul 7 00:28:31 UTC 2020
>
> Modified Files:
> src/sys/arch/powerpc/booke: e500_tlb.c
>
> Log Message:
> Fix kernel panic due to tmpfs.
>
> pmap for booke assumes that the
I think this will have issues on some big.LITTLE configurations
like Rockchip RK3399.
In the RK3399 case cpu[0-3] is VIPT I$ and cpu[4-5] is PIPT I$. Boot
order of secondaries is not guaranteed so it is possible to get different
values of aarch64_cache_vindexsize from one boot to the next.
Martin Husemann writes:
>
> That build pre-dates Luke's fix.
>
Ahh, you are correct and it built fine for me, apologies.
Thanks
On Thu, Jul 02, 2020 at 08:03:09AM -0700, scole_mail wrote:
> That change didn't work:
>
> http://releng.netbsd.org/builds/HEAD/202007020210Z/ia64.build.failed
> ...
> nbmake[10]: nbmake[10]: don't know how to make loader.efi.c. Stop
That build pre-dates Luke's fix.
Martin
"Luke Mewburn" writes:
> Module Name: src
> Committed By: lukem
> Date: Thu Jul 2 09:07:25 UTC 2020
>
> Modified Files:
> src/sys/arch/ia64/stand/ia64/efi: Makefile
>
> Log Message:
> loader.efi doesn't have source
>
> (Untested fix)
>
>
> To generate a diff of this commit:
> cvs
> On Jun 28, 2020, at 10:24 AM, Robert Elz wrote:
>
>Date:Sat, 27 Jun 2020 11:49:30 -0400
>From:"Christos Zoulas"
>Message-ID: <20200627154930.84e22f...@cvs.netbsd.org>
>
> | Modified Files:
> |src/sys/compat/sys: mount.h
> |
> | Log Message:
> | Ignore
Date:Sat, 27 Jun 2020 11:49:30 -0400
From:"Christos Zoulas"
Message-ID: <20200627154930.84e22f...@cvs.netbsd.org>
| Modified Files:
| src/sys/compat/sys: mount.h
|
| Log Message:
| Ignore the supplied size, and always use the argument size that we know.
Perhaps yes, but I'm not sure. How do you mips guys think?
Thanks,
rin
On 2020/06/27 19:08, Jaromír Doleček wrote:
Perhaps we can use a similar technique for mips too? There also the
kernel actually always uses a compile-time fixed page size AFAICS.
Jaromir
Le sam. 27 juin 2020 à 04:51, Rin
Perhaps we can use a similar technique for mips too? There also the
kernel actually always uses a compile-time fixed page size AFAICS.
Jaromir
Le sam. 27 juin 2020 à 04:51, Rin Okuyama a écrit :
>
> Module Name:src
> Committed By: rin
> Date: Sat Jun 27 02:51:23 UTC 2020
>
>
"Martin Husemann" writes:
> Module Name: src
> Committed By: martin
> Date: Fri Jun 26 10:14:32 UTC 2020
>
> Modified Files:
> src/sys/dev/ofw: ofw_subr.c
>
> Log Message:
> Remove !cold KASSERT - it does not compile on all kernels, and it is not the
> right thing to test for
Hi Rin,
Rin Okuyama wrote:
> Hi,
>
> On 2020/06/23 14:18, Simon Burge wrote:
> > Module Name:src
> > Committed By: simonb
> > Date: Tue Jun 23 05:18:43 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/mips/cavium/dev: octeon_uart.c
> >
> > Log Message:
> > Add
Hi,
On 2020/06/23 14:18, Simon Burge wrote:
Module Name:src
Committed By: simonb
Date: Tue Jun 23 05:18:43 UTC 2020
Modified Files:
src/sys/arch/mips/cavium/dev: octeon_uart.c
Log Message:
Add support for a very simple output-only console so early printf() can work.
In article <18083.1593053...@splode.eterna.com.au>,
matthew green wrote:
>"Jaromir Dolecek" writes:
>> Module Name: src
>> Committed By:jdolecek
>> Date:Wed Jun 24 19:55:25 UTC 2020
>>
>> Modified Files:
>> src/sys/dev/ic: ibm561.c
>>
>> Log Message:
>> avoid
"Jaromir Dolecek" writes:
> Module Name: src
> Committed By: jdolecek
> Date: Wed Jun 24 22:28:08 UTC 2020
>
> Modified Files:
> src/sys/arch/x86/x86: multiboot2.c
>
> Log Message:
> don't try allocating 16KB of scratch space on stack
>
> it's too early for kmem_alloc(), so use
"Jaromir Dolecek" writes:
> Module Name: src
> Committed By: jdolecek
> Date: Wed Jun 24 19:55:25 UTC 2020
>
> Modified Files:
> src/sys/dev/ic: ibm561.c
>
> Log Message:
> avoid allocating almost 5k struct ibm561data on stack in ibm561_cninit();
> it's too early for kmem_alloc(),
On Wed, Jun 24, 2020 at 10:28:08PM +, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Wed Jun 24 22:28:08 UTC 2020
>
> Modified Files:
> src/sys/arch/x86/x86: multiboot2.c
>
> Log Message:
> don't try allocating 16KB of scratch space on stack
>
>
> Module Name:src
> Committed By: jdolecek
> Date: Fri Apr 10 18:03:06 UTC 2020
>
> Modified Files:
> src/sys/arch/xen/xen: if_xennet_xenbus.c
>
> Log Message:
> convert to bus_dma(9), remove now not necessary XENPVHVM redefines
> [...]
> +
On Mon, Jun 22, 2020 at 04:14:18PM +, Maxime Villard wrote:
> Module Name: src
> Committed By: maxv
> Date: Mon Jun 22 16:14:18 UTC 2020
>
> Modified Files:
> src/sys/dev/acpi: acpi.c
>
> Log Message:
> Fix memory leak. Found by kLSan.
> +
> + default:
> +
On Mon, Jun 22, 2020 at 05:34:57AM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Mon Jun 22 05:34:57 UTC 2020
>
> Modified Files:
> src/sys/arch/powerpc/include: mcontext.h types.h
> src/sys/arch/powerpc/powerpc: sig_machdep.c
>
> Log Message:
>
On 2020/06/22 5:10, Joerg Sonnenberger wrote:
On Sun, Jun 21, 2020 at 12:40:00AM +, Rin Okuyama wrote:
- Obsolete __lwp_settcb() in order to let kernel know new TLS address via
_lwp_setprivate(2). Alternatively, we can call _lwp_setprivate(2) within
__lwp_settcb() like mips, but it is
On Sun, Jun 21, 2020 at 12:40:00AM +, Rin Okuyama wrote:
> - Obsolete __lwp_settcb() in order to let kernel know new TLS address via
> _lwp_setprivate(2). Alternatively, we can call _lwp_setprivate(2) within
> __lwp_settcb() like mips, but it is just double handling; we adjust %r2
>
On 16.06.2020 14:23, Kamil Rytarowski wrote:
> On 16.06.2020 12:25, J. Hannken-Illjes wrote:
>>> On 15. Jun 2020, at 01:38, Kamil Rytarowski wrote:
>>>
>>> Module Name:src
>>> Committed By: kamil
>>> Date: Sun Jun 14 23:38:25 UTC 2020
>>>
>>> Modified Files:
>>>
On 16.06.2020 12:25, J. Hannken-Illjes wrote:
>> On 15. Jun 2020, at 01:38, Kamil Rytarowski wrote:
>>
>> Module Name: src
>> Committed By:kamil
>> Date:Sun Jun 14 23:38:25 UTC 2020
>>
>> Modified Files:
>> src/sys/rump/include/rump: rump.h
>>
>> Log Message:
>>
> On 15. Jun 2020, at 01:38, Kamil Rytarowski wrote:
>
> Module Name: src
> Committed By: kamil
> Date: Sun Jun 14 23:38:25 UTC 2020
>
> Modified Files:
> src/sys/rump/include/rump: rump.h
>
> Log Message:
> Remove old compat include of rump_syscallshotgun.h
>
> It was
Simon Burge wrote:
> > > Module Name: src
> > > Committed By: simonb
> > > Date: Tue Jun 9 06:18:01 UTC 2020
> > >
> > > Modified Files:
> > > src/sys/arch/mips/mips: mips_machdep.c
> > >
> > > Log Message:
> > > If we are on a SiByte or Cavium CPU with an FPU, report as
Izumi Tsutsui wrote:
> > Module Name:src
> > Committed By: simonb
> > Date: Tue Jun 9 06:18:01 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/mips/mips: mips_machdep.c
> >
> > Log Message:
> > If we are on a SiByte or Cavium CPU with an FPU, report as
> Module Name: src
> Committed By: simonb
> Date: Tue Jun 9 06:18:01 UTC 2020
>
> Modified Files:
> src/sys/arch/mips/mips: mips_machdep.c
>
> Log Message:
> If we are on a SiByte or Cavium CPU with an FPU, report as "built-in FPU"
> instead of saying it's an unknown FPU type.
>
On 10/08/2018 18:11, Taylor R Campbell wrote:
Module Name:src
Committed By: riastradh
Date: Fri Aug 10 17:11:56 UTC 2018
Modified Files:
src/sys/dev/acpi: acpi_bat.c
Log Message:
Don't hold up boot: defer acpibat(4) inquiry until threads are running.
ok jmcneill@
In article <20200606135850.ge14...@pony.stderr.spb.ru>,
Valery Ushakov wrote:
>On Sat, Jun 06, 2020 at 11:25:19 +0200, Kamil Rytarowski wrote:
>
>> On 06.06.2020 09:42, Simon Burge wrote:
>> > "Kamil Rytarowski" wrote:
>> >
>> >> Module Name: src
>> >> Committed By: kamil
>> >> Date:
On Sat, Jun 06, 2020 at 11:25:19 +0200, Kamil Rytarowski wrote:
> On 06.06.2020 09:42, Simon Burge wrote:
> > "Kamil Rytarowski" wrote:
> >
> >> Module Name: src
> >> Committed By: kamil
> >> Date: Fri Jun 5 21:48:04 UTC 2020
> >>
> >> Modified Files:
> >>
> >>
On 06.06.2020 09:42, Simon Burge wrote:
> "Kamil Rytarowski" wrote:
>
>> Module Name: src
>> Committed By:kamil
>> Date:Fri Jun 5 21:48:04 UTC 2020
>>
>> Modified Files:
>>
>> src/sys/arch/x86/x86: cpu_rng.c
>>
>> Log Message:
>>
>> Change const unsigned to
"Kamil Rytarowski" wrote:
> Module Name: src
> Committed By: kamil
> Date: Fri Jun 5 21:48:04 UTC 2020
>
> Modified Files:
>
> src/sys/arch/x86/x86: cpu_rng.c
>
> Log Message:
>
> Change const unsigned to preprocessor define
>
> Fixes GCC -O0 build with the stack protector.
On 04.06.2020 23:41, Andrew Doran wrote:
> On Thu, Jun 04, 2020 at 02:35:17AM +0200, Kamil Rytarowski wrote:
>
>> On 04.06.2020 00:42, Andrew Doran wrote:
>>> On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
>>>
On 03.06.2020 01:49, Andrew Doran wrote:
> On the assembly
On Thu, Jun 04, 2020 at 02:35:17AM +0200, Kamil Rytarowski wrote:
> On 04.06.2020 00:42, Andrew Doran wrote:
> > On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
> >
> >> On 03.06.2020 01:49, Andrew Doran wrote:
> >>> On the assembly thing recall that recently you expressed a
On 04.06.2020 00:42, Andrew Doran wrote:
> On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
>
>> On 03.06.2020 01:49, Andrew Doran wrote:
>>> On the assembly thing recall that recently you expressed a desire to remove
>>> all of the amd64 assembly string functions from libc
Maxime,
I read your e-mail carefully and conclude that the best way forward here is
put this one to core@ for a technical decision.
Cheers,
Andrew
On Wed, Jun 03, 2020 at 08:25:32AM +0200, Maxime Villard wrote:
> Le 03/06/2020 ? 01:49, Andrew Doran a ?crit?:
> > On Tue, Jun 02, 2020 at
On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
> On 03.06.2020 01:49, Andrew Doran wrote:
> > On the assembly thing recall that recently you expressed a desire to remove
> > all of the amd64 assembly string functions from libc because of sanitizers -
> > I invested my time to
Le 03/06/2020 à 02:03, Kamil Rytarowski a écrit :
On 03.06.2020 01:49, Andrew Doran wrote:
On the assembly thing recall that recently you expressed a desire to remove
all of the amd64 assembly string functions from libc because of sanitizers -
I invested my time to do up a little demo to try
Le 03/06/2020 à 01:49, Andrew Doran a écrit :
On Tue, Jun 02, 2020 at 08:41:53AM +0200, Maxime Villard wrote:
Le 02/06/2020 ? 00:58, Andrew Doran a ?crit?:
Module Name:src
Committed By: ad
Date: Mon Jun 1 22:58:06 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64:
On 03.06.2020 01:49, Andrew Doran wrote:
> On the assembly thing recall that recently you expressed a desire to remove
> all of the amd64 assembly string functions from libc because of sanitizers -
> I invested my time to do up a little demo to try and show you why that's not
> a good idea:
>
>
On Tue, Jun 02, 2020 at 08:41:53AM +0200, Maxime Villard wrote:
> Le 02/06/2020 ? 00:58, Andrew Doran a ?crit?:
> > Module Name:src
> > Committed By: ad
> > Date: Mon Jun 1 22:58:06 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/amd64/amd64: cpufunc.S
> >
Le 02/06/2020 à 00:58, Andrew Doran a écrit :
Module Name:src
Committed By: ad
Date: Mon Jun 1 22:58:06 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S
src/sys/arch/amd64/include: frameasm.h
Log Message:
Reported-by:
On 2020/06/02 2:08, Joerg Sonnenberger wrote:
On Sun, May 31, 2020 at 11:24:20PM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sun May 31 23:24:20 UTC 2020
Modified Files:
src/sys/kern: kern_timeout.c
Log Message:
Stop allocating buffers dynamically
On Sun, May 31, 2020 at 11:24:20PM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sun May 31 23:24:20 UTC 2020
>
> Modified Files:
> src/sys/kern: kern_timeout.c
>
> Log Message:
> Stop allocating buffers dynamically in a DDB session, in order not to
>
Le 01/06/2020 à 03:23, Shoichi Yamaguchi a écrit :
Hi,
On Wed, May 27, 2020 at 8:47 PM Shoichi Yamaguchi wrote:
I modified virtio(4) not to allocate unused memory.
I guess it fixes the issue.
Could you check this?
I confirmed your closing the report on syzbot.
Hi,
On Wed, May 27, 2020 at 8:47 PM Shoichi Yamaguchi wrote:
>
> I modified virtio(4) not to allocate unused memory.
> I guess it fixes the issue.
>
> Could you check this?
I confirmed your closing the report on syzbot.
On 2020/06/01 9:36, Kamil Rytarowski wrote:
If you can find a use-case today in DDB for an exclusive allocator. I
have it ready and tested.
I intended to use it in ddb for one project, but that project is still
unfinished.
Good to know! I will ask you when I want it!
Thanks,
rin
On 01.06.2020 02:31, Rin Okuyama wrote:
> On 2020/06/01 9:23, Kamil Rytarowski wrote:
>> I wrote a tiny malloc (libc-style) implementation over a small static
>> storage (could be over stack or preallocated on the heap) without any
>> external dependencies.
>>
>> Would it be useful for you?
>
>
On 2020/06/01 9:23, Kamil Rytarowski wrote:
I wrote a tiny malloc (libc-style) implementation over a small static
storage (could be over stack or preallocated on the heap) without any
external dependencies.
Would it be useful for you?
At the moment, we need buffers only in db_show_callout(),
I wrote a tiny malloc (libc-style) implementation over a small static
storage (could be over stack or preallocated on the heap) without any
external dependencies.
Would it be useful for you?
On 01.06.2020 01:34, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sun May
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Sun May 31 08:33:48 UTC 2020
>
> Modified Files:
> src/sys/kern: kern_timeout.c
>
> Log Message:
> db_show_callout(): struct callout_cpu and cpu_info are too much for stack.
>
> XXX
> DDB can be running in the
> On May 31, 2020, at 1:33 AM, Rin Okuyama wrote:
>
> db_show_callout(): struct callout_cpu and cpu_info are too much for stack.
>
> XXX
> DDB can be running in the interrupt context, e.g., when activated from
> console. Therefore, use kmem_intr_alloc(9) instead of kmem_alloc(9).
>
> Frame
Jaromir Dolecek wrote:
> Index: src/sys/dev/ic/bwfmvar.h
> diff -u src/sys/dev/ic/bwfmvar.h:1.9 src/sys/dev/ic/bwfmvar.h:1.10
> --- src/sys/dev/ic/bwfmvar.h:1.9 Sat May 30 13:41:58 2020
> +++ src/sys/dev/ic/bwfmvar.h Sat May 30 15:55:47 2020
> @@ -1,4 +1,4 @@
> -/* $NetBSD: bwfmvar.h,v 1.9
On Sat, May 30, 2020 at 09:48:36PM +0900, Tetsuya Isaki wrote:
> I will do it on next weekend.
>
> Thanks,
> ---
> Tetsuya Isaki
Thank you.
At Fri, 29 May 2020 12:32:39 +,
nia wrote:
> OK... Can you request a pullup to ensure resuming with a stream
> playing doesn't panic on 9.1?
I will do it on next weekend.
Thanks,
---
Tetsuya Isaki
OK... Can you request a pullup to ensure resuming with a stream
playing doesn't panic on 9.1?
Playing audio is very distorted on resume, but that can be resolved
by killing the streams...
Le 28/05/2020 à 23:58, Andrew Doran a écrit :
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
At Wed, 27 May 2020 13:19:22 +,
nia wrote:
> 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 opened for recording for the
> first time after system
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
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
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
> 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
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
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=12084ef610
>
> [ 153.4370851] panic: MSan:
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=12084ef610
[ 153.4370851] panic: MSan: Uninitialized Kmem Memory From
virtio_pci_setup_interrupts()
[
>> 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
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:
> 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
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:
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
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
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
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
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
>
>
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
> >
"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
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:
> >
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
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.
501 - 600 of 5582 matches
Mail list logo
