abcdqfr

joined 5 months ago
[–] abcdqfr 7 points 2 weeks ago

Keep highlighting the issue.

[–] abcdqfr 1 points 2 weeks ago (4 children)

Holy shit when did this site turn into pure reddit?

[–] abcdqfr 2 points 2 weeks ago

Y'all type as well as you cook...

[–] abcdqfr 0 points 2 weeks ago

People who aren't dead inside, for aforementioned reasons

[–] abcdqfr 19 points 2 weeks ago (1 children)

No, you take the legs and let strong man take the shoulders. There's more weight on that end.

[–] abcdqfr 1 points 2 weeks ago

Tried F1-6, no love. Only thing that does respond is the mouse movement... keyboard only responds to input reisub. I think if I am at keyboard and the screen does not lock, any windows open will respond to mouse hover but not clicks... I need a linux doctor lol. Maybe a second display for outputting kernel logs, that would be fun for dev work. Though I feel like ssh is the defacto way to accomplish that... Anything we can accomplish with one host and two displays, no network?

Prompted GPT

It sounds like you're encountering a kernel-level or X/Wayland-level freeze while developing. The fact that the keyboard is unresponsive except for REISUB suggests a deep hang in the graphical session or related system processes.

Here’s a practical way to debug and diagnose this issue with two displays and one host, without needing a network:


Setup for Debugging on Two Displays

  1. Enable Persistent Kernel Logs on Second Display:

    • Use a TTY session on your second display to monitor kernel logs.
    • Connect your second display and switch to it using Ctrl+Alt+F2 (or F3-F6, depending on availability).
    • Login and run:
      sudo tail -f /var/log/kern.log
      
      or
      sudo dmesg -w
      
    • This will show you kernel logs in real time, which is often critical for diagnosing freezes.
  2. Mirror Logs or Virtual Console Across Displays:

    • If your second display doesn't switch TTYs independently, use a terminal multiplexer (like tmux or screen) to duplicate the kernel log view.
      • Start tmux in TTY1 and attach to it from TTY2:
        tmux
        tail -f /var/log/kern.log
        
        Then on the second TTY:
        tmux attach
        

Improve Debugging Workflow

  1. Set Up Magic SysRq for More Control:

    • If your system allows REISUB, the Magic SysRq key is already enabled. You can use other commands to debug live:
      • Sync and Kill Tasks: Alt + SysRq + F can attempt to kill resource-hogging processes.
      • Toggle TTY: Alt + SysRq + R can re-enable raw keyboard input if the GUI is frozen.
  2. Enable Kernel Debugging Outputs:

    • Append debug to your kernel boot parameters in GRUB:
      • Edit /etc/default/grub:
        GRUB_CMDLINE_LINUX_DEFAULT="quiet splash debug"
        
      • Update GRUB and reboot:
        sudo update-grub
        
    • This provides richer debugging output in logs.
  3. Use a Non-GUI Target:

    • For safer development, switch to a lower system target to prevent full GUI freezes:
      sudo systemctl set-default multi-user.target
      
      • Reboot into a non-GUI mode where you can manually start your app, making it easier to debug without freezing the entire desktop.
  4. Forcefully Isolate the Process:

    • Run your wallpaper application in a separate X server to isolate it:
      xinit /path/to/your/app -- :1
      
      • This starts a new X session on display :1 while keeping your primary desktop untouched.

Tips to Prevent GUI Freezes During Development

  • Limit CPU or Memory Usage:
    • Use ulimit to restrict resource usage of your program:
      ulimit -v 1048576  # Limit to 1GB virtual memory
      
  • Log Debugging Information:
    • Add debug prints in your app and log them to a file instead of stdout.

[–] abcdqfr 3 points 2 weeks ago (3 children)

My display manager keeps hanging during wallpaper engine development, never does respond to Ctrl+Alt+F2. Only REISUB seems to be able to save me. Never had anything borked or out of place after reboot. Any ideas? That still sound like the display driver crashing? Haven't done much diagnosing since I'd have to cludge through troubleshooting over SSH on Android at random :\

[–] abcdqfr 1 points 2 weeks ago

Do not use Windows :D

[–] abcdqfr 4 points 3 weeks ago (1 children)

Imagining muffled cackles from a chamber of dildos

[–] abcdqfr 3 points 3 weeks ago (1 children)

I highly recommend taking the time to really look into btrfs for anyone interested in utilizing timeshift. There is no going back.

[–] abcdqfr 1 points 3 weeks ago

Makeup MAKEUP What is this aneurysmposting?

 

Should I struggle through constant crashes to get my 7900gre with 16gb of vram working, possibly through the headache of ONNX? Can anyone report their own success or offer advice? AMD on linux is generally lovely, SD with AMD on linux, not so much. It was much better with my RTX2080 on linux but gaming was horrible with NVIDIA drivers. I feel I could do more with the 16GB AMD card if stability wasn't so bad. I currently have both cards running to the horror of my PSU. A1111 does NOT want to see the NVIDIA card, only the AMD. Something about the version of pytorch? More work to be done there.

  • Having a much better time back on Cinnamon default instead of Wayland. Oops!

** It heard me. Crashed again on an x/y plot but due to being away from Wayland I was able to see the terminal dump: amdgpu thermal overload! shutdown initiated! That'll do it! Finally something easy to fix. Wonder why thermal throttling isn't kicking in to control runaway? Will stress it once more and clock the temps this time.

Temps were exceeding 115C, phew! No idea why the default amdgpu driver has no fan control but they're ripping like they should now. Monitoring temps has restored system stability. Using multiple amd/nvidia dedicated venv folders and careful driver choice/installation were the keys to multigpu success.

 

So NVIDIA just doesn't cut it on Linux/proton I've come to learn. Looking at the best bang//buck, it this the AMD card people are flocking to? 7800 XT maybe?

view more: next ›