Hello!
Is there a reason not to enable dt(4) on macppc by default? I have
built a kernel with dt enabled for test purposes and it seems to work
correctly - commands like 'btrace /usr/share/btrace/kprofile.bt'
work and I get stacks.
Maybe I'm missing something and there are known problems? But
Greg Steuck writes:
> I went looking for why things are better on FreeBSD and they have a
> different (simpler) implementation of cos. I copied it over. Given the
> common provenance, I expect the copyright situation to be unambiguous.
>
> With the two patches things look almost universally
On Tue, Jan 18, 2022 at 01:03:04AM +0100, Alexander Hall wrote:
> On Mon, Jan 17, 2022 at 02:23:52PM +, Klemens Nanni wrote:
> > I keep doing `btrace -l | sort' to help myself searching for traces.
> >
> > Would it be worh making btrace sort the list of probes
> > lexicographically in the
While intended for more architectures, DDBPROF is strictly amd64 and
i386 only, so the machine-independent sys/conf/GENERIC does not seem fit
(until all architectures are supported).
Index: conf/GENERIC
===
RCS file:
On Mon, Jan 17, 2022 at 5:02 AM Klemens Nanni wrote:
> These don't hurt on !VMM architectures but I was still surprised to see
> them on e.g. sparc64:
>
> # arch -s ; btrace -l | grep vmm
> sparc64
> tracepoint:vmm:guest_enter
> tracepoint:vmm:guest_exit
>
> Like
On Mon, Jan 17, 2022 at 02:23:52PM +, Klemens Nanni wrote:
> I keep doing `btrace -l | sort' to help myself searching for traces.
>
> Would it be worh making btrace sort the list of probes
> lexicographically in the first place or is there any value in seeing
> them sorted by id?
I believe
On Mon, Jan 17, 2022 at 10:10:26AM -0300, Crystal Kolipe wrote:
> On Mon, Jan 17, 2022 at 01:00:44PM +, Klemens Nanni wrote:
> > These don't hurt on !VMM architectures but I was still surprised to see
> > them on e.g. sparc64:
> >
> > # arch -s ; btrace -l | grep vmm
> > sparc64
> >
On Sat, Jan 15, 2022 at 09:31:21PM +0100, Christian Weisgerber wrote:
> sbin/pfctl: fix -Wunused-but-set-variable warning
>
> M sbin/pfctl/pfctl_optimize.c
OK bluhm@
> diff 7c5dd09ecd1ff078b868c9ab52aac9754cde7761
> 6e5c342a53c05496c18849837c67b7dc05ce3792
> blob -
> Date: Mon, 17 Jan 2022 14:43:11 +
> From: Visa Hankala
>
> This fixes two bugs in plic(4). When a particular CPU is not found,
> typically when running GENERIC or RAMDISK on a multiprocessor machine,
> plic_get_cpuid() returns -1. In that case plic_attach() should just
> ignore the entry
Le Mon, Jan 17, 2022 at 02:25:27PM +, Stuart Henderson a écrit :
> On 2022/01/17 14:54, Christian Weisgerber wrote:
> > usr.sbin/ospf6d: fix -Wunused-but-set-variable warnings
> >
> > merge_config() sets "rchange", but doesn't use it. Comparing the
> > code to osfpd/ospfd.c makes me think
usr.sbin/rad: fix -Wunused-but-set-variable warning
Trivial removal of unused variable.
M usr.sbin/rad/frontend.c
diff c9fb0989c5128843af76d1ecd08c6f483f233307
1779a21799642d5916a407f0cea6255b101c055c
blob - e6f6ae0419ab1662ebb2e8cdd17c07a82d1b87f9
blob +
This fixes two bugs in plic(4). When a particular CPU is not found,
typically when running GENERIC or RAMDISK on a multiprocessor machine,
plic_get_cpuid() returns -1. In that case plic_attach() should just
ignore the entry and move on. The `cpu' variable should also be signed,
otherwise the
usr.sbin/ospf6ctl: fix -Wunused-but-set-variable warning
Maybe this is uncompleted code, but I think we can remove it for
the time being.
M usr.sbin/ospf6ctl/ospf6ctl.c
diff a992977b148f5fd9d4e3b9af9aeccac488edfa7a
c9fb0989c5128843af76d1ecd08c6f483f233307
blob -
On 2022/01/17 14:54, Christian Weisgerber wrote:
> usr.sbin/ospf6d: fix -Wunused-but-set-variable warnings
>
> merge_config() sets "rchange", but doesn't use it. Comparing the
> code to osfpd/ospfd.c makes me think that's an omission. Either
> way it seems odd that the two code bases differ
I keep doing `btrace -l | sort' to help myself searching for traces.
Would it be worh making btrace sort the list of probes
lexicographically in the first place or is there any value in seeing
them sorted by id?
Index: btrace.c
===
usr.sbin/ospf6d: fix -Wunused-but-set-variable warnings
merge_config() sets "rchange", but doesn't use it. Comparing the
code to osfpd/ospfd.c makes me think that's an omission. Either
way it seems odd that the two code bases differ here.
rde_summary_update() is incomplete. We can simply
On Mon, Jan 17, 2022 at 08:34:39AM -0500, Dave Voutila wrote:
> vmm(4) was removed from i386 hosts a couple years ago if my memory is
> correct.
Ah, my bad. It was indeed removed on 20190118.
Crystal Kolipe writes:
> On Mon, Jan 17, 2022 at 01:00:44PM +, Klemens Nanni wrote:
>> These don't hurt on !VMM architectures but I was still surprised to see
>> them on e.g. sparc64:
>>
>> # arch -s ; btrace -l | grep vmm
>> sparc64
>> tracepoint:vmm:guest_enter
>>
On 2022/01/17 10:10, Crystal Kolipe wrote:
> On Mon, Jan 17, 2022 at 01:00:44PM +, Klemens Nanni wrote:
> > These don't hurt on !VMM architectures but I was still surprised to see
> > them on e.g. sparc64:
> >
> > # arch -s ; btrace -l | grep vmm
> > sparc64
> >
On Mon, Jan 17, 2022 at 01:00:44PM +, Klemens Nanni wrote:
> These don't hurt on !VMM architectures but I was still surprised to see
> them on e.g. sparc64:
>
> # arch -s ; btrace -l | grep vmm
> sparc64
> tracepoint:vmm:guest_enter
> tracepoint:vmm:guest_exit
>
>
Hi,
Sometimes uchcom(4) looks Rx jammed.
Here is the movie (at Mastodon) that the problem has occured:
https://social.tchncs.de/@uaa/107637913051446044
Receiving an exact wMaxPacketSize bytes bulk packet from CH34x causes
this problem, because this means USB transaction is not finished.
These don't hurt on !VMM architectures but I was still surprised to see
them on e.g. sparc64:
# arch -s ; btrace -l | grep vmm
sparc64
tracepoint:vmm:guest_enter
tracepoint:vmm:guest_exit
Like some network drivers, we could use __amd64__ to limit those to
amd64
Hello, OpenBSD Developers!
Here's my code which implements this new feature, however it doesn't always
work as intended:
-
https://github.com/time-killer-games/bugs/blob/679d333cd947cb4cbec7c45485157b305aa0757b/apifilesystem/filesystem.cpp#L55-L62
-
On Mon, Jan 17, 2022 at 09:52:50AM +, Klemens Nanni wrote:
> One small mechanical diff to get rid of the boolean_t signature and
> reduce difference to NetBSD.
>
> uvm_flush() aka. uao_flush()/udv_flush()/pgo_flush()/uvn_flush() returns
> TRUE/FALSE only to make uvm_map_clean() conditionally
One small mechanical diff to get rid of the boolean_t signature and
reduce difference to NetBSD.
uvm_flush() aka. uao_flush()/udv_flush()/pgo_flush()/uvn_flush() returns
TRUE/FALSE only to make uvm_map_clean() conditionally return EFAULT.
This makes the *_flush() return 0/EFAULT themselves and
25 matches
Mail list logo
