Unraid 6.5.3 Call Trace Error, Faulty Memory?

[foxxzero]

Hi all,

 

I just built a new server for Unraid 6, having used Unraid 4 for years and years on an old HP ProLiant.

 

I'm getting a call trace error every time I boot up, and 'Fix Common Problems' is warning me about it each time.

 

A few days later, my server would crash at every opportunity, which I diagnosed down to a faulty memory stick (hundreds of errors on memtest within 5 minutes!)

 

Having replaced the stick, I thought this would fix the call trace error, but I'm still getting it!

 

Please advise, any help would be much appreciated.

 

I've attached diagnostics.

 

Thanks!

tower-diagnostics-20180717-1403.zip

[tmoran000]

me and a few other guys are having similar issues. the immediate crash. No one seems to have any idea whats causing it. Good luck 

[JorgeB]

Trace is related to a kernel alpha option in use:

 

Jul 17 13:26:09 Tower kernel: Setting dangerous option alpha_support - tainting kernel
Jul 17 13:26:09 Tower kernel: WARN_ON(!((dev_priv)->info.platform == INTEL_SKYLAKE) && !((dev_priv)->info.platform == INTEL_KABYLAKE))

 

[Hoopster]

From your syslog:

Jul 17 13:25:51 Tower kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot i915.alpha_support=1

 

It looks like you are enabling i915 alpha support so you can do Plex hardware transcoding with a Coffee Lake CPU.  That appears to be the root of the call traces.

 

I am not sure to which Linux kernel version it applies, but, I believe the kernel version planned for the upcoming unRAID 6.6 release (not yet in RC) will make enabling the i915 alpha support no longer necessary.

 

As a test, you may want to disable i915 alpha support in syslinux.cfg to see if the call traces go away,

[foxxzero]

On 7/21/2018 at 7:47 AM, Hoopster said:

From your syslog:

Jul 17 13:25:51 Tower kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot i915.alpha_support=1

 

It looks like you are enabling i915 alpha support so you can do Plex hardware transcoding with a Coffee Lake CPU.  That appears to be the root of the call traces.

 

I am not sure to which Linux kernel version it applies, but, I believe the kernel version planned for the upcoming unRAID 6.6 release (not yet in RC) will make enabling the i915 alpha support no longer necessary.

 

As a test, you may want to disable i915 alpha support in syslinux.cfg to see if the call traces go away,

 

Thank you Hoopster! I'm picking this thread up again as I'm on holiday. I can try that, if it is indeed the i915 alpha support enabling that's causing the call trace then my question is, is there anything fundamentally wrong with keeping it on? What does the call trace actually mean in reality?

 

I would like to have Coffee Lake hardware transcoding on, so it's great that 6.6 will have i915 support by default.

 

Thanks again!

[Hoopster]

On 8/17/2018 at 4:20 AM, foxxzero said:

 

Thank you Hoopster! I'm picking this thread up again as I'm on holiday. I can try that, if it is indeed the i915 alpha support enabling that's causing the call trace then my question is, is there anything fundamentally wrong with keeping it on? What does the call trace actually mean in reality? 

 

I would like to have Coffee Lake hardware transcoding on, so it's great that 6.6 will have i915 support by default.

 

Thanks again!

 

Call traces are not necessarily an indication of fatal errors. In fact, many times the system is able to recover and move on without a negative impact to the server.   I have run my server for weeks with regular call traces and, had I not checked the log to see that I had call traces, I would not have noticed anything wrong.  A call trace just indicates that a system call was not successfully completed.  Depending on what caused it, the kernel may or may not be able to recover.

 

If you do not notice problems on the server that you can associate with frequent call traces, perhaps there is no need to correct the problem.

 

In my case, the call traces started increasing in frequency and did occasionally result in a hard lock-up of the server, so, I tracked down the cause and eliminated it.  It was not related to the source of your call traces.