From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Peter Clifton <pcjc2@cam.ac.uk>
Cc: trenn@suse.de, linux-acpi@vger.kernel.org,
Vojtech Pavlik <vojtech@suse.cz>,
Dmitry Torokhov <dtor@insightbb.com>, Pavel Machek <pavel@ucw.cz>
Subject: Re: HP Compaq nc6320
Date: Thu, 12 Oct 2006 23:08:23 +0200 [thread overview]
Message-ID: <200610122308.24557.rjw@sisk.pl> (raw)
In-Reply-To: <1160671170.13557.25.camel@pcjc2lap>
On Thursday, 12 October 2006 18:39, Peter Clifton wrote:
> [snip]
>
> > I got several reports that compiling psmouse as module and unload it
> > explicitly on shutdown helps to fix things on newer HPs.
> >
> > E.g. this report:
> > About the fan and battery issue, there are three workaround:
> > - Turn off the machine and quit battery, Place the battery again.
> > - Next time you turn on the machine, turn it off during post.
> > - "modprobe -r psmouse" (after compiling psmouse as a module) before
> > shutdown the machine.
> > Next time you turn on the machine, battery status is working. Not sure
> > about the fans...
>
> My fans seemed to work ok most of the time before, it was the battery
> status which hung, and the speedstep would never go to full speed.
>
> Everything is happy with Ubuntu's kernel 2.6.17-10 and when unloading
> psmouse as part of the shutdown and reboot scripts.
>
> I did dig though psmouse a little, but being a non-expert, couldn't see
> anything odd.
>
> It could be the synaptics driver part I guess, as most people have
> laptops.
Well, on the HPC nx6325 I'm using psmouse is apparently interfering with
ACPI during resume from disk in a destructive way. Namely, with the
2.6.19-rc1-mm1 kernel the temperature in one of the thermal zones
is way off during the resume, so ACPI thinks the critical thermal
point has been passed and it tries to power off the system, which makes
it hang. Unloading psmouse before the suspend apparently helps.
I think it's synaptics too, because it spits reset failure messages during the
resume, if not unloaded before.
> It could be that psmouse keeps a serial driver of some sort alive, or a
> bus active. Perhaps it is still receiving and processing interrupts as
> the bios tries to reboot? Does someone need to open a kernel bug for
> this, and where should it go?
Well I guess so, and it looks like ACPI is the right place to start from.
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
prev parent reply other threads:[~2006-10-12 21:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-11 22:08 HP Compaq nc6320 Peter Clifton
2006-10-11 22:17 ` Peter Clifton
2006-10-11 23:53 ` Peter Clifton
2006-10-12 0:08 ` Peter Clifton
2006-10-12 14:53 ` Rafael J. Wysocki
2006-10-12 16:38 ` Thomas Renninger
2006-10-12 16:39 ` Peter Clifton
2006-10-12 21:08 ` Rafael J. Wysocki [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200610122308.24557.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=dtor@insightbb.com \
--cc=linux-acpi@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=pcjc2@cam.ac.uk \
--cc=trenn@suse.de \
--cc=vojtech@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox