| Summary: | RRGetScreenInfo possibly takes a long time to complete on i915 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Knut Petersen <Knut_Petersen> | ||||
| Component: | Driver/intel | Assignee: | Eugeni Dodonov <eugeni> | ||||
| Status: | RESOLVED INVALID | QA Contact: | Xorg Project Team <xorg-team> | ||||
| Severity: | normal | ||||||
| Priority: | medium | CC: | przanoni | ||||
| Version: | git | ||||||
| Hardware: | x86 (IA32) | ||||||
| OS: | Linux (All) | ||||||
| Whiteboard: | 2011BRB_Reviewed | ||||||
| i915 platform: | i915 features: | ||||||
| Attachments: |
|
||||||
Comment on attachment 52813 [details]
xorg log with errmsg and backtrace
Please remember to set the correct mime type for attachments.
The mieq code is behaving as intended there. The server dropped 25 events on the floor because the buffer wasn't large enough to hold them. It then resized the buffed to hold more events when it became active again. Over to intel to investigate what was possibly taking so long in handling RRGetScreenInfo Dupe of bug #41059? It has patches floating on intel-gfx@ mailing list. (In reply to comment #3) > Dupe of bug #41059? It has patches floating on intel-gfx@ mailing list. I believe so, once 41059 is resolved it will be useful to see what remains. 915GM has other problems such as requiring long load detection on CRT outputs which is also slow. Bumping to needinfo as the slow EDID read fixes have landed upstream and it is now useful to retest. Timeout. Please do reopen if you can still reproduce the issue and help us diagnose the problem, thanks. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Created attachment 52813 [details] xorg log with errmsg and backtrace Got this problem once, tried to reproduce it but failed. Hardware: i915GM on AOpen i915GMm-hfs motherboard, Pentium M (Dothan) Software: linux kernel 3.1, xorg git 10-26-2011 [...] [ 4758.759] [mi] EQ overflowing. Additional events will be discarded until existing events are processed. [ 4758.759] Backtrace: [ 4758.759] 0: /usr/bin/Xorg (xorg_backtrace+0x2c) [0x81d5b5c] [ 4758.759] 1: /usr/bin/Xorg (mieqEnqueue+0xdb) [0x81b5552] [ 4758.759] 2: /usr/bin/Xorg (0x8048000+0x4bcac) [0x8093cac] [ 4758.759] 3: /usr/bin/Xorg (QueuePointerEvents+0x54) [0x80942be] [ 4758.759] 4: /usr/bin/Xorg (xf86PostMotionEventM+0x190) [0x80cda1a] [ 4758.759] 5: /usr/lib/xorg/modules/input/evdev_drv.so (0xb6ed4000+0x3e37) [0xb6ed7e37] [ 4758.759] 6: /usr/lib/xorg/modules/input/evdev_drv.so (0xb6ed4000+0x41c9) [0xb6ed81c9] [ 4758.759] 7: /usr/lib/xorg/modules/input/evdev_drv.so (0xb6ed4000+0x4350) [0xb6ed8350] [ 4758.759] 8: /usr/lib/xorg/modules/input/evdev_drv.so (0xb6ed4000+0x449a) [0xb6ed849a] [ 4758.760] 9: /usr/bin/Xorg (0x8048000+0x74bda) [0x80bcbda] [ 4758.760] 10: /usr/bin/Xorg (0x8048000+0x998f5) [0x80e18f5] [ 4758.760] 11: (vdso) (__kernel_sigreturn+0x0) [0xb77dd400] [ 4758.760] 12: /usr/lib/libdrm.so.2 (drmModeGetConnector+0x14c) [0xb7064d1a] [ 4758.760] 13: /usr/lib/xorg/modules/drivers/intel_drv.so (0xb6ee2000+0xa908) [0xb6eec908] [ 4758.760] 14: /usr/bin/Xorg (xf86ProbeOutputModes+0xd9) [0x80f4f79] [ 4758.760] 15: /usr/bin/Xorg (0x8048000+0xb9a29) [0x8101a29] [ 4758.760] 16: /usr/bin/Xorg (RRGetInfo+0xd2) [0x8135fb7] [ 4758.760] 17: /usr/bin/Xorg (ProcRRGetScreenInfo+0x9c) [0x813b745] [ 4758.760] 18: /usr/bin/Xorg (0x8048000+0xe9f8b) [0x8131f8b] [ 4758.760] 19: /usr/bin/Xorg (0x8048000+0x2af82) [0x8072f82] [ 4758.760] 20: /usr/bin/Xorg (0x8048000+0x1e46f) [0x806646f] [ 4758.760] 21: /lib/libc.so.6 (__libc_start_main+0xfe) [0xb7105c2e] [ 4758.760] [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack. [ 4758.760] [mi] mieq is *NOT* the cause. It is a victim. [ 4759.107] [mi] Increasing EQ size to 512 to prevent dropped events. [ 4759.107] [mi] EQ processing has resumed after 25 dropped events. [ 4759.107] [mi] This may be caused my a misbehaving driver monopolizing the server's resources. [...] Knut