[CLOSE/Unable to find cause]Random kernel panics without log's

seth · 2023-07-23 15:01:11

https://archlinux.org/packages/extra/any/nvidia-prime/
You're running a regular prime setup, did you mean that the performance w/ "nvidiarun" dropped?

Hubbleexplorer · 2023-07-23 15:03:04

seth wrote:

https://archlinux.org/packages/extra/any/nvidia-prime/
You're running a regular prime setup, did you mean that the performance w/ "nvidiarun" dropped?

Yes from changing the drivers, I'm not very concern by that because the pc hasn't crash in 2 days, so i call that a win.

Last edited by Hubbleexplorer (2023-07-23 15:25:03)

Hubbleexplorer · 2023-07-25 21:28:35

So after a few days, it start crashing again in driver version "nvidia 535.86.05-3", it's weird because i can't find other reports of this happening anywhere else.
Maybe if i have the time i will try the nuclear option, reinstall and configure my arch install from scratch to be sure that i have everything well configured.

seth · 2023-07-25 21:34:50

seth wrote:

Try a different SW stack.
If it happesn across various live-distros, chances of this being a software issue wither away…

Hubbleexplorer · 2023-07-28 23:13:15

seth wrote:

seth wrote:
Try a different SW stack.
If it happesn across various live-distros, chances of this being a software issue wither away…

Confirm it also crashes in fedora, now how do i find out what hardware problem do i have?
The final lines for a crash on fedora

Jul 29 01:19:22 hubble.Home firefox.desktop[3754]: libva info: VA-API version 1.18.0
Jul 29 01:19:22 hubble.Home firefox.desktop[3754]: libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
Jul 29 01:19:22 hubble.Home firefox.desktop[3754]: libva info: Found init function __vaDriverInit_1_18
Jul 29 01:19:22 hubble.Home firefox.desktop[3754]: libva info: va_openDriver() returns 0
Jul 29 01:19:23 hubble.Home firefox.desktop[3754]: libva info: VA-API version 1.18.0
Jul 29 01:19:23 hubble.Home firefox.desktop[3754]: libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
Jul 29 01:19:23 hubble.Home firefox.desktop[3754]: libva info: Found init function __vaDriverInit_1_18
Jul 29 01:19:23 hubble.Home firefox.desktop[3754]: libva info: va_openDriver() returns 0
Jul 29 01:29:54 hubble.Home firefox.desktop[3754]: libva info: VA-API version 1.18.0
Jul 29 01:29:54 hubble.Home firefox.desktop[3754]: libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
Jul 29 01:29:54 hubble.Home firefox.desktop[3754]: libva info: Found init function __vaDriverInit_1_18
Jul 29 01:29:54 hubble.Home firefox.desktop[3754]: libva info: va_openDriver() returns 0
Jul 29 01:29:54 hubble.Home firefox.desktop[3754]: libva info: VA-API version 1.18.0

Last edited by Hubbleexplorer (2023-07-29 00:32:27)

seth · 2023-07-29 06:47:46

That's not really an error - FF tries (and succeeds?) to use HW acceleration to play a video (on teh AMD chip)
I guess simply playing a video (eg. w/ mpv) or checking "vainfo" doesn't crash anything?

Is this some fedora live system or did you install it?
Is the nvme at use at all in this context?

Hubbleexplorer · 2023-07-29 14:09:07

seth wrote:

That's not really an error - FF tries (and succeeds?) to use HW acceleration to play a video (on teh AMD chip)
I guess simply playing a video (eg. w/ mpv) or checking "vainfo" doesn't crash anything?
Is this some fedora live system or did you install it?
Is the nvme at use at all in this context?

So i install fedora to nvme, so yes the nvme is being used
and here the output for vainfo on fedora

vainfo
Trying display: wayland
libva info: VA-API version 1.18.0
libva info: Trying to open /usr/lib64/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_18
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.18 (libva 2.18.2)
vainfo: Driver version: Mesa Gallium driver 23.1.4 for AMD Radeon Graphics (renoir, LLVM 16.0.6, DRM 3.52, 6.4.6-200.fc38.x86_64)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointVLD
      VAProfileVP9Profile2            :	VAEntrypointVLD
      VAProfileNone                   :	VAEntrypointVideoProc

in arch i was using x11
for now i will remove fedora because this was just for testing and will install an arch based distro again

Last edited by Hubbleexplorer (2023-07-29 14:10:49)

seth · 2023-07-29 14:11:34

"So the plan was to not do that" - run some live distro to keep the nvme out of the equation to see whether it's the cause.

Hubbleexplorer · 2023-07-29 14:13:11

seth wrote:

"So the plan was to not do that" - run some live distro to keep the nvme out of the equation to see whether it's the cause.

ok got it, I will just remove fedora and run garuda as a live iso for a few days

Last edited by Hubbleexplorer (2023-07-29 14:13:58)

Hubbleexplorer · 2023-07-29 23:56:13

So after a few hours it crashed again with black screen on the live iso, so it's not the nvme. What should i do now?

seth · 2023-07-30 06:33:42

BIOS update or RMA?
The system is either underpowered or overclocked or overheating.
If you can rule out all or not sufficiently mitigate any of the hardware issues (I frankly forgot what we tried, but notably the notrious ryzen problems, the battery might be a problem because you can just replace it) - and since you're experiencing this across various software stacks it's unlikely anything software - there's not much you can do than dumping it.

Hubbleexplorer · 2023-07-30 10:17:54

seth wrote:

BIOS update or RMA?
The system is either underpowered or overclocked or overheating.
If you can rule out all or not sufficiently mitigate any of the hardware issues (I frankly forgot what we tried, but notably the notrious ryzen problems, the battery might be a problem because you can just replace it) - and since you're experiencing this across various software stacks it's unlikely anything software - there's not much you can do than dumping it.

The Bios has been updated to the latest version, I can't RMA because is not in the warranty period anymore.
The system can't be overclock and if the problem is power I don't even begging to know how to test this, I dought is the battery because most of the crashes happend with the laptop plugged to the wall. I suspect that the Nvidia gpu has a problem or in the Nvram or in the ship it selft, either way no solution for that unless a new moderboard, when i have time i will test the battery and the Nvram of that card.
I'm also maybe will commit blafemy and install windows 10 and check if the official Asus tools give me anything

Last edited by Hubbleexplorer (2023-07-30 10:30:31)

seth · 2023-07-30 14:07:04

The system can't be overclock

I'm pretty sure it can, but obviously you'd not have done so.

I doubt is the battery because most of the crashes happend with the laptop plugged to the wall

Unless you can operate the notebook w/o its battery, it's still gonna be the direct power supply and voltage generator. You'd have to replace it.

To be sure: you've looked at https://wiki.archlinux.org/title/Ryzen#Troubleshooting and the cstate limitation still in place and taken a look at the curve optimizer?
"Ryzen" is usually the most likely cause.

Hubbleexplorer · 2023-07-30 15:04:01

seth wrote:

The system can't be overclock
I'm pretty sure it can, but obviously you'd not have done so.
I doubt is the battery because most of the crashes happend with the laptop plugged to the wall
Unless you can operate the notebook w/o its battery, it's still gonna be the direct power supply and voltage generator. You'd have to replace it.
To be sure: you've looked at https://wiki.archlinux.org/title/Ryzen#Troubleshooting and the cstate limitation still in place and taken a look at the curve optimizer?
"Ryzen" is usually the most likely cause.

The cstate was already tested and the bios doesn't support the curbe optimizer, at least it isn't available in the bios, i have to look if is possible to activate this or if really not supported

Hubbleexplorer · 2023-07-30 15:06:27

seth wrote:

The system can't be overclock
I'm pretty sure it can, but obviously you'd not have done so.
I doubt is the battery because most of the crashes happend with the laptop plugged to the wall
Unless you can operate the notebook w/o its battery, it's still gonna be the direct power supply and voltage generator. You'd have to replace it.
To be sure: you've looked at https://wiki.archlinux.org/title/Ryzen#Troubleshooting and the cstate limitation still in place and taken a look at the curve optimizer?
"Ryzen" is usually the most likely cause.

The overclock that is possible is just for the nvram of the Nvidia card and by external tools, the Ryzen mobile cpu overclocking is normally lock to the user.
The cstate was already tested and the bios doesn't support the curve optimizer, at least it isn't available in the bios, i have to look if is possible to activate this or if really not supported

Last edited by Hubbleexplorer (2023-07-31 01:53:28)

Hubbleexplorer · 2023-07-31 02:06:21

So i install windows, and after a lot of waiting, i only detected one issue,

Windows has stopped this device because it has reported problems. (Code 43)

A request for the USB device descriptor failed.

This is weird because this appends even if no usb port is beeing used, and other weird thing is that the location reported by windows change sometimes from "Port_#0001.Hub_#0003" to "Port_#0001.Hub_#0002" after a reboot.
Could the one of the usb controlers be cooked? and if yes can it cause crashes? or is this just of windows being windows?
Also when i have the time i will test the nvram of the nvidia card, when i do it i will put an update in this thread

Ps: i forgot to mention that all usb ports work even with the error that windows show's

Last edited by Hubbleexplorer (2023-07-31 02:14:54)

seth · 2023-07-31 07:10:30

USB is a bus, not a plug - might be some internal device.
Do you get usb errors in your linux journal as well?

However this will rather not cause an immediate crash, your input might cease to function, but eg. the output (video playing etc) would be fine.

Do you have *any* control over the cpu voltage in the BIOS?

Hubbleexplorer · 2023-07-31 11:16:46

seth wrote:

USB is a bus, not a plug - might be some internal device.
Do you get usb errors in your linux journal as well?
However this will rather not cause an immediate crash, your input might cease to function, but eg. the output (video playing etc) would be fine.
Do you have *any* control over the cpu voltage in the BIOS?

I think in linux some times was warnings about usb , errors I'm not certain.
No I don't have any control over the cpu voltage in the Bios

Hubbleexplorer · 2023-08-02 17:28:46

So some updates, in linux there is no error reported so it was a windows issue, also i tested removing the battery and it crashes all the same, so for now I'm trying to get other power adapter to see if that is the issue

Hubbleexplorer · 2023-08-06 14:01:44

So after a few days, i think i found a solution, don't know if it's a good solution but it hasn't crash in 2 days.

systemctl --user mask plasma-powerdevil.service

masking the "powerdevil.service" removes some useful features but at least the crashes disappear.
Can someone explain me why because i don't understand.

seth · 2023-08-06 15:04:34

Judging from its config, powerdevil handles screen brightness, lid events and some actions on lower battery state … and wireless powersaving.

1. do you use the latter?
2. does the screen still turn off if you keep your hands off the input?

Hubbleexplorer · 2023-08-06 17:28:58

seth wrote:

Judging from its config, powerdevil handles screen brightness, lid events and some actions on lower battery state … and wireless powersaving.
1. do you use the latter?
2. does the screen still turn off if you keep your hands off the input?

No to both questions. The screen still locks after a few time but i don't thing that is powerdevil does.

seth · 2023-08-06 18:35:52

Does "xset dpms force off" trigger the panic?

Hubbleexplorer · 2023-08-06 22:59:47

seth wrote:

Does "xset dpms force off" trigger the panic?

No it does not crash, even if the powerdevil service in unmasked

seth · 2023-08-07 06:03:13

Keep PD masked for a week, if you don't get the kernel panic again, unmask it again and see whether that quickly returns the panic.

Has this btw. always happened on battery or also on AC?
Otherwise the brightness control might be the trigger, https://wiki.archlinux.org/title/Backli … interfaces

Arch Linux

#51 2023-07-23 15:01:11

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#52 2023-07-23 15:03:04

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#53 2023-07-25 21:28:35

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#54 2023-07-25 21:34:50

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#55 2023-07-28 23:13:15

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#56 2023-07-29 06:47:46

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#57 2023-07-29 14:09:07

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#58 2023-07-29 14:11:34

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#59 2023-07-29 14:13:11

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#60 2023-07-29 23:56:13

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#61 2023-07-30 06:33:42

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#62 2023-07-30 10:17:54

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#63 2023-07-30 14:07:04

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#64 2023-07-30 15:04:01

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#65 2023-07-30 15:06:27

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#66 2023-07-31 02:06:21

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#67 2023-07-31 07:10:30

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#68 2023-07-31 11:16:46

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#69 2023-08-02 17:28:46

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#70 2023-08-06 14:01:44

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#71 2023-08-06 15:04:34

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#72 2023-08-06 17:28:58

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#73 2023-08-06 18:35:52

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#74 2023-08-06 22:59:47

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

#75 2023-08-07 06:03:13

Re: [CLOSE/Unable to find cause]Random kernel panics without log's

Board footer