• 0 Posts
  • 110 Comments
Joined 1 year ago
cake
Cake day: November 7th, 2023

help-circle


  • Yeah, thanks, that comic was a little too black and white in 50% of the panels - acknowledging women’s rights and their role in society and abolishing child labor doesn’t mean that we did not process the shit out of food and invented the unholiest abominations as substitute for actual nourishment, or that it’s suddenly healthy to live in a concrete block after spending 10 hours in cloned cubicle #7.








  • An interrupt is an input that can be triggered to interrupt normal execution. It is used for e. g. hardware devices to signal the processor something has happened that requires timely processing, so that real-time behavior can be achieved (for variable definitions of real-time). Interrupts can also be triggered by software, and this explanation is a gross oversimplification, but that information is what is most likely relevant and interesting for your case at this point.

    The commands you posted will sort the interrupts and output the one with the highest count (via head -1), thereby determining the interrupt that gets triggered the most. It will then disable that interrupt via the user-space interface to the ACPI interrupts.

    One of the goals of ACPI is to provide a kind of general hardware abstraction without knowing the particular details about each and every hardware device. This is facilitated by offering (among other things), general purpose events - GPEs. One of these GPEs is being triggered a lot, and the processing of that interrupt is what causes your CPU spikes.

    The changes you made will not persist after a reboot.

    Since this is handled by kworker, you could try and investigate further via the workqueue tools: https://github.com/torvalds/linux/tree/master/tools/workqueue

    In general, Linux will detect if excessive GPEs are generated (look for the term “GPE storm” in your kernel log) and stop handling the interrupts by switching to polling. If that happens, or if the interrupts are manually disabled, the system might not react to certain events in a timely manner. What that means for each particular case depends on what the interrupts are being responsible for - hard to tell without additional details.







  • Granite counter tops also rest on a sturdy base, the caulk used to attach them doesn’t have to resist a lot of force trying to push the slab around, the caulk is mostly there to prevent liquids spilling into the cabinets and to provide a decent appearance. Yes, the caulk also somewhat attaches the slab, but keep in mind how hard it is to move to begin with, given the weight of the counter top.

    Here, the weight of the glass door pulls the panel out of the rails via the hinges. Silicone won’t provide a lasting solution.


  • I can only confirm what ballskicker and Shadow said - I’d remove the old caulk both mechanically and with the help of a solvent and then caulk it back in.

    However, I’m also pretty sure it will eventually sag again without the help of a retaining mechanism.

    Given the pictures you posted (which might not provide the full context), I assume someone really just caulked a glass panel into the profiles and left it at that. I assume you would like to avoid drilling the glass (can be done, but is tricky and has the potential to create a mess pretty quickly), so I’d simply manufacture a retaining cap that closes off the profile and holds the glass panel in place. I’d drill a hole into the ceiling to hold the cap in place, or into the profile, depending on the material and the remaining situation at hand.

    I’m talking about mounting that right here, after sliding the glass back in / caulking, of couse: