Thanks, should take remember this for the future reference.
On Wed, Mar 13, 2024 at 8:59 AM Nick Hudson wrote:
>
> Module Name:src
> Committed By: skrll
> Date: Wed Mar 13 06:59:01 UTC 2024
>
> Modified Files:
> src/sys/arch/evbmips/evbmips: interrupt.c
>
> Log Message:
>
On Thu, Jan 18, 2024 at 06:43:21 +1100, matthew green wrote:
> > Log Message:
> > macppc: enable FFS_EI in GENERIC
> >
> > I'd say it should be enabled for anything with USB.
> >
> > ok macallan
>
> yay. i think we should enable it basically everywhere that it
> is not a space issue.
I think
> Log Message:
> macppc: enable FFS_EI in GENERIC
>
> I'd say it should be enabled for anything with USB.
>
> ok macallan
yay. i think we should enable it basically everywhere that it
is not a space issue. USB is just one common way, but i can
also modify or create my own images anyway, and
> No, that definitely wasn't intentional! I've just reverted
> that. Does that need a pullup for netbsd-10 ?
Thanks for your confirmation.
I have another fix to make GENERIC boot on my 3/60
(disable more several pseudo-devices to shrink binary)
so I'll handle a pullup request with your fix.
Hi Tsutsui,
Izumi Tsutsui wrote:
> simonb@ wrote:
>
> > cvs rdiff -u -r1.187 -r1.188 src/sys/arch/sun3/conf/GENERIC
>
> >> # Veriexec
> >> # include "dev/veriexec.config"
> >> +
> >> +no obmem0 at mainbus? # XX
>
> Is this intentional!?
No, that definitely wasn't
simonb@ wrote:
> Module Name: src
> Committed By: simonb
> Date: Sun Aug 7 02:52:30 UTC 2022
>
> Modified Files:
:
> src/sys/arch/sun3/conf: DISKLESS GENERIC GENERIC3X
:
> Log Message:
> UFS/LFS dirhash:
> - Enable UFS_DIRHASH if the architecture or kernel model specific config
In article <2017973.usquhbg...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Tuesday, January 2, 2024 8:27:57 PM CET Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Tue Jan 2 19:27:57 UTC 2024
>>
>> Modified Files:
>> src/sys/sys:
Date:Tue, 2 Jan 2024 21:20:42 -0500
From:Jason Thorpe
Message-ID:
| seems safe
Safe probably, but also wrong. It looks to be there puerly
for the __BEGIN_DECLS / __END_DECLS definitions - which are
needed just beause has prototypes for lseek()
truncate() and
> On Jan 2, 2024, at 8:41 PM, Robert Elz wrote:
>
> I doubt that should really be including
> and almost certainly not , and shouldn't have prototypes
> for any functions at all.
seems safe — all of that stuff is in the implementation namespace.
-- thorpej
Date:Wed, 3 Jan 2024 03:15:39 +0300
From:Valery Ushakov
Message-ID:
| for userland uses should include stddef.h where size_t is supposed
| to come from
Unfortunately, while is defined to specify size_t it
isn't specified to include ssize_t - and many things
On Wed, Jan 03, 2024 at 01:06:57 +0100, Joerg Sonnenberger wrote:
> Date: Wed, 03 Jan 2024 01:06:57 +0100
> From: Joerg Sonnenberger
> Subject: Re: CVS commit: src/sys/sys
> To: source-changes-d@netbsd.org
>
> On Tuesday, January 2, 2024 8:27:57 PM CET Christos Zoulas wrot
On Tuesday, January 2, 2024 8:27:57 PM CET Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Tue Jan 2 19:27:57 UTC 2024
>
> Modified Files:
> src/sys/sys: rbtree.h
>
> Log Message:
> This uses size_t, so it always needs , remove ifdefs.
sys/types.h is
"Nick Hudson" writes:
> Module Name: src
> Committed By: skrll
> Date: Tue Dec 19 07:05:36 UTC 2023
>
> Modified Files:
> src/sys/dev/usb: if_axen.c
>
> Log Message:
> Add support for AX88179A. From sc.dying on current-users.
>
>
> To generate a diff of this commit:
> cvs rdiff -u
Hi,
Will check and adjust. Thanks for the tip.
On Thu, Dec 14, 2023 at 2:12 AM Valery Ushakov wrote:
>
> On Wed, Dec 13, 2023 at 23:11:35 +, Andrius Varanavicius wrote:
>
> > Module Name: src
> > Committed By: andvar
> > Date: Wed Dec 13 23:11:35 UTC 2023
> >
> > Modified Files:
>
On Wed, Dec 13, 2023 at 23:11:35 +, Andrius Varanavicius wrote:
> Module Name: src
> Committed By: andvar
> Date: Wed Dec 13 23:11:35 UTC 2023
>
> Modified Files:
> src/sys/arch/sparc64/dev: vnet.c
> src/sys/arch/sparc64/sparc64: netbsd32_machdep_13.c
>
> Log Message:
>
Thank you, I should pay attention to that.
On Wed, Oct 25, 2023 at 9:02 AM Nick Hudson wrote:
>
> Module Name:src
> Committed By: skrll
> Date: Wed Oct 25 06:02:14 UTC 2023
>
> Modified Files:
> src/sys/arch/mips/mips: kgdb_machdep.c
>
> Log Message:
> ->
>
>
> To
On 2023/10/12 14:50, SAITOH Masanobu wrote:
> Module Name: src
> Committed By: msaitoh
> Date: Thu Oct 12 05:50:56 UTC 2023
>
> Modified Files:
> src/sys/dev/pci/ixgbe: ixgbe.c
>
> Log Message:
> ixg(4): Don't print wrong error message about ixgbe_num_queues.
>
> Don't override
On 2023-10-15 17.06, Joerg Sonnenberger wrote:
On Sun, Oct 15, 2023 at 10:36:53PM +, Greg Oster wrote:
Module Name:src
Committed By: oster
Date: Sun Oct 15 22:36:53 UTC 2023
Modified Files:
src/sys/dev/pci/igc: if_igc.c
Log Message:
Fix build of the MODULAR
On Sun, Oct 15, 2023 at 10:36:53PM +, Greg Oster wrote:
> Module Name: src
> Committed By: oster
> Date: Sun Oct 15 22:36:53 UTC 2023
>
> Modified Files:
> src/sys/dev/pci/igc: if_igc.c
>
> Log Message:
> Fix build of the MODULAR kernel, which explicitly excludes vlans.
> Date: Fri, 13 Oct 2023 19:03:35 +
> From: Andrew Doran
>
> On Thu, Oct 12, 2023 at 11:55:46AM +0200, J. Hannken-Illjes wrote:
> > This is not true for RUMP. Hero you added sleepq_remove() as
> > "sleepq_unsleep(l, true)". This will unlock l_mutex without changing.
> >
> > Just poking
On Thu, Oct 12, 2023 at 11:55:46AM +0200, J. Hannken-Illjes wrote:
> > On 10. Oct 2023, at 20:58, Andrew Doran wrote:
> >
> > On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote:
> >
> >>> cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c
> >>
> >> -sleepq_unsleep(l,
> Date: Fri, 13 Oct 2023 17:52:07 +0900
> From: Rin Okuyama
>
> It would be really nice if we can find some systematical/reliable methods to
> figure out files that really depends on struct syncobj, e.g.. I tried
> ctfdump(1) to
> *.o for kernel modules, but I cannot extract information better
> Date: Tue, 10 Oct 2023 18:58:29 +
> From: Andrew Doran
>
> On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote:
>
> > > cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c
> >
> > -sleepq_unsleep(l, false);
> > +sleepq_remove(l->l_sleepq, l, true);
> > }
> >
On Thu, Oct 12, 2023 at 8:23 PM Taylor R Campbell
wrote:
>
> > Date: Thu, 12 Oct 2023 17:06:02 +0900
> > From: Rin Okuyama
> >
> > On Thu, Oct 5, 2023 at 5:39 AM Andrew Doran wrote:
> > >
> > > Module Name:src
> > > Committed By: ad
> > > Date: Wed Oct 4 20:39:35 UTC 2023
> >
> Date: Thu, 12 Oct 2023 17:06:02 +0900
> From: Rin Okuyama
>
> On Thu, Oct 5, 2023 at 5:39â¯AM Andrew Doran wrote:
> >
> > Module Name:src
> > Committed By: ad
> > Date: Wed Oct 4 20:39:35 UTC 2023
> >
> > Modified Files:
> > src/sys/kern: kern_rwlock.c
> On 10. Oct 2023, at 20:58, Andrew Doran wrote:
>
> On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote:
>
>>> cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c
>>
>> -sleepq_unsleep(l, false);
>> +sleepq_remove(l->l_sleepq, l, true);
>>}
>> }
>>
Cool! Can I send a pull up request to netbsd-10?
I've not yet observed deadlocks since this was committed,
fortunately or unfortunately, although ;)
Thanks,
rin
On Thu, Oct 5, 2023 at 5:39 AM Andrew Doran wrote:
>
> Module Name:src
> Committed By: ad
> Date: Wed Oct 4 20:39:35
On Tue, Oct 10, 2023 at 06:00:57PM +0200, J. Hannken-Illjes wrote:
> > cvs rdiff -u -r1.63 -r1.64 src/sys/kern/sys_select.c
>
> -sleepq_unsleep(l, false);
> +sleepq_remove(l->l_sleepq, l, true);
> }
>}
>mutex_spin_exit(lock);
>
> Looks like sleepq_remove() unlocks l->l_mutex
> On 8. Oct 2023, at 15:23, Andrew Doran wrote:
>
> Module Name: src
> Committed By: ad
> Date: Sun Oct 8 13:23:05 UTC 2023
>
> Modified Files:
> src/sys/kern: kern_condvar.c kern_sleepq.c kern_timeout.c
>kern_turnstile.c sys_lwp.c sys_select.c
> src/sys/rump/librump/rumpkern: sleepq.c
>
OK, it makes sense. I will revert the changes. Thanks for your explanations.
On Sun, Oct 8, 2023 at 12:49 PM matthew green wrote:
>
> > I was changing news68k specific code, thus wasn't treating them as
> > common. But I understand the point.
>
> there's a *LOT* of m68k code that is copied
> I was changing news68k specific code, thus wasn't treating them as
> common. But I understand the point.
there's a *LOT* of m68k code that is copied into all the ports
that is almost identical, and should really be shared, but it
not, and changes like can make this harder to share.
ie, while
On Sun, Oct 8, 2023 at 6:56 AM Izumi Tsutsui wrote:
>
> > In this case maybe I should remove all FPSP references (vectors.S,
> > locore.S, Makefile.news68k (MD_LIBS={FPSP})?
>
> IMO we don't have to keep strict consistencies or buildabilities of
> options but rather should consider readabilities
> In this case maybe I should remove all FPSP references (vectors.S,
> locore.S, Makefile.news68k (MD_LIBS={FPSP})?
IMO we don't have to keep strict consistencies or buildabilities of
options but rather should consider readabilities and maintainabilities.
- options FPSP in a config file is not
On Thu, Oct 05, 2023 at 12:15:23PM +0200, Martin Husemann wrote:
> On Thu, Oct 05, 2023 at 09:59:49AM +, Andrew Doran wrote:
> > Yes that makes sense and is what I plan to do after work today if nobody
> > beats me to it. MULTIPROCESSOR is long overdue removal from the MI kernel,
> > IMO.
>
On Thu, Oct 05, 2023 at 09:59:49AM +, Andrew Doran wrote:
> Yes that makes sense and is what I plan to do after work today if nobody
> beats me to it. MULTIPROCESSOR is long overdue removal from the MI kernel,
> IMO.
Hey, this is a tiny landisk kernel, do not bloat it :-)
Unfortunately it
Martin,
On Thu, Oct 05, 2023 at 11:42:03AM +0200, Martin Husemann wrote:
> On Thu, Oct 05, 2023 at 11:36:23AM +0200, Martin Husemann wrote:
> > No, I was confused by the #ifdef maze - it breaks the build for
> > non-MULTIPROCESSOR kernels only, and I am not actually sure what "use"
> > gcc sees
On Thu, Oct 05, 2023 at 11:36:23AM +0200, Martin Husemann wrote:
> No, I was confused by the #ifdef maze - it breaks the build for
> non-MULTIPROCESSOR kernels only, and I am not actually sure what "use"
> gcc sees for the "nlocks" variable at all in that case.
Scratch that too, I'll get coffee.
On Thu, Oct 05, 2023 at 11:28:49AM +0200, Martin Husemann wrote:
> This breaks the build:
>
> ../../../../kern/kern_synch.c: In function 'kpause':
> ../../../../kern/kern_synch.c:257:10: error: 'nlocks' may be used
> uninitialized in this function [-Werror=maybe-uninitialized]
> 257 | error =
On Wed, Oct 04, 2023 at 08:29:18PM +, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Wed Oct 4 20:29:18 UTC 2023
>
> Modified Files:
> src/sys/kern: kern_condvar.c kern_exec.c kern_exit.c kern_sig.c
> kern_sleepq.c kern_synch.c kern_timeout.c
In this case maybe I should remove all FPSP references (vectors.S,
locore.S, Makefile.news68k (MD_LIBS={FPSP})?
On Sun, Oct 1, 2023 at 10:08 PM Izumi Tsutsui wrote:
>
> > Module Name: src
> > Committed By: andvar
> > Date: Sun Oct 1 18:50:53 UTC 2023
> >
> > Modified Files:
> >
> Module Name: src
> Committed By: andvar
> Date: Sun Oct 1 18:50:53 UTC 2023
>
> Modified Files:
> src/sys/arch/news68k/conf: Makefile.news68k
>
> Log Message:
> include fpsp Makefile.inc in Makefile.news68k, same as other m68k ports.
>
> needed for FPSP option to build,
Hi,
Oops, I didn't notice it is not generated. Sorry for bothering you!
Thanks,
rin
On Mon, Sep 4, 2023 at 10:46 PM Andrius V wrote:
>
> Hi,
>
> Thanks for the note. I honestly wasn't aware that we have generated
> configs and will be more careful in changing them in the future to
> account
Hi,
Thanks for the note. I honestly wasn't aware that we have generated
configs and will be more careful in changing them in the future to
account that.
However, MDINSTALL config seems to be some older/legacy config, which
was not generated from GENERIC.in, I believe. I may try to transform
into
Hi,
On 2023/08/31 5:17, Andrius Varanavicius wrote:
Module Name:src
Committed By: andvar
Date: Wed Aug 30 20:17:06 UTC 2023
Modified Files:
src/sys/arch/amiga/conf: MDINSTALL
Log Message:
s/Piccalo/Piccolo/ in device description.
Some ports including amiga use
Thanks for kind words!
Apparently, we need some test to detect kernel and userland mismatch
for bpf(4) header...
I'd also like to fix problems by which ATF does not complete on ERL3.
Some CPU/memory consuming tests, e.g., lib/libc/regex/t_exhaust,
trigger watchdog.
I guess something wrong in
Module Name:src
Committed By: rin
Date: Wed Aug 23 13:21:17 UTC 2023
Modified Files:
src/sys/net: bpf.h
Log Message:
bpf: Fix SIZEOF_BPF_HDR (for LP64 userland) on mips64
It cannot fit within 18 bytes, of course ;)
As we had never provided working bpf(4) implementation
On 2023-08-25 13:30, Taylor R Campbell wrote:
> Since VOP_READDIR requires vp to be locked, I can infer that the
> handle_write caller must already hold vp locked. But that means that
> we have ifd_lock -> vnode lock in one path, and vnode lock -> ifd_lock
> in another path, which is forbidden
> Date: Fri, 25 Aug 2023 13:38:02 -0400
> From: Theodore Preduta
>
> On 2023-08-25 13:13, Taylor R Campbell wrote:
> > This can't be right, and it's a little unsettling that the problem
> > isn't caught by any automatic tests.
> >
> > As I understand it, the `ie_name' member is supposed to
On 2023-08-25 13:13, Taylor R Campbell wrote:
>> Module Name:src
>> Committed By: christos
>> Date: Wed Aug 23 19:17:59 UTC 2023
>>
>> Modified Files:
>> src/sys/compat/linux/common: linux_inotify.c
>>
>> Log Message:
>> put variable length structure at the end, so that
> Module Name:src
> Committed By: christos
> Date: Thu Aug 24 19:51:24 UTC 2023
>
> Modified Files:
> src/sys/compat/linux/common: linux_inotify.c
>
> Log Message:
> fix a locking bug (Theodore Preduta)
>
> if (needs_lock)
> vn_lock(vp, LK_SHARED
> Module Name:src
> Committed By: christos
> Date: Wed Aug 23 19:17:59 UTC 2023
>
> Modified Files:
> src/sys/compat/linux/common: linux_inotify.c
>
> Log Message:
> put variable length structure at the end, so that clang does not complain.
>
> struct inotify_entry {
>
Yes, I committed it (I had the change in my tree).
Best,
christos
> On Aug 21, 2023, at 3:40 PM, Ryo ONODERA wrote:
>
> Hi,
>
> "Christos Zoulas" writes:
>
>> Module Name: src
>> Committed By:christos
>> Date:Sun Aug 20 18:08:57 UTC 2023
>>
>> Modified Files:
>>
Hi,
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Sun Aug 20 18:08:57 UTC 2023
>
> Modified Files:
> src/sys/compat/linux: files.linux
>
> Log Message:
> add inotify (forgot to commit this)
>
>
> To generate a diff of this commit:
> cvs rdiff -u
> Date: Thu, 10 Aug 2023 17:42:35 +0900
> From: Kengo NAKAHARA
>
> Could you tell me how you test this fix for future reference?
I asked skrll@ to boot a VM with vmxnet3 and hammer on it with a
combination of:
1. dhcp
2. host$ nc -l 54321 /dev/null
guest$ nc host 54321 /dev/null
3. for i in
Hi,
On 2023/08/10 18:07, Nick Hudson wrote:
On 10/08/2023 09:42, Kengo NAKAHARA wrote:
Hi,
Could you tell me how you test this fix for future reference?
He didn't - I did. :)
Taylor suggested running with network traffic and doing ifconfig
down/up. To generate network traffic Taylor
On 10/08/2023 09:42, Kengo NAKAHARA wrote:
Hi,
Could you tell me how you test this fix for future reference?
He didn't - I did. :)
Taylor suggested running with network traffic and doing ifconfig
down/up. To generate network traffic Taylor suggested
host$ nc -l 54321 /dev/null
guest$ nc
Hi,
Could you tell me how you test this fix for future reference?
Thanks,
On 2023/08/10 17:24, Taylor R Campbell wrote:
Module Name:src
Committed By: riastradh
Date: Thu Aug 10 08:24:45 UTC 2023
Modified Files:
src/sys/dev/pci: if_vmx.c
Log Message:
vmxnet(4): Fix
On Tue, Aug 08, 2023 at 04:01:19PM +1000, matthew green wrote:
> Joerg Sonnenberger writes:
> > On Thu, Aug 03, 2023 at 08:16:31AM +, matthew green wrote:
> > > Module Name: src
> > > Committed By: mrg
> > > Date: Thu Aug 3 08:16:31 UTC 2023
> > >
> > > Modified Files:
>
Joerg Sonnenberger writes:
> On Thu, Aug 03, 2023 at 08:16:31AM +, matthew green wrote:
> > Module Name:src
> > Committed By: mrg
> > Date: Thu Aug 3 08:16:31 UTC 2023
> >
> > Modified Files:
> > src/sys/arch/evbarm/gumstix: gumstix_machdep.c
> >
On 2023/08/04 20:18, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Fri Aug 4 11:18:18 UTC 2023
Modified Files:
src/sys/arch/sun2/dev: sc_mbmem.c
Log Message:
sun2/sc(4): Fix panic due to wrong ENOMEM for DMA buffer
Use kmem_zalloc(9) for
On Thu, Aug 03, 2023 at 08:16:31AM +, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Thu Aug 3 08:16:31 UTC 2023
>
> Modified Files:
> src/sys/arch/evbarm/gumstix: gumstix_machdep.c
> src/sys/arch/evbarm/ixm1200: ixm1200_machdep.c
>
Oops, thanks for quick fix, and it seems that I need a cup of coffee...
Thanks,
rin
On 2023/07/29 22:57, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sat Jul 29 13:57:28 UTC 2023
Modified Files:
src/sys/compat/netbsd32: netbsd32_compat_80.c
On 2023/07/29 22:13, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sat Jul 29 13:13:50 UTC 2023
Modified Files:
src/sys/compat/netbsd32: netbsd32_compat_50.c
Log Message:
Now, netbsd32_compat_50 module requires netbsd32_compat_100.
Thanks pgoyette@ for
> Date: Fri, 28 Jul 2023 23:40:40 +0900
> From: Izumi Tsutsui
>
> > Module Name:src
> > Committed By: riastradh
> > Date: Fri Jul 28 10:37:28 UTC 2023
> >
> > Modified Files:
> > src/sys/kern: kern_tc.c
> >
> > Log Message:
> > timecounter(9): Link to phk's
> Module Name: src
> Committed By: riastradh
> Date: Fri Jul 28 10:37:28 UTC 2023
>
> Modified Files:
> src/sys/kern: kern_tc.c
>
> Log Message:
> timecounter(9): Link to phk's timecounter paper for reference.
Maybe it's better to refer our timecounter(9) man page?
On 2023/07/24 16:14, matthew green wrote:
"Rin Okuyama" writes:
Module Name:src
Committed By: rin
Date: Mon Jul 24 01:56:59 UTC 2023
Modified Files:
src/sys/arch/i386/stand/efiboot: Makefile.efiboot eficons.c
Added Files:
src/sys/arch/i386/stand/efiboot:
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Mon Jul 24 01:56:59 UTC 2023
>
> Modified Files:
> src/sys/arch/i386/stand/efiboot: Makefile.efiboot eficons.c
> Added Files:
> src/sys/arch/i386/stand/efiboot: eficpufunc.c eficpufunc.h
>
> Log Message:
>
Emmanuel Dreyfus writes:
> On Thu, Jun 29, 2023 at 08:43:36PM -0400, Greg Troxel wrote:
>> > Primary bootstrap is now able to read a GPT inside RAIDframe.
>> did you also update documentation?
>
> We do not have any documentation specific to primary bootstrap.
> x86/boot(8) domuent the behavior
On Thu, Jun 29, 2023 at 08:43:36PM -0400, Greg Troxel wrote:
> > Primary bootstrap is now able to read a GPT inside RAIDframe.
> did you also update documentation?
We do not have any documentation specific to primary bootstrap.
x86/boot(8) domuent the behavior with no detail about primary
and
"Emmanuel Dreyfus" writes:
> Log Message:
> Primary bootstrap is now able to read a GPT inside RAIDframe.
did you also update documentation?
> Date: Sun, 30 Apr 2023 07:27:34 +0700
> From: Robert Elz
>
> Date:Sat, 29 Apr 2023 23:30:18 +
> From:"Robert Elz"
> Message-ID: <20230429233018.cadf4f...@cvs.netbsd.org>
>
> | Modified Files:
> | src/sys/kern: vfs_subr.c
> | src/sys/sys: sdt.h
> |
Date:Sat, 29 Apr 2023 23:30:18 +
From:"Robert Elz"
Message-ID: <20230429233018.cadf4f...@cvs.netbsd.org>
| Modified Files:
| src/sys/kern: vfs_subr.c
| src/sys/sys: sdt.h
|
| Log Message:
| Fix builds (hopefully) when DTRACE hooks are not
> Date: Tue, 11 Apr 2023 21:50:49 +0200
> From: Michael van Elst
>
> On Wed, Apr 12, 2023 at 01:10:40AM +0700, Robert Elz wrote:
> >
> > | In that state then decrementing dk_rawopens beyond zero will make
> > | dklastclose do the right thing: nothing.
> >
> > Except that if that happens,
> Module Name:src
> Committed By: mlelstv
> Date: Mon Apr 10 15:26:57 UTC 2023
>
> Modified Files:
> src/sys/dev/usb: uvideo.c uvideoreg.h
>
> Log Message:
> Better descriptor parsing.
How is it better? What problems does it fix?
> Add sanity check if no default format
On Wed, Apr 12, 2023 at 01:10:40AM +0700, Robert Elz wrote:
>
> | In that state then decrementing dk_rawopens beyond zero will make
> | dklastclose do the right thing: nothing.
>
> Except that if that happens, dk_rawopens will be left == ~0 and the next
> open attempt will then increment it,
Date:Tue, 11 Apr 2023 17:21:17 +0200
From:Michael van Elst
Message-ID:
| In that state then decrementing dk_rawopens beyond zero will make
| dklastclose do the right thing: nothing.
Except that if that happens, dk_rawopens will be left == ~0 and the next
open
On Tue, Apr 11, 2023 at 09:07:49AM +, Taylor R Campbell wrote:
>
> (a) how we can legitimately enter a state where the assertions are
> violated, and
dklastclose is called when the close operation ends in no more openers.
There is nothing that guarantees that any open was successful
> Module Name:src
> Committed By: mlelstv
> Date: Tue Sep 27 17:04:52 UTC 2022
>
> Modified Files:
> src/sys/dev/dkwedge: dk.c
>
> Log Message:
> Remove bogus assertions.
>
> @@ -1221,8 +1221,6 @@ dklastclose(struct dkwedge_softc *sc)
>
>
On Mon, Feb 20, 2023 at 15:41:04 +0100, Martin Husemann wrote:
> On Mon, Feb 20, 2023 at 05:15:33PM +0300, Valery Ushakov wrote:
> > them up, b/c you cannot amend that comment. To add to the fun, I
> > think releng scripts just clone the commit message on pull ups, so
> > that comment gets
On Mon, Feb 20, 2023 at 22:35:40 +0700, Robert Elz wrote:
> Date:Mon, 20 Feb 2023 16:47:01 +0300
> From:Valery Ushakov
> Message-ID:
>
> | I wonder if we should stop abusing commit messages as pull-up
> | reminders. These XXX will not convey any useful
Date:Mon, 20 Feb 2023 16:47:01 +0300
From:Valery Ushakov
Message-ID:
| I wonder if we should stop abusing commit messages as pull-up
| reminders. These XXX will not convey any useful information a few
| months down the line...
I think they're useful (if only
On Mon, Feb 20, 2023 at 05:15:33PM +0300, Valery Ushakov wrote:
> them up, b/c you cannot amend that comment. To add to the fun, I
> think releng scripts just clone the commit message on pull ups, so
> that comment gets splattered all over the target branches too.
Yes - I try to manually remove
On Mon, Feb 20, 2023 at 13:57:32 +, Taylor R Campbell wrote:
> > > XXX pullup-8
> > > XXX pullup-9
> > > XXX pullup-10
> >
> > I wonder if we should stop abusing commit messages as pull-up
> > reminders. These XXX will not convey any useful information a few
> > months down the line...
>
>
> Date: Mon, 20 Feb 2023 16:47:01 +0300
> From: Valery Ushakov
>
> On Mon, Feb 20, 2023 at 13:30:23 +, Taylor R Campbell wrote:
>
> > Module Name:src
> > Committed By: riastradh
> > Date: Mon Feb 20 13:30:23 UTC 2023
> >
> > Modified Files:
> >
On Mon, Feb 20, 2023 at 13:30:23 +, Taylor R Campbell wrote:
> Module Name: src
> Committed By: riastradh
> Date: Mon Feb 20 13:30:23 UTC 2023
>
> Modified Files:
> src/sys/arch/sparc64/sparc64: lock_stubs.s
>
> Log Message:
> sparc64: Add missing LoadStore ordering for
Date:Tue, 24 Jan 2023 14:51:03 - (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| Once we add them older kernels will break,
I doubt that they'd break any kernels - curses using programs using
these sequences with an old kernel might break
On Tue, 24 Jan 2023 at 14:51, Christos Zoulas wrote:
>
> In article ,
> Valery Ushakov wrote:
> >On Wed, Jan 18, 2023 at 12:02:17 -0500, Christos Zoulas wrote:
> >
> >> Module Name: src
> >> Committed By:christos
> >> Date:Wed Jan 18 17:02:17 UTC 2023
> >>
> >> Modified
In article ,
Valery Ushakov wrote:
>On Wed, Jan 18, 2023 at 12:02:17 -0500, Christos Zoulas wrote:
>
>> Module Name: src
>> Committed By:christos
>> Date:Wed Jan 18 17:02:17 UTC 2023
>>
>> Modified Files:
>> src/sys/dev/wscons: wsemul_vt100_subr.c
>>
>> Log
On Wed, Jan 18, 2023 at 12:02:17 -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Wed Jan 18 17:02:17 UTC 2023
>
> Modified Files:
> src/sys/dev/wscons: wsemul_vt100_subr.c
>
> Log Message:
> Add rin, indn, vpa, hpa, and cbt terminfo capabilities
"Jonathan A. Kollasch" writes:
> Module Name: src
> Committed By: jakllsch
> Date: Thu Jan 5 02:38:51 UTC 2023
>
> Modified Files:
> src/sys/net: if_wg.c
>
> Log Message:
> Check for authorization for SIOCSDRVSPEC and SIOCGDRVSPEC ioctls for wg(4).
>
> Addresses PR 57161.
might be
> Modified Files:
> src/sys/conf: copyright
>
> Log Message:
> Welcome to 2023. Wrap lines so the years fit in to 80 columns with
> a leading kernel log timestamp.
Please don't forget requesting pullup to all release branches.
Thanks,
---
Izumi Tsutsui
On Tue, Dec 13, 2022 at 12:32:26AM +1100, matthew green wrote:
> "Michael van Elst" writes:
> > Module Name:src
> > Committed By: mlelstv
> > Date: Sun Dec 11 11:31:55 UTC 2022
> >
> > Modified Files:
> > src/sys/fs/autofs: autofs_vnops.c
> >
> > Log Message:
> >
"Michael van Elst" writes:
> Module Name: src
> Committed By: mlelstv
> Date: Sun Dec 11 11:31:55 UTC 2022
>
> Modified Files:
> src/sys/fs/autofs: autofs_vnops.c
>
> Log Message:
> Use genfs_pathconf for VOP_PATHCONF.
> Fixes bin/57103.
i see pathconf failures with puffs
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
1 - 100 of 5579 matches
Mail list logo
