Created attachment 709532 [details] Laptop booted in UEFI mode with kernel 3.8.2 Description of problem: If I choose to boot in UEFI mode and I use a 3.8 kernel, my screen will become as in pic in attachment (monitor split four times). Version-Release number of selected component (if applicable): I've tested mainly with kernel-3.8.2-206.fc18.x86_64 How reproducible: Booting in UEFI mode Steps to Reproduce: 1. Boot in UEFI 2. Wait for radeondrmfb to take over EFI VGA 3. The screen becomes split in 4 Actual results: The screen is splitted, changing resolution and/or using xrandr won't help Expected results: Screen not splitted; same behaviour as with kernel 3.7.9-205.fc18.x86_64, which did not have this issue. Additional info: Possible related bug: https://bugzilla.redhat.com/show_bug.cgi?id=752219 No issues at all if I do not boot in UEFI mode.
`dmesg|grep radeon` on kernel 3.8.2 [ 13.142421] [drm] radeon defaulting to kernel modesetting. [ 13.142427] [drm] radeon kernel modesetting enabled. [ 13.142486] fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver [ 13.143053] radeon 0000:01:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used) [ 13.143055] radeon 0000:01:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF [ 13.144458] [drm] radeon: 512M of VRAM memory ready [ 13.144459] [drm] radeon: 512M of GTT memory ready. [ 13.144503] radeon 0000:01:00.0: irq 47 for MSI/MSI-X [ 13.144513] radeon 0000:01:00.0: radeon: using MSI. [ 13.144543] [drm] radeon: irq initialized. [ 13.213666] radeon 0000:01:00.0: WB enabled [ 13.213673] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff8801b1771c00 [ 13.213676] radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0xffff8801b1771c0c [ 13.261560] [drm] radeon: power management initialized [ 13.653812] fbcon: radeondrmfb (fb0) is primary device [ 13.917177] radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device [ 13.917179] radeon 0000:01:00.0: registered panic notifier [ 13.917198] [drm] Initialized radeon 2.29.0 20080528 for 0000:01:00.0 on minor 0 `dmesg|grep radeon` on kernel 3.7.9 [ 2.820828] [drm] radeon defaulting to kernel modesetting. [ 2.820832] [drm] radeon kernel modesetting enabled. [ 2.820894] fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver [ 2.821321] radeon 0000:01:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used) [ 2.821323] radeon 0000:01:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF [ 2.822978] [drm] radeon: 512M of VRAM memory ready [ 2.822980] [drm] radeon: 512M of GTT memory ready. [ 2.823041] radeon 0000:01:00.0: irq 46 for MSI/MSI-X [ 2.823051] radeon 0000:01:00.0: radeon: using MSI. [ 2.823078] [drm] radeon: irq initialized. [ 2.825695] radeon 0000:01:00.0: WB enabled [ 2.825699] radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0xffff8801aac40c00 [ 2.873095] [drm] radeon: power management initialized [ 3.258963] fbcon: radeondrmfb (fb0) is primary device [ 3.517971] fb0: radeondrmfb frame buffer device [ 3.518012] [drm] Initialized radeon 2.24.0 20080528 for 0000:01:00.0 on minor 0
With both kernels, in UEFI mode, any external monitor attached via VGA or HDMI works fine. It's just the LVDS lcd panel that misbehaves with kernel 3.8.
Created attachment 709909 [details] dmesg from kernel 3.7.9-205.fc18.x86_64
Created attachment 709911 [details] dmesg from kernel 3.8.2-206.fc18.x86_64
Same behaviour with 3.8.3-201 (candidate update) I've noticed that I cannot create efi entries with efibootmgr when I'm on a 3.8 kernel - I can view and delete entries, reset the boot order but I cannot create a new boot entry. With the 3.7 kernel, I can create entries with efibootmgr just fine.
*********** 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 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. 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 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those.
*********** 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. It has been over a month since we asked you to test the 3.11 kernel updates and let us know if your issue has been resolved or is still a problem. When this happened, the bug was set to needinfo. Because the needinfo is still set, we assume either this is no longer a problem, or you cannot provide additional information to help us resolve the issue. As a result we are closing with insufficient data. If this is still a problem, we apologize, feel free to reopen the bug and provide more information so that we can work towards a resolution If you experience different issues, please open a new bug report for those.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days