LinuxLists.cc - Intel graphics drm issue?

[permalink] [raw]

Subject: Re: Intel graphics drm issue?

Hi Mark,

[CCing intel-gfx]

On Fri, 12 October 2012 Mark Hounschell <[email protected]> wrote:
> Not sure this is the correct place to ask about a possible drm issue. I
> have an intel based PC with an HDMI port that I'm trying to connect to
> an LG TV. I have successfully used this HDMI port connected to an Optima
> projector. Using that projector, everything from the BIOS post, BIOS
> configuration, and all the way up to a graphical login worked just fine.
> The same HDMI port and cable connected to this TV gives me the below
> messages during boot. I also get no BIOS post or BIOS configuration
> output while in the BIOS. I have a monitor connected to the DVI port so
> I can see what I should see on the TV there, just as when I was
> connected to the Optima projector. That alone makes me pretty sure it's
> not a kernel issue but here are the messages anyway. Maybe they will
> give someone a hint as to what the problem may be, in the case they
> might be willing to give me any pointers.
>
> TV - LG 42lb9df
> PC - intel DH77DF motherboard

> [ 0.000000] Linux version 3.4.10-lcrs (root@geexbox) (gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) ) #1 SMP PREEMPT Wed Oct 10 16:16:16 EDT 2012
> ...
> [ 1.897955] [drm] MTRR allocation failed. Graphics performance may suffer.
> [ 1.898045] i915 0000:00:02.0: irq 43 for MSI/MSI-X
> [ 1.898050] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [ 1.898051] [drm] Driver supports precise vblank timestamp query.
> [ 1.898084] [drm:intel_dsm_platform_mux_info] *ERROR* MUX INFO call failed
> [ 1.898737] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
> [ 1.995523] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
> [ 2.299535] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128
> [ 2.299865] Raw EDID:
> [ 2.299957] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 2.300188] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 2.300418] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 2.300648] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 2.300879] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 2.301109] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 2.301339] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> [ 2.301569] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

This looks like your LG TV either does not provide EDID information via HDMI
connector, or otherwise behaves in a special way which makes reading EDID
fail.

Did you try the TV on some other computer to check if EDID can be read there
(e.g. with nvidia/amd GPU and matching open/closed driver)?

Also make sure the TV is on (neither off nor on stand-by) as some TVs
disable too much of connector interface in those states.

> [ 2.434378] i915 0000:00:02.0: HDMI-A-3: EDID block 0 invalid.
> [ 2.477539] checking generic (e0000000 3ff0000) vs hw (e0000000 10000000)
> [ 2.477541] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
> [ 2.477549] Console: switching to colour dummy device 80x25
> [ 2.477831] fbcon: inteldrmfb (fb0) is primary device
> [ 2.637915] Console: switching to colour frame buffer device 128x48
> [ 2.679625] fb0: inteldrmfb frame buffer device
> [ 2.679626] drm: registered panic notifier
> [ 2.691536] acpi device:4b: registered as cooling_device9
> [ 2.691660] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input4
> [ 2.691698] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
> [ 2.691709] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

> geexbox:/home/mplayer # lspci
> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09)
> ...
> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
> ...

Note, usually `lspci -nn` is more informative as it also provides vendor/device
IDs in addition to nice names.

Bruno

2012-10-13 18:57:09

[permalink] [raw]

Subject: Re: Intel graphics drm issue?

Hi Bruno,

Thanks for the response.

On 10/12/2012 05:14 PM, Bruno Pr?mont wrote:
> Hi Mark,
>
> [CCing intel-gfx]
>
> On Fri, 12 October 2012 Mark Hounschell <[email protected]> wrote:
>> Not sure this is the correct place to ask about a possible drm issue. I
>> have an intel based PC with an HDMI port that I'm trying to connect to
>> an LG TV. I have successfully used this HDMI port connected to an Optima
>> projector. Using that projector, everything from the BIOS post, BIOS
>> configuration, and all the way up to a graphical login worked just fine.
>> The same HDMI port and cable connected to this TV gives me the below
>> messages during boot. I also get no BIOS post or BIOS configuration
>> output while in the BIOS. I have a monitor connected to the DVI port so
>> I can see what I should see on the TV there, just as when I was
>> connected to the Optima projector. That alone makes me pretty sure it's
>> not a kernel issue but here are the messages anyway. Maybe they will
>> give someone a hint as to what the problem may be, in the case they
>> might be willing to give me any pointers.
>>
>> TV - LG 42lb9df
>> PC - intel DH77DF motherboard
>
>> [ 0.000000] Linux version 3.4.10-lcrs (root@geexbox) (gcc version 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) ) #1 SMP PREEMPT Wed Oct 10 16:16:16 EDT 2012
>> ...
>> [ 1.897955] [drm] MTRR allocation failed. Graphics performance may suffer.
>> [ 1.898045] i915 0000:00:02.0: irq 43 for MSI/MSI-X
>> [ 1.898050] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>> [ 1.898051] [drm] Driver supports precise vblank timestamp query.
>> [ 1.898084] [drm:intel_dsm_platform_mux_info] *ERROR* MUX INFO call failed
>> [ 1.898737] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
>> [ 1.995523] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
>> [ 2.299535] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128
>> [ 2.299865] Raw EDID:
>> [ 2.299957] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 2.300188] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 2.300418] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 2.300648] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 2.300879] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 2.301109] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 2.301339] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> [ 2.301569] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>
> This looks like your LG TV either does not provide EDID information via HDMI
> connector, or otherwise behaves in a special way which makes reading EDID
> fail.
>
> Did you try the TV on some other computer to check if EDID can be read there
> (e.g. with nvidia/amd GPU and matching open/closed driver)?
>
> Also make sure the TV is on (neither off nor on stand-by) as some TVs
> disable too much of connector interface in those states.
>

I have another AMD based PC here with an nvidia card and HDMI port. Using
the nvidia driver, it boots up with no output to the tv until X starts.
Once X starts I get my kdm login screen. All is well except the resolution
is 800x600 and I have no VTs. I suspect if I had a properly configured
xorg.conf file, my resolution would be what I defined in it and work.

Using the nouveau driver, I get nothing but "no signal" on the tv. Just
like the the intel box, except no EDID messages in the log file. I've
attached a dmesg outputs for each config.

Back on the Intel machine. I boot up with a normal monitor connected to the
DVI port of the PC. Then at the kdm login screen, I disconnect the DVI
cable from the PC and connect the TV to the PCs DVI port using a DVI/HDMI
adapter. I get a beautiful 1600x1200 resolution screen on the TV. This does
not happen using the PC HDMI port.

I have no control over the tv with regards to stand-by mode. Off is standby
mode, on is on.

>> [ 2.434378] i915 0000:00:02.0: HDMI-A-3: EDID block 0 invalid.
>> [ 2.477539] checking generic (e0000000 3ff0000) vs hw (e0000000 10000000)
>> [ 2.477541] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
>> [ 2.477549] Console: switching to colour dummy device 80x25
>> [ 2.477831] fbcon: inteldrmfb (fb0) is primary device
>> [ 2.637915] Console: switching to colour frame buffer device 128x48
>> [ 2.679625] fb0: inteldrmfb frame buffer device
>> [ 2.679626] drm: registered panic notifier
>> [ 2.691536] acpi device:4b: registered as cooling_device9
>> [ 2.691660] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input4
>> [ 2.691698] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
>> [ 2.691709] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
>
>> geexbox:/home/mplayer # lspci
>> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09)
>> ...
>> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09)
>> ...
>
> Note, usually `lspci -nn` is more informative as it also provides vendor/device
> IDs in addition to nice names.

# lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
processor DRAM Controller [8086:0150] (rev 09)
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
processor PCI Express Root Port [8086:0151] (rev 09)
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200
v2/3rd Gen Core processor Graphics Controller [8086:0162] (rev 09)
00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210
Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
00:19.0 Ethernet controller [0200]: Intel Corporation 82579V Gigabit
Network Connection [8086:1503] (rev 04)
00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 1 [8086:1e10] (rev c4)
00:1c.7 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 8 [8086:1e1e] (rev c4)
00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
00:1f.0 ISA bridge [0601]: Intel Corporation H77 Express Chipset LPC
Controller [8086:1e4a] (rev 04)
00:1f.2 SATA controller [0106]: Intel Corporation 7 Series/C210 Series
Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e02] (rev 04)
00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family
SMBus Controller [8086:1e22] (rev 04)
01:00.0 PCI bridge [0604]: PLX Technology, Inc. PEX8112 x1 Lane PCI
Express-to-PCI Bridge [10b5:8112] (rev aa)
02:04.0 Multimedia audio controller [0401]: C-Media Electronics Inc CMI8788
[Oxygen HD Audio] [13f6:8788]

I can do more to help if asked.

Regards
Mark

Attachments:

dmesg.nvidia-hdmi (55.85 kB)
dmesg.nouveau-hdmi (55.01 kB)
Download all attachments

2012-10-13 19:17:50

[permalink] [raw]

Subject: Re: Intel graphics drm issue?

On 10/13/2012 02:57 PM, Mark Hounschell wrote:
> Hi Bruno,
>
> Thanks for the response.
>
> On 10/12/2012 05:14 PM, Bruno Prémont wrote:
>> Hi Mark,
>>
>> [CCing intel-gfx]
>>
>> On Fri, 12 October 2012 Mark Hounschell <[email protected]> wrote:
>>> Not sure this is the correct place to ask about a possible drm issue. I
>>> have an intel based PC with an HDMI port that I'm trying to connect to
>>> an LG TV. I have successfully used this HDMI port connected to an Optima
>>> projector. Using that projector, everything from the BIOS post, BIOS
>>> configuration, and all the way up to a graphical login worked just fine.
>>> The same HDMI port and cable connected to this TV gives me the below
>>> messages during boot. I also get no BIOS post or BIOS configuration
>>> output while in the BIOS. I have a monitor connected to the DVI port so
>>> I can see what I should see on the TV there, just as when I was
>>> connected to the Optima projector. That alone makes me pretty sure it's
>>> not a kernel issue but here are the messages anyway. Maybe they will
>>> give someone a hint as to what the problem may be, in the case they
>>> might be willing to give me any pointers.
>>>
>>> TV - LG 42lb9df
>>> PC - intel DH77DF motherboard
>>
>>> [ 0.000000] Linux version 3.4.10-lcrs (root@geexbox) (gcc version
>>> 4.7.1 20120723 [gcc-4_7-branch revision 189773] (SUSE Linux) ) #1 SMP
>>> PREEMPT Wed Oct 10 16:16:16 EDT 2012
>>> ...
>>> [ 1.897955] [drm] MTRR allocation failed. Graphics performance may
>>> suffer.
>>> [ 1.898045] i915 0000:00:02.0: irq 43 for MSI/MSI-X
>>> [ 1.898050] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
>>> [ 1.898051] [drm] Driver supports precise vblank timestamp query.
>>> [ 1.898084] [drm:intel_dsm_platform_mux_info] *ERROR* MUX INFO call
>>> failed
>>> [ 1.898737] vgaarb: device changed decodes:
>>> PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
>>> [ 1.995523] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
>>> [ 2.299535] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
>>> invalid, remainder is 128
>>> [ 2.299865] Raw EDID:
>>> [ 2.299957] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> [ 2.300188] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> [ 2.300418] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> [ 2.300648] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> [ 2.300879] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> [ 2.301109] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> [ 2.301339] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>> [ 2.301569] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>>
>> This looks like your LG TV either does not provide EDID information via HDMI
>> connector, or otherwise behaves in a special way which makes reading EDID
>> fail.
>>
>> Did you try the TV on some other computer to check if EDID can be read there
>> (e.g. with nvidia/amd GPU and matching open/closed driver)?
>>
>> Also make sure the TV is on (neither off nor on stand-by) as some TVs
>> disable too much of connector interface in those states.
>>
>
> I have another AMD based PC here with an nvidia card and HDMI port. Using
> the nvidia driver, it boots up with no output to the tv until X starts.
> Once X starts I get my kdm login screen. All is well except the resolution
> is 800x600 and I have no VTs. I suspect if I had a properly configured
> xorg.conf file, my resolution would be what I defined in it and work.
>
> Using the nouveau driver, I get nothing but "no signal" on the tv. Just
> like the the intel box, except no EDID messages in the log file. I've
> attached a dmesg outputs for each config.
>
> Back on the Intel machine. I boot up with a normal monitor connected to the
> DVI port of the PC. Then at the kdm login screen, I disconnect the DVI
> cable from the PC and connect the TV to the PCs DVI port using a DVI/HDMI
> adapter. I get a beautiful 1600x1200 resolution screen on the TV. This does
> not happen using the PC HDMI port.
>

One other thing I failed to mention. If i connect the TV HDMI to the Intel
boards DVI port using the adapter, at power up I get all the BIOS messages
and can enter the BIOS and all is fine. But when I let it boot all the way
up like this, I get nothing but "no signal" after leaving BIOS mode.
Turning the tv on/off, cable plug/unplug does not help.

Mark

> I have no control over the tv with regards to stand-by mode. Off is standby
> mode, on is on.
>
>>> [ 2.434378] i915 0000:00:02.0: HDMI-A-3: EDID block 0 invalid.
>>> [ 2.477539] checking generic (e0000000 3ff0000) vs hw (e0000000
>>> 10000000)
>>> [ 2.477541] fb: conflicting fb hw usage inteldrmfb vs VESA VGA -
>>> removing generic driver
>>> [ 2.477549] Console: switching to colour dummy device 80x25
>>> [ 2.477831] fbcon: inteldrmfb (fb0) is primary device
>>> [ 2.637915] Console: switching to colour frame buffer device 128x48
>>> [ 2.679625] fb0: inteldrmfb frame buffer device
>>> [ 2.679626] drm: registered panic notifier
>>> [ 2.691536] acpi device:4b: registered as cooling_device9
>>> [ 2.691660] input: Video Bus as
>>> /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input4
>>> [ 2.691698] ACPI: Video Device [GFX0] (multi-head: yes rom: no
>>> post: no)
>>> [ 2.691709] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on
>>> minor 0
>>
>>> geexbox:/home/mplayer # lspci
>>> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
>>> processor DRAM Controller (rev 09)
>>> ...
>>> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd
>>> Gen Core processor Graphics Controller (rev 09)
>>> ...
>>
>> Note, usually `lspci -nn` is more informative as it also provides
>> vendor/device
>> IDs in addition to nice names.
>
> # lspci -nn
> 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
> processor DRAM Controller [8086:0150] (rev 09)
> 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
> processor PCI Express Root Port [8086:0151] (rev 09)
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200
> v2/3rd Gen Core processor Graphics Controller [8086:0162] (rev 09)
> 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
> Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
> 00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210
> Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
> 00:19.0 Ethernet controller [0200]: Intel Corporation 82579V Gigabit
> Network Connection [8086:1503] (rev 04)
> 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
> Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
> 00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset
> Family PCI Express Root Port 1 [8086:1e10] (rev c4)
> 00:1c.7 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset
> Family PCI Express Root Port 8 [8086:1e1e] (rev c4)
> 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
> Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
> 00:1f.0 ISA bridge [0601]: Intel Corporation H77 Express Chipset LPC
> Controller [8086:1e4a] (rev 04)
> 00:1f.2 SATA controller [0106]: Intel Corporation 7 Series/C210 Series
> Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e02] (rev 04)
> 00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family
> SMBus Controller [8086:1e22] (rev 04)
> 01:00.0 PCI bridge [0604]: PLX Technology, Inc. PEX8112 x1 Lane PCI
> Express-to-PCI Bridge [10b5:8112] (rev aa)
> 02:04.0 Multimedia audio controller [0401]: C-Media Electronics Inc CMI8788
> [Oxygen HD Audio] [13f6:8788]
>
>
> I can do more to help if asked.
>
> Regards
> Mark

2012-10-14 08:42:42

[permalink] [raw]

Subject: Re: Intel graphics drm issue?

Hi Mark,

On Sat, 13 October 2012 Mark Hounschell <[email protected]> wrote:
> On 10/13/2012 02:57 PM, Mark Hounschell wrote:
> > On 10/12/2012 05:14 PM, Bruno Prémont wrote:
> >>> TV - LG 42lb9df
> >>> PC - intel DH77DF motherboard
> >>
> > I have another AMD based PC here with an nvidia card and HDMI port. Using
> > the nvidia driver, it boots up with no output to the tv until X starts.
> > Once X starts I get my kdm login screen. All is well except the resolution
> > is 800x600 and I have no VTs. I suspect if I had a properly configured
> > xorg.conf file, my resolution would be what I defined in it and work.
> >
> > Using the nouveau driver, I get nothing but "no signal" on the tv. Just
> > like the the intel box, except no EDID messages in the log file. I've
> > attached a dmesg outputs for each config.
> >
> > Back on the Intel machine. I boot up with a normal monitor connected to the
> > DVI port of the PC. Then at the kdm login screen, I disconnect the DVI
> > cable from the PC and connect the TV to the PCs DVI port using a DVI/HDMI
> > adapter. I get a beautiful 1600x1200 resolution screen on the TV. This does
> > not happen using the PC HDMI port.
> >
>
> One other thing I failed to mention. If i connect the TV HDMI to the Intel
> boards DVI port using the adapter, at power up I get all the BIOS messages
> and can enter the BIOS and all is fine. But when I let it boot all the way
> up like this, I get nothing but "no signal" after leaving BIOS mode.
> Turning the tv on/off, cable plug/unplug does not help.

Did you also try the DVI-HDMI adapter cable with the nVidia card?

But will all that info I would say the issues is at the side of you TV that
just does not provide (valid) EDID information, thus the driver does not know
what the display supports.

The 1600x1200 when switching DVI displays on Intel would seem like the driver
just kept on display what it had, not reconfiguring anything.

For the 800x600 of nVidia, that kind of the default fallback when display
capabilities are unknown as any remotely recent display should alt least be
capable to understand that.

Your best solution is probably to write an EDID blob (or reuse one you find
somewhere) that provides at least one mode matching your TV's native mode
(probably full-HD).

Google suggested the following document:
http://www.jordansmanuals.com/ServiceManuals%5CLG%5CTV%5CLCD%5C42LB9DF%5C42LB9DF%20Service%20Manual.pdf
which on page 13/14 shows the full EDID blob for the various HDMI outputs of the
TV. You may want to read that document, convert the EDID blobs to 512 bytes binary
files and hell DRM core to use the right one via module/kernel cmdline option:

drm_kms_helper.edid_firmware=edid/lg42lb9df.edid
or
modprobe drm-kms-helper edid_firmware=edid/lg42lb9df.edid

where
/lib/firmware/edid/lg42lb9df.edid
is the 512-bytes EDID blob created according to data from above manual.
(note, that will only work for intel, radeon and nouveau drivers but will
not work for closed drivers of AMD/nVidia)

PS: If you didn't already do so, try all of the HDMI connectors or the TV and
if available, also two distinct HDMI cables of different brand.

Bruno

> Mark
>
> > I have no control over the tv with regards to stand-by mode. Off is standby
> > mode, on is on.
> >
> >>> [ 2.434378] i915 0000:00:02.0: HDMI-A-3: EDID block 0 invalid.
> >>> [ 2.477539] checking generic (e0000000 3ff0000) vs hw (e0000000
> >>> 10000000)
> >>> [ 2.477541] fb: conflicting fb hw usage inteldrmfb vs VESA VGA -
> >>> removing generic driver
> >>> [ 2.477549] Console: switching to colour dummy device 80x25
> >>> [ 2.477831] fbcon: inteldrmfb (fb0) is primary device
> >>> [ 2.637915] Console: switching to colour frame buffer device 128x48
> >>> [ 2.679625] fb0: inteldrmfb frame buffer device
> >>> [ 2.679626] drm: registered panic notifier
> >>> [ 2.691536] acpi device:4b: registered as cooling_device9
> >>> [ 2.691660] input: Video Bus as
> >>> /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input4
> >>> [ 2.691698] ACPI: Video Device [GFX0] (multi-head: yes rom: no
> >>> post: no)
> >>> [ 2.691709] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on
> >>> minor 0
> >>
> >>> geexbox:/home/mplayer # lspci
> >>> 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
> >>> processor DRAM Controller (rev 09)
> >>> ...
> >>> 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd
> >>> Gen Core processor Graphics Controller (rev 09)
> >>> ...
> >>
> >> Note, usually `lspci -nn` is more informative as it also provides
> >> vendor/device
> >> IDs in addition to nice names.
> >
> > # lspci -nn
> > 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
> > processor DRAM Controller [8086:0150] (rev 09)
> > 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
> > processor PCI Express Root Port [8086:0151] (rev 09)
> > 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200
> > v2/3rd Gen Core processor Graphics Controller [8086:0162] (rev 09)
> > 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
> > Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
> > 00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210
> > Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
> > 00:19.0 Ethernet controller [0200]: Intel Corporation 82579V Gigabit
> > Network Connection [8086:1503] (rev 04)
> > 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
> > Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
> > 00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset
> > Family PCI Express Root Port 1 [8086:1e10] (rev c4)
> > 00:1c.7 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset
> > Family PCI Express Root Port 8 [8086:1e1e] (rev c4)
> > 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
> > Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
> > 00:1f.0 ISA bridge [0601]: Intel Corporation H77 Express Chipset LPC
> > Controller [8086:1e4a] (rev 04)
> > 00:1f.2 SATA controller [0106]: Intel Corporation 7 Series/C210 Series
> > Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e02] (rev 04)
> > 00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family
> > SMBus Controller [8086:1e22] (rev 04)
> > 01:00.0 PCI bridge [0604]: PLX Technology, Inc. PEX8112 x1 Lane PCI
> > Express-to-PCI Bridge [10b5:8112] (rev aa)
> > 02:04.0 Multimedia audio controller [0401]: C-Media Electronics Inc CMI8788
> > [Oxygen HD Audio] [13f6:8788]
> >
> >
> > I can do more to help if asked.
> >
> > Regards
> > Mark
>
>

2012-10-14 08:59:03

[permalink] [raw]

Subject: Re: [Intel-gfx] Intel graphics drm issue?

On Sat, Oct 13, 2012 at 9:17 PM, Mark Hounschell <[email protected]> wrote:
> One other thing I failed to mention. If i connect the TV HDMI to the Intel
> boards DVI port using the adapter, at power up I get all the BIOS messages
> and can enter the BIOS and all is fine. But when I let it boot all the way
> up like this, I get nothing but "no signal" after leaving BIOS mode. Turning
> the tv on/off, cable plug/unplug does not help.

Can you please boot in that configuration on latest kernel with
drm.debug=0xe added to your kernel cmdline and then attach the
complete dmesg?

Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

2012-10-14 10:20:34

[permalink] [raw]

Subject: Re: [Intel-gfx] Intel graphics drm issue?

On 10/14/2012 04:58 AM, Daniel Vetter wrote:
> On Sat, Oct 13, 2012 at 9:17 PM, Mark Hounschell <[email protected]> wrote:
>> One other thing I failed to mention. If i connect the TV HDMI to the Intel
>> boards DVI port using the adapter, at power up I get all the BIOS messages
>> and can enter the BIOS and all is fine. But when I let it boot all the way
>> up like this, I get nothing but "no signal" after leaving BIOS mode. Turning
>> the tv on/off, cable plug/unplug does not help.
>
> Can you please boot in that configuration on latest kernel with
> drm.debug=0xe added to your kernel cmdline and then attach the
> complete dmesg?

Hi Daniel,

cat /proc/cmdline
root=/dev/disk/by-id/ata-INTEL_SSDSC2CW060A3_CVCV205106EB060AGN-part4
video=1024x768 noresume splash=silent quiet apm=off nomodeset vga=normal
drm.debug=0xe

dmesg is attached

Mark

Attachments:

dmesg-intel-dvi2hdmi-3.6.2 (48.05 kB)

2012-10-14 10:34:58

[permalink] [raw]

Subject: Re: Intel graphics drm issue?

On 10/14/2012 04:41 AM, Bruno Prémont wrote:
> Hi Mark,
>
> On Sat, 13 October 2012 Mark Hounschell <[email protected]> wrote:
>> On 10/13/2012 02:57 PM, Mark Hounschell wrote:
>>> On 10/12/2012 05:14 PM, Bruno Prémont wrote:
>>>>> TV - LG 42lb9df
>>>>> PC - intel DH77DF motherboard
>>>>
>>> I have another AMD based PC here with an nvidia card and HDMI port. Using
>>> the nvidia driver, it boots up with no output to the tv until X starts.
>>> Once X starts I get my kdm login screen. All is well except the resolution
>>> is 800x600 and I have no VTs. I suspect if I had a properly configured
>>> xorg.conf file, my resolution would be what I defined in it and work.
>>>
>>> Using the nouveau driver, I get nothing but "no signal" on the tv. Just
>>> like the the intel box, except no EDID messages in the log file. I've
>>> attached a dmesg outputs for each config.
>>>
>>> Back on the Intel machine. I boot up with a normal monitor connected to the
>>> DVI port of the PC. Then at the kdm login screen, I disconnect the DVI
>>> cable from the PC and connect the TV to the PCs DVI port using a DVI/HDMI
>>> adapter. I get a beautiful 1600x1200 resolution screen on the TV. This does
>>> not happen using the PC HDMI port.
>>>
>>
>> One other thing I failed to mention. If i connect the TV HDMI to the Intel
>> boards DVI port using the adapter, at power up I get all the BIOS messages
>> and can enter the BIOS and all is fine. But when I let it boot all the way
>> up like this, I get nothing but "no signal" after leaving BIOS mode.
>> Turning the tv on/off, cable plug/unplug does not help.
>
> Did you also try the DVI-HDMI adapter cable with the nVidia card?
>

No, I didn't try that. I certainly can though.

> But will all that info I would say the issues is at the side of you TV that
> just does not provide (valid) EDID information, thus the driver does not know
> what the display supports.
>
> The 1600x1200 when switching DVI displays on Intel would seem like the driver
> just kept on display what it had, not reconfiguring anything.
>

Right, that's what I thought was happening. But at least it tells me that
the tv can in fact "probably" operate in whatever resolution I force it to.
Is there no way, like in the past we had to do, to just not care what the
tv/monitor says or does, and just use a fixed resolution?

> For the 800x600 of nVidia, that kind of the default fallback when display
> capabilities are unknown as any remotely recent display should alt least be
> capable to understand that.
>

Yep, that's what I figured here too. nvidia provides a "default/fallback"
so you can at least access the desktop. Seems a reasonable thing, no?

>
> Your best solution is probably to write an EDID blob (or reuse one you find
> somewhere) that provides at least one mode matching your TV's native mode
> (probably full-HD).
>
> Google suggested the following document:
> http://www.jordansmanuals.com/ServiceManuals%5CLG%5CTV%5CLCD%5C42LB9DF%5C42LB9DF%20Service%20Manual.pdf
> which on page 13/14 shows the full EDID blob for the various HDMI outputs of the
> TV. You may want to read that document, convert the EDID blobs to 512 bytes binary
> files and hell DRM core to use the right one via module/kernel cmdline option:
>
> drm_kms_helper.edid_firmware=edid/lg42lb9df.edid
> or
> modprobe drm-kms-helper edid_firmware=edid/lg42lb9df.edid
>
> where
> /lib/firmware/edid/lg42lb9df.edid
> is the 512-bytes EDID blob created according to data from above manual.
> (note, that will only work for intel, radeon and nouveau drivers but will
> not work for closed drivers of AMD/nVidia)
>

Thanks for this tip. I will investigate this asap.

> PS: If you didn't already do so, try all of the HDMI connectors or the TV and
> if available, also two distinct HDMI cables of different brand.

Did all that, first thing.

Thanks
Mark

2012-10-14 10:52:47

[permalink] [raw]

Subject: Re: Intel graphics drm issue?

On 10/14/2012 04:41 AM, Bruno Prémont wrote:

>
> Your best solution is probably to write an EDID blob (or reuse one you find
> somewhere) that provides at least one mode matching your TV's native mode
> (probably full-HD).
>
> Google suggested the following document:
> http://www.jordansmanuals.com/ServiceManuals%5CLG%5CTV%5CLCD%5C42LB9DF%5C42LB9DF%20Service%20Manual.pdf
> which on page 13/14 shows the full EDID blob for the various HDMI outputs of the
> TV. You may want to read that document, convert the EDID blobs to 512 bytes binary
> files and hell DRM core to use the right one via module/kernel cmdline option:
>
> drm_kms_helper.edid_firmware=edid/lg42lb9df.edid
> or
> modprobe drm-kms-helper edid_firmware=edid/lg42lb9df.edid
>
> where
> /lib/firmware/edid/lg42lb9df.edid
> is the 512-bytes EDID blob created according to data from above manual.
> (note, that will only work for intel, radeon and nouveau drivers but will
> not work for closed drivers of AMD/nVidia)
>

This certainly looks doable. That firmware file, should it contain all 4
tables or just the one for the port I'm connected to? Will it matter what
order they were in?

Thanks
Mark

2012-10-14 11:04:24

[permalink] [raw]

Subject: Re: Intel graphics drm issue?

On Sun, 14 October 2012 Mark Hounschell <[email protected]> wrote:
> On 10/14/2012 04:41 AM, Bruno Prémont wrote:
> > Your best solution is probably to write an EDID blob (or reuse one you find
> > somewhere) that provides at least one mode matching your TV's native mode
> > (probably full-HD).
> >
> > Google suggested the following document:
> > http://www.jordansmanuals.com/ServiceManuals%5CLG%5CTV%5CLCD%5C42LB9DF%5C42LB9DF%20Service%20Manual.pdf
> > which on page 13/14 shows the full EDID blob for the various HDMI outputs of the
> > TV. You may want to read that document, convert the EDID blobs to 512 bytes binary
> > files and hell DRM core to use the right one via module/kernel cmdline option:
> >
> > drm_kms_helper.edid_firmware=edid/lg42lb9df.edid
> > or
> > modprobe drm-kms-helper edid_firmware=edid/lg42lb9df.edid
> >
> > where
> > /lib/firmware/edid/lg42lb9df.edid
> > is the 512-bytes EDID blob created according to data from above manual.
> > (note, that will only work for intel, radeon and nouveau drivers but will
> > not work for closed drivers of AMD/nVidia)
> >
>
> This certainly looks doable. That firmware file, should it contain all 4
> tables or just the one for the port I'm connected to? Will it matter what
> order they were in?

It should contain just the table for the port you're connected to.
For the HDMI ports the tables are 1024 bytes (e.g. two 512 bytes blocks,
not just one as I incorrectly wrote above). For the VGA port it's just one
512 bytes block.

Oh, and check the exact documentation of edid_firmware parameter as you can
adjust its value to tell kernel to which connector exactly it applies
(otherwise it will overwrite the EDID on other ports with working displays!).

Bruno

> Thanks
> Mark
>

2012-10-14 11:26:48

[permalink] [raw]

Subject: Re: [Intel-gfx] Intel graphics drm issue?

On Sun, Oct 14, 2012 at 12:20 PM, Mark Hounschell <[email protected]> wrote:
> Hi Daniel,
>
> cat /proc/cmdline
> root=/dev/disk/by-id/ata-INTEL_SSDSC2CW060A3_CVCV205106EB060AGN-part4
> video=1024x768 noresume splash=silent quiet apm=off nomodeset vga=normal
> drm.debug=0xe
>
> dmesg is attached

>From the dmesg:

[ 1.833195] [drm:drm_pci_agp_init] *ERROR* Cannot initialize the
agpgart module.

Which is the root-cause preventing i915.ko from loading. Now with 3.7
we /shouldn't/ all that agp crap any longer on snb/ivb, so I'm a bit
confused why it still tries to initialize it. Can you maybe attach
your .config?

Also, we need to employ some dirty runtime tricks to no longer require
agp on newer chips, since we still need to keep it around for
backwards-compat with old userspace on old chips. Can you please check
with the below diff whether this hack works?

Thanks, Daniel

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7837e5..1152502 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -842,6 +842,7 @@ i915_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (intel_info->gen != 3) {
driver.driver_features &=
~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP);
+ printk("dropping agp requirement\n");
} else if (!intel_agp_enabled) {
DRM_ERROR("drm/i915 can't work without intel_agp module!\n");
return -ENODEV;

--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

2012-10-14 11:39:24

[permalink] [raw]

Subject: Re: [Intel-gfx] Intel graphics drm issue?

On 10/14/2012 07:26 AM, Daniel Vetter wrote:
> On Sun, Oct 14, 2012 at 12:20 PM, Mark Hounschell <[email protected]> wrote:
>> Hi Daniel,
>>
>> cat /proc/cmdline
>> root=/dev/disk/by-id/ata-INTEL_SSDSC2CW060A3_CVCV205106EB060AGN-part4
>> video=1024x768 noresume splash=silent quiet apm=off nomodeset vga=normal
>> drm.debug=0xe
>>
>> dmesg is attached
>
>>From the dmesg:
>
> [ 1.833195] [drm:drm_pci_agp_init] *ERROR* Cannot initialize the
> agpgart module.
>
> Which is the root-cause preventing i915.ko from loading. Now with 3.7
> we /shouldn't/ all that agp crap any longer on snb/ivb, so I'm a bit
> confused why it still tries to initialize it. Can you maybe attach
> your .config?
>

Did you mean 3.6 above? I used 3.6.2? If I'm using the right kernel I will
apply the patch and try. Let me know.

> Also, we need to employ some dirty runtime tricks to no longer require
> agp on newer chips, since we still need to keep it around for
> backwards-compat with old userspace on old chips. Can you please check
> with the below diff whether this hack works?
>
> Thanks, Daniel
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index a7837e5..1152502 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -842,6 +842,7 @@ i915_pci_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> if (intel_info->gen != 3) {
> driver.driver_features &=
> ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP);
> + printk("dropping agp requirement\n");
> } else if (!intel_agp_enabled) {
> DRM_ERROR("drm/i915 can't work without intel_agp module!\n");
> return -ENODEV;
>

Doesn't this patch only add a printk? Is that what you want me to do?

Mark

2012-10-14 14:19:13

[permalink] [raw]

Subject: Re: [Intel-gfx] Intel graphics drm issue?

On 10/14/2012 07:26 AM, Daniel Vetter wrote:
> On Sun, Oct 14, 2012 at 12:20 PM, Mark Hounschell <[email protected]> wrote:
>> Hi Daniel,
>>
>> cat /proc/cmdline
>> root=/dev/disk/by-id/ata-INTEL_SSDSC2CW060A3_CVCV205106EB060AGN-part4
>> video=1024x768 noresume splash=silent quiet apm=off nomodeset vga=normal
>> drm.debug=0xe
>>
>> dmesg is attached
>
>>From the dmesg:
>
> [ 1.833195] [drm:drm_pci_agp_init] *ERROR* Cannot initialize the
> agpgart module.
>
> Which is the root-cause preventing i915.ko from loading. Now with 3.7
> we /shouldn't/ all that agp crap any longer on snb/ivb, so I'm a bit
> confused why it still tries to initialize it. Can you maybe attach
> your .config?
>
> Also, we need to employ some dirty runtime tricks to no longer require
> agp on newer chips, since we still need to keep it around for
> backwards-compat with old userspace on old chips. Can you please check
> with the below diff whether this hack works?
>
> Thanks, Daniel
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index a7837e5..1152502 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -842,6 +842,7 @@ i915_pci_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> if (intel_info->gen != 3) {
> driver.driver_features &=
> ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP);
> + printk("dropping agp requirement\n");
> } else if (!intel_agp_enabled) {
> DRM_ERROR("drm/i915 can't work without intel_agp module!\n");
> return -ENODEV;
>

OK. Applied to 3.6.2. The dmesg is attached. The message did not show up.
I'll be here most of the day.

Mark

Attachments:

dmesg-dvi2hdmi-3.6.2-1 (48.13 kB)

2012-10-14 14:40:12

[permalink] [raw]

Subject: Re: [Intel-gfx] Intel graphics drm issue?

On Sun, Oct 14, 2012 at 4:19 PM, Mark Hounschell <[email protected]> wrote:
> OK. Applied to 3.6.2. The dmesg is attached. The message did not show up.
> I'll be here most of the day.

Ok, that at least confirms my suspicion (and yeah, I've mis-remembered
when I've merged the agp removal for gen6+, it's already all done in
3.6). But I have no idea how that could fail this way. New little
debug patch:

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a24ffbe..7ec35c5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -848,6 +848,11 @@ i915_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return -ENODEV;
}

+ printk("force-disabling agp on gen %i, is_ivybridge %i\n",
+ intel_info->gen, intel_info->is_ivybridge);
+
+ driver.driver_features &=
+ ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP);
return drm_get_pci_dev(pdev, ent, &driver);
}

Yours, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

2012-10-14 15:41:16

[permalink] [raw]

Subject: Re: [Intel-gfx] Intel graphics drm issue?

On 10/14/2012 10:40 AM, Daniel Vetter wrote:
> On Sun, Oct 14, 2012 at 4:19 PM, Mark Hounschell <[email protected]> wrote:
>> OK. Applied to 3.6.2. The dmesg is attached. The message did not show up.
>> I'll be here most of the day.
>
> Ok, that at least confirms my suspicion (and yeah, I've mis-remembered
> when I've merged the agp removal for gen6+, it's already all done in
> 3.6). But I have no idea how that could fail this way. New little
> debug patch:
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index a24ffbe..7ec35c5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -848,6 +848,11 @@ i915_pci_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> return -ENODEV;
> }
>
> + printk("force-disabling agp on gen %i, is_ivybridge %i\n",
> + intel_info->gen, intel_info->is_ivybridge);
> +
> + driver.driver_features &=
> + ~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP);
> return drm_get_pci_dev(pdev, ent, &driver);
> }
>
> Yours, Daniel
>

There is something amiss. Here is my i915_pci_probe routine. I Added a
couple more printks. NONE of these show up in dmesg. Not even the "Entered"
printk. ????

static int __devinit
i915_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
struct intel_device_info *intel_info =
(struct intel_device_info *) ent->driver_data;

printk("i915_pci_probe: Entered\n");

/* Only bind to function 0 of the device. Early generations
* used function 1 as a placeholder for multi-head. This causes
* us confusion instead, especially on the systems where both
* functions have the same PCI-ID!
*/
if (PCI_FUNC(pdev->devfn)) {
printk("i915_pci_probe: returning -ENODEV\n");
return -ENODEV;
}

/* We've managed to ship a kms-enabled ddx that shipped with an XvMC
* implementation for gen3 (and only gen3) that used legacy drm maps
* (gasp!) to share buffers between X and the client. Hence we need to
* keep around the fake agp stuff for gen3, even when kms is
enabled. */
if (intel_info->gen != 3) {
driver.driver_features &=
~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP);
printk("dropping agp requirement\n");
} else if (!intel_agp_enabled) {
DRM_ERROR("drm/i915 can't work without intel_agp module!\n");
return -ENODEV;
}

printk("force-disabling agp on gen %i, is_ivybridge %i\n",
intel_info->gen, intel_info->is_ivybridge);

driver.driver_features &=
~(DRIVER_USE_AGP | DRIVER_REQUIRE_AGP);

return drm_get_pci_dev(pdev, ent, &driver);
}

I see the i915 module loaded:

# lsmod
Module Size Used by
nfs 126282 0
fscache 42769 1 nfs
lockd 55498 1 nfs
sunrpc 171138 3 nfs,lockd
coretemp 5417 0
snd_virtuoso 28165 1
snd_oxygen_lib 28848 1 snd_virtuoso
snd_pcm 78139 1 snd_oxygen_lib
snd_page_alloc 6840 1 snd_pcm
snd_mpu401_uart 5637 1 snd_oxygen_lib
snd_rawmidi 18374 1 snd_mpu401_uart
snd_seq 46978 0
kvm 241365 0
snd_timer 17410 2 snd_pcm,snd_seq
snd_seq_device 5569 2 snd_rawmidi,snd_seq
crc32c_intel 1481 0
aesni_intel 8188 0
ablk_helper 2217 1 aesni_intel
cryptd 8236 1 ablk_helper
aes_i586 7256 1 aesni_intel
pcspkr 1458 0
serio_raw 4359 0
snd 58892 10
snd_virtuoso,snd_oxygen_lib,snd_pcm,snd_mpu401_uart,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
joydev 7748 0
sg 24563 0
i2c_i801 11132 0
sr_mod 12084 0
cdrom 32115 1 sr_mod
soundcore 5895 1 snd
e1000e 199196 0
shpchp 23210 0
pci_hotplug 23417 1 shpchp
lpc_ich 9465 0
edd 7067 0
microcode 11485 0
autofs4 26390 2
ext4 282110 2
jbd2 57523 1 ext4
crc16 1327 1 ext4
i915 420514 0
drm_kms_helper 28021 1 i915
hid_generic 761 0
drm 208515 2 i915,drm_kms_helper
xhci_hcd 117932 0
i2c_algo_bit 4973 1 i915
fan 2287 0
thermal 8404 0
button 4550 1 i915
video 11908 1 i915
scsi_dh_hp_sw 3480 0
scsi_dh_alua 6493 0
scsi_dh_rdac 6764 0
scsi_dh_emc 6481 0
scsi_dh 5432 4
scsi_dh_hp_sw,scsi_dh_alua,scsi_dh_rdac,scsi_dh_emc

# lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
processor DRAM Controller [8086:0150] (rev 09)
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core
processor PCI Express Root Port [8086:0151] (rev 09)
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200
v2/3rd Gen Core processor Graphics Controller [8086:0162] (rev 09)
00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210
Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
00:19.0 Ethernet controller [0200]: Intel Corporation 82579V Gigabit
Network Connection [8086:1503] (rev 04)
00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 1 [8086:1e10] (rev c4)
00:1c.7 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 8 [8086:1e1e] (rev c4)
00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
00:1f.0 ISA bridge [0601]: Intel Corporation H77 Express Chipset LPC
Controller [8086:1e4a] (rev 04)
00:1f.2 SATA controller [0106]: Intel Corporation 7 Series/C210 Series
Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e02] (rev 04)
00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family
SMBus Controller [8086:1e22] (rev 04)
01:00.0 PCI bridge [0604]: PLX Technology, Inc. PEX8112 x1 Lane PCI
Express-to-PCI Bridge [10b5:8112] (rev aa)
02:04.0 Multimedia audio controller [0401]: C-Media Electronics Inc CMI8788
[Oxygen HD Audio] [13f6:8788]

dmesg ad config file attached:

??????
Mark

Attachments:

kernel_config (122.33 kB)
dmesg-dvi2hdmi-3.6.2-2 (48.13 kB)
Download all attachments

2012-10-14 15:53:37

[permalink] [raw]

Subject: Re: [Intel-gfx] Intel graphics drm issue?

On Sun, Oct 14, 2012 at 5:41 PM, Mark Hounschell <[email protected]> wrote:
> There is something amiss. Here is my i915_pci_probe routine. I Added a
> couple more printks. NONE of these show up in dmesg. Not even the "Entered"
> printk. ????

That's rather strange indeed. Is there another driver bound by
accident to the intel graphics? You can check that with lspci -k
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

2012-10-14 15:56:41

[permalink] [raw]

Subject: Re: [Intel-gfx] Intel graphics drm issue?

On Sun, 14 October 2012 Daniel Vetter <[email protected]> wrote:
> On Sun, Oct 14, 2012 at 5:41 PM, Mark Hounschell <[email protected]> wrote:
> > There is something amiss. Here is my i915_pci_probe routine. I Added a
> > couple more printks. NONE of these show up in dmesg. Not even the "Entered"
> > printk. ????
>
> That's rather strange indeed. Is there another driver bound by
> accident to the intel graphics? You can check that with lspci -k
> -Daniel

A few mails ago in a kernel cmd I saw a nomodeset, could it be that
it's still around?

Bruno

2012-10-14 16:09:04

[permalink] [raw]

Subject: Re: [Intel-gfx] Intel graphics drm issue?

On 10/14/2012 11:55 AM, Bruno Pr?mont wrote:
> On Sun, 14 October 2012 Daniel Vetter <[email protected]> wrote:
>> On Sun, Oct 14, 2012 at 5:41 PM, Mark Hounschell <[email protected]> wrote:
>>> There is something amiss. Here is my i915_pci_probe routine. I Added a
>>> couple more printks. NONE of these show up in dmesg. Not even the "Entered"
>>> printk. ????
>>
>> That's rather strange indeed. Is there another driver bound by
>> accident to the intel graphics? You can check that with lspci -k
>> -Daniel
>
> A few mails ago in a kernel cmd I saw a nomodeset, could it be that
> it's still around?

Yes, that is still around. I'll get rid of it and try again.

Mark

2012-10-14 16:13:13

[permalink] [raw]

Subject: Re: [Intel-gfx] Intel graphics drm issue?

On 10/14/2012 12:09 PM, Mark Hounschell wrote:
> On 10/14/2012 11:55 AM, Bruno Pr?mont wrote:
>> On Sun, 14 October 2012 Daniel Vetter <[email protected]> wrote:
>>> On Sun, Oct 14, 2012 at 5:41 PM, Mark Hounschell <[email protected]> wrote:
>>>> There is something amiss. Here is my i915_pci_probe routine. I Added a
>>>> couple more printks. NONE of these show up in dmesg. Not even the
>>>> "Entered"
>>>> printk. ????
>>>
>>> That's rather strange indeed. Is there another driver bound by
>>> accident to the intel graphics? You can check that with lspci -k
>>> -Daniel
>>
>> A few mails ago in a kernel cmd I saw a nomodeset, could it be that
>> it's still around?
>
> Yes, that is still around. I'll get rid of it and try again.
>
> Mark
>
>

That was it. Sorry. Attached is the dmesg now. This is what I see though

[ 1.875354] [drm] Initialized drm 1.1.0 20060810
[ 1.891216] i915_pci_probe: Entered
[ 1.891218] dropping agp requirement
[ 1.891219] force-disabling agp on gen 7, is_ivybridge 1

Mark

Attachments:

dmesg-dvi2hdmi-3.6.2-2 (200.82 kB)

2012-10-14 16:54:37

[permalink] [raw]

Subject: Re: Intel graphics drm issue?

On 10/14/2012 07:03 AM, Bruno Prémont wrote:
> On Sun, 14 October 2012 Mark Hounschell <[email protected]> wrote:
>> On 10/14/2012 04:41 AM, Bruno Prémont wrote:
>>> Your best solution is probably to write an EDID blob (or reuse one you find
>>> somewhere) that provides at least one mode matching your TV's native mode
>>> (probably full-HD).
>>>
>>> Google suggested the following document:
>>> http://www.jordansmanuals.com/ServiceManuals%5CLG%5CTV%5CLCD%5C42LB9DF%5C42LB9DF%20Service%20Manual.pdf
>>> which on page 13/14 shows the full EDID blob for the various HDMI outputs of the
>>> TV. You may want to read that document, convert the EDID blobs to 512 bytes binary
>>> files and hell DRM core to use the right one via module/kernel cmdline option:
>>>
>>> drm_kms_helper.edid_firmware=edid/lg42lb9df.edid
>>> or
>>> modprobe drm-kms-helper edid_firmware=edid/lg42lb9df.edid
>>>
>>> where
>>> /lib/firmware/edid/lg42lb9df.edid
>>> is the 512-bytes EDID blob created according to data from above manual.
>>> (note, that will only work for intel, radeon and nouveau drivers but will
>>> not work for closed drivers of AMD/nVidia)
>>>
>>
>> This certainly looks doable. That firmware file, should it contain all 4
>> tables or just the one for the port I'm connected to? Will it matter what
>> order they were in?
>
> It should contain just the table for the port you're connected to.
> For the HDMI ports the tables are 1024 bytes (e.g. two 512 bytes blocks,
> not just one as I incorrectly wrote above). For the VGA port it's just one
> 512 bytes block.
>
> Oh, and check the exact documentation of edid_firmware parameter as you can
> adjust its value to tell kernel to which connector exactly it applies
> (otherwise it will overwrite the EDID on other ports with working displays!).
>

Hi Bruno,

I've taken the EDID data from that service manual. I've looked at the
EDID-Howto for how to specify the connector but all I see is:

"An EDID data set will only be used for a particular connector,
if its name and a colon are prepended to the EDID name."

Where can I find the connector names?

And could I ask if this simple pgm might work to build the file I need?

int32_t main(int argc, char **argv)
{
FILE *fd;
const char *path = "/lib/firmware/edid/lg42lb9df.edid";
const char *mode = "w+";
uint8_t firmware[1024] = {

0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x1E,
0x6D, 0x01, 0x00, 0x01, 0x01, 0x01, 0x01,
0x0E, 0x10, 0x01, 0x03, 0x80, 0x73, 0x41, 0x96, 0x0A,
0xCF, 0x74, 0xA3, 0x57, 0x4C, 0xB0, 0x23,
0x09, 0x48, 0x4C, 0xAF, 0xCF, 0x00, 0x31, 0x40, 0x45,
0x40, 0x61, 0x40, 0x81, 0x80, 0xA9, 0x40,
0xD1, 0xC0, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3A, 0x80,
0x18, 0x71, 0x38, 0x2D, 0x40, 0x58, 0x2C,
0x45, 0x00, 0xC4, 0x8E, 0x21, 0x00, 0x00, 0x1E, 0x66,
0x21, 0x50, 0xB0, 0x51, 0x00, 0x1B, 0x30,
0x40, 0x70, 0x36, 0x00, 0xC4, 0x8E, 0x21, 0x00, 0x00,
0x1E, 0x00, 0x00, 0x00, 0xFD, 0x00, 0x38,
0x4B, 0x1F, 0x44, 0x0F, 0x00, 0x0A, 0x20, 0x20, 0x20,
0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xFC,
0x00, 0x4C, 0x47, 0x20, 0x54, 0x56, 0x0A, 0x20, 0x20,
0x20, 0x20, 0x20, 0x20, 0x20, 0x01, 0x15,

0x02, 0x03, 0x1B, 0xF1, 0x4C, 0x20, 0x22, 0x10, 0x1F,
0x01, 0x02, 0x03, 0x04, 0x05, 0x12, 0x93,
0x14, 0x23, 0x15, 0x07, 0x50, 0x65, 0x03, 0x0C, 0x00,
0x10, 0x00, 0x01, 0x1D, 0x00, 0x72, 0x51,
0xD0, 0x1E, 0x20, 0x6E, 0x28, 0x55, 0x00, 0xC4, 0x8E,
0x21, 0x00, 0x00, 0x1E, 0x01, 0x1D, 0x80,
0x18, 0x71, 0x1C, 0x16, 0x20, 0x58, 0x2C, 0x25, 0x00,
0xC4, 0x8E, 0x21, 0x00, 0x00, 0x9E, 0x8C,
0x0A, 0xD0, 0x90, 0x20, 0x40, 0x31, 0x20, 0x0C, 0x40,
0x55, 0x00, 0x4C, 0x6C, 0x42, 0x00, 0x00,
0x18, 0x01, 0x1D, 0x00, 0xBC, 0x52, 0xD0, 0x1E, 0x20,
0xB8, 0x28, 0x55, 0x40, 0x4C, 0x6C, 0x42,
0x00, 0x00, 0x1E, 0x01, 0x1D, 0x80, 0xD0, 0x72, 0x1C,
0x16, 0x20, 0x10, 0x2C, 0x25, 0x80, 0x4C,
0x6C, 0x42, 0x00, 0x00, 0x9E, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xED
};

fd = fopen(path, mode);
if (fd == NULL) {
perror("/lib/firmware/edid/lg42lb9df.edid failed: ");
return 1;
}

fwrite(&firmware, 1024, 1, fd);

fclose(fd);

printf("Wrote 1024 bytes of edid data to %s\n", path);

return 0;
}

Thanks very much
Mark

2012-10-14 17:23:56

[permalink] [raw]

Subject: Re: Intel graphics drm issue?

Hi Mark,

On Sun, 14 October 2012 Mark Hounschell <[email protected]> wrote:
> I've taken the EDID data from that service manual. I've looked at the
> EDID-Howto for how to specify the connector but all I see is:
>
> "An EDID data set will only be used for a particular connector,
> if its name and a colon are prepended to the EDID name."
>
> Where can I find the connector names?

Those are the ones you see under /sys/class/drm/, without the card0-
prefix.

E.g. on my system I have:

# ls /sys/class/drm/
card0 card0-DVI-I-1 card0-LVDS-1 card0-VGA-1 controlD64 version

Thus I have connectors "DVI-I-1", "LVDS-1" and "VGA-1" (note that your
HDMI connector might not be named HDMI-1, if you are not sure which one
it is, you can look at the files below (edid, enabled, status) which
should help your find the right connector).

In addition, if you rmmod i915 and modprobe it again connectors will get
increased suffix numbers. So don't expect them to remain the same if you
have multiple GPUs detected in random order or if you rebind them to
their driver. (though except during testing or for special systems you
don't have to worry about this)

> And could I ask if this simple pgm might work to build the file I need?

It looks fine. You can also check the output with hexdump just to
make sure it looks sane.
If it's broken kernel will tell you that checksum does not match.

In any case the (successful) loading of edid should be visible in kernel
log.

Bruno

> int32_t main(int argc, char **argv)
> {
> FILE *fd;
> const char *path = "/lib/firmware/edid/lg42lb9df.edid";
> const char *mode = "w+";
> uint8_t firmware[1024] = {
>
> 0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x1E,
> 0x6D, 0x01, 0x00, 0x01, 0x01, 0x01, 0x01,
> 0x0E, 0x10, 0x01, 0x03, 0x80, 0x73, 0x41, 0x96, 0x0A,
> 0xCF, 0x74, 0xA3, 0x57, 0x4C, 0xB0, 0x23,
> 0x09, 0x48, 0x4C, 0xAF, 0xCF, 0x00, 0x31, 0x40, 0x45,
> 0x40, 0x61, 0x40, 0x81, 0x80, 0xA9, 0x40,
> 0xD1, 0xC0, 0x01, 0x01, 0x01, 0x01, 0x02, 0x3A, 0x80,
> 0x18, 0x71, 0x38, 0x2D, 0x40, 0x58, 0x2C,
> 0x45, 0x00, 0xC4, 0x8E, 0x21, 0x00, 0x00, 0x1E, 0x66,
> 0x21, 0x50, 0xB0, 0x51, 0x00, 0x1B, 0x30,
> 0x40, 0x70, 0x36, 0x00, 0xC4, 0x8E, 0x21, 0x00, 0x00,
> 0x1E, 0x00, 0x00, 0x00, 0xFD, 0x00, 0x38,
> 0x4B, 0x1F, 0x44, 0x0F, 0x00, 0x0A, 0x20, 0x20, 0x20,
> 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0xFC,
> 0x00, 0x4C, 0x47, 0x20, 0x54, 0x56, 0x0A, 0x20, 0x20,
> 0x20, 0x20, 0x20, 0x20, 0x20, 0x01, 0x15,
>
> 0x02, 0x03, 0x1B, 0xF1, 0x4C, 0x20, 0x22, 0x10, 0x1F,
> 0x01, 0x02, 0x03, 0x04, 0x05, 0x12, 0x93,
> 0x14, 0x23, 0x15, 0x07, 0x50, 0x65, 0x03, 0x0C, 0x00,
> 0x10, 0x00, 0x01, 0x1D, 0x00, 0x72, 0x51,
> 0xD0, 0x1E, 0x20, 0x6E, 0x28, 0x55, 0x00, 0xC4, 0x8E,
> 0x21, 0x00, 0x00, 0x1E, 0x01, 0x1D, 0x80,
> 0x18, 0x71, 0x1C, 0x16, 0x20, 0x58, 0x2C, 0x25, 0x00,
> 0xC4, 0x8E, 0x21, 0x00, 0x00, 0x9E, 0x8C,
> 0x0A, 0xD0, 0x90, 0x20, 0x40, 0x31, 0x20, 0x0C, 0x40,
> 0x55, 0x00, 0x4C, 0x6C, 0x42, 0x00, 0x00,
> 0x18, 0x01, 0x1D, 0x00, 0xBC, 0x52, 0xD0, 0x1E, 0x20,
> 0xB8, 0x28, 0x55, 0x40, 0x4C, 0x6C, 0x42,
> 0x00, 0x00, 0x1E, 0x01, 0x1D, 0x80, 0xD0, 0x72, 0x1C,
> 0x16, 0x20, 0x10, 0x2C, 0x25, 0x80, 0x4C,
> 0x6C, 0x42, 0x00, 0x00, 0x9E, 0x00, 0x00, 0x00, 0x00,
> 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xED
> };
>
> fd = fopen(path, mode);
> if (fd == NULL) {
> perror("/lib/firmware/edid/lg42lb9df.edid failed: ");
> return 1;
> }
>
> fwrite(&firmware, 1024, 1, fd);
>
> fclose(fd);
>
> printf("Wrote 1024 bytes of edid data to %s\n", path);
>
> return 0;
> }
>
> Thanks very much
> Mark

2012-10-14 18:03:24

[permalink] [raw]

Subject: Re: Intel graphics drm issue?

On 10/14/2012 01:22 PM, Bruno Pr?mont wrote:
> Hi Mark,
>
> On Sun, 14 October 2012 Mark Hounschell <[email protected]> wrote:
>> I've taken the EDID data from that service manual. I've looked at the
>> EDID-Howto for how to specify the connector but all I see is:
>>
>> "An EDID data set will only be used for a particular connector,
>> if its name and a colon are prepended to the EDID name."
>>
>> Where can I find the connector names?
>
> Those are the ones you see under /sys/class/drm/, without the card0-
> prefix.
>
> E.g. on my system I have:
>
> # ls /sys/class/drm/
> card0 card0-DVI-I-1 card0-LVDS-1 card0-VGA-1 controlD64 version
>
> Thus I have connectors "DVI-I-1", "LVDS-1" and "VGA-1" (note that your
> HDMI connector might not be named HDMI-1, if you are not sure which one
> it is, you can look at the files below (edid, enabled, status) which
> should help your find the right connector).
>

Perfect.

>
> In addition, if you rmmod i915 and modprobe it again connectors will get
> increased suffix numbers. So don't expect them to remain the same if you
> have multiple GPUs detected in random order or if you rebind them to
> their driver. (though except during testing or for special systems you
> don't have to worry about this)
>
>> And could I ask if this simple pgm might work to build the file I need?
>
> It looks fine. You can also check the output with hexdump just to
> make sure it looks sane.

Did that and the data looks swapped compared to the array written, but I
guess that's normal?

> If it's broken kernel will tell you that checksum does not match.
>

So the check sum is actually already in the data provided by the service
manual then.

> In any case the (successful) loading of edid should be visible in kernel
> log.
>

I'll be trying this a little later in the day.

Thanks again
Mark

2012-10-14 18:20:43

[permalink] [raw]

Subject: Re: Intel graphics drm issue?

On Sun, 14 October 2012 Mark Hounschell <[email protected]> wrote:
> >> And could I ask if this simple pgm might work to build the file I need?
> >
> > It looks fine. You can also check the output with hexdump just to
> > make sure it looks sane.
>
> Did that and the data looks swapped compared to the array written, but I
> guess that's normal?

That might very well be presentation issue, how did you call hexdump?
When called with no arguments but filename it groups bytes as words and
those look swapped (on little-endian), but `hexdump -C $file` is fine,
dumping each byte individually.

> > If it's broken kernel will tell you that checksum does not match.
> >
>
> So the check sum is actually already in the data provided by the service
> manual then.

Yes, checksum byte is part of the EDID blob.

Bruno

> > In any case the (successful) loading of edid should be visible in kernel
> > log.
> >
>
> I'll be trying this a little later in the day.
>
> Thanks again
> Mark

2012-10-14 18:57:30

[permalink] [raw]

Subject: Re: Intel graphics drm issue?

On 10/14/2012 02:19 PM, Bruno Pr?mont wrote:
> On Sun, 14 October 2012 Mark Hounschell <[email protected]> wrote:
>>>> And could I ask if this simple pgm might work to build the file I need?
>>>
>>> It looks fine. You can also check the output with hexdump just to
>>> make sure it looks sane.
>>
>> Did that and the data looks swapped compared to the array written, but I
>> guess that's normal?
>
> That might very well be presentation issue, how did you call hexdump?
> When called with no arguments but filename it groups bytes as words and
> those look swapped (on little-endian), but `hexdump -C $file` is fine,
> dumping each byte individually.
>

Yep, its right with -C

>>> If it's broken kernel will tell you that checksum does not match.
>>>
>>
>> So the check sum is actually already in the data provided by the service
>> manual then.
>
> Yes, checksum byte is part of the EDID blob.
>
> Bruno
>
>>> In any case the (successful) loading of edid should be visible in kernel
>>> log.
>>>
>>
>> I'll be trying this a little later in the day.

I gave it a try. I don't think it liked my kernel cmdline. dmesg attached.
There is a lot more in there now that nomodeset is gone and the debug is
turned on.

# ls -al /lib/firmware/edid/lg42lb9df.edid
-rw-r--r-- 1 root root 1024 Oct 14 2012 /lib/firmware/edid/lg42lb9df.edid

## cat /proc/cmdline
root=/dev/disk/by-id/ata-INTEL_SSDSC2CW060A3_CVCV205106EB060AGN-part4
noresume splash=silent quiet apm=off vga=normal drm.debug=0xe irqpoll
drm_kms_helper.edid_firmware=edid/lg42lb9df.edid

from attached dmesg:
1.833032] drm_kms_helper: Unknown parameter `edid'

Mark

Attachments:

dmesg-hdmi_only-3.6.2-3 (159.22 kB)

2012-10-14 20:41:59

[permalink] [raw]

Subject: Re: Intel graphics drm issue?

On Sun, 14 October 2012 Mark Hounschell <[email protected]> wrote:
> I gave it a try. I don't think it liked my kernel cmdline. dmesg attached.
> There is a lot more in there now that nomodeset is gone and the debug is
> turned on.
>
> # ls -al /lib/firmware/edid/lg42lb9df.edid
> -rw-r--r-- 1 root root 1024 Oct 14 2012 /lib/firmware/edid/lg42lb9df.edid
>
> ## cat /proc/cmdline
> root=/dev/disk/by-id/ata-INTEL_SSDSC2CW060A3_CVCV205106EB060AGN-part4
> noresume splash=silent quiet apm=off vga=normal drm.debug=0xe irqpoll
> drm_kms_helper.edid_firmware=edid/lg42lb9df.edid
>
>
> from attached dmesg:
> 1.833032] drm_kms_helper: Unknown parameter `edid'

As your drm drivers seem to all be built-in (according to kernel timings)
you will have to build the EDID firmware into the kernel as well (see
CONFIG_EXTRA_FIRMWARE), otherwise it probably can't be loaded (unless Linus'
firmware loading patch is already in 3.6.2 and root filesystem/initrd is
ready at that time).

Did you set CONFIG_DRM_LOAD_EDID_FIRMWARE?
If not, that may be the reason for unknown parameter `edid' error.

But I saw I mis-remembered side of EDID blobs, they are just 128 bytes
per block, not 512 (seems I was thinking disk sector sizes),
thus you should just get 256 bytes output.

Just truncating the file to 256 bytes will do. You may also
change your .c file to have
uint8_t firmware[] = {
...
};
...
fwrite(firmware, sizeof(firmware), 1, fd);
...

that way compiler gets numbers right :)

Kernel code rejects edid with unexpected size! Thus it would have
complained if it had tried to load it with a size of 1k.

Bruno

2012-10-15 09:58:05