[Stable Update] 2016-11-25 - Plasma 5.8.4, VirtualBox 5.1.10, Linux 4.9-rc6, Gstreamer

No problems - thank you for another great update :slight_smile:

You can try This Solution There is a temporary trial as well as a make it permanent option. This person also references the same sort of fix.

Nvidia mentions these settings in passing on their release notes, without even hinting at why you might need them.

Hello caho
Thanks for the reply.
After I posted I realised I had made a mistake in the kernel version.

Apologies for the confusion caused by me.

cheers

1 Like

Unbelievable. This is the way I have done it for a long time already after I had mail contact with Nvidia's helpdesk and they gave me the tip. I have been promoting this on the mint forum and helped a lot of people that way. Now, with Manjaro, it didn't help anymore. I still have the line in my xorg.conf file, but it doesn't help.
I just tried the tip telling me to write the one line in a terminal and it did work now. How can it be, when I have the same solution in my xorg.conf file and that doesn't work?
I will now reboot to see if it still works but I fear the worst. I could however make some kind of script that will start at boot to make the tearing go away.
Thanks very much jsamyth.

No, it didn't. The tearing is back with just using my xorg.conf file. I will now start the script to see if that helps.

Yes, the line in the terminal was a temporary fix, guaranteed to go away upon reboot.

I wonder if taking the line out of xorg.conf is necessary? It clearly doesn't work any more, so this setting must be handled in a different place.

I don't have nvidia, so I'm fresh out of ideas here.

Yes, I realize it was a temporary fix, but I have the same line in my xorg.conf file. Why doesn't it work there anymore?
I just write the script and let it start at boot.

Thanks again.

Strange, now it works flawlessly, no more tearing. Must be a sign that the xorg.conf file is not read or the card doesn't do anything with it.
Is the location correct: /etc/X11?
It used to be correct with the distro's I have always used but maybe Manjaro / Arch is different.

Try this path: /etc/X11/xorg.conf.d/20-nvidia.conf ! :wink:

1 Like

Also that works great. Amazing.

Where can I find info/documentation about these type of things? I mean, there must be a source for it or how else would people, like yourself, know this?

This thread today has made my day.
Thank you all very much.

The Arch-Wiki is always a good address (if you cannot find what you need on the Manjaro Wiki)
https://wiki.archlinux.org/index.php/NVIDIA#NVIDIA_Settings

The wiki pages, of course.
Thanks again.

1 Like

No problem in update but sadly xfce4-terminal drop down mode is still broken and opens only on monitor 1.

No problem - it doesn´t matter.

regards
caho

I have this one to upgrade

manjaro-welcome
20161119-1
20161130-1

But the Sy returns with errors so I am going to leave it for now.

Correction-
pacman-mirrors -g
pacman -Syy
and we're good to go :slight_smile:

nice work gentlemen

Does this update contain the NVIDIA 375.20 drivers? Waiting on stable to setup Manjaro with a GTX 1050.

On my laptop, KDE didn't start up properly anymore.
I got a black screen right after login, but surprisingly yakuake still opened up normally.

I see only one error message in the logs, not sure if related:
kwin_x11: QXcbCOnnection: XCB error 3 (BadWindow)

It seems that kscreen is the culprit (once again): I removed it and everything is back to normal.

Slight hiccup, fixed by renaming files.
Otherwise, another excellent update :slight_smile:

(74/74) checking for file conflicts [###################] 100%
error: failed to commit transaction (conflicting files)
geoclue2: /usr/share/gtk-doc/html/geoclue/geoclue.devhelp2 exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/home.png exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/index.html exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/left.png exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/right.png exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/style.css exists in filesystem
geoclue2: /usr/share/gtk-doc/html/geoclue/up.png exists in filesystem
Errors occurred, no packages were upgraded.

Hi,

I know this is a little outdated but I just resolved a problem that started with this update. My Intel CPU is overclocked using the open muliplicator and disabled turbo mode. This updated installed a new version of intel-ucode, which broke something and forced the kernel to use the stock settings, no matter what I changed in my BIOS. With a downgrade of the intel-ucode from the current "20161104-1" back to the version "20160714-1" and everything is working again.

Now I'm curious, if Intel actually made a mistake there or if I broke something during this update (problem persisted with the most recent Manjaro Update from yesterday).

I'm using kernel 4.8.9 (4.8.8 at that time) and cpuinfo and /sys/devices/system/cpu/cpu*/cpufreq/scaling_* always showed the correct max/min cpu frequency. But for some reason the turbo mode was enabled when the new intel-ucode where installed, even though it is disabled in the BIOS.

If there is no quick answer to this problem, I can open a new thread and post more information + outputs, instead of keeping this one alive.

Regards,

I'm guessing that neither Manjaro nor Arch does anything with the microcode Intel ships other than make it available. It probably comes directly from Here.

It therefore seems highly unlikely you will find anyone here to blame or seek help from. You might use the Contact Support link on that page to find out why this happened.

They may have had reasons (perhaps even non-nefarious ones) for controlling the overclocking of your particular CPU. It might be to prevent a specific failure mode that came to light. (Hey, it COULD happen?!),

Forum kindly sponsored by