Re: Xorg blanks until I switch to a TTY and back on 6.5
On Mon, Apr 29, 2019 at 05:05:25PM +1000, Jonathan Gray wrote:
> On Sun, Apr 28, 2019 at 07:26:54PM -0400, Charles wrote:
> > Hello list,
> >
> > Ever since the new inteldrm driver got merged into -current, shortly
> > before the 6.5 release, I'm seeing an odd new behavior on my Thinkpad
> > T430 -- when an external display is connected, Xorg blanks all screens
> > (but the mouse can still be seen) until I switch to a TTY and back with
> > (i.e. C-A-F4 then C-A-F5) after which point it goes back to normal.
> >
> > I'm glad the new inteldrm driver got merged, since it fixes several
> > other video issues I was having. This problem is very minor since the
> > workaround is just a few extra keystrokes when I dock or undock, but it
> > is nevertheless annoying.
> >
> > Is anyone else experiencing this issue on third gen core-I series Intel
> > chips with integrated graphics? Or on any other chips for that matter?
> >
> > I checked Xorg.0.log and didn't see anything suspicious. I also tried
> > disabling monitor hotplugging via Xorg.conf, but I either did it wrong
> > or it had no effect.
> >
> > I would attach xorg logs and dmesg, but AFAIK misc@ does not allow
> > attachments, and I don't want to annoy people with that much inline
> > info.
>
> Does this help?
>
> Index: sys/dev/pci/drm/drm_fb_helper.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_fb_helper.c,v
> retrieving revision 1.13
> diff -u -p -r1.13 drm_fb_helper.c
> --- sys/dev/pci/drm/drm_fb_helper.c 14 Apr 2019 10:14:51 - 1.13
> +++ sys/dev/pci/drm/drm_fb_helper.c 29 Apr 2019 06:58:25 -
> @@ -575,6 +575,9 @@ static bool drm_fb_helper_is_bound(struc
> #ifdef notyet
> if (READ_ONCE(dev->master))
> return false;
> +#else
> + if (!SPLAY_EMPTY(>files))
> + return false;
> #endif
>
> drm_for_each_crtc(crtc, dev) {
This appears to have done the trick. I tested with two displays that
were affected by the originally noted issue. I will continue running
with this patch for a while and report back if the issue re-appears, or
there are other relevant developments.
Thank you for the patch.
~ Charles
Re: 6.5 auto_install fails due to custom /var/tmp?
On 2019-04-30, Lyndon Nerenberg wrote: >> Sadly, no :-( >> >> But I should be able to accomplish what I need using rc.firsttime and >> a tiny bit of hackery. > > Sadly, no :-( > > What I was aiming for was to have the newly installed machines come > up with a 2GB MFS /tmp and a ~20GB /var/tmp. But MFS /tmp really > needs help in the system boot scripts. > > The critical part for us is that /var/tmp not overwhelm /var, and > we can get that with the current scheme by sizing /tmp accordingly. > > --lyndon > > My "workaround" when I've run into this during upgrades has been to ditch the MFS /tmp and mount my previous /var/tmp partition there instead. If MFS was actually fast then doing this would make me sad, but it isn't really, and sd0 is often on SSD these days...
Re: 6.5 auto_install fails due to custom /var/tmp?
Paul de Weerd wrote: > On Tue, Apr 30, 2019 at 01:29:47PM -0700, Lyndon Nerenberg wrote: > | > Sadly, no :-( > | > > | > But I should be able to accomplish what I need using rc.firsttime and > | > a tiny bit of hackery. > | > | Sadly, no :-( > | > | What I was aiming for was to have the newly installed machines come > | up with a 2GB MFS /tmp and a ~20GB /var/tmp. But MFS /tmp really > | needs help in the system boot scripts. > > Why? I've been running with MFS /tmp for *years* on several machines. > > This indeed required some changes when /var/tmp was changed into a > symlink to /tmp, but that was really no issue at all. > > There's very little difference between a /tmp on disk and a /tmp in > RAM (through mfs): both get mounted during boot at the same time. > > [weerd@pom] $ grep /tmp /etc/fstab > swap /tmp mfs rw,nodev,noatime,async,nosuid,-s=8388608 > [weerd@pom] $ df -h /tmp > Filesystem SizeUsed Avail Capacity Mounted on > mfs:12547 3.9G227M3.5G 6%/tmp > > | The critical part for us is that /var/tmp not overwhelm /var, and > | we can get that with the current scheme by sizing /tmp accordingly. > > Having /var/tmp not overwhelm /var is accomplished by having /var/tmp > symlink to /tmp (assuming /var and /tmp are on separate filesystems). > If you need more room in /var/tmp then you want to assign to your MFS > /tmp, then you need a different solution - but that's probably > something that can also be solved in a different way (don't use > /var/tmp for temporary storage, but another (dedicated) location for > whatever needs to write so much there). What hasn't been mentioned is why /var/tmp was made into a symbolic link to /tmp. Is your /var/tmp a seperate filesystem? Can I have a temporary account to demonstrate the consequences of filling /var?
Re: 6.5 auto_install fails due to custom /var/tmp?
On Tue, Apr 30, 2019 at 01:29:47PM -0700, Lyndon Nerenberg wrote: | > Sadly, no :-( | > | > But I should be able to accomplish what I need using rc.firsttime and | > a tiny bit of hackery. | | Sadly, no :-( | | What I was aiming for was to have the newly installed machines come | up with a 2GB MFS /tmp and a ~20GB /var/tmp. But MFS /tmp really | needs help in the system boot scripts. Why? I've been running with MFS /tmp for *years* on several machines. This indeed required some changes when /var/tmp was changed into a symlink to /tmp, but that was really no issue at all. There's very little difference between a /tmp on disk and a /tmp in RAM (through mfs): both get mounted during boot at the same time. [weerd@pom] $ grep /tmp /etc/fstab swap /tmp mfs rw,nodev,noatime,async,nosuid,-s=8388608 [weerd@pom] $ df -h /tmp Filesystem SizeUsed Avail Capacity Mounted on mfs:12547 3.9G227M3.5G 6%/tmp | The critical part for us is that /var/tmp not overwhelm /var, and | we can get that with the current scheme by sizing /tmp accordingly. Having /var/tmp not overwhelm /var is accomplished by having /var/tmp symlink to /tmp (assuming /var and /tmp are on separate filesystems). If you need more room in /var/tmp then you want to assign to your MFS /tmp, then you need a different solution - but that's probably something that can also be solved in a different way (don't use /var/tmp for temporary storage, but another (dedicated) location for whatever needs to write so much there). Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: 6.5 auto_install fails due to custom /var/tmp?
> Sadly, no :-( > > But I should be able to accomplish what I need using rc.firsttime and > a tiny bit of hackery. Sadly, no :-( What I was aiming for was to have the newly installed machines come up with a 2GB MFS /tmp and a ~20GB /var/tmp. But MFS /tmp really needs help in the system boot scripts. The critical part for us is that /var/tmp not overwhelm /var, and we can get that with the current scheme by sizing /tmp accordingly. --lyndon
Re: 6.5 auto_install fails due to custom /var/tmp?
Nick Holland writes: > normally, /var/tmp is a symlink to /tmp. > It can't make the link. No surprise. > Answer "Yes" to the "Continue anyway?" prompt, and all will be fine, I > believe. Sadly, no :-( But I should be able to accomplish what I need using rc.firsttime and a tiny bit of hackery. --lyndon
Re: Upgrading a CARP firewall cluster
mabi writes: > Now I would first like to upgrade the cluster to 6.4 and then to 6.5 and was > wondering if it is possible to operate that cluster for a short amount of tim > e having one node running 6.3 and the other node with 6.4 and then the same f > or going to 6.4 to 6.5. In general this is not a problem. We run several carp-ed firewall (and load balancer/proxy) pairs, and upgrade them in this manner. As was already mentioned, always read the release notes to look for carp or pfsync changes that might cause trouble. On our systems, we run the 'a' machine as primary and the 'b' machine as backup. When upgrading, we do the 'b' machine first, since this doesn't disrupt the primary. After the 'b' machine is fully configured, monitor its state table to ensure it's consistent with the 'a' machine. Once you are convinced pf is staying in sync, demote the 'a' machine and upgrade it. Make sure you have 'net.inet.carp.preempt=1' in /etc/sysctl.conf, and set advskew appropriately on each host in the pair. --lyndon
Re: Upgrading a CARP firewall cluster
mabi(m...@protonmail.ch) on 2019.04.30 08:21:43 +: > Hello, > > I have an OpenBSD 6.3 firewall cluster made out of two nodes (one master, one > backup) using CARP and pfsync. This cluster also makes use of trunk and vlan > interfaces. > > Now I would first like to upgrade the cluster to 6.4 and then to 6.5 and was > wondering if it is possible to operate that cluster for a short amount of > time having one node running 6.3 and the other node with 6.4 and then the > same for going to 6.4 to 6.5. > > Is this safe? or could there be any incompatibilities in carp/pfsync which > would prevent me to do that upgrade in two steps while keeping everything > online? > > Cheers, > Mabi This is only a problem when we change the protocols involved, and that would be mentioned in the upgrade guide. Since there were no protocol changes to carp(4) or pfsync(4) between 6.3 and 6.5, you should not have a problem with this upgrade. In fact, you could go 63 -> 64 -> 65 on one firewall while the other stays on 63. /Benno
Re: 6.5 auto_install fails due to custom /var/tmp?
On Mon, 29 Apr 2019 21:18:04 -0400 Nick Holland wrote: > normally, /var/tmp is a symlink to /tmp. > It can't make the link. No surprise. Since 5.7: http://openbsd-archive.7691.n7.nabble.com/5-7-installer-tar-Unable-to-remove-directory-td277040.html Cheers, -- Craig Skinner | http://linkd.in/yGqkv7
Re: Upgrading a CARP firewall cluster
‐‐‐ Original Message ‐‐‐ On Tuesday, April 30, 2019 11:20 AM, Igor Podlesny wrote: > CARP should be of no worries at all and PF state table's sync is > easily verified. > If after backup's upgrade-reboot it has roughly same amount of entries > you can safely demote master and repeat procedure. > Even if there were some major differences maximum what you could loose > is connections state table. Thank you Igor for the details. As you mention it doesn't really matter much if the connection state table gets lost in the worst case.
Re: Upgrading a CARP firewall cluster
On Tue, 30 Apr 2019 at 15:24, mabi wrote: [...] > Is this safe? or could there be any incompatibilities in carp/pfsync which > would prevent me to do that upgrade in two steps while keeping everything > online? CARP should be of no worries at all and PF state table's sync is easily verified. If after backup's upgrade-reboot it has roughly same amount of entries you can safely demote master and repeat procedure. Even if there were some major differences maximum what you could loose is connections state table. -- End of message. Next message?
Upgrading a CARP firewall cluster
Hello, I have an OpenBSD 6.3 firewall cluster made out of two nodes (one master, one backup) using CARP and pfsync. This cluster also makes use of trunk and vlan interfaces. Now I would first like to upgrade the cluster to 6.4 and then to 6.5 and was wondering if it is possible to operate that cluster for a short amount of time having one node running 6.3 and the other node with 6.4 and then the same for going to 6.4 to 6.5. Is this safe? or could there be any incompatibilities in carp/pfsync which would prevent me to do that upgrade in two steps while keeping everything online? Cheers, Mabi
GIVE UP: Re: SOLVED: Re: No more KDE's dolphin after upgrade to 6.5
On 4/29/19 10:48 AM, Federico Giannici wrote: On 4/26/19 9:47 PM, Rafael Sadowski wrote: It looks like you mixed packages for 6.4 and 6.5 and/or -current. Another try: run "pkg_add -X" to remove all your installed packages and install step by step what you need! I tried that but didn't worked. Anyway I found the problem with both dolphin and konsole: I think it was caused by the change in version numbering of the "private" libraries. In my system there were still around the 6.3 libraries (version 51): -rw-r--r-- 1 root bin 1821661 Oct 12 2018 libdolphinprivate.so.51.0 -rw-r--r-- 1 root bin 1806868 Mar 28 2018 libkonsoleprivate.so.51.0 alongside the new ones, but with "0" version: -rw-r--r-- 1 root bin 1720320 Apr 15 01:17 libdolphinprivate.so.0.1 -rw-r--r-- 1 root bin 1872672 Apr 14 20:12 libkonsoleprivate.so.0.0 As soon I removed the old ones, both dolphin and konsole worked! Maybe it could be useful for other users to add a note in the upgrade guide to 6.5? Now, I still have some problems with dolphin, but that is another story that I have to investigate more... Thanks Anyway, I finally had to give up! Even if I was then able to run both konsole and dolphin, they were unusable. Eventually, I have done a complete FRESH NEW Install (no Upgrade) to 6.5 (amd64), but all problems remained: a lot of kactivities crashes, dolphin usually starts only once and then usually freezes, okular randomly freezes too, etc, etc... I repeat: all this happened with a NEW Installation, even with a FRESH home directory. So, I had to do a NEW Installation of 6.4 and now everything work perfectly. Now the question is: is there something bad in my PC (or in the installation I have done) or I'm not the only one experiencing this and there are some problems with the switch to the KDE KF5 apps? Thanks.
