Bug 41265 - Radeon KMS does not work on thunderbolt media dock
Summary: Radeon KMS does not work on thunderbolt media dock
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-27 08:48 UTC by Varban
Modified: 2013-01-07 17:16 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
syslog output with drm.debug=15 (172.08 KB, patch)
2011-09-27 08:48 UTC, Varban
no flags Details | Splinter Review
acpidump output (219.58 KB, text/plain)
2012-08-14 17:05 UTC, Alexander E. Patrakov
no flags Details
lspci -vvv output when booted with the dock (90.25 KB, text/plain)
2012-08-15 03:20 UTC, Alexander E. Patrakov
no flags Details
fix for all kernels (7.15 KB, patch)
2012-08-16 18:23 UTC, Alex Deucher
no flags Details | Splinter Review
upstream 1/2 (3.21 KB, patch)
2012-08-17 13:09 UTC, Alex Deucher
no flags Details | Splinter Review
upstream 2/2 (7.04 KB, patch)
2012-08-17 13:09 UTC, Alex Deucher
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Varban 2011-09-27 08:48:11 UTC
Created attachment 51663 [details] [review]
syslog output with drm.debug=15

I have a Sony Vaio Z laptop with an internal Intel 3000M card and a discrete Radeon HD6700M card which is connected via the new Intel LightPeak/Thunderbolt port. 
Intel card works fine, Radeon card fails on drm init with invalid rom contents (attached is the full dmesg with drm.debug=15)

[drm] initializing kernel modesetting (TURKS 0x1002:0x6740 0x104D:0x9084).
[drm] register mmio base: 0xC0200000
[drm] register mmio size: 131072
radeon 0000:16:00.0: Invalid ROM contents
radeon 0000:16:00.0: Invalid ROM contents
[drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
radeon 0000:16:00.0: Fatal error during GPU init

The interesting part is that xorg detects a card on PCI:22:0:0 bus and if I specify that as the BusID (xorg.conf) the radeon driver loads and TURKS complains that it requires KMS. If I use PCI:16:0:0 as the BusID radeon does not detect a card at all. According to lspci there is nothing on bus 22:00 but I think the Intel card provides that address as the location of the discrete card.

Any ideas what I can do to get this working?

uname -a:

Linux debian 3.1.0-rc6-amd64 #1 SMP Thu Sep 22 20:01:48 UTC 2011 x86_64 GNU/Linux

xorg 7.6

lspci output:

00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 00 [VGA controller])
        Subsystem: Sony Corporation Device [104d:9084]
        Flags: bus master, fast devsel, latency 0, IRQ 48
        Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
        Memory at a0000000 (64-bit, prefetchable) [size=256M]
        I/O ports at a000 [size=64]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [d0] Power Management version 2
        Capabilities: [a4] PCI Advanced Features
        Kernel driver in use: i915
16:00.0 VGA compatible controller [0300]: ATI Technologies Inc Whistler XT [AMD Radeon HD 6700M Series] [1002:6740] (prog-if 00 [VGA controller])
        Subsystem: Sony Corporation Device [104d:9084]
        Flags: fast devsel, IRQ 255
        Memory at b0000000 (64-bit, prefetchable) [disabled] [size=256M]
        Memory at <unassigned> (64-bit, non-prefetchable) [disabled]
        I/O ports at 3000 [disabled] [size=256]
        [virtual] Expansion ROM at c0000000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
        Capabilities: [58] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
        Capabilities: [150] Advanced Error Reporting
Comment 1 Varban 2011-09-27 08:49:01 UTC
Updated to correct component
Comment 2 Alex Deucher 2011-09-29 11:54:46 UTC
You most likely have a mux-less system which means the radeon card is not actually connected to any physical displays as such there is no way for you to switch to the radeon card with vgaswitcheroo.  In order to support mux-less systems the xserver needs support for decoupling display and rendering and the drm needs support for sharing buffers between drivers.  This is a large amount of work and probably won't happen in the short term.
Comment 3 Varban 2011-09-29 12:26:16 UTC
(In reply to comment #2)
> You most likely have a mux-less system 

I'm not so sure about that.
First off, the ATI card is in a "Media Dock" which is not part of the laptop and is connected via Intel's Thunderbolt connector.
Second, the laptop and media dock have separate vga/hdmi ouputs, the HDMI on the media dock doesn't work, the HDMI on the laptop always works so I suspect the HDMI ports are not on a shared bus.
Third, in Windows, when a monitor is connected to the media dock it shows as connected to the ATI card (according to the hardware info) while the laptop screen is shown as connected to the Intel card.
And lastly, from the attached log:

[drm:intel_dsm_platform_mux_info], MUX info connectors: 7
[drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010100
[drm:intel_dsm_platform_mux_info],   port id: Analog VGA
[drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[drm:intel_dsm_platform_mux_info],   hpd mux info: unknown

I am not so certain this is really a hybrid system in the sense we've seen so far. I think the cards might be separate and drive the monitors independently. This would mean that I don't need vgaswitcheroo to switch to the radeon card and would be able to just use xinerama with 2 cards.

I will try to connect 2 different monitors to the 2 HDMI ports tonight and see what windows thinks is connected to what.
Comment 4 Varban 2011-10-13 10:36:48 UTC
In Windows, if a monitor is connected to a port on the laptop then it is shown as connected to the Intel card. If the monitor is connected to the external media dock then Windows shows it as connected to the Radeon card.

I played around with the fglrx proprietary driver (latest version 11.9) and I got two different results when my xorg.conf has 2 separate cards defined (fglrx and intel) vs only 1 card (fglrx only)

When defining 2 cards in xorg.conf I get this:

[  2060.069] (II) Loading sub module "fglrxdrm"
[  2060.069] (II) LoadModule: "fglrxdrm"
[  2060.069] (II) Loading /usr/lib/xorg/modules/linux/libfglrxdrm.so
[  2060.069] (II) Module fglrxdrm: vendor="FireGL - ATI Technologies Inc."
[  2060.069] 	compiled for 1.4.99.906, module version = 8.89.4
[  2060.072] ukiDynamicMajor: found major device number 252
[  2060.072] ukiDynamicMajor: found major device number 252
[  2060.072] ukiOpenByBusid: Searching for BusID PCI:22:0:0
[  2060.072] ukiOpenDevice: node name is /dev/ati/card0
[  2060.072] ukiOpenDevice: open result is 11, (OK)
[  2060.072] ukiOpenByBusid: ukiOpenMinor returns 11
[  2060.072] ukiOpenByBusid: ukiGetBusid reports PCI:22:0:0
[  2060.073] (==) fglrx(0): NoAccel = NO
[  2060.073] (==) fglrx(0): ATI 2D Acceleration Architecture enabled
[  2060.073] (--) fglrx(0): Chipset: "AMD Radeon HD 6700M Series" (Chipset = 0x6740)
[  2060.073] (--) fglrx(0): (PciSubVendor = 0x104d, PciSubDevice = 0x9084)
[  2060.073] (==) fglrx(0): board vendor info: third party graphics adapter - NOT original ATI
[  2060.073] (--) fglrx(0): Linear framebuffer (phys) at 0xb0000000
[  2060.073] (--) fglrx(0): MMIO registers at 0xc0200000
[  2060.073] (--) fglrx(0): I/O port at 0x00005000
[  2060.073] (==) fglrx(0): ROM-BIOS at 0x000c0000
[  2060.073] (II) fglrx(0): AC Adapter is used
[  2060.084] (II) fglrx(0): Invalid ATI BIOS from int10, the adapter is not VGA-enabled
[  2060.084] (EE) fglrx(0): Invalid video BIOS signature!
[  2060.084] (EE) fglrx(0): GetBIOSParameter failed
[  2060.084] (EE) fglrx(0): PreInitAdapter failed
[  2060.084] (EE) fglrx(0): PreInit failed


The invalid bios message.
However, when I only try to use 1 fglrx card (on pcibus 22:0:0), the driver correctly detects there an intel card and loads drivers for it but then blows up with another message:

[  1920.534] (WW) Falling back to old probe method for fglrx
[  1920.538] (II) Loading PCS database from /etc/ati/amdpcsdb
[  1920.538] (--) Chipset Supported AMD Graphics Processor (0x6740) found
[  1920.538] (WW) fglrx: No matching Device section for instance (BusID PCI:0@22:0:1) found
[  1920.538] (II) fglrx: intel VGA device detected, load intel driver.
[  1920.538] (II) LoadModule: "intel"
[  1920.539] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[  1920.539] (II) Module intel: vendor="X.Org Foundation"
[  1920.539] 	compiled for 1.11.0, module version = 2.16.0
[  1920.539] 	Module class: X.Org Video Driver
[  1920.539] 	ABI class: X.Org Video Driver, version 11.0
[  1920.540] ukiDynamicMajor: found major device number 252
[  1920.540] ukiDynamicMajor: found major device number 252
[  1920.540] ukiOpenByBusid: Searching for BusID PCI:22:0:0
[  1920.540] ukiOpenDevice: node name is /dev/ati/card0
[  1920.540] ukiOpenDevice: open result is 8, (OK)
[  1920.540] ukiOpenByBusid: ukiOpenMinor returns 8
[  1920.540] ukiOpenByBusid: ukiGetBusid reports PCI:22:0:0
[  1920.542] (WW) PowerXpress feature is not supported on A+I Mux platform. Please uninstall fglrx driver.
[  1920.542] (EE) No devices detected.
Comment 5 nover 2011-11-03 03:40:53 UTC
I have the same laptop, so I can second this. It would be really nice to have this working. 

As Varban has pointed out, the media dock does indeed have it's own HDMI and VGA ports.

And just to clarify, it's the Sony Vaio VPCZ2 model in question here.
Comment 6 DoTheDog 2011-11-04 08:37:52 UTC
Same issue here on the same hardward Sony Vaio VPCZ21 Power Media Dock. The USB and disk drive work. Just not the ATI video.

DoTheDog
Comment 7 nover 2011-11-14 13:26:42 UTC
I did some further testing on the matter of the ATI card in the PMD.

In windows, it's actually possible to have two screens connected via HDMI - one to the ATI card in the PMD, which is then "promoted" to be the primary graphics adapter, and one in the intel card.

So i guess this suggests that the ATI card is simply "another graphics card" connected to the computer? Only twist is that it's conneted via LightPeak/Thunderbolt...
Comment 8 gyhor 2012-01-05 01:58:26 UTC
I can confirm that. My Setup is a Sony VPC-Z21 (detail: VPCZ21C5321B) with the external PMD-Station.
The network, usb, diskrive are working. Only the graphic card refuses to get to work.

I am not sure, that theproblem is that the card is connect via LightPeak/Thunderbolt.
Comment 9 gyhor 2012-01-05 02:14:29 UTC
On this Site http://www.notebookcheck.net/Review-Sony-Vaio-VPC-Z21Q9E-B-Subnotebook.61141.0.html the author is mentioning that the ati card (they say it is a "HD 6650M") is controlled with the AMD XGP technology.

The FSC Amilo Sa3650 notebook uses the same technology.
Comment 10 gyhor 2012-01-10 05:59:45 UTC
With the ati-driver in windows i can configure how the system uses the PMD. 
1. as a gpu for the internal screen
2. as a graphic card for the external display

I think, that the card can used in both modes.
Comment 11 Alex Deucher 2012-01-10 06:55:22 UTC
windows supports decoupled display and rendering.
Comment 12 gyhor 2012-03-09 05:04:24 UTC
Is it possible to use the external connectors with the intel card?
I am only wanting to use the external dockingstation for the additionals connectors.
So if i can use vga and hdmi port from the dockingstaion with the intel card i would be very happy.


[   22.377284] [drm:intel_dsm_platform_mux_info], MUX info connectors: 7
[   22.377287] [drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010100
[   22.377290] [drm:intel_dsm_platform_mux_info],   port id: Analog VGA
[   22.377292] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[   22.377295] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[   22.377298] [drm:intel_dsm_platform_mux_info],   hpd mux info: unknown
[   22.377301] [drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010400
[   22.377303] [drm:intel_dsm_platform_mux_info],   port id: LVDS
[   22.377305] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[   22.377308] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[   22.377311] [drm:intel_dsm_platform_mux_info],   hpd mux info: unknown
[   22.377313] [drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010300
[   22.377315] [drm:intel_dsm_platform_mux_info],   port id: DisplayPort_B
[   22.377318] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[   22.377320] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[   22.377323] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between iGPU and dGPU
[   22.377326] [drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010301
[   22.377328] [drm:intel_dsm_platform_mux_info],   port id: HDMI/DVI_B
[   22.377331] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[   22.377334] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[   22.377336] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between iGPU and dGPU
[   22.377339] [drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010302
[   22.377342] [drm:intel_dsm_platform_mux_info],   port id: HDMI/DVI_C
[   22.377344] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[   22.377347] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[   22.377349] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between iGPU and dGPU
[   22.377352] [drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010303
[   22.377354] [drm:intel_dsm_platform_mux_info],   port id: DisplayPort_D
[   22.377357] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[   22.377360] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[   22.377362] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between iGPU and dGPU
[   22.377365] [drm:intel_dsm_platform_mux_info], Connector id: 0x0000000080010304
[   22.377367] [drm:intel_dsm_platform_mux_info],   port id: HDMI/DVI_D
[   22.377370] [drm:intel_dsm_platform_mux_info],   display mux info: MUXed between iGPU and dGPU
[   22.377373] [drm:intel_dsm_platform_mux_info],   aux/dc mux info: MUXed between iGPU and dGPU
[   22.377375] [drm:intel_dsm_platform_mux_info],   hpd mux info: MUXed between iGPU and dGPU
[   22.377383] [drm:intel_dsm_pci_probe], no _DSM method for intel device
Comment 13 Shiv Sikand 2012-05-10 10:11:47 UTC
I have a very similar issue to gyhor.

The driver gets really confused with the PCI busid.

lspci reports the ID as 16, but the driver thinks it's on 22.
Comment 14 Alex Deucher 2012-05-10 10:14:03 UTC
(In reply to comment #13)
> The driver gets really confused with the PCI busid.
> 
> lspci reports the ID as 16, but the driver thinks it's on 22.

they are the same.  0x16 (hex) = 22 (decimal)
Comment 15 Alexander E. Patrakov 2012-07-26 20:39:37 UTC
I also have an affected Sony VAIO laptop, and the failure mode is the same: cannot read BIOS on the AMD card. Is there any debugging information that I can provide (from Windows or from Linux)? Is the BIOS even supposed to be readable?
Comment 16 Ben Alex 2012-07-26 22:08:07 UTC
As per comment #15, I also have an affected Sony Vaio Z Series (model SVZ13115GGXI). Anything logs/debugs/tests I can provide to assist resolve this issue?
Comment 17 Alex Deucher 2012-07-26 22:16:41 UTC
Probably need to ask Sony where they store the discrete vbios on these systems.
Comment 18 gyhor 2012-07-30 08:45:42 UTC
Hi Alex,

what specific information do we need from sony? if I got through the first help desk, i should know what to ask :)
Comment 19 Alex Deucher 2012-07-30 13:37:42 UTC
Where the vbios (video bios) for the discrete card is stored (on a rom on the board, in the sbios (system bios), etc.).  If it's part of the sbios, there's probably an ACPI method (ROM or ATRM) to access it.
Comment 20 Alexander E. Patrakov 2012-08-04 16:14:09 UTC
I think that the card does have its BIOS, and the problem is really related to a misconfigured PCI bridge. Please take this with a grain of salt, as I am not a kernel hacker.

Some snippets from my dmesg that IMHO confirm this:

(just an interesting line, I didn't try this suggestion)
[    0.701044] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug

(here is the Radeon card)
[    0.722007] pci 0000:16:00.0: [1002:6740] type 00 class 0x030000
[    0.722073] pci 0000:16:00.0: reg 10: [mem 0xb0000000-0xbfffffff 64bit pref]
[    0.722125] pci 0000:16:00.0: reg 18: [mem 0xc0200000-0xc021ffff 64bit]
[    0.722159] pci 0000:16:00.0: reg 20: [io  0x5000-0x50ff]
[    0.722226] pci 0000:16:00.0: reg 30: [mem 0xfffe0000-0xffffffff pref]
[    0.722395] pci 0000:16:00.0: supports D1 D2

(and this is the bridge before it)
[    0.723054] pci 0000:15:03.0: PCI bridge to [bus 16-16]
[    0.723124] pci 0000:15:03.0:   bridge window [io  0x5000-0x5fff]
[    0.723132] pci 0000:15:03.0:   bridge window [mem 0xc0200000-0xc02fffff]
[    0.723149] pci 0000:15:03.0:   bridge window [mem 0xb0000000-0xbfffffff 64bit pref]

(this is vgaarb)
[    0.743085] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none
[    0.743186] vgaarb: device added: PCI:0000:16:00.0,decodes=io+mem,owns=none,locks=none
[    0.743265] vgaarb: loaded
[    0.743313] vgaarb: bridge control possible 0000:16:00.0
[    0.743367] vgaarb: no bridge control possible 0000:00:02.0

(here the kernel complains about the bug that ultimately leads to unreadability of the ROM)
[    0.773497] pci 0000:16:00.0: no compatible bridge window for [mem 0xfffe0000-0xffffffff pref]

(and tries to fix it up? still not good enough)
[    0.775668] pci 0000:16:00.0: BAR 6: assigned [mem 0xc0240000-0xc025ffff pref]
[    0.775745] pci 0000:15:03.0: PCI bridge to [bus 16-16]
[    0.775805] pci 0000:15:03.0:   bridge window [io  0x5000-0x5fff]
[    0.775872] pci 0000:15:03.0:   bridge window [mem 0xc0200000-0xc02fffff]
[    0.775937] pci 0000:15:03.0:   bridge window [mem 0xb0000000-0xbfffffff 64bit pref]

(so we still end up with lost resources)
[    0.778723] pci_bus 0000:15: resource 0 [io  0x3000-0x5fff]
[    0.778725] pci_bus 0000:15: resource 1 [mem 0xb0000000-0xc02fffff]
[    0.778726] pci_bus 0000:15: resource 2 [mem 0xd4400000-0xd44fffff 64bit pref]
[    0.778728] pci_bus 0000:16: resource 0 [io  0x5000-0x5fff]
[    0.778730] pci_bus 0000:16: resource 1 [mem 0xc0200000-0xc02fffff]
[    0.778731] pci_bus 0000:16: resource 2 [mem 0xb0000000-0xbfffffff 64bit pref]

So the main question is: why doesn't vgaarb (or who really has this job) reconfigure the bridge so that radeon can read the ROM?
Comment 21 Alexander E. Patrakov 2012-08-04 16:32:36 UTC
pci=nocrs doesn't help, and, if it is not clear from the previous comment, the ROM should be here:

16:00.0 0300: 1002:6740 (prog-if 00 [VGA controller])
        Subsystem: 104d:9084
        Physical Slot: 1-2
        Flags: fast devsel, IRQ 17
        Memory at b0000000 (64-bit, prefetchable) [size=256M]
        Memory at c0200000 (64-bit, non-prefetchable) [size=128K]
        I/O ports at 5000 [size=256]
        Expansion ROM at c0240000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
        Capabilities: [58] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
        Capabilities: [150] Advanced Error Reporting
Comment 22 Alexander E. Patrakov 2012-08-04 16:35:43 UTC
The same problem with the bridge is present in the dmesg attached by the original poster.
Comment 23 Alexander E. Patrakov 2012-08-04 17:02:31 UTC
Sorry for the noise about bridges. Of course the necessary address space for the ROM is in pci_bus 0000:15: resource 1, it's just strange that linux doesn't show the ROM on pci bus 0000:16: as a resource in dmesg.
Comment 24 Alex Deucher 2012-08-09 21:12:52 UTC
The patch on bug 26891 might help if this is a UEFI system.
Comment 25 gyhor 2012-08-10 12:11:40 UTC
i don't know why, but it don't get the VFCT Table.
this returns false:
(!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))
Comment 26 Alex Deucher 2012-08-10 13:50:54 UTC
(In reply to comment #25)
> i don't know why, but it don't get the VFCT Table.
> this returns false:
> (!ACPI_SUCCESS(acpi_get_table("VFCT", 1, &hdr)))

Then your system doesn't have the table.
Comment 27 Alexander E. Patrakov 2012-08-10 17:44:00 UTC
My Sony VAIO currently boots via MBR, in BIOS mode. There is nothing about UEFI in the BIOS setup screen. I am willing to convert the system and test the patch only if someone provides instructions how to test beforehand whether UEFI booting is supported on my system at all, without downloading files larger than 20 megabytes total. I have a 4gb USB flash drive with no important data that can be used as a test boot device.
Comment 28 Alex Deucher 2012-08-10 17:46:32 UTC
If you are not using UEFI and the system supports legacy mode, then there's no need to try the patch.
Comment 29 Alexander E. Patrakov 2012-08-12 15:40:48 UTC
Under Windows 7 Professional x64, I tried to use the "RW-Everything" tool to get information about the ROM of the AMD card. It failed, however, I don't know if it really means "you should not read this ROM" or just an incompatibility with Windows x64. Just for the record, it shows 0x00000000 as the expansion ROM base address for all PCI-like devices in the system.

However, in the "Option ROM information", it shows the PnP header and three option ROMs correctly. However, they are for the following vendor id / device id pairs, none of which seems relevant: 0x8086/0x0126 (the Intel graphics chip), 0x11ab/0x6121 (the Marvell IDE controller) and 0x8086/0x282a (the Intel fakeraid).
Comment 30 gyhor 2012-08-14 15:30:43 UTC
(In reply to comment #17)
> Probably need to ask Sony where they store the discrete vbios on these systems.

pfff... no hope here.
i wrote multiples mails and phoned the support service: They have no idea how to help us.
Comment 31 Alexander E. Patrakov 2012-08-14 17:05:38 UTC
Created attachment 65558 [details]
acpidump output

In http://mjg59.dreamwidth.org/15948.html , Matthew Garrett asked me to post acpidump output somewhere. So I am attaching it to this bug.
Comment 32 Matthew Garrett 2012-08-14 18:38:49 UTC
Could you add the full output of lspci -vvv when booted with the dock connected?
Comment 33 Alexander E. Patrakov 2012-08-15 03:20:42 UTC
Created attachment 65580 [details]
lspci -vvv output when booted with the dock
Comment 34 Alexander E. Patrakov 2012-08-16 05:34:28 UTC
In the acpidump output, there is ATRM method. I will try to add debug printks to  radeon_atrm_call() and report back.
Comment 35 gyhor 2012-08-16 08:39:35 UTC
Function radeon_atrm_call() would not be called, because 
if (!radeon_atrm_supported(rdev->pdev)) 
returns false.

Thats because this is returns null:
(!radeon_atpx_priv.atpx_detected)
Comment 36 Alexander E. Patrakov 2012-08-16 09:26:59 UTC
OK. So the bug is that the Sony BIOS provides ATRM, but not ATPX.
Comment 37 gyhor 2012-08-16 10:08:23 UTC
I am not sure. In function radeon_atpx_pci_probe_handle() do get the DEVICE_ACPI_HANDLE:

dhandle = DEVICE_ACPI_HANDLE(&pdev->dev);

It fails with 
status = acpi_get_handle(dhandle, "ATPX", &atpx_handle);


btw it is kernel 3.5RC7
Comment 38 Alex Deucher 2012-08-16 14:31:38 UTC
Please try the acpi_patches branch of my git tree:
http://cgit.freedesktop.org/~agd5f/linux/
Specifically this patch:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=acpi_patches&id=6c0775d89cf6a39f4d155c8ad53067a0768e31e0
Comment 39 Alexander E. Patrakov 2012-08-16 15:16:18 UTC
Unfortunately, your specific patch does not apply to the 3.5 kernel, so I cannot test this quickly. Now downloading your tree.
Comment 40 Alexander E. Patrakov 2012-08-16 17:05:27 UTC
I have built the kernel from your source tree. It found the card, found the HDMI-connected monitor and displayed boot text messages over it for some time (until it decided to move to the inteldrmfb framebuffer). Will test X a bit later.
Comment 41 Alexander E. Patrakov 2012-08-16 17:21:59 UTC
X works on radeon, too
Comment 42 Varban 2012-08-16 17:29:16 UTC
What settings did you use for the X server config or do the additional monitors just show as part of the intel card?

Any ideas when this patch will make it in the main line?

Did you try hotplugging the media dock rather than boot with it attached?

Thanks for the effort on troubleshooting this!
Comment 43 Alexander E. Patrakov 2012-08-16 17:37:28 UTC
The card is a completely separate card. One can create a very old-fashioned Xinerama-based dual-head setup using this (save as /etc/X11/xorg.conf.d/60-dualhead.conf):


Section "Device"
    Identifier "radeon"
    Driver "radeon"
    BusID "PCI:22:00:0"
EndSection

Section "Device"
    Identifier "intel"
    Driver "intel"
    BusID "PCI:00:02:0"
EndSection

Section "Screen"
    Identifier "Screen0"
    Device "radeon"
EndSection

Section "Screen"
    Identifier "Screen1"
    Device "intel"
EndSection

Section "ServerLayout"
    Identifier "DualHead"
    Screen "Screen0"
    Screen "Screen1" RightOf "Screen0"
    Option "Xinerama" "On"
EndSection


This is, however, deprecated, and I'd also like to know the modern way of doing this :)
Comment 44 Alexander E. Patrakov 2012-08-16 17:39:18 UTC
(In reply to comment #42)
> Any ideas when this patch will make it in the main line?

No idea.

> Did you try hotplugging the media dock rather than boot with it attached?

No, and with the static config above it doesn't make sense. Besides, GPU hotplug is not in the current X server.
Comment 45 Alex Deucher 2012-08-16 17:41:59 UTC
(In reply to comment #42)
> Any ideas when this patch will make it in the main line?

I've got it tentatively set for 3.7, but if I have time, I'll try and respin the patches for stable.
Comment 46 Alex Deucher 2012-08-16 18:23:52 UTC
Created attachment 65659 [details] [review]
fix for all kernels

Here's the patch broken out which should apply to all recent kernels.
Comment 47 Varban 2012-08-16 18:59:13 UTC
(In reply to comment #44)
> No, and with the static config above it doesn't make sense. Besides, GPU
> hotplug is not in the current X server.

If the card is separate then I'll probably play around with running two xservers that share a session, or something like it, so that I can kill one when I disconnect the media dock.

There do seem to be some issues around hotplugging and thunderbolt that are causing the USB hub in the media dock not to work but I hope they don't affect the GPU or they were caused by the GPU audio device crashing.
Comment 48 gyhor 2012-08-17 10:09:17 UTC
(In reply to comment #46)
> Created attachment 65659 [details] [review] [review]
> fix for all kernels
> 
> Here's the patch broken out which should apply to all recent kernels.

for kernel 3.5rc7 i needed additional this part in radeon_bios.c:
*** 32,37 ****
--- 32,40 ----
  
  #include <linux/vga_switcheroo.h>
  #include <linux/slab.h>
+ #ifdef CONFIG_ACPI
+ #include <linux/acpi.h>
+ #endif
  /*
   * BIOS.
   */
Comment 49 Alex Deucher 2012-08-17 13:09:02 UTC
Created attachment 65692 [details] [review]
upstream 1/2

This set of stable patches will apply cleanly.
Comment 50 Alex Deucher 2012-08-17 13:09:32 UTC
Created attachment 65693 [details] [review]
upstream 2/2

Second patch.
Comment 51 gyhor 2012-08-20 07:32:20 UTC
With this xorg.conf i can use two external monitor connected to the dockingstation.
Additionally the internal screen of the notebook is in textmode.
--
$cat /etc/X11/xorg.conf
Section "Device"
  Identifier "radeon"
  Driver "radeon"
  BusID "PCI:22:00:0"
EndSection

Section "Device"
  Identifier "intel"
  Driver "intel"
  BusID "PCI:00:02:0"
EndSection

Section "Screen"
  Identifier "Screen0"
  Device "radeon"
EndSection

Section "Screen"
  Identifier "Screen1"
  Device "intel"
EndSection
Comment 52 Florian Mickler 2012-09-05 20:41:16 UTC
A patch referencing this bug report has been merged in Linux v3.6-rc3:

commit c61e2775873f603148e8e998a938721b7d222d24
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Thu Aug 16 15:39:09 2012 -0400

    drm/radeon: split ATRM support out from the ATPX handler (v3)
Comment 53 Gerald Nunn 2012-12-28 03:34:05 UTC
Does AMD need to make a change to the proprietary fglrx drivers in order for the kernel patch to work with their drivers and if so has a bug been opened with them? I'm using Ubuntu 12.10 with kernel 3.6.9 and no problem getting this to work with the gallium (radeon) drivers, however when I try the fglrx drivers I get the following messages in kern.log:

Dec 27 13:07:11 gnunn-laptop2 kernel: [   11.925204] <3>[fglrx:hal_read_VBIOS] *ERROR* Invalid AMD VBIOS!
Dec 27 13:07:11 gnunn-laptop2 kernel: [   11.925207] <3>[fglrx:hal_init_gpu] *ERROR* Failed to read VBIOS!
Dec 27 13:07:11 gnunn-laptop2 kernel: [   11.925208] <6>[fglrx] device open failed with code -1

Which sounds like a similar issue to what was described here. While I generally find the gallium drivers to be more stable and reliable then fglrx, unfortunately fglrx significantly outperforms the open source drivers when it comes to gaming.
Comment 54 Michel Dänzer 2013-01-07 17:16:14 UTC
(In reply to comment #53)

Gerald, we can only support the open source drivers here. For fglrx issues you'll have to turn to fglrx support resources.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.