Hello,
I was inspired by Matthew Garrett's talk at LCA to find out why my
Toshiba laptop doesn't resume after a suspend. I did what I could to
diagnose it, and logged the problem here:
http://bugzilla.kernel.org/show_bug.cgi?id=7988
So far, no-one has commented, and my server logs say no-one h
Hi,
I like to ask for inclusion into stable series for these.
The original patch from Dmitry can be found here:
http://bugzilla.kernel.org/show_bug.cgi?id=7689
comment #64, #65.
The reason is:
- These patches fix a lot weird stuff on all recent
HP nc/nx series laptop models.
- The problem
i8042 - let serio bus suspend ports
Let serio subsystem take care of suspending the ports; concentrate
on suspending/resuming the controller itself.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
Signed-off-by: Thomas Renninger <[EMAIL PROTECTED]>
---
drivers/input/serio/i8042.c | 56
psmouse - properly reset mouse on shutdown/suspend
Some people report that they need psmouse module unloaded
for suspend to ram/disk to work properly. Let's make port
cleanup behave the same way as driver unload.
This fixes "bad state" problem on various HP laptops, such
as nx7400.
Signed-off-by
On 2/21/07, Thomas Renninger <[EMAIL PROTECTED]> wrote:
Hi,
I like to ask for inclusion into stable series for these.
The original patch from Dmitry can be found here:
http://bugzilla.kernel.org/show_bug.cgi?id=7689
comment #64, #65.
The reason is:
- These patches fix a lot weird stuff on all
Make ibm-acpi bay support optional at kernel compile time.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
---
This is very useful for people trying out the new ACPI generic bay driver.
It does NOT conflict with ACPI_BAY on purpose. That is for later, when we
are sure ACPI_BAY wil
Hi,
Here is the patch series to clean-up init of EC.
Please test, comment.
Thanks,
Alex
ec.mbox.gz
Description: application/gzip
Hi!
I'm not input or stable maintainer, but...
> I like to ask for inclusion into stable series for these.
>
> The original patch from Dmitry can be found here:
> http://bugzilla.kernel.org/show_bug.cgi?id=7689
> comment #64, #65.
>
> The reason is:
> - These patches fix a lot weird stuff on a
Pavel Machek wrote:
2) Fix is very disconnected from the problem. "Deinitialize mouse so
that fans work after reboot". WTF?
ACPI spec implies that EC controller and PS/2 mouse/keyboards controller
are one entity.
So if mouse screws up "its" controller, it screws up EC as well, meaning
fans
Hi Pavel,
On 2/21/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
Yes, it is quite nasty problem, but:
1) Fix is non-trivial (>100 lines, which violates -stable rule IIRC)
The fix itself is only 30 lines (counting empty lines and comments)
which is not too bad.
2) Fix is very disconnected fro
Hi,
On Wednesday, 21 February 2007 20:52, Pavel Machek wrote:
> Hi!
>
> I'm not input or stable maintainer, but...
>
> > I like to ask for inclusion into stable series for these.
> >
> > The original patch from Dmitry can be found here:
> > http://bugzilla.kernel.org/show_bug.cgi?id=7689
> > co
Hi!
> On 2/21/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
> >
> >Yes, it is quite nasty problem, but:
> >
> >1) Fix is non-trivial (>100 lines, which violates -stable rule IIRC)
> >
>
> The fix itself is only 30 lines (counting empty lines and comments)
> which is not too bad.
Well, one of stabl
On Wed, 21 Feb 2007, Alexey Starikovskiy wrote:
> Pavel Machek wrote:
> >2) Fix is very disconnected from the problem. "Deinitialize mouse so
> >that fans work after reboot". WTF?
> >
> ACPI spec implies that EC controller and PS/2 mouse/keyboards controller
> are one entity. So if mouse screws
Hi,
On Wed, Feb 21, 2007 at 01:07:25AM +0300, Alexey Starikovskiy wrote:
> Dominik Brodowski wrote:
> >Hi,
> >
> >On Tue, Feb 20, 2007 at 09:24:36PM +0300, Alexey Starikovskiy wrote:
> >
> >>>On Mon, Feb 19, 2007 at 08:44:31AM -0500, Dominik Brodowski wrote:
> >>>
> >>>
> On Fri, Feb
On Wed, Feb 21, 2007 at 04:21:14PM -0800, Greg KH wrote:
> On Wed, Feb 21, 2007 at 06:08:05PM +0100, Thomas Renninger wrote:
> > Hi,
> >
> > I like to ask for inclusion into stable series for these.
> >
> > The original patch from Dmitry can be found here:
> > http://bugzilla.kernel.org/show_bug.
On Wed, Feb 21, 2007 at 06:08:05PM +0100, Thomas Renninger wrote:
> Hi,
>
> I like to ask for inclusion into stable series for these.
>
> The original patch from Dmitry can be found here:
> http://bugzilla.kernel.org/show_bug.cgi?id=7689
> comment #64, #65.
After Dmitry and you can agree on them
Hi Chuck,
On Tue, 20 Feb 2007 10:08:26 -0500, Chuck Ebbert wrote:
> I blacklisted the k8temp driver (and the out-of-tree k8_edac driver
> in Fedora) and the temps were still volatile, so that's not causing
> it. Since then I've upgraded the system BIOS from F.06 to F.27 and
> the problems _may_ ha
Hi Luca,
On Tue, 20 Feb 2007 16:33:56 +0100, Luca Tettamanti wrote:
> Motherboard vendors usually provide tools for $(TheOtherOS) that can
> read from all thermal / fan / voltage / whatever sensors, so I guess
> it's possible to make the ACPI driver and the "raw" one play nice with
> each other[1
Hi Matthew,
On Tue, 20 Feb 2007 15:18:13 +, Matthew Garrett wrote:
> On Sun, Feb 18, 2007 at 06:38:05PM +0100, Jean Delvare wrote:
>
> > ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI
> > doesn't conflict with only k8temp, but with virtually all hardware
> > monitoring drive
Jean Delvare wrote:
> Can you try to load the i2c-dev driver, then run the following commands
> and report the results:
> $ i2cdetect -l
> For each bus listed:
> $ i2cdetect N
FWIW it's really an ATIIXP chipset, but supposedly PIIX4 compatible:
# i2cdetect -l
i2c-0 smbus SMBus PIIX4 a
On Tue, 20 Feb 2007 14:11:42 -0500, Dave Jones wrote:
> On Tue, Feb 20, 2007 at 10:08:26AM -0500, Chuck Ebbert wrote:
>
> >i2c_core
> >i2c_ec
> >i2c_piix4
> >asus_acpi (on a Compaq???)
> >sbs
>
> Something is pulling in asus_acpi as a dependancy. I've never
> figured out
On Wed, 21 Feb 2007 11:03:07 -0500, Chuck Ebbert wrote:
> Jean Delvare wrote:
> > Can you try to load the i2c-dev driver, then run the following commands
> > and report the results:
> > $ i2cdetect -l
> > For each bus listed:
> > $ i2cdetect N
>
> FWIW it's really an ATIIXP chipset, but supposedly
On Wed, Feb 21, 2007 at 05:17:37PM +0100, Jean Delvare wrote:
> On Tue, 20 Feb 2007 14:11:42 -0500, Dave Jones wrote:
> > On Tue, Feb 20, 2007 at 10:08:26AM -0500, Chuck Ebbert wrote:
> >
> > > i2c_core
> > > i2c_ec
> > > i2c_piix4
> > > asus_acpi (on a
On Wed, Feb 21, 2007 at 12:37:40PM -0500, Dave Jones wrote:
> On Wed, Feb 21, 2007 at 05:17:37PM +0100, Jean Delvare wrote:
> > On Tue, 20 Feb 2007 14:11:42 -0500, Dave Jones wrote:
> > > On Tue, Feb 20, 2007 at 10:08:26AM -0500, Chuck Ebbert wrote:
> > >
> > > > i2c_core
> > >
The brightness class core does not update the initial status of
the device's brightness at register time. Do it by ourselves
before we register the class device.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Cc: Richard Purdie <[EMAIL PROTECTED]>
---
NOTE: This patch needs an AC
25 matches
Mail list logo
