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 i
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.
> > > https://github.com/NetBS
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, thanks.
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 dev
> 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 space
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 dire
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 intros
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 byt
"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 2
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 lea
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, cons
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, and
> 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 sys
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 exi
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 C
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 t
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 tm_mday==20,
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 tm_
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 ca
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 tha
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 ar
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 ho
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 wha
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 they
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 c
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
> sr
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 unli
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 v
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.
>> http://mail-index.netbsd.org/so
> 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
> http://mail-i
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 co
"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 pleas
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
> con
> 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 ce
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 n
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 kernel
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 operatio
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, Fra
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 a
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 kern_descrip
> 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 con
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 flag
> 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 hand
> 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 m
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 open-coded
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 a
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 sugg
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 b
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 si
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, ap
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:
src/l
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 tomorrow
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 o
> 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 c
> 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 rockchip,
> 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 ro
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 wou
> >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 sw
>> 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 multique
"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 wa
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 union_mo
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 *sbuf
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 *sb
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 (e.g.
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 in
On Sat, Aug 27, 2022 at 21:53:39 +, David A. Holland wrote:
> Log Message:
> Attach tradcpp to the build.
Thanks!
-uwe
On 22-08-24 20:39, Robert Elz wrote:
| Date:Wed, 24 Aug 2022 20:37:54 +1000
| From:Luke Mewburn
| Message-ID:
|
| | I think it would be more consistent with existing convention
| | (in both NetBSD and on other systems) to add /etc/raid.d
|
| I ce
Date:Wed, 24 Aug 2022 20:37:54 +1000
From:Luke Mewburn
Message-ID:
| I think it would be more consistent with existing convention
| (in both NetBSD and on other systems) to add /etc/raid.d
I certainly won't be doing that, I detest the ".d" convention
as a genera
On 22-07-21 07:49, Robert Elz wrote:
| Module Name:src
| Committed By: kre
| Date: Thu Jul 21 07:49:36 UTC 2022
|
| Modified Files:
| src/etc/rc.d: raidframe
|
| Log Message:
| Make this better ... Allow config file for raidN to be found
| in
On Mon, Aug 22, 2022 at 10:28:55AM -0600, Brook Milligan wrote:
> OK. Here is the current patch I intend to commit along with the following
> commit message:
Looks good!
Martin
> On Aug 22, 2022, at 8:34 AM, Martin Husemann wrote:
>
> On Mon, Aug 22, 2022 at 08:27:18AM -0600, Brook Milligan wrote:
>> INSTALLBOOT_BOARDS is constructed dynamically from installboot, so it
>> is not really part of the current user interface.
>
> I would just drop the INSTALLBOOT_BOARD
> On Aug 22, 2022, at 9:53 AM, Martin Husemann wrote:
>
> On Mon, Aug 22, 2022 at 09:23:37AM -0600, Brook Milligan wrote:
>> However, that does not help people (the NetBSD build farm?,
>> armbsd.org?) who want to release an entire collection of bootable
>> images, which I think would be a really
On Mon, Aug 22, 2022 at 09:23:37AM -0600, Brook Milligan wrote:
> However, that does not help people (the NetBSD build farm?,
> armbsd.org?) who want to release an entire collection of bootable
> images, which I think would be a really great service if anyone wishes
> to pick it up.
I am not sure
On Mon, Aug 22, 2022 at 08:27:18AM -0600, Brook Milligan wrote:
> INSTALLBOOT_BOARDS is constructed dynamically from installboot, so it
> is not really part of the current user interface.
I would just drop the INSTALLBOOT_BOARDS != part and leave it to the
user to pass a proper list via
401 - 500 of 1061 matches
Mail list logo
