DRM KMS polling of connections providing errant EDID responses, or polling of "connectors" that have chips responding on DDC I2C bus address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM, will create perpetual noise in dmesg and the system log every 10 seconds. Currently the user has apparently little recourse to silence these messages aside from replacing the offending cable, monitor, or graphics adapter. That recourse is impossible for an unused DVI-D "connector" of an internal graphics processor on a motherboard that provides no physical DVI-D connector.
This change allows the root user to disable (and re-enable) DRM KMS connector polling on a per connector basis via sysfs, like so:
# cat /sys/class/drm/card0/card0-DVI-D-1/polled [hotplug_detectable] connect disconnect
# echo > /sys/class/drm/card0/card0-DVI-D-1/polled # cat /sys/class/drm/card0/card0-DVI-D-1/polled hotplug_detectable connect disconnect
# echo " connect hotplug_detectable " > \ /sys/class/drm/card0/card0-DVI-D-1/polled # cat /sys/class/drm/card0/card0-DVI-D-1/polled [hotplug_detectable] [connect] disconnect
# echo > /sys/class/drm/card0/card0-DVI-D-1/polled # cat /sys/class/drm/card0/card0-DVI-D-1/polled hotplug_detectable connect disconnect
with the enabled poll types for the connector denoted in brackets: []. This allows the root user to silence DRM KMS log spam for locally known uncorrectable conditions.
Signed-off-by Andy Walls awalls@md.metrocast.net
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c index 86118a7..8e0807d 100644 --- a/drivers/gpu/drm/drm_sysfs.c +++ b/drivers/gpu/drm/drm_sysfs.c @@ -318,11 +318,80 @@ static ssize_t select_subconnector_show(struct device *device, drm_get_dvi_i_select_name((int)subconnector)); }
+static const struct { + uint8_t mask; + const char *name; +} polled_bit_names[] = { + { DRM_CONNECTOR_POLL_HPD, "hotplug_detectable" }, + { DRM_CONNECTOR_POLL_CONNECT, "connect" }, + { DRM_CONNECTOR_POLL_DISCONNECT, "disconnect" }, +}; + +/* + * Return the decoded contents of connector->polled, using the names of the + * all the bit masks. Bits that are set, have their names enclosed in brackets. + */ +static ssize_t polled_show(struct device *dev, struct device_attribute *attr, + char *buf) +{ + struct drm_connector *connector = to_drm_connector(dev); + char *tmp; + int i; + + tmp = buf; + for (i = 0; i < ARRAY_SIZE(polled_bit_names); i++) { + if (connector->polled & polled_bit_names[i].mask) + tmp += sprintf(tmp, "[%s] ", polled_bit_names[i].name); + else + tmp += sprintf(tmp, "%s ", polled_bit_names[i].name); + } + + if (tmp != buf) + *(tmp - 1) = '\n'; + return tmp - buf; +} + +/* + * Change the state of connector->polled, given input bit-mask name-strings + * that are separated by space or newline. + */ +static ssize_t polled_store(struct device *dev, struct device_attribute *attr, + const char *buf, size_t count) +{ + struct drm_connector *connector = to_drm_connector(dev); + const char *tmp; + int i; + uint8_t polled; + + /* Polling of this connector will cease, if no match is made below */ + polled = 0; + + /* Incrementally split and parse the input */ + while ((tmp = strsep((char **) &buf, " \n")) != NULL) { + + /* Don't waste effort on multiple adjacent separators */ + if (*tmp == '\0') + continue; + + /* Check for a match with a connector poll type name */ + for (i = 0; i < ARRAY_SIZE(polled_bit_names); i++) { + if (!strncasecmp(tmp, polled_bit_names[i].name, + strlen(polled_bit_names[i].name))) { + polled |= polled_bit_names[i].mask; + break; + } + } + } + connector->polled = polled; + return count; +} + static struct device_attribute connector_attrs[] = { __ATTR_RO(status), __ATTR_RO(enabled), __ATTR_RO(dpms), __ATTR_RO(modes), + __ATTR(polled, 0644, polled_show, polled_store), };
/* These attributes are for both DVI-I connectors and all types of tv-out. */
2010/9/20 Andy Walls awalls@md.metrocast.net:
DRM KMS polling of connections providing errant EDID responses, or polling of "connectors" that have chips responding on DDC I2C bus address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM, will create perpetual noise in dmesg and the system log every 10 seconds. Currently the user has apparently little recourse to silence these messages aside from replacing the offending cable, monitor, or graphics adapter. That recourse is impossible for an unused DVI-D "connector" of an internal graphics processor on a motherboard that provides no physical DVI-D connector.
This change allows the root user to disable (and re-enable) DRM KMS connector polling on a per connector basis via sysfs, like so:
Huh, I didn't imagine solution of this issue that way. AFAIR previous thread, something else was suggested, it was about storing the fact that user already received warning/info about error.
Why I don't really like proposed solution? 1) You need to be root 2) Need to know and play with some "magic" sysfs file.
I thing it would be much better and user-friendly to display such an error just once per display. How this could be implemented?
1) Add field like "warned" to connector struct, default to 0 2) if (warning_to_be_printed && !connector->warned) { printk(); connector->warned = 1 3) if (connector_disconnected) { connector->warned = 0; }
This was you will get just one warning per connected display. Of course after disconnecting it we have to clear "warned", as user may connect another "broken" display, then we should print warning again.
What do think about this solution?
On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
2010/9/20 Andy Walls awalls@md.metrocast.net:
DRM KMS polling of connections providing errant EDID responses, or polling of "connectors" that have chips responding on DDC I2C bus address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM, will create perpetual noise in dmesg and the system log every 10 seconds. Currently the user has apparently little recourse to silence these messages aside from replacing the offending cable, monitor, or graphics adapter. That recourse is impossible for an unused DVI-D "connector" of an internal graphics processor on a motherboard that provides no physical DVI-D connector.
This change allows the root user to disable (and re-enable) DRM KMS connector polling on a per connector basis via sysfs, like so:
Huh, I didn't imagine solution of this issue that way.
The problems with my initial patch, and related approaches, were:
1. They didn't get rid of all the spam in the logs, just the most verbose portion of it.
2. They didn't deal with the root cause of the log spam and all the related, but unneeded, I/O and processing that was still occurring.
AFAIR previous thread, something else was suggested, it was about storing the fact that user already received warning/info about error.
Yes, that was the discussion.
I went with this patch because:
1. It deals with the root cause: unneeded DRM KMS connector polling
2. It eliminates all my DRM KMS connector polling related log spam, not just the hex dump.
3. The existing sysfs structure was already exposing 'struct drm_connector' members to user-space at per connector granularity
The real root cause of the polling spew is that the radeon module, based on the best information it has (BIOS connector tables, I2C bus probes, etc.), makes a decision on if a connector should be polled and how it should be polled.
Given incorrect BIOS tables, and strange I2C setups, the radeon module is bound to make the wrong decision about polling in some cases. This change is a way for the human to step in a correct things, when the radeon driver gets it wrong.
In my case, along with the log spam, there are also a lot of unneeded I2C transactions going on.
BTW, I found that Chris Wilson recently committed a change to inhibit all drm connector polling globally for a different reason:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58...
That commit message shows a case where the driver decides polling needs to happen, but the human knows differently and manual control over connector polling mitigates the problem.
Why I don't really like proposed solution?
- You need to be root
Yes, for both sysfs and module parameters.
I view video hardware configuration (montiors, cables, graphics cards) and control of what gets logged into files as system administrative issues. I'd assume that needing root privileges to turn on and off device auto detection would be the norm. I imagined that root would set up any DRM KMS connector polling fixes once in an init script and be done with it. Is there any other use-case you had in mind?
If there's some set-uid or group privilege method or utilities that's in common use (xrandr?) for manual control of drm/kms parameters, that you think would be better, just point me in that direction and I'll try to work something out.
However, trying to code automatic control of when to disable DRM KMS connector polling, by some heuristic or algorithm in radeon or drm, is likely doomed to failure for corner cases or for someone's policy preferences. I'd rather not attempt that.
- Need to know and play with some "magic" sysfs file.
I strongly dislike ever using sysfs myself. However, I'll spare us all my rantings^Wreasons. ;)
My problem with KMS was with the documentation I could find. The "userland interfaces" section in Documentation/Docbook/drm.tmpl is essentially empty. DRM design documents at freedesktop.org (which actually look closer to requirements documents) are the most detailed documents I could find, but they don't really cover KMS. Maybe I'm just looking in the wrong places.
Is there a KMS or DRM_MODESET API document? Maybe I could propose a new ioctl(), if there isn't already one that will be usable for controlling DRM KMS polling.
I thing it would be much better and user-friendly to display such an error just once per display. How this could be implemented?
- Add field like "warned" to connector struct, default to 0
- if (warning_to_be_printed && !connector->warned) { printk();
connector->warned = 1 3) if (connector_disconnected) { connector->warned = 0; }
This was you will get just one warning per connected display. Of course after disconnecting it we have to clear "warned", as user may connect another "broken" display, then we should print warning again.
What do think about this solution?
I followed most of the function calls back and looked at he return values and error messages that can get emitted under various circumstances. The amount of effort and complexity for trying to supress all the error messages due to the 10 second poll just wasn't worth it, when supressing the polling was so much easier. For supressing error messages, I decided there was too much state to track and that any policy I hard-coded would be wrong for someone.
From inside the code, it is difficult to decide what message about
errors induced from the external environment are important to the user and what aren't. It's too dependent on the external context and what action the user would like to take under various conditions.
Thanks for your comments. Sorry for the long reply.
Regards, Andy
2010/9/20 Andy Walls awalls@md.metrocast.net:
On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
2010/9/20 Andy Walls awalls@md.metrocast.net:
DRM KMS polling of connections providing errant EDID responses, or polling of "connectors" that have chips responding on DDC I2C bus address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM, will create perpetual noise in dmesg and the system log every 10 seconds. Currently the user has apparently little recourse to silence these messages aside from replacing the offending cable, monitor, or graphics adapter. That recourse is impossible for an unused DVI-D "connector" of an internal graphics processor on a motherboard that provides no physical DVI-D connector.
This change allows the root user to disable (and re-enable) DRM KMS connector polling on a per connector basis via sysfs, like so:
Huh, I didn't imagine solution of this issue that way.
The problems with my initial patch, and related approaches, were:
- They didn't get rid of all the spam in the logs, just the most
verbose portion of it.
- They didn't deal with the root cause of the log spam and all the
related, but unneeded, I/O and processing that was still occurring.
AFAIR previous thread, something else was suggested, it was about storing the fact that user already received warning/info about error.
Yes, that was the discussion.
I went with this patch because:
It deals with the root cause: unneeded DRM KMS connector polling
It eliminates all my DRM KMS connector polling related log spam, not
just the hex dump.
- The existing sysfs structure was already exposing 'struct
drm_connector' members to user-space at per connector granularity
The real root cause of the polling spew is that the radeon module, based on the best information it has (BIOS connector tables, I2C bus probes, etc.), makes a decision on if a connector should be polled and how it should be polled.
Given incorrect BIOS tables, and strange I2C setups, the radeon module is bound to make the wrong decision about polling in some cases. This change is a way for the human to step in a correct things, when the radeon driver gets it wrong.
I'd rather fix the bug for real rather than providing users with an out so that the bug never gets reported. What's the actual problem you have? Do you just want to turn polling off for an unused connecter, or does the board have a bug in the connector table? If it's a bug, we can add a quirk so that it's properly handled. What physical connectors does the board have what does the driver report in dmesg?
Alex
In my case, along with the log spam, there are also a lot of unneeded I2C transactions going on.
BTW, I found that Chris Wilson recently committed a change to inhibit all drm connector polling globally for a different reason:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58...
That commit message shows a case where the driver decides polling needs to happen, but the human knows differently and manual control over connector polling mitigates the problem.
Why I don't really like proposed solution?
- You need to be root
Yes, for both sysfs and module parameters.
I view video hardware configuration (montiors, cables, graphics cards) and control of what gets logged into files as system administrative issues. I'd assume that needing root privileges to turn on and off device auto detection would be the norm. I imagined that root would set up any DRM KMS connector polling fixes once in an init script and be done with it. Is there any other use-case you had in mind?
If there's some set-uid or group privilege method or utilities that's in common use (xrandr?) for manual control of drm/kms parameters, that you think would be better, just point me in that direction and I'll try to work something out.
However, trying to code automatic control of when to disable DRM KMS connector polling, by some heuristic or algorithm in radeon or drm, is likely doomed to failure for corner cases or for someone's policy preferences. I'd rather not attempt that.
- Need to know and play with some "magic" sysfs file.
I strongly dislike ever using sysfs myself. However, I'll spare us all my rantings^Wreasons. ;)
My problem with KMS was with the documentation I could find. The "userland interfaces" section in Documentation/Docbook/drm.tmpl is essentially empty. DRM design documents at freedesktop.org (which actually look closer to requirements documents) are the most detailed documents I could find, but they don't really cover KMS. Maybe I'm just looking in the wrong places.
Is there a KMS or DRM_MODESET API document? Maybe I could propose a new ioctl(), if there isn't already one that will be usable for controlling DRM KMS polling.
I thing it would be much better and user-friendly to display such an error just once per display. How this could be implemented?
- Add field like "warned" to connector struct, default to 0
- if (warning_to_be_printed && !connector->warned) { printk();
connector->warned = 1 3) if (connector_disconnected) { connector->warned = 0; }
This was you will get just one warning per connected display. Of course after disconnecting it we have to clear "warned", as user may connect another "broken" display, then we should print warning again.
What do think about this solution?
I followed most of the function calls back and looked at he return values and error messages that can get emitted under various circumstances. The amount of effort and complexity for trying to supress all the error messages due to the 10 second poll just wasn't worth it, when supressing the polling was so much easier. For supressing error messages, I decided there was too much state to track and that any policy I hard-coded would be wrong for someone.
From inside the code, it is difficult to decide what message about
errors induced from the external environment are important to the user and what aren't. It's too dependent on the external context and what action the user would like to take under various conditions.
Thanks for your comments. Sorry for the long reply.
Regards, Andy
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
2010/9/20 Andy Walls awalls@md.metrocast.net:
On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
2010/9/20 Andy Walls awalls@md.metrocast.net:
DRM KMS polling of connections providing errant EDID responses, or polling of "connectors" that have chips responding on DDC I2C bus address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM, will create perpetual noise in dmesg and the system log every 10 seconds. Currently the user has apparently little recourse to silence these messages aside from replacing the offending cable, monitor, or graphics adapter. That recourse is impossible for an unused DVI-D "connector" of an internal graphics processor on a motherboard that provides no physical DVI-D connector.
This change allows the root user to disable (and re-enable) DRM KMS connector polling on a per connector basis via sysfs, like so:
Huh, I didn't imagine solution of this issue that way.
The problems with my initial patch, and related approaches, were:
- They didn't get rid of all the spam in the logs, just the most
verbose portion of it.
- They didn't deal with the root cause of the log spam and all the
related, but unneeded, I/O and processing that was still occurring.
AFAIR previous thread, something else was suggested, it was about storing the fact that user already received warning/info about error.
Yes, that was the discussion.
I went with this patch because:
It deals with the root cause: unneeded DRM KMS connector polling
It eliminates all my DRM KMS connector polling related log spam, not
just the hex dump.
- The existing sysfs structure was already exposing 'struct
drm_connector' members to user-space at per connector granularity
The real root cause of the polling spew is that the radeon module, based on the best information it has (BIOS connector tables, I2C bus probes, etc.), makes a decision on if a connector should be polled and how it should be polled.
Given incorrect BIOS tables, and strange I2C setups, the radeon module is bound to make the wrong decision about polling in some cases. This change is a way for the human to step in a correct things, when the radeon driver gets it wrong.
I'd rather fix the bug for real rather than providing users with an out so that the bug never gets reported.
There is already "an out" on it's way upstream:
http://lkml.org/lkml/2010/9/6/375 http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58...
I noticed it after I submitted this patch. If I'm reading it right, the module parameter fix is very coarse: it applies to all drm adapters and connectors in the system.
What's the actual problem you have?
The actual problem I have is that the radeon driver reports three connectors (HDMI, DVI-D, and VGA) on the motherboard, but there is only one physical connector (VGA). Polling of the HDMI appears to be inhibited by the radeon module code. Polling of the (non-existent?) DVI-D interface yields a lot of log messages and useless I2C transactions.
My precise gripe is with this code path
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drive...
which is being polled every 10 seconds. It is bad for me because this function is noisy:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drive...
and this (insane?) loop multiplies the noise by a factor of 4:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drive...
In a different user's operational context, all that noise may be beneficial.
The real problem to me is that the radeon and drm modules have a single, standard way of dealing with EDID errors. However, EDID errors can happen due to a number of different causes, some of which are external (i.e. in the LCD or CRT monitor). Given that, there really is no "right thing" the drivers can do without input from the user on what the policy should be when a bad EDID is detected.
Do you just want to turn polling off for an unused connecter,
Yes, that's what I would use my proposed patch for.
(If a solution that avoids sysfs is required, I can work up a patch using DRM_IOCTL_MODE_GETPROPERTY & DRM_IOCTL_MODE_SETPROPERTY along with a patch for some utility like xrandr.)
In a larger sense it's about user policy for error reporting by the drm and radeon drivers, and error response by both the drivers and the user.
In the face of EDID errors, a user may want to take the following actions:
ignore the errors supress the errors continue to monitor the errors for a time replace cables replace graphics adapter replace monitor report a bug
All of those end user actions are possible right now, except the one to supress the errors (and the I2C transactions associated with them).
A monitor, cable, and graphics adapter set that is currently experiencing EDID errors, may be otherwise working just fine.
"Because we want to ensure people report bugs," does not seem like a good reason to prevent a user from turning off bogus error messages, for an otherwise working monitor that is providing broken EDID data. What is the resolution of a bug report for a monitor providing bad EDID data going to look like?
or does the board have a bug in the connector table?
I have not dug into the BIOS connector table bits and bytes to verify, but I'm assuming the connector table is incorrect.
If it's a bug, we can add a quirk so that it's properly handled.
I don't see how a quirk table is going to cover the situations different from mine, that also provide bad EDID data in the code path I pointed out. I know how one can add quirks for a connected DVI-D monitor that provides bad EDID data or none at all.
The radeon module already has a connector_table module parameter for quirks. That module option provides some hard-coded connector tables. I had considered adding more to that, but it seemed like a band-aid. Also, IIRC, the connector_table parameter currently applies globally to all radeon graphics adapters in the system, so it doesn't scale to multiple radeon adapters in the system.
What physical connectors does the board have what does the driver report in dmesg?
The board only has a physical VGA connector. The graphics adapter is an IGP on an MSI K9A2GM V2/V3 series motherboard (MS-7302). Here are the PCI IDs on the graphics adapter:
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon 2100 [1002:796e] (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. Device [1462:7302]
Below is the dmesg output from the unmodified drm and radeon modules which includes samples of drm module log spam for the first 30 seconds or so after boot.
Regards, Andy
Linux version 2.6.32.19-163.fc12.x86_64 (mockbuild@x86-05.phx2.fedoraproject.org) (gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) ) #1 SMP Wed Aug 18 11:38:54 UTC 2010 [snip!] [drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [drm] radeon: Initializing kernel modesetting. [drm] register mmio base: 0xFE7F0000 [drm] register mmio size: 65536 ATOM BIOS: ATI [drm] GPU reset succeed (RBBM_STATUS=0x10000140) [drm] radeon: VRAM 128M [drm] radeon: VRAM from 0x78000000 to 0x7FFFFFFF [drm] radeon: GTT 512M [drm] radeon: GTT from 0x80000000 to 0x9FFFFFFF alloc irq_desc for 28 on node 0 alloc kstat_irqs on node 0 radeon 0000:01:05.0: irq 28 for MSI/MSI-X [drm] radeon: using MSI. [drm] radeon: irq initialized. [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 963036 kiB. [drm] radeon: 128M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] radeon: 1 quad pipes, 1 z pipes initialized. [drm] radeon: cp idle (0x10000C03) [drm] Loading RS690/RS740 Microcode platform radeon_cp.0: firmware: requesting radeon/RS690_cp.bin [drm] radeon: ring at 0x0000000080000000 [drm] ring test succeeded in 1 usecs [drm] radeon: ib pool ready. [drm] ib test succeeded in 0 usecs [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] DVI-D [drm] HPD2 [drm] DDC: 0x7e40 0x7e60 0x7e44 0x7e64 0x7e48 0x7e68 0x7e4c 0x7e6c [drm] Encoders: [drm] DFP2: INTERNAL_DDI [drm] Connector 2: [drm] HDMI-A [drm] DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c [drm] Encoders: [drm] DFP3: INTERNAL_LVTM1 [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm] fb mappable at 0xD8040000 [drm] vram apper at 0xD8000000 [drm] size 4325376 [drm] fb depth is 24 [drm] pitch is 5632 fbcon: radeondrmfb (fb0) is primary device Console: switching to colour frame buffer device 170x48 fb0: radeondrmfb frame buffer device registered panic notifier [drm] Initialized radeon 2.0.0 20080528 for 0000:01:05.0 on minor 0 dracut: Starting plymouth daemon [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [snip] [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[snip] [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 07 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
[snip]
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID eth0: no IPv6 routers present [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [snip] [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 7f 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 3f 00 00 00 00 00 00 00 00 00 00 00 00 ...?............ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID [drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3f ...............?
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>01 00 03 00 00 00 00 00 00 00 00 00 00 03 0f 00 ................ <3>00 00 00 00 00 01 00 00 0f 00 00 00 00 00 00 00 ................ <3>00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 ................ <3>00 0f 00 00 00 00 00 00 00 00 01 00 00 00 00 00 ................ <3>00 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
radeon 0000:01:05.0: DVI-D-1: EDID invalid. [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls awalls@md.metrocast.net wrote:
On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
2010/9/20 Andy Walls awalls@md.metrocast.net:
On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
2010/9/20 Andy Walls awalls@md.metrocast.net:
DRM KMS polling of connections providing errant EDID responses, or polling of "connectors" that have chips responding on DDC I2C bus address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM, will create perpetual noise in dmesg and the system log every 10 seconds. Currently the user has apparently little recourse to silence these messages aside from replacing the offending cable, monitor, or graphics adapter. That recourse is impossible for an unused DVI-D "connector" of an internal graphics processor on a motherboard that provides no physical DVI-D connector.
This change allows the root user to disable (and re-enable) DRM KMS connector polling on a per connector basis via sysfs, like so:
Huh, I didn't imagine solution of this issue that way.
The problems with my initial patch, and related approaches, were:
- They didn't get rid of all the spam in the logs, just the most
verbose portion of it.
- They didn't deal with the root cause of the log spam and all the
related, but unneeded, I/O and processing that was still occurring.
AFAIR previous thread, something else was suggested, it was about storing the fact that user already received warning/info about error.
Yes, that was the discussion.
I went with this patch because:
It deals with the root cause: unneeded DRM KMS connector polling
It eliminates all my DRM KMS connector polling related log spam, not
just the hex dump.
- The existing sysfs structure was already exposing 'struct
drm_connector' members to user-space at per connector granularity
The real root cause of the polling spew is that the radeon module, based on the best information it has (BIOS connector tables, I2C bus probes, etc.), makes a decision on if a connector should be polled and how it should be polled.
Given incorrect BIOS tables, and strange I2C setups, the radeon module is bound to make the wrong decision about polling in some cases. This change is a way for the human to step in a correct things, when the radeon driver gets it wrong.
I'd rather fix the bug for real rather than providing users with an out so that the bug never gets reported.
There is already "an out" on it's way upstream:
http://lkml.org/lkml/2010/9/6/375 http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58...
I noticed it after I submitted this patch. If I'm reading it right, the module parameter fix is very coarse: it applies to all drm adapters and connectors in the system.
What's the actual problem you have?
The actual problem I have is that the radeon driver reports three connectors (HDMI, DVI-D, and VGA) on the motherboard, but there is only one physical connector (VGA). Polling of the HDMI appears to be inhibited by the radeon module code. Polling of the (non-existent?) DVI-D interface yields a lot of log messages and useless I2C transactions.
My precise gripe is with this code path
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drive...
which is being polled every 10 seconds. It is bad for me because this function is noisy:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drive...
and this (insane?) loop multiplies the noise by a factor of 4:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drive...
In a different user's operational context, all that noise may be beneficial.
The real problem to me is that the radeon and drm modules have a single, standard way of dealing with EDID errors. However, EDID errors can happen due to a number of different causes, some of which are external (i.e. in the LCD or CRT monitor). Given that, there really is no "right thing" the drivers can do without input from the user on what the policy should be when a bad EDID is detected.
Do you just want to turn polling off for an unused connecter,
Yes, that's what I would use my proposed patch for.
(If a solution that avoids sysfs is required, I can work up a patch using DRM_IOCTL_MODE_GETPROPERTY & DRM_IOCTL_MODE_SETPROPERTY along with a patch for some utility like xrandr.)
In a larger sense it's about user policy for error reporting by the drm and radeon drivers, and error response by both the drivers and the user.
In the face of EDID errors, a user may want to take the following actions:
ignore the errors supress the errors continue to monitor the errors for a time replace cables replace graphics adapter replace monitor report a bug
All of those end user actions are possible right now, except the one to supress the errors (and the I2C transactions associated with them).
A monitor, cable, and graphics adapter set that is currently experiencing EDID errors, may be otherwise working just fine.
"Because we want to ensure people report bugs," does not seem like a good reason to prevent a user from turning off bogus error messages, for an otherwise working monitor that is providing broken EDID data. What is the resolution of a bug report for a monitor providing bad EDID data going to look like?
I wasn't talking about the broken EDID messages, I was talking about the bogus connector table entries on your board. Those should be properly quirked in the driver in which case, which would avoid the problem all together in your case.
or does the board have a bug in the connector table?
I have not dug into the BIOS connector table bits and bytes to verify, but I'm assuming the connector table is incorrect.
It appears to be incorrect. If you send me a copy of the vbios, I can easily add a quirk. I suspect your board oem may offer several boards with different output configurations and neglected to update the table in some configurations.
If it's a bug, we can add a quirk so that it's properly handled.
I don't see how a quirk table is going to cover the situations different from mine, that also provide bad EDID data in the code path I pointed out. I know how one can add quirks for a connected DVI-D monitor that provides bad EDID data or none at all.
The radeon module already has a connector_table module parameter for quirks. That module option provides some hard-coded connector tables. I had considered adding more to that, but it seemed like a band-aid. Also, IIRC, the connector_table parameter currently applies globally to all radeon graphics adapters in the system, so it doesn't scale to multiple radeon adapters in the system.
It's best to just add a quirk for your board. The connector_table option is just an override for r1xx-r3xx mac and sun cards that do not have useable vbios tables. It's not really directly applicable to atom-based systems like yours.
What physical connectors does the board have what does the driver report in dmesg?
The board only has a physical VGA connector. The graphics adapter is an IGP on an MSI K9A2GM V2/V3 series motherboard (MS-7302). Here are the PCI IDs on the graphics adapter:
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon 2100 [1002:796e] (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. Device [1462:7302]
Below is the dmesg output from the unmodified drm and radeon modules which includes samples of drm module log spam for the first 30 seconds or so after boot.
Regards, Andy
Linux version 2.6.32.19-163.fc12.x86_64 (mockbuild@x86-05.phx2.fedoraproject.org) (gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) ) #1 SMP Wed Aug 18 11:38:54 UTC 2010 [snip!] [drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [drm] radeon: Initializing kernel modesetting. [drm] register mmio base: 0xFE7F0000 [drm] register mmio size: 65536 ATOM BIOS: ATI [drm] GPU reset succeed (RBBM_STATUS=0x10000140) [drm] radeon: VRAM 128M [drm] radeon: VRAM from 0x78000000 to 0x7FFFFFFF [drm] radeon: GTT 512M [drm] radeon: GTT from 0x80000000 to 0x9FFFFFFF alloc irq_desc for 28 on node 0 alloc kstat_irqs on node 0 radeon 0000:01:05.0: irq 28 for MSI/MSI-X [drm] radeon: using MSI. [drm] radeon: irq initialized. [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 963036 kiB. [drm] radeon: 128M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] radeon: 1 quad pipes, 1 z pipes initialized. [drm] radeon: cp idle (0x10000C03) [drm] Loading RS690/RS740 Microcode platform radeon_cp.0: firmware: requesting radeon/RS690_cp.bin [drm] radeon: ring at 0x0000000080000000 [drm] ring test succeeded in 1 usecs [drm] radeon: ib pool ready. [drm] ib test succeeded in 0 usecs [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] DVI-D [drm] HPD2 [drm] DDC: 0x7e40 0x7e60 0x7e44 0x7e64 0x7e48 0x7e68 0x7e4c 0x7e6c [drm] Encoders: [drm] DFP2: INTERNAL_DDI [drm] Connector 2: [drm] HDMI-A [drm] DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c [drm] Encoders: [drm] DFP3: INTERNAL_LVTM1
FWIW, it's actually the HDMI connector that is generating the errors due to the lack of a hpd pin assignment.
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Alex
On Wed, 2010-09-22 at 01:30 -0400, Alex Deucher wrote:
On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls awalls@md.metrocast.net wrote:
In a larger sense it's about user policy for error reporting by the drm and radeon drivers, and error response by both the drivers and the user.
In the face of EDID errors, a user may want to take the following actions:
ignore the errors supress the errors continue to monitor the errors for a time replace cables replace graphics adapter replace monitor report a bug
All of those end user actions are possible right now, except the one to supress the errors (and the I2C transactions associated with them).
A monitor, cable, and graphics adapter set that is currently experiencing EDID errors, may be otherwise working just fine.
"Because we want to ensure people report bugs," does not seem like a good reason to prevent a user from turning off bogus error messages, for an otherwise working monitor that is providing broken EDID data. What is the resolution of a bug report for a monitor providing bad EDID data going to look like?
I wasn't talking about the broken EDID messages, I was talking about the bogus connector table entries on your board. Those should be properly quirked in the driver in which case, which would avoid the problem all together in your case.
The problem with in-kernel quirk databases are
- you'll always end up lagging behind what's being fielded,
- the number of stale entries will grow over the years,
- the scope of the fix for a single quirk entry for the total installed user base is small; each quirk table entry itself has little value
- quirks for working around unreliable attributes still need a reliable system identification method (no big deal for PCI)
- fixing by quirk is a reactionary mode for kernel developers (it's also job security, so sysadmins are stuck coming back for help)
- it increases time to resolve problems for end users.
I don't think it's a good to plan to continually react to manufacturers that have cycle times of 6 months to a year. Quirk tables should be a solution of last resort, when there's nothing else that can be done, IMO.
I understood. A quirk database solves the immediate problem for me and for owners of that MSI motherboard.
My current problem also highlights undesirable behavior that will occur with broken EDIDs. This undesirable behavior will likely resurface in another bug report.
or does the board have a bug in the connector table?
I have not dug into the BIOS connector table bits and bytes to verify, but I'm assuming the connector table is incorrect.
It appears to be incorrect. If you send me a copy of the vbios, I can easily add a quirk. I suspect your board oem may offer several boards with different output configurations and neglected to update the table in some configurations.
Do you have a pointer to a set of steps to follow for extracting that vbios information?
What physical connectors does the board have what does the driver report in dmesg?
The board only has a physical VGA connector. The graphics adapter is an IGP on an MSI K9A2GM V2/V3 series motherboard (MS-7302). Here are the PCI IDs on the graphics adapter:
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon 2100 [1002:796e] (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. Device [1462:7302]
Below is the dmesg output from the unmodified drm and radeon modules which includes samples of drm module log spam for the first 30 seconds or so after boot.
[drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] DVI-D [drm] HPD2 [drm] DDC: 0x7e40 0x7e60 0x7e44 0x7e64 0x7e48 0x7e68 0x7e4c 0x7e6c [drm] Encoders: [drm] DFP2: INTERNAL_DDI [drm] Connector 2: [drm] HDMI-A [drm] DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c [drm] Encoders: [drm] DFP3: INTERNAL_LVTM1
FWIW, it's actually the HDMI connector that is generating the errors due to the lack of a hpd pin assignment.
Are you sure? My /var/log/messages spam insists it is DVI-D-1 (hex dumps omitted):
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: radeon 0000:01:05.0: DVI-D-1: EDID invalid. Sep 22 07:46:13 morgan kernel: [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: radeon 0000:01:05.0: DVI-D-1: EDID invalid. Sep 22 07:46:13 morgan kernel: [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
Regards, Andy
On Wed, 2010-09-22 at 08:31 -0400, Andy Walls wrote:
On Wed, 2010-09-22 at 01:30 -0400, Alex Deucher wrote:
It appears to be incorrect. If you send me a copy of the vbios, I can easily add a quirk. I suspect your board oem may offer several boards with different output configurations and neglected to update the table in some configurations.
Do you have a pointer to a set of steps to follow for extracting that vbios information?
Never mind, I figured it out.
# echo 1 > /sys/class/drm/card0/device/rom # dd if=/sys/class/drm/card0/device/rom of=msi7302igprom.bin # echo 0 > /sys/class/drm/card0/device/rom
I will send it via private email.
Regards, Andy
On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher alexdeucher@gmail.com wrote:
On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls awalls@md.metrocast.net wrote:
On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
2010/9/20 Andy Walls awalls@md.metrocast.net:
On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
2010/9/20 Andy Walls awalls@md.metrocast.net:
DRM KMS polling of connections providing errant EDID responses, or polling of "connectors" that have chips responding on DDC I2C bus address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM, will create perpetual noise in dmesg and the system log every 10 seconds. Currently the user has apparently little recourse to silence these messages aside from replacing the offending cable, monitor, or graphics adapter. That recourse is impossible for an unused DVI-D "connector" of an internal graphics processor on a motherboard that provides no physical DVI-D connector.
This change allows the root user to disable (and re-enable) DRM KMS connector polling on a per connector basis via sysfs, like so:
Huh, I didn't imagine solution of this issue that way.
The problems with my initial patch, and related approaches, were:
- They didn't get rid of all the spam in the logs, just the most
verbose portion of it.
- They didn't deal with the root cause of the log spam and all the
related, but unneeded, I/O and processing that was still occurring.
AFAIR previous thread, something else was suggested, it was about storing the fact that user already received warning/info about error.
Yes, that was the discussion.
I went with this patch because:
It deals with the root cause: unneeded DRM KMS connector polling
It eliminates all my DRM KMS connector polling related log spam, not
just the hex dump.
- The existing sysfs structure was already exposing 'struct
drm_connector' members to user-space at per connector granularity
The real root cause of the polling spew is that the radeon module, based on the best information it has (BIOS connector tables, I2C bus probes, etc.), makes a decision on if a connector should be polled and how it should be polled.
Given incorrect BIOS tables, and strange I2C setups, the radeon module is bound to make the wrong decision about polling in some cases. This change is a way for the human to step in a correct things, when the radeon driver gets it wrong.
I'd rather fix the bug for real rather than providing users with an out so that the bug never gets reported.
There is already "an out" on it's way upstream:
http://lkml.org/lkml/2010/9/6/375 http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58...
I noticed it after I submitted this patch. If I'm reading it right, the module parameter fix is very coarse: it applies to all drm adapters and connectors in the system.
What's the actual problem you have?
The actual problem I have is that the radeon driver reports three connectors (HDMI, DVI-D, and VGA) on the motherboard, but there is only one physical connector (VGA). Polling of the HDMI appears to be inhibited by the radeon module code. Polling of the (non-existent?) DVI-D interface yields a lot of log messages and useless I2C transactions.
My precise gripe is with this code path
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drive...
which is being polled every 10 seconds. It is bad for me because this function is noisy:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drive...
and this (insane?) loop multiplies the noise by a factor of 4:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drive...
In a different user's operational context, all that noise may be beneficial.
The real problem to me is that the radeon and drm modules have a single, standard way of dealing with EDID errors. However, EDID errors can happen due to a number of different causes, some of which are external (i.e. in the LCD or CRT monitor). Given that, there really is no "right thing" the drivers can do without input from the user on what the policy should be when a bad EDID is detected.
Andy, this sure looks like a broken VBIOS to me. First thing would be to update your VBIOS if possible to get a correct table for your hardware. Second would be to add a quirk in the kernel.
There are lots of cases where the kernel does odd things when the BIOS feeds it bad information. Do we really want hundreds of switches in sysfs allowing adjustments for broken BIOS features? We already have the quirk scheme for addressing this.
A simpler solution for reducing the log spam would be to only report the error once, instead of every 10 seconds. The driver could remember it has made the error report and then log another message later if the error was cleared.
Do you just want to turn polling off for an unused connecter,
Yes, that's what I would use my proposed patch for.
(If a solution that avoids sysfs is required, I can work up a patch using DRM_IOCTL_MODE_GETPROPERTY & DRM_IOCTL_MODE_SETPROPERTY along with a patch for some utility like xrandr.)
In a larger sense it's about user policy for error reporting by the drm and radeon drivers, and error response by both the drivers and the user.
In the face of EDID errors, a user may want to take the following actions:
ignore the errors supress the errors continue to monitor the errors for a time replace cables replace graphics adapter replace monitor report a bug
All of those end user actions are possible right now, except the one to supress the errors (and the I2C transactions associated with them).
A monitor, cable, and graphics adapter set that is currently experiencing EDID errors, may be otherwise working just fine.
"Because we want to ensure people report bugs," does not seem like a good reason to prevent a user from turning off bogus error messages, for an otherwise working monitor that is providing broken EDID data. What is the resolution of a bug report for a monitor providing bad EDID data going to look like?
I wasn't talking about the broken EDID messages, I was talking about the bogus connector table entries on your board. Those should be properly quirked in the driver in which case, which would avoid the problem all together in your case.
or does the board have a bug in the connector table?
I have not dug into the BIOS connector table bits and bytes to verify, but I'm assuming the connector table is incorrect.
It appears to be incorrect. If you send me a copy of the vbios, I can easily add a quirk. I suspect your board oem may offer several boards with different output configurations and neglected to update the table in some configurations.
If it's a bug, we can add a quirk so that it's properly handled.
I don't see how a quirk table is going to cover the situations different from mine, that also provide bad EDID data in the code path I pointed out. I know how one can add quirks for a connected DVI-D monitor that provides bad EDID data or none at all.
The radeon module already has a connector_table module parameter for quirks. That module option provides some hard-coded connector tables. I had considered adding more to that, but it seemed like a band-aid. Also, IIRC, the connector_table parameter currently applies globally to all radeon graphics adapters in the system, so it doesn't scale to multiple radeon adapters in the system.
It's best to just add a quirk for your board. The connector_table option is just an override for r1xx-r3xx mac and sun cards that do not have useable vbios tables. It's not really directly applicable to atom-based systems like yours.
What physical connectors does the board have what does the driver report in dmesg?
The board only has a physical VGA connector. The graphics adapter is an IGP on an MSI K9A2GM V2/V3 series motherboard (MS-7302). Here are the PCI IDs on the graphics adapter:
01:05.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon 2100 [1002:796e] (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. Device [1462:7302]
Below is the dmesg output from the unmodified drm and radeon modules which includes samples of drm module log spam for the first 30 seconds or so after boot.
Regards, Andy
Linux version 2.6.32.19-163.fc12.x86_64 (mockbuild@x86-05.phx2.fedoraproject.org) (gcc version 4.4.4 20100630 (Red Hat 4.4.4-10) (GCC) ) #1 SMP Wed Aug 18 11:38:54 UTC 2010 [snip!] [drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [drm] radeon: Initializing kernel modesetting. [drm] register mmio base: 0xFE7F0000 [drm] register mmio size: 65536 ATOM BIOS: ATI [drm] GPU reset succeed (RBBM_STATUS=0x10000140) [drm] radeon: VRAM 128M [drm] radeon: VRAM from 0x78000000 to 0x7FFFFFFF [drm] radeon: GTT 512M [drm] radeon: GTT from 0x80000000 to 0x9FFFFFFF alloc irq_desc for 28 on node 0 alloc kstat_irqs on node 0 radeon 0000:01:05.0: irq 28 for MSI/MSI-X [drm] radeon: using MSI. [drm] radeon: irq initialized. [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 963036 kiB. [drm] radeon: 128M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] radeon: 1 quad pipes, 1 z pipes initialized. [drm] radeon: cp idle (0x10000C03) [drm] Loading RS690/RS740 Microcode platform radeon_cp.0: firmware: requesting radeon/RS690_cp.bin [drm] radeon: ring at 0x0000000080000000 [drm] ring test succeeded in 1 usecs [drm] radeon: ib pool ready. [drm] ib test succeeded in 0 usecs [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] Connector 1: [drm] DVI-D [drm] HPD2 [drm] DDC: 0x7e40 0x7e60 0x7e44 0x7e64 0x7e48 0x7e68 0x7e4c 0x7e6c [drm] Encoders: [drm] DFP2: INTERNAL_DDI [drm] Connector 2: [drm] HDMI-A [drm] DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58 0x7e4c 0x7e5c [drm] Encoders: [drm] DFP3: INTERNAL_LVTM1
FWIW, it's actually the HDMI connector that is generating the errors due to the lack of a hpd pin assignment.
[drm:drm_edid_is_valid] *ERROR* Raw EDID: <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
Alex
On Wed, 2010-09-22 at 09:33 -0400, Jon Smirl wrote:
On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher alexdeucher@gmail.com wrote:
On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls awalls@md.metrocast.net wrote:
On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
2010/9/20 Andy Walls awalls@md.metrocast.net:
On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote:
2010/9/20 Andy Walls awalls@md.metrocast.net:
The real problem to me is that the radeon and drm modules have a single, standard way of dealing with EDID errors. However, EDID errors can happen due to a number of different causes, some of which are external (i.e. in the LCD or CRT monitor). Given that, there really is no "right thing" the drivers can do without input from the user on what the policy should be when a bad EDID is detected.
Andy, this sure looks like a broken VBIOS to me.
Well sure.
But that problem causes other problems in error handling code paths to surface. It also brings to light that there are some cases that are undecidable, or not worth the effort, for the error handling code paths on what the proper action should be.
First thing would be to update your VBIOS if possible to get a correct table for your hardware.
Um, no.
I will not risk taking an operational machine down due to flash write failure, however small the probability, due to the high impact. The reward of shutting up kernel error messages, is not worth the risk.
Second would be to add a quirk in the kernel.
I have expressed my thoughts on quirks in a previous post.
There are lots of cases where the kernel does odd things when the BIOS feeds it bad information. Do we really want hundreds of switches in sysfs allowing adjustments for broken BIOS features?
I see very little downside in giving the user more control over his system. A thousand knobs and switches are worth it for the user, for the one switch that is there when the user needs it to solve a problem.
To dump my VBIOS ROM for Alex, I could have hacked up the radeon driver to dump the ROM. That would have consumed a lot of time. Luckily for me, there was a switch to turn on the ROM and dump it:
# echo 1 > /sys/class/drm/card0/device/rom # dd if=/sys/class/drm/card0/device/rom of=msi7302igprom.bin # echo 0 > /sys/class/drm/card0/device/rom
I never used it before and will likely never use it again. But when I had a problem I needed to solve, its availability made the solution simple and efficient. Time to accomplish tasks is my scarcest resource; time efficiency is very important to me.
The only downside to hundreds of switches and control knobs I can really think of is possibly complexity for the end user. But it turns out, that ignoring the available controls, or ignoring large subsets of the available controls, is how people are going to deal with that complexity. Heck, I ignore most of sysfs almost all the time. I also ignore almost every module option available. My system runs fine without me caring about a majority of the existing switches.
BTW, we already have thousands of switches and controls for kernel internals in linux without sysfs and ioctl()'s:
$ find /lib/modules/`uname -r` -name "*.ko" -exec modinfo {} ; | grep '^parm:' | wc -l 3387
Why do we have that many? They are low cost in complexity, as they can easily be ignored. They are high value in utility, as they give the user control over his system to deal with unusual circumstances.
</rant>
We already have the quirk scheme for addressing this.
A simpler solution for reducing the log spam would be to only report the error once, instead of every 10 seconds. The driver could remember it has made the error report and then log another message later if the error was cleared.
My sysfs implementation was only 69 changed lines in one file:
drivers/gpu/drm/drm_sysfs.c | 69 +++++++++++
I doubt a solution to add logic to the error paths, to try and divine all the sources of EDID errors by saving state and applying rules to take the correct action, is going to be less change than that. I know more than one file will have to change.
Regards, Andy
On Wed, Sep 22, 2010 at 5:07 PM, Andy Walls awalls@md.metrocast.net wrote:
On Wed, 2010-09-22 at 09:33 -0400, Jon Smirl wrote:
On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher alexdeucher@gmail.com wrote:
On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls awalls@md.metrocast.net wrote:
On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
2010/9/20 Andy Walls awalls@md.metrocast.net:
On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote: > 2010/9/20 Andy Walls awalls@md.metrocast.net:
The real problem to me is that the radeon and drm modules have a single, standard way of dealing with EDID errors. However, EDID errors can happen due to a number of different causes, some of which are external (i.e. in the LCD or CRT monitor). Given that, there really is no "right thing" the drivers can do without input from the user on what the policy should be when a bad EDID is detected.
Andy, this sure looks like a broken VBIOS to me.
Well sure.
But that problem causes other problems in error handling code paths to surface. It also brings to light that there are some cases that are undecidable, or not worth the effort, for the error handling code paths on what the proper action should be.
First thing would be to update your VBIOS if possible to get a correct table for your hardware.
Um, no.
I will not risk taking an operational machine down due to flash write failure, however small the probability, due to the high impact. The reward of shutting up kernel error messages, is not worth the risk.
Second would be to add a quirk in the kernel.
I have expressed my thoughts on quirks in a previous post.
There are lots of cases where the kernel does odd things when the BIOS feeds it bad information. Do we really want hundreds of switches in sysfs allowing adjustments for broken BIOS features?
I see very little downside in giving the user more control over his system. A thousand knobs and switches are worth it for the user, for the one switch that is there when the user needs it to solve a problem.
To dump my VBIOS ROM for Alex, I could have hacked up the radeon driver to dump the ROM. That would have consumed a lot of time. Luckily for me, there was a switch to turn on the ROM and dump it:
The ROM is turned off by default due to a provision in the PCI spec that allows the address space of it to be reused after boot. A few old PCI devices make use of this feature. If you turn the ROM on in those machines they will crash.
# echo 1 > /sys/class/drm/card0/device/rom # dd if=/sys/class/drm/card0/device/rom of=msi7302igprom.bin # echo 0 > /sys/class/drm/card0/device/rom
I never used it before and will likely never use it again. But when I had a problem I needed to solve, its availability made the solution simple and efficient. Time to accomplish tasks is my scarcest resource; time efficiency is very important to me.
The only downside to hundreds of switches and control knobs I can really think of is possibly complexity for the end user. But it turns out, that ignoring the available controls, or ignoring large subsets of the available controls, is how people are going to deal with that complexity. Heck, I ignore most of sysfs almost all the time. I also ignore almost every module option available. My system runs fine without me caring about a majority of the existing switches.
BTW, we already have thousands of switches and controls for kernel internals in linux without sysfs and ioctl()'s:
$ find /lib/modules/`uname -r` -name "*.ko" -exec modinfo {} ; | grep '^parm:' | wc -l 3387
Why do we have that many? They are low cost in complexity, as they can easily be ignored. They are high value in utility, as they give the user control over his system to deal with unusual circumstances.
</rant>
We already have the quirk scheme for addressing this.
A simpler solution for reducing the log spam would be to only report the error once, instead of every 10 seconds. The driver could remember it has made the error report and then log another message later if the error was cleared.
My sysfs implementation was only 69 changed lines in one file:
drivers/gpu/drm/drm_sysfs.c | 69 +++++++++++
I doubt a solution to add logic to the error paths, to try and divine all the sources of EDID errors by saving state and applying rules to take the correct action, is going to be less change than that. I know more than one file will have to change.
Regards, Andy
On Wed, Sep 22, 2010 at 5:07 PM, Andy Walls awalls@md.metrocast.net wrote:
On Wed, 2010-09-22 at 09:33 -0400, Jon Smirl wrote:
On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher alexdeucher@gmail.com wrote:
On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls awalls@md.metrocast.net wrote:
On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
2010/9/20 Andy Walls awalls@md.metrocast.net:
On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote: > 2010/9/20 Andy Walls awalls@md.metrocast.net:
The real problem to me is that the radeon and drm modules have a single, standard way of dealing with EDID errors. However, EDID errors can happen due to a number of different causes, some of which are external (i.e. in the LCD or CRT monitor). Given that, there really is no "right thing" the drivers can do without input from the user on what the policy should be when a bad EDID is detected.
Andy, this sure looks like a broken VBIOS to me.
Well sure.
But that problem causes other problems in error handling code paths to surface. It also brings to light that there are some cases that are undecidable, or not worth the effort, for the error handling code paths on what the proper action should be.
First thing would be to update your VBIOS if possible to get a correct table for your hardware.
Um, no.
I will not risk taking an operational machine down due to flash write failure, however small the probability, due to the high impact. The reward of shutting up kernel error messages, is not worth the risk.
Second would be to add a quirk in the kernel.
I have expressed my thoughts on quirks in a previous post.
There are lots of cases where the kernel does odd things when the BIOS feeds it bad information. Do we really want hundreds of switches in sysfs allowing adjustments for broken BIOS features?
I see very little downside in giving the user more control over his system. A thousand knobs and switches are worth it for the user, for the one switch that is there when the user needs it to solve a problem.
To dump my VBIOS ROM for Alex, I could have hacked up the radeon driver to dump the ROM. That would have consumed a lot of time. Luckily for me, there was a switch to turn on the ROM and dump it:
# echo 1 > /sys/class/drm/card0/device/rom # dd if=/sys/class/drm/card0/device/rom of=msi7302igprom.bin # echo 0 > /sys/class/drm/card0/device/rom
I never used it before and will likely never use it again. But when I had a problem I needed to solve, its availability made the solution simple and efficient. Time to accomplish tasks is my scarcest resource; time efficiency is very important to me.
The attached patch should fix up your board. Let me know if it works for you.
Thanks,
Alex
The only downside to hundreds of switches and control knobs I can really think of is possibly complexity for the end user. But it turns out, that ignoring the available controls, or ignoring large subsets of the available controls, is how people are going to deal with that complexity. Heck, I ignore most of sysfs almost all the time. I also ignore almost every module option available. My system runs fine without me caring about a majority of the existing switches.
BTW, we already have thousands of switches and controls for kernel internals in linux without sysfs and ioctl()'s:
$ find /lib/modules/`uname -r` -name "*.ko" -exec modinfo {} ; | grep '^parm:' | wc -l 3387
Why do we have that many? They are low cost in complexity, as they can easily be ignored. They are high value in utility, as they give the user control over his system to deal with unusual circumstances.
</rant>
We already have the quirk scheme for addressing this.
A simpler solution for reducing the log spam would be to only report the error once, instead of every 10 seconds. The driver could remember it has made the error report and then log another message later if the error was cleared.
My sysfs implementation was only 69 changed lines in one file:
drivers/gpu/drm/drm_sysfs.c | 69 +++++++++++
I doubt a solution to add logic to the error paths, to try and divine all the sources of EDID errors by saving state and applying rules to take the correct action, is going to be less change than that. I know more than one file will have to change.
Regards, Andy
On Fri, 2010-09-24 at 15:12 -0400, Alex Deucher wrote:
On Wed, Sep 22, 2010 at 5:07 PM, Andy Walls awalls@md.metrocast.net wrote:
On Wed, 2010-09-22 at 09:33 -0400, Jon Smirl wrote:
On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher alexdeucher@gmail.com wrote:
On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls awalls@md.metrocast.net wrote:
On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote:
2010/9/20 Andy Walls awalls@md.metrocast.net: > On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote: >> 2010/9/20 Andy Walls awalls@md.metrocast.net:
The real problem to me is that the radeon and drm modules have a single, standard way of dealing with EDID errors. However, EDID errors can happen due to a number of different causes, some of which are external (i.e. in the LCD or CRT monitor). Given that, there really is no "right thing" the drivers can do without input from the user on what the policy should be when a bad EDID is detected.
The attached patch should fix up your board. Let me know if it works for you.
That patch suppresses the setup of the HDMI and DVI connectors that don't exist, so the log spam from polling for EDID's is gone for me.
[PATCH] drm/radeon/kms: add quirk for MSI K9A2GM motherboard
Board has no digital connectors
Reported-by: Andy Walls awalls@md.metrocast.net Tested-by: Andy Walls awalls@md.metrocast.net Signed-off-by: Alex Deucher alexdeucher@gmail.com Cc: stable@kernel.org
Yes it works for me, but it's what I'd call a "point solution". There are still these which appear to be the exact same symptoms (perpetual EDID log spam) just for different hardware setups:
https://bugs.freedesktop.org/show_bug.cgi?id=27708 https://partner-bugzilla.redhat.com/show_bug.cgi?id=610362
Here was a broader solution for a particular class of machines (Laptops with i915 chips with an LVDS with a broken EDID) exhibiting those same symptoms:
https://patchwork.kernel.org/patch/83556/
Picking these bugs off one or two at a time, as users report the same symptoms over an over again, is really a waste of users' time. Users wait while their report is queued, a custom kernel patch developed, and a kernel patch makes it through their distro to them.
On a different subject, with your patch applied, I'm now seeing a new error message in my log that I have not seen before:
failed to evaluate ATIF got AE_BAD_PARAMETER
Here's the dmesg from drm:
[drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [drm] initializing kernel modesetting (RS740 0x1002:0x796E). [drm] register mmio base: 0xFE7F0000 [drm] register mmio size: 65536 ATOM BIOS: ATI radeon 0000:01:05.0: VRAM: 128M 0x78000000 - 0x7FFFFFFF (128M used) radeon 0000:01:05.0: GTT: 512M 0x80000000 - 0x9FFFFFFF [drm] radeon: irq initialized. [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 963022 kiB. [TTM] Initializing pool allocator. [drm] radeon: 128M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] radeon: 1 quad pipes, 1 z pipes initialized. [drm] Loading RS690/RS740 Microcode [drm] radeon: ring at 0x0000000080000000 [drm] ring test succeeded in 1 usecs [drm] radeon: ib pool ready. [drm] ib test succeeded in 0 usecs [drm] Enabling audio support failed to evaluate ATIF got AE_BAD_PARAMETER [drm] Default TV standard: NTSC [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] fb mappable at 0xD8040000 [drm] vram apper at 0xD8000000 [drm] size 4325376 [drm] fb depth is 24 [drm] pitch is 5632 fbcon: radeondrmfb (fb0) is primary device Console: switching to colour frame buffer device 170x48 fb0: radeondrmfb frame buffer device drm: registered panic notifier Slow work thread pool: Starting up Slow work thread pool: Ready [drm] Initialized radeon 2.6.0 20080528 for 0000:01:05.0 on minor 0
By inspection of the code, it looks like the handle being passed into radeon_atif_call() by radeon_acpi_init() may be bad. I'm not sure why that would be though.
I won't have time until Thursday to run it down any further.
Regards, Andy
Thanks,
Alex
On Sun, Sep 26, 2010 at 2:12 PM, Andy Walls awalls@md.metrocast.net wrote:
On Fri, 2010-09-24 at 15:12 -0400, Alex Deucher wrote:
On Wed, Sep 22, 2010 at 5:07 PM, Andy Walls awalls@md.metrocast.net wrote:
On Wed, 2010-09-22 at 09:33 -0400, Jon Smirl wrote:
On Wed, Sep 22, 2010 at 1:30 AM, Alex Deucher alexdeucher@gmail.com wrote:
On Tue, Sep 21, 2010 at 1:30 PM, Andy Walls awalls@md.metrocast.net wrote:
On Tue, 2010-09-21 at 00:26 -0400, Alex Deucher wrote: > 2010/9/20 Andy Walls awalls@md.metrocast.net: > > On Mon, 2010-09-20 at 20:29 +0200, Rafał Miłecki wrote: > >> 2010/9/20 Andy Walls awalls@md.metrocast.net:
The real problem to me is that the radeon and drm modules have a single, standard way of dealing with EDID errors. However, EDID errors can happen due to a number of different causes, some of which are external (i.e. in the LCD or CRT monitor). Given that, there really is no "right thing" the drivers can do without input from the user on what the policy should be when a bad EDID is detected.
The attached patch should fix up your board. Let me know if it works for you.
That patch suppresses the setup of the HDMI and DVI connectors that don't exist, so the log spam from polling for EDID's is gone for me.
[PATCH] drm/radeon/kms: add quirk for MSI K9A2GM motherboard
Board has no digital connectors
Reported-by: Andy Walls awalls@md.metrocast.net Tested-by: Andy Walls awalls@md.metrocast.net Signed-off-by: Alex Deucher alexdeucher@gmail.com Cc: stable@kernel.org
Thanks, I've sent this to Dave.
Yes it works for me, but it's what I'd call a "point solution". There are still these which appear to be the exact same symptoms (perpetual EDID log spam) just for different hardware setups:
https://bugs.freedesktop.org/show_bug.cgi?id=27708 https://partner-bugzilla.redhat.com/show_bug.cgi?id=610362
Here was a broader solution for a particular class of machines (Laptops with i915 chips with an LVDS with a broken EDID) exhibiting those same symptoms:
https://patchwork.kernel.org/patch/83556/
Picking these bugs off one or two at a time, as users report the same symptoms over an over again, is really a waste of users' time. Users wait while their report is queued, a custom kernel patch developed, and a kernel patch makes it through their distro to them.
These are two different issues. The board needs a quirk to fix up the bogus connectors regardless of the edid crap. As to what to do about the edid stuff, I'd personally prefer we just silence most of the warnings or at least just warn once. I think we are a bit too pedantic about edid errors in general. I think a good rule of thumb would be to drop an edid if it doesn't have a valid header, but use it if it's valid, but has something like a bad checksum or extension block problems.
On a different subject, with your patch applied, I'm now seeing a new error message in my log that I have not seen before:
failed to evaluate ATIF got AE_BAD_PARAMETER
Here's the dmesg from drm:
[drm] Initialized drm 1.1.0 20060810 [drm] radeon defaulting to kernel modesetting. [drm] radeon kernel modesetting enabled. radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [drm] initializing kernel modesetting (RS740 0x1002:0x796E). [drm] register mmio base: 0xFE7F0000 [drm] register mmio size: 65536 ATOM BIOS: ATI radeon 0000:01:05.0: VRAM: 128M 0x78000000 - 0x7FFFFFFF (128M used) radeon 0000:01:05.0: GTT: 512M 0x80000000 - 0x9FFFFFFF [drm] radeon: irq initialized. [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 963022 kiB. [TTM] Initializing pool allocator. [drm] radeon: 128M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] radeon: 1 quad pipes, 1 z pipes initialized. [drm] Loading RS690/RS740 Microcode [drm] radeon: ring at 0x0000000080000000 [drm] ring test succeeded in 1 usecs [drm] radeon: ib pool ready. [drm] ib test succeeded in 0 usecs [drm] Enabling audio support failed to evaluate ATIF got AE_BAD_PARAMETER [drm] Default TV standard: NTSC [drm] Radeon Display Connectors [drm] Connector 0: [drm] VGA [drm] DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48 0x7e5c 0x7e4c [drm] Encoders: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] fb mappable at 0xD8040000 [drm] vram apper at 0xD8000000 [drm] size 4325376 [drm] fb depth is 24 [drm] pitch is 5632 fbcon: radeondrmfb (fb0) is primary device Console: switching to colour frame buffer device 170x48 fb0: radeondrmfb frame buffer device drm: registered panic notifier Slow work thread pool: Starting up Slow work thread pool: Ready [drm] Initialized radeon 2.6.0 20080528 for 0000:01:05.0 on minor 0
By inspection of the code, it looks like the handle being passed into radeon_atif_call() by radeon_acpi_init() may be bad. I'm not sure why that would be though.
I won't have time until Thursday to run it down any further.
Does your board actually have the ATIF method? I think your board is probably too old. Newer kernels should only warn when the method is present and there's an error. The method really only exists on newer laptops as far as I know.
Alex
Regards, Andy
Thanks,
Alex
Per Greg's request, here is a resend of my previous patch to add sysfs entries to allow manual override of DRM KMS connector polling actions, with accompanying documentation.
Only documentation has been added. No code has changed from the previous patch submission.
diffstat:
Documentation/ABI/testing/sysfs-drm | 208 ++++++++++++++++++++++++++++++++++++ drivers/gpu/drm/drm_sysfs.c | 69 +++++++++++ 2 files changed, 277 insertions(+)
Regards, Andy
DRM KMS polling of connections providing errant EDID responses, or polling of "connectors" that have chips responding on DDC I2C bus address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM, will create perpetual noise in dmesg and the system log every 10 seconds. Currently the user has apparently little recourse to silence these messages aside from replacing the offending cable, monitor, or graphics adapter. That recourse is impossible for an unused DVI-D "connector" of an internal graphics processor on a motherboard that provides no physical DVI-D connector.
This change allows the root user to disable (and re-enable) DRM KMS connector polling on a per connector basis via sysfs, like so:
# cat /sys/class/drm/card0/card0-DVI-D-1/polled [hotplug_detectable] connect disconnect
# echo > /sys/class/drm/card0/card0-DVI-D-1/polled # cat /sys/class/drm/card0/card0-DVI-D-1/polled hotplug_detectable connect disconnect
# echo " connect hotplug_detectable " > \ /sys/class/drm/card0/card0-DVI-D-1/polled # cat /sys/class/drm/card0/card0-DVI-D-1/polled [hotplug_detectable] [connect] disconnect
# echo > /sys/class/drm/card0/card0-DVI-D-1/polled # cat /sys/class/drm/card0/card0-DVI-D-1/polled hotplug_detectable connect disconnect
with the enabled poll types for the connector denoted in brackets: []. This allows the root user to silence DRM KMS log spam for locally known uncorrectable conditions.
Signed-off-by Andy Walls awalls@md.metrocast.net
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c index 86118a7..8e0807d 100644 --- a/drivers/gpu/drm/drm_sysfs.c +++ b/drivers/gpu/drm/drm_sysfs.c @@ -318,11 +318,80 @@ static ssize_t select_subconnector_show(struct device *device, drm_get_dvi_i_select_name((int)subconnector)); }
+static const struct { + uint8_t mask; + const char *name; +} polled_bit_names[] = { + { DRM_CONNECTOR_POLL_HPD, "hotplug_detectable" }, + { DRM_CONNECTOR_POLL_CONNECT, "connect" }, + { DRM_CONNECTOR_POLL_DISCONNECT, "disconnect" }, +}; + +/* + * Return the decoded contents of connector->polled, using the names of the + * all the bit masks. Bits that are set, have their names enclosed in brackets. + */ +static ssize_t polled_show(struct device *dev, struct device_attribute *attr, + char *buf) +{ + struct drm_connector *connector = to_drm_connector(dev); + char *tmp; + int i; + + tmp = buf; + for (i = 0; i < ARRAY_SIZE(polled_bit_names); i++) { + if (connector->polled & polled_bit_names[i].mask) + tmp += sprintf(tmp, "[%s] ", polled_bit_names[i].name); + else + tmp += sprintf(tmp, "%s ", polled_bit_names[i].name); + } + + if (tmp != buf) + *(tmp - 1) = '\n'; + return tmp - buf; +} + +/* + * Change the state of connector->polled, given input bit-mask name-strings + * that are separated by space or newline. + */ +static ssize_t polled_store(struct device *dev, struct device_attribute *attr, + const char *buf, size_t count) +{ + struct drm_connector *connector = to_drm_connector(dev); + const char *tmp; + int i; + uint8_t polled; + + /* Polling of this connector will cease, if no match is made below */ + polled = 0; + + /* Incrementally split and parse the input */ + while ((tmp = strsep((char **) &buf, " \n")) != NULL) { + + /* Don't waste effort on multiple adjacent separators */ + if (*tmp == '\0') + continue; + + /* Check for a match with a connector poll type name */ + for (i = 0; i < ARRAY_SIZE(polled_bit_names); i++) { + if (!strncasecmp(tmp, polled_bit_names[i].name, + strlen(polled_bit_names[i].name))) { + polled |= polled_bit_names[i].mask; + break; + } + } + } + connector->polled = polled; + return count; +} + static struct device_attribute connector_attrs[] = { __ATTR_RO(status), __ATTR_RO(enabled), __ATTR_RO(dpms), __ATTR_RO(modes), + __ATTR(polled, 0644, polled_show, polled_store), };
/* These attributes are for both DVI-I connectors and all types of tv-out. */
This is the initial addition of documentation for the drm module's sysfs entries. It provides a drm sysfs entries overview, and a detailed description of the new drm per output connector "polled" entry in sysfs.
Signed-of-by: Andy Walls awalls@md.metrocast.net
diff --git a/Documentation/ABI/testing/sysfs-drm b/Documentation/ABI/testing/sysfs-drm new file mode 100644 index 0000000..18a017a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-drm @@ -0,0 +1,208 @@ +Direct Rendering Infrastructure (DRI) Direct Rendering Manager (drm) module +and Translation Table Manager (ttm) module sysfs entries + +Example class view showing a single graphics adapter with three output +connectors, a special control device node for the graphics adapter, and the +Translation Table Manager (ttm) graphics memory manager virtual device: + + /sys/class/drm/ + ├── card0 -> ../../devices/<...>/drm/card0 + ├── card0-DVI-D-1 -> ../../devices/<...>/drm/card0/card0-DVI-D-1 + ├── card0-HDMI Type A-1 -> ../../devices/<...>/drm/card0/card0-HDMI Type A-1 + ├── card0-VGA-1 -> ../../devices/<...>/drm/card0/card0-VGA-1 + ├── controlD64 -> ../../devices/<...>/drm/controlD64 + ├── ttm -> ../../devices/virtual/drm/ttm + └── version + + 6 directories, 1 file + + +Corresponding DRI device nodes for the example graphics adapter, with +additional ACL properties on card0 granting rw perms to the X/console user: + + crw-rw----+ 1 root video 226, 0 2010-09-21 20:52 /dev/dri/card0 + crw-rw-rw-. 1 root video 226, 64 2010-09-21 20:51 /dev/dri/controlD64 + + +Example physical device view for a single graphics adapter with three output +connectors and a special control device node for the graphics adapter: + + /sys/devices/<...>/drm + ├── card0 + │ ├── card0-DVI-D-1 + │ │ ├── device -> ../../card0 + │ │ ├── dpms + │ │ ├── edid + │ │ ├── enabled + │ │ ├── modes + │ │ ├── polled + │ │ ├── power + │ │ │ ├── control + │ │ │ ├── runtime_active_time + │ │ │ ├── runtime_status + │ │ │ ├── runtime_suspended_time + │ │ │ ├── wakeup + │ │ │ └── wakeup_count + │ │ ├── status + │ │ ├── subsystem -> ../../../../../../../class/drm + │ │ └── uevent + │ ├── card0-HDMI Type A-1 + │ │ ├── device -> ../../card0 + │ │ ├── dpms + │ │ ├── edid + │ │ ├── enabled + │ │ ├── modes + │ │ ├── polled + │ │ ├── power + │ │ │ ├── control + │ │ │ ├── runtime_active_time + │ │ │ ├── runtime_status + │ │ │ ├── runtime_suspended_time + │ │ │ ├── wakeup + │ │ │ └── wakeup_count + │ │ ├── status + │ │ ├── subsystem -> ../../../../../../../class/drm + │ │ └── uevent + │ ├── card0-VGA-1 + │ │ ├── device -> ../../card0 + │ │ ├── dpms + │ │ ├── edid + │ │ ├── enabled + │ │ ├── modes + │ │ ├── polled + │ │ ├── power + │ │ │ ├── control + │ │ │ ├── runtime_active_time + │ │ │ ├── runtime_status + │ │ │ ├── runtime_suspended_time + │ │ │ ├── wakeup + │ │ │ └── wakeup_count + │ │ ├── status + │ │ ├── subsystem -> ../../../../../../../class/drm + │ │ └── uevent + │ ├── dev + │ ├── device -> ../../../0000:01:05.0 + │ ├── power + │ │ ├── control + │ │ ├── runtime_active_time + │ │ ├── runtime_status + │ │ ├── runtime_suspended_time + │ │ ├── wakeup + │ │ └── wakeup_count + │ ├── subsystem -> ../../../../../../class/drm + │ └── uevent + └── controlD64 + ├── dev + ├── device -> ../../../0000:01:05.0 + ├── power + │ ├── control + │ ├── runtime_active_time + │ ├── runtime_status + │ ├── runtime_suspended_time + │ ├── wakeup + │ └── wakeup_count + ├── subsystem -> ../../../../../../class/drm + └── uevent + + 20 directories, 55 files + + +Example virtual device view view showing the Translation Table Manager (ttm) +graphics memory manager virtual device: + + /sys/devices/virtual/drm + └── ttm + ├── buffer_objects + │ └── bo_count + ├── memory_accounting + │ ├── kernel + │ │ ├── available_memory + │ │ ├── emergency_memory + │ │ ├── swap_limit + │ │ ├── used_memory + │ │ └── zone_memory + │ └── pool + │ ├── pool_allocation_size + │ ├── pool_max_size + │ └── pool_small_allocation + ├── power + │ ├── control + │ ├── runtime_active_time + │ ├── runtime_status + │ ├── runtime_suspended_time + │ ├── wakeup + │ └── wakeup_count + ├── subsystem -> ../../../../class/drm + └── uevent + + 7 directories, 16 files + + + +Where: /sys/devices/<...>/drm/cardN/cardN-C-M/polled + For N a decimal system graphics adapter number: 0, 1, 2, ... + For C a connector type name (including spaces) from the set: + Unknown + VGA + DVI-I + DVI-D + DVI-A + Composite + SVIDEO + LVDS + Component + 9-pin DIN + DisplayPort + HDMI Type A + HDMI Type B + TV + Embedded DisplayPort + For M a decimal connector number for connectors of that type + over all the graphics adapters in the system: 1, 2, ... +Date: 22 September 2010 +KernelVersion: 2.6.37 +Contact: Andy Walls awalls@md.metrocast.net +Description: + Manual control over DRM Kernel Mode Set (KMS) output connector + hotplug/connect/disconnect polling criteria. The graphics + adapter drm driver (e.g. radeon, i915, nouveau) will detect + the available connectors on a graphics adapter and set polling + criteria flags for the connector to specify for what events the + 0.1 Hz DRM KMS poll of the connector should look. + + A read of the contents of this entry will show what flags are + available, with the names of flags that are set for the + connector enclosed in brackets: + + # cat /sys/devices/.../drm/card0/card0-DVI-D-1/polled + [hotplug_detectable] connect disconnect + + A write of flags names to this entry, will clear the current + flag settings and set the poll criteria flags for that + connector to those specified names: + + # echo " disconnect connect " > \ + /sys/devices/.../drm/card0/card0-DVI-D-1/polled + # cat /sys/devices/.../drm/card0/card0-DVI-D-1/polled + hotplug_detectable [connect] [disconnect] + + # echo > /sys/devices/.../drm/card0/card0-DVI-D-1/polled + # cat /sys/devices/.../drm/card0/card0-DVI-D-1/polled + hotplug_detectable connect disconnect + + The flags have the following meanings in drm_crtc_helper.c: + + hotplug_detectable: + always attempt to detect connection status upon poll + don't automatically set up another poll of connector + + connect: + attempt to detect "connect" events + automatically set up another poll of connector + + disconnect: + attempt to detect "disconnect" events + automatically set up another poll of connector + + Clearing all three flags will disable any detection actions + being taken for that connector during the 0.1 Hz poll.
On Tue, Sep 21, 2010 at 11:20:22PM -0400, Andy Walls wrote:
+Where: /sys/devices/<...>/drm/cardN/cardN-C-M/polled
For N a decimal system graphics adapter number: 0, 1, 2, ...
For C a connector type name (including spaces) from the set:
Spaces? Really? Yeah, I know it will work just fine, but why go out of your way to make it hard for people?
Unknown
VGA
DVI-I
DVI-D
DVI-A
Composite
SVIDEO
LVDS
Component
9-pin DIN
DisplayPort
HDMI Type A
HDMI Type B
TV
Embedded DisplayPort
You could always just use a '_' instead of a space for those that need it.
thanks,
greg k-h
On Wed, 2010-09-22 at 08:06 -0700, Greg KH wrote:
On Tue, Sep 21, 2010 at 11:20:22PM -0400, Andy Walls wrote:
+Where: /sys/devices/<...>/drm/cardN/cardN-C-M/polled
For N a decimal system graphics adapter number: 0, 1, 2, ...
For C a connector type name (including spaces) from the set:
Spaces? Really? Yeah, I know it will work just fine, but why go out of your way to make it hard for people?
Not my fault. It was like that when I got here.
$ ls -d /sys/devices/pci0000:00/0000:00:01.0/0000:01:05.0/drm//card0/card0* /sys/devices/pci0000:00/0000:00:01.0/0000:01:05.0/drm//card0/card0-DVI-D-1 /sys/devices/pci0000:00/0000:00:01.0/0000:01:05.0/drm//card0/card0-HDMI Type A-1 /sys/devices/pci0000:00/0000:00:01.0/0000:01:05.0/drm//card0/card0-VGA-1
I only added one entry, "polled", in those existing directories.
BTW, Jon Smirl, IBM Corp, and you have Copyright credit in the drm_sysfs.c file that creates those directories with spaces. ;)
I'll also gripe that PCI's colons are pretty annoying on the command line too, since they have to be escaped as well.
HDMI Type A
HDMI Type B
TV
Embedded DisplayPort
You could always just use a '_' instead of a space for those that need it.
A trivial patch here would do that:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=blob;f=drive...
but I have no idea what that might break.
Regards, Andy
On Wed, Sep 22, 2010 at 12:36:06PM -0400, Andy Walls wrote:
On Wed, 2010-09-22 at 08:06 -0700, Greg KH wrote:
On Tue, Sep 21, 2010 at 11:20:22PM -0400, Andy Walls wrote:
+Where: /sys/devices/<...>/drm/cardN/cardN-C-M/polled
For N a decimal system graphics adapter number: 0, 1, 2, ...
For C a connector type name (including spaces) from the set:
Spaces? Really? Yeah, I know it will work just fine, but why go out of your way to make it hard for people?
Not my fault. It was like that when I got here.
Ah, ok, sorry about that, I didn't realize it. No objection from me then, thanks for the documentation.
greg k-h
On Mon, Sep 20, 2010 at 08:59:00AM -0400, Andy Walls wrote:
DRM KMS polling of connections providing errant EDID responses, or polling of "connectors" that have chips responding on DDC I2C bus address 0xA0/0xA1 with no actual physical connector nor EDID EEPROM, will create perpetual noise in dmesg and the system log every 10 seconds. Currently the user has apparently little recourse to silence these messages aside from replacing the offending cable, monitor, or graphics adapter. That recourse is impossible for an unused DVI-D "connector" of an internal graphics processor on a motherboard that provides no physical DVI-D connector.
This change allows the root user to disable (and re-enable) DRM KMS connector polling on a per connector basis via sysfs, like so:
# cat /sys/class/drm/card0/card0-DVI-D-1/polled [hotplug_detectable] connect disconnect # echo > /sys/class/drm/card0/card0-DVI-D-1/polled # cat /sys/class/drm/card0/card0-DVI-D-1/polled hotplug_detectable connect disconnect # echo " connect hotplug_detectable " > \ /sys/class/drm/card0/card0-DVI-D-1/polled # cat /sys/class/drm/card0/card0-DVI-D-1/polled [hotplug_detectable] [connect] disconnect # echo > /sys/class/drm/card0/card0-DVI-D-1/polled # cat /sys/class/drm/card0/card0-DVI-D-1/polled hotplug_detectable connect disconnect
with the enabled poll types for the connector denoted in brackets: []. This allows the root user to silence DRM KMS log spam for locally known uncorrectable conditions.
Signed-off-by Andy Walls awalls@md.metrocast.net
You are adding a sysfs file, yet you forgot to add a file in Documentation/ABI. Please fix that and resend the patch.
thanks,
greg k-h
On Mon, 2010-09-20 at 11:52 -0700, Greg KH wrote:
On Mon, Sep 20, 2010 at 08:59:00AM -0400, Andy Walls wrote:
This change allows the root user to disable (and re-enable) DRM KMS connector polling on a per connector basis via sysfs, like so:
# cat /sys/class/drm/card0/card0-DVI-D-1/polled [hotplug_detectable] connect disconnect
You are adding a sysfs file, yet you forgot to add a file in Documentation/ABI. Please fix that and resend the patch.
Oops, process failure, sorry. Will do.
Regards, Andy
[cc'd chris wilson]
Hi Andy!
On Mon, 20 Sep 2010 19:02:30 -0400 Andy Walls awalls@md.metrocast.net wrote:
BTW, I found that Chris Wilson recently committed a change to inhibit all drm connector polling globally for a different reason:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58...
That commit message shows a case where the driver decides polling needs to happen, but the human knows differently and manual control over connector polling mitigates the problem.
On Mon, 20 Sep 2010 17:11:48 -0400 Andy Walls awalls@md.metrocast.net wrote:
On Mon, 2010-09-20 at 11:52 -0700, Greg KH wrote:
On Mon, Sep 20, 2010 at 08:59:00AM -0400, Andy Walls wrote:
This change allows the root user to disable (and re-enable) DRM KMS connector polling on a per connector basis via sysfs, like so:
# cat /sys/class/drm/card0/card0-DVI-D-1/polled [hotplug_detectable] connect disconnect
You are adding a sysfs file, yet you forgot to add a file in Documentation/ABI. Please fix that and resend the patch.
Oops, process failure, sorry. Will do.
Regards, Andy
I thought sysfs files should be one thing per file... so, maybe card0-DVI-D-1/link_status and card0-DVI-D-1/hotplug_detectable with 0/1 content would be easier to manipulate and parse?
I have to defer to the drm maintainers for the usecases. But how is having a monitor with a broken edid handled right now? While the output is connected and used, it probably just stops polling?
cheers, Flo
On Wed, 2010-09-22 at 11:44 +0200, Florian Mickler wrote:
[cc'd chris wilson]
Oops. Thanks!
Hi Andy!
On Mon, 20 Sep 2010 19:02:30 -0400 Andy Walls awalls@md.metrocast.net wrote:
BTW, I found that Chris Wilson recently committed a change to inhibit all drm connector polling globally for a different reason:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=e58...
That commit message shows a case where the driver decides polling needs to happen, but the human knows differently and manual control over connector polling mitigates the problem.
On Mon, 20 Sep 2010 17:11:48 -0400 Andy Walls awalls@md.metrocast.net wrote:
On Mon, 2010-09-20 at 11:52 -0700, Greg KH wrote:
On Mon, Sep 20, 2010 at 08:59:00AM -0400, Andy Walls wrote:
This change allows the root user to disable (and re-enable) DRM KMS connector polling on a per connector basis via sysfs, like so:
# cat /sys/class/drm/card0/card0-DVI-D-1/polled [hotplug_detectable] connect disconnect
You are adding a sysfs file, yet you forgot to add a file in Documentation/ABI. Please fix that and resend the patch.
Oops, process failure, sorry. Will do.
Regards, Andy
I thought sysfs files should be one thing per file... so, maybe card0-DVI-D-1/link_status and card0-DVI-D-1/hotplug_detectable with 0/1 content would be easier to manipulate and parse?
If precedent matters, the sysfs nodes for setting
the IO scheduler the active trigger function on an LED the active IR remote control protocols
all use the same sort of paradigm as I did.
The IO scheduler and LED trigger ones allow the user to set 1 of N choices. The IR protocol one allows the user to set M of N choices. They all uses brackets to differentiate [set] vs unset.
I have to defer to the drm maintainers for the usecases. But how is having a monitor with a broken edid handled right now? While the output is connected and used, it probably just stops polling?
Not from what I can see. I could very well be wrong on that, so please someone double check me.
This error message sequence, and from what I saw in the code, indicates to me that the gripe for a constantly bad EDID will never end:
Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: radeon 0000:01:05.0: DVI-D-1: EDID invalid. Sep 22 07:46:13 morgan kernel: [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: [drm:drm_edid_is_valid] *ERROR* Raw EDID: Sep 22 07:46:13 morgan kernel: radeon 0000:01:05.0: DVI-D-1: EDID invalid. Sep 22 07:46:13 morgan kernel: [drm:radeon_dvi_detect] *ERROR* DVI-D-1: probed a monitor but no|invalid EDID
This time around we
"probed a monitor but no|invalid EDID"
so lets do it again later, and maybe we'll get a different result.
That's legitimate to do once or twice because of transient conditions: one may get a bad EDID due to monitor power on/off or cable connect/disconnect.
To keep doing it for persistent error conditions, when the user fully understands the source of the error and has assessed the impact as inconsequential, is annoying.
By now, I guess everyone can tell at least I'm annoyed by it. :)
Regards, Andy
dri-devel@lists.freedesktop.org