I’m facing repeated system hangs/crashes since some weeks. Therefore I think the problem came with an update … but which one?
journalctl --catalog --priority=3 --boot=-1
Jan 27 10:13:02 catweazle kernel: ACPI BIOS Error (bug): Failure creating named object [\_SB.SMIC], AE_ALREADY_EXISTS (20230628/dswload2-326)
Jan 27 10:13:02 catweazle kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20230628/psobject-220)
Jan 27 10:13:02 catweazle kernel: ACPI BIOS Error (bug): Failure creating named object [\_SB.SMIB], AE_ALREADY_EXISTS (20230628/dsfield-637)
Jan 27 10:14:50 catweazle lightdm[1383]: gkr-pam: unable to locate daemon control file
Jan 27 10:14:52 catweazle pulseaudio[1514]: GetManagedObjects() failed: org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer 'org.bluez': unit failed
Jan 27 10:48:41 catweazle kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring comp_1.2.0 timeout, signaled seq=18133, emitted seq=18135
Jan 27 10:48:41 catweazle kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xorg pid 1265 thread Xorg:cs0 pid 1302
Jan 27 10:49:47 catweazle kernel: INFO: task kworker/4:0H:34 blocked for more than 122 seconds.
Jan 27 10:49:47 catweazle kernel: Tainted: G OE 6.6.74-1-MANJARO #1
Jan 27 10:49:47 catweazle kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 27 10:49:47 catweazle kernel: INFO: task kworker/3:0H:52 blocked for more than 122 seconds.
Jan 27 10:49:47 catweazle kernel: Tainted: G OE 6.6.74-1-MANJARO #1
Jan 27 10:49:47 catweazle kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 27 10:49:47 catweazle kernel: INFO: task kworker/3:1H:144 blocked for more than 122 seconds.
Jan 27 10:49:47 catweazle kernel: Tainted: G OE 6.6.74-1-MANJARO #1
Jan 27 10:49:47 catweazle kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 27 10:49:47 catweazle kernel: INFO: task kworker/4:2H:1398 blocked for more than 122 seconds.
Jan 27 10:49:47 catweazle kernel: Tainted: G OE 6.6.74-1-MANJARO #1
Jan 27 10:49:47 catweazle kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 27 10:49:47 catweazle kernel: INFO: task kworker/0:3H:2452 blocked for more than 122 seconds.
Jan 27 10:49:47 catweazle kernel: Tainted: G OE 6.6.74-1-MANJARO #1
Jan 27 10:49:47 catweazle kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 27 10:49:47 catweazle kernel: INFO: task kworker/3:2H:3842 blocked for more than 122 seconds.
Jan 27 10:49:47 catweazle kernel: Tainted: G OE 6.6.74-1-MANJARO #1
Jan 27 10:49:47 catweazle kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 27 10:49:47 catweazle kernel: INFO: task kworker/3:3H:3843 blocked for more than 122 seconds.
Jan 27 10:49:47 catweazle kernel: Tainted: G OE 6.6.74-1-MANJARO #1
Jan 27 10:49:47 catweazle kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 27 10:51:50 catweazle kernel: INFO: task kworker/4:0H:34 blocked for more than 245 seconds.
Jan 27 10:51:50 catweazle kernel: Tainted: G OE 6.6.74-1-MANJARO #1
Jan 27 10:51:50 catweazle kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 27 10:51:50 catweazle kernel: INFO: task kworker/3:0H:52 blocked for more than 245 seconds.
Jan 27 10:51:50 catweazle kernel: Tainted: G OE 6.6.74-1-MANJARO #1
Jan 27 10:51:50 catweazle kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 27 10:51:50 catweazle kernel: INFO: task kworker/3:1H:144 blocked for more than 245 seconds.
Jan 27 10:51:50 catweazle kernel: Tainted: G OE 6.6.74-1-MANJARO #1
Jan 27 10:51:50 catweazle kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
If your Manjaro is located on this sdb6 partition then you’re running out of space (the system reserves 10% so you’re left with around 2-3GB free). Clean up the partition or increase the size of the partition.
While this is a valid concern, and likely to contribute greatly to these crashes you mention, I notice an inconsistency in your inxi output:
If /dev/sdb is your Manjaro installation, you have / and /boot partitions as expected with an MBR partition scheme – however, you also have a /boot/efi mountpoint to /dev/sdb1 – this infers a UEFI booting system; which obviously it can’t be, when using an MBR partition scheme.
I can’t explain how Calamares would have created this scenario.
Perhaps this is also contributing.
I note that the BIOS has not been updated – ever, by the look of it. If the following link reflects your mainboard, you might consider attending to this whenever convenient.
According to your inxi output BIOS F2 (2018-08-08) is currently used - there have been fifteen (15) BIOS update releases since then. The latest BIOS release in F66d and was made available on 2024-09-02.
Looking at the descriptions of the BIOS updates you have missed, it would be advisable to update as soon as may be practical. While doing so will not necessarily solve your immediate issue, it will likely solve problems you were not even aware of.
yes, this is the partition, where the OS resides. But I don’t think, 83% are a problem. I never have seen any “no space left on device” messages or similar. The system is running for years with this configuration. But you are right, enlarging the partition is certainly not a luxury.
There are extremely conflicting opinions on this topic. I recently bought a new motherboard (because I want to replace this system) - the manual explicitly states “never install a BIOS update if the system is running smoothly”.
Anyway - I’ll give it a try!
It happens when you have some OS (usually Windows) installed in BIOS mode and you install Manjaro in Uefi mode. (I think it happened to me once, and that forced me to learn the difference)
Edit:
While I can’t say I agree with the advice:
…do you not think repeated hangs/crashes is the system not running smoothly?
Yes, that used to be a common stance; I suppose too many users bricked their machines due to general inattention to instructions given by the respective board manufacturers.
Then again, that was a time when seeing more than a proverbial handful of BIOS updates in the lifetime of a product was rather uncommon.
of course, this might be a problem.
But - as mentioned - this is the first time in 6 … 7 years.
Therefore it was not my first suspicion and I have lately seen more systems crashing - even new systems with very much free space on disk and the newest BIOS update installed. The symptoms are not exactly the same, but very similar.
But of course that’s just my opinion - let’s just keep looking for the problem here!
I have enlarged the root partition in the meantime - I’ll take care of the BIOS tomorrow.
df -h /dev/sdb6
Filesystem Size Used Avail Use% Mounted on
/dev/sdb6 77G 41G 33G 56% /
Good morning!
Just finished the first BIOS upgrade F2 ->F4 … and - as expected - faced some “problems”. The system won’t boot any longer using UEFI, while BIOS boot works.
Maybe this comes from the odd partitioning table?
I tried to repair this using a Manjaro live-Stick. Re-installed grub (efi and BIOS) … but the efi variant still keeps on complaining ‘grub_is_lockdown’ not found …
Anyhow - BIOS boot is not optimal, but it works.
I’ll do further updates, but this will take a while.
I’m afraid there will rise more problems and … I’m not sure how to deal with BIOS versions F40 and above. The Gigabyte website states:
Note:
1. If you are using Q-Flash Utility to update BIOS, make sure you have updated BIOS to F32 before F40
2. Before update BIOS to F40, you have to install EC FW Update Tool (B19.0517.1 or later version) to avoid 4DIMM DDR incompatibility on 3rd Gen AMD Ryzen™ CPU
… but I don’t have any Windows installations to run this Tool.
I opened a call at the Gigabyte support to clarify this
I pretty much have that same morherboard and as @BG405 posted you need that CD to upgrade EC FW Update Tool.It is not that hard to do and after updating it using that CD I could update the bios to the latest stable verision of the bios which is now at F66.Yours maybe different but after every update of the bios my settings went back to default.
This is to be expected, as it is a new BIOS. Although those default settings are adequate for many people, if there are any specific customisations one is used to, then they would of course need to be tweaked again.
If multibooting Manjaro and Windows, for example, Secure Boot would again need to be disabled, and likely the Fast Boot BIOS option also, if it exists.
@straycat mentioned the latest stable BIOS – this is also an important distinction – while I mentioned earlier that F66d was the latest available, it is also a beta BIOS. The latest stable BIOS is indeed what you should aim for; currently F65. Typically, one should only use a beta BIOS if it addresses a specific problem experienced.
Edit:- Noted Stable BIOS version currently available.
I really hate to contradict the experts, but I can’t find an F66 version. There is F65, F66b and F66d - but no F66 (just double-checked this)
But that’s absolutely no problem!
I have now reached F32. Before proceeding with F40 and the thing with the firmware updater, I need to read through this at a quiet moment.
I downloaded the boot disk from Hiren - thanks for the tip @BG405 ! Otherwise I would have tried to build myself some kind of DOS … FreeDOS or similar.
The system is currently stable - I’ll keep an eye on it.
But the thing with the UEFI boot is really strange. Sometimes it works - but most of the time I get this weird error message from grub ‘grub_is_lockdown’ not found … whatever this means …
Thank you so far for all your patience and advices!
You’re correct; F66 will be the next stable BIOS, I imagine. The point of course was to avoid a beta BIOS in favour of the stable – in your case, that appears to be F65.
Maybe. I don’t recall whether I was influenced by your post, or simply made a typo; the focus wasn’t on the version in any case, it was more about avoiding the beta’s, so no harm done.
