Bug 921053

Summary: UEFI splits screen on a laptop with radeon GPU (ATI RV710) if a newer kernel is selected
Product: [Fedora] Fedora Reporter: romny <romny>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, romny
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-27 16:02:24 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:
Attachments:
Description Flags
Laptop booted in UEFI mode with kernel 3.8.2
none
dmesg from kernel 3.7.9-205.fc18.x86_64
none
dmesg from kernel 3.8.2-206.fc18.x86_64 none

Description romny 2013-03-13 11:30:07 UTC
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.

Comment 1 romny 2013-03-13 11:38:23 UTC
`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

Comment 2 romny 2013-03-13 13:13:11 UTC
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.

Comment 3 romny 2013-03-14 08:27:17 UTC
Created attachment 709909 [details]
dmesg from kernel 3.7.9-205.fc18.x86_64

Comment 4 romny 2013-03-14 08:31:35 UTC
Created attachment 709911 [details]
dmesg from kernel 3.8.2-206.fc18.x86_64

Comment 5 romny 2013-03-15 16:16:42 UTC
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.

Comment 6 Justin M. Forbes 2013-10-18 21:13:13 UTC
*********** 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.

Comment 7 Justin M. Forbes 2013-11-27 16:02:24 UTC
*********** 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.

Comment 8 Red Hat Bugzilla 2023-09-14 01:42:17 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days