This is with Cisco UCS B-series servers F17 installs and boots fine F18 requires nomodeset boot option for any display to work. Otherwise, the screen blanks and then auto-powers down during the boot process Tested using a network install from Fedora-18-Beta-TC7, so kernel-3.6.5-2.fc18.x86_64.rpm plymouth-0.8.7-1.fc18.x86_64.rpm anaconda 18.24
Created attachment 639139 [details] lspci -vv output lspci -vv output
Does the F17 install boot fine with the latest 3.6.6 kernel from stable updates? If you remove 'rhgb' and 'quiet' from the command line on the F18 install, do you get some sort of oops output? Which graphics driver is in use here? It isn't obvious to me from the lspci output.
(In reply to comment #2) > Which graphics driver is in use here? It isn't obvious to me from the lspci > output. Nevermind on this bit. Somehow I missed the Matrox part in the lspci output. Answers to the other two questions would be appreciated.
3.6.6-1.fc17.x86_64 boots fine on F17 On F18 no oops that I can see or that logs -- monitor or remote display just goes to no-signal-recieved sleep mode during install / boot just after the kernel is loaded and the init process starts running through scripts
OK. In F18 kernels, we have CONFIG_DRM_MGA200=m and that isn't set in F17. So it seems there's a problem with that module and the particular card/machine you have. Dave, should we have this enabled in F18 still?
yes its for f18. Can you boot with nomodeset to run level 3, ssh in and modprobe mgag200 modeset=1? then get the dmesg? also lspci -vvnn
Testing with kernel-3.6.6-3.fc18.x86_64 As soon as I modprobe mgag200 modeset=1 it kills the display signal messages generated are: Nov 16 10:53:14 f18test3 kernel: [ 108.053393] fb: conflicting fb hw usage mgag200drmfb vs VESA VGA - removing generic driver Nov 16 10:53:14 f18test3 kernel: [ 108.056942] Console: switching to colour dummy device 80x25 Nov 16 10:53:14 f18test3 kernel: [ 108.063971] [TTM] Zone kernel: Available graphics memory: 24697696 kiB Nov 16 10:53:14 f18test3 kernel: [ 108.063977] [TTM] Zone dma32: Available graphics memory: 2097152 kiB Nov 16 10:53:14 f18test3 kernel: [ 108.063981] [TTM] Initializing pool allocator Nov 16 10:53:14 f18test3 kernel: [ 108.063987] [TTM] Initializing DMA pool allocator Nov 16 10:53:14 f18test3 kernel: [ 108.087142] fbcon: mgadrmfb (fb0) is primary device Nov 16 10:53:15 f18test3 kernel: [ 108.196693] [drm] mga base 0 Nov 16 10:53:15 f18test3 kernel: [ 108.303725] Console: switching to colour frame buffer device 128x48 Nov 16 10:53:15 f18test3 kernel: [ 108.344194] fb0: mgadrmfb frame buffer device Nov 16 10:53:15 f18test3 kernel: [ 108.344535] drm: registered panic notifier Nov 16 10:53:15 f18test3 kernel: [ 108.344856] [drm] Initialized mgag200 1.0.0 20110418 for 0000:0e:00.0 on minor 0
Created attachment 646431 [details] lspci -vv -nn output
*** Bug 882518 has been marked as a duplicate of this bug. ***
*** Bug 888387 has been marked as a duplicate of this bug. ***
Created attachment 666056 [details] Serial console output up to apparent hang This is a console dump to the point where progress seems to halt. The reason I say, "seems to", is that, if you wait long enough on this platform (HP DL380 Gen8), you will be prompted in text mode to continue in text mode or install via vnc.
Created attachment 666058 [details] Serial console output after hanging for some time After a few minutes, I saw progress on the serial console and was prompted to continue in VNC or remain in text mode. I was able to connect a VNC client to the booting system, but the install hung when I tried to customize partitioning. Can't say if this is a graphics problem or an Anaconda problem.
I can confirm the OP on a number of different Intel servers. S3210SH: ================================== $ lspci -vv | grep MGA -A27 02:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02) (prog-if 00 [VGA controller]) Subsystem: Emulex Corporation Device 0101 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort+ <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at e0000000 (32-bit, prefetchable) [size=16M] Region 1: Memory at e1800000 (32-bit, non-prefetchable) [size=16K] Region 2: Memory at e1000000 (32-bit, non-prefetchable) [size=8M] Expansion ROM at e1810000 [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- Address: 00000000 Data: 0000 S3420GP: ================================== $ lspci -vv | grep MGA -A27 0d:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02) (prog-if 00 [VGA controller]) Subsystem: Intel Corporation Device 0101 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at b0000000 (32-bit, prefetchable) [size=16M] Region 1: Memory at b1800000 (32-bit, non-prefetchable) [size=16K] Region 2: Memory at b1000000 (32-bit, non-prefetchable) [size=8M] Expansion ROM at b1810000 [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Latency L0 <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- Address: 00000000 Data: 0000 Modprobe dmesg: [ 338.896233] checking generic (b0000000 280000) vs hw (b0000000 1000000) [ 338.896238] fb: conflicting fb hw usage mgag200drmfb vs VESA VGA - removing generic driver [ 338.896279] Console: switching to colour dummy device 80x25 [ 338.906149] [TTM] Zone kernel: Available graphics memory: 4068262 kiB [ 338.906152] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 338.906153] [TTM] Initializing pool allocator [ 338.906156] [TTM] Initializing DMA pool allocator [ 338.937681] fbcon: mgadrmfb (fb0) is primary device [ 339.046519] [drm] mga base 0 [ 339.197009] Console: switching to colour frame buffer device 128x48 [ 339.240503] fb0: mgadrmfb frame buffer device [ 339.240505] drm: registered panic notifier [ 339.240559] [drm] Initialized mgag200 1.0.0 20110418 for 0000:0d:00.0 on minor 0 - Gilboa
On HP ProLiant DL180 G6, I get some garbled video with F18, both with kernel-3.6.10-4.fc18.x86_64 and kernel-3.7.9-205.fc18.x86_64, both on a physical VGA connection and on the remote-console/IPMI stuff. Machine functions normally though. Using GRUB_CMDLINE_LINUX+=" mgag200.modeset=0 " in /etc/defaults/grub, I get normal Video 02:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02) (prog-if 00 [VGA controller]) Subsystem: Emulex Corporation Device 0100 Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at f8000000 (32-bit, prefetchable) [size=16M] Memory at fbafc000 (32-bit, non-prefetchable) [size=16K] Memory at fb000000 (32-bit, non-prefetchable) [size=8M] Expansion ROM at fbae0000 [disabled] [size=64K] Capabilities: [dc] Power Management version 2 Capabilities: [e4] Express Legacy Endpoint, MSI 00 Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- Bert.
Haven't seen any movement on this one in a month. Please tell us there has been some progress.
*** Bug 916661 has been marked as a duplicate of this bug. ***
No change with 3.8.1-201.fc18.x86_64.
(In reply to Bert DeKnuydt from comment #14) > > Using > > GRUB_CMDLINE_LINUX+=" mgag200.modeset=0 " > > in /etc/defaults/grub, I get normal Video > I confirm. While updating Fedora 17 to Fedora 18 using Fedup on a HP ML110 G7, I need mgag200.modeset=0 option to have a usable VGA screen, otherwise, the screen is blank and put on standby. BTW, so I don't see how xorg-x11-drv-mga is involved in the Fedup boot target. Regards.
Has anyone tested F19? - Gilboa
(In reply to Yann Droneaud from comment #18) > (In reply to Bert DeKnuydt from comment #14) > > > > Using > > > > GRUB_CMDLINE_LINUX+=" mgag200.modeset=0 " > > > > in /etc/defaults/grub, I get normal Video > > > > I confirm. > > While updating Fedora 17 to Fedora 18 using Fedup on a HP ML110 G7, > I need mgag200.modeset=0 option to have a usable VGA screen, > otherwise, the screen is blank and put on standby. > > BTW, so I don't see how xorg-x11-drv-mga is involved in the Fedup boot > target. > After Fedup upgrade to F18, mgag200.modeset=0 was not required to boot F18. Then Fedup upgrade to F19 was done without any workaround. Perhaps Fedup F18 boot image is missing some update to fix the mga modeset problem. Regards.
Can you post the mga and kernel versions? (rpm -qa | egrep -e 'drv-mga|kernel' | sort)
We upgraded a FC18 install to a FC19 using yum distro sync. After upgrade attempted to boot on a supermicro server mainboard: H8QGI+-F Boot process froze on mgag200 video driver switchover. After adding nomodeset to the grub boot parameters system booted correctly. I hope it helps.
can someone boot with drm.debug=6 and get the dmesg from the dark screen?
oh also Xorg.0.log from a nomodeset run. and hopefully using F19 latest kernel (3.10.9-200.fc19.x86_64).
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 '18'. 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 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 18'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.
nomodeset requirement last seen on kernel version 3.11.1-200.fc19.x86_64 or 3.10.7-200.fc19.x86_64 or 3.10.6-200.fc19.x86_64 Confirmed nomodeset NOT necessary with supermicro server mainboard: H8QGI+-F on kernel version: 3.11.9-200.fc19.x86_64
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.