Bug 848305
| Summary: | When kernel modsetting is enabled, laptop screen remians off until Xorg starts (ironlake) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Elad Alfassa <elad> |
| Component: | plymouth | Assignee: | Ray Strode [halfline] <rstrode> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 18 | CC: | ajax, awilliam, fedora, gansalmon, itamar, jonathan, jones.peter.busi, jreznik, kernel-maint, kparal, madhu.chinakonda, ptalbert, robatino, rstrode, xgl-maint |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | AcceptedNTH | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-09-14 04:40:21 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 752654, 752662 | ||
| Attachments: | |||
|
Description
Elad Alfassa
2012-08-15 08:47:30 UTC
Created attachment 604553 [details]
dmesg output with drm.debug=0x04
Laptop model is Dell Inspiron N3010.
I would happily provide any more information required to understand the source of the problem and maybe even fix it.
Note that this bug was not present in Fedoras 17.
Maybe a combination of plymouth failing to deal with configuration changes and the kernel changing configuration shortly after plymouth is started. i think should be fixed by: https://admin.fedoraproject.org/updates/edit/plymouth-0.8.7-1.fc18 plymouth-0.8.7-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/plymouth-0.8.7-1.fc18 Package plymouth-0.8.7-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing plymouth-0.8.7-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-12334/plymouth-0.8.7-1.fc18 then log in and leave karma (feedback). Unfortunately this update did not fix the problem (installed it and rebuilt the initramfs, rebooted, still same problem) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Created attachment 606060 [details]
dmesg output with drm.debug=4 with plymouth update installed and kernel 3.6.0-0.rc1.git6.1.fc18.x86_64
Will try with a more recent kernel from koji shortly
Fixed in kernel-3.6.0-0.rc2.git1.2.fc18 Re-opening as the update to plymouth isn't pushed stable. airlied and halfline say that the bug in plymouth - fixed in 0.8.6.2-1.2012.07.23 with the note "fix plymouth race at bootup breaking efi/vesa handoff" - is a significant issue which can cause quite a lot of issues; as well as this problem, for instance, it's probably the reason the 'cirrus' kernel module doesn't work right in Alpha and you get vesa not modesetting as the X driver in cirrus VMs. So, nominating this as NTH to get https://admin.fedoraproject.org/updates/FEDORA-2012-12334/plymouth-0.8.7-1.fc18 into Alpha. Discussed at 2012-09-12 NTH review meeting. Accepted as NTH due to the possibility of the bug causing serious problems; airlied and halfline both believe it's the best course to pull the fix, as the race could affect all sorts of things. We already know it breaks the cirrus kernel module, for instance. plymouth-0.8.7-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. So some complete idiot decided to put this in RC3. On my desktop, it actually seems to make things *worse*. When I boot the RC3 desktop live image, whether via UEFI or BIOS compat, it usually fails to start X cleanly. Often I just see a bunch of boot messages on tty1 - though systemctl status gdm.service and ps agree that gdm is running, on tty1. Sometimes I get a completely corrupted graphical display. Never do I get a fully working gdm, or shell. Sometimes I get a gdm which more or less works, but no cursor; if I try to log in, I get a Shell with completely corrupted graphics. If I go to a console and restart gdm.service, it sometimes comes up, though it's often weird - sluggish cursor response. If it comes up and I can get into Shell, it'll often be corrupted as above. By comparison, RC2 - which used the old plymouth - works perfectly, booted in BIOS mode. booted in UEFI native mode it behaves as described in this bug - the screen goes into power-saving mode until GDM comes up. But GDM *does* come up, and works perfectly. No failure, no weird corruption. Shell is likewise fine. I built two live images with the sole difference being the version of plymouth included, just to confirm plymouth is the problem. It is. The 'oldplymouth' image behaves exactly as I described RC2 above, the 'newplymouth' image behaves as I described RC3. RC3/newplymouth behaviour can be pretty varied, but in every attempt it was broken _somehow_, and it was _always_ worse than _any_ RC2/oldplymouth boot. This doesn't seem to be universal, though. RC3 is fine in a VM, for instance, and others have reported it's ok on their hardware. My system has a GeForce 9600 GT graphics adapter. It's also quite fast - I know speed can matter to these bugs. The system drive is an SSD, so it boots in single-digit seconds. oh, forgot to mention - the one way I can actually get to a working desktop with RC3/newplymouth is to boot to 'runlevel 3' and then do 'systemctl start gdm.service'. then gdm comes up working fine. Looking at dmesg | grep nouveau, there are a *ton* of messages of the form: [drm] nouveau 0000:01:00.0: PFIFO_CACHE_ERROR - Ch 2/2 Mthd 0xfoof Data 0xfoofoofo the values for Mthd and Data change with each message, all the rest remains the same. oh, sometimes it's Ch 2/7 not 2/2. kparal confirms this on a Quadro NVS 140M, and airlied on a geforce 9300m, so it's looking like this affects a lot of NVIDIA hardware. Bumping up to proposed blocker. Works correctly on Quadro NVS 285, Plymouth is ok, X starts correctly, Gnome Shell/Plasma Workspaces works accelerated. Issues on nVidia Corporation Device 1057 - Plymouth is broken - I can see Fedora logo 4x times. X starts, Gnome Shell/Plasma Workspaces works unaccelerated as expected. Created attachment 612415 [details]
screen corruption with Quadro NVS 140M on Alpha RC3
I see the same error messages as Adam. I only tested this once, but for me, removing 'rhgb' from the boot parameters seems to work around the issue - I get a owrking gdm and shell then. I think I am seeing this in FC 16 on a Toshiba NB555D. Versions are: plymouth-0.8.4-0.20110822.5.fc16.x86_64 kernel-3.4.9-2.fc16.x86_64 This happens intermittently, about once in ten boots or resumes from hibernate. CTRL-ALT-DEL reboots and fixes the problem. I haven't tried waiting the 3 minutes suggested in the description above. I will, next time the problem occurs. I have not noticed the problem with the previous kernel, kernel-3.4.9-1.fc16.x86_64, I think. I split off the NVIDIA regression as https://bugzilla.redhat.com/show_bug.cgi?id=857300 - please follow it up there, not here. sorry for the confusion. I'll close this again, Peter, could you file a new bug for F16? |