Bug 801382 - PCH poison interrupts on output hotplug
PCH poison interrupts on output hotplug
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
6.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Adam Jackson
Desktop QE
: OtherQA, Reopened
Depends On:
Blocks: 842499
  Show dependency treegraph
 
Reported: 2012-03-08 07:11 EST by Levente Farkas
Modified: 2012-10-08 07:39 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-29 09:09:08 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)

  None (edit)
Description Levente Farkas 2012-03-08 07:11:47 EST
we've got a (alots of) new machine with:
- Gigabyte H67A-USB3-B3
- Intel(R) Core(TM) i5-2320 CPU @ 3.00GHz
when we would like to use it in vesa mode it's crash the machine when switch to text mode and back to X (ie. ctrl-alt-f2 then ctrl-alt-f6).

we also be able to reproduce it during install when we choose 
"install system with basic video driver"
and also switch to text mode and back to X (ie. ctrl-alt-f2 then ctrl-alt-f6) it's also crash the installer (i attached the screenshot).

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. but we found we can get it if we configure x to use vesa mode. but in this case if we switch to text mode and back to X than it's crash. so currently we're not able to find any solution to be able to boot and run an rhel-6.2 without monitor and just later plug it and the X working.
Comment 2 Adam Jackson 2012-03-09 15:42:54 EST
(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.
Comment 3 Levente Farkas 2012-03-12 11:37:38 EDT
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 &
Comment 4 Adam Jackson 2012-03-12 13:03:53 EDT
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.
Comment 5 Levente Farkas 2012-03-13 06:42:12 EDT
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
---------------------------------------
Comment 7 Adam Jackson 2012-03-13 21:45:25 EDT
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, ...?
Comment 8 Gergo Csontos 2012-03-14 05:35:50 EDT
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).
Comment 9 Gergo Csontos 2012-03-28 03:34:55 EDT
If I put nomodeset to grub.conf then everything works. I can connect the monitor after X starts.
Comment 10 Levente Farkas 2012-07-06 07:00:56 EDT
it's solved on 6.3.
Comment 11 Tomas Pelka 2012-08-01 04:18:55 EDT
(In reply to comment #10)
> it's solved on 6.3.

Can we closed as CURRENTRELEASE based on c10?
Comment 12 Adam Jackson 2012-08-03 14:49:44 EDT
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@redhat.com>
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@redhat.com>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35103
    Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---

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.
Comment 13 RHEL Product and Program Management 2012-08-03 14:50:39 EDT
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.
Comment 14 Tomas Pelka 2012-08-03 15:58:32 EDT
Since we have no HW for checking this issue I want to ask reporter to check fixed kernel when available.
Comment 15 Levente Farkas 2012-08-03 16:01:37 EDT
but the reporter already checked this and already the 6.3's kernel fix it for me:-)
as i wrote in 10...
Comment 16 Levente Farkas 2012-08-03 16:03:23 EDT
but if you really wanna fix something this #714069 still not fixed since 6.0:-((( even if it's verified by rh...

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