Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.(try) to boot livecd. 2. 3. Actual results: error -> https://picasaweb.google.com/lh/photo/_pQ9s4RE_RVWKsHh5_I0Qg?feat=directlink without quiet and hrub(? not sure of the second command name) -> https://picasaweb.google.com/lh/photo/ZTPSXjiQT1c_C3REoKn-Cg?feat=directlink Expected results: crashing at booting Additional info: Produser Dell Inc. Modell Dell System XPS L502X 8,00 GB RAM 64-bit OS Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz, number of Cores: 4
I have a similar Dell config (i7, 8GB RAM, NVidia 525 Optimus), named Inspiron 7110. The actual error log is about the same as on the first photo. I found two ways to reproducibly overcome the issue, at least on FC16 beta: 1) Add acpi=off to boot params. 2) Unplug any USB devices. I am not joking, I tried several times with and without USB devices (e.g. mouse, keyboard, pendrive). Unplugging them made FC16 boot even with ACPI being enabled. Later on, when the system is up and running I can attach any USB devices and they work.
Clearly reproducible on the above mentioned Dell N7110 config with FC16 TC3. It seems as if the kernel gets into infinite loop, as the CPU fan spins madly.
The bug still persists on FC16 with kernel 3.1.1. I tried PC-BSD 9, and ACPI seems to work well with it when I choose "Boot with ACPI enabled" option. So it seems that it is not the privilege of Microsoft to write a kernel that does not crash on ACPI use.
The issue still persists with kernel 3.1.5 and 3.2.0-rc6. But I found another way to overcome it. Instead of acpi=off option rdblacklist=i915 can be used to avoid the hangup on boot. That is quite interesting, I think. Unfortunately when Xorg tries to use intel driver it crashes the entire system, just like what happened at boot time originally. As neither nv nor nouveau driver works with my video chip and current nvidia binary driver shows only blank screen (even if I forced it to use DFP instead of CRT) I have to stick to acpi=off.
As I wrote earlier my attempt to use my NVIDIA chip was a total failure. So I have to use i915 on Linux. Still, I wanted to get rid of acpi=off somehow, so that I could put my laptop to sleep, at least. Therefore I compiled 2 restricted variants of kernel 3.2.0-rc6 (now I used kernel.org variant, not Rawhide, as before). One was without DRM (Direct Rendering Manager) the other without Laptop Hybrid Graphics (under Device Drivers/Graphics support in make menuconfig). Unfortunately both attempts failed, without acpi=off the kernel froze at booting. That hints that the issue might be i915 related. That is all I could do, my story ends here. I am just a plain user with some knowledge how to use Google Search, not a kernel hacker. I am not wiser than a hairdresser from Golgafrincham. So I do not see any other option then to say good-bye to Fedora, and Linux altogether for now.
I see that the whole Fedora community is nervous to hear what is going on with my laptop. First of all, I flashed the BIOS of my Dell Insiron 17R N7110 to the pretty recent version "A12", though change history does not show any relevant improvement. And I decided to play with Fedora 17 Alpha Live CD. Booting went as expected, kernel hung and CPU fan spinned madly. Kernel parameter acpi=off cures it, so does pci=noacpi. The latter is a better choice, I think. I experimented with USB unplugging again. Whenever I plug something to USB 3.0 slot, such as keyboard or mouse, then I need pci=noacpi. When I use USB 2.0 slot only, then the kernel does not hang even without disabling ACPI. Pretty strange.
I had the same problem on my lapton (Dell Inspiron 7110 i5 4GB RAM, NVidia 525 Optimus). Kernel hangs on boot when something is plugged to USB 3.0 slots. I managed it with acpi_backlight=vendor kernel parameter, this doesn't disable ACPI and everything seems to work fine.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I think it is not really relevant whether Fedora keeps this bug report open or not. It is a Linux kernel issue (probably a strange behavior of Dell BIOS making the kernel fail). It can be reproduced with Ubuntu 12.04.01 as well (that is an August 23 2012 release actually). So Fedora guys may not fix it even if someone clones this bug report.
kordirko above recommended using acpi_backlight=vendor kernel parameter. Yes, that works fine for me, too. Thanks!