Bug 499751 - Supermicro X7DWT loses KVM output unless booted with nomodeset
Supermicro X7DWT loses KVM output unless booted with nomodeset
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
17
All Linux
low Severity medium
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-07 18:42 EDT by Jason Tibbitts
Modified: 2013-08-01 14:22 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-01 14:22:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
BIOS ROM dump (44.00 KB, application/octet-stream)
2012-02-22 15:51 EST, Jason Tibbitts
no flags Details
ROM from machine without the issue (44.00 KB, application/octet-stream)
2012-02-22 15:55 EST, Jason Tibbitts
no flags Details

  None (edit)
Description Jason Tibbitts 2009-05-07 18:42:30 EDT
This is an odd one.  I have several Supermicro 6015T systems which each have two X7DWT motherboards and added Supermicro SIMSO+ management controllers which provide KVM over IP.  The graphics chip in the motherboard is an ATI ES1000; the chip in the management controller is a Raritan Kira.  The machines do have a standard VGA port but there is no connected monitor.  I assume there is some bizarre internal routing

09:01.0 VGA compatible controller [0300]: ATI Technologies Inc ES1000 [1002:515e] (rev 02)

Attempting to boot rawhide will result in the management controller displaying "No Signal" unless I boot with nomodeset.  I can log into the booted system and pull the kernel logs; here's everything from the first message that seems relevant.  I don't really know how you can do a reasonable EDID in this situation; I guess a quirk might help.

[drm] Initialized drm 1.1.0 20060810
generic-usb 0003:14DD:0002.0002: input,hidraw1: USB HID v1.01 Keyboard [Peppercon AG Multidevice] on usb-0000:00:1d.7-6/input2
radeon 0000:09:01.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[drm] Detected VRAM RAM=16384K, accessible=16384K, BAR=131072K
mtrr: type mismatch for d0000000,4000000 old: write-back new: write-combining
[drm] External TMDS Table revision: 2
i2c-adapter i2c-0: unable to read EDID block.
radeon 0000:09:01.0: VGA-1: no EDID data
[drm:edid_is_valid] *ERROR* Raw EDID:
<3>ff ff ff ff ff ff 00 42 03 01 00 02 00 00 00 01  .......B........
<3>0f 01 03 80 22 1b ff 0a 00 00 00 00 00 00 00 00  ...."...........
<3>00 00 bf ee 07 61 4f 01 01 01 01 01 01 01 01 01  .....aO.........
<3>01 01 01 01 01 30 2a 00 98 51 00 2a 40 30 70 13  .....0*..Q.*@0p.
<3>00 78 2d 11 00 00 00 52 62 80 a0 20 5e 63 10 10  .x-....Rb.. ^c..
<3>60 52 08 78 2d 11 00 00 00 00 00 00 fd 00 38 4c  `R.x-.........8L
<3>1f 53 0f 00 00 00 00 00 00 00 00 00 00 00 fc 00  .S..............
<3>4b 49 52 41 0a 20 20 20 20 20 20 00 00 00 28 ff  KIRA.      ...(.

radeon 0000:09:01.0: DVI-I-1: EDID invalid.
i2c-adapter i2c-0: unable to read EDID block.
radeon 0000:09:01.0: VGA-1: no EDID data
[drm:edid_is_valid] *ERROR* Raw EDID:
<3>ff ff ff ff ff ff 00 42 03 01 00 02 00 00 00 01  .......B........
<3>0f 01 03 80 22 1b ff 0a 00 00 00 00 00 00 00 00  ...."...........
<3>00 00 bf ee 07 61 4f 01 01 01 01 01 01 01 01 01  .....aO.........
<3>01 01 01 01 01 30 2a 00 98 51 00 2a 40 30 70 13  .....0*..Q.*@0p.
<3>00 78 2d 11 00 00 00 52 62 80 a0 20 5e 63 10 10  .x-....Rb.. ^c..
<3>60 52 08 78 2d 11 00 00 00 00 00 00 fd 00 38 4c  `R.x-.........8L
<3>1f 53 0f 00 00 00 00 00 00 00 00 00 00 00 fc 00  .S..............
<3>4b 49 52 41 0a 20 20 20 20 20 20 00 00 00 28 ff  KIRA.      ...(.

radeon 0000:09:01.0: DVI-I-1: EDID invalid.
[drm:drm_helper_initial_config] *ERROR* connectors have no modes, using standard modes
allocated ffff88042b86d000 800x600 fb: 0x00040000, bo ffff88042ad07600
Console: switching to colour frame buffer device 100x37
[drm] DAC-5: set mode 800x600 a
[drm] TV-7: set mode 800x600 b
fb0: radeondrmfb frame buffer device
registered panic notifier
[drm] Loading R100 Microcode
[drm] writeback test succeeded in 2 usecs
[drm] Initialized radeon 1.29.0 20080528 for 0000:09:01.0 on minor 0
Comment 1 Chuck Ebbert 2009-05-07 20:22:28 EDT
The EDID data should start with:

  { 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00 }

Looks like yours is missing the leading 0x00. The first line is:

  ff ff ff ff ff ff 00 42 03 01 00 02 00 00 00 01
Comment 2 Bug Zapper 2009-06-09 11:25:09 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Bug Zapper 2010-04-27 10:12:42 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Bug Zapper 2010-06-28 08:26:22 EDT
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 5 Jason Tibbitts 2012-02-22 15:50:47 EST
airlied asked me to reopen this and attach a BIOS ROM from the card in question.  Unfortunately testing anything on this machine is extremely difficult as users run jobs essentially forever; I can't get in edgewise to update to F16 so I only know this was required for whatever kernel was on the F15 installation media.  Adding one line at boot once a year isn't too much trouble so I let the bug drop.

But the BIOS ROM will follow.
Comment 6 Jason Tibbitts 2012-02-22 15:51:32 EST
Created attachment 565100 [details]
BIOS ROM dump
Comment 7 Jason Tibbitts 2012-02-22 15:55:12 EST
And, for fun, since I know how to do it, I have other machines with nearly identical hardware which do not have this problem so I dumped one of those ROMs as well.  It's a different version:

Bad ROM:
(C) 1988-2002, ATI Technologies Inc. BK-ATI VER008.005.007.001

Good ROM:
(C) 1988-2002, ATI Technologies Inc. BK-ATI VER008.005.030.000

The good one is attached as well.
Comment 8 Jason Tibbitts 2012-02-22 15:55:51 EST
Created attachment 565102 [details]
ROM from machine without the issue
Comment 9 Jason Tibbitts 2012-07-14 12:49:19 EDT
Just wanted to note that I finally had a chance to do maintenance on the machine in question and the current F17 kernel (3.4.4-3.fc17) still has this issue.

I don't know of any way to update the video BIOS, and I'm not sure if there's any way to automatically disable modesetting based on something as fine-grained as the video BIOS version.  But what I really don't get is why the kernel goes ahead with the modesetting operation when faced with the bogus EDID.
Comment 10 Fedora End Of Life 2013-07-04 02:44:38 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 11 Fedora End Of Life 2013-08-01 14:22:53 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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