Chris Narkiewicz writes:
> On Tue, 2023-10-17 at 16:22 -0600, Theo de Raadt wrote:
>> What will come of this discussion of opinions?
>
> If it's doable and the code quality is acceptable, I see 2 outcomes:
> 1. I could start looking for sponsorship, as I feel like my level of
> expertise is too l
I just got myself a fresh snapshot with libncurses.so.15.0:
OpenBSD 7.4-current (GENERIC.MP) #1409: Tue Oct 17 17:08:49 MDT 2023
I get some unhappiness now:
# pkg_add -ui
No progress meter: failed termcap loop
quirks-6.161 signed on 2023-10-16T11:16:03Z
Fallout from the ncurses upgrade?
Thanks
G
I had firefox crash on me but the core looks suspect. I don't understand
why `push %r15` is an invalid instruction.
% egdb /usr/local/lib/firefox/firefox ~/firefox.core
GNU gdb (GDB) 9.2
...
[New process 561871]
warning: .dynamic section for "/usr/lib/libc++.so.9.0" is not at the expected
add
Thanks for the patch.
I could see some value in tightening the conditions to always check
`!= expected`. I don't see enough improvement from separating the error
case of -1 from the incomplete read case considering the otherwise
identical behavior.
Lucas writes:
> Bump.
>
>
Visa Hankala writes:
> The EPIPE error relates to the situation where a kevent(2) EVFILT_WRITE
> call on a pipe races with the closing of the pipe's other end.
> If the close(2) happens before the kevent registration, kevent(2)
> returns EPIPE. If the close(2) happens after the kevent(2) call,
>
I'm debugging a non-trivial multithreaded unit test in the current
version of lang/ghc. It runs into some kind of unexpected condition not
handled well by GHC. I suspect we do something non-standard to cause
this behavior. These two ktrace items illustrate the issue:
12550/209588 T21651 CALL
Thanks Crystal. If somebody wants to commit this, it is OK gnezdo@
Crystal Kolipe writes:
> The iskmemdev function checks for minor number 14 in addition to 0 and 1 on
> the following archs:
>
> amd64, arm64, i386, and riscv64
>
> Device 2, 14 was traditionally /dev/io, which we don't support an
"Theo de Raadt" writes:
... removed the comprehensive summary of the effort.
> The major application problems have been reasonably isolated, and after
> 3 weeks they are mostly handled, or we know where the remaining problems
> lie:
>
> - libcrypto assembly functions with incorrect data plac
Jose Maldonado writes:
> Right now I'm using OBSD 7.2 (my first time in OBSD) and the only issue
> is my onboard audio. The audio randomly stuck (listen music or not, with
> high CPU use or not) and only a hard reboot give me back audio to next
> stuck.
>
> In dmesg don´t show nothing, but snd
Hi David,
Here are all the outputs you mentioned. Hopefully something will improve
our understanding of this story.
David Gwynne writes:
> Ofails are the sum of output errors and queue drops. Can you figure
> out which one it is with netstat -I igc0 -e and netstat -I igc0 -d?
% netstat -I igc2
Greg Steuck writes:
> The watched kettle never boiled. No more crashes in over two weeks
> (instead of two in the first week). I tried a loop of alternating iperf3
> tcp and udp to no ill effect. I still see the growth in the metrics I
> reported, yet the system remained stable.
&
The watched kettle never boiled. No more crashes in over two weeks
(instead of two in the first week). I tried a loop of alternating iperf3
tcp and udp to no ill effect. I still see the growth in the metrics I
reported, yet the system remained stable.
I applied the patch below and am still collect
Greg Steuck writes:
> My router has become unstable since upgrading from 7.1-stable to
> 7.2. After several days of uptime the machine gets into a state where
> some applications (unbound & dhcpd) report ENOBUFS (No buffer space
> available). At that time the machine is pinga
My router has become unstable since upgrading from 7.1-stable to
7.2. After several days of uptime the machine gets into a state where
some applications (unbound & dhcpd) report ENOBUFS (No buffer space
available). At that time the machine is pingable over all the
interfaces, but only the upstream
Greg Steuck writes:
Matthieu> + authok = priv_pw_check(user, style, pass);
I suspect your original patch may have swapped the arguments. The
password should go before style.
What do you thing about this patch (tested locally, but I don't have style):
diff --git a/app/xlockmo
Hi Matthieu,
I'd be inclined to go with a return in the middle and avoid some extra
variables, what do you think about the following (entirely eye-ball tested)?
char*pass;
/* buffer can be in the form style:pass */
if ((pass = strchr(buffer, ':')) != NULL) {
Thanks Christian!
OK gnezdo@ is somebody want to commit this. I confirmed that it builds too.
Christian Ludwig writes:
> There is a return missing in one of the error paths of igc_init().
> ---
> sys/dev/pci/if_igc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/sys/dev/pci/if_igc.c
Thanks for sending this fix Xiaohui.
The upstream patch is more complete
https://github.com/torvalds/linux/commit/7b89bf83181363a84f86da787159ddbbef505b8c
I believe the fixes will arrive via a normal update process unless
somebody knows a reason to apply this one specifically out of schedule.
Xi
"Johannes (krjdev) Krottmayer" writes:
> Because I want add support for a new device (NETGEAR Nighthawk RAX200
> router) to OpenBSD I need more detailed information about the Kernel
> API. Must create drivers for the corresponding devices. Want use
> OpenBSD as secure router operating system for
EPS in these files, I see LLVM as the only one in
common between
/usr/src/gnu/usr.bin/clang/lld/Makefile
/usr/src/gnu/usr.bin/clang/clang/Makefile
LLVM seems like a dubious place for such adhoc code sharing.
Thanks
Greg
>
>
> Todd
>
> On Fri, Feb 25, 2022 at 07:27:08PM -0800
No opinions?
Greg Steuck writes:
> LLVM OpenBSD guardians,
>
> I want to get a closure on "Power-up cc --print-file-name for .so names"
> thread on tech@. I care because it helps me with lang/ghc port.
>
> Here's a is fairly finished diff. I'll be taking i
"Todd C. Miller" writes:
> On Sun, 13 Feb 2022 12:07:31 -0800, Greg Steuck wrote:
>
>> I noticed that despite the OKs the code didn't submitted. Should we
>> revive this diff now and continue in the tree?
>>
>> I have vested interest: I don't w
Jeremie Courreges-Anglas writes:
> Maybe something like this? The idea is to point people to ubsan_minimal
> instead of assuming that ubsan isn't supported at all. I can't see
> a better place to document this.
>
> For more context: UBSan is supposed to catch undefined behavior at
> runtime and
Andrei writes:
> The lldb(1) debugger was recently added in base and as I was playing around
> with it I noticed the lack of line editing functionality.
>
> This is because currently lldb is built without support for
> libedit. It would be nice to have libedit in base such to be able to
> link l
body has a good idea
where the identical code could live, I'm open to not duplicating
it. Otherwise, OK?
Thanks
Greg
>From 447d158494ce4a1b4986f16e3bc2ef057712fe27 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 13 Feb 2022 22:28:43 -0800
Subject: [PATCH] Report versioned lib.so in cc -
"Theo de Raadt" writes:
> Philip Guenther wrote:
>
>> On Sun, Feb 13, 2022 at 11:18 PM Mark Kettenis
>> wrote:
>>
>> > > From: Greg Steuck
>> > > Date: Sun, 13 Feb 2022 22:37:13 -0800
>> > >
>> > > To give a se
Mark Kettenis writes:
>> From: Greg Steuck
>> Date: Sun, 13 Feb 2022 22:37:13 -0800
>>
>> To give a sense of the kind of change required to get the feature I
>> want, see the patch at the end. The change in DriverUtils.cpp is just to
>> show that the same fu
m not sure where this would belong. Maybe a
new tiny library of such wrappers to maintain in our tree?
Thanks
Greg
P.S. Naturally, once I install this patched cc, ghci is suddenly very
happy.
Greg Steuck writes:
> Since OpenBSD always uses .so.major.minor I observe GHCi running into
> t
Jonathan Gray writes:
> On Sun, Feb 13, 2022 at 12:07:31PM -0800, Greg Steuck wrote:
>> Ingo Schwarze writes:
>>
>> > Hi Todd,
>> >
>> > in view of your arguments and sthen@'s OK, i'm also OK with this
>> > going in. I think a bit
Ingo Schwarze writes:
> Hi Todd,
>
> in view of your arguments and sthen@'s OK, i'm also OK with this
> going in. I think a bit of code cleanup and copy editing in the
> manual page may be useful afterwards, but that can be done in the
> tree, no need for playing patch ping pong.
I noticed that
Greg Steuck writes:
> Sweet, let's look at the two patches below. No sets yet.
The trivial change below produced a comp70.tgz with the new library
after `make release` on amd64.
>From 7bbf84dfa72b4417fec5bf337fd2fdd310f70205 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 6
; On Sat, Feb 05 2022, Jeremie Courreges-Anglas wrote:
>> On Fri, Feb 04 2022, Greg Steuck wrote:
>>> How do people feel about shipping the minimal UBSan runtime library[1]
>>> in the base system? It takes very little to build (Makefile + a few
>>> ifdefs that both jc
How do people feel about shipping the minimal UBSan runtime library[1]
in the base system? It takes very little to build (Makefile + a few
ifdefs that both jca@ and I hacked together). The library is tiny and
useful enough for finding UB in base.
% ls -l /usr/lib/clang/13.0.0/lib/libclang_rt.ubsan
Patrick Wildt writes:
> regarding the missing userpace support: Since a few clang updates ago
> we import more than just the builtins of compiler-rt. This means we
> should have at least some related code in our tree, even if it is not
> built/complete. From the recent static analyzer mail thr
In case somebody hits this, here's a resolved issue: -fno-wrapv is
matters for UBSan coverage.
Confusion starts with:
$ uname -srm; cat a.c && clang -fsanitize=undefined a.c -c -o a.o && nm a.o
OpenBSD 7.0 amd64
int main(int argc, char **argv) {
int k = 0x7fff;
k += argc;
return 0;
}
00
Greg Steuck writes:
>> I notice people keep sending fixes to problems reported by UBSan. I
>> wanted to join the club, but the trivial thing listed at
>> https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html doesn't
>> work:
My confusion is easily resolved. P
directory
clang-13: error: linker command failed with exit code 1 (use -v to see
invocation)
Greg Steuck writes:
> I notice people keep sending fixes to problems reported by UBSan. I
> wanted to join the club, but the trivial thing listed at
> https://clang.llvm
I notice people keep sending fixes to problems reported by UBSan. I
wanted to join the club, but the trivial thing listed at
https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html doesn't
work:
$ cat a.cc; clang++ -fsanitize=undefined a.cc; ./a.out
int main(int argc, char **argv) {
int k =
As I was staring a bit more at sysctl related code this pattern caught
my attention. Looks like a few lines can disappear and hopefully code
expressivity goes up.
Anybody like this?
>From 3b52f9ad743fe9b59316077478d33f77fff9a119 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 23 Jan 2
Ted Bullock writes:
> I've been curious about this for a long time; Would using
> const uint16_t or uint32_t instead of proprocessor defines also make
> sense anyway if the purpose is to stop the compiler from being
> mysterious with implicit data types? I've never seen a compelling reason
> to u
another regress run on at least
arm64 and powerpc64, I expect this to be ready for OKs.
>From cd7274dd42398f5abee9fa8614aed87da2758fe7 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Mon, 10 Jan 2022 20:22:07 -0800
Subject: [PATCH 1/4] Copy cos(3) software implementation from FreeBSD-13
The
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 alm
Greg Steuck writes:
> This failure can be reduced to a trivial program which does change
> its behavior for the worse if s_cos.S is taken out:
>
> #include
> #include
>
> int main(int a, char**b) {
> double y = -0.34061437849088045332;
> printf("co
"Todd C. Miller" writes:
> On Fri, 07 Jan 2022 00:45:47 -0800, Philip Guenther wrote:
>
>> No where. The difference in behavior is that of 'sh' when signaled. Run
>> your test programs under "ktrace -i" and compare the behavioral difference
>> of the child 'sh' process after reception of the SI
I started by debugging a weird test failure in ghc. I narrowed it
down to a simple C program which behaves differently between OpenBSD and
FreeBSD. I stared at the headers of both systems for a bit and still
don't see why on OpenBSD the program prints:
uname -a ; cc ./a.c && ./a.out
OpenBSD home.n
Crystal Kolipe writes:
> The gpt driver was completely deleted from the tree in 2016, and removed from
> the i386 GENERIC config in revision 1.819.
>
> It has, however, remained in the amd64 GENERIC config commented out,
> which seems like an oversight.
I agree, thanks!
>
> This patch removes
Jonathan Gray writes:
> DEFMAXLOCAL unused since 2007
> 'kill local/jobs distinction. Correctly this time...'
> https://github.com/openbsd/src/commit/f01cd4cc8e1908cec38b82298fe3fc96c7421321
>
> RANLIBMAG unused since 2012
> 'more changes, discussed and tested by various people'
> https://github.
OK gnezdo@
Brad Smith writes:
> Being that rge(4) is derived from re(4) it looks like it has the same
> issues as fixed in re(4) rev 1.211.
>
> revision 1.211
> date: 2021/05/17 11:59:53; author: visa; state: Exp; lines: +4 -1;
> commitid: aS9a9xwYauxPaauQ;
> Fix mbuf leaks after reception
Anton Lindqvist writes:
> On Thu, Nov 11, 2021 at 03:29:15PM +0100, Anton Lindqvist wrote:
>> Hi,
>> The second attempt to solve the uhidev claim multiple report ids
>> conflict didn't work out either as it broke fido(4). Signalling claim
>> multiple report ids to the match routines using the rep
Mark Kettenis writes:
>> From: "Theo de Raadt"
>> Date: Tue, 07 Sep 2021 07:08:19 -0600
>>
>> Or we could coordinate the Greg approach as a sysctl ABI change near a
>> libc major bump. On the other side of such a bump, all kernel + base +
>> packages are updated to use the new storage ABI. We
grams
to detect memory errors. If people don't see an alternative solution,
I'll fix up the users of kinfo_proc.p_vm_dsize and we can decide
when/how this should land.
>From 42c776531620e9baa6735da71349c3c045fb64d8 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 5 Sep 2021 13
My aspiration for k2k21 was to get ASan working on OpenBSD. The
following is a dump of the current state and questions about future
directions.
There are roughly two parts to ASan, the compiler instrumentation and
the runtime library. The instrumentation is likely much less system
dependent than t
Anton Lindqvist writes:
> As the Consumer Control usages are well defined by the HID Usage Tables
> specification ucc might as well enumerate all of them. Finding an
> appropriate scan code recognized by X11 for each usage is more tricky.
> I've added a few more but the majority are still unmappe
Stefan Sperling writes:
> Taking a fresh look at this in the morning, I think we should be checking
> for errors from ieee80211_set_key() before flagging the group key as valid.
> The only reason this could fail in your case is ENOMEM so it shouldn't
> make a difference regarding your test case.
Stefan Sperling writes:
> On Tue, Jul 06, 2021 at 12:31:20AM +0200, Stefan Sperling wrote:
>> On Mon, Jul 05, 2021 at 02:11:36PM -0700, Greg Steuck wrote:
>> > Do I need to figure out the state machines behind iwx and iee80211 now? :)
>>
>> This AP seems to use TK
Stefan Sperling writes:
> This AP seems to use TKIP for the groupcipher and the iwx
> setkey task doesn't handle this case properly.
>
> Can you try this?
This works great, yielding these diagnostics:
iwx0: associated with 38:ff:36:23:09:ac ssid "MarlinGuest" channel 52 start MCS
0 long preamb
Greg Steuck writes:
> Stefan Sperling writes:
>
>>> iwx0: received msg 3/4 of the 4-way handshake from 38:ff:36:23:09:ac
>>> iwx0: sending msg 4/4 of the 4-way handshake to 38:ff:36:23:09:ac
>>>
>>> I never see "iwx0: sending action to" aft
Stefan Sperling writes:
>> iwx0: received msg 3/4 of the 4-way handshake from 38:ff:36:23:09:ac
>> iwx0: sending msg 4/4 of the 4-way handshake to 38:ff:36:23:09:ac
>>
>> I never see "iwx0: sending action to" after this.
>
> And you still see status: "no network" in ifconfig at this point?
> Thi
Stefan Sperling writes:
> On Mon, Jul 05, 2021 at 09:35:20AM +0200, Stefan Sperling wrote:
>> On Sun, Jul 04, 2021 at 07:58:47PM -0700, Greg Steuck wrote:
>> > I never see "iwx0: sending action to" after this.
>>
>> And you still see status: "no netw
I stumbled upon a weird hotel WiFi which never gets to a fully running
link with iwx0. I see ifconfig is stuck with:
iwx0: flags=808847 mtu
1500
lladdr xx
index 1 priority 4 llprio 3
groups: wlan egress
media: IEEE802.11 autoselect (HT-MCS11 mode 11n)
statu
Scott Cheloha writes:
> No, no, I'm not being serious. Sorry. :)
>
> The throughput improvement with such a small code change is
> interesting though.
The interesting and serious question is whether there's something
suboptimal in stdio buffering which can be cheaply improved. It seems
unlikel
I started with a failing test for Haskell network package on 6.9-current amd64
(cabal get network-3.1.2.1 && cabal v2-test)
network-3.1.2.1/build/spec/spec --match
"/Network.Socket.ByteString/recvMsg/works well/"
tests/Network/Socket/ByteStringSpec.hs:209:21:
1) Network.Socket.ByteString.re
joshua stein writes:
> A bug was reported where a Kensington USB trackball didn't work
> properly:
>
> uhidev4 at uhub0 port 6 configuration 1 interface 0 "Kensington Expert
> Wireless TB" rev 2.00/1.02 addr 9
> uhidev4: iclass 3/1, 3 report ids
> ums3 at uhidev4 reportid 1
> um
I happened to be looking at the console of one of the VMs getting abused
by syzkaller and caught what looked like assertions that people might
want to see.
pmap_unwire: wiring for pmap 0xfd807f009ae0 va 0x20001000 didn't change!
pmap_unwire: wiring for pmap 0xfd807f009ae0 va 0x20002000 did
Jan Klemkow writes:
> ping?
>
> On Thu, May 13, 2021 at 04:45:14PM +0200, Jan Klemkow wrote:
>> ping?
>>
>> On Sat, May 01, 2021 at 11:19:56AM +0200, Jan Klemkow wrote:
>> > Hi,
>> >
>> > This cleanup diff, removes a useless if islower(3) from the loop. It is
>> > guarantee by toupper(3) that
Jan Klemkow writes:
> ping?
>
> On Thu, May 13, 2021 at 04:44:23PM +0200, Jan Klemkow wrote:
>> ping?
>>
>> On Wed, May 05, 2021 at 04:42:49PM +0200, Jan Klemkow wrote:
>> > Hi,
>> >
>> > The function lreply() already calls fflush(3) on stdout. So, this calls
>> > are useless.
>> >
>> > OK?
>From 674554534b9f046f2a4cdab5c2dbc3d019c7daa7 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Wed, 21 Apr 2021 19:33:35 -0700
Subject: [PATCH] drm/drm_edid: Read within initialized memory bounds (fix off
by one)
The problem manifests as a memory out of bounds kernel panic in
OpenBSD which uses this code. T
Vitaliy Makkoveev writes:
> On Fri, Apr 30, 2021 at 10:14:31PM -0700, Greg Steuck wrote:
> Hi, you missing KERN_SYSVMSG, KERN_SYSVSEM, KERN_SYSVSHM variables. The
> rest diff is ok by me.
Good catch. My search/replace pattern wasn't good enough. Fixed and will
commit.
>&
Vitaliy Makkoveev writes:
> On Thu, Apr 29, 2021 at 09:31:57AM -0700, Greg Steuck wrote:
>> Alexander Bluhm writes:
>> >> I like this too. I somehow got the impression that macros are severely
>> >> frowned upon and didn't offer this kind of interfac
Alexander Bluhm writes:
>> I like this too. I somehow got the impression that macros are severely
>> frowned upon and didn't offer this kind of interface before.
>>
>> If you get this submitted, I can do a pass through the codebase to be
>> sure we catch them all.
Vitaliy, I volunteer to do a se
Vitaliy Makkoveev writes:
> On Tue, Apr 27, 2021 at 09:12:56PM +0200, Alexander Bluhm wrote:
>> On Tue, Apr 27, 2021 at 12:18:02PM -0600, Theo de Raadt wrote:
>> > Actually, your variation seems pretty good. Is there any reason to not
>> > use this type of define?
>>
>> This would look like thi
this magic in sysctl_int(9) I'll
happily add something. I converted all the cases of sysctl_rdint I found
reasonable last year.
In the meantime, does this look OK?
>From cc944436f4569ef28fa338626bd90c5f6e6a44a7 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Sun, 25 Apr 2021 10:
Thanks Miod!
Miod Vallat writes:
> The todr_handle struct contains two unused function pointers, which are
> either not implemented or with clones of eopnotsupp(). The following
> diff removes this waste of kernel text.
OK gnezdo if somebody wants to commit.
If art@ comes back to finish this i
A nit below.
Alexandre Ratchov writes:
> On Thu, Apr 15, 2021 at 03:24:56PM +0200, Ivo Sbalzarini wrote:
> Thanks for looking at this. Few comments:
>
> - the "PCI_VENDOR(this->subid) == PCI_VENDOR_LENOVO" compares the 16
> lower bits of the subid. It's not necessary because below we compare
>
OK gnezdo with a usability question inline.
Marcus Glocker writes:
> martijn@ has recently reported that in his machine he has two cams
> of which one is doing IR, which isn't really supported by uvideo(4).
> This IR device attaches always first as uvideo0, so he needs to swap
> that regularly w
Ulf Brosziewski writes:
> wsmouse(4) doesn't free the memory allocated for the wstpad state
> when an external touchpad is being unplugged. This patch fixes
> the leak.
>
> OK?
OK gnezdo
This goes part way through (as can be seen with -m) and then fails:
% ftp -6 -M http://cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/base69.tgz
Trying 2a04:4e42:2d::729...
Requesting http://cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/base69.tgz
ftp: Reading from socket: Connection reset by peer
W
Klemens Nanni writes:
> 6.4 is getting old.
> OK?
OK gnezdo
benno@, markus@ I doubt you'd object, just FYI.
>
> Index: ifconfig.c
> ===
> RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
> retrieving revision 1.437
> diff -u -p -r1.4
Thomas Windisch writes:
> I can get an IPv6 address with my LTE-Modem via umb with 6.8-release but
> not with -current. I am aware that there was some discussion last year
> on IPv6 support in umb but I'm not really sure what has changed. In
> both cases I do get IPv4.
Running tcpdump on this in
Thanks Stuart!
Stuart Henderson writes:
> On 2021/03/09 07:41, Greg Steuck wrote:
>> ... which goes on for hours until I wake my desktop machine (lenny). I
>> know this doesn't sound related, but I observed this multiple times and
>> see no better correlation. The two
I have weak evidence that my network connection may be disappearing as
my persistent ssh connections fall off during the same time. The cable
modem is probably playing some stupid games.
Greg Steuck writes:
> ... until starting to fail with:
>
> Mar 9 00:53:18 alix unbound: [40947
I configured unbound running on my LAN router (alix) to forward all
requests over TLS to a bunch of places with:
forward-zone:
name: "."
forward-tls-upstream: yes
# Quad9
forward-addr: 2620:fe::fe@853#dns.quad9.net
forward-addr: 9.9.9.9@853#dns.quad9.net
forward-addr: 2620:fe::9@853#dn
I had an iwx working fine (modulo known issues) for a bit on amd64 current:
iwx0 at pci0 dev 20 function 3 "Intel Wi-Fi 6 AX201" rev 0x00, msix
iwx0: hw rev 0x350, fw ver 48.1335886879.0, address xxx
Then for no discernible reason the kernel started saying:
"Intel Wi-Fi 6 AX201" rev 0x00 at pci0
Scott Cheloha writes:
> Hi,
>
> If the timecounter struct changes again in the future it will be
> easier to make the change if we are using C99-style initialization
> everywhere. In general I think C99-style initialization is easier to
> read for larger structs. The timecounter struct definite
Alexander Bluhm writes:
> Hi,
>
> Next try to fix syzkaller crash
> https://syzkaller.appspot.com/bug?id=54e16dc5bce6929e14b42e2f1379f1c18f62be43
>
> Interface group names must fit into IFNAMSIZ and be unique. But
> the kernel makes the unique check before trunkating with strlcpy().
> So there c
Hi Marcus,
Marcus Glocker writes:
> There are a few threads going on related to problems with ugen(4) and
> uhidev(4) devices on xhci(4). This is related to the issue patrick@
> already explained; while ehci(4) can save the last data toggle state,
> xhci(4) resets it on every open/close cycle,
Alexander Bluhm writes:
> As documented in sysctl(2) net.inet.ip.forwarding can be 2.
...
>
> Index: netinet/ip_input.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_input.c,v
> retrieving revision 1.353
> diff -u -p -
Thanks for the reviews!
Marcus Glocker writes:
> On Sat, 9 Jan 2021 22:09:06 +0100
> Marcus Glocker wrote:
> If you could fix the switch() indentation in a separate commit (as you
> already mentioned in one of your previous e-mails), that would be nice.
How's this instead? OK?
Tested with the
Thanks Todd for reviewing these boring patches!
Todd C. Miller writes:
> Updated diff looks good to me. OK millert@ but it would be good
> to get feedback from Marcus too.
Sure thing, I'll wait till tomorrow then?
Thanks
Greg
> I tested this by diff'ing sysctl output before/after on amd64. Since
> there's a bunch of ifdef'ness I verified RAMDISK still builds.
>
> I deliberately didn't fix the indentation to keep this diff a pure line
> motion (would run over 80 chars otherwise). I can either fix that it in
> a separate
Paul Irofti writes:
> I think Scott should split his diff in two so people can test which
> part breaks suspend-resume. Can you try reverting the dsdt.c bits and
> leaving the acpiec part of the diff in your tree and see if suspend is
> still broken?
Reverting dsdt.c and applying acpiec.c part r
I tested this by diff'ing sysctl output before/after on amd64. Since
there's a bunch of ifdef'ness I verified RAMDISK still builds.
I deliberately didn't fix the indentation to keep this diff a pure line
motion (would run over 80 chars otherwise). I can either fix that it in
a separate commit or i
Scott Cheloha writes:
> Short version:
>
> Please test if this patch breaks suspend or hibernate on your
> machine. Reply with the results of your test and your dmesg.
>
> Both are still working on my Lenovo Thinkpad X1 Carbon Gen 6.
This breaks resume from zzz on HP EliteBook 840 G1. The machi
I'm scraping the bottom of the barrel with these, so dumped them all
together for ease of review. Will submit piecemeal as reviews happen.
All verified manually with sysctl -w. Even bothered to find an i386
machine with watchdog and build a WITNESS kernel to run all code paths.
OKs?
Subject: [PA
I just hit this while booting an i386-current in vmd. The source tree is
synced to "Remove the assertion in uvm_km_pgremove()."
I enabled WITNESS on top of GENERIC. Naturally, GENERIC-Dec15 snap works.
Anybody else see this so I know it's worth a bisect?
OpenBSD 6.8-current (WITNESS) #0: Tue Dec
George Koehler writes:
> On Mon, 30 Nov 2020 20:04:10 -0800
> Greg Steuck wrote:
>
>> Tested with a bunch of manual sysctl -w's.
>>
>> OK?
>
> I'm not sure about this diff. I'm more likely to do
> ddb{0}> set $radix = 0t2
> and
Mark Kettenis writes:
>> From: Greg Steuck
>> Date: Mon, 30 Nov 2020 20:54:59 -0800
>>
>> Mark Kettenis writes:
>>
>> > The diff below fixes the way we handle named references in AML
>> > packages. This fixes some bugs but I'd like t
Mark Kettenis writes:
> The diff below fixes the way we handle named references in AML
> packages. This fixes some bugs but I'd like to make sure that this
> doesn't inadvertedly break things. So tests on a wide variety of
> machines are welcome.
I see a prompt crash: https://photos.app.goo.gl
Tested with a bunch of manual sysctl -w's.
OK?
>From 24ae202fd5d39c3c40c029fb878aa15eee33b709 Mon Sep 17 00:00:00 2001
From: Greg Steuck
Date: Mon, 30 Nov 2020 19:42:19 -0800
Subject: [PATCH] Convert ddb_sysctl to sysctl_bounded_arr
---
sys/ddb/db_usrreq.c | 22 ++
Vitaliy Makkoveev writes:
> Hi.
>
> For me `ch' is unwanted here.
>
> Index: usr.sbin/tcpdump/util.c
> ===
> RCS file: /cvs/src/usr.sbin/tcpdump/util.c,v
> retrieving revision 1.30
> diff -u -p -r1.30 util.c
> --- usr.sbin/tcpdump/ut
1 - 100 of 180 matches
Mail list logo
