PaX [comrade/them, they/them]

Very tired nerd who loves to yap

Ask me about floppa, Plan 9, computer architecture, computational logic, anything computers really (if you want)

:cat-vibing:

If I don’t reply to you it’s probably cuz I’m too tired, sorry :(

  • 5 Posts
  • 29 Comments
Joined 3 years ago
cake
Cake day: July 15th, 2022

help-circle
  • PaX [comrade/them, they/them]@hexbear.nettoMemes@lemmy.mlThe myth of consensual peace
    link
    fedilink
    English
    arrow-up
    23
    arrow-down
    8
    ·
    edit-2
    27 days ago

    1915 Lemmy lib: “God the German propaganda on .ml is intense”

    The propaganda: Peace pls yes-honey-left

    Any info I encounter contrary to the interests of my preferred empire must be the work of the dastardly Foreigner. If the other side wanted peace they should simply unconditionally surrender imaginator (skull can barely contain brain of this size)

    And if they won’t, we Ukrainians must be willing to give up their lives in a total war until victory (which is going well and good and can be expected to end in that outcome)

    Russia’s terms have been quite clear since the beginning of the war: a neutral, non-West-aligned Ukraine and the official ceding of Crimea and the breakaway republics. Even regardless of how you feel about those issues, how does it benefit you or the average Ukrainian to keep fighting over this? It is such a pointless, devastating loss of life over shit that obviously represents larger geopolitical issues for the West and Russia while Ukraine is turned into a literal wasteland (omg and the Ukrainian side has been financed by massive Western loans doomer, even if Ukraine “wins” they are gonna be fucked when the creditors come for their repayments after the war which is intentional ofc, will probably result in even more IMF austerity plans and poverty)

    Idk, maybe the Ukrainian side could get better terms (they def could have earlier) but they have just refused to actually negotiate (beyond telling the world how “open” they to are it lol) and have taken your total victory position. Ofc there is so much more to say but yeh











  • The vast majority of drivers are included with the Linux kernel now (in tree) so the difference usually comes down to kernel version (newer kernels have more drivers, of course) or kernel configuration set at compile-time (this can be anything from including or not including drivers, to turning driver features on and off, or more fundamental changes beyond drivers)

    You can get kernel version info from uname -a and a lot of the time, probably most of the time (this is also down to configuration), you can get kernel configuration info from /proc/config.gz (use gzip -d to decompress) or something like /boot/config

    Then you can run diff on configurations of 2 different distro kernels you’re interested in to see how the 2 distribution’s kernels were set up differently

    This could also be caused by different setups of userspace tools or UI that interact with these drivers in different, sometimes worse ways but this is usually much less likely in my experience (most Linux distros do things like this the same way these days tbh)

    Oh, also, there are a lot of drivers that require vendor-supplied firmware or binary blobs to function and most of the time distros don’t bake these into the kernel (although it is possible) and different distros might have more or less of these blobs available or installed by default or they might be packaged differently. The kernel should print an error message if it can’t find blobs it needs though

    I guess there’s kinda a lot to consider lol. Sorry if all of this is obvious

    What hardware are you talking about specifically?






  • What motherboard do you have? Also what happens exactly when the lock-ups happen? Have you ever been playing audio when the lock-ups happen and does it loop or stop or keep playing?

    I recently had to “fix” (workaround) a similar issue in the OpenBSD kernel with a specific hardware peripheral on my PC (running a 2nd-gen Ryzen), the High Definition Audio controller. For whatever reason (and only when I was running OpenBSD) interrupts from the HDA controller (to let the CPU know to refill audio buffers) would just randomly stop making it to the CPU and audio would loop for a few seconds and then shut off. I spent a long time trying to figure out what causes it and reading Linux driver code but I couldn’t find a cause or why only OpenBSD would trigger it. I ended up having to write kind of a hacky polling mode into the HDA driver. My only guess is some of these AMD-chipset-having motherboards have faulty interrupt controllers.

    Maybe there is a similar issue with your system and timer interrupts aren’t making it to your CPU or something. But I’m not really an expert on PC architecture and idek if it even works like that on PCs lol

    Sorry for so many questions but do you also have any kernel logs available from when this happens?