You are not logged in.
Do you have a spare cable?
I currently do not have one but my friend said he could borrow me one. I will not be able to get it today but within the next few days.
And my win 11 vm just broke ... I can't believe it. I have done a shutdown and update and it boots into system repair
Its probably because I have changed the corecount and then updated.
Because I accidentally gave it all of my cores at first and didn't want to cause harm for my hardware.
Last edited by snow1 (2024-10-18 14:23:57)
Offline
Ideally it's an "Ultra high speed" cable, the symptoms sound like a signal issue and the windows driver might use some color compression to still get the 165Hz through?
Either way, have you properly tried 144Hz (which would be just outside 340MHz)
Offline
Ideally it's an "Ultra high speed" cable, the symptoms sound like a signal issue and the windows driver might use some color compression to still get the 165Hz through?
Either way, have you properly tried 144Hz (which would be just outside 340MHz)
Okay
I have also tried 144 hz properly but it was not differnt from 165 hz both OCD and xrandr show 120hz.
Offline
And my win 11 vm just broke ... I can't believe it. I have done a shutdown and update and it boots into system repair
Its probably because I have changed the corecount and then updated.
Do you maybe have any suggestion on what is the best way of passing a whole nvme device to the windows host?
I have done it by passing through a Partition on the device by Partuuid.
Because after the Windows installation the uuid changes but partuuid stays the same. And I keep all of the performance.
Is there any better way of doing it? I just do not want to waste more time setting up vms which aren't a good setup or aren't long lasting, stable.
Or should I rather open a new discussion for this?
Actually I do not want to bother you with different topics I will create a new one.
Last edited by snow1 (2024-10-18 15:10:57)
Offline
By ID or device name (nvme*, but that's unstable across boots) but that'd better be a new topic.
I have also tried 144 hz properly but it was not differnt from 165 hz both OCD and xrandr show 120hz.
Hold on, but you said when actually using the --output, the monitor went blank for 165Hz?
Offline
By ID or device name (nvme*, but that's unstable across boots) but that'd better be a new topic.
Okay but thanks
Hold on, but you said when actually using the --output, the monitor went blank for 165Hz?
without the --output nothing happened with 120, 140 just like with the 165 hz.
(--> like absolutely nothing, no change of rate and no monitor sleep mode)
And with the output specified the screen goes blank and into sleep mode not returning to the desktop regardless of it being 144 or 165.
But with --output HDMI-0 it does change to 120 hz from 60.
sorry for confusion.
Or what exactly do you mean by properly?
Last edited by snow1 (2024-10-18 15:10:35)
Offline
Or what exactly do you mean by properly?
with --output HDMI-0
Try the replacement cable, the handshake likely fails for the signal being to poor.
Offline
sorry for confusion.
Wait now I know what I typed. I always had the --output specified.
But I also added "--mode 1920x1080".
I just tried it again and "xrandr --output HDMI-0 --rate 120" or with 144 or 165 do nothing.
If I type only "xrandr --rate 165" it gives me an error, makes sense, because there is nothing the option could be set on...
I think my brain is completely fried...
Every time I said i left out the output option I actually left out the "--mode 1920x1080"
Now I also understand what you meant by that:
Hold on, but you said when actually using the --output, the monitor went blank for 165Hz?
-------------------------------------------------------------------------------------------------------------------------------------------
So now what I actually typed:
-------------------------------------------------------------------------------------------------------------------------------------------
xrandr --output HDMI-0 --rate 144
does absolutely nothing for no matter what I type as refreshrate
-------------------------------------------------------------------------------------------------------------------------------------------
xrandr --output HDMI-0 --mode 1920x1080 --rate 120
Monitor goes blank for a few seconds, then returns with correct refreshrate of 120hz.
-------------------------------------------------------------------------------------------------------------------------------------------
xrandr --output HDMI-0 --mode 1920x1080 --rate 144
xrandr --output HDMI-0 --mode 1920x1080 --rate 165
gives me a blank screen and monitor goes into sleep mode, doesn't return to displaying anything
-------------------------------------------------------------------------------------------------------------------------------------------
I am so stupid...
Sorry for wasting your time.
I copied the commands once then just pressed arrow up and changed the rate.
I have just been thinking about this every day for like 5 days...
But now it should be clear what I did and what followed.
Regardless I will see when I get the other cable from my friend.
The one he has is a "ultra high speed"
Last edited by snow1 (2024-10-18 19:12:11)
Offline
Try the replacement cable, the handshake likely fails for the signal being to poor.
I have tried changing it again today using the "ultra high speed" HDMI cable from my friend, but it still doesn't work
Xrandr still gives the same results as with the other cable.
May the handshake actually be interrupted by the GPUs power source and not the HDMI cables signal being poor?
Offline
If anything, the output would not be capable of generating the signal at all - but that doesn't fit the windows description (or nvidias reputation)
You're not currently running nvidia-open, are you?
You could try https://aur.archlinux.org/packages/nvidia-535xx-dkms in case this is a weird driver regression, but rn I cannot come up with a sane explanation as to why things would fail (the cable would be a natural contender)
Offline
You're not currently running nvidia-open, are you?
No I am not running the nvidia-open driver, but the driver from the standard nvidia package.
I will also try the other one you suggested.
Offline
You could try https://aur.archlinux.org/packages/nvidia-535xx-dkms in case this is a weird driver regression, but rn I cannot come up with a sane explanation as to why things would fail (the cable would be a natural contender)
The 535 dkms drivers actually work xD.
I can set my rate to 144 and 165 just like to 120 hz.
There is only one issue. It only works for me on lts kernel.
If I use the standard arch linux kernel it gives me the error:
$ journalctl -xe | grep nvidia
systemd-modules-load[350]: Failed to find module 'nvidia-uvm'
Does that have to do with the dkms driver being made for custom kernels or did I just install it incorrectly?
I installed these packages from AUR:
nvidia-535xx-dkms
nvidia-535xx-utils
lib32-nvidia-535xx-utils
Last edited by snow1 (2024-10-23 11:14:40)
Offline
You need the headers of every kernel you want dkms support for
pacman -Qs headers
dkms status
But I'm also not 100% sure at hand whether 535xx builds against 6.11 (you'd get dkms building errors)
To be clear: 560xx on the LTS kernel does NOT work?
Main differences (besides the driver version) are prime-sync support (but you don't have an optimus system, do you?) and that nvidia_drm.fbdev defaults to "1" intead of "0" on 560xx (but we tested that, didn't we?)
Offline
dkms status:
nvidia/535.183.01, 6.6.57-1-lts, x86_64: installed
pacman -Qs headers
local/acl 2.3.2-1
Access control list utilities, libraries and headers
local/libcups 2:2.4.11-1
OpenPrinting CUPS - client libraries and headers
local/linux-api-headers 6.10-1
Kernel headers sanitized for use in userspace
local/linux-lts-headers 6.6.57-1
Headers and scripts for building modules for the LTS Linux kernel
local/spice-protocol 0.14.4-2
Headers for SPICE protocol
local/vulkan-headers 1:1.3.295-1 (vulkan-devel)
Vulkan header files
local/xorgproto 2024.1-2
combined X.Org X11 Protocol headers
No 560xx didn't work on lts.
I am not using an optimus system.
There are 2 more things I did aswell which I forgot mentioning.
I removed the
nvidia-drm.modeset=1
parameter from my /etc/default/grub
I think there was also an error when regenerating my initramfs about the nvidia-drm modeset option after installing the 535xx driver, that was reason I removes that.
and in /etc/modprobe.d/nvidia-drm-nomodeset.conf
I commented out the contents, as I think I had set it up manually before when trying to fix the problem.
I had the nomodeset config file but i also had modesetting enabled in grub through the nvidia-drm.modeset=1?
May that have caused the issues or was it just overwritten by either one?
I have not tried adding the modeset option or the nomodeset config back, as it works now (on lts).
And I just fried the arch system on my laptop because the battery died while the laptop was on and updating...
Everything is happening now... But that doesn't really have to do anything with my pc except for me being unable to ssh currently. sorry for distraction
Last edited by snow1 (2024-10-23 17:18:21)
Offline
YOu lack linux-headers if you want to build the 535xx drivers for the "normal" linux kernel.
I think there was also an error when regenerating my initramfs about the nvidia-drm modeset option after
I don't think mkinitcpio cares all that much unless you're building UKIs which is unlikely when you're using grub.
Check again and return the parameter.
Offline
YOu lack linux-headers if you want to build the 535xx drivers for the "normal" linux kernel.
Yes now it works
I don't think mkinitcpio cares all that much unless you're building UKIs which is unlikely when you're using grub.
Check again and return the parameter.
In this case I do not know why I removed it xD. But regardless it works now.
Thanks a lot for your time and effort helping me to resolve the problem and the explaination
I really respect that you guys are helping people with their arch linux systems voluntarily.
Hopefully the community will grow further.
I wish you all the best and have a nice evening.
Last edited by snow1 (2024-10-23 20:49:49)
Offline
Main differences (besides the driver version) are prime-sync support (but you don't have an optimus system, do you?) and that nvidia_drm.fbdev defaults to "1" intead of "0" on 560xx (but we tested that, didn't we?)
I also tried to add the nvidia_drm.fbdev=1 or nvidia_drm.fbdev=0 parameters on the 535xx but it didn't make a difference.
So that probably wasn't the reason for the problems.
Offline