In article <20221128024658.71caaf...@cvs.netbsd.org>,
Jan Schaumann wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: jschauma
>Date: Mon Nov 28 02:46:58 UTC 2022
>
>Modified Files:
> src/etc: protocols
>
>Log Message:
>regen from IANA 2022-09-28
>
>
>To generate a diff of
Taylor R Campbell writes:
[snip]
> The issue here isn't the duration of the delay -- just the mechanism.
> Sleeping for 35ms with kpause(9) is fine, but busy-waiting on the CPU
> for 35ms with delay(9) is not (unless HZ is set to something absurdly
> low like 10 instead of the usual 100, but I
> Date: Wed, 23 Nov 2022 01:42:13 -0500
> From: Brad Spencer
>
> Simon Burge writes:
>
> > + delay(35000);
> >
> > This will spin for 35 milliseconds (per sensor read if I read this
> > correctly). Can you please look at using kpause(9) for this delay?
> > See some other i2c drivers for
Simon Burge writes:
> Hi Brad,
>
>> Module Name: src
>> Committed By:brad
>> Date:Tue Nov 22 19:40:31 UTC 2022
>>
>> Modified Files:
>>
>> src/sys/dev/i2c: bmx280.c
>>
>> Log Message:
>>
>> Read the datasheet more closely and put in some delays. The chip will
>>
Hi Brad,
> Module Name: src
> Committed By: brad
> Date: Tue Nov 22 19:40:31 UTC 2022
>
> Modified Files:
>
> src/sys/dev/i2c: bmx280.c
>
> Log Message:
>
> Read the datasheet more closely and put in some delays. The chip will
> just return junk if the wait is not long enough to
On 15/11/2022 05:35, Ryo Shimizu wrote:
Since l2_sha continues to point outside of m_data manipulated by m_adj(),
it can be corrupted by subsequent m_pullup() or other mbuf m_*() operations.
I still believe that using MTAG is appropriate.
How about something like this? (not tested)
Wow, that
Hello,
On Tue, 15 Nov 2022 10:29:56 +
"Michael Lorenz" wrote:
> Module Name: src
> Committed By: macallan
> Date: Tue Nov 15 10:29:56 UTC 2022
>
> Modified Files:
> src/sys/kern: subr_pserialize.c
>
> Log Message:
> don't KASSERT(kpreempt_disabled()) while cold
>
>> > > This clearly is a layering/abstraction violation and would have been
>> > > good to discuss upfront.
>> > >
>> > > Where do you make use of that information? What about other packet
>> > > injection
>> > > paths?
>> >
>> > The next commit uses it in if_arp to ensure that the DaD probe
On Tue, Nov 15, 2022 at 11:29 AM Ryota Ozaki wrote:
>
> On Mon, Nov 14, 2022 at 8:52 PM Roy Marples wrote:
> >
> > On 14/11/2022 11:04, Martin Husemann wrote:
> > > This clearly is a layering/abstraction violation and would have been
> > > good to discuss upfront.
> > >
> > > Where do you make
On Mon, Nov 14, 2022 at 8:52 PM Roy Marples wrote:
>
> On 14/11/2022 11:04, Martin Husemann wrote:
> > This clearly is a layering/abstraction violation and would have been
> > good to discuss upfront.
> >
> > Where do you make use of that information? What about other packet injection
> > paths?
Hi,
Thank you for your updating.
Thanks,
On 2022/11/14 19:15, Roy Marples wrote:
On 14/11/2022 09:49, Kengo NAKAHARA wrote:
Hi,
Please update the size in comment, when struct pkthdr is changed.
https://github.com/NetBSD/src/blob/trunk/sys/sys/mbuf.h#L181
Thanks,
Done, thanks.
Roy
On 14/11/2022 11:04, Martin Husemann wrote:
This clearly is a layering/abstraction violation and would have been
good to discuss upfront.
Where do you make use of that information? What about other packet injection
paths?
The next commit uses it in if_arp to ensure that the DaD probe sending
On Mon, Nov 14, 2022 at 12:04:20PM +0100, Martin Husemann wrote:
> On Mon, Nov 14, 2022 at 10:15:33AM +, Roy Marples wrote:
> > On 14/11/2022 09:49, Kengo NAKAHARA wrote:
> > > Hi,
> > >
> > > Please update the size in comment, when struct pkthdr is changed.
> > >
On Mon, Nov 14, 2022 at 10:15:33AM +, Roy Marples wrote:
> On 14/11/2022 09:49, Kengo NAKAHARA wrote:
> > Hi,
> >
> > Please update the size in comment, when struct pkthdr is changed.
> > https://github.com/NetBSD/src/blob/trunk/sys/sys/mbuf.h#L181
> >
> >
> > Thanks,
>
> Done,
On 14/11/2022 09:49, Kengo NAKAHARA wrote:
Hi,
Please update the size in comment, when struct pkthdr is changed.
https://github.com/NetBSD/src/blob/trunk/sys/sys/mbuf.h#L181
Thanks,
Done, thanks.
Roy
Hi,
Please update the size in comment, when struct pkthdr is changed.
https://github.com/NetBSD/src/blob/trunk/sys/sys/mbuf.h#L181
Thanks,
On 2022/11/14 18:23, Roy Marples wrote:
Module Name:src
Committed By: roy
Date: Mon Nov 14 09:23:42 UTC 2022
Modified Files:
>I think this is a bug in your device tree because the KASSERT was
>intentional:
>
> - In the ACPI case, we probe for CPU PMU support before calling
>armv8_pmu_init.
> - In the FDT case, the PMU attaches to a node described in the device
>tree.
>
>So if you hit this KASSERT, AFAICT it
I think this is a bug in your device tree because the KASSERT was
intentional:
- In the ACPI case, we probe for CPU PMU support before calling
armv8_pmu_init.
- In the FDT case, the PMU attaches to a node described in the device
tree.
So if you hit this KASSERT, AFAICT it means your
> Modified Files:
> src/sys/external/bsd/drm2/pci: drm_pci.c
>
> Log Message:
> drm(4): Mark PCI interrupt handlers as MP-safe.
i tested this recently and on one of nvidia or radeon
it wasn't working for me. i can confirm again next
weekend...
.mrg.
Module Name:src
Committed By: andvar
Date: Wed Oct 26 21:56:19 UTC 2022
Modified Files:
src/sys/dev/spi: spiflash.c
src/usr.sbin/makefs: README
src/usr.sbin/makemandb: makemandb.c
Log Message:
fix various typos in comments and makefs README file.
[...]
---
Date:Wed, 26 Oct 2022 10:42:15 -0400
From:Jan Schaumann
Message-ID:
| New proposal:
That looks better (it needs some minor wording changes,
there are too many indefinite articles ('a') which aren't
needed, and there midnight should be just that, no hyphen
or
Robert Elz wrote:
> Date:Sun, 23 Oct 2022 13:53:01 -0400
> From:Jan Schaumann
> Message-ID:
>
> | Hmm, maybe something like this?
>
> I think there is still too much there, you don't have
> to explain everything (or almost anything), but it is
> in the right
Hi,
matthew green writes:
>> With this change, ldd /lib/libc.so.12.220 fails under NetBSD/amd64 9.99.101.
>>
>>
>> /lib/libc.so.12.220:
>> ldd: /lib/libc.so.12.220: invalid ELF class 2, expected 1
>>
>> It seems that elf32_ldd() fails.
>>
>> Builds of some pkgsrc packages that use gobject
On 2022/10/25 14:55, Masanobu SAITOH wrote:
>
>
> On 2022/10/25 14:51, matthew green wrote:
>> "SAITOH Masanobu" writes:
>>> Module Name:src
>>> Committed By: msaitoh
>>> Date: Mon Oct 24 07:45:44 UTC 2022
>>>
>>> Modified Files:
>>> src/sys/net: if_dl.h
>>>
>>>
On 2022/10/25 14:51, matthew green wrote:
> "SAITOH Masanobu" writes:
>> Module Name: src
>> Committed By:msaitoh
>> Date:Mon Oct 24 07:45:44 UTC 2022
>>
>> Modified Files:
>> src/sys/net: if_dl.h
>>
>> Log Message:
>> Increase sdl_data so that more then IFNAMSIZ
"SAITOH Masanobu" writes:
> Module Name: src
> Committed By: msaitoh
> Date: Mon Oct 24 07:45:44 UTC 2022
>
> Modified Files:
> src/sys/net: if_dl.h
>
> Log Message:
> Increase sdl_data so that more then IFNAMSIZ bytes are available.
>
> - Increase the size of dl_data[] from 12 to
Taylor R Campbell wrote in
<20221023170035.2542f60...@jupiter.mumble.net>:
...
|If you use a monotonic timer to sample the POSIX clock before and
|after a leap second, the POSIX clock will appear to have taken twice
|as long as it should to pass the leap second.
Just to note that the next
Date:Sun, 23 Oct 2022 13:53:01 -0400
From:Jan Schaumann
Message-ID:
| Hmm, maybe something like this?
I think there is still too much there, you don't have
to explain everything (or almost anything), but it is
in the right direction I think.
| For example,
On Sun, Oct 23, 2022 at 11:00 AM Taylor R Campbell <
campbell+netbsd-source-change...@mumble.net> wrote:
> > Date: Sun, 23 Oct 2022 07:39:25 -0600
> > From: Warner Losh
> >
> > I guess a more accurate way of saying this is that leap seconds simply
> > aren't reliable, cannot be made reliable,
> Date: Sun, 23 Oct 2022 12:19:37 -0600
> From: Warner Losh
>
> You must have a table of all past
> leap seconds to do any kind of sensible mapping. And you also must
> have some way to keep that up to date, [...]
It's the same for all civil calendar matters
Robert Elz wrote:
> Date:Sat, 22 Oct 2022 13:42:54 -0400
> From:Jan Schaumann
> Message-ID:
>
> | A full set of examples strikes me as too much here
>
> A full set would be yes, but I think we could handle 3.
Hmm, maybe something like this?
...and will be
> Date: Sun, 23 Oct 2022 07:39:25 -0600
> From: Warner Losh
>
> I guess a more accurate way of saying this is that leap seconds simply
> aren't reliable, cannot be made reliable, and this affects normalization
> in ways too numerous to mention due to the details of the tz files, bugs
> in the
On Sat, Oct 22, 2022 at 10:55 PM Robert Elz wrote:
> Date:Sat, 22 Oct 2022 20:17:57 -0600
> From:Warner Losh
> Message-ID: <
> canczdfqhkz0xs7lf6lmjveontc5dgsonons_ug6fzsf30og...@mail.gmail.com>
>
>
> | On the other hand, adding a caveat that leap seconds don't
On Sat, Oct 22, 2022, 8:05 PM Robert Elz wrote:
> Date:Sat, 22 Oct 2022 13:42:54 -0400
> From:Jan Schaumann
> Message-ID:
>
> | A full set of examples strikes me as too much here
>
> A full set would be yes, but I think we could handle 3.
> They don't need to be
Date:Sat, 22 Oct 2022 20:17:57 -0600
From:Warner Losh
Message-ID:
| On the other hand, adding a caveat that leap seconds don't exist in a POSIX
| time_t and that's necessarily reflected in the normalization wouldn't be
| bad.
The problem with doing that is
Date:Sun, 23 Oct 2022 08:33:18 +0700
From:Robert Elz
Message-ID: <7638.1666488...@jacaranda.noi.kre.to>
| and tm_min was incremented as tm_min+=180, and then
| mktime() called upon the result, the struct tm would
| now have tm_min==1 tm_hour==24 and
Date:Sat, 22 Oct 2022 13:42:54 -0400
From:Jan Schaumann
Message-ID:
| A full set of examples strikes me as too much here
A full set would be yes, but I think we could handle 3.
They don't need to be C code examples, just something
like
if tm_year==2022
Robert Elz wrote:
> jo...@bec.de said:
> | I'd actually weasle out a bit
>
> Yes, I would too, but
A full set of examples strikes me as too much here
still, and I do like the idea of weaseling out.
Perhaps:
This normalization is done in order from tm_sec up to
tm_year, possibly leading to
Date:Fri, 21 Oct 2022 15:00:41 -0400
From:Jan Schaumann
Message-ID:
| I believe that it's useful for people to know that
| values outside the normal ranges are normalized,
Agreed.
| as well as what that might look like.
The problem with trying to specify
Am Fri, Oct 21, 2022 at 02:06:32PM +0700 schrieb Robert Elz:
> Date:Fri, 21 Oct 2022 03:05:15 +
> From:"Jan Schaumann"
> Message-ID: <20221021030515.cdc9df...@cvs.netbsd.org>
>
> | Note normalizing behavior of mktime(3) using language from FreeBSD.
>
> If we
Robert Elz wrote:
> Date:Fri, 21 Oct 2022 11:54:08 -0400
> From:Jan Schaumann
> Message-ID:
>
> | Right, but all that strikes me as too much to put into
> | the manual page here.
>
> I agree, which is why I wondered if we should be giving any
> details about
Date:Fri, 21 Oct 2022 11:54:08 -0400
From:Jan Schaumann
Message-ID:
| Right, but all that strikes me as too much to put into
| the manual page here.
I agree, which is why I wondered if we should be giving any
details about how it is done at all.
| I think
Robert Elz wrote:
> Date:Fri, 21 Oct 2022 10:36:23 -0400
> From:Jan Schaumann
> Message-ID:
>
>
> | Perhaps like this?
>
> Like that, yes, but as you wrote it isn't how it is actually
> done I believe.
>
> The order looks to be secs, mins, hours, month, day(of
Date:Fri, 21 Oct 2022 10:36:23 -0400
From:Jan Schaumann
Message-ID:
| Perhaps like this?
Like that, yes, but as you wrote it isn't how it is actually
done I believe.
The order looks to be secs, mins, hours, month, day(of month).
There's no normalisation of the
Robert Elz wrote:
> Date:Fri, 21 Oct 2022 03:05:15 +
> From:"Jan Schaumann"
> Message-ID: <20221021030515.cdc9df...@cvs.netbsd.org>
>
> | Note normalizing behavior of mktime(3) using language from FreeBSD.
>
> If we are going to start specifying what happens
Date:Fri, 21 Oct 2022 03:05:15 +
From:"Jan Schaumann"
Message-ID: <20221021030515.cdc9df...@cvs.netbsd.org>
| Note normalizing behavior of mktime(3) using language from FreeBSD.
If we are going to start specifying what happens (how the struct tm
is normalised)
> With this change, ldd /lib/libc.so.12.220 fails under NetBSD/amd64 9.99.101.
>
>
> /lib/libc.so.12.220:
> ldd: /lib/libc.so.12.220: invalid ELF class 2, expected 1
>
> It seems that elf32_ldd() fails.
>
> Builds of some pkgsrc packages that use gobject introspection and meson fails
> because
Hi,
With this change, ldd /lib/libc.so.12.220 fails under NetBSD/amd64 9.99.101.
/lib/libc.so.12.220:
ldd: /lib/libc.so.12.220: invalid ELF class 2, expected 1
It seems that elf32_ldd() fails.
Builds of some pkgsrc packages that use gobject introspection and meson fails
because they uses ldd
In article <20221011220338.17a48f...@cvs.netbsd.org>,
Andrius Varanavicius wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: andvar
>Date: Tue Oct 11 22:03:37 UTC 2022
>
>Modified Files:
> src/sys/arch/arm/arm32: bus_dma.c
> src/sys/arch/hppa/hppa: mainbus.c
>
Date:Mon, 10 Oct 2022 17:33:35 +
From:"Roland Illig"
Message-ID: <20221010173335.c3cccf...@cvs.netbsd.org>
| Document only the POSIX requirement for now, as I didn't find
| information about _which_ ancient UNIX systems would corrupt the
| filesystem on
Date:Tue, 04 Oct 2022 10:09:35 -0400
From:Christos Zoulas
Message-ID: <8dd220d16861eb3a890461bdf02d1...@zoulas.com>
| I always forget the O_CLOEXEC is special
| in that regard. I wish it was not, but it is difficult to fix.
POSIX is adding O_CLOFORK in the next
On 2022-10-01 3:39 pm, Robert Elz wrote:
Date:Sat, 1 Oct 2022 13:00:04 -0400
[stuff deleted]
Even when it is called, the code is:
fp->f_flag = flags & FMASK;
where FMASK is (from fcntl.h)
#define FMASK (FREAD|FWRITE|FCNTLFLAGS|FEXEC)
and
#define FCNTLFLAGS
On 2022/10/04 19:22, Taylor R Campbell wrote:
>> Date: Tue, 4 Oct 2022 17:16:35 +0900
>> From: Masanobu SAITOH
>>
>> Before reverting changes, one of my machine which use serial console
>> didn't print the Copyright message.
>>
>> Revert two revert commit, i.e.
>>
> Date: Tue, 4 Oct 2022 17:16:35 +0900
> From: Masanobu SAITOH
>
> Before reverting changes, one of my machine which use serial console
> didn't print the Copyright message.
>
> Revert two revert commit, i.e.
> http://mail-index.netbsd.org/source-changes/2022/10/04/msg141389.html
>
Hi.
On 2022/10/04 16:24, Ryo ONODERA wrote:
> Hi,
>
> Taylor R Campbell writes:
>
>>> Date: Tue, 04 Oct 2022 15:53:58 +0900
>>> From: Ryo ONODERA
>>>
>>> With this patch, it works fine for me.
>>> There is no stall after genfb(4).
>>> And I do not find any other problem so far.
>>
>> Thanks!
On 2022/10/04 16:38, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Tue Oct 4 07:24:32 UTC 2022
Modified Files:
src/sys/arch/amiga/dev: ser.c
src/sys/arch/sgimips/dev: scn.c
Log Message:
Remove unused extern declaration of
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Tue Oct 4 07:24:32 UTC 2022
>
> Modified Files:
> src/sys/arch/amiga/dev: ser.c
> src/sys/arch/sgimips/dev: scn.c
>
> Log Message:
> Remove unused extern declaration of constty.
thank you.
can someone
Hi,
Taylor R Campbell writes:
>> Date: Tue, 04 Oct 2022 15:53:58 +0900
>> From: Ryo ONODERA
>>
>> With this patch, it works fine for me.
>> There is no stall after genfb(4).
>> And I do not find any other problem so far.
>
> Thanks! There probably is another problem which is that kernel
>
> Date: Tue, 04 Oct 2022 15:53:58 +0900
> From: Ryo ONODERA
>
> With this patch, it works fine for me.
> There is no stall after genfb(4).
> And I do not find any other problem so far.
Thanks! There probably is another problem which is that kernel
console printfs might stop appearing after a
Hi,
Taylor R Campbell writes:
>> Date: Tue, 04 Oct 2022 12:12:15 +0900
>> From: Ryo ONODERA
>>
>> "Taylor R Campbell" writes:
>>
>> > console(4), constty(4): Rip off the kernel lock.
>>
>> After introduction of MP-safe console/constty, my kernel stopped
>> just after genfb(4) detection.
>>
> Date: Tue, 04 Oct 2022 12:12:15 +0900
> From: Ryo ONODERA
>
> "Taylor R Campbell" writes:
>
> > console(4), constty(4): Rip off the kernel lock.
>
> After introduction of MP-safe console/constty, my kernel stopped
> just after genfb(4) detection.
> LOCKDEBUG, DIAGNOSTIC, DEBUG options does
Hi,
"Taylor R Campbell" writes:
> Module Name: src
> Committed By: riastradh
> Date: Mon Oct 3 19:57:25 UTC 2022
>
> Modified Files:
> src/sys/dev: cons.c
>
> Log Message:
> console(4), constty(4): Rip off the kernel lock.
After introduction of MP-safe console/constty, my
Yes -- I suppose genfs_pathconf() is sufficient here.
--
J. Hannken-Illjes - hann...@mailbox.org
> On 3. Oct 2022, at 11:40, Frank Kardel wrote:
>
>
> Good to know. So do we need to add path conf there?
> Frank
>
> 3 Oct 2022 11:34:09 J. Hannken-Illjes :
>
>> Frank,
>>
>> the vnode
Good to know. So do we need to add path conf there?
Frank
3 Oct 2022 11:34:09 J. Hannken-Illjes :
> Frank,
>
> the vnode operations for ".zfs" are in zfs_ctldir.c and there
> is no pathconf operation here ...
>
> --
> J. Hannken-Illjes - hann...@mailbox.org
>
>> On 3. Oct 2022, at 11:26,
Frank,
the vnode operations for ".zfs" are in zfs_ctldir.c and there
is no pathconf operation here ...
--
J. Hannken-Illjes - hann...@mailbox.org
> On 3. Oct 2022, at 11:26, Frank Kardel wrote:
>
> Well, I am am happy to do that. But ls got eopnotsupp for fpathconf of ACL
> names and barked
Well, I am am happy to do that. But ls got eopnotsupp for fpathconf of ACL
names and barked at them when listing the .zfs snapshot directory. Ls is only
ignoring einval at that place. So something must be wrong there wrt tog.
Frank
3 Oct 2022 10:53:10 J. Hannken-Illjes :
>> On 27. Sep 2022, at
> On 27. Sep 2022, at 12:33, Frank Kardel wrote:
>
> Module Name: src
> Committed By: kardel
> Date: Tue Sep 27 10:33:21 UTC 2022
>
> Modified Files:
> src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c
>
> Log Message:
> for unsupported names return EINVAL as per TOG
>
Date:Sat, 1 Oct 2022 13:00:04 -0400
From:Christos Zoulas
Message-ID: <8bd3a408-77fd-402c-8d6c-ad4b4a5e8...@zoulas.com>
| This is what I meant:
|
| RCS file: /cvsroot/src/sys/kern/kern_descrip.c,v
| retrieving revision 1.251
| diff -u -u -r1.251
> On Sep 30, 2022, at 11:02 PM, Robert Elz wrote:
>
>Date:Fri, 30 Sep 2022 20:15:07 -0400
>From:Christos Zoulas
>Message-ID:
>
> | It does not need an extra flag (it looks in the file descriptor flags to
> | find if it needs to set or not.
>
> One of us is
Date:Fri, 30 Sep 2022 20:15:07 -0400
From:Christos Zoulas
Message-ID:
| It does not need an extra flag (it looks in the file descriptor flags to
| find if it needs to set or not.
One of us is confused. From where in this case does anything
get the exclose
> On Sep 30, 2022, at 5:57 PM, Robert Elz wrote:
>
>Date:Fri, 30 Sep 2022 16:34:20 -0400
>From:Christos Zoulas
>Message-ID: <232331ad-d501-4547-b730-03590c0c9...@zoulas.com>
>
> | How about handling exclose there?
>
> That would be possible, but why? We still
On Sat, 1 Oct 2022, Robert Elz wrote:
Currently fd_affix (I mistakenly made it fp_affix in the last message...)
doesn't have a flags parameter, so to do it the way you suggest, we'd need
to alter its signature, bump to 9.99.101 ...
and add some COMPAT_09 goop for backward compability :)
Date:Fri, 30 Sep 2022 16:34:20 -0400
From:Christos Zoulas
Message-ID: <232331ad-d501-4547-b730-03590c0c9...@zoulas.com>
| How about handling exclose there?
That would be possible, but why? We still need higher level code to
handle the locking, which can also
> On Sep 30, 2022, at 10:13 AM, Robert Elz wrote:
>
>Date:Thu, 29 Sep 2022 16:47:06 - (UTC)
>From:chris...@astron.com (Christos Zoulas)
>Message-ID:
>
> | I think that the way to go is to:
> |
> | 1. Do the fd_set_exclose() in fd_affix(). That will remove
Date:Thu, 29 Sep 2022 16:47:06 - (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| I think that the way to go is to:
|
| 1. Do the fd_set_exclose() in fd_affix(). That will remove most of the calls
|to fd_set_exclose() *and* the
In article <9275.1664462...@jacaranda.noi.kre.to>,
Robert Elz wrote:
>Date:Thu, 29 Sep 2022 08:18:28 -0400
>From:"Christos Zoulas"
>Message-ID: <20220929121828.06edff...@cvs.netbsd.org>
>
> | Log Message:
> | Add fd_set_exclose(). It is probably better to do this
Date:Thu, 29 Sep 2022 08:18:28 -0400
From:"Christos Zoulas"
Message-ID: <20220929121828.06edff...@cvs.netbsd.org>
| Log Message:
| Add fd_set_exclose(). It is probably better to do this automatically in
| fd_affix()...
Since that only affects /dev/ptmx I'd
Date:Thu, 29 Sep 2022 08:18:49 -0400
From:Christos Zoulas
Message-ID:
| Yes, I had forgotten about the need to do this explicitly...
| > On Sep 28, 2022, at 10:23 PM, Robert Elz wrote:
| >
| > Apologies, I did not read the code closely enough, there must
Yes, I had forgotten about the need to do this explicitly...
christos
> On Sep 28, 2022, at 10:23 PM, Robert Elz wrote:
>
> Apologies, I did not read the code closely enough, there must be a bug
> in the way the clone file descriptor is created.
>
> kre
signature.asc
Description: Message
Apologies, I did not read the code closely enough, there must be a bug
in the way the clone file descriptor is created.
kre
Date:Wed, 28 Sep 2022 20:48:53 -0400
From:"David H. Gutteridge"
Message-ID: <9c9c8e9d9384338320b47dabfdc94...@gutteridge.ca>
| (O_CLOEXEC, on the other hand, is ignored, at the moment.)
No it isn't, your test is faulty, O_CLOEXEC is a different
kind of flag,
On Wed, 28 Sep 2022, at 15:07:41 - (UTC), Christos Zoulas wrote:
In article <20220928003547.D2375FA92%cvs.NetBSD.org@localhost>,
David H. Gutteridge wrote:
-=-=-=-=-=-
Module Name:src
Committed By: gutteridge
Date: Wed Sep 28 00:35:47 UTC 2022
Modified Files:
In article <20220928163447.b0bf6f...@cvs.netbsd.org>,
Simon J. Gerraty wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: sjg
>Date: Wed Sep 28 16:34:47 UTC 2022
>
>Modified Files:
> src/usr.bin/make: main.c meta.c
>
>Log Message:
>Don't ignore return from snprintf or getcwd
> On Sep 28, 2022, at 11:37 AM, Charlotte Koch wrote:
> Maybe it makes sense to write an article in our own wiki instead? From
> what I gather, reprogramming these NVRAM/clock chips is a *very* common
> task. (In fact, I'm going to do it myself with the Sun Blade 100 that
> I'm getting
On Thu, 29 Sep 2022, Izumi Tsutsui wrote:
Modified Files:
src/distrib/notes/sparc64: prep
Log Message:
Avoid dead link to the NVRAM/Hostid FAQ
Maybe this mirror is better than archive.org:
http://www.obsolyte.com/sunFAQ/faq_nvram.html
---
Izumi Tsutsui
That link is a mirror to an
> Modified Files:
> src/distrib/notes/sparc64: prep
>
> Log Message:
> Avoid dead link to the NVRAM/Hostid FAQ
Maybe this mirror is better than archive.org:
http://www.obsolyte.com/sunFAQ/faq_nvram.html
---
Izumi Tsutsui
In article <20220928003547.d2375f...@cvs.netbsd.org>,
David H. Gutteridge wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: gutteridge
>Date: Wed Sep 28 00:35:47 UTC 2022
>
>Modified Files:
> src/lib/libc/stdlib: posix_openpt.3
>
>Log Message:
>posix_openpt.3: reflect flag
> Module Name:src
> Committed By: riastradh
> Date: Sun Sep 25 07:50:32 UTC 2022
>
> Modified Files:
> src/sys/arch/arm/ti: ti_fb.c ti_lcdc.c
>
> Log Message:
> tilcdc(4): Set is_console on the drm device, not the fb child.
>
> The drm device is represented by a
> Module Name:src
> Committed By: riastradh
> Date: Sun Sep 25 07:50:23 UTC 2022
>
> Modified Files:
> src/sys/arch/arm/sunxi: sunxi_drm.c sunxi_fb.c
>
> Log Message:
> sunxidrm: Set is_console on the drm device, not the fb child.
>
> The drm device is represented by a
Hi,
On 21/09/2022 08:56, matthew green wrote:
this asserts for me. perhaps ryo@ didn't have LOCKDEBUG?
I had LOCKDEBUG on, but not DEBUG.
https://nxr.netbsd.org/xref/src/sys/sys/systm.h#760
I see that adding options DEBUG does indeed cause a panic with
ASSERT_SLEEPABLE()...
ah! that
> >this asserts for me. perhaps ryo@ didn't have LOCKDEBUG?
>
> I had LOCKDEBUG on, but not DEBUG.
> https://nxr.netbsd.org/xref/src/sys/sys/systm.h#760
> I see that adding options DEBUG does indeed cause a panic with
> ASSERT_SLEEPABLE()...
ah! that would explain it. nick asked me to test
>> Module Name: src
>> Committed By:skrll
>> Date:Fri Sep 16 03:55:53 UTC 2022
>>
>> Modified Files:
>> src/sys/dev/pci: if_aq.c
>>
>> Log Message:
>> Some MP improvements
>>
>> - Remove use of IFF_OACTIVE
>>
>> - Remove use of if_timer and provide an MP safe
"Nick Hudson" writes:
> Module Name: src
> Committed By: skrll
> Date: Fri Sep 16 03:55:53 UTC 2022
>
> Modified Files:
> src/sys/dev/pci: if_aq.c
>
> Log Message:
> Some MP improvements
>
> - Remove use of IFF_OACTIVE
>
> - Remove use of if_timer and provide an MP safe multiqueue
Hi Taylor,
Thanks for updating NVMM! Would it be a good idea to sync our code with
DragonBSDs? AFAICS they kept the code compiling for NetBSD too. To have a
common code base?
With regards,
Reinoud
On Tue, Sep 13, 2022 at 08:10:04PM +, Taylor R Campbell wrote:
> Module Name: src
> Committed
Thanks for quick fix!
rin
On 2022/09/12 22:10, Christos Zoulas wrote:
Yup!
christos
On Sep 12, 2022, at 5:04 AM, Rin Okuyama wrote:
Hi,
On 2022/09/12 0:42, Christos Zoulas wrote:
@@ -420,11 +423,11 @@ union_statvfs(struct mount *mp, struct s
{
int error;
struct
Yup!
christos
> On Sep 12, 2022, at 5:04 AM, Rin Okuyama wrote:
>
> Hi,
>
> On 2022/09/12 0:42, Christos Zoulas wrote:
>> @@ -420,11 +423,11 @@ union_statvfs(struct mount *mp, struct s
>> {
>> int error;
>> struct union_mount *um = MOUNTTOUNIONMOUNT(mp);
>> -struct statvfs
Hi,
On 2022/09/12 0:42, Christos Zoulas wrote:
@@ -420,11 +423,11 @@ union_statvfs(struct mount *mp, struct s
{
int error;
struct union_mount *um = MOUNTTOUNIONMOUNT(mp);
- struct statvfs *sbuf = malloc(sizeof(*sbuf), M_TEMP, M_WAITOK | M_ZERO);
+ struct statvfs
On Sun, Aug 28, 2022 at 03:30:41AM -0400, Christos Zoulas wrote:
> Modified Files:
> src/distrib/sets/lists/debug: mi
>
> Log Message:
> fix sets
Bah. Sorry about that. Been too long since the last time...
--
David A. Holland
dholl...@netbsd.org
Hi,
On Sun, Aug 28, 2022 at 03:26:28PM +0300, Valery Ushakov wrote:
> On Sun, Aug 28, 2022 at 10:48:17 +, Harold Gutch wrote:
>
> > Change back various occurrences of \*[Le], \*[Ge] (less/greater equal)
> > and \*(ua (upwards arrow) to literal "<=", ">=" and "^" whenever
> > appropriate
On Sun, Aug 28, 2022 at 10:48:17 +, Harold Gutch wrote:
> Change back various occurrences of \*[Le], \*[Ge] (less/greater equal)
> and \*(ua (upwards arrow) to literal "<=", ">=" and "^" whenever
> appropriate (e.g., in code examples).
Thanks. Using your commit as a pretext (and in no way
1 - 100 of 11039 matches
Mail list logo
