> On Nov 7, 2019, at 10:13 AM, John Donnelly <john.p.donne...@oracle.com> wrote: > > > >> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann <tzimmerm...@suse.de> wrote: >> >> Hi John >> >> Am 07.11.19 um 14:12 schrieb John Donnelly: >>> Hi Thomas ; Thank you for reaching out. >>> >>> See inline: >>> >>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann <tzimmerm...@suse.de> wrote: >>>> >>>> Hi John, >>>> >>>> apparently the vgaarb was not the problem. >>>> >>>> Am 07.11.19 um 03:29 schrieb John Donnelly: >>>>> Hi, >>>>> >>>>> I am investigating an issue where we lose video activity when the display >>>>> is switched from from “text mode” to “graphic mode” >>>>> on a number of servers using this driver. Specifically starting the >>>>> GNOME desktop. >>>> >>>> When you say "text mode", do you mean VGA text mode or the graphical >>>> console that emulates text mode? >>>> >>> >>> >>> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : >>> run-level 3; So I guess your term for it is VGA. >> >> Yes. >> >> >>> >>> >>>> When you enable graphics mode, does it set the correct resolution? A lot >>>> of work went into memory management recently. I could imagine that the >>>> driver sets the correct resolution, but then fails to display the >>>> correct framebuffer. >>> >>> There is no display at all ; so there is no resolution to mention. >>> >>> >>> >>>> >>>> If possible, could you try to update to the latest drm-tip and attach >>>> the output of >>>> >>>> /sys/kernel/debug/dri/0/vram-mm >>> >>> I don’t see that file ; Is there something else I need to do ? >> >> That file is fairly new and maybe it's not in the mainline kernel yet. >> See below for how to get it. > > I built your “tip” ; Still no graphics displayed . > > > mount -t debugfs none /sys/kernel > > cat /proc/cmdline > BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ > root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto > resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root > rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff > > > cat /sys/kernel/dri/0/vram-mm > > In VGA mode : > > > cat /sys/kernel/dri/0/vram-mm > 0x0000000000000000-0x0000000000000300: 768: used > 0x0000000000000300-0x0000000000000600: 768: used > 0x0000000000000600-0x00000000000007ee: 494: free > 0x00000000000007ee-0x00000000000007ef: 1: used > 0x00000000000007ef-0x00000000000007f0: 1: used > > > In GRAPHICS mode ( if it matters ) > > > cat /sys/kernel/dri/0/vram-mm > 0x0000000000000000-0x0000000000000300: 768: used > 0x0000000000000300-0x0000000000000600: 768: used > 0x0000000000000600-0x00000000000007ee: 494: free > 0x00000000000007ee-0x00000000000007ef: 1: used > 0x00000000000007ef-0x00000000000007f0: 1: used > total: 2032, used 1538 free 494 > > > > >> >> >>> >>> I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; >> >> Good! Looking through that log file, the card is found at line 79 and >> the generic X modesetting driver initializes below. That works as expected. >> >> I notices that several operations are not permitted (lines 78 and 87). I >> guess you're starting X from a regular user account? IIRC special >> permission is required to acquire control of the display. What happens >> if you start X as root user? > > > I am starting GNOME as root by doing “init 5” from either the console > session or from ssh . > > The default runlevel is 3 on boot . > > On failing session running your 5.4.0.rc6. > > 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not > permitted) > > 87 [ 237.712] (EE) open /dev/fb0: Permission denied > > Booting 4.18 kernel yields the same error results in: > /var/lib/gdm/.local/share/xorg/Xorg.0.log > > 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not > permitted) > > 87 [ 101.334] (EE) open /dev/fb0: Permission denied > > > What is strange the X logs ( bad and Ok ) files essentially appear as if > GNOME started ! > > > > > <Xorg.0.log.bad><Xorg.0.log.Ok> > > > > > >> >> >>> >>> >>> >>> >>> Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test >>> was 5.3.8 and it failed also ) . >>> >>> # cat /proc/cmdline >>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root >>> ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap >>> rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap >>> console=ttyS0,9600,8,n,1 drm.debug=0xff >>> >>> When you say “tip”. - Are you referring to a specific kernel ? I can >>> build a 5.4.0.rc6 ; The problem appears to have been introduced around >>> 5.3 time frame. >> >> The latest and greatest DRM code is in the drm-tip branch at >> >> git://anongit.freedesktop.org/drm/drm-tip >> >> If you build this version you should find >> >> /sys/kernel/debug/dri/0/vram-mm >> >> on the device. You have to build with debugfs enabled and >> maybe have to mount debugfs at /sys/kernel/debug. >> >> >>> >>> >>>> >>>> before and after switching to graphics mode. The file lists the >>>> allocated regions of the VRAM. >>>> >>>>> >>>>> This adapter is Server Engines Integrated Remote Video Acceleration >>>>> Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. >>>>> >>>>> >>>>> I don’t see any specific errors in the gdm logs or message file other >>>>> than this: >>>> >>>> You can boot with drm.debug=0xff on the kernel command line to enable >>>> more warnings. >>>> >>>> >>>> Could you please attach the output of lspci -v for the VGA adapter? >>>> >>> >>> >>> Here is the output from the current machine; The previous addresses were >>> from another model using the same SE device: >>> >>> >>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: >>> remove_conflicting_pci_framebuffers: bar 0: 0xc5000000 -> 0xc5ffffff >>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: >>> remove_conflicting_pci_framebuffers: bar 1: 0xc6810000 -> 0xc6813fff >>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: >>> remove_conflicting_pci_framebuffers: bar 2: 0xc6000000 -> 0xc67fffff >>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: vgaarb: deactivate >>> vga console >>> >>> >>> lspci -s 3d:00.0 -vvv -k >>> 3d:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA >>> G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if 00 [VGA controller]) >>> Subsystem: Oracle/SUN Device 4852 >>> 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 16 >>> NUMA node: 0 >>> Region 0: Memory at c5000000 (32-bit, non-prefetchable) [size=16M] >>> Region 1: Memory at c6810000 (32-bit, non-prefetchable) [size=16K] >>> Region 2: Memory at c6000000 (32-bit, non-prefetchable) [size=8M] >>> Expansion ROM at 000c0000 [disabled] [size=128K] >>> 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 256 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, Exit >>> Latency L0s <64ns >>> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- >>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- 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 >>> Kernel driver in use: mgag200 >>> Kernel modules: mgag200 >> >> Looks all normal. >> >> Best regards >> Thomas >>
============== Snip =========== Hi Thomas , I hopefully narrowed down the breakage between these up-stream commits, which is v5.2 and 5.3.0-rc1: between : 0ecfebd2b524 2019-07-07 | Linux 5.2 to : 5f9e832c1370 2019-07-21 | Linus 5.3-rc1 I started to bisect this range on by date, by day , based on the changes done in : drivers/gpu/drm/ fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma ; works Hopefully something in drivers/gpu/drm/ between the date range of 2019-07-14 to 2019-07-21 will surface tomorrow. JD. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
