Bug 801382

(In reply to comment #0)
> our real main problem is that we're not able to use the default (ie intel xorg
> driver) when we like to boot the machine WITHOUT monitor and and just plug the
> monitor later. in this case we're not able to get the graphical screen.

Why not?  What happens if you try?  X _should_ start without a monitor attached, and hotplug interrupts should take care of resizing the display when things get plugged in (though tbf I don't know if gdm completely handles that).

ssh into the headless machine and see what happens when you plug in.  If you're using gdm, then as root you should be able to set $XAUTHORITY to whatever path gdm passes to Xorg on the command line and run 'xrandr' to query output state.  I suspect that doing that will actually trigger the display to reconfigure and magically light up.

we don't use gdm. we'd like to run a simple X and our application. and yes we try: when we use gdm and only plug the monitor later than it's working. but if we only start X then it's not recognize the monitor later (even if our application running and it's working, but we can't see the X). we start X in this way:
/usr/bin/X "vt08" -v -s 0 ":1" -noreset -keeptty &

Well then it sounds like your "simple X" environment is too simple.

You could probably work around this by doing something lame in your session like:

$ xev -root | grep ConfigureNotify | while read line ; do
> xrandr --auto
> done

Which would listen for hotplug events and automatically reconfigure the screen.  I'm not entirely sure why you're not able to see X when you plug the monitor in; maybe your monitor doesn't know how to handle the default 1024x768? Or that it's setting up the default mode on a connector other than the one you're plugging into?

But whatever, you've asked for a broken environment so I guess you got what you asked for.

If you can provide details from the crash from using vesa I guess we can look into that further, but it really sounds like this is mostly a configuration issue with your X session.

it seems that the problem is motherboard dependent both intel and vesa bug happened with the same motherboards.

these are the wrong motherboards:
MSI H67MA-E35 (MS-7680)
GIGABYTE H67A-D3H-B3
GIGABYTE H67A-USB3-B3
and this's the only good one (at least for us):
GIGABYTE H67MA-USB3-B3

your command xev... doesn't give any output ie we don't get any kind of ConfigureNotify when we plug the monitor. we do these steps:
- starting the machine with X (:1), and without monitor
- ssh to this machine
- export DISPLAY=:1
- xev -root
gives this output:
---------------------------------------
Outer window is 0x200001, inner window is 0x200002

PropertyNotify event, serial 8, synthetic NO, window 0x200001,
    atom 0x27 (WM_NAME), time 101763, state PropertyNewValue

PropertyNotify event, serial 9, synthetic NO, window 0x200001,
    atom 0x22 (WM_COMMAND), time 101763, state PropertyNewValue

PropertyNotify event, serial 10, synthetic NO, window 0x200001,
    atom 0x28 (WM_NORMAL_HINTS), time 101763, state PropertyNewValue

CreateNotify event, serial 11, synthetic NO, window 0x200001,
    parent 0x200001, window 0x200002, (10,10), width 50, height 50
border_width 4, override NO

PropertyNotify event, serial 14, synthetic NO, window 0x200001,
    atom 0x106 (WM_PROTOCOLS), time 101763, state PropertyNewValue

MapNotify event, serial 15, synthetic NO, window 0x200001,
    event 0x200001, window 0x200002, override NO

MapNotify event, serial 16, synthetic NO, window 0x200001,
    event 0x200001, window 0x200001, override NO

VisibilityNotify event, serial 16, synthetic NO, window 0x200001,
    state VisibilityUnobscured

Expose event, serial 16, synthetic NO, window 0x200001,
    (0,0), width 178, height 10, count 3

Expose event, serial 16, synthetic NO, window 0x200001,
    (0,10), width 10, height 58, count 2

Expose event, serial 16, synthetic NO, window 0x200001,
    (68,10), width 110, height 58, count 1

Expose event, serial 16, synthetic NO, window 0x200001,
    (0,68), width 178, height 110, count 0
---------------------------------------
and this doesn't give anything more when we plug the monitor.

the only thing we got in messages with the wrong motherboards (but not with the good one) when we plug the monitor:
---------------------------------------
Mar 13 10:26:09 msi kernel: [drm:pch_irq_handler] *ERROR* PCH poison interrupt
---------------------------------------

may be it's the same bug as:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/795407
https://bugzilla.redhat.com/show_bug.cgi?id=748736

Well, it's related (in that the "poison interrupts" shouldn't happen), but it's probably not the same thing.

Reopening and fixing summary to reflect the real bug.

What kind of connector are you trying to plug into?  VGA, DVI, ...?

We get the "PCH poison interrupt" message just when we connect to the VGA port. But the main problem is the same on DVI as well. The monitor shows a not blinking cursor in the top left corner. I can switch to any text console (ctrl+alt+f2) and it works fine until switching back to X (ctrl+alt+f8 because we started X on DISPLAY :1). Then the signal is lost on every console and the monitor goes to standby. X restart solves this and everything works fine (ctrl+alt+f2 and f8 as well).

If I put nomodeset to grub.conf then everything works. I can connect the monitor after X starts.

it's solved on 6.3.

(In reply to comment #10)
> it's solved on 6.3.

Can we closed as CURRENTRELEASE based on c10?

No.  I know of at least the following patch - which is not present in 6.3 - that would fix this message:

---
commit 23e81d691a813839020f6e516b398d0f9369fe8b
Author: Adam Jackson <ajax>
Date:   Wed Jun 6 15:45:44 2012 -0400

    drm/i915: pch_irq_handler -> {ibx, cpt}_irq_handler
    
    Cougar/Panther Point redefine the bits in SDEIIR pretty completely.
    This function is just debugging, but if we're debugging we probably want
    to be told accurate things instead of lies.
    
    I'm told Lynx Point changes this yet more, but I have no idea how...
    
    Note from Eugeni's review:
    
    "For the record and for future enabling efforts, for LPT, bits 28-31
    and 1-14 are gone since CPT/PPT (e.g., those must be zero). And there
    is the bit 15 as a new addition, but we are not using it yet and
    probably won't be using in foreseeable future."
    
    Signed-off-by: Adam Jackson <ajax>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35103
    Reviewed-by: Eugeni Dodonov <eugeni.dodonov>
    Signed-off-by: Daniel Vetter <daniel.vetter>
---

The message is harmless in this case, but we should fix it anyway.  The above patch should already be included by the drm rebase in 6.4.

This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.

Since we have no HW for checking this issue I want to ask reporter to check fixed kernel when available.

but the reporter already checked this and already the 6.3's kernel fix it for me:-)
as i wrote in 10...

but if you really wanna fix something this #714069 still not fixed since 6.0:-((( even if it's verified by rh...