|Summary:||[855GM bisected] Mouse cursor invisible since kernel 2.6.35|
|Product:||xorg||Reporter:||Oliver Winker <oliverml1>|
|Component:||Driver/intel||Assignee:||Chris Wilson <chris>|
|Status:||RESOLVED FIXED||QA Contact:||Xorg Project Team <xorg-team>|
|Priority:||medium||CC:||arthapex, bonbons, brian, daniel, jbarnes, jd.girard, mk106c-gentoo, paromita52, remi, stenten, vasyl.demin, vvasaitis|
|i915 platform:||i915 features:|
Description Oliver Winker 2010-08-05 13:06:36 UTC
Created attachment 37599 [details] Xorg.0.log Hello, Setup: xserver-xorg-video-intel, version 2.9.1, kms, 852GM/855GM, kernel 2.6.35 With kernel 2.6.35 my mouse cursor became invisible, unfortunately ;). dmesg.txt, Xorg.0.log, xorg.conf are attached Looks similar as: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/613377 Greetings, Oliver
Comment 3 Chris Wilson 2010-08-05 13:53:24 UTC
As you appear to be the sole user who has reported this, can you please bisect the kernel to find the regression. I think it would be safe to limit the bisect to drivers/gpu/drm/i915 which would speed up the process considerably. Stating which kernel you last saw the cursor would help, but I can't offhand think of a commit that is likely to be the culprit, hence the bisection request. Alternatively you could try the 2.12 driver from xorg-edgers which may help you but not identify the regression in the kernel.
Comment 4 Sten Heinze 2010-08-05 15:35:08 UTC
(In reply to comment #3) > As you appear to be the sole user who has reported this, can you please bisect > the kernel to find the regression. I am experiencing this bug too if I switch from 2.6.34[.1] to 2.6.35. I am using same graphics (855gm), but the newer xserver-xorg-video-intel 2.12.0 (version from debian). Bisecting resulted in: 225aa01173b271a3802b716e14176eb7d11dcce4 is the first bad commit Sten
Comment 5 Oliver Winker 2010-08-05 15:54:04 UTC
Hi, I'm just bisecting - but it takes time, and I won't have too much time the next days ;). So do I understand right, that the actual bad commit is found (225aa011) ? Cheers, Oliver
Comment 6 Chris Wilson 2010-08-05 16:20:20 UTC
(In reply to comment #5) > So do I understand right, that the actual bad commit is found (225aa011) ? Yes and no. That commit is actually a merge commit with no code directly modified, so it is peculiar that git pinpointed it as the first bad commit. I asked Sten to try reverting: commit b690e96cf9e6a6cde6f0393de47bdd6317ddb5de Author: Jesse Barnes <email@example.com> Date: Mon Jul 19 13:53:12 2010 -0700 drm/i915: add pipe A force quirks to i915 driver Ported over from the old UMS list. Unfortunately they're still necessary especially on older laptop platforms. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=22126. as being the likely suspect within that merge.
Comment 7 Oliver Winker 2010-08-05 16:34:45 UTC
Yepp, saw that. That's good to know with b690e96c, because that means my bisect went actually in the wrong direction (one commit crashed X and I marked it bad - probably wrongly). Good, I'll also try to revert b690e96c then. Cheers, Ol
Comment 8 Oliver Winker 2010-08-05 17:37:53 UTC
Hi, Reverting b690e96c did it :)! Mouse cursor visible, and everything else looks ok so far as well. Thanks a lot! Oliver
Comment 9 Sten Heinze 2010-08-06 00:02:01 UTC
I can confirm that reverting b690e96c fixes this problem. Sten
Comment 10 Chris Wilson 2010-08-06 00:12:27 UTC
Hmm, what do you think Jesse? Modify the pipea quirk to ensure the pipe is enabled across s&r rather than never disable?
Comment 11 Stenten 2010-08-07 09:10:19 UTC
I found I could get the cursor back by suspending/resuming, but not by locking the screen or switching VT's. So the workaround is the actual suspend/resume cycle. Don't know if that's helpful or not; just thought I'd put it out there.
Comment 12 Chris Wilson 2010-08-07 13:58:18 UTC
Hmm, that's equally curious. Can you grab an intel_reg_dumper before and after suspend & resume? In theory we should be restoring the hardware to an identical state, so it should still be broken...
Comment 13 Stenten 2010-08-08 21:55:15 UTC
Created attachment 37713 [details] intel_reg_dumper_mainline1.txt Mainline (vanilla) 2.6.35 kernel before suspend/resume.
Comment 14 Stenten 2010-08-08 21:56:59 UTC
Created attachment 37714 [details] intel_reg_dumper_mainline2.txt Mainline (vanilla) 2.6.35 kernel after suspend/resume. Diff: 21c21 < D_STATE: 0x0000030f --- > D_STATE: 0x00000000 58c58 < PIPEASTAT: 0x80000000 (status: FIFO_UNDERRUN) --- > PIPEASTAT: 0x00000000 (status:) 94c94 < CURSOR_B_POSITION: 0x017501f5 --- > CURSOR_B_POSITION: 0x02680326
Comment 15 Stenten 2010-08-08 21:58:59 UTC
Created attachment 37715 [details] intel_reg_dumper_ubuntu1.txt Ubuntu 2.6.35-14 (2.6.35) kernel before suspend/resume. Same exact behavior as with the mainline.
Comment 16 Stenten 2010-08-08 22:00:21 UTC
Created attachment 37716 [details] intel_reg_dumper_ubuntu2.txt Ubuntu 2.6.35-14 (2.6.35) kernel after suspend/resume. Same exact behavior as with the mainline. Diff: 21c21 < D_STATE: 0x0000030f --- > D_STATE: 0x00000000 94c94 < CURSOR_B_POSITION: 0x017501f5 --- > CURSOR_B_POSITION: 0x02af038e
Comment 17 Jesse Barnes 2010-08-09 09:23:59 UTC
Many machines also need pipe a enabled at lid close even if no actual suspend occurs (at least I think I remember this...). But just keeping a pipe enabled shouldn't prevent the cursor from being visible unless we have something else wrong with our pipe & cursor plane programming.
Comment 18 Chris Wilson 2010-08-09 11:03:34 UTC
(In reply to comment #16) > Ubuntu 2.6.35-14 (2.6.35) kernel after suspend/resume. Same exact behavior as > with the mainline. Diff: > > 21c21 > < D_STATE: 0x0000030f > --- > > D_STATE: 0x00000000 And here we have another bug... Reading through the docs, 0x30f enables h/w gating on i855 and is setup by BIOS and so we should preserve across s&r, and probably even set those bits ourselves in case the BIOS hasn't enabled the powersaving.
Comment 19 Daniel Vetter 2010-08-10 13:09:33 UTC
Me too (on my Thinkpad X40, i855GM). Random observations: Suspend/Resume gives back the cursor. Reloading the i915 kernel module does not take it away. Rebooting also sometimes leaves the cursor intact. But the really curious thing: Enabling the VGA output fixes the problem, too.
Comment 20 Chris Wilson 2010-08-11 10:12:57 UTC
Daniel, can you check D_STATE after each of those steps? It sounds like the gating should only be enabled if a single pipe is active and we aren't updating that on mode change (but perhaps the BIOS is when VGA is plugged in, etc.).
Comment 21 Chris Wilson 2010-08-12 12:49:40 UTC
Experimenting showed that writing 0x0 to D_STATE did not restore the cursor. s2ram remains the only known workaround.
Comment 22 Daniel Vetter 2010-08-12 13:11:30 UTC
> --- Comment #21 from Chris Wilson <firstname.lastname@example.org> 2010-08-12 12:49:40 PDT --- > Experimenting showed that writing 0x0 to D_STATE did not restore the cursor. > s2ram remains the only known workaround. Could have told you so;) I have D_STATE: 0x0000030f and a working cursor ...
Comment 23 Chris Wilson 2010-08-19 10:14:34 UTC
*** Bug 29673 has been marked as a duplicate of this bug. ***
Comment 24 Chris Wilson 2010-08-20 03:20:27 UTC
Can someone test http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=drm-testing ? I've lost track of just which patches made it into 2.6.35...
Comment 25 Oliver Winker 2010-08-20 12:40:30 UTC
(In reply to comment #24) > Can someone test > http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=drm-testing ? I've lost > track of just which patches made it into 2.6.35... Hi Chris, I tried to build the tree directly, but it fails at the MODPOST step, see below. Also tried to revert 091d6e8 (BROKEN drm: locking.), but didn't build either. Maybe I should take another approach (merging into 2.6.35?) ?! Any hints welcome ;)! -Ol --- CC [M] drivers/gpu/drm/radeon/r600_hdmi.o CC [M] drivers/gpu/drm/radeon/evergreen.o CC [M] drivers/gpu/drm/radeon/evergreen_cs.o CC [M] drivers/gpu/drm/radeon/radeon_acpi.o LD [M] drivers/gpu/drm/radeon/radeon.o Building modules, stage 2. MODPOST 2622 modules ERROR: "drm_get_connector_status_name" [drivers/gpu/drm/drm_kms_helper.ko] undefined! WARNING: modpost: Found 5 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' make: *** [__modpost] Error 1 make: *** [modules] Error 2 make: Leaving directory `/media/OE/Devel/Linux-2.6/ickle-linux-2.6' make: *** [debian/stamp/build/kernel] Error 2 ---
Comment 26 Chris Wilson 2010-08-20 12:51:09 UTC
(In reply to comment #25) > Hi Chris, I tried to build the tree directly, but it fails at the MODPOST step, > see below. > > Also tried to revert 091d6e8 (BROKEN drm: locking.), but didn't build either. Both fixed, however I've already had a report that this is insufficient to fix the missing mouse.
Comment 27 Oliver Winker 2010-08-21 02:40:05 UTC
(In reply to comment #26) > Both fixed, however I've already had a report that this is insufficient to fix > the missing mouse. I could build it now, but on the Inspiron 500m here it is oopsing upon loading of i915: --- Begin: Loading essential drivers ... [ 6.711910] [drm] Initialized drm 1.1.0 20060810 [ 6.779135] i915 0000:00:02.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11 [ 6.793211] [drm] set up 0M of stolen space [ 6.904511] BUG: unable to handle kernel NULL pointer dereference at 00000238 [ 6.908009] IP: [<f88d78a4>] intel_i2c_create+0xa2/0x162 [i915] [ 6.908009] *pdpt = 0000000037751001 *pde = 0000000000000000 [ 6.908009] Oops: 0000 [#1] SMP [ 6.908009] last sysfs file: /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-VGA-1/uevent [ 6.908009] Modules linked in: i915(+) drm_kms_helper i2c_algo_bit drm i2c_core usbhid hid ide_cd_mod ide_gd_mod cdrom ata_generic ata_piix libata scsi_mod uhci_hcd ehci_hcd piix usbcore e100 ide_core video thermal mii button output thermal_sys nls_base [last unloaded: scsi_wait_scan] [ 6.908009] [ 6.908009] Pid: 265, comm: modprobe Not tainted 2.6.36-rc1-drmtest1+ #2 04Y212/Inspiron 500m [ 6.908009] EIP: 0060:[<f88d78a4>] EFLAGS: 00010296 CPU: 0 [ 6.908009] EIP is at intel_i2c_create+0xa2/0x162 [i915] [ 6.908009] EAX: f6c8ade8 EBX: f6c8ac00 ECX: f6cdbd9c EDX: fffffffe [ 6.908009] ESI: f6c8ac0c EDI: 00000000 EBP: f6caf3c0 ESP: f6cdbd90 [ 6.908009] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 6.908009] Process modprobe (pid: 265, ti=f6cda000 task=f6e6ed60 task.ti=f6cda000) [ 6.908009] Stack: [ 6.908009] f6c8ad8c 00000014 f88e8dd5 f88e9074 00000400 0000501c f88e9074 f6caf3c0 [ 6.908009] <0> 00000000 f6eba000 00000002 f88d938c f6c8a800 f6c8a000 f774b800 f6eba000 [ 6.908009] <0> f88d0a93 f774b800 00000000 f6eba000 00000002 f88d0070 00000246 f6eba000 [ 6.908009] Call Trace: [ 6.908009] [<f88d938c>] ? intel_dvo_init+0x48/0x260 [i915] [ 6.908009] [<f88d0a93>] ? intel_crt_init+0x10c/0x139 [i915] [ 6.908009] [<f88d0070>] ? intel_modeset_init+0x87b/0xa0b [i915] [ 6.908009] [<c11bf742>] ? vga_client_register+0x57/0x5e [ 6.908009] [<f88bad8e>] ? i915_driver_load+0xf5f/0x10a2 [i915] [ 6.908009] [<f880ecb1>] ? drm_get_pci_dev+0x158/0x22a [drm] [ 6.908009] [<c1150322>] ? local_pci_probe+0x34/0x74 [ 6.908009] [<c1150d25>] ? pci_device_probe+0x41/0x63 [ 6.908009] [<c11c95e4>] ? driver_probe_device+0x8c/0x110 [ 6.908009] [<c11c96a8>] ? __driver_attach+0x40/0x5b [ 6.908009] [<c11c8e45>] ? bus_for_each_dev+0x37/0x5f [ 6.908009] [<c11c949a>] ? driver_attach+0x11/0x13 [ 6.908009] [<c11c9668>] ? __driver_attach+0x0/0x5b [ 6.908009] [<c11c91c0>] ? bus_add_driver+0x87/0x1bb [ 6.908009] [<c113e0e0>] ? kset_find_obj+0x20/0x4a [ 6.908009] [<f88f9000>] ? i915_init+0x0/0x85 [i915] [ 6.908009] [<c11c98c4>] ? driver_register+0x7a/0xd9 [ 6.908009] [<f88f9000>] ? i915_init+0x0/0x85 [i915] [ 6.908009] [<c1150ef0>] ? __pci_register_driver+0x33/0x89 [ 6.908009] [<f88f9000>] ? i915_init+0x0/0x85 [i915] [ 6.908009] [<c1003069>] ? do_one_initcall+0x68/0x10f [ 6.908009] [<c105d537>] ? sys_init_module+0xc6c/0xdfd [ 6.908009] [<c128a454>] ? syscall_call+0x7/0xb [ 6.908009] Code: 04 89 43 08 8d 83 8c 01 00 00 ff 74 24 08 68 d5 8d 8e f8 6a 14 50 e8 4a b7 86 c8 8d 83 e8 01 00 00 c7 43 0c 28 cc 8e f8 89 43 1c <8b> 87 38 02 00 00 c7 83 ec 01 00 00 c5 76 8d f8 c7 83 f0 01 00 [ 6.908009] EIP: [<f88d78a4>] intel_i2c_create+0xa2/0x162 [i915] SS:ESP 0068:f6cdbd90 [ 6.908009] CR2: 0000000000000238 [ 7.188563] ---[ end trace 911418240e288a3a ]--- Killed ---
Comment 28 Chris Wilson 2010-08-21 02:47:38 UTC
On Sat, 21 Aug 2010 02:40:07 -0700 (PDT), email@example.com wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=29413 > > --- Comment #27 from Oliver Winker <firstname.lastname@example.org> 2010-08-21 02:40:05 PDT --- > (In reply to comment #26) > > Both fixed, however I've already had a report that this is insufficient to fix > > the missing mouse. > > I could build it now, but on the Inspiron 500m here it is oopsing upon loading > of i915: You caught the tree at a bad time. I'm having lots of fun trying to break the drm locking down into manageable chunks to avoid the stalls caused by hotplug polling. Hopefully, I've it back into a working state shortly.
Comment 29 Rémi Cardona 2010-08-26 06:56:33 UTC
Confirming the bug on my very own 855GM and patently awaiting the go-ahead from Chris to pull his tree. Cheers
Comment 30 Brian Rogers 2010-09-10 19:06:19 UTC
Rémi, I'll bet the branch is ready for testing by now.
Comment 31 Chris Wilson 2010-09-12 10:28:23 UTC
Does this magic patch do anything: http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git;a=commit;h=532db7fe1fd75f20f3abf959419d160fb7850aff (in git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git drm-intel-staging)
Comment 32 Daniel Vetter 2010-09-12 12:20:26 UTC
> --- Comment #31 from Chris Wilson <email@example.com> 2010-09-12 10:28:23 PDT --- > Does this magic patch do anything: > > http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git;a=commit;h=532db7fe1fd75f20f3abf959419d160fb7850aff This brings back my cursor on my i855, even after a cold boot (tried mutliple times). Tested-by: Daniel Vetter <firstname.lastname@example.org>
Comment 33 Chris Wilson 2010-09-12 12:41:50 UTC
Patch promoted to drm-intel-fixes, thanks!
Comment 34 arthapex 2010-09-13 00:55:22 UTC
(In reply to comment #32) > > --- Comment #31 from Chris Wilson <email@example.com> 2010-09-12 10:28:23 PDT --- > > Does this magic patch do anything: > > > > http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git;a=commit;h=532db7fe1fd75f20f3abf959419d160fb7850aff > > This brings back my cursor on my i855, even after a cold boot (tried > mutliple times). > > Tested-by: Daniel Vetter <firstname.lastname@example.org> same here. Thanks
Comment 35 Jean-Denis Girard 2010-09-20 10:35:30 UTC
(In reply to comment #34) > (In reply to comment #32) > > > --- Comment #31 from Chris Wilson <email@example.com> 2010-09-12 10:28:23 PDT --- > > > Does this magic patch do anything: > > > > > > http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git;a=commit;h=532db7fe1fd75f20f3abf959419d160fb7850aff > > > > This brings back my cursor on my i855, even after a cold boot (tried > > mutliple times). > > > > Tested-by: Daniel Vetter <firstname.lastname@example.org> > > same here. Thanks Works here too. Doesn't seem to be included in 184.108.40.206-rc1, though.