Bug 1414365 - MacBook Air freezes with latest kernel
Summary: MacBook Air freezes with latest kernel
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Prarit Bhargava
QA Contact: Evan McNabb
Depends On:
TreeView+ depends on / blocked
Reported: 2017-01-18 10:46 UTC by Alexander Todorov
Modified: 2018-03-01 15:14 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-03-01 15:14:42 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Alexander Todorov 2017-01-18 10:46:53 UTC
Description of problem:

I am running RHEL 7.3 on MacBook Air 7,2 model. 

With kernel 3.10.0-327.4.5.el7.x86_64 the computer is working fine. I do however have 2 kmods: one for backlight and another for wifi, which I compiled myself.

With kernel-3.10.0-514.el7.x86_64 I don't need the backlight driver as it seems that the Intel backlight driver is working properly. However with this version my computer randomly freezes. It may be 10 minutes after reboot and sometimes it is over 2 weeks before it freezes.

I'm not able to get anything out of kdump or abrt to investigate the problem further. 

Version-Release number of selected component (if applicable):

How reproducible:
always on particular hardware

Steps to Reproduce:

Actual results:

Expected results:

Additional info:

The sources for the additional drivers are at:

I can provide rpms and debuginfo rpms as well.

At the moment I'd really like to know how can I debug this issue further and provide more information.

NOTE: I require the -514 kernel due to an issue with external monitors not being detected with the -327 kernel.

Comment 2 Alexander Todorov 2017-01-22 08:52:53 UTC
Here are some updates from the last couple of days:

1) when system freezes it is unreachable via network
2) I had enabled logging to a remote system via network but when system freezes the remote system doesn't show anything out of the ordinary in the logs.
3) Tested with oops=panic softlockup_panic=1 on the boot command line, as proposed by jstancek, system froze
4) all of the time kdump has been enabled but there was no vmcore generated

5) I've tried adding intel_idle.max_cstate=1 on the boot command line as proposed in https://paper.myportfolio.com/install-ubuntu-on-macbook-air. So far it appears to work. My uptime is 3+ days and no freeze.  Is this going to be sufficient to find the problem ?

So far I have not tried to force crash the system with the SysReq key when it's frozen so I can get a vmcore. Will try it next if freeing continues.

Comment 3 Prarit Bhargava 2017-01-25 12:50:37 UTC
atodorov, I don't know if we've certified the Macbook Air.  The cstate parameter is interesting -- can you try increasing the max_cstate value to see if there is a particular value that causes the freezes?


Comment 4 Alexander Todorov 2017-01-30 09:11:02 UTC
what other cstate values to try with ? I don't know what this parameter controls but it appears to work. 

For the record: I don't think the MacBook Air is certified either.

Comment 5 Prarit Bhargava 2017-03-13 12:13:35 UTC
(In reply to Alexander Todorov from comment #4)
> Prarit,
> what other cstate values to try with ? I don't know what this parameter
> controls but it appears to work. 
> For the record: I don't think the MacBook Air is certified either.

Can you try max_cstate with values 0 through X (where X is the highest supported state on your HW?)


Comment 6 Prarit Bhargava 2017-06-29 17:41:40 UTC
Is this still an issue?


Comment 7 Alexander Todorov 2017-07-17 07:43:00 UTC
(In reply to Prarit Bhargava from comment #6)
> Is this still an issue?
> P.

Yes, now even more pronounced. With kernel-3.10.0-693.el7.x86_64 the moment gdm loads my computer freezes and is unusable. It doesn't matter if I have intel_idle.max_cstate=1 (or 0) or remove this parameter all together - same result.

I'm switching back to the -514 kernel which works with the intel_idle.max_cstates=1 parameter.

Comment 8 Alexander Todorov 2017-07-19 21:18:04 UTC
Scratch my previous comment. I did try the -693 kernel briefly, the freeze was related to a pointer arithmetic error in one of the custom drivers when I recompiled it for this kernel. 

With the error fixed -693 appears to be workign fine, although I didn't use that kernel for very long so it still might be the case I just didn't see the problem. I can give it a longer try sometime next week.

FYI I've switched to a 4.10 kernel, rebuilt for RHEL b/c I can't compile the video driver on earlier versions.

Comment 9 Prarit Bhargava 2018-03-01 15:14:42 UTC
Likely still a problem -- but I have no hardware to look at.  I'm closing this as CANTFIX.


Note You need to log in before you can comment on or make changes to this bug.