Re: sometimes graphics is slow, with high Xorg CPU usage
On Wed, 2021-03-10 at 09:19 -0800, Aaron Miller wrote: > On Wed, 2021-03-10 at 07:54 +, Stuart Henderson wrote: > > On 2021-03-09, Aaron Miller wrote: > > > For some time now, my -CURRENT system will occasionally get > > > into a > > > state where graphics is slow to refresh and the Xorg uses > > > ~50% > > > of > > > CPU. I notice this in Firefox or GVim when repeatedly > > > pressing > > > PgDn on a long site/file, and in Evolution (emails are slow > > > to > > > load, and text input is laggy when composing a message). > > > > > > OpenBSD 6.9-beta (GENERIC.MP) #366: Sun Feb 28 07:15:39 MST > > > 2021 > > > > Update your snapshot and see how it goes. > > It seems to be fixed now. > > I followed these steps in order: > > 1) test ===> not fixed > 2) set "machdep.allowaperture=1" in /etc/sysctl.conf and reboot > 3) test ===> not fixed > 4) upgrade snapshot and reboot > 5) realize I'm behind on openbsd.org/faq/current.html so I run > this: cd /dev && ./MAKEDEV dri > 6) reboot > 7) test ===> fixed > > Thanks for the help! > > --Aaron Unfortunately, the problem is back after a reboot. Is there any debugging information that would help track this down? I did find this in the stdout from firefox: Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: libpci missing (t=1.57872) [GFX1-]: glxtest: libpci missing --Aaron
Re: Keeping xlock on top in cwm
On Tue, Mar 16, 2021 at 04:53:32PM -0400, Dave Voutila wrote: I worked out how to set a "gap" so that maximized windows won't obscure the xclock line at the bottom. That helped. Unfortunately, it's not enough. By default `xconsole` is sized and positioned so, if brought forward, `xconsole` obscures `xclock`. That invariably happens if cycling through windows... You can change or remove xconsole from starting by modifying /etc/X11/xenodm/Xsetup_0 Thanks, but I like having xconsole... is there any way to make it obey the gap?
Re: AX201 Surface Pro 7
On Fri, Mar 05, 2021 at 07:15:11PM +0100, Stefan Sperling wrote: > On Fri, Mar 05, 2021 at 04:25:53PM +0100, Fredrik Engberg wrote: > > Hey, > > > > I had no luck with the "Qu-b0-hr-b0-48" firmware. But I had to change to > > "Qu-c0-hr-b0-48" and that seems to work. Here it is the changes I had to > > do to get it working. I might have done something wrong here so please > > point it out to me. > > > > Great! Thank for you doing this :) > > Your patch looks fine. This has now been committed. Thanks again for your help!
Re: Intel wifi ipw showing up but not working
On Mon, Mar 15, 2021 at 02:11:39PM +0100, Riccardo Mottola wrote:
> Stefan Sperling wrote:
> > > That means there is another bug. I will try to find it.
> > Could you show what 'netstat -W ipw0' looks like after an unsuccesful
> > attempt of connecting to a WEP access point?
>
> ipw0: flags=8843 mtu 1500
> lladdr 00:0c:f1:1f:b2:a0
> index 1 priority 4 llprio 3
> groups: wlan
> media: IEEE802.11 autoselect (DS11 mode 11b)
> status: active
> ieee80211: nwid westernesse chan 2 bssid 94:0c:6d:f7:a4:9c -61dBm
> nwkey
>
>
> then I run dhclient
>
> ieee80211 on ipw0:
> 0 input packets with bad version
> 0 input packets too short
> 0 input packets from wrong bssid
> 0 input packet duplicates discarded
> 0 input packets with wrong direction
> 0 input multicast echo packets discarded
> 0 input packets from unassociated station discarded
> 0 input encrypted packets without wep/wpa config discarded
> 0 input unencrypted packets with wep/wpa config discarded
> 0 input wep/wpa packets processing failed
> 0 input packet decapsulations failed
> 2 input management packets discarded
> 0 input control packets discarded
> 0 input packets with truncated rate set
> 0 input packets with missing elements
> 0 input packets with elements too big
> 0 input packets with elements too small
> 0 input packets with invalid channel
> 3 input packets with mismatched channel
> 0 node allocations failed
> 0 input packets with mismatched ssid
> 0 input packets with unsupported auth algorithm
> 0 input authentications failed
> 0 input associations from wrong bssid
> 0 input associations without authentication
> 0 input associations with mismatched capabilities
> 0 input associations without matching rates
> 0 input associations with bad rsn ie
> 0 input deauthentication packets
> 0 input disassociation packets
> 0 input packets with unknown subtype
> 0 input packets failed for lack of mbufs
> 0 input decryptions failed on crc
> 0 input ahdemo management packets discarded
> 0 input packets with bad auth request
> 0 input eapol-key packets
> 0 input eapol-key packets with bad mic
> 0 input eapol-key packets replayed
> 0 input packets with bad tkip mic
> 0 input tkip mic failure notifications
> 0 input packets on unauthenticated port
> 0 output packets failed for lack of mbufs
> 0 output packets failed for no nodes
> 0 output packets of unknown management type
> 0 output packets on unauthenticated port
> 1 active scan started
> 0 passive scans started
> 0 nodes timed out
> 0 failures with no memory for crypto ctx
> 0 ccmp decryption errors
> 0 ccmp replayed frames
> 0 cmac icv errors
> 0 cmac replayed frames
> 0 tkip icv errors
> 0 tkip replays
> 0 pbac errors
> 0 HT negotiation failures because peer does not support MCS 0-7
> 0 HT negotiation failures because we do not support basic MCS set
> 0 HT negotiation failures because peer uses bad crypto
> 0 HT protection changes
> 0 new input block ack agreements
> 0 new output block ack agreements
> 0 input frames below block ack window start
> 0 input frames above block ack window end
> 0 input block ack window slides
> 0 input block ack window jumps
> 0 duplicate input block ack frames
> 0 expected input block ack frames never arrived
> 0 input block ack window gaps timed out
> 0 input block ack agreements timed out
> 0 output block ack agreements timed out
>
>
> The two "suspect" values im my humble opinion are:
> 2 input management packets discarded
> 3 input packets with mismatched channel
>
> Riccardo
>
My best guess is that because ipw doesn't bother with calling into
the net80211 newstate function, the interface's link state is never
updated and packets cannot flow. With WPA, link state gets updated
as a side-effect of a successful WPA handshake.
Does this fix it?
diff 1ff4cf56fdff3473d72fc4b29d69428c688d47c6 /usr/src
blob - ab16cd51ba6a2efdf89ac588801a1ae2bc714ed5
file + sys/dev/pci/if_ipw.c
--- sys/dev/pci/if_ipw.c
+++ sys/dev/pci/if_ipw.c
@@ -679,7 +679,11 @@ int
ipw_newstate(struct ieee80211com *ic, enum ieee80211_state nstate, int arg)
{
struct ipw_softc *sc = ic->ic_softc;
+ struct ifnet *ifp = >ic_if;
+ if (LINK_STATE_IS_UP(ifp->if_link_state))
+ ieee80211_set_link_state(ic, LINK_STATE_DOWN);
+
switch (nstate) {
case IEEE80211_S_SCAN:
task_add(systq, >sc_scantask);
@@ -690,6 +694,14 @@
Re: Injecting an environment variable in service
On Wed, Mar 17 2021 at 11:08:35 +0100, Antoine Jacoutot wrote: On Wed, Mar 17, 2021 at 09:57:45AM +0100, Ruben Vestergaard wrote: Hi list, Is there a general way of injecting an environment variable into an rc managed service? I need Smokeping to pick up the HTTPS_CA_FILE variable, but there seems to be no obvious way to set it. I guess I could modify the system scripts, but is there a cleaner, obvious way I have missed? Sure, you can create a login class that matches the rc.d script name and add the env var in it. e.g. login.conf entry smokeping:\ :setenv=HTTPS_CA_FILE=foo:\ :tc=daemon: Brilliant, just what I was looking for! Thanks! FYI you have an example in the smokeping package README. So there is indeed. *redface.wav* Cheers, -R -- Antoine
Re: Injecting an environment variable in service
On Wed, Mar 17, 2021 at 09:57:45AM +0100, Ruben Vestergaard wrote: > Hi list, > > Is there a general way of injecting an environment variable into an rc > managed service? I need Smokeping to pick up the HTTPS_CA_FILE variable, but > there seems to be no obvious way to set it. > > I guess I could modify the system scripts, but is there a cleaner, obvious > way I have missed? Sure, you can create a login class that matches the rc.d script name and add the env var in it. e.g. login.conf entry smokeping:\ :setenv=HTTPS_CA_FILE=foo:\ :tc=daemon: FYI you have an example in the smokeping package README. -- Antoine
Injecting an environment variable in service
Hi list, Is there a general way of injecting an environment variable into an rc managed service? I need Smokeping to pick up the HTTPS_CA_FILE variable, but there seems to be no obvious way to set it. I guess I could modify the system scripts, but is there a cleaner, obvious way I have missed? Thanks! -R
