| Summary: | All 3 monitor EDIDs show the same | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Jim Cromie <jim.cromie> | ||||||||||
| Component: | DRM/Radeon | Assignee: | Default DRI bug account <dri-devel> | ||||||||||
| Status: | RESOLVED NOTABUG | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | medium | ||||||||||||
| Version: | XOrg git | ||||||||||||
| Hardware: | Other | ||||||||||||
| OS: | All | ||||||||||||
| Whiteboard: | |||||||||||||
| i915 platform: | i915 features: | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Jim Cromie
2013-12-12 19:27:24 UTC
Please attach your xorg log, xrandr --verbose, and dmesg output. Created attachment 90726 [details]
Xorg.0.log
Created attachment 90727 [details]
xrandr --verbose
According to your log, all the EDIDs are correct. It looks like the drm sysfs layer incorrectly reports the same edid for connectors via sysfs, but the driver has the correct information. Created attachment 90730 [details]
dmesg for 3.13.0-rc3-x2a-00302-g8d27637
I have rebooted since opening this bug-report.
The next reboot didnt have the GPU-lockup that was present in
the original report:
radeon 0000:01:00.0: GPU lockup CP stall for more than 10017msec
radeon 0000:01:00.0: GPU lockup (waiting for 0x000000000000006b last fence id 0x0000000000000069 on ring 0)
[drm:rv770_stop_dpm] *ERROR* Could not force DPM to low.
[drm] Disabling audio 0 support
radeon 0000:01:00.0: Saved 55 dwords of commands on ring 0.
radeon 0000:01:00.0: GPU softreset: 0x00000008
radeon 0000:01:00.0: GRBM_STATUS = 0xA0003828
radeon 0000:01:00.0: GRBM_STATUS_SE0 = 0x00000007
radeon 0000:01:00.0: GRBM_STATUS_SE1 = 0x00000007
...
this and the previous attachments are from a later reboot,
to keep things consistent at least.
Created attachment 90733 [details]
dmesg with GPU lockup (only happened once)
This is the dmesg from the original report.
Its from a slightly older kernel:
3.13.0-rc3-x2a-00174-g9538e10-1stboot/dmesg
the GPU lockup didnt happen on 2ndboot (of same kernel),
I have that too and will attach it if you want to see it too.
A GPU lockup is a separate issue and is usually caused by bugs in the userspace drivers (mesa or ddx). I'd suggest upgrading your userspace stack if you are using an older version. (In reply to comment #4) > According to your log, all the EDIDs are correct. It looks like the drm > sysfs layer incorrectly reports the same edid for connectors via sysfs, but > the driver has the correct information. yes, 3 different monitors are identified: [jimc@groucho bootlogs]$ grep Manufacturer /var/log/Xorg.0.log [ 30.170] (II) RADEON(0): Manufacturer: DEL Model: a039 Serial#: 876102485 [ 30.171] (II) RADEON(0): Manufacturer's mask: 0 [ 30.205] (II) RADEON(0): Manufacturer: ACR Model: ad99 Serial#: 1914720286 [ 30.206] (II) RADEON(0): Manufacturer's mask: 0 [ 30.269] (II) RADEON(0): Manufacturer: LNX Model: 0 Serial#: 0 [ 30.269] (II) RADEON(0): Manufacturer's mask: 0 fwiw, the last one is an AOC E2252S monitor, I guess "LNX" is a placeholder/default due to the Raw EDID errors, happening since I plugged in the AOC. [ 2.362551] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 153 [ 2.362594] Raw EDID: [ 2.362601] 00 ff ff ff ff ff ff 00 05 e3 52 22 db 06 00 00 [ 2.362623] 1b 17 01 03 68 30 1b 78 2a ee d1 a5 55 48 37 ff [ 2.362644] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2.362666] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2.362687] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2.362709] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2.362731] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 2.362752] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Those remainder errors appear to be random, varying between the 2 boots of the rc3-00174 kernel that I recorded (and the others too) [jimc@groucho bootlogs]$ grep remainder 3.13.0-rc3-x2a-00174-g9538e10-*/dmesg | sort -t: -k2 3.13.0-rc3-x2a-00174-g9538e10-2ndboot/dmesg: [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 119 3.13.0-rc3-x2a-00174-g9538e10-2ndboot/dmesg: [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 128 3.13.0-rc3-x2a-00174-g9538e10-2ndboot/dmesg: [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 130 3.13.0-rc3-x2a-00174-g9538e10-1stboot/dmesg: [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 200 3.13.0-rc3-x2a-00174-g9538e10-1stboot/dmesg: [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 241 3.13.0-rc3-x2a-00174-g9538e10-2ndboot/dmesg: [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 243 3.13.0-rc3-x2a-00174-g9538e10-1stboot/dmesg: [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 244 3.13.0-rc3-x2a-00174-g9538e10-1stboot/dmesg: [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 251 3.13.0-rc3-x2a-00174-g9538e10-1stboot/dmesg: [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 87 So I agree that sysfs is somehow to blame for the original worry. I guess I'll post over on LKML, and refer back to this bug-rpt. After testing if the EDID cmdline addition might be involved. (In reply to comment #8) > fwiw, the last one is an AOC E2252S monitor, > I guess "LNX" is a placeholder/default due to the Raw EDID errors, > happening since I plugged in the AOC. Yes, it comes from edid/1920x1080.bin > > So I agree that sysfs is somehow to blame for the original worry. > I guess I'll post over on LKML, and refer back to this bug-rpt. > After testing if the EDID cmdline addition might be involved. You might try dri-devel. (In reply to comment #7) > A GPU lockup is a separate issue and is usually caused by bugs in the > userspace drivers (mesa or ddx). I'd suggest upgrading your userspace stack > if you are using an older version. hmm. Im on Fedora-19, updated a few days ago: Dec 09 08:51:39 Updated: mesa-libglapi-9.2.4-1.20131128.fc19.x86_64 Dec 09 08:51:40 Updated: mesa-libGL-9.2.4-1.20131128.fc19.x86_64 Dec 09 08:52:17 Updated: mesa-libgbm-9.2.4-1.20131128.fc19.x86_64 Dec 09 08:52:18 Updated: mesa-libEGL-9.2.4-1.20131128.fc19.x86_64 Dec 09 08:52:52 Updated: mesa-filesystem-9.2.4-1.20131128.fc19.x86_64 Dec 09 08:53:32 Updated: mesa-dri-drivers-9.2.4-1.20131128.fc19.x86_64 Dec 09 08:54:13 Updated: mesa-libEGL-devel-9.2.4-1.20131128.fc19.x86_64 Dec 09 08:54:39 Updated: mesa-libGL-devel-9.2.4-1.20131128.fc19.x86_64 Dec 09 08:56:45 Updated: mesa-libwayland-egl-9.2.4-1.20131128.fc19.x86_64 Dec 09 08:56:47 Updated: mesa-libxatracker-9.2.4-1.20131128.fc19.x86_64 I only saw the error once, and I didnt notice any misbehavior (that said, recent behavior wrt low-res may have masked it). Is there anything I should watch for and report ? update: prepping the crow now.. original bug report was based upon this showing same monitor 3 times: $ for p in /sys/class/drm/card0*/edid; do echo; echo $p; echo; monitor-edid $p ; done but those sysfs files are really different $ pwd /sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0/drm/card0 $ sum card0-*/edid 14477 1 card0-DVI-D-1/edid 51583 1 card0-HDMI-A-1/edid 64619 1 card0-VGA-1/edid and my script works as expected with monitor-parse-edid sorry for the noise |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.