|
Description
Mateusz Kaduk
2009-03-26 16:42:37 UTC
More tests on my GM965: Booting pci=nomsi i915.modeset=1 $ grep i915 /proc/interrupts 16: 6639 6520 IO-APIC-fasteoi i915, ahci, uhci_hcd:usb5, yenta Moving or switching windows is slow and not acceptable, running glxgears shows framerates from 32 to below 3 and you need luck to kill it. Then its again possible to write anything. Booting i915.modeset=1 $ grep i915 /proc/interrupts 29: 0 0 PCI-MSI-edge i915 Things are not rendered until mouse is moved. Booting with kms disabled by default $ grep i915 /proc/interrupts 29: 5853 5411 PCI-MSI-edge i915@pci:0000:00:02.0 Everything works There is something different on KMS and UMS pathways that cause the problem. Created attachment 24794 [details]
This includes config.gz for kernel 2.6.30-rc1-vanilla with two patches from mailing list that I used.
I have similar problems. sometimes the keyboard hangs while typing. if i move the mouse, it goes on. with activ compositing it happen very very often! atm i try intel 2.7.0-3. kernel 2.6.29.1-4 on arch linux. Inte 945GC (thats what lspci said. foxconn mainboard 945CSX mini itx with intel atom 330). no kms zcat /proc/config.gz | grep MSI CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y CONFIG_MSI_LAPTOP=m anymore details? Same problem here. Screen doesn't get updated until I either move the mouse or press a key. System: Dell Latitude D630 Chip: GM965 Platform: AMD64/ Kernel: Current kernel git + pull from dri-intel OS: Debian Stable/Unstable Xorg: 7.4 Intel: 2.7.0 hm... if your typing also hangs sometimes, maybe it is an kms unrelated _regression_ in the kernel and kms just is most affected? if so, you could file a bug at the kernel bugzilla and have it listed as a regression, which gives this issue more publicity, and maybe someone involved with interrupts has some suggestions.... but of course first try with rc3-git6 as andreas on the xorg@ suggested... Hi Florian, well, running the same kernel without KMS works fine, so I wouldn't call it a regression (at least for non-KMS users). Also typing doesn't hang, it's just that when the screen freezes, I can cause a repaint either with an mouse or keyboard event. I also tried current git as you suggested (plus the patches from drm-intel git tree): no change, unfortunately. (In reply to comment #7) > Hi Florian, > > well, running the same kernel without KMS works fine, so I wouldn't call it a > regression (at least for non-KMS users). Also typing doesn't hang, it's just > that when the screen freezes, I can cause a repaint either with an mouse or > keyboard event. > > I also tried current git as you suggested (plus the patches from drm-intel git > tree): no change, unfortunately. > There are no gpu related changes between git5 and git6. So it should not change anything. Also patches from drm-intel are already in git5. I tested with git5 and still enabling KMS cause this problem. IMHO it is regression since some code has been introduce that cause bug. I am really looking forward if someone will fix it. *** Bug 21155 has been marked as a duplicate of this bug. *** Some questions here:
1) does this happen even if you're running something with animation? (e.g.
glxgears, some animated web page)
2) do you see graphics interrupts happening (grep i915 /proc/interrupts) during
that time? you'd probably have to ssh in to confirm that so as not to
perturb the display.
If the answer to both is yes, it may be that our block handler isn't running or somehow we're not flushing front buffer rendering to the screen in a timely way...
If the answer to (1) is yes but (2) is no (as is the case in some of the reports here) it may be that we're not enabling user interrupts but are completing rendering and flushing it eventually through the server...
(In reply to comment #10) > Some questions here: > 1) does this happen even if you're running something with animation? (e.g. > glxgears, some animated web page) > 2) do you see graphics interrupts happening (grep i915 /proc/interrupts) > during > that time? you'd probably have to ssh in to confirm that so as not to > perturb the display. > > If the answer to both is yes, it may be that our block handler isn't running or > somehow we're not flushing front buffer rendering to the screen in a timely > way... > > If the answer to (1) is yes but (2) is no (as is the case in some of the > reports here) it may be that we're not enabling user interrupts but are > completing rendering and flushing it eventually through the server... > 1) Yes Mouse cursor animation seems not to be affected at all. It animates 5-6s then stops on last animation. But glxgears works only if I keep moving mouse or pressing something on keyboard. Fps are higher when I move mouse more frequently. Writing this comment is possible though. To see animation I also tired playing music in totem. Moving mouse is needed, rendering stops faster then music which lasts 5-6s probably sound buffer and again mouse movement is needed to hear something. So not only rendering is affected. Test with youtube, I can watch movie for 4-5s then I hear only sound 2s more then no sound and static picture till I move mouse or press key again. 2) No After running glxgears and moving mouse to make it animated $ cat /proc/interrupts CPU0 CPU1 0: 110339 110515 IO-APIC-edge timer 1: 1678 1644 IO-APIC-edge i8042 8: 1 0 IO-APIC-edge rtc0 9: 837 845 IO-APIC-fasteoi acpi 12: 3946 3900 IO-APIC-edge i8042 14: 3427 3615 IO-APIC-edge ide0 16: 6047 6274 IO-APIC-fasteoi uhci_hcd:usb5, yenta 17: 19027 18417 IO-APIC-fasteoi uhci_hcd:usb6, HDA Intel 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb7, mmc0 19: 2 0 IO-APIC-fasteoi ehci_hcd:usb2 20: 28 30 IO-APIC-fasteoi uhci_hcd:usb3 21: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 22: 2 1 IO-APIC-fasteoi ehci_hcd:usb1 29: 0 0 PCI-MSI-edge i915 30: 6170 6187 PCI-MSI-edge ahci 31: 187 198 PCI-MSI-edge eth2 32: 5554 5486 PCI-MSI-edge iwlagn NMI: 0 0 Non-maskable interrupts LOC: 76740 98836 Local timer interrupts SPU: 0 0 Spurious interrupts RES: 21083 21734 Rescheduling interrupts CAL: 45 71 Function call interrupts TLB: 118 251 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts ERR: 0 MIS: 0 dmesg does not show anything special except [drm:drm_wait_vblank] *ERROR* failed to acquire vblank counter, -22 Xorg.0.log is also fine. Switching windows is slow badly and sometimes needs moving mouse or pressing keyboard key. Switching to VT and back is possible. Created attachment 25445 [details] [review] set proper clock gating & render clock bits We need to do this in KMS mode anyway; hope it helps with this problem. Comment on attachment 25445 [details] [review] set proper clock gating & render clock bits Does not fix this. Created attachment 25490 [details]
Intel regs dumps from ums & kms
Two files contain output from intel_reg_dumper for both cases (kms/ums).
Upping severity. Created attachment 25495 [details]
Xorg.0.log in failing kms case.
Created attachment 25496 [details]
dmesg in failing kms case.
Created attachment 25499 [details]
Regump with 2.6.30-rc3-git5 with jbarnes patch for RENCLK differences on kms faling case.
Found a smoking gun: Running "vbetool vbestate save" during boot induces the bug. Disabling this (which probably is unnecessary anyway?) fixes the problem. Created attachment 25512 [details]
DEBUGFS: Content of /sys/kernel/debug/dri/0/ with kms failing case.
Created attachment 25513 [details]
DEBUGFS: Content of /sys/kernel/debug/dri/0/ with ums working case.
Dariush, that's interesting. I'm starting to wonder if PCI state might have changed somehow. Can you check your /sys/devices/pci0000:00/0000:00:02.0/ PCI files for changes before and after vbetool runs? I wonder if config space changes somehow (maybe bus mastering or some other feature gets turned off)... resource0 from before & after might also be interesting to diff... Created attachment 25518 [details] [review] more debug info Ok in the KMS case your IER is reading back as 0, which indicates a problem. This patch adds some more debug info, please try it out. Created attachment 25519 [details] [review] remove INSTPM setting No idea why this was here, but it could cause problems. Created attachment 25520 [details]
dmesg with more debug info patch
Hi Jesse, nope, nothing changes as far as I can tell. I wasn't able to open resource0 though (I/O-Error). Do I have to employ some magic to access it? This is the output of "lspci -vvvxxxx", before & after (no difference) 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA controller]) Subsystem: Dell Latitude D630 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 Interrupt: pin A routed to IRQ 27 Region 0: Memory at f6e00000 (64-bit, non-prefetchable) [size=1M] Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at eff8 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Mask- 64bit- Count=1/1 Enable+ Address: fee0300c Data: 4179 Capabilities: [d0] Power Management version 3 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Bridge: PM- B3+ Kernel driver in use: i915 00: 86 80 02 2a 07 04 90 00 0c 00 00 03 00 00 80 00 10: 04 00 e0 f6 00 00 00 00 0c 00 00 e0 00 00 00 00 20: f9 ef 00 00 00 00 00 00 00 00 00 00 28 10 f9 01 30: 00 00 00 00 90 00 00 00 00 00 00 00 0b 01 00 00 40: 00 00 00 00 48 00 00 00 09 00 0a 91 2c 64 00 30 50: 04 00 30 00 19 00 00 00 00 00 00 00 00 00 80 7f 60: 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 05 d0 01 00 0c 30 e0 fe 79 41 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 01 01 01 01 00 00 00 00 4d 01 00 00 d0: 01 00 23 00 00 00 01 01 01 01 00 94 34 00 00 00 e0: 00 00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 f0: 05 02 34 07 ff 00 00 00 90 0f 04 00 00 c8 66 7f Created attachment 25525 [details] [review] workaround IER clearing in EnterVT Check if IER was cleared at EnterVT time. If so, re-enable interrupts so that things work. Created attachment 25526 [details] [review] Check IER in wait_request The 2D driver doesn't call EnterVT in KMS mode, so we have to do the check somewhere else. This makes the kernel check at wait_request time instead. Created attachment 25527 [details] [review] fix build Oops this one actually builds. Ah, just wanted to write that "workaround IER clearing in EnterVT" doesn't fix the problem. :) It's 1 am, will try the other patch tommorrow. Have a nice day and thanks for your help! Dariush Ok, sent out the workaround. But this is really a distro config/BIOS issue so I'm marking NOTOURBUG. Hi Jesse, yes, the workaround does fix the issue. [ 61.162844] [drm:i915_wait_request] *ERROR* something (likely vbetool) disabled interrupts, re-enabling I've filed a bugreport at Debian to not start vbetool when KMS is active. Thanks again for your help! Dariush |
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.