Do not enable the SMBus device on Asus boards if suspend
is used. We do not reenable the device on resume, leading to all sorts
of undesirable effects, the worst being a total fan failure after
resume on Samsung P35 laptop.
Signed-off-by: Carl-Daniel Hailfinger <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
---
commit f14c852a8cb7483ce0e1e0e05ef49fed2f67103b
tree ab0cbe41b344a62bc81dd5cb093e3b6062c12556
parent 392dbe84f1e484b1e48036ca266cb826fd34f8da
author <[email protected]> Fri, 12 May 2006 11:50:00 +0200
committer <[email protected]> Fri, 12 May 2006 11:50:00 +0200
drivers/pci/quirks.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 19e2b17..9c5509f 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -895,6 +895,7 @@ static void __init k8t_sound_hostbridge(
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237, k8t_sound_hostbridge);
+#ifndef CONFIG_ACPI_SLEEP
/*
* On ASUS P4B boards, the SMBus PCI Device within the ICH2/4 southbridge
* is not activated. The myth is that Asus said that they do not want the
@@ -906,8 +907,12 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_V
* bridge. Unfortunately, this device has no subvendor/subdevice ID. So it
* becomes necessary to do this tweak in two steps -- I've chosen the Host
* bridge as trigger.
+ *
+ * Actually, leaving it unhidden and not redoing the quirk over suspend2ram
+ * will cause thermal management to break down, and causing machine to
+ * overheat.
*/
-static int __initdata asus_hides_smbus = 0;
+static int __initdata asus_hides_smbus;
static void __init asus_hides_smbus_hostbridge(struct pci_dev *dev)
{
@@ -1050,6 +1055,8 @@ static void __init asus_hides_smbus_lpc_
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1, asus_hides_smbus_lpc_ich6 );
+#endif
+
/*
* SiS 96x south bridge: BIOS typically hides SMBus device...
*/
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
Pavel Machek wrote:
> Do not enable the SMBus device on Asus boards if suspend
> is used. We do not reenable the device on resume, leading to all sorts
> of undesirable effects, the worst being a total fan failure after
> resume on Samsung P35 laptop.
>
> Signed-off-by: Carl-Daniel Hailfinger <[email protected]>
> Signed-off-by: Pavel Machek <[email protected]>
This is probably also -stable material.
Regards,
Carl-Daniel
> ---
> commit f14c852a8cb7483ce0e1e0e05ef49fed2f67103b
> tree ab0cbe41b344a62bc81dd5cb093e3b6062c12556
> parent 392dbe84f1e484b1e48036ca266cb826fd34f8da
> author <[email protected]> Fri, 12 May 2006 11:50:00 +0200
> committer <[email protected]> Fri, 12 May 2006 11:50:00 +0200
>
> drivers/pci/quirks.c | 9 ++++++++-
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 19e2b17..9c5509f 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -895,6 +895,7 @@ static void __init k8t_sound_hostbridge(
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8237, k8t_sound_hostbridge);
>
> +#ifndef CONFIG_ACPI_SLEEP
> /*
> * On ASUS P4B boards, the SMBus PCI Device within the ICH2/4 southbridge
> * is not activated. The myth is that Asus said that they do not want the
> @@ -906,8 +907,12 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_V
> * bridge. Unfortunately, this device has no subvendor/subdevice ID. So it
> * becomes necessary to do this tweak in two steps -- I've chosen the Host
> * bridge as trigger.
> + *
> + * Actually, leaving it unhidden and not redoing the quirk over suspend2ram
> + * will cause thermal management to break down, and causing machine to
> + * overheat.
> */
> -static int __initdata asus_hides_smbus = 0;
> +static int __initdata asus_hides_smbus;
>
> static void __init asus_hides_smbus_hostbridge(struct pci_dev *dev)
> {
> @@ -1050,6 +1055,8 @@ static void __init asus_hides_smbus_lpc_
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH6_1, asus_hides_smbus_lpc_ich6 );
>
> +#endif
> +
> /*
> * SiS 96x south bridge: BIOS typically hides SMBus device...
> */
>
--
http://www.hailfinger.org/
On P? 12-05-06 12:13:22, Carl-Daniel Hailfinger wrote:
> Hi!
>
> Pavel Machek wrote:
> > Do not enable the SMBus device on Asus boards if suspend
> > is used. We do not reenable the device on resume, leading to all sorts
> > of undesirable effects, the worst being a total fan failure after
> > resume on Samsung P35 laptop.
> >
> > Signed-off-by: Carl-Daniel Hailfinger <[email protected]>
> > Signed-off-by: Pavel Machek <[email protected]>
>
> This is probably also -stable material.
Yes, I'd like to see it go into -stable. (But IIRC stable rules were
"mainline first").
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>>
>> This is probably also -stable material.
>
>Yes, I'd like to see it go into -stable. (But IIRC stable rules were
>"mainline first").
That rule was already broken IIRC.
Jan Engelhardt
--
On Fri, May 12, 2006 at 12:49:24PM +0200, Jan Engelhardt wrote:
> >>
> >> This is probably also -stable material.
> >
> >Yes, I'd like to see it go into -stable. (But IIRC stable rules were
> >"mainline first").
>
> That rule was already broken IIRC.
For non-security issues? The rule is, "accepted by mainline". So has
the maintainer accepted this yet or not?
thanks,
greg k-h
Pavel Machek <[email protected]> wrote:
>
> Do not enable the SMBus device on Asus boards if suspend
> is used. We do not reenable the device on resume, leading to all sorts
> of undesirable effects, the worst being a total fan failure after
> resume on Samsung P35 laptop.
>
> Signed-off-by: Carl-Daniel Hailfinger <[email protected]>
> Signed-off-by: Pavel Machek <[email protected]>
>
> ---
> commit f14c852a8cb7483ce0e1e0e05ef49fed2f67103b
> tree ab0cbe41b344a62bc81dd5cb093e3b6062c12556
> parent 392dbe84f1e484b1e48036ca266cb826fd34f8da
> author <[email protected]> Fri, 12 May 2006 11:50:00 +0200
> committer <[email protected]> Fri, 12 May 2006 11:50:00 +0200
Are these attributions correct, or did Carl-Daniel write it?
Andrew Morton wrote:
> Pavel Machek <[email protected]> wrote:
>> Do not enable the SMBus device on Asus boards if suspend
>> is used. We do not reenable the device on resume, leading to all sorts
>> of undesirable effects, the worst being a total fan failure after
>> resume on Samsung P35 laptop.
>>
>> Signed-off-by: Carl-Daniel Hailfinger <[email protected]>
>> Signed-off-by: Pavel Machek <[email protected]>
>>
>> ---
>> commit f14c852a8cb7483ce0e1e0e05ef49fed2f67103b
>> tree ab0cbe41b344a62bc81dd5cb093e3b6062c12556
>> parent 392dbe84f1e484b1e48036ca266cb826fd34f8da
>> author <[email protected]> Fri, 12 May 2006 11:50:00 +0200
>> committer <[email protected]> Fri, 12 May 2006 11:50:00 +0200
>
> Are these attributions correct, or did Carl-Daniel write it?
I tracked down the bug and provided the patch.
Pavel changed it to use the correct config option.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
On Fri, 12 May 2006, Carl-Daniel Hailfinger wrote:
> Pavel Machek wrote:
> > Do not enable the SMBus device on Asus boards if suspend
> > is used. We do not reenable the device on resume, leading to all sorts
> > of undesirable effects, the worst being a total fan failure after
> > resume on Samsung P35 laptop.
> >
> > Signed-off-by: Carl-Daniel Hailfinger <[email protected]>
> > Signed-off-by: Pavel Machek <[email protected]>
>
> This is probably also -stable material.
Isn't it inevitable that we're going to have to rerun quirks on resume on
some hardware?
Zwane Mwaikambo wrote:
> On Fri, 12 May 2006, Carl-Daniel Hailfinger wrote:
>
>> Pavel Machek wrote:
>>> Do not enable the SMBus device on Asus boards if suspend
>>> is used. We do not reenable the device on resume, leading to all sorts
>>> of undesirable effects, the worst being a total fan failure after
>>> resume on Samsung P35 laptop.
>>>
>>> Signed-off-by: Carl-Daniel Hailfinger <[email protected]>
>>> Signed-off-by: Pavel Machek <[email protected]>
>> This is probably also -stable material.
>
> Isn't it inevitable that we're going to have to rerun quirks on resume on
> some hardware?
Yes, but until we have a proper infrastructure for that, we have to
disable the smbus unhiding as a safe fix.
If you have the time to whip up a patch to add a sane quirks-on-resume
infrastructure, I'd be grateful. See the thread
"[RFC] [PATCH] Execute PCI quirks on resume from suspend-to-RAM" for
some ugly proof-of-concept.
My main motivation was to prevent bricking my laptop. Added functionality
is desirable, but secondary.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Hi.
On Friday 12 May 2006 19:53, Pavel Machek wrote:
> Do not enable the SMBus device on Asus boards if suspend
> is used. We do not reenable the device on resume, leading to all sorts
If this is just a symptom of another problem, how about another patch
addressing the base issue? Obviously it wouldn't be -stable material, but
it's usually better to address the cause instead of the symptoms (or in this
case, 'as well as').
Regards,
Nigel
Hi!
> > >>
> > >> This is probably also -stable material.
> > >
> > >Yes, I'd like to see it go into -stable. (But IIRC stable rules were
> > >"mainline first").
> >
> > That rule was already broken IIRC.
>
> For non-security issues? The rule is, "accepted by mainline". So has
> the maintainer accepted this yet or not?
Andrew took it to the -mm tree. That's as close to "accepted by
maintainer" as it gets, I'd say.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html