Hide Forgot
Description of problem: some chipsets will hang during boot due to pinctrl_cherryview, ref https://bugs.freedesktop.org/show_bug.cgi?id=93590 and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1529353 I am currently wrestling with an Acer Aspire One AO1-131 N15V1. On Fedora kernels of the 4.4 series it is not possible to blacklist the module; systems affected do boot with acpi=off, but this has more serious side-effects. As recently as kernel 4.2.3, this driver was compiled as a module (4.2.3 has other bugs on this hw, so can't actually use it productively). Version-Release number of selected component (if applicable): kernel-4.4.6-300.fc23.x86+64 How reproducible: 100%
Looking at the fedpkg repo, the problem sneaked in with the 4.4.2 update somehow. Should be a one line fix to split it off...
Looking at the upstream bug you point to, a couple things stand out to me. 1) They claim it only happens 1 out of 10 boots. Is that what you are seeing? 2) They claim that it hangs the machine even if it is a module if the module is probed on boot (I'm assuming they mean via the initramfs). Yes, the driver was built as a module in 4.2, but this was an explicit change as requested here: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org/thread/D6Z5LSF5BRO7FGYNVJ4QYKUYYLPEZ4K3/
Bastien, do you have any insight to this issue?
I see problems 100% of the time; one of those links mentions intermittent problems. I am probably not hitting the exact same prob. The point however is that pinctrl_cherryview is in flux, and it is a bad idea to build it into the kernel, as it deprives end users of a powerful workaround. As pinctrl drivers deal with hardware, which changes, this seems to be a normal occurrence. As for the root problem, I am working towards diagnosis upstream on this thread - http://thread.gmane.org/gmane.linux.kernel.gpio/15452 Thanks for pointing out Bastien's request. IMO the problem here is not bloat, but loss of end-user workaround and diagnosability. For v4.2.x the driver was in initramfs, if boot depends on it completely then it makes things brittle and hard to debug in a different way. (Having worked on kernel builds/drivers/tweaks at OLPC, I empathize with the problem space, wish linux had a more malleable means of defining "pin control", settings and quirks of specific chipset variants. As things stand, every time a new variant on a chipset comes out, it is prone to misbehaving until it gets its quirks upstream; and that's a painful process.)
(In reply to Josh Boyer from comment #3) > Bastien, do you have any insight to this issue? I don't. I'd recommend running this machine with a different kernel, because I don't see the point of removing support for CherryView machines to enable this Braswell machine. At least not until this is root-caused.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs. Fedora 23 has now been rebased to 4.7.4-100.fc23. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
Reopenin. This is still an issue on F25, and with the current F26/rawhide kernel v4.10-rc7 . If I rebuild the current rawhide kernel (using fedpkg) with a single line change -- CONFIG_PINCTRL_CHERRYVIEW=m -- then I can boot with 'noapic'.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 25 kernel bugs. Fedora 25 has now been rebased to 4.10.9-200.fc25. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.