On Tue, Jan 26, 2021 at 11:39:52PM +0100, Roland Illig wrote:
> The code of usr.bin/make gets distributed to a wider audience by Simon's
> bmake distribution (http://www.crufty.net/help/sjg/bmake.html), that's
> where the requirement of supporting C89 compilers comes from. At the
> time I
> On Jan 26, 2021, at 6:49 PM, Valery Ushakov wrote:
>
> It's hardly fair to characterize three people politely inquiring about
> that choice and pointing out a more standard way to spell what you
> want to express (that is perfectly in rhyme with the preceding table
> and is only one
On Wed, Jan 27, 2021 at 01:00:05 +, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Wed Jan 27 01:00:05 UTC 2021
>
> Modified Files:
> src/sys/sys: device.h
>
> Log Message:
> Define a macro to terminate the common usage of device_compatible_entry
>
On 26.01.2021 21:04, Christos Zoulas wrote:
Yes, and I did not push for it for the exact reasons stated below:
There was only a handful of cases and those can be handled with casts or a
macro for now.
I am questioning though the utility of maintaining compatibility with platforms
that
do not
Yes, and I did not push for it for the exact reasons stated below:
There was only a handful of cases and those can be handled with casts or a
macro for now.
I am questioning though the utility of maintaining compatibility with platforms
that
do not support C99 20 years later, vs. using %u and
On 26.01.2021 11:19, Rin Okuyama wrote:
Ping?
I don't think this is correct fix either.
Can you please revert this commit?
Sorry, I didn't get the first mail from Christos back in December,
that's why I didn't take any action.
Why shouldn't the fix I did be correct? I carefully checked the
On Tue, Jan 26, 2021 at 05:51:42PM +0900, Rin Okuyama wrote:
> Hi,
> This seems not correct for me. Is the attached patch OK with you?
Well you spotted a bug indeed int he freeing section. I'll fix and commit it.
Thanks for reporting.
Reinoud
signature.asc
Description: PGP signature
Ping?
I don't think this is correct fix either.
Can you please revert this commit?
Thanks,
rin
On 2020/12/15 7:57, Christos Zoulas wrote:
In article <20201213212746.3cfc3f...@cvs.netbsd.org>,
Roland Illig wrote:
-=-=-=-=-=-
Module Name:src
Committed By: rillig
Date: Sun Dec
Hi,
On 2021/01/25 0:33, Reinoud Zandijk wrote:
Module Name:src
Committed By: reinoud
Date: Sun Jan 24 15:33:02 UTC 2021
Modified Files:
src/sys/dev/pci: virtio_pci.c
Log Message:
On error unmap the pci_mapreg_map()d regions using bus_space_unmap() as
suggested by jak@
> On Jan 25, 2021, at 9:45 AM, Robert Elz wrote:
>
>Date:Mon, 25 Jan 2021 08:19:44 -0800
>From:Jason Thorpe
>Message-ID:
>
> | Using { 0 } makes an assumption about the first member of the
> | structure which is not guaranteed to remain true.
>
> That's
On 25.01.2021 17:19, Jason Thorpe wrote:
>
>> On Jan 25, 2021, at 6:22 AM, Kamil Rytarowski wrote:
>>
>> I have no problem with this change but I am curious why should we use "{
>> }"? It's a C GNU extension and C++ syntax.
>
> Using { 0 } makes an assumption about the first member of the
On Mon, Jan 25, 2021 at 20:28:52 +0300, Valery Ushakov wrote:
> On Mon, Jan 25, 2021 at 08:19:44 -0800, Jason Thorpe wrote:
>
> > > On Jan 25, 2021, at 6:22 AM, Kamil Rytarowski wrote:
> > >
> > > I have no problem with this change but I am curious why should we use "{
> > > }"? It's a C GNU
Date:Mon, 25 Jan 2021 08:19:44 -0800
From:Jason Thorpe
Message-ID:
| Using { 0 } makes an assumption about the first member of the
| structure which is not guaranteed to remain true.
That's right, but you could explicitly init a named field, most likely
the one
On Mon, Jan 25, 2021 at 08:19:44 -0800, Jason Thorpe wrote:
> > On Jan 25, 2021, at 6:22 AM, Kamil Rytarowski wrote:
> >
> > I have no problem with this change but I am curious why should we use "{
> > }"? It's a C GNU extension and C++ syntax.
>
> Using { 0 } makes an assumption about the
> On Jan 25, 2021, at 6:22 AM, Kamil Rytarowski wrote:
>
> I have no problem with this change but I am curious why should we use "{
> }"? It's a C GNU extension and C++ syntax.
Using { 0 } makes an assumption about the first member of the structure which
is not guaranteed to remain true.
--
On 25.01.2021 15:20, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Mon Jan 25 14:20:39 UTC 2021
>
> Modified Files:
> src/sys/arch/arm/altera: cycv_clkmgr.c
> src/sys/arch/arm/amlogic: meson_pinctrl.c meson_pwm.c meson_thermal.c
>
> On Jan 24, 2021, at 10:20 PM, Martin Husemann wrote:
>
>> I kept getting a ?static after non-static declaration? error when building
>> for aarch64.
>
> I guess that was with outdated arm/include/bus_funcs.h and
> sys/bus_proto.h (or where was the previous declaration)?
I did a “cvs
On Sun, Jan 24, 2021 at 09:45:14PM -0800, Jason Thorpe wrote:
>
> > On Jan 24, 2021, at 9:37 PM, Martin Husemann wrote:
> >
> > While I don't care for names, I would like to understand fallout in
> > details before hiding it - what exactly did not compile correctly?
> > At least the affected
> On Jan 24, 2021, at 9:37 PM, Martin Husemann wrote:
>
> While I don't care for names, I would like to understand fallout in
> details before hiding it - what exactly did not compile correctly?
> At least the affected arm kernels worked for me in the state directly
> before your commit.
I
On Sun, Jan 24, 2021 at 03:34:08PM +, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Sun Jan 24 15:34:08 UTC 2021
>
> Modified Files:
> src/sys/dev/pci: virtio_pci.c
>
> Log Message:
> Redefining bus_space functions in drivers is a bad idea, and we
> On Jan 23, 2021, at 5:40 PM, Christos Zoulas wrote:
>
>> it's a bad example. someone might copy it into another
>> driver that _doesn't_ work with this version, but may seem
>> to fix a build error.
>>
>> that's why i wanted to wrap the usage to make it clear if
>> someone were to copy it
In article <17141.1611452...@splode.eterna.com.au>,
matthew green wrote:
>Christos Zoulas writes:
>> In article <20210123230600.52be160...@jupiter.mumble.net>,
>> Taylor R Campbell wrote:
>> >
>> >Conversely, how do you know whether this hacked-up implementation
>> >which tears the write into
Christos Zoulas writes:
> In article <20210123230600.52be160...@jupiter.mumble.net>,
> Taylor R Campbell wrote:
> >
> >Conversely, how do you know whether this hacked-up implementation
> >which tears the write into two will actually work? Maybe it works for
> >virtio but there are likely other
In article <20210123230600.52be160...@jupiter.mumble.net>,
Taylor R Campbell wrote:
>
>Conversely, how do you know whether this hacked-up implementation
>which tears the write into two will actually work? Maybe it works for
>virtio but there are likely other devices out there for which it will
> Date: Sat, 23 Jan 2021 22:59:22 - (UTC)
> From: chris...@astron.com (Christos Zoulas)
>
> In article <23974.1611441...@splode.eterna.com.au>,
> matthew green wrote:
> >this seems dangerous to me. we don't define it on
> >some platforms because we can't, so having it faked
> >out here
In article <23974.1611441...@splode.eterna.com.au>,
matthew green wrote:
>"Christos Zoulas" writes:
>> Module Name: src
>> Committed By:christos
>> Date:Sat Jan 23 20:00:19 UTC 2021
>>
>> Modified Files:
>> src/sys/dev/pci: virtio_pci.c
>>
>> Log Message:
>> Provide
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sat Jan 23 20:00:19 UTC 2021
>
> Modified Files:
> src/sys/dev/pci: virtio_pci.c
>
> Log Message:
> Provide a generic bus_space_write_8 function that is bi-endian.
this seems dangerous to me. we don't
In article ,
Reinoud Zandijk wrote:
>On Fri, Jan 22, 2021 at 04:54:51PM +1100, matthew green wrote:
>> > +#ifndef _LP64
>>
>> _LP64 is a terrible way to make this choice.
>>
>> heaps of our 32 bit platforms implement the _8 variants.
>
>Can't we then just make sure they have the 8 bit variant?
In article ,
Nick Hudson wrote:
>On 22/01/2021 04:48, Christos Zoulas wrote:
>> +#if _QUAD_HIGHWORD
>> +bus_space_write_4(iot, ioh, offset, (uint32_t)(value & 0x));
>> +bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value >> 32));
>> +#else
>> +bus_space_write_4(iot, ioh,
On Fri, 22 Jan 2021, Paul Goyette wrote:
On Thu, 21 Jan 2021, Paul Goyette wrote:
Ooopppsss ignore me - looks like this was already fixed and my update
missed it.
I'll retry.
OK, I built and installed a new kernel+userland.
Most everything works, and syslogd seems to work fine (at least,
On Thu, 21 Jan 2021, Paul Goyette wrote:
Ooopppsss ignore me - looks like this was already fixed and my update
missed it.
I'll retry.
OK, I built and installed a new kernel+userland.
Most everything works, and syslogd seems to work fine (at least, it
no longer panics during startup).
On Fri, Jan 22, 2021 at 04:54:51PM +1100, matthew green wrote:
> > +#ifndef _LP64
>
> _LP64 is a terrible way to make this choice.
>
> heaps of our 32 bit platforms implement the _8 variants.
Can't we then just make sure they have the 8 bit variant? and set a define if
its atomic or not?
This
I forgot that I added dma-ranges support back in Feb last year. All good,
please ignore me :)
On Thu, 21 Jan 2021, Jared McNeill wrote:
This driver is not 64-bit safe and should not be enabled on aarch64 as-is. I
think before turning it on we should restrict it to the lower 1GB of memory
On 22/01/2021 04:48, Christos Zoulas wrote:
+#if _QUAD_HIGHWORD
+ bus_space_write_4(iot, ioh, offset, (uint32_t)(value & 0x));
+ bus_space_write_4(iot, ioh, offset + 4, (uint32_t)(value >> 32));
+#else
+ bus_space_write_4(iot, ioh, offset, (uint32_t)(value >> 32));
+
In article <27744.1611294...@splode.eterna.com.au>,
matthew green wrote:
>> +#ifndef _LP64
>
>_LP64 is a terrible way to make this choice.
>
>heaps of our 32 bit platforms implement the _8 variants.
Let's add a _HAVE_ variable then?
christos
> +#ifndef _LP64
_LP64 is a terrible way to make this choice.
heaps of our 32 bit platforms implement the _8 variants.
.mrg.
In article <20210121204833.9ebcff...@cvs.netbsd.org>,
Reinoud Zandijk wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: reinoud
>Date: Thu Jan 21 20:48:33 UTC 2021
>
>Modified Files:
> src/sys/dev/pci: virtio_pci.c
>
>Log Message:
>Remove dependency on bus_space_write_8()
Ooopppsss ignore me - looks like this was already fixed and my update
missed it.
I'll retry.
On Thu, 21 Jan 2021, Paul Goyette wrote:
This change seems to break everything! As soon as I try to start
syslogd I hit the panic() that you added
[ 28.0253983] panic: kqueue_scan,1491:
This change seems to break everything! As soon as I try to start
syslogd I hit the panic() that you added
[ 28.0253983] panic: kqueue_scan,1491: kq=0xdc13890bc4c0 kq->kq_count(1)
!= count(0), nmarker=1
[ 28.0253983] cpu0: Begin traceback...
[ 28.0253983] vpanic() at
This driver is not 64-bit safe and should not be enabled on aarch64 as-is.
I think before turning it on we should restrict it to the lower 1GB of
memory like the Pi3 models where we know it at least has a chance of
working. You can do this easily by creating a restrictive tag using
I believe it's this change that's made my vbox image panic at the drop of
a hat; while it occasionally panics before it even hits single user, it
also consistently panics when starting syslogd (even from single-user):
panic: kqueue_scan,1491: kq=0xc779aeff6dc0 kq->kq_count(1) != count(0),
> On Jan 21, 2021, at 12:00 AM, Martin Husemann
> wrote:
>
> On Wed, Jan 20, 2021 at 07:46:48PM +, Reinoud Zandijk wrote:
>> Module Name: src
>> Committed By:reinoud
>> Date:Wed Jan 20 19:46:48 UTC 2021
>>
> [..]
>> Log Message:
>> Add VirtIO PCI v1.0 attachments
On Wed, Jan 20, 2021 at 07:46:48PM +, Reinoud Zandijk wrote:
> Module Name: src
> Committed By: reinoud
> Date: Wed Jan 20 19:46:48 UTC 2021
>
[..]
> Log Message:
> Add VirtIO PCI v1.0 attachments and fix the drivers affected.
>
> * virtio on sparc64 attaches but is it not
"Nia Alarie" writes:
> Module Name: src
> Committed By: nia
> Date: Wed Jan 20 13:22:08 UTC 2021
>
> Modified Files:
> src/sys/arch/amd64/conf: GENERIC MODULAR XEN3_DOM0 XEN3_DOMU
> src/sys/arch/evbarm/conf: OPENBLOCKS_AX3
> src/sys/arch/i386/conf: GENERIC MODULAR
On Tue, Jan 19, 2021 at 07:19:51PM +0100, Martin Husemann wrote:
> On Tue, Jan 19, 2021 at 12:35:10AM +, Jason R Thorpe wrote:
> > Module Name:src
> > Committed By: thorpej
> > Date: Tue Jan 19 00:35:10 UTC 2021
> >
> > Modified Files:
> >
On Tue, Jan 19, 2021 at 12:35:10AM +, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Tue Jan 19 00:35:10 UTC 2021
>
> Modified Files:
> src/sys/arch/arm/sunxi: sunxi_sramc.c
>
> Log Message:
> Use device_compatible_entry / of_search_compatible()
> Log Message:
> Fix build as crash(8); Protect db_md_meminfo_cmd() by defined(_KERNEL).
thanks. surprised i never saw this as the change was in a
tree for a few weeks, but i guess i was mostly doing kernels
in that tree not full builds..
.mrg.
On 2021/01/18 14:49, Rin Okuyama wrote:
(2) However, in clock.c rev 1.31 and prior, curcpu->ci_idepth was not
raised before calling {hard,stat}clock(). Therefore, cpu_intr_p()
wrongly returns false. As a result, callee functions misunderstood
that they are not running in the
On 2021/01/18 13:35, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon Jan 18 04:35:05 UTC 2021
Modified Files:
src/sys/arch/powerpc/ibm4xx: clock.c
Log Message:
Invoke hardclock() and statclock() in the interrupt context.
Otherwise, entropy_enter() is
Hi Simon
On 17/01/2021 11:26, Simon Burge wrote:
On 15/01/2021 07:15, matthew green wrote:
Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD
and is the same struct on all BSD. While bringing the same functionality to
IPv4, I elected to keep the same struct just to
The change isn't wrong, but I booted the wrong kernel and it does not fix
the aarch64 issue I am seeing.
On Sun, 17 Jan 2021, Jared D. McNeill wrote:
Module Name:src
Committed By: jmcneill
Date: Sun Jan 17 15:13:15 UTC 2021
Modified Files:
src/sys/dev/wscons:
Hi Roy,
Roy Marples wrote:
> On 15/01/2021 07:15, matthew green wrote:
> >> Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD
> >> and is the same struct on all BSD. While bringing the same functionality to
> >> IPv4, I elected to keep the same struct just to have the
> Note that `entropy' is not an `rcvar' the way upsdriver is (if your
ah! i missed this, and wasn't really even thinking about
more than foo and foo_flags. thanks!
.mrg.
"Jason R Thorpe" writes:
> Module Name: src
> Committed By: thorpej
> Date: Sat Jan 16 01:23:04 UTC 2021
>
> Modified Files:
> src/sys/dev/acpi: tpm_acpi.c
>
> Log Message:
> Match PNP0C31 as a TPM 1.2 device. Works on my ThinkPad X260, and
> eliminates the last of the devices that
On Sat, Jan 16, 2021 at 14:46:46 +1100, matthew green wrote:
> > Log Message:
> > Tweak wording for consistency: `if empty or not set', not `if unset'.
>
> is this correct?
>
> rc complains if unset or not set (ie, if "$foo" is zero length):
>
> /etc/rc.d/upsdriver: WARNING: $upsdriver is not
> Date: Sat, 16 Jan 2021 14:46:46 +1100
> from: matthew green
>
> > Log Message:
> > Tweak wording for consistency: `if empty or not set', not `if unset'.
>
> is this correct?
>
> rc complains if unset or not set (ie, if "$foo" is zero length):
>
> /etc/rc.d/upsdriver: WARNING: $upsdriver is
> Log Message:
> Tweak wording for consistency: `if empty or not set', not `if unset'.
is this correct?
rc complains if unset or not set (ie, if "$foo" is zero length):
/etc/rc.d/upsdriver: WARNING: $upsdriver is not set properly - see rc.conf(5).
.mrg.
On 15/01/2021 02:43, Simon Burge wrote:
I'll test a bit more
I can't actually test as my ERLite won't boot anymore.
Console light is green, cu says I'm connected but I get nothing out of it.
With cat5 cables plugged in the ports they flash green and then stick on amber.
I'm guessing this is
On 15/01/2021 07:15, matthew green wrote:
Oh, I quite agree. However, in6_nbrinfo predates my involvement with NetBSD
and is the same struct on all BSD. While bringing the same functionality to
IPv4, I elected to keep the same struct just to have the same API, warts
and all. I like consistency.
> Oh, I quite agree.
> However, in6_nbrinfo predates my involvement with NetBSD and is the same
> struct
> on all BSD. While bringing the same functionality to IPv4, I elected to keep
> the
> same struct just to have the same API, warts and all. I like consistency.
[ .. ]
>
> That breaks
On 15/01/2021 02:43, Simon Burge wrote:
Hi Roy,
Roy Marples wrote:
On 14/01/2021 11:03, Simon Burge wrote:
Sure, I will have a look. Anything IPv6 related I might need a helping
hand to get a test case though :).
As they share a similar structure, you solve one you likely solve the other.
Hi Roy,
Roy Marples wrote:
> On 14/01/2021 11:03, Simon Burge wrote:
> > Sure, I will have a look. Anything IPv6 related I might need a helping
> > hand to get a test case though :).
>
> As they share a similar structure, you solve one you likely solve the other.
> I can assume you have working
On 14/01/2021 11:03, Simon Burge wrote:
Sure, I will have a look. Anything IPv6 related I might need a helping
hand to get a test case though :).
As they share a similar structure, you solve one you likely solve the other.
I can assume you have working IPv4 ;)
Roy
Module Name:src
Committed By: pgoyette
Date: Thu Jan 14 19:07:03 UTC 2021
Modified Files:
src/distrib/sets/lists/debug: mi
Log Message:
/home/paul/XXX.txt
Crap - meant to include the text file... Here's the good log info...
Update sets lists to accomodate
Roy Marples wrote:
> On 14/01/2021 08:00, Simon Burge wrote:
> > Module Name:src
> > Committed By: simonb
> > Date: Thu Jan 14 08:00:45 UTC 2021
> >
> > Modified Files:
> > src/sys/compat/netbsd32: netbsd32.h netbsd32_ioctl.c netbsd32_ioctl.h
> >
> > Log Message:
On 14/01/2021 08:00, Simon Burge wrote:
Module Name:src
Committed By: simonb
Date: Thu Jan 14 08:00:45 UTC 2021
Modified Files:
src/sys/compat/netbsd32: netbsd32.h netbsd32_ioctl.c netbsd32_ioctl.h
Log Message:
Handle FSSIOCSET and FSSIOCGET; vndconfig(8) works with
On 09.01.2021 17:42, Martin Husemann wrote:
On Sat, Jan 09, 2021 at 05:15:12PM +0100, Roland Illig wrote:
I guess a simple "make clean && make" will clear up the situation.
Not quite, "make clean" will not remove the old ops.c file in the objdir,
you need to manually kill it (or just remove
On Sat, Jan 09, 2021 at 05:15:12PM +0100, Roland Illig wrote:
> I guess a simple "make clean && make" will clear up the situation.
Not quite, "make clean" will not remove the old ops.c file in the objdir,
you need to manually kill it (or just remove all lint objdirs completely).
Please add an
On 09.01.2021 12:42, Jared McNeill wrote:
Not sure if it is this exact change, but I am no longer able to build
tools on Ubuntu 20.04.1:
--- lint1 ---
# link lint1/lint1
/usr/bin/ld: ops.lo: in function `initmtab':
ops.c:(.text+0x63): undefined reference to `STRUCT_ASSIGN'
That's weird
Not sure if it is this exact change, but I am no longer able to build
tools on Ubuntu 20.04.1:
--- lint1 ---
# link lint1/lint1
cc -O -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-I/home/jmcneill/netbsd/cvs-src/obj/tooldir.Linux-5.8.0-34-generic-x86_64/include/compat
Hi Roy !
That looks more semantics (the ones I know of - dynamic interface
scanning is one of my NTPd parts)
preserving now.
So far I see no other issues from the pitfalls I know of.
Lets hope our kernel and other SO_RERRORS systems miss any
interface scan worthy events.
Frank
On
On 02/01/2021 23:33, Frank Kardel wrote:
Also the behavior now fully relies in the routing message functionality which
can be disabled
on serious procession errors - at that point the code robustness relies on the
periodic
re-scanning - so I am not sure whether the periodic re-scanning
On 02/01/2021 23:33, Frank Kardel wrote:
Hi Roy !
This may look like a better solution from the interface tracking side.
People have requested being able to disable dynamic interface updates
completely.
This was implemented via the -U 0.
...
This patch seems (by visual inspection) to
Hi Roy !
This may look like a better solution from the interface tracking side.
People have requested being able to disable dynamic interface updates
completely.
This was implemented via the -U 0.
See man ntpd:
...
−U number, −−updateinterval=number
interval in
On 02/01/2021 17:23, Roy Marples wrote:
That's a good point, with this we can now remove that forced sync on a timer
approach.
Does this look ok?
Better patch:
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_io.c
--- a/external/bsd/ntp/dist/ntpd/ntp_io.c Sat Jan 02 12:39:33 2021
Hi Frank
On 02/01/2021 09:55, Frank Kardel wrote:
I doubt that the explicit draining is helpful here as it already happens
I was aware of that.
I was just trying to avoid excess timer interface timeouts if we don't get
around to reading the next message in UPDATE_GRACE time.
Let's see what
Hi Roy !
I doubt that the explicit draining is helpful here as it already happens
in the outer loop processing any routing socket input. All that is happening
in the routing messages processing path is to call
timer_interfacetimeout(current_time + UPDATE_GRACE) and
this is robust for
>sys/external/gpl2/dts/dist is meant for upstream dts files only. Do
>you mind moving this to sys/arch/arm/dts with the other custom dts files?
Ah, I Understood. Sorry, I didn't have a good grasp of the
sys/external/gpl2/dts/dist/arch policy.
I will move it to sys/arch/arm/dts.
Thanks!
--
Please also add the appropriate entry to src/distrib/sets/lists/debug.mi
for those of us who build with MKDEBUG=YES
:)
On Sat, 2 Jan 2021, Nathanial Sloss wrote:
Module Name:src
Committed By: nat
Date: Sat Jan 2 03:24:02 UTC 2021
Modified Files:
Date:Fri, 1 Jan 2021 20:38:36 +
From:"Roy Marples"
Message-ID: <20210101203836.2cadcf...@cvs.netbsd.org>
| Modified Files:
| src/external/bsd/unbound/lib/libunbound: Makefile
|
| Log Message:
| libunbound: Now we use libevent, don't build mini_event
Hi!
sys/external/gpl2/dts/dist is meant for upstream dts files only. Do
you mind moving this to sys/arch/arm/dts with the other custom dts files?
Thanks!
Jared
On Fri, 1 Jan 2021, Ryo Shimizu wrote:
Module Name:src
Committed By: ryo
Date: Fri Jan 1 07:41:46 UTC 2021
Oops. The change was to make sure that a devicetree node with a
"rockchip,grf" property on a device type that doesn't provide a config
struct doesn't deref a NULL ptr.
On Fri, 1 Jan 2021, Jared D. McNeill wrote:
Module Name:src
Committed By: jmcneill
Date: Fri Jan 1 11:44:41
"Roland Illig" writes:
> Module Name: src
> Committed By: rillig
> Date: Tue Dec 22 08:10:39 UTC 2020
>
> Modified Files:
> src/usr.bin/make: parse.c
i'm not sure which change did it (but before this one for sure),
but my builds crash early now (still trying to bootstrap nbmake):
In article <20201213212746.3cfc3f...@cvs.netbsd.org>,
Roland Illig wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: rillig
>Date: Sun Dec 13 21:27:46 UTC 2020
>
>Modified Files:
> src/usr.bin/make: for.c meta.c parse.c var.c
>
>Log Message:
>make(1): replace %zu with %u in
On Sun, Dec 13, 2020 at 12:04:40AM +, Roy Marples wrote:
> Module Name: src
> Committed By: roy
> Date: Sun Dec 13 00:04:40 UTC 2020
>
> Modified Files:
> src/external/gpl2/diffutils/dist/src: util.c
>
> Log Message:
> diffutils: execl requires a NULL sentinel
Strictly
On 2020/12/11 14:01, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Fri Dec 11 05:01:19 UTC 2020
Modified Files:
src/sys/dev/pci/ixgbe: ixgbe.c ixgbe_type.h
Log Message:
Don't use EIMC_OTHER bit because it's read only other than 82598.
Documents
On 10.12.2020 08:14, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Thu Dec 10 07:14:58 UTC 2020
>
> Modified Files:
> src/external/gpl3/gdb/dist/gdb: nbsd-nat.c
>
> Log Message:
> Fix arm, for which PT_STEP is defined but unimplemented.
>
> XXX
> Stop exposing
> On Dec 4, 2020, at 8:57 AM, Christos Zoulas wrote:
>
> In article <20201204004439.90c25f...@cvs.netbsd.org>,
> Jason R Thorpe wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:thorpej
>> Date:Fri Dec 4 00:44:39 UTC 2020
>>
>> Modified Files:
>>
In article <20201204004439.90c25f...@cvs.netbsd.org>,
Jason R Thorpe wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: thorpej
>Date: Fri Dec 4 00:44:39 UTC 2020
>
>Modified Files:
> src/sys/netinet: files.ipfilter
>
>Log Message:
>Build ip_sync.c with -Wno-error to avoid
On 2020-11-28, Yorick Hardy wrote:
> Module Name: src
> Committed By: yhardy
> Date: Sat Nov 28 22:53:06 UTC 2020
>
> Modified Files:
> src/external/cddl/osnet/dist/uts/common/fs/zfs: vdev_disk.c
>
> Log Message:
> Use vn_close to release the vnodes in the error handling blocks,
Excellent! Thank you so much for finding out and fixing this!
Full ATF successfully completed for Raspberry Pi 2b, which formerly
crashed due to "anon != NULL && anon->an_ref != 0" panic.
Now, ATF is running on Cubietruck and Raspberry Pi Zero W.
Thanks,
rin
On 2020/11/22 4:44, Nick Hudson
Please pull up to netbsd-8 and netbsd-9 release branches.
> On Nov 11, 2020, at 23:44, Simon Burge wrote:
>
> Module Name: src
> Committed By: simonb
> Date: Thu Nov 12 07:44:01 UTC 2020
>
> Modified Files:
> src/sys/conf: param.c
> src/sys/kern: init_main.c
>
On Sun, Nov 08, 2020 at 09:56:48PM +, Nia Alarie wrote:
> Module Name: src
> Committed By: nia
> Date: Sun Nov 8 21:56:48 UTC 2020
>
> Modified Files:
> src/external/bsd/kyua-cli: Makefile.inc
> src/external/ibm-public/postfix: Makefile.inc
>
On 2020/11/13 2:35, nia wrote:
I'll revert the commit shortly.
Thank you very much for your quick response.
I wasn't expecting such major breakage (obviously) and actually
did run a build but ran into different problems with libstdc++.
Yeah, this is why we need tests, and also listen to
On Thu, Nov 12, 2020 at 07:58:13PM +, Taylor R Campbell wrote:
> But there's a snag with heimdal.
>
> Heimdal exposes the sqlite3 library to clients via libgssapi.so which
> links against libkrb5.so which brings in libsqlite3.so. So we get nice
> situations like this:
>
> % ldd
> Date: Thu, 12 Nov 2020 11:21:43 -0800
> From: Jason Thorpe
>
> > On Nov 12, 2020, at 9:40 AM, nia wrote:
> >
> > For the record I'm just trying to fix things so that running
> > third-party software on NetBSD sucks less. If fewer third-party
> > libraries were exposed by the base system this
> On Nov 12, 2020, at 9:40 AM, nia wrote:
>
> For the record I'm just trying to fix things so that running
> third-party software on NetBSD sucks less. If fewer third-party
> libraries were exposed by the base system this wouldn't be
> necessary.
Why do we even have sqlite in the base system
On Thu, Nov 12, 2020 at 05:35:44PM +, nia wrote:
> I'll revert the commit shortly.
>
> I wasn't expecting such major breakage (obviously) and actually
> did run a build but ran into different problems with libstdc++.
For the record I'm just trying to fix things so that running
third-party
I'll revert the commit shortly.
I wasn't expecting such major breakage (obviously) and actually
did run a build but ran into different problems with libstdc++.
On 2020/11/12 23:03, Rin Okuyama wrote:
The backtrace reads:
| (gdb) bt
| #0 0xfc2961bca308 in ?? ()
| #1 0xfc2961b9ec10 in __deregister_frame_info_bases ()
| from /usr/lib/libgcc_s.so.1
| #2 0xf88425b4 in _rtld_call_function_void (obj=0xfc2962917400,
|
1 - 100 of 10532 matches
Mail list logo
