It may appear to be an Xorg or lightdm/gdm/mdm error but in reality for many users with this issue, it's a driver conflict and issue. I had a system that had two GPUs, an Intel and Nvidia GPU.
The only thing that got it working was to remove the nouveau driver and blacklist it so it never came back, then the Intel GPU works fine without these issues.
Solution
sudo rmmod nouveau
add nouveau/other driver to blacklist
edit th........
This is a 8TB Seagate external USB 3.0 device apparently newer kernels use a module called "UAS" instead of "USB Storage" which causes issues as a lot of devices are not properly supported in UAS mode by the kernel driver. The solution some say is to disable UAS specifically for your USB device but I'd rather just disable UAS altogether.
Solution blacklist UAS: *do not do this it does not work and just causes your USB 3.0........
This happened while an mdadm array was syncing, all access from writing a new blank file to opening a small .txt file was very slow:
[222117.312078] kjournald starting. Commit interval 5 seconds
[222117.685060] EXT3-fs (md0): using internal journal
[222117.685096] EXT3-fs (md0): mounted filesystem with ordered data mode
[222122.376847] kjournald starting. Commit interval 5 seconds
[222122.602825] EXT3-fs (md2): using internal jour........
Linux box13. 2.6.32-042stab076.5 #1 SMP Mon Mar 18 20:41:34 MSK 2013 x86_64 x86_64 x86_64 GNU/Linux
even setting privvmpages to a specific setting DOES not affect "free -m" in containers.
This is probably a kernel issue
23:36:29 up 159 days, 7:12, 4 users, load average: 0.42, 0.44, 0.33
[root@box13 ~]# free -m
total&n........
This server was experiencing loads of up to 80 and maxing out the RAM and kmemsize on a CPanel VPS. There were literally dozens if not hundreds of exim processes. I have no idea why exim has such a design that would allow it to consume this much CPU and RAM. Any normal MTA should not be spawning so many processes, it should be processing them in sequence and if it is going to spawn hundreds of processes in response to a large volume of mail, it's better to have a delayed del........
cat /proc/user_beancounters produces the following:
kmemsize 1861537 5139870 12752512 12752512 26965041
Notice the failcnt "26965041", that is for kmemsize and at first it confused me. The system had enough guaranteed and enough burst RAM available. kmemsize is a variable indepedent of that, but who cars about the explanation right, let's just make thing........
A VPS Server I had just wasn't working right, code that I migrated there just wasn't working. For example, it kept telling me the connection to the database was unsuccessful, halfway through iterating through results it already had.
Then I realized it wasn't my code. Ichecked my /proc/user_beancounters and found this:
cat /proc/user_beancounters
Version: 2.5
uid resource held maxheld barrier limit failcnt........