Bug 150543 - Fujitsu P2120 Trackpoint IRQ lost after S3 resume
Fujitsu P2120 Trackpoint IRQ lost after S3 resume
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nigel Cunningham
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-07 23:18 EST by TC
Modified: 2008-03-10 15:05 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-10 15:05:30 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)
dmesg output for 2.6.14 on P2120, after hibernate-resume (29.22 KB, text/plain)
2005-11-14 00:59 EST, TC
no flags Details
dmesg output for 2.6.15-1.1830_FC4 after S3 suspend/resume (22.41 KB, text/plain)
2006-02-07 03:14 EST, TC
no flags Details

  None (edit)
Description TC 2005-03-07 23:18:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050302 Firefox/1.0.1 Fedora/1.0.1-1.3.2

Description of problem:
With my Fujitsu P2120 notebook (Transmeta Crusoe processor, Ali chipset)
I can suspend and resume using S3 on the most recent FC3 kernel 2.6.10-1.770_FC3
[it needs a radeon video card POST to reset the terminal].

'cat /proc/interrupts' on a normal boot indicates IRQ 1 and IRQ 12 used by i8042
(IRQ 1 => Keyboard, IRQ 12 => Trackpoint).

However, upon resume from S3, IRQ 1 is registered but IRQ 12 no longer shows up
in /proc/interrupts. AFAIK, the mouse driver is statically built into the kernel, so I can't even try unloading and reloading the module.

Fn-F4 (Mouse enable) doesn't have any effect.

Version-Release number of selected component (if applicable):
kernel-2.6.10-1.770_FC3

How reproducible:
Always

Steps to Reproduce:
1. Suspend to Ram (S3)
2. Resume
3. Trackpoint no longer functions
  

Actual Results:  Mouse pointer frozen

Expected Results:  Mouse pointer functioning normally after S3 resume

Additional info:
Comment 1 TC 2005-07-13 00:13:34 EDT
Problem persists on Fedora Core 4 kernel-2.6.12-1.1390_FC4.i686.rpm
Comment 2 Dave Jones 2005-07-15 17:34:04 EDT
[This comment has been added as a mass update for all FC4 kernel bugs.
 If you have migrated this bug from an FC3 bug today, ignore this comment.]

Please retest your problem with todays 2.6.12-1.1398_FC4 update.

If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..

mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak
kudzu


Thank you.
Comment 3 TC 2005-07-17 23:07:59 EDT
kernel 2.6.12-1.1398_FC4 does not solve the problem.
Comment 4 Dave Jones 2005-09-30 02:47:05 EDT
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.
Comment 5 TC 2005-09-30 23:21:56 EDT
I installed kernel-2.6.13-1.1526_FC4 and tested the Suspend to RAM
functionality. It still exhibits the same bug (i.e., Mouse IRQ lost after resume).
Comment 6 Dave Jones 2005-11-10 14:53:29 EST
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.
Comment 7 TC 2005-11-14 00:54:54 EST
This kernel version still does not solve the problem, though the dmesg output
indicates that the mouse driver recognizes that there is a problem.
Comment 8 TC 2005-11-14 00:59:35 EST
Created attachment 121005 [details]
dmesg output for 2.6.14 on P2120, after hibernate-resume

The dmesg output indicates a cold boot, followed by hibernate (set ACPI to S3
mode). Initial hibernate attempt fails, second attempt succeed, and upon
resume, the psmouse.c driver flags an error. /proc/interrupts for i8042 on
IRQ12 (the trackpoint device) will not increment until the next
hibernate-resume cycle, where it indicates the new (presumably not serviced)
interrupt count.
Comment 9 Dave Jones 2006-02-03 02:04:10 EST
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.
Comment 10 TC 2006-02-07 03:14:09 EST
Created attachment 124305 [details]
dmesg output for 2.6.15-1.1830_FC4 after S3 suspend/resume

Problem persists in 2.6.15. Trackpoint still not recognized after a
suspend/resume cycle. (grep for psmouse in dmesg output)
Comment 11 Dave Jones 2006-09-16 22:40:22 EDT
[This comment added as part of a mass-update to all open FC4 kernel bugs]

FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel.  As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
to FC5.

Please retest with Fedora Core 5.

Thank you.
Comment 12 Dave Jones 2006-10-16 17:41:05 EDT
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.
Comment 13 TC 2006-11-09 23:09:21 EST
In 2.6.18-1.2200-FC5, I cannot resume from hibernation successfully. The system
will hardlock (no display, keyboard does not respond). Consequently I cannot
test this bug against the current FC5 2.6.18 kernel.
Comment 14 Nigel Cunningham 2007-05-18 19:12:30 EDT
Have you had the chance to try any newer kernels?
Comment 15 TC 2007-05-20 22:51:25 EDT
All kernel versions post 2.6.17 (incl latest FC5 2.6.20-1.2316.fc5)had one or
more problems resuming from S3 suspend. Usually the system will hardlock and the
screen stays blank.

However, I've found a workaround for the trackpoint bug.
 
http://leog.net/fujp%5Fforum/topic.asp?TOPIC_ID=10149

(The BIOS setting for the trackpoint must be set to MANUAL in order for the
Fn-F4, Fn-F4 switch to work).
Comment 16 Nigel Cunningham 2007-05-21 20:02:11 EDT
Ok. Let's see what we can do with the current kernel. Could you please give the
current fc6 (or fc7 if you want to run test4) kernel a try, and let me know what
problems (if any) you get? Could you also please attach current dmesg output.

Thanks!

I'll reassign to me. Dave already has enough work, I'm sure :)
Comment 17 TC 2007-05-22 02:04:52 EDT
Can the FC6/FC7 kernel install on my FC5 distro, or would I need to upgrade to
the new distro? I've tried the FC5 2.6.20-1.2316.fc5 kernel, and it still froze
on resume from S3 suspend.
Comment 18 Nigel Cunningham 2007-05-22 02:45:08 EDT
It should work fine. I would suggest installing it with a separate GRUB entry,
just in case, but I'd be surprised if there was an issue. It may be better to do
a distro upgrade though, because then you get the newer versions of the
associated suspend-to-ram related userspace utilities as well.
Comment 19 TC 2007-05-22 04:31:45 EDT
I tried to install kernel-2.6.21-1.3167-fc7 on my FC5 distro, but it complains
about requiring mkinitrd >= 6.0.9-1. I have mkinitrd-5.0.32-2 installed. I'd
proceed if I can ignore the mkinitrd requirement. Otherwise, there are quite a
few dependencies triggered by the mkinitrd upgrade.
Comment 20 Nigel Cunningham 2007-05-28 19:36:34 EDT
Ok. Do you use LVM? If not, you should be able to just compile in the hard drive
and filesystem modules and get by without it. If you do use LVM, you'll still
need an initrd. We may be able to work around the later case.
Comment 21 TC 2007-06-03 23:04:29 EDT
Recompiling the F7 kernel on FC5 results in a kernel panic on boot, since I'm
using LVM and don't have the updated mkinitrd installed.

Subsequently, I've tried booting using the Fedora 7 LiveCD and going into S3
sleep. It hangs on resume (screen blank, keypresses not recognized). This
happens whether I'm in GUI or Text mode (init 3).

I think my notebook doesn't work with suspend/resume with the newer kernels (>
2.6.17).
Comment 22 Nigel Cunningham 2007-06-11 20:26:42 EDT
We're not doing well, are we? :(

Could you try booting with noapic, nolapic or such like and see if they help at all?
Comment 23 TC 2007-06-11 21:36:28 EDT
Sorry, I've been busy trying to get F7 installed on the P2120. Finally solved
the IDE bug #242472 yesterday.

A quick suspend test using the F7 shipped pm-utils resulted in a frozen system
on resume. This is with default kernel boot parameters.

I'm not familiar with how to configure pm-utils to enable vbepost, etc. which
was needed under FC5 due to the radeon mobility chip. I used to use the
hibernate script from suspend2 under FC5 where those options were enabled.

The notebook is not with me currently, so it'll probably take another couple of
days before I can verify whether the other flags (noapic, etc.) works.
Comment 24 Nigel Cunningham 2007-06-12 00:53:03 EDT
To get pm-utils to enable vbepost, edit the appropriate variables at the top of
/usr/lib/pm-utils/functions.

I'll reenable the 'info needed from reporter' flag as I'll again be waiting to
see how you go with noapic etc.
Comment 25 Richard Hughes 2007-06-12 18:45:54 EDT
(In reply to comment #24)
> To get pm-utils to enable vbepost, edit the appropriate variables at the top of
> /usr/lib/pm-utils/functions.

Please don't do this. Please see http://people.freedesktop.org/~hughsient/quirk/
and submit a quirk for your system. Thanks.

Richard.
Comment 26 TC 2007-06-12 22:01:42 EDT
That's wierd. pm-utils in F7 no longer provides vbetool, despite what yum says.

I've checked the F7 shipped pm-utils-0.99.3-6.fc7 and fedora-testing
pm-utils-0.99.3-6.fc7.1. The changelog in pm-utils-0.99.3-6.fc7.1 suggests that
they're included,  but the actual RPM didn't have vbetool.
Comment 27 Richard Hughes 2007-06-13 06:17:43 EDT
Use the one in updates-testing. The one in fedora GOLD is broken.
Comment 28 TC 2007-06-14 03:03:10 EDT
Re Comment #27:
I did check the pm-utils-0.99.3-6.fc7.1.i686.rpm in updates-testing dated 6th
June 2007. 
It still does not include vbetool in the RPM.
Comment 29 TC 2007-06-14 22:54:42 EDT
I had to rebuild the pm-utils-0.99.3-6.fc7.1.src.rpm to get vbetool in the RPM
package. Strange. Guess I'll file a bug against pm-utils.

In addition, I've also installed hibernate-1.95 (from suspend2).

pm-suspend and "hibernate to ram" both fails with system hardlocking on resume
for kernel-2.6.21.
 
pm-hibernate and "hibernate to disk" both work (this was the first time I've
tried it, and it happened by accident since I didn't change the default order
that hibernate attempts to perform suspend [trymethod suspend2, disk, ram]).

The trackpoint works on resume from "hibernate to disk" since the hardware is
reset by the BIOS on power on.

Surprisingly "resume from disk" is almost as fast as "resume from ram" so as a
workaround I can use "hibernate to disk" for now. This is with the default F7
kernels so it's not using any suspend2 stuff.
Comment 30 TC 2007-06-14 23:33:02 EDT
I tested booting with noapic but that has no effect on the pm-suspend behavior
(system still hangs on resume).
Comment 31 Nigel Cunningham 2007-06-18 21:11:49 EDT
Did vbetools help at all?
Comment 32 TC 2007-06-20 00:03:06 EDT
As far as I can tell, vbetools should be invoked since I used pm-suspend with
the quirks options. I've always enabled hibernate to invoke vbetools, and it
hung just the same.
Comment 33 Nigel Cunningham 2007-07-02 20:41:11 EDT
Regarding the loss of the keyboard/mouse, you might also try adding
i8042.reset=1 to the kernel command line.
Comment 34 Nigel Cunningham 2007-12-10 17:17:31 EST
Any progress here?

By the way, are you on F7 now? The flags say Fedora 5, but you've mentioned F7
above.
Comment 35 petrosyan 2008-03-10 15:05:30 EDT
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.

Setting status to "INSUFFICIENT_DATA".  If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested, 
please feel free to reopen the bug report.

Thank you in advance.

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