Bug 593429 - KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to a docking station and external display
Summary: KMS:RV635:Radeon 3650HD graphics driver broken on a laptop when connected to ...
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jérôme Glisse
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-05-18 18:55 UTC by Pasi Karkkainen
Modified: 2018-04-11 07:39 UTC (History)
8 users (show)

Fixed In Version: kernel-
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-08-03 01:11:33 UTC
Type: ---

Attachments (Terms of Use)
dmesg with both monitors extended (55.61 KB, text/plain)
2010-05-28 22:09 UTC, Matěj Cepl
no flags Details
same with drm.debug=15 (121.88 KB, text/plain)
2010-05-28 22:10 UTC, Matěj Cepl
no flags Details
dmesg with drm.debug=4 (96.15 KB, text/plain)
2010-06-19 19:13 UTC, Pasi Karkkainen
no flags Details
0001-drm-radeon-kms-fix-shared-ddc-handling.patch (1.43 KB, application/octet-stream)
2010-07-12 11:35 UTC, Pasi Karkkainen
no flags Details

Description Pasi Karkkainen 2010-05-18 18:55:29 UTC
Description of problem:
I just tried installing Fedora 13 RC on my laptop (HP EliteBook 8530p) and I noticed the graphics are broken if I have the laptop on the docking station, which has external display connected with DVI. 

Version-Release number of selected component (if applicable):
Fedora 13 rc, kernel

How reproducible:

Steps to Reproduce:
1. Burn F13 rc cd/dvd
2. Connect the laptop to a docking station which has external display connected with DVI. Close the laptop lid so only the external display is in use.
3. Boot from F13 CD/DVD. 
Actual results:
Fedora starts to boot on the external display, and then the external display goes blank and Fedora crashes. I don't get to see the blue background fedora splash or the installer. ctrl-alt-del doesn't reboot, and powerbutton doesn't do anything either.

Expected results:
Fedora boots OK.

Additional info:
If I use the laptop without the dock, using only the internal display (lid open), F13 rc boots and works OK.

Another problem: If I have the laptop on the dock, but still have the internal display on (lid open) and boot Fedora then I get to see the blue splash screen on the internal display, but when X should start and GDM show up, the internal display goes blank and nothing happens after that. The external display is blank aswell. It seems the driver crashes. ctrl-alt-del doesn't do anything.

I'm going to try with "nomodeset" later, but I'm away from the dock for a couple of days now.. 

Any other information I should post, or something to try? 

01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3650 (prog-if 00 [VGA controller])
        Subsystem: Hewlett-Packard Company Device 30e7
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 33
        Region 0: Memory at c0000000 (32-bit, prefetchable) [size=256M]
        Region 1: I/O ports at 7000 [size=256]
        Region 2: Memory at d8300000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at d8320000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 128 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <64ns, L1 <1us
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis-
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
                LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -3.5dB
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
                Address: 00000000fee0200c  Data: 41d1
        Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
        Kernel driver in use: radeon
        Kernel modules: radeon

$ zegrep -i 'drm|radeon|ttm' dmesg-

[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
radeon 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
radeon 0000:01:00.0: setting latency timer to 64
[drm] radeon: Initializing kernel modesetting.
[drm] register mmio base: 0xD8300000
[drm] register mmio size: 65536
[drm] Clocks initialized !
[drm] Detected VRAM RAM=256M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 2012172 kiB.
[ttm] Initializing pool allocator.
[drm] radeon: 256M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
radeon 0000:01:00.0: irq 33 for MSI/MSI-X
[drm] radeon: using MSI.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RV635 Microcode
platform radeon_cp.0: firmware: requesting radeon/RV635_pfp.bin
platform radeon_cp.0: firmware: requesting radeon/RV635_me.bin
platform radeon_cp.0: firmware: requesting radeon/R600_rlc.bin
[drm] ring test succeeded in 1 usecs
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
[drm] Enabling audio support
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   VGA
[drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm]   Encoders:
[drm] Connector 1:
[drm]   LVDS
[drm]   Encoders:
[drm] Connector 2:
[drm]   DVI-D
[drm]   HPD1
[drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
[drm]   Encoders:
[drm] Connector 3:
[drm]   HDMI-A
[drm]   HPD2
[drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c
[drm]   Encoders:
[drm] fb mappable at 0xC0141000
[drm] vram apper at 0xC0000000
[drm] size 7257600
[drm] fb depth is 24
[drm]    pitch is 6912
fbcon: radeondrmfb (fb0) is primary device
fb0: radeondrmfb frame buffer device
[drm] Initialized radeon 2.0.0 20080528 for 0000:01:00.0 on minor 0

Comment 1 Jérôme Glisse 2010-05-18 19:22:15 UTC
Can you log in through ssh when the laptop is docked ? If so attach _full_ dmesg.

Comment 2 Pasi Karkkainen 2010-05-18 19:35:07 UTC
I'll try it as soon as I'm back where the dock is. I think the kernel crashes since keyboard didn't have any effect.. but I'll verify and report back.


Comment 3 Adam Williamson 2010-05-18 22:32:27 UTC

Fedora Bugzappers volunteer triage team

Comment 4 Vedran Miletić 2010-05-24 19:53:02 UTC
Improving summary.


Fedora Bugzappers volunteer triage team

[This triage is part of collective effort done by students of University of
Rijeka Department of Informatics.]

Comment 5 Pasi Karkkainen 2010-05-27 20:02:57 UTC
Ok, finally I could do some more testing.
It seems I can access the machine with ssh. 

Some logs here available here: http://pasik.reaktio.net/fedora/bz593429/

Booting with both the internal and external display connected:

I notice these errors from the dmesg:
[drm:drm_mode_getfb] *ERROR* invalid framebuffer id
[drm:drm_mode_getfb] *ERROR* invalid framebuffer id

Same setup but with drm.debug=15:

With drm debugging enabled there seems to be so much noise that "dmesg" command won't show the whole log..

Should I try something else? 

I also tried booting with "nomodeset", and having *only* the external display connected via dock via DVI, the laptop lid closed. In this case I could see Fedora booting up on the external display, I got GDM on the external display, but when I login from GDM the external display goes blank, and the *internal* display wakes up showing the desktop..

Comment 6 Matěj Cepl 2010-05-28 22:09:19 UTC
Created attachment 417757 [details]
dmesg with both monitors extended

Comment 7 Matěj Cepl 2010-05-28 22:10:01 UTC
Created attachment 417758 [details]
same with drm.debug=15

Comment 8 Pasi Karkkainen 2010-06-03 12:11:55 UTC
Discussion continues here: 

Comment 9 Pasi Karkkainen 2010-06-03 15:22:12 UTC
Problem/bug described here:

Paste from that email:

> HDMI-0 connected (normal left inverted right x axis y axis)
>   1920x1080      59.9 +
>   1600x1200      60.0
>   1680x1050      60.0
>   1280x1024      60.0
>   1440x900       59.9
>   1280x960       60.0
>   1280x800       59.8
>   1024x768       60.0
>   800x600        60.3     56.2
>   640x480        60.0
> $ xrandr --output DVI-0 --right-of LVDS
> Didn't make a difference.. no picture on the external DVI display.
> I wonder if that HDMI-0 is the key to the problem.. I don't have anything connected
> to the HDMI connector on the laptop. There's no HDMI connector on the dock, it's only in the laptop.

Indeed that is the problem.  On your system the HDMI and DVI ports
share the same encoder and DDC line so they will both come up as
connected since the line is shared.  The driver used to check the edid
when the lines where shared and select HDMI or DVI based on the EDID,
but perhaps that got broken at some point.


Comment 10 Pasi Karkkainen 2010-06-19 19:11:53 UTC
Here's a new log with drm.debug=4, which still enables me to capture the kernel messages before they're flooded away.


Which clearly shows both the DVI and HDMI connectors are detected as active, when only DVI is connected for real.. and this messes up everything.

Comment 11 Pasi Karkkainen 2010-06-19 19:13:41 UTC
Created attachment 425373 [details]
dmesg with drm.debug=4

dmesg with drm.debug=4, both the internal display and external DVI display connected.

Comment 12 Pasi Karkkainen 2010-07-01 14:51:40 UTC
Upstream patch to fix this bug:

It has been CC'd to stable@kernel.org for inclusion in 2.6.33.stable.

Please include this bugfix patch in F13 kernel update!

Comment 13 Pasi Karkkainen 2010-07-12 11:35:22 UTC
Created attachment 431145 [details]

Added the upstream bugfix patch as an attachment.

Comment 14 Pasi Karkkainen 2010-07-12 11:36:24 UTC
Any chance of getting this bugfix patch to the next F13 kernel update? My F13 laptop is totally unusable without this..

Comment 15 Adam Williamson 2010-07-12 19:38:49 UTC
Jerome? Dave?

Comment 16 Robert Hoekstra 2010-07-14 09:28:00 UTC
Any idea when this fix will hit the repos? I'm suffering this exact issue too. I've got to disconnect the DVI each morning at startup. After startup I can connect DVI again and start using it.. (lousy workaround, but it works.. so the laptop isn't totally unusable).

Comment 17 Pasi Karkkainen 2010-07-19 11:24:03 UTC
Oh, forgot to mention, I've tested the patch applied to F13 kernel, and it works OK.

So it should be straight forward to apply to F13 kernel update.

Comment 18 Chuck Ebbert 2010-07-22 20:33:41 UTC
This should be fixed in

Comment 19 Fedora Update System 2010-07-24 14:11:19 UTC
kernel- has been submitted as an update for Fedora 13.

Comment 20 Pasi Karkkainen 2010-07-25 13:22:15 UTC
I just tested kernel-, and it seems to work OK! 

Thanks for including the fix.

Comment 21 Pasi Karkkainen 2010-07-25 13:38:02 UTC
.. and I just noticed there seems to be an additional patch available from upstream: http://lists.freedesktop.org/archives/dri-devel/2010-July/002279.html

Subject: "[PATCH] drm/radeon/kms: fix shared ddc harder"

I'm just building a custom kernel and including that extra patch aswell, to verify things still work with it.

Comment 22 Pasi Karkkainen 2010-07-25 15:07:56 UTC
Ok, I applied the extra patch from http://lists.freedesktop.org/archives/dri-devel/2010-July/002279.html to kernel-, and built a custom kernel for testing.

Things seem to work OK with that additional patch applied. No problems found.
So I guess that extra patch should be applied to next F13 kernel update.

Comment 23 Robert Hoekstra 2010-07-26 14:34:40 UTC
Tried the kernel and all seems well. At least I don't have to disconnect the DVI connector anymore.

Comment 24 Fedora Update System 2010-07-27 02:47:51 UTC
kernel- has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/kernel-

Comment 25 Pasi Karkkainen 2010-08-01 11:42:32 UTC
The extra patch from http://lists.freedesktop.org/archives/dri-devel/2010-July/002279.html should be applied aswell, since it's a followup patch and is sent for stable@kernel.org inclusion aswell.


Comment 26 Fedora Update System 2010-08-03 01:11:09 UTC
kernel- has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.