Bug 506904 - Touchpad breaks after suspend
Touchpad breaks after suspend
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-19 04:31 EDT by Phip
Modified: 2010-12-05 01:50 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-05 01:50:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Excerpts from Xorg.0.log (2.29 KB, text/plain)
2009-06-19 05:14 EDT, Phip
no flags Details

  None (edit)
Description Phip 2009-06-19 04:31:14 EDT
Description of problem:
The touchpad on my Gateway MX6441 Notebook stops working, clicks or movement, upon waking from suspend. 

Version-Release number of selected component (if applicable):
1.1.0-7.fc11

How reproducible:
Always

Additional info:

dmesg says:
Synaptics Touchpad, model: 1, fw: 5.9, id: 0x23aeb3, caps: 0xa04713/0x10008

I have a newer laptop that is not affected by this issue, its dmesg says:
Synaptics Touchpad, model: 1, fw: 6.2, id: 0x180b1, caps: 0xa04713/0x200000
Comment 1 Phip 2009-06-19 05:14:24 EDT
Created attachment 348624 [details]
Excerpts from Xorg.0.log

The first block is the log section where X11 loads the touchpad initially.
The second block are the messages that appear on resume.
Comment 2 Peter Hutterer 2009-06-21 22:30:18 EDT
from the log:
(II) config/hal: removing device SynPS/2 Synaptics TouchPad
(II) UnloadModule: "synaptics"

this looks like the device got removed (by the kernel) after resume - for whatever reason. If you run lshal after this happens, does the touchpad show up? is it still listed in /proc/bus/input/devices?
Comment 3 Phip 2009-06-21 23:52:26 EDT
The following entry disappeared from /proc/bus/input/devices:

I: Bus=0011 Vendor=0002 Product=0007 Version=23b3
N: Name="SynPS/2 Synaptics TouchPad"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input7
U: Uniq=
H: Handlers=mouse2 event7 
B: EV=b
B: KEY=6420 0 70000 0 0 0 0 0 0 0 0
B: ABS=11000003

And This entry disappeared from lshal's output:

udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input'
  info.capabilities = {'input', 'input.touchpad'} (string list)
  info.category = 'input'  (string)
  info.parent = '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port'  (string)
  info.product = 'SynPS/2 Synaptics TouchPad'  (string)
  info.subsystem = 'input'  (string)
  info.udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input'  (string)
  input.device = '/dev/input/event7'  (string)
  input.originating_device = '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port'  (string)
  input.product = 'SynPS/2 Synaptics TouchPad'  (string)
  input.x11_driver = 'synaptics'  (string)
  linux.device_file = '/dev/input/event7'  (string)
  linux.hotplug_type = 2  (0x2)  (int)
  linux.subsystem = 'input'  (string)
  linux.sysfs_path = '/sys/devices/platform/i8042/serio1/input/input7/event7'  (string)
Comment 4 Peter Hutterer 2009-06-22 00:08:56 EDT
I have to punt this to the kernel then, if the device disappears there isn't much we can do in the X driver.
Comment 5 Phip 2009-09-06 18:47:10 EDT
I am still having this problem after updating to kernel 2.6.30.5-43.
Comment 6 Phip 2009-12-01 23:00:57 EST
Changing Version from 11 to 12.
After updating to kernel 2.6.31.6-145 in Fedora 12, I am still experiencing this problem with my touchpad not working on resume. If there is any way I can gather useful data about this, I will be happy to do so.
Comment 7 Jim Cromie 2010-01-29 15:37:45 EST
on my sony-laptop, after resume/wakeup, the pointer moves, but buttons
do not, so I cannot select a window.  

Typing also doesnt work (I dont recall whether any window is selected)

Like OP, Ive had this problem for *many* months, 
its not just the latest kernel giving me trouble.

I havent tried ssh-ing in yet.
I dont recall whether the desktop clock is running when it wakes up.

in my dmesg:
input: PS/2 Mouse as /devices/platform/i8042/serio1/input/input4
input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input5

in lsmod:
[jimc@harpo ~]$ lsmod |grep sony
sony_laptop            28732  0 
rfkill                 16220  3 bluetooth,sony_laptop

[jimc@harpo ~]$ lshal -s | grep 8042
platform_i8042
platform_i8042_i8042_AUX_port
platform_i8042_i8042_AUX_port_logicaldev_input_0
platform_i8042_i8042_AUX_port_logicaldev_input
platform_i8042_i8042_KBD_port
platform_i8042_i8042_KBD_port_logicaldev_input

presuming that I can ssh in after a bad resume,
I'll follow up if stuff disappears (as for OP) here.
Comment 8 Jim Cromie 2010-02-02 17:30:28 EST
refining previous desc - after sufficient sleep, screen will repaint,
mouse will move, but buttons nor keyboard

Im able to ssh in from another box, so the machine is up.
Its just the input system thats hosed.

these dmesg errs might be related:

Feb  2 14:43:07 harpo kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(1).
Feb  2 14:43:07 harpo kernel: [drm:radeon_cs_ioctl] *ERROR* Faild to schedule IB !
Feb  2 14:43:07 harpo kernel: [drm:radeon_ib_schedule] *ERROR* radeon: couldn't schedule IB(1).

there are 8011 of these in /var/log/messages currently.

]$ lsmod |grep radeon
radeon                448040  2
ttm                    34212  1 radeon
drm_kms_helper         22700  1 radeon
drm                   135552  4 radeon,ttm,drm_kms_helper
i2c_algo_bit            4820  1 radeon
i2c_core               23352  4 i2c_i801,radeon,drm,i2c_algo_bit


since OP reported missing lshal output,

in current state (hung keyboard, buttons, focus, desktop) but running OS
I have 109 devices in GDL, but after reboot, I have only 108.  
his is unexpected, Ive saved good output for comparison next time.


perhaps Im hijacking this thread ?
Comment 9 Bug Zapper 2010-11-04 07:04:32 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Bug Zapper 2010-12-05 01:50:11 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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